Datenmodellierung

Ziel

Die Entscheidung, die das Modell trägt, ist die Struktur der persistenten Daten. Der BABOK hält dies als Stärke der Technik fest: Die Durchsicht eines logischen Datenmodells erlaubt zu prüfen, ob der Entwurf der persistenten Daten den fachlichen Bedarf korrekt abbildet. Eine Strukturentscheidung ist nach der Implementierung teuer rückgängig zu machen, und das Modell macht sie vorher verhandelbar.

Das Modell beantwortet drei Fragen in dieser Reihenfolge: worüber die Organisation Buch führt, was sie über jedes Einzelne festhält und wie diese Dinge zusammenhängen. Die Antworten heissen Entität, Attribut und Beziehung, und eine Beziehung gilt erst dann als gesetzt, wenn sie gezählt ist: Jeder Kunde gehört zu genau einem Verkaufsgebiet, ein Verkaufsgebiet zählt null, einen oder mehrere Kunden.

Einsatz

Wann sie einzusetzen ist

• Entwurf einer relationalen Datenbank: Die persistente Struktur wird vor der Implementierung festgelegt.
• Entwurf objektorientierter Software: Die Klassen und ihre Assoziationen rahmen den zu schreibenden Code.
• Durchsicht eines Datenentwurfs: prüfen, ob das logische Modell den fachlichen Bedarf trifft.
• Bestehendes System ohne Dokumentation: die reale Struktur rekonstruieren, bevor über Übernahme oder Migration entschieden wird.
• Domäne unter Verdacht der Inkohärenz: Die formale Modellierung bringt Widersprüche und Anforderungen zutage, die die Prosa verdeckte.

Wann sie nicht einzusetzen ist

• Rein fachliches Publikum ohne IT-Hintergrund: Der Formalismus schreckt ab, für dieses Publikum das Begriffsmodell oder das Glossar halten.
• Bedarf auf Elementdefinitionen begrenzt: Format, Länge und zulässige Werte gehören allein zum Datenwörterbuch (10.12).

Die Elemente des Modells

Der BABOK zerlegt das Modell in fünf Elemente: die Entität oder Klasse, das Attribut, die Beziehung oder Assoziation, das Diagramm, das sie trägt, und die Metadaten, die das Modell wahlweise enthält.

Entität, Attribut, Beziehung

Eine Entität ist das, worüber der Fachbereich Buch führt: etwas Physisches (ein Lager), etwas Organisatorisches (ein Verkaufsgebiet), etwas Abstraktes (eine Produktlinie) oder ein Ereignis (ein Termin). Jedes Vorkommen trägt einen eindeutigen Identifikator. Auf einem Klassendiagramm heisst dieselbe Sache Klasse und trägt ein Fach mehr, jenes der Operationen: eine Rechnung ausstellen, ein Konto eröffnen.

Ein Attribut ist eine über die Entität festgehaltene Information, samt dem Datentyp, den es trägt. Sein eindeutiger Name, seine Aliasnamen, seine zulässigen Werte und seine Definition im Kontext der Lösung sind der Inhalt eines Eintrags im Datenwörterbuch. Die zulässigen Werte werden oft von einer anderswo geführten Geschäftsregel gesetzt, die die Geschäftsregelanalyse abdeckt.

Eine Beziehung sagt, wie zwei Entitäten zusammenhängen. Der BABOK gibt die Leseformel dafür, die sich vor einem Fachexperten so aussprechen lässt, wie sie dasteht: Jedes Vorkommen dieser Entität ist mit einer minimalen und einer maximalen Zahl von Vorkommen jener anderen Entität verbunden. Eine Beziehung liest sich in beide Richtungen und die beiden Lesarten sind zwei verschiedene Geschäftsregeln, die getrennt zu validieren sind. Auf einem Klassenmodell wechseln die Wörter für dieselbe Idee: Assoziation und Multiplizität.

Kardinalität und Optionalität

