{ "cells": [ { "cell_type": "markdown", "metadata": { "tags": [] }, "source": [ "# Relationaler Entwurf: Eine Einführung\n", "\n", "In diesem Tutorium beschäftigen wir uns damit, wie wir die in den vorherigen Wochen entwickelten (E)ER-Diagramme in Tabellen in schriftlicher Form überführen. In der darauf folgenden Woche geht es dann um Normalisierung und funktionale Abhängigkeiten.\n", "\n", "Hinweis: Aufgaben, die durch einen Asterisk (*) markiert sind, sind Bonusaufgaben. Diese Aufgaben können im Tutorium behandelt werden, dies ist jedoch von den Übungsleitern nicht geplant." ] }, { "cell_type": "markdown", "metadata": { "tags": [] }, "source": [ "## Einführung\n", "\n", "Im Folgenden wiederholen wir kurz, wie unterschiedliche Komponenten von (E)ER-Modellen in ein relationales Modell zu überführen sind." ] }, { "cell_type": "markdown", "metadata": { "tags": [] }, "source": [ "### Entity-Typen\n", "\n", "Bei Entity-Typen werden alle Attribute eins zu eins übernommen, gegebenenfalls kann der Entwurf jedoch verfeinert werden und Relationen zusammengelegt werden.\n", "\n", "Aus dem untenstehenden Entity-Typen `Student` ergibt sich die folgende Relation:\n", "\n", "Student(Matrikelnummer, Name, Semester)\n", "\n", "![](../resources/03_relationaler_entwurf/uniEinf1.svg)" ] }, { "cell_type": "markdown", "metadata": { "tags": [] }, "source": [ "### Relationship-Typen\n", "\n", "Bei der Umwandlung von Relationship-Typen gehen wir wie folgt vor: Die Schlüsselattribute aller beteiligten Entity-Typen werden der neuen Relation als attribute zugeordnet., gemeinsam bilden sie den Schlüssel der Relation. Dann ergänzen wir die Attribute des Relationship-Typen selbst. Somit ergibt sich für den Relationship-Typen `besucht` die folgende Relation:\n", "\n", "besucht(Matrikelnummer → Student, Vorlesungsnummer → Vorlesung, Semester)\n", "\n", "![](../resources/03_relationaler_entwurf/uniEinf2.svg)\n", "\n", "Insgesamt ergeben sich aus dem oben stehenden Diagramm die folgenden Relationen:\n", "\n", "- Student(Matrikelnummer, Name, Semester)\n", "- besucht(Matrikelnummer → Student, Vorlesungsnummer → Vorlesung, Semester)\n", "- Vorlesung(Vorlesungsnummer, Raumnummer)" ] }, { "cell_type": "markdown", "metadata": { "tags": [] }, "source": [ "### Generalisierung/Spezialisierung\n", "\n", "Bei der Generalisierung/Spezialisierung haben wir in der Vorlesung drei Stile kennengelernt: den ER-Stil, den objektorientierten Stil und den Null-Stil. Im Folgenden demonstrieren wir diese anhand des unten stehenden Beispiels, ehe wir diese Prinzipien in den Aufgaben des Tutoriums weiter vertiefen.\n", "\n", "![](../resources/03_relationaler_entwurf/uniEinf3.svg)" ] }, { "cell_type": "markdown", "metadata": { "tags": [] }, "source": [ "#### ER-Stil\n", "\n", "Im ER-Stil wird wie folgt abgebildet: Der generalisierende Entitytyp erhält eine Relation. Alle spezialisierenden Entitytypen bekommen ebenfalls eine eigene Relation mit ihren eigenen Attributen sowie zusätzlich den Schlüsselattributen des generalisierenden Entitytypen. Dieses Attribut oder diese Attribute dienen sowohl als Schlüssel als auch als Fremdschlüssel, also als Referenz auf die Generalisierung. In unserem Beispiel ergeben sich somit die folgenden Relationen für die Generalisierung/Spezialisierung:\n", "\n", "- Student(Matrikelnummer, Name, Semester)\n", "- Bachelorstudent(Matrikelnummer → Student, Anwesenheitspflicht)\n", "- Masterstudent(Matrikelnummer → Student, Mastervoraussetzungen)\n", "\n", "Insgesamt ergeben sich für das ganze Diagramm die folgenden Relationen:\n", "\n", "- Student(Matrikelnummer, Name, Semester)\n", "- Bachelorstudent(Matrikelnummer → Student, Anwesenheitspflicht)\n", "- Masterstudent(Matrikelnummer → Student, Mastervoraussetzungen)\n", "- besucht(Matrikelnummer → Student, Vorlesungsnummer → Vorlesung, Semester)\n", "- Vorlesung(Vorlesungsnummer, Raumnummer)" ] }, { "cell_type": "markdown", "metadata": { "tags": [] }, "source": [ "#### Objektorientierter Stil\n", "\n", "Im objektorientierten Stil wird jede Instanz genau einer Relation zugeordnet. Deshalb müssen wir für jede Klasse genau eine Relation erstellen. In unserem Fall ist die Disjunktheits-Einschränkung überlappend, weshalb wir Relation für Bachelorstudierende, Masterstudierende, aber auch für BachelorMasterstudierende erstellen müssen. Des Weiteren müssen wir auf Grund der partiellen Vollständigkeits-Einschränkung eine weitere Relation für Studierende erstellen, die in keine der vorherigen drei Relationen bzw. Klassen gehören. Beim Erstellen der Relationen ist zu beachten, dass alle Relationen die Attribute der Generalisierung erhalten, also auch die Attribute der potenziell beteiligten Spezialisierungen. In unserem Beispiel ergeben sich somit die folgenden Relationen für die Generalisierung/Spezialisierung:\n", "\n", "- Student(Matrikelnummer, Name, Semester)\n", "- Bachelorstudent(Matrikelnummer, Name, Semester, Anwesenheitspflicht)\n", "- Masterstudent(Matrikelnummer, Name, Semester, Mastervoraussetzungen)\n", "- BachelorMasterstudent(Matrikelnummer, Name, Semester, Anwesenheitspflicht, Mastervoraussetzungen)\n", "\n", "Insgesamt ergeben sich für das ganze Diagramm die folgenden Relationen:\n", "\n", "- Student(Matrikelnummer, Name, Semester)\n", "- Bachelorstudent(Matrikelnummer, Name, Semester, Anwesenheitspflicht)\n", "- Masterstudent(Matrikelnummer, Name, Semester, Mastervoraussetzungen)\n", "- BachelorMasterstudent(Matrikelnummer, Name, Semester, Anwesenheitspflicht, Mastervoraussetzungen)\n", "- besucht1(Matrikelnummer → Student, Vorlesungsnummer → Vorlesung, Semester)\n", "- besucht2(Matrikelnummer → Bachelorstudent, Vorlesungsnummer → Vorlesung, Semester)\n", "- besucht3(Matrikelnummer → Masterstudent, Vorlesungsnummer → Vorlesung, Semester)\n", "- besucht4(Matrikelnummer → BachelorMasterstudent, Vorlesungsnummer → Vorlesung, Semester)\n", "- Vorlesung(Vorlesungsnummer, Raumnummer)" ] }, { "cell_type": "markdown", "metadata": { "tags": [] }, "source": [ "#### Null-Stil\n", "\n", "Im Null-Stil wird nur eine einzige Relation erstellt, welche alle Attribute der Generalisierung als auch der Spezialisierungen beinhaltet. Darüber hinaus bekommt die Relation auch entweder ein Attribut, welches den Typ (in unserem Fall Student, Bachelorstudent, Masterstudent oder Bachelormasterstudent) kodiert oder eine Menge von booleschen Attributen, welche kodieren, ob eine Instanz zu einer der Spezialisierungen gehört. In unserem Beispiel ergibt sich somit die folgende Relation für die Generalisierung/Spezialisierung:\n", "\n", "- Student(Matrikelnummer, Name, Semester, Anwesenheitspflicht, Mastervoraussetzungen)\n", "\n", "Insgesamt ergeben sich für das ganze Diagramm die folgenden Relationen:\n", "\n", "- Student(Matrikelnummer, Name, Semester, Anwesenheitspflicht, Mastervoraussetzungen)\n", "- besucht(Matrikelnummer → Student, Vorlesungsnummer → Vorlesung, Semester)\n", "- Vorlesung(Vorlesungsnummer, Raumnummer)" ] }, { "cell_type": "markdown", "metadata": { "tags": [] }, "source": [ "### Verfeinerung des Entwurfs\n", "\n", "Wenn wir eine `1` zu `n` Kardinalität haben, so wie im untenstehenden Diagramm, so können wir die Relation für den Relationship-Typen vernachlässigen und dessen Informationen auf die `n` Seite hineinziehen. Der Schlüssel, welcher dabei vom Entity-Typen der `n` Seite gekommen wäre, kann dabei natürlich vernachlässigt werden, da dieser bereits im Entity-Typen enthalten ist; alle anderen Attribute, welche die Relationship-Typ-Relation sonst enthalten hätte, werden allerdings übernommen. In unserem Beispiel ergeben sich somit die folgenden zwei Relationen:\n", "\n", "- Student(Matrikelnummer, Name, Semester, MitarbeiterNr → Betreuer)\n", "- Betreuer(MitarbeiterNr, Gehalt)\n", "\n", "![](../resources/03_relationaler_entwurf/uniEinf4.svg)\n", "\n", "Dies ist möglich, da wir wissen, dass es zu jeder Studierendeninstanz maximal einen Betreuer geben kann, sodass wir dies in einer Relation darstellen können. Bei einer `1` zu `1` Kardinalität ist dies auch möglich und dann ist die Seite, in welche man den Relationship-Typen hineinzieht, beliebig." ] }, { "cell_type": "markdown", "metadata": { "tags": [] }, "source": [ "### Schwache Entity-Typen\n", "\n", "Bei schwachen Entity-Typen ist zu beachten, dass diese keinen Schlüssel haben, welche die Instanzen eigenständig identifizieren können und unterstützende Relationship-Typen benötigen. So werden die Schlüsselattribute der Entity-Typen, welche über unterstützende Relationship-Typen mit dem schwachen Entity-Typen verbunden sind, der Relation des schwachen Entity-Typen hinzugefügt.\n", "\n", "In unserem unten stehenden Beispiel ergeben sich somit die folgenden Relationen:\n", "- Gebäude(Gebäudekürzel Adresse)\n", "- Raum(Gebäudekürzel → Gebäude, RaumNr, Kapazität)\n", "\n", "![](../resources/03_relationaler_entwurf/uniEinf5.svg)" ] } ], "metadata": {}, "nbformat": 4, "nbformat_minor": 4 }