Valorización de las Bases de Datos Deductivas y de las ...

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

4


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


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


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


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,


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.


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.


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


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.


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


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.


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.


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:


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.


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.


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


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


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.


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.


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.


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


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.


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.


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.


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.


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


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.


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.


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


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:


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.


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.


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.


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]


34

2.2.4. Proyecto NAIL!.


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.


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.


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


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:


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.


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.


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.


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.


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.5. HIPAC


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.


43


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


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


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


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


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


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


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


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.


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


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


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


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.


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


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


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.


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


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


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.


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


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


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


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.


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.


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.


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


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


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.

http://alarcos.inf-cr.uclm.es/doc/bda/doc/lab/BDa-P1.pdf

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.

http://www.acm.org/sigmod/record/issues/9609/adbms.ps

http://www.mkp.com/books_catalog/catalog.asp?ISBN=1-55860-304-2



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]

http://www.ver.ucc.mx/~9660185s/courseware/unidad6.htm

http://www.ver.ucc.mx/~9660185s/courseware/unidad6.htm

http://xue.unalmed.edu.co/bios

mailto:lealra%[email protected]

mailto:lealra%[email protected]

http://delta.cs.cinvestav.mx/red/logica/logica.html

http://www.um.es/gtiweb/fjmm/disetesa.htm#inicio

http://www.filosoficas.unam.mx/morado/LogicaHoy/morado.html

http://www.filosoficas.unam.mx/morado/LogicaHoy/morado.html

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

Valorización de las Bases de Datos Deductivas y de las ...

Documents

Transcript of Valorización de las Bases de Datos Deductivas y de las ...