Sadcil: sistema de administración de conocimiento basado en inferencias lógicas

Texto completo

(1)ISC-2003-2-33. SADCIL: Sistema de Administración de Conocimiento Basado en Inferencias Lógicas. Carlos Rafael Robles Núñez. Universidad de los Andes Facultad de Ingeniería Departamento de Sistemas y Computación Bogotá 2003.

(2) ISC-2003-2-33. SADCIL: Sistema de Administración de Conocimiento Basado en Inferencias Lógicas. Carlos Rafael Robles Núñez Tesis para optar el título de Ingeniero de Sistemas y Computación Asesor: José Abásolo Prieto. Universidad de los Andes Facultad de Ingeniería Departamento de Sistemas y Computación Bogotá 2003.

(3) ISC-2003-2-33. A mi madre, por enseñarme a construir castillos en el aire; a mi esposa, por su apoyo incondicional, sin ella no hubiese podido terminar de construir el mío..

(4) ISC-2003-2-33. AGRADECIMIENTOS Dentro del ámbito académico agradezco a todos los profesores que hicieron parte de mi formación profesional, en especial a mi asesor de tesis José (Pepe) Abásolo. Doy gracias a Dios, por la forma como hizo que el universo conspirara para que pudiera llevar a feliz termino mis metas; a mis padres Cecilia y Carlos Emilio (El Chato); a mis hermanos Claudia, Juan José, Alicia Rosa y Andrés Felipe; y a mi esposa Ivón, por su apoyo incondicional y por nunca perder la fe en mi. Agradezco a Ildemaro (Marito) Vega y. Robinsón Cano por arriesgarse en la forma como lo. hicieron, solo basados en la amistad y la confianza.. A mi abuelo Celestino Núñez (Q.E.P.D.) y a. mi tía Emelina Núñez, quienes autónomamente supieron brindar ayuda desinteresada en el momento preciso. Por ultimo, le doy las gracias a quienes creyeron siempre en mi, por su apoyo moral; también a quienes nunca lo hicieron, estos últimos me animaron a demostrarles que si se podía..

(5) ISC-2003-2-33. TABLA DE CONTENIDO 1.. INTRODUCCIÓN .............................................................................................................................. 1. 2.. OBJETIVO GENERAL...................................................................................................................... 2. 3.. OBJETIVOS ESPECÍFICOS............................................................................................................. 2. 4.. JUSTIFICACIÓN ............................................................................................................................... 3. 5.. ALCANCE .......................................................................................................................................... 3. 6.. MARCO TEÓRICO ........................................................................................................................... 4 6.1 SISTEMAS BASADOS EN CONOCIMIENTO ............................................................................................... 4 6.2 CONSTRUCTORES BÁSICOS DE PROGRAMACIÓN LÓGICA ......................................................................... 4 6.2.1 Hechos ......................................................................................................................................... 5 6.2.2 Consultas ..................................................................................................................................... 5 6.2.3 Reglas.......................................................................................................................................... 6 6.3 MODELO DE DATOS LÓGICOS ............................................................................................................... 7 6.3.1 ¿Qué es un modelo de Datos? ....................................................................................................... 7 6.3.2 Predicados extensionales e Intencionales....................................................................................... 8 6.3.3 Fórmulas Atómicas....................................................................................................................... 8 6.3.4 Predicados Built-In....................................................................................................................... 8 6.3.5 Cláusulas y Cláusulas de Horn...................................................................................................... 9 6.3.6 Grafos de dependencia y Recursión ............................................................................................ 10 6.3.7 Reglas Seguras ........................................................................................................................... 10 6.3.8 Calculando reglas recursivas....................................................................................................... 11 6.4 FUNCIONES COMO ARGUMENTOS ........................................................................................................ 12. 7.. SISTEMA PROPUESTO.................................................................................................................. 14 7.1 ANÁLISIS ........................................................................................................................................... 15 7.1.1 Usuarios del Sistema .................................................................................................................. 15 7.1.2 Reglas del Negocio..................................................................................................................... 15 7.1.3 Glosario de Términos ................................................................................................................. 15 7.1.4 Diagramas de Casos de Uso........................................................................................................ 17 7.1.5 Requerimientos Funcionales ....................................................................................................... 20 7.1.6 Matriz de Contexto..................................................................................................................... 31 7.1.7 Requerimientos No Funcionales ................................................................................................. 33 7.2 DISEÑO ............................................................................................................................................. 33 7.2.1 Arquitectura ............................................................................................................................... 33 7.2.2 Diagrama de Paquetes ................................................................................................................ 37 7.2.3 Diagrama de Clases .................................................................................................................... 38 7.3 AMBIENTE DE IMPLANTACIÓN ............................................................................................................ 39. 8. CONCLUSIONES ................................................................................................................................ 40 9. BIBLIOGRAFÍA .................................................................................................................................. 41 10.ANEXOS.............................................................................................................................................. 42 10.1 ESTADO DE LA RECURSIÓN EN SQL................................................................................................... 42 10.2 EJEMPLO DE CÓMO CONECTAR XSB A BASE DE DATOS RELACIONALES ............................................... 43 10.3 EJEMPLO DE CÓMO INVOCAR XSB DESDE JAVA CON INTERPROLOG.................................................... 44 10.4 CONVERSIÓN DE PREDICADOS LÓGICOS A CONSULTAS EN BASE DE DATOS RELACIONALES................... 45.

(6) ISC-2003-2-33. 1. 1. INTRODUCCIÓN Los sistemas manejadores de bases de datos han resultado claves en la evolución de los negocios.. El poder tener la información organizada con integridad y soportar toda la. transaccionalidad del día a día, son sus principales ventajas.. Sin embargo, los usuarios. necesitaban poder consultar en un tiempo adecuado la información y mas aún garantizar que esta información estuviera depurada; para solventar esta situación se crearon las herramientas OLAP y toda la tecnología de Data WareHouse.. Una vez se organizó la información, se vió la posibilidad. de comenzar a explorar los datos mas allá de lo obvio, fue entonces cuando se desarrollaron las diferentes herramientas de Data Mining. Con el auge de la metodología orientada a objetos y el desarrollo de la Web, los sistemas manejadores de bases de datos se enfrentan nuevamente a problemas para los que no estaban preparados.. Se requieren manejadores que no solamente se integren de la mejor manera a las. tecnologías OO sino que el programador se despreocupe de cómo están guardadas las clases de su negocio.. Dicho en otras palabras los manejadores deberían entender en forma natural las. consultas hechas por los usuarios y no tener que pasar a tablas las estructuras de los objetos. Por otra parte, el desarrollo de la Web ha ocasionado que Internet sea la fuente de consulta de primera mano.. Es enorme la cantidad de información que se encuentra diseminada por toda la. red y se hace prioritario trabajar con herramientas de búsqueda mucho mas poderosas, lo que da origen a la Web Semántica.. Dentro de este contexto resulta imperativo la inclusión de un. lenguaje declarativo dentro de los sistemas manejadores de bases de datos con el fin de poder realizar consultas y/o inferencias sobre la información pero a un costo muy bajo de programación, tal como lo hacen los motores lógicos. Dentro de las consultas que se desean realizar, existe un tipo en particular, las recursivas, a las cuales muy pocos manejadores tienen forma de responder y ninguno lo hace en una manera atrayente al programador, el cual tiene que utilizar una sintaxis bastante compleja, para poder responder una consulta recursiva directamente y en algunos manejadores que no tienen implementada esta funcionalidad, toca programar procedimientos almacenados para responder consultas de este tipo. En este trabajo veremos cómo la mezcla de dos tecnologías motores relacionales y motores lógicos ayudan a resolver adecuadamente el problema de las inferencias sobre la información, combinando el poder del motor lógico para realizar inferencias y el del motor relacional para guardar información y consultarla eficientemente..

(7) 2. ISC-2003-2-33. 2. OBJETIVO GENERAL El objetivo general es desarrollar un componente de software capaz de ofrecer una interfaz tipo Prolog sobre grandes volúmenes de datos persistentes.. 3. OBJETIVOS ESPECÍFICOS 1. Evaluar el estado de la recursión propuesto en el estándar SQL99 y su implementación en 1. los diferentes Sistemas manejadores de Bases de Datos . 2. Desarrollar un componente con interfaz tipo Prolog basado en un motor lógico y manejo de persistencia de datos extensionales en un motor relacional. 3. Desarrollar una aplicación Web con arquitectura multicapas para acceso interactivo de la base de conocimiento. 4. Desarrollar un Web Services para brindar el servicio de base de conocimiento a otras aplicaciones. 5. Publicar el software en un sitio Web de la Universidad.. 1. Ver anexo 10.1.

