Database Reference
In-Depth Information
mit den möglichen Werten Kreditkarte, Bankeinzug oder Rechnung. In diesem Fall liegen
im Quellsystem umfangreichere Informationen vor als im Zielsystem benötigt werden. Bei
der konkreten Umsetzung muss daher nur geprüft werden, ob bei einem Join über die Rela-
tionen „Bestellung“ und „Kreditkarte“ ein Datensatz für eine konkrete Bestellung existiert.
Falls ja, so muss im Ziel für das Attribut Zahlweise der Wert Kreditkarte gewählt werden.
Existiert ein Datensatz für einen Join über „Bestellung“ und „Rechnungen“, dann muss der
Wert Rechnung gewählt werden usw. Wenn auch in der Praxis die Zusammenhänge mitun-
ter etwas komplizierter zu inden sind, ist das Prinzip doch im wesentlichen gleich. Ist die
Situation jedoch umgekehrt, d. h. müssen Werte auf Attribute oder sogar Relationen ab-
gebildet werden, fehlen substantielle Informationen. Speziell bei der Abbildung von Attri-
buten auf Relationen entstehen zunächst viele unvollständige Datensätze. Dieses Problem
muss dokumentiert werden und durch die Fachabteilungen müssen geeignete Strategien
deiniert werden, wie mit den fehlenden Informationen umzugehen ist.
Umgang mit berechneten Werten
Ein typisches Beispiel für diese Aufgabe ist die Einbeziehung von Steuersätzen. So kön-
nen z. B. in einem System Nettopreise und separat der jeweilige Steuersatz, im anderen nur
Preise angegeben sein. Ohne genaue Dokumentation wird nicht sofort erkennbar sein, ob
es sich im zweiten Fall um Netto- oder Bruttopreise handelt. Hinzu kommt bei länderüber-
greifenden Projekten das Problem unterschiedlicher Steuersätze. Sind die Berechnungs-
grundlagen einmal identiiziert, ist das weitere Vorgehen einfach. Zunächst ist zu norma-
lisieren, d. h. falls das Attribut berechnete Werte enthält, ist das Attribut in die jeweiligen
Grundwerte aufzuteilen. Die Berechnungsvorschrift ist als Regel zu hinterlegen. Gelten im
Ziel andere Berechnungsvorschriften, empiehlt es sich, historische Daten in separaten Re-
lationen abzubilden (wobei kenntlich zu machen ist, auf welcher Berechnungsgrundlage
die Werte beruhen) und die neue Berechnungsvorschrift nur für Daten ab dem Integrati-
onszeitpunkt anzuwenden.
Umgang mit zusammengesetzten Werten
Die Attribute der verschiedenen Quellsysteme bzw. die Attribute eines Quell- und des Ziel-
systems können sich auch im Hinblick auf ihre
Atomarität
unterscheiden. Typische Bei-
spiele sind Adressen, Personennamen oder Telefonnummern. Je nach Anforderung und
Modellierungsstrategie sind sie mehr oder weniger aufgesplittet. Je nach Integrationsziel
und -strategie müssen sie im Ziel entweder verknüpft oder aufgeteilt werden. Wichtig ist
an dieser Stelle, dass die zusammengehörenden Werte im Ziel nicht auseinandergerissen
werden.
Die hier angeführten Aufgaben werden in konkreten Integrationsprojekten in unterschied-
lichem Umfang relevant, manche Aufgaben fallen möglicherweise gar nicht an, andere da-
für in weit umfangreicherem Maß als hier angesprochen. Alle denkbaren Fälle aufzuführen
ist wegen der Verschiedenartigkeit der konkreten Projekte weder möglich noch sinnvoll.
Die Phase der Schema-Integration ist die aufwendigste Phase im Integrationsprozess. Be-
sonders bei großen und komplexen Schemas muss sehr viel Zeit eingeplant werden. Der
Aufwand steigt nochmals, wenn nur unzureichende Dokumentationen verfügbar sind. Um
