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

a) Erläutern Sie die im Entity-Relationship-Diagramm in Abbildung 1 dargestellten Beziehungstypen bezogen auf den Sachkontext. Begründen Sie, weshalb diese Kardinalitäten gewählt wurden, und erläutern Sie, auf welche Weise angemeldet und gehoertZu im Datenbankschema realisiert wurden.

Lösung: 1. Erläuterung der Beziehungstypen: - Der Beziehungstyp fehlt modelliert, welche Teilnehmerin bzw. welcher Teilnehmer bei welcher Sporteinheit gefehlt hat. Zusätzlich besitzt 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. 2. 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. 3. Relationale Umsetzung: - Der n:m-Beziehungstyp angemeldet wurde mit dem Relationsschema angemeldet umgesetzt. In dieser Relation werden die zwei Fremdschlüsselattribute TeilnehmerID und SportangebotID verwaltet, welche jeweils die Primärschlüssel aus den Relationen Teilnehmer und 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 Datenbankschema in Abbildung 2 die dritte Normalform nicht erfüllt. Überführen Sie das Schema in ein neues Schema, das die 3NF erfüllt.

Lösung: Begründung der Normalformverletzungen: 1. Verstoß gegen die 1. Normalform: Ein Datenbankschema ist in der 1. Normalform, wenn alle Attribute atomar sind. Das ist hier nicht der Fall: Das Attribut Trainername im Relationsschema Sportangebot ist nicht atomar, da 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 kein Nichtschlüsselattribut transitiv von einem Schlüsselattribut abhängt. Das Relationsschema Sporteinheit verstößt gegen die 3. Normalform, weil das Attribut Dauer vom Fremdschlüsselattribut SportangebotID abhängt (da alle Einheiten desselben Angebots gleich lang sind). Dieser Verstoß wird gelöst, indem Dauer in das Relationsschema Sportangebot verschoben wird. Neues Datenbankschema in 3NF: 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 Datenbankschemas aus Abbildung 2, sodass der neue Entwurf die beschriebenen Aspekte zusätzlich abdeckt. Erläutern Sie, auf welche Weise Ihr Modell die Anforderungen erfüllt, und begründen Sie die gewählten Kardinalitäten.

Lösung: Erweitertes Datenbankschema: angemeldet(<u>↑TeilnehmerID</u>, <u>↑SportangebotID</u>, Eigenanteil, Bezahldatum) istVerantwortlich(<u>↑SportangebotID</u>, <u>↑TrainerEMailAdresse</u>) Trainer(<u>EMailAdresse</u>, Name) Umsetzung der Anforderungen und Begründung der Kardinalitäten: - Zu Anforderung i: Die Höhe des Eigenanteils für eine Person für einen Kurs wird im Attribut Eigenanteil im Relationsschema angemeldet gespeichert. Die Information, ob bzw. wann eine Person das Sportangebot bezahlt hat, wird im Attribut Bezahldatum im Relationsschema angemeldet gespeichert. Wenn eine Person noch nicht bezahlt hat, wird als Wert NULL eingetragen. Im Relationsschema angemeldet bleibt der n:m-Beziehungstyp 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. - Zu Anforderung ii: Das Attribut Trainername wird im Relationsschema Sportangebot gelöscht. Dafür wird das Relationsschema Trainer mit dem Primärschlüssel EMailAdresse und dem Attribut Name (oder Vorname, Nachname) ergänzt. Da mehrere Trainerinnen und Trainer ein Angebot betreuen können und ein Trainer mehrere Angebote leiten kann, liegt eine n:m-Beziehung vor. Das Relationsschema istVerantwortlich entspricht diesem n:m-Beziehungstyp und besteht aus dem kombinierten Primärschlüssel SportangebotID und TrainerEMailAdresse, welche jeweils Fremdschlüssel aus den entsprechenden Relationen darstellen.