O'Reilly logo

Data Warehouse Technologien by Saake, Sattler, Köppen

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

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

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required