Implementación de Base de Datos Avanzadas

Objeto relacional

          El modelo de base de datos objeto-relacional integra los conceptos de la tradicional base de datos relacional y los conceptos de paradigma de objetos que se utiliza en la programación orientada a objetos (POO).

          El objetivo de este concepto es poder aplicar la tecnología madura de bases de datos relacionales sobre la organización de los datos complejos es decir datos de texto e imagen, mapas, datos en el rango de audio etc. Las bases de datos Objeto-relacional son compatibles con estos objetos de datos y las operaciones de mayor complejidad.

          En bases de datos orientadas a objetos, los usuarios pueden definir operaciones sobre los datos como parte de la definición de la base de datos. Una operación (llamada función) se especifica en dos partes. La interfaz (o signatura) de una operación incluye el nombre de la operación y los tipos de datos de sus argumentos (o parámetros). La implementación (o método) de la operación se especifica separadamente y puede modificarse sin afectar la interfaz. Los programas de aplicación de los usuarios pueden operar sobre los datos invocando a dichas operaciones a través de sus nombres y argumentos, sea cual sea la forma en la que se han implementado. Esto podría denominarse independencia entre programas y operaciones. SQL:2003, es el estándar de SQL92 ampliado, soporta los conceptos orientados a objetos y mantiene la compatibilidad con SQL92.

          En una base de datos objeto relacional los dominios de dicha base de datos ya no son sólo atómicos por esta razón no cumplen la 1FN debido a que las tuplas también pueden ser una relación, que llevará a la creación de una relación de relaciones es asi que no se puede aplicar el concepto de normalización. Esto porque ni siquiera se puede aplicar la primera forma normal y como consecuencia ni la segunda, ni tercera etc.

          De este modo, se genera la posibilidad de guardar objetos más complejos en una sola tabla con referencias a otras relaciones, con lo que se acerca más al paradigma de programación orientada a objetos.

 

Base de Datos Activa

          El paradigma de bases de datos activas planteado por Morgenstern en 1983, describe la noción de una base de datos activa, como una metáfora de su comportamiento, el cual se concentra” en la dinámica de la interacción con los usuarios unido a la ”inteligencia” de la base de datos ” .

          Una base de datos activa, son aquellas bases de datos capaz de detectar situaciones de interés y de actuar en consecuencia.(Mota Noviembre 2005). El mecanismo que se utiliza se parece a las reglas de producción utilizadas en el área de inteligencia artificial.

Representación de una Base de Datos Activa.

           El poder especificar reglas con una serie de acciones que se ejecutan automáticamente cuando se producen ciertos eventos, es una de las mejoras de los sistemas de gestión de bases de datos que se consideran de gran importancia desde hace algún tiempo. Mediante estas reglas se puede hacer respetar reglas de integridad, generar datos derivados, controlar la seguridad o implementar reglas de negocio. De hecho, la mayoría de los sistemas relacionales comerciales disponen de disparadores (triggers). Se han realizado mucha investigación sobre lo que debería ser un modelo general de bases de datos activas desde que empezaron a aparecer los primeros disparadores. El modelo que se viene utilizando para especificar bases de datos activas es el modelo evento–condición–acción (ECA).

           Dentro de este modelo las reglas que se utilizan para especificar situaciones con sus acciones, se les llaman reglas del tipo (ECA) o reglas que siguen el paradigma de (ECA).

El formato genérico de estas reglas es:

ON evento

IF condición

THEN acción

• El evento (o eventos) que dispara la regla: Pueden ser operaciones de consulta o actualización que se aplican explícitamente sobre la base de datos. También pueden ser eventos temporales (por ejemplo, que sea una determinada hora del día) u otro tipo de eventos externos (definidos por el usuario).
• La condición: Determina si la acción de la regla se debe ejecutar. Una vez que ocurre el evento disparador, se puede evaluar una condición (es opcional). Si no se especifica condición, la acción se ejecutaría cuando suceda el evento. Si se especifica condición, la acción se ejecutaría sólo si la condición es evaluada en verdadero.
• La acción a realizar: Puede ser una transacción sobre la base de datos o un programa externo que se ejecutaría automáticamente.

           Casi todos los sistemas relacionales incorporan reglas activas simples denominadas disparadores (triggers), que están basados en el modelo ECA:

