cenidet20E… · Azucena Montes Rendón Jurado: Dr. Hugo Estrada Esquivel Presidente M.C. Mario Guillén Rodríguez Secretario M.C. Humberto Hernández García Vocal Cuernavaca, Morelos,

cenidet Centro Nacional de Investigación y Desarrollo Tecnológico

Departamento de Ciencias Computacionales

TESIS DE MAESTRÍA EN CIENCIAS

Interoperabilidad de bases de datos basada en la

documentación de los metadatos y ontologías OWL DL

de dominio, utilizando la plataforma D2RQ

presentada por

Edgar Omar Bañuelos Lozoya

Ing. en Sistemas Computacionales en Hardware y Software

por la Universidad Autónoma de Chihuahua

como requisito para la obtención del grado de

Maestro en Ciencias en Ciencias de la Computación

Director de tesis:

Dr. José Antonio Zárate Marceleño

Co-Directora de tesis:

Dra. Azucena Montes Rendón

Cuernavaca, Morelos, México 19 de junio de 2009

cenidet Centro Nacional de Investigación y Desarrollo Tecnológico

Departamento de Ciencias Computacionales

TESIS DE MAESTRÍA EN CIENCIAS

Interoperabilidad de bases de datos basada en la documentación de los metadatos y ontologías OWL DL

de dominio, utilizando la plataforma D2RQ

presentada por

Edgar Omar Bañuelos Lozoya Ing. en Sistemas Computacionales en Hardware y Software

por la Universidad Autónoma de Chihuahua

como requisito para la obtención del grado de Maestro en Ciencias en Ciencias de la Computación

Director de tesis: Dr. José Antonio Zárate Marceleño

Co-Directora de tesis: Dra. Azucena Montes Rendón

Jurado: Dr. Hugo Estrada Esquivel Presidente

M.C. Mario Guillén Rodríguez Secretario M.C. Humberto Hernández García Vocal

Cuernavaca, Morelos, México 19 de junio de 2009

A mi familia.

Ustedes han sido el soporte en el que se han forjado esta y todas mis metas.

Los amo.

Agradecimientos

Al Dios que me acompañe, porque a pesar de las dudas y conflictos siempre me ha ayudado a

redefinir el rumbo y avanzar paso a paso.

A mi familia por su amor incondicional, en particular a mi padre por ese mes que compartimos en

extraordinarias circunstancias.

A mi director de tesis, Dr. Toño Zárate, por su guía, confianza y paciencia. Recordaré aquellas

pláticas en donde la divagación nos llevaba a otros temas no menos interesantes. Espero que

nuestra relación profesional siga dando frutos y le reitero mi amistad y respeto.

A los doctores Azucena Montes y Juan Gabriel González, mi co‐directora y profesor de clase, por

su disposición a ayudarme y las enseñanzas que bien valieron las noches de desvelo.

A mis revisores por su crítica y consejos acertados. Tanto a los maestros Humberto Hernández y

Mario Guillén que me acompañaron durante todo el trayecto, como a los doctores Pazos y Hugo

Estrada que estuvieron al principio y final de este trabajo.

Al Dr. Máximo López por su atención y apoyo constante. Su comprensión permitió que, aunque en

un tiempo no conveniente, este trabajo de tesis tuviera buen término.

A mi novia Perla, por tu cariño inagotable, por permitirme caminar a tu lado en un instante que

continúa.

A mis amigos del rancho, René, Gema y Adrián, porque como ustedes… sólo ustedes, es un honor.

A los que me brindaron su amistad dentro y fuera del Cenidet, en particular a Maty, Eduardo,

Mitto, Richard, Wilfrido, Rafael y Adriana.

A los compañeros que me apoyaron en aquella extraordinaria situación, sería difícil e injusto

nombrarlos uno por uno, sobre todo porque creo que fueron todos.

A todo el personal del centro, especialmente a la Sra. de la cafetería y a Anita, dos personas que

siempre me otorgaron un saludo sincero y que, cada una con su labor, facilitaron mi estancia en

esta institución.

Al CONACYT por el apoyo económico otorgado.

Gracias, Omar B.

Resumen

Los sistemas de información modernos requieren acceder a varias bases de datos para obtener

información que pueda ser relevante en el apoyo a la toma de decisiones, entre otras acciones.

Generalmente estas bases de datos son heterogéneas debido a que fueron diseñadas cumpliendo

ciertos requerimientos de hardware, software y representación de los datos, además su diseño

estuvo sujeto al dominio y experiencia del personal que lo llevó a cabo. Aunque desde hace varios

años se trata el problema de la recuperación de datos en bases de datos heterogéneas, el actual

impulso a la Web Semántica estimula el desarrollo de enfoques de interoperabilidad bajo esta

perspectiva.

Se presenta un enfoque de tres fases para la interoperabilidad de bases de datos. Fases

implementadas a través de las herramientas de software Doc‐D2R, Query‐D2R y D2R Server, las

primeras desarrolladas como parte de la investigación y la última incluida en la plataforma D2RQ.

En primer lugar, Doc‐D2R es utilizado para documentar los metadatos con el apoyo de una

ontología de dominio y para generar archivos de mapeo D2RQ. Esto vincula los elementos de las

bases de datos con conceptos y relaciones del dominio real. Luego, se usan servidores D2R para

publicar y mantener los datos accesibles en la Web vía consultas SPARQL. Por último, Query‐D2R

permite construir y ejecutar consultas SPARQL para acceder a los datos publicados de una o más

bases de datos. En el proceso son minimizados algunos conflictos de interoperabilidad generados

por nombres, unidades de medida y tipos de datos.

Abstract

The modern information systems require access to several databases for obtain information that

can be relevant in decision support, among other things. Generally these databases are

heterogeneous because was designed under certain hardware, software and data representation

requirements, additionally, the design dependent at the ability and experience of the designer.

Although the recuperation of data from heterogeneous databases is a problem in treatment since

several years ago, the actual impulse to Semantic Web stimulates the development of approaches

under this perspective.

A three stage approach for database interoperability is presented. The stages have been

implemented with the software tools Doc‐D2R, Query‐D2R, and D2R server, the first two were

developed how part of the investigation and the last one is part of the D2RQ platform.

First, Doc‐D2R is used in order to document database metadata, supported by domain ontology,

and generate D2RQ mapping files. This action permits that databases elements and real domain

concepts and relations have been related. Then, D2R servers are used to publish and keep data

Web accessible through SPARQL queries. Finally, Query‐D2R allows create and execute SPARQL

queries, accessing public data of one or several databases. In the process are reduced some

interoperability problems generated for names, measure units and datatypes.

i

Contenido

Capítulo 1 - Introducción ..................................................................................................................... 1

1.1. Descripción del problema ................................................................................................... 1

1.2. Propuesta de solución ......................................................................................................... 2

1.2.1. Objetivo ........................................................................................................................... 2

1.2.2. Justificación y beneficios ................................................................................................. 2

1.2.3. Alcances ........................................................................................................................... 3

1.2.4. Limitaciones..................................................................................................................... 3

1.2.5. Metodología de solución ................................................................................................. 4

1.3. Organización del documento .............................................................................................. 5

Capítulo 2 - Marco teórico .................................................................................................................. 7

2.1. Sistema manejador de base de datos ................................................................................. 7

2.2. Sistemas de bases de datos heterogéneas ......................................................................... 7

2.3. Conflictos en la interoperabilidad de bases de datos ......................................................... 9

2.4. Ontologías ......................................................................................................................... 10

2.5. Identificador Uniforme de Recursos ................................................................................. 11

2.6. Web Semántica ................................................................................................................. 11

2.6.1. RDF ................................................................................................................................ 12

2.6.2. SPARQL .......................................................................................................................... 13

2.6.3. OWL ............................................................................................................................... 13

2.7. Metodologías de construcción de ontologías ................................................................... 16

Capítulo 3 - Estado del arte ............................................................................................................... 19

3.1. Marco de trabajo para aprendizaje de ontologías ............................................................ 19

3.2. Ontologías en la integración de bases de datos heterogéneas ........................................ 19

3.3. Enfoques de ingeniería inversa basados en análisis de formularios HTML ...................... 19

3.4. Arquitectura para federación de bases de datos basada en ontologías ........................... 20

3.5. OntoGrate ......................................................................................................................... 20

3.6. Relational.OWL .................................................................................................................. 21

3.7. RDQuery ............................................................................................................................ 21

3.8. DartGrid ............................................................................................................................. 22

3.9. D2RQ Platform .................................................................................................................. 22

3.10. Asio SBRD .......................................................................................................................... 23

3.11. OpenLink Virtuoso ............................................................................................................. 23

3.12. SquirrelRDF ........................................................................................................................ 24

3.13. SPASQL .............................................................................................................................. 24

3.14. Estándar ISO/IEC 11179 ................................................................................................... 24

Contenido

ii

3.15. Tabla comparativa ............................................................................................................. 25

Capítulo 4 - Análisis del problema y diseño de la solución ............................................................... 27

4.1. Fase 1: Documentación ..................................................................................................... 28

4.2. Fase 2: Publicación ............................................................................................................ 31

4.3. Fase 3: Consulta ................................................................................................................ 31

4.4. Análisis previos .................................................................................................................. 34

4.4.1. Bases de datos de prueba ............................................................................................. 34

4.4.2. Características a documentar ........................................................................................ 36

4.4.3. Ontología de dominio .................................................................................................... 38

4.4.3.1. Esquema XML de unidades de medición ...................................................................... 43

Capítulo 5 - Doc-D2R – Software de documentación ........................................................................ 45

5.1. Especificación de requerimientos ..................................................................................... 45

5.1.1. Descripción .................................................................................................................... 45

5.1.2. Usuario .......................................................................................................................... 45

5.1.3. Requerimientos ............................................................................................................. 45

5.1.4. Casos de uso .................................................................................................................. 46

5.2. Análisis y diseño ................................................................................................................ 52

5.2.1. Componentes ................................................................................................................ 52

5.2.2. Diagramas de actividades .............................................................................................. 53

5.2.3. Esquema XML de documento de proyecto ................................................................... 58

5.3. Implementación ................................................................................................................ 62

5.3.1. Entorno de desarrollo ................................................................................................... 62

5.3.2. Clases ............................................................................................................................. 63

5.3.3. Formularios ................................................................................................................... 67

5.4. Pruebas .............................................................................................................................. 70

5.4.1. Plan de pruebas ............................................................................................................. 70

5.4.2. Especificación de casos de prueba y resultados ........................................................... 72

5.4.2.1. Caso de prueba 01: Carga de metadatos ...................................................................... 72

5.4.2.2. Caso de prueba 02: Carga de ontología y archivo de medición .................................... 75

5.4.2.3. Caso de prueba 03: Documentación de metadatos ...................................................... 78

5.4.2.4. Caso de prueba 04: Presentación del reporte de documentación ............................... 82

5.4.2.5. Caso de prueba 05: Generación de mapeo D2RQ ......................................................... 83

5.4.2.6. Caso de prueba 06: Generación de archivo de proyecto .............................................. 88

Capítulo 6 - Query-D2R – Software de consulta ............................................................................... 91

6.1. Especificación de requerimientos ..................................................................................... 91

6.1.1. Descripción .................................................................................................................... 91

6.1.2. Usuarios ......................................................................................................................... 91

6.1.3. Requerimientos ............................................................................................................. 91

6.1.4. Casos de uso .................................................................................................................. 92

6.2. Análisis y diseño ................................................................................................................ 97

Contenido

iii

6.2.1. Componentes ................................................................................................................ 97

6.2.2. Diagramas de actividades .............................................................................................. 97

6.3. Implementación .............................................................................................................. 104

6.3.1. Entorno de desarrollo ................................................................................................. 104

6.3.2. Clases ........................................................................................................................... 104

6.3.3. Formularios ................................................................................................................. 108

6.4. Pruebas ............................................................................................................................ 110

6.4.1. Plan de pruebas ........................................................................................................... 110

6.4.2. Especificación de casos de prueba y resultados ......................................................... 111

6.4.2.1. Caso de prueba 01 ....................................................................................................... 111

6.4.2.2. Caso de prueba 02 ....................................................................................................... 114

6.4.2.3. Caso de prueba 03 ....................................................................................................... 116

6.4.2.4. Caso de prueba 04 ....................................................................................................... 118

6.4.2.5. Caso de prueba 05 ....................................................................................................... 120

6.4.2.6. Caso de prueba 06 ....................................................................................................... 123

6.4.2.7. Caso de prueba 07 ....................................................................................................... 125

Capítulo 7 - Conclusiones y trabajos futuros .................................................................................. 131

7.1. Conclusiones.................................................................................................................... 131

7.2. Aportaciones ................................................................................................................... 132

7.3. Trabajos futuros .............................................................................................................. 133

Anexo A - Diagramas de bases de datos de prueba ........................................................................ 135

Referencias ...................................................................................................................................... 139

Lista de figuras Figura 1.1. Modelo de caja negra de la herramienta de generación de ontologías. .......................... 4

Figura 2.1. Sistema de bases de datos distribuidas ............................................................................ 8

Figura 2.2. Sistema de bases de datos federadas. .............................................................................. 9

Figura 2.3. Modelo de capas de la Web Semántica .......................................................................... 11

Figura 4.1. Actividades de la propuesta de solución y software relacionado ................................... 28

Figura 4.2. Actividades de la fase de documentación ....................................................................... 29

Figura 4.3. Actividad en la fase de publicación ................................................................................. 32

Figura 4.4. Actividades en la fase de consulta .................................................................................. 32

Figura 4.5. Jerarquía de clases de la ontología ontDom ................................................................... 40

Figura 4.6. Resumen de las propiedades y las restricciones de propiedades de la ontología ontDom

........................................................................................................................................................... 41

Figura 4.7. Estructura del esquema XSD de unidades de medición .................................................. 43

Figura 5.1. Diagrama de casos de uso de Doc-D2R ........................................................................... 47

Figura 5.2. Diagrama de componentes de Doc-D2R ......................................................................... 53

Contenido

iv

Figura 5.3. Diagrama de actividades de cu1_configurarProyecto .................................................... 53

Figura 5.4. Diagrama de actividades de cu2_documentar ................................................................ 54

Figura 5.5. Diagrama de actividades de cu2.1_escogerAliasTabla .................................................... 55

Figura 5.6. Diagrama de actividades de cu2.2_escogerAliasColumna .............................................. 55

Figura 5.7. Diagrama de actividades de cu2.3_escogerUnidadMedida ............................................ 56

Figura 5.8. Diagrama de actividades de cu3_generarReporte .......................................................... 56

Figura 5.9. Diagrama de actividades de cu4_generarMapeoD2RQ .................................................. 57

Figura 5.10. Diagrama de actividades de cu5_guardarProyecto ...................................................... 57

Figura 5.11. Diagrama de actividades de cu6_abrirProyecto ........................................................... 58

Figura 5.12. Estructura general del esquema XSD de documento de proyecto ............................... 58

Figura 5.13. Elemento conexión del esquema XSD de documento de proyecto .............................. 59

Figura 5.14. Elemento baseDatos del esquema XSD de documento de proyecto ............................ 60

Figura 5.15. Elemento tabla del esquema XSD de documento de proyecto .................................... 61

Figura 5.16. Elemento columna del esquema XSD de documento de proyecto ............................... 61

Figura 5.17. Elemento equivalenciaValor del esquema XSD de documento de proyecto ................ 62

Figura 5.18. Elemento FK del esquema XSD de documento de proyecto ......................................... 62

Figura 5.19. Estructura de paquetes de Doc-D2R ............................................................................. 63

Figura 5.20. Clase ConexionBD .......................................................................................................... 63

Figura 5.21. Diagrama de clases de Doc-D2R .................................................................................... 63

Figura 5.22. Clase BaseDatos ............................................................................................................ 65

Figura 5.23. Clase Ontologia.............................................................................................................. 65

Figura 5.24. Clase UnidadMedida ..................................................................................................... 65

Figura 5.25. Clase GeneradorMapeo ................................................................................................ 65

Figura 5.26. Clase ProyectoDocBD .................................................................................................... 66

Figura 5.27. Formulario principal ...................................................................................................... 67

Figura 5.28. Formulario de propiedades de un proyecto nuevo o existente .................................... 68

Figura 5.29. Formulario para definir propiedades de mapeo ........................................................... 68

Figura 5.30. Formulario para escoger alias de tabla o de columna .................................................. 69

Figura 5.31. Formulario para escoger unidad de medida ................................................................. 69

Figura 5.32. (DOCBD_CP-01) Prueba de conexión con cadena de conexión incorrecta y recepción

de mensaje de error .......................................................................................................................... 73

Figura 5.33. (DOCBD_CP-01) Conexión exitosa, carga del árbol y de la pestaña de detalle de base

de datos ............................................................................................................................................. 74

Figura 5.34. (DOCBD_CP-01) Selección de nodo de tabla alumno, carga de la pestaña de detalle de

tabla................................................................................................................................................... 74

Figura 5.35. (DOCBD_CP-01) Selección de nodo de columna alumno.Matricula, carga de pestaña de

detalle de columna ............................................................................................................................ 75

Figura 5.36. (DOCBD_CP-02) Mensaje de aviso de ontología no definida ........................................ 77

Figura 5.37. (DOCBD_CP-02) Mensaje de error de carga de ontología al dar una URL inexistente . 77

Figura 5.38. (DOCBD_CP-02) Verificación de la apertura del formulario y la carga de las clases,

propiedades y descripciones ............................................................................................................. 77

Contenido

v

Figura 5.39. (DOCBD_CP-02) Verificación de la apertura del formulario y la carga de sistemas,

magnitudes y unidades ..................................................................................................................... 78

Figura 5.40. (DOCBD_CP-03) Actualización del alias y descripción de la tabla alumno .................... 80

Figura 5.41. (DOCBD_CP-03)Actualización del alias y descripción de alumno.Sexo y la carga de los

valores de equivalencia ..................................................................................................................... 80

Figura 5.42. (DOCBD_CP-03) Mensaje de estado de publicación de columna llave no puede ser

modificado ........................................................................................................................................ 81

Figura 5.43. (DOCBD_CP-03) Actualización del alias y descripción de tabla Materia ....................... 81

Figura 5.44. (DOCBD_CP-04) Reporte de documentación abierto en navegador Web .................... 82

Figura 5.45. (DOCBD_CP-05) Mensaje de generación exitosa .......................................................... 84

Figura 5.46. (DOCBD_CP-05) Definición de cabecera ....................................................................... 84

Figura 5.47. (DOCBD_CP-05) Definición de mapeo de base de datos .............................................. 84

Figura 5.48. (DOCBD_CP-05) Definición de clase alumno y de propiedades adicionales ................. 85

Figura 5.49. (DOCBD_CP-05) Definición de propiedades y condición de publicación y tabla de

transformación para “alumno_tienesexo” ....................................................................................... 85

Figura 5.50. (DOCBD_CP-05) Definición de propiedades de clase alumno inferidas de la ontología85

Figura 5.51. (DOCBD_CP-05) Definición de clase materia y de propiedades adicionales ................. 86

Figura 5.52. (DOCBD_CP-05) Definición de propiedades de clase materia ...................................... 86

Figura 5.53. (DOCBD_CP-05) Ejecución de servidor D2R con el mapeo generado ........................... 87

Figura 5.54. (DOCBD_CP-05) Navegación Web de la base de datos publicada ................................ 87

Figura 5.55. (DOCBD_CP-06) Verificación del título del formulario con el nombre del archivo ....... 89

Figura 5.56. (DOCBD_CP-06) Mensaje de advertencia de perder cambios sin guardar ................... 89

Figura 5.57. (DOCBD_CP-06) Verificación del cierre del proyecto .................................................... 89

Figura 5.58. (DOCBD_CP-06) Verificación de carga de datos de columna alumno.Sexo .................. 90

Figura 6.1. Diagrama de casos de uso de Query-D2R ....................................................................... 93

Figura 6.2. Diagrama de componentes de Query-D2R ..................................................................... 98

Figura 6.3. Diagrama de actividades de cu1_configurar ................................................................... 98

Figura 6.4. Diagrama de actividades de cu2_construirConsulta ....................................................... 99

Figura 6.5. Diagrama de actividades de cu2.1_establecerFiltroTexto ............................................ 100

Figura 6.6. Diagrama de actividades de cu2.2_establecerFiltroLista .............................................. 100

Figura 6.7. Diagrama de actividades de cu2.1_establecerFiltroNumerico ..................................... 101

Figura 6.8. Diagrama de actividades de cu3_ejecutarConsulta ...................................................... 102

Figura 6.9. Diagrama de actividades de cu3.2_presentarResultados ............................................. 102

Figura 6.10. Diagrama de actividades de cu3.1_transformarConsulta ........................................... 103

Figura 6.11. Clase ServidorD2R ....................................................................................................... 104

Figura 6.12. Diagrama de clases de Query-D2R .............................................................................. 105

Figura 6.13. Clase Sujeto ................................................................................................................. 106

Figura 6.14. Clase Predicado ........................................................................................................... 106

Figura 6.15. Clase Consulta ............................................................................................................. 106

Figura 6.16. Clase CreadorSPARQL .................................................................................................. 106

Figura 6.17. Clase Subconsulta ........................................................................................................ 107

Figura 6.18. Clase FiltroLiteral ......................................................................................................... 107

Contenido

vi

Figura 6.19. Clase EjecutorSPARQL ................................................................................................. 108

Figura 6.20. Clase frmPresentadorD2R ........................................................................................... 108

Figura 6.21. Formulario principal de Query-D2R ............................................................................ 108

Figura 6.22. Formulario filtro de valor de texto .............................................................................. 109

Figura 6.23. Formulario filtro por listado de valores ...................................................................... 109

Figura 6.24. Formulario filtro de valor numérico ............................................................................ 109

Figura 6.25. Formulario de resultados ............................................................................................ 109

Figura 6.26. (QUERYD2R_CP-01) Configuración de ontología, servidores y consulta .................... 113

Figura 6.27. (QUERYD2R_CP-01) Consulta SPARQL generada para servidor1 ................................ 113

Figura 6.28. (QUERYD2R_CP-01) Resultados .................................................................................. 114

Figura 6.29. (QUERYD2R_CP-02) Resumen de consulta.................................................................. 115

Figura 6.30. (QUERYD2R_CP-02) Elección de variable de resultado ............................................... 115








Figura 6.38. (QUERYD2R_CP-04) Consulta SPARQL generada para servidor2, se observa la

conversión del parámetro ............................................................................................................... 120



Figura 6.41. (QUERYD2R_CP-05) Consulta SPARQL generada para servidor1, se observa la

conversión del parámetro ............................................................................................................... 122






Figura 6.47. (QUERYD2R_CP-07) Resumen de consulta1................................................................ 126

Figura 6.48. (QUERYD2R_CP-07) Consulta1 SPARQL generada para servidor1 .............................. 127

Figura 6.49. (QUERYD2R_CP-07) Resultados de consulta1 ............................................................. 127

Figura 6.50. (QUERYD2R_CP-07) Vista detalle en navegador Web de primer resultado de consulta1

......................................................................................................................................................... 127








Contenido

vii



Figura A.1. Diagrama de base de datos SiCEWin............................................................................ 135

Figura A.2. Diagrama de base de datos Prepa ................................................................................ 136

Figura A.3. Diagrama de base de datos genWeb ............................................................................ 137

Figura A.4. Diagrama de base de datos de sicewin_cut .................................................................. 138

Lista de tablas Tabla 2.1. Ejemplos de sinonimia en bases de datos ........................................................................ 10

Tabla 2.2. Ejemplo de un conflicto de escala y representación ........................................................ 10

Tabla 3.1. Comparación de algunos trabajos del estado del arte y el proyecto de tesis .................. 26

Tabla 4.1. Agrupación de tipos de datos ........................................................................................... 33

Tabla 4.2. Características originales de las bases de datos de prueba ............................................. 35

Tabla 4.3. Características finales de las bases de datos de prueba .................................................. 36

Tabla 4.4. Características de SMBD y resumen ................................................................................. 36

Tabla 4.5. Características de tabla .................................................................................................... 37

Tabla 4.6. Características de columna ............................................................................................... 37

Tabla 4.7. Reglas de creación de alias de tablas y columnas ............................................................ 38

Tabla 4.8. Reglas de nombrado en ontologías .................................................................................. 42

Tabla 5.1. Descripción de cu1_configurarProyecto .......................................................................... 47

Tabla 5.2. Descripción de cu2_documentar ...................................................................................... 48

Tabla 5.3. Descripción de cu2.1_escogerAliasTabla .......................................................................... 49

Tabla 5.4. Descripción de cu2.2_escogerAliasColumna .................................................................... 49

Tabla 5.5. Descripción de cu2.3_escogerUnidadMedida .................................................................. 50

Tabla 5.6. Descripción de cu3_generarReporte ................................................................................ 50

Tabla 5.7. Descripción de cu4_generarMapeoD2RQ ........................................................................ 51

