Data-Dictionary
Ein Data-Dictionary – deutsch Datenwörterbuch, Datenkatalog oder etwas unschärfer Datenverzeichnis genannt – ist ein Katalog von Metadaten, der die Definitionen und Darstellungsregeln für alle Anwendungsdaten eines Unternehmens und die Beziehungen zwischen den verschiedenen Datenobjekten enthält, damit der Datenbestand redundanzfrei und einheitlich strukturiert wird. Es ist ein Anwendungsfall eines spezifischen Datenmodells.
Bei einer relationalen Datenbank ist ein Datenwörterbuch eine Menge von Tabellen und Ansichten, die bei Abfragen (etwa mit der Sprache SQL) nur gelesen werden (read-only). Das Data-Dictionary ist wie eine Datenbank aufgebaut, enthält aber nicht Anwendungsdaten, sondern Metadaten, das heißt Daten, welche die Struktur der Anwendungsdaten beschreiben (und nicht den Inhalt selbst). Aufbau und Pflege eines solchen Datenkatalogs erfolgen üblicherweise über einen interaktiven Dialog oder mit Hilfe einer Datendefinitionssprache (DDL).
Aktive, passive und integrierte Data-Dictionaries
Ein aktives Data-Dictionary reflektiert jederzeit den aktuellen detaillierten Stand des Datenmodells. Änderungen an der Struktur einer Datenbank können direkt in der Pflegeoberfläche des Data-Dictionary erfolgen, oder mit anderen Mitteln, zum Beispiel einem Kommandointerpreter einer DDL. Unabhängig davon, wie diese Änderungen erfolgen, ist die Aktualität eines aktiven Data-Dictionary immer automatisch gewährleistet.
In einem passiven Data-Dictionary ist diese Synchronität nicht gegeben. Änderungen an der Struktur des Datenbank-Management-Systems (DBMS) müssen im Data-Dictionary (DD) manuell nachgepflegt werden, falls das gewünscht und wirtschaftlich möglich ist. Insbesondere DD-Produkte zur Modellierung und Dokumentation des konzeptionellen Datenmodells leiden unter dieser Problematik.
Schnittstellen zwischen Mensch und Software
Ein Datenwörterbuch kann über folgende Schnittstellen abgefragt werden:[1]
- Benutzerschnittstelle
- Datendesigner, -modellierer
- Anwendungsprogrammierer
- Endbenutzer
- Datenbankadministrator
- Software- und DBMS-Schnittstelle
- Compiler/Precompiler
- Integrierte Entwicklungsumgebung (IDE) bei Integration des Data-Dictionary im Sinne von CASE
- Anwendungsprogramme
- Berichts-/Formulargeneratoren
- Query Optimizer
- Integrity Constraint Enforcer
Klassifizierung von Data-Dictionaries nach der Modellierungsebene
In der Entwicklung und Pflege von Datenmodellen werden unterschiedliche Modellierungsebenen unterschieden:
- Konzeptionelle Ebene (in der Regel bezogen auf ein Anwendungsgebiet, in der Wirtschaftsinformatik oft auch unternehmensweit oder sogar unternehmensübergreifend)
- Logische Ebene
- Physische Ebene, in der das konzeptionelle/logische Datenmodell bezogen auf ein bestimmtes DBMS abgebildet und umgesetzt wird.
Entsprechend den unterschiedlichen Ebenen der Datenmodellierung können die Data-Dictionaries nach Unterstützung dieser Modellebenen unterschieden werden. Je nach Ebene unterscheiden sich dabei die Data-Dictionaries nach Art, Inhalt und auch Datentypen der notwendigen Metadaten, aber auch bezüglich ihrer Funktionen und Auswertungsmöglichkeiten.
Data-Dictionary zur konzeptionellen/logischen Datenmodellierung
Zu einem Data-Dictionary zur konzeptionellen/logischen Datenmodellierung gehören:
- Definition der Entitäten, Datenelemente und der Beziehungen zwischen den Entitäten
- Betriebswirtschaftliche Definitionen und Erläuterungen derselben
Neben der Festlegung der wesentlichen Datenobjekte bzw. -elemente und ihren Beziehungen werden typischerweise auch ausführliche beschreibende Texte auf Ebene der jeweiligen Entitäten hinterlegt, welche untereinander mittels Hyperlink-Technik verknüpft sind. Wenn eine Organisation ein unternehmensweites Datenmodell (UwDM) aufbaut, werden zu jedem Datenelement Angaben zur anwendungsbezogenen Semantik, zum Datentyp und zur Datendarstellung zusammengetragen. Die semantischen Angaben definieren die genaue Bedeutung eines Datenelements und sind als Fließtext formuliert. Die Darstellungsregeln legen fest, wie Datenelemente gespeichert werden (z. B. Datentyp wie Integer, Text, maximale Textlänge, Eingabeformat, Ausgabeformate, zulässige Wertebereiche als Prüfregel, statische oder dynamische Menge usw.). Diese erste Form ist häufig im Funktionsumfang eines DBMS nicht als Standardfunktion enthalten. Deshalb müssen hier oft Insellösungen eingesetzt werden. Diese stellen aber in Bezug auf das DBMS ein passives Data-Dictionary dar. Änderungen am konzeptionellen Datenmodell können nicht automatisch in das physische Datenmodell des DBMS übernommen werden.
Unter ISO/IEC 10027 sind Spezifikationen erarbeitet worden, die einen hersteller- und plattformübergreifenden Austausch von Informationsressourcen zwischen verschiedenen Data-Dictionaries erlauben sollen.
Ein Datenkatalog kann auch als Glossar genutzt werden, indem Informationsobjekte/Entitäten, Datenelemente/Attribute und auch Beziehungen/Relationships als Begriffe betrachtet werden, deren Definitionen im jeweiligen Beschreibungsteil abgelegt werden. Das Data-Dictionary kann zu vollständigen Ontologien bzw. Klassen bzw. Geschäftsprozessmodellen weiterentwickelt werden. Wenn neben der Datenstruktur auch die Methoden zur Datentransformation beschrieben werden, spricht man von einem Repository.
Data-Dictionary zur physischen Datenmodellierung
Zu einem Data-Dictionary zur physischen Datenmodellierung gehören genaue Angaben zu:
- Tabellen und Datenfeldern
- Primär- und Fremdschlüsselbeziehungen
- Integritätsbedingungen, z. B. Prüfinformationen
- Stored Procedures und Triggers
- Zugriffslegitimationen (Benutzernamen, Rollen)
- physischen Datenbankstruktur, z. B. Speicherallokationen und Indizes
- Verweis- und Verwendungsnachweis
Diese Form ist in jedem DBMS als aktives Data-Dictionary vorhanden, ist jedoch nicht in jedem Fall für den Anwendungsprogrammierer sichtbar. Wo ein solches Data-Dictionary nicht sichtbar ist, bildet es dennoch die Datenbankstruktur als Datenbankschema, ist jedoch in verborgenen Systemtabellen abgelegt. Bei jedem Zugriff auf die Datenbank liest die DBMS-Systemsoftware das Datenbankschema, um die Struktur und den Speicherort der abgefragten Daten erkennen zu können.
Funktion des Data-Dictionary in der Anwendungsentwicklung
Sinnvoll ist in jedem Fall die Integration der Metadaten aus dem Data-Dictionary in die Integrierte Entwicklungsumgebung (IDE). Für die dynamische bzw. generische Programmierung von Formularen und Berichten ist jedoch darüber hinaus ein für die Bedürfnisse der Anwendungsprogrammierung sinnvoll strukturiertes und sichtbares Data-Dictionary eine notwendige Voraussetzung.
Die Funktionen für die konzeptionelle und die physische Datenmodellierung sind häufig nicht in einem Data-Dictionary integriert. Gravierender noch, Änderungen an der detaillierten Datenbankarchitektur werden nicht ins konzeptionelle Datenmodell zurückgespiegelt. Entweder ist eine aufwendige manuelle Nachpflege notwendig, oder Aktualität des dokumentierten Datenmodells geht verloren.
Ein Data-Dictionary, das sowohl in die Datenbank, die Programmentwicklungsumgebung und die Datenmodellierungsinstrumente integriert ist, erfüllt vielfältige Funktionen:
- Es beschreibt alle persistenten Daten eines Anwendungsgebiets, z. B. in Form eines unternehmensweiten Datenmodells
- Aufgrund der Data-Dictionary -Daten können Bildschirmmasken automatisch generiert werden (siehe generative Programmierung).
- Die Struktur einer Datenbanktabelle kann von einem Programm ausgelesen werden.
- Programme können die Datentypen und -strukturen von Tabellen lesen, die zum Zeitpunkt des Programmentwurfs noch gar nicht existiert haben. Bei geeigneter Sprachunterstützung wird eine statisch fixierte Datendefinition im Programmtext obsolet. Das Data-Dictionary ist somit ein zentrales Instrument in der Anwendungsentwicklung, wenn es darum geht, Datendefinition und -modellierung von der Programmentwicklung zu entkoppeln.
Anwendungsübergreifende Datenkonsistenz
Einer der Vorteile eines wohldefinierten Data-Dictionary ist die Konsistenz der definierten Datenelemente über verschiedene Tabellen einer Datenbank. Beispielsweise können verschiedene Tabellen das Datenelement TelefonNr enthalten; mit einem Data-Dictionary kann gewährleistet werden, dass alle Tabellen auf das gleiche Datenelement verweisen. Somit kann eine datenbankweite Konsistenz und ein Verwendungsnachweis für alle Tabellenfelder und Datenelemente erreicht werden.
BNF-Syntax zum Schreiben von Data-Dictionaries (DD)
– Kontext: Datenflussdiagramm (DFD), ERM, Systemmodellierung
Ein DD kann in seiner groben Strukturierung in der BNF-Notation geschrieben werden und besteht dann aus mehreren Definitionen, die jeweils in einer Zeile stehen. In einer Definition wird in Form einer Zuweisung geschrieben:
- <Nicht-Atomarer Begriff> = <Ausdruck>
Links von der Zuweisung steht ein nicht-atomarer Begriff. Rechts von der Zuweisung steht eine Regel. Eine Regel besteht aus einer Kombination von atomaren und nicht-atomaren Begriffen. Wiederholungen sind möglich. Zirkuläre Definitionen sind verboten, Rekursionen hingegen erlaubt.
- = Zuweisung
- () Optional
- [ | ] Auswahl
- {} Wiederholung
Beispiel:
- Kundenkarte = Anrede + (Titel) + Vorname + Name + {Adresse} + Telefon
- Adresse = Strasse + Hausnummer + PLZ + Ort
- Telefon = Vorwahl + { [0|1|2|3|4|5|6|7|8|9] }
- Vorwahl = 0 + [1|2|3|4|5|6|7|8|9] + { [0|1|2|3|4|5|6|7|8|9] }
- Strasse = string
- Hausnummer = string
- Vorname = string
- Name = string
Siehe auch: Backus-Naur-Form (BNF bzw. EBNF), Syntaxdiagramme
Eine Darstellung in dieser Form erlaubt allerdings nur das Aufzeigen der Metabegriffe und ihrer Beziehungen untereinander. In der Anwendungsentwicklung ist der einzelne Metabegriff in der Regel Träger von vielfältigen Zusatzinformationen wie
- fachliche Beschreibung in Umgangssprache
- Domänenwerte
- Feldbeschreibungen (Kurz-, Mittel- und Langtext) für den Formularentwurf
- Information, ob das Datenelement leer (z. B. NULL) sein darf
- Verweise auf Prüftabellen
Deshalb kann die BNF-Notation zwar dazu dienen, die Entitäten aufzulisten und deren Beziehungen untereinander darzustellen. Für eine feingliederige Attributierung und tiefergehende Dokumentation wird die BNF-Notation sinnvollerweise durch ein eigentliches DD-Instrument unterstützt.
Siehe auch
Literatur
- Ramez Elmasri, Shamkant B. Navathe: Grundlagen von Datenbanksystemen; Pearson Studium, München 2004. ISBN 3-8273-7021-3
- Thomas Connolly, Carolyn Begg, Anne Strachan: Datenbanksysteme. Eine praktische Anleitung zu Design, Implementierung und Management; Addison-Wesley, München 2002. ISBN 3-8273-2013-5
Weblinks
- ISO/IEC 11179 (2003–2005) in der englischsprachigen Wikipedia