Introducción a nuevas Tecnologías

 

 Bases de datos orientadas por objeto.

Es una base de datos donde los elementos son objetos. Estos pueden ser bases de datos multimedia (videos, imágenes y sonidos), donde la herencia permita una mejor representación de la información, estas bases de datos tienen una identidad de ser un todo. El objetivo de una base de datos orientada a objetos son los mismos que los de las bases de datos tradicionales, pero con la ventaja de representar las modelos de datos con un marco mucho más eficiente, manteniendo la integridad y relación entre ellos.

Primera y segunda generación de bdoo.  omg  y  corba.

La primera generación de Sistemas Gestores de Bases de Datos Orientadas a Objetos (SGBDOO) data de 1986 cuando la compañia Graphael lanza G-Base, en 1987 Servio Corp introdujo GemStone, luego en 1988 Ontologic lanza su sistema VBase y la empresa Simbolics lanza Statice. Todos ellos con la finalidad de apoyar lenguajes persistentes como los usados para la inteligencia artificial.

La segunda generación se caracterizó por emplear una arquitectura cliente-servidor, y puede considerarse a partir del lanzamiento de Ontos en 1989, así como de Objet Design, Objectivity y de Versant Objet Technology,

Experiencias,  promesas,  realidad  Y  futuro

Las bases de datos orientadas a objetos fueron creadas para tener una interfaz limpia con un lenguaje de programación orientado a objetos, donde la aplicación requiere la flexibilidad  de una base de datos relacional que no tiene un rendimiento adecuado. Las BDOO pueden ser 100 veces más rápidas para ciertos tipos de aplicaciones. La vía orientada a objetos requiere una larga fase inicial de análisis, la mayoría de los proyectos de desarrollo de software son más cortos y requieren menos personas. La cantidad de código es significativamente menor.

             Los sistemas de bases de datos relacionales ofrecen lenguajes de acceso no basados en procedimientos, es decir declarativos (por ejemplo: select * from clientes; indica específicamente qué, de dónde y cómo se obtienen los datos ). En cambio los sistemas orientados a objetos son principalmente basados en procedimientos y no declarativos, lo que requieren menos optimizaciones pero más eficiente para consultas de objetos complejos.

 Estándares

• Carencia de un modelo de datos universal.
• No hay ningún modelo de datos que esté universalmente aceptado para los SGBDOO y la mayoría de los modelos carecen una base teórica.
• Carencia de experiencia. Todavía no se dispone del nivel de experiencia del que se dispone para los sistemas tradicionales.
•  Carencia de estándares. No Existe una carencia de estándares general para los SGBDOO.

Bases de  datos deductivas.

Es un sistema de bases de datos que define reglas con las cuales se puede inferir información adicional a partir de los hechos almacenados en las bases de datos. Es decir, es un programa lógico que realiza un mapeo de relaciones base hacia hechos, y reglas que son usadas para definir nuevas relaciones en términos de las relaciones base y el procesamiento de consultas. Consta de las siguientes características:

• Capacidad de expresar consultas por medio de reglas lógicas.
• Permitir consultas recursivas y algoritmos eficientes para su evaluación.
•   Contar con negaciones estratificadas.
• Soportar objetos y conjuntos complejos.
• Contar con métodos de optimización que garanticen la traducción de especificaciones dentro de planes eficientes de acceso.
• Su lenguaje de definición de datos (DDL) es dataLog.
• En lugar de relaciones entre entidades, aparecen los predicados; y en lugar de las tulpas aparecen los hechos.
• Modelado semántico y uniformidad en la representación.

 Necesidad  de la inferencia  en  aplicaciones.