Tabla 5.8. Descripción de cu5_guardarProyecto .............................................................................. 51

Tabla 5.9. Descripción de cu6_abrirProyecto ................................................................................... 52

Tabla 5.10. Características de escenario de prueba.......................................................................... 71

Tabla 5.11. Entradas para el caso de prueba 01 ............................................................................... 72

Tabla 5.12. Salidas para el caso de prueba 01 .................................................................................. 72











Contenido

viii

Tabla 6.1. Descripción de cu1_configurar ......................................................................................... 93

Tabla 6.2. Descripción de cu2_construirConsulta ............................................................................. 94

Tabla 6.3. Descripción de cu2.1_establecerFiltroTexto .................................................................... 94

Tabla 6.4. Descripción de cu2.2_establecerFiltroLista ...................................................................... 95

Tabla 6.5. Descripción de cu2.3_establecerFiltroNumerico ............................................................. 95

Tabla 6.6. Descripción de cu3_ejecutarConsulta .............................................................................. 95

Tabla 6.7. Descripción de cu3.1_transformarConsulta ..................................................................... 96

Tabla 6.8. Descripción de cu3.2_presentarResultados ..................................................................... 96

Tabla 6.9. Características de escenario de prueba.......................................................................... 111

1

1. Capítulo 1

Introducción

En la Web actual existe una gran cantidad de datos que se almacenan en bases de datos

relacionales (constituyen la denominada Web Profunda) y no son públicos y abiertos para ser

referenciados [1]. Las organizaciones privadas y públicas pueden beneficiarse de hacer disponibles

sus datos en formatos legibles por máquinas, tales datos son más valiosos si son accesibles

fácilmente y pueden ser reutilizados para integrarse con otros datos [2].

En el contexto de bases de datos, una ontología permite definir conceptos, atributos y relaciones

con una mayor abstracción e independencia a los modelos de datos de los niveles lógico o físico.

Herramientas de generación semiautomática de ontologías de bases de datos minimizan la

intervención humana y permiten reflejar cambios en los esquemas de manera transparente. En

trabajos como SquirrelRDF, Relational.OWL, D2RQ Platform, entre otros, se generan ontologías de

bases de datos con base en el análisis del diccionario de datos y siguiendo las observaciones de

Berners- Lee en cuanto a la definición de datos enlazados y la publicación de bases de datos en la

Web, sin embargo no añaden semántica que vincule los conceptos y relaciones con el dominio

real.

En esta tesis se presenta el software Doc-D2R como una herramienta para documentar bases de

datos con el apoyo de una ontología de dominio, permitiendo detallar escalas, valores permitidos,

tipos de datos, entre otros. Doc-D2R también funge como remplazo del script generate-mapping,

incluido en la plataforma D2RQ, para generar mapeos empleando los esquemas documentados.

Estos mapeos son utilizados por servidores D2R para habilitar la navegación vía Web entre los

datos y la consulta a través del protocolo SPARQL.

Por último se presenta Query-D2R, herramienta de consulta que configura su interfaz auxiliándose

de los datos publicados y permite construir y gestionar la ejecución de consultas SPARQL en los

servidores minimizando algunos conflictos de interoperabilidad.

1.1. Descripción del problema

Un sistema de recuperación de datos en bases de datos heterogéneas tiene como principal

objetivo presentar la información que el usuario gestiona de manera transparente,

independientemente de las fuentes donde se extraiga. Esto implica amortiguar las diferencias en

Capítulo 1 - Introducción

2

software, hardware y representación de la información de las bases de datos involucradas,

además de utilizar una herramienta de búsqueda común.

Por otro lado, el diseño del esquema de una base de datos está ligado al dominio, experiencia y en

ocasiones conveniencia del propio diseñador. En nuestro país es una práctica común que en

entornos no profesionales de desarrollo de software, el programador sea a la vez el diseñador de

la base de datos, dando como resultado bases de datos sumamente acopladas a la aplicación que

las utiliza.

Debido a lo anterior, es necesario plantear alternativas apegadas al impulso actual de la Web

Semántica que nos permitan pasar del esquema de la base de datos, el cual es semánticamente

incompleto, a un esquema con una mayor descripción semántica, como una ontología, que sea

más entendible para humanos y agentes de software con la finalidad de facilitar la

interoperabilidad de bases de datos.

1.2. Propuesta de solución

En esta sección se describen desde los objetivos hasta la metodología que se siguió en el

desarrollo de esta investigación.

1.2.1. Objetivo

En el contexto de la Web Semántica, el objetivo principal fue desarrollar una herramienta que

permita la generación semiautomática de ontologías, a partir de esquemas de bases de datos

relacionales heterogéneas, que puedan ser empleadas para la recuperación de datos.

Se tuvieron como objetivos particulares, ordenados de mayor a menor prioridad, los siguientes:

Desarrollar una metodología de documentación de metadatos en esquemas de bases de

datos relacionales para facilitar la traducción de dichos esquemas a ontologías.

Diseñar e implementar una herramienta semiautomática de generación de ontologías

basada en esquemas de bases de datos relacionales tratados con la técnica de

documentación propuesta.

Diseñar e implementar una herramienta enfocada a la recuperación de datos que utilice

las ontologías generadas.

1.2.2. Justificación y beneficios

Habitualmente una organización tradicional tiene en funcionamiento varias bases de datos

trabajando de manera autónoma vinculadas a diversas áreas de la administración como recursos

humanos, financieros, producción, etc. Un sistema de información que permita relacionar y

recuperar datos que están en dichas bases de datos, que por su naturaleza de diseño e

implementación generalmente son heterogéneas, puede, entre otras cosas, auxiliar en la toma de

decisiones y contribuir a la mejora de la eficiencia administrativa.


3

En un escenario entre organizaciones la necesidad de compartir información también está

presente; un ejemplo se da en las entidades gubernamentales, en donde se tienen sistemas de

información a niveles de gobierno municipal, estatal y federal que pueden ser más eficientes si son

interoperables existiendo un medio y un acuerdo para compartir datos de manera directa.

El trabajo descrito en este documento permite a los administradores de base de datos

documentar los metadatos de esquemas de base de datos auxiliándose de una ontología de

dominio. El uso de la ontología permite estandarizar el nombrado de tablas y columnas e inferir

relaciones entre las tablas con base en el análisis de las propiedades de la ontología y las llaves

foráneas de la base de datos. Esta información, visible una vez que se publican las bases de datos

en la Web, permite llevar a cabo un proceso de interoperabilidad semiautomática.

Las bases de datos publicadas son vistas como una ontología o un conjunto de tripletas RDF, pero

¿por qué ontologías? El uso de ontologías, como propone Berners-Lee para la Web Semántica [3],

permitirá en un futuro cercano que agentes inteligentes puedan interpretar y buscar, de diversas

fuentes y en forma más precisa, información que responda peticiones de humanos u otros

agentes.

Aunque la arquitectura de prueba desarrollada en este trabajo permite recuperar datos de bases

de datos dirimiendo algunos problemas de heterogeneidad, el mayor beneficio se identifica en

que forma parte del incipiente trabajo de la Web Semántica para incorporar con un mayor

significado las bases de datos a la Web, y sirve de base, como primer acercamiento, para futuros

proyectos relacionados con este tema en nuestra institución.

1.2.3. Alcances

Se especificaron los siguientes alcances:

Desarrollo de una metodología de documentación de metadatos de esquemas de bases de

datos.

Desarrollo de una herramienta de software que genere de manera semiautomática una

ontología para cada uno de los esquemas documentados.

Implementación de una herramienta que haga uso de las ontologías para recuperar datos

de las bases de datos minimizando algunos problemas de heterogeneidad.

1.2.4. Limitaciones

Teniendo como limitantes las siguientes:

Sólo aplica con Sistemas Manejadores de Bases de Datos relacionales con controlador

JDBC disponible.

Sólo se abordaron problemas de heterogeneidad relacionados con nombres, sinonimia y

homonimia, unidades de medida y tipos de datos.

Se consideró un escenario de prueba para cada herramienta. Se ajustaron y usaron tres

bases de datos considerando se presentaran los problemas de heterogeneidad a resolver,


4

dos de ellas habían estado en operación y una fue diseñada por personal con experiencia

laboral en el ramo.

La interfaz de recuperación de datos es acotada, sólo muestra términos de navegación de

acuerdo a la documentación y la ontología, permitiendo que se especifique o se filtre la

búsqueda a través de parámetros restringidos.

No se consideraron aspectos relacionados con seguridad y autenticación de usuarios.

Sólo se permiten consultas de recuperación de datos. No se contemplan la inserción,

eliminación y actualización de datos.

1.2.5. Metodología de solución

La metodología de solución fue la siguiente:

1) Análisis de información relacionada con los siguientes tópicos: documentación de bases de

datos en operación, conformación de metadatos en sistemas manejadores de bases de

datos relacionales, estándares de metadatos existentes y lenguajes para la creación de

ontologías; con la finalidad de diseñar una técnica de documentación de metadatos, ya sea

de forma interna (si lo permite el SMBD) o externa (ejemplo: archivo XML), que le dé una

mayor descripción semántica a los metadatos de la base de datos.

2) Diseño e implementación de una herramienta computacional (Figura 1.1) que reciba como

entrada la definición del esquema de la base de datos (ya tratado con la técnica de

documentación), de tal forma que tenga como resultado una ontología que represente al

esquema relacional de la base de datos con una mayor descripción semántica.

Figura 1.1. Modelo de caja negra de la herramienta de generación de ontologías.

3) Diseño e implementación de una herramienta que permita recuperar datos con base en la

navegación en ontologías y con campos de texto libre, similar a lo propuesto por Brisaboa

[4], para buscar ejemplares directamente; también debe realizar la traducción de las

consultas a lenguaje SQL, el proceso de gestión con los SMBD´s involucrados y el

despliegue de los resultados obtenidos. El diseño de la interfaz puede considerar el uso de

tripletas, especificando relaciones entre uno o más conceptos de acuerdo a las relaciones

establecidas en la propia ontología.

4) Probar las herramientas acordé a los escenarios definidos en las fases de diseño.

Esquema de base de datos

+

Documentación de metadatos

Ontología de

base de datos


5

1.3. Organización del documento

La tesis se estructura de la siguiente forma:

Capítulo 1, Introducción.

Presenta al lector la problemática a resolver y describe la metodología de solución

propuesta.

Capítulo 2, Marco teórico.

Incluye las definiciones que sitúan en el contexto del trabajo desarrollado.

Capítulo 3, Estado del arte.

Muestra los trabajos de investigación relacionados, comparándolos en torno a lo

planteado en este documento.

Capítulo 4, Análisis del problema y diseño de la solución.

Describe las fases de solución, incluyendo la descripción del papel que toman las

herramientas de software desarrolladas.

Capítulo 5, Doc-D2R.

Presenta un resumen del proceso de desarrollo de la herramienta de documentación Doc-

D2R, primer producto de software de esta tesis.

Capítulo 6, Query-D2R.

Presenta un resumen del proceso de desarrollo del software de consulta Query-D2R.

Capítulo 7, Conclusiones.

Detalla las observaciones realizadas, las conclusiones finales y aportaciones, además,

incluye la descripción de los trabajos que podrían continuar a partir de esta investigación.

6

7

2. Capítulo 2

Marco teórico

2.1. Sistema manejador de base de datos

“Un sistema manejador de bases de datos (SMBD o DBMS por sus siglas en inglés) consiste

en una colección de datos inter-relacionados y un conjunto de programas para acceder a

dichos datos. La colección de datos, normalmente denominada base de datos, contiene

información relevante para una empresa. El objetivo principal de un SMBD es proporcionar

una forma de almacenar y recuperar la información de una base de datos de manera que

sea tanto práctica como eficiente” [5].

2.2. Sistemas de bases de datos heterogéneas

Fileto y Medeiros [6] dan una definición de estos sistemas y varias consideraciones a destacar. Los

sistemas de bases de datos heterogéneas (SBDH) son herramientas de software que integran

varios sistemas de bases de datos preexistentes comúnmente llamados componentes, en donde el

mismo componente puede participar en varios SBDH’s y los componentes pueden ser

desarrollados independientemente y sin considerar una integración subsecuente. Los SBDH’s

pueden ser caracterizados usando tres conceptos clave: heterogeneidad, distribución y

autonomía.

La heterogeneidad de un SBDH depende del tipo y número de discrepancias entre las bases de

datos que lo constituyen, con respecto a sus esquemas, modelos de datos, lenguajes de consulta,

capacidad de administración de transacciones, SMBD, hardware y sistemas operativos. Las

discrepancias pueden aparecer en cualquier nivel de abstracción (instancias de datos, esquema,

modelo de datos). La heterogeneidad puede ser reflejada en la representación de los datos o en su

manera de interpretarlos. Por distribución se refiere a la localización de los componentes del

SBDH. En principio, la distribución es ortogonal a la heterogeneidad. Un sistema distribuido puede

involucrar diferentes plataformas de hardware, software y de comunicación. La autonomía se

refiere a la libertad de los componentes del SBDH para definir y administrar sus bases de datos. La

autonomía y la demanda de compartir datos son requerimientos que pueden entrar en conflicto.

Para garantizar la autonomía, un SBDH debe mantener la capacidad de cada base de datos para

administrar sus datos sin la intervención del administrador general.

Capítulo 2 – Marco teórico

8

Existen varias opciones para la implementación de SBDHs, con variaciones en el grado de

acoplamiento entre los componentes de base de datos y ofreciendo diferentes compromisos entre

cooperación y autonomía. Estos sistemas se clasifican en:

Sistema de bases de datos distribuidas (SBDD), consiste en una sencilla base de datos

lógica que es distribuida físicamente. A pesar de la fragmentación física de los datos, un

SBDD soporta un modelo de datos y lenguaje de consulta sencillos, con un esquema

integrando todo lo que el SBDD contiene.

Sistema de bases de datos federadas (SBDF), es un sistema de bases de datos distribuidas

que permite componentes heterogéneos con diferentes modelos de datos, lenguajes de

consulta y esquemas.

Sistema multibases de datos (SMBD), es una colección de bases de datos débilmente

acopladas. Las propiedades clave de un SMBD son la autonomía de las bases de datos

participantes y la ausencia de un esquema global integrado.

Se menciona que el enfoque para permitir el acceso integrado a múltiples bases de datos físicas

puede ser clasificado en dos categorías principales: integración de esquema y el federado. El

primero consiste en proveer un esquema unificado a través del cual los usuarios accedan a los

datos integrados. El segundo, por otro lado, provee algunos medios para acceder a vistas

exportadas de las bases de datos heterogéneas, dejando mucho de la responsabilidad de la

integración de los datos a los diseñadores. En el sistema distribuido (Figura 2.1), el esquema de

cada base de datos distribuida es una vista del esquema unificado. Por otro lado, en el sistema

federado (Figura 2.2) el mecanismo de exportación/importación de los esquemas de las bases de

datos es manejado externamente. La integración de esquemas hace transparente la

heterogeneidad de los datos a los usuarios, mientras que el enfoque federado concede más

autonomía a las bases de datos componentes.

Figura 2.1. Sistema de bases de datos distribuidas


9

Figura 2.2. Sistema de bases de datos federadas.

2.3. Conflictos en la interoperabilidad de bases de datos

De acuerdo con Zisman y Kramer [7], el éxito en la interoperabilidad de bases de datos depende

de la captura y entendimiento de la semántica de las bases de datos. Esto implica identificar las

relaciones semánticas que existen entre las representaciones de un mismo concepto en diferentes

esquemas. Estas relaciones se clasifican en: a) idénticas, cuando las representaciones son

exactamente iguales; b) equivalentes, cuando no son exactamente iguales, pero es posible utilizar

algún mapeo o transformación para equipararlas; c) compatibles, cuando las representaciones no

son idénticas ni equivalentes, pero las construcciones y restricciones de integridad no son

contradictorias; e d) incompatibles, cuando las representaciones son contradictorias. Las

relaciones semánticas equivalentes, compatibles e incompatibles definen conflictos.

El proyecto de tesis busca minimizar conflictos de nombre, escala y representación de acuerdo a lo

siguiente:

1) Nombre. Involucra homónimos, cuando dos elementos tienen los mismos nombres pero

diferentes significados, y sinónimos, cuando dos elementos tienen diferentes nombres

pero el mismo significado. La Tabla 2.1 muestra ejemplos de sinonimia en tres bases de

datos diferentes. En el caso 1 se observa además un conflicto de abstracción, esto se debe

a que en las bases de datos BD1 y BD2 el concepto “alumno” o “estudiante” se relaciona

con una tabla y en BD3 el concepto se vincula con un campo que representa al “nombre

completo de un alumno” autor de una tesis. Los conflictos de abstracción no están

cubiertos dentro del alcance de la tesis.


10

Tabla 2.1. Ejemplos de sinonimia en bases de datos

BD1 BD2 BD3

1 Estudiante → alumno → tesis.alumno

2 Maestro → profesor → investigador

3 Materia → materia → cursos

2) Escala. Involucra el uso de diferentes unidades de medición. La Tabla 2.2 muestra un

ejemplo de conflicto de escala en las bases de datos BD1 y BD2.

Tabla 2.2. Ejemplo de un conflicto de escala y representación

BD1 BD2

calificacion.calificacion

Definido en valores de 0-10

Tipo flotante

→ inscripcion.calificacion

Definido en valores de 0-100

Tipo entero

3) Representación. Cuando dos elementos equivalentes son representados con diferentes

tipos de datos. El ejemplo de la Tabla 2.2 también presenta un conflicto de representación

debido a que divergen en el tipo de datos.

2.4. Ontologías

En 1993, Gruber definió una ontología como una “especificación explícita de una

conceptualización" [8], en donde:

Una ontología define (especifica) los conceptos, relaciones y otras distinciones relevantes

para modelar un dominio.

La especificación adopta la forma de las definiciones del vocabulario de representación

(clases, relaciones, atributos, etc.) que proporcionan significados para el vocabulario y las

restricciones formales en su uso coherente.

También de Gruber, la definición actualizada de ontología es la siguiente [9]:

“En el contexto de las ciencias computacionales y de la información, una ontología define

una serie de primitivas de representación con las cuales se modela un dominio de

conocimiento o discurso. Las primitivas de representación son típicamente clases (o

conjuntos), atributos (o propiedades) y relaciones (o relaciones entre los miembros de

clase). En el contexto de sistemas de bases de datos, una ontología puede ser vista como

un nivel de abstracción de modelos de datos, análogo a los modelos jerárquico y relacional,

pero dirigido a modelar conocimiento acerca de individuos, sus atributos y sus relaciones

con otros individuos.”

Debido a la expresividad de los lenguajes en que son definidas, las ontologías son modelos de

datos en el nivel “semántico”, a diferencia del nivel “lógico” o “físico” en que se sitúan los

esquemas de bases de datos. Existen otras definiciones aceptadas [10] [11], para fines de este

proyecto tomaremos la versión actualizada de Gruber en el contexto de sistemas de bases de

datos.


11

2.5. Identificador Uniforme de Recursos

Una referencia URI1, acrónimo en inglés de Uniform Resource Identifier, es un identificador único

que permite la localización de un recurso para ser accedido en la Web. Se trata del URL

(descripción de la ubicación) más el URN (descripción del espacio de nombre).

2.6. Web Semántica

La definición propuesta por Berners-Lee (inventor de la World Wide Web y director del W3C2) y

otros es:

“La Web Semántica es una extensión de la Web actual, en la cual la información tiene un

significado bien definido, permitiendo una mejor colaboración entre computadoras y seres

humanos para trabajar en cooperación” [3].

La parte medular de la arquitectura actual de la Web Semántica es [12]:

Un modelo de datos (Resource Description Framework (RDF)).

Una variedad de formatos de intercambio de datos (RDF/XML, N3, Turtle, N-Triples, etc.).

Notaciones para descripción formal de ontologías o vocabularios, es decir los conceptos,

términos y relaciones dentro de un determinado dominio (RDF Schema (RDFS) y Web

Ontology Languaje (OWL))

Un mecanismo de consulta (SPARQL) para expresar consultas a través de fuentes de datos

diversas donde los datos son almacenados nativamente en RDF o vistos como RDF vía un

middleware [13].

La Figura 2.3 muestra el modelo de capas propuesto para la Web Semántica.

Figura 2.3. Modelo de capas de la Web Semántica

1 Fuente: http://www.hipertexto.info/index.htm 2 World Wide Web Consortium, más información en http://www.w3.org/


12

Incluidas en el modelo de capas, las principales recomendaciones de la W3C son las siguientes

[14]:

XML. Proporciona una sintaxis superficial para documentos estructurados, pero no impone

restricciones semánticas en el significado de estos documentos.

XML Schema. Es un lenguaje para restringir la estructura de documentos XML, extiende

XML con tipos de datos.

RDF. Es un modelo de datos para objetos (“recursos”) y relaciones entre ellos, proporciona

una semántica simple y puede ser expresado en sintaxis XML.

RDF Schema. Es un vocabulario para describir propiedades y clases de recursos RDF,

contiene una semántica para generalizar y jerarquizar propiedades y clases.

OWL. Adiciona más vocabulario para describir propiedades y clases, entre otros,

relaciones entre clases, cardinalidad, equivalencia, características de propiedades y clases

enumeradas.

Acorde con [15], los mecanismos esenciales de la Web Semántica son RDF, SPARQL y OWL.

2.6.1. RDF

Definido en [16], el marco de trabajo para descripción de recursos (RDF) tiene como objeto

representar información en la Web con base en un simple modelo de datos basado en grafos. RDF

se basa en la idea de referenciar cosas utilizando identificadores Web (URIs) [17].

La estructura de las expresiones está basada en tripletas, donde un conjunto de tripletas es

llamado grafo RDF. Cada tripleta representa una relación entre dos nodos y se compone de:

1) Sujeto. Es una referencia URI o un nodo en blanco.

2) Predicado. Es una referencia URI.

3) Objeto. Es una referencia URI, una literal o un nodo en blanco.

Una referencia URI o literal utilizada como nodo identifica lo que el nodo representa. Una

referencia URI utilizada como predicado identifica una relación entre las cosas representadas por

los nodos que conecta.

Una literal es una cadena de caracteres con una forma léxica definida (estándar Unicode3). Una

literal plana opcionalmente tiene una etiqueta de lenguaje y está normalizada a minúsculas. Una

literal de tipo tiene definido una URI de tipo de datos, por ejemplo:

http://www.w3.org/2001/XMLSchema#int.

Un nodo en blanco es un nodo que no es una referencia URI o una literal, es un nodo único que

puede ser usado en una o más declaraciones RDF pero que no tiene un nombre intrínseco.

3 Más información del estándar Unicode en: http://www.unicode.org/unicode/reports/tr15/#Specification


13

2.6.2. SPARQL

SPARQL, del acrónimo recursivo SPARQL Protocol and RDF Query Language, se conforma de tres

especificaciones:

1) SPARQL Query Languaje [13]. Define la sintaxis y semántica del lenguaje de consultas para

RDF. El lenguaje de consultas SPARQL utiliza IRIs (subconjunto de las referencias URI RDF

que omite espacios). La mayoría de las consultas se definen en base a un conjunto de

patrones de tripletas denominado patrón de grafo básico. Los patrones de tripletas son

similares a las tripletas RDF con excepción de que cualquiera de sus términos puede ser

una variable. Su funcionamiento consiste en tratar de coincidir el patrón de grafo básico

con un sub-grafo de los datos RDF sustituyendo los términos RDF del sub-grafo por las

variables definidas en el patrón. Tiene cuatro formas de consulta:

SELECT. Regresa todos, o un subconjunto de los valores que remplazan las

variables en el patrón coincidente.

CONSTRUCT. Regresa un grafo RDF construido por la sustitución de las variables

en un conjunto de plantillas de tripletas.

ASK. Regresa un valor booleano indicando si un patrón coincide o no.

DESCRIBE. Regresa un grafo RDF que describe los recursos encontrados.

El lenguaje SPARQL contiene instrucciones para realizar consultas de mayor complejidad

que involucren ordenamientos (ORDER BY), filtros (FILTER), comparaciones con tipos de

datos (DATATYPE), comparaciones opcionales (OPTIONAL), entre otros.

2) SPARQL Protocol [18]. Describe la manera de transmitir consultas SPARQL desde los

clientes hasta los ejecutores. El protocolo SPARQL contiene una única interfaz llamada

SparqlQuery. La interfaz SparqlQuery contiene una operación query, la cual es usada para

transmitir una cadena de consulta SPARQL y, opcionalmente, una descripción de conjunto

de datos (dataset) RDF.

3) SPARQL Query Results XML Format [19]. Define los documentos de resultados SPARQL,

utilizados para serializar resultados de una consulta SELECT o el resultado booleano de una

consulta ASK.

2.6.3. OWL

El Lenguaje de Ontologías Web (OWL) [14] tiene más capacidad para expresar significado y

semántica que XML, RDF, y esquemas RDF (RDFS), superando a estos lenguajes en la habilidad

