Methoden zur Erstellung eines Modells für eine Datenbank (Datenmodell) haben zum einen ein Theoriegebäude, das die Theorieelemente und ihren Zusammenhang festlegt, zum anderen auch eine grafische Darstellungstechnik (Notation). Beides wird hier im Folgenden ausführlich dargestellt.

2.1 Grundlage

Ganz am Anfang eines jeden Datenbankdesigns steht die Betrachtung des Anwendungsbereichs und des Zwecks, für den die Datenbank erstellt werden soll. Diese konzeptionelle Modellierung führt u.a. zur Identifikation der für die Datenbank . wichtigen Realweltphänome. Dabei werden, so der Stand der Technik, Objekte und Beziehungen unterschieden. Gleich strukturierte Objekte werden zu Objektklassen [Anmerkung] , gleich strukturierte Beziehungen zu Beziehungsklassen.

Realwelt­phänomen

In der US-amerikanischen Literatur wird für „Objekt“ der Begriff entity verwendet, was teilweise auch in der deutschsprachigen Literatur übernommen wurde.

Exkurs Entity:

Der Begriff „Entity“ wird nach seinem Gebrauch besser mit „Ding“ übersetzt, da die angelsächsischen Autoren ihn als allgemeinen Begriff für alles, was wahrgenommen wird, benutzen. Geeignet wäre auch – aus dem Modellierungsblickwinkel – Informationsträger. Denn alles, was wir für Datenbanken wahrnehmen, nehmen wir durch Informationen wahr. In der modelltechnischen Nutzung entspricht er aber am besten dem Begriff Objekt.

Hier eine Zusammenstellung der Begrifflichkeit.

Attributbasierte Methoden

Da die ER-Modellierung zu den attributbasierten Modellierungsmethoden gehört, werden die Realweltphänomene mit Hilfe der gefundenen Attribute zu Entitäten und Beziehungen, bzw. zu Entitäts- und Beziehungstypen. Diese werden durch deskriptive Attribute weiter beschrieben. Mehr zu Attributen unten und in [Staud 2021, Abschnitt 2.4].

Zur Entität wird ein Realweltphänomen, wenn es mit Hilfe eines Attributs (oder mehrerer) identifiziert („Kundennummer“) und mit Hilfe weiterer beschrieben werden kann.

Entitätsfindung

Dies ist eine wichtige Grundlage des Modellierungsprozesses und sollte daher immer bedacht werden.

Entitäten müssen also Attribute haben. In diesem Text werden lediglich aus didaktischen Gründen zu Beginn Entitätstypen ohne Attribute angeführt. Die Minimalausstattung ist ein identifizierendes (Schlüssel) und ein deskriptives Attribut.

Beziehungen bestehen hier zwischen Entitätstypen dergestalt, dass für sie Entitäten der beteiligten Entitätstypen (zwei oder mehr) in eine inhaltliche (letztendlich attributbasierte) Verbindung gebracht werden. Die Konkretisierung der Beziehungen durch Attribute und Attributverknüpfungen (wie in der relationalen Modellierung; vgl. Kapitel 5 in [Staud 2021]) ist hier – in der semantischen Modellierung – nicht nötig. Sie wird es aber spätestens dann, wenn das ER-Modell in ein relationales oder objektorientiertes überführt wird.

Beziehungs­findung

2.2 Entitäten und Beziehungen

Die Unterscheidung von Objekten und Beziehungen geschieht hier im Gegensatz zum relationalen Modell, wo beide – Entitäts- und Beziehungstypen – durch Relationen (also ein einziges Modellelement) dargestellt werden. Das Ziel dieser Trennung war und ist es, leichter die Abhängigkeiten zwischen den Daten zu erkennen [Chen 1976, S. 12f].

