Derzeit habe ich 5 Tabellen. Ich bin mir unsicher, wie ich die Beziehungen untereinander setzen muss.


1. Zu jedem Datensatz in Customer muss es einen Ansprechpartner (ContactPerson) und eine Anschrift (customerAddress) geben.
2. Zu jedem Customer/zu jeder Adresse kann es eine/mehrere Bankverbindung(en) (customerAccount) geben.
3. Zu jedem Customer können Vorgänge (Processe) erstellt werden. Ein Ansprechpartner aus ContactPerson muss ausgewählt werden. Es soll später möglich sein, alle Vorgänge zu einem Ansprechpartner zu filtern. Ebenso soll es möglich sein, alle Vorgänge zu einem Customer zu filtern.

Was muss ich beachten bzw. wie sind die Beziehungen am sinnvollsten zu setzen?

Wenn es zu jedem Datensatz nur einen verknüpften Datensatz gibt, dann ist der verknüpfte Datensatz in einer übergeordneten Tabelle.

Ist in deinem Fall Unfug, denn Kontaktperson und Addresse sind schlicht Eigenschaften von Customer und müssen also in dieselbe Tabelle.
Wäre vlt. schön, wenn Dataset auch 1:1 - DataRelationen unterstützen würde, tut es aber nicht.
Deshalb: die Tabellen KontaktPerson und Addresse auflösen, und die Eigenschaften in Customer einreihen.

Deine 3. Anforderung führt auf ein komplizierteres Modell: Scheinbar kann ein Kunde mehrere Ansprechpartner haben, also für den einen Prozess mag beim selben Kunden Kunde1.A der Ansprechpartner sein, für einen anneren Prozess beim selben Kunden ist Ansprechpartner aber Kunde1.B

Ist das realistisch??
Normaler ist doch wohl ein Ansprechpartner pro Kunde.

Heee, Danke zunächst für Deine Antwort.

ErfinderDesRades schrieb:

Deshalb: die Tabellen KontaktPerson und Addresse auflösen

Es soll möglich sein, mehrere Adressen des Kunden zu speichern. Deshalb wird die Tabelle "customerAddress" sicherlich nicht entbehrlich sein!?

Die Kontaktperson ist eine Person beim Kunden. D.h. im Kundendatensatz soll ersichtlich sein, wer direkter Ansprechpartner beim Kunden für das Anliegen ist. Da nicht jedes Anliegen von einem und dem selben beauftragt wird, kann es mitunter mehrere Ansprechpartner geben.

na schön, dann haben deine Kunden eben mehrere Addressen - kann mir ja egal sein, wie du klärst, an wen die Rechnung gehen soll

Deiner beschreibung nach benötigst du dann zwei Datarelations:
Customer->Process
ContactPerson->Process

Dann ist das modelliert, was du beschreibst.


annere Frage: Warum hat customer bei dir einen zusammengesetzten Primkey?

Was ich ühaupt sehr empfehle: Erstmal natürlich durchgängig Großschreibung von TabellenNamen.
und dann mein Benamungs-Schema für DB-Entitäten - also jeder Primkey heißt einfach "ID", und die ForeignKeys heißen wie die verwiesenen Tabelle + "ID".

ErfinderDesRades schrieb:

annere Frage: Warum hat customer bei dir einen zusammengesetzten Primkey?

Hab'sch vorhin auch gesehen... Ist aber zwischenzeitlich schon entfernt. Da habe ich einen Fehler gemacht.
Hm.... Und wie stelle ich es nun an, dass ich Vorgänge sowohl nach Kunden als Ansprechpartner filtern kann?

Hab's jetzt erstmal so geändert wie Du gesagt hast...

customer ist weiterhin klein geschrieben, und die DataRelation
Contact->Process
hast du wohl vergessen.

nochmal: Du tust dir sehr einen Gefallen, vernünftig zu benamen. Wieso hat Customer eine MasterID?
Warum hat Contact eine MasterID, aber keine CustomerID?

usw.

ach - und Contact hat jetzt ühaupt kein Primkey mehr - also so wird das nix - da muß man schon bisserl pingeliger sein.

Ooops.
So meinst Du? Die Benamung der Relationsbezeichnungen lasse ich einfach wie vorgegeben...

jo, die Beziehungen verlaufen richtig. Nur weil du in deinen Benamungen so schlampig bist, ists mir unmöglich, zu erkennen, mit welcher Spalte Process auf Customer verweist, und mit welcher es auf Contact verweist.

Okay....

1. Tbl_CUSTOMER(MasterID) -> Tbl_PROCESS(MasterID)
2. Tbl_CUSTOMER(MasterID) -> Tbl_CONTACTPERSONMasterID)
3. Tbl_CONTACTPERSON(MasterID) -> Tbl_PROCESS(MasterID)

mach das besser im typDataset.
Und verzichte drauf, vor jeder Tabelle diesen blöden Präfix "TBL_" zu setzen.
Mit Grossschreibung meine ich auch nicht alle Buchstaben, sondern nur den ersten, also PascalCase, um genau zu sein.

Und jetzt scheinen sie alle eine MasterId zu haben, aber ich finde überhaupt keine Tabelle namens "Master" - also ich werds langsam müde.

Ja, Programmierer sind kreativ, und müssen immer alles anners machen, als man ihnen vorsagt, aber kann man nicht einfach mal spaßeshalber es vorläufig mal ausprobieren, wie es wäre, wennmans so machte, wies gesagt wurde?
Danach, wenndes anners besser findest, kannste ja immer noch iwelche SpaltenNamen dir ausdenken, deren Bezug nicht nachvollziehbar ist, und Sonderzeichen reinfrickeln, plural flexieren und wasses alles gibt, um ein Datenmodell zu verwüsten.

Mach doch einfach mal die Benamung nach dem Schema, wassich gesagt habe: Primkeys heißen "ID", und ForeignKeys heißen <ParentTable>+"ID".
Dann wird dir auch automatisch auffallen, dass du derzeit 2 Datarelations mit demselben ForeignKey zu bedienen versuchst - was natürlich nicht gehen kann.

Und dass das dir dann auffällt ist wieder ein Zeichen dafür, dass mein Schema nicht ganz so blöde ist, wies offenbar auszusehen scheint.

Okay. Ich kann nachvollziehen, was Du mir damit sagen möchtest. Ich habe eben schnell einfach mal ein neues Projekt erstellt. Dort verwende ich ein typ. Dataset und habe jetzt Folgendes designt:

Und wie stelle ich es nun an, dass ich Vorgänge sowohl nach Kunden als Ansprechpartner filtern kann?

Process und Contact haben schon wieder keine ID.
Und die eine DataRelation haste schon wieder vergessen.

Na gut, also. Ich habe beiden Tabellen noch die nötigen ID's hinzugefügt. Wahrscheinlich ist wieder irgendetwas falsch... Zwischen welchen IDs soll aber nun die Beziehung hergestellt werden; das ist ja die Ausgangsfrage...

Hallo,

wie wäre es von ProcessID -> Process

MFG

Alex-Digital

Heeee
Das hätte zur Folge, dass "Process" der Tabelle "ContactPerson" untergeordnet ist. Vielleicht liege ich da mit meiner Logik falsch, dass soll sie aber nicht. Bei jedem Process wird lediglich ein Name aus "ContactPerson" gewählt. Später soll es möglich sein, über den Namen alles "Processe" zum Ansprechpartner ("ContactName") zu filtern.

#Habe die Lösung zu meiner Frage gefunden. Danke für eure Hilfen.