Using Correspondence Assertions for Specifying the Semantics of XML-Based Mediators

1. Using Correspondence Assertions for Specifying the Semantics of XML-Based Mediators • Presentadores: • Ignacio Duarte • Santiago Margni • Facultad de Ingeniería – Curso InterOperabilidad 2002

2. Using Correspondence Assertions for Specifying the Semantics of XML-Based Mediators • Este artículo fue presentado en Abril del 2001 en la conferencia “International WorkShop on Information Integration on the Web” realizada en Rio de Janeiro ,Brasil • Autores del artículo Vânia Maria Ponte Vidal (1) , Bernadette Farias Lóscio (2) Ana Carolina Salgado (2) (1) Departamento de Computação - Universidade Federal do Ceará (2) Centro de Informática - Universidade Federal de Pernambuco

3. Ámbito y Motivación del Trabajo Integración en Base de Datos Fuertemente estudiado en la literatura. Integración en la Web (Estudios recientes) Múltiples fuentes, autónomas, dinámicas, volátiles y heterogéneas. • Mediadores Las arquitecturas de integración de datos usualmente están basadas en mediadores. • Mediadores basados en XML (XML Document, DTD, XML Query) Dada la flexibilidad de XML para representar información estructurada y semi-estructurada, y la facilidad de convertir cualquier dato a XML, existe un creciente interés en usar XML como modelo común de datos para intercambio e integración. • Vista Integrada (Materializada vs. Virtual) Se consideran solo vistas integradas virtuales. Motivación: Aportar a la solución de utilizar XML como Mediador.

4. Objetivos Propuestos • Especificación Formal Propone especificar formalmente la relación entre el esquema mediado y los esquemas de las bases de datos de origen, a través del uso de las Correspondence assertions (CA). • Heterogeneidad semántica Mostrar como, a través de la especificación formal propuesta, se puede abordar el problema de la heterogeneidad semántica de las fuentes • Automatización (Integración de datos) Mostrar como la especificación formal propuesta favorece a la automatización de algunos aspectos de los sistemas de integración de información basados en XML. • Vista mediada (VM) Mostrar como las CA pueden ser usadas para ayudara a generar la definición de la vista mediada.

5. Repaso de Conceptos Mediador Un mediador es un sistema que soporta vistas integradas sobre múltiples fuentes de información. Ofrece el esquema de la vista integrada permitiendo consultas y actualizaciones sobre las bases de origen a través de él. Vista integrada virtual La vista integrada que ofrece el mediador puede ser virtual o materializada. En el enfoque virtual, los datos permanecen en las fuentes locales, y las consultas realizadas al mediador son descompuestas en tiempo de ejecución en consultas en las fuentes locales. Los resultados de estas consultas locales son traducidos, filtrados y combinados para entregar la respuesta final tanto al usuario como a la aplicación.

6. Proceso de generación de la vista mediada (VM) Mediated View Modeling (I) Mediated View Integration (II) Mediated view Definition (III) • Analizar los requerimientos del usuario y especificar el esquema de la VM usando un modelo de datos de alto nivel. (UCM model) • Integrar el esquema de la VM con los esquemas locales con el fin de identificar las CA que especifican formalmente la relación entre el esquema de la VM y los esquemas locales. Para lograr esto es necesario expresar ambos esquemas en un modelo común de datos. (UCM model) • Generar la definición de la VM, basada en el esquema encontrado en (I) y en las CA encontradas en (II). La definición de la VM consisten en una secuencia de reglas o consultas, que describen en forma declarativa como las consultas a través del esquema del mediador pueden ser mapeadas a consultas en las fuentes.

7. Terminología y Herramientas • UCM Model • El UCM Model se utiliza como un modelo de datos común para representar los esquemas de multiples fuentes de datos. • Data tree of a XML Document • El Data tree se utiliza para abstraer la información del documento XML. También es utilizada la noción de path expression para navegar siguiendo un camino en el árbol. • Tree Model • El Tree Model se utiliza para abstraer en un diagrama la estructura y las restricciones de integridad del esquema UCM. • Correspondence Assertion (CA) • XML QL • EL XML QL es un lenguaje de consulta especialmente diseñado para XML y permite consultar, traducir e integrar datos en XML.