Inferencia es una deducción o conclusión a la que se llega a partir de algo que se sabe que es cierto o falso. Los mecanismos de inferencia se aplican sobre los hechos y las reglas en una base de datos deductiva en particular, para lograr obtener más información a partir de los datos explícitos de la base. En datalog no existen instrucciones de control, Su ejecución se basa en dos conceptos: la unificación y el backtracking.

   En la unificación cada objetivo determina un subconjunto de cláusulas susceptibles de ser ejecutadas. Cada una de ellas se denomina punto de elección. Datalog selecciona el primer punto de elección y sigue ejecutando el programa hasta determinar si el objetivo es verdadero o falso. En caso de ser falso entra en juego el backtracking, que consiste en deshacer todo lo ejecutado situando el programa en el mismo estado en el que estaba justo antes de llegar al punto de elección. Entonces se toma el siguiente punto de elección que estaba pendiente y se repite todo el proceso.

Funciones de los Mecanismos de Inferencia

• Determinación de las acciones que tendrán lugar, el orden en que lo harán y como lo harán entre las diferentes partes del sistema experto. 
• Determinar cómo y cuándo se procesaran las reglas, y dado el caso también la elección de que reglas deberán procesarse.
• Control de dialogo con el usuario. La decisión sobre los mecanismos de procesamiento de reglas, es decir, qué estrategias de búsqueda se implementarán, es de vital importancia para la efectividad del sistema en su conjunto.

        La inferencia en las aplicaciones nacen con el afán de ofrecer una respuesta a las necesidades planteadas por los usuarios y por las aplicaciones avanzadas, en donde se necesitan herramientas semánticamente más ricas que las provistas por las bases de datos relacionales, aparecen recientes aplicaciones de los sistemas de bases de datos que consiste en ofrecer recursos para definir reglas deductivas y activas que permitan deducir, inferir u obtener información nueva a partir de los datos almacenados o sucesos condicionados. La finalidad de estas aplicaciones es incorporar a las bases de datos relacionales los beneficios de la inferencia lógica como instrumento para la formalización integrada de los aspectos estáticos y dinámicos del modelado relacional de la base de dato en las aplicaciones.

 El  lenguaje datalog  puro. 

Es el lenguaje utilizado para la manipulación de las bases de datos deductivas y es sintácticamente un subconjunto del lenguaje Prolog. Hay dos tipos de Datalog: con recursión y sin recursión. Datalog sin recursión tiene el mismo poder expresivo que el álgebra relacional, mientras que  datalog con recursión permite expresar consultas que no se pueden satisfacer en SQL2.

     Datalog es similar a prolog en su sintaxis, pero en su semántica operacional es diferente. La interpretación de una colección de predicados asigna cierto o falso a cada posible instancia de los predicados, donde los argumentos se escogen de un conjunto infinito de constantes. La interpretación se representa habitualmente por el conjunto de instancias verdaderas. Evalúa las consultas mediante la evaluación de cada regla y cada regla es evaluada examinando todos los hechos, ya sean hechos almacenados o hechos derivados, que unifican cada predicado en el cuerpo de una regla. Si alguna colección de hechos unifica con cada predicado en el cuerpo de una regla, se produce un nuevo hecho que corresponderá al encabezado de la regla.

Reglas en datalog

Un átomo es de la forma: p(t₁,...,t_n) Donde p es un símbolo de predicado y cada ti es una variable o una constante. Un literal es bien un átomo o un átomo negado.  Una regla o cláusula en tiene la forma: 

               cabeza ← cuerpo.

Donde cabeza es un átomo y cuerpo es una lista de literales que puede ser vacía; en este caso se habla de un hecho. Los hechos se escriben:

cabeza.

que equivale a escribir:

cabeza ← true.

El significado de una regla

                      P ← Q1, ..., Qn.

es: "Si Q1, Q2, ... y Qn son ciertos, entonces P es cierto". 

El modelo de datos de Datalog

• No admite símbolos de función en los argumentos.
• El significado de los programas sigue el punto de vista de teoría de modelos.
• Una relación se representa por un predicado.

Ventajas de datalog

• Almacenamiento de pocos datos.
• Ofrecen reglas que permiten crear combinaciones de datos.
• Soportan objetos y conjuntos complejos.
• Ofrecen la capacidad de expresar consultas por medio de reglas lógicas.
•  Permiten consultas recursivas y algoritmos eficientes para su evaluación.
•   Cuentan con métodos de optimización que garantizan la traducción de especificaciones dentro de planes eficientes de acceso.
•  Cuentan con negaciones estratificadas.

