Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- gf2:datenbanken:definition [2023/06/06 11:06] – lehmannr
+++ gf2:datenbanken:definition [2024/05/22 09:51] (aktuell) – marroc
@@ Zeile 3: / Zeile 3: @@
 Im Beispiel aus dem letzten Kapitel (Benutzer eines Sozialen Netzwerkes mit geposteten Fotos und Kommentaren) wurden einige grundlegende Konzepte für Datenbanken eingeführt. In der folgenden Liste werden sie noch einmal aufgeführt
-  * **Tabelle**: Eine Datenbank besteht aus Tabellen. Diese werden visuell als Tabellen dargestellt, die Zeilen und Spalten enthalten.
+  * **Tabelle**: Eine Datenbank besteht aus Tabellen, bei deren Visualisierung es Zeilen und Spalten gibt.
   * **Feld**: Ein Feld (auch Datenfeld) kann als eine Spalte in einer Tabelle gesehen werden. Es entspricht einem Merkmal in dieser Tabelle. Zum Beispiel entspricht das Feld "comment_body" in der Tabelle "Kommentare" einem Kommentar, den ein Benutzer zu einem Foto hinterlassen hat.
   * **Datensatz**: Ein Datensatz wird durch eine Zeile in einer Tabelle repräsentiert. Beispielsweise enthält die Tabelle "Benutzer" 12 Datensätze, die jeweils die Informationen eines Benutzers des sozialen Netzwerks enthalten.
@@ Zeile 38: / Zeile 38: @@
   * **Einfache Assoziation:** jeder Entität wird wieder "genau eine" Entität zugeordnet, gewissermassen eine **1:1 Beziehung**. \\ Beispiel 1:Ein Land hat genau eine Hauptstadt. Eine Hauptstadt kann genau einem Land zugeordent werden. \\ Beispiel 2: Jeder Schüler hat einen Wiki-Login-Name. Ein Wiki-Login-Name kann einem Schüler zugeornet werden.
   * **Konditionelle Assoziation**: jeder Entität wird höchstens eine Entität zugeordnet, eine keins-oder-eins Beziehung. \\ Beispiel 1: Ein (schweizer) Staatsangehöriger hat genau einen oder keinen (schweizer) Reisepass. Jeder Reisepass gehört einem Staatsangehörigen \\ Beispiel 2: Jedes Englischbuch im Klassenzimmer gehört einem Lernenden bzw. einer Lernenden. Nicht unbedingt jeder Lernende muss sein Englischbuch im Klassenzimmer dabei haben.
-  * **Mehrfache Assoziation**: jeder Entität werden "mehrere" Entitäten zugeordnet. Diese Beziehung ist eine mehr-zu-mehr-Beziehung und wird oft als komplex bezeichnet. Oft spricht man hier auch von einer m:n Beziehung. \\ Beispiel 1 einer n:m Beziehung: Im Sozalen Netzwerk können mehrer User mehrere Bilder kommentieren. \\ Beispiel 2 einer 1:n Bezieung: Ein bestimmtes Kunstwerk (Bild) kann nur in einem Museum gleichzeitig ausgestellt werden, jedoch hat ein Museum mehrere Kunstwerke ausgestellt.
+  * **Mehrfache Assoziation**: jeder Entität werden "mehrere" Entitäten zugeordnet. Diese Beziehung ist eine mehr-zu-mehr-Beziehung und wird oft als komplex bezeichnet. Oft spricht man hier auch von einer m:n Beziehung. \\ Beispiel 1 einer n:m Beziehung: Im Sozalen Netzwerk können mehrere User mehrere Bilder kommentieren. \\ Beispiel 2 einer 1:n Bezieung: Ein bestimmtes Kunstwerk (Bild) kann nur in einem Museum gleichzeitig ausgestellt werden, jedoch hat ein Museum mehrere Kunstwerke ausgestellt.
   * **Mehrfach-konditionelle Assoziation**: jeder Entität werden "keine, eine oder mehrere" Entitäten zugeordnet. Im Gegensatz zu der mehrfachen Assoziation ist hier zu nennen, dass nicht zu jeder Entität eine Beziehung zu einer Entität der Zielmenge bestehen muss.
