Informationsintegration

Unter Informationsintegration versteht man das Zusammenführen von Informationen aus verschiedenen Datenbeständen (Datenquellen) mit in der Regel unterschiedlichen Datenstrukturen in eine gemeinsame einheitliche Datenstruktur.

Dabei sollen vor allem heterogene Quellen möglichst vollständig und effizient zu einer strukturierten Einheit zusammengeführt werden, die sich effektiver nutzen lässt, als dies bei direktem Zugriff auf die einzelnen Quellen möglich wäre. Informationsintegration ist vor allem dort notwendig, wo mehrere gewachsene Systeme miteinander verbunden werden sollen, also beispielsweise bei der Zusammenführung von Unternehmen, Arbeitsabläufen und Anwendungen oder bei der Informationssuche im Internet.

Die Integration komplexerer Systeme ist erst in den 1990er Jahren in den Blickpunkt der informatischen Forschung gerückt und somit in der Entwicklung begriffen.

Geschichte

Die rasche Entwicklung in der Technologie von Datenbanken seit den 1960er Jahren führte zum Bedarf, vorhandene Daten zu teilen und zu kombinieren. Diese Kombination kann auf einer Vielzahl von Ebenen in der Datenbankstruktur stattfinden. Eine populäre Lösung beruht auf dem Prinzip des Data-Warehouse, welches die Daten aus heterogenen Quellen extrahiert, transformiert und in ein vereinheitlichtes System lädt.

Seit 2009 geht der Trend der Informationsintegration in Richtung von standardisierten Abfrageinterfaces, um die Daten in Echtzeit abzufragen. Dies erlaubt, die Daten direkt aus den heterogenen Quellen abzufragen, was einen Vorteil in der Aktualität der Daten liefert, aber erhöhte Zugriffszeiten abverlangt. Seit 2010 beschäftigen sich einige Forschungsarbeiten auf diesem Gebiet mit dem Problem der semantischen Integration. Diese beschäftigt sich weniger mit der Struktur der Architektur verschiedener Datenbanken, als mit der Lösung semantischer Konflikte zwischen heterogenen Datenquellen. Wenn zum Beispiel zwei Unternehmen ihre Datenbanken vereinen möchten, haben bestimmte Konzepte und Definitionen, beispielsweise „Einnahmen“, unter Umständen verschiedene Bedeutungen. Lösungsansätze in dieser Richtung beinhalten die Verwendung von Ontologie und Benchmarking.^[1]

Die seit 2011 bestehenden Modelle zur Datenverarbeitung führen zu Datenisolation in Form von Dateninseln von versprengten Daten. Diese Inseln sind ein ungewolltes Artefakt, bedingt durch die Methodik der Datenmodellierung, welche zu ungleichen Datensätzen führt.^[2] Um diesem Problem entgegenzuwirken wurden Methoden entwickelt, um Datenisolierungsartefakte zu vermeiden und in die Datenstruktur zu integrieren.^[3]^[4]

Methoden

Die Integration heterogener Informationen aus unterschiedlichen Quellen betrifft sowohl die Integration konkreter Daten als auch der Strukturen (Schemata), in denen sie vorliegen. Zunächst müssen in der Regel die lokalen Schemata integriert werden (Schemaintegration), wozu auch (teil)automatische Verfahren herangezogen werden können (Schema Matching). Zur anschließenden Integration der Daten sind Verfahren der Datenfusion und Duplikaterkennung notwendig.

Beispiele für verfügbare Technologien um Informationen zu integrieren beinhalten Ähnlichkeitsanalysen, welche die Erfassung von ähnlichem Text in verschiedenen Quellen über Fuzzy-String-Suche erlauben.^[5]

Möglichkeiten und Ziele

Die Informationsintegration wird in einer Reihe von unterschiedlichen Situationen signifikant, sowohl im kommerziellen als auch im wissenschaftlichen Bereich.^[6] Beispiele für die praktische Anwendung von Informationsintegration finden sich in der Integration von Produktinformationen aus Herstellerangaben und der Abruf dieser Informationen durch Produktsuchmaschinen oder in der Auswertung von verschiedenen geologischen Datensätzen zur Feststellung grenzüberschreitenden Oberflächenbeschaffenheit.^[7]

