valorización de las bases de datos deductivas y de las
TRANSCRIPT
1
Universidad Central “Martha Abreu” de Las Villas
Facultad de Matemática, Física y Computación
Valorización de las Bases de Datos
Deductivas y de las Bases de Datos Activas
Tesis presentada en opción al Título Académico de Master en Computación Aplicada
Autor: Ing. Silvia Eloisa Carlín Salgado
Tutores: Dr. Rosendo Moreno Rodríguez
Guadalajara, Jalisco, México 2003
1
Resumen.
Una de las características más comunes de la siguiente generación de los sistemas de bases de
datos es que necesitarán un modelo de datos más poderoso que el modelo relacional sin
comprometer sus ventajas (independencia de los datos y alto nivel de los lenguajes de consulta).
Para enfrentar las carencias del modelo relacional, dos tecnologías basadas en la deducción y
en la no pasividad, están siendo investigadas.
En este trabajo se realiza una investigación, la cual introduce a manera de información básica, el
concepto de la Base de Datos Relacional y los conceptos básicos de los Sistemas de Gestión de
Bases de Datos, para poder plantear la evolución de las Bases de Datos y sus nuevas
perspectivas de aplicación. En particular se plantean las características de las Bases de Datos
Deductivas y de las Bases de Datos Activas, permitiendo la valorización de algunos de los
prototipos más importantes de los Sistemas de Gestión de Bases de Datos Deductivos y Activos
más utilizados en la actualidad.
2
Abstract
One of the most common characteristics of the following generation of the systems of data bases
is that they will need a data modeling more powerful than the relational model without
jeopardizing his advantages (data independence and stop level of the query languages). In order
to face the deficiencies of the relational model, two technologies based on the deduction and the
nonpassivity, they are being investigated.
In this work an investigation is made in which it introduces to basic way of information, the
concept of Relational DataBases and the basic concepts of the Systems of Management of
Databases, to be able to raise the evolution of Databases and their new perspective of
application. In individual the characteristics of Deductive Databases and Active Databases
consider, allowing the valuation of some of the most important prototypes of the Systems of
Management of used Deductive and Active Databases more at the present time.
3
CONTENIDO:
INTRODUCCIÓN. ....................................................................................................................................... 1
CAPÍTULO 1. BREVE HISTORIA DE LOS SISTEMAS DE BASES DE DATOS. ............................. 3
1.1. CONCEPTOS FUNDAMENTALES. ............................................................................................. 3
3.2.1. ORIGEN Y EVOLUCIÓN DE LAS BASES DE DATOS......................................................................... 3 3.2.2. CONCEPTO DE BASE DE DATOS. .................................................................................................. 5 3.2.3. OBJETIVOS DE UNA BASE DE DATOS. .......................................................................................... 5 3.2.4. SISTEMAS DE GESTIÓN DE BASES DE DATOS. .............................................................................. 6
1.1.4.1. Arquitectura de un Sistema de Gestión de Bases de Datos. ............................................... 7 1.1.4.2. Arquitectura de Implantación de un SGBD. ....................................................................... 8 1.1.4.3. Ventajas del empleo de un SGBD para la manipulación de una base de datos. ................ 9 1.1.4.4. Evolución de los SGBD: nuevas perspectivas y áreas de aplicación. ...............................10
1.3. BASES DE DATOS DEDUCTIVAS. .............................................................................................14
1.2.1. DEFINICIÓN. ...............................................................................................................................14 1.2.2. ELEMENTOS CONSTITUTIVOS. ....................................................................................................14 1.2.3. FUNDAMENTOS Y CARACTERÍSTICAS. ........................................................................................14 1.2.4. ENFOQUES Y ASPECTOS. .............................................................................................................15
1.2.4.1. Reglas de Deducción. ........................................................................................................15 1.2.4.2. SGBD Deductivo. ...............................................................................................................20
3. BASES DE DATOS ACTIVAS. .........................................................................................................20
1.3.1. DEFINICIÓN. ...............................................................................................................................20 1.3.2. ELEMENTOS CONSTITUTIVOS. ....................................................................................................21 1.3.3. FUNDAMENTOS Y CARACTERÍSTICAS. ........................................................................................21 1.3.4. ENFOQUES Y ASPECTOS. .............................................................................................................22
1.3.4.1. Reglas Activas. ...................................................................................................................23 1.3.4.2. SGBD Activo. .....................................................................................................................23
CAPÍTULO 2. SISTEMAS DE BASES DE DATOS DEDUCTIVAS. ...................................................24
2.1. CONCEPTOS FUNDAMENTALES. ............................................................................................24
2.1.1. FUNDAMENTOS...........................................................................................................................24
2.2. DESCRIPCIÓN GENERAL...........................................................................................................27
2.2.1. DATALOG ...................................................................................................................................27 2.2.1.1. Perspectiva del Producto. ..................................................................................................27 2.2.1.2. Funcionalidad del Producto. .............................................................................................27
2.2.2. SISTEMA LDL (LOGIC DATA LANGUAGE). .................................................................................29 2.2.2.1. Perspectiva del Producto. ..................................................................................................29 2.2.2.2. Funcionalidad del Producto. .............................................................................................30
2.2.3. SISTEMA CORAL. ......................................................................................................................32 2.2.3.1. Perspectiva del Producto. ..................................................................................................32 2.2.3.2. Funcionalidad del Producto. .............................................................................................32
2.2.4. PROYECTO NAIL!. .....................................................................................................................34 2.2.4.1. Perspectiva del Producto. ..................................................................................................34 2.2.4.2. Funcionalidad del Producto. .............................................................................................34
2.2.5. CONCLUSIONES. .........................................................................................................................35
CAPÍTULO 3. SISTEMAS DE BASES DE DATOS ACTIVAS. ............................................................36
3.1. CONCEPTOS FUNDAMENTALES. ............................................................................................36
3.1.1. FUNDAMENTOS...........................................................................................................................36
4
3.2. CONCEPTOS FUNDAMENTALES. ............................................................................................42
3.2.5. HIPAC .......................................................................................................................................42 3.2.1.1. Perspectiva del Producto. ..................................................................................................42 3.2.1.2. Funcionalidad del Producto. .............................................................................................43
3.2.2. POSTGRES ...................................................................................................................................43 3.2.2.1. Perspectiva del Producto. ..................................................................................................43 3.2.2.2. Funcionalidad del Producto. .............................................................................................44
3.2.3. PROYECTO STARBURST ..............................................................................................................46 3.2.3.1. Perspectiva del Producto. ..................................................................................................46 3.2.3.2. Funcionalidad del Producto. .............................................................................................47
3.2.4. SYBASE ......................................................................................................................................48 3.2.4.1. Perspectiva del Producto. ..................................................................................................48 3.2.4.2. Funcionalidad del Producto. .............................................................................................49
3.2.5. INTERBASE .................................................................................................................................49 3.2.5.1. Perspectiva del Producto. ..................................................................................................49 3.2.5.2. Funcionalidad del Producto. .............................................................................................50
3.2.6. ORACLE ......................................................................................................................................55 3.2.6.1. Perspectiva del Producto. ..................................................................................................55 3.2.6.2. Funcionalidad del Producto. .............................................................................................55
3.1.1. CONCLUSIONES. .........................................................................................................................57
CONCLUSIONES .......................................................................................................................................60
RECOMENDACIONES .............................................................................................................................61
BIBLIOGRAFÍA .........................................................................................................................................62
REFERENCIAS BIBLIOGRÁFICAS. ......................................................................................................64
ANEXOS. .....................................................................................................................................................66
Anexo 1 ..................................................................................................................................................66
1
Introducción.
En la actualidad las Bases de Datos y su tecnología están teniendo un impacto decisivo sobre el
creciente uso de las computadoras. No es exagerado decir que las bases de datos
desempeñarán un papel crucial en casi todas las áreas de aplicación de las computadoras, como
los negocios, la ingeniería, la medicina, el derecho, la educación y la biblioteconomía, por
mencionar sólo unas cuantas.
Desde su introducción en 1970, el modelo relacional ha provocado un interés creciente debido a
que se fundamentan en el concepto matemático preciso de Relación, lo cual permite la
utilización de lenguajes especializados y eficientes para la manipulación de datos, basados en el
Álgebra Relacional o alguna variantes del Cálculo Relacional. Las desventajas del modelo
relacional en términos de su poder expresivo semántico hicieron surgir el interés por los modelos
semánticos. Este interés ha crecido desde finales de los años setenta, sobre todo con la
aparición de los modelos de entidad – vínculo, de jerarquía semántica y de datos semántico.
Hoy día, cuando los horizontes de las aplicaciones de Bases de Datos se encuentran en una
clara fase de expansión, la necesidad de contar con las abstracciones se está sintiendo de
manera aún más intensa.
En 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 los sistemas de bases de datos que
consiste en ofrecer recursos para definir Reglas de Deducción que permitan deducir o inferir
información nueva a partir de los datos almacenados. La meta de estas aplicaciones es
incorporar a las Bases de Datos Relacionales los beneficios de la lógica como un instrumento
para la formalización integrada de los aspectos estáticos y dinámicos del modelado de
aplicaciones.
Entre los objetivos a lograr en este trabajo se valoran los siguientes:
Exponer el conocimiento y la apreciación de las principales tendencias de las Bases de
Datos Deductivas.
Exponer el conocimiento y la apreciación de las principales tendencias de las Bases de
Datos Activas.
Conocer la implementación de los Conceptos de Bases de Datos Deductivas y Bases de
Datos Activas en los Sistemas de Gestión de Bases de Datos Avanzados.
Para el correcto desarrollo de esta tesis decidimos estructurarla en tres capítulos los cuales se
refieren a:
Introducción
2
Capítulo 1: Breve historia de los sistemas de bases de datos.
Para el entendimiento correcto de este trabajo, es necesario conocer cual ha
sido la evolución y el estado actual de la tecnología de las bases de datos, con el
objetivo de estar preparados para los cambios que, inevitablemente, se van a dar
en el área de las bases de datos y los sistemas de información. Con esta visión,
este capítulo relata brevemente la evolución de los sistemas gestores de bases
de datos, centrándose en los fundamentos de la tecnología actual y su
motivación.
Capítulo 2: Sistemas de Bases de Datos Deductivas.
En este capítulo presentamos conceptos de Datalog, así como el mecanismo de
inferencia estándar de encadenamiento hacia atrás y una estrategia ascendente
de encadenamiento hacia delante. Esta última se ha adaptado para evaluar
consultas sobre relaciones mediante operaciones relacionales estándar junto con
Datalog.
Examinamos a grandes rasgos un sistema comercial de bases de datos
deductivas llamado LDL, creado por MCC, y otros sistemas experimentales
llamados CORAL y NAIL!. El área de las bases de datos deductivas todavía esta
en una etapa experimental. Su adopción por parte de la industria impulsará su
desarrollo.
Capítulo 3: Sistemas de Bases de Datos Activas.
Los sistemas activos de la base de datos apoyan los mecanismos que les
permiten responder automáticamente a los acontecimientos que están
ocurriendo dentro o fuera del sistema mismo de la base de datos. El esfuerzo
considerable se ha dirigido hacia mejorar la comprensión de tales sistemas en
años recientes, y se han hecho diversas ofertas y se han sugerido los usos. Este
alto nivel de actividad no solo ha rendido un acercamiento estándar a la
integración de la funcionalidad activa con los sistemas convencionales de la base
de datos, sino ha conducido a la comprensión mejorada de los idiomas
descriptivos del comportamiento, de los modelos de la ejecución y de las
arquitecturas activos. Este capítulo presenta las características fundamentales
de los sistemas activos de la base de datos, describe una colección de sistemas
representativos dentro de un marco común, considera las consecuencias para
las puestas en práctica de ciertas decisiones del diseño, y discute las
herramientas para desarrollar usos activos.
3
Capítulo 1. Breve historia de los Sistemas de Bases de
Datos.
1.1. Conceptos Fundamentales.
3.2.1. Origen y Evolución de las Bases de Datos.
El almacenamiento de los datos es considerado por algunos como la parte medular de
los sistemas de información. Los objetivos generales para el diseño de la organización
de almacenamiento de datos son los siguientes:
Los datos tienen que estar disponibles cuando el usuario los necesite.
Los datos deben ser precisos y consistentes (deben poseer integridad).
El almacenamiento de los datos, así como su recuperación y actualización debe
ser eficiente.
La información obtenida de los datos almacenados debe estar en un formato útil
para la administración, planeación, control o toma de decisiones.
Hay dos enfoques para el almacenamiento de datos en un sistema basado en
computadora. El primer método es guardar los datos en archivos individuales, cada uno
de ellos único para una aplicación particular. El segundo enfoque involucra la
construcción de una base de datos. Una base de datos es un almacén de datos
formalmente definido y centralmente controlado para ser usado en muchas aplicaciones
diferentes.
Las bases de datos no son simplemente un conjunto de archivos. En vez de ello, una
base de datos es una fuente central de datos que esta pensada para que sea compartida
por muchos usuarios con una diversidad de aplicaciones.
Los objetivos de efectividad de la base de datos incluyen:
Asegurarse de que la base de datos puede ser compartida entre los usuarios de
una diversidad de aplicaciones.
Mantener datos que sean precisos y consistentes.
Asegurarse de que todos los datos requeridos para las aplicaciones actuales y
futuras estén fácilmente disponibles.
Permitir que la base de datos evolucionen y que las bases de datos crezcan.
Capítulo 1. Breve historia de los sistemas de bases de datos.
4
Permitir que los usuarios construyan su vista personal de los datos sin
preocuparse de la forma en que estén físicamente guardados.
Un poco de Historia.
Primera Generación: Sistemas de Bases de Datos Jerárquicas y de Redes.
Segunda Generación: Sistemas de Bases de Datos Relacionales.Se cumplen ya treinta
años desde que el Dr. Codd propuso el Modelo Relacional [Anexo 1], dando lugar a la
"Segunda Generación" de productos de bases de datos: ORACLE, DB2, INGRES,
INFORMIX, SYBASE, etc. que presentan una mayor independencia físico-lógica, mayor
flexibilidad y lenguajes de especificación (que actúan sobre conjuntos de registros). Este
tipo de productos se ha ido imponiendo en el mercado y ha sido uno de los principales
focos de investigación durante las décadas de los setenta y ochenta. [1], [14]
Tercera Generación: Sistemas de Bases de Datos Orientadas a Objetos y Deductivas.
Esta nueva generación de bases de datos (la "Tercera"), se caracteriza por proporcionar
capacidades de gestión de datos, objetos y gestión de conocimiento y 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.
Todas estas nuevas tecnologías afectan al proceso de diseño de bases de datos, que
resulta cada día más difícil, así como a la administración de los sistemas. Por otra parte,
también se propugna el desarrollo de nuevos estándares como el ODMG y el SQL, que
recojan las características de esta nueva generación. [1], [12]
Los Sistemas de Bases de Datos (SBD) son el resultado de la evolución de los sistemas
informativos basados en la concepción de ficheros, donde inicialmente se
independizaron los procedimientos para la apertura, cierre y acceso a los ficheros, hasta
llegarse a los Sistemas de Gestión de Bases de Datos (SGBD), que facilitan la
definición, creación, manipulación y actualización de la base de datos.
Las BD y los SGBD se basan en determinados modelos de datos, que en esencia son
una herramienta conceptual, que permite la representación del dominio de aplicación
que se quiere modelar. Desde su aparición en la década de 1950, los modelos de datos
tradicionales más conocidos son:
Modelo Jerárquico
Modelo en Red
Capítulo 1. Breve historia de los sistemas de bases de datos.
5
Modelo Relacional (el más extendido hoy en día; los datos se almacenan en
tablas a los que se accede mediante consultas escritas en SQL).
3.2.2. Concepto de Base de Datos.
Es un conjunto de datos no redundantes, almacenados en un soporte informático,
organizado de forma independiente de su utilización y accesible simultáneamente por
distintos usuarios y aplicaciones.
Es decir, la diferencia de una BD respecto a otro sistema de almacenamiento de datos,
es que éstos se almacenan de forma que cumplan tres requisitos básicos:
No redundancia. Los datos se almacenan una sola vez. Si varias aplicaciones necesitan
los mismos datos, no crearán cada una su propia copia sino que todas accederán a la
misma.
Independencia. Los datos se almacenan teniendo en cuenta la estructura inherente a
los propios datos y no la de la aplicación que los crea. Esta forma de trabajar es la que
permite que varias aplicaciones puedan utilizar los mismos datos.
Concurrencia. Varios usuarios, ejecutando la misma o diferente aplicación, podrán
acceder simultáneamente a los datos.
3.2.3. Objetivos de una Base de Datos.
Las Bases de Datos son una herramienta útil en el crecimiento de cualquier
organización, el cúmulo y control de la información permite conocer índices y puntos
neurálgicos, la información está disponible en momentos precisos y claves para el
desarrollo de la misma, para la toma de decisiones debe ser oportuna y confiable. El
llegar a este punto implica el implantar políticas y estrategias respecto a la información, y
el Administrador de la base de datos es quien debe poner en práctica estas decisiones.
Las ventajas principales de las bases de datos como son de todos conocidas involucran
la recuperación y manejo rápido y eficiente de la información, el control de la
redundancia, evitar la inconsistencia de la información y el tener una mayor integridad de
ella. Aunado a lo anterior podemos recalcar el poder de las aplicaciones distribuidas y
los sistemas cliente-servidor.
En una base de datos la información se encuentra en diversos archivos (tablas) y a su
vez estos pueden alojarse en diversos dispositivos de almacenamiento (discos), incluso
en diferentes servidores, sin embargo la información se maneja como un todo, de hecho
se dice que la información es integrada, la mayor ventaja de esto es el compartir
Capítulo 1. Breve historia de los sistemas de bases de datos.
6
información, como resultado varios usuarios pueden acceder al mismo tiempo a la base
de datos, incluso desde diferentes terminales y la transparencia del sistema evita que el
usuario perciba la trascendencia y alcance de la aplicación.
Otro de los factores que sin duda alguna ha ayudado al desarrollo de las bases de datos
son las nuevas tecnologías de almacenamiento y acceso a la información a través de
diferentes medios, así como la madurez de los sistemas operativos que han creado
bases sólidas para este tipo de aplicaciones. En los últimos años venimos asistiendo a
un avance espectacular en la tecnología de bases de datos. Temas que hasta hace poco
parecían exclusivos de laboratorios y centros de investigación, comienzan a aparecer en
las últimas versiones de algunos SGBD y en nuevos productos: bases de datos
multimedia, activas, deductivas, orientadas a objetos, temporales, móviles, paralelas,
multidimensionales, etc.
3.2.4. Sistemas de Gestión de Bases de Datos.
Un Sistema de Gestión de Bases de Datos es el conjunto de programas que
permiten definir y manipular la información que contienen las bases de datos,
realizar todas las tareas de administración necesarias para mantenerlas
operativas, mantener su integridad, confidencialidad y seguridad. Una BD nunca
Capítulo 1. Breve historia de los sistemas de bases de datos.
7
se accede o manipula directamente sino a través del SGBD. Se puede considerar
al SGBD como la interfaz entre el usuario y la BD.
El funcionamiento del SGBD está muy interrelacionado con el del Sistema
Operativo, especialmente con el sistema de comunicaciones. El SGBD utilizará las
facilidades del sistema de comunicaciones para recibir las peticiones del usuario
(que puede estar utilizando un terminal físicamente remoto) y para devolverle los
resultados.
Un SGBD debe proporcionar un conjunto de funciones para poder cumplir
adecuadamente su misión. Normalmente se clasifican en definición, manipulación
y utilización.
Función de Definición. Permite describir los elementos de datos, sus estructuras,
sus interrelaciones y sus validaciones a nivel externo, lógico e interno. Esta función
es realizada por una parte del SGBD denominada lenguaje de definición de datos
(LDD o DDL - Data Definition Language).
Función de Manipulación. Permite buscar, añadir, suprimir y modificar los datos
de la BD. Esta función es realizada por una parte del SGBD denominada lenguaje
de manipulación de datos (LMD o DML - Data Manipulation Language).
Función de Utilización. Incluye otras funcionalidades tales como: modificar la
capacidad de los registros, cargar archivos, realizar copias de seguridad, de
arranque, protección frente a accesos no autorizados, gestión de la concurrencia,
estadísticas de utilización, etc.
1.1.4.1. Arquitectura de un Sistema de Gestión de Bases de
Datos.
La mayoría de los Sistemas de Gestión de Bases de Datos actuales están
inspirados en una arquitectura sugerida en 1978 por un grupo de trabajo de ANSI.
Es conocida como ANSI/X3/SPARC "DBMS Framework" y es una arquitectura
adecuada para construir Bases Datos que cumplan los requisitos señalados en la
definición y además sean portables entre distintas máquinas y sistemas
operativos.
Esta arquitectura divide la base de datos en tres niveles:
El nivel externo es la representación de los datos, tal y como los ve el
usuario. Cada usuario tendrá una visión distinta de la base de datos
dependiente del subconjunto de datos, que está autorizado a ver según
sus privilegios de acceso y también, del formato en que se le presentan,
Capítulo 1. Breve historia de los sistemas de bases de datos.
8
que dependerá de las herramientas que utilice (por ejemplo, un programa
COBOL o un 4GL).
El nivel lógico es una representación abstracta (no física como en el nivel
interno) del contenido total de la base de datos. Contiene la definición de
todos los datos existentes más otras informaciones como restricciones de
seguridad, controles de integridad, etc.
El nivel interno es el más cercano a la máquina. Es una representación a
bajo nivel de la BD, en la que se define la forma en que los datos se
almacenan físicamente en la máquina. Se definen características como los
dispositivos en donde se almacenan los datos, el espacio que se reserva,
las estrategias de acceso, la creación de ficheros de índices, etc. Es
dependiente de la máquina en que se vaya a instalar la BD, del sistema
operativo que exista, etc.
1.1.4.2. Arquitectura de Implantación de un SGBD.
No debe confundirse el SGBD con la arquitectura que se elige para implantarlo.
Algunos SGBD sólo se pueden implantar en una de las arquitecturas y otros en
todas ellas.
La arquitectura centralizada es la más clásica. En ella, el SGBD está implantado
en una sola plataforma u ordenador desde donde se gestiona directamente, de
modo centralizado, la totalidad de los recursos. Es la arquitectura de los centros de
proceso de datos tradicionales. Se basa en tecnologías sencillas, muy
experimentadas y de gran robustez.
En la arquitectura distribuida, el SGBD y la BD no están asociados a un
determinado ordenador sino a una red, cuyos nodos se reparten las funciones.
Una base de datos distribuida es vista por las aplicaciones igual que si fuera
centralizada. Es el SGBD distribuido el que se encarga de preservar la integridad y
coherencia de la BD. Sin embargo existe otra definición mucho menos estricta de
base de datos distribuida, utilizada por muchos fabricantes de SGBD, según la
cual una base de datos es distribuida si permite lecturas y modificaciones remotas,
independientemente de que éstas sean transparentes o no, para las aplicaciones.
Esta definición no es adecuada cuando se desea seleccionar una BD realmente
distribuida.
Se suele distinguir entre sistemas homogéneos y heterogéneos. Un sistema es
homogéneo si el SGBD usado en todas las máquinas es el mismo. Si existe más
de un SGBD distinto el sistema se denomina heterogéneo.
Capítulo 1. Breve historia de los sistemas de bases de datos.
9
La distribución física, espacial o geográfica de la información, puede aconsejar la
utilización de esta arquitectura. Cada vez existen más productos disponibles en el
mercado aunque no existen estándares.
Un SGBD que soporte una arquitectura de base de datos distribuida, es mucho
más complejo que uno para base de datos centralizada y el número de SGBDs
distribuidos disponibles en el mercado es mucho menor. Existen algunos SGBDs
que ofrecen la posibilidad de implementar una BD distribuida, sólo para sistemas
homogéneos.
Es una tecnología que no está tan probada como la centralizada.
La arquitectura cliente/servidor separa las funciones de una aplicación en
componentes que establecen diálogos entre sí, para intercambiar información,
servicios o recursos con el objeto de realizar una tarea común. Cada componente
puede estar en un ordenador diferente. El proceso que inicia el diálogo o solicita
recursos se denomina cliente y suele ser la aplicación que el usuario está
ejecutando. El proceso que responde a las solicitudes se denomina servidor.
Esta arquitectura se basa, al igual que el caso anterior, en varias plataformas
interconectadas, una de las cuales actúa como "servidor" de la BD, en la que los
datos están físicamente localizados y centraliza las funciones de administración.
Las plataformas denominadas "clientes" realizan funciones de manejo de las
interfases de usuario, lógica de aplicación, etc.
La arquitectura cliente/servidor no exige requisitos especialmente complejos a los
SGBD ya que, aunque estén involucrados varios ordenadores, la base de datos en
sí está normalmente centralizada en un ordenador y su mantenimiento es igual de
sencillo que en una arquitectura centralizada clásica. Para esta arquitectura es
importante que el SGBD soporte sistemas de comunicación normalizados, ya que
tendrá que recibir peticiones de diversos clientes, operando con máquinas y
protocolos distintos.
1.1.4.3. Ventajas del empleo de un SGBD para la manipulación
de una base de datos.
Un Sistema de Gestión de Bases de Datos, normalmente proporciona una amplia
serie de ventajas. Entre las más importantes se pueden destacar:
Eliminan las inconsistencias en los datos. Algo especialmente difícil sin
un SGBD, cuando los mismos datos se utilizan y actualizan en diferentes
procesos.
Capítulo 1. Breve historia de los sistemas de bases de datos.
10
Permiten compartir los mismos datos entre diferentes aplicaciones con
distintas necesidades.
Se adaptan mejor a la existencia de aplicaciones rápidamente
cambiantes. En estos casos con los enfoques tradicionales se puede
requerir la conversión de los datos cada vez. Un SGBD proporcionará
independencia de los datos respecto a las aplicaciones.
Ahorran espacio de almacenamiento al no existir redundancia o ser ésta
escasa. También porque muchos SGBDs utilizan mecanismos de
compresión para almacenar los datos.
Mejoran la seguridad de los datos pues, normalmente, incorporan
mecanismos de seguridad en el propio SGBD.
Permiten la creación de entornos de alta disponibilidad. Los SGBDs
modernos suelen permitir realizar gran parte (a veces todo) del
mantenimiento del sistema sin necesidad de parar las aplicaciones. Por
tanto, con algunos SGBDs es posible llegar a disponer de aplicaciones
funcionando ininterrumpidamente.
Por otra parte, si se escoge adecuadamente el SGBD, no suelen presentarse
problemas de tipo técnico que no se presenten con los sistemas anteriores de
almacenamiento de datos, sino que los problemas suelen ser los típicos de
cualquier equipo lógico complejo:
La puesta en funcionamiento puede ser larga. Pues antes de obtener
los primeros resultados se necesita un período de formación y adaptación
variable, según la complejidad del entorno.
Se necesita personal especializado para su mantenimiento. En
principio un diseñador de la BD y un administrador permanente de la BD.
1.1.4.4. Evolución de los SGBD: nuevas perspectivas y áreas
de aplicación.
En la tecnología actual de SGBDs relacionales se observan las siguientes
tendencias.
Los SGBD post - relacionales
Se basan en la combinación dinámica de los modelos de datos que estén o no en
la primera forma normal. Desde el punto de vista de las operaciones de tipo
relacional, una tabla que contiene a otra anidada en ella, se visualiza como dos
Capítulo 1. Breve historia de los sistemas de bases de datos.
11
tablas unidas y cada una accesible como una entidad lógica, separada a través de
un proceso llamado normalización dinámica. El modelo post-relacional es de una
estructura tridimensional, es decir, los campos o grupos de éstos pueden aparecer
varias veces, una vez, o nunca, sin limitación y sin necesidad de definición.
Reduce el número de tablas y elimina la duplicación de datos. El modelo relacional
tradicional (1NF) es un subgrupo del modelo post-relacional.
Los SGBD Orientados a Objetos
Una de las novedades más prometedoras y más desarrolladas comercialmente de
los nuevos SGBDs, son los basados en un nuevo modelo de datos conocido como
modelo orientado a objetos.
La orientación a objetos es un paradigma que no se aplica sólo al desarrollo de
SGBDs sino, en general, al desarrollo de sistemas de información.
Aunque no existe una definición universalmente aceptada de lo que es un objeto,
la idea fundamental es la integración de dos conceptos que tradicionalmente se
han venido tratando de forma separada: datos y procesos. Cada objeto encapsula
tanto datos (también llamados atributos) como procesos (o métodos). Los objetos
se comunican entre sí mediante mensajes. Cada objeto se percibe por los demás
como el encapsulamiento de una serie de servicios que se pueden invocar
externamente. De esta forma, el encapsulamiento es una abstracción que permite
ocultar a los usuarios la instrumentación del objeto, ofreciéndoles una interfase
externa mediante la cuál interactúa con él. Esta orientación es muy adecuada para
el manejo de elementos complejos como, por ejemplo, gráficos.
Idealmente, los objetos son modulares e independientes entre sí, lo que facilita su
comprensión, reutilización y mantenimiento.
Los SGBD orientados a objetos ofrecen varias ventajas sobre los sistemas
relacionales:
Manejan más efectivamente tipos de datos complejos como imágenes.
Son más sencillos de mantener gracias al encapsulamiento.
Proveen un acceso más sencillo a los datos.
También existen varios fabricantes de SGBD relacionales que están incorporando,
lentamente, capacidades de orientación a objetos en sus SGBD, abriendo así otra
vía al desarrollo de SGBD orientados a objetos que parece muy prometedora en
un futuro muy próximo.
Capítulo 1. Breve historia de los sistemas de bases de datos.
12
Los SGBD basados en Reglas
En nuestra vida diaria encontramos muchas situaciones complejas gobernadas por
reglas deterministas: sistemas de control de tráfico, sistemas de seguridad,
transacciones bancarias, etc. Los sistemas basados en reglas son una
herramienta eficiente para tratar estos problemas. Las reglas deterministas
constituyen la más sencilla de las metodologías utilizadas por los SGBDs. La base
del conocimiento contiene las variables y el conjunto de reglas que definen el
problema, y el motor de inferencia obtiene las conclusiones aplicando la lógica
clásica a estas reglas. Por regla se entiende una proposición lógica que relaciona
dos o más objetos e incluye dos partes, la premisa y la conclusión. Cada una de
estas partes consiste en una expresión lógica con una o más afirmaciones objeto-
valor conectadas mediante los operadores lógicos y, o, o no. una regla se escribe
normalmente como “Si premisa, entonces conclusión”.
Un SGBD basado en reglas esta conformado por dos partes:
Parte declarativa:
o Hechos: conocimiento declarativo (información) sobre el mundo
real.
o Reglas: conocimiento declarativo de la gestión de la base de
hechos
En lógica monótona: únicamente se permiten añadir
hechos.
En lógica no-monótona: inserciones, modificaciones y
eliminación de hechos.
o Meta-reglas: conocimiento declarativo sobre el empleo de las
reglas.
Parte algorítmica / imperativa:
o Motor de inferencia: Software que efectúa los razonamientos
sobre el conocimiento declarativo disponible:
Se base en uno o varios esquemas de razonamiento
(ejemplo: deducción).
Se puede consultar la traza del proceso de razonamiento:
Durante las fases de diseño y depuración
Capítulo 1. Breve historia de los sistemas de bases de datos.
13
Para obtener explicaciones sobre la solución.
Los SGBD basados en reglas ofrecen varias ventajas sobre los sistemas
relacionales:
Modularidad: los lenguajes basados en reglas son muy modulares.
Cada regla es una unidad del conocimiento que puede ser añadida,
modificada o eliminada independientemente del resto de las reglas.
Se puede desarrollar una pequeña porción del sistema, comprobar su
correctos funcionamiento y añadirla al resto de la base de conocimiento.
Uniformidad:
Todo el conocimiento es expresado de la misma forma.
Naturalidad:
Las reglas son la forma natural de expresar el conocimiento en cualquier
dominio de aplicación.
Explicación:
La traza de ejecución permite mostrar el proceso de razonamiento.
Capítulo 1. Breve historia de los sistemas de bases de datos.
14
1.3. Bases de Datos Deductivas.
1.2.1. Definición.
Un Sistema de Bases de Datos que contenga reglas con las cuales se puede deducir o
inferir información adicional a partir de los hechos almacenados en las bases de datos se
llama Sistema de Bases de Datos Deductivas. Puesto que los fundamentos teóricos
de sistemas de ésta especie es la lógica matemática, a menudo se les denomina Bases
de Datos Lógicas. Una base de datos deductiva es, en esencia, un programa lógico;
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.
1.2.2. Elementos Constitutivos.
Una Base de Datos Deductiva utiliza dos tipos de especificaciones: hechos y reglas.
Los hechos se especifican de manera similar a como se especifican las relaciones,
excepto que no es necesario incluir los nombres de los atributos. Recordemos que una
tupla en una relación describe algún hecho del mundo real cuyo significado queda
determinado en parte por los nombres de los atributos. En una Base de Datos Deductiva,
el significado del valor del atributo en una tupla queda determinado exclusivamente por
su posición dentro de la tupla.
Las reglas se parecen un poco a las vistas relacionales. Especifican relaciones virtuales
que no están almacenadas realmente, pero que se pueden formar a partir de los hechos
aplicando mecanismos de inferencia basados en las especificaciones de las reglas. La
principal diferencia entre las reglas y las vistas es que en las primeras puede haber
recursividad y por tanto pueden producir vistas que no es posible definir en términos de
las vistas relacionales estándar. [2]
Las BDD buscan derivar nuevos conocimientos a partir de datos existentes
proporcionando interrelaciones del mundo real en forma de reglas. Utilizan mecanismos
internos para la evaluación y la optimización.
1.2.3. Fundamentos y Características.
Una Base de Datos Deductiva debe contar al menos con las siguientes características:
Tener la capacidad de expresar consultas por medio de reglas lógicas.
Permitir consultas recursivas y ofrecer algoritmos eficientes para su evaluación.
Contar con negaciones estratificadas.
Capítulo 1. Breve historia de los sistemas de bases de datos.
15
Contar con métodos de optimización que garanticen la traducción de
especificaciones dentro de planes eficientes de acceso.
Como característica fundamental de una Base de Datos Deductiva es la posibilidad de
inferir información a partir de los datos almacenados, es imperativo modelar la base de
datos como un conjunto de fórmulas lógicas, las cuales permiten inferir otras fórmulas
nuevas. [11]
1.2.4. Enfoques y Aspectos.
En un sistema de Bases de Datos Deductivas se usa un lenguaje declarativo para
especificar reglas. Con lenguaje declarativo se quiere decir un lenguaje que define lo que
un programa desea lograr, en vez de especificar los detalles de cómo lograrlo. Una
máquina de inferencia (o mecanismo de deducción) dentro del sistema puede deducir
hechos nuevos a partir de la base de datos interpretando dichas reglas.
El modelo empleado en las Bases de Datos Deductivas está íntimamente relacionado
con el modelo de datos relacional, y sobre todo con el formalismo del cálculo relacional.
También esta relacionado con el campo de la programación lógica y el lenguaje Prolog.
1.2.4.1. Reglas de Deducción.
Las relaciones de una Base de Datos Relacional se definen por “intención” y por
“extensión”. Para una Base particular, la intención de las relaciones que la
constituyen se define por un conjunto de leyes generales, mientras que cada
estado de la Base proporciona una extensión (conjunto de tuplas) para cada una
de las relaciones. Las tuplas constituyen, de hecho, informaciones elementales. En
un SGBD convencional, todas las leyes generales se explotan para mantener la
coherencia de las informaciones elementales; a estas leyes se las denomina
entonces restricciones de integridad.
Por el contrario, en un Sistema deductivo, algunos (o todas) de estas leyes se
utilizan como reglas de deducción para deducir nuevas informaciones elementales
a partir de las introducidas explícitamente en la Base.
Por ejemplo: se considera una Base de Datos en la que se detallan los lazos de
parentesco entre individuos, interesándose particularmente por las relaciones
PADRE y ABUELO. Entre las leyes generales que conciernen a estas dos
relaciones, se considera la ley 1 que expresa “Todo padre de un padre es un
abuelo”, y se supone que, en un momento dado, el estado de la Base es tal que
las informaciones elementales relativas a las relaciones PADRE y ABUELO son
las siguientes:
Capítulo 1. Breve historia de los sistemas de bases de datos.
16
Si la ley 1 se considera como una regla de coherencia, este estado de la Base
debe considerarse no válido, ya que la vulnera. En efecto, la extensión de
ABUELO no contiene la tupla (Juan, Jaime), siendo así que Juan es el padre de
Pablo y Pablo es el padre de Jaime. En este caso se ha hecho (implícitamente) la
hipótesis de que la tupla que satisface (en un momento dado) la relación ABUELO
son exactamente las que aparecen en su extensión. Si se prescinde de este
supuesto se puede, por el contrario, suponer que las tuplas que satisfacen la
relación ABUELO no son sólo las que aparecen de modo explícito en su extensión,
sino también las que pueden deducirse, mediante la ley 1, de las informaciones
relativas a PADRE; usando así 1 como regla de deducción.
Las reglas deductivas son un medio primario para expresar las propiedades
invariantes de los objetos. Las características distintivas de las mismas son su
simplicidad y su naturalidad: ellas declaran cual es la propiedad pero no como se
computa la misma.
Las reglas deductivas pueden ser utilizadas para codificar tanto las propiedades
que son comunes a todas las aplicaciones (por ejemplo las restricciones de
integridad), como patrones de datos complejos que pueden ser deducidos a partir
de información simple almacenada (por ejemplo vistas e información derivada)
Las aplicaciones se benefician de las reglas deductivas de dos formas:
no necesitan dedicarse al chequeo de las restricciones de integridad, ya
que las mismas son chequeadas por el sistema de base de datos
pueden utilizar vistas y datos derivados para simplificar consultas,
especialmente las recursivas, que son computadas por parte del servidor
de base de datos.
Capítulo 1. Breve historia de los sistemas de bases de datos.
17
1.2.4.1.1. Interpretación de Reglas.
Las reglas pueden ser declarativas (aserciones) o imperativas (órdenes): el
manejo de la regla es esencial, ya que provee un paradigma uniforme para
poder desenvolverse en el control de la integridad semántica, panoramas,
protección, deducción y órdenes. Mucho del trabajo en las bases de datos
deductivas se han concentrado en la semántica de los programas de reglas y
en las consultas deductivas de procesamiento, particularmente en la presencia
de predicados negados y recursivos.
Existen principalmente dos alternativas para interpretar el significado de las
reglas:
Teoría de los Modelos
Teoría de las Demostraciones
En la Teoría de Modelos, dado un dominio finito o infinito de valores
constantes, se le asigna a un predicado todas las combinaciones posibles de
valores como argumentos. Después se debe determinar si el predicado es
verdadero o falso. En general, basta con especificar las combinaciones de
argumentos que hacen que el predicado sea verdadero, y decir que todas las
demás combinaciones hacen que sean falsos. Si esto se hace con todos los
predicados, se habla de una interpretación del conjunto de predicados. [2]
En la Teoría de las Demostraciones, se considerarán los hechos y las reglas
como enunciados verdaderos o axiomas. Los axiomas base no contienen
variables. Los hechos son axiomas base que se dan por ciertos. Las reglas se
llaman axiomas deductivos, ya que pueden servir para deducir hechos nuevos.
Con los axiomas deductivos se pueden construir demostraciones que deriven
hechos nuevos a partir de los ya existentes. Los axiomas deductivos, junto con
las restricciones de integridad constituyen lo que en ocasiones se denomina
base de datos intencional, y la base de datos extensional junto con la
intencional constituyen lo que suele llamarse Base de Datos Deductiva;
aunque en realidad, quien se encarga de las deducciones es el DBMS, no la
base de datos. La interpretación por la Teoría de las Demostraciones ofrece
un enfoque por procedimientos o computacional para calcular una respuesta a
la consulta. Al proceso de demostrar si un determinado hecho (teorema) se
cumple se le conoce también como Demostración de Teoremas.
Capítulo 1. Breve historia de los sistemas de bases de datos.
18
superior (X,Y) :- supervisar (X,Y).
superior (X,Y) :- supervisar (X,Z), superior (Z,Y).
supervisar (Federico, José) es verdadero.
supervisar (Federico, Ramón) es verdadero.
supervisar (Federico, Josefa) es verdadero.
supervisar (Jazmín, Alicia) es verdadero.
supervisar (Jazmín, Ahmed) es verdadero.
supervisar (Jaime, Federico) es verdadero.
supervisar (Jaime, Jazmín) es verdadero.
supervisar (X, Y) es falso para todas la demás combinaciones posibles (X, Y).
superior (Federico, José) es verdadero.
superior (Federico, Ramón) es verdadero.
superior (Federico, Josefa) es verdadero.
superior (Jazmín, Alicia) es verdadero.
superior (Jazmín, Ahmed) es verdadero.
superior (Jaime, Federico) es verdadero.
superior (Jaime, Jazmín) es verdadero.
superior (Jaime, José) es verdadero.
superior (Jaime, Ramón) es verdadero.
superior (Jaime, Josefa) es verdadero.
superior (Jaime, Alicia) es verdadero.
superior (Jaime, Ahmed) es verdadero.
superior (X, Y) es falso para todas las demás combinaciones posibles (X, Y).
Capítulo 1. Breve historia de los sistemas de bases de datos.
19
1. superior (X,Y) :- supervisar (X,Y). (regla 1)
2. superior (X,Y) :- supervisar (X,Z), superior (Z,Y). (regla 2)
3. supervisar (Jazmín, Ahmed). (axioma base, dado)
4. supervisar (Jaime, Jazmín). (axioma base, dado)
5. superior (Jazmín, Ahmed). (aplicar la regla 1 a 3)
6. superior (Jaime, Ahmed) :- (aplicar la regla 2 a 4 y 5)
supervisar (Jaime, Jazmín),superior (Jazmín, Ahmed).
1.2.4.1.2. Utilización de las Reglas de Deducción.
La explotación de las reglas de deducción puede analizarse de dos formas. La
primera, consiste en su uso en fase de interrogación, buscando así
informaciones deducibles implícitas.
Una segunda forma consiste en su uso en fase de modificación, cuando se
añaden informaciones deducibles. Según se utilicen en el primer o el segundo
modo, las reglas se denominan de derivación o de generación.
1.2.4.1.3. Problemas asociados a las Reglas de Deducción.
La explotación de las reglas de deducción en un SGBD plantea algunos
problemas:
Encontrar criterios que permitan, para una ley dada; decidir su
utilización como regla de deducción o como regla de coherencia.
Replantear correctamente, en un contexto deductivo, las convenciones
habituales en una base de datos (representaciones de informaciones
negativas, eficacia de las respuestas a las interrogaciones, cierre del
dominio).
Capítulo 1. Breve historia de los sistemas de bases de datos.
20
Desarrollar procedimientos eficaces de deducción.
1.2.4.2. SGBD Deductivo.
El interés de los Sistemas de Gestión de Bases de Datos Deductivas tiende a
incrementarse conforme se amplía su campo de aplicación (Gestión, Sistemas
Expertos). Los estudios relativos a tales sistemas han comenzado a realizarse
hace algunos años, inspirándose inicialmente en las técnicas desarrolladas en
Inteligencia Artificial en el marco de los sistemas “Pregunta-Respuesta”,
adaptándolas a las limitaciones específicas de las Bases de Datos.
Un SGBD deductivo es un Sistema que permite derivar nuevas informaciones a
partir de las introducidas explícitamente en la Base por el usuario. Este maneja la
perspectiva según la teoría de las demostraciones de una base de datos, y en
particular es capaz de deducir hechos a partir de la base de datos extensional, es
decir, las relaciones base, aplicando a esos hechos axiomas deductivos o reglas
de inferencias especificados. Esta función deductiva se realiza mediante la
adecuada explotación de ciertos conocimientos generales relativos a las
informaciones de la Base.
3. Bases de Datos Activas.
1.3.1. Definición.
Tradicionalmente, los SGBD han sido pasivos; ejecutan consultas o transacciones sólo
cuando un usuario o un programa de aplicación les pide explícitamente que lo hagan.
Capítulo 1. Breve historia de los sistemas de bases de datos.
21
Sin embargo, muchas aplicaciones como el control de procesos, las redes de generación
/ distribución de energía eléctrica, el control automatizado del flujo de trabajo de una
oficina, el intercambio de programas, la gestión de batallas y la vigilancia de pacientes
hospitalarios no reciben un servicio adecuado de estos SGBD "pasivos". En estas
aplicaciones restringidas por el tiempo, es preciso vigilar la ocurrencia de condiciones
definidas sobre estados de la base de datos y, en caso de ocurrir, invocar acciones
específicas, quizá sujetas a ciertas restricciones de tiempo. Una posible situación en la
fabricación automatizada consistiría en vigilar la ocurrencia de un suceso, evaluara una
condición y emprender una o más acciones. En todo esto puede caber el acceso a bases
de datos compartidas que varios usuarios estén actualizando constantemente y que
deban mantenerse en un estado. [8]
1.3.2. Elementos Constitutivos.
Las bases de datos activas brindan varios beneficios a todas las aplicaciones en general,
como son:
Los elementos activos permiten una descripción centralizada y uniforme de las
reglas de negocio relevantes para el sistema de información.
El uso de elementos activos facilitan el mantenimiento de las reglas de negocio.
Los elementos activos son confiables desde el momento en que serán
automáticamente invocados cada vez que el evento apropiado sea generado por
la transacción, garantizando que todas las aplicaciones obedezcan reglas
específicas.
Mejoran el desenvolvimiento de las aplicaciones, ya que debido a la
centralización, mejores técnicas de optimización pueden ser aplicadas.
1.3.3. Fundamentos y Características.
Básicamente se han adoptado dos enfoques para resolver las necesidades de las
aplicaciones restringidas por el tiempo.
El primero consiste en escribir un programa que consulte periódicamente la BD para
determinar si ha ocurrido la situación que se espera. Es difícil de implementar porque no
es fácil determinar la frecuencia de sondeo óptima.
El segundo consiste en incorporar código en cada uno de los programas que actualizan
la BD de modo que verifiquen si se ha presentado la situación que se vigila. Pone en
peligro la modularidad y la reutilización del código.
Capítulo 1. Breve historia de los sistemas de bases de datos.
22
Las bases de datos activas manejan la vigilancia de condiciones (con disparadores y
alertas) en un nivel de abstracción que tiene tres características: su semántica está bien
definida; satisface los requerimientos de modelado y eficiencia para las aplicaciones de
BD no tradicionales, y se integra sin discontinuidad a un SGBD. [8]
1.3.4. Enfoques y Aspectos.
Hay seis aspectos que caracterizan a una BD activa:
Eficiencia. El conjunto de todas las reglas puede constituirse en un elemento que se
deberá manejar y evaluar con eficiencia cuando ocurran sucesos especificados. La
evaluación de reglas complejas bajo restricciones de tiempo es un reto cuando los
conjuntos de reglas que representan entornos dinámicos son muy grandes.
Modos de ejecución de las reglas. Las reglas pueden dispararse y ejecutarse en
diferentes modos: inmediato, diferido o separado. En el modo de ejecución inmediato, el
procesamiento de los pasos restantes de la transacción original se suspende hasta
haberse procesado por completo la regla disparada. El tiempo de respuesta y la
concurrencia pueden mejorarse si la evaluación de la condición o la ejecución de la
acción se separan de la transacción original. Si se permite que una regla dispare otra
regla como parte de su ejecución, el modelo de transacciones se hará anidado,
aumentando aún más la complejidad.
Extensiones del modelo de datos. Los SGBD activos requieren mejoras en el modelo
de datos por lo menos en dos sentidos: para especificar sucesos y para especificar
condiciones y acciones. Además de los sucesos correspondientes a las operaciones de
BD, es preciso manejar sucesos temporales o periódicos, o ambas cosas - por ejemplo
que el saldo de todas las cuentas corrientes se revise a la 5 PM de cada día -, y los
sucesos generados por el usuario o la aplicación.
Gestión de reglas. Es esencial la capacidad de manipular reglas como si fueran
cualquier otro objeto de datos del sistema, así como la capacidad para habilitarlas o
inhabilitarlas en forma individual o conjuntos de reglas. Por ejemplo, el conjunto de
reglas que se activa cuando un avión avanza por la pista de un aeropuerto se debe
inhabilitar una vez que el avión despega, y entonces es necesario habilitar otro conjunto
diferente.
Manejo de las funciones de SGBD. El SGBD activo puede efectuar las funciones de
SGBD. La gestión de restricciones, el mantenimiento de datos derivados -vistas- y las
inferencias con base en reglas son unos cuantos ejemplos.
Capítulo 1. Breve historia de los sistemas de bases de datos.
23
Interacción con partes del SGBD. A diferencia de un optimizador de consultas
convencional, en un SGBD activo no se pueden optimizar las reglas aisladas. La
optimización de reglas requiere interactuar con varios componentes del SGBD como el
gestor de transacciones, el gestor de objetos y el planificador. [8]
1.3.4.1. Reglas Activas.
Las reglas activas poseen la habilidad de imponer un comportamiento único y
consistente independiente de la aplicación que haya causado su lanzamiento y
ejecución. Debido a su capacidad de reaccionar las reglas activas son utilizadas
para codificar las estrategias que deben ser utilizadas por todas las aplicaciones.
Las reglas activas especifican como hacer y no que hacer y por lo tanto son más
difíciles de dominar que las reglas deductivas, las cuales pueden ser preferidas
para expresar propiedades invariables de los datos.
Nota. Los objetos y las reglas son especificados y diseñados por el administrador
de la base de datos mejor que por el programador de aplicación, ya que estos
elementos son comunes a todas las aplicaciones y son parte lógica del esquema
de la base de datos
1.3.4.2. SGBD Activo.
Un SGBD activo vigila continuamente el estado de la BD y reacciona
espontáneamente cuando ocurren sucesos predefinidos, en definitiva, vigila
condiciones disparadas por sucesos que representan acciones de BD -por ejemplo
actualizaciones-; si la evaluación de la condición resulta verdadera, se ejecuta la
acción. Un sistema activo ofrece tanto modularidad como respuesta oportuna. El
enfoque integrado de un SGBD activo puede considerarse como el paso lógico
más allá de los sistemas de bases de datos deductivas. Las reglas incluyen
sucesos, condiciones y acciones.
24
Capítulo 2. Sistemas de Bases de Datos Deductivas.
2.1. Conceptos Fundamentales.
2.1.1. Fundamentos.
En este capítulo analizaremos algunos sistemas de bases de datos seleccionados que,
bien se distribuyen en forma comercial, o son sistemas experimentales que han tenido
un impacto importante. No se proporcionarán los detalles completos de los sistemas
elegidos. Más bien se harán resaltar las características más importantes de los sistemas.
En consecuencia, el hecho de haber elegido un sistema no implica que se recomiende el
producto.
La contribución principal de las bases de datos deductivas es la capacidad de especificar
reglas recursivas y de proporcionar un marco de referencia para inferir información nueva
con base en las reglas especificadas.
Capítulo 2. Sistemas de Bases de Datos Deductivas.
25
Una regla tiene la forma cabeza :- cuerpo, donde :- se lee como “si y solamente si”.
Generalmente tiene con un solo predicado a la izquierda del símbolo :- (llamado cabeza,
el lado izquierdo o la conclusión de la regla) y uno o más predicados a la derecha del
símbolo :- (llamados cuerpo, lado derecho o premisa(s) de la regla).
Una regla especifica que sí una asignación o enlace particular de los valores constantes
a las variables del cuerpo (premisas de la regla), hace que todos los predicados sean
verdaderos, también hace que la cabeza (conclusión de la regla) sea verdadera usando
la misma asignación de valores constantes para las variables. En conclusión, una regla
ofrece la forma de generar hechos nuevos que se basan en hechos que ya existen.
Los mecanismos de inferencia básicos, basados en la interpretación de las reglas por la
teoría de las demostraciones, para los programas de la lógica son:
Mecanismo de inferencia ascendente (encadenamiento hacia delante).
1. El motor de inferencia comienza con los hechos y aplica las reglas para generar
nuevos hechos.
2. Los hechos generados se comprueban contra la meta del predicado.
3. La inferencia se mueve o avanza desde los hechos hacia la meta.
En este mecanismo, la estrategia de la búsqueda para generar solamente los hechos
que se relacionan con una pregunta, debe ser utilizada.
Capítulo 2. Sistemas de Bases de Datos Deductivas.
26
Mecanismo de inferencia descendente (encadenamiento hacia atrás).
1. El motor de inferencia comienza con la meta del predicado que es el objetivo de
la consulta e intenta encontrar coincidencias con las variables que conducen a
los hechos válidos en la base de datos.
2. La inferencia retrocede desde la meta prevista para determinar los hechos que
satisfarían la meta.
El mecanismo de encadenamiento hacia atrás primero busca para cualquier hecho con el
predicado superior su relación de coincidencia, si existe alguna, genera los resultados en
el mismo orden en el que se especificaron los hechos.
Por lo tanto, un programa lógico consta de:
1. Un sistema de hechos (asumiendo que éstos son todos los hechos en nuestro
mini-mundo modelado).
2. Un sistema de las deducciones permitidas (reglas de la prueba).
3. Un método de deducir.
4. Una meta a probar (o una pregunta a la respuesta). Partiendo de la existencia de
una diferencia importante entre los hechos y las reglas, ya que las reglas
especifican las cosas que son verdades si una cierta condición esta satisfecha.
Capítulo 2. Sistemas de Bases de Datos Deductivas.
27
2.2. Descripción General.
2.2.1. Datalog
2.2.1.1. Perspectiva del Producto.
Datalog es un lenguaje de consulta deductivo similar al Prolog, pero más
adecuado para aplicaciones de bases de datos.
2.2.1.2. Funcionalidad del Producto.
En Datalog, al igual que en otros lenguajes basados en la lógica, los programas se
construyen a partir de objetos básicos llamados fórmulas atómicas.
En Datalog, las fórmulas atómicas son literales de la forma p (a1,a2, …, an), donde
p es el nombre del predicado y n es el número de argumentos de dicho predicado.
Datalog incluye varios predicados integrados que también pueden servir para
construir fórmulas atómicas. Estos predicados son de dos tipos principales:
Los predicados de comparación binarios (<, <=, >, >=) sobre dominios
ordenados.
Los predicados de comparación (=, /=) sobre dominios ordenados o no
ordenados.
Éstos pueden usarse como predicados binarios con la misma sintaxis que los
demás predicados.
Los programas en Datalog pueden considerarse como un subconjunto de las
fórmulas del cálculo de predicados, que son un tanto parecidas a las fórmulas del
cálculo relacional de dominios. En Datalog, estás fórmulas se convierten primero
en lo que se conoce como forma clausal antes de expresarse en Datalog; y sólo
pueden usarse en Datalog fórmulas dadas en una forma clausal restringida,
llamadas Cláusulas de Horn.
En la forma clausal, una fórmula se debe convertir en otra fórmula con las
siguientes características:
Todas la variables de la formula están cuantificadas universalmente. Es
decir, no es necesario incluir los cuantificadores universales
explícitamente, los cuantificadores se eliminan y todas las variables de la
fórmula quedan cuantificadas implícitamente por el cuantificado universal.
Capítulo 2. Sistemas de Bases de Datos Deductivas.
28
En forma clausal, la fórmula se compone de varias cláusulas, y cada
cláusula se compone de varias literales conectadas exclusivamente por
conectores lógicos OR. Así pues, toda cláusula es una disyunción de
literales.
Las cláusulas mismas se conectan exclusivamente mediante conectores
lógicos AND, para construir una fórmula. Así pues, la forma clausal de una
fórmula es una conjunción de cláusulas.
En Datalog, las reglas se expresan como una forma restringida de cláusulas
llamadas cláusulas de Horn, en las que una cláusula puede contener cuando más
una literal positiva. Una cláusula de Horn tiene la forma:
not(P1) OR not(P2) OR … OR not(Pn) OR Q (3)
o bien la forma
not(P1) OR not(P2) OR … OR not(Pn) (4)
la cláusula de Horn (3) se puede transformar en la cláusula
P1 AND P2 AND … AND Pn => Q (5)
que se describe en Datalog como sigue:
Q :- P1, P2, …, Pn (6)
La cláusula de Horn (4) se puede transformar en
P1 AND P2 AND … AND Pn => (7)
que se describe en Datalog como sigue:
P1, P2, …, Pn. (8)
Hay dos métodos principales para definir los valores de verdad de los predicados
en los programas Datalog reales.
Los predicados definidos por hechos (o relaciones) se definen mediante una
lista de todas las combinaciones de valores (las tuplas) quehacer verdadero al
predicado.
Capítulo 2. Sistemas de Bases de Datos Deductivas.
29
Los predicados definidos por reglas (o vistas) se definen al ser la cabeza de
una o más reglas Datalog; corresponden a relaciones virtuales cuyos contenidos
puede inferir la máquina de inferencia.
La capacidad adicional que Datalog ofrece radica en la especificación de consultas
recursivas y de vistas basadas en la especificación de muchas operaciones del
álgebra relacional en forma de reglas de Datalog, que definen el resultado de
aplicar estas operaciones a las relaciones de la base de datos.
Las implementaciones de Prolog se han basado en el enfoque de encadenamiento
hacia atrás, en el que el ordenamiento de los predicados es significativo. Puesto
que Datalog se ha definido como un subconjunto de Prolog pueden usarse con
Datalog los mecanismos de inferencia para los lenguajes de programación lógica,
como los de encadenamiento hacia delante o hacia atrás. Sin embargo, si Datalog
ha de usarse en un sistema de bases de datos deductivas, convendrá definir un
mecanismo de inferencia basado en los conceptos de procesamiento de consultas
de las bases de datos relacionales. En el procesamiento de consultas relacionales,
la estrategia inherente implica una evaluación ascendente, partiendo de las
relaciones base; el orden de las operaciones se mantiene flexible y sujeto a
optimización. Por lo tanto, si una consulta sólo implica predicados definidos por
hechos, la inferencia se reduce a buscar el resultado de la consulta entre los
hechos. [8]
2.2.2. Sistema LDL (Logic Data Language).
2.2.2.1. Perspectiva del Producto.
El proyecto Logic Data Languaje (Lenguaje Lógico de Dato: LDL) de
Microelectronics and Computer Corporation (MCC) se inició en 1984.
El diseño del lenguaje LDL puede considerarse como una extensión basada en
reglas de los lenguajes basados en el cálculo de dominios. El sistema LDL ha
intentado alcanzar el poder de expresión y deducción de Prolog Sistemas de
Bases de Datos Deductivas, y al mismo tiempo igualar la facilidad de uso de QBE.
Otro reto al que se enfrentó fue el de combinar la capacidad de expresión de
Prolog con la funcionalidad y los recursos de un SGBD de propósito general. Esto
último incluye el modelado y almacenamiento de datos, así como el procesamiento
de transacciones y la optimización de consultas. MCC construyó un sistema
integrado, en vez de acoplar Prolog a bases de datos relacionales.
Capítulo 2. Sistemas de Bases de Datos Deductivas.
30
La desventaja principal que experimentaron los nuevos sistemas que acoplaron
Prolog a un SGBDR es que Prolog es un lenguaje de recorrido (navegación) en
tanto que en los SGBDR el usuario formula una consulta correcta y deja al sistema
la optimización de su ejecución. La naturaleza del recorrido de Prolog es evidente
en el ordenamiento de las reglas y los objetivos para lograr una ejecución y
terminación óptimas. Se dispone de dos opciones:
Hacer que Prolog sea más “parecido a las bases de datos” mediante la
adición de características de gestión de bases de datos por recorrido.
Modificar Prolog para convertirlo en un lenguaje de lógica declarativo de
aplicación general.
En LDL se eligió la segunda opción produciendo un lenguaje que es diferente de
Prolog en sus construcciones y estilo de programación.
LDL difiere del estilo de programación Prolog / Datalog en los siguientes aspectos:
Las reglas se compilan en LDL.
Existe una noción de “esquema” de la base de hechos en LDL en el
momento de la compilación. Esta base se actualiza libremente en el
momento de la ejecución. Prolog, en cambio, trata los hechos y las reglas
de manera idéntica, y somete los hechos a interpretación cuando son
modificados.
LDL no sigue la técnica de resolución y unificación que se emplea en los
sistemas Prolog basados en encadenamiento hacia atrás.
El modelo de ejecución de LDL es más simple, basado en la operación de
comparación y el cálculo de “menor punto fijo”. Estos operadores, a su
vez, utilizan extensiones simples del álgebra relacional.
Por todo lo anterior, LDL proporciona lengua declarativa basada en las tecnologías
de las bases de datos y la lógica para apoyar datos avanzados y usos basados en
el conocimiento.
2.2.2.2. Funcionalidad del Producto.
Las primeras implementaciones del LDL, completadas en 1987, se basaban en un
lenguaje llamado FAD. El prototipo de implementación actual, concluida en 1988,
se llama SALAD y está sufriendo cambios adicionales al probarse con las
aplicaciones de la “vida real”. El prototipo actual es un sistema portátil eficiente
Capítulo 2. Sistemas de Bases de Datos Deductivas.
31
para UNIX que supone una interfaz de una sola tupla tipo “obtener el siguiente”
entre el programa LDL compilado y un gestor de hechos subyacente.
Dada la filosofía de diseño de LDL de combinar el estilo declarativo de los
lenguajes relacionales con el poder expresivo de Prolog, las construcciones de
Prolog como negación, conjunto-de, actualizaciones y recortar, se han desechado.
En su lugar, se extendió la semántica declarativa de las cláusulas de Horn para
manejar términos complejos mediante el uso de símbolos de función, llamados
factores en Prolog.
LDL ofrece una construcción IF_THEN_ELSE de semántica declarativa nítida, para
poder expresar claramente e implementar con eficiencia reglas mutuamente
disyuntivas. Por añadidura, cuenta con un predicado “choice” (“elección”) no
orientado a procedimientos para situaciones en las que cualquier respuesta será
satisfactoria. El predicado de elección puede servir para obtener una respuesta
única, en vez de la solución con todas las respuestas que representa la
contestación por omisión de las consultas LDL. En la semántica declarativa de
LDL, la negación se ha tratado empleando estratificación y no determinismo, lo
que se logra a través de la misma construcción llamada “choice”.
Aunque la semántica de LDL se define de manera ascendente, el implementador
puede usar cualquier ejecución que se apegue a esta semántica declarativa. En
particular, la ejecución puede ser ascendente o descendente, o bien híbrida. Estas
opciones permiten al compilador / optimizador ser selectivo al adaptar los modos
de ejecución más apropiados para el programa dado.
Como primera aproximación, es fácil concebir la ejecución LDL como un cálculo
ascendente que emplea el álgebra relacional. El compilador de LDL puede
seleccionar e implementar reglas con cualquiera de los siguientes cuatro modos de
ejecución:
La ejecución segmentada.
La ejecución segmentada perezosa.
La ejecución materializada perezosa.
La ejecución materializada.
Las consultas LDL representan una nueva serie de problemas, que surgen de las
siguientes observaciones:
Capítulo 2. Sistemas de Bases de Datos Deductivas.
32
En primer lugar, el modelo de datos se ha mejorado para incluir objetos complejos
(como jerarquías y datos heterogéneos para un mismo atributo).
En segundo lugar, se necesitan operadores nuevos no sólo para operar sobre
datos complejos, sino también para efectuar nuevas operaciones como la
recursión y la negación. Así, la complejidad de los datos, además del conjunto de
operaciones, subraya la necesidad de contar con información estadística adicional
de la base de datos y estimaciones nuevas de costos. [6]
2.2.3. Sistema CORAL.
2.2.3.1. Perspectiva del Producto.
El sistema CORAL, creado en la Universidad de Wisconsin en Maidison aprovecha
las experiencias adquiridas en el proyecto LDL. Al igual que LDL, el sistema
provee un lenguaje declarativo basado en las cláusulas de Horn con una
arquitectura abierta. Sin embargo, hay muchas diferencias importantes, tanto en el
lenguaje como en su implementación. El sistema CORAL puede considerarse
como un lenguaje de programación que combina características importantes de
SQL y Prolog.
El Coral es una lengua declarativa modular de la pregunta lenguaje/programación
que apoya cláusulas generales del cuerpo con los términos complejos tales como
fijar-agrupar, agregación, negación, y las relaciones con las tuplas que contienen
variables (cuantificador universal). Una característica única del CORAL es que
proporciona una amplia gama de estrategias de la evaluación y permite a los
usuarios adaptar la ejecución de un programa con anotaciones de alta nivel.
2.2.3.2. Funcionalidad del Producto.
Desde el punto de vista del lenguaje, CORAL adapta el elemento de agrupación de
conjuntos, del LDL para acercarse más al elemento GROUP BY de SQL.
La mayor complejidad de las consultas en un lenguaje recursivo dificulta la
optimización, y el empleo de anotaciones a menudo significa una diferencia
importante en la calidad del plan de evaluación optimizado.
CORAL maneja una clase de programas con negación y agrupación que es
estrictamente más grande que la clase de programas estratificados. El problema
de lista de materiales, en el que el costo de una parte compuesta se define como
la suma de los costos de todas las partes atómicas, es un ejemplo de problema
que requiere esta generalidad adicional.
Capítulo 2. Sistemas de Bases de Datos Deductivas.
33
CORAL esta más cerca de Prolog que de LDL en cuanto al manejo de tuplas no
base, así la tupla equal (X,X) se puede guardar en la base de datos y denota que
toda tupla binaria en la que el primero y el segundo valores de campos sean
iguales, está en la relación llamada equal. Desde el punto de vista de la
evaluación, las principales técnicas de evaluación de CORAL se basan en una
evaluación ascendente, muy distinta de la evaluación descendente de Prolog. Sin
embargo, CORAL también ofrece un modo de evaluación descendente similar al
de Prolog.
Puesto que se manejan muchas semánticas y métodos de evaluación distintos,
CORAL cuenta con un mecanismo de módulos para organizar los programas.
Cada módulo exporta un predicado de consulta y puede considerarse simplemente
como una definición de dicho predicado. Un módulo contiene una o más reglas
que definen el predicado exportado y tal vez algunos predicados locales. La
semántica y la evaluación de un módulo puede controlarse agregando anotaciones
para cada módulo, y los controles de cada uno completamente independientes de
los de otros módulos. Esto permite mezclar la evaluación descendente en un
módulo con la evaluación ascendente en otro.
Desde la perspectiva de la implementación, CORAL lleva a cabo varias
optimizaciones para manejar de manera eficiente las tuplas no base, además de
usar técnicas como la de patrones mágicos para incluir selecciones en consultas
recursivas, incluir proyecciones, y optimizaciones especiales de diferentes clases
de programas lineales. También proporciona una forma eficiente de calcular
consultas no estratificadas. Se utiliza un enfoque de “compilación somera”, por el
cual el sistema interpreta el plan compilado durante la ejecución. Eso hace que la
compilación de programas, incluso de los muy grandes, sea extremadamente
rápida. CORAL utiliza el gestor de almacenamiento EXODUS para manejar las
relaciones residentes en disco. También cuenta con una buena interfaz con C++ y
es extensible, lo que permite al usuario adaptar el sistema a aplicaciones
especiales añadiendo nuevos tipos de datos o implementaciones de relaciones,
por ejemplo. Una característica interesante es el paquete de explicación, con el
cual el usuario puede examinar gráficamente la forma como se genera un hecho;
esto resulta útil para depurar y para proveer explicaciones. En resumen, CORAL
maneja consultas declarativas, extendiendo los lenguajes de consulta relacionales
y los programas de lógica, pero también es un lenguaje de programación
avanzado para aplicaciones que manejan muchos datos. La tendencia actual es
hacia la extensión del modelo de datos con características de orientación a
objetos, para crear un sistema deductivo y orientado a objetos. [8]
Capítulo 2. Sistemas de Bases de Datos Deductivas.
34
2.2.4. Proyecto NAIL!.
2.2.4.1. Perspectiva del Producto.
El proyecto NAIL! (Not Another Implementation of Logic!: ¡no una implementación
de lógica más!) se inició en Stanford en 1985, el objetivo inicial era estudiar la
optimización de la lógica mediante el modelo de “todas las soluciones” orientado a
bases de datos.
2.2.4.2. Funcionalidad del Producto.
En colaboración con el grupo MCC, este proyecto produjo el primer artículo sobre
los conjuntos mágicos y el primer trabajo sobre recursiones regulares. Por
añadidura, aportó muchas contribuciones importantes para el manejo de la
negación y la agregación en las reglas lógicas. También se desarrollaron la
negación estratificada, la negación bien fundada y la negación modularmente
estratificada en relación con este proyecto.
Se construyó un prototipo de sistema inicial, que posteriormente se abandonó
porque el paradigma puramente declarativo resultó inadecuado para muchas
aplicaciones. El sistema revisado utiliza un lenguaje central, llamado GLUE, que se
compone esencialmente de reglas lógicas individuales, con la capacidad de
enunciados SQL, envueltas en construcciones de lenguaje convencionales como
ciclos, procedimientos y módulos. El lenguaje NAIL! Original se convirtió en un
mecanismo de vistas para GLUE; permite especificaciones totalmente declarativas
en situaciones en que esto es apropiado.
Debido a las siguientes desventajas o problemas a los que se ha enfrentado la
implementación de las bases de datos deductivas, en la actualidad los sistemas de
gestión de bases de datos más importantes o más utilizados en el mercado tales
como SQL Server, Oracle, DB2, Sybase, Informix, etc, carecen de alguna
característica deductiva. [8]
Encontrar criterios de interpretación para una ley dada como regla de
deducción o como regla de coherencia.
Replantear un contexto deductivo
Desarrollar procedimientos eficaces de deducción.
Capítulo 2. Sistemas de Bases de Datos Deductivas.
35
2.2.5. Conclusiones.
Ninguno de los sistemas gestores de bases de datos que vamos a analizar es perfecto.
Cada uno tiene sus defectos y sus virtudes. En la siguiente tabla podemos ver un
resumen de las características técnicas que cumple cada uno. Ponemos solo las más
relevantes, aunque hay características que dicen cumplen todos, cada uno las cumple a
su manera.
Lenguaje
Características/ Técnicas
Datalog Sistema
LDL
Sistema
CORAL
Proyecto
NAIL!
Basado Cálculo de Dominios
Lenguaje Lógico- Declarativo
Tipos de
Inferencia
Inferencia Ascendente
Inferencia Descendente
Orden de especificación de los hechos y reglas
Tipos de
Operaciones
Comparación
Aritméticas
Relacionales
Manejo de consultas recursivas
Manejo de Agregación
Manejo de Agrupación
Manejo de Negación
Programación Modular
36
Capítulo 3. Sistemas de Bases de Datos Activas.
3.1. Conceptos Fundamentales.
3.1.1. Fundamentos.
En este capítulo se presentan sistemas de bases de datos en los que se pueden
especificar reglas activas. Se muestra el modelo evento-condición-acción, en el que las
reglas son disparadas automáticamente por eventos, iniciando las acciones
especificadas en la declaración de la regla si se cumple cierta condición.
Las bases de datos convencionales no procesan datos sin peticiones explícitas por los
usuarios o los programas de uso. Una base de datos activa puede iniciar procesos
automáticamente cuando su estado alcanza cierta condición predefinida. El sistema
activo de la base de datos es definido como sistema de gerencia de la base de datos
que permite que los usuarios especifiquen las acciones que se tomarán
automáticamente, sin la intervención del usuario, cuando se presentó cierta condición.
La evolución en el tiempo de una base de datos se define por una secuencia de estados
donde la transición de una estado al siguiente se produce por la ejecución de una
transacción del usuario: secuencia de operaciones de manipulación de la base de datos
(INSERT, DELETE, UPDATE,…).
En general, la base de datos debe evolucionar independientemente de la intervención
del usuario como respuesta a la ocurrencia de un suceso o situación (condición).
Reglas de comportamiento.
Las respuestas automáticas de bases de datos activas pueden ser declaradas usando
las cláusulas de las reglas de comportamiento Evento – Condición - Acción (ECA) :
La cláusula del evento el supervisar de cierta transacción (un evento) en una
base de datos.
La cláusula de la condición que describe una expresión lógica se evalúe que
cuando ocurre el acontecimiento.
La cláusula de la acción que se ejecutará cuando la cláusula de la condición
está satisfecha.
Las cláusulas de las reglas de comportamiento dentro de un SGBD actúan de la
siguiente forma:
Evento: especifica la causa que activa la regla.
Capítulo 3. Sistemas de Bases de Datos Activas.
37
Condición: se evalúa cuando una regla activada es seleccionada por
el SGBD para su ejecución.
Acción: se ejecuta cuando una regla ha sido seleccionada por el
SGBD y su condición se ha evaluado como cierta.
Eventos
Tipos de Eventos:
Operaciones de actualización de bases de datos: INSERT,
DELETE, UPDATE.
Operaciones de consulta de la base de datos: SELECT.
Tiempo: un instante de tiempo, un período de tiempo, …
Definidos por las aplicaciones.
Composición de Eventos:
Composición Lógica: AND, OR, NOT, …
Secuencia de eventos.
Composición temporal.
Parametrización de Eventos:
Capítulo 3. Sistemas de Bases de Datos Activas.
38
Parametrización Explícita:
Los eventos pueden parametrizarse con referencias a datos
relacionados con el evento (datos actualizados, datos consultados,
instante de tiempo, etc.)
Parametrización Implícita:
Los parámetros del evento se inicializan con valores al producirse el
evento y ser activada la regla.
Condiciones
Tipos de condiciones:
Expresiones lógicas del lenguaje SQL: cláusula WHERE.
Consulta a la base de datos. (si el resultado de la consulta es
vacío la condición no se cumple y viceversa).
Procedimientos de tipo lógico en un lenguaje de programación.
Instanciación de la condición:
La condición se puede hacer referencia a los parámetros del
evento instanciándose de esta forma la condición cuando se
activa la regla.
Parametrización de la condición:
La condición puede parametrizarse con referencias de datos
relacionados con la condición.
Los parámetros de la condición se inicializan con valores
obtenidos durante la evaluación de la condición cuando la regla
es seleccionada por el SGBD.
Acciones
Tipos de acciones:
Operaciones de actualización de la base de datos: INSERT,
DELETE, UPDATE.
Operaciones de consulta de la base de datos: SELECT.
Operaciones de control de transacciones: ROLLBACK,
COMMIT.
Capítulo 3. Sistemas de Bases de Datos Activas.
39
Llamadas a procedimientos escritos en un lenguaje de
programación.
Instanciación de la acción:
En la acción se puede hacer referencia a los parámetros del
evento (respuesta de la condición) instanciándose de esta forma
la acción cuando la regla se activa (respuesta es evaluada por
el SGBD).
Composición de acciones:
Secuencia de acciones.
Modelo de ejecución de las reglas
El modelo de ejecución de las reglas se basa en los siguientes conceptos:
Activación: una regla se activa cuando se produce su evento.
Evento
Evento real: operación de transacción (ORACLE, INGRES)
Evento virtual: efecto global de la transacción (STARBUST).
Evaluación: selección de una regla activada y evaluación de su condición.
Capítulo 3. Sistemas de Bases de Datos Activas.
40
Ejecución: ejecución de la acción de una regla evaluada como cierta.
Estas tres funciones no se realizan necesariamente de forma contigua.
Acoplo evento-condición: determina cuándo se evalúa la condición
(evaluación) con respecto a la ocurrencia del evento (activación).
Inmediato: la condición se evalúa inmediatamente después de
producirse el evento que activa la regla.
Diferido: la condición se evalúa en algún instante posterior a la
ocurrencia del evento que activa la regla.
Capítulo 3. Sistemas de Bases de Datos Activas.
41
Acoplado condición-acción: determina cuándo se ejecuta la acción (ejecución)
con respecto a la evaluación de la condición (evaluación).
Inmediato: la acción se ejecuta inmediatamente después de
evaluarse la condición de la regla.
Diferido: la acción se ejecuta en algún instante posterior a la
evaluación de la condición de la regla.
Resolución de conflictos
Al ejecutarse los eventos pueden presentarse varios conflictos:
Causas de conflictos:
Varias reglas son activadas por el mismo evento.
Varios eventos han tenido lugar antes de ejecutar el
procesamiento de reglas.
Resolución de conflictos:
Seleccionar las reglas al azar (INGRES, ORACLE).
Definir prioridades sobre las reglas cuando estas son creadas
(STARBUST).
Otros criterios (fecha de creación, …)
Terminación
La terminación de la ejecución de eventos no siempre es satisfactoria, en ocasiones ésta
nunca se presenta.
Causas de la falta de terminación:
Encadenamiento de las reglas.
Resolución de la falta de terminación:
Fijar un límite al número de reglas que pueden ser ejecutadas
durante la ejecución del procesamiento de reglas.
Definir restricciones sintácticas sobre las reglas que aseguran la
terminación.
Otros criterios.
Capítulo 3. Sistemas de Bases de Datos Activas.
42
Lenguaje de definición de reglas
Los lenguajes de definición de reglas están conformados por :
Sentencias para la creación, modificación y borrado de reglas.
Definición de prioridades entre reglas.
Sentencias para habilitar y deshabilitar una regla temporalmente.
Mecanismos para la estructuración de las reglas.
Las Reglas se clasifican en las reglas de la consistencia y las reglas de la
automatización.
La regla de la consistencia consiste en un disparador que tenga un predicado
que pueda llegar a ser verdad cuando se viola un constreñimiento. La regla, por
lo tanto, permite a las bases de datos manejar los apremios.
La regla de la automatización ejecuta simplemente el procedimiento reservado
que no tiene ninguna preocupación por apremios de la integridad después de
que las reglas de la consistencia determinen la modificación propuesta para ser
válidas. La regla de la consistencia es el constructor dedicado para los apremios
de la integridad separados de los disparadores generales.
3.2. Conceptos Fundamentales.
3.2.5. HIPAC
3.2.1.1. Perspectiva del Producto.
HiPAC, que significa High Performance Active database system (sistema de bases de
datos activo de alto rendimiento), fue un proyecto de investigación que se concentró en
la gestación de datos activos restringidos por el tiempo.
El proyecto de HiPAC comenzado en 1987 cuando había muy poca investigación sobre
las bases de datos activas.
HiPAC fue financiado por el Defense Advanced Research Projects Agency y el centro del
desarrollo del aire de Roma.
HiPAC fue desarrollado originalmente en CCA (división tecnológica avanzada de
información de Computer Corporation de América), y emigrado más adelante a Xerox
avanzó el centro de la tecnología de información.
Capítulo 3. Sistemas de Bases de Datos Activas.
43
3.2.1.2. Funcionalidad del Producto.
El modelo de conocimientos de HiPAC incluía primitivas para sucesos, condiciones y
acciones, y formulaba la noción de “reglas como objetos de primera clase”. En el modelo
de ejecución, se investigó como interactuaban la ejecución de reglas y la ejecución
convencional de transacciones; se crearon modos de acoplamiento y algoritmos para
manejar reglas con varios modos de acoplamiento. Se exploraron varias cuestiones más
como parte del proyecto HiPAC:
Una arquitectura para un SGBD activo.
La combinación de procesamiento en tiempo real con bases de datos.
La optimización de múltiples consultas.
El modelado y la evaluación del rendimiento de diversos modos de
acoplamiento.
Se diseño un mecanismo.
HiPAC está parado para el sistema activo de la base de datos del alto rendimiento.
Fue orientado originalmente en el desarrollo de usos orientados al objeto event-driven
donde está crítica la respuesta oportuna a las situaciones supervisadas.
Los ejemplos de tales usos eran gerencia de la energía y de la comunicacio'n-red,
control químico de la planta, mandos de vuelo, gerencia de la batalla, control del hacer
compras-piso, y el negociar automatizado.
Había un análisis de requisitos muy extenso de estos usos e HiPAC es quizás el sistema
más general y más cuidadoso de la regla de la base de datos con todo propuesto.
HiPAC tiene una separación clara de los acontecimientos, condiciones y las acciones y
el ECA-Model que fue introducido por los autores de HiPAC se convirtieron en el
favorable estilo de la forma de reglas activas.
3.2.2. Postgres
3.2.2.1. Perspectiva del Producto.
El sistema gestor de bases de datos conocido como PostgresSQL (y brevemente
llamado Postgres95) está derivado del paquete Postgres escrito en Berkeley. Con cerca
de una década de desarrollo tras él, PostgresSQL es el gestor de bases de datos de
código abierto más avanzado hoy en día, ofreciendo control de concurrencia multi-
versión, soportando casi toda la sintaxis SQL (incluyendo subconsultas, transacciones, y
Capítulo 3. Sistemas de Bases de Datos Activas.
44
tipos y funciones definidas por el usuario), contando también con un amplio conjunto de
enlaces con lenguajes de programación (incluyendo C, C++, Java, Perl, tcl y python).
Los focos en clases múltiples de la regla se adaptaron para los sistemas
específicos de usos.
Los disparadores fueron desarrollados para poner opiniones, mecanismos de la
herencia, y apremios de la integridad en ejecución.
Una versión comercial llamada ILLUSTRA, está disponible desde 1994
3.2.2.2. Funcionalidad del Producto.
El proyecto Postgres de Berkeley
La implementación del DBMS Postgres comenzó en 1986. Los conceptos iniciales para
el sistema fueron presentados en The Design of Postgres y la definición del modelo de
datos inicial apareció en The Postgres Data Model. El diseño del sistema de reglas fue
descrito en ese momento en The Design of the Postgres Rules System. La lógica y
arquitectura del gestor de almacenamiento fueron detalladas en The Postgres Storage
System. Postgres ha pasado por varias revisiones importantes desde entonces. El
primer sistema de pruebas fue operacional en 1987 y fue mostrado en la Conferencia
ACM-SIGMOD de 1988. Se lanzó la versión 1, descrita en The Implementation of
Postgres, a unos pocos usuarios externos en Junio de 1989. En respuesta a una crítica
del primer sistema de reglas, éste fue rediseñado y la Versión 2, que salió en Junio de
1990, lo incorporaba. La Versión 3 apareció en 1991 y añadió una implementación para
múltiples gestores de almacenamiento, un ejecutor de consultas mejorado y un sistema
de reescritura de reglas nuevas. En su mayor parte, las siguientes versiones hasta el
lanzamiento de Postgres95 se centraron en mejorar la portabilidad y la fiabilidad.
Postgres forma parte de la implementación de muchas aplicaciones de investigación y
producción. Entre ellas: un sistema de análisis de datos financieros, un paquete de
monitorización de rendimiento de motores a reacción, una base de datos de seguimiento
de asteroides y varios sistemas de información geográfica. También se ha utilizado como
una herramienta educativa en varias universidades. Finalmente, Illustra Information
Technologies (posteriormente absorbida por Informix) tomó el código y lo comercializó.
Postgres llegó a ser el principal gestor de datos para el proyecto científico de
computación Sequoia 2000 a finales de 1992.
El tamaño de la comunidad de usuarios externos casi se duplicó durante 1993. Pronto se
hizo obvio que el mantenimiento del código y las tareas de soporte estaban ocupando
Capítulo 3. Sistemas de Bases de Datos Activas.
45
tiempo que debía dedicarse a la investigación. En un esfuerzo por reducir esta carga, el
proyecto terminó oficialmente con la Versión 4.2.
Postgres95
En 1994, Andrew Yu y Jolly Chen añadieron un interprete de lenguaje SQL a Postgres.
Postgres95 fue publicado a continuación en la Web para que encontrara su propio hueco
en el mundo como un descendiente de dominio público y código abierto del código
original Postgres de Berkeley.
El código de Postgres95 fue adaptado en ANSI C y su tamaño reducido en un 25%.
Muchos cambios internos mejoraron el rendimiento y la facilidad de mantenimiento.
Postgres95 v.1.0.x se ejecutaba en torno a un 30-50% más rápido en el Wisconsin
Benchmark comparado con Postgres v.4.2. Además de corrección de errores éstas
fueron las principales mejoras:
El lenguaje de consultas Postquel fue remplazado con SQL (implementado en el
servidor). Las subconsultas no fueron soportadas hasta PostgresSQL, pero
podían ser emuladas en Postgres95 con funciones SQL definidas por el usuario.
Las funciones agregadas fueron reimplementadas. También se añadió una
implementación de la cláusula GROUP BY. La interfaz libpq permaneció
disponible para programas escritos en C.
Además del programa de monitorización, se incluyó un nuevo programa (psql)
para realizar consultas SQL interactivas usando la librería GNU readline.
Una nueva librería de interfaz, libpgtcl, soportaba clientes basados en TCL. Un
shell de ejemplo, pgtclsh, aportaba nuevas órdenes Tcl para interactuar con el
motor Postgres95 desde programas tcl.
Se revisó la interfaz con objetos grandes. Los objetos grandes de Inversión
fueron el único mecanismo para almacenar objetos grandes (el sistema de
archivos de Inversión fue eliminado).
Se eliminó también el sistema de reglas a nivel de instancia, si bien las reglas
siguieron disponibles como reglas de reescritura.
Se distribuyó con el código fuente un breve tutorial introduciendo las
características comunes de SQL y de Postgres95.
Se utilizó GNU make (en vez de BSD make) para la compilación. Postgres95
también podía ser compilado con un gcc sin parches (al haberse corregido el
problema de alineación de variables de longitud doble).
Capítulo 3. Sistemas de Bases de Datos Activas.
46
PostgresSQL
El 1996, se hizo evidente que el nombre “Postgres95” no resistía el paso del tiempo. Se
eligió un nuevo nombre, PostgresSQL, para reflejar la relación entre el Postgres original
y las versiones más recientes con capacidades SQL. Al mismo tiempo, se hizo que lo
números de versión partieran de la 6.0. volviendo a la secuencia seguida originalmente
por el proyecto Postgres.
Durante el desarrollo de Postgres95 se hizo hincapié en identificar y entender los
problemas en el código del motor de datos. Con PostgresSQL, el énfasis ha pasado a
aumentar características y capacidades, aunque el trabajo continúa en todas las áreas.
Las principales mejoras en PostgresSQL incluyen:
Los bloqueos de tabla han sido sustituidos por el control de concurrencia multi-
versión, el cual permite a los accesos de sólo lectura continuar leyendo datos
consistentes durante la actualización de registros, y permite copias de seguridad
en caliente desde pg_dump mientras la base de datos permanece disponible
para consultas.
Se han implementado importantes características del motor de datos, incluyendo
subconsultas, valores por defecto, restricciones a valores en los campos
(constraints) y disparadores (triggers).
Se han añadido funcionalidades en línea con el estándar SQL92, incluyendo
claves primarias, identificadores entrecomillados, forzado de tipos cadenas
literales, conversión de tipos y entrada de enteros binarios y hexadecimales.
Los tipos internos han sido mejorados, incluyendo nuevos tipos de fecha/hora de
rango amplio y soporte para tipos geométricos adicionales.
La velocidad del código del motor de datos ha sido incrementada
aproximadamente en un 20-40%, y su tiempo de arranque ha bajado el 80%
desde que la versión 6.0 fue lanzada.
Postgres es un producto de código abierto. Como tal, depende de la comunidad de
usuarios para su soporte. [8], [10]
3.2.3. Proyecto Starburst
3.2.3.1. Perspectiva del Producto.
El Proyecto Starburst es un prototipo extensible relacional DBMS desarrollado por IBM
en el Centro de Investigación Almaden. Las extensiones de Starburst permiten que el
Capítulo 3. Sistemas de Bases de Datos Activas.
47
sistema de base de datos este preparado para aplicaciones de bases de datos
avanzadas y no para aplicaciones de bases de datos tradicionales.
Una de las extensiones de Starburst es su regla de integridad de bases de datos de
procesamiento fácil llamado Sistema de Reglas de Starburst.
La semántica cuidadosamente especificada de la lengua y una puesta en
práctica completamente integrada.
Integrado firmemente en la gerencia de la transacción.
Trata problemas de interferencia, de la terminación y de programar de la regla de
los sistemas de la regla.
Se pone en ejecución el sistema de la regla de Starburst.
Otra regla de extensión de Starburst es Alert.
3.2.3.2. Funcionalidad del Producto.
Las reglas del lenguaje difieren en su mayoría de otras reglas de lenguajes de bases de
datos activas, en que están basadas sobre una ejecución semántica que permiten tanto
la limpieza de definición como la flexibilidad. La implementación del sistema de reglas de
Starburst fue completada fácilmente y en gran escala sobre sus características
extensivas. Los procesos de reglas de Starburst difieren en su mayoría de otros
sistemas de reglas activas en que éstas son completamente implementadas y su
completa integridad dentro de todos los aspectos de procesamiento de bases de datos,
incluyen consultas y procesamiento de transacciones, control de concurrencia,
recuperación (rollback), manejo de errores y automatización.
La sintaxis de las Reglas del Lenguaje de Starburst están basadas en la versión
extendida de SQL soportada por el sistema de base de datos Starburst.
Las reglas incluyen 5 comandos para la definición y manipulación de reglas:
CREATE
ALTER
DEACTIVATE
ACTIVATE
DROP
La sintaxis del comando CREATE:
create rule name on table
Capítulo 3. Sistemas de Bases de Datos Activas.
48
When triggering-operations
[ if condition ]
then action-list
[ precedes rule-list ]
[ follows rule-list ]
El name es el nombre de la regla, y cada regla es definida sobre una tabla.
Los componentes de una regla pueden cambiar después de que fueron definidas. Esta
es terminada usando la regla ALTER. La sintaxis de este comando es:
alter rule name on table
[ if condition ]
[ then action-list ]
[ precedes rule-list ]
[ follows rule-list ]
[ nopriority rule-list ]
Una regla puede ser borrada usando el comando DROP:
drop rule name on table
También pueden desactivarse reglas usando el comando DEACTIVATE:
deactivate rule name on table
Para reactivar una regla que ha sido desactivada, se usa el comando ACTIVATE:
activate rule name on table
A partir de las reglas del lenguaje especificadas podemos ver que las reglas del lenguaje
de Starburst son flexibles y generales.
3.2.4. Sybase
3.2.4.1. Perspectiva del Producto.
Sybase, Inc. Fundada en 1984 con el objetivo de brindar DBMS’s distribuidos de alto
desempeño al mercado. La necesidad de integrar una gran variedad de aplicaciones con
múltiples fuentes de datos es en la actualidad un claro requerimiento comercial. Desde
septiembre de 1989 Sybase introduce el Open Server, un producto que extiende las
capacidades distribuidas de Sybase a fuentes de datos heterogéneas. Este producto
Capítulo 3. Sistemas de Bases de Datos Activas.
49
complementa el Open Client, un API que se usa para enviar SQL o RPC’s a un servidor
SQL. Juntos forma la interfaz Cliente/Servidor.
3.2.4.2. Funcionalidad del Producto.
Sybase se basa en el modelo relacional y soporta acceso programado e interactivo al
servidor de SQL o alguna aplicación Open Server. El lenguaje de consultas básicas es
SQL. Múltiples secuencias SQL pueden aumentarse con la programación de
constructores, tales como lógica condicional, llamadas a procedimientos y variables
locales, estos pueden combinarse en un objeto de base de datos llamado un
procedimiento de almacenamiento. Los procedimientos pueden regresar hileras de datos
y mensajes de error, además de regresar valores en variables de programación en el
programa de aplicación.
El servidor SQL también soporta disparadores como objetos independientes en la BD,
estos tiene las capacidades de los procedimientos con tres extensiones importantes.
Ellos no pueden ejecutarse directamente, sólo responden al cumplimiento de una
condición.
Un disparador puede restaurar o modificar los resultados de una transacción del usuario.
El disparador puede ver los cambios hechos a los datos.
Además el servidor abierto de Sybase provee un método consistente para recibir
requerimientos SQL o RPC’s desde una aplicación basada en el conjunto de
herramientas de SQL Sybase o desde una aplicación que usa la interfaz de cliente
abierto de Sybase.
Sybase soporta actualizaciones distribuidas que se replican en localizaciones múltiples.
TPC (Two-Phase Commit Protocol) se usa para mantener la consistencia de las
transacciones.
3.2.5. Interbase
3.2.5.1. Perspectiva del Producto.
InterBase fue concebido y creado originalmente por un grupo de ex-empleados de la
Digital Equipment Corporation [DEC], los cuales querían desarrollar un SGDBR
innovador que ofreciera beneficios substancialmente mayores que otras bases de datos
existentes. InterBase comenzó su vida en 1985 con el nombre de Groton Database
Systems, siendo renombrado poco después como InterBase. Ashton Tate adquirió el
Capítulo 3. Sistemas de Bases de Datos Activas.
50
producto en 1991, y Borland lo adquirió a su vez en 1992 como parte de la compra de
Ashton Tate.
A lo largo de su desarrollo, InterBase ha introducido exitosamente una serie de avances
tecnológicos. Entre estos se encuentra la Arquitectura Multi-Generacional, Confirmación
en Dos Fases Automática, Sombreado de Bases de Datos, Objetos Binarios Grandes
[BLOBs], Indices Dispersos con Representación Binaria, Matrices Multi-dimensionales,
Alertadores de Eventos y el primer controlador nativo JDBC.
La mayor parte de los sistemas SGBDR existentes no pueden ofrecer tecnologías
equivalentes. Por ejemplo, la arquitectura de SQL Server utiliza una combinación de
bloqueos de páginas, tablas e índices para permitir el acceso concurrente a sus datos.
SQL Server permite la confirmación en dos fases pero necesita ayuda por parte del
programador para gestionar las secuencias de confirmación y de anulación. SQL Server
ofrece acceso a BLOBs pero su alcance es muy limitado y es significativamente más
lento que el acceso a BLOBs de InterBase.
InterBase definió un estándar industrial desde su lanzamiento en 1986 al ser capaz de
almacenar sonido, gráficos y cualquier tipo de información binaria directamente en la
Base de Datos. Las aplicaciones InterBase para el World Wide Web y sistemas
telefónicos hacen un uso extensivo de los BLOB´s para ofrecer soluciones multimedia.
Además el servidor puede hacer automáticamente uso de "filtros para BLOB´s", estos
filtros son ideales para comprimir y traducir datos para adecuarse a las necesidades de
cualquier aplicación.
InterBase proporciona altas prestaciones para aplicaciones de misión crítica, tales como:
operaciones en Mercados de Valores, Aplicaciones Hospitalarias y Farmacéuticas,
aplicaciones aerospaciales y en general cualquier tipo de aplicación de Gestión
Empresarial en la que la seguridad de la información sea un elemento crítico. Además
InterBase es la primera Base de Datos que incluye soporte JDBC, para aplicaciones
JAVA multiplataforma.
3.2.5.2. Funcionalidad del Producto.
Escalabilidad.
InterBase ofrece escalabilidad a todos los entornos MS Windows, Novell NetWare y
plataformas UNIX. Las aplicaciones desarrolladas sobre Interbase son absolutamente
independientes de la plataforma. De esta manera, si usted realiza un desarrollo en una
plataforma determinada, siempre podrá realizar una migración sin esfuerzo a una
plataforma superior o de mayor rendimiento cuando lo necesite. Todas las Bases de
Capítulo 3. Sistemas de Bases de Datos Activas.
51
Datos y objetos desarrollados inicialmente podrán ser trasladados inmediatamente y sin
modificaciones a cualquier plataforma soportada por Interbase.
Arquitectura Multi-Generacional.
El Servidor InterBase está construido sobre una Arquitectura Multigeneracional (MGA)
que incluye un motor de versiones capaz de asegurar la más alta disponibilidad de la
información tanto para usuarios de procesos transaccionales como para usuarios de
aplicaciones de Soporte de Decisiones. Los servidores tradicionales de bases de datos
soportan, en cambio, un modelo de Proceso de Transacciones en Línea (OLTP)
caracterizado por una arquitectura orientada a optimizar el rendimiento para un gran
volumen de transacciones simples y muy cortas. InterBase, al tiempo que soporta este
modelo tradicional OLTP, está también optimizado para un tipo de transacciones
concurrentes de alta duración y tamaño. Estas transacciones son las que típicamente
requieren las aplicaciones de Soporte de Decisiones. El resultado global es que
InterBase ofrece un rendimiento superior en la mayor parte de las situaciones reales a
las que se enfrentan las aplicaciones corporativas.
El Motor de Versiones de InterBase permite que las transacciones no requieran el
bloqueo de los registros que están en uso, los escritores nunca bloquean a los lectores
en el sistema de transacciones. Al contrario que en otras Bases de Datos, el sistema de
transacciones sin bloqueo de InterBase no requiere programación adicional y siempre
ofrece resultados consistentes en las consultas que se realicen a la base de datos. De
esta manera, las transacciones típicas de OLTP y las de las aplicaciones de Soporte de
Decisiones, pueden coexistir y ofrecer siempre información consistente.
Alta confiabilidad en todas sus aplicaciones.
InterBase fue la pionera del concepto de Base de Datos Activa al introducir una
tecnología avanzada de automatización en el KERNEL del servidor. La Base de Datos
Activa, incorpora alertadores de eventos, procedimientos almacenados, disparadores,
funciones globales definidas por el usuario (global UDFs) y filtros para BLOB´s (Binary
Large Object). Estos elementos permiten automatizar los procesos de Bases de Datos
que ocurren en el Servidor de manera más rápida y fiable.
Además InterBase soporta de forma complementaria la implementación de Reglas del
Negocio y cuatro tipos diferentes de Integridad Referencial Declarativa.
Los disparadores almacenan las Reglas del Negocio de una empresa en el
Servidor. Cualquier aplicación que utilice datos corporativos se adhiere
automáticamente a esas reglas. Los disparadores de InterBase automatizan la
Capítulo 3. Sistemas de Bases de Datos Activas.
52
respuesta a determinados eventos por parte del Servidor y normalmente se
utilizan para validar datos cuando una tabla o fila es insertada, actualizada o
borrada.
Los alertadores de eventos. Posibilitan la creación de Bases de Datos activas
mediante la notificación automática a las partes interesadas cuando ocurren
ciertos cambios. Por ejemplo, cuando la cantidad almacenada de un producto en
una aplicación de gestión de almacén cae por debajo de un valor, un alertador
de eventos, podría enviar un mensaje de correo electrónico al jefe de compras.
Todo esto se puede realizar sin necesidad de un "polling" continuo sobre la base
de datos, de manera que no se utilicen permanentemente recursos del sistema.
Los procedimientos almacenados aumentan el rendimiento. El uso de los
procedimientos almacenados de InterBase pueden llevar a grandes incrementos
del rendimiento de su Base de Datos mediante la descarga de procedimientos
de uso continuo desde el cliente al servidor. Un procedimiento almacenado
puede ser utilizado por cualquier aplicación que se conecte con InterBase. Los
procedimientos almacenados fuerzan el diseño modular de aplicaciones
haciendo el trabajo de mantenimiento y reutilización más fácil.
Las funciones definidas por el usuario (UDF´s) ofrecen prestaciones
personalizadas y reutilizables. Las UDFs ofrecen maneras de extender las
capacidades analíticas del Kernel de InterBase mediante la creación de
funciones propias de cada negocio. Las UDFs son código reutilizable que sirven
para asegurar la fiabilidad e integridad de los datos. De igual forma las UDF´s
pueden ser utilizadas para hacer llamadas a aplicaciones externas a la Base de
Datos.
Constantes declarativas de Integridad Referencial. Permiten a InterBase
mantener de forma eficiente las relaciones entre registros de la Base de Datos.
Los tipos soportados son:
Clave única y primaria: Asegura que no puede haber dos registros en la misma
tabla con el mismo valor, los generadores de la Base de Datos pueden crear
automáticamente valores únicos (tales como identificadores de clientes).
Integridad referencial: Valida las relaciones entre tablas para asegurar que
siempre estén sincronizadas y posibilita las actualizaciones y borrados en
cascada.
Comprobaciones (Check): Establecen que las condiciones de búsqueda
asociadas sean válidas para cualquier registro de una tabla.
Capítulo 3. Sistemas de Bases de Datos Activas.
53
Dominio: Permite la creación de nuevos subtipos y especificaciones de
integridad a nivel de columna. Los dominios pueden ser utilizados para
especificar rangos de valores aceptables para una columna, o enumerar una
lista de valores así como valores por defecto. Esto significa, que una vez
definido, un dominio puede ser utilizado por todas las aplicaciones como un alias
que apunte a un tipo de dato más sofisticado. (tal como un campo memo)
Especificaciones técnicas
Integridad
Llaves primarias
Llaves foráneas
Integridad referencial en cascada
Verificación de valores en dominios y columnas
Triggers (disparadores) con las siguientes características:
o Número ilimitado de triggers por actualización/inserción/eliminación en
un registro de una tabla
o Triggers múltiples por acción (agregar/modificar/eliminar) con opción a
ordenarlos
o Triggers en cascada
Control de Concurrencia
Bloqueo optimista
Niveles de aislamiento de datos
Bloqueos compartidos y protegidos para cuando se bloquea una tabla
explícitamente
Disponibilidad
Respaldos en línea (no hay que dar de baja el servicio)
Recuperación inmediata en caso de una falla en el servicio
Base de datos distribuida
Conexiones ilimitadas de clientes (únicamente limitadas por el hardware)
Proceso de transacciones distribuidas automáticas mediante commits de dos
fases
Capítulo 3. Sistemas de Bases de Datos Activas.
54
Tipos de datos
Caracteres (de longitud fija y variable) de hasta 64kb por campo
Enteros (8, 16 y 32 bits)
Punto flotante: de precisión sencilla y doble
Fecha y hora: desde el 1 de enero de 100 hasta 11 de diciembre de 5491
Fecha, hora y fecha/hora
Cumple con el año 2000
Arreglos multidimensionales: hasta 16 dimensiones por columna
BLOBS (memos, campos binarios) de tamaño ilimitado
Importa y exporta datos ASCII de tamaño fijo
Estándares
Cumple con ANSI SQL-92
ODBC rev 2.0 (16 bits)
ODBC rev 3.0 (16 bits)
UNICODE
Requerimientos del Sistema
Requiere un mínimo de RAM y de espacio en disco, dependiendo del sistema
operativo sobre el cual se cargue.
Driver nativos para herramientas de desarrollo de aplicaciones
PowerPlay, PowerHouse 4GL, and Impromptu from Cognos Corp.
JAM for InterBase from JYACC, Inc.
Delphi and Delphi Client/Server
Borland¨ Database Engine
Visual dBASE with Borland SQL Links
Paradox for Windows with Borland SQL Links
Capacidad de la Base de Datos
Máximo número de filas por tabla: 2 billones
Capítulo 3. Sistemas de Bases de Datos Activas.
55
Máximo tamaño de una tabla: limitada solamente por los recursos del sistema
Máximo número de Bases de Datos definidas por sistema: limitada solamente
por los recursos del sistema
Máximo número de usuarios activos por sistema: limitado por los recursos del
sistema
Máximo número de tablas por Base de Datos: 64K
Máximo tamaño de las filas (excluyendo BLOb): 64Kb
3.2.6. Oracle
3.2.6.1. Perspectiva del Producto.
Veinticinco años atrás, Larry Ellison vió una oportunidad que otras empresas dejaron
pasar cuando se topó con la descripción de un prototipo de trabajo para una base de
datos relacional y descubrió que ninguna empresa se había comprometido a
comercializar la tecnología. Ellison y sus co-fundadores, Bob Miner y Ed Oates, se
dieron cuenta de que existía un tremendo potencial de negocios en el modelo de la base
de datos relacional pero tal vez no sabían que cambiarían la imagen de la informática
comercial para siempre.
3.2.6.2. Funcionalidad del Producto.
Oracle soporta todas las funciones que se esperan de un servidor serio: un lenguaje de
diseño de bases de datos muy completo (PL/SQL) que permite implementar diseños
“activos”, con triggers y procedimientos almacenados, con una integridad referencial
declarativa bastante potente. Permite el uso de particiones para la mejora de la
eficiencia, de replicación e incluso ciertas versiones admiten la administración de bases
de datos distribuidas. Oracle ha comenzado a evolucionar en los objetos, añadiendo
tipos de clases, referencias, tablas anidadas, matrices y otras estructuras de datos.
El mayor inconveniente de Oracle es quizás su precio. Incluso las licencias de Personal
Oracle son excesivamente caras, en mi opinión.
Como la segunda empresa vendedora de software a nivel mundial, Oracle provee una
plataforma completa para desarrollar aplicaciones que utilicen el recurso dato. Algunas
de las herramientas que provee son las siguientes: [13]
Un servidor de datos llamado Oracle que permite almacenar y manipular datos
de diferente índole (imágenes, sonidos, texto, caracteres, números, etc.). Hoy en
día la última versión del servidor de datos es la 9i.
Capítulo 3. Sistemas de Bases de Datos Activas.
56
Un entorno de edición en línea que incorpora un interprete de SQL, llamado
SQL*PLUS.
Un lenguaje procedimental que permite utilizar estructuras de control y variables
para elaborar programas que accedan a la base de datos donde se pueda
utilizar comandos SQL, conocido como SQL/PLUS (Procedural Language for
SQL). Este lenguaje es reconocido y procesado también por SQL*PLUS.
Una serie de bibliotecas para la programación utilizando otros lenguajes. Esta
biblioteca conocida como OCI (Oracle Call Interfaces) fue la solución inicial al
problema de desarrollar sistemas Cliente/Servidor. Hoy en día Oracle provee
una biblioteca propietaria de funciones para realizar comunicación con
servidores de datos utilizando Java, la cual es conocida como JDBC (Java
Database Connection).
Una serie de preprocesadotes (pre-compiladores) de SQL embebido, que
constituyó la primera solución al problema de desarrollar programas de bases de
datos. Existieron pre-compiladores que aceptaban instrucciones en un lenguaje
de programación particular de tercera generación (en el caso de Oracle los
lenguajes ofrecidos era ADA, PL/I, COBOL, FORTRAN y C) junto con
instrucciones de lenguaje SQL. Estas herramientas eran conocidas como
Pro*ADA, Pro *PL/I, Pro*COBOL, Pro*Fortran y Pro*C.
Extensiones específicas al intérprete del lenguaje SQL para soportar nuevas
tecnologías. Vale la pena destacar SQLJ como un lenguaje que admite el uso
simultáneo del lenguaje Java y de SQL.
Todo un grupo de herramientas basadas en lenguajes de cuarta generación y
tecnología CASE destinadas a asistir a los diseñadores y programadores en la
tarea de desarrollar grandes aplicaciones. Las versiones actuales de estas
herramientas se conocen como Oracle/Designer y Oracle/Developer.
Toda una serie de herramientas destinadas a ayudar al administrador de la base
de datos en sus tareas cotidianas. En este apartado la herramienta mas
importante en OEM (Oracle Enterprise Manager).
Por todo lo anterior Oracle es:
Primera base de datos que completa el récord mundial de TPC-H de 3 terabyte.
Primera base de datos que supera 9 evaluaciones de seguridad estándar del sector.
Primera base de datos con servicios web incorporados.
Capítulo 3. Sistemas de Bases de Datos Activas.
57
Primera base de datos con data mining integrado.
Primera base de datos con soporte para aplicaciones empaquetadas del mundo real en
un cluster.
Primera base de datos con particionamiento de Elección Arbitraria, por Rango,
Compuesto y de Lista.
Primera base de datos con administración de memoria dinámica.
Primera base de datos con workflow incorporado.
Primera en brindar soporte para JOLAP API.
3.1.1. Conclusiones.
Ninguno de los sistemas gestores de bases de datos que vamos a analizar es perfecto.
Cada uno tiene sus defectos y sus virtudes. En la siguiente tabla podemos ver un
resumen de las características técnicas que cumple cada uno. Ponemos solo las más
relevantes, aunque hay características que dicen cumplen todos, cada uno las cumple a
su manera.
Lenguaje
Característica/Técnica
HiPAC Postgres Starburst Sybase Interbase Oracle
Estrategia de
Control
Encadenamiento
hacia Adelante
Encadenamiento
hacia Atrás
Irrevocable
Tentativo
Tipos de
Eventos
Modificación
Petición de
Operación
Recuperación
Tiempo basado
Vistas de
Actualización
Capítulo 3. Sistemas de Bases de Datos Activas.
58
Evento de
Especificación
Implícito
Explícito
Proceso de
Granularidad
Orientado a
Sistema
Orientado a
Instancias
Condición de
Alcance
Base de Datos
Entera
Valores de
Transición
Criterios de
Terminación
Sistema libre de
Conflicto
Sistema de
Punto Fijo
Enlazar
Eventos -
Condiciones
Inmediato
Variable
Diferido
Alterado
Enlazar
Condiciones -
Acciones
Inmediato
Variable
Diferido
Alterado
Transición de
Valores por
Referencia
Ninguno
Parametrización
Palabras Clave
Resolución de
Conflictos
Control del
Usuario
Orden
Seriado
Jerarquía
de
Excepción
Orden de
Ejecución
Orden de
Ejecución Jerárquico
No
Determinístico
Determinístico
Capítulo 3. Sistemas de Bases de Datos Activas.
59
Administración
De Datos
Condiciones de
Selección
Estratificación
Soporte de
Programación
Pasivo / Activo
Clases de
Reglas
60
Conclusiones
En este trabajo hemos determinado que con la introducción de los Sistemas de Gestión de
Bases de Datos basados en reglas, la interpretación y adaptación del Mundo Real, puede ser
interpretado de manera fácil y eficaz, dado las reglas constituyen la más sencilla de las
metodologías utilizadas para este fin.
Así mismo concluimos que con las investigaciones realizadas sobre la relación entre la teoría
de las bases de datos y la lógica se ha dado lugar a las bases de datos deductivas, las cuales
permiten derivar nueva información a partir de la ya introducida explícitamente por el usuario.
Esta función deductiva se realiza mediante la adecuada explotación de ciertas reglas de
conocimiento relativas al dominio de la aplicación, utilizando para ello técnicas de programación
lógica y de inteligencia artificial. Sin embargo, el campo de las bases de datos deductivas, tan
prometedor hace pocos hace pocos años, no ha eclosionado todavía.
Estamos de acuerdo que las bases de datos deben evolucionar independientemente de la
intervención del usuario como respuesta a un suceso o una determinada situación, por ello con
la valorización hecha de los sistemas de bases de datos activos, hemos podido exponer que el
poder especificar reglas con una serie de acciones que se ejecutan automáticamente cuando se
producen ciertos eventos; sin duda es una de las mejoras de los sistemas de gestión de datos
que nos llevan a considerar que con los sistemas de bases de datos activas se consigue un
nuevo nivel de independencia de conocimiento.
Por lo tanto el presente trabajo permite la visualización de la rápida evolución que la tecnología
de bases de datos ha experimentado en la últimas décadas, así como la variedad de nuevos
caminos abiertos, han conducido a investigadores y asociaciones interesadas, a reflexionar
sobre el futuro de estas tecnologías.
61
Recomendaciones
1. Todo trabajo de investigación y más uno como este que trata de mostrar el estado del arte,
tanto teórico como práctico, de los Sistemas de Bases de Datos, en especial los conocidos
como Deductivos y Activos, es perse incompleto, pues mientras buscábamos e
investigábamos, deducíamos y plasmábamos nuestras conclusiones al respecto, muchas
cosas nuevas seguían surgiendo. Es por tanto una recomendación continuar este estudio a
profundidad y tratar de abarcar más SGBD comerciales, y comprobar las posibilidades para
estos campos.
2. También es importante considerar la posible vinculación de los Sistemas de Bases de Datos
Deductivos con los Sistemas de Bases de Datos Orientados a Objetos, otro campo de
estudio aún en sus inicios.
3. Por último creemos que los Sistemas de Bases de Datos Deductivos y los Sistemas de
Bases de Datos Activos, pueden tener también cierto vínculo con las Bases de Datos
Temporales y especialmente con los Almacenes de Datos y sobre todo las formas de
obtener la información en estos últimos como ayuda a la Toma de Decisiones, por lo que
sería interesante abarcar en futuras investigaciones esta relación.
62
Bibliografía
Fundamentos
1. Date C. J., “Introducción a los sistemas de bases de datos”, 7ma. Edición, Addison
Wesley. 2000.
2. De Miguel Adoración y Piattini Mario, “Conceptos y diseño de bases de datos”, 2da.
Edición, Editorial Ra-ma. 1999.
3. Elmasri R., Navathe S. B., “Sistemas de Bases de Datos”, 2da. Edición, Addison Wesley
Iberoamericana. 1998.
4. Gardarin G., “Bases de datos“, Editorial Paraninfo. 1995.
5. González Alvarado Carlos, “Sistema de Bases de Datos”, 1era. Edición, Editorial
Tecnológica de Costa Rica. 2001.
6. Jonson James L., “Bases de datos: Modelos, lenguajes, diseño”, 1era. Edición, Oxford
University Press México. 1997.
7. McFadden F. R., Hoffer J. A., Prescott M. B., “Modern Database Management”, Addison
Wesley. 1998.
8. “Referencias De Computación”, [http://www.monografias.com/trabajos/refercomp/
refercomp.shtml]
9. Silberschatz A. Korth H. y Sudarshan S., “Fundamentos de Bases de Datos”, 3ra.
Edición, Editorial McGraw-Hill. 1997.
10. Ullman, “Principles of Database System”, Editorial Computer Science Press. 1992.
Bases de Datos Avanzadas
1. Amado Rodríguez Karina, Díaz Cervantes Imelda, “Bases de Datos Deductivas”,
[http://solar6.ingenieria.uatx.mx/~galvarez/base_datos/unidad4.htm#mecanismos]
2. Calero Muñoz Coral, Serrano Martín Manuel, “El Entorno de Trabajo ORACLE 8”,
[http://alarcos.inf-cr.uclm.es/doc/bda/doc/lab/BDa-P1.pdf].
3. Clocksin W. F. y Mellish C. S., “Programming in Prolog”, Springer-Verlag, Inc.
4. Chimenti D., Gamboa R, et al, “El Prototipo del Sistema de LDL”, IEEE Transactions on
Knowledge and Data Engineering, Marzo 1990, Vol. 2, No.1.
Bibliografía.
63
5. Dahl Verónica, “Representación Virtual del Conocimiento”, Fundación Omar Dengo y
UNED, [http://claudiogutierrez.com/bid-fod-uned/Dahl.html]
6. Giannesini Francis, Kanoui Henry, et al, “Prolog”, Addison Wesley Iberoamericana.
7. Jaeger Ulrike, Freytag Johann Christoph, “An Annotated Bibliography on Active
Databases”, Humboldt University of Berlin, Germany.
8. Klim W., “Modern database Systems. The Object Model, Interoperability and Beyond”,
ACM Press.
9. Krishnamurthy Ravi , Zaniolo Carlo, “Optimization in a Logic Basic Language for
Knowledge and Data Intesnsive Applications”, [http://www.cs.ucla.edu/~zaniolo/
papers/edbt88.pdf]
10. Lockhart Thomas, “Tutorial de PostgreSql”, Postgres Global Development Group.
11. Marteens Ian, “La Base de Datos Perfecta”, [http://freehost09.websamba.com/intitec/
articulos/BaseDatosPerfecta.htm]
12. Minker Jack, “Logia and Databases: a 20 Year Retrospective”, Institute of Computer
Studies, University of Maryland.
13. “Nuevas Tecnologías”, [http://acha.uta.cl/yon/Programacion_del_semestre/CC_763/
Nuevas_tecnologias/nuevas_tecnologias.htm]
14. Paton Norman W., “Active rules in database systems”, Springer-Verlag New York, Inc.,
ISBN 0-387-98529-8, 1999
15. Piattini M. y Díaz O., “Advanced Databases: Technology and Design”, Artech House.
16. Savino Nuncio, “El Manejador de Bases de Datos Relacionales ORACLE”,
www.bd.cesma.usb.ve/ci3315/docs/claseI.pdf
17. Stonebraker M., Brown P., “Object- Relational DBMSs tracking the next great wave”,
Morgan Kauffman Publishers.
18. “The Active Database Management System Manifesto: A Rulebase of ADBMS Features”,
ACT-NET Consortium. [http://www.ida.his.se/ida/adc/adc_bib.html]
19. Vaquer Crusat Marc, “Comparando MySQL, PostgreSQL, Internase y SAP DB”,
[http://www.arrakis.es/~qenda/Articles/ArticleDB/Articulo_DB_9-5-01a.htm]
20. Widom Jennifer , Ceri Stefano, “Active Database Systems: Triggers and Rules for
Advanced Database Processing”, Edited by, Morgan Kaufmann Publishers, Inc., ISBN 1-
55860-304-2, 1996.
64
Referencias Bibliográficas.
[1] Armas Sergio, “Dispositivos de Bases de Datos”, [http://www.ver.ucc.mx/
~9660185s/courseware/unidad6.htm, 1999]
[2] Borja Andrés Felipe, Jiménez Andrés Felipe, “Bases de Datos – Consulta sobre
Bases de Datos Deductivas”, [http://xue.unalmed.edu.co/bios, 2000]
[3] Cervantes Villagómez Ofelia, Leal Olmedo Antonio, “Entorno Data: Una
Experiencia para la administración de Bases de Datos Deductivas Orientadas a
Objetos combinando paradigmas de programación”, [{ocervan, lealra}
@udlapvms.pue.udlap.mx, 1996]
[4] Chakravarthy, S. et al. “HiPAC: A Research Project in Active, Time Constrained
Database Management”, Final Technical Report, XAIT-89-02, Xerox Advanced
Information Technology, (Agosto de 1989).
[5] Chapa Vergara Sergio V., “Lógica Matemática y Aplicaciones”,
[http://delta.cs.cinvestav.mx/red/logica/logica.html, 1998]
[6] Chimenti D., Gamboa R, et al, “El Prototipo del Sistema de LDL”, IEEE
Transactions on Knowledge and Data Engineering, Marzo 1990, Vol. 2, No.1.
[7] Clocksin W.F. , Mellish C.S., “Programming in Prolog”, Springer-Verlag.
[8] Elmasri Ramez, Navathe Shamkant B., “Sistemas de Bases de datos”, Addison
Wesley Longman, 2da. Edición, (1997).
[9] Giannesini Francis, Kanoui Henry, et al, “Prolog”, Addison-Wesley
Iberoamericana.
[10] Lockhart Thomas, “Tutorial de PostgreSql”, Postgres Global Development Group.
[11] Martínez Méndez Francisco Javier, et al, “Diseño Lógico-Conceptual de
Tesauros”, [http://www.um.es/~gtiweb/fjmm/disetesa.htm#inicio, 1992]
[12] Morado Raymundo, “Demostración Automática”, [http://www.filosoficas.unam
.mx/~morado/LogicaHoy/morado.html , 2001]
[13] Savino Nuncio, “El Manejador de Bases de Datos Relacionales ORACLE”,
[www.bd.cesma.usb.ve/ci3315/docs/claseI.pdf, 2002]
Referencias Bibliográficas.
65
[14] Piattini Mario, Monografía: "Bases de Datos Avanzadas", Novática, Vol.140,
(Julio-Agosto 1999)
66
Anexos.
Anexo 1
Los primeros SGBD fallaron en la implementación de algunos aspectos claves del modelo
relacional, existiendo en el mercado un abuso en la utilización del adjetivo relacional. En
respuesta a la corrupción del término relacional, el Dr. Codd escribió un artículo en 1985,
estableciendo 12 reglas que deben cumplirse por cualquier SGBD para verdaderamente
poderse llamar relacional.
Las 12 reglas del Dr. Codd para los SGBD relacionales:
1. Regla de la información. Toda la información de una BD relacional esta
representada explícitamente a nivel lógico y exactamente de un modo - mediante
valores en tablas.
2. Regla del acceso garantizado. Todos y cada uno de los datos (valor atómico)
de una BD relacional se garantiza que sean lógicamente accesibles recurriendo
a una combinación de nombre de tabla, valor de llave primaria y nombre de
columna.
3. Tratamiento sistemático de valores nulos. Los valores nulos (distintos de la
cadena vacía, de la cadena de caracteres blanco y distinta de cero o de
cualquier otro número) se soportan en los SGBD completamente relacionales
para representar la falta de información y la información inaplicable de un modo
sistemático e independiente del tipo de datos.
4. Catálogo dinámico en línea (On Line) basado en el modelo relacional. La
descripción de la BD se representa a nivel lógico del mismo modo que los datos
ordinarios, de modo que los usuarios autorizados puedan aplicar para su
interrogación el mismo lenguaje relacional que se aplica a los datos regulares.
5. Regla del sublenguaje completo de datos. Un sistema relacional puede
soportar varios lenguajes y varios medios de uso terminal. Sin embargo debe
haber al menos un lenguaje cuyas sentencias sean expresables mediante una
sintaxis bien definida, como cadena de caracteres y que sea completa en cuanto
al soporte de todos los siguientes puntos:
Definición de datos
Definición de vistas
Anexos.
67
Manipulación de datos (interactiva y por programas)
Restricciones de integridad
Autorización
Fronteras de transacciones (comienzo, cumplimiento y vuelta atrás)
6. Regla de actualización de vistas. Todas las vistas que teóricamente sean
actualizables, son también actualizables por el sistema.
7. Inserción, eliminación y actualización de alto nivel. La capacidad de manejar
una relación de la BD o una relación derivada como un único operando se aplica
no solamente a la recuperación de datos, sino también a la inserción, la
eliminación y a la actualización de datos.
8. Independencia física de los datos. Los programas de aplicación y las
actividades terminales permanecen lógicamente inalterables, cualesquiera que
sean los cambios efectuados, ya sea a las representaciones de almacenamiento
o a los métodos de accesos.
9. Independencia lógica de los datos. Los programas de aplicación y las
actividades terminales permanecen lógicamente inalterables cuando se efectúan
cambios en las tablas de base, cambios preservadores de la información de
cualquier tipo que permitan alteraciones.
10. Independencia de integridad. Las restricciones de integridad especificas para
una BD relacional particular deben ser definibles en el sublenguaje de datos
relacional y almacenables en el catalogo, no en los programas de aplicación.
11. Independencia de distribución. Un SGBD relacional tiene independencia de
distribución.
Esta regla dice que el lenguaje de base de datos debe ser capaz de manipular
datos distribuidos localizados en otros sistemas informáticos de forma
transparentes.
12. Regla de la no subversión. Si un sistema relacional tiene un lenguaje de bajo
nivel (un sólo registro a la vez), ese bajo nivel no puede ser utilizado para
subvertir o suprimir las reglas de integridad y las restricciones expresadas en el
lenguaje relacional de nivel superior (múltiples registros a la vez).