Datenbanken-Zusammenfassung

Entity Relationship Modell

Das ER-Modell dient der Modellierung von Umweltzusammenhängen auf einer abstrakten Ebene. Es ist unabhängig von Datenbanksystemen und -modellen, wird als sehr natürlich empfunden sowie es eine graphische Notation bietet. Hierdurch ist der Erfolg des ER-Modells zu erklären.

Entitäten und Entitätentypen
Entitäten und Entitätentypen sind mit konkreten Objekten und Klassen in Java zu vergleichen. Ein Entitätentyp ist eine abstrakte Zusammenfassung von Entitäten, die durch dieselben Eigenschaften beschrieben werden. Eine Entität belegt die vorgegebenen Eigenschaften mit konkreten Werten. Für die Modellierung interessieren nur Entitätentypen. (z.B. der Entitätentyp Person mit den Eigenschaften name, geschlecht. Ein Entität dieses Typs wäre „Peter“ und „männlich“)

Attribute
Die Eigenschaften von Entitäten in einem Entitätentyp werden durch Attribute beschrieben. Ein Attribut besteht aus einem Attribut-Bezeichner und einer Domäne für mögliche Werte von konkreten Entitäten.

Es wird unterschieden zwischen

• Einwertigen Attributen
  z.B. die Matrikelnummer, da jede Entität des Entitätstyps Student nur eine Matrikelnummer besitzt

• Mehrwertigen Attributen
  z.B. die Funktion eines Sportvereinsmitgliedes, da ein Mitglied sowohl Kassenwart als auch Jugendtrainer sein kann

sowie

• Flachen Attribute
  sind nicht weiter zerlegbar

• Zusammengesetzten Attribute
  z.B. Adresse, die in Straße, Postleitzahl und Ort zerlegt werden kann

Allgemein kann man sagen, dass eine minimale Menge von Attributen, deren Werte eine zugeordnete Entität innerhalb aller Entitäten seines Typs identifiziert, Schlüsselattributkandidaten sind. Sofern es mehrere Kandidaten gibt, wir einer als Primärschlüsselattribut ausgewählt. Schlüsselattribute können auch mehrere Attribute umfassen.

Schwache Entitäten
Schwache Entitäten können nicht autonom existieren, sie sind in ihrer Existenz von einer anderen Entität abhängig und auch nur in Kombination mit dem Schlüssel der übergeordneten Entität eindeutig identifizierbar. (z.B. die Klausuren eines Studenten)

Assoziationen
Entitäten können in Beziehungen zueinander stehen (relationships)

Beispiele:

• Der Student „Meier“ hört die Vorlesung „Mathematik 1“

• Der Mitarbeiter „Müller“ arbeitet für das Unternehmen „Telekom“

Auch Beziehungen können Eigenschaften haben, die Beziehung „arbeitet für“ könnte z.B. durch die Eigenschaft „seit Datum“ näher charakterisiert werden.

Beziehungstyp (Relationship Type)
Ein Beziehungstyp beschreibt eine Klasse von Beziehungen, die jeweils dieselben Rollen und Eigenschaften haben. Ein Beziehungstyp wird durch die Angabe der beteiligten Entitätstypen und der Attribute des Beziehungstyps festgelegt.

Kardinalitäten von zweistelligen Beziehungstypen
Die Kardinalität eines Beziehungstyps gibt an, wie viele Entitäten eines Typs mit wie vielen Entitäten eines anderen Typs in einer konkreten Beziehung stehen können oder müssen. Für die Kardinalität wird eine Mindest- und Höchstzahl angegeben.

Mindestzahl:

• 0: die Beziehung ist optional (optional)

• 1: die Beziehung ist obligatorisch (mandatory)

Höchstzahl:

• 1: eindeutige Beziehung (unique)

• n: mehrdeutige Beziehung (multiple)
• in bestimmten Modellen können auch konkrete Werte, z.B. 2 für die Höchstzahl angeben werden, z.B. die Anzahl der wiederholbaren Diplomarbeiten

Es ergeben sich somit folgende Möglichkeiten

• 0..1 (optional, unique) z.B. Ehe,
  Rollen : Mann, Frau
• 0..n (optional, multiple) z.B. Beziehung Person-Person,
  Rolle: Vater
• 1..1 (mandatory, unique) z.B. Beziehung Person-Person,
  Rolle: Kind
• 1..n (mandatory, multiple) z.B. Beziehung Buch-Autor,
  Rolle: „geschrieben von“

