Office: Neues Datenmodell bewerten

Öhmmm?*weinen

wie bitte mache ich das? Zusammengesetzter PK ist mir ja klar, aber FK in tbl_PersonenBanken: PersonID + PersonartID nicht so unbedingt! *Smilie


Ach ja... BankID...KundeID...wird nicht benötigt. Also im obigen Absatz wäre also die PersonID auch mein PK !

 

Wenn du die Beziehung über das Beziehungsfenster erstellst, dann musst du im Dialog "Beziehungen bearbeiten" alle benötigten Felder auswählen.

Vielleicht hilft dieser Thread ein wenig weiter: Tabellen normalisieren #11ff (dort schlug ich einen 3-Felder-FK vor. *wink.gif*)

 

Ich komme nochmal auf meinen Vorschlag #9 zurück. Ich glaube nämlich, daß Deine Struktur nicht einfach genug ist. Wenn die Tabellen nachher abgefragt werden sollen wird das entsetzlich kompliziert und damit fehlerträchtig.

 

\@achtelpetit: so ganz kann ich nicht nachvollziehen was Du meinst. Wie einfacher...

Ich versuche gerade Josefs Vorschlag umzusetzten.... dann sehen wir mal weiter... und irgendwie habe iich da ein Prob mit...ich wil mals sehen und testen...

 

\@Josef: habe mir jetzt den Thread angeschaut, aber so ganz schlau werde ich daraus nicht.

Er meckert schon bei dem Versuch, eine zweite Beziehung zwischen tbl_Personen Detaisl ind tbl_PersonenBanken zu erstellen.

In Bezug auf tbl_PersonenBanken sieht es jetzt wie in angehängten Bild aus.......

 

...die Grafik...

 

Ich sehe 5 Tabellen, die in einer 1:1-Beziehung zu einer anderen Tabelle stehen. Insoferne vereinfachen.
Aber viele Köche verderben den Brei, außerdem hat Joseph P. viel mehr Ahnung als ich. Wenn er das okay findet wird's wohl so sein.

 

Oder auch nicht. *biggrin.gif*
Es muss überhaupt nicht richtig sein, wie ich das vorschlug. Nur kann ich das nicht beurteilen, das muss SaschaBHH machen.
Es kommt ganz einfach auf die exakten Anforderungen an. Wenn z.B. sichergestellt sein muss, dass nur bestimmte Detail-Tabellen (*Banken, ...) befüllt sein dürfen, dann fällt mir momentan nur die zuvor erwähnte Variante ein. Man wird zwar mit Access-Tabelle immer noch keine Vermeidung von "verbotenen" Kombinationen (wie von Thomas erwähnt) zusammenbringen, aber die Prüfung könnte etwas einfach sein, da sie sich nur auf eine Tabelle bezieht.
Wenn es egal ist welche Beziehungn zw. tbl_Personen und den Detail-Tabellen exisitieren, dann kann - wie auch schon erwähnt - auf tbl_PersonenDetails ganz verzichtet werden.

Zur Sicherheit noch einmal: tbl_PersonenDetail dient nur zum Umsetzen der Regeln. Für Auswertungsabfragen wird sie vermutlich selten benötigt werden, da über PersonenID bereits eine 1:1/0-Beziehung zw. tbl_Personen und tbl_PersonenBanken usw. nachgebildet werden kann.

