Omslaget. Klicka här för att gå till bokens hemsida.

Databasteknik: Svar till övningar - kapitel 11

Första försöket

Även om en människa ganska snabbt kan titta i en (tillräckligt liten!) tabell och hitta till exempel vem som äger bil WCA912, så blir SQL-frågor både svårformulerade och ineffektiva. Exempel: Den här tabellen uppfyller inte första normalformen, som kräver att tabellen bara får innehålla enkla, odelbara värden. En sträng som består av flera bilnummer, så att man måste dela upp den i delar, är förstås inte odelbar.

Andra försöket

Även om en människa ganska snabbt kan titta i en (tillräckligt liten!) tabell och hitta till exempel vem som äger bil WCA912, så blir SQL-frågor både svårformulerade och ineffektiva. Alla frågor måste ju titta i tre olika kolumner, vilket gör varje fråga minst tre gånger så komplicerad. Exempel: Dessutom slösas plats, och komplceras frågor, av alla null-värdena. Och om någon äger mer än tre bilar, går det inte att lagra.

Tabellen uppfyller första normalformen, och normalformerna hela vägen upp till och med BCNF. Men den är ändå en dålig lösning, vilket visar att det inte räcker med normalformer för att göra en bra databas.

Tredje försöket

Tabellen innehåller en rad för varje bil, vilket innebär att det finns en del redundans: för varje bil som en viss person (som person nummer 3 i exemplet) äger, måste man upprepa vad den personen heter.

I de tidigare försöken var det personens Nummer som var primärnyckel, men här är det Bil. Eftersom en kandidatnyckel inte får innehålla null-värden, kan vi inte alls lagra personer som inte äger någon bil. (Notera att Stina försvunnit!)

Tabellen strider mot tredje normalformen, eftersom det finns ett fullständigt funktionellt beroende från icke-nyckel-attributet Nummer till icke-nyckel-attributet Namn.

En bättre lösning

Ingen som läst boken blir väl förvånad över att man ska använda sig av mer än en tabell. Man kan utgå från till exempel den tredje givna tabellen, analysera den med avseende på fullständiga funktionella beroenden, och sen dela upp den i flera tabeller genom att bryta ut de attribut som deltar i beroenden som bryter mot de olika normalformerna.

Men som vanligt rekommenderar vi att man börjar med att rita ett ER-diagram:

Ett ER-diagram med personer och bilar

Översätt sen ER-diagrammet till tabeller:

Person
Nummer Namn
1 Olle
2 Stina
3 Saddam
Äger
Person Bil
1 RFN540
3 DBA456
3 SQL123
3 WCA912
Bil
Nummer
DBA456
RFN540
SQL123
WCA912

En ytterligare fördel med ER-diagrammet är att vi måste bestämma oss mer i detalj för vad databasen får innehålla. Kan det finnas personer som inte äger några bilar? Kan det finnas bilar utan ägare? Om det inte kan finnas bilar utan ägare, vill vi kanske rationalisera bort tabellen Bil.


Av Thomas Padron-McCarthy (e-post: boken@databasteknik.se)
Senaste ändring: 31 januari 2007