8. <emergency1> <doctors1> <doctor1 id1= “d1”> <name1> John </name1> <phone1>1234</phone1> <SSN1> 414</SSN1> </doctor1> <doctors1> <patients1> <patient1 doc1= “d1” id1 =“p1”> <name1> Steve</name1> <phone1>5678</phone1> <SSN1> 134</SSN1> </patient1> <patient1 doc1= “d1” id1 =“p2”> <name1> Peter</name1> <phone1>8976</phone1> <SSN1> 214</SSN1> </patient1> <patients1> Unified Constraint Model for XML (UCM) Para ilustrar las ideas del modelo, considera el siguiente ejemplo acerca de pacientes y doctores del sector de emergencia de un hospital. • <!ELEMENT emergency1 (doctors1, patients1)> • <!ELEMENT doctors1 (doctor1) * > • <!ELEMENT patients1 (patient1) * > • <!ELEMENT doctor1 (name1, phone1, SSN1) > • <!ATTLIST doctor1 id1 ID #REQUIRED> • <!ELEMENT patient1 (name1, phone1, SSN1) > • <!ATTLIST patient 1 doc1 IDREF #REQUIRED • id1 ID #REQUIRED> • <!ELEMENT name1 #PCDATA> • <!ELEMENT phone1 #PCDATA> • <!ELEMENT SSN1 #PCDATA> XML data for the Emergency Sector DTD for the Emergency Sector

9. Unified Constraint Model for XML (UCM) (II) schema emergency = root Emergency1 type Emergency1 = emergency1 [ doctors1,patients1] type Doctors1 = doctors1 [ doctor1* ] type Patients1 = patients1 [ patient1* ] type Doctor1 = doctor1 [ @id1 [ ID ], name1 [ String ], phone1 [ String ], SSN1 [ String ] ] type Patient1 = patient1 [ @doc1 [ &[ID] ], @id1 [ ID ], name1 [ String ], phone1 [ String ], SSN1 [ String ] ] key Doctor1 [ | ./SSN1/data( ) | ] key Patient1 [ | ./SSN1/data( ) | ] foreign key Patient1 [ | ./doc1/&/ID( )| ] references Doctor1 [ | ./@id/ID( ) | ] • val doc0:Emergency1 = • emergency1 [ doctors1 [ doctor1 [ @id1 [ ^d1 ], • name1 [ “John” ], • phone1 [ “1234” ], • SSN1 [ “414” ] ] ], • patients1 [ patient1 [ @doc1 [ & [ ^d1 ] ] • @id1 [ ^p1 ], • name1 [ “Steve” ], • phone1 [ “5678” ], • SSN1 [ “134” ] ], • patient1 [ @doc1 [& [ ^d1 ] ], • @id1 [ ^p2 ], • name1 [ “Peter” ], • phone1 [ “8976” ], • SSN1 [ “214” ] ] ] ] UCM Schema for Emergency Sector The document doc0

10. Data tree of a XML Document Data Tree for document doc0 Path Expression El resultado de la path expression emergency1 /patients1 /patient1* contiene los nodos ^p1 ^p2. Considerando ahora el paciente ^p1 en emergency1 /patients1 /patient1* el resultado de ^p1/name1/data() es “Steve” El resultado de ^d1/(patient1*/doc1)-1 contiene el conjunto de todos los nodos ^p en emergency1 /patients1 /patient1* (camino inverso)

11. Tree Model The Tree model of the UCM Schema for the Emergency Sector • Negrita denota identificador de tipo • El símbolo & denota referencias especificadas como foreign key • El símbolo * denota múltiples ocurrencias de un elemento.

12. XML QL Las consultas en XML QL consisten en una cláusula WHERE que especifica lo que se quiere seleccionar y una cláusula CONSTRUCT, que especifica que debe devolver la consulta. Ejemplo: 1. <medM> 2. { WHERE <emergency1> 3. <patients1> 4. <patient1 doc1 = $i > 5. <name1> $g </> 6. <SSN1> $b </> 7. </> 8. </> 9. </>IN “emergency.xml” 10. <emergency1> 11. <doctors1> 12. <doctor1 id1 = $i > 13. <name1> $l</> 14. <SSN1> $k </> 15. </> 16. </> 17. </> IN “emergency.xml” • 18. CONSTRUCT <patientM ID = PAT_ID($b)> • 19. <nameM> $g </> • 20. <SSNM> $b </> • 21. <doctorM> • 22. <nameM> $l</> • 23. <SSNM> $k </> • 24. </> • 25. </> • 26. }