Bei Redundanz zwischen den Daten verschiedener Quellen (extensionale Redundanz) lassen sich Zusammengehörigkeiten teilweise automatisch bestimmen und für die Komplettierung von Datensätzen (Datenfusion) nutzen. So können beispielsweise die Einträge einer Telefonliste und eines Mitarbeiterverzeichnisses bei Übereinstimmung von Personennamen kombiniert werden. Da somit mehr Informationen über einzelne Objekte zur Verfügung stehen, spricht man auch von Verdichtung.

Ziel der Integration ist, eine konsistente globale Sicht auf alle Datenquellen zu ermöglichen. Redundante Datenquellen lassen sich dabei zur Verifikation nutzen. Die Zusammenführung von intensional redundanten Quellen führt zu einer höheren Abdeckung (Coverage) und die Komplettierung von Datensätzen bei extensionaler Redundanz von Quellen zu einer höheren Dichte (Density).

Materialisierte vs. Virtuelle Integration

Grundsätzlich lassen sich zwei Arten der Integration unterscheiden:

Materialisierte oder physische Integration: Daten aus unterschiedlichen Datenquellen – mit in der Regel verschiedenen Datenstrukturen – werden in die Zielstruktur transformiert und in eine zentrale Datenbasis kopiert, wo sie dann für Auswertungen zur Verfügung stehen. Dieses Prinzip findet sich beispielsweise in Data-Warehouses oder auch im Projekt zum Datenaustausch der Open Archives Initiative.

Virtuelle oder logische Integration: Die Daten verbleiben in den unterschiedlichen Quellen und die Integration findet erst bei einer Anfrage statt (Föderiertes Informationssystem).

Im Vergleich ergeben sich folgende Vor- und Nachteile

Aktualität: Bei materialisierter Integration ergibt sich die Aktualität der Daten aus dem zeitlichen Abstand der Datenaktualisierungen aus den Quellen; ein virtuell integriertes System ist dagegen stets auf dem aktuellen Stand, da die Daten zum Anfragezeitpunkt integriert werden.
Antwortzeit: Da in einem materialisierten System alle Daten zentral gehalten werden, können sie auf schnelle Antwortzeiten optimiert abgelegt werden. Bei virtueller Integration hängt die Antwortzeit stark von der Verfügbarkeit des Datenverwaltungssystems und der Zugriffsgeschwindigkeit auf die Quelldaten, der Übertragungswege sowie den zusätzlich stattfindenden Aufgaben wie Datentransformation (Mapping) und Datenbereinigung ab.
Flexibilität: Als große Datenspeicher sind materialisierte Systeme zumeist schwieriger zu warten als virtuell integrierte Systeme, bei denen die Wartung der Daten Aufgabe der Quellen ist. Außerdem kann das Hinzufügen einer Quelle die gesamte Integration beeinflussen (Global-as-View), während bei virtueller Integration das Hinzufügen, Entfernen oder Ändern einer Quelle nur auf ihr Mapping auf ein globales Schema Auswirkungen hat (Local-as-View).
Autonomie der Datenquellen: Bei materialisierter als auch virtueller Datenintegration wird nicht direkt Einfluss auf die Datenquellen genommen, bspw. bleibt deren Struktur unverändert. Durch den erforderlichen Zugriff können sich jedoch an sie gestellte Anforderungen, wie Erreichbarkeit und Performanz ändern, virtuelle Datenintegration scheint hierbei einen stärkeren Einfluss zu haben, da bei physischer Integration der Zugriff bspw. gezielt zu Zeiten mit im Allgemeinen schwächerer Auslastung erfolgen könnte.
Hardware-Bedarf: Materialisierte Integration erfordert in der Regel die Beschaffung dedizierter Hardware.
Datenqualität: Bei materialisierter Integration steht im Allgemeinen mehr Zeit zur Transformation der Daten zur Verfügung, dadurch sind im Vergleich zur virtuellen Datenintegration aufwendigere Analysen möglich – die erreichbare Datenqualität ist deshalb höher.

Integrationsarchitekturen

Materialisierte Integrationsarchitekturen

Bei materialisierten Systemen werden Daten aus den Quellen importiert, bereinigt und zentral abgelegt. Die in den Quellsystemen vorhandenen Daten werden dabei in der Regel nicht verändert.