Hinter dem Wort Kardinalität stehen zwei unabhängige Fragen, und sie als eine zu behandeln ist der häufigste Fehler auf einem logischen Modell. Die erste betrifft das Maximum: Kann ein Vorkommen auf der anderen Seite mehrere berühren oder nur eines? Die zweite betrifft das Minimum: Muss es mindestens eines berühren, oder darf es keines berühren? Der BABOK führt beide Grenzen unter dem einen Begriff Kardinalität. Die Tradition aus Barkers Methode nennt die zweite die Optionalität: Eine Beziehung ist obligatorisch, wenn ihr Minimum eins beträgt, und fakultativ, wenn es null beträgt.

Beide Grenzen werden an beiden Enden gesetzt, was vier Werte ergibt, die für eine einzige Diagrammlinie zu validieren sind. Auf der Beziehung zwischen Versicherte Person und Police: Eine versicherte Person hält null, eine oder mehrere Policen; eine Police wird von genau einer versicherten Person gehalten. Das Minimum wird selten diskutiert und trägt doch eine Implementierungsentscheidung: Null zu schreiben erlaubt der Datenbank, eine versicherte Person ohne jede Police zu führen, Eins zu schreiben verbietet ihr das und zwingt die Anwendung, die versicherte Person und ihre erste Police in derselben Transaktion anzulegen.

Das Minimum mit der Geschäftsregel zu beantworten ergibt eine falsche Grenze. Die obligatorische Krankenpflegeversicherung gilt für jede Person mit Wohnsitz in der Schweiz, was dazu verleitet, auf der Seite der Police eins zu schreiben. Das Dossier einer versicherten Person besteht im System aber bereits zwischen dem Beitrittsgesuch und der Ausstellung des Vertrags, und es besteht noch nach der Kündigung der letzten Police. Die minimale Grenze beschreibt die Zustände, die die Datenbank jederzeit annehmen muss, samt den Übergangszuständen, die die Geschäftsregel nicht kennt.

Eine standardmässig gesetzte Grenze ist eine erfundene Geschäftsregel. Das "mehrere", das von Amtes wegen gesetzt wird, weil es billiger rückgängig zu machen ist, gewährt eine Erlaubnis, die niemand gegeben hat, und es kommt an dem Tag ans Licht, an dem die Anwendung einen Fall akzeptiert, den der Fachbereich ablehnt. Jede Grenze wird beim Fachexperten validiert, in den Begriffen seiner Arbeit: wie viele Policen eine versicherte Person gleichzeitig halten kann, ob eine Police mehrere Personen decken kann. In der Schweizer Krankenversicherung lautet die zweite Antwort nein, da jede Person für sich selbst versichert ist, auch wenn der Haushalt eine einzige Rechnung erhält. Ein Modell, das ja antwortet, verwischt die Unterscheidung zwischen dem Vertrag und seiner Fakturierung.

Identifikator, Primärschlüssel, Fremdschlüssel

Der Identifikator erscheint schon auf der konzeptionellen Ebene, wo er das Attribut bezeichnet, das ein Vorkommen von den übrigen unterscheidet. Auf der logischen Ebene wird er zum Primärschlüssel und übernimmt drei Pflichten: eindeutig zu sein, unter allen Umständen gefüllt zu sein und über die Zeit stabil zu bleiben.

Der natürliche Schlüssel ist ein Attribut, das der Fachbereich bereits besitzt: die AHV-Nummer einer versicherten Person, die Nummer einer Police. Der technische Schlüssel, auch Surrogatschlüssel genannt, ist eine bedeutungslose Zahl, die das System allein zum Zweck der Identifikation vergibt. Der natürliche Schlüssel lässt sich lesen, auf einem Tabellenauszug mit blossem Auge prüfen und spart eine Spalte. Zwei Schwächen wiegen oft gegen ihn. Er ändert sich an dem Tag, an dem der Fachbereich seine Nummerierung ändert, wie die AHV-Nummer, die 2008 von elf auf dreizehn Stellen wechselte, und die Änderung pflanzt sich in alle Entitäten fort, die ihn kopieren. Jede Tabelle, die einen Personenidentifikator kopiert, wird zudem zu einer Tabelle mit Personendaten, und der zu schützende Umfang wächst entsprechend.

