Normalisierung 1.NF Primärschlüssel finden

[Gast here]

Hi,

ich tue mich irgendwie schwer damit, die korrekten Primärschlüssel zu finden, nachdem ich eine bestehende Tabelle in die 1.NF versetzt habe.

Gegeben ist die folgende Tabelle:

 

Umgewandelt in atomare Informationen

 

Die Theorie ist mir klar. Ich brauche einen Schlüssel, durch den jedes Attribut eindeutig identifiziert werden kann.

Datum ist abhängig von BestellNr -> ok
KdNr + Name ist abhängig von BestellNr -> ok
ArtNr ist nicht abhängig von BestellNr -> wäre für mich ein möglicher Schlüsselkandidat
ArtikelBez ist abhängig von ArtNr
Anzahl ist eindeutig identifizierbar über BestellNr & ArtNr
Bestellpos ist eindeutig identifizierbar über BestellNr & ArtNr

Somit wäre mein Schlüssel BestellNr und ArtNr

Dies ist aber so nicht in dem Beispiel als Lösung angegeben.

Kann mir jemand generell weiterhelfen, wie ich sowas korrekt angehe?

 

 

 

 

 

 

[Wurmi]

PK ist die Kombination BestellNr und Position.

ArtNr ist alles andere als ein Schlüsselkandidat, weil er die anderen Felder nicht bestimmt. Das wäre nämlich nur dann so, daß wenn die gleiche ArtNr in einer Zeile steht, auch die anderen Felder gleich sind. Artikel 12 Tisch ist aber einmal für Kunde Maier und ein anderes Mal für Kunde Schulz drin.

Um dann in die zweite Normalform zu kommen, muß alles, was nur von der Bestellnummer abhängt, in eine eigene Relation: Bestelldatum, Kundennummer

Für die 3. NF sind dann die Felder zu entfernen, welche von anderen Nichtschlüsselfeldern funktional abhängen: Kundenname, Artikelbezeichnung

 

 

Bearbeitet 13. November 2022 von Wurmi
Ergänzung

[Gast here]

vor 32 Minuten schrieb Wurmi:

PK ist die Kombination BestellNr und Position.

ArtNr ist alles andere als ein Schlüsselkandidat, weil er die anderen Felder nicht bestimmt. Das wäre nämlich nur dann so, daß wenn die gleiche ArtNr in einer Zeile steht, auch die anderen Felder gleich sind. Artikel 12 Tisch ist aber einmal für Kunde Maier und ein anderes Mal für Kunde Schulz drin.

Deine Lösung steht so auch in meiner Lösung. 

Jetzt kommt aber nochmal der Punkt den ich einfach nicht verstehe: 

Die einzelnen Attribute müssen doch alle eindeutig über den  zusammengesetzten Primärschlüssel identifizierbar sein.
In deinem Fall trifft das zu, in meinem doch aber auch oder wo sehe ich den Fehler nicht?

Die von dir angesprochenen Zeilen mit Artikel 12 Tisch:

Die Position ist auch immer unterschiedlich bei meiner Kombi aus den Schlüsseln

Bei deiner Kombi:

ArtNr und Anzahl hängen jeweils vom Primärschlüssel auf, auch keine Redundanz.


Ich stehe echt komplett auf dem Schlauch.
 

 

[Wurmi]

Grundsätzlich: Die Kombination  BestNr und ArtNr wäre im Prinzip nicht verkehrt für ein Tabelle mit Bestellpositionen. Deine Intuition ist da nicht abwegig. Wenn man das so machen würde, könnte man aber in einer Bestellung niemals mehrere Positionen für den gleichen Artikel haben. Die Spalte Position würde dann außerdem keinen Sinn mehr machen.

Wenn Du diese Kombination so nimmst, was machst Du dann mit der Spalte 'Position'? Von was ist sie abhängig? Vom kombinierten PK nicht, nicht von einem Teil des PK und auch nicht von einem Nichtschlüsselfeld.

M.a.W: Ein Computerprogramm, welches hier nach dem mathematischen Regelwerk rein mechanisch und ohne Hintergrundwissen die Schlüsselkandidaten berechnen würde, würde anhand der vorliegenden Daten wohl sowohl die Kombination BestNr+ArtNr als auch BestNr+Position finden. Das Programm könnte nicht entscheiden, ob ArtNr die Position bestimmt oder die Position die ArtNr. 

Denke Dir eine weitere Bestellung 4 dazu, mit ArtNr 12 in einer Position 2. Dann wärst Du vielleicht gar nicht auf die Idee gekommen, die ArtNr als Teil des PK zu nehmen. 

Nicht verzagen, Du wärst nicht der erste, der Kopfweh mit diesem Thema bekommen hätte 😀

[Whiz-zarD]

 Man könnte sich auch überlegen, welche Kombination von Schlüsselattributen unique ist und dies dann dann der Primärschlüssel und da kommt nur { BestellNr, Pos } in Frage.

