Ilustrados comunidad mundial educativa
Inicio | Escribenos
User: Pass: Recordar ó (Registrate!)

| !Publicar Articulo¡

Bases de datos activas

Resumen: Dentro del proceso de desarrollo de los sistemas de bases de datos, los cuales se han convertido en un producto estratégico de primer orden; en el afán de ofrecer una respuesta a las necesidades planteadas por los usuarios y por las aplicaciones avanzadas...
6,955 visitas
Rating: 0
Tell a Friend
Autor: Yanet Espinol Martín

RESUMEN
Dentro del proceso de desarrollo de los sistemas de bases de datos, los cuales se han convertido en un producto estratégico de primer orden; en el afán de ofrecer una respuesta a las necesidades planteadas por los usuarios y por las aplicaciones avanzadas, donde se necesitan herramientas semánticamente más ricas que las provistas por las Bases de Datos Relacionales, aparecen recientes aplicaciones de estos que consisten en ofrecer recursos para definir Reglas Deductivas y Activas que permiten deducir, inferir u obtener información nueva a partir de los datos almacenados o sucesos condicionados. La meta de estas aplicaciones es incorporar a las Bases de Datos Relacionales los beneficios de la lógica y la reacción espontánea ante sucesos predefinidos como instrumentos para la formalización integrada de los aspectos estáticos y dinámicos del modelado de aplicaciones.

El presente trabajo realiza un pequeño estudio de la evolución de las bases de datos, haciendo énfasis en una de las técnicas avanzadas de bases de datos ¨ Bases de Datos Activas ¨ cuyo paradigma que ha tenido grandes impactos desde su surgimiento.

Abstract
Within the development process of database systems, which have become a strategic product of the first order, in the eagerness to respond to the needs raised by users and advanced applications, which need tools semantically richer than those provided by the relational database, are these recent applications that consist of providing resources to define rules and deductive Active allowing deduction, inferred or obtain new information from data stored or conditional events. The goal of these applications is to incorporate the relational database the benefits of logic and reactive to events predefined as instruments for the formalization integrated static and dynamic aspects of modeling applications.

This work makes a small study of the evolution of databases, emphasizing one of the advanced techniques of databases ¨ Active Databases ¨ whose paradigm that has had a major impact since its inception.

INTRODUCCIÓN

Evolución de las Bases de Datos
El término de bases de datos fue escuchado por primera vez en 1963, en un simposio celebrado en California –USA.

¿Qué es una Base de Datos?
Una Base de Datos (BD) es un conjunto de datos interrelacionados entre sí, almacenados con un carácter más o menos permanente en la computadora, es decir, que una Base de Datos puede considerarse una colección de datos variables en el tiempo.

Desde que se empezaron a introducir los ordenadores para automatizar la gestión de las empresas en la década de los sesenta, la evolución de los sistemas de información ha tenido una considerable repercusión en la gestión de los datos, desplazándose el centro de gravedad de la informática que estaba situado en el proceso, hacia la estructuración de los datos. Surge así, a finales de los sesenta y principios de los setenta, la primera generación de productos de bases de datos en red.

Cuando en 1970, el Dr. Codd propuso el Modelo Relacional, no podía pensar que lo que se consideraba más bien una elegante teoría matemática sin posibilidad de implementación eficiente en productos comerciales iba a convertirse, en los años ochenta, en la Segunda Generación de productos de Base de Datos, que actualmente aún domina el mercado.

En los últimos años venimos asistiendo a un avance espectacular en la tecnología de bases de datos: multimedia, activas, deductivas, orientadas a objetos, seguras, temporales, móviles, paralelas, etc.

Esta tercera generación de bases de datos, se caracteriza por proporcionar capacidades de gestión de datos, gestión de objetos y conocimiento, además pretende responder a las necesidades de aplicaciones tales como: CASE (Ingeniería del software asistida por ordenador), CAD/ CAM/CIM, SIG (sistemas de información geográfica), información textual, aplicaciones científicas, sistemas médicos, publicación digital, educación y formación, sistemas estadísticos, comercio electrónico, etc. (Piattini 2000)

A la hora de clasificar estos avances en el campo de las bases de datos, podemos identificar tres dimensiones: rendimiento, funcionalidad/inteligencia y distribución/integración.


Fig. 1 Dimensiones de las Bases de Datos.

  • Rendimiento: Hay que tener en cuenta que los datos almacenados en bases de datos crecen de forma exponencial, ya se empieza a hablar de bases de datos de «petabytes» (1015). Además, los avances en el hardware determinan de forma importante la evolución de las bases de datos. Dentro de esta dimensión, destacan los siguientes tipos de tecnologías: bases de datos paralelas, bases de datos en tiempo real y bases de datos en memoria principal.
     
  • Funcionalidad/Inteligencia: La funcionalidad de las bases de datos ha ido aumentando de forma considerable, ya que gran parte de la «semántica» de los datos que se encontraba dispersa en los programas ha ido migrando hacia el servidor de datos. También hay que tener en cuenta que aspectos como la incertidumbre y el tiempo se están incorporando a las bases de datos. Dentro de estas dimensiones se destacan: las bases de datos activas, deductivas, orientadas a objetos, multimedia, temporales, seguras, difusas, y los almacenes de datos (datawarehousing) y la minería de datos (datamining). (Piattini 2000)
  • Distribución/Integración: El avance espectacular de las comunicaciones así como la difusión cada día mayor del fenómeno Internet/Web, ha revolucionado el mundo de las bases de datos. También la aparición de la «informática móvil» o «computación nómada» obliga a replantearse algunos conceptos fundamentales de las bases de datos. En esta dimensión podemos destacar las siguientes tecnologías: bases de datos distribuidas, federadas y multibases de datos, bases de datos móviles, y bases de datos web.

