11. december 2006 - 13:03Der er
38 kommentarer og 1 løsning
DB-design
Hej gutter
Jeg har gang i et lille projekt. Jeg er ved at designe en DB. Da jeg ikke er så skarp i det, håber jeg at I vil guide mig lidt i den rigtige retning.
Jeg har sammen med nogle venner startet en fodboldklub. Næsten som en tradition er der ved afslutningen af hver sæson, mange spillere der vil gøre krav på titlen som årets topscorer. Ved at nedskrive målscorere og andre oplysninger for hver kamp vi spiller, kan man regne sig frem til dette, men det kunne da være sjovere, og nok også nemmere hvis jeg fik en database til at klare det for mig. Jeg har tænkt mig at lave en DB der indeholder flere data og vil nu se hvordan dette gøres optimalt.
Her er en beskrivelse af de data jeg forventer at DB’en skal indeholde.
SpillerInfo. Indeholder specifikke data om spilleren. -Unikt spillerID – Hver gang en ny spiller oprettes i DB’en, skal -der oprettes et unikt ID. -Fornavn -Efternavn -Email-adresse -Brugerlogin -Password
KampData. Indeholder data om alle kampe. -KampID – unikt ID som der kan refereres til. -Dato – for hvornår kampen bliver/blev spillet -Resultat – Vi vil jo gerne vide hvad kampen endte.
MaalData. Data om hvert enkelt mål. -Maal_ID – ID som senere kan bruges i referenceøjemed. -Tidspunkt – Efter hvor mange minutter blev dette mål scoret?
AddresseData. -Vejnavn -Husnummer
PostnrBy. -Postnr -By
Jeg vil nu prøve at beskrive relationerne mellem tabellerne.
For hver kamp skal der være en række i tabellen KampData. Resultatet kan selvfølgelig først skrives ind når kampen er slut. Rækkerne i MaalData repræsenterer hvert mål der bliver scoret og refererer til KampID. Alle mål der bliver scoret har en reference til den spiller der scorer der pågældende mål. Referencen er SpillerID. Alle kampe bliver spillet på en lokation med en adresse. Alle spillere har en adresse. Adresser kan indtastes i AdresseData. AdresseData har også en reference til PostnrBy da man både kan finde frem til by via postnr, men også til postnr hvis man kender bynavnet.
Jeg har uploadet et ER-diagram som gerne skulle beskrive ovenstående.
Umiddelbart ville jeg nok sige at en kamp foregår mellem to Hold, som hver har en hjemmeadresse tilknyttet. Kunne måske bare udvidde Adresse til Hold. Dit nuværende diagram viser en mange-til-mange mellem kamp og adresse, men en kamp foregår da vist kun ét sted ad gangen ;-)
Hmmm,... det lyder korrekt. Hvad synes du ellers om designet? Jeg har ikke så høje tanker om mine egne evner på dette område, så det vil da overraske mig meget hvis der ikke skal rettes mere.
Der er intet i vejen for at du starter med en simpel datamodel som kan det meste. Hvis du selv synes at du har fået det hele med, så ville jeg starte med at implementere dette. Jeg kan ikke slev lige se om der skulle mangle noget...
Prøv lige at fjerne dine dobbeltplinger omkring schemae og tabelnavn. Afslut med semikolon (;) Hvis det ikke virker, så lave lige en describe af tabellen (desc xxxx.postnrby;)
Jeg startede forfra og skriver nu alle kommandoerne i hånden og tester på en online SQL-server og kaster bare kommandoerne i fjæset på den. Det virker fint indtil videre.
Du kan ikke parse det som en date med midre du bruger session variable eller formaterer: INSERT INTO kampdata (kampid, resultat, dato) VALUES ('1', '4-4', to_date('2006-06-16','YYYY-MM-DD'));
Jeg har nu ændret lidt i ER-diagrammet og tilføjet en beskrivelse af det. Jeg vil sætte stor pris på det, hvis der er nogen som vil kigge på det og kommentere på det.
Du kunne måske godt udvidde lide med hvem der har spillet hvornår. Man kan jo ikke se om folk har scoret 1 mål i 1 kamp, eller 1 mål i 53 kampe. Spiller I mod andre eller mellem hinanden? Vil du registrere udeholdets mål også? Måske bare lave en fiktiv "spiller" som scorer udemålene....
Mht hvem der har spillet hvornår, har jeg måske bare brug for en reference fra spiller til kampid, som så indikerer at spilleren har været på banen i den pågældende kamp. På den måde har jeg både antal kampe spilleren har spillet, hvor mange mål spilleren har scoret, samt i hvilken kamp målet/målene er scoret.
Jeg har i første omgang ikke tænkt mig at registrere modstandernes mål.
Dette er et lille skoleprojekt som desværre skal afleveres på mandag. Jeg havde i første omgang opgivet at nå at lave det færdigt, men har bestemt mig for at tage chancen.
Hvordan vil du gemme at spiller x spillede med i kamp 1,2,3 og spiller y spillede med i 3,4,5? Det gør du ved at sætte en tabel imellem de to og have en id til kamp og til spiller. Med andre ord bliver din n-n relation til en tabel med to 1-n relationer til kamp hhv. spiller.
www.califfo.dk/proj/ER_diagram.jpg er opdateret. Var det sådan du mente det? Kan det så passe at attributterne i den nye tabel er primærnøglerne i "kampdata" og "spillerinfo"?
Ja, men jeg tror at dine relationer skal vende omvendt. Hvis man bruger kragetæer så skal de begge pege hen på den nye entitet. Og så synes jeg at dine betegnelse for entiteten er lidt misvisende. måske at du skal kalde den spillerkampdata el. lign.
"...Hvis man bruger kragetæer så skal de begge pege hen på den nye entitet..." Det udtryk har jeg ikke hørt før i denne sammenhæng, men jeg tror jeg har forstået det nu.
Jep. Betegnelsen for entiteten var ikke så god. "spillerkampdata" er bedre.
Jeg tror at vi skal stoppe designet her, så du kan blive færdig med opgaven. Det ser godt ud. Husk dog på at det nu er en fysisk model som du har tegnet. Før var det en logisk model. Det er meget vigtigt at du gør opmærksom på forskellen i din opgavebesvarelse. Mange-til-mange relationer må godt forekomme i den logiske model.
Ok,... tak. Jeg opretter lige DB'en med alle tabeller og vender så tilbage. Tusind tak for din hjælp indtil videre. Den er uvurderlig. Det er superfedt at få så god hjælp.
DROP TABLE spillerinfo; DROP TABLE gruppeinfo; DROP TABLE kampdata; DROP TABLE maaldata; DROP TABLE spillerkampdata; DROP TABLE adressedata; DROP TABLE postnrby;
Drop plingerne ved ID ('ID') og så skal dine constraints hede noget forskelligt. Typisk ville jeg skrive [TABELNAVN]_PK Spillerkampdata skal indeholde kampid og spillerid med tilhørende foreign keys:
Du kan tilføje ON DELETE CASCADE til slutningen af dine to foreign keys. Så bliver relationen automatisk slettet hvis du sletter fra spiller eller kamptabellen
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.
