Diseño Avanzado de bases de datos

Paradigmas de Bases de Datos.

          Después de los 60’s en las tecnologías de la informaciónse dio un giro en los sistemas de archivos, los cuales selimitaban a la estructuración del almacenamiento físicode los datos. En esta época se dio inicio a las primerasgeneraciones de bases de datos de red y las bases dedatos jerárquicas, ya que era posible guardarestructuras de datos en listas y arboles.

• 1970• Lawrence J. Ellison• Desarrolla Relational Software System más conocido actualmente como RACLE
• 80’s• desarrollará el SQL (Structured Query Language)
• 1990• En la década de 1990 la investigación en bases de datos giró en torno a lasbases de datos orientadas a objetos
• XXI• Surgen diversos manejadores de bases de datos entre ellos, MySQL, SQlite,PostgreSQL, etc.

CONCEPTO DE BASE DE DATOS

          Una base de datos es un conjunto deinformación relacionada con un asunto ocon una finalidad. En Access, una basede datos es un archivo que puedecontener tablas donde se encuentratoda la información sobre un temaespecifico, consultas, formularios,informes entre otros. Tal como unacolección de música, el control dealumnos en un colegio o un directoriotelefónico.

SISTEMA MANEJADOR DE BASE DE DATOS

          Es un conjunto de programas que seencargan de manejar la creación ytodos los accesos a las bases dedatos.El objetivo principal del sistema gestorde base de datos es proporcionaruna forma de almacenar y recuperarla información de una base de datosde manera que sea tanto prácticacomo eficiente.

COMPONENTES DE UN SISTEMA MANEJADOR DE BASE DE DATOS

El lenguaje de definición de datos(DDL):

• Es utilizado para describir todas las estructurasde información y los programas que se usanpara construir, actualizar e introducir lainformación que contiene una base de datos.El DDL permite al administrador de la baseespecificar los elementos de datos que laintegran , su estructura y las relaciones queexisten entre ellos, las reglas de integridad, loscontroles a efectuar antes de autorizar elacceso a la base.

El lenguaje de manipulación de datos(DML)

• DML son las siglas de Data Manipulation Languagey se refiere a los comandos que permiten a unusuario manipular los datos en un repositorio, esdecir, añadir, consultar, borrar o actualizar.
• En SQL los comandos SELECT, INSERT, UPDATE yDELETE son comandos DML

El lenguaje Estructurado de consulta (SQL)

• Sublenguaje de base de datos utilizado en la consulta,actualización y gestión de base de datos relacionales. Esel estándar de facto para los productos de base dedatos.
• Una consulta es una instrucción de solicitud pararecuperar información. La parte de un DML se llamalenguaje de consultas.
• Ejemplo:
• Select nombre, dirección
• From cliente
• Where id cliente = 2

FUNCIONES PRINCIPALES

• Crear y organizar la Base de datos.
• Establecer y mantener las trayectorias deacceso a la base de datos de tal formaque los datos puedan ser accesadosrápidamente.
• Manejar los datos de acuerdo a laspeticiones de los usuarios.
• Registrar el uso de las bases de datos.

• Interacción con el manejador de archivos.Esto a través de las sentencias en DML alcomando del sistema de archivos. Así elManejador de base de datos es elresponsable del verdaderoalmacenamiento de los datos.
• Respaldo y recuperación. Consiste encontar con mecanismos implantados quepermitan la recuperación fácilmente de losdatos en caso de ocurrir fallas en elsistema de base de datos.

• Control de concurrencia. Consiste encontrolar la interacción entre los usuariosconcurrentes para no afectar lainconsistencia de los datos.
• Seguridad e integridad. Consiste en contarcon mecanismos que permitan elcontrol de la consistencia de los datosevitando que estos se vean perjudicadospor cambios no autorizados o previstos

SMDB DE CODIGO ABIERTO

• MySQL
• PostgreSQL
• Firebird
• SQLite
• Apache Derby

BASE DE DATOS DE CODIGO PROPIETARIO

• Dbase
• Microsoft SQL Server
• Oracle
• FileMaker
• Visual FoxPro
• Informix
• InterBase
• EDeveloper
• Microsoft Access