Du sollst auch keine 2. Beziehung erstellen, sondern die erste auf 2 Felder erweitern. *Smilie
Noch etwas ist wichtig: Beachte bei dieser Beziehung die Richtung. Die PK-Seite muss tbl_PersonenDetails sein. (Im Bild kommt mir das so vor, als wäre tbl_PersonenBanken die PK-Seite.

 

Hi,

das mit dem erweitern der Beziehung habe ich getestet, aber dann meckert er ein fehlenden eindeutigen Schlüssel auf der Primärseite an.

Jetzt:

tbl_Personendetails = PK=> (PersonArtID+PersonID)
tbl_PersonenBank = PK => (PersonArtID+PersonID)

In diesem Fall kann ich die Beziehung erweitern. Ergebnis im Anhang.

 

Ich probierte das jetzt aus: da sieht man wieder einmal wie doof Access ist bzw. wie ursuper die Benutzerwünsche umgesetzt werden.
Access ignoriert nämlich in diesem Fall die Verknüpfungsrichtung, weil es anscheinend der "Meinung" ist, dass in diesem Fall tbl_PersonenBanken die PK-Seite ist, weil PersonID der PK ist. => man kann diese Verknüpfung nur erstellen, wenn man in der Tabelle tbl_PersonenBanken den PK entfernt, die Beziehung erstellt und dann erst den PK setzt.
Oder: einfach per DDL durchführen. *Smilie
Code:

 

Das hast Du richtig gesehen, vermute ich. Ich kann aber als Primär Seite nur tbl_PersonenBanken einstellen.. liegt das am zusammengesetzten PK in tbl_PersonenDetails?

...da hat sich jetzt was überschnitten... ich teste mal Deine Idee...

 

Also irgendwie ist der Wurm drin:

"Es wurde kein eindeutiger Index für das in Beziehung stehende Feld der Primärtabelle angegeben"

Das passiert beim DDL Versuch oder auch "Manuell". Die Primärseite ist ja "tbl_Personendetails". Beide Felder zusammen bilden ja den PK. Jedes Feld ist indiziert mit Duplikate möglich. Wo ist der böse Wurm???

 

Auf die Gefahr hin, mich unbeliebt zu machen.
Die Struktur ist für mich nicht einleuchtend. Wo ist der Unterschied zwischen "Personen" und "Personen1"?
Ich vermute, der Finanzmakler will Vertragspartner verwalten. Es gibt also Personen (natürliche oder juristische) die irgendeinen Vertrag haben, für den der Makler verantwortlich ist. Daraus resultieren 2 Tabellen: Adressen (die Bezeichnung scheint mir klarer als "Personen") und Verträge.
Jetzt will man die Art des Vertrages bezeichnen daraus resultiert die Tabelle "Vertragsarten".
Eine der Adresse (oder viele) stellen eine Bank dar, die Bank hat einen oder wahrscheinlich mehrere Nominalzinssätze, also Tabelle Zinsen.
Der Sozialstatus soll klassifiziert werden, das gibt eine weitere Tabelle. Und nach diesem Schema kanns weitergehen.
Kurz und gut, mir fehlt bei der vorgestellten Struktur die Mitte. Das läßt sich so nur sehr schwer erweitern oder anpassen. Gerade in diesem Gewerbe dürften Erweiterungen und Änderungen aber an der Tagesordnung sein.

 

\@achtelpetit:

Keiner der hilft, macht sich unbeliebt. Auch Du nicht.

Da gibt es keinen. tbl_Personen_1 ist der Alias für tbl_Personen. Sprich die physikalsich gleiche Tabelle kommt 2 x im Layout vor. Hier ist das durch die reflexive (auf sich selbst beszogen) m:n Beziehung über tbl_PersonenBeziehungen entstanden.

Warum Personen und nicht Adressen oder auch Kontakte genannt.

Eine Adresse beschreibt für mich eine Anschrift zu einer Person. Und wenn ich mich Frage "Wie nehme ich Kontakt" zu einer Person auf, dann würde ich antworten "über Telefon" oder "Email". Deshalb habe ich Person als Bezeichnung gewählt, weil das für mich am eindeutigsten war/ist.

Da hast Du mein Modell nicht richtig gelesen. Der Kunde wird klassifiziert (A,B oder C-Kunde) und hat auch einen Sozialstatus "Renter", "Arbeitnehmer" o.ä.

Bei dem Thema war ich noch garnicht. Ich will erstmal das Modell um die "Personen" stehen haben... dann folgen die nächsten Schritte... und das sind noch eine Menge...glaube mir.

 

Hast du möglicherweise im PK die Felder anders sortiert? ... PersonArtID-PersonID statt PersonID-PersonArtID?