Zu jeder Bestellung kann es nur noch eindeutige Positionen geben. In einer Bestellung könnte ja auch mehrfach der gleiche Artikel vorhanden sein. Kennt man ja z.B. auch bei einem Kassenbon, wenn der/die Kassierer/in mehrfach den gleichen Artikel über den Scanner schiebt. Dann taucht der Artikel auch mehrfach auf dem Bon auf aber sie haben unterschiedliche Positionen.

Bearbeitet 13. November 2022 von Whiz-zarD

[Wurmi]

Ich muß das zurücknehmen, was ich oben geschrieben habe. Weil es im Beispiel schon zweimal den Artikel 67 Stuhl gibt, mit unterschiedlichen Positionsnummern. Damit kann der Artikel nicht funktional die Positionsnummer bestimmen.

[Wurmi]

vor 6 Minuten schrieb Whiz-zarD:

 Man könnte sich auch überlegen, welche Kombination von Schlüsselattributen unique ist und dies dann dann der Primärschlüssel und da kommt nur { BestellNr, Pos } in Frage.

Sowohl BestNr+ArtNr als auch BestNr+PosNr sind unique im Beispiel. Das ist ja das knifflige. Ohne semantischen Hintergrundwissen kann man da den richtigen PK nicht entscheiden.

[Whiz-zarD]

Es darf aber keine Position pro Bestellung mehrfach geben aber das würde { BestNr, ArtNr } erlauben. Somit gäbe es keine eindeutige Identifikation. { BestellNr, Pos } identifizieren die Zeilen eindeutig. Wenn ein Artikel auch nur ein mal pro Bestellung vorkommen darf, dann braucht man noch einen Unquie-Constraint über { BestNr, ArtNr }.

Bearbeitet 13. November 2022 von Whiz-zarD

[Wurmi]

vor 5 Minuten schrieb Whiz-zarD:

Es darf aber keine Position pro Bestellung mehrfach geben aber das würde { BestNr, ArtNr } erlauben. Somit gäbe es keine eindeutige Identifikation. { BestellNr, Pos } identifizieren die Zeilen eindeutig.

Ganz meine Rede. Es steht alles schon weiter oben. Der Kollege muß ja die mathematischen Regeln anwenden lernen - die funktionale Abhängigkeit und die inhaltliche Thematik sind 2 Paar Stiefel.

Etwa wenn ich eine Relation habe von der Art:

• Max;23
• Moritz;24
• Hans;35
• Lise;17

Was ist hier der Primary Key? 

[Gast here]

vor 2 Stunden schrieb Whiz-zarD:

Es darf aber keine Position pro Bestellung mehrfach geben aber das würde { BestNr, ArtNr } erlauben. Somit gäbe es keine eindeutige Identifikation. { BestellNr, Pos } identifizieren die Zeilen eindeutig. Wenn ein Artikel auch nur ein mal pro Bestellung vorkommen darf, dann braucht man noch einen Unquie-Constraint über { BestNr, ArtNr }.

 

vor 1 Stunde schrieb Wurmi:

Ganz meine Rede. Es steht alles schon weiter oben. Der Kollege muß ja die mathematischen Regeln anwenden lernen - die funktionale Abhängigkeit und die inhaltliche Thematik sind 2 Paar Stiefel.

Etwa wenn ich eine Relation habe von der Art:

• Max;23
• Moritz;24
• Hans;35
• Lise;17

Was ist hier der Primary Key? 

Ich habe zumindest herausgefunden, dass ich die 2.NF scheinbar auch so hinbekomme, wenn ich nur über die Kardinalitäten gehe. Dann fehlt vielleicht mal ein Schlüsselchen aber der Rest scheint trotzdem zu passen. Irgendwie habe ich das Gefühl, dass dieses logische Zerdenken es nur noch schlimmer macht bei mir. Ich brauche ein System das ich anwenden kann.

Zu deinem Beispiel:
Zahlenkombinationen sind i.d.R. eindeutig, deshalb die Zahlen. Allerdings steht nirgendwo, dass Buchstabenkombis dies nicht auch sein könnten. In diesem Fall wäre die Spalte zu nehmen, die nur eindeutige Informationen beinhaltet.

Bearbeitet 13. November 2022 von here

[Wurmi]

Das was du 'logisches Zerdenken' nennst, ist ein mathematisches Vorgehen, was man kennen sollte. Jedoch reicht es nicht, um gute Datenbanken zu designen, es braucht da noch Erfahrung und Intuition dazu. 

Anhand von Beispieldaten reicht logisches Vorgehen nicht, es braucht außerdem Hintergrundwissen. Eine funktionale Abhängigkeit kann man anhand von Beispieldaten zum Beispiel immer nur widerlegen, aber niemals beweisen!

In meinem Primitivbeispiel könnte die Zahl eben alles sein: eine PersonenId (um damit ein Schlüsselkandidat), das Alter, wann man die Unschuld verloren hat, die Gehaltsklasse, die Hausnummer, das Gewicht, Startnummer, you name it... Daß die Zahl im Beispiel zufällig unique ist, beweist in keinster Weise, daß sie es immer sein muß. Ein rein logisches Vorgehen zum Finden des PK versagt bei meinem Beispiel.

Und so ist es auch bei dem Beispiel aus der Aufgabe. Daß in den Bestellungen die ArtNr nur einmal vorkommt, bedeutet nicht, daß es auch so sein muß.