@@ Zeile 44: / Zeile 44: @@
 Video zum Thema:
-{{ youtube>W4UkIK2BwS8 }}
+|{{ youtube>W4UkIK2BwS8 }}|{{ youtube>34_FRBo9vOU }}|
+<WRAP nicebox green>
+**Kurzer Auftrag 1:**\\
+Wie sieht das ERM Diagrammm von Instahub aus?
+- Bestimmen Sie alle Entitäten und deren Beziehungen
+- Zeichnen Sie ein Diagramm
+<accordion>
+<panel title="Lösungen">
+ {{ :gf2:datenbanken:er-instahub.png?direct&800 |}}\\
+[[https://herrschultz.info/doku.php?id=info:sek1:db-instahub|Bildquelle]]
+</panel>
+</accordion>
+</WRAP>
 ==== Attribute oder Merkmale von Entitäten oder Beziehungen====
 Nun haben wir in unserem Beispiel die Entitäten ('User' und 'Fotos') und deren Beziehungen ('Posten' und 'Kommentieren') inklusive der Assozationen im ERM-Model gezeichnet. Was noch fehlt, um danach eine Datenbankentwurf umsetzen zu können, sind die Merkmale von Entitäten oder auch jene von Beziehungen. \\
 {{ :gf2:datenbanken:erm_instahub5.png?direct&800 |}}\\
 Einfach ausgedrückt entsprechen Sie den Feldern (als Gedankenstütze man sich könnte dies hier auch als "Tabellenspalten" oder "Überschriften" vorstellen), die wir über jede Tabelle abspeichern wollen.\\
@@ Zeile 56: / Zeile 69: @@
 Für unser Beispiel vom Sozialen Netzwerk könnten folgende Attribute dem ERM zugefügt werden.
+{{ :gf2:datenbanken:ih_ergebnis.png?direct&600 |}}
+[[https://herrschultz.info/doku.php?id=info:sek1:db-instahub|Bildquelle]]
 <WRAP nicebox green>
-**Kurzer Auftrag 1:**\\
+**Kurzer Auftrag 2:**\\
 Identifizieren Sie im obigen Model die Primär- und die Fremdschlüssel und bestimmen Sie die restlichen nicht abgebildeten Attribute. Ihr Instahub oder die früheren Tabellen können helfen.
 </WRAP>
@@ Zeile 64: / Zeile 79: @@
 <WRAP nicebox green>
-** ERM - Aufgabe ** \\
+** Auftrag 3 ** \\
 Erstellen Sie ein ERM zum folgenden Szenario. Dies wird sicher am einfachsten auf Papier erstellt. Indentifizieren Sie die Primär- und Fremdschlüssel, bestimmen Sie die jeweiligen Entitätsbeziehungen und erstellen Sie ein Diagramm. Achtung, vermutlich braucht dies auch etwas Platz!
@@ Zeile 78: / Zeile 93: @@
 ==== Abbildungsregeln für die drei Beziehungstypen ====
+Eine relationale Datenbank besteht somit aus mehreren untereinander in Beziehung stehenden Tabellen. Beim Entwerfen solcher gut funktionierender Datenbanken sind Regeln zu beachten, mit denen innerhalb von Tabellen Abhängigkeiten freigelegt werden könne und so redundante Information (Anomalien) vermieden werden können.
 === Abbildungsregel für 1:1 Beziehungen - KANN-Regel ===
-Die **KANN-Regel** bedeutet, dass man bei einer einfach-zu-einfach Beziehung 2 Tabellen erstellen kann, aber nicht muss. Man kann also 2 Tabellen erstellen, wobei es keine Rolle spielt, ob man (in diesem Beispiel Land bei Hauptstadt als Fremdschlüssel definiert oder umgekehrt Hauptstadt bei Land als Fremdschlüssel definiert). \\
+Die **KANN-Regel** bedeutet, dass man bei einer einfach-zu-einfach Beziehung zwei Tabellen erstellen kann, aber nicht miss. Es spielt keine Rolle, ob man (im Beispiel Land-Hauptstadt bei der Land-Tabelle die Hauptstadt als Fremdschlüssel definiert oder umgekehrt bei der Hauptstadt-Tabelle das Land als Fremdschlüssel definiert). \\
-Alternativ ist es hier aber auch möglich, nur 1 Tabelle zu erstellen, die alle Länder und Hauptstädte enthält. In diesem Fall braucht man keinen Fremdschlüssel für diese Beziehung!\\
+Alternativ ist es hier aber auch möglich, nur 1 Tabelle zu erstellen, die alle Länder und Hauptstädte enthält. Natürlich braucht es in diesem Fall keinen Fremdschlüssel mehr, jedoch nach wie vor einen Primärschlüssel.
+----
 === Abbildungsregel - MUSS-Regel für einfach-mehrfache Beziehungen ===
@@ Zeile 88: / Zeile 106: @@
 **Beispiel einer einfach-zu-mehrfachen-Beziehung**\\
-Jeder Auftrag (zum Beispiel Bestellung) gehört zu genau 1 Kunden, während jeder Kunde mehrere Bestellungen tätigen kann (siehe Video weiter oben).
+Jeder Auftrag (zum Beispiel Bestellung-Kunden-Firma im Video) gehört zu genau 1 Kunden, während jeder Kunde mehrere Bestellungen tätigen kann.
-<WRAP nicebox green>
+----
-**Auftrag:** \\
-Zeichnen Sie kurz das ERM mit Kunde-Bestellungen und diskutieren Sie zu zweit die Beziehungen und die oben beschriebenen Regeln für dieses Beispiel.
-</WRAP>
 === Abbildungsregeln - MUSS-Regel für komplexe Beziehungen ===
-Die **MUSS-Regel für komplexe Beziehungen** bedeutet, dass man bei komplexen (mehrfach-zu-mehrfach, also n:m) Beziehungen für jede der beiden Entitäten eine Tabelle braucht und __zusätzlich__ für die Beziehung selber eine eigene / weitere / dritte Tabelle erstellen muss. In der dritten Tabelle müssen beide Fremdschlüssel (für beide Entitäten) enthalten sein. Der Primärschlüssel der dritten Tabelle wird aus den beiden Fremdschlüsseln der anderen Tabellen zusammengesetzt.
+Die **MUSS-Regel für komplexe Beziehungen** bedeutet, dass man bei komplexen (mehrfach-zu-mehrfach, also n:m) Beziehungen für jede der beiden Entitäten eine Tabelle braucht und __zusätzlich__ für die Beziehung selber eine eigene / weitere / dritte Tabelle erstellen muss. In der dritten Tabelle müssen beide Fremdschlüssel (für beide Entitäten) enthalten sein. Der Primärschlüssel der dritten Tabelle wird aus den beiden Fremdschlüsseln der anderen Tabellen zusammengesetzt. \\
+Hier kann unser Beispiel vom Anfang mit den Instahub User - Photos - Kommentaren genannt werden.
+----
 <WRAP nicebox green>
-**Auftrag:** \\
+**Auftrag 4:** \\
-Besprechen Sie kurz zu zweit diese "Muss-Regel" für unser Instahub-Beispiel und auch für die Zoo Aufgabe.
+  - Besprechen Sie kurz zu zweit diese genannten Regeln für unser Instahub-Beispiel und auch für die Zoo Aufgabe. Entwerfen Sie so die Datenbank in groben Zügen (Wie viele Tabelle, welche Attribute, ...)
+  - Füllen Sie die folgenden Begriffe in das leere ERM, dabei sollten alle möglichst viele der Ihnen bekannten Beziehungstypen genutzt werden. Ergänzen Sie das ERM durch einige wenige Attribute. Erklären Sie in groben Zügen die Struktur der Datenbank, unter Beachtung der oben formulierten Regeln.
+{{ :gf2:datenbanken:emr_diagramm_leer.png?direct&400 |}}
 </WRAP>
+[[gf2:datenbanken:sql|Weiter zu Einführung in SQL]]