Inconvenientes de datalog

• Poder encontrar criterios de interpretación para las reglas deductivas. Es complicado poder encontrar buenos criterios de evaluación para las reglas lógicas por lo que es muy difícil sacar todo su potencial.
• Replantear correctamente, en un contexto deductivo, las convenciones habituales en una base de datos.
• Desarrollar procedimientos eficaces de deducción.

Facilidades  de  la  negación  estratificada. Del modelaje conceptual al diseño de una base de datos deductiva.

Contar con negación estratificada permite la capacidad de modelado natural de objetos del mundo real, encapsulando su estructura y comportamiento, que proporcionan los modelos orientados a objetos; la capacidad de derivación de nuevos conocimiento a partir de datos existentes, suministrando vínculos del mundo real en forma de reglas, que proporcionan los modelos de datos deductivos; y además, la capacidad de almacenamiento persistente que proporcionan los sistemas administradores de bases de datos

 

BASES DE DATOS ACTIVAS COMO PROVEEDORAS DE MECANISMOS DE APOYO A: REGLAS  DE  INTEGRIDAD, MANTENIMIENTO  DE  DATOS  DERIVADOS,  "TRIGGERS", ALERTAS,  CONTROL  DE  VERSIONES,  ENTRE OTROS.

 

 

Base de datos activa

            Son aquellas bases de datos capaces de detectar situaciones de interés y de actuar en consecuencia. El mecanismo que se utiliza se parece a las reglas de producción utilizadas en el área de inteligencia artificial.   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. Mediante estas reglas se puede hacer respetar reglas de integridad, generar datos derivados, controlar la seguridad o implementar reglas de negocio.

            El concepto de Bases de Datos Activas (SGBDA) se define en la capacidad del motor de manejar eventos al momento en que los datos sufren cambios como modificación, eliminación o actualización, es decir, cuando se producen ciertas condiciones ejecuta de forma automática ciertas acciones, además el motor de base de datos debe ser capaz de monitorizar y reaccionar ante eventos de manera oportuna y eficiente.

Estas características de reaccionar ante condiciones son definidas en el esquema de base de datos, de manera que, se elimina la responsabilidad de la aplicación que hace uso de la misma a gestionar tales eventos; la manera más común de definirlos en el esquema es a través de triggers, característica que maneja la gran mayoría de los motores de BD más conocidos en el mercado. La característica que se viene utilizando para especificar bases de datos activas es el modelo evento–condición–acción

Ejemplo.

 Tras la modificación de la tabla persona, se chequea su fecha de nacimiento y se procede a actualizar el campo edad, de todos los registros.

Sistema Gestor de Bases de Datos Activo (SGBDA)

 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 las siguientes  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.

Características de las bases de datos activas.

• Un SGBDA no deja de ser un SGBD (Sistema de Gestión de Base de Datos). 
• Un SGBDA tiene un modelo de reglas ECA (Evento-Condición-Acción). 
• Un SGBDA debe soportar la gestión de reglas y la evolución de la base de reglas, esto significa, que el SGBD debe soportar la definición mediante reglas.

Características de ejecución de reglas ECA

• Un SGBDA tiene un modelo de ejecución. 
•  Un SGBDA debe ofrecer diferentes modelos de acoplamiento. 
•  Un SGBDA debe implementar modos de consumo. 
•  Un SGBDA debe gestionar la historia de eventos. 
•  Un SGBDA debe implementar resolución de conflictos.

Características de aplicación y usabilidad.

• Un SGBDA debería poseer un entorno de programación. 
•  Un SGBD A debería ser ajustable.

 Ventajas

• Mayor productividad. 
•  Mejor mantenimiento. 
•  Reutilización de código. 
• Reducción del tráfico de mensajes. 
• Posibilidad de optimización semántica. 
•  Facilitar el acceso a la BD a usuarios finales.

