Databasedesign • Hvad skal man tage højde for: – Hvad skal kunne trækkes UD af databasen – Hvilke data skal IND – Hvilke tabeller og felter skal vi have.

Præsentationer af emnet: "Databasedesign • Hvad skal man tage højde for: – Hvad skal kunne trækkes UD af databasen – Hvilke data skal IND – Hvilke tabeller og felter skal vi have."— Præsentationens transcript:

1 Databasedesign • Hvad skal man tage højde for: – Hvad skal kunne trækkes UD af databasen – Hvilke data skal IND – Hvilke tabeller og felter skal vi have – Så skal man normalisere alle tabellerne for at sikre: – En effektiv og korrekt fordeling af data i tabellerne og mindske mængden af gentagne data i databasen

2 FORNAVNEFTERNAVNADRESSEPOSTNRBYNAVN PerLarsenVejen 1002500Valby BoHansen2300KBH S IbJensenAleen 352730Herlev JensAndersenKøbenhavn S Dårlig tabel – der er ikke noget, der entydigt identificerer hver post Derfor opretter vi en primærnøgle: IDFORNAVNEFTERNAVNADRESSEPOSTNRBYNAVN 1PerLarsenVejen 1002500Valby 2BoHansen2300KBH S 3IbJensenAleen 352730Herlev 4JensAndersenKøbenhavn S

3 Ikke så godt med et automatisk ID, for sletter vi IB og opretter ham igen, så får han nummer 5 og ikke 3, da dette nummer ER brugt – historikken er ikke med – derfor laves et nyt felt STATUS, hvor vi angiver om folk er med eller ikke – MEN POSTERNE ER UNIKKE. Og der var flere steder hvor samme oplysning var skrevet flere gange og stavet forkert. Og der må ikke være ”huller” og felter må ikke afhænge af hinanden. Det gør Postnr og Bynavn, så derfor skal Bynavn ud i en anden tabel IDFORNAVNEFTERNAVNADRESSEPOSTNRSTATUS 1PerLarsenVejen 1002500Ja 2BoHansenStien 22300Ja 3IbJensenAleen 352730Nej 4JensAndersenSvinget 872300Ja POSTNRBYNAVN 2300København S 2500Valby 2730Herlev Men vi skal også se på postnummertabellen om den er god nok: Den skal også have et entydigt ID (i tilfælde af at et postnummer ændrer sig)

4 IDPOSTNRBYNAVN 12300København S 22500Valby 32730Herlev IDFORNAVNEFTERNAVNADRESSEPOSTIDSTATUS 1PerLarsenVejen 1002Ja 2BoHansenStien 21Ja 3IbJensenAleen 353Nej 4JensAndersenSvinget 871Ja Så Postnr fra den anden tabel fjernes og der henvises til Postid i stedet – og så kan vi relatere tabellerne NU ER TABELLERNE PÅ DET, DER HEDDER 3NF – det vil sige: Der er en primærnøgle Ingen repeterende data Alle felter er afhængige af primærnøglen Alle felter der ikke er primærnøglen skal være uafhængige af hinanden

5 Og så kommer chefen og vil have Privat telefon, Mobil og Arb telefon med! IDFORNAVNEFTERNAVNADRESSEPOSTIDSTATUSPRIVAT TLFMOBILARB TLF 1PerLarsenVejen 1002Ja1235689732659873 2BoHansenStien 21Ja32659878 3IbJensenAleen 353Nej32548797 4JensAndersenSvinget 871Ja32659878 For mange tomme felter og felter, der afhænger af hinanden ! Derfor: IDFORNAVNEFTERNAVNADRESSEPOSTIDSTATUS 1PerLarsenVejen 1002Ja 2BoHansenStien 21Ja 3IbJensenAleen 353Nej 4JensAndersenSvinget 871Ja IDKUNDEIDTYPENR 11112356897 21232659873 32132659878 43332548797 54332659878 IDPOSTNRBYNAVN 12300København S 22500Valby 32730Herlev Så 1 tabel endte op med at blive til 4! TYPETLF ART 1Privat tlf 2Arb tlf 3Mobil