Vous êtes sur la page 1sur 396

UNIVERSIDAD DE GRANADA

E.T.S.I. INFORMA TICA

Dpto. de Ciencias de la Computacion e Inteligencia Arti cial

TESIS DOCTORAL

TRATAMIENTO de la IMPRECISIO N
en BASES de DATOS RELACIONALES:
EXTENSIO N del MODELO y ADAPTACIO N
de los SGBD ACTUALES

Jose Galindo Gomez

1999
UNIVERSIDAD DE GRANADA

TESIS DOCTORAL

TRATAMIENTO de la IMPRECISIO N
en BASES de DATOS RELACIONALES:
EXTENSIO N del MODELO y ADAPTACIO N
de los SGBD ACTUALES

Autor : Jose Galindo Gomez


Director : Juan Miguel Medina Rodrguez
Departamento : Ciencias de la Computacion e
Inteligencia Arti cial
Programa de Doctorado : Tratamiento de la Informacion en
Inteligencia Arti cial

Esta Tesis Doctoral fue defendida del 12 de Marzo de 1999,


obteniendo la cali cacion de
SOBRESALIENTE CUM LAUDE.
Indice General
Agradecimientos y Dedicatorias 1
1 Introduccion: Bases de Datos y Conjuntos Difusos 3
1.1 Motivacion y Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Descripcion por Captulos . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Modelo Relacional de Bases de Datos . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1 Estructuras de Datos: Tablas o Relaciones . . . . . . . . . . . . . . . . 8
1.2.2 Integridad de los Datos . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.3 De nicion de los datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.4 Manipulacion de los Datos: A lgebra y Calculo Relacional . . . . . . . 10
1.2.4.1 A lgebra Relacional . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2.4.2 Calculo Relacional . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2.5 El Lenguaje SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2.5.1 Comando SELECT . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2.5.2 Comando INSERT . . . . . . . . . . . . . . . . . . . . . . . . 19
1.2.5.3 Comando DELETE . . . . . . . . . . . . . . . . . . . . . . . . 20
1.2.5.4 Comando UPDATE . . . . . . . . . . . . . . . . . . . . . . . . 20
1.2.5.5 Comando CREATE TABLE . . . . . . . . . . . . . . . . . . . . 20
1.2.6 El SGBDR Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.2.6.1 Estructuras y Tipos de Datos . . . . . . . . . . . . . . . . . . 23
1.2.6.2 Integridad de los Datos . . . . . . . . . . . . . . . . . . . . . 25
1.3 Teora de Conjuntos Difusos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.3.1 Conjuntos Difusos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.3.2 Conceptos sobre Conjuntos Difusos . . . . . . . . . . . . . . . . . . . . 27
1.3.3 Operaciones sobre Conjuntos Difusos . . . . . . . . . . . . . . . . . . . 28
1.3.3.1 Union e Interseccion . . . . . . . . . . . . . . . . . . . . . . . 28
1.3.3.2 Complemento . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.3.4 Numeros Difusos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.3.4.1 El Principio de Extension . . . . . . . . . . . . . . . . . . . . 31
1.3.4.2 Aritmetica Difusa . . . . . . . . . . . . . . . . . . . . . . . . 32
1.3.5 Teora de la Posibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2 Modelos de BDR Difusas: GEFRED 35
2.1 Imprecision Sin Utilizar Logica Difusa . . . . . . . . . . . . . . . . . . . . . . 36
2.1.1 Aproximacion de Codd . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.1.2 Esquema con Valores por Defecto . . . . . . . . . . . . . . . . . . . . . 37
I
II INDICE GENERAL

2.1.3 Rangos en Valores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37


2.1.4 Bases de Datos Estadsticas y Probabilsticas . . . . . . . . . . . . . . 37
2.2 Modelos Basicos de Bases de Datos Difusas . . . . . . . . . . . . . . . . . . . 38
2.3 Modelo de Buckles-Petry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.4 Modelo de Prade-Testemale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.5 Modelo de Umano-Fukami . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.6 Modelo de Zemankova-Kaendel . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.7 Modelo GEFRED de Medina et al. . . . . . . . . . . . . . . . . . . . . . . . . 43
2.8 Resumen de los Tipos de Modelos de BDRD . . . . . . . . . . . . . . . . . . 47
2.9 Lenguajes para Consultas Flexibles . . . . . . . . . . . . . . . . . . . . . . . . 48
2.9.1 El Lenguaje SQLf de Bosc y Pivert . . . . . . . . . . . . . . . . . . . . 49
2.9.2 Cuanti cadores Difusos de la Consulta . . . . . . . . . . . . . . . . . . 50
3 Division Relacional Difusa 53
3.1 Introduccion y Enfoque del Problema . . . . . . . . . . . . . . . . . . . . . . 53
3.2 Dos Nuevos Operadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.2.1 Interseccion Difusa Cuali cada: \Q . . . . . . . . . . . . . . . . . . . 55
3.2.2 Proyeccion Difusa Generalizada con Funciones de Grupo F : P F . . . 60
3.2.2.1 Consideraciones Adicionales . . . . . . . . . . . . . . . . . . 64
3.3 Division Relacional Difusa Generalizada:  . . . . . . . . . . . . . . . . . . . 65
3.3.1 De nicion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.3.2 Justi cacion de la Division Difusa Generalizada y Comparacion con la
Formula Clasica de la Division Relacional . . . . . . . . . . . . . . . . 66
3.4 Un Ejemplo Practico de Division Relacional Difusa . . . . . . . . . . . . . . . 67
3.5 Problemas que se Plantean y Posibles Soluciones . . . . . . . . . . . . . . . . 74
3.6 Relajacion del Cuanti cador en la Division Difusa . . . . . . . . . . . . . . . 75
3.7 Estudio Comparativo con otras Propuestas . . . . . . . . . . . . . . . . . . . 78
3.7.1 La Division de Mouaddib . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.7.1.1 Analisis de la Propuesta . . . . . . . . . . . . . . . . . . . . . 80
3.7.2 La Division de Umano/Fukami . . . . . . . . . . . . . . . . . . . . . . 81
3.7.2.1 Analisis de la Propuesta . . . . . . . . . . . . . . . . . . . . . 82
3.7.3 Distintos Tipos de Divisiones para Distintos Signi cados, segun Bosc
et al. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.7.3.1 Analisis de la Propuesta . . . . . . . . . . . . . . . . . . . . . 86
3.7.4 La Division de Yager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
3.7.4.1 Analisis de la Propuesta . . . . . . . . . . . . . . . . . . . . . 91
3.7.5 La Division de Vila et al. . . . . . . . . . . . . . . . . . . . . . . . . . 91
3.7.5.1 Analisis de la Propuesta . . . . . . . . . . . . . . . . . . . . . 93
3.8 Conclusiones y Lneas Futuras sobre la Division Difusa . . . . . . . . . . . . . 95
4 Calculo Relacional Difuso 97
4.1 Calculo Relacional Difuso de Dominios . . . . . . . . . . . . . . . . . . . . . . 98
4.1.1 De nicion de las Expresiones del Calculo Difuso de Dominios . . . . . 98
4.1.1.1 A tomos Difusos . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.1.1.2 Formulas Bien Formadas con A tomos Difusos: WFF (Well
Formed Formulas ) . . . . . . . . . . . . . . . . . . . . . . . . 101
INDICE GENERAL III

4.1.2 Restriccion del Calculo Relacional Difuso para Producir Relaciones Fi-
nitas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.2 Capacidad Expresiva del Calculo Relacional Difuso . . . . . . . . . . . . . . . 104
4.2.1 Operadores Primitivos del A lgebra . . . . . . . . . . . . . . . . . . . . 104
4.2.2 Operadores No Primitivos del A lgebra . . . . . . . . . . . . . . . . . . 106
4.2.3 Traduccion de A lgebra Relacional Difuso a Calculo Relacional Difuso
de Dominios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
4.3 Calculo de la Relacion Difusa Resultante . . . . . . . . . . . . . . . . . . . . . 108
4.3.1 Grado de una variable en una WFF con una sustitucion . . . . . . . . 109
4.3.2 Relacion Difusa Generalizada Resultante . . . . . . . . . . . . . . . . . 115
4.4 Ejemplos de Consultas en Calculo Relacional Difuso . . . . . . . . . . . . . . 116
4.5 Cuanti cadores Difusos en el Calculo Relacional Difuso . . . . . . . . . . . . 129
4.6 Estudio Comparativo con otras Propuestas . . . . . . . . . . . . . . . . . . . 131
4.7 Conclusiones y Lneas Futuras sobre el Calculo Relacional Difuso . . . . . . . 132
5 Arquitectura de la BDRD: El Servidor FSQL 133
5.1 Implementacion de la BDRD: FIRST . . . . . . . . . . . . . . . . . . . . . . . 134
5.1.1 Esquema General de FIRST . . . . . . . . . . . . . . . . . . . . . . . . 134
5.1.2 Representacion del Conocimiento Impreciso . . . . . . . . . . . . . . . 136
5.1.2.1 Representacion de los Datos Difusos y/o con Tratamiento Difuso136
5.1.2.2 Comparadores Difusos Generalizados . . . . . . . . . . . . . 139
5.1.2.3 Umbral de Cumplimiento de una Condicion Difusa: Cuali -
cadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
5.1.2.4 Representacion de Cuanti cadores Difusos de la Consulta . . 140
5.1.3 Implementacion de FIRST en Oracle . . . . . . . . . . . . . . . . . . . 140
5.1.3.1 Representacion del Conocimiento Impreciso en la Base de Da-
tos Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
5.1.3.2 FMB (Fuzzy Metaknowledge Base, Base de Metaconocimiento
Difuso): De nicion de Tablas . . . . . . . . . . . . . . . . . . 144
5.1.3.3 Resumen del Contenido de la FMB . . . . . . . . . . . . . . 152
5.1.3.4 Vistas sobre la FMB . . . . . . . . . . . . . . . . . . . . . . . 153
5.1.4 Ejemplo de Implementacion en FIRST de la BD y la FMB . . . . . . 154
5.2 Sintaxis y Semantica del Lenguaje FSQL . . . . . . . . . . . . . . . . . . . . 160
5.2.1 El DML de FSQL: SELECT, INSERT, DELETE y UPDATE . . . . . . . . . 160
5.2.1.1 Novedades en el SELECT Difuso . . . . . . . . . . . . . . . . . 161
5.2.1.2 Otros Comandos: INSERT, DELETE y UPDATE . . . . . . . . . 167
5.2.1.3 Cuanti cadores en FSQL . . . . . . . . . . . . . . . . . . . . 167
5.2.1.4 De nicion de los Comparadores Difusos de FSQL para Atri-
butos Difusos Tipo 1 o 2 . . . . . . . . . . . . . . . . . . . . 170
5.2.1.5 Equivalencias entre Comparadores Difusos y Excepciones a
sus De niciones . . . . . . . . . . . . . . . . . . . . . . . . . 176
5.2.1.6 Restrictividad de los Comparadores Difusos . . . . . . . . . . 178
5.2.1.7 De nicion del Comparador Difuso FEQ para Atributos Difusos
Tipo 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
5.2.1.8 Tipos de Condiciones Difusas Elementales, Con y Sin Expre-
siones Aritmeticas . . . . . . . . . . . . . . . . . . . . . . . . 179
5.2.1.9 Comparacion de Valores Crisp Usando Comparadores Difusos 183
IV INDICE GENERAL

5.2.1.10 Ejemplos de Consultas en FSQL . . . . . . . . . . . . . . . . 183


5.2.2 El DDL de FSQL: CREATE, ALTER y DROP . . . . . . . . . . . . . . . . 190
5.2.2.1 Comandos del DDL de FSQL . . . . . . . . . . . . . . . . . . 191
5.2.2.2 Ejemplo de Creacion de una BDRD con Sentencias del DDL
de FSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
5.3 Arquitectura del Servidor FSQL . . . . . . . . . . . . . . . . . . . . . . . . . 199
5.3.1 Datos: Base de Datos Tradicional y FMB . . . . . . . . . . . . . . . . 200
5.3.2 Servidor FSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
5.3.3 Cliente FSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
5.3.4 Funcionamiento del Servidor FSQL . . . . . . . . . . . . . . . . . . . . 201
5.4 El Servidor FSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
5.4.1 Informacion y Opciones de Con guracion del Servidor FSQL . . . . . 202
5.4.2 Estadsticas y Controles de Acceso del Servidor FSQL . . . . . . . . . 206
5.4.3 Instalacion/Desinstalacion del Servidor FSQL . . . . . . . . . . . . . . 207
5.4.4 Instalacion/Desinstalacion de una Base de Datos de Ejemplo . . . . . 209
5.5 Implementacion del Servidor FSQL . . . . . . . . . . . . . . . . . . . . . . . . 209
5.5.1 Analizador Lexico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
5.5.2 Analizador Sintactico . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
5.5.3 Analizador Semantico y Conversor . . . . . . . . . . . . . . . . . . . . 217
5.5.3.1 Fase preliminar: Las Tablas, sus Alias y los Comodines . . . 218
5.5.3.2 Fase de Tratamiento de Atributos Difusos . . . . . . . . . . . 218
5.5.3.3 Fase de Tratamiento de la Funcion CDEG . . . . . . . . . . . . 219
5.5.4 Funciones de Representacion y Comparacion Difusa . . . . . . . . . . 220
5.5.4.1 Funciones de Representacion . . . . . . . . . . . . . . . . . . 220
5.5.4.2 Funciones de Comparacion Difusa . . . . . . . . . . . . . . . 223
5.5.5 Como Introducir Nuevos Comparadores Difusos en FSQL y su Servidor 225
5.6 Mejoras Posibles al Sistema FSQL . . . . . . . . . . . . . . . . . . . . . . . . 227
5.6.1 Mejoras al Lenguaje FSQL . . . . . . . . . . . . . . . . . . . . . . . . 227
5.6.2 Mejoras al Servidor FSQL . . . . . . . . . . . . . . . . . . . . . . . . . 229
6 El Cliente FSQL 231
6.1 Objetivo y Funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
6.2 Programacion de Clientes FSQL: Operaciones Basicas . . . . . . . . . . . . . 233
6.2.1 Ejecucion de Sentencias FSQL . . . . . . . . . . . . . . . . . . . . . . 233
6.2.2 Ver las Etiquetas De nidas para un Atributo Difuso . . . . . . . . . . 234
6.2.3 Ver el MARGEN y la Distancia MUCH . . . . . . . . . . . . . . . . . . . . 235
6.2.4 Ver Atributos Difusos Tipo 3 Compatibles y sus Longitudes . . . . . . 236
6.2.5 Ver si estan Instalados los Paquetes del Servidor FSQL . . . . . . . . 236
6.2.6 Ver Funciones que Aplica CDEG para los Operadores Logicos . . . . . . 236
6.2.7 Acceso a Informacion sobre el Servidor FSQL, Estadsticas y otras Op-
ciones de Con guracion . . . . . . . . . . . . . . . . . . . . . . . . . . 237
6.3 Programacion de FQ, un Cliente FSQL . . . . . . . . . . . . . . . . . . . . . 237
6.4 Cliente FSQL Visual en Java . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
INDICE GENERAL V

7 Algunas Aplicaciones del lenguaje FSQL 243


7.1 Clasi cacion Difusa de Imagenes de una Base de Datos . . . . . . . . . . . . . 243
7.1.1 Introduccion al Problema . . . . . . . . . . . . . . . . . . . . . . . . . 243
7.1.2 Representacion de la Forma de un Objeto . . . . . . . . . . . . . . . . 244
7.1.2.1 La Curva de Curvaturas a la Escala Mas Signi cativa . . . . 244
7.1.3 Deteccion de Caractersticas Propias . . . . . . . . . . . . . . . . . . . 245
7.1.4 Clasi cacion, segun las Caractersticas de cada Imagen . . . . . . . . . 248
7.1.4.1 Clasi cacion de Figuras Geometricas . . . . . . . . . . . . . 248
7.1.4.2 Clasi cacion de Figuras Complejas . . . . . . . . . . . . . . . 249
7.2 Data Mining con FSQL en un Entorno Financiero . . . . . . . . . . . . . . . 250
7.2.1 Data Mining como A rea Independiente . . . . . . . . . . . . . . . . . . 250
7.2.2 Tecnicas de Data Mining . . . . . . . . . . . . . . . . . . . . . . . . . 252
7.2.3 DAPHNE: Un Prototipo para Clustering Financiero . . . . . . . . . . 254
7.2.3.1 Funcionamiento de DAPHNE . . . . . . . . . . . . . . . . . . 255
7.2.4 Uso de FSQL para Clustering Difuso . . . . . . . . . . . . . . . . . . . 258
7.2.5 Resultados Experimentales . . . . . . . . . . . . . . . . . . . . . . . . 259
7.3 Gestion de una Inmobiliaria Difusa . . . . . . . . . . . . . . . . . . . . . . . . 261
7.3.1 Objetivos Principales . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
7.3.2 Atributos Difusos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
7.3.3 Ejemplos de Consultas Flexibles . . . . . . . . . . . . . . . . . . . . . 264
Conclusiones y Lneas Futuras 267
A Palabras Reservadas de FSQL 271
B Gramatica de FSQL 273
B.1 Gramatica del SELECT Difuso de FSQL . . . . . . . . . . . . . . . . . . . . . . 273
B.2 Gramatica del INSERT Difuso de FSQL . . . . . . . . . . . . . . . . . . . . . . 282
B.3 Gramatica del DELETE Difuso de FSQL . . . . . . . . . . . . . . . . . . . . . . 283
B.4 Gramatica del UPDATE Difuso de FSQL . . . . . . . . . . . . . . . . . . . . . . 283
B.5 Gramatica de las Sentencias del DDL de FSQL . . . . . . . . . . . . . . . . . 285
C Errores Generados por el Servidor FSQL 297
D Funciones U tiles del Paquete FSQL PKG 311
E Ficheros Generados con este Trabajo 315
E.1 Disco del Servidor FSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
E.2 Discos de FQ: El Cliente FSQL . . . . . . . . . . . . . . . . . . . . . . . . . . 315
F Ejemplos de Sentencias FSQL Traducidas a SQL 319
F.1 DML: Consultas FSQL Traducidas por el Servidor FSQL . . . . . . . . . . . 319
F.2 DDL: Sentencias CREATE, ALTER y DROP de FSQL Traducidas a SQL . . . . . 325
G Manual de Usuario de FQ (Fuzzy Queries) 331
G.1 Instalacion de FQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
G.2 Empezando con FQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
G.3 Las Opciones de FQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
VI INDICE GENERAL

G.3.1 Menu Archivo (File) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334


G.3.2 Menu Edicion (Edit) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
G.3.3 Menu SGBD (DBMS) . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
G.3.4 Menu Insertar (Insert) . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
G.3.5 Menu Opciones (Options) . . . . . . . . . . . . . . . . . . . . . . . . . 343
G.3.6 Menu Herramientas (Tools) . . . . . . . . . . . . . . . . . . . . . . . . 344
G.3.7 Menu Ayuda (Help) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
G.4 La Ventana de Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
G.4.1 Submenu Archivo (File) . . . . . . . . . . . . . . . . . . . . . . . . . . 346
G.4.2 Submenu Opciones (Options) . . . . . . . . . . . . . . . . . . . . . . . 347
G.5 Sobre los Tiempos de Traduccion y Recuperacion . . . . . . . . . . . . . . . . 350
G.6 Mejoras para Sucesivas Versiones . . . . . . . . . . . . . . . . . . . . . . . . . 351
H Glosario de Terminos y Siglas 353
Referencias Bibliogra cas 359
Marcas Registradas 371
Indices 373
Indice de Tablas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Indice de Figuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
Indice de Materias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
Agradecimientos y Dedicatorias
No han sido pocos los que, de alguna forma, han colaborado a que pueda terminar este
trabajo. A todos ellos quiero expresar mi agradecimiento mas sincero y \crisp".
Aun pudiendo caer en el error de olvidar a alguien, me gustara nombrar a algunos para
agradecerles explcitamente su colaboracion y apoyo: A todos los miembros en general del
grupo de trabajo en \Razonamiento Aproximado e Inteligencia Arti cial" del Departamento
de Ciencias de la Computacion e Inteligencia Arti cial de la Universidad de Granada y en
particular a Juan Miguel Medina y Amparo Vila; al Gobierno Espa~nol, a traves del proyecto
TIC97-0931, y a la \Caja General de Ahorros de Granada" por su colaboracion en el trabajo
sobre Data Mining y FSQL (apartado 7.2); a Ramon Alberto Carrasco, Antonio Caba y Jose
Andres Carreras; a la Universidad de Malaga y en particular a los miembros del Departamento
de Lenguajes y Ciencias de la Computacion.
Tambien quiero dedicar este trabajo y agradecer el apoyo de mis padres y hermanas, mis
suegros y cu~nados, mi abuela Esperanza, mi sobrino Carlos, mi mujer M. Carmen Aran-
da y, por supuesto, mi hija Patricia, a quien, ademas de agradecer su increble capacidad
comprensiva tambien quiero dedicarle este trabajo muy especialmente.
En general, me gustara dedicar este trabajo a los ni~nos y ni~nas del mundo, pues ellos son
el presente y el futuro y por ellos, y no por nosotros, debemos luchar todos para conseguirles
un mundo mas justo, mas limpio y lleno de vida.

1
2 AGRADECIMIENTOS Y DEDICATORIAS
Captulo 1
Introduccion: Bases de Datos y
Teora de Conjuntos Difusos
1.1 Motivacion y Objetivos
La evolucion de las bases de datos comenzo con el uso, de forma elemental, de cheros secuen-
ciales. Con el tiempo, se fueron creando aplicaciones para estos cheros y fueron surgiendo
diversos problemas, como son la e ciencia en la recuperacion de informacion, la redundancia,
seguridad... As, nacieron los primeros Sistemas Gestores de Bases de Datos (SGBD o DBMS,
DataBase Management Systems ), como programas encargados de gestionar el almacenamien-
to y recuperacion de la informacion, teniendo en cuenta los aspectos y problemas que esto
plantea.
La arquitectura ANSI/SPARC data de 1978 y en ella se propone la division de un SGBD
en tres niveles: El nivel interno, el nivel conceptual y el nivel externo. El nivel interno es
el mas cercano a la parte fsica del SGBD, y se encarga de como y donde son almacenados
fsicamente los datos. El nivel conceptual se encarga de organizar las relaciones existentes
entre los datos, describiendo las entidades, atributos, relaciones, tipos de datos, operaciones
basicas y restricciones de la base de datos global. El nivel externo es el mas cercano al usuario
y se encarga de describir una parte de la base de datos para un usuario o grupo de usuarios
particular, escondiendo el resto de la base de datos y evitando el acceso de los usuarios a
informacion privada.
Estos tres niveles son muy importantes en todos los SGBD, pero quizas el mas relevante
de ellos sea el nivel conceptual. Originariamente, el nivel conceptual permite la utilizacion
de tipos de datos elementales a los que llamaremos \crisp" (en contraposicion a los tipos
difusos que veremos mas adelante). Estos tipos de datos son, por ejemplo, datos numericos
(basicamente naturales, enteros y reales con distinta precision), datos alfanumericos (cadenas
de caracteres de distinta longitud) y datos binarios (como cheros de imagenes, sonido...).
Ademas, un SGBD debe incorporar un conjunto de operaciones basicas sobre la base de datos
para, por ejemplo, insertar, modi car, borrar o consultar informacion. De estas, las mas
importantes y usuales seran aquellas destinadas a la consulta de informacion. Por ejemplo,
se pueden efectuar preguntas del tipo \dame las personas que tienen mas de 17 a~nos y menos
de 25".
Las bases de datos tradicionales o clasicas no permiten el almacenamiento de concep-
tos \difusos" que los humanos manejamos de forma cotidiana y natural. Por conceptos o
3
4 CAPITULO 1. INTRODUCCION:
 BASES DE DATOS Y CONJUNTOS DIFUSOS

informacion \difusa" (o fuzzy ) entendemos informacion que encierra alguna imprecision o in-
certidumbre. Por ejemplo, el concepto de persona \joven" indica claramente que la persona no
tiene 80 a~nos, pero no indica explcitamente su edad exacta. En bases de datos tradicionales
se podra almacenar la etiqueta \joven" como de forma textual (dato alfanumerico), pero esto,
ademas de complicar el almacenamiento de edades numericas normales, nos imposibilita el
tratamiento apropiado de esta informacion. Es decir, podemos almacenar la palabra \joven",
pero no la informacion que esta expresa. De este modo, cuestiones como \dame las personas
que tienen menos de 40 a~nos" no se podran resolver, pues habra que comparar el numero 40
con la cadena de caracteres \joven". Ademas, otro tipo de consultas son tambien imposibles
de efectuar en bases de datos clasicas, como son \dame las personas que son jovenes" o \cuya
edad es cercana a \joven".
Las bases de datos difusas unieron la teora de bases de datos, principalmente del mo-
delo relacional (apartado 1.2) con la teora de conjuntos difusos (apartado 1.3), para permitir,
basicamente dos objetivos: El almacenamiento de informacion difusa (ademas de informacion
no difusa o \crisp", por supuesto) y el tratamiento y consulta de esta informacion de forma
difusa o exible. Ligado a esto han surgido propuestas en multitud de sentidos, incluyendo
la consulta difusa en bases de datos clasicas, sin informacion difusa. Algunos ejemplos de
esas propuestas seran expuestas en el Captulo 2 y en el apartado 3.7, destacando el Modelo
GEFRED (apartado 2.7) como una sntesis de los modelos mas relevantes publicados en la
literatura.
Queremos hacer hincapie en un aspecto de las bases de datos difusas, que nos parece
de vital importancia en estas: Cada elemento resultante de una consulta difusa debera ser
recuperado junto con un grado que indique el nivel con el que dicho elemento ha satisfecho
la condicion difusa impuesta en la consulta. A este grado lo llamaremos grado de cumpli-
miento, de compatibilidad o nivel de satisfaccion. Este grado de cumplimiento suele ser un
valor real entre 0 (condicion no satisfecha en absoluto) y 1 (condicion totalmente satisfecha).
El grado de cumplimiento es fundamental, pues es una ventaja importante con respecto a
las bases de datos clasicas. Es decir, la pregunta \dame las personas jovenes" en una base de
datos clasica sera traducida, por ejemplo, como \dame las personas que tienen entre 17 y 25
a~nos". Con esa consulta, una base de datos clasica recupera exclusivamente las personas que
tienen una edad entre 17 y 25 a~nos y no recuperara una persona que tenga 16 o 26 a~nos, por
ejemplo. Sin embargo, una persona con 16 o 26 a~nos es tambien \joven" en algun nivel. Por
el contrario, a la consulta \dame las personas jovenes" una base de datos difusa respondera
recuperando cada persona con un grado de cumplimiento indicando en que medida cada
persona es \joven". Por ejemplo, podemos obtener como resultado de la consulta anterior la
relacion de la Tabla 1.1.
As pues, en bases de datos difusas podemos efectuar consultas exibles y muy expresi-
vas estableciendo umbrales de cumplimiento para las condiciones difusas, como por ejemplo,
\dame las personas jovenes con grado mnimo 0.75".
Aunque a primera vista pueda no parecerlo, el uso de informacion difusa hace surgir nu-
merosos problemas que no se plantean con informacion \crisp". En este trabajo pretendemos
estudiar tales problemas y plantear soluciones para eliminarlos o para evitar, en lo posible,
sus efectos. Principalmente, nos centraremos en estudiar la operacion de la division relacional
en bases de datos difusas y la creacion de un lenguaje de consulta difuso basado en el calculo
relacional.
Tambien presentamos el Servidor FSQL, que es un prototipo multiusuario de bases de
datos difusas construido sobre el SGBD Oracle (apartado 1.2.6). El Servidor FSQL permite
 Y OBJETIVOS
1.1. MOTIVACION 5

Grado de
Nombre Edad Cumplimiento
Fulano 23 1.0
Mengano Joven 1.0
Pepe 28 0.8
Juanito 13 0.7
Benito Maduro 0.5
Zutano Aprox. 33 0.1
Matusalen 969 0.0
 Matusalen o Matusalem fue un Patriarca bblico antediluviano
(Gen. 5, 21{27) al que la Biblia le computa 969 a~nos.
Tabla 1.1: Resultado de ejemplo de la consulta difusa \dame las personas jovenes".

el almacenamiento de informacion difusa y su tratamiento a traves de otro lenguaje especial


para manejo y de nicion de informacion difusa, el FSQL (Fuzzy SQL), que es una extension
del popular lenguaje SQL (apartado 1.2.5). Por supuesto, este lenguaje permite recuperar los
grados de cumplimiento.
1.1.1 Descripcion por Captulos
De una forma rapida y general, podemos describir el contenido de esta memoria explicando
brevemente el contenido de los captulos:
 Captulo 1: Se da una introduccion general y se plantean los objetivos de este trabajo.
Se incluyen una introduccion a los conceptos de Bases de Datos Relacionales y de la
Teora de Conjuntos Difusos, los cuales seran utilizados a lo largo de esta memoria.
 Captulo 2: Se introducen los principales modelos publicados para dar solucion al
tratamiento de informacion \imprecisa" en bases de datos relacionales, especialmente
aquellos que utilizan la teora de Conjuntos Difusos. En particular, nos centramos en el
modelo GEFRED, sobre el que esta construido todo este trabajo. Se incluye una vision
general de las diferentes caractersticas que distinguen los distintos modelos de Bases
de Datos Relacionales Difusas (BDRD).
 Captulo 3: Se de ne el operador Division Relacional del A lgebra Relacional, pero
para trabajar con Bases de Datos Relacionales Difusas (BDRD). Para ello, se de nen dos
nuevos operadores con utilidad por s mismos. Al nal se incluye un analisis comparativo
con otros modelos de Division Relacional Difusa.
 Captulo 4: Se de ne un Calculo Relacional de Dominios para una BDRD, as como un
mecanismo para calcular para cada tupla los grados de cumplimiento de las condiciones
impuestas en la formula bien formada de la expresion.
 Captulo 5: Este captulo trata sobre como se ha implementado el Servidor FSQL. Para
ello, primero se de nen dos conceptos que seran utilizados en esta implementacion: Una
arquitectura para una BDRD basada en Oracle y un lenguaje de consulta y de nicion
de datos para BDRD basado en SQL, el lenguaje FSQL. Se incluye una descripcion
detallada de las caractersticas del Servidor FSQL y de su implementacion.
6 CAPITULO 1. INTRODUCCION:
 BASES DE DATOS Y CONJUNTOS DIFUSOS

 Captulo 6: En este captulo se explican los objetivos y caractersticas basicas de los


programas Cliente FSQL, que son utilizados como interfaz entre el usuario y el Servidor
FSQL del captulo anterior. Ademas, se explica el funcionamiento de la comunicacion
entre Cliente y Servidor FSQL y como programar un Cliente FSQL, as como una serie
de operaciones utiles en estos programas. Se incluye una breve referencia a como esta
implementado el programa FQ, un Cliente FSQL creado para este trabajo, y el proyecto
de creacion de un cliente FSQL Visual, en Java para que pueda ser ejecutado a traves
de Internet.
 Captulo 7: De poco o nada servira todo este trabajo si no tuviera aplicaciones
practicas. En este captulo exponemos algunas de las aplicaciones practicas que hemos
estudiado y en algunos casos implementado.
 Apendices: En los apendices se incluye informacion general, adicional o de consulta
que puede ser util para el entendimiento de algunos apartados espec cos:
A Lista con las Palabras Reservadas de FSQL que utiliza el Servidor FSQL.
B Se incluyen, en formato Yacc, la gramatica empleada por del Servidor FSQL de
consultas difusas (sentencia SELECT), las gramaticas para otras sentencias del DML
de FSQL y la gramatica para sentencias del DDL de FSQL.
C Lista con todos los posibles mensajes de error que puede detectar el Servidor FSQL,
su signi cado y algunas pautas para subsanarlos.
D Descripcion de las funciones que pueden utilizarse del paquete FSQL PKG, incluido
con el Servidor FSQL.
E Descripcion del contenido y utilidad de todos los discos y cheros generados en este
trabajo.
F Lista de ejemplos de sentencias de FSQL traducidas a SQL.
G Manual de usuario de FQ, el Cliente FSQL creado para esta memoria y que en el
Captulo 6 se explica como fue programado.
H Glosario en el que se explican brevemente algunos terminos y siglas empleados en
esta memoria y que puede resultar util consultar en cualquier momento.
Esta memoria se cierra con una lista de las referencias bibliogra cas utilizadas, una lista
de las marcas registradas que se mencionan en esta memoria, ndices de tablas y guras
aparecidas en el texto y un ndice de materias para facilitar la localizacion (por paginas)
de algunos conceptos concretos o las referencias a los autores mas relevantes (buscar por
\Autores").

1.2 Modelo Relacional de Bases de Datos


En esta seccion intentaremos dar una vision general de lo que son las bases de datos en general
y el Modelo Relacional en particular. No pretendemos dar una explicacion exhaustiva de su
de nicion ni de sus caractersticas pues ya existen en la bibliografa multitud de libros sobre
el tema con distintos enfoques [51, 86, 132, 141].
1.2. MODELO RELACIONAL DE BASES DE DATOS 7

Entenderemos por Base de Datos un repositorio o conjunto de datos almacenados,


normalmente en dispositivos electronicos de un ordenador, y que son gestionados (para lectura
y/o escritura) por un programa llamado Sistema Gestor de Bases de Datos (SGBD).
Los datos de una base de datos no deben tener redundancias (un mismo dato no debe estar
almacenado en distintos lugares) y pueden ser compartidos por varios usuarios del SGBD.
El SGBD maneja las solicitudes de acceso a la base de datos por parte de los usuarios,
ocultando a estos detalles sobre el hardware donde los datos estan almacenados. Ademas, el
SGBD se encarga de tareas como la privacidad de los datos y la e ciencia en su acceso.
La gestion de bases de datos se empezo a hacer popular en los a~nos 1970s y 1980s y hoy da
su uso esta ampliamente extendido, usandose en multitud de peque~nas y medianas empresas
y no solo en las grandes.
En todas las bases de datos se almacena informacion sobre determinadas entidades u
objetos y sobre las relaciones existentes entre algunas de estas entidades.
Los modelos de bases de datos que mas se generalizaron fueron:
1. Modelo jerarquico: Los datos se representan por una estructura en arbol, donde los
datos inferiores dependen o estan incluidos en los datos superiores. Su limitacion radica
en el hecho de que solo permite representar directamente relaciones de uno a muchos.
2. Modelo en red: Los datos se pueden ver como en el modelo jerarquico, pero sin
limitacion en cuanto a su organizacion, de forma que los datos inferiores pueden estar
tambien relacionados con varios de los superiores. As, permite modelar mejor una
correspondencia de muchos a muchos.
3. Modelo relacional: En este modelo todos los datos son vistos en forma de tabla o
relacion. Es el mas extendido por su facilidad de comprension y lo veremos mas en
profundidad a continuacion.
El Modelo relacional de bases de datos fue propuesto por Dr. E.F. Codd de IBM en
1970 y publicado en [41], en un intento de simpli car la estructura de la base de datos, que
llegaba a ser demasiado compleja en otros modelos. Pronto, el modelo relacional se popularizo,
aunque muchos de los sistemas que se llamaban relacionales no lo eran realmente. Por eso,
Codd publico una lista de 12 reglas que deberan cumplir todos los SGBD Relacionales [45].
De nicion 1.1 Llamaremos Base de Datos Relacional (BDR) a aquella base de datos
donde todos los datos visibles al usuario estan organizados estrictamente como tablas (o rela-
ciones) de datos y donde todas las operaciones de la base de datos trabajan sobre estas tablas
y/o producen nuevas tablas. El SGBD Relacionales (SGBDR) es un SGBD que trabaja sobre
este tipo de bases de datos. tu
Esta de nicion, junto con las caractersticas basicas de toda base de datos, nos lleva a
tener que de nir los siguientes apartados:
1. Estructuras de datos empleadas: Las tablas o relaciones.
2. Integridad de los datos: Claves primarias, candidatas y externas.
3. De nicion de los datos: Lenguajes (DDL) basicamente para la creacion, borrado y
alteracion de la estructura de las tablas y objetos de la base de datos relacional.
4. Manipulacion de los datos: Lenguajes (DML) basicamente para la consulta, modi-
cacion e insercion de datos.
8 CAPITULO 1. INTRODUCCION:
 BASES DE DATOS Y CONJUNTOS DIFUSOS

1.2.1 Estructuras de Datos: Tablas o Relaciones


La estructura de los datos viene caracterizada por el concepto de tabla o relacion. Para
precisar dicho concepto es necesaria la de nicion previa de algunos conceptos:
De nicion 1.2 Llamaremos Atributo, Campo o Columna (Attribute, Column) a cada
una de las caractersticas importantes y variables que tiene cualquier tipo de entidad u objeto
y que son almacenadas en una base de datos, para reconocer a dicha entidad u objeto. No nos
importara que dicha entidad tenga otros atributos, pero solo trataremos aquellos que realmente
nos interesan y que, por tanto, deseamos almacenar en nuestra base de datos. tu
De nicion 1.3 Llamaremos Dominio (Domain) al conjunto de todos los valores posibles
que puede tomar un atributo. Por tanto, todos los atributos tendran un dominio asociado.
tu
Una caracterstica inicial que se le exiga a los valores del dominio era la atomicidad, en el
sentido de que no exista una descomposicion de los mismos que aporte signi cado. No obstante
esta premisa se ha relajado con la evolucion del modelo, y actualmente se encuentran en la
literatura muchas matizaciones de la misma. Un dominio puede llevar asociado un conjunto
de operadores espec cos del mismo. Por ejemplo, el dominio de los numeros enteros tiene
operadores como la suma y la resta.
De nicion 1.4 Llamaremos Tupla al conjunto de todos los valores concretos de todos los
atributos de una determinada entidad u objeto. tu
De nicion 1.5 Llamaremos Valor de Dominio a un valor concreto de una tupla. O sea
es el valor para un atributo concreto de una entidad concreta. tu
Con estos conceptos podemos de nir lo que es una relacion:
De nicion 1.6 Llamaremos Relacion o Tabla (Relation, Table) a el conjunto de dos par-
tes, cabecera y cuerpo:
 La cabecera consiste en un conjunto jo de n pares atributo-dominio,

f(A1 : D1 ); (A2 : D2 ); :::; (An : Dn)g


donde cada atributo Aj se corresponde exactamente con el dominio subyacente Dj con
j = 1; 2; :::; n, siendo estos dominios no necesariamente distintos.
 El cuerpo consta de un conjunto de tuplas, donde cada tupla consiste en un conjunto
de n pares atributo-valor,

f(A1 : vi1); (A2 : vi2); :::; (An : vin)g


con i = 1; 2; :::; m, siendo m el numero de tuplas que contiene el conjunto. Para cada
atributo Aj existe un par atributo-valor (Aj : vij ) donde vij es el Valor de Dominio del
atributo Aj perteneciente al dominio Dj de la entidad o tupla i-esima.
1.2. MODELO RELACIONAL DE BASES DE DATOS 9

Los valores m y n se denominan cardinalidad y grado de la relacion, respectivamen-


te. Mientras que el grado se mantiene constante en el tiempo para una relacion, la
cardinalidad puede variar en una misma relacion con el tiempo.
Cada relacion tiene un nombre que identi ca a todo su contenido y que sera usado para
expresar las operaciones que se realicen sobre la relacion. tu
Otras de niciones utiles para expresar las restricciones de integridad son:
De nicion 1.7 Llamaremos Clave o Llave Primaria (Primary Key) al conjunto de atri-
butos que se usaran para identi car unvocamente cada tupla de una relacion. Este conjunto
debe ser mnimo, es decir, que no exista un subconjunto de el que pueda usarse con el mismo
proposito. Pueden existir varios de estos conjuntos para una relacion dada, pero solamente
se seleccionara uno de estos como Clave Primaria, quedando los restantes como Claves Al-
ternativas o Claves Candidatas. tu
De nicion 1.8 Llamaremos Clave o Llave Externa (Foreign Key) al conjunto de atribu-
tos de una relacion que son Clave primaria o candidata en otra relacion distinta y que pueden
usarse para enlazar o relacionar los datos de ambas relaciones. tu
De su de nicion se obtienen las siguientes propiedades para las relaciones:
1. No hay tuplas duplicadas1: Esto implica que siempre debera existir una clave primaria.
La necesidad de que exista una clave primaria para cada relacion estriba en que es la
unica forma de acceder de forma unvoca a cada tupla de la misma. A veces, la clave
primaria puede ser el conjunto de todos los atributos que forman la relacion.
2. Los atributos no estan ordenados. Esta propiedad proviene del hecho de que la cabecera
de una relacion es un conjunto matematico.
3. Las tuplas no se encuentran ordenadas. Tambien esta propiedad se apoya en que la
de nicion del cuerpo de una relacion se corresponde con un conjunto matematico.
4. Los valores de los atributos son atomicos, en el sentido en el que apuntabamos cuando
introducamos el concepto de dominio. Una relacion que cumpla esta propiedad se dice
que esta NORMALIZADA. Aunque a primera vista esta propiedad pueda suponer una
fuerte restriccion a la representacion de imprecision, se pueden hacer lecturas de la
misma que posibiliten la representacion de este tipo de informacion sin ocasionar una
perdida de validez del modelo. En el Captulo 2 se prestara una atencion especial al
estudio del tratamiento que diferentes modelos proporcionan a esta propiedad.
1.2.2 Integridad de los Datos
Una base de datos consiste en una con guracion de datos que se supone que representan
una porcion del mundo real. Ningun modelo de base de datos puede garantizar que esa
representacion se corresponda con la realidad en todo momento, esto supondra, entre otras
1 En algunas implementaciones particulares, se permiten que existan duplicados en la relacion resultante de
una consulta. En SQL, por ejemplo, se dispone de la palabra reservada DISTINCT para especi car que no se
muestren las tuplas repetidas en la relacion resultante.
10 CAPITULO 1. INTRODUCCION:
 BASES DE DATOS Y CONJUNTOS DIFUSOS

cosas, que la base de datos tendra que poseer un conocimiento, no solo sobre los datos,
sino tambien sobre su signi cado. Lo que s puede y debe hacer un SGBD es impedir que se
introduzca informacion que no pueda ser identi cada, ni que se haga referencia en un lugar de
la base de datos a informacion que no exista en la misma. Estos son los enunciados informales
de las reglas de Identidad y Referencial respectivamente. En forma mas precisa pueden ser
formulados como sigue:
 Regla de Identidad: Ningun componente de la clave primaria de una relacion base
puede aceptar un valor nulo.
Donde nulo signi ca que la informacion no se encuentra por alguna razon (como por
ejemplo que la propiedad no sea aplicable o que el valor sea desconocido).
 Regla de Integridad Referencial: La base de datos no puede contener valores para
la clave externa que no hallen correspondencia con los adoptados por la clave primaria
de la relacion a la que hacen referencia.
1.2.3 De nicion de los datos
Los lenguajes de de nicion de datos o DDL (Data De nition Language) permiten la creacion,
modi cacion y eliminacion de objetos de la base de datos relacional. Estos objetos pueden
ser de diversos tipos segun el SGBD y estan desde los basicos como los son tablas, vistas o
ndices, hasta los mas so sticados como son snapshots, sinonimos, procedimientos y funciones
almacenadas, paquetes de funciones y procedimientos, clusters, secuencias, roles, triggers...
Para esto existe un lenguaje ampliamente extendido en la actualidad: El lenguaje SQL
(en su parte DDL), del que hablaremos mas adelante (apartado 1.2.5).
1.2.4 Manipulacion de los Datos: A lgebra y Calculo Relacional
Los lenguajes de manipulacion de datos o DML (Data Manipulation Language) permiten la
consulta, modi cacion e insercion de datos. Para esto, el lenguaje SQL (en su parte DML),
del que hablaremos mas adelante, es tambien muy utilizado.
Las consultas forman la parte mas importante de la manipulacion de datos pues en una
base de datos hay informacion almacenada en distintas tablas y su objetivo es poder consultar
toda esta informacion y la relacion que exista entre ella. Para tal n puede ser util emplear
varias relaciones en una misma consulta.
En [42], Codd dise~no dos niveles de lenguajes formales para la Manipulacion de Datos: El
Algebra Relacional y el Calculo Relacional. Estos dos lenguajes son la base de cualquier otro
lenguaje y son mencionados y explicados ampliamente en la bibliografa.
El A lgebra proporciona un conjunto de operadores mediante los cuales especi car la
operacion a realizar sobre las tablas, mientras que el Calculo proporciona una sintaxis con
la que expresar aquello que se desea obtener de las relaciones sin tener que especi car el
mecanismo para obtenerlo. O sea, en el A lgebra hay que indicar como se recuperan los datos
de nuestra consulta a traves de sus operadores y en el Calculo hay que indicar que datos
queremos recuperar, sin especi car como hacerlo.
De niciones del A lgebra y del Calculo Relacional, en sus dos versiones Calculo de tuplas y
Calculo de dominios, pueden encontrarse en la bibliografa numerosas veces [17, 51, 132, 141].
En [141] Ullman expone como pasar una expresion en algebra a otra en calculo de tuplas,
como pasar una expresion en calculo de tuplas a otra en calculo de dominios y como pasar
1.2. MODELO RELACIONAL DE BASES DE DATOS 11

una expresion en calculo de dominios a otra en algebra, demostrando la equivalencia total de


estos lenguajes.
1.2.4.1 A lgebra Relacional
Este lenguaje de consulta dispone de unos operadores que, individualmente y combinandolos,
permiten expresar practicamente cualquier tipo de consulta a una base de datos clasica.
Estos operadores actuan sobre relaciones existentes produciendo nuevas relaciones. Existen
tres tipos de operadores:
 Operador de asignacion: Asigna el resultado de otras operaciones sobre relaciones a
una nueva relacion. A traves de este operador es posible conservar el resultado de otras
operaciones anteriores.
 Operadores tradicionales sobre conjuntos: Son Union, Interseccion, Diferencia y Pro-
ducto Cartesiano. Salvo para el Producto Cartesiano, es necesario que las relaciones
sobre las que operan sean compatibles, en el sentido de que posean el mismo grado y de
que esten de nidas sobre el mismo producto cartesiano de dominios.
{ Union (Union ): La union de dos relaciones R y S es el conjunto de aquellas tuplas
que pertenecen a la relacion R, a la relacion S o a ambas relaciones. Lo notaremos
como R [ S .
{ Interseccion (Intersection ): La interseccion de dos relaciones R y S da como
resultado el conjunto de aquellas tuplas que pertenecen a R y a S . Lo notaremos
como R \ S .
{ Diferencia o Resta (Di erence ): La diferencia de dos relaciones R y S es el
conjunto de tuplas que pertenecen a R y no pertenecen a S . Lo notaremos como
R S.
{ Producto Cartesiano (Cartesian Product, Times ): El producto cartesiano de
dos relaciones R y S consiste en todas las posibles combinaciones de pares de
tuplas, una de cada relacion. Lo notaremos como R  S .
 Operaciones especiales: Son Seleccion, Proyeccion, Reunion y Division.
{ Seleccion (Selection ): Este operador extrae de una relacion R, un subconjunto de
tuplas que cumple una condicion. Esta condicion puede ser: atomica o compuesta.
Una condicion atomica o simple esta formada por una sola comparacion, mientras
que en el segundo caso se trata de un conjunto de condiciones atomicas combinadas
mediante el uso de operadores logicos (NOT, AND y OR). Lo notaremos como
F (R), donde F es una formula o condicion que puede incluir atributos de la
relacion R, constantes de cualquier dominio, comparadores aritmeticos (>, , <,
, = y 6=) y operadores logicos.
{ Proyeccion (Projection ): Con esta operacion podemos eliminar de una relacion
los atributos que no nos interesen en cada momento, proyectando la relacion en
cuestion sobre los atributos que s nos interesen. Una proyeccion produce un sub-
conjunto \vertical" de una relacion R. Lo notaremos como r1 ;r2 ;:::;rn (R), donde
los ri son atributos de la relacion R.
12 CAPITULO 1. INTRODUCCION:
 BASES DE DATOS Y CONJUNTOS DIFUSOS

{ Reunion (Join ): Mediante este operador, a partir de dos relaciones R y S , se


construye una relacion compuesta de todas las posibles combinaciones de pares de
tuplas concatenadas, pertenecientes, una a la relacion R y la otra a la relacion
S , tales que las tuplas que componen el par satisfacen una condicion comun. Se
notara como R 1rs S , donde r es un atributo de R, s es un atributo de S y  es
un comparador aritmetico que da nombre a la operacion: -Reunion.
En el caso de que la condicion sea la igualdad \=" entre algunos atributos de R y
S , se hablara de Equi-Reunion.
{ Reunion Natural (Natural Join ): Es una reunion en la que la condicion es la
igualdad pero entre todos los atributos de R con igual nombre que los de S y por
tanto, en el resultado nal solo aparecera uno de los dos (o el atributo de R o el
de S ), ya que son iguales. Se notara como R 1 S .
{ Division (Division, Quotient ): Dada una relacion R con la cabecera (A; B ) y una
relacion S con cabecera (B ), donde A y B son atributos simples o conjuntos de
atributos, se de ne la Division Relacional de R entre S , que se notara como
R  S , a una relacion Q con cabecera (A) y cuyo cuerpo esta constituido por todas
las tuplas (A : a) tales que existe una tupla (A : a; B : b) en R para cada tupla
(B : b) que aparece en S .
Entonces, diremos que las tuplas de la relacion Q cumplen los requisitos de la
division R  S .
Tanto la relacion R como la S pueden ser relaciones base de la Base de Datos o
pueden ser el resultado de cualquier tipo de operacion algebraica.
A veces, se generaliza la de nicion anterior, extendiendo la division y considerando
el caso en el que la relacion S tenga tambien atributos no comunes con la relacion
R. En ese caso, si la cabecera de S la representamos como (B; C ) el resultado
seran las tuplas (A : a; C : c) tales que existe una tupla (A : a; B : b) en R por
todas las tuplas (B : b; C : c) que aparecen en S . El resultado es equivalente a
hacer la division de R entre la proyeccion de R0 sobre B y posteriormente hacer el
producto cartesiano entre la relacion resultante y la proyeccion de S sobre C .
En realidad los unicos operadores del A lgebra que son realmente imprescindibles son los
llamados operadores primitivos: Union, Diferencia, Producto Cartesiano, Proyeccion y
Seleccion. El resto pueden ponerse en funcion de los anteriores:
 Interseccion:
R \ S = R (R S ) (1.1)
 Reunion: La operacion de Reunion es como una seleccion sobre el producto cartesiano
entre R y S :
R 1rs S = rs(R  S ) (1.2)
 Reunion Natural: Es como una proyeccion sobre una seleccion sobre el producto
cartesiano entre R y S .
R 1 S = d R:a=S:a (R  S ) (1.3)
donde:
1.2. MODELO RELACIONAL DE BASES DE DATOS 13

d hace referencia a la union sin duplicados de los atributos de R y S .


R:a y S:a son todos los atributos de R y S respectivamente que se llaman igual en
ambas relaciones.
 Division: La division es un poco mas compleja de expresar en funcion de los demas
operadores. Segun el esquema anterior, tenemos que la division relacional tiene su
equivalencia en operadores primitivos en lo que llamaremos formula clasica de la division
relacional :
R  S = A (R) A((A (R)  S ) R) (1.4)
1.2.4.2 Calculo Relacional
El Calculo Relacional usa el calculo de predicados de primer orden. Esta idea de usar el calculo
de predicados como base de un lenguaje de consulta parece haberse originado en un artculo
de Kuhns [94], aunque aplicado a Bases de Datos Relacionales fue propuesto en su forma
original en [42], como hemos dicho. En ese artculo, Codd tambien introduce el concepto
de completitud relacional: Se dice que un lenguaje es relacionalmente completo si posee
la propiedad de que cualquier relacion (consulta) de nible por medio de las expresiones del
calculo se puede recuperar mediante proposiciones pertinentes de ese lenguaje. En el artculo
tambien describe el \algoritmo de reduccion de Codd" por el que se puede convertir una
expresion arbitraria del Calculo en una expresion del A lgebra semanticamente equivalente,
mostrando as la completitud del A lgebra relacional y dando una posible forma de realizar el
Calculo.
El Calculo de Codd se conoce como calculo de tuplas porque se basa en el concepto de
variable de tupla, que es una variable que toma los valores de las tuplas de alguna relacion
o de la union de dos o mas relaciones, es decir, una variable tupla tiene como unicos valores
permitidos las tuplas de una unica relacion o de una union.
Una implementacion del calculo de tuplas fue el lenguaje QUEL, usado en el sistema
INGRES [89]. El lenguaje SQL incorpora tambien elementos del calculo (ver apartado 1.2.5).
En 1977, Lacroix y Pirotte propusieron en [95] un calculo relacional alternativo, el calculo
de dominios, en donde las variables de tupla se sustituyen por variables de dominio, que
varan sobre los dominios subyacentes de los atributos de las relaciones. Los mismos autores
presentaron en [96] un lenguaje basado en este calculo, el ILL. Pirotte y Wodon presentaron
en [126] el lenguaje FQL, mucho mas formal que el ILL. Query By Example (QBE), presen-
tado por Zloof en [173] y otros artculos, tambien se puede considerar como una realizacion
particular del calculo de dominios.
Una expresion en el Calculo Relacional Orientado a Tuplas toma la siguiente forma:

ft j (t)g
donde
t es una variable tupla, que es una variable que denota una tupla de longitud ja, con unos
dominios jos en sus atributos. Notaremos como t[i] al i-esimo atributo de la tupla t o
como t:nombre al atributo cuyo nombre es puesto tras el punto. A veces puede ser util
indicar que t tiene n atributos, para lo que usaremos la siguiente notacion: t(n) .
14 CAPITULO 1. INTRODUCCION:
 BASES DE DATOS Y CONJUNTOS DIFUSOS

es una formula construida por atomos y operadores, que describimos a continuacion


Un atomo puede ser de dos formas:
1. Pertenencia: R(t), donde R es una relacion y t una variable tupla. Este atomo expresa
la a rmacion de que t pertenece a R. Esta a rmacion expresa tambien, logicamente,
que t tiene los dominios de R.
2. Comparacion: xy, donde  es un comparador aritmetico y x e y son constantes o
atributos particulares de una variable tupla. Este atomo expresa la a rmacion de que
x se relaciona con y mediante .
A continuacion, de nimos los operadores validos y lo que son ocurrencias de variables
libres y ligadas, a la vez que de nimos el concepto de Formula Bien Formada o WFF
(Well Formed Formula). Una WFF esta de nida de la siguiente forma:
1. Un atomo es una WFF. Todas sus ocurrencias de variables de dominio son libres.
2. Si es una WFF, tambien lo es : (NOT ). La formula : sostiene que es falsa.
Las ocurrencias de variables de dominio en : son libres o ligadas segun esten en .
3. Si 1 y 2 son WFF, tambien lo son 1 _ 2 ( 1 OR 2 ) y 1 ^ 2 ( 1 AND 2 ). La
formula 1 _ 2 sostiene que es cierta 1 o es cierta 2 o lo son ambas, y la formula
1 ^ 2 sostiene que 1 y 2 son ambas ciertas. Las ocurrencias de variables de dominio
en 1 _ 2 y 1 ^ 2 son libres o ligadas segun esten en 1 y 2 .
4. Si 1 y 2 son WFF, tambien lo es 1 ! 2 (IF 1 THEN 2 ), indicando que si 1 es
cierta tambien lo es 2 . Las ocurrencias de variables de dominio en 1 ! 2 son libres
o ligadas segun esten en 1 y 2 .
5. Si es una WFF y x es una variable de dominio que aparece como libre en , entonces,
9x( ) y 8x( ), son tambien WFF siendo las ocurrencias de x ligadas en esas dos ultimas
WFF. La formula 9x( ) sostiene que existe un valor de x tal que cuando sustituimos
este valor en todas las ocurrencias libres de x en , la formula se hace cierta. La
formula 8x( ) sostiene que para cualquier valor de x, si sustituimos ese valor en todas
las ocurrencias libres de x en , la formula se hace cierta.
6. Si es una WFF, tambien lo es ( ).
7. Nada mas es una WFF.
Los parentesis pueden situarse cuando sean necesarios para alterar la precedencia de los
operadores o para aclarar el orden de evaluacion de estos. Normalmente se supone que el orden
de precedencia es el siguiente: A tomos, cuanti cadores (9 y 8), negacion (:), conjuncion (^),
disyuncion (_) e implicacion (!), en ese orden. Igualmente, se pueden introducir tambien
otros operadores logicos como XOR (eXclusive OR), NOR (NOT OR), NAND (NOT AND)...
Ejemplo 1.1 Sea R una relacion con los alumnos de una determinada asignatura y su nota.
La consulta \dame los nombres de los alumnos que han obtenido una nota superior a 7", se
resolvera, en calculo de tuplas con la siguiente expresion:
ft(1) j 9u(R(u) ^ u:nota > 7 ^ u:nombre = t:nombreg
tu
1.2. MODELO RELACIONAL DE BASES DE DATOS 15

Los operadores del A lgebra Relacional pueden ser tambien expresados en Calculo Rela-
cional. Por ejemplo, los operadores primitivos del algebra seran expresados de la siguiente
forma en Calculo Relacional:
Ejemplo 1.2 La union de R y S se expresa en Calculo por la siguiente expresion:
ft j R(t) _ S (t)g
tu
Ejemplo 1.3 La interseccion de R y S se expresa en Calculo por la siguiente expresion:
ft j R(t) ^ S (t)g
tu
Ejemplo 1.4 La diferencia R S se expresa en Calculo por:
ft j R(t) ^ :S (t)g
tu
Ejemplo 1.5 La seleccion F (R) se expresa en Calculo por:
ft j R(t) ^ F 0g
donde F 0 es la misma formula F con cada atributo i, denotando la i-esima componente,
reemplazado por t[i]. tu
Ejemplo 1.6 El producto cartesiano de R y S , teniendo estas relaciones grados r y s res-
pectivamente, se expresa en Calculo por:
ft(r+s) j 9u(r); v(s) (R(u) ^ S (v)
^t[1] = u[1] ^ : : : ^ t[r] = u[r]
^t[r + 1] = v[1] ^ : : : ^ t[r + s] = v[s]g
Observe que igualamos los atributos de la tupla t con los de las tuplas u y v que existen en
R y S respectivamente. tu
Ejemplo 1.7 La proyeccion i1 ;:::;i (R) sobre n atributos de R se expresa en Calculo por:
n

ft(n) j 9u(R(u) ^ t[1] = u[i1 ] ^ : : : ^ t[n] = u[in ]g


tu
El Calculo Relacional Orientado a Dominios utiliza variables de dominio en vez de
variables tupla y esto hace que sea mas explcito, al manejar cada atributo independiente-
mente. Una expresion en Calculo de dominios tiene el siguiente formato:

fx1 ; x2; : : : ; xn j (x1 ; x2 ; : : : ; xn)g


Las principales diferencias con el Calculo de Tuplas son:
16 CAPITULO 1. INTRODUCCION:
 BASES DE DATOS Y CONJUNTOS DIFUSOS

1. Usa variables de dominio, en vez de variables de tupla. Una variable de dominio es


como los valores t[i] usados en el Calculo de tuplas. As, en la expresion, antes de la
formula hay que especi car todas las variables de dominio que deseamos recuperar (los
xi ).
2. En los atomos de pertenencia hay que utilizar tantas variables de dominio como atributos
tenga la relacion.
3. En los atomos de comparacion x e y son constantes o variables de dominio.
4. Tras los cuanti cadores (9 y 8), hay que indicar la variable de dominio que esta ligada.
5. El usuario percibe la base de datos como un conjunto de entidades (atributos) que estan
relacionados a traves de las relaciones. En cambio, en el calculo de tuplas las entidades
son las relaciones, las cuales tienen distintos atributos. Por eso el calculo de dominios
esta mas cerca del lenguaje natural.
En el Captulo 4 veremos mas detalles sobre el Calculo Relacional, en especial el de
Dominios, aplicado a BDRD y se explicara el concepto de expresiones \seguras" (\safe ") del
calculo relacional.
1.2.5 El Lenguaje SQL
El lenguaje SEQUEL (Structured English QUEry Language) fue desarrollado por Chamberlin
et al. [37, 38] en la segunda mitad de los a~nos 70 para manejar el modelo relacional de Codd
[41]. Con el tiempo este lenguaje llego a conocerse como SQL (Structured Query Language).
En 1979, Relational Software, Inc. (actualmente Oracle Corporation) introdujo el primer
sistema comercial que usaba SQL. Hoy da, SQL es el lenguaje aceptado como estandar para
los SGBDR y la bibliografa sobre el lenguaje SQL es muy extensa [26, 52, 86] y en todos se
explican los comandos basicos de este lenguaje en sus dos vertientes:
 DML (Data Manipulation Language, Lenguaje de Manipulacion de Datos): Las sen-
tencias de este lenguaje permiten la consulta y la modi cacion de los datos almacenados
en la base de datos. Ejemplos de comandos del DML SQL son: SELECT, INSERT, DELETE
y UPDATE que seran brevemente explicados a continuacion.
 DDL (Data De nition Language, Lenguaje de De nicion de Datos): Las sentencias
de este lenguaje permiten la creacion y modi cacion de las estructuras en las que se
almacenaran los datos. Ejemplos de comandos del DDL SQL son: CREATE (para crear
objetos de la base de datos: tablas, vistas...), DROP (para borrar objetos), ALTER (para
modi car objetos), y sentencias para controles de seguridad, ndices y control del al-
macenamiento fsico de los datos. Los objetos pueden ser, por ejemplo, tablas (objeto
TABLE), vistas (objeto VIEW) ndices (objeto INDEX), usuarios (objeto USER), sinonimos
(objeto SYNONYM)... Al nal de este apartado resumiremos el comando CREATE TABLE.
A continuacion vamos a resumir la sintaxis de los comandos mas importantes del DML y
del DDL de SQL2.
2 Se
ha utilizado el SQL de Oracle, que puede tener algunas diferencias con respecto al SQL estandar
dependiente de la ANSI/ISO.
1.2. MODELO RELACIONAL DE BASES DE DATOS 17

1.2.5.1 Comando SELECT


El comando mas importante es, quizas, el de consulta, ya que nos debe permitir expresar una
gran cantidad de tipos de consultas, que pueden involucrar multitud de expresiones y objetos
diferentes (tablas, vistas, comparadores, subconsultas, modos de ordenacion y agrupamien-
to...).
El comando SELECT de SQL tiene el siguiente formato basico3 :
SELECT <lista de selecci
on>
FROM <lista de tablas>
[WHERE <condici
on>]
[<otras cl
ausulas>]

donde
<lista de selecci
on> es una lista de expresiones, separadas por comas, que incluyen todo
lo que deseamos que aparezca en la relacion resultante de nuestra consulta. Como
expresiones pueden emplearse los nombres de atributos de alguna tabla, constantes,
operaciones aritmeticas, funciones...
<lista de tablas> es una lista con todas las tablas, separadas por comas, que intervienen
en la consulta. Aqu deben aparecer las tablas de los atributos que sean usados en el
resto de la sentencia.
<condicion> es una condici on que puede incluir atributos de una relacion, constantes de
cualquier dominio, comparadores aritmeticos (>, , <, , = y 6=), otros comparadores
(LIKE, IN, IS y BETWEEN), llamadas a funciones y operadores logicos (NOT, AND y OR).
La relacion resultante incorporara todas las tuplas que cumplan esta condicion.
<otras cl
ausulas> es una lista de clausulas opcional. Entre estas clausulas, las mas impor-
tantes son:
ORDER BY <expresiones o posiciones> [ASC|DESC] para ordenar la consulta por
los campos de la misma que se indiquen a continuacion, indicando la expresion
por la que ordenar o el numero de atributo de la <lista de seleccion>. Esta
ordenacion puede ser ascendente (ASC, valor por defecto) o descendente (DESC).
GROUP BY <lista de expresiones> [HAVING <condici on>] para agrupar las tuplas
resultantes segun el valor de la lista de expresiones que se indica y devolviendo una
unica la de datos para el grupo con informacion sobre el grupo en general. Con la
clausula HAVING se puede establecer una condicion sobre los grupos, recuperando
solo aquellos grupos que cumplan esa condicion.
Esta clausula se puede usar si se usan Funciones de Grupo (Group Functions ),
como las mostradas en la Tabla 1.2. Las funciones de grupo son aquellas funciones
que se aplican a un grupo nito de valores, de un determinado grupo, dando como
resultado un unico valor. Si no se usa la clausula GROUP BY con funciones de grupo,
entonces se supone un unico grupo formado por todas las tuplas que cumplen la
condicion. Ver Ejemplos 1.9 y 1.10.
3 Entre corchetes indicamos las clausulas que son opcionales.
18 CAPITULO 1. INTRODUCCION:
 BASES DE DATOS Y CONJUNTOS DIFUSOS

Funcion Utilidad
COUNT Cuenta el numero de elementos del grupo.
SUM Suma de la expresion en el grupo.
AVG Calcula la media de la expresion en el grupo.
MAX Valor maximo del grupo.
MIN Valor mnimo del grupo.
STDDEV Calcula la desviacion tpica en el grupo, para la expresion.
VARIANCE Calcula la varianza en el grupo, para la expresion.
Todas las funciones de grupo tienen un argumento en el que hay que
especi car un atributo o una expresion, sobre la que actuara la funcion.
Tabla 1.2: Funciones de Grupo utilizables en la sentencia SELECT.

As pues, en una consulta con la clausula GROUP BY, todos los elementos expresa-
dos despues de la palabra SELECT deben ser elementos de la clausula GROUP BY,
elementos conteniendo funciones de grupo, o constantes.
START WITH y CONNECT BY se utilizan para devolver las en orden jer arquico.
Varias sentencias SELECT pueden ser concatenadas usando operadores de conjuntos: UNION
para la union sin duplicados, UNION ALL para la union con duplicados, INTERSECT para la
interseccion y MINUS para la diferencia o resta.
Se pueden utilizar subconsultas dentro de <lista de tablas> como si estas fueran tablas
y se pueden utilizar condiciones especiales como:
[NOT] EXISTS <subconsulta> que, sin el NOT, toma el valor verdad si la subconsulta recu-
pera alguna tupla y falso en caso contrario.
<expr> [NOT] IN <subconsulta> que, sin el NOT, toma el valor verdad si la expresi on esta
incluida en el resultado de la subconsulta y falso en caso contrario.
<expr1> [NOT] BETWEEN <expr2> AND <expr3> que, sin el NOT, toma el valor verdad si la
expresion <expr1> esta entre las otras dos.
<expr1> [NOT] LIKE <expr2> que, sin el NOT, toma el valor verdad si la primera expresion,
de tipo cadena de caracteres, cumple el patron especi cado en la segunda expresion.
<expr> IS [NOT] NULL que, sin el NOT, toma el valor verdad si la expresion toma el valor
Nulo.
Ademas, se pueden tambien utilizar subconsultas que recuperen un unico valor como si
fueran una expresion. Tambien permite establecer nombres de alias en tablas y atributos para
enlazar tablas entre distintas partes de las subconsultas.
Todo ello, y mucho mas, hace que el comando SELECT de SQL sea un comando tremenda-
mente potente y exible, muy simple de utilizar en consultas no muy complicadas y no tan
simple en consultas complejas.
Ejemplo 1.8 Seleccionar aquellos Clientes y su Salario que tienen un salario mayor que
100000:
1.2. MODELO RELACIONAL DE BASES DE DATOS 19

SELECT Nombre, Salario


FROM Empleados
WHERE Salario > 10000;
tu
Ejemplo 1.9 Seleccionar aquellos Clientes y su Salario que tiene una letra 'X' en el nombre
y que tienen un salario mayor que la media, ordenando la salida por el salario:
SELECT Nombre, Salario
FROM Empleados
WHERE Nombre LIKE '%X%'
AND Salario > (SELECT AVG(Salario)
FROM Empleados)
ORDER BY Salario;
Observe la subconsulta y los caracteres comodn (%) de la condicion LIKE. tu
Ejemplo 1.10 Seleccionar los Clientes, su Salario y su Departamento, que tienen un salario
mayor que la media de su Departamento, ordenando la salida por el Departamento:
SELECT Nombre, Salario, Dpto
FROM Empleados E
WHERE Salario > (SELECT AVG(Salario)
FROM Empleados
WHERE E.Dpto = Dpto)
ORDER BY 3;
Observe el alias E, que es utilizado en la subconsulta para hacer referencia al Dpto del SELECT
mas externo. El 3 hace referencia a que se ordene (ascendentemente) por el tercer argumento
de la lista de seleccion, esto es, por Dpto. tu
1.2.5.2 Comando INSERT
El comando INSERT sirve para introducir nuevos datos en la base de datos y tiene el siguiente
formato general:
INSERT INTO <tabla>
[ (<lista de atributos>) ]
VALUES (<lista de expresiones>)

donde
<tabla> Es la tabla (vista o subconsulta) donde se desea insertar una tupla.
(<lista de atributos>) es una lista de atributos entre par entesis y separados por comas
que indican el orden de las expresiones siguientes. Esta lista es opcional y si no aparece
se toma la lista de atributos de <tabla> en el orden en el que se usaron en su creacion.
(<lista de expresiones>) es una lista de expresiones entre par entesis y separados por
comas que expresan los valores que deseamos insertar en los correspondientes atributos.
Esta lista y la palabra VALUES pueden sustituirse por una subconsulta que contendra
los datos que seran insertados. Usando una subconsulta pueden insertarse varias tuplas
a la vez.
20 CAPITULO 1. INTRODUCCION:
 BASES DE DATOS Y CONJUNTOS DIFUSOS

1.2.5.3 Comando DELETE


El comando DELETE sirve para borrar datos (tuplas) en la base de datos y tiene el siguiente
formato general:
DELETE <tabla>
WHERE <condicion>

que borra las tuplas de <tabla> que cumplen la condicion que se indica.
1.2.5.4 Comando UPDATE
El comando UPDATE sirve para actualizar valores de datos antiguos en la base de datos y tiene
el siguiente formato general:
UPDATE <tabla>
SET <asignaci
on>
[WHERE <condicion>]

donde
<tabla> Es la tabla (vista o subconsulta) donde se desean actualizar datos.
<asignacion> es una asignaci on con los siguientes dos formatos posibles para actualizacion
de un unico atributo o varios de ellos respectivamente:
<atributo> = <expr> que expresa que se actualiza el atributo a la expresi on que se
indican.
(<lista de atributos> = <subconsulta> que expresa que se actualizan todos los
atributos de la lista con los datos de la subconsulta (que debe ser con igual numero
y tipo de atributos).
WHERE <condicion> es una cl ausula opcional que indica la condicion que deben cumplir las
tuplas de <tabla> para ser actualizadas con los datos indicados.
1.2.5.5 Comando CREATE TABLE

El comando CREATE TABLE sirve para crear tablas en la base de datos especi cando el nombre
de la tabla, los atributos, sus dominios, restricciones... Es similar a la sentencia ALTER TABLE
y tiene el siguiente formato general:
CREATE TABLE <tabla>
[( <definici
on de columnas y restricciones> )]
[<otras cl
ausulas>]

donde
<tabla> Es el nombre que tendra la tabla que se desea crear.
<definicion de columnas y restricciones> Es una lista separada por comas de de ni-
ciones de columnas y/o restricciones de tabla, que se explicaran a continuacion.
1.2. MODELO RELACIONAL DE BASES DE DATOS 21

<otras cl
ausulas> permite especi car algunas caractersticas de la tabla, como el maximo
numero de transacciones concurrentes que pueden actualizar el bloque de datos de la
tabla, el lugar fsico de almacenamiento, cluster al que pertenece, el grado de paralelismo
al crear la tabla, si habilita o no la restriccion de integridad, inserta los valores iniciales
de una subconsulta tras la creacion de la tabla...
La de nicion de columnas y restricciones pueden ir mezcladas con las restricciones de
tabla. Dentro de la de nicion de columnas se pueden incluir las restricciones de columna.
La De nicion de una columna se hace simplemente indicando el nombre de la columna
y el tipo de datos que almacenan (su dominio). En el apartado 1.2.6.1 daremos un resumen
de los tipos de datos de Oracle. Tras esto se pueden a~nadir, opcionalmente, dos clausulas. Si
se a~naden ambas, debe hacerse en este orden:
DEFAULT <expr> para establecer un valor por defecto para la columna actual. Ese valor sera
el que se asigne a ese atributo si en una sentencia INSERT se omite el valor para dicha
columna.
<restricci
on de columna> que indica un requisito que deben cumplir todos los valores
insertados en este atributo.
La imposicion de restricciones se efectua poniendo el tipo de restriccion, de entre los
siguientes:
 NOT NULL: Impone que una columna no contenga valores NULL. Esta restricci
on, como
hemos apuntado anteriormente, supone el soporte para la Regla de Identidad. Esta
restriccion no puede ser de tabla.
 NULL: Indica que una columna puede contener valores NULL.
 UNIQUE: Impone que una columna o grupo de ellas sean unicas dentro de la tabla.
 PRIMARY KEY: Identi ca a una o varias columnas como Clave Primaria. Si es restriccion
de tabla, hay que especi car despues, entre parentesis, la lista de columnas que forman
la Clave primaria.
 FOREIGN KEY: Identi ca a una o varias columnas como Clave Externa y fuerza a que exis-
tan en alguna tabla las columnas o grupos de ellas que constituyan dicha clave, forzando
el cumplimiento de la Regla de Integridad Referencial. Con la clausula REFERENCES se
puede indicar la clave candidata que es referenciada por una clave externa y con la op-
cion ON DELETE CASCADE especi ca que se mantenga la regla de integridad referencial,
borrando las tuplas con las llaves externas si se borra su correspondiente llave candidata
en la otra relacion.
 on>):
CHECK (<condici Esto habilita la posibilidad de imponer una determinada con-
dicion sobre uno o varios atributos. Esto permite, por ejemplo, restringir los valores de
dominio que pueden ser adoptados por una columna o grupo de ellas. Con esta restric-
cion se pretende especi car, en forma precisa, el dominio que subyace a un atributo o
columna.
22 CAPITULO 1. INTRODUCCION:
 BASES DE DATOS Y CONJUNTOS DIFUSOS

Todas las restricciones pueden ser etiquetadas con un nombre utilizando la clausula
CONSTRAINT seguida del nombre que se le quiere dar. As, cuando esta restriccion se vulnere,
el nombre de la restriccion gurara en el mensaje de error que genere el SGBD, facilitando al
usuario la comprension del mensaje y la solucion del problema.
Ejemplo 1.11 Observe la siguiente sentencia de creacion de una tabla:
CREATE TABLE PISOS (
PISO# NUMBER(9) NOT NULL PRIMARY KEY,
DUENNO# NUMBER(9) NOT NULL
CONSTRAINT DUENNO#_NO_VALIDO REFERENCES CLIENTES(CLIENTE#),
DIRECCION VARCHAR2(60),
SUPERFICIE NUMBER(9,1)
CONSTRAINT NULL_INVALIDO_SUPERFICIE NOT NULL,
PRECIO NUMBER(6)
CONSTRAINT NULL_INVALIDO_PRECIO NOT NULL,
ZONA VARCHAR2(9) DEFAULT 'CENTRO'
CONSTRAINT ZONA_NO_VALIDA CHECK
(ZONA IN ('CENTRO','NORTE','SUR','ESTE','OESTE')));

En ella se crea una tabla con 6 atributos, cuya clave primaria es PISO#. El atributo
DUENNO# es clave externa, por lo que antes de crear esta tabla debe existir la tabla CLIENTES
con el atributo CLIENTE# como clave primaria y que estos atributos sean de tipos compatibles.
tu
1.2.6 El SGBDR Oracle
Como ejemplo de SGBDR comercial vamos a comentar algunos aspectos del gestor de bases
de datos ORACLE de Oracle Corporation [117], que fue el primer fabricante en introducir
un producto relacional en el mercado, adelantandose a la propia IBM en casi 2 a~nos, y fue
tambien el primero en sacar un producto que usase SQL. Actualmente es el mayor vendedor
de SGBDR independiente.
Oracle esta implementado en cerca de 100 plataformas distintas incluyendo MS-DOS,
Windows, OS/2, Macintosh, Sun, MIPS y muchas otras basadas en sistemas Unix, como
Linux. Oracle siempre ha sido el SGBDR con mejores tiempos de ejecucion, siendo, por
meritos propios, el lder en ejecucion OLTP.
Como DML y DDL, Oracle utiliza SQL [26, 52, 86]. Pero ademas, Oracle incorpora un
lenguaje procedural, el PL/SQL [82, 118, 146], que es una extension de SQL y que permi-
te crear procedimientos y funciones almacenadas en el SGBD. Los paquetes PL/SQL son
conjuntos de funciones y/o procedimientos.
Oracle dispone de acceso a traves de ODBC y multitud de aplicaciones para los mas
diversos nes SQL*Net, SQL*Plus, Developer 2000...
Aqu resumiremos algunos aspectos relacionados con Oracle, ya que es el SGBD empleado
para la implementacion que se explica en el Captulo 5. Aunque Oracle ha sacado recientemen-
te su version 8 [2, 4], la implementacion ha sido programada en la version 7.3 [17, 82, 99, 116],
sin que se usen elementos que puedan no funcionar en versiones posteriores.
Las novedades mas relevantes de Oracle 8 son que se presenta como una base de datos
objeto-relacional, el particionamiento de tablas (pudiendo bloquear exclusivamente una parte
1.2. MODELO RELACIONAL DE BASES DE DATOS 23

de una tabla), aumento de rendimiento en aplicaciones de Data Warehouse, mejora de procesos


internos como el paralelismo o el procesamiento de transacciones on-line, nuevas herramientas
de administracion (Enterprise Manager) y asistentes para diversas operaciones utiles, como
la creacion automatica de una base de datos casi sin intervencion del usuario y la posibilidad
de importar bases de datos de otras aplicaciones (como de Microsoft Access) o de versiones
anteriores de Oracle. Ademas la inminente aparicion de la version Oracle 8i abre aun mas las
posibilidades incorporando la tecnologa iFS (Internet File System) para ver la informacion
de la base de datos como si fueran archivos y directorios contenidos en un disco, accesible de
igual modo con clientes HTTP, FTP, IMAP, POP o SMTP o con el mismo que accedamos a
los cheros convencionales. Ademas, Oracle 8i incorpora una maquina virtual Java y permite
la programacion tanto en PL/SQL como en Java de cualquier objeto, incluyendo triggers
(disparadores). Tambien incluye la sintaxis SQLJ para incluir codigo SQL en el codigo Java.
Junto a todo lo ya apuntado, la posibilidad de extender las capacidades del servidor
Oracle a traves de los llamados cartuchos de datos, Data Cartridges, hacen que el SGBD
Oracle este en primera la en cuanto a potencia, exibilidad, e ciencia y adaptacion a las
nuevas tecnologas (Internet, WWW...).
1.2.6.1 Estructuras y Tipos de Datos
Como en cualquier base de datos relacional, los datos se organizan a traves de tablas y en
general de acuerdo con el modelo relacional. Las cabeceras de atributo, que en Oracle se
denominan columnas (columns ), no presentan un orden de acuerdo con el modelo relacional
y respondiendo a la nocion de conjunto que subyace a estas. Las columnas pueden estar
de nidas sobre los tipos de dominio o tipos de datos que a continuacion se relacionan:
 Caracter: Una columna de nida sobre un dominio de este tipo, debera especi car la
longitud maxima de la cadena de caracteres que podra contener. La longitud maxima
para una columna de nida sobre este dominio dependera del tipo de la columna, os-
cilando entre los 255 caracteres de maximo para el tipo CHAR, los 2000 para el tipo
VARCHAR2 y los 231 1 bytes del tipo LONG.

 Numerico: Los diferentes dominios numericos soportados por Oracle son subconjuntos
de los enteros y los reales. Todos ellos pueden ser representados a traves del tipo
NUMBER(p,s), donde los parametros p (precision) y s (escala) indican, respectivamente,
el numero maximo de dgitos (de 1 a 38) y el numero de cifras decimales (de {84 a
127) que puede contener el atributo. Si no se especi ca el valor de s, se supone que es
cero. Existen otras expresiones sintacticas de tipo aceptadas pero todas ellas pueden
encontrar una expresion equivalente mediante el tipo NUMBER, como son: INTEGER y
FLOAT, entre otros.

 Fecha y Hora: Oracle permite representar fechas en diferentes formatos para un rango
comprendido entre el 1 de Enero del a~no 4712 A.C. y el 31 de Diciembre del 4712 D.C.
El tipo que opera sobre este dominio es el tipo DATE y cada valor de este tipo almacena:
El siglo, a~no, mes, da, hora, minuto y segundo. La funcion TO_CHAR permite convertir
este tipo de dato a cadena de caracteres en diversos formatos.
 Binario: A traves de los datos de nidos sobre este dominio se pueden representar cual-
quier tipo de informacion mediante una representacion binaria, como una coleccion de
24 CAPITULO 1. INTRODUCCION:
 BASES DE DATOS Y CONJUNTOS DIFUSOS

bytes, sin que Oracle les atribuya signi cado alguno. As, pueden almacenarse gra cos,
sonidos, documentos y su interpretacion no depende de Oracle. Los tipos que sustentan
este dominio son el RAW para un tama~no maximo de 255 bytes y el LONG RAW para una
longitud superior a los 2 GigaBytes.
 Identi cador de la: Oracle identi ca mediante un codigo cada uno de los registros
de la base de datos. El tipo ROWID se re ere a un dominio que contiene todos los valores
que puede adoptar esta codi cacion.
Es posible la creacion de vistas como representacion logica de una tabla o un conjunto
de tablas. O sea, una vista es una consulta particular sobre la base de datos, la cual tiene un
nombre propio. Sin embargo, las vistas, aunque no presentan problemas en consulta, pueden
plantearlos en la actualizacion de las mismas, al resultar imposible en algunas ocasiones
reconstruir la informacion a actualizar en las tablas base sobre las que se construyen.
Para todos los dominios existe un valor denominado NULL que signi ca que, o no se conoce
el valor o no es aplicable4. Oracle proporciona un tratamiento espec co para este tipo de
valores, utilizando una logica tri-valuada, pues cualquier comparacion con valores NULL no
es resuelta ni como verdadera ni como falsa. En el apartado 2.1.1 se explica esta logica
tri-valuada.
Todas las columnas pueden contener el valor NULL en alguna tupla, excepto aquellas en
las que en se establecio la restriccion NOT NULL (NULL no permitido) o PRIMARY KEY (Clave
primaria).
Cuando se emplea el valor NULL en una condicion simple, esta se evalua como UNK-
NOWN (desconocido), que es similar a FALSE (falso). La diferencia esta en que si operamos
con UNKNOWN siempre obtenemos UNKNOWN. As, por ejemplo, NOT UNKNOWN vale
UNKNOWN, mientras que NOT FALSE vale TRUE (verdad).
Como se explico en el apartado 1.2.5.1 pueden emplearse condiciones especiales con LIKE,
IN, IS y BETWEEN.
Otros elementos estructurales proporcionados por Oracle son:
 Indices: Facilitan, de forma transparente al usuario, un rapido acceso a las tuplas de
una tabla y pueden forzar la unicidad de las mismas.
 Agrupaciones (clusters): Pueden ayudar al sistema a almacenar fsicamente juntas
estructuras de datos a las que se accede conjuntamente con frecuencia, aunque perte-
nezcan a tablas distintas. Al igual que los ndices, su empleo es transparente al usuario
y es el optimizador el que se encarga de usarlos para mejorar la e ciencia del sistema.
 Procedimientos almacenados: Son fragmentos de codigo en lenguaje PL/SQL y
pueden ser de 4 tipos:
1. Funciones (FUNCTION): Fragmento de codigo cuya llamada devuelve un valor.
Pueden tener argumentos.
2. Procedimientos (PROCEDURE): Fragmento de codigo cuya llamada no devuelve
un valor. Pueden tener argumentos y pueden devolver valores usando paso de
parametros por variable (OUT).
4 El
primer intento de representar informacion inexacta fue precisamente la introduccion del concepto de
valor nulo, NULL, y fue publicado por Codd en [43] (ver apartado 2.1.1).
1.3. TEORIA DE CONJUNTOS DIFUSOS 25

3. Paquetes : Son conjuntos de funciones y procedimientos que pueden ser expor-


tados para poder usarse desde fuera o internos para que solo puedan ser utiliza-
dos desde dentro del paquete. Cada paquete tiene dos partes: La especi cacion
(PACKAGE), con las declaraciones publicas visibles desde fuera del paquete, y el
cuerpo (PACKAGE BODY), con las declaraciones privadas que solo son visibles desde
dentro del paquete.
4. Disparadores (TRIGGER): Un trigger es un fragmento de codigo asociado a una
tabla que se ejecuta cuando se efectua alguna determinada accion sobre dicha tabla,
como insertar datos, borrar datos, actualizar datos... Los disparadores son muy
importantes para mantener la integridad de los datos, ya que pueden evitar insertar
datos inconsistentes, erroneos o que no cumplen determinadas condiciones.

1.2.6.2 Integridad de los Datos


Oracle fuerza la Regla de Identidad mediante el uso de la restriccion NOT NULL en la creacion
y modi cacion de las tablas. (sentencias CREATE TABLE y ALTER TABLE respectivamente).
Como hemos dicho, la Regla de Integridad Referencial esta soportada por Oracle a traves de
la restriccion FOREIGN KEY en la creacion y modi cacion de las tablas.
Ademas, dispone de un conjunto de restricciones para mantener la integridad de la base
de datos que se pueden aplicar a las sentencias de creacion y modi cacion de tablas. Dichas
restricciones se pueden imponer a una columna (restriccion de columna) o a un grupo de ellas
(restriccion de tabla) y determinan, que las operaciones que se realicen sobre las mismas,
satisfagan algunas condiciones. Estas restricciones fueron de nidas en el apartado 1.2.5.5.

1.3 Teora de Conjuntos Difusos


Vamos a dedicar este apartado a introducir algunas nociones elementales sobre la teora de
conjuntos difusos (fuzzy sets ), as como la notacion utilizada al respecto a lo largo de esta
memoria. En este resumen nos detendremos en los aspectos semanticos y de representacion
relacionados con esta potente herramienta teorica. En la literatura podemos encontrar una
gran cantidad de trabajos sobre esta teora, que fue introducida por primera vez por L.A.
Zadeh5 en 1965, en su trabajo [165]. En [159] podemos encontrar una recopilacion de algunos
de los artculos mas interesantes publicados sobre el tema por L.A. Zadeh. En [57], [61] y
[172] es posible encontrar recopilados los aspectos mas importantes que constituyen la teora
de conjuntos difusos as como la teora de la posibilidad.
Una mas moderna sntesis de los conjuntos difusos y sus aplicaciones puede verse en
[93, 101, 111] y sobre todo en [123].

1.3.1 Conjuntos Difusos


La interpretacion original de conjunto difuso proviene de una generalizacion del concepto
clasico de subconjunto ampliado a la descripcion de nociones \vagas" e \imprecisas". Esta
generalizacion se realiza como sigue:
5 L.A. Zadeh fue nombrado doctor honoris causa por la Universidad de Granada en 1996, por su valiosa
aportacion en este campo de la ciencia.
26 CAPITULO 1. INTRODUCCION:
 BASES DE DATOS Y CONJUNTOS DIFUSOS

1. La pertenencia de un elemento a un conjunto pasa a ser un concepto \difuso" o \bo-


rroso". Para algunos elementos puede no estar clara su pertenencia o no al conjunto.
2. Dicha pertenencia puede ser cuanti cada por un grado. Dicho grado se denomina ha-
bitualmente como \grado de pertenencia" de dicho elemento al conjunto y toma un
valor en el intervalo [0; 1] por convenio.
Mediante esta herramienta podemos representar de forma adecuada conceptos \impreci-
sos". Es necesario hacer notar que muchos de estos conceptos con naturaleza \imprecisa", si
no todos, responden a criterios subjetivos. Esto es, la de nicion de esa imprecision depende
en mayor o menor medida de la persona que la expresa.
De forma mas precisa podemos introducir la de nicion de conjunto difuso como sigue:
De nicion 1.9 Un Conjunto Difuso Ae sobre un universo de discurso
es un conjunto
de pares
Ae = fA(x)=x : x 2
; A (x) 2 [0; 1]g (1.5)
donde A (x) se denomina grado de pertenencia del elemento x al conjunto difuso Ae. Este
grado oscila entre los extremos 0 y 1:
A (x) =0 indica que x no pertenece en absoluto al conjunto difuso Ae.
A (x) =1 indica que x pertenece totalmente al conjunto difuso Ae.
A veces, en vez de dar una lista exhaustiva de todos los pares que forman el conjunto,
se da una de nicion para la funcion A (x), llamada funcion caracterstica o funcion de
pertenencia. tu
Si la funcion de pertenencia solo produce valores del conjunto f0,1g, entonces, el conjunto
que genera no es difuso, sino \crisp".
Ejemplo 1.12 Si consideramos que la \edad" (en a~nos enteros) es el universo de discurso de
\joven", el conjunto difuso que representa dicho concepto podra expresarse en la forma:
joven = f1=20; 1=25; 0:9=26; 0:8=27; 0:7=28; 0:6=29; 0:5=30; : : : ; 0:1=34g
El identi cador \joven" con la connotacion de que lleva asociado un conjunto difuso recibe
la denominacion de \etiqueta lingustica". tu
De nicion 1.10 Llamaremos Etiqueta Lingustica a aquella palabra, en lenguaje natural,
que exprese un conjunto difuso, que puede estar formalmente de nido o no. tu
Con esta de nicion, podemos asegurar que en nuestra vida cotidiana utilizamos multitud
de etiquetas lingusticas: \joven", \viejo", \fro", \caliente", \templado", \barato", \caro",
\bajo", \alto", \grande", \peque~no"...
Ademas, la de nicion intuitiva de esas etiquetas, no solo puede variar de un individuo a
otro y del momento particular, sino que tambien vara del contexto en el que se aplique. Por
ejemplo, seguramente no mediran la misma altura una persona \alta" y un edi cio \alto".
La representacion de conjuntos difusos puede ser variada y depende, fundamentalmente
de la naturaleza del universo de discurso sobre el que de namos el conjunto difuso.
1.3. TEORIA DE CONJUNTOS DIFUSOS 27

 Dado un universo de discurso nito



= fx1 ; x2 ; : : : ; xn g
un conjunto difuso Ae se puede representar como
Ae = 1 =x1 + 2 =x2 + : : : + n=xn (1.6)
donde i representa el grado de pertenencia del elemento xi , con i = 1; 2; : : : ; n. Habi-
tualmente los elementos con grado cero no se listan. Aqu la suma no hace el papel de
la suma aritmetica sino que tiene el sentido de agregacion.
 Dado un universo de discurso in nito
, un conjunto difuso Ae sobre
se puede repre-
sentar como
Z
eA = Ae(x)=x; (1.7)
donde Ae(x) es el grado de pertenencia de x.
1.3.2 Conceptos sobre Conjuntos Difusos
Sobre conjuntos difusos se de nen una serie de conceptos que nos permiten tratar y comparar
conjuntos difusos:
 Igualdad de conjuntos difusos:
De nicion 1.11 Dos conjuntos difusos Ae y Be sobre
se dicen iguales si cumplen:
Ae = Be () 8x 2
; Ae(x) = Be (x) (1.8)
tu
 Inclusion de un conjunto difuso en otro:
De nicion 1.12 Dados dos conjuntos difusos Ae y Be sobre
, decimos que Ae esta
incluido en Be si cumplen:
Ae  Be () 8x 2
; Ae(x)  Be (x) (1.9)
tu
 Soporte de un conjunto difuso:
De nicion 1.13 El soporte (support) de un conjunto difuso Ae de nido sobre
es un
subconjunto de dicho universo que satisface:
supp(Ae) = fx 2
; Ae(x) > 0g (1.10)
tu
 -corte de un conjunto difuso:
28 CAPITULO 1. INTRODUCCION:
 BASES DE DATOS Y CONJUNTOS DIFUSOS

De nicion 1.14 Un -corte de un conjunto difuso Ae de nido sobre


, denotado por
Ae , es un subconjunto no difuso de elementos de
, cuya funcion de pertenencia toma
un valor mayor o igual que algun valor concreto : de dicho universo que satisface:
Ae = fx : x 2
; Ae(x)  g (1.11)
donde 2 [0; 1]. tu
 Nucleo de un conjunto difuso:
De nicion 1.15 El nucleo (kernel) de un conjunto difuso Ae de nido sobre
es un
subconjunto de dicho universo que satisface:
kern(Ae) = fx 2
; Ae(x) = 1g (1.12)
tu
 Altura de un conjunto difuso:
De nicion 1.16 La Altura (height) de un conjunto difuso Ae de nido sobre
se de ne
como:
hgt(Ae) = sup Ae(x) (1.13)
x2

tu
 Conjunto difuso normalizado:
De nicion 1.17 Un conjunto difuso Ae de nido sobre
se dice normalizado si y solo
si
9x 2
; Ae(x) = hgt(Ae) = 1 (1.14)
tu
1.3.3 Operaciones sobre Conjuntos Difusos
Las operaciones que inmediatamente se sugieren de la de nicion de conjunto difuso son la
union, la interseccion y el complemento. En [125] podemos encontrar estas y otras operaciones,
como la concentracion (elevar al cuadrado la funcion de pertenencia), la dilatacion (efectuar la
raz cuadrada de la funcion de pertenencia) y la intensi cacion, que pueden utilizarse cuando
se usan modi cadores lingusticos (linguistic hedges ) como \muy" o \poco".
1.3.3.1 Union e Interseccion
De nicion 1.18 Si Ae y Be son dos conjuntos difusos sobre un universo de discurso
, la
funcion de pertenencia de la union de ambos conjuntos, Ae [ Be , viene dada por
Ae[Be (x) = f (Ae(x); Be (x)); x 2
(1.15)
donde f es una T-conorma [134]. tu
1.3. TEORIA DE CONJUNTOS DIFUSOS 29

De nicion 1.19 Si Ae y Be son dos conjuntos difusos sobre un universo de discurso


, la
funcion de pertenencia de la interseccion de ambos conjuntos, Ae \ Be, viene dada por
Ae\Be (x) = g(Ae(x); Be (x)); x 2
(1.16)
donde g es una T-norma [134]. tu
Las de niciones anteriores no son unicas ya que existen varios operadores que satisfacen el
concepto de T-norma y de T-conorma, como las presentadas en [57, 156]. Los mas importantes
son:
 Operadores idempotentes: El maximo y el mnimo para la union y la interseccion res-
pectivamente. Satisfacen, ademas de la idempotencia, la propiedad distributiva aplicada
sobre ambos y son estrictamente crecientes. Estos operadores son los mas utilizados por-
que conservan gran cantidad de las propiedades de los operadores booleanos. En [14]
puede encontrarse una justi cacion a la eleccion de los operadores max y min para
de nir los anteriores conceptos.
 Operadores arquimedianos: Emplean la suma probabilstica, (x + y x  y), y el
producto, (x  y), para la union y la interseccion, respectivamente. Estos operadores
no satisfacen la propiedad distributiva ni son idempotentes.
 Operadores acotados (bounded ): Los operadores dados por, min(1; x + y) y max(0; x +
y 1), representan la union y la interseccion respectivamente. Estos operadores no
satisfacen la idempotencia, la propiedad distributiva ni la propiedad de absorcion. Por
contra, satisfacen las propiedades conmutativa, asociativa y de identidad.
1.3.3.2 Complemento
La nocion de complemento se puede construir a partir del concepto de negacion fuerte de E.
Trillas [140]:
De nicion 1.20 Una funcion C de [0,1] en [0,1] es una negacion fuerte si satisface las
siguientes condiciones:
1. C(0)=1
2. C(C(a))=a (involucion)
3. C es estrictamente decreciente
4. C es continua.
tu
Aunque existen varios tipos de operadores que satisfacen tales propiedades o versiones re-
lajadas de las mismas, nosotros, para el complemento, emplearemos principalmente la version
proporcionada por Zadeh en [165], en la cual:
C (x) = 1 x (1.17)
Por tanto, para un conjunto difuso Ae sobre un universo de discurso
, la funcion de
pertenencia del complemento de Ae, :Ae, viene dada por:
:Ae(x) = 1 Ae(x); x 2
(1.18)
30 CAPITULO 1. INTRODUCCION:
 BASES DE DATOS Y CONJUNTOS DIFUSOS

0

Figura 1.1: Numero difuso general: Entre y .

1.3.4 Numeros Difusos


El concepto de numero difuso fue introducido por primera vez en [167] con el proposito de ana-
lizar y manipular valores numericos aproximados. El concepto ha sido re nado sucesivamente
y en esta memoria entenderemos por numero difuso lo siguiente [59]:
De nicion 1.21 Sea A un subconjunto difuso de
y A su funcion de pertenencia cum-
pliendo:
1. 8x; y 2
; 8A (t)  minfA (x); A (y)g, es decir que es convexo.
2. A es semicontinua superiormente.
3. El soporte de A es un conjunto acotado.
entonces diremos que A es un numero difuso. tu
Algunos autores incluyen en la de nicion la necesidad de que el subconjunto difuso este
normalizado (De nicion 1.17).
La forma general de la funcion de pertenencia de un numero difuso A, es la siguiente:
8 r (x)
>
< hA si x 2 [ ; )
A (x) = > s (x) si x 2 [ ; ] (1.19)
: 0A si x 2 ( ; ]
en otro caso
donde rA ; sA :
! [0; 1], rM no decreciente, sM no creciente y

rA ( ) = h = sA ( )
con h 2 (0; 1] y ; ; ;  2
.
Al numero h se le denomina altura del numero difuso, al intervalo [ ; ] intervalo modal y
a los numeros y  holguras izquierda y derecha respectivamente. El numero difuso
de la Figura 1.1 es una representacion de \aproximadamente entre y ".
1.3. TEORIA DE CONJUNTOS DIFUSOS 31

0

Figura 1.2: Numero difuso trapezoidal normalizado.

A lo largo de esta memoria utilizaremos a menudo un caso particular de numeros difusos


que se obtienen cuando consideramos a las funciones rA y sA como funciones lineales. En este
caso la funcion de pertenencia adopta la forma:
8 (x )h
> si x 2 [ ; )
< hh +
> si x 2 [ ; ]
A(x) = > (1.20)
> h (x )h si x 2 ( ; ]
: 0 en otro caso
A un numero difuso de este tipo lo llamaremos triangular o trapezoidal . Usualmente
trabajaremos con numeros difusos normalizados por lo que h = 1, en este caso podremos carac-
terizar un numero difuso trapezoidal normalizado A, mediante el empleo de los 4 parametros
que son realmente imprescindibles:

A  ( ; ; ; )
La Figura 1.2 muestra una representacion gra ca de dicho numero.
1.3.4.1 El Principio de Extension
Este principio, propuesto en [167], proporciona un metodo general que permite extender
conceptos matematicos no difusos para el tratamiento de cantidades difusas. Se de ne como
sigue:
De nicion 1.22 Sea
un producto cartesiano de universos
=
1 
2  : : : 
n, y
Af1 ; Af2 ; : : : ; Afn , n conjuntos difusos de
1 ;
2 ; : : : ;
n respectivamente, f una funcion desde

al universo
0 , entonces un conjunto difuso Be de
0 viene de nido por:
Z
Be =  e (y)=y

0 B
donde y = f (x1 ; x2 ; : : : ; xn ) (y 2
0), y
32 CAPITULO 1. INTRODUCCION:
 BASES DE DATOS Y CONJUNTOS DIFUSOS

 max min
Be (y) = (x1 ;x2 ;::: ;xn)2f 1 (y) fAf1 (x1 ); : : : ; Afn (xn )g; f 1(y) 6= 0
0; en otro caso
tu
1.3.4.2 Aritmetica Difusa
Gracias al Principio de Extension es facil extender las operaciones aritmeticas clasicas al
tratamiento de numeros difusos. De esta forma las cuatro operaciones principales quedan
extendidas como sigue:
 Suma Extendida: Dadas dos cantidades difusas A1 y A2 , la funcion de pertenencia
de la suma viene dada por la expresion:
A1A2 (y) = supfmin(A1 (y x); A2 (x))=x 2
g (1.21)
 Diferencia Extendida: Dadas dos cantidades difusas A1 y A2, la funcion de perte-
nencia de la suma viene dada por la expresion:
A1 A2 (y) = supfmin(A1 (y + x); A2 (x))=x 2
g (1.22)
De estas de niciones se puede obtener facilmente que el si A1 tiene n terminos y A2 tiene
m terminos, el numero de terminos de A1 + A2 y de A1 A2 es (n 1) + (m 1) + 1, o lo
que es lo mismo: n + m 1.
Ejemplo 1.13 Sean A1 y A2 dos cantidades difusas de nidas (con el formato de la De nicion
1.9 y la ecuacion 1.6) como:
A1 = 1=1 + 0:9=2 + 0:5=3
A2 = 1=2 + 0:8=3 + 0:3=4
entonces, aplicando el Principio de Extension obtenemos que:
A1 + A2 = 1=3 + 0:9=4 + 0:8=5 + 0:5=6 + 0:3=4
A1 A2 = 0:3= 3 + 0:8= 2 + 1= 1 + 0:9=0 + 0:5=1
Observe que se cumple que el numero de terminos de las operaciones es 3 + 3 1 = 5. tu
 Producto Extendido: El producto de dos cantidades difusas A1 A2 se obtiene:
 supfmin( (z=y);  (y))=y 2
f0gg si z 6= 0
A 1 A 2 ( z ) = A1 A2 (1.23)
max(A1 (0); A2 (0)) si z = 0
 Division Extendida: La division de dos cantidades difusas se de ne mediante:

A1 A2 (z) = supfmin(A1 (y:z); A2 (y))=y 2


g (1.24)
Basandose en una expresion particular del principio de incertidumbre adaptada al empleo
de cortes y en un tipo de numero difuso similar al descrito anteriormente, denominado
numero L R, en [57] se describen formulas de calculo rapido para las anteriores operaciones
aritmeticas.
1.3. TEORIA DE CONJUNTOS DIFUSOS 33

1.3.5 Teora de la Posibilidad


Esta teora se basa en la idea de variables lingusticas y como estas estan relacionadas con
los conjuntos difusos [168]. As, se puede evaluar la posibilidad de que una determinada
variable X sea o pertenezca a un determinado conjunto Ae, como el grado de pertenencia de
los elementos de X en Ae.
De nicion 1.23 Sea un conjunto difuso Ae de nido sobre
con su funcion de pertenencia
Ae(x) y una variable X sobre
(que desconocemos su valor). Entonces, la proposicion \X
es Ae" de ne una Distribucion de Posibilidad, de forma que se dice que la \posibilidad"
de que X = u vale Ae(u), para todo valor u 2
. tu
Como veremos, dos distribuciones de posibilidad pueden ser comparadas con distintos
comparadores. Los mas tpicos son la medida de posibilidad, \posiblemente igual", y la
medida de necesidad, \necesariamente igual" (ecuaciones 5.6 y 5.8 respectivamente).
34 CAPITULO 1. INTRODUCCION:
 BASES DE DATOS Y CONJUNTOS DIFUSOS
Captulo 2
Modelos de Bases de Datos
Relacionales Difusas: GEFRED
El problema de la representacion y el tratamiento de informacion \imprecisa" ha sido amplia-
mente estudiado y pueden encontrarse muchas referencias al respecto en la bibliografa. Sin
embargo, todos los modelos publicados para dar solucion a este problema tienen sus ventajas,
desventajas y sus limitaciones.
Ademas, el termino \imprecision" engloba varios signi cados que puede ser interesante
distinguir: Que la informacion que tenemos es incompleta, que no sabemos si es o no cierta
(incertidumbre), que desconocemos totalmente esa informacion (unknown) o que dicha infor-
macion no es aplicable a determinada entidad (unde ned). A veces estos signi cados no son
disyuntivos, sino que pueden unirse en una determinada informacion.
En este captulo se exponen los principales modelos publicados para dar solucion al pro-
blema de la representacion y el tratamiento de informacion imprecisa en bases de datos rela-
cionales. El problema no es trivial, ya que hay que modi car la estructura de las relaciones
y, con esto, las operaciones sobre estas. Para permitir almacenar informacion imprecisa y
consultar de forma imprecisa esta informacion se requiere el estudio de multitud de casos
particulares que no ocurren en el modelo clasico, sin imprecision.
Entre los modelos que se exponen estan: distintas aproximaciones sin utilizar la logica
difusa (como la aproximacion \clasica" de Codd [43, 44, 46, 47]), el modelo de Prade-Testemale
[127, 128, 129, 130], el modelo de Umano-Fukami [70, 142, 143, 144, 145], el modelo de Buckles-
Petry [28, 29, 30, 32], el modelo de Zemankova-Kaendel [170, 171] y el modelo GEFRED de
Medina-Pons-Vila [102, 103, 72, 79].
Existen otros modelos para el tratamiento de la incertidumbre en bases de datos, pero
que no han tenido demasiada aceptacion, como los basados en los conjuntos rough (rugosos),
introducidos por Pawlak en 1982 [121, 122].
Principalmente nos centraremos en el modelo GEFRED, en el cual nos hemos basado
para desarrollar este trabajo. El modelo GEFRED constituye una sntesis eclectica de los
diferentes modelos publicados para tratar el problema de representacion y tratamiento de
informacion difusa mediante bases de datos relacionales. Una de las principales ventajas de
este modelo es que consiste en una abstraccion general que permite tratar diferentes enfoques,
incluso aunque estos puedan parecer muy dispares.
Un estudio mas detallado de todos estos modelos puede verse en las respectivas referen-
cias de cada uno y todos juntos en [103, 125]. En [103] puede verse, ademas, un estudio
35
36 CAPITULO 2. MODELOS DE BDR DIFUSAS: GEFRED
NOT AND T m F OR T m F
T F T T m F T T T T
m m m m m F m T m m
F T F F F F F T m F
Tabla 2.1: Tablas de verdad para la logica tri-valuada.

NOT AND T A I F OR T A I F
T F T T A I F T T T T T
A A A A A I F A T A A A
I I I I I I F I T A I F
F T F F F F F F T A F F
Tabla 2.2: Tablas de verdad para la logica tetra-valuada.

comparativo de GEFRED con todos los demas modelos.

2.1 Imprecision Sin Utilizar Logica Difusa


En este apartado vamos a resumir algunas ideas que posibilitan, de algun modo, el trata-
miento de informacion imprecisa, pero sin utilizar la teora de conjuntos difusos ni, por tanto,
distribuciones de posibilidad. En la bibliografa a veces se engloban estos modelos en el apar-
tado de imprecision en bases de datos convencionales, aunque, algunas de las ideas que aqu
se exponen no han sido implementadas en ningun modelo.

2.1.1 Aproximacion de Codd


El primer intento de representar datos imprecisos en una base de datos fue la introduccion
de valores nulos, NULL, por parte de Codd, en 1979 en [43] y ampliado en [44, 46, 47]. Este
modelo no utilizaba la teora de conjuntos difusos. Un valor NULL en un atributo indica que
dicho valor era cualquiera de entre todos los que estuvieran incluidos en el dominio de dicho
atributo.
Cualquier comparacion con un valor NULL, origina un resultado que no es ni Verdad (T,
True) ni Falso (F, False), llamado \quizas" (m, Maybe) (o desconocido, unknown, en el SQL
de Oracle). Las tablas de verdad de los comparadores clasicos NOT, AND y OR pueden verse
en la Tabla 2.1.
Despues, se a~nadio un matiz mas, diferenciando el valor NULL en dos marcas: \A-marca"
que representa un valor ausente o desconocido, pero aplicable y el valor \I-marca" que re-
presenta que el valor esta ausente porque no es aplicable. Una I-marca puede ser situada,
por ejemplo, en el atributo matrcula del coche, de alguien que no tiene coche. Esto da lugar
a una logica tetra-valuada donde el valor A, que tiene el similar signi cado que el m de la
Logica tri-valuada anterior, surge como resultado de comparar cualquier valor que contenga
una \A-marca" y un nuevo valor I es a~nadido como resultado de comparar cualquier valor
que contenga una \I-marca". En la Tabla 2.2 se muestran las tablas de verdad de esta logica
tetra-valuada.
 SIN UTILIZAR LOGICA
2.1. IMPRECISION  DIFUSA 37

2.1.2 Esquema con Valores por Defecto


Date presento en 1982 una aproximacion para el tratamiento de valores nulos (dicha aproxi-
macion se recoge en [50]). Parte de la opinion de que el problema del tratamiento de valores
nulos no se encontraba bien de nido y de que, por tanto, de momento no debera incorporarse
esta caracterstica al Modelo Relacional. Partiendo de esta premisa, presenta una alternativa
basada en el concepto de \valores por defecto".
En este modelo, en la declaracion de cada dominio se designa un valor de dicho dominio
como \valor por defecto". Igual que en SQL se hace con la clausula DEFAULT (ver apartado
1.2.5.5). As, cuando se inserta una nueva tupla en una relacion, el usuario tiene que propor-
cionar un valor para cada atributo que no tenga un \valor por defecto" y el sistema asignara
el \valor por defecto" en aquellos atributos en los que no se proporcione su valor.
2.1.3 Rangos en Valores
En [85], Grant extiende el modelo relacional para permitir almacenar en un atributo un rango
o intervalo de valores posibles para el mismo, ademas de un valor preciso y el valor NULL en
el caso de que no se tenga ninguna informacion.
El problema de tuplas repetidas lo soluciona permitiendolas, ya que aunque aparezcan
como identicas, pueden ser distintas.
Los operadores relacionales son rede nidos en dos versiones, True y Maybe. Por ejemplo
el operador < se de ne como:

[a; b] <T [n; m] si b < n (2.1)


[a; b] <M [n; m] si a < m
Para las consultas en este modelo puede utilizarse la propuesta de Lipski [98, 128] de
situar cada tupla en una de estas tres categoras: Tupla que seguro que pertenece al resultado
(surely-set), tupla que posiblemente pertenece al resultado (possible-set) y tupla que seguro
que no pertenece al resultado (eliminated-set).
2.1.4 Bases de Datos Estadsticas y Probabilsticas
La principal propuesta en este sentido fue publicada en 1982 de la mano de Wong [153], en la
cual maneja multitud de casos de incertidumbre por inferencia estadstica. Esta formulacion
supone que la informacion incompleta puede ser comparada estadsticamente. Este metodo
ve las consultas como experimentos estadsticos en los que la informacion es incompleta y se
centra en calcular la respuesta a la consulta como el conjunto de aquellas tuplas que minimizan
los dos tipos de errores estadsticos. En [137], Shoshani y Wong resumen la investigacion y
utilidad sobre bases de datos estadsticas.
En [11], Barbara et al. publicaron el modelo mas desarrollado de bases de datos proba-
bilsticas, en el que las probabilidades estan asociadas a los valores de los atributos. En este
modelo, cada atributo probabilstico se trata como una distribucion de probabilidad discreta.
En una tupla, las probabilidades deben estar normalizadas: La suma de las probabilidades
de todos los valores probables debe ser igual a 1. Sin embargo, puede ser difcil determinar
las probabilidades para todos los posibles valores del dominio. As, desarrollan el concepto de
probabilidades perdidas (missing probabilities ) para introducir, el resto de probabilidades en
un valor general que incluye todos los valores del dominio, sin especi car como se distribuye
38 CAPITULO 2. MODELOS DE BDR DIFUSAS: GEFRED
la probabilidad en esos valores. O sea, en la base de datos se almacenara cada valor del
dominio que sepamos su probabilidad y esta probabilidad y, para el conjunto de todos los va
valores del dominio se almacena el valor restante de la probabilidad (1 menos la suma de las
probabilidades que conocemos).
En las recuperaciones, se podran establecer un mecanismo para recuperar solo los valores
que tengan una probabilidad mayor que un determinado umbral. Ademas, en las operaciones
relacionales (como la Reunion Natural), las probabilidades pueden necesitar ser recalculadas.
Para el calculo de estas probabilidades se consideran dos metodos. Uno es que estas sean
introducidas por el usuario de acuerdo a su criterio personal o a unos calculos efectuados
por el mismo. Otro es que el sistema sea el que calcule estas probabilidades a partir de un
conjunto de ejemplos, entre los que pueden estar datos recogidos por encuestas o examinando
directamente una muestra de la poblacion.
En el modelo de Cavallo y Pittarelli [36] la probabilidad aparece asociada a cada tupla,
indicando la probabilidad de que dicha tupla pertenezca a la relacion. El trabajo de Fuhr
[69], en cambio, se centra mas en como especi car consultas imprecisas.

2.2 Modelos Basicos de Bases de Datos Difusas


El modelo basico de BDRD se considera la forma mas simple y consiste en a~nadir un grado,
normalmente en el intervalo [0,1], a cada tupla. Esto permite mantener la homogeneidad de
los datos de la base de datos. Sin embargo, la semantica que se le asigne a ese grado sera
la que determine su utilidad y, por tanto, esta semantica sera utilizada en los procesos de
consulta.
Este grado puede tener el signi cado de grado de pertenencia de cada tupla a la relacion
[84, 114]. Este grado puede tener otros signi cados, como el nivel de la fuerza de dependencia
que existe entre dos atributos, representando as la relacion que exista entre ellos [10], el grado
de cumplimiento de una condicion o el grado de importancia [23] de cada tupla en la relacion,
entre otros (ver apartado 2.8).
El principal inconveniente de estos modelos difusos es que no permite representar la infor-
macion imprecisa que tengamos sobre algun atributo particular de alguna entidad concreta
(como los valores \joven" o \viejo" para un atributo \Edad"). Ademas, el caracter difuso es
asignado de forma global a cada tupla.

2.3 Modelo de Buckles-Petry


El primer modelo que utiliza relaciones de similitud [166] en el modelo relacional fue el
propuesto por Buckles y Petry [28, 29, 30], en el que las bases de datos no difusas son un caso
particular de su modelo.
Una Relacion Difusa la de nen como un subconjunto del producto cartesiano siguiente:
P (D1 )  : : :  P (Dm ), donde P (Di ) representa el conjunto de las partes de un dominio
Di , que incluye a todos los subconjuntos que pueden considerarse dentro del dominio Di (con
cualquier numero de elementos).
A continuacion ponemos algunos ejemplos de los valores que pueden representarse. Los
dos primeros pertenecen al modelo original y el tercer tipo fue a~nadido mas tarde [30]:
1. Conjunto nito de escalares. Ej. frubio, casta~no, pelirrojog.
2.4. MODELO DE PRADE-TESTEMALE 39

2. Conjunto nito de numeros. Ej. f15, 16, 17g.


3. Conjunto de numeros difusos. Ej. fmuy alto, altog.
El signi cado de estos valores es disyuntivo, o sea, en el primer ejemplo indica que la
persona que tiene ese valor tiene el pelo rubio, casta~no, o pelirrojo. A cada uno de esos
valores posibles se le llama interpretacion.
Para cada dominio D, escalar o numerico, se establece una Relacion de similitud que sirve
para medir la similitud o parecido entre cada dos elementos del dominio1. Normalmente, los
valores de similitud estan normalizados en el intervalo [0,1], correspondiendo el 0 al signi cado
\totalmente diferentes" y el 1 al signi cado \totalmente parecidos" (o \iguales"). Por tanto,
una Relacion de Similitud puede ser vista como una funcion sr , tal que:

sr : D  D ! [0; 1] (2.2)
sr (di ; dj ) 7 ! [0; 1]
con di ; dj 2 U .
Para un determinado umbral , los valores que sean similares con un grado mayor que
seran indistinguibles y podran ser considerados identicos. En [7] pueden encontrarse distintas
formulas que modelan esta indistinguibilidad. As, pueden construirse clases de equivalencia
de forma que los elementos de una misma clase son indistinguibles para el grado de similitud
.
En [32] se desarrolla un Calculo Relacional para este modelo.
Un modelo similar fue propuesto por Shenoi y Melton [135, 136], en el que usaban re-
laciones de proximidad en vez de las relaciones de similitud. Las relaciones de proximidad
cumplen tambien las propiedades re exiva y simetrica pero no cumplen necesariamente la
propiedad transitiva [166].

2.4 Modelo de Prade-Testemale


Prade y Testemale publicaron en [127, 128, 129, 130] un modelo de BDRD que permite
incorporar lo que denominan datos \incompletos" o \inciertos" en el ambito de la Teora de
la Posibilidad (apartado 1.3.5).
Consideremos un atributo A cuyo dominio es D. Todo nuestro conocimiento disponible
acerca del valor que toma A para un objeto x puede ser representado mediante una distribu-
cion de posibilidad A(x) sobre D [ feg, donde e es un elemento especial que denota el caso
en que A no se aplica a x. En otras palabras, A(x) es una aplicacion que va de D [ feg al
intervalo [0; 1]. Con esta formulacion pueden representarse todos los tipos de valores que se
exponen en la Tabla 2.3.
Los casos 1, 2 y 3 permiten representar las situaciones tratadas anteriormente en los
modelos sin Logica difusa (apartado 2.1). En cambio, el resto supone un muestrario de las
capacidades de representacion del modelo.
En todos los modelos posibilsticos hay que tener en cuenta que si tenemos que, para un
d 2 D, se cumple que A(x)(d) = 1, esto solo indica que el valor d es completamente posible
1 En la Tabla 5.5 se muestra un ejemplo de relacion de similitud sobre un atributo RENDIMIENTO de una
tabla de EMPLEADOS.
40 CAPITULO 2. MODELOS DE BDR DIFUSAS: GEFRED

Informacion Modelo Prade-Testemale Modelo Umano-Fukami


1. Sabemos exacta- A(x)(e) = 0
mente el dato y este A(x)(c) = 1 A(x) (d) = f1=cgP
es \crisp": c A(x)(d) = 0; 8d 2 D; d 6= c
2. Desconocida (pero A(x)(e) = 0 Unknown (ecuacion 2.3)
aplicable) A(x)(d) = 1; 8d 2 D
3. No aplicable o sin A(x)(e) = 1 Unde ned (ecuacion 2.4)
sentido A(x)(d) = 0; 8d 2 D
4. Ignorancia total A(x)(d) = 1; 8d 2 D [ feg Null (ecuacion 2.5)
5. Rango [m; n]: En- A(x)(e) = 0
tre m y n A(x()(d) = A(x() (d) =
1 si d 2 [m; n]  D 1 si d 2 [m; n]  D
0 en otro caso 0 en otro caso
6. La informacion A(x) (e) = 0
disponible es una dis- A(x) (d) = a (d) 8d 2 D A(x) (d) = a (d) 8d 2 D
tribucion de posibili-
dad a
7. La posibilidad de A(x) (e) = ; No representable
que no sea aplicable A(x) (d) = a (d) 8d 2 D
es  y, caso de que sea
aplicable el dato es a
Observe que, en el caso 7, la distribucion de posibilidad a puede representar
cualquier tipo de informacion de los tipos 1, 2, 5 y 6.

Tabla 2.3: Representacion de informacion en dos modelos posibilsticos.

para A(x), y no que el valor d sea cierto para A(x), a menos que ese sea el unico valor posible,
i.e. A(x) (d0 ) = 0; 8 d0 6= d.
Ademas, todas las distribuciones de posibilidad deben estar normalizadas, es decir, debe
existir al menos un valor d con total posibilidad (A(x) (d) = 1). Como se dijo en el apartado
1.3.5 dos distribuciones de posibilidad pueden ser comparadas usando los comparadores de
posibilidad o de necesidad, pudiendo as efectuar una determinada seleccion sobre una relacion
difusa de este modelo. Ademas, las tuplas resultantes pueden ser distinguidas por su nivel de
satisfaccion de la condicion.

2.5 Modelo de Umano-Fukami


Uno de los primeros modelos de bases de datos relacionales difusas fue el que presentaron
Umano, Fukami et al., en [70, 142, 143, 144, 145].
2.5. MODELO DE UMANO-FUKAMI 41

En esta propuesta utiliza las distribuciones de posibilidad para modelar el conocimiento


sobre la informacion en forma similar a como lo hacen Prade-Testemale. La diferencia reside
en como concibe la informacion \no aplicable" que entienden que puede ser modelada por
una distribucion de posibilidad sobre el dominio considerado, en la que cada valor de dominio
aparece con un valor de posibilidad igual a 0. Es decir, si D es el universo de discurso de A(x)
y A(x) (d) representa la posibilidad de que A(x) tome el valor u en U , entonces para los valores
\desconocidos y aplicables", que denomina \unknown", emplea la misma representacion que
Prade-Testemale:
Unknown : A(x) (d) = 1 8d 2 D (2.3)
Para los valores \no aplicables" existe un caso especial de distribucion de posibilidad
denominado \inde nido" (unde ned) y que se representa como:
Unde ned : A(x) (d) = 0 8d 2 D (2.4)
Para representar la situacion en la que no se conoce incluso si una \ausencia" de informa-
cion es \aplicable" o no, emplean un valor especial que denominan \Null":
Null = f1=Unknown; 1=Unde nedg (2.5)
Para el resto de los casos de informacion \imprecisa" adopta una representacion similar
a la del modelo Prade-Testemale. En la Tabla 2.3 puede verse una comparacion de las
representaciones empleadas en ambos modelos.
En [145] Umano y Fukami extienden su modelo de bases de datos difusas, al que llaman
modelo possibility-distribution-fuzzy-relational (modelo relacional difuso de distribuciones de
posibilidad), para representar y manipular datos ambiguos. En este modelo permiten alma-
cenar distribuciones de posibilidad en los valores de los atributos. Ademas, cada tupla de
una relacion tiene asociada una distribucion de posibilidad en el intervalo [0,1], de forma que
indica el grado de pertenencia de esa tupla a esa relacion (signi cado 2). O sea, ellos de nen
una relacion difusa R, de m atributos, como una funcion de pertenencia R :

R : P (U1 )  P (U2 )      P (Um ) ! P ([0; 1])


donde el smbolo  denota el Producto Cartesiano, P (Uj ) con j = 1; 2; : : : ; m es la coleccion
de todas las distribuciones de posibilidad en el Universo de discurso Uj del j -esimo atributo
de R.
La funcion R asocia a cada tupla de la relacion R un valor de P ([0; 1]), que es el conjunto
de todas las distribuciones de posibilidad en el intervalo [0,1] y que sera vista como un grado
de pertenencia de esa tupla a R.
A efectos practicos es como si a cada relacion R se le a~nadiera un atributo (R ) con el
dominio en P ([0; 1]). Naturalmente, puede almacenarse un numero entre 0 y 1 (por ejemplo
0.8) como valor para ese atributo, siendo este visto como una distribucion de posibilidad (1/0.8
en el ejemplo). Igualmente, podemos almacenar valores \crisp" en cualquier otro atributo.
De esta forma el modelo possibility-distribution-fuzzy-relational tiene la ventaja de per-
mitir dos tipos de ambiguedad:
1. Ambiguedad en los valores de los atributos: Permite que los valores que almacenan las
relaciones no sean valores exactos, sino que pueden ser distribuciones de posibilidad.
42 CAPITULO 2. MODELOS DE BDR DIFUSAS: GEFRED
2. Ambiguedad en la asociacion de valores: Asigna a cada tupla un grado de pertenencia
a la relacion, que puede ser visto como un grado de verdad para indicar en que medida
estan relacionados los atributos de cada tupla (a traves de la relacion).
En este contexto de ne los operadores basicos del A lgebra Relacional entre relaciones de
este tipo: Union, Diferencia, Producto Cartesiano, Proyeccion y Seleccion. Tambien de ne los
otros operadores no basicos: Interseccion, Reunion y Division. En particular, en el apartado
3.7.2 estudiaremos la Division Relacional que estos autores proponen, con sus ventajas e
inconvenientes.
Cuando en los valores de los atributos hay distribuciones de posibilidad (valores no \crisp")
utiliza el Principio de Extension [167] para operar entre ellos.
Algunos autores [115, 139] utilizan un grado de posibilidad, de forma que en la relacion
resultante de una seleccion, las tuplas tendran un grado que sera obtenido de tomar el mnimo
entre el grado que tenan en la relacion original y el grado de cumplimiento de la condicion
de la seleccion.

2.6 Modelo de Zemankova-Kaendel


Este modelo de base de datos, publicado en [170, 171], se compone de tres partes: (a) una
base de datos de valores (VDB) donde se organizan los datos en forma similar al resto de los
modelos posibilsticos, (b) una base de datos explicativa, donde se almacenan las de niciones
para los subconjuntos difusos y relaciones difusas y (c) un conjunto de reglas de traduccion,
que se emplean para el manejo de adjetivos, etc. La manipulacion de datos esta basada en
el algebra relacional. Este lenguaje esta implementado en una forma extendida del sistema
RIM (Relational Information Management) desarrollado por la Boeing Co.
 Planteamiento de la consulta: Este modelo plantea la recuperacion en una consulta
en forma similar al de Prade-Testemale solo que la medida de posibilidad que emplea
para encontrar la compatibilidad del subconjunto difuso F de la condicion con el valor
del atributo A para cada tupla en la relacion viene dada por:

pA(F ) = sup fF (u)  (u)g (2.6)


u2D
y la medida de certeza
cA (F ) = max
u2D
f0; inf fF (u)  A(u)gg (2.7)
es usada en lugar de la medida de necesidad de Prade-Testemale. Sin embargo, la
interpretacion del grado de certeza no esta clara y no hay relacion entre la posibilidad
y la certeza, como s la hay entre posibilidad y necesidad: N (X ) = 1 P (:X ).
El resultado de una consulta se presenta en forma de relaciones difusas las cuales con-
tienen dos campos en los que se recogen los valores de posibilidad y certeza que
presenta cada tupla para la consulta dada. Sobre estas relaciones se pueden establecer
unos umbrales mnimos a satisfacer para las tuplas que se recuperen.
2.7. MODELO GEFRED DE MEDINA ET AL. 43

 Operadores de Seleccion: En el estudio que hacen de las condiciones impuestas en


la seleccion parten de una relacion  de similaridad sobre D  D y a partir de ella
construyen cualquier otra relacion de comparacion [170]. Dan tres ejemplos: \aprox.
igual", \mayor que" y \menor que". Si s es la relacion de similitud de la que se parte
la relacion \mayor que" se construira:
 1 0:5  s(x; y) si x  y
mayor que(x; y) = 0:5  s(x; y) si x < y (2.8)

Las correspondientes medidas de posibilidad se computaran utilizando la ecuacion 2.6


lo que dara para condiciones de tipo Af con f atomico:

pf (A(x)) = supf (d; f )  A(x)(d)g (2.9)


d2D
para condiciones del tipo AF donde F no sea atomico, no da ninguna regla de calculo.

2.7 Modelo GEFRED de Medina et al.


El modelo GEFRED [102, 103] fue propuesto por Medina, Pons y Vila y se basa en la de nicion
de lo que llama Dominio Difuso Generalizado (D) y Relacion Difusa Generalizada (R), que
incluyen los dominios y las relaciones clasicas respectivamente:
De nicion 2.1 Si U es el universo o dominio de discurso, Pe(U ) el conjunto de todas las
distribuciones de posibilidad de nidas sobre U , incluidas las que de nen los tipos Unknown
y Unde ned (tipos 8 y 9 de la tabla 2.4), y NULL es otro tipo de nido en la tabla 2.4 (tipo
10) entonces, de nimos Dominio Difuso Generalizado como D  Pe(U ) [ NULL.
Los tipos Unknown, Unde ned y NULL son de nidos en el sentido de Umano, Fukami et
al. de [70] y [143]. tu
Con esos dominios difusos podremos representar todos los tipos de datos que se expresan
en la tabla 2.4.
De nicion 2.2 Una Relacion Difusa Generalizada, R, viene dada por un par de con-
juntos: \cabecera" (H) y \cuerpo" (B), R = (H; B), de nidos como sigue:
- La \Cabecera" es un conjunto jo de ternas atributo-dominio-compatibilidad (donde el
ultimo es opcional),
H = f(A1 : D1 [; C1 ]); (A2 : D2 [; C2 ]); : : : ; (An : Dn [; Cn ])g
donde a cada atributo Aj , le subyace un dominio difuso generalizado, no necesariamente
distinto, Dj (j = 1; 2; : : : ; n). Cj es un \atributo de compatibilidad" que toma valores
en el intervalo [0,1].
44 CAPITULO 2. MODELOS DE BDR DIFUSAS: GEFRED
1. Un escalar simple (Ej. Tama~no=Grande, representado mediante la distribu-
cion de posibilidad 1/Grande).
2. Un numero simple (Ej. Edad=28, representado mediante la distribucion de
posibilidad 1/28).
3. Un conjunto de posibles asignaciones excluyentes de escalares
(Ej. Aptitud=fMala,Buenag, se expresa f1/Mala,1/Buenag).
4. Un conjunto de posibles asignaciones excluyentes de numeros
(Ej. Edad= f20; 21g, representado mediante f1=20; 1=21g).
5. Una distribucion de posibilidad en el dominio de los escalares
(Ej. Aptitud= f0:6/mala,1.0/regularg).
6. Una distribucion de posibilidad en el dominio de los numeros
(Ej. Edad= f0:4=23; 1:0=24; 0:8=25g, numeros difusos, etiquetas lingusticas).
7. Un numero Real 2 [0; 1] representando grados de cumplimiento
(Ej. Calidad=0.9).
8. Un valor desconocido Unknown dado por la distribucion de posibilidad
Unknown=f1=u : u 2 U g sobre el dominio, U , considerado.
9. Un valor inde nido Unde ned dado por la distribucion de posibilidad
Unde ned=f0=u : u 2 U g sobre el dominio, U , considerado.
10. Un valor nulo NULL dado por la expresion
NULL=f1/Unknown,1/Unde nedg.
Tabla 2.4: Tipos de datos que puede representa GEFRED.

- El \Cuerpo" consiste en un conjunto de tuplas difusas generalizadas distintas, donde


cada tupla esta compuesta por un conjunto de ternas atributo-valor-grado (el grado es
opcional),

B = f(A1 : dei1 [; ci1 ]); (A2 : dei2 [; ci2 ]); : : : ; (An : dein [; cin ])g
con i = 1; 2; : : : ; m; siendo m el numero de tuplas de la relacion, y donde deij repre-
senta el valor de dominio que toma la tupla i sobre el atributo Aj , y cij el grado de
compatibilidad asociado a este valor.
tu
El grado de compatibilidad se usara cuando efectuemos alguna operacion (por ejemplo una
consulta) y nos servira para almacenar el grado con el que un valor de un atributo concreto
de una tupla concreta ha satisfecho dicha operacion. As, las relaciones base de la base de
datos no tienen atributos de compatibilidad.
De nicion 2.3 Sea R una relacion difusa generalizada dada por:
 H = f(A : D [; C ]); : : : ; (A : D [; C ])g
R = B = f(A1 : de 1 [; c 1]); : : : ; (A n : de n [; c n])g (2.10)
1 i1 i1 n in in
con i = 1; 2; : : : ; m, siendo m el numero de tuplas de la relacion. Entonces, se de nen:
2.7. MODELO GEFRED DE MEDINA ET AL. 45

 Componente de valor de una relacion difusa generalizada, Rv , como la parte de la


relacion dada por:

 Hv
= f(A1 : D1 ); : : : ; (An : Dn )g
Rv =Bv = f(A1 : dei1 ); : : : ; (An : dein )g (2.11)

donde Hv y Bv son las componentes de valor de la \cabecera" y el \cuerpo" respec-


tivamente.
 Componente de compatibilidad de una relacion difusa generalizada, Rc, como la
parte de la relacion dada por:

 Hc = f[C1 ]; : : : [; Cn ]g
Rc = Bc = f[ci1 ]; : : : [; cin ]g (2.12)

donde Hc y Bc son las componentes de compatibilidad de la \cabecera" y el \cuerpo"


respectivamente.
tu
Los operadores de comparacion tambien son rede nidos para adaptarse a la naturaleza
difusa de los datos que manejamos:
De nicion 2.4 Sea U el dominio de discurso considerado. Llamaremos Comparador Ex-
tendido, , a cualquier relacion difusa de nida sobre U , expresada en la forma:
 : U  U ! [0; 1] (2.13)
(ui; uj ) 7 ! [0; 1]
con ui ; uj 2 U tu
De nicion 2.5 Sea U el dominio de discurso considerado, D el dominio difuso generalizado
construido sobre el y sea  un comparador extendido de nido en U. Consideremos una funcion
 de nida como:

 : D  D ! [0; 1] (2.14)
 (de1 ; de2 ) 2 [0; 1]
Entonces, diremos que  es un Comparador Difuso Generalizado sobre D inducido por
el comparador extendido , si cumple:

 (de1 ; de2 ) = (d1 ; d2 ) 8d1 ; d2 2 U (2.15)


donde de1 ; de2 representan las distribuciones de posibilidad 1=d1 ; 1=d2 , inducidas, respectiva-
mente, por los valores d1 ; d2 . tu
46 CAPITULO 2. MODELOS DE BDR DIFUSAS: GEFRED
En una relacion (De nicion 2.2), el grado de compatibilidad del valor de un atributo
concreto (en una tupla) se obtiene como consecuencia de los procesos de manipulacion rea-
lizados sobre esa relacion y expresa el grado con el que ese valor ha satisfecho la operacion
realizada sobre el.
Sobre estas de niciones GEFRED rede ne los operadores del algebra relacional en el
llamado A  lgebra Relacional Difuso Generalizado: Union, Interseccion, Diferencia, Pro-
ducto cartesiano, Proyeccion, Seleccion, Reunion y Division. Estos operadores se de nen
indicando la cabecera y el cuerpo de una Relacion Difusa Generalizada que sera el resultado
de la operacion. Todos esos operadores estan de nidos en [102] y [103], excepto la division
que esta de nida en el Captulo 3 [72]. A continuacion, damos la de nicion de algunos de los
operadores del A lgebra Relacional Difuso Generalizado, que usaremos posteriormente.
De nicion 2.6 Sean R y R0 dos relaciones difusas generalizadas dadas por:
 H = f(A : D [; C ]); : : : ; (A : D [; C ])g
R = B = f(A1 : de 1 [; c 1]); : : : ; (A n : de n [; c n])g
1 i1 i1 n in in

 H0 = f(A01 : D10 [; C10 ]); : : : ; (A0n0 : Dn0 0 [; Cn0 0 ])g


R0 = B0 = f(A01 : de0k1 [; c0k1 ]); : : : ; (A0n0 : de0kn0 [; c0kn0 ])g
donde i = 1; : : : ; m y k = 1; : : : ; m0 , siendo m y m0 las respectivas cardinalidades y donde n
y n0 son los respectivos grados. Entonces, el Producto Cartesiano Difuso Generalizado
se de ne como una relacion difusa generalizada dada por:
H H [ H0
R  R0 =  = (2.16)
B = B  B0
tu
De nicion 2.7 Sea R una relacion difusa generalizada dada por la ecuacion 2.10, y sea X
un subconjunto de H expresado como:
X  H; X = f(As : Ds [; Cs0 ]) : s 2 S; s0 2 S 0; S; S 0  f1; : : : ; ngg
Entonces, la Proyeccion Difusa Generalizada de R sobre X , P (R; X ) es una relacion
difusa generalizada dada por:
 P = X
P (R ; X ) = H BP = f(As : deis [; cis0 ])g (2.17)

con s 2 S , s0 2 S 0 y S; S 0  f1; : : : ; ng. tu


De nicion 2.8 Sea R una relacion difusa generalizada dada por la ecuacion 2.10, ea 2 D
una constante,  un comparador difuso generalizado y sea 2 [0; 1] un \umbral de cumpli-
miento". Entonces, la Seleccion Difusa Generalizada realizada sobre R con la condicion
inducida por  compuesto con ea y el atributo Ak (k 2 f1; : : : ; ng) y cuali cada por , S (R;
 (Ak ; ea)  ), es una relacion dada por:
2.8. RESUMEN DE LOS TIPOS DE MODELOS DE BDRD 47

 HS= f(A1 : D1 [; C1 ]); : : : ; (An : Dn [; Cn ])g


S (R;  (Ak ; ea)  ) = BS = f(A1 : der1 [; cr1 ]); : : : ; (Ak : derk ; c0rk ); : : : ; (An : dern [; crn ])g
(2.18)
con
c0rk =  (derk ; ea)  (2.19)
donde r = 1; : : : ; m0 , siendo m0 la cardinalidad de la seleccion. tu

2.8 Resumen de los Tipos de Modelos de BDRD


Como hemos visto, a nivel teorico existen muchos modelos de Bases de Datos Relacionales Di-
fusas (BDRD) que, basados en el modelo relacional (apartado 1.2), lo extienden para permitir
almacenar y/o tratar informacion imprecisa o incierta.
Los modelos de BDRD se basan en el concepto de relacion difusa. Sin embargo, hay varias
formas de permitir informacion imprecisa o incierta en estas relaciones difusas. Ademas, esas
formas pueden ser mezcladas para permitir una mayor exibilidad. Algunas de las mas
importantes formas de introducir informacion difusa en las relaciones son:
1. Valores difusos en los atributos: Esto se re ere a que en los atributos de una
relacion podremos almacenar valores difusos y podremos operar con ellos. El tipo de
estos valores puede ser muy variado, como se muestra en la Tabla 2.4. Este tipo de
relaciones difusas es empleado en [28, 30, 102, 114, 129, 143, 145], aunque, como se
ha visto, no todos admiten todos los tipos posibles, siendo GEFRED [102, 103] el mas
general.
2. Grado en cada valor de un atributo: Esto implica que cada valor de cada atributo
puede tener asociado un grado, generalmente en el intervalo [0,1], que mida el nivel
de difuminado de dicho valor. El signi cado de estos grados puede ser variado como
veremos a continuacion. Este tipo de relaciones difusas es empleado en [23] (ver apartado
3.7.3) y en el modelo GEFRED [102].
3. Grado en toda la tupla de una relacion: Esto es similar al caso anterior, pero aqu
el grado esta asociado a toda la tupla y no exclusivamente a un valor particular de una
tupla. Este tipo de relaciones difusas es empleado en [114, 138, 145] (ver apartados
3.7.1 y 3.7.2).
4. Grado en un conjunto de valores de diversos atributos: Este es un caso intermedio
entre los dos casos anteriores. Aqu el grado esta asociado a algunos atributos. Este
puede ser un caso poco usual pero que puede ser a veces muy util.
El dominio de esos grados suele estar delimitado al intervalo [0,1], pero pueden permitirse
otros valores, como por ejemplo distribuciones de posibilidad.
Ademas, el signi cado de esos grados es variado. Dependiendo de este signi cado el
tratamiento de los datos podra ser diferente. Los posibles signi cados mas importantes de
los grados son los siguientes:
48 CAPITULO 2. MODELOS DE BDR DIFUSAS: GEFRED
1. Grado de cumplimiento (o satisfaccion): Una propiedad puede cumplirse con cierto
grado entre dos extremos: La propiedad se cumple totalmente (usualmente grado 1)
y la propiedad no se cumple en absoluto (usualmente grado 0). Esto suele emplearse
tras establecer alguna condicion sobre los valores de una relacion (i.e. una seleccion
con una condicion difusa) y los grados expresaran en que medida esa condicion ha sido
satisfecha. Este signi cado se usa en [23, 102, 138].
2. Grado de pertenencia: Este tipo de grados miden el nivel de pertenencia de un
objeto (por ejemplo una tupla) a un conjunto (una relacion, para el ejemplo anterior).
Este signi cado se usa en [114, 145].
3. Grado de incertidumbre: El grado expresa la seguridad con que conocemos un
dato determinado. Si estamos seguros de su veracidad dicho grado sera 1 y si estamos
seguros de su falsedad dicho grado sera 0. Los valores entre 0 y 1 expresan distintos
niveles de incertidumbre, indicando que no estamos completamente seguros. En [63]
puede verse una discusion sobre estos aspectos. Este signi cado es, en cierta forma,
bastante parecido al anterior, pues puede entenderse esa incertidumbre como expresada
sobre la pertenencia de una tupla a la relacion.
4. Grado de posibilidad: Mide la posibilidad de la informacion almacenada. Como se
dice en [125], este signi cado es similar al anterior, pero se ve este grado como mas debil
ya que contiene informacion que es mas o menos posible (y no mas o menos cierta).
5. Grado de importancia: Distintos objetos (tuplas, atributos...) pueden tener dife-
rentes importancias, de forma que existan objetos mas importantes que otros. Este
signi cado se usa en [23, 114].

2.9 Lenguajes para Consultas Flexibles


La recuperacion de informacion de una base de datos es una actividad fundamental. Con ello
pretendemos siempre obtener los datos que nos interesan en cada momento para aplicarles
un tratamiento particular. En una consulta clasica (o tradicional) se establecen las llama-
das condiciones de consulta y cada dato del resultado debe satisfacer completamente dichas
condiciones. Por consulta exible entendemos aquella consulta en la que cada condicion
individual puede ser satisfecha parcialmente. La consulta exible a bases de datos puede ser
realizada tanto en bases de datos clasicas como difusas. Basicamente, las ventajas generales
de las consultas exibles son:
 Pueden proveer respuestas cuando las consultas clasicas, por ser demasiado restrictivas,
no lo hacen.
 Conseguir los elementos que cumplen las condiciones con un grado que indique su nivel
de cumplimiento de estas condiciones, pudiendo obtener solo los n mejores.
Ademas de las consideraciones que se han expuesto anteriormente al explicar los distintos
modelos, aqu vamos a a~nadir algunas mas.
Uno de los primeros trabajos sobre consultas exibles utilizando conjuntos difusos fue el
de Tahani [138], aunque su trabajo se enfocaba sobre bases de datos clasicas. A partir de
2.9. LENGUAJES PARA CONSULTAS FLEXIBLES 49

relaciones clasicas y un predicado difuso produce una relacion en la que cada tupla tiene
asociado un grado que indica el nivel de satisfaccion del predicado.
Muy similar a la idea de Tahani es la propuesta por Bosc et al. en [23], en donde hace un
estudio sobre la division relacional entre las relaciones difusas resultantes de sendas consultas
difusas. En el apartado 3.7.3 se explica su modelo de bases de datos, sus distintas propues-
tas de division relacional y un estudio comparativo entre esas propuestas y la que nosotros
proponemos en ese mismo captulo.
Una consulta con condiciones imprecisas utiliza predicados atomicos de nidos usando con-
juntos difusos sobre un dominio particular. Por ejemplo, son predicados imprecisos \Alto",
\Caro", \Bueno"... A estos predicados se le pueden a~nadir modi cadores lingusticos, repre-
sentados por funciones de [0,1] a [0,1] para modelar los signi cados de \muy", \no muy",
\mas o menos"... Las funciones modi cadoras mas usuales son de la forma siguiente, donde
A es el predicado:
1. Amod (d) = (A (d))n
donde n > 1 para un concentrador y n < 1 para un dilatador (ver apartado 1.3.3).
2. Amod (d) = on (A (d))
donde o es una norma idempotente para un concentrador y una co-norma para un
dilatador.
3. Amod (d) = (A (d  a))
En [25] puede verse mas informacion sobre modi cadores.
Las condiciones compuestas expresadas en forma de expresiones logicas son representadas
usando operaciones sobre conjuntos difusos. Normalmente se usa la funcion mnimo para
la conjuncion y la funcion maximo para la disyuncion, pero pueden usarse otras funciones
[64, 161, 164], como las expresadas en el apartado 1.3.3.1. Tambien puede desearse expresar
que determinadas condiciones simples tienen mayor importancia que otras [60, 133].
Las consultas tambien pueden involucrar cuanti cadores [149, 158, 169] y funciones de
agregacion [62].

2.9.1 El Lenguaje SQLf de Bosc y Pivert


El lenguaje SQLf [22], publicado en 1995, representa una sntesis de las caractersticas y
funcionalidades sugeridas en otras propuestas anteriores de consulta exible en bases de datos
clasicas, como [19, 97, 115, 138, 154]. Igual que en estos trabajos, SQLf solo considera el
comando de consulta SELECT. El formato de una consulta SQLf se basa en el de una consulta
SQL (apartado 1.2.5.1) y es:
SELECT [N|T|N,T] <lista_de_selecci
on>
FROM <lista_de_tablas>
WHERE <condicion_difusa>

donde, para recuperar la relacion resultante, se aplica la condicion difusa al producto carte-
siano de todas las tablas de la lista, se proyecta sobre los atributos de la lista de seleccion
y se devuelven solo las N mejores tuplas y/o aquellas que tengan su umbral (threshold ) de
50 CAPITULO 2. MODELOS DE BDR DIFUSAS: GEFRED
cumplimiento mayor que T. Los valores N y T son opcionales y se puede especi car uno de
ellos o los dos.
En la condicion difusa, ademas de condiciones clasicas, las unicas condiciones difusas
que pueden emplearse son la comparacion entre valores \crisp" (columnas) con etiquetas
lingusticas y el uso del comparador difuso \aproximadamente igual" entre valores \crisp".
Tambien permite el uso de cuanti cadores.

2.9.2 Cuanti cadores Difusos de la Consulta


Mediante el concepto de cuanti cador [158, 164, 169] es posible construir consultas que requie-
ren efectuar un calculo sobre el numero de tuplas que satisfacen una determinada condicion.
Al igual que en el modelo clasico, los cuanti cadores pueden ser absolutos y relativos.
Los cuanti cadores absolutos pueden resolver cuestiones sobre el numero total de tuplas
resultantes de una determinada consulta, diciendo (o respondiendo a) si este numero es \gran-
de", \peque~no", \muchos", \pocos", \muchsimos"... En estos casos se observa que la verdad
del cuanti cador depende de una unica cantidad.
Los cuanti cadores relativos pueden resolver cuestiones en las que la verdad del cuanti -
cador depende de dos cantidades. Este tipo de cuanti cadores se usan en expresiones como
\la mayora", \la minora", \aproximadamente la mitad"... En estos casos, para evaluar la
verdad del cuanti cador necesitamos hallar la cantidad total que cumple la condicion y pon-
derarla respecto a la cantidad total que podra cumplirla (incluyendo los que la cumplen y
los que no la cumplen).
En [169] representa a los cuanti cadores difusos absolutos como conjuntos difusos en el
intervalo [0; +1) y los relativos como conjuntos difusos en el intervalo [0; 1]. O sea, un
cuanti cador Q es representado como una funcion Q, cuyo dominio depende de si es absoluto
o relativo:

Qabs : R+ ! [0; 1]
Qrel : [0; 1] ! [0; 1]
En [103] se ofrece una discusion con mas profundidad sobre este aspecto, donde representa
a los cuanti cadores difusos (absolutos o relativos) como distribuciones de posibilidad trape-
zoidales. En las Figuras 4.5 y 5.9 puede verse la representacion gra ca de algunos ejemplos
de cuanti cadores difusos relativos.
Ademas, los cuanti cadores pueden usarse en dos principales familias de expresiones [125],
donde Q es el Cuanti cador y A y B son predicados (condiciones difusas o no):
1. \Q elementos del conjunto X cumplen A": Por ejemplo, \la mayora de los jugadores
del equipo X son muy buenos".
2. \Q elementos del conjunto X que cumplen B tambien cumplen A": Por ejemplo, \la
mayora de los jugadores del equipo X que son altos son tambien muy buenos".
Existen varios metodos para determinar el grado de verdad de sentencias con cuanti cado-
res. Por ejemplo, en [158] se propone un metodo basado en el principio de extension, en [162]
(ver apartado 3.7.4) se propone un metodo muy extendido [20, 164] basado en operadores
OWA (Ordered Weighted Average) [160].
2.9. LENGUAJES PARA CONSULTAS FLEXIBLES 51

Otros metodos [169] distinguen cuando A es un predicado clasico y cuando A es un


predicado difuso en el que los elementos que cumplen A forman un conjunto difuso (ver
apartados 5.2.1.1 y 5.2.1.3, donde se explica el uso de cuanti cadores en FSQL).
Pueden encontrarse otras propuestas alternativas en [149, 131].
Un estudio sobre la aplicacion de cuanti cadores difusos en la Division Relacional en
BDRD puede verse en el apartado 3.6 y otras propuestas anteriores en los apartados 3.7.4 y
3.7.5. En el apartado 4.5 puede verse el uso y utilidad de cuanti cadores difusos en el Calculo
Relacional Difuso que se propone en ese mismo captulo.
52 CAPITULO 2. MODELOS DE BDR DIFUSAS: GEFRED
Captulo 3
Division Relacional Difusa
El modelo GEFRED [102, 103] no inclua una de nicion explcita para la Division Relacional
Difusa. Esta operacion, por sus caractersticas intrnsecas y por los problemas que plantea
el tratamiento de informacion \imprecisa", no es directamente trasladable de bases de datos
clasicas a difusas. En este captulo pretendemos dar una solucion a este problema, que mejora
algunos aspectos de otras soluciones aparecidas en la bibliografa. Al nal de este captulo se
ofrece un resumen de algunas otras soluciones al problema de la Division Difusa y un breve
estudio comparativo con la propuesta que aqu hacemos.
Las tuplas de la relacion resultante de la division que aqu proponemos se obtienen junto
con un grado de posibilidad que indica la medida en que esa tupla cumple las condiciones de
la division relacional. Los resultados obtenidos son los que intuitivamente se esperan obtener.
Ademas, para formalizar este metodo de division relacional difusa, se de nen dos nuevos
operadores que pueden ser utiles en otras operaciones (apartado 3.2): La Interseccion Difusa
Cuali cada y la Proyeccion Difusa Generalizada con Funciones de Grupo.
A lo largo de este trabajo nos centraremos en el uso de las relaciones difusas del modelo
GEFRED que, como se ha dicho en el apartado 2.8, representa la informacion difusa en dos
sentidos: Valores difusos en los atributos y un Grado (opcional) asociado a cada valor. Esos
grados son vistos como grados de cumplimiento.

3.1 Introduccion y Enfoque del Problema


La division relacional es un operador del A lgebra relacional. Este operador permite resolver
preguntas del tipo:
 Lista todos los clientes que han comprado todos nuestros productos.
 Dame los clientes de Madrid que han comprado de todos los 10 productos mas vendidos.
La division relacional hace uso del cuanti cador universal (para todo, 8) seleccionando las
tuplas de una primera relacion que estan relacionadas, de alguna forma, con todas las tuplas
de una segunda relacion.
Los cuanti cadores lingusticos han sido muy usados en el contexto de las Bases de Datos
para procesar consultas exibles. Ejemplo de esto es el metodo presentado por Zadeh en
[169], el uso de los operadores OWA presentado por Yager en [162, 163, 164] o el metodo
que Vila et al. presentaron en [150]. En este ultimo artculo puede verse, ademas, un estudio
comparativo de los metodos de Zadeh y Yager.
53
54 CAPITULO 3. DIVISION
 RELACIONAL DIFUSA

Estos estudios sirven para calcular el grado de cumplimiento (o de verdad) de a rmaciones


que incluyen cuanti cadores lingusticos (absolutos o relativos) y propiedades (precisas o
imprecisas). Por ejemplo, calculan el grado de cumplimiento de a rmaciones del tipo:
 Muy Pocos estudiantes son buenos en Matematicas.
 La mayora de los estudiantes son jovenes.
Sin embargo, estos metodos solo dan un grado de cumplimiento para la expresion y no
nos dicen las tuplas que cumplen la a rmacion y en que grado la cumple cada una. En el
presente trabajo formalizamos un metodo para calcular la respuesta a preguntas del tipo de
los primeros ejemplos, dados al principio de esta seccion, indicando las tuplas que satisfacen
la pregunta y en que grado la satisfacen. Esto nos va a permitir establecer un umbral, u,
para seleccionar solo aquellas tuplas cuyos grados de cumplimiento sean mayor que u. Otra
importante aportacion de nuestra propuesta es que los valores de los atributos pueden ser
difusos de multitud de tipos (Tabla 2.4).
La de nicion de la division relacional clasica la podemos encontrar en el apartado 1.2.4.1.
En este trabajo nos centraremos en la primera de nicion, sin considerar la division extendida,
para simpli car y para enfocar mejor el problema.
La division relacional no es una operacion primitiva del algebra relacional clasico, ya que
puede expresarse en terminos de los operadores primitivos del algebra relacional clasico. En la
ecuacion 1.4 se muestra como puede expresarse el operador de division en funcion de algunos
de los operadores primitivos del algebra relacional clasico: Proyeccion, Producto Cartesiano
y Diferencia relacional.
Nosotros llamaremos a esa ecuacion la formula clasica de la division relacional. Esa
formula sera explicada y demostrada de manera informal en el apartado 3.3.2.
El problema surge cuando los atributos de nuestra base de datos no son \crisp", sino
distribuciones de posibilidad. Entonces, la proyeccion no es trivial, pues hay que considerar
cuando dos distribuciones de posibilidad se consideran redundantes. Existen varios criterios
para esto. Por ejemplo, en [129] Prade y Testemale consideran que dos distribuciones de
posibilidad  y 0 sobre un dominio D son aproximadamente iguales si
sup j (d) 0 (d) j "D (3.1)
d2D
donde "D es un umbral dependiente del dominio.
El mismo problema se plantea en la diferencia relacional, ya que hay que considerar si dos
tuplas son o no iguales, lo cual, en un contexto difuso no siempre dara por respuesta si o no,
ya que dos tuplas pueden ser redundantes solo en cierto grado.
El metodo que aqu presentamos esta enmarcado dentro del modelo GEFRED [102, 103],
aunque sus fundamentos teoricos pueden usarse en otros contextos. Como se ha dicho, GE-
FRED de ne de nuevo los operadores del algebra relacional en el llamado A  lgebra Relacio-
nal Difuso Generalizado: Union, Interseccion, Diferencia, Producto cartesiano, Proyec-
cion, Seleccion y Reunion. Estos operadores se de nen indicando la cabecera y el cuerpo de
una Relacion difusa generalizada que sera el resultado de la operacion. El grado de com-
patibilidad del valor de un atributo concreto (en una tupla) se obtiene como consecuencia
de los procesos de manipulacion realizados sobre esa relacion y expresa el grado en el que ese
valor ha satisfecho la operacion realizada sobre el. De acuerdo con esto, las relaciones base
3.2. DOS NUEVOS OPERADORES 55

de la base de datos no tienen atributos de compatibilidad. El grado de compatibilidad no


indica, por tanto, el grado de pertenencia a la relacion.
Para nuestra de nicion de Division Relacional Difusa, usaremos las de niciones de Pro-
ducto Cartesiano Difuso Generalizado, Proyeccion Difusa Generalizada y Selec-
cion Difusa Generalizada dadas en el apartado 2.7.

3.2 Dos Nuevos Operadores


Como ya hemos indicado anteriormente, para la de nicion de la division difusa generalizada,
vamos a de nir dos nuevos operadores que tambien pueden usarse para otros nes, incluso
fuera del contexto de GEFRED.

3.2.1 Interseccion Difusa Cuali cada: \Q


En el algebra relacional clasico, si suponemos que tenemos dos relaciones clasicas R y R0 com-
patibles respecto a la union (con igual numero y tipo de atributos), la interseccion relacional,
notada por R \ R0 , representa las tuplas de R que pertenecen tambien a R0 (entendiendo la
pertenencia desde un punto de vista \crisp").
En una base de datos relacional difusa los conceptos anteriores ya no estan tan claramente
de nidos: La igualdad de tuplas y la pertenencia a un conjunto son conceptos difusos. En
este contexto, de nimos la Interseccion Difusa Cuali cada de R y R0 , notada por R \Q R0 ,
que expresa la posibilidad de que existan las tuplas de R en la relacion R0 o, dicho de otro
modo, la posibilidad de que las tuplas de R esten en la interseccion.
De nicion 3.1 Sean R y R0 dos relaciones difusas generalizadas, tales que ambas son rela-
ciones base de la base de datos y compatibles con respecto a la union, dadas por:
H = f(A1 : D1 ); : : : ; (An : Dn )g
R= B = f(A1 : dei1 ); : : : ; (An : dein )g
 H0 = f(A01 : D1 ); : : : ; (A0n : Dn g
R0 = B0 = f(A01 : de0 k1); : : : ; (An : de0kn)g
con i = 1; : : : ; m y k = 1; : : : ; m0 , siendo m y m0 las cardinalidades de R y R0 respectivamente,
y siendo n el grado de ambas relaciones1 .
Entonces, la Interseccion Difusa Cuali cada de R y R0 , sera igual a R, modi cando
los grados de compatibilidad de sus atributos:
8H
>
< \ f(A1 : D1 ; C1 ); : : : ; (An : Dn; Cn)g
= (
B\v Q = Bv = f(A1 : dei1); : : : ; (An : dein )g
Q
0
R \Q R = > B (3.2)
: \ Q = B\c Q = fc00i1 ; : : : ; c00in g
1 Los conceptos de relacion, cardinalidad y grado fueron introducidos en la De nicion 1.6 y el concepto de
relacion difusa generalizada en la De nicion 2.2.
56 CAPITULO 3. DIVISION
 RELACIONAL DIFUSA

con i = 1; : : : ; m y donde Bv es la componente de valor (sin grados de compatibilidad) del


cuerpo, B, de R. Los grados de compatibilidad de la componente de compatibilidad B\c Q se
calculan de la siguiente forma:

c00iq = Ki 8q = 1; : : : ; n (3.3)
donde Ki es el grado de posibilidad de que la tupla i de R exista en R0 . Observese que, por
de nicion, siempre van a existir sus grados de compatibilidad Cq . Dichos valores, Ki , con
i = 1; : : : ; m, se calculan uno a uno de la siguiente forma: 8i = 1; : : : ; m

Ki = w=1max f min f= (deiq ; de0 wq )gg


;:::;m0 q=1;:::;n
(3.4)
donde = es un comparador difuso generalizado (ver De nicion 2.5) sobre D inducido por el
comparador extendido = (d; d0 )=(d; d0 ). tu
Observaciones:
 El comparador = sera usado para medir la igualdad de dos valores. Una de nicion de
este comparador, para distribuciones de posibilidad, podra ser, por ejemplo:

= (pe; pe0 ) = sup min (= (p; p0 ); pe(p); pe0 (p0 )) (3.5)


(p;p0 )2U U
= sup min (pe(d); pe0 (d)) (3.6)
d2U

donde pe; pe0 2 D, y sus distribuciones de posibilidad asociadas son pe y pe0 respectivamen-
te. U es el dominio de discurso sobre el que se construye el dominio difuso generalizado
D (ver De nicion 2.1). El comparador = se puede traducir por \posiblemente igual".
Para este comparador puede usarse otra de nicion, sobretodo si se emplea para compa-
rar escalares o distribuciones de posibilidad sobre escalares con una relacion de similitud
entre ellos. Por ejemplo, se puede utilizar una medida de necesidad, como la indicada
en la ecuacion 3.40. En el apartado 5.2.1.7 se da una de nicion de este comparador
para distribuciones de posibilidad sobre escalares con una relacion de similitud.
Nosotros, usaremos la de nicion anterior a lo largo de este captulo, aunque queremos
remarcar que este metodo es independiente del comparador empleado para evaluar la
igualdad entre valores difusos. Para determinados tipos de valores es posible que para
aplicar este metodo se requiera de nir previamente un comparador de igualdad para
ellos.
 Al aplicar la ecuacion 3.4, i es una constante que indica la tupla de R a la cual estamos
calculando su posibilidad, Ki , de que exista en R0 .
 Notese que para calcular los Ki los grados de compatibilidad de R y R0 no son tenidos
en cuenta porque ambas relaciones, R y R0 , son relaciones base de la base de datos y
por tanto no tienen atributos de compatibilidad.
3.2. DOS NUEVOS OPERADORES 57

 Se puede mejorar mucho la e ciencia del proceso de calcular los Ki , si entre los atributos
de R y R0 existen n0 atributos con dominios \crisp", con 1  n0  n (numericos o
escalares simples, esto es, tipos 1 y 2 de la Tabla 2.4). Si establecemos que esos n0
atributos sean los primeros, entonces, podemos cambiar la de nicion anterior haciendo
que:
8H
>
> \ = f(A1 : D1 ; C1 ); : : : ; (An0 : Dn0 ; Cn0 );
< Q

((Anv0 +1 : Dn0 +1v ); : : : ; (An :eDn)g


R \Q R0 = > B\Q = B = f(A1 : di1 ); : : : ; (An : dein0 )g (3.7)
>
: B\ Q = B\c Q = fc00i1 ; : : : ; c00in0 g
con i = 1; : : : ; m y donde Bv es la componente de valor (sin grados de compatibilidad)
del cuerpo, B, de R. Los grados de compatibilidad de la componente de compatibili-
dad B\c Q se calculan ahora de la siguiente forma, alterando solamente los atributos de
compatibilidad de los n0 primeros atributos (con dominios \crisp"):
 K si q 2 f1; : : : ; n0g
c00iq = i
0
ciq si q 2 fn + 1; : : : ; ng y 9Cq (3.8)

Los valores Ki , con i = 1; : : : ; m, se calculan uno a uno, para cada tupla i, en los
siguientes dos pasos: 8i = 1; : : : ; m
(a) Calcular una relacion, Ri , resultante de la siguiente seleccion (que no plantea
problemas ya que la condicion de seleccion es una igualdad sobre atributos \crisp"):
Ri = S (R0 ; A0q = deiq 8q = 1; : : : ; n0 ) (3.9)
(b) Calcular Ki aplicando la misma ecuacion 3.4, pero considerando ahora la relacion
Ri en vez de R0 y restringiendo el rango de q: Si llamamos deiwq a los valores de Ri,
entonces

Ki = w=1
max f min f=(deiq ; deiwq )gg
;:::;v q=n0+1;::: ;n
(3.10)
donde v es la cardinalidad de la relacion Ri . As, la funcion max se aplica solo a
v valores (en vez de a m0) y la funcion min solo se aplica cada vez a n n0 valores
(en vez de a n). Por tanto, para cada funcion min, el comparador = se aplica
solo a los valores de los n n0 atributos difusos.
 A la relacion resultante de la Interseccion Difusa Cuali cada podemos aplicarle un
umbral u 2 [0; 1], de forma que C1  u. As conseguimos que en el resultado nal esten
las tuplas de R que estan en R0 con posibilidad u como mnimo.
 La Interseccion Difusa Cuali cada no posee la propiedad conmutativa. La operacion
R \Q R0 expresa la posibilidad de que las tuplas de R esten en R0 y la operacion R0 \Q R
expresa la posibilidad de que las tuplas de R0 esten en R. Este operador es, en cierto
sentido, como una interseccion en una sola direccion.
58 CAPITULO 3. DIVISION
 RELACIONAL DIFUSA

H A B C
B A1 B1 C1
A1 B3 C2
A2 B2 C2
A2 B3 C2
A3 B3 C2
A3 B1 C3
Tabla 3.1: Ejemplo 3.1 de Interseccion Difusa Cuali cada: Relacion R.

H A B C
B A1 B1 C1
A1 B2 C1
A1 B2 C3
A2 B3 C3
A2 B1 C1
A3 B3 C3
A3 B2 C1
Tabla 3.2: Ejemplo 3.1 de Interseccion Difusa Cuali cada: Relacion R0 .

 Los grados de posibilidad calculados por las ecuaciones 3.4 y 3.10 son asignados a un
conjunto de atributos (con n y n n0 elementos cada uno respectivamente). Sin embargo,
el unico requisito indispensable es que sea asignado como mnimo a un atributo, para
que dicho valor sea conservado.
 Tambien es posible usar un comparador difuso generalizado inducido por otro compa-
rador extendido que no sea la igualdad (como \mayor que", \mucho mayor que"...). En
tal caso, vara el signi cado de la Interseccion Difusa Cuali cada R \Q R0 , que expresa
la posibilidad de que las tuplas de la relacion R esten relacionadas con las tuplas de
R0 de la forma que indique el comparador. Naturalmente, para simular la operacion
de division relacional difusa solo sera valido el uso de un comparador que exprese la
\igualdad".
El siguiente ejemplo ilustra el funcionamiento de este operador:
Ejemplo 3.1 Sean las relaciones difusas generalizadas R y R0 dadas por las Tablas 3.1 y 3.2
respectivamente. Supondremos que el atributo A es un atributo con dominio \crisp" y que
los atributos B y C son atributos difusos que usan las etiquetas lingusticas de la Figura 3.1.
Si calculamos ahora la Interseccion Difusa Cuali cada R \Q R0 el resultado es el que se
encuentra en la Tabla 3.3. En dicha Tabla hemos expresado tambien las operaciones por las
que se obtienen los valores de CA (obviamente ese calculo no aparecera en la relacion nal).
El calculo de CA de la Tabla 3.3 expresa la ecuacion 3.10 desarrollada. Los valores
numericos se obtienen al aplicar el comparador difuso generalizado = (ecuacion 3.5) so-
bre las etiquetas lingusticas de los atributos B y C (Figura 3.1). Cada funcion min actua
sobre dos valores porque hay dos atributos con dominios difusos (B y C). Cada funcion max
3.2. DOS NUEVOS OPERADORES 59

B
B1 B2 B3
1

0.75

0.5

0
1 2 3 4 5 6 7 8 9 10 11

C
1
C1 C2 C3

0.66

0.25

0
1 2 3 4 5 6 7 8 9 10 11

Figura 3.1: Ejemplo 3.1 de Interseccion Difusa Cuali cada: De nicion de etiquetas sobre los
atributos B y C.
60 CAPITULO 3. DIVISION
 RELACIONAL DIFUSA

H A CA (Calculo de CA ) B C
B A1 1 = maxfminf1,1g, minf0.5,1g, minf0.5,0gg B1 C1
A1 0.66 = maxfminf0,0.66g, minf0.75,0.66g,minf0.75,0.25gg B3 C2
A2 0.5 = maxfminf0.75,0.25g, minf0.5,0.66gg B2 C2
A2 0.25 = maxfminf1,0.25g, minf0,0.66gg B3 C2
A3 0.66 = maxfminf1,0.25g, minf0.75,0.66gg B3 C2
A3 0 = maxfminf0,1g, minf0.5,0gg B1 C3
Tabla 3.3: Ejemplo 3.1: Relacion R \Q R0 , con el calculo de CA .

H A CA B C
B A1 1 B1 C1
A1 0.66 B3 C2
A3 0.66 B3 C2
Tabla 3.4: Ejemplo 3.1: Resultado de aplicar el umbral 0.6 a R \Q R0 .

actua sobre tantos valores como tuplas se obtengan en la seleccion de la ecuacion 3.9 (tuplas
de R0 cuyo valor del atributo A sea igual al valor del atributo A de la tupla que estamos
calculando su CA ). En R0 hay tres tuplas con el valor A1, dos con el valor A2 y dos con el
valor A3. Por tanto, como se expresa en la Tabla 3.3, en las tuplas con A1 la funcion max
actua sobre tres valores y en las tuplas con A2 o A3 la funcion max actua sobre dos valores.
El valor del atributo CA para una tupla concreta expresa la posibilidad de que esa tupla
se encuentre en la relacion R0 . As, vemos que el grado de compatibilidad CA para la tupla
(A1,B1,C1) es de 1, ya que esa tupla tambien se encuentra exactamente igual en R0 . Para
la tupla (A1,B3,C2), la compatibilidad es 0.66 por su \parecido" con la tupla (A1,B2,C1) de
R0. Igualmente (A3,B1,C3) tiene compatibilidad 0 porque no hay posibilidad de que dicha
tupla se encuentre en R0 .
Podemos aplicar un umbral a CA para obtener solo las tuplas cuya posibilidad de pertenecer
a R0 sea 0.6 como mnimo. El resultado de aplicar este umbral esta en la Tabla 3.4. tu
Para una explicacion mas detallada del calculo de este operador vease el Ejemplo 3.5, mas
adelante en la seccion 3.4.
3.2.2 Proyeccion Difusa Generalizada con Funciones de Grupo F : P F
De nicion 3.2 Supongamos que tenemos los siguientes cuatro elementos, de nidos como
sigue:
1. Una relacion difusa generalizada R dada por:

H = f(A1 : D1 [; C1 ]); : : : ; (An : Dn [; Cn ])g


R= B = f(A1 : der1 [; cr1 ]); : : : ; (An : dern [; crn ])g
con r = 1; 2; : : : ; m, siendo m el numero de tuplas (la cardinalidad) de la relacion.
3.2. DOS NUEVOS OPERADORES 61

2. Una lista de elementos de H, X , no necesariamente distintos, que notaremos como:

X = fx1 ; : : : ; x g : xi 2 H; 8i = 1; : : : ;
3. Un subconjunto de H, X 0 , compuesto por atributos de nidos sobre dominios \crisp"
(tipos 1 y 2 de la Tabla 2.4). Si al numero de elementos de X 0 le llamamos , a este
subconjunto lo notaremos como:
X 0  H : X 0 = fx01 ; : : : ; x0 g
En X 0 , como en cualquier conjunto, no se admiten elementos duplicados. Los elementos
de X y X 0 pueden ser atributos normales o atributos de compatibilidad.
4. Una lista de Funciones de Grupo2 , F , de nidas sobre los elementos de X . Por tan-
to, la lista F tiene elementos, donde cada elemento es una funcion de grupo (no
necesariamente distinta) de nida sobre cada uno de los atributos de X respectivamente:
F = fgfunc1; : : : ; gfunc g
Considerando que la Proyeccion Difusa Generalizada de R sobre X 0 viene dada por:
(
R0 = P (R; X 0 ) = H0 = X 0 (3.11)
B0 = f(x01 : de0 t1 ); : : : ; (x0 : de0t )g
con t = 1; : : : ; m0 , siendo m0 el numero de tuplas de la proyeccion.
Entonces, con base a los elementos anteriores, de nimos la Proyeccion Difusa Gene-
ralizada de R sobre X 0, con Funciones de Grupo F sobre X , como una relacion difusa
generalizada dada por:
8 F
>
< HFP = fX 0 :x01 ; : : : ; X 0 :x0 ; X:x1 ; : : : ; X:x g
F 0
P (R; X ; X ) = > BP = f(X 0 :x01 : de0 t1 ); : : : ; (X 0 :x0 : de0 t ); (3.12)
: (X:x1 : deFt1 ); : : : ; (X:x : deFt )g
con t = 1; : : : ; m0 , siendo m0 el numero de tuplas de esa proyeccion y donde los de0 tj con
j = 1; : : : ; son los valores que se obtienen aplicando la proyeccion P (R; X 0 ) expresada
anteriormente (por eso los notamos igual).
Los deFti se obtienen aplicando la siguiente ecuacion:

8t = 1; : : : ; m0 ; 8i = 1; : : : ; : deFti = gfunci fR:deri : r = 1; : : : ; mg (3.13)


R0 :de0 tj =R:de0 rj ;8j =1;:::;

donde los R:de0 rj con j = 1; : : : ; son los valores de X 0 en la r-exima tupla de R. tu


62 CAPITULO 3. DIVISION
 RELACIONAL DIFUSA

FOR := 1 TO 0 DO
t m (* Para cada tupla *)
i
FOR := 1 TO DO (* Para cada atributo de *) X
:= G ; (* Se inicializa un grupo (o lista) G *)
FOR r
:= 1 TO DO m (* Se recorren las tuplas de *) R
IF ( 0 0 e
R :d
t1 = R:de
0 r1 AND 0R :de
0 t2 = 0 R:de
r2 AND AND 0 
0 t = R :de R:de0 r )
G := G [ R:deri (* Se a~
nade un elemento al grupo *)
END IF
END FOR
ti de
F := gfunc
i fGg (* Se calcula la funci
on de grupo sobre G *)
END FOR
END FOR

Figura 3.2: Algoritmo para el computo de los resultados de las Funciones de Grupo.

La ecuacion 3.13 puede calcularse a traves del algoritmo de la Figura 3.2. Esa ecuacion,
al igual que el algoritmo, aplica la funcion de grupo gfunci a los valores del atributo xi 2 X
de R de aquellas tuplas que cumplan que los valores de los atributos X 0 sean iguales a los de
R0. Esta igualdad se entiende en el sentido clasico ya que los elementos de X 0 son \crisp".
Es posible elaborar una version mas e ciente (en tiempo) de ese algoritmo, pero la que
aqu exponemos es mas clara e intuitiva.
Los ultimos elementos de HPF (sobre los que actuan las funciones de grupo de F ), pueden
expresarse mediante una variante en la que se hace referencia a la funcion de grupo espec ca
que actua sobre el atributo. En este caso, podemos eliminar la etiqueta de los elementos de
X 0:

HPF = fx01 ; : : : ; x0 ; gfunc1(x1 ); : : : ; gfunc (x )g (3.14)


A continuacion exponemos un sencillo ejemplo que clari ca la utilizacion de la Proyeccion
Difusa Generalizada con Funciones de Grupo:
Ejemplo 3.2 Sean los siguientes 4 elementos:
1. Una relacion difusa generalizada R dada por la Tabla 3.5. Hemos considerado todos sus
atributos con dominios \crisp" para simpli car el ejemplo.
2. Una lista de elementos de H, X , con 3 elementos:

X = fB; B; Cg
2 Por Funciones de Grupo (o de Agregacion) entendemos aquellas funciones que se aplican a un grupo nito
de valores dando como resultado un unico valor. Los ejemplos mas tpicos de funciones de grupo son las que se
usan para contar el numero de elementos del grupo (count), calcular el valor maximo (max), el mnimo (min),
la suma (sum), la media (avg), la varianza (variance), la desviacion tpica (stddev)... Todas las funciones
anteriores estan de nidas en el lenguaje SQL: Ver seccion 1.2.5.1 y Tabla 1.2.
3.2. DOS NUEVOS OPERADORES 63

H A B C
B A1 0.5 1
A1 0.6 2
A1 0.7 3
A2 0.3 4
A2 0.5 5
A3 0.1 6
Tabla 3.5: Ejemplo 3.2: Relacion R.

H A min(B) avg(B) sum(C)


B A1 0.5 0.6 6
A2 0.3 0.4 9
A3 0.1 0.1 6
Tabla 3.6: Ejemplo 3.2: Resultado de P F (R; X ; X 0 ).

3. Un subconjunto de H, X 0 , con un elemento:


X 0 = fA g
4. Una lista de Funciones de Grupo, F , de nidas sobre los elementos de X . Por tanto, la
lista F tendra 3 elementos (las funciones mnimo, media y suma de un grupo):

F = fmin; avg; sumg


Si con los datos anteriores calculamos la Proyeccion Difusa Generalizada de R sobre el
conjunto de atributos X 0 , con las funciones de grupo F sobre los atributos de X ,

P F (R; X 0 ; X ) = P fmin;avg;sumg(R; fAg; fB; B; Cg)


obtendremos la relacion que se expresa en la Tabla 3.6. La cabecera esta expresada en el
formato de la ecuacion 3.14. tu
La capacidad de la Proyeccion Difusa Generalizada con Funciones de Grupo para resolver
facilmente cuestiones que, de otra forma, seran mas complicadas, se ilustra mediante el
siguiente ejemplo:
Ejemplo 3.3 Sea una base de datos sobre alumnos, con una relacion R con los atributos
(ALUMNO, ASIGNATURA, NOTA...), donde el atributo NOTA admite valores difusos (Bueno,
Malo...). Supongamos que deseamos averiguar lo siguiente:
 Que alumnos son Buenos (con grado mnimo 0.8) en 2 o mas asignaturas.
64 CAPITULO 3. DIVISION
 RELACIONAL DIFUSA

Entonces, si = es el comparador difuso generalizado de nido en la ecuacion 3.5, el proceso


a seguir es simple:
1. R0 = S (R; = (NOTA; Bueno)  0:8)
2. R00 = P fcountg (R0 ; ALUMNO; NOTA)
3. S (R00 ; count(NOTA)  2)
El resultado que buscamos lo obtenemos en el ultimo paso. tu
Con la misma tecnica del ejemplo anterior se pueden resolver cuestiones mas complicadas:
 Que alumnos son Buenos en 2 asignaturas y Malos en 3 asignaturas.
Para una explicacion mas detallada del calculo de este operador vease el Ejemplo 3.5, mas
adelante en la seccion 3.4.
3.2.2.1 Consideraciones Adicionales
La Proyeccion Difusa Generalizada de R sobre el conjunto de atributos X 0 , con Funciones
de Grupo F sobre los atributos de X , P F (R; X 0 ; X ), modela en algebra relacional difusa
generalizada lo que en SQL (apartado 1.2.5) se efectua con la clausula GROUP BY de una
sentencia SELECT. Recordemos que en una consulta con la clausula GROUP BY, todos los ele-
mentos expresados despues de la palabra SELECT deben ser elementos de la clausula GROUP
on P F (R; X 0 ; X )
BY, elementos conteniendo funciones de grupo, o constantes. As, la proyecci
podra ser facilmente traducida a una sentencia SELECT de SQL, actuando cada clausula sobre
los siguientes elementos:
 SELECT: Los elementos seleccionados, sobre los que se proyectara, seran los del conjunto
X 0 y cada una de las funciones de F sobre cada uno de los atributos de X respectiva-
mente.
 FROM: La relacion R.
 GROUP BY: En esta clausula apareceran todos los atributos de X 0 .
Como hemos indicado, los atributos de X pueden tener dominios difusos. En ese caso,
las funciones de grupo de F correspondientes a dichos atributos deberan estar de nidas sobre
dichos dominios. De esta forma podremos calcular el valor mnimo de un grupo de numeros
difusos, el maximo...
Ejemplo 3.4 El paso 2 del Ejemplo 3.3, se especi cara en SQL como:
SELECT ALUMNO, Count(NOTA)
FROM R'
GROUP BY ALUMNO;

El resultado sera una relacion con dos atributos, con el nombre de los alumnos y el numero
de notas de cada uno en R0 . tu
 RELACIONAL DIFUSA GENERALIZADA: 
3.3. DIVISION 65

Los elementos de X 0 son atributos con dominios \crisp". Tambien podra contener atri-
butos con dominios difusos, si adoptamos un criterio para saber cuando considerar que dos
valores de un atributo son iguales. De esta forma, en la proyeccion de la ecuacion 3.11 habra
que aplicar ese criterio para eliminar las tuplas redundantes. Ademas, en la ecuacion 3.13 (y
en su algoritmo) habra tambien que aplicar dicho criterio para ver la igualdad de todos los
valores de los atributos de X 0 (en R y R0 ).

3.3 Division Relacional Difusa Generalizada: 


En este apartado vamos a dar primero la de nicion de nuestra propuesta de Division Difusa
y posteriormente damos una justi cacion para esta division, comparandola con la formula
clasica de la Division Relacional (ecuacion 1.4).
3.3.1 De nicion
De nicion 3.3 Sean R y R0 dos relaciones difusas generalizadas, dadas por:
H = f(A1 : D1 [; C1 ]); : : : ; (An0 : Dn0 [; Cn0 ]); : : : ; (An : Dn [; Cn ])g
R= B = f(A1 : dei1 [; ci1 ]); : : : ; (An0 : dein0 [; cin0 ]); : : : ; (An : dein [; cin ])g
 H0 = f(A0n0 +1 : Dn0 +1 [; Cn0 +1 ]); : : : ; (A0n : Dn [; Cn ])g
R0 = B0 = f(A0n0 +1 : de0 kn0+1 [; c0kn0 +1]); : : : ; (An : de0 kn [; c0kn ])g
con i = 1; : : : ; m y k = 1; : : : ; m0 , siendo m y m0 las cardinalidades de R y R0 respectivamente
y donde n y n n0 son los respectivos grados.
Ademas, tenemos que 1  n0 < n, tal que los Dj , con j = 1; : : : ; n0 , son dominios \crisp":
numerico o escalar simple (tipos 1 y 2 de la Tabla 2.4).
Entonces, de nimos la Division Relacional Difusa Generalizada de R entre R0 ,
notada por R  R0 , como otra relacion difusa generalizada obtenida por la aplicacion de las
siguientes operaciones:
1. Se calcula la relacion R00 de la siguiente forma:

R00 = P (R; A)  R0 (3.15)


con A = fA1 ; : : : ; An0 g. La proyeccion sobre A no plantea problemas, ya que hemos
supuesto que todos los atributos de A tienen dominios \crisp".
2. Se aplica la Interseccion Difusa Cuali cada entre R00 y R:
R000 = R00 \Q R (3.16)
Para esta operacion, consideramos que el numero n0 de esta de nicion tiene el mismo
valor que el numero n0 mencionado en la de nicion de la Interseccion Difusa Cuali cada
(ecuaciones 3.7, 3.8, 3.9 y 3.10).
66 CAPITULO 3. DIVISION
 RELACIONAL DIFUSA

3. Los resultados de nitivos se obtienen aplicando la Proyeccion Difusa Generalizada de


R000 sobre A, con Funciones de Grupo F sobre C :

R  R0 = P F (R000; A; C ) (3.17)
donde C = fC1 ; : : : ; Cn0 g son todos los atributos de compatibilidad asociados a los
atributos de A, y F es una lista de n0 funciones, todas ellas iguales, correspondientes a
la funcion de grupo \mnimo" ( min):
F = fmin; :n:0:; ming (3.18)
La Proyeccion con Funciones de Grupo del ultimo paso no plantea ninguna problematica,
ya que tanto A como C son conjuntos de atributos con dominios \crisp". tu
La Division Relacional Difusa Generalizada es una extension de la Division Relacional
clasica sobre atributos \crisp" y, por tanto, incluye a esta. O sea, sobre relaciones clasicas
(sin atributos difusos), ambas obtienen identicos resultados (aunque de distinta forma). En
otras palabras, en bases de datos clasicas esta sera tambien otra forma de calcular la division
relacional.
3.3.2 Justi cacion de la Division Difusa Generalizada y Comparacion con
la Formula Clasica de la Division Relacional
La Division Difusa que aqu presentamos funciona de manera similar a la formula clasica de
la Division Relacional, expresada en la ecuacion 1.4 que aqu reproducimos:
R  R0 = A(R) A ((A (R)  R0 ) R)
Para elaborar la Division Difusa nos hemos basado en la formula clasica, solucionando los
problemas que aparecan por la naturaleza imprecisa de los datos que manejamos.
Para aplicar la formula clasica en R  R0 lo primero que hace es calcular A (R)  R0
(siendo A los atributos de R que no son comunes a R0 ). Esta operacion se aplica de la misma
forma en la Division Difusa, en la ecuacion 3.15. Con esta operacion conseguimos una
relacion (R00 ) con todas las tuplas sobre las que evaluaremos su existencia en R. En esta
operacion es realmente donde se aplica el cuanti cador universal (8), porque, para cada valor
del conjunto de atributos A, tendremos en R00 todos los valores que buscaremos en R.
A continuacion, la formula clasica aplica el operador Diferencia Relacional: R00 R. Con
esta operacion eliminamos del conjunto de todas las tuplas que buscamos, las que realmente
existen en R. As, obtenemos aquellas tuplas que buscabamos en R y que no existen en esa
relacion.
Si ahora proyectamos sobre A, obtendremos aquellas tuplas que no cumplen las condiciones
de la Division Relacional. Para obtener las que s las cumplen basta restar a todas las tuplas
de A (R), aquellas que no las cumplen.
En Bases de datos difusas el primer problema se plantea al aplicar la diferencia relacional:
R R. La di cultad radica en determinar en que medida una tupla de R00 pertenece o no a
00
R, ya que en ambas relaciones pueden haber tuplas que no sean iguales pero si parecidas.

3.4. UN EJEMPLO PRACTICO  RELACIONAL DIFUSA
DE DIVISION 67

Para solventar este problema introducimos la Interseccion Difusa Cuali cada que aplica-
mos en la ecuacion 3.16. Este operador tiene una diferencia semantica con respecto a la
diferencia relacional: Mientras que la diferencia relacional, R00 R, devuelve las tuplas de
R00 que no pertenecen a R, la Interseccion Difusa Cuali cada, R00 \Q R, devuelve el grado de
posibilidad de que las tuplas de R00 pertenezcan a R. Si dicho grado es 1 indica que esa tupla
pertenece a ambas relaciones, si es 0 es que esa tupla pertenece solo a R00 y cualquier grado
intermedio representa una posibilidad intermedia.
Como la Interseccion Difusa Cuali cada devuelve los valores de manera inversa a la dife-
rencia relacional, nos evitamos tener que efectuar la ultima Diferencia de la formula clasica, la
cual daba la vuelta a los valores obtenidos, como hemos visto. Recordemos que, en el sentido
clasico, una interseccion equivale a dos diferencias: R \ S = R (R S ).
En este punto, solo queda proyectar la relacion R000 sobre los atributos A. Esto plantea un
nuevo problema, pues para cada valor A puede haber varios grados de posibilidad distintos
asociados a el. Por ello, aplicamos la Proyeccion Difusa con Funciones de Grupo, ecuacion
3.17, tomando el valor mnimo de todos los asociados a un mismo valor de A. Como buscamos
los valores de A que estan relacionados (en R) con todos los valores de R0 , tomamos la T-
norma del mnimo en todas las Funciones de Grupo de F .

3.4 Un Ejemplo Practico de Division Relacional Difusa


Vamos a exponer un ejemplo simple pero signi cativo que muestre la forma en que se aplica
la Division Difusa Generalizada y su capacidad expresiva:
Ejemplo 3.5 Supongamos que tenemos una base de datos Relacional Difusa sobre jugadores
de baloncesto. Una relacion de la base de datos podra tener los atributos (JUGADOR, EQUIPO,
ALTURA, CALIDAD, NUM_CAMISETA...). Los campos ALTURA (que almacena la altura del
jugador) y CALIDAD (que mide la calidad del jugador segun el numero de puntos medio por
partido), permiten almacenar valores difusos (tipo 6 de la Tabla 2.4). Nosotros, para el
ejemplo, usaremos las etiquetas lingusticas de la Figura 3.3.
Hemos eliminado las etiquetas \Muy Bajo" y \Muy Malo", por considerar que profesio-
nalmente no juegan jugadores de esas caractersticas.
En este contexto, vamos a encontrar los equipos de baloncesto que poseen una plantilla
con todos los tipos de jugadores (en ALTURA y CALIDAD) de los que dispone el equipo de
Cordoba.
Para encontrar dichos equipos, primero tomaremos una proyeccion de la relacion anterior
sobre los atributos que nos interesan (EQUIPO, ALTURA y CALIDAD), quedando la relacion R
que muestra la Tabla 3.7. Esta tabla no tiene atributos de compatibilidad puesto que solo
hemos efectuado la proyeccion sobre una relacion base.
Obtenemos una segunda relacion R0 mediante la proyeccion sobre los atributos ALTURA
y CALIDAD despues de haber efectuado una seleccion con la condicion EQUIPO=Cordoba. En
nuestro ejemplo, R0 contendra solo dos tuplas. Esta relacion puede verse en la Tabla 3.7.
Antes de exponer el calculo de la Division Difusa Generalizada R  R0 , realizaremos una
serie de observaciones de caracter intuitivo acerca de los resultados que cabran esperar.
Si observamos ambas relaciones, podemos ver que en R tenemos que el equipo de Granada
cumple con las condiciones de dicha division. Obviamente, el equipo de Cordoba tambien.
Ambos equipos tienen dos tuplas con los mismos valores que R0 en los atributos ALTURA y
CALIDAD.
68 CAPITULO 3. DIVISION
 RELACIONAL DIFUSA

ALTURA
Bajo Normal Alto Muy Alto
1

0.5

0
170 175 180 185 190 195 200 205 210 cm.

CALIDAD
Malo Regular Bueno Muy Bueno
1

0.75

0.5

0
5 10 15 20 25 30 35 40 45 Puntos/Partido

Figura 3.3: Ejemplo 3.5 de Division Relacional: De nicion de etiquetas sobre los atributos
ALTURA y CALIDAD.

3.4. UN EJEMPLO PRACTICO  RELACIONAL DIFUSA
DE DIVISION 69

H EQUIPO ALTURA CALIDAD


B Cordoba Bajo Muy Bueno
Cordoba Muy Alto Malo
Granada Bajo Muy Bueno
Granada Muy Alto Malo
Granada Alto Regular
Malaga Bajo Muy Bueno
Malaga Alto Malo
Malaga Muy Alto Muy Bueno
Sevilla Bajo Bueno
Sevilla Muy Alto Malo
Sevilla Normal Bueno
Cadiz Muy Alto Muy Bueno
Cadiz Bajo Bueno
Almera Alto Muy Bueno
Almera Bajo Regular
Huelva Alto Muy Bueno
Tabla 3.7: Ejemplo 3.5 de Division Relacional: Relacion R.

H ALTURA CALIDAD
B Bajo Muy Bueno
Muy Alto Malo
Tabla 3.8: Ejemplo 3.5 de Division Relacional: Relacion R0 .
70 CAPITULO 3. DIVISION
 RELACIONAL DIFUSA

El equipo de Malaga tiene una tupla que coincide con una de R0 , (Bajo, Muy Bueno):
Con compatibilidad 1 en CALIDAD y 1 en ALTURA. La otra tupla de R0 , (Muy Alto, Malo), no
empareja directamente con ninguna otra tupla de Malaga. Sin embargo, vemos que no hay
muchas diferencias: La compatibilidad con la tupla (Malaga, Alto, Malo) es de 1 en CALIDAD
y de 0.5 en ALTURA (Alto y Muy Alto \se parecen", o son posiblemente iguales, con grado
0.5). Por tanto, parece logico que el equipo de Malaga debe aparecer en el resultado de la
division, pues cumple \en parte" con los requisitos.
Igualmente, el equipo de Sevilla tiene una tupla que coincide con una de R0 , (Muy Alto,
Malo). La otra tupla de R0 , (Bajo, Muy Bueno), no empareja directamente con ninguna otra
tupla de Sevilla, pero vemos que hay similitudes: La compatibilidad con la tupla (Sevilla,
Bajo, Bueno) es de 1 en ALTURA y 0.75 en CALIDAD (Bueno y Muy Bueno \se parecen" con
grado 0.75), y la compatibilidad con la tupla (Sevilla, Normal, Bueno) es de 0.5 en ALTURA
y 0.75 en CALIDAD. As, vemos que el equipo de Sevilla tambien cumple \en parte" con los
requisitos de la division.
Con el equipo de Cadiz se empareja la tupla (Cadiz, Bajo, Bueno) con la tupla (Bajo,
Muy Bueno) de R0 (con grados 1 y 0.75 en ALTURA y CALIDAD respectivamente). Sin embargo,
la otra tupla de R0 , (Muy Alto, Malo), no se empareja con ninguna otra de Cadiz (si en
ALTURA, pero en absoluto en CALIDAD). Por eso, parece obvio que el resultado debera indicar
que Cadiz no cumple los requisitos necesarios para estar en la relacion de la Division.
Por ultimo, los equipos de Almera y Huelva no cumplen claramente con los requisitos de
la Division.
Despues de este estudio informal acerca de los resultados esperados, pasemos a ver como
se comporta la Division Difusa Generalizada que hemos de nido. Para calcular R  R0 ,
calcularemos las siguientes ecuaciones:
1. Ecuacion 3.15: Calculamos R00 de la siguiente forma:

R00 = P (R; EQUIPO)  R0 (3.19)


obteniendo la relacion que se expresa en la Tabla 3.9.
2. Ecuacion 3.16: Calculamos la Interseccion Difusa Cuali cada, R00 \Q R, teniendo en
cuenta que hay un atributo con dominio \crisp" (EQUIPO). As, obtenemos la relacion
R000 de la tabla 3.10. En el campo CEQUIPO tenemos la posibilidad de que las tuplas de
R00 esten en R. En esta Tabla, hemos incluido las operaciones por las que se obtienen
esos valores aplicando la ecuacion 3.10. Los valores a los que afectan las funciones min
son los resultados de aplicar el comparador difuso generalizado de la ecuacion 3.5.
Para aclarar el funcionamiento de la Interseccion Difusa Cuali cada vamos a efectuar
paso a paso el calculo de CEQUIPO para las dos tuplas del equipo de Granada y para las
dos del equipo de Cadiz:
 Calculo de CEQUIPO para la tupla (Granada, Bajo, Muy Bueno) de R000. Como esta
tupla es la tercera, tenemos que i = 3. Los pasos a seguir son los siguientes:
(a) Hallar la seleccion de la ecuacion 3.9, sabiendo que n0 = 1:
R3 = S (R; EQUIPO = Granada)

3.4. UN EJEMPLO PRACTICO  RELACIONAL DIFUSA
DE DIVISION 71

H EQUIPO ALTURA CALIDAD


B Cordoba Bajo Muy Bueno
Cordoba Muy Alto Malo
Granada Bajo Muy Bueno
Granada Muy Alto Malo
Malaga Bajo Muy Bueno
Malaga Muy Alto Malo
Sevilla Bajo Muy Bueno
Sevilla Muy Alto Malo
Cadiz Bajo Muy Bueno
Cadiz Muy Alto Malo
Almera Bajo Muy Bueno
Almera Muy Alto Malo
Huelva Bajo Muy Bueno
Huelva Muy Alto Malo
Tabla 3.9: Ejemplo 3.5 de Division Relacional: Relacion R00 = P (R; EQUIPO)  R0 .

H EQUIPO CEQUIPO (Calculo de CEQUIPO ) ALTURA CALIDAD


B Cordoba 1 = maxfminf1,1g, minf0,0gg Bajo Muy Bueno
Cordoba 1 =maxfminf0,0g, minf1,1gg Muy Alto Malo
Granada 1 =maxfminf1,1g, minf0,0g, minf0,0gg Bajo Muy Bueno
Granada 1 =maxfminf0,0g, minf1,1g, minf0.5,0.5gg Muy Alto Malo
Malaga 1 =maxfminf1,1g, minf0,0g, minf0,1gg Bajo Muy Bueno
Malaga 0.5 =maxfminf0,0g, minf0.5,1g, minf1,0gg Muy Alto Malo
Sevilla 0.75 =maxfminf1,0.75g, minf0,0g, minf0.5,0.75gg Bajo Muy Bueno
Sevilla 1 =maxfminf0,0g, minf1,1g, minf0,0gg Muy Alto Malo
Cadiz 0.75 =maxfminf0,1g, minf1,0.75gg Bajo Muy Bueno
Cadiz 0 =maxfminf1,0g, minf0,0gg Muy Alto Malo
Almera 0 =maxfminf0,1g, minf1,0gg Bajo Muy Bueno
Almera 0 =maxfminf0.5,0g, minf0,0.5gg Muy Alto Malo
Huelva 0 =maxfminf0,1gg Bajo Muy Bueno
Huelva 0 =maxfminf0.5,0gg Muy Alto Malo
Tabla 3.10: Ejemplo 3.5 de Division Relacional: Relacion R000 = R00 \Q R, con el calculo de
CEQUIPO .
72 CAPITULO 3. DIVISION
 RELACIONAL DIFUSA

H EQUIPO ALTURA CALIDAD


B Granada Bajo Muy Bueno
Granada Muy Alto Malo
Granada Alto Regular
Tabla 3.11: Ejemplo 3.5 de Division Relacional: Relaciones intermedias R3 y R4 .

de donde obtenemos la relacion de la Tabla 3.11.


(b) Calcular K3 (que sera el valor de CEQUIPO para esa tupla), segun la ecuacion
3.10, teniendo en cuenta que v = 3 porque en la seleccion anterior se seleccio-
naron 3 tuplas (cardinalidad de R3 ):
K3 = max f min
w=1;:::;3 q=ALTURA;CALIDAD
f= (de3q ; de3wq )gg
= max fminf= (de3(ALTURA) ; de3w(ALTURA) ); = (de3(CALIDAD ) ; de3w(CALIDAD) )gg
w=1;:::;3
= max fminf= (Bajo; de3w(ALTURA) ); = (Muy Bueno; de3w(CALIDAD) )gg
w=1;:::;3
= maxfminf= (Bajo; Bajo); = (Muy Bueno; Muy Bueno)g;
minf= (Bajo; Muy Alto); = (Muy Bueno; Malo)g;
minf= (Bajo; Alto); = (Muy Bueno; Regular)gg
= maxfminf1; 1g; minf0; 0g; minf0; 0gg
= 1
donde = es el comparador difuso generalizado de la ecuacion 3.5.
 Calculo de CEQUIPO para la tupla (Granada, Muy Alto, Malo) de R000 (i = 4):
(a) Hallar la seleccion de la ecuacion 3.9, R4 , que es la misma que la del punto
anterior y su resultado es tambien la relacion de la Tabla 3.11.
(b) Calcular K4 (que sera el valor de CEQUIPO para esa tupla), segun la ecuacion
3.10, teniendo en cuenta que v = 3 porque en la seleccion anterior se seleccio-
naron 3 tuplas:
K4 = max fminf= (Muy Alto; de4w(ALTURA) ); = (Malo; de4w(CALIDAD) )gg
w=1;:::;3
= maxfminf= (Muy Alto; Bajo); = (Malo; Muy Bueno)g;
minf= (Muy Alto; Muy Alto); = (Malo; Malo)g;
minf= (Muy Alto; Alto); = (Malo; Regular)gg
= maxfminf0; 0g; minf1; 1g; minf0:5; 0:5gg
= 1
 Calculo de CEQUIPO para la tupla (Cadiz, Bajo, Muy Bueno) de R000 (i = 9):
(a) Hallar la seleccion de la ecuacion 3.9:
R9 = S (R; EQUIPO = Cadiz)
de donde obtenemos la relacion de la Tabla 3.12.

3.4. UN EJEMPLO PRACTICO  RELACIONAL DIFUSA
DE DIVISION 73

H EQUIPO ALTURA CALIDAD


B Cadiz Muy Alto Muy Bueno
Cadiz Bajo Bueno
Tabla 3.12: Ejemplo 3.5 de Division Relacional: Relaciones intermedias R9 y R10 .

(b) Calcular K9 (que sera el valor de CEQUIPO para esa tupla), segun la ecuacion
3.10, teniendo en cuenta que ahora v = 2 porque en la seleccion anterior se
seleccionaron solo 2 tuplas:
K9 = wmax =1;2
fminf=(Bajo; de9w(ALTURA) ); =(Muy Bueno; de9w(CALIDAD))gg
= maxfminf= (Bajo; Muy Alto); = (Muy Bueno; Muy Bueno)g;
minf= (Bajo; Bajo); = (Muy Bueno; Bueno)gg
= maxfminf0; 1g; minf1; 0:75gg
= 0:75
 Calculo de CEQUIPO para la tupla (Cadiz, Muy Alto, Malo) de R000 (i = 10):
(a) Hallar la seleccion de la ecuacion 3.9, R10 , de donde obtenemos, igual que
antes, la relacion de la Tabla 3.12.
(b) Calcular K10 (que sera el valor de CEQUIPO para esa tupla), segun la ecuacion
3.10:
K10 = wmax
=1;2
fminf= (Muy Alto; de10w(ALTURA) ); =(Malo; de10w(CALIDAD) )gg
= maxfminf= (Muy Alto; Muy Alto); = (Malo; Muy Bueno)g;
minf= (Muy Alto; Bajo); = (Malo; Bueno)gg
= maxfminf1; 0g; minf0; 0gg
= 0
3. Ecuacion 3.17: Siguiendo con el proceso general de la Division Difusa, y para terminar,
efectuamos la Proyeccion Difusa Generalizada de R000 sobre el atributo EQUIPO, con
Funcion de Grupo \mnimo" (min) sobre el atributo CEQUIPO :

R  R0 = P fming (R000 ; EQUIPO; CEQUIPO ) (3.20)

El resultado nal de la division puede verse en la Tabla 3.13. tu


A la relacion resultante de la Division Difusa Generalizada se le puede aplicar una seleccion
de forma que CEQUIPO  u, donde u 2 [0; 1] es un umbral. De esta forma, si en el ejemplo
anterior, establecemos u = 0:7, no obtendremos las tuplas de los equipos de Malaga, Cadiz,
Almera y Huelva.
Se podra haber de nido la Division Difusa Generalizada para que no se obtuvieran aque-
llas tuplas en las que CEQUIPO = 0, pero de la forma de nida obtenemos mas informacion, ya
que as podemos saber los equipos que no cumplen en absoluto los requisitos de la division.
74 CAPITULO 3. DIVISION
 RELACIONAL DIFUSA

H EQUIPO CEQUIPO
B Cordoba 1
Granada 1
Malaga 0.5
Sevilla 0.75
Cadiz 0
Almera 0
Huelva 0
Tabla 3.13: Ejemplo 3.5 de Division Relacional: Relacion resultante de R  R0 .

H ALTURA
B Bajo
Normal
Tabla 3.14: Ejemplo 3.6 de Division Relacional: Relacion R0 .

3.5 Problemas que se Plantean y Posibles Soluciones


Hay un caso particular para el que la Division Difusa Generalizada puede parecer no compor-
tarse correctamente. Este caso se da cuando, al hacer la division (R  R0 ), una misma tupla
de R se relaciona con todas o parte de las tuplas de R0 .
Siguiendo en el mismo contexto que el Ejemplo 3.5 de la base de datos sobre equipos de
baloncesto, vamos a ver un ejemplo en el que se da este caso:
Ejemplo 3.6 Supongamos que buscamos los equipos que tienen al menos un jugador \Bajo"
y al menos un jugador de altura \Normal". En este caso, R0 sera una relacion de cardinalidad
2, con el unico atributo ALTURA, como se muestra en la Tabla 3.14.
Imaginemos, por ejemplo, que el equipo de Jaen tiene todos sus jugadores \Muy Altos",
menos uno que es \Normal". En este caso, el resultado de la division devolvera ese equipo
en una tupla con grado de posibilidad 0.5 (minf0.5,1g), obtenido al aplicar la Proyeccion con
Funciones de Grupo (ecuacion 3.20) a la relacion R000 de la Tabla 3.15. tu
En el ejemplo anterior se ve que la Division Difusa devuelve un equipo que se relaciona
solo con una tupla de las dos de R0 , ya que ese equipo no tiene ningun jugador \Bajo", por lo
que podra ser conveniente que no se devolviera. El problema estriba en que hemos utilizado
un denominador poco discriminador, al estar demasiado proximos los valores de \Bajo" y
\Normal".
Este tipo de problemas es tpico al manejar datos imprecisos. Si tenemos datos difusos,
los resultados tambien lo seran y deberan interpretarse como tales. Ademas, siempre sera
posible hacer otras consultas a la Base de Datos para conseguir mas informacion.
Podemos encontrar una solucion al problema anterior, pero no sabemos hasta que punto es
aconsejable, pues al solucionar ese problema estamos impidiendo que se muestre informacion
que pudiera ser util.
Una solucion podra ser que al efectuar la Interseccion Difusa Cuali cada, en cada grupo,
las tuplas de R solo pueden usarse una vez donde obtengan mayor grado de posibilidad. De
 DEL CUANTIFICADOR EN LA DIVISION
3.6. RELAJACION  DIFUSA 75

H EQUIPO CEQUIPO (Calculo de CEQUIPO ) ALTURA

B ... ..
.
..
.
Jaen 0.5 = maxf0.5, 0, : : : ,0g Bajo
Jaen 1 = maxf1, 0, : : : ,0g Normal
.. .. ..
. . .
Tabla 3.15: Ejemplo 3.6 de Division Relacional: R000 (resultado de la Interseccion Difusa
Cuali cada).

H EQUIPO CEQUIPO (Calculo de CEQUIPO ) ALTURA

B ... ..
.
..
.
Jaen 0 = maxf0, : : : ,0g Bajo
Jaen 1 = maxf1, 0, : : : ,0g Normal
.. .. ..
. . .
Tabla 3.16: Resultado de la Interseccion Difusa modi cada, para el Ejemplo 3.6.

esta forma, en el Ejemplo 3.6, la relacion resultante de esta Interseccion Difusa modi cada es
la que se muestra en la Tabla 3.16. Puede observarse que el resultado de la comparacion con la
tupla con el valor \Normal" de R solo aparece una vez, donde obtiene el grado de posibilidad
1. Por tanto, el resultado nal sera que este equipo obtiene un grado de posibilidad cero en
la division (minf0,1g).
La Division Difusa modi cada (usando la Interseccion Difusa modi cada) aumenta con-
siderablemente el numero de calculos a efectuar de forma no justi cada para casos generales.
La mejor solucion al problema planteado esta en dos factores fundamentales:
1. Elegir (si es posible) cuidadosamente las etiquetas lingusticas de forma que la similitud
entre ellas no sea excesiva.
2. Usar un umbral, u, adecuado y seleccionar las tuplas cuyo grado de compatibilidad sea
mayor que u. Este umbral puede usarse al nal de calcular la Division Difusa.
Ademas, puede ser util comparar los resultados que se obtienen con distintos umbrales y
efectuar otras consultas similares a la base de datos.

3.6 Relajacion del Cuanti cador Universal en la Division Di-


fusa
Hasta ahora, hemos visto un sistema para calcular el resultado de la division relacional en
relaciones con atributos difusos. Esta division la hemos considerado desde el punto de vista
clasico, es decir, hemos considerado exclusivamente el cuanti cador universal \para todo"
(8) a la hora de calcular esta division. En este apartado vamos a exponer algunos metodos
para relajar ese cuanti cador y permitir usar cuanti cadores difusos tanto relativos como
absolutos. Los cuanti cadores difusos fueron explicados en el apartado 2.9.2.
76 CAPITULO 3. DIVISION
 RELACIONAL DIFUSA

Puede parecer que todos los cuanti cadores que pueden utilizarse para relajar el cuan-
ti cador universal de la division son cuanti cadores relativos, ya que estos dependen de las
tuplas existentes en la relacion del denominador de la division relacional. Ejemplos de estos
cuanti cadores son \todos", \casi todos", \la mayora", \aproximadamente la mitad", \la
minora"... Sin embargo, tambien pueden utilizarse cuanti cadores absolutos, que no depen-
dan del numero de tuplas del denominador. Ejemplos de cuanti cadores absolutos son \1 o
mas" (cuanti cador existencial), \mas de 5", \aproximadamente 5", \pocos"...
El cuanti cador existencial es una muestra de cuanti cador absoluto que puede utilizarse
en lugar del cuanti cador universal de la division. Para utilizar este cuanti cador, basta con
utilizar la funcion maximo en lugar de la funcion mnimo en la proyeccion con funciones de
grupo F de la ecuacion 3.17. Es decir, en vez de la de nicion de F de la ecuacion 3.18
utilizaramos la siguiente de nicion:

F = fmax; :n:0:; maxg (3.21)


Para cualquier otro cuanti cador absoluto Q, se puede aplicar la funcion de grupo suma
y a continuacion, aplicar la funcion del cuanti cador Q sobre el resultado obtenido:

F = fQ(sum); :n:0:; Q(sum)g (3.22)


Para un cuanti cador relativo Q, se puede calcular la media aritmetica (avg) y a conti-
nuacion, aplicar la funcion del cuanti cador Q sobre el resultado obtenido:

F = fQ(avg); :n:0:; Q(avg)g (3.23)


Ejemplo 3.7 Siguiendo con el Ejemplo 3.5, supongamos que queremos aplicar la division
relacional difusa con los siguientes cuanti cadores:
1. Cuanti cadzor existencial (9).
2. Cuanti cador absoluto \aproximadamente 2" de nido como una funcion triangular, de
la siguiente forma:
80
< si x  0 o si x  3
Q(x) = : x 1 si 1 < x  2
3 x si 2 < x < 3
3. Cuanti cador relativo \algunos", de nido como: Q(x) = x.
4. Cuanti cador relativo \casi todos", de nido como en la Figura 3.4.
5. Cuanti cador universal (8).
Entonces, el resultado de la division relacional difusa R  R0 con estos cuanti cadores es
el que se muestra en la Tabla 3.17. tu
Otro ejemplo de division difusa con cuanti cadores difusas es expuesto mas adelante en
el Ejemplo 3.15 (apartado 3.7.5).
 DEL CUANTIFICADOR EN LA DIVISION
3.6. RELAJACION  DIFUSA 77

Q
1

0
0.4 0.9 1
Figura 3.4: Cuanti cador difuso relativo \casi todos".

9
H EQUIPO CEQUIPO aprox: 2 C algunos C casi todos C 8
CEQUIPO EQUIPO EQUIPO EQUIPO
B Cordoba 1 1 1 1 1
Granada 1 1 1 1 1
Malaga 1 0.5 0.75 0.7 0.5
Sevilla 1 0.75 0.875 0.95 0.75
Cadiz 0.75 0 0.375 0 0
Almera 0 0 0 0 0
Huelva 0 0 0 0 0
Tabla 3.17: Ejemplo 3.7 de Division Difusa con cuanti cadores: Relacion resultante de R  R0.
78 CAPITULO 3. DIVISION
 RELACIONAL DIFUSA

3.7 Estudio Comparativo con otras Propuestas de Division


Difusa
En la bibliografa podemos encontrar algunas propuestas para efectuar la Division Relacional
en una Base de Datos Difusa. Generalmente estas propuestas usan un modelo de relaciones
difusas o un signi cado de los grados distinto al que nosotros empleamos (ver secciones 3.1 y
2.8). Ahora exponemos algunas de estas propuestas, comparandolas con la que aqu damos.

3.7.1 La Division de Mouaddib


En [114], Mouaddib propuso un metodo para efectuar la division relacional en bases de datos
difusas basada en la identi cacion de objetos que tuvieran similares caractersticas. Para ello,
usa un sistema de calcular la division valido en bases de datos tradicionales: Si tenemos la
relacion R(X; Y ) y S (Y ), donde los atributos Y de R y los de S estan de nidos en el mismo
dominio, entonces, la division relacional sera una relacion D(X ) que puede ser calculada de
la siguiente forma:

D(X ) = \Ri con i 2 [1; n] (3.24)


Ri (X ) = Ri0 [X ] (3.25)
Ri0 (X; Y ) = Select(R; Y = yi ) con yi 2 S (3.26)
donde n es el numero de elementos de S , \ es el operador de interseccion, [ ] es la proyeccion
sobre los atributos que haya dentro de los corchetes y el operador de seleccion se expresa con
la palabra Select.
En su modelo de bases de datos difusas, cada tupla tiene un valor 2 [0; 1] asociado, que
indica el grado con el que cada tupla pertenece a la relacion. Tambien puede verse como el
grado de certeza de cada tupla.

R f S = \f Ri con i 2 [1; n] (3.27)


Ri (X ) = Ri0 [X ]f (3.28)
Ri0 (X; Y ) = Selectf (R; Y = yi) con yi 2 S (3.29)
donde \f es el operador de interseccion difusa, [ ]f es la proyeccion difusa y el operador de
seleccion difusa lo expresa con la palabra Selectf .
Cada relacion difusa (R f S , Ri , Ri0 ) esta representada por una funcion caracterstica.
La funcion caracterstica asociada a R f S puede calcularse como sigue:

Rf S = min Ri (x) con x 2 DomX (3.30)


Ri (x) = u:X
max  0 (u) con u 2 Ri0
=x Ri
(3.31)
R0i (u) = min(u: ; max
y
min(yi (y); u:Y (y))) con y 2 DomY (3.32)

donde u: denota el grado de pertenencia de u a R y yi es un valor de S .


3.7. ESTUDIO COMPARATIVO CON OTRAS PROPUESTAS 79

Colores white whitish creme yellow yellowish red


white 1 0.8 0.4 0 0 0
whitish 0.8 1 0.5 0 0 0
creme 0.4 0.5 1 0 0 0
yellow 0 0 0 1 0.8 0
yellowish 0 0 0 0.8 1 0
red 0 0 0 0 0 1
Tabla 3.18: Ejemplo 3.8 de Division de Mouaddib: Similitud entre colores.

Mushroom Color
m1 white 1
m1 yellow 0.8
m1 red 0.7
m2 red 1
m3 whitish 0.6
m3 yellow 1
Tabla 3.19: Ejemplo 3.8 de Division de Mouaddib: Relacion R.

Color
whitish 1
yellowish 1
Tabla 3.20: Ejemplo 3.8 de Division de Mouaddib: Relacion S .
80 CAPITULO 3. DIVISION
 RELACIONAL DIFUSA

Ejemplo 3.8 Sean R y S las relaciones de las Tablas 3.19 y 3.20 respectivamente, sobre setas
(Mushrooms) y su color. Los colores son escalares y su funcion caracterstica de similitud
esta en la Tabla 3.18.
Por ejemplo, para las 3 primeras tuplas u1, u2 y u3 de R, tenemos que:
R01 (u1) = min(1; maxy
fmin(whitish(y); white (y))g) (3.33)
= min(1; maxy
f0:8; 0:8; 0:4; 0; 0; 0g) = 0:8 (3.34)
R01 (u2) = R01 (u3) = 0:6 (3.35)
Entonces, deducimos que:

R1 (m1) = max(R01 (u1); R01 (u2); R01 (u3)) = 0:8


De similar forma obtenemos que R2 (m1) = 0:8, de donde calculamos el resultado nal
para m1:

Rf S (m1) = min(R1 (m1); R2 (m1)) = min(0:8; 0:8) = 0:8 (3.36)
Para las otras tuplas (m2 y m3) obtenemos que:

Rf S (m2) = min(R1 (m2); R2 (m2)) = min(0; 0) = 0 (3.37)


Rf S (m3) = min(R1 (m3); R2 (m3)) = min(0:6; 0:8) = 0:6 (3.38)
tu
3.7.1.1 Analisis de la Propuesta
La division de Mouaddib representa un caso bastante particular y su modelo de bases de
datos no permite representar mas tipos que los escalares y un grado ( ) asociado a cada
escalar. Este grado tiene un signi cado de pertenencia. Sin embargo, GEFRED nos permite
representar multitud de tipos entre los que esta incluido el tipo que usa Mouaddib, que sera
el tipo 5 de la Tabla 2.4, con un unico valor no normalizado.
Ademas, el metodo de Mouaddib no funciona correctamente, pues en la ecuacion 3.32
desplaza la variable y por todo el dominio del atributo Y . Esto implica que el resultado de
la division puede variar con solo modi car el dominio y la funcion de similitud asociada al
mismo. Por ejemplo, si nosotros introducimos un nuevo valor en el dominio de un atributo la
relacion resultante puede verse alterada, como se demuestra en el siguiente ejemplo.
Ejemplo 3.9 Cambiemos la segunda tupla de R por los valores (m1,yellowish,1). En este
caso obtenemos los mismos valores de la division del Ejemplo 3.8.
Introduzcamos ahora un nuevo color entre white y whitish, que llamaremos white whitish,
tal que whitish (white whitish) = 0:9 y white (white whitish) = 0:9. En ese caso, vemos que
el resultado de la division ha variado, pues obtenemos un grado de 0.9 para m1, cuando lo
esperable es 0.8, como antes de modi car el dominio. tu
3.7. ESTUDIO COMPARATIVO CON OTRAS PROPUESTAS 81

Nuestra division puede obtener similares resultados que la division de Mouaddib pero sin
el inconveniente anterior. Para ello basta con usar la siguiente funcion de comparacion difusa
(en vez de la ecuacion 3.5):

= (x; y) = min(x: ; y: ; x:value (y:value)) (3.39)


donde x e y son los valores que queremos comparar. Cada valor tiene a su vez dos campos:
x.value es el valor asociado a x y que debe pertenecer al dominio del atributo en cuestion y
x: 2 [0; 1] es el grado asociado a ese valor.
En el mismo artculo, Mouaddib presenta el concepto de Informacion Matizada (Nuanced
Information) con el cual permite que su modelo de base de datos admita distribuciones de
posibilidad. La principal desventaja con respecto a la division que aqu presentamos es que la
division de Mouaddib solo permite un atributo comun a ambas relaciones (R y S ), mientras
que en nuestra propuesta podemos tener cualquier numero de atributos comunes a ambas
relaciones.
Mouaddib utiliza tambien medidas de necesidad. Para utilizar la medida de necesidad en
la division que aqu presentamos solo tenemos que utilizar el siguiente comparador difuso:

=N (pe; pe0 ) = dinf


2U
max (pe(d); 1 pe0 (d)) (3.40)
Mouaddib utiliza tambien grados con el signi cado de importancia y propone una division
relacional en la cual se pondera la importancia de cada atributo en ambas relaciones con unos
pesos entre 0 y 1. Esta consideracion no es tenida en cuenta en nuestro modelo, y los grados
que usamos son grados de cumplimiento, no grados de importancia.
3.7.2 La Division de Umano/Fukami
En [145] Umano y Fukami proponen su modelo de BDRD, el cual fue expuesto en el apartado
2.5. En su division, R  S , considera que en el resultado estaran las tuplas tales que los valores
del grado S para todas las tuplas de S son menores o iguales que los valores del grado R
en las tuplas correspondientes.
Ejemplo 3.10 Sean dos relaciones R y S con los valores de las Tablas 3.21 y 3.22, donde
las columnas R y S expresan, respectivamente, el grado de pertenencia de cada tupla a su
relacion.
El resultado puede verse en la Tabla 3.23. La tupla <a1 ; b1 > esta en el resultado porque
los valores de los grados 0.8 y 0.3 de las tuplas de S son menores que los valores de los grados
1 y 0.7 de las tuplas <a1 ; b1 ; c1 ; d1 > y <a1 ; b1 ; c3 ; d3 > respectivamente. El grado para esta
tupla es igual a: min(0:8 ^ 1; 0:3 ^ 0:7) = min(0:8; 0:3) = 0.3.
Como el grado 0.3 de la tupla <c3 ; d3 > de S es mayor que el grado 0.2 de la tupla
<a3 ; b3 ; c3 ; d3 > de R, la tupla <a3 ; b3 > no aparece en el resultado. tu
Cuando las relaciones incluyen distribuciones de posibilidad como valores de atributos
los resultados son obtenidos evaluando la igualdad de los valores de los atributos. Ademas,
a~naden que si en grados de pertenencia hay distribuciones de posibilidad entonces se debe
de nir una relacion de orden para esas distribuciones de posibilidad, indicando una forma
para hacerlo.
82 CAPITULO 3. DIVISION
 RELACIONAL DIFUSA

R A B C D
1 a1 b1 c1 d1
0.7 a1 b1 c3 d3
0.9 a2 b2 c3 d3
0.8 a3 b3 c1 d1
0.2 a3 b3 c3 d3
0.9 a1 b1 c2 d2
Tabla 3.21: Ejemplo 3.10 de Division de Umano/Fukami: Relacion R.

S C D
0.8 c1 d1
0.3 c3 d3
Tabla 3.22: Ejemplo 3.10 de Division de Umano/Fukami: Relacion S .

3.7.2.1 Analisis de la Propuesta


La principal ventaja que presenta el modelo de bases de datos de Umano y Fukami es que nos
permite almacenar un grado de pertenencia para cada tupla. Sin embargo, nosotros creemos
que en la mayora de los casos esa informacion no es muy util, pues en la mayora de los casos
reales se tienen entidades que sabemos que lo son (pertenecen a una relacion con grado 1),
pero que puede que desconozcamos exactamente algunos de sus atributos.
Por ejemplo, si tenemos una base de datos de alumnos, clientes o jugadores de baloncesto,
sabremos que esas entidades lo son con grado 1. Es raro encontrar, en la practica, casos en
los que una entidad lo sea con cierto grado en una relacion \base" de la base de datos. Por
ejemplo, un jugador de baloncesto lo es o pertenece a un equipo con grado 1, siempre. Lo
mas normal es que desconozcamos, o sea difcil medir con exactitud, algun o algunos de sus
atributos: edad, altura, color del pelo, calidad... El grado de pertenencia es util tras alguna
operacion y es visto o como grado de pertenencia al conjunto que genera esa operacion o como
grado de cumplimiento de las condiciones establecidas en esa operacion.
Por otra parte, Umano y Fukami no explican detenidamente que hacer en una division
difusa cuando los valores de los atributos son distribuciones de posibilidad. Cosa que s hacen
con los demas operadores. Simplemente, se limitan a indicar que \cuando las relaciones
incluyen distribuciones de posibilidad como valores de atributos los resultados son obtenidos
evaluando la igualdad de los valores de los atributos" (pagina 25 de [145]).

RS A B
0.3 a1 b1
Tabla 3.23: Ejemplo 3.10 de Division de Umano/Fukami: Relacion resultante R  S .
3.7. ESTUDIO COMPARATIVO CON OTRAS PROPUESTAS 83

3.7.3 Distintos Tipos de Divisiones para Distintos Signi cados, segun Bosc
et al.
En [23] Bosc, Dubois, Pivert y Prade hacen un estudio detallado de algunos tipos de divisiones
dependiendo del signi cado de los grados asociados a cada tupla de cada relacion: Grado de
cumplimiento en atributos graduales, nivel de importancia en una consulta o incertidumbre
en los datos. En su estudio se centran en los dos primeros signi cados.
En su artculo, ellos ven dos clases de problemas, centrandose en el segundo de ellos
exclusivamente:
 Almacenar y manipular informacion incompleta, permitiendo imprecision e incertidum-
bre: Esto puede ser conseguido por distintos mecanismos, como por ejemplo a traves de
la probabilidad [11, 153] (apartado 2.1.4) o de la teora de la posibilidad [127, 143, 147]
(Captulo 2).
 Admitir la posibilidad de poder efectuar consultas exibles (difusas) usando predicados
o condiciones imprecisas y teniendo en cuenta que, en una consulta, algunas partes de la
condicion pueden ser mas importantes que otras. As, las consultas exibles necesitan
una expresion de las preferencias (comparaciones difusas) y unos niveles de importancia
(umbrales).
Para la division consideran dos interpretaciones posibles, pero ambas se basan en bases
de datos clasicas y las relaciones difusas consideradas son el resultado de una consulta difusa
efectuada sobre una relacion clasica. De esta consulta difusa se obtiene una relacion en la
cual existe un grado para cada tupla. Consideran dos tipos de signi cados para esos grados:
1. Grado de cumplimiento: Una propiedad puede cumplirse con cierto grado entre dos
extremos: La propiedad se cumple totalmente (usualmente grado 1) y la propiedad no
se cumple en absoluto (usualmente grado 0).
2. Grado de importancia: Distintos objetos (tuplas) pueden tener diferentes importan-
cias, de forma que existan objetos mas importantes que otros.
O sea, ellos solo consideran relaciones difusas como consecuencia de una seleccion sobre
una relacion clasica (\crisp") usando predicados difusos o por medio de la valoracion directa
de los niveles de importancia.
Supongamos que tenemos dos relaciones R(X; A) y S (A; Y ), donde X , A e Y son atributos
simples o conjuntos de atributos. Notaremos como T (t) el grado de la tupla t en la relacion
T . Entonces, en [23] se consideran los siguientes dos casos, segun las interpretaciones que se
den a R (x; s[A]) y a S (s):

R(x; s[A]) S (s)


Caso 1 Grado de cumplimiento Grado de cumplimiento
Caso 2 Grado de cumplimiento Grado de importancia
Un inconveniente de este modelo es que, aunque el grado esta asociado a un atributo, solo
considera un grado por cada tupla. De esta forma no es posible establecer distintos grados
para distintos atributos dentro de una misma tupla. Este problema se hace mas patente
cuando A es un conjunto formado por varios atributos.
84 CAPITULO 3. DIVISION
 RELACIONAL DIFUSA

X A R
x1 a1 0.8
x1 a2 0.8
x2 a1 0.2
x2 a2 0.5
x3 a1 0.2
x3 a2 1
x4 a1 0.3
x4 a2 0.5
x5 a1 0.2
x5 a2 0.7
Tabla 3.24: Ejemplo 3.11 de Division de Bosc et al.: Relacion R.

Caso 1: El grado de las tuplas de la division se calculara por:


RS (x) = min ( (s) ! R (x; s[A]))
s S
(3.41)
interpretando el cuanti cador universal de la division como una conjuncion generalizada y
usando la T-norma del mnimo.
En este caso la division puede ser efectuada usando dos modelos de implicacion:
1 si a  b
Implicacion de Godel : a ! b = b en otro caso (3.42)
1 si a = 0
Implicacion de Goguen : a ! b = min(1; b=a) si a 6= 0 (3.43)
donde consideramos para la division que a = S (s) y b = R (x; s[A]).
Con la implicacion de Godel, cuando R (x; s[A])  S (s), el resultado de la implicacion es
R (x; s[A]) y esta evaluacion es absoluta puesto que no depende de S (s). O sea, la implicacion
de Godel no mide si el grado de cumplimiento en R se parece mucho o poco al grado en S .
A veces, puede interesar un resultado que mida ese acercamiento de forma relativa, dando
la relacion R (x; s[A])=S (s). Para ello, podemos usar la implicacion de Goguen que es una
R-implicacion, a ! b = supfc 2 [0; 1]; a  c  bg, generada usando el producto en la operacion
.
Ejemplo 3.11 Sean dos relaciones R y S con los valores de las Tablas 3.24 y 3.25, donde
las columnas R y S expresan, respectivamente, el grado de pertenencia de cada tupla a su
relacion. Entonces, en la Tabla 3.26 se muestran los resultados de la division: A la izquierda
empleando la implicacion de Godel y a la derecha empleando la implicacion de Goguen. En
esas relaciones se muestran tambien las operaciones efectuadas para calcular el grado de
cumplimiento  en cada tupla. tu
Es importante destacar que, en estas dos implicaciones, para que un elemento xi aparezca
en el resultado es obligatorio que todos los elementos de S esten relacionados en R con xi :
Si S (s) > 0 y R (x; s[A]) = 0, entonces RS (x) = 0. Por el contrario, la implicacion de
Lukasiewicz no se comporta as y su resultado sera 1 S (s) en este caso (ver ecuacion 3.45).
Ademas, la implicacion de Lukasiewicz no permite distinguir entre el Caso 1 y el Caso 2.
3.7. ESTUDIO COMPARATIVO CON OTRAS PROPUESTAS 85

A 
a1 0.3
a2 0.8
Tabla 3.25: Ejemplo 3.11 de Division de Bosc et al.: Relacion S .

Implicacion de Godel Implicacion de Goguen


X  (Calculo de ) X  (Calculo de )
x1 1.0 = minf1, 1g x1 1.00 = minfminf1, 0.8/0.3g, minf1, 0.8/0.8gg
x2 0.2 = minf0.2, 0.5g x2 0.63 = minfminf1, 0.2/0.3g, minf1, 0.5/0.8gg
x3 0.2 = minf0.2, 1g x3 0.67 = minfminf1, 0.2/0.3g, minf1, 1/0.8gg
x4 0.5 = minf1, 0.5g x4 0.63 = minfminf1, 0.3/0.3g, minf1, 0.5/0.8gg
x5 0.2 = minf0.2, 0.7g x5 0.67 = minfminf1, 0.2/0.3g, minf1, 0.7/0.8gg
Tabla 3.26: Ejemplo 3.11 de Division de Bosc et al. (caso 1): Resultados de R  S segun las
implicaciones de Godel y Goguen.

Caso 2: En este caso, la relacion S puede ser vista como un conjunto de requisitos que
deben cumplir los objetos X de R, de forma que cada requisito tiene asociado el grado de
importancia que tiene. As, una tupla x cumplira totalmente las condiciones de la division si
posee en R el maximo grado de cumplimiento con todos los requisitos expresados en S que
tienen alguna importancia, independientemente del grado de importancia que tengan:

RS (x) = 1 () (8s; S (s) > 0 ) R (x; s[A]) = 1)


Por otra parte, una tupla x no cumplira en absoluto las condiciones de la division si existe
al menos un requisito en S con el maximo nivel de importancia y ademas x no cumple en
absoluto este requisito:

RS (x) = 0 () (9s; S (s) = 1 ^ R (x; s[A]) = 0)


Para las situaciones intermedias se utiliza la ecuacion 3.41, donde ahora la implicacion
usada es la implicacion de Dienes:

Implicacion de Dienes : a ! b = maxf1 a; bg (3.44)


Observese que la implicacion de Dienes respeta los dos casos particulares que hemos ex-
plicado justo antes.
La relacion S debe estar normalizada con respecto a , esto es, el mayor grado de im-
portancia debe ser 1 (9si; S (si ) = 1), para as tener una escala apropiada para los niveles
de importancia. Si S no esta normalizada entonces estamos dividiendo por una relacion que
esta, en cierto sentido, vaca.
86 CAPITULO 3. DIVISION
 RELACIONAL DIFUSA

X A R
x1 a1 1.0
x1 a2 1.0
x2 a1 1.0
x3 a1 0.4
x3 a2 0.8
x4 a1 0.2
x4 a2 0.8
x5 a2 0.8
x6 a1 0.4
x6 a2 0.2
x7 a1 0.2
x7 a2 0.2
x8 a2 0.2
Tabla 3.27: Ejemplo 3.12 de Division de Bosc et al.: Relacion R.

A 
a1 0.3
a2 1.0
Tabla 3.28: Ejemplo 3.12 de Division de Bosc et al.: Relacion S .

Ejemplo 3.12 Sean dos relaciones R y S con los valores de las Tablas 3.27 y 3.28. Observe
que la relacion S esta normalizada. Entonces, en la Tabla 3.29 se muestran los resultados de
la division. En esa relacion se muestran tambien las operaciones efectuadas para calcular el
grado de cumplimiento  en cada tupla. tu
Observese en este caso que, para que un elemento xi aparezca en el resultado, no es
obligatorio que todos los elementos de S esten relacionados en R con xi , cosa que s pasaba
en el caso 1.

3.7.3.1 Analisis de la Propuesta


La principal diferencia entre la division que proponemos y el enfoque de Bosc et al. es que
ellos parten de bases de datos clasicas y las relaciones difusas consideradas son el resultado de
una consulta difusa efectuada sobre una relacion clasica. De esta consulta difusa se obtiene
una relacion en la cual existe un grado para cada tupla pero no admiten valores difusos como
valores de los atributos en una relacion.
Ademas, hay que destacar que ese grado esta asociado a la tupla entera, no a un atributo
particular. Por tanto, estos modelos de division no son aplicables cuando ambas relaciones
tienen varios atributos en comun y queremos que en la division se tengan en cuenta todos
ellos.
En el caso 1 se dan ciertos casos que podran ser vistos como incoherencias. Este caso
ocurre cuando un objeto x de R se relaciona con todas las tuplas de S pero con un grado
3.7. ESTUDIO COMPARATIVO CON OTRAS PROPUESTAS 87

X  (Calculo de )
x1 1.0 = minfmaxf1 0.3, 1.0g, maxf1 1, 1.0gg
x2 0.0 = minfmaxf1 0.3, 1.0g, maxf1 1, 0.0gg
x3 0.8 = minfmaxf1 0.3, 0.4g, maxf1 1, 0.8gg
x4 0.7 = minfmaxf1 0.3, 0.2g, maxf1 1, 0.8gg
x5 0.7 = minfmaxf1 0.3, 0.0g, maxf1 1, 0.8gg
x6 0.2 = minfmaxf1 0.3, 0.4g, maxf1 1, 0.2gg
x7 0.2 = minfmaxf1 0.3, 0.2g, maxf1 1, 0.2gg
x8 0.2 = minfmaxf1 0.3, 0.0g, maxf1 1, 0.2gg
Tabla 3.29: Ejemplo 3.12 de Division de Bosc et al. (caso 2): Resultado de R  S segun la
implicacion de Dienes.

Implicacion de Lukasiewicz Implicacion de Lukasiewicz modi cada


X  (Calculo de ) X  (Calculo de )
x1 1.0 = minf1, 1g x1 0.5 = minf1 0.5, 1 0.0g
x2 0.7 = minf1 0.1, 1 0.3g x2 0.7 = minf1 0.1, 1 0.3g
x3 0.9 = minf1 0.1, 1g x3 0.8 = minf1 0.1, 1 0.2g
x4 0.7 = minf1, 1 0.3g x4 0.7 = minf1 0.0, 1 0.3g
x5 0.9 = minf1 0.1, 1 0.1g x5 0.9 = minf1 0.1, 1 0.1g
Tabla 3.30: Ejemplo 3.11 de Division de Bosc et al. (caso 1 modi cado): Resultados de R  S
segun las dos implicaciones de Lukasiewicz.

ligeramente inferior al que marca S . En ese caso, x es recuperado en la relacion de la division


pero con un grado que puede ser muy peque~no en relacion a lo cerca que esta de cumplir las
condiciones de la division.
As, en el Ejemplo 3.11 la tupla de x5 esta muy cerca de cumplir las condiciones de la
division, pues solo esta a 0.1 grados por debajo de los requisitos expresados en la relacion S en
ambos valores (a1 y a2 ). Sin embargo, usando la implicacion de Goguen obtiene 0.67 y usando
la de Godel obtiene solo un grado de 0.2. Ese problema puede ser solucionado utilizando la
implicacion de Lukasiewicz:
1 si a  b
Implicacion de Lukasiewicz : a ! b = 1 (a b) en otro caso (3.45)

Ademas, puede interesarnos encontrar tuplas que cumplan los requisitos de la division
estrictamente como se expresan en la relacion S . Para solucionar este problema podemos
utilizar una modi cacion de la anterior implicacion:

Implicacion de Lukasiewicz modi cada : a ! b = 1 ja bj (3.46)


donde ja bj expresa el valor absoluto de esa diferencia.
Con esas dos implicaciones los resultados de la division R  S con las Tablas del Ejemplo
3.11 son los expresados en la Tabla 3.30.
88 CAPITULO 3. DIVISION
 RELACIONAL DIFUSA

Otra posible implicacion aplicable es la de Rescher-Gaines, que es tremendamente simple


y que no obtiene los resultados graduados:

si a  b
1
Implicacion de Rescher-Gaines : a ! b = 0 en otro caso (3.47)
Como ya se ha indicado, en el caso 2 la principal ventaja estriba en que para que un
elemento aparezca en el resultado no es obligatorio que todos los elementos de S esten rela-
cionados, en R, con dicho elemento, ya que todo depende de la importancia que tenga ese
elemento. Esto puede verse como una relajacion del cuanti cador universal de la division,
aunque en su propuesta no consideran la posibilidad de utilizar cuanti cadores difusos como
los explicados en el apartado 2.9.2.
3.7.4 La Division de Yager
En [162] Yager expone una division difusa basada, de nuevo, en relaciones difusas que sim-
plemente a~naden un grado de pertenencia a cada tupla. Sin embargo, su metodo aporta la
novedad de relajar el cuanti cador universal de la division, utilizando cuanti cadores difusos
de nidos de la forma de Zadeh [169] (apartado 2.9.2). Su propuesta se basa en los operadores
OWA (Ordered Weighted Average) introducidos por el mismo Yager en [160]:
De nicion 3.4 Un operador OWA de dimension n es una funcion F
F : [0; 1]n ! [0; 1] (3.48)
que tiene asocido un vector de n pesos: wi 2 [0; 1], con i = 1; : : : ; n, de forma que
X
n
wi = 1
i=1
y donde para cualquier argumento (a1 ; : : : ; an ), se tiene la siguiente de nicion

X
n
F (a1 ; : : : ; an) = bi  wi (3.49)
i=1
donde los bi son los elementos ai ordenados de mayor a menor: b1  b2  : : :  bn . tu
En sntesis, es un metodo intermedio entre tomar el valor mnimo y tomar el valor maximo
de un conjunto de valores (a1 ; : : : ; an ). As, si el vector de pesos (w1 ; : : : ; wn ) es (0; : : : ; 0; 1)
la funcion F (a1 ; : : : ; an ) tomara el valor mnimo de los ai y si el vector de pesos es (1; 0; : : : ; 0)
la funcion tomara el valor maximo.
Mostraremos el metodo para efectuar su division relacional difusa, a traves del siguiente
ejemplo:
Ejemplo 3.13 Sean R y S las relaciones de las Tablas 3.31 y 3.32 respectivamente. La
relacion difusa S almacena los requisitos de destreza manual. As, para cada tipo de habilidad,
indica el grado con el que dicha habilidad requiere destreza manual.
Sea el cuanti cador difuso relativo \la mayora " modelado de forma simple: Q(r) = r, con
r 2 [0; 1]. Entonces, la consulta \mostrar la gente que tiene la mayora de las habilidades que
requieren destreza manual " se soluciona con una division entre R y S de la siguiente forma:
3.7. ESTUDIO COMPARATIVO CON OTRAS PROPUESTAS 89

Nombre Habilidad
Jean I 1.0
Jean II 0.7
Jean III 0.5
Barbara I 0.3
Barbara II 0.6
Debbie I 1.0
Debbie II 0.7
Debbie III 0.5
Debbie IV 0.2
Tina II 1.0
Patricia I 1.0
Patricia II 0.8
Patricia III 0.2
Tabla 3.31: Ejemplo 3.13 de Division de Yager: Relacion R.

Habilidad
I 1.0
II 0.8
III 0.2
IV 0.0
Tabla 3.32: Ejemplo 3.13 de Division de Yager: Relacion S .
90 CAPITULO 3. DIVISION
 RELACIONAL DIFUSA

1. Hallar la gente de R: Es una proyeccion simple sobre el atributo \Nombre", de la que


obtenemos: fJean, Barbara, Debbie, Tina, Patriciag.
2. Para cada elemento u obtenido en el paso anterior, calcular Ru+ , como la proyeccion en
R sobre los atributos que no estan en u.
3. Evaluar el grado de verdad de la a rmacion \Q S 's son Ru+ ", o sea, \la mayora de los
elementos de S estan en Ru+ ". Para ello:
(a) Ordenamos de menor a mayor los grados de S y calculamos su suma d:
e1 = 0; e2 = 0:2; e3 = 0:8; e4 = 1 y d = 2.
(b) Calculamos el conjunto de valores Sj , de forma que S0 = 0 y
Sj = edj + Sj 1
S1 = 0; S2 = 0:1; S3 = 0:5 y S4 = 1.
(c) Calculamos el conjunto de pesos:
wj = Q(Sj ) Q(Sj 1)
En este caso tenemos que wj = ej =d con j 2 f1; 2; 3; 4g:
w1 = 0; w2 = 0:1; w3 = 0:4 y w4 = 0:5.
(d) Para cada u:
i. Calcular los Ci , con i 2fI,II,III,IVg:
Ci = maxf1 i ; Ru+(i)g
donde i y Ru+ (i) son los grados del elemento i en S y en Ru+ respectivamente.
ii. Ordenar de mayor a menor los Ci : b1  b2  b3  b4 .
iii. Calcular el grado de verdad buscado como:
X
4
T (u) = bi  wi
j =1
Los 3 ultimos pasos, para \Jean" seran calculados de la siguiente forma:
CI = maxf1 1:0; 1:0g = 1:0
CII = maxf1 0:8; 0:7g = 0:7
CIII = maxf1 0:2; 0:5g = 0:8
CIV = maxf1 0:0; 0:0g = 1:0
De donde obtenemos que b1 = 1; b2 = 1; b3 = 0:8; b4 = 0:7 y, por tanto:

T (Jean) = 1  0 + 1  0:1 + 0:8  0:4 + 0:7  0:5 = 0:77


El resultado global se muestra en la Tabla 3.33 con la mayora . El valor de 8 indica el
resultado obtenido utilizando el cuanti cador 8, con el que Q(r) = 1 si y solo si r = 1. Este
ultimo cuanti cador, de hecho, lo que hace es tomar el mnimo de los Ci , que coincide con
la medida de necesidad entre los valores de R con respecto a los de S para un determinado
\Nombre". tu
3.7. ESTUDIO COMPARATIVO CON OTRAS PROPUESTAS 91

Nombre la mayora 8
Jean 0.77 0.70
Barbara 0.47 0.30
Debbie 0.77 0.70
Tina 0.42 0.00
Patricia 0.82 0.80
Tabla 3.33: Ejemplo 3.13: Resultado de la Division de Yager.

3.7.4.1 Analisis de la Propuesta


La division de Yager tiene la caracterstica principal de relajar el cuanti cador universal,
pudiendo usar cualquier otro cuanti cador difuso Q, como por ejemplo el cuanti cador difuso
\la mayora " del ejemplo anterior. Esta relajacion la hace a traves de los operadores OWA.
En la division que proponemos nosotros tambien se permite relajar el cuanti cador, pudiendo
usar cualquier tipo de cuanti cador, incluso aquellos que son no monotonos. Yager considera
solo los cuanti cadores monotonos, aunque, de hecho, solo estudia el caso particular de los
cuanti cadores monotonos crecientes.
Yager utiliza un modelo de BDRD similar al empleado por Mouaddib (apartado 3.7.1)
que no permite representar mas tipos que los escalares y un grado ( ) asociado a cada escalar.
Este grado tiene un signi cado de pertenencia. Como dijimos anteriormente este tipo de datos
es tambien considerado por GEFRED, pero con signi cado de posibilidad (distribuciones de
posibilidad no normalizadas sobre escalares).
Ademas, Yager no considera en su division el caso en el que ambas relaciones tengan varios
atributos comunes con distinto grado cada uno.
Algunos resultados mereceran un estudio detallado, ya que, por ejemplo \Patricia" cumple
perfectamente con los requisitos expresados en la relacion S y sin embargo solo obtiene 8 =
0:8. Con el cuanti cador difuso obtiene la mayora = 0:82, un valor que creemos demasiado
peque~no con respecto al que intuitivamente se espera obtener.

3.7.5 La Division de Vila et al.


En [149], Vila, Cubero, Medina y Pons proponen un novedoso sistema para el calculo de la
division relacional R(A; B )  S (B ), en BDRD bajo el modelo posibilstico, es decir, en las
que se pueden almacenar distribuciones de posibilidad como valores en sus atributos.
Su sistema se basa en \comprimir" las relaciones involucradas, de forma que: La relacion
del numerador R se quede con tantas tuplas como valores distintos existan para el conjunto de
atributos A y la relacion del denominador S se quede con una unica tupla. Las distribuciones
de posibilidad de B son comprimidas en una unica distribucion de posibilidad tomando el
valor maximo en cada distribucion, para cada valor del dominio subyacente.
Si llamamos B (R) a la relacion R comprimida de esa forma y P a la distribucion de
posibilidad resultante de la relacion S , entonces, su division es efectuada de la siguiente
forma:

A( QB'P (B (R))) (3.50)


92 CAPITULO 3. DIVISION
 RELACIONAL DIFUSA

P# S#
P1 0.8/S1, 0.5/S2
P1 0.7/S1, 0.6/S2
P1 0.8/S3, 0.7/S4
P2 1/S1
P2 1/S4
P3 0.6/S1, 0.9/S3
P3 1/S2
P4 0.7/S1, 0.2/S3
P4 1/S2
P4 1/S3
P4 0.6/S1, 0.5/S4
P5 1/S3
P6 0.5/S1, 0.7/S2, 1/S3
Tabla 3.34: Ejemplo 3.14 de Division de Vila et al.: Relacion R.

donde A es la proyeccion sobre los atributos de A y  QB'P es una seleccion generalizada


llamada '-seleccion dependiente de la medida difusa Q.
A grandes rasgos, para un cuanti cador difuso Q creciente se obtiene una medida Q . Por
ejemplo, el cuanti cador Q puede ser expresado como:
8
>
< 0(x si 0  x  aQ
Q(x) = > (b aQ ) si aQ < x < bQ (3.51)
aQ )
:1 Q
si bQ  x  1
donde aQ ; bQ 2 [0; 1] y aQ  bQ . Estos dos valores representan al cuanti cador, de forma que
para el cuanti cador 9 corresponden los valores (0,0) y para el cuanti cador 8 corresponden
los valores (1,1). Entonces, podemos obtener el valor Q de la siguiente forma:
Q = (bQ aQ)=2 + 1 bQ (3.52)
Con esos datos, podemos de nir que la seleccion  QB'P a~nade un grado que es calculado
de la siguiente forma:
Q(B jP ) + (1 Q)N (B jP ) (3.53)
donde (AjP ) y N (AjP ) son las medidas de posibilidad y necesidad respectivamente con las
que el B se empareja con P .
Ejemplo 3.14 Sea R la relacion de la Tabla 3.34, donde el atributo S# es difuso. Al com-
primir la relacion R obtenemos la relacion de la Tabla 3.35. Y sea P una distribucion de
posibilidad de nida como:
P = f0:5=S 1; 0:7=S 2; 1=S 3g
3.7. ESTUDIO COMPARATIVO CON OTRAS PROPUESTAS 93

P# S#
P1 0.8/S1, 0.6/S2, 0.8/S3, 0.7/S4
P2 1/S1, 1/S4
P3 0.6/S1, 1/S2, 0.9/S3
P4 0.7/S1, 1/S2, 1/S3, 0.5/S4
P5 1/S3
P6 0.5/S1, 0.7/S2, 1/S3
Tabla 3.35: Ejemplo 3.14 de Division de Vila et al.: Relacion R comprimida.

P# 9 casi todos 8
P1 0.80 0.64 0.60
P2 0.50 0.10 0.00
P3 0.90 0.66 0.60
P4 1.00 0.76 0.70
P5 1.00 0.44 0.30
P6 1.00 0.60 0.50
Tabla 3.36: Ejemplo 3.14: Resultado de la Division de Vila et al.

Consideremos, por ejemplo, los siguientes 3 cuanti cadores: 9 con sus valores asociados
(0,0) y 9 = 1, \casi todos ", con sus valores (0.7,0.9) y casi todos = 0:2 y por ultimo, el
cuanti cador clasico para la division, 8, con sus valores (1,1) y 8 = 0.
En la Tabla 3.36 se incluyen los resultados para los 3 cuanti cadores considerados tomando
el maximo y el mnimo como la T-conorma y la T-norma respectivamente. As, por ejemplo
para P1 tenemos los siguientes calculos para cada cuanti cador:
9 (P 1) = maxfminf0:5; 0:8g; minf0:7; 0:6g; minf1; 0:8g; minf0; 0:7gg = 0:8
8(P 1) = minfmaxf1 0:5; 0:8g; max f1 0:7; 0:6g; max f1 1; 0:8g; maxf1 0; 0:7gg = 0:6
casi todos (P 1) = (0:2  0:8) + (1 0:2)  0:6 = 0:64
Es facil obtener los valores para cualquier otro cuanti cador, teniendo los valores de 9
(posibilidad) y de 8 (necesidad). tu
3.7.5.1 Analisis de la Propuesta
La division de Vila et al. tiene la caracterstica principal de relajar el cuanti cador universal,
pudiendo usar cualquier otro cuanti cador difuso Q creciente, como por ejemplo el cuanti -
cador difuso \casi todos " del ejemplo anterior. Ademas, el modelo de BDRD que emplea es
un modelo posibilstico, por lo que permite el uso de distribuciones de posibilidad, aunque no
contempla explcitamente el uso de escalares con una relacion de semejanza entre ellos.
Esta division no de ne el caso en el que ambas relaciones tengan varios atributos comunes,
aunque da una nocion sobre como se podra efectuar.
En terminos generales, obtiene el conjunto de los elementos de A para los que la union de
los valores de B con los que estan relacionados, es \similar" a la union de los valores de la
94 CAPITULO 3. DIVISION
 RELACIONAL DIFUSA

Nuestra Propuesta Propuesta de Vila et al.


H EQUIPO C9EQUIPO C algunos
EQUIPO C casi todos
EQUIPO C8
EQUIPO
9 algunos casi todos 8
B Cordoba 1 1 1 1 1 0.75 0.6 0.5
Granada 1 1 1 1 1 0.75 0.6 0.5
Malaga 1 1 1 1 1 0.75 0.6 0.5
Sevilla 1 0.875 0.875 0.75 1 0.5 0.2 0
Cadiz 1 0.5 0 0 1 0.5 0.2 0
Almera 1 0.75 0.25 0.5 1 0.5 0.2 0
Huelva 1 0.5 0 0 1 0.5 0.2 0
Tabla 3.37: Ejemplo 3.15 de comparacion entre la propuesta de Division de Vila et al. y
nuestra propuesta.

relacion denominador S . Ese \similar" puede ser visto como una medida de posibilidad, de
necesidad o de una mezcla de ambas, dependiendo del cuanti cador empleado.
Por tanto, la propuesta de Vila et al. mas que una division relacional en sentido estricto,
es, como ellos mismos llaman, una \seleccion generalizada" que permite efectuar selecciones
con cierta similitud semantica a la division relacional. Su propuesta es interesante pues aporta
la operacion de compresion y la seleccion generalizada, operaciones estas que pueden resultar
muy utiles en consultas exibles a BDRD.
Algunos resultados mereceran un estudio detallado, ya que, por ejemplo \P6" cumple
perfectamente con los requisitos expresados en P , o sea S#=P , y sin embargo solo obtiene
8 = 0:5, un valor que creemos demasiado peque~no con respecto al que intuitivamente se
espera obtener.
La diferencia entre esta propuesta y la nuestra se ve facilmente con un ejemplo:

Ejemplo 3.15 Sea R la relacion de la Tabla 3.7 (Ejemplo 3.5) y sea R0 la relacion de la Tabla
3.8, pero considerando solo el atributo CALIDAD. As pues, los resultados de R  R0 obtenidos
por nuestra propuesta y por la propuesta de Vila et al. estan expresados en la Tabla 3.37
utilizando cuatro cuanti cadores: (1) Existencial, (2) universal, (3) el cuanti cador difuso
\algunos" de nido como Q(x) = x, esto es, con sus valores (0,1), siguiendo la ecuacion 3.51,
y algunos = 0:5 y (4) el cuanti cador difuso \casi todos", de nido como en el Ejemplo 3.14,
esto es, con sus valores (0.7,0.9) y casi todos = 0:2.
Puede apreciarse que, quizas, los resultados de nuestra propuesta son mas acordes a los
resultados que intuitivamente uno espera obtener. Ademas, nuestra propuesta distingue entre
los casos de los equipos de \Sevilla", \Cadiz" y \Almera", dando distinto grado a cada uno de
esos equipos. Naturalmente, esa graduacion depende del cuanti cador difuso empleado. tu

Por otra parte, solo considera cuanti cadores difusos cuya funcion Q sea creciente y si-
guiendo la ecuacion 3.51, algo demasiado restrictivo, ya que algunos cuanti cadores son inhe-
rentemente decrecientes (global o localmente), tales como \la minora", \exclusivamente unos
pocos", \aproximadamente menos que la mitad", \aproximadamente x"... Nuestra propuesta
permite el uso de cualquier tipo de cuanti cadores difusos, independientemente de la forma
que tenga su funcion Q, como se muestra en el Ejemplo 3.7.
3.8. CONCLUSIONES Y LINEAS FUTURAS SOBRE LA DIVISION
 DIFUSA 95

3.8 Conclusiones y Lneas Futuras sobre la Division Relacional


Difusa
La Division Difusa Generalizada presentada permite extender de forma consistente la semantica
de la Division Relacional al ambito de las BDRD. Las principales ventajas de nuestra pro-
puesta son:
 Las relaciones difusas pueden almacenar muchos tipos de datos difusos (distribuciones
de posibilidad, escalares...) y lo unico que necesitamos es tener de nida una funcion de
comparacion para esos valores, la cual puede ser sustituida sin necesidad de alterar el
proceso de la division. Por supuesto, si usamos distintas funciones de comparacion los
resultados podran ser diferentes.
 Las relaciones sobre las que se aplica la division pueden disponer de cualquier numero
de atributos comunes.
 Permite la relajacion del cuanti cador universal propio de la operacion de Division
Relacional, con cualquier tipo de cuanti cador difuso de nido como se explico en el
apartado 2.9.2.
Ademas, sus resultados pueden a~nadirse a los de otras operaciones, como las presentadas
en [150, 163, 169] para obtener mas informacion de una base de datos.
Por ejemplo, podemos saber en que medida es cierta la siguiente a rmacion y, ademas,
saber que alumnos cumplen esa a rmacion y en que grado la cumple cada uno:
 La mayora de los alumnos son Buenos (o Muy Buenos) en al menos una asignatura y
Malos (o Muy Malos) en al menos otra asignatura.
La Division Relacional Difusa Generalizada puede ser extendida para el caso en el que R0
tenga ademas otros atributos no comunes a R. Esta extension se hace de la misma forma que
para la Division clasica (explicada en el apartado 1.2.4.1).
Hemos estudiado aqu la Division Relacional en Bases de Datos Difusas cuando los atri-
butos de A (atributos no comunes a ambas relaciones) son \crisp", esto es, atributos en los
que no surgen problemas al aplicar la proyeccion sobre ellos (cuando se eliminan tuplas re-
dundantes). Si entre los atributos de A hay atributos con dominios difusos el problema surge
al efectuar las siguientes operaciones:
 Ecuacion 3.11 para el calculo de la Proyeccion Difusa Generalizada con Funciones de
Grupo: En esta operacion se proyecta sobre atributos de A (all llamados X 0 ). En el
computo del resultado de las funciones de grupo no hay problemas porque en X se usan
exclusivamente atributos de compatibilidad (que tienen dominio crisp: [0; 1]).
 Ecuacion 3.13 para el calculo de la Proyeccion Difusa Generalizada con Funciones de
Grupo: Esta ecuacion aplica una condicion de igualdad sobre atributos de A.
 Ecuacion 3.15, para el calculo de la Division Difusa Generalizada: En esta operacion se
proyecta sobre todos los atributos de A.
96 CAPITULO 3. DIVISION
 RELACIONAL DIFUSA

Por tanto, para incluir atributos con dominios difusos entre los atributos de A, es necesario
adoptar previamente un criterio para saber cuando dos valores difusos pueden ser considerados
iguales. Un ejemplo es el criterio de Prade y Testemale [129] de la ecuacion 3.1. El problema
que presenta este criterio es que no cumple la propiedad transitiva, y por tanto, el resultado
puede variar dependiendo del orden de evaluacion de las tuplas de una relacion. Buckles y
Petry, en [28, 30], exponen otras aproximaciones al problema, dentro del modelo propuesto
por estos autores.
Actualmente, estamos estudiando una propuesta que contribuya a reducir, en lo posible,
el problema de la igualdad de conjuntos difusos y el problema de la redundancia en Bases
de Datos Difusas. No obstante, la eliminacion total de este problema, de forma unica para
todos los contextos, es imposible, por la naturaleza difusa de los datos en cuestion. Tambien
estamos estudiando la posibilidad de relajar el cuanti cador universal pero utilizando los
operadores OWA sobre los grados resultantes de la Interseccion Difusa Cuali cada. Para ello,
el problema que surge es como obtener los pesos wi del operador OWA (ver De nicion 3.4).
Una posible ampliacion de nuestra propuesta consiste en considerar el caso en el que las
relaciones sobre las que se aplica la division relacional tengan atributos de compatibilidad
asociados a algunos de sus atributos.
Captulo 4
Calculo Relacional Difuso
Como parte integrante del modelo relacional de bases de datos (apartado 1.2) Codd introdujo
en [42] dos niveles de Lenguajes para la Manipulacion de Datos (DML, Data Manipulation
Languages ): El A lgebra Relacional y el Calculo Relacional.
Ambos lenguajes fueron explicados basicamente en el apartado 1.2.4 para bases de datos
clasicas (con todos los dominios crisp), y se adaptan perfectamente a ellas. En bases de datos
difusas las de niciones se complican para atender a una casustica mayor. En el apartado
2.7 se explico el modelo GEFRED [102, 103] de bases de datos relacionales difusas. Como se
ha visto GEFRED dispone de un algebra relacional difuso para este modelo, incluyendo la
operacion de la division (Captulo 3 y [72]).
Aqu, damos la de nicion de un calculo relacional difuso orientado a dominios para el
modelo GEFRED, aunque sus fundamentos pueden usarse en otros modelos.
En [32] se propone un calculo de dominios para el modelo de bases de datos relacionales
difusas de Buckles-Petry [28, 30] (apartado 2.3), el cual es mas restrictivo que el modelo
GEFRED (apartado 2.7) y no cuenta con los atributos de compatibilidad para evaluar el
grado de cumplimiento de la condicion impuesta en una expresion.
Hemos elegido el calculo de dominios en vez del de tuplas porque tiende a estar mas cerca
del lenguaje natural que el calculo de tuplas. Al usar variables de dominio y tratar as cada
atributo independientemente, el calculo de dominios es mas explcito y mas facil de usar.
La diferencia fundamental entre el calculo de tuplas y el de dominios estriba basicamente
en como el usuario entiende la base de datos, esto es, las relaciones y los atributos. En el
calculo de tuplas las entidades principales son las relaciones, las cuales tienen propiedades
particulares (sus atributos). En el calculo de dominios las entidades principales son los atri-
butos, los cuales se pueden relacionar entre ellos usando las relaciones de la base de datos.
Esta ultima vision esta mas cercana a como el hombre ve y entiende el universo que representa
la base de datos.
En primer lugar daremos la de nicion del calculo relacional difuso de dominios. Despues
veremos las expresiones en calculo de los operadores primitivos del algebra y de los operadores
no primitivos mas tpicos y una demostracion sobre como para cualquier expresion algebraica
se puede encontrar una expresion equivalente en calculo. Posteriormente, mostraremos un
mecanismo para averiguar, en la relacion resultante, el grado de cumplimiento con el que
cada valor de cada tupla ha satisfecho la condicion de la consulta. Finalmente, expondremos
unos ejemplos practicos que muestran la capacidad o potencia expresiva de este lenguaje
y como extraer los grados de cumplimiento en la relacion resultante (muy importante para
97
98 CAPITULO 4. CALCULO
 RELACIONAL DIFUSO
considerar el conjunto de tuplas del resultado como un conjunto difuso).

4.1 Calculo Relacional Difuso de Dominios


(Fuzzy Domain Relational Calculus)
Para la de nicion del Calculo Relacional Difuso de Dominios nos basaremos en el Calculo Re-
lacional de Dominios clasico (apartado 1.2.4.2), usando la notacion de Ullman [141]. Primero
de niremos las expresiones validas de este Calculo Relacional, junto con los atomos difusos y
las Formulas Bien Formadas (WFF) con atomos difusos. Posteriormente, veremos como res-
tringir las expresiones del calculo a aquellas que representan una relacion nita (expresiones
\seguras").
4.1.1 De nicion de las Expresiones del Calculo Difuso de Dominios
Las expresiones, en Calculo de Dominios son de la forma:
fx1 ; x2 ; : : : ; xn j (x1 ; x2 ; : : : ; xn)g (4.1)
donde:
 x1 ; x2 ; : : : ; xn son variables de dominio, esto es, variables que toman valores dentro
del dominio en el que se de nan. Estas variables toman valores dentro del rango (o
dominio) de un atributo concreto de una relacion difusa generalizada. Por eso, a veces
se les nombra con igual nombre que ese atributo. Con estas variables expresamos una
tupla con los atributos que deseamos que tenga nuestra relacion resultante u objetivo.
La relacion resultante sera tambien una relacion difusa generalizada. Entre los xi de
la parte izquierda puede tambien haber constantes o expresiones que usen constantes
y variables pero, para simpli car y enfocar mejor el problema, no tendremos en cuenta
estas posibilidades.
 (x1 ; x2; : : : ; xn ) es una Formula Bien Formada o WFF (Well Formed Formula ),
que esta construida a partir de elementos llamados atomos difusos y de unos operado-
res espec cos. Esta formula debe tener como unicas variables libres x1 ; x2 ; : : : ; xn y
expresa un predicado o condicion que debe ser cumplida por las tuplas resultantes. Un
predicado solo puede ser Verdadero o Falso (recordemos que esta basado en el calculo
de predicados de primer orden). Todos estos conceptos los de nimos a continuacion.
4.1.1.1 A tomos Difusos
Los atomos difusos de las formulas (WFF) los de nimos como formados por dos partes:
1. Grado de cumplimiento: 
2. Umbral de cumplimiento:
y se expresaran usando el comparador crisp \" (o usualmente tambien \>") de la siguiente
forma1 :
1 Puede utilizarse otro comparador distinto a \" y a \>", aunque cambiara totalmente el sentido de la
consulta.

4.1. CALCULO RELACIONAL DIFUSO DE DOMINIOS 99


El grado de cumplimiento  de los atomos puede, a su vez, ser de dos tipos:
1. Pertenencia:  = R(x1 ; x2 ; : : : ; xn ), donde R es una relacion difusa generalizada de
grado n y cardinalidad m (como en la ecuacion 2.10) y cada xi es una variable de
dominio o una constante (crisp o difusa). Este atomo expresa el grado de cumplimiento
(o de verdad) que tiene la a rmacion que sostiene que (x1 ; x2 ; : : : ; xn ) es una tupla de
R. Este grado de cumplimiento se calcula de la siguiente forma:

R(x1 ; x2 ; : : : ; xn ) = r=1max f min f=(derc; xc)gg


;:::;m c=1;::: ;n
(4.2)

donde = es un comparador difuso generalizado (ver De nicion 2.5) sobre D inducido


por el comparador extendido = (d; d0 )=(d; d0 ), de nido de forma general, para distri-
buciones de posibilidad, como:

=(pe; pe0 ) = sup min (= (p; p0 ); pe(p); pe0 (p0 )) (4.3)


(p;p0)2U U
= sup min (pe(d); pe0 (d)) (4.4)
d2U

donde pe; pe0 2 D, y sus distribuciones de posibilidad asociadas son pe y pe0 respec-
tivamente. U es el dominio de discurso sobre el que se construye el dominio difuso
generalizado D (ver De nicion 2.1). El comparador = se puede traducir por \posi-
blemente igual" y su de nicion puede cambiarse por otra distinta. En otros tipos de
datos (como los escalares), su de nicion sera distinta, adaptada al tipo de datos en
cuestion (relaciones de similitud [166]). En el apartado 5.2.1.7 se da una de nicion de
este comparador para distribuciones de posibilidad sobre escalares con una relacion de
similitud.
Nosotros, usaremos la de nicion anterior a lo largo de este captulo, aunque queremos
remarcar que el calculo que de nimos es independiente del comparador empleado para
evaluar la igualdad entre valores difusos. Para determinados tipos de valores es posible
que se requiera de nir previamente un comparador de igualdad para ellos.
Si notamos por K a una tupla (k1 ; : : : ; kn ) donde todos ki son constantes, entonces,
llamaremos tupla mas parecida a K en R a la tupla j {esima, (dej 1 ; : : : ; dejn ), tal que
cumple que:

max f min f= (derc ; kc )gg = c=1min


r=1;::: ;m c=1;:::;n ;:::;n
f=(dejc; kc)g (4.5)

Esto es, la tupla mas parecida a K en R es la tupla (dej 1 ; : : : ; dejn ) de R que mas \se
parece" a (k1 ; : : : ; kn ). Por tanto, R(K ) toma el valor (por la ecuacion 4.2) de la
100 CAPITULO 4. CALCULO
 RELACIONAL DIFUSO
similitud entre K y su tupla mas parecida en R. En otras palabras, la ecuacion 4.2
calcula la mayor similitud entre K y una tupla de R (que sera su tupla mas parecida).
A esa similitud que calcula la ecuacion 4.2, a veces, para simpli car, le llamaremos
grado de pertenencia de una tupla a R.
2. Comparacion:  =  (x; y), donde  es un comparador difuso generalizado inducido
por el comparador extendido , y x e y son variables de dominio o constantes (crisp o
difusas). Este atomo difuso expresa el grado de cumplimiento con el que x se relaciona
con y mediante el comparador  . Estos atomos difusos los llamaremos comparaciones
difusas.
Se puede observar que las comparaciones crisp son un caso particular de las comparacio-
nes difusas y estan incluidas dentro de estas. Por tanto, por cuestiones de claridad, en las
expresiones del calculo tambien podremos usar comparaciones crisp, con la notacion in ja
tradicional: xy, donde x e y son constantes o variables de dominio y  es un comparador
aritmetico:  2 f=; 6=; <; ; >; g.
El umbral de cumplimiento es una constante real, con 2 [0; 1], que expresa un
lmite que debe igualar o superar  para que el atomo se considere Verdad. Por simplicidad,
establecemos que los atomos se podran escribir sin el umbral cuando se desee expresar que
el grado de cumplimiento sea no nulo. O sea, cuando en un atomo no aparezca el umbral,
se supone que este es expresado con el comparador \>" y = 0. Esto sera muy usual en
las comparaciones crisp, re riendose a que estas sean verdad, y en los atomos de pertenencia
para indicar que solo vamos a considerar las tuplas que pertenecen a la relacion con grado no
nulo.
Ejemplo 4.1 Consideremos que:
 R y S son relaciones difusas generalizadas de grado 4 y 3 respectivamente.
 x1 , x2 y x3 son variables de dominio.
 \Bueno" es una etiqueta lingustica constante con una distribucion de posibilidad aso-
ciada.
 #n es un numero difuso que expresa \aproximadamente n", siendo n una constante
numerica.
 > es el comparador difuso generalizado \mayor que".
 >> es el comparador difuso generalizado \mucho mayor que".
Entonces, las Tablas 4.1 y 4.2 recogen algunos ejemplos de atomos difusos de Pertenencia
y de Comparacion respectivamente, junto con su signi cado. Observese como en cualquier
campo de un atomo difuso pueden aparecer variables de dominio, constantes crisp o constantes
difusas (numeros difusos, etiquetas lingusticas, distribuciones de posibilidad...). tu
El signi cado y la utilidad de los umbrales de cumplimiento varan en funcion del tipo de
atomo:

4.1. CALCULO RELACIONAL DIFUSO DE DOMINIOS 101

R(x1 ; x2 ; 13; 8)  0:6 La tupla (x1 ; x2 ; 13; 8) pertenece a R con grado mnimo 0.6
R(x1 ; x2 ; x3 ; #8)  0:5 La tupla (x1 ; x2 ; x3 ; #8) pertenece a R con grado mnimo 0.5
S (x1 ; Bueno; x3 ) La tupla (x1 ; Bueno; x3 ) pertenece a S con grado no nulo

Tabla 4.1: Ejemplos de atomos difusos de Pertenencia y su signi cado.


=(x1 ; Bueno)  0:9 x1 es \Bueno" con grado mnimo 0.9
>(x1 ; #15)  0:25 x1 es mayor que \aproximadamente 15" con grado mnimo 0.25
>>(#5; x2 )  0:5 \Aproximadamente 5" es mucho mayor que x2 con grado mnimo 0.5

Tabla 4.2: Ejemplos de atomos difusos de Comparacion y su signi cado.

 A tomos de Pertenencia: En este tipo de atomos aplicamos un criterio de indistin-


guibilidad de tuplas, o sea, un criterio que indica si 2 tuplas podemos considerarlas
su cientemente parecidas. En la ecuacion 4.2 asignamos a R(x1 ; : : : ; xn ) el valor de
la similitud de la tupla (x1 ; : : : ; xn ) con la tupla de R que mas se le parezca. Con-
sideraremos que esas dos tuplas son su cientemente parecidas o, lo que es lo mismo,
que (x1 ; : : : ; xn ) 2 R si esa similitud es mayor o igual que el umbral de cumplimiento
preestablecido , esto es, si R(x1 ; : : : ; xn )  . En ese caso, el atomo se aceptara como
Verdad y en otro caso se tomara como Falso.
 A tomos de Comparacion: Los umbrales de cumplimiento indican si se considera que
el atomo de la comparacion difusa es aceptado como Verdad o rechazado por ser Falso:
Si el valor que devuelve el comparador difuso ( ) es mayor o igual que , entonces el
atomo sera Verdad. En caso contrario, el atomo sera Falso.
4.1.1.2 Formulas Bien Formadas con A tomos Difusos: WFF (Well Formed For-
mulas )
A continuacion, de nimos los operadores validos y lo que son ocurrencias de variables de
dominio libres y ligadas, a la vez que de nimos el concepto de Formula Bien Formada o
WFF con atomos difusos. Una WFF con atomos difusos esta de nida como las WFF del
calculo clasico pero incluyendo atomos difusos:
1. Un atomo difuso es una WFF. Todas sus ocurrencias de variables de dominio son libres.
2. Si es una WFF, tambien lo es : (NOT ). La formula : sostiene que es falsa.
Las ocurrencias de variables de dominio en : son libres o ligadas segun esten en .
3. Si 1 y 2 son WFF, tambien lo son 1 _ 2 ( 1 OR 2 ) y 1 ^ 2 ( 1 AND 2 ). La
formula 1 _ 2 sostiene que es cierta 1 o es cierta 2 o lo son ambas, y la formula
1 ^ 2 sostiene que 1 y 2 son ambas ciertas. Las ocurrencias de variables de dominio
en 1 _ 2 y 1 ^ 2 son libres o ligadas segun esten en 1 y 2 .
4. Si 1 y 2 son WFF, tambien lo es 1 ! 2 (IF 1 THEN 2 ), indicando que si 1 es
cierta tambien lo es 2 . Las ocurrencias de variables de dominio en 1 ! 2 son libres
o ligadas segun esten en 1 y 2 .
102 CAPITULO 4. CALCULO
 RELACIONAL DIFUSO
5. Si es una WFF y x es una variable de dominio que aparece como libre en , entonces
tambien son WFF 9x( ) y 8x( ), siendo las ocurrencias de x ligadas en esas dos ultimas
WFF. La formula 9x( ) sostiene que existe un valor de x tal que cuando sustituimos
este valor en todas las ocurrencias libres de x en , la formula se hace cierta. La
formula 8x( ) sostiene que para cualquier valor de x, si sustituimos ese valor en todas
las ocurrencias libres de x en , la formula se hace cierta.
6. Si es una WFF, tambien lo es ( ).
7. Nada mas es una WFF.
Los parentesis pueden situarse cuando sean necesarios para alterar la precedencia de los
operadores o para aclarar el orden de evaluacion de estos. Normalmente se supone que el or-
den de precedencia es el siguiente: A tomos, cuanti cadores (9 y 8), negacion (:), conjuncion
(^), disyuncion (_) e implicacion (!), en ese orden. Igualmente, se pueden introducir tam-
bien otros operadores como XOR (eXclusive OR), NOR (NOT OR), NAND (NOT AND)...
Nosotros no lo hemos hecho para simpli car.
Observese que solo utilizamos dos tipos de cuanti cadores, el existencial y el universal.
Sin embargo es posible de nir otros cuanti cadores difusos que relajen, de alguna forma, las
consultas. Por ejemplo, podramos usar cuanti cadores del tipo \la minora", \la mayora",
\aproximadamente n", \aproximadamente la mitad"... La de nicion de este tipo de cuanti -
cadores difusos es un tema complejo que estudiaremos de forma independiente en el apartado
4.5.
Notaremos como (x1 ; : : : ; xn ) a una WFF donde las variables x1 ; : : : ; xn son variables
libres (no necesariamente todas las que haya en ). A veces, notaremos una WFF simplemente
, sin que esto indique que no tiene variables libres.
Si en la posicion i apareciera una constante ki en lugar de la variable xi , (x1 ; : : : ; ki ; : : : ; xn ),
se supondra que todas las ocurrencias de la variable xi son sustituidas por la constante ki .
Obviamente, xi deja de ser variable libre, por lo que tenemos que:
(x1 ; : : : ; xi 1 ; ki ; xi+1 ; : : : ; xn ) = 1 (x1 ; : : : ; xi 1 ; xi+1 ; : : : ; xn )
donde 1 es la misma WFF pero con las ocurrencias de xi sustituidas por la constante ki .
La de nicion anterior de WFF se puede simpli car eliminando de la de nicion algunos
operadores, como lo demuestra el siguiente lema:
Lema 4.1 Si es una formula en calculo relacional (de tuplas o de dominios), entonces hay
una formula equivalente 0 sin ocurrencias de los operadores ^, 8 o !.
Demostracion: Para eliminar los operadores ^, 8 y ! de una formula basta con sustituirlos
por expresiones equivalentes en funcion de los otros operadores:
1. Reemplazar cada subformula de la forma 1 ^ 2 por :(: 1 _: 2 ). Esta transformacion
se denomina Ley de DeMorgan.
2. Reemplazar cada subformula de la forma 8x( (x)) por :9x(: (x)).
3. Reemplazar cada subformula de la forma 1 ! 2 por : 1 _ 2 .
Por tanto, en 0 solo apareceran operadores :, _ o 9, que son los realmente imprescindi-
bles. Los otros son utiles para conseguir expresiones mas simples e intuitivas. tu

4.1. CALCULO RELACIONAL DIFUSO DE DOMINIOS 103

4.1.2 Restriccion del Calculo Relacional Difuso para Producir Relaciones


Finitas
J.D. Ullman, en [141], de ne las llamadas expresiones \seguras" (\safe ") del calculo relacional
clasico. Las expresiones seguras son aquellas que producen relaciones nitas. Las expresiones
no seguras deben descartarse ya que carecen de sentido. Si llamamos X a un conjunto de
variables de dominio x1 ; : : : ; xn , un ejemplo de expresion no segura es fX j :R(X )g, la cual
denota todas las tuplas posibles que no estan en R, algo imposible de conseguir si algun
dominio de R es in nito.
Para de nir las expresiones seguras, Ullman de ne DOM( ) como el conjunto de smbolos
que aparecen explcitamente en o que son componentes de alguna tupla en alguna relacion
mencionada en . Con esto, Ullman dice que una expresion en calculo relacional clasico fX
j (X )g es segura si:
1. Siempre que X cumpla , todos los componentes de X son miembros de DOM( ).
2. Para cada subformula de de la forma 9u(w(u)), si u cumple w para cualesquiera otros
valores de las otras variables libres de w, entonces, u 2 DOM(w).
3. Para cada subformula de de la forma 8u(w(u)), si u 62 DOM(w), entonces u cumple
w para todos los valores de las otras variables libres de w.
Como dice Ullman, el proposito de los puntos (2) y (3) es asegurar que podemos determinar
la verdad de una formula cuanti cada (con 9 o 8) considerando solo los u que pertenecen a
DOM(w). Por ejemplo, cualquier formula de la forma
9u (R(u; : : : ) ^    ) (4.6)
cumple (2), y cualquier formula de la forma
8u (:R(u; : : : ) _    ) o tambien 8u (R(u; : : : ) !    ) (4.7)
cumple (3). Observe que, en la de nicion de seguridad, no asumimos que cualquier variable
libre de w, excepto u, tenga necesariamente valores en DOM(w). Las reglas (2) y (3) deben
sostenerse independientemente del valor de estas variables.
Todas las variables que aparezcan en una WFF deben formar parte, como mnimo, de un
atomo difuso de pertenencia. As, una variable tiene el dominio del atributo que le corresponda
segun la posicion de esa variable en el atomo. Esa variable solo puede tomar los valores que
tenga ese atributo en esa relacion (o relaciones). En algunas versiones del calculo relacional
(como QUEL [89]), se puede establecer previamente el rango de cada variable, de forma que
la formula queda, en algunos casos, ligeramente simpli cada.
En calculo relacional difuso, debido a las caractersticas difusas de su entorno de trabajo y a
que podemos establecer umbrales de cumplimiento, a veces puede ser util utilizar expresiones
no seguras desde un punto de vista estricto y manejarlas como si fueran seguras, esto es,
manejarlas, a traves de la llamada \evaluacion limitada", restringiendo su evaluacion solo con
valores en DOM( ).
De nicion 4.1 En Calculo Relacional Difuso diremos que una expresion es segura si, es-
tableciendo todos sus umbrales a 1, la expresion es segura considerandola desde un punto de
vista clasico. Todas las expresiones se evaluaran, segun la \evaluacion limitada", como si
104 CAPITULO 4. CALCULO
 RELACIONAL DIFUSO
fueran seguras: Para calcular el resultado de la consulta sera obligatorio que todos los va-
lores del resultado pertenezcan a DOM( ). O sea, el resultado siempre se restringe
exclusivamente a valores en DOM( ).
Ademas, los valores de DOM( ) pueden estar relacionados entre s formando las tuplas
de las relaciones. tu
En formulas con el formato de la ecuacion 4.6, DOM( ) se restringe a los valores contenidos
en la relacion R.
La de nicion anterior es logica, ya que no tiene sentido considerar todas las posibles tuplas
de nuestro universo, que pueden ser in nitas. En su lugar, como en el calculo clasico, solo
trataremos con tuplas que existan en las relaciones pertinentes de nuestra base de datos. En
la siguiente seccion se estudian unos casos en los que se aclara esto.

4.2 Capacidad Expresiva del Calculo Relacional Difuso de Do-


minios
Para cualquier expresion del algebra relacional difuso existe una expresion equivalente en
calculo relacional difuso de dominios. Esta a rmacion es basica para la completitud relacional
y sera demostrada mas adelante (Teorema 4.1).
En esta seccion, primero vamos a expresar los operadores primitivos del algebra relacional
en calculo relacional difuso de dominios (union, diferencia, producto cartesiano, proyeccion
y seleccion). Posteriormente, expresaremos en calculo otros operadores no primitivos del
algebra (interseccion, division y reunion).
Las consultas con el calculo difuso son especialmente expresivas por dos motivos principal-
mente: El calculo es no procedimental y por tanto debemos indicar solo lo que queremos (no
como obtenerlo), y, ademas, podemos establecer unos umbrales ( ) que nos regulen el grado
de cumplimiento mnimo que deseamos que tengan los valores de las tuplas del resultado.
En bases de datos clasicas el grado de cumplimiento debe ser siempre maximo, objetivo
que se consigue con = 1 en todos los atomos difusos. Eso no indica forzosamente que el aco-
plamiento entre todos los distintos valores difusos sea exacto, sino que existe total posibilidad
de que ambos valores sean (o se re eran) al mismo valor. Naturalmente, si los posibles va-
lores difusos del dominio (etiquetas, distribuciones de posibilidad...) estan convenientemente
de nidos entonces, con = 1 aseguramos un acoplamiento exacto entre los valores compa-
rados. Por valores difusos o etiquetas lingusticas \convenientemente de nidas" entendemos
aquellos valores (x; y) tal que, si son considerados distintos no sean tan parecidos como para
que = (x; y) = 1 (ver ecuacion 4.3).
Hay que destacar que en algunas expresiones no tiene sentido poner un umbral < 1 en
los atomos de pertenencia ya que aplicaremos la \evaluacion limitada". La explicacion a este
hecho la damos a continuacion usando como ejemplo la expresion de la union. En los atomos
en los que puede ser util poner un umbral < 1 lo indicamos explcitamente.

4.2.1 Operadores Primitivos del A lgebra


Los operadores primitivos del algebra difuso, expresados en calculo relacional difuso de do-
minios, son los siguientes:

4.2. CAPACIDAD EXPRESIVA DEL CALCULO RELACIONAL DIFUSO 105

1. Union Difusa (Fuzzy Union ): Sean R y R0 dos relaciones de grado n compatibles


respecto de la union (con igual numero y tipo de sus atributos). La union de ambas
relaciones viene dada por la siguiente expresion en calculo:
R [ R0 = fx1 ; : : : ; xn j R(x1 ; : : : ; xn ) _ R0 (x1 ; : : : ; xn)g (4.8)
En palabras, esa expresion produce el conjunto de tuplas (x1 ; : : : ; xn ) tales que estan
en R o en R0 . Ver Ejemplo 4.6 en la seccion 4.4.
En la expresion de la union no tiene sentido poner un umbral < 1 en los atomos
de pertenencia. Cada tupla del resultado pertenecera con grado 1 a una de las dos
relaciones: R o R0 . El grado de pertenencia a la otra relacion no nos importa. Esa
expresion es segura desde un punto de vista clasico, por lo que decimos que es segura
en nuestro Calculo Relacional Difuso. Sin embargo, desde un punto de vista difuso esa
expresion no es segura, ya que podran existir tuplas que cumplieran y con todos o
alguno de sus elementos fuera de DOM( ). Esa situacion ocurrira con mayor frecuencia
cuanto menor fueran los umbrales. En tal caso, como hemos indicado, el resultado se
restringe a valores que pertenezcan a DOM( ). Con esa restriccion los umbrales de
cumplimiento pierden su sentido, y por eso no son colocados en la expresion.
2. Diferencia Difusa (Fuzzy Di erence ): Sean R y R0 dos relaciones de grado n compa-
tibles respecto de la union. La diferencia entre ambas relaciones se expresa como:
R R0 = fx1 ; : : : ; xn j R(x1 ; : : : ; xn ) ^ :R0 (x1 ; : : : ; xn)  g (4.9)
En palabras, esa expresion produce el conjunto de tuplas (x1 ; : : : ; xn ) tales que estan
en R y no pertenecen a R0 con un grado mayor o igual que . Con = 1 tenemos
una diferencia similar al estilo clasico. Con < 1 se eliminaran tambien del resultado
aquellas tuplas de R que pertenezcan a R0 en un grado su cientemente grande ( ). Esa
pertenencia a R0 se calculara por la ecuacion 4.2. Ver Ejemplo 4.13 en la seccion 4.4.
Igualmente, aqu no tiene sentido poner un umbral < 1 en el atomos de R, ya que,
para que la expresion sea segura, las tuplas (x1 ; : : : ; xn ) que seran evaluadas seran las
de R, que pertenecen a R con grado 1. Tambien podran evaluarse las tuplas de R0 , pero
estas pertenecen a R0 con grado 1, y 1  , por lo que dichas tuplas nunca apareceran
en el resultado (independientemente de su grado de pertenencia a R).
3. Producto Cartesiano Difuso (Fuzzy Cartesian Product o Times ): Sean R y R0 dos
relaciones de grado n y m respectivamente. El producto cartesiano de ambas relaciones
se expresa como:
R  R0 = fx1 ; : : : ; xn ; v1 ; : : : ; vm j R(x1 ; : : : ; xn) ^ R0(v1 ; : : : ; vm )g (4.10)
En palabras, esa expresion produce el conjunto de todas las tuplas posibles (x1 ; : : : ; xn ;
v1 ; : : : ; vm ) tales que (x1 ; : : : ; xn ) pertenece a R y (v1 ; : : : ; vm ) pertenece a R0 .
4. Proyeccion Difusa (Fuzzy Projection ): Sean R una relacion de grado n y (A1 ; : : : ; Ak )
un conjunto de atributos de R con k < n. Entonces, la proyeccion de R sobre esos
atributos se expresa como:
P (R; A1 ; : : : ; Ak ) = fx1 ; : : : ; xk j 9xk+1; : : : ; xn R(x1; : : : ; xn)g (4.11)
106 CAPITULO 4. CALCULO
 RELACIONAL DIFUSO
Hemos supuesto que los atributos sobre los que proyectamos son los k primeros para
simpli car la expresion. La extrapolacion en el caso de que no sean los primeros es
trivial. Esa expresion produce una relacion similar a R, pero eliminando los atributos
sobre los que no se proyecta. Ver Ejemplos 4.12 y 4.13 en la seccion 4.4.
5. Seleccion Difusa (Fuzzy Selection ): Sean R una relacion de grado n y F una formula
que expresa la condicion que deben cumplir las tuplas de R. Entonces, la seleccion en
R con la condicion F se expresa como:
S (R; F ) = fx1 ; : : : ; xn j R(x1 ; : : : ; xn ) ^ F 0 g (4.12)
donde F 0 es la formula F con cada operando i, denotando el i-esimo componente,
reemplazado por xi . Esa expresion produce una relacion con las tuplas de R que cumplen
el predicado F (o la WFF F 0 ). Ver Ejemplo 4.12 en la seccion 4.4.
4.2.2 Operadores No Primitivos del A lgebra
Hay otros operadores muy utiles del algebra relacional que no son primitivos, es decir, pue-
den ser expresados en terminos de los operadores primitivos. Vamos a expresar en Calculo
Relacional Difuso los mas tpicos:
1. Interseccion Difusa (Fuzzy Intersection ): Sean R y R0 dos relaciones de grado n
compatibles respecto de la union. La interseccion de ambas relaciones viene dada por
la siguiente expresion en calculo:
R \ R0 = fx1 ; : : : ; xn j R(x1 ; : : : ; xn )  ^ R0 (x1 ; : : : ; xn)  0 g (4.13)
En palabras, esa expresion produce el conjunto de tuplas (x1 ; : : : ; xn ) tales que perte-
necen a R (en grado mnimo ) y pertenecen a R0 (en grado mnimo 0 ).
Si observamos esa expresion vemos que podran existir tuplas que pertenezcan a R y a
R0 con grado mayor que y 0 respectivamente y cuyos valores no esten en DOM( ).
Para calcular el resultado se aplicara la \evaluacion limitada" restringiendolo a tuplas
con valores que pertenezcan a DOM( ). Con esa restriccion tenemos que el umbral de
cumplimiento del atomo de R sera util en las tuplas de R0 (ya que las de R pertenecen
a R con grado 1). Igualmente, el umbral 0 del atomo de R0 se aplica a las tuplas de R.
As, se considerara que una tupla de R pertenece a la interseccion si pertenece a R0 en
grado mnimo 0 . Si = 0 = 1 tenemos una interseccion similar al estilo clasico. Ver
Ejemplo 4.7 en la seccion 4.4.
2. Reunion Difusa (Fuzzy Join ): Sean R y R0 dos relaciones de grado n y m. La reunion
de ambas relaciones se expresa como:
R ./ R0 = fx1 ; : : : ; xn ; v1 ; : : : ; vm j R(x1 ; : : : ; xn ) ^ R0(v1 ; : : : ; vm ) ^  (xi ; vj )  g
 (xi ;vj )
(4.14)
con i 2 f1; : : : ; ng y j 2 f1; : : : ; mg. En palabras, esa expresion produce el conjunto
de tuplas (x1 ; : : : ; xn ; v1 ; : : : ; vm ) tales que (x1 ; : : : ; xn ) pertenece a R, (v1 ; : : : ; vm )
pertenece a R0 y cumplen que
 (xi ; vj ) 

4.2. CAPACIDAD EXPRESIVA DEL CALCULO RELACIONAL DIFUSO 107

siendo xi y vj dos variables con dominio en atributos de R y R0 respectivamente.


Observese que una reunion es una seleccion sobre el producto cartesiano.
La reunion natural (natural join ) es una variante en la que se comparan todos los
atributos con igual nombre en ambas relaciones usando el comparador difuso \posible-
mente igual" (ecuacion 4.3) y en la que se puede eliminar del resultado uno de cada dos
atributos que comparamos. En una reunion natural difusa puede interesar no eliminar
ningun atributo o mezclar, de alguna forma, los dos atributos en un unico atributo.
3. Division Difusa (Fuzzy Quotient o Division ): La de nicion del operador division del
algebra relacional clasico esta incluida en el apartado 1.2.4.1.
Sean R y R0 dos relaciones de grado n + m y m respectivamente, siendo los atributos
de R0 de igual tipo a los ultimos m atributos de R, de nidas como:

R(a1 ; : : : ; an ; b1 ; : : : ; bm )
R0(b1 ; : : : ; bm )

Entonces, la Division Relacional, R  R0 , se puede expresar como la siguiente consulta:


Dame las tuplas (a1 ; : : : ; an ) de R que se relacionan (en R) con todas las tuplas de
R0 (en grado mnimo ). En bases de datos difusas la forma de relacionarse sera por
similitud (no por igualdad). Por tanto, podemos dar un grado de cumplimiento a esa
similitud.
En Calculo Relacional Difuso de Dominios esa consulta se obtiene por la siguiente
expresion:

R  R0 = fa1 ; : : : ; an j 8b1 ; : : : ; bm (R0(b1 ; : : : ; bm ) ! R(a1 ; : : : ; an ; b1 ; : : : ; bm )  )g


(4.15)

Esa expresion produce el conjunto de tuplas A = (a1 ; : : : ; an ) tal que si B = (b1 ; : : : ; bm )


pertenece a R0 entonces (A; B ) pertenece a R en grado mnimo .
Observe que el atomo de R tiene un umbral de cumplimiento . Esto hace posible que
en el resultado haya tuplas que cumplen parcialmente la condicion de la consulta. Si
establecemos = 1 solo se recuperaran las tuplas (a1 ; : : : ; an ) de R que se relacionan
(en R) con todos los valores de R0 de forma exacta. O sea, si = 1 tenemos una division
al estilo clasico. Con < 1 tendremos en el resultado ademas tuplas que se parecen a
todas las de R0 en grado mnimo . Ver Ejemplo 4.12 en la seccion 4.4.
Puede verse facilmente que esta de nicion de la division relacional difusa es totalmente
equivalente a la de nida en el captulo anterior [72] pero aplicando, a esta ultima, una
seleccion de forma que obtengamos solamente las tuplas con grado mayor o igual que
el umbral . Ademas, como se vera en el apartado 4.3, el procedimiento que de nimos
para obtener los grados de cumplimiento del resultado obtiene los mismos grados que
los obtenidos aplicando la division relacional difusa del captulo anterior.
108 CAPITULO 4. CALCULO
 RELACIONAL DIFUSO

4.2.3 Traduccion de A lgebra Relacional Difuso a Calculo Relacional Difuso


de Dominios
Teorema 4.1 Toda expresion E en algebra relacional difusa se puede expresar con una ex-
presion segura del calculo relacional difuso de dominios.
Demostracion: Basandonos en lo dicho anteriormente, para la demostracion operaremos
por induccion sobre el numero de operadores de la expresion E: Si E no tiene operadores se
trata de una unica relacion R, sin operar sus datos de ninguna forma. En ese caso, si R tiene
grado n la expresion en calculo de dominios es:
R = fx1 ; : : : ; xn j R(x1 ; : : : ; xn )g
En el caso de que E tenga uno o mas operadores, se procedera segun el operador principal.
El operador principal puede ser la Union (E=E1 [E2 ), la Diferencia (E=E1 E2 ), el Producto
Cartesiano (E=E1 E2 ), la Proyeccion (E=P (E1 ; A1 ; : : : ; Ak )) o la Seleccion (E=S (E1 ; F )).
En cada caso, se aplica respectivamente la ecuacion 4.8, 4.9, 4.10, 4.11 y 4.12 sustituyendo los
atomos de pertenencia de R y R0 en las ecuaciones por las WFF de las expresiones en calculo
de E1 y E2 respectivamente. tu
Ejemplo 4.2 Consideremos la formula clasica de la Division Relacional, expresada en la
ecuacion 1.4. Para pasarla a una expresion en Calculo Relacional Difuso de Dominios su-
pondremos que A = (a1 ; : : : ; an ) y que el resto de atributos es B = (b1 ; : : : ; bm ). Entonces,
tenemos que:

A (R)  fA j 9B R(A; B )g
A (R)  R0  fA; B j 9B (R(A; B )) ^ R0 (B )g
(A (R)  R0 ) R  fA; B j 9B (R(A; B )) ^ R0 (B ) ^ :R(A; B )  g
A ((A (R)  R0 ) R)  fA j 9B (9B (R(A; B )) ^ R0 (B ) ^ :R(A; B )  )g
Con lo que construimos la expresion de nitiva, equivalente a la division relacional y en la
que hemos eliminado el segundo 9B (R(A; B )) ya que su mision era delimitar el dominio de
A y eso ya lo hace el primero:

R  R0 = A(R) A ((A (R)  R0) R) (4.16)


 fA j 9B (R(A; B )) ^ :9B (R0 (B ) ^ :R(A; B )  )g
Puede verse que esta expresion es equivalente a la mostrada en la ecuacion 4.15. tu
4.3 Calculo de la Relacion Difusa Resultante
Con lo visto hasta el momento ya podemos escribir cualquier expresion en este Calculo Re-
lacional Difuso de Dominios. Sin embargo, en bases de datos difusas es muy util saber el
grado de cumplimiento con el que un determinado valor cumple o satisface una condicion.
En particular, el modelo GEFRED cuenta con los llamados \atributos de compatibilidad",
los Cj de cada atributo Aj de cada relacion difusa generalizada (ver De nicion 2.2). Para
calcular los valores de Cj , los cij llamados \grados de compatibilidad" de cada atributo en
una tupla, de niremos el Grado de una variable de dominio en una WFF:

4.3. CALCULO  DIFUSA RESULTANTE
DE LA RELACION 109

4.3.1 Grado de una variable en una WFF con una sustitucion


Vamos a de nir una funcion  que se aplicara a una WFF . Esta funcion devolvera el grado
con el que un valor concreto, de una tupla concreta, satisface el predicado . A la funcion
habra que indicarle que valor (x) y de que tupla (S ) queremos evaluar: Sx . Para este calculo
no tendremos en cuenta los umbrales de cumplimiento, , de los atomos de .
De nicion 4.2 Sea E el conjunto de todas las expresiones seguras del Calculo Relacional
Difuso de Dominios, el conjunto de todas las WFF de E , (x1 ; : : : ; xn ) 2 es una WFF
con todos los xi como unicas variables libres, y x una variable de dominio (que puede aparecer
o no en ). Entonces, para evaluar si es Verdad o Falso tenemos que sustituir las variables
libres en por unos valores (s1 ; : : : ; sn ) a los que llamaremos sustitucion S .
Supondremos, por el lema 4.1, que en hay como maximo los tres tipos de operadores
basicos: negacion (:), disyuncion (_) y cuanti cador existencial (9).
Entonces, de nimos recursivamente lo que llamamos Grado de una variable de do-
minio x en una WFF con una sustitucion S , notado por Sx ( ), como una funcion:
Sx : ! [0; 1] [  (4.17)
Sx ( ) 2 [0; 1] [ 
donde  es una constante con el requisito de que  62 [0; 1]. Esta constante indica que el Grado
de la variable x en no es aplicable o carece de sentido. Nosotros supondremos que  < 0
(para simpli car la de nicion de la disyuncion).
Atendiendo al tipo de operador con mas precedencia de , se pueden dar 4 casos:
1. Sin operadores: En este caso es un atomo difuso y distinguiremos entre los dos
tipos de atomos difusos: Pertenencia y Comparacion.
2. Negacion.
3. Disyuncion.
4. Cuanti cador existencial.
Vamos a estudiar esos 4 casos para hallar el valor de Sx ( ). La de nicion es recursiva,
donde el caso base es el caso 1 (cuando es un atomo). En el resto de los casos, el grado
en se obtiene en funcion de los grados en las subformulas obtenidas al evaluar el operador
con mas precedencia en :
1. Sin operadores ( es un atomo): En este caso, se atendera al tipo de atomo que sea:
(a) Pertenencia:
8 R(K )
>
< (S; K ) si no hay variables en el atomo
Sx (R(x1 ; : : : ; xn ; K )  ) = > R si x = Ai y @Ci
: minfcri; R(S; K )g si x = Ai y 9Ci
en otro caso
(4.18)
donde:
110 CAPITULO 4. CALCULO
 RELACIONAL DIFUSO

IF @ variables en el atomo
RETURN R(K )
ELSE
IF = x Ai con i 2 f1; : : : ; n + pg THEN (* Si x es un atributo de R *)
IF 9Ci en R THEN
Buscar la r-esima tupla de R tal que sea la tupla
mas parecida a (S; K ) en R con mayor cri:
RETURN minfcri ; R(S; K )g
ELSE (* @Ci *)
RETURN R(S; K )
END IF
ELSE (* Si x NO es un atributo de R *)
RETURN 
END IF
END IF

Figura 4.1: Algoritmo para calcular el grado Sx en un atomo de Pertenencia.

 R es una relacion difusa generalizada de grado n + p.


 K es una lista con todas las constantes (k1 ; : : : ; kp) que aparecen en el atomo.
 Los valores de R(S; K )=R(s1 ; : : : ; sn; k1 ; : : : ; kp ) y R(K ) se calculan por la
formula de la ecuacion 4.2.
 Ai con i 2 f1; : : : ; ng, es un atributo de R. La comparacion x = Ai indica que
la variable x tiene el dominio del atributo Ai .
 cri es un valor del atributo de compatibilidad Ci de R, asociado al atributo
Ai , de una tupla r tal que su componente de valor (der1 ; : : : ; dern ) es la tupla
mas parecida a (S; K ) en R. La tupla mas parecida a (S; K ) en una relacion
siempre existe e incluso puede haber varias con igual similitud. En caso de que
existan varias se tomara la que tenga mayor cri .
Calcular el grado Sx en un atomo de Pertenencia R(x1 ; : : : ; xn ; K ) es simple,
siguiendo el algoritmo de la Figura 4.1.
Para \Buscar la tupla r-esima de R tal que sea la tupla mas parecida a (S; K )
en R con mayor cri " y devolver (con RETURN) el resultado pertinente, podemos
usar el algoritmo de la Figura 4.2, donde suponemos que R tiene m tuplas y donde
renombramos la tupla (S; K ) a Y = (y1 ; : : : ; yn+p).
(b) Comparacion:
8  (s ; y)
< i si xi es una variable y x = xi
Sx ( (xi ; y)  ) = :  (xi ; y) si xi es una constante (de x) (4.19)
 en otro caso
donde si es el valor de S correspondiente a la variable xi . Con x = xi indicamos
que ambas variables son la misma variable (tienen el mismo dominio).

4.3. CALCULO  DIFUSA RESULTANTE
DE LA RELACION 111

G := 0 (* Mayor similitud: ( ) *) R S; K
C := 0 (* Mayor grado de compatibilidad: ri *) c
t
FOR := 1 TO DO m (* Para cada tupla de ... *) R
f
M := minw=1;:::;n+p = ( tw w ) de ; y g
(* M := Similitud entre y la - Y
esima tupla *) t
IF G <
M THEN
G := M
C := ti c
ELSE
IF G = M AND C ti THEN <c
C := ti c
END IF
END IF
END FOR
RETURN min C G f; g
Figura 4.2: Algoritmo para \Buscar la tupla r-esima de R tal que sea la tupla mas parecida
a (S; K ) en R con mayor cri ".

2. Negacion: (x1 ; : : : ; xn ) = : 1 (x1 ; : : : ; xn )


1 Sx ( 1 (x1 ; : : : ; xn )) si Sx ( 1 (x1 ; : : : ; xn )) 6= 
Sx ( (x1 ; : : : ; xn )) =  en otro caso
(4.20)

3. Disyuncion: (x1 ; : : : ; xn ) = 1 (u1 ; : : : ; up ) _ 2 (v1 ; : : : ; vq ), donde cada uj es un xk


distinto y cada vj es un xk distinto, aunque algunos de los u's pueden coincidir con
algunos de los v's.

Sx ( (x1 ; : : : ; xn )) = maxfSx ( 1 (u1 ; : : : ; xp )); Sx ( 2 (v1 ; : : : ; vq ))g (4.21)

Al ser  < 0 aseguramos que el grado en una disyuncion va a ser  solo si son  los
grados de ambas partes de la disyuncion.
4. Cuanti cador existencial: (x1 ; : : : ; xn ) = 9xn+1 ( 1 (x1 ; : : : ; xn+1 ))
Sx ( (x1 ; : : : ; xn )) = max fSx ( 1 (x1 ; : : : ; xn ; sn+1))g (4.22)
sn+1 2DOM( )

Observe que DOM( )=DOM( 1). A 1 le llamaremos subformula del 9. Observe que al
evaluar el grado de 1 , sn+1 sera una constante y sera tratada como tal. Naturalmente,
el valor de sn+1 estara dentro del dominio de la variable xn+1 .
tu
112 CAPITULO 4. CALCULO
 RELACIONAL DIFUSO
B
B1 B2 B3
1

0.75

0.5

0
1 2 3 4 5 6 7 8 9 10 11

C
1
C1 C2 C3

0.66

0.25

0
1 2 3 4 5 6 7 8 9 10 11

Figura 4.3: Ejemplo 4.3: De nicion de etiquetas sobre los atributos B y C.

Ejemplo 4.3 Sea R una relacion con dos atributos, B y C, que tienen de nidas las etiquetas
de la Figura 4.3. Ademas, supondremos que aun no hay atributos de compatibilidad en R.
Sea la siguiente WFF:
(b; c) = R(b; c) ^ (= (b; B2)  0:7 ! =(c; C2)  0:5)
donde = es el comparador difuso generalizado de la ecuacion 4.3.
Entonces, si tenemos una sustitucion S = (B3; C1) 2 R, podremos calcular Sc ( (b; c)).
Para ello, apliquemos el lema 4.1 a , obteniendo que
(b; c) = :(:R(b; c) _ :(:=(b; B2)  0:7 _ =(c; C2)  0:5))
Una forma muy simple de hallar Sc ( (b; c)) es seguir los siguientes 3 pasos:
1. Sustituir en todos sus atomos por los grados de la misma variable c en cada atomo
con la misma sustitucion S :
Sc ( (b; c))  :(:Sc (R(b; c)) _ :(:Sc (= (b; B2)  0:7) _ Sc (= (c; C2)  0:5)))

2. Hallar cada grado de cada atomo independientemente y sustituirlo en su lugar:


Sc ( (b; c))  :(:1 _ :(: _ 0:66))

4.3. CALCULO  DIFUSA RESULTANTE
DE LA RELACION 113

3. Operar segun la De nicion 4.2. En general, lo que se hace es quedarse con los valores
que son distintos de . Los operadores se van resolviendo de mayor a menor prioridad:
Sc ( (b; c))  :(1 1 _ :( _ 0:66))
 :(0 _ :(0:66))
 :(0 _ (1 0:66))
 :(0 _ 0:34)
 :(0:34)
 1 0:34
 0:66
De igual forma, podemos calcular el grado de b en con la misma sustitucion S = (B3; C1):
Sb ( (b; c))  :(:Sb (R(b; c)) _ :(:Sb (= (b; B2)  0:7) _ Sb (= (c; C2)  0:5)))
 :(:1 _ :(:0:75 _ ))
 :(1 1 _ :(1 0:75 _ ))
 :(0 _ :(0:25))
 :(:(0:25))
 0:25
La constante  podemos verla como un smbolo que nos indica que debemos eliminar esa
parte y centrarnos en otra. tu
A la luz del ejemplo anterior podemos construir el siguiente lema que simpli ca algunas
operaciones en el caso de que exista un operador de conjuncion:
Lema 4.2 Sea una WFF cuyo operador principal es el operador de conjuncion ^, es
decir, la formula es del tipo (x1 ; : : : ; xn ) = 1 (u1 ; : : : ; up ) ^ 2 (v1 ; : : : ; vq ), donde cada uj
es un xk distinto y cada vj es un xk distinto, aunque algunos de los u's pueden coincidir con
algunos de los v's. En ese caso:
8 S ( (u ; : : : ; x ))
>
< x 1 1 p si Sx ( 1 ) 6=  y Sx ( 2 ) = 
S
x ( 2 (v1 ; : : : ; vq ))
Sx ( (x1 ; : : : ; xn )) = min si Sx ( 1 ) =  y Sx ( 2 ) 6= 
: fSxx (( 21 ((vu11;; :: :: :: ;; vxqp))));g en otro caso
S
>
(4.23)
Demostracion: Por el lema 4.1 (ley de DeMorgan) tenemos que:
(x1 ; : : : ; xn ) = :(: 1 (u1 ; : : : ; up ) _ : 2 (v1 ; : : : ; vq ))
Sean
= Sx ( 1 (u1 ; : : : ; xp ))
= Sx ( 2 (v1 ; : : : ; vq ))
Se pueden dar 4 casos distintos:
114 CAPITULO 4. CALCULO
 RELACIONAL DIFUSO
1. 6=  y = : En este caso el resultado que obtenemos segun este lema es . Por la
De nicion 4.2 obtenemos tambien el mismo resultado:
Sx ( (x1 ; : : : ; xn ))  :(: _ :)  :(1 _ )  :(1 )  1 (1 ) =
2. =  y 6= : En este caso el resultado segun este lema es . Por la De nicion 4.2
obtenemos tambien :
Sx ( (x1 ; : : : ; xn ))  :(: _ : )  :( _ 1 )  :(1 )  1 (1 ) =
3. 6=  y 6= : El resultado es minf ; g, igual que el obtenido por la De nicion 4.2:
Sx ( (x1 ; : : : ; xn ))  :(: _ : )  1 maxf1 ; 1 g = minf ; g
4. =  y = : Por este lema obtenemos como resultado minf; g = , igual que el
obtenido por la De nicion 4.2:
Sx ( (x1 ; : : : ; xn ))  :(: _ :)  :( _ )  :  
Si tomaramos  > 1 podramos simpli car la ecuacion 4.23 tomando solo el tercer caso,
pero la ecuacion 4.21 de la disyuncion no quedara tan simple. tu
Presentamos otros dos lemas que pueden simpli car el calculo de la funcion  cuando
existen operadores de implicacion (!) o cuanti cadores universales (8).
Lema 4.3 Sea una WFF cuyo el operador principal es el operador de implicacion !, es
decir, la formula es del tipo (x1 ; : : : ; xn ) = 1 (u1 ; : : : ; up ) ! 2 (v1 ; : : : ; vq ), donde cada uj
es un xk distinto y cada vj es un xk distinto, aunque algunos de los u's pueden coincidir con
algunos de los v's. En ese caso:
8 1 S ( (u ; : : : ; x )) si S ( ) 6=  y S ( ) = 
>
< x 1 1
S ( 2 (v1 ; : : : ; vq ))
p x 1 x 2
S ( 1 ) =  y S ( 2 ) 6= 

Sx ( (x1 ; : : : ; xn )) = maxx si x x
>
: f1  S ( 1 ); S ( 2 )g si S ( 1 ) 6=  y S ( 2 ) 6= 
x x x x
si Sx ( 1 ) =  y Sx ( 2 ) = 
(4.24)
Demostracion: Por el lema 4.1 tenemos que:
(x1 ; : : : ; xn ) = : 1 (u1 ; : : : ; up ) _ 2 (v1 ; : : : ; vq )
Sean
= Sx ( 1 (u1 ; : : : ; xp ))
= Sx ( 2 (v1 ; : : : ; vq ))
Se pueden dar 4 casos distintos:
1. 6=  y = : En este caso el resultado que obtenemos segun este lema es 1 . Por
la De nicion 4.2 obtenemos tambien el mismo resultado:
Sx ( (x1 ; : : : ; xn ))  : _   (1 ) _   1

4.3. CALCULO  DIFUSA RESULTANTE
DE LA RELACION 115

2. =  y 6= : En este caso el resultado segun este lema es . Por la De nicion 4.2


obtenemos tambien :
Sx ( (x1 ; : : : ; xn ))  : _   _ 
3. 6=  y 6= : El resultado es maxf1 ; g, igual que el obtenido por la De nicion
4.2:
Sx ( (x1 ; : : : ; xn ))  : _  (1 ) _  maxf1 ; g
4. =  y = : Por este lema obtenemos como resultado , igual que el obtenido por
la De nicion 4.2:
Sx ( (x1 ; : : : ; xn ))  : _    _   
tu
Lema 4.4 Sea una WFF cuyo el operador principal es cuanti cador universal 8, es
decir, la formula es del tipo (x1 ; : : : ; xn ) = 8xn+1 1 (x1 ; : : : ; xn+1 ). Entonces:

Sx ( (x1 ; : : : ; xn )) = min fSx ( 1 (x1 ; : : : ; xn; sn+1))g (4.25)


sn+1 2DOM( )
A 1 le llamaremos subformula del 8. Observe que al evaluar el grado de 1 , sn+1 sera
una constante y sera tratada como tal.
Demostracion: Por el lema 4.1 tenemos que:
(x1 ; : : : ; xn ) = :9xn+1 : 1 (x1 ; : : : ; xn+1 )
Sean ( 1 ; : : : ; f ) todos los f valores de sn+1, y sea
i = Sx ( 1 (x1 ; : : : ; xn ; i ))
con i = 1; : : : ; f . Entonces, segun este lema el resultado que obtenemos es:
Sx ( (x1 ; : : : ; xn )) = minf 1 ; : : : ; f g
Por la De nicion 4.2 el resultado es:
Sx ( (x1 ; : : : ; xn ))  :Sx (9xn+1 : 1 (x1 ; : : : ; xn+1 ))
 1 maxf1 1 ; : : : ; 1 f g
Podemos ver que ambos resultados son equivalentes. tu
4.3.2 Relacion Difusa Generalizada Resultante
Con los elementos de nidos anteriormente podemos indicar que que el resultado de una ex-
presion segura en calculo relacional difuso de dominios de la forma:
fx1 ; x2; : : : ; xn j (x1 ; x2 ; : : : ; xn)g
es una relacion difusa generalizada R como la siguiente:
 H = f(A : D [; C ]); : : : ; (A : D [; C ])g
R = B = f(A1 : de 1 [; c 1 ]); : : : ; (An : den [; c n ])g
1 r1 r1 n rn rn
con r = 1; 2; : : : ; m, siendo m el numero de tuplas de la relacion y cuyas componentes H y
B, se obtienen de la siguiente forma:
116 CAPITULO 4. CALCULO
 RELACIONAL DIFUSO
1. Calcular la componente de valor del cuerpo, f(A1 : der1 ); : : : ; (An : dern )g, com-
puesta por todas las tuplas (der1 ; : : : ; dern ) que cumplen (hacen cierto) el predicado
(der1 ; : : : ; dern ). Llamamos m al numero de tuplas que cumplen el predicado.
2. La componente de compatibilidad del cuerpo, f[cr1 ]; : : : ; [; crn ]g, se calcula des-
pues, teniendo en cuenta que en la cabecera existe el atributo de compatibilidad Ci ,
con i 2 [1; n], si y solo si Sxir ( (x1 ; : : : ; xn )) 6= , para todas las sustituciones Sr =
(der1 ; : : : ; dern ) con r = 1; 2; : : : ; m. Es facil observar que si el grado vale  para una
sustitucion, valdra tambien  para todas las demas. Entonces, si existe el atributo Ci ,
sus grados de compatibilidad, para todas las m tuplas se calculan de la siguiente forma:
cri = Sxir ( (x1 ; : : : ; xn)) (4.26)
donde r = 1; 2; : : : ; m y Sr = (der1 ; : : : ; dern ) es la r{esima tupla de R. Tambien, podemos
considerar que @Ci (y por tanto podremos eliminarlo) si cri = 1 8r = 1; : : : ; m. Si todas
las tuplas tienen un valor 1 en un atributo de compatibilidad concreto, ese atributo de
compatibilidad no nos aporta ninguna informacion, ya que eso es lo que suponemos si
no existe el atributo de compatibilidad.
Aplicamos la funcion  con las sustituciones Sr , esto es, con todas las tuplas que ya han
satisfecho el predicado de la consulta. Esto podra plantear la pregunta de como obtener
esas tuplas para luego aplicarle la funcion  que les corresponda. Sin embargo, esa pregunta
no tiene demasiado sentido ya que estamos de niendo un calculo relacional y este es, por
de nicion, un lenguaje no procedimental (non procedural ). Es decir, sus expresiones dicen
que deseamos obtener, pero no como obtenerlo. Una vez obtenidas, de alguna forma, las
tuplas del resultado (R), calculamos el grado de compatibilidad de cada valor de cada tupla,
con la funcion .
Ademas, con ligeros retoques a la funcion  (eliminando los valores ), es facil obtener el
grado con el que cada tupla globalmente ha satisfecho la condicion completa.

4.4 Ejemplos de Consultas en Calculo Relacional Difuso


El Calculo Relacional Difuso tiene mayor capacidad expresiva del Calculo Relacional Clasico
del que procede. Para mostrar esa potencia y para aclarar el calculo de la relacion difusa gene-
ralizada resultante de una consulta, en esta seccion daremos una serie de ejemplos con los que
hemos intentado abarcar la inmensa casustica que nos podemos encontrar en una consulta.
Cada uno de los ejemplos siguientes esta enfocado a uno o varios de esos casos particulares,
pero todos estan basados en un mismo contexto, el cual explicamos a continuacion.
Supongamos que tenemos una Base de Datos Relacional Difusa sobre jugadores de ba-
loncesto. Una relacion de la Base de Datos podra tener los atributos (JUGADOR, EQUIPO,
ALTURA, CALIDAD, NUM_CAMISETA...). Para los ejemplos tomaremos una proyecci on de es-
ta supuesta relacion que se muestra en la Tabla 4.3. Los campos ALTURA (que almacena la
altura del jugador) y CALIDAD (que mide la calidad del jugador segun el numero de puntos
medio por partido) permiten almacenar valores difusos (tipo 6 de la Tabla 2.4). Nosotros,
para los ejemplos, usaremos las etiquetas lingusticas de la Figura 4.4.
Hemos eliminado las etiquetas \Muy Bajo" y \Muy Malo", por considerar que profesio-
nalmente no juegan jugadores de esas caractersticas.

4.4. EJEMPLOS DE CONSULTAS EN CALCULO RELACIONAL DIFUSO 117

H JUGADOR EQUIPO ALTURA CALIDAD


B J1 Almera Alto Muy Bueno
J2 Almera Bajo Regular
J3 Cadiz Muy Alto Muy Bueno
J4 Cadiz Bajo Bueno
J5 Cordoba Bajo Muy Bueno
J6 Cordoba Muy Alto Malo
J7 Granada Bajo Malo
J8 Granada Muy Alto Malo
J9 Granada Alto Regular
J10 Huelva Alto Muy Bueno
J11 Jaen Bajo Muy Bueno
J12 Jaen Normal Regular
J13 Jaen Alto Muy Bueno
J14 Jaen Alto Muy Bueno
J15 Malaga Bajo Muy Bueno
J16 Malaga Alto Regular
J17 Malaga Muy Alto Muy Bueno
J18 Sevilla Bajo Bueno
J19 Sevilla Muy Alto Bueno
J20 Sevilla Normal Bueno
Tabla 4.3: Relacion R.
ALTURA
Bajo Normal Alto Muy Alto
1

0.5

0
170 175 180 185 190 195 200 205 210 cm.

CALIDAD
Malo Regular Bueno Muy Bueno
1

0.75

0.5

0
5 10 15 20 25 30 35 40 45 Puntos/Partido

Figura 4.4: De nicion de etiquetas sobre los atributos ALTURA y CALIDAD.


118 CAPITULO 4. CALCULO
 RELACIONAL DIFUSO
H JUGADOR EQUIPO ALTURA CALTURA Sustitucion
B J2 Almera Bajo 1 S1
J4 Cadiz Bajo 1 S2
J5 Cordoba Bajo 1 S3
J7 Granada Bajo 1 S4
J11 Jaen Bajo 1 S5
J12 Jaen Normal 0.5 S6
J15 Malaga Bajo 1 S7
J18 Sevilla Bajo 1 S8
J20 Sevilla Normal 0.5 S9
Tabla 4.4: Relacion R4:4 .

Para los ejemplos usaremos como identi cadores de las variables de dominio las iniciales
del nombre del atributo a cuyo dominio pertenezcan (j , e, a y c). A los predicados, les
llamaremos como hasta ahora . A la relacion resultante de cada ejemplo le llamaremos Ri ,
donde i es el numero del ejemplo.
Ejemplo 4.4 Mostrar los jugadores con sus equipos y alturas de aquellos jugadores Bajos
(en grado mnimo 0.5).
La expresion que resuelve esa consulta sera:

fj; e; a j 9c(R(j; e; a; c) ^ =(a; Bajo)  0:5)g


Primero se calcula la componente de valor, esto es, las tuplas (j; e; a) que cumplen el
predicado. En este caso, existen 9 tuplas que cumplan el predicado: Ver componente de valor
de la relacion resultante mostrada en la Tabla 4.4. Llamaremos Sr con r = 1; : : : ; 9 a las 9
tuplas de la componente de valor. Por comodidad, en la Tabla 4.4 indicamos a la derecha
de cada tupla la sustitucion a la que corresponde. Despues, para calcular la componente
de compatibilidad hay que estudiar que atributos de compatibilidad existen. Los atributos
CJUGADOR y CEQUIPO no los consideraremos en el resultado, ya que tenemos que: 8r = 1; : : : ; 9
cr(JUGADOR) = Sj r ( (j; e; a)) = 1
cr(EQUIPO) = Se r ( (j; e; a)) = 1
Observe que, como en S hay un valor de la clave primaria de R (atributo JUGADOR), para
calcular el grado de la WFF se puede eliminar el 9c, sustituyendo la variable c por el unico
valor posible para cada Si . O sea, como en S hay un valor de la clave primaria, el valor de
c que alcance el grado maximo (ecuacion 4.22) sera el correspondiente a la tupla de su clave
primaria.
El atributo CALTURA existe y para cada Sr tenemos que:
cr(ALTURA) = Sa r ( (j; e; a))
Por ejemplo, para la ultima tupla (jugador \J20") con r = 9, tenemos que:
c9(ALTURA) = Sa 9 ( (j; e; a))
= a(J20;Sevilla;Normal) ( (j; e; a))

4.4. EJEMPLOS DE CONSULTAS EN CALCULO RELACIONAL DIFUSO 119

De donde, si aplicamos el metodo del Ejemplo 4.3, obtenemos que


(J20 ;Sevilla;Normal) ( (j; e; a))  9c(R(J20; Sevilla; Normal; c) ^ = (Normal; Bajo))
a
 R(J20; Sevilla; Normal; Bueno) ^ 0:5
 1 ^ 0:5
 0:5
El cuanti cador existencial lo eliminamos cuando sustituimos todas las ocurrencias de
la variable c por el valor \Bueno", que hace maximo el grado de la subformula del 9. En
particular, ese valor de c es el unico que existe en R con la sustitucion S9 , ya que la sustitucion
contiene un valor de la clave primaria. El grado en ese atomo, con ese valor de c, es 1. Con
otros valores de c su grado es 0. Como es una conjuncion, tomamos el grado mas peque~no de
ambos atomos (segun el lema 4.2). Por eso, con otros valores de c tenemos que minf0; 0:5g = 0
y con c = \Bueno" tenemos que minf1; 0:5g = 0:5. De todos esos valores tomamos el maximo
(ecuacion 4.22), y obtenemos que maxf0; : : : ; 0; 0:5g = 0:5, que es el resultado nal. Habra
tantos ceros como valores de c haya en DOM( ) distintos a \Bueno". tu
Ejemplo 4.5 Obtener los jugadores con sus equipos y alturas de aquellos jugadores de Jaen
o Malaga que son de altura Normal (en grado mnimo 0.5) o Bajos (en grado mnimo 0.7).
La expresion que resuelve esa consulta sera:

fj; e; a j 9c(R(j; e; a; c)
^ (e = Jaen _ e = Malaga)
^ ((=(a; Bajo)  0:7) _ (=(a; Normal)  0:5)) )g
Observe que los atomos como e = Jaen son comparaciones crisp y se podran haber puesto
como comparaciones difusas del tipo = (e; Jaen)  1. Esas comparaciones tomaran el valor
1 si son ciertas y 0 si son falsas. Por motivos de claridad las expresamos como comparaciones
crisp.
La relacion resultante, R4:5 , se muestra en la Tabla 4.5. El atributo CEQUIPO no lo escribimos
porque su valor es 1 para todas las tuplas que se seleccionen, ya que para cualquier sustitucion
Sr = (srj ; sre; sra), se tiene que:

Se r ( (j; e; a))  9c(R(srj ; sre; sra ; c) ^ (sre = Jaen _ sre = Malaga) ^ ( _ ))
 c2DOM(
max f1 ^ (sre = Jaen _ sre = Malaga) ^ g
)
 sre = Jaen _ sre = Malaga
En el primer paso, eliminamos el 9 aplicando la ecuacion 4.22. Ese predicado es una WFF
segura y como la unica relacion que se usa es R, entonces, todos los valores del resultado
estaran en R. Por tanto, el grado en el atomo de pertenencia siempre sera 1 para cualquier
valor de c.
Ademas, tenemos que en la relacion resultante los equipos (sre ) seran de \Jaen" o de
\Malaga", por lo que una de esas dos comparaciones sera igual a 1 y la otra igual a 0. Por
tanto, para cualquier sustitucion Sr , el resultado sera: maxf1; 0g = 1.
120 CAPITULO 4. CALCULO
 RELACIONAL DIFUSO
H JUGADOR EQUIPO ALTURA CALTURA Sustitucion
B J11 Jaen Bajo 1 S1
J12 Jaen Normal 1 S2
J13 Jaen Alto 0.5 S3
J14 Jaen Alto 0.5 S4
J15 Malaga Bajo 1 S5
J16 Malaga Alto 0.5 S6
Tabla 4.5: Relacion R4:5 .

El calculo de CALTURA se hace de la misma forma. Veamos como se calculara para las
tuplas S1 y S6 (Tabla 4.5):

c1(ALTURA) = Sa 1 ( (j; e; a))  9c(R(J11; Jaen; Bajo; c)


^ ( _ )
^ (=(Bajo; Bajo) _ =(Bajo; Normal)) )
 1 ^  ^ (1 _ 0:5)
 minf1; maxf1; 0:5gg = 1
c6(ALTURA) = Sa 6 ( (j; e; a))  9c(R(J16; Malaga; Alto; c)
^ ( _  )
^ (=(Alto; Bajo) _ =(Alto; Normal)) )
 1 ^  ^ (0 _ 0:5)
 minf1; maxf0; 0:5gg = 0:5
En el primer caso la variable c es sustituida por \Muy Bueno" y en el segundo caso
se sustituye por \Regular". Esos son los unicos valores de c que hacen que el grado de la
subformula del 9 sea mayor que 0. tu
Ejemplo 4.6 Partiendo de las relaciones R4:4 (Tabla 4.4) y R4:5 (Tabla 4.5) de los Ejemplos
4.4 y 4.5 respectivamente, la union (en terminos de algebra relacional) de ambas relaciones
correspondera a la consulta: Obtener los jugadores con sus equipos y alturas de aquellos
jugadores que pertenecen a R4:4 o a R4:5 .
La expresion que resuelve esa consulta sera, como en la ecuacion 4.8:

R4:4 [ R4:5 = fj; e; a j R4:4 (j; e; a) _ R4:5 (j; e; a)g


Los valores de los atributos de compatibilidad CJUGADOR y CEQUIPO seran todos igual a 1,
por lo que no los indicamos en la relacion resultante de la Tabla 4.6. Por ejemplo, vamos a
ver como se calculan para las tuplas S6 , S10 y S12 . Observe que para calcular los valores de
compatibilidad debemos aplicar dos veces la ecuacion 4.18 (o su algoritmo):

c6(EQUIPO) = Se 6 ( )  Se 6 (R4:4 (j; e; a)) _ Se 6 (R4:5 (j; e; a))  1 _ 1  1
c10(EQUIPO) = Se 10 ( )  Se 10 (R4:4 (j; e; a)) _ Se 10 (R4:5 (j; e; a))  0 _ 1  1
c12(EQUIPO) = Se 12 ( )  Se 12 (R4:4 (j; e; a)) _ Se 12 (R4:5 (j; e; a))  1 _ 0  1

4.4. EJEMPLOS DE CONSULTAS EN CALCULO RELACIONAL DIFUSO 121

H JUGADOR EQUIPO ALTURA CALTURA Sustitucion


B J2 Almera Bajo 1 S1
J4 Cadiz Bajo 1 S2
J5 Cordoba Bajo 1 S3
J7 Granada Bajo 1 S4
J11 Jaen Bajo 1 S5
J12 Jaen Normal 1 S6
J13 Jaen Alto 0.5 S7
J14 Jaen Alto 0.5 S8
J15 Malaga Bajo 1 S9
J16 Malaga Alto 0.5 S10
J18 Sevilla Bajo 1 S11
J20 Sevilla Normal 0.5 S12
Tabla 4.6: Relacion R4:6 = R4:4 [ R4:5 del Ejemplo 4.6.

H JUGADOR EQUIPO ALTURA CALTURA


B J11 Jaen Bajo 1
J12 Jaen Normal 0.5
J15 Malaga Bajo 1
Tabla 4.7: Relacion R4:7 = R4:4 \ R4:5 del Ejemplo 4.7.

Note que el calculo de cr(JUGADOR) , con r = 1; : : : ; 12, es similar al de cr(EQUIPO) . Para las
mismas tuplas, obtengamos ahora los valores del atributo de compatibilidad CALTURA , sabiendo
que ese atributo existe en R4:4 y en R4:5 :

c6(ALTURA) = Sa 6 ( )  minf0:5; 1g _ minf1; 1g  maxf0:5; 1g = 1


c10(ALTURA) = Sa 10 ( )  0 _ minf0:5; 1g  maxf0; 0:5g = 0:5
c12(ALTURA) = Sa 12 ( )  minf0:5; 1g _ 0  maxf0:5; 0g = 0:5
tu
Ejemplo 4.7 En la misma lnea que el ejemplo anterior, la interseccion (en terminos de
algebra relacional) de ambas relaciones R4:4 y R4:5 correspondera a la consulta: Obtener los
jugadores con sus equipos y alturas que pertenecen a R4:4 y a R4:5 .
La expresion que resuelve esa consulta sera, como en la ecuacion 4.13:

R4:4 \ R4:5 = fj; e; a j R4:4 (j; e; a) ^ R4:5 (j; e; a)g


Los valores de los atributos de compatibilidad CJUGADOR y CEQUIPO son siempre 1, por lo que
no aparecen en la relacion resultante de la Tabla 4.7. El calculo de ambos es muy similar:
Para cualquier sustitucion Sr con r = 1; 2; 3 tenemos que:

cr(EQUIPO) = Se r ( )  1 ^ 1  1
122 CAPITULO 4. CALCULO
 RELACIONAL DIFUSO
H EQUIPO CEQUIPO
B Almera 0.5
Cordoba 1
Granada 1
Jaen 0.5
Malaga 0.5
Tabla 4.8: Relacion R4:8 .

Para el atributo de compatibilidad CALTURA tenemos que:


c1(ALTURA) = c3(ALTURA) = Sa 1 ( ) = Sa 3 ( )  minf1; 1g ^ minf1; 1g  1
c2(ALTURA) = Sa 2 ( )  minf0:5; 1g ^ minf1; 1g  minf0:5; 1g = 0:5
tu
Ejemplo 4.8 Mostrar los equipos que tienen al menos un jugador Malo (en grado mayor o
igual que 0.5):
fe j 9j; a; c(R(j; e; a; c) ^ =(c; Malo)  0:5)g (4.27)
El resultado de esta consulta esta en la Tabla 4.8. Por ejemplo, el valor para CEQUIPO en
la primera tupla S1 , c1(EQUIPO) , lo obtenemos mediante:

Se 1 ( )  9j; a; c(Se 1 (R(j; e; a; c)) ^ Se 1 (= (c; Malo)  0:5))
 maxfSe 1 (R(J1; e; Alto; Muy Bueno) ^ =(Muy Bueno; Malo)  0:5);
Se 1 (R(J2; e; Bajo; Regular) ^ = (Regular; Malo)  0:5) g
 maxfminf1; 0g; minf1; = (Regular; Malo)gg = maxf0; 0:5g = 0:5
Observe que cuando evaluamos el cuanti cador existencial (9), las variables ligadas (j , a
y c) son sustituidas (segun la ecuacion 4.22) por los valores de j , a y c (JUGADOR, ALTURA y
CALIDAD) que hay en DOM( ) para tomar el mayor grado de todas esas sustituciones. En la
ecuacion anterior hemos eliminado aquellos valores de j , a y c que no tienen una tupla en R
con EQUIPO=S1 (Almera), ya que para esos valores el grado en la subformula del 9 es 0.
Al calcular Se 3 ( ) nos encontramos que existen tres valores posibles para las variables j ,
a y c que hacen que el grado en la subformula del 9 sea mayor que 0. Estos tres valores son
los de las tres tuplas de R con EQUIPO=S3 (Granada):

Se 3 ( )  9j; a; c(Se 3 (R(j; e; a; c)) ^ Se 3 (= (c; Malo)  0:5))
 maxfSe 3 (R(J7; e; Bajo; Malo)) ^ Se 3 (=(Malo; Malo)  0:5);
Se 3 (R(J8; e; Muy Alto; Malo)) ^ Se 3 (= (Malo; Malo)  0:5);
Se 3 (R(J9; e; Alto; Regular)) ^ Se 3 (= (Regular; Malo)  0:5) g
 maxfminf1; = (Malo; Malo)g;
minf1; = (Malo; Malo)g;
minf1; = (Regular; Malo)g g
 maxfminf1; 1g; minf1; 1g; minf1; 0:5gg = maxf1; 1; 0:5g = 1

4.4. EJEMPLOS DE CONSULTAS EN CALCULO RELACIONAL DIFUSO 123

H EQUIPO CEQUIPO
B Almera 0.75
Cadiz 1
Cordoba 0.75
Granada 0.66
Huelva 0.75
Jaen 0.75
Malaga 0.75
Sevilla 1
Tabla 4.9: Relacion R4:9 .

H EQUIPO CEQUIPO
B Almera 0.5
Cordoba 0.75
Granada 0.66
Jaen 0.5
Malaga 0.5
Tabla 4.10: Relacion R4:10 .

Al aplicar la ecuacion 4.22, tomaremos el mayor grado de los tres, que puede ser el grado
de la tupla del jugador \J7" o el del jugador \J8", las cuales consiguen ambas grado 1 (la
tupla de \J9" consigue solo grado 0.5). tu
Ejemplo 4.9 Mostrar los equipos en los que existe al menos un jugador Bueno (en grado
mayor o igual que 0.5):
fe j 9j; a; c(R(j; e; a; c) ^ =(c; Bueno)  0:5)g (4.28)
La relacion R4:9 esta en la Tabla 4.9. tu
Ejemplo 4.10 Mostrar los equipos en los que existe al menos un jugador Malo (en grado
mnimo 0.5) y un jugador Bueno (en grado mnimo 0.5):
fe j 9j; a; c(R(j; e; a; c) ^ =(c; Malo)  0:5) ^
9j; a; c(R(j; e; a; c) ^ =(c; Bueno)  0:5)g
El resultado se muestra en la Tabla 4.10. Si observamos los Ejemplos 4.8 y 4.9, se ve
que el predicado de este ejemplo esta formado por la conjuncion de los predicados de ambos
ejemplos. Por tanto, esa consulta es equivalente a la siguiente:
fe j R4:8(j; e; a) ^ R4:9 (j; e; a)g
tu
124 CAPITULO 4. CALCULO
 RELACIONAL DIFUSO
Ejemplo 4.11 Mostrar aquellos equipos en los que todos sus jugadores sean Bajos (en grado
mnimo 0.5) o Buenos (en grado mnimo 0.75):
fe j 8j; a; c (R(j; e; a; c) ! (= (a; Bajo)  0:5 _
=(c; Bueno)  0:75) ) g
La relacion resultante se muestra en la Tabla 4.11. Veamos como obtenemos ese resultado:
Si llamamos 1 a la subformula del 8, tenemos que:
(e) = 8j; a; c 1 (j; e; a; c)
Por ejemplo, para la primera tupla (Tabla 4.11), aplicando el lema 4.4, buscamos los
valores de (j; a; c) en DOM( ) que consiguen un menor grado en 1 con la sustitucion S1 .
Los valores de (j; a; c) tales que (j;Almera; a; c) 2 R obtienen grado 1. Segun eso, tenemos
que hay dos valores para (j; a; c) para los que el grado puede ser menor que 1 (las dos tuplas
del equipo de Almera). En la siguiente ecuacion expresamos solo esos dos valores de (j; a; c):

c1(EQUIPO) = Se 1 ( (e)) = minfSe 1 ( 1 (J1; e; Alto; Muy Bueno));


Se 1 ( 1 (J2; e; Bajo; Regular)) g
Desarrollando esos grados por el lema 4.3 obtenemos que
Se 1 ( 1 (J1; e; Alto; Muy Bueno))  1 ! (0 _ 0:75)  maxf1 1; 0:75g  0:75
Se 1 ( 1 (J2; e; Bajo; Regular))  1 ! (1 _ 0:66)  maxf1 1; 1g  1
y entonces
c1(EQUIPO) = Se 1 ( (e)) = minf0:75; 1g = 0:75
Aplicando el lema 4.1 obtenemos tambien el mismo resultado, teniendo que la consulta es
equivalente a
fe j :9j; a; c : (:R(j; e; a; c) _
= (a; Bajo)  0:5 _
= (c; Bueno)  0:75) g
Si llamamos 2 a esa WFF quitandole la primera negacion y 3 a esa WFF quitandole
tambien el cuanti cador, tenemos que:
(e) = : 2 (e) = :9j; a; c( 3 (j; e; a; c)) = :9j; a; c(: 1 (j; e; a; c))
Entonces, para la primera tupla tenemos que:
c1(EQUIPO) = Se 1 ( (e)) = 1 Se 1 ( 2 (e))
Para resolver Se 1 ( 2 (e)) buscamos los valores de (j; a; c) en DOM( ) que consiguen un
mayor grado en 3 con la sustitucion S1 . Segun eso, tenemos que hay dos valores de (j; a; c)
para los que el grado puede ser mayor que 0. En la siguiente ecuacion expresamos solo esos
dos valores de (j; a; c), que son las dos tuplas del equipo de Almera:

4.4. EJEMPLOS DE CONSULTAS EN CALCULO RELACIONAL DIFUSO 125

H EQUIPO CEQUIPO
B Almera 0.75
Cadiz 0.75
Huelva 0.75
Jaen 0.66
Sevilla 1
Tabla 4.11: Relacion R4:11 .

Se 1 ( 2 (e)) = maxfSe 1 ( 3 (J1; e; Alto; Muy Bueno));


Se 1 ( 3 (J2; e; Bajo; Regular)) g
Desarrollando esos grados obtenemos que
Se 1 ( 3 (J1; e; Alto; Muy Bueno))  :(:1 _ 0 _ 0:75)  :(0:75)  0:25
Se 1 ( 3 (J2; e; Bajo; Regular))  :(:1 _ 1 _ 0:66)  :(1)  0
y entonces
Se 1 ( 2 (e)) = maxf0:25; 0g = 0:25
Por tanto, obtenemos el resultado esperado:
c1(EQUIPO) = Se 1 ( (e)) = 1 Se 1 ( 2 (e)) = 1 0:25 = 0:75
Para la cuarta tupla, S4 , tambien vamos a desarrollar las ecuaciones:
c4(EQUIPO) = Se 4 ( (e))
Ahora tenemos que existen 4 valores de (j; a; c) en DOM( ) que pueden tener un grado
en 1 con la sustitucion S1 menor que 1 (los 4 del equipo de Jaen). En la siguiente ecuacion
expresamos solo esos 4 valores de (j; a; c):
Se 4 ( (e)) = minfSe 4 ( 1 (J11; e; Bajo; Muy Bueno));
Se 4 ( 1 (J12; e; Normal; Regular));
Se 4 ( 1 (J13; e; Alto; Muy Bueno));
Se 4 ( 1 (J14; e; Alto; Muy Bueno)) g
Calculando cada uno de esos grados tenemos que:
Se 4 ( 1 (J11; e; Bajo; Muy Bueno))  1 ! (1 _ 0:75)  maxf1 1; 1g  1
e ( 1 (J12; e; Normal; Regular))  1 ! (0:5 _ 0:66)  maxf1 1; 0:66g  0:66
S 4
Se 4 ( 1 (J13; e; Alto; Muy Bueno))  1 ! (0 _ 0:75)  maxf1 1; 0:75g  0:75
Se 4 ( 1 (J14; e; Alto; Muy Bueno))  1 ! (0 _ 0:75)  maxf1 1; 0:75g  0:75
Con lo anterior, obtenemos que
c4(EQUIPO) = Se 4 ( (e)) = minf1; 0:66; 0:75; 0:75g = 0:66
tu
126 CAPITULO 4. CALCULO
 RELACIONAL DIFUSO
H EQUIPO ALTURA CALIDAD
B Almera Alto Muy Bueno
Almera Bajo Regular
Cadiz Muy Alto Muy Bueno
Cadiz Bajo Bueno
Cordoba Bajo Muy Bueno
Cordoba Muy Alto Malo
Granada Bajo Malo
Granada Muy Alto Malo
Granada Alto Regular
Huelva Alto Muy Bueno
Jaen Bajo Muy Bueno
Jaen Normal Regular
Jaen Alto Muy Bueno
Malaga Bajo Muy Bueno
Malaga Alto Regular
Malaga Muy Alto Muy Bueno
Sevilla Bajo Bueno
Sevilla Muy Alto Bueno
Sevilla Normal Bueno
Tabla 4.12: Relacion R0 para el Ejemplo 4.12.

H ALTURA CALIDAD
B Muy Alto Muy Bueno
Bajo Bueno
Tabla 4.13: Relacion R00 para los Ejemplos 4.12 y 4.13.

Ejemplo 4.12 Dame los equipos que tienen jugadores con iguales caractersticas (en altura
y calidad) que el equipo de Cadiz (en grado mnimo 0.5).
Para resolver esta consulta vamos a considerar dos relaciones R0 y R00 de nidas mediante
las siguientes expresiones:
R0 (e; a; c) = fe; a; c j 9j R(j; e; a; c)g
R00(a; c) = fa; c j 9j R(j; Cadiz; a; c)g
donde R(j; e; a; c) es la relacion difusa generalizada de la tabla 4.3.
En terminos de algebra relacional, la relacion R0 es una proyeccion de la relacion R sobre
los atributos EQUIPO, ALTURA y CALIDAD. La relacion R00 es el resultado de una seleccion con
la condicion EQUIPO=Cadiz y posteriormente una proyeccion sobre los atributos ALTURA y
CALIDAD. Las relaciones R0 y R00 se muestran en las Tablas 4.12 y 4.13 respectivamente.
En algebra relacional la consulta de este Ejemplo se resuelve mediante la division rela-
cional R0  R00, que es equivalente a la siguiente expresion en Calculo Relacional de Dominios,
como en la ecuacion 4.15:

4.4. EJEMPLOS DE CONSULTAS EN CALCULO RELACIONAL DIFUSO 127

H EQUIPO CEQUIPO
B Almera 0.5
Cadiz 1
Jaen 0.5
Malaga 0.75
Sevilla 0.75
Tabla 4.14: Relacion R4:12 .

R0  R00 = fe j 8a; c (R00 (a; c) ! R0 (e; a; c)  0:5)g


Observe como en el atomo de R0 incluye un umbral de cumplimiento ( = 0:5). Esto hace
que en el resultado haya tuplas que cumplen parcialmente la condicion de la consulta. Si
establecemos = 1 solo se recuperaran los equipos que tienen jugadores exactamente con
iguales caractersticas (en altura y calidad) que el equipo de Cadiz.
El resultado de la consulta de este ejemplo, R4:12 , se representa en la relacion de la Tabla
4.14.
El grado de compatibilidad para la primera tupla (S1 ) viene dado por la siguiente ecuacion,
en la que hemos expresado los valores (a; c) de DOM( ) que, segun la De nicion 4.1, son las
2 tuplas de R00 :

c1EQUIPO = Se 1 ( ) = minfSe 1 (R00 (Muy Alto; Muy Bueno) ! R0 (e; Muy Alto; Muy Bueno));
Se 1 (R00 (Bajo; Bueno) ! R0 (e; Bajo; Bueno)) g
= minfmaxf1 1; 0:5g; max f1 1; 0:66gg
= minf0:5; 0:66g = 0:5
Brevemente, los grados de compatibilidad para las otras tuplas vienen dados por:
c2EQUIPO = minfmaxf1 1; 1g; maxf1 1; 1gg = 1
c3EQUIPO = minfmaxf1 1; 0:5g; maxf1 1; 0:75gg = 0:5
c4EQUIPO = minfmaxf1 1; 1g; maxf1 1; 0:75gg = 0:75
c5EQUIPO = minfmaxf1 1; 0:75g; max f1 1; 1gg = 0:75
Cualquier consulta posible se puede efectuar mediante una unica expresion en calculo
relacional. Esto es, cualquier expresion algebraica, con cualquier numero de operadores, se
puede expresar en calculo en una unica expresion, como se demostro en el Teorema 4.1.
Basandonos en esto, este ejemplo se podra tambien haber resuelto con una unica expre-
sion, sin usar las relaciones R0 ni R00 , obteniendo los mismos resultados (Tabla 4.14):
fe j 8j 0; a; c (R(j 0 ; Cadiz; a; c) ! 9j R(j; e; a; c)  0:5) g
La division relacional difusa se expone en el captulo anterior y en [72], obteniendo el
mismo resultado que se obtiene mediante calculo relacional con = 0. Para obtener identicos
resultados si > 0, en algebra tendremos que aplicar tras la division una seleccion que
recupere solo las tuplas cuyo grado sea mayor o igual que . tu
128 CAPITULO 4. CALCULO
 RELACIONAL DIFUSO
H ALTURA CALIDAD
B Alto Muy Bueno
Bajo Regular
Muy Alto Muy Bueno
Bajo Bueno
Bajo Muy Bueno
Muy Alto Malo
Bajo Malo
Alto Regular
Normal Regular
Muy Alto Bueno
Normal Bueno
Tabla 4.15: Relacion R000 para el Ejemplo 4.13.

H ALTURA CALTURA CALIDAD CCALIDAD


B Alto 0.5 Muy Bueno 0.5
Bajo 0.34 Regular 0.34
Muy Alto 1 Malo 1
Bajo 1 Malo 1
Alto 1 Regular 1
Normal 0.5 Regular 0.5
Normal 0.5 Bueno 0.5
Tabla 4.16: Relacion R4:13 = R000 R00 del Ejemplo 4.13.

Ejemplo 4.13 Tomemos ahora una proyeccion (en terminos de algebra relacional) de la
relacion R0 de la Tabla 4.12 sobre los atributos ALTURA y CALIDAD. La relacion resultante,
R000, se muestra en la tabla 4.15 y es obtenida mediante la expresion:
R000(a; c) = fa; c j 9e R0(e; a; c)g
Entonces, partiendo de las relaciones R000 (Tabla 4.15) y R00 (Tabla 4.13) la diferencia
relacional, R000 R00 (ecuacion 4.9), adquiere en calculo relacional mayor expresividad, resol-
viendo la consulta siguiente: Dame las tuplas de R000 que no estan en R00 (en grado mnimo
0.75):
R000 (a; c) R00 = fa; c j R000(a; c) ^ :R00(a; c)  0:75g
El resultado se muestra en la Tabla 4.16. El calculo de los grados de compatibilidad es
facil. Para cualquier tupla i, se cumple que ci(ALTURA) = ci(CALIDAD) y, por ejemplo, para las dos
primeras tuplas (S1 y S2 ) tenemos que:
Sa 1 ( ) = Sc 1 ( )  1 ^ :0:5  minf1; 1 0:5g = 0:5
Sa 2 ( ) = Sc 2 ( )  1 ^ :0:66  minf1; 1 0:66g = 0:34
Observe que para todas las tuplas el grado en la parte izquierda de la conjuncion sera
siempre 1. Por tanto, al tomar el mnimo de la conjuncion (lema 4.2) el resultado sera el

4.5. CUANTIFICADORES DIFUSOS EN EL CALCULO RELACIONAL DIFUSO 129

grado en la parte derecha de la conjuncion. Esa parte esta negada (:) por lo que, cuanto
mas pertenezca una tupla a R00 menos pertenecera a la diferencia y menor sera el grado de
compatibilidad de sus atributos en el resultado. Si una tupla pertenece a R00 en grado mayor
que 0.75 entonces no pertenecera al resultado, ya que 0.75 es el umbral de cumplimiento
que hemos adoptado. As, si el umbral es , en el resultado apareceran siempre grados de
cumplimiento mayores o iguales que 1 . tu

4.5 Cuanti cadores Difusos en el Calculo Relacional Difuso


El Calculo Difuso presentado no contempla la posibilidad de la inclusion de cuanti cadores
difusos (absolutos o relativos) del tipo de \muchos", \casi todos"... [20, 149, 150, 158, 162,
163, 164, 169]. La utilidad y forma de uso de estos cuanti cadores se vieron en el apartado
2.9.2 en general y en los apartados 5.2.1.1 y 5.2.1.3 se veran aplicados a FSQL.
En este apartado vamos a dar unos posibles signi cados de estos cuanti cadores, indicando
como aplicar la funcion  aqu de nida cuando nos encontramos tales cuanti cadores. Para
calcular en que medida se cumple un cuanti cador se puede tener en cuenta lo siguiente: La
proporcion de tuplas que cumplen la condicion y el grado con el que cumplen la condicion
todas las tuplas (incluidas las que no superan el umbral establecido).
Por ejemplo, si buscamos los \equipos en los que casi todos sus jugadores son Buenos
(con grado mnimo 0.75)", para evaluar el grado de los equipos que se seleccionen, habra
que tener en cuenta: El numero de jugadores \Buenos" (con grado mnimo 0.75), el numero
de jugadores no \Buenos" (con grado mnimo 0.75) y el grado con el que todos ellos son
\Buenos". O sea, si un equipo E1 tiene de diez jugadores, siete \Buenos" con grado 1 y tres
\Buenos" con grado 0, y otro equipo E2 tiene de diez jugadores, siete \Buenos" con grado
1 y tres \Buenos" con grado 0.7, su grado de cumplimiento del cuanti cador casi todos no
debera, quizas, ser el mismo.
Una posible solucion, teniendo en cuenta toda esa informacion, es ponderar de alguna
forma cada uno de esos 3 factores:
1. T : Total de elementos que cumplen la condicion. En caso de cuanti cadores relativos
ese numero habra que dividirlo por el total de elementos considerados.
2. M : Sumatoria de los grados de cumplimiento de los elementos que cumplen la condicion.
Como el grado de cumplimiento siempre es menor o igual que 1, tenemos que T  M .
En caso de cuanti cadores relativos ese numero habra que dividirlo por el total de
elementos considerados.
3. N : Sumatoria de los grados de cumplimiento de los elementos que no cumplen la con-
dicion. En caso de cuanti cadores relativos ese numero habra que dividirlo por el total
de elementos considerados.
No obstante la in uencia del tercer factor N es discutible y puede ser eliminado. Incluso, en
determinados casos, puede usarse solo uno de los dos primeros factores, sin in uir demasiado
en el resultado nal. La diferencia entre usar distintas combinaciones de estos cuanti cadores
producira variaciones de pocos decimales y, esas diferencias pueden ser casi inapreciables en
el resultado nal moviendo adecuadamente el umbral de cumplimiento para el cuanti cador
difuso.
130 CAPITULO 4. CALCULO
 RELACIONAL DIFUSO
Aqu proponemos un sistema para utilizar los dos primeros factores: Sea  2 [0; 1] un peso
que indica la importancia del primer factor T con respecto al segundo M . Entonces, el factor
considerado sera:

 T + (1 )M (4.29)
De esta forma, si  = 1 indica que solo se usa el primer factor T y si  = 0 indica que
solo se usa el segundo factor M . Como T  M , a mayor valor de , mayor sera la expresion
anterior y de ella depende el numero de tuplas a recuperar. Naturalmente, el numero de
tuplas recuperadas tambien depende del umbral que se establezca al cuanti cador difuso.
El valor de esa expresion es el que sera utilizado como argumento de la funcion Q que
represente al cuanti cador. La de nicion de los cuanti cadores puede depender del valor de .
As, cada cuanti cador podra de nirse en funcion del valor , de forma que dependiendo de
este su de nicion adopte una u otra forma, aunque, posiblemente, el matiz que esto represente
tenga escasa relevancia global.
Entonces, teniendo en cuenta todo lo anterior, la forma de expresar un cuanti cador difuso
en Calculo Relacional Difuso de Dominios es:

(x1 ; : : : ; xn ) = Q xn+1 1 (x1 ; : : : ; xn+1) (4.30)


indicando que el cuanti cador Q se cumple en 1 para los valores de xn+1 con un grado
mnimo de , evaluando el total en la forma que indica la ecuacion 4.29 con el valor de 
indicado como superndice de Q.
De nicion 4.3 Sea una WFF cuyo el operador principal es un cuanti cador difuso Q
(absoluto o relativo). Es decir, la formula es del tipo de la ecuacion 4.30. El cuanti cador Q
esta de nido como una funcion del tipo indicado en el apartado 2.9.2. Entonces:

Sx ( (x1 ; : : : ; xn )) = Q( T + (1 )M ) (4.31)


donde T y M son el primer y segundo factor respectivamente, tal y como se han explicado
anteriormente. Para calcular T hay que contar cuantas tuplas cumplen el predicado 1 (y
dividirlo por el numero total de tuplas evaluadas si el cuanti cador es relativo). Para calcular
M hay que sumar los grados de las tuplas cumplen el predicado 1 (y dividirlo por el numero
total de tuplas evaluadas si el cuanti cador es relativo). tu
Ejemplo 4.14 Mostrar los equipos en los que casi todos (en grado mnimo 0 y con  = 0:8)
sus jugadores son Buenos (en grado mnimo 0.75). Donde \casi todos" es un cuanti cador
difuso relativo de nido como la funcion Q de la Figura 4.5, en la que la ecuacion de la recta
entre x = 0:4 y x = 0:9 es: y = (x 0:4)=0:5.
La expresion que resuelve esa consulta sera:

fe j Casi todos00:8 j; a; c(R(j; e; a; c) ! =(c; Bueno)  0:75) g


4.6. ESTUDIO COMPARATIVO CON OTRAS PROPUESTAS 131

Q
1

0
0.4 0.9 1

Figura 4.5: Cuanti cador difuso relativo \casi todos".

H EQUIPO T M CEQUIPO
B Almera 1/2 0.75/2 0.15
Cadiz 2/2 1.75/2 1.00
Cordoba 1/2 0.75/2 0.15
Granada 0/3 0/3 0.00
Jaen 3/4 2.25/4 0.63
Malaga 2/3 1.5/3 0.47
Sevilla 3/3 3/3 1.00
Tabla 4.17: Relacion R4:14 .

Considerando la relacion R de la Tabla 4.3, obtenemos la relacion R4:14 con los datos de
la Tabla 4.17, en donde hemos expresado tambien los valores de T y M para cada equipo.
Tengase en cuenta que:

CEQUIPO = Q( T + (1 )M )


Hemos puesto el umbral del cuanti cador difuso a cero, para recuperar todos los equipos
y su grado de compatibilidad. Si ese umbral fuera establecido a 0.5 (con igual valor de ) solo
se hubieran recuperado los equipos de Cadiz, Jaen y Sevilla. tu

4.6 Estudio Comparativo con otras Propuestas de Calculo Di-


fuso
En [32], Buckles, Petry y Sachar proponen un calculo de dominios para el modelo de bases de
datos relacionales difusas de Buckles-Petry [28, 30] (apartado 2.3), el cual es mas restrictivo
que el modelo GEFRED (apartado 2.7). Como se ha visto, su modelo permite representar
menor cantidad de tipos de informacion. En las condiciones de su calculo, los umbrales de
cumplimiento se pueden establecer para cada atributo y no para cada atomo, por lo que
no se pueden especi car consultas como la siguiente: \Lista los jugadores que son altos (en
grado mnimo 0.9) y bajos (en grado mnimo 0.5)". Tampoco consideran en su de nicion la
132 CAPITULO 4. CALCULO
 RELACIONAL DIFUSO
posibilidad de usar cuanti cadores difusos, ci~nendose exclusivamente a los dos cuanti cadores
crisp: Existencial (9) y universal (8).
Ademas, como en su modelo no incluyen los atributos de compatibilidad de GEFRED,
en la de nicion de su Calculo Difuso, no incluyen un metodo formal para calcular los grados
de cumplimiento para la condicion establecida. Esto ultimo nos parece una caracterstica
fundamental de todo lenguaje de consulta difuso sobre bases de datos difusas o clasicas.
En [97], Li y Liu hacen un estudio muy general del calculo relacional aplicado a bases
de datos difusas. En las WFF del calculo difuso que proponen no incluyen ni siquiera el
uso de los cuanti cadores existencial (9), universal (8) ni, por supuesto los cuanti cadores
difusos. Ademas, no proveen de un metodo claro para calcular el grado de cumplimiento de la
condicion para las tuplas seleccionadas y en la WFF establecen un umbral de cumplimiento
general para toda la formula y no para cada atomo difuso. En los atomos de pertenencia
utilizan funciones de pertenencia, de las que no se aporta ninguna de nicion, sobre todo para
valores no extrados de la relacion (del tipo que damos nosotros en la ecuacion 4.2).

4.7 Conclusiones y Lneas Futuras sobre el Calculo Relacional


Difuso
En este captulo hemos presentado un Calculo Relacional Difuso para aplicarlo a bases de
datos difusas, que permite expresar condiciones difusas y cuanti cadores difusos. El Calculo
Relacional Difuso es una extension del Calculo Relacional Clasico, por lo que tambien es
posible usarlo en bases de datos clasicas o en relaciones sin atributos difusos.
Ademas, hemos presentado la funcion  que, como hemos visto, es un evaluador que
devuelve el grado con el que un valor concreto x, de una tupla concreta (S; K ) satisface el
predicado . Esta funcion nos va a permitir averiguar el grado con el que cada valor de cada
tupla cumple la condicion impuesta en la consulta, es decir,  nos devuelve los grados de
compatibilidad de la relacion difusa generalizada resultante.
El trabajo de la funcion  es fundamental, ya que el Calculo Relacional esta basado en la
logica de predicados de primer orden, por lo que los predicados solo pueden ser Verdaderos o
Falsos. Esta dualidad la utilizamos, como en el modelo clasico, para ver si una tupla pertenece
o no a la relacion resultante: Si los valores de la tupla hacen que el predicado sea Verdad, esa
tupla pertenecera al resultado y aparecera en el. Por el contrario, si sus valores hacen que el
predicado sea Falso, esa tupla no pertenecera al resultado y no sera considerada. Entonces, si
una tupla cumple el predicado es porque cada uno de los valores de esa tupla han satisfecho las
condiciones impuestas en ese predicado. Sin embargo, cada uno de esos valores ha satisfecho
esas condiciones con un cierto grado en el intervalo [0,1], y el conocimiento de esos grados es
vital en bases de datos difusas. El trabajo de la funcion  es calcular esos grados.
Es facil traducir una expresion en Calculo Relacional Difuso de Dominios a otra equivalente
en un Calculo Relacional Difuso de Tuplas.
Con esto conseguimos tener los dos niveles de lenguajes de consulta que dise~no Codd [42]
para bases de datos relacionales pero extendidos a bases de datos relacionales difusas: El
A lgebra Relacional Difuso (de nido en [102, 103, 72] y en el captulo anterior) y el Calculo
Relacional Difuso aqu expuesto.
Un trabajo interesante sera elaborar un metodo e ciente para calcular la componente de
valor del resultado de una expresion en Calculo Relacional Difuso, que podra basarse en el
\algoritmo de reduccion de Codd" [42].
Captulo 5
Arquitectura de la BDRD: El
Servidor FSQL (Fuzzy SQL)
La arquitectura de la BDRD (Base de Datos Relacional Difusa) muestra los elementos basicos
con los que esta construida y como se relacionan unos con otros. Esos elementos son de
distinta naturaleza: Estructuras de datos (tablas, vistas...), gramaticas para la de nicion
de DML (Data Manipulation Language) y DDL (Data De nition Language), programas (en
distintos lenguajes), datos...
El objetivo de esta arquitectura es, como ya se ha indicado, poder almacenar y tratar
informacion imprecisa, difusa, y para ello necesitamos formalizar un metodo de hacerlo. Es
decir, es absolutamente imprescindible de nir como se van a almacenar estos nuevos tipos de
informacion y como es posible comunicarse con la BDRD para conseguir nuestro proposito.
Este canal de comunicacion sera una va para que los usuarios, sea directamente o a traves
de aplicaciones espec cas puedan trabajar con la BDRD. Para la construccion de ese canal
hemos preferido modi car un canal ya existente y ampliamente empleado: El Lenguaje de
Consulta Estructurado SQL (Structured Query Language) [26, 37, 38, 52, 86].
As pues, hemos modi cado el lenguaje SQL para adaptarlo a las necesidades de una
BDRD, de forma que permita expresar valores difusos, condiciones difusas, atributos difusos,
grados de compatibilidad, umbrales de cumplimiento... naciendo as el que hemos denominado
SQL Difuso, Fuzzy SQL o FSQL [75, 77, 78].
Para que el lenguaje FSQL cobrara vida hemos creado un Servidor FSQL multiusuario,
implantado de acuerdo con el modelo Cliente/Servidor, para uno de los SGBD (Sistemas
Gestores de Bases de Datos) mas potentes y difundidos en la actualidad: Oracle [92, 99, 116,
117]. El programa Cliente FSQL, que permite consultar esa BDRD de forma facil, comoda y
exible usando el Servidor FSQL, sera explicado en el Captulo 6. Ademas del Servidor FSQL,
hemos construido un programa Cliente FSQL, llamado FQ, para Windows 95/98/NT (ver
apartado 6.3 y Apendice G).
En este captulo explicaremos primero como hemos conseguido almacenar valores difu-
sos partiendo de un SGDB clasico (Oracle), explicando como se ha implementado el modelo
GEFRED de BDRD [102, 103]. Esta es la base de nuestro Sistema de BDRD. A conti-
nuacion daremos una de nicion de la sintaxis y la semantica del lenguaje FSQL (tanto de
sentencias DML como DDL). Posteriormente de niremos la arquitectura de nuestro modelo
Cliente/Servidor de BDRD y como se ha programado el Servidor de Consultas FSQL (ver-
sion 1.2). Terminaremos el captulo con una lista de las mejoras mas importantes que pueden
133
134 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
incorporarse tanto al lenguaje FSQL como a proximas versiones del Servidor FSQL.

5.1 Implementacion de la BDRD: FIRST


En [103] se expuso un modulo para permitir extender la capacidad de un SGBDR clasico para
que pueda representar y manipular informacion \imprecisa". Este modulo, llamado FIRST
[106] (Fuzzy Interface for Relational SysTems, Interface Difuso para Sistemas Relacionales),
utiliza GEFRED como modelo teorico y los recursos del modelo relacional clasico para poder
representar este tipo de informacion.
Ademas, para poder efectuar las operaciones tpicas sobre la BDRD (creacion de tablas,
de etiquetas, consultas exibles...) hemos extendido el lenguaje SQL para que permita tratar
los nuevos datos. Esta extension la hemos llamado FSQL (Fuzzy SQL) y sera explicada en la
seccion 5.2.
Nosotros hemos modi cado ligeramente FIRST para mejorarlo y adaptarlo a nuevas ne-
cesidades. El resultado es el siguiente:
5.1.1 Esquema General de FIRST
La Figura 5.1 muestra el esquema general de FIRST. Como la idea de partida es la de
construirlo sobre un gestor de bases de datos convencional, todos los desarrollos a realizar
toman a dicho gestor como el elemento principal al que van dirigidas todas las peticiones.
En breve, explicamos cada uno de esos modulos:
 SGBDR (Sistema Gestor de Bases de Datos Relacionales, Relational DabaBase Ma-
nagement System, RDBMS): Todas las operaciones que hayamos concebido para la
extension difusa que representa nuestra implementacion, se traduciran a peticiones al
SGBDR an trion (en general en SQL). Las peticiones al SGBDR se realizaran emple-
ando el lenguaje SQL o FSQL, dependiendo si la consulta involucra o no relaciones
y/o condiciones difusas. Como veremos, las sentencias FSQL seran procesadas por el
Servidor FSQL.
 BD (Base de Datos): Almacena, en formato relacional toda la informacion que sea de
interes, igual que cualquier otra base de datos. La unica diferencia es que nuestra base
de datos permitira el almacenamiento de informacion difusa en sus tablas. La forma en
que se representan los datos en dichas tablas dependera de la naturaleza de los mismos
y se vera en los proximos apartados.
 FMB (Fuzzy Metaknowledge Base, Base de Metaconocimiento Difuso): El \dicciona-
rio" o \catalogo del sistema" de un SGBDR representa aquella parte del sistema que
almacena informacion sobre los datos recogidos en la base de datos, as como otro ti-
po de informaciones: Usuarios, permisos, accesos, datos de control... Dentro de este
catalogo hemos incluido la FMB, que extiende esta parte del sistema a n de que pueda
recoger aquella informacion necesaria relacionada con la naturaleza \imprecisa" de la
nueva coleccion de datos a procesar. Su organizacion y la informacion que almacena se
veran mas adelante.
 Servidor FSQL: Su objetivo es captar las sentencias en lenguaje FSQL y traducirlas
a un lenguaje que entienda el SGBDR, el lenguaje SQL. Para efectuar esta traduc-
cion utilizara la informacion almacenada en la FMB. Este Servidor esta ntegramente
 DE LA BDRD: FIRST
5.1. IMPLEMENTACION 135

' $' BD FMB DIC


$
& ' %& $ %
Fuzzy Clasico
Base de Datos Catalogo del Sistema
HHYHHH  *
HjHH 
SGBDR

&
# % Sistema Gestor de
Bases de Datos Relacionales
6?

"
' $' $'! 

*
Servidor
FSQL
6? HHYHHH
HjH H $
& %& %& %
Interfaz o FSQLF Cliente
Cliente Visual FORM Difuso FSQL

Figura 5.1: Esquema General de FIRST.

programado en el lenguaje PL/SQL de Oracle y se encuentra implantado como una co-


leccion de modulos almacenados en el Servidor Oracle. Nuestro Servidor FSQL podra
ser instalado en cualquier plataforma donde exista una implementacion de Oracle.
 Cliente FSQL: Se trata de un programa que hace de interfaz entre el hombre (u otro
programa) y el Servidor FSQL. Este programa puede ser muy simple, pues el trabajo
principal de una operacion FSQL sera efectuado por el Servidor FSQL. El programa
Cliente FSQL puede ser programado para cualquier Sistema Operativo y en cualquier
lenguaje de programacion1 . En el Captulo 6 se explican las funciones de este programa y
como puede programarse. Nosotros hemos desarrollado un Cliente FSQL para Windows
95/98/NT llamado FQ (ver apartado 6.3 y Apendice G). Por supuesto, es posible
desarrollar Clientes FSQL visuales, que ayuden a editar sentencias difusas sin necesidad
de conocer la sintaxis de FSQL ni la de SQL. Actualmente estamos desarrollando un
1 Los unicos requisitos de un lenguaje para poder programarse un Cliente FSQL en el son que permita
efectuar consultas sobre la base de datos clasica y que permita ejecutar procedimientos almacenados en el
SGBD
136 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL

Figura 5.2: Formato de una distribucion de posibilidad trapezoidal.

Cliente FSQL visual programado en lenguaje Java (apartado 6.4), para que pueda ser
ejecutado a traves de una red TCP/IP (como Internet o una Intranet, por ejemplo).

5.1.2 Representacion del Conocimiento Impreciso


Los diferentes elementos que forman parte del tratamiento impreciso pueden recibir diferentes
representaciones. As pues, por ejemplo, una distribucion de posibilidad normalizada puede
venir representada por diferentes tipos de funciones (parabolas, hiperbolas...). Nosotros em-
plearemos para la misma una representacion trapezoidal del tipo del representado en la Figura
5.2. Lo mismo se puede decir para la forma en que modelamos las operaciones relacionales
difusas, as como para el resto de los items u objetos \difusos" que nuestro sistema va a
utilizar.
Pudiera parecer que el criterio de representacion expuesto supone una fuerte restriccion,
sin embargo, esto no es as dada la naturaleza \imprecisa" de la informacion con la que
tratamos. No parece muy acertado modelar unos datos, que en s son imprecisos, con una
representacion extremadamente precisa dada por funciones no lineales. A esto habra que
a~nadir la perdida de e ciencia, pues los calculos en funciones no lineales son, en general, mas
costosos que en funciones lineales.
En este apartado vamos a mostrar los criterios de representacion empleados en nuestra
implementacion. Estos criterios no son exclusivos de una implementacion concreta, como
FIRST y su Servidor FSQL, sino que representan la base sobre la que construir la implemen-
tacion de los mismos de acuerdo con el esquema dise~nado para la realizacion de un SGBDRD
(SGBDR Difusas). Podramos decir, por tanto, que constituyen un paso intermedio a cubrir
entre la formulacion de un modelo de Bases de Datos Relacionales Difusas y la implemen-
tacion efectiva de un sistema basado en el. En [104] se encuentran algunos de los aspectos
relacionados con la representacion e implementacion de un SBDRD.
A continuacion resumimos los criterios adoptados para la representacion del conocimiento
impreciso [103]: Datos difusos, comparadores difusos, umbrales de cumplimiento y cuanti -
cadores de la consulta.

5.1.2.1 Representacion de los Datos Difusos y/o con Tratamiento Difuso


Para los diferentes tipos de datos que constituan la de nicion de dominio difuso generalizado,
recogidos en la Tabla 2.4, acordamos los siguientes criterios de representacion:
 DE LA BDRD: FIRST
5.1. IMPLEMENTACION 137

Alto
1

0
170 175 180 185 190 195 200 205 210 cm.

Figura 5.3: Ejemplo de una Etiqueta Lingustica para el concepto \Alto".

1. Datos Precisos (crisp, clasicos): Se empleara la representacion que proporcione el


SGBDR an trion. Es decir, se adoptaran los formatos para cadenas alfanumericas,
valores numericos, fechas, horas... e incluso objetos, soportados por el sistema sobre el
que se construya FIRST.
2. Datos Imprecisos (fuzzy, difusos): Los datos de naturaleza imprecisa soportados por
GEFRED pueden ser clasi cados en dos grupos con distintas representaciones para
cada uno de ellos: Sobre referencial ordenado y sobre referencial discreto no ordenado.
Por \referencial" se entiende el dominio subyacente del atributo en cuestion. As, por
ejemplo, un atributo Altura puede ser considerado difuso para almacenar valores como
\Alto" (ver Figura 5.3), \Bajo"... pero el dominio subyacente sobre el que se construyen
las distribuciones de posibilidad es ordenado y corresponde a los centmetros de altura
posibles.
 DATOS IMPRECISOS SOBRE REFERENCIAL ORDENADO
Este grupo de datos contiene distribuciones de posibilidad sobre dominios continuos
o discretos sobre los que existe una relacion de orden. A este grupo pertenecen
el tipo 6 de la Tabla 2.4. Cada dato de este tipo tiene asociada una funcion de
pertenencia. Por cuestiones de simplicidad de representacion y de e ciencia en el
calculo, adoptaremos las siguientes representaciones para este tipo de datos:
Distribucion de Posibilidad Trapezoidal : Esta representacion determina la fun-
cion de pertenencia asociada al dato mediante el uso de cuatro parametros
[ ; ; ; ], tal y como se muestra en la Figura 5.2. Utilizamos funciones de
pertenencia normalizadas, aquellas que poseen un nucleo no vaco, i.e., tienen
posibilidad maxima (1) para, al menos, un valor del dominio subyacente.
Etiqueta Lingustica : Los datos expresados mediante una etiqueta lingustica ha-
cen referencia a un concepto impreciso, a veces subjetivo, que lleva asociado
una distribucion de posibilidad. Por ejemplo, la etiqueta lingustica \Alto",
puede llevar asociada la distribucion de posibilidad en representacion trape-
zoidal que muestra la Figura 5.3.
Valores Aproximados : Dado un valor, n, perteneciente al dominio subyacente,
podemos dar una representacion del concepto impreciso \aproximadamente n"
mediante un valor, llamado \margen", a partir del cual podemos construir
su funcion de pertenencia como una distribucion de posibilidad triangular,
138 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL

0
n-margen = = n = = n+margen

Figura 5.4: Distribucion de posibilidad para \Aproximadamente n" (#n).

0
= = n = = m

Figura 5.5: Distribucion de posibilidad para el intervalo [n,m].

como la de la Figura 5.4. Nuevamente empleamos funciones de pertenencia


normalizadas.
Intervalos de posibilidad : Son un caso de distribuciones de posibilidad trapezoi-
dales en el que las pendientes de ambos lados del trapecio son in nitas y por
tanto todos los valores entre los dos extremos son los unicos que son total-
mente posibles (posibilidad 1), como se muestra en la Figura 5.5. Se opera
con ellos de forma similar a como se hace con la distribuciones de posibilidad
trapezoidales. Estos valores tienen el mismo signi cado que en el modelo de
Grant [85] (ver apartado 2.1.3).
 DATOS CON ANALOGIA SOBRE REFERENCIAL NO ORDENADO
Este grupo de datos esta construido sobre dominios subyacentes discretos no or-
denados en los que se encuentran de nidas \relaciones de semejanza" o similitud
entre los valores que lo constituyen. Para este tipo de datos tendremos que pro-
porcionar almacenamiento para la representacion de los mismos, as como para las
\relaciones de semejanza" de nidas sobre los valores del dominio. Los diferentes
tipos que podemos representar dentro de este grupo son:
Escalares Simples : Se considera como una distribucion de posibilidad con una
unica pareja de datos en la que el valor de posibilidad es 1: f(1; d)g. O sea,
se considera que el valor del escalar d es el unico posible y su posibilidad es 1
(para que este normalizada2).
2 El
sistema de representacion empleado permite que no se normalicen ni los escalares simples ni las distri-
buciones de posibilidad sobre estos, aunque esto no es recomendable.
 DE LA BDRD: FIRST
5.1. IMPLEMENTACION 139
Unknown Undefined
1 1

0 0

Figura 5.6: Distribuciones de posibilidad para los tipos UNKNOWN y UNDEFINED.

Distribucion de Posibilidad sobre Escalares : A un dato impreciso de este tipo le


asociamos una representacion en la que se describen los valores del dominio
de discurso que la componen con los respectivos valores de posibilidad para
cada uno de ellos, f(p1 ; d1 ); : : : ; (pn ; dn )g. Uno de los pi debe ser 1 para que
la distribucion este normalizada.
Por otra parte, existen otros 3 valores especiales que pueden almacenarse en cualquiera
de los tipos de datos \imprecisos" que acabamos de describir. Estos 3 valores son
tomados en el sentido de Umano, Fukami et al. de [70] y [143]:
 UNKNOWN (Desconocido, pero aplicable): Un dato de este tipo re eja el des-
conocimiento con respecto al valor que toma un atributo. Sabemos, sin embargo,
que el atributo puede tomar algun valor del dominio de discurso. Esto implica
que es posible que tome cualquiera de ellos, por tanto representaremos el tipo
UNKNOWN mediante la distribucion de posibilidad, f1=u; 8u 2 U g donde U es
el dominio subyacente. La Figura 5.6 muestra gra camente esta distribucion de
posibilidad, la cual toma el valor 1 para todo el dominio subyacente.
 UNDEFINED (No aplicable): Cuando un atributo toma el valor UNDEFINED
re eja el hecho de que ninguno de los valores de dominio sobre el que esta de nido
es aplicable. Esto se puede entender como que ninguno de los valores de dominio
es posible, por lo que lo representaremos mediante la distribucion de posibilidad,
f0=u; 8u 2 U g donde U es el dominio subyacente. La distribucion de posibilidad se
muestra en la Figura 5.6, la cual toma el valor 0 para todo el dominio subyacente.
 NULL (Ignorancia absoluta): Sobre un atributo tenemos un valor NULL cuan-
do no aportamos informacion, bien porque no la conocemos (UNKNOWN) o
porque no es aplicable (UNDEFINED). Mediante el conjunto f1/UNKNOWN,
1/UNDEFINEDg podemos modelar este tipo de dato.
5.1.2.2 Comparadores Difusos Generalizados
En la literatura pueden encontrarse diversos metodos de comparacion de numeros difusos,
los cuales pueden clasi carse en dos categoras: los que emplean una funcion del conjunto de
numeros difusos a un conjunto ordenado y los que utilizan relaciones difusas para el proceso
de comparacion. Al primer tipo pertenecen las propuestas recogidas en [1, 155, 157]. Sobre el
segundo tipo se encuentran diferentes aproximaciones en [9, 13, 53, 58]. Nosotros basaremos
140 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
la implementacion que estamos describiendo en comparadores construidos en torno al segundo
tipo. Concretamente, partiremos del esquema formulado en [127], si bien su representacion
ha sido simpli cada y adaptada a las peculiaridades tanto de GEFRED como de FIRST.
Como vimos en el apartado dedicado a GEFRED, la de nicion de comparador difuso
generalizado permita modelar una amplia variedad de modalidades de comparacion. FIRST
no pone lmite con respecto al numero y tipo de los comparadores que pueden emplearse.
Como veremos, en la implementacion del modelo de BDRD que aqu presentamos se han
implementado 15 comparadores diferentes. De ellos, 14 son para datos sobre referencial
ordenado y se muestran en la Tabla 5.12 y se de nen en el apartado 5.2.1.4. Ademas, en el
apartado 5.2.1.7 se de ne 1 comparador para los datos sobre referencial no ordenado.

5.1.2.3 Umbral de Cumplimiento de una Condicion Difusa: Cuali cadores


Cuando planteamos una consulta en una base de datos con imprecision se establecen una serie
de condiciones a cumplir por las tuplas que la satisfagan. Dada la naturaleza imprecisa de
los operadores y de los datos sobre los que operamos, existe un grado de cumplimiento para
cada condicion involucrada en una consulta. Este grado de cumplimiento se halla compren-
dido entre 0 y 1. Mediante el empleo de un umbral mnimo, entre 0 y 1, para el grado de
cumplimiento podemos ejercer algun control sobre la precision con que se satisfacen cada una
de las condiciones de la consulta. Si establecemos un umbral de cumplimiento 1 para una
condicion envuelta en una consulta, eliminaremos aquellas tuplas que no igualen o superen el
umbral para esa condicion.
En nuestro modelo es posible asociar un cuali cador lingustico (una palabra) a un um-
bral determinado, de forma que puedan efectuarse consultas poniendo como umbral dicho
cuali cador, haciendo que las consultas contengan mas signi cado.

5.1.2.4 Representacion de Cuanti cadores Difusos de la Consulta


Como se vio en el apartado 2.9.2, los cuanti cadores difusos absolutos se representan como
distribuciones de posibilidad trapezoidales en el intervalo [0; +1) y los relativos como dis-
tribuciones de posibilidad trapezoidales en el intervalo [0; 1]. En la FMB se almacenaran los
valores de un trapecio en esos rangos, como por ejemplo los cuanti cadores difusos relativos
de la Figura 5.9.

5.1.3 Implementacion de FIRST en Oracle


A continuacion vamos a describir en lneas generales, cuales son los niveles sobre los que
podemos actuar para llevar a cabo la implementacion de los principales modulos de FIRST
empleando los recursos antes mencionados:
 A nivel de la Base de Datos. La base de datos es aquella coleccion de datos persistentes
que constituyen la representacion de una fraccion de conocimiento del universo. Co-
mo nuestro sistema contempla la representacion de conocimiento impreciso, debemos
determinar la forma en que este se almacena en la base de datos. Por tanto, habra
que extender la representacion de los datos para albergar este tipo de informacion. En
realidad, como veremos, este \tipo" de informacion imprecisa puede ser, de hecho, de
muchos \tipos" diferentes.
 DE LA BDRD: FIRST
5.1. IMPLEMENTACION 141

 A nivel del Catalogo del Sistema. En un SGBDR clasico existe una parte del sistema en
la que se recoge toda aquella informacion que el gestor necesita saber acerca de los datos
que almacena ,\datos sobre los datos" (denominados a veces \metadatos"). Esta parte
representa habitualmente dicha informacion mediante el empleo de tablas o relaciones
organizadas siguiendo un esquema similar al empleado por la propia base de datos.
FIRST necesita tener informacion sobre los elementos de la base de datos que contienen
informacion imprecisa as como de la naturaleza y representacion de dicha informa-
cion. Denominaremos Base de Metaconocimiento Difuso (FMB), a aquella extension
del Catalogo del Sistema que recoge la informacion necesaria sobre los datos de natu-
raleza imprecisa existentes en la base de datos. La FMB sera explicada en el apartado
5.1.3.2 y siguientes.
 A nivel del Gestor de FIRST. El gestor posee conocimiento implementado sobre las
operaciones de naturaleza imprecisa que puede realizar y de como hacerlo. El Servidor
FSQL es la parte del sistema que contiene las rutinas que se encargan de implementar
esas operaciones.
A continuacion exponemos el sistema utilizado para la representacion del conocimiento
impreciso y para el almacenamiento de la FMB. El Servidor FSQL sera explicado en detalle
en el apartado 5.4.

5.1.3.1 Representacion del Conocimiento Impreciso en la Base de Datos Oracle


En el sistema que se esta describiendo existen tres tipos de atributos susceptibles de tra-
tamiento impreciso. La clasi cacion adoptada se basa en criterios de representacion y de
tratamiento de los datos \imprecisos": Se clasi can segun el tipo del dominio que les subyace
y por si permiten el almacenamiento de informacion imprecisa o solo permiten el tratamiento
impreciso de datos sin imprecision:
1. Atributos Difusos Tipo 1: Son atributos con \datos precisos", clasicos o crisp, que
pueden tener etiquetas lingusticas de nidas sobre ellos. Este tipo de atributos reciben
una representacion igual que los datos precisos. Sin embargo, cuentan con informacion
en la FMB, donde se almacenaran las etiquetas, tambien recogera informacion acerca
de la naturaleza de estos atributos. Por tanto, son atributos clasicos que admiten el
tratamiento difuso y por tanto podremos efectuar consultas difusas ( exibles) sobre
ellos, aunque no permitan almacenar valores difusos.
Este tipo de atributos son los que permitiran que bases de datos relacionales clasicas
puedan bene ciarse de nuestro trabajo, permitiendo el tratamiento difuso de datos no
difusos, mediante el empleo de consultas exibles sobre una base de datos tradicional.
Como veremos, esto puede ser utilizado para, por ejemplo, operaciones de Data Mining.
2. Atributos Difusos Tipo 2: Son atributos que pueden recoger \datos imprecisos so-
bre referencial ordenado". Estos atributos recogen el tipo de datos cuya representacion
ha sido descrita en el apartado 5.1.2.1. Permiten tambien la representacion de infor-
macion incompleta en forma de datos de tipo UNKNOWN, UNDEFINED y NULL.
Logicamente, tambien admiten \informacion precisa".
142 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
Tipos de Atributos de la BD para cada Tipo 2
Valores FT F1 F2 F3 F4
UNKNOWN 0 NULL NULL NULL NULL
UNDEFINED 1 NULL NULL NULL NULL
NULL 2 NULL NULL NULL NULL
CRISP 3 d NULL NULL NULL
LABEL 4 FUZZY ID NULL NULL NULL
INTERVALO [n,m] 5 n NULL NULL m
APROXIMADAMENTE(d) 6 d d{margen d+margen margen
TRAPECIO [ ; ; ; ] 7  
Para un atributo Difuso Tipo 2 llamado F, la representacion usa 5 atributos: FT para almacenar
el codigo de tipo que le corresponde a cada valor y los atributos F1, F2, F3 y F4 para almacenar
los parametros de cada dato. Los valores NULL que aparecen en los atributos tienen el signi cado
de valor \no-aplicable" en el SGBDR an trion.

Tabla 5.1: Representacion interna de Atributos Difusos Tipo 2.

En la Tabla 5.1 mostramos el sistema utilizado para representar a los atributos difu-
sos Tipo 2. As, vemos que un atributo difuso Tipo 2, llamado por ejemplo F, esta
compuesto, de hecho, por 5 atributos clasicos:
 FT: Almacena el tipo de valor que corresponde al dato que queremos almace-
nar, indicando su representacion. Segun lo visto, puede ser: UNKNOWN (0),
UNDEFINED (1), NULL (2), CRISP (3), LABEL (4), INTERVALO (5), APRO-
XIMADAMENTE (6) o TRAPEZOIDAL (7). Observe que a~nadimos una T al
nombre del atributo.
 F1, F2, F3 y F4: Los atributos cuyo nombre se forma a~nadiendo los numeros 1,
2, 3 y 4 al nombre del atributo almacenan la descripcion de los parametros que
de nen el dato y que depende del tipo de valor (FT) al que pertenezca:
{ UNKNOWN, UNDEFINED, NULL: Estos 3 valores no necesitan ningun
parametro, por lo que todos ellos permanecen a NULL (entendiendo este valor
como el NULL del SGBD an trion y no como el NULL del valor difuso, que
no deben confundirse).
{ CRISP: Un valor de tipo crisp, necesita tan solo un parametro, F1, en el cual
se almacenara el valor crisp en cuestion.
{ LABEL: Igualmente, un valor de tipo etiqueta solo necesita un parametro
para almacenar el identi cador asociado a dicha etiqueta (FUZZY ID). Ese
indicador es util para poder acceder a la FMB y obtener la descripcion asociada
a esta etiqueta.
{ INTERVALO: Necesita los dos valores extremos del intervalo [n,m], que son
almacenados en F1 y F4 respectivamente.
{ APROXIMADAMENTE: Este valor solo necesita un valor que se almacena
en F1 y que es el valor central de la distribucion de posibilidad triangular, d.
Sin embargo, para reducir operaciones (tanto matematicas como de acceso a
datos), se aprovechan los atributos F2, F3 y F4 para almacenar los valores
d{margen, d+margen y margen, respectivamente. El valor margen es un valor
 DE LA BDRD: FIRST
5.1. IMPLEMENTACION 143

almacenado en la FMB para cada atributo difuso, y su valor depende del


signi cado de dicho atributo.
Esto nos permite la posibilidad de almacenar valores aproximados sin indicar
el margen, usando el margen por defecto almacenado en la FMB, o tambien
almacenar valores aproximados con un margen particular para ellos, distinto
al de la FMB.
{ TRAPECIO: Necesita forzosamente almacenar los 4 valores que identi can
a un trapecio: [ ; ; ; ]. En F2 y F3 se almacenan unas operaciones que
simpli can las ecuaciones cuando se opera con este tipo de dato.
En esta representacion se ha primado los aspectos siguientes:
 Velocidad de ejecucion frente a economa de almacenamiento. Para alguno de los
tipos que puede recoger este atributo, se podra emplear una representacion mas
compacta, sin embargo, esto ralentizara la mayora de las operaciones implicadas
en una consulta3 .
 Uniformidad en la representacion. Empleamos cinco atributos clasicos para repre-
sentar cada atributo difuso de este tipo.
 Uso de los elementos del SGBDR an trion para representar la informacion respe-
tando en dicha representacion el esquema relacional. Este criterio, unido a otros
adoptados a lo largo de esta exposicion, posibilitara el reducir cualquier operacion
de naturaleza imprecisa a terminos del modelo relacional clasico.
3. Atributos Difusos Tipo 3: Son atributos sobre \dominio discreto no ordenado con
analoga". Estos atributos recogen datos escalares simples (SIMPLE) o distribuciones
de posibilidad (DISTR. POS.) sobre dominios escalares, representados en la forma que
se describe en el apartado 5.1.2. Tambien aceptan datos de tipo UNKNOWN, UNDE-
FINED y NULL.
Igual que en atributos difusos Tipo 2, para atributos de este tipo tendremos que al-
macenar en la base de datos el tipo del valor almacenado y los datos de este valor.
La FMB (Base de Metaconocimiento Difuso) contabilizara cada atributo de este tipo
que aparezca en la base de datos. Tambien almacenara las \relaciones de semejanza"
de nidas sobre el dominio subyacente.
En la Tabla 5.2 mostramos el sistema utilizado para representar a los atributos difu-
sos Tipo 3. As, vemos que un atributo difuso Tipo 3, llamado por ejemplo F, esta
compuesto, de hecho, por un numero variable de atributos clasicos:
 FT: El tipo de valor que corresponde al dato que queremos almacenar. Este
puede ser: UNKNOWN (0), UNDEFINED (1), NULL (2), SIMPLE (3) o DIS-
TRIBUCION  de POSIBILIDAD (4).
 Lista de n parejas, con n1, del tipo (valor de posibilidad,etiqueta ), (FP1,F1),
: : : (FPn,Fn): En estos atributos se almacenan los datos de la distribucion de
posibilidad que deseamos almacenar. En un valor de tipo SIMPLE solo se usa la
primera pareja y el valor de posibilidad debera ser 1 (para estar normalizada).
3 En realidad bastara con los atributos FT y F1, almacenando los valores de cada valor trapecio en una
tabla independiente, asociada a cada tabla que contenga atributos difusos Tipo 2.
144 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL

Tipos de Atributos de la BD para cada Tipo 3


Valores FT FP1 F1 : : : FPn Fn
UNKNOWN 0 NULL NULL : : : NULL NULL
UNDEFINED 1 NULL NULL : : : NULL NULL
NULL 2 NULL NULL : : : NULL NULL
SIMPLE 3 p d : : : NULL NULL
DISTR. POS. 4 p1 d1 : : : pn dn
El valor n es el maximo numero de pares (grado posibilidad, valor) que puede representar el
atributo instanciado. Este valor, que tiene que ser establecido en el momento en que se declara el
atributo, acota la capacidad de ese atributo para representar distribuciones de posibilidad y esta
almacenado en la FMB.

Tabla 5.2: Representacion interna de Atributos Difusos Tipo 3.

En un valor de tipo DISTR. POS. se podran almacenar hasta n parejas, donde en


cada una de ellas el valor de posibilidad estara en el intervalo [0,1]. Se pueden usar
menos de n parejas dejando el resto de campos a NULL. En la FMB se almacenan
las etiquetas, su relacion de semejanza y el valor de n.
5.1.3.2 FMB (Fuzzy Metaknowledge Base, Base de Metaconocimiento Difuso):
De nicion de Tablas
Como hemos visto en el apartado anterior, existe cierto tipo de informacion sobre los atributos
descritos, que precisa ser almacenada de una forma accesible por el sistema. La Base de
Metaconocimiento Difuso, FMB, va a ser la encargada de organizar toda aquella informacion
relacionada con la naturaleza imprecisa de estos atributos. En FIRST se contempla la Base de
Metaconocimiento Difuso como una extension del Catalogo del sistema, por ello, organiza la
informacion mediante el uso de tablas o relaciones. Los elementos del tratamiento impreciso
que se almacenan en la Base de Metaconocimiento son los siguientes:
 Atributos de la base de datos que reciben tratamiento impreciso.
 Clase de informacion imprecisa que recogen: De que Tipo difuso son estos atributos
(Tipo 1, 2 o 3) y la longitud maxima de las distribuciones de posibilidad para los
atributos Tipo 3.
 Objetos de nidos en el ambito de la base de datos, como por ejemplo cuanti cadores
difusos de consulta.
 Objetos difusos de nidos sobre cada atributo:
{ Etiquetas lingusticas (para atributos difusos Tipo 1, 2 y 3).
{ El margen para valores aproximados y la distancia mnima para que 2 valores sean
considerados como muy separados (para atributos difusos Tipo 1 y 2).
{ Relaciones de semejanza (para atributos difusos 3).
 La descripcion de esos objetos.
 DE LA BDRD: FIRST
5.1. IMPLEMENTACION 145

Tabla/Vista Sinonimo
T. FUZZY COL LIST FCL
T. FUZZY OBJECT LIST FOL
T. FUZZY LABEL DEF FLD
T. FUZZY APPROX MUCH FAM
T. FUZZY NEARNESS DEF FND
T. FUZZY COMPATIBLE COL FCC
T. FUZZY QUALIFIERS DEF FQD
V. LABELS FOR OBJCOL LFOC
V. LABELS OBJCOL T3 LOCT3
V. ALL COMPATIBLES T3 ACT3

Tabla 5.3: Tablas y vistas de FIRST y sus sinonimos publicos.

A continuacion detallamos como FIRST implementa la FMB, que es el nucleo basico de


FIRST. La organizacion de las tablas que la constituyen y la relacion entre ellas se muestran
en la Figura 5.7. Tambien se han creado unas vistas que facilitan el acceso a determinados
conjuntos de datos, como se vera en el apartado 5.1.3.4.
En Oracle cada atributo es asignado unvocamente a una pareja de datos (OBJ#,COL#),
donde OBJ# es el identi cador de una tabla y COL# es el identi cador de la columna o atri-
buto concreto dentro de esa tabla. Nosotros en lo sucesivo nos referiremos a OBJ# como el
identi cador de una tabla, aunque este tambien puede ser el identi cador de una vista. As,
si tenemos una o varias tablas difusas, podremos de nir una vista difusa sobre ellas.
Para cada tabla/vista de la FMB se ha creado un sinonimo publico con las siglas de la
tabla, de forma que se facilita el acceso, ya que los nombres de estas tablas son largos de
escribir. En la Tabla 5.3 se expone el conjunto de tablas y vistas de la FMB y el nombre del
sinonimo publico creado para cada una. Ademas, los permisos de acceso para cada tabla han
sido concedidos sobre estos sinonimos.
Procedemos a describir como se crea cada tabla, su estructura, su signi cado y el de cada
uno de sus atributos.

 Tabla FUZZY COL LIST


Esta tabla contiene una descripcion de aquellos atributos de la base de datos que son
susceptibles de tratamiento difuso. Esta descripcion se realiza en terminos analogos a los
empleados por Oracle. La tabla se crea con la siguiente sentencia:
CREATE TABLE FUZZY_COL_LIST(
OBJ# NUMBER NOT NULL,
COL# NUMBER NOT NULL,
F_TYPE NUMBER(1) NOT NULL,
LEN NUMBER(2) NOT NULL,
COM VARCHAR2(100),
PRIMARY KEY (OBJ#,COL#),
CONSTRAINT LEN_TOO_LONG_IN_FUZZY_COL_LIST
CHECK (LEN>=1 AND LEN<=10),
146 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL

FUZZY_COL_LIST (FCL)
OBJ# COL# F_TYPE LEN COM

FUZZY_APPROX_MUCH (FAM)
OBJ# COL# MARGEN MUCH

OBJ#1 COL#1 OBJ#2 COL#2


FUZZY_COMPATIBLE_COL (FCC)

FUZZY_OBJECT_LIST (FOL)
OBJ# COL# FUZZY_ID FUZZY_NAME FUZZY_TYPE

FUZZY_LABEL_DEF (FLD)
OBJ# COL# FUZZY_ID ALFA BETA GAMMA DELTA

FUZZY_NEARNESS_DEF (FND)
OBJ# COL# FUZZY_ID1 FUZZY_ID2 DEGREE

FUZZY_QUALIFIERS_DEF (FQD)
OBJ# COL# FUZZY_ID QUALIFIER

Figura 5.7: Esquema de la Base de Metaconocimiento Difuso (FMB).


 DE LA BDRD: FIRST
5.1. IMPLEMENTACION 147

CONSTRAINT FUZZY_TYPE_MUST_BE_1_2_o_3
CHECK (F_TYPE=1 OR F_TYPE=2 OR F_TYPE=3));

Los atributos de esta tabla tienen el siguiente signi cado cada uno:
- OBJ#:Almacena el numero de objeto de la tabla (o vista) que tiene un atributo difuso.
- COL#: Almacena el numero de columna dentro de la tabla que admitira un tratamiento
difuso.
- F TYPE: Almacena el Tipo de atributo difuso de la columna identi cada por (OBJ#,COL#).
Este Tipo puede tomar el valor 1, 2 o 3, y ello es comprobado por la restriccion
FUZZY TYPE MUST BE 1 2 o 3

- LEN: Almacena la longitud (length ) m


axima de una distribucion de posibilidad en atri-
butos Tipo 3, i.e., el numero maximo de parejas (valor de posibilidad,etiqueta ) que
admite una distribucion de posibilidad en este atributo. Por necesidades del Ser-
vidor FSQL suponemos que no hay mas de 10 datos y 1 como mnimo (restriccion
LEN TOO LONG IN FUZZY COL LIST).

- COM: Almacena un comentario opcional sobre el atributo. En general es util para poner,
por ejemplo, el nombre de la tabla y el atributo, de forma que sea facil descubrir que
Tipo difuso tiene un atributo particular, sin tener que saber su pareja de numeros
(OBJ#,COL#).
El tratamiento de un atributo depende fundamentalmente del campo F TYPE y segun el
valor de este es distinto lo que almacenaremos en la FMB, como veremos mas adelante.

 Tabla FUZZY OBJECT LIST


Esta tabla contiene una lista de los objetos de tipo difuso que hay de nidos en las columnas
de la base de datos. Ademas, re eja una clasi cacion de estos objetos mediante el campo
FUZZY TYPE.

CREATE TABLE FUZZY_OBJECT_LIST(


OBJ# NUMBER NOT NULL,
COL# NUMBER NOT NULL,
FUZZY_ID NUMBER(3) NOT NULL, -- No m
as de 1000 objetos por cada atributo
FUZZY_NAME VARCHAR2(30) NOT NULL,
FUZZY_TYPE NUMBER(1) NOT NULL,
PRIMARY KEY (OBJ#,COL#,FUZZY_ID),
CONSTRAINT FK_OBJ#_COL#_FOL FOREIGN KEY (OBJ#,COL#)
REFERENCES FUZZY_COL_LIST (OBJ#,COL#) ON DELETE CASCADE,
CONSTRAINT NO_SPACES_IN_FUZZY_NAME
CHECK (FUZZY_NAME NOT LIKE '% %'));

Los atributos de esta tabla tienen el siguiente signi cado:


- (OBJ#,COL#): Almacena el identi cador del atributo al que pertenece el objeto. Es una
llave externa a la anterior tabla (restriccion FK OBJ# COL# FOL).
148 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
- FUZZY ID: Identi cador del objeto difuso. Llave externa a las tablas FUZZY LABEL DEF
y FUZZY NEARNESS DEF.
- FUZZY NAME: Nombre del objeto sin espacios (restriccion NO SPACES IN FUZZY NAME).
- FUZZY TYPE: Tipo del objeto. Puede ser uno de los siguientes
 0 para etiquetas lingusticas de tipo trapezoidal de nida en la tabla FUZZY LABEL DEF.
 1 para escalares sujetos a tratamiento mediante una relacion de semejanza de nida
en FUZZY NEARNESS DEF.
 2 para cuali cadores de nidos sobre el ndice de cumplimiento en la consulta (um-
bral) y almacenados en la tabla FUZZY QUALIFIERS DEF.
 3 para etiquetas lingusticas de nidas sobre cuanti cadores relativos y almacenadas
en la tabla FUZZY LABEL DEF con ALFA, BETA, GAMMA, DELTA 2 [0; 1] (ver apartado
2.9.2).
 4 para etiquetas lingusticas de nidas sobre cuanti cadores absolutos y almacena-
das en la tabla FUZZY LABEL DEF con ALFA, BETA, GAMMA, DELTA  0 (ver apartado
2.9.2).

 Tabla FUZZY LABEL DEF


Esta tabla contiene los puntos que determinan la distribucion de posibilidad trapezoi-
dal correspondientes a los tipos de objetos 0, 3 y 4 del atributo FUZZY TYPE de la tabla
FUZZY OBJECT LIST. El signi cado de esa distribuci
on depende, naturalmente, de ese tipo.
CREATE TABLE FUZZY_LABEL_DEF(
OBJ# NUMBER NOT NULL,
COL# NUMBER NOT NULL,
FUZZY_ID NUMBER(3) NOT NULL, -- FUZZY_OBJECT_LIST.FUZZY_ID%TYPE
ALFA NUMBER NOT NULL,
BETA NUMBER NOT NULL,
GAMMA NUMBER NOT NULL,
DELTA NUMBER NOT NULL,
PRIMARY KEY (OBJ#,COL#,FUZZY_ID),
CONSTRAINT FK_OBJ#_COL#_FUZZY_ID_FLD FOREIGN KEY (OBJ#,COL#,FUZZY_ID)
REFERENCES FUZZY_OBJECT_LIST (OBJ#,COL#,FUZZY_ID) ON DELETE CASCADE,
CONSTRAINT MUST_BE_ORDERED
CHECK (ALFA<=BETA AND BETA<=GAMMA AND GAMMA<=DELTA));

Los campos de esta tabla tienen el siguiente signi cado:


- (OBJ#,COL#,FUZZY ID): Estos 3 campos son la llave primaria de esta tabla y llave externa
a la tabla FUZZY OBJECT LIST (restriccion FK OBJ# COL# FUZZY ID FLD).
- ALFA, BETA, GAMMA y DELTA: De nen una distribuci
on de posibilidad trapezoidal del tipo
de la Figura 5.2 (pagina 136):
 DE LA BDRD: FIRST
5.1. IMPLEMENTACION 149

= inf fx : x 2 support(label)g (5.1)


= inf fx : x 2 kernel(label)g (5.2)
= supfx : x 2 kernel(label)g (5.3)
 = supfx : x 2 support(label)g (5.4)
donde support es el conjunto soporte de la etiqueta label (conjunto de valores que son
distintos de cero) y kernel es el nucleo de la etiqueta label (conjunto de valores que
tienen su grado de posibilidad igual a 1).
Estos 4 campos tienen la obligacion de cumplir la condicion que le impone la restriccion
MUST BE ORDERED:

  

 Tabla FUZZY APPROX MUCH


Esta tabla almacena datos que son utilizados cuando se trabaja con atributos difusos
Tipos 1 o 2.
CREATE TABLE FUZZY_APPROX_MUCH(
OBJ# NUMBER NOT NULL,
COL# NUMBER NOT NULL,
MARGEN NUMBER NOT NULL,
MUCH NUMBER NOT NULL,
PRIMARY KEY (OBJ#,COL#),
CONSTRAINT FK_OBJ#_COL#_FAM FOREIGN KEY (OBJ#,COL#)
REFERENCES FUZZY_COL_LIST (OBJ#,COL#) ON DELETE CASCADE,
CONSTRAINT MARGEN_LESS_THAN_MUCH_IN_FAM
CHECK (MARGEN<MUCH));

Sus campos tienen el siguiente signi cado:


- (OBJ#,COL#): Almacena el identi cador del atributo al que pertenece el objeto. Es
la llave primaria de la tabla y llave externa a la tabla FUZZY COL LIST (restriccion
FK OBJ# COL# FAM).

- MARGEN: Es el margen utilizado en las etiquetas triangulares de valores \aproximados".


Estas funciones de pertenencia son de tipo triangular, con valor de pertenencia 1 para
el valor sobre el que se considera la aproximacion y estan caracterizadas por este valor
que ha de ser aportado en la consulta y por la anchura de lo que podramos considerar
la base del triangulo. Ver Figura 5.4 (pagina 138).
- MUCH: Es el valor que indica la distancia mnima para que 2 valores de este atributo sean
considerados como muy separados. Es utilizado, como se explica mas adelante, en los
comparadores difusos MGT, NMGT, MLT y NMLT.
150 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
En esta tabla la restriccion MARGEN LESS THAN MUCH IN FAM obliga a que el valor de MARGEN
sea menor que el de MUCH, cosa que es razonable y que evita posibles equivocaciones si se
introducen los datos en un orden erroneo.

 Tabla FUZZY NEARNESS DEF


Esta tabla representa las medidas de proximidad, semejanza o similitud entre los diferentes
valores de dominio permitidos sobre los campos de Tipo 3.
CREATE TABLE FUZZY_NEARNESS_DEF(
OBJ# NUMBER NOT NULL,
COL# NUMBER NOT NULL,
FUZZY_ID1 NUMBER(3) NOT NULL, -- FUZZY_OBJECT_LIST.FUZZY_ID%TYPE
FUZZY_ID2 NUMBER(3) NOT NULL, -- FUZZY_OBJECT_LIST.FUZZY_ID%TYPE
DEGREE NUMBER (3,2) NOT NULL,
PRIMARY KEY (OBJ#,COL#,FUZZY_ID1,FUZZY_ID2),
CONSTRAINT FK_OBJ#_COL#_FUZZY_ID1_FND FOREIGN KEY (OBJ#,COL#,FUZZY_ID1)
REFERENCES FUZZY_OBJECT_LIST (OBJ#,COL#,FUZZY_ID) ON DELETE CASCADE,
CONSTRAINT FK_OBJ#_COL#_FUZZY_ID2_FND FOREIGN KEY (OBJ#,COL#,FUZZY_ID2)
REFERENCES FUZZY_OBJECT_LIST (OBJ#,COL#,FUZZY_ID) ON DELETE CASCADE,
CONSTRAINT FUZZY_ID1_IGUAL_QUE_FUZZY_ID2
CHECK (FUZZY_ID1<>FUZZY_ID2),
CONSTRAINT FUZZY_ID1_MAYOR_QUE_FUZZY_ID2
CHECK (FUZZY_ID1<FUZZY_ID2),
CONSTRAINT DEGREE_MUST_BE_IN_0_1_INTERVAL
CHECK (DEGREE>=0 AND DEGREE<=1));

Sus campos tienen la siguiente lectura:


- (OBJ#,COL#): Almacena el identi cador del atributo Tipo 3 que posee la funcion de
semejanza que aqu se almacena.
- FUZZY ID1: Identi cador de un objeto etiqueta. Los atributos (OBJ#,COL#,FUZZY ID1)
forman una llave externa que debe existir en la tabla FUZZY OBJECT LIST (restriccion
FK OBJ# COL# FUZZY ID1 FND) y en esta tabla su campo FUZZY TYPE correspondiente
debe tener el valor 1.
- FUZZY ID2: Identi cador de otro objeto etiqueta. Los atributos (OBJ#,COL#,FUZZY ID2)
forman una llave externa que debe existir en la tabla FUZZY OBJECT LIST (restriccion
FK OBJ# COL# FUZZY ID2 FND) y en esta tabla su campo FUZZY TYPE correspondiente
debe tener el valor 1.
- DEGREE: Grado de similitud o semejanza entre las etiquetas indicadas por los 2 atributos
anteriores (FUZZY ID1 y FUZZY ID2). Este valor estara comprendido en el intervalo [0,1]
(restriccion DEGREE MUST BE IN 0 1 INTERVAL) y se admite un maximo de 2 numeros
decimales. En datos difusos una mayor precision no es, de hecho, importante.
Como suponemos que la relacion de semejanza cumple la propiedad re exiva, no se alma-
cenara una comparacion para un par de etiquetas iguales, por lo que los identi cadores de las
 DE LA BDRD: FIRST
5.1. IMPLEMENTACION 151

etiquetas deben ser distintos (restriccion FUZZY ID1 IGUAL QUE FUZZY ID2). Se supone que
una etiqueta es \similar" a ella misma en grado 1.
Ademas, la relacion de semejanza cumple la propiedad simetrica, por lo que solo se alma-
cenara un grado de similitud por cada pareja de etiquetas distintas y se exige que los identi -
cadores de las etiquetas esten ordenados, de forma que el identi cador puesto en primer lugar
sea menor que el puesto en segundo lugar (restriccion FUZZY ID1 MAYOR QUE FUZZY ID2), de
forma que se aceleran las consultas a esta tabla, ya que sabemos en que orden son almacenadas
las parejas de etiquetas.
La llave primaria de esta relacion esta formada por los atributos: OBJ#, COL#, FUZZY ID1
y FUZZY ID2.

 Tabla FUZZY COMPATIBLE COL


Indica los atributos difusos Tipo 3 que son compatibles con otros. De esta forma no es
necesario de nir las etiquetas y las relaciones de similitud para cada uno de ellos. Ademas,
esto nos permite comparar dos atributos difusos Tipo 3 entre s, si son compatibles, ya que
esto indica que ambos atributos tienen el mismo dominio.
CREATE TABLE FUZZY_COMPATIBLE_COL(
OBJ#1 NUMBER NOT NULL,
COL#1 NUMBER NOT NULL,
OBJ#2 NUMBER NOT NULL,
COL#2 NUMBER NOT NULL,
PRIMARY KEY (OBJ#1,COL#1),
CONSTRAINT FK_OBJ#1_COL#1_FCC FOREIGN KEY (OBJ#1,COL#1)
REFERENCES FUZZY_COL_LIST (OBJ#,COL#) ON DELETE CASCADE,
CONSTRAINT FK_OBJ#2_COL#2_FCC FOREIGN KEY (OBJ#2,COL#2)
REFERENCES FUZZY_COL_LIST (OBJ#,COL#) ON DELETE CASCADE);

Sus campos tienen el siguiente signi cado:


- (OBJ#1,COL#1): Almacena el identi cador del atributo Tipo 3 que es compatible con
otro. Es la llave primaria e indica que este atributo no tiene etiquetas de nidas sobre
el y tomara las de nidas por el siguiente atributo. Esta pareja de atributos es llave
externa a la tabla FUZZY COL LIST (restriccion FK OBJ#1 COL#1 FCC).
- (OBJ#2,COL#2): Almacena el identi cador de un atributo Tipo 3 que tiene etiquetas
y relaciones de semejanza de nidas sobre el y que seran adoptadas por el atribu-
to (OBJ#1,COL#1). Igualmente, esta pareja de atributos es llave externa a la tabla
FUZZY COL LIST (restricci
on FK OBJ#2 COL#2 FCC).

 Tabla FUZZY QUALIFIERS DEF


Expresa el nivel de umbral de cumplimiento mnimo asociado al cuali cador lingustico
asociado en la tabla FUZZY OBJECT LIST con FUZZY TYPE igual a 2. En el apartado 5.1.2.3
esta explicado un poco mas en detalle.
152 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
CREATE TABLE FUZZY_QUALIFIERS_DEF(
OBJ# NUMBER NOT NULL,
COL# NUMBER NOT NULL,
FUZZY_ID NUMBER(3) NOT NULL,
QUALIFIER NUMBER(3,2) NOT NULL,
PRIMARY KEY (OBJ#,COL#,FUZZY_ID),
CONSTRAINT FK_OBJ#_COL#_FUZZY_ID_FQD FOREIGN KEY (OBJ#,COL#,FUZZY_ID)
REFERENCES FUZZY_OBJECT_LIST (OBJ#,COL#,FUZZY_ID) ON DELETE CASCADE);

Sus campos tienen el siguiente signi cado:


- (OBJ#,COL#,FUZZY ID): Estos 3 campos son la llave primaria y llave externa a la tabla
FUZZY OBJECT LIST (restricci on FK OBJ# COL# FUZZY ID FQD) y tienen identicos signi-
cados.
- QUALIFIER: El cuali cador asociado es un numero en el intervalo [0,1], que admite 2
decimales como maximo
La utilidad de esta tabla y la de los cuali cadores sobre los umbrales de cumplimiento es
mnima, por lo que no ha sido implementada aun en el Servidor FSQL.
5.1.3.3 Resumen del Contenido de la FMB
Resumiendo, la FMB almacena una lista con los atributos que admiten tratamiento difuso y
su Tipo de atributo difuso (1, 2 o 3). Ademas, para cada atributo difuso se almacena distinta
informacion dependiendo de su Tipo:
 Atributos Difusos Tipo 1 o Tipo 2: Para poder usar atributos Tipo 1 (crisp) y atributos
Tipo 2 en condiciones difusas (consultas exibles) basta con declararlos como tales (tabla
FUZZY COL LIST de la FMB) y almacenar los siguientes datos en la FMB:

? Etiquetas lingusticas trapezoidales : Nombre de la etiqueta (tabla FUZZY OBJECT LIST)


y los valores ; ; and  (FUZZY LABEL DEF), como en la Figura 5.2.
? Valor para el margen de los valores aproximados (campo MARGEN de la tabla
FUZZY APROX MUCH): Usada cuando se emplean valores aproximados en un atributo
concreto (ver Figura 5.4 y Tablas 5.1 y 5.14).
? Distancia mnima para que dos valores sean considerados como muy separados
(campo MUCH de la tabla FUZZY APROX MUCH): Usada por los comparadores MGT/NMGT
y MLT/NMLT (ver ecuaciones 5.17, 5.18, 5.19 y 5.20).
? Cuali cadores y Cuanti cadores (tablas FUZZY QUALIFIERS DEF y FUZZY LABEL DEF).

 Atributos Difusos Tipo 3: Ademas de declararlos como tales (tabla FUZZY COL LIST),
en la FMB hay que almacenar tambien:
? Longitud maxima de sus distribuciones de posibilidad 4 (tabla FUZZY COL LIST).
4 Como ya se ha dicho, esto se re ere al numero maximo de parejas (posibilidad, referencia a etiqueta)
que puede tener una distribucion de posibilidad sobre el atributo difuso Tipo 3 en cuestion, para que pueda
almacenarse en la base de datos.
 DE LA BDRD: FIRST
5.1. IMPLEMENTACION 153

? Etiquetas lingusticas (escalares): Su nombre (tabla FUZZY OBJECT LIST) y la re-


lacion de similitud entre ellas (tabla FUZZY NEARNESS DEF).
? Compatibilidad entre atributos de este Tipo (tabla FUZZY COMPATIBLE COL).
? Cuali cadores y Cuanti cadores (tablas FUZZY QUALIFIERS DEF y FUZZY LABEL DEF).

5.1.3.4 Vistas sobre la FMB


Sobre las tablas de FIRST se han creado unas vistas que son utiles para consultar distintos
aspectos de una base de datos difusa de forma clara y sencilla.
Estas vistas son las siguientes:

 Vista LABELS FOR OBJCOL


Sirve para obtener o consultar facilmente las etiquetas de nidas sobre atributos difusos
Tipo 1 o 2 y los parametros del trapecio posibilstico asociado.
CREATE or replace view LABELS_FOR_OBJCOL AS
SELECT FOL.OBJ# OBJ#, FOL.COL# COL#,
Fuzzy_Name Label, Alfa, Beta, Gamma, Delta
FROM FOL, FLD
WHERE FOL.OBJ#=FLD.OBJ# AND FLD.FUZZY_ID=FOL.FUZZY_ID AND
FOL.COL#=FLD.COL# AND FOL.FUZZY_TYPE=0;

Sus campos tienen el siguiente signi cado:


- (OBJ#,COL#): Almacena el identi cador del atributo sobre el que esta de nida la etiqueta
especi cada en los demas campos.
- Label: Nombre de la etiqueta lingustica.
- (Alfa, Beta, Gamma, Delta): Indican la de nicion de la etiqueta de forma trapezoidal
del tipo de la Figura 5.2 (pagina 136).

 Vista LABELS OBJCOL T3


Sirve para obtener o consultar facilmente las etiquetas de nidas sobre atributos difusos
Tipo 3, as como la relacion de similitud entre ellos.
CREATE or replace view LABELS_OBJCOL_T3 AS
SELECT FND.OBJ# OBJ#, FND.COL# COL#,
FOL1.FUZZY_NAME Label_1, FOL2.FUZZY_NAME Label_2, DEGREE
FROM FOL FOL1, FOL FOL2, FND
WHERE FOL1.OBJ#=FOL2.OBJ# AND FOL1.COL#=FOL2.COL# AND
FOL1.OBJ#=FND.OBJ# AND FOL1.COL#=FND.COL# AND
FOL1.FUZZY_TYPE=1 AND FOL2.FUZZY_TYPE=1 AND
FND.FUZZY_ID1=FOL1.FUZZY_ID AND FND.FUZZY_ID2=FOL2.FUZZY_ID;
154 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
Sus campos tienen el siguiente signi cado:
- (OBJ#,COL#): Almacena el identi cador del atributo sobre el que estan de nidas las
etiquetas especi cadas en los demas campos.
- Label 1: Nombre de una etiqueta lingustica de nida sobre el atributo anterior.
- Label 2: Nombre de otra etiqueta lingustica.
- DEGREE: Es el grado de similitud de nido entre las etiquetas Label 1 y Label 2.

 Vista ALL COMPATIBLES T3


Sirve para obtener o consultar facilmente los atributos difusos Tipo 3 que se han de nido
como compatibles a otros. De esta forma, podemos saber que atributos difusos Tipo 3 no
tienen etiquetas de nidas sobre ellos y cuales s las tienen. Ademas, tambien nos muestra la
longitud maxima permitida para las distribuciones de posibilidad de esos atributos difusos
Tipo 3.
CREATE or replace view ALL_COMPATIBLES_T3 AS
SELECT distinct FCL1.COM Columna_1, FCL1.LEN Length_1,
FCL2.COM Compatible_Con_Columna_2, FCL2.LEN Length_2
FROM FCL FCL1, FCL FCL2, FCC
WHERE FCL1.OBJ#=FCC.OBJ#1 AND FCL2.OBJ#=FCC.OBJ#2 AND
FCL1.COL#=FCC.COL#1 AND FCL2.COL#=FCC.COL#2;

Sus campos tienen el siguiente signi cado:


- Columna 1: Nombre de la columna que es compatible con la siguiente y que, por tanto,
no tiene de nidas etiquetas sobre ella.
- Length 1: Longitud maxima para las distribuciones de posibilidad que podremos alma-
cenar en la columna anterior.
- Compatible Con Columna 2: Nombre de la columna que tiene de nidas las etiquetas,
las cuales tambien usara Columna_1.
- Length 2: Longitud maxima para las distribuciones de posibilidad para la segunda
columna.
5.1.4 Ejemplo de Implementacion en FIRST de la BD y la FMB
En este apartado vamos a ilustrar como se representan en la base de datos y en la FMB una
tabla con todos los Tipos difusos vistos y algunos no difusos. Representaremos la relacion
de la Tabla 5.4, que muestra una relacion de los empleados de una determinada empresa. A
lo largo de este ejemplo vamos a ver como se implementa la informacion que recoge dicha
relacion. Veremos la estructura interna que adoptan los campos difusos en la base de datos y
como se almacenan los datos relativos a los atributos difusos en la FMB.
Como vemos, la tabla EMPLEADOS tiene los siguientes atributos:
 DE LA BDRD: FIRST
5.1. IMPLEMENTACION 155

6 JOVEN MADURO MAYOR


1
 A B B
 A B B
  A  B B
  A  B B
  A  B B
  A  B B
  A B B -
0 16 25 30 35 40 45 50 55 65 80 EDAD
a)

6 BAJO MEDIO ALTO


1
 B  A 
 B  A 
 B A
 B A
 B  A
  B  A
  B  A SALARIO-
0 50 65 85 95 110 130 180  1000$
b)

Figura 5.8: De nicion de etiquetas sobre los atributos EDAD y SALARIO.


156 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
NOMBRE SALARIO EDAD RENDIMIENTO
N1 85000 31 Bueno
N2 100000 Maduro Regular
N3 90000 Joven Malo
N4 21000 Mayor Excelente
N5 97000 Joven Unknown
N6 125000 #30 Bueno
N7 105000 [30,35] Regular
N8 180000 $[22,25,33,35] Bueno
N9 105000 Unknown Regular
El smbolo # signi ca \aproximadamente", [n,m] es un intervalo y
el valor $[ ; ; ; ] es un trapecio posibilstico.
Tabla 5.4: Ejemplo de para la relacion EMPLEADOS.

 NOMBRE: Almacena el nombre de los empleados. Es un atributo \crisp", no difuso,


de tipo texto. Por supuesto, tambien se pueden de nir atributos \crisp" de cualquier
otro tipo base del SGBD (numeros, fechas...). Este campo sera la clave primaria de
esta tabla.
 SALARIO: Almacena el salario de cada empleado. Es un atributo difuso Tipo 1. Por
tanto, todos los valores que puede almacenar esa columna son de tipo \crisp", como
puede observarse en la tabla. Sin embargo, como se detalla mas adelante, este atributo
mantiene informacion en la FMB. La Figura 5.8 b) muestra la de nicion de las etiquetas
lingusticas de nidas sobre este atributo. El valor del margen para valores aproximados
es de 15000 y la distancia mnima para considerar dos valores como muy separados es
de 40000. Ambos valores son almacenados en FUZZY APPROX MUCH, Tabla 5.7.
 EDAD: Almacena la edad de cada empleado. Es un atributo difuso Tipo 2 y puede,
por tanto, almacenar todos los tipos de datos que se mostraron en la Tabla 5.1. La
Figura 5.8 a) muestra la de nicion de las etiquetas lingusticas de nidas sobre este
atributo. El valor del margen para valores aproximados es de 5 y la distancia mnima
para considerar dos valores como muy separados es de 9. Ambos valores son almacenados
en FUZZY APPROX MUCH, Tabla 5.7.
sr (d; d0 )
Malo Regular Bueno Excelente
Malo 1 0.8 0.5 0.1
Regular 0.8 1 0.7 0.5
Bueno 0.5 0.7 1 0.8
Excelente 0.1 0.5 0.8 1
Tabla 5.5: Relacion de Similitud sr sobre RENDIMIENTO.

 RENDIMIENTO: Almacena una cali cacion del rendimiento de cada empleado. Es


un atributo difuso Tipo 3 y puede, por tanto, almacenar los tipos de datos que se
mostraron en la Tabla 5.2. Para simpli car hemos supuesto que la maxima longitud de
 DE LA BDRD: FIRST
5.1. IMPLEMENTACION 157

las distribuciones de posibilidad para este atributo es 1. Las etiquetas (escalares) que
tiene de nidas y su relacion de similitud estan expresadas en la Tabla 5.5.
Con esos datos, tenemos que la tabla FUZZY COL LIST tiene los datos expresados en la
Tabla 5.6. Para mayor claridad, los numeros de los atributos OBJ# y COL# han sido sustituidos
por el nombre de los objetos que representan entre parentesis, en todas las tablas del ejemplo.
OBJ# COL# F TYPE LEN COM
(Empleados) (Salario) 1 NULL 'EMPLEADOS.SALARIO'
(Empleados) (Edad) 2 NULL 'EMPLEADOS.EDAD'
(Empleados) (Rendimiento) 3 1 'EMPLEADOS.RENDIMIENTO'

Tabla 5.6: Ejemplo para la tabla FUZZY COL LIST.

OBJ# COL# MARGEN MUCH


(Empleados) (Salario) 15000 40000
(Empleados) (Edad) 5 9

Tabla 5.7: Ejemplo para la tabla FUZZY APPROX MUCH.


En la tabla FUZZY OBJECT LIST apareceran todas las etiquetas de la Figura 5.8 y de la
Tabla 5.5. Esto es mostrado en la Tabla 5.8. Las etiquetas trapezoidales registradas en esa
tabla, con FUZZY TYPE=0, estan de nidas en FUZZY LABEL DEF, Tabla 5.9.
OBJ# COL# FUZZY ID FUZZY NAME FUZZY TYPE
(Empleados) (Salario) 0 'BAJO' 0
(Empleados) (Salario) 1 'MEDIO' 0
(Empleados) (Salario) 2 'ALTO' 0
(Empleados) (Edad) 0 'JOVEN' 0
(Empleados) (Edad) 1 'MADURO' 0
(Empleados) (Edad) 2 'MAYOR' 0
(Empleados) (Rendimiento) 0 'MALO' 1
(Empleados) (Rendimiento) 1 'REGULAR' 1
(Empleados) (Rendimiento) 2 'BUENO' 1
(Empleados) (Rendimiento) 3 'EXCELENTE' 1

Tabla 5.8: Ejemplo para la tabla FUZZY OBJECT LIST.


La relacion de similitud sobre el atributo RENDIMIENTO de la Tabla 5.5, es almacenada
en la FMB en FUZZY NEARNESS DEF, Tabla 5.10.
Una vez hechas esas de niciones, la relacion EMPLEADOS queda implementada en el
SGBDR Oracle como re eja la Tabla 5.11, donde hemos adoptado para los atributos EDAD
y RENDIMIENTO, la implementacion mostrada en las Tablas 5.1 y 5.2 respectivamente
(apartado 5.1.3.1).
158 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL

OBJ# COL# FUZZY ID ALFA BETA GAMMA DELTA


(Empleados) (Salario) 0 50000 65000 85000 95000
(Empleados) (Salario) 1 85000 95000 110000 130000
(Empleados) (Salario) 2 110000 130000 999999 999999
(Empleados) (Edad) 0 0 16 30 40
(Empleados) (Edad) 1 25 35 45 55
(Empleados) (Edad) 2 40 50 65 80

Tabla 5.9: Ejemplo para la tabla FUZZY LABEL DEF.

OBJ# COL# FUZZY ID1 FUZZY ID2 DEGREE


(Empleados) (Rendimiento) 0 1 0.8
(Empleados) (Rendimiento) 0 2 0.5
(Empleados) (Rendimiento) 0 3 0.1
(Empleados) (Rendimiento) 1 2 0.7
(Empleados) (Rendimiento) 1 3 0.5
(Empleados) (Rendimiento) 2 3 0.8

Tabla 5.10: Ejemplo para la tabla FUZZY NEARNESS DEF.


 DE LA BDRD: FIRST
5.1. IMPLEMENTACION 159

NOMBRE SALARIO EDADT EDAD1 EDAD2 EDAD3 EDAD4 : : :


N1 85000 3 31 NULL NULL NULL :::
N2 100000 4 1 NULL NULL NULL :::
N3 90000 4 0 NULL NULL NULL :::
N4 21000 4 2 NULL NULL NULL :::
N5 97000 4 0 NULL NULL NULL :::
N6 125000 6 30 25 35 5 :::
N7 105000 5 30 NULL NULL 35 :::
N8 180000 7 22 25 33 35 :::
N9 105000 0 NULL NULL NULL NULL :::

: : : RENDIMIENTOT RENDIMIENTOP1 RENDIMIENTO1


::: 3 1 2
::: 3 1 1
::: 3 1 0
::: 3 1 3
::: 0 NULL NULL
::: 3 1 2
::: 3 1 1
::: 3 1 2
::: 3 1 1
Ver en la tabla FUZZY OBJECT LIST (5.8) los identi cadores (FUZZY ID) para las etiquetas de
EDAD1 y RENDIMIENTO1.

Tabla 5.11: Representacion interna real de la relacion de ejemplo EMPLEADOS en el SGBD


con la extension FIRST.
160 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
5.2 Sintaxis y Semantica del Lenguaje FSQL
Como se vio en el apartado 1.2.5, el lenguaje SQL fue desarrollado basicamente por Cham-
berlin et al. [37, 38] en la segunda mitad de los a~nos 70. Hoy da la bibliografa sobre el
lenguaje SQL es muy extensa [26, 52, 86] y en todos se explican los comandos basicos de este
lenguaje en sus dos vertientes:
 DML (Data Manipulation Language, Lenguaje de Manipulacion de Datos): Las sen-
tencias de este lenguaje permiten la consulta y la modi cacion de los datos almacenados
en la base de datos. Ejemplos de comandos del DML SQL son: SELECT, INSERT, DELETE
y UPDATE. Estas comandos son explicadas brevemente en el apartado 1.2.5.
 DDL (Data De nition Language, Lenguaje de De nicion de Datos): Las sentencias
de este lenguaje permiten la creacion y modi cacion de las estructuras en las que se
almacenaran los datos. Ejemplos de comandos del DDL SQL son: CREATE (para crear
objetos de la base de datos: tablas, vistas...), DROP (para borrar objetos), ALTER (para
modi car objetos), y sentencias para controles de seguridad, ndices y control del al-
macenamiento fsico de los datos. Algunos autores distinguen entre el DDL y el DCL
(Data Control Language, Lenguaje de Control de Datos), dejando para este ultimo las
tareas de control (de seguridad, almacenamiento...).
Para expresar formalmente la sintaxis de una sentencia hemos elegido la forma de gramatica
utilizando el formato de Yacc (ver Apendice B).
Cada sentencia FSQL que se desee ejecutar debe ser previamente analizada por el sistema
para asegurar, por un lado que la sentencia esta correctamente escrita (pertenece a nuestra
gramatica) y por otro, que tiene sentido efectuarla (por ejemplo, que usamos objetos validos).
Para ello usamos los tpicos 3 analizadores siguientes, los cuales son explicados en profundidad
en el apartado 5.5 sobre la implementacion del Servidor FSQL y que ahora, solo resumimos
brevemente:
1. Analizador Lexico: Asegura que todos los elementos de la sentencia estan permitidos,
agrupando los caracteres en palabras (tokens ). Igual que SQL, el lenguaje FSQL no es
sensible a mayusculas/minusculas, i.e., las sentencias pueden escribirse independiente-
mente en mayusculas, minusculas o ambas.
2. Analizador Sintactico: Asegura que los tokens estan en un orden adecuado y que la
construccion de la sentencia es correcta sintacticamente.
3. Analizador Semantico: Asegura que el signi cado de la sentencia es correcto y que,
por tanto, tiene sentido efectuarla.
A continuacion nos centraremos en revisar la sintaxis de los comandos mas utiles e im-
portantes, explicando las novedades que estos incorporan en FSQL para que nos permitan
manejar informacion difusa. Las gramaticas utilizadas estan incluidas en el Apendice B
(pagina 273).
5.2.1 El DML de FSQL: SELECT, INSERT, DELETE y UPDATE
Dentro del DML la sentencia mas usual y mas compleja es la sentencia de consulta de da-
tos, SELECT, aunque tambien son interesantes las sentencias INSERT, DELETE y UPDATE. A
continuacion de nimos el formato para estas sentencias en FSQL.

5.2. SINTAXIS Y SEMANTICA DEL LENGUAJE FSQL 161

5.2.1.1 Novedades en el SELECT Difuso


La sentencia SELECT es una sentencia tan potente como compleja y exible, muy facil de
usar en consultas simples y no tan facil de usar en consultas complejas debido a su potencia
y versatilidad. Esta sentencia es tan potente que rara vez se llega a utilizar todo su poder
expresivo para realizar una consulta, pues lo normal es efectuar consultas mucho mas simples
de lo que SELECT permite.
A veces, para simpli car la escritura y el entendimiento de consultas complicadas se usan
vistas intermedias que son creadas como subconsultas a la base de datos.
El lenguaje FSQL es una autentica extension de SQL. Esto signi ca que todas las senten-
cias validas en SQL lo son tambien en FSQL. Ademas, FSQL incorpora algunas novedades
para permitir el tratamiento de informacion imprecisa. Basicamente, las extensiones efectua-
das a esta sentencia son las siguientes:
 Etiquetas Lingusticas: Si un atributo es susceptible de tratamiento difuso entonces
pueden de nirse etiquetas sobre el. Estas etiquetas son precedidas, por convenio, por
el smbolo $ para distinguirlas facilmente de otros identi cadores.
Hay 2 tipos de etiquetas que seran usadas en diferentes tipos de atributos difusos.
1. Etiquetas para atributos con un dominio subyacente ordenado : Cada etiqueta de
este tipo tiene asociada, en la FMB5 , una distribucion de posibilidad trapezoidal
como la de la Figura 5.2 (pagina 136). As, por ejemplo, podemos de nir las eti-
quetas $Muy Bajo, $Bajo, $Normal, $Alto y $Muy Alto sobre el atributo Altura
de una persona. Por ejemplo, El atributo $Alto puede ser de nido como una dis-
tribucion de posibilidad con los siguientes valores (en centmetros) =185, =195,
=200 y =210, como se muestra en la Figura 5.3.
2. Etiquetas para atributos con un dominio subyacente no ordenado (como los esca-
lares de los tipos 1, 3 y 5 en la Tabla 2.4): Aqu, puede haber una relacion de
similitud de nida entre cada dos etiquetas del dominio y almacenada en la FMB.
El grado de similitud entre cada dos etiquetas sera un valor del intervalo [0,1].
Por ejemplo, para un atributo que almacenara el color del pelo de una persona
podramos de nir las etiquetas $Rubio y $Pelirrojo e indicar (en la relacion de
similitud) que ambos valores son similares en grado 0.6.
 Comparadores Difusos: Ademas de los comparadores clasicos tpicos (=, >...), FSQL
incluye los comparadores difusos de la Tabla 5.12. Como en SQL, los comparadores
difusos pueden comparar una columna de una tabla con una constante o dos columnas
del mismo tipo o de tipos compatibles.
Los comparadores de posibilidad son mas generales (menos restrictivos) que los de nece-
sidad. Por tanto, los comparadores de necesidad recuperan menos tuplas y estas tuplas
cumpliran necesariamente con las condiciones impuestas en la consulta. Ver apartado
5.2.1.6 para mas datos sobre la restrictividad de los comparadores.
En [78] y mas adelante, en el apartado 5.2.1.4 (pagina 170), se expone la de nicion de
todos estos comparadores con ejemplos sobre sus resultados.
5 La FMB (Fuzzy Metaknowledge Base, Base de Metaconocimiento Difuso) es un catalogo del sistema difuso
con informacion sobre los atributos difusos y fue explicada en el apartado 5.1.3.2.
162 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
Comp. Difuso Signi cado
Posibilidad FEQ Fuzzy EQual: Posiblemente Igual (sobre escalares o numeros difusos)
FGT Fuzzy Greater Than: Posiblemente Mayor que
FGEQ Fuzzy Greater or Equal: Posiblemente Mayor o Igual que
FLT Fuzzy Less Than: Posiblemente Menor que
FLEQ Fuzzy Less or Equal: Posiblemente Menor o Igual que
MGT Much Greater Than: Posiblemente Mucho Mayor que
MLT Much Less Than: Posiblemente Mucho Menor que
Necesidad NFEQ Necessarily Fuzzy EQual: Necesariamente Igual que (o incluido en)
NFGT N. Fuzzy Greater Than: Necesariamente Mayor que
NFGEQ N. Fuzzy Greater or Equal: Necesariamente Mayor o Igual que
NFLT N. Fuzzy Less Than: Necesariamente Menor que
NFLEQ N. Fuzzy Less or Equal: Necesariamente Menor o Igual que
NMGT N. Much Greater Than: Necesariamente Mucho Mayor que
NMLT N. Much Less Than: Necesariamente Mucho Menor que
Tabla 5.12: Comparadores Difusos de FSQL (Fuzzy SQL).

En atributos con dominio subyacente no ordenado (difusos Tipo 3) solo puede usarse el
comparador difuso FEQ, puesto que carecen de orden. Este comparador es de nido para
este Tipo de atributos en el apartado 5.2.1.7 (pagina 178).
El comparador difuso de \desigualdad" o \posiblemente distinto" no se ha considerado
porque puede modelarse negando una comparacion con FEQ:

NOT <Atributo Difuso> FEQ <Atributo o Cte>

 Umbral de Cumplimiento (threshold,  ): Para cada condicion simple se puede esta-


blecer un umbral de cumplimiento (por defecto sera 1) con el formato siguiente:

<Condici
on simple> THOLD 
indicando que la condicion debe ser satisfecha con un grado mnimo de  2 [0; 1] pa-
ra que la tupla en cuestion aparezca en la relacion resultante. La palabra reservada
THOLD es opcional y puede ser sustituida por cualquier comparador crisp tradicional (=,
...), modi cando as, logicamente, el signi cado de la consulta. La palabra THOLD es
equivalente a usar el comparador crisp .
En lugar de un numero, como umbral puede ponerse un cuali cador, que es un identi-
cador o etiqueta que debera estar de nida en la FMB6 .

Ejemplo 5.1 Dame todas las personas con pelo rubio (en grado mnimo 0.5) que son
posiblemente mas altas que la etiqueta $Alta (en grado mnimo 0.8):
6 Esta opcion no esta implementada en la presente version del Servidor FSQL, por lo que no esta contemplada
en la gramatica del Apendice B.

5.2. SINTAXIS Y SEMANTICA DEL LENGUAJE FSQL 163

<Condici
on> (con operadores logicos) CDEG(<Condici
on>)
<cond1> AND <cond2> min(CDEG(<cond1>),CDEG(<cond2>))
<cond1> OR <cond2> max(CDEG(<cond1>),CDEG(<cond2>))
NOT <cond1> 1 { CDEG(<cond1>)
Tabla 5.13: Operaciones usadas por defecto para el calculo de la funcion CDEG de FSQL con
operadores logicos.

SELECT * FROM Personas WHERE Pelo FEQ $Rubio THOLD 0.5 AND
Altura FGT $Alta THOLD 0.8

Si buscamos personas que son \necesariamente" mas altas que la etiqueta $Alta, en-
tonces debemos usar el comparador difuso NFGT en vez de FGT. tu

 Funcion CDEG(<atributo>): Una llamada a la funcion CDEG (Compatibility DEGree)


puede ser colocada en la lista de seleccion (expresiones tras la palabra reservada SELECT).
Su argumento es un atributo y muestra una columna con el grado de compatibilidad o
cumplimiento de la condicion de la consulta para el atributo que se indica. Si aparecen
operadores logicos (NOT, AND y/o OR), el calculo de este grado de cumplimiento es efec-
tuado usando las funciones que se indican en la Tabla 5.13: Se usa la norma triangular
del mnimo y del maximo, pero FSQL permite modi car las funciones a emplear. Para
ello hay que modi car la vista FSQL OPTIONS. En esta vista el usuario puede establecer
las funciones a usar para cada uno de los 3 operadores logicos. Obviamente, la funcion
que se indique en esa vista debe estar implementada en el SGBD y el usuario debe tener
acceso a la misma.
Estas funciones pueden ser implementadas por un usuario particular para su uso per-
sonal. La funcion para el NOT tendra un unico argumento numerico, mientras que las
funciones para el AND y para el OR tendran ambas dos argumentos numericos.
En el apartado 5.5.3.3 se explica el tratamiento que el Servidor FSQL da a las llamadas
a la funcion CDEG, y en el apartado 5.4.1 se detalla el formato de la vista FSQL OPTIONS y
como se cambian las funciones asociadas a los operadores logicos alterando su contenido.
La precedencia de los operadores logicos es la habitual, i.e., de mayor a menor prece-
dencia estan NOT, AND y OR.
Si el argumento de la funcion CDEG es un atributo, entonces la funcion CDEG solo usa
las condiciones que incluyen a ese atributo. Si el atributo indicado como argumento de
CDEG no aparece en la condici on, entonces, esta funcion no es aplicable a dicho atributo,
pero en vez de dar un error se procede a devolver grado 1 para todas las tuplas. Tambien
podemos usar un asterisco como argumento como se explica a continuacion.
 CDEG(*): Si esta funcion tiene un asterisco como argumento, entonces calcula y muestra
el grado de cumplimiento de la condicion para cada tupla. Este calculo es efectuado co-
mo se explico en el punto anterior pero teniendo en cuenta todos los atributos empleados
en la condicion, y no solo uno de ellos.
164 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
Cte. Difusa Signi cado
UNKNOWN Valor desconocido pero el atributo es aplicable (tipo 8 de la Tabla 2.4).
UNDEFINED Atributo no aplicable o sin sentido (tipo 9 de la Tabla 2.4).
NULL Ignorancia total: No sabemos nada sobre eso (tipo 10 de la Tabla 2.4).

$[ , , , ] Distribucion de posibilidad trapezoidal (   ): Ver Figura 5.2.
$label Etiqueta lingustica: Puede ser un trapecio o un escalar (de nidos en FMB).
[n,m] Intervalo \Entre n y m" ( = =n y ==m).
#n Valor difuso \Aproximadamente n" ( = =n y n{ ={n=margen en FMB).
Tabla 5.14: Constantes difusas que pueden ser usadas en FSQL.

 Caracter Comodn %: El empleo de este caracter es similar al del utilsimo caracter


comodn * de SQL, pero este, ademas de incluir todas las columnas de las tablas in-
dicadas en la parte FROM de la consulta, tambien incluye las columnas con el grado de
cumplimiento de aquellos atributos relevantes. O sea, en el resultado tambien encon-
traremos columnas donde la funcion CDEG esta aplicada a cada uno de los atributos que
aparecen en la condicion.
Si, en el Ejemplo 5.1, hubieramos querido obtener dos columnas mas con los grados
de CDEG(Pelo) y CDEG(Altura), podramos simplemente haber reemplazado el co-
modn * por %. Por supuesto, este caracter puede ser tambien usado con el formato
[[scheme.]table.]%, como por ejemplo: Personas.%.
Si un atributo difuso no aparece en la clausula WHERE, su CDEG no es aplicable y por
tanto no aparecera su CDEG si se usa el comodn %.
 Constantes Difusas: En FSQL podemos usar diversos tipos de constantes difusas.
Estos tipos son detallados en la Tabla 5.14. Ver Ejemplos 5.1, 5.2 y los ejemplos de los
apartados 5.2.1.8 y 5.2.1.10.
Como se ha dicho anteriormente las etiquetas estan registradas en la FMB, al igual que
el valor del margen para valores aproximados.
 Condicion con IS: Otra clase de condicion que podemos usar en FSQL tiene el si-
guiente formato:

8 UNKNOWN
<
< Atributo Difuso > IS [NOT]
: UNDEFINED (5.5)
NULL

Observaciones sobre la condicion con IS:


{ Este tipo de condicion (sin NOT) sera cierta si el valor del atributo difuso de la
izquierda (<Atributo Difuso>) es la constante situada a la derecha.
{ Si el atributo no es difuso y la constante de la derecha es NULL, esta constante sera
entendida de la forma que lo haga el SGBD (si este lo permite). En particular,

5.2. SINTAXIS Y SEMANTICA DEL LENGUAJE FSQL 165

Oracle permite valores NULL7 como valor posible de los atributos, aunque esto
puede ser evitado estableciendo la restriccion NOT NULL en los comandos CREATE
TABLE o ALTER TABLE.
{ Si FEQ es usado en vez de IS el signi cado es distinto. Con FEQ se compara el grado
de compatibilidad entre el atributo y la constante (ecuacion 4.3) y no simplemente
si el atributo es igual a la constante.
El Ejemplo 5.2 ilustra el uso de este tipo de condicion.
 Cuanti cadores difusos8 : Los cuanti cadores difusos [158, 164, 169] (apartado
2.9.2), tanto absolutos como relativos pueden establecerse de la siguiente forma (similar
a la de [22]), en sus dos modalidades, cuyos signi cados se muestran a continuacion con
unos ejemplos:
 on difusa ) THOLD
$Cuantificador FUZZY[ ] ( condici 

$Cuantificador FUZZY[ ] ( condici
on difusa1 ) ARE ( condici
on difusa2 )
THOLD 
donde $Cuantificador es un cuanti cador (absoluto o relativo). Esta precedido del
smbolo $ para distinguirlo de otros identi cadores. Ademas, algunos cuanti cadores
relativos pueden llevar un argumento entre corchetes. La opcion FUZZY[] es opcional,
al igual que su argumento .
Igual que en comparaciones difusas simples,  es un umbral opcional, normalmente
en [0,1], que debe cumplir el cuanti cador para que la condicion sea evaluada como
cierta (por defecto 1). Aqu, tambien la palabra THOLD es opcional y tambien puede
ser sustituida por cualquier comparador crisp tradicional, modi cando el signi cado de
la consulta. La palabra THOLD es equivalente a usar el comparador crisp . El uso de
estos cuanti cadores y su signi cado se explicara en el apartado 5.2.1.3.
 Comentarios: FSQL permite incorporar comentarios en las sentencias, de forma que
ellos no seran tenidos en cuenta al analizarla y ejecutarla. Los comentarios pueden ser
de 3 tipos:
1. Comentario hasta n de lnea: Con -- (dos guiones) se~nalamos que desde ese punto
hasta el nal de esa lnea es un comentario. Este tipo de comentarios es tambien
valido en SQL y PL/SQL.
2. Comentario de un bloque: Todo lo que este incluido entre las marcas /* y */
sera considerado como un comentario. Este tipo de comentarios (estandar en el
lenguaje C) es tambien valido en SQL y PL/SQL.
3. Comentario hasta n de sentencia: Con /* se~nalamos que desde ese punto hasta
el nal de la sentencia es un comentario. Es decir, si no se cierra el comentario se
supone que el comentario termina al nal, siendo ignorado totalmente el resto de
la sentencia. Este tipo de comentarios es propio de FSQL y generan un error si se
usan en SQL o PL/SQL.
7 No debe confundirse el valor NULL del SGBD Oracle con el valor de la constante difusa NULL de la
ecuacion 5.5 (o de la Tabla 5.14) que tiene el sentido difuso de Umano, Fukami et al. de [70] y [143].
8 Esta opcion no esta implementada en la presente version del Servidor FSQL, por lo que no esta contemplada
en la gramatica del Apendice B.
166 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
 Evitar que una sentencia pase por el Servidor FSQL: En determinadas cir-
cunstancias puede interesarnos que el Servidor FSQL no ejecute su funcion y se limite
simplemente a operar como si no estuviera (de forma clasica). Para ello basta con incor-
porar el smbolo ! (admiracion cerrada) como primer caracter de la sentencia enviada
al Servidor. O sea, si el Servidor FSQL encuentra que el primer caracter de la sentencia
es !, se comportara, con el resto de la sentencia, como si no estuviera.
Esto es util si el programa Cliente FSQL no admite la posibilidad de enviar una sentencia
SQL estandar, de forma que con este sistema aceleramos el proceso para este tipo de
sentencias, ya que el Servidor FSQL no se ejecuta completamente.
Ejemplo 5.2 Un ejemplo de consulta que muestre un grado de compatibilidad (usando
CDEG), use una constante de tipo trapezoidal y evite los valores UNKNOWN podra ser:
SELECT Ciudad,CDEG(Habitantes)
FROM Poblacion
WHERE Pais='Espa~na' AND
Habitantes FGEQ $[200,350,650,800] .75 AND
Habitantes IS NOT UNKNOWN;

Observaciones respecto a este ejemplo:


 El umbral mnimo de cumplimiento esta establecido en 0.75 (la palabra reservada THOLD
no aparece porque es opcional). As, en la tabla resultante, la columna CDEG(Habitantes)
tendra valores en el intervalo [0.75,1].
 Como usamos el comparador FGEQ, los valores y  del trapecio no seran usados, i.e.,
si el numero de habitantes es crisp y excede de 350, el grado de cumplimiento de esa
condicion sera 1. Naturalmente, si el numero de Habitantes es crisp y menor o igual
que 200 el grado sera cero.
 Si una ciudad espa~nola tiene en el atributo difuso Habitantes la distribucion de po-
sibilidad $[50,150,200,350], su grado de cumplimiento de la condicion sera 0.5 y no
aparecera, por tanto, en el resultado nal, ya que el umbral mnimo ha sido establecido
en 0.75.
tu
Las consultas difusas reducen el riesgo de obtener respuestas vacas, ya que permite utilizar
una escala de discriminacion mas na: El intervalo [0,1] en vez del conjunto f0,1g. Es decir,
permite recuperar tuplas en consultas que en modo crisp no se obtiene ninguna respuesta. Sin
embargo, a veces puede ocurrir que no existan elementos que satisfagan el resultado de una
consulta. Para solucionar ese posible problema, las consultas FSQL se muestran especialmente
exibles, pues en cada condicion simple, podemos actuar sobre los siguientes parametros de
consulta, para debilitar las condiciones:
1. Comparadores difusos (Tabla 5.12): Existe una gran variedad y alternar el uso de
comparadores entre posibilidad y necesidad puede resultar especialmente util.
2. Umbrales: Modi cando este valor podemos decidir el grado de importancia de las
tuplas que buscamos para recuperar solo los elementos mas importantes.

5.2. SINTAXIS Y SEMANTICA DEL LENGUAJE FSQL 167

3. Usar comparadores clasicos en lugar de la palabra THOLD: Con esto podemos


conseguir modi car el signi cado de la consulta. Por ejemplo, podemos recuperar los
elementos menos importantes usando el comparador < (o ). Tambien podemos recu-
perar justo los elementos que cumplen la condicion con un determinado grado usando
el comparador =.
4. Constantes difusas (Tabla 5.14): Si la parte derecha de una condicion simple es una
constante difusa esta puede ser modi cada para exibilizar la consulta y conseguir mejor
nuestro objetivo.
El debilitamiento de de consultas ha sido estudiado en [5, 6]. Otra propuesta en este
sentido [119] se basa en el clustering difuso de datos. O sea, cuando no existen datos que
satisfacen la consulta el sistema puede mostrar las clases de datos que s existen y provee la
clase mas cercana a la consulta, como una alternativa. Este sistema aplica el algoritmo de
clustering difuso C-means [16] para clasi car los datos en varios grupos difusos, representados
por etiquetas lingusticas de nidas por funciones de pertenencia.
5.2.1.2 Otros Comandos: ,
INSERT DELETE y UPDATE
Los comandos INSERT, DELETE y UPDATE tambien pertenecen, con el comando SELECT al DML
o Lenguaje de Manipulacion de Datos (igual que COMMIT y ROLLBACK) y su sintaxis es muy
similar a la que tienen en SQL, modi cando las expresiones, las subconsultas y las condicio-
nes por expresiones difusas, subconsultas difusas y condiciones difusas respectivamente. La
gramatica asociada a cada uno de estos comandos esta tambien en el Apendice B.
En sntesis, las modi caciones de FSQL son las siguientes para cada uno:
 INSERT:Podremos utilizar expresiones difusas como valores para la insercion, as como
subconsultas difusas, tanto en los valores a insertar como en las relaciones en las que se
insertan. El comando INSERT de SQL esta explicado en el apartado 1.2.5.2.
 DELETE: En la clausula WHERE de este comando se pueden utilizar las mismas condiciones
difusas que en la clausula WHERE del comando SELECT de FSQL, explicado anteriormente.
El comando DELETE de SQL esta explicado en el apartado 1.2.5.3.
 UPDATE: Los valores a actualizar podran ser expresiones difusas o subconsultas difusas.
Ademas, en la clausula WHERE de este comando se pueden utilizar las mismas condiciones
difusas que en la clausula WHERE del comando SELECT de FSQL, explicado anteriormente.
El comando UPDATE de SQL esta explicado en el apartado 1.2.5.4.
5.2.1.3 Cuanti cadores en FSQL
El uso de cuanti cadores ha sido muy estudiado, como se vio en el apartado 2.9.2. Aqu
exponemos el uso que puede hacerse de ellos en FSQL, incorporando cuanti cadores con y
sin argumentos.
A traves de algunos ejemplos mostraremos la potencia de los cuanti cadores en FSQL:
Ejemplo 5.3 Seleccionar los equipos de baloncesto que tienen muchos (con grado mnimo
0.5) jugadores altos y muy buenos (con umbrales 0.75). Mostrar tambien el grado con el que
cada equipo cumple el cuanti cador:
168 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL

1
Q 1
Q

0 0
0.5 0.75 1 0.25 0.75 1
a) b)

Figura 5.9: Dos cuanti cadores difusos relativos.

SELECT Equipo, CDEG(*)


FROM Jugadores
GROUP BY Equipo
HAVING $Muchos (Altura FEQ $Alto 0.75 AND
Calidad FEQ $Muy_Bueno 0.75) THOLD 0.5;

Observe que la condicion que requiere el cuanti cador puede ser multiple y que el cuanti-
cador muchos es un cuanti cador absoluto, que debera estar de nido en la FMB. Observe
que CDEG(*), cuando hay sentencias de grupo (GROUP BY), hace referencia a la condicion sobre
el grupo (HAVING). tu
Ejemplo 5.4 Seleccionar los equipos de baloncesto en los que la mayora (con grado mnimo
0.5) de sus jugadores altos son tambien muy buenos (con umbrales 0.75):
SELECT Equipo, CDEG(*)
FROM Jugadores
GROUP BY Equipo
HAVING $La_Mayoria (Altura FEQ $Alto 0.75)
ARE (Calidad FEQ $Muy_Bueno 0.75) 0.5;

El cuanti cador la mayora es un cuanti cador relativo, que debera estar de nido en la
FMB con la forma, por ejemplo, de la Figura 5.9 a). Observe que en este ejemplo no aparece
la palabra opcional THOLD, teniendo el mismo signi cado que en el ejemplo anterior (). tu
La palabra reservada FUZZY es opcional y si aparece, se indica que la evaluacion del
cuanti cador es hecha sumando, no los elementos que cumplen la condicion, sino el grado de
cumplimiento de los mismos. Con los siguientes ejemplos se aclarara este concepto.
Ejemplo 5.5 Seleccionar los equipos de baloncesto que tienen muchos mas que 3 (con grado
mnimo 0.5) jugadores altos (con grado mnimo 0.75):
SELECT Equipo, CDEG(*)
FROM Jugadores
GROUP BY Equipo
HAVING $Muchos_Mas_Que[3] (Altura FEQ $Alto 0.75) 0.5;

5.2. SINTAXIS Y SEMANTICA DEL LENGUAJE FSQL 169

El cuanti cador $Muchos_Mas_Que[3] es un cuanti cador relativo con un argumento, que


supondremos que esta de nido en la FMB como una funcion Q de la Figura 5.9 b).
Si un equipo, por ejemplo, tiene 4 jugadores que cumplen con la condicion, es decir, 4
jugadores que son altos con grado mnimo 0.75, entonces, este equipo cumple con el cuanti -
cador en grado Q(3=4) = Q(0:75) = 0. Por tanto, dicho equipo no aparecera en el resultado,
ya que se exige 0.5 como grado mnimo.
Supongamos otro equipo que tiene 6 jugadores que cumplen con la condicion. Entonces,
dicho equipo cumple con el cuanti cador en grado Q(3=6) = Q(0:5) = 0:5. Por tanto, dicho
equipo s aparecera en el resultado. As, un equipo que tenga 12 jugadores que cumplan con
la condicion, cumplira con el cuanti cador en grado Q(3=12) = Q(0:25) = 1. tu
En el ejemplo anterior, si un equipo tiene n jugadores que cumplen con la condicion, su
grado de cumplimiento del cuanti cador no depende del grado con el que esos n jugadores
cumplan la condicion. O sea, un equipo con n jugadores altos en grado 0.75 todos ellos tendra
el mismo grado de cumplimiento del cuanti cador que un equipo con n jugadores altos en
grado 1 todos ellos.
En sntesis, en el ejemplo anterior se ha considerado que el conjunto de los jugadores que
cumplen la condicion es crisp, o sea, que la cumplen o no la cumplen, o, lo que es lo mismo
que o son altos con grado mnimo 0.75 o no lo son. Sin embargo, hay otro metodo [169] que
considera el conjunto de los elementos que cumplen la condicion como difuso. Esto puede
ser conseguido en FSQL utilizando la palabra reservada FUZZY tras el cuanti cador. En este
metodo lo que se hace no es contar el numero de elementos que cumplen la condicion, sino
sumar los grados de cumplimiento de esos elementos.
Ejemplo 5.6 Seleccionar los equipos de baloncesto que tienen muchos mas que 3 (con gra-
do mnimo 0.5) jugadores altos (con grado mnimo 0.75), considerando el conjunto de los
jugadores que cumplen la condicion como difuso:
SELECT Equipo
FROM Jugadores
GROUP BY Equipo
HAVING $Muchos_Mas_Que[3] FUZZY (Altura FEQ $Alto 0.75) 0.5;

As, por ejemplo, un equipo con 6 jugadores que cumplen todos ellos con la condicion en
grado 1, cumple el cuanti cador en grado Q(3=6) = Q(0:5) = 0:5. Sea otro equipo, tambien
con 6 jugadores que cumplen la condicion, pero, de ellos 2 la cumplen en grado 1 y 4 en grado
0.75. En este caso, la sumatoria de los grados de cumplimiento es 5 (2*1+4*0.75), el equipo
cumple el cuanti cador en grado Q(3=5) = Q(0:6) = 0:3 y, por tanto, no sera seleccionado en
el resultado nal. tu
Puede usarse un argumento  2 [0; 1], de forma que FUZZY[] indique que, al evaluar el
cuanti cador, se tengan en cuenta ambos valores (sin la palabra FUZZY y con ella), ponderando
el primero de ellos (sin FUZZY) con la importancia que indique  y el segundo valor (con FUZZY)
con la importancia  1, tal y como se explico en el apartado 4.5 (expresion 4.29). As, poner
FUZZY[0] es equivalente a poner FUZZY y poner FUZZY[1] es equivalente a no poner nada.
Un cuanti cador difuso del tipo $Muchos_Menos_Que[n] puede ser modelado de la misma
forma que el cuanti cador del ejemplo anterior (Figura 5.9 b)), pero invirtiendo los operandos
de la division, de forma que ahora se aplica Q al resultado de la division t=n (y no a n=t), donde
170 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
A B
1


0
A A A B A B B B

Figura 5.10: Comparacion de dos distribuciones de posibilidad trapezoidales.

t es la suma de los elementos que cumplen la condicion, la suma del grado de cumplimiento
de la misma o la ponderacion de ambas usando . As, estos cuanti cadores deberan ser
identi cados segun su tipo en la FMB (en la tabla FUZZY OBJECT LIST), para indicar al
Servidor FSQL como deben ser aplicados.

5.2.1.4 De nicion de los Comparadores Difusos de FSQL para Atributos Difusos


Tipo 1 o 2
Los comparadores difusos (Tabla 5.12) pueden usarse para comparar atributos difusos, entre
s o con contantes (difusas o crisp).
Para atributos difusos Tipo 3 solo esta permitido usar el comparador difuso FEQ, ya que
no existe una relacion de orden en el dominio de estos atributos. Por ejemplo, no podemos
decir si el valor \Rubio" es mayor que el valor \Moreno", pero si podemos medir su similitud.
La de nicion de este comparador para este Tipo de atributos difusos se explica mas adelante
en el apartado 5.2.1.7.
En atributos difusos Tipo 2 podemos almacenar valores crisp {como en los Tipo 1{,
pero ademas podemos almacenar valores como los expresados en la Tabla 5.14. El caso mas
general es el Trapecio Difuso, pues este tipo de valor engloba a todos los demas. As, por
ejemplo, un valor aproximado #n es una distribucion de posibilidad triangular donde = =n
y n = n=margen y el valor para el margen es almacenado en la FMB (atributo MARGEN
de la tabla FUZZY APPROX MUCH) para cada atributo de cada relacion. Igualmente, un valor
intervalo [n,m] puede verse como un trapecio en el que = =n y ==m.
Por tanto, aqu nos centraremos en el estudio de los comparadores difusos cuando com-
paramos dos distribuciones de posibilidad trapezoidales, que es el caso mas general. Como se
vera mas adelante, el Servidor FSQL tiene en cuenta los tipos de distribuciones de posibili-
dad que hay que comparar en cada momento para observar sus peculiaridades y aumentar la
e ciencia de cada comparacion. As, si en una relacion hay muchos valores crisp (o muchos
intervalos...) las comparaciones seran mas rapidas que si hay muchos trapecios.
Supondremos que deseamos comparar dos distribuciones de posibilidad cualesquiera que
denotaremos por A=$[ A , A , A ,A ] y B=$[ B , B , B ,B ], como por ejemplo las que estan
representadas en la Figura 5.10. Usaremos tambien la funcion CDEG, para expresar el grado
de compatibilidad de una comparacion difusa. El resultado de esta comparacion dependera,
naturalmente, del comparador difuso (Tabla 5.12) empleado. A continuacion de nimos cada
uno de los comparadores difusos:

5.2. SINTAXIS Y SEMANTICA DEL LENGUAJE FSQL 171

 Comparador Difuso FEQ (Fuzzy EQual,Possibly Equal, Igual Difuso, Posible-


mente Igual): Para comparar dos distribuciones de posibilidad A y B (trapezoidales) y
obtener el Grado de Compatibilidad entre ellas, CDEG(A FEQ B), o, lo que es lo mismo,
en que medida son posiblemente similares, se usa la ecuacion:
CDEG(A FEQ B) = sup min (= (p; p0 ); A(p); B(p0 )) (5.6)
(p;p0 )2U U
= sup min (A(d); B(d)) (5.7)
d2U

donde U es el dominio subyacente a ambas distribuciones de posibilidad y A(d) es el


grado de posibilidad para el valor d 2 U en la distribucion de posibilidad A. La funcion
=, toma el valor 1 si sus argumentos son iguales y 0 si son diferentes.
En el caso de la Figura 5.10 obtenemos que las distribuciones A y B tienen un grado
de compatibilidad de ". Observe que este comparador difuso es el unico que posee la
propiedad conmutativa.
 Comparador Difuso NFEQ (Necessarily Fuzzy EQual, Necesariamente Igual
Difuso): Este comparador mide el grado de necesidad (u obligatoriedad) que existe
para que una distribucion sea (o este incluida en) otra. Este grado se calcula por la
ecuacion:

CDEG(A NFEQ B) = dinf


2U
max (1 A(d); B(d)) (5.8)

En el ejemplo de la Figura 5.10 tenemos que: CDEG(A NFEQ B) =0;


CDEG(B NFEQ A) =0;
Con otros comparadores distintos de la igualdad difusa, se modi ca la distribucion de
posibilidad de la parte derecha de la comparacion, tal y como se expresa en la Figura 5.11.
Ademas, en los comparadores difusos de necesidad se niega la distribucion de posibilidad
de la parte izquierda de la comparacion, tal y como se hace en la ecuacion 5.8.
 Comparadores Difusos FGT/NFGT (possibly/Necessarily Fuzzy Greater Than,
Posiblemente/Necesariamente Mayor Difuso): Para obtener el grado de compa-
tibilidad con el que una distribucion de posibilidad A es posiblemente/necesariamente
mayor que otra B se utilizan la siguientes ecuaciones:

81 si A  B
< A B
CDEG(A FGT B) =
: 0( B B ) ( A A ) si A < B y A > B (5.9)
en otro caso (A  B )
81 si A  B
< A B
CDEG(A NFGT B) =
: 0( B B ) ( A A ) si A < B y A > B (5.10)
en otro caso ( A  B )
172 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
A
1

0
A A A A

FGT A
1

0
A A A A

FGEQ A
1

0
A A A A

FLT A
1

0
A A A A

FLEQ A
1

0
A A A A

Figura 5.11: Modi cacion de la parte derecha de una comparacion difusa segun el comparador
difuso empleado.

5.2. SINTAXIS Y SEMANTICA DEL LENGUAJE FSQL 173
A B
1


0
A A A B A B B B

1-B FGT A
1
1

1-B

0
A A A B A B B B

Figura 5.12: Representacion gra ca de la comparacion B NFGT A, donde su grado de compa-


tibilidad es 1 ".

En la Figura 5.10 obtenemos que: = 0 ; CDEG(A NFGT B) = 0 ;


CDEG(A FGT B)
= 1 ; CDEG(B NFGT A) = 1 " ;
CDEG(B FGT A)
En la Figura 5.12 hay un ejemplo gra co de la comparacion de necesidad B NFGT A.
Observese como se niega la distribucion B y se modi ca la distribucion A segun el
comparador empleado.

 Comparadores Difusos FGEQ/NFGEQ (possibly/Necessarily Fuzzy Greater or


EQual Than, Posiblemente/Necesariamente Mayor o Igual Difuso):
81 si A  B
< A B
CDEG(A FGEQ B) = si A < B y A > B (5.11)
: 0( B B ) ( A A )
en otro caso (A  B )

81 si A  B
< A B
CDEG(A NFGEQ B) =
: 0( B B ) ( A A ) si A < B y A > B (5.12)
en otro caso ( A  B )

En la Figura 5.10 obtenemos que: CDEG(A FGEQ B) ="; CDEG(A NFGEQ B) =0;
CDEG(B FGEQ A) =1; CDEG(B NFGEQ A) =1;
174 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
 Comparadores Difusos FLT/NFLT (possibly/Necessarily Fuzzy Less Than, Po-
siblemente/Necesariamente Menor Difuso):
81 si A  B
< A B
CDEG(A FLT B) =
: 0( B B ) ( A A ) si A > B y A < B (5.13)
en otro caso ( A  B )
81 si A  B
< A B
CDEG(A NFLT B) =
: 0( B B ) (A A ) si A > B y A < B (5.14)
en otro caso ( A  B )
En la Figura 5.10 obtenemos que: CDEG(A FLT B) =1; CDEG(A NFLT B) =1 ";
CDEG(B FLT A) =0; CDEG(B NFLT A) =0;
 Comparadores Difusos FLEQ/NFLEQ (possibly/Necessarily Fuzzy Less or EQual
Than, Posiblemente/Necesariamente Menor o Igual Difuso):
81 si A  B
< B A
CDEG(A FLEQ B) = si A > B y A < B (5.15)
: 0( A A ) ( B B )
en otro caso ( A  B )
81 si A  B
< A B
CDEG(A NFLEQ B) =
: 0( B B ) (A A ) si A > B y A < B (5.16)
en otro caso ( A  B )
En la Figura 5.10 obtenemos que: = 1 ; CDEG(A NFLEQ B) = 1 ;
CDEG(A FLEQ B)
= " ; CDEG(B NFLEQ A) = 0 ;
CDEG(B FLEQ A)

En los comparadores que usan la expresion \Mucho" (mucho mayor/menor que), se usa
la distancia M (almacenada en el atributo MUCH de la tabla FUZZY APPROX MUCH de la FMB).
Tambien con estos comparadores se modi ca la distribucion de la parte derecha de la compa-
racion, tal y como se muestra en la Figura 5.13 (donde M=M ).
 Comparadores Difusos MGT/NMGT (possibly/Necessarily Much Greater Than,
Posiblemente/Necesariamente Mucho Mayor difuso): Como ya hemos indicado,
en la FMB se almacena un valor para cada atributo difuso Tipo 1 o 2 que indica
la distancia mnima para que 2 valores de ese atributo sean considerados como muy
separados (atributo MUCH de la tabla FUZZY APPROX MUCH). Sea M esta distancia, para
un atributo con dos valores cualesquiera A y B. Entonces, para obtener el grado de
compatibilidad con el que A es posiblemente/necesariamente mucho mayor que B, se
utilizan las siguientes ecuaciones:
81 si A  B + M
< +M 
CDEG(A MGT B) =
: 0(  ) ( )
A
B
A B
A
B
si A < B + M y A > B + M (5.17)
en otro caso (A  B + M)

5.2. SINTAXIS Y SEMANTICA DEL LENGUAJE FSQL 175

A
1

0
A A A A

MGT A
1

0
A A A A A+ M A+ M
M
MLT A
1

0
A- M A- M A A A A
M

Figura 5.13: Modi cacion de la parte derecha de una comparacion difusa segun el comparador
difuso \Mucho Mayor/Menor que" empleado.
176 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
81 si A  B + M
< +M
CDEG(A NMGT B) =
: 0( ) ( )
A
B
A B
A
B
si A < B + M y A > B + M (5.18)
en otro caso ( A  B + M)
Ademas de las distribuciones de la Figura 5.10, supondremos otra distribucion de po-
sibilidad A'=A M= $[ A M, A M, A M,A M]. Si comparamos con los
comparadores MGT/NMGT estas 3 distribuciones de posibilidad de ejemplo, se obtiene que:
CDEG(A MGT B) = 0 ; CDEG(A NMGT B) = 0 ;
CDEG(B MGT A) = 0 ; CDEG(B NMGT A) = 0 ;
CDEG(A MGT A') = 0 ; CDEG(A NMGT A) = 0 ;
CDEG(A' MGT A) = 0 ; CDEG(A' NMGT A) = 0 ;
CDEG(A' MGT B) = 0 ; CDEG(A' NMGT B) = 0 ;
CDEG(B MGT A') = 1 ; CDEG(B NMGT A') = 1 ";

 Comparadores Difusos MLT/NMLT (possibly/Necessarily Much Less Than, Po-


siblemente/Necesariamente Mucho Menor difuso):
81 si A  B M
< M
CDEG(A MLT B) =
: 0( ) ( )
A
B
A B
A
B
si A > B M y A < B M (5.19)
en otro caso ( A  B M)
81 si A  B M
< B M A
CDEG(A NMLT B) =
: 0( A A ) ( B B )
si A > B M y A < B M (5.20)
en otro caso ( A  B M)
En el caso de la Figura 5.10, y con la distribucion A' de nida anteriormente, se obtiene
que:
CDEG(A MLT B) = 0 ; CDEG(A NMLT B) = 0 ;
CDEG(B MLT A) = 0 ; CDEG(B NMLT A) = 0 ;
CDEG(A MLT A') = 0 ; CDEG(A NMLT A) = 0 ;
CDEG(A' MLT A) = 0 ; CDEG(A' NMLT A) = 0 ;
CDEG(A' MLT B) = 1 ; CDEG(A' NMLT B) = 1 ";
CDEG(B MLT A') = 1 ; CDEG(B NMLT A') = 0 ;

5.2.1.5 Equivalencias entre Comparadores Difusos y Excepciones a sus De ni-


ciones
De las de niciones de todos estos comparadores difusos podemos obtener que hay comparado-
res difusos que son equivalentes entre s con solo intercambiar de orden los valores comparados,
i.e., consiguen igual grado de cumplimiento. Por ejemplo, en modo crisp se cumple que la
comparacion A>B es equivalente a la comparacion B<A.
Los comparadores difusos de nidos anteriormente muestran las siguientes equivalencias:

5.2. SINTAXIS Y SEMANTICA DEL LENGUAJE FSQL 177

A FEQ B  B FEQ A (5.21)


A FGT B  B NFLEQ A (5.22)
A FLT B  B NFGEQ A (5.23)
A FGEQ B  B FLEQ A (5.24)
A NFGT B  B NFLT A (5.25)
A NMGT B  B NMLT A (5.26)
De la ecuacion 5.21 obtenemos que el comparador FEQ cumple la propiedad conmutativa.
De hecho, es el unico comparador difuso que cumple tal propiedad.
Estas equivalencias se cumplen siempre, por de nicion. Sin embargo, el Servidor FSQL
incorpora unas excepciones en aras de la claridad. Estas excepciones se producen cuan-
do se compara, utilizando un comparador de necesidad, un valor con una constante difusa
UNKNOWN, UNDEFINED o NULL. En esos casos se devuelve siempre un grado de compa-
tibilidad 0 (cero), aunque en algunas comparaciones determinadas el valor a devolver debera
ser 1.
Ejemplo 5.7 En las comparaciones siguientes, el grado de compatibilidad entre ambas cons-
tantes es 1, siguiendo la de nicion de comparador difuso empleado:
UNDEFINED NFEQ #8
$[1,2,3,4] NFEQ UNKNOWN
[100,200] NFLT UNKNOWN
8 NFGT NULL

Sin embargo, el Servidor FSQL devuelve 0 (cero) como grado de compatibilidad de esas
comparaciones, que es el valor que uno espera obtener. Por ejemplo, en el segundo caso, uno
espera obtener un valor nulo cuando estudia la necesidad de que cualquier valor difuso sea
UNKNOWN (desconocido). tu
Estas excepciones hacen que se devuelva el valor que intuitivamente uno espera obtener.
Ademas, al usar un comparador de necesidad se esta indicando claramente que se desean
recuperar pocas e interesantes tuplas, por lo que no parece logico que se recuperaran tuplas
con valores como UNKNOWN en el atributo utilizado en la seleccion. Por otra parte, si se
desea obtener todas aquellas tuplas que posiblemente cumplen la condicion de la seleccion se
debe entonces utilizar un comparador de posibilidad y no de necesidad.
Si en la base de datos difusa hay almacenada una etiqueta que no esta de nida en la
tabla FUZZY OBJECT LIST de la FMB, entonces la comparacion devolvera el valor NULL (en
el sentido del SGBD) y por tanto, la condicion sera evaluada como \falsa" para esa tupla.
Aparentemente, otra posible inconsistencia es que el tipo del valor difuso que se almacena
no sea correcto, i.e., no esta entre 0 y 7 para atributos difusos Tipo 2 o no esta entre 0 y
4 para atributos difusos Tipo 3. Sin embargo, este error no debera producirse nunca pues
al declarar la tabla con CREATE TABLE se debera incorporar una restriccion que chequeara
(CHECK) esa condicion e impidiera la insercion de valores incorrectos, tal y como se de ne en
el apartado 5.2.2.
178 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
Familia Comparadores difusos, de mayor a menor restrictividad
Igual difuso NFEQ > FEQ
Mayor difuso NFGT > FGT > NFGEQ > FGEQ
Menor difuso NFLT > FLT > NFLEQ > FLEQ
Mucho Mayor difuso NMGT > MGT
Mucho Menor difuso NMLT > MLT
Tabla 5.15: Restrictividad de los comparadores difusos por familias.

5.2.1.6 Restrictividad de los Comparadores Difusos


Hay comparadores cuyos resultados de comparacion incluyen unos a otros. Por ejemplo, en
modo crisp, el resultado del comparador \>=" incluye al de \>". Decimos entonces que
el comparador \>" es mas restrictivo que \>=". O sea, los comparadores mas restrictivos
recuperaran menor o igual cantidad de tuplas y las tuplas recuperadas nunca tendran un
grado de cumplimiento mayor que con los comparadores menos restrictivos.
En la Tabla 5.15 se puede ver el orden de restrictividad de los comparadores difusos, por
familias. Observe que cualquier comparador de necesidad es mas restrictivo que su corres-
pondiente comparador de posibilidad.
5.2.1.7 De nicion del Comparador Difuso FEQ para Atributos Difusos Tipo 3
Como ya hemos indicado, para atributos difusos Tipo 3 solo esta permitido usar el compa-
rador difuso FEQ, ya que no existe una relacion de orden en el dominio de estos atributos.
Por ejemplo, no podemos decir si el valor \Rubio" es mayor que el valor \Moreno", pero si
podemos medir su similitud. As, cuando comparamos dos valores de tipo simple entre s, el
valor devuelto es el valor almacenado en su relacion de similitud (tabla FUZZY NEARNESS DEF)
suponiendo que ambos valores esten normalizados, i.e., tengan grado de posibilidad 1.
Lo normal (y deseable) es que tanto los valores simples como las distribuciones de posi-
bilidad sobre atributos difusos Tipo 3 esten normalizadas, i.e., tengan grado de posibilidad 1
al menos en alguna componente. Sin embargo, si eso no ocurriera el Servidor FSQL lo tiene
en cuenta en la comparacion.
Supongamos que deseamos comparar dos distribuciones de posibilidad cualesquiera, F y
X, sobre las etiquetas ling
usticas de un atributo difuso Tipo 3:

F FEQ X (5.27)
donde

F= fFPi =labelFi g con i = 1; 2 : : : LENF (5.28)


X = fXPj =labelXj g con j = 1; 2 : : : LENX (5.29)
siendo labelFi y labelXj etiquetas lingusticas que pertenecen al mismo atributo y por tanto
se pueden comparar con su relacion de similitud. Los valores FPi y XPj son los grados de
posibilidad, en [0,1], asociados a dichas etiquetas respectivamente. LENF y LENX indican el

5.2. SINTAXIS Y SEMANTICA DEL LENGUAJE FSQL 179

numero de parejas fgrado,etiquetag de las distribuciones de posibilidad F y X respectivamente,


con LENF  1 y LENX  1.
Entonces, el grado de compatibilidad entre F y X, o, lo que es lo mismo, el grado de
cumplimiento de la condicion de la ecuacion 5.27, viene dado por:

CDEG(F FEQ X) = i=1:::LENmax


F ;j =1:::LENX
f(labelFi; labelXj )  FPi  XPj g (5.30)
donde (labelFi ; labelXj ) expresa el grado de similitud entre ambas etiquetas, el cual debe
estar almacenado en la tabla FUZZY NEARNESS DEF de la FMB.
La ecuacion anterior se simpli ca si la comparacion es efectuada directamente sobre una
etiqueta ($label=labelX1 que se supone con posibilidad XP1 =1):

CDEG(F FEQ $label) = i=1max


:::LENF
f(labelFi; label)  FPi g (5.31)
Si para una pareja de etiquetas no esta de nido su grado de similitud en la FMB, este se
supone que es cero.
5.2.1.8 Tipos de Condiciones Difusas Elementales, Con y Sin Expresiones Aritmeticas
Por todo lo visto, podemos concluir que existen 8 tipos basicos de comparaciones o condicio-
nes difusas elementales (sin expresiones aritmeticas externas). Estas condiciones pueden ser
enlazadas con otras condiciones (difusas o no) mediante los operadores logicos (NOT, AND y
OR) para formar condiciones difusas m as complejas.
Sean <fcol> y <fcol2> dos atributos difusos expresados con el formato de SQL (con su
esquema y tabla o no) y <fcomp> un comparador difuso de los de nidos en la Tabla 5.12.
Entonces, los 8 tipos basicos de condiciones difusas son los siguientes:
1. Comparacion de un atributo difuso Tipo 1 o 2 con una distribucion de posibilidad
constante de tipo aproximado #n (como la Figura 5.4):
<fcol> <fcomp> #n

2. Comparacion de un atributo difuso Tipo 1 o 2 con una distribucion de posibilidad


constante de tipo intervalo [n,m] (como la Figura 5.5):
<fcol> <fcomp> [n,m]

3. Comparacion de un atributo difuso Tipo 1 o 2 con una distribucion de posibilidad


constante de tipo trapecio $[ , , ,] (como la Figura 5.2):
<fcol> <fcomp> 
$[ , , , ]

4. Comparacion de un atributo difuso de cualquier Tipo (1, 2 o 3) con una distribucion de


posibilidad constante de tipo etiqueta lingustica $label (de nida en la FMB):
180 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
<fcol> <fcomp> $label

5. Comparacion de un atributo difuso Tipo 1 o 2 con una expresion constante de tipo crisp
<expr crisp>:

<fcol> <fcomp> <expr crisp>

En la expresion crisp tambien puede incluirse una columna crisp o difusa Tipo 1 de
cualquier tabla. Ver Ejemplo 5.8 expuesto a continuacion.
6. Comparacion de un atributo difuso de cualquier Tipo con otro que sea compatible con
el primero:
<fcol> <fcomp> <fcol2>

La unica incompatibilidad que existe entre atributos difusos esta entre atributos de Tipo
3 con atributos de otro tipo y con otros atributos de Tipo 3 que no sean declarados
explcitamente como compatibles en la tabla FUZZY COMPATIBLE COL.
Si el atributo de la derecha es difuso Tipo 2 o 3 y tras este aparecen operaciones
aritmeticas, estas seran consideradas como externas a la comparacion difusa. Ver Ejem-
plos 5.9 y 5.10 expuestos a continuacion.
7. Comparacion de un atributo difuso con una constante difusa sin argumentos variables
usando el comparador difuso FEQ:
8 UNKNOWN
<
< fcol > FEQ
: UNDEFINED
NULL

En este tipo de comparacion no puede emplearse otro comparador difuso distinto de


FEQ y la columna <fcol> no puede ser difusa Tipo 1.

8. Comparacion de un atributo difuso con una constante difusa sin argumentos variables
usando la comparacion con IS (con o sin NOT):
8 UNKNOWN
<
< fcol > IS [NOT]
: UNDEFINED
NULL

Si la columna <fcol> es difusa Tipo 1 solo puede usarse la constante NULL, que tendra
el sentido que le da el SGBD y no es el NULL difuso.
A todas estas condiciones difusas, menos a la ultima, se le pueden poner un umbral de
cumplimiento, de forma que la condicion establecida solo sera valida si su grado de cumpli-
miento supera dicho umbral.
Las comparaciones difusas (excepto IS) pueden ir precedidas o sucedidas por expresiones
aritmeticas que operan con la comparacion difusa, de forma que estas son consideradas como
externas a la comparacion difusa. El Servidor FSQL limita las expresiones aritmeticas despues
de la comparacion difusa de forma que estas solo pueden aparecer:

5.2. SINTAXIS Y SEMANTICA DEL LENGUAJE FSQL 181

1. Cuando queremos comparar una expresion crisp (caso 5): Entonces, toda la expresion
debe ser crisp y situada a la derecha del comparador difuso. La comparacion difusa se
efectuara sobre toda la expresion. A la izquierda debe haber, logicamente, un atributo
difuso Tipo 1 o 2.
2. Cuando justo tras el comparador aparece un atributo difuso Tipo 2 o 3: Entonces,
las expresiones aritmeticas que sucedan a ese atributo difuso seran consideradas como
externas a la comparacion, ya que el Servidor FSQL no admite operaciones aritmeticas
sobre atributos difusos Tipo 2 o 3.
Si aparece un atributo difuso Tipo 2 o 3 en una expresion aritmetica tras el comparador,
pero este atributo no esta justo despues del comparador, entonces el tratamiento para
este atributo puede ser con gurado por el usuario, tal y como se explica en el apartado
5.4.1.
A continuacion exponemos una serie de ejemplos que muestran la gran variedad de tipos
de comparaciones difusas con expresiones aritmeticas que pueden efectuarse.
Ejemplo 5.8 La siguiente comparacion difusa con expresiones aritmeticas:
0.5 * Sueldo FGT SQRT(Comision)+3/4 THOLD 0.25

expresa que el grado de compatibilidad con el que el atributo Sueldo (que suponemos Tipo
1 o 2) es \posiblemente mayor" que la expresion crisp que le sigue (donde Comision es un
atributo numerico crisp o difuso Tipo 1), multiplicado por 0.5 debe ser mayor o igual que
el umbral 0.25. Si llamamos a ese grado de compatibilidad entonces, la comparacion es
equivalente a:

(0:5  )  0:25
Observe que la expresion crisp tras FGT es considerada como un unico valor crisp que es
comparado con Sueldo. Por tanto, las variaciones en el valor de Comision in uiran en el
valor de . tu
Ejemplo 5.9 Siguiendo el ejemplo anterior y suponiendo que Sueldo es un atributo difuso
Tipo 2 y Tasa es Tipo 1, la siguiente comparacion difusa es correcta:
0.5 * Tasa NFLT Sueldo-5*SQRT(Tasa) THOLD 0.25

La expresion aritmetica tras Sueldo es considerada como externa, ya que Sueldo es de


Tipo 2. Si fuera de Tipo 1 sera considerada como un unico valor crisp (como en el ejemplo
anterior). Si llamamos al grado de compatibilidad con el que Tasa es \necesariamente
menor difuso que" Sueldo, entonces, la comparacion es equivalente a:
p
(0:5  5  Comision)  0:25
Observe que tanto las expresiones aritmeticas anteriores como posteriores a la comparacion
difusa son consideradas como externas a ella y, por tanto, las variaciones en el valor de Tasa
no in uyen ahora en el valor de . tu
182 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
Ejemplo 5.10 De igual forma que en el ejemplo anterior, si utilizamos atributos difusos Tipo
3 de distintas tablas, Profesion, tambien es correcta la siguiente comparacion difusa:
0.5 * Empleado.Profesion FEQ Personas.Profesi
on-5*SQRT(Comision) THOLD 0.25

Si llamamos al grado de compatibilidad con el que el valor de Profesion de la tabla


Empleado es similar al valor de Profesion de la tabla Personas, entonces, la comparaci
on es
equivalente a:
p
(0:5  5 Comision)  0:25
Observe que tanto las expresiones aritmeticas anteriores como posteriores a la comparacion
difusa son consideradas como externas a ella. tu
Ejemplo 5.11 La siguiente comparacion difusa con expresiones aritmeticas:
0.5 * Sueldo FGT #5 THOLD 0.25

expresa que el grado de compatibilidad con el que el atributo Sueldo (que suponemos Tipo
1 o 2) es \posiblemente mayor" que \aproximadamente 5", multiplicado por 0.5 debe ser
mayor o igual que el umbral 0.25. Si llamamos a ese grado de compatibilidad entonces, la
comparacion es equivalente a:

(0:5  )  0:25
Tras la constante #5 no se pueden a~nadir operaciones aritmeticas9 , igual que si se utiliza
un trapecio, una etiqueta o cualquier otra constante difusa. tu
Ejemplo 5.12 La comparacion difusa puede ser mas elaborada que en el ejemplo anterior:
Plus - 0.50 + 0.35 * SQRT(Estado) * Sueldo NFGEQ $[2,3,4,5] = 35

donde Estado y Plus las suponemos como columnas crisp (o difusas Tipo 1). Observese que
hemos cambiado la palabra reservada THOLD por el comparador crisp =. Entonces, la condicion
equivalente sera
p
(Plus 0:5 + 0:35  Estado  ) = 35
donde aqu es el grado con el que el Sueldo es \necesariamente mayor o igual" que el
trapecio $[2,3,4,5].
El signi cado de esta condicion es que tiene que ser igual a 35 el resultado de multiplicar
, 0.35 y la raz cuadrada del Estado y despues sumarle el valor de Plus y restarle 0.5. tu
9 Esta
limitacion podra ser subsanada en posteriores versiones del Servidor FSQL. Para ello, habra que
modi car la gramatica para que admita ese tipo de expresiones.

5.2. SINTAXIS Y SEMANTICA DEL LENGUAJE FSQL 183

5.2.1.9 Comparacion de Valores Crisp Usando Comparadores Difusos


Observese que FSQL permite comparar, usando comparadores difusos, dos atributos difusos
Tipo 1 (crisp) o un atributo difuso Tipo 1 con una expresion de tipo crisp (incluyendo ah
atributos no difusos). Esto podra considerarse como erroneo, pues desde cierto punto de
vista no tiene sentido comparar difusamente dos valores crisp, debiendose entonces utilizar
los comparadores crisp clasicos.
Sin embargo, FSQL permite este tipo de comparacion, dandole un matiz que puede resultar
muy util y que no se consigue utilizando comparadores crisp clasicos.
As, cuando comparamos un atributo difuso Tipo 1 con un valor crisp mediante un com-
parador difuso, lo que se hace es difuminar el valor situado a la derecha de la comparacion,
convirtiendolo a un valor aproximado, del tipo de la Figura 5.4, utilizando el margen pa-
ra valores aproximados del atributo situado a la izquierda de la comparacion. Por eso, es
obligatorio que a la izquierda del comparador difuso exista siempre un atributo difuso.
Si en la comparacion difusa no se desea que se difumine el valor de la derecha entonces,
se debe utilizar un comparador crisp clasico y no un comparador difuso.
Ejemplo 5.13 Por ejemplo, si <fcol_t1> es un atributo difuso Tipo 1, las siguientes dos
comparaciones difusas son equivalentes:
<fcol t1> FGT 6
<fcol t1> FGT #6

En el primer caso se difumina implcitamente el 6 y en el segundo explcitamente. Si no se


desea difuminar usar el comparador crisp > en el primer caso. tu
Igualmente, cuando se compara un atributo difuso Tipo 1 con un intervalo [n,m] (Figura
5.5), utilizando un comparador difuso, tambien se difumina el intervalo convirtiendose en el
trapecio $[n-margen,n,m,m+margen] (Figura 5.2). Si no se desea que se difumine se debe
emplear un comparador crisp, como en BETWEEN n AND m, o varios (>= y <=).
Con los comparadores del tipo \Mucho Mayor/Menor que", MGT/NMGT y MLT/NMLT, se
difumina ademas el valor crisp situado a la izquierda de la comparacion tambien a un valor
aproximado con el mismo margen. Esto se hace as porque estos comparadores son difusos
\per se ", es decir el cuanti cador \Mucho" incluye un matiz difuso extra que no tienen los
demas comparadores. O sea, estos comparadores no proceden de difuminar comparadores
clasicos ya existentes, sino que son difusos por s mismos, sin que exista una version clasica
para ellos.
Por eso, al difuminar ambos valores en estos comparadores conseguimos que la compa-
racion sea mas gradual, i.e., valores que obtendran grado cero si no se hiciera as, ahora
obtienen un grado que estara en el intervalo (0,0.5]. El valor 0.5 se debe a que el difuminado
de ambos valores se hace con el mismo margen, con lo que la inclinacion de los lados del
triangulo posibilstico es la misma en ambos casos.
5.2.1.10 Ejemplos de Consultas en FSQL
Con los siguientes ejemplos intentamos mostrar la potencia del comando SELECT con su ex-
tension difusa de FSQL.
Supongamos que tenemos una base de datos Relacional Difusa sobre jugadores de balon-
cesto. Una relacion de la base de datos podra ser la relacion Jugadores de la Tabla 5.16.
184 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
H Jugador Equipo Altura Calidad
B P1 Cordoba Bajo $[30,38,40,45]
P2 Cordoba Muy Alto $[2,7,10,15]
P3 Granada Normal Regular
P4 Granada 192 Regular
P5 Granada Alto #10
P6 Malaga 198 Malo
P7 Malaga Muy Alto #35
P8 Malaga 170 $[31,34,35,38]
P9 Sevilla Bajo #15
P10 Sevilla Normal Bueno
P11 Cadiz Muy Alto #25
P12 Cadiz Bajo Muy Bueno
P13 Almera Alto Muy Bueno
P14 Almera Muy Alto #8
P15 Almera 177 #6
P16 Huelva Alto Muy Bueno
P17 Huelva Unknown Unknown
P18 Jaen Unknown $[8,12,15,25]
P19 Jaen Normal #25

Tabla 5.16: Relacion difusa Jugadores.

Los campos Altura (que almacena la altura del jugador) y Calidad (que mide la calidad
del jugador segun el numero de puntos medio por partido), son atributos difusos Tipo 2.
Nosotros, para el ejemplo, usaremos las etiquetas lingusticas de la Figura 5.14.
Ademas, sabemos que en la FMB esta almacenado el valor 10 para el margen de los valores
aproximados del atributo Calidad (atributo MARGEN de la tabla FUZZY APPROX MUCH). Eso
indica que el valor \aproximadamente n" (#n) expresa la distribucion de posibilidad triangular
expresada por n10 (trapecio $[n{10,n,n,n+10]). La distancia mnima para considerar dos
valores muy separados (atributo MUCH de la tabla FUZZY APPROX MUCH) es 12 para el atributo
Altura y 15 para el atributo Calidad.
Por supuesto, la relacion Jugadores puede incluir valores \Unknown" en el caso de que
desconozcamos totalmente la Altura o la Calidad de un jugador. En este contexto no tienen
sentido los valores \Unde ned" o \Null".
Ejemplo 5.14 Dame todos los datos de los jugadores que son posiblemente altos (en grado
mnimo 0.5) y que tienen una calidad posiblemente menor que buena (en grado mnimo 0.25).
Recuperar los grados de compatibilidad de ambos atributos independientemente y el asociado
a la condicion completa. La consulta FSQL y el resultado obtenido se muestran en la Tabla
5.17.
Si subimos el umbral mnimo del atributo Calidad a 0.5 el resultado es el mismo pero sin
recuperar las tuplas de los jugadores P11 ni P19. tu
Ejemplo 5.15 Modi car los comparadores empleados en el Ejemplo 5.14 anterior para recu-
perar aquellos jugadores que cumplen con la condicion impuesta \necesariamente". Es decir,

5.2. SINTAXIS Y SEMANTICA DEL LENGUAJE FSQL 185

ALTURA
Bajo Normal Alto Muy Alto
1

0.5

0
170 175 180 185 190 195 200 205 210 cm.

CALIDAD
Malo Regular Bueno Muy Bueno
1

0.75

0.5

0
5 10 15 20 25 30 35 40 45 Puntos/Partido

Figura 5.14: De nicion de etiquetas sobre los atributos Altura y Calidad.

SELECT Jugadores.%, CDEG(*) FROM Jugadores


WHERE Altura FEQ $Alto THOLD 0.5 AND
Calidad FLT $Bueno THOLD 0.25;
H Jugador Equipo Altura Calidad CDEG(Altura) CDEG(Calidad) CDEG(*)
B P2 Cordoba Muy Alto $[2,7,10,15] 0.50 1.00 0.50
P3 Granada Normal Regular 0.50 1.00 0.50
P4 Granada 192 Regular 0.70 1.00 0.70
P5 Granada Alto #10 1.00 1.00 1.00
P6 Malaga 198 Malo 1.00 1.00 1.00
P7 Malaga Muy Alto #35 0.50 1.00 0.50
P10 Sevilla Normal Bueno 0.50 0.50 0.50
P11 Cadiz Muy Alto #25 0.50 0.25 0.25
P14 Almera Muy Alto #8 0.50 1.00 0.50
P17 Huelva Unknown Unknown 1.00 1.00 1.00
P18 Jaen Unknown $[8,12,15,25] 1.00 0.86 0.86
P19 Jaen Normal #25 0.50 0.25 0.25
Tabla 5.17: Consulta FSQL y relacion resultante del Ejemplo 5.14.
186 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
SELECT Jugadores.%, CDEG(*) FROM Jugadores
WHERE Altura NFEQ $Alto THOLD 0.5 AND
Calidad NFLT $Bueno THOLD 0.25;
H Jugador Equipo Altura Calidad CDEG(Altura) CDEG(Calidad) CDEG(*)
B P4 Granada 192 Regular 0.70 0.33 0.33
P5 Granada Alto #10 0.50 0.50 0.50
P6 Malaga 198 Malo 1.00 1.00 1.00
Tabla 5.18: Consulta FSQL y relacion resultante del Ejemplo 5.15.

SELECT Jugadores.%, CDEG(*) FROM Jugadores


WHERE Altura FEQ $Alto THOLD 0.5 AND
Calidad NFLT $Bueno THOLD 0.25;
H Jugador Equipo Altura Calidad CDEG(Altura) CDEG(Calidad) CDEG(*)
B P2 Cordoba Muy Alto $[2,7,10,15] 0.50 0.67 0.50
P3 Granada Normal Regular 0.50 0.33 0.33
P4 Granada 192 Regular 0.70 0.33 0.33
P5 Granada Alto #10 1.00 0.50 0.50
P6 Malaga 198 Malo 1.00 1.00 1.00
P14 Almera Muy Alto #8 0.50 0.60 0.50
P18 Jaen Unknown $[8,12,15,25] 1.00 0.25 0.25
Tabla 5.19: Consulta FSQL y relacion resultante del Ejemplo 5.16.

modi car los comparadores de posibilidad por sus correspondientes comparadores de necesi-
dad. La consulta FSQL y el resultado obtenido se muestran en la Tabla 5.18. tu

Ejemplo 5.16 Modi car los comparadores empleados en el Ejemplo 5.14 para recuperar
aquellos jugadores que cumplen con la condicion impuesta sobre el atributo Calidad \nece-
sariamente". Es decir, modi car el comparador de posibilidad FLT por su correspondiente
comparador de necesidad NFLT. La consulta FSQL y el resultado obtenido se muestran en la
Tabla 5.19. tu
Observe como en el Ejemplo 5.16 se recuperan mas tuplas que en el Ejemplo 5.15 y
menos que en el Ejemplo 5.14. Ello es debido a la restrictividad de los comparadores difusos
(apartado 5.2.1.6).
Ejemplo 5.17 Dame todos los datos de los jugadores que son posiblemente Malos (en grado
mnimo 0.75) y tambien aquellos que siendo posiblemente Buenos (en grado mnimo 0.75) son
posiblemente Bajos (en grado mnimo 0.75). La consulta FSQL y la relacion resultante se
muestra en la Tabla 5.20. tu

Ejemplo 5.18 Dame todos los datos de los jugadores que son Malos en Calidad y tambien
aquellos que siendo peores o iguales que Buenos en Calidad son mayores o iguales que Altos

5.2. SINTAXIS Y SEMANTICA DEL LENGUAJE FSQL 187

SELECT Jugadores.%, CDEG(*) FROM Jugadores


WHERE Calidad FEQ $Malo 0.75 OR
( Calidad FEQ $Bueno 0.75 AND
Altura FEQ $Bajo 0.75 );
H Jugador Equipo Altura Calidad CDEG(Altura) CDEG(Calidad) CDEG(*)
B P2 Cordoba Muy Alto $[2,7,10,15] 0.00 0.80 0.80
P6 Malaga 198 Malo 0.00 1.00 1.00
P8 Malaga 170 $[31,34,35,38] 1.00 0.78 0.78
P9 Sevilla Bajo #15 1.00 0.75 0.75
P12 Cadiz Bajo Muy Bueno 1.00 0.75 0.75
P14 Almera Muy Alto #8 0.00 0.80 0.80
P15 Almera 177 #6 0.60 0.93 0.93
P17 Huelva Unknown Unknown 1.00 1.00 1.00
P18 Jaen Unknown $[8,12,15,25] 1.00 0.75 0.75
Tabla 5.20: Consulta FSQL y relacion resultante del Ejemplo 5.17.

en Altura. Utilizar solo comparadores de necesidad y establecer que los grados de de cum-
plimiento de todas las condiciones simples sean mayor que 0. La consulta FSQL y la relacion
resultante se muestra en la Tabla 5.21.
Observe como hemos puesto el comparador > antes del umbral cero. Con esto indicamos
que el grado de cumplimiento debe ser estrictamente mayor que cero, i.e., distinto de cero.
Por defecto (sin ese comparador), el grado de cumplimiento tendra que ser mayor o igual
que cero. tu
Ejemplo 5.19 Dame todos los datos de los jugadores que son posiblemente mucho peores
que Buenos (en grado mnimo 0.2) y posiblemente mucho mas altos que una altura Normal
(en grado mnimo 0.2). Evitar los valores Unknown (desconocidos) en la relacion resultante.
La consulta FSQL y la relacion resultante se muestra en la Tabla 5.22.
Recuerde que la distancia mnima para considerar dos valores muy separados (atributo
MUCH de la tabla FUZZY APPROX MUCH) es 12 para el atributo Altura y 15 para el atributo
Calidad. tu
Ejemplo 5.20 Dame todos los datos de los jugadores que son necesariamente mucho peores
que Muy Buenos (en grado mnimo 0.25) y necesariamente mucho mas altos que Bajos (en
grado mnimo 0.25). Evitar los valores Unknown (desconocidos) en la relacion resultante. La
consulta FSQL y la relacion resultante se muestra en la Tabla 5.23. tu
Ejemplo 5.21 Dame los equipos que tienen al menos un jugador que sea Muy Alto y Muy
Bueno y tambien que tenga un jugador que sea Muy Bajo y Muy Malo (con todas las condicio-
nes en grado mnimo 0.5). La consulta FSQL esta en la tabla 5.24 y el resultado esta formado
unicamente por el equipo de Almera y Huelva (este ultimo por sus valores desconocidos). tu
La operacion de division relacional puede efectuarse tambien con FSQL aunque, al no ser
una operacion directamente implementada en SQL, su escritura no es inmediata.
188 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL

SELECT Jugadores.%, CDEG(*) FROM Jugadores


WHERE Calidad NFEQ $Malo > 0 OR
( Calidad NFLEQ $Bueno > 0 AND
Altura NFGEQ $Alto > 0 );
H Jugador Equipo Altura Calidad CDEG(Altura) CDEG(Calidad) CDEG(*)
B P2 Cordoba Muy Alto $[2,7,10,15] 1.00 1.00 1.00
P4 Granada 192 Regular 0.70 1.00 0.70
P5 Granada Alto #10 0.50 1.00 0.50
P6 Malaga 198 Malo 1.00 1.00 1.00
P7 Malaga Muy Alto #35 1.00 0.40 0.40
P11 Cadiz Muy Alto #25 1.00 0.80 0.80
P14 Almera Muy Alto #8 1.00 1.00 1.00
P15 Almera 177 #6 0.00 1.00 0.27
Tabla 5.21: Consulta FSQL y relacion resultante del Ejemplo 5.18.

SELECT Jugadores.%, CDEG(*) FROM Jugadores


WHERE Calidad MLT $Bueno 0.2 AND
Altura MGT $Normal 0.2 AND
Calidad IS NOT Unknown AND
Altura IS NOT Unknown;
H Jugador Equipo Altura Calidad CDEG(Altura) CDEG(Calidad) CDEG(*)
B P2 Cordoba Muy Alto $[2,7,10,15] 1.00 0.20 0.20
P5 Granada Alto #10 0.65 0.25 0.25
P6 Malaga 198 Malo 0.44 0.50 0.44
P14 Almera Muy Alto #8 1.00 0.35 0.35
Tabla 5.22: Consulta FSQL y relacion resultante del Ejemplo 5.19.

SELECT Jugadores.%, CDEG(*) FROM Jugadores


WHERE Calidad NMLT $Muy Bueno 0.25 AND
Altura NMGT $Bajo 0.25 AND
Calidad IS NOT Unknown AND
Altura IS NOT Unknown;
H Jugador Equipo Altura Calidad CDEG(Altura) CDEG(Calidad) CDEG(*)
B P2 Cordoba Muy Alto $[2,7,10,15] 1.00 1.00 1.00
P4 Granada 192 Regular 0.45 0.50 0.45
P5 Granada Alto #10 0.53 0.67 0.53
P6 Malaga 198 Malo 1.00 1.00 1.00
P14 Almera Muy Alto #8 1.00 0.80 0.80
Tabla 5.23: Consulta FSQL y relacion resultante del Ejemplo 5.20.

5.2. SINTAXIS Y SEMANTICA DEL LENGUAJE FSQL 189

SELECT DISTINCT Equipo FROM Jugadores P1


WHERE EXISTS (SELECT * FROM Jugadores P2
WHERE P1.Equipo = P2.Equipo AND
Altura FEQ $Muy_Alto .5 AND
Calidad FEQ $Muy_Bueno .5)
AND
EXISTS (SELECT * FROM Jugadores P2
WHERE P1.Equipo = P2.Equipo AND
Altura FEQ $Bajo .5 AND
Calidad FEQ $Malo .5);

Tabla 5.24: Consulta FSQL para el Ejemplo 5.21.


H Altura Calidad
B Bajo Muy Bueno
Alto Regular
Tabla 5.25: Relacion difusa Buscados.

Ejemplo 5.22 Efectuar la division relacional entre las relaciones difusas Jugadores (Tabla
5.16) y Buscados (Tabla 5.25). La relacion del denominador, Buscados, puede ser vista como
una lista de \tipos" de jugadores y la division relacional es una consulta para obtener los
equipos que incorporan en sus las todos los \tipos" de jugadores de la tabla Buscados.
Supondremos que la comparacion de atributos sera efectuada con un umbral mnimo de
0.5. La consulta FSQL esta en la Tabla 5.26 y el resultado esta formado unicamente por
los equipos de Cordoba, Malaga, Sevilla y Huelva (este ultimo por sus valores desconocidos).
Los valores desconocidos pueden evitarse a~nadiendo condiciones del tipo J2.Altura IS NOT
UNKNOWN.
Puede verse que la division del tipo de este ejemplo es compatible con la division relacional
difusa propuesta en el Captulo 3, es decir, obtienen los mismos resultados si aplicamos a esta
ultima una seleccion con umbral mayor o igual a 0.5. As, si aplicamos la division relacional
difusa propuesta en el Captulo 3 a las relaciones de este ejemplo obtenemos los siguientes
resultados, para los valores con grado mayor que cero:
f0.5/Cordoba, 0.5/Malaga, 0.5/Sevilla, 0.33/Cadiz, 1/Huelva, 0.33/Jaeng
Tomando aquellos equipos con grado mayor o igual a 0.5 obtenemos identicos resultados
que con FSQL. Sin embargo, FSQL tiene el inconveniente de que no permite obtener los
grados de cumplimiento, ya que estos grados son calculados en el SELECT mas interno y no es
posible extraer esos valores y usarlos (para mostrarlos) en el SELECT mas externo.
Con FSQL los grados pueden ser obtenidos a base de efectuar distintas pruebas. As, si
en la consulta de la Tabla 5.26 ponemos el smbolo > delante de los umbrales 0.5, entonces
obtenemos solo los equipos que cumplen con la condicion con un grado estrictamente mayor
190 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL

-- Divisi
on Difusa: PLAYERS / SEARCH
SELECT distinct Equipo FROM Jugadores J1
WHERE NOT EXISTS
(SELECT Buscados.* FROM Buscados
WHERE NOT EXISTS
(SELECT J2.* FROM Jugadores J2
WHERE J2.Equipo=J1.Equipo AND
J2.Altura FEQ Buscados.Altura 0.5 AND
J2.Calidad FEQ Buscados.Calidad 0.5));

Tabla 5.26: Consulta FSQL para el Ejemplo 5.22.

que 0.5. En ese caso obtenemos solo el equipo de Huelva, por lo que podemos deducir que los
equipos de Cordoba, Malaga y Sevilla cumplen la condicion con grado 0.5. tu

5.2.2 El DDL de FSQL: CREATE, ALTER y DROP


El DDL (Data De nition Language) es el conjunto de sentencias necesarias para la creacion
y modi cacion de las estructuras en las que se almacenaran los datos. Ejemplos de sentencias
del DDL SQL son: CREATE (para crear objetos de la base de datos: tablas, vistas...), ALTER
(para modi car objetos), DROP (para borrar objetos), y sentencias para controles de seguridad,
ndices y control del almacenamiento fsico de los datos.
A continuacion vamos a centrarnos en los 3 primeros tipos de sentencias del DDL y
enfocados a cuatro tipos de objetos de la BDRD:
 Objeto TABLE: Tablas difusas (con atributos difusos). El grupo de sentencias formado
por CREATE TABLE, ALTER TABLE y DROP TABLE ya existe en el DDL de SQL estandar.
Aqu, hemos ampliado su sintaxis para que permitan expresar las necesidades de una
BDRD.
 Objeto VIEW: Vistas difusas (con atributos difusos). El grupo de sentencias formado por
CREATE VIEW, ALTER VIEW y DROP VIEW ya existe en el DDL de SQL est andar. Aqu,
hemos ampliado la sintaxis de CREATE VIEW para permitir expresar una vista como una
subconsulta difusa (atributos difusos, condiciones difusas...).
 Objeto LABEL: Etiquetas de atributos difusos Tipos 1 y 2. Estas son asociadas a distri-
buciones de posibilidad trapezoidales. Este objeto es exclusivo de FSQL.
 Objeto NEARNESS: Relaciones de semejanza o similitud. Este objeto implica la de nicion
de etiquetas para atributos difusos Tipo 3 y la relacion de similitud entre ellas. Este
objeto es exclusivo de FSQL.
La gramatica que genera el DDL de FSQL puede verse en el Apendice B. La de nicion de
otras clausulas para otros objetos, como son sinonimos (SYNONYM) e instantaneas (SNAPSHOT),
no la hemos incluido aqu, pues su de nicion es igual a la de SQL o muy similar a ella y/o a
clausulas de las que se incluye su de nicion.

5.2. SINTAXIS Y SEMANTICA DEL LENGUAJE FSQL 191

5.2.2.1 Comandos del DDL de FSQL


El lenguaje FSQL extiende algunos comandos ya existentes en SQL, pero tambien incorpora
otros nuevos. Estas son las modi caciones a los comandos ya existentes y los nuevos comandos:
? CREATE TABLE: Esta es la sentencia que mas novedades incorpora:
{ Tipos de Datos Difusos: Se han a~nadido tres nuevos tipos de datos, uno para
cada Tipo de atributo difuso. Por comodidad en el aprendizaje, cada nuevo tipo
tiene dos nombres. Estos son los tres nuevos tipos y su formato:
1. Atributos difusos Tipo 1: Se escribe con las palabras reservadas CRISP o
FTYPE1 seguido de dos n umeros entre parentesis y separados por una coma,
que indican los valores que tendra el nuevo atributo difuso en las columnas
MARGEN y MUCH de la tabla FUZZY APPROX MUCH. A continuaci on se puede poner
opcionalmente el tipo base del atributo, es decir, el dominio subyacente, sobre
el que tomaran valores los valores crisp que tenga la relacion. Por defecto se
tomara NUMBER como tipo base. Pueden producirse errores semanticos, por
ejemplo si se de ne el tipo base como un tipo difuso.
2. Atributos difusos Tipo 2: Se escribe con las palabras reservadas POSSIBILISTIC
o FTYPE2 seguido de dos numeros entre parentesis y separados por una co-
ma, que indican los valores que tendra el nuevo atributo difuso en la tabla
FUZZY APPROX MUCH. Igual que en los Tipo 1, a continuaci on se puede poner
opcionalmente el tipo base sobre el que tomaran valores las distribuciones de
posibilidad que tenga la relacion. Al crear la tabla de nitiva el campo que
almacena el tipo de valor difuso debe restringirse a valores enteros entre 0 y 7
(con una restriccion de tipo CHECK).
3. Atributos difusos Tipo 3: Se escribe con las palabras reservadas SCALAR o
FTYPE3 seguido opcionalmente de un n umero entre parentesis que indica el
numero de datos maximo para los valores de dicho atributo, es decir el numero
maximo de elementos en las distribuciones de posibilidad sobre escalares (valor
del atributo LEN de la tabla FUZZY COL LIST). Suponemos que no hay mas de
10 datos (y 1 como mnimo y por defecto). Opcionalmente se puede a~nadir a
la de nicion de este tipo de atributos la palabra DOMAIN seguida del nombre
de un atributo (que puede ser de la misma tabla), para indicar que el atributo
que estamos de niendo en la tabla que queremos crear sera compatible con
el atributo que se indica tras DOMAIN y podra, por tanto, tomar sus valores
sin tener que de nirlos de nuevo para este atributo. La clausula DOMAIN hace
que se inserte una la en la tabla FUZZY COMPATIBLE COL. Al crear la tabla
de nitiva el campo que almacena el tipo de valor difuso debe restringirse a
valores enteros entre 0 y 4 (con una restriccion de tipo CHECK).
{ Subconsultas, constantes, condiciones y expresiones difusas: Cuando estos
elementos forman parte de una sentencia CREATE TABLE se permite utilizar sus
variantes difusas, tal y como se expusieron en el apartado 5.2.1. Por ejemplo, para
especi car un valor constante por defecto, tras la palabra reservada DEFAULT puede
situarse cualquier tipo de constante, sea difusa (Tabla 5.14) o no lo sea.
{ Restricciones de columna: A una columna difusa le podemos imponer varias
restricciones especiales, ademas de las ya existentes para atributos clasicos:
192 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
1. NOT NULL: Prohibe el valor NULL (aplicable a Tipos difusos 1, 2 y 3, e incluso
a tipos clasicos).
2. NOT UNDEFINED: Prohibe el valor UNDEFINED (aplicable a Tipos difusos 2 y
3).
3. NOT UNKNOWN: Prohibe el valor UNKNOWN (aplicable a Tipos difusos 2 y 3).
4. NOT LABEL: Prohibe valores del tipo etiqueta, $label (aplicable a Tipos difusos
2 y 3).
5. NOT CRISP: Prohibe valores del tipo crisp (aplicable s olo al Tipo difuso 2).
6. NOT TRAPEZOID: Prohibe valores del tipo trapecio, $[a,b,c,d] (aplicable s olo
al Tipo difuso 2).
7. NOT INTERVAL: Prohibe valores del tipo intervalo, $[n,m] (aplicable s olo al
Tipo difuso 2).
8. NOT APPROX: Prohibe valores del tipo aproximado, #n (aplicable s olo al Tipo
difuso 2).
9. ONLY LABEL: Indica que el atributo difuso al que se aplica s olo puede tomar
valores tipo etiqueta lingustica, de nida en la FMB. Es como prohibir todos
los demas tipos (aplicable a Tipos difusos 2 y 3).
10. ONLY LABEL OR UNKNOWN: Indica que el atributo difuso al que se aplica s olo
puede tomar valores tipo etiqueta lingustica, de nida en la FMB, o el valor
Unknown. Es como prohibir todos los demas tipos (aplicable a Tipos difusos
2 y 3). Esta opcion puede ser muy util, pues el valor Unknown es un valor que
es bastante usual en la practica, no siendo as los valores Unde ned y Null.
11. CHECK (<condici on>): Chequea que los valores de ese atributo cumplen una
determinada condicion, la cual puede ser difusa. Si la condicion es difusa es
solo aplicable a los Tipos difusos (1, 2 y 3) y si la condicion no es difusa se
puede aplicar a cualquier tipo de datos (incluidos los tipos clasicos).
Ejemplo 5.23 El siguiente ejemplo crea una tabla de pisos para una inmobiliaria \di-
fusa" con atributos difusos de todo tipo:
CREATE TABLE PISOS (
PISO# NUMBER(9) NOT NULL PRIMARY KEY,
DUENNO# NUMBER(9) NOT NULL,
DIRECCION VARCHAR2(60),
SUPERFICIE FTYPE1 (15,25) NUMBER(4)
CONSTRAINT NULL_INVALIDO_SUPERFICIE NOT NULL,
PRECIO FTYPE2 (500,3000) NUMBER(6) DEFAULT UNKNOWN
CONSTRAINT NULL_INVALIDO_PRECIO NOT NULL
CONSTRAINT UNDEFINED_INVALIDO_PRECIO NOT UNDEFINED,
ZONA FTYPE3 (3) DEFAULT UNKNOWN
CONSTRAINT NULL_INVALIDO_ZONA NOT NULL
CONSTRAINT UNDEFINED_INVALIDO_ZONA NOT UNDEFINED);

donde el atributo super cie se supone dado en m2 y el tipo base del precio se supone
en miles de pesetas. tu

5.2. SINTAXIS Y SEMANTICA DEL LENGUAJE FSQL 193

? CREATE VIEW: Esta sentencia nos permite crear vistas con subconsultas difusas. El
formato es igual que en SQL pero admitiendo subconsultas difusas (SELECT difuso visto
en el apartado 5.2.1).
Ejemplo 5.24 La siguiente sentencia crea una vista con los datos de los pisos que estan
en el centro con un grado superior a 0.8 y que tienen un precio inferior a Barato con
grado mnimo 0.5:
CREATE VIEW PISOS_CENTRO AS
SELECT PISO#, PRECIO, ZONA, CDEG(ZONA) FROM PISOS
WHERE ZONA FEQ $CENTRO 0.8 AND
PRECIO FLEQ $BARATO 0.5
READ ONLY;

donde el ultimo atributo indica el grado con el que cada piso pertenece a la zona centro.
En la vista ese grado estara comprendido en el intervalo [0.8,1]. tu
? CREATE LABEL: Esta es una nueva sentencia, exclusiva de FSQL, y sirve para habilitar
etiquetas en el dominio de un atributo difuso concreto. Tiene dos formatos posibles:
1. Crear una etiqueta para un atributo difuso Tipo 1 o 2 concreto y asociarle una
distribucion de posibilidad trapezoidal:
CREATE LABEL nombre_label ON [schema.]table.atributo
VALUES alfa,beta,gamma,delta;

donde tras la palabra reservada VALUES se ponen forzosamente los 4 valores numericos
que forman la distribucion de posibilidad asociada a la etiqueta nombre label.
Esta sentencia generara un error si el atributo no es difuso Tipo 1 o 2, o si el
atributo ya tiene de nida una etiqueta con el mismo nombre. En el segundo caso,
se debe usar el comando ALTER LABEL.
2. Copiar todas las etiquetas de nidas para un atributo, atributo2, en otro atributo,
atributo1. Ambos atributos deben ser difusos de Tipos 1  o 2 indistintamente, o
ambos de Tipo 3. Su formato es:
CREATE LABEL * ON [schema.]table.atributo1
FROM [schema.]table.atributo2;

Cuando nos encontramos con atributos difusos Tipo 1 o 2 hay que copiar las
etiquetas de la tabla FUZZY OBJECT LIST y su de nicion de FUZZY LABEL DEF y se
copian todas las que tienen distinto nombre de las ya de nidas en atributo1, sin
borrar las que este tuviera anteriormente (ver Ejemplo F.17). Se generara un error
si atributo2 no tiene de nida ninguna etiqueta.
En atributos difusos Tipo 3 en realidad no copia las etiquetas de uno a otro,
sino que establece que ambos atributos son compatibles (insertando una la en
FUZZY COMPATIBLE COL). El efecto es el mismo que si aplicamos la cl ausula DOMAIN
en la sentencia CREATE TABLE que crea la tabla que contiene al atributo en cuestion.
Se generara un error si atributo1 tiene ya una relacion de similitud asociada a el.
194 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
Ejemplo 5.25 Crear una etiqueta llamada BARATO sobre el atributo PRECIO de la tabla
PISOS:

CREATE LABEL BARATO ON PISOS.PRECIO VALUES 5000,6000,7000,8000;

donde la distribucion de posibilidad asociada sera $[5000,6000,7000,8000]. tu

? CREATE NEARNESS: Esta es una nueva sentencia, exclusiva de FSQL, y sirve para crear
etiquetas para los atributos difusos Tipo 3. Con esta sentencia se deben de nir todas las
etiquetas que van a pertenecer al atributo y con ellas se va a de nir tambien la relacion
de similitud, es decir, el grado de similitud entre cada 2 etiquetas. Su formato es:

CREATE NEARNESS ON [schema.]table.atributo


LABEL lista_de_etiquetas
VALUES lista_de_similitudes;

donde lista de etiquetas es una lista de las etiquetas que vamos a de nir separadas
por comas y lista de similitudes es la lista de grados de similitud entre cada 2
etiquetas. El orden en que se escriben las etiquetas in uye en el orden en el que se
escribiran los grados de similitud. As, si e1 , e2 : : : , en es la lista con n etiquetas y
(i; j ) es el grado de similitud entre la etiqueta i-esima y la j -esima, entonces la lista
con los grados se dara en el siguiente orden:
(1; 2), (1; 3), (1; 4), : : : (1; n),
(2; 3), (2; 4), : : : (2; n),
(3; 4), : : : (3; n),
:::
(n 1; n);
Por tanto, si hay n etiquetas, tras la palabra VALUES debemos situar n2 =2 n=2 numeros
(donde = representa la division entera, que trunca). Por ejemplo, con 4 etiquetas habra
que poner 6 valores y con 5 etiquetas habra que escribir 10 valores.
Otra posible de nicion del numero de valores, sabiendo el numero de etiquetas n, es
f (n), donde:
1 si n = 2
f (n) = f (n 1) + n 1 en otro caso (n > 2) (5.32)

Al utilizar este tipo de sentencia sobre un atributo, se generara un error si ocurre algo
de lo siguiente:
{ El atributo no es difuso Tipo 3: No tiene sentido de nir relaciones de similitud
sobre otros tipos de atributos.

5.2. SINTAXIS Y SEMANTICA DEL LENGUAJE FSQL 195

{ El atributo ya tiene una relacion de similitud: Para modi car la relacion ya exis-
tente se debe usar ALTER NEARNESS.
{ El atributo es compatible con otro Tipo 3: Entonces, se debe modi car la relacion
sobre el atributo con el que es compatible. Para eliminar esa compatibilidad y
poder crear as otra relacion de similitud, se debe usar previamente el comando
DROP NEARNESS.
{ La lista de similitudes tiene un numero de elementos distinto al que debe tener
segun la lista de etiquetas.
{ Algun valor de la lista de similitudes no pertenece al intervalo [0,1].
Ejemplo 5.26 Crear las etiquetas del atributo ZONA de la tabla PISOS:
CREATE NEARNESS ON PISOS.ZONA
LABEL CENTRO, NORTE, SUR, ESTE, OESTE
VALUES 0.8, 0.8, 0.8, 0.8,
0 , 0.5, 0.5,
0.5, 0.5,
0;

donde de nimos 5 etiquetas y damos los 10 valores correspondientes a la funcion de


similitud sobre estas etiquetas. tu
? ALTER TABLE: Sentencia para modi car una tabla ya creada. Su formato es igual al de
SQL pero permitiendo de nir tipos de datos difusos y restricciones difusas, como se ha
explicado mas arriba en la sentencia CREATE TABLE.
? ALTER VIEW: Sentencia para recompilar una vista. Su formato es identico al de SQL.
? ALTER LABEL: Sentencia exclusiva de FSQL para modi car una etiqueta de un atributo
difuso Tipo 1 o 2. Esto puede entenderse como borrarla y crearla de nuevo. Su formato
es igual al de CREATE LABEL pero cambiando la palabra reservada CREATE por ALTER:
ALTER LABEL nombre_label ON [schema.]table.atributo
VALUES alfa,beta,gamma,delta;

Esta sentencia producira un error si la etiqueta no esta previamente de nida para el


atributo indicado.
? ALTER NEARNESS: Sentencia exclusiva de FSQL para modi car las etiquetas de un atri-
buto difuso Tipo 3 y/o sus grados de similitud. Admite dos formatos:
1. En el sentido de borrar las etiquetas y crearlas de nuevo: As, su formato es igual
al de CREATE NEARNESS pero cambiando la palabra CREATE por ALTER:
ALTER NEARNESS ON [schema.]table.atributo
LABEL lista_de_etiquetas
VALUES lista_de_similitudes;
196 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
Se producira un error si el atributo en cuestion no tiene asociada una relacion de
similitud o no es difuso Tipo 3.
2. Para modi car solo el grado de similitud o compatibilidad entre dos etiquetas
(label1 y label2). Para esto ultimo su formato es:
ALTER NEARNESS ON [schema.]table.atributo
CDEG(label1,label2)=nuevo_grado_a_cambiar;

Se producira un error ocurre algo de lo siguiente:


{ El atributo no es difuso Tipo 3: No tiene sentido de nir relaciones de similitud
sobre otros tipos de atributos.
{ Las etiquetas label1 y/o label2 no existen en la relacion de similitud sobre
dicho atributo.
{ El atributo no tiene una relacion de similitud de nida sobre el o la relacion de
similitud que utiliza esta asociada directamente a otro atributo: Para modi car
un grado en la relacion ya existente se debe efectuar directamente sobre el
atributo que de ne la relacion y no sobre otros que sean compatibles a este.
Para eliminar esa compatibilidad y poder crear as otra relacion de similitud,
se debe usar previamente el comando DROP NEARNESS y posteriormente CREATE
NEARNESS.
O sea, para alterar una relacion de similitud sobre un atributo, este atributo
debe ser el propietario directo de esa relacion y no basta con ser un atributo
que sea compatible con el atributo propietario.

Ejemplo 5.27 Para modi car el grado de similitud entre las etiquetas NORTE y SUR del
atributo ZONA de la tabla PISOS tendramos que utilizar la siguiente sentencia:

ALTER NEARNESS ON PISOS.ZONA


CDEG(NORTE,SUR) = 0.2;

donde 0.2 es el nuevo grado de similitud entre dichas etiquetas. tu

? DROP TABLE: Sentencia para borrar una tabla (difusa o no). Su formato es identico al
de SQL.
? DROP VIEW: Sentencia para borrar una vista (difusa o no). Su formato es identico al de
SQL.
? DROP LABEL: Sentencia exclusiva de FSQL que sirve para borrar una o todas las etiquetas
de nidas sobre un atributo difuso Tipos 1 o 2. Su formato es:
DROP LABEL etiqueta ON atributo

donde etiqueta es el nombre de la etiqueta que queremos eliminar. Si en lugar de poner


el nombre de la etiqueta se pone el caracter comodn asterisco * se borraran todas las
etiquetas de nidas en la FMB para ese atributo (ver Ejemplo F.18).

5.2. SINTAXIS Y SEMANTICA DEL LENGUAJE FSQL 197

? DROP NEARNESS: Sentencia exclusiva de FSQL que sirve para borrar las etiquetas de
atributos difusos Tipo 3. Tiene dos formatos posibles:
1. Para borrar todas las etiquetas de un atributo y su relacion de similitud:
DROP NEARNESS ON [schema.]table.atributo;

Si se aplica este formato sobre un atributo difuso Tipo 3 que es compatible con otro,
entonces lo que hace es que se elimina esa compatibilidad, quedando el atributo en
cuestion sin ninguna etiqueta ni relacion de similitud.
2. Para borrar una unica etiqueta de un atributo. En este caso se borraran tambien
los grados de similitud entre esa etiqueta y el resto de ellas.
DROP NEARNESS etiqueta ON [schema.]table.atributo;

Para borrar una relacion de similitud o una etiqueta sobre un atributo, este atributo
debe ser el propietario directo de esa relacion y no basta con ser un atributo que sea
compatible con el atributo propietario. Si esto no se cumple, se producira un error.
5.2.2.2 Ejemplo de Creacion de una BDRD con Sentencias del DDL de FSQL
Los siguientes ejemplos muestran como crear una BDRD con todos los Tipos de atributos
difusos y de niendo sus etiquetas, relaciones de similitud... y todos los elementos necesarios.
Para instalar esta base de datos se ha creado un script de instalacion en el chero FDBins.sql
(ver Apendice E).
-- Creaci
on de la Base de Datos de Ejemplo: Crear las tablas:
CREATE TABLE PERSONAL(
EMP# CHAR(4) NOT NULL,
NOMBRE CHAR(20) NOT NULL,
SEXO CHAR(1) NOT NULL,
EDAD FTYPE2(5,10) NUMBER(3) DEFAULT UNKNOWN NOT NULL,
CIUDAD CHAR(15) NOT NULL,
PRIMARY KEY (EMP#));

CREATE TABLE APTITUD(


EMP# CHAR(4) NOT NULL,
ESTUDIOS FTYPE3(1) DEFAULT UNKNOWN NOT NULL,
PROF FTYPE3(1) DEFAULT UNKNOWN NOT NULL,
EXPERIENCIA FTYPE2(2,5) DEFAULT UNKNOWN NUMBER(2) NOT NULL,
PRIMARY KEY (EMP#),
CONSTRAINT FK_EMP#_APTITUD FOREIGN KEY (EMP#)
REFERENCES PERSONAL ON DELETE CASCADE);

CREATE TABLE DPTO(


DPTO# CHAR(4) NOT NULL,
NOMBRE CHAR(20) NOT NULL,
LOCALIZ CHAR(15) NOT NULL,
BENEFICIOS NUMBER(10) NOT NULL,
PRIMARY KEY (DPTO#));

CREATE TABLE PUESTOS(


198 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
PUESTO# CHAR(4) NOT NULL,
NOMBRE CHAR(20) NOT NULL,
ESTUDIOS FTYPE3(1) DOMAIN APTITUD.ESTUDIOS NOT NULL,
PROF FTYPE3(1) DOMAIN APTITUD.PROF NOT NULL,
EXPERIENCIA FTYPE2(2,5) NUMBER(2) NOT NULL,
PRIMARY KEY (PUESTO#));

CREATE TABLE EMPLEOS(


EMP# CHAR(4) NOT NULL,
DPTO# CHAR(4) NOT NULL,
PUESTO# CHAR(4) NOT NULL,
SUELDO FTYPE1(10000,50000) NUMBER(7) NOT NULL,
COMISION FTYPE2(5000,15000) NUMBER(7) NOT NULL,
RENDIMIENTO FTYPE3(1) NOT NULL,
PRIMARY KEY (EMP#,DPTO#,PUESTO#),
FOREIGN KEY (EMP#) REFERENCES PERSONAL ON DELETE CASCADE,
FOREIGN KEY (EMP#) REFERENCES APTITUD ON DELETE CASCADE,
FOREIGN KEY (DPTO#) REFERENCES DPTO ON DELETE CASCADE,
FOREIGN KEY (PUESTO#) REFERENCES PUESTOS ON DELETE CASCADE);

CREATE TABLE CIUDADES(


CIUDAD1 CHAR(15) NOT NULL,
CIUDAD2 CHAR(15) NOT NULL,
DISTANCIA FTYPE1(25,100) NUMBER(5) NOT NULL,
PRIMARY KEY (CIUDAD1,CIUDAD2));

CREATE TABLE REQUISITOS(


Clave INTEGER NOT NULL,
ESTUDIOS FTYPE3(4) DOMAIN APTITUD.ESTUDIOS NOT NULL,
PRIMARY KEY (Clave));

-- Creaci
on de Etiquetas:

-- Tabla PERSONAL:
CREATE LABEL MUY_JOVEN ON PERSONAL.EDAD VALUES 16,16,20,26;
CREATE LABEL JOVEN ON PERSONAL.EDAD VALUES 18,22,30,35;
CREATE LABEL MADURO ON PERSONAL.EDAD VALUES 25,32,45,50;
CREATE LABEL MAYOR ON PERSONAL.EDAD VALUES 40,45,55,60;
CREATE LABEL MUY_MAYOR ON PERSONAL.EDAD VALUES 50,55,62,70;

-- Tabla APTITUD:
CREATE LABEL POCA ON APTITUD.EXPERIENCIA VALUES 0,1,2,4;
CREATE LABEL ALGUNA ON APTITUD.EXPERIENCIA VALUES 2,3,5,6;
CREATE LABEL MUCHA ON APTITUD.EXPERIENCIA VALUES 5,7,10,12;
CREATE LABEL BASTANTE ON APTITUD.EXPERIENCIA VALUES 7,8,15,20;
CREATE LABEL GRANDE ON APTITUD.EXPERIENCIA VALUES 12,15,50,50;

CREATE NEARNESS ON APTITUD.ESTUDIOS


LABELS SECUNDARIA, DIPLOMADO, LICENCIADO, DOCTOR
VALUES .5, .2, .1,
.6, .3,
.8;
5.3. ARQUITECTURA DEL SERVIDOR FSQL 199

CREATE NEARNESS ON APTITUD.PROF


LABELS DIRECTOR, INGENIERO, TECNICO, ADMINISTRATIVO, SECRETARIO, VENDEDOR
VALUES .8, .7, .6, .4, .4,
.8, .2, .2, .2,
.8, .6, .5,
.7, .6,
.6;

-- Tabla PUESTOS: No se definen etiquetas para los atributos ESTUDIOS y PROF


-- porque se toman de los atributos hom
onimos de la tabla APTITUD.
CREATE LABEL POCA ON PUESTOS.EXPERIENCIA VALUES 0,1,2,4;
CREATE LABEL ALGUNA ON PUESTOS.EXPERIENCIA VALUES 2,3,5,6;
CREATE LABEL MUCHA ON PUESTOS.EXPERIENCIA VALUES 5,7,10,12;
CREATE LABEL BASTANTE ON PUESTOS.EXPERIENCIA VALUES 7,8,15,20;
CREATE LABEL GRANDE ON PUESTOS.EXPERIENCIA VALUES 12,15,50,50;

-- Tabla EMPLEOS:
CREATE LABEL BAJO ON EMPLEOS.SUELDO VALUES 50000,55000,80000,120000;
CREATE LABEL MEDIO ON EMPLEOS.SUELDO VALUES 70000,90000,170000,200000;
CREATE LABEL ALTO ON EMPLEOS.SUELDO VALUES 160000,180000,250000,300000;
CREATE LABEL MUY_ALTO ON EMPLEOS.SUELDO VALUES 200000,240000,1000000,1000000;
CREATE LABEL REDUCIDA ON EMPLEOS.COMISION VALUES 0,5000,10000,15000;
CREATE LABEL BAJA ON EMPLEOS.COMISION VALUES 11000,15000,20000,30000;
CREATE LABEL NORMAL ON EMPLEOS.COMISION VALUES 15000,17000,30000,40000;
CREATE LABEL ALTA ON EMPLEOS.COMISION VALUES 20000,32000,50000,60000;
CREATE LABEL ELEVADA ON EMPLEOS.COMISION VALUES 40000,50000,200000,300000;

CREATE NEARNESS ON EMPLEOS.RENDIMIENTO


LABELS MALO, REGULAR, BUENO, EXCELENTE
VALUES .8, .5, .1,
.7, .5,
.8;

-- Tabla CIUDADES:
CREATE LABEL MUY_CORTA ON CIUDADES.DISTANCIA VALUES 0,0,70,100;
CREATE LABEL CORTA ON CIUDADES.DISTANCIA VALUES 70,100,150,200;
CREATE LABEL MEDIA ON CIUDADES.DISTANCIA VALUES 100,150,250,300;
CREATE LABEL LARGA ON CIUDADES.DISTANCIA VALUES 150,200,450,600;
CREATE LABEL MUY_LARGA ON CIUDADES.DISTANCIA VALUES 300,400,1000,1500;
CREATE LABEL LA_MAYOR ON CIUDADES.DISTANCIA VALUES 1000,1500,99999,99999;

5.3 Arquitectura del Servidor FSQL


La Base de Datos Relacional Difusa (BDRD) y el Servidor FSQL [75, 77, 78] han sido im-
plementados, como ya se ha dicho, usando un SGBD ya existente, Oracle [92, 99, 116, 117].
Basicamente, esto implica tres consecuencias:
1. El sistema sera, quizas, mas lento que si se hubiera programado a bajo nivel.
2. La tarea de implementacion se hace mas simple ya que no necesitamos programar el
SGBD.
200 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
3. Obtenemos todas las ventajas del SGBD an trion (seguridad, e ciencia...) sin que
tengamos que tener en cuenta esos importantes detalles.
El SGBD elegido fue Oracle por su gran versatilidad, su popularidad (esta implantado en
multitud de empresas y entidades) y por la posibilidad que ofrece para crear paquetes (con
procedimientos y funciones) internos al sistema. Estos paquetes son creados en un lenguaje
propio, PL/SQL [82, 99, 116, 118, 146], que es muy e ciente en accesos a la base de datos
(mas que otros que hemos probado, como Pro*C...). Por supuesto, esta arquitectura puede
ser implementada en otros SGBD.
La arquitectura de la BDRD con el Servidor FSQL esta compuesta por:
1. Datos: Base de datos tradicional y Base de Metaconocimiento Difuso, FMB (Fuzzy
Meta-knowledge Base ).
2. Servidor FSQL (version 1.2): Encargado de ocultar el procesamiendo difuso al usuario.

3. Cliente FSQL: Encargado de hacer de interfaz entre el usuario y el Servidor FSQL.


Sera explicado en detalle en el Captulo 6.
A continuacion explicamos cada uno de estos componentes:
5.3.1 Datos: Base de Datos Tradicional y FMB
Los datos pueden ser clasi cados en dos categoras: La base de datos tradicional y la base
de metaconocimiento difuso o FMB. La base de datos tradicional esta compuesta por los
datos de nuestras relaciones con un formato especial para almacenar atributos difusos, como
se explico en el apartado 5.1.3.1.
La base de metaconocimiento difuso, FMB (Fuzzy Meta-knowledge Base ) almacena infor-
macion sobre la BDRD en un formato relacional. En la FMB se almacena una lista con los
atributos que admiten tratamiento difuso su Tipo de atributo difuso (1, 2 o 3). Ademas, para
cada atributo difuso se almacena distinta informacion dependiendo de su Tipo difuso, tal y
como se explico en el apartado 5.1.3.2. En el apartado 5.1.3.3 puede leerse un resumen de la
informacion que se guarda en la FMB.
5.3.2 Servidor FSQL
Como ya se ha dicho, ha sido programado ntegramente en PL/SQL, e incluye tres tipos de
funciones:
 Funcion de Traduccion (FSQL2SQL): Esta funcion, incluida en el paquete FSQL PKG,
efectua un analisis lexico, sintactico y semantico de la consulta FSQL. Si encuentra
errores de cualquier naturaleza, generara una tabla con todos los errores encontrados.
Si no hay errores, la consulta FSQL es traducida a una sentencia en SQL (ver ejemplos
en el Apendice F). La sentencia resultante en SQL podra incluir llamadas a los siguientes
tipos de funciones.
 Funciones de Representacion: Estas funciones son utilizadas para mostrar los atri-
butos difusos de manera que sean comprensibles por el usuario, evitando as el crptico
formato interno de estos atributos.
5.3. ARQUITECTURA DEL SERVIDOR FSQL 201

 Funciones de Comparacion Difusa: Se utilizan para comparar atributos y valores


difusos y para calcular los grados de compatibilidad que devuelve la funcion CDEG.
Lo que hace la funcion de Traduccion, es reemplazar los atributos difusos del SELECT por
llamadas a las funciones de Representacion, las condiciones difusas por llamadas a las funcio-
nes de Comparacion Difusa y reemplazar las llamadas a la funcion CDEG por llamadas a las
funciones de Comparacion Difusa y otras funciones si existen operadores logicos involucrados
en la condicion del atributo argumento de CDEG. Las funciones por defecto para los distintos
operadores logicos se muestran en la Tabla 5.13 y pueden ser cambiadas por otras, tal y como
se indica en el apartado 5.4.1.
La implementacion del Servidor FSQL sera explicada ampliamente en el apartado 5.5.
5.3.3 Cliente FSQL
Es un programa independiente que sirve de interfaz entre el usuario y el Servidor FSQL. El
usuario introduce la consulta FSQL (de forma directa o indirecta) y el programa Cliente se
comunica con el Servidor y con la base de datos para obtener los resultados deseados. La
principal funcion que usara directamente el Cliente sera la funcion de Traduccion del Servidor
FSQL. Sin embargo, en el paquete FSQL PKG existen otras funciones utiles que pueden ser
tambien usadas por el Cliente FSQL. En el Apendice D se listan y describen las funciones de
FSQL PKG.
La estructura de un programa Cliente FSQL y todo lo relacionado con el sera explicado
en detalle en el Captulo 6.
Nosotros hemos desarrollado un Cliente FSQL para Windows 95/98/NT, llamado FQ
(Fuzzy Queries). En el apartado 6.3 se incluyen algunas nociones sobre su implementacion y
en el Apendice G se incluye un manual de usuario.
5.3.4 Funcionamiento del Servidor FSQL
El proceso de llamada del Servidor FSQL esta esquematizado en la Figura 5.15. Resumiendo,
para una consulta FSQL se ejecutan los siguientes pasos:
1. El programa Cliente FSQL enva la consulta FSQL al Servidor FSQL.
2. El Servidor FSQL analiza la consulta y, si es correcta, genera una sentencia SQL a partir
de la consulta original en FSQL. En este paso el Servidor FSQL usa la informacion de
la FMB.
3. Una vez ha sido generada la consulta en SQL, el programa Cliente leera dicha consulta.
Si en el paso 2 el Servidor FSQL encontro errores, entonces, en este paso se leeran dichos
errores, para ser mostrados al usuario.
4. El programa Cliente enviara la consulta SQL a cualquier base de datos que sea coherente
con la FMB. Para la ejecucion de esta consulta podran usarse diversas funciones del
Servidor FSQL (de Representacion y Comparacion Difusa), pero eso es trasparente al
usuario.
5. Finalmente, el Cliente recibira los datos resultantes y los mostrara al usuario. El formato
de presentacion dependera, logicamente, del programa Cliente FSQL empleado.
202 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL

FSQL Client

1. FSQL Query 3. SQL Query 4. SQL Query 5. Results

Traditional
2. Fuzzy Meta-knowledge FMB
FSQL Server Database

Database

Figura 5.15: Arquitectura basica para la BDRD con el Servidor FSQL.

Los pasos 3 y 4 podran haber sido eliminados para incrementar la e ciencia pero, de esta
forma conseguimos una independencia entre la fase de Traduccion (pasos 1, 2 y 3) y la fase de
Consulta (pasos 4 y 5). As, podemos usar una base de datos local con el Servidor FSQL y la
FMB para traducir nuestras sentencias localmente y depurar los errores, y enviar las consultas
traducidas a una base de datos remota, evitando as sobrecargar la red de comunicaciones con
mensajes de error, consultas traducidas... De esta forma, la base de datos remota podra no
tener instalada la funcion de Traduccion, aunque si requerira tener instaladas las funciones
de representacion y comparacion difusa.

5.4 El Servidor FSQL


Vista la arquitectura que presenta el modelo Cliente/Servidor empleado, a continuacion ex-
plicamos algunas caractersticas del Servidor FSQL, as como las pautas a seguir para su
instalacion.

5.4.1 Informacion y Opciones de Con guracion del Servidor FSQL


El Servidor FSQL dispone de una tabla, FSQL ALL INFO, en la que se almacena informacion
general sobre el Servidor FSQL y sobre diversas opciones que puede con gurar cada usuario.
Esta tabla esta creada de la siguiente forma:
CREATE TABLE FSQL_ALL_INFO (
OWNER VARCHAR2(30),
OPCION VARCHAR2(30),
VALOR VARCHAR2(100),
PRIMARY KEY (OWNER,OPCION));
5.4. EL SERVIDOR FSQL 203

OPCION Contenido del campo VALOR


VERSION SFSQL Version del actual Servidor FSQL
FECHA INSTALACION Fecha de instalacion del Servidor FSQL
FECHA ULTIMO USO Fecha del ultimo uso del Servidor FSQL (como traductor)
FECHA ULTIMO FIN Fecha del ultimo uso de la funcion FSQL FIN (paquete FSQL PKG)
DBA INSTALLER Superusuario DBA que instala el Servidor FSQL
Tabla 5.27: Informacion disponible en la vista FSQL INFO.

Los campos de esta tabla tienen el siguiente signi cado general para cada uno:
- OWNER: Almacena el identi cador del USUARIO que tiene activada esa opcion de con-
guracion. Este campo tiene reservado el valor 'FSQL SERVER' para las opciones que
contienen informacion sobre el Servidor FSQL para todos los usuarios.
- OPCION: Opcion que se establece al valor VALOR.
- VALOR: Valor para la opcion OPCION.
Esta tabla no es accesible por los usuarios de forma directa, sino que existen dos vistas
sobre esta tabla que nos permiten acceder a sus datos:
1. Vista FSQL INFO, de informacion: Contiene informacion general sobre el Servidor
FSQL. Esta vista tiene permisos de acceso publicos solo de lectura y esta creada con la
sentencia:

CREATE or replace view FSQL_INFO AS


SELECT OPCION, VALOR FROM FSQL_ALL_INFO WHERE OWNER='FSQL SERVER';

La informacion que contiene y que todos los usuarios pueden consultar (pero no modi-
car) esta expresada en la Tabla 5.27.
2. Vista FSQL OPTIONS, de opciones de con guracion: Contiene diversas opciones de
con guracion e informacion, independientes para cada usuario, sobre el comportamiento
del Servidor FSQL. Esta vista tiene permisos de acceso publicos de lectura y escritura,
de forma que cada usuario puede modi car sus valores. La sentencia que crea esta vista
es la siguiente:

CREATE or replace view FSQL_OPTIONS AS


SELECT * FROM FSQL_ALL_INFO WHERE OWNER=USER;

As, cada usuario puede acceder solamente a las opciones de con guracion propias y no
a las de otros usuarios. El campo OPCION contiene el tipo de informacion u opcion de
con guracion y el campo VALOR contiene el valor asignado para esa OPCION. Segun esto,
el campo OPCION puede contener los siguientes valores:
204 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
NOT indica que en el campo VALOR se almacena la funcion que se aplica, cuando apa-
rece el operador NOT, para calcular el grado de cumplimiento de una funcion
CDEG. La funci on debe existir y el usuario en cuestion debe tener privilegios pa-
ra ejecutarla. En el texto del campo VALOR puede incluirse el nombre del pro-
pietario y del paquete en el que esta incluida la funcion, separados por pun-
tos: [[owner.]package.]function. Esta funcion debe tener un unico argumento
numerico.
AND indica que en el campo VALOR se almacena la funci on que se aplica, cuando apa-
rece el operador AND, para calcular el grado de cumplimiento de una funcion
CDEG. La funci on debe existir y el usuario en cuestion debe tener privilegios pa-
ra ejecutarla. En el texto del campo VALOR puede incluirse el nombre del pro-
pietario y del paquete en el que esta incluida la funcion, separados por pun-
tos: [[owner.]package.]function. Esta funcion debe tener dos argumentos
numericos.
OR indica que en el campo VALOR se almacena la funci on que se aplica, cuando apare-
ce el operador OR, para calcular el grado de cumplimiento de una funcion CDEG.
La funcion debe existir y el usuario en cuestion debe tener privilegios para eje-
cutarla. En el texto del campo VALOR puede incluirse el nombre del propie-
tario y del paquete en el que esta incluida la funcion, separados por puntos:
[[owner.]package.]function. Esta funci on debe tener dos argumentos numericos.
TRATA FUZZY ATRIB indica el tipo de tratamiento que se le da a los atributos difusos
Tipo 2 o 3, cuando estos estan fuera de los lugares normales (la lista de seleccion,
argumento de CDEG o en condiciones). El usuario puede especi car aqu que tipo
de tratamiento desea dar cuando, por ejemplo, aparece un atributo difuso Tipo 2
o 3 en una clausula ORDER BY, o como argumento de una funcion distinta de CDEG.
Para esta opcion, el atributo VALOR puede tomar 3 valores:
(a) ERROR: Este valor indica que el Servidor FSQL generara un ERROR, indican-
do que el atributo esta mal situado porque los atributos difusos no admiten
operaciones aritmeticas, ni ser argumento de funciones (excepto CDEG), ni
estar en la lista de ordenacion de la clausula ORDER BY, ni estar situados en la
posicion en la que se produce el error.
(b) TIPO VALOR: Indica que se debe utilizar el Tipo del valor difuso como sustituto
del atributo en s. O sea, considerar que el valor del atributo al que se re ere
es el tipo de valor de cada tupla, es decir, a~nadir al nombre del atributo una
'T' haciendo as referencia al valor de la columna del tipo (ver Tablas 5.1 y
5.2). Con esta opcion, si, por ejemplo, se utiliza un atributo difuso Tipo 2 en
la lista de ordenacion de la clausula ORDER BY, entonces el resultado apare-
cera ordenado por tipo de valor difuso de dicho atributo: Primero los valores
Unknown, luego los Unde ned y, sucesivamente, los valores Null, valores crisp,
etiquetas, intervalos, valores aproximados y valores trapecio.
(c) REPRESENT: Indica que se debe utilizar la representacion gra ca del atributo.
Es decir, tratar el atributo como si estuviera en la lista de seleccion y sustituirla
por una llamada a la funcion de representacion que le corresponda. Con esta
opcion, si, por ejemplo, se utiliza un atributo difuso Tipo 2 en la lista de
ordenacion de la clausula ORDER BY, entonces el resultado aparecera ordenado
5.4. EL SERVIDOR FSQL 205

OPCION VALOR
NOT Funcion que aplica CDEG en NOT a. Por defecto 1-a
AND Funcion que aplica CDEG en a AND b. Por defecto LEAST(a,b)
OR Funcion que aplica CDEG en a OR b. Por defecto GREATEST(a,b)
TRATA FUZZY ATRIB Atributos en posiciones inusuales: ERROR, TIPO VALOR o REPRESENT
NUM ERRORES N errores FSQL encontrados en la ultima traduccion del usuario
TIEMPO TRADUCCION Tiempo empleado en la ultima traduccion del usuario
Tabla 5.28: Opciones de con guracion disponibles en la vista FSQL OPTIONS para el usuario
que indique la columna OWNER.

alfabeticamente por la representacion de este atributo, tal y como se muestra


en la Tabla 5.34 para atributos difusos Tipo 2 (Tabla 5.35 para atributos
difusos Tipo 3).
Con esta con guracion, el atributo debe ser tratado como una cadena de carac-
teres (tipo VARCHAR2) para que el SGBD no produzca un error (ORA-0172210 ,
ORA-0185811 ).
Esta es la con guracion por defecto y es la mas logica, pues dar un error
puede ser contraproducente y la segunda opcion puede conseguirse facilmente
a~nadiendo la 'T' directamente. Sin embargo, el usuario puede con gurar el
Servidor FSQL para que este utilice la opcion que mas le convenga.
Cuando se utiliza un atributo difuso Tipo 2 en la clausula ORDER BY, otra
opcion, que podra ser includa en proximas versiones, tratara de realizar una
ordenacion segun algun criterio basado en el orden que subyace a este Tipo de
atributos difusos.
NUM ERRORES indica el n umero de errores encontrados por el Servidor FSQL en la ultima
traduccion que el usuario OWNER efectuo. Este valor es actualizado automaticamente
y no tiene sentido ni efecto que el usuario lo modi que.
TIEMPO TRADUCCION indica el tiempo empleado por el Servidor FSQL en la u ltima tra-
duccion que el usuario OWNER efectuo. El tiempo indicado comienza justo en la
primera instruccion que ejecuta el Servidor FSQL y termina justo antes de devol-
ver el numero de errores encontrados. Este tiempo dependera, entre otras cosas,
del numero de errores que se produzcan (NUM ERRORES), no incluye los tiempos em-
pleados en las comunicaciones entre el Servidor y el Cliente FSQL, es actualizado
automaticamente y no tiene sentido ni efecto que el usuario lo modi que.
Las funciones utilizadas por defecto para las opciones NOT, AND y OR fueron mostradas
en la Tabla 5.13 (pagina 163). Las opciones de con guracion estan resumidas en la
Tabla 5.28.
Ejemplo 5.28 Si el usuario PPGG desea utilizar unas funciones espec cas que el ha creado, en
un paquete llamado PKG, como funciones de los operadores logicos NOT y AND, podra insertar
los siguientes valores:
10 ORA-01722: Invalid number.
11 ORA-01858: A non-numeric character found where a digit was expected.
206 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
INSERT INTO FSQL_OPTIONS values (USER,'NOT','PPGG.PKG.LukaNOT');
INSERT INTO FSQL_OPTIONS values (USER,'AND','PPGG.PKG.LukaAND');

Como el operador logico OR no ha sido modi cado, este seguira usando la misma funcion
que antes de esas inserciones. tu
5.4.2 Estadsticas y Controles de Acceso del Servidor FSQL
La tabla FSQL STATS del Servidor FSQL es utilizada para controlar los accesos que se efectuen
al Servidor y poder efectuar estadsticas sobre esos datos. Por defecto, esta tabla se instala
con permisos de lectura (SELECT) para todos los usuarios, aunque el administrador del Ser-
vidor FSQL puede decidir eliminar este acceso, quedando estos datos ocultos para los demas
usuarios. El formato de la tabla es el siguiente:
CREATE TABLE FSQL_STATS (
EVENTO VARCHAR2(30) PRIMARY KEY,
NUM NUMBER (38) NOT NULL);

Los campos de esta tabla tienen el siguiente signi cado general para cada uno:
- EVENTO: Indica el suceso del que guarda informacion. Los eventos actuales se indican a
continuacion.
- NUM: Es un campo entero de tama~ no maximo en Oracle, que almacena el numero de
veces que ha ocurrido el evento especi cado en el campo anterior o el valor asociado a
dicho evento. El Servidor FSQL controla si se produce desbordamiento (ORA-0143812 )
en este campo para algun evento concreto, estableciendo, en ese caso, el valor de NUM
de ese evento a cero. El administrador del Servidor FSQL puede controlar los valores
de este campo e inicializarlos cuando lo desee.
Los eventos que actualmente gestiona el Servidor FSQL son los siguientes, aunque esta
lista es susceptible de variar facilmente:
ACCESOS PARA TRADUCCIONES indica el numero de veces que el Servidor FSQL ha sido invo-
cado para efectuar alguna traduccion, aunque esta no se haya efectuado por haberse
encontrando algun error en la sentencia. Simplemente suma 1 al campo NUM cada vez
que se ejecuta la funcion de traduccion FSQL2SQL.
ACCESOS SIN ERRORES indica el numero de veces que el Servidor FSQL ha sido invocado para
efectuar alguna traduccion y esta se ha efectuado sin que el Servidor FSQL encontrara
ningun error en la sentencia FSQL.
TOTAL ERRORES COMETIDOS indica el numero total de errores encontrados por el Servidor
FSQL en todas las consultas que se han intentado traducir.
12 ORA-01438: When inserting or updating records, a numeric value was entered that exceeded the precision
de ned for the column.
5.4. EL SERVIDOR FSQL 207

TIEMPO TOTAL ACCESOS indica el tiempo, en segundos, empleado en responder a todas las
peticiones recibidas (con o sin errores). El SGBD Oracle no permite acceder a una
unidad de tiempo menor que el segundo, por lo que en ordenadores rapidos13 no es
extra~no encontrar que algunas traducciones tardan cero segundos.
TIEMPO ACCESOS SIN ERRORES indica el tiempo, en segundos, empleado en responder a todas
las peticiones recibidas en las que el Servidor FSQL no encontro errores.
TIEMPO ULTIMA TRADUCCION indica el tiempo, en segundos, empleado en responder a la ultima
peticion que tuvo el Servidor FSQL. Esta ultima traduccion es independiente del usuario
que la realiza.
ERRORES ULTIMA TRADUCCION indica el numero de errores encontrados por el Servidor FSQL
en la ultima peticion que tuvo. Esta ultima traduccion es independiente del usuario que
la realiza.
EJECUCIONES FSQL FIN indica el numero de veces que se ha ejecutado el procedimiento
FSQL FIN del paquete FSQL PKG (ver Apendice D).
ULTIMO SESSIONID indica el numero de la ultima sesion que accedio al Servidor FSQL.
TOTAL PAQUETE FSQL PKG indica el numero de veces que se ha cargado el paquete FSQL PKG.
Esto hace referencia al numero de veces que se ha usado el Servidor FSQL, sin tener en
cuenta las distintas consultas efectuadas durante una misma sesion.
CAMBIOS DE SESSIONID indica el numero de veces que cambia el numero de sesion entre dos
accesos consecutivos al Servidor FSQL.
Con esta informacion puede calcularse facilmente el tiempo de traduccion medio global y
el tiempo de traduccion medio de las consultas en las que no se encontraron errores, as como
otros datos de interes.

5.4.3 Instalacion/Desinstalacion del Servidor FSQL


La instalacion del Servidor FSQL requiere ser efectuada por un administrador de la base
de datos (DBA). Nosotros hemos utilizado siempre el administrador SYS. La razon de este
requisito radica en que durante la ejecucion de algunas fases del Servidor se accede a una
tabla que solo es accesible por este: DBA TAB COLUMNS. Este acceso es siempre exclusivamente
de lectura.
En el Apendice E existe una relacion de todos los cheros generados en esta memoria con
su contenido y utilidad.
Los cheros de instalacion son cheros de texto con ordenes para Oracle (scripts ) que
pueden ser ejecutados desde SQL*Plus con tan solo anteponer el smbolo @ (arroba) al nombre
del chero:
@[<ruta>]<nombre fichero>
13 Ordenadores PC con procesadores Pentium II a 266 Mhz. o mejores.
208 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
donde <ruta> es el camino14 (path) donde esta el chero (es opcional) y <nombre_fichero> es
el nombre del chero a ejecutar. Si el chero tiene la extension .sql entonces no es necesario
escribirla.
Para instalar el Servidor FSQL hay que seguir los siguientes pasos, siendo superusuario
(SYS):
1. Instalar FIRST (si no lo esta): Para ello se debe ejecutar el chero FIRSTins.sql.
Este chero crea las tablas de la FMB, concede los privilegios necesarios, crea algunos
alias y algunas vista utiles, inserta comentarios sobre los objetos creados (comando
comment)...

2. Instalar Servidor FSQL: Para ello se debe ejecutar el chero SFSQLins.sql. Este
chero crea las tablas del Servidor (ver Tabla 5.31) e inserta los valores de aquellas
que son constantes, instala los paquetes del Servidor (ver Tabla 5.29), crea algunos
sinonimos y vistas, inserta comentarios sobre los objetos creados (comando comment)...
3. Instalar Cliente FSQL: Esto es indispensable para poder utilizar el Servidor. El
Cliente FSQL que se presenta en esta memoria es FQ (Fuzzy Queries) para Windows
95/98/NT (ver Captulo 6 y Apendice G).
Durante la ejecucion de esos cheros se va mostrando en pantalla las distintas fases por
las que atraviesa dicha ejecucion, as como los mensajes de error (si los hay).
Durante la instalacion de FIRST y del Servidor, antes de crear alguna tabla la borra pre-
viamente, por lo que se pueden producir algunos errores al intentar borrar algo que no existe
(ORA-0094215 y ORA-0143216 ). Cualquier otro error podra impedir la correcta ejecucion del
Servidor FSQL, por lo que si se produjera otro tipo de error se debera revisar el codigo del
error y el lugar donde ha ocurrido para subsanarlo. Puede asegurarse que los objetos se han
creado correctamente mirando que el campo STATUS de la tabla DBA OBJECTS valga 'VALID'.
Los comentarios insertados con el comando comment pueden ser consultados en las vistas
ALL TAB COMMENTS, ALL COL COMMENTS, USER TAB COMMENTS...
Tras una instalacion correcta se puede proceder a instalar o crear un base de datos difusa,
con sus tablas, vistas, etiquetas, relaciones de similitud...
Para desinstalar el Servidor FSQL hay que seguir los siguientes pasos, siendo superu-
suario (SYS):
1. Desinstalar Servidor FSQL: Para ello se debe ejecutar el chero SFSQLdes.sql.
2. Desinstalar FIRST: Para ello se debe ejecutar el chero FIRSTdes.sql. En realidad
no es necesario desinstalar FIRST, ya que pueden existir otros sistemas que lo esten
utilizando.
3. Desinstalar el Cliente FSQL: Igualmente, este paso se puede omitir si necesitamos
el cliente para otras utilidades que incorpore (como acceso a bases de datos a traves de
SQL normal).
14 En SQL*Plus puede establecerse el camino por defecto escogiendo el directorio deseado con la opcion Open
(Abrir) del menu File (Archivo) y pulsando en el boton \Cancel" (Cancelar), sin abrir ningun chero.
15 ORA-00942: Table or view does not exist.
16 ORA-01432: Public synonym to be dropped does not exist.
 DEL SERVIDOR FSQL
5.5. IMPLEMENTACION 209

Nombre Paquete Fichero Contenido


FSQL PKG FSQL PKG.sql Analizador Lexico y Sintactico y otras funciones
utiles: FSQL2SQL, FSQL FIN... (ver Apendice D)
FSQL SEMANTIC FSQL SEM.sql Analizador Semantico y conversor del Servidor FSQL
FSQL AUX FSQL AUX.sql Funciones utiles para el Servidor
FSQL FUNCTIONS FSQL F.sql Funciones de representacion y comparacion difusa
FSQL FUNCTIONS2 FSQL F2.sql Mas funciones de comparacion difusa
Tabla 5.29: Paquetes PL/SQL del Servidor FSQL y resumen de su contenido.

5.4.4 Instalacion/Desinstalacion de una Base de Datos de Ejemplo


Para instalar las bases de datos difusas no es preciso que este instalado el Servidor FSQL pero
s es preciso que este instalado FIRST. La instalacion de una base de datos no es necesario
que sea efectuada por un administrador y puede ser instalada o creada por cualquier usuario
que tenga acceso a FIRST (todos, por defecto).
En esta memoria se incluyen dos bases de datos de ejemplo:
1. Fichero FDBins.sql: Instala la base de datos de ejemplo del apartado 5.2.2.2, la cual
es una base de datos general con varias tablas que abarcan todos los casos posibles. Se
desinstala con el chero FDBdes.sql.
2. Fichero Basketin.sql: Instala una base de datos sobre jugadores de baloncesto, como la
del ejemplo de apartado 5.2.1.10. Se desinstala con el chero Baskedes.sql. El chero
Basketi2.sql contiene otros valores para la tabla de la base de datos de baloncesto.

5.5 Implementacion del Servidor FSQL


El objetivo del Servidor FSQL es conseguir traducir una sentencia FSQL a una sentencia en
SQL, mediante llamadas a funciones del Servidor.
Para ello, se han creado distintos paquetes PL/SQL [82, 99, 116, 118, 146] de forma que
cada parte del Servidor esta en un paquete distinto. En la Tabla 5.29 puede verse una lista de
los paquetes del Servidor FSQL y un resumen de su contenido y utilidad. Como curiosidad,
comentaremos que solo los paquetes del Servidor FSQL version 1.2 estan formados por cerca
de 8000 lneas de codigo. A esto, habra que a~nadir las lneas para la creacion de las tablas y
la insercion de datos que estos paquetes necesitan (mas de 3000 lneas).
El paquete FSQL PKG es el unico que contiene funciones utilizables por el usuario o por
el programa Cliente FSQL. En el Apendice D se enumeran y explican las funciones de este
paquete PL/SQL.
Basicamente, desde un punto de vista conceptual el Servidor FSQL consta de los siguientes
modulos:
1. Analizador Lexico: Se encarga de analizar si la sentencia FSQL es correcta lexicamente,
generando una lista con los tokens (palabras) de la sentencia.
2. Analizador Sintactico: Analiza si la sentencia es correcta sintacticamente. Para ello
utiliza una gramatica que genera sentencias que admiten las extensiones de FSQL que
se vieron en el apartado 5.2.
210 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
Nombre Tabla/Vista Contenido
T. RESERVADAS Palabras Reservadas del lenguaje FSQL (Apendice A)
T. T TRANSI Transiciones del Automata del Analizador Lexico (Figura 5.16)
T. TABLA SINTAX Transiciones de la Gramatica LL(1) para el Analizador Sintactico
T. PRODUCCIONES Producciones de la Gramatica para el Analizador Sintactico
V. ACCESSIBLE TABLES Tablas y Vistas accesibles por el usuario
T. FSQL ALL ERRORS Mensajes de Error FSQL de todos los usuarios (Apendice C)
V. FSQL ERRORS Mensajes de Error FSQL del usuario particular
T. FSQL ALL QUERIES Consultas FSQL y su traduccion SQL de todos los usuarios
V. FSQL QUERY Consultas FSQL y su traduccion SQL del usuario particular
T. FSQL ALL INFO Informacion y opciones de con guracion de todos los usuarios
V. FSQL INFO Informacion sobre el Servidor FSQL para todos los usuarios
V. FSQL OPTIONS Opciones de con guracion modi cables por cada usuario
T. FSQL STATS Control de accesos para estadsticas
Tabla 5.30: Tablas y Vistas del Servidor FSQL y resumen de su contenido.

3. Analizador Semantico y Conversor: Analiza si la sentencia es correcta desde el


punto de vista semantico y, a la vez, va generando la sentencia SQL equivalente. La
funcion encargada de lanzar el proceso global es la funcion FSQL PKG.FSQL2SQL.
4. Funciones de Representacion y Comparacion Difusa: Estas funciones son utiliza-
das para mostrar los atributos difusos de manera que sean comprensibles por el usuario,
para comparar atributos y valores difusos y para calcular los grados de compatibilidad
que devuelve la funcion CDEG.
Para llevar a cabo todas estas tareas el Servidor FSQL utiliza unas tablas que son creadas
al instalar el Servidor. Una lista de estas tablas con un resumen de su utilidad y de sus
caractersticas puede verse en las Tablas 5.30 y 5.31.
Los errores que se van encontrando se van insertando en la tabla FSQL ALL ERRORS, a
traves de su vista FSQL ERRORS. Estos objetos son creados de la siguiente forma:
CREATE TABLE FSQL_ALL_ERRORS (
Sessionid NUMBER NOT NULL, -- Id. de sesi
on: USERENV('SESSIONID')
Indice NUMBER(2) NOT NULL, -- N
umero de orden del error
Msg_error VARCHAR2(2000) NOT NULL, -- Mensaje del error
PRIMARY KEY (Sessionid,Indice));

CREATE or replace view FSQL_ERRORS AS


SELECT * FROM FSQL_ALL_ERRORS WHERE SESSIONID=USERENV('SESSIONID');

El signi cado de sus atributos es el siguiente:


 Sessionid: Es el numero identi cativo de la sesion en la que se esta ejecutando el
Servidor FSQL. De esta forma, cada usuario puede estar ejecutando el Servidor en
paralelo en distintas sesiones, lo que hace la Servidor FSQL ser multiusuario.
 DEL SERVIDOR FSQL
5.5. IMPLEMENTACION 211

Consultable Modi cable


por el por el
Nombre Tabla/Vista Leda por Escrita por Usuario Usuario
T. RESERVADAS A. Lexico Constante S No
T. T TRANSI A. Lexico Constante No No
T. TABLA SINTAX A. Sintactico Constante No No
T. PRODUCCIONES A. Sintactico Constante No No
V. ACCESSIBLE TABLES A. Semant./Cliente Sistema S No
T. FSQL ALL ERRORS { { No No
V. FSQL ERRORS Cliente FSQL Lex./Sint./Sem. S S
T. FSQL ALL QUERIES { { No No
V. FSQL QUERY Sint./Sem./Cliente Lex./Sint./Sem. S S
T. FSQL ALL INFO { { No No
V. FSQL INFO USER/Cliente Servidor FSQL S No
V. FSQL OPTIONS Sem./USER/Cliente USER/Cliente S S
T. FSQL STATS DBA/USER/Cliente Servidor FSQL S No
Tabla 5.31: Caractersticas de las Tablas y Vistas del Servidor FSQL.

 Indice: Simplemente numera los errores por orden de aparicion.


 Msg error: Contiene el mensaje del error cometido. En el Ap endice C se muestran una
lista con los errores que genera el Servidor FSQL y su posible solucion.
La sentencia FSQL es almacenada token a token en la tabla FSQL ALL QUERIES a traves
de su vista FSQL QUERY. En esta vista es donde el conversor ira traduciendo parte a parte la
sentencia FSQL en su sentencia SQL equivalente. Estos objetos son creados de la siguiente
forma:
CREATE TABLE FSQL_ALL_QUERIES (
Sessionid NUMBER NOT NULL, -- Id. de sesi
on: USERENV('SESSIONID')
Indice NUMBER (10) NOT NULL, -- N
umero de token (empezando por el 0)
Posicion NUMBER (10) NOT NULL, -- Posicion del final del token
Nombre VARCHAR2(30)NOT NULL, -- Nombre del token
Atributo VARCHAR2(2000),
-- Token le
do de la entrada. Si es cadena/texto podr
a tener hasta
-- 2000 caracteres (max long aceptada en una columna VARCHAR2 SQL)
PRIMARY KEY (Sessionid,Indice));

CREATE or replace view FSQL_QUERY AS


SELECT * FROM FSQL_ALL_QUERIES WHERE sessionid=USERENV('SESSIONID');

El signi cado de sus atributos es el siguiente:


 Sessionid: Es el numero de sesion en la que se esta ejecutando el Servidor FSQL. De
esta forma, cada usuario puede estar ejecutando el Servidor en paralelo en distintas
sesiones.
212 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
 Indice:
Simplemente numera los tokens por orden de aparicion en la sentencia FSQL.

Posicion: Contiene la posici on de cada token y es utilizado para generar el mensaje de
error. As, cada mensaje de error indicara la posicion donde este se produce, de forma
que se ayuda al usuario a localizar y corregir el error cometido.
 Nombre: Indica el nombre del token. Cada token tiene un nombre que lo identi ca,
como por ejemplo ID para un identi cador, GT para el smbolo >, LT para el smbolo <,
EQ para el smbolo =, GEQ para el smbolo >=...

 Atributo: Almacena el token encontrado o la modi cacion efectuada por el conversor.


A continuacion explicamos un poco mas en detalle cada uno de los modulos que contiene
el Servidor FSQL. No obstante, durante el proceso de desarrollo de todos los modulos del
Servidor FSQL se han introducido multitud de comentarios explicativos en el codigo fuente
que facilitan su lectura, comprension y modi cacion.
Un estudio mas exhaustivo y general de los analizadores lexico, sintactico y semantico
puede encontrarse en [3].
5.5.1 Analizador Lexico
La funcion encargada del analisis lexico es FSQL PKG.FSQL LEXICO y es llamada por la funcion
FSQL2SQL y devuelve el numero de errores lexicos encontrados por el analizador en la sentencia
FSQL (ver Apendice C).
El analizador lexico asegura que todos los elementos de la sentencia estan permitidos,
agrupando los caracteres en palabras, llamadas tokens, que son los smbolos terminales de la
gramatica. Los tokens son obtenidos leyendo la sentencia caracter a caracter y aplicando sobre
la marcha el automata nito determinista de la Figura 5.16, donde su estado inicial es el cero,
sus estados terminales son representados con un crculo doble y tienen los signi cados dados en
la Tabla 5.32. Para simpli car el automata se ha utilizado una lista de palabras reservadas que
son identi cadores con un signi cado especial y que estan reservados para un uso concreto. En
el Apendice A se muestra la lista de todas las palabras reservadas consideradas por el Servidor
FSQL. Ejemplos de palabras reservadas son SELECT, FROM, INSERT, CDEG, FEQ, NFEQ...
Para hallar los tokens, suponemos que el automata esta situado en el estado cero, se lee
un caracter de la sentencia de entrada y dependiendo de este se pasa a otro estado. As,
leyendo caracteres va cambiando de estado hasta que llegamos a un estado en el que no existe
transicion para el caracter ledo. En ese caso, si el estado es terminal ( nal) ya tenemos un
token y si el estado es no terminal entonces obtenemos un error lexico.
Si el token es un identi cador (estado 15) se debera comprobar si pertenece a la lista de
palabras reservadas, las cuales estan contenidas en la tabla RESERVADAS (ver Apendice A).
Esta tabla tiene permiso de lectura para todos los usuarios, por si estos desean consultarla
en algun momento, y esta creada con la siguiente sentencia:
CREATE TABLE RESERVADAS(
Palabra varchar(20) NOT NULL,
PRIMARY KEY (Palabra));

La tabla T TRANSI contiene la tabla de transiciones para el automata empleado. Al igual


que la tabla RESERVADAS, sus datos son introducidos durante la instalacion del Servidor y
permanecen siempre constantes:
 DEL SERVIDOR FSQL
5.5. IMPLEMENTACION 213
Estado Token
1 Suma
2 Resta
3 Producto
4 Division
5 Parentesis izquierdo
6 Parentesis derecho
7 Coma
8 Punto
9 Comparador Mayor que
10 Dolar (comienzo de etiqueta o trapecio)
11 Comparador Menor que
12 Comparador Igual que
13 Numero Entero
14 Numero Real en notacion Fija
15 Identi cador o Palabra Reservada
16 Comparador Mayor o Igual que
17 Comparador Menor o Igual que
19 Comparador Distinto a (4 formas)
20 Corchete izquierdo
21 Corchete derecho
22 Punto y coma
24 Cadena (con comillas dobles)
26 Texto (con comillas simples)
27 Sostenido (Smbolo de Aproximadamente)
28 Tanto por ciento (Caracter comodn)
29 Llave izquierda
30 Llave derecha
33 Numero Real en notacion Exponencial
36 Operador Concatenar
38 Comentario (3 formas)
 Los tokens 16, 17, 19 y 36 admiten espacios entre sus caracteres.
 Como en SQL, no se distingue entre mayusculas y minusculas
(excepto en los estados 24 y 26).
Tabla 5.32: Signi cado de los Estados Terminales del automata de la Figura 5.16.

CREATE TABLE T_TRANSI (


Estado NUMBER(2) NOT NULL, -- Estado actual
Caracter NUMBER(3) NOT NULL, -- Car
acter le
do
Sig_estado NUMBER(2) NOT NULL, -- Estado siguiente leyendo ese car
acter
PRIMARY KEY (Estado,Caracter));

Ademas, el analizador lexico elimina los comentarios que hubiera en el comando de entra-
da. El formato de los comentarios se ha explicado en el apartado 5.2.1.
Si encuentra un error, inserta el texto del error en la vista FSQL ERRORS y continua el
analisis en busca de mas errores.
El analizador lexico inserta en la vista FSQL QUERY una lista con todos los tokens de la
sentencia de entrada (ordenados por el atributo INDICE). Tras el analisis lexico, todas las
\palabras" de la sentencia estaran introducidas en esta vista de forma ordenada.
Estado Inicial
+ $
1 0 10
214
- > =
2 9 16

b
* =
3 12

/ {A..Z}
4 15 {A..Z,0..9,_,$,#}

( < =
5 11 17
b >
) {!,^,} =
6 18 19

b
, [
7 20

. ]
8 21

{0..9} ;
{0..9} 13 22
E ASCII-{"}
.
" "
{0..9} 23 24
14 E
31

{0..9} {0..9} {+,-} 25 26

{0..9} ASCII-{}
33 32 #
27
{0..9}
*
* * %
39 40 28
ASCII-{*, /}
{EOS,/} {
ASCII-{*} EOS 29
-
37 38
}
30
ASCII-{ }
EOS (End Of Sentence) es el b
Fin de Sentencia.
b representa al espacio en blanco. 35 36
ASCII es el conjunto de todos los caracteres.
representa el retorno de carro (RETURN): Caracteres 10 o 13.

Estados Terminales (finales). Estados No Terminales.

Figura 5.16: Automata nito determinista usado por el Analizador Lexico de FSQL.
 DEL SERVIDOR FSQL
5.5. IMPLEMENTACION 215

5.5.2 Analizador Sintactico


La funcion FSQL PKG.FSQL SINTACTICO es la encargada de este analisis y es llamada por la
funcion FSQL2SQL tras el analizador lexico y devuelve el numero de errores encontrados por
la sentencia FSQL, incluyendo lexicos y sintacticos (ver Apendice C).
El analizador Sintactico asegura que los tokens estan en un orden adecuado y que la
construccion de la sentencia es correcta sintacticamente.
Para expresar la sintaxis de una sentencia hemos elegido la forma de gramatica utilizando
el formato de Yacc. El Apendice B contiene la gramatica empleada por el Servidor FSQL.
Una gramatica G esta formada por 4 conjuntos de datos: G = fT; N; S; P g, donde:
 T es una lista de smbolos Terminales de la gramatica, es decir, las palabras (tokens ) que
son utilizados para formar una sentencia nal valida. En nuestra gramatica (Apendice
B) hemos tomado la convencion de escribirlos con todas las letras en mayuscula.
 N es una lista de smbolos No Terminales, que son smbolos temporales utilizados para
generar sentencias validas de nuestra gramatica. En nuestra gramatica son escritos con
todas las letras en minuscula.
 S es un smbolo No Terminal, llamado Smbolo Inicial, a partir del cual se derivan todas
las sentencias validas de nuestra gramatica aplicando las producciones.
 P es un conjunto de Producciones a partir de las cuales y empezando por el Smbolo
Inicial se obtienen las sentencias. Una produccion tiene dos partes: Izquierda y Derecha
(separadas por dos puntos). La parte izquierda es un smbolo de N y la parte derecha
es una lista de smbolos de N y/o T en un orden concreto. El smbolo de la parte
izquierda puede ser sustituido por todos los smbolos de la parte derecha. Si varias
producciones tienen el mismo smbolo de la izquierda se pueden escribir separando las
distintas partes derechas por las que puede ser sustituido por el caracter `|'. Ese caso
indica que el smbolo de la parte izquierda puede ser sustituido por cualquiera de esas
partes derechas. La parte derecha de una produccion puede ser la cadena vaca (nada),
que indica que el smbolo No Terminal de la izquierda puede ser eliminado sin ser
sustituido por nada.
La generacion de sentencias de una gramatica es simple, pues se trata de, empezando
por S sustituir cada smbolo de N por una de las posibilidades que ofrece en el conjunto de
producciones P . Las producciones son aplicadas hasta que no hay smbolos de N . En ese
caso, decimos que la sentencia generada es correcta sintacticamente. Si se llega a un punto en
el que no existe una produccion valida para construir la sentencia, la sentencia sera erronea
sintacticamente.
Para ello, utiliza las tablas PRODUCCIONES y TABLA SINTAX creadas de la siguiente forma
y con el siguiente signi cado para sus atributos:
CREATE TABLE PRODUCCIONES (
Num_prod NUMBER(3) NOT NULL,
Posicion NUMBER(1) NOT NULL,
Parte_der VARCHAR2(20),
Terminal_der CHAR NOT NULL,
PRIMARY KEY (Num_prod,Posicion));
216 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
Esta tabla contiene la lista de producciones de la gramatica. Una produccion utiliza
tantas las como smbolos tenga en la parte derecha de la produccion. Sus atributos tienen
el siguiente signi cado:
 Num prod: Indica el numero de produccion a la que pertenece. Todas las producciones
de nuestra gramatica estan numeradas.
 Posicion: Posicion que ocupa el smbolo del atributo Parte der en esa produccion. La
parte derecha de una produccion puede tener n smbolos, con n  1. Por tanto, para
cada uno de esos n smbolos hay que incluir una la en esta tabla.
 Parte der: Smbolo (No Terminal o Terminal) de la derecha que esta en esa Posicion
dentro de la parte derecha de la produccion. Por convenio hemos notado en mayusculas
los smbolos terminales y en minusculas los smbolos no terminales. Si como parte
derecha de la produccion aparece la cadena vaca, se inserta 'VACIO' (como smbolo No
Terminal).
 Terminal der: Indica si el smbolo de Parte der es Terminal ('T') o No Terminal
('N').
La tabla TABLA SINTAX contiene las transiciones del analizador sintactico, segun la gramatica
LL(1) usada. Aprovechando que la gramatica es LL(1), se simpli ca el desarrollo del anali-
zador sintactico. As, utilizamos una estructura tipo pila, implementada a traves de tablas
PL/SQL (tipo TPILA). Entonces, seguimos el siguiente algoritmo:
1. Introducir un smbolo de FIN en la Pila, para que nos indique cuando hemos terminado
el analisis.
2. Introducir el Smbolo Inicial de la gramatica en la Pila, para empezar el analisis.
3. Se lee un token de la entrada, i.e., de la vista FSQL QUERY ordenadamente por el campo
Indice.

4. Se lee un smbolo de la Pila.


5. Si el smbolo de la Pila es el smbolo de FIN, termina el analisis: Si, en ese momento,
quedan smbolos sin analizar en la entrada, entonces se genera un error del tipo \en-
contrado en la entrada un token cuando esperaba el FIN de la sentencia". Si, por el
contrario, no quedan smbolos sin analizar, la sentencia sera correcta sintacticamente.
6. Si el smbolo de la Pila es terminal y coincide con el de la entrada se acepta el token y
se vuelve al paso 3. Si no coinciden ambos valores, entonces se genera un error.
7. Si el smbolo de la Pila es no terminal, entonces para dicho smbolo no terminal y para el
token ledo existira una unica produccion a aplicar. Eso es averiguado leyendo en la tabla
TABLA SINTAX. La parte derecha de dicha producci on es introducida smbolo a smbolo
en la Pila en orden inverso (orden decreciente del atributo PRODUCCIONES.posicion).
8. Ir al paso 4.
Como vemos, la tabla TABLA SINTAX es fundamental en este analisis, pues nos permite
averiguar el numero de la produccion a aplicar. Esta tabla tiene el siguiente formato:
 DEL SERVIDOR FSQL
5.5. IMPLEMENTACION 217

CREATE TABLE TABLA_SINTAX (


Simbolo_NT VARCHAR2(20) NOT NULL,
Simbolo_T VARCHAR2(20) NOT NULL,
Num_prod NUMBER(3) NOT NULL,
PRIMARY KEY (simbolo_NT,simbolo_T));

Y sus atributos tienen el siguiente signi cado:


 Simbolo NT: Smbolo No Terminal encontrado en la Pila.
 Simbolo T: Smbolo Terminal (token ) ledo de la consulta de entrada.
 Num prod: Numero de produccion a aplicar en el caso de que encontremos ese Simbolo NT
en la Pila y ese Simbolo T en la entrada.
Los valores de esta tabla son introducidos de la siguiente forma: Para cada produccion
del tipo

I ! D1 D2 : : : Dn (5.33)
hay que insertar en TABLA SINTAX tuplas con I en el primer atributo, el numero de esa
produccion en el tercer atributo y un smbolo terminal incluido en los Smbolos Directores en
el segundo atributo. O sea, para cada produccion se introducen en esta tabla tantas tuplas
como Smbolos Directores existan. Los Smbolos Directores se calculan de la siguiente forma:
1. Si D1 D2 : : : Dn no es anulable: Iniciales(D1D2 : : : Dn ).
2. Si D1 D2 : : : Dn s es anulable: Iniciales(D1D2 : : : Dn ) [ Seguidores(I ).
Durante el analisis sintactico se va modi cando el atributo FSQL QUERY.nombre de algunos
tokens, de forma que los identi camos mas exactamente para facilitar esta identi cacion al
analizador semantico. Esto se efectua principalmente para localizar el signi cado de los
identi cadores, comparadores, numeros de umbral...
5.5.3 Analizador Semantico y Conversor
La funcion FSQL SEMANTIC.semantico es la encargada de este analisis y es llamada por la
funcion FSQL2SQL tras el analizador lexico y sintactico si en estos no se han encontrado
errores. El analizador semantico solo es ejecutado, por tanto, si la sentencia no contiene
errores lexicos ni sintacticos. De esta forma, conseguimos que el analizador semantico no sea
ejecutado innecesariamente.
El analizador semantico es el modulo mas complejo de todo el Servidor, el mas largo, el
que mas tiempo de ejecucion necesita y el que mas accesos a la base de datos realiza. Igual
que en los anteriores analizadores, esta funcion devuelve el numero de errores encontrados en
la sentencia FSQL (ver Apendice C).
Este analizador se asegura que la sentencia no tiene errores semanticos en general y, mas
en particular, en lo relativo a la extension difusa de FSQL.
Ademas, a la vez que analiza semanticamente la sentencia va convirtiendola en una sen-
tencia de SQL, de forma que va sustituyendo las clausulas propias de FSQL por clausulas
218 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
propias de SQL utilizando, principalmente, llamadas a funciones (sobretodo a las Funciones
de Representacion y Comparacion difusa, apartado 5.5.4). En el Apendice F se exponen
algunos ejemplos de sentencias FSQL traducidas a SQL.
Durante todo el proceso, el analizador utiliza la vista FSQL QUERY alterando el contenido
de la columna Atributo, de forma que una vez terminado el analisis sin errores, la sentencia
SQL resultante se obtiene concatenando todos los campos Atributo de esa vista, ordenados
por el campo Posicion. Esa concatenacion debera ser efectuada por el programa Cliente
FSQL (ver Captulo 6).
Resumiendo, este analisis se compone de las siguientes tres grandes fases:
5.5.3.1 Fase preliminar: Las Tablas, sus Alias y los Comodines
En una primera fase este analizador estudia los alias de las tablas y si las tablas situadas en
la parte FROM de la sentencia son o no accesibles por el usuario. En caso negativo se genera
un error.
Tras esto, se soluciona el problema que pueden plantear los comodines, tanto el asterisco
*, como el tanto por ciento %, ya que ambos pueden incluir atributos que requieran un
tratamiento especial por ser difusos Tipo 2 o 3. Los atributos difusos Tipo 1 no requieren
un tratamiento especial. La inclusion de comodines puede ser efectuada en los 6 siguientes
formatos:
* <tabla>.* <esquema>.<tabla>.*
% <tabla>.% <esquema>.<tabla>.%

Con el comodn *, si las tablas involucradas no contienen atributos difusos Tipo 2 o 3 se


dejan los comodines. En caso contrario, columna por columna de la tabla se incluye en la
lista de seleccion (en la posicion que tena el comodn). Si el atributo es difuso Tipo 2 o 3 se
incluye la llamada a la funcion que representa su valor. Suponemos que los atributos difusos
Tipo 2 o 3 tienen en orden sus columnas: Primero el tipo (terminado en T) y luego el resto
de atributos (ordenados por su numero), como se expone en las Tablas 5.1 y 5.2 segun sea su
Tipo difuso 2 o 3 respectivamente.
Con el comodn %, si las tablas no tienen atributos con ictivos (difusos Tipos 2 o 3) se
cambian por <tabla>.* o <esquema>.<tabla>.* y se incluyen las llamadas a la funcion CDEG
de los Tipos 1, si los hay. Las llamadas a CDEG son incluidas en la vista FSQL QUERY como si
hubiesen sido escritos en la consulta inicial, poniendo su posicion a cero, siendo tratados as
como un CDEG normal posteriormente (por el procedimiento calcula CDEG). Si un atributo
difuso no aparece en la clausula WHERE, su CDEG no es aplicable y por tanto no aparecera su
CDEG si se usa el comodn % (que ser a eliminado en calcula CDEG).
5.5.3.2 Fase de Tratamiento de Atributos Difusos
Despues del proceso anterior se pasa a la parte mas importante del desarrollo, el tratamiento
de los atributos difusos. Todas las expresiones que necesitan un tratamiento especial por ser
extensiones de FSQL y que no pueden ser tratadas normalmente, incluyen, forzosamente un
atributo difuso. Por tanto, en esta fase se localizan los atributos y para cada uno de ellos se
realiza un tratamiento especial si es difuso (en el procedimiento trata fuzzy column).
En este tratamiento se tiene en cuenta que un atributo difuso puede aparecer en los
siguientes lugares:
 DEL SERVIDOR FSQL
5.5. IMPLEMENTACION 219

1. En la lista de seleccion del SELECT como columna solitaria y no en expresiones17:


En este caso se modi ca (a traves del procedimiento llamado fuzzy column en sl) el
campo FSQL QUERY.atributo de las columnas difusas Tipo 2 o 3. En su lugar se pone
una llamada a la funcion correspondiente para mostrar ese atributo difuso de forma
coherente (funciones fshow2 y fshow3 respectivamente).
2. Como argumento de la funcion CDEG: En este lugar, el tratamiento de dicho atributo
con esta funcion se realiza en la fase posterior.
3. En una condicion difusa (clausula WHERE): En este caso se sustituye cada condicion
difusa elemental por una funcion de comparacion difusa, teniendo en cuenta el tipo de
condicion difusa elemental que sea, tal y como se indico en el apartado 5.2.1.8 y en las
que un atributo difuso puede aparecer en las siguientes posiciones:
(a) A la izquierda de cualquier comparador difuso, expresados en la Tabla 5.12 (FEQ,
NFEQ, FGT...).
(b) A la derecha de cualquier comparador difuso si hay otra columna a la izquierda de
tipos compatibles18 .
(c) A la izquierda de una condicion con IS.
4. En cualquier otro lugar (en operaciones aritmeticas, como argumento de funciones,
en la clausula ORDER BY...): Si el atributo difuso es Tipo 1, no hay problema y no se
hace ningun tratamiento especial. Si el atributo difuso es Tipo 2 o 3, pueden hacerse 3
tratamientos distintos, tal y como se explico en el apartado 5.4.1, y cada usuario puede
escoger el tipo de tratamiento que desea efectuar en cada momento.

5.5.3.3 Fase de Tratamiento de la Funcion CDEG


Primero se calculan las funciones que se usaran como normas para el tratamiento de los
operadores logicos que aparecen en la condicion. Estas funciones estan almacenadas en la
vista FSQL OPTIONS, como se vio en el apartado 5.4.1. Por defecto se usan las funciones que
se indicaron en la Tabla 5.13. En la Tabla 5.33 se ven las funciones empleadas para sustituir
un CDEG donde su atributo este involucrado en una <Condicion> con operadores logicos. Si en
la vista FSQL OPTIONS no esta de nida la funcion a emplear para algun operador, se utilizaran
las funciones por defecto, donde LEAST y GREATEST son funciones para el mnimo y el maximo
respectivamente que estan ya implementadas en Oracle.
Una vez ledas las funciones anteriores se pasa al tratamiento particular de cada llamada
a esta funcion particular de FSQL (procedimiento calcula CDEG). Si el argumento es * se
tienen en cuenta todas las condiciones elementales de la condicion de la clausula WHERE y
si, por el contrario, el argumento es un atributo, solo se tendran en cuenta las condiciones
elementales donde este involucrado dicho atributo. En general, es mas util utilizar el * pues
nos da el grado de cumplimiento de toda la condicion impuesta en la consulta para cada tupla.
17 La inclusion de atributos difusos (sobretodo los Tipo 2) y constantes difusas en expresiones aritmeticas no
esta contemplada en esta version y debera ser tenida en cuenta en versiones posteriores.
18 En esta version no se consideran validas comparaciones sin atributos difusos a la izquierda de un compa-
rador difuso, aunque s aparezcan a la derecha. La solucion a este inconveniente es tan facil como intercambiar
el orden de los argumentos del comparador.
220 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
<Condici
on> Funciones para CDEG(<Condicion>) F. para CDEG(<Condicion>) con
(con op. logicos) por defecto (FSQL OPTIONS vaco) estas funciones en FSQL OPTIONS
<c1> AND <c2> LEAST(CDEG(<c1>),CDEG(<c2>)) F AND(CDEG(<c1>),CDEG(<c2>))
<c1> OR <c2> GREATEST(CDEG(<c1>),CDEG(<c2>)) F OR(CDEG(<c1>),CDEG(<c2>))
NOT <c1> 1 - CDEG(<c1>) F NOT(CDEG(<c1>))

Tabla 5.33: Funciones usadas para el calculo de la funcion CDEG con operadores logicos.

Si en la lista de condiciones elementales aparece una condicion clasica (crisp), se utilizara


una llamada a la funcion FSQL FUNCTIONS.CompCrisp que devuelve 1 si la condicion es verdad
y 0 si la condicion es falsa.
5.5.4 Funciones de Representacion y Comparacion Difusa
Estas funciones no son ejecutadas por el Servidor FSQL, aunque forman parte de este. En
la sentencia SQL traducida de una FSQL, se incluyen llamadas a algunas de estas funciones.
De esta forma, estas funciones son ejecutadas cuando se ejecuta la sentencia SQL resultante
de la traduccion de una sentencia FSQL usando el Servidor FSQL.
Para que una funcion pueda ser empleada de esta forma debe ser declarada como restrin-
gida (restricted ) de la siguiente forma:
PRAGMA RESTRICT_REFERENCES (<nombre_funci
on>,WNDS,WNPS,RNPS);

donde <nombre_funcion> es el nombre de la funcion, WNDS (Write No Database State ) no


permite que se modi que la base de datos desde la funcion, WNPS (Write No Package State )
no permite escribir variables de ningun paquete y RNPS (Read No Package State ) no permite
leer variables de ningun paquete.
Para el correcto funcionamiento de estas funciones es imprescindible que las tablas y
atributos de FIRST esten correctamente de nidos, as como que todos los objetos utilizados
para los atributos difusos esten correctamente introducidos en dichas tablas. Por ejemplo, si en
una relacion se almacena una etiqueta lingustica para un determinado atributo difuso Tipo 2 y
dicha etiqueta no esta de nida correctamente (en FUZZY OBJECT LIST y/o FUZZY LABEL DEF)
se producira un error en tiempo de ejecucion cuando se intente acceder a esa etiqueta.
Algunos de estos errores podran ser detectados y evitados de niendo algunos triggers
(disparadores) en el SGBD que ayuden a mantener la integridad de los atributos difusos y de
los valores de la FMB. La mision de estos triggers sera producir un error cuando se intente
insertar algun valor incorrecto, tanto en la base de datos como en la FMB.
5.5.4.1 Funciones de Representacion
Las Funciones de Representacion estan incluidas en el paquete FSQL FUNCTIONS y tienen
por objetivo representar gra camente aquellos atributos difusos que tienen una representacion
interna distinta de la habitual, i.e., los atributos difusos Tipo 2 y 3. Existen tres tipos de
estas funciones:
1. Funcion fshow2: Esta funcion se utiliza para representar atributos difusos Tipo 2, y su
cabecera, con sus argumentos, es la siguiente:
 DEL SERVIDOR FSQL
5.5. IMPLEMENTACION 221

F_TYPE Representacion Ejemplos


0 UNKNOWN UNKNOWN
1 UNDEFINED UNDEFINED
2 NULL NULL
3 (crisp) F1 25
4 (etiqueta) label Joven
5 (intervalo) [F1,F4] [21,26]
6 (aproximado) F1F4 2210
7 (trapecio) $[F1,F1+F2,F3+F4,F4] $[18,21,26,28]
Tabla 5.34: Representacion Gra ca de Atributos difusos Tipo 2.

FUNCTION fshow2 (
OBJ IN FUZZY_LABEL_DEF.OBJ#%TYPE, COL IN FUZZY_LABEL_DEF.OBJ#%TYPE,
F_TYPE IN FUZZY_COL_LIST.F_TYPE%TYPE,
F1 IN NUMBER, F2 IN NUMBER, F3 IN NUMBER, F4 IN NUMBER) RETURN VARCHAR2;

donde (OBJ,COL) son los numeros identi cativos de la tabla y columna del atributo que
se desea representar, F_TYPE es el tipo del valor de dicho atributo y F1, F2, F3 y F4
son el resto de argumentos del atributo, tal y como se representan los atributos difusos
Tipo 2 en formato relacional (Tabla 5.1).
La funcion devuelve un dato de tipo cadena de caracteres (VARCHAR2), que es el dato
mostrado. En la Tabla 5.34 se muestra como se representa cada tipo de valor en un
atributo difuso Tipo 2, con un ejemplo para cada uno.
2. Funcion fshow3: Esta funcion se utiliza para representar atributos difusos Tipo 3, y su
cabecera, con sus argumentos, es la siguiente:

FUNCTION fshow3 (
OBJ IN FUZZY_LABEL_DEF.OBJ#%TYPE, COL IN FUZZY_LABEL_DEF.OBJ#%TYPE,
LEN IN FUZZY_COL_LIST.LEN%TYPE,
F_TYPE IN FUZZY_COL_LIST.F_TYPE%TYPE,
FP1 IN NUMBER, F1 IN FUZZY_OBJECT_LIST.FUZZY_ID%TYPE,
FP2 IN NUMBER, F2 IN FUZZY_OBJECT_LIST.FUZZY_ID%TYPE,
FP3 IN NUMBER, F3 IN FUZZY_OBJECT_LIST.FUZZY_ID%TYPE,
FP4 IN NUMBER, F4 IN FUZZY_OBJECT_LIST.FUZZY_ID%TYPE,
FP5 IN NUMBER, F5 IN FUZZY_OBJECT_LIST.FUZZY_ID%TYPE,
FP6 IN NUMBER, F6 IN FUZZY_OBJECT_LIST.FUZZY_ID%TYPE,
FP7 IN NUMBER, F7 IN FUZZY_OBJECT_LIST.FUZZY_ID%TYPE,
FP8 IN NUMBER, F8 IN FUZZY_OBJECT_LIST.FUZZY_ID%TYPE,
FP9 IN NUMBER, F9 IN FUZZY_OBJECT_LIST.FUZZY_ID%TYPE,
FP10 IN NUMBER,F10 IN FUZZY_OBJECT_LIST.FUZZY_ID%TYPE) RETURN VARCHAR2;

donde (OBJ,COL) son los numeros identi cativos de la tabla y columna del atributo que
se desea representar, F_TYPE es el tipo del valor de dicho atributo, LEN es el numero
222 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
F_TYPE Representacion Ejemplos
0 UNKNOWN UNKNOWN
1 UNDEFINED UNDEFINED
2 NULL NULL
3 (simple) FP1/label Moreno (si FP1=1 se quita el 1/)
4 (dist. pos) FP1/label1: : : FPLEN /labelLEN 0.2/Rubio, 0.8/Casta~no, 1/Moreno (LEN=3)
Tabla 5.35: Representacion Gra ca de Atributos difusos Tipo 3.

de campos maximo del atributo en cuestion y (FPi,Fi) son el resto de argumentos del
atributo, tal y como se representan los atributos difusos Tipo 3 en formato relacional
(Tabla 5.2). Como puede observarse, el Servidor FSQL no esta preparado para represen-
tar distribuciones de posibilidad sobre atributos difusos Tipo 3 con mas de 10 elementos
de longitud. De todas formas, nos parece que las distribuciones de posibilidad de este
tipo con una longitud mayor de 10 elementos son excesivamente raras y no muy utiles
en la mayora de los casos.
La funcion devuelve un dato de tipo cadena de caracteres (VARCHAR2), que es el dato
mostrado. En la Tabla 5.35 se muestra como se representa cada tipo de valor en un
atributo difuso Tipo 3, con un ejemplo para cada uno.
3. Funcion fshow3 len1: Esta funcion es similar a la funcion anterior pero en esta supone-
mos que el argumento LEN vale 1, por lo que se reduce mucho el numero de argumentos.
En realidad, pensamos que los atributos difusos Tipo 3 son, en la mayora de los casos
utilizados como distribuciones de posibilidad con un unico elemento, por lo que usando
esta funcion de representacion incrementamos la e ciencia en la mayora de los casos.
Su cabecera es la siguiente y sus argumentos no necesitan ya explicacion.

FUNCTION fshow3_len1 (
OBJ IN FUZZY_LABEL_DEF.OBJ#%TYPE, COL IN FUZZY_LABEL_DEF.OBJ#%TYPE,
F_TYPE IN FUZZY_COL_LIST.F_TYPE%TYPE,
FP1 IN NUMBER, F1 IN FUZZY_OBJECT_LIST.FUZZY_ID%TYPE) RETURN VARCHAR2;

Estas funciones pueden detectar algunos errores en la representacion de valores difusos en


las tablas, en tiempo de ejecucion:

 Si una determinada etiqueta no existe en FUZZY OBJECT LIST su representacion no puede


ser leda y mostrara el mensaje \ERROR: Etiqueta no de nida".
 Si el tipo de valor difuso no es correcto, i.e., no esta entre 0 y 7 para atributos difusos
Tipo 2 o no esta entre 0 y 4 para atributos difusos Tipo 3, entonces el mensaje mostrado
sera: \Error en Tipo Fuzzy". Este error puede ser evitado facilmente estableciendo, al
crear la tabla, una restriccion en las columnas del tipo de valores difusos: De 0 a 7 para
los atributos difusos Tipo 2 (Tabla 5.1) y de 0 a 4 para los Tipo 3 (Tabla 5.2).
 DEL SERVIDOR FSQL
5.5. IMPLEMENTACION 223

Formato de la comparacion Funcion empleada


N con el comparador difuso generico FFF en la traduccion
1 fcol_t1 FFF [X,Y] FFF_crisp_finter
2 fcol_t1 FFF #Aprox FFF_crisp_aprox
3 fcol_t1 FFF $label FFF_crisp_trape
4 fcol_t1 FFF $[a,b,c,d] FFF_crisp_trape
5 fcol_t1 FFF crisp FFF_t1_t1
6 fcol_t1 FFF expr_crisp FFF_t1_t1
7 fcol_t1 FFF fcol_t1 FFF_t1_t1
8 fcol_t1 FFF fcol_t2 FFF_t1_t2
9 fcol_t1 FFF (UNKNOWN|UNDEFINED|NULL) Error
10 fcol_t1 IS [NOT] (UNKNOWN|UNDEFINED) Error
11 fcol_t1 IS [NOT] NULL Comp. clasica: NULL del SGBD (no difuso)
Tabla 5.36: Funciones de comparacion difusa empleadas con atributos difusos Tipo 1.

5.5.4.2 Funciones de Comparacion Difusa


Las Funciones de Comparacion difusa estan incluidas en los paquetes FSQL FUNCTIONS
y FSQL FUNCTIONS2. En el segundo estan, por ahora, solo las funciones de comparacion de
los comparadores \Mucho Mayor/Menor que", i.e., MGT/NMGT y MLT/NMLT. El resto, estan en
el primer paquete.
Como ya se ha dicho anteriormente, el Servidor FSQL tiene en cuenta el tipo de los
valores a comparar, de forma que se utilice la funcion mas apropiada para cada tipo, ganando
el sistema en e ciencia. As, si en una comparacion sabemos que un elemento es un valor
crisp, la comparacion es mas simple que si es un trapecio o que si puede ser cualquier tipo de
valor representado por el nombre de un atributo difuso.
Por eso, se ha programado una funcion independiente para cada tipo de comparacion
posible, de forma que en cada caso se utilice la funcion apropiada. Se podra haber programado
solo una funcion general que sirviera para todos los tipos, pero esto sera poco e ciente cuando
ya sabemos el tipo de una o ambas partes de la comparacion.
Los atributos difusos Tipo 1 son considerados como valores crisp y los atributos difusos
Tipo 2 y 3 tienen funciones separadas por su incompatibilidad.
Para atributos difusos Tipo 2, las funciones generales, que sirven para cualquier tipo,
han sido programadas con el nombre del comparador al que implementan y son utilizadas
exclusivamente cuando a ambos lados del comparador aparecen sendos atributos difusos Tipo
2. As, existen las siguientes funciones de comparacion entre dos atributos difusos Tipo 2:
FEQ, NFEQ, FGT, NFGT...
En las Tablas 5.36 y 5.37 se muestran las funciones empleadas cuando se utiliza respec-
tivamente un atributo difuso Tipo 1, <fcol_t1>, y Tipo 2, <fcol_t2>, con un comparador
difuso generico que llamaremos FFF.
Con respecto a la Tabla 5.36, destacar el hecho de que no pueden usarse las constantes
difusas UNKNOWN, UNDEFINED y NULL con atributos difusos Tipo 1, excepto NULL con
el operador IS (caso 11) en el que NULL es entendido en el sentido que le da el SGBD y no en
el sentido difuso de Umano, Fukami et al. de [70] y [143]. En este caso, no se le puede poner
umbral de cumplimiento. Recordemos ademas, que en los casos 1, 5, 6 y 7 la parte derecha
224 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
Formato de la comparacion con el Funcion empleada
N comparador difuso generico FFF o FEQ (si es requerido) en la traduccion
1 fcol_t2 FFF [X,Y] FFF_inter
2 fcol_t2 FFF #Aprox FFF_aprox
3 fcol_t2 FFF $label FFF_trape
4 fcol_t2 FFF $[a,b,c,d] FFF_trape
5 fcol_t2 FFF crisp FFF_crisp
6 fcol_t2 FFF expr_crisp FFF_crisp
7 fcol_t2 FFF fcol_t1 FFF_crisp
8 fcol_t2 FFF fcol_t2 FFF
9 fcol_t2 FEQ UNKNOWN FEQ_UNKNOWN
10 fcol_t2 FEQ UNDEFINED FEQ_UNDEFINED
11 fcol_t2 FEQ NULL FEQ_NULL
12 fcol_t2 IS [NOT] (UNKNOWN|UNDEFINED|NULL) Comp. clasica del F_TYPE
13 fcol_t2 = 'CADENA' o fcol_t2 [NOT] LIKE 'CADENA' Comp. clasica: fshow2
Tabla 5.37: Funciones de comparacion difusa empleadas con atributos difusos Tipo 2.

de la comparacion es difuminada tal y como se explica en el apartado 5.2.1.9. En el caso 6 la


expresion crisp puede contener cualquier tipo de operador aritmetico (+, -, *...) y funciones
(ABS, SQRT, LEAST...).
Si la parte izquierda de una comparacion es crisp (caso de la Tabla 5.36) entonces los
comparadores de Necesidad obtienen identicos valores que sus homonimos de Posibilidad, por
lo que el Servidor FSQL solo implementa estos ultimos.
Con respecto a la Tabla 5.37, del Tipo 2, queremos hacer las siguientes aclaraciones en
algunos de sus casos:
 Casos 9, 10 y 11: Las comparaciones con estas constantes difusas solo pueden efectuarse
con el comparador FEQ.
 Caso 12: Es una comparacion clasica en la que se compara si el valor del Tipo del
atributo difuso es 0, 1 o 2, respectivamente para UNKNOWN, UNDEFINED o NULL.
Por tanto, no se le puede poner umbral de cumplimiento.
 Caso 13: En este tipo de comparaciones no difusas, lo que se pretende comparar es la
representacion del atributo difuso, que es visto como una cadena de caracteres (tipo
VARCHAR2) que debe compararse con la 'CADENA' indicada. Para conseguir la repre-
sentacion del atributo difuso se usa, como ya hemos indicado arriba (apartado 5.5.4.1),
la funcion fshow2 obteniendo los resultados de representacion de la Tabla 5.34. En el
apartado 5.4.1 se explica como conseguir esto.
Para los atributos difusos Tipo 3, con los que solo se puede usar el comparador FEQ, se ha
programado la funcion FEQ3 y algunas asociadas. En la Tabla 5.38 se muestran las funciones
empleadas cuando se utiliza un atributo difuso Tipo 3, <fcol_t3>, con el comparador difuso
FEQ. De esta tabla queremos matizar lo siguiente:

 Caso 1: Se utilizara una u otra funcion dependiendo de la longitud maxima de las


distribuciones de posibilidad sobre el atributo involucrado: Atributo LEN de la tabla
 DEL SERVIDOR FSQL
5.5. IMPLEMENTACION 225

Formato de la comparacion Funcion empleada


N con el comparador difuso FEQ en
 la traduccion
1 fcol_t3 FEQ $label
FEQ3 label LEN1 si LEN = 1
FEQ3 label otro caso
2 fcol_t3 FEQ fcol_t3 FEQ3
3 fcol_t3 FEQ (UNKNOWN|NULL) FEQ3_UNKNOWN_NULL
4 fcol_t3 FEQ UNDEFINED FEQ_UNDEFINED
5 fcol_t3 IS [NOT] (UNKNOWN|UNDEFINED|NULL) Comparacion clasica del F_TYPE
fcol_t3 = 'CADENA' o tambien
6 fcol_t3 [NOT] LIKE 'CADENA'
Comp. clasica: fshow3
fshow3 LEN1

Tabla 5.38: Funciones de comparacion difusa empleadas con atributos difusos Tipo 3.

FUZZY COL LIST. La funci on FEQ3_label_LEN1 solo existe para acelerar la comparacion
cuando todos los valores del atributo difuso son simples, caso que suponemos muy usual
en este Tipo de atributos difusos.
 Caso 4: Se utiliza la misma funcion que para Tipo 2 (FEQ_UNDEFINED), ya que tiene
identico sentido.
 Caso 5: Es una comparacion clasica en la que se compara si el valor del Tipo del valor
difuso es 0, 1 o 2, respectivamente para UNKNOWN, UNDEFINED o NULL. Por tanto,
no se le puede poner umbral de cumplimiento.
 Caso 6: En este tipo de comparaciones no difusas, lo que se pretende comparar es la
representacion del atributo difuso, que es visto como una cadena de caracteres (tipo
VARCHAR2) que debe compararse con la 'CADENA' indicada. Para conseguir la repre-
sentacion del atributo difuso se usa, como ya hemos indicado arriba (apartado 5.5.4.1),
la funcion fshow3 o fshow3_LEN1 (segun el valor de LEN) obteniendo los resultados de
representacion de la Tabla 5.35. En el apartado 5.4.1 se explica como conseguir esto.

5.5.5 Como Introducir Nuevos Comparadores Difusos en FSQL y su Ser-


vidor
Introducir nuevos comparadores difusos que funcionen en el Servidor FSQL no es una opera-
cion extremadamente complicada pero tampoco es trivial. Hay que modi car algunos paque-
tes y tablas del Servidor FSQL y probablemente tengamos que crear un nuevo paquete para
las funciones de comparacion difusa del nuevo comparador.
En sntesis, los pasos a seguir para introducir un nuevo comparador difuso son los siguien-
tes:
1. Cambiar la gramatica, incluida en el Apendice B:
(a) Introducirlo como palabra reservada.
(b) Introducir una produccion como las producciones de los otros comparadores difu-
sos: Producciones 232 a 238 y 501 a 507 de nuestra gramatica.
226 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
La gramatica utilizada se facilita en dos cheros con diferentes formatos: El chero
consulta.y, que contiene la gram atica en formato Yacc, tal y como aparece en el
Apendice B y el chero consulta.ag con formato del programa ag.
2. Comprobar si es LL(1): Esto se puede hacer facilmente con el programa ag, Analizador
de Gramaticas19 .
3. Modi car las tablas siguientes del Servidor FSQL:
(a) Introducir el nombre del comparador en la tabla RESERVADAS, tal y como estan los
otros comparadores difusos.
(b) A~nadir la produccion a la tabla PRODUCCIONES, tal y como estan introducidas las
otras producciones ya mencionadas.
(c) A~nadir a la tabla TABLA SINTAX las siguientes tuplas, donde <F_comp> es el nuevo
comparador difuso y <N_prod> es el numero de produccion del nuevo comparador:
('fcomparador', '<F_comp>', <N_prod>)
('resto_expr', '<F_comp>', 50)
('resto_col', '<F_comp>', 64)
('resto_col2', '<F_comp>', 70)
('resto_fcond', '<F_comp>', 218)
('resto_cond_elemental', '<F_comp>', 215)

4. A~nadir todas las funciones pertinentes al paquete FSQL FUNCTIONS2 o a otro paquete.
Tenga en cuenta que si un paquete es excesivamente largo puede dar problemas al
instalarlo en el Servidor Oracle.
5. Modi car el analizador semantico para incluir el nuevo operador: Esta es la fase mas
delicada y complicada de la operacion. Hay que modi car el paquete FSQL SEMANTIC
(sobretodo el procedimiento trata fuzzy column) cuidadosamente para no alterar el
funcionamiento de todo lo anterior. Para esto, conviene destacar los siguientes tipos de
comparadores difusos:
 Comparadores para atributos difusos Tipo 3: En la actualidad este Tipo de atri-
butos solo aceptan el comparador difuso FEQ y por eso, reciben un tratamiento
especial.
 Comparadores del tipo \Mucho Mayor/Menor que" (en su version de posibilidad
y necesidad): Estos comparadores necesitan la distancia del atributo MUCH de la
tabla FUZZY APPROX MUCH (M) por lo que en cada apartado son tratados indepen-
dientemente.
 El resto de comparadores son tratados a parte, pues son muy parecidos entre s,
con algunas salvedades ya indicadas anteriormente.
19 El programa ag (Analizador de Gramaticas) es un programa util para analizar gramaticas, indicando si la
gramatica que lee, en un chero .ag, es LL(1). Ademas, puede generar los Iniciales y los Seguidores de cada
smbolo no terminal. El programa ha sido desarrollado por Carlos Ure~na, profesor del Dpto. de Lenguajes y
Sistemas Informaticos de la Universidad de Granada, al cual le agradecemos desde estas paginas su amabilidad
al facilitarnos este programa.
5.6. MEJORAS POSIBLES AL SISTEMA FSQL 227

5.6 Mejoras Posibles al Sistema FSQL


El Servidor FSQL y el lenguaje en el que se basa disponen de una funcionalidad importante.
No obstante, como en cualquier otro programa, existen diversos aspectos en los que puede
mejorarse y/o ampliar su funcionalidad. Entre esos aspectos, destacan los siguientes, sepa-
rando entre mejoras al Lenguaje FSQL y mejoras al Servidor FSQL. Tanto unas como otras
deberan ser tenidas en cuenta en sucesivas versiones del Servidor FSQL.
5.6.1 Mejoras al Lenguaje FSQL
A continuacion, enumeramos una serie de mejoras que deberan tenerse en cuenta para mejorar
el Lenguaje FSQL. Por supuesto, todas las modi caciones a este lenguaje requieren modi car
tambien el Servidor FSQL para que este pueda trabajar con dichas modi caciones.
 Introducir nuevos comparadores difusos que operen con las distribuciones de posibili-
dad desde otros puntos de vista como, por ejemplo, el area en comun que tengan las
distribuciones de posibilidad. Ver apartados 5.5.4 y 5.5.5.
 Ampliar el lenguaje FSQL para que admita expresiones difusas para valores aproxima-
dos, con el signi cado de la Figura 5.4 (pagina 138), de acuerdo con el siguiente formato:

#<expr>

donde <expr> no tiene por que ser forzosamente un numero, sino que puede ser cual-
quier expresion crisp, incluyendo atributos crisp, atributos difusos Tipo 1, operaciones
y funciones aritmeticas, parentesis...
 Ampliar el lenguaje FSQL para que admita expresiones difusas para valores aproxima-
dos, con el signi cado de la Figura 5.4 (pagina 138), pero con un margen distinto del
almacenado en la FMB y expresado con <expr2>, de acuerdo con el siguiente formato:
#<expr1> +- <expr2>

donde <expr1> y <expr2> no tienen por que ser forzosamente numeros, sino que pue-
den ser cualquier expresion crisp, incluyendo atributos crisp, atributos difusos Tipo 1,
operaciones y funciones aritmeticas, parentesis...
 Ampliar el lenguaje FSQL para que admita expresiones para intervalos, con el signi cado
de la Figura 5.5 (pagina 138), de acuerdo con el siguiente formato:
[<expr1>,<expr2>]

donde <expr1> y <expr2> no tienen por que ser forzosamente numeros, sino que pue-
den ser cualquier expresion crisp, incluyendo atributos crisp, atributos difusos Tipo 1,
operaciones y funciones aritmeticas, parentesis...
 Ampliar el lenguaje FSQL para que admita expresiones difusas para trapecios, con el
signi cado de la Figura 5.2 (pagina 136), de acuerdo con el siguiente formato:
228 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
$[<expr1>,<expr2>,<expr3>,<expr4>]

donde <expr1>, <expr2>, <expr3> y <expr4> no tienen por que ser forzosamente
numeros, sino que pueden ser cualquier expresion crisp, incluyendo atributos crisp,
atributos difusos Tipo 1, operaciones, funciones aritmeticas, parentesis...
 Ampliar el lenguaje FSQL para que permita utilizar valores distintos de los especi cados
en la tabla FUZZY APPROX MUCH para los valores MARGEN y MUCH. Su sintaxis podra ser:
{ Comparadores que solo utilicen el MARGEN: Especi car el valor MARGEN tras el com-
parador, entre parentesis. Ejemplo:
Distancia FEQ(35) $[11,34,55,66]
{ En comparadores MGT/NMGT y MLT/NMLT, se deberan especi car ambos valores sepa-
rados por comas, primero el valor para MARGEN y luego, opcionalmente el valor para
MUCH. Si solo se desea especi car este ultimo, se puede dejar el primero en blanco.
O sea, el formato general, tras el comparador difuso sera: ([MARGEN][,MUCH]).
Ejemplos:
Distancia MGT(35) #888
Distancia MGT(35,88) #888
Distancia MGT(,88) #888

 Permitir efectuar comparaciones difusas sobre atributos \crisp", que ni siquiera han
sido declarados como difusos Tipo 1. Naturalmente, en este caso no podran utilizarse o
declararse etiquetas y se debe usar la sintaxis dada en el punto anterior si la comparacion
requiere los valores del MARGEN y/o del MUCH.
 Que se permita la inclusion de atributos y constantes difusas en expresiones aritmeticas,
excepto con los atributos difusos Tipo 3 y sus etiquetas. Ademas, estas expresiones
podran utilizarse en comparaciones que involucren comparadores difusos. Ver apartados
1.3.4.1 y 5.5.3.2.
 Que se puedan expresar constantes del tipo distribuciones de posibilidad sobre las etique-
tas de un atributo difuso Tipo 3. Por ejemplo, podran ponerse entre llaves, pudiendose
expresar el siguiente tipo de condiciones difusas:
Color Pelo FEQ f0,8/$Casta~no, 1/$Moreno g THOLD 0.75

 Que se permita el uso de modi cadores lingusticos (linguistic hedges ) como \muy" o
\poco", alterando as la distribucion de posibilidad que se indique tras el modi cador,
tal y como se indica en los apartados 1.3.3 y 2.9. Por ejemplo:
Salario FEQ $Muy $Normal THOLD 0.75

 Permitir establecer un valor N indicando que se recuperen las N mejores tuplas. Es decir,
limitar las tuplas del resultado por cantidad y no por un umbral de cumplimiento. Esta
caracterstica es incorporada por el lenguaje SQLf [22] (apartado 2.9.1). Por ejemplo,
la siguiente consulta selecciona solo las 11 tuplas (como maximo) que mejor satisfacen
la condicion impuesta (por eso el umbral es cero):
5.6. MEJORAS POSIBLES AL SISTEMA FSQL 229

SELECT[11] Jugador, CDEG(*)


FROM Equipos_Futbol
WHERE Num_Goles NFEQ $Muy_Alto 0;

Si se establece un umbral distinto de cero, la condicion es mas restrictiva, por lo que es


mas facil que se recuperen menos de 11 tuplas. Poniendo el umbral a cero en este tipo
de consultas, nos aseguramos que si no se obtienen 11 tuplas es que no hay mas tuplas
interesantes.
 Incluir en FSQL una sintaxis especial para especi car la division relacional difusa entre
dos relaciones difusas. Actualmente FSQL incorpora el mismo mecanismo que SQL
para aplicar la division relacional y este fue visto en el Ejemplo 5.22. Sin embargo,
con ese mecanismo no podemos obtener el grado con el que cada tupla cumple las
condiciones de la division, ya que esos grados son obtenidos en un SELECT interno
(subconsulta). Ademas, ese mecanismo no permite aplicar cuanti cadores difusos a la
division relacional. En el Captulo 3 se hace un estudio en profundidad de la division
relacional difusa en BDRD, proponiendo un sistema para efectuarla que incluye el uso
de cualquier tipo de cuanti cador difuso.

5.6.2 Mejoras al Servidor FSQL


El siguiente elenco de caractersticas son mejoras que deberan incorporarse en el Servidor
FSQL. Estas caractersticas no afectan al lenguaje FSQL en s, sino a la forma en que actual-
mente el Servidor FSQL trabaja y a algunas caractersticas del lenguaje FSQL que no han
sido implementadas aun.
 Incorporar las sentencias del DDL de FSQL, as como las restantes sentencias del DML
de FSQL (apartado 5.2 y Apendice B). Con esto, se pueden incorporar nuevos valores
en las tablas FSQL_ALL_INFO y FSQL_STATS (apartados 5.4.1 y 5.4.2) para, por ejemplo,
obtener estadsticas sobre el uso de cada sentencia.
 Incorporar un mecanismo para expresar la compatibilidad entre atributos difusos Tipo
1 o 2, con otros atributos difusos Tipo 1 o 2 (indistintamente), de similar forma a
como ya se hace con atributos difusos Tipo 3 con la tabla FUZZY COMPATIBLE COL. Con
atributos difusos Tipo 3 esa tabla era necesaria para poder compararlos entre s y para
evitar tener que rede nir las etiquetas para distintos atributos con igual dominio. En
el caso de atributos difusos Tipo 1 o 2 la utilidad de esa tabla queda restringida a
la segunda utilidad, pues ambos Tipos de atributos difusos son siempre comparables
entre s sin necesidad de especi carlo. Esto es muy util en la creacion de vistas con
atributos difusos, pues sin esto, al crear una vista, hay que copiar para esa vista todas
las etiquetas que tienen los atributos difusos de la tabla de la que proceden.
 Permitir el uso de cuali cadores sobre el umbral de cumplimiento de una condicion
difusa y tambien el uso de cuanti cadores difusos (absolutos y relativos). Ver apartados
5.1.2.3 y 2.9.2. Ambas opciones estan de nidas en el apartado 5.2.1.1, aunque, como no
han sido implementadas en el Servidor FSQL, no estan contempladas en la gramatica
del Apendice B.
230 CAPITULO 5. ARQUITECTURA DE LA BDRD: EL SERVIDOR FSQL
 Programar nuevas normas para ser utilizadas en el calculo de la funcion CDEG cuando
intervienen operadores logicos, de forma que un usuario no tenga que programar las nor-
mas mas usuales y que, para utilizarlas, solo tenga que modi car la vista FSQL OPTIONS,
como en el Ejemplo 5.28. Ver apartados 5.4.1 y 5.5.3.3.
 Permitir la escritura de condiciones difusas sin atributos difusos a la izquierda del com-
parador difuso. Ver apartado 5.5.3.2. Ademas, como se ha explicado en el apartado
anterior, sera deseable que se permitiera utilizar comparadores difusos entre expresiones
difusas (o no).
 Que la funcion CDEG se pueda emplear en cualquier posicion como una expresion cual-
quiera, y no exclusivamente en la lista de seleccion, tras SELECT.
 Incluir algun metodo de ordenacion de atributos difusos Tipo 2, para cuando se utiliza
un atributo difuso de este Tipo en la clausula ORDER BY. Ver apartado 5.4.1.
 De nir algunos triggers en el SGBD que ayuden a mantener la integridad de los atributos
difusos y de los valores de la FMB. Como se dijo en el apartado 5.5.4, esto evitara
inserciones de valores incorrectos en la base de datos, en la FMB y en las tablas del
Servidor FSQL (principalmente FSQL OPTIONS).
 Incorporar medidas de seguridad en las tablas de FIRST y del Servidor FSQL de forma
que un usuario no pueda consultar ni modi car los objetos, caractersticas u opcio-
nes de con guracion declaradas por otro usuario. Actualmente FIRST no almacena
informacion sobre propietario de cada objeto ni sobre permisos de acceso a ellos.
 Estudiar la migracion de todo o parte del Servidor FSQL del lenguaje PL/SQL a Java,
ya que Oracle 8i incorpora una maquina virtual Java y permite la programacion tanto en
PL/SQL como en Java de cualquier objeto, incluyendo triggers (disparadores). Tambien
incluye la sintaxis SQLJ para incluir codigo SQL en el codigo Java. Esto facilita la tarea
de utilizar el Servidor FSQL en otras bases de datos distintas de Oracle20 .
 Estudiar las ventajas y posibilidades que podra abrir el uso de objetos para de nir
los Tipos difusos y resolver consultas difusas en FSQL, aprovechando que la reciente
version Oracle 8 permite crear bases de datos orientadas a objetos.
 Incluir la posibilidad de efectuar consultas (aunque sean simples), en lenguaje natural
(ingles y/o espa~nol), al igual que ya incluye Microsoft SQL Server 7.0 para anglofonos
y para el lenguaje SQL. No obstante, el sistema que incluyen, aunque util, todava no
esta muy depurado y falta mucho por hacer.

20 Por otra parte, Oracle 8 incorpora un asistente para migrar facilmente a Oracle 8 bases de datos que no
sean Oracle (como Access, por ejemplo) o que sean de versiones anteriores de Oracle. Esta utilidad puede
ser muy util para aquellas empresas que disponen de una peque~na base de datos y que ven que su SGBD
se les queda peque~no y/o que deseen utilizar alguna de las aplicaciones que Oracle incorpora o que han sido
programadas para Oracle (como el Servidor FSQL)
Captulo 6
El Cliente FSQL
Como se indico en el apartado 5.3, el programa Cliente FSQL es el encargado de hacer de
interfaz entre el usuario y el Servidor FSQL. Este programa puede ser muy simple, pero es
muy importante pues va a permitir al usuario ejecutar sentencias difusas en FSQL (sin que
el usuario tenga por que saber como se accede al Servidor).
En este captulo veremos inicialmente cual es el objetivo basico y los posibles modos de
funcionamiento de un programa Cliente. Posteriormente, veremos con detalle como puede
programarse un Cliente FSQL de forma facil, empleando cualquier lenguaje que permita
acceso a bases de datos Oracle u ODBC (Open DataBase Connectivity, Conectividad Abierta
de Bases de Datos).
Nosotros hemos construido un Cliente FSQL para Windows 95/98/NT, llamado FQ.
En la ultima seccion se incluyen unos breves comentarios acerca de como esta construido
el \esqueleto" del programa FQ, es decir, las partes mas importantes y fundamentales del
mismo. En el Apendice G se incluye un manual de usuario de este programa.

6.1 Objetivo y Funcionamiento


El programa Cliente FSQL es el encargado de enviar la sentencia en lenguaje FSQL al Ser-
vidor FSQL y obtener de este los errores que contenga dicha sentencia (usando la funcion
FSQL2SQL). Si la sentencia no contiene errores, entonces el Cliente debe obtener del Servidor
dicha sentencia FSQL traducida a una sentencia SQL equivalente. Hecho esto, enviara la sen-
tencia SQL al SGBD y, en su caso, obtendra la respuesta y efectuara las acciones oportunas
con los resultados.
La relacion del programa Cliente FSQL con el Servidor FSQL es efectuada de forma
transparente al usuario, i.e, el usuario no tiene que conocer nada acerca del Servidor FSQL.
Las operaciones fundamentales que debera ejecutar el Cliente FSQL son:
1. Conexion al SGBD: En esta operacion el programa Cliente debe solicitar del usuario
su nombre de conexion (login ) y su clave de acceso (password ). Tras esto, intenta abrir
una sesion en el SGBD y, si se consigue, asigna un numero de sesion a la conexion
efectuada. Cada consulta mandada al Servidor FSQL esta identi cada por el numero
de sesion por lo que cada usuario puede establecer varias sesiones (conexiones) con el
SGBD y en todas ellas podra utilizar el Servidor FSQL. El numero de sesion puede
calcularse facilmente en Oracle usando la expresion:
231
232 CAPITULO 6. EL CLIENTE FSQL
USERENV('SESSIONID')

La caracterstica multiusuario del Servidor FSQL posibilita que el programa Cliente


FSQL pueda permitir el establecimiento de varias conexiones o que el mismo programa
pueda ejecutarse varias veces, estableciendo una conexion con cada una de ellas. Por
supuesto, cada conexion puede establecerse con distinto o igual nombre de usuario.
2. Edicion de la sentencia en FSQL: Este apartado puede variar enormemente de un
programa Cliente a otro. En el modo mas inmediato el usuario escribira la sentencia
en modo texto, con lo que el usuario debera conocer el lenguaje SQL y su extension a
FSQL. Tambien, el programa Cliente puede incluir formularios para realizar consultas
del tipo QBE (Query By Example ) de [173] o a traves de asistentes que van solicitando
paulatinamente, y de forma visual, los datos necesarios para la edicion de la sentencia.
Por supuesto, en determinados casos el programa Cliente podra tambien tener una o
varias sentencias \tipo" en las que solo tendra que pedir algunos datos al usuario.
3. Obtener y mostrar los errores (si los hay): Los errores encontrados son introducidos
por el Servidor FSQL en la vista FSQL ERRORS. Esta vista mantiene separados los errores
que se produzcan en cada sesion. Por supuesto, el programa Cliente puede efectuar \o -
line " un chequeo de la sentencia para ver si tiene errores lexicos o sintacticos, de forma
que no enve al Servidor FSQL sentencias erroneas lexica o sintacticamente. Para ello
el Cliente debera incorporar el analizador lexico y el sintactico. Ambos, son bastante
faciles de implementar, teniendo en cuenta lo que se ha explicado en los apartados 5.2,
5.5.1 y 5.5.2, as como la gramatica expuesta en el Apendice B. El analizador semantico
(apartado 5.5.3) tambien puede ser includo en el Cliente aunque esto ya no resulta ni
e ciente por los accesos a la base de datos, ni tan facil de implementar como los dos
anteriores. Este analisis \o -line ", aunque deseable para reducir los accesos al SGBD,
no solo no es indispensable sino que, si se incluye, debera poder ser desactivado ya que
el Servidor FSQL puede cambiar para acoger nuevos cambios del lenguaje FSQL y esto
no debera inutilizar el programa Cliente para utilizar las nuevas mejoras introducidas.
4. Obtener resultados, mostrarlos u operar con ellos: Una vez que se han obtenido
los resultados en el caso de una consulta, el programa Cliente debera operar con ellos de
alguna forma (grabarlos en disco, utilizarlos en otros calculos, mostrarlos en pantalla...).
Quizas la mas habitual sea mostrar los datos en pantalla e, igualmente, esta puede
efectuarse de varias formas, siendo las mas basicas las siguientes:
 Modo Fila: Cada la de la tabla resultante es mostrada en una ventana indepen-
diente con sus datos distribuidos en el espacio de esta. En este modo se contara
con las opciones tpicas de \Ver siguiente", \Ver anterior", \Ver primero", \Ver
ultimo"...
 Modo Tabla: Se muestra una tabla con los resultados de forma que caba columna
corresponde a un atributo de la consulta original. En este modo es util contar
con un \scroll " (o barra de desplazamiento) tanto horizontal como vertical, que
nos permita \movernos" por los datos de la tabla, modi cando la porcion de tabla
que es visualizada en cada momento. Este modo es el empleado en FQ que, como
se explica en su manual de usuario del Apendice G, incluye multitud de opciones
para ordenar por columnas, agrupar las o columnas con igual valor, cambiar el
 DE CLIENTES FSQL: OPERACIONES BASICAS
6.2. PROGRAMACION  233

tama~no de las y columnas, habilitar y deshabilitar la particion de palabras en


cada celda de la tabla...
5. Desconexion del SGBD: Esta operacion supone que no se van a efectuar mas ope-
raciones con el SGBD. En realidad esta operacion no es estrictamente necesaria y en
general, bastara con cerrar el programa Cliente. Si el programa Cliente puede seguir
usandose sin conexion esta desconexion puede signi car simplemente inhabilitar el uso
del SGBD hasta que se ordene una nueva conexion. El programa Cliente puede tambien
implementar una desconexion temporal, de forma que impida el uso del programa hasta
que no se introduzca la clave del usuario que inicio su ejecucion.
A grandes rasgos, los unicos requisitos que debe tener un lenguaje de programacion para
poder programar un Cliente FSQL en el son, que permita efectuar consultas en SQL sobre la
base de datos clasica y que permita ejecutar procedimientos almacenados en el SGBD.

6.2 Programacion de Clientes FSQL: Operaciones Basicas


A grandes rasgos ya se han visto en el apartado anterior los pasos que deben programarse
en un programa Cliente FSQL. En este apartado veremos mas a bajo nivel como se obtienen
los resultados a partir de una consulta FSQL correcta o los errores si es incorrecta. Tambien
veremos otras operaciones utiles para el usuario que utiliza una BDRD.
Para esto lo unico que se necesita es que el lenguaje de programacion elegido incorpore
formas de efectuar consultas en FSQL y llamadas a procedimientos almacenados. Esto se
puede hacer a traves de ODBC o usando algunos de los sistemas que Oracle proporciona,
como son los Oracle Objects (para Visual Basic, C++, Excell...). Oracle tambien proporciona
una herramienta de programacion, Developer 2000, que esta enfocada a crear aplicaciones de
Bases de Datos y que permite crear, entre otras opciones, codigo para Windows o codigo en
Java para ser utilizado en las paginas web (WWW) de Internet.
En el Apendice D se encuentran una lista de las funciones que vamos a utilizar a conti-
nuacion, todas ellas incluidas en el paquete FSQL PKG y pertenecientes al Servidor FSQL.
6.2.1 Ejecucion de Sentencias FSQL
Basicamente, el algoritmo a seguir es el siguiente, suponiendo que ya hayamos establecido la
conexion con el SGBD y que ya tenemos la sentencia en FSQL en una variable de tipo cadena
de caracteres1 (string ) denominada sentencia:
1. Llamar a la funcion FSQL2SQL del paquete FSQL PKG, para descubrir el numero de errores
de la sentencia:
Num Errores := FSQL PKG.FSQL2SQL(sentencia);

2. Si encontramos errores (Num Errores>0) los mensajes de error correspondientes se en-


cuentran en la campo Msg error de la vista FSQL ERRORS, uno tras otro ordenados por
el campo Indice en orden de aparicion. En el Apendice C hay una lista con todos los
posibles mensajes de error, sus posibles causas y sus posibles soluciones.
1 Como se ha indicado, una sentencia FSQL puede incluir comentarios dentro de la sentencia y puede estar
formada por varias lneas, todas en la misma variable de tipo cadena.
234 CAPITULO 6. EL CLIENTE FSQL
3. En caso de que no haya errores, la sentencia SQL resultante estara almacenada en la
vista FSQL QUERY y sera obtenida concatenando el campo Atributo en el orden que
indique el campo Indice. Al concatenar se debe incorporar un espacio en blanco entre
cada dos valores consecutivos del campo Atributo. Aunque no es necesario, este espacio
se puede omitir, por delante y por detras, cuando el campo Atributo tiene longitud
1 y este caracter vale uno de los siguientes caracteres: `+', `-', `*', `/', `.', `;', `,', `=',
`>', `<', `(' y `)'. Eliminar ese espacio cuando sea posible no es obligatorio, pero puede
convenir hacerlo para ahorrar espacio (en grandes sentencias) y sobretodo para que la
sentencia resultante quede mejor formateada si va a ser mostrada.
Esta concatenacion para obtener la sentencia SQL puede ser efectuada directamen-
te por el programa Cliente FSQL o puede tambien efectuarse a traves de la funcion
FSQL concat del Servidor FSQL:

Sentencia SQL := FSQL PKG.FSQL concat;

Esa funcion devuelve una cadena del tipo VARCHAR2 de Oracle, por lo que esta limitada
a la longitud maxima que le asigne Oracle (32767 caracteres) y si supera esa longitud la
funcion devuelve NULL. Esto supone un problema si la sentencia SQL resultante supera
esa longitud maxima.
4. Una vez obtenida la sentencia SQL resultante, el Cliente FSQL debera enviar esta
sentencia al SGBD como si se tratara de una sentencia normal en SQL. Si la sentencia
es una consulta, se deberan recuperar los resultados de la misma.
5. Cuando se ha terminado de ejecutar sentencias FSQL se debe llamar al procedimiento
FSQL FIN, borrando los datos temporales que ya no son u tiles. Este procedimiento no
tiene argumentos ni devuelve ningun dato. Esta operacion no hay que efectuarla tras
cada sentencia FSQL sino una unica vez, al nal.
Puede resultar util que el programa Cliente FSQL incorpore opciones para ver la consulta
SQL resultante, para mandar consultas SQL sin pasar por el Servidor FSQL o para ver la
consulta FSQL si esta fue formada de forma visual o semiautomatica.
6.2.2 Ver las Etiquetas De nidas para un Atributo Difuso
Dado un atributo difuso con su esquema o propietario SCH, el nombre de la tabla a la que
pertenece TBL y su nombre de columna COL, podemos ver que etiquetas hay de nidas para
dicho atributo y su de nicion, siguiendo el siguiente algoritmo:
1. Calcular el numero de Objeto de la tabla: Puede usarse la funcion FSQL OBJ y
asegurarse de que es distinto de cero (objeto no existe):
NOBJ# := FSQL PKG.FSQL OBJ (SCH,TBL);

2. Calcular el numero de la columna: Puede usarse la funcion FSQL COL:


NCOL# := FSQL PKG.FSQL COL (SCH,TBL,COL);
 DE CLIENTES FSQL: OPERACIONES BASICAS
6.2. PROGRAMACION  235

3. Si NCOL#=0 quiere decir que dicha columna no existe con ese nombre, o sea, esa columna
no es ni crisp ni difusa Tipo 1. Entonces, pasaremos a comprobar si es difusa Tipo 2 o
3 comprobando si existe a~nadiendo una 'T' al nombre de la columna. Si vuelve a salir
cero entonces, de nitivamente, dicha columna no existe en la tabla:

NCOL# := FSQL PKG.FSQL COL (SCH,TBL,COL||'T');

4. Calcular el Tipo difuso del atributo: Una vez calculados los numeros identi cativos
de la tabla y el atributo, hay que calcular el Tipo difuso de este, lo cual puede hacerse
usando la funcion FSQL FTYPE:

F TYPE := FSQL PKG.FSQL FTYPE (NOBJ#,NCOL#);

5. Si F TYPE=0 indica que la columna no es difusa por lo que no puede tener etiquetas
de nidas sobre su dominio.
6. Obtener las etiquetas segun su Tipo difuso:
 Tipos 1 o 2 (F TYPE=1 OR F TYPE=2): Se puede obtener una tabla con los datos
buscados usando la vista LABELS FOR OBJCOL a traves de su sinonimo publico LFOC:

SELECT Label, Alfa, Beta, Gamma, Delta


FROM LFOC
WHERE OBJ# = NOBJ# AND
COL# = NCOL#;

donde Label es el nombre de la etiqueta y el resto de las columnas seleccionadas


corresponden a los valores de nidos para el trapecio de esa etiqueta: $[ , , ,].
 Tipo 3 (F TYPE=3): Se puede obtener una tabla con todas las etiquetas de nidas
para un atributo difuso Tipo 3 y el grado de similitud entre cada par de ellas,
usando la vista LABELS OBJCOL T3 a traves de su sinonimo publico LOCT3:
SELECT Label_1, Label_2, Degree
FROM LOCT3
WHERE OBJ# = NOBJ# AND
COL# = NCOL#;

donde Label 1 y Label 2 son los nombres de sendas etiquetas y Degree es el grado
de similitud entre ellas.
6.2.3 Ver el MARGEN y la Distancia MUCH
Estos datos son directamente consultables utilizando la tabla FUZZY APPROX MUCH a traves de
su sinonimo publico FAM. Previamente hay que hallar los numeros identi cativos de la tabla y
el atributo (NOBJ#,NCOL#), tal y como hemos hecho en el apartado anterior y luego utilizar
la siguiente consulta:
236 CAPITULO 6. EL CLIENTE FSQL
SELECT MARGEN, MUCH
FROM FAM
WHERE OBJ# = NOBJ# AND
COL# = NCOL#;

6.2.4 Ver Atributos Difusos Tipo 3 Compatibles y sus Longitudes


Para ver esta informacion de forma clara se puede usar la vista ALL COMPATIBLES T3 a traves
de su sinonimo publico ACT3, la cual tiene las siguientes columnas:
 Columna_1: Nombre de la columna que es compatible con la siguiente y que, por tanto,
no tiene de nidas etiquetas sobre ella.
 Length_1: Longitud maxima para las distribuciones de posibilidad que podremos al-
macenar en la columna anterior.
 Compatible_Con_Columna_2: Nombre de la columna que tiene de nidas las etiquetas,
las cuales tambien usara Columna_1.
 Length_2: Longitud maxima para las distribuciones de posibilidad para la segunda
columna.
6.2.5 Ver si estan Instalados los Paquetes del Servidor FSQL
Esta operacion puede ser util para ver si esta instalado el Servidor FSQL, aunque, como se
ha visto, el Servidor FSQL esta formado por otros elementos, aparte de los paquetes. En
general, puede suponerse que si estan instalados los paquetes, esta instalado todo lo demas,
ya que, en el proceso de desistalacion se borran todos los elementos del Servidor y no solo los
paquetes.
Los paquetes del Servidor FSQL pueden verse en la Tabla 5.29. Si <Nombre_Pkg> es el
nombre de uno de los paquetes, para ver si esta o no instalado hay que efectuar la siguiente
consulta para leer el estado del paquete:
SELECT Status
FROM ALL_OBJECTS
WHERE Object_Name='<Nombre_Pkg>' AND
Object_Type='PACKAGE';

Despues, debe comprobarse que el estado (Status) del paquete en cuestion es 'VALID'.
6.2.6 Ver Funciones que Aplica CDEG para los Operadores Logicos
Esta operacion es tan simple como efectuar las siguientes 3 consultas, correspondientes a cada
operador logico:
SELECT FUNCTION FROM FSQL_OPTIONS WHERE OPCION = 'NOT'
SELECT FUNCTION FROM FSQL_OPTIONS WHERE OPCION = 'AND'
SELECT FUNCTION FROM FSQL_OPTIONS WHERE OPCION = 'OR'

Si alguna de las anteriores consultas no obtiene ninguna tupla, se aplicaran las funciones
por defecto, expuestas en las Tablas 5.13 y 5.33.
 DE FQ, UN CLIENTE FSQL
6.3. PROGRAMACION 237

6.2.7 Acceso a Informacion sobre el Servidor FSQL, Estadsticas y otras


Opciones de Con guracion
Esto se hace accediendo normalmente a la tabla FSQL STATS, y a las vistas FSQL INFO y
FSQL OPTIONS, del Servidor FSQL. Ademas, esta ultima vista puede ser tambien modi cada
por el usuario para alterar algunas opciones de con guracion.
En los apartados 5.4.1 y 5.4.2 se explican esos objetos y la informacion que contienen.

6.3 Programacion de FQ (Fuzzy Queries), un Cliente FSQL


Como complemento del Apendice G, en el que se incluye un manual de usuario del programa
FQ, aqu vamos a esbozar unas nociones sobre como esta construido este programa, a nivel
de programacion, en sus operaciones mas importantes.
El Cliente FQ ha sido programado en Visual Basic 5.0 de Microsoft [18, 48, 124] y por
tanto los fragmentos de codigo que exponemos en este apartado estan en este lenguaje2 .
Observese que los comentarios en ese lenguaje empiezan por un apostrofe (').
FQ accede a Oracle a traves de los Oracle Objects para OLE (Objects Linking and Em-
beding ), que son una coleccion de objetos programables que simpli can el desarrollo de apli-
caciones que necesitan comunicarse con Oracle. Entre los objetos que dispone se encuentran
los siguientes:
 OraClient: Este objeto de ne un Cliente de Oracle y gestiona un conjunto de objetos
OraSession.
 OraSession: Este objeto de ne una sesion de trabajo con Oracle y gestiona un conjunto
de objetos OraDatabase.
 OraDatabase: Este objeto representa una unica conexion (login ) a una base de datos
Oracle. Contiene el metodo DbExecuteSQL que es el que hay que usar para ejecutar un
procedimiento almacenado en el SGBD. Antes de efectuar la llamada a DbExecuteSQL
hay que a~nadir (Add) los parametros del procedimiento a ejecutar a la lista de parametros
de este objeto (propiedad Parameters) indicando su valor y si son de entrada o salida.
Tras la llamada hay que eliminarlos (Remove).
 OraDynaset: Este objeto representa las las y columnas que devuelve una consul-
ta SELECT. Para cada consulta hay que crear un objeto de este tipo con la funcion
DbCreateDynaset. Su propiedad Fields devuelve la colecci on de campos para la -
la actual (empezando por la primera). Un objeto OraDynaset tiene un conjunto de
metodos para \moverse" por la tabla recuperada y establecer en cada momento la la
actual que se desee (MoveFirst o DbMoveFirst, MoveLast o DbMoveLast, MovePrevious
o DbMovePrevious, MoveNext o DbMoveNext, MovePreviousn, MoveNextn, MoveRel,
MoveTo...).
 OraParameter: Este objeto representa una variable de una sentencia SQL o de un
bloque PL/SQL que esta ligada a una variable del programa. La propiedad Parameters
2 Dentro de esos fragmentos de codigo, algunas cadenas de caracteres, entre comillas dobles, han sido partidas
en varias lneas por motivos de claridad. Esto pudiera causar errores de compilacion si estos fragmentos se
prueban tal y como son mostrados. Para evitar esos errores basta con eliminar los retornos de carro en las
cadenas de caracteres.
238 CAPITULO 6. EL CLIENTE FSQL
del objeto OraDatabase es una coleccion de objetos de este tipo y cuenta con los metodos
Add y Remove para a~
nadir y borrar parametros respectivamente.
 OraField: Este objeto representa una columna independiente dentro de una la de un
objeto OraDynaset.
Con estos objetos, podemos efectuar las operaciones basicas que vimos en los apartados
6.1 y 6.2, teniendo en cuenta que en FQ la consulta FSQL es introducida directamente por
el usuario en un recuadro de texto (objeto RichTextBox).
1. Conexion al SGBD: En la conexion se crean los objetos necesarios para el resto de
operaciones con Oracle:
Set OraSession = CreateObject("OracleInProcServer.XOraSession")
Set OraDatabase = OraSession.DbOpenDatabase(DatabaseName, Connect$, 0&)

donde:
CreateObject es una funcion para crear objetos OLE donde su argumento es una
cadena de caracteres en la que se introduce la aplicacion que produce el objeto y
el tipo de objeto a crear, separados por un punto.
OracleInProcServer es el nombre de la aplicaci on que produce el objeto a crear.
XoraSession es el tipo de objeto dentro de la aplicaci on que lo produce.
Connect$ es la cadena de conexi on formada por el nombre de usuario (login ) y su clave
de acceso (password ) separados por el caracter /.
DatabaseName es el nombre de la base de datos y debe ser introducida por el usuario
al igual que su nombre y clave. Puede usarse la cadena 2: para referirse a la base
de datos local.
2. Llamar a la funcion FSQL2SQL para descubrir el numero de errores de la consulta (va-
riable Num_Errores):
'A~
nadir par
ametros: NUMERRORES (de salida: 2) y SELECT_CMD (de entrada: 1)
OraDatabase.Parameters.Add "NUMERRORES", 0, 2
OraDatabase.Parameters("NUMERRORES").ServerType = ORATYPE_NUMBER
OraDatabase.Parameters.Add "SELECT_CMD", ConsultaFSQL, 1
OraDatabase.Parameters("SELECT_CMD").ServerType = ORATYPE_VARCHAR2

'Ejecutar la funci
on
OraDatabase.DbExecuteSQL (
"declare NUMERRORES number(4);
Begin :NUMERRORES:=FSQL_PKG.FSQL2SQL (:SELECT_CMD); end;")

'Capturar valor de salida


Num_Errores = OraDatabase.Parameters("NUMERRORES")

'Eliminar par
ametros
OraDatabase.Parameters.Remove "NUMERRORES"
OraDatabase.Parameters.Remove "SELECT_CMD"
 DE FQ, UN CLIENTE FSQL
6.3. PROGRAMACION 239

3. Si no hubo errores hay que componer el resultado de la traduccion, lo cual se hace en


la variable ConsultaSQL:

Dim consultaSQL As String


Dim valor As String
Dim anterior_sin_esp As Boolean

...

'Componer resultado de la tabla FSQL_QUERY


Set SQLDynaset = OraDatabase.DbCreateDynaset( _
"SELECT ATRIBUTO FROM FSQL_QUERY
WHERE ATRIBUTO IS NOT NULL AND SESSIONID=USERENV('SESSIONID')
ORDER BY INDICE", ORADYN_READONLY)
consultaSQL = SQLDynaset.Fields("atributo").Value
SQLDynaset.DbMoveNext

' No meter espacios ni antes ni despu


es de determinados caracteres
anterior_sin_esp = False
Do While SQLDynaset.EOF <> True
valor = SQLDynaset.Fields("atributo").Value
ch1 = Left(valor, 1) 'Tomamos el primer caracter
If anterior_sin_esp Or _
(Len(valor) = 1 And _
(ch1 = "," Or ch1 = "." Or ch1 = "=" Or _
ch1 = ";" Or ch1 = "-" Or ch1 = "+" Or _
ch1 = "(" Or ch1 = ")" Or _
ch1 = "/" Or ch1 = "*" Or _
ch1 = ">" Or ch1 = "<")) Then
consultaSQL = consultaSQL & valor
anterior_sin_esp = Not anterior_sin_esp
Else
consultaSQL = consultaSQL & " " & valor
End If
SQLDynaset.DbMoveNext
Loop

La concatenacion para formar la sentencia SQL resultante puede ser efectuada por la
funcion FSQL concat, que devuelve un valor de tipo VARCHAR2. Esta funcion puede
emplearse tras una llamada a FSQL2SQL sin que se detecten errores. Sin embargo, como
ya se ha dicho, debido a las limitaciones del tipo de datos VARCHAR2, esta operacion
solo sera valida si la sentencia SQL resultante tiene menos de 32767 caracteres (caso
normal). En caso de que la sentencia SQL sea de una longitud mayor se devuelve el
valor NULL. El programa Cliente FSQL debera comprobar ese caso para formar el
mismo la sentencia. Para eliminar esa comprobacion, FQ forma siempre la sentencia
internamente, tal y como se ha visto.
4. Si hubo errores se pueden calcular con la siguiente consulta, accediendo a cada la, igual
que en la consulta anterior, utilizando la propiedad Fields y los metodos para cambiar
la la actual:
240 CAPITULO 6. EL CLIENTE FSQL
Set ErrorDynaset = OraDatabase.DbCreateDynaset(
"SELECT INDICE,MSG_ERROR
FROM FSQL_ERRORS
WHERE SESSIONID=USERENV('SESSIONID')
ORDER BY INDICE", 0&)

5. Una vez obtenida la consulta SQL, FQ la enva al SGBD como si se tratara de una
consulta normal en SQL, creando de nuevo un objeto de tipo OraDynaset:
Set SQLDynaset = OraDatabase.DbCreateDynaset(consultaSQL, ORADYN_READONLY)

Los resultados de esta consulta son cargados en un objeto de tipo MSFlexGrid, que es
un objeto de tipo tabla de datos (grid, parrilla).
6. Para nalizar la sesion se ejecuta FSQL FIN,:
OraDatabase.DbExecuteSQL ("Begin FSQL_PKG.FSQL_FIN; end;")

En todo momento se hace una gestion de los posibles errores que puedan cometerse. Si
estos errores se producen en una operacion con el SGBD entonces, en el atributo LastServer-
ErrText tendremos el texto del error cometido y en el atributo LastServerErr el numero de
dicho error. Ambos atributos pertenecen a los objetos OraSession y OraDatabase.

6.4 Cliente FSQL Visual en Java


Actualmente se esta desarrollando un programa Cliente FSQL en Java, para poder editar
consultas visualmente. El programa se esta desarrollando, en calidad de proyecto n de
carrera de la Ingeniera Superior en Informatica de la Universidad de Malaga, por el alumno
R.F. Oliva, siendo el Director de dicho proyecto el autor de esta memoria.
El objetivo de este programa es triple:
1. Que pueda consultarse una base de datos (tradicional o difusa) a traves de consultas
(tradicionales o difusas), sin que el usuario necesite conocer ni el lenguaje SQL ni su
extension FSQL. Por supuesto, el programa permitira la ejecucion de sentencias escritas
directamente en estos lenguajes.
2. Que el programa pueda ser ejecutado a traves de Internet o cualquier Intranet empresa-
rial. Por este objetivo es por lo que se ha optado por Java como lenguaje de programa-
cion, siendo as el programa independiente de cualquier plataforma (Windows, Unix...),
siempre que se disponga de una \maquina virtual Java".
3. Que el programa pueda ser ejecutado como una aplicacion independiente. As, en este
modo de ejecucion no se tienen las limitaciones en cuanto a seguridad que impone la
utilizacion de applets.
Se han utilizado las bibliotecas JDBC de Java para acceso a Oracle. En concreto, se han
utilizado los drivers \oci8" para la aplicacion independiente y \thin" para los applets Java.
6.4. CLIENTE FSQL VISUAL EN JAVA 241

Figura 6.1: Ventana asistente de un Cliente FSQL Visual.

Al elegir la opcion para la creacion de una nueva consulta a traves del \Asistente Visual
FSQL" se mostrara una ventana (Figura 6.1) en la que indicaremos los datos que queremos
que aparezcan en la relacion de salida. Todo esto se hace de forma que el usuario no necesite
escribir nada, sino simplemente a base de \clicks" de raton. A grandes rasgos el procedimiento
es como sigue:

1. Elegir la tabla (o vista) de las que se van a obtener los datos de la consulta.
2. Elegir los atributos de la misma que van a a~nadirse a la lista de seleccion, o sea, los
que apareceran en la consulta nal. Estos atributos pueden aparecer con o sin expre-
siones con constantes y/o atributos, incluyendo llamadas a funciones (como CDEG). Las
expresiones mas complicadas que la simple aplicacion de una funcion se dispone de un
recuadro de texto donde se forma la expresion hasta que se pulsa un boton \A~nadir a
Seleccion", que introduce la expresion formada en la lista de valores a mostrar.
3. Repetir los pasos anteriores con todas las tablas que contengan datos que deseemos
consultar.
242 CAPITULO 6. EL CLIENTE FSQL
4. Ordenar las expresiones de la lista de seleccion en el orden en el que queramos que
aparezcan. Esto se hace marcando las expresiones de las que se desee alterar su posicion
y pulsando a continuacion los botones para \Subir" o \Bajar".
5. Pulsar el boton adecuado dependiendo de lo que deseemos hacer a continuacion: Mandar
consulta como FSQL o como SQL, Cancelar la consulta o seguir formando la consulta.
Esta ultima opcion nos lleva a otra ventana para formar las condiciones (clausula WHERE)
de la consulta actual, tambien de forma visual.
Esta aplicacion tambien dispone de todas las opciones que tiene el programa FQ (Apendice
G), para consulta de etiquetas, compatibilidad entre atributos, ver relaciones de similitud,
informacion sobre la conexion y sobre las opciones de con guracion del Servidor FSQL, ar-
chivar el resultado de una consulta... Asimismo, permite tener \abiertas" varias consultas a
la vez para comparar resultados o copiar datos de una a otra.
Captulo 7
Algunas Aplicaciones del lenguaje
FSQL
7.1 Clasi cacion Difusa de Imagenes de una Base de Datos
En [8] se mostraron algunos resultados sobre la clasi cacion exible y automatica de un objeto
segun su forma, la cual es obtenida a partir de una imagen 2D del mismo. El objeto es repre-
sentado usando un conjunto de caractersticas obtenidas a partir de la curva de curvaturas
del contorno del objeto. Estas caractersticas, almacenadas en una base de datos, pueden ser
tratadas como difusas o crisp y, a partir de aqu, es posible realizar la clasi cacion usando
el lenguaje de consulta difuso FSQL (Fuzzy SQL) visto anteriormente (apartado 5.2). Las
de niciones de las posibles clases pueden estar tambien almacenadas en una BDRD.

7.1.1 Introduccion al Problema


En la industria es frecuente encontrar procesos en los que es conveniente poder clasi car
distintos objetos a partir de una imagen captada, por ejemplo, con una camara fotogra ca o
de vdeo.
Para realizar esta clasi cacion utilizamos una representacion del objeto que se basa ex-
clusivamente en la informacion del contorno del mismo, es decir en su forma exterior, la cual
es una de las caractersticas principales de todo objeto. La caracterizacion nal se consigue
de niendo un conjunto de atributos que pueden tomar valores difusos y extrayendo las ca-
ractersticas concretas para cada gura. Por caracterstica difusa entendemos aquellas que
denotan imprecision y que pueden tener signi cados no exactos para el ser humano, como por
ejemplo, el tama~no de un objeto puede ser grande, peque~no, mediano... Ademas de permitir
realizar una clasi cacion exible, la representacion que proponemos reduce la dimensionali-
dad de la caracterizacion con lo que el metodo puede ser util en aplicaciones donde existen
restricciones de tiempo.
Este metodo de clasi cacion es valido en entornos donde los objetos son claramente iden-
ti cables por su forma. Por ejemplo, puede ser usado para la clasi cacion en tiempo real de
objetos que circulan en una cinta transportadora y que son visualizados desde una camara
situada en una posicion ja. Tambien se puede aplicar en la clasi cacion de objetos en una
base de datos en la que contamos con una imagen de cada uno de ellos.
Esta clasi cacion puede orientarse en dos sentidos:
243
244 CAPITULO 7. ALGUNAS APLICACIONES DEL LENGUAJE FSQL
 Clasi car los objetos atendiendo a su forma general: Es aplicable a distinguir, por
ejemplo, los distintos tipos de se~nales de tra co para conduccion automatica.
 Clasi car los objetos en varias clases propias y particulares al sistema: Este sen-
tido es mas general pero requiere una fase de aprendizaje despues de la cual es sistema
conozca el conjunto de clases posibles en las que poder clasi car cada objeto. La repre-
sentacion de cada clase se realiza tambien de niendo un conjunto de atributos difusos
a partir de una forma generica.
La clasi cacion es llevada a cabo a traves de consultas difusas en FSQL teniendo las
caractersticas de las clases almacenadas en una base de datos. El almacenamiento de estas
caractersticas de un objeto determinado, en la base de datos, puede efectuarse \on-line".
Las aplicaciones de este metodo pueden ser diversas, entre las que podemos destacar la
automatizacion industrial (identi cacion de piezas en lneas de ensamblado, inspeccion de
piezas defectuosas o con fallos...) o clasi cacion de imagenes en una base de datos.
A continuacion explicamos en detalle el proceso en los siguientes apartados: En primer
lugar damos una idea del metodo para la representacion de la forma de un objeto. Luego, a
partir de esa forma obtenemos caractersticas que pueden representarse como atributos difusos
de la BDRD y con esos atributos podremos realizar la clasi cacion nal.
7.1.2 Representacion de la Forma de un Objeto
El primer paso importante es el de aislar el objeto que se pretende caracterizar dentro de una
imagen generica 2D de niveles de gris1 . El proceso de segmentacion para conseguir subdividir
la imagen en sus partes constituyentes es una tarea compleja dentro del procesamiento de
imagenes [91]. En general, la eleccion del metodo depende de la naturaleza de las imagenes
con las que se trabaje. Nosotros vamos a suponer que la imagen de entrada ya contiene un
unico objeto que es el que vamos a representar. Por ejemplo, si se toman imagenes de los
objetos que pasan por una cadena de montaje (con fondo liso) o si se tienen almacenadas en
una base de datos y se pretenden clasi car.
7.1.2.1 La Curva de Curvaturas a la Escala Mas Signi cativa
Para representar el objeto presente en la imagen asumimos que toda la informacion necesaria
para ello esta en la curva que de ne su contorno. De este modo, en un primer paso la gura
va a ser caracterizada utilizando una funcion o curva de curvatura calculada sobre el contorno
digital del objeto. El contorno digital es una secuencia de puntos adyacentes consecutivos
que no se intersectan y que de nen la frontera de un objeto. Se calcula conectando los puntos
frontera obtenidos con un algoritmo de extraccion de bordes (metodos basados en el gradiente
[91] o metodos basados en la energa local [112, 113]).
El contorno de un objeto va a ser representado usando su forma parametrica (p(t) =
(x(t); y(t)) para un parametro t que indica la posicion del punto dentro del contorno. De
esta forma se usan dos funciones x(t) e y(t) para especi car cada punto a lo largo de la curva
desde el punto inicial hasta el punto nal.
Sea K = fk(t)jt = 1; : : : ; ng la curva de valores de curvatura calculada a partir del
contorno digital C = f(x(t); y(t))jt = 1; : : : ; ng. Los valores de la curva de curvaturas K
1 Se opta por imagenes en niveles de gris pues reduce la complejidad del problema y, en este caso, la
informacion de color no es necesaria, ya que nos basamos en su forma exclusivamente.
 DIFUSA DE IMAGENES
7.1. CLASIFICACION  DE UNA BASE DE DATOS 245
0.9

0.8

0.7

0.6

0.5

0.4

0.3

0.2

0.1

-0.1
0 100 200 300 400 500 600 700 800

(a) (b)
Figura 7.1: (a) Contorno de un nematodo. Se se~nalan los puntos caractersticos en el orden en que
se calcula la curvatura. (b) Curva de curvatura a la escala mas signi cativa. El pico mas pronunciado
corresponde al punto 4 de (a) y el mas a la izquierda al punto 1.

determinan una representacion unidimensional de una curva plana. Esta se~nal unidimensional
constituye un descriptor util para la extraccion de la forma de un contorno, de forma que en
los puntos de una parte recta de un contorno la curvatura es nula y en una parte curva del
contorno, la curvatura sera mayor (en valor absoluto) cuanto mas peque~no sea el radio de esa
curva. El signo del valor de la curvatura indica el sentido de la curva (concava o convexa).
En [8, 66, 67, 81, 110] pueden verse mas detalles sobre el calculo de la curvatura.
La Figura 7.1(a) muestra el contorno de un objeto, en este caso particular representa el
contorno de un nematodo2 . Mostramos en 7.1(b) la curva de curvaturas suavizada a la escala
mas signi cativa. La escala mas signi cativa para una curvatura es el \nivel" de suavizado
con el que se obtiene con menor ruido de cuantizacion. Este ruido deriva de que un contorno
de una imagen digital no puede ser continuo, sino que es un contorno digital, debido a que el
angulo entre pxeles vecinos solo puede variar en incrementos de 45o . De ah, que la gra ca
7.1(b) sea tan ondulante, aunque, con la escala signi cativa, se reduce mucho ese \ruido".

7.1.3 Deteccion de Caractersticas Propias


La curva de curvaturas va a ser utilizada para detectar las caractersticas propias de la -
gura y as conseguir la representacion de nitiva. Se pretende que estas caractersticas nos
permitan representarla para posteriormente identi carla o clasi carla dentro de un conjunto
determinado.
Para ello seleccionamos un conjunto de puntos importantes del contorno, a los que llama-
mos puntos caractersticos, que son aquellos puntos con valores de curvatura, tanto positivos
como negativos, que sobresalen de los demas. El signo indica si el punto pertenece a una
parte concava o convexa del contorno y depende del sentido en el que este ha sido calculado.
En nuestro caso siempre se calcula el contorno a partir del punto mas alto de la gura en la
imagen 2D y siguiendo el contorno en sentido contrario a las agujas de un reloj. Por tanto,
la curvatura tambien esta calculada en este orden para cada punto del contorno.
Suponemos que los valores de curvatura siguen una distribucion Normal de media cero y
varianza 2 , N (0; 2 ). La varianza muestral se calcula:
2 Gusano de cuerpo liforme o cilndrico, no segmentado, desprovisto de apendices locomotores y general-
mente parasito, como la lombriz intestinal.
246 CAPITULO 7. ALGUNAS APLICACIONES DEL LENGUAJE FSQL

X
N
2 = N1 (ki km )2 (7.1)
i=1
P
donde km es la media de los valores de curvatura (km = N1 Ni=1 ki ) y N es el numero de
puntos del contorno.
Los puntos que vamos a considerar importantes para la caracterizacion de la forma, los
puntos caractersticos, van a ser puntos outliers de la anterior distribucion. Es decir, un
punto pi es considerado un punto caracterstico del contorno bajo consideracion si el valor de
su curvatura ki veri ca que

ki 62 ( ; +) (7.2)


donde  va a ser usada para de nir el grado de curvatura de un determinado punto. O sea,
lo importante no es el valor de curvatura exacto de esos puntos, sino su comparacion con
el resto de puntos. As,  indicara como de grande es la curvatura y esa informacion puede
codi carse en distintas etiquetas lingusticas difusas: Por ejemplo, Alto, Medio o Bajo grado
de curvatura. Estas etiquetas estan asociadas a distribuciones de posibilidad como muestra
la Figura 5.2. Hemos considerado solo tres etiquetas posibles, pero este numero puede variar
para adaptarse a cada aplicacion particular. Estas etiquetas son importantes para un posterior
tratamiento ya que permiten exibilizar la clasi cacion y deben de nirse cuidadosamente.
Generalmente los puntos que forman parte del entorno de un punto caracterstico tambien
tienen un alto valor de curvatura. Solo se considera punto caracterstico el maximo local de
cada subgrupo de puntos outliers de la distribucion.
La distribucion de estos puntos va a identi car el tipo de contorno. Tambien se tiene en
cuenta la distancia relativa entre cada dos puntos caractersticos, calculada como el numero
de puntos del contorno que hay entre dos de ellos con respecto al numero total de puntos
del contorno. De esta manera podemos distinguir, por ejemplo, guras de forma cuadrada de
guras de forma rectangular.
Por tanto, la forma del objeto es representada como un conjunto de puntos caractersticos.
Cada uno de ellos mantiene informacion sobre el signo de la curvatura, el grado de curvatura
(relativo al valor absoluto de la misma como se ha descrito anteriormente) y la distancia del
punto anterior a ese punto. Para el primero la distancia sera tomada con respecto al ultimo
(un objeto siempre tiene un contorno cerrado).
Ejemplo 7.1 Consideremos unos objetos cuya forma del contorno es cuadrada (Figura 7.2(a)),
pentagonal irregular (Figura 7.2(c)) o triangular (Figura 7.2(e)). Estos contornos simples
muestran claramente el calculo de los puntos caractersticos. En la Figura 7.2 (b), (d) y (f)
se muestran las curvas de curvaturas calculadas como en [8]. Se puede observar que para el
contorno pentagonal los puntos de la lnea recta inferior tienen una curvatura constante pero
los otros dos lados tienen mucha variacion en su curvatura a pesar de tratarse tambien de
lneas rectas. Esto es debido, como se ha mencionado antes, al ruido de cuantizacion, ya que
se tiene que representar el angulo continuo entre puntos vecinos como un angulo discreto (0o ,
45o , 90o ...). En el triangulo esto no ocurre porque al calcular la curvatura se ha suavizado
mas el contorno. tu
 DIFUSA DE IMAGENES
7.1. CLASIFICACION  DE UNA BASE DE DATOS 247

0.25

0.2

0.15

0.1

0.05

-0.05
0 100 200 300 400 500 600 700

(a) 0.25
(b)
0.2

0.15

0.1

0.05

-0.05
0 50 100 150 200 250 300 350 400 450

(c) 0.3
(d)
0.25

0.2

0.15

0.1

0.05

-0.05
0 50 100 150 200 250 300 350 400

(e) (f)
Figura 7.2: Contornos de guras y curvas de curvatura asociadas, a la escala mas signi cativa
para cada contorno.
248 CAPITULO 7. ALGUNAS APLICACIONES DEL LENGUAJE FSQL
7.1.4 Clasi cacion, segun las Caractersticas de cada Imagen
Una vez extrado el conjunto de puntos caractersticos a partir del contorno digital de la
imagen de un objeto, procedemos a su clasi cacion. Para ello, tenemos en cuenta, segun lo
visto anteriormente, los siguientes atributos basicos del contorno:
1. Numero de puntos caractersticos: Naturalmente, el numero de vertices (esquinas)
de un contorno es una caracterstica basica del mismo.
2. Signo del valor de la curvatura en cada vertice: Esto nos permite, como se
ha dicho anteriormente, ver si el contorno sigue una trayectoria concava o convexa.
En realidad, la importancia de esto esta en la distribucion de signos entre los vertices
hallados.
3. Distancia entre vertices: Calculada como distancia relativa a la distancia total, nos
permite distinguir entre guras distintas pero que tengan igual numero de vertices e
igual distribucion de signos en su curvatura. Por ejemplo, entre un cuadrado y un
rectangulo. Estas distancias nos impiden distinguir entre objetos identicos pero con
distinto tama~no o distinta distancia a la camara. Si en un contexto particular eso fuera
interesante, tendramos que utilizar para ello otra caracterstica que indicara el tama~no
global del contorno.
4. Grado de curvatura de cada punto: Esto es calculado usando el valor absoluto de
la curvatura en cada vertice y nos permite distinguir entre vertices muy puntiagudos
y vertices poco puntiagudos. A cada punto se le asocia una etiqueta lingustica para
facilitar la clasi cacion, ya que, como hemos dicho, no nos interesa el valor exacto en
s, sino con respecto al resto de valores.
En determinados ambientes, el modelo puede ser ampliado para considerar otras carac-
tersticas de los objetos (crisp o difusas), como por ejemplo el color o el tama~no (que podra
ser obtenido a partir del contorno del objeto).
Esta clasi cacion se puede efectuar de dos modos, segun el tipo de guras (o formas) que
deseemos clasi car, aunque el segundo tipo incluye las del primero:
7.1.4.1 Clasi cacion de Figuras Geometricas
En muchos entornos podemos encontrar que las guras a clasi car son, en general, geometricas
(mas o menos regulares) o que realmente no sabemos nada sobre las clases posibles.
Estudiando las caractersticas anteriores se puede llegar a una conclusion sobre el tipo
de gura que tenemos. As, por ejemplo, si tenemos un contorno con 3 vertices de igual
signo estamos ante una gura triangular. Las otras dos caractersticas nos informan sobre
el tipo concreto de triangulo. Por ejemplo, si la distancia entre los vertices y el grado de
curvatura en ellos es similar, el triangulo sera equilatero. De igual modo, si un vertice posee
mayor grado que los otros dos y ademas esta a mayor distancia de los otros dos que estos
entre s, entonces el triangulo sera tipo isosceles. Esto es extensible a cualquier tipo de gura
geometrica, incluidas, por ejemplo las guras estrelladas (cuya caracterstica esencial es que
vara el signo de cada vertice alternativamente).
Para la comparacion de estos valores es preferible hacerlo de forma exible, ya que son
parametros bastante variables. Para ello, podemos usar el lenguaje FSQL, en la forma que
se indica en el siguiente apartado.
 DIFUSA DE IMAGENES
7.1. CLASIFICACION  DE UNA BASE DE DATOS 249

7.1.4.2 Clasi cacion de Figuras Complejas


En este caso queremos clasi car guras que no tienen una forma geometrica de nida. Para
ello debemos obtener una relacion de las clases de guras que el sistema puede encontrar.
Esto dependera de cada aplicacion concreta.
Cada una de las clases debera ser de nida dando valores a las 4 caractersticas de nidas
anteriormente. Si consideramos valores concretos para ellas, sera, probablemente, muy difcil
hacer una buena clasi cacion pues es muy probable que el objeto de entrada no se acople de
manera exacta a los parametros de nidos para una clase. Sin embargo, este acoplamiento
aunque no sea exacto si puede ser aproximado, por lo que para ello introducimos el uso de
atributos difusos.
Todas las caractersticas menos el signo pueden ser tratadas como atributos difusos, esto
es, en cada una podemos de nir etiquetas lingusticas difusas (ver Figura 5.2). As, por
ejemplo, podemos considerar que una gura pertenece a una clase si tiene \aproximadamente
5 vertices", con todos positivos, \aproximadamente 3 vertices grandes" y con los vertices
situados \aproximadamente" a la misma distancia.
Si estas caractersticas de nuestras guras las almacenamos en una BDRD (Base de Datos
Relacional Difusa), entonces, esta puede ser consultada usando el lenguaje de consulta difuso
FSQL.
Con una consulta FSQL podramos obtener todas las guras de la base de datos que
pertenecen a una determinada clase. Ademas, con FSQL podemos obtener tambien un grado
(entre 0 y 1) que nos indica en que medida una gura pertenece a una clase. La idea es aplicar
una consulta del tipo de la dada en el siguiente ejemplo:
Ejemplo 7.2 Supongamos que tenemos una tabla Objetos que contiene las caractersticas
de multitud de objetos extraidas de una imagen del objeto. La consulta para seleccionar
aquellos objetos que son triangulos isosceles o similares tendra el siguiente formato:
SELECT Imagen#, CDEG(*)
FROM Objetos
WHERE NumVertices = 3
AND Signo1 = 'P' AND Dist1 FEQ $Grande 0.8 AND GradoK1 FEQ $Grande 0.7
AND Signo2 = 'P' AND Dist2 FEQ $Grande 0.8 AND GradoK2 FEQ $Normal 0.7
AND Signo3 = 'P' AND Dist3 FEQ $Pequenna 0.8 AND GradoK3 FEQ $Normal 0.7;
tu
Dependiendo del contexto en el que nos encontremos, es posible que la gura pueda estar
girada cierto grado. Para contemplar esta posibilidad habra que efectuar mas comparaciones,
entre cada dos vertices (o puntos signi cativos) correlativamente, manteniendo el orden.
Por otra parte, si el numero de vertices es variable, el esquema de la base de datos debera
ser diferente: Una tabla para las caractersticas generales de cada objeto, sin indicar las
caractersticas de sus vertices y otra tabla para almacenar las caractersticas de los vertices
de todas las guras.
Otra posibilidad es almacenar en una tabla de la base de datos las caractersticas de todas
las clases posibles. Entonces, clasi car una gura concreta sera consultar dicha tabla usando
las caractersticas de esta gura en la condicion de la consulta.
Uno de los puntos mas importantes del metodo es de nir las clases apropiadamente. En
este sentido, es posible ense~nar al sistema la de nicion de cada clase o que el mismo deduzca
250 CAPITULO 7. ALGUNAS APLICACIONES DEL LENGUAJE FSQL
tanto el numero de clases como sus caractersticas haciendo uso de tecnicas de Data Mining
extrayendo la informacion de una base de datos que contenga ejemplos de imagenes concretas
para la aplicacion. Entre estas tecnicas podemos destacar el algoritmo de clustering difuso
C-means [16].

7.2 Data Mining con FSQL en un Entorno Financiero


En [34, 35] presentamos un metodo para insertar el uso del lenguaje de consulta difuso FSQL
como una tecnica mas de Data Mining, incluyendo como ejemplo un sistema de clasi cacion y
clustering difuso aplicado a los clientes de una entidad nanciera3. El uso de FSQL hace que
el proceso de extraccion de informacion (Data Mining) pueda ser evaluado a nivel practico y
no solo teorico.
Concretamente, usamos FSQL para efectuar consultas que obtengan determinados objetos
(tuplas) con caractersticas similares, esto es, objetos de un determinado grupo o conjunto.
Las caractersticas sobre las que se actuaran y los valores de estas son obtenidos previamente
por un proceso de segmentacion, aplicando el prototipo DAPHNE, desarrollado por Carrasco
[33, 35]. El uso de FSQL nos evita tener que usar algoritmos de clasi cacion y ademas, la
clasi cacion es efectuada en tiempo real. De esta forma podemos tambien tratar como difusos
los clusters obtenidos a traves de algoritmos no difusos.
En este apartado daremos primero una vision global del Data Mining como un conjunto
de tecnicas orientadas a obtener conocimiento implcito (no explcito) que sea de interes a
partir de los datos existentes en la base de datos. Se incluye una clasi cacion de las tecnicas
de Data Mining segun el tipo de conocimiento a descubrir. Ademas, se quiere hacer notar las
caractersticas que hacen del Data Mining un campo de investigacion autonomo y de interes
por s mismo, en el que se aplican tecnicas de otros campos.
Posteriormente, resumimos las caractersticas y utilidad de DAPHNE, explicamos el uso
de FSQL para clustering difuso y exponemos algunos resultados experimentales obtenidos.
7.2.1 Data Mining como A rea Independiente
Se puede de nir Data Mining como el proceso de extraccion de informacion de interes a
partir de los datos. Segun [68], el Data Mining persigue descubrir conocimiento que sea
nuevo, potencialmente util y de un calculo no trivial:
 Nuevo: Esta caracterstica del conocimiento depende del marco de referencia que se
tome. As, si un sistema descubre \si un cliente es culpable de un accidente entonces
tiene una edad mayor de 17 a~nos". Para el sistema puede ser una informacion nueva
pero para un usuario que este analizando reclamaciones de seguros es algo obvio.
 U til: El conocimiento es util cuando puede ayudar a conseguir un objetivo del sistema
o del usuario. Retomando el ejemplo anterior, si el sistema descubre \si un cliente es
culpable de un accidente entonces es probable que sea hombre", esta informacion es
potencialmente util a ese usuario y/o al sistema.
 No trivial: Un sistema se considera no trivial si posee algun grado de autonoma en
el procesamiento de los datos y evaluacion de los resultados. Los sistemas de bases de
3 Este trabajo esta parcialmente subvencionado por el Gobierno Espa~nol, bajo el proyecto TIC97-0931, y
por la \Caja General de Ahorros de Granada".
7.2. DATA MINING CON FSQL EN UN ENTORNO FINANCIERO 251

datos convencionales son capaces de obtener informacion desconocida (no explcita) y


de gran utilidad como, por ejemplo, el total de saldo en cuentas de clientes en el a~no
1997, pero que su obtencion no puede ser considerado como un proceso de Data Mining
ya que su calculo se puede considerar trivial.
Existe, por tanto, un cierto consenso entre diversos autores [39, 68, 151] en la de nicion
de Data Mining como el proceso de extraccion de informacion implcita, no trivial, previa-
mente desconocida y potencialmente util (por ejemplo, reglas de conocimiento, restricciones
y regularidades) a partir de los datos de una base de datos.
Se podra pensar que este campo de Data Mining no tiene personalidad propia, esto es, que
esta integrado en otros como el de Sistemas de Aprendizaje (Machine Learning ), Estadstica
o Sistemas de Gestion de Bases de Datos (SGBD). Si bien es cierto que Data Mining se
aprovecha de dichas tecnicas, existen una serie de caractersticas de Data Mining, a parte de
las ya enumeradas, que lo rea rman como un area independiente [68, 151]:
 Lenguaje de alto nivel: El conocimiento descubierto debe ser representado en un
lenguaje de alto nivel que, aunque no tiene porque ser lenguaje natural, s debe ser
comprensible por usuarios no expertos. En este sentido, cada vez son mas tpicos los
entornos de usuario gra cos y/o la posibilidad de representacion del conocimiento de
multiples formas o vistas. Ademas, esta caracterstica de representacion ultimamente
se ha ampliando no solo al conocimiento descubierto (resultado) sino tambien a las pe-
ticiones del mismo (entradas del usuario), que pueden ser expresadas como \consultas",
expresadas en un lenguaje de alto nivel o a traves de entornos gra cos.
 Precision: El conocimiento descubierto debera retratar de forma precisa los conteni-
dos de la base de datos. Las \imperfecciones" (ruido, datos excepcionales) deberan ser
expresadas con medidas de incertidumbre. Por otro lado, el uso de estas medidas im-
plica la necesidad de un estudio sistematico de las medidas de calidad del conocimiento
descubierto.
 E ciencia: El proceso de extraccion de conocimiento debe ser e ciente y los tiempos de
ejecucion sobre grandes cantidades de datos deben ser predecibles y aceptables cuando
se traten grandes cantidades de datos. Como consecuencia de esto, los algoritmos que
use el sistema deben ser escalables a la gran cantidad de datos que, en de nitiva, van a
manejar.
 Manejo de diferentes tipos de datos: Al existir diferentes tipos de datos y bases
de datos en diversas aplicaciones (datos relacionales, objetos, hipertexto...) sera dese-
able que un sistema Data Mining realizara su trabajo de una forma efectiva sobre esta
diversidad de datos. Sin embargo, parece difcil construir un sistema que gestione todos
los tipos de datos, incluyendo los tipos difusos (apartado 5.1.2.1).
 Extraccion interactiva de conocimiento en multiples niveles de abstraccion:
El descubrimiento interactivo de conocimiento puede permitir al usuario re nar on-line
la extraccion de conocimiento, el enfoque y la profundidad del mismo. Ademas, debera
ser posible ver los datos y resultados de Data Mining en diferentes niveles de abstraccion
o desde diferentes angulos.
252 CAPITULO 7. ALGUNAS APLICACIONES DEL LENGUAJE FSQL
 Extraccion de informacion desde diferentes fuentes de datos: Actualmente es
un gran reto la extraccion de conocimiento desde diferentes fuentes de datos. Estos datos
pueden estar formateados o no, y pueden tener diversas semanticas. Esta caracterstica
esta alentada por las cada vez mas amplias y accesibles redes de ordenadores (inclu-
yendo Internet y las Intranets). Como consecuencia surge la necesidad de algoritmos
distribuidos y paralelos en Data Mining.
 Proteccion y privacidad de datos: Ver los datos desde diferentes angulos y niveles
de abstraccion puede ir en contra de la privacidad por lo que surge el tema, interesan-
te de estudio, de medidas de seguridad para prevenir descubrimiento de informacion
\sensible". Sirva de ejemplo [68] la controversia que provoco en EE.UU. una campa~na
publicitaria de tabaco que era dirigida a hombres, negros y jovenes, ya que la empresa
haba distinguido este per l como el mas susceptible de consumir su producto. Esta
caracterstica, como es obvio, puede ser opuesta a algunas de las descritas y debera ser
tenida muy en cuenta.
Sin embargo, algunos autores [90] remarcan la falta de identidad de Data Mining, de
tal forma que cali can los sistemas actuales como de primera generacion, caracterizados por
el uso e ciente de algoritmos de Machine Learning en grandes bases de datos bajo SGBD
tradicionales. Segun esto, hay una necesidad creciente de alcanzar la segunda generacion de
sistemas Data Mining para bases de datos, en la que el descubrimiento de informacion este
totalmente integrado y optimizado en el sistema, llegando a ser lo que se ha llamado como
Sistema de Gestion de Conocimiento y Descubrimiento de Informacion (Knowledge and Data
Discovery Management System, KDDMS). Probablemente, en las proximas decadas habra
una evolucion hacia esta clase de sistemas.
El termino Data Mining (DM) o, traduciendo literalmente Minera de Datos, ha sido usado
[39, 151] como equivalente a otros como Descubrimiento de Informacion y Conocimiento (Kno-
wledge and Data Discovery, KDD), Minera del Conocimiento en Bases de datos (Knowledge
Mining from Databases ), Extraccion del Conocimiento (Knowledge Extraction ), Arqueologa
de la Informacion (Data Archaeology ), Analisis de Datos (Data Analysis ), Rastreo de In-
formacion (Data Dredging )... Sin embargo, numerosos autores posteriores distinguen entre
Data Mining y Knowledge Discovery. As, en [27] los autores reducen el signi cado de Data
Mining a la aplicacion de procedimientos o algoritmos para revelar patrones de conocimien-
to novedoso o para veri car hipotesis desarrolladas en etapas previas. Segun esto, el Data
Mining debera integrarse dentro del campo de Knowledge Discovery, que sera mucho mas
amplio y consistira en etapas de procesamiento previas y posteriores al Data Mining. Como
etapas previas estaran la obtencion de datos, la limpieza de datos, su integracion y chequeo,
desarrollo de hipotesis... Como etapas posteriores al Data Mining podran estar el chequeo y
la veri cacion del conocimiento descubierto, la interpretacion y uso de este conocimiento...
Sin embargo, los nombres de Data Mining y Knowledge Discovery son normalmente usados
como sinonimos y nosotros los usaremos indistintamente en este estudio.

7.2.2 Tecnicas de Data Mining


Existen diversas formas de clasi car las tecnicas de Data Mining, como son por el tipo de
base de datos sobre la que trabajan (relacional, transaccional, orientada a objetos...), por el
tipo de tecnicas utilizadas (estadsticas, extraccion basada en patrones en generalizacion...)
7.2. DATA MINING CON FSQL EN UN ENTORNO FINANCIERO 253

y por el tipo de conocimiento que va a ser extrado. Segun este ultimo criterio, que es el mas
usual, las tecnicas de Data Mining se dividen principalmente en [39, 68, 151]:
Extraccion de Reglas de Asociacion: Se trata de descubrir asociaciones importantes
entre los valores de conjuntos de atributos, de tal manera que la presencia de cualquier valor
de algun conjunto en un elemento de la base de datos (registro, tupla...) implique la presencia
de otro valor que pertenezca a otro conjunto.
Por ejemplo, se puede descubrir en una base de datos transaccional que determinado
valor de un atributo implica otro valor de un segundo atributo, en las transacciones. De esta
manera, si la base de datos es de ventas de artculos de camping, un sistema puede llegar a
descubrir que las personas que compran un saco de dormir suelen adquirir tambien una tienda
de campa~na.
Estos procesos de extraccion de reglas pueden suponer el estudio repetitivo de grandes
bases de datos con el objeto de encontrar diferentes patrones de asociacion por lo que son
necesarios algoritmos muy e cientes. Como ejemplos de algoritmos tenemos los populares
Apriori, DHP y PARTITION. Existen tambien algoritmos sobre bases de datos distribuidas
como DMA [40].
Generalizacion de datos a nivel multiple, resumen y caracterizacion: Estas he-
rramientas de analisis y extraccion de datos son las mas extendidas, esto es, existen muchos
productos comerciales que las soportan. La generacion y resumen de datos muestra las ca-
ractersticas generales o una vista resumida de alto nivel sobre un conjunto de datos (de bajo
nivel) especi cados por el usuario dentro una base de datos. Frecuentemente es deseable
presentar vistas generalizadas de los datos en multiples niveles de abstraccion. Existen dos
enfoques principales de generalizacion:
1. El enfoque del cubo: La idea general es materializar ciertos calculos costosos que se
piden con frecuencia, especialmente aquellos que implican funciones de agregacion (su-
mas, medias, desviacion tpica...) y almacenar estas vistas materializadas en una base
de datos \multidimensional" que se denomina cubo de datos. Estas vistas pueden servir
para soporte de decision, descubrir conocimiento, o cualquier otra aplicacion. Las fun-
ciones de agregacion pueden ser precalculadas agrupandolas por diferentes conjuntos de
atributos. Este enfoque tiene algunos nombres alternativos, as como algunas variantes
como pueden ser \bases de datos multidimensionales", \vistas materializadas" y OLAP
(On-Line Analytical Processing ).
2. El enfoque orientado a la induccion de atributos: Se puede considerar a este
enfoque como una generalizacion del anterior donde la consulta usada es mas general que
una simple clausula de agrupamiento. El nucleo de esta tecnica es el uso de una losofa
on-line en la que la generalizacion de datos se realiza conforme a las distribuciones
de valores de atributos en un conjunto concreto de datos relevantes. Se obtiene una
relacion generalizada o cubo (de nitivo o temporal) que puede usarse para obtener mas
conocimiento interesante en un proceso de Data Mining interactivo.
Segmentacion, Agrupamiento o Clustering: La segmentacion es la tecnica de identi -
cacion de patrones de interes dentro de los llamados \algoritmos de descubrimiento" [68]. De
forma breve, consiste en agrupar registros u objetos en clases que re ejen patrones inherentes
254 CAPITULO 7. ALGUNAS APLICACIONES DEL LENGUAJE FSQL
a los datos. Son metodos muy tradicionales que provienen de la Taxonoma Matematica. La
idea basica consiste en de nir algun tipo de \distancia" entre los elementos de la base de
datos usando algunos de sus atributos y obtener grupos (clusters) de elementos maximizan-
do la distancia entre los distintos grupos y minimizandola entre los elementos de un mismo
grupo. Las distancias usadas frecuentemente no son Eucldeas e incluso no son distancias en
el sentido matematico sino que son medidas de \semejanza".
Estos metodos de segmentacion clasicos tienen el inconveniente de no poder usar alguna
informacion adicional que se pueda tener tal y como la forma de los grupos. La Segmentacion
Conceptual [109] intenta evitar tales problemas. Estos metodos trabajan con datos estructu-
rados (como bases de datos espaciales) y determinan los grupos no solo por la similitud entre
atributos sino que tambien por la coherencia conceptual.
Uno de los algoritmos de segmentacion mas populares es el llamado C-means (C-medias) o
su variante difusa Fuzzy C-means [16], el cual caracteriza cada grupo con los valores centrales
de cada una de las caractersticas (atributos) usadas en el proceso. Recientemente se han
investigado algoritmos aplicables a grandes cantidades de informacion especialmente en el
ambito concerniente a las bases de datos. Ejemplos de estos algoritmos son el algoritmo
CLARANS (Clustering Large Applications based upon Randomized) basado en dos algoritmos
de segmentacion estadsticos (PAM y CLARA) y el algoritmo BIRCH (Balanced Interative
Reducing and Clustering). Tambien se han desarrollado mecanismos para la segmentacion
interactiva, la cual combina la habilidad del usuario humano con el poder de calculo del
ordenador.

Clasi cacion: La clasi cacion es la segunda parte dentro de los \algoritmos de descubri-
miento" [68], ya que no es su ciente obtener un conjunto de grupos (segmentacion) sino que
tambien es necesario \describirlos" por medio de las variables usadas. Es mas, el verdadero
objetivo es obtener un proceso de clasi cacion que nos permita incluir cada nuevo elemento
en el correspondiente grupo conforme a los valores de sus atributos.
La clasi cacion ha sido ampliamente estudiada en el contexto de sistemas de aprendizaje,
as una de las tecnicas de clasi cacion que mas exito han tenido en Data Mining en la llamada
\sistema de aprendizaje ID-3". Tambien se han intentado otros enfoques como los basados
en redes neuronales, estadsticos y basados en los conjuntos rough, introducidos por Pawlak
en 1982 [121, 122].

7.2.3 DAPHNE: Un Prototipo para Clustering Financiero


Para nuestros propositos, hemos usado el prototipo DAPHNE [33, 35], desarrollado por Ca-
rrasco en 1998. Este prototipo es parte de un proyecto de investigacion conjuntamente con la
entidad nanciera \Caja General de Ahorros de Granada". El objetivo es la segmentacion o
clustering de una base de datos de clientes que permita efectuar un tratamiento diferenciado
a los clientes (como marketing directo, por ejemplo).
DAPHNE es una herramienta generica para clustering enfocada a entornos nancieros o
bancarios. El prototipo usa tecnicas de distintas areas: Clustering jerarquico, aprendizaje
no supervisado basado en herramientas de conjuntos difusos, tecnicas de SGBD y tecnicas
estadsticas. Ademas de los requisitos espec cos del problema, el prototipo ha sido dise~nado
considerando las funcionalidades deseables para sistemas Data Mining, ya mencionadas ante-
riormente:
7.2. DATA MINING CON FSQL EN UN ENTORNO FINANCIERO 255

 Manejo de diferentes tipos de datos: En el problema en particular, se consideran


tres tipos de datos para el clustering: Numerico, binario y escalar. El binario puede
tomar dos unicos valores extremos (como verdadero y falso por ejemplo). Los escalares
permiten tomar un valor de entre un conjunto nito de valores y ademas entre cada
dos valores posibles existe una relacion que mide la distancia entre ellos. La combi-
nacion de estos tres tipos de datos para procesos de clustering es novedosa entre las
implementaciones de este tipo de sistemas.
 Extraccion de informacion desde diferentes fuentes de datos: DAPHNE es
exible para manejar datos de distintos SGBD (a traves de ODBC).
 E ciencia y extraccion interactiva de conocimiento: DAPHNE ha sido dise~nado
para ser interactivo con el usuario y dar la respuesta, con la particion de la poblacion,
en tiempo real.
 Precision: El uso del metodo clasico de Benzecri para obtener la jerarqua de clases
garantiza la bondad de la particion. El procedimiento para obtener una buena particion,
basado en conjuntos difusos, tambien ha obtenido excelentes resultados en las pruebas
efectuadas.
 Interfaz amigable: El inferfaz de DAPHNE es gra co y dise~nado para su facil utili-
zacion. Asimismo, el prototipo gestiona una meta-base de datos de tal modo que para
el usuario sea facil y rapida la gestion de un proyecto de segmentacion.
7.2.3.1 Funcionamiento de DAPHNE
Como primer paso para el sistema de clustering de DAPHNE se deben escoger los atributos de
los clientes relevantes para el clustering. Esto es efectuado por un ingeniero del conocimiento
experto en sistemas nancieros. Para esta seleccion el usuario puede utilizar un metodo que
ha sido desarrollado para seleccion automatica de atributos importantes, basado en algoritmos
geneticos [100].
As pues, el usuario inserta un nuevo proyecto para clustering en la meta-base de datos
del prototipo, especi cando la tabla o vista que contiene los datos (datos de ejemplo) y los
atributos que DAPHNE utilizara para el clustering. El usuario no necesita especi car nada
para atributos con dominios numericos o binarios. Si surgen atributos escalares, el usuario
debera incluirlos en la meta-base de datos, especi cando la lista de valores posibles y dando
una medida de distancia (inversa a una relacion de similitud) entre cada dos de ellos, teniendo
en cuenta la siguiente de nicion:
De nicion 7.1 Una funcion d(xi ; xj ) que mide la \distancia" (en algun sentido) entre dos
elementos de un determinado dominio U , se dice que es una medida de distancia si cumple
lo siguiente:
1. d(xi ; xj )  0 8xi; xj 2 U
2. d(xi ; xj ) = 0 si y solo si xi = xj
3. d(xi ; xj ) = d(xj ; xi )
4. d(xi ; xj )  d(xi ; xk ) + d(xk ; xj ) (Desigualdad triangular)
256 CAPITULO 7. ALGUNAS APLICACIONES DEL LENGUAJE FSQL
donde xi ; xj ; xk 2 U . tu
Una vez introducidos los datos necesarios para el funcionamiento de DAPHNE, las etapas
de su funcionamiento son las siguientes:
1. Normalizacion: El principal objetivo de esta etapa es hacer posible la comparacion
entre atributos para simpli car los procesos posteriores. Los atributos numericos son
escalados al intervalo [0,1], los binarios son convertidos al conjunto f0,1g y los valores de
atributos escalares son cambiados por un codigo que esta almacenado en la meta-base
de datos.
2. Calculo de la matriz de distancias ultrametrica de la poblacion: Desde los
resultados de Dunn, Zadeh y Bezdek, representados en [55, 148], se sabe que existe una
equivalencia entre clustering jerarquico, relacion difusa transitiva max-min y distancias
ultrametricas. Por tanto, en la matriz ultrametrica se especi can todas las posibles
segmentaciones que pueden efectuarse sobre la poblacion. El dendrograma o diagrama
de arbol puede ser visto como un diagrama para la representacion de los resultados del
clustering jerarquico que es efectuado en terminos de matriz de distancias. Este proceso
contiene los siguientes tratamientos:
 Calcular la matriz de distancias de la poblacion: Para cada par de individuos
de la poblacion la distancia que separa a ambos es obtenida por la media de las
distancias obtenidas entre los distintos tipos de atributos (numericos, binarios y
escalares):
{ La distancia entre atributos numericos se obtiene como la media entre las
distancias Eucldeas de los valores normalizados.
{ La distancia entre atributos binarios se obtiene a traves de la medida de simi-
litud de Sokal y Michener sobre los atributos binarios normalizados [65].
{ La distancia entre atributos escalares se obtiene como la media de todas las
distancias calculadas a partir de la relacion de distancias especi cada por el
usuario y contenida en la meta-base de datos de DAPHNE.
As, si en el universo U hay n elementos, la matriz de distancias resultante sera
una matriz cuadrada simetrica de n  n, en la que los elementos de la diagonal
principal son todos ceros. En esta matriz de distancias cada tres elementos xi , xj
y xk veri can la desigualdad triangular.
 Calcular la matriz de distancias ultrametrica: La matriz obtenida en el paso ante-
rior es transformada de tal forma que para cualesquiera tres elementos, la distancia
entre ellos cumpla tambien la desigualdad ultrametrica [65], tambien llamada
condicion de Bourbaki (del nombre de su autor):
d(xi; xj )  maxfd(xi ; xk ); d(xk ; xj )g
Puede observarse que la desigualdad ultrametrica es una propiedad mas fuerte
que la desigualdad triangular. Para obtener la matriz de distancias ultrametrica
a partir de la matriz de distancias DAPHNE usa el metodo de Benzecri [15, 87],
aunque existen otros metodos.
7.2. DATA MINING CON FSQL EN UN ENTORNO FINANCIERO 257

3. Calcular los posibles -cortes4 : Como la matriz ultrametrica es nita, contiene solo
un conjunto nito de valores diferentes. As, para el clustering jerarquico o la matriz
ultrametrica podemos determinar inequivocamente el conjunto de todos los posibles
-cortes diferentes, esto es, el conjunto de todas las posibles relaciones de equivalen-
cia asociadas con la matriz. En otras palabras, cada -corte implica una particion o
clustering diferente sobre la poblacion.

Ejemplo 7.3 Supongamos un universo U con 6 elementos f1,2,3,4,5,6g, con la matriz


de distancias D de la que se obtiene, usando el metodo de Benzecri, la matriz de
distancias ultrametrica D0 :
00 7 6 7 6 7
1 00 6 6 6 6 6
1
BB 0 5 2 5 6 C
C B
B 0 5 2 5 5 C
C
D=B
B 0 6 1:5 2 C
C B
=) D = B
0 0 5 1:5 1:5 C
C
BB 0 7 5 C
C B
B 0 5 5 C
C
@ 0 1 A @ 0 1 A
0 0
Con esos datos podemos obtener los siguientes -cortes, donde los Gi son los distintos
grupos obtenidos de cada -corte:
 =0 =) G1 =f1g, G2 =f2g, G3 =f3g, G4 =f4g, G5 =f5g y G6 =f6g.
 =1 =) G1 =f1g, G2 =f2g, G3 =f3g, G4 =f4g y G5 =f5,6g.
 =1.5 =) G1 =f1g, G2 =f2g, G3 =f4g y G4 =f3,5,6g.
 =2 =) G1 =f1g, G2 =f2,4g y G3 =f3,5,6g.
 =5 =) G1 =f1g y G2 =f2,3,4,5,6g.
 =6 =) G1 =f1,2,3,4,5,6g.
tu
4. Clustering: Este proceso asigna cada individuo de la poblacion a un cluster o grupo
determinado. Para esto es necesario obtener una particion determinada de la matriz
ultrametrica. Por tanto, el problema consiste en elegir un -corte entre los posibles
-cortes, obtenidos de acuerdo a la hipotesis de que no se tiene ninguna informacion
previa sobre la estructura de los datos. La particion puede ser obtenida de distinta
forma, segun la opcion que elija el usuario:
 Particion optima absoluta: Esta particion es determinada al nivel de similitud
0.5 [148] (en matrices normalizadas), en caso de que no se tenga ningun tipo de
conocimiento sobre la estructura de los datos.
 Una buena particion: Para esto se usa un procedimiento de aprendizaje no su-
pervisado basado en herramientas de conjuntos difusos. Este procedimiento de ne
una buena particion como el valor mnimo de la medida de nida sobre el conjunto
de todos los posibles -cortes [55].
4 En el apartado 1.3.2 se explico el concepto general de -corte.
258 CAPITULO 7. ALGUNAS APLICACIONES DEL LENGUAJE FSQL
 Particion determinada por un determinado numero de grupos n: Mediante un
algoritmo de busqueda binaria sobre todos los posibles -cortes, obtenemos el -
corte que implica n grupos o el que implica el numero de grupos mas cercano a n.
Con esto se pueden especi car condiciones como \menos (o mas) de n grupos".

5. Calcular los centroides de cada grupo: Esta etapa obtiene una tupla que identi ca
a cada grupo. O sea, los valores de esa tupla identi can un valor \tpico", central o
centroide de cada grupo. El valor de cada atributo en esta tupla depende del tipo de
este:

 Atributos Numericos: El centroide es obtenido como la media de los valores de este


atributo para todas los objetos (tuplas) que pertenecen a el cluster en cuestion.
 Atributos Escalares: Cada valor posible es identi cado por una etiqueta lingustica.
As, mezclando estos valores de los objetos del cluster obtenemos una distribucion
de posibilidad, que es obtenida como una especie de media de la distribucion de
probabilidad, usando una combinacion convexa de las etiquetas lingusticas [54].
 Atributos Binarios: Son considerados como un caso particular de los atributos
escalares pero unicamente con dos posibles valores.

7.2.4 Uso de FSQL para Clustering Difuso


Como hemos visto anteriormente, como resultado de DAPHNE obtenemos un numero de
grupos caracterizados por unos valores centrales para cada atributo, a partir de un conjunto
de ejemplos (hacerlo con toda la base de datos sera demasiado lento). Estos resultados, en
s, no son directamente manipulables por un usuario sino que son datos intermedios dentro
del proceso analtico del sistema. El objetivo es asignar cada elemento de la base de datos a
un cluster, as como cada elemento que insertemos en dicha base de datos.
Normalmente, para este objetivo se usa un algoritmo de clasi cacion con el que se obtienen
reglas (como arboles de decision) que describen cada grupo y con las que es facil clasi car
cualquier elemento en un grupo adecuado. Estos algoritmos pueden ser bastante lentos y no
indican si un elemento esta claramente en un grupo o pertenece al grupo pero no es muy
\tpico" del mismo.
Nuestra propuesta original es el uso de DAPHNE para obtener los centroides de cada
grupo y, posteriormente, usarlos en una consulta FSQL. As, las descripciones de cada grupo
pueden ser usadas por el usuario de forma amigable, a traves de un lenguaje de alto nivel
y los resultados son obtenidos en tiempo real. Ademas, usando la funcion CDEG de FSQL
podemos obtener en que grado cada elemento pertenece a cada grupo, de forma que los
grupos obtenidos pueden ser vistos como grupos o conjuntos difusos. En otras palabras, CDEG
calcula un grado que indica en que medida cada elemento es \tpico" del grupo. De esta forma
un mismo elemento puede pertenecer a varios grupos, presumiblemente con distinto grado de
pertenencia a cada uno.
As pues, a partir de los centros (C1 ; : : : ; Cn ) para n atributos (A1 ; : : : ; An ) de un deter-
minado grupo elaboramos una consulta FSQL con el siguiente formato:
7.2. DATA MINING CON FSQL EN UN ENTORNO FINANCIERO 259

SELECT tabla.*,CDEG(*)
FROM tabla
WHERE A C
1 FEQ # 1 THOLD AND
A C
2 FEQ # 2 THOLD AND
:::
An FEQ #Cn THOLD ;
Con este tipo de consulta obtenemos los elementos que pertenecen al grupo en cuestion
con un grado de pertenencia mayor o igual que el umbral elegido. Los #Ci representan
el valor \aproximadamente Ci " representados por distribuciones de posibilidad triangulares
(Figura 5.4). En vez de esos valores aproximados podemos tambien utilizar trapecios (Figura
5.2) del tipo: $[Ci ; Ci ; Ci + ; Ci + ], eligiendo unos valores apropiados para  y ,
tales que sean positivos y con  > .
Por supuesto, podemos usar otro comparador difuso de los de la Tabla 5.12, principalmente
NFEQ para obtener resultados m as precisos. Para evitar los valores Unknown (desconocidos)
que pudiera haber en atributos difusos podemos a~nadir el siguiente tipo de condicion para el
atributo Ai que lo precise:
Ai IS NOT UNKNOWN

Tanto en atributos difusos como \crisp" puede interesarnos tambien evitar los valores
nulos, lo cual es posible a~nadiendo el siguiente tipo de condicion para el atributo Ai en
cuestion:
Ai IS NOT NULL

Es facil ver que de esta forma usamos los grupos obtenidos como si fueran grupos difusos,
incluso si ellos se han obtenido a traves de algoritmos \crisp".
La sentencia FSQL anterior resuelve la siguiente consulta a la base de datos: \Dame
los objetos que pertenecen al grupo C y su grado de pertenencia al mismo de aquellos que
pertenecen a dicho grupo con un grado de pertenencia mnimo de ".
Aunque FSQL es un lenguaje de alto nivel, su utilizacion puede ser efectuada de forma
trasparente a traves de programas Clientes FSQL (Captulo 6), de forma que estos oculten el
uso de FSQL a un usuario no adiestrado en el uso de SQL o FSQL.
La principal ventaja del metodo que proponemos es, quizas, que el algoritmo de clasi ca-
cion que debe aplicarse tras el clustering, no es necesario, ya que esta clasi cacion es efectuada
por FSQL en tiempo real, ademas de que, de esta forma, los usuarios no expertos podran
utilizar los datos producidos por DAPHNE.
7.2.5 Resultados Experimentales
La segmentacion de clientes de una determinada empresa tiene su origen en el campo del
marketing e investigacion de mercados. Proporciona una division analtica de todos los po-
tenciales clientes en un mercado de ventas segun diferentes criterios, lo cual permite orientar
el marketing adecuado a cada uno de los grupos (marketing directo). Ejemplo de esto es [152],
donde se propone un proyecto de segmentacion difusa de clientes para una entidad nanciera.
Usando tecnicas de segmentacion difusa construye grupos de clientes homogeneos en lo refe-
rente a las caractersticas de los clientes pertenecientes al mismo grupo y heterogeneos entre
los de distintos grupos.
260 CAPITULO 7. ALGUNAS APLICACIONES DEL LENGUAJE FSQL
Cluster# Nomina Uso Tarjeta Saldo
1 N Medio {307,667
2 S Bajo 265,328
3 S Medio 1,857,751
4 N Bajo 125,556
5 S Alto {3,488
6 N Medio 3,550
Tabla 7.1: Ejemplo de clustering: DAPHNE obtiene 6 clusters.

El sistema explicado en el apartado anterior ha sido aplicado al problema de segmentacion


de clientes de una entidad nanciera en una situacion real. Los atributos relevantes identi-
cados por los expertos de la entidad fueron: Nomina (Nomina), Nivel de uso de la tarjeta
de credito (Uso Tarjeta) y Saldo medio (Saldo). El primer atributo tiene dominio binario
e indica si el cliente recibe su nomina a traves de la entidad (valor `S') o no (valor `N'). El
nivel de uso de la tarjeta de credito es tratado como un escalar usando las etiquetas \Bajo",
\Medio" y \Alto", obtenidas, junto con su relacion de similitud, tras un estudio analtico en
el sistema de \data warehouse" de la compa~na.
A traves de una muestra de 1000 tuplas, DAPHNE obtuvo 6 clusters como el numero
optimo de grupos en la poblacion. Los valores centrales de cada grupo son los que se muestran
en la Tabla 7.1. El atributo Nomina no ha sido considerado como difuso para mostrar que los
atributos con tratamiento difuso y \crisp" pueden convivir sin problemas.
Tras esto, para recuperar, por ejemplo, los clientes (en toda la base de datos) que per-
tenecen a el cluster 1 con un grado mnimo de 0.7, podramos efectuar la siguiente consulta
FSQL:

SELECT Cliente#, CDEG(*)


FROM Clientes
WHERE Nomina = 'N' AND
Uso Tarjeta FEQ $Medio THOLD 0.7 AND
Saldo FEQ #-307667 THOLD 0.7
ORDER BY 2 DESC;

donde Cliente# es un atributo de la relacion Clientes con el codigo de cada cliente. Un


ejemplo de los resultados de esta consulta se muestra en la Tabla 7.2.
Observe que el usuario puede facilmente ponderar la importancia de cada atributo a traves
del umbral de cumplimiento y del comparador difuso empleado. Por ejemplo, es posible dar
mas (o menos) importancia al atributo Saldo aumentando (o disminuyendo) su correspon-
diente umbral. Esto puede ser muy util para enfocar mejor la seleccion de clientes de acuerdo
a objetivos concretos dependientes de cada aplicacion particular.
Si los resultados de DAPHNE de la Tabla 7.1 son almacenados en una relacion de la base
de datos llamada, por ejemplo, Clusters, entonces, la consulta anterior puede ser efectuada
tambien de forma mas general como:
 DE UNA INMOBILIARIA DIFUSA
7.3. GESTION 261

Cliente# CDEG(*)
C1 1.00
C2 0.95
C3 0.91
C4 0.80
C5 0.80
C6 0.75
C7 0.71
C8 0.70
Tabla 7.2: Resultados de una consulta FSQL para Data Mining.

SELECT Cliente#, CDEG(*)


FROM Clientes, Clusters
WHERE Clientes.Nomina = Clusters.Nomina AND
Clientes.Uso Tarjeta FEQ Clusters.Uso Tarjeta THOLD 0.7 AND
Clientes.Saldo FEQ Clusters.Saldo THOLD 0.7 AND
Clusters.Cluster# = 1
ORDER BY 2 DESC;

donde para modi car la consulta para otro grupo basta con cambiar la ultima condicion de
igualdad con el atributo Cluster#.

7.3 Gestion de una Inmobiliaria Difusa


Las aplicaciones de los SGBD y de la teora de bases de datos a problemas de \gestion" son
inmensas, como lo demuestra la enorme cantidad de aplicaciones de este tipo que se venden en
el mercado, que van desde la gestion de un video-club hasta la gestion de un garaje, pasando
por supermercados, hospitales, hoteles, colegios, universidades o, en general, aplicaciones para
la gestion de cualquier empresa, independientemente de su tama~no o dedicacion.
En todas ellas tienen aplicacion las bases de datos difusas pues estas no reducen en nada
las posibilidades de las bases de datos clasicas, sino que, por el contrario, las aumentan para
poder almacenar y tratar informacion que usando bases de datos clasicas sera imposible.
Ademas, usando adecuadamente el poder deductivo de FSQL se pueden obtener conclusiones
muy utiles. Por ejemplo, en un hospital podramos efectuar consultas del tipo \Dame los
enfermos jovenes que padecen hepatitis y que llevan ingresados aproximadamente mas de
5 semanas". En un colegio se podra consultar informacion como \Dame los alumnos que
han superado Matematicas con buena nota y han superado fsica con nota regular ". En un
supermercado sera util conocer las respuestas a preguntas como \Dame los productos que se
han vendido mucho gastando poco en su publicidad ".
En n, la lista de aplicaciones de gestion y de consultas utiles sobre estas sera intermina-
ble. En este apartado vamos a explicar brevemente como se podra efectuar la gestion de una
inmobiliaria a traves de una BDRD y del lenguaje FSQL. El programa se esta desarrollando
en la actualidad, en calidad de proyecto n de carrera de la Ingeniera Superior en Informatica
de la Universidad de Malaga, por el alumno P. Palomo, siendo el Director de dicho proyecto
el autor de esta memoria.
262 CAPITULO 7. ALGUNAS APLICACIONES DEL LENGUAJE FSQL
Durante el desarrollo del proyecto se mantendran contactos con diversos Agentes de la
Propiedad Inmobiliaria (A.P.I.), conocidos previamente, a los que queremos agradecer desde
estas lneas su colaboracion. As, las caractersticas que se pretenden dar al proyecto seran
validadas por estos agentes.
A continuacion incluimos una descripcion de este proyecto, sin mas ambicion que pretender
dar una idea de las posibilidades que abre el uso de FSQL.

7.3.1 Objetivos Principales


Gracias a la existencia del Servidor FSQL, los objetivos de este proyecto no tienen que cen-
trarse en la resolucion de las consultas exibles. As pues, los objetivos mas importantes del
proyecto son:

 Conseguir un programa para la gestion de una inmobiliaria, con todas las funcionalida-
des que esto requiera: Gestion de la oferta y demanda para la venta, alquiler o traspaso
de cualquier nca o inmueble posible (piso, local, cochera, trastero, solar, chalet, nave
industrial...).
 Los atributos de la base de datos que sean susceptibles de tratamiento difuso seran
considerados como tales y clasi cados en los 3 tipos difusos que consideramos (apartado
5.1.3.1): Atributos difusos Tipo 1, 2 o 3.
 Facilidad en el aprendizaje y en la utilizacion del programa: El programa incorporara
un sistema de ayuda on-line y tendra un dise~no que permita facilidad de acceso a las
operaciones mas frecuentes, as como un interfaz intuitivo y de facil aprendizaje.
 Facilidad para efectuar consultas tradicionales o exibles a la base de datos, de manera
que se con guren las consultas de forma visual o directamente a traves de SQL o FSQL.
 Facilidad para modi car, insertar o borrar valores u objetos de la base de datos, inclu-
yendo valores difusos.
 Facilidad para consultar y modi car la FMB: Esto implica consultar y/o modi car las
etiquetas de nidas, el margen para valores aproximados, atributos Tipo 3 compatibles,
a~nadir nuevas etiquetas...
 Posibilidad de contrastar de forma exible las ofertas con las demandas, dando un
listado con los inmuebles que pueden interesar a cada demanda junto con un grado de
\interes" o emparejamiento para cada inmueble.
 Mantenimiento de cheros historicos: En esos cheros se almacenaran las ofertas y
demandas que ya han sido objeto de una operacion o que han sido dadas de baja por
cualquier motivo. Esto nos permitira hacer consultas sobre situaciones anteriores.
 Opcion para exportar la base de datos: Esto nos permite instalarla en otro equipo o
simplemente hacer una copia de seguridad de la misma.
 DE UNA INMOBILIARIA DIFUSA
7.3. GESTION 263

7.3.2 Atributos Difusos


En esta memoria no pretendemos dar una lista exhaustiva de todos los atributos difusos
declarados en el proyecto, sino mas bien una idea de los atributos que son susceptibles de
tratamiento difuso.
Por supuesto, el esquema de la base de datos tambien incluye atributos clasicos, como
pueden ser: Los nombres de clientes, su DNI, su numero de telefono, las direcciones de los
inmuebles, atributo para observaciones en general, fechas, numero de ascensores, si el piso
tiene calefaccion, agua caliente central, cochera, si es Vivienda de Proteccion O cial (V.P.O.)...
En general, para dar una mayor versatilidad al programa, se han utilizado pocos atributos
difusos Tipo 1, ya que estos permiten la consulta exible pero no permiten el almacenamiento
de valores difusos. As, algunos atributos difusos Tipo 2 podran haberse considerado como
de Tipo 1, restringiendo la posibilidad de almacenar imprecision en su dominio. Tambien hay
que tener en cuenta que los atributos difusos Tipo 2 requieren en general de mayor cantidad
de espacio para ser almacenados y mayor tiempo para ser procesados. As pues, hay que
llegar a un compromiso entre exibilidad (en la representacion y el tratamiento difuso) y
e ciencia (en espacio de almacenamiento y tiempo de CPU).
Ejemplos de atributos difusos considerados como de Tipo 1 son: El numero de habi-
taciones, el numero de servicios, el precio de la comunidad, la altura del piso (numero de
planta)... Puede observarse que, en general, los valores de los atributos anteriores suelen ser
bien conocidos y sin ambiguedad.
Los atributos difusos Tipo 2 son los mas numerosos, ya que hemos querido dar mucha
exibilidad a la base de datos. Entre estos, destacan los siguientes:
 Precio: En gran parte de los casos, el precio establecido a un inmueble no es jo, sino
que el vendedor establece un precio aproximado, e incluso, a veces, el mismo vendedor
le indica a la agencia que estara dispuesto a bajar cierta cantidad del precio estable-
cido. Esta informacion puede almacenarse en la base de datos en forma de trapecio
posibilstico, de forma que cuando ejecutemos un emparejamiento con las demandas de
inmuebles, se tenga en cuenta esa posibilidad.
 Super cie (en m2): A veces, es difcil acceder de forma rapida a la escritura del inmueble
o hacer una medicion exacta de la super cie del mismo. Por eso, la posibilidad de alma-
cenar valores aproximados fue muy valorada por los agentes inmobiliarios consultados.
 Edad: Igualmente, es difcil y en general innecesario saber la edad exacta del inmueble,
aunque s es tremendamente util saber su edad aproximada. De esta forma podemos
almacenar que un piso es nuevo, seminuevo, viejo o que tiene aproximadamente 8 a~nos,
por ejemplo.
 Tama~no de la cochera, del trastero, del jardn o del terreno disponible (si procede).
Los atributos difusos Tipo 3 considerados son los siguientes, teniendo cada uno su co-
rrespondiente relacion de semejanza entre los valores posibles:
 Atributos para las condiciones de Luz, Ruido, Vistas, Calidad de los muebles (en caso
de pisos amueblados) y Estado general del inmueble: Se consideran diversos valores

(etiquetas) posibles, como Pesimo, Fatal, Malo, Normal, Bueno, Excelente y Optimo.
264 CAPITULO 7. ALGUNAS APLICACIONES DEL LENGUAJE FSQL
Muchos de estos atributos podran ser considerados como de Tipo 2 para permitir una
mayor exibilidad, sobre todo en el tipo de consultas, pudiendo efectuar consultas con
condiciones del tipo \... cuyas vistas sean mejores que Buenas". Sin embargo, como ese
tipo de condiciones no son muy usuales en los atributos considerados, se ha optado por
considerarlos como de Tipo 3 con longitud 1 (atributo LEN de FUZZY_COL_LIST). De esta
forma se ahorra espacio de almacenamiento. Aunque se reduce el comparador difuso
que se puede emplear con estos atributos a FEQ exclusivamente, esto no resta demasiada
exibilidad, pues contamos con la exibilidad que aporta el umbral de cumplimiento y
con que la relacion de similitud entre las etiquetas este bien de nida.
 Zona (barrio): Este atributo se ha implementado con longitud 3, de forma que permite
indicar que un piso esta situado entre 3 zonas, con distinto grado. Por ejemplo, el valor
f0.5/Centro, 1/Molinillo, 0.7/Capuchinosg
indica que el inmueble en cuestion esta situado en el barrio del Molinillo, mas cerca del
barrio de Capuchinos que del Centro de la ciudad5.
La relacion de similitud entre las distintas zonas o barrios dependera de la distancia
existente entre ellas y de su extension.
 Tipo de Inmueble: Este atributo distingue entre Pisos, Estudios, Chalets, Casas Ado-
sadas, Solares, Cocheras, Trasteros, Naves industriales... En general, la relacion de
similitud sera cero entre la mayora de ellos, pero entre algunos sera distinta de cero.
Por ejemplo, se puede establecer que un chalet se parece a una casa adosada en grado
0.8, de forma que un cliente que busque un chalet es un cliente potencial de las casas
adosadas, por lo que deberan ser tenidas en cuenta a la hora de ofertarle material. Ver
Ejemplo 7.4.
Otros datos, como la existencia de chimenea o piscina (individual o colectiva), seran al-
macenados en un campo de texto especial de observaciones, en el que tienen cabida cualquier
consideracion que quiera efectuarse y que no haya sido considerada explcitamente por atri-
butos en la relacion.
7.3.3 Ejemplos de Consultas Flexibles
El tipo de consultas que pueden efectuarse son inmensas y de entre ellas destaca la compara-
cion entre la relacion de inmuebles ofertados y la relacion de demandas de inmuebles. En la
primera relacion se almacenan los inmuebles con los que se desea operar (vender, alquilar...)
y en la relacion de demandas se almacenan las caractersticas generales de los inmuebles que
estan siendo demandados o buscados por determinados clientes.
As, en la relacion de demandas el cliente indica las caractersticas del inmueble que busca.
Por ejemplo, un piso grande, con mas de 5 habitaciones aproximadamente, con cochera grande,
poco ruido, mucha luz y que sea un piso alto.
Posteriormente, la relacion de demandas se empareja con la relacion de ofertas utilizando
comparadores difusos (Tabla 5.12) de necesidad y umbrales estrictamente mayores que cero,
pidiendo al sistema que ordene la salida decrecientemente por el grado de compatibilidad
5 Esos tres barrios pertenecen a la ciudad de Malaga, donde se esta elaborando el proyecto.
 DE UNA INMOBILIARIA DIFUSA
7.3. GESTION 265

alcanzado por cada inmueble. Si se obtienen demasiados inmuebles se puede optar por subir
el umbral de cumplimiento y si se obtienen demasiados pocos inmuebles, entonces se efectuara
la misma consulta utilizando comparadores de posibilidad, en vez de los de necesidad, que
son mas restrictivos.
Algunos ejemplos, que pueden ser efectuados on-line, sin necesidad de incluir la busqueda
en la tabla de demandas, pueden ser los siguientes:
Ejemplo 7.4 Ejemplo, suponga que entra un cliente en la inmobiliaria e indica: \Estoy
buscando un chalet grande con unos 6 dormitorios que tenga un terrenillo, aunque no hace
falta que sea muy grande". Entonces, la siguiente consulta FSQL devuelve los inmuebles que
cumplen esas condiciones, ordenando de mayor a menor por el primer atributo mostrado, que
es el grado de compatibilidad:
SELECT CDEG(*), Inmuebles_Venta.*
FROM Inmuebles_Venta
WHERE Tipo FEQ $Chalet .5
AND Superficie FGEQ $Grande .5
AND Habitaciones FGEQ #7 .5
AND Terreno FGEQ $Normal .5
ORDER BY 1 DESC;

Debido a que se incluyen bastantes condiciones elementales, se ha optado por utilizar


comparadores de posibilidad, para conseguir as seleccionar una mayor cantidad de inmuebles.
Como el salon es considerado como una habitacion, la consulta se ha hecho considerando
7 habitaciones (6 dormitorios mas el salon). En general, las inmobiliarias no contabilizan la
cocina y los aseos en el numero de habitaciones.
En la consulta anterior, tambien seran consideradas las casas adosadas, si este Tipo de
inmueble tiene un grado de similitud superior a 0.5 con respecto a los chalets. Si buscamos
exclusivamente chalets debemos establecer el umbral a 1, o no poner umbral, ya que 1 es el
umbral por defecto. tu
Ejemplo 7.5 Otro cliente podra indicarnos: \Me gustara comprar un piso que sea peque~no
con unos 50 m2 mas o menos, pero que tenga mucha luz y poco ruido, de unos 8 millo-
nes maximo, por la zona de Capuchinos". En este caso la consulta FSQL que obtiene la
informacion buscada sera:
SELECT CDEG(*), Inmuebles_Venta.*
FROM Inmuebles_Venta
WHERE Tipo FEQ $Piso .5
AND Superficie FGEQ $[30,40,60,70] .5
AND Luz FEQ $Bueno .5
AND Ruido FEQ $Bueno .5
AND Precio FLEQ #9 .5
AND Zona FEQ $Capuchinos .5
ORDER BY 1 DESC;

El trapecio posibilstico del atributo Superficie podra ser calculado automaticamente de


la siguiente forma: [n 20; n 10; n +10; n +20], donde n es el tama~no indicado por el cliente.
266 CAPITULO 7. ALGUNAS APLICACIONES DEL LENGUAJE FSQL
Si el cliente esta muy seguro de la extension del piso que busca se puede utilizar #n (en este
caso #50). La condicion sobre el Precio establece que este sea menor que aproximadamente
9 millones, aunque el cliente especi co 8, ya que, segun los agentes consultados, al comprar
un piso es frecuente gastar mas dinero del pensado inicialmente.
En la consulta anterior, tambien seran considerados los inmuebles de Tipo Estudio, si
este Tipo de inmueble tiene un grado de similitud superior a 0.5 con respecto a los pisos. tu
Puede observarse que el numero de consultas posibles y la utilidad de sus respuestas es
tremenda. As, a cada cliente se empezara por ense~narle el inmueble que tenga un mayor
grado de compatibilidad con respecto a lo que busca. En caso de no encontrar lo que busca,
puede exibilizarse aun mas la consulta reduciendo los umbrales (hasta llegar a 0), cambiando
las constantes difusas de la derecha de las comparaciones simples, cambiando comparadores
difusos, eliminando condiciones no muy vinculantes o cambiando algun comparador logico
AND por OR utilizando los par entesis para establecer la precedencia.
Ejemplo 7.6 Supongamos que en la consulta del ejemplo anterior no obtenemos ningun
inmueble que sea de interes para el cliente. Entonces, podemos proceder a exibilizar la
consulta de la siguiente forma:
SELECT CDEG(*), Inmuebles_Venta.*
FROM Inmuebles_Venta
WHERE Tipo FEQ $Piso .25
AND Superficie FGEQ $[20,30,70,80] .25
AND (Luz FEQ $Bueno .5 OR
Ruido FEQ $Bueno .5)
AND Precio FLEQ #10 .25
AND Zona FEQ $Capuchinos .25
ORDER BY 1 DESC;

Si aun as, seguimos sin obtener pisos que interesen al cliente, podemos eliminar las con-
diciones mas super uas (como la de Luz y Ruido), reducir los umbrales o poner como valida
otra Zona que este cercana o tenga similares caractersticas (con OR). tu
Naturalmente, el sistema de consulta exible no asegura la realizacion de operaciones, pero
s que asegura que mostramos a cada cliente los pisos mas acordes a sus necesidades y gustos,
teniendo en cuenta que cuando uno busca cualquier tipo de inmueble rara vez busca algo jo,
sino que busca algo con unas caractersticas basicas iniciales que puede ir modi cando y que
es frecuente que lo que el cliente adquiera nalmente no se parezca mucho a lo que buscaba
inicialmente.
Ademas, este sistema permite a la inmobiliaria mantener una gran base de datos, sin tener
que recordar de memoria las caractersticas difusas de estos, algo bastante usual hoy da en
las inmobiliarias y que imposibilita manejar muchos inmuebles de forma efectiva.
Conclusiones y Lneas Futuras
En este trabajo se han aportado distintos resultados, entre los que cabe destacar los siguientes
como los mas signi cativos:
 Sistema de Division Relacional Difusa para el modelo GEFRED: Este modelo de
BDRD es el mas general y completo de los aparecidos en la bibliografa. Las principales
innovaciones de nuestra propuesta de division difusa con respecto a otros sistemas son
que permite que en los atributos sean almacenados todos los tipos de datos del modelo
GEFRED (principalmente distribuciones de posibilidad) y que permite la existencia de
varios atributos comunes entre las relaciones sobre las que se va a efectuar la division.
Ademas, cada tupla del resultado se obtiene con un grado de cumplimiento que indica el
grado con el que cada tupla cumple con las condiciones de la division. Nuestra propues-
ta de division tambien permite la relajacion del cuanti cador universal, permitiendo
cualquier tipo de cuanti cador.
 Calculo Relacional Difuso de Dominios para el modelo GEFRED: Se demuestra
que este calculo es totalmente equivalente al algebra relacional difuso de este modelo.
Ademas, se provee de un metodo pa