Wie in den meisten Modellierungstheorien für Datenbanken gibt es hier also die Unterscheidung der einzelnen Elemente (hier Entität genannt) und der zusammengehörenden gleichartigen Elemente, die hier Entitätstyp genannt werden. „Gleichartig“ bedeutet hier, dass die Entitäten dieselben Attribute aufweisen. Denselben Schlüssel und dieselben sonstigen Attribute. Ganz gleich für Beziehungen. Es gibt die einzelnen Beziehungen und die Beziehungstypen. Beispiele folgen gleich unten.

Entität und Entitätstyp

In der grafischen Notation werden Entitätstypen durch Rechtecke dargestellt. Hier z.B. die Entitätstypen Datenbanksysteme und Händler:

Entitätstypen grafisch

Sie stellen – datenbanktechnisch – die attributtechnisch gleich aufgebauten Entitäten „Datenbanksysteme“ bzw. „Händler von Datenbanksystemen“ dar, die jeweils zu Typen zusammengefasst wurden.

Das zweite Grundelement dieses Ansatzes sind Beziehungen: Ein ER-Modell beschreibt einen Weltausschnitt als eine Menge von Entitäten/Entitätstypen, die durch Beziehungen/Beziehungstypen verknüpft sind. Für die Beziehungen gilt zu klären, welche Entitäten von welchen Entitätstypen in einer für den Anwendungsbereich bedeutsamen Beziehung stehen. Dies klingt einfacher als es ist, denn als Beziehung ist ja einiges denkbar. Die Aufgabe wird einfacher, wenn man die Attribute mit hinzunimmt, denn letztendlich sind auch hier (wie später in den relationalen Datenmodellen) die Beziehungen attributbasiert. Allerdings werden in den ER-Modellen diese (Beziehungs-)Attribute nicht ausgewiesen.

Beziehungen

Beispiele für Beziehungen, die in einem ER-Modell zur Rechnungsstellung auftauchen können, sind:

• Rechnungsköpfe – Rechnungspositionen: Ein Rechnungskopf ist i.d.R. mit mehreren Rechnungspositionen semantisch verknüpft, eine Rechnungsposition mit einem Rechnungskopf.
• Kunden – Rechnungen (über Rechnungsköpfe): ein Kunde taucht auf mindestens einer Rechnung auf, eine Rechnung bezieht sich typischerweise auf einen Kunden.
• Rechnungspositionen – Artikel: Zu einer Rechnungsposition gehört ein Artikel, ein bestimmter Artikel kann sich auf vielen Rechnungspositionen wiederfinden.

Vgl. hierzu das Modellierungsbeispiel in Abschnitt 11.1 und die übrigen Beispiele in den Kapiteln 11 und 12.

Ähnlich wie bei den Entitätstypen führt der Weg zu den Beziehungstypen über die Betrachtung der einzelnen Beziehungen: Gleich strukturierte Beziehungen werden zu Beziehungstypen zwischen Entitätstypen. Diese werden dann im ER-Modell ausgewiesen und grafisch mit den Entitätstypen verknüpft.

Beziehungs­typen

Wie oben schon aussgeführt, sind Beziehungen in Entity Relationship - Modellen letztendlich auch attributbasiert, allerdings werden die (Beziehungs-)Attribute nicht ausgewiesen. Dies geschieht später, z.B. bei der Abbildung des ER-Modells in ein relationales.

Die Beziehungstypen werden durch Rauten dargestellt. In unserem Beispiel könnte der Beziehungstyp DB_H (nach den Anfangsbuchstaben der Entitätstypen) erfasst werden, mit der festgehalten wird, welcher Händler welches Datenbanksystem zu verkaufen bereit ist:

Beziehungs­typen grafisch

DB_H: Datenbanken – Händler. Angebotsbeziehung.

Die Beziehungen sind die zwischen einzelnen Datenbanksystemen und einzelnen Händlern, z.B. Händler X bietet ORACLE an. Alle solchen Beziehungen zusammen bilden den Beziehungstyp. In unserem Beispiel könnte damit das erste kleine Datenmodell angelegt werden:

Es erfasst, wie gesagt, welcher Händler welches Datenbanksystem auf dem Markt anbietet. Halten wir fest, dass bisher nur die Entitäten und Entitätstypen als solche, ohne jegliche Identifikation und Beschreibung, erfasst worden sind. Dazu gleich mehr.

