Motivación

1. Motivación La integración de fuentes de datos heterogéneos a sistemas de software es el mayor caso en la comunidad biomédica y varios acercamientos han sido explorados: linking databases, “on the fly” integración a través de vistas, e integración a través de warehousing. En este documento se reportan experiencias con dos sistemas que se desarrollaron en la Universidad de Pennsylvania : • sistema de integración K2, que ha sido primariamente utilizado para proveer vistas sobre múltiples bases de datos externas y sistemas de software. • data warehouse GUS con el que se bajan datos, se limpian, integran y anotan datos de múltiples fuentes de datos externos. Sin embargo en estos acercamientos sobre vistas y warehouse cada uno tiene sus ventajas, no hay un ganador claramente.

2. Introducción El reciente completado del borrador inicial del genoma humano, lafinalización de la secuencia de la Drosophila, C.elegans , y gran cantidad de otros proyectos en progreso, ha permitido la basta cantidad de datos del genoma la posibilidad de refinamiento y análisis futuro de este estudio. Repasando las secuencias de DNA los cientificos han investigado en las secuencias de las correspondientes proteínas, su estructura y funciones. Esas y otras preguntas solo pueden ser contestadas con la experimentación directa, muchos otras comprensiones pueden ser obtenidas con el acceso a la tremenda cantidad de información de el genoma que es posible en línea.

3. Ejemplo Suponga que los investigadores buscan descubrir los genes que involucran a el desorden multi-genético neurológico como la esquizofrenia bipolar. La alta carga de análisis de los patrones de perfil genético involucra a decenas de miles de posibles genes potenciales. Analizando el perfil revela cientos de genes que son candidatos a ese desorden. Acceden a bases de datos como GenBank , SWISS-PROT y OMIM para determinar en que región de los cromosomas humanos están ubicados los genes que están asociados con la esquizofrenia a través del mapeo genético. GenBank, EMBL y DDBJ forman “consorcio”

4. Heterogeneidad Desafortunadamente, aunque mucha información de investigación genética puede accederse en línea, no toda reside en una base de dato única. Esta se encuentra dispersa sobre múltiples fuentes de datos usando una variedad de distintos modelos de datos y formatos de datos, y presentando a su vez una variedad de lenguajes e interfaces distintos para la consulta de datos. Muchas de estas Fuentes de datos no están implementadas usando un sistema convencional, como por ejemplo BD relacionales, pero usan archivos con formato y GUI´s especializadas, y también packages de obtención de datos.

5. Archivos con formato • La información es compleja y no es fácil de representar en un DBMS relacional. Las estructuras incluyen datos secuenciales (listas) y estructuras de records profundamente anidados (deeply nested). • Los archivos con formato son fácilmente accesible por lenguajes como Perl y C, y un gran numero de programas de software existen para trabajar con estos archivos. • Los archivos y sus packages asociados para recuperar la información están disponibles para una gran cantidad de plataformas.

6. SWISS-PROT En el ejemplo del tipo de dato habilitado en línea tenemos el caso de SWISS-PROT. Cada línea comienza con 2 caracteres, e indica el tipo de dato contenido en esta. Por ejemplo,cada entrada es identificada con un numero de incorporación AC (accession) y es “timestamped” con hasta 3 fechas DT: la fecha de creación, la fecha de actualización y la de anotación. La secuencia SQlista de aminoácidos Información taxonómica OC Referencias a otras bases de datos DR “feature” FT “keyword” KW, líneas de comentarios CC Nótese que las referencias bibliograficas son estructuras anidadas, hay dos referencias, y los campos RP,RC,RA y RL se repiten para cada una de ellas.

7. Imagen

8. El dilema La heterogeneidad de las fuentes de datos, junto con la implementación frecuentemente no convencional hace que el acceso a los datos del genoma a través de múltiples fuentes sea extremadamente difícil. Los investigadores están enfrentados con un dilema: • Que software pueden usar para mejorar el acceso a los datos? • Que tan complicado puede llegar a ser este software? • Deben tener los datos como están, o deben crear sus propias bases de datos especializadas?