Data-Warehouses (DWH): Sind die wichtigsten Vertreter materialisierter Datenbanksysteme. Die für den Informationsbedarf eines Unternehmens erforderlichen Daten werden direkt in einem zentralen Data-Warehouse persistent gespeichert, um eine globale, einheitliche Sicht auf die relevanten Daten zu ermöglichen. Um die Quelldaten in die DWH-Basisdatenbank zu integrieren, muss zu diesem Zweck eine Integrationsschicht implementiert werden (ETL-Prozess).

Operational Data Stores (ODS): Während Data-Warehouse-Systeme primär den Erfordernissen eines Unternehmensmanagement angepasst ist und somit die zur Verfügung stehenden Informationen den strategischen Entscheidungsprozessen dienen, stehen bei „Operationalen Data-Stores“ die integrierten Daten operativen Geschäftsprozessen zur Verfügung. Dies impliziert bereits, dass die in einem zentralen Data-Warehouse gespeicherten Daten „operativ“ eingesetzt werden sollen, d. h. nach der abgeschlossenen Integration (Import, Bereinigung, Speicherung) unterliegen diese Daten Veränderungen. Daher stehen im Mittelpunkt der Betrachtung bei ODS-Systemen auch nicht historische, sondern primär aktuelle Daten. Insofern ergibt sich ein weiteres wesentliches Unterscheidungsmerkmal zu DWH, da die Synchronisation zu den Quelldaten entweder bei Anfragen oder zumindest in häufigen, regelmäßigen Abständen zu erfolgen hat. ODS werden von Unternehmen zumeist in jenen Geschäftsbereichen eingesetzt, in denen die Aktualität der Daten eine wesentliche Rolle spielt, wie z. B. in Kunden- und Lieferanten-Kommunikationsbereichen und in Lagerverwaltungsprozessen. Mit dem Trend zum Realtime-Data-Warehouse und zu leistungsstärkeren Datenbankmanagementsystemen dürfte der Operational Data Store im Data-Warehouse aufgehen.

Virtuelle Integrationsarchitekturen

Im Gegensatz zu materialisierten Systemen werden Daten in virtuellen Datenbanksystemen nicht im integrierten System selbst gespeichert, sondern verbleiben physisch in den Datenquellen und werden nur bei Anfragen in das Integrationssystem geladen (virtueller Datenspeicher).

Föderierte Datenbanksysteme (FDBS): Im Mittelpunkt eines Föderierten Datenbanksystems steht ein „globales konzeptionelles“ (= kanonisches) Schema. Dieses Schema stellt einerseits die Schnittstelle zu den lokalen, verteilten Datenbanken und ihren lokalen Schemata dar und bietet andererseits anfragenden Anwendungen mittels geeigneter Dienste eine integrierte globale Sicht auf die föderierten Quelldaten. FDBS entstehen zumeist durch die Vereinigung mehrerer Datenbanksysteme (Multidatenbanksysteme) mit dem Ziel einer „zentralen“ (föderierten) Koordination gemeinsamer Aufgaben.

Mediator-basiertes Informationssystem & Wrapper (MBS): Mediatoren dienen als „Vermittler“ zwischen Datenquellen und Anwendungen. Der Mediator nimmt hierbei Anfragen der Anwendung entgegen und beantwortet diese, indem er mit den maßgeblichen Datenquellen kommuniziert. Dies impliziert bereits ein großes Wissen über den Aufbau aller föderierten Datenquellen hinsichtlich Schemata und möglichen Inkonsistenzen der verbundenen Entitäten. Im Gegensatz zu föderierten Datenbanksystemen bieten mediatorbasierte Informationssysteme jedoch nur einen lesenden Zugriff auf die integrierten Systeme. Mediatorbasierte Systeme in Verbindung mit Wrappern stellen bereits eine konkrete Softwareausprägung von Middleware dar. Prinzipiell können Mediatoren auch als Teil eines materialisierten Informationssystems eingesetzt werden, etwa als Vermittler zwischen der Integrationsschicht (oder dem zentralen Data-Warehouse), um die Heterogenität der angeschlossenen Quellsysteme zu überwinden. Da jedoch das wesentliche Charakteristikum von materialisierten Systemen, ein im Mittelpunkt stehendes Data-Warehouse, in mediatorbasierten Systemen fehlt, werden sie den virtuellen Informationsarchitekturen zugeordnet.

