Normalisierung 2.NF Probleme

[Gast here]

Ich habe hier folgende Tabelle, die aus der GA1 Winter 2019 stammt und tue mich da sehr schwer, diese in die 2.NF zu überführen. 

Ich brauche eine Kombination aus Schlüsseln, um einen Datensatz eindeutig zu identifizieren, Theorie alles klar soweit. In der Praxis sieht es bei mir mit der 2.NF aber leider nicht so gut aus und ich würde gerne wissen, ob es irgendein methodisches Vorgehen gibt  oder Tricks, um die Aufgabe sauber in den 20 Minuten zu lösen.

Ich beiße mir sehr lange die Zähne aus, um zu überprüfen welche Kombis wie eindeutig werden und dann (sofern es tatsächlich geklappt hat) müssen aus den gefundenen Schlüsseln auch noch die weiteren Tabellen erstellt werden-Fiel mir bei dieser Aufgabe auch sehr schwer und ich habe es nicht korrekt gelöst bekommen (Abgleich mit Löser).

Gefordert war u.a. das Überführen in 1.NF, 2.NF und 3.NF. Hier habe ich schonmal die 1.NF bereitgestellt.

[Gast Feature]

Also, die Attribute sind allesamt atomar. Die 1NF liegt also vor.

Die 2NF ist halbwegs erfüllt, da die vorliegende 1NF eine Voraussetzung ist. Es muss jedes Nichtschlüsselattribut von einem Schlüsselattribut abhängig sein (der Primary Key ist also gesucht). Wir können hier also in Tabellen splitten. Ich bin mir nicht sicher, ob ich den Kontext der Tabelle richtig verstanden habe (ist auch schon spät), aber Rad, Wart und MA sehen mir aufgrund ihrer IDs sehr nach Kandidaten aus. Daraus würde ich nun drei Tabellen erstellen. Die Nichtschlüsselattribute sind funktional abhängig von den Primary Keys. Anschließend liegt die 2NF vor. Würde bis hierhin also schon mal ganz gut aussehen.

Eine Voraussetzung für die 3NF ist das Vorliegen der 2NF. Sieht gut aus. Sind irgendwelche Attribute voneinander abhängig, die keine Schlüssel sind? Falls nein, liegt die 3NF vor.

Habe das Thema gehasst, aber ich denke, wenn man dabei systematisch vorgeht, kommt man immer ans Ziel. Ist ja bei der Bestimmung von Kardinalitäten nicht anders. Uns wurde immer gesagt: Hat man Normalisierung und Kardinalitäten hinter sich, ist die Datenbank ein Kinderspiel. Hoffe, ich konnte weiterhelfen.

[Gast here]

Das hat

vor 19 Stunden schrieb Feature:

Also, die Attribute sind allesamt atomar. Die 1NF liegt also vor.

Die 2NF ist halbwegs erfüllt, da die vorliegende 1NF eine Voraussetzung ist. Es muss jedes Nichtschlüsselattribut von einem Schlüsselattribut abhängig sein (der Primary Key ist also gesucht). Wir können hier also in Tabellen splitten. Ich bin mir nicht sicher, ob ich den Kontext der Tabelle richtig verstanden habe (ist auch schon spät), aber Rad, Wart und MA sehen mir aufgrund ihrer IDs sehr nach Kandidaten aus. Daraus würde ich nun drei Tabellen erstellen. Die Nichtschlüsselattribute sind funktional abhängig von den Primary Keys. Anschließend liegt die 2NF vor. Würde bis hierhin also schon mal ganz gut aussehen.

Eine Voraussetzung für die 3NF ist das Vorliegen der 2NF. Sieht gut aus. Sind irgendwelche Attribute voneinander abhängig, die keine Schlüssel sind? Falls nein, liegt die 3NF vor.

Habe das Thema gehasst, aber ich denke, wenn man dabei systematisch vorgeht, kommt man immer ans Ziel. Ist ja bei der Bestimmung von Kardinalitäten nicht anders. Uns wurde immer gesagt: Hat man Normalisierung und Kardinalitäten hinter sich, ist die Datenbank ein Kinderspiel. Hoffe, ich konnte weiterhelfen.

Das hat mir heute auf jeden Fall schonmal weitergeholfen. Allerdings bin ich immer noch auf der Suche nach einem systematischen Vorgehen zu den Schlüsseln.
 

Bei diesem Beispiel kann man jetzt leider nicht direkt sagen, "aha, wir nehmen einfach alles was im dem Attribut '...Nr' stehen hat als Schlüssel"

 

[Predni]

vor einer Stunde schrieb here:

Das hat

Das hat mir heute auf jeden Fall schonmal weitergeholfen. Allerdings bin ich immer noch auf der Suche nach einem systematischen Vorgehen zu den Schlüsseln.
 

