Bases de Datos

LORCDB: Gestor de Bases de Datos Objeto-Relacionales de Restricciones
Departamento de Lenguajes y Sistemas Informticos Memoria de Tesis Doctoral para optar al grado de Doctora en Informtica por la Universidad de Sevilla
presentado por
Da Mara Teresa Gmez Lpez

Directores:
Dr. D. Rafael Martnez Gasca Dr. D. Carmelo Del Valle Sevillano
Sevilla, Diciembre de 2007
Mara Teresa Gmez Lpez Primera Edicin, Septiembre 2007 Grupo de investigacin Quivir Departamento de Lenguajes y Sistemas Informticos ETSI Informtica Universidad de Sevilla Avd. de la Reina Mercedes, s/n Sevilla, 41012. Espaa Copyright c MMVII Grupo Quivir http://www.lsi.us.es/mayte
mayte@lsi.us.es
Financiacin: Este trabajo ha sido nanciado por el Ministerio de Ciencia y Tecnologa

del Gobierno de Espaa (CICYT DP I 2000 0666 C 02 02), (CICYT DP I 2003 07146 C 02 01), (CICYT DP I 2006 15476 C 02 00).
Don Rafael Martnez Gasca y Don Carmelo Del Valle Sevillano, Profesores Titulares de Universidad del rea de Lenguajes y Sistemas Informticos de la Universidad de Sevilla,
HACEN CONSTAR
que Doa Mara Teresa Gmez Lpez, Ingeniera en Informtica por la Universidad de Sevilla, ha realizado bajo su supervisin el trabajo de investigacin titulado
Una vez revisado, autorizo el comienzo de los trmites para su presentacin como Tesis Doctoral al tribunal que ha de juzgarlo.
Fdo. Rafael Martnez Gasca
Carmelo del Valle Sevillano Universidad de Sevilla
rea de Lenguajes y Sistemas Informticos Sevilla, 19 de Octubre de 2007
Yo, Mara Teresa Gmez Lpez, con DNI nmero 28.631.064-C,
DECLARO BAJO JURAMENTO
Ser la autora del trabajo que se presenta en la memoria de esta tesis doctoral que tiene por ttulo:
Lo cual rmo en Sevilla, 19 de Octubre de 2007.
Fdo. Mara Teresa Gmez Lpez
A mis padres que me ensearon a luchar todos los das para conseguir lo que quera, y a Jess que con su cario diario me da fuerzas para poderlo hacer
ndice general
1. Introduccin
1.1. Ejemplos Motivadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Contexto del Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
3 7
1.3. Justicacin del Trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.4. Objetivos de la Tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.5. Marco de la Tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.6. Estructura de la Tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2. Antecedentes de las Bases de Datos
17
2.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.2. Dominio de Aplicacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.2.1. CAD - Computer-Aided Design y CAM - Computer-Aided Manufacturing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.2.2. CIM - Computer Integrated Manufacturing y PDM - Product Data Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.2.3. CASE - Computer-Aided Software Engineering . . . . . . . . . . . 22
2.2.4. GIS - Geographic Information System y Bases de Datos EspacioTemporales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.3. Naturaleza de la informacin . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.3.1. Bases de Datos Deductivas . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.2. Bases de Datos de Restricciones . . . . . . . . . . . . . . . . . . . . 28 2.3.3. Bases de Datos Deductivas de Restricciones . . . . . . . . . . . . . 29 2.4. Modelo lgico de almacenamiento de Bases de Datos . . . . . . . . . . . . 30 2.4.1. Bases de Datos Relacionales . . . . . . . . . . . . . . . . . . . . . . 30 2.4.2. Bases de Datos Orientadas a Objetos . . . . . . . . . . . . . . . . . 33 2.4.3. Bases de Datos Objeto-Relacionales . . . . . . . . . . . . . . . . . . 38 2.4.4. Comparacin entre las propuestas . . . . . . . . . . . . . . . . . . . 40 2.5. Posicin de la propuesta dentro del organigrama general . . . . . . . . . . 41 2.6. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3. Antecedentes de las Bases de Datos de Restricciones
47
3.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.2. Origen de las Bases de Datos de Restricciones . . . . . . . . . . . . . . . . 48 3.3. Formalizaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.3.1. Lgica y Modelo de Primer Orden . . . . . . . . . . . . . . . . . . . 50 3.3.2. Formalizacin de las Bases de Datos de Restricciones . . . . . . . . 52 3.3.3. Ejemplo de Modelado con Relaciones Restrictivas . . . . . . . . . . 55 3.4. Consultas a Bases de Datos de Restricciones . . . . . . . . . . . . . . . . . 56 3.4.1. Eliminacin de cuanticadores . . . . . . . . . . . . . . . . . . . . . 56 3.4.2. Consultas sobre restricciones . . . . . . . . . . . . . . . . . . . . . . 57 3.4.3. Algebra Relacional para Restricciones . . . . . . . . . . . . . . . . . 60 3.4.4. Evaluacin de consultas en BDdR . . . . . . . . . . . . . . . . . . . 63 3.5. Prototipos de Bases de Datos de Restricciones . . . . . . . . . . . . . . . . 63 3.5.1. DISCO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 3.5.2. MLPQ/PReSTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 3.5.3. DEDALE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 3.5.4. CCUBE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.5.5. CQA/CDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 3.5.6. DeCoR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 3.6. Comparativas entre las Propuestas . . . . . . . . . . . . . . . . . . . . . . 80 3.7. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4. Propuesta de Modelado para las Bases de Datos de Restricciones
85
4.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 4.2. Formalizacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 4.2.1. Restriccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.2.2. Bases de Datos de Restricciones . . . . . . . . . . . . . . . . . . . . 90 4.2.3. Nueva Denicin del Modelo de Bases de Datos de Restricciones . . 90 4.2.4. Atributos en las Bases de Datos de Restricciones . . . . . . . . . . . 93 4.3. Consultas a Bases de Datos de Restricciones . . . . . . . . . . . . . . . . . 94 4.4. Resolucin de Problemas con Restricciones . . . . . . . . . . . . . . . . . . 98 4.4.1. Problemas de Satisfaccin de Restricciones . . . . . . . . . . . . . . 99 4.4.2. Problemas de Optimizacin con Restricciones . . . . . . . . . . . . 100 4.4.3. Bases de Grbner . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 4.4.4. Descomposicin Algebraica Cilndrica . . . . . . . . . . . . . . . . . 101 4.5. Operador Seleccin para BDdR . . . . . . . . . . . . . . . . . . . . . . . . 103 4.5.1. Operador de Seleccin para Atributos de tipo Restriccin . . . . . . 103 4.5.2. Operador de Seleccin para Atributos de tipo Variable de Restriccin111 4.6. Operador Proyeccin para BDdR . . . . . . . . . . . . . . . . . . . . . . . 113 4.6.1. Operador de Proyeccin para Atributos Variables de Restriccin . . 113 4.7. Operador de Unin de Conjuntos para BDdR . . . . . . . . . . . . . . . . 117 4.8. Operador Diferencia de Conjuntos para BDdR . . . . . . . . . . . . . . . . 119 4.9. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
5. Arquitectura LORCDB. Un Gestor para BDdR
123
5.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 5.2. Las Bases de Datos Objeto-Relacionales y las Restricciones . . . . . . . . . 125 5.2.1. Representacin de las Restricciones como Objetos usando UML . . 126 5.3. Arquitectura del Sistema Gestor de BDdR . . . . . . . . . . . . . . . . . . 131 5.3.1. Consulta sobre la base de datos . . . . . . . . . . . . . . . . . . . . 135 5.4. CORQL: Ampliacin de SQL para BDdR . . . . . . . . . . . . . . . . . . . 137 5.4.1. Creacin de una LORCDB . . . . . . . . . . . . . . . . . . . . . . . 137 5.4.2. Creacin de tablas en una LORCDB . . . . . . . . . . . . . . . . . 137 5.4.3. Insercin de tuplas en la tabla . . . . . . . . . . . . . . . . . . . . . 138 5.4.4. Consulta a una LORCDB . . . . . . . . . . . . . . . . . . . . . . . 140 5.4.5. Modicacin de la estructura de una tabla . . . . . . . . . . . . . . 143 5.4.6. Modicacin del contenido de una tabla . . . . . . . . . . . . . . . 144 5.5. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
6. Implementacin del lenguaje CORQL
147
6.1. Ejemplo de caso de estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 6.2. Implementacin de la Seleccin . . . . . . . . . . . . . . . . . . . . . . . . 149 6.3. Implementacin del Producto Cartesiano . . . . . . . . . . . . . . . . . . . 162 6.4. Implementacin de la Proyeccin . . . . . . . . . . . . . . . . . . . . . . . 163 6.4.1. Deteccin de grupos de restricciones relacionadas para la Proyeccin Numrica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 6.4.2. Deteccin de grupos de restricciones relacionadas para la Proyeccin Simblica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 6.4.3. Seleccin de la tcnica para evaluar la proyeccin . . . . . . . . . . 171 6.5. Implementacin de la Operacin de Unin . . . . . . . . . . . . . . . . . . 177 6.6. Implementacin de la Operacin de Diferencia . . . . . . . . . . . . . . . . 178 6.7. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
7. La Diagnosis de Fallos Basada en Modelos: Un caso de estudio
181
7.1. Conceptos sobre Diagnosis de Fallos . . . . . . . . . . . . . . . . . . . . . . 182 7.2. Deniciones y Notacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 7.3. La Diagnosis de Fallos y las BDdR . . . . . . . . . . . . . . . . . . . . . . 188 7.3.1. Insercin de Componentes en la BDdR . . . . . . . . . . . . . . . . 188 7.3.2. Obtencin de la Red de Contextos . . . . . . . . . . . . . . . . . . . 189 7.3.3. Obtencin de las CARCs y los PCCM . . . . . . . . . . . . . . . . 190 7.3.4. Obtencin de los CCM para un Modelo Observable . . . . . . . . . 192 7.3.5. Obtencin de los Hitting Sets Mnimos . . . . . . . . . . . . . . . . 193 7.4. Ms ejemplos de Consultas . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 7.5. Ejemplos de Consultas en la Diagnosis Basada en Modelos . . . . . . . . . 196 7.5.1. Ejemplos de Seleccin 7.5.2. Ejemplos de Proyeccin . . . . . . . . . . . . . . . . . . . . . . . . . 198 . . . . . . . . . . . . . . . . . . . . . . . . 199
7.6. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
8. Optimizacin y Pruebas en la Evaluacin de Consultas en BDdR
207
8.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 8.2. Pruebas para el Operador de Proyeccin . . . . . . . . . . . . . . . . . . . 210 8.2.1. Ejemplo de Diagnosis Basada en Modelos . . . . . . . . . . . . . . . 211 8.2.2. Mejoras en la Evaluacin de la Proyeccin Simblica . . . . . . . . 212 8.2.3. Ejemplos de Pruebas usando Proyeccin Simblica . . . . . . . . . . 212 8.2.4. Conclusiones para el operador de Proyeccin Simblica . . . . . . . 215 8.2.5. Mejoras en la Evaluacin de la Proyeccin Numrica . . . . . . . . 216
8.2.6. Ejemplos de Pruebas usando la Proyeccin Numrica . . . . . . . . 218 8.2.7. Conclusiones para el operador de Proyeccin Numrica . . . . . . . 219 8.2.8. Mejoras en la Evaluacin de la Proyeccin Numrica con Optimizacin de Variable . . . . . . . . . . . . . . . . . . . . . . . . . . 219
8.2.9. Ejemplos de Pruebas usando la Proyeccin Numrica con Optimizacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 8.2.10. Conclusiones para el operador de Proyeccin Maximizando valores de Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 8.3. Los Sistemas de Informacin Geogrca y LORCDB . . . . . . . . . . . . . 223 8.3.1. Informacin almacenada en la LORCDB . . . . . . . . . . . . . . . 224 8.4. Pruebas para el Operador de Seleccin . . . . . . . . . . . . . . . . . . . . 225 8.4.1. Ejemplos de Pruebas usando Seleccin . . . . . . . . . . . . . . . . 227 8.4.2. Conclusiones para el operador de Seleccin . . . . . . . . . . . . . . 230 8.5. Pruebas para el Operador de Unin . . . . . . . . . . . . . . . . . . . . . . 232 8.5.1. Ejemplos de Pruebas usando la Unin . . . . . . . . . . . . . . . . . 233 8.5.2. Conclusiones para el operador de Unin . . . . . . . . . . . . . . . 237
8.6. Pruebas para el Operador de Diferencia . . . . . . . . . . . . . . . . . . . . 238 8.6.1. Ejemplos de Pruebas usando la Diferencia . . . . . . . . . . . . . . 239 8.6.2. Conclusiones para el operador de Diferencia . . . . . . . . . . . . . 242 8.7. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
9. Conclusiones y Trabajos Futuros
245
9.1. Anlisis de la Consecucin de los Objetivos . . . . . . . . . . . . . . . . . . 245 9.2. Principales Aportaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 9.2.1. Redenicin del modelo de Bases de Datos de Restricciones . . . . . 247 9.2.2. Creacin de un nuevo Gestor de Bases de Datos de Restricciones . . 248 9.2.3. Implementacin eciente del lenguaje CORQL . . . . . . . . . . . . 248 9.2.4. Gestor vlido para aplicaciones de naturaleza diferente . . . . . . . 248 9.3. Publicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 9.4. Lneas Futuras de Investigacin . . . . . . . . . . . . . . . . . . . . . . . . 254 9.4.1. Incluir la Programacin Lgica . . . . . . . . . . . . . . . . . . . . 254
9.4.2. Restricciones de Integridad . . . . . . . . . . . . . . . . . . . . . . . 255 9.4.3. Ampliar el tipo Restriccin . . . . . . . . . . . . . . . . . . . . . . . 255 9.4.4. Bases de Datos Distribuidas . . . . . . . . . . . . . . . . . . . . . . 255 9.4.5. Analizar ms casos de estudio . . . . . . . . . . . . . . . . . . . . . 255
A. Algoritmo para la Proyeccin Simblica
257
A.1. Algoritmo para la Obtencin de los CRRV . . . . . . . . . . . . . . . . . . 257 A.2. Estructuras de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 A.3. Descripcin del Algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 A.4. Ejemplo de Traza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 A.5. Propiedades del Algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 A.5.1. Transicin entre estados de la Estructura-CRRV . . . . . . . . . . . 267 A.5.2. Complejidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 A.5.3. Completitud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 A.5.4. Correccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
B. Ejemplos de Tablas de Restricciones para el Anlisis de Eciencia
273
B.1. Ejemplo para la diagnosis basada en modelos . . . . . . . . . . . . . . . . . 273 B.2. Aplicacin para la captura de restricciones sobre SIG . . . . . . . . . . . . 273 B.2.1. Pasos para la obtencin de restricciones . . . . . . . . . . . . . . . . 275 B.3. Contenido de las tablas de Sistemas de Informacin Geogrca . . . . . . . 276
ndice de tablas
2.1. Una comparacin entre Sistemas Gestores de Bases de Datos (I) . . . . . . 41 2.2. Una comparacin entre Sistemas Gestores de Bases de Datos (II) . . . . . 42
3.1. Relacin entre la Terminologa Deductiva y la Relacional . . . . . . . . . . 78 3.2. Caractersticas de los prototipos de Bases de Datos de Restricciones . . . . 83 4.1. Eliminacin de Cuanticadores en funcin del tipo de restriccin y dominio 115 4.2. Resumen de las Operaciones y Tcnicas para evaluar consultas . . . . . . . 121 5.1. Ventajas e Inconvenientes de Restricciones y BD Relacionales . . . . . . . 124
7.1. Modelo del Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 7.2. Obtencin de CARC para el ejemplo introductorio . . . . . . . . . . . . . . 190 7.3. Obtencin de los CCM (I) . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 7.4. Obtencin de los CCM (II) . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 7.5. Obtencin de los Hitting Sets Mnimos . . . . . . . . . . . . . . . . . . . . 194 7.6. Obtencin de los Hitting Sets Mnimos (II) . . . . . . . . . . . . . . . . . . 194 7.7. Posibles combinaciones de atributos y operaciones y . . . . . . . . . . 196
7.8. Salida consulta con seleccin (I) . . . . . . . . . . . . . . . . . . . . . . . . 198 7.9. Salida consulta con seleccin (II) . . . . . . . . . . . . . . . . . . . . . . . 198 7.10. Salida consulta con seleccin (III) . . . . . . . . . . . . . . . . . . . . . . . 199 7.11. Salida consulta con Proyeccin (I) . . . . . . . . . . . . . . . . . . . . . . . 200
7.12. Salida consulta con Proyeccin (II) . . . . . . . . . . . . . . . . . . . . . . 200 7.13. Salida consulta con Proyeccin (III) . . . . . . . . . . . . . . . . . . . . . . 201 7.14. Salida consulta con Proyeccin Numrica Vertical (IV) . . . . . . . . . . . 202 8.1. Comparacin para la evaluacin de Proyecciones Simblicas utilizando las Bases de Grbner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 8.2. Comparacin para la evaluacin de Proyecciones Simblicas utilizando Descomposicin Algebraica Cilndrica . . . . . . . . . . . . . . . . . . . . . . 216 8.3. Comparacin para la evaluacin de Proyecciones Numricas . . . . . . . . . 219 8.4. Comparacin para la Evaluacin de Proyecciones Numrica con Optimizacin222 8.5. Comparacin para la Evaluacin de la Seleccin . . . . . . . . . . . . . . . 231 8.6. Comparacin para la evaluacin de la Unin . . . . . . . . . . . . . . . . . 237 8.7. Comparacin para la evaluacin de la Diferencia . . . . . . . . . . . . . . . 243
ndice de guras
1.1. Ejemplos de restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Ejemplo Motivador I. Sistema de Informacin Geogrca . . . . . . . . . . 1.3. Ejemplo Motivador II. Sistema Econmico . . . . . . . . . . . . . . . . . . 1.4. Ejemplo Motivador III. Sistema para la Diagnosis Basada en Modelos . . 2 4 5 7 9 9
1.5. Ejemplo de representacin de un conjunto de tuplas como una restriccin 1.6. Modelos de datos relacional y con restricciones 2.1. Caractersticas de las bases de datos . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . 19
2.2. El mundo de las bases de datos segn Stonebraker [1996] . . . . . . . . . . 39 2.3. Divisin detallada de una base de datos por caractersticas . . . . . . . . . 42 2.4. Ejemplos de propuestas combinando caractersticas de las Bases de Datos 3.1. Ejemplo de representacin de un conjunto de tuplas como una restriccin 3.2. Ejemplo de representacin de una restriccin en una base de datos relacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.3. Comparacin entre las Bases de Datos Extensivas y las BDdR . . . . . . . 54 3.4. Figura representada por la frmula t . . . . . . . . . . . . . . . . . . . . 56 43 49
3.5. Consistencia en las consultas a restricciones . . . . . . . . . . . . . . . . . 58 3.6. Evaluacin de Consultas a Restricciones . . . . . . . . . . . . . . . . . . . 64 3.7. Ejemplo de instancia de un escritorio (desk) con un cajn (drawer) en una habitacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.1. Equivalencia entre una relacin extendida, una relacin restrictiva y una relacin con atributos clsicos y restricciones . . . . . . . . . . . . . . . . 86 4.2. Representacin de k-tuplas restriccin y relaciones restrictivas . . . . . . . 91 4.3. Ejemplo de representacin de k-tuplas restriccin y relaciones restrictivas . 92 4.4. Representacin extendida de la relacin de la gura 4.3 . . . . . . . . . . . 95 4.5. Ejemplo de Descomposicin Algebraica Cilndrica . . . . . . . . . . . . . . 102 4.6. Ejemplo donde Cx < Cy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 4.7. Ejemplo de reescritura de la negacin 4.8. Ejemplo de proyeccin sobre variables . . . . . . . . . . . . . . . . . . . . 108 . . . . . . . . . . . . . . . . . . . . 109
4.9. Ejemplo de Cx Cy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 4.10. Ejemplo de seleccin con condicin de atributos variable de restriccin 4.11. Tipos de Proyeccin en funcin de la salida 4.12. Tipos de Unin entre restricciones . . 113
. . . . . . . . . . . . . . . . . 117
. . . . . . . . . . . . . . . . . . . . . . 118
4.13. Tipos de Diferencias entre restricciones . . . . . . . . . . . . . . . . . . . . 119 5.1. Representacin del objeto-restriccin con UML . . . . . . . . . . . . . . . 126
5.2. Ejemplo de rbol sintctico de una restriccin (objeto-restriccin) . . . . . 127 5.3. Indexacin entre variables y restricciones . . . . . . . . . . . . . . . . . . . 129 5.4. Tabla de almacenamiento de restricciones para la serializacin de los objetos 130 5.5. Ejemplo de Serializacin de Objetos-Restriccin . . . . . . . . . . . . . . . 131 5.6. Arquitectura de la Base de Datos de Restricciones . . . . . . . . . . . . . . 132 5.7. Modicacin del contenido de una Bases de Datos de Restricciones . . . . 134
5.8. Consulta sobre la Bases de Datos de Restricciones . . . . . . . . . . . . . . 136 5.9. Ejemplo de tablas rellenas . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 6.1. Diagrama de Tablas del ejemplo . . . . . . . . . . . . . . . . . . . . . . . 148
6.2. Ejemplo de tabla Provincias . . . . . . . . . . . . . . . . . . . . . . . . . . 148 6.3. Ejemplo de tablas que almacenan Restricciones . . . . . . . . . . . . . . . 149
6.4. Ejemplo de Cx
Cy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
. . . . . . . . . . . . . . . . . . . . . . 152
6.5. Pasos de la operacin de Seleccin
6.6. Relaciones tras la eliminacin por atributos univaluados (Paso I) . . . . . . 154 6.7. Relaciones tras la eliminacin por atributos variables de restriccin (Paso II)155 6.8. Tipos de relaciones entre los rangos de las variables de dos restricciones 6.9. Ejemplo de relacin entre restricciones en funcin de sus envolventes 6.10. Ejemplo de comparacin entre restricciones . 155
. . . 158
. . . . . . . . . . . . . . . . . 159
6.11. Ejemplo de restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 6.12. Representacin de restricciones . . . . . . . . . . . . . . . . . . . . . . . . 162 6.13. Relaciones tras la eliminacin por construccin de CSP (Paso III y IV) . . 162 6.14. Salida del ejemplo tras el Producto Cartesiano . . . . . . . . . . . . . . . 163
6.15. Tipos de Proyeccin: Horizontal y Vertical . . . . . . . . . . . . . . . . . . 164 6.16. Ejemplo de conjunto de restricciones . . . . . . . . . . . . . . . . . . . . . 166 6.17. Grafo de Restricciones de la Relacin para Proyeccin Horizontal 6.18. Ejemplo para realizar proyeccin Vertical . . . . . 169
. . . . . . . . . . . . . . . . . . 169
6.19. Grafo del Ejemplo para la proyeccin Vertical . . . . . . . . . . . . . . . . 170 6.20. rbol de decisin para construir el modelo y decidir qu tcnica lo resolver 172 6.21. Tipos de unin entre restricciones . . . . . . . . . . . . . . . . . . . . . . 178
6.22. Tipos de diferencias entre restricciones . . . . . . . . . . . . . . . . . . . . 179 7.1. Ejemplo introductorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 7.2. Red de Contextos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
7.3. Producto Cartesiano entre Componentes . . . . . . . . . . . . . . . . . . . 189 7.4. Tablas de las CARCs y los PCCM para el ejemplo introductorio . . . . . . 191 7.5. Ejemplo de Diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
7.6. Salida consulta con Proyeccin (V) . . . . . . . . . . . . . . . . . . . . . . 203 7.7. Salida consulta con Proyeccin (VI) . . . . . . . . . . . . . . . . . . . . . 204
7.8. Salida consulta con Proyeccin (VII) . . . . . . . . . . . . . . . . . . . . . 205 7.9. Salida consulta con Proyeccin (VIII) 8.1. Ejemplo de Diagnosis . . . . . . . . . . . . . . . . . . . . 206
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
8.2. Tiempos de Evaluacin para Proyeccin Simblica para Ecuaciones Polinmicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 8.3. Tiempos de Evaluacin para Proyeccin Simblica para Inecuaciones Polinmicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 8.4. Tiempos de Evaluacin para Proyeccin Numrica . . . . . . . . . . . . . 220 . . . 222
8.5. Tiempos de Evaluacin para Proyeccin Numrica con Optimizacin 8.6. Vista del Mapa Hbrida
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
8.7. Residenciales de la zona . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 8.8. Censos de la zona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
8.9. Tiempos de Evaluacin para la Seleccin . . . . . . . . . . . . . . . . . . . 232 8.10. Nmero de CSP creados para la Seleccin . . . . . . . . . . . . . . . . . . 232 8.11. Obras de la zona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 8.12. Tiempos de evaluacin para la Unin . . . . . . . . . . . . . . . . . . . . . 238 8.13. Nmero de CSP creados para la Unin . . . . . . . . . . . . . . . . . . . . 238 8.14. Tiempos de evaluacin de la Diferencia . . . . . . . . . . . . . . . . . . . . 244 8.15. Nmero de CSP creados para la Diferencia . . . . . . . . . . . . . . . . . 244
A.1. Tipos de Proyeccin: Horizontal y Vertical . . . . . . . . . . . . . . . . . . 258 A.2. Ejemplo transformacin grafo Nodo-Restricciones . . . . . . . . . . . . . . 260 A.3. Ejemplo de CRRV no mnimo . . . . . . . . . . . . . . . . . . . . . . . . . 262 A.4. Ejemplo de bsqueda de restricciones relacionadas por variables . . . . . . 267 B.1. Contenido de la tabla Componentes para el subsistema 1 . . . . . . . . . . 274 B.2. Contenido de la tabla Componentes para el subsistema 2 . . . . . . . . . . 274
B.3. Contenido de la tabla Componentes para el subsistema 3 . . . . . . . . . . 275 B.4. Contenido de la tabla Componentes para el subsistema 4 . . . . . . . . . . 275 B.5. Aplicacin para el almacenamiento de Restricciones . . . . . . . . . . . . . 276 B.6. Contenido de la tabla Calles . . . . . . . . . . . . . . . . . . . . . . . . . . 277 B.7. Contenido de la tabla Residenciales . . . . . . . . . . . . . . . . . . . . . . 278 B.8. Envolventes de las variables de Residenciales B.9. Contenido de la tabla de Censos . . . . . . . . . . . . . . . . 279
. . . . . . . . . . . . . . . . . . . . . . . 279
B.10.Contenido de la tabla de Obras . . . . . . . . . . . . . . . . . . . . . . . . 280
Agradecimientos
Slo quien ha hecho una tesis sabe lo graticante que es escribir los agradecimientos, intentar devolver un poco de lo mucho que se ha recibido. No me gustara que el agradecimiento a mis directores, los Doctores Rafael Martnez Gasca y Carmelo del Valle, quedara como una mencin normal. Ellos han sido excepcionales, su ayuda, comprensin y disposicin absoluta, han hecho que todos estos aos de investigacin hayan sido un placer. Sin ellos nada de esto habra sido posible. Importante tambin ha sido la participacin de el Dr. Miguel Toro, por sus grandes ideas y seguimiento durante todo este tiempo. Durante estos aos, el departamento se ha convertido tambin en mi casa, y mis compaeros me han ofrecido siempre ayuda y cario, especialmente Fernando de la Rosa, Pablo Fernndez, Roberto, Sergio, Joaqun, David, Diana, Irene, Vctor Daz, Carlos G. Vallejo y Juan Antonio lvarez. Pero han sido esenciales los que se han convertido en amigos del alma, Rafael Ceballos, Toi Reina, Octavio Martn, Antonio Talln y Beatriz Bernrdez, que han aguantado todos estos aos con incondicional amistad y comprensin. Todos mis amigos, los de toda la vida, han participado en esta tesis dndome innitos buenos momentos, recordndome que aunque la investigacin es todo, no todo es investigar. Muchos de ellos han seguido cada publicacin y captulo de esta tesis, como si fuera suya. Tantas llamadas de preocupacin le tengo que agradecer a Mnica, Eva, Sara, Migue, Josena, Isabel y Raquel. Tantas charlas y buenos momentos con Guillermina, Sandra y Nlida. Algunos, como Antonio, Loren y Jorge, han soportado mis nervios desde la carrera, compartido mis primeras penas y alegras en la Escuela de Informtica. Pero sin duda, lo ms importante en todo esto ha sido mi familia, mis sobrinos, que siempre sacan de m una sonrisa y me han dado fuerzas para continuar. Y mis hermanas, que siempre han estado ah, y s que siempre lo estarn. Las que me han enseado con el ejemplo que querer es poder.
No puede quedar fuera de este agradecimiento Carmen, no slo por dejar que le robe a Rafael innumerables veces, sino por su disposicin incondicional a prestarnos su ayuda y cario.
Resumen
Esta tesis doctoral aborda el problema de almacenar y tratar en una base de datos informacin compleja, como los datos econmicos, geogrcos o de ingeniera. Para ello se realiza un anlisis de los diferentes modelos lgicos, tipos de gestores de bases de datos y aplicaciones en las que intervienen dichos datos complejos. Debido a que los datos pueden ser de naturalezas diferentes, en la actualidad es necesario disear soluciones a medida para cada tipo de problema cuando sus datos son heterogneos. De entre todas las propuestas existentes, las Bases de Datos de Restricciones son el centro de esta tesis, ya que dicha informacin se puede representar mediante el uso de restricciones, lo que signica un conjunto de variables denidas sobre un dominio relacionadas entre s. Si se extendiera el modelo de datos para soportar datos complejos utilizando las Bases de Datos de Restricciones, toda aquella informacin que pudiera ser representada mediante restricciones no necesitara adaptarse al gestor de bases de datos. La propuesta en la que se centra esta tesis, es un gestor de bases de datos que da una solucin genrica para las aplicaciones que utilizan datos complejos representados mediante restricciones. En esta memoria de tesis se realiza un anlisis de las propuestas existentes para las Bases de Datos de Restricciones, detectando aquellos aspectos que pueden ser mejorados. Estas mejoras implicarn la redenicin del modelo de datos de las Bases de Datos de Restricciones, proponiendo tres tipos de atributos: atributo clsico, atributo restriccin y atributo variable de restriccin. Derivado de este nuevo modelo y estos nuevos atributos, ser necesario redenir las cinco operaciones primitivas del lgebra relacional para el uso de restricciones, ampliando el lenguaje de consulta SQL. Esto signicar modicar y ampliar dichas operaciones, y los operadores que pueden verse involucrados para los diferentes tipos de atributos. Una vez ampliada la semntica y la sintaxis de SQL, se propone una arquitectura que permite que la evaluacin de las diferentes consultas sea eciente, diseando diferentes
estrategias en funcin de los datos y el tipo de consulta. Junto a esto, se ha denido un conjunto de algoritmos para cada una de las operaciones mejorando la eciente computacional de la evaluacin de consultas. Finalmente, se realiza un anlisis experimental mediante casos de prueba para comprobar la efectividad y eciencia de un conjunto de consultas. La cobertura de los casos de prueba se ha hecho considerando los casos ms desfavorables, mostrando los tiempos medios de evaluacin para cada una de las operaciones del lgebra relacional extendida para restricciones.
Captulo 1 Introduccin
Desde la denicin de las bases de datos relacionales, stas han avanzado para dar soluciones cada vez ms ecientes y exibles al tratamiento de datos, dando soporte a estructuras cada vez ms complejas. Sin embargo, la investigacin en el rea de las bases de datos no ha crecido tan rpido como la complejidad de los datos que tienen que almacenar. Ante dicha problemtica, aplicaciones que trabajan con datos 'no tradicionales', como mdicos, multimedia, cientcos, de ingeniera o geogrcos, tienen que disear estructuras a medida de sus necesidades. En general, como datos 'no tradicionales' se conocen a aquellos que no toman valores nicos, sino que dependen de parmetros, variables o vienen denidos por relaciones entre variables mediante ecuaciones o inecuaciones matemticas. Esta creciente complejidad de las aplicaciones y los datos que tratan, orient a la comunidad de bases de datos a marcar en su investigacin nuevos retos, lo que en los aos
90 dio origen a las llamadas Constraint Databases (CDB). Las Constraint Databases extendieron el modelo de las bases de datos relacionales clsicas para dar cabida a datos de tipo Restriccin, donde una restriccin es un conjunto de variables denidas sobre un dominio y relacionadas entre s. Dicha relacin entre variables se puede describir de una manera compacta mediante una combinacin con operadores lgicos de ecuaciones e inecuaciones. La traduccin al espaol del trmino Constraint Database no es fcil, ya que debe dar a entender que es una base de datos donde es posible almacenar y tratar restricciones numricas como un tipo tradicional, al igual que los tipos numricos, cadenas o fechas. El trmino en espaol que se ha elegido en esta tesis para designar las Con-
straint Databases es Bases de Datos de Restricciones (BDdR) queriendo destacar

la capacidad de almacenar datos de tipo Restriccin, y marcando la diferencia con las
Captulo 1. Introduccin
restricciones de integridad o acceso ya existentes en las bases de datos. La razn por la cual los datos 'no tradicionales' se representan como restricciones es porque permite una forma genrica de representar cualquier dato que pueda ser descrito mediante una relacin entre variables. Esta idea permitir denir una manera nica de representar todos los datos que puedan ser descritos mediante restricciones, independientemente del nmero de variables, su semntica o de la aplicacin de los utilice. Esto signica que aplicaciones de caractersticas diferentes, como econmicas, estadsticas, geogrcas, mdicas o de ingeniera, utilizarn la misma funcionalidad para almacenar y tratar sus datos, facilitando el desarrollo e implementacin de dichas aplicaciones. El origen en el desarrollo de las Bases de Datos de Restricciones fue la representacin de datos que puedan tomar un nmero de valores muy grande o incluso innito de manera nita, ya que permiten mayor expresividad y compresin de la informacin. Un ejemplo sencillo para entender esta idea es la representacin mediante restricciones del rea rectangular mostrada en la gura 1.1.a.
Y
1 y 5 2 x 4 x, y
(a)
x2 + y2 4 x * y 1 x, y
(b)
Figura 1.1: Ejemplos de restricciones Si se utiliza una base de datos relacional para almacenar estas restricciones, una alternativa sera almacenar la restriccin mediante los puntos que la acotan:
(2, 1), (2, 5), (4, 1), (4, 5). De esta manera, se obtiene una manera vlida de representar
puntos, segmentos, lneas, rectngulos o caminos. Sin embargo, esta solucin no es la ms conveniente principalmente por dos razones: no todos los tipos de restricciones pueden ser representadas de esta forma, como el ejemplo de la gura 1.1.b; y por la evidente prdida de expresividad, ya que no se almacena la informacin en si, sino un conjunto de valores que la representan. Cmo se almacenara la informacin de la gura 1.1.b, teniendo en cuenta que los valores de x e y son innitos, en una base de datos relacional clsica? Ni que
Ejemplos Motivadores
decir tiene, que la discretizacin de los datos producira prdida de informacin, lo que implica prdida de precisin, junto a la creacin de bases de datos mucho ms grandes. El crecimiento de las bases de datos tambin inuir en las operaciones de consulta y modicacin, ya que tendran que ser analizados y modicados muchos ms registros que si la informacin estuviera almacenada con slo una restriccin. Sin embargo, si se tuviera la capacidad de almacenar la restriccin en s, la informacin sera completa y el espacio necesario para almacenarla muy pequeo, derivado de la compresin de la informacin. Adems no sera necesario tener distintos tipos de informacin ni formas de almacenarlas en funcin de la morfologa de la restriccin, tanto la gura 1.1.a como la 1.1.b, seran de tipo Restriccin. De esta forma, las Bases de Datos de Restricciones extienden el modelo de las bases relacionales clsicas, permitiendo tratar gran cantidad de datos o incluso innitos representados de forma nita. Esto se hace utilizando restricciones numricas, como una combinacin lgica (booleana) de ecuaciones e inecuaciones matemticas. Al utilizar datos ms complejos, las Bases de Datos de Restricciones necesitan tener denido un lenguaje de consulta donde estn contempladas las caractersticas de los nuevos datos, disear cmo se almacenarn las restricciones y cmo se evaluarn las consultas de una manera eciente. No es slo importante saber cmo se almacenar la informacin, igual de importante es conocer cmo se inferir conocimiento cuando la informacin se almacena de manera intensiva, mediante restricciones, en lugar de extensiva.
1.1.
Para entender mejor qu tipos de problemas solucionan las Bases de Datos de Restricciones, se muestran tres ejemplos que se analizarn en mayor profundidad a lo largo de esta tesis. Estos ejemplos justican que las bases de datos relacionales no son sucientemente expresivas para tratar datos no tradicionales. Los ejemplos que se muestran a continuacin, pueden ser almacenados en una Base de Datos de Restricciones, no teniendo que buscar soluciones a medida para cada caso, y reduciendo la complejidad de las aplicaciones que utilizan dichos datos, ya que ser resuelta por el gestor de bases de datos. Al igual que no es necesario adaptar los gestores de bases de datos relacionales para tratar datos de tipo administrativo, se busca denir un gestor de bases de datos para trabajar con restricciones.
Sistemas de Informacin Geogrca:
Las BDdR han utilizado el mbito de los sistemas de informacin geogrca, como uno de sus ms destacables casos de estudio. Esto es debido a que los datos espacio-temporales son fcilmente representables mediante restricciones. Un ejemplo podra ser una base de datos que almacenara toda la informacin relacionada a las cosechas de una regin, por lo que se podran almacenar los propietarios, el tipo de plantacin, u otros datos de tipo econmico. Estos datos pueden ser almacenados en una base de datos relacional clsica, mientras que las parcelas podran ser representadas mediante restricciones. Un ejemplo de las parcelas es el mostrado en la gura 1.2, donde tambin se representa el recorrido de un avin que va a fumigar dichas cosechas. El recorrido del avin tambin puede ser representado mediante restricciones donde la variable tiempo est involucrada.
Y
Parcela 1
Parcela 2
Parcela 3
Parcela 5 Parcela 4
Parcela 6
Parcela 7
Figura 1.2: Ejemplo Motivador I. Sistema de Informacin Geogrca Este tipo de informacin da cabida a consultas donde pueden estar involucrados datos tradicionales, como:
Quin es el propietario de la parcela 6? Qu tipo de cosecha tiene la parcela 3?

Pero hay consultas que no pueden ser resueltas sin un tratamiento especial de las restricciones que representan la informacin, como por ejemplo:
Qu parcelas no son atravesadas por el avin? Quines son los propietarios de las parcelas atravesadas por el avin? Qu parcelas sern atravesadas por el avin entre los instantes de tiempo 5 y 15?
Qu parcelas estn al sur de la parcela 2?
Sistemas Econmicos:
Los sistemas econmicos tambin se pueden utilizar como un ejemplo apropiado para el uso de BDdR, ya que gran cantidad de datos, como los impuestos a pagar en funcin de los ingresos o el crecimiento del mercado a lo largo del tiempo, no pueden ser representados directamente en las bases de datos relacionales clsicas. Es posible encontrar variables que dependen de otros parmetros, no tomando valores nicos, como es el caso de los impuestos en funcin de los ingresos representados en la gura 1.3. En dicha gura se muestran los impuestos que se tienen que pagar, para cuatro pases, en funcin de los ingresos.
4000 3500 3000 2500 2000 1500 1000 500 0
00 00 00 00 00 00 00 00 00 10 30 50 70 90 00 00 0 0 0 0 0
Impuestos
Pas A Pas B Pas C Pas D
11
13
Ingresos
Figura 1.3: Ejemplo Motivador II. Sistema Econmico Si no se utilizaran restricciones, sera necesario almacenar todas las posibles relaciones entre Ingresos e Impuestos para todos los pases. Esto generara gran cantidad de tuplas y una informacin incompleta, ya que las combinaciones son innitas, inconveniente que evita el uso de BDdR. Adems, si la informacin se representa mediante restricciones, se podan realizar consultas como:
En qu pas se pagan menos impuestos para unos ingresos de 50.001 euros? Qu impuestos se pagan en el pas C para unos ingresos de 34.000 euros? Para cualquier ingreso se paga menos en el pas D que en el pas A?
En la tesis de Gross [68] se muestra otro ejemplo econmico, donde una empresa quiere almacenar la informacin relativa a sus labores de importacin y exportacin, junto a datos administrativos propios de cualquier empresa como son empleados, departamentos, productos . . . Adems de estos datos, tiene informacin relativa a
15
los impuestos que pagar en funcin de si es compra, venta, del pas y la empresa con la que negocie, o de cmo ucte el mercado de valores. Para la empresa no slo ser un reto almacenar la informacin, tambin poder obtener el mayor rendimiento de ella, pudiendo minimizar gastos o prevenir cambios econmicos. Sin duda, el ideal de tener una base de datos que pueda trabajar con esta informacin compleja al igual que con los datos administrativos, facilitara el desarrollo de las aplicaciones que usan dichos datos, siendo el objetivo que persiguen las BDdR.
Diagnosis de Fallos Basada en Modelos:

Pese a que los datos espacio-temporales han sido el motor de las primeras justicaciones para la utilizacin de las bases de datos con restricciones, tambin existen otros campos que podran ser sensiblemente mejorados, ste es el caso de la diagnosis de fallos basada en modelos. Aunque en el captulo 7 se explica con ms detalles en qu consiste la diagnosis de fallos, en este punto se describen algunas ideas para motivar su uso en las BDdR. La idea de la diagnosis basada en modelos descrita en [127] radica en la comparacin entre el comportamiento esperado de un sistema y el comportamiento observado. El comportamiento esperado del sistema se establece mediante la creacin de un modelo que describa cada uno de los subsistemas que lo forman mediante restricciones, y la relacin entre ellos mediante variables. Para obtener el comportamiento observado es necesario colocar sensores en el sistema que va a ser diagnosticado. Un ejemplo muy utilizado para introducir la diagnosis basada en modelos es el mostrado en la Figura 1.4. Dicho ejemplo muestra 5 componentes, de los cuales 3 son multiplicadores (Mi ) y 2 sumadores (Ai ), relacionados mediante las variables (x, y , z ) y con sensores colocados en las entradas y las salidas (a, b, c, d, e, f , g ). Para almacenar esta informacin en una base de datos, ser necesario utilizar una BDdR, ya que las combinaciones de valores que pueden tomar las variables son innitos y sera imposible almacenarlos extensivamente utilizando una base de datos relacional. El ejemplo de la diagnosis basada en modelos no es un caso de estudio ms donde son necesarias las Bases de Datos de Restricciones por tratar datos no tradicionales, el eje de su aportacin radica en que, en oposicin a los datos espacio-temporales, existe mayor nmero de variables, y el valor de ellas puede depender a su vez de otras, teniendo una clara dependencia. En los sistemas de informacin geogrca, se trabajar como mximo con cuatro dimensiones (x, y, z, t), mientras que los
Contexto del Problema
a b c d e
M1 M2
x y A1 A2 f g
M3
Figura 1.4: Ejemplo Motivador III. Sistema para la Diagnosis Basada en Modelos
sistemas formados por componentes pueden estar constituidos por gran cantidad de variables. Otra caracterstica de la diagnosis basada en modelos es la relacin entre el comportamiento de los distintos componentes, ya que los valores de salida de un componente no slo est determinado por l, sino tambin por los valores de las variables que le suministren otros componentes. Esta ampliacin del nmero de variables y de la complejidad del sistema, fuerza la denicin de nuevos tipos de consultas y la bsqueda de diseos de bases de datos que las soporten ms all de las propuestas en los sistemas de informacin geogrca. Entre los ejemplos de consultas sobre este tipo de sistemas, donde existen restricciones involucradas, se encuentran:
Qu valor tiene f si a = 4, b = 1, c = 2, d = 4? Qu componente est fallando si los sensores obtienen los valores . . .? Qu componentes pueden estar fallando si la variable g es incorrecta? Obtener posibles valores que toman los sensores si el sistema funcionara correctamente. Lo que signica obtener instancias de las variables a, b, c, d y f . Un ejemplo de salida es: {a, b, c, d, e, f , g } = {1, 1, 2, 5, 3, 7, 11}.
Qu relacin de comportamiento tienen las variables a, b, c, d y f ? En este

caso se obtendra una nueva restriccin (a c + b d = f ) que relaciona las variables de manera simblica.
1.2.
El modelo relacional propuesto por Codd [33], considerado como uno de los pilares ms importantes en las bases de datos relacionales, est dividido en dos niveles, lgico y
fsico. La capa lgica es sobre la cual se especican las consultas, mientras que la capa
fsica describe el almacenamiento fsico de los datos, la organizacin de cheros y las rutas de acceso a la informacin. Desde que se deni este modelo, la complejidad de los tipos de datos que se deben tratar ha ido creciendo, por lo que el modelo relacional ya no es suciente. Estas nuevas necesidades fueron recogidas en los aos 80 con la aparicin de la orientacin a objetos y la consecuente adaptacin de las bases de datos [3], aunque alejndose en algunos aspectos del modelo relacional original, caractersticas que se analizarn en el captulo 2. El siguiente paso en la adaptacin a datos ms complejos, fue la creacin de las bases de datos objeto-relacionales [143] que dan cabida a la orientacin a objetos pero acercndose ms a la estructura del modelo relacional. En paralelo con estos cambios en las bases de datos surgieron las Bases de Datos de Restricciones, con el trabajo de Kanellakis, Kuper y Revesz [84], por lo que han convivido con muchos de los avances sufridos en las bases de datos relacionales, aunque no siempre hacindose eco de las ventajas que stas ofrecan. Las Bases de Datos de Restricciones se originaron basndose en las investigaciones relacionadas con DATALOG [28] y la Programacin Lgica con Restricciones (Constraint Logic Programming - CLP) [34][82]. Inicialmente, la motivacin consisti en combinar los trabajos en ambas reas, con el objetivo de obtener versiones ms ptimas de la Programacin Lgica basada en Restricciones utilizando el modelo de las bases de datos. Para abordar esta propuesta, se parti de un modelo de datos introducido en [93], fundamentado en considerar una tupla de una base de datos como un conjunto de restricciones de igualdad o desigualdad en los atributos de dicha tupla, siendo las restricciones un mecanismo natural de especicar las consultas de similitud en series de datos. Un ejemplo aclarador de esta armacin es el presentado en [94] mostrado en la gura 1.5, donde un conjunto de tuplas de una relacin puede ser representado por una restriccin. Cada tupla de una relacin est relacionada con las restantes tuplas con el operador lgico de disjuncin (), mientras que los atributos que forman una tupla tienen una relacin lgica de conjuncin () con el resto de tuplas. La mayor contribucin aportada por las BDdR no radica simplemente en utilizar las restricciones como objetivo, sino como medio para una mayor expresividad en los datos. Esto origin cambios en el modelos propuesto por Codd, incrementando el nivel de abstraccin entre la capa fsica de datos y la semntica que dichos datos pueden tomar. Esto alent a incluir una capa adicional, analizada en [60], a la arquitectura conceptual de las bases de datos que se muestra en la gura 1.6. Esta capa es el resultado de dividir
x a1 a2 a3
y b1 b2 b3
( x = a1 y = b1 ) ( x = a2 y = b2 ) ( x = a3 y = b3 )
Figura 1.5: Ejemplo de representacin de un conjunto de tuplas como una restriccin la capa lgica de las bases de datos clsicas en dos nuevas capas: abstracta y concreta. La capa lgica abstracta representa un conjunto de datos que pueden ser innitos, como las relaciones entre variables mostrados en los ejemplos de las guras 1.2, 1.3 1.4, y deber soportar la semntica de las consultas sobre dichos datos. Mientras que en la capa lgica
concreta se representar dicha informacin de una manera nita mediante restricciones.

Datos Tradicionales Capa Lgica: Capa sobre la que se define la semntica de las consultas sobre un conjunto finito de tuplas Datos No Tradicionales Capa lgica abstracta: Capa sobre la que se define la semntica de las consultas sobre un conjunto infinito de tuplas Capa lgica concreta: Representacin mediante restricciones
Capa fsica: fichero de almacenamiento, estructura de indexacin, mtodos de acceso a datos...
Figura 1.6: Modelos de datos relacional y con restricciones Desde que se originaron las Bases de Datos de Restricciones hasta la actualidad, han surgido muchas teoras y propuestas pese a ser una comunidad pequea. Y aunque muchos de los problemas ocasionados por el tratamiento y almacenamiento de restricciones fueron detectados y solucionados, no han sido incluidos todos los benecios de las bases de datos relacionales y las objeto-relacionales. Las propuestas en el campo de las BDdR se mantienen alejadas de las bases de datos relacionales, hacindose patente la prdida de eciencia en la evaluacin de las consultas, en el almacenamiento, obtencin y modicacin de los datos tal como se analizar a lo largo de esta tesis.
10
1.3. Justicacin del Trabajo

Aunque las bases de datos comerciales se han desarrollado mucho para adaptarse a las nuevas necesidades, tanto en aspectos de expresividad como en eciencia, sin duda queda mucho camino por recorrer. Una deciencia destacable es que el tratamiento de los datos no tradicionales no est homogeneizado, y no existen propuestas fcilmente adaptables a los distintos tipos de problemas. Esto signica que las aplicaciones tienen que adaptarse a las propuestas existentes, como ocurre en los sistemas de informacin geogrca, en lugar de buscar soluciones que se adapten a las aplicaciones. Un ejemplo puede ser una empresa que tiene que tratar datos que no slo son de tipo administrativos (nombre, telfono, edad . . .), como por ejemplo las curvas que describan sus benecios por departamentos en funcin de distintos parmetros. Dicha empresa se enfrentar a mucho ms que realizar el diseo y la implementacin necesaria en cualquier aplicacin, tendr que decidir cmo se almacena la informacin y cmo ser tratada para inferir el conocimiento que necesite en cada momento. Esta problemtica es cada vez ms frecuente, ya que cada vez los datos que deben ser almacenados son ms complejos. Aunque existen gran cantidad de prototipos de BDdR, hay caractersticas de gran importancia a las cuales no se les ha prestado la suciente atencin. Como se ha presentado en el apartado de Contexto del Problema, se ha denido la extensin del modelo relacional para las BDdR, quedando por estudiar en profundidad aspectos de importancia como: Los prototipos desarrollados hasta el momento no explotan por completo las ventajas de las bases de datos relacionales, tratando todas la informacin como restricciones e ignorando las ventajas del paradigma relacional para los datos que toman valores nitos. Otro de los inconvenientes de las soluciones existentes es que los lenguajes y arquitecturas propuestas son dependientes de la ndole de los datos que tratan, mayoritariamente orientado a sistemas geogrcos. Esto provoca que no sean soluciones genricas y con sintaxis alejadas de SQL, lo que supone un mayor esfuerzo por parte del usuario para utilizar una BDdR. Ya que la semntica debe ser redenida para los datos representados como restricciones, los lenguajes propuestos hasta el momento para trabajar con BDdR tienen las mismas capacidades que el lenguaje SQL denido para las bases de datos
Objetivos de la Tesis
11
relacionales clsicas? El objetivo de esta pregunta es conocer si se pueden hacer el mismo tipo de consultas sobre los datos que son almacenados como restricciones, que sobre los datos tradicionales. A lo largo de esta tesis se darn las explicaciones pertinentes para demostrar que la respuesta a esta pregunta es no. Es fcil denir un modelo que represente las restricciones desde un punto de vista lgico y fsico como se muestra en la gura 1.6, pero es tan fcil realizar la transformacin de la restriccin entre una representacin y otra en la prctica?; y realmente se han ofrecido soluciones ecientes a nivel computacional? Esta pregunta sin duda est relacionada con una de las mayores deciencias en el campo de la investigacin de las Bases de Datos de Restricciones, y la razn por la que ha tenido pocas de pocos avances, la dicultad de pasar de la teora a la prctica. De esto tambin se deriva la falta de estudios a nivel de optimizacin en la evaluacin de consultas. Pese a que las restricciones se utilizan como herramienta para representar relaciones entre valores, no se puede olvidar la importancia de los elementos que componen y relacionan las restricciones, las variables. Las propuestas en las BDdR han denido consultas sobre dichas variables? Cmo se inere informacin relativa a las variables y cmo relacionan distintas restricciones? Esta problemtica es otra de las asignaturas pendientes en las BDdR. Por ejemplo para casos ms complejos donde hay relacionadas muchas variables, como el ejemplo de los impuestos comentado con anterioridad, cmo se obtiene qu impuesto es el mnimo a pagar si esta informacin no est almacenada explcitamente?
1.4.
Objetivos de la Tesis
El objetivo general de esta tesis es Denir un Gestor de Base de Datos de
Restricciones que permita almacenar y consultar datos clsicos, restricciones y las variables que las forman, al igual que las bases de datos tradicionales tratan los datos clsicos. A este Gestor de Bases de Datos de Restricciones se le llamar
LORCDB, y para obtener este objetivo general se presentan distintos subobjetivos:
Redenir el concepto de Base de Datos de Restricciones para que se acerque

lo ms posible a las bases de datos relacionales. Por esta razn se dene un nuevo
12
tipo de dato Restriccin que tendr la capacidad de representar un nmero de datos innito de forma nita, permitiendo que la informacin sea ms completa y precisa. Esto signica que tanto la sintaxis como la semntica de las consultas tiene que cambiar para contemplar este nuevo tipo reejando su complejidad.
Redenir formalmente las operaciones del lgebra relacional para el tratamiento de restricciones. Existen cinco operaciones primitivas en el lgebra relacional (seleccin, proyeccin, producto cartesiano, unin y diferencia) con las que se pueden denir el resto de las operaciones sobre relaciones. Al tener un tipo de datos Restriccin, estas cinco operaciones y sus operadores tienen que ser analizadas y ampliadas.
Ampliar el lenguaje SQL para el tratamiento de restricciones. Acorde con

el lgebra relacional denida para restricciones, se describir una extensin de SQL dando origen a un nuevo lenguaje llamado CORQL (Constraint Object-Relational Query Language).
Disear una arquitectura que permita almacenar restricciones, junto a la utilizacin de las tcnicas necesarias para la inferencia de conocimiento de la informacin de la base de datos. La arquitectura debe ser modular, fcilmente
congurable y que permita adaptar bases de datos ya existentes, facilitando su migracin. Para esto se utilizar un gestor de Bases de Datos Objeto-Relaciones, en este caso OracleT M 9.i. Para inferir el conocimiento la arquitectura se apoyar en dos familias de tcnicas: numricas y simblicas.
Analizar la complejidad computacional de la evaluacin de cada uno de los operadores, buscando soluciones ecientes. Para mejorar la eciencia en
la evaluacin de consultas, se proponen un conjunto de mejoras que se explicarn con detalle a lo largo de la tesis. Entre ellas caben destacar la indexacin de variables y restricciones, el etiquetado de restricciones por su tipo para su resolucin, el almacenamiento de envolventes de los dominios de las variables, y la denicin de heursticas que ayuden a la resolucin de problemas de restricciones.
Buscar una solucin adaptable a distintos problemas. La arquitectura que

se propone servir como capa lgica para el tratamiento de cualquier aplicacin cuyos datos se puedan representa mediante restricciones polinmicas y lineales. Con
Marco de la Tesis
13
el objetivo de mostrar cmo se utiliza para distintas aplicaciones, se usarn distintos ejemplos donde al arquitectura facilita el tratamiento de los datos, ejemplos econmicos, sistemas de informacin geogrca y diagnosis de fallos basada en modelos. La incorporacin de las BDdR no slo facilita el desarrollo de aplicaciones al incorporar gran parte de la lgica a la base de datos, tambin implica la mejora de las aplicaciones en s. En el caso de la diagnosis de fallos, muchas de sus fases han sido mejoradas gracias a la utilizacin de las BDdR y validado por la comunidad de diagnosis, ms all de la claras ventajas que ofrece tener almacenada la informacin de un sistema a nivel de persistencia y facilidad de acceso. Todos estos objetivos dan como resultado una arquitectura sobre Bases de Datos de Restricciones a la que se ha llamado Labelled Object-Relational Constraint
Database - LORCDB, intentando reejar algunas de las caractersticas de dicha arquitectura, como es la utilizacin de bases de datos objeto-relacionales, y el etiquetado de restricciones para facilitar la evaluacin de consultas.
1.5.
tigacin:
Marco de la Tesis
Esta tesis doctoral se ha desarrollado en el marco de los siguientes proyectos de inves-
Desarrollo de herramientas basadas en modelos semicualitativos para el anlisis de sistemas dinmicos. Aplicacin a la supervisin, control y prediccin de comportamiento (CICYT DP I 2000 0666 C 02 02). Dentro del proyecto, la tarea relacionada con esta tesis consista en ampliar el tipo de conocimiento con el objetivo de realizar las consultas sobre sistemas semicualitativos tanto estticos como dinmicos. En este sentido, se propuso un lenguaje de consultas sobre las propiedades cualitativas del estacionario y del transitorio de los sistemas dinmicos semicualitativos sujetos a restricciones. Este proyecto dio como resultado un conjunto de herramienta para el tratamiento computacional de las bases de datos empricas, evitando informacin no relevante para su posterior tratamiento con tcnicas de aprendizaje supervisado.
Investigador principal: Rafael Martnez Gasca Perodo de duracin: 2000 2003
14
Automatizacin de la deteccin y diagnosis de fallos de sistemas estticos y dinmicos usando conocimiento semicualitativo (CICYT DP I 2003 07146 C 02 01). Este proyecto abarca la diagnosis basada en modelos con
tratamiento simblico de la informacin. La descripcin del sistema se presenta mediante un conjunto de restricciones, almacenadas en una Base de Datos de Restricciones. El tratamiento de la informacin utilizando como capa lgica las bases de datos, no slo mejoraron la persistencia, recuperacin y fcil composicin del los sistemas, tambin mejor muchas de las fases del proceso de diagnosis. Gracias a la utilizacin de las Bases de Datos de Restricciones en la diagnosis basada en modelos, se plantearon nuevas necesidades semnticas de las restricciones y su tratamiento.
Investigador principal: Rafael Martnez Gasca Perodo de duracin: 2003 2006 Deteccin automtica de fallos, diagnosis y tolerancia a fallos en sistemas con incertidumbre y distribuidos. (CICYT DP I 2006 15476 C 02 00). Este
proyecto aborda entre sus tareas el tratamiento de los datos relativos a la diagnosis cuando el sistema est distribuido, tanto semnticamente como estructuralmente. En este caso, las Bases de Datos de Restricciones tienen que ser ampliadas para el tratamiento de restricciones distribuidas con la complejidad que conlleva la dispersin de los datos.
Investigador principal: Rafael Martnez Gasca Perodo de duracin: 2006 2009 Asistente virtual interactivo: Informacin para orientacin laboral (AVIOL) Dentro de este proyecto se realizan las tareas relacionadas con el acceso a bases
de datos heterogeneas: 'Anlisis y diseo de KSB ( Knowledge Service Bus)', 'Desarrollo de KSB', 'Conguracin, parametrizacin y pruebas' y 'Puesta en marcha y simulacin'. Proyecto realizado en colaboracin con Sadiel S.A.
Investigadores responsables: Rafael Martnez Gasca Y M. Teresa Gmez Perodo de duracin: 2007 2008
Estructura de la Tesis
15
1.6.
Estructura de la Tesis
Captulo 2. Antecedentes de las Bases de Datos. Las bases de datos han ido
mejorado en los ltimos aos y estos avances han afectado claramente a las BDdR. En este captulo se analizan diferentes caractersticas y su relacin con las Bases de Datos de Restricciones, como los modelos lgicos, la naturaleza de la informacin y el dominio de las aplicaciones.
El resto del documento est estructurado en los siguientes captulos:
Captulo 3. Antecedentes de las Bases de Datos de Restricciones. Desde los

aos 90, muchas han sido las deniciones y los prototipos desarrollados para BDdR, en este captulo se analizarn dichas aportaciones y qu caractersticas pueden ser mejoradas.
Captulo 4. Propuesta de Modelado para las Bases de Datos de Restricciones. Partiendo de la denicin original de Base de Datos de Restricciones,
se redene el concepto para ampliar la funcionalidad de las propuestas existentes. Esta redenicin conlleva la necesidad de ampliar la sintaxis y la semntica del lgebra relacional para restricciones, junto a las tcnicas utilizadas para la evaluacin de las consultas.
Captulo 5. Arquitectura LORCDB. Un Gestor para BDdR. Este captulo

muestran la arquitectura propuesta con sus distintos mdulos, los cuales permiten utilizar distintas tcnicas en funcin del tipo de consulta que se realice y las restricciones relacionadas con dicha consulta. En esta parte de la tesis se trata el paso de la capa lgica a la fsica, aportando soluciones para mejorar la eciencia, y dando soporte un nuevo lenguaje de consulta llamado CORQL.
Captulo 6. Implementacin del lenguaje CORQL. Muestra los detalles de

diseo e implementacin de las LORCDB, junto a cmo se almacenan las restricciones. Al representar la informacin de manera intensiva en forma de restriccin, su tratamiento es computacionalmente costoso. Para paliar este hecho, la arquitectura se ayuda de tcnicas de indexacin de informacin junto al desarrollo de un conjunto de algoritmos relacionados con cada una de las operaciones del lgebra relacional para restricciones. Los algoritmos se presentan sobre un ejemplo para un sistema de gestin de impuestos.
16
Captulo 7. La Diagnosis de Fallos Basada en Modelos: Un caso de estudio.

En este captulo se presenta cmo la utilizacin de BDdR puede facilitar y mejorar el proceso de diagnosis de fallos en un sistemas. La diagnosis basada en modelos nunca ha sido utilizada como caso de estudio en el mbito de las BDdR, y describe problemas de caractersticas muy diferentes a los sistemas de informacin geogrca. Utilizar las BDdR en reas tan dispares es posible gracias a que la arquitectura LORCDB no es dependiente del problema.
Captulo 8. Optimizacin de Evaluacin de Consultas en BDdR. En el

captulo 6 se presentan las caractersticas de las implementaciones para evaluar de manera ms eciente las consultas, y en este captulo se muestra de manera emprica cmo mejoran los tiempos de evaluacin de consultas. Se realizan anlisis para cada una de las operaciones del lgebra relacional que trabajan con restricciones, presentando resultados sobre sistemas para diagnosis de fallos basada en modelos, junto a sistemas de informacin geogrca.
Captulo 9. Conclusiones y Trabajos Futuros. Finalmente se presentan las

conclusiones de la tesis y las lneas de investigacin abiertas que quedarn como trabajos futuros.
Anexo A. Algoritmos para la Proyeccin Simblica. Este anexo presenta

los detalles relativos a los algoritmos relacionados con la operacin de proyeccin simblica sobre atributos de tipo variable de restriccin.
Anexo B. Tablas de Restricciones para el Anlisis de Eciencia. Muestra

las tablas de las Bases de Datos de Restricciones utilizadas en las pruebas empricas del captulo 8. Tambin se presenta en este anexo algunos detalles de una aplicacin desarrollada para obtener las restricciones que representan informacin relativa a sistemas de informacin geogrca.
Captulo 2 Antecedentes de las Bases de Datos

La mayora de las aplicaciones actuales hacen uso de las bases de datos para hacer persistente su informacin. Al ser un denominador comn, la creacin de mtodos ecientes para la evaluacin de consultas ha sido un rea de investigacin y desarrollo de gran importancia. Los distintos desarrollos han dado origen a diversas soluciones de caractersticas distintas. En este captulo se analizan tres de las caractersticas fundamentales que ayudan a clasicar y denir las bases de datos. Esta clasicacin ayudar a recorrer las distintas propuestas que se han desarrollado alrededor de las bases de datos hasta la actualidad, en funcin de: El dominio de las aplicaciones que utilizan y son almacenadas en las bases de datos. La naturaleza de la informacin a almacenar. El modelo lgico de almacenamiento que usan, y por extensin los lenguajes de consulta que se denen para utilizarlas. Estas caractersticas describen aspectos que diferencian una base de datos de otra, con la idea de cumplir principalmente dos objetivos, que han sido los motores del desarrollo de este rea de conocimiento: la bsqueda de representaciones de datos ms expresivos, y el desarrollo de bases de datos cada vez ms ecientes a nivel de evaluacin de consultas. Sin duda alguna, la creacin de nuevos dominios de aplicaciones cada vez ms complejos ha originado la bsqueda de nuevas soluciones, tanto para dar mayor versatilidad en la naturaleza de los datos que se almacenan, como en la denicin de nuevos soportes lgicos
18
Captulo 2. Antecedentes de las Bases de Datos
que les puedan dar cabida. Esta ampliacin a tipos ms complejos, junto al crecimiento de la cantidad de informacin, ha originado sistemas ms complejos y por lo tanto ms difciles de evaluar.
2.1. Introduccin
Desde que en la dcada de los 60 se empezaron a desarrollar los primeros sistemas gestores de bases de datos hasta la actualidad, se han propuesto diferentes soluciones al problema del almacenamiento y gestin de la informacin. El continuo crecimiento de la cantidad de informacin y la aparicin de nuevos mbitos de trabajos y aplicaciones, han hecho que las necesidades de las bases de datos hayan crecido en concordancia. Dicha ampliacin sucesiva de las bases de datos, ha venido principalmente provocada por la bsqueda de nuevas soluciones que permitieran tener mayor capacidad expresiva para representar los datos. Una de las caractersticas de las bases de datos que permitirn su clasicacin es el
dominio de la aplicacin a la cual dan soporte, ya que dichos dominios pueden necesitar
menor o mayor expresividad. Con respecto a esta divisin, se analizarn algunos ejemplos como las bases de datos administrativas, de informacin geogrca, espacio-temporales, para diseo asistido por ordenador . . . La capacidad expresiva de datos que se pueden almacenar da origen a una clasicacin en funcin de la naturaleza de la informacin que almacena la base de datos:
Bases de Datos Extensivas: Son bases de datos donde la informacin est almacenada de forma explcita, y donde las consultas obtienen un subconjunto de la informacin almacenada directamente en la base de datos. Un ejemplo de informacin extensiva puede ser cmo se almacena una persona, mediante su edad, nombre, DNI . . .
Bases de Datos Intensivas: Estas bases de datos pueden deducir informacin no

almacenada explcitamente en la base de datos, sino mediante un grupo que datos que representan la informacin completa. Un ejemplo de informacin intensiva es la representacin del movimiento de un avin, donde se almacena la ecuacin que describe su ruta, pero no todos los puntos explcitos por los que pasa.
Dominio de Aplicacin
19
Independientemente de que los datos se representen de forma intensiva o extensiva, se pueden utilizar distintos gestores de bases de datos para almacenarlos. El modelo lgico para almacenar la informacin ha ido avanzando desde los primitivos sistemas de archivos, pasando por las bases de datos relacionales, las orientadas a objetos y las objetorelacionales, dando origen a los distintos modelos lgicos de almacenamiento. En funcin del dominio de la aplicacin, se necesitar mayor o menor capacidad expresiva y ser necesario decidir cmo se representar la informacin (intensiva o extensiva) y qu modelo lgico se utilizar para su almacenamiento y gestin. Estas tres caractersticas (dominio de las aplicaciones, naturaleza de la informacin y modelo lgico) describirn cada base de datos, como se muestra en la gura 2.1, y que se detallarn a lo largo del captulo.
Modelo Lgico
Naturaleza de la Informacin
Dominio de la Aplicacin
Figura 2.1: Caractersticas de las bases de datos
2.2.
Los incesantes cambios en los tipos de datos que gestionan las bases de datos han sido el principal impulsor de nuevas tecnologas. Aunque las bases de datos tradicionales dan cabida a gran cantidad de aplicaciones, ya que tratan datos administrativos, existen tipos de datos que no son gestionados de forma natural. En las ltimas dcadas la complejidad de las aplicaciones ha ido creciendo, demandando nuevas soluciones ya que la utilizacin de las bases de datos relacionales clsicas no es suciente. En las prximas subsecciones se presentan algunos ejemplos de estos dominios especialmente relacionados con esta tesis.
20
2.2.1. CAD - Computer-Aided Design y CAM - Computer-Aided Manufacturing

El diseo asistido por ordenador (Computer-Aided Design) [154] trabaja con datos
relativos a diseos mecnicos y elctricos de coches, aviones, barcos, circuitos integrados
. . ., involucrando software y en algunas ocasiones hardware especco. Permite disear

en dos o tres dimensiones mediante elementos geomtricos, como puntos, lneas, arcos, supercies y slidos, para obtener un modelo numrico de un objeto o conjunto de ellos.
La fabricacin asistida por ordenador (Computer-Aided Manufacturing) almacena

datos similares a los que utiliza el diseo asistido por ordenador, junto a datos relativos a la produccin de elementos discretos, como el montaje, y a la produccin de carcter continuo, como la sntesis qumica. Estas aplicaciones estn a menudo organizadas en una jerarqua, existiendo una aplicacin de nivel superior que monitoriza procesos individuales de fabricacin. Estas aplicaciones deben responder en tiempo real y ser capaces de ajustar los procesos para mantener un rendimiento ptimo con unas tolerancias mnimas. Estas aplicaciones utilizan una combinacin de algoritmos estndar y reglas personalizadas para responder a diferentes condiciones dependientes del sistema. Toda esta informacin debe ser almacenada en la base de datos, alejndose mucho de las caractersticas de los datos administrativos, por lo que claramente necesitar soportes de almacenamiento con otras cualidades. Un ejemplo de sistema que utiliza esta tecnologa es FORAN [138], una aplicacin que ayuda al diseo de barcos ofreciendo soluciones al ensamblaje, anlisis de probabilidades de error en la construccin, caractersticas elctricas . . . La geometra de los objetos que se describen en estos sistemas, se denen mediante un conjunto de puntos, lneas, crculos, conos, . . ., en 2 3 dimensiones. Adems de su forma geomtrica, se pueden denir su comportamiento individual y su relacin con el resto de objetos, junto a la planicacin de acciones para la composicin entre ellos para construir objetos ms complejos [135][139]. Entre las caractersticas que hacen ms complejos estos tipos de sistemas destacan: El diseo no es esttico, sino que evoluciona a lo largo del tiempo. Esto supone que las estructuras que almacenan el diseo del sistema tienen que ser fcilmente adaptables.
21
Los sistemas suelen tener muchas dependencias topolgicas y funcionales, lo que signica que un cambio afectar a gran cantidad de objetos del sistema. El cambio del diseo puede conllevar cambios en otras partes del diseo y muy probables cambios en los programas que acceden a ellos, lo que resulta muy costoso de mantener. El problema de la ingeniera cooperativa es usual, donde distintos roles de usuarios pueden acceder al sistema teniendo que tomar decisiones parciales para obtener un resultado nal coherente.
2.2.2. CIM - Computer Integrated Manufacturing y PDM - Product Data Management

La fabricacin integrada por ordenador (Computer Integrated Manufacturing) es un
rea que se origin ante la creciente competitividad entre las empresas en el mercado actual. El mundo empresarial ha establecido que, estratgicamente hablando, la integracin de todas las reas de una empresa en sistema nico es la opcin ms viable para incrementar su productividad y crear empresas ms competitivas. John W. Bernard lo dene como "la integracin de los computadores digitales en todos los aspectos del proceso de manufactura", ya que se trata de un sistema complejo, de mltiples capas, diseado con el propsito de minimizar los gastos y crear riqueza en todos los aspectos.
La gestin de los datos del producto (Product Data Management) es un rea orientada a
controlar los datos relativos a los productos. Estos sistemas crean y controlan las relaciones entre los conjuntos de datos que denen un producto, almacenando dichas relaciones en una base de datos. Este tipo de aplicaciones son importantes para la gestin del ciclo de vida del producto, pudiendo contemplar desde los requisitos, especicaciones, planicacin de fabricacin o ensamblaje, y pruebas sobre el producto nal. La problemtica de ambas tecnologas es que deben intervenir en todo el proceso de fabricacin, desde la materia prima hasta el producto nal. Esto conlleva que todos los departamentos, pese a ser independientes, tienen que estar coordinados para obtener el producto nal, teniendo en cuenta tanto la caracterstica software como hardware del proceso.
22
2.2.3. CASE - Computer-Aided Software Engineering

La ingeniera del software asistida por ordenador (Computer-Aided Software Engineering) almacena datos relativos a las etapas del ciclo de vida del software: planicacin, recopilacin y anlisis de requisitos, diseo, implementacin, pruebas, mantenimiento y documentacin. Al igual que ocurre en la fabricacin asistida por ordenador o la fabricacin integrada por ordenador, la ingeniera cooperativa es imprescindible. Las herramientas CASE deben permitir compartir de forma concurrente el diseo del proyecto, el cdigo y la documentacin. Tambin debe controlar las dependencias entre dichos componentes y ayudar a la gestin de cambios, facilitando la coordinacin de diversas actividades de gestin de proyecto y la monitorizacin del progreso.
2.2.4. GIS - Geographic Information System y Bases de Datos Espacio-Temporales

Los sistemas de informacin geogrca (Geographic Information System) [71][125]
tienen especial importancia en esta tesis, ya que es el caso de uso ms extendido en las Bases de Datos de Restricciones. Buena parte de los datos de dichos sistemas derivan de las fotografas va satlite, por lo que la cantidad de informacin tiende a ser muy grande. Las consultas sobre las bases de datos que almacenan dicha informacin pueden implicar la identicacin de caractersticas, basndose por ejemplo en la forma, el color o la textura, utilizando tcnicas avanzadas de reconocimiento de patrones. En los sistemas de informacin geogrca se pueden establecer relaciones entre datos de localizacin, como direcciones, edicios, parcelas y calles. Tambin es posible representar distintos tipos de conocimiento sobre las regiones geogrcas, lo que se describe mediante diferentes capas para que sean fcilmente tratables y entendibles.
Creacin de Datos
Las aplicaciones modernas de sistemas de informacin geogrca se basan en la digitalizacin de la informacin, para lo cual existen un conjunto de mtodos. La mayora de ellos transforman los mapas impresos a digitales utilizando diseo asistido por ordenador y referencias geogrcas.
23
Los distintos objetos que conforman un sistema geogrco deben estar relacionados, por ejemplo para establecer las correspondencias entre la informacin meteorolgica, obtenida mediante satlite, con las regiones polticas de un mapa. Para que un sistema geogrco tenga la capacidad de relacionar distintas capas de informacin, se utilizan referencias espaciales mediante variables (tpicamente x, y y z como coordenadas de longitud, latitud y altitud respectivamente). A su vez, esto le dar la posibilidad de trabajar con diferentes escalas.
Representacin de Datos
Los datos de los GIS representan objetos reales del mundo, como calles, terrenos o montaas, mediante datos digitales. Estos datos del mundo real pueden ser divididos en dos grupos: objetos discretos (como una casa) y reas continuas (como zonas de nubosidad). Existen dos mtodos para almacenar estos tipos de informacin: mediante mallas rectangulares o componentes geomtricos. Las mallas rectangulares (raster) consisten en celdas distribuidas mediante las y columnas, y donde cada celda lleva un valor discreto asociado, como un color, la cantidad de lluvia registrada o el tipo de terreno. Cada una de las celdas representar la informacin relativa a una porcin del mapa, que normalmente tiene forma cuadrada. Los componentes geomtricos son puntos, lneas y polgonos. Son especialmente frecuentes para representar las elevaciones del terrenos en sistemas en tres dimensiones, utilizando tcnicas de triangularizacin de supercies. Dichos componentes pueden a su vez tener informacin asociada como atributo del objeto En ambos tipos de modelos existen tanto ventajas como inconvenientes, y se utilizar una implementacin u otra en funcin de las caractersticas de la informacin que se almacena. En el caso de la representacin mediante mallas, generalmente se necesitar mucho mayor espacio de almacenamiento que en la utilizacin de componentes geomtricos. Sin embargo, el tamao utilizado por la malla es estable, no depende de la cantidad de objetos que tenga el sistema, no como ocurre en los sistemas con componentes geomtricos. A cambio, las implementaciones y las consultas con mallas de datos son mucho ms fciles que utilizando componentes geomtricos. De todas formas existen mtodos que transforman la informacin representada en un formato al otro.
24
Cuando se representan objetos que tambin tienen caractersticas espaciales y temporales, pero no exclusivamente ligadas a la informacin geogrca se hablar de bases de
datos espacio-temporales. Un ejemplo de estas aplicaciones puede ser el control de trco

de una ciudad, el trco areo en un aeropuerto, el movimiento de un robot o el anlisis de fenmenos meteorolgicos, donde es importante saber la variacin en el tiempo de un objeto. Estas bases de datos aaden la capacidad de asociar un atributo tiempo a los objetos que se tratan en los sistemas de informacin geogrca de una manera esttica. Esta caracterstica de movilidad ampla mucho los tipos de consultas que se pueden realizar, como cundo llover en una provincia o si dos aviones se encontrarn en su ruta.
2.3. Naturaleza de la informacin

Como se ha introducido en el comienzo del captulo, una forma de clasicar las bases de datos es en funcin de la naturaleza de la informacin que almacena, si es de manera intensiva o extensiva. Esta divisin no es excluyente, ya que todas las bases de datos intensivas pueden tener caractersticas extensivas, permitiendo que ambas caractersticas convivan.
Bases de Datos Extensivas:

Son aquellas que almacenan la informacin de forma explcita, y donde las consultas devolver un subconjunto de los datos almacenados. Tambin se pueden llamar por
induccin o por extraccin, ya que la salida de una consulta slo puede contener
informacin almacenada explcitamente en la base de datos. Las caractersticas de
induccin la poseen todas las bases de datos, independientemente de su modelo

lgico o implementacin, ya que todas tienen que dar la posibilidad de seleccionar una parte de la informacin que almacenan. Esta forma de almacenamiento es la ms usada en las aplicaciones administrativas, por ejemplo para almacenar todas la informacin scal de un conjunto de personas, junto a sus datos personales. En este ejemplo, las consultas del tipo obtener los nombres y direcciones de las personas
cuyos impuestos superen los 30.000 euros signicar seleccionar las personas con
dicha caracterstica y devolver slo los campos relativos a su nombre y direccin. En este caso toda la informacin que se obtiene tras la consulta est almacenada en la base de datos tal cual, slo hay que realizar una extraccin de ella.
Naturaleza de la informacin
25
Bases de Datos Intensivas:

En el caso de las bases de datos intensivas, la informacin que se almacena puede ser una representacin no literal o explcita de los datos. Las consultas sobre estas bases de datos pueden deducir informacin nueva, o lo que es lo mismo, conocimiento almacenado en la base de datos pero no de forma directa o explcita, sino inferido partiendo de la almacenada. Un caso de uso de este tipo de informacin se presenta en los sistemas espacio-temporales; por ejemplo para almacenar caractersticas de los aviones de forma extensiva, como el modelo, la compaa o el nmero de asientos, e informacin de forma intensiva como su ruta y sus probabilidades de retraso en funcin del tiempo. Sobre este tipo de informacin no slo es posible hacer consultas del tipo qu aviones son de un determinado modelo, tambin se podr inferir informacin como cundo pasa por encima de una determinada ciudad o si
dos aviones se encuentran en algn instante de tiempo. Representar de forma explcita esta informacin conllevara almacenar la posicin de los aviones en todos los instantes de tiempo, lo cual sera muy costoso a nivel de recursos de espacio. Para evitar el almacenamiento explcito, las bases de datos intensivas pueden representar su informacin de dos maneras:
Valores Representativos: Almacenando un subconjunto de datos que describan a los restantes, por ejemplo un segmento sobre las variables x, y puede ser representada mediante los extremos que la denen, por ejemplo {x = 0, y = 1} y {x = 4, y = 9}, de forma que de estos valores se puede inferir la ecuacin que representa los datos restantes. Esta forma de almacenar la informacin, es la que se utiliza en los sistemas de informacin geogrca cuando los datos son representados mediante componentes geomtricos.
Representacin Simblica de los datos: Utilizando una representacin

lgica o numrica de los posibles valores que pueden tomar, lo que para el ejemplo anterior sera almacenar la restriccin {y = 2x + 1 0 x 4 1
y 9}.
Existen bases de datos especcas con esta caracterstica de deduccin cuando la representacin de los datos es simblica. Para inferir la informacin necesaria, en funcin de la consulta, utilizan tcnicas de inferencia como la programacin lgica y la programacin con restricciones, que se describen a continuacin. Las bases de
26
datos que han desarrollado este tipo de inferencia son las Bases de Datos Deduc-
tivas, Bases de Datos de Restricciones y las Bases de Datos Deductivas de Restricciones.
2.3.1. Bases de Datos Deductivas

Los sistemas de Bases de Datos Deductivas (DDB, Deductive Databases) [36] pueden hacer inferencia de nuevo conocimiento, deduciendo nuevos datos basndose en las reglas y hechos almacenados. Estas bases de datos se originaron con la fusin de las tcnicas de la Programacin Lgica (LP, Logic Programming) [100][63] y las bases de datos. Entre las caractersticas de las Bases de Datos Deductivas, se encuentran: Se basan en un conjunto de hechos y reglas, usando lenguajes declarativos como Datalog [28][72], para especicar dichas reglas y hechos. Mediante procesos de inferencia pueden deducir nuevas reglas y hechos partiendo de los almacenados. Un buen ejemplo de lenguaje declarativo es Prolog [141], pero sin duda fue Datalog el lenguaje especcamente diseado para trabajar con lgica y bases de datos. Datalog es un lenguaje de consulta basado en la Programacin Lgica, denido como un subconjunto sintctico de Prolog junto a un lenguaje de consulta de bases de datos. Un programa lgico consiste en un conjunto nito de clusulas de la forma:
L0 : L1 , . . ., Ln .
donde cada Li es un literal expresado de la forma pi (t1 , . . . , tk ), siendo pi un predicado y tj para 1j k trminos, donde los trminos pueden ser constantes o variables. La parte de la izquierda de la clusula se llama cabecera o antecedente, y la derecha cuerpo o consecuente, y donde los literales se relacionan mediante el operador de conjuncin. Cuando el cuerpo de una clusula est vaco, se dene como hecho, en otro caso como
regla. Los hechos representarn la informacin extensiva de la base de datos, mientras

que las reglas describirn la informacin intensiva, pudiendo inferir ms reglas y hechos partiendo de las clusulas denidas. Como diferencia funcional tangible, con respecto a otras bases de datos, hay que destacar que las Bases de Datos Deductivas permiten consultas recursivas, caracterstica
27
que no poseen las bases de datos relacionales y el lenguaje de consulta SQL-92, la cual fueron aadidas hasta SQL:1999.
Datalog y las bases de datos relacionales

Datalog fue desarrollado para aplicaciones que usan gran nmero de hechos y que pueden ser almacenados en una base de datos relacional [149]. De forma que los predicados se pueden dividir en:
Predicados BDE (Base de Datos Extensiva), que sern aquellos predicados almacenados como relaciones en una base de datos. Si p(a1 ,. . . , ak ) es un predicado DBE, existir una relacin P en la base de datos con la tupla (a1 ,. . . , ak ). Los predicados BDE tambin son conocidos como datos.
Predicados BDI (Base de Datos Intensiva), los cuales se denen mediante reglas. Un predicado BDI puede aparecer en la cabecera o en el cuerpo de una regla, mientras
que un predicado BDE slo puede aparecer en el cuerpo de las regla. Los predicados
BDI tambin pueden ser identicados con relaciones, llamadas relaciones BDI. Las relaciones BDI no son almacenadas explcitamente, estn ms bien relacionadas con
el concepto de vistas de las relaciones, y se obtienen con el compilador o intrprete de Datalog. Un ejemplo de programa Datalog es el siguiente, donde se representan los caminos entre los distintos nodos de un grafo:
r1 : camino(X, Y ) : arco(X, Y ). r2 : camino(X, Y ) : arco(X, Z ), camino(Z, Y ).

Para el ejemplo, camino(X, Y) es un predicado BDI, mientras que arco(X, Y) es un
predicado BDE. Un ejemplo de relacin BDI es obtener una parte de la informacin,

como el conjunto de nodos alcanzables desde el nodo A, donde la consulta sera: ?
camino(A, X ).
Inconvenientes de las Bases de Datos Deductivas

Entre los inconvenientes de las Bases de Datos Deductivas se encuentran:
28
Es una forma diferente de representar entidades y relaciones a como se realiza en las bases de datos relacionales, ya que los predicados BDI no corresponden con una relacin tal como se conoce en las bases de datos relacionales, no siendo una transformacin directa. Tampoco tienen operaciones de agregados (MIN, MAX, AVG . . .) ni de agrupacin (GROUP BY) como tienen las bases de datos relacionales. La cabecera se deriva del cuerpo, pero no al contrario. Esto provoca que existan casos que necesitarn una doble inclusin de reglas para representar esta bidireccionalidad. Los cambios estructurales son muy costosos ya que no existe posibilidad de denir relaciones mediante referencias entre distintos predicados. Si por ejemplo la signatura de uno de los hechos cambia, todas las reglas que lo contienen deben ser modicadas. No estn reejados ninguno de los aspectos de integridad referencial para evitar inconsistencia en la informacin, como para el ejemplo sera denir arcos sobre vrtices que no existen. Esto es debido a que es necesario garantizar que cuando los hechos son actualizados no violen las reglas de integridad [116][109]. El objetivo es mantener la consistencia de la Base de Datos Deductiva, lo que signica que satisface un conjunto de restricciones de integridad. Las implementaciones que hay de Bases de Datos Deductivas son poco ecientes para problemas grandes, con muchas reglas y hechos. Pese a que la informacin puede ser parcialmente almacenada en bases de datos relacionales, la evaluacin de consultas es computacionalmente costosa ya que parte de la informacin tiene que ser inferida. Junto a la posibilidad de que exista una recursividad innita, por ejemplo si se aade un ciclo al grafo.
2.3.2. Bases de Datos de Restricciones

Las Bases de Datos de Restricciones (BDdR) son el mbito de trabajo y desarrollo ms importante en esta tesis, por lo que sern analizadas durante toda la memoria, siendo en el captulo 3 donde se estudien en profundidad, en esta seccin slo se hace una breve introduccin. Las Bases de Datos de Restricciones (CDBs, Constraint Databases) permiten representar la informacin mediante restricciones, donde una restriccin es una combinacin
29
de ecuaciones e inecuaciones con operadores lgicos. Las restricciones permiten describir las relaciones entre los valores que pueden tomar un conjunto de variables denidas en un dominio. Una base de datos tradicional se puede representar mediante restricciones, ya que no sera ms que un conjunto de restricciones de igualdad o desigualdad de los atributos de dicha tupla. Esto hace que las BDdR sean una generalizacin del modelo relacional, donde las relaciones entre los atributos no tienen que ser exclusivamente de igualdad o desigualdad con un valor, sino que se pueden denir relaciones ms complejas entre dichos atributos. Dichas restricciones permiten almacenar de manera simblica los distintos valores que pueden tomar las variables en funcin de otras, lo que signica que esta informacin ser almacenada de manera intensiva. Para la inferencia de nueva informacin, las Bases de Datos de Restricciones se basan en la Programacin con Restricciones (CP, Constraint Programming) [42][118].
2.3.3. Bases de Datos Deductivas de Restricciones

Estas bases de datos combinan las dos anteriores, las Bases de Datos Deductivas que soportan la Programacin Lgica y las Bases de Datos de Restricciones que soportan la Programacin con Restricciones. La Programacin Lgica y la Programacin con Restricciones dan origen a las Programacin Lgica con Restricciones (CLP, Constraint Logic Programming) [81][82]. Las Bases de Datos Deductivas de Restricciones (CDDB, Constraint Deductive Databases) permiten describir dominios innitos de valores mediante restricciones junto a la capacidad de inferencia lgica de las Bases de Datos Deductivas. Esto hace posible que se aadan restricciones en programas lgicos en el cuerpo de las clusulas, por ejemplo:
A(X, Y ) : X + Y > 0, B (X ), C (Y ).
donde X + Y > 0 es una restriccin y A(X, Y ), B (X ) y C (Y ) son predicados. La evaluacin de las consultas en las CDDB [73] se realiza de forma similar a como se hace en las Bases de Datos Deductivas con la programacin lgica, donde la consulta es evaluada en funcin de un objetivo. Para cumplir dicho objetivo y que su cuerpo sea satisfactible, se buscan todas las combinaciones de forma recursiva y utilizando backtracking. Las restricciones que se encuentren en esta bsqueda se irn aadiendo a un conjunto de
restricciones almacenadas. Cada vez que una nueva restriccin se aade a dicho conjunto,
se analiza si dicho conjunto contina siendo satisfactible, siguiendo con la bsqueda o
30
deshaciendo la decisin en funcin del resultado. Aunque en la prctica, la satisfactibilidad de las restricciones almacenadas a veces se analiza con algoritmos incompletos que no siempre detectan las inconsistencias [137]. Esta combinacin de hechos y restricciones ha hecho necesario la extensin del lgebra relacional para estos tipos de datos [147][1] y la ampliacin de los lenguajes de consultas [114].
2.4. Modelo lgico de almacenamiento de Bases de Datos

Los primeros almacenamientos de datos se realizaban sobre cheros, tras estos sistemas basados en archivos llegaron los sistemas gestores de bases de datos y con ellos la primera generacin de bases de datos basada en estructuras jerrquicas. Fue en 1967 cuando se cre el grupo de trabajo llamado DBTG (Data Base Task Group), el cual gener una serie de informes en busca de la estandarizacin de un entorno que permitiera la creacin de bases de datos y la manipulacin de la informacin. En 1970 Codd [32] elabor uno de los artculos ms inuyentes en el rea de las bases de datos, dando origen a las bases de datos relacionales y con ellas a la segunda generacin de las bases de datos. Pese a sus ventajas, el modelo relacional tienen grandes inconvenientes entre los que destacan su limitada capacidad de modelado y la falta de expresividad a la hora de tratar con datos ms complejos. Ante la creciente complejidad de los datos y las aplicaciones de las bases de datos, se originaron sistemas con mayor capacidad de expresin, denindose las bases de datos orientadas a objetos y ms tarde las bases de datos objeto-relacionales, y con ellas a la tercera generacin. En esta seccin se hace un recorrido por estas propuestas.
2.4.1. Bases de Datos Relacionales

Sin duda alguna, la propuesta ms revolucionaria que dio paso a las bases de datos relacionales fue el modelo propuesto por Codd [32], donde todos los datos estn estructurados desde el punto de vista lgico mediante relaciones (tablas). Cada relacin tiene un nombre que la representa de forma nica y est compuesta de forma vertical por atributos (columnas) cuyo nmero determina la cardinalidad o grado de la relacin. A
Modelo lgico de almacenamiento de Bases de Datos
31
su vez est compuesta de manera horizontal por tuplas (las), que contienen un valor para cada atributo. Pese a que la estructura lgica del modelo relacional es simple, su estructura terica es muy slida. Esta base terica permite tratar con la semntica de los datos y con los problemas de coherencia y redundancia, junto a un conjunto de reglas de normalizacin. El modelo relacional propone la independencia entre los datos junto a la manera de almacenarlos, y los programas que los usan. A partir de esa idea se desarroll el lenguaje de consulta SQL (Structured Query language), que ha llegado a ser un estndar de facto para los sistemas relacionales. El lenguaje SQL es un lenguaje declarativo que permite denir datos (DDL - Data Denition Language) y manipularlos (DML - Data Manipulation Language). Desde su creacin en 1986, sufri diversas ampliaciones hasta llegar a la ms utilizada hasta el momento, SQL:92 (SQL2), denida sobre bases de datos relacionales. El trmino de relacin R est denido basndose en su signicado matemtico. Siendo los conjuntos S1 , S2 , . . ., Sn no necesariamente distintos, R es un subconjunto del producto cartesiano S1 S2 . . . Sn , tambin llamado conjunto de n-tuplas. De esta forma se dene una base de datos relacional como una coleccin de relaciones siguiendo una forma normalizada [47] en la que cada relacin tiene un nombre distinto. Resumiendo, una tabla que represente una relacin de grado n tiene las siguientes propiedades: Cada la representa un tupla de grado n. El orden de las las no es relevante. Todas las tuplas (las) son distintas. El orden de las columnas es importante, y debe corresponder a un dominio determinado. Cada columna va asociada a una etiqueta y a un determinado dominio. Aunque sin duda los sistemas gestores de bases de datos relacionales marcaron el comienzo de las bases de datos en general, tienen algunas deciencias que se analizan a continuacin:
Sobrecarga semntica: El modelo relacional tiene una sola estructura para representar las entidades y las relaciones entre ellas, las tablas. No hay mecanismos para distinguir entre entidades y relaciones, o entre distintos tipos de relaciones, por lo que se dice que est semnticamente sobrecargado en ese aspecto.
32
Estructura de datos homognea: El modelo relacional dene la homogeneidad

de datos tanto horizontal como vertical. La homogeneidad horizontal signica que cada tupla de una relacin debe estar compuesta por los mismos tipos de atributos. La homogeneidad vertical signica que los valores de una columna concreta de una relacin deben provenir todos ellos del mismo dominio, adems la interseccin de una la y de una columna debe ser un valor atmico. Esta estructura ja es demasiado restrictiva para muchos objetos del 'mundo real', que tienen una estructura compleja, e incluso recursivas, lo que condiciona combinaciones poco naturales que son muy inecientes. Uno de los ejemplos clsicos de esta problemtica es la planicacin del ensamblaje de componentes [4], donde un componente est a su vez formado por ms, que a su vez tambin pueden estar constituido por otros componentes. Este caso representa la necesidad de almacenar una estructura recursiva de tamao indeterminado, no manteniendo la homogeneidad de datos.
Capacidad de denir nuevos tipos: Los sistemas gestores de bases de datos

exclusivamente relacionales no permiten la denicin de nuevos tipos que se adapten a las necesidades de los usuarios y las aplicaciones. Muchos sistemas gestores de bases de datos relacionales (SGBDR) actuales han ampliado los tipos de datos que pueden utilizar, como por ejemplo los objetos binarios de gran tamao (BLOB, Binary Large Object). Un BLOB es un dato que contiene informacin binaria relativa a una imagen, una secuencia de vdeo o de audio digitalizada, un procedimiento o algn tipo de objeto de gran tamao no estructurado, de forma que el sistema no tienen ningn conocimiento sobre el contenido o la estructura interna. Esto impide realizar consultas y operaciones sobre tipos de datos que son inherentemente ricos y estructurados, por lo que no la gestionan, sino que simplemente contiene una referencia a la informacin.
Gestin de las consultas recursivas: Como consecuencia, al no tener incluido

los datos de carcter recursivo dentro del modelo relacional, aparece la falta de capacidad de las consultas recursivas de forma natural. Volviendo al ejemplo del ensamblaje de componentes, si una base de datos almacena la relacin entre un componente y los que lo componen de forma recursiva hasta llegar a una pieza indivisible, cmo es posible conocer todas las piezas relacionadas con una determinada a cualquier nivel, si a priori no se conoce el nmero de niveles que hay?
33
Operaciones limitadas: El modelo relacional slo tiene un conjunto jo de operaciones, como son las operaciones de conjuntos y las orientadas a tuplas, no pudiendo especicar nuevas operaciones. Este problema se hace especialmente patente en los sistemas geogrcos, donde la informacin est representada mediante puntos, lneas y polgonos, y se necesitan denir operaciones para conocer la distancia, la interseccin, o el hecho de que un objeto est contenido dentro de otro.
No correspondencia de impedancias: El lenguaje estndar para el tratamiento

de bases de datos relacionales (SQL) carece de completitud computacional, ya que no tiene denido instrucciones de control de ujo como IF, WHILE, DO, . . . Aunque SQL sea un lenguaje declarativo, es posible incorporarlo en lenguajes procedimentales de ms alto nivel como JavaT M o C. Sin embargo, esta tcnica produce una
no correspondencia de impedancias por estar mezclando diferentes paradigmas de

programacin, el procedimental y el declarativo.
2.4.2. Bases de Datos Orientadas a Objetos

El paradigma de la orientacin a objetos apareci ante las necesidades de representar aspectos a un nivel de abstraccin mayor. Un objeto contiene tanto la estructura de los datos como el conjunto de operaciones que pueden usarse para manipularlo, apareciendo el concepto de encapsulacin. Tambin es importante el concepto de ocultacin de la informacin, donde se separa los aspectos externos de un objeto de sus detalles internos. De esta forma, las bases de datos se adaptaron a los lenguajes de programacin orientados a objetos (OOPL, Object-Oriented Programming Languages) para poder hacer dichos objetos persistentes. Entre las soluciones propuestas para el almacenamiento de objetos en bases de datos relacionales, existe la posibilidad de establecer una correspondencia entre las instancias de las clases (los objetos) y una o ms tuplas distribuidas entre una o ms relaciones. Hay diversas estrategias para asignar las clases a relaciones, aunque todas ellas tienen como resultado una prdida de informacin semntica ya que hay que denir el cdigo para descomponer los objetos en tuplas y el cdigo para leer las tuplas de las relaciones y reconstruir los objetos. Distintas deniciones han aparecido para describir qu es un Sistema Gestor de Base de Datos Orientadas a Objetos (SGBDOO) [3]. Por ejemplo en [156] donde se dene que
34
un SGBDOO debe proporcionar funcionalidad de bases de datos, soportar el concepto de identidad de los objetos, establecer un mecanismo de encapsulacin, y soportar objetos con estados complejos. Aunque otros trabajos [86] lo denen como orientacin a objetos (tipos abstracto de datos, herencia e identidad de objetos) junto a las capacidades de las bases de datos. Pero estas deniciones dejan fuera algunas de las necesidades ms importantes en las bases de datos, que ms tarde fueron recogidas [120], como son la denicin de un lenguaje de consulta de alto nivel con capacidad de optimizacin de las consultas, control de concurrencia, soporte de objetos complejos e ndices para hacer los accesos ms ecientes. Otro de las caractersticas obligatorias que ms tarde se aadieron a los SGBDOO es la capacidad de denir nuevos tipos por el usuario, partiendo del conjunto de tipos predenidos por el sistema. Adems, no debe haber ninguna distincin de uso entre los tipos denidos por el sistema y los denidos por los usuarios. Entre algunas de las caractersticas especcas que deben cumplir los SGBDOO se encuentran:
Soporte de objetos complejos: Deben ser capaces de ofrecer formas de construir

objetos complejos basndose en otros simples, deniendo para ellos sus constructores. Entre estos objetos complejos se encuentran SET, TUPLE o LIST, con la consecuente dicultad que conlleva la integridad referencial entre ellos [117].
Capacidad de identicacin de objetos: Diferenciando entre el concepto de

igualdad de tupla con respecto al contenido, que tiene el lgebra relacional clsica, y la igualdad entre objetos en funcin de su identicador (OID), que es independiente del contenido de sus atributos.
Polimorsmo y sobrecarga: Pudiendo aplicarse el mismo mtodo sobre objetos

de diferente tipo (sobrecarga), y dando la posibilidad de denir distintos mtodos con el mismo nombre en funcin de sus parmetros de entrada (polimorsmo).
Extensibilidad: Dando la posibilidad al usuario de crear nuevos tipos a partir de

otros ya denidos. Esos nuevos tipos no sern diferentes en uso a los denidos por el sistema.
El Lenguaje de Manipulacin de Datos debe ser computacionalmente completo: Por lo que dicho lenguaje debe ser de propsito general, idea que no
se llev al estndar hasta la aparicin de SQL:1999, que s es computacionalmente
35
completo al poder combinarse con otros lenguajes de programacin. En SQL:1999 (SQL3) se incluyeron adems algunas caractersticas como la ampliacin de las expresiones en las condiciones de la consultas, conceptos de bases de datos activas con la denicin de triggers, consultas recursivas, junto a las caractersticas mencionadas de la orientacin a objetos.
Estndar de objetos de datos ODMG

Existen muchas implementaciones de SGBDOO entre las que se pueden destacar Poet,
Jasmine, ObjectStore, Versant o GemStone. Dichas soluciones se basan en el estndar del

modelo de datos orientado a objetos (OODM, Object-Oriented Data Model), el cual est compuesto de un modelo de objetos, un lenguaje de denicin de objetos y un lenguaje de consulta sobre objetos con una sintaxis similar a la de SQL. Dicho estndar fue denido por ODMG (Object Data Management Group), el cual propone la denicin de la semntica de los objetos en las bases de datos. Desde las primeras publicaciones y denicin del primer estndar al respecto en 1993 [26], se ha ido renado hasta la actual versin 3.0 [13]. Dicho estndar sirve an como referencia en publicaciones recientes [96] con el propsito de soportar todas las funcionalidades existentes en las bases de datos relacionales y el modelo de datos orientado a objetos. Los principales componentes del estndar son: El modelo de objetos (OM, Object Model) El lenguaje de denicin de objetos (ODL, Object Denition Language) El lenguaje de consulta de objetos (OQL, Object Query Language) Enlaces con lenguajes de programacin orientados a objetos como C ++ y JavaT M .
El modelo de objetos
El modelo de objetos ODMG (Object Data Management System) soporta el concepto de bases de datos como un rea de almacenamiento de objetos persistentes sobre un conjunto de tipos determinados, donde una la de una relacin puede ser una instancia de un objeto. El modelo de datos permite almacenar objetos, haciendo posible que mltiples usuarios y aplicaciones los compartan. Se dene como un superconjunto del modelo de objetos que especica las siguientes primitivas bsicas de modelado:
36
Objetos y literales (objetos inmutables que no cambian en el tiempo, como Integer, Float, Boolean o Character), donde slo los objetos tienen identicadores unvocos y los literales se comparan por su contenido. A su vez, los objetos y literales pueden clasicarse en diferentes tipos (atmicos, colecciones y tipos estructurados). El comportamiento se dene mediante un conjunto de operaciones que pueden realizarse sobre o por el objeto. El estado o vida del objeto se dene mediante los valores que el objeto tiene para una serie de propiedades, que pueden ser atributos o una relacin entre varios objetos. Los literales no tienen estado.
El lenguaje de denicin de objetos

El lenguaje de denicin de objetos (ODL, Objet Denition Language) es un lenguaje creado para denir las especicaciones de los tipos de objetos en los sistemas compatibles con ODMG, de una manera equivalente al lenguaje de denicin de datos de los SGBDR tradicionales. El ODL dene los atributos y relaciones de los tipos y especica la signatura de las operaciones, aunque no su implementacin. La sintaxis de ODL es una ampliacin del lenguaje de denicin de interfaces (IDL - Interface Denition Language) de CORBA.
El lenguaje de consulta de objetos

OQL (Object Query Language) es el lenguaje de consulta denido por ODMG, el cual ofrece un acceso declarativo a las bases de datos de objetos con una notacin similar a
SQL-92 para expresar consultas. Al igual que SQL, OQL se puede utilizar como lenguaje
autnomo y como lenguaje embebido dentro de otros lenguajes procedimentales. Dicho lenguaje extiende nociones de la orientacin a objetos como objetos complejos, identidad de objetos, expresiones de camino con la notacin '.' o '', polimorsmo e invocacin de operaciones, e incluso proporcionando primitivas de alto nivel para tratar con conjuntos de objetos. Tambin proporciona primitivas para tratar con estructuras, listas y arrays tratando a estos constructores con la misma eciencia. El resultado de una consulta cualquiera, es de un tipo que pertenece al modelo ODMG y puede consultarse de nuevo, por lo que cumple la propiedad del cierre transitivo. Es un lenguaje de consulta sencillo que permite acceder de forma fcil a un SGBDOO, aunque no es computacionalmente
37
completo, ya que no proporciona operadores explcitos de actualizacin; ms bien invoca operaciones denidas sobre los objetos para este propsito, y as no infringe la semntica del modelo, en la cual por denicin los objetos se manejan mediante los mtodos denidos sobre ellos. Sin duda alguna, los SGBDOO tienen tanto ventajas como inconvenientes. Entre sus ventajas se pueden destacar: Capacidad de ampliacin, ya que permite que el usuario dena nuevos tipos que se adapten a sus necesidades. A esto hay que aadirle las caractersticas propias de la orientacin a objetos como la herencia, lo que facilita la reusabilidad de los tipos denidos. La orientacin a objetos permite encapsular informacin y comportamiento, por lo que tiene mayor capacidad de modelado. Esta capacidad facilita su adaptacin a aplicaciones complejas, como las que se han presentado en la seccin anterior. Existencia de un lenguaje de consulta ms expresivo, gracias a la navegabilidad existente entre objetos. Esta caracterstica ayuda a paliar la deciencia en los SGBDR en materia a consultas recursivas. Eliminacin de la no correspondencia de impedancias de los SGBDR, eliminando muchas de las deciencias de unir los lenguajes declarativos como SQL y los imperativos como JavaT M . Entre sus inconvenientes se encuentran: Carencia de un modelo de datos y de un lenguaje de consulta orientado a objetos con base terica aceptada de forma genrica por la comunidad de SGBDOO, como s tienen los SGBDR con SQL. Aunque ODMG ha hecho una importante aportacin en este aspecto, sin duda no tiene el grado de aceptacin del modelo relacional. La relacin entre optimizacin de consultas y la encapsulacin, ya que dicha encapsulacin de objetos provoca dicultades en la evaluacin de las consultas. Complejidad, ya que el tratamiento de referencias entre objetos, las transacciones de larga duracin y la gestin de versiones, son ms complejas que en el caso de las bases de datos relacionales. Una de las caractersticas de esta complejidad, radica
38
en la necesidad de serializar los objetos para que sean almacenados de una manera persistente. Una metfora clara que representa esta complejidad podra ser establecer el smil con un coche que para guardarse en un garaje hay que desmontarlo, y cuando se vuelva a necesitar se tendr que montarlo de nuevo. Estas acciones de 'desmontado' y 'montado' son las necesarias en los objetos para que se almacenen y hagan persistentes en los soportes fsicos. Que el usuario pueda denir nuevos datos es sin duda alguna un salto cuantitativo, pero en el caso de bases de datos remotas, como es el caso de las existentes para aplicaciones web, signicar que la funcionalidad no pertenece a la base de datos, sino al usuario.
2.4.3. Bases de Datos Objeto-Relacionales

Las bases de datos objeto-relacionales son una ampliacin del modelo relacional para dar soporte a las nuevas aplicaciones en bases de datos. Este tipo de bases de datos usan el estndar SQL:2003, el cual incluye nuevos tipos y procedimientos denidos por el usuario, el tipo referencia, y soporta objetos de gran tamao pero siempre basndose en el modelo relacional. Las bases de datos relacionales no son tan descriptivas como las orientadas a objetos para poder soportar las aplicaciones que estn surgiendo en la actualidad, pero por otra parte tiene grandes ventajas. La idea que origin las bases de datos objetos-relacionales fue fusionar las ventajas de ambas e intentar reducir sus deciencias, manteniendo las mismas tablas relacionales bsicas y el mismo lenguaje de consulta aunque incorporando el concepto del tipo 'objeto', dando como resultado los Sistemas Gestores de Bases de Datos Objeto-Relacionales (SGBDOR). Las bases de datos objeto-relacionales fueron analizadas por Stonebraker [143], proponiendo la divisin mostrada en la gura 2.2. En esta gura se muestra cmo la orientacin a objetos permite ampliar la complejidad de los datos, mientras que la bsqueda de soluciones relacionales mejora la eciencia en la evaluacin de consultas. Entre las caractersticas de las bases de datos objeto-relacionales, se puede destacar que el acceso a la base de datos se puede hacer usando lenguajes de ms alto nivel orientados a objetos. Pero donde toda la informacin es relacional, y las tuplas y las relaciones mantienen el mismo signicado que en las bases de datos relacionales, aprovechando su desarrollo y madurez.
39
+ SGBD Relacional SGBD Objeto-Relacional
Capacidades de bsqueda/Soporte multiusuario
Sistema de Archivos
SGBD Orientado a objetos
Complejidad de los datos/extensible
Figura 2.2: El mundo de las bases de datos segn Stonebraker [1996] Entre las ventajas de los SGBDOR se puede destacar: Reutilizacin y comparticin, ya que surge la capacidad de ampliar los servicios del SGBD para implementar funcionalidad estndar de manera central, en lugar de codicar dicha funcionalidad en cada aplicacin. Esto es muy utilizado en los sistemas geogrcos, que necesitan una serie de funciones asociadas que calculen la distancia entre objetos, operaciones de inclusin o solapamientos. De esta forma no se tiene que denir la funcionalidad en cada aplicacin sino slo en el servidor, aumentando la productividad tanto del desarrollador como del usuario nal. La adaptacin de las aplicaciones relacionales a las objeto-relacionales, ya que los SGBDOR pueden introducirse de forma gradual. SQL:2003 es compatible con SQL:92, por lo que la transformacin de un sistema ya existente se puede realizar por pasos. Los SGBDOR tienen la capacidad de almacenar instancias de clases y atributos clsicos relacionales, eso ofrece la posibilidad de escoger en funcin de las necesidades de la aplicacin, cul es la implementacin ms adecuada. En los SGBDOO toda la informacin es almacenada como objetos, por lo que se gana capacidad expresiva pero con deciencias en la optimizacin de la evaluacin de consultas. Por otro lado, en los SGBDR todos los datos son univaluados, sus dominios son atmicos, con un estructura ja y nica pero encontrar las relaciones entre los datos es ms fcil y eciente por su simplicidad. Vistas estas caractersticas, sera ms apropiado utilizar
40
en funcin de las necesidades un modelo u otro de representacin, seleccionando en cada caso el necesario. De esta forma, ambos modelos podran convivir en el mismo gestor de base de datos. Aunque obviamente tiene algunas desventajas: La complejidad y el incremento de coste, ya que se pierde la simplicidad del modelo relacional. Los SGBDOR no aaden todos los valores de la orientacin a objetos, ya que tan solo contemplan el modelo de objetos como una extensin del modelo relacional al que se le aade complejidad. La 'convivencia' de datos puramente relacionales y objetos hace que se pierda la homogeneidad de acceso a la informacin. Esta caracterstica hace que el tratamiento de la informacin dependa de su naturaleza, y por lo tanto aumente la complejidad del desarrollo de los SGBDOR.
2.4.4. Comparacin entre las propuestas

Aunque en las subsecciones anteriores se muestran muchas de las caractersticas de los distintos gestores de bases de datos, en las tablas 2.1 y 2.2 analizadas en [45] se muestra un resumen de algunas de sus caractersticas. En la tabla 2.1 se presentan las caractersticas ms genricas relativas a la facilidad de uso, de programacin, junto a caractersticas de los lenguajes de consulta y la naturaleza de los datos que soportan. El objetivo de muchas multinacionales es desarrollar nuevos sistemas gestores de bases de datos que lideren el mercado, ya que la seleccin de un buen gestor de bases de datos es una decisin muy importante para una empresa. En la tabla 2.2 se muestran algunas consideraciones al respecto de los productos que existen en el mercado y su madurez.
Posicin de la propuesta dentro del organigrama general
41
Comparacin Estndares Facilidad de uso
SGBDR SQL2 Fcil
SGBDOO ODMG-2.0 Fcil para los programadores, no tanto para el usuario nal
SGBDOR SQL:2003 Similar a los SGBDR, aunque con algunas extensiones confusas Independencia entre datos y aplicacin Denicin de SQL3 basado en SQL pero con orient. a objetos Facilita la denicin de tipo complejos y relaciones Limitado sobre todo para los nuevos tipos de datos
Facilidad de desarrollo El uso de SQL
Independencia entre datos y aplicacin Completo
Los objetos son una forma natural de modelar, extensible y adaptable Extensin de SQL con la creacin de OQL adaptado a la orient. a objetos
Datos complejos y relaciones Soporte a la Orientacin a Objetos Distribucin
Difcil de modelar Pobre, es difcil almacenar los objetos en la BD Muy buena
Facilita la denicin de tipo complejos y relaciones Directa y Extensible
Depende del SGBDOO
Muy Buena
Tabla 2.1: Una comparacin entre Sistemas Gestores de Bases de Datos (I)
2.5.
Tras analizar las tres caractersticas que denen una base de datos (dominio de la aplicacin, naturaleza de la informacin y modelo lgico), en la gura 2.3 se resumen grcamente. La combinacin de estas tres caractersticas describir una base de datos. Se pueden encontrar innidad de casos donde estas caractersticas estn combinadas, presentados en la gura 2.4, como por ejemplo: No slo son los ejemplos de aplicaciones administrativas los que almacenan informacin de manera extensiva, tambin son muy utilizadas en el rea de investigacin de Data Mining [74][136] utilizando un SGBDR.
42
Comparacin Madurez del producto Soporte comercial
SGBDR Mucha Gran xito
SGBDOO Relativamente Tiene buen futuro
SGBDOR An est siendo denida Falta el apoyo empresarial
Tabla 2.2: Una comparacin entre Sistemas Gestores de Bases de Datos (II)
Bases de Datos Extensivas Administrativos CAD GIS CIM Espacio temporal Bases de Datos Intensivas (DDB, CDB, CDDB)
SGBD Relacional SGBD Objeto-Relacional
CAM
CASE
Sistema de Archivos
SGBD Orientado a objetos
Dominio de la aplicacin Modelo lgico de almacenamiento
BASE DE DATOS
Figura 2.3: Divisin detallada de una base de datos por caractersticas En el trabajo [140] se presenta una combinacin donde el dominio de la aplicacin es el tratamiento de imgenes, la informacin es almacenada de manera intensiva y el modelo lgico de almacenamiento un SGBDR. Este ejemplo es relevante ya que pese a utilizar el modelo relacional, diseado originalmente para informacin extensiva, se puede inferir informacin no almacenada de manera explcita. Algunas soluciones para el dominio de los sistemas de informacin geogrca han utilizado las Bases de Datos Deductivas de Restricciones [1], basndose en cheros Datalog. Las Bases de Datos Deductivas (intensivas) y los SGBDOO tambin han sido analizados [104], con ejemplos de aplicaciones como la planicacin de horarios [25].
43
El sistema MLPQ [133] dene una solucin para sistemas de informacin geogrca utilizando Bases de Datos de Restricciones, cuya informacin ser intensiva pero almacenada en un sistema de archivos. El sistema CCUBE [17] presenta una solucin a sistemas espacio-temporales utilizando Bases de Datos de Restricciones cuyo soporte lgico son los SGBDOO. Ante las emergentes aplicaciones relacionadas con Internet, nuevos tipos de datos han tenido que ser tratados, como es el caso de XML. Esto ha generado nuevas necesidades como la analizada en [92] y [119], donde se almacenan documentos XML de manera extensiva utilizando SGBDOR.
Naturaleza de la Informacin
CDDB DDB CDB Intensivo

(valores Represen tativos)
Sist.Infor. Geogrfica [1] Planificacin [25] MLPQ(GIS) [133] Imgenes [140] Data Mining [74][136] XML [92][119] CCUBE (EspacioTemporal)[17] LORCDB
Extensivo Archivos
SGBDR
SGBDOO
SGBDOR
Modelo Lgico
Figura 2.4: Ejemplos de propuestas combinando caractersticas de las Bases de Datos Estos ejemplos muestran la independencia de estas tres caractersticas que se han denido, aunque sin duda hay combinaciones que son de mayor uso que otras. Como se ha presentado, en las bases de datos se pueden destacar dos necesidades bsicas: la bsqueda de nuevas tecnologas para gestionar tipos ms complejos de datos; y la necesidad de mejorar la evaluacin de las consultas, ya que la cantidad de datos a tratar es cada vez mayor y cualquier propuesta tiene que contemplar la eciencia de la evaluacin de sus consultas. Para cubrir estas necesidades, los aspectos analizados en esta tesis para las distintas caractersticas de las base de datos son:
A nivel de dominio de la aplicacin: Se propone una nueva forma de tratar

datos complejos, donde la informacin se representa de manera intensiva y extensiva independientemente de la aplicacin. Esta solucin pretende ser genrica, no
44
dependiente del dominio de la aplicacin, aunque se utilizar la diagnosis de fallos basada en modelos como un tipo de CAD/CAM y los sistemas de informacin geogrca como ejemplos por su importancia en el mercado.
A nivel de naturaleza de la informacin: Se utilizan las Bases de Datos de

Restricciones para representar los datos de manera intensiva y extensiva. Aunque las Bases de Datos de Restricciones necesitan ser revisadas para aprovechar ms sus cualidades. La utilizacin de restricciones es especialmente apropiado para el tratamiento de CAD/CAM [146], ya que son problemas formados por un conjunto nito de objetos geomtricos junto a un grupo de restricciones entre ellos [99]. Estas restricciones se pueden describir mediante ecuaciones donde las variables son las diferentes coordenadas de los objetos.
A nivel de modelo lgico: Se utilizan los Sistemas Gestores de Bases de Datos

Objeto-Relacionales, aadindole funcionalidad a nivel de evaluacin de consultas para el tratamiento de datos. El uso de SGBDOR, junto a un conjunto de algoritmos que harn posible optimizar los tiempos de acceso a la base de datos para datos complejos. Se utiliza dicho modelo lgico por dar la capacidad de representar datos complejos mediante objetos para informacin intensiva, mientras que mantiene algunas caractersticas de las bases de datos relacional que ayudan a trabajar con datos extensivos. Todo esto da origen al sistema LORCDB (Labelled Objet-Relational Constraint Databases), que ser descrito a lo largo de esta memoria de tesis, y cuyas caractersticas tambin se presentan en la gura 2.4.
2.6. Resumen
Para describir una base de datos es necesario contemplar tres caractersticas: El dominio de las aplicaciones que utilizan y gestionan las bases de datos, la naturaleza de la informacin a almacenar, y el modelo lgico de almacenamiento. En este captulo se han presentado los detalles de cada una de estas familias, y cmo sus distintas combinaciones dan origen a las distintas bases de datos. Ante la creciente complejidad de los dominios de las aplicaciones, las dems caractersticas han tenido que ir avanzando de forma anloga para darles soporte. Los ejemplos de aplicaciones mostradas en este captulo, entre
Resumen
45
otras, necesitan buscar soluciones especcas a sus problemticas, no pudiendo utilizar soluciones genricas para almacenar sus datos. Esto signica que cada aplicacin, debido a tener datos muy complejos, tendr una base de datos con una lgica especca. Las propuestas de sistemas gestores de bases de datos, han ido acercando su funcionalidad a estas necesidades, dando la posibilidad al usuario a ampliar los tipos de datos y sus operaciones, teniendo a veces que apoyarse en representaciones intensivas de la informacin. Esto signica que cada problema particular, que no puede ser representado de forma exclusivamente extensiva, tendr que desarrollar una solucin adaptada a sus necesidades. El objetivo de esta tesis es denir y desarrollar una solucin genrica para estos datos, de forma que se pudiera utilizar el mismo gestor de base de datos, pudiendo dale distinta funcionalidad con menor coste individual en cada aplicacin. Para ello se utilizarn los SGBDOR junto a funcionalidad basada en la programacin con restricciones. De esta forma, todas las aplicaciones cuyos datos puedan ser descritos con ciertas restricciones, descritas en los sucesivos captulos, no tendrn que disear una funcionalidad especca independiente del gestor de bases de datos que utilicen, estar incluida en el gestor LORCDB.
Captulo 3 Antecedentes de las Bases de Datos de Restricciones

Las Bases de Datos de Restricciones (DBdR) son una estrategia importante en el tratamiento de informacin intensiva. La bsqueda de cmo almacenar y gestionar la informacin intensiva, representando los datos en forma de restriccin, ha sido el impulsor de la creacin y el desarrollo de las BDdR, con el objetivo de buscar soluciones cada vez ms expresivas y ecientes. Para su estudio exhaustivo se han creado varias deniciones, junto a la formalizacin de trminos que ayudan a entender mejor tanto sus posibilidades como sus limitaciones. Adems de la formalizacin de las BDdR, en este captulo se hace un recorrido desde sus orgenes hasta las aportaciones ms actuales. As mismo, se presentan distintos prototipos, analizando sus aportaciones y deciencias con el n de realizar una propuesta que aporte soluciones a sus debilidades.
3.1.
Introduccin
La idea que dio origen al desarrollo de las BDdR surge de la necesidad de una nueva forma de almacenar datos que no toman valores nicos, sino que dependen de parmetros, variables, o vienen denidos por relaciones entre variables mediante ecuaciones o inecuaciones matemticas. La representacin de estos datos de manera extensiva podra crear bases de datos innitas, por ejemplo al representar un espacio continuo, por lo que hay
48
Captulo 3. Antecedentes de las Bases de Datos de Restricciones
que buscar alternativas para almacenar los datos de forma intensiva. Una posibilidad es discretizar los datos, pero eso podra conllevar la creacin de bases de datos mucho ms grandes a la vez que prdida de informacin. El crecimiento de las bases de datos tambin inuye en las operaciones de consulta y modicacin, ya que tendran que ser analizados y modicados muchos ms registros que si la informacin estuviera almacenada de manera ms compacta. Sin embargo, si se tuviera la capacidad de representar y almacenar dichas ecuaciones, inecuaciones e incluso combinaciones de ellas, la informacin sera completa y el espacio necesario para almacenarla muy pequeo debido a la compresin de la informacin. Las BDdR abordan la solucin de este problema tratando la informacin no de forma discreta, sino como un conjunto de restricciones sobre variables denidas sobre unos determinados dominios. El reto de las BDdR no acaba en la simple necesidad de almacenar la informacin de forma intensiva, va ms all, ya que se necesita tratar esa informacin deniendo un lenguaje de consulta, y una metodologa que ofrezca una manera eciente de evaluar las consultas sobre los datos.
3.2. Origen de las Bases de Datos de Restricciones

Las Bases de Datos de Restricciones (CDB, Constraint Databases) tuvieron su origen a principios de 1990 con el artculo de Kanellakis, Kuper y Revesz [84], amplindose ms tarde en los trabajos [93][130]. Originalmente, el objetivo de las BDdR fue denir una versin de bases de datos a la que se le aadi funcionalidad relacionada con la Programacin Lgica con Restricciones (Constraint Logic Programming - CLP). La creacin de las DBdR fue una evolucin natural de la investigacin en el campo de la Programacin con Restricciones, al igual que las Bases de Datos Deductivas [36] y Datalog [28] fueron el resultado de la combinacin de las bases de datos y la Programacin Lgica. Considerando las bases de datos relacionales una forma eciente, compacta y transparente de representacin de datos, se busc combinar las ventajas del modelo relacional y la Programacin Lgica con Restricciones. Las BDdR se basaron en la equivalencia entre una tupla en una base de datos relacional y un conjunto de restricciones de igualdad o desigualdad sobre los atributos de dicha tupla [93]. Debido a que las restricciones son un mecanismo natural de especicar las consultas de similitud en series de datos, muchas de las caractersticas del modelo relacional pueden extenderse al campo de la Programacin
Origen de las Bases de Datos de Restricciones
49
x a1 a2 a3
y b1 b2 b3
( x = a1 y = b1 ) ( x = a2 y = b2 ) ( x = a3 y = b3 )
Figura 3.1: Ejemplo de representacin de un conjunto de tuplas como una restriccin con Restricciones. Un ejemplo de equivalencia entre un conjunto de tuplas de una relacin y una restriccin es el presentado en [94], mostrado en la gura 3.1. En sus inicios, las BDdR se crearon para representar problemas donde se involucran datos espaciales, temporales o ambos a la vez [9], aunque su capacidad descriptiva y de inferencia puede ser extendida a cualquier dominio cuya informacin se pueda representar mediante restricciones. Al utilizar originalmente este dominio de aplicacin, las propuestas se centraron en las restricciones lineales. Las restricciones lineales permiten describir problemas espacio-temporales de una forma aproximada, siendo ms fciles de evaluar las consultas a nivel de coste computacional que utilizando restricciones polinmicas. Sin embargo, las restricciones polinmicas son ms genricas, teniendo mayor capacidad expresiva. Las BDdR fueron denidas en base a la lgica y modelo de primer orden, tanto para la descripcin de restricciones como para la evaluacin de las consultas. El fundamento de las BDdR se apoya en la dualidad de representar un conjunto de datos mediante una restriccin (frmula) sobre un conjunto de variables libres {x1 , . . . , xm }, o representarlos como un conjunto de tuplas formadas por atributos (a1 , . . . , an ). Esto proporciona gran poder declarativo y expresivo, como se muestra en la gura 3.2, donde se describe la equivalencia entre una restriccin y su almacenamiento en una base de datos relacional, en este caso una restriccin lineal de igualdad en el dominio de los naturales. Este es un caso, como muchos otros mostrados en el captulo 1 de [130], donde se generara una bases de datos relacional innita si la informacin no se representara mediante restricciones.
50
a 1 1 1 2 3 4 5 ...
b 1 2 3 1 1 1 1 ...
c 2 3 4 3 4 5 6 ... {a+b=c para a, b, c: Natural}
Figura 3.2: Ejemplo de representacin de una restriccin en una base de datos relacional
3.3. Formalizaciones
Las primeras deniciones relativas a BDdR se apoyaron en la lgica de primer orden, estableciendo un smil entre el modelo lgico y las restricciones. En este apartado se presentan algunos formalismos utilizados en el rea de las BDdR.
3.3.1. Lgica y Modelo de Primer Orden

En esta seccin se exponen algunas deniciones que introducen los lenguajes de primer orden y su interpretacin mediante modelos. La lgica de primer orden se considera un lenguaje de consulta puramente declarativo, que presenta algunas limitaciones como la falta de expresividad en operaciones de conteo, y carencia de deniciones de estructuras recursivas. Estas deniciones son necesarias para entender la teora bsica de modelado de las BDdR [34][82].
Denicin 3.1: Vocabulario. Representado por la signatura , est constituido por

tres conjuntos: F que representa los operadores, C que representa las constantes, y P que representa los predicados. Un ejemplo de vocabulario es: = ({+, }, {0, 1}, {<}) que permitir denir inecuaciones polinmicas.
Denicin 3.2: Trminos. La lgica de primer orden se basa en la utilizacin de trminos, que pueden ser variables, constantes pertenecientes al conjunto C , o una expresin de la forma f (t1 , . . . , tn ), donde f F y t1 , . . . , tn son a su vez trminos.
Formalizaciones
51
Denicin 3.3: Frmula atmica. Una frmula atmica t puede venir representada
mediante un trmino t o por un predicado cuyos parmetros son trminos p(t1 , . . . , tn ).
Denicin 3.4: Frmula. Una frmula puede ser una frmula atmica, o una combinacin lgica de frmulas atmicas. Por ejemplo, si y son frmulas, entonces (
), ( ), ( ), ( ) y ( ) tambin son frmulas.

Antes de introducir la formalizacin de las BDdR, es necesario formalizar algunas deniciones relativas a restricciones.
Denicin 3.5: Estructura. La idea de estructura es aadir un dominio a un vocabulario, lo que implicar aadirlo a las frmulas atmicas y a las frmulas genricas. Para un conjunto de valores (U ) que denen el dominio, y un vocabulario , una -estructura
M en U se dene mediante:
La asignacin de cada f F de aridad n a la funcin f M : U n U , lo que signica que para todos los valores de entrada de f , pertenecientes a U , se obtiene un valor de salida tambin perteneciente al dominio U . Para cada predicado p P , los parmetros de p de aridad n pertenecen a U , lo que se expresa de la forma P M U n . Toda constante c C tiene que pertenecer a U representado de la forma cM U .
Denicin 3.6: Restriccin. Sea un vocabulario, una restriccin sobre (restriccin) es una frmula atmica de primer orden sobre o la negacin de una frmula atmica. El poder de representacin de las restricciones radica en su capacidad de representar de una forma compacta un conjunto de datos extensivos, a los que se denomina Denible
con Restricciones (Denability with Constraints). Tambin es posible el proceso inverso, extender una restriccin, lo que signica describir los valores que hacen consistente la
restriccin.
Denicin 3.7: Denible con Restricciones (Extensin de Restricciones).

Dado un vocabulario y una estructura M = (U , ) donde U es el dominio, un conjunto
X U n es denible en M con -restricciones, si dicho conjunto puede ser representado

con una frmula (combinacin nita de frmulas atmicas con operadores booleanos):
52
{(a1 , ..., an ) U n | M |= (a1 , ..., an )}

Los tipos de restricciones tratados en esta tesis son:
Restricciones lineales de igualdad, las cuales son restricciones sobre =

({+}, {0, 1}, {=}). Cada restriccin corresponde con una condicin de la forma p = 0, donde p es una funcin lineal de la forma a1 x1 + . . . + aj xj + a0 , ai representa
coecientes y xi variables. Estas restricciones son normalmente interpretadas sobre las estructuras Rlin = (I R, ), Qlin = (Q, ), Zlin = (Z, ).
Restricciones polinmicas de igualdad, las cuales son restricciones sobre =

({+, }, {0, 1}, {=}). Cada restriccin corresponde a una condicin de la forma p = 0,
donde p es un polinomio. Estas restricciones son normalmente interpretadas sobre las estructuras Rpol = (I R, ), Qpol = (Q, ), Zpol = (Z, ).
Restricciones lineales, son restricciones sobre = ({+}, {0, 1}, {<}). Cada restriccin corresponde con una condicin de la forma p > 0 y p 0, donde p es una funcin lineal de la forma a1 x1 + . . . + aj xj + a0 , ai representa coecientes y xi variables. Estas restricciones son normalmente interpretadas sobre las estructuras
Rlin = (I R, ), Qlin = (Q, ), Zlin = (Z, ).
Restricciones
polinmicas, las cuales son restricciones sobre
({+, }, {0, 1}, {<}). Cada restriccin corresponde a una condicin de la forma p > 0 o p 0, donde p es un polinomio. Estas restricciones son normalmente interpretadas sobre las estructuras Rpol = (I R, ), Qpol = (Q, ), Zpol = (Z, ).
3.3.2. Formalizacin de las Bases de Datos de Restricciones

La idea fundamental de los principios en el diseo de las BDdR es que una conjuncin
de restricciones es la correcta generalizacin de un conjunto de hechos [84]. Las tuplas y

relaciones del modelo relacional pueden ser transformadas en frmulas de primer orden libres de cuanticadores, lo que permite manipular informacin de una forma simblica. Un ejemplo de esto se puede observar en la representacin de los rectngulos, que estn denidos por sus cuatro vrtices. La forma clsica podra llevar a almacenar los datos en una relacin de aridad 5, conteniendo la tupla de la forma (n, a, b, c, d), donde n es el nombre del rectngulo, y los puntos a, b, c y d denen las esquinas del rectngulo ((a, b),
Formalizaciones
53
(a, d), (c, b), (c, d)). En un modelo de BDdR dicho rectngulo se puede modelar mediante una relacin ternaria R(z, x, y ), que puede ser interpretada como que (x, y) es un punto perteneciente al rectngulo de nombre z . El rectngulo ahora se puede almacenar en una nica tupla de la forma:
(z = n) (a x c) (b y d)
El primer modelo de BDdR fue diseado como una extensin del modelo relacional, donde las tuplas son denidas como conjunciones de frmulas atmicas, y las relaciones como disyunciones entre tuplas. Estas deniciones fueron presentadas en los trabajos [84] y [93], de donde se pueden resaltar las siguientes deniciones:
Denicin 3.8: Modelo de Base de Datos de Restricciones. Dado un vocabulario . Una k-tupla restriccin es una tupla de k variables x1 , . . . , xk sobre . De manera que una k-tupla restriccin ser una combinacin de restricciones con el operador de conjuncin de la forma 1 . . . N , donde cada i , para 1 i N , es una restriccin sobre , y las variables de cada i pertenecen a {x1 , . . . , xk }. Una relacin restrictiva de aridad k sobre , es un conjunto nito r = {1 , . . . , M }, donde cada i para 1 i M , es una k-tupla restriccin sobre las variables
x1 , . . . , xk . Una relacin restrictiva se describe mediante una frmula disyuntiva de

la forma 1 . . . M . Partiendo de las deniciones anteriores, una Base de Datos de Restricciones es una coleccin nita de relaciones restrictivas de cualquier aridad nita. Estaleciendo la analoga con la teora de base de datos, una relacin r con aridad
k se dene como un conjunto nito de k-tuplas restriccin (con k atributos), o puntos

en un espacio de k-dimensiones. Pero si el nmero de tuplas que existe es innito, no podr ser representado mediante una relacin tal como se conoce en las bases de datos relacionales. En la bibliografa, esta representacin de la informacin mediante puntos se le denomina relacin no denida con restricciones (unrestricted relation). La relacin mediante restricciones denida en el Modelo de BDdR proporciona la posibilidad de representar estos puntos aunque sean innitos de una forma nita en un espacio k-dimensional, dando origen a las relaciones restrictivas (constraint relation), lo que introduce las siguientes deniciones:
54
Denicin 3.9: Interpretacin de Relaciones Restrictivas. Sea un vocabulario, y M = (U , ) una estructura (un vocabulario sobre un dominio U ). Sea r una relacin restrictiva de aridad k sobre , y r (x1 , . . . , xk ) la frmula correspondiente a la relacin r. Entonces r representa todos los puntos a1 , . . . , ak tales que (a1 , . . . , ak ) es satisfactible en M. Lo que se representa acorde con la denicin 3.7:
{(a1 , . . . , ak ) U k | M |= r (a1 , . . . , ak )}
Denicin 3.10: Relacin Extendida. La representacin de los posibles conjuntos

innitos de puntos en un espacio de k dimensiones que describe una relacin restrictiva, se dene como una extensin de la relacin o relacin extendida. De esta denicin se puede inferir la denicin de Bases de Datos Extendidas o Extensivas como la unin de relaciones extendidas.
Denicin 3.11: Base de Datos Denible con Restricciones. Cualquier coleccin nita de relaciones no denidas con restricciones (unrestricted relations) se le llama
Base de Datos no denida con restricciones (unrestricted database). Y una base

de datos sin restricciones o extendida se le denomina Denible con Restricciones, si todas sus relaciones son denibles mediante restricciones siguiendo la denicin 3.7. Por lo Tanto, una Base de Datos de Restricciones D representa una Base de Datos Denible D , si D representa con restricciones todas las relaciones no denidas con restricciones de D .
Base de Datos sin Restricciones/ extendida Definible con restricciones Base de Datos de Restricciones
Relacin de Restricciones
Base de Datos Relacional
Relacin sin Restricciones/ extendida Relacin sin Restricciones/ extendida Relacin sin Restricciones/ extendida
1 2 ... n 1 2 ... k 1 2 ... m
Extender
Figura 3.3: Comparacin entre las Bases de Datos Extensivas y las BDdR En la gura 3.3 se muestran las ideas de las equivalencias entre las bases de datos no descritas con restricciones y las BDdR. Las bases de datos sin restricciones o extensivas, son aquellas donde la informacin est almacenada mediante todos los puntos que la representan, como es el caso de las bases de datos relacionales clsicas, con la diferencia
Formalizaciones
55
de que tericamente pueden almacenar innitos puntos. Si estas relaciones pueden ser representadas como restricciones (denibles mediante restricciones), se podr representar como una BDdR. Del mismo modo, las BDdR representan un conjunto de puntos de manera simblica, cuya transformacin conllevara la extensin de las relaciones y por consiguiente de la base de datos.
3.3.3. Ejemplo de Modelado con Relaciones Restrictivas

Anteriormente se ha mostrado cmo es posible representar distintos tipos de restricciones en funcin del vocabulario () utilizado. A continuacin se mostrarn algunos ejemplos de cmo las relaciones restrictivas, correspondientes con estas clases de restricciones, pueden ser utilizadas adecuadamente para representar diferentes tipos de datos.
Restricciones lineales: El uso de restricciones lineales est ms extendido en el

dominio de las BDdR, frente al uso de las polinmicas. Esto es debido a que la evaluacin de las consultas sobre restricciones lineales es ms eciente que sobre restricciones polinmicas. Sea la relacin restrictiva s, formada por las restricciones:
(y = 2x (x = y )) y (1 x + y )
La frmula DNF (Disjunctive Normal Form) de s ser:
s (x, y ) (y = 2x (x = y )) (1 x + y ).
Donde s (x, y ) describe el conjunto de puntos que forman cada una de las restricciones en el espacio bidimensional (x, y).
Restricciones de igualdad a constantes: Son un caso particular de restricciones

lineales, por ejemplo la relacin q formada por las tuplas en el espacio bidimensional
(x, y), (1, 2) y (3, 4). Dichas tuplas son equivalentes a las restricciones x = 1 y = 2
y x = 3 y = 4. Por lo tanto q corresponde a la frmula q (x = 1 y = 2)
(x = 3 y = 4).
En general, todas las relaciones nitas de aridad k en el conjunto D con n tuplas
i ai 1 , . . . , ak para i = 1, . . . , n pueden representarse como una relacin restrictiva de igualdad
mediante la frmula:
n i=1 ((x1
i = ai 1 ) . . . (xk = ak ))
56
Restricciones polinmicas con inecuaciones: Sea la relacin restrictiva t formada

por las restricciones:
(x y y 6 x y 0), (x 3 y y 9 x x 0) y (x2 + y 2 9)
La frmula DNF correspondiente ser:
t (x, y ) (x y y 6 x y 0) (x 3 y y 9 x x 0) (x2 + y 2 9)
La gura 3.4 presenta de forma grca el conjunto de restricciones denida por la frmula t , la cual representa un conjunto innito de puntos en el espacio bidimensional
(x, y).
y
Figura 3.4: Figura representada por la frmula t
3.4. Consultas a Bases de Datos de Restricciones

Como se ha comentado anteriormente, la lgica de primer orden es un lenguaje declarativo, mientras que en las bases de datos se utilizan tambin lenguajes procedimentales como es el lgebra relacional, por lo que es necesario analizar cmo se adapta el lgebra relacional cuando se trata con restricciones descritas con lgica de primer orden.
3.4.1. Eliminacin de cuanticadores

Una consulta a una base de datos clsica sobre una relacin consiste bsicamente en la seleccin de un conjunto de atributos que cumplen una determinada condicin. Esta seccin se centra en la seleccin de los atributos, lo que signica devolver slo una parte de la relacin involucrada en la consulta. En el caso de las BDdR, eliminar una parte de la informacin no siempre es trivial, e incluso en algunos casos no es posible.
Consultas a Bases de Datos de Restricciones
57
Los algoritmos de eliminacin de cuanticadores [101][152][98][145] transforman frmulas con cuanticadores en otras equivalentes sin dichos cuanticadores. La operacin de proyeccin sobre las variables de una restriccin conllevan dicha eliminacin de cuanticadores, donde un ejemplo muy utilizado es:
(a, b, c) x(ax2 + bx + c > 0), donde a, b y c son parmetros (variables libres) y x es la variable cuanticada a eliminar.
Tras la eliminacin de x se obtendr la frmula equivalente a :
(a, b, c) (a > 0 b2 < 4ac)

Como se comenta al principio de este apartado, no siempre es fcil o posible realizar esta eliminacin [75], lo que se muestra en el siguiente ejemplo. Sea una estructura (Z; {+}, {0, 1}, {=}), y la frmula:
y = 3x + 2
para eliminar la variable x obteniendo slo y (x(y = 3x + 2)), la frmula no puede ser expresada sin la variable x, a menos que se incluyan otras funciones en el vocabulario, en este caso:
y mod 3 = 2
Una estructura M admite eliminacin de cuanticadores efectivos, si para todas las frmulas (x1 , . . . , xn ) en la estructura M, existe (y puede ser encontrada ecientemente) una frmula libre de cuanticadores (x1 , . . . , xn ) tal que satisfagan M, lo que es equivalente a decir que:
M |= (x1 , . . . , xn ) (x1 , . . . , xn ) (x1 , . . . , xn )

O lo que es lo mismo, que la relacin extendida sin las variables que se quieren eliminar sea denible con restricciones. Slo para la estructura (I R; {+, }, {0, 1}, {<}) es posible asegurar que se puede encontrar una frmula libre de cuanticadores, para el resto de estructuras depender de las restricciones que se construyan con ellas.
3.4.2. Consultas sobre restricciones

Basndonos en la denicin de las BDdR como un conjunto nito de relaciones de restricciones, un Esquema de bases de datos (SC) ser denido como un conjunto nito no vaco de relaciones restrictivas con nombres. Estos Esquemas son necesarios para realizar
58
las consultas sobre la base de datos, pudiendo diferenciar una relacin de otra. De esta forma, en las BDdR los Esquemas son equivalentes a lo que son las relaciones para las bases de datos relacionales. Cuando nos enfrentamos a las consultas a BDdR, hay que tener en cuenta que a nivel conceptual son una representacin simblica de bases de datos extensivas, por lo que la consulta se complica. Esto signica que se pueden abordar de dos formas: a nivel conceptual sobre bases de datos extensivas, o a nivel de representacin sobre las propias restricciones. Una consulta a nivel de representacin ser consistente slo si corresponde con una consulta en el nivel conceptual, como se muestra en la gura 3.5. Conceptualmente, las BDdR son representaciones simblicas de lo que podan ser bases de datos relacionales. De esta forma, se puede pensar en una consulta desde dos puntos de vista: en el nivel conceptual como una transformacin sobre una base de datos relacional, donde se obtienen restricciones consultando por datos no restrictivos; o en el nivel de representacin como una transformacin de las restricciones (consulta sobre restricciones), donde se obtienen restricciones como salida. Una consulta en el nivel de representacin se puede realizar slo si corresponde con una consulta en el nivel conceptual.
Consulta sobre Restricciones D Q Q(D)
BDdR A nivel de Representacin representa A nivel Conceptual
Relacin Restrictiva de salida representa
Base de Datos Do extensiva
Consulta sobre Q0 informacin sin restricciones
Relacin sin Qo (Do) restricciones de salida
Figura 3.5: Consistencia en las consultas a restricciones Un ejemplo de consulta presentada en [44] es la siguiente, donde un esquema se representa mediante la relacin T de aridad 3 (x1 , x2 , x3 ). La base de datos extendida o sin restricciones consiste en un conjunto de tuplas en I R3 , que puede ser representada como la unin nita de un conjunto de inecuaciones polinmicas en una BDdR. Sean las restricciones del esquema T de una base de datos D, representado de la forma D(T ) = {1 , . . ., M }. Para realizar una consulta Q de aridad 2, donde slo se quieren obtener las variables x1 y x2 , se escribir una frmula de forma:
59
x3 (1 . . . M )
Ya que (I R; {+, }, {0, 1}, {<}) admite la eliminacin de cuanticadores, se puede obtener como una frmula en funcin de x1 y x2 tras eliminar la variable x3 . se representar en DNF, con una frmula de la forma:
1 . . . l
donde dicha frmula ser el resultado de evaluar la consulta Q sobre la base de datos
D, representado como Q(D):={1 . . . l }. La consulta a la restriccin es consistente,

ya que transforma cada conjunto semi-algebraico de I R3 en sus proyecciones en el plano (x1 ,x2 ). Donde un conjunto X , consistente en tuplas de elementos sobre un dominio, se llama semi-algebraico si es denible con inecuaciones polinmicas sobre los reales. Una vez construidas las consultas, stas se evalan reemplazando las instancias de los predicados de la base de datos por la frmula que dene la relacin, y usando la eliminacin de cuanticadores para convertir el resultado en la forma normal disjuntiva. Las propiedades de las consultas a bases de datos relacionales, listadas abajo, contribuyen al xito del modelo relacional. Por esta razn, las BDdR tambin deben cumplir estas propiedades:
Clausura: Es una propiedad que poseen los lenguajes cuya lgebra relacional es
cerrada, lo que signica que la salida de la evaluacin de una consulta puede ser utilizada como relacin de entrada para otra consulta. Esto signica que Q(D):=D', o lo que es lo mismo, que la salida de una consulta restrictiva aplicada a una relacin restrictiva, debe ser tambin una relacin restrictiva. La propiedad de clausura es muy til, ya que se puede descomponer una determinada consulta, facilitando su escritura, en consultas ms simples anidadas.
Eciencia de evaluacin: Las consultas pueden ser evaluadas ecientemente en

funcin de la complejidad de los datos y su cantidad, lo cual consiste en evaluar una consulta en trminos del tamao de la base de datos [31][91]. Si se utiliza el lgebra relacional como lenguaje de consulta, es posible denir una planicacin de las consultas para optimizar el tiempo o la memoria necesaria para su evaluacin. Las propuestas que analizan al nal de este captulo han tenido en cuenta este aspecto de las BDdR, cada una utilizando distintas estrategias.
60
Consistencia: Sea D una BDdR y D0 una base de datos extendida donde D representa a D0 . Una consulta sobre restricciones Q se le denomina consistente si existe una consulta no restrictiva Q0 tal que Q(D) es denible si y slo si Q0 (D0 ) es denible y Q(D) representa a Q0 (D0 ). Teniendo en cuenta que una consulta es una frmula en la lgica apropiada, donde tanto la entrada como la salida son un conjunto de relaciones, se puede utilizar para el estudio de las BDdR dos lenguajes diferentes de consulta, el lenguaje del lgebra relacional y el clculo relacional. Aunque ambos son equivalentes, utilizaremos el lgebra relacional por ser procedimental en lugar de declarativo, como es el clculo relacional. El lgebra relacional describe cmo se obtiene una relacin partiendo de una o varias de entrada, especicndose de forma explcita un cierto orden, lo que implica una cierta estrategia al evaluar la consulta. Por otro lado, el clculo relacional especica qu hay que extraer, derivando de una rama de la lgica simblica denominada clculo de predicados, donde un predicado es una funcin booleana con argumentos. En esta tesis se utiliza el lgebra relacional ya que permite establecer una equivalencia directa de cada una de las operaciones con las del lenguaje de consulta SQL, junto a la posibilidad de describir el orden en el que se evaluarn las distintas partes de las operaciones sobre una relacin, con el objetivo de optimizar la evaluacin de consultas.
3.4.3. Algebra Relacional para Restricciones

El lenguaje del lgebra relacional es un lenguaje procedimental, donde tanto los operandos como los resultados son relaciones (propiedad de cierre), permitiendo anidar expresiones. Dicho lenguaje tiene denido cinco operadores bsicos: la proyeccin ( ), la seleccin ( ), la unin (), la diferencia (), y el producto cartesiano (). Con los cuales pueden construir una expresin para la consulta, y denir operadores ms complejos. Muchos trabajos han analizado cmo ampliar el lgebra relacional cuando las consultas se hacen sobre BDdR [44][10][58]. En esta tesis se utiliza la redenicin propuesta en [44] del lgebra relacional para restricciones, que se basa en la denicin de las Expresiones del
lgebra Relacional (Relational Algebra Expressions, RAEs). Sea un vocabulario , una

estructura M sobre y un esquema de base de datos (SC) donde U denota el dominio de M, las expresiones del lgebra relacional se denen de forma inductiva como:
U es una Expresin del lgebra Relacional.
61
Cada relacin R SC es una Expresin del lgebra Relacional. Si e1 y e2 son Expresiones del lgebra Relacional de aridad k1 y k2 respectivamente, el producto cartesiano (e1 e2 ) es una Expresin del lgebra Relacional de aridad
k1 +k2 .
Las Expresiones del lgebra Relacional, involucradas en las operaciones de unin y diferencia, tienen que tener la misma aridad, y con ambas se obtiene una Expresin
del lgebra Relacional de esa aridad.

Si e es una Expresin del lgebra Relacional de aridad k , e i1 , . . ., ip {1, . . ., k }, entonces la proyeccin i1 ,...,ip (e) es una Expresin del lgebra Relacional de aridad
p.
Si e es una Expresin del lgebra Relacional de aridad k , y es una frmula libre de cuanticadores sobre tambin de aridad k (con las variables x1 , . . ., xk ), entonces la seleccin (e) es una Expresin del lgebra Relacional de aridad k . Una vez denida la aridad de las operaciones, a continuacin se muestra la equivalencia entre las bases de datos extensivas D y las consultas no restrictivas Qe , en comparacin con la BDdR D y las consultas sobre restricciones Qe para las distintas Expresiones del
lgebra Relacional. Siendo e una Expresin del lgebra Relacional:

Si e es el dominio U (e de aridad 1), entonces Qe (D) := U , ya que se obtendrn todos los valores del dominio de forma extensiva. De forma intensiva ser Qe (D ) :=
{x1 = x1 }, que representa de forma simblica que x1 puede tomar cualquier valor
del dominio. Si e es R SC (una relacin de la base de datos), entonces Qe (D) := D(R) que representa todas las tuplas de los valores que pueden tomar las variables de la relacin R, y Qe (D) := D (R) que representa las restricciones que forman las relacin
R.
Si e es (e1 e2 ), entonces Qe (D) := Qe1 (D)Qe2 (D). Siendo las variables de e1 {x1 , . . ., xk1 } y las de e2 {x1 , . . ., xk2 }, se renombran las variables de e2 usadas en
Qe2 (D ) como xk1 +1 , . . ., xk1 +k2 respectivamente. Por lo tanto: Qe (D ) := { } | Qe1 (D ), Qe2 (D )
62
ya que cada restriccin y formarn una misma tupla y por lo tanto tendrn una relacin de conjuncin entre ellas. Si e es (e1 e2 ), entonces Qe (D) := Qe1 (D)Qe2 (D), y Qe (D ) := Qe1 (D )Qe2 (D ), donde la relacin entre las restricciones de Qe1 (D ) y Qe2 (D ) es de disyuncin.
Qe1 (D )
) (
Qe2 (D )
Si e es (e1 e2 ), entonces Qe (D) := Qe1 (D)Qe2 (D). Considerando la frmula
Qe (D ), despus de renombrar las variables x1 , . . . , xk a y1 , . . . , yk respectivamente,

es (y1 , . . . , yk ). Considerando la frmula:
Qe1 (D )
) (
Qe2 (D )
Poniendo en DNF, 1 . . . l , entonces Qe (D ) := {1 , . . . , l }. Si e es i1 ,...,ip (e ) con e de aridad k y donde i1 , . . . , ip {1, . . . , k }, esto implica que
Qe (D) := {(ai1 , . . . , aip ) | (a1 , . . . , ak ) Qe (D)}.

Para la representacin mediante restricciones, se supone que la frmula correspondiente a Qe (D ) despus de renombrar las variables x1 , . . ., xk a y1 , . . ., yk , construyendo (y1 , . . ., yk ). De forma que a partir de la frmula:
(x1 , . . . , xk ) y1 , . . . , yk
p j =1
xj = yij
se genera una nueva frmula libre de cuanticadores , donde se han eliminado las variables ym y1 , . . . , yk que no pertenecen a las p variables de la proyeccin. Dicha frmula ser equivalente a pero expresada en DNF tal que 1 . . . l , de forma que Qe (D ) := {1 , . . . , l } Si e es (e ), entonces Qe (D) := {a |a Qe (D) y M |= ( a)}. En este caso a representa los vectores de la misma aridad que e con los valores de las variables que cumplen la condicin . Suponiendo que la frmula correspondiente a Qe (D ) es , poniendo en DNF obtenemos 1 . . . l , de manera que Qe (D ) :=
{ 1 , . . . , l }
De esta forma, para cada Expresin del lgebra Relacional e, la consulta sobre restricciones Qe representa la consulta para informacin extensiva Qe .
Prototipos de Bases de Datos de Restricciones
63
3.4.4. Evaluacin de consultas en BDdR

Hay dos aspectos que hay que estudiar en las consultas a BDdR. La primera de ellas es cundo se hace el tratamiento de las restricciones, si en tiempo de ejecucin o en tiempo de compilacin. Y la segunda de ellas es si dicha evaluacin se realizar con estrategias ascendentes (bottom-up) o descendentes (top-down). Los sistemas de BDdR en tiempo de ejecucin estudian las restricciones nicamente cuando se evalan las consultas, mientras que el tratamiento en tiempo de compilacin conlleva simplicar y reescribir las restricciones cuando son almacenadas, antes de ser evaluadas para una consulta. Cmo se realiza el proceso de evaluacin se muestra en la gura 3.6, donde =
(x1 , . . . , xm ) representa una consulta sobre restricciones para las variables x1 , . . . , xm .

Dicha consulta se evaluar sobre las relaciones cuyos nombres son R1 , . . ., Rn , lo que se representa de la forma (R1 , . . . , Rn :x1 , . . . , xm ). Para una Base de Datos de Restricciones
D concreta denida para una -estructura M, donde sus relaciones restrictivas expresadas en DNF son r1 , . . . , rn , el primer paso de la evaluacin ser la eliminacin de cuanticadores. Tras la eliminacin de cuanticadores, la salida de la consulta puede ser un conjunto innito de puntos con m dimensiones que satisfacen la frmula (a1 , . . . , am ), o una representacin mediante restricciones en DNF. La representacin de los valores (a1 , . . . , am ) que satisfacen de manera simblica, puede denir un nuevo conjunto de relaciones denidas sobre M que a su vez pueden ser entrada de otra consulta (cumplen la propiedad de clausura).
3.5.
Existen muchos prototipos e implementaciones para BDdR, cuyas principales diferencias radican en los modelos lgicos que utilizan para almacenar las restricciones, si tienen o no capacidad de inferencia basada en la Programacin Lgica, los tipos de restricciones con las que trabajan, y cmo evalan las consultas. A continuacin se analizan las aportaciones ms relevantes.
64
Consulta sobre restricciones (R1,,Rn:x1,,xm)
BDdR de entrada D(r1,rn) con ri en DNF
Eliminacin de cuantificadores
Restricciones en (r1/R1,,rn/Rn)
{(a1,, am): (a1,, am) es cierto}
Condicin de Clausura
Restricciones en
Figura 3.6: Evaluacin de Consultas a Restricciones
3.5.1. DISCO
DISCO [24][129] (Datalog with Integer Set COnstraints) es un sistema de BDdR basado en la Programacin Lgica con Restricciones, el cual implementa una reduccin de Datalog para restricciones booleanas cuyas variables estn establecidas en el dominio de los enteros, pudiendo denir el rango tanto de forma nita como innita. Como se explica en el capitulo 2, Datalog es un subconjunto de Prolog donde se denen reglas declarativamente, junto con un conjunto de relaciones existentes que se tratan como literales del lenguaje. Como los lenguajes declarativos, Datalog dene lo que un programa desea lograr, en vez de especicar los detalles de cmo lograrlo, siendo una mquina de inferencia la que deduce hechos nuevos a partir de las reglas. DISCO aade a Datalog la posibilidad de incluir ciertas restricciones, que se describen a continuacin, en el cuerpo de las clusulas.
Sintaxis
La sintaxis de DISCO es bsicamente la de Datalog, denotada como Datalog<Z ,P (Z) , ya que el cuerpo de las reglas slo puede contener conjunciones de restricciones de orden sobre enteros o conjuntos. Lo que signica que los problemas a resolver mediante DISCO estn constituidos por un conjunto de reglas y hechos Datalog denidos con restricciones
65
booleanas, donde las reglas son transformadas a expresiones del lgebra relacional. En este caso, un programa es un conjunto nito de reglas de la forma: R0 : R1 , . . . , Rl . La expresin de la cabecera R0 es una frmula atmica de la forma p(v1 , . . . , vn ), mientras que las reglas R1 , . . . , Rl son frmulas atmicas del tipo:
p(v1 , . . . , vn ): donde p es un predicado. v u: donde u y v son variables o constantes enteras, y es un operador relacional
{=, =, <, , >, , <g }, donde g es un natural y {v <g u} representa la expresin
v + g < u. V U o V = U : donde V y U son conjuntos de variables o constantes. cU oc / U : donde c es un entero o una constante y U es un conjunto de variables
o constantes.
Evaluacin de Consultas
DISCO utiliza la evaluacin 'bottom-up' basada en la eliminacin de cuanticadores sobre las restricciones de la base de datos. Para mejorar los tiempos de consulta, y asegurar que terminan en el caso de que sean recursivas, propone una mejora reduciendo el dominio en cada bsqueda [131], junto a la planicacin del tratamiento de las operaciones del lgebra relacional para optimizar la evaluacin [95].
Ejemplo
Aunque los sistemas DISCO pueden utilizarse en gran cantidad de ejemplos [131], uno muy descriptivo es una base de datos donde se almacenan siete coches (a, b, c ,d , e, f ,
g ) colocados en la en una calle. Sobre su colocacin conocemos algunos hechos: a y b no

estn aparcados al lado, e est delante de a con al menos 3 coches en medio, c est detrs de b con al menos 2 coches entre ellos, f est delante de g con al menos 4 coches entre ellos, y b y f estn juntos. La base de datos que representa las posiciones entre coches de manera genrica es:
suc(1,2).
...
suc(6,7).
66
adj(x,y) :- succ(x,y). adj(x,y) :- succ(y,x). gap(x,y) :- x<1 y. //x est a la izquierda de y, y no consecutivos gap(x,y) :- y<1 x. //y est a la izquierda de x, y no consecutivos range(x) :- 0<x, x<8. neq(x,y) :- x<y. //no son el mismo neq(x,y) :- y<x. //no son el mismo pos(1).
...
pos(7).
Y la consulta para conocer cul es la posicin de cada uno una de los coches ser de la forma: park(a,b,c,d,e,f,g) :- gap(a,g), e<3 a, b<2 c, f<4 g, adj(b,f),
range(a), range(b), range(c), range(d), range(e), range(f),range(g) neq(a,b), neq(a,c), neq(a,d), . . ., neq(e,g), neq(f,g) pos(a), pos(b), . . .
de donde se obtendr la salida:
park(a,b,c,d,e,f,g) :- a=5, b=3, c=6, d=4, e=1, f=2, g=7.
Inconvenientes
Pese a que DISCO permite trabajar con datos innitos mediante una representacin nita, s existen algunos inconvenientes a destacar en esta propuesta: Todos los avances en el campo de las bases de datos relacionales no se tienen en cuenta, ya que la informacin se almacena en un chero, obviando aspectos como evitar redundancia de datos, mantener integridad referencial o la creacin de estructuras de indexacin.
67
Al no estar la base de datos representada mediante entidades y relaciones, y al no estar normalizada, las modicaciones en el contenido de la base de datos conllevarn muchos cambios, lo que diculta su mantenimiento. Por ejemplo, si en lugar de siete coches tuviramos ocho, se tendran que hacer cambios en las reglas succ, range y
pos.
Como consecuencia del inconveniente anterior, y al no existir la posibilidad de integridad referencial, sera fcil olvidar algunas de estas actualizaciones de contenido, originando bases de datos inconsistentes. Los cambios estructurales en la base de datos son muy costosos. Por ejemplo incluyendo una nueva variable en la cabecera de alguna regla o en algn hecho, todas las consultas donde dichas variables estn involucradas tendran que ser modicadas, junto a todas las reglas que hicieran uso de ella. El lenguaje de denicin de datos y de consulta se aleja del estndar SQL, lo que hace difcil su utilizacin en el mercado. Las consultas son complejas y extensas. El rango en una base de datos relacional no se dene de forma explcita, ya que la solucin no puede tomar valores que no estn en la base de datos. Mientras que en el ejemplo, la denicin del rango se dene de forma explcita dos veces, en range y en las distintas instancias de pos. Pese a que la propuesta trabaja con valores enteros, y tericamente sobre dominios innitos, si la consulta inere restricciones con innitas soluciones el problema no podra ser tratado, al menos de forma completa. No permite trabajar con restricciones lineales ni polinmicas, slo permitiendo restricciones de orden y sobre conjuntos, lo que limita mucho su uso. No ofrece la capacidad de inferir nuevas restricciones partiendo de las almacenadas, obteniendo como salida de una consulta un conjunto de restricciones tras realizar una eliminacin de cuanticadores.
3.5.2. MLPQ/PReSTO
Esta propuesta presenta una combinacin del sistema MLPQ (Management of Linear Programming Queries) y PReSTO (Parametric Rectangle Spatio Temporal Object), am-
68
bos desarrollados en la Universidad de Nebraska-Lincoln [129][133]. El sistema MLPQ da soporte a la gestin de bases de datos con restricciones lineales. MLPQ fue esecialmente diseada para el tratamiento de informacin espacial, gracias a un entorno grco que permite trabajar en 2 3 dimensiones, y a la interaccin del usuario con el conocimiento almacenado mediante consultas. Por otra parte, PReSTO es un sistema de base de datos temporales, el cual permite consultas sobre sistemas que cambian en el tiempo.
Sintaxis
Las BDdR en MLPQ/PReSTO consisten en un conjunto de reglas Datalog [132], donde el cuerpo est formado por restricciones lineales. Estas restricciones lineales tienen la forma:
a1 x1 + a2 x2 + . . . + an xn b
donde ai y b son constantes, xi variables y es un operador de comparacin de entre {=, <, , >, }. La sintaxis del lenguaje de consulta de ambos sistemas (MLPQ y PReSTO) es muy similar a la de SQL, concretamente es un subconjunto de ste. En su lenguaje de consulta incorpora palabras reservadas de SQL como SELECT, WHERE, GROUP BY, HAVING, junto a agregados del tipo MIN y MAX.
Pese a que la sintaxis de MLPQ/PReSTO es muy similar a SQL, los datos no son almacenados en una base de datos relacional, sino mediante reglas Datalog en un chero de texto. Esto signica que la evaluacin de las consultas conlleva una transformacin de las consultas en SQL en una consulta Datalog. Los operadores que se permiten en las consultas contemplan la denicin de vistas, agregados (como min y max), unin e interseccin de relaciones, adems de las consultas en funcin de una condicin. Al basarse en Datalog, permite las consultas sobre estructuras recursivas, aadiendo un operador de aproximacin Apx el cual garantiza obtener una solucin en casos recursivos ya que establece el mximo nmero de soluciones que se pueden obtener.
69
Ejemplo
Un ejemplo de base de datos de MLPQ/PReSTO puede ser: almacenar un conjunto de pases (country(id, x, y, t)) donde se relacionan los puntos geogrcos pertenecientes a dicho pas (x, y ), el identicador del pas (id) y el ao t al que corresponde dichas caractersticas. La base de datos tambin almacena la localizacin de las ciudades (location(c, x,
y)), donde (x, y ) representa su situacin geogrca y c el identicador de la ciudad. Junto

a estas dos relaciones, country y location, tambin se almacena la relacin growth(t, c, p) que representa la poblacin p de una ciudad c en un instante de tiempo t. Un ejemplo de la informacin puede ser:
begin country(id,x,y,t):- id=1, x>=0, x<=4, y>=5, y<=15, t>=1800, t<=1950. country(id,x,y,t):- id=1, x>=0, x<=8, y>=5, y<=15, t>=1950, t<=2000. country(id,x,y,t):- id=2, x>=4, x<=12, y>=5, y<=15, t>=1800, t<=1950.
...
location(c,x,y):- x=3, y=2, c=101. location(c,x,y):- x=7, y=3, c=102. location(c,x,y):- x=5, y=6, c=103. location(c,x,y):- x=7, y=10, c=104.
...
growth(t,c,p):- c=101, p=10000, t>=1800, t<=2000. growth(t,c,p):- c=102, p=20000, t>=1800, t<=2000. growth(t,c,p):- c=103, p=10000, t>=1800, t<=2000.
...
end
Con esta informacin, se pueden realizar consultas como 'Obtener todas las ciudades
que en 1900 tenan una poblacin mayor de 10000', donde la consulta sera de la forma:
SELECT growth.c FROM growth, location, country
70
WHERE growth.c=location.c, location.x=country.x, location.y=country.y, growth.t=1900, growth.p>10000
Inconvenientes
Esta solucin comparte todas las desventajas que tiene DISCO con lo que respecta a la utilizacin de Datalog para el almacenamiento y representacin de la informacin. De esta formas se hace patente la prdida de la potencia de esta solucin por no utilizar bases de datos relacionales. Cuando las soluciones tras la evaluacin de las consultas tienen innitas soluciones, MLPQ/PReSTO utiliza un operacin de aproximacin, llamado Apx, para asegurarse de su nalizacin. Al basarse en Datalog, permite tanto consultas como estructuras recursivas, lo que puede llevar a obtener un nmero de soluciones innitas. Esto provoca que en algunos casos, el resultado de una consulta no sea completa, obtenindose slo algunas de las soluciones. No se pueden obtener nuevas restricciones derivadas de las almacenadas de una forma simblica. Si esto fuera posible, se evitaran las limitaciones de devolver en una consulta innitos valores y tenerlos que acotar mediante una aproximacin.
3.5.3. DEDALE
DEDALE [69][70][134] es una de las primeras implementaciones de BDdR que utiliza la orientacin a objetos para representar las restricciones. DEDALE fue un proyecto en el cual participaron los grupos de investigacin VERSO y VERTIGO pertenecientes a la Universidad de Pars para dar soporte a restricciones lineales. DEDALE fue desarrollado para trabajar exclusivamente para aplicaciones geogrcas, ya que su sintaxis y su semntica se centra en el tipo de consultas que se realizan en este mbito.
71
Sintaxis
DEDALE dispone de un lenguaje de consulta muy similar a SQL, mejorando la manipulacin de los objetos en el espacio. Entre las operaciones algebraicas que permite realizar entre los objetos geogrcos, se encuentran la interseccin, unin, diferencia, producto cartesiano, seleccin y la proyeccin. Para trabajar con las operaciones tpicas sobre objetos geogrcos dene macros, por ejemplo para conocer si dos objetos son adyacentes, dene funciones sobre los lmites o los vrtices de los objetos [46].
Al almacenar la informacin en una base de datos orientada a objetos, realiza una transformacin de las consultas en DEDALE a OQL (analizado en la seccin 2.4.2) para el tratamiento de los atributos atmicos o simples, aquellos que no son restricciones. Para la mejora de la eciencia en la evaluacin de consultas referentes a las aplicaciones geogrcas, sobre restricciones, aporta un conjunto de algoritmos para la optimizacin de las consultas presentados en [69]. Para las consultas sobre datos multidimensionales utiliza algoritmos basados en rboles como la variante de R-Tree, R Tree [8].
Ejemplo
Uno de los ejemplos de consulta sobre una base de datos DEDALE se muestra a continuacin. El lenguaje de consulta desarrollado en DEDALE se basa en la sintaxis de SQL, realizando transformaciones de las consultas usadas en los sistemas de informacin geogrca a OQL, como se observa en el siguiente ejemplo:
SELECT b.name FROM Resort a , Resort b WHERE a.name="Skiing Area" AND b.name="Building" AND b.geometry SOUTH-OF a.geometry
Lo que signica que siendo p1 los puntos pertenecientes a a y p2 los pertenecientes a b, si b est al sur de a, signica que siendo p1.x=p2.x, entonces p1.y>p2.y. Lo que DEDALE transformar en la siguiente consulta en OQL:
72
SELECT b.name FROM Resort a, Resort b WHERE a.name="Skiing Area" AND b.name="Building" AND (a.geometry JOIN b.geometry[1, 2 AS 3]) JOIN? 'geometry.2>geometry.3'
donde b.geometry[1, 2 AS 3] describe que es necesario renombrar la variable y en b, para que pueda tomar valores diferentes a los que toma en a. Tambin se puede destacar cmo la operacin a.geometry JOIN b.geometry[1, 2 AS 3] es la unin de las variables que tienen en comn ambos atributos (x en este caso), lo que permite seleccionar, mediante la comparacin 'geometry.2 > geometry.3', aquellos nombres de b que est al sur de a.
Inconvenientes
Pese a que el salto cuantitativo fue importante para esta propuesta, ya que por primera vez se utilizaron las bases de datos orientadas a objetos, an tiene aspectos que se pueden mejorar: Toda la sintaxis y la semntica del lenguaje est orientada al tratamiento de sistemas de informacin geogrcos, lo que provoca que esta solucin no sea genrica para cualquier sistemas denido mediante restricciones. Al utilizar las bases de datos orientadas a objetos como modelo lgico, toda la informacin se almacena como atributos dentro de un objeto, esto hace que mantenga todos los inconvenientes que se analizaron en la seccin 2.4.2, con respecto las bases de datos orientadas a objetos. Al basarse en sistemas espacio-temporales, el nmero de dimensiones del dominio de los problemas no puede ser mayor que cuatro. Esta caracterstica hace que la operacin de proyeccin no contemple qu ocurre cuando las tuplas que forman una relacin tengan variables distintas y cmo afecta esto a las distintas operaciones.
73
3.5.4. CCUBE
CCUBE (Constraint Comprehension Calculus) [19][20] dene el lenguaje de manipulacin de datos al que le debe su nombre. CCUBE presenta una integracin de restricciones con la orientacin a objetos para la optimizacin de consultas sobre objetos. El modelo de datos para el clculo de restricciones est basado en los objetos que describen restricciones espacio-temporales (Constraint Spatio-Temporal, CST). En la implementacin de CCUBE se plantea la denicin de un sistema con capacidad expresiva para datos complejos, pero sin perder de vista la necesidad de que el sistema sea eciente a nivel prctico.
Sintaxis
Con respecto a la sintaxis del lenguaje CCUBE, cabe destacar que utiliz como punto de partida la propuesta desarrollada por Kim et al. [87] donde se propone el lenguaje XSQL, el cual fue creado para adaptar la formalizacin de la lgica de primer orden a los lenguajes orientados a objetos. Otra de las aportaciones relevantes en el mbito de la orientacin a objetos, que inuy en CCUBE, fue una propuesta de Fegaras y Maier [50] llamado monoid calculus, probando su ecacia para lenguajes orientados a objetos como OQL. El monoid calculus es un formalismo algebraico para denir operaciones sobre estructuras algebraicas sencillas, proponiendo un tipo nico de datos junto a los operadores denidos en las bases de datos relacionales y las orientadas a objetos. De esta forma, se presenta como una semntica formal para el lenguaje OQL. Los formalismos anteriores fueron ampliados con restricciones lineales para la denicin de un lenguaje de consulta sobre restricciones orientadas a objetos. El formalismo de Kim et al. fue extendido [18][21] con la denicin del lenguaje Lyri C . La formalizacin de Fegaras y Maier [50] fue ampliada con el lenguaje CCUBE [17], creando un sistema de restricciones orientado a objetos que implementa disyunciones y conjunciones sobre restricciones lineales representadas con objetos en C ++ .
El modelo de datos de CCUBE se basa en restricciones espacio-temporales (CST, Constraint Spatio-Temporal) representadas mediante objetos. La evaluacin de las consultas
74
utiliza un conjunto de bibliotecas implementadas en C ++ que denen la clase CST, la cual implementa mtodos sobre restricciones como y , permitiendo combinaciones con operadores lgicos entre restricciones lineales. Las operaciones de dicha clase aseguran tiempo polinmico en la evaluacin de consultas, ya que utiliza el paquete CPLEX [79] desarrollado por Robert E. Bixby [16], el cual resuelve sistemas con restricciones lineales de gran tamao.
Ejemplo
Un ejemplo de denicin de objetos en CCUBE presentado en [20], es el objeto
my desk, el cual es de la clase DESK mostrado en la gura 3.7. En este ejemplo, el

atributo extent es del tipo CST, el cual tiene la capacidad de representa restricciones lineales.
Desk my desk = desk( catalogNo = 22354, name = 'one drawer desk', color = 'red', extent = (-4w 4 -2z2) drawer = new drawer( color = 'blue' center = (p=2 -3q1) extent = (-1w1 1 -1z1 1) translation = (w=w1 +p z=z1 +q) ) );
Algunos de los aspectos que presenta este ejemplo mediante sus atributos son: el tamao de desk y drawer vienen denidos mediante sus correspondientes atributos
extent, mientras que la posicin de drawer con respecto a desk la dene la restriccin
del atributo translation; el movimiento de drawer no puede ser cualquiera, ya que el atributo center dene que slo se puede mover hacia arriba o abajo, ya que p toma el valor nico 2. La siguiente consulta es un ejemplo donde se obtiene como salida nuevos objetos CST, encontrndose para cada escritorio (desk) de la clase all desks su posicin en una
75
Figura 3.7: Ejemplo de instancia de un escritorio (desk) con un cajn (drawer) en una habitacin habitacin, asumiendo que el centro del escritorio est en el punto (6, 4) y la ecuacin de traslacin (con respecto a las coordenadas de la habitacin) es u = w + x v = z + y . La consulta ser de la forma:
select new CST((u,v) | (dsk extend u=w+x v=z+y x=6 y=4 )) into {bag CST } result all desk as {desk} dsk
que obtiene nuevos objetos CST con las coordenadas u, v del escritorio con respecto a la habitacin, para el nuevo centro del escritorio tras su traslado. Cabe denotar que
{bag CST } determina el tipo del parmetro resultado, que en este caso ser un conjunto
de objetos del tipo CST.
Inconvenientes
Al igual que DEDALE, CCUBE representa un importante salto cuantitativo en las BDdR ya que utiliza la orientacin a objetos, pero tambin tiene sus inconvenientes. Al igual que DEDALE, CCUBE mantiene todos los inconvenientes de las bases de datos orientadas a objetos. Una de las deciencias de esta aportacin, tambin al igual que DEDALE, es la dependencia de resolver problemas del mbito espacio-temporal, no aportando una solucin independiente de la aplicacin.
76
Los objetos de la clase CST tienen denidas operaciones booleanas pero no tcnicas simblicas de sustitucin y eliminacin de variables, por lo que la operacin de proyeccin tendr ciertas limitaciones.
3.5.5. CQA/CDB
CQA/CDB [61] es un prototipo de BDdR especialmente desarrollado para el tratamiento de sistemas espacio-temporales implementado en JavaT M . Por esta razn, esta solucin slo utiliza restricciones lineales, que segn sus creadores son sucientes para aproximar los problemas del mbito espacio-temporal.
Sintaxis
La sintaxis de CQA/CDB es similar a la de SQL, pero incluyendo nuevas operaciones como project para trabajar sobre variables, y operaciones sobre agregados como area utilizado sobre sistemas espaciales [2]. CQA/CDB ampla los tipos de atributos que puede tener una tupla en dos: atributos clsicos o atributos que representan restricciones.
CQA/CDB dene una extensin del lgebra relacional denida sobre restricciones, ampliando las operaciones primitivas. Como mejora en la optimizacin de las consultas, propone la reordenacin del orden de evaluacin de los operadores y el uso de indexacin utilizando R -Tree para minimizar el nmero de objetos que se analizan en la evaluacin de las consultas.
Ejemplo
Un ejemplo presentado en [59] para aclarar esta aportacin, es una base de datos donde est almacenada el movimiento de un huracn sobre una regin. Consiste en tres relaciones cuyos esquemas son:
Parcela:[IdParcela:cadena; x,y:restriccin] PropietarioParcela:[nombre:cadena; t:restriccin; IdParcela:cadena] Huracn: [x,y,t:restriccin]
77
Este esquema dene un conjunto de parcelas denidas sobre x y y , y sus propietarios a lo largo del tiempo (denido por la variable t). La informacin Huracn dene la posicin con respecto a x e y de un huracn a lo largo del tiempo, tambin representando el tiempo con la variable t. Y algunos ejemplos de consulta sern: Obtener todas las parcelas por las que pas el huracn:
R0 = join Huracn and Parcela R1 = project R0 on IdParcela
Obtener los nombres de los propietarios de las parcelas que fueron azotadas por el huracn entre los instantes 4 y 9.
R0 = join PropietarioParcela and Parcela R1 = select t>= 4, t<= 9 from Huracn R2 = join R0 and R1 R3 = project R2 on nombre
Inconvenientes
Entre los inconvenientes de esta propuesta se encuentran: No hace una referencia expresa a qu modelo lgico utiliza para almacenar la informacin. Aunque CQA/CDB permite diferenciar los datos clsicos de las restricciones, ignora las caractersticas propias del lgebra relacional de Codd [32]. Pese a que la sintaxis tiene elementos en comn con SQL, aparecen operadores nuevos como PROJECT, y cambia la semntica de otros como SELECT, como ocurre en el segundo ejemplo mostrado para la sentencia R1. No describe de forma explcita que se cia a soluciones exclusivamente espaciotemporales, aunque los ejemplos que se presentan en la la bibliografa no tratan restricciones de otra naturaleza.
78
La denicin de la seleccin y la proyeccin se hace sobre un conjunto de restricciones denidas sobre las misma variables, pero no se establece su comportamiento cuando las restricciones tienen distintas variables.
3.5.6. DeCoR
La porpuesta DeCoR [67][66] presenta una implementacin de BDdR apoyndose en Bases de Datos Deductivas. Esta propuesta es de especial inters por la presentacin de un conjunto de transformaciones y reescrituras de la base de datos en tiempo de compilacin [68]. A esta reescritura se le denomina Constraint Lifting, mejorando la eciencia en la evaluacin de las consultas. Las BDdR de este sistema slo permite trabajar con restricciones lineales sobre el dominio de los reales.
Sintaxis
Al estar soportada por bases de datos Datalog, las restricciones estn descritas mediante reglas y hechos pero con una sintaxis que intenta acercarse a un lenguaje de bases de datos. Por ejemplo utiliza la palabra create para la creacin de relaciones (tablas),
assert para la insercin de informacin, y query para realizar consultas. Al basarse en

las Bases de Datos Deductivas, fue necesario la denicin de las equivalencias entre la terminologa deductiva y la relacional. Estas equivalencias son las mostradas en la tabla 3.1.
Terminologa Deductiva Terminologa relacional
Predicado Argumento Hecho Regla Frmula
Relacin Atributo Tupla Vista Expresin algebraica relacional
Tabla 3.1: Relacin entre la Terminologa Deductiva y la Relacional
79
El Constraint Lifting Algorithm (CLA) consiste en una transformacin donde el objetivo es mejorar los tiempos de evaluacin de consultas. Esta transformacin consiste en reescribir las clusulas para que durante la evaluacin slo los hechos relevantes para la consulta sean analizados. La idea principal es manipular y simplicar las restricciones contenidas en la base de datos, de manera que no sea necesaria su manipulacin en tiempo de evaluacin, salvo para instanciar las variables en funcin de la consulta y comprobar si las restricciones son satisfactibles. Un ejemplo fcil de transformacin de las restricciones es el siguiente:
q (X ) X + Y 6 2 X p1 (X, Y ) p2 (Y ). p1 (X, Y ) 1 X b1 (X, Y ). p2 (X ) b2 (X, Y ).

En una evaluacin bottom-up, se generaran valores de X en p1 , por ejemplo X = 1, que no haran satisfactible q(X). Pero si las reglas se transformaran en:
q (X ) X + Y 6 2 X p1 (X, Y ) p2 (Y ). p1 (X ) X + Y 6 2 X 1 X b1 (X, Y ). p2 (X ) X + Y 6 2 X b2 (X, Y ).

reduciendo p1 de la forma:
q (X ) X + Y 6 2 X p1 (X, Y ) p2 (Y ). p1 (X ) X + Y 6 2 X b1 (X, Y ). p2 (X ) X + Y 6 2 X b2 (X, Y ).

evitara la generacin de muchos hechos que nalmente no seran satisfactibles. Para evaluaciones up-down, el proceso de reescritura conllevara generar una nueva q con las restricciones de p1 de forma anloga.
Ejemplo
Un ejemplo de creacin de tablas y consulta es:
80
open test/test // apertura de la base de datos deductiva create scale(str, float, float, float, float) //creacin de tabla assert scale(str, 'sg', 0, 5000, 0, 0) //rellena la tabla scale
...
create persons(str, float) //crear la tabla persons assert persons('Tom', 80000) //rellenar la tabla persons
...
create taxes(str, float, float) //crear la tabla taxes assert persons(Kt, Sal, Taxes) //rellenar la tabla taxes scale(Kt, Min, Max, X, Y) &//crea relaciones entre las tablas Sal>=Min & Sal<Max & //establece restricciones Taxes = XSal+Y //establece restricciones
Y un ejemplo de consulta podra ser: qu impuestos deben pagar las personas de cualquier departamento? Cuya sentencia sera:
query taxes(Dep, Sal, Taxes) & persons(Pers, Sal)
Inconvenientes
DeCor al utilizar Datalog, compartiendo todos los inconvenientes comentados en DISCO y MLPQ/PReSTO. Junto a los inconvenientes propios a Datalog se pueden aadir, al igual que las dems, que no es posible inferir nuevas restricciones partiendo de las almacenadas.
3.6. Comparativas entre las Propuestas

Para realizar la comparacin entre las distintas propuestas, y la que es la aportacin de esta tesis (LORCDB), se utilizan seis parmetros que ayudarn a determinar las diferentes caractersticas que se consideran importantes para las BDdR, y que se muestran en la tabla 3.2.
Comparativas entre las Propuestas
81
1.
Soporte Lgico de Almacenamiento: Como se expuso en la seccin 2.4, los datos

pueden ser almacenados de forma diferente en funcin del soporte lgico que utilicen. Propuestas como MLPQ/PReSTO hacen referencia a la utilizacin de una base de datos, cuando en realidad utilizan un chero de texto plano para el almacenamiento de las restricciones. Esto signica que no trabajan con bases de datos relacionales, desaprovechando su potencia, capacidad de modularidad, soporte masivo de datos, capacidad de denir referencias entre relaciones . . . Las propuestas basadas en la orientacin a objetos, como DEDALE y CCUBE, almacenan toda la informacin como objetos, no separando lo que es la informacin discreta de la restrictiva. Esta decisin obliga a tratar de forma similar tipos de datos de carcter diferente. En estos casos, para adaptar una base de datos relacional a una Base de Datos de Restricciones, se tendran que convertir todos los datos de la base de datos original a la orientada a objetos. Para contrarrestar los inconvenientes de las bases de datos orientadas a objetos, pero sin perder la capacidad expresiva de la orientacin a objetos, en esta tesis se propone la utilizacin de Gestores de Bases de Datos Objeto-Relacionales. De esta forma se aprovechan todas las ventajas de las cualidades relacionales y la capacidad expresiva de la orientacin a objetos.
2.
Programacin Lgica: Algunas propuestas de BDdR incorporan las Programacin Lgica, permitiendo denir estructuras y lenguajes recursivos. Las propuestas que que permiten la Programacin Lgica son las cercanas a Datalog y por lo tanto a las Bases de Datos Deductivas, combinando en las clusulas tanto predicados como restricciones. Este aspecto no se trata en esta tesis, slo permitiendo trabajar con Programacin con Restricciones, sin aadir todas las caractersticas de la Programacin Lgica.
3.
Lenguaje similar a SQL: En muchas de estas propuestas, como DISCO y DeCoR,

el lenguaje que se utiliza para la creacin y consulta de las bases de datos est muy alejado del estndar SQL, siendo mucho ms prximos a la sintaxis de Datalog. Esto obliga a que los usuarios deban aprender este lenguaje mucho menos extendido en las bases de datos que SQL. Consideramos que el acercamiento de los lenguajes sobre bases de datos de restricciones a SQL es imprescindible, ya que al ser SQL un estndar de facto, facilita la incorporacin de las BDdR al mercado. La propuesta LORCDB, mantiene toda la sintaxis y semntica de SQL, aadiendo funcionalidad
82
relativa a restricciones. Esto hace posible que aplicaciones sobre bases de datos ya existentes fueran compatibles con su ampliacin a BDdR. 4.
Tipos de Restricciones: Pese a que en la teora de BDdR se contempla la posibilidad de trabajar con restricciones polinmicas, la mayora de las soluciones, al trabajar con problemas espacio-temporales, denen operaciones exclusivamente para restricciones lineales. Pese a que en muchos casos ser suciente con utilizar las restricciones lineales ya que pueden aproximar la solucin, en general las restricciones lineales no son sucientes. Por esta razn se propone ampliar los tipos de restricciones tambin a polinmicas.
5.
Independiente de la Aplicacin: Los ejemplos para los cuales se han desarrollado estos prototipos son mayoritariamente los datos espacio-temporales, como MLPQ/PReSTO o CQA/CDB. Eso enfoca la sintaxis y la semntica de las consultas a la aplicacin, no siendo soluciones generales sino dependiente del problema. Por esta razn en esta tesis se propone la denicin de un lenguaje que no sea dependiente del problema, pero que se pueda adecuar a l.
6.
Denicin del tipo Variable de Restriccin: La denicin de BDdR radica en

describir la relaciones de una base de datos como una restriccin mediante los operadores booleanos de conjuncin y disyuncin. Propuestas como CQA/CDB apuntan a la denicin de dos tipos de atributos, clsicos y restriccin. Sin embargo, en esta tesis se propone denir tres tipos de atributos: clsicos, restricciones y variables de restricciones. Ninguna de las propuestas existentes hasta el momento describe el lgebra relacional para estos tres tipos de atributos como el lgebra relacional hace con los tipos clsicos. Todas las propuestas enmarcan las operaciones sobre un conjunto de restricciones denidas sobre las mismas variables, no deniendo la semntica de los operadores cuando las restricciones se denen sobre mltiples variables distintas. Esto permite inferir nuevas restricciones partiendo de las almacenadas, utilizando sustitucin simblica de variables.
3.7. Resumen
En este captulo se muestran los formalismos que se han establecido para denir las Bases de Datos de Restricciones. Este anlisis va desde la denicin de qu es una Res-
Resumen
83
Modelo Lgico MLPQ/ PReSTO DISCO DEDALE CCUBE CQA/CDB DeCor LORCDB Archivo BDOO BDOO ? Archivo BDOR Archivo
Programacin Lgica S(Datalog) S(Datalog) No No No S(Datalog) No
Similar a SQL S No S S S No S
Tipo de Restriccin Lineales Lineales Lineales Lineales Lineales Lineales Lineales y Polinmicas
Independiente de la Aplicacin No No No No No S S
Variable de Restriccin No No No No No No S
Tabla 3.2: Caractersticas de los prototipos de Bases de Datos de Restricciones
triccin utilizando la lgica de primer orden, hasta la combinacin de las restricciones para
dar origen a las BDdR. Para denir los nuevos lenguajes de consultas sobre dichas bases de datos, se propuso una extensin del lgebra relacional adaptada a las nuevas necesidades, todo ello haciendo posible realizar la evaluacin de consultas sobre restricciones. Basndose en esas deniciones, se ha originado un conjunto de propuestas con distintas caractersticas: en funcin del modelo lgico de almacenamiento; si utilizan Programacin Lgica o slo Programacin con Restricciones; tipo de lenguaje de consulta y si estos permiten trabajar sobre un dominio de aplicacin genrico; tipos de restricciones a las que dan soporte (lineal o polinmica); y denicin de operaciones sobre mltiples variables de restricciones. Todas estas caractersticas se presentan en una comparativas de las distintas propuestas, detectando las deciencias que se mitigarn en la propuesta LORCDB, la que se detalla en esta memoria de tesis.
Captulo 4 Propuesta de Modelado para las Bases de Datos de Restricciones

En este captulo se reformulan algunas de las deniciones relacionadas con las Bases de Datos de Restricciones, con el objetivo de diferenciar los datos extensivos de los intensivos, de forma que la Base de Datos permita tratar y almacenar datos heterogneos de una manera homognea. Esto deriva en que se distingan tres tipos de atributos: los tipos clsicos, el tipo restriccin y el tipo variable de restriccin. Esto conlleva tambin la necesidad de redenir las operaciones primitivas del lgebra relacional para estos nuevos tipos, describiendo la sintaxis y la semntica de las distintas operaciones cuando los nuevos tipos estn involucrados. Al ampliarse los tipos de atributos de la bases de datos, ser necesario utilizar nuevas tcnicas para la evaluacin de las consultas, las cuales tambin se presentan en este captulo.
4.1.
Introduccin
La propuesta que se presenta en esta tesis cambia la denicin de BDdR, introduciendo nuevos conceptos fundamentados en la idea de que una relacin formada por un conjunto de tuplas puede ser representada como una combinacin de restricciones y atributos clsicos (de dominios atmicos). Esta idea es la presentada en la gura 4.1, que utiliza un ejemplo que muestra la equivalencia semntica entre un conjunto de tuplas de una relacin y una restriccin (4.1.a y 4.1.b), cuya transformacin se explic en la seccin 3.2.
86
Captulo 4. Propuesta de Modelado para las Bases de Datos de Restricciones
La redenicin de las BDdR aborda el tratamiento de las tuplas como atributos de valores extensivos (aquellos donde las variables se puedan representar mediante restricciones de igualdad entre variables y valores constantes) y atributos intensivos, que representarn relaciones entre variables en forma de restriccin. Esto da origen a relaciones cuyos atributos pueden ser de dos tipos, siendo equivalentes a una relacin extendida o a una relacin restrictiva, como se presenta en la gura 4.1.c.
x 5 5 5 ... 6 6 6 ... a 1 1 1 ... 1 1 1 ... b 1 2 3 ... 1 2 3 ... (a) c 2 3 4 ... 3 4 5 ... (b) (c)
( x = 5 a + b = c) ( x = 6 a + b + 1 = c)
para a, b, c, x: Natural
x 5 6
Restriccin a+b=c a,b,c: Natural a+b+1=c a,b,c: Natural
Figura 4.1: Equivalencia entre una relacin extendida, una relacin restrictiva y una relacin con atributos clsicos y restricciones La nueva denicin de las BDdR radica en la caracterstica de dualidad de los datos, extensivos e intensivos, para que ambos tipos puedan formar parte de una misma relacin. Aquellos que pueden ser representados como atributos clsicos no deben participar en la restriccin, mientras que los que toman un nmero de valores muy grandes o incluso innitos sern representados mediante variables pertenecientes a restricciones. Esta diferencia viene promovida porque el tratamiento de los datos intensivos, pese a su capacidad expresiva, es ms complejo que en el caso de los extensivos. Utilizando las dos formas de representacin ser posible minimizar el tamao de la base de datos haciendo posible que la informacin sea completa, a la vez que se pueden aprovechar todas las ventajas del lgebra relacional respecto a los atributos que toman un nico valor, manteniendo la primera forma normal que establece que los dominios de los atributos deben ser atmicos [32].
Una relacin de una BDdR est formada por dos tipos de atributos: atributos clsicos, que tienen una relacin de igualdad con un valor determinado, por lo que el atributo es a su vez una variable (como x en el ejemplo de la
Formalizacin
87
gura 4.1.c); y atributos que describen la relacin entre un conjunto de variables mediante una frmula (como el atributo Restriccin de dicha gura). El atributo Restriccin representa a su vez una relacin, pero en este caso una relacin restrictiva.
El nombre de la variable que tenga una relacin de igualdad con una constante, corresponder al nombre del atributo, mientras que el nombre del atributo restriccin tendr una relacin semntica con las variables, no sintctica. Por ejemplo, si se representa mediante una restriccin el recorrido de un vehculo utilizando las variables x, y y t, se le puede dar el nombre al atributo Recorrido, que es independiente de las variables que lo representan. Las variables que forman una restriccin no pueden formar parte de los atributos clsicos de dicha relacin, por ejemplo la variable x del atributo Recorrido, no puede ser a su vez un atributo clsico llamado x. Esta nueva denicin de equivalencias entre relaciones restrictivas y relaciones con atributos clsicos y restricciones, se origina para encontrar un nivel intermedio entre expresividad y optimizacin en la evaluacin de consultas, donde no toda la informacin sea representada de forma extensiva, ni toda de forma intensiva como una restriccin. Esta es la misma losofa que origin las Bases de Datos Objeto-Relacionales, para poder almacenar datos ms complejos sin perder las ventajas de los avances en el rea de las bases de datos relacionales.
4.2.
Formalizacin
Para redenir las BDdR, junto a las diferentes operaciones sobre las mismas, es necesario reformular algunas de las deniciones dadas en el captulo 3 relativas a restriccin,
k-tupla restriccin, relacin restrictiva y Bases de Datos de Restricciones.
4.2.1. Restriccin
Una restriccin es una relacin entre variables denidas sobre un dominio [42], donde existe una limitacin sobre el espacio de posibilidades o valores que pueden tomar dichas variables. El tipo Restriccin denido en esta tesis ser: Restriccin numrica denida como una combinacin conjuntiva de ecuaciones e inecuaciones, lineales y polinmicas.
88
La denicin de las restricciones se basa en la propuesta desarrollada en el captulo
2 de [130] con algunas variantes, utilizando una gramtica donde se denen las variables
y constantes de un dominio (Natural, Flotante o Entero). Una restriccin para la nueva denicin de DBdR ser de la forma:
restriccin := restriccin atmica '' Restriccin

| restriccin atmica
;
Donde una restriccin atmica es:
restriccin atmica :=expresin PREDICADO expresin ; expresin := trmino OPERADOR BINARIO expresin
| trmino | ''trmino
; trmino := Variable//representando el atributo variable de restriccin

| Constante
;
De forma general, los predicados y los smbolos de los operadores son:
PREDICADO := '=' | '<' | '' | '>' | '' ; OPERADOR BINARIO := '+' | '' | '' ;
La redenicin de las Bases de Datos de Restricciones que aqu se propone se basa en cuatro tipos de restricciones, tambin analizadas en [57]: restricciones lineales de igualdad, polinmicas de igualdad, inecuaciones lineales e inecuaciones polinmicas. Dependiendo del tipo de restriccin se utilizarn tcnicas y algoritmos diferentes para un tratamiento ms eciente, por lo que es necesario reformular la denicin de PREDICADO, expresin y OPERADOR BINARIO para detectar a cul de estos cuatro tipos pertenece:
Formalizacin
89
PREDICADO := PREDICADO ECUACIN

| PREDICADO INECUACIN
; PREDICADO ECUACIN := '=' ; PREDICADO INECUACIN := '<' | '' | '>' | ;

Entrando en los detalles para diferenciar las restricciones lineales y polinmicas:
expresin := expresin Lineal

| expresin Polinmica
; expresin Lineal := trmino Lineal SMBOLO LINEAL expresin Lineal

| trmino Lineal | ''trmino Lineal
; expresin Polinmica := trmino OPERADOR BINARIO expresin Polinmica

| trmino | ''trmino
; trmino := Variable
| Constante
;
Donde los trmino y los smbolos para las restricciones lineales son:
SMBOLO LINEAL := '+' | '' ; trmino Lineal := Constantes '' Variable '' Constantes
| Constantes '' Variable | Variable '' Constantes | Variable
; Constantes := Constante '' Constantes

| Constante
90
Constante := I R | N | Z ; Variable := I R | N | Z ;
Basadas en estos tipos de expresiones y predicados, se denen los cuatro tipos de restricciones soportadas:
Restricciones
lineales
de
Igualdad: Las que estn denidas sobre
expresin Lineal y PREDICADO ECUACIN
Restricciones sobre inecuaciones lineales: Las que estn denidas sobre

expresin Lineal y PREDICADO INECUACIN
Restricciones polinmicas de igualdad: Las que estn denidas sobre

expresin Polinmica y PREDICADO ECUACIN
Restricciones sobre inecuaciones polinmicas: Las que estn denidas sobre

expresin Polinmica y PREDICADO INECUACIN
4.2.2. Bases de Datos de Restricciones

Las aportaciones a las BDdR en esta tesis se apoyan en dos aspectos, uno de ellos es la redenicin de sus caractersticas acercndolas a las bases de datos relacionales clsicas aprovechando todos los avances en este rea. Por otra parte, se hacen propuestas relativas a la implementacin basadas en el modelo terico, un aspecto que se ha dejado en algunas ocasiones en un segundo plano en las soluciones existentes. En este captulo se analiza esta nueva denicin, mientras que los detalles de implementacin sern abordados en los siguientes captulos.
4.2.3. Nueva Denicin del Modelo de Bases de Datos de Restricciones

El nuevo modelo de BDdR sigue una denicin paralela a la original de las BDdR (denicin 3.8 del captulo 3), pero en este caso diferenciando las partes de la restriccin
Formalizacin
91
que se representan mediante igualdad de variables y constantes (atributos clsicos o univaluados), y la informacin representada mediante restricciones (atributos restriccin). Una k-tupla restriccin con las variables x1 , . . . , xk es una conjuncin nita de la forma 1 . . . N donde cada i , para 1 i N , es una restriccin de la forma {xj =Constante} donde xj {x1 , . . . , xk } a los que se denominar Atributo Clsico
o Univaluado, o una relacin representada mediante una restriccin, siguiendo la

gramtica de la seccin 4.2.1, entre las variables x1 , . . . , xk no pertenecientes a un atributo univaluado, a los que se denominar Atributo Restriccin. Una relacin restrictiva est denida como un conjunto de Atributos Univaluados y un conjunto de Atributos Restriccin. Una relacin restrictiva de aridad k, es un conjunto nito r = {1 , . . . , M }, donde cada j para 1 j M es una k-tupla restriccin sobre las variables x1 , . . . , xk . La frmula correspondiente es la disjuncin de la forma 1 . . . M , tal que j = 1 . . . N donde cada i para 1 i N es una k-tupla restriccin. Si existe en cada j r una i de la forma {x=Constante}, donde x sea la misma variable en todos los i pertenecientes a distintos j y x no aparece en el resto de los i de una misma j , se dir que x es un atributo univaluado, mientas que el resto de variables formarn parte en uno o varios Atributos Restriccin.
Relacin Restrictiva k-tupla restriccin
11 21 ... n1
2
...
12 22 ... n2
...
1m 2m ... nm
Figura 4.2: Representacin de k-tuplas restriccin y relaciones restrictivas
92
En la gura 4.2 se presenta la equivalencia entre una relacin restrictiva y las ktuplas restriccin que la forman. Para que en dicha relacin existan tanto atributos univaluados como atributos restriccin, tiene que cumplirse que: Siendo ij una i 1 . . . N y j 1 . . . M , tal que j = 1j . . . N j , una relacin restrictiva tendr atributos univaluados (x) si:
ij j 1..M | i 1..N , {ij x = cj } donde cj es una constante t 1..N t = i tj (x1 , . . . , xk ) x /{x1 , . . . , xk }

Lo que signica que si en todas las k-tuplas restriccin existe una relacin de igualdad entre una variable y una constante (la misma variable en todas las tuplas), y dicha variable no aparece en el resto de la k-tupla restriccin, se dir que dicha variable es un atributo univaluado o atributo clsico, ya que corresponde con la denicin de atributo en el lgebra relacional de Codd. Un ejemplo es el presentado en la gura 4.3, donde la relacin de la Base de Datos de Restricciones est formada por un atributo restriccin y dos atributos univaluados. En el ejemplo existen dos variables x e y que aparecen en todas las tuplas con una relacin de igualdad con una constante, y que no participan en el resto de la relacin, por lo que son atributos univaluados.
atributos univaluados
x y 2 3 3 8
relacin restrictiva
Restriccin
x = 5 y = 2a +b > cd + a < 8 x = 5 y = 3 a + b 1 > c e + a < 3 x = 7 y = 3 d *2 > c d + a < 7 x = 9 y = 8a +b+c = 5

para a, b, c, d, e: Natural
5 5 7 9
a+b > cd +a <8 a + b 1 > c e + a < 3

d *2 > c d + a < 7 a+b+c =5
Figura 4.3: Ejemplo de representacin de k-tuplas restriccin y relaciones restrictivas
Por lo tanto, una Base de Datos de Restricciones es una coleccin nita de relaciones restrictivas formadas por atributos univaluados y atributos restriccin. Un aspecto que an queda abierto es denir si todas las restricciones irn en un mismo atributo restriccin o en diferentes. Aunque a lo largo de este trabajo se tratar este tema
Formalizacin
93
otra vez, ahora es oportuno hacer algunas puntualizaciones. Una de las razones por la cual un conjunto de restricciones debe pertenecer al mismo atributo restriccin puede ser por las variables que las componen. Un ejemplo puede ser cuando se describen caractersticas de personas como nombre, edad, . . . (atributos univaluados), junto a la situacin geogrca de la parcela que posee sobre las variables (x, y ), que describen la latitud y longitud de los distintos puntos que la forman. En este caso se utilizar un atributo restriccin para almacenar todas las parcelas, ya que todas las restricciones estn denidas sobre las mismas variables y describen una misma caracterstica. Sin embargo existen otros dos casos de anlisis relativos a este tema:
Restricciones denidas sobre las mismas variables pero que describen distintas caractersticas. Un ejemplo puede ser: sean dos tipos de restricciones,
ambas sobre (x, y ), una que describe las parcelas y otra las casas. Pese a estar denidas sobre las mismas variables, describen dos caractersticas de las posesiones de la persona y desde el punto de vista de las bases de datos relacionales clsicas, no sera conveniente almacenarlas en un mismo atributo ya que no tienen relacin semntica.
Restricciones denidas sobre distintas variables pero que describen la misma caracterstica. Un ejemplo de esto es el que precisamente ocurre en la
diagnosis de fallos basada en modelos, que es uno de los casos de estudio analizados en esta tesis. En la diagnosis basada en modelos cada componente puede ser descrito mediante una restriccin, que estar denida sobre variables que no tiene que ser iguales a las variables de las restricciones. De hecho, lo ms usual es que los componentes tengan distintas entradas y salidas para conformar los sistemas, pero que a nivel semntico las restricciones describen una misma caracterstica: el comportamiento de los componentes. En este caso las restricciones de los componentes pertenecern a un mismo atributo.
4.2.4. Atributos en las Bases de Datos de Restricciones

Derivado de las deniciones anteriores, aparece una nueva clasicacin de atributos que permitir crear, actualizar y consultar las BDdR en concordancia con sus caractersticas. En esta nueva denicin existen tres tipos distintos de atributos:
94
Atributo Clsico (ati ): Representa un atributo perteneciente a una k-tupla de

una relacin, donde ati es de un tipo permitido por el estndar SQL, como por ejemplo Numrico, Cadena, Fecha . . . Este tipo de atributo es el denido como atributo univaluado.
Atributo Restriccin (atc i ): Representa un atributo perteneciente a una k-tupla

de una relacin, donde atc i es una restriccin (atributo restriccin), por lo que a su vez describe una tupla de variables. Dicho atributo restriccin tendr un nombre, al igual que los atributos univaluados, pero no relacionado con la sintaxis de las variables, sino con su semntica.
Atributo Variable de Restriccin (atc i .vj ): Representa un atributo que ser

una variable vj {v1 , . . ., vk } que participa en el atributo restriccin atc i . No es necesario que la variable vj pertenezca a todas las restricciones de las distintas tuplas que forman la relacin, pero s al menos a una. Por ejemplo en la gura 4.4 se presenta de manera extensiva la relacin de la gura 4.3 donde se puede hacer referencia a un atributo univaluado (x o y ), a una restriccin completa (Asociacin), a una variable que est en todas las restricciones (Asociacin.a), o a una variable que slo est en una restriccin del atributo restriccin (Asociacin.e).
4.3. Consultas a Bases de Datos de Restricciones

Al tener nuevos tipos distintos de atributos, ahora las consultas a las BDdR sern ms complejas. Al igual que se present en el captulo 3, ser necesaria la eliminacin de cuanticadores para inferir nuevo conocimiento derivado de las restricciones almacenadas, junto a nuevas estrategias que resuelvan la evaluacin de consultas para estos nuevos tipos de atributos. Antes de comenzar con la redenicin del lgebra relacional para las nuevas BDdR, es conveniente comparar algunas propiedades de las bases de datos clsicas y su relacin con las BDdR: Cada instancia de los atributos tienen un nico valor, a lo que se le denomina dominio atmico. Esto no ocurre en las BDdR a nivel de atributo restriccin, ya que el atributo de una relacin puede ser una restriccin que represente muchos valores
95
x 5
y 2
a 1 2 3 4 ...
Asociacin
b 1 1 2 2 ... b 2 1 3 2 ... c 1 1 3 2 ... b 1 2 3 1 ... c 1 1 4 4 ... c 1 1 2 2 ... d 5 6 2 2 ... c 3 2 1 2 ... d 6 5 3 3 ... e 2 0 1 0 ...
a 1 2 1 2 ...
a 1 1 1 2 ...
a 1 1 1 2 ...
Figura 4.4: Representacin extendida de la relacin de la gura 4.3
para un conjunto de variables. Sin embargo analizado desde el punto de vista de que un atributo restriccin es a su vez una relacin de variables, se podra denir como una referencia a una relacin. Esto mantendra conceptualmente la primera forma normal, a la vez que permite la inclusin del atributo restriccin. Los valores de los atributos tienen que pertenecer a un determinado dominio. Sobre esto es necesario hacer alguna aclaracin para la nueva denicin de las BDdR, ya que un atributo restriccin puede estar denido sobre distintas variables, aunque s es necesario que todas las variables de un mismo atributo restriccin estn denidas sobre el mismo dominio (Naturales, Enteros o Flotantes). Cada relacin tiene un nombre diferente para poder diferenciar una de otra, lo que
96
tambin ocurre en las BDdR, a lo que en la teora de las BDdR se le llama esquema de la base de datos. Cada atributo de una relacin tiene un nombre nico dentro de dicha relacin, lo que tambin ocurre en las BDdR. La diferencia es que s es posible que la misma variable pertenezca a atributos restriccin diferentes, de forma que dos restricciones puedan denir relaciones sobre la misma variable. Cada tupla es diferente, no pudiendo estar duplicadas. Esto tambin tiene algunos detalles en las BDdR, donde hay que evitar que dos restricciones que estn representadas de una manera sintcticamente diferente no representen el mismo conjunto de valores. El orden de los atributos y de las tuplas no es importante, ni en las bases de datos relacionales ni en las BDdR. Para denir las consultas es necesario apoyarse en las cinco operaciones primitivas del lgebra relacional, con las cuales se pueden denir las restantes. Dichas operaciones son: seleccin ( ), proyeccin ( ), producto cartesiano (), unin de conjuntos () y diferencia de conjuntos (). Adems del tipo de operacin, hay que tener en cuenta qu tipos de atributos estn involucrados en dicha operacin, lo que depender de cada caso.
Operador de Seleccin. Su signatura es (R1 = predicado (R2 )), donde R1 y R2 son

relaciones de una base de datos y el predicado una condicin que involucra atributos de la relacin R2 . La relacin R1 es un subconjunto horizontal de la relacin R2 que representa aquellas tuplas que satisfacen la condicin del predicado. Un predicado es una expresin booleana cuyos componentes son operadores lgicos ={, } y operadores de comparacin ={<, , >, , =, <>}. Los operandos de estos operadores son atributos o constantes pertenecientes al dominio del atributo. Esto signica que el predicado tendr la forma:
a1 c1 a2 c2 . . . an cn
donde ai representa un atributo (de cualquier tipo de los tres propuestos) y ci constantes del mismo tipo que ai u otro atributo. Tambin se pueden denir las condiciones mediante negaciones , de la forma (ai ci ). Cuando nos referimos a esta operacin en las BDdR, es necesario replantear la parte del predicado del operador de seleccin, ya que podra hacer referencia a
97
atributos clsicos, atributos restriccin o a atributos variable de restriccin. Los detalles relativos a las BDdR se muestran en la seccin 4.5.
Operador de Proyeccin. Su signatura es R1 = <a1 ,...,an > (R2 ), donde R1 y R2

son relaciones y a1 , . . . , an son atributos de la relacin R2 . La relacin R1 es un subconjunto vertical de la relacin R2 , donde slo aparecen los atributos a1 , . . . , an y sin tuplas duplicadas. Para esta operacin en las BDdR, es necesario replantear la obtencin de los atributos, ya que si se pretende obtener un conjunto de atributos del tipo variable de restriccin, sera necesario eliminar de la solucin aquellas variables de las restricciones que no aparecieran en la proyeccin. Los detalles relativos a la proyeccin para las BDdR se muestran en la Seccin 4.6.
Producto Cartesiano. Su signatura es R3 = R1 R2 , donde la relacin R3 dene la

unin horizontal (con el operador ) de cada tupla de la relacin R1 con cada tupla de la relacin R2 . De esta forma, la operacin une horizontalmente dos relaciones obteniendo una nueva con todos los pares posibles entre las tuplas de R1 y R2 . Si una relacin tiene I tuplas y N atributos y la otra tiene J tuplas y M atributos, la relacin R3 tendr (I J ) tuplas (cardinalidad) con (N + M ) atributos (grado). Para este operador no es necesario describir una nueva semntica operacional para los atributos restriccin ni variables de restriccin, ya que los operandos de esta operacin son relaciones, lo que no permite diferenciar entre los distintos tipos de atributos. Su descripcin es igual a la denida en el lgebra relacional clsica pero con atributos que pueden ser restricciones.
Unin de Conjuntos. Su signatura es R3 = R1 R2 , donde se dene la relacin

R3 como la unin vertical de todas las tuplas de R1 y R2 , sin tuplas duplicadas. R1
y R2 tienen que ser compatibles con respecto a la unin, lo que signica que tienen que tener el mismo grado y que para todos los atributos de R1 , su atributo i-simo tiene que ser del mismo tipo que el atributo i-simo de R2 . Pese a que al igual que el producto cartesiano, los parmetros de entrada de la unin de conjuntos son relaciones, s es interesante destacar que ser necesario el anlisis de la relacin de salida. Como se ha comentado, la unin de conjuntos no permite tuplas duplicadas, as que ser necesario cerciorarse de que dos tuplas con atributos restriccin no representan el mismo conjunto de valores, o que los valores de una de
98
las tuplas no estn incluidos en otra. Los detalles relativos a las BDdR se muestran en la seccin 4.7.
Diferencia de Conjuntos. Su signatura es R3 = R1 R2 , donde R3 es una relacin

formada por las tuplas de R1 que no pertenecen a R2 . Las relaciones R1 y R2 tambin tienen que ser compatibles en el mismo aspecto que en la unin. Tambin para esta operacin, en el caso de los atributos que sean restricciones, ser necesario analizar cundo una restriccin es o no igual a otra, lo que se estudia en la seccin 4.8.
4.4. Resolucin de Problemas con Restricciones

Antes de comenzar la exposicin sobre cmo evaluar las consultas para las distintas primitivas presentadas, es necesario introducir dos tipos de tcnicas para resolucin de problemas: los problemas de satisfaccin y optimizacin de restricciones; y la eliminacin y sustitucin de variable mediante tcnicas simblicas. La utilizacin de estas familias de tcnicas depender del tipo de consulta que se realice.
Problemas de Satisfaccin u Optimizacin de Restricciones: Esto es necesario ya que la evaluacin de las consultas relacionadas con algunos de estos operadores se basan en la construccin y resolucin de problemas de satisfaccin de restricciones. Los problemas de satisfaccin de restricciones ayudarn a: evaluar si se cumple el predicado de la operacin de seleccin; obtener valores de las variables en la operacin de proyeccin; y conocer si dos restricciones comparten las mismas soluciones en las operaciones de unin y diferencia de conjuntos. Un ejemplo para la seleccin podra ser obtener todas las tuplas de una relacin donde las soluciones de un atributo restriccin At estn incluidas en otra restriccin C. En este caso se construir un problema de satisfaccin de restricciones con cada restriccin del atributo At y C para conocer si existe alguna solucin de At que no sea solucin de
C.
En el caso de los problemas de optimizacin de restricciones, se puede encontrar un ejemplo en la proyeccin para obtener el mayor o el menor valor que puede tomar una variable contenida en las restricciones de un atributo restriccin para una determinada relacin.
Resolucin de Problemas con Restricciones
99
Eliminacin o Sustitucin de Variables: Estas tcnicas se utilizarn en el operador de proyeccin, para obtener de manera simblica nuevas restricciones eliminando un conjunto de las variables de las restricciones almacenadas en la base de datos. Este tipo de tcnicas se basa en la sustitucin de variables, apoyndose en las Bases de Grbner, y la eliminacin de variables utilizando la Descomposicin Algebraica Cilndrica.
4.4.1. Problemas de Satisfaccin de Restricciones

Muchos problemas de ingeniera han sido modelados mediante problemas de satisfaccin de restricciones [56][111][37]. Un problema de satisfaccin de restricciones (Constraint Satisfaction Problem - CSP) es una representacin de un conjunto de variables, dominios y restricciones, ligado a uno o varios esquema de razonamiento para resolverlo. Formalmente, est denido por la tripleta <X, D, C> donde, X = {x1 , x2 , . . ., xn } es un conjunto nito de variables, D = {d(x1 ), d(x2 ), . . ., d(xn )} es el conjunto de dominios de cada una de las variables, y C = {C1 , C2 , . . ., Cm } un conjunto de restricciones. Cada restriccin Ci est denida como una relacin R de un conjunto de variables V = {xi , xj , . . ., xk } a lo que se denomina mbito de la restriccin. R puede ser representada como un subconjunto de productos cartesianos de la forma d(xi ) d(xj ) . . . d(xk ), una restriccin Ci =
(Vi , Ri ) limita los valores simultneos que pueden tomar las variables para que satisfagan
las restricciones donde estn involucradas. Sea Vk = {xk1 , xk2 , . . ., xkl } un subconjunto de
X , una l-tupla (xk1 , xk2 , . . ., xkl ) de d(xk1 ), d(xk2 ), . . ., d(xkl ) se denomina instanciacin
de variables en Vk . Una instanciacin es consistente si son satisfactibles todas sus restricciones para los valores de Vk . Una instanciacin consistente de todas las variables en
X es una solucin, por lo que el objetivo de la resolucin de un CSP consiste en encontrar

una o ms de una solucin. Aunque la resolucin o evaluacin de un CSP tambin puede ser verdadero o falso cuando slo se quiere conocer si un conjunto de valores de variables es una solucin o no del problema. Un CSP puede ser resuelto mediante diferentes tcnicas de bsqueda y consistencia, como algoritmos de vuelta atrs (backtracking) [62][15]. Sin embargo, cuando un CSP tiene un dominio continuo, no se puede garantizar que se encuentre una solucin utilizando nicamente bsqueda, ya que no es posible obtener todos los valores de las variables cuando su dominio es muy grande, pudiendo llegar a ser innito. De todas formas, los CSP con dominios innitos pueden ser resueltos aplicando relajacin de consistencias antes o
100
durante la bsqueda, de manera que se realiza eliminacin local de valores inconsistentes para las variables del dominio [14][102]. En teora, si un CSP tiene una nica solucin, aplicando un determinado grado de consistencia se puede reducir el dominio de las variables a un solo valor; si un CSP tiene ms de una solucin, o incluso innitas, todos los valores que permanezcan en el dominio despus de aplicar la consistencia sern parte de la solucin. En la prctica, una resolucin eciente de un CSP consiste en aplicar varios niveles de consistencia como la arco consistencia [103][112][113] a cada nodo del rbol de bsqueda. Normalmente la resolucin de problemas de satisfaccin de restricciones se realiza utilizando combinaciones de bsqueda y tcnicas de consistencia. Esta bsqueda tambin se ha analizado con tcnicas de bsqueda local, con el objetivo de utilizar tcnicas ms ecientes [122][121][29]. La bsqueda exhaustiva no siempre trabaja bien con problemas complejos, ni siquiera incluyendo tcnicas de ramicacin y acotacin o vuelta atrs ms inteligentes. Para los problemas de gran tamao, en algunas ocasiones es ms eciente usar bsqueda local donde no se analizan todas las soluciones, pero se pueden encontrar algunas en un tiempo menor.
4.4.2. Problemas de Optimizacin con Restricciones

Un problema de optimizacin con restricciones (Constraint Optimization Problem COP) es un problema de satisfaccin de restricciones denido por <X, D, C> junto a una funcin objetivo f que debe ser optimizada:
f: {d(x1 ) d(x2 ) . . . d(xn )} St donde (St , ) denen el orden total.

Para un problema de optimizacin de restricciones que pretende maximizar un objetivo, A es una solucin para el COP si y slo si A es una solucin del CSP y no existe un
A para el cual f(A ) > f(A). De esta forma slo las soluciones del CSP que maximicen o
minimicen el objetivo, sern consideradas soluciones del COP [38][76].
4.4.3. Bases de Grbner

Las Bases de Grbner se basan en la sustitucin simblica de variables para restricciones polinmicas de igualdad. La teora de las bases de Grbner, desarrollada por Buchberger [23], fue el origen de muchos de los algoritmos de sustitucin simblica para
Resolucin de Problemas con Restricciones
101
mltiples variables en polinomios de igualdad. Dicha teora se plantea como una generalizacin del mtodo de eliminacin de Gauss para mltiples variables en ecuaciones lineales, y el algoritmo de Euclides para ecuaciones polinmicas de una variable. Mediante las bases de Grbner se transforma un conjunto de restricciones polinmicas en otro conjunto equivalente que tiene las mismas soluciones que el original, pero eliminado unas determinadas variables. Partiendo de un conjunto de polinomios de igualdad de la forma P = 0, y las variables que se desean eliminar, se obtiene un sistema equivalente
(G = 0) pero sin dichas variables.

Un ejemplo de obtencin de las bases de Grbner puede ser: siendo el conjunto de polinomios {a + b = c, d + e = f , c f = g }, eliminar las variables {c, f }. En esta caso se obtendr la nueva restriccin: {f = (a + b) (d + e)} Poder obtener nuevas restricciones depender de las variables que se pretenden eliminar, ya que no todas las posibilidades son matemticamente viables. Slo ser posible eliminar variables que pueden ser sustituidas por otras que s forman parte de la solucin. Por ejemplo, para el sistema de ecuaciones anterior no podra ser eliminada la variable a. El algoritmo de Buchberger fue el primero para la obtencin de las Bases de Grbner Bases, aunque a ste lo siguieron algunas mejoras [49][48]. En general, la complejidad de los algoritmos para la obtencin de las Bases de Grbner es alta, exponencial en funcin del nmero de variables involucradas en el peor de los casos.
4.4.4. Descomposicin Algebraica Cilndrica

En el caso de restricciones representadas mediante inecuaciones polinmicas, la eliminacin de variables se basa en la Descomposicin Algebraica Cilndrica. Al igual que las bases de Grbner, la Descomposicin Algebraica Cilndrica es una tcnica simblica de eliminacin de variables, pero en este caso permite trabajar con inecuaciones polinmicas dentro del dominio de los reales. sta es una tcnica clsicamente usada en el estudio de problemas de propiedades topolgicas y algebraicas, aunque es posible encontrar ms detalles sobre otras utilidades de esta tcnica [5][6]. En esta tesis, la aportacin de la Descomposicin Algebraica Cilndrica radica en la eliminacin de las variables no pertenecientes
102
a una sentencia con el operador de proyeccin cuando la sustitucin simblica no es suciente. La Descomposicin Algebraica Cilndrica de I Rk es una secuencia S1 . . . Sk donde, para cada 1 i k, Si es una particin nita de I Ri en subconjuntos semi-algebraicos, llamados
celdas de nivel i. La Descomposicin Algebraica Cilndrica devolver inecuaciones cuyos

bordes implican a funciones algebraicas [22][126]. Un ejemplo es el mostrado en la gura 4.5, que muestra las restricciones:
(x2 + y 2 < 1) y ((x + 1)2 + y 2 < 1).

La primera restriccin representa una circunferencia centrada en (0, 0) de radio 1, y la segunda otra circunferencia tambin de radio 1 pero centrada en 1.
y
-1 -1/2 0
Figura 4.5: Ejemplo de Descomposicin Algebraica Cilndrica Al realizar la Descomposicin Algebraica Cilndrica sobre la variable x, se crearn las celdas mostradas con las lneas discontinuas marcadas es dicha gura. Dichas divisiones se generan segn los valores de x donde ambas restricciones se cortan entre si, lo que signicar que son los puntos donde hay que analizar su comportamiento conjunto. En este caso se obtendr la restriccin: 1 < x < 1/2 1 x2 < y < 1 x2
1/2 < x < 0 2 x2 < y < 2x x2

La cual describe el rea que forma la interseccin entre ellas. La eliminacin de la variable y signicar obtener slo la parte de la restriccin que contiene a x, obteniendo nalmente:
Operador Seleccin para BDdR
103
1 < x < 0
El mayor problema de la Descomposicin Algebraica Cilndrica es la complejidad, ya que el algoritmo para realizarla es doblemente exponencial en funcin del nmero de celdas. Algunos trabajos han analizado dicha complejidad para mejorar los tiempos de eliminacin de cuanticadores [35][144]. Junto a la limitacin ya comentada sobre que no se puede asegurar la eliminacin de variables para restricciones con variables del dominio de los enteros o los naturales.
4.5.
Como se ha expuesto anteriormente, el operador seleccin obtiene un subconjunto horizontal de las tuplas de la relacin de entrada en funcin de las condiciones que se denen en un predicado. En el predicado para la seleccin sobre las BDdR pueden aparecer los tres tipos de atributos:
Atributo Clsico o Univaluado (at): Para atributos de tipo clsico o univaluados

no es necesario redenir el operador de seleccin, ni a nivel sintctico ni semntico, ya que describir la misma semntica operacional que en el lgebra relacional clsica.
Atributo Restriccin (atc i ): Este tipo de atributo representa una columna de la

relacin que es de tipo restriccin, lo que signica que el tipo de los atributos del predicado sern del tipo atributo restriccin. En este caso es necesario redenir las operaciones de comparacin <, , >, , =, <> para restricciones numricas. Este anlisis se presenta en la subseccin 4.5.1 de este captulo, junto a la ampliacin del predicado con nuevas operaciones de comparacin entre restricciones.
Atributo Variable de Restriccin (atc i .vj ): Este tipo de atributo representa a

una variable de un atributo restriccin, lo que necesita ser estudiado. Los predicados con este tipo de atributo involucrado se analizarn con detalle en la subseccin 4.5.2
4.5.1. Operador de Seleccin para Atributos de tipo Restriccin

En esta subseccin se analiza el operador de seleccin cuando en el predicado hay involucrados atributos de tipo restriccin de una determinada relacin. Para esto es necesario conocer qu tipos de condiciones se pueden establecer sobre el tipo restriccin. La
104
comparacin entre atributos restriccin que se proponen hacen referencia a la relacin entre las soluciones que pueden tomar las dos restricciones involucradas en la comparacin. Entre los operadores, se denirn los analizados en el captulo 2 de [107] con respecto a que las soluciones que hacen satisfactible una restriccin estn incluidas en las soluciones de otra (, , , ), o que tienen al menos una solucin en comn (&). Adems se denirn, para atributos restriccin, la semntica de los operadores de comparacin ya existentes en el lgebra relacional clsica ( =(<, , >, , =, <>)). Estos operadores informarn de si todas las soluciones de una restriccin son mayores, menores, iguales o distintas de las soluciones de otra restriccin. Un ejemplo de seleccin para atributos de tipo restriccin puede ser:
R = (Cx a2 +b2 <1) (R)

donde Cx representa el nombre de un atributo restriccin de la relacin R. La relacin de salida R estar formada por el subconjunto de las tuplas de R donde todas las soluciones que hacen satisfactible las restricciones almacenadas en el atributo restriccin Cx tambin sean solucin de la restriccin {a2 + b2 < 1}. Para conocer todas las tuplas de R que cumplen la condicin, se tendrn que construir problemas de satisfaccin de restricciones con cada una de las restricciones del atributo {R.Cx } y la restriccin del predicado {a2 + b2 < 1}, con el objetivo de conocer qu tuplas formarn parte de R . Slo podrn cumplir la condicin aquellas restricciones que tengan las mismas variables que la restriccin del predicado, a y b para este ejemplo. Antes de comenzar con las operaciones de comparacin sobre restricciones, es necesario incluir una nueva operacin sobre variables, la igualdad sintctica entre variables de distintas restricciones:
Denicin de Igualdad Sintctica: Sean Cx y Cy dos restricciones donde X =

{x1 , x2 , . . ., xn } representa las variables de Cx , e Y ={y1 , y2 , . . ., ym } las variables de Cy . Si xi X , e yj Y , entonces xi S yj es cierto si ambas variables son sintcticamente iguales, o lo que es lo mismo, tienen el mismo nombre. Que dos variables pertenecientes a distintas restricciones sean sintcticamente iguales, no implica que sean la misma variable, o lo que es lo mismo, que los valores que puedan tomar sean los mismos. Esto es debido a que al pertenecer a distintas restricciones, las soluciones que hacen satisfactible una o otra restriccin no tienen porqu ser las mismas. Dependiendo de la condicin que relacione ambas restricciones, se establecer o no, est igualdad sintctica como igualdad semntica. Por ejemplo, sea una relacin con un atributo restriccin donde cada tupla
105
representa el recorrido de un vehculo, todas las restricciones estarn denidas sobre las variables x, y y t. Pese a esto, los valores de dichas variables que hacen satisfactible cada restriccin no tienen que ser los mismos, lo que signica que son sintcticamente iguales pero no semnticamente iguales. Sin embargo, si se estableciera como condicin obtener los vehculos que se encuentran en su recorrido en un punto (x, y ) para un instante de tiempo t, se estara deniendo la igualdad semntica entre dichas variables, ya que necesariamente tienen que compartir soluciones.
Denicin de las operaciones de comparacin permitidas entre restricciones:

Cx < Cy es cierto si para todas las xi S yj , el mximo valor que puede tomar xi siempre es menor que el mnimo valor que puede tomar yj , y para todas las
variables de Cx existe una sintcticamente igual en Cy y viceversa. Esta denicin es extensible a Cx > Cy . Para conocer si Cx < Cy , se construye un CSP donde todas las variables xi de Cx , que tambin pertenezcan a Cy (yj ) de forma que (xi S yj ), sern renombradas como xi construyendo una nueva restriccin Cx . Esto es necesario ya que ambas restricciones tienen que poder tomar distintos valores con respecto a las variables compartidas, y si se mantienen los mismos nombres en el CSP, nunca podr ocurrir que los valores que tome xi en Cx sean distintos a los que toma en Cy . Para conocer si todas las soluciones de Cx para las variables xi S yj son menores que las soluciones que hacen satisfactible Cy , se construye un CSP donde se buscar si existe una solucin donde esto no ocurra. Si se encuentra alguna solucin, entonces la salida de la evaluacin del predicado Cx < Cy ser falso, y cierto en caso contrario. Por lo tanto la frmula:
xi X , yj Y | xi S yj (xi < yj )
ser transformada en:
(xi X , yj Y | xi S yj xi > yj xi = yj ).
Esta trasformacin evita tener que analizar todo el espacio de bsqueda de las soluciones del CSP, slo teniendo que resolver un CSP con el objetivo de encontrar
106
un valor donde se cumple que xi yj . El CSP se construye de la forma:
X = {x1 , x2 , . . ., xn } Y = {y1 , y2 , . . ., yn } Cx Cy xi X yj Y | xi S yj aadir al CSP {(xi > yj xi = yj )}

Si existe alguna solucin para el CSP, entonces Cx < Cy devolver falso, porque signicar que no todos los valores de las variables de Cx son menores que en Cy ya que es posible encontrar un valor que cumple lo contrario. Si no existe ninguna solucin para el CSP, la comparacin Cx < Cy devolver cierto. Un ejemplo es el mostrado en la gura 4.6, donde Cx < Cy es cierto.
y Cy
Cx x
Figura 4.6: Ejemplo donde Cx < Cy
Este tipo de seleccin puede ser utilizada en las consultas sobre sistemas de informacin geogrca, por ejemplo para conocer qu parcelas estn al suroeste de otra.
Cx Cy es cierto si para todas las variables xi S yj , el mximo valor de xi siempre

es menor o igual que el menor valor que puede tomar yj . Esta denicin puede ser extendida a Cx Cy . La construccin del CSP es muy similar a la del caso anterior:
X = {x1 , x2 , . . ., xn } Y = {y1 , y2 , . . ., ym } Cx Cy xi X yj Y | xi S yj aadir al CSP {(xi > yj )}

Si existe una solucin al CSP, entonces Cx Cy devolver falso, y cierto en caso contrario.
107
Cx = Cy es cierto si todas las soluciones de Cx tambin lo son de Cy y viceversa. En

este caso no simplemente consiste en comparar ambas restricciones sintcticamente, ya que se puede representar el mismo conjunto de valores con dos restricciones morfolgicamente diferentes. En la construccin del CSP no se renombran las variables, ya que precisamente lo que se busca es conocer si todas las soluciones que hacen satisfactible a Cx tambin hacen satisfactible a Cy . En este caso, se crear el siguiente CSP:
X = {x1 , x2 , . . ., xn } Y = {y1 , y2 , . . ., yn }
(Cx Cy ) (Cy Cx )
Si existe alguna solucin para el CSP, entonces Cx =Cy devolver falso, y cierto en caso contrario. Para el operador <>, que describe si dos restricciones no son iguales, se puede utilizar esta misma forma de construir el CSP. La diferencia radica que si el existe alguna solucin devolver cierto, y falso en caso contrario. Aqu no acaba la complicacin de estos operadores de comparacin, ya que la operacin de negacin para los reales tiene una problemtica aadida. En los problemas de satisfaccin de restricciones sobre reales, el nmero de soluciones es muy grande, tericamente innita, lo que hace que la bsqueda de soluciones sea muy costosa. Esto ha generado soluciones que abordan el problema mediante aproximaciones con una determinada precision utilizando intervalos que contienen las soluciones. Esta utilizacin de intervalos provoca que una restriccin y su negacin compartan soluciones en la prctica, aunque de forma terica no tendran que compartirlas [12][64]. Para evitar esto, la creacin de CSP que se propone en esta tesis se apoya en la reescritura de la negacin de las restricciones, cuando stas estn denidas sobre reales, construyendo una nueva restriccin. Para obtener de manera prctica, no exclusivamente terica la operacin de negacin, ser necesario que dicha negacin no tome los valores derivados de la aproximacin, construyendo la negacin con la separacin de una constante . El valor de depender de la aproximacin que se haga, siendo de un orden mayor que la aproximacin que utilice el resolutor de CSP, por ejemplo si la aproximacin llega hasta reales de 104 , ser 103 . La reescritura para una restriccin de forma trmino1 trmino2 , donde puede ser uno de los operadores <, , >, o =, ser de la forma:
trmino1 < trmino2 trmino1 trmino2 +
108
trmino1 trmino2 trmino1 > trmino2 + trmino1 > trmino2 trmino1 + trmino2 trmino1 trmino2 trmino1 + < trmino2 trmino1 = trmino2 trmino1 + < trmino2 trmino1 >
trmino2
En la gura 4.7 se muestra grcamente un ejemplo donde partiendo de la restriccin
(x 5,5)2 + (y 5,5)2 4, se construye su negacin obteniendo la nueva restriccin (x 5,5)2 + (y 5,5)2 > 4 + 103 .
Cx Cx
Cx
Cx
103
Figura 4.7: Ejemplo de reescritura de la negacin Slo cabe aclarar que si las restricciones estn denidas sobre el dominio de los enteros o los naturales, no ser necesario incluir el factor de aproximacin en la negacin de las mismas.
Cx & Cy ser cierto si existe alguna solucin que haga satisfactible ambas restricciones, siendo todas las variables sintcticamente iguales entre ambas. En este caso el CSP ser de la forma:
X = { x1 , x2 , . . . , xn } Cx Cy
Si se encuentra una solucin para este CSP, la operacin Cx & Cy devolver cierto, y falso si no encuentra solucin.
Cx < (Cy FOR {yd , . . ., yh }) es una variante para la operacin < que devolver
cierto si para todas las variables xi S yj tal que yj {yd , . . ., yh } el mximo valor
de xi es menor que el mnimo valor de yj . Esta operacin realiza una proyeccin
109
sobre las variables que aparecen en el predicado {yd , . . ., yh }, lo que conlleva que las variables de Cx que no pertenecen a {yd , . . ., yh } no son relevantes en esta operacin. En este caso, las restricciones Cx y Cy no tienen que tener todas las variables sintcticamente iguales entre ellas, y slo se incluirn comparaciones entre aquellas variables que aparezcan en la condicin. El CSP que se construye es de la forma:
X = { x1 , x2 , . . . , xn } Y = {y1 , y2 , . . ., ym } Cx Cy xi X yj {yd , . . . , yh } | xi S yj aadir al CSP {(xi > yj xi = yj )}
y z Cy Cx
y
Cy Cx
C x < (C y FOR{ y})

(a)
x
(b)
C x < (C y FOR{ y} AND C x .x = C y .x)
Figura 4.8: Ejemplo de proyeccin sobre variables Si existe alguna solucin para el CSP, la comparacin devolver falso, y cierto en caso contrario. Un ejemplo para esto es el que se muestra en la gura 4.8.a donde la proyeccin se hace sobre la variable y , y el predicado es Cx <(Cy FOR {y }). Dicho predicado pregunta si todos los valores de la variable y en Cx son menores que en
Cy , independientemente de los valores de las variables {x, z }. Sin embargo, para el

predicado Cx <(Cy FOR {x}) el mismo ejemplo devolvera falso. Esta denicin es extensible a las operaciones , >, y &. Este tipo seleccin puede ser utilizada en las consultas sobre sistemas de informacin geogrca, por ejemplo para conocer si una nube est encima de una regin.
110
Otra variante de este tipo de comparacin es la que se basa en conocer si las soluciones de una restriccin son menores que otra para un valor establecido de una variable o varias variables. En la gura 4.8.b se muestra un ejemplo, donde para los valores de x donde
Cx y Cy son satisfatibles, siempre el valor de y que hace satisfactible Cx es menor que el

valor de y que hace satisfactible Cy . La condicin para este ejemplo es:
Cx < (Cy FOR {y} AND Cx .x=Cy .x)

De forma que la sintaxis genrica para establecer igualdad semntica ser:
Cx < (Cy FOR {yd ,. . .,yh } AND Cx .v1 =Cy .v1 AND . . . AND Cx .vi =Cy .vi
AND . . . AND Cx .vk =Cy .vk ), donde vi / {yd ,. . .,yh }

Lo que signicar que se construir y resolver un CSP de la forma:
X = { x1 , x2 , . . . , xn } Y = {y1 , y2 , . . ., ym } Cx Cy x i X y j { y d , . . . , y h } | x i S y j aadir al CSP {(xi > yj xi = yj )} v {v1 , . . . , vk } | v S xi v S yj aadir al CSP {xi = yj } Cx Cy ser cierto si todas las soluciones de Cx lo son tambin de Cy . Para la
inclusin, es necesario que las restricciones estn denidas sobre las mismas variables, de forma que sean Cx y Cy dos restricciones donde X = {x1 , x2 , . . ., xn } son las variables de Cx y Cy , Cx Cy es igual que la implicacin (Cx Cy ) [107]. Esta operacin determina si todas las soluciones de Cx son tambin soluciones de Cy , aunque es posible que Cy tenga soluciones que no pertenezcan a Cx . Para evitar analizar todas las soluciones de Cx , comprobando que stas tambin lo son de Cy , se buscar una solucin donde esto no ocurra, de forma que la evaluacin de la condicin Cx Cy corresponde con la frmula:
(xi X (Cx Cy ))
Y el CSP que se crear es:
111
X = { x1 , x2 , . . . , xn } C x C y
Si se encuentra alguna solucin para el CSP devolver falso, y cierto si no encuentra ninguna. En este caso tambin es necesario la misma reescritura de la negacin de restricciones que se ha explicado para la operacin '='. En la gura 4.9 hay un ejemplo donde la restriccin Cx est incluida en la restriccin Cy . Esta denicin puede ser extendida a Cx Cy .
v2 Cx Cy
v1
Figura 4.9: Ejemplo de Cx Cy
Cx Cy devolver cierto si todas las soluciones de Cx tambin son de Cy , y adems

obligatoriamente Cy tiene al menos una solucin que no pertenecen a Cx . Como el operador anterior, ambas restricciones tienen que estar denidas sobre las mismas variables. En este caso, se construye un CSP como el anterior para saber que Cx Cy , y otro para saber que existe una solucin para Cy que no pertenece a Cx :
X = { x1 , x2 , . . . , xn } Cy Cx
Si existe alguna solucin para el CSP, entonces Cx Cy devolver cierto y falso en otro caso. Esta denicin es extensible a Cx Cy .
4.5.2. Operador de Seleccin para Atributos de tipo Variable de Restriccin

Los atributos variable de restriccin tambin pueden participar en el predicado de una seleccin. El atributo atc i .vj se podr comparar con una constante u otro atributo que pertenezca al mismo dominio que la variable vj , lo que implica dos tipos de comparacin:
112
Sea xi una variable perteneciente a las variables X = {x1 , x2 , . . . , xn } de un atributo restriccin Cx y {Cx .xi c} una parte del predicado de la seleccin, donde c es un valor del dominio de xi , y = {<, >, , , =}. Se cumplir la condicin para aquellas restricciones donde la variable xi puede tomar valores relativos a c en funcin de . Para realizar dicha seleccin, se proponen dos alternativas que se analizarn ms en profundidad en el siguiente captulo. Una posibilidad es crear un CSP, o ampliar el que se construya con el resto del predicado, incluyendo la restriccin {xi c}. Si el CSP encuentra alguna solucin, signicar que la variable puede tomar algn valor relativo a c que cumpla la condicin. La otra opcin es almacenar en la base de datos los valores mximos y mnimos para cada variable en cada restriccin, de manera que en la seleccin primero se comprobar si el valor
c puede cumplir la condicin, en funcin del mximo y el mnimo de la variable Cx .xi y lo establecido por . Si esto es posible, se construir un CSP para asegurar
que realmente existe un valor que cumple la condicin. Si no est dentro de dichos lmites, se podr asegurar que la restriccin Cx no cumple la condicin del predicado. Sea xi una variable que pertenece a las variables X = {x1 , x2 , . . . , xn } de la restriccin Cx , y {Cx .xi Cy .yj } perteneciente al predicado de la seleccin, donde yj es una variable del atributo restriccin Cy . La variable yj puede ser sintcticamente igual o diferente a Cx .xi , aunque obligatoriamente del mismo dominio, y = {<,
>, , , =}. Se seleccionarn aquellas tuplas donde la variable xi de Cx puede

tomar los valores relacionados con la variable yj de Cy en funcin de . Una vez seleccionadas la tuplas con restricciones cuyas variables son las que aparecen en el predicado, ser necesario crear o modicar el CSP que se construye para la seleccin, por ejemplo con la restriccin {Cx .xi Cy .yj }. Si el CSP encuentra una solucin, signicar que las variables xi e yj pueden tomas los valores cuya relacin viene determinada por . Un ejemplo de seleccin con variables de restriccin en el predicado puede ser
Relacin.c>Relacin.d (R), donde R es la relacin de la gura 4.10. Como salida de la

seleccin slo se obtendr la primera tupla {x = 5 y = 2 a + b > c d + a < 8} de la relacin. Esto es debido a que en la segunda y en la cuarta tupla no aparece
d, por lo que no se puede denir la relacin entre variables, y en la tercera aparece d > c c + 1, que nunca cumplir la condicin.
Operador Proyeccin para BDdR
113
Relacin
a+b > cd +a <8 a + b 1 > c e + a < 3 d > c *c +1 d + a < 7
Re lacin.c>Re lacin.d
5 2 5 3 7 3 9 8
Relacin
5 2
a+b > cd +a < 8
a+b+c = 5
Figura 4.10: Ejemplo de seleccin con condicin de atributos variable de restriccin
4.6.
El operador de proyeccin realiza una seleccin vertical de una relacin, devolviendo un subconjunto de los atributos que la conforman. Como en la nueva denicin de las BDdR existen tres tipos de atributos, existirn tres tipos de seleccin vertical o proyeccin: Para atributos univaluados o clsicos (at) no es necesario redenir el operador de proyeccin, ni a nivel sintctico ni semntico, ya que es el descrito para en el lgebra relacional clsica. Para atributos restriccin (atc i ), pese a que a su vez representan una columna que es una relacin, no conllevar mayor problema ya que ser obtener las restricciones tal como estn almacenadas. El nico proceso que se tendra que realizar sera comprobar que no existen tuplas duplicadas, como se explicar en la seccin 4.7 para la unin de conjuntos que tiene la misma problemtica. Los atributos variable de restriccin (atc i .vj ), hacen referencia a una columna de una columna de la relacin, se analizar en la subseccin 4.6.1, ya que la evaluacin de este atributo para el operador de proyeccin necesita profundizar en diferentes aspectos.
4.6.1. Operador de Proyeccin para Atributos Variables de Restriccin

Cuando se quieren obtener las variables de un atributo restriccin de una relacin, es posible obtener dos tipos de informacin. Una de las posibilidades es obtener los valores extensivos (o numricos) de las variables (como se muestra en la gura 4.4), y la otra
114
es obtener una representacin intensiva (o simblica), mediante restricciones que describa todos los valores que pueden tomar las variables involucradas en la proyeccin. La sentencia para la proyeccin sobre variables de restriccin ser de la forma:
c (atc (R) i .vj ,...,atk .vl )
Y la evaluacin de dicha operacin puede obtener informacin intensiva o extensiva:
Informacin Intensiva: En este caso, se obtendrn nuevas restricciones que desc criben el conjunto de valores que pueden tomar las variables (atc i .vj , . . . , atk .vl ).
La forma de la sentencia ser:

c CON ST RAIN T S (atc (R) i .vj ,...,atk .vl )
donde la palabra CONSTRAINTS se utiliza para denotar que se quiere obtener una
c representacin simblica de los valores de las variables (atc i .vj , . . . , atk .vl ).
Estas restricciones, equivalentes a los valores extensivos de las variables, se pueden obtener utilizando diferentes tcnicas, sustitucin simblica de variables, o eliminacin de cuanticadores:
Sustitucin simblica de variables: Esta tcnica se puede utilizar para

restricciones denidas sobre cualquier dominio de variables, ya que consisten en eliminar un conjunto de variables sustituyndolas en funcin de otras pero sin perder informacin. La limitacin de la sustitucin simblica viene dada porque slo est denida para restricciones de igualdad, tanto lineales como polinmicas, ya que hace uso de la teora de las Bases de Grbner presentada en la seccin 4.4.3.
Eliminacin simblica de cuanticadores: Existen casos de consultas sobre BDdR donde para obtener un subconjunto de variables de forma intensiva no es suciente con la sustitucin simblica, bien por el tipo de las restricciones involucradas, o porque no existan sucientes variables para sustituir las no deseadas. En estos casos, ser necesario recurrir a la eliminacin de cuanticadores. La eliminacin de los cuanticadores ( y ) [101][152] se basa en la Descomposicin Algebraica Cilndrica [110] orientada a la proyeccin sobre aquellas variables que formarn parte de la solucin, tal como se presenta en
115
la seccin 4.4.4. Desafortunadamente, el peor caso de complejidad para la eliminacin de cuanticadores reales es doblemente exponencial en funcin del nmero de bloques de cuanticadores [153][39][27]. Los tipos de restricciones con los que se trabaja en esta tesis, sobre las cuales se puede asegurar que se obtendr una solucin a la eliminacin de cuanticadores se presentan en la tabla 4.1. En dicha tabla se puede observar que slo para las soluciones sobre el dominio de los reales es posible asegurar dicha eliminacin, por lo que es posible que la proyeccin devuelva una relacin vaca, para mantener la propiedad de cierre, cuando dicha eliminacin no sea posible.
Restriccin Dominio Tiene eliminacin de cuanticadores
Lineal Lineal Lineal Polinmica Polinmica Polinmica
Real Natural Entero Real Natural Entero
S No No S No No
Tabla 4.1: Eliminacin de Cuanticadores en funcin del tipo de restriccin y dominio
Informacin Extensiva: Cuando se realiza la proyeccin sobre las variables, tambin se ofrecer la posibilidad de obtener los valores extensivos de las variables, no su representacin simblica. Este caso tambin es de proyeccin en funcin de las variables, pero no ser necesario eliminar cuanticadores, ya que la salida ser extensiva. Para obtener dichos valores se construir un CSP con todas las restricciones y variables involucradas, aunque slo se mostrar como evaluacin de la proyeccin aquellas variables denidas en la sentencia del operador de proyeccin. La forma de la sentencia ser:
c V ALU ES [N ](atc (R) i .vj ,...,atk .vl )
donde de utiliza la palabra reservada VALUES para describir que se quieren obtener valores instaciados de las variables, y N representa el nmero de tuplas que se quieren obtener, ya que puede ser que las posibilidades sean innitas. Si no se establece en valor de N , por defecto se presentar una sola tupla.
116
Siendo C1 , . . ., Cn las restricciones de la relacin R involucradas en la proyeccin, el CSP que se crear para obtener el valor de las variables ser de la forma:
aadir al CSP {X1 = {x1,1 , x1,2 , . . ., x1,m C1 }}

...
aadir al CSP {Xn = {xn,1 , xn,2 , . . ., xn,m Cn }}

C1 . . . Cn
Cuando un problema de satisfaccin de restricciones no slo pretende encontrar una solucin, sino que quiere encontrar la mejor solucin en funcin de un objetivo denido, se utilizar un problema de optimizacin de restricciones. Esto tiene relacin con la bases de datos clsicas, ya que en las bases de datos relacionales, no slo es posible obtener todas los valores de un conjunto de atributos, tambin es posible extender el lgebra aadiendo agregados como COU N T , SU M , AV G,
M AX y M IN que permite realizar a su vez operaciones con dichos atributos. Para

el caso de las variables de restricciones, en esta tesis se amplan la utilizacin de las operaciones M AX y M IN . Estas operaciones en las bases de datos relacionales se pueden realizar sobre atributos numricos, por lo que tambin se podrn utilizar para variables de restricciones que son tambin atributos numricos, pudiendo obtener sus mximos y mnimos valores. Para obtener la evaluacin de la proyeccin ser necesario crear un COP con las restricciones relacionadas con la variable a maximizar o minimizar. Sean C1 , C2 , . . ., Cn las restricciones de la relacin involucradas en la proyeccin, sea Xi las variables de Ci , y x la variable a minimizar o maximizar, entonces el COP se construye de la forma:
X1 = {x1,1 , x1,2 , . . ., x1,m C1 } ... Xn = {xn,1 , xn,2 , . . ., xn,m Cn }
Maximizar(x) Minimizar(x)
C1 C2 . . . Cn //para las Ci donde x Xi
La gura 4.11 resume lo presentado en esta seccin, donde se muestra la divisin del tipo de proyeccin en funcin de la salida que se quiere obtener (intensiva o extensiva). En el caso de la extensiva o numrica, se construirn problemas de satisfaccin u optimizacin de restricciones para obtener valores concretos de las variables. En el caso de la salida intensiva, representado mediante restricciones, se eliminarn las variables no deseadas.
Operador de Unin de Conjuntos para BDdR
117
Si dichas variables pueden ser sustituidas por otras y las restricciones son polinmicas o lineales de igualdad, se recurrir a la obtencin de las Bases de Grbner. Si esto no es posible, se necesitar eliminar cuanticadores utilizando la Descomposicin Algebraica Cilndrica, cuya salida slo se puede asegurar para restricciones denidas sobre el dominio de los reales. En el caso de la proyeccin extensiva, se obtendrn tuplas con los valores concretos que pueden tomar las variables, como atributos univaluados. En el caso de la obtencin extensiva no existen limitaciones con respecto al tipo de restriccin o dominio de sus variables.
Proyeccin Extensiva (numrica) CSP COP Sustitucin Simblica Bases de Groebner
(Independiente del Dominio de las Variables, pero slo para ecuaciones lineales o polinmicas)
Intensiva (simblica) Eliminacin de Cuantificadores Descomposicin Algebraica Cilndrica

(Slo variables en el dominio de los Reales, pero independiente del tipo de restricciones (lineales, polinmicas, inecuaciones o ecuaciones))
(Independiente del (Independiente del Dominio de las Dominio de las Variables y el tipo de Variables y el tipo de restricciones (lineales, restricciones polinmicas, (lineales, inecuaciones o polinmicas, ecuaciones) ) inecuaciones o ecuaciones) )
Figura 4.11: Tipos de Proyeccin en funcin de la salida
4.7.
Operador de Unin de Conjuntos para BDdR
Otra de las operaciones primitivas del lgebra relacional es la unin de conjuntos (R1 R2 ), la cual obtiene para dos relaciones de entrada, la unin vertical de las tuplas de ambas sin repeticin. La problemtica de este operador radica en que una tupla es una restriccin denida como una combinacin conjuntiva de atributos univaluados y atributos restriccin. En funcin de las soluciones que compartan dichas tuplas, se obtendrn distintas relaciones de salida. Analizando la unin entre dos restricciones denidas sobre las mismas variables, se pueden encontrar los cuatro casos, como se muestra en la gura 4.12, donde Cx y Cy representan las restricciones:
118
Si Cx
Cy y Cy
Cx , entonces la unin de ambas restricciones ser una nueva
restriccin {Cx Cy }. Esto es lo que se muestra en las guras 4.12.a y 4.12.b. Si se cumple que Cx Cy o su equivalente Cy Cx , entonces la unin de ambas restricciones ser {Cy } o {Cx } respectivamente. Esto es lo que se muestra en las guras 4.12.c y 4.12.d.
Cx Cy Cx Cy Cx Cy Cx Cy
a. Sin soluciones en comn Cy Cx c. Cx incluida en Cy Cy
b. Algunas soluciones en comn Cx Cx
Cy
d. Cy incluida en Cx
Figura 4.12: Tipos de Unin entre restricciones
Para obtener la relacin de salida para la operacin de unin, hay que tener en cuenta que las relaciones pueden estar formadas por varios atributos clsicos y restriccin. De esta forma, se compara cada tupla t1 R1 , con cada tupla t2 R2 , analizando si dichas tuplas son iguales o comparten soluciones. Sean las tuplas t1 y t2 , donde xi representa atributos univaluados, consti los valores de los atributos univaluados, y Ci atributos restriccin:
t1 {x1 = const1 . . . xn = constn C1 . . . Cm } t2 {x1 = const1 . . . xn = constn C1 . . . Cm }

Si xi | consti = consti t1 t2 t1 t2 En otro caso: Si Ci | Ci
Ci Ci | Ci
Ci
t1 t2 t1 t2 (Figuras 4.12.a y 4.12.b)

En otro caso: (Ci ,Ci (Ci Ci Ci Ci ))
t1 t2 {x1 = const1 . . . xn = constn C1 . . . Cm } | si Ci Ci Ci Ci (Figura 4.12.d)

en otro caso (Ci Ci ) Ci Ci (Figura 4.12.c)
Operador Diferencia de Conjuntos para BDdR
119
4.8.
Operador Diferencia de Conjuntos para BDdR
Por ltimo, queda por analizar la diferencia de conjuntos (R1 R2 ), la cual obtiene para dos relaciones de entrada las tuplas de R1 que no pertenecen a R2 . La problemtica de este operador tambin radica en que una tupla es una restriccin denida como una combinacin conjuntiva de atributos univaluados y atributos restriccin. En funcin de las soluciones que compartan dichas tuplas, se obtendrn distintas relaciones de salida. Analizando la diferencia entre dos restricciones, se pueden diferenciar cuatro casos, presentados en la gura 4.13, donde Cx y Cy representan restricciones: Si Cx y Cy no tienen ninguna solucin en comn, entonces la diferencia de las restricciones ser Cx , como se presenta en la gura 4.13.a. Si se cumple que Cx y Cy tienen alguna solucin en comn pero Cx tiene soluciones que no pertenecen a Cy , entonces la diferencia de las restricciones ser {Cx Cy }. Estos casos son los presentados en las guras 4.13.b y 4.13.c. Si se cumple que Cx Cy , entonces la diferencia entre las restricciones ser la restriccin vaca, como se muestra en la gura 4.13.d.
Cx Cy Cx Cx Cy Cx Cy
a. Sin soluciones en comn Cx Cy Cx Cy
b. Algunas soluciones en comn Cy Cx
c. Cy incluida en Cx
d. Cx incluida en Cy
Figura 4.13: Tipos de Diferencias entre restricciones
La negacin de las restricciones tambin conllevar la reescritura de las mismas en los trminos explicados en la seccin 4.5.1. Para obtener la relacin de salida para la operacin de diferencia, hay que tener en cuenta que las relaciones pueden estar formadas por varios atributos clsicos y restriccin. De esta forma, se compara cada tupla t1 R1 , con cada tupla t2 R2 , analizando si dichas tuplas son iguales o comparten soluciones. Sean las tuplas t1 y t2 , donde xi
120
representa atributos univaluados, consti los valores de los atributos univaluados, y Ci atributos restriccin:
t1 {x1 = const1 . . . xn = constn C1 . . . Cm } t2 {x1 = const1 . . . xn = constn C1 . . . Cm }

Si xi | consti = consti
t1 t2 t1
En otro caso: Si Ci | Ci Ci
t1 t2 {x1 = const1 . . . xn = constn C1 . . . Cm } | si una solucin de Ci | Ci Ci Ci Ci Ci (Figuras 4.13.b y 4.13.c)

En otro caso: Ci Ci (Figura 4.13.a) En otro caso (Ci Ci Ci ):
t1 t2 //(Figura 4.13.d) t1 no pertenece a la relacin de salida
4.9. Resumen
En este captulo se reformula la denicin de Bases de Datos de Restricciones para diferenciar los atributos clsicos o univaluados y los atributos restriccin. Esta divisin genera tres diferentes tipos de atributos: atributo clsico, atributo restriccin y atributo variable de restriccin. Esto hace necesario que las operaciones primitivas del lgebra relacional, tengan que ampliar tanto su sintaxis como su semntica. Las operaciones que se revisan en este captulo son:
La seleccin, ya que la condicin del predicado puede incluir restricciones y variables de restricciones.
La proyeccin, ya que se podr realizar proyeccin sobre las variables de los atributos restriccin, tanto de forma extensiva como intensiva.
La unin y diferencia de conjuntos, siendo necesario analizar las relaciones

entre las tuplas formadas por atributos clsicos y atributos restriccin.
Resumen
121
Estas operaciones se pueden redenir gracias a dos familias de tcnicas: por una parte, la construccin y resolucin de problemas de satisfaccin y optimizacin de restricciones para el tratamiento numrico de las restricciones; y por otra, la sustitucin de variables y eliminacin de cuanticadores para el tratamiento simblico de la informacin. En la tabla 4.2 se presenta un resumen del tratamiento de los distintos tipos de atributos en funcin de las distintas operaciones. En dicha tabla se reeja cundo se utiliza el lgebra relacional clsica (AR), cundo es necesario crear y resolver un CSP o un COP, o en qu circunstancias hay que tratar de forma simblica las restricciones.
ati atc i atc i .vj
Igual que AR Igual que AR Igual que AR Igual que AR Igual que AR
Creacin de CSP Igual que AR Igual que AR Creacin de CSP Creacin de CSP Creacin de CSP
Creacin de CSP Creacin de COP Tratamiento Simblico
No aplicable a esta Operacin No aplicable a esta Operacin No aplicable a esta Operacin
Tabla 4.2: Resumen de las Operaciones y Tcnicas para evaluar consultas
Captulo 5 Arquitectura LORCDB. Un Gestor para BDdR

En base al nuevo concepto de Base de Datos de Restricciones introducido en el captulo anterior, en este captulo se especica una arquitectura que permite dar soporte a las caractersticas descritas. La utilizacin de las BDdR ha ampliado sin duda la capacidad expresiva de los gestores de bases de datos, pero a su vez tambin complica el tratamiento de la informacin, ya que su representacin es intensiva y se necesitan tcnicas de inferencia diferentes a las propias de las bases de datos extensivas. Esto hace necesario desarrollar una arquitectura que facilite dicho procesamiento, obteniendo un gestor de base de datos con capacidad expresiva pero con mtodos de evaluacin de consultas computacionalmente ecientes. Para el tratamiento de datos de tipo restriccin ser necesario denir un nuevo lenguaje de consulta, que se presenta como una ampliacin de la gramtica de SQL. El nuevo lenguaje mantendr toda la funcionalidad del estndar, junto a la posibilidad de realizar las mismas operaciones para datos de tipo restriccin y variable de restriccin.
5.1.
Introduccin
La utilizacin de restricciones permite una mayor expresividad, pero tambin implica procesos ms complejos para su tratamiento. Por esta razn, en esta memoria de tesis se propone una arquitectura que permita que los datos en forma de restriccin sean fcilmente almacenables, y por supuesto se puedan recuperar de una manera lo ms eciente posible.
124
Captulo 5. Arquitectura LORCDB. Un Gestor para BDdR
Como tambin se ha presentado en esta tesis, las restricciones se almacenarn como un tipo nuevo (atributo restriccin), de manera que el lgebra relacional es extendida para dichas restricciones y las variables que las componen. Aunque existen trabajos [30] donde se analizan las variables que forman las restricciones, no abordan el problema de las variables como un atributo nuevo que puede participar en las operaciones de seleccin y proyeccin, siendo necesario enriquecer el lenguaje de consulta para este nuevo tipo de atributo. Pese a ampliar el modelo relacional con las restricciones, la propuesta aqu presentada mantiene las reglas relacionales descritas por Codd [33]. La idea principal es mantener todas las ventajas del lgebra relacional junto a la expresividad que permiten las restricciones. La combinacin de ambas reas es benecioso tanto para las bases de datos como para las construccin y resolucin de problemas de satisfaccin de restricciones, ya que las ventajas de una representan las deciencias de otra. En la tabla 5.1 se muestran las ventajas e inconvenientes de cada uno de los paradigmas utilizados, la combinacin de ambos dar como resultado una nueva arquitectura para gestores de Bases de Datos de Restricciones.
Ventajas
Desventajas
Representacin extensiva Almacenamiento nito Consultas por extraccin
BD Relacionales Denicin asentada desde 1970

Gran capacidad el almacenamiento Optimizacin de Consultas Estndar aceptado por la comunidad Solucin Genrica
Restricciones
Gran expresividad Datos innitos en espacio nito Inferencia de nueva informacin Representacin Intensiva Tcnicas de Inferencia
Conocimiento experto Falta de estndar Soluciones a medida Complejidad de resolucin
Tabla 5.1: Ventajas e Inconvenientes de Restricciones y BD Relacionales La teora de bases de datos relacionales es aceptada tanto por la comunidad de investigadores como por las empresas que desarrollan soluciones comerciales genricas e independientes de las aplicaciones que las utilizan, siendo la mejor solucin para el almacenamiento de gran cantidad de datos siempre que stos puedan ser representados de
Las Bases de Datos Objeto-Relacionales y las Restricciones
125
forma nita. Para los datos clsicos se han desarrollado diferentes algoritmos, minimizando los tiempos de acceso a los registros. Por otro lado, la programacin con restricciones tiene gran capacidad expresiva, pero entre sus inconvenientes se encuentran que no existen soluciones generales que permitan crear problemas de satisfaccin u optimizacin de restricciones de forma automtica, lo que signica que cada modelo para resolver un problema tendr que ser construido a medida de las necesidades. Sin embargo, la construccin y resolucin de problemas de satisfaccin de restricciones necesita de conocimientos ms expertos y complejos, no existiendo un lenguaje estndar. Si ambos paradigmas se combinaran, se obtendra un sistema con gran capacidad de almacenamiento y gran capacidad expresiva, donde los modelos se puedan construir partiendo de la informacin almacenada de una manera fcil mediante un lenguaje sencillo y conocido como es SQL. Para el tratamiento de la informacin almacenable de forma nita se utilizarn las mejoras relacionadas con el lgebra relacional, mientras que el tratamiento de restricciones se har utilizando tcnicas y algoritmos de la programacin con restricciones y eliminacin simblica. El siguiente paso es denir una forma de almacenar las restricciones en una base de datos relacional, por lo que se propone utilizar Bases de Datos Objeto-Relacionales. Como se muestra en el captulo 2, las Bases de Datos Objeto-Relacionales permiten almacenar objetos manteniendo las caractersticas del lgebra relacional, por lo que ser la alternativa de soporte lgico utilizada en esta tesis.
5.2.
Las restricciones que se tratarn son las expresadas en la gramtica mostrada en la seccin 4.2, por lo que presentan una estructura compleja que no se puede almacenar en una base de datos relacional clsica. Por dicha razn, se utilizan las Bases de Datos ObjetoRelacionales para dar soporte a las restricciones numricas. De esta forma, las restricciones se describen en base a objetos como rboles sintcticos, donde los nodos internos son los operadores booleanos, operadores de comparacin y operadores numricos, mientras que las hojas sern las variables y las constantes que forman cada restriccin. De todas formas, en las siguientes secciones se presenta ms extensamente cmo son estos objetos, y cmo se harn persistentes en la base de datos. Sobre dichos objetos se construir un conjunto de mtodos para su obtencin, tratamiento y modicacin, produciendo una ampliacin
126
del gestor de bases de datos clsico aadindoles la capacidad de trabajar con restricciones y las variables que las forman.
5.2.1. Representacin de las Restricciones como Objetos usando UML

Las Bases de Datos Objeto-Relacionales analizadas por Stonebraker [143] son una ampliacin de las bases de datos relacionales para soportar el almacenamiento de objetos. Estas bases de datos utilizan el lenguaje de consulta SQL:2003, el cual permite la inclusin de la denicin de nuevos tipo de datos y procedimientos, lo que resulta necesario para la arquitectura que se presenta en esta tesis dando soporte a las BDdR. La eleccin de las Bases de Datos Objeto-Relacionales es novedosa en el mundo de las BDdR, ya que ninguna otra propuesta la ha tenido en cuenta para almacenar las restricciones. Entre las caractersticas de estas bases de datos, es relevante destacar aspectos como el uso de un lenguaje de programacin de ms alto nivel, lo que har posible el tratamiento de las restricciones de una forma ms fcil al representarlas como objetos, pudiendo combinar la potencia de las bases de datos relacionales con la expresividad de la orientacin a objetos. La denicin de este objeto-restriccin est basada en la notacin extendida de UML propuesta en [106] y mostrada en la gura 5.1.
Restriccin <<Object Type>> 0..1 2 Expresin {xor} 0..1 OPERADOR BINARIO OPERADOR {*,-,+} 1 Restriccin Atomica <<Object Type>> 1 {xor}
<<udt>> <<table>> <<udt>> <<table>>
0..1 OPERACIN BOOLEANA OPLOGIC{AND}
PREDICADO:{=, <, <=,>, >=} 0..1 Trmino 1
Variables
Constante
Figura 5.1: Representacin del objeto-restriccin con UML
En esta gura se representa una Restriccin como una Restriccin Atmica, o una conjuncin lgica de restricciones atmicas. A su vez, una Restriccin Atmica es la comparacin de dos Expresiones usando los comparadores (=, <, >, , ). Cada Expresin
127
es una combinacin de operadores aritmticos de variables y constantes denidas sobre enteros, naturales o otantes. En la gura 5.2 se muestra un ejemplo de cmo se representa la restriccin {a + b > c d + a < 8} como un objeto en forma de rbol sintctico. De esta forma, a una restriccin representada como un objeto mediante un rbol sintctico se le denominar objeto-restriccin.
> + a b c d +
< 8 a
Figura 5.2: Ejemplo de rbol sintctico de una restriccin (objeto-restriccin)
Un rbol sintctico es una estructura recursiva que viene denida por una raz y dos rboles sintcticos (hijo izquierdo e hijo derecho) si es un operador binario, o una raz y un rbol sintctico si es unario. Cada uno de estos rboles se representarn mediante objetos que representan las distintas restricciones, donde cada uno de estos objetos tiene un identicador, OID (Object Identication), que lo hace nico y diferenciable de todos los dems. El tipo de restricciones a las cuales se les da soporte en esta nueva arquitectura son las restricciones lineales de igualdad, las inecuaciones lineales, las polinmicas de igualdad y las inecuaciones polinmicas, todas ellas sobre el dominio de los naturales, enteros y los otantes, las cuales se describieron en la seccin 4.2.1. Este soporte debe ser ofrecido de una manera eciente, y con una implementacin modular y fcil de adaptar a nuevos requisitos. Todo esto, presentando una arquitectura independiente de la naturaleza de los datos que se estn tratando, pudiendo crear modelos en funcin de las consultas y de los datos almacenados en la base de datos. Como ya se ha comentado en el captulo anterior, la forma de evaluar una consulta depender de qu quiere obtener el usuario (informacin intensiva o extensiva), del tipo de restricciones involucradas y del dominio de las variables que las constituyen. En funcin del tipo de las restricciones se utilizar un motor de inferencia u otro, por lo que cuando una restriccin es insertada, se analizar y se etiquetar de una de las cuatro formas: 'Lineal
128
de Igualdad' (LinEQ), 'Inecuacin Lineal' (LinIN), 'Polinmica de Igualdad' (PolEQ) o 'Inecuacin Polinmica' (PolIN). Dos de los problemas de las Bases de Datos Objeto-Relacionales son la complejidad que conlleva el almacenamiento y tratamiento de objetos, y el coste computacional que ello provoca. Para paliar dichos problemas, se propone una arquitectura con ciertas caractersticas que ayuden a que el proceso de evaluacin de las consultas sea ms fcil y eciente. Las sentencias sobre las BDdR ms costosas, computacionalmente hablando, son las relacionadas con las restricciones y sus variables, ya que ser necesario trabajar con objetos en lugar de con informacin exclusivamente extensiva acorde con el lgebra relacional clsica. En el caso de las restricciones, se almacenar informacin adicional relacionada con ellas, con el objetivo de facilitar su posterior tratamiento. Este anlisis se realizar cuando las restricciones son aadidas a la base de datos (en tiempo de compilacin), mejorando as los tiempos de la evaluacin de consulta (en tiempo de ejecucin). Pese a que este tratamiento har ms lenta la insercin de restricciones, se compensa con la ganancia en las consultas, que son procesos que se suelen repetir ms en una base de datos. Para cada restriccin se almacenarn distintas caractersticas:
Rango de las variables (envolvente): Para cada variable de cada restriccin se

almacenarn los valores mximos y mnimos que puede tomar. Dichos valores son conocidos bien porque dicha informacin ha sido descrita al aadir la restriccin, por las caractersticas de la propia restriccin en la que est la variable, o por los valores mximos y mnimos del resto de variables de la restriccin a la que pertenece. De esta forma se puede utilizar la aritmtica intervalar [11] denida sobre las operaciones de la gramtica descrita:
[a, b] + [c, d] = [ a + c , b + d ] [a, b] [c, d] = [ a d , b c ] [a, b] [c, d] = [min( ac , ad , bc , bd ), max( ac , ad , bc , bd )]

Los valores mximos y mnimos que toma cada variable para cada restriccin sern almacenados en la base de datos para hacer ms eciente la evaluacin de consultas. Simplemente con el anlisis de dichos valores, se puede conocer si es posible que dos restricciones compartan alguna solucin, si las soluciones de una restriccin pueden estar incluida en otra . . . Esta informacin tambin ayudar a utilizar como
129
heurstica de resolucin de problemas de satisfaccin de restricciones, comenzar la bsqueda por las variables con tamaos de dominios ms pequeos.
Tipo de la restriccin: Ya que en funcin de si son ecuaciones o inecuaciones

la resolucin simblica se realizar con diferentes tcnicas, se almacenar qu tipo de restriccin es. Para la resolucin numrica el tipo de restriccin puede ayudar a utilizar como heurstica resolver primero las variables que estn en restricciones lineales y luego las que pertenecen a restricciones polinmicas.
Relacin entre variables y restricciones: Se mantendr una tabla donde se

almacenar la relacin entre las restricciones y las variables que tienen. Esta indexacin har ms eciente la bsqueda de variables que tiene una restriccin y en qu restricciones est una determinada variable. Tambin esta informacin ayudar a utilizar heursticas relacionadas con el grado de las variables, o lo que es lo mismo, el nmero de restricciones en las que cada variable participa para comenzar la bsqueda por dichas variables. Estas caractersticas se reejan en las tres tablas, mostradas en la gura 5.3, para mantener la segunda forma normal con respecto a las variables y las restricciones.
Restricciones (k)IdRestriccin: int Restriccin: Object Etiqueta: String 1..1 1..n Restricciones/Variables Variables 1..1 (k)IdRestriccin: int (k)IdVariable: int (k)IdVariable: int Nombre: String 1..n Rango_Inicio: number Tipo: String Rango_Fin: number
Figura 5.3: Indexacin entre variables y restricciones Cuando se crea una Base de Datos de Restricciones se crean tambin estas tres tablas (Restricciones, Variables y Restricciones/Variables), que mantienen las relaciones entre las variables y las restricciones. Estas tablas disminuyen la complejidad computacional de las consultas ya que con una sola consulta se puede conocer qu restricciones tienen qu variables y viceversa. Estas tablas permiten identicar cada restriccin (tabla Res-
tricciones), cada variable (tabla Variables) y establecer la relacin entre ambas (tabla Restricciones/Variables), lo que ayuda a detectar las restricciones relacionadas con una
consulta sin necesidad de tratarlas todas. Estas tablas no son visibles ni accesibles por el usuario de una forma directa, pero s de una manera implcita cuando se aaden, modican, borran o consultan restricciones de la base de datos. La tabla Restricciones almacena
130
el idRestriccin que corresponde al identicador del objeto (OID) generado por el sistema, y la Etiqueta acorde con el tipo de restriccin que representa. La tabla Variables almacena, para cada variable, su identicador, su nombre y el dominio (Natural, Entero o Flotante) al que pertenece. La tabla Restricciones/Variables almacena la relacin entre las variables y las restricciones, y sobre qu rango (Rango Inicio, Rango Fin) estn denidas cada una de las variables para cada una de las restricciones en las que participan. A su vez, las restricciones necesitarn una tabla donde los objetos (rboles sintcticos) se almacenarn de forma persistente, la cual tendr los campos presentados en la gura 5.4. Dicha gura presenta una tabla que permite serializar la informacin relativa al objeto-restriccin para poderla hacer persistente en una base de datos basado en el teorema de Cayley y Prfer revisado en [108]. Un objeto-restriccin se almacenar como un conjunto de tuplas con el mismo Id Restriccin. Cada una de estas tuplas representa un subrbol sintctico cuyo identicador se almacena en el atributo Id rbol. Cada uno de estos rboles tiene como atributos: una Raz, que puede tomar como valor uno de los operadores (, <, >, , , =, +, , ); el Hijo Izquierdo, que puede ser a su vez un subrbol con un determinado Id rbol, un identicador de variable o una constante; y el Hijo Derecho con la misma semntica que el hijo Izquierdo. Los atributos Hoja Izquierdo y Hoja Derecho describirn si los subrboles, Hijo Izquierdo e Hijo Derecho respectivamente, representan un subrbol (si toma el valor 0), el identicador de una variable (si toma el valor 1) o una constante (si toma el valor 2). De esta manera, pese a que los rboles sintcticos son por denicin una estructura recursiva, no es necesario hacer consultas recursivas para obtener un objeto-restriccin completo, ya que todas las tuplas de los subrboles que lo forman se caracterizan por tener un mismo
Id Restriccin.
rbol Sintctico Restriccin Id_Restriccin: Entero Identificador de la Restriccin Id_rbol: Entero Identificador del rbol Raiz: Cadena con la raiz del rbol Hijo_Izquerdo: Entero Identificador del rbol Izquierdo, variable o constante Hoja_Izquerdo: 0, 1 2 dependiendo de si es rbol, variable o constante Hijo_Derecho: Entero Identificador del rbol Derecho, variable o constante Hoja_Derecho: 0, 1 2 dependiendo de si es rbol, variable o constante
Figura 5.4: Tabla de almacenamiento de restricciones para la serializacin de los objetos
Arquitectura del Sistema Gestor de BDdR
131
Para la restriccin anterior ({a + b > c d + a < 8}), una forma de serializarla para almacenarla en una tabla es la mostrada en la gura 5.5. Aunque en el ejemplo se muestran los nombres de las variables, en realidad se almacenar el identicador de cada una de ellas establecido en la tabla interna Variables, lo que facilitar el cambio de nombre y dominio de las variables, ya que slo se almacenan en un lugar, cumpliendo as la segunda regla de Codd sobre el acceso garantizado [33][51].
rbol Sintctico Restriccin Id_Restriccin Id_rbol Raiz 1 1 1 1 1 ... 1 2 3 4 5 ... AND > < + + ... Hijo Izquerdo 2 4 5 a d ... Hoja Hijo Hoja Izquerdo Derecho Derecho 0 0 0 1 1 ... 3 c 8 b a ... 0 1 2 1 1 ...
Figura 5.5: Ejemplo de Serializacin de Objetos-Restriccin
Las restricciones sern tratadas de diferente manera en funcin de cmo se especique en las sentencias de consulta a la base de datos, dependiendo de si su tratamiento es numrico o simblico. Al representarse la informacin como un objeto, se permite denir un conjunto de mtodos pertenecientes a dicho objeto-restriccin que har posible crear diferentes modelos dependiendo de las restricciones involucradas y de la evaluacin de la consulta necesaria.
5.3.
En este documento se propone una arquitectura que trata la optimizacin temporal de las consultas cuando hay involucradas restricciones en ellas. Dicha arquitectura est basada en la utilizacin de un gestor de Bases de Datos Objeto-Relacional, junto a la construccin de las tres tablas internas comentadas y la denicin del objeto-restriccin. El principal objetivo es aadir una capa que haga lo ms transparente posible el uso de restricciones por parte del usuario, ampliando la sintaxis y la semntica de SQL, cambiando
132
Tratamiento de datos de Entrada/Salida
Construccin de Modelos
Modificacin de la estructura de la base de datos Modificacin del contenido de la base de datos
Resolutores
Resolutores de restricciones
Consulta sobre la base de datos
Resolutores Simblicos
BDdR
Datos
Figura 5.6: Arquitectura de la Base de Datos de Restricciones su sintaxis lo menos posible y siguiendo la losofa del estndar. Dicha ampliacin conlleva mantener toda la semntica de SQL de forma que si no existiesen atributos del tipo restriccin, sera un gestor de bases de datos relacional clsico, lo que facilita la adaptacin progresiva de bases de datos ya existentes a una Base de Datos de Restricciones. Esto signica que, con respecto al tratamiento de los datos clsicos y no del tipo restriccin, ni la semntica ni la sintaxis de SQL sufrirn ningn cambio, slo se ampliarn para el tratamiento de las restricciones y las variables que las forman. La arquitectura propuesta toma como nombre LORCDB, derivado de algunas de sus caractersticas expresadas en ingls (Labelled Object-Relational Constraint Database). La arquitectura, esquematizada en la gura 5.6, se divide principalmente en cuatro capas:
Tratamiento de datos de Entrada/Salida: Se encarga de la relacin con el

usuario, analizando las sentencias de entrada y mostrando el resultado de la evaluacin de las consultas. Mediante un Anlisis lxico y sintctico se estudia si es
133
necesario el tratamiento de restricciones para la evaluacin de la consulta. Si no tiene restricciones involucradas, la consulta ser tratada por el gestor de Base de Datos Objeto-Relacional y devolver la informacin obtenida al usuario sin necesidad de un tratamiento especial. En caso de que la consulta implique el tratamiento de restricciones, el mdulo Construccin de Modelos construir el modelo necesario para tratar la consulta.
Construccin de Modelos: Alguna de las partes que componen este mdulo se

explicarn con ms detalle en el siguiente captulo, ya que es la capa ms compleja e importante de la arquitectura. Dependiendo del tipo de sentencia (Creacin
de la BDdR, Creacin de Tablas, Consultas, . . .) se utilizarn distintas tcnicas y

herramientas junto a un conjunto de algoritmos y heursticas para resolverlas. Esta capa est a su vez dividida en tres, las cuales representan los tipos de acciones que se pueden realizar sobre una base de datos:
Modicacin de la estructura de la base de datos: Este mdulo slo

necesita comunicarse con la base de datos, e integra la Creacin de una DBdR con las tablas internas descritas en la seccin anterior, Creacin de Tablas cuando tienen algn campo restriccin, y Modicacin de la Estructura de
Tablas cuando stas tienen algn campo de tipo restriccin.
Modicacin del contenido de las tablas de la base de datos: Este mdulo se comunicar con la base de datos y necesitar construir problemas de satisfaccin y optimizacin de restricciones. Entre las acciones que integra se encuentra la Insercin de Tuplas en una Tabla y la Modicacin del Contenido
de una Tabla, tal como se muestra en la gura 5.7. La Insercin de Tuplas en una Tabla aade una tupla con restricciones en una tabla determinada, construyendo el rbol sintctico, obteniendo la envolvente (Rango Inicio, Rango Fin) con un COP para conocer los valores mximos y mnimos que pueden tomar cada una de las variables, y etiquetando la restriccin en funcin de su tipo. Tambin es necesario comprobar la integridad de la restriccin (que tiene al menos una solucin), ya que no tendra que permitirse introducir restricciones como por ejemplo {x < y y < x}, ya que no existe ningn valor de x e
y donde dicha restriccin se cumpla. Por otro lado, el submdulo de Modicacin de Contenido de una Tabla se encarga de modicar aquellas tuplas de
una relacin que cumplen una determinada condicin, por lo que en caso de que
134
Insercin de Tuplas en una Tabla Comprobar si la tupla ya existe (Creando y resolviendo un CSP si es necesario)
Modificacin del Contenido de una Tabla Comprobar si la tupla ya existe (Creando y resolviendo un CSP si es necesario)
Encontrar las envolventes (Creando y resolveindo un COP)
Obtener la Relacin
Crear y resolver un CSP para conocer qu tuplas se modifican
Figura 5.7: Modicacin del contenido de una Bases de Datos de Restricciones existan restricciones involucradas, necesitar construir y resolver un CSP tal como se ha explicado en la seccin 4.5 para la seleccin de tuplas que cumplan una condicin.
Consulta sobre la base de datos: Este mdulo gestiona el tratamiento

de la sentencia cuando se realiza una consulta sobre tablas con atributos restriccin, del tipo seleccin, proyeccin, producto cartesiano, unin o diferencia de conjuntos. Los detalles de este mdulo sern descritos ms ampliamente en la subseccin 5.3.1.
Datos: Representa el sistema gestor de Bases de Datos Objeto-Relacional, con la

estructura de tablas internas explicadas en la seccin anterior. Como ejemplo de gestor de Base de Datos Objeto-Relacional se ha considerado utilizar OracleT M 9.i, aunque se podra extender a cualquier otro gestor que permitiera el modelo lgico objeto-relacional.
Resolutores: Est formado por las herramientas que resolvern, siempre que la
sentencia lo requiera, los modelos construidos en la capa Construccin de Mode-
los. Como ejemplo de herramientas en esta tesis se han utilizado JSolverT M [78] y
MathematicaT M v.5 [128], donde JSolverT M evaluar las sentencias de forma numrica y MathematicaT M v.5 lo har de manera simblica, aunque podran ser sustituidas por otras herramientas equivalentes.
135
Al ser una arquitectura modular, permite el intercambio de los resolutores de modelos, de esta forma provee de mayor capacidad de adaptacin a nuevos tipos de restricciones, nuevos dominios de variables, aadir otras operaciones denidas para la consulta, y ampliar las herramientas que resuelvan los modelos. Esto es posible ya que se utiliza el patrn
de diseo Estrategia, pudiendo decidir en tiempo de ejecucin qu herramienta realizar

la evaluacin de la consulta.
5.3.1. Consulta sobre la base de datos

Este mdulo, presentado en la gura 5.8, da soporte a los cinco tipos de operaciones primitivas del lgebra relacional pero adaptadas al tratamiento de las restricciones, lo cual ha derivado en la denicin de los dos nuevos tipos de atributos. Cualquiera de las relaciones de salida puede ser a su vez una relacin de entrada que participe en otra operacin, manteniendo as la propiedad de cierre o clausura del lgebra relacional. Dicha caracterstica se observa en la gura 5.8 entre el mdulo Consulta y los restantes mdulos denidos para las distintas operaciones. Esto hace posible que una consulta pueda estar formada por varias operaciones anidadas, por ejemplo una proyeccin que se hace sobre la relacin obtenida como salida en una seleccin. Aunque en el siguiente captulo se analizan todos los detalles de implementacin relativos a cada una de las operaciones, aqu se presentan algunos detalles de inters:
Seleccin: La operacin de seleccin se realiza sobre una relacin que puede ser
una tabla de la base de datos o la relacin de salida de otra operacin, lo cual se hace en Obtener las relaciones involucradas. De entre las tuplas de dicha relacin, formarn parte de la salida de la operacin de seleccin aquellas que cumplan una determinada condicin. En el submdulo Seleccionar las restricciones se obtendrn aquellas tuplas que cumplan la condicin en funcin del lgebra relacional sobre los atributos clsicos, que puedan cumplir la condicin en funcin de los valores mximos y mnimos que puedan tomar las variables (envolvente), y que tengan variables relacionadas con el predicado. Para conocer cules de estas tuplas cumplen el predicado, siempre que estn involucrados atributos restricciones, ser necesario construir un CSP de la forma que se ha explicado en el captulo anterior (seccin 4.5).
136
Consulta
Seleccin
Obtener las Relaciones involucrada Obtener Relacin
Proyeccin
Producto Cartesiano
Obtener Relaciones
Unin
Obtener Relaciones
Diferencia
Obtener Relaciones
Seleccin de Restricciones
Seleccin de Restricciones relacionadas con la proyeccin
Realizar combinaciones
Combinacin de Restricciones Posible Creacin y resolucin de CSP
Combinacin de Restricciones Posible Creacin y resolucin de CSP
Posible Creacin y resolucin de CSP
Creacin Creacin de Creacin y Creacin y de Modelo Modelo resolucin resolucin para la para la de COP de CSP Sustitucin Eliminacin de de Variables Variables
Figura 5.8: Consulta sobre la Bases de Datos de Restricciones
Proyeccin: Esta es la operacin ms compleja, ya que la proyeccin es una seleccin horizontal de los atributos que forman la relacin, por lo que tambin pueden ser restricciones o variables de restriccin. La mayor problemtica la establece la obtencin de las variables de restriccin, que pueden ser conjuntos de valores instanciados de las variables (obtenidos mediante CSP o COP), o nuevas restricciones inferidas de las originales por la eliminacin o sustitucin de variables, como se explic en el captulo anterior (seccin 4.6). Al igual que en la seleccin, se tendr que obtener primero la relacin de entrada de la operacin (tabla de la base de datos o relacin de salida de otra operacin) y los atributos restriccin relacionados con la proyeccin que se pretende realizar.
Producto Cartesiano: Como se ha analizado en el captulo anterior, no se necesita

un tratamiento especial aunque existan atributos restriccin en las relaciones sobre las que se realiza el producto cartesiano. Al igual que en el resto de operadores, las relaciones de entrada de dicho operador pueden ser tablas de la base de datos o relaciones de salida de otras operaciones.
Unin: En el caso de que las tuplas contengan atributos restriccin hay que cerciorarse de que no existan dos tuplas repetidas en la relacin de salida como se analiz
CORQL: Ampliacin de SQL para BDdR
137
en la seccin 4.7. Si los atributos clsicos toman valores diferentes, o las envolventes de las distintas restricciones no tienen valores en comn, no ser necesario crear y resolver un CSP.
Diferencia: Tiene las mismas caractersticas que la unin, analizando si las restricciones no tienen valores en comn o las soluciones de una estn incluidas en la de otra (seccin 4.8), por lo que tambin en algunos casos ser necesario crear y resolver un CSP.
5.4.
Una vez introducidos los distintos mdulos de la arquitectura, esta seccin presenta la sintaxis y la semntica de las sentencias que hacen uso de ellos. Este conjunto de sentencias denirn una ampliacin de SQL para Bases de Datos de Restricciones que recibir el nombre de CORQL (Constraint Object-Relational Query Language).
5.4.1. Creacin de una LORCDB

Para la creacin de una LORCDB se utiliza la siguiente sintaxis:
CREATE LORCDB <nombre base de datos>
Como se ha explicado en este captulo, las restricciones se almacenarn como objetos en una Base de Datos Objeto-Relacional, pero con una estructura de tablas internas que permite indexar las variables y almacenar los valores mximos y mnimos de cada variable para hacer las consultas ms ecientes. Esto signica que cuando una LORCDB es creada con la sentencia anterior, tambin estas tres tablas son creadas. Estas tablas estarn protegidas ante el acceso de los usuarios de forma explcita, slo permitiendo que se modiquen por el sistema cuando las restricciones son aadidas, modicadas o borradas.
5.4.2. Creacin de tablas en una LORCDB

Siguiendo la losofa de modicar la sintaxis de SQL lo menos posible, la creacin de las tablas para las LORCDB es similar a la de las bases de datos relacionales clsicas,
138
con la nica diferencia de poder crear columnas (atributos) de tipo restriccin (Atributo Restriccin). Un ejemplo de creacin de tablas puede ser:
CREATE TABLE Parcelas(IdPropietario Integer, Nombre String, Parcela Constraint)
Aunque tambin es posible crear una tabla con varios atributos restriccin. Por ejemplo, las parcelas y las casas que contiene las parcelas:
CREATE TABLE ParcelasYCasas(IdPropietario Integer, NombrePropietario String, Parcela Constraint, Casa Constraint)
5.4.3. Insercin de tuplas en la tabla

Si un atributo es de tipo restriccin, ser posible aadir restricciones en dicha columna. Al igual que el resto de tipos, se realizar la comprobacin de que el tipo del elemento insertado es conforme con el tipo de la columna donde se aade la informacin. Cuando se aade una restriccin a la base de datos, se actualiza la tabla Restricciones, junto a la tabla Variables si se aade alguna variable nueva, y Variables/Restriccin para crear la relacin entre las variables y la restriccin aadida. Las variables de las restricciones tienen que estar denidas sobre un tipo (Natural, Entero y Flotante); si no se especica, el dominio por defecto ser Flotante. Tambin es posible denir el rango de las variables para un determinado dominio. La sintaxis de las restricciones insertadas tiene que seguir la gramtica denida en la subseccin 4.2.1 para restricciones. La sintaxis de la insercin de la informacin ser de la forma:
INSERT INTO <nombre de la tabla> ( <lista de atributos> ) VALUES ( < lista de valores > )
Si un atributo se ha creado como atributo restriccin, el valor que se le da tendr la sintaxis:

'{'<cadena restriccin>[,'('Dominio [Rango] nombre variable[,Dominio [Rango] nombre variable . . . ]')]}'
Un ejemplo de insercin de restricciones en la tabla anterior puede ser:
139
INSERT INTO ParcelasYCasas(IdPropietario, Nombre, Parcela, Casa) VALUES

(101, 'Jess Pineda', {'x2 + y 2 49'(Float 10..10 x, Float y)},
{'x > 0 AND x 5 AND y > 0 AND y 6.5'})
Como se muestra en el ejemplo, es posible denir el dominio de cada variable, teniendo en cuenta que si una variable participa en varias restricciones, es necesario que en todas est denida sobre el mismo tipo, aunque el rango de sus valores pueda tomar diferentes valores. Tambin es posible acotar los posibles valores que puede tomar una variable utilizando la sintaxis Rango Inicio..Rango Fin, que en caso de no especicarse ser .. + que corresponder por defecto con {Integer.MIN VALUE..Integer.MAX VALUE} para las variables de Enteros, {0..Integer.MAX VALUE} para las variables de Naturales, y {Float.MIN VALUE..Float.MAX VALUE} para las variables de Flotantes. Estos valores son los denidos en el lenguaje JavaT M usado para la implementacin del lenguaje CORQL. Cuando una restriccin se aade a la base de datos, se comprueba su consistencia, ya que si no existe ninguna solucin para ella no se realizar su insercin, por ejemplo
x2 > 2x2 .
Resumiendo, los pasos para almacenar una tupla con atributos restriccin en una LORCDB son: 1. 2. Comprobar que la sintaxis de la sentencia es correcta. Comprobar que ninguna de las variables de la restriccin de entrada est ya en la base de datos con otro tipo. En caso de que esto ocurra se mostrar un error y no se realizar la insercin. 3. 4. 5. Comprobar que dicha tupla no est ya almacenada. Crear un objeto con la restriccin y almacenarlo en la tabla Restricciones. Rellenar el campo de la etiqueta en la tabla Restricciones en funcin del tipo de restriccin que sea (LinEQ, LinIN, PolEQ, PolIN). 6. Si la variable ya est en la base de datos no se volver a incluir a la tabla Variables, s se incluir en caso contrario.
140
7.
Crear tuplas en la tabla Restricciones/Variables para la nueva restriccin y todas las variables, tanto las nuevas como las que estaban.
8.
Crear un COP, al que se le incluir el rango denido en la insercin, para conocer para cada variable de la restriccin su valor mayor y menor, y almacenarlos en los campos Rango Inicio y Rango Fin de la tabla Restricciones/Variables. Tras realizar estos pasos, las tablas para la insercin anteriormente mostradas quedarn
como se muestra en la gura 5.9, donde la tabla ParcelasYCasas tiene dos atributos de tipo restriccin. Los atributos restriccin contienen el identicador del objeto que se almacena en la tabla Restricciones, a la vez que sus variables son almacenadas en la tabla Variables para denir la indexacin con las restricciones mediante la tabla Restricciones/Variables. Pese a que el rango de la variable x denida en la sentencia es 10..10, el mximo valor que puede tomar para que la restriccin {x2 + y 2 49} sea satisfactible es 7..7, que sern los almacenados en la tabla Restricciones/Variables. Con respecto a la etiqueta, en este caso las restricciones son inecuaciones polinmicas (PolIN) y lineales (LinIN). Estas etiquetas ayudarn a escoger qu herramienta es ms adecuada para evaluar las distintas consultas sobre las diferentes tuplas.
ParcelasYCasas
Id 101 Nombre J. Pineda Parcela 1 Casa 2
Restricciones
Id 1 2 Restriccin x2+y2=<49 x>0 & x=<5 & y>0 & y=<6.5 Etiqueta PolIN LinIN IdRes 1 1 2 2
Restricciones/Variables
IdVar 1 2 1 2 Rango_Ini -7 -7 0 0 Rango_Fin 7 7 5 6.5 Id 1 2
Variables
Nombre Tipo x y Float Float
Figura 5.9: Ejemplo de tablas rellenas
5.4.4. Consulta a una LORCDB

Una consulta a una Base de Datos de Datos de Restricciones es una combinacin de las operaciones primitivas del lgebra relacional presentadas en el captulo anterior en la seccin 4.3.
141
La sintaxis de las consultas sern de la forma:

consulta := SELECT <lista de atributos(t1 ) [,lista de atributos(t2 ), . . .]> FROM <lista de tablas(t1 , t2 , . . .)> WHERE predicado [{UNION|MINUS} consulta]
El parmetro <lista de atributos(ti )> representa diferentes tipos de proyeccin realizada sobre los atributos pertenecientes en la tabla ti , que pueden ser atributos clsicos, restricciones o variables de restricciones. Si se quieren obtener atributos de distintas tablas (t1 , t2 , . . .) conllevar la realizacin del producto cartesiano entre la relacin resultante de cada tabla. El parmetro predicado hace referencia al operador de seleccin, deniendo las condiciones que tienen que cumplir los atributos de la relacin. Por ltimo UNION y
MINUS sern los operadores de unin y diferencia de conjuntos.

El orden de prioridad al resolver las operaciones sern: 1. 2. 3. 4. Seleccin (WHERE predicado) Proyeccin para cada tabla (SELECT <lista de atributos(ti )>) Producto cartesiano, uniendo todas las relaciones Unin y diferencia, ambas con la misma prioridad Con respecto a la lista de atributos, donde at representa atributos clsicos, atc atributos restriccin, y atc .variable atributos variables de restriccin, la sintaxis ser:
lista de atributos := atributo ',' lista de atributos

| atributo
; atributo := ['MIN' | 'MAX' | 'AVG' | 'COUNT' . . .] at

| atc | [VERTICAL | HORIZONTAL] atributo Variable
; atributo Variable := 'VALUES' '('listaAtVariables')'
142
| 'CONSTRAINTS' '('listaAtVariables')' | 'FULL CONSTRAINTS' '('listaAtVariables')' | 'VALUES'[n] '('listaAtVariables')' | ['MIN' | 'MAX'] 'VALUE' '('atc .variable')' | 'BOOLEAN VALUE' '('atc ')'
; listaAtVariables := atc '.'variable ',' listaAtVariables

| atc '.'variable
;
Cuando la proyeccin se realiza sobre atributos variables de restriccin, existen diferentes alternativas en funcin de cmo y qu tipo de informacin se quiere obtener: Para determinar qu restricciones de la relacin est involucradas en la operacin de proyeccin, se utilizan palabras reservadas del lenguaje VERTICAL y HORIZONTAL. Dichas palabras representan si la relacin entre las variables se pueden hacer entre restricciones de la misma tupla (VERTICAL), o del mismo atributo pero entre distintas tuplas (HORIZONTAL). Si no se especica, la opcin por defecto es HORIZONTAL. Cuando se quiere obtener como salida otra restriccin, se utiliza la palabra reservada CONSTRAINTS, pero cuando se quiere especicar que se quiere hacer sustitucin simblica y no simplemente eliminacin, se utiliza la sentencia FULL CONSTRAINTS. Cuando se quiere hacer una proyeccin sobre atributos variable de restriccin, pero obteniendo valores instanciados de las variables, se utiliza la palabra VALUES, lo que devolver una tupla con valores de las variables. En caso de querer obtener ms de una tupla, se utilizar VALUES [n], donde n representa el nmero de tuplas que se quieren obtener. Si se quiere obtener slo un valor de una variable, el mnimo o el mximo, ser ['MIN' | 'MAX'] 'VALUE' la sentencia utilizada. Cuando se quiere conocer si existe un valor que hace satisfactible cada una de las restricciones de un atributo restriccin, se utiliza la sentencia BOOLEAN VALUE, donde la salida ser true o false.
143
Con respecto al predicado, y siguiendo la denicin introducida en 4.5, la sintaxis ser de la forma:
predicado := condicin
| condicin ['AND' | 'OR'] predicado
; condicin := at ['<' | '' | '>' | '' | '=' | '<>'] [at | constante]

| atc ['<' | '' | '>' | '' | '=' | '<>' | '&' | '' | '' | '' | '']
[atc | restriccin]
| atc ['<' | '' | '>' | '' | '=' | '<>' | '&' | '' | '' | '' | '']
'(' [atc | restriccin] 'FOR' '{'listaVariables'}' ['AND' listaAtVarIgual]')'

| atributo Variable ['<' | '' | '>' | '' | '=' | '<>']
[atc '.'variable | constante] ; listaVariables := Variable

| Variable ',' listaVariables
; listaAtVarIgual := atc '.'Variable '=' atc '.'Variable

| atc '.'Variable '=' atc '.'Variable 'AND' listaAtVarIgual
5.4.5. Modicacin de la estructura de una tabla

Existen dos acciones de modicacin de la estructura de una tabla, una de ellas es la modicacin de la estructura, aadiendo una nueva columna con la sintaxis:
ALTER TABLE <nombre de la tabla> ADD <nombre de la columna>
144
<tipo de la columna>
donde la columna aadida puede ser un atributo restriccin. La otra opcin es borrar una columna que tambin puede ser un atributo restriccin. En ese caso, se eliminarn todas las restricciones que estn en la tabla Restricciones, las variables que no pertenezcan a otras restricciones de Variables, y por supuesto las entradas que relacionen las variables y restricciones de Restricciones/Variables. La sintaxis sera:
ALTER TABLE <nombre de la tabla> DROP <nombre de la columna>
5.4.6. Modicacin del contenido de una tabla

Con respecto a la modicacin de contenido, se puede modicar la informacin ya almacenada o eliminar tuplas completas. La sintaxis para la modicacin de las tuplas es:
UPDATE <nombre de la tabla> SET
<nombre del atributo> = <nuevo valor>
WHERE predicado
donde la columna de la sentencia tiene que estar involucrada en el predicado. Con esta operacin ser posible cambiar el contenido de un atributo clsico, un atributo restriccin, o el nombre de una variable de una restriccin. Cambiar el nombre de una variable no es ms que modicar un registro de la tabla Variables. Con respecto al borrado de una tupla, la sintaxis ser:
DELETE FROM <nombre de la tabla> WHERE predicado

en este caso, en el predicado tienen que estar involucrados algunos de los atributos de la tabla sobre la cual se va a realizar el borrado. El predicado seguir la sintaxis y la semntica explicada en la seccin 4.5.1 del captulo anterior.
5.5. Resumen
En este captulo se presenta la arquitectura que da soporte a la nueva denicin de Base de Datos de Restricciones. La arquitectura LORCDB tiene caractersticas que ayudarn a que la evaluacin de consultas sea ms fcil y eciente, almacenando informacin
Resumen
145
sobre las restricciones. La informacin que almacena est relacionada con el rango del dominio donde est denida, el tipo de restriccin y la relacin entre restricciones y las variables que las conforman. Para trabajar con atributos del tipo restriccin, se ha denido una extensin de SQL llamado CORQL, deniendo la gramtica relativa a las distintas operaciones que se pueden realizar sobre una Base de Datos de Restricciones, como su creacin, creacin de tablas, insercin de tuplas, consultas, modicaciones y borrados. Para ello se ha utilizado la redenicin de las cinco primitivas del lgebra relacional, teniendo en cuenta los atributos restriccin y atributos variable de restriccin, propuestos en el captulo anterior.
Captulo 6 Implementacin del lenguaje CORQL

Una vez denida la arquitectura que da soporte a las Bases de Datos de Restricciones y el nuevo lenguaje CORQL presentado como extensin de SQL, en este captulo se presentar cmo dicha arquitectura junto a un conjunto de algoritmos, hacen ms prctica y eciente la evaluacin de las distintas operaciones relacionadas con la consulta. Para facilitar la presentacin de las diferentes estrategias de evaluacin de consultas, se introduce un ejemplo hipottico basado en los impuestos a pagar cuando se realiza la venta de productos en funcin de la provincia o el pas involucrado.
6.1.
Ejemplo de caso de estudio
Como ejemplo para hacer ms claros los pasos que conforman los distintos algoritmos relacionados con la implementacin de cada una de las operaciones del lgebra relacional para BDdR, se utiliza la base de datos mostrada en la gura 6.1. Dicha base de datos almacena las provincias (tabla Provincia) de fabricacin de distintos productos (tabla Pro-
ducto). Cuando se realiza la venta de dichos productos ser necesario pagar unos impuestos
provinciales si se venden dentro de su misma provincia (tabla ImpuestosProvinciales), impuesto nacionales si se venden a otra provincia del mismo pas, donde se pagarn los impuestos en funcin de la provincia donde se realice la venta (tabla ImpuestosNacionales), o impuestos internacionales si se venden a otro pas (tabla ImpuestosInternacionales) lo que depender del pas donde se haga dicha venta. Algunas de estas tablas tienen atributos de tipo Restriccin, donde se denir una relacin entre variables. En el caso de la tabla Provincia se establecer la relacin entre las
148
Captulo 6. Implementacin del lenguaje CORQL
Precio ImpuestosInterNacionales (k)IdPas: int Impuestos: Constraint ImpProv Producto (k)IdProducto: int Nombre: String Precio: float IdProvincia: int 1..1 0..n Provincia (k)Id: int Nombre: String Superficie: Constraint 1..1 1..n ImpuestosProvinciales (k)IdProvincia: int Impuestos: Constraint ImpProv ImpuestosNacionales 1..n (k)IdProvincia: int Impuestos: Constraint ImpNac
Precio
Figura 6.1: Diagrama de Tablas del ejemplo variables espaciales x e y en el atributo restriccin Supercie. Algunos ejemplos concretos de estas restricciones son los presentos en la gura 6.2.
Id 1 2 Nombre Sevilla Cdiz Provincias Superficie -27 x +39 y < 5682 AND 8x+67 y < 14656 AND 75 x +19 y < 15575 28 x +9 y < 6053 AND 5 x -42 y < -3149 AND -33 x +33 y < -1683 34 x +80 y < 14050 AND 16 x -13 y < 3421 AND -41 x -67 y < -13481 AND -9 x < -1665
Huelva
-24x +10y < -7298 AND 28x +30 y < 12806 Crdoba AND 18x -24 y < 4986 AND -22x -16 y < -8678 Mlaga Jaen Granada ... 7 x +36 y < 20488 AND 39 x -22 y < -10270 AND -46 x -14 y < -8660 88 y < 50776 AND 57 x < 7980 AND -39 x -88 y < -51220 AND -18 x < -936 39 x +88 y < 51220 AND -110 y < -57200 AND -39 x +22 y < 10270 ...
5 6 7 ...
Figura 6.2: Ejemplo de tabla Provincias Otro ejemplo de atributo restriccin es ImpuestosNacionales.Impuestos, que relaciona las variables ImpNac, ImpProv y Precio. Al igual que en las bases de datos relacionales clsicas, se pueden denir relaciones entre los atributos univaluados de distintas tablas mediante la denicin de claves ajenas, como la que existe entre Provincias.id e Im-
puestosNacionales.IdProvincia. Aunque en las BDdR se crean relaciones entre las variables de las restricciones de forma implcita, por ejemplo entre los atributos restriccin
Impuestos para las tablas ImpuestosProvinciales, ImpuestosNacionales e ImpuestosInter-
Implementacin de la Seleccin
149
nacionales. Dicha relacin se representa en la gura 6.1 con lneas discontinuas junto al
nombre de las variables. Cabe destacar el atributo Precio, que puede representar tanto un atributo clsico, cuando se denota como Producto.Precio, como un atributo variable de restriccin ImpuestosNacionales.Impuestos.Precio. Un ejemplo del contenido de las tablas ms relevantes, ya que tienen atributos de tipo restriccin, se muestra en la gura 6.3. Como se puede observar, las restricciones tienen variables que las relacionan, las cuales estarn almacenadas e indexadas en las tablas Restricciones, Restricciones/Variables y
Variables, por lo que el cambio de las restricciones no implicar cambios estructurales en

el diseo de la base de datos, slo cambios en el contenido de las tablas de indexacin.
IdProvincia 1 1 1 2 3 4 4 ...
ImpuestosProvinciales Impuestos
0<Precio<3.000 AND ImpProv=0.05*Precio+50 3.000<=Precio<6.000 AND ImpProv=0.06*Precio+53 12.000<=Precio AND ImpProv=0.07*Precio+61 0<Precio<24.000 AND ImpProv=0.09*Precio 0<Precio<38.000 AND ImpProv=0.10*Precio+50 0<Precio<12.000 AND ImpProv=0.02*Precio+50 12.000<=Precio<41.000 AND ImpProv=0.13*Precio+50 ...
IdProvincia 1 1 2 2 3 4 4 ...
ImpuestosNacionales Impuestos
0<=ImpProv<500 AND ImpNac=ImpProv + 0.02Precio 500<ImpProv AND ImpNac=ImpProv + 0.01Precio 0<=ImpProv<200 AND ImpNac=Precio*Precio*0.05 200<=ImpProv AND ImpNac=Precio*0.07 ImpNac=ImpProv *ImpProv+99 0<=Precio<2000 AND ImpNac=ImpProv + 0.01Precio 2000<=Precio<=5000 AND ImpNac=0.11*Precio + 54 ...
ImpuestosInternacionales IdPas Impuestos

1 2 3 4 5 6 7 8 9 10 11 12 13 ... ImpInterNac=ImpNac + 10 ImpInterNac=ImpNac+12 ImpInterNac=ImpNac*1.02 ImpInterNac=ImpProv + 100 ImpInterNac=ImpProv + 0.01Precio ImpInterNac=ImpProv + 0.02Precio ImpInterNac=ImpNac*1.20 ImpInterNac=ImpNac*1.0545 ImpInterNac=ImpProv ImpInterNac=ImpProv + 26 ImpInterNac=ImpProv + 98 ImpInterNac=Precio*0.025 ImpInterNac=Iva*Valor*0.025 ...
Figura 6.3: Ejemplo de tablas que almacenan Restricciones Sobre estas tablas se presentarn distintos ejemplos para las cinco operaciones primitivas del lgebra relacional, donde se reejar cmo se incorporan distintas estrategias para el tratamiento de restricciones, junto a los detalles de cada uno de los algoritmos necesarios para que la evaluacin de dichas operaciones sea eciente.
6.2.
Para que la implementacin de la seleccin sea eciente, se dene una estrategia para tratar, en un determinado orden, cada una de las condiciones del predicado. La estrategia de evaluacin de la seleccin consistir en, partiendo de una relacin de entrada (R), obtener un subconjunto horizontal RSalida . Para obtener la salida, se ejecutar una secuencia de pasos donde en cada uno de ellos se eliminarn las tuplas que no cumplan una parte de
150
la condicin. Esto vendr determinado por el tipo de atributo involucrado en el predicado, tal como se muestra en la gura 6.5. 1.
Atributos Univaluados: Partiendo de una relacin R de entrada, sobre la que se

quieren obtener aquellas tuplas que cumplen un predicado, primero se seleccionarn aquellas cuyos atributos clsicos o univaluados cumplan el predicado en funcin del lgebra relacional clsica, obteniendo una nueva relacin R . Esto es posible gracias al nuevo modelo de BDdR introducido en esta tesis, ya que en el resto de propuestas no exista esta divisin entre los datos univaluados y los datos restriccin.
2.
Atributos Variable de Restriccin: El segundo tratamiento estar relacionado

con los atributos variable de restriccin, donde dichos atributos representan variables numricas cuyos valores mximos y mnimos estn almacenados en las tablas de indexacin de la base de datos. Los predicados relacionados con ellos, pueden denir una comparacin entre dos variables, una variable y un atributo clsico numrico, o una variable y una constante. Estos tres tipos de comparaciones se tratarn mediante el anlisis de los lmites (mximo y mnimo) entre los dos atributos involucrados en la comparacin del predicado. Por ejemplo, si las tuplas de la relacin de salida tienen que cumplir que la variable a es menor que el valor 5, y el dominio de dicha variable para una restriccin es 10..15, signicar que la tupla a la que pertenece dicha variable no formar parte de la salida. En algunos casos, esta eliminacin de tuplas se podr realizar sin necesidad de crear ningn problema de satisfaccin de restricciones, tan slo siendo necesario una consulta clsica, ya que los valores mximos y mnimos de cada variable estn almacenados en atributos clsicos. Sin embargo, para estar seguros que la variable puede tomar ese valor, ser necesario crear un CSP.
3.
Atributos Restriccin: Para los atributos restriccin se harn dos tipo de

tratamientos. En principio se analizarn los rangos de las variables (envolventes), para conocer si se cumple el predicado involucrado con los atributos restriccin. Si con este anlisis no es suciente, ser necesario crear y resolver problemas de satisfaccin de restricciones.
Anlisis de Rangos de las Variables: Analizando el mnimo y mximo valor

que puede tomar una variable, es posible inferir si las restricciones involucradas
151
en la comparacin cumplen o no una condicin. Por ejemplo si se comparan dos restricciones Cx y Cy , ambas denidas sobre las variables v1 e v2 , donde los rangos son Cx (v1 :[5..15], v2 :[20..30]) y Cy (v1 :[20..25], v2 :[40..55]). Si el predicado fuera Cx <Cy , se puede asegurar que la tupla a la que pertenecen ambas restricciones formar parte de la relacin de salida, mientras que si el predicado fuera Cx Cy , la tupla a la que pertenecen las restricciones no formara parte de la relacin de salida.
Construccin de CSP: Aunque existen casos donde es posible saber si una

tupla formar parte de la relacin de salida sin necesidad de construir y resolver un CSP, tambin existen casos donde no es posible saberlo con un simple anlisis de los dominios de las variables. Volviendo al ejemplo anterior, si los dominios de las variables fueran Cx (v1 :[5..15], v2 :[20..30]) y Cy (v1 :[2..25],
v2 :[10..55]), y el predicado Cx Cy , pese a que los dominios de las variables en Cx estn incluidas en los dominio de las variables en Cy , no se puede asegurar
que se cumple el predicado para las restricciones. Un ejemplo donde los rangos de las variables estn incluidos dentro de otra, pero no sus soluciones, es el mostrado en la gura 6.4. En esos casos ser necesario crear y resolver un problema de satisfaccin de restricciones con ambas restricciones de la forma presentada en la seccin 4.5.1.
v2 Cy Cx
v1
Figura 6.4: Ejemplo de Cx
Cy
Un ejemplo de consulta con seleccin sobre las tablas de la gura 6.3, y siguiendo los pasos descritos anteriormente puede ser:
Obtener los impuestos provinciales, impuestos nacionales e impuestos internacionales que tienen que pagar los productos de la provincia con identicador igual a 1. Adems se
152
R'
Atributos Univaluados: lgebra Relacional
R'
R''
Atributos Variable de Restriccin: Satisfactibilidad de las envolventes con lgebra relacional
R''
Atributos Restriccin: Satisfactibilidad de las envolventes con lgebra relacional
R'''
R'''
RSalida
Atributos Restriccin: Satisfactibilidad mediante CSP con lgebra relacional
Figura 6.5: Pasos de la operacin de Seleccin
desea que de entre todas las posibilidades de impuestos provinciales, slo presentar los impuestos para los productos cuyos precios son mayores de 4.000 y menores de 5.000, y que para cada impuesto nacional (ImpNac) el impuesto internacional siempre sea menor que ImpN ac 1.25.
La sintaxis de consulta para el ejemplo ser de la forma:
SELECT * FROM ImpuestosProvincial, ImpuestosNacionales, ImpuestosInternacionales WHERE ImpuestoProvinciales.idProvincia = 1 AND ImpuestoNacionales.idProvincia = 1 AND
153
ImpuestoProvincial.Impuestos.Precio > 4000 AND ImpuestoProvincial.Impuestos.Precio < 5000 AND ImpuestosInternacionales.Impuestos < (ImpInterN ac = ImpN ac 1,25 FOR {ImpInterN ac} AND ImpuestosInternacionales.Impuestos.ImpNac=ImpNac)
Este ejemplo muestra un predicado donde hay involucrados atributos clsicos, como es el caso de ImpuestoProvinciales.id =
1, atributos restriccin como
ImpuestosInternacionales.Impuestos < (ImpInterN ac = ImpN ac 1,25), y variables de restriccin como ImpuestoProvincial.Impuestos.Precio > 4000. Todos estos tipos de atributos ayudarn a explicar la problemtica del tratamiento de los datos de tipo restriccin y cmo son evaluados en la seleccin. Para cada una de las relaciones (tablas) que aparezcan en el predicado de la consulta se resolvern de forma independiente, al menos que existan condiciones que comparen dos relaciones. El orden de resolucin ser el mostrado en la gura 6.5, que para este ejemplo sern: 1.
Atributos Clsicos (univaluados). Eliminar todas aquellas tuplas que no cumplan las condiciones relativas a los atributos univaluados.
Esta eliminacin es la que hacen las bases de datos relacionales clsicas, evitando el tratamiento de dichas tuplas mediante problemas de satisfaccin de restricciones para saber si se cumple una condicin. Si no se almacenaran los atributos restriccin y los univaluados de forma independiente esto no sera posible, con el consecuente gasto computacional. En el caso del ejemplo, no pertenecern a la relacin de salida aquellas tuplas de la tabla ImpuestoProvinciales, cuyo atributo id sea distinto de 1, junto a las tuplas de
ImpuestosNacionales cuyo idProvincia no sea igual a 1. De esta forma slo quedarn

las tuplas mostradas en la gura 6.6. 2.
Atributos Variable de Restriccin. Eliminar todas aquellas tuplas relativas a

variables de atributos restriccin cuya envolvente no cumpla la parte del predicado relacionada con ellas.
154
IdProvincia 1 1 1
0<Precio<3.000 AND ImpProv=0.05*Precio+50 3.000<=Precio<6.000 AND ImpProv=0.06*Precio+53 12.000<=Precio AND ImpProv=0.07*Precio+61
IdProvincia 1 1
0<=ImpProv<500 AND ImpNac=ImpProv + 0.02Precio 500<ImpProv AND ImpNac=ImpProv + 0.01Precio
IdPas
1 2 3 4 5 6 7 8 9 10 11 12 13
ImpuestosInternacionales Impuestos
ImpInterNac=ImpNac +10 ImpInterNac=ImpNac+12 ImpInterNac=ImpNac*1.02 ImpInterNac=ImpProv + 100 ImpInterNac=ImpProv + 0.01Precio ImpInterNac=ImpProv + 0.02Precio ImpInterNac=ImpNac*1.20 ImpInterNac=ImpNac*1.0545 ImpInterNac=ImpProv ImpInterNac=ImpProv + 26 ImpInterNac=ImpProv + 98 ImpInterNac=Precio*0.025 ImpInterNac=Iva*Valor*0.025
Figura 6.6: Relaciones tras la eliminacin por atributos univaluados (Paso I) Esto tambin se transformar en una consulta clsica sobre la base de datos, ya que la envolvente est almacenada como dos atributos numricos de la relacin Res-
tricciones/Variables. Esto provocar que el tiempo de evaluacin de las consultas sea

menor, ya que se eliminarn todas aquellas tuplas cuyas restricciones relacionadas con la condicin, no puedan cumplir el predicado por su envolvente. Ms an, se facilitar la resolucin de los CSP, si su construccin fuera necesaria, aadiendo para cada variable de cada restriccin sus valores mximos y mnimos (Rango Inicio, Rango Fin). Esta aportacin evitar crear problemas de satisfaccin de restricciones que de todas formas no van a ser satisfactibles. En el ejemplo, servir para eliminar todas las tuplas de la tabla de ImpuestosProvin-
ciales cuyo valor de la variable Precio no contenga valores entre 4.000 y 5.000.
De forma que nalmente podrn formar parte de la relacin de entrada las tuplas que contienen la restriccin del atributo ImpuestosProvinciales.Impuesto: 3.000
P recio < 6.000 AN D ImpP rov = 0.06 P recio + 53. Tras esta eliminacin, las
tuplas que hasta el momento estarn involucradas en la consulta son las mostradas en la gura 6.7. 3.
Atributos Restriccin. Analizar la parte del predicado de la seleccin donde se

establece la comparacin entre dos restricciones.
Slo se analizarn aquellas tuplas que tengan las mismas variables que la restriccin del predicado. Para el caso del ejemplo, donde se quieren obtener todas las tuplas tal que ImpuestosInternacionales.Impuestos < ImpInterNac=ImpNac1.25 slo se analizarn aquellas cuyo IdPas es 1, 2, 3, 7 y 8, ya que las dems no relacionan el ImpNac con el ImpInterNac. Una vez detectado este subconjunto de tuplas, ser
155
IdProvincia 1
0<Precio<3.000 AND ImpProv=0.05*Precio+50
IdProvincia 1 1
IdPas
1 2 3 4 5 6 7 8 9 10 11 12 13
ImpInterNac=ImpNac + 10 ImpInterNac=ImpNac+12 ImpInterNac=ImpNac*1.02 ImpInterNac=ImpProv + 100 ImpInterNac=ImpProv + 0.01Precio ImpInterNac=ImpProv + 0.02Precio ImpInterNac=ImpNac*1.20 ImpInterNac=ImpNac*1.0545 ImpInterNac=ImpProv ImpInterNac=ImpProv + 26 ImpInterNac=ImpProv + 98 ImpInterNac=Precio*0.025 ImpInterNac=Iva*Valor*0.025
Figura 6.7: Relaciones tras la eliminacin por atributos variables de restriccin (Paso II) necesario analizar las restricciones que la forman. Tambin las envolventes de las variables, donde se aproxima su comportamiento con los valores mximos y mnimos que pueden tomar, ayudan a conocer si una tupla con restricciones va a formar o no parte de la solucin. Para dos restricciones Cx y Cy , donde al menos una de ellas formar parte de una relacin de la base de datos, la relacin del rango entre una de las variables que tienen en comn puede ser de diferentes formas, como se muestra en la gura 6.8, lo que puede ayudar a conocer si cumplen o no un predicado. En el caso de que ambas restricciones formen parte de una relacin, el anlisis se realiza comparando cada una de las restricciones de una de las relaciones con todas las restricciones de la otra, lo que conllevar nm combinaciones, donde n y m representan el nmero de tuplas de cada una de las relaciones respectivamente. Un ejemplo podra ser un predicado que incluyera entre sus condiciones ImpuestosProvinciales.Impuestos
ImpuestosNaciones.Impuestos, donde se tendran que comparar todas las restricciones de los impuestos provinciales con cada una de las restricciones de los impuestos nacionales.
Cx
(a)
Cy
Cx
(b)
Cy
Cx
(c)
Cy
Cy
Cx (d)
Cx Cy
(e)
Figura 6.8: Tipos de relaciones entre los rangos de las variables de dos restricciones
156
En el trabajo de P. Veltri [150] se introdujo esta idea de aproximacin mediante cajas de consistencia, para mejorar los tiempos de evaluacin de consulta en las BDdR. Pero dicho trabajo tiene ciertas limitaciones, ya que slo dene las operaciones y tipos de relacin entre restricciones lineales que representan polgonos en dos dimensiones. Esta tesis se basa en dicha propuesta, pero extendiendo su uso a todo tipo de restriccin polinmica, que no tienen que representar un polgono, y para un nmero indeterminado de dimensiones. Adems, dicho trabajo aade las restricciones que describen la caja de consistencia a la restriccin que acota, mientras que una de la propuestas de esta tesis radica en no almacenar las envolventes como restriccin, sino como datos numricos clsicos con caractersticas relacionales, evitando as tener que construir y resolver el problema de satisfaccin de restricciones. Las opciones de relacin entre dos restricciones con respecto a sus envolventes, y para cada una de sus variables (v ), las mostradas en gura 6.8, son:
(a) Todos los valores que la variable v puede tomar en Cx son siempre menores
que los que puede tomar en Cy .
(b) El mayor valor que la variable v puede tomar en Cx es igual que el menor que
puede tomar en Cy .
(c) La variable v puede tomar un conjunto de valores que hacen satisfactible tanto
la restriccin Cx como la Cy , y los que exclusivamente hacen que Cx sea satisfactible son menores que los que pueden hacer Cy satisfactible.
(d) Para la variable v , todos los valores que puede tomar en Cx tambin son
solucin en Cy , aunque en Cy puede tomar ms valores.
(e) Todos los valores que v puede tomar en Cx tambin son soluciones de Cy , y
viceversa. Estas relaciones entre dominios ayudarn a conocer las relaciones entre restricciones descritas con las operaciones denidas en la seccin 4.5, evitando en algunos casos construir y resolver problemas de satisfaccin de restricciones. Generalizando dicha relacin para n variables, siendo v1 . . . vn las variables de las restricciones Cx y Cy , y sea Rango InicioCx (v1 ), . . ., Rango InicioCx (vn ) los menores valores que pueden tomar las variables en la restriccin Cx , Rango FinCx (v1 ), . . ., Rango FinCx (vn ) los valores mayores que puede tomar las variables en la restriccin
Cx , Rango InicioCy (v1 ), . . ., Rango InicioCy (vn ) los valores menores que puede
tomar las variables en la restriccin Cy , y Rango FinCy (v1 ), . . ., Rango FinCy (vn )
157
los valores mayores que pueden tomar las variables en la restriccin Cy . En los casos donde se aade la clusula FOR en la condicin, para determinar sobre qu conjunto de variables se realiza la comparacin, slo se analizarn dichas variables. Mientras que si tambin se utiliza la palabra reservada AND junto a FOR, se denir la igualdad semntica entre las variables involucradas en la condicin. Los distintos casos dependiendo de la operacin entre las restricciones Cx y Cy , y los rangos de sus variables son: Si v v1 , . . ., vn o v vi , . . . , vj (i 1 . . . n, j 1 . . . n y i = j ) en caso de que se utilice la clusula FOR {vi , . . . , vj }, se cumple que:
Rango FinCx (v ) < Rango InicioCy (v ) (Figura 6.8.a), entonces:

Cx <Cy y Cx Cy : cierto Cx >Cy y Cx Cy : falso Cx =Cy : falso Cx <>Cy : cierto Cx &Cy : falso Cx Cy y Cx Cy : falso Cx Cy y Cx Cy : falso
En la gura 6.9 se muestran ejemplos de relacin entre las cajas de satisfaccin, resaltadas con sombreado, para dos restricciones. En la gura 6.9.a se presenta un ejemplo donde Cx <Cy , lo que signica que todos los valores de v1 y v2 que hacen satisfactible Cx , son menores que los valores de dichas variables que hacen satisfactibe Cy . En la gura 6.9.b se presenta un ejemplo donde Cx <Cy FOR {v2 }, lo que signica que todos los valores de v2 que hacen satisfactible
Cx son menores que los valores de dicha variable que hacen satisfactible Cy .
Si v v1 , . . ., vn o v vi , . . . , vj (i 1 . . . n, j 1 . . . n y i = j ) en caso de que se utilice la clusula FOR {vi , . . . , vj }, se cumple que:
Rango FinCx (v ) = Rango InicioCy (v ) (Figura 6.8.b), entonces:

Cx <Cy : falso Cx Cy : cierto Cx >Cy y Cx Cy : falso Cx =Cy : falso
158
V2
V2
Cy
Cy
Cx
Cx
V1 C x (v1 3) + (v 2 2) 1 (v1 4) + (v 2 2) 2 1
2 2 2
V1 C x (v1 5 ) + (v 2 2) 1 (v1 6) + (v 2 2) 2 1
2 2 2
C y 2.25 * (v1 8) 2 + 9 * (v 2 5) 2 20.25 v 2 6.5 (0.3) * (v1 8) (a) (b)
Figura 6.9: Ejemplo de relacin entre restricciones en funcin de sus envolventes
Cx <>Cy : cierto Cx &Cy : No se tiene suciente informacin, hay que crear un CSP tal como
se explic en la subseccin 4.5.1
Cx Cy y Cx Cy : falso Cx Cy y Cx Cy : falso
Si v v1 . . . vn o v vi . . . vj (i 1 . . . n, j 1 . . . n y i = j ), en caso de que se utilice la clusula FOR {vi , . . . , vj }, se cumple que:
Rango FinCx (v ) > Rango InicioCy (v ) y Rango InicioCx (v ) < Rango InicioCy (v ) (Figura 6.8.c), entonces:
Cx <Cy y Cx Cy : falso Cx >Cy y Cx Cy : falso Cx =Cy : falso Cx <>Cy : cierto Cx &Cy : No se tiene suciente informacin, hay que crear un CSP tal como
Cx Cy y Cx Cy : falso Cx Cy y Cx Cy : falso
Si v vi , . . . , vj (i 1 . . . n, j 1 . . . n y i = j ) en caso de que se utilice la clusula (FOR {vi , . . . , vj } AND Cx .var=Cy .var AND . . .), se cumple que:
Rango FinCx (v ) > Rango InicioCy (v ) y Rango InicioCx (v ) < Rango InicioCy (v ) (Figura 6.8.c), entonces:
159
Cx <Cy FOR {vi , . . . , vj } y Cx Cy FOR {vi , . . . , vj }: No se tiene suciente

informacin, hay que crear un CSP tal como se explic en la subseccin 4.5.1
Cx >Cy FOR {vi , . . . , vj } AND . . . y Cx Cy FOR {vi , . . . , vj } AND . . .:

falso
Cx =Cy FOR {vi , . . . , vj } AND . . .: falso Cx <>Cy FOR {vi , . . . , vj } AND . . .: cierto Cx Cy FOR {vi , . . . , vj } AND . . . y Cx Cy FOR {vi , . . . , vj } AND . . .:
falso
Cx Cy FOR {vi , . . . , vj } AND . . . y Cx Cy FOR {vi , . . . , vj } AND . . .:

falso Para los ejemplos mostrados en la gura 6.10, la sentencia Cx
<
(Cy
F OR {v2 }) ser cierta exclusivamente para el caso 6.10.a, mientras que F OR {v2 } AN D Cx .v1 = Cy .v1 ) ser cierto para
la sentencia Cx < (Cy
los casos a y b de dicha gura. El problema es que para poder asegurar que
Cx < (Cy
F OR {v2 } AN D
Cx .v1 = Cy .v1 ) es cierto para el ejemplo
6.10.b, ser necesario crear y resolver un CSP, no siendo suciente con analizar las envolventes (marcada con lnea discontinua en la gura).
v2
v2
Cy Cy Cx Cx
(a)
v1
(b)
v1
Figura 6.10: Ejemplo de comparacin entre restricciones Si v v1 , . . . , vn o v vi , . . . , vj (i 1 . . . n, j 1 . . . n y i = j ) en caso de que se utilice la clusula FOR {vi , . . . , vj }, se cumple que:
Rango InicioCx (v ) > Rango InicioCy (v ) y Rango FinCx (v ) < Rango FinCy (v ), lo que signica que el dominio de Cx est incluido en el Cy (Figura 6.8.d), entonces:
160
Cx <Cy y Cx Cy : falso Cx >Cy y Cx Cy : falso Cx =Cy : falso Cx <>Cy : cierto Cx &Cy : No se tiene suciente informacin, hay que crear un CSP tal como
Cx Cy y Cx Cy : No se tiene suciente informacin, hay que crear un CSP

tal como se explic en la subseccin 4.5.1

tal como se explic en la subseccin 4.5.1 Si v v1 , . . . , vn o v vi , . . . , vj (i 1 . . . n, j 1 . . . n y i = j ) en caso de que se utilice la clusula FOR {vi , . . . , vj }, se cumple que:
Rango InicioCx (v ) = Rango InicioCy (v ) y Rango FinCx (v ) = Rango FinCy (v ) (Figura 6.8.e), entonces:
Cx <Cy y Cx Cy : falso Cx >Cy y Cx Cy : falso Cx =Cy y Cx <>Cy No se tiene suciente informacin, hay que crear un
CSP tal como se explic en la subseccin 4.5.1

tal como se explic en la subseccin 4.5.1

tal como se explic en la subseccin 4.5.1 En la gura 6.11.a se presenta un ejemplo donde la caja de valores satisfactibles de Cx est incluida en la de Cy y realmente todas las soluciones de Cx lo son tambin de Cy . Por otro lado en la gura 6.11.b se presenta un ejemplo donde, pese a que el rango de Cx es igual que el de Cy , no todas las soluciones de Cx lo son de Cy . En el caso de las operaciones de igualdad e inclusin, en funcin de los rangos ser posible asegurar que dichas comparaciones no se cumplen, pero para asegurar que se cumplen siempre ser necesario crear y resolver un problema de satisfaccin de restricciones. Si no se cumple ninguna de las opciones mencionadas sobre los rangos de las variables, la salida ser falso. Esto se tendr que hacer para todas las variables
161
V2 Cy Cx
V2 Cy
Cx
V1 (a) (b)
V1
Figura 6.11: Ejemplo de restricciones de las restricciones involucradas en el predicado. Si no existe la variante F OR se har para todas las variables, hasta que se encuentra una con la que la evaluacin devuelva falso, o se hayan estudiado todas las variables involucradas en las restricciones. En caso de que nalmente devuelva cierto, signica que las tuplas a las que pertenecen las restricciones formarn parte de la relacin de salida. Continuando con el ejemplo de la gura 6.7, se analizarn las tuplas de la relacin
ImpuestosInternacionales con IdPas igual a 1, 2, 3, 7 y 8, ya que son los nicos que

comparten las variables con la restriccin del predicado. En la gura 6.12 se muestra grcamente el contenido del atributo restriccin Impuestos de la relacin Im-
puestosInternacionales. Analizar dichas restricciones para seleccionar aquellas que cumplan ImpuestosInternacionales.Impuestos < (ImpInterN ac = ImpN ac 1,25 FOR {Im-
pInterNac} AND ImpuestosInternacionales.Impuestos.ImpNac=ImpNac), signica encontrar las restricciones donde para un valor de la variable ImpNac, siempre su impuesto internacional ImpInterNac ser menor que el que pueda tomar en la restriccin {ImpInterN ac = ImpN ac 1,25}. En este caso es posible discriminar las restricciones de las tuplas con idPas 1 y 2, ya que el mnimo valor que puede tomar la variable
ImpInterNac en ambas, es mayor que el que puede tomar la misma variable en la restriccin de entrada {ImpInterN ac = ImpN ac 1,25}. Para las restantes restricciones, no ser suciente analizar exclusivamente las envolventes, siendo necesario construir un CSP comparando cada una de las restricciones de ImpuestosInternacionales.Impuestos con {ImpInterN ac = ImpN ac 1,25}, para conocer las tuplas donde se cumple la condicin. La resolucin de los CSP informar que las restricciones que cumplen la condicin son las que pertenecen a las tuplas con idPas igual a 3, 7 y 8, que son las mostradas en la gura 6.13.
162
35 Impuestos Internacionales 30 25 20 15 10 5 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Impuestos Nacionales ImpInterNac=ImpNac+10 (idPas 1) ImpInterNac=ImpNac+12 (idPas 2) ImpInterNac=ImpNac*1.25 (Restriccin de Entrada) ImpInterNac=ImpNac*1.02 (IdPas 3) ImpInterNac=ImpNac*1.20 (idPis 7) ImpInterNac=ImpNac*1.0545 (idPas 8)
Figura 6.12: Representacin de restricciones

0<Precio<3.000 AND ImpProv=0.05*Precio+50
IdProvincia 1
IdProvincia 1 1
IdPas
3 7 8
ImpInterNac=ImpNac*1.02 ImpInterNac=ImpNac*1.20 ImpInterNac=ImpNac*1.0545
Figura 6.13: Relaciones tras la eliminacin por construccin de CSP (Paso III y IV)
6.3. Implementacin del Producto Cartesiano

El producto cartesiano entre dos relaciones devuelve una nueva relacin formada por la unin conjuntiva de las tuplas de cada una de las relaciones de entrada. Por lo que la implementacin de esta operacin no necesita de un tratamiento especial pese a que las relaciones contengan atributos restriccin. La salida de la consulta propuesta en la seccin 6.2 obtendr las tres relaciones mostradas en la gura 6.13, para realizar el producto cartesiano de ellas, ser necesario efectuar dos productos cartesianos para obtener una nica relacin de salida. Siendo ImpuestosProvinciales (R1 ), ImpuestosNacionales (R2 ) e
ImpuestosInternacionales (R3 ), se tendrn que realizar dos veces el producto cartesiano,

por ejemplo ((R1 R2 )R3 ) o (R1 (R2 R3 )), ambos equivalentes. Pese a que estas relaciones estn formadas por atributos restriccin, se har como en el lgebra relacional clsica, concatenando horizontalmente cada tupla de una relacin con las tuplas de la otra relacin. Para el ejemplo nalmente se obtendr una nueva relacin, presentada en la gura 6.14.
Implementacin de la Proyeccin
163
ImpuestosProvinciales. idProvincia
1 1 1 1 1 1
ImpuestosProvinciales. Impuestos 0<=Precio<3.000 AND ImpProv=0.05*Precio+50 0<=Precio<3.000 AND ImpProv=0.05*Precio+50 0<=Precio<3.000 AND ImpProv=0.05*Precio+50 0<=Precio<3.000 AND ImpProv=0.05*Precio+50 0<=Precio<3.000 AND ImpProv=0.05*Precio+50 0<=Precio<3.000 AND ImpProv=0.05*Precio+50
ImpuestosNacionales. idProvincia
1 1 1 1 1 1
ImpuestosNacionales. Impuestos 0<=ImpProv<500 AND ImpNac=ImpProv + 0.02Precio 0<=ImpProv<500 AND ImpNac=ImpProv + 0.02Precio 0<=ImpProv<500 AND ImpNac=ImpProv + 0.02Precio 500<ImpProv AND ImpNac=ImpProv + 0.01Precio 500<ImpProv AND ImpNac=ImpProv + 0.01Precio 500<ImpProv AND ImpNac=ImpProv + 0.01Precio
ImpuestosInterNacionales. idPais
3 7 8 3 7 8
ImpuestosInterNacionales. Impuestos ImpInterNac=ImpNac*1.02 ImpInterNac=ImpNac*1.20 ImpInterNac=ImpNac*1.0545 ImpInterNac=ImpNac*1.02 ImpInterNac=ImpNac*1.20 ImpInterNac=ImpNac*1.0545
Figura 6.14: Salida del ejemplo tras el Producto Cartesiano
6.4.
La operacin de proyeccin obtiene un subconjunto vertical de la relacin de entrada, lo que signica un subconjunto de los atributos de la relacin. Dependiendo del tipo de atributo sobre el cual se realice la proyeccin (clsicos (univaluados), atributos restriccin o variable de restriccin), se obtendrn diferentes salidas y se tratarn de diferente manera. En el caso de la proyeccin sobre atributos de tipo restriccin o de tipo clsico, el comportamiento de la proyeccin ser igual que en el lgebra relacional clsica, la diferencia fundamental est cuando la proyeccin hace referencia a las variables atributos restriccin. Para obtener un subconjunto de las variables que aparecen en las restricciones, no slo es necesario tratar las restricciones en las que dichas variables aparecen, tambin es necesario conocer las restricciones con variables que a su vez estn relacionadas con ellas. Volviendo al ejemplo de la gura 6.14, si se quiere obtener el Im-
puesto Internacional que se paga en funcin del Precio, signicar hacer una proyeccin
donde se obtienen las variables ImpuestosProvinciales.Impuestos.Precio e ImpuestosIn-
ternacionales.Impuestos.ImpInterNac. Obtener la relacin simblica entre estas variables

signica tener que eliminar las variables ImpNac e ImpProv, las cuales aparecen en el atributo restriccin ImpuestosNacionales.Impuesto. Si en lugar de una proyeccin simblica se quisiera obtener valores numricos de las variables, tambin se tendran que tener en cuenta las restricciones del atributo restriccin ImpuestosNacionales.Impuesto, ya que restringen los valores que puede tomar la variable ImpProv y por lo tanto los que pueden tomar ImpNac e ImpInterNac. Dependiendo de si la salida de la evaluacin de la proyeccin es intensiva o extensiva (simblica o numrica), se utilizar uno de los dos algoritmos que se proponen en esta seccin con respecto a la bsqueda de las restricciones relacionadas con los atributos de la proyeccin. En el caso de la obtencin de las instancias de las variables mediante
164
resolucin numrica, ser necesario encontrar todas las restricciones que estn involucradas con las variables de la proyeccin directa o indirectamente. Mientras que para la proyeccin simblica se buscarn los conjuntos de restricciones que permitan realizar eliminacin o sustitucin de variables, lo que signica que ser posible devolver nuevas restricciones donde slo las variables de la proyeccin estn involucradas. En este tesis se denen dos tipos de proyeccin con respecto a cmo se realiza esta bsqueda de restricciones relacionadas con los atributos variable de restriccin: Proyec-
cin Horizontal y Proyeccin Vertical. Dependiendo de si la bsqueda de restricciones

relacionadas por variables se realiza por tuplas o por columnas, se utilizar un caso u otro. Se denomina Proyeccin Horizontal a la bsqueda de restricciones relacionadas con la proyeccin cuando las restricciones pertenezcan a la misma tupla (6.15.a). Para la proyeccin horizontal se realizar una bsqueda de restricciones relacionadas por cada Gi
G1 . . . Gn . Por otra parte, la Proyeccin Vertical realizar la bsqueda de restricciones

relacionadas entre las distintas tuplas de un mismo atributo restriccin (6.15.b). Para la proyeccin vertical se realizar una bsqueda de restricciones relacionadas por cada Gi
G1 . . . Gm .
Relacin Relacin
G1
...
Gn G1
(a) Proyeccin Horizontal
...
(b) Proyeccin Vertical
Gm
Figura 6.15: Tipos de Proyeccin: Horizontal y Vertical Los atributos variable de restriccin que participen en la proyeccin, denirn si la operacin se realiza con las restricciones de una misma tupla (horizontal), o con las restricciones de una misma columna (vertical). Si todas las variables pertenecen a un mismo atributo restriccin, la proyeccin ser vertical por defecto, mientras que si pertenecen a ms de un atributo restriccin se realizar la proyeccin horizontal. En el caso de que aparezca una sola variable como atributo en la proyeccin, se denir horizontal por de-
165
fecto. Estas deniciones por defecto se pueden variar utilizando las palabras reservadas
HORIZONTAL y VERTICAL.
El objetivo primero en la proyeccin ser obtener todos los conjuntos de restricciones que contengan las variables que aparezcan en la consulta, o que estn relacionadas con dichas variables. La denicin formal de qu es un Conjunto de Restricciones Rela-
cionadas con la Proyeccin depender de si la evaluacin es simblica o numrica, y de si

la proyeccin es horizontal o vertical.
Restricciones para la Proyeccin Horizontal: Conjunto de restricciones

pertenecientes a una misma tupla. Una relacin con atributos restriccin tendr
G1 . . .Gi . . .Gn conjuntos de restricciones, donde cada Gi est formado por todas las
restricciones de la tupla i-sima de la relacin, para sus n tuplas.
Restricciones para la Proyeccin Vertical: Conjunto de restricciones

pertenecientes a una misma columna (atributo restriccin). Una relacin con atributos restriccin tendr G1 . . .Gi . . .Gm , donde cada Gi est formado por todas las restricciones del i-simo atributo restriccin de la relacin, para sus m atributos restriccin.
6.4.1. Deteccin de grupos de restricciones relacionadas para la Proyeccin Numrica

Cuando la proyeccin es numrica, todas las restricciones que tengan variables relacionadas de forma directa o indirecta con las variables que aparezcan en la proyeccin participarn en el problema de satisfaccin u optimizacin de restricciones que se crear para su evaluacin. Que una restriccin est relacionada de forma directa con una variable signica que dicha variable pertenece a la restriccin, mientras que si est relacionada de forma indirecta signicar que la restriccin tienen una variable en comn con otra restriccin que est relacionada de forma directa o indirecta con la variable de la proyeccin. El caso de la representacin simblica no es igual, precisamente por la representacin simblica del valor de las variables mediante restricciones. Para ver ms claramente la diferencia entre las restricciones relacionadas para los dos tipos de proyeccin se utiliza el ejemplo de la gura 6.16. En el caso de obtener la representacin simblica de las variables R2 .ImpProv, R2 .Precio y R3 .ImpInterNac, slo ser necesario realizar la eliminacin
166
simblica de la variable R2 .ImpNac trabajando con las restricciones R2 y R3 , obteniendo una nueva restriccin {49.0196ImpInterN ac + 50 ImpP rov + P recio = 0}, en este caso utilizando las Bases de Grbner. Pero si se quiere conocer los valores instanciados de dichas variables es necesario incluir R1 entre las restricciones relacionadas, ya que la variable ImpNac depende de la variable ImpProv, cuyos valores no slo estn restringidos por la restriccin R2 , tambin por R1 .
R1 0<Precio<3.000 AND ImpProv=0.05*Precio+50 R2
Precio, ImpProv
R3 0<=ImpProv<500 AND ImpNac=ImpProv + 0.02Precio

ImpNac
ImpInterNac=ImpNac*1.02
Figura 6.16: Ejemplo de conjunto de restricciones El algoritmo propuesto para encontrar todas las restricciones relacionadas con las variables de una proyeccin numrica, est basado en la representacin de cada conjunto de restricciones Gi , independientemente de que sea proyeccin vertical y horizontal, como un grafo. Las restricciones se representan como nodos y las variables como aristas, de forma que existir una arista entre dos nodos si las restricciones que representan dichos nodos tienen una variable en comn, y dicha variables no est instanciada en el predicado. De esta idea de deriva la denicin:
Denicin 6.1: Conjunto de Restricciones Relacionadas por Variables (CRRV) para la Proyeccin Numrica. Mximo conjunto de restricciones donde al menos
una variable de cada restriccin afecta directa o indirectamente a las variables de la proyeccin. O lo que es lo mismo, una componente conexa en los trminos anteriormente expuestos.
6.4.2. Deteccin de grupos de restricciones relacionadas para la Proyeccin Simblica

Como se comenta en el captulo 5, la proyeccin puede obtener datos intensivos mediante tcnicas de sustitucin o eliminacin de variables. Independientemente de la tcnica que se utilice ser necesario conocer las relaciones entre las restricciones en funcin de las variables que las forman y las que se establecen en la proyeccin, lo que tambin depender de si la proyeccin es vertical u horizontal. La nica diferencia entre la proyeccin horizontal vertical y horizontal son las restricciones involucradas en dicha bsqueda.
167
Antes de denir qu es un grupo de restricciones relacionadas por variables en una proyeccin simblica, son necesarias algunas notaciones previas. Siendo c1 , . . ., cn todas las restricciones de un conjunto Gi , e independientemente de que dicho grupo est formado por restricciones de la misma tupla o del mismo atributo restriccin, y ci , . . ., cj un subconjunto de dichas restricciones:
Variables(ci , . . . , cj ). La unin de las variables de las restricciones ci , . . ., cj sin

repeticin.
Variables(Q, {ci , . . . , cj }). La unin de las variables sin repeticin de las restricciones ci , . . ., cj que aparecen en la consulta Q. Partiendo de dicha notacin, se buscar un conjunto de restricciones que estn relacionadas entre s por compartir variables que tengan que ser eliminadas. Para un conjunto de restricciones Gi formado por todas las restricciones de una tupla {c1 , . . ., cn }, un subconjunto Gi ' formada por las restricciones {ci , . . ., cj } {c1 , . . ., cn }, se le denominar
Conjunto de Restricciones Relacionadas por Variables (CRRV) para la Proyeccin Simblica si, cada variable de las restricciones de Gi ': aparece en la proyeccin; o
est al menos en dos restricciones de Gi '; o slo pertenece a una restriccin de Gi . Adems este conjunto debe ser mnimo, lo que signica que no puede existir ningn CRRV incluido dentro de otro.
Denicin 6.2: Conjunto de Restricciones Relacionadas por Variables (CRRV) para la Proyeccin Simblica. Gi ' ser un Conjunto de Restricciones Relacionadas por Variables si:
Siendo Gi ' {ci , . . ., cj } Gi {c1 , . . ., cn } Gi 'Gi
ck Gi ' v Variables(ck ) | v / Variables(Q, ck )

(v Variables(Gi '{ck })) ( cl {Gi ck } | v Variables(cl ))
Variables(Q,{ci , . . ., cj }) =
G Gi ' | G sea un CRRV
168
Ejemplo de Proyeccin Horizontal

Este tipo de proyeccin se har cuando los atributos de la proyeccin pertenecen a distintos atributos restriccin, lo que signica que se realizar la bsqueda de restricciones relacionadas entre las restricciones de una misma tupla. Un ejemplo de proyeccin simblica horizontal sobre la relacin de la gura 6.14 puede ser:
SELECT ImpuestoInternacionales.id, CONSTRAINTS (ImpuestosProvinciales.Impuestos.ImpInterNac, ImpuestosInternacionales.Impuestos.Precio) FROM ImpuestosProvinciales, ImpuestosInternacionales
Lo que signica que un CRRV estar formado por un conjunto de restricciones de una misma tupla, donde sus variables pertenecen a las variables de la proyeccin Q, o aparecen en otra restriccin de dicho conjunto, o no aparecen en ninguna restriccin de dicha tupla. El algoritmo que obtendr los CRRV para la proyeccin simblica tambin se basa en la representacin de cada conjunto de restricciones Gi como un grafo, donde las restricciones se representan como nodos y las variables como aristas, de forma que existir una arista entre dos nodos si las restricciones que representan dichos nodos tienen una variable en comn que no pertenezca a la proyeccin. Para buscar la similitud con la teora de grafos, al igual que para la proyeccin numrica, primero se buscarn las componentes conexas pero con la diferencia de que las variables de la proyeccin no se representarn como aristas. El segundo paso ser buscar los subconjuntos mnimos de componentes que permitan eliminar las variables que no aparecen en la proyeccin. En la gura 6.17 se muestran los conjuntos de restricciones para cada una de las tuplas del ejemplo de la gura 6.14, junto a la relacin entre las distintas restricciones y las variables que las relacionan. Los CRRV del ejemplo para las variables de la proyeccin Precio e ImpIn-
terNac sern: {R1 , R7 , R13 }, {R2 , R8 , R14 }, {R3 , R9 , R15 }, {R4 , R10 , R16 }, {R5 , R11 , R17 }
y {R6 , R12 , R18 }, ya que forman un conjunto de restricciones donde todas las variables que no aparecen en la consulta pertenecen a otra restriccin de dicho conjunto. Los detalles relativos al algoritmo estn descritos en el apndice A.
169
R1 0<Precio<3.000 AND ImpProv=0.05*Precio+50 R2 0<Precio<3.000 AND ImpProv=0.05*Precio+50 R3 0<Precio<3.000 AND ImpProv=0.05*Precio+50 R4 0<Precio<3.000 AND ImpProv=0.05*Precio+50 R5 0<Precio<3.000 AND ImpProv=0.05*Precio+50 R6 0<Precio<3.000 AND ImpProv=0.05*Precio+50
R7
Precio, ImpProv
0<=ImpProv<500 AND ImpNac=ImpProv + 0.02Precio
R13
ImpNac
Precio, ImpProv
R8
ImpNac
R14
R9
Precio, ImpProv
R15
ImpNac
10 Precio, ImpProv
500<ImpProv AND ImpNac=ImpProv + 0.01Precio
ImpNac
R16
R11 Precio, ImpProv
ImpNac
R17
R12 Precio, ImpProv
ImpNac
R18
Figura 6.17: Grafo de Restricciones de la Relacin para Proyeccin Horizontal
Ejemplo de Proyeccin Vertical

Una vez explicada la proyeccin horizontal, es fcil introducir la proyeccin vertical, ya que en lo nico que se diferencian es que en la proyeccin vertical las restricciones sobre las que se realiza la bsqueda pertenecen a un mismo atributo restriccin. En la gura 6.18 se presenta un ejemplo muy similar al anterior con respecto a las restricciones, con la diferencia de que todas las restricciones estn en una misma columna. En este caso se realizar una proyeccin vertical, donde las restricciones han sido nombradas para que sea ms fcil la explicacin de las relaciones entre variables y restricciones.
Impuestos R1 R2 R3 R4 R5 0<=Precio<3.000 AND ImpProv=0.05*Precio+50 0<=ImpProv<500 AND ImpNac=ImpProv + 0.02Precio 500<ImpProv AND ImpNac=ImpProv + 0.01Precio ImpInterNac=ImpNac*1.02 ImpInterNac=ImpNac*1.0354
Figura 6.18: Ejemplo para realizar proyeccin Vertical Un ejemplo de proyeccin sobre la relacin de la gura 6.18 puede ser:
170
SELECT CONSTRAINTS (ImpuestosInternacionales.Impuestos.ImpInterNac, ImpuestosInternacionales.Impuestos.Precio) FROM ImpuestosInternacionales
En la gura 6.19 se muestra el grafo donde se representan las restricciones como nodos y las variables que las relacionan como aristas.
{ImpNac} {Precio, ImpProv} {ImpNac, ImpProv, Precio}
R2
Na c}
{Im pN
R4
{ImpNac, ImpInterNac}
}
R1
p {Im
ac
{Precio, ImpProv}
R3
{ImpNac}
R5
Figura 6.19: Grafo del Ejemplo para la proyeccin Vertical Pese a que slo hay una componente conexa en este grafo, existen diferentes CRRV, ya que cumplen la denicin 6.2. Los CRRV para este ejemplo son: {R1 , R2 , R4 }, {R1 , R2 , R5 }, {R1 , R3 , R4 } y {R1 , R3 , R5 }.
Eliminacin o Sustitucin Simblicas de Variables

Cuando un CRRV tiene una variable que slo aparece en una restriccin del conjunto
Gi , y no pertenece a la proyeccin, no ser posible realizar sustitucin simblica, ya que

dicha variable no puede ser representada mediante otras de la proyeccin. Para los casos donde slo se quieran obtener nuevas restricciones utilizando sustitucin de variables, los CRRV no podrn estar formados con este tipo de variables. A este nuevo CRRV se le denominar Conjunto Completo de Restricciones Relacionadas por Variable
(CCRRV), y ser de la forma: Denicin 6.3: Conjunto Completo de Restricciones Relacionadas por Variables (CCRRV). G' ser un Conjunto Completo de Restricciones Relacionadas por
Variables si:
Siendo Gi ' {ci , . . ., cj } Gi {c1 , . . ., cn } Gi 'Gi
ck Gi '
171
v Variables(ck ) | v / Variables(Q, ck )
(v Variables(Gi '{ck }))
La sintaxis de este tipo de proyeccin es:

SELECT FULL CONSTRAINTS (<lista de Variables>) FROM relacin WHERE predicado
Esta nueva denicin permite diferenciar al usuario cundo quiere hacer eliminacin de variables, y cundo quiere hacer sustitucin de variables siempre que sea posible. Si aparece la palabra reservada FULL y se obtienen los CCRRV, signicar que se quiere hacer sustitucin de variables, ya que todas las variables que no aparecen en la proyeccin pueden ser sustituidas por variables de la proyeccin. Mientras que si no aparece dicha palabra reservada, signicar que al usuario no le importa obtener nuevas restricciones simplemente haciendo eliminacin de variables, utilizando Descomposicin Algebraica Cilndrica y eliminacin de cuanticadores. Esta operacin es especialmente interesante en casos de estudios como la diagnosis basada en modelos, el cual se explicar con detalle en el siguiente captulo.
6.4.3. Seleccin de la tcnica para evaluar la proyeccin

Una vez conocidos los Conjuntos de Restricciones Relacionadas por Variables, es necesario construir un modelo y seleccionar la tcnica que lo resolver. Un tipo de proyeccin u otra, depender de la sintaxis que utilice el usuario cuando realice la consulta. Dentro de esta divisin (intensiva y extensiva) se utilizarn distintas tcnicas en funcin de los conjuntos de restricciones relacionadas con las variables que se quieran obtener. Recordando que la sintaxis de la proyeccin es de la forma:
SELECT [ [FULL] CONSTRAINTS | VALUES | MIN VALUE | MAX VALUE] (<lista de atributos>) FROM relacin WHERE predicado
172
Las palabras reservadas MIN y MAX, denotarn la construccin de un problema de optimizacin de restriccines, mientras que la palabra reservada VALUES denir el deseo del usuario de conocer los valores instanciados de las variables. Por otra parte, la palabra reservada CONSTRAINTS describe la necesidad de utilizar tcnicas simblicas para mostrar el resultado en forma de restriccin. Para conocer qu tcnica es necesaria, y cmo construir el modelo con ms detalle, se utiliza el rbol de decisin presentado en la gura 6.20, en funcin de la proyeccin de entrada y a los CRRV obtenidos en la seccin 6.4.1 y 6.4.2.
Se pide el mnimo o el mximo de una variable? SI Se construye un COP que ser resuelto con JSolver NO Es una proyeccin Extensiva? SI Se construye un CSP que ser resuelto con JSolver SI Todas las restricciones son de igualdad? SI Se resuelve utilizando las Bases Grbner NO Se resuelve con Descomposicin Algebraica Cilndrica NO Se puede hacer sustitucin simblica (es un CCRRV)? NO Se resuelve con Descomposicin Algebraica Cilndrica
Figura 6.20: rbol de decisin para construir el modelo y decidir qu tcnica lo resolver La secuencia de decisiones que se reejan en dicho rbol son:
Se pide el mnimo o el mximo de una variable en la consulta? La respuesta

a esta pregunta ser s, cuando en la proyeccin aparezcan las palabras MIN VALUE o MAX VALUE. Este tipo de problema se resuelve contruyendo un COP.
Es una proyeccin Extensiva? La respuesta a esta pregunta ser s, cuando en

la proyeccin aparezca la palabra reservada VALUES, lo que signicar que se buscan valores concretos de las variables, lo que se resolver con la construccin de un CSP. Si aparecen la palabra reservada CONSTRAINTS la respuesta ser no, y se resolver la proyeccin de manera simblica.
Se puede hacer sustitucin simblica? La respuesta a esta pregunta ser s

cuando el conjunto de restricciones relacionadas por variables es completo (CCRRV),
173
lo que signica que todas las variables o estn al menos en dos restricciones o pertenecen a la proyeccin y pueden participar en la solucin. Si se utiliza la palabra reservada FULL slo los CCRRV sern tratados, y los CRRV sern ignorados. Si no aparece dicha palabra, se tratarn tanto los CRRV como los CCRRV.
Todas las restricciones son de igualdad? Si todas las restricciones estn etiquetadas como LinEq o PolEq, signica que se pueden utilizar las Bases de Grbner para obtener la nueva restriccin como resultado, en caso contrario se utilizar la Descomposicin Algebraica Cilndrica junto a la eliminacin de cuanticadores.
Construccin de Modelos (Hojas del rbol de decisin)

Una vez conocidos los CRRV, o los CCRRV, y qu tipo de modelo hay que construir, es el momento de construir dicho modelo. Para la problemtica propuesta existen cuatro tipos: Problemas de Optimizacin de Restricciones, Problemas de Satisfaccin de Restricciones, sustitucin simblica con Grbner, o eliminacin de cuanticadores con la Descomposicin Algebraica Cilndrica. 1.
Construccin de Problemas de Optimizacin de Restricciones

Como ya se ha mencionado en este mismo captulo, la sintaxis de este tipo de proyeccin ser de la forma:
SELECT [MIN VALUE | MAX VALUE] (<atributo variable de restriccin>) FROM relacin WHERE predicado
Denindose Lista CRRV como la lista con los CRRV obtenidos en la seccin 6.4.1 (CRRV1 . . . CRRVn ), y teniendo en cuenta si existen variables instanciadas en el predicado de la forma relacin.AtribRestriccin.variable=constante o
relacin.AtribRestriccin.variable=relacin.AtribRestriccin.variable,
se construir un COP. Se nombrarn las restricciones de cada CRRV de la lista de la forma CRRV1 .Restricciones . . . CRRVn .Restricciones. El COP que se construye ser una combinacin disyuntiva de cada CRRV, mientras que entre las restricciones de un mismos CRRV existir una relacin conjuntiva. Esto har posible obtener el
174
mximo o mnimo valor de la variable analizando todos los CRRV. La estructura del COP ser de la forma:
aadir al COP las variables

{Variables(CRRV1 .Restricciones) . . . Variables(CRRVn .Restricciones)}
aadir al COP
(Maximize(atributo variable de restriccin)
Minimize(atributo variable de restriccin))
aadir al COP las restricciones

{CRRV1 .Restricciones . . . CRRVn .Restricciones} relacin.AtribRestriccin.variable=constante
...
relacin.AtribRestriccin.variable=relacin.AtribRestriccin.variable
Este COP se resolver con JSolverT M [78], aunque como se ha comentado en el captulo anterior se podra utilizar otro resolutor. La salida que se mostrar al usuario ser slo el valor de la variable objetivo de la proyeccin. 2.
Construccin de Problemas de Satisfaccin de Restricciones

Para obtener valores instanciados de un conjunto de variables se construir un problema de satisfaccin de restricciones, que ser similar a la construccin de problemas de optimizacin de restricciones con respecto al CRRV, pero sin incluir el objetivo de maximizar o minimizar. Como ya se ha mencionado en este mismo captulo, la sintaxis de este tipo de proyeccin ser de la forma:
SELECT VALUES (<lista de Variables>) FROM relacin WHERE predicado
Al sario do
igual
que en
en
la
optimizacin si existen
de
variables,
Lista CRRV
en el
represenpredicao
ta la lista de CRRV obtenidos en la seccin 6.4.1. Tambin es necetener de la cuenta variables instanciadas forma
relacin.AtribRestriccin.variable=constante
175
relacin.AtribRestriccin.variable=relacin.AtribRestriccin.variable.
Con toda esta informacin, se construir un CSP de la forma:
aadir al CSP las variables

{Variables(CRRV1 .Restricciones) . . . Variables(CRRVn .Restricciones)}
aadir al CSP las restricciones

{CRRV1 .Restricciones . . . CRRVn .Restricciones} relacin.AtribRestriccin.variable=constante
...
relacin.AtribRestriccin.variable=relacin.AtribRestriccin.variable
Para la arquitectura que se propone en esta memoria de tesis, este CSP se resolver con JSolverT M [78] y la salida que se mostrar al usuario ser el valor de las variables que pertenecen a la lista de Variables. Como es posible que el nmero de soluciones sea muy grande o incluso innito, por defecto se presentar slo una solucin, aunque se podr modicar en la misma sentencia para N tuplas, de la forma:
SELECT VALUES[N](<lista de Variables>) FROM relacin WHERE predicado
3.
Construccin de Problemas de Eliminacin de Variables

Este tipo de problemas se construir cuando se quiere obtener una relacin simblica entre variables en lugar de sus valores concretos. Se aplicar cuando los CRRV no son completos, o existe al menos una inecuacin polinmica entre las restricciones del CRRV. La sintaxis de este tipo de proyeccin ser de la forma:
SELECT CONSTRAINTS(<lista de Variables>) FROM relacin WHERE predicado
Siendo Lista CRRV el conjunto de restricciones relacionadas obtenido en la seccin 6.4.2 en funcin de la lista de variables de la proyeccin, se construir una funcin que ser resuelta con Mathematica v.5 T M . El prototipo de la funcin es el siguiente:
Reduce [ Exists[{Variables que se quieren eliminar }, restricciones],

{lista de todas las Variables} ]
176
En este caso, para cada CRRVi {CRRV1 , . . ., CRRVn }, los cuales son los CRRV que forman Lista CRRV, se construir:
Reduce [ Exists
[{Variables(CRRVi .Restricciones)Variables(Q, CRRVi .Restricciones)},
CRRVi .Restricciones], {Variables(CRRVi )}
]
La construccin de esta sentencia se genera de forma automtica y transparente para el usuario, como en el resto de los modelos. La salida que se mostrar al usuario ser el valor de salida de dicha funcin. 4.
Construccin de Problemas de Sustitucin Simblica con Grbner

En este caso, todas las variables que aparecen en una sola restriccin tambin aparecen en la consulta, por lo que estamos seguros de poder hacer sustitucin simblica sin perder informacin de las variables de dicha consulta, lo que signica que los CRRV son completos. Adems las restricciones tienen que estar formadas por ecuaciones lineales o polinmicas, siendo la sintaxis de la sentencia de la forma:
SELECT FULL CONSTRAINTS (<lista de Variables>) FROM relacin
La sintaxis de la funcin, que tambin ser resuelta por Mathematica v.5
TM
, es:
GroebnerBasis({Restricciones polinmicas de igualdad}, {Variables de salida}, {Variables a eliminar})

Tras obtener los CCRRV, se construir de forma automtica un modelo para cada CCRRVi Lista CRRV de la forma:
GrbnerBasis({CRRVi .Restricciones}, {Variables(Q, CRRVi .Restricciones)}, {Variables(CRRVi .Restricciones)Variables(Q, CRRVi .Restricciones)})
La salida que se mostrar al usuario ser el valor de salida de dicha funcin para cada uno de los CCRRV, ya a los CRRV que no sean completos no se les puede hacer sustitucin de variables.
Implementacin de la Operacin de Unin
177
6.5.
Implementacin de la Operacin de Unin
Esta operacin tiene dos relaciones como parmetros de entrada (R1 , R2 ) donde ambas relaciones tienen que ser equivalente con respecto a la unin. La relacin que se obtiene como salida tendr todas las tuplas de R1 y R2 sin repeticin. En el caso de que las relaciones que se vayan a unir tengan atributos restriccin, ser necesario una comprobacin especial de dichos atributos para que no aparezcan tuplas duplicadas en la relacin de salida. Para hace ms eciente la implementacin, se separar el tratamiento de los atributos univaluados de los atributos restriccin. Los pasos de dicha comprobacin se realizar entre todos los pares de tuplas t1 R1 y t2 R2 , y sern: 1. Si todos los atributos clsicos entre dos tuplas son iguales, se pasa al paso 2, en caso contrario ambas tuplas formarn parte de la solucin. Esta comprobacin se har mediante el lgebra relacional clsica. 2. Si todas las restricciones de ambas tuplas tienen las mismas variables, se pasar al paso 3, en caso contrario ambas tuplas formarn parte de la solucin. Esta comprobacin se har utilizan exclusivamente el lgebra relacional clsica, ya que dicha informacin est almacenada en la tabla Restricciones/Variables. 3. Entre las tuplas se comparan sus atributos restriccin como se ha explicado en la seccin 4.7. En dicha seccin se analiza la unin de tuplas utilizando la operacin de inclusin entre restricciones (), lo que gracias a tener almacenado el mnimo y mximo valor de cada variable se puede hacer de una manera ms eciente, evitando la creacin de CSP. Si existe ms de un atributo restriccin en las relaciones R1 y
R2 se comparar cada i-simo atributo restriccin de t1 con el atributo restriccin

i-simo de t2 , existiendo dos casos: Si existe alguna restriccin perteneciente a t1 con soluciones que no est en el atributo restriccin de t2 , y viceversa (los casos a y b de la gura 6.21): t1 y t2 formarn parte de la relacin de salida En caso contrario, signicar que todas las relaciones sern de la forma c o d de la gura 6.21, por lo tanto una nueva tupla formar parte de la relacin de salida. Dicha tupla tendr como atributos clsicos los mismos que t1 y t2 , y como atributos restriccin la restriccin de t2 (caso d) o de t1 (caso c).
178
Cx
Cy
Cx
Cy
Cx
Cy
Cx
Cy
a. Sin soluciones en comn Cy Cx c. Cx incluida en Cy Cy
b. Algunas soluciones en comn Cx Cx
Cy
d. Cy incluida en Cx
Figura 6.21: Tipos de unin entre restricciones
6.6. Implementacin de la Operacin de Diferencia

En el caso de la diferencia sobre los relaciones (R1 , R2 ), donde ambas relaciones tienen que ser equivalente con respecto a la diferencia, la relacin que se obtiene como salida tendr todas las tuplas de R1 que no pertenezcan a R2 . En el caso de que las relaciones que se vayan a unir tengan atributos restriccin, ser necesario comprobar las soluciones que tienen en comn cada una de las restricciones de R1 con respecto a las de R2 . Para hace ms eciente la implementacin, se separar el tratamiento de los atributos univaluados de los atributos restriccin. Los pasos de dicha comprobacin se realizar entre todos los pares de tuplas t1 R1 y t2 R2 , y sern: 1. Si todos los atributos clsicos entre las dos tuplas son iguales, se pasa al paso 2, en caso contrario la tupla t1 formarn parte de la solucin. Esta comprobacin se har mediante el lgebra relacional clsica. 2. Si todas las restricciones de ambas tuplas tienen las mismas variables, se pasar al paso 3, en caso contrario la tupla t1 formar parte de la solucin. Esta comprobacin se har mediante el lgebra relacional clsica gracias a tener las variables indexadas en la tabla Restricciones/Variables. 3. Entre las tuplas se comparan sus atributos restriccin como se ha explicado en la seccin 4.8. En dicha seccin se estudia la diferencia de tuplas analizando si existen alguna solucin para dos restricciones, equivalente al operado & explicado, lo que gracias a tener almacenado el mnimo y mximo valor de cada variable se puede hacer de una manera ms eciente, evitando la creacin de CSP.. Si existe ms de un atributo restriccin en las relaciones R1 y R2 se comparar cada i-simo atributo restriccin de t1 con el atributo restriccin i-simo de t2 , existiendo dos casos:
Resumen
179
Si existe alguna restriccin del atributo restriccin de t1 (Cx ) que tenga una solucin no perteneciente al atributo restriccin de t2 (Cy )(los casos a, b y c de la gura 6.22): Una nueva tupla formar parte de la relacin de salida. Dicha tupla tendr como atributos clsicos los mismos que t1 y t2 , y como atributos restriccin la restriccin de t1 (caso a) o una nueva restriccin con las soluciones de t1 que no pertenecen a t2 (caso b y c). En caso contrario, signicar que todas las relaciones sern de la forma d de la gura 6.22: La tupla t1 no formar parte de la salida.
Cx
Cy
Cx
Cx
Cy
Cx
Cy
a. Sin soluciones en comn Cx Cy Cx Cy
b. Algunas soluciones en comn Cy Cx
c. Cy incluida en Cx
d. Cx incluida en Cy
Figura 6.22: Tipos de diferencias entre restricciones
6.7.
Resumen
En este captulo se presenta, para cada una de las cinco operaciones primitivas del lgebra relacional, los detalles de implementacin necesarios para evaluarlas de una manera eciente y acorde con la arquitectura propuesta. Para la seleccin se propone utilizar el lgebra relacional clsica para los atributos univaluados, las envolventes para la parte del predicado relacionada con atributos variables de restriccin y para los atributo restriccin, y por ltimo construir un CSP en los casos en que sea necesario, dada la elevada complejidad de resolucin stos. Todas estas decisiones son tomadas con el objetivo de conocer las tuplas que cumplen un determinado predicado con el menor gasto computacional posible. Para la proyeccin se divide el problema en dos etapas: bsqueda de restricciones de manera horizontal o vertical; y bsqueda de restricciones relacionadas por variables en funcin de si la evaluacin es simblica o numrica. Para cada uno de estos casos, se
180
describe cmo se crearn cada uno de los modelos dependiendo del tipo de restricciones involucradas y el tipo de consulta. Por ltimo se presenta la diferencia y la unin, minimizando el nmero de CSP que se tienen que construir para la evaluacin gracias a: el anlisis de las envolventes de las variables de cada una de las restricciones; aprovechando el lgebra relacional clsica para los atributos univaluados; y analizando los rangos de las variables para conocer las soluciones que comparten las restricciones.
Captulo 7 La Diagnosis de Fallos Basada en Modelos: Un caso de estudio

Aunque ha sido el campo de los sistemas geogrcos el ms utilizado como caso de estudio en las BDdR, tambin se pueden encontrar innovadores estudios en el campo de la gentica [124], o en el campo de data mining [97]. La diagnosis de fallos se considera una rea donde tambin las BDdR pueden aportar grandes benecios. En este captulo se introducir el problema de la diagnosis de fallos basada en modelos como otro ejemplo de utilizacin de las Bases de Datos de Restricciones. El proceso de diagnosis detecta qu componentes fallan en funcin de los valores obtenidos de un conjunto de sensores incluidos en el sistema. Cuando el comportamiento de los componentes que conforman el sistema se puede representar con restricciones polinmicas, se puede utilizar una LORCDB para el tratamiento y evaluacin de la informacin. Se ha utilizado la diagnosis de fallos como un caso de uso en las BDdR debido a que tiene caractersticas idneas, ya que los valores de las variables no son nicos, dependen de las entradas, y su funcionamiento y conguracin del sistema puede ser descrito mediante restricciones. Entre las razones que han llevado a la utilizacin de la diagnosis de fallos como caso de estudio se encuentran: Un sistema puede estar formado por muchos componentes, por lo que una base de datos es una estructura ideal para almacenar toda la informacin con el objetivo de agilizar su tratamiento. Los distintos componentes se relacionan entre ellos mediante variables, a lo cual dan soporte las LORCDB mediante la indexacin entre restricciones y variables.
182
Captulo 7. La Diagnosis de Fallos Basada en Modelos: Un caso de estudio
En la diagnosis de sistemas slo se conocen los valores de las variables que tienen sensores, de forma que pese a que el sistema puede ser el mismo, las restricciones que representan su funcionamiento dependen de la localizacin de dichos sensores. Esta es la misma idea desarrollada en la proyeccin sobre atributos variable de restriccin, donde sobre una misma relacin de entrada es posible realizar diferentes proyecciones dependiendo de los atributos que se quieran obtener. Dependiendo del tipo de restriccin que describa el comportamiento del componente y del tipo de informacin que se quiera obtener, es necesario utilizar diferentes tcnicas. La accin de decidir y ejecutar dichas tcnicas se ve facilitada por la utilizacin de la arquitectura LORCDB y el lenguaje CORQL. Esto signica que un proceso tan complejo como es el de la diagnosis de fallos, se puede realizar simplemente mediante un conjunto de consultas a la base de datos. Para introducir la problemtica de la diagnosis basada en modelos, en principio se utiliza un sistema sencillo y muy difundido en el rea de la diagnosis de fallos. Este ejemplo ayudar a explicar las deniciones relativas al paradigma de la diagnosis basada en modelos. Una vez que el problema y los pasos de la diagnosis han sido introducidos, se presenta un sistema ms complejo, tanto en el nmero de componentes, como en el tipo de restricciones que lo describen y por lo tanto el tipo de consultas que se pueden realizar. Sobre este ejemplo ms complejo, se introducir cmo las distintas tcnicas sobre problemas de satisfaccin de restricciones y eliminacin de variables hacen posible el proceso de la diagnosis de fallos.
7.1. Conceptos sobre Diagnosis de Fallos

El rea de la diagnosis de fallos es un campo emergente desde el punto de vista de las empresas, ya que un sistema que falla puede conllevar grandes prdidas econmicas. La diagnosis basada en modelos permite determinar, basndose en su monitorizacin, por qu un sistema correctamente diseado no funciona como se espera. De esta forma abarca la deteccin de los componentes cuyo comportamiento no corresponde a los esperados por el diseador del sistema. Los sistemas a diagnosticar mediante modelos son especialmente idneos para su tratamiento mediante DBdR, ya que se pueden representar mediante un conjunto de res-
Conceptos sobre Diagnosis de Fallos
183
tricciones (componentes) relacionadas mediante variables (uniones entre componentes). Analizando un sistema de componentes como un conjunto de datos relacionados mediante las variables que contiene, sera posible obtener el comportamiento de una parte del sistema en funcin de sus variables, o saber qu valores de salida tendra el sistema para una entrada determinada, facilitando la labor del ingeniero. Heredando toda la potencia de las bases de datos relacionales, y utilizando BDdR tambin sera posible alterar o ampliar el sistema almacenado con pocas modicaciones, facilitando el acceso a sistemas formados por gran cantidad de componentes. Antes de continuar con los detalles que relacionan las BDdR y la diagnosis de fallos, es necesario hacer una introduccin a las dos propuestas de diagnosis en las que se basan los ejemplos utilizados en este captulo, FDI y DX. FDI (Fault Detection and Isolation) [80][115] consiste en el anlisis de un modelo para identicar las relaciones entre los componentes que lo forman, determinando qu componentes del sistema afectan a cada variable observable (con sensores), utilizando el anlisis estructural [142][123]. De esta forma, FDI dene una rma de fallo para cada uno de los posible errores del sistema, slo teniendo en cuenta los fallos simples, lo que signica que slo puede fallar un componente del sistema al mismo tiempo. FDI realizar dicho anlisis estructural dependiendo de la conguracin del sistema, por lo que dicho proceso se har fuera de lnea (informacin precompilada). DX, al contrario que FDI, da cabida a la deteccin de fallos mltiples cuyos primeros desarrollos se publicaron en los trabajos [40][127][89]. Estos trabajos tratan de descubrir discrepancias entre el comportamiento observado de un sistema y el comportamiento esperado segn un modelo. La propuesta DX se caracteriza por la diagnosis de un sistema deniendo un conjunto mnimo de componentes que pueden fallar en funcin del comportamiento observado (sntomas), por lo que ser un proceso en lnea. Sin duda fueron los trabajos de De Kleer y Williams [90] y Reiter [127] los que formalizaron el problema de la diagnosis de fallos, junto a la denicin de propuestas para hacer el proceso ms eciente evitando bsquedas innecesarias. El tipo de diagnosis sobre la que se basan los ejemplos de las consultas que se describirn en este captulo, utiliza una combinacin de ambas tcnicas (DX y FDI) [55] seleccionando las caractersticas ms ventajosas de ambas. Tambin hay que tener en cuenta que entre las soluciones dadas para la diagnosis, se suele pasar por alto la importancia del almacenamiento del sistema a diagnosticar. El inconveniente es que no existen aportaciones que permitan tratar las restricciones y sus variables como un dato consultable en una base de datos relacional, por lo que la creacin
184
y la diagnosis de sistemas de gran tamao resulta engorroso y complicado. El uso de las BDdR en el campo de la diagnosis hace los sistemas ms verstiles, conlleva persistencia, facilita la composicin de los sistema, disminuye la utilizacin de memoria y hace ms eciente el proceso de diagnosis ya que agiliza el acceso a la informacin. Como se ha expuesto con anterioridad, el uso de SQL sobre restricciones hace posible obtener diferentes modelos en funcin de la consulta, en este captulo se presenta cmo la arquitectura LORCDB puede almacenar las restricciones que describen el comportamiento y la relacin entre los componentes de un sistema. Junto a esto se presentan qu consultas ayudan a realizar la diagnosis sin necesidad de crear una aplicacin especca para su tratamiento, ya que toda la tcnicas y lgica de inferencia de conocimiento est incluida en la arquitectura. La localizacin de los sensores denir qu variables son observables y cules deben ser inferidas en funcin del resto (no observables). La arquitectura LORCDB permite consultar estos sistemas equivalentes, simulando la colocacin de los sensores en lugares diferentes e inriendo nuevas restricciones. La colocacin de los sensores denir qu parte del sistema se conoce, o lo que es lo mismo, qu variables se quieren obtener mediante la proyeccin.
7.2. Deniciones y Notacin

Para la comprensin clara del caso de estudio son necesarias algunas deniciones. Las deniciones y la notacin usadas estn basadas en los conceptos desarrollados por la comunidad de diagnosis, combinando la lgica DX y las rmas de fallos (FDI). Para facilitar la comprensin de las deniciones, se utilizar un ejemplo sencillo conocido en el campo de la diagnosis mostrado en la gura 7.1. En este ejemplo los componentes Ai representan sumadores, mientras que los componentes Mi representan multiplicadores.
a b c d e
M1 M2
x y A1 A2 f g
M3
Figura 7.1: Ejemplo introductorio
Deniciones y Notacin
185
Denicin 7.1. Modelo del Sistema Polinmico - MSP (System Polynomial Model - SPM). Puede ser denido como un conjunto nito P de restricciones polinmicas o lineales las cuales describen el comportamiento del sistema. Para diagnosticar dicho sistema es necesario denir qu variables sern no observables (Vnob ) y cuales observables (Vob ), que sern las que tengan sensores. De esta forma, un MSP est formado por la tupla {P, Vob , Vnob }. Para el ejemplo de la gura 7.1, las restricciones sern las descritas en la tabla 7.1, donde las variables observables son {a, b, c, d, e, f, g}, y las no observables {x, y, z}. Nombre M1 M2 M3 A1 A2 restriccin
ac=x bd=y ce=z x+y =f y+z =g
Tabla 7.1: Modelo del Sistema
Denicin 7.2. Contexto. Cualquier subconjunto de componentes que componen

el sistema. El nmero de los posibles contextos es 2nComp 1, donde nComp es el nmero de componentes del sistema.
Denicin 7.3. Red de Contextos (RC). Un grafo formado por todos los Contextos del sistema, acorde con ATMS [88]. Los nodos del grafo son los Contextos y existir una arista entre dos Contextos si los componentes de uno de ellos est contenido en el otro, y el contexto menor tiene slo un elemento menos que le otro contexto. La creacin de estas aristas facilitar la diagnosis nal. La Red de Contextos es la mostrada en la gura 7.2, donde se muestra un grafo donde los nodos son todos los Contextos.
Denicin 7.4. Restricciones de Contextos con Redundancia Analtica. Estas

restricciones son ms conocidas por sus nombre en ingls (Context Analytical Redundancy Constraint - CARC), y denen restricciones derivadas de las restricciones originales del sistema. Estas restricciones se pueden obtener utilizando tcnicas simblicas para la eliminacin de las variables no observables. Las restricciones de contexto con redundancia analtica son restricciones equivalentes a las originales, pero que slo relacionan las variables denidas como observables.
186
M1M2M3A1A2
M1M2M3A1
M1M2M3A2
M1M2A1A2
M1M3A1A2
M2M3A1A2
M1M2M3 M1M2A1 M1M3A2 M1M2A2 M1M3A1 M2M3A1
M2M3A2 M1A1A2 M2A1A2 M3A1A2
M1M2
M1M3 M2M3 M1A1 M1A2
M2A1 M2A2 M3A1 M3A2 A1A2
M1
M2
M3
A1
A2
[]
Figura 7.2: Red de Contextos
Denicin 7.5. Posible Contexto Conictivo Mnimo (PCCM). Cuando es

posible obtener un CARC con las restricciones asociadas a los componentes de un Contexto, se dir que dicho Contexto es un Posible Contexto Conictivo Mnimo. Que sea mnimo signica que para que un Contexto sea un PCCM, ninguno de sus subcontextos pueden tener asociados las mismas CARC que l. Los Posibles Contextos Conictivos Mnimos (PCCM) obtenidos, y los CARC para el ejemplo de la tabla 7.1, son los siguientes: CARC1 {f = a c + b d}: Generado con las restricciones de los componentes
{M1 , M2 , A1 }
CARC2 {g = b d + c e}: Generado con las restricciones de los componentes
{M2 , M3 , A2 }
CARC3 {f g = a c c e}: Generado con las restricciones de los componentes
{M1 , M3 , A1 , A2 }
Donde las restricciones asociadas a dichos PCCM se obtendrn mediante la eliminacin de las variables no observables, utilizando en este caso las Bases de Grbner por ser restricciones polinmicas de igualdad. Los PCCM estn marcados en la gura 7.2 mediante crculos, donde se puede observar que por ejemplo {M2, M3, A2} {M2, M3, A1, A2}, ambos tienen la CARC2 asociada, pero se selecciona {M2, M3, A2} como PCCM por ser mnimo.
Deniciones y Notacin
187
Aquellos contextos cuyas Restricciones de Contextos con Redundancia Analtica no sean vacas, y no estn en otro contexto menor, sern los Posibles Contextos Conictivos Mnimos. Para obtener los PCCM no es necesario estudiar las 2nComp 1 combinaciones, slo aquellas de las cuales se puedan obtener las restricciones de contextos con redundancia analtica [55].
Denicin 7.6. Modelo Observable (MO). Conjunto de valores denidos para un

subconjunto de las variables del sistema. Las variables cuyo valor es conocido, se denirn como variables observables. Estas variables son las encargadas de mostrar los sntomas de un sistema, y en funcin de sus valores ser posible realizar la diagnosis.
Denicin 7.7. Contexto Conictivo Mnimo (CCM). Cuando tras aplicar un

modelo observable alguna de las CARC no es satisfactibles, se dice que el o los Posibles Contextos Conictivos Mnimos a los que estn asociados dichas CARC son Contextos Conictivos Mnimos. La diagnosis del sistema se basar en los componentes asociados a los Contextos Conictivos Mnimos.
Denicin 7.8. Hitting Set (HS). Sea una coleccin de conjuntos de componentes
C los Contextos Conictivos Mnimos para un modelo observable, un hitting set es un
conjunto H
SC
S tal que H contiene al menos un elemento de cada S C . Un HS
de C es mnimo si y slo si ningn subconjunto propio es un hitting set de C . Se le llama
single minimal hitting set a un hitting set formado por un solo componente.
Siendo los distintos hitting set minimales {HS 1 , . . ., HS i , . . ., HS n }, la cardinalidad de HS i (|HS i |) es el nmero de componentes que forman HS i . Reiter [127] present una de las primeras soluciones para la determinacin de los hitting sets mnimos utilizando los llamados HS-trees. Este trabajo fue mejorado por Greiner [65] en el llamado HS-DAG, evitando que el tamao del rbol de combinaciones creciera exponencialmente con el nmero de componentes. Otras soluciones relativas a la obtencin de hitting sets minimales fueron BHS-trees mediante la utilizacin de rboles binarios, o los HST-trees de Wotawa [155]. Aunque tambin existen las soluciones que utilizan programacin con restricciones en lugar de rboles [41], basadas en encontrar el mximo conjunto de restricciones satisfactibles para una modelo observable determinado.
Denicin 7.9. Diagnosis mnima. Est formada por los hitting sets mnimos
del sistema para un modelo observable. En caso de que se utilicen distintos modelos observables, la diagnosis mnima ser la interseccin entre todos los hitting sets mnimos obtenidos para cada modelo observable.
188
Por ejemplo, para el modelo observable {a=1, b=2, c=2, d=3, e=2, f=9, g=11} no son satisfactibles las Restricciones de Contextos con Redundancia Analtica CARC1 y CARC2 . Lo que signica que los Contextos Conictivos Mnimos para este modelo observable sern:
{M1 , M2 , A1 } y {M2 , M3 , A2 }. En este caso M2 ser un single minimal hitting set.

Para estos Contextos Conictivos Mnimos los hitting sets mnimos obtenidos son: {M2 }, {M1 , M3 }, {M1 , A2 }, {A1 , M3 }, {A1 , A2 }.
7.3. La Diagnosis de Fallos y las BDdR

Una vez mostrados todas las deniciones relativas a la diagnosis de fallos basada en modelos, a continuacin se presenta qu sentencias se realizarn para almacenar la informacin relativa al sistema, y qu consultas son necesarias para obtener la diagnosis de fallos cuando ste est almacenado en una LORCDB. Para mostrar las valores que se obtienen se continuar utilizando el ejemplo de la gura 7.1
7.3.1. Insercin de Componentes en la BDdR

Para almacenar el comportamiento de cada uno de los componentes del sistema es necesario crear una tabla con un atributo restriccin. Un ejemplo de dicha tabla puede ser la creada de la forma:
CREATE TABLE COMPONENTES(Id Number, Nombre String, Comportamiento Constraint)

Una vez creada la tabla para almacenar los componentes, es el momento de insertar la informacin relativa a cada uno de ellos, como es el caso del componente M1 mostrado a continuacin, junto al resto de componentes mostrados en la tabla 7.1. Cada vez que se inserta una restriccin se actualizan las tablas Restricciones, Variables y Restriccio-
nes/Variables para que las futuras bsquedas de restricciones relacionadas por variables
sean ms ecientes.
INSERT INTO COMPONENTES(Id, Nombre, Comportamiento) VALUES
(3, 'M1', {'a c = x'(Float 10..10 a, Float 10..10 c, Float x)})
La Diagnosis de Fallos y las BDdR
189
En este caso, pese a que no se establece el valor mnimo y mximo que puede tomar la variable x de forma explcita, se puede inferir de los rangos de a y c, obteniendo los valores 100..100. Esto es posible gracias a utilizar la gramtica intervalar [11].
7.3.2. Obtencin de la Red de Contextos

Para obtener la Red de Contextos es necesario realizar todas las combinaciones de los componentes del sistema. Para realizarlo mediante consultas a la base de datos, una forma utilizando exclusivamente consultas, es realizar una secuencia de productos cartesianos anidados sobre relaciones de booleanos, tantos como componentes tenga el sistema. De forma general ser:
(((C1 C2 ). . .)Ci ). . .)Cn )

donde C1 . . .Ci . . .Cn representan n relaciones, una por componente. Cada una de estas relaciones estar formada por un atributo que representar al componente i-simo del sistema y dos tuplas, una con el valor true y otro false como las mostradas en la gura 7.3. Tras realizar los n 1 productos cartesianos entre las relaciones y eliminando la primera tupla que tendr todos los componentes a false, se obtendr una relacin con n atributos y 2nComp 1 tuplas que representarn los componentes que forman cada Contexto.
A1 False True A2 False True A1 False False True True A2 False True False True
A1 False False True True
A2 False True False True
A3 False True
A1 False False False False True True True True
A2 False False True True False False True True
A3 False True False True False True False True
Figura 7.3: Producto Cartesiano entre Componentes
190
7.3.3. Obtencin de las CARCs y los PCCM

Para la obtencin tanto de los Posibles Contextos Conictos Mnimos (PCCM), junto a las restricciones asociadas a ellos (CARC), hay que denir las variables donde estn los sensores colocados, los cuales determinarn qu variables son observables. Como ejemplo se propone obtener los nombres de los componentes de los PCCM y las CARCs asociados para las variables observables a, b, c, d, e, f, g. Para obtener unas nuevas restricciones donde slo aparezcan relacionadas las variables observables, ser necesario realizar una proyeccin simblica, lo que conlleva utilizar la palabra reservada CONSTRAINTS. Debido al diseo de la tabla Componentes, todas las restricciones se almacenan en un mismo atributo restriccin llamado Comportamiento, por lo que la proyeccin ser vertical, aunque no ser necesario utilizar la palabra reservada VERTICAL ya que todas las variables de la proyeccin pertenecen al mismo atributo restriccin. Al realizar la diagnosis es ms conveniente realizar sustitucin de variables en lugar de eliminacin, as ser posible obtener las salidas en funcin de las entradas, por lo que se utilizar la palabra reservada FULL. Uniendo todas estas caractersticas, se construir la consulta:
R1 = SELECT NOMBRE, FULL CONSTRAINTS
(COMPORTAMIENTO.a, COMPORTAMIENTO.b, COMPORTAMIENTO.c, COMPORTAMIENTO.d, COMPORTAMIENTO.e, COMPORTAMIENTO.f, COMPORTAMIENTO.g) FROM COMPONENTES
Nombre M1 A1 M2 M1 A1 A2 M3 M2 A2 M3
Comportamiento(a, b, c, d, e, f, g)
(a c) b d + f = 0 (a c) b d + f = 0 (a c) b d + f = 0 (a c) + c e + f g = 0 (a c) + c e + f g = 0 (a c) + c e + f g = 0 (a c) + c e + f g = 0 (b d) c e + g = 0 (b d) c e + g = 0 (b d) c e + g = 0
Tabla 7.2: Obtencin de CARC para el ejemplo introductorio
La Diagnosis de Fallos y las BDdR
191
Donde se obtendr como salida la tabla 7.2. Sobre la relacin de salida R1 se puede obtener por una parte los componentes que forman el PCCM, y por otra parte cada CARC para cada PCCM. Para ello se crearn dos tablas, PCCM y CARCS, de la forma:
CREATE TABLE CARCS(idPCCM Autonumrico, carc Constraint)

La tabla CARCS almacenar cada una de las restricciones derivadas en el atributo
carc como el conjunto de componentes que forman parte del PCCM con el identicador
almacenado en el atributo idPCCM. Dicho identicador se generar de forma automtica con un campo autonumrico. Para almacenar las CARCs en dicha tabla se realizar la sentencia sobre la relacin R1 anteriormente obtenida de la forma:
INSERT INTO CARCS (carc) VALUES (R1 )

Como las tuplas no pueden obtenerse repetidas, se obtendr la tabla mostrada en gura 7.4.a.
IdPCCM Componente 1 IdPCCM 1 2 3 CARC 1 1 2 2 2 2 (a) Tabla CARCs 3 3 3 M1 A1 M2 M1 A1 A2 M3 M2 A2 M3
- (a * c) - b * d + f = 0
- (a * c) + c * e + f - g = 0 - (b * d) - c * e + g = 0
(b) Tabla PCCM
Figura 7.4: Tablas de las CARCs y los PCCM para el ejemplo introductorio Y para obtener los componentes del PCCM se crear una tabla donde sern almacenados. La creacin de la tabla ser de la forma:
CREATE TABLE PCCM(idPCCM Integer, Componente String)

Y rellenndola con la informacin de la consulta R1 de la forma:
INSERT INTO PCCM(idPCCM, Componente) VALUES (Select CARCS.idPCCM, R1 .Nombre from CARCS, R1 WHERE CARCS.carc=R1 .Comportamiento)
192
Tras la insercin de esta informacin, la tabla PCCM quedar como se muestra en la gura 7.4.b.
7.3.4. Obtencin de los CCM para un Modelo Observable

Para obtener los Contextos Conictivos Mnimos es necesario saber qu restricciones son satisfactibles para el conjunto de los valores de los sensores, lo que se establece en el predicado de la consulta (la condicin del WHERE). Para conocer si cada una de las restricciones (CARC) almacenadas en la tabla son satisfactibles para cada uno de los valores de los sensores, se utilizar las palabras reservadas BOOLEAN VALUE, que devuelve
true o false. Dicha operacin se realiza sobre restricciones, siendo equivalente a VALUES,
pero con la nica diferencia que devuelve true si encuentra un valor de las variables que hace satisfactible la restriccin, renombrando dicho atributo con el nombre Satisfactible. La sentencia ser de la forma:
R2 = SELECT idPCCM, CARC, BOOLEAN VALUE (CARC) as Satisfactible FROM CARCS WHERE (CARC.a=1 AND CARC.b=2 AND CARC.c=2 AND CARC.d=3 AND CARC.e=2 AND CARC.f=9 AND CARC.g=11)
Obteniendo la relacin mostrada en la tabla 7.3, donde se aade un nuevo atributo que indica si cada CARC es o no satisfactible en funcin de la instanciacin de un conjunto de variables. IdPCCM 1 2 3 CARC Satisfactible false true false
(a c) b d + f = 0 (a c) + c e + f g = 0 (b d) c e + g = 0
Tabla 7.3: Obtencin de los CCM (I)
Para realizar la diagnosis mnima habr que obtener slo aquellos conjuntos de componentes asociados a las CARCs no satisfactibles, los cuales se obtendrn realizando la consulta:
SELECT IdPCCM, CARC FROM R2 WHERE Satisfactible=false

Obteniendo la tabla 7.4.
Ms ejemplos de Consultas
193
IdPCCM 1 3
CARC
Satisfactible false false
(ac) bd + f = 0 (bd) ce + g = 0
Tabla 7.4: Obtencin de los CCM (II)
7.3.5. Obtencin de los Hitting Sets Mnimos

Partiendo de los componentes que forman los CCM conseguidos en el apartado anterior, se obtendrn los hitting sets y con ellos la diagnosis mnima del sistema para el modelo observable. Los hitting set deben estar formados por al menos un componente de cada CCM, y para que sea mnimo, slo podr estar formado por un componente de cada CCM. La cardinalidad mxima de los hitting sets ser el nmero de CCM diferentes que se hallan obtenido, 2 en el caso del ejemplo que se est desarrollando. Y con la consulta, combinado la tabla CCM y PCCM que contiene los componentes de cada hitting set:
SELECT PCCM.Componente, PCCM 1.Componente FROM PCCM, PCCM AS PCCM 1 WHERE PCCM.idPCCM=1 AND PCCM.idPCCM 1.id=3
Se obtendr una tupla por cada hitting set mnimo, en este caso las representadas en la tabla 7.5. O lo que es lo mismo, la tabla 7.6. En la tabla se observan hitting sets mnimos de uno y dos componentes, que corresponde con el nmero de CCM. El caso de M 2 es un single minimal hitting set, ya que el fallo del componente M 2 explicara el comportamiento del sistema para el modelo observable descrito. Las tuplas restantes representan hitting sets mnimos de dos componentes {M 1, M 2}, {A1, M 2}, {M 1, A3}, {A1, A3}, . . .
7.4.
En las secciones anteriores se ha presentado un ejemplo y las consultas que hay que realizar para obtener la diagnosis de un sistema. El ejemplo estaba formado por cinco componentes, todos ellos con restricciones polinmicas de igualdad, por lo que la eliminacin de variables se realiza utilizando la teora de las Bases de Grbner. En esta seccin
194
PCCM.Componente M1 A1 M2 M1 A1 M2 M1 A1 M2
PCCM 1.Componente M2 M2 M2 A2 A2 A2 M3 M3 M3
Tabla 7.5: Obtencin de los Hitting Sets Mnimos Hitting Set HS1 HS2 HS3 HS4 HS5 HS6 HS7 HS8 HS9 A1 0 1 0 0 1 0 0 1 0 A2 0 0 0 1 1 0 1 0 0 M1 1 0 0 1 0 1 0 0 0 M2 1 1 1 0 0 0 1 0 1 M3 0 0 0 0 0 1 0 1 1
Tabla 7.6: Obtencin de los Hitting Sets Mnimos (II)
se analiza un ejemplo ms complejo, tanto en el nmero de componentes, que pasarn a ser 38, como en el tipo de restricciones, que sern tanto ecuaciones como inecuaciones polinmicas. Tambin se presentan nuevos tipos de consultas relacionadas con la proyeccin numrica a parte de la simblica. El conjunto de componentes del sistema y sus relaciones es el presentado en la gura 7.5, donde Mi representa multiplicadores, Ai sumadores y Ri restadores. El sistema se ha dividido en cuatro partes en funcin del tipo de restriccin
195
que la forman. La parte del sistema etiquetada con (1) tiene restricciones de la forma {variable1 operacin variable2 <= variable3 variable1 operacin
variable2 >= variable3 operacin constante}. La parte del sistema etiquetada con
(2) tiene restriciones de la forma {variable1 operacin variable2 <= variable3 }, mientras que los componentes etiquetados con (3) y (4) son de la forma: {variable1
operacin variable2 = variable3 }. Los detalles de todos los componentes se presentan en la seccin B.1 del apndice B.
w1 y1 a1 b1 c1 d1 e1 f1 g1 h1 2 i1 j1 k1 l1 m n o p 1 a b c d
A1
A23
m1
M6
s1
A10
x1
M4
a2
A18
R1
n1 o1
A22
A11
z1 o2
A17
h2
M9
A14
R4
b2
A19
g2
t1
R5
i2
A15
p1
A16
r2 s2
R3 M8 A20 M10
4 p2
q1
M7
A12
k2 l2
M5
R2
r1
u1
A13
c2
A21
t2
A4 A6
q r
A9
q2
h i e
M2
A5
j
A3
k
A7
A8
M1 A2
g
M3
s u
Figura 7.5: Ejemplo de Diagnosis Los componentes estn almacenados en una tabla creada de la forma:
CREATE TABLE COMPONENTES (Identificador Integer, Nombre String, Comportamiento Constraint, Subsistema Integer)
Para insertar informacin en la tabla se harn sentencias de la forma:
196
INSERT INTO TABLE COMPONENTES (IDENTIFICADOR, NOMBRE, COMPORTAMIENTO, SUBSISTEMA) VALUES (1, 'A1', {'a+b<=e AND e-1<=a+b' (Float 5..10 a, Float 5..15 b, Float e)}, 1)
7.5. Ejemplos de Consultas en la Diagnosis Basada en Modelos

Como se ha presentado en captulos anteriores, el uso de las BDdR ampla la semntica de las operaciones del lgebra relacional. En esta seccin se muestran algunos ejemplos de seleccin y proyeccin utilizando la tabla Componentes sobre los tres tipos de atributos
c denidos en las BDdR (ati , atc i , ati .vj ). Estos tres tipos de atributos permiten ampliar
los tipos de consultas. Con la combinacin del operador y seleccin se pueden realizar gran cantidad de consultas relativas a la diagnosis basada en modelos. La combinacin natural de las operaciones es de la forma: R1 = a1 ,...,an (predicate (R2 )), que con los distintos atributos que pueden participar en ellas, mostrados en la tabla 7.7, se obtendrn nueve variantes.
atributos
atributos relativos al predicado
ati at
c i
ati atc i atc i .vj
atc i .vj
Tabla 7.7: Posibles combinaciones de atributos y operaciones y
Algunos de los ejemplos de estas combinaciones relacionadas con la diagnosis basada en modelos pueden ser: 1.
at1 ...atm ((at1 ...atn ) ). Cul es el identicador del componente cuyo nombre es A1?
En esta consulta slo hay relacionados atributos clsicos, por lo que slo se har uso del lgebra relacional clsica.
Ejemplos de Consultas en la Diagnosis Basada en Modelos
197
2.
c ). Qu nombres tienen los componentes cuyo contenido del atriat1 ...atm ((atc 1 ...atn )
buto Comportamiento es igual a la restriccin x + y = z ? Esta consulta obtendr como salida todos los nombres de los componentes cuya restriccin de comportamiento sea igual a dicha restriccin. Esta operacin de comparacin es una de las denidas entre restricciones en el captulo 4, donde se describe que dos restricciones son iguales si comparten las mismas soluciones. 3.
c c c ). En qu componentes la variable c puede tomar at1 ...atm ((atc 1 .v1 ...at1 .vk ...atn .v1 ...atn .vk )
el valor 5? En este caso se buscarn las restricciones con dicha variable comprobando que el valor 5 est incluido entre los valores de las envolventes, y con aquellos que cumplan dicha condicin se crear un problema de satisfaccin de restricciones. 4.
c ((at ...at ) ). Qu restriccin es la que describe el comportamiento del com(atc n 1 1 ...atm )
ponente cuyo nombre es A1? Es una seleccin clsica, pese a que obtenga un atributo restriccin. 5.
c ((atc ...atc ) ). Qu restricciones son distintas a a + b = e? Lo que implica (atc n 1 ...atm ) 1
compara las soluciones de cada restriccin con a + b = e, y devolver aquellas que no son iguales. 6.
c ((atc .v ...atc .v ...atc .v ...atc .v ) ). Cules son las restricciones si se conocen los (atc n 1 n k 1 ...atm ) 1 1 1 k
valores de las variables {a = 5, b = 3}? La evaluacin de esta consulta consiste en sustituir las variables por constantes con los valores establecidos. 7.
c c c (atc ((at1 ...atn ) ). Cul es la relacin simblica de las variables 1 .v1 ...at1 .vk ...atm .v1 ...atn .vk )
a, b, c, d, u pertenecientes a los componentes A1, A2, M 1 y M 3? En este caso es

necesario recurrir a la eliminacin de cuanticadores, para que en la solucin slo aparezcan las variables establecidas en la proyeccin (a, b, c, d, u). 8.
c c c c ). Qu valor mximo puede tomar la variable (atc ((atc 1 .v1 ...at1 .vk ...atm .v1 ...atn .vk ) 1 ...atn )
c en el atributo restriccin Comportamiento? La evaluacin de esta consulta se

realizar con la creacin de un problema de optimizacin de restricciones con las restricciones relacionadas con esta proyeccin numrica. 9.
c c c c c (atc ((atc 1 .v1 ...at1 .vk ...atm .v1 ...atn .vk ) 1 .v1 ...at1 .vk ...atn .v1 ...
). atc n .vk )
Cules son los valores de las
variables a, b y c si d = 5 y e = 6? La solucin a esta consulta se obtiene con la construccin de un problema de satisfaccin de restricciones.
198
Aunque en esta seccin se han incluido ejemplos generales sobre consultas relacionadas con la diagnosis de fallos, en las siguientes subsecciones se plantearn consultas concretas con las acciones a realizar necesarias para evaluarlas.
7.5.1. Ejemplos de Seleccin

En esta subseccin se presentan tres ejemplos, cada uno de ellos correspondiente a un tipo de atributo.
Relativo a atributos clsicos: Seleccionar las tuplas de la tabla Componentes

cuyo atributo Nombre sea A1.
SELECT * FROM COMPONENTES WHERE NOMBRE = 'A1'

Obteniendo la tupla mostrada en la tabla 7.8. Identicador 1 Nombre A1 Comportamiento
a+b=e
Tabla 7.8: Salida consulta con seleccin (I)
Relativo a atributos restriccin: Seleccionar las tuplas de la tabla Componentes

cuyo campo Comportamiento sea igual a {c + d g + 5 = 5}.
SELECT * FROM COMPONENTES WHERE COMPORTAMIENTO = "c + d g + 5 = 5"

Obteniendo la tupla mostrada en la tabla 7.9. Identicador 2 Nombre A2 Comportamiento
c+d=f
Tabla 7.9: Salida consulta con seleccin (II)
Para evaluar esta consulta se crear de forma automtica slo un problema de satisfaccin de restricciones, ya que slo se realiza la comparacin entre restricciones que comparten las mismas variables.
199
Relativo a atributos variable de restriccin: Seleccionar las tuplas de la tabla

Componentes cuya variable Comportamiento.j sea mayor que 5.
SELECT * FROM COMPONENTES WHERE COMPORTAMIENTO.j>5

Obteniendo la tupla mostrada en la tabla 7.10. Identicador 5 7 8 Nombre M2 A6 A3 Comportamiento
hi=j j+m=q jg =k
Tabla 7.10: Salida consulta con seleccin (III)
Para evaluar esta consulta primero se analiza si la variable de la seleccin, en este caso j, puede tomar valores mayores que 5 en funcin de su envolvente almacenada en las tablas de indexacin de la base de datos. Luego se construir un CSP para asegurar que esto es posible. Para el ejemplo propuesto, esto ocurre en todas las restricciones que contienen a j. En caso de que la comparacin fuera entre dos variables en lugar de entre una variable y una constante, se analizara tambin en funcin de sus envolventes estudiando si existe algn valor donde la comparacin se cumpla. Un ejemplo puede ser para la restriccin del componente A6, si en el predicado apareciera la condicin
Comportamiento.j>Comportamiento.q, y el dominio de las variables j y m fueran

positivos, dicha tupla no formara parte de la salida ya que la condicin nunca se podra cumplir.
7.5.2. Ejemplos de Proyeccin

Sobre una relacin se puede obtener un subconjunto de sus atributos, que pueden ser de los tres tipos comentados. A continuacin se muestran ejemplos para cada uno de los tipos de atributos:
Relativo a atributos clsicos: Obtener el atributo Nombre de los componentes

de la relacin Componentes.
200
SELECT NOMBRE FROM COMPONENTES

Obteniendo la tupla mostrada en la tabla 7.11. Nombre A1 A2 A4 A5 M2 M1 A6
...
Tabla 7.11: Salida consulta con Proyeccin (I)
Relativo a atributos restriccin: Obtener el comportamiento de las tuplas de la

relacin Componentes.
SELECT COMPORTAMIENTO FROM COMPONENTES

Obteniendo la tupla mostrada en la tabla 7.12. Comportamiento
a+b=e c+d=f m+n=h o+p=i hi=j ...

Tabla 7.12: Salida consulta con Proyeccin (II)
En este caso para evaluar esta consulta slo se utilizar el lgebra relacional clsica, ya que no existen dos restricciones con las mismas variables, lo que signica que son diferentes. En otros casos, cuando dos o ms restricciones comparten las mismas variables ser necesario realizar la comparacin de dichas restricciones para
201
comprobar que no son iguales mediante la creacin y resolucin de un problema de satisfaccin de restricciones.
Relativo a atributos variable de restriccin: sta es sin duda la proyeccin que

implica ms complicacin algortmica y computacional, ya que un atributo variable de restriccin se puede obtener de forma simblica o numrica. Siguiendo la sintaxis y la semntica de la extensin de SQL propuesta en esta tesis y mostrada en el captulo 4 se presentan distintos ejemplos:
Proyeccin numrica para obtener tuplas de valores: Obtener 10 valores

de las variables c1, d1, b1, a1, y1, a2.
SELECT VALUES[10](COMPORTAMIENTO.c1, COMPORTAMIENTO.d1, COMPORTAMIENTO.b1, COMPORTAMIENTO.a1, COMPORTAMIENTO.y1, COMPORTAMIENTO.a2) FROM COMPONENTES

Obteniendo la tupla mostrada en la tabla 7.13. c1 9 9 9 9 9 9 9 9 9 9 d1 9 10 10 10 10 10 10 10 10 10 b1 0 0 0 0 0 0 0 0 0 0 a1 5 5 5 5 5 5 5 5 5 5 y1 20 1 2 3 4 5 6 7 8 9 a2 100 20 30 40 50 60 70 80 90 100
Tabla 7.13: Salida consulta con Proyeccin (III) Para evaluar esta consulta se obtiene los conjuntos de restricciones relacionadas con las variables que aparecen en la proyeccin, con lo que obtiene las restricciones del subconjunto de componentes {A23, M 6, R1, A10, M 4, A11}. En ese caso la proyeccin ser vertical por defecto, ya que todas las variables pertenecen a un mismo atributo restriccin. Con esas restricciones se construye
202
un problema de satisfaccin de restricciones, devolviendo los 10 primeros valores obtenidos al resolver dicho problema.
Proyeccin numrica para obtener valores mximos o mnimos: Obtener el mayor valor que puede tomar la variable t para los componentes {A1,
M 1, A2, M 3, A7, A3, A8, M 2, A9, A4, A5, A6}.
SELECT VERTICAL MAX VALUE(COMPORTAMIENTO.t) FROM COMPONENTES WHERE SUBSISTEMA = 1

Obteniendo la tupla mostrada en la tabla 7.14. t
8063
Tabla 7.14: Salida consulta con Proyeccin Numrica Vertical (IV) Para evaluar esta consulta se crear un COP con las restricciones de los componentes {A1, M 1, A2, M 3, A7, A3, A8, M 2, A9, A4, A5, A6}, estableciendo
t como objetivo a maximizar. Con esas restricciones se construye y resuelve un

problema de optimizacin de restricciones donde se buscar el valor mximo de la variable t.
Proyeccin simblica: Obtener las restricciones de Contextos con Redundancia Analtica (CARC) y sus componentes asociados cuando los sensores estn en las variables {a1, b1, c1, d1, y1, a2}. Lo que signica obtener restricciones donde slo las variables de la proyeccin pueden aparecer. Como slo se puede conocer la informacin de las variables con sensores, relacionando entradas con salidas del sistemas, se utilizar la palabra reservada FULL, para que slo se analicen los conjuntos completos de restricciones relacionadas por variables.
SELECT NOMBRE, FULL CONSTRAINTS (COMPORTAMIENTO.a1, COMPORTAMIENTO.b1, COMPORTAMIENTO.c1, COMPORTAMIENTO.d1, COMPORTAMIENTO.y1, COMPORTAMIENTO.a2) FROM COMPONENTES WHERE SUBSISTEMA = 3
O utilizando la secuencia de consultas descritas en la seccin 7.3.4, obteniendo en una tabla las CARCs y en otra los componentes del PCCM, lo que se muestra en la gura 7.6.
203
IdPCCM Componente
1
IdPCCM 1 Comportamiento(a1, b1, c1, d1, y1, a2)
A23 M6 R1 A10 M4 A11
1
2
a2-a1 *c1 -a1 *c1 - b1 *c1 +a1 *d1 +2*a1 *c1 *d1+2b1 *c1d1 -a1 *d1 - b1 *d1-a1 *y1 -a1 *c1 *y1 - b1 *c1 *y1 +a1 *d1 *y1 +b1 *d1y1 =0
2
1 1 1 1
(a) Tabla CARCs
(b) Tabla PCCM
Figura 7.6: Salida consulta con Proyeccin (V) En este caso slo se obtiene un conjunto de restricciones relacionadas por variables formada por las restricciones de los componentes {A23, M 6, R1, A10,
M 4, A11}. Esta nueva restriccin se utiliza en la diagnosis para, en funcin

del Modelo Observable, conocer si la restriccin es satisfactible y por lo tanto todos los componentes funcionan de forma correcta, o si por el contrario no se cumple y algn componente est fallando. En este caso la obtencin de la nueva restriccin se realiza utilizando las bases de Grbner, ya que todas son polinmicas de igualdad.
Otro ejemplo de proyeccin simblica que tambin utiliza las Bases de Grbner pero sobre varios conjuntos de restricciones relacionadas, es obtener las restricciones de Contextos con Redundancia Analtica (CARC) y sus componentes asociados cuando los sensores estn en las variables {a2, z1, b2, r2, t1, s2, c2, g2, p2}. Lo que signica obtener restricciones donde slo las variables de la proyeccin pueden aparecer. Como slo se puede conocer la informacin relativa a los sensores se utilizar la palabra reservada FULL, para que slo se analicen los CRRV completos.
SELECT NOMBRE, FULL CONSTRAINTS (COMPORTAMIENTO.a2, COMPORTAMIENTO.z1, COMPORTAMIENTO.b2, COMPORTAMIENTO.r2, COMPORTAMIENTO.t1, COMPORTAMIENTO.s2, COMPORTAMIENTO.c2, COMPORTAMIENTO.g2, COMPORTAMIENTO.p2) FROM COMPONENTES WHERE SUBSISTEMA = 4
O utilizando la secuencia de consultas descritas en la seccin 7.3.4, obteniendo en una tabla las CARCs y en otra los componentes del PCCM, lo que se muestra en la gura 7.7.
204
IdPCCM Componente
IdPCCM 1 2 3 4 5 6
Comportamiento(a2, z1, b2, r2, t1, s2, c2, g2, p2)
a2 * b2 + b2 2 + g2 - a2 * r2 - b2 * r2 = 0
g2- a2* r2- b2* r2 + a2* t1+ b2* t1= 0

c2*g2- a2*p2- b2*p2+ g2*s2= 0
- b2 + t1 = 0
- (b2* c2) - p2 + c2 * r2 - b2 * s2 + r2 * s2 = 0
p2 - c2 * r2 - r2 * s2 + c2 * t1 + s2 * t1 = 0
(a) Tabla CARCs
1 1 1 2 2 2 3 3 3 3 4 4 5 5 5 6 6 6
A18 M9 A19 A18 M9 R3 A18 M9 M8 A20 A19 R3 M8 A19 A20 R3 M8 A20
(b) Tabla PCCM
Figura 7.7: Salida consulta con Proyeccin (VI) En este caso se obtienen seis conjuntos de restricciones relacionadas por variables {A18, M9, A19}, {A18, M9, R3} y {A18, M9, M8, A20}, {A19, R3}, {A19, M8, A20}, {R3, M8, A20} cada uno de ellos con una restriccin asociada. Dichos conjuntos se obtienen de una manera eciente utilizando el algoritmo de proyeccin simblica presentado en el apndice A.
Otro ejemplo de proyeccin simblica, pero que utiliza la Descomposicin Algebraica Cilndrica por tratar inecuaciones, se basa en obtener nuevas restricciones y los componentes asociados cuando los sensores estn en las variables {a, b, c, d, u}. Se utilizar la palabra reservada FULL, para que exclusivamente se analicen los CCRRV. La consulta en este caso ser:
SELECT NOMBRE, FULL CONSTRAINTS(COMPORTAMIENTO.i1, COMPORTAMIENTO.j1, COMPORTAMIENTO.k1, COMPORTAMIENTO.l1, COMPORTAMIENTO.s2) FROM COMPONENTES WHERE SUBSISTEMA = 2
Tambin se puede obtener dicha informacin por separado en las tablas CARCS y PCCM, utilizando la secuencia de consultas descritas en la seccin 7.3.4, lo que se muestra en la gura 7.8.
Resumen
205
IdPCCM Componente IdPCCM Comportamiento(i1, j1, k1, l1, s2) 1 1 1 1 A16 M7 R2 A12
j1< - i1 j1= - i1 (l11+ k1 s2 0 l1>1+ k1) j1> - i1 (l1<1+ k1 s2 i1+ j1+ i1*k1+ j1* k1- i1*l1- j1*l1 l1=1+ k1 s2 0 l1>1+ k1)
(a) Tabla CARCs
(b) Tabla PCCM
Figura 7.8: Salida consulta con Proyeccin (VII) Como el operador OR no puede aparecer dentro de un atributo restriccin ser necesario transformar dicha restriccin a DNF (Disjunctive Normal Form) para representar cada una de las partes de la restriccin en una tupla diferente, ya que las relaciones entre las distintas tuplas es precisamente disyuntiva. La nueva relacin es por lo tanto la que se muestra en la gura 7.9.
7.6.
Resumen
En este captulo se presentan distintas deniciones relacionadas con la diagnosis de fallos basada en modelos. Este tipo de problema puede ser tratado con las BDdR, ya que el comportamiento de los componentes puede ser representado con restricciones polinmicas de igualdad o desigualdad. Esto hace posible que utilizando CORQL y LORCDB, se pueda realizar un proceso tan complejo como es la diagnosis de fallos exclusivamente mediante un conjunto de consultas. Tambin se presenta, para un ejemplo ms grande, distintos tipos de consultas relacionados con las operaciones de seleccin y proyeccin. En este captulo se puede apreciar cmo la sintaxis y la semntica de CORQL es vlida tanto para ejemplos de uso tan dispares como el econmico, mostrado en el captulo anterior, y la diagnosis de fallos, junto al tratamiento de sistemas de informacin geogrca que se presentar en el siguiente captulo. Esto facilita el desarrollo de cualquier aplicacin que necesite usar restricciones, ya que la arquitectura ofrece gran parte de la lgica de inferencia y las tcnicas que necesite utilizar. Adems cabe destacar la transparencia de cara al usuario con respecto al tipo de restricciones que se ven involucradas en la consulta, y de la tcnica necesaria para evaluarlas.
IdPCCM Componente
IdPCCM
Comportamiento(i1, j1, k1, l1, s2)
1 2 3 4 5 6
j1 < - i1 j1= -i1l11+k1s20 j1= - i1 l1>1+ k1 j1>-i1l1<1+k1 s2i1+ j1+i1 *k1 + j1 *k1 -i1 *l1- j1 *l1 j1> -i1l1=1+ k1s20 j1> - i1 l1>1+ k1
(a) Tabla CARCs
1 1 1 1 2 2 2 2 3 3 3 3 4 4 4 4 5 5 5 5 6 6 6 6
A16 M7 R2 A12 A16 M7 R2 A12 A16 M7 R2 A12 A16 M7 R2 A12 A16 M7 R2 A12 A16 M7 R2 A12
(b) Tabla PCCM
Figura 7.9: Salida consulta con Proyeccin (VIII)
Captulo 8 Optimizacin y Pruebas en la Evaluacin de Consultas en BDdR

En los captulos anteriores se han explicado las distintas decisiones tomadas para la denicin de un nuevo concepto y diseo de las Bases de Datos de Restricciones. Dichas decisiones tienen como objetivos dar capacidad expresiva y hacer la evaluacin de consultas lo ms eciente posible. En este captulo, se presentan distintas pruebas empricas para mostrar cmo dichas decisiones mejoran los tiempos de la evaluacin para las distintas operaciones. Todas estas pruebas se basarn en dos tipos de casos de estudio: por una parte la diagnosis basada en modelos, especialmente adecuada para la Proyeccin sobre variables; y los sistemas de informacin geogrca para el resto de operadores (Seleccin, Unin y Diferencia). Como ya se ha comentado en captulos anteriores, el Producto Cartesiano no conlleva ninguna modicacin del tratamiento de los datos con respecto a los tipos bsicos ya denidos en SQL, por lo que no se muestran pruebas para l. Para que la evaluacin de las consultas sea eciente en tiempo, se proponen distintas estrategias de resolucin para cada una de las operaciones, deniendo el orden del tratamiento de datos, junto a un conjunto de heursticas.
8.1.
Introduccin
Uno de los campos ms analizados en el rea de las bases de datos durante toda su historia, es la optimizacin de la evaluacin de consultas, entendida como la mejora de
208
Captulo 8. Optimizacin y Pruebas en la Evaluacin de Consultas en BDdR
los tiempos de respuesta de un sistema gestor de bases de datos. Mejorar la evaluacin de las consultas tambin implica la mejora de las operaciones de borrado y modicacin, ya que ambas operaciones consisten en seleccionar un conjunto de tuplas de una relacin que tienen que ser modicadas o borradas. Por esta razn, en este captulo se presenta cmo las decisiones de diseo de la arquitectura LORCDB han inuido en la mejora de los tiempos de evaluacin de consultas. En funcin del tipo de operacin que se ejecute en la base de datos, se recurrir a las distintas mejoras que se exponen a continuacin. Las decisiones de implementacin que estn involucradas con la mejora computacional de los tiempos de evaluacin de consultas son:
Estrategia de Optimizacin 1. Utilizacin del lgebra relacional: El modelo de Base de Datos de Restricciones propuesto, separa en atributos distintos aquellos que representan valores nicos, a los que se les ha denominado atributos univaluados, y los campos que describen restricciones. Esto permite que la Selec-
cin se realice en dos pasos, primero la obtencin de las tuplas que cumplen las
condiciones relacionadas con el lgebra relacional clsica, y luego las relacionadas con las restricciones en s. Tambin la utilizacin del lgebra relacional inuye en las operaciones de Unin y Diferencia, ya que ambas operaciones necesitan analizar si las tuplas de las relaciones involucradas son o no iguales. Para que dos tuplas sean iguales, lo tienen que ser sus atributos clsicos y sus atributos restriccin, siendo ms eciente empezar la comparacin por los atributos clsicos en lugar de por las restricciones, lo que implica la construccin y resolucin de menos problemas de satisfaccin de restricciones.
Estrategia de Optimizacin 2. Indexacin de variables: La arquitectura

propuesta almacena las relaciones entre las variables y las restricciones a las que pertenecen. Esto permite realizar la bsqueda del Conjunto de Restricciones Relacionadas por Variables (CRRV) necesaria en la operacin de Proyeccin Simbli-
ca y Numrica sobre atributos variable de restriccin. Si no se hiciera ningn tipo

de tratamiento para conocer las restricciones inferidas tras la eliminacin para la proyeccin simblica, sera necesario analizar las 2n 1 combinaciones posibles de conjuntos de restricciones, siendo n el nmero de restricciones implicadas. Esta indexacin tambin permite conocer, en operaciones como la Seleccin, Unin y la
Diferencia, si dos restricciones tienen o no las mismas variables.
Introduccin
209
Estrategia de Optimizacin 3. Almacemiento de envolventes de variables:

Cada vez que una restriccin se almacena en una Base de Datos de Restricciones, se almacena tambin el valor mximo y mnimo que pueden tomar cada una de sus variables. Esto permite conocer el grado de consistencia entre un conjunto de restricciones simplemente comparando dichas envolventes. De esta forma, simplemente con una consulta sobre atributos numricos y utilizando el lgebra relacional clsica, se puede conocer si es posible que dos restricciones compartan alguna solucin, si todos los valores que toman un conjunto de variables para hacer satisfactible una restriccin son mayores o menores que los que hacen satisfactible la otra restriccin, o si ambas restricciones pueden compartir las mismas soluciones. Dicho conocimiento es muy importante, con respecto a la eciencia computacional, en operaciones como la Seleccin, Unin y Diferencia. Otra tipo de operacin que es mejorable, en aspectos de eciencia, gracias a tener almacenado los valores mximos y mnimos de las variables es la proyeccin numrica para maximizar o minimizar una variable. En este tipo de operacin es necesario construir y resolver un problema de optimizacin de restricciones, lo que puede conllevar el anlisis de todo el espacio de bsqueda para conocer cul es el valor mayor o menor de dicha variable. Gracias a tener almacenado los valores mximos y mnimos de cada variable para cada restriccin, se puede utilizar como heurstica empezar la bsqueda instanciando la variable que se quiere maximizar o minimizar con el mximo o el mnimo valor respectivamente. Utilizando esta estrategia, se transformar el anlisis de todos el espacio de bsqueda por la bsqueda de la primera solucin. Esto es posible gracias a almacenar las envolventes de las variables, reduciendo as el espacio de bsqueda.
Estrategia de Optimizacin 4. Etiquetado de restricciones: Se han denido

cuatro tipos de etiquetas de restricciones, para conocer si son inecuaciones o ecuaciones, o para conocer si son lineales o polinmicas. El etiquetado relativo a si son o no restricciones de igualdad ayuda a conocer qu tcnica tiene que ser utilizada en la proyeccin simblica sobre variables de restriccin, mientras que el etiquetado que describen si son o no lineales ayuda a utilizar distintas heursticas de resolucin de problemas de satisfaccin de restricciones [85][77][151]. En este documento se analizan tres tipos de heursticas: por el dominio de las variables, por el tipo de restriccin a la que pertenece (lineal o polinmica), y por el grado de las variables
210
(nmero de restricciones en las que participa una variable). Estas cuatro estrategias se utilizarn de diferente manera para la evaluacin de las distintas operaciones. Para mostrar los distintos tiempos de evaluacin, para el operador de Proyeccin se utilizar la diagnosis basada en modelos presentada en el captulo 7. Esta eleccin es debida a que los ejemplos de sistemas de componentes a diagnosticar involucran muchas variables, enriqueciendo los tipos de proyeccin que se pueden hacer sobre las distintas variables. La bsqueda de las restricciones relacionadas por variables encuentra su caso ms desfavorable y computacionalmente complejo, cuando hay involucradas gran cantidad de variables. Para mostrar el estudio emprico de los operadores de seleccin, unin y diferencia es mucho ms apropiado utilizar como caso de estudio los sistemas de informacin geogrca, ya que su caso ms complejo y desfavorable es cuando las restricciones involucradas en la operacin comparten las mismas variables, lo que puede implicar la construccin y resolucin de problemas de satisfaccin de restricciones. Adems, el tratamiento de los sistemas de informacin geogrca es un rea de gran importancia y en auge en el campo de las BDdR. De esta forma, cada operacin se probar sobre los casos ms desfavorables, ya que la proyeccin sobre atributos variable de restriccin con las mismas variables no necesita obtener los CRRV, y la seleccin, la unin y la diferencia sobre restricciones con distintas variables, no necesita la creacin de problemas de satisfaccin de restricciones para resolverlas. En ambos casos de estudio se utilizar el dominio de los Flotante, ya que de forma general es computacionalmente ms complejo que los Enteros y los Naturales. Las pruebas temporales que se presentan en este documento sobre la evaluacin se han realizado en una mquina AMD Athlon 64 X 2 Dual Core a 2,21 Hz con 2 GB de
Memoria. Cada uno de los tiempos que aparecen en este captulo han sido obtenidos con
100 pruebas para obtener el tiempo medio de ejecucin de ellas, siempre presentado en
milisegundos.
8.2. Pruebas para el Operador de Proyeccin

La proyeccin sobre una relacin permite obtener un subgrupo vertical de los atributos que la forman. En el caso de las Bases de Datos de Restricciones esto signica obtener atributos clsicos, atributos restriccin o atributos variable de restriccin. El nico caso
Pruebas para el Operador de Proyeccin
211
que necesita de un tratamiento diferente al que hacen los gestores de bases de datos relacionales clsicas, es la obtencin de atributos variable de restriccin. Sern los distintos tipos de proyeccin en funcin de la salida y las restricciones involucradas, el objetivo de los ejemplos relacionados con este operador.
8.2.1. Ejemplo de Diagnosis Basada en Modelos

Como en el captulo 7 ya se introdujo el problema de la diagnosis basada en modelos y por qu se utiliza como caso de estudio en esta tesis, slo queda recordar el problema ya presentado que se vuelve a mostrar en la gura 8.1. Este sistema se divide a su vez en cuatro subsistemas etiquetados en la gura desde 1 hasta 4.
w1 y1 a1 b1 c1 d1 e1 f1 g1 h1 2 i1 j1 k1 l1 m n o p 1 a b c d
A1
A23
m1
M6
s1
A10
x1
M4
a2
A18
R1
n1 o1
A22
A11
z1 o2
A17
h2
M9
A14
R4
b2
A19
g2
t1
R5
i2
A15
p1
A16
r2 s2
R3 M8 A20 M10
4 p2
q1
M7
A12
k2 l2
M5
R2
r1
u1
A13
c2
A21
t2
A4 A6
q r
A9
q2
h i e
M2
A5
j
A3
k
A7
A8
M1 A2
g
M3
s u
Figura 8.1: Ejemplo de Diagnosis Las restricciones se almacenarn en una tabla llamada Componentes con los campos Identicador, Nombre y Comportamiento, donde Comportamiento es un atributo restriccin. El contenido exacto de esta tabla se muestran en las guras B.1, B.2, B.3 y
212
B.4 del Apndice B, donde cada tabla representa una parte de la tabla Componentes para cada uno de sus subsistemas. Las proyecciones que se realizan sobre dicho sistema contemplan los tres tipos posibles: simblicas, numricas y numrica con maximizacin o minimizacin de variables.
8.2.2. Mejoras en la Evaluacin de la Proyeccin Simblica

La Proyeccin Simblica sobre una relacin, es la obtencin de nuevas restricciones donde slo estn involucradas las variables denidas en la proyeccin. Si no se utilizara la arquitectura LORCDB, sera necesario analizar toda las combinaciones de restricciones, mientras que utilizando la indexacin propuesta se realizar la bsqueda de CRRV. Se presentan la comparacin de ambas estrategias, sin utilizar los CRRV y con CRRV para demostrar empricamente cmo se mejora la eciencia computacional.
Analizar todas las combinaciones de las restricciones: Este sera el caso donde
la base de datos tiene almacenadas las restricciones sin informacin adicional sobre qu variables relacionan qu restricciones. Para inferir todas las restricciones que se pueden obtener, en funcin de un conjunto de variables dadas en la proyeccin, es necesario probar las 2n 1 combinaciones, y que las tcnicas de eliminacin de cuanticadores obtuvieran las nuevas restricciones, en caso de que fuera posible.
Obtener los CRRV: Esto es posible gracias a la Estrategia 2, donde se propone

la indexacin entre las restricciones y las variables, junto a un algoritmo de bsqueda que permite conocer a priori slo las combinaciones de restricciones que inferirn nuevas restricciones relacionando slo un conjunto de variables.
8.2.3. Ejemplos de Pruebas usando Proyeccin Simblica

Para mostrar distintos usos de la proyeccin simblica para las distintas tcnicas de eliminacin simblica, se ha almacenado en la Base de Datos de Restricciones el ejemplo de la gura 8.1 que consta de diferentes tipos de restricciones. Los subsistemas 1 y 2 con inecuaciones polinmicas, y los subsistemas 3 y 4 con ecuaciones polinmicas. Los diez primeros ejemplos con operaciones de proyeccin simblica se harn sobre los subsistemas
3 y 4, por lo que se utilizarn las Bases de Grbner, mientras que los diez ltimos ejemplos
213
se harn sobre los subsistemas 1 y 2, por lo que se utilizar de Descomposicin Algebraica Cilndrica para la eliminacin de cuanticadores. Las medidas temporales que aparecen en las tablas slo tienen en cuenta el tiempo que tarda en realizarse la operacin de proyeccin, no la seleccin que ser analizada ms adelante. Las consulta con proyeccin simblica para este ejemplo tienen la sintaxis:
SELECT FULL CONSTRAINTS (Comportamiento.v1 , Comportamiento.v2 , . . .) FROM Componentes WHERE subsistema = n
donde n es el identicador del subsistema y v1 , v2 , . . . son las variables que se quieren obtener en la proyeccin pertenecientes al atributo Comportamiento. Se presentan algunos ejemplos de consultas, utilizando como variables los casos ms desfavorables, los cuales son aquellos donde estn relacionadas las variables de entrada y salida de cada uno de los subsistemas, lo que implica una bsqueda de CRRV ms compleja. Estos primero diez ejemplos son para eliminacin simblica de variables donde las restricciones involucradas son ecuaciones polinmicas, y por lo tanto utilizando las Bases de Grbner: 1. 2. Inferir las restricciones del subsistema 4 nicamente con las variables s2, t2, t, q 2. Inferir las restricciones del subsistema 4 nicamente con las variables a2, z 1, o2, r2,
g 2.
3. Inferir las restricciones del subsistema 4 nicamente con las variables r2, t1, s2, t2,
p2.
4. Inferir las restricciones del subsistema 4 nicamente con las variables a2, z 1, o2, r2,
t1, s2, t2, g 2, p2.

5. Inferir las restricciones del subsistema 4 nicamente con las variables s2, t2, t, r2,
t1, p2, q 2.
6. Inferir las restricciones del subsistema 4 nicamente con las variables s2, t2, t, a2,
z 1, o2, r2, g 2, q 2.
7. Inferir las restricciones del subsistema 4 nicamente con las variables s2, t2, t, a2,
z 1, o2, r2, t1, g 2, q 2, p2.
214
8.
Inferir las restricciones del subsistema 3 nicamente con las variables a1, b1, c1, d1,
y 1, a2.
9. 10. Inferir las restricciones del subsistema 3 nicamente con las variables c1, d1, y 1, z 1. Inferir las restricciones del subsistema 3 nicamente con las variables a1, b1, c1, d1,
y 1, a2, z 1.
Los tiempos medios de evaluacin de cada una de estas consultas se presentan en la tabla 8.1. Dicha tabla muestra el nmero de veces que se hace uso de las Bases de Grbner, y el tiempo medio de ejecucin en milisegundos para cada una de las consultas. El nmero de veces que se hace uso de las Bases de Grbner ser 2n 1 si se analizan todas las posibilidades, o el nmero de CRRV dependiente del subsistema y de las variables que se quieran obtener.
Consulta Todas las Combinaciones Nmero de Combinaciones Tiempo (ms) Slo CRRV Nmero de CRRV Tiempo (ms)
(1) (2) (3) (4) (5) (6) (7) (8) (9) (10)
210 1 = 1023 210 1 = 1023 210 1 = 1023 210 1 = 1023 210 1 = 1023 210 1 = 1023 210 1 = 1023 26 1 = 63 26 1 = 63 26 1 = 63
1,5045 105 1,2358 105 1,2386 105 1,3486 105 1,2385 105 1,2880 105 1,2399 105 8,9338 103 8,2281 103 8,2281 103
1 1 1 3 3 2 5 1 1 1
1,2871 102 1,2831 102 1,2910 102 4,5416 102 2,3815 102 4,2740 102 5,6727 102 1,3592 102 1,9431 101 2,4359 102
Tabla 8.1: Comparacin para la evaluacin de Proyecciones Simblicas utilizando las Bases de Grbner De una forma similar se realiza la comparacin entre la utilizacin o no de los CRRV cuando las restricciones involucradas en la relacin son inecuaciones polinmicas. En este caso los ejemplos de proyeccin son: 1. Inferir las restricciones del subsistema 2 nicamente con las variables w1, e1, f 1,
g 1, h1, o2.
215
2.
Inferir las restricciones del subsistema 2 nicamente con las variables e1, f 1, g 1, h1,
r2.
3. Inferir las restricciones del subsistema 2 nicamente con las variables i1, j 1, k 1, l1,
s2.
4. 5. Inferir las restricciones del subsistema 2 nicamente con las variables k 1, l1, t2. Inferir las restricciones del subsistema 2 nicamente con las variables w1, e1, f 1,
g 1, h1, o2, r2.

6. Inferir las restricciones del subsistema 2 nicamente con las variables e1, f 1, g 1, h1,
i1, j 1, k 1, l1, r2, s2.

7. Inferir las restricciones del subsistema 2 nicamente con las variables i1, j 1, k 1, l1,
s2, t2.
8. Inferir las restricciones del subsistema 1 nicamente con las variables a, b, c, d, m,
n, o, p, r.
n, o, p, t.
n, o, p, r, t.
Los tiempos medios de evaluacin de cada una de estas consultas se presenta en la tabla 8.2. Dicha tabla muestra el nmero de veces que se hace uso de la Descomposicin Algebraica Cilndrica, y el tiempo medio de ejecucin en milisegundos para cada una de las consultas. Al igual que para los sistemas con inecuaciones polinmica, el nmero de veces que se hace uso de la Descomposicin Algebraica Cilndrica ser 2n 1 si se analizan todas las posibilidades, o el nmero de CRRV dependiente del subsistema y de las variables que se quieran obtener.
8.2.4. Conclusiones para el operador de Proyeccin Simblica

Para mostrar grcamente las diferencias con respecto al tiempo de evaluacin de la proyeccin analizando todas las combinaciones o slo los CRRV, se presentan las guras
216
Consulta
Todas las Combinaciones Nmero de Combinaciones Tiempo (ms)
Slo CRRV Nmero de CRRV Tiempo (ms)
(1) (2) (3) (4) (5) (6) (7) (8) (9) (10)
210 1 = 1023 210 1 = 1023 210 1 = 1023 210 1 = 1023 210 1 = 1023 210 1 = 1023 210 1 = 1023 212 1 = 4095 212 1 = 4095 212 1 = 4095
1,3147 106 1,3329 106 1,3247 106 1,4320 106 1,5847 106 1,3250 106 1,5522 106 3,6122 106 3,4882 106 3,8114 106
1 1 1 1 3 2 2 1 1 1
1,4657 103 1,4424 103 1,5754 103 1,4273 103 3,9177 103 2,8363 103 2,9097 103 1,2838 104 2,9334 104 8,9334 104
Tabla 8.2: Comparacin para la evaluacin de Proyecciones Simblicas utilizando Descomposicin Algebraica Cilndrica 8.2 y 8.3. La gura 8.2 muestra los datos presentados en la tabla 8.1 relativos al tiempo de evaluacin, sin ningn tipo de mejora (- -) o slo analizando los CRRV (- -). La gura 8.3 presenta la comparacin de los tiempos de evaluacin presentados en la tabla 8.2, sin ninguna mejora (- -) y slo analizando los CRRV (- -). Ambas guras utilizan la escala logartmica para facilitar la presentacin de los datos, pudiendo as observar la mejora cuantitativa utilizando la bsqueda de los CRRV que puede llegar a ser hasta
1000 veces ms rpida. Dicha mejora se hace ms notable para los sistemas con muchos
componentes, ya que el nmero de combinaciones crece exponencialmente en funcin del nmero de restricciones.
8.2.5. Mejoras en la Evaluacin de la Proyeccin Numrica

Cuando la proyeccin sobre una relacin con restricciones requiere la obtencin de un conjunto de los valores instanciados de las variables denidas en dicha proyeccin, se construir y resolver un problema de satisfaccin de restricciones. Dicho problema de satisfaccin de restricciones se crear con todas las restricciones involucradas en la relacin como se explic en la seccin 6.4.1. Para resolver el problema de satisfaccin de restricciones y obtener dichos valores, existe un conjunto de heursticas para mejorar los
217
1,00E+06 1,00E+05
Tiempo (ms)
1,00E+04 1,00E+03 1,00E+02 1,00E+01 1,00E+00 1 2 3 4 5 6 7 8 9 10
Todas las Combinaciones Slo CRRV
Figura 8.2: Tiempos de Evaluacin para Proyeccin Simblica para Ecuaciones Polinmicas
1,00E+07 1,00E+06
Tiempo (ms)
1,00E+05 1,00E+04 1,00E+03 1,00E+02 1,00E+01 1,00E+00 1 2 3 4 5 6 7 8 9 10 Todas las Combinaciones Slo CRRV
Figura 8.3: Tiempos de Evaluacin para Proyeccin Simblica para Inecuaciones Polinmicas tiempos, basadas en la ordenacin de variables y valores, lo cual tiene un signicativo impacto en el tamao del espacio de bsqueda [38][43][52][53][83]. En este captulo se van a utilizar algunas de estas heursticas, comparando los tiempos de evaluacin con la resolucin del problema sin utilizar ninguna de ellas. Las pruebas relativas a las heursticas son:
Sin heursticas: Construccin de CSP sin heursticas, realizando la bsqueda en

el orden en el que la base de datos devuelve las restricciones y las variables.
218
Por el dominio de las variables: Comenzar la bsqueda con las variables con el
dominio ms pequeo, lo que se puede hacer gracias a que la arquitectura LORCBD almacena las envolventes de cada variable (Estrategia 3).
Por tipo de restriccin: Comenzar por las variables que se encuentran en restricciones lineales, analizando primero las restricciones lineales y luego las polinmicas (Estrategia 4).
Por grado de las variables: Comenzar por las variables de mayor grado, lo que
se dene como el nmero de restricciones en las que participa una variables. Gracias a utilizar las tablas de indexacin entre variables y restricciones, es muy sencillo conocer el grado de las variables (Estrategia 2). Precisamente por ser heursticas, los tiempos de evaluacin dependern del tipo de problema [148], no siendo posible denir una heurstica como la mejor de forma global.
8.2.6. Ejemplos de Pruebas usando la Proyeccin Numrica

Para todos los ejemplos se obtendrn los 10 primeros valores que encuentre que hagan las restricciones involucradas satisfactibles. El nmero de tuplas que se quieren obtener, 10 en este caso, ser el mismo para todas las heursticas para que no inuya en la comparativa. La proyeccin numrica para este ejemplo tienen la sintaxis:
SELECT VALUES[10] (Comportamiento.v1 , Comportamiento.v2 , . . .) FROM Componentes WHERE subsistema = n
donde n es el identicador del subsistema y v1 , v2 , . . . son las variables que se quieren obtener en la proyeccin numrica pertenecientes al atributo restriccin Comportamiento. Se ha realizado un ejemplo de proyeccin en cada subsistema, ya pese a que slo se muestra un conjunto de variables, se tiene que encontrar una solucin para las restantes aunque no formen parte de la salida. Esto implica que el tiempo de resolucin de un problema de satisfaccin de restricciones ser independiente de las variables que se presenten como solucin. Los ejemplos utilizados son: 1. Obtener 10 tuplas de valores del subsistema 4 para las variables a2, z 1, b2, r2, t1,
g 2.
219
2. 3. 4.
Obtener 10 tuplas de valores del subsistema 3 para las variables n1, m1, a1, y 1, a2. Obtener 10 tuplas de valores del subsistema 2 para las variables e1, f 1, g 1, h1, t1. Obtener 10 tuplas de valores del subsistema 1 para las variables a, b, c, d, u. La comparacin utilizando las diferentes heursticas, presentada en milisegundos, es la
expuesta en la tabla 8.3.

Consulta Sin heurstica Tiempo (ms) Por dominio Tiempo (ms) Por tipo de restriccin Tiempo (ms) Por grado Tiempo (ms)
(1) (2) (3) (4)
49,884 34,157 31,981 38,797
30,408 30,957 31,985 37,748
29,883 28,311 31,457 25,690
32,142 27,145 31,452 28,1312
Tabla 8.3: Comparacin para la evaluacin de Proyecciones Numricas
8.2.7. Conclusiones para el operador de Proyeccin Numrica

En la gura 8.4 se presentan los tiempos para los cuatro ejemplos de proyeccin mostrados en la tabla 8.3. En dicha gura se presenta grcamente la comparacin utilizando las cuatro posibilidades descritas para resolver el problema de satisfaccin de restricciones: sin heurstica (- -); comenzando por las variables de menor dominio (- -); comenzando por variables que se encuentran en restricciones lineales (- -); y comenzando por las variables de mayor grado (--). Pese a que los tiempos obtenidos con las heursticas son prometedores, no se puede generalizar y denir una heurstica como la mejor. Lo que s cabe destacar es que la arquitectura LORCBD facilita llevar a cabo dichas heursticas, pudiendo hacerse de forma transparente para el usuario.
8.2.8. Mejoras en la Evaluacin de la Proyeccin Numrica con Optimizacin de Variable

Cuando la proyeccin sobre una relacin con restricciones requiere de la obtencin del mayor o el menor valor que puede tomar una variable, ser necesario construir y
220
60 50 Sin Heurstica Por dominio Por tipo de Restriccin Por grado 10 0 1 2 3 4
Tiempo (ms)
40 30 20
Figura 8.4: Tiempos de Evaluacin para Proyeccin Numrica resolver un problema de optimizacin de restricciones. Dicho problema de optimizacin de restricciones se crear con todas las restricciones involucradas en la relacin como se explic en la seccin 6.4.1. En este caso se realizar la comparacin entre estudiar todo el espacio de bsqueda, o utilizar una estrategia derivada de las envolventes de las variables. La comparacin de los distintos tiempos de ejecucin se har de la forma:
Estudiar todo el espacio de bsqueda: Con el objetivo de maximizar o minimizar la variable denida en la proyeccin.
Comenzar la bsqueda por la variable objetivo con un valor de terminado (el mximo o el mnimo): De esta forma se comienza la bsqueda instanciando
la variable a maximizar por su mayor valor, o en el caso de la minimizacin por el menor valor de dicha variable (Estrategia 3). Esto implica transformar el anlisis de todo el espacio de bsqueda en la bsqueda de la primera solucin.
8.2.9. Ejemplos de Pruebas usando la Proyeccin Numrica con Optimizacin

En este caso se presentan diez ejemplos de proyeccin donde se quieren obtener el mximo valor que puede tomar una variable. Si no se utiliza ningn tipo de mejora, el tiempo depender de las restricciones que forman el COP, mientras que si se realiza la transformacin del anlisis de todo el espacio de bsqueda en la bsqueda de una solucin, el tiempo se reducir drsticamente.
221
La sintaxis de los ejemplos de proyeccin para este caso es:

SELECT MAX VALUE(Comportamiento.v ) FROM Componentes WHERE subsistema = n
donde n es el identicador del subsistema y v la variable a maximizar perteneciente al atributo Comportamiento. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Obtener el mximo valor que puede tomar la variable u para el subsistema 1. Obtener el mximo valor que puede tomar la variable t para el subsistema 1. Obtener el mximo valor que puede tomar la variable q para el subsistema 1. Obtener el mximo valor que puede tomar la variable t1 para el subsistema 2. Obtener el mximo valor que puede tomar la variable s2 para el subsistema 2. Obtener el mximo valor que puede tomar la variable a2 para el subsistema 3. Obtener el mximo valor que puede tomar la variable y 1 para el subsistema 3. Obtener el mximo valor que puede tomar la variable g 2 para el subsistema 4. Obtener el mximo valor que puede tomar la variable q 2 para el subsistema 4. Obtener el mximo valor que puede tomar la variable p2 para el subsistema 4. Cuyos tiempos de evaluacin, utilizando las dos estrategias explicadas, se presentan en la tabla 8.4.
8.2.10. Conclusiones para el operador de Proyeccin Maximizando valores de Variables

En la gura 8.5 se presenta, utilizando la escala logartmica, la comparativa de todos los tiempos en milisegundos para las diez pruebas. Por una parte se analiza todo el espacio de bsqueda (- -), y por otra se utiliza la estrategia de comenzando la bsqueda por la variable objetivo (- -). En dicha grca se puede observar que la mejora es cuantitativamente muy superior pudiendo obtener hasta una solucin 10.000 veces mejor en algunos
222
Consulta
Todo el Espacio de Bsqueda
Por Variable Objetivo
(1) (2) (3) (4) (5) (6) (7) (8) (9) (10)
6,8607 105 6,8607 105 6,8607 105 1,5090 106 1,5090 106 9,7087 105 9,7087 105 1,1539 106 1,1539 106 1,1539 106
7,5497 102 7,9927 102 8,1328 102 7,5943 102 8,2365 102 7,3478 102 7,5647 102 8,4934 102 7,6414 102 1,2801 102
Tabla 8.4: Comparacin para la Evaluacin de Proyecciones Numrica con Optimizacin casos, ya que la opcin del anlisis de todo el espacio de bsqueda es muy costosa en tiempo. Esto es posible gracias a almacenar el mximo y mnimo valor de cada variable en la base de datos.
1,00E+07 1,00E+06
Tiempo (ms)
1,00E+05 1,00E+04 1,00E+03 1,00E+02 1,00E+01 1,00E+00 1 2 3 4 5 6 7 8 9 10 Todas las soluciones Por Variable Objetivo
Figura 8.5: Tiempos de Evaluacin para Proyeccin Numrica con Optimizacin
Los Sistemas de Informacin Geogrca y LORCDB
223
8.3.
Los Sistemas de Informacin Geogrca y LORCDB
El rea de los sistemas de informacin geogrca ha sido el caso de estudio ms analizado en el tratamiento de las Bases de Datos de Restricciones, ya que las restricciones son una forma natural de representar elementos geomtricos, propios de los sistemas de informacin geogrca. Es por esta razn, por la que en esta memoria de tesis se presenta cmo pueden ser tratados con la arquitectura LORCDB, y qu ventajas aade la utilizacin de dicha arquitectura. Las aplicaciones comerciales para el tratamiento de sistemas de informacin geogrca como Oracle SpatialT M , SigPacT M o ArcGisT M utilizan dos formas para almacenar dichos datos: mediante mallas o celdas de bits (raster); o de forma vectorial (puntos, lneas y polgonos). Esta representacin tiene tres claros inconvenientes: la saturacin de la base de datos con gran cantidad de informacin; la prdida de precisin, ya que se tendr que aproximar la informacin con lneas; y la falta de expresividad, ya que las ecuaciones no se almacena como tal. Derivado de estas desventajas, existe la problemtica de una mayor complicacin de las operacin de modicacin de la base de datos, ya que si para almacenar una determinado objeto son necesarios ms registros, tambin ms registros tendrn que modicarse si dicho objeto cambia o es eliminado. Con el objetivo de paliar dichos inconvenientes, las BDdR proponen sustituir las mallas y los vectores por restricciones. Otra de las razones para abordar los sistemas de informacin geogrca en esta tesis, es la realizacin de las distintas pruebas con los operadores de seleccin, unin y diferencia. Dichos operadores son ms complejos cuando en las relaciones sobre las que se opera hay involucradas restricciones con las mismas variables. Mientras que los sistemas para realizar la diagnosis basada en modelos estn formados por muchas variables, los sistemas de informacin geogrca estn formadas por muchos restricciones denidas sobre las mismas variables. Esto implica que los sistemas de informacin geogrca son un caso complejo de evaluacin de la seleccin, unin y diferencia, ya que las comparaciones entre las restricciones de las distintas tuplas conllevar, en algunos casos, construir y resolver problemas de satisfaccin de restricciones. Lo primero para poder hacer consultas sobre un conjunto de restricciones de una Base de Datos de Restricciones es almacenarlas. Para construir un conjunto de tablas relacionadas con informacin geogrca, sobre las que hacer las consultas, se ha desarrollado
224
e implementado una aplicacin que ayuda a la captura de puntos de un mapa con el objetivo de obtener las restricciones y almacenarlas en la Base de Datos de Restricciones. Toda la informacin sobre la aplicacin se encuentra en la Seccin B.2 del Apndice B. Dicha aplicacin utiliza el mtodo de Lagrange para la aproximacin mediante polinomios a un conjunto de puntos, dicho mtodo utiliza la interpolacin mediante mnimos cuadrados [54][7]. La utilizacin de polinomios tambin conlleva una aproximacin de la realizada, pero que se acerca ms a la informacin real y con menor nmero de restricciones que si se utilizan slo lneas.
8.3.1. Informacin almacenada en la LORCDB

Para denir diversos ejemplos donde la seleccin, la unin y la diferencia se pueden ver involucradas, se crean cuatro tablas diferentes. Dichas tablas tendrn atributos restriccin para almacenar la posicin de un grupo de Residenciales, Calles, Zonas de Censo y Obras que se estn realizando en la zona. En la gura 8.6 se muestra la vista hbrida obtenida con Google Maps [105] de una zona de Sevilla, donde se pueden observar las distintas calles con sus nombres. Las restricciones concretas de estas 26 calles se encuentran en la gura B.6 del Apndice B. Las calles se almacenarn en la tabla Calles creada con la sentencia:
CREATE TABLE Calles(Id Integer, Nombre String, Situacion Constraint, Tipo String)
Como atributos a destacar estn el campo Situacion que almacena las restricciones que describe cada calle, y el tipo que denir si es 'calle' o 'avenida' tomando estas dos cadenas como posibles valores. Para enriquecer las consultas, tambin se ha incluido la tabla Residenciales con los residenciales de la zona, creada mediante la sentencia:
CREATE TABLE Residenciales(Id Integer, Nombre String, Situacion Constraint)
En esta tabla, como atributo a destacar est el atributo restriccin Situacion que almacena una combinacin conjuntiva de inecuaciones lineales y polinmicas. El contorno de los residenciales se muestra en la gura 8.7, mientras que las restricciones de los 27 residenciales concretos se muestran en la gura B.7 del Apndice B, y las envolventes de las variables en la gura B.8 del mismo apndice.
Pruebas para el Operador de Seleccin
225
Figura 8.6: Vista del Mapa Hbrida Tambin se crear en la base de datos otra tabla para almacenar los censos electorales de la zona, que se muestran en la gura 8.8, y cuyas restricciones concretas se encuentran en la gura B.9 del apndice B. La tabla Censos ser creada mediante la sentencia:
CREATE TABLE Censos(Id Integer, Nombre String, Situacion Constraint)
Cada una de las tres tablas creadas representa una capa sobre las variables (x, y), permitiendo almacenar, en poco espacio y manteniendo la simbologa, la informacin relativa a calles, residenciales y censos. Queda por describir la ltima tabla Obras, que se detallar cuando se analicen las operaciones de unin y diferencia, ya que slo se utilizan en consultas de ese tipo.
8.4.
Partiendo de una relacin donde hay involucradas restricciones, la seleccin devolver un subconjunto horizontal de dicha relacin con aquellas tuplas que cumplan una condicin dada. Dicha condicin deber estar relacionada con las restricciones que conforman la
226
Figura 8.7: Residenciales de la zona tupla, utilizando los operadores <, , >, , =, <> &, , , y , presentados en el captulo 4. En esta seccin se presenta un conjunto de consultas con estos operadores de comparacin, y las mejoras relacionadas con la evaluacin del operador de seleccin. Los casos que se compararn son:
Sin Mejora: Esto signica crear todos los CSP necesarios para la comparacin de
las restricciones. Si las restricciones estuvieran almacenadas sin informacin relativa a las envolventes de las variables, sera necesario crear un problema de satisfaccin de restricciones para cada tupla con restricciones. Si la comparacin se hiciera entre dos atributos restriccin, eso conllevar realizar n m problemas de satisfaccin de restricciones donde n y m representan el nmero de tuplas de cada una de las relaciones.
Con lgebra Relacional: Lo que signica crear los CSP slo con las tuplas que
cumplan las condiciones establecidas con el lgebra relacional sobre los atributos clsicos. Si adems de condiciones relativas a un atributo restriccin existen condiciones relativas a atributos univaluados, no ser necesario crear problemas de satisfaccin de restricciones con aquellas tuplas que no cumplan las condiciones del
227
Figura 8.8: Censos de la zona lgebra relacional clsica (Estrategia 1). Esta seleccin la realizar el gestor de bases de datos relacionales.
Analizando Envolventes: Lo que implica crear los CSP slo con las restricciones que cumplan las envolventes, derivado de la Estrategia 3. Analizando las envolventes de las restricciones se puede obtener mucha informacin sobre ella, y slo para algunos casos ser necesario crear un problema de satisfaccin de restricciones. Estos casos ya han sido enumerados en la seccin 6.2.
Aadiendo Envolventes: Incluyendo los dominios de las variables en los CSP para acotar ms la bsqueda, derivado tambin de la Estrategia 3. Ya que se
tienen almacenadas las envolventes de las variables, stas pueden ser incluidas en los problemas de satisfaccin de restricciones para acotar ms la bsqueda.
8.4.1. Ejemplos de Pruebas usando Seleccin

Se propone un conjunto de diez consultas con distintas operaciones de comparacin entre restricciones, utilizando las tres tablas incluidas en la base de datos (Residenciales,
228
Calles y Censos). Se utilizarn cuatro estrategias diferentes, anotando el nmero de CSP

que se tienen que crear y resolver para evaluar la seleccin, y el tiempo de ejecucin de cada consulta. Dichos ejemplos utilizan condiciones de atributos clsicos combinados con atributos restriccin. Entre las operaciones de comparacin entre restricciones se encuentran todos los operadores de comparacin descritos, junto a ejemplos donde la comparacin se realiza con restricciones aadidas en la propia consulta, no pertenecientes a las relaciones almacenadas. 1.
Qu residenciales estn al este de la Avenida de las Ciencias? La descripcin detallada de esta consulta ser: obtener todos los residenciales r tal que para todo (x, y) que sea solucin de la Avenida de las Ciencias y para todo (x', y) que sea solucin de r, siempre x x'. La consulta ser:
SELECT Residenciales.Nombre FROM Residenciales, Calles WHERE Residenciales.Situacion >= (Calles.Situacion FOR x AND Calles.Situacion.y = Residenciales.Situacion.y) AND Calle.Nombre = 'Avd de las Ciencias'
2.
Qu residenciales estn al oeste de la calle Flor de Albahaca? La descripcin detallada de esta consulta ser: obtener todos los residenciales r tal que para todo (x, y) que sea solucin de Flor de Albahaca y para todo (x', y) que sea solucin de r, siempre x x'. La consulta ser:
SELECT Residenciales.Nombre FROM Residenciales, Calles WHERE Residenciales.Situacion <= (Calles.Situacion FOR x AND Calles.Situacion.y = Residenciales.Situacion.y) AND Calles.Nombre = 'Flor de Albahaca'
3.
Qu residenciales estn al norte de la calle Flor de Salvia? La descripcin

detallada de esta consulta ser: obtener todos los residenciales r tal que para todo (x, y) que sea solucin de Flor de Salvia y para todo (x, y') que sea solucin de r, siempre y' y. La consulta ser:
SELECT Residenciales.Nombre FROM Residenciales, Calles WHERE Calles.Situacion <= (Residenciales.Situacion FOR y
229
AND Calles.Situacion.x = Residenciales.Situacion.x) AND Calles.Nombre = 'Flor de Salvia'
4.
Qu residenciales estn ms al norte (tienen mayor latitud) que el residencial 'Entre Parques' ? La descripcin detallada ser: obtener todos los residenciales r tal que para todo (x, y) que sea solucin de Entre Parques y para todo (x', y') que sea solucin de r, siempre y' > y. La consulta ser:
SELECT r.Nombre FROM Residenciales as r, Residenciales as r1 WHERE r1.Nombre = 'Entre Parques' AND r.Situacion > (r1.Situacion FOR y)
5.
Qu residenciales estn ms al noreste que el residencial Galileo (estn a ms latitud y longitud)? La descripcin detallada ser: obtener todos los
residenciales r tal que para todo (x, y) que sea solucin de Galileo y para todo (x', y') que sea solucin de r, siempre y' > y y x' > x. La consulta ser:
SELECT r1.Nombre FROM Residenciales as r, Residenciales as r1 WHERE r.Nombre = 'Galileo' AND r.Situacion < r1.Situacion
6.
Qu calles estn exclusivamente en el censo 2? La descripcin detallada ser:

obtener todas las calles c tal que para todo (x, y) que sea solucin de c tambin lo es del censo 2. La consulta ser:
SELECT Calles.Nombre FROM Censos, Calles WHERE Censos.Nombre = 'Censo 2' AND Calles.Situacion Censos.Situacion
7.
Qu residenciales pertenecen al censo 3? La descripcin detallada ser: obtener todos los residenciales r tal que para todo (x, y) que sea solucin de r tambin lo es del censo 3. La consulta ser:
SELECT Residenciales.Nombre FROM Residenciales, Censo WHERE Censos.Nombre = 'Censo 3' AND Censos.Situacion Residenciales.Situacion
230
8.
Qu avenidas pertenecen al censo 2? La descripcin detallada ser: obtener

todos las calles c que sean de tipo avenida, donde existe un valor de (x, y) que es solucin de c y tambin lo es del censo 2. La consulta ser:
SELECT Calles.Nombre FROM Censo, Calles WHERE Censos.Nombre='Censo 2' AND Censos.Situacion & Calles.Situacion AND Calles.Tipo = 'avenida'
9.
Qu residenciales estn ms al norte (a mayor latitud) que la rotonda (x 177)2 + (y 288)2 222 ? Este es un ejemplo de insercin de restricciones en
la consulta que no estn previamente almacenadas en la base de datos. La consulta ser:
SELECT Residenciales.Nombre FROM Residenciales WHERE Residenciales.Situacion > ((x 177)2 + (y 288)2 222 FOR y )
10.
Qu residenciales estn ms al este que la rotonda (x 177)2 + (y 288)2 222 ? La consulta ser:
SELECT Residenciales.Nombre FROM Residenciales WHERE Residenciales.Situacion > ((x 177)2 + (y 288)2 222 FOR x)
Los datos relativos al tiempo y al nmero de CSP que se crean para cada seleccin se muestran en la tabla 8.5. En esta tabla se presentan los cuatro tipos de medias para el caso sin mejoras, y cmo el nmero de problemas de satisfaccin de restricciones y el tiempo se van decrementando cada vez que se va aadiendo cada una de las tres mejoras. Esto signica que la ltima columna contiene los resultados cuando se utilizan las tres mejoras para la evaluacin de la seleccin.
8.4.2. Conclusiones para el operador de Seleccin

Tras realizar todas las medidas temporales y crear los CSP necesarios, en la gura 8.9 se presenta grcamente toda la informacin relativa a los tiempos de ejecucin. Cada una de las medidias, representadas con distintos colores en el grco, muestra cmo decrementan los tiempos de ejecucin cuando las mejoras se van incorporando. Los datos se presentan en
231
Sin Consulta Mejora Nmero de CSP (ms)
Con lgebra Relacional de CSP (ms)
Analizando Envolventes de CSP (ms)
Aadiendo Envolventes Tiempo (ms) de CSP
Tiempo Nmero
Tiempo Nmero
Tiempo Nmero
(1) (2) (3) (4) (5) (6) (7) (8) (9) (10)
2627 2627 2627 2627 2627 263 273 263 27 27
5,0745103 3,2044103 4,3165103 4,2456103 8,5145103 1,5598103 1,6373103 9,0265102 1,6808103 7,3295102
27 27 27 27 27 27 27 2 27 27
1,4755103 1,4466103 1,6655103 9,2444102 2,0255103 1,4467103 9,0247102 7,0245102 1,6808103 7,3295102
20 3 2 0 0 12 7 2 0 0
7,6475102 7,1346102 6,8030102 2,0991 2,0971 7,9477102 7,9627102 7,0236102 4,1943 3,1457
20 3 2 0 0 12 7 2 0 0
7,5334102 6,9327102 6,6032102 2,0991 2,0971 7,9453102 7,8622102 7,0277102 4,1943 3,1457
Tabla 8.5: Comparacin para la Evaluacin de la Seleccin milisegundos y utilizando la escala logartmica para mostrar ms claramente las diferencias temporales. Estas mejoras vienen derivadas de la reduccin del nmero de problemas de satisfaccin de restricciones, mostrada en la gura 8.10, tambin presentada utilizando la escala logartmica. Como se puede observar en la grca de la gura 8.9, existen consultas donde se obtienen evaluaciones del orden de hasta 1000 veces ms ecientes que sin utilizar ninguna mejora. En casos como las consultas 3, 4, 9, y 10, no es necesario construir ningn CSP ya que el simple anlisis de la envolvente, que no es ms que una consulta clsica sobre atributos numricos, es suciente. Tambin se puede observar que siempre el nmero de CSP del tercer (- -) y cuarto (--) caso son iguales, y el tiempo de evaluacin muy similar, ya que la cuarta mejora slo implica incluir las envolventes, no reducir el nmero de CSP. Si no se hiciera referencia a atributos clsicos en la condicin, el tiempo y el nmero de los CSP construidos de la primera y segunda prueba para cada ejemplo, seran iguales.
232
1,00E+04
1,00E+03 Sin Mejora Tiempo (ms) 1,00E+02 Con Algebra Relacional Analizando Envolventes Aadiendo Envolventes 1,00E+01
1,00E+00 1 2 3 4 5 6 7 8 9 10
Figura 8.9: Tiempos de Evaluacin para la Seleccin

1000
100
Nmero de CSP creados
Sin Mejora Con lgebra Relacional Analizando Envolvente Aadiendo Envolvente
10
1 1 2 3 4 5 6 7 8 9 10
Figura 8.10: Nmero de CSP creados para la Seleccin
8.5. Pruebas para el Operador de Unin

La unin entre dos relaciones devolver una nueva relacin con las tuplas de ambas sin repeticin. Cuando en las tuplas involucradas en la operacin de unin hay atributos de tipo restriccin, es necesario analizar dichos atributos para cerciorarse de que las tuplas con dichas restricciones no son iguales. La comparacin entre dos restricciones no pueden ser exclusivamente morfolgica, ya que dos restricciones pueden tener las mismas soluciones y estar representadas de forma distinta, por ejemplo 2y = 2x + 2 y y = x + 1. Cmo comparar dos tuplas con atributos restriccin de una manera eciente se ha explicado en la seccin 6.5. Para esta operacin se proponen 10 ejemplos, donde se muestra la comparativa aadiendo cada una de las estrategias de optimizacin. Las comparaciones se realizarn sobre los casos:
Pruebas para el Operador de Unin
233
Sin Mejora: Creando todos los posibles CSP entre dos relaciones R1 , R2 con restricciones, siendo necesario crear un CSP con una restriccin de R1 y otra de R2 para conocer si comparten todas las soluciones. Esto signica que existen n m posibilidades donde m y n son el nmero de tuplas de R1 y R2 respectivamente.
Con lgebra Relacional: Creando CSP con las tuplas que tengan todos los atributos clsicos iguales, utilizando la Estrategia 1. Si una tupla de R1 y otra de R2
tienen al menos uno de sus atributos clsicos o univaluados distintos, no sera necesario crear un CSP para esa opcin ya que independientemente de las restricciones, dichas tuplas son distintas y ambas formarn parte de la relacin de salida.
Analizando las Envolventes: Creando los CSP slo con las restricciones que cumplan las envolventes, como se explica en la seccin 6.5. La envolvente de las variables de las restricciones da informacin sobre si las restricciones pueden compartir o no soluciones. Si los valores denidos por las envolventes de las restricciones no tienen ningn valor en comn o slo algunos, no ser necesario crear un CSP con esas restricciones ya que seguro que las restricciones no son iguales. Sin embargo, si las envolventes de las variables de una restriccin estn incluidas en la otra, ser necesario comprobar mediante un CSP, si realmente una restriccin est incluida dentro de otra aunque lo estn sus envolventes. Para facilitar las consultas y enriquecer los ejemplos se aade una nueva tabla Obras a la Base de Datos de Restricciones. La tabla Obras almacenar 25 zonas donde se van a realizar obras en los prximos aos, como se muestra en la gura 8.11. Los detalles de cada una de las restricciones almacenadas en la tabla Obras se muestran en la gura B.10 del Apndice B.
8.5.1. Ejemplos de Pruebas usando la Unin

En el anlisis de tiempos para los prximos ejemplos, slo tendrn en cuenta el tiempo de la evaluacin de la operacin de unin, una vez que las relaciones de entrada se han obtenido. 1. Obtener la situacin (atributo Situacion) de las calles y residenciales. La consulta ser:
234
7 15 18 20 21 16 22 23 19 10 24 17 25 8 14 13 11 12
1 3
2 4
5 6
Figura 8.11: Obras de la zona
SELECT Calles.Situacion FROM Calles UNION SELECT Residenciales.Situacion FROM Residenciales
2.
Para los residenciales y la calles, obtener los identicadores de censos a los que pertenecen y su situacin. La consulta ser:
SELECT Censos.Id, Calles.Situacion FROM Censos, Calles WHERE Calles.Situacion Censos.Situacion UNION SELECT Censos.Id, Residenciales.Situacion FROM Censos, Residenciales WHERE Residenciales.Situacion Censos.Situacion
3.
Obtener los identicadores de obras y las situaciones de las calles y residenciales, ambas del censo 1, que les afecte alguna obra. La consulta ser:
SELECT Obras.Id, Calles.Situacion FROM Obras, Calles, Censos WHERE Calles.Situacion & Obras.Situacion AND Calles.Situacion Censos.Situacion AND Censoa.Id = 1
235
UNION SELECT Obras.Id, Residenciales.Situacion FROM Obras, Residenciales, Censos WHERE Residenciales.Situacion & Obras.Situacion AND Residenciales.Situacion Censos.Situacion AND Censos.Id = 1
4.
Obtener los identicadores de obras y las situaciones de las calles y residenciales que les afecte alguna obra. La consulta ser:
SELECT Obras.Id, Calles.Situacion FROM Obras, Calles WHERE Calles.Situacion & Obras.Situacion UNION SELECT Obras.Id, Residenciales.Situacion FROM Obras, Residenciales WHERE Residenciales.Situacion & Obras.Situacion
5.
Obtener los identicadores de censo y las situaciones de las obras y las calles. La consulta ser:
SELECT Censos.Id, Obras.Situacion FROM Obras, Censos WHERE Obras.Situacion & Censos.Situacion UNION SELECT Censos.Id, Calles.Situacion FROM Calles, Censos WHERE Calles.Situacion & Censos.Situacion
6.
Obtener los identicadores de censo y las situaciones de las obras y los residenciales. La consulta ser:
SELECT Censos.Id, Obras.Situacion FROM Obras, Censos WHERE Obras.Situacion & Censos.Situacion UNION SELECT Censos.Id, Residenciales.Situacion FROM Residenciales, Censos WHERE Residenciales.Situacion & Censos.Situacion
236
7.
Obtener los identicadores de censo y las situaciones de las obras del censo 1 y de las calles de cualquier censo. La consulta ser:
SELECT Censos.Id, Obras.Situacion FROM Obras, Censos WHERE Obras.Situacion & Censos.Situacion AND Censos.Id= 1 UNION SELECT Censos.Id, Calles.Situacion FROM Calles, Censos WHERE Calles.Situacion & Censos.Situacion
8.
Obtener los identicadores de censo y las situaciones de las obras del censo 2 y de los residenciales de cualquier censo. La consulta ser:
SELECT Censos.Id, Obras.Situacion FROM Obras, censo WHERE Obras.Situacion & Censos.Situacion AND Censos.Id = 2 UNION SELECT Censos.Id, Residenciales.Situacion FROM residenciales, censo WHERE Residenciales.Situacion & Censos.Situacion
9.
Obtener los identicadores de censo y las situaciones de las obras y las calles incluidas en el censo 2. La consulta ser:
SELECT Censos.Id, Obras.Situacion FROM obras, censo WHERE Obras.Situacion & Censos.Situacion UNION SELECT Censos.Id, Calles.Situaciont FROM Calles, Censos WHERE Calles.Situacion Censos.Situacion AND Censos.Id = 2
10.
Obtener los identicadores de censo y las situaciones de las obras de cualquier censo y de los residenciales incluidos en el censo 3. La consulta ser:
SELECT Censos.Id, Obras.Situacion FROM Obras, censo WHERE Obras.Situacion & Censos.Situacion UNION SELECT Censos.Id, Residenciales.Situacion FROM residenciales, censo WHERE Residenciales.Situacion Censos.Situacion AND Censos.Id = 3
237
Toda la informacin relativa a los tiempos medios de ejecucin y el nmero de CSP que se crean para cada uno de los ejemplos se muestra en la tabla 8.6.
Sin Consulta Mejora Nmero de CSP Tiempo (ms) Con lgebra Relacional Nmero de CSP Tiempo (ms) Analizando Envolventes Nmero de CSP Tiempo (ms)
(1) (2) (3) (4) (5) (6) (7) (8) (9) (10)
702 702 49 336 650 650 182 104 300 275
5,6953103 6,0534103 1,0286103 2,4798103 4,8486103 4,9985103 2,4264103 1,4627103 2,6361103 3,2747103
702 215 22 24 146 158 49 32 48 77
5,6953103 2,3855103 8,7765102 9,4371102 1,6053103 1,7028103 9,9509102 1,0255103 1,0684103 1,2572103
28 11 3 11 7 4 4 0 2 0
9,2012102 8,7556102 7,2142102 1,4239102 7,9691102 7,9062102 7,4448102 5,1799101 7,0182102 5,3372101
Tabla 8.6: Comparacin para la evaluacin de la Unin
8.5.2. Conclusiones para el operador de Unin

La informacin contenida en la tabla 8.6 se presenta de forma grca en las guras 8.12 y 8.13. El tiempo de evaluacin del operador de unin para cada ejemplo (presentado en la gura 8.6) est estrechamente ligado con el nmero de CSP necesarios para resolverlos (presentado en la gura 8.13), ambas presentadas utilizando la escala logartmica. Dichas grcas muestran en distintos colores los datos relativos a cada una de las mejoras propuestas: sin ninguna mejora creando todos los CSP (- -); creando CSP slo cuando los atributos clsicos son iguales (- -); y creando CSP slo en aquellos casos donde la envolvente de una de las restricciones est incluida en la envolvente de otra (- -). Cabe destacar casos como el del ejemplo 1, donde el uso del lgebra relacional no decrementa el nmero de CSP que se crean y por lo tanto tampoco el tiempo de evaluacin. Esto ocurre cuando las relaciones no tienen atributos univaluados o todos ellos son iguales en las distintas tuplas. En la gura 8.12 se puede observar cmo para esta
238
operacin la Estrategia 1 puede realizar la evaluacin hasta tres veces ms rpido que sin mejoras. Sin embargo, para este ejemplo la mejora ms sustancial es el Anlisis de Envolventes (derivada de la Estrategia 3) que en los ejemplos, y combinndola con el lgebra relacional, ha llegado a ser hasta sesenta veces ms eciente en tiempo.
1,00E+04
1,00E+03 Sin Mejora Tiempo (ms) 1,00E+02 Con lgebra Relacional Analizando Envolventes 1,00E+01
1,00E+00 1 2 3 4 5 6 7 8 9 10
Figura 8.12: Tiempos de evaluacin para la Unin
1000
100 Sin Mejora Nmero de CSP creados 10 Con lgebra Relacional Analizando Envolventes
1 1 2 3 4 5 6 7 8 9 10
Figura 8.13: Nmero de CSP creados para la Unin
8.6. Pruebas para el Operador de Diferencia

La diferencia entre dos relaciones R1 y R2 devolver una nueva relacin con las tuplas de R1 que no estn en R2 . Cuando en las tuplas involucradas en la operacin de diferencia hay atributos de tipo restriccin, hay que hacer un anlisis especco de ellas para cerciorarse que las tuplas con dichas restricciones no son iguales, para no incluir en la salida
Pruebas para el Operador de Diferencia
239
tuplas de R2 . Cmo realizar la evaluacin de la diferencia de una manera eciente se ha explicado en la seccin 6.6. Para esta operacin se proponen 10 ejemplos, donde se muestra la comparativa aadiendo cada una de las mejoras, iguales a las de la operacin de unin. Las comparaciones se realizarn sobre los casos:
Sin Mejora: Creando todos los posibles CSP, lo que al igual que en la Unin
signica n m posibilidades, donde m y n son el nmero de tuplas de R1 y R2 respectivamente.
Con lgebra Relacional: Creando CSP slo con las tuplas que tengan todos los atributos clsicos iguales, derivado de la Estrategia 1. Si una tupla de R1 y
otra de R2 tienen al menos unos de sus atributos clsicos o univaluados distintos, no sera necesario crear un CSP para esa opcin, ya que independientemente de las restricciones, dichas tuplas son distintas, lo que signica que la tupla de R1 formarn parte de la relacin de salida.
Analizando las Envolventes: Creando slo CSP con las restricciones que cumplan las envolventes cuyos detalles se explicaron en la seccin 6.6, derivado de la
Estrategia 3.
8.6.1. Ejemplos de Pruebas usando la Diferencia

Los ejemplos para la operacin de la Diferencia tambin se realizarn sobre las tablas
Residenciales, Calles, Censos y Obras. Los tiempos presentados para los prximos ejemplos
slo tienen en cuenta el tiempo de ejecucin de la diferencia, una vez de las relaciones de entrada se han obtenido. 1. Obtener la situacin de las obras incluidas en el censo 1 menos la situacin de las calles, tambin del censo 1, donde hay una obra. La consulta ser:
SELECT Obras.Id, Obras.Situacion FROM Obras, Censos WHERE Obras.Situacion censos.Situacion AND Censos.Id = 1 MINUS SELECT Obras.Id, Calles.Situacion FROM Obras, Censos, Calles
240
WHERE Calles.Situacion censos.Situacion AND Calles.Situacion Obras.Situacion AND Censos.Id = 1
2.
Obtener el identicador y la situacin de las obras incluidas en el censo 3 que no estn incluidas en la situacin del censo 2. La consulta ser:
SELECT Obras.Id, Obras.Situacion FROM Obras, Censos WHERE Obras.Situacion Censos.Situacion AND Censos.Id = 3 MINUS SELECT Obras.Id, Obras.Situacion FROM Obras, Censos WHERE Obras.Situacion Censos.Situacion AND Censos.Id = 2
3.
Obtener el identicador del censo y la situacin de las obras incluidas en el censo
1, menos la situacin de los residenciales incluidas en cualquier censo. La consulta

ser:
SELECT Censos.Id, Obras.Situacion FROM Obras, Censos WHERE Obras.Situacion Censos.Situacion AND Censos.Id = 1 MINUS SELECT Censos.Id, Residenciales.Situacion FROM Censos, residenciales WHERE Residenciales.Situacion Censos.Situacion
4.
Obtener el censo y la situacin de las obras incluidas en el censo 2, menos la situacin de los residenciales de cualquier censo. La consulta ser:
SELECT Censos.Id, Obras.Situacion FROM Obras, Censos WHERE Obras.Situacion Censos.Situacion AND Censos.Id = 2 MINUS SELECT Censos.Id, Residenciales.Situacion FROM Censos, residenciales WHERE Residenciales.Situacion Censos.Situacion
5.
Obtener el identicador del censo y la situacin de los residenciales incluidos en el censo 1, menos la situacin de las obras de cualquier censo. La consulta ser:
SELECT Censos.Id, Residenciales.Situacion FROM Censos, residenciales
Pruebas para el Operador de Diferencia
241
WHERE Residenciales.Situacion Censos.Situacion AND Censos.Id = 1 MINUS SELECT Censos.Id, Obras.Situacion FROM Obras, Censos WHERE Obras.Situacion Censos.Situacion
6.
Obtener el identicador del censo y la situacin de las obras incluidas en el censo 1, menos la situacin de las calles incluidas en cualquier censo. La consulta ser:
SELECT Censos.Id, Obras.Situacion FROM Obras, Censos WHERE Obras.Situacion Censos.Situacion AND Censos.Id = 1 MINUS SELECT Censos.Id, Calles.Situacion FROM Censos, Calles WHERE Calles.Situacion Censos.Situacion
7.
Obtener el identicador del censo y la situacin de las obras incluidas en el censo 2, menos la situacin de las calles incluidas en cualquier censo. La consulta ser:
SELECT Censos.Id, Obras.Situacion FROM Obras, Censos WHERE Obras.Situacion Censos.Situacion AND Censos.Id = 2 MINUS SELECT Censos.Id, Calles.Situacion FROM Censos, Calles WHERE Calles.Situacion Censos.Situacion
8.
Obtener el identicador del censo y la situacin de las calles incluidas en el censo 2, menos la situacin de las obras incluidas en cualquier censo. La consulta ser:
SELECT Censos.Id, Calles.Situacion FROM Censos, Calles WHERE Calles.Situacion Censos.Situacion AND Censos.Id = 2 MINUS SELECT Censos.Id, Obras.Situacion FROM Obras, Censos WHERE Obras.Situacion Censos.Situacion
9.
Obtener el identicador del censo y la situacin de las calles, menos la situacin de las obras incluidas en cualquier censo. La consulta ser:
242
SELECT Censos.Id, Calles.Situacion FROM Censos, Calles WHERE Calles.Situacion Censos.Situacion MINUS SELECT Censos.Id, Obras.Situacion FROM Obras, Censos WHERE Obras.Situacion Censos.Situacion
10.
Obtener el identicador del censo y la situacin de los residenciales, menos la situacin de las obras incluidas en cualquier censos. La consulta ser:
SELECT Censos.Id, Residenciales.Situacion FROM Censos, residenciales WHERE Residenciales.Situacion Censos.Situacion MINUS SELECT Censos.Id, Obras.Situacion FROM Obras, Censos WHERE Obras.Situacion Censos.Situacion
Toda la informacin relativa a los tiempos medios de ejecucin y el nmero de CSP que se crean para cada uno de los ejemplos se muestra en la tabla 8.7.
8.6.2. Conclusiones para el operador de Diferencia

Para mostrar de forma grca los datos presentados en la tabla 8.7 para los 10 ejemplos, se han creado las guras 8.14 y 8.15, ambas utilizando la escala logartmica. En cada una de estas tablas se utilizan diferentes colores para presentar cmo las distintas mejoras van decrementando el nmero de CSP que se generan, y por lo tanto el tiempo de evaluacin: creando todos los CSP (- -); slo creando CSP cuando los atributos clsicos son iguales (-); y slo creando CSP con aquellos casos donde las cajas de consistencia denidas por las envolventes tienen alguna solucin en comn (- -). Para los ejemplos y con la utilizacin del lgebra relacional, se obtienen mejoras el doble de ecientes que sin mejoras. Con respecto al anlisis de envolventes, se obtienen evaluaciones de consultas casi tres veces ms rpidas que sin utilizar ninguna estrategia de optimizacin.
Resumen
243
Sin Consulta Mejora Nmero de CSP Tiempo (ms)
Con lgebra Relacional Nmero de CSP Tiempo (ms)
Analizando Envolventes Nmero de CSP Tiempo (ms)
(1) (2) (3) (4) (5) (6) (7) (8) (9) (10)
35 80 240 240 300 240 240 403 930 930
1,4040103 8,4934102 1,9314103 1,3004103 1,9980103 1,7909103 1,1709103 2,2668103 2,3651103 3,4534103
4 3 64 64 140 72 109 104 256 268
7,2142102 7,3610102 8,9851102 9,1654102 1,0863103 8,7665102 9,45099102 9,2458102 1,1557103 1,3179103
4 3 15 14 29 24 40 40 92 58
7,2142102 7,2771102 7,8433102 7,6751102 8,7034102 7,8852102 8,4751102 8,0264102 8,8234102 9,0085102
Tabla 8.7: Comparacin para la evaluacin de la Diferencia
8.7.
Resumen
En este captulo se presentan un conjunto de ejemplos para las operaciones primitivas del lgebra relacional redenidas en esta tesis. Dichas pruebas utilizan dos casos de estudio, la diagnosis basada en modelos para la proyeccin simblica y numrica, y los sistemas de informacin geogrca para la seleccin, unin y diferencia. Se han utilizado casos de estudio diferentes para analizar los casos computacionalmente ms complejos en cada operacin, muchas variables para la proyeccin, y pocas variables en el resto de los casos. Para cada una de las operaciones se ha realizado la comparativa aadiendo las distintas mejoras propuestas derivadas del diseo de la arquitectura LORCDB: utilizacin del lgebra relacional, indexacin de variables, almacenar las envolventes de las variables, y etiquetado de restricciones. Entre las cuatro operaciones, se han realizado 176 pruebas, cada una de ellas ejecutadas
100 veces para obtener los tiempos medios de evaluacin. El anlisis de las operaciones se
ha realizado de manera separada, lo que signica que al combinar las distintas operaciones en una misma consulta, tambin se mejorar el tiempo de evaluacin global.
244
1,00E+04
1,00E+03 Sin Mejora Tiempo (ms) 1,00E+02 Con lgebra Relacional Analizando Envolventes 1,00E+01
1,00E+00 1 2 3 4 5 6 7 8 9 10
Figura 8.14: Tiempos de evaluacin de la Diferencia

1000
100 Sin Mejora Nmero de CSP creados 10 Con lgebra Relacional Analizando Envolventes
1 1 2 3 4 5 6 7 8 9 10
Figura 8.15: Nmero de CSP creados para la Diferencia Cabe destacar que la operacin que ms decrementa el tiempo de evaluacin es la proyeccin, tanto simblica como numrica. Esto es posible gracias a la utilizacin del algoritmo para la deteccin de los Conjuntos de Restricciones Relacionadas por Variables en el caso simblico, y el uso de las distintas heursticas en el caso de la proyeccin numrica.
Captulo 9 Conclusiones y Trabajos Futuros

En esta tesis se han analizado las necesidades existentes en las bases de datos para el tratamiento de informacin intensiva, mediante su representacin mediante restricciones. Se han analizado las soluciones existentes hasta el momento, especialmente en el mbito de las Bases de Datos de Restricciones. Dicho anlisis ha dado origen a la deteccin de un conjunto de deciencias en las propuestas existentes hasta el momento, y un conjunto de propuestas para mejorar sus inconvenientes. En este captulo se realiza un resumen de los objetivos cumplidos en esta tesis, qu publicaciones se han derivado de ellos y las lneas de investigacin abiertas que an quedan por cumplir.
9.1.
Anlisis de la Consecucin de los Objetivos
El principal objetivo denido en esta tesis es:
Ampliar los Gestores de Bases de Datos para el tratamiento de Informacin compleja representada mediante Restricciones
Como consecuencia de este objetivo, se derivan un conjunto de subobjetivos para conseguirlo:
Analizar las necesidades de las Bases de Datos actuales y sus deciencias con respecto al tratamiento de datos complejos
Las bases de datos relacionales tienen cualidades para el tratamiento de datos extensivos, pero existen grandes deciencias en lo concerniente a los datos intensivos.
246
Captulo 9. Conclusiones y Trabajos Futuros
De esta forma, se analizan los distintos gestores de bases de datos para dar cabida a las aplicaciones que necesitan representacin intensiva de la informacin.
Analizar las Bases de Datos de Restricciones y sus deciencias

Una de las formas de tratar dichos datos intensivos es utilizando las Bases de Datos de Restricciones, que presentan el centro de estudio de esta memoria. Este rea de investigacin ha dado como origen un conjunto de propuestas, analizadas en esta tesis con el objetivo de detectar qu caractersticas pueden ser mejoradas. El objetivo de esta tesis ha sido encontrar y subsanar dichos inconvenientes, deniendo un Gestos de Bases de Datos no dependiente de la aplicacin.
Denir un nuevo modelo de Base de Datos con Restricciones

Derivado de los defectos detectados, se dene un nuevo modelo de datos para la redenicin de las Bases de Datos de Restricciones. Dicha denicin implica la separacin de la informacin intensiva de la extensiva en dos tipos de atributos distintos, con formas de representacin y tratamientos diferentes.
Ampliar la sintaxis y la semntica de SQL para tratar Restricciones

Al tener diferentes tipos de datos, se modica la sintaxis y la semntica de SQL para incluir las restricciones y las variables de restricciones como nuevos atributos que pueden participar en las consultas. Para ello se ha redenido la semntica de algunos de los operadores de comparacin ya existentes, y se han incluido nuevos operadores para denir las operaciones sobre restricciones. Uno de los defectos de las otras propuestas de Bases de Datos de Restricciones radica en que las soluciones estaban diseadas en funcin de la aplicacin a la que daban soporte, los sistemas de informacin geogrca mayoritariamente. Sin embargo, en esta tesis se ha propuesto un lenguaje de consulta independiente de la aplicacin, que se puede utilizar siempre que los datos se puedan representar como restricciones polinmicas, utilizando inecuaciones o ecuaciones.
Disear una arquitectura para las Bases de Datos con Restricciones

Para que la propuesta no se quede slo a nivel terico, se propone una arquitectura para las Bases de Datos de Restricciones utilizando el paradigma objeto-relacional, junto a un conjunto de tablas de indexacin para facilitar el tratamiento de las
Principales Aportaciones
247
restricciones almacenadas. Dentro del Sistema Gestor de Bases de Datos de Restricciones, se incluyen un conjunto de herramientas y estrategias de resolucin de consultas, para que la funcionalidad relativa a las restricciones sea resuelta por el gestor. Esto provoca que las aplicaciones queden liberadas de la complejidad y tratamiento de las restricciones.
Implementacin del lenguaje de Consulta

Gracias a la arquitectura propuesta y un conjunto de algoritmos, se han implementado de una manera eciente cada una de las operaciones primitivas del lgebra relacional orientadas a restricciones. Para mostrar de forma emprica cmo las decisiones de diseo e implementacin reducen el tiempo de evaluacin de las consultas, se utilizan diferentes casos de estudios y usos de operadores, mostrando los tiempos medios de evaluacin para cada uno de ellos.
9.2.
Principales Aportaciones
Cabe destacar un subconjunto de las propuestas de esta tesis, como las aportaciones ms relevantes en al rea de los Gestores de Bases de Datos.
9.2.1. Redenicin del modelo de Bases de Datos de Restricciones

Utilizando la capacidad de extraccin del lgebra relacional, y la capacidad expresiva y de inferencia de las programacin con restricciones, se crea un nuevo modelo con tres tipos de atributos: clsico o univaluado, restriccin, y atributo de restriccin. Esto provoca una redenicin del modelo de Bases de Datos de Restricciones, junto a las operaciones de seleccin, proyeccin, producto cartesiano, unin y diferencia. Estas consultas modican necesariamente la sintaxis de SQL, intentando mantener su sintaxis y su semntica en lo posible, facilitando as adaptacin de los usuarios que conocen SQL. Este nuevo lenguaje llamado CORQL, junto a los detalles relativos al nuevo modelo, se presentan en el captulo 4.
248
9.2.2. Creacin de un nuevo Gestor de Bases de Datos de Restricciones

En el captulo 5 se presenta la arquitectura LORCDB, la cual permite mayor expresividad que las bases de datos relacionales al utilizar datos intensivos, haciendo a la vez la evaluacin de consultas ms eciente. Esto es gracias a ciertas decisiones de diseo, como la indexacin de variables, almacenado de los lmite de los valores de satisfactibilidad, y etiquetado de las restricciones en funcin de su tipo. El gestor crea de forma automtica y transparente al usuario, los modelos necesarios para evaluar las consultas. La arquitectura incluye las herramientas necesarias para resolver dichos modelos, y presentar la salida al usuario.
9.2.3. Implementacin eciente del lenguaje CORQL

Para la mejora de la eciencia cuando se tratan datos intensivos y extensivos, se proponen un conjunto de algoritmos y estrategias de evaluacin de las consultas. La losofa de las estrategias propuestas radica en posponer el uso de tcnicas simblicas o resolucin de problemas de satisfaccin de restricciones. Esto es posible gracias los distintos algoritmos para la deteccin de restricciones relacionadas por variables y al anlisis de envolventes para conocer la satisfactibilidad de un conjunto de restricciones, tal como se analiza en el captulo 6.
9.2.4. Gestor vlido para aplicaciones de naturaleza diferente

Tres son los ejemplos de aplicaciones mostrados en esta memoria, para mostrar cmo la misma arquitectura y el mismo lenguaje es vlida para distintos usos. Dichas aplicaciones son los sistemas de informacin geogrca, gestin econmica, y la diagnosis de fallos. Cabe destacar la diagnosis de fallos basada en modelos como ejemplo novedoso. La diagnosis basada en modelos nunca haba sido utilizada antes como caso de estudio en las Bases de Datos de Restricciones, siendo un problema emergente y de gran importancia en el mundo de la ingeniera. El uso de este caso de estudio hace posible ampliar tipos de consultas, especialmente orientadas a los atributos variable de restriccin, no denidos hasta el momento. Esto es debido a que los sistemas a diagnosticar suelen ser complejos y estn formados por gran cantidad de variables, tal como se explica en el captulo 7.
Publicaciones
249
9.3.
Publicaciones
Durante el desarrollo de esta tesis se han publicado trabajos tanto en el rea de la bases de datos, de la diagnosis de fallos, como especcamente en el campo de las Bases de Datos de Restricciones. Dichas aportaciones presentadas cronolgicamente son:
[2003] : El objetivo cubierto en este ao se bas en la creacin de una base de datos

relacional que permitieran almacenar restricciones. En funcin de la consulta a la base de datos, se construan y resolvan problemas de satisfaccin de restricciones (CSP) en tiempo de ejecucin. Las restricciones eran almacenadas como cadenas en la base de datos, lo que signica que se podan hacer consultas con respecto a las restricciones, pero no a sus variables. En estos primeros trabajos, slo era posible trabajar con restricciones lineales, lo que vena determinado por el tipo de resolutor que se utilizaba.
Ttulo: Arquitectura para la Consulta a Bases de Datos Restrictivas. Autores: Mara Teresa Gmez, Rafael M. Gasca, Carmelo Del Valle y Rafael Ceballos
Publicado en: Jornadas de Ingeniera del Software y Bases de Datos, pginas:

593-602, 2003
ndice de Aceptacin: 24.6 % Ttulo: CSP y Bases de Datos Restrictivas. Autores: Mara Teresa Gmez, Rafael M. Gasca, Carmelo Del Valle y Rafael Ceballos
Publicado en: Revista Iberoamericana de Inteligencia Articial, Volumen 20, pginas: 150-163, 2003
Ttulo: CSP aplicados a la diagnosis basada en modelos. Autores: Rafael Ceballos, Carmelo Del Valle, Mara Teresa Gmez y Rafael M.
Gasca.
Ttulo: Modelo de CSP para consultas a Bases de Datos Restrictivas
250
Autores: Mara Teresa Gmez, Rafael M. Gasca, Carmelo Del Valle y Antonio
Mrquez
Publicado en: X Conferencia de la Asociacin Espaola Para la Inteligencia Articial (CAEPIA), Volumen I, pginas: 469-472, 2003
[2004]: Los trabajos desarrollados durante este ao se centran en resolver el problema

de la diagnosis de componentes basada en modelos, almacenando toda la informacin en Bases de Datos de Restricciones. Se ofrece una arquitectura que permite conocer los componentes que fallan en un sistema cuando ste est almacenado como restricciones en una base de datos relacional. Se aportan los algoritmos para mejorar la eciencia de la proyeccin para atributos variable de restriccin, e incluyendo tcnicas simblicas al proceso.
Ttulo: Determination of Possible Minimal Conict Sets Using Constraint Databases Technology and Clustering.
Autores: M. T. Gmez-Lpez, R. Ceballos, R. M. Gasca y S. Pozo. Publicado en: IBERAMIA, Lecture Notes in Computer Science, Springer, Volumen: 3315, pginas: 942-952, 2004.
ndice de Aceptacin: 31 % Ttulo: Applying Constraint Databases in the Determination of Potential Minimal
Conicts to Polynomial Model-based Diagnosis.
Autores: Mara Teresa Gmez, R. Ceballos, R. M. Gasca y C. Del Valle Publicado en: Constraint Databases (CDB), Lecture Notes in Computer Science,
Springer, Volumen: 3074, pginas: 74-87, 2004.
ndice de Aceptacin: 34 % Ttulo: Constraint Databases Technology for Polynomial Models Diagnosis Autores: Mara Teresa Gmez-Lpez, Rafael Ceballos, Rafael M. Gasca y Carmelo
Del Valle
Publicado en: 15th International Workshop on Principles of Diagnosis (DX'04),

pginas: 215-220, 2004
Publicaciones
251
Ttulo: Determination of Possible Minimal Conict Sets Using Components Clusters and Grbner Bases.
Autores: Rafael Ceballos, Mara Teresa Gmez-Lpez, Rafael M. Gasca y S. Pozo Publicado en: 15th International Workshop on Principles of Diagnosis (DX'04),
pginas: 21-26, 2004
[2005]: Durante este ao se crea la primera versin de la arquitectura usando el paradigma objeto-relacional. Dicha arquitectura permite crear problemas de satisfaccin de restricciones e inferir nuevas restricciones partiendo de las almacenadas en la base de datos utilizando tcnicas simblicas. El caso de estudio contina siendo la diagnosis basada en modelos, incorporando todas la mejoras obtenidas en el ao anterior. En estos trabajos las restricciones son almacenadas como objetos indexados en una base de datos relacional, para mejorar la eciencia de las consultas.
Ttulo: Improving the determination of Minimal Hitting Sets in Model-Based Diagnosis.
Autores: Mara Teresa Gmez-Lpez, Rafael Ceballos, Rafael M. Gasca y Carmelo

Del Valle
Publicado en: 16th International Workshop on Principles of Diagnosis, (DX'05)

Monterey (California), pginas: 61-66, 2005
Ttulo: Algoritmo para la bsqueda de restricciones en una base de datos relacional

orientada a objetos con restricciones polinmicas.
Autores: Mara Teresa Gmez-Lpez, Rafael M. Gasca y Carmelo Del Valle Publicado en: Revista CUORE. Vivat Academia, Octubre 2005, nmero 12, pginas: 3-16
Ttulo: ORCDB: Arquitectura para la extensin de la semntica de SQL en bases

de datos restrictivas orientadas a objetos con restricciones polinmicas de igualdad.
Autores: Mara Teresa Gmez-Lpez, Rafael M. Gasca, Carmelo Del Valle y Victor
Cejudo
Publicado en: Jornadas de Ingeniera del Software y Bases de Datos, pginas 221229, 2005.
ndice de Aceptacin: 31,7 %
252
Ttulo: Querying a Polynomial Constraint Object-Relational Database in Modelbased Diagnosis.
Autores: Mara Teresa Gmez-Lpez, Rafael M. Gasca, Carmelo Del Valle y F.

Fernando de la Rosa T.
Publicado en: International Conference on Database and Expert Systems Applications (DEXA), Lecture Notes in Computer Science, Springer, volumen 3588, pginas 848-857, 2005.
Ttulo: A model integration of DX and FDI techniques for automatic determination

of minimal diagnosis.
Autores: Rafael Ceballos, Mara Teresa Gmez-Lpez, Rafael. M. Gasca y Carmelo

Del Valle
Publicado en: International Joint Conference on Articial Intelligence (IJCAI'05),

2nd MONET Workshop on Model-Based Systems, Edimburgo, Scotland, Julio 2005 [2006]: Una vez que la arquitectura est desarrollada, se completa la sintaxis y la
semntica de la ampliacin de SQL. Como caso de estudio se utiliza la diagnosis basada en modelos para la obtencin de los hitting sets, junto a ejemplos econmicos. Tambin se plantea el primer trabajo de cmo las Bases de Datos de Restricciones pueden ser ampliadas para un tratamiento distribuido de la informacin.
Ttulo: Improving the determination of Minimal Hitting Sets in Model-Based Diagnosis using Constraint Databases.
Autores: Mara Teresa Gmez-Lpez, Rafael M. Gasca and Carmelo Del Valle Publicado en: 6th IFAC Symposium on Fault Detection, Supervision and Safety
of Technical Processes, SAFEPROCESS 2006
Ttulo: Ampliacin de la sintaxis y la semntica de SQL para el tratamiento de

datos tipo restriccin.
Autores: Mara Teresa Gmez-Lpez y Rafael M. Gasca Publicado en: XI Jornadas de Ingeniera del Software y Bases de Datos, Sitges,
Espaa, pginas: 471-476, 2006
Publicaciones
253
Ttulo: Distributed Model-Based Diagnosis using Object-Relational Constraint

Databases.
Autores: Mara Teresa Gmez-Lpez, Rafael M. Gasca, Carmelo Del Valle y Sergio
Pozo
Publicado en: IEEE The 20th International Conference on Advanced Information

Networking and Applications, Vienna, Austria, vol 2. pginas: 866-870, 2006
Ttulo: Integracin de tcnicas basadas en modelos para la determinacin de la

diagnosis minima de un sistema.
Autores: Rafael Ceballos, Mara Teresa Gmez-Lpez, Rafael M. Gasca y Carmelo

Del Valle
[2007]: La utilizacin de las Bases de Datos de Restricciones es benecioso tanto

desde el punto de vista del almacenamiento de datos, como desde el punto de vista de la construccin y resolucin de problemas de satisfaccin de restricciones. Con esta idea se han creado trabajos, tanto en el caso de la diagnosis basada en modelos utilizando la indexacin de variables, como la resolucin de problemas sper restringidos utilizando las envolventes de las variables.
Ttulo: A compiled model for faults diagnosis based on dierent techniques. Autores: Rafael Ceballos, Mara Teresa Gmez-Lpez, Rafael M. Gasca y Carmelo
Del Valle
Publicado en: AI Communications, vol. 20, pginas 6-17, 2007 ndice de Impacto: 0.46 Ttulo: Developing a Labelled Object-Relational Constraint Database Architecture
for Projection Operator.
Autores: Mara Teresa Gmez-Lpez, Rafael Ceballos, Rafael M. Gasca y Carmelo

Del Valle
Publicado en: En la segunda fase del proceso de revisin en Data & Knowledge
Engineering. Ed. Elsevier
ndice de Impacto: 1.36
254
Ttulo: NMUS: Structural Analysis for Improving the Derivation of All MUSes in
Overconstrained Numeric CSPs
Autores: Rafael M. Gasca y Carmelo Del Valle, Mara Teresa Gmez-Lpez y

Rafael Ceballos
Publicado en: XII Conferencia de la Asociacin Espaola Para la Inteligencia Articial (CAEPIA), Lecture Notes in Articial Intelligence, Springer, volumen 4788, pginas 160-169, 2007
ndice de Aceptacin: 20,1 Ttulo: Bases de Datos de Restricciones para el tratamiento de CSP Autores: Mara Teresa Gmez-Lpez, Rafael M. Gasca y C. Del Valle Publicado en: Workshop on Planning, Scheduling and Constraint Satisfaction,
2007
Ttulo: Supervised and Distributed Model-Based Diagnosis Autores: Diana Borrego, Mara Teresa Gmez-Lpez y Rafael M. Gasca Publicado en: II Workshop on Industrial Applications of Distributed Intelligent
Systems, 2007
9.4. Lneas Futuras de Investigacin

Una vez denido el nuevo modelo de Bases de Datos de Restricciones, existen lneas claras para continuar con la investigacin, ya que el objetivo siempre es tener todas las ventajas de las bases de datos relaciones clsicas, pero aadiendo la utilizacin de restricciones como tipo de dato. Con esta idea, se proponen las siguientes lneas futuras de investigacin.
9.4.1. Incluir la Programacin Lgica

Incluir capacidades lgicas, no exclusivamente numricas en la Base de Datos de Restricciones. Esto signica aadir las cualidades de la programacin lgica con restricciones, no slo programacin con restricciones numricas como se tiene hasta el momento.
Lneas Futuras de Investigacin
255
9.4.2. Restricciones de Integridad

Incluir restricciones de integridad en las Bases de Datos de Restricciones sobre atributos restriccin o variable de restriccin. Por ejemplo, que las soluciones de las restricciones de un atributo tienen que estar incluidas en las soluciones de otro atributo restriccin.
9.4.3. Ampliar el tipo Restriccin

Con respecto al tratamiento de restricciones, sera muy interesante denir el tipo
Restriccin utilizando ms operadores como , , o . Pese a que en operaciones

como la unin y la diferencia se utiliza el operador de negacin () en la obtencin de nuevas restricciones, no se permite aadir nuevas restricciones a la base de datos con dicho operador. Si se incluyeran dichos operadores, la construccin de problemas de satisfaccin de restricciones o de optimizacin con restricciones no conllevara demasiada problemtica, pero la eliminacin simblica de variables sera mucho ms compleja.
9.4.4. Bases de Datos Distribuidas

Cuando la informacin de una Base de Datos de Restricciones no est centralizada, ser necesario ampliar la arquitectura para el tratamiento de dicha informacin. Esto tambin signica crear los problemas de satisfaccin de restricciones y modelos de eliminacin simblica de forma distribuida. Aunque ya se han publicado trabajos que amplan la arquitectura LORCDB para hacer distribuida, an quedan muchos aspectos que analizar y mejorar.
9.4.5. Analizar ms casos de estudio

Aunque en esta tesis se presentan tres casos de estudios (econmico, diagnosis basada en modelos y sistemas de informacin geogrca), existen mucho otros como la planicacin, optimizacin, y los sistemas CAD/CAM. Estos casos de estudio son especialmente complejos ya que pueden utilizar estructuras recursivas, por lo que presenta inters analizar cmo el uso de Bases de Datos de Restricciones podran facilitar su desarrollo, o cmo se puede ampliar la arquitectura propuesta para dichos casos.
Apndice A Algoritmo para la Proyeccin Simblica

En esta seccin se presenta con detalle el algoritmo para la proyeccin simblica sobre atributos variable de restriccin, tanto para bsqueda horizontal como vertical. Para obtener el conjunto de restricciones relacionadas por variables (CRRV) se propone un algoritmo, mostrando las estructuras de datos necesarias, una traza del mismo, y las propiedades que cumple.
A.1.
Algoritmo para la Obtencin de los CRRV
Como se expuso en el captulo 6, para la bsqueda de las restricciones relacionadas con los atributos variable de restriccin, existen dos variantes, la proyeccin horizontal (gura A.1.a) y la proyeccin vertical (gura A.1.b). En funcin de qu tipo de proyeccin se realize, la bsqueda involucrar restricciones de la misma tupla (G1 , . . ., Gn ), o del mismo atributo restriccin (G1 , . . ., Gm ). Partiendo de la notacin introducida en el captulo 6:
Variables(ci , . . . , cj ). Conjunto de las variables de las restricciones ci , . . ., cj sin

repeticin.
Variables(Q, {ci , . . . , cj }). Conjunto de variables sin repeticin de las restricciones

ci , . . ., cj que aparecen en la consulta Q.
258
Apndice A. Algoritmo para la Proyeccin Simblica
Relacin
Relacin
G1
...
Gn G1
(a) Proyeccin Horizontal
...
(b) Proyeccin Vertical
Gm
Figura A.1: Tipos de Proyeccin: Horizontal y Vertical Y de la denicin de CRRV para la proyeccin simblica:
Conjunto de Restricciones Relacionadas por Variables (CRRV) para la Proyeccin Simblica. Gi ' ser un Conjunto de Restricciones Relacionadas por Variables si:
Siendo Gi ' {ci , . . ., cj } | (Gi {c1 , . . ., cn } Gi 'Gi )
ck Gi ' v Variables(ck ) | v / Variables(Q, ck )

(v Variables(Gi '{ck })) ( cl (Gi {ck }) | v Variables(cl ))
A.2. Estructuras de Datos

En este apndice se describen los detalles del algoritmo para obtener los CRRV para cada uno de los Gi , y las variables de la proyeccin denidas en la consulta Q. La idea del algoritmo es agrupar las restricciones que tengan variables en comn que no pertenezcan a la consulta. Antes de describir el algoritmo, cabe destacar los tipos de relacin entre dos restricciones a nivel de CRRV. Dos restricciones tendrn una relacin AND si son las nicas que tienen una variable que no pertenece a la consulta, lo que signica que si una de las restricciones forma parte de un CRRV, la otra restriccin tambin pertenecer al
Estructuras de Datos
259
CRRV. Mientras que dos restricciones en un CRRV tendrn una relacin OR si tienen una variable no perteneciente a la proyeccin en comn pero que tambin est en otras restricciones de Gi , lo que signica que dichas restricciones pueden pertenecer al mismo CRRV o no. Basado en esta idea se crea un grafo donde cada nodo estar formado por una restriccin sola, o un conjunto de restricciones con una relacin AND entre ellas dos a dos, lo que provocar que el grafo tenga menos nodos, y por lo tanto el recorrido de l sea ms eciente. Cada uno de los nodos del grafo (Nodo-Restricciones) estar formado por una estructura con los siguientes atributos:
Conjunto Restricciones: Conjunto de las restricciones que forman el nodo, que tienen
una relacin AND entre ellas. Es posible que este conjunto slo tenga una restriccin.
Conjunto VariablesResueltas: Conjunto con las variables de las restricciones que

pertenecen a la proyeccin, o que estn en dos restricciones del conjunto de Res-
tricciones derivado de que tengan una relacin AND. Conjunto VariablesNoResueltas: Conjunto con las variables de las restricciones del
conjunto Restricciones, que no pertenecen a las VariablesResueltas. Entre dos nodos del grafo (Nodo-Restricciones) existir una arista si comparten al menos una variable no resuelta (VariablesNoResueltas). En la gura A.2 se muestra un ejemplo donde las restricciones R1 y R2 tienen una relacin AND, ya que la variable k slo aparece en esas dos restricciones, por lo que si una pertenece a un CRRV, la otra tambin tendr que pertenecer. El resto de restricciones tienen una relacin OR. Una vez formado dicho grafo, el recorrido del grafo consiste en, partiendo de cada uno de los Nodo-Restricciones con variables pertenecientes a la consulta Q, obtener todos los conjuntos de Nodo-Restricciones que cumplan la denicin de CRRV. Para ello se utiliza una estructura llamada Estructura-CRRV, a la que se le irn aadiendo las distintas restricciones a lo largo del recorrido del grafo tal como se explicar en el algoritmo 1. La
Estructura-CRRV tiene los atributos: Conjunto Restricciones: Conjunto de los identicadores de las restricciones que hasta
el momento forman el CRRV.
260
R7
y
v2
y
R7
v2
R3
y
R3
y
x
v1
R1
R2
x
R6
z
v3
v1
R1,R2
x
R6
z
v3
R4
z
R4
z
R5
Figura A.2: Ejemplo transformacin grafo Nodo-Restricciones
Conjunto VariablesAnalizadas: Conjunto con las variables que ya se han catalogado

dentro de los tres tipos denidos para los CRRV: (a) variables que aparecen en la proyeccin; (b) variables que estn al menos en dos restricciones del conjunto
Restricciones de la misma Estructura-CRRV; (c) variables que slo estn en una

restriccin de las pertenecientes al grupo de restricciones Gi sobre la que se est haciendo la bsqueda, y no pertenecen a las variables de la proyeccin.
Conjunto VariablesNoAnalizadas: Conjunto con las variables de las restricciones del

conjunto Restricciones que no pertenecen an a VariablesAnalizadas.
Conjunto VariablesNoResueltas: Conjunto con las variables no pertenecientes a la

proyeccin, que slo aparecen en una restriccin de las pertenecientes al grupo de restricciones Gi sobre el que se est realizando el recorrido.
Conjunto RestCiclo: Este conjunto de restricciones evita ciclos cuando existen relaciones OR entre restricciones, y se pueden obtener CRRV repetidos resolviendo la variable con dos o ms restricciones diferentes. Un ejemplo basado en la gura A.2 es obtener dos CRRV por la relacin OR existente entre (R1 R2 , R3 ) y (R1 R2 ,
R4 ), por lo que realizando el recorrido por ambas ramas se obtendrn dos CRRV:
{R1 R2 , R3 , R6 , R4 } y {R1 R2 , R4 , R6 , R3 }. Estos CRRV son los mismos, ya que el orden de las restricciones no es determinante. Para evitar estas duplicaciones, al comenzar un recorrido OR se aadir dicha restriccin a RestCiclo, para que no pueda participar en otro recorrido. Un ejemplo de la traza completa se mostrar ms adelante.
z
v4
R5
z
v4
Estructuras de Datos
261
La idea del algoritmo consiste en, inicializando una Estructura-CRRV con un Nodo-
Restricciones con variables de la proyeccin, ir aadiendo a la Estructura-CRRV nuevas

restricciones que tenga VariablesNoResueltas en comn con las VariablesNoAnalizadas de la Estructura-CRRV que se est tratando. Cuando se aade a una Estructura-CRRV llamada por ejemplo crrv, un Nodo-Restricciones rr (crrv.aadir(rr)) por existir una variable que pertenezca a las variablesNoAnalizadas de crrv, y a las variablesNoResueltas de rr, se har: 1. Aadir las restricciones de rr a crrv:
crrv.restricciones.aadir(rr.restricciones)
2. Poner como analizadas aquellas variables no analizadas de crrv que aparezcan como no resueltas en rr, ya que son variables que no pertenecen a la proyeccin que estn al menos en dos restricciones, una de las restricciones ya incluidas en crrv y otra de rr:
crrv.variablesAnalizadas.aadir(crrv.variablesNoAnalizadas rr.variablesNoResueltas)
3. Aadir a las variables no analizadas de crrv, las no resueltas de rr que no estn ya en las analizadas:
crrv.variablesNoAnalizadas.aadir(rr.VariablesNoResueltas crrv.VariablesAnalizadas)
Cuando una Estructura-CRRV no tiene ninguna variable en las VariablesNoAnalizadas y el conjunto es mnimo, se almacenar en una lista llamada ListaCRRV. Para conocer si un CRRV obtenido mediante el algoritmo es mnimo, se utilizar la funcin esMni-
mo(CRRV), la cual comprueba si para cada una de las restricciones del CRRV de entrada,
existe al menos una variable que slo aparece en dos restricciones del conjunto. Esto signicar que dicha restriccin es necesaria para forma el CRRV, y que si ella no formar parte del conjunto, dejara de ser un CRRV. Con el algoritmo propuesto, esta comprobacin slo ser necesaria si existen restricciones que tengan ms de una variable en comn. Como se la gura A.3, donde el conjunto de restricciones mostradas no forman un CRRV, ya que por ejemplo todas las variables de R2 (x, y ) aparecen en otras dos restricciones. Si el conjunto VariablesNoResueltas est vaco, el CRRV ser un CCRRV (Conjunto Completo de Restricciones Relacionadas por Variables).
262
R2
x
y
R1
x
R3
x,y
y,z
R4
Figura A.3: Ejemplo de CRRV no mnimo
A.3. Descripcin del Algoritmo

Para cada Gi G, independientemente de que sea G = (G1 , . . . , Gn ) o G =
(G1 , . . . , Gm ), se construir un grafo como se ha explicado. El procedimiento que obtiene

todos los CRRV es el mostrado en el algoritmo 1.
Algoritmo 1: Obtencin de CRRV de la Proyeccin Simblica para G Entrada: Q Salida: Lista listaCRRV
Lista Gi Lista listaCRRV := Lista() Lista G := ObtenerGrafosRestricciones(Q)
Para cada Gi G hacer
Lista restProyeccin := ObtenerRestriccionesProyeccin(Gi )

ObtenerCRRV(Gi , restProyeccin, listaCRRV)
Dependiendo de la consulta Q, se obtendrn los conjuntos de restricciones G1 , . . . , Gn , donde cada Gi es una lista de Nodo-Restricciones, obtenido mediante la funcin Obten-
erGrafosRestricciones. Para cada Gi , ser necesario conocer los Nodo-Restricciones que

contienen las variables que participan en la proyeccin, las cuales se obtendrn con la funcin ObtenerRestriccionesProyeccin. La funcin ObtenerCRRV obtiene, partiendo de las restricciones de restProyeccin, todos los CRRV para cada Gi en la variable listaCRRV.
ObtenerCRRV(Lista Gi , Lista restProyeccin, Lista listaCRRV): Este procedimiento realizar un recorrido de las restricciones de Gi , comenzando por las restricciones pertenecientes a la lista restProyeccin. Cuando se comienza la bsqueda por un Nodo-
Restricciones, el algoritmo obtiene todos los CRRV con dicha restriccin. Para evitar que
Descripcin del Algoritmo
263
al comenzar la bsqueda por otro Nodo-Restricciones con variables de la proyeccin, se vuelvan a encontrar dichos CRRV, dichas restricciones se almacenarn en restriccionesVis-
itadas. Para cada una de estas Estructuras-CRRV, se analizarn sus VariablesNoAnalizadas para unir aquellas restricciones que tengan variables en comn que no pertenezcan
a las variables de la proyeccin. La funcin ObtenerCRRV es la mostrada en el algoritmo 2.
Algoritmo 2: Funcin ObtenerCRRV Entrada: Lista Gi , Lista restProyeccin, Lista listaCRRV Salida: Lista listaCRRV
Estructura-CRRV crrv Lista restricionesVisitadas
Para cada r restProyeccin | r / restricionesVisitadas hacer

restriccionesVisitadas.aadir(r) crrv := Estructura-CRRV(); crrv.restricciones.aadir(r) crrv.variablesAnalizadas.aadir(r.VariablesResueltas) crrv.variablesNoAnalizadas.aadir(r.VariablesNoResueltas) crrv.RestCiclo := Lista() crrv.VariablesNoResueltas := Lista() recorridoGrafoCRRV(crrv, listaCRRV, restriccionesVisitadas) El procedimiento RecorridoGrafoCRRV es recursivo (mostrado en el algoritmo 3), y se basa en ir encontrando restricciones que tengan en comn variables no analizadas de la
Estructura-CRRV que se pasa como parmetro de entrada. Cuando no quedan variables

por analizar, se aade a listaCRRV. Para evitar recorridos duplicados, se utiliza el conjunto
restriccionesVisitadas, que tambin ser parmetro de entrada. Volviendo a la gura A.2,

un ejemplo de los recorridos duplicados que esta lista de restriccionesVisitadas evitados puede ser: al comenzar la bsqueda por el nodo R1 -R2 , se crear un CRRV formado por {R1 -R2 , R4 , R5 }, si R1 -R2 no se aadiera a la lista de restriccionesVisitadas, al comenzar la bsqueda por R5 si fuera una restriccin con variables de la proyeccin, se volvera a construir el mismo CRRV.
264
Algoritmo 3: Procedimiento recorridoGrafoCRRV Entrada: Estructura-CRRV crrv, Lista listaCRRV, Lista restriccionesVisitadas Salida: Lista listaCRRV si crrv.variablesNoAnalizadas.esVaca() entonces si esMnimo(crrv) entonces
listaCRRV.aadir(crrv)
sino
Para v CRRV.VariablesNoAnalizadas
crrv.VariablesNoAnalizadas.borrar(v) crrv.VariablesAnalizadas.aadir(v)
Lista restRelacionadas := ObtenerRestrYVariables(crrv, v,
Gi , restriccionesVisitadas)
//obtiene los Nodo-Restricciones de Gi que tengan a v , pero no estn ya //incluidos en crrv.RestCiclo ni restriccionesVisitadas
si restRelacionadas.esVaca() entonces si v / Variables(Gi crrv.restricciones) entonces

crrv.varNoResueltas.aadir(v)
sino Para cada rr restRelacionadas hacer

crrv.restriccionesCiclo.aadir(rr)
//restricciones en distinto orden
//evita obtener el mismo CRRV pero recorriendo las Estructura-CRRV copiaCrrv := crrv.clonar() copiaCrrv.aadir(rr) recorridoGrafoCRRV(copiaCrrv, listaCRRV, restriccionesVisitadas)
A.4. Ejemplo de Traza

Para entender mejor el algoritmo, se presenta la traza para el ejemplo de la gura A.2 donde las variables de la proyeccin son v1 , v2 , v3 : Se inicializa crrv con algn Nodo-Restricciones que contenga variables de la proyeccin, crrv:{Restricciones: R1 -R2 ; VariablesAnalizadas: {k}; VariablesNoAnalizadas:
Ejemplo de Traza
265
{x}; VariablesNoResueltas: {}; restCiclo: {}}, RestriccionesVisitadas: R1 -R2 . Para x: {R3 , R4 } := ObtenerRestYVariables(. . ., x, . . .)
crrv:{Restricciones: R1 -R2 , R3 ; VariablesAnalizadas: {k, x}; VariablesNoAnalizadas: {y}; VariablesNoResueltas: {}; restCiclo: {R3 }}, RestriccionesVisitadas: R1 -R2 . Para y : {R6 , R7 } = ObtenerRestYVariables(. . ., y, . . .)
crrv:{Restricciones: R1 -R2 , R3 , R6 ; VariablesAnalizadas: {k, x, y}; VariablesNoAnalizadas: {z}; VariablesNoResueltas: {}; restCiclo: {R3 , R6 }}, RestriccionesVisitadas: R1 -R2 . Para y : {R4 , R5 } = ObtenerRestYVariables(. . ., z, . . .) crrv:{Restricciones: R1 -R2 , R3 , R6 , R4 ; VariablesAnalizadas: {k, x, y, z}; VariablesNoAnalizadas: {};VariablesNoResueltas: {}; restCiclo: {R3 , R6 , R4 }}, RestriccionesVisitadas: R1 -R2 . Como no quedan variables por analizar, {R1 -R2 , R3 , R6 , R4 } es un
CRRV, y como no tiene variablesNoResueltas tambin ser un CCRRV. crrv:{Restricciones: R1 -R2 , R3 , R6 , R5 ; VariablesAnalizadas: {k, x, y, z}; VariablesNoAnalizadas: {};VariablesNoResueltas: {}; restCiclo: {R3 , R6 , R4 , R5 }}, RestriccionesVisitadas: R1 -R2 . Como no quedan variables por analizar, {R1 -R2 , R3 , R6 , R5 } es un
CRRV, y como no tiene variablesNoResueltas tambin ser un CCRRV.
crrv:{Restricciones: R1 -R2 , R3 , R7 ; VariablesAnalizadas: {k, x, y}; VariablesNoAnalizadas: {}; VariablesNoResueltas: {}; restCiclo: R3 , R6 , R7 }, RestriccionesVisitadas: R1 -R2 . Como no quedan variables por analizar, {R1 -R2 , R3 , R7 } es un CRRV, y como no tiene variablesNoResueltas tambin ser un CCRRV.
crrv:{Restricciones: R1 -R2 , R4 ; VariablesAnalizadas: {k, x}; VariablesNoAnalizadas: {z}; VariablesNoResueltas: {}; restCiclo: {R3 , R4 }}, RestriccionesVisitadas: R1 -R2 . Para z : {R5 , R6 } = ObtenerRestYVariables(. . ., z, . . .)
266
crrv:{Restricciones: R1 -R2 , R4 , R5 ; VariablesAnalizadas: {k, x, z}; VariablesNoAnalizadas: {};VariablesNoResueltas: {v4}; restCiclo: {R3 , R4 }}, RestriccionesVisitadas: R1 -R2 . Como no quedan variables por analizar, {R1 -R2 , R4 , R5 } es un CRRV, pero como tiene variables no resueltas, no es un CCRRV.
crrv:{Restricciones: R1 -R2 , R4 , R6 ; VariablesAnalizadas: {k, x, z};

VarNoAnalizadas: {y};VariablesNoResueltas: {v4}; restCiclo: {R3 , R4 }}, RestriccionesVisitadas: R1 -R2 . Para y : {R7 } = ObtenerRestYVariables(. . ., y, . . .). No devuelve R3 porque est en restCiclos, y as se evita que la listaCRRV contenga CRRV duplicados. crrv:{Restricciones: R1 -R2 , R4 , R6 , R7 ; VariablesAnalizadas: {k, x, z, y}; VariablesNoAnalizadas: {};VariablesNoResueltas: {v4}; restCiclo: {R3 , R4 }}, RestriccionesVisitadas: R1 -R2 . Como no quedan variables por analizar, {R1 -R2 , R4 , R6 , R7 } es un CRRV, pero como tiene variables no resueltas, no es un CCRRV. crrv:{Restricciones: R5 ; VariablesAnalizadas: {}; VarNoAnalizadas: {z}; VariablesNoResueltas: {}; restCiclo: {}}, RestriccionesVisitadas: R1 -R2 , R5 .
...
Ningn CRRV obtenido desde la inicializacin con R5 incluir al Nodo-Restricciones
R1 -R2 , ya que todos los CRRV con R1 -R2 se han obtenido con la primera inicializacin de la traza, y se ha incluido en RestriccionesVisitadas. Un ejemplo de cmo se va construyendo la Estructura-CRRV en los distintos pasos de la traza presentada, se muestra en la gura A.4 en forma de rbol. Los diferentes CRRV sern todos los posibles caminos desde la raz hasta las hojas de cada uno de dichos rboles.
A.5. Propiedades del Algoritmo

Para analizar las distintas propiedades del algoritmo, se comenzar estudiando cmo cambia el estado de la Estructura-CRRV, la listaCRRV y restriccionesVisitadas, que son los parmetros de entrada del algoritmo recursivo recorridoGrafoCRRV.
Propiedades del Algoritmo
267
R4
R6
y
z
R3
y
R5 R7
v1
R1,R2 R5
z
x
R4
z
R6
R7
R3
z
v4
...
R5
z
R4
...
Figura A.4: Ejemplo de bsqueda de restricciones relacionadas por variables
A.5.1. Transicin entre estados de la Estructura-CRRV

Antes de comenzar la descripcin de la complejidad del algoritmo y las distintas propiedades que tiene, es necesario analizar cmo cambian los distintos parmetros de entrada del mtodo recursivo recorridoGrafoCRRV (algoritmo 3) para obtener todos los CRRV: Estructura-CRRV, listaCRRV y restriccionesVisitas:
Estructura-CRRV (crrv): restricciones r1 , . . . , rn VariablesAnalizadas vA1 , . . . , vAm VariablesNoAnalizadas vN A1 , vN A2 , . . . , vN Ak VariablesNoResueltas vN R1 , . . . , vN Rp restriccionesCiclo rC1 , . . . , rCq listaCRRV lcrrv1 , . . . , lcrrvr restriccionesVisitadas rV1 , . . . , rVs
Los estados a donde puede cambiar dependern de las variables no analizadas, de lo que se derivan cuatro tipos de transiciones:
268
1.
Si {vN A1 , vN A2 , . . . , vN Ak } = , la variable crrv formar un CRRV y ser aadido a listaCRRV: listaCRRV lcrrv1 , . . . , lcrrvr , crrv El recorrido continuar con otro CRRV derivado de la utilizacin de la recursividad.
2.
Si vN A1 slo est en una restriccin, ya aadida a crrv, lo que implica que (vN A1
/Variables(Gi crrv.restricciones)), se aadir a las variables no resueltas:

Estructura-CRRV (crrv): restricciones r1 , . . . , rn VariablesAnalizadas vA1 , . . . , vAm VariablesNoAnalizadas vN A2 , . . . , vN Ak VariablesNoResueltas vN R1 , . . . , vN Rp , vNA1 restriccionesCiclo rC1 , . . . , rCq listaCRRV lcrrv1 , . . . , lcrrvr restriccionesVisitadas rV1 , . . . , rVs
3.
Si todas las restricciones que tienen a la variable vN A1 , son aquellas ya incluidas en el crrv, en las restriccionesVisitadas, o en las restriccionesCiclo ((
r Gi
| Variables(r)
vN A1 = ) (crrv.restricciones restriccionesCiclo restriccionesVisitadas) = ), signicar que el crrv no formar parte de listCRRV.

listaCRRV lcrrv1 . . . lcrrvr restriccionesVisitadas rV1 . . . rVs
El recorrido continuar con otro CRRV derivado de la utilizacin de la recursividad. 4. En el caso de que la variable no analizada vN A1 est en otras restricciones que no impliquen CRRV duplicados, para (
rGi
| Variables(r) vN A1 = ) (cr-
rv.restricciones restriccionesCiclo restriccionesVisitas) = {rr1 . . . rrt }), donde {rr1 . . . rrt } = , se construirn t CRRV, con las distintas restricciones {rr1 . . . rrt }, resueltos de forma recursiva con el procedimiento recorridoGrafoCRRV.
Estructura-CRRV (crrv): restricciones r1 , . . . , rn , rr1 VariablesAnalizadas {vA1 , . . . , vAm }
269
{rr1 .V ariablesN oResueltas {vN A1 , . . . , vN Ak }} VariablesNoAnalizadas ({vN A1 , . . . , vN Ak }
rr1 .V ariablesN oResueltas)VariablesAnalizadas

VariablesNoResueltas vN R1 , . . . , vN Rp restriccionesCiclo rC1 , . . . , rCq , rr1 listaCRRV lcrrv1 , . . . , lcrrvr restriccionesVisitadas rV1 , . . . , rVs
...
Estructura-CRRV (crrv): restricciones r1 , . . . , rn , rrt VariablesAnalizadas {vA1 , . . . , vAm } {rrt.V araiblesN oAnalizadas {vN A1 , . . . , vN Ak }} VariablesNoAnalizadas ({vN A1 , . . . , vN Ak }
rrt .V ariablesN oResueltas)VariablesAnalizadas

VariablesNoResueltas vN R1 , . . . , vN Rp restriccionesCiclo rC1 , . . . , rCq , rr1 , . . ., rrt listaCRRV lcrrv1 , . . . , lcrrvr restriccionesVisitadas rV1 , . . . , rVs
A.5.2. Complejidad
Para cada Nodo-Restricciones con alguna variable de la consulta, se hace un recorrido del grafo en funcin de las variables no analizadas que tengan los Nodo-Restricciones. Lo que signica que los Nodo-Restricciones de cada Gi se recorrern como mucho m (n2 ), donde m es el nmero de Nodo-Restricciones con variables de la proyeccin, y n el nmero de Nodo-Restricciones del problema. Extendido para G {G1 , . . . , Gk } ser: m1 (n2 1) +
2 . . . + mi (n2 i ) + . . . + mk (nk ), donde mi ser el nmero de Nodo-Restricciones con
variables de la consulta en Gi , y ni el nmero de Nodos-Restricciones en Gi .
A.5.3. Completitud
En esta propiedad ser necesario demostrar que: partiendo de un conjunto de grafos
G = {G1 , . . . , Gn }, el algoritmo obtiene todos los CRRV para dicho conjunto.
270
El algoritmo analiza cada uno de los {G1 , . . . , Gn } en funcin de la consulta. Como para cada Gi se comienza la bsqueda desde cada Nodo-Restricciones con una variable de la proyeccin, se obtendrn todos los CRRV para un Gi . Lo que queda por analizar es que inicializando una Estructura-CRRV con un Nodo-Restricciones (r1 ) que contenga una variable de la consulta, se obtendrn todos los crrv que contengan dicho Nodo-Restricciones. Si las restricciones {r1 , . . . , rn1 , rn } forman un crrv signica que la estructura con las restricciones {r1 , . . . , rn1 } no ser un crrv, y tendr al menos una variable no analizada en comn con rn . Esto signica que existir una transicin tipo 4 entre el crrv {r1 , . . . , rn1 } y {r1 , . . . , rn1 , rn } tal como se explic en la seccin anterior. Esta idea se puede extender a que si las restricciones {r1 , . . . , rn1 } forman parte de una Estructura-CRRV, signica que existe una variable no analizada en {r1 , . . . , rn2 } en comn con la restriccin rn1
. . . Hasta que nalmente la Estructura-CRRV contenga tan slo a {r1 }, que es un estado
inicial si {r1 } contienen a variables de la proyeccin. Que no se obtengan todos los CRRV con el algoritmo, signica que existe un CRRV que no pertenece a la listaCRRV (crrv / {lcrrv1 , . . . , lcrrvr }), donde crrv.restricciones
= {r1 , . . . , rn }. Si crrv es un CRRV, por la denicin tiene que r {r1 , . . . , rn } que

pertenezca a la proyeccin (Variables(Q,{ci , . . ., cj }) = ). Como se obtienen todos los crrv con una restriccin con variables de la proyeccin, no es posible que exista un CRRV que no pertenezca a listaCRRV.
A.5.4. Correccin
Para demostrar que el algoritmo es correcto ser necesario demostrar que todas las Estructuras-CRRV aadidas a listaCRRV son CRRV, lo que tambin implica que sean mnimos y existan CRRV duplicados.
Todos los elementos de la listaCRRV son CRRV:

Derivado de los cuatro tipos de transiciones de estados presentados, se puede demostrar que todas los elementos de ListaCRRV forman un conjunto de restricciones {ci , . . ., cj } donde:
ck {ci , . . ., cj } v Variables(ck ) | v / Variables(Q, ck )
(v Variables(Gi '{ck })) ( cl {Gi ck } | v Variables(cl ))
271
Una Estructura-CRRV se almacenar en la listaCRRV si no le quedan variablesNoAnalizadas (Transicin 1). Para eliminar las variables de la lista de VariablesNoAnalizadas se pueden dar dos casos: que sea una variable no resuelta (Transicin 2), por lo que cumple la condicin de la denicin
cl {Gi ck } | v Variables(cl )); o
que est en otra restriccin (Transicin 4), por lo que cumple la condicin de la denicin (v Variables(Gi '{ck }). Si no existe ninguna restriccin que no est incluida ya en ret-
riccionesCiclo o restriccionesVisitadas, el crrv no formar parte de la solucin (Transicin

3). La clusula de la denicin relativa a las variables de la proyeccin (Variables(Q,{ci ,
. . ., cj }) = ), tambin se cumple porque siempre la bsqueda de CRRV se comienza

inicializando una Estructura-CRRV con restricciones con variables de la proyeccin.
Los CRRV obtenidos son mnimos:

Si una Estructura-CRRV almacenada en la listaCRRV no fuera mnima, signicara que para un CRRV de salida del algoritmo con las restricciones
{r1 , . . . , ri1 , ri , ri+1 , . . . , rn }: ri {r1 , . . . , ri1 , ri , ri+1 , . . . , rn } | {r1 , . . . , ri1 , ri+1 , . . . , rn } es un CRRV.
Si {r1 , . . . , ri1 , ri+1 , . . . , rn } cumple la denicin de CRRV, signica que todas las variables que no sean de la proyeccin y que estn en ms de una restriccin de Gi , estn al menos en dos restricciones del CRRV. Por lo que el conjunto de restricciones
{r1 , . . . , ri1 , ri , ri+1 , . . . , rn } no sera un CRRV ya que la funcin esMnimo(CRRV) habra

detectado que no todas las restricciones son necesarias para formas el CRRV.
No existen CRRV duplicados en la lista listaCRRV

Gracias a utilizar las estructuras auxiliares restriccionesVisitadas y restCiclo no pueden existir dos CRRV duplicados en la listaCRRV. La lista restriccionesVisitas incluye a las restricciones con variables de la proyeccin para las cuales ya se han encontrado todos los CRRV donde est involucrada. Para que dos CRRV formados por las mismas restricciones, pero aadidas a la Estructura-CRRV en diferente orden ({r1 , . . . , ri1 , ri , . . . , rj , . . . , rn }, {r1 , . . . , ri1 , rj , . . . , ri , . . . , rn }), formarn parte de la listaCRRV de salida, tendra que
272
ocurrir: ri y rj tienen una relacin OR con ri1 , por lo que por la Transicin 4, se incluira
ri en el atributo restCiclo de los siguientes recorridos y ri no podr formar parte de la

Estructura-CRRV con las restricciones {r1 , . . . , ri1 , rj }.
Apndice B Ejemplos de Tablas de Restricciones para el Anlisis de Eciencia

En este apndice se muestran las restricciones usadas para todos los ejemplos del captulo 8. Dicho captulo utiliza el ejemplo de la diagnosis basada en modelos y los sistemas de informacin geogrca. Tambin se presenta la aplicacin desarrollada para facilitar la captura de restricciones necesarias para realizar las consultas sobre los sistemas de informacin geogrca.
B.1.
Ejemplo para la diagnosis basada en modelos
El caso de estudio de la diagnosis basada en modelos utiliza un conjunto de componentes distribuidos en cuatro subsistemas. Las restricciones concretas se muestran en las guras: B.1, B.2, B.3 y B.4.
B.2.
Aplicacin para la captura de restricciones sobre SIG
Lo primero para poder hacer consultas sobre un conjunto de restricciones de una Base de Datos de Restricciones, ser obtener y almacenar dichas restricciones. En esta tesis se ha desarrollado e implementado una aplicacin que ayuda a la captura de puntos de
274
Apndice B. Ejemplos de Tablas de Restricciones para el Anlisis de Eciencia
Figura B.1: Contenido de la tabla Componentes para el subsistema 1
Figura B.2: Contenido de la tabla Componentes para el subsistema 2 un mapa con el objetivo de obtener las restricciones y almacenarlas en la Base de Datos de Restricciones, cuya interfaz se muestra en la gura B.5. Dicha aplicacin utiliza el mtodo de Lagrange para la aproximacin mediante polinomios a un conjunto de puntos, dicho mtodo utiliza la interpolacin mediante mnimos cuadrados [54][7]. La utilizacin de polinomios tambin conlleva una aproximacin de la realizada, pero que se acerca ms a la realidad que si slo se utilizan rectas, a la vez que necesita menos restricciones para aproximar una supercie curva.
Aplicacin para la captura de restricciones sobre SIG
275
B.2.1. Pasos para la obtencin de restricciones

1. Marcando algunos de los puntos del contorno de la gura que se quiera obtener su restriccin. 2. Incrementar el grado del polinomio hasta que se acerque lo ms posible a lo que se quiere representar. 3. Determinar si es un polinomio de igualdad (Equals), si el polinomio es el lmite inferior (Up) o es el lmite superior (Down) de la supercie marcada. 4. Determinar el nombre de dicha gura en la zona de nombre y salvar (Save).
276
5.
Si la zona a representar tiene que estar representada por varias restricciones, con una relacin conjuntiva, se continan aadiendo restricciones manteniendo el nombre. En caso contrario, se utiliza el botn Clear para comenzar con una nueva restriccin.
La aplicacin tambin muestra el coeciente de determinacin que se est utilizando, y el valor residual de la suma de los cuadrados de la aproximacin. Cuando una restriccin se almacena en la base de datos tambin se almacenan las envolventes para cada una de las variables, que son directamente obtenidos de los puntos aadidos por el usuario.
Figura B.5: Aplicacin para el almacenamiento de Restricciones
B.3. Contenido de las tablas de Sistemas de Informacin Geogrca

Para realizar las distintas pruebas sobre las operaciones de Seleccin, Unin y Diferencia, se han creado cuatro tablas con atributos clsicos y atributos restriccin. Dichas tablas son Calles (gura B.6), Residenciales (gura B.7), Censos (gura B.9) y Obras
Contenido de las tablas de Sistemas de Informacin Geogrca
277
(gura B.10). En la gura B.8 se muestran las envolventes de las variables x e y para las distintas restricciones de la tabla Residenciales, informacin que se almacena en la tabla Restricciones/Variables. En realidad, no se utiliza el nombre de la variable, sino su identicador almacenado en la tabla Variables, pero en esta gura se utiliza el nombre de las variables para facilitar su entendimiento.
Figura B.6: Contenido de la tabla Calles
Figura B.7: Contenido de la tabla Residenciales
Contenido de las tablas de Sistemas de Informacin Geogrca
279
Figura B.8: Envolventes de las variables de Residenciales
Figura B.9: Contenido de la tabla de Censos
280
Figura B.10: Contenido de la tabla de Obras
Bibliografa
[1] J. M. Almendros-Jimnez, A. Becerra-Tern, A Safe Relational Calculus for Functional Logic Deductive Databases, Electronic Notes on Theoretical Computer Science 86 (3). [2] W. G. Aref, H. Samet, Extending a DBMS with Spatial Operations, in: SSD '91: Proceedings of the Second International Symposium on Advances in Spatial Databases, Springer-Verlag, London, UK, 1991. [3] M. P. Atkinson, F. Bancilhon, D. J. DeWitt, K. R. Dittrich, D. Maier, S. B. Zdonik, The Object-Oriented Database System Manifesto., in: the First International Conference on Deductive and Object-Oriented Databases, 1989. [4] F. Bancilhon, S. Khoshaan, A Calculus for Complex Objects., in: PODS, 1986. [5] S. Basu, Algorithms in semi-algebraic geometry, ph D thesis (1996). [6] S. Basu, R. Dhandapani, R. Pollack, On the Realizable Weaving Patterns of Polynomial Curves in R3, in: Symposium on Graph Drawing, vol. 3383 of Lecture Notes in Computer Science, Springer, 2004. [7] B. Beckermann, E. Sa, the sensitivity of least squares polynomial approximation (1998). [8] N. Beckmann, H.-P. Kriegel, R. Schneider, B. Seeger, The R*-Tree: An Ecient and Robust Access Method for Points and Rectangles., in: SIGMOD Conference, 1990. [9] A. Belussi, E. Bertino, B. Catania, Manipulating Spatial Data in Constraint Databases, in: M. Scholl, A. Voisard (eds.), Proceedings of the 5th International Symposium on Large Spatial Databases (SSD), vol. 1262, Springer-Verlag, 1997.
282
BIBLIOGRAFA
[10] A. Belussi, E. Bertino, B. Catania, An Extended Algebra for Constraint Databases, Knowledge and Data Engineering 10 (5) (1998) 686705. [11] F. Benhamou, L. Granvilliers, Continuous and interval constraints, in: F. Rossi, P. van Beek, T. Walsh (eds.), Handbook of Constraint Programming, Foundations of Articial Intelligence, chap. 16, Elsevier Science Publishers, Amsterdam, The Netherlands, 2006. [12] F. Benhamou, P. V. Hentenryck, Introduction to the Special Issue on Interval Constraints., Constraints 2 (2) (1997) 107112. [13] M. Berler, J. Eastman, D. Jordan, C. Russell, O. Schadow, T. Stanienda, F. Velez, The object data standard: ODMG 3.0, Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 2000. [14] C. Bessire, J.-C. Rgin, Arc Consistency for General Constraint Networks: Preliminary Results., in: IJCAI (1), 1997. [15] J. Bitner, E. M. Reingold, Backtracking programming techniques, Comm of the ACM 18 (11) (1975) 651656. [16] R. E. Bixby, E. A. Boyd, R. Z. Ros-Mercado (eds.), Integer Programming and Combinatorial Optimization, 6th International IPCO Conference, Houston, Texas, USA, June 22-24, 1998, Proceedings, vol. 1412 of Lecture Notes in Computer Science, Springer, 1998 (1998). [17] A. Brodsky, V. S. andJ. Chen, P. Exarkhopoulo, The CCUBE Constraint ObjectOriented Database System, International Conference on Management of Data Procceding, Philadelphia (1999) 577579. [18] A. Brodsky, Y. Kornatzky, The Lyli c language: Querying constraint object, In Int.
Conf. ACM SIGMOD, on Management of Data.

[19] A. Brodsky, V. E. Segal, J. Chen, P. A. Exarkhopoulo, The CCUBE Constraint Object-Oriented Database System., Constraints 2 (3/4) (1997) 245277. [20] A. Brodsky, V. E. Segal, J. Chen, P. A. Exarkhopoulo, The CCUBE Constraint Object-Oriented Database System, in: SIGMOD '99: Proceedings of the 1999 ACM SIGMOD international conference on Management of data, ACM Press, 1999.
BIBLIOGRAFA
283
[21] A. Brodsky, X. S. Wan, On approximation-based query evaluation, expensive predicates and constraint objects, in: ILPS95 Workshop on Constraints, Databases and Logic Programming, Portland, 1995. [22] C. W. Brown, Improved projection for Cylindrical Algebraic Decomposition, J. Symb. Comput. 32 (5) (2001) 447465. [23] B. Buchberger, Grbner bases: An algorithmic method in polynomial ideal theory, Multidimensional Systems Theory, N. K. Bose, ed. (1985) 184232. [24] J.-H. Byon, P. Z. Revesz, DISCO: A Constraint Database System with Sets., in: CDB, 1995. [25] Y. Caseau, P.-Y. Guillo, E. Levenez, A Deductive and Object-Oriented Approach to a Complex Scheduling Problem, Springer, Berlin, Heidelberg, 1993. [26] R. G. G. Cattell, The Object Database Standard: ODMG-93 (Release 1.1), Morgan Kaufmann, 1994. [27] B. Caviness, J. e. Johnson, Quantier Elimination and Cylindrical Algebraic Decomposition, Springer-Verlag. [28] S. Ceri, G. Gottlob, L. Tanca, What you always wanted to know about Datalog (and never dared to ask), vol. 1, IEEE Educational Activities Department, Piscataway, NJ, USA, 1989. [29] L. Chang, A. K. Mackworth, Local Consistency in Junction Graphs for ConstraintBased Inference., in: AAAI, 2006. [30] J. Chomicki, D. Q. Goldin, G. M. Kuper, D. Toman, Variable Independence in Constraint Databases., IEEE Trans. Knowl. Data Eng. 15 (6) (2003) 14221436. [31] J. Chomicki, J. Marcinkowski, On the Computational Complexity of Consistent Query Answers, CoRR cs.DB/0204010. [32] E. F. Codd, A Relational Model of Data for Large Shared Data Banks, Commun. ACM 13 (6) (1970) 377387. [33] E. F. Codd, Relational database: a practical foundation for productivity, Commun. ACM 25 (2) (1982) 109117.
284
BIBLIOGRAFA
[34] J. Cohen, Constraint Logic Programming Languages., Commun. ACM 33 (7) (1990) 5268. [35] G. E. Collins, J. R. Johnson, W. Krandick, Interval arithmetic in Cylindrical Algebraic Decomposition, Journal of Symbolic Computation 34 (2) (2002) 145157. [36] R. M. Colomb, Deductive Databases and Their Applications, Taylor & Francis, Inc., Bristol, PA, USA, 1998. [37] A. Croker, V. Dhar, A Knowledge Representation for Constraint Satisfaction Problems, IEEE Trans. Knowl. Data Eng. 5 (5) (1993) 740752. [38] P. Dasgupta, P. P. Chakrabarti, A. Dey, S. Ghose, W. Bibel, Solving Constraint Optimization Problems from CLP-Style Specications Using Heuristic Search Techniques, IEEE Transactions on Knowledge and Data Engineering 14 (2) (2002) 353 368. [39] J. Davenport, J. Heintz, Real Quantier Elimination Is Doubly Exponential, J. Symb. Comput, 5 (1988) 2935. [40] R. Davis, Diagnostic reasoning based on structure and behavior, In Articial Intelligence 24 (1984) 347410. [41] M. G. de la Banda, P. J. Stuckey, J. Wazny, Finding all minimal unsatisable subsets, in: PPDP '03: Proceedings of the 5th ACM SIGPLAN international conference on Principles and practice of declaritive programming, ACM Press, 2003. [42] R. Dechter, Constraint Processing (The Morgan Kaufmann Series in Articial Intelligence), Morgan Kaufmann, 2003. [43] R. Dechter, I. Meiri, Experimental evaluation of preprocessing algorithms for constraint satisfaction problems, Artif. Intell. 68 (2) (1994) 211241. [44] J. V. den Bussche, onstraint Databases, Queries, and Query Languages", Constraint Databases, G. Kuper and L. Libkin and J. Paredaes, Springer, 2000. [45] R. S. Devarakonda, Object-Relational Database Systems - The Road Ahead, ACM Electronic Magazine (Agosto).
BIBLIOGRAFA
285
[46] F. Dumortier, M. Gyssens, L. Vandeurzen, D. V. Gucht, On the Decidability of Semi-Linearity of Semi-Algebraic Sets and its Implications for Spatial Databases, in: Proceedings of the Sixteenth ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems, May 12-14, 1997, Tucson, Arizona, ACM Press, 1997. [47] R. Fagin, Normal forms and relational database operators, in: SIGMOD '79: Proceedings of the 1979 ACM SIGMOD international conference on Management of data, ACM Press, New York, NY, USA, 1979. [48] J. Faugre, A new ecient algorithm for computing Grbner bases without reduction to zero (f5), ACM Press, New York, NY, USA, 2002. [49] J.-C. Faug`ere, A new ecient algorithm for computing grbner bases (f4 ), Journal of Pure and Applied Algebra 139 (1-3) (1999) 6188. [50] L. Fergaras, D. Maier, Towards an eective calculus for object query processing, In Proc ACM SIGMOD Conf. on Management of Data, 1995. [51] R. Finkelstein, Is your database relational? Part 2 of Dr. Codd's rules for relational databases, Data Based Advis. 5 (6) (1987) 6668. [52] P. Flener, B. Hnich, Z. Kiziltan, A meta-heuristic for subset problems, in: PADL '01: Proceedings of the Third International Symposium on Practical Aspects of Declarative Languages, Springer-Verlag, London, UK, 2001. [53] E. C. Freuder, A sucient condition for backtrack-free search, J. ACM 29 (1) (1982) 2432. [54] E. Fuchs, K. Donner, Fast Least-Squares Polynomial Approximation in Moving Time Windows, in: ICASSP '97: Proceedings of the 1997 IEEE International Conference on Acoustics, Speech, and Signal Processing (ICASSP '97)-Volume 3, IEEE Computer Society, Washington, DC, USA, 1997. [55] R. Gasca, C. D. Valle, R. Ceballos, M. Toro, An Integration of FDI and DX approaches to polinomial models, 14th International Workshop on principles of Diagnosis - DX.
286
BIBLIOGRAFA
[56] R. M. Gasca, J. A. Ortega, M. Toro, A framework for semiqualitative reasoning in engineering applications., Applied Articial Intelligence 16 (3) (2002) 173197. [57] F. Geerts, B. Kuijpers, On the decidability of termination of query evaluation in transitive-closure logics for polynomial constraint databases., Theor. Comput. Sci. 336 (1) (2005) 125151. [58] D. Goldin, P. Kanellakis, Constraint Query Algebras Constraints, Journal E. Freuder editor. [59] D. Goldin, A. Kutlu, M. Song, Extending the Constraint Database framework, in: PCK50: Proceedings of the Paris C. Kanellakis memorial workshop on Principles of computing & knowledge, ACM Press, New York, NY, USA, 2003. [60] D. Q. Goldin, Taking Constraints out of Constraint Databases., in: Constraint DataBases, vol. 3074 of Lecture Notes in Computer Science, Springer, 2004. [61] D. Q. Goldin, A. Kutlu, M. Song, F. Yang, The Constraint Database Framework: Lessons Learned from CQA/CDB., in: ICDE, 2003. [62] S. W. Golomb, L. D. Baumert, Backtrack programming., J. ACM 12 (4) (1965) 516524. [63] J. C. Gonzlez-Moreno, M. T. Hortal-Gonzlez, M. Rodrguez-Artalejo, Semantics and Types in Functional Logic Programming., in: Fuji International Symposium on Functional and Logic Programming, 1999. [64] L. Granvilliers, F. Goualard, F. Benhamou, Box Consistency through Weak Box Consistency, in: ICTAI '99: Proceedings of the 11th IEEE International Conference on Tools with Articial Intelligence, IEEE Computer Society, Washington, DC, USA, 1999. [65] R. Greiner, B. A. Smith, R. W. Wilkerson, A correction to the algorithm in Reiter's theory of diagnosis, Articial Intelligence 41 (1) (1989) 7988. [66] R. Gross, R. W. Marti, DeCor a Deductive Constraint Database System., in: WLP, 1994. [67] R. Gross, R. W. Marti, Managing Temporal Knowledge using a Deductive Constraint Database System., in: BTW, 1995.
BIBLIOGRAFA
287
[68] R. Gross-Brunschwiler, Implementation of Constraint Database Systems Using a Commpiler-Time Rewrite Approach, Ph.D. thesis, Swis Federal Institute of Technology , Zrich (May 1996). [69] S. Grumbach, P. Rigaux, M. Scholl, L. Segoun, DEDALE, A Spatial Constraint Database., in: Workshop on Database Programming Languages, 1997. [70] S. Grumbach, P. Rigaux, L. Segoun, The DEDALE System for Complex Spatial Queries., in: SIGMOD Conference, 1998. [71] M. Hadjieleftheriou, G. Kollios, P. Bakalov, V. J. Tsotras, Complex Spatio-Temporal Pattern Queries., in: VLDB, 2005. [72] A. Y. Halevy, I. S. Mumick, Y. Sagiv, O. Shmueli, Static analysis in Datalog extensions, J. ACM 48 (5) (2001) 9711012. [73] J. Han, Constraint-Based Query Evaluation in Deductive Databases, Knowledge and Data Engineering 6 (1) (1994) 96107. [74] J. Han, Y. Fu, W. Wang, K. Koperski, O. Zaiane, Dmql: A data mining query language for relational databases, in: Proc.oftheSIG-MOD'96 DKMD Workshop, 1996. [75] W. Hodges, Some Strange Quantiers., in: Structures in Logic and Computer Science, 1997. [76] X. Huang, A General Extension of Constraint Propagation for Constraint Optimization., in: CP, 2004. [77] T. Hulubei, B. O'Sullivan, Search Heuristics and Heavy-Tailed Behaviour., in: CP, 2005. [78] ILOG, Jsolver 2.1, Reference Manual April. [79] Ilog, Inc., Solver CPLEX, http://www.ilog.fr/products/cplex/. [80] R. Isermann, Supervision, fault-detection and fault-diagnosis methods an introduction, Control Engineering Practice 5 (1997) 639652. [81] J. Jaar, J.-L. Lassez, Constraint Logic Programming., in: POPL, 1987.
288
BIBLIOGRAFA
[82] J. Jaar, M. J. Maher, Constraint Logic Programming: A Survey., J. Log. Program. 19/20 (1994) 503581. [83] P. W. P. Jr., Search rearrangement backtracking and polynomial average time., Artif. Intell. 21 (1-2) (1983) 117133. [84] P. C. Kanellakis, G. M. Kuper, P. Revesz, Constraint Query Languages, Symposium on Principles of Database Systems (1990) 299313. [85] K. Kask, New Search Heuristics for Max-CSP, in: Principles and Practice of Constraint Programming, 2000. [86] S. Khoshaan, R. Abnous, Object-Orientation: Concepts, Languages, Databases, User Interfaces, John Wiley & Sons, New Jersey, 1990. [87] M. Kifer, W. Kim, Y. Sagiv, Querying Object-Oriented Databases., in: SIGMOD Conference, 1992. [88] J. D. Kleer, An Assumption-based Truth Maintenance System, Articial Intelligence 28 2 (1986) 127161. [89] J. D. Kleer, A. Mackworth, R. Reiter, Characterizing diagnoses and systems, Articial Intelligence 56 2-3 (1992) 197222. [90] J. D. Kleer, B. Williams, Diagnosing multiple faults, Art. Int. [91] M. Koubarakis, S. Skiadopoulos, Tractable Query Answering in Indenite Constraint Databases: Basic Results and Applications to Querying Spatiotemporal Information, in: Spatio-Temporal Database Management, 1999. [92] T. Kudrass, M. Conrad, Management of XML Documents in Object-Relational Databases., in: EDBT Workshops, 2002. [93] G. Kuper, L. Libkin, J. Paredaes, Constraint Databases, Springer, 1998. [94] G. Kuper, L. Libkin, J. Paredaes, "Introduction", Constraint Databases, G. Kuper and L. Libkin and J. Paredaes, Springer, 2000. [95] G. Kuper, L. Libkin, J. Paredaes, "The DISCO SYSTEM", Constraint Databases, G. Kuper and L. Libkin and J. Paredaes, Springer, 2000.
BIBLIOGRAFA
289
[96] H.-J. Lee, S.-W. Lee, H.-J. Kim, Design and implementation of an extended relationship semantics in an ODMG-compliant OODBMS, J. Syst. Softw. 76 (2) (2005) 171180. [97] C. K.-S. Leung, Dynamic FP-Tree Based Mining of Frequent Patterns Satisfying Succinct Constraints., in: CDB, 2004. [98] L. Libkin, Variable independence for rst-order denable constraints, ACM Trans. Comput. Logic 4 (4) (2003) 431451. [99] A. Lomonosov, Graph and combinatorial algorithms for geometric constraint solving, Ph.D. thesis, chair-Meera Sitharam (2004). [100] S. Lucas, Context-sensitive Computations in Functional and Functional Logic Programs., Journal of Functional and Logic Programming 1998 (1). [101] A. Macintyre, K. McKenna, L. van den Dries, Elimination of quantiers in algebraic structures, Adv. Math. 47 (1) (1983) 7487. [102] A. K. Mackworth, Consistency in networks of relations., Artif. Intell. 8 (1) (1977) 99118. [103] A. K. Mackworth, E. C. Freuder, The Complexity of Constraint Satisfaction Revisited, Articial Intelligence 59 (1-2) (1993) 5762. [104] D. Maier, J. B. Cushing, Treating Programs as Objects: The Computational Proxy Experience, Springer, Berlin, Heidelberg, 1993. [105] G. Maps, http://maps.google.es/maps (2007). [106] E. Marcos, B. Vela, J. M. Cavero, A methodological approach for Object-Relational Database design using uml., Inform., Forsch. Entwickl. 18 (3-4) (2004) 152164. [107] K. Marriott, P. J. Stuckey, "Programming with Constraints. An introduction", Simplication, Optimization and Implication, The Mitt Press, 1998. [108] J. L. Martin, V. Reiner, Factorizations of some weighted spanning tree enumerators, Journal of Combinatorial Theory, Series A 104 (2) (2003) 287300.
290
BIBLIOGRAFA
[109] E. Mayol, E. Teniente, Consistency preserving updates in Deductive Databases, vol. 47, Elsevier Science Publishers B. V., Amsterdam, The Netherlands, The Netherlands, 2003. [110] S. McCallum, Solving Polynomial Strict Inequalities using Cylindrical Algebraic Decomposition., Comput. J. 36 (5) (1993) 432438. [111] U. Montanari, Networks of constraints: Fundamental properties and applications to picture processing., Inf. Sci. 7 (1974) 95132. [112] B. A. Nadel, Tree search and ARC consistency in constraint satisfaction algorithms, Springer-Verlag (1988) 287342. [113] B. A. Nadel, Constraint satisfaction algorithms, Comput. Intell. 5 (4) (1990) 188 224. [114] S.ieva, F. Senz-Prez, J. Snchez, Towards a Constraint Deductive Database Language based on Hereditary Harrop Formulas, in: P. Lucio, F. Orejas (eds.), Sextas Jornadas de Programacin y Lenguajes, PROLE, 2006. [115] M.yberg, M. Krysander, Combining AI, FDI, and statistical hypothesis-testing in a framework for diagnosis, in: Proceedings of IFAC Safeprocess'03, Washington, USA, 2003. [116] A. Oliv, Integrity Constraints Checking In Deductive Databases, in: G. M. Lohman, A. Sernadas, R. Camps (eds.), 17th International Conference on Very Large Data Bases, September 3-6, 1991, Barcelona, Catalonia, Spain, Proceedings, Morgan Kaufmann, 1991. [117] E. Oomoto, M. Kamitani, T. Takamatsu, Path existence constraints in ObjectOriented Databases (2000) 4558. [118] B. O'Sullivan, P. van Beek, Introduction to the Special Issue on Principles and Practice of Constraint Programming (cp 2005)., Constraints 11 (2-3) (2006) 8384. [119] E. Pardede, J. W. Rahayu, D. Taniar, On using collection for aggregation and association relationships in XML object-relational storage, in: SAC '04: Proceedings of the 2004 ACM symposium on Applied computing, ACM Press, New York, NY, USA, 2004.
BIBLIOGRAFA
291
[120] K. Parsaye, M. Chignell, Intelligent database tools & applications, John Wiley & Sons, Inc., New York, NY, USA, 1993. [121] S. Prestwich, Stochastic local search in constrained spaces (2000) 2739. [122] S. Prestwich, Local Search and Backtracking vs Non-Systematic Backtracking Technical Report FS-01-04 (2001) 109115. [123] B. Pulido, C. Alonso, Possible conicts, ARRs, and conicts (2002). [124] V. Ramanathan, P. Z. Revesz, Constraint Database Solutions to the Genome Map Assembly Problem., in: Constraint DataBases, vol. 3074 of Lecture Notes in Computer Science, Springer, 2004. [125] S. Rasetic, J. Sander, J. Elding, M. A. Nascimento, A Trajectory Splitting Model for Ecient Spatio-Temporal Indexing., in: VLDB, 2005. [126] S. Ratschan, Approximate quantied constraint solving by cylindrical box decomposition (2002). [127] R. Reiter, A theory of diagnosis from rst principles, Articial Intelligence 32 1 (1987) 5796. [128] W. Research, Mathematica 5, Reference Manual April. [129] P. Revesz, Datalog and Constraints, Constraint Databases (2000) 155170. [130] P. Revesz, Introduction to Constraint Databases, Springer, 2001. [131] P. Z. Revesz, Problem Solving in the DISCO Constraint Database System, in: V. Gaede, A. Brodsky, O. Gunter, D. Srivastava, V. Vianu, M. Wallace (eds.), Proceedings of the 2nd Workshop on Constraint Databases and Applications, vol. 1191, Springer-Verlag, 1997. [132] P. Z. Revesz, MLPQ/PReSTO User Manual, http:// www.cse.unl.edu/
revesz/MLPQ/mlpq.htm.
[133] P. Z. Revesz, R. Chen, P. Kanjamala, Y. Li, Y. Liu, Y. Wang, The MLPQ/GIS Constraint Database System, in: Proceedings of the 2000 ACM SIGMOD International Conference on Management of Data, May 16-18, 2000, Dallas, Texas, USA, ACM, 2000.
292
BIBLIOGRAFA
[134] P. Rigaux, M. Scholl, L. Segoun, S. Grumbach, Building a constraint-based spatial database system: model, languages, and implementation., Inf. Syst. 28 (6) (2003) 563595. [135] O. W. Salomons, F. van Slooten, F. J. A. M. van Houten, H. J. J. Kals, Conceptual graphs in constraint based re-design, in: SMA '95: Proceedings of the third ACM symposium on Solid modeling and applications, ACM Press, New York, NY, USA, 1995. [136] S. Sarawagi, S. Thomas, R. Agrawal, Integrating Association Rule Mining with Relational Database Systems: Alternatives and Implications, Data Min. Knowl. Discov. 4 (2-3) (2000) 89125. [137] R. Selje, A new method for integrity constraint checking in Deductive Databases, Data Knowl. Eng. 15 (1) (1995) 63102. [138] F. G. Sener, New Module for Damage Probabilistic Calculations with ecient user interface and including the latest classication society rules, internal Report (2005). [139] M. Shakeri, Implementation of an automated operation planning and optimum operation sequencing and tool selection algorithms, Comput. Ind. 54 (3) (2004) 223236. [140] A. Soer, H. Samet, Two data organizations for Storing Symbolic Images in a Relational Database System, in: DS-8: Proceedings of the IFIP TC2/WG2.6 Eighth Working Conference on Database Semantics- Semantic Issues in Multimedia Systems, Kluwer, B.V., Deventer, The Netherlands, The Netherlands, 1998. [141] M. Spivey, An introduction to logic programming through Prolog, Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 1996. [142] M. Staroswiecki, P. Declerk., Analytical redundancy in non linear interconnected systems by means of structural analysis., in: IFAC Advanced Information Processing in Automatic Control (AIPAC-89), Nancy, France, 1989. [143] M. Stonebraker, D. Moore, P. Brown, Object-Relational DBMSs: Tracking the Next Great Wave, Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 1998. [144] A. W. Strzebonski, Cylindrical Algebraic Decomposition using validated numerics, Journal of Symbolic Computation 49 (9) (2006) 10211038.
BIBLIOGRAFA
293
[145] T. Sturm, Reasoning over Networks by Symbolic Methods, Applicable Algebra in Engineering, Communication and Computing 10 (1) (1999) 7996. [146] V. Telerman, Using Constraint Solvers in CAD/CAM Systems, in: PSI '02: Revised Papers from the 4th International Andrei Ershov Memorial Conference on Perspectives of System Informatics, Springer-Verlag, London, UK, 2001. [147] D. Toman, Constraint Databases and Program Analysis Using Abstract Interpretation, in: Constraint Databases and Applications, 1997. [148] E. Tsang, J. Borrett, A. Kwan, An attempt to map the performance of a range of algorithm and heuristic combinations (1995). [149] J. Ullman, Assigning an appropriate meaning to database logic with negation (1994). [150] P. Veltri, Constraint database query evaluation with approximation, in: ITCC '01: Proceedings of the International Conference on Information Technology: Coding and Computing, IEEE Computer Society, Washington, DC, USA, 2001. [151] R. Wallace, Factor Analytic Studies of CSP Heuristics., in: CP, 2005. [152] V. Weispfenning, Aspects of quantier elimination in algebra, in: Universal algebra and its links with logic, algebra, combinatorics and computer science, vol. 4 of R & E Res. Exp. Math., Heldermann, Berlin, 1984. [153] V. Weispfenning, The complexity of linear problems in elds, Journal of Symbolic Computation (1988) 3 27. [154] P. T. Whelan, CAD/CAM database management system requirements for mechanical parts, ph D thesis (1989). [155] F. Wotawa, A variant of reiter's hitting-set algorithm., Inf. Process. Lett. 79 (1) (2001) 4551. [156] S. B. Zdonik, D. Maier (eds.), Readings in Object-Oriented Database Systems, Morgan Kaufmann, 1990.

Bases de Datos

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Bases de Datos

Diunggah oleh

Hak Cipta:

Format Tersedia

LORCDB: Gestor de Bases de Datos Objeto-Relacionales de Restricciones

Da Mara Teresa Gmez Lpez

Dr. D. Rafael Martnez Gasca Dr. D. Carmelo Del Valle Sevillano

Sevilla, Diciembre de 2007

Financiacin: Este trabajo ha sido nanciado por el Ministerio de Ciencia y Tecnologa

LORCDB: Gestor de Bases de Datos Objeto-Relacionales de Restricciones

Fdo. Rafael Martnez Gasca

Carmelo del Valle Sevillano Universidad de Sevilla

rea de Lenguajes y Sistemas Informticos Sevilla, 19 de Octubre de 2007

Yo, Mara Teresa Gmez Lpez, con DNI nmero 28.631.064-C,

DECLARO BAJO JURAMENTO

LORCDB: Gestor de Bases de Datos Objeto-Relacionales de Restricciones

Lo cual rmo en Sevilla, 19 de Octubre de 2007.

Fdo. Mara Teresa Gmez Lpez

2. Antecedentes de las Bases de Datos

3. Antecedentes de las Bases de Datos de Restricciones

4. Propuesta de Modelado para las Bases de Datos de Restricciones

4.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 4.2. Formalizacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 4.2.1. Restriccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

5. Arquitectura LORCDB. Un Gestor para BDdR

6. Implementacin del lenguaje CORQL

7. La Diagnosis de Fallos Basada en Modelos: Un caso de estudio

7.6. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

8. Optimizacin y Pruebas en la Evaluacin de Consultas en BDdR

9. Conclusiones y Trabajos Futuros

A. Algoritmo para la Proyeccin Simblica

B. Ejemplos de Tablas de Restricciones para el Anlisis de Eciencia

6.5. Pasos de la operacin de Seleccin

8.7. Residenciales de la zona . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 8.8. Censos de la zona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

B.10.Contenido de la tabla de Obras . . . . . . . . . . . . . . . . . . . . . . . . 280

straint Databases es Bases de Datos de Restricciones (BDdR) queriendo destacar

Sistemas de Informacin Geogrca:

Quin es el propietario de la parcela 6? Qu tipo de cosecha tiene la parcela 3?

Qu parcelas estn al sur de la parcela 2?

Pas A Pas B Pas C Pas D

Diagnosis de Fallos Basada en Modelos:

Contexto del Problema

Qu relacin de comportamiento tienen las variables a, b, c, d y f ? En este

Contexto del Problema

Contexto del Problema

concreta se representar dicha informacin de una manera nita mediante restricciones.

Capa fsica: fichero de almacenamiento, estructura de indexacin, mtodos de acceso a datos...

1.3. Justicacin del Trabajo

El objetivo general de esta tesis es Denir un Gestor de Base de Datos de

Redenir el concepto de Base de Datos de Restricciones para que se acerque

Ampliar el lenguaje SQL para el tratamiento de restricciones. Acorde con

Buscar una solucin adaptable a distintos problemas. La arquitectura que

Esta tesis doctoral se ha desarrollado en el marco de los siguientes proyectos de inves-

Investigador principal: Rafael Martnez Gasca Perodo de duracin: 2000 2003

El resto del documento est estructurado en los siguientes captulos:

Captulo 3. Antecedentes de las Bases de Datos de Restricciones. Desde los

Captulo 5. Arquitectura LORCDB. Un Gestor para BDdR. Este captulo

Captulo 6. Implementacin del lenguaje CORQL. Muestra los detalles de

Captulo 7. La Diagnosis de Fallos Basada en Modelos: Un caso de estudio.

Captulo 8. Optimizacin de Evaluacin de Consultas en BDdR. En el

Captulo 9. Conclusiones y Trabajos Futuros. Finalmente se presentan las

Anexo A. Algoritmos para la Proyeccin Simblica. Este anexo presenta

Anexo B. Tablas de Restricciones para el Anlisis de Eciencia. Muestra

Captulo 2 Antecedentes de las Bases de Datos

Captulo 2. Antecedentes de las Bases de Datos

Bases de Datos Intensivas: Estas bases de datos pueden deducir informacin no

Figura 2.1: Caractersticas de las bases de datos

Captulo 2. Antecedentes de las Bases de Datos

2.2.1. CAD - Computer-Aided Design y CAM - Computer-Aided Manufacturing

. . ., involucrando software y en algunas ocasiones hardware especco. Permite disear

Financiacin: Este trabajo ha sido nanciado por el Ministerio de Ciencia y Tecnologa

Lo cual rmo en Sevilla, 19 de Octubre de 2007.

B. Ejemplos de Tablas de Restricciones para el Anlisis de Eciencia

Sistemas de Informacin Geogrca:

concreta se representar dicha informacin de una manera nita mediante restricciones.

1.3. Justicacin del Trabajo

El objetivo general de esta tesis es Denir un Gestor de Base de Datos de

Redenir el concepto de Base de Datos de Restricciones para que se acerque

Anexo B. Tablas de Restricciones para el Anlisis de Eciencia. Muestra

. . ., involucrando software y en algunas ocasiones hardware especco. Permite disear

datos espacio-temporales. Un ejemplo de estas aplicaciones puede ser el control de trco

Estructura de datos homognea: El modelo relacional dene la homogeneidad

Capacidad de denir nuevos tipos: Los sistemas gestores de bases de datos

Capacidad de identicacin de objetos: Diferenciando entre el concepto de

Polimorsmo y sobrecarga: Pudiendo aplicarse el mismo mtodo sobre objetos

El lenguaje de denicin de objetos

Facilita la denicin de tipo complejos y relaciones Directa y Extensible