• EXTENSIONES DE TIPOS BÁSICOS• OBJETOS COMPLEJOS• HERENCIA• SISTEMA DE REGLAS

CARACTERíSTICAS PRINCIPALES de SGBD OR

El estudio se hará primero con herencia de datos y luego con herencia de funciones.

La tercera caracterísica de un OR es la capacidad de soportar herencia, pudiendo crearse supertipos y subtipos.

Es aplicable solo a tipos composite. Suponga que construye el tipo de datos persona_t , con una columna simple, llamada name :

Create row type Persona_tPersona_t (

nombre varchar (30)

) ;

Lo usaremos como supertipo en los ejemplos siguientes :

Ud puede ahora construir dos tipos adicionales :

Empleado_t y Estudiante_t

under Persona_t;

Create row typerow type Estudiante_t(

num_creditos float)under Persona_t;

HERENCIA

HERENCIA

Create row typerow type Empleado_t

( salario int; fech_ing date; direccion varchar(30) ; ciudad varchar(30);

)

create row typerow type Estudiante_emple_tEstudiante_emple_t( descuent float)under Empleado_t , Estudiante_t ;

Estudiante_emple_tEstudiante_emple_t , tiene acceso a los datos :

nombrenombre heredado de Persona_tPersona_tsalario, fech_ing, direccion, ciudadsalario, fech_ing, direccion, ciudad heredado de Empleado_tEmpleado_tnum_creditosnum_creditos heredado de Estudiante_tEstudiante_tdescuentdescuent especificado por el tipo Estudiante_emple_tEstudiante_emple_t

Ya que los tipos no esta preparados para el almacenamiento, debemos crear tablas :

Create table personapersona of type Persona_tPersona_t

under persona

Create table emple of type Empleado_t

under persona

Create table estudiante of type Estudiante_t

Create table estudiante_emple of type Estudiante_emple_tunderunder estudiante , emple

Create table personapersona of type Persona_tPersona_t

Create table emple of type Empleado_t

under persona

Create table estudiante of type Estudiante_tunder persona

Create table estudiante_emple of type Estudiante_emple_t

underunder estudiante , emple

Esta es una jerarquia de

tablas

persona

estudiante_emple

estudianteemple

Select nombre

From emple

where salario = 3000

Esta sentencia examina la tabla emple para aquellos empleados que ganen 3000, pero adicionalmente examina todas las tablas heredadas por emple en la jerarquia.

De este modo el ambito de “from emple” es tomado por un SGBD OR como la tabla emple y todas las tablas heredadas en la jerarquía de herencia.

select nombre

from onlyonly (emple)

where salario = 3000

Si Ud. desea que solo se examine la tabla emple.

El comportamiento heredado de una función definida por el usuario esta determinado por sus argumentos.Veamos el caso de la función sobrepago( )

Create function sobrepago (Empleado_t obj)returns booleanas select obj.salario > ( select salario from emple where nombre = ´Joe¨);

Instancia de Empleado_t

sobrepago

Ahora considerar la siguiente consulta :

Select e.nombrefrom only (emple) ewhere sobrepago (e);

TABLASTABLAS

Aquí se evalúa solo la tabla emple al usar la función sobrepago

Select s.nombrefrom estudiante_emple swhere sobrepago (s);

Suponga una consulta sobre Estudiante_emple_tEstudiante_emple_t donde no existe la función sobrepago( ) , un buen sistema OR automáticamente heredará la función del supertipo.

sobrepago

sobrepago

sobrepago

Select e.nombrefrom only (emple) ewhere sobrepago (e);

Select s.nombrefrom only (estudiante_emple) swhere sobrepago (s);

Esto es quivalente a :

sobrepago sobrepago

Select s.nombrefrom estudiante_emple swhere sobrepago (s);

• EXTENSIONES DE TIPOS BÁSICOS• OBJETOS COMPLEJOS• HERENCIA• SISTEMA DE REGLAS

CARACTERíSTICAS PRINCIPALES de SGBD OR

La última carácterística de un buen SGBD OR es poseer un potente sistema de reglas de propósito general.

Las reglas son excepcionalmente valiosas en la mayoría de aplicaciones de SGBD debido a que ellas protegen la integridad de la data, haciendo mas simple el mantenimiento.

SISTEMA DE REGLAS

Aunque los SGBD relacionales brindan algún soporte para reglas a traves del uso de triggers, los SGBD OR desarrrollan un sistema mucho mas flexible.

El paradigma para un sistema de reglas en SGBD es un sistema de producción, popularizado en los años 80 por la comunidad de la Inteligencia artificial.

SISTEMA DE REGLAS

la sintaxis general de una regla es :

ON <EVENTO>WHERE <CONDICION>