(8) 3. ISC-2003-2-33. 4. JUSTIFICACIÓN La búsqueda de información sobre grandes repositorios de datos requiere de motores de inferencias a la vez poderosos y declarativos. 2. Semántica .. Esta es una idea central del concepto de Web. Las bases de datos lógicas o de conocimientos se ajustan a este perfil.. Lenguajes. como SQL u OQL cumplen con las primeras características pero su sintaxis no es la mas amigable. Actualmente existen motores lógicos como software libre, que para manejar la persistencia de 3 datos extensionales pueden conectarse con diferentes tipos de bases de datos relaciónales,. combinando de esta forma el poder de las inferencias de las bases de datos lógicas con el almacenamiento y acceso eficiente de las bases de datos relacionales. Escribir predicados lógicos, con la practica, es mas sencillo que consultas de SQL u OQL, sin embargo, si se utiliza una herramienta lógica directamente para conectarse a una base de datos relacional, los pasos necesarios son. engorrosos y el resultado de la consulta solo estará. disponible por la ventana de comandos, adicionalmente esta información no está compartida.. Por. estos motivos, el tener una herramienta fácil de usar, que permita: compartir información para crear una base de conocimiento, multiusuario y que adicionalmente haga transparente todas las conexiones entre las diferentes motores, son razones suficientes para el desarrollo del tema.. 5. ALCANCE El componente podrá usar como repositorio para el manejo de persistencia cualquier manejador de bases de datos relacional que pueda accederse vía ODBC y JDBC; cuyo catalogo pueda consultarse vía SQL. En este trabajo se hizo énfasis en la funcionalidad y no tanto en el desempeño.. Una versión. posterior se ocupará de este tema.. 2. [BER2001] También llamados Hechos, si el lector no está relacionado con programación lógica, este concepto es explicado en la sección 6.2.1.. 3.

(9) 4. ISC-2003-2-33. 6. MARCO TEÓRICO Los conceptos explicados en este aparte solo pretenden servir como base para la compresión del resto del documento.. Si se desea obtener información mas profunda sobre algún tema se. recomienda mirar las referencias bibliográficas [ULL1988], [ULL1989] y [STE1986]. Se comenzará por las definiciones de Sistemas Basados en conocimientos, se repasarán los componentes de la programación lógica y por ultimo se explicaran los temas relacionados al modelo de datos lógico.. 6.1 Sistemas Basados en Conocimiento El termino conocimiento es utilizado hoy en día como un atributo de los sistemas de programación que soportan en algún nivel lenguajes declarativos. Un sistema de conocimiento, es un sistema que provee un lenguaje declarativo que juega los roles de lenguaje de manipulación de datos y el lenguaje del host en un sistema manejador de bases de 4 datos .. 6.2 Constructores básicos de programación lógica5 Los constructores básicos de la programación lógica son los términos y las sentencias. tres tipos básicos de sentencias: hechos, reglas y las consultas.. Existen. Adicionalmente existe una. estructura de datos conocida como término.. 4 5. [ULL1988] Las definiciones de los conceptos explicados en esta sección fueron traducidos de [STE1986]..

(10) 5. ISC-2003-2-33. 6.2.1 Hechos Un hecho es el sentido que tiene una relación entre objetos, a esta relación también se le conoce como predicado.. 6 Por ejemplo el hecho padre(abraham,isaac) significa que Abraham es el. padre de Isaac, la semántica del hecho es dada por el programador,. lo que implica que cuando. se define el hecho, implícitamente también se define el roll que juega cada uno de los objetos o de los átomos que tiene el predicado.. Por ejemplo una definición para el predicado padre podría ser. padre(papa,hijo), pero el programador también podría definir padre(hijo,papa), el hecho mencionado anteriormente tendría que cambiarse por padre(isaac,abraham).. A diferencia del. modelo relacional donde las columnas se definen con un nombre, en programación lógica el roll del objeto depende de la posición que tenga éste dentro del predicado.. 6.2.2 Consultas Un punto bastante interesante de la programación lógica es que un simple conjunto de hechos, es por si mismo, un programa.. Aún con una sola línea que expresa el hecho padre(abraham,. isaac), un motor lógico ya esta en capacidad de responder cuatro preguntas elementales. padre(X,isaac).. A lo cual responderá X =abraham.. padre(abraham,Y).. A lo cual responderá Y = isaac.. padre(abraham, isaac).. A lo cual responderá que Sí.. padre(X,Y).. A lo cual responderá X =abraham Y = isaac, si existieran mas hechos padre, el resultado serían todas las tuplas de la relación.. Podemos notar ciertos aspectos interesantes, primero la similitud entre un hecho y una consulta, la sintaxis son prácticamente la misma, solo que la consulta puede o no contener variables. Dentro de las reglas básicas de sintaxis es que tanto los hechos como los argumentos de los hechos (átomos) comienzan por minúsculas mientras que las variables comienzan por mayúsculas. Así las cosas en las consultas anteriores X y Y son variables e isaac y abraham son constantes.. 6. En programación lógica las constantes comienzan por minúsculas y las variables comienzan por mayúsculas, es por eso que el predicado se escribe padre(abraham, isaac) y no padre(Abraham, Isaac)..

(11) ISC-2003-2-33. 6. Podríamos realizar otra consulta de la siguiente forma padre(abraham, sara) a lo que el motor lógico responderá que no, no necesariamente porque abraham no sea el padre de sara sino porque no existe un hecho con esta información.. 6.2.3 Reglas Como vimos anteriormente con solo escribir hechos, el motor lógico es capaz de responder consultas sencillas, estas consultas también pueden ser más complejas y adicionalmente pueden involucrar recursión, pero se siguen invocando de la misma forma, en otras palabras, las reglas encapsulan funcionalidad para contestar preguntas más complejas. Por ejemplo supongamos los siguientes hechos padre(abraham, isaac). padre(isaac, jacob). Vamos a definir una regla a la que llamaremos ancestro, la cual definiremos semánticamente como la relación que existe genealógicamente entre un hijo con su padre, abuelo, bisabuelo, etc. ancestro(X,Y):-padre(X,Y). ancestro(X,Z):-padre(X,Y),ancestro(Y,Z). Dentro de la definición de la regla tenemos en cuenta lo siguiente: ancestro(X,Y) se define como padre(X,Y), así las cosas ancestro(abrahan,isaac) y ancestro(isaac,jacob) al consultarlos al motor lógico en ambos la respuesta sería Sí.. Visto de esta forma no representa mayor ventaja. tener una regla, pero de la línea 2 de la definición obtenemos lo siguiente: se dice que X es ancestro de Z, si X es padre de Y y adicionalmente Y es ancestro de Z, lo que origina una recursión, si ahora preguntamos ancestro(abraham,jacob) el motor lógico contestará que Sí, mas aún podemos preguntar por todos los ancestros de jacob de la siguiente manera ancestro(X,jacob) y el motor responderá que X=abraham,isaac o podríamos preguntar por todos los descendientes de abraham a lo que el motor responderá que ancestro(abraham,Y), Y=isaac, jacob. Lo mas interesante de la programación lógica es que las inferencias son realizadas automáticamente por el motor lógico, o sea, no hay que programarlas, basta con escribir los hechos y escribir las reglas y el motor se encargará de realizar las inferencias necesarias..

(12) ISC-2003-2-33. 7. 6.3 Modelo de Datos lógicos7 6.3.1 ¿Qué es un modelo de Datos? 8 Un modelo de datos es un formalismo matemático que consta de dos partes :. 1. Notación para describir datos y 2. Un conjunto de operaciones usadas para manipular los datos. Dentro de los modelos de datos tenemos: modelo relacional, modelo de red, modelo jerárquico, modelo orientado a objetos y modelo lógico.. Es sobre este último que se concentrará toda la. atención. Este modelo comúnmente llamado Datalog por su origen, al ser un Prolog para manejar sistemas de bases de datos.. Sin embargo Datalog difiere de Prolog en que el primero solo permite. variables y constantes como argumentos de los predicados, o sea no admite funciones, sin embargo este tema se tratará mas adelante. El modelo matemático de Datalog es esencialmente el mismo del modelo relacional. predicados en Datalog denotan relaciones.. Los. Sin embargo difieren del álgebra relacional en que. los atributos de la relación no tienen nombres en sus columnas, sino que son referenciadas en el mismo orden en que el predicado las expresa o sea que el orden no se puede cambiar. Por ejemplo se define el predicado padre como padre(papa, hijo), predicados ejemplos de padre serian padre(abraham, isaac) quiere decir que abraham es el padre de isaac, sin embargo si se coloca el predicado al contrario es decir padre(isaac, abrahan) significará que isaac es el padre de abraham, es responsabilidad del programador preservar el orden en que el predicado define su semántica.. 7. Los conceptos y algoritmos utilizados en esta parte del documento fueron traducidos de [ULL1998] 8 [ULL1988].