• Los eventos son sentencias SQL de manejo de datos (INSERT, DELETE, UPDATE).
• La condición (que es opcional) es un predicado booleano expresado en SQL.
• La acción es una secuencia de sentencias SQL, que pueden estar inmersas en un lenguaje de programación integrado en el producto que se esté utilizando (por ejemplo, PL/SQL en Oracle).

           El modelo ECA se comporta de un modo simple e intuitivo: cuando ocurre el evento, si la condición es verdadera, entonces se ejecuta la acción. Se dice que el disparador es activado por el evento, es considerado durante la verificación de su condición y es ejecutado si la condición es cierta. Sin embargo, hay diferencias importantes en el modo en que cada sistema define la activación, consideración y ejecución de disparadores.

           Los disparadores relacionales tienen dos niveles de granularidad: a nivel de fila y a nivel de sentencia. En el primer caso, la activación tiene lugar para cada tupla involucrada en la operación y se dice que el sistema tiene un comportamiento orientado a tuplas. En el segundo caso, la activación tiene lugar sólo una vez para cada sentencia SQL, refiriéndose a todas las tuplas invocadas por la sentencia, con un comportamiento orientado a conjuntos. Además, los disparadores tienen funcionalidad inmediata o diferida. La evaluación de los disparadores inmediatos normalmente sucede inmediatamente después del evento que lo activa (opción después), aunque también puede precederlo (opción antes) o ser evaluados en lugar de la ejecución del evento (opción en lugar de). La evaluación diferida de los disparadores tiene lugar al finalizar la transacción en donde se han activado (tras la sentencia COMMIT).

           Un disparador puede activar otro disparador. Esto ocurre cuando la acción de un disparador es también el evento de otro disparador. En este caso, se dice que los disparadores se activan en cascada.

           El lenguaje de reglas de este tipo debe tener componentes para especificar eventos, especificar condiciones y especificar acciones. Adicionalmente a la especificación de las reglas es importante conocer cómo es la semántica de la ejecución de estas. En particular, existen tres aspectos relevantes en la forma en cómo se ejecutan las reglas, que describen el dinamismo de una base de datos.

           Es importante saber si una regla se dispara una vez por cada tupla “tocada” o una sola vez por todas las tuplas “tocadas”.

           Otro aspecto importante es si se puede especificar una sola regla por evento o más de una. En el caso en el que se permita más de una regla por evento, en cuál orden se ejecutan esas reglas y cuándo se termina la ejecución.

           Finalmente, es necesario determinar si las reglas se van a ejecutar como parte de la transacción donde se disparen o si se van a ejecutar como transacciones aparte. Esto es fundamental por la propiedad de atomicidad que se debe garantizar para las transacciones de una base de datos.

           De este modo, al encontrarse las reglas definidas como parte del esquema de la base de datos, se comparten por todos los usuarios, en lugar de estar replicadas en todos los programas de aplicación. Cualquier cambio sobre el comportamiento reactivo se puede llevar a cabo cambiando solamente las reglas activas, sin necesidad de modificar las aplicaciones. Además, mediante los sistemas de bases de datos activas se hace posible integrar distintos subsistemas (control de accesos, gestión de vistas, etc.) y se extiende el ámbito de aplicación de la tecnología de bases de datos a otro tipo de aplicaciones.

Características de las reglas activas

           Además de las características que poseen los disparadores que incorporan los sistemas relacionales, algunos sistemas más avanzados y algunos prototipos de bases de datos activas ofrecen algunas características que incrementan la expresividad de las reglas activas:

Propiedades de las reglas activas

           No es difícil diseñar reglas activas de modo individual, una vez se han identificado claramente el evento, la condición y la acción. Sin embargo, entender el comportamiento colectivo de las reglas activas es más complejo ya que su interacción suele ser sutil. Por este motivo, el problema principal en el diseño de las bases de datos activas está en entender el comportamiento de conjuntos complejos de reglas. Las propiedades principales de estas reglas son terminación, confluencia e idéntico comportamiento observable.

