Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

--- faecher:informatik:oberstufe:datenbanken:darstellungsweise:start [23.01.2024 09:02] – [UML Diagramme] Frank Schiebel
+++ faecher:informatik:oberstufe:datenbanken:darstellungsweise:start [03.04.2025 13:25] (aktuell) – Frank Schiebel
@@ Zeile 11: / 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 den 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 27: / 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 44: / 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.
-===== 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 |}}
 ===== Relationales Modell =====
@@ Zeile 96: / Zeile 92: @@
 **Kraftfahrzeug**(__FahrgestellNR__, Baujahr)\\
 **FahrzeugTyp**(__TypCode__, Modell, Hersteller, Schadstoffklasse\\
-**besitzt**(HalterID↑, FahrgestellNR↑, Anmeldedatum, Abmeldedatum, Kennzeichen)\\
+**besitzt**(__HalterID↑__, __FahrgestellNR↑__, Anmeldedatum, Abmeldedatum, Kennzeichen)\\
-**istEin**(FahrgestellNR↑,TypCode↑) \\
+**istEin**(__FahrgestellNR↑__,__TypCode↑__) \\
 ++++
@@ Zeile 113: / Zeile 109: @@
 <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 137: / Zeile 133: @@
   * 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 145: / 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>.:*}}