Database Reference
In-Depth Information
Vereinheitlichung von Wertelisten und Kodes
Häuig werden zur Ersetzung von konkreten Werten sogenannte
Kodes
verwendet (z. B.
könnten bei einem Attribut „Geschlecht“ statt der Werte „männlich“ und „weiblich“ die
Werte „m“ und „w“ verwendet werden), die einfacher zu verwalten sind. Die erlaubten
Werte werden oft zusätzlich als Werteliste in einem CHECK-Constraint deiniert, um un-
terschiedliche Einträge für den gleichen Sachverhalt zu verhindern. Müssen Quellsysteme
zusammengeführt oder auf ein Ziel gemappt werden, kann es vorkommen, dass sich zum
einen die verwendeten Kodes unterscheiden und zum anderen der Umfang der vorgege-
benen Werteliste.
Bilden die Kodes den gleichen Sachverhalt ab, ist die Abbildung recht einfach, da die Werte
aus den Quellen einfach durch die Zielwerte ersetzt werden (z. B. „Geschlecht“ im Quell-
system und „Anrede“ im Zielsystem, „Geburtsdatum“ im Quellsystem und „Altersgruppe“
im Zielsystem).
Ebenfalls noch gut beherrschbar ist der Fall, dass gleiche Sachverhalte, aber unterschiedli-
che Ausprägungen abgebildet werden (z. B. „Früchte“ mit den Werten Banane, Apfel, Oran-
ge in einem System und „Obst“ mit den Werten Birne, Apfel, Melone im anderen System).
Hier werden die Wertelisten und die entsprechenden Kodes vereinigt, Mehrfachvorkom-
men von Werten und Kodes werden beseitigt.
Schwieriger ist der Umgang mit sich überlappenden Ausprägungen (z. B. „Produktkatego-
rien“ in einem Quellsystem mit den erlaubten Werten Sport, Gesundheit, Ernährung und in
einem anderen Quellsystem „Artikelgruppen“ mit den erlaubten Werten Fitness und Well-
ness). Hier müssen gemeinsam mit den Fachabteilungen klare Zuordnungen deiniert wer-
den.
Ob es sinnvoller ist, die Daten einer Quelle so aufzubereiten, dass sie auf die Werteliste
der anderen Quelle (oder des Ziels) abgebildet werden können oder ob eine neue, globale
Werteliste als Lookup hilfreicher ist, muss im Einzelfall gemeinsam mit der Fachabteilung
entschieden werden.
Vereinheitlichung von Formatierungen
Die meisten Variationen inden sich üblicherweise bei Telefonnummern, Datumswerten
und Personennamen. Auf Schema-Ebene sind hier die Attribute so weit wie möglich auf-
zuteilen (zu
atomarisieren
). Bei Datumswerten ist es empfehlenswert, in einem Zwischen-
schritt das Datum aufzuteilen und die einzelnen Datumsbestandteile als separate numeri-
sche Attribute zu deinieren, d. h. Tag, Monat, Jahr, Stunde, Minute usw., die dann je nach
Bedarf in das gewünschte Datumsformat überführt werden können. Genauso können Te-
lefonnummern behandelt werden, die zunächst in die Attribute Ländervorwahl, Ortsvor-
wahl, Anschluss, Nebenstelle aufgeteilt und später wie gefordert wieder kombiniert werden
können. Auch bei Personennamen ist diese Vorgehensweise sinnvoll, hier sollten Attribute
für den akademischen Grad, Namenszusätze, Vornamen, Mittelnamen und Familienna-
men sowie ggf. Adelsprädikate (falls relevant) vorgesehen werden. Gibt es keine standar-
disierten Vorgaben, weisen die tatsächlich gespeicherten Werte eine enorme Vielfalt hin-
sichtlich der Schreibweisen auf. Hier hat es sich als nützlich erwiesen, zunächst mittels
Data Proiling
die vorkommenden Wertemuster zu ermitteln und für jedes Muster eine ei-
gene Vorschrift abzuleiten.