DO <ACCION>

La semantica de las reglas requiere del SGBD estar atento por la ocurrencia de algún eventoevento, y ocurrido este, verificar si la condicióncondición establecida es verdadera, y entonces ejecutar la acciónacción indicada.

SISTEMA DE REGLAS

El sistema de reglas, debe incluir la capacidad de ejecutar la acción especificada antes o despues de ocurrido el evento ( por defecto, despues)

SISTEMA DE REGLAS

LAS 4 REGLAS BASICAS

. Reglas ACTUALIZACION - ACTUALIZACION

. Reglas CONSULTA- ACTUALIZACION

. Reglas ACTUALIZACION - CONSULTA

. Reglas CONSULTA - CONSULTA

En este caso el evento es una actualización y la acción otra actualización.

ON <EVENTO>WHERE <CONDICION>

DO <ACCION>

Por ejemplo, considerar la siguiente regla : Si se actualiza el sueldo de Miguel, entonces propagar el cambio sobre Jenny.

Create rule Miguel_Jenny_sueldoon update to emp.sueldo

where current.nombre = ‘Miguel’do update emp

set new.sueldowhere nombre = ‘Jenny’;

Sueldo establecido para Miguel

A Miguel se le acaba de cambiar el sueldo

new es comando

Veamos como funciona : si se actualiza el sueldo de Miguel a 5200 :

Update empset sueldo = 5200where nombre = ‘Miguel’;

Entonces cuando el sueldo de Miguel sea actualizado, el de Jenny tambien lo será, con el mismo valor (5200), de acuerdo a la regla anterior.

Una variante, usando el comando current, para propagar actualización sobre otro empleado (Elena), pero con efecto distinto a Jenny :

Create rule Miguel_Elena_sueldoon update to emp.sueldo

where current.nombre = ‘Miguel’do update emp

set sueldo = current.sueldowhere nombre = ‘Elena’;

Si se re-actualiza el sueldo de Miguel a 5600 :

Update empset sueldo = 5600where nombre = ‘Miguel’;

El sueldo de Elena será fijado a 5200 y el Jenny a 5600.

Porqué ?

En este caso el evento es una consulta y la acción es una actualización.

ON <EVENTO>WHERE <CONDICION>

DO <ACCION>

Create rule auditar_sueldoon select to emp.sueldo

where current.nombre = ´Miguel´do insert into auditar values (user, current.sueldo, datetime);

En esta regla cuando se consulta el sueldo de Miguel, se inserta una fila en la tabla auditar, indicando quien hizo la consulta (user), el valor consultado (sueldo) y la fecha y hora cuando de efectuó la consulta. Así la tabla auditar sirve para tener un registro detallado de accesos al sueldo de Miguel.

consulta

actualización

En este caso el evento es una actualización y la acción es una consulta de respuesta. Estas reglas también son conocidas como alertas

ON <EVENTO>WHERE <CONDICION>

DO <ACCION>

Create alert alerta_sobre_Miguel_sueldo(mechanism = ´callback´);

Create rule alerta_ cambio_ Miguel_sueldo on update to emp

where current.nombre=´Miguel´do raise alert alerta_sobre_Miguel_sueldo;

Esta regla vigila alguna actualización del sueldo de Miguel y toma acción notificando con la alerta alerta_sobre_Miguel_sueldo alerta_sobre_Miguel_sueldo . Aquí el mecanismo de notificación es callback.

Tambien es posible que la notificación sea mas restrictiva, asi si un cliente tiene interes en una alerta, puede usar el comando :

listen alerta_sobre_Miguel_sueldo;

En este caso el evento es una consulta y la acción es tambien una consulta.

ON <EVENTO>WHERE <CONDICION>

DO <ACCION>

Create rule Jenny_Miguel_sueldoonon select to emp.sueldo

wherewhere current.nombre = ´Jenny´dodo instead

select sueldofrom empwhere nombre = ´Miguel´;

Esta regla vigila el evento consulta del sueldo de Jenny y cuando esto ocurre, se muestra el sueldo de Miguel en lugar del sueldo de Jenny (INSTEADINSTEAD)

• IBM• INFORMIX•ORACLE

Todos estos sistemas se autodenominan

Bases de Datos Universales, pero presentan diferencias, especialmente en su capacidad de ajustarse lo mas que se pueda al modelo OR, situación que también se presentó cuando aparecieron los primeros SGBD relacionales.

• Fórmula del Fracaso : tecnología inmadura + esperanzas poco realistas

• Evaluación de la evolución de la tecnología de los SGBD OR (productos, herramientas, aplicativos) y de los precios de venta

• Costo real de una migración: hardware, software y recursos humanos.

• Capacidad de migración o de integración con los sistemas actuales o heredados