Aufgabe 3 - Datenbankmodellierung und Normalisier… · Abitur NRW Informatik GK · Nachtermin 2021

a) Erläutern Sie die Beziehungstypen im Sachkontext, begründen Sie die Kardinalitäten und erläutern Sie, wie diese im Datenbankschema realisiert wurden.

Lösung: Erläuterung der Beziehungstypen: * Der Beziehungstyp fehlt modelliert, welche Teilnehmerin bzw. welcher Teilnehmer bei welcher Sporteinheit gefehlt hat. Zusätzlich hat der Beziehungstyp das Attribut *istEntschuldigt*. * Der Beziehungstyp angemeldet modelliert, welche Teilnehmer/-innen für welche Sportangebote angemeldet sind. * Der Beziehungstyp gehoertZu modelliert, welches Sportangebot aus welchen Sporteinheiten besteht. Begründung der Kardinalitäten: * Eine Person kann für mehrere Sportangebote ($m$) angemeldet sein. Für ein Sportangebot können mehrere Personen ($n$) angemeldet sein. * Eine Sporteinheit gehört zu einem Sportangebot ($1$). Ein Sportangebot besteht aus mehreren Sporteinheiten ($n$). * Eine Person kann bei mehreren Sporteinheiten ($m$) fehlen. Bei einer Sporteinheit können mehrere Personen ($n$) fehlen. Umsetzung im Datenbankschema: * Der $n:m$-Beziehungstyp angemeldet wurde mit dem Relationenschema `angemeldet` umgesetzt. In dieser Relation werden die zwei Fremdschlüsselattribute `TeilnehmerID` und `SportangebotID` verwaltet, welche jeweils die Primärschlüssel einmal in der Relation `Teilnehmer` und einmal in der Relation `Sportangebot` darstellen. * Der $1:n$-Beziehungstyp gehoertZu wurde so umgesetzt, dass in der Relation `Sporteinheit` zusätzlich das Fremdschlüsselattribut `↑SportangebotID` verwaltet wird, welches den Primärschlüssel aus der Relation `Sportangebot` abbildet.

d) Begründen Sie anhand von zwei Argumenten, weshalb das gegebene Datenbankschema die dritte Normalform nicht erfüllt.

Lösung: 1. Verstoß gegen die 1. Normalform: Ein Datenbankschema ist in der 1. Normalform, wenn für jedes Relationenschema gilt, dass alle Attribute atomar sind. Das ist hier nicht der Fall: Das Attribut `Trainername` im Relationenschema `Sportangebot` ist nicht atomar, weil es sowohl den Vor- als auch den Nachnamen enthält. 2. Verstoß gegen die 3. Normalform: Ein Datenbankschema ist in der 3. Normalform, wenn es in der 2. Normalform ist und es zusätzlich kein Nichtschlüsselattribut gibt, das transitiv von einem Schlüsselattribut abhängig ist. Es darf also keine funktionalen Abhängigkeiten von Attributen geben, die selbst nicht zum Schlüssel gehören. Das Relationenschema `Sporteinheit` verstößt gegen die dritte Normalform, weil das Attribut `Dauer` vom Fremdschlüsselattribut `SportangebotID` abhängt (da laut Hinweis die Dauer für alle Sporteinheiten desselben Sportangebots gleich ist). Dieser Verstoß wird gelöst, indem das Attribut `Dauer` in den Entitätstyp bzw. die Relation `Sportangebot` verschoben wird.

d) Wandeln Sie das gegebene Datenbankschema in ein neues Schema um, das die dritte Normalform erfüllt.

Lösung: Teilnehmer(<u>ID</u>, Vorname, Nachname) Sportangebot(<u>ID</u>, Sportart, ↑TrainerID, Dauer) Trainer(<u>ID</u>, Vorname, Nachname) Sporteinheit(<u>ID</u>, Datum, Thema, ↑SportangebotID) angemeldet(<u>↑TeilnehmerID</u>, <u>↑SportangebotID</u>) fehlt(<u>↑TeilnehmerID</u>, <u>↑SporteinheitID</u>, istEntschuldigt)

e) Modellieren Sie eine Erweiterung des Entity-Relationship-Diagramms aus Abbildung 1.

Lösung: Beschreibung der Modellierung: * Die Relation/Beziehung angemeldet erhält die Attribute `Eigenanteil` und `Bezahldatum`. * Neuer Entitätstyp Raum mit dem Primärschlüsselattribut `Bezeichnung` (unterstrichen) und dem Attribut `Größe`. * Beziehungstyp findetStatt zwischen `Raum` und `Sportangebot` mit einer $1:n$-Kardinalität (1 bei `Raum`, $n$ bei `Sportangebot`).

e) Erläutern Sie, auf welche Weise Ihr entwickeltes Modell die Anforderungen realisiert, und begründen Sie die von Ihnen gewählten Kardinalitäten.

Lösung: Umsetzung der Anforderung i: Die Höhe des Eigenanteils für eine Person für einen Kurs wird in dem Attribut `Eigenanteil` der Beziehungsrelation `angemeldet` gespeichert. Die Information, ob bzw. wann eine Person das Sportangebot bezahlt hat, wird in dem Attribut `Bezahldatum` der Beziehungsrelation `angemeldet` gespeichert. Wenn eine Person noch nicht bezahlt hat, dann wird als Wert `null` eingetragen. Der $n:m$-Beziehungstyp bleibt bestehen, weil für jede Person und jedes gewählte Sportangebot verwaltet werden soll, ob dieses bereits bezahlt wurde und wie hoch der Eigenanteil ist. Umsetzung der Anforderung ii: Alle Räume werden im Entitätstyp `Raum` mit dem Primärschlüssel `Bezeichnung` und dem Attribut `Größe` verwaltet. Der $1:n$-Beziehungstyp wurde gewählt, weil verwaltet werden muss, welches Sportangebot in welchem Raum stattfindet und in welchen Räumen welche Sportangebote stattfinden (ein Angebot findet immer im selben Raum statt [1], in einem Raum können mehrere Angebote stattfinden [$n$]).