Der Fremdschlüssel ist das Attribut, über das eine Entität den Identifikator einer anderen trägt; er hält die Beziehung auf der logischen Ebene und sein Platz wird vom Maximum der Kardinalität diktiert: In einer Eins-zu-viele-Beziehung sitzt er auf der Seite "viele", wobei die Police die AHV-Nummer ihrer versicherten Person trägt. Eine Viele-zu-viele-Beziehung bietet keine Seite, auf die man ihn setzen könnte. Das ist das Zeichen, dass dem Modell eine Entität fehlt. Man benennt sie, gibt ihr ihren Identifikator und ihre eigenen Attribute. Die beiden Beziehungen, die von ihr ausgehen, werden wieder zu Eins-zu-viele-Beziehungen: Zwischen Police und Leistung ist die Zwischenentität die Deckung, die den Beginn der Deckung und den Selbstbehaltssatz trägt.

Die Metadaten

Das fünfte, fakultative Element beschreibt das Modell selbst: die Herkunft und den Gebrauch der Entitäten sowie die Sicherheits-, Vertraulichkeits- und Auditvorgaben, die auf einer Entität oder auf einer ganzen Gruppe lasten. In einer Domäne, deren Entitäten Gesundheitsdaten tragen, steuert die als Metadatum geführte Vertraulichkeitsvorgabe die Zugriffsrechte und die Aufbewahrungsfristen, und sie wird beim Fachbereich genauso erhoben wie eine Kardinalität.

Die drei Ebenen

Zwei Modelle derselben Domäne können sich von Ebene zu Ebene spürbar unterscheiden, weil die drei Ebenen zu unterschiedlichen Zwecken entwickelt werden. Das ist die Unterscheidung, die Praktiker am häufigsten verwechseln, und sie entscheidet darüber, wer den Stift führt.

Das konzeptionelle Datenmodell ist unabhängig von jeder Lösung und von jeder Technologie. Es bildet ab, wie der Fachbereich seine Information wahrnimmt, und es dient dazu, ein kohärentes Vokabular für ihre Beschreibung aufzubauen. Es enthält die Entitäten der Domäne und die Beziehungen, auf die es ankommt, benannt in den Worten des Fachbereichs. Diese Entitäten zielen bereits auf eine implementierbare Struktur, und genau das trennt diese Ebene vom Begriffsmodell. Der BABOK hält fest, dass auf dieser Ebene die Notationen weitgehend ähnliche Ergebnisse liefern, so sehr, dass man sie als eine einzige Technik behandeln kann.

Das logische Datenmodell ist eine Abstraktion des vorigen, die die Regeln der Normalisierung einbezieht, um die Integrität der Daten und der Beziehungen formal zu führen. Es bleibt plattformunabhängig, und es ist mit dem Entwurf einer Lösung verbunden: Identifikatoren, Fremdschlüssel, gesetzte Kardinalitäten. Typ, Länge und Index warten auf die nächste Ebene, weil sie ein Datenbankmanagementsystem voraussetzen.

Das physische Datenmodell beschreibt die physische Organisation einer Datenbank auf einem bestimmten Datenbankmanagementsystem: Tabellen, Spalten, Typen, Längen, Indizes. Seine Anliegen sind Leistung, Nebenläufigkeit und Sicherheit, und sie lassen sich erst beantworten, wenn die Technologie gewählt ist.

Die konzeptionelle Ebene gehört dem Business Analyst: Sie setzt keine Technologie voraus und die Fachexperten können sie bestätigen oder widerlegen. Die logische Ebene wird geteilt: Der Business Analyst liest sie, befragt sie und validiert sie gegen den Bedarf, der Architekt oder der Lösungsentwerfer baut sie. Die physische Ebene gehört dem Datenbankadministrator und dem Ingenieur. Der BABOK sagt es in seinen eigenen Worten: Logische und physische Modelle enthalten Elemente, die der von ihnen getragenen Lösung eigen sind, und werden in der Regel von Stakeholdern entwickelt, die in der Implementierung bestimmter technischer Lösungen kompetent sind.

