DATA%20CONSULTING%20LOGO
AdobeStock_218913222.jpeg

TEIL 2: METADATEN und DATENKATALOGE

“Standards sind wie Zahnbürsten. Jeder stimmt zu, dass sie wichtig sind, aber keiner möchte die des anderen nutzen”
zugeschrieben Murtha Baca

Wie bereits häufig angemerkt ist die Einführung eines Datenkatalogs kein reines IT-Projekt, sondern muss auf fachlichen Anforderungen basieren. Am Anfang sind einige grundlegende Fragen zu klären:

Was ist der Umfang des Datenkatalogs? Sollen nur die Strukturen der Datenquellen dokumentiert werden oder soll ein Data Hub implementiert werden, der Daten vorhält und ein Datenshopping erlaubt.

Designfragen, ob ein Datenkatalog im engeren Sinne, mit Fokus auf Datenquellen, Datenelemente, Glossar, Verantwortlichkeiten etc., oder vollständigeres Metadatenmanagement gewünscht ist, d. h. eine fachliche Modellierung von z. B. Geschäftsobjekten, Geschäftsregeln oder Datenqualitätsregeln.

Ein Datenkatalog benötigt ein Daten- und Operationsmodell, wie jede andere Anwendung auch. Es müssen die Elemente (Artefakte, Klassen, Entitäten, wie immer man sie bezeichnen möchte), die vom Datenkatalog verwendet werden sollen, festgelegt und definiert werden. In Anlehnung an das Singapore Framework für den Dublin Core muss ein Anwendungsprofil erstellt werden. In der Metadaten-Gemeinschaft wird der Begriff Application Profil (AP) verwendet, um die Anpassung von Standards an bestimmte Anwendungen zu beschreiben.

Die folgenden Schritte zeigen den Ablauf zum Aufbau eines solches DataCatalogAP exemplarisch.

  1. Benötigte Fähigkeiten der Applikation festlegen, z. B. die Modellierung und Speicherung von Geschäftsobjekten, Attributen, Geschäftsregeln, Datenqualitätsregeln, den Import und das Design von Datenmodellen, Im- und Export von Datenlieferungen etc.
    Jede funktionale Forderung sollte in maximal zwei Zeilen pro Anforderung beschrieben sein. Beispielsweise:
    1. Das System soll Metadaten zu einer Datenqualitätsapplikation speichern
    2. Es sollen die einzuhaltenden Geschäftsregeln modelliert werden
    3. Es sollen die überwachenden Datenqualitätsregeln modelliert werden
    4. Es soll die Abbildung des semantischen Datenmodells auf das logische Datenmodell dokumentiert werden
  2. Ein Domänenmodell entwickeln. Beschreiben der Elemente und ihrer Beziehungen, um die Forderungen abdecken zu können. Als Notation bietet sich das Object Role Modeling (ORM) oder die modernere Unified Model Language (UML) an. In unseren Beispielen (und auch den meisten Kundenimplementierungen) nutzen wir die UML 2.5.

  3. Eigenschaften beschreiben. Die dritte Stufe detailliert das Domänenmodell aus. Die benötigen Objekte und Attribute werden fachlich in einem Glossar beschrieben. Bei Beschreibung greifen wir auf bestehenden Metadatenmodelle und aber auch auf Metadatenelemente (also die Meta-Meta Ebene) zurück. Ein Metadatenelement kann dabei Grundlage für mehrere unterschiedliche Attribute sein, z. B. wird ein Titel (http://purl.org/dc/elements/1.1/title) als Name eines Geschäftsobjektes, eines Datenelements und einer Datenqualitätsregel verwendet. Auch die verwendeten Beziehungen (http://purl.org/dc/terms/relation) können aus bestehenden Metadatenelementen kommen, z. B. DQ-Regel gehört zu (isPartof http://purl.org/dc/terms/isPartOf) Geschäftsregel.


  4. Syntax und Wertebereich festlegen (Datumsformat, erlaubte Werte …)
    Der 4. Arbeitsschritt kann auch parallel zum Festlegen der Attribute durchgeführt werden. Hier werden die Datenstandards festgelegt, z. B. in welchem Format werden Datum oder Beträge gespeichert oder welche erlaubten Werte gibt es für ein Attribut. Bei den erlaubten Werten sollte man, wie bei den Attributen auch, auf vordefinierte Werte zurückgreifen (enumerations).
  5. Richtlinien und Regeln für die Nutzung der Applikation festlegen. An diesem Punkt ist das Applikationsmodell des Datenkatalogs beschrieben. Nun gilt es ein Operationsmodell zu entwickeln:
    – Festlegen der Rollen im Datenkatalog (Kompetenzen, Aufgaben …)
    – Festlegen der Geschäftsregeln: Für jedes Element muss ein Glossareintrag existieren, keine DQ-Regeln ohne eine Geschäftsregel etc.
    – Festlegen der Mindestinformation pro Element: Welche Attribute sind verpflichtend und welche optional?
  6. Applikation implementieren (technisch und organisatorisch)
    Wie führe ich den Datenkatalog ein? Wie fange ich an? Einige Implementationen nehmen den Quellen-Ansatz, das bedeutet eine Quelle wird in den Datenkatalog importiert, Beziehungen abgebildet und fachlich dokumentiert. Wir empfehlen aber einen fachlichen – prozessorientierten – Ansatz, bei dem die Elemente eines bestehenden Geschäftsprozesses im Datenkatalog dokumentiert werden und in einem zweiten Schritt die Quellen mit diesen Elementen verbunden werden. Mit jedem weiteren Geschäftsprozess, den man abbildet, kann man dabei auf bereits dokumentierte Elemente zugreifen. Man kann schneller Ergebnisse präsentieren, hat einen Erfolg, wenn man einen Prozess abgebildet hat und sieht auch schnell Probleme im existierenden Prozessdesign.