13. Construyendo la vista mediada (Paso I) Mediated View Modeling (I) Mediated View Integration (II) Mediated view Definition (III) Para ilustrar el proceso, supongamos que se cuenta con la especificación por parte del usuario del esquema de la VM “Med Schema”. En ella se integra la información a partir del “Emergency Schema” ya conocido con el esquema del Área de Cuidados Intensivos (“Intensive Care Schema”).

14. Modelando la vista mediada

15. Construyendo la vista mediada (Paso II) Mediated View Modeling (I) Mediated View Integration (II) Mediated view Definition (III) A partir del esquema común encontrado, el siguiente paso consiste en realizar la integración entre el esquema Med y los esquemas locales (Intensive Care y Emergency) utilizando las CA para definir las relaciones entre los mismos.

16. Construyendo la vista mediada (Paso II) El proceso de integración comienza con la especificación de la CA para el elemento raíz medM, el cual contiene un conjunto de patientM que son semánticamente equivalentes a elementos de emergency1 /patients1 /patient1* y/o elementos de intensivecare2 /patients2 /patient2* como se especifica en la siguiente CA: Y1: medM/patientM* ºemergency1/patients1/patient1* Èintensivecare2/patients2/patient2* Formalmente, Y1 especifica que: - Para cada elemento p1 en emergency1/patients1/patient1* existe un p en medM/patientM* tal que p º p1 - Para cada elemento p2 en intensivecare2/patients2/patient2* existe un p’ en medM/patientM* tal que p’ º p2 Criterio para realizar el object matching: Un patientM pMen medM/patientM* machea un patient1 p1en emergency1/patients1/patient1* si y solo si pM/SSNM/data() = p1/SSN1/data(). Ver imágen

17. Construyendo la vista mediada (Paso II) Dado que patientM es semánticamente equivalente a patient1 se deben especificar las CA de los subelementos de patientM con los subelementos de patient1. Y2: patient1/name1º patientM/nameM Y3: patient1/SSN1º patientM/SSNM Y4: patient1/doc1Î patientM/doctorM* Formalmente: Para cada elemento p1 en emergency1/patients1/patient1* si existe un p en medM/patientM* tal que p º p1 entonces: Ver imágen • p contienen un elemento nameMtal que p/nameM/data() = p1/name1/data() (Y2) • p contienen un elemento SSNMtal que p/SSNM/data() = p1/SSN1/data() (Y3) • Existe un d en p/doctorM* tal que d ºp1/doc1 (Y4)

18. Construyendo la vista mediada (Paso II) Y1: medM/patientM* º emergency1/patients1/patient1* È intensivecare2/patients2/patient2 Y2: patient1/name1º patientM/nameM Y3: patient1/SSN1º patientM/SSNM Y4: patient1/doc1Î patientM/doctorM* Y5: doctor1/name1º doctorM/nameM(similar a Y2 ) Y6: doctor1/SSN1º doctorM/SSNM(similar a Y3 ) Y7: patient2/name2º patientM/nameM(similar a Y2 ) Y8: patient2/SSN2º patientM/SSNM(similar a Y3 ) Y9: patient2/(docpat2/pat2/&Patient2)-1/doc2Ì patientM/doctorM. Y10: doctor2/name2º doctorM/nameM(similar a Y2 ) Y11: doctor2/SSN2º doctorM/SSNM(similar a Y3 ). Ver imágen

19. Construyendo la vista mediada (Paso III) Mediated View Modeling (I) Mediated View Integration (II) Mediated view Definition (III) El último paso consiste en la generación de la definición de la VM. La cual se genera a partir del esquema de la VM, y las CA del mediador. En esta caso se utiliza XML-QL para la definición de la VM, pero se podría utilizar cualquier otro lenguaje.

20. Definición de la vista mediada (Paso III) Ver CA Ver imágen

21. Definición de la vista mediada (Paso III) Ver imágen

