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:
-
Att hitta en viss bil i tabellen kräver strängmatchning med like och %,
vilket är mycket långsammare än enkla strängjämförelser med =.
-
En enkel fråga som "finns samma bil med på två ställen" blir närapå helt omöjlig att formulera.
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:
-
Att hitta en viss bil i tabellen kräver jämförelse med alla tre kolumnerna
Bil1, Bil2 och Bil3.
-
En enkel fråga som "finns samma bil med på två ställen"
blir ruskigt krånglig, eftersom man måste jämföra var och en av kolumnerna
(Bil1, Bil2 och Bil3) med var och en av de andra.
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:
Ö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