Estrategias de Diseños:

Orientada a Objetos

           Una base de datos orientada a objetos es un sistema de gestión de base de datos mediante el cual representamos la información en forma de objetos que son utilizados en programación orientada a objetos.

           La investigación y el desarrollo de la base de datos orientada a objetos fue impulsada en gran medida por su alto rendimiento en almacenamiento de datos y los requerimientos de acceso que tenían entornos de soporte de diseño tales como el CAD (Computer Aided Design) y el CASE (Computer Aided Software Engineering).

           A medida que ha ido aumentando el uso de la tecnología web, muchas organizaciones se muestran más interesadas en el concepto de base de datos orientada a objetos, dado que es útil para mostrar los datos complejos de estas tecnologías.

           Algunas bases de datos orientadas a objetos han sido diseñadas para trabajar bien con lenguajes de programación orientados a objetos tales como Delphi, Ruby, Python, Perl, Java, Visual Basic.NET, etc.

           A partir de 2004, la base de datos orientada a objetos ha vuelto a experimentar un crecimiento debido al surgimiento de bases de datos orientadas a objetos de código abierto. Son fáciles de usar y asequibles. Están totalmente escritas en lenguaje de programación orientado a objetos, como Smalltalk, Java o C.

Uso actual de la base de datos orientada a objetos

           La base de datos orientada a objetos ha encontrado su nicho de aplicación en áreas tales como la ingeniería, las bases de datos espaciales, las telecomunicaciones y en áreas científicas como la física de alta energía y la biología molecular.

           Otro conjunto de bases de datos orientadas a objetos se centra en el uso integrado en dispositivos, paquetes de software y sistemas en tiempo real.

Base de datos 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.

Esquema Conceptual:

Entidad - Relacion

          Es solo y exclusivamente un método del que disponemos para diseñar estos esquemas que posteriormente debemos de implementar en un gestor de BBDD (bases de datos). Este modelo se representa a través de diagramas y está formado por varios elementos.

          Este modelo habitualmente, además de disponer de un diagrama que ayuda a entender los datos y como se relacionan entre ellos, debe de ser completado con un pequeño resumen con la lista de los atributos y las relaciones de cada elemento.

Elementos del modelo entidad-relación

Entidad:

          Las entidades representan cosas u objetos (ya sean reales o abstractos), que se diferencian claramente entre sí.

          Para poder seguir un ejemplo durante el artículo añadiré ejemplos sobre un taller mecánico, donde se podría crear las siguientes entidades:

• Coches (objeto físico): contiene la información de cada taller.
• Empleado (objeto físico): información de los trabajadores.
• Cargo del empleado (cosa abstracta): información de la función del empleado.

Estas entidades se representan en un diagrama con un rectángulos, como los siguientes.

Atributos

          Los atributos definen o identifican las características de entidad (es el contenido de esta entidad). Cada entidad contiene distintos atributos, que dan información sobre esta entidad. Estos atributos pueden ser de distintos tipos (numéricos, texto, fecha...).

          Siguiendo el ejemplo de antes podemos analizar los atributos de nuestra entidad "Coches", que nos darán información sobre los coches de nuestro supuesto taller.

          Unos posibles atributos serían los siguientes: número de chasis, matrícula, DNI del propietario, marca, modelo y muchos otros que complementen la información de cada coche.

          Los atributos se representan como círculos que descienden de una entidad, y no es necesario representarlos todos, sino los más significativos, como a continuación.

          En un modelo relacional (ya implementado en una base de datos) un ejemplo de tabla dentro de una BBDD podría ser el siguiente.

          Este ejemplo es con tres atributos, pero un coche podría tener cientos (si fuese necesario) y seguirían la misma estructura de columnas, tras implementarlo en una BBDD.

