Det er en fiktiv Database for at lære Normalisering og opdelingen af data i flere tables. Tanken var et net sted ala. dating.dk og hvad vi ellers har derude.
Umiddelbart ja, men kan du evt. ikke hurtigt lave et E/R diagram - så er det nemmere at vurdere. Min eneste kommentar er fornavn og efternavn...dem ville jeg umiddelbart sætte til En til Mange, idet et fornavn eller efternavn jo godt kan forekomme hos flere personer...Ellers skal du jo bare sørge for, at fornavn OG efternavn OG et tredie unikt træk udgør primærnøglen i din tabel...
Fornavn og Efternavn er jo som du siger En til Mange, men det er irrelevant da det skrives af brugeren og ikke skal vælges fra noget andet Table. Men for god ordens skyld retter jeg det lige til :-)
Se nu ligner det noget:-) Synes det er en rigtig god ide, som du har skrevet under tabellen T_PersonInfo, at din primærnøgle skal bestå af nickname og et ID nummer - så er du ihvertfald sikker! Dine andre tabeller ser også fine ud - du overholder jo de gængse krav med en samlingstabel når forholdet er mange-til-mange etc. Så jeg kan kun give dig thumbs-up:-) En sidste ting: Du har ret i, at en-mange forholdet ved Fornavn og Efternavn er irrelevant når det ikke skal bruges i andre tabeller, men du bør søge en så toptrimmet database som muligt, og derfor bør man rent teoretisk 1)Enten smide navnene i en tabel for sig eller 2)Lade dem indgå i primærnøglen eller 3)Lave en helt tredie, unik PK som eks. PersonID
Og det er jo det som du har gjort, så det er i top:-)
Angående NickName som PK, efter hvad jeg har forstået så er det hurtigere at bruge et tal feldt som PK da access er langsommere til at søge på tekst strenge. Derfor valgte jeg at bruge "PInfoId".
Jeg slettede "SoegerForhold" 'M til M' fra T_PersonInfo efter at jeg lavede E/R diagrammet, mener dette skulle være korrekt da "PInfoId" lægger i T_PersonForholdsType Det må jo være sådant det skal være?
Jeg har brugt navnet PInfoId i flere tables, vil dette give mig problemer senere?
1) Det er fint nok at du har slettet SoegerForhold fra T_PersonInfo. Ingen probs der:-) 2) Kan ikke se hvad du mener med problemer i forhold til at bruge PInfoID i flere tabeller, for det bliver du jo nødt til at for unikt at identificere personen, der "optræder" i den givne tabel... PInfoID optræder jo kun én gang som PK - alle de andre tabeller er den jo Fremmednøgle...såvidt jeg kan bedømme:-)
2)Jeg mener bare at jeg læste et eller andet sted at man burde navngi alle feldter forskelligt, selvom de representere samme info, i dette tilfælde Personens ID. Men jeg har heller ikke lige været i stand til at se hvorfor, man definere jo table.field i sin sql, dermed er de jo fint skilt fra hinanden.
Jo tak, nu kommer jo lige relations opretning og de forskellige valg der......... Der er en del ting at tænke på, men det er jo det der gør det sjovt :-)
Indeed...du poster bare igen hvis du løber ind i probs - så kigger vi på det:-)
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.