Normalisieren: die ersten drei Normalformen

Normalisieren heisst, dem Modell jene Redundanzen zu entziehen, die es der Datenbank erlauben, sich selbst zu widersprechen. Wird die Adresse der versicherten Person auf jede ihrer Policen kopiert, können zwei Policen derselben Person zwei verschiedene Adressen tragen, und nichts in der Struktur sagt, welche gilt. Der Vorgang legt jedes Attribut zu dem Identifikator, von dem es abhängt, und ein Fremdschlüssel trägt die Beziehung zwischen den daraus entstehenden Entitäten.

Die Regeln, die den Vorgang steuern, sind die Normalformen, die Edgar F. Codd formuliert hat: die erste in der Arbeit von 1970, die das relationale Modell begründet, die zweite und die dritte im Forschungsbericht von 1971, der die Normalisierung weitertreibt. Jede fügt der vorigen eine Anforderung hinzu, und die ersten drei decken ab, was ein Business Analyst am logischen Modell einer betrieblichen Anwendung zu prüfen hat.

Die erste Normalform verlangt, dass jedes Attribut einen einzigen Wert trägt und dass sich keine Attributgruppe wiederholt. Eine Entität Schadenfall, die Leistung 1, Leistung 2 und Leistung 3 trüge, verletzt sie. Dieselbe Information in einer einzigen Spalte kommagetrennter Codes verletzt sie ebenso. Das Mittel dagegen wechselt nicht: Was sich wiederholt, wird zu einer Entität, die mit der ersten verbunden ist.

Die zweite Normalform fügt hinzu, dass jedes nicht identifizierende Attribut von der Gesamtheit des Identifikators abhängt, und sie greift nur bei Entitäten mit zusammengesetztem Identifikator. Eine Entität Deckung, die über das Paar Policennummer und Leistungscode identifiziert wird und die Bezeichnung der Leistung trägt, verletzt sie: Die Bezeichnung hängt allein vom Code ab und wird auf jede Police kopiert, die diese Leistung einschliesst. Die Bezeichnung gehört zur Entität Leistung.

Die dritte Normalform fügt hinzu, dass kein nicht identifizierendes Attribut von einem anderen nicht identifizierenden Attribut abhängt. Eine Entität Police, die zugleich den Code des Versicherers und dessen Namen trägt, verletzt sie: Der Name lässt sich aus dem Code ableiten, und zwei Policen desselben Versicherers können zwei verschiedene Namen tragen, sobald einer von Hand erfasst wird. Der Name gehört zu einer Entität Versicherer, die über ihren Code identifiziert wird.

Ein Modell in dritter Normalform schreibt jeden Sachverhalt an genau einer Stelle, hält seine Beziehungen über Schlüssel und lässt jedes Attribut allein vom Identifikator seiner Entität abhängen. Die weiteren Formen, angefangen bei der Boyce-Codd-Normalform, behandeln Fälle mehrerer Schlüsselkandidaten: Eine Entität in dritter Normalform, die nur einen Schlüsselkandidaten trägt, erfüllt Boyce-Codd bereits, was in einer betrieblichen Anwendung der Normalfall ist.

Bewusst denormalisieren

Die physische Ebene nimmt die Normalisierung mitunter zurück. Ein normalisiertes Modell verteilt die Information auf viele Tabellen, und jede Lesung, die sie wieder zusammenführt, bezahlt ebenso viele Joins. Bei einer leselastigen Last, Dashboard, Data Warehouse, regulatorischer Bericht, kopiert der physische Entwurf einen Wert, um den Join zu vermeiden, und das Sternschema eines Warehouse ist die geordnete Form dieser Kopie. Der Preis wird in Konsistenz bezahlt: Jede Kopie muss aktuell gehalten werden und der Entwurf benennt den Mechanismus, der dafür sorgt, sonst findet die Datenbank den Widerspruch wieder, den die Normalisierung ihr genommen hatte.