9. Link-driven Federation vs. Integración: En los pasados 10 años muchas técnicas se han desarrollado para proveer el acceso a multiples, heterogéneas fuentes de datos. Varias link driven federations han sido creadas, en ellas los usuarios comienzan con temas de interés y saltan a otras fuentes de datos relacionadas vía Web links que han sido creados por los desarrolladores del sistema. SRS, LinkDB y GeneCards son ejemplos de este tipo. Sistemas de vistas integradas han emergido de la comunidad, como el sistema Kleili/K2 y OPM. En estos sistemas los esquemas de las fuentes de datos son unificados a un esquema global en algún modelo común, como el relacional o orientado a objetos. Los usuarios consultan este esquema global usando un lenguaje de alto nivel de consulta como SQL, OQL o CPL

10. Dos estrategias Se ilustran las dos estrategias de vistas y warehouse . Abajo tenemos las múltiples y heterogéneas fuentes de datos. Sobre estas tenemos la capa de software que se encarga de extraer e integrar las fuentes. La línea punteada indica que esa capa de integración puede ser usada para consultas o para crear un warehouse. Siendo vista o warehouse la estrategia vemos que en la parte superior las consultas pueden realizarse en una variedad de programas de aplicación como por ejemplo interfaces Web.

11. Características Las federaciones link driven son muy usadas por usuarios no expertos, desde que estas trabajan con interfaces de point and click . Se intenta en este caso ofrecer un lenguaje de consulta fácilmente aprendible por usuarios no técnicos. Por ejemplo el SRS permite a los usuarios especificar una combinación lógica de expresiones regulares para indexar en campos de interés. Esto es muy útil para laboratorios con manejadores sin formación profesional en computadoras. En la vistas o warehouse el usuario ve el esquema global de los datos fuente. Para mejorarlo el esquema debe dar al usuario la posibilidad de conectar varias piezas de información. Esto puede hacerse explicito dado a este una tabla de linking identificando los hot links a diferencia de las federaciones link-driven , o puede proveer software para machear entre la información.

12. K2/Kleisli K2 es la ultima encarnación del sistema de consulta distribuido que fue desarrollado los pasados siete años en la Universidad de Pennsylvania. K2 esta basado en muchos de los principios que guiaron el diseño de Kleisli, su conceptual predecesor. Como Kleisli, K2 usa un modelo de datos de valor complejo. Se tomo la decisión de que K2 soportara lo mas recientes lenguajes de consulta OQL. OQL usa el estilo de sintaxis de SQL “ select-from-where”, pero su semántica es comprensiva, como CPL.

13. Diccionarios El modelo de datos con valores complejos de K2 permiten incorporar un nuevo tipo de datos, como los “diccionarios”. El diccionario es una función con una definición de dominio finito. Esto permite representar las clases orientadas a objetos como diccionarios cuyo modelo de dominio son las clases extendidas, i.e. sets de objetos identidades. K2 también es diferente de Kleisli en el lenguaje de implementación, mientras Kleisli fue escrito usando Standard ML , K2 es implementado primariamente en Java y hace uso de protocolos estandar y API´s que son parte de la “Plataforma Java”, incluida RMI y JDBC.

14. Data drivers K2 consiste en un set de “data drivers” , cada uno de ellos maneja el nivel bajo de detalles de comunicación con una simple clase de fuente de datos. (e.g. Sybase relational databases, Perl/shell scripts, BLAST 2.x familia, etc). El manejador acepta consultas expresadas en el lenguaje de consulta de esa fuente de datos. Estas trasmiten sus consultas a la fuente para evaluación y entonces convierten el resultado de la consulta en la representación interna de valores complejos de K2. Para las fuentes de datos que soportan esto, esto es echo sobre la base de tupla por tupla o objeto a objeto análogo a el demand-driver tuple paradigma de proceso en las bases relacionales. Los data drivers son los responsables de proveer al K2 con la metadata de la fuente de datos “underlying” (tipos y esquema) que luego es usado para hacer el chequeo de tipos en las consultas. 

15. Ejemplo Para ilustrar como K2 es usado, considere el siguiente escenario en el cual GUS es consultado en combinación con una BD NCBI PubMed. GUS contiene EST assemblies que representan genes. La figura 3 muestra una versión simplificada del tipo K2 que describe la entrada en PubMed que provee en el servicio de red Enterez de NCBI.

