Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

--- faecher:informatik:oberstufe:datenbanken:darstellungsweise:start [02.02.2022 18:29] – [Relationales Modell] sbel
+++ faecher:informatik:oberstufe:datenbanken:darstellungsweise:start [03.04.2025 13:25] (aktuell) – Frank Schiebel
@@ Zeile 2: / Zeile 2: @@
 ===== ER-Diagramme =====
 Eine Möglichkeit, wie man eine Datenbank strukturiert darstellen kann, hast du bereits kennengelernt - als ER-Diagramm.
@@ Zeile 12: / Zeile 11: @@
 Eine Universität bietet Veranstaltungen an, die an einem bestimmten Wochentag in einem
 bestimmten Zeitblock in einem bestimmten Raum stattfinden. Jede Veranstaltung wird
-von genau einer Dozentin angeboten, von dem Nachname, Vorname und eine eindeutige AngestelltenId bekannt sind.
+von genau einer Dozentin angeboten, von der Nachname, Vorname und eine eindeutige AngestelltenId bekannt sind.
 Ein Inhaltsmodul umfasst alle Veranstaltungen, die in diesem Modul angeboten werden. Für jedes Inhaltsmodul gibt es
-eine eindeutige Modulnummer, eine Bezeichnung und die Zahl der CreditPoints, die die Studierenden angerechnet werden.
+eine eindeutige Modulnummer, eine Bezeichnung und die Zahl der Credit-Points, die den Studierenden angerechnet werden.
 Studierende besuchen Veranstaltungen. Studierende haben einen Namen und Vornamen und eine eindeutige Matrikelnummer.
@@ Zeile 28: / Zeile 27: @@
 Anmerkungen:
-  * Attribute, die einen Primärschlüssel darstellen werden im ER Diagramm unterstrichen, Fremdschlüssel werden in ER Diagrammen als Attribut eingetragen und auch nicht gekennzeichnet.
+  * Attribute, die einen Primärschlüssel darstellen, werden im ER Diagramm unterstrichen, Fremdschlüssel werden in ER Diagrammen **nicht** als Attribut eingetragen (und somit auch nicht gekennzeichnet).
   * Man hätte ''Wochentag'', ''Block'' und ''Raum'' auch als weitere Entitäten auffassen können.
   * Die Veranstaltungen haben keinen offensichtlichen Primärschlüssel. Hier könnte ein Surrogatschlüssel ''VeranstaltungsID'' Abhilfe schaffen.
 ++++
-Wir betrachten ein weiteres Beispiel:
+Wir betrachten ein **weiteres Beispiel**:
 {{ :faecher:informatik:oberstufe:datenbanken:darstellungsweise:kfz.drawio.png |}}
@@ Zeile 45: / Zeile 44: @@
 ----
-Da jeder Fahrzeugbesitz mit einer An- oder Abmeldung des KFZ einhergeht, macht es Sinn, die Informationen Kennzeichen, An- und Abmeldedaten der Beziehung "besitzt" zuzuschreiben. Wenn man das ER Diagramm jetzt in Datenbank-Tabellen überführen möchte, benötigt man also für die Beziehungsraute - wie auch schon für die Attribute - eine eigene Tabelle. Außerdem werden Fremdschlüssel im ER-Diagramm nicht dargestellt, es ist in dieser Hinsicht also unvollständig, obwohl es natürlich einen ausgezeichneten Überblick über die Beziehungen zwischen den Entitäten bietet.
+Da jeder Fahrzeugbesitz mit einer An- oder Abmeldung des KFZ einhergeht, macht es Sinn, die Informationen Kennzeichen, An- und Abmeldedaten der Beziehung "besitzt" zuzuschreiben. Wenn man das ER Diagramm jetzt in Datenbank-Tabellen überführen möchte, benötigt man also für diese Beziehungsraute - wie auch schon für die Entitäten - eine eigene Tabelle. Außerdem werden Fremdschlüssel im ER-Diagramm nicht dargestellt, es ist in dieser Hinsicht also unvollständig, obwohl es natürlich einen ausgezeichneten Überblick über die Beziehungen zwischen den Entitäten bietet.
 ===== Relationales Modell =====
