Spørsmål om database (begrep og modellering)

[NoobMaster]

Hei alle sammen.

Jeg har noen spørsmål om database-begrep og modellering. I it-faget jeg har nå skal jeg forklare hva redundans, attributter og entiteter er. I tillegg skal vi lage en datamodell til et scenario. Slik jeg har forstått det betyr redundans å sørge for at det finnes flere kopier av data, slik at om én server går ned, er databasen fortsatt tilgjengelig. Attributter er navnet på kolonnene i en tabell, mens entiteter er radene.

Har jeg forstått dette riktig, eller finnes det andre forklaringer?

 

I tillegg skal vi lage en datamodell til en oppgave som handler om en bilklubb som inneholder medlemmer, biler, bilturer, kontaktinformasjon, osv. Det "vanlige", egentlig. Da lagde jeg modellen som er vedlagt (under?). Kunne jeg ha fått noen innspill?

 

Takker for svar på forhånd.

[Thorbear]

Hehe, redundans er jo et ord som kan bety flere ting, avhengig av sammenhengen. I enkelte sammenhenger er det som du sier, at man med vilje lagrer data i flere kopier for å ikke miste noe, det kan også brukes om å ha flere servere, for å holde en nettside oppe gjennom strømbrudd på én lokasjon. Generelt sett betyr ordet at man har mer av noe enn det som er absolutt nødvendig.
I IT-faget snakker de ofte om redundans i forbindelse med normalisering av tabeller, der målet er å unngå å lagre samme informasjon flere steder, slik at det er færre steder man må oppdatere om en verdi endres.

Når det gjelder attributter og entiteter, så snakker vi ofte om at "en entitet har attributter", der en entitet er "en ting", for eksempel en bil eller en person, og attributtene til disse entitetene er for eksempel navnet til en person eller fargen på bilen.

I datamodellen din ser det ut som du har kommet et stykke på vei, men det føles som om noe mangler. Hvordan kobles "Kontaktinformasjon" sammen med "Medlemmer"? Jeg kan ikke se hverken PK eller FK i Kontaktinformasjon, som vil gjøre det litt vanskelig å vite hvilke rader som hører til hvilke medlemmer. Jeg ville kanskje også trodd at telefonnummer, postnummer, adresse, og epost gikk som kontaktinformasjon?
I koblingen mellom biler og bilturer så er det en mange-til-mange kobling, her veit jeg ikke hvor detaljert modellen skal være, eller hva dere har lært om så langt, men når dette skal implementeres så vil det måtte være en tabell mellom disse to, for å få til mange-til-mange koblingen.

[TitanSable]

Siden det åpenbart er snakk om relasjonsdatabaser så er redundans noe man forsøker å unngå: som det står over her så betyr det at samme data ligger flere steder. Som oftest ønsker man da å normalisere for å unngå dette.

Entiteter er objekter og ligger i rader i tabellene. Attributter er egenskaper og ligger i kolonner. Semantikken din er litt unøyaktig der siden rader er rader og kolonner er kolonner, det er f.eks. ikke noe 1:1 forhold mellom rad og entitet selv om entiteter ligger i rader. Du blander litt mellom hva det er og hvordan det lagres.

Modellen er litt uferdig, som @Thorbear påpeker. 
•    Du har både email, adresse og telefon i "Medlemmer"-tabellen. Hva ser du for deg ligger i "Kontaktinformasjon" da?
•    Biler kan fint ha flere attributter. Avhengig av hvor mye jobb du vil legge i dette kan også merke og modell legges ut i egen tabell.
•    Mange-til-mange mellom biler og bilturer bør ha en koblingstabell. Dersom du ønsker at et medlem kan låne bilen til et annet medlem på en tur så legg til medlem i den samme tabellen og bruk UK til å sikre at et medlem kun er med én gang på en gitt tur.
•    Selve turen burde i det minste ha med utgangspunkt og antall kilometer. Jeg ville modellert inn hele reiseruten.
•    Osv. Det er alltid ting man kan gjøre annerledes. Tenk på hva modellen skal brukes til og hva som er hensiktsmessig å ha med (og hva som ikke er relevant).
 

[quantum]

Enig med det som skrives over her. 

Jeg tror du har tenkt at tabellen kontaktinformasjon er en "tilleggstabell", hvor man kan legge inn et ekstra telefonnummer, email eller lignende "one-liner", mens primæradressen ligger i medlemstabellen. Det er forsåvidt OK å gjøre det slik, men du kan da ikke få lagt inn separat fakturaadresse og postadresse hvis den skiller seg fra bostedsadresse eller lignende. Det kan hende det er ok, eller ikke, avhengig av hvordan dette skal brukes. Uansett må du ha en FK til medlemstabellen, og en PK. Og så bør vel medlemstabellen også ha poststed, ikke bare postnummer, selv om sted kan utledes av nummer på ulike vis. Hvis du har tenkt å gjøre det bør det nok med i en kommentar.

