DWH-Lösungen sind von einem Meer von unstrukturierten Daten umgeben, die 4/5 aller zur Verfügung stehenden Daten in einem Unternehmen betragen. Was ist der neue Horizont des DWH? Ganz klar: die unstrukturierten Daten.
Es geht also um das Finden und Entdecken im Bereich der unstrukturierten Daten und der Interaktion mit dem DWH. Während es beim Finden um gewohntes Navigieren mittels WEB-Suche geht, bei der Suchende aus der Fülle der Ergebnisliste die passenden Dokumente und Informationen selber noch selektieren muss, geht es beim Entdecken um Mining-ähnliche Verfahren, durch die Muster in den Daten identifiziert werden, die die strukturierten Daten ergänzen können.
In diesem Kontext möchte ich den neuen architektonischen Ansatz von Barry Devlin ins Spiel bringen. Er heißt Business Integrated Insight (BI²) und er vereint die unstrukturierten mit den unstrukturierten Daten. Daraus ergeben sich auch Ansätze, die die unstrukturierten Daten auffindbar machen und deren Integration in das DWH ermöglichen. In diesem Artikel wird ausführlich über semantisches WEB und seine Bedeutung für die Anbindung von unstrukturierten Daten an das DWH gesprochen.

2. Schichtenarchitektur von Business Integrated Insight

Business Integrated Insight besteht aus drei Schichten: Menschen, Prozesse und Informationen. Diese Aufteilung sollte den SOA-Vertrauten oder SAP Netweaver Spezialisten bekannt vorkommen. Die erste Schicht, wohl bekannt, „Business Information Resource“, beinhaltet alle Informationen, die für das Unternehmen zur Erreichung seiner Ziele notwendig sind. „Business Function Assembly“ ist in seiner Essenz die Stelle, wo die Prozesse des Unternehmens definiert werden. In der letzten Schicht sind die Menschen angesiedelt. Dieses trägt den Namen „Personal Action Domain“ und beschreibt, wie Mitarbeiter mittels der Prozesse interagieren, um die persönlichen Ziele und die Unternehmensziele zu erfüllen.

Abbildung 1: Schichtenarchitektur Business Integrated Insight (BI²)

3. BI² und Business Information Resource

Für diesen Artikel ist die erste Schicht, Business Information Resource (BIR), relevant. BIR liefert eine logische Sicht über alle Daten des Unternehmens.
Gewöhnlich sprechen wir über strukturierte und unstrukturierte Daten, oder harte und weiche Daten. Bei genauerer Betrachtung erweist sich diese Aufteilung als unzureichend, denn Daten haben viel mehr Attribute, wie persönlich, lokal, stabil, historisch, abgeleitet, etc. vorzuweisen. Barry Devlin definiert dafür ein dreidimensionales Modell. Seine Achsen sind „Timeliness/Consistency“, „Reliance/Usage“ und „Structure / Knowledge Density“.

Abbildung 2: Die Achsen von Business Information Resource

Visuell ist dieses Modell im folgenden Diagramm zu sehen. Die Werte auf den Achsen sind nicht als klar und diskret definiert, sondern eher als Anhaltspunkte. Wo eine Information auf einer dieser Achse zu positionieren ist, obliegt der Subjektivität des Betrachters. Was ist die Bedeutung dieser Achsen?

1. Timeliness / Consistency: beschreibt wie eine Information sich ändert von der Entstehung für einen bestimmten Zweck bis zu einem historischen (nicht mehr veränderbaren) Zustand.
2. Structure / Knowledge Density: beschreibt „die Reise“ der Information vom unstrukturierten Zustand bis zu einem strukturierten Zustand, der mithilfe von Kontextinformationen immer mehr Wissen beinhaltet.
3. Reliance / Usage: beschreibt den Weg der Information von einer bestimmten Person bis auf eine Abteilung-, Unternehmen- oder Globalebene.
4. Die Achse „Timeliness / Consistency“

Data Warehousing wurde ursprünglich konzipiert, um die Abhängigkeit von der Volatilität der Daten zu reduzieren. Dies war für viele Jahre ausreichend, denn damit konnte man die Vergangenheit analysieren, um für die Zukunft besser gerüstet zu sein. Wenn wir aber den Horizont erweitern und auch operationale Daten in Betracht ziehen, dann sind andere Eigenschaften von Bedeutung. Hier sind die Daten nur zu einem bestimmten Zeitpunkt korrekt, dann werden sie verändert, beobachtet, gegen anderen Daten validiert und schließlich historisiert. Plastisch ausgedrückt, die Daten werden immer solider, härter.
Eigentlich sind „timeliness and consistency“ nicht miteinander verbunden, jedoch ist es in der IT üblich, die „Zeitlosigkeit“ und die Konsistenz der Daten miteinander zu verbinden. Da wir hier über eine logische Datenarchitektur sprechen ist jedoch zu beachten, dass Daten, die logisch zusammenhängen, physisch öfter in separaten Prozessen verändert werden. Daher ist die Konsistenz der Daten nicht immer gewährleistet. Man könnte sogar sagen, dass die Konsistenz (Nicht-Veränderbarkeit der Daten) steigt, wenn wir uns in der Richtung der historischen Daten bewegen.