22. Conclusiones de los autores • Las ventajas de tener una especificación de alto nivel para el mediador, son la independencia del lenguaje con que se implementara el mismo, y la “facilidad” que brinda para “entender” la semántica asociada al mediador. • Es posible utilizar las CApara ayudar a generar la VM • Se puede llegar a probar formalmente que la definición de la VM implementa correctamente la especificación del mediador • El formalismo presentado puede manejar el tema de la heterogeneidad semántica. • La especificación semántica del mediador, puede ser usada también para automatizar otros aspectos de la integración de datos, como ser el mantenimiento de la definición de la VM.

23. Nuestras conclusiones • El articulo propone una solución teórica-práctica a un problema, importante, actual, y en creciente difusión. • Nos brinda un importante aporte técnico con las herramientas utilizadas: • UCM • Data Tree y PathExpression • Tree • XML Document, XML DTD y XML-QL • La importancia de la existencia de un formalismo. • Permite probar formalmente la correctitud • Brinda una metodología para lograr abstraer la información • Facilidad para automatizar mantenimiento

24. Nuestras conclusiones (II) • El ejemplo • Si bien compartimos que la metodología, ayuda a especificar este tipo de problemas y como se pueden llegar a resolver, el ejemplo presentado es bastante simple, por lo cual no queda a priori de manifiesto la potencia del mismo. • Puntos débiles del enfoque • No demuestra la correctitud del formalismo • No queda de manifiesto la completitud del método • No se discute en profundidad como favorecer la automatización en las tareas de integración. • No tiene en cuenta el problema de representación en datos de fuentes heterogéneas • Omite el pasaje de los diferentes esquemas al UCM model

25. Referencias [1] S. Chawathe, H. Garcia Molina, J. Hammer. The TSIMMIS Project: Integration of Heterogeneous Information Sources. In Proc. of 10th Meeting of the Information Processing Society of Japan (IPSJ), oct. 1994. [2] M. Genesereth, A. Keller, O. Dushka. Infomaster: an information integration system. In Proc. of ACM SIGMOD International Conf. on Management of Data, p. 539-542, Tucson, Arizona, may 1997. [3] C. K. Baru, A. Gupta, B. Ludascher, R. Marciano, Y. Papakostatinou, P. Velikhov, V. Chu. XML-Based Information Mediation with MIX. In Proc. of ACM SIGMOD Conf. On Management of Data, p. 597-599, Philadephia, Pennsylvania, jun.1999. [4] T. Bray, J. Paoli, C. M. Sperberg-McQueen. Extensible markup language (XML) 1.0. W3C recommendation, Feb. 1998. http://www.w3c.org/TR/REC-xml/. [5] R. Hull. Managing Semantic Heterogeneity in Databases: A Theoretical Perspective. In Proc. of ACM Symp. on Principles of Database Systems, p. 51-61, 1997. [6] A. Deutsch, M. Fernandez, D. Florescu, A. Levy , D. Suciu. XML-QL: A Query Language for XML. In Proc. of International World Wide Web Conference, Toronto, may 1999. [7] S. Spaccapietra, C. Parent. View Integration: A Step Forward in Solving Structural Conflicts. IEEE Trans. on Software Engineering, v. 6, n. 2, apr. 1994.

26. Referencias (II) [8] S. Cluet, C. Delobel, J. Siméon, K. Smaga. Your mediators need data conversion! In Proc of ACM SIGMOD Conference on Management of Data, p. 177-188, Seattle, Washington, jun. 1998. [9] V. Christophides, S. Cluet, J. Siméon. On Wrapping Query Languages and Efficient XML Integration. In Proc. of ACM SIGMOD Conf. on Management of Data, p. 141-152, Dallas, Texas, USA, may 2000. [10] D.Lee, W. W. Chu. Comparative Analysis of Six XML Schema Languages, SIGMOD Record, v.29, n.3, p. 76-87, mar. 2000. [11] Y. Papakinstantinou, S. Abiteboul, H. Garcia Molina. Object fusion in mediator systems. In Proc. of International Conference on Very Large Datanases (VLDB), p. 413-424 , Bombay, India, sept. 1996. [12] W. Fan, G.M. Kuper and J. Siméon, A Unified Constraint Model for XML. To appear in the Tenth International World Wide Web Conference (WWW'10), may 2001, Hong Kong, China. [13] P. Fankhauser, M. Fern andez, A. Malhotra, M. Rys, J. Sim_eon, and P. Wadler. The XML query algebra. W3C Working Draft, Feb. 2001. http://www.w3.org/TR/query-algebra/.