En muchas aplicaciones, la base de datos debe evolucionar independientemente de la intervención del usuario como respuesta a un suceso o una determinada situación. En los sistemas de gestión de bases de datos tradicionales (pasivas) esto no era posible, pues la evolución de la base de datos se programa en el código de las aplicaciones, esto provocó el surgimiento de los ” sistemas de gestión de bases de datos activas ” , donde esta evolución es autónoma y se define en el esquema de la base de datos.

Mediante los sistemas de bases de datos activas se consigue un nuevo nivel de independencia de datos: la independencia de conocimiento. El conocimiento que provoca una reacción se elimina de los programas de aplicación y se codifica en forma de reglas activas.

DESARROLLO
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.


Fig. 2 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.

  • Granularidad del procesamiento de las reglas.

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

2. Anidamiento de reglas y terminación.
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.

3. Concurrencia con las transacciones.
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:

  • Respecto a los eventos, estos pueden ser temporales o definidos por el usuario. Los eventos temporales permiten utilizar expresiones dependientes del tiempo, como por ejemplo: cada viernes por la tarde, a las 17:30 del 29/06/2002. Los eventos definidos por el usuario son eventos a los que el usuario da un nombre y que son activados por los programas de usuario. Por ejemplo, se podría definir el evento de usuario ¨ nivel_alto_azufre ¨ y que una aplicación lo activara; esto activaría la regla que reacciona al evento.
     
  • La activación de los disparadores puede que no dependa de un solo evento sino que dependa de un conjunto de eventos relacionados en una expresión booleana que puede ser una simple disyunción o una combinación más compleja que refleje la precedencia entre eventos y la conjunción de eventos.
  • La consideración y/o ejecución de reglas se puede retrasar. En este caso, la consideración y/o la ejecución tienen lugar durante transacciones distintas, que pueden ser completamente independientes o pueden estar coordinadas con la transacción en la que se ha verificado el evento.
     
  • Los conflictos entre reglas que se activan por el mismo evento se pueden resolver mediante prioridades explícitas, definidas directamente por el usuario cuando se crea la regla. Se pueden expresar como una ordenación parcial (utilizando relaciones de precedencia entre reglas), o como una ordenación total (utilizando prioridades numéricas). Las prioridades explícitas sustituyen a los mecanismos de prioridades implícitos que poseen los sistemas.
  • Las reglas se pueden organizar en conjuntos y cada conjunto se puede habilitar y deshabilitar independientemente.

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.

CONCLUSIONES
Los avances de las Bases de Datos Activas, forman un punto de importancia trascendental y complementaria al Modelo Relacional en la representación de la realidad.

  • Un Sistema Gestor de Bases de Datos Activo es capaz de monitorizar y reaccionar ante eventos de manera oportuna y eficiente, caracterizándose por su reacción ante ciertas condiciones que ejecutan de forma automática ciertas acciones.
  • Mayor productividad, mejor mantenimiento, reutilización de código.
  • Posibilidad de optimización semántica.
  • Mayor independencia de datos.
  • Integración de distintos subsistemas.
  • Extensión del ámbito de aplicación.

REFERENCIAS BIBLIOGRÁFICAS
1. Mota, S. A. (Noviembre 2005). "Bases de Datos Activas (apuntes de CI-5311)."
2. Piattini, M. y. D., O. (2000). “Advanced Databases: Technology and Desing”. Londres, Artech House.
3. Date, C.J. “Introducción a los Sistemas de Bases de Datos”. PrenticeHall. 7ª edición. 2001.
4. Ullman, J.D. “Database and Knowledge-Base Systems” Computer Science Press.1989. 

AUTORA
Yanet Espinal Martín.
Ocupación: Profesor de la Universidad de las Ciencias Informáticas (UCI).
Graduado: Lic. Ciencia de la Computación.
e-mail: janetdjm@gmail.com, yanete@uci.cu
Curso 2007-2008
"Año 50 de la Revolución"

Articulos relacionados:
Programas Aritméticos, de Aleatoriedad y de Arreglos Desarrollados en Microsoft visual
Resumen:
En este trabajo se presenta el código completo de cada uno de los programas presentados. Se han desarrollado completamente los ejercicios asignados en la clase de Progra...
Teoría General de los Sistemas
Resumen:
Aportes Semanticos. Sistema. Caracteristicas de los sistemas. Entradas. Proceso. Caja Negra. Salidas. Relaciones. Atributos. Contexto. Rango. Subsistemas. Variables. Pará...
Del MS-DOS al Windows (pdf)
Resumen:
En este artículo se aborda la inclusión, estudio, características e influencia del Sistema Operativo (SO) en la Informática Educativa en Cuba. Para ello partimos de la ne...
Generaciones de Computadoras
Resumen:
Evolucion historica de las generaciones de las computadoras, hasta la actualidad.
Principios de Data Mining
Resumen:
Los primeros programadores de computadoras desarrollaban aplicaciones que satisfacían vagamente los requerimientos de información de los usuarios finales. Ahora, gracias ...
Copyright © 2011 ilustrados.com, Monografias, tesis, bibliografias, educacion. Tofos los temas y publicaciones son propiedad de sus respectivos autores ©