Databases Reference
In-Depth Information
Update-Anomalien:
Die gleiche Art von Inkonsistenz kann natürlich eintreten,
wenn wir die folgende
update
-Anweisung ausführen:
update alben
set verlag='Panini'
where reihe='Asterix' and band=1
Das Album „Asterix der Gallier“ ist jetzt bei Panini erschienen, die Bände 17 und
25 dagegen bei Ehapa.
Delete-Anomalien:
Ein Szenario, in dem wir zwar keine inkonsistenten Daten er-
halten, aber unbeabsichtigt zu viele Daten verlieren, ergibt sich mit der folgenden
Anweisung:
delete from alben
where reihe='Tim und Struppi' and band=1
Wir entfernen das Album „Der geheimnisvolle Stern“ aus unserer Sammlung und
verlieren zugleich die Information, dass die „Tim und Struppi“-Alben im Carlsen
Verlag erschienen sind.
Wir erkennen rasch, dass der Entwurf unserer Tabelle die Ursache für diese Ano-
malien ist, da wir zu viele Informationen in diese eine Tabelle gequetscht haben.
Wir wenden unser Wissen aus Kapitel 5 an und zerlegen die Tabelle
alben
in
zwei neue Tabellen:
Listing 8.2:
Die Zerlegung einer Tabelle
create table reihen(
name varchar(30) primary key,
verlag varchar(30)
);
create table alben(
reihe varchar(30) references verlage,
titel varchar(30) not null,
band int check(band>=0),
jahr int check(jahr>=1900),
primary key(reihe, band)
)
Wenn wir die Daten aus der Tabelle 8.3 jetzt geeignet auf die beiden neuen Tabel-
len verteilen, dann ergibt sich der Datenbestand aus den Tabellen 8.2 und 8.3.
Keine noch so raffinierte Integritätsregel ist so wirksam wie diese einfache Umfor-
mung: Die beschriebenen Anomalien sind nicht mehr möglich. Lediglich unsere
SQL-Anweisungen werden komplexer, da wir es jetzt mit zwei Tabellen zu tun
haben. Wir teilen
insert
-Anweisungen für die Datensätze, die wir in die Tabelle
