{
 "cells": [
  {
   "cell_type": "markdown",
   "metadata": {
    "tags": []
   },
   "source": [
    "# Entity-Relationship Modellierung: Eine Einführung\n",
    "\n",
    "In diesem Tutorium machen wir uns mit der Entity-Relationship (ER) Modellierung vertraut. Mittels dieser Modelle können wir Verhältnisse der realen Welt wiederspiegeln. Im dritten Tutorium wandeln wir dann dieses Modell in eine relationale Datenbank um, damit wir die zuvor im Modell dargestellten Sachverhältnisse organisiert abspeichern können."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {
    "tags": []
   },
   "source": [
    "## Einführung\n",
    "\n",
    "Das Grundgerüst des `Entity-Relationship Modell` sind `Entity-Typen` und `Relationship-Typen`."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {
    "tags": []
   },
   "source": [
    "### Entity-Typen\n",
    "\n",
    "`Entity-Typen` sind Klassen von gewissen Instanzen, z.B. Studierenden oder auch Produkten und werden durch ein Rechteck gekennzeichnet. In dem Rechteck eines `Entity-Typen` steht dann der Name dieses `Entity-Typen` und was diese Klasse ausmacht, wird dann durch Attribute gekennzeichnet. Die Attribute werden durch die Nadelnotation am `Entity-Typen` vermerkt. Konkret gibt es vier Arten von Attributen:\n",
    "\n",
    "1. Atomare Attribute: Attribute, welche mittels eines einzelnen Werts gespeichert werden können.\n",
    "2. Komplexe Attribute: Attribute, die aus mehreren Bestandteilen bestehen (Adresse(Straße, Hausnummer, PLZ, Stadt, Land)).\n",
    "3. Mengenwertige Attribute: Attribute, die aus mehreren Werten bestehen ({Noten}).\n",
    "4. Abgeleitete Attribute: Attribute, welche nicht physisch gespeichert werden müssen, da Sie aus anderen Attributen hergeleitet werden können.\n",
    "\n",
    "Darüber hinaus gibt es auch Schlüsselattribute. Ist der Stecknadelkopf ausgefüllt, so handelt es sich um das Schlüsselattribut oder eines der Schlüsselattribute, die gemeinsam den Schlüssel bilden, wobei ein Schlüssel die Instanz eindeutig identifiziert. Ist der Stecknadelkopf eines Attributs hingegen nicht ausgefüllt, so handelt es sich um ein Nicht-Schlüsselattribut.\n",
    "\n",
    "Im Folgenden haben wir ein Beispiel eines `Entity-Typen` `Studierende`, wobei die Instanzen der Studierenden eindeutig durch ihre `Matrikelnummer` identifiziert werden. Zusätzlich haben Studierende das komplexe Attribut `Name`, welches aus den atomaren Attributen `Vorname` und `Nachname` besteht. Des Weiteren besuchen Studierende potenziell viele `Vorlesungen`, weshalb dies ein mengenwertiges Attribut ist, welches zusätzlich auch komplex ist und aus einer `VLID` und einem `VlTitel` besteht. Außerdem haben `Studierende` auch noch das Attribut `Semester`, welches angibt, in welchem Semester diese sich befinden. Zuletzt haben Studierende noch die Attribute `Geburtsdatum` und `Alter`, wobei `Alter` ein hergeleitetes Attribut ist.\n",
    "\n",
    "![](../resources/01-02_modellierung/UniEinf1.png)"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {
    "tags": []
   },
   "source": [
    "### Relationship-Typen\n",
    "\n",
    "`Relationship-Typen` bilden Beziehungen ab, welche zwischen den unterschiedlichen `Entitäts-Typen` gelten. So kann ein `Studierender` z.B. eine `Vorlesung` besuchen oder eine Kundin ein Produkt kaufen. Bei allen `Relationship-Typen` muss die Kardinalität zwischen den Beteiligten `Entitäts-Typen` angegeben werden. Die Kardinalität definiert auf einem abstrakten Niveau, in welchen Verhältnissen die `Entitäts-Typen` zueinander stehen. Folgende Ausprägungen sind dabei möglich:\n",
    "\n",
    "1. `Eins-zu-Eins` (1 : 1): Für jede Instanz aus dem einen `Entitäts-Typen` gibt es maximal eine andere Instanz aus dem anderen beteiligten `Entitäts-Typen`, mit dem die Instanz in Verbindung steht. Beispiel: Eine Fakultät hat maximal einen Dekan, eine Person kann Dekan maximal einer Fakultät sein.\n",
    "2. `Eins-zu-Viele` (1 : n): Für jede Instanz aus dem einen `Entitäts-Typen` gibt es potenziell viele andere Instanzen aus dem anderen Beteiligten `Entitäts-Typen`, mit denen die Instanz in Verbindung stehen kann, aber diese stehen maximal in Verbindung zu dieser einen Instanz. Beispiel: Ein Dozent kann Modulverantwortlicher vieler Module sein, aber ein Modul kann nur einen Modulverantwortlichen haben.\n",
    "3. `Viele-zu-Viele` (n : m): Für alle Instanzen aller Beteiligten `Entitäts-Typen` kann es potenziell viele andere Instanzen in den anderen Beteiligten `Entitäts-Typen` geben, mit welchen die Instanz in Verbindung steht. Beispiel: Eine `Vorlesung` kann viele `Studierende` haben, welche diese besuchen, aber jede `Studierende` Person kann auch viele Vorlesungen besuchen.\n",
    "\n",
    "Wichtig ist hierbei zu verstehen, dass `n`, `m` oder andere Variablen lediglich das Verhältnis beschreiben und nie einen konkreten Wert annehmen, da wir über Klassen bzw. Entity-Typen sprechen. In unserem Beispiel dient es also nur dazu zu verbildlichen, dass Vorlesungen von vielen Studierenden besucht werden können und dass Studierende viele Vorlesungen besuchen können.\n",
    "\n",
    "![](../resources/01-02_modellierung/UniEinf2.png)\n",
    "\n",
    "Die Kardinalität kann nicht angeben, ob sich jede Entity eines Entitytypen an einem Relationshiptypen beteiligen muss. Dies kann über die `Totalität` definiert werden, dargestellt durch einen schwarzen Punkt. Im folgenden Beispiel fordert der Totalitätspunkt, dass jedes modul von mindestens einem:einer Professor:in verwantwortet wird:\n",
    "\n",
    "![](../resources/01-02_modellierung/UniEinf3.png)\n",
    "\n",
    "Wäre der `Totalitätspunkt` im obigen Beispiel nicht vorhanden, so könnte ein(e) `Professor(in)` Modulverantwortliche(r) von einem oder mehreren Modulen sein und ein Modul könnte einen oder keinen Verantwortlichen `Professor` oder `Professorin` haben.\n",
    "\n",
    "Des Weiteren können `Relationship-Typen`, genauso wie die `Entitäts-Typen`, auch Attribute haben. Im Gegensatz zu `Entity-Typen` müssen `Relationship-Typen` aber keine Attribute haben.\n",
    "\n",
    "Da `Relationship-Typen` Beziehungen zwischen `Entitäts-Typen` abbilden, dürfen diese nie direkt miteinander verbunden sein und auch `Entity-Typen` dürfen ebenfalls nie miteinander verbunden sein. Des Weiteren müssen `Relationship-Typen` auch nicht mit genau zwei `Entitäts-Typen` verbunden sein, wie wir es bisher gesehen haben, da Beziehungen nicht immer zwischen genau zwei Klassen stattfinden.Relationship-Typen können somit auch drei oder mehr `Entity-Typen` verbinden."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {
    "tags": []
   },
   "source": [
    "### Rekursive Relationship-Typen\n",
    "\n",
    "`Relationship-Typen`können auch einen und den gleichen `Entitäts-Typen` mit sich selbst verbinden. Dies ist z.B. hilfreich, wenn wir für Module weitere Module als Voraussetzung abbilden möchten. Diese `Relationship-Typen` werden auch konkret als `rekursive Relationship-Typen` bezeichnet.\n",
    "\n",
    "Zur Kennzeichung der Beziehung müssen bei `rekursiven Relationship-Typen` sogenannte `Rollen` angegeben werden. In unserem Beispiel stellen sie dar, dass Module Vorgänger- oder Nachfolgemodule für andere Module sein können.\n",
    "\n",
    "![](../resources/01-02_modellierung/UniEinf4.png)"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {
    "tags": []
   },
   "source": [
    "### Schwache Entity-Typen\n",
    "\n",
    "Entities von `Schwache Entity-Typen` zeichnen sich darin aus, dass sie nur in Zusammenhang eines „normalen“ Entitytypen eindeutig identifiziert werden können. Falls bspw. unsere Datenbank nur Studierende aus einer einzigen Universität abbilden können soll, genügt es, für Studierende die `MatrikelNummer` als Identifikationsmerkmal zu nutzen. Sobald jedoch Studierende mehrerer Universitäten abgebildet werden sollen, könnte eine und die gleiche Matrikelnummer mehrfach vergeben sein. In diesem Fall muss die `Studierende` als schwacher Entitytyp modelliert werden, welcher nur im kontext einer `Universität` eindeutig ist.\n",
    "\n",
    "Gekennzeichnet werden dabei `schwache Entitäts-Typen` mit einer doppelt umrahmten Box. Die Nadel seines `schwachen Schlüssels`, ist im Gegensatz zu einem normalen Schlüssel, nicht ausgefüllt, dafür aber durch eine gestrichelte Linie unterstrichen. Per doppelter Umrahmung werden webenfalls die `Relationship-Typen` gekennzeichnet, die dem schwachen Entitytypen seinen Kontext geben. Die ist nötig, da ein `Entitäts-Typ` an mehreren Beziehungen (`Relationship-Typen`) beteiligt sein kann, aber nicht alle Schlüssel dieser `Entitäts-Typen` notwendig seien müssen, um die Instanzen des `schwachen Entitäts-Typen` zu identifizieren.\n",
    "\n",
    "![](../resources/01-02_modellierung/UniEinf5.png)"
   ]
  }
 ],
 "metadata": {},
 "nbformat": 4,
 "nbformat_minor": 4
}