@@ Zeile 92: / Zeile 92: @@
 **Kraftfahrzeug**(__FahrgestellNR__, Baujahr)\\
 **FahrzeugTyp**(__TypCode__, Modell, Hersteller, Schadstoffklasse\\
-**besitzt**(HalterID↑, FahrgestellNR↑, Anmeldedatum, Abmeldedatum, Kennzeichen)\\
+**besitzt**(__HalterID↑__, __FahrgestellNR↑__, Anmeldedatum, Abmeldedatum, Kennzeichen)\\
-**istEin**(FahrgestellNR↑,HalterID↑) \\
+**istEin**(__FahrgestellNR↑__,__TypCode↑__) \\
 ++++
@@ Zeile 105: / Zeile 105: @@
 ++++ Lösung |
-Wenn die 1:n Beziehung keine eigenen Attribute hat, kann man sie durch einen direkte Beziehung der beiden Tabellen modellieren und benötigt keine eigene "Besziehungstabelle".
+Wenn die 1:n Beziehung keine eigenen Attribute hat, kann man sie durch einen direkte Beziehung der beiden Tabellen modellieren und benötigt keine eigene "Beziehungstabelle".
 ++++
 <WRAP center round important 95%>
-Man benötigt **keine eigene Beziehungs-Tabelle**:
+Für folgende Beziehungen benötigt man **keine eigene Beziehungs-Tabelle**:
   * Für 1:1 Beziehungen - diese können sogar in eine Tabelle zusammengefasst werden.
-  * Für 1.n Beziehungen, wenn die Beziehung keine eigenen Attribute besitzt. Dann kann durch Primär- und Fremdschlüssel eine direkte Beziehung zwischen das Tabellen hergestellt werden.
+  * Für 1:n Beziehungen, wenn die Beziehung keine eigenen Attribute besitzt. Dann kann durch Primär- und Fremdschlüssel eine direkte Beziehung zwischen den Tabellen hergestellt werden.
 **Für n:m Beziehungen benötigt man immer eine eigene Beziehungstabelle**
@@ Zeile 128: / Zeile 128: @@
 === (A6) ===
-{{ :faecher:informatik:oberstufe:datenbanken:darstellungsweise:airplane.jpg?nolink&200|}}
+{{ :faecher:informatik:oberstufe:datenbanken:darstellungsweise:airplane.jpg?230|}}((Image by [[https://pixabay.com/users/lars_nissen-2780243/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=3702676|Lars_Nissen]]))
-Eine Fluggesellschaft speichert alle Buchungen der Passagiere. Für das Vielfliegerprogramm  "Sky-High" werden diese Daten ausgewertet. Ein Auschnitt aus der Verwendete DB soll modelliert werden, und zwar die Miniwelt mit den folgenden Entitäten und Eigenschaften:
+Eine Fluggesellschaft speichert alle Buchungen der Passagiere. Für das Vielfliegerprogramm  "Sky-High" werden diese Daten ausgewertet. Ein Auschnitt aus der verwendeten Datenbank soll modelliert werden, und zwar die Miniwelt mit den folgenden Entitäten und Eigenschaften:
   * Ein Flugzeug hat einen bestimmten Typ, z.B. "B747-A", ein Kennzeichen, das es identifiziert, z.B. "D-LH54, ein Baujahr sowie  eine Anzahl von Sitzplätzen.
-  * Flugzeuge legen Flugstrecken zurück. Jede Flugstrecke hat eine Flugnnummer, wie z.B. "LH-3186". Die Flugnummer bezeichnet den Flug der Flugstrecke mitsamt seiner Abflugzeit. Der Flug der Strecke wird somit durch die Flugnummer und der Abflugszeit eindeutig festgelegt.
+  * Flugzeuge legen Flugstrecken zurück. Jede Flugstrecke hat eine Flugnnummer, wie z.B. "LH-3186". Zu jedem Flug gehört außerdem eine bestimmte Abflugzeit. Der Flug der Strecke wird somit durch die Flugnummer und die Abflugszeit eindeutig festgelegt.
   * Flugstrecken führen von einem Startflughafen zu einem Zielflughafen, haben eine bestimmte Dauer und eine bestimmte Länge in Meilen.
   * Passagiere haben einen Namen und Vornamen. Sie buchen Flugstrecken.
@@ Zeile 141: / Zeile 141: @@
 Aufgaben
-  * Erstelle zunächst ein ER-Diagramm der Miniwelt
+  * Erstelle zunächst ein ER-Diagramm der Miniwelt. Erstelle nicht unnötig viele separate Entitäten, sondern beschränke dich auf die nötigen, um die gegebene Miniwelt sinnvoll modellieren zu können.
   * Überführe das ER-Diagramm in ein relationales Datenbankschema
   * Überlege dir, ob der "Umweg" über das ER Diagramm Vorteile bei der Modellierung bietet gegenüber dem Versuch, das relationale DB-Schema direkt niederzuschreiben? (Welche)
+===== Alternative grafische Darstellung: UML Diagramme =====
+Eine weiter Möglichkeit, Datenbankentwürfe grafisch darzustellen, ist mit Hilfe von UML Diagrammen. Die Darstellung verwendet dabei die aus der objekorientierten Programmierung üblichen Konventionen für Objekte und deren Beziehungen zueinander. Die Beispieldatenbank der KFZ Verwaltung aus dem vorigen Abschnitt in der Darstellung als UML-Diagramm folgendermaßen aussehen:
+{{ .:autos_uml.drawio.png |}}
+  * Jede Entität wird als Objekt dargestellt
+  * Die Attribute werden den Objekten in gewohnter Weise wie bei der Darstellung von Objekten bei der objektorientierten Programmierunm zugeordnet.
+  * Primärschlüssel werden unterstrichen
+  * Fremdschlüssel werden **nicht** als Attribute angegeben
+  * Wenn eine Verknüpfungstabelle nötig ist (n-m-Beziehung oder - wie bei den Autos - zusätzliche Attribute) wird diese als weiteres Objekt mit den nötigen Attributen angegeben und mit einer gestrichelten Linie der Beziehung zwischen den anderen Entitäten zugeordnet.
+Ein Vorteil der UML Darstellung ist, dass man sofort erkennen kann, wieviele Tabellen zur Implementierung nötig sind, bei den ER-Diagrammen muss man sehr genau darauf achten, ob eine Beziehungsraute eine weitere Tabelle erforderlich macht - entweder wenn weitere Attribute nötig sind, oder wenn man eine n-m-Beziehung modellieren möchte.
+----
+{{:aufgabe.png?nolink  |}}
+=== (A7) ===
+Überführe die Datenbankmodelle aus Aufgabe 5 und Aufgabe 6 in ein UML-Diagramm.
+----
+==== Material ====
+{{simplefilelist>.:*}}