Integritetsvillkor

Databashanteraren kan förstås inte lyckas helt och hållet med att hålla databasen fri från felaktiga uppgifter. Den kan inte hoppa ut ur datorn och springa iväg och kolla upp Bengts lön. (Åtminstone inte med dagens teknik. I framtiden kanske städernas gator är fulla av databashanterare som rusar fram och tillbaka och kontrollerar löneuppgifter. Övning: Rita en bild av en gata i framtiden, med databashanterare och svävande bilar!) Men databashanteraren kan hjälpa till lite i alla fall.

Den som skapar och ansvarar för databasen (databasadministratören) kan berätta för databashanteraren vilka regler som alla data i databasen måste uppfylla. Reglerna kallas integritetsvillkor. Om nu en persons lön kan stå på två ställen, så kanske vi har integritetsvillkoret att båda de uppgifterna måste vara lika. Eller så har vi helt enkelt en regel som säger att alla löner måste ligga mellan 0 och 40000. (ABB-direktörer och chefsöverläkare får inte vara med i databasen.)

Integritetsvillkor ("integrity constraints" på engelska) är alltså villkor som begränsar vilka data som kan lagras i databasen. Åtminstone en del av integritetsvillkoren är egentligen också begränsningar som gäller i den riktiga världen, och inte bara i databasen, för databasen beskriver en del av världen. Om man har ett integritetsvillkor som säger att alla löner måste ligga mellan 0 och 40000, så säger man ju också att ingen människa, av de som ska vara med i databasen, har en lön som ligger utanför det intervallet.

Här är två vanliga typer av integritetsvillkor i relationsdatabaser:

1. Nyckelvillkor, nämligen att primärnyckeln (och eventuella andra kandidatnycklar) måste ha unika värden, dvs att det inte får finnas två rader i en tabell som har samma värde på primärnyckeln.
2. Referensintegritetsvillkor, nämligen att om det står i tabellen Anställd att en viss anställd jobbar på avdelning nummer 17, så ska det också finnas en avdelning med nummer 17, i tabellen Avdelning.

Ett exempel: Anställda och avdelningar

Även om man inte kan så mycket om databaser så verkar det väl rimligt att:

• varje anställd måste ha ett nummer
• två anställda inte får ha samma nummer
• varje avdelning måste ha ett nummer
• två avdelningar inte får ha samma nummer
• om det står att en anställd jobbar på en avdelning med ett viss nummer, så måste det också finnas en sån avdelning.

Nyckelvillkor i SQL

create table Avdelning
(Nummer integer not null,
Namn varchar(10),
primary key (Nummer));

Nu har vi alltså skapat tabellen Avdelning, och talat om för databashanteraren att kolumnen Nummer är primärnyckel. Databashanteraren kommer nu att se till att varje avdelning har ett unikt nummer.

Vi stoppar in data i databasen:

insert into Avdelning values (1, 'Data');
insert into Avdelning values (2, 'Städning');
insert into Avdelning values (3, 'Ekonomi');
insert into Avdelning (Namn) values ('Lager'); /* Ger fel */
insert into Avdelning values (3, 'Lager');     /* Ger fel */
update Avdelning set Nummer = 2
    where Namn = 'Data';                       /* Ger fel */

• Vi försökte lägga in lageravdelningen utan något nummer alls, men eftersom Nummer är primärnyckel måste varje avdelning ha ett nummer.
• Vi försökte lägga in lageravdelningen med numret 3, men det finns redan en avdelning med nummer 3, nämligen ekonomiavdelningen.
• Vi försökte ändra numret på dataavdelningen från 1 till 2, men det finns redan en avdelning med nummer 2.

Referensintegritet i SQL

create table Anställd
(Nummer integer not null,
Namn varchar(10),
JobbarPå integer,
primary key (Nummer),
foreign key (JobbarPå) references Avdelning(Nummer));

alter table Anställd
add foreign key (JobbarPå) references Avdelning(Nummer);