Relación

          Es un vínculo que nos permite definir una dependencia entre varias entidades, es decir, nos permite exigir que varias entidades compartan ciertos atributos de forma indispensable.

          Por ejemplo, los empleados del taller (de la entidad "Empleados") tienen un cargo (según la entidad "Cargo del empleado"). Es decir, un atributo de la entidad "Empleados" especificará que cargo tiene en el taller, y tiene que ser idéntico al que ya existe en la entidad "Cargo del empleado".

           Las relaciones se muestran en los diagramas como rombos, que se unen a las entidades mediante líneas.

          Yo, bajo mi punto de vista, entiendo mejor esto en una tabla (de una implementación en una BBDD), por lo que voy a poner el ejemplo de como se representaría (resaltada la relación, que posteriormente veremos como se haría).

Empleados

Cargo del empleado

Relaciones de cardinalidad

          Podemos encontrar distintos tipos de relaciones según como participen en ellas las entidades. Es decir, en el caso anterior cada empleado puede tener un cargo, pero un mismo cargo lo pueden compartir varios empleados.

           Esto complementa a las representaciones de las relaciones, mediante un intervalo en cada extremo de la relación que especifica cuantos objetos o cosas (de cada entidad) pueden intervenir en esa relación.

Uno a uno: Una entidad se relaciona únicamente con otra y viceversa. Por ejemplo, si tuviésemos una entidad con distintos chasis y otra con matrículas deberíamos de determinar que cada chasis solo puede tener una matrícula (y cada matrícula un chasis, ni más en ningún caso).

Uno a varios o varios a uno:Determina que un registro de una entidad puede estar relacionado con varios de otra entidad, pero en esta entidad existir solo una vez. Como ha sido en el caso anterior del trabajador del taller.

Varios a varios: determina que una entidad puede relacionarse con otra con ninguno o varios registros y viceversa. Por ejemplo, en el taller un coche puede ser reparado por varios mecánicos distintos y esos mecánicos pueden reparar varios coches distintos.

          Los indicadores numéricos indican el primero el número mínimo de registros en una relación y posteriormente el máximo (si no hay límite se representa con una "n").

Entidad-Relacion Extendido:

          Se trata de una técnica cuyo objetivo es la representación y definición de todos los datos que se introducen, almacenan, transforman y producen dentro de un sistema de información, sin tener en cuenta las necesidades de la tecnología existente, ni otras restricciones.

           Dado que el modelo de datos es un medio para comunicar el significado de los datos, las relaciones entre ellos y las reglas de negocio de un sistema de información, una organización puede obtener numerosos beneficios de la aplicación de esta técnica, pues la definición de los datos y la manera en que éstos operan son compartidos por todos los usuarios.

Las ventajas de realizar un modelo de datos son, entre otras:

• Comprensión de los datos de una organización y del funcionamiento de la organización.
• Obtención de estructuras de datos independientes del entorno físico.
• Control de los posibles errores desde el principio, o al menos, darse cuenta de las deficiencias lo antes posible.
• Mejora del mantenimiento.
          Aunque la estructura de datos puede ser cambiante y dinámica, normalmente es mucho más estable que la estructura de procesos. Como resultado, una estructura de datos estable e integrada proporciona datos consistentes que puedan ser fácilmente accesibles según las necesidades de los usuarios, de manera que, aunque se produzcan cambios organizativos, los datos permanecerán estables.

           Este diagrama se centra en los datos, independientemente del procesamiento que los transforma y sin entrar en consideraciones de eficiencia. Por ello, es independiente del entorno físico y debe ser una fiel representación del sistema de información objeto del estudio, proporcionando a los usuarios toda la información que necesiten y en la forma en que la necesiten.

Descripción

           El modelo entidad/relación extendido describe con un alto nivel de abstracción la distribución de datos almacenados en un sistema. Existen dos elementos principales: las entidades y las relaciones. Las extensiones al modelo básico añaden además los atributos de las entidades y la jerarquía entre éstas. Estas extensiones tienen como finalidad aportar al modelo una mayor capacidad expresiva.

Los elementos fundamentales del modelo son los siguientes:

Entidad

           Es aquel objeto, real o abstracto, acerca del cual se desea almacenar información en la base de datos. La estructura genérica de un conjunto de entidades con las mismas características se denomina tipo de entidad.

           Existen dos clases de entidades: regulares, que tienen existencia por sí mismas, y débiles cuya existencia depende de otra entidad. Las entidades deben cumplir las siguientes tres reglas:


