Veröffentlicht 10. November 200519 j 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
10. November 200519 j Ich versteh dein Problem gerade nicht.. Warum musst du die ID von Namen und Vornamen trennen ? Die sind doch beide Abhaengig von der ID...
10. November 200519 j 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?!
10. November 200519 j 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.
10. November 200519 j Das Problem hat sich gerade erledigt. ich habe zu sehr um die Ecke gedacht... Vielen Dank für die Antworten. Gruss Dragi
10. November 200519 j 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
10. November 200519 j 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
10. November 200519 j 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
10. November 200519 j 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
10. November 200519 j 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).
10. November 200519 j man kann sich auch kaputt normalisieren... man sollte Datenaufkommen vs. Performance gegenüber stellen......
10. November 200519 j Wie gesagt ist es ja nur ein Beispiel um Normalisierung anwenden zu lernen. In einem Projekt würde ich das auch nicht machen! Dragi
10. November 200519 j 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...
11. November 200519 j 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
11. November 200519 j 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 [..]
11. November 200519 j 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
11. November 200519 j 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.
11. November 200519 j 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
11. November 200519 j 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...
11. November 200519 j 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.
11. November 200519 j 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
11. November 200519 j ja..das beispiel mit vorname/name war dämlich Straße/Ort ist ein besseres Beispiel für die 3. NF
11. November 200519 j 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
Archiv
Dieses Thema wurde archiviert und kann nicht mehr beantwortet werden.