Professional Documents
Culture Documents
TESIS
que para obtener el grado de
Presenta:
Asesor:
I INTRODUCCIÓN
II SISTEMAS BASADOS EN CONOCIMIENTO
III SISTEMAS EXPERTOS
IV .-ARQUITECTURA DE UNA BDI
V PROGRAMACIÓN DE UNA BDI
VI ESTADO DEL ARTE
VII CONCLUSIONES BIBLIOGRAFÍA
Mayo 8, 1999.
Por medio de este conducto, informo a ese Consejo Técnico de Posgrado que el
C. Sergio Antonio Becerra Zepeda, terminó su período de revisión de tesis para:
Bajo el título:
“BASES DE DATOS INTELIGENTES”
1. INTRODUCCIÓN
2. SISTEMAS BASADOS EN CONOCIMIENTO
3. SISTEMAS EXPERTOS
4. ARQUITECTURA DE UNA BDI
5. PROGRAMACIÓN DE UNA BDI
6. ESTADO DEL ARTE
CONCLUSIONES
el cual cumple con los requisitos necesarios para su aprobación, por lo cual lo
autorizo para su impresión.
Atentamente
Will it to be possible than does a machine make the same
as make the human brings when do think ?
Turing 1950
I Abstract
I Abstract
Descripción:
Presenta:
Me. Sergio Antonio Becerra Zepeda
Candidato al Grado de Maestro en Ciencias Computacionales.
Validación:
Universidad de Colima
Facultad de Ingeniería Mecánica y Eléctrica
Maestría en Ciencias Computacionales.
Junio, 1999.
II. Tabla de Contrenidos
I Abstrac
II Tabla de contenidos
1. Introducción
2.1 Antecedentes 4
3. Sistemas Expertos
3.1 Antecedentes 31
3.2 Programación lógica en sistemas expertos 32
5.2.1 Recordset 66
5.2.2 Database Object 68
5.2.3 SQL en Visual Basic 70
5.2.4 Edición de las Bases persistente y en intenso 88
5.2.4.1 Representación gráfica de los datos 92
4.3.2 Manipulación de la base en intenso 95
5.3 Archivos binarios 96
5.4 Filtrado y preproceso 105
7. Conclusiones
1. Introducción
2.1 Antecedentes
Una clasificación primaria de los SGBD, nos permite establecer los tipos básicos según
el tipo de estructura de datos que soporta:
tablas, en las que los conjuntos de registros tienen un formato fijo e idéntica
estructura. El enfoque relaciona1 en bases de datos parte del modelo relaciona1 en
matemáticas y, por tanto, son susceptibles de aplicar al minio todas las
formulaciones teóricas que éste presenta; en objetivos posteriores desarrollamos
una descripción exhaustiva de este enfoque, puesto que el prototipo BDI, de
nuestro estudio utiliza un SGBD relaciona1 (Microsoft Jet).
Una característica de los tres primeros modelos mencionados es que sólo aceptan
datos escalares individuales tipificados y nulos ("NULL"). Como característica general,
los esquemas han sido desarrollados con la capacidad de operar sobre datos “ideales”,
en el supuesto de que la información a procesar es exacta, correcta y bien definida.
En 1970 se propuso el modelo relacional, basado en los trabajos del Dr. Codd,
básicamente el modelo matemático que dio fundamentos a la segunda generación de
SGBD, caracterizada por una mayor independencia físico-lógica, dado que actúan
sobre conjuntos de registros; entre ellas destacan ORACLE, DB2, INGRES, INFORMIX,
SYBASE, etc. Codd propuso un modelo simple de datos en el que todos ellos se
representarían en tablas constituidas por filas y columnas. A dichas tablas se les dio en
nombre matemático de relaciones, denominándose así el sistema como relacional.
Codd también propuso dos lenguajes para manipular los datos en las tablas: álgebra y
cálculo relacional, que soportan la manipulación de los datos sobre la base de
operadores lógicos en lugar de los punteros físicos utilizados en los modelos jerárquicos
y de red. El resultado fue la aparición de sistemas relacionales durante la última mitad
de los setenta que soportaban lenguajes como el Structured Query Language (SQL), el
Query Language (Quel) y el Query-by-Example(QBE): los trabajos de investigación que
se realizaron durante la década de los ochenta se centraron en la optimización de
consultas, lenguajes de alto nivel, teoría de la normalización, organizaciones físicas
para el almacenamiento de las relaciones, algoritmos para la gestión de memorias
intermedias (buffers), técnicas de indexación para un acceso asociativo más rápido
(distintas variaciones de los árboles), sistemas distribuidos, diccionarios de datos,
gestión de transacciones, etc. Estas investigaciones han tenido como consecuencia la
elevada tasa de transacciones de muchos de los productos actuales que permiten
asegurar entornos transaccionales en línea (OLTP) muy eficientes y seguros. También
cabe recordar que durante la primera mitad de los ochenta se estandariza el lenguaje
SQL (el SQUANSI se aprueba en 1986), ofreciendo, al cabo de poco tiempo,
prácticamente todos los productos una interfaz SQL, aún los no relacionales (sistemas
“renacidos”).
Nivel Definición
Conceptual Nivel estructural de la base de datos que define su esquema lógico.
Externo Nivel estructural de la base de datos que define las vistas de los
usuarios.
Interno Nivel estructural de la base de datos que define la vista física.
Tabla 1. Arquitectura de tres niveles.
Este tipo de sistema no es considerado como una base de datos en el sentido estricto
del término; será hasta que aparezcan los primeros ficheros u archivos en los que
pueda almacenarse la descripción de los datos (catálogo o diccionario) que
consideremos la primer clasificación de SGBD (Clásicos), aún cuando prácticamente
todas las restricciones sobre los datos se comprueban en los programas.
2. Sistemas basados en conocimiento 11
Aunque, normalmente, en lugar de utilizar un lenguaje como Prolog (que procesa una
tupla a la vez) se suele emplear un lenguaje relaciona1 declarativo denominado
DATALOG, que es poco procedimental y orientado a conjuntos, lo que lo hace más
adecuado para bases de datos. Sintácticamente el DATALOG es muy parecido al
Prolog, existiendo en la actualidad diferentes versiones. Este tipo de lenguajes resulta
muy útil para hacer consultas de tipo recursivo, siendo clásica la de los ancestros de
una persona (conociendo que los padres de una persona son sus ancestros, así como
los padres de los ancestros). Sin embargo, todavía no existen productos comerciales
que puedan incluirse en esta categoría, aunque algunas de sus nociones se van
incorporando en la nueva generación de SGBD relacionales-activos”
Algunos aspectos en los que se considera necesaria una mayor investigación, son:
combinar acceso declarativo y acceso navegacional, soportar completamente la
funcionalidad de los objetos compuestos, acceso a los metadatos, almacenamiento de
los servicios (métodos) en la base de datos, definición dinámica de clases, mecanismos
para definir restricciones y disparadores, gestión de la extensión de las clases, soporte
de vistas y lenguajes de consulta y de optimización, es conveniente particularizar que
en febrero de 1997 en reunión del grupo ISO/IEC JTC1/SC21M/G3 se presentó la
solicitud de aprobación del SQL3 (las partes Foundafion, Bindings, Persistent Stored
Modules y Object) como norma internacional con efectos a diciembre de 1998;
actualmente existe una sólida convergencia entre OQL y SQL3.
Los sistemas de base relacional han sido diseñado específicamente para soportar el
procesamiento analítico de los datos: On Line Analytical Processing (OLAP),
representan los datos mediante matrices de n dimensiones denominadas “hipercubos”
asignando a cada dimensión un dominio específico jerarquizado, cada casilla del
hipercubo contiene datos agregados (información de...) que relacionan los elementos
entre las distintas dimensiones, de hecho, éstas actúan como apuntadores para
identificar los valores dentro de la matriz.
El simple concepto dado, puede causar confusión ya que muchos sistemas basados en
programas convencionales podrían ser incorrectamente categorizados como sistemas
basados en conocimiento.
Esta inconsistencia puede ser aclarada, sobre la base de tres conceptos fundamentales
que distinguen a los sistemas basados en conocimiento de los programas algorítmicos
convencionales y de los programas generales basados en búsqueda:
1 .La separación que existe entre el conocimiento, y la forma cómo éste es utilizado.
2. El uso de conocimiento específico de un determinado dominio.
2. Sistemas basados en conocimiento 17
Dicho de una manera simple, los programas convencionales utilizan algoritmos para
resolver problemas, mientras que los sistemas basados en conocimiento resuelven
problemas donde las soluciones algorítmicas no existen o son muy costosas para ser
implementadas.
Actualmente, el amplio éxito de los sistemas de bases de datos, combinado con las
necesidades de gestión de información y los desarrollos que han emanado del estudio
de la IA, han dado como resultado un interés creciente en extender los sistemas de
bases de datos a sistemas de bases de datos inteligentes, elevando su utilidad al punto
en que pueda construirse conocimiento a partir de datos simples y que éste —
conocimiento— permita controlare interpretar la estructura en su conjunto, Wiederhold ,
los describe de la siguiente manera:
tradicionales sistemas basados en conocimiento han utilizado con gran asiduidad, para
representar el conocimiento, una extensión de la lógica de proposiciones, denominada
lógica "0+" o representación objeto-atributo-valor.
En el caso que nos ocupa, tenemos la certeza de que de los datos en bruto raramente
se obtendrán de una manera directa beneficios. Su verdadero valor radica en la
posibilidad de extraer información útil para el soporte de decisiones o la exploración y
compresión del fenómeno que es la fuente de datos. En general, nuestra habilidad para
analizar y comprender conjuntos de datos masivos decrece mucho más rápidamente
que nuestra capacidad de unir y almacenar estos datos. Por tanto, es necesario una
nueva generación de técnicas y herramientas computacionales para soportar la
extracción de conocimiento útil para grandes volúmenes de datos.
Una representación del conocimiento puede ser un esquema o dispositivo utilizado para
capturar los elementos esenciales del dominio de un problema. Una representación
manipulable es aquella que facilita la computación. En representaciones manipulables,
la información es accesible a otras entidades que usan la representación como parte de
una computación.
• Capture generalizaciones.
• Pueda ser comprendido por todas las personas que vayan a proporcionarlo y
procesarlo.
• Pueda ser fácilmente modificado.
• Pueda ser utilizado en diversas situaciones aún cuando no sea totalmente exacto o
completo.
• Pueda ser utilizado para reducir el rango de posibilidades que usualmente debería
considerarse para buscar soluciones.
P Q P^Q PvQ ~P ⊃Q
P⊃ P≡Q
T T T T F T T
T F F T F F F
F T F T T T F
F F F F T T T
2. Sistemas basados en conocimiento 22
Las ligas también pueden ser de diferentes tipos indicando diferentes relaciones entre
nodos, algunas de las más usadas son:
2. Sistemas basados en conocimiento 23
La red semántica se puede ver dividida en planos. En cada plano se tiene la definición
de un concepto, pero estos tienen ligas a otros planos en que hay conceptos
relacionados. Es decir que un nodo tiene ligas a nodos del mismo plano que lo definen,
pero también a nodos de otros planos que están relacionados, como subclases,
superclases, analogías, etc. En cada plano hay un nodo tipo y una serie de nodos
“token”, los conceptos representados de esta manera se pueden definir inmediatamente
(la definición directa mediante los nodos en el mismo plano) y por concepto completo
(todos los nodos y relaciones a las que se pueda llegar en red partiendo de dicho nodo).
En general es posible usar este tipo de estructuras para diferentes tipos de
razonamiento:
Los objetos estructurados tienen diversas denominaciones, entre las que destacan:
Esquemas (Bartlett 1932), Frames (Minsky 1975), Scripts (Schank, Abelson 1977),
2. Sistemas basados en conocimiento 25
Objetos (Goldeberg. 1977, Steels 1982, entre otros), Descriptores funcionales (Kay M.
1982), las características generales de este modelo de representación son:
b) Cada atributo tiene asociado un valor, el cual a su vez puede ser otro objeto
Los árboles de decisión son una forma de representación sencilla, muy usada entre los
sistemas de aprendizaje supervisado, para clasificar ejemplos en un número finito de
clases. Se basan en la partición del conjunto de ejemplos según ciertas condiciones
que se aplican a los valores de los atributos. Su potencia descriptiva viene limitada por
las condiciones o reglas con las que se divide el conjunto de entrenamiento; por
ejemplo, estas reglas pueden ser simplemente relaciones de igualdad entre un atributo
y un valor, o relaciones de comparación (“mayor que”, etc.), etc. Los sistemas basados
en árboles de decisión forman una familia llamada TDIDT (Top-Down Induction of
Decisión Trees), cuyo representante más conocido es ID3 (Interactive Dichotomizer) se
basa en la reducción de la entropía media para seleccionar el atributo que genera cada
partición (cada nodo del árbol), seleccionando aquél con el que la reducción es máxima.
Los nodos del árbol están etiquetados con nombres de atributos, las ramas con los
posibles valores del atributo, y las hojas con las diferentes clases.
En los siguientes párrafos ofreceremos una visión detallada del esquema relacional,
desde la óptica de la lógica de primer orden, ocupándonos de 4a estructura e integridad
de los datos así como de su manipulación.
El producto cartesiano de una serie de dominios D1;D2; ...;Dn, denotado por: D1xD2x... x
Di, es el conjunto de todas las tuplas (x 1;x 2;...x n,) tales que para cualquier i, i = 1 ;...; n
Una relación R de atributos A1, A2,. . . . An; define lo que se llama un esquema de
relación, denotado por R(A1; A2; . . . An,), de manera que una relación específica R1, con
un conjunto concreto de tuplas resulta una instancia o extensión de dicho esquema.
• Algebra Relacional.
*División: Divide una relación R de grado m+n entre una relación R' de grado n,
produciendo una de grado m.
Cálculo Relacional de Tupías. Una expresión en el CRT, tiene la forma {P/P(t)} que
representa el conjunto de todas las tuplas t que hacen verdadera la fórmula o predicado
P. Usaremos t[A] para denotar el valor que tiene la tupla t para el atributo A y t ∈ R para
denotar que t está en la relación R. Se dice que una variable para t es libre si no se
encuentra cuantificada (universal o existencialmente).
Las fórmulas se construyen a partir de los átomos usando las siguientes reglas:
Siguiendo esta definición es posible generar una relación infinita, por ejemplo el número
de tuplas que no están en una relación {t/¬ (t∈R)}, así se introduce el concepto de
dominio de una fórmula P, dom(P) es el conjunto de todos los valores representados
por P.
Cálculo relacional de dominios. Esta forma del cálculo relaciona1 utiliza variables de
dominio a las que se asignan valores del dominio de un atributo (dato). Las expresiones
tienen la forma: {<x1 ,x2,…xn, > | P (x1,x2 ,..., xn, ) } donde x1,x2 ,..., xn representan las
variables de dominio y P la fórmula compuesta de átomos, éstos pueden tener las
siguientes formas:
3. Sistemas expertos
3.1 Antecedentes
En teoría estos sistemas son capaces de razonar siguiendo pasos comparables a los
que sigue un especialista (médico, biólogo, geólogo, matemático, etc.), cuando resuelve
un problema propio de su disciplina. Por ello el creador de un SE debe comenzar por
identificar y recoger, del experto humano, los conocimientos que éste utiliza:
conocimientos teóricos, pero sobre todo los conocimientos empíricos adquiridos en la
práctica.
La programación lógica tiene sus antecedentes más próximos en los trabajos de prueba
automática de teoremas de los años sesenta. J. A. Robinson propone en 1965 una
3. Sistemas expertos 33
regla de inferencia a la que llama resolución (Regla que se aplica sobre cierto tipo de
fórmulas del Cálculo de Predicados de Primer Orden, llamadas cláusulas y la
demostración de teoremas bajo esta regla de inferencia se lleva a cabo por reducción al
absurdo), mediante la cual la demostración de un teorema puede ser llevada a cabo de
manera automática, sus trabajos sirvieron de base al primer lenguaje de programación
que contempla, como parte del intérprete, los mecanismos de inferencia necesarios
para la demostración automática.
El común denominador de estos sistemas radica en la forma en que utilizan las bases
de datos, manipulando la información existente para aplicarla a soluciones que van
desde sencillas inferencias hasta complejos procesos de representación mediante el
uso de la lógica.
o sea no precisos. Básicamente el Sistema Experto esta compuesto por los siguientes
módulos:
4. Arquitectura de BDI
4.1 Fundamentos
Desde el punto de vista de ingeniería, la mayor parte del trabajo requerido para
construir sistemas de IA, está basado en el desarrollo de adecuadas representaciones
de conocimiento y sus correspondientes estrategias de manipulación.
4.2 Descripción
Fundamentalmente, una BDI, deberá ser capaz de deducir hechos a partir de la base
de datos aplicando axiomas deductivos o reglas de inferencia a esos hechos.
Los principales pasos dentro del proceso interactivo e iterativo del KDD pueden verse
en la figura 8, y son los siguientes:
5. Elección del tipo de sistema para minería de datos. Esto depende de si el objetivo del
proceso de KDD es la clasificación, regresión, agrupamiento de conceptos (clustering),
detección de desviaciones, etc.
4.3 Arquitectura
Los SGBD Inteligentes no existen como tales, por lo que en la arquitectura de una base
de datos inteligente intervienen múltiples factores y condicionales derivadas de las
estrategias que el programador decida implementar y las necesidades del sistema a
desarrollar, sin embargo, en el grueso de los estudios enfocados al desarrollo de un
sistema inteligente de bases de datos, se distingue como objetivo de la intetfaz:
proporcionar consejo y apoyo a la toma de decisiones, ofrecer opiniones informadas y
explicación de sus razonamientos, además, deberá permitir que el directivo u operador
manipule grandes volúmenes de información entre los que encontramos ejemplos,
reglas, heurísticas, hechos e incluso modelos de predicción con probabilidades de
certeza. Los beneficios son amplios y múltiples, por ejemplo la reducción en el tiempo
de toma de decisiones, apoyo a la toma de decisiones basada en hechos, el
mejoramiento del desempeño de personal no experto, la acelerada capacitación de
personal mediante tutores, flexibilidad y apoyo a la reorganización y la reingeniería, el
mejor diagnóstico de fallas, el mejor mantenimiento, la optimización de tiempos y
movimientos, el mejor servicio, y la retención del conocimiento y experiencia
corporativa; para ello, considerando el desarrollo de una BDI sobre un motor relacional,
el sistema -regularmente- integrará:
Para los efectos de nuestro estudio, nos ocuparemos de la arquitectura basada en los
4. Arquitectura de una BDI 47
Formato Características
Archivo Plano (dbint.db) Tanto la base de reglas como el motor de
inferencia operan en forma periférica al
sistema (Uso de Prolog).
Table La base de reglas y las funciones de
inferencia pertenecen al lenguaje nativo
(Visual Basic 6)
c 1 = enfermo (pedro) :-
hijo-de(pedro, juan),
fumador(juan)
c 2 = enfermo (alberto) :-
hijo-de(alberto, josé),
fumador(josé)
Igg(c 1 , c 2) = enfermo(X) :-
hijo-de(X, Y),
fumador(Y).
con técnicas de arriba hacia abajo (especialización por introducción de nuevos literales,
como FOIL).
b. Resolución inversa
b1 = enfermo(pedro)
b2 = hijo-de(pedro, juan)
b3 = fumador(juan)
d. Patrones de reglas.
Se denominan patrones de reglas a un tipo especial de reglas en las que los predicados
son variables. La búsqueda de reglas se realiza a partir de los patrones de reglas
existentes, proporcionados por el usuario. Para cada patrón de regla se prueban todas
las posibles combinaciones de predicados existentes y, cada una de las reglas así
4. Arquitectura de una BDI 54
obtenidas, se evalúa con los datos de entrenamiento. Por ejemplo, con un patrón de
reglas de la forma:
P(X) :- R(X,Y), Q(Y)
se podría obtener, por ejemplo, la regla
enfermo(X)
hijo-de(X,Y),
fumador(Y).
e. Cláusulas
La última de ellas se interpreta como que una persona no puede ser a la vez padre y
madre de otra.
Este autor señala que hasta ahora se ha intentado solucionar los casos de
incertidumbre no dejando almacenar cierta información o mediante los valores nulos;
por lo que propone incluir nuevas técnicas en los SGBD como los factores de
incertidumbre que se emplean en los Sistemas de Recuperación de la Información o en
los Sistemas Expertos, y la lógica borrosa (fuzzy). En esta misma línea se encuentra
Johnston, que propone una lógica multivaluada “reglamentada” a la que se le añaden
“áreas de la lógica que van más allá de la lógica proposicional y de predicado de primer
orden”, como pueden ser: la lógica modal, la lógica no monotónica y la lógica funcional
no verdadera.
Podemos denotar esto como: µ.A(x) → [0,1]. A µ también se le conoce como el “valor
de verdad” porque representa el grado en que una proposición es verdadera. Mediante
esta herramienta podemos asignar distintos valores considerando las posibilidades
_
explícitas del atributo (Universo de discurso [Ω]), así un conjunto difuso Λ sobre un
_
universo de discurso Ω, es un conjunto de ares: Λ = {x; µA(x): x ∈ Ω; µA(x) ∈ [O,1]},
_
donde µA(x) se denomina grado de pertenencia de x a Λ. Existen múltiples
representaciones de conocimiento difuso mediante la lógica fuzzy, para los efectos de
nuestro estudio, tan sólo describiremos aquéllas posibles asignaciones de valor
operando sobre datos concretos, así las etiquetas lingüísticas aplicadas corresponden
al dominio específico (columnas) que se trate por ejemplo:
Una vez que se asignen los valores asignados por lógica difusa a las tupias que
corresponda, su tratamiento dependeran -en cada caso- del proceso que las requiera y
serán operadas en forma convencional por el grado de pertenencia asociado.
4. Arquitectura de una BDI 59
En su forma inversa, el difusor ataca directamente el contenido de los campos con una
función de pertenencia (rango) y construye la base en intenso asignando etiquetas
lingüísticas determinadas: BAJA, ALTA, URGENTE..., Por ejemplo:
Ii (0.3)
F(P)
Is (0.8)
Tenemos:
Cada una de las variables de entrada y de salida tiene una representación dentro del
Sistema de Lógica Difusa en forma de Variables Lingüísticas. Finalmente atendiendo
una de las recomendaciones generales sobre el diseño de SGBD relacionales, se
utilizará la lógica fuzzy exclusivamente en aquellos dominios que lo exijan o que
representen estados intermedios de procesos en desarrollo.
Si bien los valores nulos (también se le denomina “valor ausente o condicional”) no son
un concepto exclusivo del modelo relacional, ha sido en el contexto de este modelo
donde se ha abordado su estudio de manera más sistemática y donde se están
realizando más investigaciones a fin de formalizar su tratamiento. La necesidad de los
“valores nulos” o “marcas” en bases de datos es evidente por diversas razones:
En las siguiente figura aparecen las tablas de verdad para la lógica trivaluada, donde
existen los valores C (cierto), F (falso) y Q (quizás). Además, se incluye un nuevo
operador denominado MAYE, que aplicado al valor de una expresión “quizás”, da como
resultado “cierto”.
a) IS NULL, que toma el valor cierto si el operando es nulo y falso en caso contrario
b) IF NULL, que toma dos operandos y que devuelve el valor del primero, salvo que sea
nulo, en cuyo caso devuelve el valor del segundo.
En el lenguaje SQL las columnas admiten valores nulos a no ser que se especifique
NOT NULL, y se soporta la lógica trivaluada, cuyas tablas de verdad ya hemos
representado.
Por ejemplo: . . . WHERE NULLIF (año, -99) > 1980, que es equivalente a:
p IS [NOT] TRAE
FALSE
UNKNOWN
este último (UNKNOWN) corresponde al operador MA YBE Así, por ejemplo, podemos
formular la siguiente consulta:
SELECT titulo
FROM libros
WHERE (año = 1996) IS UNKNOWN;
Esta diferencia, que puede parecer académica en exceso, es de hecho muy importante
para reflejar con más precisión la semántica del universo del discurso a tratar y para
responder de manera “más inteligente” a las consultas que se realicen sobre la base de
datos. En la lógica cuatrivaluada se distingue, por tanto, entre un valor nulo o marca
que representa información desconocida pero aplicable, que denominaremos α, de otro
que representa información inaplicable, que denominaremos β.
En este caso las operaciones aritméticas quedan modificadas como sigue, siendo ↔ un
operador aritmético y x un valor no nulo de la base de datos:
x↔α=α↔x=α
x↔β=β↔x=β
α↔β=β↔α=β
α↔α=α
β↔β=β
A continuación se muestran las tablas de verdad para la lógica cuatrivaluada, donde por
“A”(Aplicable) y por “I” (Inaplicable) se representan los valores de verdad de la lógica
cuatrivaluada, según CODD.
AND C A F I OR C A F I NOT
C C A F I C C C C C C F
A A A F I A C A A A A A
F F F F F F C A F F F C
I I I F I I C A F I I I
El lenguaje SQL con que opera el motor relaciona1 Jet, no soporta aún la lógica
4. Arquitectura de una BDI 65
Si el resultado tiene definida una clase nula y uno o más operandos son nulos:
Por otro lado, Gessert propone asociar a cada tabla de datos que pueda contener
valores nulos una “tabla de estados lógicos” que se corresponde fila a fila y campo a
campo a la tabla de datos y que posee las mismas claves. Mediante este esquema, la
tabla de datos no tendría valores nulos, y en la tabla de estados se almacenarían los
siguientes valores
NA inaplicable
AF que indica que es falso
AM que indica que es desconocido pero aplicable
AT que señala que es cierto
5.2.1 RecordSet
1. Métodos
2. Objetos Contenidos
3. Propiedades
Mediante este objeto nos comunicaremos con la base de datos. Toda la jerarquía de
clases que comienza aquí, y para llamar a los métodos de los RecordSets, siempre
tendremos que pasar por un objeto database. En la inteligencia de simplificar,
agruparemos, por su funcionalidad, todos sus métodos, propiedades y funciones
relacionadas.
5. Programación de una BDI 69
1. Métodos
2. Propiedades
3. Objetos Contenidos
4. Funciones Relacionadas
‘lista-campo está compuesto por uno o más nombres de campos, separados por comas,
pudiéndose especificar también el nombre de la tabla a la cual pertenecen seguido de
un punto y del nombre del campo correspondiente. Si el nombre del campe o de la tabla
está compuesto de más de una palabra, este nombre ha de escribirse entre corchetes
([nombre]). Si se desea seleccionar todos los campos de una tabla, sE puede utilizar el
asterisco (*) para indicarlo.
Una sentencia SELECT no puede escribirse sin la cláusula FROM. Una cláusula es una
extensión de un mandato que complementa a una sentencia o instrucción, pudiendo
complementar también a otras sentencias. Es, por decirlo así, un accesorio
imprescindible en una determinada máquina, que puede también acoplarse a otras
máquinas. En este caso, la cláusula FROM permite indicar en qué tablas o en qué
consultas (queries) se encuentran los campos especificados en la sentencias SELECT.
Estas tablas o consultas se separan por medio de comas (,), y, si sus nombres están
compuestos por más de una palabra, éstos se escriben entre corchetes ([nombre]). He
aquí algunos ejemplos de mandatos SQL en la estructura SELECT...FROM...:
c) Claúsula WHERE
d) Cláusula ORDER BY
La palabra reservada ASC es opcional e indica que el orden del campo será de tipo
ascendiente (O-9 A-Z), mientras que, si se especifica la palabra reservada DESC, se
indica que el orden del campo es descendiente (9-O Z-A). Si no se especifica ninguna
de estas palabras reservadas, la cláusula ORDER BY toma, por defecto, el tipo
ascendiente [ASC].
SELECT nombre, apellidos, tele fono FRO M clientes ORDER B Y apellidos, nombre;
Crea una agenda telefónica de ‘clientes’ ordenada por ‘apellidos’ y ‘nombre’.
SELECT * FROM pedidos ORDER BY fecha DESC;
Relación de ‘pedidos’ ordenados desde el más antiguo hasta el más moderno.
SELECT * FROM abonados ORDER BY apellidos, nombre, fecha-nacimiento DESC;
Relación de ‘abonados’ por ‘apellidos’ y ‘nombre’ ascendientemente, y por ‘fecha-
nacimiento’ en orden descendiente (del más viejo al más joven).
control-data.RecordSource = variable-SQL
control-data. Refresh
5. Programación de una BDI 76
El lenguaje SQL nos permite eliminar registros que cumplan las condiciones o criterios
indicadas a través de la sentencia DELETE, cuya sintaxis es la siguiente:
Donde el parámetro ‘tablas’ indica el nombre de las tablas de las cuales se desea
eliminar los registros, y, el parámetro ‘criterios’, representa las comparaciones o criterios
que deben cumplir los registros a eliminar, respetando a aquellos registros que no los
cumplan. Si - por ejemplo - quisiéramos eliminar todos los pedidos realizados por el
cliente cuyo código sea 4 en el día de hoy, utilizaríamos la siguiente sentencia:
* Sumas o totales
Retorna el saldo medio de una tabla llamada ‘diario’. Este resultado se toma como un
nuevo campo en el RecordSet y se le llama ‘saldo-medio’.
* Conteo de registros
Para conocer cuántos registros hay utilizaremos la función COUNT, cuya sintaxis es la
siguiente: COUNT(expresión).
5. Programación de una BDI 79
En una consulta podría ser útil omitir registros que estén duplicados. Por ejemplo, en
nuestros pedidos hay duplicación, puesto que un cliente realiza varios pedidos en el
mismo día. Quizá necesitemos una historia para conocer los días y los clientes que
realizaron algún pedido, pero no necesitaremos toda la lista, si no que nos diga,
únicamente, mediante una línea, qué cliente realizó algún pedido y en qué día. Para
ello, utilizaremos el predicado DISTINCT, cuya sintaxis es la siguiente:
SELECT DISTINCT lista-campos . . .
5. Programación de una BDI 80
Si deseamos que la consulta sea más completa y nos visualice también el nombre y los
apellidos correspondientes del cliente en cuestión (estos datos están en la tabla
‘clientes’ y no en ‘pedidos’), escribiríamos este mandato:
i) Reemplazar datos
j) Grupos de registros
Si se precisa mostrar un resumen de los datos que tenemos, especificando el total - por
ejemplo -, de los ingresos y de los gastos de cada día, en lugar de visualizar todos los
ingresos y gastos realizados al detalle. Para llevar a cabo esta tarea hemos de tener en
cuenta, en primer lugar, bajo qué campo se van a agrupar los datos (en lo expuesto,
sería el campo fecha), y, a continuación, realizar la consulta mediante la cláusula
GROUP BY, cuya sintaxis es la siguiente:
Para conocer cuántas unidades se pidieron cada día, tipearíamos esta sentencia:
SELECT fecha, SUM(unidades) AS cantidad FROM pedidos GROUP BY fecha;
5. Programación de una BDI 82
En la siguiente sentencia se muestra para cada cliente aquellos días en que se realizó
un pedido, resumiéndose el número de pedidos realizados así como el total de
unidades pedidas:
SELECT fecha, codigó cliente, COUNT(codigo cliente) AS num pedidos,
SUM(unidades) AS cantidad FROM pedidos GROUP BY fecha,
codigó cliente HAVING fecha<#116197#;
k) Combinación de datos
Las consultas realizadas hasta ahora requerían de una dosis de habilidad para
conseguir crear un conjunto de datos que tuviese información combinada de dos tablas.
Pero, podemos combinar datos de una manera mucho más sencilla y eficaz: mediante
las operaciones JOIN, las cuales permiten combinar datos de dos tablas. La operación
JOIN más común es INNER JOIN, cuya sintaxis es:
tabla 1 INNER JOIN tabla2 ON tabla J .campó común=tabla2.campó común
Donde tabia1 y tabla2 representan el nombre de las tablas a combinar. Ambas tablas
han de tener un campo común o igual para poder realizar correctamente la combinación
de los datos. Por ejemplo:
5. Programación de una BDI 83
El resultado será un conjunto de registros con los datos de las dos tablas. Este conjunto
poseerá el nombre de todos los campos de la tabla pedidos y de todos los campos de la
tabla clientes. En cada registro aparecerán los datos relacionados, es decir, que en un
pedido aparecerán los datos del mismo y los datos personales del cliente que realizó el
pedido.
La operación INNER JOIN combina los datos de las dos tablas siempre que haya
valores coincidentes en los campos comunes o enlazados.
Existen también otras dos formas de combinar: LEFT JOIN y RIGHT JOIN. Ambas
tienen la misma sintaxis que INNER JOIN, pero estas operaciones incluyen todos los
registros de una tabla y aquellos registros de la otra en que los campos comunes sean
iguales.
En la operación LEFT JOIN, incluye todos los registros de la primera tabla (parámetro
tabla1) y aquellos registros de la segunda tabla (parámetro tabla2) en que los campos
comunes sean iguales. En la operación RIGHT JOIN ocurre lo contrario: incluye todos
los registros de la segunda tabla y aquellos registros de la primera tabla en que los
campos comunes sean iguales.
El registro que contiene el pedido del cliente que no existe no aparece, puesto que no
hay coincidencia. Si utilizamos:
Observaremos que aparecen todos los registros de la tabla pedidos, incluido aquel
donde indicamos que el pedido fue solicitado por el cliente inexistente, pero en los
campos relacionados (campos de la tabla clientes) no habrá ningún dato relacionado o
combinado. Si utilizamos:
Obtendremos el mismo resultado que con la operación INNER JOIN, puesto que se
visualizan todos aquellos registros que existen en clientes y aquellos que coincidan con
el campo clave en la tabla pedidos. Como el código inexistente no existe en la tabla
clientes, este registro no aparece.
Mediante las herramientas citadas, es posible recuperar los datos objetivo que serán
transformados al formato IPL, dichos datos, generalmente serán el producto de varias
consultas cuyos productos se redireccionan hacia un archivo a partir del que se
edificará la base de datos en intenso, sobre la que opera el proceso de inferencia.
Tabla: Motor .
CVE String ' 5 Indice primario.
MAX1 - MAX4 Double
Tabla: Lecturas .
CVE String ' 5 Indice primario.
L1 - L4 Double
Y una base en intenso compuesta por el total de registros edificada con base a la
siguiente estructura:
Tenemos:
'{ Creación de la BD
Dim i As Byte
For i = I To 5
NewTb. Fields. Append Campo(i)
Next í
‘{ Utilizando SQL
NewDb. Close
End Function
Wend
tb. Close
While Not bt. EOF
A$ = bt!CVE
B$ = bt!L1
C$ = bt!L2
D$ = bt!L3
e$ = bt!L4
Ab$ = Chr(44) + C$ + Chr(44) + D$ + Chr(44) + e$
f$ = btipe + Chr(40) + A$ + Chr(44) + B$ + Ab + Chr(41) + Chr(46)
Print #free, f$
bt. MoveNext
Wend
bt. Close
db. Close
Close #free
End Function
En el desarrollo de los distintos prototipos, hemos incluido un vista global de las bases
de datos que recuperan tanto la estructura como el contenido de dicha, con el objetivo
de consolidar una aplicación totalmente transparente, el siguiente listado constituye su
base de operación ( En fragmentos de código, se hace referencia a los objetos
contenidos en el prototipo de ejemplo anexo al presente documento):
5. Programación de una BDI 89
Option Explicit
Dim WorkDb As Database
Dim td As Tabl eDef
Dim Database/sOpen As Boolean
Dim CurrentTable As Recordset
Dim TablelsOpen As Boolean
Dim source As String
LstOfFields Click
End Sub
Option Explicit
Dim cont_mostrados As Long
Dim mi_left As Long
Dim mi_top As Long
Dim avance_left As Long
Dim avance_top As Long
Dim media_caja As Long
Dim mínimo_ punto As Long
Dim cancelar_arbol As Boolean
BinaryDB1. bas
End Sub
byte-next = Readlndex("ByteNext")
rec-next = Readlndex("RecNext")
Put #1, byte-next, message
Close #1
len-bytes = Len(message)
v$ = byte next & DOT & len-bytes & DOT & Trim(frmRec. txtFrom) & DOT &
Trim(frmRec.txtSubject) & DOT & Trim(frmRec. txtDate) & DOT & Trim(frmRec. txtTo) &
DOT & “HECHO“
Writelndex "R" & rec-next, v$
byte-next = byte-next + len-bytes
Writelndex “Byte Next" byte-next
rec-next = rec-next + 1
Writelndex "RecNext"; rec-next
End Sub
‘{ crear archivo
End Sub
BinaryDB2.bas
IstrSection = "Index"
IfixedstrRet Value = String(sizer, "')
5. Programación de una BDI 103
On Error Go To 0
On Error Resume Next
End Function
IstrSection = “Index”
IstrValue = Trim(IstrValue)
IintJunk = WritePrivateProfleString(IstrSection, IstrKey, IstrValue, IndexPath)
On Error Go To 0
On Error Resume Next
End Sub
BinaryDB3.bas
BinaryDB4. bas
x1% = Len(T$)
Place % = 0
For Counterl % = 1 To xI%
CurrentChar$ = Mid$(T$, Counter1 %, 1)
If CurrentChar$ = LIMITE Then Place % = Place % + 1
If Place% = v% Then
xStart% = Counterl % + 1
Exit For
End If
Next
For Counter2% = xStart% To xl%
CurrentChar$ = Mid$(T$, Counter2%, 1)
If CurrentChar$ = LIMITE Then Place % = Place % + 1
If Place% = v% + 1 Then
xStop% = Counter2% - xStart%
Exit For
End If
Next
If xStop % = 0 Then
Parse = Trim(Mid$(T$, xStart%))
If InStr(Parse, LIMITE) Then Parse = “”
Else
Parse = Trim(Mid$(T$, xStart%, xStop%))
If InStr(Parse, LIMITE) Then Parse = “”
End If
On Error GoTo 0
On Error Resume Next
End Function
• Fuzzy DBExpert.
• Fuzzy DbRelation.
Dim R As Recordset
free = FreeFile
Set dbDatos = OpenDatabase('path+file')
Set R = DB. OpenRecordset("Iectura”)
Open “‘PA TH’\lbase.int" For Output As #free
R. MoveFirst
While Not R.EOF
a$ = R!id
b$ = R!prioridad
c$ = Rllectura
Call difusor(a$, b$, c$)
R. Mo veNext
Wend
R. Close
db Datos. Close
Close #free
End Sub
If T2 <= li Then
pertenece = ‘Bajo”
End If
If T2 >= is Then pertenece = “Urgente”
Else
pertenece = “Alto”
End If
a$ = Tl
b$ = pertenece
c$ = T3
f$ = et + T i + ", " +pertenece+", "+T3+"). "
Print #free, f$
End Function
5. Programación de una BDI 107
a)La base de datos en intenso esta constituida por un archivo temporal plano.
Dicha base, se crea y destruye según sea preciso en las operaciones generales del
sistema, las operaciones sobre ésta las efectúa un archivo binario (file.xpl) compilado
en Prolog. La temporalidad de este archivo obedece a que el motor debe procesar
bases de conocimiento distintas en el marco de procesos de inferencia determinados.
Los rasgos pueden tener pesos asociados y relacionados con ellos que representan
5. Programación de una BDI 110
Un animal come alimento, respira aire, tiene masa y está formado por miembros; ahora
una persona es del tipo animal, el cual "hereda" todas las características antes descritas
del animal. Así también tenemos la posibilidad de detallar más sus cualidades como
que tiene en sus partes piernas y brazos.
r("PAJARO",es_del_tipo, "ANIMAL").
r("PAJARO", puede, volar).
5. Programación de una BDI 112
r("PAJARO",esta_formado_Por, plumas).
r("PAJARO",esta_formado_por, alas).
r("CANARIO", es_del_tipo, "PAJARO").
r("CANARIO", color, amarillo).
r("Ave X", un_representante_de,"CANARIO").
r("PERSONA", es_del_tipo,"ANIMAL").
r("PERSONA", esta_formado_por, piernas).
r("PERSONA", esta_formado_por,brazos).
r("Persona X",un_representante_de,"PERSONA").
Podemos observar que la cláusula r( Elemento-I Lazo, Elemento-2) relaciona por medio
de "Lazo" el "elemento-I" con el "elemento _2", sólo falta un sistema que haga uso de
ella, y exprese el conocimiento que la red determina por medio de la acción. Por
ejemplo una expresión clausal que sea capaz de proporcionar en una lista las
características que hereda un elemento de la clase.
La noción básica de esto es que el conocimiento puede ser representado por un tipo de
estructura gráfica directa y nivelada en la cual el elemento estructural básico es un
conjunto de nodos interrelacionados mediante relaciones. Los nodos representan
conceptos en la memoria. Una relación es una asociación entre los conjuntos de los
nodos. Las relaciones son directas y niveladas. Desde este punto de vista el
"significado" de un concepto (representado por un nodo) está dado por el patrón de
relaciones entre el cual éste participa. Las redes semánticas se caracterizan por el
tratamiento de conceptos, representados por nodos, y relaciones entre ellos,
representadas por arcos que ligan a los nodos entre sí. Básicamente los nodos pueden
ser de dos tipos:
Los conceptos están previamente ordenados en una taxonomía, y existen los arcos
especiales “es un” y “es un tipo de”. El primero liga un nodo individual con uno genérico
y expresa que un individuo es de cierta clase, y el segundo liga dos nodos genéricos
entre sí y expresa que un concepto o tipo es un subtipo de otro. Es importante destacar
que a diferencia del formalismo de la lógica, para las redes semánticas no hay métodos
formales y generales de deducción. El significado asignado a una red lo establecen
solamente los procedimientos que manipulan la red.
b) Método BOTTOM UP
El encadenamiento hacia adelante “Bottom Up”, se comienza con las cláusulas que son
aserciones o hipótesis. Para ello se usan las aserciones e implicaciones que permitan
derivar nuevas aserciones, se termina cuando eventualmente la cláusula original o
hipótesis es resultado de las aserciones derivadas.
Una refutación en este método comienza con las aserciones de las cláusulas originales,
se utilizan las aserciones para obtener nuevas aserciones a partir de las ya generadas,
se termina cuando se deriva una que explícitamente contradiga el objetivo. Este método
de resolución genera una estructura más compleja que la generada por “Top Down",
por lo cual la búsqueda es más difícil.
Como podemos apreciar en los ejemplos citados con anterioridad, la base en intenso
es, generalmente, una estructura simple, donde se evalúa a sus miembros en función
de su peso o áridad; resulta evidente que el repositorio de reglas constituye el eje
fundamental del proceso de inferencia. Este repositorio, para los efectos de nuestro
estudio, se concentra en funciones ad hoc desarrolladas en el lenguaje anfitrión (Visual
Basic) y en archivos binarios (.xpl) compilados por y para el motor de inferencia
huésped Amzi4 Prolog.
persona(nombre, sexo).
donde:
persona( Carlos, M),
persona(Sofía,F),
Aplicando la expresión:
hombre:-(persona(x,M).
mujer:-(persona(x,F).
5. Programación de una BDI 116
Tenemos:
Todas los ejemplos en que interviene el motor de Proiog tienen la misma base, así que
sólo nos ocuparemos de describir el proceso de `búsqueda funcional' tomando como
referencia uno de los ejemplos clásicos de la Programación Lógica, ocupándonos de
sus aspectos principales;
a) La Base Persistente.
Compuesta por la tabla: Familia, donde
b) La base en intenso.
Compuesta por la estructura:
person(nombre,genero,padre,madre,pareja).
c) El objetivo de la inferencia.
d) El repositorio de reglas.
%Listado 9 arbol.pro
%Código: Prolog
% Objetivo del proceso de inferencia:
relation(R, X, Y) :-
relations(Rs),
member(R, Rs),
Q [R, X, Y],
call(Q)
% Repositorio de reglas en sí
full_hermanos(S 1, S2) :-
madre(M, S2),
madre(M, S 1),
S 1 \= s2,
padre(F, S 1),
5. Programación de una BDI 119
padre(F, S2).
half_hermanos(S 1, S2) ;-
madre(M, S2),
madre(M, S1),
S1 \= s2,
padre(F 1, S1),
padre(F2, S2),
F 1 \= F2.
hermana(S, P) :-
hermanos@a, P),
female(S),
hermano(8, P) :-
hermanos(B, P),
male(B).
tio(U,X) :-
padres(P,X),
hermano(U, P).
tia(A,X) :-
padres(P,X),
hermana(A, P).
sobrinos(N,X):-
hermanos(S,X),
padres(S, N),
male(N).
sobrina(N,X) :-
hermanos(S,X),
padres(S, N),
female(N).
primos(X, Y) :-
padres(P, Y),
hermanos(S, P),
5. Programación de una BDI 120
padres(S,X).
abuelas(GM,X) :-
padres(P,X),
madre(GM, P).
abuelos(GF,X):-
padres(P,X),
padre(GF, P).
nieto(GS,X) :-
nietos(GS,X),
male(GS).
nieta(GD,X):-
nietos(GD,X),
female(GD).
nietos(GC,X) :-
padres(X, C),
padres (C, GC).
person(X) :-
person(X, _,_,_,_)
male(X) :-
person(X, male,_,_,_).
female(Y) :-
person(Y, female,_,_,_).
madre(M, C) :-
person(C,_, M,_,_).
padre(F, C) :-
person(C,_,_, F,_).
spouse(S, P) :-
person(P,_,_,_, S),
S \= single.
member(X, [X\_])
member(X, [_\ Y]) :- member(X, Y).
5. Programación de una BDI 121
Do
rc = PopListLS(TList, bSTR, StrVal)
If (rc = 0) Then
RelationshipList.Addltem StrVal
End If
Loop While (rc = 0)
Relations = 1
End Function
If IsEmpty(MaxStrLen) Then
MaxStrLen = 255
End If
If IsEmpty(ErrorMethod) Then
ErrorMethod = 0
End If
End Sub
End Sub
Select Case tf
Case 0
CaII StrL S = False
Case I
CalIStrLS = Trae
Case Else
Call ErrorHandler("IsCalIStr", tf)
End Select
End Function
Public Sub GetArgLS(ByVal Term As Long, ByVal ArgNum As Long, ByVal BType
As lnteger, Ptr As Variant)
Dim rc As Long, tstr As String
Dim tlong As Long, tfloat As Single, tint As Integer, tdouble As Double
Dim s As String
End Sub
Select Case rc
Case 0
PopListLS = rc
Case -1
PopListLS = rc
Case Else
Call ErrorHandler("IsPopList" rc)
End Select
End Function
Hemos seleccionado éste ejemplo por su sencillez y amplia documentación entre los
distintos grupos de programación lógica consultados, de hecho, constituye la base de
explicación a usuarios de Amzi4, sobre su operación conjunta con Visual Basic; éste y
todos los ejemplos concentrados en el prototipo (listados, base persistente, repositorio
de reglas, base en intenso), pueden ser editados en las vistas de `Edición' en los
prototipos desarrollados.
Resulta difícil clasificar las herramientas (que superan ampliamente el centenar) que
pueden servir para la explotación inteligente de los almacenes de datos, pero en una
primera aproximación podríamos distinguir las siguientes categorías:
Las herramientas OLAP (siglas que pueden englobar todas las anteriores categorías),
se pueden definir como un tipo de tecnología software que permite a los analistas,
gestores y ejecutivos obtener una visión de los datos por medio de un acceso rápido,
consistente e interactivo a una amplia variedad de posibles vistas de la información que
ha sido transformada a partir de datos en bruto para reflejar la dimensionalidad real de
6. Estado del Arte 127
Suele ser muy habitual con estas herramientas realizar el cálculo de las siguientes
métricas:
- Ratios multidimensionales.
- Comparaciones.
- Perfiles estadísticos y clasificaciones.
Este tipo de herramientas permite a los analistas del negocio verificar hipótesis, que el
propio usuario va haciendo y validando con los datos que le devuelven sus consultas,
pudiendo navegar por las distintas dimensiones de los datos.
Sin embargo, existe otro tipo de técnicas, más potentes, que permiten descubrir
información valiosa sin depender del usuario, son las que se engloban dentro de la
categoría de minería de datos (data mining) propiamente dicha, en nuestro estudio, sólo
hemos pormenorizado en los algoritmos de modelado basados en IPL, sin embargo,
existe una fuerte tendencia, en el seno de los grupos de IA, por la utilización de
modelados abstractos: Objetos y clases entre otros.
6. Estado del Arte 128
Algunas de las tareas que se llevan a cabo con las herramientas de minería de datos
son las siguientes:
Estas tareas se pueden llevar a cabo mediante la aplicación de distintas técnicas que
resumimos a continuación:
7. Conclusiones
Referencias bibliográficas
a) Textos
CODD, E.F. “The Relational Model for Database Manaaement: Version 2”.
Ed. Addison-wesley, Massachussets, USA, 1990.
b) Artículos
The Data Mining Research Group. “lntroduction to DBMiner and Data Mining and
Warehousing Concepts"
ftp://ftp.fas. sfu. ca/pub/cs/han/slides/boeingintro. ppt