para representar contenido interpretable por una computadora en la Web. OWL tiene tres sub-

lenguajes con un nivel de expresividad creciente:

OWL Lite, sirve para usuarios que necesitan una clasificación jerárquica y restricciones

simples. Por ejemplo, admite restricciones de cardinalidad pero sólo permite establecer

valores de 0 ó 1. Proporciona una ruta rápida de migración para tesauros y otras

taxonomías. Tiene una menor complejidad formal que OWL DL.


14

OWL DL, es útil para usuarios que requieren de una mayor expresividad pero conservando

plena computabilidad (se garantiza que todas las conclusiones sean computables) y

resolución (todos los cálculos se resolverán en un tiempo finito). Incluye todas las

construcciones del lenguaje OWL, pero pueden ser usadas sólo bajo ciertas restricciones

(por ejemplo, mientras una clase puede ser una subclase de muchas clases, una clase no

puede ser un ejemplar de otra). Se denomina OWL DL debido a su correspondencia con la

lógica de descripciones, un campo de investigación que estudia la lógica que compone la

base formal de OWL.

OWL Full, sirve para usuarios que requieren máxima expresividad y libertad sintáctica de

RDF sin garantías computacionales. Por ejemplo, una clase puede ser considerada

simultáneamente como una colección de clases individuales y como una clase individual.

Permite una ontología para aumentar el significado del vocabulario predefinido (RDF o

OWL). Esto no quiere decir que cualquier software de razonamiento soporte razonamiento

completo para cada característica de OWL Full.

Con base en (20), se da relevancia a los principales elementos que permiten definir RDFS y las

versiones de OWL4:

RDF Schema.

o Clases y ejemplares.

o Propiedades binarias entre objetos.

o Organización de clases y propiedades en jerarquías.

o Tipos de propiedades: restricciones de dominio y rango.

OWL Lite.

o Igualdad entre ejemplares, entre clases y entre propiedades.

o Desigualdad entre ejemplares (simple y por enumeración).

o Relación inversa, transitiva y simétrica entre propiedades.

o Propiedades funcionales (permiten como máximo un valor para un ejemplar

dado).

o Propiedades funcionales inversas (cuando el valor de la propiedad identifica al

ejemplar).

o Restricciones de dominio y rango más refinadas.

o Restricciones de cardinalidad (0/1).

OWL DL.

o Clases disjuntas (disjoint).

o Expresiones algebraicas booleanas (unión, intersección, complemento).

4 Los lenguajes RDFS y OWL son recomendaciones de la W3C, existen herramientas para su edición, como Protége y

OntoEdit, y sus ontologías pueden ser consultadas utilizando SPARQL.


15

o Enumeraciones de ejemplares para definir una clase.

o Propiedades con valor específico.

OWL Full.

o Una clase puede ser, al mismo tiempo, un tipo y una subclase de otra.

o Una clase puede ser un ejemplar por si misma.

o Igualdad entre una clase y un ejemplar.

Existe una inclusión semántica y sintáctica en los lenguajes RDFS, OWL Lite y OWL DL, en donde

cada modelo de una ontología RDFS es también un modelo para la misma ontología expresada en

OWL Lite (y similar para OWL Lite en OWL DL). OWL Full no incluye a OWL DL, ya que el segundo

contiene construcciones en el lenguaje más restrictivas. Los desarrolladores de ontologías que

desean utilizar OWL deben considerar el sub-lenguaje que mejor se adapte a sus necesidades.

Algunas definiciones en el contexto de ontologías OWL son:

Dominio5. Es el conjunto de términos lingüísticos o semánticos que son específicos a un

área de interés. A menudo es conocido como “dominio o universo del discurso”.

Individuos6. Representan objetos interesantes en el dominio. Son también conocidos como

ejemplares o instancias7 y pueden ser referidos como “ejemplares de clases”.

Propiedades. Son relaciones binarias entre individuos. Pueden ser transitivas, funcionales,

simétricas, pueden ser limitadas a tener un solo valor, pueden tener inversos, entre otros.

En el editor Protégé son conocidas como “ranuras” (del inglés “slots”). En lógica

descriptiva son conocidas como “roles” y en UML y otras nociones orientadas a objetos

como “relaciones”. En algunos otros formalismos son llamadas “atributos”. Hay tres tipos

principales de propiedad:

o Propiedades objeto (object properties). Relacionan a un individuo con otro

individuo.

o Propiedades de tipo de datos (datatype properties). Relacionan a un individuo con

un valor de tipo de dato de esquema XML o una literal RDF.

o Propiedades de anotación (annotation properties). Son utilizadas para agregar

información (metadatos – datos acerca de los datos) a las clases, individuos y

propiedades objeto y de tipo de dato.

Clases. Son interpretadas como conjuntos que contienen individuos. Pueden ser

organizadas en una jerarquía de superclase-subclase conocida como taxonomía. En

5 Fuente: http://en.wikipedia.org/wiki/Domain_of_discourse

6 Las definiciones del resto de los términos son tomadas de [60].

7 Debido a la traducción literal de la palabra inglesa “instance”; algunos autores no concuerdan con el uso de este

término.


16

ocasiones es utilizada la palabra “concepto” en lugar de clase. Una clase es una

representación concreta de un concepto.

OWL permite definir clases (owl:Class), subclases (rdfs:subClassOf), ejemplares, clases

equivalentes (owl:equivalentClass), propiedades de tipo de dato (DatatypeProperty), propiedades

de objeto (ObjectProperty), entre otras.

2.7. Metodologías de construcción de ontologías

En [20] realizan una revisión de metodologías para construcción de ontologías. A continuación se

describen algunas, agregando la propuesta por Noy y McGuinness en [21]:

Método de Uschold y King. Proponen cuatro actividades: identificar el propósito de la

ontología, construirla, evaluarla y documentarla. Presentan tres estrategias para definir los

conceptos principales: top-down (arriba hacia abajo), identificar primero los conceptos

más abstractos y luego especializarlos en conceptos más específicos; bottom-up (abajo

hacia arriba), identificar primero los conceptos más específicos y generalizarlos en

conceptos más abstractos; y middle-out (en medio hacía afuera), identificar primero los

conceptos más importantes y generalizarlos y especializarlos en otros conceptos.

Metodología de Gruninger y Fox. Es un método formal basado en la robustez de la lógica

clásica y puede ser usado como guía para transformar escenarios informales en modelos

computacionales. Proponen identificar intuitivamente los principales escenarios; formular

preguntas de competencia para determinar el alcance de la ontología y utilizarlas junto

con las respuestas para extraer los principales conceptos, propiedades, relaciones y

axiomas; y expresar en lógica de primer orden los componentes de la ontología.

Methontology. Enfocada en el proceso de desarrollo y ciclo de vida de ontologías. En el

proceso de desarrollo identifica las tareas para construir ontologías (planeación, control,

garantía de calidad, especificación, adquisición de conocimiento, conceptualización,

integración, formalización, implementación, evaluación, mantenimiento, documentación y

administración de la configuración), especificando las técnicas usadas en cada actividad,

los productos de salida y la forma de ser evaluados. Por otra parte identifica las etapas por

las que atraviesa una ontología en su ciclo de vida y la interdependencia con el ciclo de

vida de otras ontologías.

On-To-Knowledge. Los pasos que propone son: patada inicial (del inglés kick-off), etapa en

la que se capturan y especifican los requerimientos de la ontología, se identifican las

preguntas de competencia, se estudia el posible reuso de ontologías y se construye la

primera versión borrador de la ontología; refinamiento, se produce una ontología madura

orientada a la aplicación; evaluación, se evalúan los requerimientos y las preguntas de

competencia, la ontología es probada en el ambiente de aplicación; y mantenimiento.


17

Metodología de Noy y McGuinness. Consiste en lo siguiente: 1) determinar el dominio y el

alcance de la ontología, para determinar el alcance sugieren diseñar una lista de de

preguntas de competencia, preguntas que la ontología debería ser capaz de responder y

que sirven como prueba de control de calidad; 2) considerar la reutilización de ontologías

existentes; 3) enumerar términos importantes para lo ontología; 4) definir las clases y la

jerarquía de clases; 5) definir las propiedades de las clases; 6) definir las restricciones de

las propiedades: cardinalidad, tipo de valor, dominio y rango, entre otras; y 7) crear

ejemplares.

.

18

19

3. Capítulo 3

Estado del arte

En este capítulo se describen los proyectos más significativos del estado del arte y se presenta una

tabla comparativa. Debido a que el enfoque de esta tesis parte de la documentación de

metadatos, se incluye la descripción de un estándar relacionado con el tema.

3.1. Marco de trabajo para aprendizaje de ontologías

Li y otros plantean en [22] un marco de trabajo para la generación de una ontología OWL a partir

de un esquema de base de datos relacional. Este marco de trabajo utiliza un analizador de bases

de datos para extraer información del esquema. La información obtenida es transferida al

generador de ontología, el cual la construye siguiendo una serie de 12 reglas de aprendizaje

preestablecidas. Al final, los usuarios pueden refinar la ontología ayudados de un razonador y de

un editor de ontologías. En este trabajo se definen reglas para el aprendizaje de clases,

propiedades, características de propiedad (tipo de dato), jerarquía, cardinalidad y ejemplares.

3.2. Ontologías en la integración de bases de datos heterogéneas

En [23] se enfatiza la utilización de ontologías para el modelado de datos en casos de

interoperabilidad entre bases de datos con heterogeneidad de esquemas e incompatibilidades

semánticas. Utilizando el entorno de desarrollo Protégé 2000 y en base a un ejemplo, muestra una

propuesta de solución diseñando de manera manual ontologías locales y una ontología global.

3.3. Enfoques de ingeniería inversa basados en análisis de formularios HTML

En [24] y [25] proponen enfoques para generación de ontologías basados en el supuesto de que la

semántica de las bases de datos puede ser extraída del análisis de las páginas y formularios HTML.

Como primer paso obtienen un esquema de modelo de formularios, identificando elementos

como: campos de formulario, unidades estructurales, relaciones, restricciones, tipos de

formulario, ejemplares de formulario, entre otros.

En [24], el segundo paso es reemplazar construcciones del esquema de modelo de formularios con

construcciones en una ontología en lenguaje F-Logic utilizando reglas de mapeo. Por último, crean

ejemplares en la ontología a partir de los datos contenidos en los formularios HTML (proceso

denominado “migración de datos”) utilizando técnicas provistas para el entendimiento de tablas.

Capítulo 3 – Estado del arte

20

En [25], el segundo paso es generar un esquema XML a partir del esquema de modelo de

formularios (utilizando reglas de traducción entre conceptos). Basado en el esquema XML se

construye una estructura jerárquica del formulario. En seguida se deriva un sub-esquema

relacional encontrando equivalencias entre elementos de la estructura jerárquica y el esquema

físico de la base de datos. El siguiente paso es utilizar reglas de mapeo para construir un sub-

esquema conceptual UML basado en el sub-esquema relacional. Debido a que este proceso se

realiza con cada formulario HTML, es necesario integrar los sub-esquemas UML en un esquema

UML global. El esquema UML global es mapeado dentro de una ontología OWL para finalmente

crear ejemplares en la ontología con base en las tuplas de la base de datos relacional.

3.4. Arquitectura para federación de bases de datos basada en ontologías

En [26] presentan una arquitectura para federar tres bases de datos en Web basada en ontologías

e integración de esquemas. Está compuesta de:

1) Ontología. Representa el esquema global de las bases de datos y es creada de manera

manual.

2) Generador de Interfaz de Consulta. Genera automáticamente la interface de consulta

basándose en las frases en lenguaje natural acotado o la metáfora cognitiva asociada a

cada atributo de la ontología. Las restricciones de la consulta son expresadas en un

Lenguaje Formal de Consulta (LFC) definido en XML.

3) Distribuidor de Consultas. Comprueba los atributos implicados en la consulta del usuario,

lee la lista de identificadores de bases de datos asociados en la ontología, reenvía la

consulta y la lista de identificadores a los traductores de consultas y le informa al gestor de

la presentación las bases de datos involucradas.

4) Gestor de la presentación. Construye la primera página de respuesta informando al

usuario las bases de datos de las cuales se obtendrá respuesta. A partir de esta página el

usuario puede seleccionar las bases de datos en las que esté interesado y navegar a través

de los datos.

5) Traductores de Consultas. Traducen la consulta de formato LFC al específico de la base de

datos (SQL). Se auxilia en el esquema de correspondencias.

6) Esquema de Correspondencias. Subconjunto de la ontología que contiene los conceptos y

atributos de la base de datos asociada.

7) Emisor de Respuestas. Recupera la información solicitada de la base de datos asociada, la

formatea en LFR y la envía al gestor de la presentación para que se la presenta al usuario.

Todos los módulos de la arquitectura basan su funcionamiento en la Ontología y/o en los

Esquemas de Correspondencias.

3.5. OntoGrate

La arquitectura OntoGrate [27] combina representación de esquemas basada en ontologías,

inferencia lógica de primer orden y envolturas SQL (SQL wrappers) para integrar dos bases de

datos relacionales de ejemplo (Stores 7 de Informix y Nwind de Microsoft) del dominio de ventas

en línea. Define una súper ontología para SQL, expresando conceptos como funciones de


21

agregación y restricciones de integridad, que permite exportar características deseables de los

sistemas de bases de datos vía herencia de ontologías. Traduce cada esquema de base de datos a

su propia ontología. Conforma una ontología fusionada definiendo relaciones entre cada ontología

utilizando axiomas de “puente” (reglas de mapeo de primer orden). El módulo OntoEngine cumple

peticiones de consulta o traducción mediante el encadenamiento hacia atrás o hacia delante sobre

los axiomas de “puente” en la ontología fusionada (proceso denominado “integración de datos por

inferencia”). Traductores de sintaxis permiten a OntoEngine acceder a los datos relacionales

mediante una trasformación de Web-PDDL a SQL de las consultas atómicas. Web-PDDL es el

lenguaje de ontologías que esta arquitectura consideró más expresivo (comparado con Datalog y

XQuery) para representar relaciones entre esquemas como axiomas de “puente”.

3.6. Relational.OWL

En [28] representan datos relacionales y componentes del esquema de una base de datos a través

de una ontología en lenguaje RDF/OWL denominada Relational.OWL. Extraen metadatos

relevantes (tablas, columnas, tipos de datos y restricciones de longitud, llaves primarias y llaves

secundarias) de las tablas del sistema (también llamadas Diccionario de Datos o Repositorio) y los

representan dentro de la ontología de manera automática.

En [29] hacen énfasis en las principales características de su enfoque de mapeo:

Combinación de mapeo manual y automático. Por ser automático, enfoque adecuado en

escenarios donde los esquemas de bases de datos cambian constantemente. No adiciona

semántica real a los objetos RDF, en caso necesario, esto debe hacerse de manera manual.

Enfoque dentro de la Web Semántica. El proceso completo de mapeo es realizado

utilizando aplicaciones de Web Semántica. Mencionan como arquitectura más posible

aquella donde el mapeo sea procesado por pequeñas aplicaciones de envoltorio

(wrappers).

Lenguaje de mapeo bien-conocido. Basado completamente en técnicas actuales de

RDF/OWL. Los desarrolladores de aplicaciones de Web Semántica no requieren aprender

otro lenguaje de mapeo.

Existen dos diferentes implementaciones de Relational.OWL [30]:

Aplicación Relational.OWL. Desarrollada en lenguaje Java y para bases de datos IBM DB2 y

MySQL. Realiza transformaciones de base de datos a RDF/OWL y viceversa.

Relational.OWL para Oracle 10g. Procedimientos almacenados para bases de datos Oracle

implementados en PL/SQL. En su primera versión sólo realiza transformaciones de base de

datos a RDF/OWL.

3.7. RDQuery

Complementando Relational.OWL, en [31] presentan RDQuery, un sistema envoltorio (wrapper)

que traduce automáticamente consultas SPARQL y RDQL en consultas SQL basándose en la

representación Relational.OWL. El sistema RDQuery está implementado en lenguaje Java y para


22

bases de datos IBM DB2 y MySQL. La interfaz permite seguir el proceso de traducción, verificar la

consulta SQL generada y observar los resultados de la ejecución en la base de datos.

3.8. DartGrid

Chen y otros describen un marco de trabajo denominado DartGrid [32] compuesto principalmente

de tres componentes:

DartMapping, herramienta semántica visual empleada por expertos del dominio para

realizar un mapeo semántico entre diferentes esquemas relacionales y una ontología

compartida.

DartQuery, interfaz de consulta dinámicamente generada con base en la definición de

clases de la ontología compartida, realiza la conversión del lenguaje de consultas de

ontologías a consultas en SQL.

DartSearch, Interfaz de búsqueda intuitiva que permite a los usuarios realizar consultas de

texto libre sobre todas las bases de datos y navegar semánticamente entre los resultados.

Implementa un mecanismo de ranking para mejorar la precisión.

Los autores presentan una aplicación en donde, a través de una capa semántica, son relacionadas

bases de datos con estructuras heterogéneas semánticamente interconectadas. En la capa

semántica los usuarios y máquinas navegan a través de las interconexiones. Esta aplicación logra

resultados satisfactorios en la interoperabilidad de 70 bases de datos legadas de la Academia

China de Medicina Tradicional.

3.9. D2RQ Platform

En [33] describen D2RQ como una plataforma para acceder bases de datos relacionales no-RDF

como grafos RDF de solo lectura. Consta de un lenguaje de mapeo (D2RQ Mapping Language), un

motor de consultas (D2RQ Engine) y un servidor HTTP (D2R Server).

El lenguaje de mapeo D2RQ es un lenguaje declarativo para describir un modelo de datos

relacional a través de una ontología. Algunos objetos de este lenguaje son [34]:

ClassMap, representa una clase o un grupo de clases, usado para describir tablas. Define

un patrón URI concatenando los valores de la llave primaria para acceder a las tuplas de la

tabla.

PropertyBridges, usado para describir atributos de una tabla. Existen dos tipos:

DatatypePropertyBridges para literales y ObjectPropertyBridges para URIs y referenciar

ejemplares creados por otro ClassMap.

La plataforma incluye dos scripts ejecutables en línea de comandos Unix y Windows: generate-

mapping para crear un archivo de mapeo analizando el esquema de una base de datos existente y

dump-rdf para vaciar el contenido de la base de datos en un archivo RDF.

El motor D2RQ es un plug-in para Jena y Sesame (marcos de trabajo para construir aplicaciones de

Web Semántica) encargado de reescribir las llamadas de las API y las consultas SPARQL a consultas


23

SQL, gestionarlas con la base de datos involucrada y regresar los resultados en formato de tripletas

RDF o de resultado SPARQL (result sets).

Construido sobre el motor D2RQ, el servidor D2R permite mapear el contenido de una base de

datos en un archivo RDF y hacer accesibles las descripciones de los datos a través de la Web por

medio de la URI del recurso; considera las observaciones de Berners-Lee para datos enlazados

(Linked Data) [35] haciendo posible el recorrido entre los datos utilizando un navegador de Web

Semántica (ej. Tabulator, Disco); y proporciona una interface SPARQL de punto final (SPARQL

endpoint) para habilitar la consulta a la base de datos.

La plataforma D2RQ se encuentra implementada en lenguaje Java bajo licencia GNU GPL y soporta

bases de datos Oracle, MySQL, PostgreSQL y cualquier otra compatible con SQL-92.

3.10. Asio SBRD

Asio Semantic Bridge for Relational Databases (Asio SBRD) es una herramienta que proporciona

acceso RDF a datos relacionales. Según [36], ASIO SBRD permite transformar consultas SPARQL a

SQL, gestionar la ejecución en la base de datos relacional y regresar los resultados en formato RDF.

Una ontología de origen de datos es auto-creada en formato OWL SWRL (Semantic Web Rule

Language); relacionada con una preexistente ontología de dominio utilizando reglas de mapeo

creadas gráficamente con Asio Cartographer y Asio SQD; y agregada a la configuración para hacer

la base de datos disponible a consultas semánticas.

Asio Cartographer [37] es una herramienta para alinear ontologías OWL. Permite a los usuarios

visualizar ontologías y dibujar mapeos entre ellas de manera gráfica. Transforma los mapeos en

SWRL/RDF o SWRL/XML para utilizarlos en una base de conocimientos.

El propósito de Asio Semantic Query Decomposition (Asio SQD) [38] es dividir la consulta SPARQL

sobre la ontología de dominio en subconsultas optimizadas para cada una de las ontologías de

fuentes de datos involucradas. Los conjuntos de resultados de cada subconsulta son

transformados en una respuesta sencilla usando la ontología de dominio y regresados al usuario.

3.11. OpenLink Virtuoso

Descrito como un servidor de bases de datos virtual, OpenLink Virtuoso [39] proporciona acceso a

diferentes bases de datos tratándolas como una sola unidad lógica. Es compatible con Oracle, MS

SQL Server, DB/2, Informix, entre otros.

Virtuoso permite mapear datos relacionales a través de vistas RDF[40][12]. Incluye un lenguaje

meta-esquema (como extensión de SPARQL) para definir el mapeo de datos SQL a ontologías RDF

con base en patrones de cuatro elementos (grafo, sujeto, predicado, objeto), ofrece acceso por

protocolo SPARQL a clientes HTTP y permite a los clientes SQL realizar consultas SPARQL en lugar o

dentro de consultas SQL.


24

Algunos de los requerimientos del mapeo son:

Definir clases RDF (una para cada tabla) y las relaciones entre ellas utilizando RDF Schema

y URIs.

Crear una clase URI para cada valor de columna de llave primaria. Una clase URI define la

conversión de una columna o un conjunto de columnas en una URI.

Crear literales RDF y predicados URI para cada columna no llave. El lenguaje meta-

esquema soporta clases literal para definir la conversión de una columna o un conjunto de

columnas en una literal.

Definir patrones de mapeo cuádruples y almacenes de patrones. Los patrones especifican

la transformación de un conjunto de columnas relacionales en tripletas correspondientes a

un patrón de grafo SPARQL.

3.12. SquirrelRDF

SquirrelRDF [41] es una herramienta que permite realizar consultas SPARQL en bases de datos

relacionales (vía JDBC). Incluye un mapeador de bases de datos relacionales con una ontología,

una herramienta de línea de comandos, una API para Java y un servlet para realizar consultas

SPARQL vía HTTP.

3.13. SPASQL

SPASQL[42]es un servidor MySQL modificado para responder consultas SPARQL y SQL.

Considerando el traslape entre la expresividad de los lenguajes y la similitud entre los conjuntos de

resultados, SPASQL compila las consultas SPARQL en la misma estructura de datos (tablas reunidas

y restricciones) en que MySQL compila las consultas SQL, permitiendo al motor MySQL ejecutarlas

de la misma forma.

3.14. Estándar ISO/IEC 11179

El estándar multiparte ISO/IEC 11179 [43] presenta bases para la creación, organización y registro

de metadatos. Se conforma de 6 partes, destacando la de formulación de definiciones de datos y

la de principios de nombrado e identificación.

En la parte de formulación de definiciones de datos [44] establece como requerimientos que una

definición de datos debe ser declarada en singular (exceptuando si el concepto por sí mismo es

plural); decir lo que el concepto es, no solo lo que no es; ser declarada como una frase descriptiva

u oración(es); contener solo abreviaturas entendidas comúnmente; y ser expresada sin

incrustación de definiciones de otros datos o conceptos subyacentes.

Recomienda que una definición de datos debe: declarar el significado esencial del concepto; ser

precisa y no ambigua; ser concisa; poder valerse por sí misma; ser expresada sin justificación, uso

funcional o información procedimental; evitar el razonamiento circular; usar la misma

terminología y estructura lógica consistente para definiciones relacionadas; y ser apropiada para el

tipo del elemento de metadato que está definiendo.


25

En los principios de nombrado e identificación [45], se menciona que un nombre debe contener

términos discretos de tipo: clase objeto, propiedad, representación y calificado. Los términos clase

objeto conforman la parte del nombre que representa una actividad u objeto en un contexto (ej.

Empleado, tomado del elemento de datos “Empleado Segundo Apellido”). Los términos propiedad

denotan una característica común de las clases objeto (ej. Segundo Apellido, tomado del ejemplo

anterior). Los términos de representación definen la forma de representar los elementos de datos

y los valores de dominio, deben incluirse a partir de una lista de palabras controlada (ej. Cantidad,

Nombre, Número, Medida). Los términos de calificado deben agregarse a los de clase objeto,

propiedad y representación cuando es necesario distinguir un elemento de dato de otro. El

objetivo de definir reglas de nombrado es mantener la consistencia, apariencia y semántica de los

nombres, además de establecer equivalencias semánticas de nombrado a través de diferentes

lenguajes.

3.15. Tabla comparativa

Se realizó una comparación (Tabla 3.1) entre algunos de los trabajos del estado del arte y el

proyecto de tesis considerando los siguientes criterios:

1) Si se contempla la documentación de metadatos de las bases de datos dentro del enfoque.