Einzelne Entitäten und Beziehungen werden in ER-Modellen in der Regel nicht ausgewiesen. Nur die jeweiligen Entitäts- bzw. Beziehungstypen.

2.3 Beziehungen präzisieren

Wie in den meisten anderen Ansätzen zur Datenmodellierung werden auch hier die Beziehungen genauer festgelegt. Im ersten Schritt sollen hier 1:1-, 1:n- und n:m - Beziehungen unterschieden werden. Diese werden einfach bei den beiden beteiligten Entitätstypen vermerkt. Da es sich beim obigen Beispiel um eine n:m - Beziehung handelt, könnte diese so angegeben werden:

Die Bedeutung ist dieselbe wie in der relationalen Theorie: Ein Datenbanksystem kann, muss aber nicht, von mehreren Händlern angeboten werden, ein Händler kann, muss aber nicht, mehrere Datenbanksysteme anbieten.

Ein Beispiel für eine 1:n - Beziehung ist Angestellte/Abteilung. Ein Angestellter ist einer Abteilung zugeordnet, eine Abteilung hat in der Regel mehrere Angestellte:

Beispiele für 1:1 - Beziehungen folgen unten.

Der ER-Ansatz sieht auch Beziehungen eines Entitätstyps mit sich selber vor. Zwei Beispiele mögen dies verdeutlichen. Erstens das einer Stückliste, die z.B. wie folgt modelliert werden kann:

Rekursive Beziehungen

Der Entitätstyp Teile könnte z.B. alle Teile eines Fahrradtyps erfassen, der Beziehungstyp DB_H, welches Teil in einem andern enthalten ist (Enthaltensein).

Ein weiteres Beispiel für eine rekursive Beziehung ist ein Vorgesetztenverhältnis. Z.B. in einem Unternehmen mit dem Entitätstyps Angestellte und dem Beziehungstyp ist_V („ist vorgesetzt“).

Die Art der grafischen Anordnung der Raute (nach unten oder seitlich) hat dabei keine Bedeutung.

Die Aussagekraft dieser Modellfragmente ist noch sehr beschränkt. Sie erhöht sich erst, wenn im folgenden Abschnitt Attribute eingeführt werden.

2.4 Singuläre Entitätstypen

Es gibt eine Gruppe von Entitäten, deren Existenz im jeweiligen Datenmodell davon abhängt, dass in einem anderen Entitätstyp eine bestimmte Entität vorliegt. Das in der Literatur meistgenannte Beispiel ist ein Entitätstyp Kinder in einem Datenmodell zu den Beschäftigten eines Unternehmens, zu dem auch ein Entitätstyp der Angestellten gehört. Hier gibt es in Kinder nur dann einen Eintrag, wenn Vater oder Mutter im Betrieb beschäftigt sind. Jeder Eintrag in Kinder ist also existentiell abhängig von den Einträgen in Angestellte. Verlassen die Eltern das Unternehmen, wird der Eintrag in Kinder gelöscht.

Existenz­abhängigkeit

Ein zweites sehr typisches Beispiel sind die Auftragspositionen in einem Datenmodell Aufträge (vgl. die folgende Abbildung). Die Auftragspositionen hängen existentiell vom Auftragskopf ab. Wird ein bestimmter Auftragskopf gelöscht, müssen auch seine Auftragspositionen gelöscht werden.

Dies ist nicht die normale Situation, bei der in einer Beziehung die Entitäten der beiden Entitätstypen unabhängig voneinander existieren.

Solche „abhängigen“ Entitätstypen werden singuläre Entitätstypen und die zugehörigen Beziehungen singuläre Beziehungstypen genannt. In der grafischen Notation werden sie zusammen mit dem Beziehungstyp mit einer Doppellinie versehen:

Vgl. Abbildung 11.1-1 für die Einbettung dieses Modellfragments in ein größeres ER-Modell.

