Konzeptionelle Frage: 2 Vatertabellen... ?

Hallo,

Ich habe ein „konzeptionelles“ Problem und kann das leider nciht selber lösen, da ich mich da mit den theoretischen Aspekten nicht auskenne.

Ich habe eine Tabelle „Versand“ die alle Infos zu einem versendten PAket beinhaltet (DAtum, Versanddienstleister, TrackingID) etc.

Diese Tabelle hat nun zwei Foreign Keys einmal zu einer einer "Bestellung"sTabelle und einmal zu einer „Werbepräsentbestellung“ Tabelle. ("Vater"tabellen)
Wenn nun ein Werbepräsent bestellt wird bekommt die „Versand“ Tabelle den entsprechenden Primary Key der „Werbepräsentbestellung“ eingetragen, wie das eben bei Relationen so der FAll ist. Wenn eine normale Bestellung stattfindet bekommt der entsprechende ForeignKey die ID der normalen normale Bestellung… = typische Foreign Key Relation…

(Dies ist vereinfacht, man könnte evtl. auch Werbepresentbestellung als normale Bestellung ansehen und damit würde diese Tabelle wegfallen. DAs ganz ist jedoch nur exemplarisch um mein Problem aufzuzeigen, da die Anwendung selbst wesentlich komplexer ist…)

Meine Frage ist nun, „irgendwie“ denke ich, dass das aber nicht richtig ist, dass eine Versandtabelle zwei ForeignKeys hat, wovon immer eine definitiv den Wert „Null“ hat: Wenn ich ein Werbepräsent versende dann hat der NormaleBestellungs Foreign Key = Null und wenn ich eine Normale Bestellung versende dann hat der Werbepräsent Foreign Key = Null.
Das hört sich für mich irgendwie nach nicht richtig normalisiert an, mir fehlt aber das Wissen um da festzustellen was und ob das nun „falsch“ ist bzw. was die richtige Lösung ist.
(In dem Beispiel oben muss ein Foreign Key der Versandtabelle eigentlich immer auf eine Bestellung verweisen und somit dürfte der Foreign Key niemals Null sein. Mit der Lösung oben kann ich aber keine Constraints setzen da, da ja immer doch einer der beiden Foreign Keys null ist…)

Theoretisch wäre es möglich, die Versandtabelle zu duplizieren und einmal eine „WerbepräsentVErsand“ TAbelle anzulegen und einemal eine „(Normale)BestellungVersand“ Tabelle. Dann könnte man den jeweils zweiten ForeignKey weglassen und hätte nur noch den „richtigen“ Foreign Key in der Tabelle. DAnn hat man aber zwei mehr oder weniger identische Tabellen??? (Ist das der richtige Lösungsansatz?)

Oder macht es Sinn hier mit einer Relationen Tabelle zu arbeiten die zwischen einer einzelne Versandtabelle geschaltet wird und dann die Primary Keys von allen Drei Tabellen beinhaltet.

Bin für Tips und Hinweise sehr dankbar !!!

Julian

Hallo,

ich denke, Dein Problem besteht aus der Abgrenzung der Bestellung und der Werbebestellung.

Fall 1: Beide haben identische Daten, dann würde ich eine Tabelle nehmen, die ein Attribut isWerbeBestellung hat.

Fall 2: Eine der Bestellungen erweitert die Attribute. Dann würde ich dies auch so modellieren. (z.B. Werbebestellung erwitert Bestellung)

Versand – Bestellung – Werbebestellung

Die Werbebestellung enthält dann nur noch die erweiterten Attribute.

Fall 3: Es gibt bei beiden gemeinsame und unterschiedlichen Attribute. Dann würde ich die gemeinsamen in eine Tabelle AbstractBestellung legen und Bestellung und Werbebestellung mit dieser verbinden.

Man sollte aber ein laufendes System nicht ohne Not ändern. Wenns also um Kosmetik geht - kannst Du es Dir auch sparen.#

Gruß

Peter

Hallo Peter,

erstmal vielen Dank für deine Antwort die mir sehr geholfen hat. Ein Problem konnte ich damit super gut lösen!

Bei einer anderen Tabelle ist mir allerdigns wieder zumindest ein „optisches Problem“ aufgefallen. Ich habe eine „Kommentartabelle“ die mindestens 10 anderen Tabellen „1 zu n“ Verknüpft ist.

