SISTEMAS DE BASES DE DATOS DEDUCTIVAS

SISTEMAS DE BASES DE DATOS DEDUCTIVAS

Un DBMS deductivo es aquel que soporta la perspectiva de una base de datos por la teoría de demostraciones y —en particular— es capaz de deducir o inferir hechos adicionales a partir de los hechos dados en la base de datos extensional (aplicando axiomas deductivos o reglas de in-ferencia especificados para esos hechos dados).* Los axiomas deductivos, junto con las restri -cciones de integridad (que tratamos más adelante), forman lo que en ocasiones se conoce como base de datos intensional; y la base de datos extensional y la intensional juntas constituyen lo que generalmente se conoce como base de datos deductiva (aunque no es un buen término, de-bido a que es el DBMS, y no la base de datos, quien realiza las deducciones).

*Con respecto a esto, vale la pena observar que Codd decía desde 1974 que uno de los objetivos del modelo relacional era, precisamente, "combinar los campos de la recuperación de hechos y la administración de archivos preparándose para la adición, en un tiempo posterior, de servicios inferenciales en el mundo comer-cial" [11.2], [25.8].

788 Parte V / Temas adicionales

Como acabamos de indicar, los axiomas deductivos forman una parte de la base de datos intensional. La otra parte consiste en axiomas adicionales que representan restricciones de inte-gridad (es decir, las reglas cuyo propósito principal es restringir las actualizaciones; aunque de hecho, dichas reglas también pueden ser usadas en el proceso de deducir hechos adicionales a partir de los que se han dado).

Veamos cómo se vena la base de datos de partes y proveedores de la figura 3.8 en forma de "DBMS deductivo". Primero, habrá un conjunto de axiomas base que definan los valores de dominio válidos. Nota: En lo que viene a continuación, por razones de legibilidad adoptamos esencialmente las mismas convenciones con respecto a la representación de valores como lo hicimos (por ejemplo) en la figura 3.8; por lo tanto, escribimos 300 como una abreviatura ade-cuada para CANT(300), etcétera.

) ) ) )) ) )

NOMBRE ( Tornillo )etcétera

STATUS STATUS STATUS etcétera

( 5 ) ( 10 ) ( 15 )

CIUDAD CIUDAD CIUDAD CIUDAD etcétera