Desde hace años los metadatos han sido útiles en favor de la integración de esquemas de

base de datos1.

2) Si se utilizan ontologías y/o archivos de mapeo y como son generados. Herramientas de

generación semiautomática de ontologías minimizan la intervención humana y permiten

reflejar los cambios del esquema de bases de datos de manera transparente.

3) Si el acceso a los datos es con base en URIs. En [46] Berners-Lee recalca la importancia del

mapeo de los objetos esenciales de las tablas dentro del espacio de las URIs. Las URIs nos

permiten identificar y localizar cualquier clase de objeto o concepto en la Web, es por ello

que son la base de los datos enlazados y de la publicación de bases de datos en la Web.

4) Si presentan interface de recuperación de datos para usuarios sin conocimiento de

SPARQL. Según [26], el éxito de un sistema depende de que los usuarios encuentren la

interface cómoda, fácil de usar, potente y flexible para satisfacer sus necesidades.

5) Si permiten ejecutar consultas SPARQL, ya sea a través del protocolo o por medio de

alguna herramienta de software.

6) El número de bases de datos de las que simultáneamente pueden recuperar datos.

7) Si implementan algún enfoque de integración de datos.

8) Si trabajan sobre un dominio de aplicación específico o pueden ser adaptables a

cualquiera.

9) El tipo de licencia de software en que las aplicaciones están disponibles.

1 Véase [59]


26

Tabla 3.1. Comparación de algunos trabajos del estado del arte y el proyecto de tesis

27

4. Capítulo 4

Análisis del problema y diseño de la solución

El problema tratado en esta tesis conduce a proponer alternativas apegadas a la Web Semántica

que faciliten la interoperabilidad de bases de datos heterogéneas. Esto implica amortiguar las

diferencias en software, hardware y representación de la información, además de utilizar una

herramienta de búsqueda común.

Debido a la estandarización de componentes de cómputo, actualmente son mínimos los

problemas que generan las diferencias en hardware. En cuanto al software, se debe considerar

que los sistemas administradores de bases de datos pueden estar montados en sistemas

operativos diferentes, sin embargo, utilizando herramientas de programación y componentes de

conectividad multiplataforma esto no implica algún conflicto. El problema de mayor complejidad a

resolver se manifiesta con las diferencias en la representación de los datos.

La idea clave de nuestro enfoque de solución es documentar los metadatos de las bases de datos

con base en una ontología de dominio (preexistente o creada para ello), esto permite obtener una

representación común y de mayor abstracción, dirimiendo conflictos generados por nombre

(sinonimia y homonimia) y sentando las bases para que las herramientas de consulta minimicen

los conflictos por diferencias en unidades de medida y tipos de datos.

Considerando lo anterior, la propuesta de solución se divide en las fases de:

1) Documentación, consiste en extraer los metadatos de una base de datos, documentarlos

con base en una ontología de dominio y generar un mapeo en formato D2RQ.

2) Publicación, comprende la publicación de la bases de datos en la Web utilizando un

servidor D2R. Las fases 1 y 2 se deben repetir con todas las bases de datos relacionales

heterogéneas involucradas.

3) Consulta, consiste en registrar y verificar todos los servidores de publicación para luego

construir consultas conformando tripletas de sujeto-relación-objeto, convertirlas a

SPARQL, gestionarlas en los servidores y presentar los resultados.

Se plantearon tres herramientas de software para implementar estas fases (Figura 4.1): Doc-D2R,

Query-D2R y D2R Server; siendo las primeras desarrolladas en el trabajo de tesis y la última, el

servidor, forma parte de la plataforma D2RQ.

Capítulo 4 – Análisis del problema y diseño de la solución

28

Figura 4.1. Actividades de la propuesta de solución y software relacionado

Las fases presentadas tienen una estrecha relación con la plataforma D2RQ debido a que, como

resultado del análisis del estado del arte, se decidió reutilizar y aprovechar las ventajas de esta

plataforma. Algunas de estas ventajas son:

1) Presenta un lenguaje de mapeo bien definido que comprende información de parámetros

de conexión, tablas, columnas, descripciones, alias de tabla y columna, condiciones de

publicación, tipos de datos, equivalencias y transformaciones de valores, etc.

2) Incluye un servidor HTTP que permite publicar la base de datos en la Web como un

conjunto de datos RDF, habilitando el acceso por medio de URIs y consultas SPARQL. El

servidor se basa en el motor D2RQ, encargando de realizar la transformación de consultas

SPARQL y peticiones de datos RDF a las consultas SQL necesarias, de gestionarlas con el

SMBD y de regresar los resultados en formato de resultados SPARQL.

3) Todas las herramientas de la plataforma están desarrolladas en lenguaje de programación

Java y su código fuente está disponible bajo licencia GNU GPL, esto las hace

multiplataforma y factibles de modificar y adaptar9.

Además de lo anterior, se destaca que recientemente el lenguaje de mapeo D2RQ ha sido

considerado uno de los lenguajes iniciales en la discusión del grupo de trabajo de la W3C para la

estandarización de los lenguajes de mapeo.

A continuación se describe con mayor detalle cada una de las fases de la propuesta de solución. Al

final del capítulo se incluyen los análisis previos a la implementación de la fase de documentación.

4.1. Fase 1: Documentación

La documentación abarca los siguientes aspectos:

Definición de alias de tabla y columna, escritos o elegidos por el usuario a partir de las

clases y propiedades de tipo de dato de una ontología de dominio.

9 Los creadores de la plataforma mantienen un foro de discusión muy activo, puede consultarse en:

http://sourceforge.net/mailarchive/forum.php?forum_name=d2rq-map-devel


29

Declaración de equivalencias entre valores permitidos en la ontología y valores en la base

de datos.

Especificación de unidades de medida para columna, elegidas por el usuario del listado

tomado del archivo de medición.

Relaciones agregadas automáticamente, inferidas a partir de la ontología de dominio.

La fase de documentación comprende las actividades mostradas en la Figura 4.2.

Figura 4.2. Actividades de la fase de documentación

a) Extraer metadatos.

i. El usuario establece los parámetros de conexión.

ii. Doc-D2R, utilizando JDBC, importa el esquema de la base de datos y la información

extraída es presentada al usuario y guardada en una copia en memoria del proyecto

de documentación.

b) Cargar ontología de dominio y unidades de medida.

i. El usuario establece la ruta de la ontología de dominio.

ii. Doc-D2R carga la taxonomía de clases y propiedades de la ontología de dominio

(ontDom).

iii. Doc-D2R carga la información relacionada con los sistemas de unidades desde una

ruta de archivo predefinida.

c) Documentar metadatos.

El usuario documenta las columnas de dos formas disponibles:

i. Redactando las características de forma manual.

ii. Relacionando columnas con propiedades objeto de la ontología, en este caso:


30

1. El nombre de la propiedad es asignado como alias de columna, no

permitiendo modificación al mismo.

2. La definición de la columna es tomada de la anotación de comentario

(rdfs:comment) de la propiedad, permitiendo modificación posterior.

3. En caso de relacionar propiedades con listado de valores permitidos

predefinidos, se presenta al usuario el listado para que establezca las

equivalencias correspondientes.

4. La unidad de medida puede ser elegida por el usuario relacionando alguna de

las unidades predefinidas.

5. Las demás características de columna son documentadas de forma manual

por el usuario (valor por defecto, máscara de formato, etc.).

El usuario documenta las tablas (alias y definición) de dos formas disponibles:

i. Redactando las características de forma manual.

ii. Relacionando tablas con clases de la ontología, en este caso:

1. El nombre de la clase es asignado como alias de tabla, no permitiendo

modificación al mismo.

2. La definición de la tabla es tomada de la anotación de comentario

(rdfs:comment) de la clase, permitiendo modificación posterior.

La información recabada a partir de la documentación es almacenada directamente en

la copia temporal del proyecto.

d) Generar mapeo D2RQ.

Es la actividad medular de la propuesta de solución. Aprovechando algunas de las

ventajas de la plataforma D2RQ, el objetivo de esta actividad es adecuar la estructura

de la base de datos (sin modificarla) a la definida por la ontología de dominio. Esto se

lleva a cabo generando un mapeo D2RQ enriquecido con la información del proceso

de documentación. Las sub-actividades son las siguientes:

i. Doc-D2R crea un nuevo archivo de mapeo D2RQ.

ii. Doc-D2R agrega las cabeceras de prefijos y los datos de conexión al archivo de mapeo.

iii. Para cada tabla, Doc-D2R agrega una definición de clase en el archivo de mapeo. Esta

actividad no se realiza en tablas que tienen sólo dos columnas, dos llaves primarias y

dos llaves foráneas, debido a que se asume que estas tablas constituyen una relación

muchos a muchos (n:m). El nombre de la clase es tomado a partir de los alias de

ontología y de usuario, teniendo como preferencia el primero. Si el alias es de

ontología se agrega una relación rdfs:Class con la clase de la ontología de dominio.

iv. Para cada columna que no es llave foránea, Doc-D2R agrega una definición de

propiedad. El nombre de la propiedad es tomado a partir de los alias de ontología y de

usuario, teniendo como preferencia el primero. Si el alias es de ontología la propiedad

D2RQ se relaciona con el URL de la propiedad de la ontología. Si la columna tiene

definidos valores permitidos, se agrega la tabla de transformación. Si la columna tiene

definida una máscara de formato, se agrega la condición de formato.


31

v. Doc-D2R crea una representación de grafo dirigido del esquema de la base de datos,

nombrando cada nodo de tabla a partir de los alias de ontología y de usuario,

teniendo como preferencia el primero, y etiquetando las aristas con el nombre de la

relación involucrada.

vi. Doc-D2R consulta las propiedades objeto de la ontología ontDom. Para cada

propiedad objeto, Doc-D2R extrae el nombre de las clases que ocupan la posición de

dominio y rango. Luego revisa si esas dos clases están presentes en el grafo, si es así,

por medio de un recorrido verifica si pueden ser alcanzables entre sí o desde cualquier

otro nodo. En caso de que las clases sean alcanzables, Doc-D2R crea una definición de

propiedad considerando las reuniones tomadas del recorrido y la nombra igual que la

propiedad objeto de la ontología.

vii. Para cada columna que es llave foránea, Doc-D2R agrega una definición de propiedad

con reunión (join). Esta actividad no se realiza en columnas que pertenecen a tablas

n:m. El nombre de la propiedad es asignado concatenando los nombres de las clases

origen y destino en la relación. Esta actividad no se realiza en caso de que la propiedad

D2RQ entre esas dos clases ya exista.

viii. Para cada tabla n:m, Doc-D2R agrega una definición de propiedad n:m en donde se

involucran dos reuniones. El nombre de la propiedad es asignado concatenando los

nombres de las clases origen y destino. Esta actividad no se realiza en caso de que la

propiedad D2RQ entre esas dos clases ya exista.

Aunque Doc-D2R permite guardar el documento de proyecto, recuperarlo y generar un reporte de

documentación, son actividades que sólo brindan un mayor soporte al usuario más no son

indispensables para generar el mapeo.

4.2. Fase 2: Publicación

La Figura 4.3 muestra la arquitectura de la plataforma D2RQ. La fase de publicación se realiza

utilizando el servidor D2R y el mapeo generado en la fase de documentación. La única actividad en

esta fase es la siguiente:

a) Publicar base de datos en la Web.

i. El usuario ejecuta el servidor D2R indicando el mapeo correspondiente.

Las fases 1 y 2 se realizan con todas las bases de datos involucradas.

4.3. Fase 3: Consulta

La Figura 4.4 muestra las actividades en la fase de consulta, las cuales son:

a) Preparar consulta.

i. El usuario establece la ruta de la ontología de dominio y las rutas de los archivos de

documentación y de los servidores D2R.


32

Figura 4.3. Actividad en la fase de publicación

Figura 4.4. Actividades en la fase de consulta

b) Enlazar servidores D2R.

i. Query-D2R consulta los servidores D2R y extrae las clases y propiedades de ontDom

que estén relacionadas a un alias de tabla o columna.


33

c) Construir consulta.

i. El usuario conforma su consulta en Query-D2R. La construcción de la consulta se basa

en la noción de tripletas de dominio-relación-rango (ó sujeto-predicado-objeto) y

consiste en formular sub-consultas que sirven de filtrado para consultas más

abstractas. En caso de que los rangos estén relacionados a un tipo de dato, Query-D2R

agrupa los tipos esquema XML en categorías (Tabla 4.1) y carga un formulario para

especificar filtrados en base a plantillas y escoger unidad de medida relacionada. Si el

rango está relacionado a un conjunto de valores permitidos definidos en la ontología,

QueryD2R presenta el listado al usuario.

Tabla 4.1. Agrupación de tipos de datos

Categoría Tipo esquema XML Tipos JDBC

Valor de texto xsd:string char, varchar, longvarchar

Valor numérico xsd:long biginit

xsd:decimal decimal, float, numeric

xsd:double double

xsd:integer int

xsd:float real

xsd:short smallint

xsd:byte tinyint

Valor de fecha xsd:date date

Valor de fecha tiempo xsd:dateTime timestamp

Valor booleano xsd:boolean boolean, bit

d) Convertir consulta a SPARQL.

i. Query-D2R realiza la transformación de la consulta construida al lenguaje de consulta

SPARQL. En caso de que en la consulta se haya especificado un filtro con una

determinada unidad de medida (ej. Calificaciones en formato de 0-10 menores a 6),

Query-D2R verifica la tabla de conversión en de las unidades de medida (situada

dentro del archivo medicion.xml) y convierte el valor de parámetro (valor 6) a la

unidad de medida del servidor a consultar (por ejemplo: si la documentación indica

que maneja las calificaciones en forma de 0-100, el valor 6 es convertido a su

equivalente 60 en esta unidad de medida).

e) Ejecutar consulta en servidores.

i. Query-D2R envía la consulta a cada uno de los servidores D2R. Los resultados

individuales son concatenados en un conjunto de resultados global.

f) Mostrar resultados.

i. Query-D2R presenta el conjunto de resultados global, habilitando un enlace URL para

consultar los detalles directamente del servidor D2R en el navegador Web

predeterminado.


34

4.4. Análisis previos

En esta sección se presentan las consideraciones previas a la implementación de Doc-D2R.

4.4.1. Bases de datos de prueba

Una normalización extrema en una base de datos relacional puede provocar un gran número de

tablas y en consecuencia un pobre rendimiento debido al número de reuniones necesarias en las

consultas SQL. Según [47], muchas implementaciones de bases de datos relacionales comerciales

no van más allá de la tercera forma normal (3FN)10. La 3FN garantiza que:

Sean definidas llaves primarias para cada tabla.

Cada registro sea identificado únicamente con una llave primaria.

Todos los campos contengan un valor simple (sean atómicos).

Todos los campos no-clave sean totalmente dependientes (dependencia funcional total) a

la llave primaria y no existan dependencias parciales.

No existan dependencias transitivas.

Con base en lo anterior, se definieron los requerimientos de diseño de las bases de datos de

prueba:

1) Normalización. El diseño debe encontrarse en 3FN.

2) Llaves foráneas. Las llaves primarias y foráneas deben estar definidas explícitamente en el

sistema manejador de base de datos.

Sumado a los requerimientos de diseño, debe estar disponible un controlador JDBC para

interactuar con el SMBD y el SMBD debe ser compatible con el estándar SQL-92.

Para la elección de las tres bases de datos del escenario de prueba se contaban con las siguientes

opciones:

Primaria, secundaria y preparatoria. Diseñados por un grupo de profesionales de la

Computación y en donde los diseños no estuvieron sujetos a requerimientos estrictos y

presentaban poca documentación.

Los diseños de las 5 bases de datos (contred, sisban, sispro, siscom y siscob)

correspondientes a los módulos del Sistema Integral de Administración de Tecnológicos

(SIATEC) y el de la base de datos del Sistema de Control Escolar bajo ambiente Windows

del Cenidet (SiCEWin). Estos diseños estuvieron implementados en un ambiente real y

presentaban documentación (externa, en documento de texto) de los atributos de sus

tablas.

10 Breve repaso en http://support.microsoft.com/kb/283878/


35

genWeb, utilizada por el proyecto “Generador de Páginas Web para Profesores-

Investigadores” del Cenidet. Diseñada por un grupo de alumnos como parte de un

proyecto de fin de materia. Presentaba descripción básica de las tablas.

Fueron descartadas aquellas donde el diseño no cumplía la 3FN y adecuarlo implicaba un

significante número de cambios11. La Tabla 4.2 muestra un resumen de las características

originales de las bases de datos de prueba elegidas. Se adecuaron los diseños para que

presentaran los conflictos a resolver y cumplieran con los requerimientos. La Tabla 4.3 muestra un

resumen de las características finales y la descripción de las principales modificaciones efectuadas.

Los diagramas modificados de las bases de datos SiCEWin, Prepa y genWeb son mostrados en el

Anexo A.

Tabla 4.2. Características originales de las bases de datos de prueba

Nombre Descripción Diseñador Características de diseño

Documentación SMBD

SiCEWin Fue utilizada por el Sistema de Control Escolar bajo ambiente Windows (SiCEWin) del Cenidet

Alumnos del Cenidet

17 tablas

157 columnas

24 llaves primarias

24 llaves foráneas

-Descripción básica en cada uno de los campos.

-Indicación de campos requeridos.

-Rango aceptado de valores para algunos campos.

-Máscara de formato de valores para algunos campos.

Paradox

Prepa Diseñada para ser utilizada en un hipotético sistema de registro escolar de escuelas preparatorias

Grupo de profesionales de la computación

8 tablas

42 columnas

13 llaves primarias

9 llaves foráneas

-No existente. Microsoft Access

genWeb Utilizada por el proyecto “Generador de Páginas Web para Profesores-Investigadores” del Cenidet

Alumnos del Cenidet

11 tablas

91 columnas

20 llaves primarias

10 llaves foráneas

-Descripción básica de las tablas

Microsoft SQL Server 2000

11 En particular las bases de datos que integraban el Sistema Integral de Administración de Tecnológicos


36

Tabla 4.3. Características finales de las bases de datos de prueba

Nombre Características de diseño SMBD Modificaciones

SiCEWin 13 tablas (-4 del original)

65 columnas (-92)

17 llaves primarias (-7)

14 llaves foráneas (-10)

MySQL Server 5.0 -Eliminación de tablas temporales y de configuración.

-Eliminación de grupos repetidos, dependencias transitivas, entre otras, para que cumpliera con la 3FN.

Prepa 7 tablas (-1 del original)

36 columnas (-6)


6 llaves foráneas (-3)

Microsoft SQL Server 2005 Express Edition

-Adecuación para manejo de datos de una sola preparatoria.

-Cambios en llaves para que cumpliera con la 3FN.

genWeb 11 tablas (igual al original)

65 columnas (-21)


10 llaves foráneas (igual)

MySQL Server 5.0 -Eliminación de tabla de activación y otras.

-Eliminación de grupos repetidos.

4.4.2. Características a documentar

En esta sección se da un resumen de las características que se consideraron documentar para cada

uno de los elementos de la base de datos. En las tablas mostradas los valores de la columna

“Proporcionado por” tienen el siguiente significado:

Usuario. Especificado por el usuario.

Calculado. Calculado por la herramienta de software.

Ontología/Usuario. Puede ser escrito por el usuario o elegido a partir de la ontología.

Ontología. El usuario debe elegir a partir de la ontología.

Las características a documentar se dividen en:

SMBD y resumen. Características generales y de acceso a la base de datos, son mostradas

en la Tabla 4.4. Tabla 4.4. Características de SMBD y resumen

Características Proporcionado por

Nombre de base de

datos

Usuario

Descripción general Usuario

Usuario Usuario

Total llaves primarias Calculado

Total llaves foráneas Calculado

Total de campos Calculado

Total de tablas Calculado

SMBD (tipo) Calculado

SMBD (versión) Calculado


37

Tabla. Las características de una tabla y su relación con otras tablas son mostradas en la

Tabla 4.5. Tabla 4.5. Características de tabla


Alias Ontología/Usuario

Definición Ontología/Usuario

Llaves primarias (listado) Calculado

Llaves foráneas (listado) Calculado

Relacionada con tablas (listado) Calculado

Total de campos Calculado

Columna. Las características de una columna son mostradas en la Tabla 4.6. La máscara de

formato deberá definirse con una expresión regular de la forma especificada en la clase

Pattern12 de J2SE (Java 2 Standard Edition v1.4.2).

Tabla 4.6. Características de columna


Alias Ontología/Usuario

Definición Ontología/Usuario

Tipo de dato Calculado

Admite valores nulos Calculado

Precisión de dato Calculado

Escala de dato Calculado

Ejemplo de dato Usuario

Máscara de formato Usuario

Valor por defecto Ontología/Usuario

Valores permitidos Ontología/Usuario

Unidad de medida Ontología

La Tabla 4.7 muestra un conjunto de reglas, definidas por el autor, para la creación de alias de

tablas y columnas. Se recomienda la formulación de descripciones o definiciones acorde con el

estándar ISO/IEC 11179-4:200413.

12 Documentación disponible en http://java.sun.com/j2se/1.4.2/docs/api/java/util/regex/Pattern.html

13 Véase sección 3.14


38

Tabla 4.7. Reglas de creación de alias de tablas y columnas

Contexto: Bases de datos del proyecto de tesis

Alcance: Alias para tablas y columnas

Autoridad: Autor de la tesis

Reglas semánticas:

Alias de tabla:

a) Los alias de tabla representan cosas de interés (conceptos generales) en el universo del discurso (dominio). Ejemplo: Alumno, Profesor, Materia.

NOTA: Los alias de tablas que impliquen relaciones entre tablas (ej. autores_publicacion en Genweb),

quedan excluidas de las reglas de nombrado.

b) Sólo puede ser definido un y solo un alias de tabla para identificar un concepto determinado, ejemplo: no debe existir un alias de tabla alumno y un alias de tabla estudiante.

Alias de columna:

a) Los alias de columna representan características de conceptos. Ejemplo: apellidoPaterno, CURP, sexo.

b) Los alias de columna que identifican una misma característica deben preservar la misma estructura, ejemplo: alumnoApellidoPaterno y maestroAellidoPaterno.

c) En un alias de columna es preferible no incluir el término de tabla, se recomienda hacerlo solo en los casos similares al inciso anterior.

Reglas sintácticas:

Alias de tabla:

a) Un alias de tabla se conforma sólo de un término de concepto. Alias de columna:

a) Un alias de columna debe contener un término de propiedad.

Reglas léxicas:

Alias de tabla:

a) Los sustantivos son utilizados en su forma singular, a menos que el concepto por sí mismo esté definido en plural. Ejemplo: Alumno, Tesis.

b) Todas las palabras inician en mayúsculas y no contienen espacios en blanco (convención de nombrado PascalCase).

Alias de columnas:

a) Los sustantivos son utilizados en su forma singular, a menos que la característica por sí misma esté definida en plural. Ejemplo: apellidoPaterno, CURP, sexo.

b) La primer palabra inicia en minúscula, las demás en mayúscula y no contiene espacios en blanco (convención de nombrado camelCase).

Ambos:

a) Se permiten abreviaturas y acrónimos sólo si son comúnmente utilizados en el dominio. b) No se permiten caracteres especiales ni acentos. c) Las siglas bien conocidas (ej. CURP) son en mayúsculas.

Reglas de unicidad:

Todos los alias deben ser únicos dentro del contexto.

4.4.3. Ontología de dominio

En esta sección se describe de manera general la ontología desarrollada, la metodología utilizada y

las reglas de nombrado establecidas.

La ontología ontDom contiene las clases relacionadas con el dominio de registros escolares. El

referir una ontología como una ontología de dominio implica una redundancia, sin embargo en

este documento se aplica indistintamente el término “ontología de dominio” para referir a la

ontología ontDom.


39

Para la construcción de la ontología se siguió la metodología propuesta en [21]:

Determinar el dominio y alcance de la ontología:

El dominio de la ontología es el de registros escolares debido a la naturaleza de las bases

de datos de prueba. La ontología se utilizará en la construcción y ejecución de consultas y

como auxiliar en la documentación de las bases de datos y generación de mapeos D2RQ. El

lenguaje de ontologías a utilizar es OWL DL.

La construcción y el mantenimiento de la ontología fueron realizados por el autor de esta

tesis.

Se definieron las siguientes preguntas de competencia:

P1.Alumnos que toman clases con XProfesor y son tesistas de él.

P2. Calificaciones del XAlumno.

P3. Alumnos que llevan XMateria y tienen calificación menor a XValor.

P4. Nombre del tema de tesis de XAlumno.

P5. Materia que toma XAlumno a XHora.

P6. Nombre de las especialidades de XCarrera.

P7. Todos los alumnos (hombres) que toman materias con XProfesor.

P8. Profesores que le imparten clase a XAlumno.

P9. Profesores que dirigen tesis de alumnos de XEspecialidad.

P10. Alumnos con XBeca que están en XCarrera.

Considerar la reutilización de ontologías:

No se encontró una ontología relevante para reutilizar en su totalidad, sin embargo se

consideraron algunas características de las ontologías PROTON14 e ISO-1911515.

Enumerar términos importantes para lo ontología:

La enumeración es la siguiente:

Alumno, especialidad, carrera, beca, escuela, tesis, profesor, grupo, materia,

horario, calificación.

Definir las clases y la jerarquía de clases:

Se consideró la recomendación de [21] respecto a que la ontología no contenga toda la

información posible del dominio, sólo la necesaria para nuestra aplicación. Utilizando un

proceso de desarrollo combinado16 se llegó a la jerarquía de clases de la Figura 4.5.

14PROTON (PROTon ONtology), diseñada dentro del alcance del proyecto SEKT, más información en

http://proton.semanticweb.org/ 15

Ontología de información geográfica de acuerdo al estándar ISO-19115, más detalles en

http://loki.cae.drexel.edu/~wbs/ontology/iso-19115.htm 16

Combinación de los enfoques top-down y bottom-up, véase pág. 9 de [27].


40

Figura 4.5. Jerarquía de clases de la ontología ontDom

Definir las propiedades de las clases:

El resumen de las propiedades es mostrado en la Figura 4.6.

Definir las restricciones de las propiedades:

El resumen de las restricciones de las propiedades es mostrado en la Figura 4.6.

Crear ejemplares:

La creación de ejemplares no aplica en la ontología ontDom, sólo se utiliza su estructura.

La definición detallada de la ontología ontDom puede ser consultada en la documentación

electrónica de la misma17.

Aunado a la construcción de la ontología ontDom se definió un conjunto de reglas de nombrado

en ontologías basado en el estándar ISO/IEC 11179-5:2005 [45]. Se incluyen reglas semánticas,

sintácticas, léxicas y de unicidad. Estás reglas se muestran en la Tabla 4.8.

17 Generada automáticamente con el editor Protege-OWL y disponible en la biblioteca del Cenidet.


41

Figura 4.6. Resumen de las propiedades y las restricciones de propiedades de la ontología ontDom


42

Tabla 4.8. Reglas de nombrado en ontologías

Contexto: Ontologías OWL del proyecto de tesis

Alcance: Nombrado de clases y propiedades objeto y de tipo de dato

Autoridad: Autor de la tesis

Reglas semánticas:

Clases:

a) Los nombres de clases representan conjuntos de objetos que comparten características en el universo del

discurso (dominio). Ejemplo: Alumno, Profesor, Materia.

b) Sólo puede ser definido un y solo un nombre para identificar una clase determinada, ejemplo: no debe existir una

clase Alumno y una clase Estudiante.

Propiedades:

a) Los nombres de propiedades representan relaciones binarias, pueden ser de tipo de dato (datatype properties) o

de objeto (object properties). Ejemplo: tieneApellidoPaterno, realizaTesis.

b) Sólo puede ser definido un y solo un nombre para identificar una propiedad determinada, ejemplo: no debe

existir una propiedad tieneApellidoPaterno y una propiedad tieneApaterno.

Reglas sintácticas:

Clases:

a) Un nombre de clase se conforma sólo de un término clase.

Propiedades:

a) Un nombre de propiedad de tipo de dato se conforma de la palabra “tiene” seguida del término de propiedad y

opcionalmente el término de clase. Ejemplo: tieneCardinalidad, tienePrecisionDato.

b) En un nombre de propiedad objeto se recomienda el uso de prefijos y sufijos, sin embargo no es obligatorio.

Prefijos: es, tiene, esta, entre otros. Sufijos: de, por, entre otros.

c) Los términos de representación y cualificadores no son obligatorios, en caso de que se presenten deben ubicarse

inmediatamente antes y después, respectivamente, del término de propiedad.

Reglas léxicas:

Clases:

a) Los sustantivos son utilizados en su forma singular, a menos que el concepto por sí mismo esté definido en

plural. Ejemplo: Alumno, Tesis.

b) Todas las palabras inician en mayúsculas y no contienen espacios en blanco.

Propiedades:

a) Los sustantivos son utilizados en su forma singular, a menos que el concepto por sí mismo esté definido en

plural. En caso de contener verbos, estos son escritos en tiempo presente. Ejemplo: dirigeTesis.

b) La primer palabra inicia en minúscula, las demás en mayúscula y no contiene espacios en blanco (convención de

nombrado camelCase).

Ambos:

a) Se permiten abreviaturas y acrónimos sólo si son comúnmente utilizados en el dominio.

b) Los nombres sólo se conforman de letras y números.

c) No se permiten caracteres especiales ni acentos.

Reglas de unicidad:

a) Todos los nombres deben ser únicos dentro del contexto.


43

4.4.3.1. Esquema XML de unidades de medición

Este esquema define la estructura del archivo XML que guarda la información de sistemas de

unidades, incluye:

Capacidad para guardar n sistemas de unidades.

Cada sistema de unidad incluye un nombre corto, un nombre largo y un conjunto de

magnitudes.

Cada magnitud contiene una unidad fundamental y un conjunto de unidades derivadas.

En cada unidad derivada se agrega, además del símbolo de la unidad, el factor de

conversión en relación con la unidad fundamental.

Capacidad para guardar factores de conversión entre magnitudes de diferentes sistemas

de unidades.

La Figura 4.7 muestra una gráfica resumiendo las anteriores características.

Figura 4.7. Estructura del esquema XSD de unidades de medición

De acuerdo a la estructura definida se creó el archivo XML de medición (medicion.xml), el cual

incluye las principales unidades del Sistema Internacional de Unidades y un sistema auxiliar

denominado “Otro” en donde se guardan los valores de unidades de calificación. Este archivo XML

es utilizado en las fases de documentación y consulta1.

1 El contenido de medicion.xsd y medicion.xml se encuentra en la documentación de Doc-D2R disponible en la biblioteca

del Cenidet.

44

45

5. Capítulo 5

Doc-D2R – Software de documentación

Este capítulo presenta un resumen del proceso de desarrollo de Doc-D2R.

5.1. Especificación de requerimientos

En esta sección se incluye la descripción de la herramienta y del usuario que la utiliza, así como el

listado de requerimientos y casos de uso.

5.1.1. Descripción

Doc-D2R es una herramienta de software que permitirá extraer el esquema de una base de datos,

documentarlo con base en una ontología de dominio y generar automáticamente el mapeo D2RQ

correspondiente.

5.1.2. Usuario

El usuario de Doc-D2R se denominará “documentador”. El documentador deberá tener

conocimiento de los parámetros de conexión y el dominio de aplicación de la base de datos.

5.1.3. Requerimientos

El siguiente es el listado de requerimientos obtenidos de acuerdo al alcance y propuesta de

solución de esta tesis:

a) Requerimientos funcionales:

i. Extraer y presentar los metadatos de un esquema de base de datos relacional.

ii. Extraer y presentar la taxonomía de clases y propiedades de una ontología OWL DL.

iii. Extraer las unidades de medidas almacenadas en un archivo de medición.

iv. Permitir relacionar clases y propiedades de la ontología con tablas y columnas de la

base de datos, respectivamente.

v. Permitir relacionar unidades de medida con columnas de la base de datos.

vi. Generar reporte de documentación.

vii. Generar mapeo D2RQ.

viii. Permitir guardar y recuperar archivo de documentación sin pérdida de información.

Capítulo 5 – Doc-D2R - Software de documentación

46

b) Requerimientos de interfaz de usuario:

i. Contener un formulario principal como punto de partida para acceder a cualquier

otro.

ii. Presentar los metadatos de la base de datos en un componente de navegación por

ratón o flechas del teclado y mostrar las propiedades de la selección en una pestaña

de detalle.

c) Requerimientos de confiabilidad:

i. Se liberará el software en su versión beta una vez terminada y aprobada la etapa de

pruebas.

ii. No se contemplarán esquemas de tolerancia a fallas y recuperación.

d) Requerimientos de mantenimiento:

i. El código fuente debe contener comentarios de documentación e implementación.

e) Requerimientos de portabilidad:

i. Deberá ser capaz de ejecutarse en sistemas operativos basados en Windows y Linux e

interactuar con Sistemas Manejadores de Bases de Datos compatibles con el estándar

SQL-92.

f) Requerimientos reglamentarios:

i. Será liberado en su versión 1.0 una vez que su desempeño sea aprobado por el comité

revisor de la tesis.

5.1.4. Casos de uso

Como resultado del análisis de los requerimientos funcionales se observa al documentador como

único actor encargado de activar las siguientes funciones:

Configurar nuevo proyecto, estableciendo los parámetros de conexión de la base de datos

y la ruta de la ontología de dominio.

Documentar los elementos de la base de datos. Entre otros, incluye:

o Escoger alias de tabla a partir de las clases de la ontología de dominio.

o Escoger alias de columna a partir de las propiedades de tipo de dato de la

ontología de dominio.

o Escoger unidad de medida partir de las unidades definidas en archivo de medición.

Generar reporte de documentación.

Generar mapeo D2RQ.

Guardar archivo de proyecto Doc-D2R.

Abrir archivo de proyecto Doc-D2R.

La Figura 5.1 muestra el diagrama de casos de uso. Los casos de uso son mostrados con detalle

desde la Tabla 5.1 hasta la Tabla 5.9.


47

Figura 5.1. Diagrama de casos de uso de Doc-D2R

Tabla 5.1. Descripción de cu1_configurarProyecto

cu1_configurarProyecto

Actor: Documentador.

Descripción: Permite establecer los parámetros iniciales de un nuevo proyecto de documentación.

Precondición: No tiene.

Flujo normal

(fn):

1) El actor pulsa el botón de nuevo proyecto.

2) La aplicación muestra el formulario para indicar los campos de conexión y la ruta de

la ontología de dominio.

3) El actor rellena los campos y presiona el botón para verificar la conexión.

4) La aplicación verifica la conexión e indica el mensaje de conexión exitosa.

5) El actor presiona el botón de aceptar.

Flujos

alternativos

(fa):

2) (fa1) En caso de que exista proyecto cargado, la aplicación manda mensaje de

confirmación de cierre de proyecto sin guardar cambios.

3) (fa1) El actor confirma el mensaje (continúa en el punto 2 del flujo normal).

4) (fa2) La aplicación verifica la conexión e indica el mensaje de conexión fallida

permitiendo al usuario modificar los campos (continúa en el punto 3 del fn).

(fa3) En cualquier momento el actor presiona el botón de cancelar y la aplicación


48

cierra el formulario de nuevo proyecto.

Poscondiciones: La aplicación extrae los metadatos de la base de datos y los presenta desglosados en

un componente de árbol.

La aplicación almacena en memoria los parámetros de configuración inicial y los

valores de los metadatos.

Tabla 5.2. Descripción de cu2_documentar

cu2_documentar


Descripción: Permite documentar los elementos de la base de datos.

Precondición: La aplicación debe tener un proyecto configurado.

Flujo normal: 1) El actor pulsa el nombre de la base de datos en el árbol.

2) La aplicación carga el resumen de la base de datos y un campo para la descripción.

3) El actor rellena la descripción de la base de datos.

4) El actor pulsa el nombre de una tabla en el árbol.

5) La aplicación carga los campos para documentación de tabla.

6) El actor escoge el tipo de alias de tabla y presiona el botón de agregar alias.

7) La aplicación evalúa el tipo de alias, si es de usuario activa el campo de texto, si es

de ontología véase cu2.1_escogerAliasTabla.

8) El actor rellena o escoge el alias de tabla.

9) El actor rellena la descripción y condición de publicación de tabla.

10) El actor pulsa el nombre de una columna de la tabla en el árbol.

11) La aplicación carga los campos para documentación de columna.

12) El actor escoge el tipo de alias de columna y presiona el botón de agregar alias.

13) La aplicación evalúa el tipo de alias, si es de usuario activa el campo de texto, si es

de ontología véase cu2.2_escogerAliasColumna.

14) El actor rellena o escoge el alias de columna.

15) El actor presiona el botón de agregar unidad de medida.

16) Véase cu2.3_escogerUnidadMedida.

17) El actor escoge la unidad de medida.

18) El actor rellena los demás campos de documentación de columna.

19) El actor repite los pasos 10 al 18 con cada columna de la tabla.

20) El actor repite los pasos 4 al 19 con cada tabla de la base de datos.

Flujo

alternativo:

El actor puede documentar en cualquier orden, escogiendo el elemento de la base de

datos en el árbol. El orden presentado sólo es un orden sugerido.

Poscondición: La aplicación almacena en memoria la información de la documentación de metadatos.

Incluye: cu2.1_escogerAliasTabla, cu2.2_escogerAliasColumna y cu2.3_escogerUnidadMedida.


49

Tabla 5.3. Descripción de cu2.1_escogerAliasTabla

cu2.1_escogerAliasTabla


Descripción: Permite escoger alias de tabla.

Precondición: Que el actor escoja alias de tabla como de ontología y presione el botón de agregar alias.

Flujo normal: 1) La aplicación abre el formulario de escoger alias de tabla.

2) La aplicación extrae las clases de la ontología y las muestra en una vista de árbol.

3) El actor elige una de las clases.

4) La aplicación muestra la descripción de la clase en un campo de texto.


Flujos

alternativos

(fa):

2) (fa1) La aplicación no puede acceder a la ontología o no es un archivo de ontología

OWL DL válido, mandando un mensaje de error y cerrando el formulario de escoger

alias de tabla.


cierra el formulario de escoger alias de tabla.

Poscondición: La aplicación vincula el alias de tabla con la clase elegida y reemplaza la descripción de la

tabla por la de la clase.

Tabla 5.4. Descripción de cu2.2_escogerAliasColumna

cu2.2_escogerAliasColumna


Descripción: Permite escoger alias de columna.

Precondición: Que el actor escoja alias de columna como de ontología y presione el botón de agregar

alias.

Flujo normal: 1) La aplicación abre el formulario de escoger alias de columna.

2) La aplicación extrae las clases de la ontología y las muestra en una vista de árbol.

3) El actor elige una de las clases.

4) La aplicación muestra la descripción de la clase en un campo de texto, extrae las

propiedades de tipo de dato de la clase y las muestra en otra vista de árbol

5) El actor elige una de las propiedades.

6) La aplicación muestra la descripción de la propiedad en un campo de texto.


Flujos

alternativos

(fa):

2) y 4) (fa1) La aplicación no puede acceder a la ontología o no es un archivo de

ontología OWL DL válido, mandando un mensaje de error y cerrando el formulario

de escoger alias de columna.


cierra el formulario de escoger alias de columna.

Poscondición: La aplicación vincula el alias de columna con la propiedad elegida y reemplaza la

descripción de la columna por la de la propiedad.


50

Tabla 5.5. Descripción de cu2.3_escogerUnidadMedida

cu2.3_escogerUnidadMedida


Descripción: Permite escoger unidad de medida.

Precondición: Que el actor presione el botón de agregar unidad de medida a una columna.

Flujo normal: 1) La aplicación abre el formulario de escoger unidad de medida.

2) La aplicación extrae del archivo de medición los sistemas de unidades y los muestra

en una vista de árbol.

3) El actor elige uno de los sistemas de unidades.

4) La aplicación extrae del archivo de medición las magnitudes del sistema de unidades

y las muestra en otra vista de árbol.

5) El actor elige una de las magnitudes.

6) La aplicación extrae del archivo de medición las unidades de la magnitud y las

muestra en otra vista de árbol.

7) El actor elige una de las unidades.


Flujos

alternativos

(fa):

2), 4) y 6) (fa1) La aplicación no puede acceder o leer el archivo de medición, mandando

un mensaje de error y cerrando el formulario de escoger unidad de medida.


cierra el formulario de escoger unidad de medida.

Poscondición: La aplicación vincula la unidad de medida de columna con la unidad de medida elegida.

Tabla 5.6. Descripción de cu3_generarReporte

cu3_generarReporte


Descripción: Genera un reporte de documentación.


Flujo normal: 1) El actor pulsa el botón de generar reporte de documentación.

2) La aplicación toma la información de los metadatos y su documentación y genera un

reporte en un archivo temporal.

3) La aplicación invoca la apertura del archivo en el navegador Web predeterminado.

Flujo

alternativo:

2) La aplicación no puede crear el archivo temporal y manda mensaje de error.

Poscondición: El reporte de documentación es abierto en el navegador Web predeterminado.


51

Tabla 5.7. Descripción de cu4_generarMapeoD2RQ

cu4_generarMapeoD2RQ


Descripción: Genera un archivo de mapeo D2RQ.


Flujo normal: 1) El actor pulsa el botón de generar mapeo.

2) La aplicación muestra un formulario con campos para la ruta del archivo de salida y

la contraseña de la base de datos.

3) El actor rellena los campos y presiona el botón para aceptar y generar mapeo.

4) La aplicación genera el archivo de mapeo D2RQ en el siguiente orden:

i. Cabecera y datos de conexión.

ii. Clases para cada tabla, excepto aquellas de relación n:m.

iii. Propiedades para cada columna no llave foránea.

iv. Propiedades con reunión para cada columna llave foránea.

v. Propiedades n:m para cada tabla de relación n:m.

vi. Propiedades con reuniones múltiples, de acuerdo al análisis de las

propiedades objeto de la ontología de dominio y la documentación de

tablas.

5) La aplicación manda mensaje de generación exitosa.

Flujos

alternativos

(fa):

3) (fa1) El actor presiona el botón de cancelar y la aplicación cierra el formulario para

generar mapeo.

4) (fa2) Ocurre un error y la aplicación manda mensaje de error en la generación.

Poscondición: El archivo de mapeo D2RQ es generado y guardado en la ruta elegida por el actor.

Tabla 5.8. Descripción de cu5_guardarProyecto

cu5_guardarProyecto


Descripción: Guarda un archivo de proyecto Doc-D2R.


Flujo normal: 1) El actor pulsa el botón de guardar proyecto.

2) Si es un proyecto sin guardar, la aplicación muestra un dialogo de guardar archivo.

3) El actor escoge la ruta de guardado del archivo.

4) La aplicación guarda la información de conexión, metadatos y documentación en un

archivo de proyecto Doc-D2R en la ruta elegida por el actor.

Flujos

alternativos

(fa):

2) (fa1) Si es un proyecto ya guardado anteriormente, la aplicación toma la ruta ya

establecida (continúa en el punto 4 del flujo normal).

3) (fa3) El actor presiona el botón de cancelar y la aplicación cierra el dialogo de

guardar archivo.

4) (fa2) Ocurre un error y la aplicación manda un mensaje de error en el guardado.

Poscondición: El archivo de proyecto Doc-D2R es generado y guardado en la ruta elegida por el actor.


52

Tabla 5.9. Descripción de cu6_abrirProyecto

cu6_abrirProyecto


Descripción: Abre un archivo de proyecto Doc-D2R.

Precondición: No tiene

Flujo normal: 1) El actor pulsa el botón de abrir proyecto.

2) La aplicación muestra un diálogo de abrir archivo de proyecto Doc-D2R.

3) El actor busca la ruta y escoge el archivo.

4) La aplicación abre el archivo, muestra los metadatos de la base de datos, carga las

propiedades del proyecto y la información de documentación.

Flujos

alternativos

(fa):

2) (fa1) Si un proyecto ya está cargado, la aplicación manda un mensaje de

confirmación avisando que se perderán los cambios.

3) (fa1) El actor confirma el mensaje (continúa en el punto 2 del flujo normal).

3) (fa2) El actor presiona el botón de cancelar y la aplicación cierra el dialogo de abrir

archivo.

4) (fa2) Ocurre un error y la aplicación manda un mensaje de error al abrir el archivo.

Poscondición: El archivo de proyecto Doc-D2R elegido por el actor es cargado en la aplicación.

5.2. Análisis y diseño

En esta sección se incluye desde la definición de los componentes que integran Doc-D2R hasta la

especificación del formato de documento de proyecto.

5.2.1. Componentes

De acuerdo al análisis de los casos de uso, se contemplaron los siguientes componentes:

Módulo de extracción. Contribuye directamente en los casos de uso 1, 2.1, 2.2 y 2.3, se

encarga de las siguientes funcionalidades:

o Extraer los metadatos de la base de datos.

o Extraer la taxonomía de clases y propiedades de la ontología de dominio.

o Extraer las unidades de medida del archivo de medición.

Módulo de configuración. Contribuye directamente en los casos de uso 1, 2, 3, 5 y 6, se

encarga de las siguientes funcionalidades:

o Configurar, guardar y abrir proyectos Doc-D2R.

o Administrar la información de documentación.

o Generar el reporte de documentación.

Módulo de generación. Contribuye directamente en el caso de uso 4, se encarga de las

siguientes funcionalidades:

o Detectar propiedades con reuniones múltiples.

o Generar el mapeo D2RQ.

Los módulos de extracción y configuración se agrupan en un módulo denominado “módulo de

documentación”, como se observa en el diagrama de componentes de la Figura 5.2.


53

Figura 5.2. Diagrama de componentes de Doc-D2R

5.2.2. Diagramas de actividades

Se diseñaron diagramas de actividades para cada caso de uso detallando las acciones que realiza

cada módulo. Estos diagramas son mostrados a partir de la Figura 5.3 hasta la Figura 5.11.

Figura 5.3. Diagrama de actividades de cu1_configurarProyecto


54

Figura 5.4. Diagrama de actividades de cu2_documentar


55

Figura 5.5. Diagrama de actividades de cu2.1_escogerAliasTabla

Figura 5.6. Diagrama de actividades de cu2.2_escogerAliasColumna


56

Figura 5.7. Diagrama de actividades de cu2.3_escogerUnidadMedida

Figura 5.8. Diagrama de actividades de cu3_generarReporte


57

Figura 5.9. Diagrama de actividades de cu4_generarMapeoD2RQ

Figura 5.10. Diagrama de actividades de cu5_guardarProyecto


58

Figura 5.11. Diagrama de actividades de cu6_abrirProyecto

5.2.3. Esquema XML de documento de proyecto

Este esquema define la estructura del archivo XML que guarda la información de un proyecto Doc-

D2R, incluye:

Capacidad para guardar la información de conexión.

Capacidad para guardar la ruta de la ontología de dominio y el tipo de ubicación (Web o

desde archivo).

Capacidad para guardar los metadatos de la base de datos y la información de

documentación.

La Figura 5.12 muestra la estructura general del archivo XSD (XML Schema Definition) con las

características antes mencionadas.

Figura 5.12. Estructura general del esquema XSD de documento de proyecto

La subestructura de la información de conexión (Figura 5.13) incluye:

claseDriver. Clase del controlador JDBC.

Usuario. Usuario de la base de datos.

Conexión. Cadena de conexión a la base de datos.


59

Figura 5.13. Elemento conexión del esquema XSD de documento de proyecto

El elemento que almacena la información de base de datos contiene (Figura 5.14):

nombreSMBD. Nombre del Sistema Manejador de Base de Datos.

versionSMBD. Version del SMBD.

nombreBD. Nombre de la base de datos.

descripcionBD. Descripción de la base de datos.

totalTablas. Número total de tablas.

totalColumnasBD. Número total de columnas.

totalPKBD. Número total de llaves primarias.

totalFKBD. Número total de llaves foráneas.

tabla. Subestructura que contiene la información de las tablas de la base de datos, incluye

los siguientes elementos (Figura 5.15):

o esTablaEnlace. Valor booleano que identifica si una tabla es de enlace. Una tabla

es de enlace si contiene sólo dos columnas, dos llaves primarias y dos llaves

foráneas, estas tablas constituyen una relación n:m.

o nombreTabla. Nombre de la tabla.

o aliasTabla. Alias de la tabla, contiene dos atributos: tipoAlias para guardar si es de

usuario o de ontología y claseOntología para guardar la clase con la cual está

relacionado.

o descripcionTabla. Descripción de la tabla.

o totalColumnasTabla. Número de columnas en la tabla.

o totalPKTabla. Número de llaves primarias en la tabla.

o totalFKTabla. Número de llaves foráneas en la tabla.

o esTablaPublicable. Valor booleano que identifica si la tabla es publicable1.

o condicionPublicaciónTabla. Condición de publicación de la tabla, generalmente

ligada a un filtro por valores en las columnas que contiene.

o columna. Subestructura que contiene la información de las columnas de la tabla,

constituida por los siguientes elementos (Figura 5.16):

nombreCol. Nombre de la columna.

1 Sin importar el valor de este elemento, las tablas que constituyen una relación n:m sólo se publican como propiedades

n:m.


60

aliasCol. Alias de la columna, contiene dos atributos: tipoAlias para

guardar si es obtenido del usuario o de la ontología y claseOntología para

guardar la clase con la cual está relacionado.

descripcionCol. Descripción de la columna.

tipoDato. Nombre del tipo de dato de la columna en el SMBD, contiene el

atributo numTipoJDBC que guarda el número del tipo de dato JDBC

equivalente.

esNulo. Valor booleano que identifica si la columna admite valores nulos.

precision. Tamaño de la columna.

escala. Cantidad de dígitos decimales.

