INF1300 - Høst 2016

ORM - Tips og triks

OBS:
Husk at det som står som pensum på fagsidene, er det gjeldende i dette faget. Dette dokumentet er kun ment som en rask oppsummering, og kan på ingen måte erstatte pensumbok og forelesninger. 

Her er et lite knippe tips til ting å tenke på når man modellerer i ORM. Listen er en oppsummering av hva som er gjennomgående feil på innleveringer av obliger i faget INF1300. Jeg har delt inn i tre kategorier. Først en enkel avklaring av de grunnleggende elementene vi har i ORM-modeller. Deretter de elementære feilene som mange gjør i starten, men som må være på plass før en eksamen. Til slutt gjennomgår jeg noen tips og triks til hvordan modelleringen kanskje kan gjøres/forstås litt enklere. 

 

Terminologi

 

Begrep og verditype

Begreper tegnes med heltrukken linje, verditype med stiplet linje. Det er en viktig forskjell på disse to, så pass på å notere dette riktig (se her for diskusjon om hva som skiller dem). Andre ord for verditype er representasjonstype, identifikator eller verdi.

Roller

Dette er de små boksene som står mellom to eller flere begreper eller mellom et begrep og en verditype. De noteres gjerne med et verb under seg("..har..", "..tilhører.."), og rolleparet (eller generelt de 1, 2, 3 eller flere rollene som står samlet) har alltid en eller flere interne entydighetsskranker over seg. 

Setningstype

Setningstyper er alle relasjoner mellom begreper og begreper, samt begreper og verdityper. Som oftest opptrer disse i form av binære rollepar, men mellom begrepene kan de også være unære, ternære eller generelt n-ære. Setningstyper kan igjen deles inn i to, faktatyper og broer. 

Faktatype

Den vanligste formen for en faktatype er en setningstype mellom to eller flere begreper. Merk også at unære setningstyper på et begrep også kalles en faktatype. 

Bro

En bro er en setningstype mellom ett begrep og én verditype. Det finnes to spesialtilfeller av broer - perfekte broer og synonyme broer, i tillegg til bare vanlige, generelle broer. 

Perfekt bro

En-til-en mellom begrep og verditype, samt påkrevd rolle på rollen spilt av begrepet. Gjør begrepet refererbart, og ender ofte opp som en primærnøkkel. 

Synonym bro

En-til-mange mellom et begrep og en verditype, dvs. den korte streken står over rollen spilt av verditypen. Her skjuler det seg et nytt begrep som vi må danne før vi skal realisere modellen. (Ikke særlig vanlig.)

Skranker

Skranker betyr rett og slett begrensninger. De vanligste skrankene er entydighetsskranker, mengdeskranker, verdiskranker, ringskranker og påkrevde roller (også kalt totale roller). Noen av disse kan også deles opp i interne og eksterne skranker. Interne skranker er begrensninger som gjelder én setningstype. Eksterne skranker involverer to eller flere setningstyper. 

For eksempel finnes det både interne og eksterne entydighetsskranker. Påkrevde roller har også denne inndelingen, men her er den interne varianten så vanlig at vi bare kaller den for "påkrevd rolle", mens vi spesifiserer at det er den eksterne ved å kalle den "ekstern påkrevd rolle". Mengdeskranker pleier som regel alltid å være eksterne, så vi trenger sjelden å spesifisere dette. Ringskranker er kun interne, så her er det heller ikke nødvendig å skille på dette. Verdiskranker er alltid interne. 

Entydighetsskranker

Deles igjen opp i intern og ekstern entydighet. 

Intern entydighet består av streker over roller. Disse kan være korte eller lange. En kort strek vil si en strek som går over bare én rolle. En lang strek strekker seg over to eller flere. 

MERK: Disse strekene kalles ofte for piler. Dette henger igjen fra ORM1-notasjon hvor det var piler i stedet for streker. Så når man blir bedt om å "løse opp lange piler" så er det altså lange interne entydighetsskranker det refereres til. 

Ekstern entydighet refererer til entydighetsskranker på tvers av setningstyper. Disse noteres ved en sirkel med et symbol inni (en strek), samt stiplede streker til rollene de gjelder. Husk at det er svært vesentlig hvilke av rollene i setningstypene disse stiplede linjene kobles til! 

Mengdeskranker