(13) 8. ISC-2003-2-33. 6.3.2 Predicados extensionales e Intencionales. Una diferencia importante entre los modelos de datos relacionales y lógico es que en el modelo lógico las relaciones se pueden definir de dos maneras.. Un predicado que se guarda en la base. de datos se conoce como predicado extensional (EDB), un ejemplo padre(adán, caín) esta guardado en la base de datos mientras que un predicado definido por medio de una regla lógica (calculado, no está guardado en la base de datos) se conoce como un predicado intencional (IDB).. 6.3.3 Fórmulas Atómicas Los programas de Datalog son construidos a partir de formulas atómicas, por ejemplo p(A1,A2,…,An), donde p es el símbolo del predicado y Ai son los argumentos, como se mencionó anteriormente, un argumento puede ser una constante o una variable.. Para Datalog las. constantes comienzan por minúsculas y las variables comienzan por mayúsculas, todas las cadenas que comienzan por números son consideradas constantes.. 6.3.4 Predicados Built-In También se pueden escribir fórmulas donde se utilicen comparaciones matemáticas, por ejemplo =, <, etc., a este tipo de fórmula se les llama predicados built-int es importante destacar que el resultado de este tipo de predicados puede llegar a no ser finito.. Este tipo de predicado resulta. muy útil para la definición de las reglas, pues permite realizar comparación de elementos y hasta operaciones matemáticas..

(14) 9. ISC-2003-2-33. 6.3.5 Cláusulas y Cláusulas de Horn Un literal es una fórmula atómica o una fórmula atómica negada.. Se denotarán las formulas. atómicas negadas como ┐p(A1,…,An). Una cláusula es una suma (O lógicos) de literales. Una cláusula de Horn es una cláusula en la cual al menos un literal es positivo o cualquiera de las siguientes: 1. Un solo literal positivo, por ejemplo padre(X,Y) que es llamado un hecho. 2. Uno o mas literales negados, sin ningún literal positivo, en los cuales existe integridad y los cuales no serán considerados en nuestra discusión de Datalog. 3. Un literal positivo y uno o mas literales negativos, los cuales son llamados reglas. La razón para la cláusula 3 es que: ┐p1v┐p2v… v ┐pnvq es lógicamente equivalente a p1Λp2Λ… Λ pn→q. Al pasar a Datalog p1Λp2Λ… Λ pn→q. queda de la siguiente forma: q:- p1Λp2Λ… Λ pn. Donde la parte que aparece antes de :- se conoce como el nombre de la regla y la parte del predicado que aparece después de :- se conoce como el cuerpo de la regla. Ejemplo de un programa en Datalog: hermano(X,Y):- padre(X,Z), padre(Y,Z) , X/=Y. primo(X,Y):- padre(X,Xp), padre(Y,Yp) , hermano(Xp,Yp). primo(X,Y):- padre(X,Xp), padre(Y,Yp) , primo(Xp,Yp). pariente(X,Y):- hermano(X,Y). pariente(X,Y):- pariente(X,Z) , padre (Y,Z). pariente (X,Y):- pariente(Z,Y) , padre(X,Z). Adicional a las reglas siguen los hechos del predicado padre, con los cuales se alimentan las reglas para producir los resultados, para este ejemplo padre es un predicado extensional, mientras que hermano, primo y pariente son predicados intencionales..

(15) 10. ISC-2003-2-33. 6.3.6 Grafos de dependencia y Recursión En ocasiones necesitamos saber cuales predicados dependen de otros, los predicados que en un grafo de dependencia tengan un ciclo se conocen como predicados recursivos.. Los que no tienen. ciclos se conocen como predicados no recursivos. Como lo podemos apreciar en la figura 1, los predicados padre y hermano no son recursivos mientras que los predicados primo y pariente si son recursivos, primo por ejemplo busca los primos en segundo, tercer y n-esimo grado.. Figura 1. Grafo de dependencia del programa del punto anterior.. 9. 6.3.7 Reglas Seguras Existen ciertas restricciones que se deben tener en cuenta al momento de escribir los programas en Datalog con el fin de evitar las relaciones infinitas.. Para garantizar que no se den relaciones. como la siguiente mayorque(X,Y):-X>Y si ejecutamos mayorque(X,Y) de seguro da una relación infinita, es mas la misma ejecución de mayorque(1,Y) nos daría como resultados infinitos de Y. Para asegurarnos que esto no ocurra, existen unas reglas sencillas que se deben cumplir al momento de escribir los programas en Datalog. 1. Una variable que aparece como argumento y además aparece en un predicado del cuerpo esta limitada. 2. Una variable X que aparece en el cuerpo en una comparación del estilo X=a o a=X, donde a es constante esta limitada. 3. Una Variable X que aparece en el cuerpo en una comparación del estilo X=Y o Y=X, donde Y es una variable que esta limitada, también esta limitada..

(16) 11. ISC-2003-2-33. Se define que una regla es segura si todas sus variables están limitadas.. 6.3.8 Calculando reglas recursivas Resolver reglas no recursivas no representa problema para los motores lógicos, en realidad el trabajo duro aparece cuando las reglas son recursivas y esa dificultad es inyectada por las relaciones intencionales que se definen en las reglas. Para resolver las reglas recursivas se utiliza el siguiente algoritmo10: Entradas: Una colección de reglas de Datalog con predicados EDB r1,…,rk y predicados IDB p1,…,pm. También, una lista de relaciones R1,…,Rk que sirven como valores para los predicados EDB. Salidas: Al menos una solución de punto fijo a la ecuación de Datalog obtenida de esas reglas. Método: Se comienza estableciendo las ecuaciones para las reglas. variables P1,…,Pm que corresponden a predicados IDB, Pi=EVAL(pi,R1,…,Rk,P1,…,Pm).. y. Esas ecuaciones tienen la ecuación para Pi. es. Se inicializa luego cada Pi a el conjunto vacío y se aplica EVAL. repetidamente para obtener nuevos valores para Pi’s. al conjunto, el algoritmo se detiene.. Cuando no se pueden adicionar mas tuplas. Se supone que EVAL es monótona, una propiedad que. quiere decir que si se agregan nuevos registros ninguno de los registros que se tienen en el resultado desaparece.. for i:=1 to m do Pi := Ø; repeat for i:=1 to m do Qi := Pi; /*salva los viejos valores de Pi’s */ for i:=i to m do Pi := EVAL(pi,R1,…,Rk,Q1,…,Qm); until Pi=Qi for all i, 1≤i≤m; Output Pi’s Algoritmo 1. Evaluación Simple de Ecuaciones Recursivas. 9. Tomado y traducido de [ULL1988]. [ULL1988] Tanto el algoritmo 1 como el 2 son tomados de esta referencia. 10.

(17) ISC-2003-2-33. 12. Existe una mejora a este algoritmo que se le conoce como Semi-naive la cual lo que busca es no tener que calcular siempre pi con el EVAL sino que calcula un ∆pi lo cual lo hace mas eficiente, en lugar de terminar cuando Pi=Qi termina cuando el ∆pi es vació. for i:=1 to m do begin ∆Pi:=EVAL(pi,R1,…,Rk,Ø,…,Ø); Pi:= ∆Pi; end; repeat for i:=1 to m do ∆Qi:= ∆Pi; /*salva los viejos valores de ∆P’s */ for i:=1 to m do begin ∆Pi:=EVAL_INC(Pi,R1,…,Rk,P1,…,Pm, ∆Q1,…, ∆Qm); ∆Pi:= ∆Pi-Pi /*remueve las tuplas que ya aparecían */ end for i:=1 to m do Pi:=Pi U ∆Pi; until ∆Pi=Ø for all i; output Pi’s Algoritmo 2. Evaluación Semi-naive de Ecuaciones Recursivas. 6.4 Funciones como argumentos Como se mencionó anteriormente los argumentos de los predicados se limitaban a variables y constantes, sin embargo en ocasiones es mejor utilizar términos que pueden ser variables , constantes y funciones.. Los términos11 pueden ser definidos recursivamente así:. 1. Una variable es un término 2. Una constante es un término 3. Si f es una función, y T1,…,Tk son términos, entonces f(T1,…,Tk) es un término. Entre los usos que se le pueden dar a las funciones como argumentos es la de incorporar a las relaciones algunas de las estructuras del modelo jerárquico, así por ejemplo empleado podría guardar un EDB de un empleado con la siguiente estructura empleado(nombre(Apellido,Nombre), direccion(Calle,Numero,ciudad)). 11. [ULL1989].