mascaraFormato. Mascara de formato de la columna.

unidadMedida. Unidad de medida de la columna, contiene los atributos

sistema y magnitud para guardar el sistema de unidades y la magnitud

correspondiente.

valorDefault. Valor predeterminado de la columna.

ejemploValor. Valor de ejemplo de la columna.

esColumnaPublicable. Valor booleano que identifica si la columna es

publicable.

condicionPublicacionColumna. Condición de publicación de la columna.

valorPermitido. Listado de valores permitidos para la columna.

equivalenciaValor. Subestructura que guarda el listado de equivalencias

entre los valores de la base de datos y los valores de la ontología (Figura

5.17).

o PK. Contiene el listado de los nombres de las columnas que son llaves primarias.

o FK. Subestructura que contiene la información de las llaves foráneas de la tabla

(Figura 5.18), incluye: nombre de la llave foránea, nombre de la tabla relacionada,

y listado de columnas origen y destino.

Figura 5.14. Elemento baseDatos del esquema XSD de documento de proyecto


61

Figura 5.15. Elemento tabla del esquema XSD de documento de proyecto

Figura 5.16. Elemento columna del esquema XSD de documento de proyecto


62

Figura 5.17. Elemento equivalenciaValor del esquema XSD de documento de proyecto

Figura 5.18. Elemento FK del esquema XSD de documento de proyecto

Los documentos de proyecto son archivos con estructura XML creados a partir del esquema

definido, sin embargo no son guardados con extensión .xml sino con la extensión .dbd, esto con el

fin de identificarlos y diferenciarlos de mejor forma en el sistema de archivos.

5.3. Implementación

En esta sección se describe el entorno de desarrollo, las clases y los formularios implementados.

5.3.1. Entorno de desarrollo

Lenguaje de programación: Java SE 6

Se optó por este lenguaje debido al requerimiento multiplataforma, la posibilidad de

reutilizar código fuente de D2RQ y la necesidad de utilizar la API Jena para la manipulación

de la ontología de dominio. El entorno de programación usado fue Netbeans IDE 6.5.

Librerías auxiliares:

JENA 2.5.6. Empleada para extraer la taxonomía de clases y propiedades de la ontología

OWL DL de dominio.

XMLBeans 2.4.0. Permite generar clases Java partiendo de un esquema XML definido. Es

utilizada para generar las clases que manipulan la información de proyecto y de unidades

de medida. Permite crear y abrir archivos XML de proyecto.

MySQL JDBC Driver 5.1.6. Utilizada en la extracción de metadatos de bases de datos

MySQL.

Microsoft SQL Server 2005 JDBC Driver 1.2. Utilizada en la extracción de metadatos de

base de datos SQL Server.


63

5.3.2. Clases

Cada módulo contemplado se implementó como paquete. El diagrama de clases de la Figura 5.21

muestra las clases, y las relaciones existentes entre ellas, que corresponden a cada paquete1.

En total se implementaron 7 paquetes: el paquete base docbdd2r; los paquetes que representan

los módulos, documentacion, configuracion, extraccion y generacion; y los paquetes de

formularios y otros. La estructura de paquetes se presenta en la Figura 5.19.

El listado con la descripción de las principales clases2 se muestra desde la Figura 5.20 hasta la

Figura 5.26.

Figura 5.19. Estructura de paquetes de Doc-D2R

ConexionBD

Ruta de paquete:

docbdd2r.documentacion.

extraccion

Descripción:

Implementa la conexión a

una base de datos.

Figura 5.20. Clase ConexionBD

Figura 5.21. Diagrama de clases de Doc-D2R

1 El nombre del paquete se observa bajo cada nombre de clase. 2 Las figuras sólo muestran la interfaz de la clase, es decir, el conjunto de atributos y métodos públicos. Para mayor

información puede consultarse la documentación de clases de Doc-D2R, disponible en la biblioteca del Cenidet.


64


65

BaseDatos

Ruta de paquete:

docbdd2r.documentacion.extraccion

Descripción:

Implementa la obtención de los metadatos de la base de

datos.

Figura 5.22. Clase BaseDatos

Ontologia

Ruta de paquete:


extraccion

Descripción:

Implementa la recuperación de las

clases, propiedades y

descripciones de una ontología

OWL.

Figura 5.23. Clase Ontologia

UnidadMedida

Ruta de paquete:


extraccion

Descripción:

Implementa la recuperación de

sistemas, magnitudes y

unidades de medida. Figura 5.24. Clase UnidadMedida

GeneradorMapeo

Ruta de paquete:

docbdd2r.generacion

Descripción:

Implementa la generación del

mapeo D2R.

Figura 5.25. Clase GeneradorMapeo


66

ProyectoDocBD

Ruta de paquete:

docbdd2r.configuracion

Descripción:

Administra el documento XML del proyecto y recupera los datos para los modelos de los

componentes del formulario principal.

Figura 5.26. Clase ProyectoDocBD


67

5.3.3. Formularios

frmPrincipalView - Formulario principal

Una vez cargado o creado un nuevo proyecto, presenta el árbol de la jerarquía de tablas y

columnas y cambia la vista de detalle de acuerdo a la selección de un nodo (base de datos, tabla o

columna). Tiene una barra de menús y de herramientas con las opciones, entre otras, para crear,

cargar y guardar proyecto, generar documentación y generar mapeo D2RQ (Figura 5.27).

Figura 5.27. Formulario principal

frmConfig - Formulario de propiedades de un proyecto nuevo o existente

Permite especificar o actualizar los parámetros de conexión, probar la conexión y establecer la

ruta y tipo de ubicación de la ontología de dominio (Figura 5.28).


68

Figura 5.28. Formulario de propiedades de un proyecto nuevo o existente

frmMapeo - Formulario para definir propiedades de mapeo

Permite escribir la contraseña de la base de datos y elegir archivo de salida del mapeo (Figura

5.29).

Figura 5.29. Formulario para definir propiedades de mapeo

frmEscogerAlias - Formulario para escoger alias de tabla o de columna

Carga el árbol de jerarquía de clases y actualiza el árbol de propiedades de acuerdo al nodo

seleccionado (Figura 5.30).


69

Figura 5.30. Formulario para escoger alias de tabla o de columna

frmEscogerUnidadMedida - Formulario para escoger unidad de medida

Carga el árbol de sistemas, actualiza el árbol de magnitudes de acuerdo al sistema elegido y

actualiza el árbol de unidades de acuerdo a la magnitud y sistema elegido (Figura 5.31).

Figura 5.31. Formulario para escoger unidad de medida


70

5.4. Pruebas

En esta sección se presenta un resumen del plan de pruebas, de la especificación de casos y

procedimientos de prueba y de los resultados obtenidos.

5.4.1. Plan de pruebas

Introducción

Basado en el estándar IEEE 829, se define el plan de pruebas para verificar el funcionamiento de

Doc-D2R, esta herramienta es el primer producto de software del proyecto de tesis.

Elementos a probar

Se probarán las siguientes funcionalidades:

Documentación. Desde la extracción de metadatos hasta la generación del archivo de

proyecto.

Mapeo D2R. Generación del mapeo D2R.

Las pruebas se aplicarán a la primera versión (beta) del sistema Doc-D2R. La inspección de código

fuente no se incluye en el plan de pruebas ya que será tarea del programador al terminar la

codificación de cada clase.

Características a probar

La siguiente lista presenta el nombre, precedido del identificador, de cada uno de los casos de

prueba y las características que comprenden:

DOCBD_CP-01 Carga de metadatos:

o Conexión a base de datos.

o Presentación de metadatos de base de datos.

DOCBD_CP-02 Carga de ontología y archivo de medición:

o Carga de taxonomía de clases y propiedades de la ontología de dominio.

o Carga de los sistemas y unidades de medida tomados del archivo XML de

medición.

DOCBD_CP-03 Documentación de metadatos:

o Documentación de columnas.

o Documentación de tablas.

DOCBD_CP-04 Presentación del reporte de documentación:

o Presentación en pantalla del reporte de documentación.

DOCBD_CP-05 Generación de mapeo D2RQ:

o Creación de archivo de mapeo.

o Definición de cabecera, parámetros de conexión, clases, propiedades sin reunión,

propiedades con reunión simple, propiedades n:m y propiedades con 3 o más

reuniones.

DOCBD_CP-06 Generación de archivo de proyecto:

o Creación de archivo de proyecto.

o Carga de archivo de proyecto.


71

Características excluidas de las pruebas

Características de rendimiento, por ejemplo: tiempos de carga de interfaz, de extracción

de metadatos, de obtención de clases y propiedades de ontología de dominio y de

generación de mapeos D2RQ.

Cualquier otra no mencionada en los casos de prueba.

Enfoque

Las pruebas son de carácter funcional o de caja negra, se evaluará el sistema de acuerdo al

comportamiento o salida previstos dada una determinada entrada. El enfoque para cada caso de

prueba es el siguiente:

Carga de metadatos. Involucra el establecimiento de una conexión de base de datos y el

aviso de conexión fallida o en caso de conexión exitosa la presentación en pantalla de los

metadatos de la base de datos.

Carga de ontología y archivo de medición. Implica la carga de la taxonomía de clases y

propiedades de la ontología de dominio y la carga de los sistemas, magnitudes y unidades

de medida tomados del archivo de medición.

Documentación de metadatos. Comprende el establecimiento de las características de los

metadatos de tablas y columnas, ya sea de manera manual o relacionando con clases o

propiedades de la ontología de dominio.

Presentación del reporte de documentación. Presentación en pantalla del reporte de

documentación.

Generación de mapeo D2RQ. Involucra la generación de clases y propiedades D2RQ de

acuerdo a la documentación y la creación y presentación en pantalla del archivo de

mapeo.

Generación de archivo de proyecto. Implica la creación y recarga del archivo de proyecto.

Criterios de éxito/fallo

En cada uno de los procedimientos de casos de prueba se describen los resultados esperados. Se

considera que una prueba ha pasado con éxito cuando los resultados obtenidos coinciden con los

esperados. Por el contrario, la discordancia supone un fallo en la prueba.

Escenario de prueba Tabla 5.10. Características de escenario de prueba

LAP

Hardware Tipo: Computadora portátil

Procesador: AMD Turion 64 X2 TL-60, 2.00 GHz

Memoria RAM: 3 GB

Disco duro: 250 GB

Software Sistema operativo: Windows Vista Home Premium SP1

SMBD (herramientas cliente y servidor): MySQL Server 5.0

Base de Datos: SiCEWin_cut (versión recortada de la base de datos SiCEWin, véase diagrama en el Anexo A)

Doc-D2R Beta

Java SE Development Kit (JDK), version 6


72

5.4.2. Especificación de casos de prueba y resultados

5.4.2.1. Caso de prueba 01: Carga de metadatos

Identificador del caso de prueba

DOCBD_CP-01


a) Conexión a base de datos.

i. Conexión fallida.

ii. Conexión exitosa.

b) Presentación de metadatos de base de datos.

Entradas Tabla 5.11. Entradas para el caso de prueba 01

Característica Entrada Observaciones

a.i. Parámetros de conexión (clase de

controlador JDBC, nombre de

usuario, contraseña y cadena de

conexión).

Todos los valores son en cadena de texto.

Se deben estipular uno o más de los

parámetros de forma errónea (por ej.:

contraseña incorrecta, cadena de conexión

inválida, etc.).

a.ii. Parámetros de conexión. Se deben estipular los valores correctos para la

conexión a la base de datos SiCEWin_cut del

servidor MySQL en LAP.

b. No tiene. Es la salida de a.ii.

Salidas Tabla 5.12. Salidas para el caso de prueba 01

Característica Salida Observaciones

a.i. Aviso de error. Presentación en pantalla del aviso, al aceptar el aviso

debe permitir cambiar los valores de conexión y

reintentar.

a.ii. Presentación de

metadatos.

Presentación en pantalla de la jerarquía de tablas y

columnas de la base de datos.

b. No tiene. Es la salida de a.ii, al seleccionar un nodo de tabla o

columna se debe presentar en pantalla el panel de

documentación conteniendo las características del

elemento1.

Escenario de prueba

Mismo escenario para todos los casos, véase sección 5.4.1.

1 Características definidas en la sección 4.4.2.


73

Procedimiento de prueba

Ejecutar Doc-D2R.

Abrir diálogo de creación de nuevo proyecto (presionar botón Nuevo de la barra de

herramientas).

Establecer parámetros de conexión no válidos (servidor erróneo en cadena de conexión).

Probar conexión y recibir mensaje de error.

Establecer cadena de conexión correcta.

Aceptar.

Verificar la carga del árbol de metadatos y la pestaña de detalle de base de datos.

Seleccionar nodo de tabla alumno y verificar la carga de la pestaña de detalle de tabla.

Seleccionar nodo de columna alumno.Matricula y verificar la carga de la pestaña de detalle

de columna.

Dependencias de caso de prueba

No tiene.

Resultados1

Prueba exitosa

Figura 5.32. (DOCBD_CP-01) Prueba de conexión con cadena de conexión incorrecta y recepción de mensaje de error

1 Para cada caso de prueba se muestran las pantallas de resultados más relevantes en la ejecución de cada uno de los

procedimientos. Cada figura describe la acción desarrollada.


74

Figura 5.33. (DOCBD_CP-01) Conexión exitosa, carga del árbol y de la pestaña de detalle de base de datos

Figura 5.34. (DOCBD_CP-01) Selección de nodo de tabla alumno, carga de la pestaña de detalle de tabla


75

Figura 5.35. (DOCBD_CP-01) Selección de nodo de columna alumno.Matricula, carga de pestaña de detalle de columna

5.4.2.2. Caso de prueba 02: Carga de ontología y archivo de medición


DOCBD_CP-02


a) Carga de taxonomía de clases y propiedades de la ontología de dominio.

b) Carga de los sistemas y unidades de medida tomados del archivo de medición.



a. Archivo OWL o dirección URL de

la ontología de dominio.

Ruta de archivo elegida a partir de un diálogo

de abrir archivo. Dirección URL escrita

directamente a partir de una caja de texto.

Accesible a partir del dialogo de propiedades

de proyecto.

b. No tiene. Doc-D2R obtiene directamente la ruta del

archivo de medición.


76



a. Carga y presentación de la

taxonomía de la ontología de

dominio.

Se ejecuta a partir de la primera elección de

alias de tabla o columna. Se carga el formulario

de elección de alias y se presenta la taxonomía

de clases de la ontología de dominio. Debe

verificarse que incluya toda la jerarquía de

clases definida en la ontología de dominio. Al

seleccionar un nodo de clase se debe presentar

el listado de las propiedades de tipo de dato

relacionadas.

b. Carga y presentación de los

sistemas, magnitudes y unidades

de medida.

Llenado de los valores en la ventana de

unidades de medida, accesible desde el botón

de elección de unidad de medida del panel de

documentación de metadatos de columnas.

Debe verificarse que los listados de sistemas,

magnitudes y unidades contengan todos los

valores definidos en el archivo de medición.


Continuar desde: DOCBD_CP-01.

Elegir documentar alias de columna desde ontología (pestaña de detalle de columna,

opción De ontología).

Pulsar agregar alias de columna y recibir mensaje de error de ontología no definida.

Abrir diálogo de propiedades de proyecto (elegir menú Archivo/Propiedades).

Cambiar a la pestaña de ontología de dominio.

Elegir ontología desde la Web.

Establecer una dirección URL de una ontología inexistente.

Aceptar.

Pulsar agregar alias de columna y recibir mensaje de error de carga de ontología.

Abrir diálogo de propiedades de proyecto, pestaña de ontología de dominio.

Establecer una dirección URL correcta de la ontología de dominio.

Aceptar.

Pulsar agregar alias de columna, verificar la apertura del formulario de elección de alias y

la carga del árbol de clases de la ontología.

Seleccionar nodo de clase Persona/Alumno, verificar la carga de la descripción de clase y

del árbol de propiedades.

Seleccionar nodo de propiedad tieneSexo, verificar la carga de la descripción de propiedad.

Cancelar.

Pulsar agregar unidad de medida, verificar la apertura del formulario de elección de

unidad de medida y la carga del árbol de sistemas de medición.

Seleccionar el primer nodo de sistema, verificar la carga del árbol de magnitudes.


77

Seleccionar nodo de magnitud Longitud, verificar la carga de unidades de medida.

Cancelar.


Dependencia con el caso 01.

Resultados

Prueba exitosa

Figura 5.36. (DOCBD_CP-02) Mensaje de aviso de ontología no definida

Figura 5.37. (DOCBD_CP-02) Mensaje de error de carga de ontología al dar una URL inexistente

Figura 5.38. (DOCBD_CP-02) Verificación de la apertura del formulario y la carga de las clases, propiedades y

descripciones


78

Figura 5.39. (DOCBD_CP-02) Verificación de la apertura del formulario y la carga de sistemas, magnitudes y unidades

5.4.2.3. Caso de prueba 03: Documentación de metadatos


DOCBD_CP-03


a) Documentación de tablas.

b) Documentación de columnas.



a. Alias de tabla, descripción, estado y condición

de publicación.

Accesibles a partir de la pestaña

de documentación de tabla.

b. Alias de columna, descripción, formato, unidad

de medida, valor por defecto, ejemplo de dato,

valores permitidos, equivalencias de valores,

estado y condición de publicación.

Accesibles a partir de la pestaña

de documentación de columna.


Carac. Salida Observaciones

a. No tiene. Revisar que el alias de tabla sea vinculado correctamente con la clase elegida en el

formulario. Debe verificarse que no puedan ser documentadas dos tablas con el

mismo alias.

b. No tiene. Revisar que el alias de columna sea vinculado correctamente con la propiedad

elegida en el formulario. Revisar que la unidad de medida sea vinculada

correctamente con la unidad elegida en el formulario.


79



Seleccionar nodo de tabla alumno.

Elegir documentar alias de tabla desde ontología.

Pulsar agregar alias de tabla y verificar la apertura del formulario de elección de alias.

Seleccionar nodo de clase Persona/Alumno.

Deseleccionar el campo de reemplazar descripción.

Aceptar.

Verificar la actualización del alias de alumno en la pestaña de detalle de tabla.


Seleccionar el campo de reemplazar descripción.

Verificar la actualización de la descripción en la pestaña de detalle de tabla.

Seleccionar nodo de columna alumno.Sexo.

Elegir documentar alias de columna desde ontología

Seleccionar nodo de propiedad tieneSexo.

Aceptar

Verificar la actualización del alias y descripción de columna alumno.Sexo y la carga de los

valores de ontología en el listado de equivalencias.

Definir la equivalencia entre el valor de ontología “femenino” y el valor de base de datos

“mujer”.

Definir la equivalencia entre el valor de ontología “masculino” y el valor de base de datos

“hombre”.

Establecer condición de publicación a alumno.Sexo=”hombre”.

Seleccionar nodo de tabla alumno.

En el listado de columnas, intentar deseleccionar el campo de publicación de la columna

Matricula y verificar mensaje de que no es posible hacerlo.

Deseleccionar los campos de publicación de las demás columnas salvo las columas: Sexo,

Nombre y ApellidoP.

Seleccionar nodo de tabla materia.


Seleccionar nodo de clase Materia.

Aceptar.

Verificar la actualización del alias y descripción de tabla Materia.

Seleccionar nodo de tabla grupo.

Deseleccionar campo de publicación (repetir para las tablas: grupoprofe, inscripción y

profesor).


Dependencia con el caso 01 y 02.


80

Resultados

Prueba exitosa

Figura 5.40. (DOCBD_CP-03) Actualización del alias y descripción de la tabla alumno

Figura 5.41. (DOCBD_CP-03)Actualización del alias y descripción de alumno.Sexo y la carga de los valores de equivalencia


81

Figura 5.42. (DOCBD_CP-03) Mensaje de estado de publicación de columna llave no puede ser modificado

Figura 5.43. (DOCBD_CP-03) Actualización del alias y descripción de tabla Materia


82

5.4.2.4. Caso de prueba 04: Presentación del reporte de documentación


DOCBD_CP-04


a) Presentación en pantalla del reporte de documentación.



a. Archivo XML de proyecto. Doc-D2R debe tomar el documento de proyecto actual

y guardarlo con extensión “xml” en la carpeta

temporal predeterminada.



a. Presentación en pantalla

del reporte.

La vista debe abrirse en una instancia del navegador

web predeterminado.


Pulsar botón generar documentación de la barra de herramientas del formulario principal.


Dependencia con el caso 01. Para

obtener un reporte más completo es

necesario el caso 03.

Resultados

Prueba exitosa

Figura 5.44. (DOCBD_CP-04) Reporte de documentación abierto en navegador Web


83

5.4.2.5. Caso de prueba 05: Generación de mapeo D2RQ


DOCBD_CP-05


a) Creación y presentación en pantalla del archivo de mapeo D2RQ.



a. Documento de proyecto. Doc-D2R toma el documento de proyecto actual.



a. Presentación en pantalla

del reporte.

Debe verificarse la correcta definición de cabecera,

parámetros de conexión, clases, propiedades sin

reunión, propiedades con reunión simple, propiedades

n:m y propiedades con 3 o más reuniones. Debe

ejecutarse el servidor D2R con el mapeo generado y

verificar que en la navegación en cada tabla no genere

ningún error.



Abrir diálogo de creación de generación de mapeo (presionar botón Generación Mapeo de

la barra de herramientas).

Establecer contraseña de base de datos y ruta del archivo de salida.

Aceptar.

Verificar mensaje de generación exitosa.

Abrir archivo de mapeo generado, verificar:

o Definición de cabecera.

o Definición de mapeo de base de datos.

o Definición de clase alumno y de propiedades adicionales relacionadas con la

documentación de alias (URI del alias utilizado: rdf:isDefinedBy, descripción:

rdf:comment).

o Definición de propiedades de la clase alumno. Revisar la condición de publicación

y tabla de transformación de la propiedad tieneSexo.

o Definición de propiedades de clase alumno inferidas de la ontología.

o Definición de clase materia y de propiedades adicionales relacionadas con la

documentación de alias.

o Definición de propiedades de clase materia.

Ejecutar servidor D2R con el mapeo generado, verificar que no reporte errores.


84

Abrir navegador Web e ingresar a la página del servidor D2R, verificar que sólo estén

publicadas las tablas de alumno y materia.


Dependencia con el caso 01. Para obtener un mapeo más completo es necesario el caso 03.

Resultados

Prueba exitosa

Figura 5.45. (DOCBD_CP-05) Mensaje de generación exitosa

Figura 5.46. (DOCBD_CP-05) Definición de cabecera

Figura 5.47. (DOCBD_CP-05) Definición de mapeo de base de datos


85

Figura 5.48. (DOCBD_CP-05) Definición de clase alumno y de propiedades adicionales

Figura 5.49. (DOCBD_CP-05) Definición de propiedades y condición de publicación y tabla de transformación para

“alumno_tienesexo”

Figura 5.50. (DOCBD_CP-05) Definición de propiedades de clase alumno inferidas de la ontología


86

Figura 5.51. (DOCBD_CP-05) Definición de clase materia y de propiedades adicionales

Figura 5.52. (DOCBD_CP-05) Definición de propiedades de clase materia


87

Figura 5.53. (DOCBD_CP-05) Ejecución de servidor D2R con el mapeo generado

Figura 5.54. (DOCBD_CP-05) Navegación Web de la base de datos publicada


88

5.4.2.6. Caso de prueba 06: Generación de archivo de proyecto


DOCBD_CP-06


a) Creación y guardado de archivo de proyecto.

b) Carga de archivo de proyecto.



a. Documento de proyecto. Doc-D2R toma el documento de proyecto actual.

b. Archivo con extensión “dbd”. No tiene.



a. Archivo con extensión “dbd”. El archivo debe guardar una estructura XML

con los datos del proyecto.

b. Presentación en pantalla de la

jerarquía de tablas y columnas de

la base de datos y de la pestaña

de detalle de base de datos.

Doc-D2R debe validar el formato del archivo y

mostrar mensaje de error en caso de que no lo

sea.



Abrir diálogo de guardado de proyecto (presionar botón Guardar de la barra de

herramientas).

Elegir ruta y nombre de archivo.

Guardar.

Verificar que el título del formulario muestre el nombre del archivo.

Cerrar proyecto actual (elegir menú Archivo/Cerrar).

Verificar la apertura de ventana de advertencia de perder cambios sin guardar.

Aceptar.

Verificar el cierre del proyecto.

Abrir diálogo de abrir proyecto (presionar botón Abrir en la barra de herramientas).

Buscar la ruta y elegir el archivo previamente guardado.

Aceptar.

Seleccionar el nodo de tabla alumno y verificar que el alias, descripción y valores de

publicación de columnas sean los definidos previamente.

Seleccionar el nodo de columna alumno.Sexo y verificar que el alias, descripción,

equivalencias de valores y condición de publicación sean los definidos previamente.


89


Dependencia con el caso 01. Para obtener un archivo más completo es necesario el caso 03.

Resultados

Prueba exitosa