Disse ser ut som eksterne entydighetsskranker, bare med andre symboler i sirkelen. De kan gå mellom to roller spilt av samme begrep, eller over en kombinasjon av roller i én setningstype til en kombinasjon av roller i en annen setningstype så lenge det er de samme begrepene som spiller rollene i de to setningstypene. De vanligste er "likhetsskranke", "ulikhetsskranke" og "delmengdeskranke". Pass på at delmengdeskranken er retningsbestemt, og man må markere retningen med en pil (fra den lille mengden mot den store mengden) 

Ringskranke

Disse ligner på mengdeskrankene, men legg merke til at de har noen prikker på hver side av sirkelen der skranken blir angitt. Står alltid over roller spilt av samme begrep. Sammenlikner på verdier i stedet for mengder. 

Verdiskranker og frekvensskranker

Verdiskranker (domeneskranker) begrenser hvilke lovlige verdier en forekomst av et begrep eller en rolle kan ha. 

Frekvensskranker begrenser hvor mange forskjellige forekomster en rolle eller en samling av roller kan ha. 

Ting som må være på plass

  1. Setningstyper og intern entydighet
  2. Forhold Begreper - Verdityper
  3. Refererbarhet
  4. Løse opp lange piler
  5. Begreper med samme navn er samme begreper
  6. Vit hvilke tegn som er lov å bruke i ORM

 

1. Alle setningstyper skal ha intern entydighet

Altså, alle rollepar (disse boksene mellom to begreper) skal ha minst én strek over seg. Dersom det er flere enn to roller (f.eks. tre) så må streken være over alle eller alle minus en av rollene. Dersom n er antall roller i faktatypen, må skranken (streken) strekkes over minst n-1 bokser (roller). Setningstyper med manglende intern entydighet tyder på svært lav forståelse av ORM-modellering, og gir garantert trekk. Modellen lar seg ikke realisere når dette ikke er på plass, og det vil gi trekk på eksamen. 

2. Ha et bevisst forhold til begreper og verdityper

Er ikke dette på plass, vil man blant annet risikere å ikke klare å gjøre modellen refererbar (som er neste punkt), som igjen gjør at modellen ikke kan realiseres. 

Ofte kan man velge om noe skal modelleres som et begrep eller en verditype. Er f.eks. en persons navn et begrep eller en verditype? Vel, det spørs. Hvor "dypt" skal navn modelleres? Skal det gis ytterligere egenskaper, eller er navnet den minste atomære (meningsbærende) enheten? Navn kan for eksempel gjøres til et begrep som igjen består av "Fornavn" og "Etternavn". Navn kan også gjøres direkte til en verditype dersom man ikke ønsker å si noe om fornavn og etternavn, og navnet i seg selv er den minste enheten. 

Det kan også være greit å huske at det er kun verditypen som blir lagret i tabellen når den er realisert. Begrepene blir til navn på relasjonene. 

3. Modellen må være refererbar

Refererbar betyr at man unikt kan identifisere et objekt utifra sine verdityper. Ta for eksempel en gitt dag for en tid tilbake siden. Dersom jeg skal fortelle deg nøyaktig hvilken dag jeg snakker om, så må jeg oppgi informasjon som skiller denne ene dagen fra alle andre dager. En vanlig måte å gjøre dette på, er å oppgi hvilket år det er snakk om, hvilken måned det er snakk om, samt hvilken dag i måneden det er. Altså - kombinasjonen av år, måned og dag gjør hver enkelt dag unikt refererbar. Det er ingen tvil om nøyaktig hvilken dag jeg snakker om.

Et annet eksempel kan være det abstrakte begrepet Person. Dersom jeg skal fortelle deg om en gitt person, må jeg ha en unik måte å identifisere personen på slik at du vet hvem jeg snakker om. Jeg kan kanskje oppgi hvor gammel personen er, og hvor personen studerer. Dette er attributter personen har som kan inngå i en unik referansemåte. Men for å være helt sikker på at vi snakker om samme person, må jeg kanskje oppgi noe så spesifikt som fornavn og etternavn, eller kanskje fødselsdato og personnummer. Først da vet du nøyaktig hvilken person jeg snakker om.

Legg altså merke til - mange av begrepene vi bruker er abstrakte (En dag, En person) Vi gir denne abstrakte "ideen" noen egenskaper som hjelper oss med å identifisere hver enkelt forekomst av denne mer abstrakte "ideen". Dersom hvert objekt av en slik "idé" er unikt identifiserbart via noen attributter, så kan vi si at "ideen" - eller begrepet i vårt tilfelle - er refererbart via disse attributtene.