Bei diesem Beispiel kann man jetzt leider nicht direkt sagen, "aha, wir nehmen einfach alles was im dem Attribut '...Nr' stehen hat als Schlüssel"

 

 

Wieso nicht? Ich habe die Bestellnr der ich eine bestimmte Bestellung zuordnen kann. Ich habe eine Kdnr die ich einem festen Kunden zuordnen kann und ich habe eine Artnr die ich einem festen Artikel zuordnen kann. Sind schonmal 3 Tabellen die ich daraus ziehen kann.

[Gast here]

vor 24 Minuten schrieb Predni:

Wieso nicht? Ich habe die Bestellnr der ich eine bestimmte Bestellung zuordnen kann. Ich habe eine Kdnr die ich einem festen Kunden zuordnen kann und ich habe eine Artnr die ich einem festen Artikel zuordnen kann. Sind schonmal 3 Tabellen die ich daraus ziehen kann.

2.NF ist gesucht, nicht die dritte

Welche Primärschlüssel würdest du denn bilden? Die von deinen genannten Tabellen?

 

 

 

 

 

 

 

 

[Gast Feature]

vor 4 Stunden schrieb here:

Das hat

Das hat mir heute auf jeden Fall schonmal weitergeholfen. Allerdings bin ich immer noch auf der Suche nach einem systematischen Vorgehen zu den Schlüsseln.
 

Bei diesem Beispiel kann man jetzt leider nicht direkt sagen, "aha, wir nehmen einfach alles was im dem Attribut '...Nr' stehen hat als Schlüssel"

 

Na ja, systematisch wird da schwierig, denn es hängt doch immer vom Kontext ab, wie die Beziehungen untereinander sind. Ich nehme mal an, das Datum gehört zur Bestellung? Dann haben wir ja schon mal eine Relation/Tabelle mit Primary Key. Dann gibt es die Tabelle Kunde, der auch schon eine Nummer hat. Dann gibt es noch die Tabelle Artikel. Ich würde aber aufpassen und die Bestellposition und die Anzahl in die Bestellung packen, nicht in die Artikel-Tabelle. So, dann überlegt man sich, wie das alles miteinander in Beziehung steht und fügt die Fremdschlüssel ein.

Später bestimmt man, wenn man daraus ein Modell bauen möchte, noch die Kardinalitäten und bis zum ERM/Tabellenmodell ist es dann nicht mehr weit (sofern das auch gesucht ist). Ansonsten schlage ich mal vor, dass du die konkrete Aufgabenstellung postest.

[Predni]

Tabellen:

Bestellungen Bestellnr (PK) ; Datum; KDnr (FK)

Kunde: KDnr (PK); Name

Artikel: Artnr (PK); Artikelbezeichnung

Für die Anzahl hätte ich dann noch eine Hilfstabelle:

Bestellpostion: Bestellpositionsnr (PK); Bestellnr (FK); Artnr (FK)´; Anzahl

 

[Gast here]

vor 18 Stunden schrieb Feature:

Na ja, systematisch wird da schwierig, denn es hängt doch immer vom Kontext ab, wie die Beziehungen untereinander sind. Ich nehme mal an, das Datum gehört zur Bestellung? Dann haben wir ja schon mal eine Relation/Tabelle mit Primary Key. Dann gibt es die Tabelle Kunde, der auch schon eine Nummer hat. Dann gibt es noch die Tabelle Artikel. Ich würde aber aufpassen und die Bestellposition und die Anzahl in die Bestellung packen, nicht in die Artikel-Tabelle. So, dann überlegt man sich, wie das alles miteinander in Beziehung steht und fügt die Fremdschlüssel ein.

Später bestimmt man, wenn man daraus ein Modell bauen möchte, noch die Kardinalitäten und bis zum ERM/Tabellenmodell ist es dann nicht mehr weit (sofern das auch gesucht ist). Ansonsten schlage ich mal vor, dass du die konkrete Aufgabenstellung postest.

Die Aufgabenstellung heißt: normalisiere in 2. NF und 3. NF, mehr Infos gibt es nicht
 

vor 10 Stunden schrieb Predni:

Tabellen:

Bestellungen Bestellnr (PK) ; Datum; KDnr (FK)

Kunde: KDnr (PK); Name

Artikel: Artnr (PK); Artikelbezeichnung

Für die Anzahl hätte ich dann noch eine Hilfstabelle:

Bestellpostion: Bestellpositionsnr (PK); Bestellnr (FK); Artnr (FK)´; Anzahl

du bist ja immer noch in der 3. NF  Ich möchte ja erstmal in die 2. kommen und dazu brauche ich die richtigen Schlüssel

 

 

Die offizielle Lösung sagt übrigens BestellNr und BestellPosition als zusammengesetzer Schlüssel und eigene Tabellen dann in der 2. NF