Data Warehouse Technologien

Quelle → Arbeitsbereich Arbeitsbereich → Basis-DB

Art des Zugriffs Satzorientiert Mengenorientiert

Verfügbare Datenbasen Eine Quelle (Updatefile) Viele Quellen

Verfügbare Datensätze Quellabhängig: Alle, alle Ände-

rungen, Deltas

Zusätzlich Basis-DB verfügbar

Programmiersprache Skripte: Perl, AWK, . . . oder 3GL SQL, PL/SQL

Tabelle 4.5: Anforderungen in der Transformationsphase

Transformationen vom Quellsystem zum Datenbeschaffungsbereich und vom

Datenbeschaffungsbereich zur Basisdatenbank zusammen.

Für die Transformationen gibt es keine definierte Aufgabenteilung. Ein

möglicher Ansatz, um die anfallenden Arbeiten zu strukturieren, stellt die Ver-

wendung von Mustern (engl. pattern) dar, siehe dazu [KBB11]. Prinzipiell gibt

es das Problem, dass die Quelldaten, die im Datenbeschaffungsbereich geladen

sind, nicht im Format der Basisdatenbank vorliegen. Auch die Struktur der Da-

ten kann sehr unterschiedlich sein. Daher wird im Datenbeschaffungsbereich

oft ein quellnahes Schema genutzt, während das Schema der Basisdatenbank

multidimensional ist. Somit ergibt sich bei der Überführung im Datenbeschaf-

fungsbereich eine strukturelle Heterogenität. Daten- und Schematransforma-

tionen stellen dabei die zentrale Aufgabe im Transformationsprozess dar.

4.4.1 Daten- und Schemakonflikte

Im Folgenden betrachten wir vor allem OLTP-Systeme, da diese die Hauptda-

tenquelle in operativen Umgebungen darstellen. Sekundärsysteme sind Doku-

mente in firmeninternen Altarchiven und im Internet. Vielfach sind diese dann

für den ETL-Prozess in unstrukturierte und semistrukturierte Dokumente un-

terteilbar. Bei unstrukturierten Dokumenten erfolgt der Zugriff oftmals über

Suchmaschinen. Auf semistrukturierte Dokumente kann mittels Suchmaschi-

nen, Mediatoren oder Wrapper als XML-Dokumente oder Ähnliches zugegriffen

werden. Hier wird das Grundproblem der Heterogenität der Quellen deutlich.

Darüber hinaus existieren auch unterschiedliche Datenmodelle, wie in Ab-

bildung 4.11 gezeigt. Ursache hierfür ist die autonome Entscheidung über die

Anschaffung von Systemen in den verschiedenen Unternehmensbereichen. In

den Datenmodellen existieren dabei verschiedene und sogar verschieden mäch-

tige Modellierungskonstrukte. Dies bedeutet, dass die Anwendungssemantik in

den einzelnen Modellen in einem unterschiedlichen Ausmaß erfassbar ist und

eine Abbildung zwischen Datenmodellen nicht eindeutig erfolgen kann.

Beispielsweise lassen sich an dieser Stelle das Relationenmodell, die ob-

jektorientierte Modellierung und XML-Repräsentationen nennen. Aufgrund

der Entwurfsautonomie gibt es unterschiedliche Modellierungen für gleiche

Sachverhalte der Realwelt. Selbst im gleichen Datenmodell sind verschiedene

4.4 Die Transformationsphase 107

Name

Vorname

PLZ

...

Kunde

Kunde

Name

Vorname

PLZ

Kunde

Name

Vorname

PLZ

ERM UML XML-Struktur

Abbildung 4.11: Heterogene Datenmodelle

Modellierungen möglich, so z.B. durch unterschiedliche Modellierungsperspek-

tiven der Datenbankdesigner.

Zusätzlich sind verschiedene Repräsentationen der Daten in den Quell-

systemen möglich. So können unterschiedliche Datentypen genutzt werden. In

Systemen werden auch nicht immer alle möglichen Datentypen angeboten, und

intern weicht die Darstellung der Daten oft voneinander ab. Es kann auch der

Fall eintreten, dass unterschiedliche Werte eines Datentyps zur Repräsentation

derselben Information genutzt werden.

Die Entwurfsautonomie führt zu divergenten Modellen. So können in rela-

tionalen Datenbanksystemen unterschiedliche Normalisierungsgrade genutzt

werden. Auch die Entscheidung über Relation, Wert oder Attribut kann im Mo-

dellierungsprozess abweichend getroffen sein. Die Abbildung 4.12 bietet ein

Beispiel in der Klassendiagrammdarstellung für einen Kunden. Hier ist das

Geschlecht einerseits als Attribut modelliert und andererseits als eigenstän-

dige Klassen, Mann und Frau. Weiterhin können die Aufteilung der Daten in

Tabellen, gewollte Redundanzen aus den Quellsystemen und die Verwendung

von Schlüsseln, z.B. sprechende Schlüssel, in den Bereich der Entwurfsautono-

mie eingeordnet werden.

Kunde

Name

Vorname

Geschlecht

...

Kunde

Name

Vorname

...

Mann Frau

Abbildung 4.12: Schema-Heterogenität

Im SQL-Standard werden diese Aspekte nur unzureichend unterstützt. So

kann mittels INSERT-Statement nur eine Zieltabelle adressiert werden. Mit SQL

108 4 Extraktions-, Transformations- und Ladeprozess