For å kunne realisere vår ORM-modell må alle begreper kunne entydig identifiseres. Dette er de fire eneste måtene som kan gjøre et begrep refererbart i en ORM-modell: 

 

Alle unike kombinasjoner som gjør et begrep refererbart, kommer til å ende opp som kandidatnøkler. Det er blant disse vi også plukker relasjonens primærnøkkel. 

At modellen er refererbar, er helt elementært, og må være på plass mot eksamen. Du burde minimum beherske å gjøre et begrep refererbart via perfekt bro, og via ekstern entydighet. Dette er de to vanligste formene å gjøre det på. 

Her passer det også å snakke litt om bruken av ID. Mange tenker at man kan bare gi alle begreper en unik ID og dermed er modellen alltid refererbar. Min kommentar til dette er at det er nok det man i praksis ville gjort i en del tilfeller. Men dette er i så fall av hensyn til optimalisering av databasen i forhold til lagringsplass eller oppslagstid - ikke fordi det er slik relasjonen mellom dataene nødvendigvis er. I INF1300 er målet å lære det grunnleggende og forstå hvordan sammenhengen mellom data skal forstås. Dersom man ikke lærer seg å gjøre ting uten bruk av ID, vil man siden ikke kunne ta et aktivt valg på hvorvidt det skal benyttes eller ikke. Vær derfor kritisk til bruk av ID - prøv heller andre primærnøkler som Navn, kombinasjon av Boktittel+Sidetall, kombinasjon av Dag+Hendelse, kombinasjon av liste+listelinjenummer og så videre. Veldig ofte kan nesten alle begreper identifiseres/representeres på en slik måte uten bruk av ID. Dessuten er det slik at om man bare nøyer seg med IDer (løpenumre) for å slippe å forholde seg til f.eks. eksterne entydigheter, så blir modellen feil fordi man "mister" andre kandidatnøkler enn primærnøklene når man realiserer modellen. 

4. Man må lære seg å løse opp lange piler

Dette betyr ikke at man må løse opp alle lange piler før man realiserer en modell. Men når man realiserer en lang pil, så løser man den i praksis opp. Dessuten finnes det tilfeller hvor man ønsker å gå fra lang pil til begrepsdannelse, eller motsatt for å få satt på andre skranker riktig. Se foilene for hvordan dette gjøres - dette må være på plass før eksamen. 

5. Gjentakelse av begreper

Det går helt klart an å repetere det samme begrepet flere steder i modellen. Enkelte ganger er det til og med helt nødvendig for å få bedre oversikt, og fordi modellen kanskje må deles opp i flere mindre modeller. Men man må da huske på at alle begrepene med samme navn faktisk representerer det samme begrepet. Så når dette realiseres, kommer alle relasjonene til alle begrepene med samme navn til å havne i samme relasjon. Man snakker altså hele tiden om det samme konseptet, det er bare at man av praktiske hensyn velger å tegne det flere steder. 

Men hva om for eksempel en person skal gifte seg med en annen person? Skal man da bruke to Person-begreper? 

Vel, både og. Ja, man kan gjøre dette. Men husk at det finnes i så fall kun ett begrep Person, og det samme begrepet gjentas bare to ganger. Så når modellen realiseres, så vil disse to begrepene med samme navn (som representerer det samme konseptet) ende opp som en og samme relasjon. Så i eksempelet med "Personen Ola gifter seg med Personen Kari" så vil det ofte være mest naturlig å modellere dette som ett begrep som spiller begge rollene i en binær relasjon. 

6. Vit hvilke tegn som er lov å bruke i ORM-modeller

Til slutt - innimellom det noen som finner opp noen egne tegn som de putter inn i modellen. Unngå dette. ORMs tegn klarer å fange opp stort sett alle ønskelige og fornuftige relasjoner. Anbefaler derfor at man sjekker ORM-cheat-sheeten som finnes i boka eller på INF1300 nettsidene dersom man tenker å benytte et tegn som ikke er så mye brukt. 

Styr også unna å blande ORM1 og ORM2 tegn, bruk den ene notasjonen konsekvent. Jeg anbefaler på det sterkeste å benytte seg av ORM2 notasjon da det er dette som benyttes i kurset (det er det som står omtalt i cheat-sheetet, og det som vises på de fleste forelesningsfoiler). 

