Navigation |
|
Allgemeines |
|
Normalformen |
|
Joins |
|
Relationenalgebra |
|
|
|
|
|
Entwurf von Datenbanken
Bei Datenbankentwurf soll ein Ausschnitt der realen Welt auf ein Datenbankschema abgebildet werden. Dafür gibt es ein systematisches Vorgehen, das nachfolgend aufgezeigt wird.
Grundsätzlich steht beim Datenbankentwurf als erstes eine Anforderungsanalyse an. Daraus entsteht dann der konzeptionelle und anschließend der logische Entwurf. Am Ende führt der physische Entwurf zum physischen Modell. So ist das Ziel beim logischen Entwurf beispielsweise das konzeptuelle Modell in das Datenmodell des ausgewählten DBMS zu transformieren, also entweder in ein relationales Datenmodell oder ein objektorientiertes Datenmodell. Dafür gibt es gewisse Techniken wie Transformationsregeln und Normalisierung. Mit letzteren versucht man Datenbank-Anomalien zu verhindern, bzw. einzuschränken.
Nachfolgend wird darauf eingegangen wie man von einem ER-Modell auf ein relationales Datenschema kommt. Dafür müssen Entity-Typen und Beziehungstypen umgewandelt werden, schließlich gibt es im relationalen Modell nur ein Konstrukt: die Relation, also die Tabelle.
Grundsätzlich wird dafür jeder Entity-Typ zu einer eigenen Tabelle mit einem eindeutigen Schlüssel, eventuellen Fremdschlüssel und weiteren Attributen als neue Spalten. Über die Schlüssel können die separaten Tabellen dann wie zu einem großen Ganzen "verbunden werden. So werden beispielsweise Weak Entity-Typen ebenfalls zu einer neuen Tabelle, müssen zu ihrem Schlüsselattribut aber zwangsläufig auch noch den Primärschlüssel des übergeordneten Entity-Typen bekommen, um so die identifizierende Eigenschaft gewährleisten zu können.
Generalisierungen
Anders sieht es hingegen bei der Übertragung von Generalisierungen aus. Hier hat man mehrere Möglichkeiten.
1. Möglichkeit: Die Oberentity, als auch die Unterentity, bekommen ein eigenes Relationenschema (Tabelle), jeweils mit dem gleichen Primärschlüssel. Hätte man also die Oberentity Fahrzeug mit dem Primärschlüssel Kennzeichen, dann hätte auch die Unterentitäten PKW und LKW bei einer Umsetzung den Schlüssel Kennzeichen in ihrem Relationenschema, allerdings als Primär + Fremdschlüssel.
2. Möglichkeit: Die zweite Möglichkeit ist nur bei einer vollständigen Spezialisierung des Oberentity-Typs möglich. Ist dies der Fall, entfällt die Oberentity als Tabelle, dafür wird jeweils die Unterentitäten als Tabelle mit dem identifizierenden Attribut der Oberentity als Primärschlüssel modelliert.
3. Möglichkeit: Bei der dritten Möglichkeit sind Nullwerte notwendig. Hier modelliert man lediglich die Oberentität als Tabelle. Diese bekommt als eine weitere Spalte aber noch ein zusätzliches Attribut zur Angabe des Untertyps. So könnte man beispielsweise die Unterentität PKW mit dem Wert "1" und LKW mit "2" kodieren, sodass wenn man als Fahrzeug ein LKW in die Tabelle aufnehmen möchte, man im entsprechenden zusätzlichen Feld eine "1" einträgt. Man braucht dann eben immer eine Logik die den Eintrag aus der Tabelle entsprechend wieder rückkodiert.
4. Möglichkeit: Auch bei der vierten Möglichkeit sind Nullwerte notwendig. Hier modelliert man ebenfalls lediglich die Oberentität als Tabelle, statt einem zusätzlichen Attribut ergänzt man dieses aber mit je einem zusätzlichen Attribut pro Unternentität. Darin wird abgespeichert o eine Entität zu einem bestimmten Untertyp gehör. Würde also das Fahrzeug ein PKW sein, würde in dem einem zusätzlichen Attribut für den PKW ein true (Wahr) stehen, während im weiteren zusätzlichen Attribut für den LKW ein false (falsch) stehen würde. Bei sehr vielen Unterentitäten bläht sich die Tabelle aber regelrecht auf, weshalb diese Alternative wenn überhaupt nur bei Spezialisierungen mit wenigen Unterentitäten genommen werden sollte.
Generell präsentiert sich Möglichkeit Nummer 1 als die beste Alternative, da sie immer verwendbar ist und keine sonstige Gründe dagegen sprechen. Tatsächlich wird diese auch im Regelfall benutzt.
Beziehungstypen
Ebenfalls aufpassen muss man bei der Übertragung von Beziehungstypen. Hier geben nämlich die Kardinalitäten an, ob neue Relationen gebildet werden müssen und wie die Fremdschlüssel verteilt werden. Hier ein Überblick:
- 1:1 Beziehungen: Bei 1:1 Beziehungen muss im Normalfall keine neue Relation gebildet werden. Darüber hinaus kann man auswählen, welche Relation den Fremdschlüssel bekommen soll
- 1:n Beziehung: Auch bei der 1:n Beziehung wird keine eigene Relation. Im Gegensatz zur 1:1 Relation wird der Fremdschlüssel (oder auch Attribute des Relationship-Typs) aber immer an die Relation des Entity-Typs mit der n beschrifteten Kante angefügt.
- n:m Beziehung: Eine n:m Beziehung wird zu einer zusätzlichen Relation. Diese enthält die (Primär-)Schlüssel der beteiligten Entity-Typen als Attribute und zusätzlich die Attribute des Relationship-Typs (falls vorhanden). Der Primärschlüssel ist also einzusammengesetzer Schlüssel als den Primärschlüsseln der beteiligten Entity-Typen.
- Rekursive Beziehungen: Die Umwandlung von rekursiven Beziehung gestaltet sich analog zu normalen 1:1, 1:n, n:m-Beziehungen.
|
|
|