16. Enterez La red Enterez provee en el lenguaje C API a PubMed y otras varias BD, incluida GenBank, y usos ASN.1 para representar datos y tipos. ASN.1 es un modelo de datos de valores complejos, mas que lo usado por K2. El controlador de datos de red Enterez ha sido desarrollada usando ASN.1/C API. Este controlador aparece en la interfase de K2 OQL como una función de usuario definido que puede pasar comandos escritos usando una sintaxis ad-hoc . Por ejemplo la siguiente OQL sentencia obtiene todas las sustancias (proteínas, enzimas, etc.) asociadas con la referencia PubMed: K2> enterez(“-g 20296074 –d m –r Enterez-bakc.getmle.data.E.substance.E.name”); Y su resultado es: list( “Heparin”, “Complement 3d”, “N-acetylheparin”, “Glycoproteins”, “Complement 9”, “clusterin”) K2: optimized query in 0.0020 seconds. K2: total elapsed time for request was 1.162 seconds.

17. Sintaxis Enterez define get-medline-substances(pmid) as enterez(“-g” || pmid || “-d m –r Enterez-back.getmle.E.substance.E.name”); Combinando esa función con los datos de genes el el data warehouse GUS, podemos listar la referencias y substancias asociadas a los EST assembly con la siguiente función de vista OQL. La función “GUS-transcript-seqs” toma la entrada de GUS EST assembly ID y retorna el numero de accesión de la secuencia individual Define GUS-transcript-seqs(rnaId) as select enaseq.source_id from GUS_RNASequence rs, GUS_NAFeature naf, GUS_AssemblySequence aseq, GUS_ExternalNASequence enaseq where rs.rna_id = variant( 1: rnaId) and rs.na_feature_id = naf.na_feature_id and rs.na_sequence_id= aseq.assembly_na_sequence_id and aseq.na_sequence_id = enaseq.na_sequence_id;

