04. juni 2007 - 21:14Der er
12 kommentarer og 2 løsninger
Database design. Er det ok?
Hej Eksperter!
Jeg sidder og skal til at lave en database for vores billard klub. Jeg har skitseret en model på et stykke papir, men er ikke sikker på at den er lavet rigtig. Jeg har derfor brug for at vide om den er lavet rigtig eller om der lige skal ændres noget. Forklaringen kommer til hver tabel.
POSTOGBY (Postnr) city
PERSON (licensnr) internID fornavn efternavn adresse postnr
PERSONKONTAKT (ID) telefonnr email licensnr
NØGLER (ID) Hoveddør Køboks Lager
SNIT (ID) licensnr 3bc 1bc fri kegler årstal
PERSONSTATUS (ID) indmeldt udmeldt
BESTYRELSE (bestyrelseID) post personID
HOLD (licensnr) holdnr holdtype
Licensnummer for tabellerne er fødselsdatoer + 0 eller 1 ved ens fødselsdato, dog kun DDMMYY-0. bruger derfor ID'er ved nogle tabeller da der kan forkomme tvillinger. Ellers er det
De første 2 tabeller burde være ok. Lidt standard.
PERSONKONTAKT har jeg lavet fordi en person kan have flere telefonnumre og/eller emails.
SNIT havde jeg tænkt mig at gemme snitene for hver person for et år og ikke løbene.
PERSONSTATUS har drillet mig lidt. Jeg tvivler endda stadig på at dn er lavet rigtigt. En person kan nemlig melde sig ind og ud flere gange. Der er gratis medlemsskab efter 25 års medlemsskab. derfor bliver jeg nød til at holde styr på hvor lang tid hvert medlem har været medlem.
HOLD skal holde styr på hvem som spiller på hvilke hold i eksterne turneringer. Klubben spiller pt. 2 hold i 2. division og 2. hold i 3. division. Der er 4 spillere på hvert hold.
Ser man i forhold til databaseteori, så vil din database med fordel kunne normaliseres. En normalisering vil give dig bedre mulighed for søgninger i din database.
Kommentarer til enkelttabeller, håber jeg har fået det hele med.
// Den her er god nok POSTOGBY (Postnr) city
// Ser ud til at du har 2 unikke ID på denne tabel, licensnr og id. Jeg ville derfor nøjes med at bruge ID som fremmednøgle og lade licensnr være under personen derudover ville jeg lægge statusid ind her PERSON (licensnr) internID fornavn efternavn adresse postnr statusid
// Denne her skal splittes op i 2 tabeller PERSONKONTAKT (ID) personid(internid) typeid beskrivelse
KONTAKTTYPE (ID) type (1 =telefonnr, 2 = email, 3= licensnr)
forskellen imellem arne_v's design og designet som jeg har opbygget er normaliseringsgraden, arne_v har bibeholdt den normaliseringsgrad som du opsatte. Det har sine fordele og sine ulemper.
Som jeg læser typ og val. Mener han typen af information, f.eks under nøgler hvor han skriver typ er det sandsynligvis det samme som der hvor jeg oprettede en ny tabel, og han forventer nok at du vil administrere det på samme måde. Men det er jo bare gætværk fra min side heh.
Kigger man med hensyn til flere kontaktinformationer så har jeg lavet en fejl med beskrivelsen i kontakttypen i min opsætning. Men det gik også stærkt.
Fordelen ved at dele den op i en tabel for sig selv er at du kan nøjes med 1 entitet i din personkontakttabel og referere til det id i den anden tabel, derved undgår du redundans, og redundans er det man forsøger at undgå ved databasenormalisering.
Dette har betydning når du skal opdatere informationer, således at du kun skal opdatere informationerne ét sted.
Ulempen er så mere komplekse sql queries der kan have betydning for din søgehastighed, dog nok ikke på et lille klubsite. Der skal mange flere søgninger til.
Så hvis vi skal se meget generelt på en normalisering så er der disse fordele og ulemper:
Fordele: - Ingen redundans, data opdateres ét sted, - Bedre søgemuligheder
Ulemper - Længere søgehastigheder, - Data redundans, der skal håndteres manuelt
Det var en super god forklaring. Jeg vil bruge dit design da det formindsker redundans. Kan du ikke smide et svar, så du kan få et "stort femtal af maaaj" :-)
Først lige svaret til arne_v som en kommentar, og derefter svaret.
Bl.a. i person tabellen er licensnr PK, licensnr kan pga. nedenstående ikke være PK da licensnr ikke er unik, dette vil ikke overholde 1 Normalform.
"Licensnummer for tabellerne er fødselsdatoer + 0 eller 1 ved ens fødselsdato, dog kun DDMMYY-0"
Kigger vi på NØGLER tabellen er udleveret, afleveret og type delvist afhængig af licensnr og ikke kun nøgleid, dvs. de er ikke transitivt afhængige af PK. Det overholder ikke 3 normalform. Det samme gør sig gældende for bestyrelsestabel, hvor licensnr,FK faktisk, som jeg ser det, er afhængig af sig selv og ikke af PK? (Kan være jeg mistolker intentionen med den her tabel?).
Det kan godt være min analyse er lidt rusten, da det er lang tid siden jeg har haft database teorien helt inde på nethinden. Men jeg mener det skulle være forklaringen.
Hvis der er noget i din beskrivelse jeg har misforstået arne_v, så er jeg da også frisk på at genlære noget af min gamle teori :)
Der er en PK altså er den på 1NF. Formulereingen af spørgsmålet kunne godt antyde at den ikke kan bruge ssom PK, men jeg mener altså ikke at man kan/bør udstede flere licenser med samme id til forskellige personer.
Nøgler er en fejl. Licensnr skal selvfølgelig være både PK og FK. For afleveringstidpsunktet afhænger ikke kun af nøgleid. Ihvertfald ikke hvis vi forudsætter, at det ikke er engangsnøgler.
Alle felter afhænger af dem selv. Det kan man ikke bruge til noget. Min bestyrelsesid er det samme som spørgers og jeg antager at det er f.eks. (formand,kasserer, menigt medlem).
Jeg sidder her noget tid efter og har revet al mit hår af i desperation over hvordan jeg skal lave tabellen "Nøgler"
Du har foreslået at tabellen skal se således ud:
NØGLER ------ nøgleid,PK typ licensnr,FK udleveret afleveret
Jeg ved ikke hvordan tuplen skal se ud (datatyperne) uden at få konflikter på PK. Kan du evt lave et eksempel?
Lige en hurtig forklaring:
Alle medlemmerne har et licensnummer, som er deres fødselsdato (ddmmyy + 0 eller 1 eller 2 osv osv - ved 2 ens fødselsdage stiger sidste nummer) Dette er det samme licensnummer, som Den Sjællandske Billard Union (SJBU) bruger og derfor vil jeg bruge samme. Det er måske ikke så hensigtsmæssigt i længden, men lad det bare ligge.
Alle medlemmerne i vores klub kan have 0 nøgler eller:
...nøgle til køskab (med køskabnummer (unik køskabnummer). En spiller kan godt have 2 køskabe og derfor 2 køskabnøgler med 2 forskellige numre. ...nøgle til hoveddøren ...nøgle til lageret (kun bestyrelsen) ...nøgle til Ballskab
Medlemmerne lægger et depositum for de forskellige nøgler med forskellige beløb.
500 kr for en hoveddørsnøgle 100 kr for en nøgle til køskabet 0 kr for nøgle til lageret nøgle til ballskab - ikke fastsat endnu
NØGLER ------ nøgleid,PK typ licensnr,PK,FK udleveret afleveret
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
