*UXSSHULQJ IRU JUDXWVNDOOHU (QYLVXHOOJXLGHJMHQQRPQRHQ DY1,$0JUXSSHULQJHQV XQGHUIXQGLJKHWHU

*UXSSHULQJ IRU JUDXWVNDOOHU (QYLVXHOOJXLGHJMHQQRPQRHQ DY1,$0JUXSSHULQJHQV XQGHUIXQGLJKHWHU

Historikk (Ikke bruk tid på å lese dette, den nyttige informasjonen begynner på neste side...) Ideen til å lage en relativt enkel og visuell forklaring for villfarne gruppedeltakere ble født en ettermiddag høsten 1999, da undertegnede satt og rettet nisseoppgaver og rev seg i sitt hår: Ille hvor grundig det går an å misforstå NIAM-modellering, og spesielt gruppering, tenkte vi da. Noen burde skrive en rett-på-sak forklaring! Vi vurderte først å kaste oss over en mektig oppgave: Å skrive NIAM for Nolduser TM, den kunne sikkert blitt interessant den, men vi hadde jo andre ting å drive med også, så den kom seg aldri forbi idé-stadiet. Senere i semesteret da veterinæroppgavene datt inn i hylla, så vi til vår store skrekk og gru at mange fortsatt ikke hadde lært seg å gruppere skikkelig. Da kom idéen til et noe mindre prosjekt; en idé som i høstsemesteret 2000 er i ferd med å bli virkelighet: Gruppering for Grautskaller TM - Et dokument som tar sikte på å avdekke mysteriet bak grupperingen og gi deg praktiske eksempler som du kan bruke! Skrevet av: Frank Johnsen Åndelig støtte: Trude Hafsøe Side 2 av 16

%HJUHSHURJUHSUHVHQWDVMRQVW\SHU Et begrep tegnes som en heltrukken sirkel. Begrepets navn skrives inne i denne sirkelen. En representasjonstype er en stiplet sirkel. Den forteller oss om en mulig representasjon for ett begrep. Legg merke til den perfekte broen mellom begrepet "person" og representasjonstypen "f.nr". Dette betyr at en person i denne modellen kan representeres ved fødelsnummeret, dvs. at ett fødselsnummer entydig angir én person. Når vi grupperer er det representasjonen som blir primærnøkkel i relasjonen: Person F.nr for OBS! Dersom det finnes flere kandidatnøkler (mulige primærnøkler) må vi velge en av dem. OBS! Legg merke til at attributtene i en relasjon blir en kombinasjon av navnet på den grupperende rollen og navnet på representasjonstypen (evt. begrepet) som er med i det binære utsagnet. Som dere vil se dersom dere orker å lese resten av dokumentet, så gir dette til tider noen ikke fullt så gode attributtnavn. Det er fordi jeg er lat og ikke gidder finne på gode rollenavn. Side 3 av 16

8QGHUWU\NNLQJDYUHODVMRQHU Når vi modellerer NIAM får vi en god del flere begreper enn det er hensiktsmessig å lage relasjoner av. Betrakt denne enkle modellen: Her har vi to begreper; "person" og "adresse", deres representasjonstyper og forholdene mellom dem. Ved gruppering gir alle begreper opphav til en relasjon. Dette innebærer at vi her skal ha en relasjon for person der fødselsnummer er primærnøkkel og adresse er et vanlig attributt, og en relasjon for adresse der gatenavnet er primærnøkkel: Person F.nr for Bosted for Adresse Gatenavn for Legg merke til at adressen skal grupperes inn i personrelasjonen og ikke omvendt, ettersom entydighetsskranken står nærmest personbegrepet. Vi får en fremmednøkkel fra adressen i person til adresserelasjonen. I dette tilfellet ser vi at all informasjon finnes i personrelasjonen, og at en egen adresserelasjon derfor strengt tatt er unødvendig. Ved å undertrykke adresse får vi følgende: Person F.nr for Bosted for OBS! Vær oppmerksom på at du kun kan undertrykke relasjoner dersom informasjonen finnes i andre relasjoner allerede. Gode kandidater for undertrykking er begreper som omhandler mål, vekt og liknende. Side 4 av 16

6NUDQNHUHUYLNWLJHIRONHQV Ethvert binært utsagn (=forhold mellom to begreper) må ha en entydighetsskranke. Skrankene er nødvendige for å angi hvor mange ganger et begrep kan spille den gitte rollen, og legger dermed grunnlaget for grupperingen. Noen eksempler på ulik skrankesetting mellom to begreper: Her sier vi at en bil må eies av en person, men en person kan eie mange biler. Her vil grupperingen i alle fall frambringe en Bil-relasjon, Person er ikke så spennende i dette tilfellet og blir undertrykt: Bil Reg.nr. for Person eier Her sier vi at en person må eie en bil, men at en bil kan eies av mange personer. Her er det Person som er den interessante relasjonen: Person F.nr for Bil eies av Side 5 av 16

Her sier vi at en person kan eie mange biler og at en bil kan eies av mange personer. Dette er en såkalt begrepsdannelse, og er den svakeste skranken vi kan sette. Ettersom NIAM-Suiten ikke kan tegne den nødvendige sirkelen og navngivningen på en begrepsdannelse angitt ved lang entydighetsskranke, må en splitte opp forholdet og angi det samme ved bruk av ekstern entydighet. Når dere modellerer for hånd kan dere selvfølgelig fritt velge mellom de to måtene å tegne det på. Relasjonene dere får etter grupperingen vil uansett være de samme. Vi kan da angi eierforholdet slik : Gruppering gir oss disse tre relasjonene: Person F.nr for Bil Reg.nr for Eieforhold Person eier Bil eies av Side 6 av 16

Her vil Person og Bil i Eieforhold-relasjonen være fremmednøkler til henholdsvis Person- og Bilrelasjonen. I dette tilfellet kunne vi dessuten godt ha undertrykt Person og Bil, ettersom all informasjon finnes i Eieforhold. Her sier vi at en bil kan eies av kun en person, og at en person kan eie kun en bil. Dette er den sterkeste skranken vi kan sette. Legg merke til at det ikke er satt noen påkrevd rolle på noen av sidene her. Det betyr at vi står fritt til å velge om bilen skal grupperes inn i personrelasjonen eller omvendt. Ikke under noen omstendighet må man finne på å gruppere inn i begge relasjoner! Her kan vi altså gruppere enten slik: Person F.nr for Bil Reg.nr for Person eier Person i Bil-realsjonen er fremmednøkkel til Person-relasjonen. Eller slik: Bil Reg.nr for Person F.nr for Bil eies av Bil i Person-relasjonen er fremmednøkkel til Bil-relasjonen. Her ville det vært mulig å undertrykke Person i det første tilfellet og Bil i det andre, dersom en skulle ønske det. Side 7 av 16

Side 8 av 16 OBS! Dersom vi påkrever en av sidene i utsagnet mellom bil og person i den siste modellen, så er det det begrepet som har den påkrevde rollen nærmest seg som får det andre inn i sin relasjon. OBS! Begrepsdannelser skal ha egne navn og gir opphav til egne relasjoner.

(NYLYDOHQWHYHLHU Betrakt følgende modell som omhandler kinobilletter: Når vi grupperer en modell med ekvivalente veier (Equivalence Of Path), må vi passe på at vi bevarer denne skranken. Velger her å undertrykke Dag og Kinosal. Vi får da følgende tre relasjoner: Sete Kinosal har Setenr for Forestilling Kinosal har Dag for Billett Setenr på Dag på Sete kinosal på Forestilling kinosal på Legg merke til Billett-relasjonen! Her forekommer kinosalen to ganger; én gang som en del av setet og én gang som en del av forestillingen. Når vi har en EOP skal disse to alltid være like! Det betyr at den enkleste måten å opprettholde dette på (og spare litt lagringskapasitet i samme slengen) er å droppe ett av dem. Den nye Billett-relasjonen ser da slik ut: Billett Kinosal på Setenr på Dag på Side 9 av 16

Legg merke til at i den opprinnelige Billett-relasjonen er kombinasjonen Sete kinosal og Setenr fremmednøkkel til Kinosal og Setenr i Sete-relasjonen. Slik er det også med kombinasjonen Forestilling kinosal og Dag som er fremmednøkkel til Forestilling-relasjonen. De samme fremmednøklene har vi også i den nye Billett-relasjonen, men da inngår det samme Kinosal -attributtet i begge fremmednøklene! OBS! Legg merke til at attributtene innad i en relasjon må ha unike navn! Side 10 av 16

6WHUNRJVYDNJUXSSHULQJ Nå begynner dere forhåpentligvis å få en viss føling med gruppering. Det er da på tide å se på de to hoveddtypene vi har, nemlig sterk og svak gruppering. Det vil bare bli forskjell på de to i modeller med underbegreper og modeller der ikke alle roller er påkrevd: Sterk gruppering tillater ikke NIL i noen relasjon, mens svak gruppering tillater NIL. Denne modellen tar for seg ansatte og deres adresse og telefonnr (dersom de har oppgitt dem). Gruppert svakt får vi kun én relasjon (velger å undertrykke Telefon og Adresse): Ansatt Ansattnr for Adresse bopel Telefon for Her kan både Adresse og Telefon være NIL, ettersom de ikke er påkrevd. Grupperer vi sterkt kan vi ikke ha NIL i noen relasjon. Dermed må vi skille ut de attributtene som potensielt er NIL i egne relasjoner: Ansatt Ansattnr for Ansatt med telefon Ansattnr for Telefon for Ansatt med adresse Ansattnr for Adresse bopel Denne måten å dele opp relasjonene på hindrer forekomster av NIL. Alle ansatte vil finnes i Ansatt-relasjonen. De ansatte som har oppgitt telefonnummer vil også finnes i Ansatt med Side 11 av 16

Side 12 av 16 telefon-relasjonen, og tilsvarende for dem som har oppgitt en adresse. Resultatet blir altså nesten som om vi hadde delt inn i underbegreper i modellen! Dette kan du lese mer om i neste seksjon...

8QGHUEHJUHSHU Betrakt denne modellen over ansatte, der ansatte enten er fast ansatte med månedslønn eller deltidsansatte med timelønn: Gruppert sterkt får vi disse relasjonene (Lønn og Ansattype undertrykkes): Ansatt Ansattnr for Fast ansatt Ansattnr for Ansattype for Mnd. Lønn for Her blir Ansattnr for en fremmednøkkel til samme attributt i Ansatt-relasjonen. Deltidansatt Ansattnr for Timelønn for Her blir også Ansattnr for en fremmednøkkel til dette attributtet i Ansatt-relasjonen. Underbegrepene gir her opphav til egne relasjoner. Samme modell gruppert svakt: Ansatt Ansattnr for Ansattype for Mnd. Lønn for Timelønn for Her glemmer vi at vi har underbegreper, og legger all informasjon fra superbegrepet og underbegrepene inn i én og samme relasjon. Legg merke til at vi da mister de påkrevde rollene som var på underbegrepene en ansatt er enten fast- eller deltidsansatt og har derfor enten Side 13 av 16

måneds- eller timelønn. Ett av de to lønnsattributtene vil derfor alltid være NIL i denne relasjonen. Hvorvidt dere velger å gruppere sterkt eller svakt vil i hvert enkelttilfelle måtte vurderes ut fra bruksområdet til databasen. OBS! Legg merke til at ved sterk gruppering av underbegreper arver underbegrepene representasjonen til superbegrepet (dvs. de får samme primærnøkkel), og får dermed også fremmednøkler til superbegreprelasjonen. Dette er de eneste attributtene de får fra superbegrepet. Side 14 av 16

)UHPPHGQ NOHU Ingen gruppering er komplett uten fremmednøkler, ettersom det er disse som uttrykker forholdet mellom de ulike relasjonene. Fremmednøkler har en retning, og tegnes derfor som piler (eller delmengder); eventuelt kan de skrives som tekst. Dersom du velger å skrive dem, angis de på følgende format: ATTRIBUTTNAVN-LISTE er fremmednøkkel til RELASJON-NAVN(ATTRIBUTTNAVN-LISTE) Betrakt følgende modell over politiets hemmelige (fiktive) tiggerregister: Det antas her at begrepene Dag og Tid er representert på et annet (ikke her vist) ark, og at representasjonene er henholdsvis dato og klokkeslett. Dessuten er underbegrepet Ikke- egentlig Ikke-tigger, men det ble det ikke plass til i sirkelen. Posisjon er tenkt å være nummer i rekken som gaten er på ruten. Gruppert etter kunstens regler (beskrevet tidligere i guiden) får vi disse relasjonene: Person F.nr for Navn på Type aktivitet Side 15 av 16

Tigger F.nr for Inntekt antatt F.nr for er fremmednøkkel til Person(F.nr for) Ikke-tigger F.nr for Hobby for F.nr for er fremmednøkkel til Person(F.nr for) Politi Fnr.nr for Kodenavn under cover F.nr for er fremmednøkkel til Ikke-tigger(F.nr for) Rute Tiggeroperatør Posisjon for Gate på Tiggeroperatør er fremmednøkkel til Tigger(F.nr for) Spaning Politispaner Dag for Tid for Tiggeroperatør med Posisjon for med Politispaner er fremmednøkkel til Politi(F.nr for) (Tiggeroperatør med, Posisjon for med) er fremmednøkkel til Rute(Tiggeroperatør, Posisjon for) Her er det verdt å merke seg disse punktene: Underbegreper får alltid fremmednøkkel fra sin primærnøkkel til primærnøkkelen i relasjonen til det begrepet det er direkte underbegrep av. I vårt tilfelle betyr dette at Ikketigger og Tigger har fremmednøkkel til Person, mens Politi har fremmednøkkel til Ikketigger. Når vi har to begreper (hvorav ingen av dem er undertrykt; dvs. de har hver sin relasjon) vil vi alltid ha en fremmednøkkel mellom disse. Fremmednøkkelen går fra det inngrupperte attributtet i relasjonen vi grupperer inn i, til primærnøkkelen i relasjonen vi grupperer inn i fra. Vi har tre slike tilfeller i vårt eksempel: Fremmednøkkel fra Tiggeroperatør i Rute til Tigger(F.nr for), fremmednøkkel fra Politispaner i Spaning til Politi(F.nr for) og fremmednøkkel fra (Tiggeroperatør med, Posisjon på med) i Spaning til Rute(Tiggeroperatør, Posisjon på). OBS! I de tilfellene hvor en fremmednøkkel refererer til en sammensatt primærnøkkel, må alle attributtene fra primærnøkkelen være med i tabellen fremmednøkkelen går fra. Det går ikke an å slå sammen disse til ett attributt. Side 16 av 16