Datenbankentwurf - Relationale Datenbanken und SQL - page 86

An dieser Stelle könnten wir noch diskutieren, ob einige dieser Attribute nicht
eigenständige Entitätentypen beschreiben, z.B. »Lagerplatz«. Diese Frage kann
nicht allgemein entschieden werden, sondern hängt von der jeweiligen Umgebung
ab. Wenn die aufzubauende Datenbank auch eine Lagerverwaltung enthalten soll,
ist es sicher sinnvoll, »Lagerplatz« mit Attributen wie Kapazität, Lage und klimati-
schen Bedingungen als eigenständigen Entitätentyp zu definieren. Solange aber
keine Attribute für »Lagerplatz« benötigt werden, reicht es aus, »Lagerplatz« als
Attribut von »Artikel« zu verwenden.
3.2.13 Umsetzung eines ER-Modells in ein
relationales Datenmodell
Im folgenden diskutieren wir, wie aus dem ER-Diagramm ein Relationenschema
abgeleitet wird. Am einfachsten ist es natürlich, die entsprechende Funktion des
Design-Werkzeuges zu verwenden, das nicht nur das Modell grafisch darstellt
(ggf. auch über mehrere Seiten), eine Beschreibung der Entitätstypen und Bezie-
hungstypen mit den Attributen, Beschreibungen und Anmerkungen gibt, sondern
auch eine Umwandlung in ein relationales Datenmodell erzeugt (dort physikali-
sches Datenmodell genannt im Gegensatz zu dem konzeptionellen [ERM] und objekt-
orientierten [UML]).
Aus Entitäten werden Relationen
Der erste Schritt ist denkbar einfach: Für jeden Entitätentyp in dem Datenmodell
wird eine Relation gebildet. Die Attribute dieser Relation sind zum einen die Attri-
bute des Entitätentyps, ggf. kommen weitere Attribute für Fremdschlüssel hinzu.
Der Schlüssel wird aus den Schlüsselattributen des Entitätentyps gebildet.
Funktionale Beziehungen werden durch Fremdschlüssel realisiert
Funktionale Beziehungen, d. h. 1:1- oder n:1-Beziehungen, können in praktisch
jedem Datenmodell dadurch dargestellt werden, dass in irgendeiner Weise ein Ver-
weis auf die Speicherstruktur hergestellt wird, die den rechten Entitätentyp reali-
siert (Zeiger auf den Vatersatz beim Netzwerk-Datenbankmodell, Verweis über
Schlüssel in irgendeiner Form bei fast allen Datenmodellen).
Im relationalen Datenmodell wird dieser Verweis über so genannte Fremdschlüssel
realisiert (vgl. Kapitel 2.2). Bei n:1-Beziehungen nennen wir die Relation, die auf
der Seite mit der Kardinalität 1..1 oder 0..1 steht, Vater-Relation , die andere Sohn-
Relation. In die Sohn-Relation wird für jedes Schlüsselattribut der Vater-Relation
ein Attribut eingebracht, das denselben Datentyp hat.
Falls zwischen diesen beiden Relationen nur eine n:1-Beziehung existiert, können
wir in der Regel die Bezeichner der Vater-Relation übernehmen. Die Beziehung
zwischen Bestellung und Kunde kann also wie in Abbildung 3.9 aufgelöst werden.