Ønsker man å sette en skranke som det ikke finnes noen tegn for i ORM, se muligheten for å sette en stjerne (*) og å skrive en kommentar. 

Generelle tips

  1. Elementære setninger
  2. Gi mening
  3. Skranker
  4. Påkrevde roller

 

1. Bruk elementære setninger

Husk at alle relasjoner kan/skal utrykkes med elementære setninger. De innleveringene jeg får inn som benytter seg av elementære setninger, er ofte svært gode, om ikke perfekte. Det skal godt gjøres å bomme på modelleringen dersom man har utformet en riktig elementær setning. 

Ta for eksempel oppgave 5 i oblig 6 fra 2014 (lag en ORM-modell som beskriver forskjellige måleenheter...) Svært mange syntes denne er vanskelig å løse direkte. Men hva om man starter med en elementær setning? 

"En kopp tilsvarer 400 gram."

Denne kan leses som 'måleenhet' tilsvarer 'faktor' 'måleenhet'. 

En alternativ elementær setning som utrykker det samme, vil være "Forholdet mellom måleenheten kopp og måleenheten gram er faktoren 1 til 400." 

Jeg regner med at det er helt opplagt at vi her snakker om to begreper, "Måleenhet" og "Faktor", samt tre roller (måleenhet-fra, med-faktor, måleenhet-til). Altså, en ternær faktatype hvor måleenhet spiller to roller, og faktor en. 

Slik kan altså denne oppgaven løses ved å tenke via elementære setninger. Også alle de andre ORM-modelleringsoppgavene kan løses så enkelt via elementære setninger. 

2. Er det lov? Vel - gir det mening? Er det nødvendig?

Svært ofte kommer det opp spørsmål om hvilke regler en modell må følge. Er det f.eks. lov å ha mange til mange mellom begrep og verditype? Er det lov å ha både delmengdeskranke og ulikhetsskranke over de samme rollene? Kan man ha en-til-en mellom to begreper? 

Vel, svaret er som oftest: "Gir det mening?" og "Er det nødvendig?". Dersom man forstår betyningen av de egenskapene man har satt på sine begreper og roller, så kan man selv finne ut av om det er riktig ved å stille disse to spørsmålene. 

Skal det være en-til-en mellom Dato og Måltid? Antageligvis ikke, man har antagelig flere måltider per dag. Skal det være mange til mange mellom Person og Fødselsdato? Nei, man har antageligvis bare én fødselsdato. Kan en binær faktatype både ha en-til-en skranke og mange-til-mange skranke? Nei, en-til-en utelukker muligheten for mange-til-mange uansett. Det gir heller ikke helt mening å ha ulikhetsskranke og delmengdeskranke over samme roller. Hele veien gjelder altså prinsippet; "Gir det mening?" 

3. Pass på bruken av skranker

Er du usikker på om en skranke skal være med? Vel - da ville jeg kanskje droppet å ta den med. Det skinner ofte lett gjennom at man ikke har forstått bruken av forskjellige skranker når de havner på gale steder. Og det kan lett skje. Det er også et klassisk trekk ved svake besvarelser at kandidaten forsøker å "lure" retteren ved å gjette seg frem til noen skranker for å prøve å overbevise om at han eller hun har forstått bruken. Det ser veldig ofte bare dumt ut for en som har god kjennskap til ORM-modellering. Da er det kanskje bedre om sensor forblir uvitende om hvorvidt du kan det eller ikke - hvis du bruker det feil så vet sensor at du ikke kan det... 

Jeg tror den vanligste "feilplasseringen" av skranker som forekommer i obliger og eksamen, er feilplassering av påkrevde roller og ekstern entydighet, med mengdeskranker på en god tredjeplass. Her er noen gode huskeregler på når disse skal være med: 

Påkrevde roller

Veldig ofte opptrer disse i forbindelse med følgende: 

  1. I forbindelse med en primær- eller kandidatnøkkel.
  2. Fordi oppgaveteksten spesifikt ber om dette.

 

Så, dersom du vurderer å sette en påkrevd rolle og er usikker - vurder om noen av disse to kriteriene er oppfylt. Hvis ikke de er det, ville jeg latt den stå uten påkrevd rolle.

 

Ekstern entydighet

Egentlig gjelder de samme reglene her som for påkrevde roller. De opptrer som regel i følgende situasjoner: 

  1. I forbindelse med primær- eller kandidatnøkkel.
  2. Fordi oppgaveteksten spesifikt ber om dette / det er helt åpenbart.

 

