planlos0815 Geschrieben 22. März 2011 Teilen Geschrieben 22. März 2011 Hallo Leute, Folgender Fall: In Access XP habe ich eine Tabelle "Kunde". Es gibt eine Kundennummer (Schlüssel), Name, Straße, PLZ und Ort. Eine zweite Tabelle "Postleitzahlen" hat 2 Spalten: PLZ und Ort. Diese Tabelle kann keinen Schlüssel haben, da es Postleitzahlen gibt, für die es mehrere Orte gibt, und Orte, die mehrere PLZ haben. In der Tabelle Kunde kann ich über ein Drop-Down-Menü Postleitzahlen auswählen (Nachschlagen im Entwurf der Tabelle). Lege ich nun eine Abfrage an, in der ich die Kundendaten und zusätzlich den Ort aus der PLZ-Tabelle eintrage, kann ich in der Abfrage keine neuen Datensätze erfassen. In der Abfrage sind die beiden Tabellen natürlich miteinander verbunden. Würde ich in der Tabelle PLZ die PLZ als Schlüssel definieren, kann ich in der Abfrage neue Daten eingeben - aber das geht eben nicht. Irgendwelche Lösungsvorschläge? Danke Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
raiserle Geschrieben 22. März 2011 Teilen Geschrieben 22. März 2011 Dann ist nach deiner Ansicht .. dein DB-Modell flasch. Denn wenn du schon sagst, es "KANN" n:m Beziehungen bei PLZ+Ort geben, musst du dies auch auflösen. Hier musst du dann eben bei deinem DropDown etwas mehr machen. Oder du machst es einfach .. und vergibst pro Tupel in der PLZ_ORT Tabelle einfach einen (ID) Primärschlüssel. Es kommt nun darauf an, wie kompliziert du es machen willst. Oder was du mit den Daten bezwecken willst - bzw. wie du sie weiter verarbeiten willst. vG Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
planlos0815 Geschrieben 22. März 2011 Autor Teilen Geschrieben 22. März 2011 n:m Beziehung? Das habe ich so nicht gesagt. Es ist nicht möglich, in der Tabelle PLZ EINEN Primärschlüssel zu vergeben. Beispielsweise hat Dresden unter Anderem die Postleitzahlen 01462 und 01465. Schönfeld und Tauscha haben beide 01561. Nicht schön, ist aber so. Vergebe ich einen Primärschlüssel, der beide Felder beinhaltet (jedes Tupel kommt exakt ein mal vor) habe ich das selbe Phänomen. Ich möchte in de Abfrage neue Kunden eingeben, wobei ich die Postleitzahl aus einem Dropdown auswählen (Nachschlagen) will, der Ort soll gefunden werden. Ist die Postleitzahl nicht eindeutig, so soll eine Auswahl möglich sein. Welcher Fehler steckt dann im Datenmodell? Dass ich etwas an meinem Dropdown machen muss, ist mir klar - nur was? Danke Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
flashpixx Geschrieben 22. März 2011 Teilen Geschrieben 22. März 2011 In diesem Fall ist die Kombination aus PLZ und Ort eindeutig, d.h. Du musst eben bei Eingabe einer Ziffer eben die Spalte mit den PLZ durchsuchen und bei Eingabe eines Buchstabens die Spalte mit den Orten und eben diese in der Dopdownbox anzeigen. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
raiserle Geschrieben 22. März 2011 Teilen Geschrieben 22. März 2011 (bearbeitet) Stimmt - du hast n:m nicht gesagt, aber du hast es beschrieben! Das ist der Fehler! Wenn du sagst, dass eine Plz mehrmals für einen Ort und ein Ort mehrmals für eine Plz vorkommt... also ich glaub nicht, dass es KEINE n:m ist!!! Erst denken - dann MEKERN! Bei deinem Vorhaben, über DD die PLZ auszuwählen - und dann ggf ein bzw mehrere Ort auszuwählen - ist genau mit der N:M - sowie mit der ID für jedes Tupel machbar. Wobei bei der n:m sollte dann die Tabelle - die die n:m Beziehung darstellt einen EINDEUTIGEN Schlüssel haben. Sonst bist du gezwungen beide Schlüssel in die Kundentabelle einzutragen. Aussehen könnte es so: Mit diesem DB-Model sollte es am einfachsten gehen. Hiebei musst du nicht mal viel ÜBERLEGEN. Für das DD holst du alle Tupel aus der PLZ und kannst sie im DD darstellen.... auswählen aund dann einen SELECHT mit der gewählten PLZ auf die N:M Tabelle. Nachtrag @flashpixx: Das wiederspricht jeder Normalisierung. Und er hatte am Anfang ja auch schon gesagt, dass es n:m ist. Also beschrieben - nur könnte er es eben so - oder so lösen. Entweder einen EINDETIGEN schlüssel für jedes Tupel - oder die Variante ... in diesem Post. Bearbeitet 22. März 2011 von raiserle zwischenzeitliches Posting Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
flashpixx Geschrieben 23. März 2011 Teilen Geschrieben 23. März 2011 Das wiederspricht jeder Normalisierung. Und er hatte am Anfang ja auch schon gesagt, dass es n:m ist. Also beschrieben - nur könnte er es eben so - oder so lösen. Entweder einen EINDETIGEN schlüssel für jedes Tupel - oder die Variante ... in diesem Post. Ich habe nichts über einen Schlüssel gesagt. meine Aussage ist nur, dass die Kombination, also das Tupel von Ort & PLZ eindeutig ist. Außerdem habe ich auch keine Aussage über irgendwelche Referenzen zu anderen Entities beschrieben o.ä. So dass ich mit meiner Aussage nicht gegen die Normalisierung verstoße. Wobei ich zu einem abstrakten Primärschlüssel, den als FK aus den anderen Tabellen referenziere, greifen würde und zusätzlich Ort & PLZ als eindeutigen Schlüssel führen würde. Möchte man keinen abstrakten Schlüssel als PK einführen, empfehle ich die GKZ (Gemeindekennzahl / -ziffer). Diese Nummer ist eindeutig und setzt sich aus Bundesland, Kreis etc zusammen, siehe Amtlicher Gemeindeschlüssel ? Wikipedia Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.