alter table Anställd add constraint Anställd_till_avdelning
add foreign key (JobbarPå) references Avdelning(Nummer);

Ett referensattribut refererar alltid till primärnyckeln i en annan tabell (eller, ibland, samma tabell). Den har alltså samma domän som nyckeln i en annan tabell. Därför kallas ett referensattribut ibland för främmande nyckel (engelska: foreign key).

Vi stoppar in data i databasen:

insert into Anställd values (1, 'Svea', 1);
insert into Anställd values (2, 'Sten', 3);
insert into Anställd (Nummer, Namn) values (3, 'Bengt');
insert into Anställd values (4, 'Sergio', 5); /* Ger fel */
update Anställd set Avdelning = 7
    where Namn = 'Svea';                      /* Ger fel */
delete from Avdelning where Namn = 'Data';    /* Ger fel */
update Avdelning set Number = 9
    where Namn = 'Data';                      /* Ger fel */

• Vi försökte lägga in en anställd som heter Sergio och som jobbar på avdelning 5, men det finns ingen avdelning med nummer 5.
• Vi försökte ändra Sveas rad så att hon jobbar på avdelning 7 i stället för avdelning 1 som förut, men det finns ingen avdelning 7.
• Vi försökte ta bort dataavdelningen (avdelning nummer 1), men vad ska då hända med Svea? Det står ju i tabellen Anställd att hon jobbar på avdelning 1.
• Vi försökte ändra numret på dataavdelningen från 1 till 9, men (igen!) vad ska då hända med Svea? Det står ju i tabellen Anställd att hon jobbar på avdelning 1.

Vadå "misslyckas"?

Det brukar betyda att operationen avbryts, och att ingen ändring görs i databasen. Beroende på vad man använder för databashanterare och vad det är för sorts integritetsvillkor så sker det antingen direkt när man försökte göra ändringen, eller när hela transaktionen försöker göra commit.

Men man kan också tala om för databashanteraren att den inte ska avbryta operationen, utan "laga" databasen på lämpligt sätt. Titta på referensintegritetsvillkoret från exemplet ovan:

foreign key (JobbarPå) references Avdelning(Nummer)

1. foreign key (JobbarPå) references Avdelning(Nummer) on delete set null

   Det här betyder att om jag tar bort en avdelning som det finns anställda som jobbar på, så sätts JobbarPå för alla dessa anställda till null.

2. foreign key (JobbarPå) references Avdelning(Nummer) on delete cascade

   Om jag tar bort en avdelning som det finns anställda som jobbar på, så tas även dessa anställda bort.

3. foreign key (JobbarPå) references Avdelning(Nummer) on delete set default

   Om jag tar bort en avdelning som det finns anställda som jobbar på, så sätts JobbarPå för alla dessa anställda till den kolumnens defaultvärde.

4. foreign key (JobbarPå) references Avdelning(Nummer) on update cascade

   Om jag ändrar numret på en avdelning som det finns anställda som jobbar på, så sätts JobbarPå för alla dessa anställda avdelningens nya nummer.

Ajöss med konsulterna!

create table Konsult
(Nummer integer not null,
Namn varchar(10),
InhyrdAv integer,
primary key (Nummer),
foreign key (InhyrdAv) references Avdelning(Nummer)
on delete cascade);

insert into Konsult values (3, 'Sture', 2);
insert into Konsult values (4, 'Sally', 2);
insert into Konsult values (5, 'Sune', 3); 
delete from Avdelning where namn = 'Städning'; /* Kaskad! */

Mer komplicerade villkor

Ibland talar man om allmänna semantiska integritetsvillkor (engelska: "general semantic integrity constraints"). Det är vilka villkor som helst, som beror på hur det ser ut i den verklighet som databasen ska modellera. "Semantik" har ju med "betydelse" att göra, och de här villkoren bestäms av vad databasens data betyder. Eftersom den riktiga världen kan vara hur komplicerad som helst, så kan också de här integritetsvillkoren vara hur komplicerade som helst.