Peer-Daten-Management Systeme (PDMS): Als letztes in der Praxis relevantes Integrationssystem sollen Peer-Daten-Management-Systeme angeführt werden. Der innere Aufbau einer Peer-Komponente ist wie folgt definiert:

Peers können ein oder mehrere „eigene“ Data-Warehouses verwalten.
Es stehen Schema-Mappings zwischen den eigenen Datenstrukturen und Strukturen anderer Peers zur Verfügung, durch die Datenelemente miteinander in Beziehung gebracht werden können.
Zur Kommunikation mit verbundenen Komponenten stellt jeder Peer ein Exportschema oder Funktionen zur Verfügung. Peers fungieren als eigenständige, autonome Komponenten, die Anfragen sowohl mit eigenen Datenbeständen als auch mit Daten bzw. Anfrageergebnissen anderer verbundener Peers zu beantworten versuchen.

Siehe auch

Datenbankschema, SchemaSQL
Data-Lineage
Dataspaces
Data-Warehouse, Föderiertes Datenbanksystem, Portal (Informatik), Verteilte Datenbank
ETL-Prozess
Mashup (Internet)
Master Data Management
Semantic Web und Linked Open Data: Das Web als verteilte Datenbank

Literatur

Ulf Leser, Felix Naumann, Informationsintegration. dpunkt, 2007, ISBN 978-3-89864-400-6.
Stefan Conrad: Föderierte Datenbanksysteme. Konzepte der Datenintegration. Springer, 1997, ISBN 3-540-63176-3.
M. Tamer Özsu, Patrick Valduriez: Principles of Distributed Database Systems. Prentice Hall, 1999, ISBN 0-13-659707-6.

Einzelnachweise

↑ Shubhra S. Ray u. a.: Combining Multi-Source Information through Functional Annotation based Weighting: Gene Function Prediction in Yeast. In: IEEE Transactions on Biomedical Engineering. Band 56, Nr. 2, 2009, S. 229–236, doi:10.1109/TBME.2008.2005955.
↑ Duane Nickull: Modeling Method to Harmonize Disparate Data Models. 2003.
↑ Michael Mireku Kwakye: A Practical Approach To Merging Multidimensional Data Models. 2011.
↑ Rapid Architectural Consolidation Engine – The enterprise solution for disparate data models. iri (en), 2011.
↑ Dave L. Hall, James Llinas: Introduction to Multisensor Data Fusion. In: Proc. of IEEE. Vol. 85, No. 1, Jan 1997, S. 6–23.
↑ Scott Weidman, Thomas Arrison: Steps Toward Large-Scale Data Integration in the Sciences: Summary of a Workshop. National Research Council 2010, ISBN 978-0-309-15443-7.
↑ Bertram Ludäscher u. a.: Managing Scientific Data: From Data Integration to Scientific Workflows. (PDF; 2,3 MB) sds.edu (en)

[1] Shubhra S. Ray u. a.: Combining Multi-Source Information through Functional Annotation based Weighting: Gene Function Prediction in Yeast. In: IEEE Transactions on Biomedical Engineering. Band 56, Nr. 2, 2009, S. 229–236, doi:10.1109/TBME.2008.2005955.

[2] Duane Nickull: Modeling Method to Harmonize Disparate Data Models. 2003.

[3] Michael Mireku Kwakye: A Practical Approach To Merging Multidimensional Data Models. 2011.

[4] Rapid Architectural Consolidation Engine – The enterprise solution for disparate data models. iri (en), 2011.

[5] Dave L. Hall, James Llinas: Introduction to Multisensor Data Fusion. In: Proc. of IEEE. Vol. 85, No. 1, Jan 1997, S. 6–23.

[6] Scott Weidman, Thomas Arrison: Steps Toward Large-Scale Data Integration in the Sciences: Summary of a Workshop. National Research Council 2010, ISBN 978-0-309-15443-7.

[7] Bertram Ludäscher u. a.: Managing Scientific Data: From Data Integration to Scientific Workflows. (PDF; 2,3 MB) sds.edu (en)

[1]

[2]

[3]

[4]

[5]

[6]

[7]