Desventajas.

            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. 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 monitorear reglas activas que puedan ayudar a los usuarios en el diseño y depuración de sus reglas.

Aplicación de las bases de datos activas.

Las aplicaciones clásicas de las reglas activas son internas a la base de datos: el gestor de reglas activas trabaja como un subsistema del SGBD implementando algunas de sus funciones. En este caso, los disparadores son generados por el implementando algunas de sus funciones. En este caso, los disparadores son generados por el sistema y no son visibles por parte de los usuarios. La característica típica de las aplicaciones internas es la posibilidad de dar una especificación declarativa de las funciones, a partir de la que derivar las reglas activas.

 

Trigger 

    Un disparador define una acción que la base de datos debe llevar a cabo cuando se produce algún suceso relacionado con la misma. Los disparadores (triggers) pueden utilizarse para completar la integridad referencial, también para imponer reglas de negocio complejas o para auditar cambios en los datos. El código contenido en un disparador, denominado cuerpo del disparador, está formado por bloques PL/SQL. La ejecución de disparadores es transparente al usuario.

 

    Existen varios tipos de disparadores, dependiendo del tipo de transacción de disparo y el nivel en el que se ejecuta el disparador (trigger):

 1.-Disparadores de nivel de fila: se ejecutan una vez para cada fila afectada por una instrucción DML. Los disparadores de nivel de fila se crean utilizando la cláusula for each row en el comando create trigger.

 2.-Disparadores de nivel de instrucción: se ejecutan una vez para cada intrucción DML. Por ejemplo, si una única intrucción INSERT inserta 500 filas en una tabla un disparador de nivel de instrucción para dicha tabla sólo se ejecutará una vez. Los disparadores de nivel de instrucción son el tipo predeterminado que se crea con el comando create trigger.

 3.-Disparadores Before y After: puesto que los disparadores son ejecutados por sucesos, puede establecerse que se produzcan inmediatamente antes (before) o después (after) de dichos sucesos.

 4.-Disparadores Instead Of: puede utilizar INSTEAD OF para indicar a Oracle lo que tiene que hacer en lugar de realizar las acciones que invoca el disparador. Por ejemplo, podría usar un disparador

INSTEAD OF en una vista para gestionar las inserciones en una tabla o para actualizar múltiples tablas que son parte de una vista.

 5.-Disparadores de esquema: puede crear disparadores sobre operaciones en el nivel de esquema tales como create table, alter table, drop table, audit, rename, truncate y revoke. Puede incluso crear disparadores para impedir que los usuarios eliminen sus propias tablas. En su mayor parte, los disparadores de nivel de esquema proporcionan dos capacidades: impedir operaciones DDL y proporcionar una seguridad adicional que controle las operaciones DDL cuando éstar se producen.

 6.-Disparadores en nivel de base de datos: puede crear disparadores que se activen al producirse sucesos de la base de datos, incluyendo errores, inicios de sesión, conexiones y desconexiones. Puede utilizar este tipo de disparador para automatizar el mantenimiento de la base de datos o las acciones de auditoría.

Sintaxis

 

Para eliminar

 

Activar/ Desactivar dispadores

Existen dos opciones.

·         ALTER TRIGGERnombre_disparador{DISABLE|ENABLE};

·         ALTER TABLEnombre_tabla{ENABLE|DISABLE}ALL TRIGGERS;

La ejecución del disparador puede serantes(before) odespués(after) de llevar a cabo la sentencia disparadora. Es posible especificar condiciones adicionales para la ejecución del disparador (restrictores).

Dado que una sentencia disparadora puede afectar una o más filas de una tabla, es necesario especificar si se quiere que el disparador se ejecute para cada una de las filas afectadas o para el bloque en general.

Para diseñar un disparador hay que cumplir dos requisitos:

·         Especificar las condiciones en las que se va a ejecutar el disparador. Esto se descompone en un evento que causa la comprobación del disparador y una condición que se debe cumplir para ejecutar el disparador.

·         Especificar las acciones que se van a realizar cuando se ejecute el disparador.

Registros old y new.

