[Oracle] Foreign Key aus mehreren Tabellen

Computer: Software & Programmierung Datenbanken allgemein
#1

Hallo Leute,

schon wieder ich mit einem Oracle-Problem.

Und zwar habe ich eine Tabelle die Foreign Keys auf insgesamt 23 andere Tabellen benötigt.

Der PK der anderen Tabellen besteht aus jeweils drei Feldern, d. h. wenn ich jetzt für jede Tabelle einen eigenen Foreign Key mache, dann brauche ich alleine dafür 69 Felder, das würde ich gerne vermeiden.

Da die PKs aller Tabellen gleich aufgebaut sind dachte ich mir ich könnte vielleicht nur drei Felder als Foreign Key verwenden und den Constraint praktisch so legen, dass er nur eine von den Tabellen referenzieren muss.

Die Frage ist jetzt wie ich so einen Constraint erzeugen kann.

Alternative wäre natürlich ein Insert-Trigger der das überprüft, aber das würde ich gerne vermeiden.

Danke und Grüße,
Robert

#2

Hi,

Und zwar habe ich eine Tabelle die Foreign Keys auf insgesamt
23 andere Tabellen benötigt.

ei. Bist Du sicher, dass das DB-Layout optimal ist?

Der PK der anderen Tabellen besteht aus jeweils drei Feldern,
d. h. wenn ich jetzt für jede Tabelle einen eigenen Foreign
Key mache, dann brauche ich alleine dafür 69 Felder, das würde
ich gerne vermeiden.

Verständlich. Nimm als PK eine zusätzliche Spalte (ID), die über eine Sequenz gefüttert wird; und mach über die drei anderen Spalten einen Unique Index.

Da die PKs aller Tabellen gleich aufgebaut sind

Sie haben aber unterschiedliche Inhalte. Falls nicht, ist Dein DB-Layout _nicht_ optimal :smile:

Cheatah

#3

ei. Bist Du sicher, dass das DB-Layout optimal ist?

Das Problem ist, dass das DB-Layout eine Abbildung eines Objektmodells sein soll.

Die eine Tabelle stellt eine Buchung dar, die vielen anderen Tabellen sind Geschäftsfälle zu denen die Buchung gehören kann.

Im Objektmodell gibt es eine Basisklasse die die Primärschlüssel enthält und alle Geschäftsfälle erben diese Primärschlüssel.

Im ER haben wir alle vererbten Attribute in die Tabellen in denen die Geschäftsfälle liegen übernommen, hauptsächlich aus dem Grund, dass wenn wir da einen zentrale Tabelle hätten, diese ziemlich voll wäre (wir haben so schon ein enormes Datenaufkommen).

Vermutlich war es ein Fehler Überlegungen in Sachen Datenmengen in die Datenmodellierung zu nehmen, darunter leiden wir wohl jetzt.

Naja, nochmal darüber nachdenken. :o)

Der Unique-Index hätte das Problem, dass noch nicht sicher geprüft ist ob der Datensatz auch in den anderen Tabellen existiert.

Danke auf jeden Fall für deinen Input. :smile:

Grüße, Robert

#4

Hei,

nach Deinen Angaben hast Du für unterschiedliche Geschäftsvorfälle mindestens 23 andere Tabellen. Wäre hier nicht eine Zusammenfassung zu einer einzigen Tabelle sinnvoll, die dann halt einige redundante Spalten enthält, die je nach Geschäftsfall mehr oder weniger gefüllt werden. Auch stelle ich ein Objektmodell in Frage, das für jeden noch so kleinen Unterschied in einem abgeleiteten Objekt gleich einen neuen Baum in die Objekthierarchie einhängt.

Wichtig finde ich auch, darauf weist mein Vorredner bereits hin, die Verwendung von technischen Schlüsseln, was ja auch einem Gedanken an eine Objekt-Id entspricht. Natürliche Schlüssel, die einen PK bilden, sind schliesslich nicht ohne weiteres änderbar.

Viel Spaß trotzdem noch und Grüße aus Düsseldorf

Dirk Bielemeier

#5

Also nochmal danke für eure Kommentare.

Die einzigen Daten die den Geschäftsfällen gemeinsam sind, sind diese IDs die wir als Primärschlüssel verwenden.

Wir haben jetzt diese IDs in eine eigene Tabelle gelegt, die eigentlichen Geschäftsfalltabellen haben Foreign-Keys auf diese eine Tabelle und z. B. die Buchung hat auch Foreign-Keys auf diese eine Tabelle statt auf die einzelnen Geschäftsfalltabellen.

Also kein Kompromiss mehr beim Datenmodell. :o)

Das Datenaufkommen (vermutlich eine knappe Million Datensätze pro Tag und soll zwei oder drei Jahre aufgehoben werden) hoffen wir dann mit viel Hardware und Oracle-Mitteln (z. B. aufteilen dieser Tabelle über mehrere physische Devices) schaffen zu können.

Danke und Grüße,
Robert