Samme regel her - er du usikker, og ikke føler at noen av disse to tilfellene er oppfylt, så ville jeg droppet å sette en ekstern entydighet. Husk også at ekstern entydighet alltid gjelder kun ett begrep, men står på de rollene i rolleparene som ikke spilles av det begrepet (se lenger opp om ekstern entydighet).

 

Det kan også være et triks å prøve å gjøre om den eksterne entydigheten til en binær faktatype (gjøre om til lang pil). Dette gjøres rett og slett ved å gjøre det motsatte av hva man gjør når man løser opp en lang pil. Da skal den eksterne entydigheten være tilsvarende den interne entydighetsskranken i setningstypen som oppstår. 

Mengdeskranker

Er du usikker på hvordan disse benyttes - vel, bruk de kun dersom oppgaveteksten etterspør dette. Husk at disse alltid står over to eller flere roller spilt av samme begrep. 

4. Husk å tenke på om rollene skal være påkrevde.

Svært mange glemmer å tenke på om rollen skal være påkrevd eller ikke (den fete prikken). Igjen, her er det en fin balanse mellom å ikke gjøre for mange roller påkrevde, samt å finne ut hvem roller som må være påkrevde for at modellen skal gi mening. Noen påkrevde roller er helt opplagte - andre er diskutable og uten fasitsvar. 

5. Husk hvorfor vi modellerer - realisering og forklaring.

Dette punktet burde kanskje vært helt først på denne listen. Men ofte er dette noe man ikke innser før man har forstått det øvrige (og så innser man at dette punktet er kanskje det viktigste). 

En ORM-modell kan sies å ha to formål: 

  1. Å illustrere hvordan man tenker på en informativ, enkel og oversiktlig måte.
  2. Å danne grunnlag for en database som kan løse det konkrete problemet (realiserbar modell).

 

Det første punktet handler altså om å utrykke hvordan man tenker uten å måtte tenke på konkrete tekniske implementeringer i en database. Hvis jeg skal forklare hvordan jeg ser for meg at en rekke data henger sammen uten tanke på teknisk løsning, vil en ORM-modell kunne være et nyttig verktøy. Det er mye enklere og oversiktlig for deg å lese en modell med ternære og kvartære faktatyper, ekstern entydighet, kanskje noen ringskranker samt begreper og verdityper som alle sammen kan dannes om til elementære setninger, enn å få en rekke SQL create-setninger som viser hvordan databasen er. Og spesielt nyttig er det for kunden - nå kan jeg bare be kunden utrykke med vanlig språk hva hun ønsker seg, hvilke relasjoner som databasen hun trenger må fange opp, også kan jeg modellere det. Dersom jeg skal presentere mitt forslag for kunden, trenger hun ikke å kunne noe som helst om SQL. Om hun ikke forstår ORM-modellen (noe de aller færreste gjør), kan jeg veldig enkelt gjøre den om til helt vanlige elementære setninger som alle kan forstå. 

Det andre formålet med ORM-modeller er å danne grunnlaget for å opprette en relasjonsdatabase som kan brukes i praksis. Da må man altså ta høyde for alle krav som stilles for å opprette slike tabeller. ORM har noen få regler (bl.a. refererbarhet og entydighet) som sørger for at man oppfyller disse reglene automatisk. For å kunne realisere må man også løse opp alle n-ære faktatyper til binære faktatyper (løse opp lange piler). En slik oppløst modell vil ikke være like oversiktlig som modellen i det første tilfellet, men nå lar modellen seg realisere. Heldigvis finnes det en enkel oppskrift (algoritme) man bare kan følge, så løser dette seg av seg selv. 

Når det gjelder INF1300 ville jeg anbefalt å gjøre begge dele. Bruk lange piler (n-ære faktatyper) der hvor det er naturlig og mest oversiktlig. Dersom man blir bedt om å realisere slike lange piler, så viser man hvordan man tenker å løse dem opp. Altså, tegn et lite utsnitt der du viser hvordan begrepsdannelsen modelleres, også noterer du hvordan denne realiseres. Da har du vist både at du klarer å tegne en oversiktlig og god modell, og du har vist at du forstår hvordan du bryter den ned og får realisert den. 

 

 

Skrevet av Simen Buodd 2014-2015.
Takk til Ellen Munthe-Kaas for faglig input og korrektur