Generalisierung
Entitätstypen können durch Generalisierung weiter strukturiert werden. Die Generalisierung im ER-Modell ist vergleichbar mit der in Java, Eigenschaften ähnlicher Entitätstypen werden einem gemeinsamen Obertyp zugeordnet. Der jeweilige Untertyp ergänzt diese nur um seine speziellen Attribute, er spezialisiert also den Obertyp. Diese Beziehung wird „is-a“-Beziehung genannt. (z.B. Student is-a Person / Dozent is-a Person)

Aggregation
Durch die Aggregation werden einem übergeordneten Entitätstyp mehrere untergeordnete Entitätstypen zugeordnet. Diese Beziehung wird als „part-of“-Beziehung bezeichnet, da untergeordnete Enitäten Bestandteile der übergeordneten sind. (z.B. CPU part-of Computer / HDD part-of Computer)

Graphische Notation

• Entitätstypen: rechteckige Kästchen

• Schwache Entitätstypen: rechteckige Kästchen mit doppeltem Rand
• Beziehungstypen: Rauten mit Verbindungslinien zu den Entitätstypen, die in Beziehung stehen
• Attribute: Kreise mit Verbindungslinie zu den Entitätstypen oder Beziehungstypen
• Schlüsselattribute: wie Attribute, jedoch unterstrichen
• Beziehungstyp: wird an den Kanten der in Beziehung stehenden Entitätstypen notiert

Rekursive Beziehungstypen
Ein Beziehungstyp, bei dem die beteiligten Entitätstypen identisch sind, heißt rekursiv. (z.B. Person-Person)

Konsolidierung
Konsolidierung bezeichnet den Vorgang, der die Modelle, die aus verschiedenen Anwendersichten entworfen worden sind, zu einem globalem Schema zusammenfasst. Man versteht darunter das Entfernen von Redundanzen und Widersprüchen.

Widersprüche entstehen durch

• Synonyme (gleiche Sachverhalte werden unterschiedlich benannt)

• Homonyme (unterschiedliche Sachverhalte werden gleich benannt)
• Unterschiedliches Modellieren desselben Sachverhalts zum einen über Beziehungen, zum anderen über Attribute (z.B. der Autor eines Buches, modelliert als Attribut / modelliert als Beziehungstyp „geschrieben von“)

Des weiteren sollten Generalisierungen und Aggregationen benutzt werden, um das Modell übersichtlicher zu gestalten (z.B. Student und Dozent als Spezialisierungen von Person).

Verbale Beschreibung von Entitätstypen
ENTITY TYPE <Entitätstyp>
[DEPENDENT ON <Entitätstyp>]    nur für schwache Entitäten, um die Abhängigkeit von dem übergeordneten Entitätstyp zu beschreiben
DESCRIPTION <Eine stichhaltige Beschreibung der Funktion des Entitätstyps>
ATTRIBUTES
                <Attributname 1>                               <Datentyp 1>;
                <Attributname n>                               <Datentyp n>;