( Londres )( Paris ( Roma ( Atenas

etcétera.Luego, habrá axiomas base para las tupias en las relaciones base:

V ( V1, Smith, 20, Londres )V ( V2, jones, 10, París )etcétera

P ( P1, Tuerca, Rojo, 12, Londres ) etcétera

VP ( V1, P1, 300 ) etcétera

Nota: No estamos sugiriendo seriamente que la base de datos extensional será creada listando explícitamente todos los axiomas base como acabamos de indicar, sino que (por supuesto) se usa-rán los métodos tradicionales de definición y captura de datos. En otras palabras, los DBMSs deductivos aplicarán, por lo general, sus deducciones para bases de datos convencionales que ya existan y que hayan sido construidas en la forma convencional. Sin embargo, ¡observe que ahora se vuelve más importante que nunca que la base de datos extensional no viole ninguna de las restric-ciones de integridad declaradas!; ya que una base de datos que viola cualquiera de estas restricciones, representa (en términos lógicos) un conjunto de axiomas inconsistentes, y es bien sabido que, par-tiendo de ese punto, es posible demostrar que es "verdadera" absolutamente cualquier proposición que se quiera (en otras palabras, es posible derivar contradicciones). Por la misma razón, también es importante que el conjunto de restricciones de integridad establecido sea consistente.

Ahora para la base de datos intensional. Éstas son las restricciones de atributos:

V ( v, vn, vt, ve ) =► V# ( v ) ANDNOMBRE ( vn ) ANDSTATUS ( vt ) ANDCIUDAD ( ve )

V# ( V1)

V# ( V2)

V# ( V3)

V# ( V4)

V#etcétera NOMBRE ( Perno

NOMBRE ( SmithNOMBRE ( JonesNOMBRE ( BlakeNOMBRE ( ClarkNOMBRE ( Adams

( White ( Tuerca

NOMBRE NOMBR

Capítulo 23 I Bases de datos basadas en la lógica 789

p ( p , p n , p l , p p , p e ) = <

etcétera

P# ( p ) AND NOMBRE ( pn ) AND COLOR ( pl ) AND PESO ( pp ) AND CIUDAD ( pe )

Restricciones de clave candidata:

V ( v, vn1, vt1, vd

etcétera

AND V ( V, vn2, Vt2, =►• vn1 = vn2 AND

vt1 • vt2 ANDvd = vc2

vc2 )

Restricciones de clave externa:

P, C ) =► V vn, vt, ve ) AND pn, pl, pp, pe )

Y así sucesivamente. Nota: Para efectos de la explicación, suponemos que las variables que aparecen al lado derecho del símbolo de implicación y que no aparecen al lado izquierdo (en el ejemplo, vn, vt, etcétera) están cuantificadas existencialmente. (Todas las demás están cuantifi-cadas universalmente, como explicamos en la sección 23.4.) Técnicamente, necesitamos algu-nas funciones de Skolem; vn, por ejemplo, en realidad debería ser reemplazada por —digamos— VN (v), donde VN es una función de Skolem.

Observe de paso que la mayoría de las restricciones que mostramos anteriormente no son cláusulas puras en el sentido de la sección 23.5, ya que el lado derecho no es simplemente una disyunción de términos simples.

Añadamos ahora algunos axiomas deductivos adicionales:

V ( v, vn, vt, ve ) AND vt > 15= ► BUENPROVEEDOR ( v, vt, ve )

(compárelo con la definición de la vista BUEN_PROVEEDOR del capítulo 9, sección 9.1).

V ( vx, vxn, vxt, ve ) AND V ( vy, vyn, vyt, ve )=»■ VV_COUBICADO ( vx, vy )

V ( v, vn, vt, c ) AND P ( p, pn, pl, pp, c )= + VP_C0UBICAD0 ( v, p )

y así sucesivamente.Para hacer el ejemplo un poco más interesante, ampliemos ahora la base de datos para que

incluya una varrel de "estructura de partes", que muestra qué partes px contienen qué partes py como componentes inmediatos (es decir, de primer nivel). Primero, una restricción para mostrar que px y py deben identificar partes existentes:

ESTRUCTURAPARTES ( px, py ) => ? ( px, xn, xl,

P ( py , yn , y i , Algunos valores de

datos:

ESTRUCTURA_PARTES ( P1, P2 )ESTRUCTURA_PARTES ( P1, P3 )ESTRUCTURAPARTES ( P2, P3 )ESTRUCTURAPARTES ( P2, P4 )etcétera

xc ) AND ye )


(En la práctica, es probable que ESTRUCTURA_PARTES también tenga un argumento de "cantidad" que muestre cuántas py son necesarias para hacer una px, pero omitimos este refi-namiento por razones de simplicidad.)

Ahora añadimos un par de axiomas deductivos para explicar lo que significa que la parte px contenga a la parte py como componente (a cualquier nivel):

ESTRUCTURAPARTES ( px, py ) =► COMPONENTE_DE ( px, py )

ESTRUCTURA_PARTES ( px, pz ) AND COMPONENTEDE ( pz, py )= *■ COMPONENTEDE ( px, py )

En otras palabras, la parte py es un componente de la parte px (a algún nivel) si es un compo-nente inmediato de la parte px o un componente inmediato de alguna parte pz que a su vez es componente (a algún nivel) de la parte px. Observe que el segundo axioma es recursivo; define al predicado COMPONENTE_DE en términos de sí mismo.* Por el contrario, los sistemas rela -ciónales no han permitido, históricamente, que las definiciones de vistas (o las consultas, o las restricciones de integridad, etcétera) sean recursivas de esta forma. Esta habilidad para soportar la recursion es una de las distinciones más inmediatamente obvias entre los DBMSs deductivos y sus contrapartes relaciónales clásicas; aunque como mencionamos en la sección 23.5 (y como vimos en el capítulo 6), no existe una razón fundamental de por qué los sistemas relaciónales clásicos no deban ser extendidos para soportar tal recursion, y en algunos ya se ha hecho. Tendremos más que decir con respecto a la recursion en la sección 23.7.

Datalog

De lo que explicamos anteriormente, debe quedar claro que una de las partes más directamente visibles de un DBMS deductivo será un lenguaje en el cual se formulen los axiomas deductivos (llamados reglas, por lo general). El ejemplo más conocido de uno de estos lenguajes se llama Datalog (por analogía con Prolog) [23.9]. En esta subsección presentamos una breve explicación sobre Datalog. Nota: El énfasis sobre Datalog es por su poder descriptivo y no por su poder compu-tacional (como de hecho también fue el caso con el modelo relacional original [5.1]). El ob -jetivo es definir un lenguaje que a fin de cuentas tendrá un poder expresivo mayor que el de los lenguajes relaciónales convencionales [23.9]. Por consecuencia, el énfasis en Datalog, y además el énfasis en los sistemas basados en la lógica en general, es muy fuerte sobre las consultas y no sobre las actualizaciones, aunque es posible y necesario extender el lenguaje para que también soporte la actualización (vea más adelante).

En su forma más simple, Datalog soporta la formulación de reglas como las cláusulas de Horn simples sin funciones. En la sección 23.4 definimos una cláusula de Horn para que fuera una WFF de alguna de las dos formas siguientes:

A1 AND A2 AND ... AND An

A1 AND A2 AND . . . AND An =*■ B

*De hecho, hemos definido claramente un cierre transitivo; en cualquier momento dado, la relación correspondiente a COMPONENTE_DE es el cierre transitivo de la relación correspondiente a ESTRUC-TURA_PARTES (vea el capítulo 6).

Capítulo 23 / Bases de datos basadas en la lógica 791

(donde las As y Bs son ejemplares de predicado no negados que involucran solamente constantes y variables). Sin embargo, siguiendo el estilo de Prolog, Datalog en realidad escribe la segunda de estas formas de la otra manera:

B ■*= A1 AND A2 AND AND An

Por lo tanto, para ser consistentes con otras publicaciones en esta área, haremos lo mismo en las partes que vienen a continuación.

En una cláusula como ésta, B es la cabeza de la regla (o conclusión) y las As son el cuerpo de la regla (o premisas o meta; cada A individual es una submeta). Por brevedad, los ANDs son frecuentemente reemplazados por comas. Un programa Datalog es un conjunto de estas cláusu-las separadas de alguna forma convencional; por ejemplo, por punto y coma (sin embargo, en este libro no usaremos punto y coma, sino que simplemente comenzaremos cada cláusula en una nueva línea). Dentro de estos programas, no asignamos ningún significado al orden de las cláusu-las.

Observe que toda la "base de datos deductiva " puede ser considerada como un programa Datalog en el sentido anterior. Por ejemplo, podríamos tomar todos los axiomas establecidos an-teriormente para los proveedores y partes (los axiomas base, las restricciones de integridad y los axiomas deductivos), escribirlos en un estilo Datalog, separarlos con punto y coma (o escribir-los en líneas separadas) y el resultado sería un programa Datalog. Sin embargo, como dijimos anteriormente, por lo general no especificaremos de esta forma la parte extensional de la base de datos, sino de una forma más convencional. Por lo tanto, el propósito principal de Datalog es soportar específicamente la formulación de axiomas deductivos. Como ya mencionamos, esa función puede ser considerada como una extensión al mecanismo de definición de vistas que se encuentra en los DBMSs relaciónales actuales.

Datalog también puede ser usado como lenguaje de consulta (de nuevo, en forma similar a Prolog). Por ejemplo, supongamos que hemos dado la siguiente definición Datalog de BUEN_PROVEEDOR:

BUENPROVEEDOR ( v, vt, ve <= V ( v, vn, vt, ve )AND vt > 15

Éstas son algunas consultas típicas contra BUEN_PROVEEDOR:

1. Obtener todos los buenos proveedores:

? * = BUENPROVEEDOR ( v, vt, ve )

2. Obtener los buenos proveedores que están en París:

? ■*= BUENPROVEEDOR ( v, vt, París )

3. ¿Es un buen proveedor el proveedor VI?

? ■*= BUEN_PROVEEDOR ( V1 , vt, ve )

Y así sucesivamente. En otras palabras, una consulta en Datalog consiste en una regla especial con una cabeza "?" y un cuerpo que consiste de un solo término que indica el resultado de la con-sulta; la cabeza "?" significa (por convención) "Desplegar".


"Referencias y bibliografía"). En la presente sección tratamos brevemente algunas de las técni -cas más simples y mostramos su aplicación a la consulta "explotar la parte Pl" sobre los si -guientes datos de ejemplo:

EP

PX PY

P1 P2P1 P3P2 P3P2 P4P3 P5P4 P5P5 P6

Unificación y resolución

Por supuesto, un enfoque posible es usar las técnicas estándar de Prolog para unificación y re-solución, como las describimos en la sección 23.4. En el ejemplo, este enfoque funciona de la siguiente forma. Las primeras premisas son los axiomas deductivos, que lucen de esta forma (en forma normal conjuntiva):

1. NOT EP ( px, py ) OR COMP ( px, py )

2. NOT EP ( px, pz ) OR NOT COMP ( pz, py ) OR COMP ( px, py )

Construimos otra premisa a partir de la conclusión deseada:

3. NOT COMP ( P1, py ) OR RESULTADO ( py )

Los axiomas base forman las premisas restantes. Considere por ejemplo el axioma base

4. EP ( P1, P2 )

Si sustituimos Pl en lugar de px y P2 en lugar de py en la línea 1, podemos resolver las líneas 1 y 4 para que produzcan

5. COMP ( P1 , P2 )

Ahora, si sustituimos P2 en lugar depy en la línea 3 y resolviendo las líneas 3 y 5, obtenemos

6. RESULTADO ( P2 )

Por lo tanto, P2 es un componente de Pl. Un argumento exactamente equivalente mostrará que P3 también es un componente de Pl. Ahora bien, tenemos por supuesto los axiomas adi -cionales COMP(P1,P2) y COMP(P1,P3); entonces podemos aplicar el proceso anterior en forma recursiva para determinar la explosión completa. Le dejamos los detalles como ejercicio.

Sin embargo, en la práctica, la unificación y resolución pueden ser bastante costosas en rendimiento. Por lo tanto, a menudo será necesario encontrar alguna estrategia más eficiente. Las subsecciones siguientes tratan algunos enfoques posibles para este problema.

Evaluación ingenua

La evaluación ingenua [23.25] es probablemente el enfoque más simple de todos. Como su nombre lo sugiere, el algoritmo es muy simple; lo podemos explicar fácilmente (para nuestra consulta de muestra) en términos del siguiente seudocódigo:


COMP := EP ;ejecuta hasta que COMP llegue a un "punto fijo" ;COMP := COMP UNION ( COMP » EP ) ; fin ;

DESPLEGAR := COMP WHERE PX = P# ( ' P1 ' ) ;

Las varrels COMP y DESPLEGAR (al igual que la varrel EP) tienen cada una dos atribu-tos, PX y PY. A grandes rasgos, el algoritmo funciona formando repetidamente un resultado in-termedio que consiste en la unión de la junta de EP con el resultado intermedio anterior, hasta que ese resultado intermedio llega a un punto fijo; es decir, hasta que deja de crecer. Nota: La expresión "COMP * EP" es una abreviatura para "juntar COMP y EP sobre COMP.PY y EP.PX, y proyectar el resultado sobre COMP.PX y EP.PY"; por brevedad, ignoraremos las ope-raciones para renombrar atributos que nuestro dialecto de álgebra requeriría para que esta opera-ción funcionara (vea el capítulo 6).

Veamos paso a paso el algoritmo con nuestros datos de ejemplo. Después de la primera ite-ración del ciclo, el valor de la expresión COMP » EP es como se muestra abajo del lado izquierdo y el valor resultante de COMP es como se muestra abajo del lado derecho (con las tupias que se añaden en esta iteración marcadas con un asterisco):

COMP » EP PX PY

P1 P3

P1 P4P1 P5P2 P5P3 P6P4 P6

COMP

PX PY

P1 P2

P1 P3P2 P3P2 P4P3 P5P4 P5P5 P6P1 P4P1 P5P2 P5P3 P6P4 P6

Después de la segunda iteración se ven de esta forma:

COMP a EP PX PY

P1 P3


COMP

PX PY

P1 P2

P1 P3P2 P3P2 P4P3 P5P4 P5P5 P6P1 P4P1 P5P2 P5P3 P6P4 P6P1 P6P2 P6

Observe cuidadosamente que el cálculo de COMP » EP en este segundo paso repite com-pletamente el cálculo de COMP « EP del primer paso y además, calcula algunas tupias adi -cionales (de hecho, dos tupias adicionales —(Pl ,P6) y (P2,P6)— en este caso). Ésta es una razón por la cual el algoritmo de evaluación ingenua no es muy inteligente.


Después de la tercera iteración, el valor de COMP » EP (después de más cálculos repetidos) resulta ser el mismo que el de la iteración anterior; por lo tanto, COMP ha llegado a un punto fijo y salimos del ciclo. Después el resultado final es calculado como una restricción de COMP:

COMP

PX PY


Ahora es evidente otra ineficiencia mayúscula: el algoritmo ha calculado efectivamente la explosión para cada parte —de hecho, ha calculado el cierre transitivo completo de la relación EP— y luego ha descartado todo nuevamente, con excepción de las tupias que en realidad de-seaba; en otras palabras, de nuevo se ha realizado mucho trabajo innecesario.

Cerramos esta subsección señalando que la técnica de evaluación ingenua puede ser conside-rada como una aplicación del encadenamiento hacia adelante. Comenzando desde la base de datos extensional (es decir, los valores de datos reales), aplica las premisas de la definición (es decir, el cuerpo de la regla) en forma repetida hasta obtener el resultado deseado. De hecho, el algoritmo en realidad calcula el modelo mínimo para el programa Datalog (vea las secciones 23.5 y 23.6).

Evaluación semiingenua

La primera mejora obvia al algoritmo de evaluación ingenua es evitar la repetición de los cálcu -los de cada paso en el siguiente: evaluación semiingenua [23.28]. En otras palabras, en cada paso calculamos solamente las nuevas tupias que necesitan ser añadidas en esta iteración particular. De nuevo, explicamos la idea en términos del ejemplo "explotar la parte Pl". El seudocódigo es:

NUEVO := EP ;COMP := NUEVO ;ejecutar hasta que NUEVO esté vacío ;

NUEVO := ( NUEVO » EP) MINUS COMP ;COMP := COMP UNION NUEVO ;

fin ; DESPLEGAR : = COMP WHERE PX = P# ( ' P1 ' ) ;

De nuevo, veamos paso a paso el algoritmo. En la primera entrada al ciclo, NUEVO y COMP son idénticos a EP:

NUEVO PX PY


COMP

PX PY

P1 P2

P1 P3P2 P3P2 P4P3 P5P4 P5P5 P6

Al terminar la primera iteración se ven de esta manera:


NUEVO PX PY


COMP

PX PY

P1 P2P1 P3P2 P3P2 P4P3 P5P4 P5P5 P6P1 P4P1 P5P2 P5P3 P6P4 P6

En esta etapa, COMP es igual a como era en la evaluación ingenua y NUEVO es simple-mente las nuevas tupias que fueron añadidas a COMP en esta iteración; observe en particular que NUEVO no incluye la tupia (P1 ,P3). Compárelo con la contraparte de la evaluación ingenua.

Al final de la siguiente iteración tenemos:

NUEVO PX PY

P1P2

G_ Q

_

COMP

PX PY

P1 P2P1 P3P2 P3P2 P4P3 P5P4 P5P5 P6P1 P4P1 P5P2 P5P3 P6P4 P6P1 P6P2 P6

La siguiente iteración deja vacío a NUEVO y por lo tanto, salimos del ciclo.

Filtrado estático

El nitrado estático es un refinamiento a la idea básica de la teoría de optimización clásica de realizar restricciones tan pronto como sea posible. Puede ser considerado como una aplicación del encadenamiento hacia atrás en el cual, en efecto, usa información de la consulta (la con-clusión) para modificar las reglas (las premisas). También se le conoce como reducción del conjunto de hechos importantes, ya que (de nuevo) usa información de la consulta para elimi-nar inmediatamente tupias inútiles en la base de datos extensional en el conjunto de salida [23.29]. En términos de nuestro ejemplo, podemos explicar el efecto en términos del siguiente seudocódigo:

NUEVO := EP WHERE PX = P# ( ' P1 ' ) ;COMP := NUEVO ;ejecutar hasta que NUEVO esté vacío ;

NUEVO := ( NUEVO * EP ) MINUS COMP ;COMP := COMP UNION NUEVO ;

fin ; DESPLEGAR :- COMP ;


De nuevo, veamos paso a paso el algoritmo. En la primera entrada al ciclo, NUEVO y COMP se ven de esta manera:

NUEVO PX PY

P1 P1

P2 P3

COMP

PX PY

Q. Q

-

P2 P3

Al final de la primera iteración se ven de esta manera:

NUEVO PX PY

P1 P1

P4 P5

COMP

PX PY

P1 P1 P1 P1

P2 P3 P4 P5

Al final de la siguiente iteración tenemos:PX PY

P1 P6

PX PY


La siguiente iteración deja vacío a NUEVO y por lo tanto, salimos del ciclo.Esto concluye nuestra breve introducción a las estrategias de procesamiento de consultas recursivas. Por

supuesto, en la literatura se han propuesto muchos otros enfoques, la mayoría de ellos mucho más sofisticados que los simples que tratamos anteriormente; sin embargo, en un libro de esta naturaleza es insuficiente el espacio para tratar todo el material de fondo necesario para tener una comprensión adecuada de estos enfoques. Para mayores explicaciones vea por ejemplo las referencias [23.16] a [23.43].

23.8 RESUMEN

Esto nos lleva al final de nuestra corta introducción al tema de las bases de datos que están basadas en la lógica. Aunque las ideas todavía están limitadas en su mayoría al mundo de la in-vestigación, unas cuantas de ellas han comenzado a encontrar su camino en productos rela-ciónales comerciales (este comentario es especialmente cierto con respecto a algunas de las técnicas de optimización). En términos generales, el concepto de bases de datos basadas en la lógica luce interesante; hemos identificado varias ventajas potenciales en diversos puntos de las secciones anteriores. Una ventaja adicional, que no mencionamos explícitamente en el cuerpo del capítulo, es que la lógica podría formar la base de una integración genuinamente suave entre los lenguajes de programación de propósito general y la base de datos. En otras palabras, en vez del enfoque de "sublenguaje de datos incrustado" soportado por los productos SQL actuales

COMPNUEVO


—un enfoque que no es muy elegante, por no decir más— el sistema podría proporcionar un solo lenguaje basado en la lógica y en el cual los "datos son datos", sin tomar en cuenta si están guardados en una base de datos compartida o si son locales a la aplicación. (Por supuesto, hay varios obstáculos que salvar antes de poder lograr este objetivo, y uno no tan pequeño es —en primer lugar— demostrara satisfacción de la comunidad de TI en conjunto, que la lógica es una base adecuada para un lenguaje de programación.)

Revisemos rápidamente los puntos principales del material que hemos cubierto. Comen-zamos con un breve tutorial sobre el cálculo proposicional y de predicados, presentando los siguientes conceptos, entre otros:

■ Una interpretación de un conjunto de WFFs es la combinación de (a) un universo de discurso, (b) una transformación entre constantes individuales que aparecen en esas WFFs conobjetos de ese universo, y (c) un conjunto de significados definidos para los predicados yfunciones que aparecen en esas WFFs.

■ Un modelo para un conjunto de WFFs es una interpretación en la cual todas las WFFs delconjunto dan como resultado verdadero. Un conjunto dado de WFFs puede tener cualquiercantidad de modelos (en general).

■ Una demostración es el proceso de mostrar que alguna WFF dada g (la conclusión) es unaconsecuencia lógica de algún conjunto dado de WFFs/7,/2, ...,fn (las premisas). Explicamos un método de demostración conocido como resolución y unificación con ciertodetalle.

Luego examinamos la perspectiva de bases de datos por la teoría de demostraciones. En esta perspectiva, la base de datos es considerada como si consistiera en la combinación de una base de datos extensional y una base de datos intensional. La base de datos extensional con-tiene axiomas base, es decir, los datos base (en general); la base de datos intensional contiene restricciones de integridad y axiomas deductivos, es decir, vistas (de nuevo, en general). El "significado" de la base de datos consiste entonces en un conjunto de teoremas que pueden ser deducidos a partir de los axiomas; la ejecución de una consulta llega a ser (al menos concep-tualmente) un proceso de demostración de teoremas. Un DBMS deductivo es un DBMS que soporta esta perspectiva de la teoría de demostraciones. Describimos brevemente a Datalog, un lenguaje de usuario para estos DBMSs.

Una diferencia inmediata entre Datalog y los lenguajes relaciónales tradicionales es que Datalog soporta axiomas recursivos y por lo tanto consultas recursivas, aunque no hay razón por la cual el álgebra y el cálculo relaciónales tradicionales no deban ser extendidos para que hagan lo mismo (vea la explicación del operador TCLOSE en el capítulo 6).* Tratamos algunas técnicas simples para la evaluación de dichas consultas.

En conclusión: iniciamos este capítulo mencionando varios términos —"bases de datos ló-gicas", "DBMS inferencial", "DBMS deductivo", etcétera— que a menudo se encuentran en la literatura de investigación (y hasta cierto punto, incluso en los anuncios de los fabricantes). Por

*Con respecto a esto, es interesante observar que los DBMSs relaciónales deben tener de todas formas la posibilidad de realizar procesamiento recursivo en segundo plano, debido a que el catálogo contendrá cierta información estructurada en forma recursiva (las definiciones de vistas expresadas en términos de otras definiciones de vistas son uno de estos casos).


lo tanto, cerremos el capítulo proporcionando algunas definiciones para esos términos. Sin embargo, queremos prevenirlo que no siempre hay consenso sobre estos temas, por lo que es probable que encuentre diferentes definiciones en la literatura. Las siguientes definiciones son mis preferidas:

■ Procesamiento de consultas recursivas. Ésta es fácil. El procesamiento de consultas recursivas se refiere a la evaluación y, en particular, a la optimización de consultas cuya definiciónes intrínsecamente recursiva (vea la sección 23.7).

■ Base de conocimientos. Este término a menudo es usado con el significado de lo que en lasección 23.6 llamamos la base de datos intensional; es decir, consiste en las reglas (las restricciones de integridad y axiomas deductivos), en oposición a los datos básicos los cualesconstituyen la base de datos extensional. Pero otros escritores usan ocasionalmente "basede conocimientos" para que signifique la combinación de las bases de datos intensional y extensional (vea a continuación "base de datos deductiva"); con excepción de que, como lo dicela referencia [23.10], "una base de conocimientos con frecuencia incluye objetos complejos [así como] relaciones clásicas" (vea la parte VI de este libro para una explicación sobrelos "objetos complejos"). Luego, el término tiene de nuevo otro significado más específicoen los sistemas de lenguaje natural. Probablemente lo mejor es evitarlo por completo.

■ Conocimientos. ¡Otra fácil! Conocimientos es lo que hay en la base de conocimientos... Porlo tanto, esta definición reduce el problema de la definición de "conocimientos" a un problema anterior no resuelto.

■ KBMS (Sistemas de Administración de Base de Conocimientos). Es el software que administra la base de conocimientos. Por lo general, el término se usa como un sinónimo para elDBMS deductivo (vea el siguiente párrafo).

■ DBMS deductivo. Es un DBMS que soporta la perspectiva de bases de datos por la teoría dedemostraciones y que en particular es capaz de deducir información adicional a partir de labase de datos extensional mediante la aplicación de reglas de inferencia (es decir, deductivas)que están guardadas en la base de datos intensional. Un DBMS deductivo casi seguramentesoportará reglas recursivas y por lo tanto, realizará procesamiento de consultas recursivas.

■ Base de datos deductiva (término desaprobado). Es una base de datos que es administradapor un DBMS deductivo.

■ DBMS experto. Es un sinónimo para el DBMS deductivo.

■ Base de datos experta (término desaprobado). Es una base de datos que es administrada porun DBMS experto.

■ DBMS inferencial. Es un sinónimo para el DBMS deductivo.

■ Sistema basado en la lógica. Es un sinónimo para el DBMS deductivo.

■ Base de datos lógica (término desaprobado). Es un sinónimo para la base de datos deductiva.

■ La lógica como un modelo de datos. Es un modelo de datos que consiste (al menos) en objetos, reglas de integridad y operadores. En un DBMS deductivo, los objetos, las reglas deintegridad y los operadores están representados de la misma manera uniforme, concretamente como axiomas en un lenguaje lógico como Datalog; de hecho, como explicamos enla sección 23.6, una base de datos en un sistema de éstos puede ser considerada precisamente como un programa lógico que contiene axiomas de los tres tipos. Por lo tanto, en unsistema de éstos podemos decir legítimamente que el modelo de datos abstracto para el sistema es la lógica misma.

SISTEMAS DE BASES DE DATOS DEDUCTIVAS

Documents

Transcript of SISTEMAS DE BASES DE DATOS DEDUCTIVAS