Free Press

Das Entity-Relationship-Datenmodell (ER) existiert seit über 35 Jahren. Es eignet sich gut für die Datenmodellierung zur Verwendung mit Datenbanken, da es relativ abstrakt ist und leicht zu diskutieren und zu erklären ist. ER-Modelle lassen sich leicht in Relationen übersetzen. ER-Modelle, auch ER-Schema genannt, werden durch ER-Diagramme dargestellt.

Die ER-Modellierung basiert auf zwei Konzepten:

• Entitäten, definiert als Tabellen, die bestimmte Informationen (Daten) enthalten)
• Beziehungen, definiert als die Assoziationen oder Interaktionen zwischen Entitäten

Hier ist ein Beispiel dafür, wie diese beiden Konzepte in einem ER-Datenmodell kombiniert werden können: Prof. Ba (Entität) lehrt (Beziehung) den Kurs Datenbanksysteme (Entität).

Für den Rest dieses Kapitels werden wir eine Beispieldatenbank namens COMPANY-Datenbank verwenden, um die Konzepte des ER-Modells zu veranschaulichen. Diese Datenbank enthält Informationen über Mitarbeiter, Abteilungen und Projekte. Wichtige Punkte, die zu beachten sind, sind:

• Es gibt mehrere Abteilungen im Unternehmen. Jede Abteilung hat eine eindeutige Kennung, einen Namen, den Standort des Büros und einen bestimmten Mitarbeiter, der die Abteilung leitet.
• Eine Abteilung steuert eine Reihe von Projekten, von denen jedes einen eindeutigen Namen, eine eindeutige Nummer und ein Budget hat.
• Jeder Mitarbeiter hat einen Namen, eine Kennnummer, eine Adresse, ein Gehalt und ein Geburtsdatum. Ein Mitarbeiter ist einer Abteilung zugewiesen, kann aber an mehreren Projekten mitarbeiten. Wir müssen das Startdatum des Mitarbeiters in jedem Projekt erfassen. Wir müssen auch den direkten Vorgesetzten jedes Mitarbeiters kennen.
• Wir wollen die Angehörigen jedes Mitarbeiters erfassen. Jeder Angehörige hat einen Namen, ein Geburtsdatum und eine Beziehung zum Mitarbeiter.

Entität, Entitätsmenge und Entitätstyp

Eine Entität ist ein Objekt in der realen Welt mit einer unabhängigen Existenz, das von anderen Objekten unterschieden werden kann. Eine Entität kann sein

Entitäten können nach ihrer Stärke klassifiziert werden. Eine Entität gilt als schwach, wenn ihre Tabellen existenzabhängig sind.

• Das heißt, sie kann nicht ohne eine Beziehung zu einer anderen Entität existieren
• Ihr Primärschlüssel ist vom Primärschlüssel der übergeordneten Entität abgeleitet
  • Die Tabelle Ehepartner in der Datenbank COMPANY ist eine schwache Entität, weil ihr Primärschlüssel von der Tabelle Mitarbeiter abhängig ist. Ohne einen entsprechenden Mitarbeiter-Datensatz würde der Ehepartner-Datensatz nicht existieren.

Eine Entität gilt als stark, wenn sie unabhängig von allen ihren verwandten Entitäten existieren kann.

• Kerne sind starke Entitäten.
• Eine Tabelle ohne Fremdschlüssel oder eine Tabelle, die einen Fremdschlüssel enthält, der Nullen enthalten kann, ist eine starke Entität

Ein weiterer Begriff, den man kennen sollte, ist Entitätstyp, der eine Sammlung ähnlicher Entitäten definiert.

Ein Entitätssatz ist eine Sammlung von Entitäten eines Entitätstyps zu einem bestimmten Zeitpunkt. In einem Entitätsbeziehungsdiagramm (ERD) wird ein Entitätstyp durch einen Namen in einem Kästchen dargestellt. In Abbildung 8.1 lautet der Entitätstyp zum Beispiel EMPLOYEE.

Existenzabhängigkeit

Die Existenz einer Entität ist abhängig von der Existenz der verbundenen Entität. Sie ist existenzabhängig, wenn sie einen obligatorischen Fremdschlüssel hat (d.h. ein Fremdschlüsselattribut, das nicht null sein kann). In der Datenbank COMPANY ist zum Beispiel die Entität Ehepartner von der Entität Mitarbeiter abhängig.

Arten von Entitäten

