Zu blöd zum arbeiten mit normalisierten Tabellen :(

[dragi]

Hallo,

wenn ich eine Adressdatenbank habe die eine Tabelle Name und Vorname hat brauche ich ja noch eine Tabelle die die IDs von Name und Vorname zusammenhält. Jetzt schreibe ich Tester Toni in die Tabellen Name und Vorname...wie soll die dritte tabelle dann gefüllt werden?! Ich kenne die IDs doch noch nicht wenn ich den Datensatz schreibe?!

Könnt ihr mir das erklären?

Gruß

Dragi

[Joe Kinley]

Ich versteh dein Problem gerade nicht..

Warum musst du die ID von Namen und Vornamen trennen ? Die sind doch beide Abhaengig von der ID...

[carstenj]

Hallo,

ja noch eine Tabelle die die IDs von Name und Vorname zusammenhält

naja, man kann Normalisierung auch übertreiben. Name und Vorname sollten eigentlich schon in einer Tabelle auftauchen. Das hat ja auch den Sinn, dass man Datensätze eindeutig identifizieren kann, und eine Person ist eine Person, sie besteht nicht aus Namen und Vornamen. Oder habe ich dich falsch verstanden?

Aber wieso weisst du die ID nicht beim Erstellen? Du vergibst die doch?!

[Monty82]

Aber wieso weisst du die ID nicht beim Erstellen? Du vergibst die doch?!

Oder sie wird - je nach dem welches RDMS und welche Einstellung (autoincrement) - automatisch vergeben, kann aber dann auch nach dem erstellen ausgelesen werden.

Ansonsten stimme ich carstenj's Aussage zu.

[dragi]

Das Problem hat sich gerade erledigt. ich habe zu sehr um die Ecke gedacht... Vielen Dank für die Antworten.

Gruss

Dragi

[zirri]

Hallo,

wenn ich eine Adressdatenbank habe die eine Tabelle Name und Vorname hat brauche ich ja noch eine Tabelle die die IDs von Name und Vorname zusammenhält. Jetzt schreibe ich Tester Toni in die Tabellen Name und Vorname...wie soll die dritte tabelle dann gefüllt werden?! Ich kenne die IDs doch noch nicht wenn ich den Datensatz schreibe?!

Könnt ihr mir das erklären?

Gruß

Dragi

Also, ich will Dir nicht zu nahe treten, aber lerne erstmal die Grundsätze von Datenbanken & Dich vielleicht korrekt auszudrücken...

Du redest die ganze Zeit von Tabellen, meinst aber Spalten/Felder/E..... & was wirklich Dein Problem ist kommt auch nicht rüber

Nichts für ungut

gruss / zirri

[dragi]

Wenn ich von Tabellen rede meine ich auch Tabellen. Es sollte ein kleines Bespiel sein und Name und Vorname packt man beim normalisieren in 2 Tabellen denn sonst würde man "Müller" mehrmals schreiben. Das man das nicht in der Praxis macht ist mir auch klar...aber es sollte ein Beispiel zur Normalisierung sein.

Gruß

dragi

[geloescht_JesterDay]

Es sollte ein kleines Bespiel sein und Name und Vorname packt man beim normalisieren in 2 Tabellen denn sonst würde man "Müller" mehrmals schreiben. Das man das nicht in der Praxis macht ist mir auch klar...aber es sollte ein Beispiel zur Normalisierung sein.

i

Sagtest ja schon, in der Praxis ist das absolut praxisfremd

Aber du meinst wohl sowas:

Vornamen:


ID

Text



Nachnamen:


ID

Text


Personen:

ID

ID_VN

ID_NN

[dragi]

Ja, so war das gemeint

Aber ich denke mal ich muß beim hinzufügen eines Datensatzes erstmal prüfen ob der Name schon vorhanden ist, wenn ja, dann die ID merken. Als nächstes das gleiche mit dem Vornamen und wenn etwas nciht vorhanden ist es hinzufügen und die ID dann merken. und zum schluss schreibe ich denn die rausgesuchten IDs in die Tabelle Personen. Richtig?

Gruß

dragi

[ksg9-sebastian]

Du denkst wirklich total um die Ecke

1. SELECT DISTINCT auf die Datenbank abfäuern mit:

vorname LIKE $vorname && nachname LIKE $nachname

2. ResultSet enthält Daten (länge > 0)

2.1 ja

- Person mit vorname nachname ist schon vorhanden

2.2 nein

- Person ist noch nicht vorhanden

- Person hinzufügen

Person in zwei Tabellen aufzuteilen (Name + Vorname zu trennen ist völlig übertrieben und bring nur Mehr-Aufwand, weil du ne Abfrage über mehrere Tabellen machen musst, das hat auch nichts mehr mit dem eigentlichen Sinn von Normalisierung zu tun).

[zirri]

man kann sich auch kaputt normalisieren...

man sollte Datenaufkommen vs. Performance gegenüber stellen......

[dragi]

Wie gesagt ist es ja nur ein Beispiel um Normalisierung anwenden zu lernen. In einem Projekt würde ich das auch nicht machen!

Dragi

[IJK]

Um es auf die Spitze zu treiben @Jesterday

Du könntest Vor- und Nachnamen verwursteln (jemand heißt zB Thomas Ludwig, zwei mögliches Vornamen):

ID

Text

Personen:

ID

ID_Vorname

ID_Nachname

*hehe*

Allerdings wird es komplexer, wenn man nun mehrere Vornamen hat, da man diese wieder in einem Textfeld der ersten Tabelle zusammenfassen muss, was aber nicht wirklich normalisiert wäre...

[Goos]

Wenn ich von Tabellen rede meine ich auch Tabellen. Es sollte ein kleines Bespiel sein und Name und Vorname packt man beim normalisieren in 2 Tabellen denn sonst würde man "Müller" mehrmals schreiben. Das man das nicht in der Praxis macht ist mir auch klar...aber es sollte ein Beispiel zur Normalisierung sein.

Erklaert mir bitte jemand, was das mit Normalisierung zutun haben soll?

Goos

[ksg9-sebastian]

Erklaert mir bitte jemand, was das mit Normalisierung zutun haben soll?

1. NF: Pro Zeile nur genau ein Datensatz, d.h. keine "Listen" in ne Zelle oder so, == keine redundanten (sich wiederholende) Daten

2. NF: Jeder Datensatz muss eindeutig identifizierbar sein (=Primärschlüssel)

3. NF: Jede Spalte muss DIREKT über den Primärschlüssel eindeutig sein, und NICHT über seine zweite Spalte.

Beispiel zur 3. NF:

Tabelle Person

personenId INT

vorname Varchar(30)

nachname Varchar(30)

Das wäre _keine_ 3. NF, weil der nachname nur zusammen mit dem Vornamen eindeutig sind.

Es kann mehrere Personen geben welche den gleichen Vor- oder Nachnamen haben, somit wäre vorname und nachname nur _zusammen_ eindeutig.

Edit: Und genau das ist in dem Beispiel von dragi der Fall

[..] Name und Vorname packt man beim normalisieren in 2 Tabellen denn sonst würde man "Müller" mehrmals schreiben [..]

[Goos]

Beispiel zur 3. NF:

Tabelle Person

personenId INT

vorname Varchar(30)

nachname Varchar(30)

Das wäre _keine_ 3. NF, weil der nachname nur zusammen mit dem Vornamen eindeutig sind.

Es kann mehrere Personen geben welche den gleichen Vor- oder Nachnamen haben, somit wäre vorname und nachname nur _zusammen_ eindeutig.

Ich kann in diesem Beispiel aber keine tansitiven Abhaengigkeiten erkennen, behaupte also, dass diese Tabelle zumindest mal der 3 NF entspricht.

Waerst du so nett, mich vom gegenteil zu ueberzeugen?

Goos

[ksg9-sebastian]

http://de.wikipedia.org/wiki/Prim%C3%A4rschl%C3%BCssel

Die Grafiken (a, b, c) zeigen genau das was ich versucht habe zu erklären.

Die Datensätze sind nicht eindeutig anhand des Vornamens ODER Nachnamens, deshalb kann man Vorname und Nachname auslagern und in der Personentabelle dann nur die beiden IDs festhalten.

[Goos]

Die Grafiken (a, b, c) zeigen genau das was ich versucht habe zu erklären.

Was soll das bitte mit Normalisierung zutun haben?

Da gehts doch nur um die Vergabe von Schluesseln.

Die Datensätze sind nicht eindeutig anhand des Vornamens ODER Nachnamens, deshalb kann man Vorname und Nachname auslagern und in der Personentabelle dann nur die beiden IDs festhalten.

Den Sinn hinter diesem Satz versteh ich nicht.

Die Datensaetze muessen doch auch nicht eindeutig sein anhand der Namen...dafuer hats doch die ID.

Ich halte die Auslagerung von Vorname und Nachname also aufrgund von Normalisierungsbestreben noch immer fuer voellig sinnbefreit

Goos

[mme]

Aus meiner Sicht ist das eine fehlinterpretation der 3.NF. Jede Spalte soll nur vom Primärschlüssel abhängen und nicht von einer anderen Spalte. Wenn ich den Vornamen betrachte hat dieser keine Abhängigkeit vom Nachnamen und andersherum. Wo also ist das Problem?

Sonst müsste man ja auch noch das Geburtsdatum auslagern weil theoretisch könnten ja zwei Perosnen am gleichen Tag geburtstag haben. Auch das Argument die Person ist nicht eindeutig über Vorname oder Nachname identizierbar kann ich nur sagen darum geht es bei der Normalform nicht und wenn dem doch so währe, ist die Person auch sowieso nicht eindeutig über Vor- und Nachname identifiezeirbar. Dafür bräuchte man noch geburtsdatum und geburtsort...

[mme]

Kurz noch ein Bsp.:

Eine Strasse ist abhängig vom Ort weil es nur bestimmte Strassen im Ort gibt (Vorgegebee Kombinationen).

Ein Vorname ist nicht abhängig vom Nachnamen, es gibt keine vorgegebenen Kombinationen, jede Kombi ist möglich.

[Goos]

Aus meiner Sicht ist das eine fehlinterpretation der 3.NF. Jede Spalte soll nur vom Primärschlüssel abhängen und nicht von einer anderen Spalte. Wenn ich den Vornamen betrachte hat dieser keine Abhängigkeit vom Nachnamen und andersherum. Wo also ist das Problem?

Sonst müsste man ja auch noch das Geburtsdatum auslagern weil theoretisch könnten ja zwei Perosnen am gleichen Tag geburtstag haben. Auch das Argument die Person ist nicht eindeutig über Vorname oder Nachname identizierbar kann ich nur sagen darum geht es bei der Normalform nicht und wenn dem doch so währe, ist die Person auch sowieso nicht eindeutig über Vor- und Nachname identifiezeirbar.

Ok, du hasts begriffen

Wieso aber nehmen verschiedene Leute immer wieder mal gerade dieses Name, Vorname Beispiel fuer Normalisierung her, obwohl es nichts damit zutun hat?

Dafür bräuchte man noch geburtsdatum und geburtsort...

Selbst das wuerde nicht wirklich helfen, es sei denn man fuehrt da noch Fingerabdruecke, DNA oder aehnliches ein. Ansonsten langt es aber doch auch, wenn eine Person ueber die ID eindeutig zu identifizieren ist.

Goos

[ksg9-sebastian]

ja..das beispiel mit vorname/name war dämlich

Straße/Ort ist ein besseres Beispiel für die 3. NF

[Goos]

Straße/Ort ist ein besseres Beispiel für die 3. NF

Noe, taugt auch nicht.

Ein Strassenname ist nicht abhaengig vom Ort, also taugts nicht fuer die 3. NF.

Es gibt die Schillerstrasse halt nicht nur in Monopolytown, sondern auch in Muenchen (schaetz ich mal). Deshalb kann man nicht sagen, dass in einem Schillerstrasse Datensatz immer auch Monopoly stehen muss

Goos