[Gast here]

vor 52 Minuten schrieb Wurmi:

Das was du 'logisches Zerdenken' nennst, ist ein mathematisches Vorgehen, was man kennen sollte. Jedoch reicht es nicht, um gute Datenbanken zu designen, es braucht da noch Erfahrung und Intuition dazu. 

Anhand von Beispieldaten reicht logisches Vorgehen nicht, es braucht außerdem Hintergrundwissen. Eine funktionale Abhängigkeit kann man anhand von Beispieldaten zum Beispiel immer nur widerlegen, aber niemals beweisen!

In meinem Primitivbeispiel könnte die Zahl eben alles sein: eine PersonenId (um damit ein Schlüsselkandidat), das Alter, wann man die Unschuld verloren hat, die Gehaltsklasse, die Hausnummer, das Gewicht, Startnummer, you name it... Daß die Zahl im Beispiel zufällig unique ist, beweist in keinster Weise, daß sie es immer sein muß. Ein rein logisches Vorgehen zum Finden des PK versagt bei meinem Beispiel.

Und so ist es auch bei dem Beispiel aus der Aufgabe. Daß in den Bestellungen die ArtNr nur einmal vorkommt, bedeutet nicht, daß es auch so sein muß.

Jetzt fängt es an kompliziert zu werden. Wie genau ist denn dieses mathematische Vorgehen, um eben solche Aufgaben der IHK gut zu lösen? Mit meinem bisherigen Wissen konnte ich die IHK Dinger immer ganz gut lösen, allerdings weiß ja keiner was so in den neuen Prüfungen anders gemacht wird, deshalb würde ich da schon gerne dein System verstehen bzw. anwenden lernen.

Aktuelle Strategie bei mir: Kardinalitäten aus der Tabelle bilden und daraus neue Tabellen ableiten. m:n in der 2.Nf auflösen und in der 3.NF nur noch die transitiven Abhängigkeiten weg. 

Bearbeitet 13. November 2022 von here

[lukas256]

Kann mans nicht easy machen und einer OrderNummer der ganzen geben

[Wurmi]

vor 12 Minuten schrieb here:

Jetzt fängt es an kompliziert zu werden. Wie genau ist denn dieses mathematische Vorgehen, um eben solche Aufgaben der IHK gut zu lösen? Mit meinem bisherigen Wissen konnte ich die IHK Dinger immer ganz gut lösen, allerdings weiß ja keiner was so in den neuen Prüfungen anders gemacht wird, deshalb würde ich da schon gerne dein System verstehen bzw. anwenden lernen.

Ich habe da ehrlich gesagt kein persönliches System und bin da auch schon recht lang weg von der Theorie. Jedenfalls gibt es Algorithmen, um Schlüsselkandidaten zu bestimmen. Man findet mit Google mehr als genug, wenn man Armstrong-Axiome, Primary-Key, Algorithmus, Normalform etc. eingibt. Kommt mir manches bekannt vor, aber in voller mathematischer Notation sieht das Recht abschreckend aus. Die Prüfungen bei der IHK sind auch darauf angelegt, dass man die ersten 3 Normalform versteht und das Verständnis anwenden kann - das reicht.

 

[Wurmi]

Eine Sache kann ich ohne Formelkram mitgeben:

Bei einer Funktion muss bei gleichem Input immer der gleiche Output rauskommen. Ist bei einer Beispieltabelle mit vielen Spalten zum Beispiel bei 2 Spalten folgende Situation

Kunde;Alter

• Hans;23
• Hans;23
• Hans;23

so ist zu vermuten, daß eine funktionale Abhängigkeit zwischen Kunde und Alter besteht, was etwa bei der 3NF bedeutet, daß der abhängige Wert rausmuss. 

Kommt der Datensatz

• Hans;24

dazu, so ist die Vermutung funktionale Abhängigkeit widerlegt.

 

 

[Gast here]

vor 31 Minuten schrieb Wurmi:

Die Prüfungen bei der IHK sind auch darauf angelegt, dass man die ersten 3 Normalform versteht und das Verständnis anwenden kann - das reicht.

 

Genau darum geht's mir ja erstmal. Und dafür brauche ich ein geeignetes Vorgehen, welches wie ein Algorithmus sicher funktioniert. 

[Wurmi]

vor 24 Minuten schrieb here:

Genau darum geht's mir ja erstmal. Und dafür brauche ich ein geeignetes Vorgehen, welches wie ein Algorithmus sicher funktioniert. 

Daß ein reiner Algorithmus nicht reicht, habe ich weiter oben ja versucht, auszudrücken. Ein Algorithmus kann von einem Computer ausgeführt werden, und ein solcher kann in deinem Beispiel, auf die Gefahr mich zu wiederholen, nicht sagen, ob BestNr+ArtNr oder BestNr+Position der richtige PK ist. Sprich, rein algorithmisch kriegst Du die Hausaufgabe nicht gelöst und nicht einmal mein Primitivbeispiel.

Kennst Du die Merkregel "The key, the whole key, and nothing but the key". Das sind die drei NF.