Sie sollten auch mit den verschiedenen Arten von Entitäten vertraut sein, einschließlich unabhängiger Entitäten, abhängiger Entitäten und charakteristischer Entitäten. Diese werden im Folgenden beschrieben.

Unabhängige Entitäten

Unabhängige Entitäten, die auch als Kernel bezeichnet werden, sind das Rückgrat der Datenbank. Auf ihnen basieren die anderen Tabellen. Kerne haben die folgenden Eigenschaften:

• Sie sind die Bausteine einer Datenbank.
• Der Primärschlüssel kann einfach oder zusammengesetzt sein.
• Der Primärschlüssel ist kein Fremdschlüssel.
• Sie sind in ihrer Existenz nicht von einer anderen Entität abhängig.

Wenn wir uns auf unsere Datenbank COMPANY beziehen, sind Beispiele für eine unabhängige Entität die Kundentabelle, die Mitarbeitertabelle oder die Produkttabelle.

Abhängige Entitäten

Abhängige Entitäten, die auch als abgeleitete Entitäten bezeichnet werden, sind in ihrer Bedeutung von anderen Tabellen abhängig. Diese Entitäten haben die folgenden Eigenschaften:

• Abhängige Entitäten werden verwendet, um zwei Kerne miteinander zu verbinden.
• Sie gelten als existenzabhängig von zwei oder mehr Tabellen.
• Viele-zu-viele-Beziehungen werden zu assoziativen Tabellen mit mindestens zwei Fremdschlüsseln.
• Sie können andere Attribute enthalten.
• Der Fremdschlüssel identifiziert jede assoziierte Tabelle.
• Es gibt drei Optionen für den Primärschlüssel:
  1. Verwenden Sie einen Verbund von Fremdschlüsseln assoziierter Tabellen, wenn diese eindeutig sind
  2. Verwenden Sie einen Verbund von Fremdschlüsseln und einer qualifizierenden Spalte
  3. Erstellen Sie einen neuen einfachen Primärschlüssel

Merkmalentitäten

Merkmalentitäten liefern weitere Informationen über eine andere Tabelle. Diese Entitäten haben die folgenden Merkmale:

• Sie stellen mehrwertige Attribute dar.
• Sie beschreiben andere Entitäten.
• Sie haben typischerweise eine Eins-zu-viele-Beziehung.
• Der Fremdschlüssel wird verwendet, um die charakterisierte Tabelle weiter zu identifizieren.
• Optionen für den Primärschlüssel sind wie folgt:
  1. Verwenden Sie einen Verbund aus Fremdschlüssel und einer qualifizierenden Spalte
  2. Erstellen Sie einen neuen einfachen Primärschlüssel. In der Datenbank COMPANY könnten dies sein:
     • Mitarbeiter (EID, Name, Adresse, Alter, Gehalt) – EID ist der einfache Primärschlüssel.
     • MitarbeiterTelefon (EID, Telefon) – EID ist Teil eines zusammengesetzten Primärschlüssels. Hier ist EID auch ein Fremdschlüssel.

Attribute