1. Tienen que tener existencia propia.
2. Cada ocurrencia de un tipo de entidad debe poder distinguirse de las demás.
3. Todas las ocurrencias de un tipo de entidad deben tener los mismos atributos.

Relación

           Es una asociación o correspondencia existente entre una o varias entidades. La relación puede ser regular, si asocia tipos de entidad regulares, o débil, si asocia un tipo de entidad débil con un tipo de entidad regular. Dentro de las relaciones débiles se distinguen la dependencia en existencia y la dependencia en identificación.

           Se dice que la dependencia es en existencia cuando las ocurrencias de un tipo de entidad débil no pueden existir sin la ocurrencia de la entidad regular de la que dependen. Se dice que la dependencia es en identificación cuando, además de lo anterior, las ocurrencias del tipo de entidad débil no se pueden identificar sólo mediante sus propios atributos, sino que se les tiene que añadir el identificador de la ocurrencia de la entidad regular de la cual dependen.

           Además, se dice que una relación es exclusiva cuando la existencia de una relación entre dos tipos de entidades implica la no existencia de las otras relaciones.

Una relación se caracteriza por:
• Nombre: que lo distingue unívocamente del resto de relaciones del modelo.
• Tipo de correspondencia: es el número máximo de ocurrencias de cada tipo de entidad que pueden intervenir en una ocurrencia de la relación que se está tratando. Conceptualmente se pueden identificar tres clases de relaciones:
  1. Relaciones 1:1: Cada ocurrencia de una entidad se relaciona con una y sólo una ocurrencia de la otra entidad.
  2. Relaciones 1:N: Cada ocurrencia de una entidad puede estar relacionada con cero, una o varias ocurrencias de la otra entidad.
  3. Relaciones M:N: Cada ocurrencia de una entidad puede estar relacionada con cero, una o varias ocurrencias de la otra entidad y cada ocurrencia de la otra entidad puede corresponder a cero, una o varias ocurrencias de la primera.
• Cardinalidad: representa la participación en la relación de cada una de las entidades afectadas, es decir, el número máximo y mínimo de ocurrencias de un tipo de entidad que pueden estar interrelacionadas con una ocurrencia de otro tipo de entidad. La cardinalidad máxima coincide con el tipo de correspondencia.

          Según la cardinalidad, una relación es obligatoria, cuando para toda ocurrencia de un tipo de entidad existe al menos una ocurrencia del tipo de entidad asociado, y es opcional cuando, para toda ocurrencia de un tipo de entidad, puede existir o no una o varias ocurrencias del tipo de entidad asociado.

Dominio

           Es un conjunto nominado de valores homogéneos. El dominio tiene existencia propia con independencia de cualquier entidad, relación o atributo.

Atributo

           Es una propiedad o característica de un tipo de entidad. Se trata de la unidad básica de información que sirve para identificar o describir la entidad. Un atributo se define sobre un dominio. Cada tipo de entidad ha de tener un conjunto mínimo de atributos que identifiquen unívocamente cada ocurrencia del tipo de entidad. Este atributo o atributos se denomina identificador principal. Se pueden definir restricciones sobre los atributos, según las cuales un atributo puede ser:


• Univaluado, atributo que sólo puede tomar un valor para todas y cada una de las ocurrencias del tipo de entidad al que pertenece.
• Obligatorio, atributo que tiene que tomar al menos un valor para todas y cada una de las ocurrencias del tipo de entidad al que pertenece.

          Además de estos elementos, existen extensiones del modelo entidad/relación que incorporan determinados conceptos o mecanismos de abstracción para facilitar la representación de ciertas estructuras del mundo real:


