Anfängerfrage Referezielle Integrität

[Eric S]

Hallo Forum

Ich bin nach Jahren mal wieder ins kalte DB-Wasser geworfen worden und mir erschließt sich folgender Zusammenhang nicht vielleicht wäre jemand so freundlich mir auf die Sprünge zu helfen.


Also, ich habe Tabelle A in der sich eine Spalte ProduktID befindet die noch als "normale Spalte" als INTEGER, NOT NULL definiert ist, allerdings ist sie (bisher) nicht UNIQUE. Diese Spalte gibt es als Primärschlüssel in Tabelle B dort ist A.ProduktID aber nicht als Fremdschlüssel eintragen.

1.) Ich verstehe irgendwie nicht mehr so ganz wie das möglich ist, da es von A.ProduktID einige Datensätze mit der gleichen ProduktID gibt. Die Spalte B.ProduktID muß als Primärschlüssel doch eindeutig sein meines bescheidenen DB-Wissens nach.

Also habe ich doch:

Tabelle A
ProduktID - SpalteMitWert
10 - A
20 - B
20 - C
20 - D
30 - E

Tabelle B
ProduktID - SpalteMitWert
10 - A
20 - ? (mir nicht ganz so klar worauf die 20 jetzt "zeigt" sie kann ja da PK nur einmal vorkommen)
30- D

2.) Nun soll A.ProduktID Primärschlüssel werden und als Fremdschlüssel in Tabelle B genutzt werden samt CASCADE. Natürlich dürfen beim Umbau keine bestehenden "Verbindungen" verloren gehen.
Also baue ich um, indem ich A.ProduktID erstmal eindeutig mache, das klappt soweit.

ProduktID - SpalteMitWert
10 - A
20 - B
40 - C
50 - D
30 - E

Nun muss ich allerdings in Tabelle B diese Änderungen irgendwie auch machen hier liegt derzeit mein zweites Verständnisproblem.

Tabelle B
ProduktID - SpalteMitWert
10 - A
20 -
30 - D
40 -
50 -

Wie ist die Vorgehensweise ?

 

[akretschmer]

Also, ich habe Tabelle A in der sich eine Spalte ProduktID befindet die noch als "normale Spalte" als INTEGER, NOT NULL definiert ist, allerdings ist sie (bisher) nicht UNIQUE. Diese Spalte gibt es als Primärschlüssel in Tabelle B dort ist A.ProduktID aber nicht als Fremdschlüssel eintragen.

1.) Ich verstehe irgendwie nicht mehr so ganz wie das möglich ist, da es von A.ProduktID einige Datensätze mit der gleichen ProduktID gibt. Die Spalte B.ProduktID muß als Primärschlüssel doch eindeutig sein meines bescheidenen DB-Wissens nach.

Ganz ruhig.

Du brauchst eine Tabelle mit einem Primary kKey. Der ist impliziet dann auch Unique, dazu noch NOT NULL. Und dann eine Tabelle, wo Duauf diesen key referenziert, also einen Foreign Key.

Man kann das gleich beim erstellen der Tabellen machem aber ich zeige Dir erst mal den langen Weg:

test=*# create table ta(id int, wert int);
CREATE TABLE
Time: 150,585 ms
test=*# create table tb(id int);
CREATE TABLE
Time: 1,306 ms

-- nun den Primary key

test=*# alter table tb add primary key (id);
ALTER TABLE
Time: 34,777 ms


-- nun den Foreign key
test=*# alter table ta add constraint id_ta foreign key (id) references tb(id);
ALTER TABLE
Time: 1,833 ms

Und der kurze Weg:

test=# create table tb(id int primary key);
CREATE TABLE
Time: 23,832 ms
test=*# create table ta (id int references tb);
CREATE TABLE
Time: 1,389 ms

Fragen? Fragen!

 

[Eric S]

Leider ja

Obiges Szenario existiert schon ich lege also keine neuen Tabellen an sondern muss an einer uralten bestehenden Datenbank aus der Spalte ProduktID in Tabelle A den neuen Primärschlüssel von A machen, das bekomme ich auch hin.

Jedoch war die Spalte ProduktID bisher in Tabelle B ebenfalls enthalten dort jedoch als Primärschlüssel allerdings ohne das eine Referenz via Fremdschlüssel zwischen Tabelle A und Tabelle B existierte ....

Nun muss ich diese Beziehung erstellen habe jedoch hier ein Verständnisproblem:
- In A.ProduktID existieren Werte dopppelt.
- In B.ProduktID logischerweise nicht da die Spalte dort PK war.

Nun habe ich bspw. folgende Daten

Tabelle A
ProduktID - AndereSpalteMitWert
10 - A
20 - B
20 - C
20 - D
30 - E

Tabelle B
ProduktID - AndereSpalteMitWert
10 - A
? - B
? - C
? - D
30 - E

Mir ist nicht ganz so klar worauf die ID = 20 aus Tabelle B jetzt "zeigt" (first come first serve ?) sie kann ja nur einmal vorkommen und was ist mit den anderen beiden Zeilen aus Tabelle A die ebenfalls eine ID = 20 haben.

 

[akretschmer]

ir ist nicht ganz so klar worauf die ID = 20 aus Tabelle B jetzt "zeigt" (first come first serve ?) sie kann ja nur einmal vorkommen und was ist mit den anderen beiden Zeilen aus Tabelle A die ebenfalls eine ID = 20 haben.

Gut erkannt. Da es seitens der Datenbank keinen Constraint gab, ist das nicht eindeutig. Willst Du einen Foreign Key von der B auf die A dann muß da ein PK existieren. Also mußt Du jetzt dafür sorgen, daß da nur einer mit der 20 drin ist. Du solltest den Macher der Datenbank jetzt solange quälen bis er Dir sagt, welche Du jetzt löschen kannst.

 

[Tom.S]

Ich glaube, Du musst umgekehrt denken: In B ist die ProduktID der Primärschlüssel und in A der Fremdschlüssel. Somit kann in A auch die ProduktID '20' mehrfach auftreten. Dann kann allerdings A.ProduktID nicht zum Primärschlüssel werden.
Ich würde Dir empfehlen, bei deinen Umbauarbeiten immer einen Surrogatschlüssel zu nutzen und nie einen auch noch so eindeutigen natürlichen Schlüssel, um genau solche Probleme zu vermeiden.