Normalisierung - Datenbanken?

[RobertB2011]

Hallo,

wir haben gerade in der Schule das Thema "Normalisierung".

Leider finde ich gar kein Zugang zu dem Thema. Wir haben das Thema nur paar Wochen lang und der Lehrer hat es einfach sehr schnell erklärt. Habe mir schon diverse Seiten angeschaut, aber die erklären das meistens mit einem Fachchinesisch

Wir haben beispielsweise so eine Aufgabe:

http://abload.de/img/scan78oki2d.jpg
http://abload.de/img/scan9999z1faj.jpg

Wir bekommen immer die 0 Form und müssen dann die 1, 2 und 3 Normalform bilden.

Die erste Normalform ist einfach und kann ich nachvollziehen.

Was man bei der zweiten und dritten machen muss, verstehe ich leider gar nicht. Könnte das vielleicht jemand verständlich erklären?

Das wäre richtig klasse! Vielen lieben Dank!

 

[paep]

Hier ist es doch eigentlich ganz gut erklärt:

http://www.tinohempel.de/info/info/datenbank/normalisierung.htm

 

[s_fiebig]

Hallo,
ich kann nur empfehlen sich das Thema etwa hier durchzulesen: http://v.hdm-stuttgart.de/~riekert/lehre/db-kelz/chap4.htm
Derjenige hat wesentlich mehr Zeit investiert, um das Thema aufzubereiten, als es hier wohl jemand in kurzer Zeit schafft. Dann kannst Du dazu vielleicht zielgerichtet eine Frage stellen.

Ich denke das Thema erfordert vielleicht ein wenig Praxis. Hast Du bereits mit einer einfachen Datenbank - nicht auf dem Papier - gearbeitet?

Edit: Der Link vom Poster vor mir hat sogar schrittweise Anweisungen und ist noch verständlicher.

 

[Valhal]

Das Prinzip ist ganz einfach: Es darf keine Duplikate in der Datenbank geben. Die Durchführung ist auch leicht, wenn du dir überlegst, dass jede Entität bzw. jeder Gegenstand bzw. jedes Objekt eine eigene Tabelle haben muss.

1. Schaue welche Objekte/Gegenstände/Entitäten du hast.
2. Jedes Ding in eine Tabelle
3. Verbindungen mit extra Tabelle herstellen

Du solltest nicht in "Normalformen" denken. Kein Mensch geht die Normalformen 1-5 in der Praxis durch... das ist schwachsinnige Datenbanktheorie. Benutzt lieber deine eigene Vorgehensweise: Keine Duplikate!

 

[RobertB2011]

Vielen Dank, für eure Antworten.

Eine Relation ist in der Zweiten Normalform, wenn sie in der Ersten Normalform ist und jedes Nicht-Schlüsselattribut von jedem Schlüsselkandidaten vollständig funktional abhängig ist.

Der fette Teil: Also ich brauche die 1. NF damit ich die 2. NF bilden kann ---> Alles klar

Zum anderen Teil: Nicht-Schlüsselattribute sind alle Zeilen außer die mit den Primärschlüsseln? Also in meinem Beispiel KundeNR, Kunde etc.?

Was ich nicht verstehe: Wieso ist in meinem Beispiel BestellAnz von den Primärschlüsseln Bestellnr und BestellAnz abhängig? Danke

Das Prinzip ist ganz einfach: Es darf keine Duplikate in der Datenbank geben. Die Durchführung ist auch leicht, wenn du dir überlegst, dass jede Entität bzw. jeder Gegenstand bzw. jedes Objekt eine eigene Tabelle haben muss.

1. Schaue welche Objekte/Gegenstände/Entitäten du hast.
2. Jedes Ding in eine Tabelle
3. Verbindungen mit extra Tabelle herstellen

Du solltest nicht in "Normalformen" denken. Kein Mensch geht die Normalformen 1-5 in der Praxis durch... das ist schwachsinnige Datenbanktheorie. Benutzt lieber deine eigene Vorgehensweise: Keine Duplikate!

Interessanter Ansatz. Aber so recht will es nicht klappen... Versuche es mal bei paar Aufgaben

 

[s_fiebig]

Nicht-Schlüsselattribute sind alle Zeilen außer die mit den Primärschlüsseln?

Nein, da Attribute keine Zeilen sind. :-)

Was ich nicht verstehe: Wieso ist in meinem Beispiel BestellAnz von den Primärschlüsseln Bestellnr und BestellAnz abhängig?

Du beziehst Dich auf die 2. Tabelle hier: http://abload.de/img/scan9999z1faj.jpg
Bevor ich die Lösung poste: Was soll diese Tabelle denn ausdrücken, in Worten. Was passiert denn beim Bestellen?

 

[RobertB2011]

Nein, da Attribute keine Zeilen sind. :-)

Spalten?

---

Du beziehst Dich auf die 2. Tabelle hier: http://abload.de/img/scan9999z1faj.jpg
Bevor ich die Lösung poste: Was soll diese Tabelle denn ausdrücken, in Worten. Was passiert denn beim Bestellen?

Ich meintte die 2. NF:

http://abload.de/img/scan78oki2d.jpg

 

[Freezedevil]

Du musst dir eine Spalte aus der Tabelle der ersten Normalform herauspicken und dann überprüfen ob eine andere von ihr abhängig ist. Nehmen wir beispielsweise mal die Spalte ArtNr. Jeder Wert gibt eindeutig (nicht eineindeutig) vor welcher Wert beispielsweise in der Spalte ArtName steht.
45 -> Schalter
46 -> Schalter
47 -> Dimmer
99 -> Sirene