Diese Bemerkungen führen dann zu der Klassifizierung der Daten in fünf Klassen:

• In-flight Daten bestehen aus Meldungen, die gerade am Entstehen im Unternehmen sind. Sie sind erst dann valide wenn der Moment der Entstehung vorbei ist.
• Normalerweise fließen solche „in-flight“-Daten in Datenbanken. In dem Fall nennen wir diese Daten live. Jedoch in Szenarien, wo sehr viele Daten mit einer rasanten Geschwindigkeit aufgenommen werden, werden die Daten nicht in der atomaren Form aufgenommen. Live Daten haben eine eingeschränkte Zeit, in der sie valide sind.
• Stable and reconciled (wir haben reconciled mit „abgestimmt“ übersetzt): Daten sind mittelfristig stabil (werden nicht mehr verändert), Zusätzlich sind abgestimmte Daten in Ihrer Bedeutung konsistent, da sie überprüft wurden.
• Historical (historische) Daten erweitern die Zeitperiode, in der die Konsistenz und die Validität der Daten unverändert bleiben. In diesem Zustand werden Daten „eingefroren“.

5. Die Achse Structure / Knowledge Density

Ursprünglich waren alle strukturierten Daten unstrukturiert. Erst wenn eine Struktur definiert wird, die dann in einem umfangreichen Datenmodell eingebettet wird, werden die Rohdaten in Strukturen „gegossen“. Dabei gehen viele Informationen verloren, die nicht in die Strukturen passen. Der Prozess, eine Struktur in den Rohdaten zu identifizieren, ist allgegenwärtig in der Arbeitswelt.
Bei der Modellierung der Daten definiert man implizit auch Metadaten, wie z.B. Feldnamen, Bedeutung von Feldern, Beziehungen, Wertebereiche, etc. Es ist jedoch nicht immer gewünscht, aus allen Daten strukturierte Daten zu gewinnen. Es ist sogar zu empfehlen, nach Lösungen zu suchen, die die Strukturierung der Daten vermeiden. Dazu kommen wir später.
Die Achse ist so zu verstehen, dass die Strukturierung der Daten abnimmt, wenn wir uns darauf „bewegen“. Es ist hier interessant zu beobachten, dass durch die Strukturierung der Daten mehr Wissen in einer kleinen Menge von sichtbaren Daten verpackt wird. Somit nimmt die Dichte des Wissens zu (so erklärt sich die zweite Bezeichnung der Achse, Knowledge Density). Für die IT ist dies ein wichtiges Ziel, denn dadurch kann der Informationskonsument bedient werden. Die Kehrseite der Medaille bei diesem Prozess ist aber, dass viele implizite Informationen, die in den Ursprungsdaten vorhanden waren, nicht mehr zu finden sind. Und das ist ein triftiger Grund, nicht alle Daten zu strukturieren.
Dabei identifiziert Barry Devlin zuerst die atomaren Daten (atomic). Hier ist eine einzige Information per Dateneinheit vorhanden. Atomare Daten sind in relationalen Datenbanken zu finden. Bei dieser Klasse sind sehr viele Informationen über die atomaren Daten in den Metadaten vorhanden. Diese Metadaten sind aber physikalisch in den meisten Fällen separat gespeichert.
„Derived data“, abgeleitete Daten, sind Daten, die aus den atomaren Daten durch diverse Bearbeitungsschritte gewonnen wurden. Beispielweise können atomare Daten später aufsummiert werden. Somit werden am Ende die Operanden der Summe verloren gehen. Um die abgeleiteten Operationen zu beschreiben nutzen wir Metadaten, die die Bedeutung dieser Schritte festhalten.
„Compound data“, zusammengesetzte Daten, ist die Bezeichnung der dritten Klasse und verweist auf XML oder ähnliche Datenstrukturen, wo Daten und Metadaten miteinander vermischt werden. In solchen Fällen sind jedoch zusätzliche Metadaten in separaten Dateien zu finden. Hier ist die Struktur nicht mehr so rigide wie es bei den atomaren Daten der Fall war.
Die letzte Klasse in diesem Kontinuum ist „Multiplex data“, Multiplex-Daten. Hier sind Dokumente, Bilder, Videodateien und alle Arten von binary large object (BLOB) einzuordnen. In diesem Fall sind die Metadaten implizit im Dokument zu finden. Hier fehlen Strukturen fast vollständig, oder besser gesagt, sie sind implizit, und warten darauf, identifiziert zu werden.

SOURCE: Am Horizont des Data Warehousing, Teil 1

Aktuelle Artikel von Alexandru Draghici

• Aktuelle Ansätze für In-Memory-Lösungen und -Appliances
• Competitive Intelligence, die natürliche Ergänzung zu Business Intelligence
• Am Horizont des Data Warehousing, Teil 2
• Compliance-Anforderungen, Text Analytics und Sentiment Analysis