nicht angemeldet
Hallo, bin zwar nicht Ekki ... aber egal.
Wenn ich dein Problem richtig verstanden habe, dann würde ich folgendes zu Kunde geben:
- Adresse ist Adresse, eine Adresse selbst sollte nicht durch einen kontext-losen Typen klassifiziert werden
- stattdessen sollte die Klassifizierung im Kontext erfolgen, und dieser ist "RECHNUNG"
d.h. entweder du legst mehrere Spalten an wie in deinem Beispiel oder du erzeugst eine Tabelle zwischen Rechnungen und Adressen, bestehend aus "Rechnungs_ID", "Adressen_ID" und "Adressen_Typen_Id" ... mit drei Fremdschlüsseln. Solange es genau nur 2 Möglichkeiten gibt, würde ich subjektiv den Ansatz mit den Spalten wählen. Beim geringsten Verdacht auf eine unbekannte Anzahl von Möglichkeiten, würde ich die Zwischentabelle als Ansatz wählen.
Mach dir doch mal ne Zeichnung, ein Böxchen für jede Entität (Kunde, Rechnung, Adresse), dann malst du einfach Linien zwischen die Böxchen, wo beide Dinge ein reales Verhältnis zueinander haben. Und dann fügst du die Kardinalität an jedes Verbindungslinienende an, z.B:
Ein (Kardinalität: 1) Kunde kann viele (Kardinalität: n) Adressen haben
Ein (Kardinalität: 1) Kunde kann viele (Kardinalität: n) Rechnungen haben
Eine Rechnung (1) kann nur an einen (1) Kunden geschickt werden
Eine Rechnung (1) kann an eine oder mehrere (falls das für dich Sinn macht) Adressen geschickt werden, alle Adressen müssen aber zum selben Kunden gehören.**
1:n Beziehungen sind in der Regel "Parent(Vater)-Child(Kind)-Beziehungen" und werden durch einen Fremdschlüssel in der Child(Kind)-Tabelle realisiert.
m:n Beziehungen, im konkreten Fall wäre Rechnung zu Adresse eine solche, werden mit Zwischentabellen realsisiert. ggf sind zusätzliche Beschränkungen oberhalb der referentiellen Integrität von dir zu implementieren um geschäfts-logische Fehler und Inkonsistenzen zu vermeiden
** diese Beschränkung musst du u.U. ausserhalb der Datenbank in deiner Geschäftslogik gewährleisten.
Cheers, Frank