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 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. Ámbito y Motivación del Trabajo

4 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. Objetivos Propuestos

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 Mediated View Modeling (I) Mediated View Integration (II) Mediated view Definition (III) Proceso de generación de la vista mediada (VM) I)Analizar los requerimientos del usuario y especificar el esquema de la VM usando un modelo de datos de alto nivel. (UCM model) II)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) III)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 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. Terminología y Herramientas

8 Unified Constraint Model for XML (UCM) John 1234 414 Steve 5678 134 Peter 8976 214 Para ilustrar las ideas del modelo, considera el siguiente ejemplo acerca de pacientes y doctores del sector de emergencia de un hospital. XML data for the Emergency SectorDTD for the Emergency Sector

9 Unified Constraint Model for XML (UCM) (II) 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” ] ] ] ] 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( ) | ] UCM Schema for Emergency SectorThe document doc0

10 Path Expression El resultado de la path expression emergency 1 /patients 1 /patient 1 * contiene los nodos ^p 1 ^p 2. Considerando ahora el paciente ^p 1 en emergency 1 /patients 1 /patient 1 * el resultado de ^p 1 /name 1 /data() es “Steve” El resultado de ^d 1 /(patient 1 */doc 1 ) -1 contiene el conjunto de todos los nodos ^p en emergency 1 /patients 1 /patient 1 * (camino inverso) Data tree of a XML Document Data Tree for document doc0

11 Tree Model The Tree model of the UCM Schema for the Emergency Sector 1)Negrita denota identificador de tipo 2)El símbolo & denota referencias especificadas como foreign key 3)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: 18. CONSTRUCT 19. $g 20. $b 21. 22. $l 23. $k 24. 25. 26. } 1. 2. { WHERE 3. 4. 5. $g 6. $b 7. 8. 9. IN “emergency.xml” 10. 11. 12. 13. $l 14. $k 15. 16. 17. IN “emergency.xml”

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 med M, el cual contiene un conjunto de patient M que son semánticamente equivalentes a elementos de emergency 1 /patients 1 /patient 1 * y/o elementos de intensivecare 2 /patients 2 /patient 2 * como se especifica en la siguiente CA:  1: med M /patient M *  emergency 1 /patients 1 /patient 1 *  intensivecare 2 /patients 2 /patient 2 * Formalmente,  1 especifica que: - Para cada elemento p 1 en emergency 1 /patients 1 /patient 1 * existe un p en med M /patient M * tal que p  p 1 - Para cada elemento p 2 en intensivecare 2 /patients 2 /patient 2 * existe un p’ en med M /patient M * tal que p’  p 2 Criterio para realizar el object matching: Un patient M p M en med M /patient M * machea un patient 1 p 1 en emergency 1 /patients 1 /patient 1 * si y solo si p M /SSN M /data() = p 1 /SSN 1 /data(). Ver imágen

17 Construyendo la vista mediada (Paso II) Dado que patient M es semánticamente equivalente a patient 1 se deben especificar las CA de los subelementos de patient M con los subelementos de patient 1.  2: patient 1 /name 1  patient M /name M  3: patient 1 /SSN 1  patient M /SSN M  4: patient 1 /doc 1  patient M /doctor M * Formalmente: Para cada elemento p 1 en emergency 1 /patients 1 /patient 1 * si existe un p en med M /patient M * tal que p  p 1 entonces: - p contienen un elemento name M tal que p/name M /data() = p 1 /name 1 /data() (  2 ) - p contienen un elemento SSN M tal que p/SSN M /data() = p 1 /SSN 1 /data() (  3 ) - Existe un d en p/doctor M * tal que d  p 1 /doc 1 (  4 ) Ver imágen

18  1: med M /patient M *  emergency 1 /patients 1 /patient 1 *  intensivecare 2 /patients 2 /patient 2  2: patient 1 /name 1  patient M /name M  3: patient 1 /SSN 1  patient M /SSN M  4: patient 1 /doc 1  patient M /doctor M *  5: doctor 1 /name 1  doctor M /name M (similar a  2 )  6: doctor 1 /SSN 1  doctor M /SSN M (similar a  3 )  7: patient 2 /name 2  patient M /name M (similar a  2 )  8: patient 2 /SSN 2  patient M /SSN M (similar a  3 )  9: patient 2 /(docpat 2 /pat 2 /&Patient 2 ) -1 /doc 2  patient M /doctor M.  10: doctor 2 /name 2  doctor M /name M (similar a  2 )  11: doctor 2 /SSN 2  doctor M /SSN M (similar a  3 ). Construyendo la vista mediada (Paso II) 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 imágen Ver CA

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 CA para 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/.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/.