Exempel på allmänna semantiska integritetsvillkor:

• Ingen får tjäna mer än sin närmaste chef.
• Löner kan bara höjas.

Det andra villkoret, om att löner bara kan höjas, är ett dynamiskt villkor (engelska: "transition constraint", dvs "ändringsvillkor"). Det spelar bara in vid ändringar i databasen, och för att kontrollera det måste man jämföra innehållet i databasen före och efter ändringen.

Hur anger man dessa mer komplicerade villkor?

Vi tänker oss att vi använder samma exempeldatabas som i avsnittet om SQL. Villkoret att ingen får tjäna mer än sin närmaste chef kan skrivas så här:

create assertion checksalary
check (not exists (select *
                   from Anställd as proletär, Anställd as boss
                   where proletär.Chef = boss.Nummer
                   and proletär.Lön > boss.Lön))

Dynamiska villkor, som begränsar vilka ändringar som får göras i databasen, kan normalt inte uttryckas med en assertion. Det beror på att man måste titta på tillståndet i databasen både före och efter ändringen för att kunna kontrollera villkoret.

Aktiva databaser

Därifrån är inte steget långt till att införa en liknande mekanism, inte bara för integritetsvillkor, utan för vilka villkor som helst. Man skriver en regel som anger ett villkor och en åtgärd, och när det villkoret är uppfyllt, så ska databashanteraren utföra åtgärden. Då har vi det som kallas en aktiv databas.

Om vi använder en aktiv databas som låter oss ange ECA-regler, kan vi skriva en ECA-regel om villkoret att löner bara kan höjas:

create exception bad_salary "Kan inte sänka lönen!";
create trigger salarycheck for Anställd after update as begin
    if (new.Lön < old.Lön) then
        exception bad_salary;
end;

Om någon transaktion försöker ändra kolumnen Lön i tabellen Anställd så att det nya värdet blir lägre än det gamla, så kommer regeln att utlösas, och den transaktionen kommer att avbrytas.

I en riktig aktiv databashanterare kan man göra mer än bara avbryta transaktionen. Ofta finns så kallade lagrade procedurer, som är små (eller stora) programsnuttar som man kan lagra i databasen, och som kan köras när villkorsdelen av en regel är uppfylld. Reglerna kan därför användas till mycket annat än att bara kontrollera integritetsvillkor. Till exempel kan en aktiv databashanterare automatiskt beställa mer varor när lagret i en butik börjar bli tomt.

Vem kollar villkoren? Procedurellt eller deklarativt?

Hittills i det här avsnittet har vi bara sett den deklarativa metoden: att man med olika former av regler talar om för databashanteraren vad som ska gälla, och sen är det databashanterarens uppgift att se till att inga transaktioner kan ändra data så att integritetsvillkoren bryts.

Alternativet är att ange integritetsvillkoren procedurellt, dvs med vanlig programkod som kontrollerar att de är uppfyllda. Det kan vara i ett programmeringsspråk som Java eller C i ett applikationsprogram, eller kanske inuti en lagrad procedur i databasen. Programmeraren måste skriva programkod som kontrollerar varje ändring som ska göras, så att den uppfyller alla integritetsvillkor.

Helst vill man att databashanteraren ska sköta om kontrollen, automatiskt och utan att användare eller applikationsprogrammerare behöver bry sig. Det har flera fördelar:

• Mindre arbete för applikationsprogrammeraren, eftersom databashanteraren gör det mesta jobbet.
• Det är svårt för programmeraren att tänka på alla ställen som måste kontrolleras. Titta bara på hur många olika typer av ändringar som kunde orsaka att referensintegriteten bröts i exemplet med anställda och avdelningar tidigare i det här avsnittet.
• Reglerna finns samlade och i explicita, så att man kan läsa dem och se vilka de är. Annars får man läsa igenom en massa programkod, och sluta sig till vad det är för villkor som den programkoden försöker upprätthålla.
• Det är lättare att ändra i reglerna. Annars får man leta igenom alla existerande applikationsprogram, luska ut vilka delar av dem som kontrollerar reglerna, och ändra i allihop. (Har vi källkoden till alla program som används? Vet vi ens vilka program det är? Till exempel det där lönebonusuträkningsprogrammet från 1987 som de brukar använda på personalavdelningen? Eller har de slutat använda det programmet och skrivit ett nytt?)

