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