Estas variables se utilizan del mismo modo que cualquier otra variable, con la salvedad de que no es necesario declarar las,son de tipo %ROWTYPE y contienen una copia del registro antes (OLD) y después (NEW) de la acción SQL (INSERT,UPDATE,DELETE)que ha ejecutado el trigger. Utilizando esta variable podemos acceder a los datos que se están insertando, actualizando o borrando

De uso exclusivo en los disparadores de nivel de fila, si se intenta hacer referencia a cualquiera de los dos dentro de otro tipo de disparador, se obtendrá un error de compilación.

La siguiente tabla resume los valores regresados por estos seudoregistros en diferentes eventos

Ejemplo 1:

Ahora cree el siguiente disparador

 

Inserte los siguientes datos

Revise la tabla amigoscopia, el disparador realizó un insert al momento de insertar datos en la tabla amigos

Manejo de excepciones

Para hacer que un trigger ejecute un ROLLBACK de la transacción que tiene activa y teniendo en cuenta que en las sentencias que componen el cuerpo de un trigger no puede haber este tipo de sentencias (rollback, commit,...) hay que ejecutar 'error / excepcion' mediante la sentenciaraise_application_errorcuya sintaxis es:

Dondenum_erroren el rango: [-20000 y -20999]

Ejemplo: Retomando el ejemplo anterior, desarrollamos una excepción en nuestra tabla amigos.

En la cual no admitimos como amiga a 'Isabel Mebarak Ripoll'

Ejemplo 2:

Ingresamos los siguientes registros en la tabla libros

insert into libros values(100,'Uno','Richard Bach','Planeta',25);

insert into librosvalues(103,'El aleph','Borges','Emece',28);

insert into libros values(105,'Matematica estas ahi','Paenza','Nuevo siglo',12);

insert into libros values(120,'Aprenda PHP','Molina Mario','Nuevo siglo',55);

insert into libros values(145,'Alicia en el pais de las maravillas','Carroll','Planeta',35);

Creamos un trigger a nivel de fila que se dispara "antes" que se ejecute un "update" sobre el campo "precio" de la tabla "libros". En el cuerpo del disparador se debe ingresar en la tabla "control", el nombre del usuario que realizó la actualización, la fecha, el código del libro que ha sido modificado, el precio anterior y el nuevo:

Cuando el trigger se dispare, antes de ingresar los valores a la tabla, almacenará en "control", además del nombre del usuario y la fecha, el precio anterior del libro y el nuevo valor.

Actualizamos el precio del libro con código 100:

update libros set precio=30 where codigo=100;

Veamos lo que se almacenó en "control" al dispararse el trigger:

select *from control;

Los campos "precioanterior" y "precionuevo" de la tabla "control" almacenaron los valores de ":old.precio" y ":new.precio" respectivamente.

Actualizamos varios registros:

update libros set precio=precio+precio*0.1 where editorial='Planeta';

Veamos lo que se almacenó en "control" al dispararse el trigger:

select *from control;

Los campos "precioanterior" y "precionuevo" de la tabla "control" almacenaron los valores de ":old.precio" y ":new.precio" respectivamente de cada registro afectado por la actualización.

Modificamos la editorial de un libro:

update libros set editorial='Sudamericana' where editorial='Planeta';

El trigger no se disparó, pues fue definido para actualizaciones del campo "precio" unicamente.

Ejemplo 3:

Vamos a reemplazar el trigger anteriormente creado. Ahora el disparador "tr_actualizar_precio_libros" debe controlar el precio que se está actualizando, si supera los 50dolares, se debe redondear tal valor a entero hacia abajo (empleando "floor"), es decir, se modifica el valor ingresado accediendo a ":new.precio" asignándole otro valor:

Vaciamos la tabla "control":

truncate table control;

Actualizamos el precio del libro con código 100:

update libros set precio=54.99 where codigo=100;

Veamos cómo se actualizó

select *from libros where codigo=100;

El nuevo precio actualizado se redondeó a 54.

Veamos lo que se almacenó en "control" al dispararse el trigger:

select *from control;