Figura 5.55. (DOCBD_CP-06) Verificación del título del formulario con el nombre del archivo

Figura 5.56. (DOCBD_CP-06) Mensaje de advertencia de perder cambios sin guardar

Figura 5.57. (DOCBD_CP-06) Verificación del cierre del proyecto


90

Figura 5.58. (DOCBD_CP-06) Verificación de carga de datos de columna alumno.Sexo

91

6. Capítulo 6

Query-D2R – Software de consulta

Este capítulo presenta un resumen del proceso de desarrollo de Query-D2R.

6.1. Especificación de requerimientos

En esta sección se incluye la descripción de la herramienta, el listado de requerimientos y casos de

uso, entre otros.

6.1.1. Descripción

Query-D2R es una herramienta que permitirá construir consultas, transformarlas a SPARQL y

gestionar su ejecución en servidores D2R. Query-D2R parte del hecho de que los servidores

utilizan mapeos generados por Doc-D2R considerando la documentación previa.

6.1.2. Usuarios

La herramienta no tiene un usuario particular denominado. Los usuarios de Query-D2R deberán

conocer las rutas de la ontología de dominio y de los servidores y archivos de documentación,

además de estar relacionados con el dominio de aplicación.

6.1.3. Requerimientos

El siguiente es el listado de requerimientos obtenidos de acuerdo al alcance y propuesta de

solución de esta tesis:

a) Requerimientos funcionales:

i. Extraer y presentar los sujetos, predicados y objetos relacionados con la ontología de

dominio que se encuentren publicados en los servidores D2R.

ii. Construir consultas relacionando tripletas con la información extraída.

iii. Permitir filtrados con base en valores de texto y numéricos determinados por el

usuario y por valores permitidos en la ontología.

iv. En caso de filtrados numéricos, extraer de cada servidor la unidad de medida

relacionada y presentarlas al usuario en un listado.

v. Convertir la consulta a SPARQL adecuando los parámetros numéricos de acuerdo a la

unidad de medida de cada servidor.

Capítulo 6 – Query-D2R - Software de consulta

92

vi. Gestionar la ejecución de la consulta en los servidores D2R, concatenar los resultados

y presentarlos al usuario en forma de tabla.

b) Requerimientos de interfaz de usuario:

i. Los resultados de las consultas deben presentarse en un componente de tabla,

mostrando las características principales del recurso y habilitando un enlace para

mostrarlo directamente en el navegador Web predeterminado.

c) Requerimientos de confiabilidad:

i. Se liberará el software en su versión beta una vez aprobada la etapa de pruebas.

ii. No se contemplarán esquemas de tolerancia a fallas y recuperación.

d) Requerimientos de mantenimiento:

i. El código fuente deberá contener comentarios de documentación e implementación.

e) Requerimientos de portabilidad:

i. Deberá ser capaz de ejecutarse en sistemas operativos basados en Windows y Linux.

f) Requerimientos reglamentarios:

i. Será liberado en su versión 1.0 una vez que su desempeño sea aprobado por el comité

revisor de la tesis.

6.1.4. Casos de uso

Como resultado del análisis de los requerimientos funcionales se observa un usuario genérico

encargado de activar las siguientes funciones:

Configurar parámetros iniciales: rutas de ontología, servidores y proyectos de

documentación. Una vez configurados incluye la actualización de los sujetos.

Construir consulta. Incluye la definición de subconsultas de acuerdo a lo siguiente:

o Escoger sujeto.

o Escoger predicado.

o Escoger objeto. Dentro de esta función se contempla la carga de las opciones de

filtrado.

Ejecutar consulta. Incluye:

o Construir consulta SPARQL configurando los parámetros para cada servidor D2R.

o Ejecutar consulta en cada servidor.

o Concatenar y presentar los resultados.

La Figura 6.1 muestra el diagrama de casos de uso. Los casos de uso son mostrados con detalle

desde la Tabla 6.1 hasta la Tabla 6.8.


93

Figura 6.1. Diagrama de casos de uso de Query-D2R

Tabla 6.1. Descripción de cu1_configurar

cu1_configurar

Actor: Usuario genérico.

Descripción: Permite establecer los parámetros iniciales y actualizar la lista de sujetos.

Precondición: No tiene.

Flujo normal: 1) El actor escribe la ruta de la ontología de dominio.

2) El actor agrega una nueva información de servidor y escribe la ruta del servidor D2R

y el proyecto de documentación.

3) El actor repite el punto 2 para cada uno de los servidores.

4) El actor presiona botón de actualizar información.

5) Quey-D2R consulta con los servidores los sujetos relacionados con la ontología de

dominio y los carga en una lista eliminando las repeticiones.

Flujo

alternativo:

El orden de los puntos 1 y 2 es sólo un orden recomendado, puede intercambiarse en

cualquier momento.

Poscondición: La lista de sujetos es cargada y se envía un mensaje de actualización exitosa.


94

Tabla 6.2. Descripción de cu2_construirConsulta

cu2_construirConsulta


Descripción: Permite construir una consulta especificando un conjunto de subconsultas.

Precondición: Lista de sujetos cargada.

Flujo normal: 1) El actor elige un sujeto de la lista.

2) La aplicación consulta con los servidores los predicados relacionados con la

ontología de dominio y con el sujeto seleccionado y los carga en una lista

eliminando las repeticiones.

3) El actor elige un predicado de la lista.

4) La aplicación consulta con los servidores y la lista de variables los objetos

relacionados con el sujeto y predicado seleccionados y los carga en una lista

eliminando las repeticiones. Si son objetos literal verifica los tipos de dato y los

agrupa de acuerdo a la categoría correspondiente (texto, numérico, booleano,

fecha, fecha-tiempo).

5) El actor elige un objeto de la lista.

6) El actor presiona botón de agregar subconsulta.

7) La aplicación verifica el tipo de objeto. Si es objeto literal de tipo texto verifica en

la ontología que no tenga lista de valores predefinidos, si existe lista véase

cu2.2_establecerFiltroLista, si no véase cu2.1_establecerFiltroTexto. Si es objeto

literal de tipo numérico véase cu2.3_establecerFiltroNumerico.

8) Agrega la subconsulta a la lista de subconsultas creando las variables pertinentes.

Las variables son actualizadas en la lista de sujetos.

9) El actor repite desde el punto 1 para cada una de las subconsultas.

Flujo alternativo: No tiene.

Poscondición: La lista de subconsultas y la lista de variables son actualizadas.

Incluye: cu2.1_establecerFiltroTexto, cu2.2_establecerFiltroLista y

cu2.3_establecerFiltroNumerico

Tabla 6.3. Descripción de cu2.1_establecerFiltroTexto

cu2.1_establecerFiltroTexto


Descripción: Permite añadir un filtro de texto a la subconsulta.

Precondición: Que el objeto sea literal de tipo texto y no tenga lista de valores predefinidos en la

ontología.

Flujo normal: 1) La aplicación abre el formulario de filtros de texto.

2) El actor establece uno de los filtros y presiona el botón de aceptar o el actor

presiona el botón de sin filtro.

3) La aplicación agrega el tipo de filtro y los valores de los parámetros a la

subconsulta y cierra el formulario de filtros de texto.


Poscondición: El filtro de texto es agregado a la subconsulta.


95

Tabla 6.4. Descripción de cu2.2_establecerFiltroLista

cu2.2_establecerFiltroLista


Descripción: Permite añadir un filtro de lista a la subconsulta.

Precondición: Que el objeto sea literal de tipo texto y tenga lista de valores predefinidos en la

ontología.

Flujo normal: 1) La aplicación abre el formulario de filtros de lista.

2) La aplicación carga la lista de valores.

3) El actor escoge uno de los valores y presiona el botón de aceptar o el actor

presiona el botón de sin filtro.


subconsulta y cierra el formulario de filtros de lista.


Poscondición: El filtro de lista es agregado a la subconsulta.

Tabla 6.5. Descripción de cu2.3_establecerFiltroNumerico

cu2.3_establecerFiltroNumerico


Descripción: Permite añadir un filtro numérico a la subconsulta.

Precondición: Que el objeto sea literal de tipo numérico.

Flujo normal: 1) La aplicación consulta en los archivos de documentación la unidad de medida

relacionada con el objeto.

2) La aplicación abre el formulario de filtros numéricos.

3) Si se recuperaron unidades de medida la aplicación carga la lista de unidades y la

hace visible.

4) El actor establece uno de los filtros, con o sin unidad de medida, y presiona el

botón de aceptar o el actor presiona el botón de sin filtro.


subconsulta y cierra el formulario de filtros numéricos.


Poscondición: El filtro numérico es agregado a la subconsulta.

Tabla 6.6. Descripción de cu3_ejecutarConsulta

cu3_ejecutarConsulta


Descripción: Permite ejecutar la consulta y presentar los resultados.

Precondición: Por lo menos una subconsulta en la lista.

Flujo normal: 1) El actor presiona botón de ejecutar consulta.

2) La aplicación verifica la primer subconsulta, si involucra dos variables, en sujeto y

objeto, presenta dialogo de escoger variable de resultado.

3) El actor escoge la variable de resultado.

4) La aplicación construye la consulta, configurada para cada servidor. Véase

cu3.1_transformarConsulta.

5) La aplicación ejecuta la consulta en todos los servidores y concatena los resultados.

6) La aplicación abre el formulario de resultados y presenta los resultados obtenidos.


96

Véase cu3.2_presentarResultados.


Poscondición: Los resultados son presentados en el formulario de resultados.

Incluye: cu3.1_transformarConsulta y cu3.2_presentarResultados.

Tabla 6.7. Descripción de cu3.1_transformarConsulta

cu3.1_transformarConsulta


Descripción: Crea la consulta SPARQL general y ajusta los valores de los parámetros para crear las

consultas específicas a cada servidor.

Precondición: Que se haya presionado el botón de ejecutar consulta y se haya escogido variable de

resultado.

Flujo normal: 1) La aplicación crea el prologo de la consulta.

2) La aplicación crea la forma de resultado de la consulta.

3) La aplicación crea el cuerpo de la consulta procesando cada una de las

subconsultas y añadiendo los filtros estipulados. Se mantiene una lista de

parámetros para cada servidor donde son agregados una vez que son

transformados a la unidad de medida correspondiente.

4) Se eliminan las líneas duplicadas en el cuerpo de la consulta.

5) Se crea la consulta general conjuntando el prologo, la forma de resultado y el

cuerpo.

6) Se crea la consulta para cada servidor remplazando los valores de su lista de

parámetros en la consulta general.


Poscondición: Es creada una lista con la dirección y la consulta específica de cada servidor.

Tabla 6.8. Descripción de cu3.2_presentarResultados

cu3.2_presentarResultados


Descripción: Presenta los resultados de la consulta y sus principales propiedades.

Precondición: Que la consulta se haya ejecutado en cada servidor y los resultados hayan sido

concatenados en una sola lista.

Flujo normal: 1) La aplicación abre el formulario de resultados.

2) La aplicación toma un elemento de la lista de resultados.

3) La aplicación extrae del elemento la dirección del servidor.

4) La aplicación consulta las principales propiedades del elemento.

5) La aplicación crea una tabla tomando como encabezado los nombres de las

propiedades y añade un renglón con los valores.

6) La aplicación repite desde el punto 1 hasta el 4 con todos los elementos de la lista

de resultados. Si un nombre de propiedad ya está en el encabezado sólo añade el

valor en la columna correspondiente, si no lo está, crea una nueva columna.


Poscondición: Los resultados son presentados en un componente de tipo tabla.


97

6.2. Análisis y diseño

En esta sección se incluye la definición de los componentes que integran Query-D2R y los

diagramas de actividades que detallan su interacción.

6.2.1. Componentes

De acuerdo al análisis de los casos de uso, se contemplaron los siguientes componentes (Figura

6.2):

Módulo de construcción. Contribuye directamente en los casos de uso 1, 2, 2.1, 2.2 y 2.3,

se encarga de las siguientes funcionalidades:

o Presentar los sujetos, objetos y predicados sin repeticiones.

o Extraer de la ontología los valores permitidos de un determinado objeto.

o Extraer de los archivos de documentación las unidades de medida de un

determinado objeto.

o Crear las subconsultas y los filtros.

o Administrar las variables de consulta.

Módulo de transformación. Contribuye directamente en el caso de uso 3.1, se encarga de

las siguientes funciones:

o Crear la consulta SPARQL general.

o Administrar los parámetros de consulta, verificando la unidad de medida de cada

servidor y realizando la conversión según se requiera.

o Crear la consulta SPARQL específica a cada servidor.

Módulo de ejecución. Contribuye directamente en los casos de uso 1 y 3, se encarga de las

siguientes funcionalidades:

o Extraer los sujetos, objetos y predicados de cada servidor.

o Ejecutar la consulta específica a cada servidor.

o Extraer las propiedades de los elementos de la lista de resultados.

Módulo de presentación. Contribuye directamente en el caso de uso 3.2, se encarga de la

siguiente función:

o Presentar las propiedades de los elementos de la lista de resultados en un

componente de tabla y habilitar una opción para verlos directamente en el

navegador Web predeterminado.

6.2.2. Diagramas de actividades

Se diseñaron diagramas de actividades para cada caso de uso detallando las acciones que realiza

cada módulo. Estos diagramas son mostrados a partir de la Figura 6.3 hasta la Figura 6.10.


98

Figura 6.2. Diagrama de componentes de Query-D2R

Figura 6.3. Diagrama de actividades de cu1_configurar


99

Figura 6.4. Diagrama de actividades de cu2_construirConsulta


100

Figura 6.5. Diagrama de actividades de cu2.1_establecerFiltroTexto

Figura 6.6. Diagrama de actividades de cu2.2_establecerFiltroLista


101

Figura 6.7. Diagrama de actividades de cu2.1_establecerFiltroNumerico


102

Figura 6.8. Diagrama de actividades de cu3_ejecutarConsulta

Figura 6.9. Diagrama de actividades de cu3.2_presentarResultados


103

Figura 6.10. Diagrama de actividades de cu3.1_transformarConsulta


104

6.3. Implementación

En esta sección se describe el entorno de desarrollo, las clases y los formularios implementados.

6.3.1. Entorno de desarrollo

Lenguaje de programación: Java SE 6

Se optó por este lenguaje debido al requerimiento multiplataforma y la necesidad de

utilizar la API Jena para la manipulación de la ontología de dominio y la ejecución de

consultas SPARQL. El entorno de programación usado fue Netbeans IDE 6.5.

Librerías auxiliares:

JENA 2.5.6. Empleada para extraer los valores predefinidos de las propiedades de tipo de

dato de la ontología OWL DL de dominio y ejecutar las consultas SPARQL utilizando ARQ.

Medicion. Generada con XMLBeans 2.4.0, contiene las clases que manipulan la

información del documento XML de unidades de medida.

Proy. Generada con XMLBeans 2.4.0, contiene las clases que manipulan la información del

documento XML de proyecto.

6.3.2. Clases

Cada módulo contemplado se implementó como paquete. En total se implementaron 7 paquetes:

el paquete base queryd2r; los paquetes que representan los módulos, construccion, ejecucion,

transformacion y presentacion; y los paquetes de formularios y otros. El diagrama de clases de la

Figura 6.12 muestra las clases que corresponden a cada paquete.

El listado con la descripción de las principales clases se muestra desde la Figura 6.11 hasta la Figura

6.20.

ServidorD2R

Ruta de paquete:

queryd2r.construccion

Descripción:

Administra los datos de servidor.

Punto de partida para obtener y

guardar la lista de sujetos.

Figura 6.11. Clase ServidorD2R


105

Figura 6.12. Diagrama de clases de Query-D2R


106

Sujeto

Ruta de paquete:


Descripción:

Administra los datos de sujeto y la lista de

predicados.

Figura 6.13. Clase Sujeto

Predicado

Ruta de paquete:


Descripción:

Administra los datos de predicado y el objeto

relacionado.

Figura 6.14. Clase Predicado

Consulta

Ruta de paquete:


Descripción:

Controla el conjunto de subconsultas y la

lista de variables.

Figura 6.15. Clase Consulta

CreadorSPARQL

Ruta de paquete:

queryd2r.transformacion

Descripción:

Implementa la creación de la consulta SPARQL general y la lista de consultas específicas.

Figura 6.16. Clase CreadorSPARQL


107

Subconsulta

Ruta de paquete:


Descripción:

Administra los valores de una subconsulta:

sujeto, predicado, objeto, variables y filtro.

Figura 6.17. Clase Subconsulta

FiltroLiteral

Ruta de paquete:


Descripción:

Administra los datos de filtro de texto o

numérico.

Figura 6.18. Clase FiltroLiteral


108

EjecutorSPARQL

Ruta de paquete:

queryd2r.ejecucion

Descripción:

Se encarga de interactuar con

los servidores a través de

consultas SPARQL.

Figura 6.19. Clase EjecutorSPARQL

frmPresentadorD2R

Ruta de paquete:

queryd2r.presentacion

Descripción:

Clase formulario que se encarga de crear y mostrar la tabla de resultados y sus principales

propiedades.

Figura 6.20. Clase frmPresentadorD2R

6.3.3. Formularios

frmPrincipalView - Formulario

principal

Presenta el campo de texto para

escribir la ruta de la ontología de

dominio; la tabla y los botones

para agregar, quitar y actualizar

servidores; los listados de sujeto,

predicado y objeto para

especificar y agregar

subconsultas; la tabla para

visualizar, reacomodar y eliminar

subconsultas; y el botón para

ejecutar consulta (Figura 6.21).

Figura 6.21. Formulario principal de Query-D2R


109

frmFiltroTexto - Formulario filtro de

valor de texto (Figura 6.22)

Figura 6.22. Formulario filtro de valor de texto

frmFiltroLista - Formulario filtro por listado de

valores (Figura 6.23)

Figura 6.23. Formulario filtro por listado de valores

frmFiltroNumerico - Formulario filtro de valor

numérico (Figura 6.24)

Figura 6.24. Formulario filtro de valor numérico

frmPresentadorD2R - Formulario de

resultados

Presenta la tabla de resultados y un botón

para abrir los recursos seleccionados en el

navegador Web preseterminado (Figura

6.25).

Figura 6.25. Formulario de resultados


110

6.4. Pruebas

En esta sección se presenta un resumen del plan de pruebas, de la especificación de casos y

procedimientos de prueba y de los resultados obtenidos.

6.4.1. Plan de pruebas

Introducción

Basado en el estándar IEEE 829, la presente sección define el plan de pruebas para verificar el

funcionamiento de Query-D2R, herramienta de consulta del proyecto de tesis.

Elementos a probar

Se probarán las siguientes funcionalidades:

Construcción de consultas con y sin filtros.

Transformación de consulta a consultas SPARQL específicas.

Ejecución de consultas.

Presentación de resultados.

Las pruebas se aplicarán a la primera versión (beta) del sistema Query-D2R.

La inspección de código fuente no se incluye en el plan de pruebas ya que será tarea del

programador al terminar la codificación de cada clase.


La siguiente lista presenta el nombre, precedido del identificador, de cada uno de los casos de

prueba:

QUERYD2R_CP-01 Una variable sin filtro.

QUERYD2R_CP-02 Varias variables y filtro de texto “igual”.

QUERYD2R_CP-03 Filtro de texto “contiene”.

QUERYD2R_CP-04 Filtro numérico “mayor” con unidad derivada.

QUERYD2R_CP-05 Filtro numérico “menor” con unidad fundamental.

QUERYD2R_CP-06 Filtro de texto “igual” basado en lista.

QUERYD2R_CP-07 Consultas genéricas.

Características excluidas de las pruebas

Características de rendimiento, por ejemplo: tiempos de carga de interfaz, de

actualización de servidores y de ejecución de consultas.

Cualquier otra no incluida en los casos de prueba.

Enfoque

Las pruebas son de carácter funcional o de caja negra, se evaluará el sistema de acuerdo a los

resultados esperados para una determinada consulta. Las consultas fueron formuladas con base

en las preguntas de competencia para la ontología de dominio (sección 4.4.3) y considerando se

presentaran los problemas de heterogeneidad a resolver (sección 2.3).


111

Criterios de éxito/fallo

En cada uno de los procedimientos de casos de prueba se describen los resultados esperados. Se

considera que una prueba ha pasado con éxito cuando los resultados obtenidos coinciden con los

esperados. Por el contrario, la discordancia supone un fallo en la prueba.

Escenario de prueba Tabla 6.9. Características de escenario de prueba

Identificador Hardware Software

Lap Tipo: Computadora portátil

Procesador: AMD Turion 64 X2 TL-60, 2.00 GHz

Memoria RAM: 3 GB

Disco duro: 250 GB

Sistema operativo: Windows Vista Home Premium SP1

SMBD: Microsoft SQL Server 2005 Express Edition

Base de Datos: Prepa

Query-D2R Beta

D2R-Server 0.4

Java SE Development Kit (JDK), version 6

Virtual Tipo: Máquina virtual VMware Worstation 6.5

Procesadores: 1, modo de ejecución automático

Memoria RAM: 512 MB

Disco duro: 8 GB (virtualizado en Lap)

Sistema operativo: Ubuntu Linux 8

SMBD: MySQL Server 5.0

Bases de Datos: SiCEWin y genWeb

D2R-Server 0.4

OpenJDK Java 6

Los proyectos de documentación de cada una de las bases de datos fueron generados en Lap. Los

archivos de mapeo fueron generados desde Lap pero almacenados en rutas de cada equipo1.

Las direcciones de los servidores D2R son las siguientes:

Prepa: http://172.16.141.1:2020

SiCEWin: http://172.16.141.128:2020

genWeb: http://172.16.141.128:2021

6.4.2. Especificación de casos de prueba y resultados

6.4.2.1. Caso de prueba 01


QUERYD2R_CP-01

1 El contenido de los proyectos de documentación y archivos de mapeo no se incluye en este documento, sólo se hacen

referencias necesarias en cada caso. Sin embargo, puede consultarse en el disco relacionado con esta tesis disponible en

la biblioteca del Cenidet, en él también se encuentran los scripts de creación de bases de datos y de inserción de datos

de prueba.


112


Funcionamiento de todos los componentes del formulario principal.

Construcción y ejecución de consultas con una variable y sin filtros.

Llenado de la tabla de resultados en el formulario correspondiente.

Entradas

Ruta de ontología de dominio e información de servidores y documentación.

Creación de consulta “Nombre de todas las especialidades”.

Salida

11 resultados, 3 de Prepa y 8 de SiCEWin. genWeb no contiene especialidades.

Elementos de bases de datos relacionados

Prepa.especialidad.nombre_especialidad (nvarchar)

SiCEWin.especialidad.Descripcion (varchar)

Escenario de prueba

Mismo escenario para todos los casos, véase sección 6.4.1.


Ejecutar Query-D2R.

Escribir ruta de ontología de dominio.

Agregar nuevo servidor.

Escribir los datos del servidor y documentación de Prepa, mantener la pestaña en Activo.


Escribir los datos del servidor y documentación de SiCEWin, mantener la pestaña en

Activo.


Escribir los datos del servidor y documentación de genWeb, mantener la pestaña en

Activo.

Actualizar.

Agregar subsonsulta: Especialidad-tieneNombreEspecialidad-valorTexto (sin filtro).

Ejecutar consulta.


No tiene.

Resultados

Prueba exitosa


113

Figura 6.26. (QUERYD2R_CP-01) Configuración de ontología, servidores y consulta

Figura 6.27. (QUERYD2R_CP-01) Consulta SPARQL generada para servidor1


114

Figura 6.28. (QUERYD2R_CP-01) Resultados



QUERYD2R_CP-02


Construcción y ejecución de consultas con varias variables y filtro de texto de tipo “igual”.

Apertura del mensaje de pregunta de variable de resultado.

Entrada

Creación de consulta “Nombre de las especialidades de XCarrera”.

Salida

3 resultados de SiCEWin. Prepa no contiene carreras. genWeb no contiene especialidades ni

carreras.


SiCEWin.especialidad

SiCEWin.carrera.Descripcion (varchar)


Continuar desde: QUERYD2R_CP-01.

Limpiar consulta.

Agregar subsonsulta: Especialidad-esDeCarrera-Carrera.

Agregar subsonsulta: Carrera1-tieneNombreCarrera-valorTexto (igual a “Computación”).

Ejecutar consulta.

Escoger variable Especialidad1.


115


Dependencia con el caso 01, configuración inicial de servidores y ontología.

Resultados

Prueba exitosa

Figura 6.29. (QUERYD2R_CP-02) Resumen de consulta

Figura 6.30. (QUERYD2R_CP-02) Elección de variable de resultado



116




QUERYD2R_CP-03


Construcción y ejecución de consultas con varias variables y filtro de texto de tipo “contiene”.

Entrada

Creación de consulta “Todos los alumnos que toman materias con XProfesor”.

Salida

7 resultados de SiCEWin. Prepa no cumple con el filtro. genWeb no contiene alumnos.


SiCEWin.alumno

