Access, lage database

[AnAbo]

Hei! jeg skal lage en database ut ifra vinmonopolets nettsider. Innholdet skal kun omhandle VIN.

informasjon som skal inn er som følger:

 

Type vin

produktnavn

produsent

årgang

alkoholprosent

land

distrikt

smak

mat

 

Har rett og slett problemer med å se en logisk måte å dele dette opp i fornuftige tabeller.

Noen som kan hjelpe? tipse?

 

EDIT:

Jeg lurer på hva som er fornuftig fordeling av tabeller.

Det skal bare lages små eksempler med informasjon i tabellene, så det blir ingen stor database.

Tror kanskje det ville være greit og dele den opp mest mulig på en fornuftig måte.

Hadde vært strålende om noen kunne hjulpet meg for eksempel med en illustrasjon i og med at jeg ikke har mye forståelse for dette faget!

Jeg bruker programmet powerdesigner til å lage databasen, men jeg kan lage en database i powerdesigner utifra eksempler i access ogsåvidere dersom det skulle vært aktuelt.

 

kan også nevnes at type mat skal foreslås ut ifra type vin i tabellen. ikke hvilken type vin som passer til hvilken mat.

 

 

på forhånd takk for all hjelp

 

mvh Andrè

Endret 8. november 2012 av Soetz

[hjahre]

Hvor mange joins vil du ha?

Jeg tenker at du vil ha vintype, produsent, land, distrikt og mat i sine respektive tabeller. Smak vil du sannsynligvis også ha i egen tabell. Resten kan du slenge inn i samme. Også ville jeg ha sørget for å ha fremmed-nøkler som sier hvilke verdier som er gyldige verdier. Enkelt sagt så vil du sannsynligvis ha minst mulig dobbeltlagring. Men dette kan gå utover hastighet, så ved store databaser ville jeg ha vurdert å ha en "key-value"-store. I ditt tilfelle vil jeg tro det funker fint med forskjellige tabeller.

 

EDIT: Jeg vil tro denne posten hadde passet bedre i Database-forumet, tror du ville fått fler svar der

Endret 8. november 2012 av hjahre

[The Stig]

Om feltene du nevner er alle du skal ha med kan du faktisk ha alle i en og samme tabell - men, mistenker du at du etter hvert vil utvide må du nok dele opp litt. Anbefaler at du deler opp tabeller etter kategorier, for eks. vin og produsent. Bruk fremmednøkler og lag relasjoner mellom alle tabeller, hvor et naturlig midtpunkt er vin.

[nomore]

En hovedregel som en lærer lærte meg en gang er at dersom to eller flere rader inneholder samme informasjon, så bør det lagre i en ny tabell og joines inn.

[AnAbo]

takk for mange gode svar! jeg lager en ny post i databasetråden, med litt mer utfyllende spørsmål!

[hjahre]

Nå er denne tråden automagisk flyttet til database-forumet, så jeg vet ikke om du trenger å lage ny tråd. Er greit å ikke la forumet flømmes over av nesten like tråder

[AnAbo]

Ah okei! takker!

 

Jeg lurer på hva som er fornuftig fordeling av tabeller.

Det skal bare lages små eksempler med informasjon i tabellene, så det blir ingen stor database. tror kanskje det ville være greit og dele den opp mest mulig på en fornuftig måte.

 

Hadde vært strålende om noen kunne hjulpet meg for eksempel med en illustrasjon i og med at jeg ikke har mye forståelse for dette faget! Tusen takk!

 

Edit: jeg bruker powerdesigner til å lage databasen.

kan også nevnes at type mat skal foreslås ut ifra type vin, og ikke motsatt.

Endret 8. november 2012 av Soetz

[hjahre]

Du burde ha tabeller med unike rader og der så lite informasjon som mulig går igjen. Dette kan føre til at du må joine noen tabeller når du skal finne viner, men det er ikke mye som må til.

 

Jeg har laget et lite diagram som burde funke OK, men det kan sikkert gjøres en del forbedringer. Det må sies at jeg ikke er så stødig i UML, hadde det vært ORM hadde det vært lettere

[AnAbo]

hvorfor gir alt så mye mening når det er ferdig, men det er umulig å få til å lage mening når jeg skal lage det selv?!

Tusen hjertelig takk for et supert utgangspunkt! jeg skylder deg en tjenest. :>

[hjahre]

Jeg vet akkurat hva du mener, er ikke alltid like lett å vite hvordan man skal stykke opp tabeller. Det kan hende du må opprette noen felter i tabellene for å få alt til å fungere, jeg har ikke erfaring med PowerDesigner så vet ikke åssen den funker. Og jeg visste ikke om du ville kunne finne land ut fra produsent og motsatt, eller om du måtte innom vinen. Land-tabellen kan splittes mer, men jeg så ikke vitsen med det ettersom det ville ført til to ekstra tabeller og én tabell som var like stor. Det hadde vært greit med tanke på skrivefeil osv, men det kan man sjekke på andre måter

[quantum]

 

Jeg har laget et lite diagram som burde funke OK, men det kan sikkert gjøres en del forbedringer.

Unektelig ... et tips kan jo være å bruke ER istedenfor UML, så slipper du å modellere klasser når du tror du modellerer tabeller Da blir det sikkert lettere å holde styr på hvilken vei 1:n-relasjonene skal gå også, du har prøvd å bruke arv til å uttrykke dette, og så har det gått i ball for deg med retningen på pilene.

 

Tror også det er lurt å tenke én gang til gjennom hvor lurt det egentlig er med 1:n-relasjon mellom vin og mat, og vin og smak. En vin kan passe til mange matretter, men hver matrett kan kun passe til én vin. Det fjerner jo valgets kvaler når menyen er gitt ... meeeen ....

 

En bør også tenke gjennom tekniske nøkler (f.eks. et tall som økes med en hver gang ny rad settes inn i en tabell) vs. naturlige nøkler (som navn på vinprodusent). Ser ut som du har tenkt å ha naturlige nøkler, og det du skal tenke på da er at om produsenten skifter navn, så vil Vin-tabellens FK også måtte oppdateres.

 

En annen ting å tenke på her er at alle tabellene - bortsett fra de som helst skulle inngått i n:n-relasjoner, samt selve vin-tabellen - er overflødige, så lenge de ikke inneholder annen informasjon enn det som må inngå i primærnøkkel.

 

La oss se på tabellen Land. Her må både land og distrikt inngå i PK for å få unikhet, og da vil igjen disse verdiene måtte dupliseres inn i Vin som FK, og vips ser vi da at tabellen Land er overflødig, siden den ikke inneholder mer informasjon enn akkurat det som ligger i PK. Nå refereres også Land fra Produsent på samme måte, men fordi Produsent også kan elimineres på samme måte som Land, og fordi både Produsent og Vin nødvendigvis må komme fra samme land og distrikt, så kan vi droppe Produsent også.

 

Men; når dette er sagt, det er ikke særlig vanskelig å se for seg at man etterhvert vil legge inn flere felt i både Land og Produsent, og da må de skilles ut i egne tabeller likevel. Jeg er heller ikke noen tilhenger av naturlige nøkler, og det peker også i retning av flere tabeller. Det fundamentale her er å få orden på det logiske nivået - denne modellen sier at det bare fins en vin i verden som passer til lammekoteletter, og bare en vin i verden med smak av eik og solbær.