• Un conjunto de reglas garantiza la terminación cuando, para cada transacción que puede activar la ejecución de reglas, esta ejecución produce un estado final en un número finito de pasos.
• Un conjunto de reglas garantiza la confluencia cuando, para cada transacción que puede activar la ejecución de reglas, la ejecución termina produciendo un estado final único que no depende del orden de ejecución de las reglas.
• Un conjunto de reglas garantiza un comportamiento observable idéntico cuando, para cada transacción que puede activar la ejecución de reglas, esta ejecución es concluyente y todas las acciones visibles llevas a cabo por la regla son idénticas y producidas en el mismo orden.

           Estas propiedades no tienen la misma importancia. Concretamente, la terminación es una propiedad esencial; se debe evitar la situación en que las transacciones, activadas por el usuario, causan ejecuciones infinitas por la activación recursiva de reglas. Por otra parte, la confluencia y el idéntico comportamiento observable no son esenciales.

           El proceso del análisis de reglas permite la verificación de si las propiedades deseadas se cumplen en un conjunto de reglas. Una herramienta esencial para verificar la terminación es el grafo de activación, que representa interacciones entre reglas. El grafo se crea incluyendo un nodo para cada regla y un arco de la regla R1 a la regla R2 cuando la acción de R1 contiene una sentencia del lenguaje de manejo de datos que es también uno de los eventos de R2. Una condición necesaria para la no terminación es la presencia de ciclos en el grafo de activación: sólo en este caso podemos tener una secuencia infinita de ejecución de reglas.

           Los sistemas que tienen muchas reglas activas suelen ser cíclicos. Sin embargo, sólo unos pocos ciclos son los que provocan situaciones críticas. De hecho, el que un grafo sea cíclico es condición necesaria pero no suficiente para la no terminación.

           Uno de los problemas que ha limitado el uso extensivo de reglas activas, a pesar de su potencial para simplificar el desarrollo de bases de datos y de aplicaciones, es el hecho de que no hay técnicas fáciles de usar para diseñar, escribir y verificar reglas. Por ejemplo, es bastante difícil verificar que un conjunto de reglas es consistente, es decir, que no se contradice. También es difícil garantizar la terminación de un conjunto de reglas bajo cualquier circunstancia. Para que las reglas activas alcancen todo su potencial, es necesario desarrollar herramientas para diseñar, depurar y monitorizar reglas activas que puedan ayudar a los usuarios en el diseño y depuración de sus reglas.

Aplicaciones de las BD activas

           Las aplicaciones del paradigma de base de datos activas son muy variadas. Una primera clasificación de las aplicaciones lo establece el uso de las reglas para labores internas del DBMS, o sea, reglas generadas por el sistema, no visibles a los usuarios, o para labores externas, las cuales son especificadas por el usuario y permiten realizar labores específicas dependientes del dominio del problema. Algunos ejemplos de las actividades que se pueden realizar en estas aplicaciones se muestran a continuación.

           Internas: Soportar las características clásicas del manejo o administración de las bases de datos. Ejemplos de estas aplicaciones son:

• Control de integridad. (Restricciones implícitas y explícitas.)
• Mantenimiento de vistas y datos derivados, los cuales pueden existir virtualmente o ser materializados.
• Administración de copias de los datos (duplicación).
• Seguridad. Recuperación ante fallas.

Existen otras aplicaciones internas potenciales, pues hasta el momento no han sido explotadas por los DBMS, entre ellas se encuentran: mantenimiento de versiones, administración de la seguridad, “tracking” de eventos.

           Externas: Estas aplicaciones contienen conocimiento de la aplicación, expresándola en forma de reglas, a las cuales comúnmente se les llama reglas del negocio.

           Con respecto al control de integridad las restricciones que se pueden establecer con las reglas activas son:

• Restricciones estáticas: Se evalúan sobre un estado de la base de datos, un ejemplo de estas son las restricciones de dominio.
• Restricciones dinámicas: Se evalúan sobre la transición de un estado a otro, por ejemplo: el sueldo de un empleado sólo puede aumentar.

Independientemente de si las restricciones son estáticas o dinámicas, dependiendo de quién las especifica, se pueden dividir en:

• Restricciones “built-in”: Son restricciones fijas y especificadas con cláusulas del lenguaje de Definición de Datos (DDL), por ejemplo: referential integrity (foreign keys, REFERENCES) y claves primarias (PRIMARY KEY).
• Restricciones genéricas: Son restriccionesespecificadas por el usuario, por ejemplo con la definición de CONSTRAINTS; algunos ejemplos de estos son: NOT NULL, UNIQUE y CHECK.  

Base de Datos Deductivas

    Una base de datos deductiva consiste en un sistema de almacenamiento que, a través de ciertas reglas definidas, es capaz de utilizar la información contenida en la base de datos para deducir información adicional.

    Este tipo de bases de datos se fundamenta en materias como la lógica matemática y el cálculo relacional, por ello también se las suele denominar como bases de datos lógicas. Su objetivo es definir nuevas relaciones para el procesamiento de consultas a través de la información presente en la propia base de datos.

    Para ello, las bases de datos deductivas utilizan un lenguaje declarativo (normalmente Prolog). Este lenguaje tiene la particularidad de definir reglas que marcan lo que el programa, en este caso la base de datos, desea conseguir. Esto lo diferencia de los lenguajes usados habitualmente en otras bases de datos como el SQL, que definen el cómo conseguirlo.

    En definitiva, las bases de datos activas y deductivas son capaces de deducir nuevos hechos a partir de la información presente en la data base, teniendo en cuenta determinadas reglas definidas de antemano por su lenguaje.