SiCEWin.inscripcion

SiCEWin.grupo

SiCEWin.grupoprofe

SiCEWin.profesor.Nombre (varchar)

Prepa.estudiante

Prepa.calificacion

Prepa.grupo

Prepa.maestro.nombre (nvarchar)1



Limpiar consulta.

1 Se presenta un conflicto de abstracción, en Prepa el nombre del profesor se divide en nombre, paterno y materno, en

cambio en SiCEWin sólo se maneja Nombre para guardar el nombre completo. Pueden ser obtenidos con dos consultas

independientes.


117

Agregar subsonsulta: Alumno-tomaClaseCon-Profesor.

Agregar subsonsulta: Profesor1-tieneNombreCompleto-valorTexto (contiene

“Santoloaya”).

Ejecutar consulta.

Escoger variable Alumno1.



Resultados

Prueba exitosa




118




QUERYD2R_CP-04


Construcción y ejecución de consultas con varias variables y filtro numérico de tipo

“mayor” con unidad derivada.

Apertura de formulario de filtro numérico con el listado de unidades de medida.

Transformación de parámetros de acuerdo a la unidad de medida de cada servidor,

considerando la elección de unidad derivada.

Entrada

Creación de consulta “Calificaciones aprobatorias (mayores o iguales a 6 en base 0-10) de

XAlumno”.

Salida

4 resultados, 3 de Prepa y 1 de SiCEWin. genWeb no contiene inscripciones.


SiCEWin.alumno.Nombre (varchar)

SiCEWin.alumno.ApellidoP (varchar)

SiCEWin.inscripcion.Calificacion (int, unidad de medida calif0-100)

Prepa.estudiante.nombre (nvarchar)

Prepa.estudiante.paterno (nvarchar)

Prepa.calificacion.calificacion (float, unidad de medida calif0-10)



Limpiar consulta.

Agregar subsonsulta: Alumno-tieneInscripcion-Inscripcion.


119

Agregar subsonsulta: Inscripcion1-tieneValorCalificacion-valoNumérico (mayor a 5.9 en

unidad “calif0-10”).

Agregar subsonsulta: Alumno1-tieneApellidoPaterno-valorTexto (igual a “Bañuelos”).

Agregar subsonsulta: Alumno1-tieneNombre-valorTexto (contiene “edgar”).

Ejecutar consulta.

Escoger variable Inscripcion1.



Resultados

Prueba exitosa




120

Figura 6.38. (QUERYD2R_CP-04) Consulta SPARQL generada para servidor2, se observa la conversión del parámetro




QUERYD2R_CP-05


Construcción y ejecución de consultas con varias variables y filtro numérico de tipo

“menor” con unidad fundamental.

Transformación de parámetros de acuerdo a la unidad de medida de cada servidor,

considerando la elección de unidad fundamental.

Entrada

Creación de consulta “Calificaciones reprobatorias (menores a 60 en base 0-100) de XAlumno”.

Salida

2 resultados, 1 de Prepa y 1 de SiCEWin. genWeb no contiene inscripciones.


121


SiCEWin.alumno.Nombre (varchar)

SiCEWin.alumno.ApellidoP (varchar)

SiCEWin.inscripcion.Calificacion (int, unidad de medida calif0-100)

Prepa.estudiante.nombre (nvarchar)

Prepa.estudiante.paterno (nvarchar)

Prepa.calificacion.calificacion (float, unidad de medida calif0-10)



Limpiar consulta.


Agregar subsonsulta: Inscripcion1-tieneValorCalificacion-valoNumérico (menor a 60 en




Ejecutar consulta.

Escoger variable Inscripcion1.



Resultados

Prueba exitosa



122

Figura 6.41. (QUERYD2R_CP-05) Consulta SPARQL generada para servidor1, se observa la conversión del parámetro




123



QUERYD2R_CP-06


Construcción y ejecución de consultas con filtro de texto basado en lista.

Extracción de lista de valores válidos para una propiedad en la ontología.

Apertura del formulario de listado de valores.

Entrada

Creación de consulta “Todos los alumnos (hombres) que toman materias con XProfesor”.

Salida

3 resultados de SiCEWin. Prepa no cumple con el filtro. genWeb no contiene inscripciones.


SiCEWin.alumno

SiCEWin.inscripcion

SiCEWin.grupo

SiCEWin.grupoprofe

SiCEWin.profesor.Nombre (varchar)

SiCEWin.profesor.Sexo (char, valores H y M para masculino y femenino respectivamente)

Prepa.estudiante

Prepa.calificacion

Prepa.grupo

Prepa.maestro.nombre (nvarchar)



Limpiar consulta.


Agregar subsonsulta: Profesor1-tieneNombreCompleto-valorTexto (contiene

“Santoloaya”).

Agregar subsonsulta: Alumno1-tieneSexo-valorTexto (elegido por lista, igual a

“masculino”).

Ejecutar consulta.




Resultados

Prueba exitosa


124





125



QUERYD2R_CP-07


Construcción y ejecución de consultas, funcionalidad en general.

Apertura del detalle de resultados en el navegador Web predeterminado.

Entrada

Creación de consulta1 “Alumnos que toman clases con XProfesor y son tesistas de él”.

Creación de consulta2 “Alumnos que llevan XMateria y tienen calificación menor a

XValor”.

Creación de consulta3 “Tema de tesis de XAlumno”.

Creación de consulta4 “Profesores que le imparten clase a XAlumno”.

Salida

Consulta1: 2 resultados de SiCEWin.

Consulta2: 5 resultados, 2 de Prepa y 3 de SiCEWin.

Consulta3: 1 resultado de SiCEWin.

Consulta4: 8 resultados, 4 de Prepa y 4 de SiCEWin.


Varios.



Limpiar consulta.


Agregar subconsulta: Alumno1-realizaTesis-Tesis.

Agregar subconsulta: Profesor1-dirigeTesis-Tesis1.

Agregar subconsulta: Profesor1-tieneNombreCompleto-valorTexto (contiene “Zárate”).

Ejecutar consulta.


Seleccionar primer resultado.

Abrir en navegador.

Cerrar resultados.

Limpiar consulta.


Agregar subsonsulta: Inscripcion1-tieneValorCalificacion-valoNumérico (menor a 80 en


Agregar subsonsulta: Inscripcion1-tieneMateria-Materia.

Agregar subsonsulta: Materia1-tieneNombreMateria-valorTexto (igual a “Español”).


126

Ejecutar consulta.


Cerrar resultados.

Limpiar consulta.

Agregar subsonsulta: Alumno-realizaTesis-Tesis.



Ejecutar consulta.

Escoger variable Tesis1.

Cerrar resultados.

Limpiar consulta.



Ejecutar consulta.

Escoger variable Profesor1.



Resultados

Prueba exitosa

Figura 6.47. (QUERYD2R_CP-07) Resumen de consulta1


127

Figura 6.48. (QUERYD2R_CP-07) Consulta1 SPARQL generada para servidor1

Figura 6.49. (QUERYD2R_CP-07) Resultados de consulta1

Figura 6.50. (QUERYD2R_CP-07) Vista detalle en navegador Web de primer resultado de consulta1


128





129





130




131

7. Capítulo 7

Conclusiones y trabajos futuros

7.1. Conclusiones

El trabajo de tesis descrito en este documento cumple los objetivos presentados en la sección

1.2.1. Durante el desarrollo de la investigación se obtuvieron las siguientes conclusiones:

El software Doc-D2R implementa la documentación de metadatos de bases de datos

relacionales y la generación automática de mapeos D2RQ. Se aprovecha la actividad de

documentar cediendo al usuario la responsabilidad de relacionar elementos de las bases

de datos con conceptos y propiedades de una ontología ligada al dominio real,

permitiendo generar mapeos con una mayor descripción.

El enfoque fue ajustado para trabajar con servidores D2R y en consecuencia con su

lenguaje de mapeo. Los servidores permiten publicar las bases de datos en la Web como

un conjunto de tripletas RDF. El lenguaje D2RQ ha sido considerando por un grupo de

trabajo de la W3C1 como uno de los modelos para la estandarización de lenguajes de

mapeo de bases de datos, lo que implica que Doc-D2R podría ser adaptado sin mayores

modificaciones para trabajar bajo las recomendaciones y el nuevo lenguaje que se

generen.

El software QueryD2R desarrollado permite consultar directamente los servidores D2R a

través del protocolo SPARQL. La construcción de consultas se realiza conformando

tripletas de sujeto-predicado-objeto e implementa filtros similares a los propuestos por

Brisaboa [4] en el marco del Lenguaje Natural Acotado.

Los datos de las base de datos son publicados en una representación común de mayor

abstracción. Los problemas de sinonimia y homonimia no se presentan debido a que

Query-D2R limita la elección de tripletas sólo a los elementos relacionados con la

ontología, mostrando un único nombre para un concepto en el dominio aún cuando en

tablas y/o columnas difieran en su denominación.

1 http://www.w3.org/2005/Incubator/rdb2rdf/

Capítulo 7 – Conclusiones

132

Los problemas por unidades de medida se atacan transformando los parámetros de las

consultas SPARQL a la unidad de la columna definida en los archivos de documentación.

Los problemas por tipos de datos se minimizan al equipararlos primero a tipos de datos

del esquema XML (indispensable para el mapeo D2RQ) y luego agruparlos en categorías

para su filtrado en las consultas.

El enfoque presentado puede implementarse en cualquier dominio siempre y cuando se

defina o se cuente con una ontología relacionada. La idea inicial es reutilizar o adecuar

alguna ontología existente, el buscador de ontologías Swoogle1 reporta más de 10,000

ontologías en su índice de búsqueda. El proceso de documentación depende totalmente

de la ontología de dominio, sin embargo una vez generado el mapeo D2RQ la ontología

sólo es utilizada para extraer la lista de valores predefinidos para propiedades de tipo de

dato y generar los filtros de lista en Query-D2R.

Es posible que en los archivos de mapeo se generen propiedades que no tengan

congruencia en el dominio debido al tipo de análisis realizado en las llaves foráneas y la

documentación de tablas y columnas. Tal es el caso de la propiedad tomaClaseCon en

SiCEWin, generada relacionando las tablas alumno y profesor a través de la tabla tesis y

corregida a la postre con un ajuste manual. Es necesario considerar la participación del

usuario para confirmar cualquier propiedad inferida antes de generar el mapeo.

La definición de estándares para la definición de URIs para clases específicas, como CURP

para persona, permitiría integrar datos de manera más precisa. El trabajo mostrado en

este documento considera la definición del esquema de la base de datos, sin embargo es

necesario complementarlo infiriendo otras propiedades y relaciones a partir del análisis de

los datos y de reglas definidas en la ontología.

7.2. Aportaciones

La contribución más relevante de esta tesis se da en la definición e implementación de un proceso

de documentación bajo un enfoque de Web Semántica. Dentro del tópico de interoperabilidad de

bases de datos, esto permite resolver conflictos generados por la heterogeneidad en nombres,

como sinonimia y homonimia, y presentar alternativas para resolver discrepancias en unidades de

medida y tipos de datos, además de sentar las bases para resolver conflictos como el de

abstracción y otros.

Otras aportaciones:

Dos herramientas de software multiplataforma flexibles a cualquier SMBDs con

controlador JDBC disponible y desarrolladas en lenguaje Java: Doc-D2R y Query-D2R.

1 http://swoogle.umbc.edu/

Capítulo 7 – Conclusiones

133

Reglas para la definición de alias de tablas y columnas y nombrado de elementos en

ontologías, formuladas bajo lineamientos de estándares internacionales.

Archivo XML de unidades de medida y factores de conversión y clases Java para la

manipulación de los datos del mismo.

Ontología de dominio de registros escolares desarrollada en el lenguaje OWL DL.

7.3. Trabajos futuros

Ampliar Doc-D2R para preferir en la documentación el uso de vocabularios estándar

(FOAF 1 , SKOS 2 , Dublin Core 3 , entre otros) sobre el presentado por la ontología,

principalmente en el caso de conceptos y propiedades muy generales, como persona o

teléfono. Esto aligeraría la dependencia del enfoque con la ontología de dominio y

permitiría incluir en la herramienta de consulta datos RDF de otras fuentes que habiliten

un punto de consulta SPARQL.

Ampliar el lenguaje de mapeo D2RQ y el servidor D2R para agregar información, como la

de las unidades de medida, acorde con las resoluciones que el grupo de trabajo de la W3C

libere, buscando participar directa o indirectamente en este grupo con las observaciones

que del propio trabajo se obtengan.

Modificar Query-D2R para incluir diversas fuentes de datos RDF y no sólo servidores D2R

que utilicen mapeos generados por Doc-D2R. Adecuar la herramienta para permitir la

construcción de consultas SPARQL de mayor complejidad que incluyan, entre otras cosas,

patrones opcionales.

Complementar Query-D2R con una comunidad de agentes de software desarrollados bajo

alguna plataforma como JADE, considerando la utilización de reglas SWRL en la ontología

de dominio. Los agentes se encargarían principalmente de analizar los datos de acuerdo a

las reglas definidas, dotando al enfoque de un mayor poder de inferencia.

Formular y proponer estándares para la definición de URIs para clases específicas en

México (persona-CURP, escuela-ClaveRegistroSEP, etc.), sometiéndolos a su evaluación y

aprobación.

1 Proyecto Friend of a Friend, define vocabulario para describir personas, http://www.foaf-project.org/ 2 Del inglés Simple Knowledge Organization System, define vocabulario para utilizar en sistemas de conocimiento, http://www.w3.org/2004/02/skos/ 3 La iniciativa Dublin Core define un estándar de metadatos para describir recursos, http://dublincore.org/

135

A. Anexo A

Diagramas de bases de datos de prueba

Figura A.1. Diagrama de base de datos SiCEWin

Anexo A – Diagramas de bases de datos de prueba

136

Figura A.2. Diagrama de base de datos Prepa

especialidad

clave_especialidad int

nombre_especiali... nvarchar(50)

Nombre de columna Tipo comprimido

maestro

clave_maestro int

paterno nvarchar(15)

materno nvarchar(15)

nombre nvarchar(20)

direccion nvarchar(50)

colonia nvarchar(30)

municipio nvarchar(30)

entidad nvarchar(30)

telefono nvarchar(15)


materia

clave_materia int

nombre nvarchar(50)


FK_calificacion_alumno

estudiante

clave_estudiante int

clave_especialidad int

paterno nvarchar(15)

materno nvarchar(15)

nombre nvarchar(20)

direccion nvarchar(50)

municipio nvarchar(30)

colonia nvarchar(30)

entidad nvarchar(30)

telefono nvarchar(15)


calificacion

clave_estudiante int

calificacion float

id_carga_grupo int


horario

clave_grupo int

dia nvarchar(15)

hora_inicio nvarchar(15)

hora_fin nvarchar(15)

Nombre de colu... Tipo comprimido

FK_alumno_especialidad

grupoclave_grupo

clave_materia

clave_maestro

grado

nombre_grupo

periodo

FK_grupo_maestro

FK_grupo_materia

FK_calificacion_grupo

FK_horario_grupo


137

Figura A.3. Diagrama de base de datos genWeb


138

Figura A.4. Diagrama de base de datos de sicewin_cut

139

Referencias

[1] W. Hu y Y. Qu, "Discovering Simple Mappings Between Relational Database Schemas and

Ontologies," en The 6th International Semantic Web Conference and the 2nd Asian Semantic

Web Conference (ISWC07+ASWC07), Busan, Korea, 2007.

[2] R. Cyganiak. (2006, Oct.) Richard Cyganiak´s Weblog. [En línea].

http://dowhatimean.net/2006/10/open-data-and-the-semantic-web

[3] T. Berners-Lee, J. Hendler, y O. Lassila, "The Semantic Web - A new form of Web content that

is meaningful to computers will unleash a revolution of new possibilities," Scientific

American, May. 2001.

[4] N. R. Brisaboa, et al., "Sistema de consulta vía Web para el Instituto Andaluz de Patrimonio

Histórico," en II Jornadas de Bibliotecas Digitales JBIDI, 2001.

[5] A. Silberschatz, H. F. Korth, y S. Sudarshan, Fundamentos de bases de datos, 4ta ed. McGraw

Hill, 2002.

[6] R. Fileto y C. Bauzer, "A Survey on Information Systems Interoperability," Universidad de

Campinas Relatorio Técnico Technical Report -IC-03-030-, 2003.

[7] A. Zisman y J. Kramer, "Towards Interoperability in Heterogeneous Database Systems -

Imperial College Research Report No. DOC95/11," Imperial College, 1995.

[8] T. R. Gruber, "Toward Principles for Design of Ontologies Used for Knowledge Sharing,"

Knowledge Systems Laboratory, Stanford University, Technical Report 93-04, 1993.

[9] T. R. Gruber, "Ontology," en Encyclopedia of Database Systems, L. Liu y M. Tamer Özsu, Eds.

Springer-Verlag, 2008, Tomada del sitio web del autor:

http://tomgruber.org/writing/ontology-definition-2007.htm.

[10] M. Ushold y M. Gruninger, "Ontologies: Principles, Methods and Applications," Knowledge

Engineering Review, vol. 11, no. 2, 1996.

[11] N. Guarino, "Formal Ontology and Information Systems," en Proceedings of the International

Conference on Formal Ontology in Information Systems (FOIS98), 1998.

[12] OpenLink Software. (2007, Jun.) Virtuoso RDF Views - Getting Started Guide. [En línea].

http://virtuoso.openlinksw.com/Whitepapers/pdf/Virtuoso_SQL_to_RDF_Mapping.pdf

Referencias

140

[13] W3C. (2007, Nov.) SPARQL Query Language for RDF. [En línea]. http://www.w3.org/TR/rdf-

sparql-query/

[14] W3C. (2004, Feb.) OWL Web Ontology Language Overview. [En línea].

http://www.w3.org/TR/2004/REC-owl-features-20040210/

[15] W3C. (2007, Nov.) Guía Breve de Web Semántica. [En línea].

http://www.w3c.es/Divulgacion/Guiasbreves/WebSemantica

[16] W3C. (2004, Feb.) Resource Description Framework (RDF): Concepts and Abstract Syntax. [En

línea]. http://www.w3.org/TR/rdf-concepts/

[17] W3C. (2004, Feb.) RDF Primer. [En línea]. http://www.w3.org/TR/2004/REC-rdf-primer-

20040210/

[18] W3C. (2007, Nov.) SPARQL Protocol for RDF. [En línea]. http://www.w3.org/TR/rdf-sparql-

protocol/

[19] W3C. (2007, Nov.) SPARQL Query Results XML Format. [En línea]. http://www.w3.org/TR/rdf-

sparql-XMLres/

[20] O. Corcho, M. Fernández López, y A. Gómez Pérez, "Methodologies, tools and languages for

building ontologies. Where is their meeting point?," Data and Knowledge Engineering, págs.

41-64, Jul. 2003.

[21] N. F. Noy y D. L. McGuinness, "Desarrollo de Ontologías-101: Guía Para Crear Tu Primera

Ontología," Mar. 2001.

[22] M. Li, X.-Y. Du, y S. Wang, "Learning Ontology from Relational Database," en Proceedings of

2005 International Conference on Machine Learning and Cybernetics, 2005, págs. 3410-3415.

[23] G. Barchini, M. Álvarez, y S. Herrera, "Sistemas de información: Nuevos Escenarios basados

en Ontologías," Revista de Gestión de Tecnología y Sistemas de Información, Journal of

Information Systems and Technology Management, vol. 3, no. 1, 2006.

[24] I. Astrova y B. Stantic, "Reverse Engineering of Relational Databases to Ontologies: An

Approach Based on an Analysis of HTML Forms," en Proceedings of the Workshop W6 on

Knowledge Discovery and Ontologies (KDO), 8th European Conference on Principles and

Practice of Knowledge Discovery in Databases (PKDD), 2004.

[25] S. M. Benslimane, M. Malki, y A. Lehirech, "Towards ontology-based semantic web from data-

intensive web: A reverse engineering approach," en IEEE International Conference on

Referencias

141

Computer Systems and Applications 2006, 2006, págs. 771-778.

[26] N. R. Brisaboa, M. R. Penabad, Á. S. Places, y F. J. Rodríguez, "Arquitectura para Federación

de Bases de Datos Documentales basada en Ontologías," en Actas de las 4tas. Jornadas

Iberoamericanas de Ingeniería de Requisitos y Ambientes de Software, F. Torres Rojas, J. E.

Araya Monge, y S. Sánchez, Eds. Heredia, Costa Rica, 2001, págs. 252-262.

[27] D. Dou y P. LePendu, "Ontology-based integration for relational databases," en Proceedings

of the 2006 ACM symposium on Applied computing, 2006.

[28] C. Pérez de Laborda y S. Conrad, "RelationalOWL - A Data and Schema Representation Format

Based on OWL," en Second Asia-Pacific Conference on Conceptual Modelling (APCCM2005),

Newcastle, Australia, 2005, págs. 89-96.

[29] C. Pérez de Laborda y S. Conrad, "Database to Semantic Web Mapping using RDF Query

Languages," en 25th International Conference on Conceptual Modeling (ER2006), Tucson,

Arizona, Estados Unidos, 2006, págs. 241-254.

[30] Universidad Heinrich-Deine. (2006, Oct.) Semantic Web Activities at the Databases and

Information Systems Group. [En línea]. http://www.dbs.cs.uni-

duesseldorf.de/RDF/index.php?lang=es

[31] C. Pérez de Laborda, M. Zloch, y S. Conrad, "RDQuery - Querying Relational Databases on-the-

fly with RDF-QL," en Proceedings of the 15th International Conference on Knowledge

Engineering and Knowledge Management (EKAW2006), Poderbrady, República Checa, 2006,

págs. 19-20.

[32] H. Chen, et al., "From Legacy Relational Databases to the Semantic Web: an In-Use

Application for Traditional Chinese Medicine," en 5th International Semantic Web Conference

(ISWC2006), 2006.

[33] C. Bizer, R. Cyganiak, J. Garbers, y O. Maresch. (2007, Oct.) User Manual and Language

Specification. [En línea]. http://sites.wiwiss.fu-berlin.de/suhl/bizer/d2rq/spec/

[34] C. Bizer y A. Seaborne, "D2RQ - Treating Non-RDF Databases as Virtual RDF Graphs," en 3rd

International Semantic Web Conference (ISWC2004), Hiroshima, Japón, 2004.

[35] T. Berners-Lee. (2007, May.) Linked Data. [En línea].

http://www.w3.org/DesignIssues/LinkedData.html

[36] BBN Technologies. (2007) Asio Semantic Bridge for Relational Databases. [En línea].

http://asio.bbn.com/sbrd.html

Referencias

142

[37] BBN Technologies. (2007) Asio Cartographer. [En línea].

http://asio.bbn.com/cartographer.html

[38] BBN Technologies. (2007) Asio Semantic Query Decomposition. [En línea].

http://asio.bbn.com/sqd.html

[39] OpenLink Software. (2007) Overview - What is Virtuoso?. [En línea].

http://docs.openlinksw.com/virtuoso/WhatIsVirtuoso.html

[40] OpenLink Software. (2007) RDF Database and SPARQL - RDF Views -- Mapping Relational Data

to RDF. [En línea]. http://docs.openlinksw.com/virtuoso/rdfviews.html

[41] SquirrelRDF. Documentation. [En línea]. http://jena.sourceforge.net/SquirrelRDF/

[42] RDF Data Access Working Group. (2007, Jun.) SPASQL: SPARQL Support In MySQL. [En línea].

http://www.w3.org/2005/05/22-SPARQL-MySQL/XTech

[43] ISO/IEC. (2007, ) ISO/IEC 11179, Information Technology -- Metadata registries (MDR). [En

línea]. http://metadata-stds.org/11179/

[44] ISO/IEC, "Information technology - Metadata registries (MDR), Part 4: Formulation of data

definitions," Estándar Internacional ISO/IEC 11179-4:2004(E), 2004.

[45] ISO/IEC, "Information technology - Metadata registries (MDR), Part 5: Naming and

identification principles," Estándar Internacional ISO/IEC 11179-5:2005(E), 2005.

[46] T. Berners-Lee. (2006, May.) Relational Databases and the Semantic Web (in Design Issues).

[En línea]. http://www.w3.org/DesignIssues/RDB-RDF.html

[47] G. Powell, Beginning Database Design. Wiley Publishing, Inc., 2006.

[48] M. Siegel y S. E. Madnick, "Schema Integration Using Metadata," Massachusetts Institute of

Technology Working paper, 1989.

[49] M. Horridge, H. Knublauch, A. Rector, R. Stevens, y C. Wroe, "A Practical Guide To Building

OWL Ontologies Using The Protégé-OWL Plugin and CO-ODE Tools," 2004.

Documents

cenidet20E… · Azucena Montes Rendón Jurado: Dr. Hugo Estrada Esquivel Presidente M.C. Mario Guillén Rodríguez Secretario M.C. Humberto Hernández García Vocal Cuernavaca, Morelos,