Existenzabhängigkeiten dieser Art sind wichtig, insbesondere wenn das Datenmodell zur Datenbank geworden ist und seine Alltagstauglichkeit beweisen muss. Deshalb spielen sie in einem anderen Modellierungsansatz eine prominente Rolle, der SERM (vgl. Kapitel 12).

2.5 Attribute

Wie auch in der relationalen Theorie (vgl. [Staud 2021, Kapitel 2] für eine umfassende Einführung) werden die Entitäten und Beziehungen in ER-Modellen durch Attribute beschrieben. Dabei werden hier aber verschiedene Arten von Attributen mit unterschiedlicher grafischer Notation unterschieden:

• „Normale“ deskriptive Attribute, qualitativ oder quantitativ
• Schlüsselattribute
• Mehrwertige Attribute
• Abgeleitete Attribute
• Zusammengesetzte Attribute

In der grafischen Notation werden Attribute werden Attribute durch beschriftete Ellipsen dargestellt, die mittels einer Linie mit dem zugehörigen Entitäts- bzw. Beziehungstyp verbunden sind.

Deskriptive Attributedienen „nur“ der Beschreibung der Entitäten bzw. Beziehungen. Quantitative deskriptive Attribute haben die zusätzliche Eigenschaft, dass mit ihren Ausprägungen gerechnet werden kann. Im Beispiel der Abbildung sind Alter und Gehalt quantitativ, Geschlecht ist qualitativ, Firmeneintritt ist eine Datumsangabe.

Deskriptive Attribute

Auf die Unterscheidung von rangskalierten Attributen wie bei Merkmalen in der Statistischen Messtheorie) wird in der Datenbanktheorie verzichtet.

In der folgenden Abbildung soll das Attribut Bez die Bezeichnung des Datenbanksystems, Nr eine identifizierende Nummer erfassen. Beide sollen eindeutig sein, nur dann sind sie als Schlüssel geeignet. Schlüsselattribute werden durch Unterstreichung gekennzeichnet.

Schlüssel

Für alle Kenner der relationalen Theorie: Nicht irritiert sein. In der relationalen Theorie werden Fremdschlüssel, die es hier gar nicht gibt, durch Unterstreichung gekennzeichnet. In ER-Modellen sind es die Schlüssel, die durch Unterstreichung kenntlich gemacht werden.

Meist liegt nur ein einziges Schlüsselattribut vor. Sind es zwei oder mehr, wie im obigen Beispiel, kann auch von konkurrierenden Schlüsseln gesprochen werden. Bei konkurrierenden Schlüsseln identifiziert jeder Schlüssel alle Entitäten oder Beziehungen des Typs.

Konkurrenz unter Schlüsseln

Im Gegensatz dazu sprechen wir von einem zusammengesetzten Schlüssel, wenn mehrere Attribute zusammen den Schlüssel bilden. In der folgenden Abbildung genügt u.U. nicht die Angabe der Bezeichnung einer Vorlesung (z.B. Datenbanksysteme), sondern es muss auch noch das Semester angegeben werden (Datenbanksysteme / SS20), z.B. wenn es darum geht festzuhalten, wer in welchem Semester welche Vorlesung gehalten hat.

Zusammen­gesetzter Schlüssel

Oftmals gibt es bei einem Attribut mehrere Ausprägungen in Bezug auf eine Entität. In der folgenden Abbildung z.B. mehrere (beherrschte) Programmiersprachen (ProgSpr) für einen Angestellten oder mehrere Projekte (identifiziert durch eine Projektnummer, ProjNr), in denen er oder sie mitarbeitet.

Ein solches Attribut wird mehrwertig genannt und durch eine Doppellinie gekennzeichnet.

Mehrwertige Attribute

