EXTENSIONES DE TIPOS BSICOS

OBJETOS COMPLEJOS
HERENCIA
SISTEMA DE REGLAS

CARACTERSTICAS
PRINCIPALES de SGBD OR
El estudio se har primero con herencia de datos
y luego con herencia de funciones.
La tercera caractersica 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_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 type Estudiante_t
(
num_creditos float
)

under Persona_t;
HERENCIA
HERENCIA
Create row type Empleado_t
( salario int;
fech_ing date;
direccion varchar(30) ;
ciudad varchar(30);
)
create row type Estudiante_emple_t
(
descuent float
)

under Empleado_t , Estudiante_t ;
Estudiante_emple_t , tiene acceso a los datos :
nombre heredado de Persona_t
salario, fech_ing, direccion, ciudad heredado de Empleado_t
num_creditos heredado de Estudiante_t
descuent especificado por el tipo Estudiante_emple_t
Ya que los tipos no esta preparados para el
almacenamiento, debemos crear tablas :
Create table persona
of type Persona_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_t
under estudiante , emple
Create table persona of type Persona_t
Create table emple of type Empleado_t
under persona
Create table estudiante of type Estudiante_t
under persona
Create table estudiante_emple of type Estudiante_emple_t
under estudiante , emple
Esta es una
jerarquia de
tablas
persona
estudiante_emple
estudiante emple
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 jerarqua de herencia.
select nombre
from only (emple)
where salario = 3000
Si Ud. desea que solo se examine la tabla emple.
El comportamiento heredado de una funcin definida
por el usuario esta determinado por sus argumentos.
Veamos el caso de la funcin sobrepago( )
Create function sobrepago (Empleado_t obj)
returns boolean
as
select obj.salario >
( select salario
from emple
where nombre = Joe);
Instancia de
Empleado_t
sobrepago
Ahora considerar la siguiente consulta :
Select e.nombre
from only (emple) e
where sobrepago (e);
TABLAS
Aqu se evala solo la tabla emple
al usar la funcin sobrepago
Select s.nombre
from estudiante_emple s
where sobrepago (s);
Suponga una consulta sobre Estudiante_emple_t donde
no existe la funcin sobrepago( ) , un buen sistema OR
automticamente heredar la funcin del supertipo.
sobrepago
sobrepago
sobrepago
Select e.nombre
from only (emple) e
where sobrepago (e);
Select s.nombre
from only (estudiante_emple) s
where sobrepago (s);
Esto es quivalente a :
sobrepago
sobrepago
Select s.nombre
from estudiante_emple s
where sobrepago (s);
EXTENSIONES DE TIPOS BSICOS
OBJETOS COMPLEJOS
HERENCIA
SISTEMA DE REGLAS

CARACTERSTICAS
PRINCIPALES de SGBD OR
La ltima carcterstica de un buen SGBD OR es
poseer un potente sistema de reglas de
propsito general.
Las reglas son excepcionalmente valiosas en la
mayora 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 algn
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 produccin,
popularizado en los aos 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 algn evento,
y ocurrido este, verificar si la condicin
establecida es verdadera, y entonces ejecutar
la accin indicada.
SISTEMA DE REGLAS
El sistema de reglas, debe incluir la capacidad
de ejecutar la accin 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 actualizacin y
la accin otra actualizacin.
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_sueldo
on update to emp.sueldo
where current.nombre = Miguel
do update emp
set new.sueldo
where 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 emp
set sueldo = 5200
where 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 actualizacin sobre otro
empleado (Elena), pero con efecto distinto
a Jenny :
Create rule Miguel_Elena_sueldo
on update to emp.sueldo
where current.nombre = Miguel
do update emp
set sueldo = current.sueldo
where nombre = Elena;
Si se re-actualiza el sueldo de Miguel a 5600 :
Update emp
set sueldo = 5600
where 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
accin es una actualizacin.
ON <EVENTO>
WHERE <CONDICION>
DO <ACCION>
Create rule auditar_sueldo
on 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
actualizacin
En este caso el evento es una actualizacin y
la accin es una consulta de respuesta.
Estas reglas tambin 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 actualizacin del sueldo
de Miguel y toma accin notificando con la
alerta alerta_sobre_Miguel_sueldo . Aqu el
mecanismo de notificacin es callback.
Tambien es posible que la notificacin 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
accin es tambien una consulta.
ON <EVENTO>
WHERE <CONDICION>
DO <ACCION>
Create rule Jenny_Miguel_sueldo
on select to emp.sueldo
where current.nombre = Jenny
do instead
select sueldo
from emp
where 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 (INSTEAD)
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, situacin que tambin se present
cuando aparecieron los primeros SGBD
relacionales.
Frmula del Fracaso : tecnologa inmadura +
esperanzas poco realistas
Evaluacin de la evolucin de la tecnologa
de los SGBD OR (productos, herramientas,
aplicativos) y de los precios de venta
Costo real de una migracin: hardware,
software y recursos humanos.
Capacidad de migracin o de integracin con
los sistemas actuales o heredados