• La generalización, permite abstraer un tipo de entidad de nivel superior (supertipo) a partir de varios tipos de entidad (subtipos); en estos casos los atributos comunes y relaciones de los subtipos se asignan al supertipo. Se pueden generalizar por ejemplo los tipos profesor y estudiante obteniendo el supertipo persona.
• La especialización es la operación inversa a la generalización, en ella un supertipo se descompone en uno o varios subtipos, los cuales heredan todos los atributos y relaciones del supertipo, además de tener los suyos propios. Un ejemplo es el caso del tipo empleado, del que se pueden obtener los subtipos secretaria, técnico e ingeniero.
• Categorías. Se denomina categoría al subtipo que aparece como resultado de la unión de varios tipos de entidad. En este caso, hay varios supertipos y un sólo subtipo. Si por ejemplo se tienen los tipos persona y compañía y es necesario establecer una relación con vehículo, se puede crear propietario como un subtipo unión de los dos primeros.
• La agregación, consiste en construir un nuevo tipo de entidad como composición de otros y su tipo de relación y así poder manejarlo en un nivel de abstracción mayor. Por ejemplo, se tienen los tipos de entidad empresa y solicitante de empleo relacionados mediante el tipo de relación entrevista; pero es necesario que cada entrevista se corresponda con una determinada oferta de empleo. Como no se permite la relación entre tipos de relación, se puede crear un tipo de entidad compuesto por empresa, entrevista y solicitante de empleo y relacionarla con el tipo de entidad oferta de empleo. El proceso inverso se denomina desagregación.
• La asociación, consiste en relacionar dos tipos de entidades que normalmente son de dominios independientes, pero coyunturalmente se asocian.


La existencia de supertipos y subtipos, en uno o varios niveles, da lugar a una jerarquía, que permitirá representar una restricción del mundo real.

           Una vez construido el modelo entidad/relación, hay que analizar si se presentan redundancias. Para poder asegurar su existencia se deben estudiar con mucho detenimiento las cardinalidades mínimas de las entidades, así como la semántica de las relaciones.

           Los atributos redundantes, los que se derivan de otros elementos mediante algún calculo, deben ser eliminados del modelo entidad/relación o marcarse como redundantes.

           Igualmente, las relaciones redundantes deben eliminarse del modelo, comprobando que al eliminarlas sigue siendo posible el paso, tanto en un sentido como en el inverso, entre las dos entidades que unían.

Notación

Entidad

           La representación gráfica de un tipo de entidad regular es un rectángulo etiquetado con el nombre del tipo de entidad. Un tipo de entidad débil se representa con dos rectángulos concéntricos con su nombre en el interior.

Relación

           Se representa por un rombo unido a las entidades relacionadas por dos líneas rectas a los lados. El tipo de correspondencia se representa gráficamente con una etiqueta 1:1, 1:N o M:N, cerca de alguno de los vértices del rombo, o bien situando cada número o letra cerca de la entidad correspondiente, para mayor claridad.

          La representación gráfica de las cardinalidades se realiza mediante una etiqueta del tipo (0,1), (1,1), (0,n) o (1,n), que se coloca en el extremo de la entidad que corresponda. Si se representan las cardinalidades, la representación del tipo de correspondencia es redundante.

Atributo

           Un atributo se representa mediante una elipse, con su nombre dentro, conectada por una línea al tipo de entidad o relación.

           En lugar de una elipse puede utilizarse un círculo con el nombre dentro, o un círculo más pequeño con el nombre del atributo a un lado. También pueden representarse en una lista asociada a la entidad. El identificador aparece con el nombre marcado o subrayado, o bien con su círculo en negro.

Exclusividad

           En la representación de las relaciones exclusivas se incluye un arco sobre las líneas que conectan el tipo de entidad a los dos o más tipos de relación.

Jerarquía (tipos y subtipos)

          La representación de las jerarquías se realiza mediante un triángulo invertido, con la base paralela al rectángulo que representa el supertipo y conectando a éste y a los subtipos. Si la división en subtipos viene determinada en función de los valores de un atributo discriminante, éste se representará asociado al triángulo que representa la relación.

          En el triángulo se representará: con una letra d el hecho de que los subtipos sean disjuntos, con un círculo o una O si los subtipos pueden solaparse y con una U el caso de uniones por categorías. La presencia de una jerarquía total se representa con una doble línea entre el supertipo y el triángulo.


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.


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

Ejemplo DB Relacionada