Post on 14-Mar-2018
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.31. (QUERYD2R_CP-02) Consulta SPARQL generada para servidor1 ................................ 115
Figura 6.32. (QUERYD2R_CP-02) Resultados .................................................................................. 116
Figura 6.33. (QUERYD2R_CP-03) Resumen de consulta.................................................................. 117
Figura 6.34. (QUERYD2R_CP-03) Consulta SPARQL generada para servidor1 ................................ 117
Figura 6.35. (QUERYD2R_CP-03) Resultados .................................................................................. 118
Figura 6.36. (QUERYD2R_CP-04) Resumen de consulta.................................................................. 119
Figura 6.37. (QUERYD2R_CP-04) Consulta SPARQL generada para servidor1 ................................ 119
Figura 6.38. (QUERYD2R_CP-04) Consulta SPARQL generada para servidor2, se observa la
conversión del parámetro ............................................................................................................... 120
Figura 6.39. (QUERYD2R_CP-04) Resultados .................................................................................. 120
Figura 6.40. (QUERYD2R_CP-05) Resumen de consulta.................................................................. 121
Figura 6.41. (QUERYD2R_CP-05) Consulta SPARQL generada para servidor1, se observa la
conversión del parámetro ............................................................................................................... 122
Figura 6.42. (QUERYD2R_CP-05) Consulta SPARQL generada para servidor2 ................................ 122
Figura 6.43. (QUERYD2R_CP-05) Resultados .................................................................................. 122
Figura 6.44. (QUERYD2R_CP-06) Resumen de consulta.................................................................. 124
Figura 6.45. (QUERYD2R_CP-06) Consulta SPARQL generada para servidor1 ................................ 124
Figura 6.46. (QUERYD2R_CP-06) Resultados .................................................................................. 124
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
Figura 6.51. (QUERYD2R_CP-07) Resumen de consulta2................................................................ 128
Figura 6.52. (QUERYD2R_CP-07) Consulta2 SPARQL generada para servidor1 .............................. 128
Figura 6.53. (QUERYD2R_CP-07) Resultados de consulta2 ............................................................. 128
Figura 6.54. (QUERYD2R_CP-07) Resumen de consulta3................................................................ 129
Figura 6.55. (QUERYD2R_CP-07) Consulta3 SPARQL generada para servidor1 .............................. 129
Figura 6.56. (QUERYD2R_CP-07) Resultados de consulta3 ............................................................. 129
Figura 6.57. (QUERYD2R_CP-07) Resumen de consulta4................................................................ 130
Contenido
vii
Figura 6.58. (QUERYD2R_CP-07) Consulta4 SPARQL generada para servidor1 .............................. 130
Figura 6.59. (QUERYD2R_CP-07) Resultados de consulta4 ............................................................. 130
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
Tabla 5.13. Entradas para el caso de prueba 02 ............................................................................... 75
Tabla 5.14. Salidas para el caso de prueba 02 .................................................................................. 76
Tabla 5.15. Entradas para el caso de prueba 03 ............................................................................... 78
Tabla 5.16. Salidas para el caso de prueba 03 .................................................................................. 78
Tabla 5.17. Entradas para el caso de prueba 04 ............................................................................... 82
Tabla 5.18. Salidas para el caso de prueba 04 .................................................................................. 82
Tabla 5.19. Entradas para el caso de prueba 05 ............................................................................... 83
Tabla 5.20. Salidas para el caso de prueba 05 .................................................................................. 83
Tabla 5.21. Entradas para el caso de prueba 06 ............................................................................... 88
Tabla 5.22. Salidas para el caso de prueba 06 .................................................................................. 88
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.
Capítulo 1 - Introducción
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,
Capítulo 1 - Introducción
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
Capítulo 1 - Introducción
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
Capítulo 2 – Marco teórico
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.
Capítulo 2 – Marco teórico
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.
Capítulo 2 – Marco teórico
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/
Capítulo 2 – Marco teórico
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
Capítulo 2 – Marco teórico
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.
Capítulo 2 – Marco teórico
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.
Capítulo 2 – Marco teórico
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.
Capítulo 2 – Marco teórico
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.
Capítulo 2 – Marco teórico
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
Capítulo 3 – Estado del arte
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
Capítulo 3 – Estado del arte
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
Capítulo 3 – Estado del arte
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.
Capítulo 3 – Estado del arte
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.
Capítulo 3 – Estado del arte
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]
Capítulo 3 – Estado del arte
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
Capítulo 4 – Análisis del problema y diseño de la solución
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:
Capítulo 4 – Análisis del problema y diseño de la solución
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.
Capítulo 4 – Análisis del problema y diseño de la solución
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.
Capítulo 4 – Análisis del problema y diseño de la solución
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.
Capítulo 4 – Análisis del problema y diseño de la solución
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.
Capítulo 4 – Análisis del problema y diseño de la solución
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/
Capítulo 4 – Análisis del problema y diseño de la solución
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
Capítulo 4 – Análisis del problema y diseño de la solución
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)
9 llaves primarias (-4)
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)
15 llaves primarias (-5)
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
Capítulo 4 – Análisis del problema y diseño de la solución
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
Características Proporcionado por
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
Características Proporcionado por
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
Capítulo 4 – Análisis del problema y diseño de la solución
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.
Capítulo 4 – Análisis del problema y diseño de la solución
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].
Capítulo 4 – Análisis del problema y diseño de la solución
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.
Capítulo 4 – Análisis del problema y diseño de la solución
41
Figura 4.6. Resumen de las propiedades y las restricciones de propiedades de la ontología ontDom
Capítulo 4 – Análisis del problema y diseño de la solución
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.
Capítulo 4 – Análisis del problema y diseño de la solución
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.
Capítulo 5 – Doc-D2R - Software de documentación
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
Capítulo 5 – Doc-D2R - Software de documentació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
Actor: Documentador.
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.
Capítulo 5 – Doc-D2R - Software de documentación
49
Tabla 5.3. Descripción de cu2.1_escogerAliasTabla
cu2.1_escogerAliasTabla
Actor: Documentador.
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.
5) El actor presiona el botón de aceptar.
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.
(fa2) En cualquier momento el actor presiona el botón de cancelar y la aplicación
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
Actor: Documentador.
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.
7) El actor presiona el botón de aceptar.
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.
(fa2) En cualquier momento el actor presiona el botón de cancelar y la aplicación
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.
Capítulo 5 – Doc-D2R - Software de documentación
50
Tabla 5.5. Descripción de cu2.3_escogerUnidadMedida
cu2.3_escogerUnidadMedida
Actor: Documentador.
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.
8) El actor presiona el botón de aceptar.
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.
(fa2) En cualquier momento el actor presiona el botón de cancelar y la aplicación
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
Actor: Documentador.
Descripción: Genera un reporte de documentación.
Precondición: La aplicación debe tener un proyecto configurado.
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.
Capítulo 5 – Doc-D2R - Software de documentación
51
Tabla 5.7. Descripción de cu4_generarMapeoD2RQ
cu4_generarMapeoD2RQ
Actor: Documentador.
Descripción: Genera un archivo de mapeo D2RQ.
Precondición: La aplicación debe tener un proyecto configurado.
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
Actor: Documentador.
Descripción: Guarda un archivo de proyecto Doc-D2R.
Precondición: La aplicación debe tener un proyecto configurado.
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.
Capítulo 5 – Doc-D2R - Software de documentación
52
Tabla 5.9. Descripción de cu6_abrirProyecto
cu6_abrirProyecto
Actor: Documentador.
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.
Capítulo 5 – Doc-D2R - Software de documentación
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
Capítulo 5 – Doc-D2R - Software de documentación
54
Figura 5.4. Diagrama de actividades de cu2_documentar
Capítulo 5 – Doc-D2R - Software de documentación
55
Figura 5.5. Diagrama de actividades de cu2.1_escogerAliasTabla
Figura 5.6. Diagrama de actividades de cu2.2_escogerAliasColumna
Capítulo 5 – Doc-D2R - Software de documentación
56
Figura 5.7. Diagrama de actividades de cu2.3_escogerUnidadMedida
Figura 5.8. Diagrama de actividades de cu3_generarReporte
Capítulo 5 – Doc-D2R - Software de documentación
57
Figura 5.9. Diagrama de actividades de cu4_generarMapeoD2RQ
Figura 5.10. Diagrama de actividades de cu5_guardarProyecto
Capítulo 5 – Doc-D2R - Software de documentación
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.
Capítulo 5 – Doc-D2R - Software de documentación
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.
Capítulo 5 – Doc-D2R - Software de documentación
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
Capítulo 5 – Doc-D2R - Software de documentación
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
Capítulo 5 – Doc-D2R - Software de documentación
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.
Capítulo 5 – Doc-D2R - Software de documentación
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.
Capítulo 5 – Doc-D2R - Software de documentación
64
Capítulo 5 – Doc-D2R - Software de documentación
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:
docbdd2r.documentacion.
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:
docbdd2r.documentacion.
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
Capítulo 5 – Doc-D2R - Software de documentación
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
Capítulo 5 – Doc-D2R - Software de documentación
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).
Capítulo 5 – Doc-D2R - Software de documentación
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).
Capítulo 5 – Doc-D2R - Software de documentación
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
Capítulo 5 – Doc-D2R - Software de documentación
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.
Capítulo 5 – Doc-D2R - Software de documentación
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
Capítulo 5 – Doc-D2R - Software de documentación
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
Características a probar
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.
Capítulo 5 – Doc-D2R - Software de documentación
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.
Capítulo 5 – Doc-D2R - Software de documentación
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
Capítulo 5 – Doc-D2R - Software de documentación
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
Identificador del caso de prueba
DOCBD_CP-02
Características a probar
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.
Entradas Tabla 5.13. Entradas para el caso de prueba 02
Característica Entrada Observaciones
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.
Capítulo 5 – Doc-D2R - Software de documentación
76
Salidas Tabla 5.14. Salidas para el caso de prueba 02
Característica Salida Observaciones
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.
Procedimiento de prueba
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.
Capítulo 5 – Doc-D2R - Software de documentación
77
Seleccionar nodo de magnitud Longitud, verificar la carga de unidades de medida.
Cancelar.
Dependencias de caso de prueba
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
Capítulo 5 – Doc-D2R - Software de documentación
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
Identificador del caso de prueba
DOCBD_CP-03
Características a probar
a) Documentación de tablas.
b) Documentación de columnas.
Entradas Tabla 5.15. Entradas para el caso de prueba 03
Característica Entrada Observaciones
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.
Salidas Tabla 5.16. Salidas para el caso de prueba 03
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.
Capítulo 5 – Doc-D2R - Software de documentación
79
Procedimiento de prueba
Continuar desde: DOCBD_CP-02.
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.
Pulsar agregar alias de tabla y verificar la apertura del formulario de elección de alias.
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.
Pulsar agregar alias de tabla y verificar la apertura del formulario de elección de alias.
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).
Dependencias de caso de prueba
Dependencia con el caso 01 y 02.
Capítulo 5 – Doc-D2R - Software de documentación
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
Capítulo 5 – Doc-D2R - Software de documentación
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
Capítulo 5 – Doc-D2R - Software de documentación
82
5.4.2.4. Caso de prueba 04: Presentación del reporte de documentación
Identificador del caso de prueba
DOCBD_CP-04
Características a probar
a) Presentación en pantalla del reporte de documentación.
Entradas Tabla 5.17. Entradas para el caso de prueba 04
Característica Entrada Observaciones
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.
Salidas Tabla 5.18. Salidas para el caso de prueba 04
Característica Salida Observaciones
a. Presentación en pantalla
del reporte.
La vista debe abrirse en una instancia del navegador
web predeterminado.
Procedimiento de prueba
Pulsar botón generar documentación de la barra de herramientas del formulario principal.
Dependencias de caso de prueba
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
Capítulo 5 – Doc-D2R - Software de documentación
83
5.4.2.5. Caso de prueba 05: Generación de mapeo D2RQ
Identificador del caso de prueba
DOCBD_CP-05
Características a probar
a) Creación y presentación en pantalla del archivo de mapeo D2RQ.
Entradas Tabla 5.19. Entradas para el caso de prueba 05
Característica Entrada Observaciones
a. Documento de proyecto. Doc-D2R toma el documento de proyecto actual.
Salidas Tabla 5.20. Salidas para el caso de prueba 05
Característica Salida Observaciones
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.
Procedimiento de prueba
Continuar desde: DOCBD_CP-03.
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.
Capítulo 5 – Doc-D2R - Software de documentación
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.
Dependencias de caso de prueba
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
Capítulo 5 – Doc-D2R - Software de documentación
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
Capítulo 5 – Doc-D2R - Software de documentación
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
Capítulo 5 – Doc-D2R - Software de documentación
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
Capítulo 5 – Doc-D2R - Software de documentación
88
5.4.2.6. Caso de prueba 06: Generación de archivo de proyecto
Identificador del caso de prueba
DOCBD_CP-06
Características a probar
a) Creación y guardado de archivo de proyecto.
b) Carga de archivo de proyecto.
Entradas Tabla 5.21. Entradas para el caso de prueba 06
Característica Entrada Observaciones
a. Documento de proyecto. Doc-D2R toma el documento de proyecto actual.
b. Archivo con extensión “dbd”. No tiene.
Salidas Tabla 5.22. Salidas para el caso de prueba 06
Característica Salida Observaciones
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.
Procedimiento de prueba
Continuar desde: DOCBD_CP-05.
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.
Capítulo 5 – Doc-D2R - Software de documentación
89
Dependencias de caso de prueba
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
Capítulo 5 – Doc-D2R - Software de documentación
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.
Capítulo 6 – Query-D2R - Software de consulta
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.
Capítulo 6 – Query-D2R - Software de consulta
94
Tabla 6.2. Descripción de cu2_construirConsulta
cu2_construirConsulta
Actor: Usuario genérico.
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
Actor: Usuario genérico.
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.
Flujo alternativo: No tiene.
Poscondición: El filtro de texto es agregado a la subconsulta.
Capítulo 6 – Query-D2R - Software de consulta
95
Tabla 6.4. Descripción de cu2.2_establecerFiltroLista
cu2.2_establecerFiltroLista
Actor: Usuario genérico.
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.
4) 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 lista.
Flujo alternativo: No tiene.
Poscondición: El filtro de lista es agregado a la subconsulta.
Tabla 6.5. Descripción de cu2.3_establecerFiltroNumerico
cu2.3_establecerFiltroNumerico
Actor: Usuario genérico.
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.
5) La aplicación agrega el tipo de filtro y los valores de los parámetros a la
subconsulta y cierra el formulario de filtros numéricos.
Flujo alternativo: No tiene.
Poscondición: El filtro numérico es agregado a la subconsulta.
Tabla 6.6. Descripción de cu3_ejecutarConsulta
cu3_ejecutarConsulta
Actor: Usuario genérico.
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.
Capítulo 6 – Query-D2R - Software de consulta
96
Véase cu3.2_presentarResultados.
Flujo alternativo: No tiene.
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
Actor: Usuario genérico.
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.
Flujo alternativo: No tiene.
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
Actor: Usuario genérico.
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.
Flujo alternativo: No tiene.
Poscondición: Los resultados son presentados en un componente de tipo tabla.
Capítulo 6 – Query-D2R - Software de consulta
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.
Capítulo 6 – Query-D2R - Software de consulta
98
Figura 6.2. Diagrama de componentes de Query-D2R
Figura 6.3. Diagrama de actividades de cu1_configurar
Capítulo 6 – Query-D2R - Software de consulta
99
Figura 6.4. Diagrama de actividades de cu2_construirConsulta
Capítulo 6 – Query-D2R - Software de consulta
100
Figura 6.5. Diagrama de actividades de cu2.1_establecerFiltroTexto
Figura 6.6. Diagrama de actividades de cu2.2_establecerFiltroLista
Capítulo 6 – Query-D2R - Software de consulta
101
Figura 6.7. Diagrama de actividades de cu2.1_establecerFiltroNumerico
Capítulo 6 – Query-D2R - Software de consulta
102
Figura 6.8. Diagrama de actividades de cu3_ejecutarConsulta
Figura 6.9. Diagrama de actividades de cu3.2_presentarResultados
Capítulo 6 – Query-D2R - Software de consulta
103
Figura 6.10. Diagrama de actividades de cu3.1_transformarConsulta
Capítulo 6 – Query-D2R - Software de consulta
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
Capítulo 6 – Query-D2R - Software de consulta
105
Figura 6.12. Diagrama de clases de Query-D2R
Capítulo 6 – Query-D2R - Software de consulta
106
Sujeto
Ruta de paquete:
queryd2r.construccion
Descripción:
Administra los datos de sujeto y la lista de
predicados.
Figura 6.13. Clase Sujeto
Predicado
Ruta de paquete:
queryd2r.construccion
Descripción:
Administra los datos de predicado y el objeto
relacionado.
Figura 6.14. Clase Predicado
Consulta
Ruta de paquete:
queryd2r.construccion
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
Capítulo 6 – Query-D2R - Software de consulta
107
Subconsulta
Ruta de paquete:
queryd2r.construccion
Descripción:
Administra los valores de una subconsulta:
sujeto, predicado, objeto, variables y filtro.
Figura 6.17. Clase Subconsulta
FiltroLiteral
Ruta de paquete:
queryd2r.construccion
Descripción:
Administra los datos de filtro de texto o
numérico.
Figura 6.18. Clase FiltroLiteral
Capítulo 6 – Query-D2R - Software de consulta
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
Capítulo 6 – Query-D2R - Software de consulta
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
Capítulo 6 – Query-D2R - Software de consulta
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.
Características a probar
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).
Capítulo 6 – Query-D2R - Software de consulta
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
Identificador del caso de prueba
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.
Capítulo 6 – Query-D2R - Software de consulta
112
Características a probar
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.
Procedimiento de prueba
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.
Agregar nuevo servidor.
Escribir los datos del servidor y documentación de SiCEWin, mantener la pestaña en
Activo.
Agregar nuevo servidor.
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.
Dependencias de caso de prueba
No tiene.
Resultados
Prueba exitosa
Capítulo 6 – Query-D2R - Software de consulta
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
Capítulo 6 – Query-D2R - Software de consulta
114
Figura 6.28. (QUERYD2R_CP-01) Resultados
6.4.2.2. Caso de prueba 02
Identificador del caso de prueba
QUERYD2R_CP-02
Características a probar
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.
Elementos de bases de datos relacionados
SiCEWin.especialidad
SiCEWin.carrera.Descripcion (varchar)
Procedimiento de prueba
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.
Capítulo 6 – Query-D2R - Software de consulta
115
Dependencias de caso de prueba
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
Figura 6.31. (QUERYD2R_CP-02) Consulta SPARQL generada para servidor1
Capítulo 6 – Query-D2R - Software de consulta
116
Figura 6.32. (QUERYD2R_CP-02) Resultados
6.4.2.3. Caso de prueba 03
Identificador del caso de prueba
QUERYD2R_CP-03
Características a probar
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.
Elementos de bases de datos relacionados
SiCEWin.alumno
SiCEWin.inscripcion
SiCEWin.grupo
SiCEWin.grupoprofe
SiCEWin.profesor.Nombre (varchar)
Prepa.estudiante
Prepa.calificacion
Prepa.grupo
Prepa.maestro.nombre (nvarchar)1
Procedimiento de prueba
Continuar desde: QUERYD2R_CP-02.
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.
Capítulo 6 – Query-D2R - Software de consulta
117
Agregar subsonsulta: Alumno-tomaClaseCon-Profesor.
Agregar subsonsulta: Profesor1-tieneNombreCompleto-valorTexto (contiene
“Santoloaya”).
Ejecutar consulta.
Escoger variable Alumno1.
Dependencias de caso de prueba
Dependencia con el caso 01, configuración inicial de servidores y ontología.
Resultados
Prueba exitosa
Figura 6.33. (QUERYD2R_CP-03) Resumen de consulta
Figura 6.34. (QUERYD2R_CP-03) Consulta SPARQL generada para servidor1
Capítulo 6 – Query-D2R - Software de consulta
118
Figura 6.35. (QUERYD2R_CP-03) Resultados
6.4.2.4. Caso de prueba 04
Identificador del caso de prueba
QUERYD2R_CP-04
Características a probar
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.
Elementos de bases de datos relacionados
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)
Procedimiento de prueba
Continuar desde: QUERYD2R_CP-03.
Limpiar consulta.
Agregar subsonsulta: Alumno-tieneInscripcion-Inscripcion.
Capítulo 6 – Query-D2R - Software de consulta
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.
Dependencias de caso de prueba
Dependencia con el caso 01, configuración inicial de servidores y ontología.
Resultados
Prueba exitosa
Figura 6.36. (QUERYD2R_CP-04) Resumen de consulta
Figura 6.37. (QUERYD2R_CP-04) Consulta SPARQL generada para servidor1
Capítulo 6 – Query-D2R - Software de consulta
120
Figura 6.38. (QUERYD2R_CP-04) Consulta SPARQL generada para servidor2, se observa la conversión del parámetro
Figura 6.39. (QUERYD2R_CP-04) Resultados
6.4.2.5. Caso de prueba 05
Identificador del caso de prueba
QUERYD2R_CP-05
Características a probar
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.
Capítulo 6 – Query-D2R - Software de consulta
121
Elementos de bases de datos relacionados
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)
Procedimiento de prueba
Continuar desde: QUERYD2R_CP-04.
Limpiar consulta.
Agregar subsonsulta: Alumno-tieneInscripcion-Inscripcion.
Agregar subsonsulta: Inscripcion1-tieneValorCalificacion-valoNumérico (menor a 60 en
unidad “calif0-100”).
Agregar subsonsulta: Alumno1-tieneApellidoPaterno-valorTexto (igual a “Bañuelos”).
Agregar subsonsulta: Alumno1-tieneNombre-valorTexto (contiene “edgar”).
Ejecutar consulta.
Escoger variable Inscripcion1.
Dependencias de caso de prueba
Dependencia con el caso 01, configuración inicial de servidores y ontología.
Resultados
Prueba exitosa
Figura 6.40. (QUERYD2R_CP-05) Resumen de consulta
Capítulo 6 – Query-D2R - Software de consulta
122
Figura 6.41. (QUERYD2R_CP-05) Consulta SPARQL generada para servidor1, se observa la conversión del parámetro
Figura 6.42. (QUERYD2R_CP-05) Consulta SPARQL generada para servidor2
Figura 6.43. (QUERYD2R_CP-05) Resultados
Capítulo 6 – Query-D2R - Software de consulta
123
6.4.2.6. Caso de prueba 06
Identificador del caso de prueba
QUERYD2R_CP-06
Características a probar
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.
Elementos de bases de datos relacionados
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)
Procedimiento de prueba
Continuar desde: QUERYD2R_CP-05.
Limpiar consulta.
Agregar subsonsulta: Alumno-tomaClaseCon-Profesor.
Agregar subsonsulta: Profesor1-tieneNombreCompleto-valorTexto (contiene
“Santoloaya”).
Agregar subsonsulta: Alumno1-tieneSexo-valorTexto (elegido por lista, igual a
“masculino”).
Ejecutar consulta.
Escoger variable Alumno1.
Dependencias de caso de prueba
Dependencia con el caso 01, configuración inicial de servidores y ontología.
Resultados
Prueba exitosa
Capítulo 6 – Query-D2R - Software de consulta
124
Figura 6.44. (QUERYD2R_CP-06) Resumen de consulta
Figura 6.45. (QUERYD2R_CP-06) Consulta SPARQL generada para servidor1
Figura 6.46. (QUERYD2R_CP-06) Resultados
Capítulo 6 – Query-D2R - Software de consulta
125
6.4.2.7. Caso de prueba 07
Identificador del caso de prueba
QUERYD2R_CP-07
Características a probar
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.
Elementos de bases de datos relacionados
Varios.
Procedimiento de prueba
Continuar desde: QUERYD2R_CP-06.
Limpiar consulta.
Agregar subsonsulta: Alumno-tomaClaseCon-Profesor.
Agregar subconsulta: Alumno1-realizaTesis-Tesis.
Agregar subconsulta: Profesor1-dirigeTesis-Tesis1.
Agregar subconsulta: Profesor1-tieneNombreCompleto-valorTexto (contiene “Zárate”).
Ejecutar consulta.
Escoger variable Alumno1.
Seleccionar primer resultado.
Abrir en navegador.
Cerrar resultados.
Limpiar consulta.
Agregar subsonsulta: Alumno-tieneInscripcion-Inscripcion.
Agregar subsonsulta: Inscripcion1-tieneValorCalificacion-valoNumérico (menor a 80 en
unidad “calif0-100”).
Agregar subsonsulta: Inscripcion1-tieneMateria-Materia.
Agregar subsonsulta: Materia1-tieneNombreMateria-valorTexto (igual a “Español”).
Capítulo 6 – Query-D2R - Software de consulta
126
Ejecutar consulta.
Escoger variable Alumno1.
Cerrar resultados.
Limpiar consulta.
Agregar subsonsulta: Alumno-realizaTesis-Tesis.
Agregar subsonsulta: Alumno1-tieneApellidoPaterno-valorTexto (igual a “Bañuelos”).
Agregar subsonsulta: Alumno1-tieneNombre-valorTexto (contiene “edgar”).
Ejecutar consulta.
Escoger variable Tesis1.
Cerrar resultados.
Limpiar consulta.
Agregar subsonsulta: Alumno-tomaClaseCon-Profesor.
Agregar subsonsulta: Alumno1-tieneApellidoPaterno-valorTexto (igual a “Bañuelos”).
Ejecutar consulta.
Escoger variable Profesor1.
Dependencias de caso de prueba
Dependencia con el caso 01, configuración inicial de servidores y ontología.
Resultados
Prueba exitosa
Figura 6.47. (QUERYD2R_CP-07) Resumen de consulta1
Capítulo 6 – Query-D2R - Software de consulta
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
Capítulo 6 – Query-D2R - Software de consulta
128
Figura 6.51. (QUERYD2R_CP-07) Resumen de consulta2
Figura 6.52. (QUERYD2R_CP-07) Consulta2 SPARQL generada para servidor1
Figura 6.53. (QUERYD2R_CP-07) Resultados de consulta2
Capítulo 6 – Query-D2R - Software de consulta
129
Figura 6.54. (QUERYD2R_CP-07) Resumen de consulta3
Figura 6.55. (QUERYD2R_CP-07) Consulta3 SPARQL generada para servidor1
Figura 6.56. (QUERYD2R_CP-07) Resultados de consulta3
Capítulo 6 – Query-D2R - Software de consulta
130
Figura 6.57. (QUERYD2R_CP-07) Resumen de consulta4
Figura 6.58. (QUERYD2R_CP-07) Consulta4 SPARQL generada para servidor1
Figura 6.59. (QUERYD2R_CP-07) Resultados de consulta4
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)
Nombre de columna Tipo comprimido
materia
clave_materia int
nombre nvarchar(50)
Nombre de columna Tipo comprimido
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)
Nombre de columna Tipo comprimido
calificacion
clave_estudiante int
calificacion float
id_carga_grupo int
Nombre de columna Tipo comprimido
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
Anexo A – Diagramas de bases de datos de prueba
137
Figura A.3. Diagrama de base de datos genWeb
Anexo A – Diagramas de bases de datos de prueba
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.