En möjlig uppdelning i olika typer av integritetsvillkor

• Inneboende villkor ingår i den datamodell som man använder, och går inte att bryta mot om man inte byter datamodell. I den vanliga relationsmodellen har vi till exempel villkoret att värden ska vara atomära och att man bara kan stoppa in högst ett värde i varje ruta i tabellen. Om vi har en kolumn som heter Vikt, och den har datatypen integer, så går det helt enkelt vi inte stoppa in mer än en vikt på varje rad. (Jo, går går det kanske. Vill man göra något riktigt dumt kan man göra om Vikt till ett textfält och skriva in vikterna med komma emellan. Eller så kan man göra flera kolumner, Vikt1, Vikt2 osv. Det är också dumt. Nästan jämt i alla fall.)
• Implicita villkor behöver man inte ange uttryckligen, utan de följer som en konsekvens av vad man skriver i datadefinitionsspråket, alltså till exempel create table-kommandona. Hit kan man räkna nyckelvillkor, att primärnyckeln i en tabell måste ha olika värden för varje rad och inte får innehålla null-värden.
• Explicita integritetsvillkor måste man ange själv, antingen genom att skriva programkod som kontrollerar dem, eller genom att tala om dem för databashanteraren.

Databasens interna integritet

Varje index måste stämma överens med den riktiga tabell som det pekar in i. Om man lägger till eller tar bort rader i tabellen, och indexet av någon anledning inte ändras för att reflektera detta, så kan databashanteraren kanske bli så förvirrad att den kraschar.

Därför måste databashanteraren vara mycket noga med att upprätthålla integriteten på de interna datastrukturerna. Annars kanske man inte längre kan komma åt några data alls i databasen.

"Integritet" som i "personlig integritet"

Kom ihåg:

• Svenska personlig integritet = engelska privacy
• Svenska dataintegritet = engelska data integrity
• Och de två är inte alls samma sak!

Vi tar inte upp så mycket om personlig integritet här, men vi ska i alla fall nämna de svenska personnumren, som ibland ger upphov till både debatt och förvirring. Är personnummer hemliga? Är författaren dum när han nu talar om att hans personnummer är 631211-1658?

Nej, svenska personnummer är inte hemliga. De är inte alls hemliga. Om du vet namn och adress på en person, så att det går att avgöra vem det är, så kan du ringa till skattemyndigheten och få den personens personnummer. Du behöver inte tala om vem du är eller vad du ska ha personnumret till.

Eventuella problem och risker med personnummer handlar alltså inte om att personnummer är hemliga, utan om att de är unika. De fungerar som en nyckel eller ett unikt namn, inte som ett lösenord.

Om det finns en fara med personnummer så är det att det blir lätt att se att den där 631211-1658 som skriver databaskurser är samma person som den där 631211-1658 som har årskort på Klubb Läderhamster. Och det kanske jag inte vill att alla ska veta. Därför vill jag kanske inte att Klubb Läderhamster ska använda mitt personnummer som medlemsnummer, och trycka det på medlemskortet.

De viktigaste begreppen

integritet, dataintegritet, personlig integritet (privacy), integritetsvillkor, nyckelvillkor, referensintegritet, aktiv databas

Litteratur

• Padron-McCarthy/Risch, kapitel 12
• Connolly et al, fjärde upplagan: kapitel 9
• Date, åttonde upplagan: kapitel 9
• Elmasri/Navathe, fjärde upplagan: avsnitt 5.2, 5.3 och 8.2
• Silberschatz, fjärde upplagan: kapitel 6