(18) ISC-2003-2-33. 13. Otras de las utilidades, cuando mayor provecho se le saca es la utilización de funciones lógicas recursivamente, se puede apreciar en el siguiente ejemplo:. natural(0). natural(suc(X)):-natural(X). suma(0,X,X):-natural(X). suma(suc(X),Y,suc(Z)):-suma(X,Y,Z). multiplicar(0,X,0). multiplicar(suc(X),Y,Z):-multiplicar(X,Y,W),suma(W,Y,Z). exponente(suc(X),0,0). exponente(0,suc(X),suc(0)). exponente(suc(N),X,Y):-exponente(N,X,Z),multiplicar(Z,X,Y).. El ejemplo muestra como se pueden definir los naturales a partir de una función como argumento suc(X), a partir de la definición de los naturales desarrolla reglas mas avanzadas como la suma, la multiplicación y la potenciación..

(19) 14. ISC-2003-2-33. 7. SISTEMA PROPUESTO El sistema debe cubrir todo el proceso de construcción, publicación y consultas sobre los modelos de inferencias lógicas basados en datos guardados en una base de datos relacional. La metadata del sistema debe guardarse en el mismo esquema donde están guardados los datos, es decir que el mismo repositorio contendrá tanto los datos del negocio como la información de las estructuras de los modelos de inferencias lógicas. El sistema debe contar con un modulo de construcción de modelos, el cual debe permitir la administración de los modelos de inferencias lógicas (creación, modificación, eliminación.. Estos. modelos, son los mundos sobre los cuales se va a trabajar. Una vez creados los modelos de inferencias lógicas, el sistema debe permitir definir elementos dentro de éstos.. Dichos elementos son los Hechos y las Reglas.. El sistema permitirá definir los. hechos y asociarles la fuente de datos (tablas, vistas o consultas dentro del repositorio) que contiene la información de donde se va a alimentar.. Por otro lado, el sistema debe proveer un. editor de reglas con un validador para las mismas. Cuando un modelo se encuentre estable, o sea sin errores, el sistema debe permitir la publicación del contenido del modelo para que éste pueda ser consultado.. El sistema apoyará toda la. administración de seguridad, pues permitirá configurar el nivel de acceso de los usuarios a los modelos e incluso a las reglas, para esto nos apoyaremos en unas vistas de los modelos, llamadas submodelos..

(20) 15. ISC-2003-2-33. 7.1 Análisis 7.1.1 Usuarios del Sistema Los actores del sistema son: Administrador Se encarga de la creación de los demás usuarios del sistema Constructor de Modelos Su función es administrar todo lo concerniente a los modelos y a los usuarios con sus respectivos niveles de seguridad. Tiene acceso a todos los servicios del sistema. Analista La función principal de este actor es realizar consultas sobre los modelos.. 7.1.2 Reglas del Negocio. No. 1 2 3. Definición Solamente se pueden consultar los modelos que estén publicados. Para publicar un modelo se necesita que sus hechos y sus reglas no tengan errores. Al momento de crear un usuario se necesita al menos crearle un submodelo.. Tipo de Regla. Estática/ Dinámica. Fuente. Acción Restricción Acción Restricción. Estática. Carlos Robles. Estática. Carlos Robles. Acción Restricción. Estática. Carlos Robles. 7.1.3 Glosario de Términos •. Modelo:. Es el mundo sobre el cual vamos a trabajar, es el contenedor de hechos y reglas. que permiten hacer inferencias. •. Submodelo:. Es una vista del modelo, en esta se pueden limitar el acceso a los hechos y. las reglas del modelo y dentro de los cuales se pueden crear reglas propias. •. Hechos:. Son los datos de base sobre los que se basan las inferencias. Tienen un sentido. semántico que es especificado por el que los crea. •. Reglas:. Son las definiciones que se hacen dentro del modelo, están escritas en lenguaje. lógico y por lo general incluyen recursión, las hay de dos tipos las públicas que son creadas por.

(21) 16. ISC-2003-2-33. el constructor del modelo y las privadas que solo aplican a los Submodelos y son creadas por los analistas. •. Publicar: Hacer público a los demás usuarios.. Para el caso del Constructor de modelos al. momento de publicar un modelo, los usuarios que según la configuración de seguridad tengan acceso al nuevo modelo, podrían realizar consultas sobre este.. Para el caso del usuario. analista podría publicar la definición de una consulta y los demás usuarios tendrían acceso a esta definición y podrían ejecutarla..

(22) ISC-2003-2-33. 7.1.4 Diagramas de Casos de Uso Módulo Administrativo Parte 1: Modelos, Hechos y Reglas. Esta parte se encarga de la administración de los modelos, hechos y reglas.. 17.

(23) ISC-2003-2-33. 18. Módulo Administrativo Parte 2: Publicación, Usuarios y Submodelos (Seguridad) Esta parte del módulo se encarga de la publicación del modelo para que los usuarios finales lo puedan consultar, la creación de portafolios públicos que son los repositorios donde los usuarios finales pueden publicar consultas, la administración de usuarios y la seguridad del sistema donde se configura que usuarios pueden ver que modelos, cuales reglas dentro del modelo y cuales portafolios públicos pueden acceder..

(24) ISC-2003-2-33. 19. Módulo Consultas Este módulo se encarga de la creación de consultas, la publicación y exportación a otros formatos de los resultados de las mismas..

(25) ISC-2003-2-33. 20. 7.1.5 Requerimientos Funcionales Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Iteración: Resumen: Curso Básico Eventos:. Caminos de Excepción: Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones: Autor: Fecha: Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Iteración: Resumen: Curso Básico Eventos:. Caminos de Excepción: Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones: Autor: Fecha:. CU-SADCIL-01 Crear Modelo Necesario Alta Finished El constructor de modelos crea un nuevo modelo. 1. El constructor de modelos requiere crear un nuevo Modelo. 2. El constructor de modelos ingresa los datos básicos para la creación del modelo: el nombre corto (código máximo 8 caracteres), un nombre largo (descripción) y propósito (una pequeña leyenda donde explique los objetivos del modelo. 3. El sistema valida la información ingresada por el constructor de modelos y si no encuentra dentro del repositorio un modelo con el mismo nombre lo crea. • En el punto 3 si ya existe un Modelo con el nombre corto o largo que el Constructor de modelos le quiere colocar al modelo, el sistema informa el error y solicita un nuevo nombre para el nuevo modelo.. Ninguna Un nuevo modelo ha sido creado en el repositorio. Carlos Rafael Robles Núñez 07 Marzo 2003 CU-SADCIL-02 Modificar Modelo Necesario Media Finished El constructor de modelos del sistema modifica los datos de un modelo. 1. El constructor de modelos selecciona cambiar los datos de un modelo. 2. El constructor de modelos ingresa el identificador del modelo a modificar. 3. El sistema presenta alternativas para modificar nombre largo y propósito. 4. El constructor de modelos modifica los datos del modelo 5. El sistema actualiza los cambios • En el punto 2 si el modelo no existe en el sistema se informa el error y solicita nuevamente el identificador del modelo. El modelo existe en el sistema. Se modificaron los datos del modelo. Carlos Rafael Robles Núñez 07 Marzo 2003.

(26) ISC-2003-2-33. Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Iteración: Resumen: Curso Básico Eventos:. Caminos de Excepción: Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones: Autor: Fecha:. Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Iteración: Resumen: Curso Básico Eventos:. Caminos Alternativos: Caminos de Excepción: Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones: Autor: Fecha:. 21. CU-SADCIL-03 Eliminar Modelo Necesario Baja Finished El constructor de modelos elimina un modelo existente. 1. El constructor de modelos desea eliminar un modelo 2. El constructor de modelos ingresa el nombre corto del modelo a eliminar. 3. El sistema elimina del repositorio el modelo e invalida todas las consultas que tienen que ver con este modelo. • En el punto 3 si el modelo no existe en el repositorio, el sistema informa el error y solicita nuevamente el nombre corto del modelo a eliminar. El modelo a eliminar debe existir en el repositorio El modelo se ha eliminado del repositorio Carlos Rafael Robles Núñez 07 Marzo 2003. CU-SADCIL-04 Crear Hecho Necesario Alta Finished El Constructor de modelos define hechos para un modelo. 1. El constructor de modelos selecciona el modelo sobre el cual va a definir el nuevo hecho. 2. El constructor de modelos ingresa los datos necesarios para la definición del los hechos, nombre del hecho o predicado, semántica del hecho (una pequeña descripción del hecho), numero de átomos, nombre, tipo y roll de cada átomo dentro del hecho. 3. El Constructor de modelos selecciona la fuente de datos para el hecho y se encarga de empalmar cada columna de la fuente de datos con cada uno de los átomos del hecho. 4. El sistema valida que el matching efectivamente cuadre. 5. El sistema guarda en el repositorio la definición del hecho y la información de la fuente de datos para ser utilizada en tiempo de consulta.. Ninguna Un nuevo hecho se ha creado para el modelo. Carlos Rafael Robles N 07 Marzo 2003.

(27) ISC-2003-2-33. Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Iteración: Resumen: Curso Básico Eventos:. Caminos Alternativos: Caminos de Excepción: Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones: Autor: Fecha: Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Iteración: Resumen: Curso Básico Eventos:. Caminos Alternativos: Caminos de Excepción: Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones: Autor: Fecha:. 22. CU-SADCIL-05 Modificar Hecho Necesario Media Finished El constructor de modelos modifica un hecho dentro de un modelo. 1. El Constructor de modelos digita el nombre del modelo al cual se le va a modificar el hecho. 2. El constructor de modelos selecciona el hecho al cual le va a realizar la modificación. 3. El constructor realiza las modificaciones necesarias tanto de la definición como las de fuentes de datos. 4. El sistema guarda en el repositorio la nueva definición de hechos.. La definición del hecho existe El hecho no esta cargado, indica que solo existe la definición pero que no hay datos en los hechos. La definición del hecho ha sido modificada. Carlos Rafael Robles Núñez 07 Marzo 2003 CU-SADCIL-06 Eliminar Hecho Necesario Baja Finished El constructor de modelos elimina un hecho. 1. El Constructor de modelos digita el nombre del modelo al cual se le va a eliminar la definición de un hecho. 2. El constructor de modelos selecciona el hecho a eliminar. 3. El sistema elimina el hecho del repositorio.. La definición del hecho existe. La definición del hecho ha sido eliminada, junto con sus contenidos si los había. Carlos Rafael Robles Núñez 07 Marzo 2003.

(28) ISC-2003-2-33. Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Iteración: Resumen: Curso Básico Eventos:. Caminos de Excepción: Rutas Alternativas Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones: Autor: Fecha: Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Iteración: Resumen: Curso Básico Eventos:. Caminos de Excepción: Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones: Autor: Fecha:. 23. CU-SADCIL-07 Crear Regla Necesario Alta Finished El Constructor de modelos o el Analista crea una nueva regla en el modelo/submodelo. 1. El constructor de modelos o el analista selecciona el modelo/submodelo al que se le va a crear la nueva regla. 2. El constructor de modelos o el analista digita la nueva regla en el editor de reglas, además le asigna un nombre. 3. El sistema valida la regla. 4. La nueva regla es guardada en el repositorio. En el paso 3 si la regla presenta algún error se le informa al constructor de modelos para su corrección, si de todas formas desea salvarla se le advierte que esta regla esta inconsistente.. Ninguna Una nueva regla ha sido adiciona en el repositorio. Carlos Rafael Robles Núñez 07 Marzo 2003 CU-SADCIL-08 Modificar Regla Necesario Media Finished El Constructor de modelos o el Analista modifica una regla existente en el modelo/submodelo. 1. El constructor de modelos o el analista selecciona el modelo/submodelo al que se le va a modificar la nueva regla. 2. El constructor de modelos o el analista modifica la regla en el editor de reglas, además si es el constructor de modelos y la regla es privada la puede hacer publica al modelo al modelo de la que se derivó el submodelo. 3. El sistema valida la regla modificada 4. La regla modificada es guardada en el repositorio. En el paso 3 si la regla presenta algún error se le informa al constructor de modelos para su corrección, si de todas formas desea salvarla se le advierte que esta regla esta inconsistente.. Ninguna La regla modificada ha sido guardada en el repositorio. Carlos Rafael Robles Núñez 07 Marzo 2003.

(29) ISC-2003-2-33. Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Iteración: Resumen: Curso Básico Eventos:. Caminos de Excepción: Rutas Alternativas Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones: Autor: Fecha: Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Iteración: Resumen: Curso Básico Eventos:. Caminos de Excepción: Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones: Autor: Fecha:. 24. CU-SADCIL-09 Eliminar Regla Necesario Baja Finished El Constructor de modelos o el Analista elimina una regla del modelo/submodelo. 1. El constructor de modelos o el analista seleccionan el modelo/submodelo al cual le van a eliminar la regla. 2. El constructor de modelos o el analista eliminan la regla. 3. El sistema elimina la regla del repositorio.. Ninguna La regla ha sido eliminada del modelo/submodelo dependiendo del caso. Carlos Rafael Robles Núñez 07 Marzo 2003 CU-SADCIL-10 Validar Modelo Necesario Alta Finished El Constructor de modelos valida la consistencia del modelo, reglas y hechos. 1. El constructor de modelos selecciona el modelo a validar 2. El sistema informa el estado del modelo, dependiendo de la consistencia de los hechos y las reglas. 3. El sistema actualiza el estado del modelo.. Ninguna El estado del modelo ha sido actualizado a valido o inválido según el caso. Carlos Rafael Robles Núñez 07 Marzo 2003.

(30) ISC-2003-2-33. Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Iteración: Resumen: Curso Básico Eventos:. Caminos de Excepción: Rutas Alternativas Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones: Autor: Fecha: Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Iteración: Resumen: Curso Básico Eventos: Caminos de Excepción: Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones: Autor: Fecha:. 25. CU-SADCIL-11 Publicar Modelo Necesario Alta Finished El Constructor de modelos hace público el modelo, a partir de este instante los usuarios autorizados a consultar el modelo lo podrán utilizar. 1. El constructor de modelos selecciona el modelo a publicar 2. El sistema verifica que el modelo este en un estado valido. 3. El modelo es marcado en el repositorio como visible, desde este momento los Submodelos derivados del modelo seleccionado se podrán consultar.. El modelo es valido. El modelo es marcado como visible. Carlos Rafael Robles Núñez 07 Marzo 2003 CU-SADCIL-12 Ocultar Modelo Deseable Baja Finished El Constructor de modelos oculta temporalmente el modelo, puede ser por actualización del mismo. 1. El constructor de modelos selecciona el modelo que quiere ocultar. 2. El modelo es marcado como oculto. 3. El sistema deshabilita los Submodelos que dependen del modelo oculto.. Ninguna. Tanto el modelo cono los Submodelos que dependen de el están deshabilitados y no se pueden consultar. Carlos Rafael Robles Núñez 07 Marzo 2003.

(31) ISC-2003-2-33. Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Iteración: Resumen: Curso Básico Eventos: Caminos de Excepción: Rutas Alternativas Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones: Autor: Fecha:. Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Iteración: Resumen: Curso Básico Eventos: Caminos de Excepción: Rutas Alternativas Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones: Autor: Fecha:. 26. CU-SADCIL-13 Crear Usuario Necesario Alta Finished El Constructor de modelos crea un nuevo usuario. 1. El constructor de modelos digita los datos del nuevo usuario, nombre, identificación, password. 2. El sistema crea un nuevo registro de usuario en el repositorio. En el paso 1 el constructor de modelos debe hacer uso del caso de uso CUSADCIL-16 crear submodelo para el usuario. Ninguna Un nuevo usuario ha sido creado. Carlos Rafael Robles Núñez 07 Marzo 2003. CU-SADCIL-14 Modificar Usuario Necesario Media Finished El Constructor de modelos modifica un usuario existente. 1. El constructor de modelos selecciona el usuario al cual va a modificar 2. El constructor de modelos cambia los datos del usuario 3. El sistema registra los cambios del usuario en el repositorio. En el paso 2, el constructor de modelos puede hacer uso de los casos de uso CU-SADCIL-16, CU-SADCIL-17 o CU-SADCIL-18 que son crear, modificar o eliminar submodelo. Después de terminada la modificación el usuario debe quedar con al menos un submodelo asociado. Ninguna Los datos modificados del usuario han sido guardados. Carlos Rafael Robles Núñez 07 Marzo 2003.

(32) ISC-2003-2-33. Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Iteración: Resumen: Curso Básico Eventos: Caminos de Excepción: Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones: Autor: Fecha: Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Iteración: Resumen: Curso Básico Eventos:. Caminos de Excepción: Rutas Alternativas Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones: Autor: Fecha:. 27. CU-SADCIL-15 Eliminar Usuario Necesario Baja Finished El Constructor de modelos elimina un usuario existente. 1. El constructor de modelos selecciona el usuario que desea eliminar. 2. El sistema elimina el usuario del repositorio junto con todos los Submodelos asociados a este usuario.. Ninguna Tanto el usuario como los Submodelos relacionados con el han sido eliminados. Carlos Rafael Robles Núñez 07 Marzo 2003 CU-SADCIL-16 Crear Submodelo Necesario Alta Finished El Constructor de modelos crea un nuevo submodelo con base en un modelo existente, limitando los hechos y las reglas que podrá ver el usuario al cual se le va a asociar el submodelo. 1. El constructor de modelos selecciona el usuario al cual se le va a crear el submodelo. 2. El constructor de modelos selecciona el modelo del cual se va a copiar el submodelo. 3. El constructor de modelos selecciona cuales reglas y hechos van a ser heredados por el submodelo. 4. El constructor de modelos califica el submodelo como editable/no editable lo cual le permitirá al analista administrar reglas privadas en el submodelo. 5. El sistema guarda la información del nuevo submodelo en el repositorio.. El modelo y el usuario existen. El modelo es valido y visible. Un nuevo Submodelo ha sido creado para el usuario. Carlos Rafael Robles Núñez 13 Marzo 2003.

(33) ISC-2003-2-33. Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Iteración: Resumen: Curso Básico Eventos:. Caminos de Excepción: Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones: Autor: Fecha: Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Iteración: Resumen: Curso Básico Eventos:. Caminos de Excepción: Rutas Alternativas Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones: Autor: Fecha:. 28. CU-SADCIL-17 Modificar Submodelo Necesaria Media Finished El Constructor de modelos modifica un submodelo, adicionando o eliminando hechos y/o reglas del submodelo. 1. El constructor de modelos selecciona el usuario al cual se le va a modificar un submodelo. 2. El constructor de modelos selecciona el submodelo a modificar. 3. El constructor de modelos selecciona/deselecciona cuales reglas y hechos van a ser heredados por el submodelo. 4. El constructor de modelos califica el submodelo como editable/no editable lo cual le permitirá al analista administrar reglas privadas en el submodelo. 5. El sistema guarda la información del submodelo modificado en el repositorio.. El modelo y el usuario existen Ninguna Se han modificado un submodelo. Carlos Rafael Robles Núñez 13 Marzo 2003 CU-SADCIL-18 Eliminar Submodelo Necesaria Baja Finished El Constructor de modelos elimina un submodelo. 1. El constructor de modelos selecciona el usuario al cual se le va a eliminar un submodelo. 2. El constructor de modelos selecciona el submodelo a eliminar. 3. El sistema verifica que no sea el único submodelo y elimina el submodelo seleccionado.. El usuario tiene mas de un submodelo. El submodelo ha sido eliminado de los Submodelos del usuario. Carlos Rafael Robles Núñez 13 Marzo 2003.

(34) ISC-2003-2-33. Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Iteración: Resumen: Curso Básico Eventos:. Caminos de Excepción: Rutas Alternativas Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones: Autor: Fecha:. Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Iteración: Resumen: Curso Básico Eventos:. Caminos de Excepción: Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones: Autor: Fecha:. 29. CU-SADCIL-19 Explorar Modelo Necesario Alta Finished El Constructor de modelos o el Analista consultas cuales hechos y/o reglas están disponibles para ejecución. 1. El constructor de modelos o el analista selecciona la opción de explorar modelo. 2. El sistema muestra los hechos y/o las reglas disponibles para el usuario que esta consultando.. Ninguna Ninguna Carlos Rafael Robles Núñez 07 Marzo 2003. CU-SADCIL-20 Ejecutar Regla Necesario Alta Finished El Constructor de modelos o el Analista ejecutan una consulta sobre el modelo, la consulta tiene que estar previamente creada y debe estar en un estado valido. 1. El constructor de modelos o el analista seleccionan una regla a ejecutar 2. El sistema solicita los parámetros de entrada si hubiese 3. El constructor de modelos introducen el valor de los parámetros. 4. El sistema procesa la regla y muestra el resultado tabular.. Ninguna. Ninguna. Carlos Rafael Robles Núñez 07 Marzo 2003.

(35) ISC-2003-2-33. Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Iteración: Resumen: Curso Básico Eventos:. Caminos de Excepción: Rutas Alternativas Puntos de Extensión: Triggers: Suposiciones: Pre-condiciones: Post- Condiciones: Autor: Fecha:. 30. CU-SADCIL-21 Explorar Base de Datos Necesario Alta Finished El Constructor de modelos consultas la estructura de tablas y columnas de la base de datos relacional con la cual esta conectador para construir el modelo. 1. El constructor de modelos selecciona la opción de explorar base de datos. 2. El sistema muestra las tablas y dentro de cada tabla la información de las columnas disponibles para crear hechos.. Ninguna Ninguna Carlos Rafael Robles Núñez 07 Marzo 2003.

(36) 31. ISC-2003-2-33. 7.1.6 Matriz de Contexto Número. Caso de Uso. 1. Crear Modelo. 2. Modificar Modelo. 3. Eliminar Modelo. 4. Crear Hecho. 5. Modificar Hecho. 6. Eliminar Hecho. 7. Crear Regla. 8. Modificar Regla. 9. Eliminar Regla. 10. Validar Modelo. 11. Publicar Modelo. 12. Ocultar Modelo. 13. Crear Usuario. 14. Modificar usuario. 15. Eliminar Usuario. 16. Crear Submodelo. 17. Modificar Submodelo. 18. Eliminar Submodelo. 19. Explorar Modelo. Resumen. Core. El constructor de modelos crea un nuevo modelo. El constructor de modelos del sistema modifica los datos de un modelo. El constructor de modelos elimina un modelo existente. El Constructor de modelos define hechos para un modelo. El constructor de modelos modifica un hecho dentro de un modelo. El constructor de modelos elimina un hecho. El Constructor de modelos o el Analista crea una nueva regla en el modelo/submodelo. El Constructor de modelos o el Analista modifica una regla existente en el modelo/submodelo. El Constructor de modelos o el Analista elimina una regla del modelo/submodelo. El Constructor de modelos valida la consistencia del modelo, reglas y hechos. El Constructor de modelos hace público el modelo, a partir de este instante los usuarios autorizados a consultar el modelo lo podrán utilizar. El Constructor de modelos oculta temporalmente el modelo, puede ser por actualización del mismo. El Constructor de modelos crea un nuevo usuario. El Constructor de modelos modifica un usuario existente. El Constructor de modelos elimina un usuario existente. El Constructor de modelos crea un nuevo submodelo con base en un modelo existente, limitando los hechos y las reglas que podrá ver el usuario al cual se le va a asociar el submodelo. El Constructor de modelos modifica un submodelo, adicionando o eliminando hechos y/o reglas del submodelo. El Constructor de modelos elimina un submodelo. El Constructor de modelos o el Analista consultas cuales reglas están disponibles para ejecución.. SI. Este caso de uso depende. SI. 1. SI. 1. SI. 1. SI. 4. SI. 4. SI. 4. SI. 7. SI. 7. SI. 1,4,7. SI. 1. NO. 1. SI SI. 13. SI. 13. SI. 10,13. SI. 10,13,16. SI. 10,13,16. SI. 16.

(37) 32. ISC-2003-2-33. 20. Ejecutar Regla. 21. Explorar Base de Datos. El Constructor de modelos o el Analista ejecutan una regla (consulta) sobre el modelo, la consulta tiene que estar previamente creada y debe estar en un estado valido. El Constructor de modelos consultas la estructura de tablas y columnas de la base de datos relacional con la cual esta conectador para construir el modelo.. SI. NO. 11,16.

(38) ISC-2003-2-33. 33. 7.1.7 Requerimientos No Funcionales ID Requerimiento. Tipo. P Afecta a. Excepciones. Consecuencias. 1. Desarrollo. 3 1-21. Ninguna. Se dificulta la utilización del sistema por parte del usuario.. Operacional. 1 1-21. Ninguna. La información puede ser consultada ó modificada por cualquier usuario.. Desarrollo. 1 7,8,9,19, 20,21. En horas de Se pueden la noche bloqueos.. Operacional. 4 1-21. Para las Existe mayor probabilidad consultas no de equivocación al ingresar existe ó modificar la información. confirmación.. Desarrollo. 5 Esto Ninguna afecta en el diseño y no en los requerimi entos 2 1-21 Ninguna. 2. 3. 4. 5. 7. Se debe especificar un estándar gráfico y un estándar de nombres para el acceso a la información. Es necesario que el sistema realice autenticación de usuarios El sistema debe permitir concurrencia en las consultas. El sistema debe solicitar confirmación a los usuarios antes de ejecutar operaciones. El lenguaje de programación debe ser JAVA y debe funcionar en ambiente Web.. Se debe utilizar Desarrollo Ant, Javadoc, Log4j, CVS y Junit.. presentar. Insatisfacción.. Dificultad en el mantenimiento, pruebas y documentación. 7.2 Diseño 7.2.1 Arquitectura Sadcil es un componente que le permite al desarrollador poder realizar inferencias lógicas sobre bases de datos relacionales y al usuario final hacer consultas en modo interactivo de una manera amigable ya que este no tiene que saber Prolog para realizar esta tarea.. Adicionalmente Sadcil. provee las herramientas para crear bases de datos de conocimientos porque las consultas realizadas se pueden documentar y compartir con todos los usuarios del sistema, por ultimo por.

(39) ISC-2003-2-33. 34 tratarse de un componente EJB de sesión potencia el producto brindando posibilidad de acceso concurrente a la información. En la Figura 2 se puede apreciar la arquitectura de Sadcil.. Figura 2. Arquitectura de SADCIL (Sistema de Administración de Conocimiento basado en Inferencias Lógicas). El aplicativo como tal comienza en el SadcilBean, sin embargo para efectos prácticos se desarrolló una interfaz grafica para que los usuarios puedan ejecutar el aplicativo sin necesidad de escribir código; los desarrolladores si deberían trabajar desde la parte del EJB. El cliente por medio de un Browser se encarga de realizar las solicitudes al Servidor Web realizando validaciones de primer nivel como campos requeridos y tipos de datos por medio de JavaScript.. El servidor Web contesta en formato XML utilizando varios esquemas (*.xsd) que se. incluyen en los anexos, el servidor Web también envía las hojas de estilo (*.xsl) para que el Browser se encargue de la transformación del XML en HTML, de esta manera la tarea de presentación queda como responsabilidad del Browser. El servidor Web tiene instalado un Servlet cuya única función es servir de controlador, recibe las peticiones del cliente, se las delega al EJB y el resultado de las peticiones (XML) es enviado al cliente junto con las hojas de estilos necesarias (XSL). En el servidor de aplicaciones encontramos el EJB de sesión SadcilBean; éste se encarga de la comunicación con Datalog y con el Sistema manejador de base de datos..

(40) ISC-2003-2-33. 35 La comunicación con el sistema manejador de base de datos la realizamos utilizando JDBC, el único requisito es que el SMDB tenga tablas de diccionario de donde se pueda sacar la información de las tablas y las columnas de las tablas, esto se hace necesario para la conversión de las tablas relaciones en tablas Extensionales en el Datalog. 12 La comunicación con el Datalog se realiza por medio de Interprolog .. Esta librería se encarga de. comunicar el mundo Java con el mundo Prolog, para el caso específico de Sadcil se esta trabajando con XSB, del cual hablaremos mas adelante.. Dentro de las funcionalidades que. provee Sadcil permite el desentendimiento completo de esta parte, ya que para el desarrollador es transparente y solo tendrá que interactuar con objetos de Java con métodos públicos que le permitirán realizar las consultas y configurar sobre cuales tablas de las bases de datos relacionales se harán, sin entrar en configuraciones ni comunicaciones de Java con XSB y viceversa. Por ultimo, XSB que es el componente sobre el cual se baso el desarrollo.. XSB es un sistema. que tiene funcionalidades de Prolog y adicionalmente de bases de datos deductivas, es desarrollado por el departamento de ciencias de la computación de Stonny Brook University y la herramienta puede ser bajada de http://xsb.sourceforget.net. XSB provee funcionalidad para conectarse a base de datos relacionales por medio de ODBC, esta configuración que se realiza por medio de comandos de XSB también es transparente al desarrollador que utiliza Sadcil.. El EJB sesión se encarga de brindar la funcionalidad de navegar. por las diferentes tablas del modelo de datos, mostrar la información de las columnas de cada una de esas tablas y permitir la configuración de tablas Extensionales a partir de tablas relaciónales. Una vez definidas las tablas Extensionales quedan a disposición de XSB para poder utilizarlas en inferencias directamente o poder definir reglas con las mismas para potenciar las inferencias.. En resumen la funcionalidad que brinda Sadcil se puede mirar de la siguiente forma: 1. Construir Modelos de inferencias lógicas en ambiente Java, basados en bases de datos relacionales sin necesidad de interactuar con XSB, Interprolog. 2. Poder consultar los modelos de inferencias lógicas, utilizando predicados, los cuales son mas naturales al programador que las sentencias de SQL recursivo que define el estándar de SQL99. 3. Tener los resultados de las consultas directamente sobre el aplicativo de ejemplo o poder tener estos resultados como objetos de una clase llamada SadcilResultSet que seria equivalente a la clase ResultSet de estos modelos utilizando reglas definidas en Prolog. 12. Interprolog es un componente de XSB y se puede bajar del sitio http://xsb.sourceforget.net.

(41) ISC-2003-2-33. 36 4. Funcionalidad multiusuario. 5. Capacidad de crear una base de datos de conocimiento documentada y cooperativa ya que los mismos usuarios se encargan de ir documentando las reglas y compartirlas con los demás haciéndolas publicas..

(42) ISC-2003-2-33. 37. 7.2.2 Diagrama de Paquetes. Figura 3. Diagrama de Paquetes. Como se puede apreciar en la figura 3, el paquete central y a la vez el mas importante se llama Sadcil, dentro de este paquete están las definiciones de los modelos, las reglas y las tablas extensionales.. Los otros paquetes cumplen funciones de soporte para Sadcil de la siguiente. manera: Paquete DB:. Es el encargado de la comunicación con las bases de datos relacionales, ya sea. para acceso a los datos de las tablas extensionales o para guardar la información de los modelos de Sadcil en forma persistente. Paquete File:. Su función principal es generar los archivos con la información de las reglas para. que sean procesados por el motor lógico. Paquete Datalog: Es el paquete auxiliar mas importante pues se encarga de la comunicación con el motor lógico, la configuración en línea de las tablas extensionales basados en la información de la base de datos relacional, la compilación de los archivos de las reglas, realizar las consultas y devolver las respuestas..

(43) ISC-2003-2-33. 38 Paquete XML: Su función se centra en realizar transformaciones a XML de respuestas enviadas por Datalog a Sadcil. Paquete HTML: Es un paquete que solo se utiliza cuando se utiliza la herramienta en forma interactiva o sea como usuario final, las clases de este paquete sirven para ayudar a formatear la información en formato HTML para la presentación en Web.. 7.2.3 Diagrama de Clases. Figura 4. Diagrama de Clases paquete Sadcil.

(44) ISC-2003-2-33. 39. 7.3 Ambiente de Implantación El lenguaje de programación utilizado fue Java, como motor lógico se utilizó el software XSB. 13. Versión 2.6, el cual puede ser bajado de la pagina http://xsb.sourceforge.net, se seleccionó este motor por ser software libre, adicionalmente para la conexión de Java con XSB se utilizó 14 Interprolog .. Para la conexión de Java con las bases de datos relacionales, se utilizó JDBC, para las conexiones con bases de datos Oracle se hace necesario classes12.zip, adicionalmente se necesita un driver ODBC, el cual depende del motor relacional al que nos vamos a conectar. En el motor seleccionado como deposito de las tablas extensionales también se guarda la información de los modelos de Sadcil, el volumen de datos manejados para los modelos es muy bajo -básicamente las reglas y la configuración de las tablas de las bases de datos relacionales que contienen la información de las tablas extensionales. Como servidor de aplicaciones se utilizó Jboss, como servidor Web se utilizó Tomcat y para la implementación del Web Services se utilizó Java WSDP 1.3.. 13. XSB es un sistema de programación lógica y base de datos deductiva que funciona en Windows y Unix. Está siendo desarrollado en el departamento de ciencias de la computación de Stony Brook University, con colaboración de Katholieke Universiteit Leuven, Universidade Nova de Lisboa, Uppsala Universitet y XSB Inc. 14 Puede ser bajado de http://www.declarativa.com/interprolog/.

(45) ISC-2003-2-33. 40. 8. CONCLUSIONES Las bases de datos lógicas son una buena opción para ser utilizadas como motores de inferencias en aplicaciones complejas tales como búsquedas en una Web Semántica. Existen versiones libres de motores lógicos que están evolucionando; sin embargo actualmente solo ofrecen funcionalidad mas no eficiencia en el manejo de grandes volúmenes de datos, si estos se encuentran guardados en una base de datos relacional.. Si por el contrario los datos se. encuentran guardados en sus propios formatos, nos enfrentaríamos a un problema de información replicada con todas las implicaciones de la duplicidad. La separación de hechos en bases de datos relacionales y las reglas en los formatos de archivos propios de los motores lógicos, es actualmente la forma más apropiada para distribuir la información.. Se esperaría que las dos tecnologías converjan, pero resultaría mas fácil que los. motores relacionales incluyeran un lenguaje declarativo que un motor lógico trabajar en el largo camino de optimización que han recorrido las casas de desarrollo de bases de datos relacionales. Las versiones libres de los motores son monousuario y no permiten compartir la información, uno de los aportes de este trabajo fue incluirlos en un componente, lo que permite poder ser utilizados por diferentes usuarios y/o aplicaciones y además la información se comparte para crear una base de conocimiento..

(46) ISC-2003-2-33. 41. 9. BIBLIOGRAFÍA [BER2001]. Berners-Lee, Tim. The Semantic Web, Scientific American, May 2001.. [DRA1992]. Draxler, C. Prolog to SQL compiler, Version 1.0. Technical report, CIS Centre for Information and Speech Processing Ludwig-Maximilians-University, Munich, 1992.. [SAG2002]. Sagonas, Konstantinos., Otros. The XSB System Version 2.5, Volumen I y II, Programmer’s Manual, Marzo 11 de 2002.. [STE1986]. Sterling Leon, Shapiro Ehud. The Art of Prolog, Advanced Programming Techniques, MIT Press. 1986.. [ULL1988]. Ullman, Jeffrey. Principles of Database and knowledge-base system, Volumen I, Stanford University, Science Computer Press, 1988.. [ULL1989]. Ullman, Jeffrey. Principles of Database and knowledge-base system, Volumen II: The New Technologies, Stanford University, Computer Science Press, 1989.. URL’S http://xsb.sourceforge.net http://www.declarativa.com/interprolog.

(47) ISC-2003-2-33. 42. 10.ANEXOS 10.1 Estado de la recursión en SQL Actualmente los manejadores se pueden clasificar de la siguiente manera: SMBD. Recursión. DB2. Si. Oracle 9i. Si. Postgres, Microsoft SQL Server. No. Observación Cumple ANSI SQL3 Esta implementada pero no cumple con el ANSI SQL3. Básicamente la recursión se hace a través de procedimientos almacenados. Equivalencias XSB, DB2 y Oracle 9i. XSB. DB2. Oracle. Ancestros de Ismael. ?- ancestro(X,ismael).. with recursive anc(padre, hijo) as (select * from ancestro) union (select p.padre,a.hijo from ancestro p, anc a where p.hijo=a.padre) select anc.padre from anc where anc.hijo='ismael';. SELECT rownum,padre FROM ancestro CONNECT BY PRIOR padre= hijo START WITH hijo= 'ismael';. Descendientes de Andres. ?- ancestro(andres,Y).. with recursive anc(padre, hijo) as (select * from ancestro) union (select p.padre,a.hijo from ancestro p, anc a where p.hijo=a.padre) select anc.hijo from anc where anc.padre='andres';. SELECT rownum, hijo FROM ancestro CONNECT BY PRIOR hijo= padre START WITH padre= 'andres';.

(48) ISC-2003-2-33. 43 10.2 Ejemplo de cómo conectar XSB a base de datos relacionales En este ejemplo nos conectáremos a una base de datos Oracle, cuyo string de conexión es BD9i, nos conectaremos con el usuario system, contraseña manager. Dentro del esquema de la base de datos existe una tabla llamada ancestro, con dos columnas: padre e hijo; con esta información crearemos el hecho padre en XSB. C:\XSB\config\x86-pc-windows\bin>xsb [xsb_configuration loaded] [sysinitrc loaded] [packaging loaded] XSB Version 2.5 (Okocim) of March 11, 2002 [x86-pc-windows; mode: optimal; engine: slg-wam; gc: indirection; scheduling: local] | ?- import odbc_open/3 from odbc_call.15 yes | ?- odbc_open(‘BD9i’,’system’,’manager’). yes | ?- import odbc_import/2 from odbc_call. yes | ?- odbc_import('ANCESTRO'('PADRE','HIJO'),'padre'). yes | ?- [ancodbc]. [Compiling .\ancodbc] [ancodbc compiled, cpu time used: 0.4000 seconds] [ancodbc loaded] yes | ?- ancestro(X,carlos). SELECT rel1.PADRE , rel1.HIJO FROM Ancestro rel1 WHERE rel1.HIJO = ?; X = juan, SELECT rel1.PADRE , rel1.HIJO FROM Ancestro rel1; SELECT rel1.PADRE , rel1.HIJO FROM Ancestro rel1 WHERE rel1.PADRE = ? AND rel1. HIJO = ?; X = pedro, SELECT rel1.PADRE , rel1.HIJO FROM Ancestro rel1 WHERE rel1.PADRE = ?; no | ?- ancestro(X,ismael). X = francisco, X = pedro, X = pablo, X = andres, No | ?- ancestro(andres,Y). Y = francisco, Y = ramon, Y = mario, Y = ismael, no | ?- halt. End XSB (cputime 403.56 secs, elapsetime 403.55 secs). 15. [SAG2002] ver los manuales de XSB para buscar información adicional de los predicados odbc_open y odbc_import..

(49) ISC-2003-2-33. 44 16. 10.3 Ejemplo de cómo invocar XSB desde Java con Interprolog import com.declarativa.interprolog.*; import com.xsb.interprolog.*; public class ancestro{ public static void main(String args[]) { PrologEngine engine = new SubprocessEngine(args[0]); Object[] bindings; engine.command("import append/3 from basics"); engine.command("[ancestro]");. //Se llama a XSB para consultar los ancestros de juan respuesta unica bindings = engine.deterministicGoal("ancestro(Xpadre,juan)","[string(Xpadre)]"); System.out.println("\nAncestros de Juan:"+bindings[0]+"\n"); //Se llama a XSB para consultar los ancestros de ismael, respuesta multiple. String G = "(ancestro(X,ismael))"; String T = "X"; String GG = "findall(TM, ("+G+",buildTermModel("+T+",TM)), L), ipObjectSpec('ArrayOfObject',L,LM)"; Object[] solutions = (Object[])engine.deterministicGoal(GG,"[LM]")[0]; System.out.println("Numero de soluciones :"+solutions.length); for(int I=0;I<solutions.length;I++) { System.out.println("Solution "+I+":"+solutions[I]); } System.exit(0); } }. 16. Adaptación de código expuesto en http://www.declarativa.com/interprolog/faq.htm sobre como conectarse con Java a XSB, se modificó para consultar el programa ancestro..

(50) ISC-2003-2-33. 45 10.4 Conversión de predicados lógicos a consultas en base de datos relacionales 17. Los predicados a bases de datos son traducidos de acuerdo a las siguientes reglas : • Las Disyunciones (OR) son traducidas como distintas consultas SQL conectadas por el operador UNION. • Las conjunciones (AND) son traducidas a joins. • Las negaciones son traducidas a subconsultas con NOT EXISTS. • Las variables de ocurrencia única no son traducidas. • Las variables libres son traducidas como GROUP BY. • Las variables ligadas son traducidas a las condiciones del join con una igualdad. • Las constantes traducen como condiciones del join con la constante a un lado de la igualdad. • Nulos son traducidos a la condición IS NULL.. 17. [DRA1992].

(51)