N:N-kobling MÅ ha en knyttetabell i den fysiske modellen, men hvis dette er en logisk modell så vises den vel normalt ikke frem.  Den må være der i databasen. Jeg vet ikke hvaslags modell dere skal lage, så det bør du få klarhet i. Jeg vil tro det er meningen du skal vise at du forstår hvordan en N:N-knytning implementeres og da må du vise knyttetabellen.

Er også litt usikker på meningen med N:N-knytningen mellom bil og tur. Er det sånn at flere biler skal kunne registrere seg på samme tur, eller den samme bilen ta samme tur flere ganger? Siden tur-tabellen ikke har noe dato så kan det tyde på at det er tenkt slik. I såfall kan du lagre dato for bilens tur i knyttetabellen. Og så må vel turen også ha et startpunkt, eller er det ment å være slik at alle turene starter fra klubbens hjemby? 

Det står en del om databasenormalisering på wikipedia. Det kan være greit å lese gjennom, trenger ikke forstå alt 100% på første forsøk ... ?

Endret 25. februar 2020 av quantum

[quantum]

PS, det kunne vært greit å vite noe om hvaslags bilklubb dette er også. Det kan være en tur/am-car-klubb/veteranklubb. Da kan det sikkert være fint om tur-tabellen inneholder info om fine steder å stoppe, om destinasjonen er i hjembyen til en venne-klubb osv. Eller er det et bilkollektiv? Da vil ting som km, booking av datoer osv. være mer interessant.

[TitanSable]

5 minutes ago, quantum said:

Og så bør vel medlemstabellen også ha poststed, ikke bare postnummer, selv om sted kan utledes av nummer på ulike vis.

Dersom man skal ha med poststed, noe jeg er enig at man bør ha med, så bør jo det normaliseres og ikke ligge i selve medlemstabellen.

[quantum]

TitanSable skrev (49 minutter siden):

Dersom man skal ha med poststed, noe jeg er enig at man bør ha med, så bør jo det normaliseres og ikke ligge i selve medlemstabellen.

Forsåvidt. En kunne jo tatt det enda lengre, som vel diverse katalogtjenester gjør, å skille ut hele adressen med gatenavn og nummer også, så kan man se hvor mange som bor i en husstand når man søker på en adresse, f.eks. 

I praksis så er man ofte pragmatisk i forhold til slike ting og det mest vanlige i medlemsregistre og lignende er nok å ikke normalisere begrepet adresse helt ut, selv om det medfører lagring av redundante data å ikke gjøre det. Ved full normalisering ender man ofte opp med veldig mange tabeller som det blir unødvendig kronglete å programmere mot. Dog er det kult om poststedet popper opp automatisk når postnr er tastet inn, så for all del. Man må rett og slett ta avgjørelsen basert på hva systemet skal brukes til.

Prisen det koster å lagre litt redundante data er fort spart inn i utviklingskostnader. Selv om mange ulike medlemmer bor i samme by, er det ikke et problem utover plassforbruket, så lenge det er entydig for hvert medlem hvilken by vedkommende bor i. Verre er det om redundante data fører til tvetydighet, slik at et medlem for eksempel kan knyttes til mange adresser, uten at man vet entydig hva som er bostedsadresse, hva som er postadresse og lignende. Eller i et handelssystem; da er det svært uheldig om en faktura står som betalt i en tabell og ubetalt i en annen, har ulike antall varer, varene har ulike priser osv, ettersom hvor man slår opp. 

Jobbet en gang med en database, den gangen hvor fasttelefon var vanlig, og medlemsregistret skulle være sånn at man ikke lagret redundante telefonnummere, altså egen telefontabell med en rekke unike numre, hvor flere i samme husstand da skulle knyttes mot samme telefonnummer. Husker ikke helt hvordan det gikk i det prosjektet, men det er nok det lengste jeg har sett noen dra normalisering i praksis. Vanligvis er man mer pragmatisk.

[TitanSable]

33 minutes ago, quantum said:

Vanligvis er man mer pragmatisk.

Jeg regner med at dette er en innlevering og da normaliserer man ? 

[quantum]

TitanSable skrev (1 time siden):

Jeg regner med at dette er en innlevering og da normaliserer man ? 

Til hvilken normalform da? ?

[TitanSable]

1 hour ago, quantum said:

Til hvilken normalform da? ?

Nå er det mange år siden jeg har levert oppgaver på dette, men jeg har jo stilt opp som eksamenssensor noen ganger.

Jeg ville gått for 2.5, dvs, ha postnummer+sted i samme tabell. Det ville ikke plaget meg nevneverdig å ha redundans på stedsnavn og jeg ville ikke gitt trekk for den løsningen. Stedsid+stedsnavn i egen tabell kan gi verdi i enkelte tilfeller, men dersom kun postnummer/sted er trekt ut så er det godt nok til å vise at man forstår modellering. 

[TitanSable]

4 hours ago, quantum said:

Man må rett og slett ta avgjørelsen basert på hva systemet skal brukes til.

Ja, hvis det kun er for å lage fakturaer så er det jo antageligvis feil å normalisere. Erfaring tilsier dog at før eller senere kommer det en nisse som skal ha en tullete rapport. 

Endret 25. februar 2020 av TitanSable

[quantum]

Nissen ja, hehe ...