Ca Beispiel „Kommentar-Tabelle“:
KOM_ID_PK
KOM_KOMMENTAR;
KOM_DATUM;
KOM_KUNDE_ID_FK;
KOM_BESTELLUNG_ID_FK;
KOM_LIEFERUNG_ID_FK;
KOM_RECHNUNG_ID_FK;
…ID_FK;
und so geht das immer weiter mit den ID_FKs (Fremdschlüsselverknüpfungen).

Ist das a) so richtig, dass man diese ganzen FKs in der Kommentartabelle sind?
(Ich könnte ja alternativ auch eine Kommentartabelle für jeden Kommentartyp z.B. „Rechnungskommentar“ anlegen) Oder sollte man dieses „Problem“ auch durch Eine Basis-Tabelle oder Abstract-Tabelle die dann „vererbt“ wird lösen, so wie du das aufgezeigt hast?)

Vielen Dank! und viele Grüße Julian.

PS. hast du vielleicht auch einen guten Buchtip für mich, wo genau sowas praxisorientiert erklärt wird.
(Ich habe dieses „Datenbanken: Konzepte und Sprachen“ Buch, dort wird allerdings nicht so richtig auf derartige Probleme eingegangen, obwohl es sonst sehr gelobt wird…(zumindest bei Amazon…))

Hallo,

Dein Problem stößt schon etwas an die Grenzen des relationalen Modells. Die puristische Lösung ist sicherlich viele einzelne abhängige Tabellen oder eine Tabelle vorzuschalten. Bei der Bedienung wirst Du aber schnell merken, dass das unnötig kompliziert wird.
Noch sauberer - und völlig unbedienbar - ist dann die innere Tabelle. Finger weg.
Warum benutzt Du zeilenweisen Text. Das kannst Du doch viel besser in ein LONG Feld speichern. Dann wäre der Text an der Tabelle als Attribut mit dran.

Bei einer anderen Tabelle ist mir allerdigns wieder zumindest
ein „optisches Problem“ aufgefallen. Ich habe eine
„Kommentartabelle“ die mindestens 10 anderen Tabellen „1 zu n“
Verknüpft ist.

Ca Beispiel „Kommentar-Tabelle“:
KOM_ID_PK
KOM_KOMMENTAR;
KOM_DATUM;
KOM_KUNDE_ID_FK;
KOM_BESTELLUNG_ID_FK;
KOM_LIEFERUNG_ID_FK;
KOM_RECHNUNG_ID_FK;
…ID_FK;
und so geht das immer weiter mit den ID_FKs
(Fremdschlüsselverknüpfungen).

Ist das a) so richtig, dass man diese ganzen FKs in der
Kommentartabelle sind?
(Ich könnte ja alternativ auch eine Kommentartabelle für jeden
Kommentartyp z.B. „Rechnungskommentar“ anlegen) Oder sollte
man dieses „Problem“ auch durch Eine Basis-Tabelle oder
Abstract-Tabelle die dann „vererbt“ wird lösen, so wie du das
aufgezeigt hast?)

Vielen Dank! und viele Grüße Julian.

PS. hast du vielleicht auch einen guten Buchtip für mich, wo
genau sowas praxisorientiert erklärt wird.
(Ich habe dieses „Datenbanken: Konzepte und Sprachen“ Buch,
dort wird allerdings nicht so richtig auf derartige Probleme
eingegangen, obwohl es sonst sehr gelobt wird…(zumindest bei
Amazon…))

Gute Bücher gibts viele. Kommt drauf an, wie gut Du bist.

Thomas Kyte: Expert Oracle One-on-One
Thomas Kyte Oracle Performance by Design

sind zwei (englische) Bücher, die wirklich gut sind, aber auch nicht ganz einfach. Tomas Kyte ist asktom.oracle.com. DER Oracle Spezialist.

Kemper/Eickler Datenbanksysteme. (Uni Niveau eben auch)

Oracle und Java (Markt und Technik) gibts bei terrashop für 15 Euro. Ein echtes Schnäppchen. Sonst kostet es gut 70 Euro. Viele gute Beispiele, die auch funktionieren.

Überhaupt gibts bei terrashop einiges für den schmalen Geldbeutel.

Gruß

Peter