Normalisierung von Datenbanken

Mein zusammen!

Ich habe ein Problem mit einer Aufgabe...
Erster Teil einer relativ umfassenden Aufgabe ist die Normalisierung der Daten bis in die 3. Normalform. Gesagt, getan.

Allerdings bin ich mir bei der 3. Normalform nicht so ganz sicher, ob das mit der Tabelle "Teilnahme" (s.u.) so richtig ist. Was mich verwundert ist, dass ich eigentlich die Kurs ID als Fremdschlüssel brauche und der Primärkey aus allen 3 Attributen besteht (lt. Aufgabenstellung kann ein Kurs an verschiedenen Tagen zu verschiedenen Uhrzeiten stattfinden).

Ich wollte einfach mal nett fragen, ob vielleicht jmd helfen kann, ob das so richtig ist? Nicht dass sich das als Folgefehler am Ende durch die gesamte Aufgabe zieht...

Das hier ist die Ausgangsform, die sich meiner Meinung nach bereits in der 1. Normalform befindet:


Nun habe ich alle Daten ausgelagert, die jew von einem Schlüssel abhängig sind, d.h. ich habe für Teilnehmer und für Kurse eigene Tabellen erstellt:


Ich hätte mir nun überlegt, dass ich nun eigentlich die Daten zum teilgenommenen Kurs auslagern müsste für die 3. NF, sieht dann so aus:


Ist der dritte Schritt tatsächlich richtig? Irgendwie kommt mir das komisch vor?! Sieht jemand den Fehler??

Ich würde auch sagen, dass da was nicht stimmt.

"Datum des belegten Kurses" ist ja offensichtlich eine Eigenschaft des Kurses => gehört auch in die selbe Tabelle, ebenso die "Startzeit".

Am besten sortierst du die Spalten mal danach, wo sie dazugehören:
Datum, Startzeit, Preis, Dauer, Bezeichnung, KursID => Kurs
TeilnehmerID, Nachname, Geburtsdatum => Teilnehmer
Kontonummer, Zahlungsart => auslagern in die Relation zwischen Teilnehmer und Kurs

Danach solltest du alle redundanten Informationen in eigenen Tabellen auslagern und mittels ID mit dem Kurs/dem Teilnehmer verknüpfen. Ohne die Daten jetzt komplett durchzusehen (ist ein wenig klein^^) würde ich sagen, dass Teilnehmer <-> Kurs eine M:N-Beziehung ist => eigene Relation - zB mit eigenen Attributen für die Zahlungsmodalität.

Wenn ich nochmal drüber nachdenke, erscheint es mir sogar sinnvoll die "Startzeit", sowie das "Datum des belegten Kurses" zusammen mit der Zahlungsart als Attribute der Relation zwischen Kurs und Teilnehmer zu nehmen. Die Kontonummer würde ich schon beim Kunden lassen, schließlich "gehört sie ja irgendwie einfach zum Kunden" und ist für jeden Vorgang gleich.

Für die Relation habe ich mir nun Folgendes überlegt:
Ich vergebe eine einmalige Buchungsnummer o.ä. (z.B. fortlaufende Nummerierung) für jeden belegten Kurs, mit den Attributen Teilnehmer ID, Kurs ID, Zahlungsart, Datum und Startzeit.
Diese Relation lässt sich ja eigentlich auch als Entität darstellen.

Damit hätte ich in der Ursprungstabelle nur noch: Teilnehmer ID, Kurs ID und Buchungsnummer.

Tabelle Kunden:
-Teilnehmer ID (Key)
-Nachname
-Geburtsdatum
-Kontonummer

Tabelle Kurs:
-Kurs ID (Key)
-Bezeichnung des Kurses
-Dauer des Kurses
-Preis

Tabelle Teilnahme:
-Buchungsnummer (Key)
-Teilnehmer ID
-Kurs ID
-Datum
-Startzeit
-Zahlungsart

Damit sind meiner Meinung nach alle Redundanzen weg.

So wie in deinem letzten Post passt es genau. Ob die Zahlungsart jetzt zum Kunden (weil ein Kunde immer gleich bezahlt) oder zum Kurs gehört (weil ein Kunde je nach Kurs anders bezahlt) muss in der Aufgabe näher spezifiziert sein, ändert aber nichts an der Normalisierung, beides richtig.

Wenn du dir über einen bestehenden Entwurf nicht sicher bist, dann kannst du, statt die Relationen mühevoll umzuformen, diese auch über den Haufen werfen und nochmal kurz von vorne mit einem ERM beginnen. Wenn du dieses korrekt in ein relationales Modell umformst (dafür gibt es feste Regeln, also kein Platz für eigene Interpretationen) , dann landest du automatisch in der 3. NF ohne auch je über die Definition der Regeln nachgedacht zu haben.

Danke euch beiden, dann kanns ja morgen in Access weitergehen

Also, ich habe heute den Dozenten gefragt, eigentlich wäre es mit der Buchungsnummer richtig, aus didaktischen Gründen allerdings nicht erlaubt - zusammengesetzte Keys erwünscht.

Ich würde daher nun in der letzten Tabelle als PK die Kombination aus
-Teilnehmer ID
-Kurs ID
-Datum oder Startzeit
nehmen.

Das wäre in dem Fall ok. Die von dir genannte Kombination wäre auch zuvor schon ein Superschlüssel gewesen und muss dementsprechend unique sein, da kannst du das dann als PK nehmen wenn dein Prof das didaktisch gut findet (warum auch immer).

Ich ging auch von einer "guten" Lösung aus, der Dozent meinte zwar, dass die Identifikation über die Buchungsnummer an und für sich zwar besser ist, aber wir "aus didaktischen Gründen" mit zusammgesetzen Schlüsseln arbeiten sollen. Was solls.
Danke euch!