Avatar billede OnkelJoakim Novice
04. juni 2007 - 21:14 Der 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.



Rasmus
Avatar billede 0xffff Nybegynder
05. juni 2007 - 00:41 #1
Hejsa Rasmus,

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)

// Samme her
NØGLER
(ID) personid nøgletype

NØGLETYPE
(ID) type (Hoveddør = 1, Køboks = 2, Lager = 3, osv..)

// Licensnummer skal ud, da vi nu håndterer det på id basis
SNIT
(ID) personid 3bc 1bc fri kegler årstal

PERSONSTATUS
(ID) type (indmeldt = 1, udmeldt = 2)

// Den her kan jeg ikke lige gennemskue, men jeg vil mene at du skal have personid som fremmednøgle.
BESTYRELSE
(bestyrelseID) post personID

// Skal splittes op så holdtypen kommer i en tabel for sig selv
HOLD
(id) personid holdnr

// Beskriver typen som efter principperne fra ovenstående.
HOLDTYPE
(id) type
Avatar billede arne_v Ekspert
05. juni 2007 - 04:49 #2
POSTBY
------
postnr,PK
city

PERSON
------
licensnr,PK
fornavn
efternavn
adresse1
adresse2
postnr,FK

PERSONKONTAKT
-------------
licensnr,PK,FK
prioritet,PK
typ
val

NØGLER
------
nøgleid,PK
typ
licensnr,FK
udleveret
afleveret

SNIT
----
licensnr,PK,FK
år,PK
3bc
1bc
fri
kegler

PERSONSTATUS
------------
licensnr,PK,FK
eventno,PK
eventtyp
tid

BESTYRELSE
----------
bestyrelsesid,PK
licensnr,FK

HOLD
----
holdnr,PK
type

HOLDDELTAGERE
-------------
holdnr,PK,FK
licensnr,PK,FK
Avatar billede OnkelJoakim Novice
05. juni 2007 - 07:05 #3
Hej begge 2!

Jeg er lidt i tvivl om datatyperne (typ og val) i Arne_v's design.

PERSONKONTAKT
-------------
licensnr,PK,FK
prioritet,PK
typ
val

Kan du evt. lave et eksempel. Jeg skal kunne registrere 0 til flere telefonnumre og eller emails
Avatar billede OnkelJoakim Novice
05. juni 2007 - 07:39 #4
Er lige på vej i seng. Mit arbejde har gjort mig til vampyr. Og de sover som sagt om dagen ;-)
Avatar billede 0xffff Nybegynder
05. juni 2007 - 08:13 #5
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.

NØGLETYPE
(ID) type (Hoveddør = 1, Køboks = 2, Lager = 3, osv..)

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.

KONTAKTTYPE
(ID) type beskrivelse (1 =telefonnr, 2 = email, 3= licensnr)

og her fjernes beskrivelse så fra personkontakt.


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
Avatar billede OnkelJoakim Novice
05. juni 2007 - 21:06 #6
Hej 0xffff!!!

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" :-)

Tak for hjælpen

Rasmus
Avatar billede arne_v Ekspert
05. juni 2007 - 21:33 #7
Hm.

Saa vidt jeg kan se er midt design da fuldt normaliseret.

Gider du forklare hvad der ikke er normaliseret ?
Avatar billede 0xffff Nybegynder
05. juni 2007 - 22:52 #8
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 :)
Avatar billede 0xffff Nybegynder
05. juni 2007 - 22:54 #9
Og her var svaret.

Jeg vil samtidig da syntes at arne_v skulle komme med et svar, da han også har bidraget.
Avatar billede arne_v Ekspert
06. juni 2007 - 04:13 #10
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).
Avatar billede arne_v Ekspert
06. juni 2007 - 04:15 #11
Og et svar.
Avatar billede OnkelJoakim Novice
06. juni 2007 - 05:34 #12
Hejsa!


Jeg er lige kommet hjem fra en dødsyg nats arbejde. Jeg kigger på det, men i får begge 100 P.

Tak for hjælpen begge to.

Rasmus
Avatar billede OnkelJoakim Novice
14. juli 2007 - 16:44 #13
Hej Arne!

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


Kan du hjælpe med dette?

mvh
Rasmus
Avatar billede arne_v Ekspert
14. juli 2007 - 21:56 #14
Som jeg også fik rettet ovenfor skal det være:

NØGLER
------
nøgleid,PK
typ
licensnr,PK,FK
udleveret
afleveret
Avatar billede Ny bruger Nybegynder

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.

Loading billede Opret Preview
Kategori
Computerworld tilbyder specialiserede kurser i database-management

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester