Propuesta para Integrar Bases de Datos que Contienen Información de la Web Andrea do Carmo, Regina Motz Instituto de Computación, Facultad de Ingeniería, Universidad de la República Montevideo, Uruguay {docarmo,rmotz}@fing.edu.uy Resumen En este trabajo comenzamos analizando la aplicabilidad de criterios de integración de instancias, utilizados por metodologías de integración de bases de datos, a un contexto donde las bases de datos a integrar contienen información extraída de la Web. Proponemos luego una herramienta de integración de bases de datos, orientada a satisfacer necesidades de integración de información identificadas en el contexto antes mencionado. 1. Introducción. En los últimos años la World Wide Web (WWW) ha crecido drásticamente, convirtiéndose en una de las principales fuentes de información acerca de casi cualquier área temática. En este marco, puede resultar de interés contar con una visión integrada de la información relativa a un área temática determinada, que ofrezca soporte para realizar consultas que involucren varios sitios. Por ejemplo, averiguar qué librería vende a menor precio un determinado libro. De no contar con dicha visión integrada, satisfacer la consulta anterior requeriría un gran esfuerzo (manual) de navegación, extracción, y comparación de información contenida en diferentes sitios. Dado que la información contenida en los sitios Web presenta escasa o ninguna estructuración, no es posible utilizar una metodología de integración de bases de datos para integrarla. Un enfoque para realizar dicha integración consiste en estructurar primero la información contenida en cada sitio en una base de datos (BD), y luego sí integrar dichas BDs aplicando una metodología de integración de BDs [10]. El hecho de integrar la información contenida en los sitios Web en una BD, permite aprovechar la potencia ofrecida por los lenguajes de consulta a BDs para consultar dicha información. Este trabajo se centra en la integración de los datos contenidos en las BDs Web, entendiendo por BDs Web a las bases de datos utilizadas para estructurar la información extraída de los sitios Web. Cada BD Web representa y almacena información extraída de un sitio Web 1. Estas BDs evolucionan de manera autónoma tanto a nivel de esquemas como a nivel de instancias para reflejar la evolución de los sitios que representan. También pueden evolucionar a nivel de esquemas por iniciativa de los diseñadores locales, a los efectos de mejorar su representatividad. El hecho de que la información contenida en las BDs Web provenga de fuentes altamente independientes, autónomas, no pertenecientes a una misma organización, y sin intensiones de cooperar como son los sitios Web, puede llevar a que el grado de solapamiento de instancias entre las BDs que se integran sea bajo y a que la frecuencia de aparición de conflictos en los datos sea alta, entendiéndose por conflicto diferentes valores para un mismo atributo. Los conflictos en los valores de un atributo presente en varias BDs Web pueden obedecer a que: 1) los sitios representados por dichas BDs almacenan información parcial acerca del atributo; 2) el valor del atributo depende del sitio origen; 3) el valor almacenado en alguno de los sitios es erróneo. Ilustremos lo anterior mediante un ejemplo. Supongamos que queremos construir una BD integrada a partir de información contenida en dos librerías electrónicas A y B que tienen sus sitios en la Internet. Supongamos que dentro de la información que almacenan ambas librerías acerca de sus libros encontramos: el nombre, el autor, el precio de venta y un conjunto de comentarios realizados por lectores. Es 1 La construcción de una BD Web a partir de un sitio Web está fuera del alcance del presente trabajo y se puede consultar en [13].
probable que el conjunto de comentarios que almacena A acerca de un libro sea distinto del conjunto de comentarios relativos al mismo libro en B. En este caso, podemos decir que la diferencia obedece a que cada sitio almacena información parcial acerca de los comentarios asociados a un libro (caso 1). Tampoco sorprende que el precio al que vende un libro A no coincida con el precio al que lo vende B. En este caso, podemos decir que la diferencia obedece a que el precio de venta de un libro depende del sitio (caso 2). Sin embargo, es razonable esperar que para ambos sitios el autor de un mismo libro sea el mismo, por lo que diferencias en el valor de este atributo obedecen a que el valor almacenado en alguno de los sitios es incorrecto (caso 3). En el primer caso puede interesar que en la BD integrada se conserven todos los valores del atributo (en el ejemplo, los comentarios). En el segundo caso puede interesar no sólo conservar todos los valores del atributo sino también una indicación de la fuente de la que proviene cada valor (en el ejemplo, el precio). En el tercer caso interesa conservar únicamente el valor que se considera correcto de acuerdo a algún criterio (en el ejemplo, el autor). En este trabajo analizamos en primer lugar la aplicabilidad de criterios de integración de instancias, utilizados por metodologías de integración de BDs, para integrar información contenida en BDs Web. Del análisis realizado, surge que muchos de esos criterios (especialmente los relacionados con la integración de valores de atributos equivalentes 2 ) resultan insuficientes para cubrir ciertas necesidades identificadas en un contexto de integración de BDs Web. Para cubrir las necesidades que este contexto plantea, proponemos una herramienta de integración de BDs llamada SIM+, basada en ODMG 93 [2], que ofrece al usuario 3 diferentes criterios de integración de instancias. Para integrar atributos equivalentes nuestra herramienta provee tres criterios: unir los valores que el atributo tiene en las BDs fuentes, unir los valores que éste tiene en las BDs fuentes indicando el origen de cada valor, y tomar el valor proveniente de una de las BDs fuentes. Para integrar clases equivalentes ofrece la semántica de unión y la semántica de intersección. El resto del trabajo se organiza de la siguiente manera. En la sección 2 analizamos la aplicabilidad de criterios de integración de instancias, utilizados por metodologías de integración de BDs, al contexto de integración de BDs Web. En la sección 3 presentamos los criterios de integración de instancias implementados por la herramienta propuesta. En la sección 4 describimos la herramienta propuesta. En la sección 5 presentamos la arquitectura de SIM+ y describimos sus módulos principales. En la sección 6 presentamos las conclusiones. 2. Análisis de aplicabilidad de criterios de integración de instancias a BDs Web. En esta sección analizamos la aplicabilidad de criterios de integración de instancias comunmente utilizados por metodologías de integración de BDs para integrar instancias contenidas en las BDs Web. Primero presentamos los principales problemas que plantea la integración de instancias. Luego, para cada uno de los problemas planteados presentamos los criterios de resolución utilizados por las metodologías de integración de BDs, evidenciamos (si corresponde) por qué resultan insuficientes para integrar instancias de BDs Web, y comentamos brevemente los criterios implementados por la herramienta de integración que proponemos. Finalmente presentamos la aplicación de la herramienta propuesta a un ejemplo. Los principales problemas que la integración de instancias plantea son: identificar instancias; integrar valores de atributos equivalentes; e integrar instancias de clases equivalentes. El problema de identificar instancias consiste en decidir cuándo dos instancias de clases equivalentes, pertenecientes a las respectivas BDs a integrar, representan a un mismo objeto del mundo real. A cada par de instancias identificadas le llamaremos instancias equivalentes. El problema de integrar valores de atributos equivalentes lo podemos definir de la siguiente manera: Sean S1 y S2 los esquemas a integrar. Sean C1 y C2 dos clases equivalentes, con C1 perteneciente a S1 y C2 perteneciente a S2. Sean a1,..,ak los atributos de C1 y C2 que están en correspondencia de equivalencia (a a1,..,ak les llamaremos atributos comunes). Sea S12 el esquema resultante de integrar S1 y S2. Sea C la clase 2 Que dos atributos, clases o subesquemas en general sean equivalentes (o estén en correspondencia de equivalencia) significa que representan un mismo concepto del mundo real. 3 De aquí en adelante utilizaremos el término usuario para referirnos al administrador de la BD integrada.
de S12 resultante de integrar C1 y C2. Sea c una instancia de C. En este trabajo llamaremos integración de valores de atributos equivalentes abreviando, integración de atributos equivalentes a la tarea de darle valor a los atributos a1,...,ak de c a partir de los valores que estos tienen en las instancias fuentes. Si c es el resultado de integrar dos instancias c1 y c2 equivalentes, pertenecientes a C1 y C2 respectivamente, el valor de cada atributo común se construye a partir de los valores del mismo en c1 y c2. Si c se construye a partir de una instancia i de un esquema que no tiene una instancia equivalente en el otro esquema el valor de cada atributo común se construye a partir del valor del mismo en i. El problema de integrar instancias de clases equivalentes lo podemos definir de la siguiente manera: Sean S1 y S2 los esquemas a integrar. Sea C1 una clase del esquema S1 y C2 una clase del esquema S2, siendo C1 y C2 clases equivalentes. Sea S12 el esquema resultante de integrar S1 y S2, y sea C la clase de S12 resultante de integrar C1 y C2. En este trabajo llamaremos integración de instancias de clases equivalentes abreviando, integración de clases equivalentes a la tarea construir la extensión de C a partir de las extensiones de C1 y C2. Si bien en este trabajo tratamos por separado la integración de clases equivalentes y la integración de atributos equivalentes, estos problemas están estrechamente vinculados. Por un lado, para construir la extensión de una clase integrada es necesario construir cada instancia de la clase, y por lo tanto es necesario darle valor a cada atributo de cada instancia (en particular, a los atributos resultantes de integrar dos atributos fuentes equivalentes). Por otro lado, cuando se construye el valor de un atributo a de una clase integrada, resultante de integrar dos atributos fuentes equivalentes, dependiendo de la semántica que se aplique para integrar clases equivalentes, habrá casos en los que dicho valor se construye a partir de dos valores fuentes, y otros casos en los que se construye a partir de un único valor fuente. Si se aplica semántica de intersección, el valor del atributo a siempre se construye a partir de dos valores fuentes (los valores de los atributos fuentes equivalentes). En cambio, si se aplica semántica de unión, para instancias de la clase integrada, construidas a partir de una instancia i de un esquema que no tiene una instancia equivalente en el otro esquema, el valor del atributo a se construye en base a un único valor fuente (el valor del atributo en i). 2.1. Identificación de instancias. Para identificar instancias muchas metodologías de integración asumen que en las instancias existe un campo id tal que dos instancias representan el mismo objeto del mundo real si ambas tienen el mismo valor de id. Otras permiten al usuario definir un predicado de join tal que dos instancias representan el mismo objeto del mundo real si satisfacen dicho predicado. Dado que consideramos que ambos criterios resultan adecuados para identificar instancias pertenecientes a BDs Web, la herramienta que proponemos utiliza los dos: permite al usuario definir un predicado de join y en ausencia de dicho predicado, identifica instancias utilizando el criterio de igualdad de los valores de la clave. 2.2. Integración de valores de atributos equivalentes. Para darle valor a un atributo de la BD integrada resultante de integrar dos atributos fuentes equivalentes, algunas metodologías adoptan el criterio de tomar el valor que dicho atributo tiene en una de las BDs fuentes [4,8,12]. Generalmente utilizan la noción de BD más confiable para elegir de qué BD tomar el valor (criterio de preferencia). Otras metodologías combinan los valores provenientes de las BDs fuentes aplicando sobre estos una función de agregación (suma, promedio, etc) o de unión de valores [7,9]. En el contexto de integración de BDs Web, tanto el criterio de preferencia como el de combinar los valores del atributo en las BDs fuentes resultan útiles para integrar atributos equivalentes. El criterio de preferencia resulta adecuado para integrar atributos que por su naturaleza deberían tener un valor único (en el ejemplo presentado en la sección 1, el autor). Este criterio requiere además conocer la confiabilidad de las fuentes, de manera de determinar de qué fuente tomar el valor. El criterio de combinar los valores fuentes (en particular la opción de unir los valores) resulta adecuado para integrar atributos cuyo valor se conoce de manera parcial en los sitios, ya que permite conservar todos los valores en la BD integrada (en el ejemplo presentado en la sección 1, los comentarios). Sin embargo ninguno de los criterios anteriores permite resolver el caso en que el valor del atributo común depende del origen (en el ejemplo presentado en la sección 1, el precio). En este caso, interesa no sólo conservar los valores que el atributo tiene en cada fuente sino también el origen de cada
valor. Si aplicamos el criterio de preferencia perdemos el valor proveniente de una de las fuentes, y si aplicamos el criterio de unir valores perdemos el origen de cada valor. Para integrar atributos equivalentes cuyo valor depende del origen nuestra herramienta propone unir los valores que el atributo tiene en las BDs fuentes y acompañar cada valor con una indicación de su origen. La herramienta provee además los criterios de preferencia y unir valores del atributo en las BDs fuentes. Los criterios de unir valores y unir valores mas indicación del origen resultan especialmente adecuados para evitar pérdida de valores de interés en casos en donde no se conoce la confiabilidad de las fuentes. 2.3. Integración de instancias de clases equivalentes. Para construir la extensión de una clase de la BD integrada resultante de integrar dos clases fuentes equivalentes los criterios más comunmente utilizados por las metodologías de integración son: semántica de intersección o semántica de unión [4]. En ausencia de conflictos en los datos, la semántica de intersección se puede pensar como la aplicación de una operación de join sobre las clases que están siendo integradas. En ausencia de conflictos en los datos, la semántica de unión se puede pensar como la aplicación de una operación de outer join sobre las clases que están siendo integradas. Por lo general las metodologías que aplican semántica de intersección trabajan sobre dominios donde existe un alto grado de solapamiento de instancias entre las BDs que se integran. Como en el contexto de la Web existe alto grado de independencia entre los sitios, puede darse el caso de que éstos mantengan poca información en común. En este caso, aplicar la semántica de intersección sobre las BDs construidas a partir de dichos sitios puede traer como consecuencia que clases del esquema integrado resultantes de integrar clases fuentes equivalentes queden despobladas o con muy pocas instancias. Esto hace pensar que la semántica de intersección puede no ser adecuada para el contexto de las BDs Web. Pero como entendemos que la elección de una determinada semántica depende del tipo de aplicación que se está construyendo mas que de las características particulares del contexto, nuestra herramienta provee al usuario ambas semánticas. 2.4. Ejemplo. En esta sección mostramos el resultado de aplicar SIM+ a un caso concreto, concentrándonos especialmente en los resultados obtenidos al aplicar los criterios de integración de instancias que dicha herramienta provee (presentados informalmente en las secciones 2.2 y 2.3). Retomemos el ejemplo de las librerías electrónicas, presentado en la sección 1. En A la información que se almacena de cada libro es: nombre, autor, comentarios, precio y cantidad de páginas. En B la información que se almacena de cada libro es: nombre, autor, comentarios, precio y resumen. Sea BD1 la BD Web que modela a la librería A y BD2 la que modela a B. Sea S1 el esquema de BD1 y S2 el esquema de BD2. Sean I1 el conjunto de instancias que representan a los libros ofrecidos por A e I2 el conjunto de instancias que representan a los libros ofrecidos por B. S1: libro(nom,autor,coment,precio,cant_pag) S2: libro(nom,autor,coment,precio,resumen) I1: I2: l1(x,pedro,{c1,c2},200,350) l3(x,julio,{c4},220,r1) l2(y,juan,{c3},100,70) l4(z,mario,{c5,c6},110,r2) Como se verá en las secciones 4 y 5, para integrar las BDs fuentes SIM+ requiere que el usuario establezca las correspondencias de equivalencia entre subesquemas, el criterio para integrar clases equivalentes, y el criterio para integrar cada par de atributos equivalentes. Considerando que: - el usuario estableció correspondencias de equivalencia entre las clases libro, y entre los atributos nom, autor, coment, y precio de las BDs fuentes - el criterio utilizado para identificar instancias es el de igualar los valores de la clave (atributos nom) - el usuario eligió semántica de unión para integrar clases equivalentes
- el usuario eligió integrar los atributos coment por unión de valores, los atributos precio por unión de valores mas indicación del origen, y los atributos nom y autor por preferencia siendo BD1 la BD más confiable la BD resultante de integrar BD1 y BD2 aplicando SIM+ tiene por esquema S12 y por instancias I12. S12: libro(nom,autor,coment,precio,cant_pag,resumen) I12: l13(x,pedro,{c1,c2,c4},{(200,s1),(220,s2)},350,r1) l2 (Y,juan,{c3},{(100,S1)},70,r) l4 (Z,mario,{c5,c6},{(110,S2)},p,r2) El esquema S12 tiene una única clase libro resultante de integrar las clases libro de S1 y S2. Dado que SIM+ integra clases equivalentes creando una clase integrada cuyos atributos son la unión de los atributos de las clases fuentes, la clase libro de S12 tiene por atributos la unión de los atributos de las clases fuentes libro. I12 tiene tres instancias: l13 resultante de integrar l1 y l3 (instancias que representan el mismo libro); l2 construida a partir de l2 y cargando con un valor por defecto (r) el atributo resumen no presente en la clase libro de S1; y l4 construida a partir de l4 y cargando con un valor por defecto (p) el atributo cant_pag no presente en la clase libro de S2. Como l2 no tiene una instancia equivalente en S2, los valores de los atributos comunes en l2 se construyen a partir de los valores de los mismos en l2. De esta forma, el valor de coment de l2 es el valor que tiene coment en l2, el valor de precio en l2 es el valor que tiene precio en l2 mas una indicación del esquema del que se tomó dicho valor (el esquema al que pertenece l2), y los valores de nom y autor en l2 son los valores de dichos atributos en l2. Razonando de manera análoga, el valor de coment de l4 es el valor que tiene coment en l4, el valor de precio en l4 es el valor que tiene precio en l4 mas una indicación del esquema del que se tomó dicho valor (el esquema al que pertenece l4) y los valores de nom y autor en l4 son los valores de dichos atributos en l4. Si en lugar de haber elegido semántica de unión el usuario hubiera elegido semántica de intersección, el resultado de integrar I1 e I2 hubiera sido: I12: l13(x,pedro,{c1,c2,c4},{(200,s1),(220,s2)},350,r1) La aplicación de la semántica de intersección provocó pérdida de instancias (las que representan a los libros Y y Z). De no contar con el criterio de unir valores mas indicación de origen (propuesto en este trabajo) también se hubiera perdido información de interés. Si el atributo precio se hubiera integrado aplicando el criterio de preferencia, el resultado de integrar I1 e I2 (manteniendo la semántica de unión) hubiera sido: I12: l13(x,pedro,{c1,c2,c4},200,350,r1) l2 (Y,juan,{c3},100,70,r) l4 (Z,mario,{c5,c6},110,p,r2) En este caso se perdió el precio de X en B y la información relativa al origen de cada valor (no sabemos qué librería vende X a 200, Y a 100 y Z a 110). Si el atributo precio se hubiera integrado aplicando el criterio de unir valores, el resultado de integrar I1 e I2 (manteniendo la semántica de unión) hubiera sido: I12: l13(x,pedro,{c1,c2,c4},{200,220},350,r1) l2 (Y,juan,{c3},{100},70,r) l4 (Z,mario,{c5,c6},{110},p,r2) En este caso se perdió la información acerca del origen de cada valor (no sabemos a qué precio vende el libro X cada librería, ni qué librería vende Y a 100 y Z a 110).
3. Criterios de integración de instancias implementados por SIM+. En esta sección presentamos formalmente los criterios implementados por SIM+ para integrar atributos equivalentes y clases equivalentes. 3.1. Criterios para integrar atributos equivalentes. En esta sección presentamos formalmente los tres criterios para integrar atributos equivalentes que provee SIM+. Estos criterios son: integración por unión de valores, integración por unión de valores mas indicación del origen, y preferencia. En el marco de la herramienta, llamaremos atributos complementarios a aquellos atributos de las BDs fuentes que se integran por unión de valores, dependientes del origen a aquellos atributos de las BDs fuentes que se integran por unión de valores mas indicación del origen, y ordinarios a aquellos atributos de las BDs fuentes que se integran aplicando el criterio de preferencia. 3.1.1. Integración por unión de valores. Integrar un atributo común a por unión de valores significa que el valor de dicho atributo en la instancia c resultante de integrar la instancia c1 del esquema S1 y la instancia c2 del esquema S2, siendo estas últimas dos instancias equivalentes, es la unión de los conjuntos {c1.a} y {c2.a}, siendo c1.a el valor del atributo a en c1 y c2.a el valor del atributo a en c2. Para instancias c que se construyen a partir de una instancia i de un esquema que no tiene una instancia equivalente en el otro esquema el valor del atributo a en c es {i.a}. Más formalmente: c C C = C1 C2 C1 ClasesS1 C2 ClasesS2 C1 C2 C1.a C2.a a (AtributosC1 AtributosC2) a (ComplementariosC1 ComplementariosC2), {c1.a} {c2.a} si c1 C1 c2 C2 c1 c2 c.a = {c1.a} si c1 C1 (( )c2 C2 c1 c2) {c2.a} si c2 C2 (( )c1 C1 c1 c2) ClasesSi representa al conjunto de clases del esquema Si. AtributosCi representa al conjunto de atributos de la clase Ci. ComplementariosCi representa al conjunto de atributos complementarios de la clase Ci. El símbolo es utilizado para representar al operador de integración de clases, el símbolo es utilizado para representar equivalencia entre clases o entre atributos, y el símbolo es utilizado para representar la equivalencia entre instancias (dos instancias que representan el mismo objeto del mundo real). El tipo del atributo a en el esquema integrado será set(t), siendo T el tipo de a en las clases que se integran 4. 3.1.2. Integración por unión de valores mas indicación de origen. Integrar un atributo común a por unión de valores mas indicación del origen significa que el valor de dicho atributo en la instancia c resultante de integrar la instancia c1 del esquema S1 y la instancia c2 del esquema S2, siendo estas últimas dos instancias equivalentes, es la unión de los conjuntos {(c1.a,s1)} y {(c2.a,s2)}, siendo c1.a el valor del atributo a en c1 y c2.a el valor del atributo a en c2. Para instancias c que se construyen a partir de una instancia i de un esquema que no tiene una instancia equivalente en el otro esquema el valor del atributo a en c es {(i.a,s)} siendo S el identificador del esquema al que la instancia i pertenece. Más formalmente: c C C = C1 C2 C1 ClasesS1 C2 ClasesS2 C1 C2 C1.a C2.a a (AtributosC1 AtributosC2) a (DependientesdelOrigenC1 DependientesdelOrigenC2), {(c1.a,s1)} {(c2.a,s2)} si c1 C1 c2 C2 c1 c2 c.a = {(c1.a,s1)} si c1 C1 (( )c2 C2 c1 c2) {(c2.a,s2)} si c2 C2 (( )c1 C1 c1 c2) 4 En este trabajo asumimos que los atributos equivalentes tienen igual tipo en las clases que se integran.
DependientesdelOrigenCi representa al conjunto de atributos dependientes del origen de la clase Ci. El tipo de a en el esquema integrado será set(struct {T a_original,string origen}), siendo T el tipo de a en las clases que se integran. 3.1.3. Preferencia. Integrar un atributo común a aplicando el criterio de preferencia significa que el valor de dicho atributo en la instancia c resultante de integrar la instancia c1 del esquema S1 y la instancia c2 del esquema S2, siendo estas últimas dos instancias equivalentes, es igual al valor de a en la instancia proveniente del esquema más confiable. Para instancias c que se construyen a partir de una instancia i de un esquema fuente que no tiene una instancia equivalente en el otro esquema el valor del atributo a en c es i.a. Más formalmente: c C C = C1 C2 C1 ClasesS1 C2 ClasesS2 C1 C2 C1.a C2.a a (AtributosC1 AtributosC2) a (OrdinariosC1 OrdinariosC2), c1.a si ( c1 C1 S1 es el esquema más confiable) c.a = ( c1 C1 (( )c2 C2 c1 c2)) c2.a si ( c2 C2 S2 es el esquema más confiable) ( c2 C2 (( )c1 C1 c1 c2)) OrdinariosCi representa al conjunto de atributos ordinarios de la clase Ci. El tipo del atributo a en el esquema integrado será T, siendo T el tipo de a en las clases que se integran. 3.2. Criterios para integrar clases equivalentes. En esta sección presentamos formalmente los criterios que SIM+ ofrece para integrar clases equivalentes: la semántica de intersección y la semántica de unión. 3.2.1. Semántica de intersección. En este trabajo introducimos una operación llamada Oi que nos permite definir la semántica de intersección independientemente de la presencia de conflictos. Construir la extensión de una clase C resultante de integrar dos clases fuentes equivalentes C1 y C2 aplicando semántica de intersección significa aplicar la operación Oi sobre las clases C1 y C2. Definimos Oi de la siguiente manera: Sean C1 y C2 dos clases. El resultado de aplicar la operación Oi a C1 y C2 es una clase C cuyo conjunto de propiedades 5 es la unión de los conjuntos de propiedades de C1 y C2, y cuya extensión está dada por el siguiente conjunto: {c C / c1 C1 c2 C2 c1 c2 ( a PropiedadesC1 PropiedadesC2, c.a = c1.a) ( a PropiedadesC2 PropiedadesC1, c.a = c2.a) ( a AtributosC1 AtributosC2 a (ComplementariosC1 ComplementariosC2), c.a = {c1.a} {c2.a}) ( a AtributosC1 AtributosC2 a (DependientesdelOrigenC1 DependientesdelOrigenC2), c.a = {(c1.a,s1)} {(c2.a,s2)}) ( a AtributosC1 AtributosC2 a (OrdinariosC1 OrdinariosC2), c1.a si S1 es el esquema más confiable c.a = c2.a si S2 es el esquema más confiable ) ( a RelacionesC1 RelacionesC2, c.a = c1.a c2.a)} PropiedadesCi representa al conjunto de propiedades de la clase Ci. RelacionesCi representa al conjunto de relaciones de la clase Ci. 5 De aquí en adelante, el término propiedad lo utilizaremos en el sentido de ODMG 93, esto es, para hacer referencia tanto a atributos como a relaciones.
3.2.2. Semántica de unión. En este trabajo introducimos una operación llamada Ou que nos permite definir la semántica de unión independientemente de la presencia de conflictos. Construir la extensión de una clase C resultante de integrar dos clases fuentes equivalentes C1 y C2 aplicando semántica de unión significa aplicar la operación Ou sobre las clases C1 y C2. Definimos Ou de la siguiente manera: Sean C1 y C2 dos clases. El resultado de aplicar la operación Ou a C1 y C2 es una clase C cuyo conjunto de propiedades es la unión de los conjuntos de propiedades de C1 y C2, y cuya extensión está dada por el siguiente conjunto: C1 Oi C2 {c C / c1 C1 (( )c2 C2 c1 c2) ( a PropiedadesC1 PropiedadesC2, c.a = c1.a) ( a PropiedadesC2 PropiedadesC1, c.a = ) ( a AtributosC1 AtributosC2 a (ComplementariosC1 ComplementariosC2), c.a = {c1.a}) ( a AtributosC1 AtributosC2 a (DependientesdelOrigenC1 DependientesdelOrigenC2), c.a = {(c1.a,s1)}) ( a AtributosC1 AtributosC2 a (OrdinariosC1 OrdinariosC2), c.a = c1.a) ( a RelacionesC1 RelacionesC2, c.a = c1.a)} {c C / c2 C2 (( )c1 C1 c1 c2) ( a PropiedadesC2 PropiedadesC1, c.a = c2.a) ( a PropiedadesC1 PropiedadesC2, c.a = ) ( a AtributosC1 AtributosC2 a (ComplementariosC1 ComplementariosC2), c.a = {c2.a}) ( a AtributosC1 AtributosC2 a (DependientesdelOrigenC1 DependientesdelOrigenC2), c.a = {(c2.a,s2)}) ( a AtributosC1 AtributosC2 a (OrdinariosC1 OrdinariosC2), c.a = c2.a) ( a RelacionesC1 RelacionesC2, c.a = c2.a)} El símbolo representa un valor desconocido. El primero de los tres conjuntos a partir de los cuales definimos la extensión de C denota a las instancias c de C resultantes de aplicar la operación Oi (definida en 3.2.1) sobre las clases C1 y C2 (instancias construidas a partir de dos instancias equivalentes). El segundo denota a las instancias c de C construidas a partir de las instancias c1 que pertenecen a C1 y que no tienen una instancia equivalente en C2. En este caso el valor de las propiedades de c que pertenecen a C1 se construye a partir del valor que tienen las mismas en la instancia c1 mientras que las propiedades que sólo están definidas en C2 se cargan con. De manera análoga, el tercer conjunto denota a las instancias c de C construidas a partir de las instancias c2 que pertenecen a C2 y que no tienen una instancia equivalente en C1. El valor de las propiedades de c que pertenecen a C2 se construye a partir del valor que tienen las mismas en la instancia c2 mientras que las propiedades que sólo están definidas en C1 se cargan con. 4. Descripción general de SIM+. En esta sección describimos brevemente la herramienta de integración de BDs Web SIM+. Una descripción más detallada de la misma se puede encontrar en [3]. La herramienta provee al usuario diferentes alternativas para integrar instancias. Para integrar clases equivalentes el usuario puede elegir entre semántica de unión y semántica de intersección. Para integrar atributos equivalentes ofrece al usuario la posibilidad de clasificar cada atributo de las BDs fuentes en una de tres categorías: complementario, dependiente del origen u ordinario. Cada una de estas categorías determina un criterio distinto de integración. Los atributos complementarios SIM+ los integra uniendo sus valores; los dependientes del origen los integra uniendo sus valores y acompañando cada valor con una indicación de la fuente; los ordinarios los integra aplicando preferencia. SIM+ utiliza como motor de integración una herramienta de integración de BDs ya existente, llamada SIM [4,8], agregándole etapas de preprocesamiento de su entrada y posprocesamiento de su salida. Algunas de las razones que nos llevaron a elegir SIM como motor de integración son: se basa en ODMG 93, es semiautomática, declarativa, incremental (permite construir una BD integrada a partir de un conjunto inicial
de correspondencias y luego enriquecerla mediante el agregado de nuevas correspondencias ), permite detectar inconsistencias en el conjunto de correspondencias establecidas entre subesquemas de las BDs a integrar y se apoya en una base formal. A partir de dos BDs fuentes modeladas utilizando ODMG 93 y de un conjunto de correspondencias de equivalencia entre subesquemas de las BDs fuentes, SIM construye semiautomáticamente una BD integrada. La BD integrada está dada por un esquema integrado y un conjunto de especificaciones de mapeos de instancias (mapeos de instancias, en forma abreviada). Los mapeos de instancias consisten básicamente en expresiones OQL que indican cómo poblar las clases, atributos y relaciones del esquema integrado a partir de las BDs fuentes. Los criterios que utiliza SIM para integrar instancias, expresados a través de los mapeos de instancias, son: predicado de join provisto por el usuario para identificar instancias (o en su defecto, criterio de igualdad de valores de los atributos claves), semántica de intersección para integrar clases equivalentes, y criterio de preferencia para integrar atributos equivalentes. Las etapas de pre y posprocesamiento agregadas a SIM permiten implementar el resto de los criterios de integración que SIM+ provee (semántica de unión, y los criterios de unir valores y unir valores indicando el origen de cada valor). En grandes líneas SIM+ trabaja de la siguiente manera. Recibe como entradas dos BDs fuentes modeladas utilizando ODMG 93, un conjunto de correspondencias de equivalencia entre subesquemas de las BDs fuentes, el criterio de integración de clases equivalentes, y la clasificación de los atributos equivalentes en complementarios, dependientes del origen y ordinarios. Como primera etapa (preproceso) aplica una serie de transformaciones a las BDs fuentes y a las correspondencias de equivalencia. En una segunda etapa aplica SIM sobre las BDs y las correspondencias transformadas. En una tercera etapa (posproceso) aplica ciertas modificaciones a los mapeos de instancias devueltos por SIM. La salida de SIM+ es una BD integrada dada por un esquema integrado y un conjunto de mapeos de instancias. El esquema integrado devuelto por SIM+ es el esquema integrado que SIM genera en la segunda etapa del proceso descripto. Los mapeos de instancias devueltos por SIM+ son los generados en la tercera etapa del proceso descripto. 4.1. Sintaxis de las especificaciones de mapeos de instancias. Las especificaciones de mapeos de instancias indican cómo poblar el esquema integrado a partir de las BDs fuentes. Cada clase del esquema integrado tiene asociada una especificación de mapeos de instancias. La sintaxis de esta especificación está expresada en una extensión del lenguaje ODL y es como sigue: mapping <nombre de clase> { origins <tipo de atributo> <nombre de atributo> [, <tipo de atributo> <nombre de atributo>]*; def_ext <expresión oql> def_att <nombre de atributo> as <expresión oql>; def_rel <nombre del camino transversal> as <expresión oql>;} La cláusula origin especifica referencias a las clases de los esquemas fuentes a partir de las cuales (o mas bien de sus instancias) se construye la extensión de la clase del esquema integrado. La cláusula def_ext describe la extensión de la clase a través de una consulta OQL. La cláusula def_att indica, en base a expresiones OQL, cómo darle valor a un atributo de una instancia de la clase integrada. La cláusula def_rel define, a través de una expresión OQL, cómo poblar una relación de una instancia perteneciente a la clase integrada (con qué instancias está vinculada a través de la relación en cuestión). Las expresiones OQL asociadas a def_att y def_rel son evaluadas cada vez que se construye una nueva instancia de la clase integrada a partir de la consulta especificada en def_ext. Una variable especial this permite referenciar a la instancia de la clase que se está construyendo actualmente. 5. Arquitectura de SIM+. En la figura 1 mostramos la arquitectura de SIM+. En dicha arquitectura distinguimos tres módulos principales: el preprocesador, SIM, y el posprocesador.
Corr, DatosPosproceso DatosPosproceso PREPROCESADOR preproc_para_posproceso BD1,BD2,Corr SIM MapInstancias POSPROCESADOR BD1 BD2 EsquemaIntegrado atr_comunes sem_union MapInstancias MapInstancias figura 1 Arquitectura de SIM+ Flujo de datos DatosPosproceso: criterio de integración de clases equivalentes, y listas de atributos complementarios y dependientes del origen. 5.1. El preprocesador. Este módulo implementa la etapa de preprocesamiento. Está compuesto básicamente por el procedimiento preproc_para_posproceso. 5.1.1. Preproc_para_posproceso. El procedimiento preproc_para_posproceso realiza transformaciones estructurales de las BDs a integrar necesarias para implementrar las propuestas de integración de atributos equivalentes. Básicamente, recibe como entrada las BDs a integrar, un conjunto de correspondencias de equivalencia entre subesquemas de dichas BDs (utilizadas posteriormente por SIM), el criterio a aplicar en la integración de clases equivalentes, y los criterios para integrar los atributos equivalentes dados por las siguientes listas: - la lista de atributos complementarios de cada esquema - la lista de atributos dependientes del origen de cada esquema Aquellos atributos equivalentes que no pertenezcan a ninguna de las dos listas se consideran atributos ordinarios. El procedimiento preproc_para_posproceso devuelve como salida las BDs transformadas y un nuevo conjunto de correspondencias de equivalencia. Dichas correspondencias son el resultado de reescribir las correspondencias que este procedimiento recibió como entrada para adaptarlas a las BDs transformadas. La transformación de los esquemas fuentes, consiste en cambiarle el tipo a aquellos atributos que el usuario declaró como complementarios o dependientes del origen. El nuevo tipo de dichos atributos en los esquemas fuentes es el que tendrá el atributo (resultante de la integración) en el esquema integrado según los criterios de integración de atributos equivalentes (ver 3.1). Por ejemplo, si el atributo es complementario en ambos esquemas fuentes, se modifica cada esquema fuente multivaluando dicho atributo. Las razones por las que es necesario realizar estas transformaciones son: - en SIM dos atributos equivalentes tienen igual tipo - el tipo de un atributo del esquema integrado devuelto por SIM, resultante de integrar dos atributos equivalentes es igual al tipo de dichos atributos en los respectivos esquemas fuentes - el esquema integrado devuelto por SIM+ es el esquema integrado devuelto por SIM
- el tipo de un atributo del esquema integrado, resultante de integrar dos atributos equivalentes utilizando los criterios propuestos, puede ser distinto del tipo que dichos atributos tienen en los respectivos esquemas fuentes Las transformaciones de los esquemas fuentes aseguran que al aplicar SIM sobre dichos esquemas el atributo del esquema integrado, resultante de integrar dos atributos fuentes equivalentes, tenga el tipo requerido para aplicar las propuestas de integración de atributos equivalentes. Los detalles de implementación de este procedimiento se pueden consultar en [3]. 5.2. SIM. SIM es el motor de integración de SIM+. Este módulo es el responsable de construir el esquema integrado que SIM+ devuelve y un primer mapeo de instancias. Recibe como entradas las BDs transformadas por el preprocesador y el conjunto de correspondencias devueltas por éste. Devuelve como salida una BD integrada dada por un esquema integrado y mapeos de instancias. En líneas generales SIM construye el esquema integrado en dos etapas: 1) conformación de esquemas y 2) merge de los esquemas conformados. En la conformación de esquemas elimina diferencias estructurales entre subesquemas de los esquemas fuentes que están en correspondencia de equivalencia. Esta etapa la implementa a través de transformaciones llamadas aumentaciones de esquemas. Desde un punto de vista intuitivo, dados dos subesquemas que están en correspondencia de equivalencia, la aumentación transforma el subesquema menor en un orden llamado orden de aumentación en el subesquema mayor. Como resultado de estas transformaciones, las partes comunes a ambos esquemas fuentes quedan representadas de la misma manera. La etapa final de la integración de esquemas es el merge, que se puede pensar como la superposición de los esquemas resultantes de la etapa de conformación. Los criterios que SIM utiliza para integrar instancias, expresados a través de los mapeos de instancias, son: predicado de join provisto por el usuario para identificar instancias (o en su defecto, criterio de igualdad de valores de los atributos claves), semántica de intersección para integrar clases equivalentes, y criterio de preferencia para integrar atributos equivalentes. Por más detalles acerca de SIM consultar [4,8]. 5.3. El posprocesador. Este módulo implementa la etapa de posprocesamiento. Está compuesto principalmente por dos procedimientos: atr_comunes y sem_union. Estos procedimientos implementan los criterios de integración de atributos equivalentes y la semántica de unión respectivamente. 5.3.1. El procedimiento atr_comunes. Este procedimiento implementa los criterios de integración de atributos equivalentes. Sólo se ejecuta si alguna de las listas de atributos recibidas como entrada de preproc_para_posproceso (listas de atributos complementarios y dependientes del origen) son no vacías o si el criterio para integrar clases equivalentes es semántica de unión. Recibe como entrada el mapeo de instancias generado por SIM y lo devuelve modificado. La modificación del mapeo de instancias sólo afecta a las clases C de la BD integrada resultantes de integrar dos clases fuentes equivalentes C1 y C2. Dicha modificación consiste en sustituir el mapeo asociado a cada atributo común a 6 por la invocación a una función que computa el criterio de integración que corresponda dependiendo de la categoría a la que pertenece a en los esquemas fuentes (ver definición de criterios de integración de atributos equivalentes en 3.1). Por ejemplo, si el atributo a común a ambos esquemas fuentes es complementario o dependiente del origen se invoca a una función que devuelve la unión de los valores de dicho atributo en los esquemas fuentes. Los detalles de implementación de este procedimiento se pueden consultar en [3]. 6 La propuesta no toca los mapeos que generó SIM para los atributos no comunes.
5.3.2. El procedimiento sem_union. Este procedimiento implementa la semántica de unión y se ejecuta después del procedimiento atr_comunes. Este procedimiento no se ejecuta si el criterio elegido por el usuario para integrar clases equivalentes es la semántica de intersección. Recibe como entrada el mapeo de instancias generado por SIM y lo devuelve modificado. La modificación del mapeo de instancias sólo afecta a las clases C de la BD integrada resultantes de integrar dos clases fuentes equivalentes C1 y C2. Dicha modificación consiste en sustituir la consulta OQL generada por SIM 7, por una consulta que computa la operación Ou definida en la sección 3.2.2. La implementación requiere además crear e instanciar ciertas clases (clases auxiliares) no existentes en las BDs fuentes que se integran. Por cada clase C se crean dos clases auxiliares: C1aux en la BD a la que pertenece C1, con igual estructura que C1, y C2aux en la BD a la que pertenece C2, con igual estructura que C2. Estas clases auxiliares se instancian con valores por defecto (utilizados para representar ) y son transparentes al usuario. La nueva consulta OQL utiliza las instancias de las clases auxiliares para construir instancias de C generadas a partir de una instancia de una clase fuente que no tiene una instancia equivalente en la clase fuente del otro esquema. Los detalles de implementación de este procedimiento se pueden consultar en [3]. 6. Conclusiones. En el contexto de integración de BDs Web, donde la información que dichas BDs contienen proviene de fuentes altamente independientes, autónomas, no pertenecientes a una misma organización, y sobre todo sin intensiones de cooperar, surgen ciertas necesidades relativas a la integración de instancias que no son cubiertas por los criterios de integración de instancias utilizados por metodologías de integración de BDs. Por ejemplo, diferencias en los valores de un atributo pueden obedecer a que dicho valor depende del origen (típicamente el precio de venta de un libro). En este caso, interesa que en la BD integrada no sólo se conserven los valores que el atributo tiene en las fuentes sino también el origen de cada valor. La aplicación de cualquiera de los criterios de integración de atributos equivalentes (preferencia y unir valores de las fuentes) utilizados por la mayoría de las metodologías de integración para resolver este conflicto provoca pérdida de información de interés. El principal aporte de este trabajo es la propuesta de una herramienta de integración de BDs llamada SIM+, especialmente orientada a cubrir necesidades relativas a la integración de instancias, identificadas en el contexto de integración de BDs Web. Esta herramienta ofrece al usuario diferentes criterios de integración de instancias. Algunos de éstos son criterios ya existentes, utilizados generalmente en forma aislada por diferentes metodologías de integración, mientras que otros son nuevos. Para integrar atributos equivalentes ofrece los siguientes criterios: unir valores fuentes, unir valores fuentes etiquetando cada valor con el origen, y preferencia. Para integrar clases equivalentes ofrece semántica de intersección y semántica de unión. SIM+ se construye en base a una herramienta de integración de BDs existente llamada SIM. SIM constituye el motor de integración de SIM+. Utiliza semántica de intersección para integrar clases equivalentes y el criterio de preferencia para integrar atributos equivalentes. Además del motor de integración, SIM+ consta de dos componentes que son los que le permiten implementar los criterios de integración de instancias que SIM no provee. Actualmente se está desarrollando en JAVA un prototipo de SIM+. Este prototipo está basado en la arquitectura mostrada en la figura 1 y ofrecerá al usuario una interface gráfica. Dicho prototipo nos permitirá evaluar el funcionamiento de la herramienta propuesta frente a casos reales (casos en donde las BDs a integrar se construyen a partir de sitios Web reales). En un futuro pensamos incorporar a SIM+ un mecanismo para propagar cambios a nivel de esquema desde una BD Web hacia la BD integrada, producto de la evolución del sitio que dicha BD Web representa. Una primera propuesta en este sentido se puede consultar en [3]. 7 Que computa la operación Oi (definida en 3.2.1) en el caso particular en que todos los atributos equivalentes se integran aplicando el criterio de preferencia.
Bibliografía. [1]C. Batini, M Lenzerini and S.B. Navathe, A Comparative Analysis of Methodologies for Database Schema Integration, ACM Computing Surveys, Vol. 18, nº4, December 1986. [2]R. Catell et al., The Object Database Standard: ODMG 93, release 1.2, Morgan Kauffman, 1996. [3]A. do Carmo Aplicando Integración de Esquemas en un Contexto DW Web, Tesis de maestría, Pedeciba Informática InCo, Facultad de Ingeniería, Universidad de la República, Montevideo, Uruguay, Febrero 2000. [4]P. Fankhauser, R. Motz and G. Huck, Schema Integration Methodology, Deliverable D4 4/1, IRO DB(P8629), 1995. [5]R. Hackathorn, Web Farming for the Data Warehouse, Morgan Kaufmann Publishers, Inc., San Francisco, California, 1999. [6]S. Kerr and A. Gal, Information Services for the Web: Building and Maintaining Domain Models, Proc. of the 3 rd IFCIS International Conference on Cooperative Information Systems (CoopIS), New York City, New York, USA, August 20 22, 1998. [7]W. Kim, ed., Modern Database Systems: the object model, interoperability, and beyond, ACM Press, New York, 1995. [8]R. Motz, Instanciating Integrated Schemas, SBBD 98, Maringá Paraná Brasil, October 1998. [9]C. Parent and S. Spaccapietra, Database Integration: an Overview of Issues and Approaches, Communications of the ACM, Vol. 41, nº5, pp. 166 178, May 1998. [10]R. Ruggia, R. Motz and A. Gutierrez, Diseño y Mantenimiento dinámico de Data Warehouses: Aplicación al caso de datos extraídos de la Web, documento interno sobre proyecto DW Web, InCo, Facultad de Ingeniería, Universidad de la República, Montevideo, Uruguay 1998. [11]A. Rajaraman and P. Norvig, Virtual Database Technology: Transforming the Internet into a Database, IEEE Computing, July August 1998. [12]S. Spaccapietra, C. Parent and Y. Dupont, Model Independent Assertions for Integration of Heterogeneous Schemas, VLDB Journal, Vol. 1, nº1, July 1992. [13]D. Viera, Extracción y Mantenimiento Dinámico de Datos de la Web, informe final del proyecto de grado en Ingeniero en Computación, InCo, Facultad de Ingeniería, Universidad de la República, Montevideo, Uruguay, Abril 1999.