Das muss man dann eigentlich für alle möglichen Spaltenpaare machen, wenn man komplett mechanisch ohne höhere Logik vorgeht. Das ist jedoch eigentlich kein besonders gutes Vorgehen und bei solch kleinen Datensätzen schon garnicht. Da existieren nämlich Abhängigkeiten die nur durch der Winzigkeit des Datenbestandes existieren. Beispielsweise ist der Artikelname von der Artikelanzahl abhängig, was logisch gesehen Schwachsinn ist. Man kommt so also eher nicht ans Ziel obwohl dieses Vorgehen der formalen Definition folgt.

Im Prinzip solltest du dich eher an den Rat von Valhal halten.

Hier mal ein Beispiel welches eigentlich genauso gelagert ist wie deins, aber du kannst ja mal testweise schreiben wie die normalisierten Tabellen aussehen würden und warum du es so machen würdest.

Filmname | ReleaseJahr | Produktionsland | Schauspielername | Geburtsjahr | NameDerRolle

also beispielsweise:
Snatch | 2000 | USA | Brad Pitt | 1963 | Mickey
...

Die eigentlichen Daten sind für dieses Vorgehen jedoch unerheblich.

 

[RobertB2011]

Du musst dir eine Spalte aus der Tabelle der ersten Normalform herauspicken und dann überprüfen ob eine andere von ihr abhängig ist.

Ich dachte immer man muss mit den Spalten der Primärschlüssel schauen, ob eine andere Spalte vom Primärschlüssel abhängig ist? Also für die 2. NF...

Jetzt mal rein logisch gedacht, würde ich es wie folgt machen:

Filmname | ReleaseJahr | Produktionsland

Schauspielername | Geburtsjahr | NameDerRolle

Vielen lieben Dank, für die Antwort

 

[Freezedevil]

Ja es könnte tatsächlich sein, dass man das nur beim Schlüssel prüfen muss. Wie gesagt macht das in der Praxis kein Mensch so.
Deine Normalisierung ist allerdings nicht ganz richtig. Ist der Name der Rolle tatsächlich eine Eigenschaft die zum Schauspieler gehört? Sicherlich nicht, denn Brad Pitt hat schon viele Rollen gespielt. Schau dir nochmal alle drei Schritte an.

1. Schaue welche Objekte/Gegenstände/Entitäten du hast.
2. Jedes Ding in eine Tabelle
3. Verbindungen mit extra Tabelle herstellen

 

[RobertB2011]

1. Schaue welche Objekte/Gegenstände/Entitäten du hast.
2. Jedes Ding in eine Tabelle
3. Verbindungen mit extra Tabelle herstellen

Jedes Ding in eine Tabelle?

Also zum Film gehört: Filmname | ReleaseJahr | Produktionsland

Zum Schauspieler gehört: Schauspielername | Geburtsjahr

NameDerRolle ---> wäre dann alleine?

Würde mich freuen, wenn du die richtige Lösung angeben würdest. Dann würde ich das verstehen.

Vielen Dank

 

[Freezedevil]

Entscheidend ist der dritte Punkt. In einem Film gibt es mehrere Schauspieler und ein Schauspieler kann in mehreren Filmen mitwirken - eine klassische n:m Beziehung also. Das bedeutet, dass du eine zusätzliche Tabelle für die Beziehung zwischen beiden benötigst. Der Name der Rolle ist ein zusätzliches Attribut dieser Beziehung, da der Name der Rolle durch den Film und den Schauspieler bestimmt ist (zumindest wenn man mal ausblendet, dass ein Schauspieler mehrere Rollen in einem Film übernimmt). Das bedeutet, dass du am Ende drei Tabellen hast.

Film
Filmname | Releasejahr | Produktionsland

Schauspieler
Schauspielername | Geburtsjahr

spielt_in
Filmname | Schauspielername | NameDerRolle

Edit:
Vermutlich seid ihr noch nicht bei Joins, aber du musst dir vorstellen, dass du die Tabellen für bestimmte Abfragen wieder zusammensetzen musst - sprich joinen. Wenn du zB wissen willst welche Schauspieler in Film x mitgespielt haben. Dafür braucht man eine solche Verbundtabelle.

 

[RobertB2011]

Vielen lieben Dank, für die super Erklärung.

Eine Frage hätte ich noch:

http://abload.de/img/foto2ahdfc.jpg

Wieso habe ich in der 1. NF Code und Saison als Primärschlüssel? Was für einen nutzen hat der Primärschlüssel beziehungsweise welche Frage muss ich mir stellen um auf den Primärschlüssel zu kommen?

---

2. NF

Wieso sind zum Beispiel vom Code die Nichtschlüsselattribute Stadt, Region, Hotel, Zimmer und Stern abhängig? Welche Frage muss ich mir da stellen?

Wäre toll, wenn das noch jemand erklären würde. Dann wäre es glaub verstanden

Vielen Dank!

 

[paep]

Zu 1.

Der Primärschlüssel ist ein Verbundschlüssel. Du musst dir die Frage stellen, wie du einen Datensatz eindeutig identifizieren kannst.

Pro Code gibt es nur jeweils einmal Saison A, B, C oder D.

Zu 2.

Der Code ist die "Nummer" des Hotels, identifiziert also ein Hotel eindeutig. Jedes Hotel ist fest in einer Stadt und Region. Außerdem hat es eine Anzahl an Zimmern und Sterne.

 

[RobertB2011]

Vielen Dank, richtig gut erklärt!

Also kann ich mir eigentlich immer die Frage stellen bei der 1 zur 2. Form : brauche ich den Primärschlüssel um auf das Nichtschlüsselattribut zu kommen? Ist das korrekt ?

Dankeschön