ER-Modell Verfahren der Schrittweisen Verfeinerung.

[JeeperCreeper]

Hallo,

die Aufgabe lautet, ein ER-Modell in ein Relationales Datenmodell zu bauen. Danach soll ich mit dem Verfahren der Schrittweisen Verfeinerung die 1-3 Normalform prüfen und nachbessern.

Im ersten Anhang habe ich das ER Modell gebaut.


im zweiten Schritt habe ich auf Basis des ER-Modell das Relationale Modell gebaut. Die Ausrufezeichen stehen für den Fremdschlüssel.


Als nächstes soll ich das Verfahren der Schrittweisen Verfeinerung vornehmen.

1. Normalform:
In der 1NF stellen wir sicher, dass jede Attributwert Menge Atomar ist und jede Tabelle einen Primärschlüssel hat.

Lösung:

Folgende Attribute lassen sich Atomar aufteilen:

• Name → Vorname, Nachname
• Adresse → Straße, Ort, Bundesland, Hausnummer ,Land, Postleitzahl, Stadt
• Datum → Tag, Monat, Jahr
• Rufnummer → Vorwahl, Rufnummer

2. Normalform:

• Die Relation muss bereits in der 1NF sein.
• Datenfelder müssen von einem Schlüssel“ funktional abhängig“ sein

Lösung: ??????????????
Hier komme ich nicht weiter. Ich habe mir jedes Video auf Youtube angeschaut und verstehe es immer noch nicht. In Videos hat man immer 2 Primäre Schlüssel verbunden, wie kommt man drauf? In meinem Modell habe ich ja entweder nur einzelne Tabellen mit 1 Primär Schlüssel oder manche Tabellen, die 1 Primärschlüssel und 1 Fremdschlüssel haben.
Muss ich für die zweite Normalform eine Datenbank erstellen und diese mit Werte füllen, die bewusst falsch anlegen, damit ich so, die 2 Normalform erklären kann?

 

[ukulele]

Also ich stecke jetzt nicht tief drin in deinem Projekt und natürlich weiß ich auch nicht auf welche YT Videos du dich beziehst.

Ein gängiger Anwendungsfall für zusammengesetzte PKs wäre eine n:m-Beziehung, die maximal einmal bestehen kann. Du hast so eine Beziehung zwischen Produkt und Lagert. Die Tabelle "lagert_in" die diese Beziehung abbildet, hat einen FK auf Lager und einen auf Produkt. Die beiden zusammen können den PK bilden weil sie zusammen eindeutig sind. Gibt es hier allerdings eine zeitliche Komponente, wo Produkt A in Lager A liegt, entnommen wird, und wieder eingelagert wird, und dabei zwei Einträge in "lagert_in" mit jeweils Zeitraum erfolgen müsste man den PK noch um den Zeitraum erweitern, damit er wieder eindeutig ist.

Die Theorie (Normalform) versucht ja, keine künstlichen PKs zu erstellen, wenn ein Schlüsselkandidat vorhanden ist. In der Praxis würde man an diesem Punkt einfach sagen fuck it und eine ID in die Tabelle hauen

 

[dabadepdu]

In Videos hat man immer 2 Primäre Schlüssel verbunden, wie kommt man drauf?

Das macht man immer, in den Beispielen für die 2. NF, weil die sich darum dreht. Das heißt alles
- was aus 2 Schlüsseln besteht, muss betrachtet werden (und genau dafür sind die Beispiele)
- was nur 1 Schlüssel hat, ist automatisch 2. NF
- zusätzliche Attribute müssen genau betrachtet werden, ob sie tatsächlich von beiden Schlüsseln abhängig sind (sonst sind sie falsch zugeordnet)

Für die 2. NF musst Du also nur Tabellen mit mehr als 1. Schlüsselkandidat betrachten.

In Deinem Model sieht es so aus, dass die Bestellung auch ein gutes Beispiel ist (neben Lager, Produkt). Du hast dazu die Menge modelliert, aber die ist nicht in dem anderen Screenshot aufgeführt. Es gibt also nur Bestellung mit Bestellung beinhaltet Produkt ohne Mengenangabe.
Die Mengenangabe gehört mit dazu und ist weder nur von Bestellung abhängig noch nur von Produkt, also ein solider Fall für 2. NF.

In meinem Modell habe ich ja entweder nur einzelne Tabellen mit 1 Primär Schlüssel oder manche Tabellen, die 1 Primärschlüssel und 1 Fremdschlüssel haben.

Das stimmt also wohl nicht oder? Bestellpositionen bestehen aus PK auf Bestellung und PK auf Produkt.

Muss ich für die zweite Normalform eine Datenbank erstellen und diese mit Werte füllen, die bewusst falsch anlegen, damit ich so, die 2 Normalform erklären kann?

Ich denke nicht. Wenn Du es drauf hast, machst Du eine Modell Version für jede NF oder Du machst direkt die finale NF.
Hier ist einfach die Frage, was im Unterricht / Lehre speziell als Aufgabe gestellt ist. Daran musst Du Dich halten.

Für Dich selbst kannst Du natürlich die Tabellen in verschiedenen NF anlegen und ausprobieren, wie die Sachen funktionieren. Dafür musst Du nicht verschiedene DB anlegen, einfach andere Namen und die Insert Scripte etwas anpassen. Fertig.
Und wenn Du damit spielst, Daten einfügst (echte Bestellung) und versuchst, die zu aktualisieren oder sowas, dann merkst Du auch ganz gut, wo der Haken an einer x.NF steckt. Einfach machen, tut nicht weh. Nebenbei kann man mit Transactions spielen und alles was Müll ist wieder zurückdrehen - wenn es nicht sowieso Fehler produziert und von allein geschieht. Aber das ist ein eigenes Thema und hier erstmal nicht entscheidend, nur praktisch.