Características y aspectos a tener en cuenta

Las principales características de las bases de datos deductivas son las siguientes:

• Utilizan el lenguaje DataLog, un lenguaje declarativo.
• Permiten hacer consultas a través de reglas lógicas, deduciendo nueva información por medio de los datos presentes en la database.
• Son capaces de soportar conjuntos y objetos de gran complejidad.
• Al contrario que en otras bases de datos, no existen relaciones entre entidades, sino predicados. También se basan en hechos en lugar de tulpas.
• Pueden establecer negaciones por estratos.

En cualquier caso, la característica fundamental de esta base de datos es que ha de ser modelada a través de reglas lógicas, las cuáles le permiten deducir información a partir de los datos ya almacenados.

Ventajas y desventajas

Las bases de datos deductivas tienen un funcionamiento muy particular, lo cual provoca que su uso tenga ciertas ventajas y desventajas.

Ventajas

Entre las ventajas de las bases de datos deductivas se pueden citar:

• Son capaces de deducir información a partir de reglas lógicas que interpretan los datos almacenados.
• Derivado del punto anterior, contienen menor cantidad de datos y ocupan menos espacio de almacenamiento, ya que hay información que no es necesario almacenar, sino que es la propia base de datos quien se encarga de deducirla.
• Se pueden realizar consultas recursivas basadas en bucles y ciclos de procesamiento que se repiten.

Desventajas

Por su parte, las principales desventajas de las bases de datos deductivas son:

• Es necesario definir criterios a la hora de utilizar las reglas de deducción, para que la base de datos pueda trabajar con coherencia.
• Obligan a replantear las convenciones formales frecuentes en las bases de datos y adaptarlas a un contexto deductivo.
• Además de definir criterios lógicos, hay que desarrollar procesos de deducción eficaces.
• Si las reglas lógicas y los procesos no están correctamente definidos, es probable que la base de datos no arroje resultados coherentes, o incluso que se vea atrapada en bucles infinitos.

 Orientada o Objeto Dinamico

Disparadores

Un disparador es un objeto con nombre en una base de datos que se asocia con una tabla, y se activa cuando ocurre un evento en particular para esa tabla.

El disparador queda asociado a la tabla nombre_tabla. Esta debe ser una tabla permanente, no puede ser una tabla TEMPORARY ni una vista.

momento_disp es el momento en que el disparador entra en acción. Puede ser BEFORE (antes) o AFTER (despues), para indicar que el disparador se ejecute antes o después que la sentencia que lo activa.

evento_disp indica la clase de sentencia que activa al disparador. Puede ser INSERT, UPDATE, o DELETE. Por ejemplo, un disparador BEFORE para sentencias INSERT podría utilizarse para validar los valores a insertar.

No puede haber dos disparadores en una misma tabla que correspondan al mismo momento y sentencia. Por ejemplo, no se pueden tener dos disparadores BEFORE UPDATE. Pero sí es posible tener los disparadores BEFORE UPDATE y BEFORE INSERT o BEFORE UPDATE y AFTER UPDATE.

sentencia_disp es la sentencia que se ejecuta cuando se activa el disparador. Si se desean ejecutar múltiples sentencias, deben colocarse entre BEGIN ... END, el constructor de sentencias compuestas. Esto además posibilita emplear las mismas sentencias permitidas en rutinas almacenadas.

Tipos avanzados de base de datos:

Las exigencias del desarrollo de computadoras más potentes, ha traído la aparición de aplicaciones más potentes, que requieren la utilización de una serie de datos más complejamente relacionados y con necesidades de consulta, altamente relacionados o consultas muy particulares, como los sistemas de información geográfica, el diseño de circuitos entre otros, por lo que el modelo de bases de datos relacionales se ha visto superado y si bien es los lenguajes de manipulación y definición de datos, son muy simples de manejar directamente por el usuario, son difíciles de insertar en un lenguaje de programación convencional, dando lugar a un problema de resistencia de un lenguaje al ser utilizado junto con otro.

Ya que los investigadores, buscan cumplir, con estas nuevas exigencias, han estado buscando nuevas alternativas fiables y se han desarrollado alternativas como los modelos de bases de datos, deductivos, los persistentes, los funcionales o los orientados a objetos.

Modelo orientado a objetos

Él modelo de base de datos orientado a objetos, se centra en tratar los problemas desde un punto realista, y modelando cada uno de ellos como si se tratase de un conjunto de elementos u objetos que interrelacionan entre sí para solucionar un problema como si fueran las partes de una maquinaria más compleja que sus partes individuales.