Jede Entität wird durch einen Satz von Attributen beschrieben (z. B. Mitarbeiter = (Name, Adresse, Geburtsdatum (Alter), Gehalt).

Jedes Attribut hat einen Namen und ist mit einer Entität und einem Bereich von zulässigen Werten verbunden. Die Informationen über die Attributdomäne werden jedoch nicht in der ERD dargestellt.

Im Entity-Relationship-Diagramm, das in Abbildung 8.2 dargestellt ist, wird jedes Attribut durch ein Oval mit einem Namen darin dargestellt.

Attributtypen

Es gibt einige Attributtypen, mit denen Sie vertraut sein müssen. Einige davon sind so zu belassen, wie sie sind, aber einige müssen angepasst werden, um die Darstellung im relationalen Modell zu erleichtern. In diesem ersten Abschnitt werden die Arten von Attributen besprochen. Später werden wir die Anpassung der Attribute an das relationale Modell erörtern.

Einfache Attribute

Einfache Attribute sind solche, die aus den atomaren Wertbereichen stammen; sie werden auch einwertige Attribute genannt. In der Datenbank COMPANY würde ein Beispiel hierfür lauten: Name = {John} ; Alter = {23}

Zusammengesetzte Attribute

Zusammengesetzte Attribute sind solche, die aus einer Hierarchie von Attributen bestehen. In unserem Datenbankbeispiel, das in Abbildung 8.3 dargestellt ist, kann die Adresse aus Nummer, Straße und Vorort bestehen. Dies würde also geschrieben werden als → Adresse = {59 + ‚Meek Street‘ + ‚Kingsford‘}

Mehrwertige Attribute

Mehrwertige Attribute sind Attribute, die eine Reihe von Werten für jede Entität haben. Ein Beispiel für ein mehrwertiges Attribut aus der Datenbank COMPANY, wie in Abbildung 8.4 zu sehen, sind die Abschlüsse eines Mitarbeiters: BSc, MIT, PhD.

Abgeleitete Attribute

Abgeleitete Attribute sind Attribute, die aus anderen Attributen berechnete Werte enthalten. Ein Beispiel dafür ist in Abbildung 8.5 zu sehen. Das Alter kann aus dem Attribut Geburtsdatum abgeleitet werden. In diesem Fall wird das Geburtsdatum als gespeichertes Attribut bezeichnet, das physisch in der Datenbank gespeichert ist.

Schlüssel

Eine wichtige Einschränkung für eine Entität ist der Schlüssel. Der Schlüssel ist ein Attribut oder eine Gruppe von Attributen, deren Werte zur eindeutigen Identifizierung einer einzelnen Entität in einer Entitätsmenge verwendet werden können.

Schlüsseltypen

Es gibt verschiedene Arten von Schlüsseln. Diese werden im Folgenden beschrieben.

Kandidatenschlüssel

Ein Kandidatenschlüssel ist ein einfacher oder zusammengesetzter Schlüssel, der eindeutig und minimal ist. Er ist eindeutig, weil keine zwei Zeilen in einer Tabelle zu irgendeinem Zeitpunkt denselben Wert haben können. Er ist minimal, weil jede Spalte notwendig ist, um die Eindeutigkeit zu erreichen.

Aus dem Beispiel unserer Datenbank COMPANY, wenn die Entität Employee(EID, Vorname, Nachname, SIN, Adresse, Telefon, Geburtsdatum, Gehalt, DepartmentID) ist, sind mögliche Kandidatenschlüssel:

• EID, SIN
• Vorname und Nachname – unter der Annahme, dass es in der Firma niemanden mit demselben Namen gibt
• Nachname und AbteilungsID – unter der Annahme, dass zwei Personen mit demselben Nachnamen nicht in derselben Abteilung arbeiten

Zusammengesetzter Schlüssel

Ein zusammengesetzter Schlüssel setzt sich aus zwei oder mehr Attributen zusammen, er muss jedoch minimal sein.

Anhand des Beispiels aus dem Abschnitt „Kandidatenschlüssel“ sind folgende zusammengesetzte Schlüssel möglich:

• Vorname und Nachname – unter der Annahme, dass es im Unternehmen niemanden mit demselben Namen gibt
• Nachname und Abteilungs-ID – unter der Annahme, dass zwei Personen mit demselben Nachnamen nicht in derselben Abteilung arbeiten

Primärschlüssel

Der Primärschlüssel ist ein Kandidatenschlüssel, der vom Datenbankdesigner ausgewählt wird, um als Identifizierungsmechanismus für die gesamte Entitätsmenge verwendet zu werden. Er muss Tupel in einer Tabelle eindeutig identifizieren und darf nicht null sein. Der Primärschlüssel wird im ER-Modell durch Unterstreichen des Attributs angezeigt.

• Ein Kandidatenschlüssel wird vom Designer ausgewählt, um Tupel in einer Tabelle eindeutig zu identifizieren. Er darf nicht Null sein.
• Ein Schlüssel wird vom Datenbankdesigner ausgewählt, um als Identifizierungsmechanismus für die gesamte Entitätsmenge verwendet zu werden. Dieser wird als Primärschlüssel bezeichnet. Dieser Schlüssel wird durch Unterstreichen des Attributs im ER-Modell angezeigt.

Im folgenden Beispiel ist EID der Primärschlüssel:

Mitarbeiter(EID, Vorname, Nachname, SIN, Adresse, Telefon, Geburtsdatum, Gehalt, AbteilungsID)

Sekundärschlüssel

Ein Sekundärschlüssel ist ein Attribut, das ausschließlich für Abrufzwecke verwendet wird (kann zusammengesetzt sein), z. B.: Telefon und Nachname.

Alternativschlüssel

Alternativschlüssel sind alle Kandidatenschlüssel, die nicht als Primärschlüssel gewählt werden.

Fremdschlüssel

Ein Fremdschlüssel (FK) ist ein Attribut in einer Tabelle, das auf den Primärschlüssel in einer anderen Tabelle verweist ODER er kann null sein. Sowohl Fremd- als auch Primärschlüssel müssen vom gleichen Datentyp sein.

In dem folgenden Beispiel der Datenbank COMPANY ist DepartmentID der Fremdschlüssel:

Mitarbeiter(EID, Vorname, Nachname, SIN, Adresse, Telefon, Geburtsdatum, Gehalt, DepartmentID)

Nullen

Eine Null ist ein spezielles, vom Datentyp unabhängiges Symbol, das entweder unbekannt oder unzutreffend bedeutet. Es bedeutet nicht Null oder leer. Zu den Merkmalen der Null gehören:

• Keine Dateneingabe
• Nicht erlaubt im Primärschlüssel
• Sollte in anderen Attributen vermieden werden
• Kann
  • einen unbekannten Attributwert darstellen
  • einen bekannten, aber fehlenden, Attributwert
  • eine „nicht anwendbare“ Bedingung
• kann Probleme verursachen, wenn Funktionen wie COUNT, AVERAGE und SUM verwendet werden
• kann logische Probleme verursachen, wenn relationale Tabellen verknüpft werden

HINWEIS: Das Ergebnis einer Vergleichsoperation ist Null, wenn eines der beiden Argumente Null ist. Das Ergebnis einer arithmetischen Operation ist Null, wenn eines der beiden Argumente Null ist (mit Ausnahme von Funktionen, die Nullen ignorieren).

Beispiel für die Verwendung von Null

Nutzen Sie die Gehalts-Tabelle (Salary_tbl) in Abbildung 8.6, um ein Beispiel für die Verwendung von Null zu verfolgen.

Suchen Sie zunächst alle Mitarbeiter (emp#) im Vertrieb (unter der Spalte jobName), deren Gehalt plus Provisionen größer als 30.000 sind.

• SELECT emp# FROM Salary_tbl
• WHERE jobName = Sales AND
• (commission + salary) > 30,000 -> E10 und E12

Dieses Ergebnis schließt E13 wegen des Nullwerts in der Spalte commission nicht ein. Um sicherzustellen, dass die Zeile mit dem Nullwert enthalten ist, müssen wir uns die einzelnen Felder ansehen. Wenn man die Provision und das Gehalt für den Mitarbeiter E13 addiert, ergibt sich ein Nullwert. Die Lösung ist unten dargestellt.

Beziehungen

Beziehungen sind der Klebstoff, der die Tabellen zusammenhält. Sie werden verwendet, um verwandte Informationen zwischen Tabellen zu verbinden.

Die Stärke der Beziehung basiert darauf, wie der Primärschlüssel einer verwandten Entität definiert ist. Eine schwache oder nicht-identifizierende Beziehung besteht, wenn der Primärschlüssel der verbundenen Entität keine Primärschlüsselkomponente der übergeordneten Entität enthält. Beispiele für Unternehmensdatenbanken sind:

• Kunde(KundenID, Kundenname)
• Bestellung(AuftragsID, KundenID, Datum)

Eine starke oder identifizierende Beziehung liegt vor, wenn der Primärschlüssel der verbundenen Entität die Primärschlüsselkomponente der übergeordneten Entität enthält. Beispiele sind:

• Kurs(CrsCode, DeptCode, Beschreibung)
• Klasse(CrsCode, Abschnitt, KlasseZeit…)

Beziehungstypen

Nachfolgend werden die verschiedenen Beziehungstypen beschrieben.

Ein-zu-viele-Beziehung (1:M)

Eine Ein-zu-viele-Beziehung (1:M) sollte die Norm in jedem relationalen Datenbankentwurf sein und ist in allen relationalen Datenbankumgebungen zu finden. Ein Beispiel: Eine Abteilung hat viele Mitarbeiter. Abbildung 8.7 zeigt die Beziehung zwischen einem dieser Mitarbeiter und der Abteilung.

Eins-zu-eins-Beziehung (1:1)

Eine Eins-zu-eins-Beziehung (1:1) ist die Beziehung einer Entität zu nur einer anderen Entität und umgekehrt. Sie sollte in jedem relationalen Datenbankentwurf selten vorkommen. Sie könnte sogar darauf hinweisen, dass zwei Entitäten tatsächlich in dieselbe Tabelle gehören.

Ein Beispiel aus der Datenbank COMPANY ist, dass ein Angestellter mit einem Ehepartner verbunden ist und ein Ehepartner mit einem Angestellten.

Viele-zu-viele-Beziehungen (M:N)

Bei einer Viele-zu-viele-Beziehung sind folgende Punkte zu beachten:

• Sie kann nicht als solche im relationalen Modell implementiert werden.
• Sie kann in zwei 1:M-Beziehungen umgewandelt werden.
• Es kann durch Aufbrechen implementiert werden, um eine Reihe von 1:M-Beziehungen zu erzeugen.
• Es beinhaltet die Implementierung einer zusammengesetzten Entität.
• Erzeugt zwei oder mehr 1:M-Beziehungen.
• Die Tabelle der zusammengesetzten Entität muss mindestens die Primärschlüssel der ursprünglichen Tabellen enthalten.
• Die Verknüpfungstabelle enthält mehrere Vorkommen der Fremdschlüsselwerte.
• Zusätzliche Attribute können nach Bedarf zugewiesen werden.
• Durch die Erstellung einer zusammengesetzten Entität oder Brückenentität können Probleme vermieden werden, die bei einer M:N-Beziehung auftreten. Zum Beispiel kann ein Mitarbeiter an vielen Projekten arbeiten ODER ein Projekt kann viele Mitarbeiter haben, die daran arbeiten, abhängig von den Geschäftsregeln. Oder ein Schüler kann viele Klassen haben, und eine Klasse kann viele Schüler aufnehmen.

Abbildung 8.8 zeigt einen weiteren Aspekt der M:N-Beziehung, bei der ein Mitarbeiter unterschiedliche Anfangsdaten für verschiedene Projekte hat. Daher benötigen wir eine JOIN-Tabelle, die die EID, den Code und das Startdatum enthält.

Beispiel für die Abbildung eines binären Beziehungstyps M:N

• Für jede binäre Beziehung M:N sind zwei Beziehungen zu identifizieren.
• A und B stellen zwei Entitätstypen dar, die an R beteiligt sind.
• Erstelle eine neue Relation S, um R darzustellen.
• S muss die PKs von A und B enthalten. Diese können zusammen die PK in der Tabelle S sein ODER diese können zusammen mit einem anderen einfachen Attribut in der neuen Tabelle R die PK sein.
• Die Kombination der Primärschlüssel (A und B) ergibt den Primärschlüssel von S.

Unäre Beziehung (rekursiv)

Eine unäre Beziehung, auch rekursiv genannt, ist eine Beziehung zwischen Vorkommen desselben Entitätssatzes. In dieser Beziehung sind der Primär- und der Fremdschlüssel identisch, aber sie stellen zwei Entitäten mit unterschiedlichen Rollen dar. Siehe Abbildung 8.9 für ein Beispiel.

Für einige Entitäten in einer unären Beziehung kann eine separate Spalte erstellt werden, die auf den Primärschlüssel desselben Entitätssatzes verweist.

Ternäre Beziehungen

Eine ternäre Beziehung ist ein Beziehungstyp, der viele bis viele Beziehungen zwischen drei Tabellen umfasst.

In Abbildung 8.10 finden Sie ein Beispiel für die Abbildung eines ternären Beziehungstyps. Beachten Sie, dass n-ary bedeutet, dass mehrere Tabellen in einer Beziehung stehen. (Denken Sie daran, N = viele.)

• Erstellen Sie für jede n-äre (> 2) Beziehung eine neue Beziehung, um die Beziehung darzustellen.
• Der Primärschlüssel der neuen Beziehung ist eine Kombination aus den Primärschlüsseln der beteiligten Entitäten, die die N (viele) Seite halten.
• In den meisten Fällen einer n-ären Beziehung haben alle beteiligten Entitäten eine many-Seite.

Attribution

Dieses Kapitel des Datenbankentwurfs (einschließlich der Bilder, sofern nicht anders angegeben) ist eine abgeleitete Kopie von Data Modeling Using Entity-Relationship Model von Nguyen Kim Anh, lizenziert unter Creative Commons Attribution License 3.0 license

Das folgende Material wurde von Adrienne Watt geschrieben:

1. Nullen Abschnitt und Beispiel
2. Key Terms
3. Exercises