KEY (<Attribut, welches als Primärschlüssel dienen soll>  nicht bei schwachen Entitäten, da der Schlüssel von der übergeordneten Entität geerbt wird
END <Entitätstyp>;

Als konkretes Beispiel:
ENTITY TYPE Student
DESCRIPTION Beschreibung der relevanten Daten eines Studenten
ATTRIBUTES
                matr_nr       char(8);
                name          char(15) ;
                semester     cardinal ;
KEY (matr_nr)
END Student;

Verbale Beschreibung von Beziehungstypen
RELATIONSHIP TYPE <Beziehungstyp>
ROLES
<Rollenbezeichnung>        <zugehöriger Entitätstyp> (OPTIONAL/MANDATORY UNIQUE/MULTIPLE)
<Rollenbezeichnung>        <zugehöriger Entitätstyp> (OPTIONAL/MANDATORY UNIQUE/MULTIPLE)
END <Beziehungstyp>

Als konkretes Beispiel:
RELALTIONSHIP TYPE Bestellung-Kunde
ROLES
ist_bestellt            Bestellung            OPTIONAL MULTIPLE;
hat_bestellt          Kunde                   MANDATORY UNIQUE;
END Bestellung-Kunde;

Überführen von ER-Modellen in Relationen

Beim Überführen von ER-Modelle in Relationen müssen folgende Schritte vollzogen werden:

1. Jeder Entitätstyp wird in ein Relationenschema transformiert
2. Aus den Attributen werden Spalten
3. Mehrwertige Attribute müssen in eigene Relationen überführt werden
4. Zweistellige Beziehungen vom Typ 1:1 oder 1:n können über zusätzliche Attribute in den in Beziehung stehenden Relationenschemata realisiert werden
5. Mehrwertige Beziehungen und Beziehungen vom Typ n:m müssen als eigenes Relationenschema dargestellt werden

Transformation von Entitätstypen
Für jeden Entitätstyp wird ein eigenes Relationenschema eingeführt, wobei Name, Attribute und Primärschlüssel übernommen werden.

Transformation von Beziehungstypen
Zweistellige Beziehungen vom Typ 1:1 oder 1:n können durch Übernehmen des Primärschlüssels der eindeutig bestimmten Entität in die nicht eindeutig bestimme Entität als Fremdschlüssel dargestellt werden (z.B. Beziehung 1:n zwischen Bestellung und Bestellposition. Es wird der Primärschlüssel von Bestellung in Bestellposition als Fremdschlüssel aufgenommen, um eine Bestellposition eindeutig zuordnen zu können). Alle Attribute des Beziehungstyps selbst werden ebenfalls in das Relationenschema der nicht eindeutig bestimmten Entität übernommen. Das Problem hierbei ist, dass bei „nicht schwachen“ Entitätstypen null-Marken auftreten können.

Für alle anderen Beziehungen müssen eigene Relationenschemata gebildet werden, die die Schlüsselattribute der beteiligten Entitätstypen enthalten. Des weiteren müssen alle Attribute des Beziehungstyps selbst mit aufgenommen werden.

Transformation von is-a und part-of Beziehungen
Für diese Beziehungen werden im Relationenmodell nur Schemata für die beteiligten Entitätstypen, nicht aber für die Beziehung selbst benötigt.

Normalisierung

Die Normalisierung beschreibt gewisse Regeln, die ein Datenbankentwurf erfüllen muss, um zu einer guten Datenbankstruktur überführt werden zu können. Wichtigster Punkt ist die Vermeidung von Redundanzen. Probleme entstehen durch die Verteilung von Informationen über viele Tabellen, die aber notwendig ist, um die Konsistenz der Daten zu gewährleisten.

Daher wurden sogenannte Normalformen entwickelt, denen Relationen genügen sollen.

Funktionale Abhängigkeit
Eine funktionale Abhängigkeit zwischen Attributmengen besteht, wenn aus Kenntnis aller Attribute der Menge A durch Inspektion der Datenbank die Attributwerte der Attribute der Menge B abgeleitet werden können. (z.B weiß man, dass zwei Studenten desselben Studiengangs demselben Fachbereich angehören (Studiengang) -> (Fachbereich)). Somit bedeuten funktionale Abhängigkeiten in einer Relation redundante Speicherung von Daten und sind zu vermeiden.

Die Normalformen
Ein relationales Datenmodell wird als korrekt bezeichnet, wenn es den drei Normalformen genügt. Die Normalformen bauen aufeinander auf.

1. Normalform
Eine Relation genügt der ersten Normalform, wenn die Werte der Attribute elementar sind. Die 1NF ist eine Grundforderung für relationale Datenbanken, so können z.B. keine Arrays als Attribut gespeichert werden.

Was letztendlich als elementar angesehen wird, ist vom konkreten Modell abhängig. Besteht keinerlei Notwendigkeit, z.B. die Postleitzahl für gewisse Auswertungen getrennt zu speichern, kann durchaus die Adresse an sich als elementar angesehen werden. Auf derartige Attribute (wie die Adresse in Form von „Friedrichstr. 104 53000 Wetter“) können keine Such- und Zugriffskriterien angewandt werden.

Mehrwertige Attribute müssen in eigene Relationen überführt werden.

2. Normalform
Die zweite Normalform behandelt die funktionale Abhängigkeit A -> B, bei der B keine Schlüsselattribute enthält und A Teilmenge der Schlüsselattribute darstellt.
Eine Relation genügt der 2NF, wenn alle nicht zu den Schlüsselattributen der Relation gehörende Attribute nur vom gesamten Primärschlüssel der Relation abhängig sind, und nicht schon bereits von einem Teilschlüssel.
Demzufolge sind Relationen, die keinen zusammengesetzten Primärschlüssel besitzen immer in 2NF.

3. Normalform
Die dritte Normalform behandelt die funktionale Abhängigkeit A -> B, wobei A nicht Obermenge eines Schlüssels ist und B keine Schlüsselattribute enthält.
Also darf kein Nicht-Schlüsselattribut von einem andere Nicht-Schlüsselattribut funktional abhängig sein.

Aufgaben + Lösungen