Ein auf ein Datum eingefrorener Wert sieht wie eine Redundanz aus und wird zu Unrecht gelöscht. Der Betrag der auf einen Schadenfall angewandten Franchise, der am Schadenfall festgehalten ist, sieht aus wie eine Kopie der Franchise, die die Police trägt. Es sind zwei Sachverhalte: Die Police trägt die heute geltende Franchise, der Schadenfall trägt jene, die zu seinem Datum galt. Das Attribut am Schadenfall zu löschen macht die Historie von den aktuellen Werten abhängig, und die erste Änderung der Franchise schreibt die Vergangenheit um.

Datenmodell und Begriffsmodell

Ein Begriffsmodell (BABOK 10.11) erfasst Bedeutung und Vokabular: die Begriffe, die der Fachbereich verwendet, die Fakten, die sie verbinden, und die Definitionen, auf die sich die Organisation einigt. Ein Datenmodell erfasst die Struktur, die für Speicherung und Implementierung bestimmt ist: die Entitäten, ihre Attribute, die Schlüssel und die Kardinalitäten. Ronald G. Ross formuliert die Grenze in einer Zeile: Begriffsmodelle sind auf den Begriff zentriert, Datenmodelle auf das Ding, die Entität oder die Klasse. Er fügt hinzu, dass sich ein Datenmodell recht leicht aus einem Begriffsmodell ableiten lässt, während der umgekehrte Weg deutlich schwieriger ist, was das praktische Argument dafür ist, mit dem Vokabular zu beginnen, wenn die Begriffe der Domäne umstritten sind.

Drei benachbarte Objekte tragen fast gleiche Namen. Das Begriffsmodell ist die Technik 10.11, jene des Vokabulars. Das konzeptionelle Datenmodell ist die abstrakteste Ebene, und es bleibt ein Datenmodell: Es hat Entitäten und Beziehungen, und es zielt am Ende auf eine implementierbare Struktur. Das modèle conceptuel de données von Merise, das MCD, bezeichnet für eine Leserschaft in der Romandie genau diese Ebene, im eigenen Vokabular einer anderen Modellierungsschule. Das Begriffsmodell legt fest, was das Wort "Schadenfall" bedeutet und dass die Police einen Schadenfall deckt. Das konzeptionelle Datenmodell legt fest, dass Schadenfall eine Entität ist, die mit der Entität Police verbunden ist, und es eröffnet die Frage, wie viele Schadenfälle eine Police decken kann.

Die richtige Notation wählen

Das Diagramm eines Datenmodells heisst Entity-Relationship-Diagramm (ERD), jenes eines Klassenmodells Klassendiagramm. Der BABOK entscheidet es in einem Satz: Logische und physische ERD dienen der Implementierung einer relationalen Datenbank, ein logisches oder physisches Klassendiagramm der Unterstützung einer objektorientierten Entwicklung.

Das Kriterium, das entscheidet, ist das Artefakt, das gerade entworfen wird. Das persistente Schema wird als ERD entworfen, die Struktur des Codes wird als Klassen entworfen und eine objektorientierte Anwendung auf einer relationalen Datenbank, der Normalfall in einem Schweizer Unternehmen, bringt beide Modelle hervor: das ERD für ihre Datenbank, das Klassendiagramm für ihren Code. Die Plattform des Projekts lässt die Frage offen, das Artefakt schliesst sie.

Zwei sekundäre Kriterien schärfen die Wahl. Zuerst das Verhalten: Die Klasse trägt neben ihren Attributen auch Operationen und ist als einzige der beiden dazu in der Lage, sodass eine Domäne, in der das Verhalten so viel zählt wie die Struktur, als Klassen modelliert wird. Danach die Leserschaft am anderen Ende, wenn das Modell durch mehrere Hände geht: Der Datenbankadministrator liest ein ERD geläufig, die Entwicklerin ein Klassendiagramm und eine fachliche Leserschaft, die mit Informationssystemen vertraut ist, eine Domänenverantwortliche oder ein Controller, folgt lieber einem ERD, dessen Vokabular jenes der Entitäten und Beziehungen bleibt.