18. Composición de funciones La segunda función, GUS-transcript-pubmed-refs, joinea la tablas relevante en GUS con PubMed, usando dos funciones que ya están definidas. Llama a get-medline-substances en cada secuencia en EST assembly y retorna una colección de registros, cada uno de ellos contiene una PubMed ID (pmid) y una lista de sustancias. define GUS-transcript-pubmed-refs(rnaId) as select struct( pmid: pmid, substances: get-medline-substances(pmid)) from flatten(select accn-to-ids(“m “ || accn) from GUS-transcript-seqs(rnaId accn) pmid; Ahora podemos llamar GUS-transcript-pubmed-refs con una assembly ID para obtener los PubMed ID´s asociados y sustancias : K2> GUS-transcript-pubmed-refs(101005); Bag((pmid:9530155, substances: list (“Neurotensin”, “Azacitidine”, “neuromedin N”, “Peptide Fragments”)))

19. Aspectos varios No se menciono las capacidades en orientación a objetos de K2. Un aspecto interesante del sistema son que las vistas integradas pueden ser definidas no solo con funciones OQL, sino que también se puede definir con clases orientadas a objetos. Un nuevo lenguaje K2MDL permite a los usuarios especificar como extender y como son computados los atributos para las fuentes de datos underlying . • Usando K2 para definir vistas, los usuarios tienen un rango de opciones, dentro de ellas: • Nivel Alto • Nivel Bajo K2 esta implementado en un servidor muti-hebra y puede manejar múltiples colecciones de clientes. Los clientes se comunican con este usando RMI-IIOP o ad-hoc sockets protocol.

20. Estrategias de Vistas y Datawarehouses - Modelos Relacionales, OO, Objetos Complejos, etc. - Lengujes SQL, OQL, CPL, etc. • Copia Física de los Datos. • Costo Inicial. • Mantenimiento • Resultado de las consultas • Performance • Independencia

21. Detección de cambios en los datos fuente. 1 - Como podemos detectarlos. 2 - Como podemos automatizar el proceso de 'refresh'. 3 - Como podemos monitorear el origen de datos.

22. Automatización del proceso de 'refresh' Mantenimiento de vistas. f(I1 U d1,I2 U d2,...,In U dn) f(I1,I2,...,In) ¿ g ? I1,I2,...,In I1 U d1,I2 U d2,...,In U dn updates

23. GUS (Esquema Unificado Genomático) - Esquema de DataWarehouse. - ADN -> ARN -> proteinas - Muchas Tablas ( muchas secuencias) - Limpieza de Datos

24. GUS (Esquema Unificado Genomatico) Origen de los datos • Manuales o Computacionales • Esfuerzo en la Secuencia del Genoma • Versionados y Similitudes • Metadata

25. GUS (Esquema Unificado Genomatico) Manejo de Actualizaciones • Manejo de versiones. • Algoritmos DIFF • Ambientes de Testing y Produccion.

26. GUS (Esquema Unificado Genomatico) Experiencia • Muchas Revisiones. • Mayor poder en las Consultas. • Legibilidad en las moléculas. • Información

27. GUS (Esquema Unificado Genomatico) GUS Sim. Gen. Ev.

28. Performance • Punto desicivo al momento de decidir la solución. • Velocidad de ejecución de las consultas • Naturaleza de la consulta • Cantidad de fuentes • Estrategias de join • Calidad de servicio de las redes • Diferentes niveles de performance

29. Performance • Dos enfoques: • Datos localizados en una única fuente (warehouse) • GSDB (Nested Loop Joins) • Datos ubicados en más de una fuente • GDB-GSDB (Semi Joins) • GDB-GSDB (Nested Loop Joins) • GDB-Enterez (Nested Loop Joins)

30. Performance Cromosoma 1 2 3 4 5 6 7 8 9 GSDB LJ (isql) 20 20 18 19 19 23 21 20 17 GDB - GSDB SJ (Kleisli) 147 106 215 150 97 93 1 38 75 75 GDB - GSDB NL (Kleisli) 1771 1508 2135 1769 1298 3033 1531 1124 1131 Recuperar el nombre oficial, numeros de entrada y secuencia de aminoácidos de todos los genes humanos conocidos que se mapean al cromosoma c. GDB - Enterez NL (Kleisli) - - - 1113 420 1943 342 558 848

31. Conclusiones Kleisli/K2 • Inicialmente se integraron los datos usando links • Sistema basado en vistas para acceder a múltiples sistemas on line via web • Consultas parametrizadas, elaboradas a demanda y algunas elboradas directamente en CPL • K2 utilizó OQL y mejoró el conjunto de consultas • Retardos de red e inaccesibilidad de los datos pueden ser tolerados

32. Conclusiones GUS • Adecuado para sistemas cuyas fuentes estan siendo utilizadas en sistemas productivos donde los datos son confiables • Mayores niveles de performance • Construcción a partir de sistemas de vistas como K2

33. Conclusiones K2 no fue utilizado para la carga de GUS • OQL es bueno para consultas pero no para reestructuración de grandes volumenes de datos • OQL no presenta sintáxis explícita par inserciones y actualizaciones como SQL, es necesario utilizar llamadas a métodos • Los datos no son reestructurados ni integrados al momento de hacer la replicación sino posteriormente

34. Conclusiones Problemas de la BD basadas en vistas • Estándares y cooperación entre fuentes. • CORBA (OMG, LSR-Life Sciences Research) • Trabajan con los propietarios de las fuentes para que implementen Wrappers que cumplan con determinadas especificaciones. • Problemas: • Diversidad • Autonomía • Rapidéz de cambio en los esqumas

35. Conclusiones Problemas de la BD basadas en vistas • CORBA decayó en popularidad • Apareció XML como formáto universal para el intercambio de datos • XML como base para el almacenamiento de los datos. • Problemas: • Almacenamiento de datos XML • Integración semántica (Mayor esf. en Kleisli) • Capas de mapeo semántico (K2MDL)

36. Crítica del artículo Area de investigación • Sistemas de información basados en la integración de vistas • Sistemas de información basados en almacenes de datos • Aplicaciones de la interoperabilidad a la investigación Científica

37. Crítica del artículo Objetivos • Mostrar alternativas y problemas que se presentan en la integración de datos. • Dinamismo y heterogeneidad de datos en el estudio del genoma. • Problemas en la integracion de datos tan dinámicos, eterogeneos, autonomos y distribuidos.

38. Crítica del artículo Motivación • La utilización de estas tecnologías fue pionera en la materia • Mostrar las diferencias prácticas que se notaron entre las alternativas de almacenes de datos y la integracíon de vistas

39. Crítica del artículo Trabajos relacionas • Tecnologías de interoperabilidad CORBA • XML (Fromato de intercambio y solución de almacenamiento) • Problemas de almacenamiento y consulta sobre datos XML • Problemas de cooperación entre las fuentes (Wrappers, terminologías, etc) • Integración semantica

40. Crítica del artículo Calidad técnica, originalidad, etc • Puntos fuertes: • Objetividad • Amplitud • Claridad • Puntos débiles: • Poca profundidad técnica • Desactualizado • No discute temas importantes como integración semántica