Mehrwertige Attribute können Probleme bereiten, beim Entwerfen und beim Betreiben der später entstehenden Datenbank. Sie sollten nur eingesetzt werden, wenn das durch das Attribut identifizierte Realweltphänomen (hier: Programmiersprachen und Projekte) nicht noch weiter beschrieben werden. Z.B. die Programmiersprachen durch die Bezeichnung des verwendeten Compilers („C++“ mit Visual Studio …) oder das Projekt durch den Projektleiter. Tritt solche eine Situation auf, muss zu anderen Modellstrukturen gegriffen werden. Vgl. dazu das nächste Kapitel.

Abgeleitete Attribute sind solche, die nicht direkt erfasst, sondern aus anderen Attributen bestimmt werden. Z.B. könnte in einem Entitätstyp zu den Angestellten eines Unternehmens das Alter aus dem abgespeicherten Geburtsdatum (GebDat) und dem vom System gelieferten Tagesdatum bestimmt werden. Sie werden durch eine gestrichelte Linie kenntlich gemacht, wie unten beim Attribut Alter.

Abgeleitete Attribute

Bei zusammengesetzten Attributen handelt es sich um solche, die zum Zweck der Erfassung in andere Attribute zerlegt werden können. Nehmen wir als Beispiel eine Namensangabe. Das Attribut Name kann zerlegt werden in die Attribute Vorname und Nachname.

Zusammen­gesetzte Attribute

Dies ist beliebig ausbaubar (akademische Grade, usw.). Eine solche „Verschachtelung“ kann auch mehrstufig sein, wie das Beispiel einer Adressangabe zeigt.

Zu beachten ist, dass bei zusammengesetzten Attributen nur die unterste Ebene tatsächlich aus Attributen besteht. Die übergeordneten (hier „Name“ und „Adresse“) sind lediglich Benennungen für inhaltlich zusammengehörige Gruppen von Attributen.

2.6 Das erste ER-Modell

Natürlich werden Attribute nicht isoliert, sondern mit ihrem zugehörigen Entitäts- bzw. Beziehungstyp erfasst, wie in den obigen Abbildungen ja schon angedeutet.

Für ein Datenmodell entsteht dann eine Grafik wie in der folgenden Abbildung gezeigt. Dort werden die Datenbanksysteme durch ihre Bezeichnung (Bez) identifiziert, sowie durch die Angabe ihres Typs (Typ), der Liste ihrer Datentypen, der Liste ihrer Komponenten und ihren Listenpreis beschrieben. Die Händler werden durch den Firmennamen identifiziert (Firmenname) und durch ihre Adressangaben sowie durch ihre Verbindungsdaten beschrieben.

Markt für Datenbank­systeme

Der Beziehung wurde ebenfalls ein Attribut (Konditionen) zugewiesen. In ihm soll festgehalten werden, welche prozentualen Nachlässe der Händler bei den einzelnen Datenbanksystemen zu geben bereit ist. Da die Prozentsätze je nach Datenbanksystem verschieden sein können, kann dieses Attribut nicht beim Händler, sondern nur bei der Beziehung (Kombination Datenbanksystem/Händler) platziert werden.

Attribut auf Beziehung

Hinweise zum ER-Modell

• Bez: Bezeichnung des Datenbanksystems

• Typ: Datenbanksystemtyp, also relational, objektorientiert, NoSQL-System, usw.

• Konditionen: Verkaufskonditionen. Hängen ab vom Datenbanksystem und vom Händler. D.h., ein Datenbanksystem hat bei verschiedenen Händlern unterschiedliche Konditionen und ein Händler hat für verschiedenen Datenbanksysteme auch unterschiedliche Konditionen. Diese sind also abhängig von der Kombination Händler/Datenbanksystem und müssen deshalb beim Beziehungstyp erfasst werden.

• Die Attribute Datentypen, Komponenten, Telefon, Mail sind mehrwertig. D.h., es gibt je Entität mehrere Attributsausprägungen.

Im Vorgriff auf Abschnitt 4.1 seien hier die sog. Kardinalitäten schon mal angesprochen. N und m bedeuten: Ein Händler bietet mehrere Datenbanksysteme an, ein Datenbanksystem wird von mehreren Händlern angeboten. Näheres dazu in Abschnitt 4.1.