Dieselbe Beziehung in zwei Notationen

Das Entity-Relationship-Diagramm und das UML-Klassendiagramm schreiben dieselbe Information auf zwei Arten. Die Kardinalität wird meist in Krähenfussnotation (crow's foot) geschrieben, auf Everest (1976) zurückgehend und dann durch Barkers Methode und die Oracle-Workshops verbreitet; es ist die Notation, die BABOKs Abbildung verwendet, und die, die man tatsächlich am Whiteboard zeichnet.

Der Krähenfuss steckt die Zählung in ein zweiteiliges Symbol, eines für das Maximum und eines für das Minimum, während UML sie am Ende der Assoziation im Klartext als Intervall schreibt. Beide Notationen setzen die Markierung auf die Seite der Entität, die gezählt wird, sodass sich eine Beziehung in beiden gleich liest, indem man der Linie zu dieser Entität folgt.

Auf der Beziehung zwischen Versicherte Person und Police trägt das ERD auf der Seite der Police einen Kreis und danach eine Gabel und auf der Seite der versicherten Person zwei Striche; das Klassendiagramm schreibt 0..* auf der Seite der Police und 1 auf der Seite der versicherten Person. Der gezeichnete Sachverhalt ist derselbe, das Vokabular wechselt: Das ERD spricht von Entität, Beziehung und Kardinalität, das Klassendiagramm von Klasse, Assoziation und Multiplizität.

Ohne eine ausdrückliche Transformation von einem ins andere wird die Übereinstimmung der beiden Modelle von Hand geprüft: Eine auf dem ERD korrigierte Kardinalität pflanzt sich nicht ins Klassendiagramm fort.

Eine dritte Schule findet sich in französischsprachigen Organisationen. Merise schreibt dasselbe Fachgebiet als konzeptionelles Datenmodell, das MCD, und überführt es anschliessend über feste Regeln in Tabellen. Seine Kardinalität steht am entgegengesetzten Ende zu jenem, an dem Krähenfuss und UML die ihre setzen: Ein Modell, das unbemerkt von einer Schule in die andere übertragen wird, behauptet über das Fachgebiet das Gegenteil.

Der Bezug zum Datenwörterbuch

Das Datenwörterbuch (BABOK 10.12) definiert die Elemente: den eindeutigen Namen eines Attributs, seine Aliasnamen, seine zulässigen Werte, sein Format und seine Länge, seine Definition im Kontext der Lösung. Das Datenmodell liefert die Struktur: welche Entitäten es gibt, welche Attribute ihnen gehören, wie sie sich verbinden. Beide Artefakte hängen über die Attribute zusammen, und der BABOK hält fest, dass das Wörterbuch oft gemeinsam mit einem Entity-Relationship-Diagramm geführt wird, aus dem es sich ableiten lässt. Ein Modell ohne Wörterbuch zeigt Kästchen, deren zulässigen Inhalt niemand kennt, ein Wörterbuch ohne Modell liefert Felder, deren Zusammensetzung niemand kennt.

KI-Überlegungen

Ein Sprachmodell leistet bei dieser Technik zwei Dienste. Der erste ist die Ableitung eines Modellvorschlags: Es liest das Schema einer bestehenden Datenbank, Spalten, Typen, Constraints und Fremdschlüssel, oder einen Bestand an Anforderungsdokumenten und Gesprächsprotokollen, und es schlägt daraus Entitäten, Attribute und Beziehungen vor. Bei einem Altsystem ohne Dokumentation lässt sich der gewonnene Entwurf schneller korrigieren, als sich ein leeres Blatt füllen lässt. Der zweite ist die Prüfung der Normalisierung: Eine Wiederholungsgruppe, eine partielle Abhängigkeit oder eine transitive Abhängigkeit zu melden, ist geregelte Arbeit, die sich gut für die Maschine eignet. Die Grenze ist fachlicher Natur. Was eine Entität für die Organisation bedeutet und dass eine Beziehung in ihrem Geschäft tatsächlich besteht, sind Sachverhalte, die der Fachbereich hält und die das Modell abbilden muss. Eine Maschine, die ein Schema liest, folgert daraus, was die Datenbank enthält, samt den Strukturfehlern, die sie angesammelt hat; sie kann nicht bestätigen, dass eine Police wirklich nur eine versicherte Person deckt, denn die Antwort liegt darin, wie die Organisation versichert. Jeder Vorschlag der KI ist ein Entwurf, der den Fachexperten vorgelegt wird.

Aufwand

Werkzeuge

Die Werkzeuge scheiden sich daran, was sie aufbewahren, eine Zeichnung oder ein Modell. Das generische Diagrammwerkzeug liefert ein sauberes Diagramm und prüft nichts, sodass zwei Entitäten dasselbe Attribut unter zwei Namen tragen können, ohne dass etwas darauf hinweist. Für die konzeptionelle Ebene genügt es, die der Business Analyst mit dem Fachbereich führt und in der Sitzung korrigiert. Die Datenmodellierungsumgebung führt ein Repository, in dem die drei Ebenen drei Sichten desselben Modells sind: Sie erzeugt das Skript zur Erstellung der Datenbank, erschliesst das Modell aus einer bestehenden Datenbank rückwärts und vergleicht es mit dem ausgerollten Schema, was die Abweichung zwischen beiden sichtbar macht. Der Datenkatalog übernimmt bei den Metadaten: Herkunft einer Entität, Klassifikation von Personen- oder Gesundheitsdaten, Aufbewahrungsfrist. Die physische Ebene entzieht sich bisweilen allen drei Familien, dort wo die Datenbank von Migrationsskripten geführt wird, die neben dem Code versioniert sind: Die Folge der Skripte gilt und das Modell ist nur an dem Tag genau, an dem man es rückwärts erschliesst.

Quellen

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.15 Data Modelling.
• OMG, Unified Modeling Language (UML) Specification: die Spezifikation, die das Klassendiagramm und seine Multiplizitätsnotation definiert.
• Peter Chen, "The Entity-Relationship Model: Toward a Unified View of Data", ACM Transactions on Database Systems, Bd. 1, Nr. 1 (1976), S. 9-36: die Gründungsschrift des Entity-Relationship-Modells.
• Gordon C. Everest, "Basic Data Structure Models Explained with a Common Example", Proc. Fifth Texas Conference on Computing Systems (1976): der Ursprung der Kardinalitätsnotation im Krähenfuss.
• Richard Barker, CASE*Method: Entity Relationship Modelling, Addison-Wesley (1990), ISBN 978-0201416961: die Barker/Oracle-Variante des Krähenfusses und die Tradition, die die Optionalität als eigene Frage neben dem Maximum der Kardinalität benennt.
• E. F. Codd, "A Relational Model of Data for Large Shared Data Banks", Communications of the ACM, Bd. 13, Nr. 6 (1970), S. 377-387: das relationale Modell und die erste Normalform.
• E. F. Codd, "Further Normalization of the Data Base Relational Model", IBM Research Report RJ909 (1971), wiederabgedruckt in Data Base Systems, hrsg. von Randall Rustin, Prentice-Hall (1972): die zweite und die dritte Normalform.
• DAMA International, DAMA-DMBOK: Data Management Body of Knowledge: die Referenz des Datenmanagements, die dieselben drei Ebenen verwendet, konzeptionell, logisch und physisch.
• Ronald G. Ross, "What Is a Concept Model?", Business Rules Journal, Bd. 15, Nr. 10 (2014): die Referenzaussage zur Grenze zwischen Begriffsmodell und Datenmodell.