Desde el punto de vista de una base de datos, los datos se almacenan de una forma parecida al sistema relacional, de manera que existirá una tabla por cada clase o subclase de nuestro esquema. Quizás la única diferencia sustancial es que cada objeto tiene asignado automáticamente un número (OID- Object Identifier) que sirve para poder ser referenciado por los objetos de los que forma parte. El concepto de OID sustituye, en parte, al de clave en el sistema relacional.

• Modelo declarativo

Este modelo, resulta sumamente intuitivo para el usuario, lo que permite que se olvide de problemas que conlleva por si sola la programación en otros modelos. Suele usarse este modelo, para grandes bases de datos que tienen como objetivo primordial la consulta de datos o información. Utiliza un lenguaje declarativo, el cual no debe confundirse con el SQL.

Dentro de las bases de datos declarativas existen dos fundamentales:

• Modelo deductivo

El modelo deductivo de las bases de datos, se basa en predicciones lógicas, que genera a través de consultas recurrentes, además deduce relaciones indirectas de los datos que se almacenan.

 

Bases de Datos Espaciales

Una Base de Datos Espacial permite el almacenamiento de las geometrías de un archivo cartográfico dentro de una base de datos, de modo que podamos almacenar y analizar estos datos de un modo más eficiente gracias al lenguaje SQL que con el tradicional formato shapefile.

Como analista GIS, ¿me es necesario conocer cómo trabajar con Bases de Datos Espaciales?

Al usar una Base de Datos Espacial, descubrirás, como analista, que buena parte de las limitaciones del formato shapefile desaparecen cuando se usan funciones basadas en el lenguaje de consulta SQL. Gracias al lenguaje de consulta, el tiempo a la hora de realizar operaciones espaciales (buffer, intersección entre geometrías…) se reduce debido a que opera con unos campos que codifican la geometría en vez de usar la geometría de los archivos vectoriales.

Desde la creación de geometrías, obtención de datos acerca de éstas pasando por operaciones espaciales, tenemos toda una serie de funcionalidades que aprovechan la potencia del lenguaje SQL a la hora de efectuar cualquier análisis sobre nuestros datos espaciales, obteniendo el resultado con el formato deseado directamente.

¿Qué programas actuales hay en el mercado que manejen Bases de Datos Espaciales?
Actualmente encontramos en el programa ArcGIS de la compañía ESRI la posibilidad de guardar nuestros datos en el formato geodatabase, el cual es el modelo de Bases de Datos Espaciales desarrollado por la propia compañía. Aunque otros programas, como QGIS, pueden cargar estos datos, se necesita tener una licencia del propio ArcGIS para la generación y manipulación de geodatabases.

Pero yo manejo software libre, ¿qué opciones tengo?
Obviamente, el principal problema de la geodatabase es que es un formato propietario de ESRI y, aunque es posible cargarla en otros programas, para su correcta creación y manipulación se requiere del programa ArcGIS. Afortunadamente, si eres un usuario de software GIS de código abierto (como es el caso de QGIS, gvSIG, UDIG…) tienes diversas alternativas libres para poder trabajar con Bases de Datos Espaciales:
MySQLSpatial – Una extensión de MySQL, base de datos encontrada por defecto en plataformas de hosting y, por tanto, muy usada por desarrolladores web.
Spatialite – Extensión de SQLite, es una base de datos muy simple basada en ficheros.
PostGIS – Extensión de la base de datos PostgreSQL, esta potente base de datos multiplataforma es totalmente compatible con los estándares ofrecidos por el Open Geospatial Consortium (OGC).
H2GIS – Extensión de H2, una base de datos ligera programada en Java, la cual funciona por medio de ficheros del mismo modo que SQLite.

Y de entre todas estas alternativas libres, ¿por qué PostGIS es la mejor?
Todos los programas que se han mencionado anteriormente son buenos programas con licencia gratuita que permiten el manejo de Bases de Datos Espaciales, pero de todos ellos PostGIS destaca por los siguientes motivos:
1. Como se mencionó anteriormente, es compatible con los estándares del OGC, por lo que facilita el intercambio de información geográfica.
2. Permite fácilmente la importación y exportación de datos en distintos formatos (shapefile…) gracias a varias herramientas de conversión.
3. Posee cientos de funciones espaciales 2D y 3D, soportando los formatos alfanumérico, vectorial y ráster.
4. Es un formato compatible con varias programas SIG de escritorio, tanto propietarios (ArcGIS, MapInfo…) como libres (QGIS, gvSIG…), y servidores de mapas web (Geoserver, Mapserver…). Además, PostGIS es la base cartográfica usada para la plataforma de cartografía web CARTO.