Tabellen und Constraints - Grundkurs Datenbanksysteme - page 85

drop table farben;
create table farben(
farbe varchar(8) primary key
);
insert into farben values('diamonds');
insert into farben values ('hearts');
insert into farben values ('spades');
insert into farben values('clubs')
Nach Anpassung der Tabelle farben kommt die Tabelle spielkarten an die
Reihe:
update spielkarten set farbe='diamonds' where farbe='Karo';
update spielkarten set farbe='hearts' where farbe='Herz';
update spielkarten set farbe='spades' where farbe='Pik';
update spielkarten set farbe='clubs' where farbe='Kreuz'
Anschließend werden die Tabellen wieder über eine referenzielle Integritätsregel
miteinander verbunden:
alter table spielkarten
add constraint fk_farben
foreign key(farbe) references farben
Für eine so kleine Änderung sind das viele Verarbeitungsschritte. Das ist aber
nicht das Schlimmste:
Weil die referenzielle Integritätsregel zeitweilig aufgehoben wurde, gibt es ein
Zeitfenster, in dem Datensätze in die Tabelle spielkarten eingefügt werden
können, die nicht der referenziellen Integrität genügen.
Konsistenzverletzungen können wir nur vermeiden, wenn wir die Tabelle
spielkarten für die Dauer der Änderungen sperren (siehe auch Kapitel 17).
Das ist zwar möglich, hält die Anwender aber bei großen und stark genutzten
Tabellen möglicherweise lange von der Arbeit ab.
Hinweis
Änderungen am Tabellenschema mit alter table können im lau-
fenden Betrieb problematisch sein!
Das ganze Theater wäre vermeidbar gewesen, wenn wir auf farbe als natürli-
chen Primärschlüssel verzichtet hätten.
Unsere ganze Datenbank gewinnt stark an Robustheit gegenüber Änderungen,
wenn wir den Einsatz natürlicher Primärschlüssel vermeiden. In unserer einfa-
chen Datenbank erscheint die Wahl der Spalte farbe zum Primärschlüssel ganz