Datamodellering : praksis og teori med oppgavesamling 8291915210 [PDF]

Zitiervorschau

(C) Ectyar Bortrøwv Kop teruvup forbudt. (Vet er dogp tMatt ct

6tv ntotietten/ over.) NB Rana DepotbibHot ’

© Edgar Bostrøm.

Trykket hos Centraltrykkeriet, Sarpsborg 1. opplag august 1999 2. opplag desember 1999.1 2. opplag er noen det gjort noen få feilrettinger.

ISBN 82-91915-21-0

Det må ikke kopieres fra denne bok i strid med åndsverkloven og fotografiloven eller i strid med avtaler om kopiering inngått med KOPINOR, Interesseorganiasjonen for rettighets­ havere til åndsverk. Kopiering i strid med lov eller avtale kan medføre erstatningsansvar og inndragning, og kan straffes med bøter eller fengsel.

2

Forord. Datamodellering ble på 1970-tallet introdusert som en teknikk for å gi en beskrivelse av en database (framtidig eller eksisterende). De mest innflytelsesrike innen dette var antagelig amerikanerne Peter P.S. Chen og C. Bachman. Siden har det utviklet seg mange forskjellige varianter av denne teknikken, samtidig som anvendelsesområdet har blitt utvidet til bl.a. generell systemutvikling og organisasjonsutvikling.

Jeg ønsker med denne boka å gi en innføring i datamodellering som er relativt lettlest, samtidig som den viser hvorledes teknikken kan brukes bl.a. til å utforme databaser. Vekten er lagt på praktisk innføring og på presen­ tasjon av typiske strukturer, slik at man forhåpentligvis kjenner igjen tilsvarende strukturer når man arbeider med nye problemstillinger i praksis. Samtidig er det tatt med noe teori og bakgrunn som sikter mot en overordnet forståelse av temaet.

Boka bruker Enity-Relationship-modeller (forkortet ER-, EAR-modeller eller ERM) med vanlig kråkefotnotasjon. Vi har imidlertid tatt med en kort innføring i Chens opprinnelige ER-notasjon og NIAM. Min erfaring er at det er lurt å lære seg vanlig kråkefotnotasjon grundig først, men at det også er verdifullt å lære andre varianter, inklusive fordeler og ulempler med disse. Det kreves lite forkunnskaper, men det er ikke skadelig å ha arbeidet med databaser noen timer. Hvis man har jobbet mye med databaser, bør man imidlertid "omprogrammeres", slik at man ikke hele tiden tenker på databaser under utviklingen av en modell. Litt arbeide med programmering, gjerne også med datastrukturer, gjør antagelig at man forstår noen av de videregående delene raskere, men framstillingen er bevisst laget slik at man ikke trenger kunnskaper i dette for å lese boka. Boka kan brukes på ulike måter: • Som et hjelpemiddel for personer som jobber med systemutvikling eller er med i utviklingsprosjekter. • Som del av et kurs i systemutvikling, et eget datamodelleringskurs eller som del av et databasekurs. • Til en kortere innføring i et slikt kurs. Man kan da evt. kutte ut eller ta lettere på noen av kapitlene, f.eks. deler av kap. 6 (Mer kompliserte strukturer) og 11 (Andre datamodeileringsdialekter). Hvis normalisering tas opp kan man velge "miniinnføringen" i kap. 7 eller en mer grundig innføring i Tillegg A. På grunn av muligheten for å bruke deler av boka i en kortere variant er det også litt overlapp mellom kap. 3 og kap. 6. Boka bygger på 15 års erfaring med undervisning (bl.a. ved høgskolene i Buskerud og Østfold), konsulentarbeide og metode/verktøyutvikiing innen temaet. Noe av stoffet har tidligere eksistert som kompendium.

Et kurs av denne typen bør etter min mening inneholde mange oppgaver, både i datamodellering som sådan og gjerne også oppgaver/småprosjekter hvor man lager en datamodell, overfører den til et databasesystem, og lager ferdig i alle fall en prototype av et system i et databasesystem. Vi viser til oppgavesamlingen i tillegg B. I kurs hvor boka blir brukt som pensumlitteratur kan foreleser fa tilsendt løsningsforslag til oppgavene.

Jeg vil av og til referere til Modelator, et datamaskinbasert verktøy for datamodellering. Verktøyet er mye i bruk både i undervisning og i private og offentlige virksomheter, og boka vil antagelig bli brukt mye sammen med dette verktøyet. Formålet med disse referansene er å knytte sammen teorien med hvorledes man kan gjøre ting i praksis på en datamaskin, og hva et slikt verktøy kan / ikke kan hjelpe deg til. Verktøyet kan også brukes for automatisk generering av en database ut fra en datamodell og automatisk "reversering", dvs. motsatt vei. En slik bruk bidrar dermed til å gi forståelse av sammenhengen mellom datamodell og database. Vi anbefaler naturlig nok at Modelator brukes sammen med boka. Det bør imidlertid understrekes at boka ikke er en innføring i Modelator som sådan. For dette vises til et eget innføringshefte.

Jeg har (under tvil) inkludert noen begreper fra databasesystemer, bl.a. i forbindelse med datadefinisjon. Dermed vil det være lettere å se sammenhengen mellom modellering og databaser. Ulempen er at man mentalt lager en litt for tett kobling mellom datamodellering og hva man gjør i et databasesystem. Datamodellering handler nemlig først og fremst om modellering av deler av virkeligheten, ikke først og fremst om databaser. Takk til kollegaer, tidligere studenter og andre som har bidratt med forslag og kritikk av deler av stoffet. Til slutt en takk til min gode venn og tidligere nabo Hussain Afeef, som inviterte meg og familien til 14 dagers uforglemmelig ferie på Maldivene sommeren 1999, og som dermed var årsak til at boka ikke ble ferdig i tide.

3

INNHOLDSFORTEGNELSE. 1. 1.1. 1.2.

2. 2.1. 2.2.

3. 3.1. 3.2.

3.3. 3.4. 3.5.

HVA ER DATAMODELLERING?............................................................... Innledende eksempel - et ansattsystem........................................................ ANNET GJENNOMGÅENDE EKSEMPEL.................................................................................

LITT OM KLASSIFISERING I ET DATAMODELLERINGSPERSPEKTIV .............................. Klassifikasjon i forbindelse med datamodeller Klassifikasjon, språk og flertydighet.......................................................

MER OM ATTRIBUTTER, ENTITETSTYPER OG RELASJONSTYPER...... Hvor strenge regler/skranker skal man ha?........................... Attributter.......................................................................... Nødvendig- , identifikator-, kandidatnøkkel-, og atomær-egenskapene Domenebegrepet........................................................................

3.8.

Tegning av datamodeller -

5.

REGLER FOR FREMMEDNØKLER...............................

5.1. 5.2. 5.3. 5.4. 5.5.

BØR FREMMEDNØKLER VÆRE MED I EN DATAMODELL^ FREMMEDNØKLER I 1 :M-TILFELLET........................................ FREMMEDNØKLER I MlM-TILFELLET............................................... FREMMEDNØKLER I 1:1-TILFELLET.................................................. FREMMEDNØKLER SOM OGSÅ ER EN DEL AV IDENTIFIKATOR.

5.6. 5.7.

FREMMEDNØKLER I MODELATOR............................

52

.53 53 54 56 57 59 61

63

MER KOMPLISERTE STRUKTURER..............................

6.1.

MIST IKKE TRÅDEN !......................................................................

6.2. 6.3. 6.4. 6.5.

Nullverdier i attributter og mulige konsekvenser for datamodellen..................... en hovedaktør, flere medaktører...................................................... Kontroll av dataverdier - noen varianter Hierarki og nettverk............................................ "Alle-til-alle"-relasjonstyper...............................................................

6.6. 6.7.

RELASJONSTYPER AV HØYERE ORDEN

6.8.

Ekvivalente stier............................................

KORT OM NORMALISERING AV EN DATAMODELL Normalisering i praksis................................................. Hovedregelen for normalisering............................................... Automatisk normalisering?..........................................

8.1. 8.2. 8.3.

UTVIKLING AV DATAMODELLER - EN SAMMENFATNING.......................... Det språklige aspektet ved datamodellering Arbeidsgangen med datamodellering En ENKEL UTVIKLINGSMODELL............................................................

9.

DATAMODELLER OG KONSTRUKSJON AV SKJERMBILDER.....................................

10.

DATAMODELLER - PÅ KURS OG I VIRKELIGHETEN.................................................

11.

ANDRE DATAMODELLERINGSDIALEKTER..........................................................

4

47 47 51

Referanseintegritet.....................................................

6.

11 • 1 • 1 1.2. 11.3.

.31 .34 37 38 43

ENTITETISERING - EN MYE BRUKT TEKNIKK ENTITETISERING AV M1M-RELASJONSTYPER................................................................ ENTITETISERING AV 1:1-RELASJONSTYPER......................................................... ENTITETISERING I MODELATOR........................

8.

.23

noen råd............................... ................

4.1. 4.2. 4.3.

7.

.21 .22

Begrepet relasjon i datamodeller og i relasjonsdatabaser RELASJONSTYPER...................................................................

7.1. 7.2. 7.3.

.21

ENTITETSTYPER..................................................................................

3.6. 3.7.

4.

j

VARIASJONER INNENFOR VÅR DIALEKT CHEN'S OPPRINNELIGE NOTASJON NIAM/ORM......................................................... ...1...”

.

j

102 102 104 107

109 111

TILLEGG A:

MER OM NORMALISERING

128

TILLEGG B:

OPPGAVESAMLING

136

TILLEGG C:

KORT LITTERATURLISTE

150

STIKKORDSREGISTER

151

5

Kap. 1

HVA ER DATAMODELLERING?

1. Hva er datamodellering? Datamodellering er, litt forenklet sagt, en teknikk for å beskrive strukuren for og sammenhengen mellom ulike ting som vi ønsker å systematisere informasjon om. Selve dokumentasjonen av det arbeidet vi gjør kalles gjeme en datamodell. Det er vanlig å skille mellom informasjon og data, slik at "data + tolkning = informasjon".

I et slikt perspektiv burde begrepene vært informasjonsmodellering og informasjonsmodeller i stedet for datamodellering og -modeller. De siste begrepene er imidlertid såpas innarbeidet at det neppe er mulig å "snu strømmen". En annen måte å understreke dette på er å snakke om semantisk datamodellering, hvor ordet semantisk betyr at man fokuserer på betydningsinnholdet av modellen, ikke hvorledes data representeres.

Teknikken er særlig i bruk for • å klargjøre innholdet i begreper og skille disse ut fra andre beslektede begreper. • å finne fram til en fornuftig struktur i en database, eventuelt beskrive strukturen for en allerede eksisterende database.

Vi snakker i denne sammenheng om å ha et "virksomhetsperspektiv" henholdsvis et "databaseperspektiv" på datamodelleringen (jfr. Andersen 1988). Man starter gjerne med å forsøke å gi en presis beskrivelse av en utvalgt del av en virksomhet eller et system - i det vi spør "hva er de viktige begreper for virksomheten, hvordan henger disse sammen og hvilke opplysninger er interessante for hvert begrep". I mange tilfelle vil en slik beskrivelse være viktig i seg selv, helt uavhengig av eventuell bruk av informasjonsteknologi. I de fleste tilfeller brukes imidlertid denne beskrivelsen som et grunnlag for å lage en databasestruktur. Vi går altså fra et "virksomhetsperspektiv" til et "databaseperspektiv".

I dette innledende kapittelet vil vi arbeide med et svært forenklet eksempel - først med vekt på virksomhetsperspektivet, og deretter se hvorledes dette gir opphav til en databasestruktur som kan brukes til å lage en database i et databasesystem. Hvorfor ikke jobbe direkte i databasesystemet?

Brukervennlige databasesystemer og utviklingsverktøy som Microsoft Access, Oracle, Sybase, Sybase SQL Anywhere, Progress, Delphi, Visual Basic og ulike verktøy for utvikling i et Web-miljø gjør at man kan lage brukervennlige applikasjoner på relativt kort tid. Det er mulig å definere databasen direkte i databasesystemet, uten å ha analysert problemstillingen på orhånd. Hvis det dreier seg om 3 - 4 tabeller/filer, er dette selvsagt greit nok. Svært ofte viser det seg imidlertid at problemet var mer komplisert enn man trodde på forhånd, og at man blir sittende å konsentrere seg om felt, feltlengder - og "kanskje jeg burde ha splittet ut disse feltene i en egen tabell likevel", når man egentlig burde ha spurt seg hva som er de overordnede begreper og sammenhenger i et man skal arbeide med. Når man sitter og arbeider med ett og ett felt, er det også fort gjort å gjøre opplagte feil, som f.eks. at man har forskjellig lengde på felt som skal kobles sammen.

6

Kap. 1

HVA ER DATAMODELLERING?

Alt dette fører til at man lett får databaser som er dårlig utformet (dårlig databasedesign), slik at applikasjonen både blir dårlig i seg selv, og at den blir vanskelig å endre på et senere tidspunkt. Vi vil derfor meget sterkt anbefale at man arbeider systematisk med å utforme en datamodell og får diskutert forskjellige alternativer for denne før man setter i gang i databasesystemet.

1.1.

Innledende eksempel - et ansattsystem.

Som et innledende eksempel tar vi for oss strukturering av en dei informasjon som er relevant for en tenkt personalavdeling, for deretter å vise hvordan vi på grunnlag av dette får fram en database for et enkelt personalsystem.

La oss anta at vi på forhånd har snakket med personalavdelingen. Etter våre diskusjoner med dem har vi kommet frem til følgende problembeskrivelse:

"De ansatte i firmaet er fordelt på forskjellige avdelinger. Det er viktig å få med hvem som jobber hvor, og hvilken stillingstype de har. Vi har fere faste kurs i jirmaet, og vi vil vite hvilke kurs den ansatte har gått på." Entitetstyper.

Vi kan allerede nå se at de viktigste delene er "Ansatt", "Avdeling", "Stillingstype" og "Kurs". Disse kalles entitetstyper. Hva slags opplysninger trenger vi om disse entitetstypene? Om de ansatte er vi antagelig interessert i ansattnr, navn, adresse, etc. Disse opplysningene kaller vi attributter. Tilsvarende trenger en liste over attributter for avdeling, stillingstype og kurs.

I datamodellering beskrives en entitetstype vanligvis som et rektangel, med navnet på entitetstypen inni rektangelet. Den første delen av datamodellen blir dermed1: Stillingstype

Avdeling

Ansatt

Kurs

Relasjonstyper - maksima

Det neste vi tar opp er hvorledes entitetstypene er relatert til hverandre. Fra problembeskrivelsen har vi at hver Ansatt kan delta i flere Kurs så lenge han eller hun er ansatt. Sammenhengen mellom Ansatt og Avdeling må også bli klarlagt. Hva hvis en ansatt har byttet avdeling siden vedkommende ble ansatt? Er vi da interessert i å vite alle avdelinger han eller hun har vært ansatt i, eller er det bare avdelingen som den ansatte jobber i nå som er viktig? Er det slik at en ansatt kan jobbe i to forskjellige avdelinger på samme tid? Samme problemstilling kan oppstå mellom Ansatt og Stillingstype.

Noen av svarene på slike spørsmål er opplagte, som f.eks. at en avdeling kan ha mange ansatte. I andre tilfelle er det mer snakk om bedriftens eller organisasjonens "policy", f.eks. når det gjelder om samme

1 Plasseringen er for få en pen tegning senere. Skyggeeffekten er naturligvis bare gimmic.

7

Kap. 1

HVA ER DATAMODELLERING?

ansatt kan jobbe i flere avdelinger samtidig. La oss si at vi har diskutert problemene med personalavdelingen og at vi har kommet frem til følgende: Ansatt-Kurs * Hver Ansatt kan ha vært med på flere Kurs, og vi vil vite hvilke kurs hver har vært med på. * Hvert Kurs kan bli tatt av flere Ansatte (det er opplagt for oss, men ikke for en datamaskin!).

Ansatt -Avdeling * En Avdeling kan ha mange Ansatte. Hver Ansatt kan bare jobbe i en Avdeling. Vi er ikke interessert i jobber som en ansatt kan ha hatt i andre avdelinger.

Ansatt-Stillingstype * En Ansatt kan kun ha en Stillingstype. Det kan være mange ansatte som har samme Stillingstype (eks. sekretærer, direktører, systemkonsulenter osv.) og vi er ikke interessert i tidligere stillinger. Sammenhengen mellom entitetstypene over er at enten er bare maksimum en tillatt eller at mange er tillatt. Dette vises hhv. som en vinkelrett strek og en såkalt kråkefot: Avdeling

Ansatt

max. 1

eller

mange

Datamodellen ser dermed slik ut:

Vi kaller disse for relasjonstyper. Beskrivelsene av ”hva relasjonstypen gjelder” (jobber i, omfatter osv.), hjelper oss til å forstå hva modellen handler om, og kalles verbaler hvis sammenhengen beskrives verbalt eller roller hvis sammenhengen beskrives via et substantiv (f.eks. at relasjonstypen mellom Avdeling og Ansatt beskrives med rollenavnet ansattforhold). Vi vil generelt snakke om dette som verb/roller.Vi anbefaler at disse blir satt inn i modellen, da en skikkelig gjennomtenkning av dette ofte vil avklare misforståelser.

Relasjonstyper - minima

Angivelsen av "en" og "mange" går som nevnt på det maksimale antall i en sammenheng, f.eks. at en Ansatt kan jobbe i maksimalt en Avdeling om gangen eller at en Avdeling kan ha mange Ansatte. Mange som arbeider med datamodellering synes det klarer seg med en slik maksimumsbeskrivelse.

8

Kap. 1

HVA ER DATAMODELLERING?

Hvis man skal ha en mer presis modell, bør man imidlertid for hver relasjonstype angi minimum i hver retning. Spørsmålet blir da om en Ansatt kan jobbe i minimalt 0 Avdeling (dvs. ikke behøver å jobbe i noen avdeling) eller om Ansatt må jobbe i minimum 1 Avdeling. Enkelt sagt: kan betyr minimum 0, må betyr minimum 1. Den vanligste måten å angi dette på, er å sette på en minimums-beskrivelse på relasjonslinjen, ved siden av maksimumsbeskrivelsen. Figuren viser et forslag til minimumsbeskrivelse.

Attributter

Datamodellen i figuren oppsummerer både problembeskrivelsen og presiseringer som er gjort underveis. Det som mangler er hvilke opplysninger eller attributter som er relevante for de forskjellige entitetstypene. Vår erfaring er at hvis den grafiske delen av datamodellen er godt gjennomarbeidet, vil det være relativt lett å plassere attributter i rett entitetstype.

Vi tenker oss at vi etter diskusjon med personalavdelingen er blitt enige om at følgende attributter skal være med: Stillingstype stillingskode stillingsbetegnelse

Avdeling avdelingsnr avdelingsnavn

Ansatt ansattnr ansattnavn adresse telefonnr

Kurs kursnr kursnavn

For hver entitetstype har vi valgt ut et attributt som vi vet at er entydig (unikt) - og understreket dette. Eksempelvis er ansattnr entydig innenfor et firma, mens ansattnavn ikke nødvendigvis er det (flere personer kan ha samme navn). Det valgte entydige attributtet brukes altså til å identifisere en enkelt forekomst av en entitetstype, og kalles derfor identifikator. 1 noen tilfelle velger vi å bruke en kombinasjon av flere attributter for å danne en slik identifikator. Fremmednøkler

Dersom datamodellen med attributter over skal brukes som grunnlag for å lage en database, må databasen inneholde en form for "kobling" mellom de ulike entitetstypene. Med attributtene over kan vi f.eks. finne ut informasjon om den ansatte, men mangler opplysninger om hvilken avdeling vedkommende jobber i. For å få med dette legger man inn ekstra attributter som viser hvilke verdier som hører sammen med hvilke. Disse ekstra attributtene kalles fremmede attributter / fremmednøkler.

Hvordan skal vi fa til disse koblingene i praksis? For å fa til koblingen mellom Ansatt og Avdeling, vil det være en god idé å legge inn et nytt attributt, avdelingsnr, i entitetstypen Ansatt. Det fører til at vi for hver ansatt kan finne ut hvilken avdeling som den ansatte jobber i. Dette er mulig fordi vi allerede vet at en ansatt ikke kan jobbe i mer enn en Avdeling og fordi vi antok at avdelingsnr er unikt. Merk at det

9

Kap. 1

HVA ER DATAMODELLERING?

ikke er nødvendig å legge avdelingsnavn i Ansatt, fordi vi kan finne avdnavnet via avdelingsnr. På samme måte kan vi legge stillingskode inn i Ansatt for å finne sammenhengen mellom Ansatt 02 Stillingstype.

Hvis vi skal tenke mot en database, må vi også gjøre noe med sammenhengen mellom Ansatt og Kurs. Dette må imidlertid løses på en annen måte enn de to andre sammenhengene. Grunnen til det er at dette er et "mange-til-mange" forhold. Vi kan ikke legge attributtet kursnr i Ansatt, fordi vi ikke vet hvor mange kurskoder det vil bli for en Ansatt. Vi kan heller ikke legge attributtet ansattnr i Kurs, da vi ikke vet hvor mange ansattnr det vil bli for et Kurs. Derfor må vi lage en ny entitetstype mellom Ansatt og Kurs. Denne kan vi kalle Kursdeltagelse. Vi har forutsatt at flere ansatte kan ha tatt samme kurs, og vi kan nå finne det enkelte kurs for den enkelte ansatt ved å kombinere kurskode og ansattnr - nemlig det vi har kalt kursdeltagelse. Den komplette databaseorienterte datamodellen vises under: Stillingstype

Avdeling

Stillingskode

Avdelingsnr

Stillingsbetegnelse

Avdelingsnavn

gjelder

omfatter

jobber- i Ansatt

tilhører

har

Kursdeltagelse

gjelder

gjelder

Kurs

har

Ansattnr

'Kursnr

Kursnr

Ansattnavn

'Ansattnr

Kursnavn

Adresse

Telefonnr ‘Stillingskode

‘Avdelingsnr

De * -merkede attributtene angir fremmednøkier. Vi kommer detaljert tilbake til fremmednøkler i kap. 5. Vi har nå sett på et meget enkelt eksempel som demonstrerer hvordan man går fram for å lage en datamodell. Vi har også sett hvorledes slike modeller gir opphav til diskusjoner ("er det virkelig slik at en ansatt kan jobbe i bare en avdeling om gangen?"). For større problemer vil det naturligvis kreves mye tid for a utforme en slik modell.

Kort sammendrag av terminologien som er brukt.

Et rektangel,’ f.eks. fAvdeling A"^ ■■—

er en generalisering av en "ting" som vi ønsker å beskrive. Rektangelet symboliserer det generelle ved avdelinger, slik at vi ønsker å fokusere på egenskaper som er felles for alle forekomster av "klassen" eller "typen" Avdeling. Vi kaller derfor slik bokser en entitetstype. Mer om begrunnelse for denne begrepsdannelsen følger i kap. 2.

Det samme gjelder når vi har beskrevet forholdet mellom to entitetstyper, dvs. det vi kaller en relasjonstype. Når det gjelder maksimalbeskrivelser, finnes det tre kategorier relasjonstyper: en-til-mange ~l----- —------- —---------------- — mange-til-mange en-til-en

/------------------------ -------------j----------------- —— ------------- L

Det mest vanlige er "en-til-mange" og "mange-til-mange"- relasjonstyper. Å beskrive slike minima og maksima kalles ofte å beskrive kardinaliteten (fra latin, angivelse av antall) til en relasjonstype.

10

Kap. 1

HVA ER DATAMODELLERING?

Vi har også vært inne på at man bør beskrive hva de enkelte relasjonstypene gjelder, enten ved en verbal beskrivelse, f.eks. Ansatt jobber i Avdeling, der jobber i er verbalbeskrivelsen, eller ved å bruke et rollenavn, ansattforhold. Kort snakker vi derfor om en verb/rolle-beskrivelse. Det er spesielt viktig å bruke verb/roller hvis det finnes flere relasjonstyper mellom to entitetstyper.

Opplysninger vi ønsker å ha med for hver entitetstype kalles som nevnt attributter. Attributter kan være vanlige attributter (f.eks. navn, adresse og telefon for entitetstypen Ansatt). Det attributtet eller den attributtkombinasjonen som brukes for å identifisere entitetstypen, kalles en identifikator. Andre attributter kommer fra relaterte entitetstyper, disse benyttes til å knytte sammen to entitetstyper (f.eks. avdelingsnr til entitetstypen Ansatt). Disse kalles som nevnt ofte fremmednøkler eller koblingsfelt. Figuren under oppsummerer de begrepene som er nevnt. omfatter

”jobber i” er en verbalbeskrivelse eller en rolle for en relasjonstype (kort: verb/rolle) avdelingsnr, avdelingsnavn, ansattnr, ansattnavn osv. er attributter ansattnr og avdelingsnr er identifikatorer (markert med understreking) avdelingsnr er også fremmednøkkel i Ansatt (markert med stjerne)

1.2.

Annet gjennomgående eksempel.

I tillegg til ansattsystemet over, kommer vi av og til også til å bruke et eksempel fra et typisk ordresystem, igjen temmelig forenklet, og bare et lite utsnitt (det trengs mange flere entitetstyper og attributter i et virkelig system). Identifikatorer og fremmednøkler er heller ikke tatt med.

Fra det innledende eksempelet går vi nå i neste kapittel over på å se litt mer på klassifiseringsprosessen som ligger bak det å lage en datamodell. Dette gir også en bedre forståelse for begrepsdannelsen som blir brukt.

11

Kap. 2

2.

LITT OM KLASSIFISERING I ET DATAMODELLERINGSPERSPEKTIV.

Litt om klassifisering i et datamodelleringsperspektiv.

Dette kapittelet skal gi litt bakgrunn om prosessen med og problemer med klassifikasjon av "ting" og begreper, slik vi gjør det i forbindelse med datamodellering. Det vil dermed gi en viss teoretisk ramme rundt den prosessen som ble beskrevet i kap. 1, og vil være nyttig før vi går videre.

2.1.

Klassifikasjon i forbindelse med datamodeller.

I utviklingen av datamodellen som ble vist i forrige kapittel gjorde vi egentlig en klassifisering som vi skal se noe nærmere på. Figuren under viser noen aspekter av dette:

Klassifikasjon er avhengig av sammenhengen. For i det hele tatt å kunne gjøre en klassifikasjon, må vi vite i hvilken sammenheng klassifikasjonen skal gjøres. Gjelder dette et idrettssteve? Arrangement av et kurs? Et styremøte? Et ansattystem? Vi trenger altså å diskutere en systemaygrensning, m.a.o. å finne ut hva som systemet skal inneholde og hva som er "utenfor" systemet. I engelskspråkling litteratur kalles dette for the Universe of Discourse (UoD), altså den delen av universet som vi avgrenser oss til å arbeide med. Det å finne en fornuftig systemavgrensning, samt å se sammenhengen mellom denne avgrensningen og hva som er utenfor systemet, er noe av det vanskeligste i praktisk systemutvikling.

12

Kap. 2

LITT OM KLASSIFISERING I ET DATAMODELLERINGSPERSPEKTIV.

vår avgrensning ("universe of Discourse")

Klassifikasjon av "ting":

På venstre side av figuren ser vi 4 "ting"2. Har disse noe felles? På et fargebilde ville vi sett at de hadde noe blått på seg. Alle har dessuten noe rundt øverst (hode) og noe som går ut til en eller begge sider rett under hodet. Men: de fleste ville vel si direkte at det som er felles mellom disse tingene, er at de kategoriseres som mennesker. Dette er imidlertid en klassifikasjon som vi velger å gjøre. Vi tenker vel knapt nok på det til daglig, men selve begrepet menneske er noe som er skapt av oss - det finnes ikke i naturen eller utenfor oss på noe vis. Vi mennesker har altså laget oss et sett med begreper, bl.a. for å kunne kommunisere og behandle ting som er temmelig like på en effektiv måte. Det er altså viktig å skille mellom forekomster / instanser og typer / klasser. Det er dessuten ikke gitt at person er den mest fornuftige klassifikasjonen - det kommer an på hvilken sammenheng vi står i. To av tingene driver med sport - de andre er kanskje også aktive i sport. Er det mest dekkende begrep for disse sportsutøver? Alternativt kunne man tenke seg situasjonen som er beskrevet i forrige kapittel - hvor det var naturlig å klassifisere tingene som ansatte. I mange andre tilfelle er selve forekomstene også abstrakte - som de ulike avdelinger eller kurs i eksempelet over. 1 motsetning til personer er det dermed vanskelig å tenke seg et bilde av dette - hvordan tegner man kurs nr. 34? Dermed kan den venstre delen av figuren over være uaktuell - tingene er abstrakte og vi gjør en klassifiseringsprosess som kun er bygget på data om den abstrakte tingen.

Klassifikasjon av "data om ting":

Det kan være mye å si om den første av "tingene" over. For eksempel har han bart, lite hår, slips og heter Per. Alt dette er data om denne tingen - data betyr rett og slett "det som er gitt". Spørsmålet er hvilke av disse data som er interessante for flere forekomster, og som det dermed er naturlig å abstrahere til et felles mønster. Igjen kommer det an på hvilken sammenheng vi er i. Hårfarge, bart etc. kan være interessant i et system for frisører, mens det neppe er interessant i et generelt ansattsystem. Vi spør oss altså om hvilke data som er interessante for alle eller en del av "tingene", og klassifiserer disse. Vi ender dermed opp med: Beskrivelse

Symbol

Type/klasse av tingen (hele boksen)........ Navn på denne klassifikasjonen...............

Interessante data for denne typen/klassen

Formelt begrep

entitetstype An satt

Ansattnr '^Ansattnavn

entitetstypenavn

attributter

Skal vi snakke om den første av "tingene" over, må vi ha noe som henviser til / identifiserer denne "tingen". Ofte bruker vi en identifikasjon som er entydig i en gitt kontekst (sammenheng), f.eks. bare fornavn - som Ole.

2 D.v.s. egentlig bilder av "ting". Vi skulle helst hatt selve tingen, altså den bestemte personen sittende inne i boka. Men: det var ikke plass - og denne personen kunne i tilfelle bare finnes i en av bøkene!

13

Kap. 2

LITT OM KLASSIFISERING I ET DATAMODELLERINGSPERSPEKTIV.

Når det finnes flere med samme fornavn - slik som Per i figuren over, vil navnet Per likevel kunne brukes for identifikasjon innenfor en gitt avdeling dersom det bare er en som heter Per i denne avdelingen. Ellers vil f.eks. "Per med barten" kunne være en grei identifikasjon så lenge den andre Per ikke har bart. Vi ser likevel at det er behov for en entydig identifikasjon av hver forekomst av en entitetstype, slik som ansattnr i kap. 1.1. Det bør til slutt nevnes at det noen ganger er vanskelig å trekke opp skillet mellom "tingen" og "informasjon om tingen". Dette gjelder spesielt de tilfellene hvor "tingen bare består av informasjon". Et eksempel: I et saksbehandlersystem kan vi registerere flere stikkord pr. sak og motsatt, slik at modellen blir:

Stikkord

????

Sak

Saksnr Saksdato

Hvis "tingen" er stikkordet, hva lagrer vi da om stikkordet? Jo, vi gir hvert stikkord et navn - slik at vi kan referere til det. Altså får vi Stikkord

Stikkordsnavn

Stikkordet er altså selve "tingen", mens stikkordsnavnet er det som beskriver tingen. Jeg er fullstendig klar over at dette skillet er ikke lett å se klart som nybegynner innenfor datamodellering!

Klassifikasjon av relasjoner. I tillegg til at vi klassifiserer fra flere entiteter til en felles entitetstype, foregår det en tilsvarende klassifiseringsprosess fra enkeltrelasjoner til en felles relasjonstype. Vi tar for oss avdelinger og ansatte

Hver av strekene er en relasjon mellom to "ting". Siden disse er mellom de samme ting av samme type, er det naturlig a gjøre en tilsvarende klassifikasjon som vi gjorde for entitetstyper. Med andre ord: de 4 relasjonene over er av samme type - og en klassifikasjon av disse kalles dermed en relasjonklasse eller relasjonstype. Med forutsetning om at hver ansatt må jobbe i en og bare en avdeling, ser vi at denne relasjonstypen blir min. 0 max. mange på venstre side, min. 1, max. 1 på høyre side.

14

Kap. 2

LITT OM KLASSIFISERING I ET DATAMODELLERINGSPERSPEKTIV.

Det kan godt finnes flere relasjoner mellom de samme entitetene, og til og med relasjoner mellom to entiteter av samme type. Det siste kalles gjerne egenrelajoner, og vil bli behandlet i kap. 6.5.

På type-nivå her vi dermed Ansatt jobber i Avdeling, Ansatt er leder for Avdeling og Ansatt er sjef til Ansatt. Vi kommer til å snakke om en-til-mange, mange-til-mange og en-til-en så mange ganger at vi velger å bruke en kortform på disse: en-til-mange -> l:m mange-til-mange -> m:m en-til-en 1:1 Dette er altså det vi tidligere har kalt ulike former for kardinalitet, i dette tilfelle maksimumskardinalitet.

2.2.

Klassifikasjon, språk, flertydighet og redundans.

Om ting og navn på ting. Figuren med personer og avdelinger over viser at ulike ting kan ha samme navn, og dette er en av grunnene til at det er viktig med at minst ett attributt eller attributtkombinasjon er entydig, slik at ulike forekomster kan skilles fra hverandre. Det er imidlertid viktig å være bevisst på at samme ting også kan ha forskjellige navn.

Noen trivielle eksempler:

Tegningene på venstre side brukes som bilde på selve tingene, mens navnene, eller betegnelsene står til høyre.

15

Kap. 2

LITT OM KLASSIFISERING I ET DATAMODELLERINGSPERSPEKTIV.

Forholdet mellom "ting" og "navn på ting"/begreper er altså, sagt med en "kvasi"-datamodell:

Det praktiske problemet med dette er at når data registreres, kan "samme ting" registreres på ulike måter, noe som ofte gjør det vanskelig å finne igjen dataene og å lage korrekt statistikk etc. Eksempler på slike problemer: • skal man registrere forkortelsen eller fullt navn? • skal lange navn registreres fullt ut, eller bare en kortere form (Røde Kors vs. Norges Røde Kors) • forkortelser som illustrert over, og i økende grad om man skal registrere den norske eller engelske måten å skrive firmanavnet på (Kværner vs. Kvaerner, NRK vs. Norsk Rikskringkasting vs. Norwegian Broadcasting Cooperation). • navneendringer (Universitetet i Trondheim vs. Norges Teknisk Naturvitenskapelige Universitet) • varemerker vs. firmanavn (Diplom-Is vs. Norsk Iskrem BA) • skal A/S komme før eller etter firmanavnet? • og forresten, skal et aksjeselskap skrives a.s., A/S, a.s, eller noe annet? En mulig måte å løse dette på i et praktisk system, er å ha en liste over alternative navn, slik at man kan slå opp på det alternative navnet dersom det ikke finnes som hovedbegrep. For eksempel, for et kundesystem:

Modell

Noen eksempler på data viser dette mer konkret

Kundenr 34 35

Kunde

Kundenr

Kundenavn Norsk Rikskringkasting Kværner A/S

Kundenavn

Kundenr 34 34 34 35

Alternativt navn NRK Norwegian Broadcasting Cooperation Norsk Riks Kringkasting Kvaerner Inc.

Et annet eksempel på flertydighet av begreper, litt gammelt, riktignok, men illustrerende:

Nye pass fra 1. januar 1993 enn der passet blir utstedt, må det leve-

Justisdepartementet har utarbeidet et nytt pass som tas I bruk fra 1. januar 1993. De gamle passene vil være gyldige til de utløper. I de neste 10 årene vil det derfor være to pass I omløp.

res bilde I tre eksemplarer. Bildet må t dato, ___ og _passinnehaveren ___ være av ny skal ikke ha hodeplagg på bildet. som u(lerøer pass på

De nye passene vil ha en laminert persondataside. Det blir derfor ikke mulig å foreta senere navneendringer i passet, Det nye passet har ikke rubrikker for innehavets stilling, særskilte kjennetegn eller høyde, hår- og øyenfarge.

dagen kan fortsette med denne praksisen. For utstedelse og fornying av pass må man betale rettsgebyr (1992: kr 450,-). For pass til barn under 16 år betales halvparten av rettsgebyret Nærme,e

Passfoto må som før leveres i to eksemplarer. Bor passøkeren i et annet distrikt

Justisdepartementet v/lnformasjonskontoret, tlf. (02) 34 51 04.

Justisdepartementet Innrykket av Statens informasjonstjeneste 6701 #2

16

Er det ett pass, to pass eller mange pass?

Kap. 2

LITT OM KLASSIFISERING I ET DATAMODELLERINGSPERSPEKTIV.

Egennavn og fellesnavn. Vanlig språk (f.eks. norsk) er bygd opp rundt generaliseringer og klassifikasjoner - eller rettere sagt: språket er vårt viktigste redskap til klassifikasjon3. Når vi snakker om å identifisere forekomster og å navngi typer/klasser, er dette det samme som det vi helt tilbake til barneskolen kalte for egennavn og fellesnavn. (Husker dere det, folkens?) Når vi f.eks. sier "Ole jobber i Jernvare", er dette underforstått.

Egennavn:

Ole som er en

Fellesnavn:

Ansatt (egtl. Ansattnavn)

jobber i Jernvare som er en

Avdeling (egtl. Avdelingsnavn)

For at dette skal være presist nok, må vi forutsette at Ole er entydig innenfor ansatte, og Jernvare er entydig innenfor avdelinger. Vi kunne selvsagt ha slått det hele sammen til en setning, slik at typologiseringen var eksplisitt i selve setningen: "Ansatt med personnavn Ole jobber-i Avdeling med avdelingsnavn Jernvare", men vanligvis snakker vi selvsagt ikke så presist! Også her kan skillet være litt uklart, fordi det i noen tilfelle blir brukt samme navn både på egennavn og fellesnavn, eller at egennavnet har gått over til å bli fellesnavn. Eksempelvis kommer fellesnavnet geysir egentlig fra en bestemt geysir på Island (altså geysiren Geysir). Et mindre hyggelig eksempel: Egennavnet Quisling er på engelsk blitt til fellesnavn for en landsforeder: "That man is a quisling".

For de som har arbeidet litt med programmering, tilsvarer skillet mellom egennavn og fellesnavn det samme som man ser mellom variable og datatyper i en variabeldeklarasjon.

Geysir eller en geysir?

Hierarki og nettverk av begreper.

Hva er dette en tegning av?

Hadde vi spurt en del personer om det, ville vi antagelig ha fått en rekke svar.

En mulig måte å klassifisere mulige svar på kan være:

3 Andre måter å klassifisere på er bl.a. via tegninger, ikoner, håndbevegelser m.m.

17

Kap. 2

LITT OM KLASSIFISERING I ET DATAMODELLERINGSPERSPEKTIV.

Med mulig forbehold om det siste er alle svarene er riktige, de er bare i ulik detaljeringsgrad eller abstraksjonsgrad. Denne upresisheten i språket er noe vi har vent oss til, og det framgår som regel av sammenhengen hvilken betydning som skal legges til grunn i et konkret tilfelle. Problemet kommer først og fremst når man skal kategorisere, på hvilket nivå skal kategoriseringen skje^?

Når en arbeider med datamodeller, er det svært viktig å være klar over dette forholdet (vi kommer tilbake til dette i kap. 3.5). Vi skal her bare nevne noen eksempler: • skal begrepet Bok brukes om et konkret bokeksemplar, om en bokutgivelse, om alle utgivelser av "samme" bok. Hva vil det si at to bøker er samme bok? (NB! Merk flertydigheten: to bøker er samme bok...) • skal begrepet Kurs gjelde et kurs som f.eks. DA 305 - Databaser, eller en bestemt avholdelse av kurset, f.eks. DA 305 høsten 1999 ved Høgskolen i Østfold. • skal begrepet Person være bare fysiske personer, eller også juridiske personer (firmaer, institusjoner etc.) • personer som jobber med salg i en butikk: skal man snakke om Person, Ansatt, Selger eller noe annet? • ordet Bil kan tilsvarende ha en rekke betydninger. • Trykk på clutchen (kløtsjen?)". Betyr det å trykke på clutchpedalen eller på selve clutchen? • ordet Telefon. Hvis noen sier at "Du far snart en telefon", betyr det da at det kommer en telefonsamtale til deg, at du far et telefonapparat i gave, at du får et telefonnummer, et telefonabonnement (som for ISDN kan omfatte flere telefonnumre) .... • Hentet fra et annet område: Når noen sier at "jeg får sola i øynene", er vel også det også en feil beskrivelse. Det er forhåpendligvis solstråler vedkommende mener (!!)

Heldigvis er det ikke nødvendig å være så presis til daglig. Vi forstår som regel ting presist nok ut fra den sammenhengen det står i.

Som barn lekte Marianne, datteren vår, "Bilbingo" som man kan få på bensinstasjoner. Det er et ark med mange bilder av skilt, og når man kjører på veien skal man krysse av etter hvert som man ser et skilt av denne typen. Dette ga henne samme type nivåproblem. Hvis skiltet er som over, skal hun da krysse av hvis hun ser et vilkårlig forbudsskilt?, et annet fartsgrenseskilt?, bare hvis det er et max. 50-skilt?

18

Kap. 2

LITT OM KLASSIFISERING I ET DATAMODELLERINGSPERSPEKTIV.

Redundans og inkonsistens

Som vi allerede har vært inne på, er naturlige språk (norsk, engelsk etc.) temmelig upresise, slik at vi må ofte må gjøre en presisering av begreper. En annen vesentlig egenskap ved naturlige språk er at de inneholder mye redundans, dvs. "overflødighet". Det samme gjelder mye av den systematikken vi har skapt rundt manuell informasjon.

Eksempel - redundant språk: Hvis jeg skal ut å fiske, og sier: "Det hender jo av og til at jeg far noe fisk, av og til ikke", så kan denne setningen egentlig reduseres til "Kanskje får jeg fisk". Alt annet er egentlig unødvendig.

Eksempel - redundant informasjon: Da postnummer ble innført i Norge, var det for å effektivisere postbehandlingen. Et postkontor fikk tildelt et eller flere postnummer, slik at man fra postnummeret kunne se hvilket fysisk postkontor vedkommende sognet til. Men: dette førte til at informasjon om poststedet strengt tatt ble overflødig. Ikke nok med det, mye av adressen ellers til personer er redundant. Tenk deg f.eks. at du har valgt å bruke en postboks som din personlige postadresse. Ofte oppgir du allikevel full gateadresse og lignende, som i a) under.

Ole Olsen Brannveien 911 Postboks 123 N-5801 Sogndal Norge a) Full postadresse

123 N-5801

b) Ikke-redundant postadresse

Den siste er i prinsippet tilstrekkelig, men er kanskje litt vel kort... Grunnen til at denne redundansen kan være fornuftig er selvsagt at den gjør det enklere å finne fram ut fra litt ufullstendige opplysninger, og å oppdage feil som er gjort.

I tillegg er selve postnr/poststed-kombinasjonen uklar. Opprinnelig var poststedet det stedet som var ansvarlig for din post, og identifiserte bl.a. hvor du skulle hente pakker som kom til deg. Etter hvert har dette blitt endret på, slik at det nå ikke lenger er noe entydig samsvar mellom det fysiske postkontoret du henter posten på og det som står som poststed i adressen din. 3535 3536 0387 0543 1657

Krøderen Poststed = fysisk postkontor Noresund Oslo 4 —-------------------- -r- Poststed Oslo har mange fysiske postkontor Oslo 4 Poststed Torp har inget fysisk postkontor for tiden, det er (dessverre) nedlagt Torp

I vanlig språk er det svært mye redundans, men vi forstår som regel ting ut fra sin sammenheng likevel. Når man systematiserer informasjon, f.eks. med henblikk på lagring i en database, forsøker man for en stor del å unngå redundans, av flere grunner • det fører til at det lagres unødvendig mye data • behandlingen blir ofte mer komplisert og mindre presis • redundans fører svært lett til inkonsistenser

Med inkonsistens mener vi at ting "ikke stemmer overens med seg selv". Et typisk eksempel kan hentes nettopp fra postnr og poststed:

19

Kap. 2 PERSON Personid 4 3 2 1

LITT OM KLASSIFISERING I ET DATAMODELLERINGSPERSPEKTIV.

Personnavn Jensen, Jan Olesen, Olle Hansen, Hans Jensen, Jens

Postnr 3535 3535 3535 3535

Poststed Krøderen Krøderen Krødern Noresund

Problemet er naturligvis at opplysning om poststed for postnr 3535 m.fl. gjentas en rekke ganger. Noen ganger er det korrekt, andre ganger er det litt eller helt feil. Vi har altså inkonsistenser i data. Det riktige ville selvsagt være å fortelle én gang at Postnr 3535 er Krøderen, og deretter bare referere til postnummeret i Person. Altså:

POST

Postnr Poststed 3535 Krøderen 3536 Noresund

PERSON

Personid 4 3 2 1

Post

Personnavn Jensen,Jan Olesen, Olle Hansen, Hans Jensen,Jens

Postnr 3535 3535 3535 3535

+—

Postnr Poststed

■*

Person

Personid Personnavn ‘Postnr

Hvis vi har behov for poststedet for en gitt person kan vi gå fra Person og finne dette i Post. Siden det faktum at Postnr 3535 heter Krøderen bare finnes ett sted, er vi kvitt redundansen, og også kvitt muligheten for inkonsistenser. Det kan selvsagt være at det blir feil (f.eks. at vi har skrevet at 3535 heter Ørpen, men da blir det i tilfelle konsekvent feil, og ikke inkonsistent).

Vi kommer tilbake til slike spørsmål en rekke ganger senere, ikke minst i kapittelet om normalisering.

20

Kap. 3

3.

MER OM ATTRIBUTTER, ENTITETSTYPER OG RELASJONSTYPER.

Mer om attributter, entitetstyper og relasjonstyper.

Vi skal i dette kapittelet beskrive begrepene entitetstyper, relasjonstyper og attributter nærmere. Vi skal også bl.a. ta opp identifikatorbegrepet, som er sentralt både i datamodeller og i databaser. Vi starter imidlertid med å si litt om skranker/regler som er aktuelle når det gjelder datamodellering.

3.1.

Hvor strenge regler/skranker skal man ha?

En klassifikasjon innebærer oftest at man setter opp skranker for hva som er tillatt og hva som ikke er tillatt. Dette er vi selvsagt vant til i samfunnet, f.eks. innen lovgiving, diskusjon av ytringsfrihet osv. Det samme gjelder egentlig også for de fleste aspektene av informatikk: setter man for "strenge" behandlingsrutiner vil disse bli "for trange" til at man kan behandle ting som er noe forskjellig, setter man for "slappe" regler så kan man gjøre nesten som man vil, slik at man ikke får den standardisering eller klassifisering som man ønsker.

ingen regler

for strenge regler

slipper gjennom ting som ikke skulle vært tillatt

hindrer ting som burde vært tillatt

passe strenge regler", slipper gjennom de som passer med strukturen, og bare disse.

Det samme gjelder også for datamodeller. Skranker for hva som er tillatt er nødvendig å ha, f.eks. vil skranker på dataverdier gjøre at vi kan få den strukturen som er nødvendig for at dataene skal kunne egne seg for effektiv klassifisering og behandling.

Det meste av kapitlene som følger har nettopp til hensikt å gå i detalj på hva som er fornuftige skranker i de ulike tilfeller. Vi har allerede sett på flere typer skranker, og tar bare noen få eksempler her. Tre eksempler:

Identifikatorskranken - det at et attributt eller en -kombinasjon velges for å identifisere de ulike entitetene, dvs. forekomstene av en entitetstype, er fundamental i et informasjonssystem. Uten denne ville vi f.eks. ikke kunne garantere at alle ansattnr i et system var forskjellige - og dermed heller ikke kunne være sikre på at vi så på eller arbeidet med data f.eks. til den personen vi ønsket. Minimum- og maksimumsskranken - som sier noe om hvor mange entiteter av en type som kan kobles sammen med entiteter av en annen type er tilsvarende fundamental. fe

L0-

1

100........

1000 .....

10.0000 ....

w

eneste lovlige verdi er 1

100 ........

1000

alle tall > 0 er tillatt

21

Kap. 3

MER OM ATTRIBUTTER, ENTITETSTYPER OG RELASJONSTYPER.

Dersom man hadde hatt en m:m-relasjonstype, ville man riskert å lagre informasjon som var uforenlig med de reglene som man ønsker at skal gjelde. På den annen side: mange vil sikkert ønske å ha Avdeling har min.l, max. mange Ansatt. Selv om det kanskje er riktig at det ikke finnes avdelinger uten ansatte, er det neppe viktig å sjekke dette. For Kunde-systemet kan vi si tilsvarende: det at en Ordre kan bestå av 0 ordrelinjer virker lite sannsynlig, det er vel mest naturlig at den har en eller flere, men på den annen side gjør det vel ikke noe om en ordre kan mangle ordrelinjer - f.eks. fordi man ved en bestilling sier at: Kan jeg komme tilbake med nøyaktig hva vi skal bestille senere? Fylke

Et siste eksempel på dette: Vi vet at et fylke omfatter en rekke kommuner, men det er neppe noe stort poeng at informasjonssystemet skal gi en feilmelding dersom et fylke ---------- -r--------ikke har mange kommuner. (For øvrig er både Svalbard og Jan Mayen definert som fylker i en ZZ omfatter del sammenhenger - men disse har som kjent ingen kommuner...)

T

Det er etter min mening liten grunn til å påtvinge minimum 1 her.

Kommune

Datatyper sier noe om tillatte verdier f.eks. for et attributt. Et heltall kan kun inneholde sifre, evt. med et fortegn foran (og i en datamaskin gjerne begrenset av en minimal og maksimal størrelse på tallet), en streng/tekst inneholder vilkårlige tegn osv. I utgangspunktet tenker man på f.eks. et telefonnummer som et tall, men det har i det siste blitt mer og mer vanlig å skrive +47 og deretter det vanlige telefonnummeret. Tilsvarende skrives en del utenlandske telefonnummer med paranteser og/eller streker. Det er dermed tvilsomt om et telefonnummer alltid er et heltall. I praksis vil det gjerne lagres som en streng.

De to siste eksemplene illustrerer at man lett kan sette strengere skranker enn de som er viktig å håndtere. Vi vil senere se på en rekke andre slike skranker.

3.2.

Attributter

Attributter er, som vi vet fra tidligere, "egenskaper" ved en entitetstype, og som kan gis en "verdi" f eks i form av et tall, en streng med tegn, eller "nei"/"ja"-verdi. Hvilke verdier som er mulige ("domenet") for de forskjellige attributter vil variere fra et attributt til et annet. Vi skal komme tilbake til dette i underkapittelet om domenebeskrivelser (kap. 3.4). Kategorisering av attributter. Vi kan grovt sett skille mellom tre kategorier av attributter:

>

"Vanlige" attributter. Dette er attributter som kun sier noe om eller identifiserer den entitetstypen som attributtet er knyttet til, som f.eks. det 11-sifrede fødselsnummeret5 eller et personnavn, hårfarge, høyde etc. for en person.

>

"Fremmede" attributter. Disse hentes egentlig fra en annen entitetstype, og er med for å "binde sammen" datamodellen. For ansattsystemet vil vi eksempelvis kunne ha med et avdelingsnr i ANSATT-entitetstypen, for dermed å kunne referere til hvilken avdeling den ansatte jobber i. Dette attributtet "hører hjemme" som vanlig attributt i AVDELING, og når det opptrer i ANSATT-entitetstypen, er det derfor i en fremmed entitetstype. Det er viktig å væie klar over at fremmede attributter gir noe av den samme informasjonen som relasjonstypene. I relasjonsdatabasesystemer fungerer slike fremmede attributter som "limet" mellom de forskjellige tabellene i databasen. Et vanlig diskusjonstema i datamodelleringskretser er derfor om fremmede attributter skal være med i en datamodell eller om de helst bør utelates. I kap. 5 tar vi opp spørsmålet om sammenhenger mellom relasjonstyper og fremmede attributter i detalj, og vi vil også komme tilbake til

5 Som kjent er det hele det 11-sifrede nummeret som heter fødselsnummer, mens personnr er en "teller" for

personer som er født på samme dag (siffer 7 - 9 i fødselsnummeret).

22

MER OM ATTRIBUTTER, ENTITETSTYPER OG RELASJONSTYPER.

Kap. 3

spørsmålet om slike attributter bør tas med i datamodeller eller ikke. 1 de tilfelle vi tar med fremmede attributter, vil disse bli markert med en stjerne (*) - slik at disse tydelig skilles ut fra vanlige attributter. En annen vanlig måte å markere disse på, er med en stiplet linje. >

"Avledbare" attributter. At vi har et avledbart attributt, vii si at man på en eller annen måte kan utlede attributtverdien ut fra verdier som allerede finnes beskrevet i datamodellen. Vi kan snakke om to hovedtyper: • Beregn inger. Eksempler her kan være: • Pris = Enhetspris * Antall. Hvis enhetspris er fast og man har et gitt antall, kan prisen avledes. Den behøver derfor ikke være med f.eks. i en database. • Personnavn = Etternavn + " " + Fornavn, hvor + betyr sammenslåingen av to strenger, og "" betegner et blankt tegn mellom. • Totalt antall kjøpt = summen av antall (for en gitt ordre). Dette kan finnes ved ren opptelling. • Anta at vi i AVDELING-entitetstypen hadde et attributt Antallansatte (dvs. for denne avdelingen). Et slikt attributt kan avledes ved at man teller opp antallet i ANSATT-entitetstypen som er knyttet til denne avdelingen. Et slikt attributt er derfor overflødig, og kan gi opphav til inkonsistenser i databasen. • Rene oppslag, f.eks.: • Navn på avdelingen som en person er ansatt i. Hvis man vet avdelingsnummeret på avdelingen som personen jobber i, vil man automatisk kunne finne avdelingsnavnet også. Det er derfor ingen grunn til å ha med avdelingsnavn i ANSATT-entitetstypen. I slike tilfelle kan man finne en forskrift for hvorledes attributtene kan avledes fra andre attributter som finnes i datamodellen. Det er ikke vanlig å ta disse med i modellen. Hvis de tas med, bør de merkes på en spesiell måte, gjerne sammen med "forskrift for hvorledes de skal finnes".

Vi skal under se på ulike egenskaper som kan tillegges enkeitattributter eller kombinasjoner av attributter. Dette blir en form for skranker for hvilke verdier som er lovlig for attributtet (evt. -kombinasjonen).

3.3.

Nødvendig-, identifikator-, kandidatnøkkel-, og atomær-egenskapene.

3.3.1.

Nødvendig-egenskapen.

For hvert attributt i en entitetstype bør vi spørre oss: "Hvilke attributter MÅ ha en verdi", dvs. er nødvendige hvis attributtet skal være meningsfullt. Vi tar for oss ANSATT:

Eksempeldata:

ANSATT

Ansattnr Ansattnavn Ansattnr Ansattnavn Privat-telefonnr Antai l fødsler

8234 4356 7124

Rita Hansen Ole Hansen Synnøve Hansen

Privat­ telefonnr 89345344

Antall_ fødsler 2

89999877

Vi spør oss altså hvilke attributter som må være med i en entitet (dvs. forekomst) dersom denne skal ha mening. Ansattnr er opplagt nødvendig, bl.a. fordi det brukes til å identifisere den ansatte. Ansattnavn er vel også et "MUST" å ha med - det har neppe noen mening å ha opplysning om et ansattnr dersom man ikke vet navnet på vedkommende. Privat telefonnr er derimot ikke nødvendig - hvis vi da ikke sier at alle som skal være ansatt nødvendigvis må ha en privat-telefon. Tilsvarende er Antall_fødsler uutfyllt for noen. Vi snakker altså om at attributtverdien mangler, eller at den "er" NULL6. Grunnen til at verdien mangler kan være flere, f.eks.

6 En liten filosofisk fotnote: "er" står i anførselstegn. Siden poenget nettopp er at verdien ikke er (ikke finnes eller ukjent), er det egentlig selvmotsigende å snakke om NULL som en "verdi". NULL finnes altså for å fortelle at verdien ikke finnes! Derfor er sammenligning med null meningsløs, eller sagt med andre ord: NULL * NULL. Litt folkelig sagt: selv om to mennesker mangler adresse, betyr ikke det at de bor på samme sted.

23

Kap. 3

MER OM ATTRIBUTTER, ENTITETSTYPER OG RELASJONSTYPER.

• • • m.m. For en

den mangler tilfeldigvis (som privatJelefonnr over) den kan ikke være aktuell (som antallfødsler for menn) den er ikke kjent enda, eller vil aldri bli kjent (vi vet ikke innkjøpsår for gamle maskiner ....) mer omfattende beskrivelse av nullverdier, se Date 1995, og videre referanser derfra.

Det kan være litt forvirrende når man sier at f.eks. Privat_telefonnr ikke er "Nødvendig". Hvorfor har vi det da med i det hele tatt? At et attributt er Nødvendig betyr at det aktuelle attributtet må ha en verdi for alle forekomster av den bestemte entitetstypen (dvs. alle entiteter), sagt med andre ord: det er alltid nødvendig å fylle det ut. At det er ikke-nødvendig betyr at det noen ganger er med, noen ganger ikke. Nødvendig tilsvarer altså MÅ/minimum 1, mens ikke-nødvendig tilsvarer KAN/minimum 0. I databasesystemer er det vanlig å angi om en kolonne/felt er "Nødvendig", f.eks. ved å spesifisere "NOT NULL" (dvs. at "ikke-verdi" ikke er tillatt), Mandatory, Required, Obligatorisk eller lignende. Nødvendig-egenskapen gjelder i utgangspunktet ett attributt om gangen. Det finnes likevel tilfelle hvor det er en sammenheng mellom nødvendig-egenskapen i flere attributter. 1 et system for reparasjon av maskiner kan man f.eks. ha attributtene siste_reparasjonsdato og siste_reparasjonsårsak. På verdi-nivå må begge ha verdi eller begge være NULL. Alternativt kan vi tenke oss at siste_reparasjonsdato for maskiner som aldri har vært reparert bhr satt til innkjøpsdato, og siste_reparasjonsårsak er "Innkjøp". Nullverdier kan få følger for hvordan datamodellen ser ut, se kap.6.2. I en del tilfelle velger vi å bruke en "umulig" verdi for å angi at verdien ikke gjelder, f.eks. at -1 på årstall betyr ukjent årstall. Dette har sine fordeler, men kan også være uheldig. Vi går ikke inn på detaljer om dette her.

3.3.2.

Identifikator-egenskapen.

Som vi skal komme til i neste underkapittel, er det viktig at hver entitet (altså forekomst) skal kunne identifiseres - bl.a. fordi de representer forskjellige ting i virkeligheten. Alle er kjent med bruken av det 11 sifrede fødselsnummeret i denne forbindelse. Skal man skille forekomstene fra hverandre, må de nødvendigvis ha forskjellige verdier på ett eller flere attributter. I de fleste tilfelle består identifikatoren av ett eneste attributt, men i en del tilfelle vil det være en kombinasjon av to eller flere attributter (dvs. en attributtgruppe) som til sammen danner identifikator. Vi snakker da om en sammensatt identifikator. 1 databasesystemer brukes gjerne ordet primæmøkkel om identifikator, og det deklareres med stikkordet PRIMARY KEY.

Vi kan definere begrepet identifikator slik: En identifikator for en entitetstype er et attributt eller en gruppe av attributter som velges ut til å identifisere de ulike forekomster av en entitetstype, og som oppfyller følgende egenskaper: (1) ENTYDIGHET: alle verdiene for dette attributtet (evt. attributtgruppen) er forskjel­

(2) IRREDUSIBILITET7:

(3) ENTITETSINTEGRITET.

lige, dvs. verdiene er entydige. hvis en gruppe av attributter til sammen danner identifikatoren, er alle enkeltattributtene nødvendige for å danne denne, dvs. identifikatoren kan ikke reduseres mer. alle deler av identifikatoren må ha Nødvendig-egenskap.

Kommentarer til disse kravene: Entydighet:

Dette kravet bhr ofte kalt for minimalitetskravet. Ordet minimalitet gir imidlertid assosiasjon om at det skal være færrest mulig attributter i en identifikator. Poenget er imidlertid et annet, nemlig at vi ikke kan ta bort elementer av den forslåtte identifikatoren uten at den mister entydighetsegenskapen. Man kan altså ikke redusere identifikatoren - den er irredusibel.

24

Kap. 3

MER OM ATTRIBUTTER, ENTITETSTYPER OG RELASJONSTYPER.

Kravet sier at vi må velge et attributt(-kombinasjon) som vi garantert ikke finner to like verdier av. Derfor er f.eks. ansattnavn utilstrekkelig i de fleste tilfeller - det bør være tillatt å ansette to personer som begge heter Arne Olsen. (Forfatteren har opplevd at 3 studenter het Kjetil Hansen på samme skole, på samme tid!).

Dersom man har en gruppe av attributter som tilsammen danner identifikator, er det viktig at det er kombinasjonen som må være entydig, ikke hvert attributt for seg. Vi har altså en sammensatt identifikator. Et eksempel: Ved en undervisningsinstitusjon er det entydige studentnummeret sammensatt av to attributter: • startår for studenten (f.eks. 98) Student • 3-sifret løpenummer pr. student innen dette året (f.eks. 083). Oppgir man kun løpenummeret 083, er det selvsagt ikke nok til å identifisere en entydig student. Kombinasjonen er imidlertid entydig. Start årstall Kombinasjonen er entydig, ikke hvert attributt for seg

...........

Løpenr dette år

I mange tilfelle vil vi kunne velge mellom flere mulige identifikatorer. Vi snakker da om at vi har flere kandidatnøkler for denne entitetstypen, se kap. 3.3.3.

Irredusibilitet: Dette kravet er kun aktuelt dersom man har en sammensatt identifikator. Hvis man har et forslag til en identifikator, bør man stille seg spørsmålet om "kan vi kutte ut et eller flere av disse attributtene og likevel kunne bruke de gjenværende som identifikator?". Et trivielt eksempel (flere eksempler kommer senere): Noen foreslår å bruke kombinasjonen av fødselsnr (det 11 -sifrede) og navn som identifikator. Denne kombinasjonen er naturligvis entydig, men den er ikke irredusibel, fordi vi kan kutte ut navn og allikevel være sikker på at det resterende (fødselsnr) er brukbart som identifikator. Den foreslåtte identifikator vil være svært uheldig, fordi den vil tillate at mange mennesker har samme fødselsnummer hvis de ikke har samme navn. Da ville selvsagt fødselsnummert bli ubrukelig!

Entitetsintegritet:

Et eksempel: Dersom ansattnr blir brukt som identifikator for ANSATT, vil vi neppe tillate at vi har en ansatt som ikke har noe ansattnr. Siden en identifikator pr. definisjon skal identifisere, eller om vi vil "blinke ut" en entydig forekomst blant mange entiteter (dvs. forekomster), er det naturlig at identifikatoren MÅ ha en verdi, dvs. har Nødvendig-egenskapen8. Modelator vil automatisk sørge for entitetsintegritet, i og med at et attributt som markeres som identifikator også automatisk vil markert Nødvendig-egenskapen.

Tommelfingerregler for valg av identifikator: Dersom man kan velge mellom forskjellige mulige identifikatorer, bør en bl.a. ta hensyn til: • om man virkelig kan være sikker på at attributt(-gruppen) er entydig. • om det er fare for at attributt(-gruppe)verdien vil kunne endres. Dersom et ansattnummer f.eks. besto av avdelingsnummer i kombinasjon med et løpenummer, ville personen måtte skifte ansattnummer dersom personen byttet avdeling. Dette er neppe heldig, spesielt ikke hvis man skal beholde historiske data i firmaet. Tilsvarende bør tidspunkt (timer/minutter) normalt ikke inngå i identifikatoren. • at eventuelle tall som inngår i identifikatoren er heltall (bl.a. fordi andre former for tall ikke representeres nøyaktig i en datamaskin).

8Vi kunne vel teoretisk tillate en eneste verdi som har "ikke-verdi" på identifikatoren, men det har vist seg at det ikke er noen særlig god løsning - og det har vel neppe noen særlig praktisk betydning heller.

25

Kap. 3 • •

MER OM ATTRIBUTTER, ENTITETSTYPER OG RELASJONSTYPER.

dersom man skal realisere datamodellen som en database, vil det ofte av hastighetshensyn lønne seg å bruke en kort identifikator. under ellers like forhold foretrekkes en enkel identifikator framfor en sammensatt.

Identifikatorer - noen eksempler: Enkle identifikatorer er oftest trivielle, mens det andre ganger er mange å velge mellom, og også noen ganger hvor man ikke er sikker på at det man ønsker å ha som identifikator virkelig er entydig og Nødvendig For sammensatte identifikatorer har vi ofte flere valg, og vi må også tenke på irredusibilitetskravet. Noen eksempler:

Eksempel 1:

Vi vil identifisere hvert enkelt hus (eiendom) i Norge. Noen alternativer for identifikator: • Kombinasjonen av kommunenr, gårdsnr og bruksnr (en teller innenfor en gitt gård), samt seksjonsnr (innenfor bruksnr igjen) er en mulighet (som brukes f.eks. ved tinglysning etc.). Der hvor man ikke har seksjonsnr, kan man si at det er seksjonsnr = 1. Selv om dette er et godt valg, så vil kommunesammenslåin­ ger m.m. gjøre at selv ikke dette valget er helt stabilt. • 1 praksis er kombinasjonen gatenavn og gatenr entydig innenfor samme poststed, så vi kunne brukt kombinasjonen gatenavn, gatenr, postnr, poststed som identifikator (f.eks. Roseveien 33A, 7005 Trondheim). Men: her bør vi spørre oss om er entydighetskriteriet oppfyllt? Ja, det er neppe to veier som heter det samme med samme poststed. • er irredusiblitetsskravet oppfyllt? Nei, siden vi kan ta bort poststedet og likevel beholde entydigheten, er den foreslåtte identifikatoren ikke irredusibel. • er entitetsmtegriteten oppfyllt? Neppe, det finnes sannsynligvis en del eiendommer som ikke har noe gatenummer, kanskje heller ikke et gatenavn el.l. • Konklusjonen er at det finnes flere grunner til at den foreslåtte primærnøkkelen ikke er brukbar. Nærmere undersøkelse må til for å finne ut om kombinasjonen gatenavn, gatenr, postnr kan brukes eller ikke. Geografisk posisjon. Ved hjelp av (breddegrad,lengdegrad)-kombinasjonen kan man i praksis identifisere (f.eks. midten av) et hus via koordinater med svært høy nøyaktighet. Dersom disse koordinatene representeres som heltall ville dette kunne brukes, men er neppe særlig praktisk. Eksempel 2:

Vi vil identifisere utleie av prøveskilter på trafikkstasjonene (tidligere biltilsynet). La oss anta at prøveskiltet bare kan lånes en dag om gangen og at samme skilt ikke kan lånes ut flere ganger pr. dag. Forslag: * Isombinasjonen kjennetegn,fødselsnummer. Imidlertid er ikke den entydig, siden samme person kan komme tilbake og låne samme skilt en annen dag. Skiltutleie * ta også med dato, altså bruk kombinasjonen av alle tre attributtene. Det betyr imidlertid at et skilt kan lånes av flere samme dag, noe vi ikke ville tillate. * Prøv kombinasjonen fødselsnr, dato. Men: da kan samme person bare låne et Kjennetegn skilt pr. dag, men samme skilt kan lånes flere ganger pr. dag. Fødselsnr * Prøv kombinasjonen kjennetegn, dato. Dermed kan samme kjennetegn bare leies Dato ut en gang pr. dag, men hver person kan leie flere skilter pr. dag. Det var akkurat det vi ønsket. I de tilfelle hvor vi ikke har noe naturlig attributt som kan brukes som identifikator, lager vi et kunstig nummer (Leks. et kundenummer eller et annet løpenummer) for å sikre entydigheten. 1 databaser blir løpenummer også o e brukt dersom andre identifikator-muligheter vil virke tungvindt eller f.eks. bestå av svært mange attributter. Det mest vanlige er at ett (evt. kombinasjon av flere) ”vanlig"(e) attributt(er) er identifikator. Imidlertid bør man av og til trekke inn relaterte entitetstyper for å få en fornuftig identifikator. 1 praksis bruker vi de fremmede attributter i denne sammenhengen. Identifikatoren kan også være en kombinasjon av "vanlige" attributter og fremmede" attributter, eller kun av fremmede attributter. Vi kommer tilbake til dette i kap. 5.

Oppsummering - hvordan finne en bra identifikator.

26

Kap. 3

MER OM ATTRIBUTTER, ENTITETSTYPER OG RELASJONSTYPER.

Som nevnt over, er identifikatoren mange ganger helt opplagt. Dersom den ikke er det, og vi ser at den bør bestå av flere attributter, vil prosessen ofte være: Ikke entydig eller for "stram" stranke

"Riktig" skranke

Ikke minimal eller ikke Nødvendig for alle deler, for "slapp" skranke

tid

3.3.3. Kandidatnøkler. Hva hvis det er flere attributter eller attributtkombinasjoner som kan brukes som identifikator? Vi har allerede vært inne på det i et par eksempler over. I et personalsystem vil man ha både et entydig ansattnummer og et entydig 11-sifret fødselsnummer. Det blir da opp til datamodellereren å bestemme hvilken av "kandidatene for å være primæmøkkel" som bør velges som primærnøkkelen.

Altså:

En kandidatnøkkel er et attributt eller attributtkombinasjon som kan brukes som primæmøkkel.

Enkelte mener med dette at kandidatnøkkelen skal oppfylle alle 3 kravene til en primæmøkkel (entydighet, irredusibilitet og entitetsintegritet). Andre mener at en kandidatnøkkel godt kan ha nullverdier, slik at hvis den skal velges som primæmøkkel, så må man sørge for å fjerne denne muligheten. Dersom nullverdier skal tillates, kan det også være spørsmål om bare en skal tillates eller at det tillates mange nullverdier. Siden NULL NULL (jfr. tidligere fotnote), er det et definisjonsspørsmål om dette bryter entydighetsregelen eller ikke. En attributtkombinasjon som er entydig, men redusibel, kalles en supernøkkel. Med andre ord: Supernøkkel ——fjerner overflødige attributter Kandidatnøkkel

Unikhet - vanlig begrep i databasesystemer. Selv om kandidatnøkkelbegrepet er det tradisjonelle begrepet, er begrepet entdighet eller unikhet (uniqueness) mer og mer vanlig å bruke (bl.a. i databasesystemer). Det defineres gjerne med å skrive UNIQUE () hvor består av ett attributt eller en liste med attributter med komma mellom. Det er også mulig å definere unikhet i Modelator (fra versjon 4.0).

Unikhet kan brukes sammen med Nødvendig-egenskapen eller uten denne. Siden nullverdier ikke regnes som like, kan man i en viss forstand si at unikhetsegenskapen beholdes selv om man har mange NULL-verdier. Eksempel: Pasientsystemer ved sykehus bruker et såkalt PIN-nummer, Person-ldentifikasjoN- et løpenummer Pasient som identifikator. I tillegg har man med det unike 11-sifrede Fødselsesnummet, bl.a. for rapportering til trygdemyndighetene. Men: hva med utenlandske pasienter, som f.eks. er her på ski-ferie og som brekker benet og legges inn på sykehus? Det naturlige er derfor HN--------at vilkårlig mange fødselsnummer kan mangle (være NULL) men de fødselsnummer Pasientnavn som finns må være unike (altså alle er ulike). enten mangler dvs. NULL eller hvis utfyllt: unik.

.......... Fødseisnr

27

Kap. 3

MER OM ATTRIBUTTER, ENTITETSTYPER OG RELASJONSTYPER.

Den samme situasjonen oppstår f.eks. ved Ll-relasjonstyper, men detaljer rundt dette tas ikke opp her Poenget er altså at både Unik (men vilkårlig mange NULL er tillatt) og Nødvendig-egenskapen er nyttig for å beskrivi skranker som finnes i virkeligheten.

Valgbar som identifikator Altså:

Identifikator må velges blant attributtkombinasjonene som har er unik & irredusibel & nødvendig9.

Vi skal komme tilbake til begrepet kandidatnøkkel i kap. 7, Kort om normalisering av en datamodell

3.3.4. Atomærkravet. De fleste som arbeider med datamodellering, legger også et annet krav til attributter, nemlig det at de skal være "atomære", dvs. udelelige10*.Dette gjelder to forhold: 1) attributt skal ikke kunne deles opp i flere deler. 2) attributtet skal ikke repeteres.

Ikke kunne deles opp i forskjellige deler

Prinsippet er at ved å dele opp i "minst mulige deler", så kan vi eventuelt slå sammen disse delene igjen hvis det er ønskelig. Derimot er det ikke så lett å dele opp noe som allerede er slått sammen, noen ganger er det faktisk umulig å vite hvor grensen går mellom de ulike delene av et sammensatt attributt. Noen eksempler: Noen attributter er gjeme opplagt atomære, som f.eks. et kundenummer, avdelingsnummer, avdelingsnavn alder, etc. • Hva f.eks. med ansattnavn? Dersom man aldri har behov for å splitte opp navnet f.eks. i etternavn og fornavn, vil man kunne betrakte et personnavn som atomært. Dersom man av og til trengte å skille disse, burde man i stedet lage to eller tre attributter, etternavn, fornavn, evt. også mellomnavn1 J. Et konkret eksempel: et firma med 1000 ansatte skal slå sammen to databaser med data om de samme personene. En navneliste er ordnet med som ett attributt, en annen med som ett attributt. Dette blir enten en omfattende manuell jobb eller

Foi spesielt interesserte - evt. for 2. gangs gjennomlesning: Det er forfatterens prinsippielle mening at de fundamentale begrepene er (irredusibel) unikhet og nødvendighet valget av én primærnøkkel blant eventuelt flere unike gjøres for at alle fremmednøkler (det kan være flere inn mot den samme entitetstypen) skal referere til samme attributt(er) • fremmednøkler er å betrakte som en implementasjon av en relasjonstype i en relasjonsdatabase. Siden datamodellering i praksis blir brukt mest for å designe relasjonsdatabaser, er det likevel ikke unaturlig at spesifikasjon av identifikator/primærnøkkel og fremmednøkkel pragmatisk sett er det viktigste. Se Bostrøm 1993 for begrunnelse og detaljer. 10 Enhver med litt kjennskap til naturvitenskap vet at et atom er delelig, så ordet er kanskje ikke så godt valgt... Siden ordet er innarbeidet, beholder vi det likevel. Av lathetshensyn er dette ikke gjennomført i de fleste eksemplene som brukes. Hvorvidt det i praksis lønner seg a splitte har også med om det betraktes som en helhet, se teksten ellers. •

28

Kap. 3

MER OM ATTRIBUTTER, ENTITETSTYPER OG RELASJONSTYPER.

en jobb som må gjøres via en eller annen form for programmering. Dersom begge navnelistene hadde vært delt i etternavn, fornavn og mellomnavn som ulike attributter, ville sammenligningen vært triviell. Altså: Ansattl

Ansatt

~~~>

Ansnr Ansnavn

Ansnr

Ans_etternavn Ans_fornavn

Ikke repeteres. Et eksempel på et attributt som er repeterende, er hvis ANSATT hadde attributtet arbeidsoppgaver, og slik at man ønsket å kunne se på en og en av disse arbeidsoppgavene for hver ansatt. Vi har også splittet fornavn og etternavn: Ansattl

Ansatt

Ansnr

Ansnr Ansnavn

Ans_etternavn

312 311 291

Bø Mo Dal

Ole Dag Jo

Ans_fornavn

Arbeidsoppgaver

312 311 291

Bø, Ole Mo, Dag Dal, Jo

Sentr.bord Regnskap Journal Regnskap Vask og rengjøring Journalist

Arbeidsoppgave

*Ansnr

Oppgavenavn

a) med arbeidsoppgaver som repeterende attributt

312 312 312 311 311 291

Sentr. bord Regnskap Journal Regnskap Vask og rengjøring Journalist

b) med repetisjonen fjernet - er atomisk.

En slik oppsplitting gjør at vi er nede på "grunnivå". En slik splitting gjør at vi får flere entitetstyper, men er likevel fordelaktig i mange sammenhenger. Vi skal se på noen eksempler på ønsker som man kan ha m.h.t. disse dataene, og se hvorledes dette kan gjøres i de ulike tilfellene.

Ønske Hva må gjøres i a) Vi må vite hva som skiller oppgavene Vi vil vite hvor mange arbeidsoppgaver ansnr 312 har (blank, komma, eller annet tegn). Deretter må vi programmere en opptelling hvor vi skiller strengene fra hverandre og legger til en for hver blank12. Vi må programmere leting i Ansattnr 312 skal ikke lenger Arbeidsoppgaver etter teksten Regnskap, jobbe med regnskap slette denne og flytte resten av teksten tilsvarende framover. Programmere en leting etter en og en Lage en sortert utskrift av oppgave i Arbeidsoppgaver, flytte dem arbeidsoppgavene for hver

Hva må gjøres i b) Tell opp antall rader i Arbeidsoppgave hvor ansnr = 312.

Slette raden i Arbeidsoppgave hvor ansnr = 312 og oppgavenavn = Regnskap Gjøre en standardsortering av Arbeidsoppgave (eller en kopi av

12 og hvis det er blank som er skilletegn: er da Vask og rengjøring en, to eller tre oppgaver?

29

Kap. 3

MER OM ATTRIBUTTER, ENTITETSTYPER OG RELASJONSTYPER. ansatt

fram eller tilbake i denne teksten avhengig av sorteringsrekkefølgen 13 Lage en liste over alle Må igjen programmere en leting inni arbeidsoppgaver og hvem som Arbeidsoppgaver, antagelig lage en har disse midlertidig tabell med oppgaver, lete videre osv. Det blir noen linjer kode! Vi vil finne alle som jobber Programmer en leting i attributtet med Journal Arbeidsoppgaver, hvor delstrengen skal være Journal. Men: da kommer også Journalister med! Vi ønsker en liste over alle Lett å lage en ny entitetstype, men den arbeidsoppgaver som skal kan ikke kobles mot et attributt i ansatt. kunne finnes (uavhengig av Vanskelig å lage kontroll. om noen har dem), og med mulighet for å kontrollere at de arbeidsoppgavene som skrives inn på en ansatt er en lovlig arbeidsoppgave. Det skal være plass til svært Må sette av svært mye plass (hvor mye mange arbeidsoppgaver pr. trengs tro??) i arbeidsoppgave-strengen i ansatt hver ansatt.

denne) Gjøre en standardkobling og utvelgelse av data fra Arbeidsoppgave og Ansatt.

Gjør et standardsøk etter oppgavenavn = 'Journal' (eksakt strengen Journal). Ingen fare foi sammenblanding med Journalist Lag en ny entitetstype Arbeidsoppgavetype med attribi Oppgavenavn. Kobl denne samr med Arbeidsoppgave. Kontrolle på at nye arbeidsoppgaver er et lovlig oppgavenavn fås gratis. (Tegn opp selv!) Ligger implisitt i strukturen.

Oversikten viser tydelig at man i a) må programmere enhver endring, og noen endringer er vanskelig å få til, mens man i b) kan bruke standardoperasjoner som gjelder enhver entitetstype / tabell i en database. Alle de ’ operasjonene som gjøres i b) er lett å gjøre f.eks. med SQL (Structured Query Language), standardspråket for manipulasjon i et relasjonsdatabasesystem.

Vi kan også tenke oss en gruppe av attributter som repeteres, f.eks. hvis vi ønsket å legge inn antall timer som den ansatte er tilstede pr. dag. I dette tilfelle ville kombinasjonen av dato og timeantall repeteres mange ganger

a) Både sammensatt og repeterende

b) Splittet ut, er atomisk.

Vi haper dette er nok til å overbevise deg om at man bør splitte ut repeterende attributter. I praksis skjer dette ved a legge en slik repetisjon til en egen entitetstype, og deretter binde den til sitt "opphav" med en l:mrelasjonstype. Dette gir en mest mulig ryddig og forståelig modell, samtidig som skillet mellom entitetstype og attributt blir klarere enn om man tillot repeterende attributter i modellen.

13

30

*

*

og igjen: hva med Vask og rengjøring - skal det sorteres som en, to eller tre?

Kap. 3

MER OM ATTRIBUTTER, ENTITETSTYPER OG RELASJONSTYPER.

Atomærkravet på nytt - det kommer an på bruken av data Vi argumenterte over for at dataene skulle være atomære. Når vi nå tar det opp på nytt, er det for å se på unntak, og å være klar over at man også bør vurdere om dataene brukes atomært eller ikke. Igjen noen eksempler: • I argumentasjonen over med å dele et navneattributt i flere deler, unnlot vi å nevne at dersom man alltid vil komme til å bruke hele navnet som en helhet, kan det forsvares å beholde det som ett attributt. • Det 11-sifrede fødselsnummeret inneholder som kjent flere deler, hvorav en av delene igjen danner en

1 2 dato

•

•

•

•

•

3 4 mnd

5 6 år

6 8 9 personnr

10 11 kontrollsifre

fødselsdato Dette er opplagt ikke atomisk. Spørsmålet er imidlertid om dataene i praksis skal brukes som en helhet. Om de ikke skal det, kan det likevel være en godtagbar struktur dersom man f.eks. alltid bare skal plukke ut noen av dataene, f.eks. sifrene 5 og 6 - som årstallet. Et fødselsnummer skal heller ikke kunne endres, et argument som taler for man kan beholde det som en helhet. Dessuten: siffer 10 og 11 er beregnede attributter ut fra de 9 første, slik at de strengt tatt ikke trenger å være med i de hele tatt .... I Norge har vi faste fylkesnummer (01 = Østfold, 02 = Akershus osv.). Hver kommune i Norge har sitt kommunenummer, som består av 4 sifre, hvorav de to første er fylkesnummeret. Eksempelvis er 0101 = Halden, 0104 = Moss, 0105 = Sarpsborg, 0106 = Fredrikstad. Kommunenumrene er altså ikke atomiske, og det bør vurderes om man skal dele det i to deler, eller om man skal godta dette bruddet på atomiskheten. I en del firmaer består ansattnummeret av en kombinasjon av avdelingsnummeret for avdelingen du jobber, og et nummer innenfor denne avdelingen. Dette er etter vår mening en uheldig struktur, fordi det betyr at personen må ha et nytt ansattnummer dersom personen bytter avdeling. Skulle vi være helt ekstreme, kunne vi si at f.eks. et fornavn også er sammensatt, fordi det kan deles opp i bokstaver. Skulle vi da lage en egen entitetstype for fornavnbokstaver (med attributtene personid bokstavnr og bokstaven)? Dette kunne være nyttig dersom vi f.eks. skulle slette den 5. bokstaven i hvert navn .... Det sier seg selv at en såpas ekstrem form for atomisering ikke er praktisk. Vi kan også argumentere med at repetisjoner bør kunne være tillatt i en første fase av en datamodell, eller dersom modellen bare skal brukes til en grovoversikt av dataene. Etter hvert bør man imidlertid uansett splitte opp, spesielt når man begynner å arbeide med identifikatorer og fremmednøkler. Det kan også være at man skal lage datamodellen med henblikk på implementasjon i et databasesystem som tillater repeterende felt14, 15. Noen velger i dette tilfelle å bruke klammerparanteser i datamodellen for å vise dette, f.eks. {Arbeidsoppgave}, evt. å angi et maksimalt antall, f.eks. Arbeidsoppgave/10, altså at man kan registrere maksimalt 10 arbeidsoppgaver pr. person.

Vi konkluderer: Dersom det ikke finnes gode grunner for noe annet, bør vi sørge for at attributter ikke er sammensatt av mindre deler. Det avgjørende er at de dataene som lagres i ett attributt ikke skal splittes opp videre, altså at de brukes atomisk.

3.4.

Domenebegrepet.

I en detaljert beskrivelse av en datamodell kan man ønske å ha med hvilke "mulige verdier" et attributt kan ha, og kanskje også hvorledes disse kan tenkes å bli representert i en datamaskin. Det teoretiske "settet av mulige verdier" (engelsk: "pool of values") kalles ofte for et domene, mens detaljer om f.eks. hvorledes tall av forskjellig størrelse lagres i en datamaskin ofte kalles for en fysisk representasjon eller lagringsformat. Siden begrepet ER-modell ikke er presist definert, vil det være forskjellig fra miljø til miljø hvorvidt man har en detaljert domenebeskrivelse eller ikke i forbindelse med en datamodell.

14Noen databasesystemer tillater slike repetisjoner ved at man kan definere at et attributt gjentas et antall ganger. Dessuten har mange systemer mulighet for å definere et (mer eller mindre) "fri-tekst"-felt, som også strengt tatt bryter atomærkravet. 15Sidesprang: Et av diskusjonemnene innen fagmiljøer i databasesystemer er nettopp om man bør tillate slike repetisjoner. Spørsmålet er nært knyttet til det vi kaller normalformer for databaser og datamodeller, hvor "første normalform" nettopp forbyr slike repeterende attributter. Forkjemperne for at repetisjon skal være tillatt, snakker derfor om "non first normal form" (NFNF). Det går også under navnet NF-square, eller (NF)2.

31

Kap. 3

MER OM ATTRIBUTTER, ENTITETSTYPER OG RELASJONSTYPER.

Noen eksempler på attributter med domenebeskrivelser:

Attributt______ Postnr Kundenr Ansattnavn Selgemavn Salgsdato Betalingsfrist Rabatt Bestillingsantall

Domene______ Norsk postnr Kundenr Personnavn Personnavn Dato Dato Rabattkategori Bestillingsantall

Lagringsformat Heltall, 2 bytes16 Heltall, 4 bytes Streng, 30 bytes (som over) Heltall, 4 bytes (som over) Kodes som heltall, 1 byte Heltall, 4 bytes

I tillegg ville man da trenge en beskrivelse av hvert domene, f.eks.

Domene

Tillatte verdier/regler:

Norsk postnr Kundenr Personnavn Rabattkategori Bestillingsantall Dato

4-sifret positivt heltall heltall f.o.m. 10000 t.o.m. 99999, Bokstaver og blanke tegn, etternavn først, max. 30 tegn. Storkunderabatt, Småkunderabatt, Ingen ra ?tt. Positivt heltall, maksimalt 1 million. Lovlig dato etter gitte regler.

Under Dato kan vi trekke inn utseendet på data, som (/ ). På tilsvarende måte kan vi definere f.eks. at beløp alltid beskrives med desimalkomma, og med punktum for hver tusen. Det kan diskuteres hvorvidt dette hører hjemme i en domenebeskrivelse eller ikke. Domenene vil tilhøre datamodellen som helhet, ikke noen bestemt entitetstype. Ideelt sett bør en slik domenebeskrivelse også være gjennomgående for flere datamodeller, f.eks. innen samme . ma. Fordelen med en slik domenebeskrivelse er at man får gruppert attributtene i forskjellige typer med forskjellige egenskaper, bl.a. slik at personnavn som opptrer i forskjellige sammenhenger (f.eks. som ansattnavn, selgernavn forsikringstagernavn, forbryternavn) kan få en lik struktur, og det kan knyttes samme regler og beskrivelser til disse. Et domene blir derfor en abstraksjon av attributter med samme egenskaper, en slags attributtklasse eller attributtype, hvor altså attributtene er forekomster eller instanser av et domene.

DOMENER

Personnavn

fonnr

ATTRIBUTTER

Polisen

Ansattnavn orjelfnr Mobil telfnr Skatteyter navn Privat telfnr

-Reisepolisenr ivspollisenr oligpolisenr ilpolisenr

Hvis vi forutsetter at et domene alltid blir representert på samme måte f.eks. i et firma, kan vi sette opp følgende datamodell for sammenhengen mellom representasjon, domene og attributt17:

For de som ikke er kjent med datamaskinbegreper: 1 en byte kan man lagre 8 kombinasjoner av 0 og 1 tilsammen 256 kombinasjoner. 1 2 bytes kan man lagre 256*256 kombinasjoner etc. Når vi snakker om en semantisk datamodell, er poenget nettopp at slike lagringsmessige detaljer er uinteressante for selve datamodelleringsprosessen. 17Noen vil snakke om flere typer representasjon, som lagringsformat, presentasjonsformat osv. Modellen blir da noe mer komplisert.

32

Kap. 3

MER OM ATTRIBUTTER, ENTITETSTYPER OG RELASJONSTYPER.

Som modellen viser, er domenebeskrivelsen er en mer detaljert beskrivelse enn den fysiske representasjonen.

De sirklene vi ser i NIAM-teknikken er egentlig domener, se kap. 11.3. Domenebeskrivelser kan være mer innviklet enn bare f.eks. en maksimalt antall tegn etc. Domenet dato kan f.eks. beskrives som / , hvor er et av tallene l til 12, og hvor dag er 1 ..31 for månedene 1, 3, 5, 7, 8, 10, 12, og.... osv. Årstall beskrives med alle 4 siffer. Juliansk tidsregning brukes. Tilsvarende er domenet norsk bilnummer mer komplisert enn det man tror på forhånd, tenk gjerne gjennom de ulike mulighetene, inkl, hvilke bokstaver som er tillatt, inkl, traktor- og motorsykkelskilt, gamle bilnummer med fylkesbetegnelse etc. etc. Et annet eksempel på mer kompliserte situsjoner har vi hvis selve domenebeskrivelsen er uklar. Et eksempel: I alle fall i tidlige versjoner av Telenors Telefonkatalogen på CD-ROM kan man søke på ulike felt, som f.eks. etternavn/firmanavn, fornavn, telefonnr etc. Et av feltene heter sted, som kan være et fylke, kommune eller poststed. Problemet blir hvis man søker f.eks. på "Tromsø", som er en kommune, men som også er poststedsnavnet for noen (men ikke alle) i denne kommunen. Får man da med alle i kommunen, eller bare de som har poststed Tromsø? Enda verre blir det hvis man søker på forkortelsen Troms, som er forkortelse både for fylket, kommunen og i alle fall to poststedsnavn (Tromsø og Tromsdalen). Her bør domenet sted, gjøres om til 3 ulike domener, fylke, kommune og poststed, slik at man vet med sikkeret hvilket domene man søker innenfor.

I mange databasesystemer brukes begrepet datatype om en beskrivelse som inneholder både hvorledes data representeres i maskinen, samtidig som den ofte inneholder noe domeneinformasjon. Typisk kan et databasesystem ha datatyper som Tekststrenger (hvor man oppgir lengde) Heltall (med eller uten lengde) Desimaltall (med eller uten lengde og ant. desimaler) Dato (hvor man som regel ikke oppgir lengde) Penger (her i Norge vil i alle fall antall desimaler være fast, = 2)

De to siste datatypene er helt klart domener samtidig, mens de første ikke sier særlig om hva slags data som skal lagres, og kommer da nær lagringsformat m.m. En annen måte å snakke om domener i forhold til representasjoner på, er å kalle de for hhv. logiske og fysiske datatyper. Så vidt vi kan se, er det mest vanlige at man ikke gjør et formelt skille mellom domener og representasjoner. Det mest vanlige blant praktikerne er at man for hvert attributt i datamodellen beskriver en datatype, og bruker dette begrepet omtrent i samme betydning som i databaser. Det er dette som også gjøres i Modelator, men man har dog mulighet for gi et eget navn på en datatype, og dermed få et primitivt domene. Fordelen med dette er bl.a. at dersom du ønsker å endre hvorledes denne datatypen skal representeres, så er det nok å endre domenebeskrivelsen, så vil alle attributtene ha den nye beskrivelsen.

Det som er beskrevet i forrige avsnitt, blir av de fleste betraktet som en praktisk mellomting mellom en alt for lite presis beskrivelse, og en beskrivelse som mange vil oppfatte som overdrevet formalistisk. Men, årsaken kan vel forresten også være at mange som driver med datamodellering er svært opphengt i databasetankegangen!

33

Kap. 3 3.5.

MER OM ATTRIBUTTER, ENTITETSTYPER OG RELASJONSTYPER.

Entitetstyper.

Hva er en entitetstype?

Vi minner om det viktige skillet mellom entitet (forekomst) og entitetstype.

Enkelt sagt er en entitetstype en generalisering av 'ting", "noe", som vi på en eller annen måte vil beskrive. Vi vil typisk starte opp med entitetstyper hvor forekomstene (altså entitetene) er konkrete ting eller ting som man kjenner igjen, slik som PERSON, AVDELING, KUNDE. Etterhvert som vi utvikler modellen, vil vi ofte ha behov for mer abstrakte entitetstyper, hvor man ikke kan henvise til "noe" i virkeligheten. Et eksempel: I et firma jobber mange ansatte i forskjellige prosjekter, og vi har behov for å si noe bl.a. om timeforbruk i denne sammenhengen. Person og prosjekt skulle være temmelig opplagte entitetstyper. Imidlertid vil vi også ha behov for "det at en person deltar i et prosjekt" som entitetstype, dersom vi skal kunne si noe om hvor mange timer den enkelte person har jobbet i hvert av prosjektene som vedkommende har deltatt i. Et mulig navn på denne vil være "PROSJEKTPERSON". Skal man detaljere en slik person-prosjekt-modell videre, vil man også kunne ha behov for å måle timetall pr. person pr. prosjekt pr. uke, og dermed ha en "PROSJEKTPERSONUKEFORBRUK"-entitetstype med timetall som ét av attributtene. I slike tilfelle vil det ofte være vanskelig å finne et fornuftig navn på entitetstypen - og selvsagt også vanskeligere å forstå.

a) Vi starter med relativt opplagte entitetstyper,

b) men kommer etter hvert til mer abstrakte "ting". Det skal også innrømmes at verb/rolle-beskrivelsene ofte blir mindre fantasifulle når en kommer over i mer abstrakte "ting".

Det kan også være at entiteter gir uttrykk for ting som ikke finnes i virkeligheten, f.eks. plasseringen som forfatteren av denne boka fikk da jeg deltok i OL-konkurransen i curling i 1839. Det kan også gjelde framtidige forhold eller forhold som man håper på, eller hendelser, f.eks. en kollisjon eller en persons opptreden på et bestemt sted. I forbindelse med hendelser er det viktig å understreke at det vi er interessert i, er "hva som er interessant å si noe om" i form av verdier, navn osv. ikke "hva som skjer" i forbindelse med en hendelse.

Entitetstyper kan altså være abstraksjoner av bl.a.: • konkrete ting, personer o.l. • abstrakte, men vanlig kjente ting, som f.eks. "PROSJEKT". • helt abstrakte ting, som f.eks. "PROSJEKTPERSONUKEFORBRUK" over. • følelser, meninger (hvis vi har noe målbart å si om dette) • hendelser i fortid, nåtid eller framtid (hvis vi har noe målbart å si om dette).

34

Kap. 3

MER OM ATTRIBUTTER, ENTITETSTYPER OG RELASJONSTYPER.

Når vi velger hvilke entitetstyper vi vil ha med i modellen, er det altså uttrykk for at "dette er interessant å si noe om". Det er viktig å være bevisst på at entitetstypene ikke er "gitt på forhånd", entitetstypene er jo uttrykk for klassifikasjoner som vi har valgt, og som som vi tror kan være fruktbare i vår sammenheng. Hva man velger som entitetstyper er derfor viktig også når man skal foreta en avgrensning av hva som skal være med i det systemet man skal beskrive, og like viktig, hva man velger at ikke skal være med i systemet. En slik avgrensning er en av de viktigste avgjørelser man gjør i forbindelse med en system- og organiasjonsutvikling!

Vi skal under komme med en del tommelfingerregler for hvorledes man skal avgjøre om "noe" (eller snarere en generalisering av mange "noer" som har samme struktur) bør oppfattes som en entitetstype eller ikke, og forskjellen på entitetstyper og attributter. Tommelfingerregel 1.

1 en bok i datamodellering beskrives en entitet som "noe som kan beskrives med minst to utsagn" (Øren 1985, s. 47). Eksempelvis kan man komme med mange utsagn om en bestemt kunde - altså entiteten, mens det vel neppe er noe mer å si om kundens kundenummer, 51834 - som er en attributtverdi. Et attributt er altså en opplysning om noe annet, nemlig entitetstypen.

Tommelfingerregel 1: En entitetstype bør normalt ha minst to attributter. Hva vi mener det er viktig å si om for hver entitetstype, blir spesifisert i hvilke attributter vi har med for den bestemte entitetstypen. Attributter for en entitetstype kan i denne sammenheng grupperes i to: • identifiserende attributter (som brukes til å "blinke ut" en bestemt entitet (dvs. forekomst) ofte uten å gi ytterligere informasjon. Eksempler: kundenummer, ansattnummer. Disse gir ofte ikke noen informasjon i seg selv. • ikke-identifiserende attributter, som beskriver det som er identifisert via identifikatoren. Både definisjonen med "minst to utsagn" og at man både trenger identifiserende og ikke-identifiserende attributter, gir oss oss følgende tommelfingerregel:

Den eneste grunnen til at vi noen ganger vil ha en entitetstype med bare ett attributt, er for å kontrollere f.eks. verdier som tastes inn mot et sett av lovlige verdier. Et eksempel: Et firma har kunder i forskjellige land, og ønsker ikke å bruke noen bestemte koder, forkortelser el.l. på landsnavnene. Samtidig vil de ha mulighet for å sjekke at man ikke taster inn samme land under forskjellige navn (Storbritania, Storbrittania, Great Britan, United Kingdom ..). Vi kan da legge navn på de ulike landene i en egen entitetstype, slik at navnet på landet blir en fremmednøkkel i Firma. Altså må man registrere en av de lovlige landsnavnene. Vi kommer tilbake til dette i kap. 6.4.1 boka "Databasorienterad systernutveckling" kaller professor Bo Sundgren slike ett-attributts entitetstyper for pseudoentiteter (Sundgren 1992, s. 166).

Tommelfingerregel 2.

En entitetstype er en abstraksjon av (flere) entiteter som har noe felles. Dersom en entitets"type" kun har én forekomst, vil vi derfor sjelden ta den med i datamodellen.

Et eksempel: Vi har en beskrivelse av typen: "Vi skal lage en datamodell for i forbindelse med ansattforhold i et firma. Firmaet har mange avdelinger, og de ansatte ....". I et slikt tilfelle ser vi ingen grunn til å ha med firma som egen entitetstype. Unntaket kan være hvis vi f.eks. har et tall som kan variere over tid. Hvis f.eks. totalomsetningen og antall biler som firmaet har pr. dags dato er

35

Kap. 3

MER OM ATTRIBUTTER, ENTITETSTYPER OG RELASJONSTYPER.

interessant, kan det kanskje være grunn til å ha slike forhold som attributter. Disse vil i så tilfelle komme i en egen entitetstype (som ikke er relatert til andre) - selv om det ikke er en abstraksjon fra flere like verdier. Vi understreker imidlertid at det her er snakk om sjeldne unntak - og vi har dermed følgende tommelfingerregel-

Tommelfingerregel 2: Entitetstyper er vanligvis abstraksjoner fra flere forekomster med samme struktur. Selv om abstraksjonen er bygget på flere forekomster av en ting, er det abstraksjoen vi tegner i datamodellen. Vi vil derfor anbefale at alle entitetstyper gis entalIsbetegnelser (AVDELING, ikke AVDELINGER).

Tommelfingerregel 3:

Et tredje forhold som gir grunnlag for en tommelfingerregel, er det at samme opplysninger, i form av attributter ikke bør gjentas unødvendig i samme datamodell. Grunnen til dette er naturligvis at overlapping vil føre til opplysninger om samme entitet vil finnes flere steder, noe som ofte vil være problematisk (redundans- og inkonstensproblemer).

Et eksempel: Vi ønsker å utvide ansattsystemet slik at det også inneholder en lønnsdel for de ansatte. Vi vil da forsøke å unngå at de samme personopplysninger finnes på nytt i en annen entitetstype som f.eks. Lønnstaker. Slike endringer kan naturligvis føre til at man må justere den tidligere modellen, slik at man f.eks. også betrakter vikarer som ansatte. Eventuelt kan man tenke seg at man legger til et nytt attributt, f.eks. ansatt kategori for å skille mellom kategorier av ansatte.

Tommelfingerregel 3: Hver entitet (forekomst) bør helst beskrives i bare en entitetstvpe.

I noen tilfelle vil denne regelen virke noe kunstig. På et sykehus vil man antagelig skille mellom PASIENT og ANSATT, selv om noen av de ansatte naturligvis kan være pasienter ved samme sykehus.

Tommelfingerregel 4.

Siste tommelfingerregel sier samtidig noe om forskjellen på en entitetstype og et attributt. Av og til vil skillet mellom entitetstype og attributt være vanskelig å fa øye på. Vi skal gi to eksempler på dette:

Eksempel 1: La oss si at vi har et boksystem, og at vi for hver bok vil notere et fritt antall emner som denne boka omhandler. Samtidig kan samme emne gå igjen i flere bøker:

Uheldig sammenblanding av entitetstype og attributt

Det vil være fristende å sette emne som attributt til entitetstypen EMNE. Vårt poeng her er imidlertid at vi bør skille mellom EMNE som "ting", og det vi lagrer om en slik ting, nemlig emneordet. I dagligtale går imidlertid dette om hverandre, jfr. også teksten rett over forrige figur - som altså bør rettes opp! Grunnen til at attributt og

36

Kap. 3

MER OM ATTRIBUTTER, ENTITETSTYPER OG RELASJONSTYPER.

entitetstype var vanskelig å skille her, var antagelig at dette er et eksempel på et unntak fra tommelfingerregelen om at alle entitetstyper må ha minst to attributter. Hvis vi i stedet hadde innført et emnenummer, ville det vært mer naturlig også å snakke om emnenavn.

Eksempel 2: Hvis privat telefonnummer til den ansatte er et interessant attributt f.eks. for en ansatt, bør dette attributtet kalles telefonnummer, ikke bare telefon. (Telefon kunne vært et naturlig navn for en entitetstype, ikke for et attributt.) Enda bedre: Kall det Privat telefonnr, i motsetning telefonnr på jobben.

Tommelfingerregel 4: Sørg for at entitetstyper ikke har samme navn som attributter. Siden attributter er noe som skal kunne gis en verdi, vil de ofte hete noe med nummer eller navn

Begrepet relasjon i datamodeller og i relasjonsdatabaser.

3.6.

Vi møter begrepet relasjon også i ordet relasjonsdatabaser, men det er viktig at dette er i en helt annen betydning enn innenfor datamodelleringen. En relasjon i en relasjonsdatabase er det vi kaller for en tabell / register / fil i forbindelse med databaser.

Relasjonsbegrepet i matematikk. For å forklare denne bruken av begrepet relasjon, må vi gå til matematikken. Mange lærebøker i matematikk for høgskole/universitetsnivå har et eget kapittel om relasjoner, og begrepet er på en måte like fundamentalt som funksjonsbegrepet slik vi kjenner det i matematikk.

Vi har f.eks. en variabel x som kan ha verdiene x,, x2, x3, x4 osv. og y som kan ha verdiene Yi, y2> y3, y4 osv. Hvis x3 og y2 er relatert til hverandre i en eller annen sammenheng, sier vi at kombinasjonen (x3,y2) er sann. Tilsvarende f.eks. med (X|,y,). Hvis f.eks. x, og y4 ikke er relatert, sier vi at (x,,y4) ikke er sant. Relasjonen består da av alle kombinasjoner (x,y) som er relatert. Disse kan f.eks. settes opp i en tabell, slik:

X3

y2

X|

y.

osv., hvor X] y4 ikke er med.

En slik opplisting beskriver altså en relasjon i matematisk betydning. Hvis x-ene hentes fra et domene D, og yene hentes fra et domene D2, kan relasjonen skrives som R(x,y), hvor x e18 D, og y e D2. Alternativt kan den skrives som xRy, hvor R betraktes som en operator som "handler" på de to operandene x og y. Det er egentlig det samme som vi har fra elementær matematikk. Vi bruker f.eks. operatøren +, som i uttrykket x + y "handler på" x og y og gir et resultat, nemlig summen av disse. I forbindelse med relasjoner far vi imidlertid ut om verdien "sann" (altså at den bestemte (x,y)-kombinasjonen er sann), eller "ikke-sann" (hvis den bestemte (x,y)kombinasjonen ikke er sann).

Relasjonsbegrepet kan utvides til et vilkårlig antall variable. Hvis vi f.eks. har R og variablene a,b,c,d, .... som er definert over gitte domener, vil relasjonen R(a,b,c,d, ....) bestå av de kombinasjone av disse variablene som "hører sammen", dvs. er sanne.

Relasjoner i en relasjonsdatabase.

18 Tegnet e betyr "er et element i domenet".

37

Kap. 3

MER OM ATTRIBUTTER, ENTITETSTYPER OG RELASJONSTYPER.

Dersom eksemplet skulle anvendes på et informasjonssystem i stedet, kan vi f.eks. tenke oss at x = studentnr og y = kursnr for et lærested, mens relasjonen er "har tatt eksamen i". R(x,y) består dermed av alle (studentnr,kursnr)-kombinasjoner som representerer studenter som har tatt de enkelte kurser ved dette lærestedet.

Hvis student nr. x3 har tatt kurs nr. y2, er altså relasjonen sann for (x3,y2) .Tilsvarende f.eks. med (x^y,). Hvis student nr. xj ikke har tatt kurs nr. y4 er (x„y4) ikke sann. Vi kunne altså tenke oss tabellen over som en opplisting av de (x,y)-kombinasjoner som gjør relasjonen "har tatt eksamen i" sann. Vi far dermed en relasjon/tabell slik vi kjenner den fra relasjonsdatabaser. Studentnr 21 21 17

Kursnr 1010 1020 1010

De kombinasjonene som vi ser her, er altså de som er "sanne", i den betydning av de refererer seg til studentnr som har tatt det aktuelle kursnr. Hvis student nr. 24 ikke har tatt kurs nr. 1010, skal hun heller ikke være med i relasjonen over. For en beskrivelse av teorien bak relasjonsdatabaser henviser vi til standard innføringsbøker i databasesystemer. Grunnen til at dette tas opp i det hele tatt, er for å gi en viss anelse om hvor begrepet relasjon i forbindelse med relasjonsdatabaser kommer fra.

Relasjonstyper og relasjoner i datamodeller.

Som vi ser, er ordet relasjon slik det brukes i matematikk og i relasjonsdatabaser, noe annet enn det som brukes i datamodellering, hvor vi som kjent snakker om relasjoner (dvs. forekomster) og relasjonstyper (dvs. kategori­ seringen) når vi beskriver hvorledes de forskjellige entitetstypene er logisk og begrepsmessig knyttet sammen jfr. innledningskapitlene.

Det er temmelig forvirrende at samme begrep blir bruk forskjellig i såpas nærliggende sammenhenger. Noen forsøker å unngå hele problemet ved å bruke begrepet som forhold eller sammenheng (f.eks. Gerhard Skagesteins bok "Dataorientert systemutvikling", Skagestein 1996) når det snakkes om relasjoner og relasjonstyper i en datamodell. Jeg tror imidlertid det skal vanskelig gjøres å unngå å høre ordet relasjon(-stype) brukt i begge betydninger, jfr. at datamodellering på engelsk vanligvis kalles "Entity-Relationship Modeling" ER-modellering, ERM m.m. Jeg vil derfor slå et slag for å forklare hvordan ordet brukes i matematikk og " ’ relasjonsdatabaser og hvorledes dette er forskjellig fra slik vi bruker det i datamodellering. Ti! slutt kan det nevnes at engelskmennene ikke har de samme problemene som oss når det gjelder begrepsforvirring, fordi de skiller mellom • •

3.7.

relation relationship/relationship type -

i matematikk og i relasjonsdatabaser i datamodeller

Relasjonstyper.

Dersom et antall entitetstyper er valgt ut til å være intereressant som et system, dvs. danne en helhet - er det nesten pr. definisjon naturlig at det finnes en eller annen sammenhengstruktur mellom entitetstypene. Den sammenhengsstrukturen vi er interessert i når det gjelder datamodellering, går på hvorledes entitetstypene er ogisk knyttet til hverandre, i form av hvor mange forekomster av den ene entitetstypen som kan knyttes til én forekomst av den andre typen. Som vi har sett: vi er interessert både i det minimale og det maksimale antall forekomster.

38

Kap. 3

MER OM ATTRIBUTTER, ENTITETSTYPER OG RELASJONSTYPER.

Noen få sammenhengsstrukturer er interessante bare "den ene veien", det vi kan kalle ensidige relasjonstyper. For et stikkordsregister for en bok, med entitetstypene Side

Emne_i_bok

rei. er uinteressant denne veien, dvs. en ensidig relasjonstype.

vil det helt sikkert være interessant "For et gitt emne, hvilke sider finnes emnet på", mens det motsatte neppe er interessant. Vi kaller gjerne slike relasjonstyper for ensidige.

I de aller fleste tilfelle er imidlertid sammenhengen interessant begge veier. Dette gjelder så og si alt vi har vært borte i tidligere - og vi har derfor nesten ikke tenkt på muligheten av ensidige relasjonstyper. Vi er bevisst at når vi snakker på typenivå, snakker vi om relasjonstyper mellom forskjellige entitetstyper, mens man på forekomstnivå snakker om relasjoner mellom entiteter.

Som for entitetstyper ser vi også her litt på noen tommelfingerregler: Tommelfingerregel 1.

Første tommelfingerregel går på en struktur som er svært vanlig i de fleste systemer, hvor man har én forekomst som danner et "hode" for en rekke opplysninger av samme art. Det viktig å se at disse er to ulike ting, slik at man får både en entitetstype med "hode"-opplysninger og en med "linje"-opplysninger. Vi har allerede vært borte i Ordre-Ordrelinje, men kan nevne en rekke andre eksempler:

Tommelfingerregel 2. Et godt råd, som fortjener en egen ramme, er at man for hver relasjonstype bør spørre hvilken tidsdimensjon som relasjonstypen gjelder for. Som vi har vært inne på tidligere, kan det bl.a. være snakk om • "i øyeblikket" • "for tiden" • at vi ønsker å ha med full historikk. • på et bestemt tidspunkt • for et tidsrom

Det er viktig å være bevisst på tidsdimensjonen, og modellen vil ofte bli forskjellig avhengig av vårt valg mht. dette. Et eksempel: I Avdeling - Ansatt hvor vi skal se på ansattforhold. Dette kan tolkes i to retninger:

39

Kap. 3

MER OM ATTRIBUTTER, ENTITETSTYPER OG RELASJONSTYPER.

enten: Det er kun hvilken avdeling den ansatte jobber i for øyeblikket som er interessant. I så tilfelle er dette antagelig en l:m-relasjonstype (forutsatt at man bare kan arbeide i en avdeling om gangen).

eller: Vi ønsker å ha med historikken, slik at vi vet hvilke avdelinger den ansatte har jobbet i over tid. Dette blir klart en m:m. Dette kan igjen modelleres på (minst) 2 måter, avhengig av hvorvidt vi skiller ut historikken og det nåværende, eller om man lar de finnes i samme relasjonstype.

Skillet mellom de to løsningene kommer fram i verbalbeskrivelsene. I praksis vil m:m splittes i 2 I:mrelasjonstyper med en mellomliggende entitetstype, hvor man får en fra- og til-dato. I løsningen til venstre over vil en "tom" (dvs. ikke-utfyllt) til-dato kunne brukes som tegn på at personen jobber i avdelingen fremdeles (attributtet til-dato vil i tilfelle ikke være et Nødvendig"-attributt). Vi ville da i tillegg måtte ha en regel som sier at for personer som jobber i firmaet, vil vi tillate at en og bare en verdi av til-dato er tom. Blant annet av denne grunn vil antagelig løsningen til høyre være å foretrekke. Vi kan trekke to konklusjoner av dette eksempelet, nemlig at tidsdimensjonen er viktig, og at en "videre" tidsdimensjon, f.eks. fra øyeblikksbilde" til "over tid", gjør at max. 1 ofte må gjøres om til max. mange.

Før denne tommelfingerregelen vil vi derfor også gi et godt råd: Vær bevisst på tidsdimensjonen for hver relasjonstype, og dokumenter denne via en verbal- eller rollebeskrivelse.

Tommelfingerregel 2: Når man går over fra "i øyeblikket" til "over tid", vil som regel 1 :m bli til m:m, og 1:1 bli til l:m eller m:m

Tommelfingerregel 3.

I eksemplene vi har sett til nå, har vi alltid hatt at minimum er 0 eller 1, mens maksimum har vært 1 eller mange. Disse er de mest vanlige minima hhv. maksima. 1 noen tilfelle vil vi imidlertid ha andre typer min. eller max. Andre minima som kan tenkes er at minimum er et bestemt tall > 1, eller et ubegrenset minimum. Et eksempel på det første er dersom et større firma f.eks. har en policyregel som sier at for "ethvert produkt som vi

40

Kap. 3

MER OM ATTRIBUTTER, ENTITETSTYPER OG RELASJONSTYPER.

bruker i produksjonen, skal det være minimum 2 leverandører", for dermed å sikre seg mot eventuelle stopp i leveransene. Et minimum > 1 kan tegnes som en dobbelt strek for minimum19, som vist under:

Et eksempel hvor både maksima og minima kan være faste er hentet fra skoleverden. Vi antar at en klasse kan ha fra 5 til 30 elever.

Dersom man alltid har et maksimum på en eller to, kan man omformulere det med to 1 :m i stedet, slik som vist under, nemlig at et produkt alltid må ha en hovedleverandør, men det kan i tillegg ha en bi-leverandør.

Regler av denne typen vil imidlertid gjerne ha form av vanligvis-regler, og ikke av helt ubrytelige regler. Et annet eksempel på en slik vanligvis-regel, er regelen om at en student kun kan gå opp til en eksamen 3 ganger i samme fag ved samme høyskole. Selv om denne håndheves relativt strengt, ville det neppe være heldig dersom det var umulig å legge inn eksamen nr. 4 for en bestemt student. Tommelfingerregel 3: Andre minima enn 0 eller 1 og andre maksima enn 1 eller m er som gjeme vanligvis-regler, ikke ubrytelige regler. Man bør dermed ikke ta hensyn til dem under den grafiske utformingen av modellen, men notere dem som kommentarer til modellen. Dersom man virkelig har et maksimum som er et lite antall (f.eks. 2, 3, 4), bør man vurdere å omforme en m:m til flere 1 :m.

Tommelfingerregel 4. Erfaring har vist oss at det er svært sjelden at vi har 1:1 -relasjonstyper i virkeligheten. (En av de første ting jeg gjør når jeg skal se gjennom / kritisere en modell som andre personer har laget, er å spørre om de foreslåtte 1:1relasjonstyper virkelig er 1:1, eller slike forhold i virkeligheten av og til kan bli 1 :m eller t.o.m. m:m). Spesielt er 1:1 med minimum 1 på begge sider svært uvanlig. Hvis de forekommer, er det som regel et tegn på at vi har brukt to forskjellige navn om samme begrep, og at vi burde ha slått sammen entitetstypene på hver side til en entitetstype.

Tommelfingerregel 4: l:l-relasjonstyper er sjeldne i praksis.

Tommelfingerregel 5.

19 Notasjon for dette er ikke standardisert. Dette er valget som blir brukt i Modelator.

41

Kap. 3

MER OM ATTRIBUTTER, ENTITETSTYPER OG RELASJONSTYPER.

Den nest siste tommelfingerregelen vi skal gi i denne sammenhengen, er følgende: Det er svært sjelden med minimum 1 på begge sider av en relasjonstype. Vi kan gå tilbake til Ansatt-systemet igjen:

a) Vanlig struktur

b) Vanlig struktur

c) Svært sjelden struktur

Anta at vi i stedet hadde minimum 1 på mange-siden, dvs. at AVDELING MÅ ha minst 1 ANSATT. Dette betyr at 1) Hvis vi lager en ny avdeling, må den samtidig bemannes med minst en person. 2) Dersom sistemann i en avdeling slutter, må avdelingen samtidig også slutte å eksistere. 3) I praksis vil vi vel sjelden håndheve slike regler som helt ubrytelige, men heller som vanligvis-regler.

Selv om vi på dette stadiet i utviklingen av en datamodell ikke skal konsentrere oss om eventuell imple­ mentasjon i en database, er det en kjent sak at de aller fleste databasesystemer har problemer med å legge inn poster i to tabeller samtidig. Regelen vil derfor bli brutt, og ikke annet i et lite øyeblikk20. Også en regel som sier at den ansatte behøver ikke å være ansatt i noen avdeling, men hver avdeling må likevel ha minst en ansatt (dvs. at vi bytter på hvor minimum 0 og 1 står i a) i tegningen over, samtidig som vi krever at regel 1) og 2) skal gjelde), er også svært vanskelig å håndtere uten å programmere. Det å kreve at en person alltid skal være tilknyttet en avdeling for å kunne bli registrert som ansatt (minimum 1 på AVDELING-siden slik det er gjort i modellen over), er vel derimot en regel som det i mange firmaer kan være gode grunner til å håndheve som ubrytelig, og som vi derfor ikke har noen prinsippielle motforestillinger mot. Selv om det kan føre til en litt rotete begrepsbruk, kan man jo alltid opprette en eller flere fiktiv(e) avdeling(er), f.eks. "diverse", "midlertidig", og knytte de avdelingsløse opp mot en slik "avdeling". Det å ha minimum 1 på en av sidene av 1 :m, i praksis på siden med maksimum 1, er derfor svært vanlig.

Den samme argumentasjonen kunne brukes, og enda sterkere, om 1:1-relasjonstyper.

Tommelfingerregel 5: Relasjonstyper med minimum 1 på mange-siden er svært uvanlige i praksis. 1:1 med minimum 1 på begge sider bør ikke forekomme.

Tommelfingerregel nr. 6 Den siste tommelfingerregelen går på det at vi ikke skal ta med relasjonstyper som vi kan lese ut fra de relasjonstypene som allerede er tegnet opp. Vi tar et eksempel:

1 databasesystemer som har et utbygd transaksjonsbegrep kan man riktignok hindre at noen ser denne midlertidige inkonsistensen, nemlig ved at man ser på flere innsettinger som en enhet. Tilsvarende må man for hver sletting av ansatt eller overflytting av en ansatt til en annen avdeling sjekke om det fremdeles vil være noen igjen i avdelingen. Chris Date karakteriserer slike regler som "sistemann ut av rommet slukker igjen lysef'-regler (!). (Se Date 1990a).

42

Kap. 3

MER OM ATTRIBUTTER, ENTITETSTYPER OG RELASJONSTYPER.

Anta at vi utvider datamodellen slik at kursene grupperes sammen i en kursrekke, slik at hvert kurs hører bare til en kursgruppe. Modellen ville da se slik ut:

Den stiplede linjen viser en avledet relasjonstype. Det denne relasjonstypen forteller er forsåvidt sant, men det vil alltid være mulig å lese hvilke kursgrupper en person har tatt (evt. tatt deler av) ved å gå via kursentitetstypen. Hvis vi også har med den avledede relasjonstypen, vil vi både få redundant informasjon og mulighet for inkonsistenser. Et annet eksempel: Hvis datamodellen omfatter flere firmaer, slik at vi har FIRMA som egen entitetstype:

a) avledbar

b) ikke avledbar

For a) kan samme argumentasjon kan brukes, slik at Firma - Ansatt-relasjonstypen er avledbar. For b) derimot er det vel opplagt at man kan ha tatt svenneprøven i et annet firma enn det man nå jobber i, slik at denne ikke er avledbar. Vi kommer detaljert tilbake til slike problemstillinger i kapittelet om Ekvivalente stier., kap. 6.8. Vi ser her, som en rekke andre steder, at det er svært viktig å ta med en verbalbeskrivelse for relasjonstypen, eventuelt å beskrive substantivisk "rollen" som de to entitetstypene spiller overfor relasjonstypen.

Tommelfingerregel 6: Avledbare relasjonstyper bør som regel ikke tas med i en datamodell. Tas de med, bør de merkes på en spesiell måte (f.eks. med stiplet linje).

3.8.

Tegning av datamodeller - noen råd.

43

Kap. 3

MER OM ATTRIBUTTER, ENTITETSTYPER OG RELASJONSTYPER.

Vi skal konkludere dette kapittelet med et kort underkapittel med et par råd med hensyn til tegning av datamodeller.

Jobb grundig med entitets- og relasjonstyper før du konsentrerer deg om attributter. Dersom man er svært opphengt i en databasetenkning, kan det være fristende å tegne en entitetstype, finne alle dens attributter, tegne neste osv. Dette vil jeg betrakte som engrunnleggende feil arbeidsmetodikk. Min erfaring helt motsatt:

Bruk mesteparten av tiden til å jobbe på entitets- og relasjonstype-nivå. Dersom dette er gjort grundig, vil de fleste attributter "falle på plass av seg selv" i riktige entitetstyper.

Dette betyr selvsagt ikke at det ikke vil være behov for endringer etterhvert som man legger inn flere og flere attributter. Hvis modellen i utgangspunktet er fornuftig, vil imidlertid de aller fleste endringer som er aktuelle bli i form av forfininger (f.eks. ut fra det som er beskrevet i kapitlene om entitetisering og normalisering), og svært lite i form av at den grunnleggende strukturen må gjøres helt om.

Jeg vil også anbefale at man ikke konsentrerer seg så mye om minimumsbeskrivelser på det første råutkastet, siden et slikt råutkast ofte blir endret radikalt likevel.

Gi en definisjon av hver entitetstype (evt. også hvert attributt).

Ved å gjøre dette, tvinger du deg selv til å tenke igjennom hva du egenlig mener med hvert begrep. Et av de vanligste problemene når man arbeider med datamodellering, er at vi jobber med begreper som har ulike betydninger i dagligtale, og hvor man ub_evisst skifter mellom å bruke samme begrep i ulike betydninger. Et godt eksempel på dette følger i neste avsnitt (Vareeksemplar, Vare, Varegruppe etc.). Tilsvarende eksempler finnes det mange av, her følger bare noen fa: Prøve: Kurs: Annonse: Bok:

Kunde: Ansatt:

en prøve på et laboratorium, er det en konkret prøvetaking eller er det en bestemt prøvetype? er det kursdeltagelse for en gitt person, kursavholdelse, kurs som beskrevet i en kursplan? hvis "samme annonse" trykkes to ganger, er det da en eller to "annonser"? bokeksemplar, bokutgivelse (alle med samme ISBN-nr). Hva med nytt opplag, ny utgivelse, leksikon som kan bestå av mange bind, bøker hvor mange småromaner er samlet (og som tidligere er gitt ut som egne bøker)...... Er dette kun de som har kjøpt noe av oss, eller er det "mulige kunder" ("prospects"). Er du ansatt hvis du er midlertidig inne i bedriften (vikar, utplassert, vikarbyråansatt - men i praksis har jobbet på samme sted gjennom lengre tid ...).

For å klargjøre dette, vil det ofte være lurt å tvinge seg selv (eller andre!) til å beskrive noen forekomster av en slik entitetstype som et er snakk om - gjerne ved et sett attributtverdier.

Det kan lønne seg å holde en mest mulig hierarkisk struktur.

I motsetning til mange andre diagram form er, viser ikke datamodeller noen "retning" (slik man har f.eks. i dataflytdiagrammer eller virksomhetsgrafer). Jeg vil likevel anbefale at man som hovedretning tegner l:mrelasjonstyper med "1-er entitetstypen" høyere opp enn "m-entitetstypen".

Begge de gjennomgående eksemplene (ansattsystemet og ordresystemet) er tegnet på denne måten (slik at vi f.eks. ser hierarkiet mellom KUNDE, ORDRE og ORDREL1NJE), se tegninger i kap. 1. En erfaring som mange har, er at dette gjør modellen lettere å lese. Tegnemåten kan også gjøre det lettere å avsløre hierarkier i begreper. Eksempelvis kan begrepet "VARE" brukes i forskjellige generaliseringsnivåer:

44

Kap. 3 • • • •

MER OM ATTRIBUTTER, ENTITETSTYPER OG RELASJONSTYPER.

en bestemt fysisk vare (f.eks. Mark Mode! DC-70, serienr. 80403723 El), dvs. det vi kan kalle et vareeksemplar. den typen TVer generelt (alle Mark DC-70), noe som vel er synonymt med artikkel. Dette er antagelig den mest vanlige betydningen av ordet vare. det kan være at alle TV-merker generelt kalles vare (vi kan da snakke om varegrupper) det kan til og med være at vare brukes om en større kategori av varer (f.eks. elektrovarer).

Dette gir oss et hierarki på denne måten:

Dersom vi ikke hadde tegnet modellen hierarkisk, ville vi antagelig ikke fått såpass god oversikt over strukturen i de begrepene vi har valgt.

Eksempelet viser også et annet og svært viktig prinsipp innen datamodellering generelt, nemlig at man bør arbeide grundig med en begrepsavklaring, ikke minst i forhold til dagligdagse begreper som ofte har svært mange forskjellige betydningen

I tillegg til de argumentene jeg har gitt over, vil en slik standard gjøre at modeller som er tegnet av forskjellige mennesker ser mer like ut, slik at de lettere kan sammenlignes.

Jeg skrev øverst at jeg anbefaler et hierarki som hovedretning, men ikke at jeg ønsket det som en ubrytelig regel. Bruk derfor sunn fornuft for å fa en modell som ser så presentabel ut som mulig.

Plasser entitetstyper fra samme virksomhetsområde i nærheten av hverandre.

En større modell vil ofte favne flere ulike, men relaterte områder, f.eks. både en ordredel og en faktureringsdel. Det kan da lønne seg mest mulig å samle "beslektede" entitetstyper nær hverandre dersom det er praktisk mulig. Dette vil gjøre det lettere å få overblikk over en del om gangen, og dermed mentalt sett minske kompleksiteten når man skal se på systemet. Dette stemmer som kjent med det såkalte nærhetsprinsippet i psykologi og pedagogikk: man oppfatter ting som er nære hverandre (i avstand, tid eller lignende) som å høre sammen.

Del eventuelt opp en stor modell i mindre deler.

For en stor modell kan det være en fordel å se bare deler av modellen om gangen. Det kan f.eks. gjøres ved at du deler modellen opp i delsystemer, hvor du kan se bare et og et delsystem om gangen. I Modelator ver. 4 blir dette kalt for entitetstypegrupper.

Attributter sammen med den grafiske modellen i små modeller, men ikke i store.

45

Kap. 3

MER OM ATTRIBUTTER, ENTITETSTYPER OG RELASJONSTYPER.

I tegningene i denne boka er attributtene ofte satt sammen med entitetstypene på tegningen. Dette er en fornuftig for svært små modeller. Hvis man tegner en litt større modell for hånd, vil jeg imidlertid anbefale at attributtlisten skilles fra den grafiske modellen. Dette har to årsaker: • man slipper å slite ut blyant og viskelær som følge av forandringer underveis. • selve modellen blir lett uoversiktlig dersom alle attributter finnes tegnet på modellen.

I Modelator kan man velge om man vil ha med attributter i grafen eller ikke, gjeldende for alle entitetstyper eller individuelt for hver entitetstype. I tillegg kan man velge mellomformer, som å ha med kun identifikatorer, eller kun identifikatorer og fremmednøkler. Du kan t.o.m. ta med datatypene i selve modellen (hele datatypenavnet eller et fritt valgt antall tegn). For stor modeller det antagelig helt urealistisk å ha med alle attributtene i grafen, det gir for liten oversikt.

46

Kap. 4

ENTITETISERING - EN MYE BRUKT TEKNIKK

4. Entitetisering - en mye brukt teknikk 4.1.

Entitetisering av m:m-relasjonstyper.

I vår eksempelmodell har vi allerede en m:m-relasjonstype, nemlig mellom ANSATT og KURS. Ved hjelp av denne modellen kan vi se hvilke kurs hver ansatt har tatt, og for hvert kurs hvilke ansatte som har gått på kurset. Dersom vi imidlertid hadde kommet med et tilleggskrav om at vi trenger informasjon om hvilket år vedkommende gikk på hvert av kursene, ville vi fått problemer med den eksisterende modellen.

hvordan få med årstall for hvert kurs for hver ansatt?? •

•

Vi kan ikke plassere årstall som et attributt til ANSATT, fordi vedkommende kan ha tatt de forskjellige kursene i forskjellige år. Å lagre en rekke årstall, evt. kombinert med kursnummer for det/de kurs som ble tatt dette året, vil stri mot atomærkravet, som ble tatt opp i kap. 3.3.4. Vi vet dessuten ikke hvor mange årstall/kurs det kan bli snakk om pr. ansatt. På tilsvarende måte kan man heller ikke lagre årstall for når den enkelte ansatte tok kurset sammen med selve kurset.

Problemstillingen sprenger altså grensen for de entitetstypene som vi har hatt i modellen til nå. Saken er at årstallet verken har direkte med ansatt eller kurs å gjøre, men er en opplysning om forholdet disse i mellom. Siden vi i "vår" notasjon (i motsetning bl.a. til Chens opprinnelige definisjon, se kap. 11.2) ikke tillater at relasjonstyper kan ha egne attributter, må vi "ha en entitetstype å henge årstallet på". Det vil altså være en entitetstype hvor man kan legge inn attributter om ett kurs for en ansatt. Hva skal vi kalle "det at en person har deltatt på et kurs"? Det kan vel være nærliggende å kalle det kursdeltagelse. Vi får altså følgende modell:

Vi ser også at modellen gir mulighet for nye elementer, f.eks. dersom man ønsker å legge inn et eventuelt resultat (karakter el.l.) for hver kursdeltagelse. Dersom vi legger inn et attributt gangnr el.l., gir det oss også muligheten til å lagre informasjon om at samme person kan ha gått på samme kurs flere ganger, med forskjellig resultat. Samtidig ser vi at vi har definert et nytt begrep, nemlig: Kursdeltagelse = Den "ting" at en person har gått på et kurs. Ved å kalle den mellomliggende entitetstypen for Kursdeltagelse, og ikke f.eks. eksamen, har vi også tatt nærmere stilling til hva vi vil at modellen skal inneholde - nemlig at den kan inneholde informasjon også om kurs som ikke nødvendigvis avsluttes med en eksamen. Denne prosessen, at vi har en m:m-relasjonstype som vi erstatter med en ny entitetstype og to (1 :m-) relasjonstyper mellom de to opprinnelige entitetstypene, er kanskje det mest brukte "trikset" innen datamodellering, og så sentralt at vi har gitt det en egen betegnelse, nemlig entitetisering av en relasjonstype.

47

Kap. 4

ENTITETISERING - EN MYE BRUKT TEKNIKK

Legg også merke til at vi automatisk fikk minimum 1 både på Ansatt-siden og på Kurs-siden. Grunnen til dette er at dersom en Kursdeltagelse overhodet skal ha mening, må det være knyttet til både en ansatt og et kurs, dvs det er knyttet til minimum en ansatt og minimum ett kurs. Vi kan vise Kursdeltagelse som en kombinasjon av lovlige ansatte, kurs og kursdeltagelser på matriseform, slik:

Kurs. Ansatt—► 1001 r 1002 1003

100 1997 1996 1998

101

102 1995

103 1995

104

105

1998

Eksempel på KURS­ DELTAGELSE: Kurs nr 1003 ble tatt av ansattnr 104 i 1998.

I en datamodell må dette omformes slik at det blir atomisk. Hver..eéi1e med verdi må derfor representeres som en ny forekomst, derfor vil forekomster for KURSDELTAGELSE se slik ut: KURSDELTAGELSE Ansattnr Kursnr Årstall 100 1001 1997 100 1002 1996 100 1003 1998 102 1001 1995 1995 * 103 1001 104 1003 1998

Dette er den formen man vil ha dataene på i en relasjonsdatabase. 1 tillegg har vi forekomster for Ansatt og for Kurs, slik at man kan se f.eks. ansattnavn, adresse etc. fra Ansatte, samt kursbeskrivelse etc. fra Kurs.

Noen eksempler. Ordre-modellen kan også utvikles via entitetisering. Vi tar utgangspunkt i

Denne modellen er helt i orden dersom man bare vil vite hvilke varer som er bestilt på hvilke ordre. Dersom man vil vite noe mer, f.eks. antall bestilt av hver vare innenfor hver ordre, trenger jeg å splitte ORDRE/VAREkombinasjonen. Personer som er kjent med ordrebehandling, bruker gjerne begrepet ordrelinje om dette:

48

Kap. 4

ENTITETISERING - EN MYE BRUKT TEKNIKK

Igjen har vi oppnådd både å få en modell som favner mer av virkeligheten og vi har foretatt en begrepsdannelse. Vi kan nevne noen andre eksempler: •

VARE/LAGER.

Denne modellen viser hvilke varer som finnes på hvilke lagre. Dersom vi har behov for f.eks. antall-på-lager for hver vare/lager-kombinasjon, må vi gjøre samme oppsplitting igjen. NB! Vi bør være forsiktige så vi ikke kaller den nye entitetstypen for antall-på-lager! Antallet på lager er en målbar verdi (kan telles opp), mens entitetstypen er selve "tingen" (eller rettere: "tingtypen"). Hva skal vi kalle det at "det at en gitt vare finnes på et gitt lager"? Det som er vanlig når vi ikke finner noe naturlig navn, er å kalle det med en kombinasjon av de to gamle entitetstypene. 1 dette tilfelle kan det være naturlig å kalle den nye entitetstypen for Vare_på_lager.

•

ANSATT/AVDELING:

Vi tar for oss det gamle eksempelet med Ansatt og Avdeling, men antar nå at en person kan være ansatt i flere avdelinger på en gang, og slik at personen har forskjellig beskjeftigelsesprosent i de forskjellige avdelingene. Igjen får vi samme struktur. Det ville være fristende å kalle denne nye entitetstypen for Ansatt i avdeling, men forsøk selv å finne et bedre uttrykk før du kikker i fotnoten21!

Vi kan nevne i farten noen andre eksempler: • m:m mellom Bokeksemplar og Låntaker på et bibliotek: Entitetisering er nødvendig hvis du vil ha med historikk (tidligere lån). • m:m mellom Ansatt og Prosjekt. Entitetisering må gjøres hvis man skal ha med antall timer som hver ansatt har deltatt i for hvert prosjekt, når vedkommende begynte i prosjektet osv. • m:m mellom Pasient og Diagnose i et sykehussystem, hvis vi vil vite når den enkelte diagnose ble stilt for den enkelte pasient, og evt. hvis samme diagnose ble stilt flere ganger.

21 At man er ansatt et sted med en bestemt beskjeftigelses-prosent, kan naturligvis kalles for en beskjeftigelse.

49

Kap. 4 •

ENTITETISERING - EN MYE BRUKT TEKNIKK

VARE OG VARE.

Denne strukturen er spesiell, i og med at dey er en relasjonstype mellom de samme entitetstypene. Dersom vi har behov for å entitetisere en vanlig "vare - og hvilke varer som inngår i vare" (bill-of-material)- struktur, f.eks fordi vi vil si hvor mange av hver vare som inngår i hver vare, blir det slik: Vare

Varen r

Varenavn består av

For å vise helheten har jeg også tatt med fremmednøkler i denne forbindelse. Forklaring på dette finnes i kapittelet om fremmednøkler (se kap. 5.2). Vi kommer deltaljert tilbake til denne modellen i forbindelse med nettverk (se kap. 6.5.2). Tips. Dersom denne splittingen er vanskelig å forstå kan du gjerne tenke deg to Vare som smelter sammen:

Man bør være klar over at en m:m-struktur kan skjule mer kompliserte strukturer. Et trivielt eksempel: Anta at vi i et svært tidlig utviklingstrinn i en beskrivelse av et ordresystem kun har to entitetstyper, Kunde og Vare. Kunde

Vare

^-Q———CHc Kundenr

Varenr

Kundenavn

Varenavn

Pris ......

En entitetisering av denne vil naturlig frambringe ORDRE. Ved nærmere ettertanke er det imidlertid et m:m mellom ORDRE og VARE igjen, slik at vi er nødt til å gjøre en ny entitetisering mellom disse igjen for å fa en modell med hvor ORDRELINJE også er med.

50

Kap. 4

ENTITETISERING - EN MYE BRUKT TEKNIKK

Slike mer komplekse strukturer kan forøvrig være skjult også i andre tilfelle, f.eks. kan det være at en l:mrelasjonstype ved nærmere ettersyn bør splittes opp i flere 1 :m-relasjonstyper med mellomliggende entitetstyper (jfr. hierarkiet med hensyn til forskjellig betydninger av begrepet vare, kap. 3.7). Min erfaring er at entitetisering er svært nyttig i forbindelse med utvikling av datamodeller, idet vi begynner modelleringen med "opplagte" entitetstyper, oftest med m:m-relasjonstyper mellom, for så å se at man har behov for entitetisering for å få med alle de attributtene som er ønskelig.

Ulike meninger om bruk av m:m Vi bør avslutningsvis peke på at det er noe forskjellige meninger om bruk av m:m-relasjonstyper i datamodeller.

•

•

•

Den ene ytterligheten er at man (i alle fall på kladdestadiet) kan sette nye attributter direkte på relasjonstypen uten å entitetisere denne. Vi mener imidlertid dette ville gjøre det vanskelig å ha et klart skille mellom entitetstyper og relasjonstyper. Den andre ytterligheten, at man overhodet ikke tillater m:m-relasjonstyper i datamodeller forekommer også, med den begrunnelsen at de ikke kan implementeres i databasesystemer. Vi mener imidlertid at dette er å starte i feil ende: en datamodelleringsprosess skal ta utgangspunkt i virkeligheten (jfr. virksomhetsperspektivet), ikke i en database. Vi foreslår altså en mellomløsning, nemlig å bruke m:m-relasjonstyper under utformingen av datamodellen. Dersom det er "mer å si om relasjonstypen", vil vi imidlertid entitetisere, for dermed å få fram nye begreper og å kunne legge inn nye attributter som måtte være nødvendige. Vårt råd er altså: Behold m:m-relasjonstyper så lenge som mulig !

Dersom vi vil at datamodellen skal overføres til en relasjons-databasestruktur, er vi (dessverre) nødt til å splitte også de resterende m:m-relasjonstypene. Dette er imidlertid det aller siste vi bør gjøre før vi danner relasjonsdatabasen, og er en helt mekanisk prosess, slik vi har sett i dette kapittelet.

4.2.

Entitetisering av l:l-relasjonstyper.

Entitetisering er utvilsomt mest brukt i forbindelse med m:m-relasjonstyper. Vi skal imidlertid se at det også kan være nyttig i forbindelse med l:l-relasjonstyper hvor begge minima er 0. Standardeksempelet her er følgende:

I følge norsk lov er dette en "for tiden"-beskrivelse, man har ikke lov til å være gift med flere personer på samme tid22. Som vi ser av minimum O-betingelsene på begge sider, kan dette illustrere menn og kvinner generelt, enten de er gift eller ikke. Dersom man skal ha med f.eks. ekteskapsdato eller antall barn i dette ekteskapet, kunne slike attributter naturligvis alltid plasseres på Mann, evt. alltid på Kvinne. En slik løsning er vel imidlertid lite hensiktsmessig, av flere grunner: • Hva man velger vil være tilfeldig (eller diskriminerede?) • Ekteskapsdato og antall barn gjelder ikke mannen eller kvinnen som sådan, men forholdet dem imellom. • Hvis vi plasserte disse to attributtene f.eks. på MANN, ville vi få en rekke entiteter (dvs. forekomster) hvor disse to attributtene ikke gjalt, nemlig for alle som ikke var gift. (Ingen av disse attributtene kan ha Nødvendig-egenskapen).

Vår løsning vil derfor være en entitetisering:

22Det blir alltid mye moro når man i en undervisnings-situasjon setter opp 1 :m, mange-til-en eller m:m mellom Mann og Kvinne. De to første av disse formene kalles som kjent polygami og polyandri.

51

Kap. 4

ENTITETISERING - EN MYE BRUKT TEKNIKK

Vi bør observere at entitetisering kun er aktuelt når selve forholdet er symmetrisk, dvs. kun i tilfellene • •

4.3.

m:m-relasjonstyper 1:1 -relasjonstyper med minimum 0 på begge sider.

Entitetisering i Modelator.

Modelator støtter den arbeidsmetodikken som er nevnt over, i og med at entitetisering gjøres automatisk når man måtte ønske det. Det skjer ved at man legger en ny entitetstype på en relasjonslinje med mrm (ev. 1:1 med mimmum 0 pa begge sider). Etter en bekreftelse vil systemet utføre den splittingen som er beskrevet over automatisk, inklusive korrekt plassering av minima. Den omvendte prosessen, nemlig å gå tilbake til en m:m-relasjonstype (evt. 1:1 med minima 0) fra en entitetisert situasjon gjøres også automatisk i Modelator. Verbalbeskrivelsene må i praksis gjøres om etter en entitetisering, slik at de slettes.

52

Kap. 5

REGLER FOR FREMMEDNØKLER

5, Regler for fremmednøkler Vi har så vidt vært inne på fremmede attributter i innledningskapitelet og i kap. 3.2. Et fremmed attributt er et attributt som settes inn for å danne en kobling mellom to entitetstyper, og er dermed "limet" i en relasjonsdatabase.

En fremmednøkkel består av et eller flere fremmede attributter som tilsammen danner en helhet. En slik fremmednøkkel vil alltid referere til identifikator i den relaterte entitetstypen. Hvis identifikatoren i den relaterte entitetstypen består av bare ett attributt, vil fremmedattributtet også være hele fremmednøkkelen. For å klargjøre dette:

a) Avdeling/ansatte

b) Fra forenklet boklånssystem

Som vanlig bruker vi understreking for å vise identifikator, og * for å vise fremmedattributter. I det siste eksempelet antar vi at vi har et bibliotek hvor hver bok (identifisert med sitt ISBN) kan finnes i flere eksemplarer. Kombinasjonen av ISBN og eksemplarnr er nødvendig for å skille de forskjellige bokeksemplarene (av samme bok) fra hverandre.

5.1.

Bør fremmednøkler være med i en datamodell?

Mange vil prinsippielt sett svare nei på dette spørsmålet. Fremmednøkler kan egentlig ses på som en implementasjonsmekanisme for relasjonstypene i en datamodell. Vi vil likevel argumentere for at det kan være en fordel å ta dem med i datamodellen, i alle fall når man begynner med "finarbeidet" på modellen. Siden fremmednøklene slik vi arbeider med det er en konsekvens av relasjonstyper og identifikatorer (se senere i kapittelet) er det naturlig at det tas samtidig med at identifikatorer spesifiseres. Vår begrunnelse for å ha fremmednøkler med i forbindelse med datamodellering er denne: Datamodellering blir i dag mest brukt som grunnlag for å lage en databasestruktur som skal implementeres i en relasjonsdatabase. Hovedprinsippet i oppbyggingen av en relasjonsdatabase er svært enkel å forstå - kanskje minst like lett å forstå som hovedtrekkene i datamodellering.

53

REGLER FOR FREMMEDNØKLER

Kap. 5

Mange finner det derfor naturlig å ta med fremmednøkler allerede fra begynnelsen av datamodelleringen, eller i alle fall når man begynner med litt mer detaljert analyse. Av og til vil man kunne ha fordel av å se datamodellen som et sett med tabeller i en relasjonsdatabase, og kanskje også kunne tenke seg noen forekomster i en slik database. Andre ganger vil det være en fordel å kunne se på den grafiske modellen, uten i det hele tatt å tenke på attributta i vå. Vi har derfor erfaring for at det kan være en fordel å veksle mellom synssettene - noen ganger å "tenke relasjonsdatabase", andre ganger å "tenke datamodell". En annen vesentlig grunn til å ta med fremmednøkler, er at dersom de brukes som deler av identifikatoren, vil dette ofte gi mulighet for å uttrykke akkurat de skrankene som vi ønsker skal gjelde. Både dette kapittelet og kap. 6 inneholder en rekke eksempler på dette.

5.2.

Fremmednøkler i l:m-tilfellet.

Siden 1 :m-relasjonstyper er utvilsomt det vanligste i en datamodell, vil vi bruke dette som illustrasjon av bakgrunnen for fremmednøkkel-begrepet.

Avdeling

Avdelingsnr

Vi tar for oss ansattsystemet enda en gang, og ser på hvorfor og hvorledes vi legger til fremmedattributter. Noen vil kanskje synes vi går vel grundig til verks for å komme fram til en "opplagt" konklusjon, men vi mener det kan være fornuftig å se på dette litt nærmere, slik at man ser hvorfor strukturen nødvendigvis må bli som den blir.

Hvis vi kun hadde han med attributter fra de to entitetstypene isolert, ville vi finne fram til alle opplysninger om avdelingene og de ansatte som sådan.

Avdelingsnavn

Ansatt

Ansattnr

Vi vil derimot ikke kunne finne f.eks. avdelingsnr eller avdelingsnavn for den avdelingen en gitt person jobber i. Hvorledes skal en slik kobling foregå? • Hvis vi ikke hadde relasjonstypene til å vise koblinger, ville vi bare kunne gjort to typer utvidelser: Vi Kunne enten legge til et nytt attributt, eller, hvis det ikke går, legge til en ny entitetstype. • For å være sikker på at vi gjør koblinger som ikke kan gi mulighet for flertydighet, bør vi ta utgangspunkt i en eller flere av identifikatorene. Vi kan ikke være sikker på at f.eks. alle avdelingsnavn er forskjellige, dermed kan vi ikke vite at vi 'kobler" riktige data. Derimot vet vi at alle avdelingsnr er forskjellige. Vi har kun to muligheter: • Vi kunne forsøkt å legge Ansattnr som ekstra attributt i Avdeling. Dette ville imidlertid føre til at vi for hver avdeling fikk flere ansattnr-attributt, ett for hver ansatt. Vi kunne heller ikke vite hvor mange vi trenger, fordi vi ikke vet hvor mange ansatte som kan finnes i hver avdeling. Det er derfor ikke noe godt forslag, og det strider også mot atomærkravet (se kap. 3.3.4). • La oss prøve det andre, nemlig å legge Avdelingsnr inn som ekstra attributt i Ansatt (på mange-siden). Siden hver ansatt i følge datamodellen kun kan jobbe i en avdeling, vil vi her aldri fa problemer med atomærkravet. For en gitt ansatt kan vi også se direkte avdelingsnr for avdelingen som vedkommende jobber i, og dermed indirekte finne avdelingsnavnet (hentes fra Avdeling ut fra det kjente avdelingsnr). Dersom vi ønsker å gå den motsatte veien, f.eks. gitt avdelingsnr = 17, finn alle ansattes navn og telefonnr, kan vi bare søke etter alle med avdelingsnr 17 i Ansatt, og dermed finne den ønskede informasjon. Vi ser at denne strukturen er enkel, samtidig som den gir samme informasjon som det som ligger i relasjonstypen.

Vi kommer dermed med følgende forslag til struktur: AVDELING

Avdelingsnr Avdelingsnavn

AWATT

Ansattnr Ansattnavn

*Avdelingsnr

54

Fremmednøkkelen legges på mange-siden.

Kap. 5

REGLER FOR FREMMEDNØKLER

Dersom identifikatoren på "en"-siden er sammensatt av to eller flere attributter, vil vi naturligvis måtte ta med alle disse som fremmede attributter på "mange"-siden, slik at de til sammen danner fremmednøkkelen.

Vi har følgende enkle regel:

Ved 1 :m-relasjonstyper legges (den muligens sammensatte) identifikatoren fra en-siden som fremmednøkkel på mange-siden. Som vi alt har sett, vil vi i denne boka bruke * for å markere fremmednøkkelen. Andre måter å markere den på, er å bruke en stiplet linje (Avdelingsnr) eller å skrive (f) bak. Dersom det kan være tvil om hvilken entitetstype som fremmednøkkelen "kommer fra", bør dette noteres separat.

Fremmednøkler og Nødvendig-egenskapen.

Dersom vi spesifiserer fremmede attributter i en datamodell, ser vi at Nødvendig-egenskapen eller "ikkeNødvendig" for fremmede attributter er det samme som "minimum 1" eller "minimum 0" på "den motsatte siden av relasjonstypen", se figuren under.

Minimum 0 gir ikke-Nødvendig

a) Avdeling-Ansatt med min. 1

b) Avdeling-Ansatt med min. 0.

Et minutts gjennomtenkning kan være nødvendig for å forstå denne sammenhengen, som er et helt fast mønster i forbindelse med datamodellering og databasedesign.

Siden denne regelen gjelder "begge veier", kan vi om ønskelig påtvinge databasen til å overholde "minimum 1"regelen ved å sette Nødvendig-egenskapen på fremmednøkkelen.

Fremmednøkler må ha samme datatype og lengde, men kan ha forskjellig navn. Siden fremmednøklen i en entitetstype skal "matche" identifikatoren i en (som regel annen) entitetstype, er det naturlig at den må ha samme datatype og lengde som dens "eier". Det gir lite mening å sammenligne en tekststreng med et heltall! I de aller fleste tilfelle vil man også bruke samme navn på identifikator-attributtene og fremmedattributtene, slik som f.eks. Avdelingsnr i eksempelet over. For å klargjøre forholdet, kunne vi i stedet ha kalt fremmednøkkelen for Ansatts avdnr el.l. Det er altså ikke noe krav om at fremmednøkkelen og "originalen" har samme navn.

55

Kap. 5

REGLER FOR FREMMEDNØKLER

I noen tilfelle må vi endre navnet på fremmednøkkelen for å hindre at samme attributtnavn forekommer flere ganger. De to mest vanlige tilfellene her er • "egenrelasjoner", dvs. hvis entitetstypen er "relatert til seg selv". • hvis det er flere 1 :m mellom de samme entitetstypene. Vi skal se på eksempler på disse to tilfellene:

Nødvendig Ikke-Nødvendig

a) Hierarki med endring av fremmednøkkelnavn

5.3.

b) Flere relasjonstyper mellom de samme med endring av fremmednøkkelnavn. NB! Fremmednøklene gjelder hver sin relasjonstype.

Fremmednøkler i m:m-tilfellet.

Vi bruker Ansatt-Kurs-eksempelet igjen:

Hvis vi hadde forsøkt å legge fremmednøkler på noen av sidene, ville vi i begge tilfelle fatt repeterende attributter. Som vi så i kap. 4 kan en m:m-relasjonstype "entitetiseres", transformeres til en ny entitetstype og to mellomliggende l:m-relasjonstyper. For hver av disse kan vi da benytte regelen for i :m-tilfellet over. Vi har altså omformet det vanskeligere m:m-tilfelle til et enklere og kjent tilfelle, nemlig 1 :m-tilfellet. En m:m-relasjonstype omformes til to l:m-relasjonstyper ved entitetisering. Identifikatorer fra begge "en" sidene blir fremmednøkler i den nye entitetstypen.

1 eksempelet over får vi:

Merk at det er kombinas|onen av Ansattnr og Kursnummer som er en mulig identifikator. I de fleste tilfelle brukes denne direkte, men f.eks. skal tillate at samme ansatt har gått på samme kurs flere ganger, må vi ha en mer utvidet identifikator, f.eks. slik at • årstall inngår i identifikator (hvis vi forutsetter at man ikke kan gå flere ganger i året på samme kurs!) • en gangnr inngåi i identifikatoren (første gang personen går på kurset er gangnr — 1, neste er gangnr — 2). • man kan ønske å legge inn et løpenummer i stedet for Ansattnr, Kursnr-kombinasjonen el.l.

56

Kap. 5

REGLER FOR FREMMEDNØKLER

Altså: • Hvis kombinasjonen av fremmednøkler bare kan forekomme en gang: bruk denne kombinasjonen som primærnøkkel. Dette er det vanligste tilfellet. (Hvis man likevel vil bruke en annen primærnøkkel må kombinasjonen av fremmednøkler defineres som en kandidatnøkkel). • ellers velg en annen identifikator, eventuelt ved å utvide identifikatoren med flere attributter.

Som nevnt tidligere, mener jeg denne entitetiseringen med fordel ventes med dersom man ikke har attributter som gjør at splittingen er nødvendig.

5.4.

Fremmednøkler i 1:l-tilfellet.

l:l-relasjonstyper forekommer relativt sjelden i praksis. Også i de tilfelle der det forekommer, kan det være grunn til å diskutere om man bør slå de to aktuelle relasjonstyper sammen til en når man begynner å tenke på implementering. Vi tar likevel opp problematikken rundt dette.

For 1 :m-tilfellet var det temmelig opplagt at fremmednøkkelen måtte settes på "m"-siden. Siden 1:l-tilfellet er symmetrisk, må vi studere dette nærmere:

Tilfelle 1: Min. 0 på en side, min. 1 på den andre.

NB: Vi studerer her en annen relasjonstype enn "jobber i", som den vi har tatt opp tidligere23.

De to naturlige mulighetene er: • Legg avdelingsnr inn som fremmednøkkel i Ansatt (for de ansatte som er avdelingsledere, vil denne altså vise hen til den avdelingen som denne ansatte er leder for). • Legg ansattnr (dvs. avdelingslederens ansattnr) inn som fremmednøkkel i avdeling. Ifølge datamodellen finnes det ansatte som ikke er avdelingsledere (det gjelder vel antagelig de aller fleste ansatte!). Dermed vil vi ha mange "NULL", dvs. manglende verdier for fremmednøkkelen avdelingsnr i Ansatt. Vi har dessuten ingen mulighet til å sjekke at hver avdeling virkelig har en avdelingsleder, noe som er en forutsetning ifølge modellen. Løsning 1 har dermed to svakheter. Begge disse svakhetene blir løst dersom man i stedet velger å legge inn ansattnr for avdelingslederen som fremmednøkkel i AVDELING24, slik:

Vi har her valgt å "døpe om" Ansattnr til Avdleders_ansnr, for dermed å gjøre det mer forståelig hva fremmednøkkelen gjelder.

231 praksis vil vi neppe ta sjansen på å tvinge gjennom en 1:1 -struktur i denne sammenhengen. Det er vel ikke utelukket at samme ansatt av og til blir satt til å lede flere avdelinger. Påstanden om at hver avdeling må ha en leder er vel muligens også tvilsom .... 24For å kontrollere at hver avdeling bare har en avdelingsleder måtte avdleders_ansnr være definert som unik, og i dette tilfelle også nødvendig. 1 noen slike 1:1 med minimum 1 på en side og minimum 0 på den andre siden, brukes fremmednøkkelen også som primærnøkkel, men det er neppe praktisk i dette tilfellet.

57

Kap. 5

REGLER FOR FREMMEDNØKLER

Dette mønsteret vi ser her bør brukes i alle situasjoner hvor vi har 1:1 med minimum 1 på den ene siden, minimum 0 på den andre siden.

Tilfelle 2:

Min. 0 på begge sider.

Vi sier altså her at endel avdelinger har en avdelingsleder (men i alle fall ikke mer enn en) og at en del ansatte kan lede en avdeling (men de kan i alle fall ikke lede mer enn en avdeling). Ansatt

er leder for

Ansnr

Avdeling

Avdelingsnr

De to mest nærliggende løsninger er: enten: Vi legger fremdeles fremmednøkkelen i AVDELING, fordi vi kan anta at det finnes flere ansatte enn avdelinger. Dette kan vi imidlertid ikke lese ut fra modellen, slik at vi ikke kan finne noen fast regel for slike tilfelle. I noen tilfelle kan det være umulig å vite hvilke det er flest av, som f.eks. når det gjelder MANN -KVINNE-relasjonstypen som vi har sett på tidligere. Ansatt

er leder for

Ansnr

Avdeling

Avdelingsnr

*Avdleders_ansnr

eller: Siden dette tilfellet er symmetrisk og vi i kap. 4 viste at det kunne foretas en entitetisering i denne situasjonen kan vi utføre dette også her: Ansatt

-j—|—04“ Ansnr

Avdelingsledelse

Avdeling

4-04—F ‘Ansnr

Avdelingsnr

‘Avdelingsnr

Vi har dermed forenklet dette tilfellet til forrrige tilfelle, og dermed kan vi for hver av relasjonstypene sette identifikatoren fra "min. 1-siden" som fremmednøkkel på "min. 0"-siden, slik vi allerede har gjort på figuren over.

Tilfelle 3:

Min. 1 på begge sider.

Som vi ser, er denne situasjonen så og si utenkelig. I praksis ville vi temmelig sikkert ha slått sammen disse to entitetstypene til en entitetstype. Også andre tilfelle hvor vi kan konstruere for 1:1 med minimum 1 på begge sider blir svært kunstige. Jeg har enda ikke truffet på noen som har hatt bruk for slike konstruksjoner!

To tenkbare, men ikke gode måter er beskrevet under. Detaljer på dette er utenfor rammen av boka, og er relativt uinteressante i praksis.

58

Kap. 5

REGLER FOR FREMMEDNØKLER

Oppsummering, l:l-relasjonstyper og fremmednøkler. Vi kan oppsummere 1:1 -tilfellene slik: Fremmednøkler for l:l-relasjonstyper: Tilfelle 1, min 0 på en side, min 1 på den andre: - Sett fremmednøkkelen på "min 0"-siden. Tilfelle 2, min 0 på begge sider: enten: reduksjon til tilfelle 1 ved entitetisering. eller: legg fremmednøkkelen på en av sidene (gjerne de som antas å få færrest forekomster i en evt. database) Tilfelle 3, min 1 på begge sider: enten: legg fremmednøkler på begge sider. eller: anta at det egentlig er tilfelle 1, programmér sjekk på min 1 på begge sider. eller: (det beste rådet) glem hele problematikken I

5.5.

Fremmednøkler som også er en del av identifikator.

En fremmednøkkel kan godt inngå som en del av identifikatoren (på mange-siden). Hvorvidt man velger en slik løsning eller ikke, vil være svært avgjørende for hvorledes modellen tolkes. Vi skal ta noen eksempler på dette:

Eksempel 1:

Ansatt har en sammensatt identifikator. Ansattnr er altså ikke entydig, slik at f.eks. ansattnr = 1 kan forekomme mange ganger, en for hver avdeling. Vi har altså omdefinert ansattnr til å være en "intern teller" innenfor hver avdeling. Dette er ikke en bra løsning, bl.a. fordi den ansatte må bytte identifikasjon dersom vedkommende bytter avdeling.

Eksempel 2:

59

Kap. 5

REGLER FOR FREMMEDNØKLER

Vi har enda ikke satt på identifikator for ordrelinje. Det finnes i alle fall 4 muligheter: 1)

2)

3) 4)

Bruk kombinasjonen Ordrenr, Varenr. Dette vil føre til at man ikke kan ha samme varenr mer enn en gang på samme ordre. 1 noen tilfelle er det ønskelig, i andre tilfelle vil man ønske å kunne sette opp samme varenr flere ganger på samme ordre (f.eks. fordi man har en struktur som sier ingen rabatt for første maskin solgt, 5% rabatt for neste osv.). Hvis kombinasjonen ordrenr/varenr kan forekomme flere ganger: legg en teller på antall ganger som denne kombinasjonen har forekommet, og la den være en del av identifikatoren. Denne løsningen er ikke spesielt heldig. & Pa for-trykte ordreformularer er det gjerne et linjenr for hver ordrelinje. Vi kan bruke et slikt linienr (posisjonsnummer) sammen med ordrenr som identifikator. Vi kan innføre et løpenummer for alle ordrelinjene (uavhengig av hvilke ordre de hører til) og bruke dette som eneste identifikator. Dette synes jeg blir et unødvendig kompliserende element.

hDvenr“njege 'ØSn'nSen ‘ °rdreSyStemer er forsla8 "r 3’ evt fors,a8

' hvis varenr må være forskjellig for

I forbindelse med entitetisering vil fremmednøklene fra begge sider som regel være et godt valg som identifikator, slik vi allerede har sett. Dette tilsvarer løsning I over. Imidlertid kan det være grunner til å gjøre det anneledes, eventuelt at vi ma gjøre det anneledes.

Eksempel 3: Nar fremmednøkkelen inngår som (som en del av) en identifikator kan den også "arves" i flere nivåer. For å vise prinsippet på en relativt stor grad av arv, tenker vi oss et utlånssystem for et bibliotek, hvor vi også ønsker hamed både historikk (hvilke bokeksemplarer har vært lånt av hvem), og mulighet for reservasjon av bøker (men reservasjonene slettes så fort du virkelig har fatt boka). J

Her er stort sett bare identifikatorer og fremmednøkler tatt med. Vi tar oss ikke tid til å forklare detaljer i denne modellen (mye skulle vel forøvrig være relativt selvforklarende).

60

REGLER FOR FREMMEDNØKLER

Kap. 5

Poenget med denne figuren er 1) å vise en relativt omfattende struktur når det gjelder "arv" av fremmednøkler, og at man må passe på at man bruker hele identifikatoren (på 1-siden) som fremmednøkkel (på mangesiden). Noen få unntak på dette finnes, se kap. 6.8. 2) å antyde at når man far relativt omfattende identifikatorer og/eller fremmednøkkelstrukturer, bør det vurderes å "bryte av" arven ved å innføre et løpenummer av et eller annet slag. Det kunne f.eks. være naturlig i innføre et løpenummer på utlånene. 3) å vise at det kan bli en omfattende oppgave å endre på strukturen hvis man f.eks. går over fra å bruke ISBN-nr til å bruke en annen klassifikasjon, eller man velger å ha en fortløpende teller på alle bokeksemplar som finnes i biblioteket.

Det finnes mange komplekse spørsmål innenfor dette området, som vi ikke kan ta opp her.

5.6.

Referanseintegritet.

I tillegg til å danne koblinger mellom sammenhørende verdier i to entitetstyper, sørger definisjon av fremmednøkler for at korresponderende data som finnes i en entitetstype også må finnes i den andre entitetstypen. Dette kalles referanseintegritet. Vi tar som vanlig utgangspunkt i AVDELING - ANSATT. AVDELING

ANSATT

Avdelingsnr 11 31 23

Ansattnr 453 987 781 991 721

Avdelingsnavn Økonomi Lager Produksjon

Ansattnavn Anne Hansen Ole Jensen Else Andersen Hans Johansen Tor Olsen

* Avdelingsnr 31 15 23

????

ingen avd.

23

Her er det ett, eller muligens to problemer med integriteten mellom tabellene. 1) Vi ser umiddelbart at ansatt med ansattnr 987 ikke kan jobbe i avdeling nr 15 - vi refererer jo ikke til en ikke-eksisterende avdeling ! 2) Er den nest siste linjen tillatt? Det kommer an på om avdelingsnr i ANSATT har Nødvendigegenskapen eller ikke.

61

Kap. 5

REGLER FOR FREMMEDNØKLER

Kravet om samsvar mellom verdier i fremmednøklen og identifikatoren hvor dataene "hentes fra" kalles for referanseintegritetskravet. Selv om det egentlig er noe feil ordbruk, vil vi kalle det attributtet(-gruppen) som fremmednøkkelen "kommer fra" for fremmednøkkelens eier. REFERANSEINTEGRITET: Enhver verdi i en fremmednøkkel må stemme overens med en verdi av identifikatoren i dens "eier". Dersom fremmednøkkelen er "ikke-Nødvendig", er det også tillatt at fremmednøkkelen ikke har noen verdi (er tom).

Når vi f.eks. lager en en-til-mange-relasjonstype, har vi dermed samtidig også definert at det skal være en referanseintegritet mellom de aktuelle entitetstyper. Vår påstand er at dette er vel så viktig som akkurat om hvor det er en og hvor det er mange. Men som sagt: samtidig som vi bestemmer hvordan relasjonstypen skal være, bestemmer vi også referanseintegriteten.

Av og til tegner vi opp en relasjonstype uten at vi oppgir kardinalitet, og dermed heller ikke referanseintegritet Dette betyr b • enten at vi ikke har bestemt oss enda • eller at vi vil vise at verdiene to attributter ofte er de samme, uten at de alltid er det. Vi snakker at om en ubestemt relasjonstype, og tegner det opp bare en enkel strek mellom entitetstypene. Noen databasesystemer, f.eks. Microsoft Access har muligheten for å danne slike ubestemte relasjonstyper - rett og slett ved å ikke oppgi at man skal ha referanseintegritet.

Ubestemt relasjonstype - uten referanseintegritet.

t er vikt g å være klar over at referanseintegritet også må gjelde ved sletting og endring. Man kan ikke slette f.eks. avdeling nr. 23 uten at det gjøres noe med den/de ansatte i den avdelingen. Det finnes flere standardiserte måter å håndtere dette på: • ingen endring/sletting: data som kan "eie" andre data, kan ikke slettes eller endres. betinget sletting/endrmg: data i "eier" slettes/endres bare hvis den ikke har noen relaterte data Dette kalles RESTRICT, evt. NO ACTION. • kaskadeendring/sletting: dersom data i “eier" slettes/endres, så slettes/endres også alle relaterte data. Hvis remmednøkkelen igjen er del av idetifikator, vil dette kunne føre til videre sletting/endring, som igjen kan føre til ... Dette kalles CASCADE. nullstilling: hvis data i "eier" slettes eller endres slik at fremmednøkkelen ikke lenger har noen tilsvarende eier , settes fremmednøkkelen til NULL, dvs. til "ingen verdi". Dette forutsetter at fremmednøkkelen ikke er nødvendig (jfr. kap. 3.3.2). Dette kalles SET NULL eller NULLIFY De engelske betegnelsene er de som brukes i SQL, standarden for databasespråk.

Mange av oss opplever problemer med referanseintegritet opptil mange ganger daglig. Det er ikke noe annet enn det som skjer på webben når en peker henviser til en ikke-eksisterende side: 404 Not Found

The requested URL

was not found on this server.

For den saks skyld har Tekst-TV-sider av og til de samme problemene fra en oversikts/henvisnings-side til en side som inneholder mer informasjon om et tema. Av og til har de stokket nummerne på sidehenvisningene....

62

Kap. 5

5.7.

REGLER FOR FREMMEDNØKLER

Fremmednøkler i Modelator.

Som nevnt i innledningen av dette kapittelet, er det forskjellige meninger hvorvidt datamodeller skal inneholde fremmednøkler eller ikke, og i tilfelle når man skal begynne å ta disse med.

I Modelator versjon 3 hadde man to modi, enten at fremmednøkler overhodet ikke ble laget, eller fremmed­ nøkler ble laget automatisk, og endret etterhvert som man endrer modellen. Dersom identifikator ikke var definert på "primær"-siden, ble det laget en "foreløpig fremmednøkkel" som ble brukt for å markere at det ville komme en "ordentlig fremmednøkkel" siden. For versjon 4 er dette endret til systemet lager fremmednøkler etter reglene over så fort det er definert identifikator på "primær"-siden. I praksis betyr det at de som arbeider mest på et overordnet nivå - og dermed gjeme kutter ut identifikator etc. - ikke får med fremmednøkler heller, mens de som lager en detaljert modell tar med identifikatorer og dermed også fremmednøkler.

Implementerte regler for håndtering av fremmednøkler. De ulike kategorier av relasjonstyper behandles ut fra teorien tidligere i kapittelet: • l:m trenger ikke mer kommentarer. • m:m Vi må i tilfelle foreta en entitetisering (se kap. 4), og fremmednøklene vil komme automatisk i den "koblende" entitetstypen. Kombinasjonen av dem vil også markeres som identifikator. I noen tilfelle bør dette endres fordi det er en mer komplisert struktur. • 1:1 med minimum 1 på en side og minimum 0 på den andre siden hånderes tilsvarende som 1 :m. • 1:1 med minimum 0 på begge sider er derimot mer komplisert, fordi den i likhet med m:m er symmetrisk, slik at valget av fremmednøkkelside er vilkårlig. Når en ny relasjonstype lages, har man derfor valgt at "fra"-siden er primær-siden, mens "til"siden er fremmednøkkelsiden. Dette kan imidlertid byttes om på når som helst. Alternativt kan man foreta en entitetisering, jfr. tidligere i kapittelet. Vi får dermed en reduksjon til forrige tilfelle. • 1:1 med minimum 1 på begge sider behandles som forrige tilfelle, bortsett fra at entitetisering ikke er aktuelt. Systemet håndterer også alle andre endringer som er en følge av at identifikator eller relasjonstypen endres. Dette gjelder bl.a. at • dersom fremmednøkler inngår i identifikatoren, vi! denne kunne arves videre, og nødvendig i flere nivåer. Endringer i en identifikator vil dermed kunne få konsekvenser for flere nivåer. • dersom en identifikator gjøres om fra å være enkelt identifikator til å være sammensatt, vil alle "tilhørende" fremmednøkler bli endret tilsvarende, om nødvendig i flere nivåer. Dette gjelder selvsagt også dersom enda flere attributter inngår i identifikatoren. Tilsvarende fjernes fremmednøkler dersom man tar bort ett eller flere attributter fra identifikatoren, evt. fjernes helt hvis siste del av identifikatoren tas bort. • når en fremmednøkkel opprettes, vil den få samme navn som dens "eier", men dette kan endres senere. • dersom en identifikator endrer navn, vil dens underliggende fremmednøkler også endre navn. Endringen gjelder kun "nedover" i fremmednøkkelstrukturen, ikke oppover. • hvis relasjonstypen endres, f.eks. at 1 :m byttes om, vil systemet endre fremmednøkler ut fra dette. • en identifikator kan ikke være sin "egen fremmednøkkel", verken direkte eller indirekte. Sagt med andre ord: vi tillater ikke ikke sirkularitet av fremmednøkler. • det sørges for konsistens mellom Nødvendig-egenskapen og "minimum på motsatt side", jfr. kap. 5.2. I praksis betyr dette at det er en kaskade innsetting/endring/sletting, på samme måte som for "vanlige" data (jfr. kap.5.6).

Det gjøres også en rekke andre sjekker etc., f.eks. at en fremmednøkkel ikke kan "gå i sirkel". Kort sagt vil systemet vedlikeholde fremmednøkkelstrukturen automatisk, samme hva du gjør av endringer i modellen. Praktisk erfaring har vist at muligheten for automatisk generering og endring av fremmednøkler er svært nyttig, spesielt i større prosjekter.

63

Kap. 6

MER KOMPLISERTE STRUKTURER

6. Mer kompliserte strukturer Vi skal I her ta for oss en del mer kompliserte strukturer som er vanlige å se i datamodeller. Nesten alle struk­ turene er vist med et eksempel. Som nevnt i innledningen er det viktigste at du ser det generelle i disse strukturene, slik at du "har tegningene i hodet" og har forslag til hvorledes tilsvarende problemer skal modelleres Først imidlertid en generell advarsel ved tegning av mer kompliserte modeller.

6.1.

Mist ikke tråden !

I mange modeller er det viktig at man følger en verdi eller et bestemt verdisett gjennom flere entitetstyper slik at disse senere kan kobles på en entydig måte. Det er derfor viktig at modellen ikke gjør at du mister denne muligheten. Spørsmålet er: hvor kompleks kan en modell være uten at man mister en slik sammenheng? I den vanlige ordremodellen kan vi for en gitt kunde finne nøyaktig hvilke varer vedkommende har bestilt selv om vi må gå hele stien Kunde - Ordre - Ordrelinje - Vare. Om vi hadde en og bare en varegruppe for en gitt vare, ville vi også da "beholde tråden". Derimot gir følgende modell problemer dersom man skal forsøke å finne ut hvilke kontaktpersoner som har plassert de forskjellige ordrene:

Kunde Knr 100 r loi

Knavn Fisk & Vilt a.s. Andre varer a.s.

Kunde kontakt

Knr 100 100

KKnavn Dal Ole Bø Anne

Ordre

Ordrenr 1

Ordredato 12.07.98 12.07.98

Et forsøk på å begynne i Ordre og gå via Kunde til Kundekontakt ville gitt alle kombinasjoner av kontaktpersoner og ordrer for den aktuelle kunden - m.a.o. en alle-til-alle-kobling (jfr kap 6 6) Vi har altså "mistet tråden". Problemet kan illustreres ved at man tenker på de enkelte forekomster av attributtene (dvs konkrete dataverdier) som noder. AB

a) b)

64

B

BC

C

én verdi i A kobles til én bestemt (evt. flere bestemte) verdier i C. én verdi i A kobles med alle verdiene i C som har den gitte verdien i B.

Knr 100 100

Kap. 6

MER KOMPLISERTE STRUKTURER

En sammenligning av disse to tilfellene viser oss følgende regel:

For å "beholde tråden" gjennom flere relasjonstyper i en datamodell, er maksimal kompleksitet: • først et vilkårlig antall (O..m) relasjonstyper i mange-retning • deretter et vilkårlig antall (O..m) relasjonstyper i 1-retning.

b) "mister tråden"

a) "beholder tråden"

I a) er det ingen problemer med å følge tråden fra A til H og motsatt i modellen under, og dermed heller ikke problemer med å følge en de! av denne, f.eks. fra D til G. 1 b) derimot mister man tråden, fordi man "går gjennom en 1-er" for deretter å "gå til mange" igjen.

Denne fellen er så vanlig å gå i at den har fått sitt eget navn, nemlig "the connection trap", sammenkoblingsfellen.

6.2.

Nullverdier i attributter og mulige konsekvenser for datamodellen

Vi tok opp Nødvendig-egenskapen, NULL og NOT NULL i kap. 3.3.1. Vi antydet også at Nødvendigegenskapen kan ha konsekvenser for utforming av datamodellen. I prinsippet kan enhvert ikke-identfikatorattributt skilles ut i en egen entitetstype sammen med sin identifikator. I figuren viser vi informasjon om personer som bor i Norge, både de som er født her og de som har bor her men kommer fra et annet land.

Person

Personid Personnavn

Adresse Person!

Telefonnr

Opprinnelsesland

A r f ø rste g a n g J N o rg e

Personid

Navn

Adr

Telefon

Opprinnelse

Til_Norge

*Personid

*Personid

*Personid

*Personid

Personnavn

Adresse

Telefonnr

Opprinnelsesland

*Personid År første gang i Norge

65

Kap. 6

MER KOMPLISERTE STRUKTURER

Strengt tatt kunne også Personl vært tatt bort. Strukturen er imidlertid ikke særlig god. Vi skal ta punkt for punkt: H • Navn og Adr bør uansett ikke splittes ut - det blir uansett iike mange forekomster i Person 1 Navn oe Adr (jfr. også regler i kap. 3.7). ’ 5 • Telefon kan splittes ut, vi får dermed visualisert at Telefonnr kan fylles ut, men at det er et ikke-Nødvendig attributt. Siden de fleste har telefon, og det er et enkelt attributt, er det liten grunn til å splitte det ut. Hvis Opprinnelse (Opprinnelsesland og År_første_gang_i_Norge ) bare er fy Ilt ut for relativt fa entiteter (forekomster), kan det være grunn til å splitte disse ut. Det er imidlertid naturlig å anta at disse "henger sammen", på den måten at enten begge eller ingen av dem er fyllt ut for en gitt forekomst. Hvis vi ønsker at modellen skal reflektere dette, kan vi splitte dem ut i en felles entitetstype, slik:

Sett Nødvendig på begge.

Altså: Enten må Opprinnelsesland og Årjørst^gang_i_Norge begge fylles ut, eller så er ingen av dem fyllt ut tor en gitt persomd. Om man bryr seg med å implementere en slik skranke, og om den i tilfelle gjøres via datamodellen, som her, eller om den gjøres prosydurelt, f.eks.via f.eks. en trigger i databasen, er opp til den enkelte databasedesigner. I problemstillinger av denne typen snakker vi ofte om sterk eller svak gruppering: sterk gruppering vil si at vi samler sammen mest mulig i en entitetstype", mens vi ved svak gruppering skiller ut verdier som kan ha nullverdier. Det bør også sies at en slik design avhenger av situasjonen: Dersom dette modellerte et system for Utlendings­ direktoratet, ville antagelig de to aktuelle attributtene begge vært Nødvendig, slik at det ville vært naturlig å hatt dem sammen med Person. 6

6.3.

En hovedaktør, flere medaktører

Prinsippet En svært vanlig struktur er at vi har en m:m-situasjon, men at en av de som er knyttet opp er spesiell, nåværende, hoved el.l. Det kan være nesten hva som helst, og dermed det litt generelle ordet aktør.

Et eksempel: Anta at man i et ordresystem har ulike varer, og at en vare kan ha mange mulige leverandører men —r-e en hovedleverandør. Dette skal reflekteres i modellen. Et par mulige måter å gjøre dette på, er:

hovedleverandør Vare

a) foretrukket

66

-f- Leverandør

b)

ikke foretrukket

Kap. 6

MER KOMPLISERTE STRUKTURER

I a) skiller vi mellom hovedleverandøren og andre mulige leverandører, og dette vises tydelig i modellen. I b) bruker vi et attributt Hoved? som kan tenkes å ha verdien Ja eller Nei (Sant eller Usant). Problemet med denne strukturen er imidlertid at den tillater at det settes Ja for flere Vare/Leverandør-kombinasjoner, m.a.o. at strukturen ikke kan påtvinge at hver vare bare har en hovedleverandør. Det ville vært direkte feil å lage en egen entitetstype "Hovedleverandør" el.l. Hovedleverandøren er en vanlig leverandør, men har bare en spesiell rolle i forhold til en vare.

En slik situasjon med vilkårlig mange, samtidig som en er "hoved", er temmelig vanlig, f.eks. • en person har mange interesser, men bare en hovedinteresse • hver person kan delta i flere prosjekter og et prosjekt kan ha mange prosjektdeltagere, men bare en person er leder for prosjektet • for et telefonnummer er det (maksimum) en hovedoppføring i telefonkatalogen (den som betaler), men det kan finnes mange tilleggsoppføringer på samme nummer. • mange foreninger (f.eks. Den Norske Dataforening) opererer med at et firmamedlemsskap omfatter et hovedmedlem og et antall (min. 0 max. mange) tilleggsmedlemmer. • i det nye båtregisteret (for småbåter) registreres hver båt med én hovedeier og et vilkårlig antall medeiere.

Bruk i forbindelse med historikk.

En nesten tilsvarende situasjon har man i når det er behov for å ha med historikk: En person har til enhver tid bare en stillingstype, men kan over tid ha hatt andre stillingstyper, Vi vil vite både nåværende og tidligere stillingstyper. 1 praksis vil vi også vite fra- og eventuelt til-dato for når vedkommende hadde de ulike stillingstypene.

Noen kommentarer til denne strukturen: • Siden en person kan ha en stillingstype, så en annen og så komme tilbake til samme igjen, kan ikke kombinasjonen av stillingskode og ansattnr brukes som identifikator. • Vi må ta vare på når personen begynte i den stillingen han/hun nå har (Stilling_fradato). Hvis personen bytter stillingstype, tas Stilling fradato ned i stillingsperiode. • Hvis man synes dette blir mye jobb å håndtere, kan man eventuelt kutte ut 1 :m-delen, og slik at stillingsperiode også inneholder nåværerende. I tilfelle må Tildato være et "ikke-Nødvendig" attributt (se kap. 3.3.2) - tildatoen fylles ikke ut for nåværende stillingsperiode. Dersom man skal sikre at hver person kun har en stillingstype for øyeblikket, må det kontrolleres at kun en verdi av tildato i Stillingsperiode er NULL for hver ansatt. • Ofte må nåværende stillingsperiode uansatt tas med i stillingsperiode, f.eks. fordi stillingsperiode er relatert til andre entitetstyper. Her kunne man f.eks. tenke seg at man for hver stillingsperiode ville vite hvilke hvilke oppdrag vedkommende hadde tatt på seg.

67

MER KOMPLISERTE STRUKTURER

Kap. 6

Kontroll av dataverdier - noen varianter.

6.4.

6.4.1. Grad av kontroll mot lovlige verdier. Kontroll av lovlige verdier.

Når det skal lages et system er det viktig å tenke gjennom graden av kontroll av samsvarende dataverdier Vi tenker oss et kundesystem med kunder fra ulike land. Skal vi kontrollere at samme land alltid skrives likt eller skal vi tillate at vi skriver Holland, Nederland og The Nederlands om hverandre? (Jfr. kap. 2.2.) Datamodellen vil se forskjellig ut avhengig av hvilket valg vi gjør i så måte:

Land

Land

Land

Landsn.avn

Landsn,avn

Landsns vn

•*

Kunde

Kunde

Kundenr

Kundenr

Kundenr

Kundenr

Landsnavn

‘Landsnavn

‘Landsnavn

Landsnavn

Kunde

a) a) b) c) d)

b)

Kunde

c)

Ingen kontroll - skriv hva du vil som landsnavn. Du kan kun oppgi de lovlige landsnavnene som finnes i Land Du kan oppgi et lovlig landsnavn eller intet navn (= Norge??) Ingen kontroll, men du bør sjekke om landsnavnet finnes fra før (Streken viser en ubestemt relasjonstype, se kap. 5.6)

d)

Ingen kontroll. Tvungen kontroll Frivillig kontroll

Av og til spiller det ingen stor rolle om man bruker forskjellige betegnelser på det samme, men en slik standardisering er ofte nødvendig, bl.a. dersom vi skal lage statistikk. Hvis det noen ganger sto Nederland an re ganger Holland eller andre kombinasjoner, ville naturligvis en statistikk over antall kunder pr land bli feil. Om ikke annet er en slik metodikk svært nyttig for å hindre skrivefeil. I et system vil gjeme slike ontiollverdier finnes i en komboboks, slik at man bare velger mellom et sett med lovlige verdier, se under.

I virkelige systemer finnes det ofte mange kontrollerende entitetstyper rundt en sentral entitetstype, f.eks. slik:

Kap. 6

MER KOMPLISERTE STRUKTURER

Eksempelet viser bare et lite, men typisk utvalg av slike. I databaser blir de tilsvarende tabellene gjeme kalt kodetabeller. Noen ganger inneholder de en kode sammen med en beskrivelse, i andre tilfelle inneholder de bare selve verdien (slik som landsnavn over)25.

Standardverdier på mange-siden, regel og unntak. På mange-siden av en relasjonstype vil man ofte ha standardverdier som kan overskrives. Det danner dermed et struktur med regel og unntak. Det finnes flere måter å håndtere dette på. For et gitt kundenr er det gjeme samme kundenavn, adresse, kontaktperson osv. hver gang, men det kan av og til være ønskelig med en et annet navn, kontaktperson osv. Et ordresystem er igjen typisk:

a) Standardverdier som kan endres (unntak)

b) Unntaksverdier lagres spesielt.

Om valg a): Dette er tilsynelatende en dårlig struktur (dårlig normalisering, se kap. 7). Tenk deg imidlertid at kundenr 3141 ringer og vil plassere en ordre, men at det er en annen kontaktperson og/eller en annen adresse enn vanlig. Dette bør være tillatt uten at man med det sier at det må lagres en helt ny kunde. I praksis er slike systemer laget slik at man ved en ny ordre henter ned "standardverdiene" fra kunde, men at de kan endres og derfor må lagres i ordren. Ofte opererer slike systemer med mange ulike adresser (til kontaktpersoner, faktureringsadresse(r)) etc.

Om valg b): Dersom vi har en annen verdi enn den som finnes i Kunde legges denne i Unntaksordre. Dette hindrer lagring av redundante data i ordren dersom det er standardverdier som brukes. På den annen side gir dette mer komplisert behandlingslogikk: For å skrive ut ordrens kontaktperson må man først sjekke om ordrenummeret finnes i Unntaks ordre. I så tilfelle skrives det ut derfra, ellers hentes det fra Kunde. I praksis er derfor a) enklere, selv om det gir lagring av mere data.

Standardverdier med unntak i flere nivåer. Det hender at standardverdier arves i flere nivåer. Igjen et eksempel fra kunder og ordrer:

25 Slike kontrollverdier er egentlig et eksempel på det vi tidligere har kalt for domener (dvs. verdiområder) for et attributt. Hvis man bare har noen få aktuelle verdier, og disse verdiene er helt faste, har noen utviklingsverktøy mulighet for enten eksplisitt å danne et domene, eller at man kan oppgi hvilke verdier som er tillatt. Imidlertid: dersom disse verdiene skal kunne endres, f.eks. fordi det er behov for å legge inn nye verdier, så vil man måtte endre selve datastrukturen. Dersom disse dataene i stedet legges til slike "kontrollentitetstyper", vil man kunne endre settet av tillatte verdier ved ganske enkelt å endre data i dem.

69

Kap. 6

MER KOMPLISERTE STRUKTURER

Kundegruppe

Gruppekode

Rabattprosent

Kunde

Kundenr ‘Gruppekode

Rabattprosent

Ordre

Vare

Ordenr

Varenr

‘Kundenr

Rabattprosent

Ordrelinje

Pris Rabattprosent

‘Ordenr

‘Varenr Rabattprosent

En kunde opprettes med den rabattprosenten som gjelder sin kundegruppe. Denne prosenten kan imidlertid overskrives for en bestemt kunde. Tilsvarende kan en gitt ordre få en annen rabattprosent enn den som er vanlig for kunden, og en bestemt ordrelinje kan fa en bestemt rabattprosent ("OK, siden du kjøpte over 1000 tannbørster så skal du få en bedre rabatt på disse"). Tilsvarende kan det settes en rabattprosent på en vare, f.eks. i en gitt tid. Endelig: hva hvis både varen og ordren har en rabatt? Skal den beste gjelde? Beregnes ut fra en formel? Settes det manuelt?

Hvis ulike standardverdier er tillatt. Vi tenker oss at ordresystemet skal inneholde muligheter for at ordrer skal kunne plasseres av flere personer, men bare et bestemt sett av personer, nemlig de som vi har registrert som kundekontakter. Disse kundekontaktene ville blitt repeterende i kunde, slik at de må ut i en egen entitetstype. Modellen kan da bli f.eks. slik:

Vi antar her at kontaktpersonnavn er entydig innenfor en gitt kunde, men ikke nødvendigvis innenfor alle kunder. Det virker det fristende å legge inn en direkte relasjonstype mellom Kunde og Ordre, men strengt tatt er ikke dette nødvendig. Hvis det ikke er noen bestemt person, kan man likevel definere en kontaktperson som heter generell el.L, slik at også dette tilfellet er dekket. Vanskeligere problemer av denne typen er behandlet i forbindelse med ekvivalente stier, se kap. 6.8.

70

MER KOMPLISERTE STRUKTURER

Kap. 6

6.4.2. Kobling av samme entitetstype mot ulike nivåer. Et lignende tilfelle som over har vi dersom vi skal kunne koble verdier opp mot forskjellige nivåer.

Eksempel 1.

Saker som behandles (f.eks. i det offentlige) har som regel en bestemt saksbehandler, men noen ganger betraktes selve avdelingen som saksbehandler, uten at det knyttes til en bestemt person.

Avdeling

Avdeling

Avdelingsnr

Avdelingsnr

Ansatt

Lager en "generell ansatt" for hver avdeling

Ansatt

Ansattnr

Ansattnr

Ansattnavn

Ansattnavn

‘Avdelingsnr

Sak

‘Avdelingsnr

Saknr

‘Avdelingsnr ‘Ansattnr

a)

enten-eller

b) bruker en kunstig forekomst for å fa enkel struktur.

Løsning a) : Modellen i a) under løser for så vidt dette problemet, men det må da passes på at man i Sak enten fyller inn Avdelingsnr eller Ansattnr, ikke begge delene - derfor minimum 0 på begge relasjonstypene fra Sak. Selvsagt kunne man også ha saker med en bestemt saksbehandlere ha fy Ilt inn begge attributtene, men man måtte da kontrollere at avdelingsnr i sak var det samme som avdelingsnummeret for den ansatte som arbeidet med saken. I så tilfelle blir det et eksempel på det som kalles "ekvivalente stier", se kap. 6.8. Løsning b): En mulig annen løsning er antydet i b), hvor alle saker er tilsynelatende er koblet til en ansatt, men hvor hver avdeling har fatt sin ekstra "kvasiansatte", f.eks. alle med navn "Generelt". 1 dette tilfelle kan det synes som en lite heldig løsning, men i andre tilfelle er dette en svært naturlig måte å gjøre det på.

Eksempel 2

En variant av dette har vi hvis fremmednøkkelen i "mellomentitetstypen" også er en del av identifikator for denne. En slik situasjon kan f.eks. være fra et arbeidskontor hvor jobbene som finnes er kategorisert med en hovedkategori og underkategori. De fleste jobbene som tilbys er kategorisert via underkategorien, men det er også noen som kun er kategorisert på hovedkategori.

71

Kap. 6

MER KOMPLISERTE STRUKTURER

Legg merke til at Hkatkode er i a) fremmednøkkel både til Hovedkategori og Underkategori. Mulighet a) ser tilsynelatende grei ut, og er grei hvis du kan velge mellom å registrere koder på jobben eller ikke registrere noen kode i det hele tatt. Derimot er den ubrukelig dersom du ønsker å kunne registrere bare hovedkategori. Argumentasjonen er: • du ønsker å legge inn Hkatkode i Ledigjobb. • Referanseintegritetsregelen (se kap. 5.2) sier at enten må hele fremmednøkkelen være NULL, eller så må den matche med sin eier". For relasjonstypen fra Ledigjobb til Underkategori betyr dette at da må (Hkatkode,Ukatkodej-kombinasjonen matche med en lovlig underkategori. • Men siden (Hkatkode,Ukatkodej-kombinasjonen er identifikator i Underkategori, må den ifølge entitetsintegritetsregelen (kap. 3.3.2) fylles ut. • For å "matche" en lovlig Underkategori må dermed både Hkatkode og Ukatkode ha en verdi i Ledigjobb. Konklusjonen er altså at dersom man alltid vil at Hkatkode i Ledigjobb skal ha en verdi, så må Ukatkode også ha en verdi. Dermed vil vi få minimum 1 fra Ledigjobb til Underkategori, og relasjonstypen fra Ledig jobb til Hovedkategori er unødvendig. Vi velger altså b). Hva så med det opprinnelige ønsket om at noen jobber ble kategorisert bare på hovedkategi? Det finnes to måter å gjøre dette på: • enten: du må legge inn f.eks. ukatkode = 0 i Underkategori for hver hovedkategori (for eksempel kalt Generelt), slik at de som bare er klassifisert på hovedkategori er definert på med ukatkode 0. Dette er en vanlig løsning (og som er valgt f.eks. i oversikter over ledige jobber på arbeidskontoret). Dette gjør det også enklere f.eks. å telle opp antall jobber i hver hovedkategori. • eller: du må lage en annen identifikator i Underkategori. I så tilfelle er du tilbake til eksemplet med Avdeling - Ansatt - Sak over.

6.4.3. Kontroll av datakombinasjoner i to eller flere dimensjoner. Hva gjør man dersom man ikke kan velge mellom faste data, men at det er kombinasjoner av data fra to forskjellige "ting" som er lovlig?

Eksempel 1: Kontroll er nødvendig. Vi tenker oss et system hvor et større firma har lager mange steder, og at de ulike lagrene har ulike varer. Ved registrering av et vareuttak må man passe på at vareuttaket gjøres fra et lager som virkelig har den aktuelle varen.

72

Kap. 6

MER KOMPLISERTE STRUKTURER

I a) kan man notere uttak fra lagre som ikke har den aktuelle varen, mens dette er forhindret i b). I praksis vil m:m-forholdet i a) over entitetiseres, bl.a. fordi man må vite antall av hver vare på hvert lager.

Eksempel 2: Kontroll av kombinasjoner kan diskuteres. I andre tilfelle er det spørsmål om unntak skal tillates eller ikke. Et eksempel: Lærere i videregående skole har kompetanse til å undervise et eller flere fag (gjerne to eller tre fag). Skal de tillates å undervise i andre fag enn det de har kompetanse til?

a)

Kan undervise i alle fag

b) Kan bare undervise i fag du har kompetanse i

Situasjonen er som i forrige eksempel, bortsett fra at vi også i a) har entitetisert m:m-relasjonstypen fordi vi var interessert i å vite hvilket nivå (grunnfag, mellomfag eller hovedfag) for hvert av fagene som læreren hadde kompetanse i. Vi ser at a) tillater at læreren kan undervise i vilkårlige fag, også uten at han/hun har kompetanse i det, mens b) krever at læreren har kompetanse i faget som han/hun skal undervise i. Modellen kunne også ha inneholdt en Lovlignivå-entitetstype som kontrollerte de lovlige verdiene for Nivå (f.eks. at det var en av kodene G = grunnfag, M = mellomfag eller H = hovedfag). Hvilken modell som er riktig, avhenger naturligvis av hvilke regler man ønsker at systemet skal kunne håndtere. Det viktige er at du som datamodellkyndig er klar over slike muligheter og strukturer, og spør de riktige spørsmålene for å få klargjort dette. Spørsmålet er altså om alle kombinasjoner av de overordnede entitetstypene kan tillates (her Lærer og Fag) m.a.o. om de er uavhengig av hverandre, eller om det bare er visse kombinasjoner av disse som er tillatt. Skoleverket tillater (dessverre vil noen si) at man kan undervise i fag man ikke har kompetanse i, altså situasjon a).

73

Kap. 6

MER KOMPLISERTE STRUKTURER

Eksempel 3: Henting av standardverdier og mindre grad av kontroll. Ogsa i slike tilfelle kan man kombinere henting av standardverdier og en noe mindre grad av kontroll Vi skal ha med postnummer. De aller fleste kunder er norske, men vi har også noen utenlandske kunder.

a)

b) c)

er ubrukelig dersom det bare er norske postnummer i Post. Man kunne selvsagt lagt inn f.eks. S-43000 Gbteborg i Post, men vi kunne ikke sjekke at dette stemte med at landsnavnet som ble lagt inn var Sverige. gjør at man registrerer alle lovlige postnr/landsnavn (evt. koder) i Post forjand. Dette er mulig, men virker kanskje noe omfattende dersom de aller fleste kundene er norske. her kunne vi tenke oss at når et postnr skrives inn i kunde og land er Norge, så hentes det tilsvarende poststedet fra Post. I motsatt fall skrives dette inn manuelt. Dette vil ikke gi noen fullgod kontroll, men kan kanskje være en mellomting som vil fungere brukbart likevel. Vi har i dette tilfelle det som tid­ ligere er kalt en ubestemt relasjonstype, markert med en enkelt strek mellom entitetstypene, se kap. 5.6

Eksempel 4: Kontroll med kombinasjoner av tre dimensjoner.

Et eksempel på en struktur hvor det er en kontroll i tre dimensjoner: Vi tenker oss noen svært populære kurs (f.eks. Kursnr 101, Felles opplegg for bilførerprøven, kursnr 102 Felles opplegg for båtførerprøven), som er helt standardisert og avholdes en rekke steder i landet, f.eks. av en friundervismngsinstitusjon. Det er imidlertid ikke slik at hvert kurs kjøres hver måned alle steder, så vi trenger å vite hvilke kurs som går hvilke steder hvilke måneder. Det er en felles påmeldingstelefon (800-nummer), uavhengig av hvor i landet du ønsker å gå.

74

Kap. 6

MER KOMPLISERTE STRUKTURER

Hvis kursavholdelse hadde vært sløyfet og kursdeltagelse hadde vært knyttet opp direkte mot Kurs, Sted og Måned, kunne man ha registrert deltagere et kurs som ikke gikk den bestemte måneden på det bestemte stedet. To små kommentarer til dette eksempelet: • Det finnes andre grunner til at vi trenger en slik kursavholdelse. • Det kunne vært lurt å lage en ny identifikator (f.eks. et løpenummer) for hver ny kursavholdelse.

Eksempel 5:

Omgjøring av prosydurell tenkning til dataorientert tenkning.

Kombinasjoner av dataverdier kan også brukes til å modellere andre situasjoner som vi ofte tenker på som prosydurelle, dvs. at man må foreskrive hvorledes behandlingen skal skje, f.eks. i form av løkker og valg i et programmeringsspråk. Vi skal ta et eksempel: Momsprosenten i Norge var 20% t.o.m. 1991, 22% f.o.m. 1992 t.o.m. 1995, deretter har den vært 23%, men det kan godt hende den endres igjen. Hvis vi skulle ha et system som ga riktig momsprosent for hvert år fra 1990, tenker vi nesten automatisk på en rekke hvis-setninger, altså en del av en prosedyre el.l., se a) under, men det kan også tenkes en annen løsning, se b): 20 1990 20 1991 if aar < 1992 then momsprosent := 20 1992 22 else 1993 22 if aar < 1995 then momsprosent := 22 1994 22 else 1995 23 momsprosent := 23; 1996 23 .......

a) eksempel på løsning via kode

b) løsning via data

Fordelen med b) er selvsagt at disse nye data kan legges inn uten at en behøver å endre i programkoden. En løsning hvor bare første årstall med endret moms settes inn er også mulig. Vi ville i tilfelle registere momsprosenter for 1990, 1992 og 1995.

75

Kap. 6

MER KOMPLISERTE STRUKTURER

Eksempel 6:

Kontroll i flere dimensjoner brukt for å kontrollere antall i hver gruppe.

Kontroll av dataverdier i flere dimensjoner kan også brukes der hvor man skal kontrollere at "noe" ikke har mer enn et bestemt antall av "noe annet". Vi tenker oss en problemstilling med at studenter skal deles i grupper, hvor hver gruppe kan ha maksimalt 5 deltagere. Hver deltager kan delta i bare en gruppe. Problemet er selvsagt å kontrollere at det er maksimalt 5 i hver. Et første forsøk vises i a), men denne er uheldig av mange grunner.

Max. antall i gruppe - håpløs løsning

Ved bruk av en fremmednøkkelkombinasjon som identifikator kan vi tvinge systemet til å godta maksimalt 5 studenter pr. gruppe. Siden hver student bare kan ha én gruppedeltagelse (se modellen), får vi også dette kravet innfridd. I praksis betyr dette at studnr i Gruppedeltagelse er unik. Vi kan velge å slå sammen Student og Gruppedeltagelse til Student men det synes kanskje mindre naturlig. Det er vel naturlig at Student i tilfelle inneholder mange andre opplysninger, og at gruppenr og og teller_innen_gruppen er noe som legges til senere, derfor minimum 0 opp mot Gruppe og Antalls_kontroll. (Gruppenr,TellerJnnen_gruppe) bør i tilfelle deklareres som unik. For en gitt Gruppenr,Tellerjnnen_gruppe i Student må enten begge være fyllt ut, eller ingen være fyllt ut, og vi har dermed den situasjonen hvor vi tidligere anbefalte å vurdere utsplitting av et 1:1 -forhold, se kap. 6.2, "Nullverdier i attributter og mulige konsekvenser for datamodellen".

Mindre anbefalt løsning i dette tilfelle.

76

Kap. 6

MER KOMPLISERTE STRUKTURER

Maskering av data via status-attributter.

Vi avslutter med en problemstilling som ligger litt på siden av hovedtemaet, men hvor man også i de fleste tilfelle bruker kontroll mot bestemte verdier.

Veldedighetsorganiasjoner har gjerne store databaser over givere og hvilke gaver de har gitt:

Ofte ringer personer til organiasjonen og sier at han/hun vil slettes fra systemet. Problemet er bare at dersom vedkommende slettes, så slettes også gaven26. Dessuten kan det være greit å ha også passive personer liggende i systemet. Hvis man kjøper adresser kan man f.eks. sjekke at man ikke legger inn som aktiv den samme personen som har bedt om å bli slettet. Løsningen på slike problemer er å opprette en statuskode, med mulige verdier Aktiv, Passiv, Avdød etc. I skjermbilder for denne databasen sørger man så for å vise bare de som har kode Aktiv27. Alternativt kan maskering skje ved å lage et såkalt utsnitt (view) i et databasesystem, f.eks. via SQL-setningen CREATE VIEW........

Kundesystemer, personalsystemer etc. fungerer gjerne også på samme måte. Dette har selvsagt også den fordelen at hvis man en kunde, ansatt el.l. slutter, men senere kommer tilbake, så finnes gamle data der allerede.

6.5.

Hierarki og nettverk.

6.5.1. Hierarki. Problemet er: hvordan beskriver man data som i sin natur er hierarkiske? Det er her snakk om to tilfeller, enten med et bestemt antall nivåer, eller med et vilkårlig antall nivåer og (nogenlunde) like attributter på hvert nivå.

Hierarkier med et fast antall nivåer. Vi tenker oss et enkelt eksempel hvor et firma har avdelinger, underavdelinger, og under underavdelinger.

26 Forutsatt at personid ikke er del av identifikator for gaven kan man eventuelt bruke slettingsregelen ON DELETE SET NULL, se kap. 5.6. Dette fører imidlertid til at man også mister opplysning f.eks. om hvilket fylke vedkommende var fra, slik at historiske statistikker ikke blir så lett å lage. 27 Det er vel egentlig et paradoks, men organiasjonene må altså lagre navn om deg, slik at de ikke skal risikere at de ikke får deg med i registeret deres! Dessuten: fristelsen ligger da naturligvis nærme til å sende et brev om "du som tidligere har gitt til oss, nå er vi i krise...." FY!

77

Kap. 6

MER KOMPLISERTE STRUKTURER

Dette bør utvilsomt modelleres slik dersom det er snakk om at de ulike avdelingene har ulike attributter, og at andre entitetstyper alltid er relatert bare til ett av nivåene. Ofte er imidlertid hierarkiene mindre strukturert: • Hva hvis noen avdelinger ikke har underavdelinger, andre ett nviå, andre kanskje svært mange nivåer? • Hva hvis noen ansatte er tilknyttet Avdeling, noen Underavdeling, noen Under under, eller kanskje 4,nivå? Skal man ha relasjonstyper fra ansatt til alle disse, og men bare én er aktuell for hver ansatt? • Hva hvis de ulike nivåene skal inneholde de samme attributter, og i det hele tatt er like strukturmessig?

Hierarki i et vilkårlig antall nivåer - hierakiske egenrelasjoner

Hvis det skal være et vilkårlig antall nivåer, kan man selvsagt ikke tegne under-under-under... etc. i det uendelige. Avdeling er knyttet til et antall avdelinger av samme type som seg selv, eller mer presist: En avdeling kan ha som underordnet er vilkårlig antall avdelinger. En avdeling kan ha som overordnet maksimalt en avdeling.

1 Påkledning 2 Yrkesklær 3 Klær 4 Sko 5 Barneklær 6 Voksenklær 7 Dameklær 8 Herreklær 9 Møbler a)

b)

c)

Figuren viser et hierarki beskrevet som en datamodell, som en graf (her: et tre) og som tabell/"relasjonell form”, dvs. slik den ville se ut i en relasjonsdatabase. Sjekk at det er samme data i treet og tabellen! Relasjonstypen medfører en "intern" fremmednøkkel. I en gitt forekomst av entitetstypen viser verdien av fremmednøkkelen til avdelingsnummeret for den overordnede avdelingen, og fremmednøkkelen er derfor døpt om til Overordnet avdnr. Legg merke til at en avdeling kan ha en overordnet, ikke må. Alternativt kunne man selvsagt definert at det øverste nivået har seg selv som overordnet. Vi bør uansett ikke tillate at "egenfremmednøkkelen" er en del av identifikatoren. Dette ville ført til at "identifikasjonen går i sirkel".

Med en slik struktur kan vi ha et vilkårlig antall nivåer, og ansatte kan tilkobles ulike nivåer. Man må imidlertid være klar over at denne strukturen også har sine problemer. Blant annet kan det være ønske om ulike attributter pa de forskjellige nivåene. Hvis man ønsker en hierarkisk nummerering av nivåene (1, 1.1, 1.2, 1.2.1 osv.) er det lurest å ha en fortløpende teller som identifikator for hver node, og så lage nummerering når man skal skrive ut hierarkiet. Dermed kan man legge til nye eller fjerne noder uten at man behøver å tenke på omnummerering. Noen fa andre eksempler på hierarkier: • en ansatt kan være sjef for en rekke ansatte, som igjen kan være sjef for andre, osv. • et prosjekt kan bestå av delprosjekter, i et vilkårlig antall nivåer • en bok kan bestå av kapitler, som består av underkapitler i et vilkårlig antall nivåer • en harddisk deles opp i kataloger/mapper som igjen kan bestå av kataloger, som igjen

Som avslutningskommentar bør det sies at slike strukturer ikke alltid er så lett å håndtere i databasesystemer. Standardspråket SQL som brukes i forbindelse med databaser har f.eks. problemer med f.eks. "finn alle underavdelinger i alle nivåer for avdeling nr. 1", For de som kan programmere eller kan noe om algoritmer og datastrukturer: problemet er knyttet at mange operasjoner på trær enklest formuleres rekursivt.

78

1 1 1 3 3 6_ 6_

Kap. 6

MER KOMPLISERTE STRUKTURER

6.5.2. Nettverk Representasjon av nettverk i datamodeller. Tankegangen er den samme som over, nemlig at vi har "noe" som er knyttet til andre av "noe". Den klassiske eksemplet på dette er at en vare kan bestå av andre varer, jfr. for eksempel møbler fra IKEA.

I a) har vi bare den rene m:m med seg selv. I b) har vil vi også ha med hvor mange av hver vare som inngår i hver vare. Dette er det samme som vi har sett tidligere i forbindelse med entitetisering - nemlig at vi må entitetisere hvis vi skal vite noe om forholdet mellom entitetstypen(e) som relasjonstypen går mellom. Et slikt nettverk kan framstilles på flere måter, se figur under.

Varenr Varenavn 100 101 102 103 104

............ ............

Varenr Består_av_ varenr 100 101 100 103 101 102 104 101 102 103 104 103

a)

a) b) c)

b)

Antall

2 3 1 4 2 4

c)

er som rettet graf28, i dette tilfellet også med vekter - i form av antall av hver vare i hver vare. er en relasjonell form/tabellform slik den kunne uttrykkes i en relasjonsdatabase. er en matrise.

28 For de som ikke er kjent med grafer: det er vanlig å kalle sirklene for noder, mens linjene kalles for kanter (jfr. trekanter, firkanter osv). 1 en rettet graf (directed graph) har kantene retning fra en node til en annen. I en ikke-rettet graf har ikke kantene retning, de går mellom to noder.

79

Kap. 6

MER KOMPLISERTE STRUKTURER

Legg merke til at de 3 formene graf, relasjonell/tabeliform og matriseform uttrykker nøyaktig det samme informasjonsinnholdet. Vi sier gjerne at de er isomorfe, eller litt enkelt sagt: det er en fullstendig én-til-énkorrespondanse mellom dem. Som kjent finnes det også andre måter å representere en rettet graf på som også er isomorfe med representasjonene over, se vanlige bøker i algoritmer og datastrukturer. Bruk gjeme litt tid på å se at det er samme data som representeres i alle de tre formene!

De som kjenner litt til grafer, ser umiddelbart at man i den relasjonelle formen har én tabell for nodene og én tabell for kantene. I tillegg til det praktiske behovet for modellering av nettverk, viser dette at vi alltid kan sette en graf på relasjonell form, slik at dette i noen tilfelle kan fungere som en alternativ datastruktur for å representere grafer i et program.

Symmetri? En varestrukturer er et eksempel på en ikke-symmetrisk struktur. I andre tilfelle er datamodellen symmetrisk i og med at de to "benene" i datamodellen beskriver det samme. Et eksempel: Vi skal lage informasjon om hvilke land som er nabo til hvilke land. Det er i så tilfelle

Figuren viser ikke-entitetisert og entitetisert form av nabolandsproblematikken.

Konkrete data for denne er f.eks. Landsnavnl Norge Norge Norge Sverige Finland

Landsnavn! Sverige Finland Russland Finland Russland

Landsnavn1

Landsnavn2

Norge

Norge Sverige Finland Russland

Sverige x

Finland x x

Russland x

X

Siden det her bare var snakk om hvilke som land som var knyttet til hvilke land, er eksistensen av naboskap bare markert med et kryss i matrisen. Dersom man f.eks. skulle lagre antall kilometer felles grense, ville vi i stedet satt inn et tall i matrisen, hhv. lagt til en kolonne ekstra i tabellen. Forholdet kunne selvsagt også vært tegnet som en graf, og vi vil se at denne grafen er en ikke-rettet graf, dvs. at man ikke trenger piler for å vise retning.

Det er klart at dersom (Landsnavnl,Landsnavn2) finnes i tabellen, må også (Landsnavn2,Landsnavnl) være sant - altså at det er symmetri i dataene. Vi trenger heller ikke å lagre (Landsnavn 1,Landsnavn 1). En slik matrise kalles i matematikken for en strengt øvre (evt. nedre) triangulær matrise. Enkel matematikk viser at det ror n noder blir høyst n * (n-1) . ? kanter.

80

Kap. 6

MER KOMPLISERTE STRUKTURER

Dersom man lagrer data "begge veier", får man altså redundans. Det problematiske med slike strukturer er selvsagt at dette kan føre til inkonsistenser. Det ville f.eks. vært mulig å lagre at Norge hadde felles grense med Russland, men at Russland ikke hadde felles grense med Norge, eller at antall kilometer felles grense var ulik.

Hvorledes løse problemet? I praksis bør man ta et standpunkt til om man • vil tillate dobbeltlagringen og dermed inkonsistensfaren. • tillater dobbeltlagring, men av og til kjører kontroller på at inkonsistenser ikke eksisterer. • lar data skal gå gjennom en forprosessering, f.eks. slik at når data legges inn, så legges de alltid inn slik at fra land < til land i alfabetisk rekkefølge (eller en annen tilsvarende sortering). Tilsvarende må man ta hensyn til dette i forbindelse med spørring inn mot dataene. Ingen av disse løsningene er fullgode, men moderne databasesystemer har mekanismer som gjør at vi kan automatisere den siste løsningen. Til slutt: dersom problemstillingen over var litt anneledes, ville vi ikke fått symmetri. Eksempelvis kunne man ønske å lagre hvor mye (i antall millioner kroner) et land hadde eksportert for til et annet land. I så tilfelle måtte man lagre dataene "begge veier".

Eksempler på nettverk. Noen få eksempler på problemstilinger som gjerne må modelleres som nettverk: • Kurs i en kursrekke, hvor man har som bygger på andre kurs. • Flyruter (hvilke norske byer går det fly mellom)? • Firmastrukturer (hvilke firmaer eier hvilke, og i hvor stor eierprosent)? • Saker (f.eks. i offentlig forvaltning), som henviser til andre saker. Tilsvarende vil en representasjon av lover, som ofte henviser til andre lover, gi et nettverk. • Prosjektplaner • Sosiogram - for kartlegging av de sosiale relasjoner mennesker i mellom • En oversikt over hvorledes politiske partier har utviklet seg (oppsplittinger, sammenslåinger osv.) • Nettverk av sammenkoblede datamaskiner • En tegning av en datamodell er i seg selv en graf.

Vær oppmerksom på at det ikke alltid er lett å se om data danner et hierarki eller et nettverk. Den greieste måten å avgjøre dette på, er å forsøke å tegne opp noen forekomster som et hierarki. Dersom dette "sprekker", må man modellere det opp som et nettverk. Det er ofte slik at noe som ser ut til å være et hierarki, i virkeligheten er et nettverk. Et typisk eksempel i å så måte er et slektstre: mange har en felles tipp-tipp-tipp-tipp-tipp-far eller mor, slik at et slektstre egentlig er et nettverk. Tenk også på utvidelesbehovet: det kan være at det er et hierarki i dag, men at man senere vil få "tverrstrukturer" som gjør at det blir et nettverk.

6.5.3. Konklusjon - modeller med hierarki eller nettverk. Datamodeller som inneholder hierarkier og/eller nettverk er relativt vanlige. Når vi møter problemstillinger som muligens bør modelleres som hierarki eller nettverk, kan det følgende brukes som en sjekkliste:

81

Kap. 6

6.6.

MER KOMPLISERTE STRUKTURER

"Alle-til-alle’’-relasjonstyper.

Dette hovedkapittelet heter Mer kompliserte strukturer. Alle-til-alle er egentlig ikke mer komplisert, men likevel en struktur som mange ikke tenker over, og som ikke er vanlig å beskrive i kurser i datamodellering. Det er imidlertid nyttig å være klar over problemstillingen, bl.a. for å skille den fra en normal m:m.

Alle-til-alle uten ekstra attributter. Delmengder av alle-til-alle.

Igjen tar vi for oss deler av en tidligere modell:

Hva hvis alle hadde tatt alle kurs?

Kursdeltagelse 1001 1002

unødvendig hvis alle-til-alle

I så tilfelle hadde det ikke vært nødvendig med noen relasjonstype i det heie tatt - hvis ansatt a, finnes, og kurs kj finnes, så vet vi at ansatt a, har tatt kurset k,. Det er det som i matematikk og databaseteori kalles for det et kartesisk produkt - "alle koblet med alle".

Shke alle-til-alle-relasjonstyper forekommer noen ganger. I de fleste tilfelle er det imidlertid ikke behov for at absolutt alle av noe kobles til absolutt alle av noe annet. Poenget er da nettopp at vi i de fleste tilfelle har behov for å vite hvilke ansatte som er koblet til hvilke kurs, m.a.o. hvilken delmengde av alle-til-alle som er aktuell. Det er nettopp derfor vi i de fleste tilfelle trenger denne "koblingensentitetstypen" for å vise hvilken delmengde av alle-til-alle som er aktuell.

82

MER KOMPLISERTE STRUKTURER

Kap. 6

Alle-til-alle med ekstra attributter.

Dersom man skal ha med opplysninger som gjelder hvert element i en alle-til-alle, vil man trenge en ny, koblet entitetstype uansett. Dette vil være tilfelle dersom man f.eks. skal ha med karakterer for alle på alle kursene.

Et mer realistisk eksempel: Et bilutleiefirma har følgende priser for ulike kategorier av sine biler: Pr.dag_^ Kat. A Kat. B Kat. C Kat. D

1 dag 450 550 650 800

3 dager 400 500 550 700

> 3 dager 350 400 500 600

Vi velger følgende datamodell for å representere situasjonen:

Det at den nye entitetstypen må inneholde alle kombinasjoner av kategorier og utleievarigheter, lar seg ikke beskrive i den grafiske modellen29. Sagt med andre ord: Skranken Antall forekomster (Omkostning) = Antall forekomster (Kategori) * Antallforekomster (Utleievarighet) kan ikke beskrives grafisk. Vi skal se videre på denne problemstillingen i forbindelse med relasjonstyper av høyere orden, se neste underkapittel. Vi avslutter dette korte underkapittelet med å påpeke det man ser av matrisen over: det at matrisen er fullstendig utfyllt er ensbetydende med at vi har en alle-til-alle-situasjon.

6.7.

Relasjonsty per av høyere orden.

Vi har til nå sett på relasjonstyper mellom to entitetstyper. I noen tilfelle har vi imidlertid problemstillinger som krever at 3 eller flere entitetstyper trekkes inn for å modellere en situasjon. Vi skal også se hvorledes vi kan kombinere fremmednøkler med identifikator-egenskapen for å beskrive regler / skranker i denne forbindelsen.

6.7.1. Koblinger mellom 3 entitetstyper. Situasjonen illustreres best ved et eksempel - vi vrir litt på ansatt-eksempelet: • I ANSATT-systemet antar vi at hver person kan jobbe i flere avdelinger (og omvendt), hver person kan ha flere stillingstyper (og omvendt) og hver avdeling kan ha flere stillingstyper (og omvendt). • Vi legger også inn følgende regel: For hver avdeling som den ansatte jobber i, skal vedkommende være ansatt i bare en stillingstype.

Skulle vi tegnet opp dette, ville det blitt 3 entitetstyper, og m:m-relasjonstyper mellom alle 3.

29 Det lar seg heller ikke representere direkte i en relasjonsdatabase uten bruk av tilleggsmekanismer. Problemet er også at man for å ha full konsistens til enhver tid vil måtte sette inn poster i 2 eller flere tabeller samtidig.

83

Kap. 6

MER KOMPLISERTE STRUKTURER

Imidlertid er det ikke en alle-til-alle-situasjon (jfr. kap. 6.6) - selv om vedkommende er ingeniør og økonom og jobber i avdeling nr 14 og 15, er det ikke sikkert at vedkommende jobber både som ingeniør og som økonom i begge avdelinger - regel nr. 2 tillater dessuten ikke dette i det hele tatt. Vi trenger derfor en kobling mellom ansatt, stillingstype og avdeling, altså en m:m:m (mange-til-mange-til-mange).

Men. for det første finnes ikke en slik 3-leddet relasjonstype" i vår notasjon, og for det andre har vi ingen mulighet for å lagre informasjon om hvilke kombinasjoner av kategorikode,avdelingsnr og ansattnr som er aktuelle. Løsningen er dermed å lage en ny entitetstype - tenk gjerne på det som en entitetisering av den 3leddede relasjonstypen over, slik at vi far:

4 kommentarer - som alle bør tenkes skikkelig igjennom: 1. I dette tilfelle fantes det et naturlig begrep for "koblingen", men ofte vil det være vanskelig å finne et passende ord for en slik entitetstype - den uttrykker som regel noe abstrakt. 2. Beskjeftigelse forutsetter en stillingstype, avdeling og ansatt, derfor minimum 1 i alle retninger fra denne. 3. Den valgte identifikatoren for Beskreftigelse er lagt inn for å oppfylle regelen over, nemlig at For hver avdeling som den ansatte jobber i, skal vedkommende være ansatt i bare en stillingstype". Dersom ikke denne regelen hadde vært satt opp, ville det vært naturlig å bruke kombinasjonen av alle 3 fremmednøklene som identifikator, eventuelt å lage en ny identifikator. Legg arbeide i å finne ut eventuelle slike regler, og hvorledes disse kan legges inn i en datamodell. Ofte vil løsningen ligge i å bruke en kombinasjon av fremmednøkler alene eller sammen men andre attributter for å få fram slike regler. 4. Slike "relasjonstyper av høyere orden" framkommer dersom problemstillingen krever at tre begrep (eller flere) brukes samtidig for å beskrive det vi ønsker. Eksempelvis kan ikke informasjonen "Ansattnr 100 har stillingskode 4521 i avdeling nr. 14" deles i to eller tre setninger som inneholder bare to og to av begrepene ansattnr, stillingskode og avdelingsnr. Prøv - det går ikke uten at du mister informasjon! Vi snakker derfor

84

Kap. 6

MER KOMPLISERTE STRUKTURER

om at Beskjeftigelse er irredusibel - den kan ikke reduseres til en forenklet struktur. Sagt med andre ord: den må være en relasjonstype av orden tre30.

Vi kunne ha kommet fram til den samme strukturen med en helt annen framgangsmåte: • Vi begynner med m:m mellom Avdeling og Ansatt • Dette splittes for å få med hvilke avdelinger vedkommende jobber i, og den nye entitetstypen kalles Beskjeftigelse. Avdeling/ansatt-kombinasjonen blir en naturlig identifikator for denne. • Til slutt tenker vi på at hver slik beskjeftigelse er koblet til en og bare en stillingstype, og trekker opp denne relasjonstypen. Resultatet blir identisk med figuren over.

Noen andre eksempler på samme problemstilling: • En lærer kan ha mange fag og mange klasser, hver klasse kan ha mange fag, osv. Men: Hver klasse har bare en lærer pr. fag. • En bryter kan delta i flere konkurranser og i ulike vektklasser, men i hver konkurranse deltar han bare i en vektklasse. • Ulike utstyrsenheter (f.eks. en bestemt datamaskin eller motorsag) kan være i bruk av ulike personer i ulike prosjekter. Men for hvert prosjekt er det bare en person som far lov til å bruke denne enheten. • I en ornitologisk database: En fugleobservasjon er kombinasjonen av person, fugleart og sted (pluss dato). Vi antar at de 3 første har hver sin entitetstype. I en entitetstype fugleobservasjon vil kombinasjonen av person_id,fugleart_id, sted id og dato være identifikator. • Anta i stedet at systemet bare skulle inneholde første observasjon av en fugleart på et bestemt sted, samt dato og hvilken person som observerte arten. Da ville kombinasjonen av sted og fugleart være identifikator, selv om man har en kobling til en entitststype Person.

6.7.2. Flerrolle-problematikk. Vi har allerede vært borte i problemstillinger hvor det er flere like relasjonstyper mellom de samme entitetstypene, jfr. Vare-Vare struktur og Land-Naboskap (kap. 6.5.2). 1 begge disse tilfellene var det så å si gitt av problemstillingen at f.eks. Vare har nøyaktig to koblinger til Vare_struktur, og tilsvarende for Land. Vi kan derfor snakke om at f.eks. Vare og Vare struktur har to ulike roller i forhold til hverandre.

Hva hvis det ikke nødvendigvis er akkurat to slike roller? Vi skal se et eksempel på dette sammen med ulike løsninger.

Eksempel på flerrolleproblematikk - denne gangen noe annet enn ansatte: 30 Både N1AM og Chens opprinnelige ER-notasjon er bedre enn vår ER-notasjon til å vise slike forhold, se kap. 11.2 og 11.3.3. Til gjengjeld er de etter mitt syn mer kompliserte å forstå, og sammenhengen mellom disse og relasjonsdatabaser er mindre opplagt. Vi får også stort sett fram regler og lignende som er nødvendige, bl.a. fordi en eller flere fremmednøkler naturlig kan brukes som (del av) identifikatoren i slike tilfelle.

85

Kap. 6

MER KOMPLISERTE STRUKTURER

Det skal lages en modell for sanger, med tekstforfatterere, melodiforfattere og oversettere for en sangbok Dermed er det bare en melodi pr. tekst og motsatt. Hvilke mulige løsninger kan finnes? Forslag 1:

Løsningen er imidlertid lite heldig, ikke minst fordi mange tektsforfattere også er melodiforfattere til samme eller en annen sang, og ofte vil de samme personene også være oversettere for noen av sangene. Vi får altså mye redundans. I dette tilfelle bør vi derfor slå sammen de ulike rollene slik at personopplysninger finnes bare i en entitetstype,

m.a.o. at rollene er blitt til relasjonstyper. I slike situasjoner føles det naturlig å bruke et rollenavn (forfatter, komponist, oversetter) i stedet for en verbal beskrivelse. Man kan altså si at den første relasjonstypen angir at Sang og Person står i et forfatter-forhold til hverandre, den andre at Sang og Person (en annen eller samme) har et komponist-forhold etc. Modellen over kan godt betraktes som en mange-til-3-relasjonstype, altså en svært begrenset m:m. Denne er utvilsomt en bedre løsning enn den forrige, fordi man slipper å ha informasjon om de samme personene i ulike entitetstyper. Imidlertid har flere ulemper, bl.a. at den ikke er utvidbar. Hvis vi kom med to nye ønsker: * man vil utvide systemet til å gjelde en ekstra egenskap, f.eks. tilrettelegger av melodien. Dette ville gi en ny relasjonstype, og Sang ville måtte endres til å inneholde enda en fremmednøkkel. • noen av sangene er skrevet/komponert/oversatt av flere personer i fellesskap. Modellen takler ikke dette. Relasjonstypene måtte da i tilfelle vært m:m. I en database ville vi dermed fatt de to entitetstypene over, samt 3 koblingstabeller" for å holde m:m-relasjonstypene. Hvis både dette kravet og kravet over skulle vært realisert, ville vi fått en mye mer omfattende struktur.

Vi bør altså tenke på nytt, bl.a. ut fra at det egentlig er et m:m mellom personer og sanger, i tillegg til at det for hver slik kombinasjon kan finnes mange roller (forfatter, komponist, oversetter ,„). Vi ville vel at modellen skulle sett omtrent slik ut: Sang

forfatterfe), komponist(er), oversetter(e),...'

Person

Siden dette m:m-forholdet opplagt inneholder mer kompleksitet, splitter vi dette. I rolle vil vi da få en identifikasjon av personen og sangen som fremmednøkkel, samt at vi må si hvilken rolle den enkelte spilte i denne sangen (forfatter, komponist etc.). Siden disse rollene bør være faste, bør de enten hentes fra et forhåndsefinert domene, eller hentes fra en annen entitetstype. Dersom vi velger den siste løsningen, får vi følgende:

86

Kap. 6

MER KOMPLISERTE STRUKTURER

Rolletype

Eksempler på data her: F, 'Forfatter' K, 'Komponist' O, 'Oversetter'

Rollekode

Rollenavn

Sang

Sangmedvirkning

Person

Sangnr

*Sangnr

Personid

* Personid "Rollekode

Denne løsningen er svært fleksibel: • Dersom vi ønsker noen flere rolletyper, kan vi bare legge disse inn som data i Rolletype, og deretter er de valgbare som roller som kan knyttes til en sang og person. • Dersom vi ønsker f.eks. flere forfattere på samme sang, gjør vi det ganske enkelt ved å bruke kombinasjonen av f.eks. sangnr og aktuell rollekode sammen med flere personid. • Hvis vi skulle kreve at hver person bare hadde én rolle (kunne være enten forfatter eller komponist eller oversetter), kan dette gjøres ved at bare identifikator i Sang medvirkning i stedet besto av kombinasjonen (Sangnr,Personid). Andre betingelser / skranker kan ordnes ved ulik bruk av fremmednøklene som en del av identifikatoren.

Som en videreføring: Hvorledes burde datamodellen sett ut dersom vi skiller melodier og tekster, slik at hver tekst kan ha flere melodier og motsatt? Legg merke til at det som i de to første utgavene av denne modellen var en del av strukturen, nemlig Forfatter, Komponist, Oversetter, i det siste forslaget er blitt en del av data som kan endres på. Vi har altså laget en mer åpen struktur ved at noe av metadata (dvs. strukturen) i stedet er blitt vanlige data. Dette er et svært vanlig triks i forbindelse med datamodellering. Dersom et slikt system skulle lages f.eks. for filmer, ville fordelene vært enda mer åpenbare, fordi de ulike personene kan inngå i svært mange forskjellige roller.

Andre eksempler

Bilder i et bildearkiv: hvem er med på de ulike bilder, og hvilken rolle har de (hovedperson, biperson etc.) En idrettsklubb: ulike idrettsgrupper og personer: hvilke verv (leder, sekretær, oppmann, ..) har en person i hver av gruppene. • En skole: ulike personer og fag: hvilken kompetanse (grunnfag, mellomfag, hovedfag) har vedkommende. • Prosjekter: hvilke personer og prosjekter og hva slags rolle personene har i prosjektene (leder, deltager, ekstern konsulent) etc. Vi bruker ofte fremmednøkler som en del av identifikator for å begrense lovlige kombinasjoner (jfr. kap. 6.7.1).

• •

Vurder om det er (nesten) samme informasjon for hver rolle. Tilfellene over var enkle, i og med at man uansett skulle ha samme opplysninger om alle rollene. I andre tilfelle vil de ulike rollene kreve litt ulike data. Det er da et avveiningsspørsmål om man skal ha sterk strukturering av informasjonen eller ikke.

87

Kap. 6

MER KOMPLISERTE STRUKTURER

Vi tenker oss at vi skal ha opplysninger om ulike datamaskiner som finnes på en arbeidsplass, inklusive hvilken program- og maskinvare de har. For enkelhets skyld tenker vi kun på selve maskinene, harddisken(e) i hver maskin, diskettstasjon(er), høyttaler(e).

•

•

I a) har vi en entitetstype for hver utstyrsenhet og utstyrstype - noe som blir temmelig omfattende hvis vi skal ha med alle aktuelle utstyrstyper. I b) har vi gjort en kategorisering, slik at de ulike utstyrstypene (diskettstasjon, harddisk, høyttaler, etc.) er data i entitetstypen utstyrstype. Dermed kan nye utstyrstyper legges inn uten at strukturen endres. På den annen side kan vi ha "overkategorisert" dersom data som skal lagres om utstyr er forskjellig avhengig av hva slags utstyrstype det er snakk om. Eksempelvis:

UTSTYR

Utstyrskode Diskettstasjon Disk Høyttaler

Verdi_for_utstyr 1,44 6,5 30

Enhet MB GB watt

Vi ser altså at "hva verdien gjelder" bør finnes sammen med selve verdien. Spørsmålet er om de ulike utstyrstypene er såpas ulike at vi nesten gjør vold på virkeligheten ved å lage felles kategorier.

Problemstillinger rundt hvor "sterk kategorisering" vi bør velge er svært vanlige innenfor datamodellering. Eksempelet viser at det neppe finnes noe entydig svar på dette, men man må rett og slett avveie hvor like eller ulike de forskjellige tingene er31.

Egentlig er vi her ved det helt grunnleggende spørsmål i så å si all kategorisering, ikke minst innen databehandling. Jeg kaller det for Det store kategoriseringsspørsmålet. Det store kategoriseringsspørsmålet: Hvor like er ting for at det skal betraktes som det samme, og hvor ulike er de for at det skal betraktes som forskjellige?

Forfatteren var for en tid tilbake med på å designe et slikt system for utstyrshåndtering, hvor det ikke var noen tvil om at en sterk kategorisering var en god løsning. Opplegget var naturligvis en god del mer komplisert enn eksempelet over viser.

88

MER KOMPLISERTE STRUKTURER

Kap. 6 6.8.

Ekvivalente stier.

Noen datamodeller er slik at du kan gå to (eller flere) forskjellige veier (stier) fra en entitetetstype til en annen. I noen tilfelle er dette uproblematisk, mens det i andre tilfelle kan føre til redundans eller inkonsistenser i data. Slike problemer handler om det som kalles ekvivalente stier (engelsk: eqvivalence-of-path). Vi definerer først begrepet "ler-sti"32:

Vi har en ler-sti fra entitetstype B til entitetstype A dersom vi kan gå fra B til A og stien alltid går i en retning hvor det er maksimum 1.

Begrepet ekvivalente stier kan defineres slik:

Vi har to (eller flere) ekvivalente stier fra B til A dersom vi har to (eller flere) forskjellige ler-stier slik at du for en gittforekomst av B alltid møter samme forekomst av A uansett hvilken sti du går.

En vanlig situasjon er denne:

På forekomst-nivå er det da spørsmål om vi for en gitt B-forekomst alltid møter samme A-forekomst uavhengig av hvilke stier vi går mellom. Les figuren under nedenfra (fra b-ene)!

a)

ekvivalente stier: for en gitt B-forekomst møter vi alltid samme A-forekomst via begge ler-stier.

b)

ikke ekvivalente stier: for en gitt B-forekomst kan vi møte forskjellige A-forekomster

Et par eksempler vil som vanlig hjelpe på forståelsen.

32 Dette begrepet er ikke sett andre steder. Begrepet referansesti (referential path, se f.eks. Date 1995 s. 119) er nesten det samme, men en refereransesti må alltid gå fra en fremmednøkkel til dens "eier", mens en ler-sti kan også gå gjennom "den motsatte veien" av fremmednøkkelen i en én-til-én-relasjonstype. Dersom ler-stien inneholder en slik "motsatt vei".

89

Kap. 6

MER KOMPLISERTE STRUKTURER

Eksempler: Vi tenker oss et konsern med mange firmaer, avdelinger og produkter, og enda flere ansatte. Vi antar at det kan være flere like avdelingsnummer i de ulike firmaene, slik at kombinasjonen av firmanr og avdnr er nødvendig for å identifisere en avdeling. Tilsvarende for produkter og for prosjekter. Det er vel urealistisk at hver ansatt bare kan være med i et prosjekt, men problemstillingen blir den samme uansett.

a) Ekvivalente stier (sannsynligvis)

b) ler-stier som ikke er ekvivalente (sannsynligvis)

a)

inneholder ler-stiene Ansatt-Avdeling-Firma og Ansatt-Produkt-Firma. Spørsmålet er da. hvis vi går fra et gitt ansattnr via disse stiene, vil vi da nødvendigvis møte samme Firma? Med andre ord. Kan personen jobbe med produkter som produseres av en annet firma enn det han/hun er ansatt i? Svaret er antagelig nei. Da er de to firmanr i Ansatt alltid like, og bør slås sammen.

b)

inneholder to grupper av ler-stier. 1 tillegg har vi delmengder innen disse gruppene igjen (de to siste i b)). Ansatt-Avdeling-Firma Ansatt ---- Firma. Ansatt-Prosjekt-Firma Ansatt-Post Ansatt-Avdeling-Post Ansatt---- Post. 1 tillegg til de som er oppgitt her Ansatt-Avdeling-Firma-Post kommer delmengder av disse stiene, nemlig Ansatt-Prosjekt-Firma-Post Avdeling-Post og Avdeling-Firma-Post Dermed: >■ Kan en person delta i et prosjekt utenfor sitt eget firma? Antagelig er svaret Ja, og i så tilfelle er ikke disse to stiene ekvivalente. Dermed er begge firmanr i Ansatt nødvendige, men ett eller begge bør døpes om, f.eks. til avdelingjfirmanr og prosjekt_firmanr. >■ Kan en person ha et postnr som er forskjellig fra avdelingens firmanr? Her er svaret helt sikkert Ja, og de to stiene er ikke ekvivalente. > Kan en ansatt ha et postnr som er forskjellig fra postnr for det firma han/hun jobber i? Igjen er svaret Ja. Tilsvarende for alle andre ler-stier fra Ansatt til Post. Det er naturlig å konkludere med at eksempel b) ikke inneholdt noen ekvivalente stier.

90

Kap. 6

MER KOMPLISERTE STRUKTURER

Legg merke til at grafene i a) og b) var helt like, med unntak av postnr-problemstillingen. Man kan dermed ikke se på selve grafen om ler-stiene er ekvivalente, men vi må undersøke hvilke regler som gjelder for den virksomheten man skal lage en modell for. Uten å føre noe mer formelt argument for det, er det naturlig at følgende regel gjelder:

Dersom samme to fremmedattributter kommer fra samme "opprinnelige eier" men via forskjellige stier: • slå dem sammen dersom de er ekvivalente stier33. • behold dem, og gjør om navn på en eller begge dersom stiene ikke er ekvivalente.

Hva hvis fremmednøkkelen ikke arves hele veien? Vi tar opp igjen problemstillingen med Firma - Avdeling - Produkt - Ansatt. Det er lett å tro at problemet med ekvivalente stier kom av at firmanr ble arvet i begge stiene fra Firma til Ansatt, slik at firmanr kom ned som fremmednøkkel to ganger i Ansatt, og at problemet ville være løst dersom man f.eks. innførte et eget produktnummer som var uavhengig av firmanr.

Saken er imidlertid at dette ville gjøre det enda verre, fordi det da ikke er så synlig at vi har ekvivalente stier. Med denne strukturen vil vi f.eks. kunne lagre: firmanr 1 2

avdnr 100

firmanavn A/S .... A/S ...

firmanr 1

produktnr 8888 ansnr 1000

avdnr 100

firmanr 2

produktnr 8888

33 Det bør gjøres oppmerksom på at en slik sammenslåing er kan gi problemer ved oppdatering. Dersom er firmanr endres, kan da endringen gjøres slik at referanseintegriteten hele tiden vedlikeholdes (også midt i endringen)? Detaljer om dette hører hjemme i databaseteori, og tas ikke opp her.

91

Kap. 6

MER KOMPLISERTE STRUKTURER

uten å kunne hindre at vi lagrer data om at personen jobber med et produkt fra et annet firma enn der han/hun er ansatt. Hvis denne kontrollen var viktig måtte vi finne andre måter å kontrollere det på (f.eks. via såkalte triggere i et databasesystem eller kontroller ved inntasting av data).

Ekvivalente stier kan være redundante Eksempel 1:

Vi har tidligere sett på problemstillingen med Hovedkategorier, Underkategorier og ledige jobber på et arbeidskontror (kap. 6.4.2). Vi har her tegnet opp en relasjonstype fra LedigJobb til Hovedkategori.

Slik den er tegnet her, er det naturlig å anta at stiene Ledigjobb - Underkategori - Hovedkategori og Ledigjobb - Hovedkategori ekvivalente. Den er redundant, fordi all informasjon som finnes i denne kan avledes via de to andre. En slik kalles ofte en avledet relasjonstype, noe som f.eks. kan vises med en stiplet linje. Relasjonstypen er overflødig og kan (og bør) fjernes. Vær imidlertid klar over at i mange slike tilfelle er stiene ikke ekvivalente, slik at relasjonstypen er nødvendig!

Eksempel 2:

Et annet eksempel på situasjoner som er vanskelig å håndtere:

Vi har tatt utgangspunkt i vårt vanlige ordresystem, men skal også ha med fakturering. I enkle tilfelle kan man ta fakturalinjene direkte ut fra ordrelinjen - slik vi har vist her.

Vi kan tenke oss ulike tilfelle: • Som vi har tenkt oss over, skal vi ha mulighet til å lage en faktura som gjelder flere ordrer, eventuelt å spre samme ordre på flere fakturaer. I så tilfelle må fakturaen ta utgangspunkt i hver enkelt ordrelinje, slik vi har

92

Kap. 6

•

MER KOMPLISERTE STRUKTURER

vist her. Dette skaper imidlertid flere ler-stier mellom to av entitetstypene, nemlig Ordrelinje og Kunde. Er disse ekvivalente? Hvis man unntaksvis skal kunne faktureres for noe et annet firma har bestilt, er de ikke ekvivalente. Hvis man bare kan faktureres for sine egne ordrelinjer, er de ekvivalente. I så tilfelle er også Kunde-Faktura redundant, fordi kundeinformasjonen som trengs på fakturaen kan leses via Ordrelinje-Ordre-Kunde-stien. Det virker imidlertid litt tungvindt å gå denne lange stien for hver gang man skal ha kundeinformasjon, og dessuten får man i utgangspunktet denne kundeinformasjonen mange ganger - en for hver relatert ordrelinje. Hvis vi i stedet ønsker at en ordre må faktureres samlet (men at fakturaen kan gjelde flere ordrer): Første idé var antagelig bare å kutte ut relasjonstypen fra Faktura til Ordrelinje. Dette gjør imidlertid at man ikke finner igjen hvilke ordrer den enkelte fakturaen gjalt (man "mister tråden", se kap. 6.1). Det bør derfor være en 1 :m fra Faktura til Ordre, samtidig som Faktura - Kunde blir redundant dersom man ikke skal kunne betale for andres ordrer.

Eksempel 3 - nødvendig redundans pga. tidsperspektivet: Vi tenker oss et system for studieadministrasjon på et studiested med mange studier. Vi antar her (urealistisk, men det forenkler problembeskrivelsen) at en person kan opptas ved bare ett studium ved studiestedet.

Spørsmålet angående ekvivalente stier blir: Kan en student ta eksamen i kurs som ikke hører til sitt eget studium? Hvis svaret er Ja, vil de to aktuelle stiene ikke være ekvivalente. Hvis svaret er Nei bør vi sjekke om disse to stiene er redundante. I teorien er de det, og vi kunne kutte ut relasjonstypen mellom studium og student. Vi kan jo finne ut hvilket studium vedkommende går på ved å se hvilke eksamener vedkommende har tatt. Men: hva med de som nettopp er tatt opp til studiet, og dermed ikke har noen eksamen? Må vi registrere en "kvasieksamen" på dem bare for å kunne legge inn hvilket studium de går på?

Konklusjonen her er dermed at også redundante ekvivalente stier i praksis kan være nødvendige p.g.a. at data som gjør de redundante ikke blir lagt inn på samme tidspunkt.

Eksempel 4: Ekvivelente stier, alternative verdier og litt til etc. - en "umulig" struktur.

93

Kap. 6

MER KOMPLISERTE STRUKTURER

En vare kan ha ulike priser over tid (jfr. fradato og tildato), og derfor lager vi en "varepris". Vi tenker oss at vi kan legge inn nye priser for framtiden (planlagte kampanjer). • Siden vi må ha (Varenr,Fradato) eller tilsvarende som identifikator i Varepris, må fradato være en del av fremmednøkkelen som implementerer Varepris-Ordrelinje i Ordrelinje. Ellers ville ikke ordrelinje kunnet referere til en bestemt varepris-forekomst. Men fradato (når den bestemte prisen begynte å gjelde) har selvsagt ingenting med Ordrelinje å gjøre, og burde ikke finnes der. • I alle tidligere tilfelle har fremmednøkkelen blitt behandlet som en enhet også hvis den besto av flere enn ett attributt. Eksempelvis var enten hele fremmednøkkelen identifikator, eller ingen del av den var det. For (Varenr,Fradato)-kombinasjonen i Ordrelinje brytes imidlertid dette prinsippet. • Vi hadde tenkt at pris i vare var den som gjaldt dersom vi ikke hadde noen bestemt varepris for den aktuelle perioden, men siden * varenr i Ordrelinje er fremmednøkkel både til Varepris og Vare, må * varenr i Ordrelinje fylles ut (del av identifikatoren for ordrelinje). Men da må også Fradato fylles ut, slik at OrdreVarepris får minimum 1. Altså kan vi ikke få at enten Ordrelinje-Varepris eller Ordrelinje-Varerelasjonstypen skal gjelde for en gitt Ordrelinje. • Vi kunne ha kuttet ut relasjonstypen Ordrelinje-Vare, men de fleste problemene ville likevel bestått. Strukturen er problematisk av flere grunner, bl.a. fordi verdien som skal plukkes fra Varepris til Ordrelinje er gitt av noe utenforstående (dagens dato). Det spørs om ikke det hele bør omformuleres noe, f.eks. slik at man hadde en standardpris og en aktuell pris i vare. Hvis det ikke var noe tilbud var standardpris = aktuell pris. Hvis det var et tilbud, sørget vi for at aktuell pris ble hentet fra en Varepris uten at denne nødvendigvis var relatert direkte. Aktuell pris kunne da legges inn for hver dag, eller hentes for hver ordrelinje som ble laget.

Problemet er at Ordrelinje-Varepris ikke egentlig er naturlig å relatere i vanlig forstand, fordi det ikke er viktig å sjekke verdiene i Ordrelinje mot identifikatoren i Varepris. Dersom man skulle laget et informasjonssystem ut fra dette ville dessuten utplukket av riktig verdi i Varepris bestemmes av en kobling mellom varenr og klokken/datoen. Dette er et eksempel på problemsstillinger som vanskelig lar seg løse direkte via datamodellen, og hvor vi delvis må tenke prosydurelt samtidig. Det er naturligvis mulig å konstruere andre eksempler på slike "umulige" strukturer.

Oppsummering - ekvivalente stier. Når flere ler-stier går fra entitetstypen B til entitetstypen A kan disse være ekvivalente stier, men behøver ikke å være det. Det er generelt sett umulig å avgjøre dette ved bare å se på entitets- og relasjonstypene.

Det er viktig å merke seg at ekvivalente stier er en skranke - altså en begrensning/betingelse/tilleggsregel som gjelder modellen, på samme måte som maksima og minima er skranker.

94

Kap. 6 •

•

MER KOMPLISERTE STRUKTURER

Modellen kan håndtere ekvivalente stier-skranken automatisk hvis og bare hvis du kan følge arvede fremmednøkler langs begge stiene helt til den "den opprinnelige eierens" identifikator. Dette gjøres ved at disse fremmednøklene slås sammen i starten av stien. I andre tilfelle kan ikke de ekvivalente stier kontrolleres datamodellmessig, og man må eventuelt ty til andre mekanismer.

En advarsel til slutt: I en del tilfelle ser det først ut som om stiene er ekvivalente, men ved en nærmere undersøkelse finner vi ut at ekvivalensen ikke gjelder i absolutt alle tilfeller. Vi har sett flere eksempler over som er diskutable i så måte.

95

Kap. 7

KORT OM NORMALISERING AV EN DATAMODELL

7. Kort om normalisering av en datamodell Mens vi tidligere mest har konsentrert oss om en hel datamodell, vil vi nå se på strukturen i en og en entitetstype. Litt forenklet sagt går normalisering ut på å avsløre eventuelle "indre sammenhenger" mellom attributtene, sammenhenger som fører til at vi burde ha gjort utsplittinger i flere entitetstyper. Vi går altså fra et "makroperspektiv" til et "mikroperspektiv". Det vil være umulig å se om en datamodell er normalisert bare ved å kikke på selve attributtlisten. Man må i tillegg ha kunnskap om hvorledes de forskjellige attributtene eventuelt er knyttet til hverandre i virkeligheten. Følgelig er det å finne fram til indre sammenhenger som gir grunnlag for normalisering ikke en automatiserbar prosess. Selv om normaliseringsreglene i vanligvis er formulert ut fra relasjonsdatabaseteori, er det ingen ting i veien for at man jobber med dem med utgangspunkt i en datamodell. For å kunne bruke normaliseringsreglene, må vi imidlertid på forhånd ha definert identifikatorer, og dermed i praksis også fremmednøkler. Jeg krever imidlertid ikke at m:m-relasjonstyper er entitetisert (hvis dette ikke da er nødvendig .for å få med alle detaljer i problemstillingen). Vanlige m:m-relasjonstyper kan aldri gi opphav til normaliseringsproblemer, men må selvsagt splittes før datamodellen overføres til et databasesystem. Vi bør også nevne at det er under en viss tvil at vi har tatt med normalisering under datamodellering, fordi det tradisjonelt har hørt inn under emnet databaseteori. Vi mener likevel det er grunn til å ta det med, fordi bevissthet omkring normalisering ofte vil gjøre at man får beskrevet forhold ved virkeligheten som det er riktig å ta med i en datamodell - og forhold som er helt uavhengig av en eventuell implementering i en relasjonsdatabase. Kort sagt: normalisering vil tilføre datamodellen mer semantikk.

Vi har valgt å dele opplegget om normalisering i to, delvis en enkel innføring som vil være nok til at man i praksis får en godt normalisert datamodell, • delvis et TILLEGG A som tar for seg normaliseringsreglene mer i detalj, sammen med eksempler.

7.1.

Normalisering i praksis.

Normaliseringsteori blir av mange praktikere regnet som "fjernt" og vanskelig. Imidlertid er selve ideene bak normalisering svært enkle, og kan uttrykkes slik:

Hovedregelen for normalisering: Se °m det finnes noe som gjentas sammen eller som danner en samlet gruppe innenfor en entitetstype Splitt i tilfelle dette ut i en ny entitetstype.

Etter å ha hjulpet barn med å systematisere opprydding på barnerommet, er jeg kommet til en enda mer folkelig form pa normahseringteorien: Hovedregelen for normalisering - folkelig form:

Forskjellige ting skal legges i forskjellige bokser. |

Med forskjellige bokser mener vi selvsagt forskjellige entitetstyper/entitetsbokser.

96

Kap. 7

KORT OM NORMALISERING AV EN DATAMODELL

Dersom man har dette prinsippet i bakhodet når man utvikler datamodellen, vil denne i praksis også være normalisert. Reglene for normalisering er derfor nærmest bare en kontroll på at man har gjort en god datamodelleringsjobb, slik at det kan ses på som en form for kvalitetssikring.

Vi har sett tidligere at to entitetstyper med l:m-relasjonstyper seg i mellom ikke bør slås sammen til en enkelt entitetstype. Litt forenklet sagt er normaliseringsreglene regler som skal hjelpe deg til å avsløre uheldige l:mrelasjonstyper internt i en entitetstype. Et eksempel:

1 ansattsystemet ønsker man av en eller annen grunn å samle avdelingsnr, avdelingsnavn og ansattdata i samme entitetstype, slik: ANSATT

Ansattnr Ansattnavn Privattelefonnr Avdelingsnr Avdelingsnavn

(underforstått: for den avd. man jobber i)

For å avsløre eventuelle uheldige sammenhenger, "sprer vi attributtene utover" samtidig som vi setter på eventuelle l:m-forhold disse imellom, slik:

Det kan ved første øyekast virke litt merkelig at samme ansattnavn kan ha flere ansattnr. Vi snakker imidlertid her om navnet, eksempelvis at navnet Kjetil Hansen kan finnes for to forskjellige ansattnr. Tilsvarende: Et telefonnr kan gjelde flere ansatte, f.eks. hvis et ektepar jobber i samme firma. 1 :m-forholdene fra "ikke-identifikatoren" til identifikatoren er greie, fordi de kun gir ny informasjon om den entitetstypen som vi arbeider med, her: ANSATT. Det uheldige 1 :m-forholdet er det som finnes mellom avdelingsnr og avdelingsnavn. Vi ser at strukturen fører til avledede relasjonstyper, noe som vi bør unngå (jfr. om relasjonstyper i kap. 3.7). De som kjenner til normalisering, kjenner igjen denne problemstillingen som brudd på 3. normalform. Blant formelle grunner vi kan anføre for at dette er en uheldig struktur, er bl.a.: • opplysning f.eks. om at avdeling nr 3 heter Regnskapsavdelingen vil gjentas for hver person som jobber der. Dette gir unødvendig dobbeltlagring, redundans. Hvis man ikke er svært nøye, kan det føre til at man får data som ikke "stemmer med seg selv", inkonsistenser (jfr. også kap. 2.2). Hvis mange jobber i den samme avdelingen, er det svært lett å skrive feil en eller flere ganger, slik at dataene blir selvmotsigende. • Det vil være umulig å finne fram til at f.eks. avdeling nr 7 heter "Smøreavdelingen", dersom man tilfeldigvis ikke har noen ansatte der for tiden.

Selv om det ville vært mulig å drøfte hele normaliserings-teorien via relasjonstyper, velger vi i neste underkapittel å gå over til et annet begrep, nemlig determinantbegerepet.

97

Kap. 7 7.2.

KORT OM NORMALISERING AV EN DATAMODELL Hovedregelen for normalisering.

I de fleste framstillinger av normalisering gir man først og fremst en beskrivelse av normalformene (12., 3. normalform, Boyce-Codds normalform, 4. og 5. normalform). Vi vil i stedet gå direkte på Boyce-Codds normalform, bl.a. fordi den dekker både 2. og 3. normalform og "litt til", og at den er lettere å forstå enn disse Vi trenger da å definere et nytt begrep, nemlig begrepet "determinant".

Determinantbegrepet. En determinant er i vår sammenheng et attributt eller en gruppe av attributter som bestemmer (determinerer) verdien av et annet attributt. Vi bruker symbolet for å vise determinering. Noen eksempler: 1600 Fredrikstad Postnr Poststed, se tabellen 1601 Fredrikstad Ansattnr Postnr 1602 Fredrikstad Ansattnr Poststed Ansattnr Ansattnavn 1620 Gressvik Ansattnr Hårfarge Ansattnr Alder (hver person har bare en afder i øyeblikket!) Avdelingsnr + Avdelingsnavn Ansattnr Avdelingsnr (forutsatt at personen bare jobber i en avdeling) Ansattnr Avdelingsnavn (Ordrenr,Varenr) Antall (komb. ordrenr,varenr determinerer antall for denne ordrelinjen) Chassisnummer på bil -► Kjennetegn Kjennetegn Chassisnummer på bil

Vi ser at f.eks. "dersom vi kjenner postnr, så finnes kun ett poststed med dette postnr". Derimot ser vi at "hvis man kjenner poststed, er det flere ulike postnr", dermed er det ikke noen determinering den andre veien. Bortsett fra de to siste, gjelder alle disse determineringene bare den ene veien. Grunnen til at den siste gjelder begge veier, er at det er et 1:1 -forhold mellom Kjennetegn og Chassisnummer, de determinerer altså hverandre. Noen reagerer kanskje på Ansattnr Poststed, og mener at denne skulle gått via postnr. Imidlertid er det jo sant at gitt ansattnr, så har den ansatte kun ett poststed. Vi har dermed at både Ansattnr Poststed direkte og at Ansattnr Postnr Poststed, med andre ord både en direkte og en indirekte (transitiv) determinering. Det samme gjelder for Ansattnr, Avdelingsnr og Avdelingsnavn. Det er akkurat slike situasjoner som gir opphav til et av normaliseringsproblemene, slik vi skal se under.

Normaliseringsproblemer, et par eksempler. Eksempel 1: Ansattsystemet, nå tegnet med determineringsdiagram.

Det er jo slik at hvis vi kjenner ansattnummeret for en person, er også personens navn entydig gitt. Altså: ansattnr determinerer ansattnavn. Det motsatte er derimot ikke tilfelle: Hvis vi kjenner ansattnavnet Kjetil Hansen, er ikke ansattnr entydig gitt, fordi det godt kan være flere personer som heter Kjetil Hansen. På tilsvarende måte blir det med f.eks. privat telefonnr (forutsatt at vedkommende ikke har flere privattelefonnummer). Vi kan tegne det slik:

Identifikator Ansattnavn

Privat telfnr 98

Ansattnr

FY!

Avdelingsnr

Avdelings­ navn

Kap. 7

KORT OM NORMALISERING AV EN DATAMODELL

Vi ser at l:m-forholdene ganske enkelt er blitt snudd til determineringspiler, og at det uheldige Avdelingsnr Avdelingsnavn-forholdet kommer fram. Jeg velger å kalle et slikt diagram for et determinerings-diagram. Som vi skal se, ligger det uheldige i at ansattnavn kan determineres både direkte fra identifikatoren og indirekte via ansattnr. Altså: Ansattnr og -navn utgjør en gruppe som burde vært splittet ut, slik at vi får entitetstypene. Sagt med andre ord: vi blander sammen opplysninger om jobber i Ansatt Avdeling avdeling (avdelingsnr, avdelingsnavn) og ansatt (ansattnr, privar telefonnr, etc.). Løsningen er selvsagt som vist på figuren: Ansattnr Avdelingsnr

Eksempel 2. Bokeksemplarer.

Vi skal ha oversikt over alle bokeksemplarer som er kjøpt inn til et bibliotek, sammen med innkjøpsdato og

Vi tenker oss altså at samme bok (med samme ISBN) kan finnes i flere eksemplarer. Vi må derfor vite både ISBN og eksemplarnr for å vite innkjøpsdato. Derimot trenger vi bare å vite ISBN for å vite tittelen på boka. Hvis f.eks. 50 bokeksemplarer har samme ISBN, så har de også samme tittel. Dette blir dermed en uheldig struktur - redundans i dataene. Tabben man har gjort, er at man har blandet sammen noe som gjelder det bestemte bokeksemplaret (innkjøpsdato) og noe som gjelder bok, som ISBN. Løsningen blir igjen å "legge forskjellige ting i forskjellige bokser", dermed:

Normaliseringsregelen. I de eksemplene vi har sett over, er determinering fra identifikatoren helt i orden, mens en determinering fra andre attributter, eller fra deler av identifikator har ført til problemer. Siden kandidatnøkler er attributter som kunne vært identifikator, er det naturlig at ikke de skaper ekstra problemer. Vi har dermed helt uformelt antydet hva som bør være kriteriet for en godt normalisert struktur.

Hovedregelen for normalisering - presis form: En datamodell er godt normalisert dersom 1) alle attributter er atomiske 2) enhver determinant er en kandidatnøkkel.

99

Kap. 7

KORT OM NORMALISERING AV EN DATAMODELL

Denne normaliseringsregelen kalles Boyce-Codds normalform (BCNF), og inneholder som tidligere nevnt kriterier for både 1., 2. og 3. normalform og "litt til". Appendix A har detaljene om dette. Som nevnt i kap. 3.2, er en kandidatnøkkel et attributt(-gruppe) som garanterer entydige verdier innenfor entitetstypen (dessuten må den være irredusiblel, jfr. kap. 3.3.3). Dersom vi ikke har noen andre kandidatnøkler enn identifikator, vil naturligvis regelen forenkles til å si at "identifikator er eneste determinant". Dersom man ikke har noen andre kandidatnøkler enn identifikatoren, vil determineringsdiagrammet se slik ut-

Hvis vi har f.eks. to kandidatnøkler, vil de "determinere hverandre" (Kandidatnøkkel^Kandidatnøkkel2), og vi vil få determineringspiler fra begge disse til alle de andre attributtene. Dette gir imkUertid ikke noen normaliseringsproblemer.

Hvilke determineringer er ikke tillatt ? Her er noen eksempler på ikke-tillatte strukturer:

100

Kap. 7

KORT OM NORMALISERING AV EN DATAMODELL

I normaliseringsteori kalles (1), (2), (3) og (BCNF) for brudd på hhv. 1. normalform, 2. normalform, 3. normalform34 og Boyce-Codds normalform. Siden brudd på 2.normalform og 3. normalform også automatisk er brudd på Boyce-Codds normalform, har vi valgt kun å fokusere på denne siste. For detaljer: se Tillegg A. Slike ikke-helt-normaliserte strukturer vil bl.a. lett føre til unødvendig dobbellagring (redundans) og dermed gi fare for selvmotsigene data (inkonsistenser). Det vil derfor generelt sett være en fordel å unngå dem. I alle disse tilfelle vil løsningen på normaliseringsproblemet være å splitte den ikke-godt-nok-normaliserte entitetstypen i to entitetstyper (i spesielle tilfelle i tre), i praksis med l.m mellom, og kontrollere på nytt at man nå ikke får de samme problemene. Det kan også diskuteres om det er noen krise f.eks. om både postnr og poststed finnes i samme entitetstype som person, og om man ikke bør tillate at ting ikke er helt normalisert. Mitt svar på det er: • Jeg mener at man alltid bør normalisere entitetstypene slik at de oppfyller hovedregelen for normalisering. Dette vil gi en øket innsikt i hvorledes "ting henger sammen". • Om man så skal "denormalisere" igjen dersom man skal gjøre om datamodellen til en databasestruktur, kommer av en rekke forhold, som f.eks. forventet antall poster i tabellene, om de samme verdiene gjentas mange ganger, maskinytelse osv. Vi tar ikke opp dette her.

7.3.

Automatisk normalisering?

Noen databaseverktøy, f.eks. de siste versjonene av Microsoft Access, har en funksjon for å analysere sammenhenger i tabeller og eventuelt foreslå splitting i dataene i to eller flere tabeller på grunnlag av dette. Et slik funksjon kan selvsagt være nyttig, men vi kan aldri fastslå med sikkerhet om noe er dårlig normalisert eller ikke ut fra dataene alene. Slike funksjoner må derfor brukes med stor forsiktighet!

Av det som er sagt over, er det også gitt at man ikke kan få noe verktøy til å gjøre en automatisk normalisering, med mindre du beskriver determineringer mellom de ulike attributter i det samme verktøyet. For de fleste er det imidlertid lettere å oppdage hva som skal gjøres (splitt tabellen i 2 med attributt a og b i en ene og a, c og d i den andre!) enn å formelt beskrive hvilke determineringer som gjelder. Ut fra det som er sagt over, har Modelator ingen mulighet for å oppdage dårlig normalisering. I stedet inneholder systemet en mulighet for overføring av attributter mellom to eksisterende entitetstyper, slik at det er forholdsvis lett å gjøre en utsplitting og normalisering ved å "flytte attributter over til riktig sted". Det kunne imidlertid vært ønskelig på en eller annen måte å markere "brudd på normaliseringsreglene" dersom man valgte å "denormalisere" etter normaliseringen. Dette ville ha verdi i dokumentasjonssammenheng.

34 Under "brudd på 3NF" har jeg tegnet inn postnr -> poststed. Det at en slik struktur ikke er fullt ut normalisert, var grunnen til at jeg ikke har tatt med postnr og poststed i det gjennomgående ANSATTeksempelet - slik at ingen skal kunne si at det settes opp en diskutabel struktur som eksempel!

101

Kap. 8

UTVIKLING AV DATAMODELLER - EN SAMMENFATNING.

8. Utvikling av datamodeller - en sammenfatning. 8.1.

Det språklige aspektet ved datamodellering.

Vi har allerede flere ganger merket den nære sammenhengen mellom vanlig språk og datamodellering. Det er derfor ingen tilfeldighet når slike modeller som vi har laget, kalles semantiske datamodeller, dvs. modeller som bygger på meningsinnholdet i begreper og setninger, og hverken går på de formelle grammatiske (syntaktiske) reglene i språket eller på hvorledes data lagres.

En annen betegnelse som også understreker det samme, er at datamodeller ofte kalles konseptuelle modeller eller begrepsmodeller. Vi skal i dette kapittelet kun ta opp noen eksempler hvor vi viser sammenhengen mellom språk og datamodellering.

Det språklige aspekt - et eksempel.

Svært ofte er det slik at både entitetstyper, relasjonstyper, inkl. max. (ofte også min.) og verbalbeskrivelser, og mange av attributtene kan finnes ut fra en beskrivelse av det område man skal lage en modell for. Derimot er det sjelden at man far ting som identifikator og Nødvendig-egenskapen på direkten. Vi skal se et eksempel på hvorledes en kan plukke ut en datamodell fra en skriftlig eller muntlig beskrivelse.

Vi tar opp ansattsystemet igjen. Vi tenker oss at vi har bedt en av de ansatte å beskrive hva som er interessante data i forbindelse med hver ansatt. En slik beskrivelse (med flere detaljer enn i kap. 1.1) kan kanskje se slik ut: Først og fremst vil jeg si at vårt firma er delt inn i forskjellige avdelinger, hver med sitt avdelingsnummer og avdelingsnavn, og slik at hver ansatt jobber i en og bare en avdeling. Siden vi her snakker om en offentlig virksomhet, er det også av interesse å vite hvilken stillingstype den ansatte er plassert i - dvs. slik at de har en stillingskode og en stillingsbetegnelse. Siden det skjer stadige forandringer både i bemanningen og i det arbeidet vi skal gjøre, er det opprettet faste kurs som de ansatte deltar på. Siden slik kursdeltagelse kan ha betydning for videre utvikling både for den enkelte og for virksomheten, kan det være av interesse å vite årstallet for kursdeltagelsen for den enkelte. Når det gjelder den ansatte selv, har vi valgt å innføre et løpenummer på hver ansatt, i tillegg til at vi selvsagt har med navn, (gate)adresse, telefonnummer, postnummer og det tilhørende poststedet for vedkommende. Det er vel sikkert også mere som er aktuelt, men dette får holde i denne omgangen".

Selv om det vel skinner igjennom at denne historien er konstruert, er det ikke så langt fra vanlig norsk prosa. Vi skal nå disikere" denne beskrivelsen, med henblikk på å se hvorledes det aller meste av det som er skrevet her, kan beskrives på en presis form ved hjelp av en datamodell. Historien kommer derfor ordrett om igjen, men med nummer for henvisning til teksten. I tillegg er sentrale substantiver satt med store bokstaver.

1 2 3 4 5 6 8 9

10

102

"Først og fremst vil jeg si at vårt FIRMA er delt inn i forskjellige AVDELINGer, hver med sitt avdelingsnummer og avdelingsnavn, og slik at hver ANSATT jobber i en og bare en AVDELING. Siden vi her snakker om en offentlig VIRKSOMHET, er det også av interesse å vite hvilken stillingstype den ANSATTe er plassert i - dvs. slik at de har en stillingskode og en stillingsbetegnelse. Siden det skjer stadige forandringer både i bemanningen og i det arbeidet vi skal gjøre, er det opprettet faste KURS som de ANSATTe deltar på. Siden slik KURSDELTAGELSE kan ha betydning for videre utvikling både for DEN ENKELTE og for VIRKSOMHETEN, kan det være av interesse å vite årstallet for KURSDELTAGELSEn for DEN ENKELTE. Når det gjelder den ANSATTe selv, har vi valgt å innføre et løpenummer på hver ANSATT,

Kap. 8 11 12 13

UTVIKLING AV DATAMODELLER - EN SAMMENFATNING. i tillegg til at vi selvsagt har med navn, (gateadresse), telefonnr postnummer og det tilhørende poststedet for vedkommende. Det er vel sikkert også mere som er aktuelt,.....

Kommentarer: Vi ser følgende: • Noen av substantivene kommer alltid i entall (VIRKSOMHET, FIRMA). Disse er dermed ikke grunnlag for abstraksjon i form av en entitetstype. • Andre substantiver komme ofte i flertall, og det er derfor naturlig med en generalisering i form av en entitetstype. (KURSDELTAGELSE kommer riktignok bare i entall her, men ut fra beskrivelsen ellers ser vi at det skal kunne lagres informasjon om flere kursdeltagelser). • I et par tilfelle brukes det forskjellige begrep om det samme (FIRMA = VIRKSOMHET, ANSATT = DEN ENKELTE). • Vi får altså fram mange kandidater for entitetstyper rett og slett ved å se på de sentrale substantiver i teksten. Andre kommentarer: linje 2: .. hver med sitt avdelingsnummer og avdelingsnavn: Vi ser her tydelig at disse to er knyttet til et annet begrep, nemlig avdeling. De er altså ikke selvstendige entitetstyper, men attributter. linje 3: Denne setningen finner vi helt eksakt igjen i datamodellen (både entitetstyper, min, max og verbalbeskrivelsen). linje 5: finner vi også igjen i datamodellen. Legg merke til at vi sier hvilken stillingstype (ikke f.eks. hvilke stillingstyper). Vi kan derfor se at det er snakk om et maksimum på 1. linje 7: Siden det skjer stadige .... Dette er en begrunnelse for hvorfor de eller de tingene er interessante. Dette kommer ikke med i en datamodell. lin. 8/9: Her skjer det en interessant begrepsdannelse, dvs. vi danner et nytt ord, som direkte eller indirekte er forklart tidligere, eller som på en eller annen måte framgår av sammenhengen. Kursdeltagelse defineres som vi ser som "kurs som den ansatte går på", noe som vel er litt upresist, og som kommer klarere fram i datamodeller. linje 12: Postnummer og det tilhørende poststed. Her antydes det at postnummer og poststed "hører sammen", og dermed at de kanskje skal samles i en egen entitetstype. (En slik antydning kommer nok sjelden på denne måten i praksis !) line 13: Beskrivelsen blir sjelden fullstendig....

Hvilken datamodell kan vi trekke ut fra beskrivelse? Det skulle vel være i samsvar med det meste av den modellen vi allerede kjenner godt til:

Det er kanskje overraskende at noen av de delene som vi har tatt for gitt, strengt tatt ikke kan leses ut fra beskrivelsen vi har sett på, jfr. spørsmålstegnene i modellen over. Antagelsen om at postnr og postnavn hørte

103

Kap. 8

UTVIKLING AV DATAMODELLER - EN SAMMENFATNING.

sammen og burde splittes ut, og navnet POST er også antagelser / egen navngivning. I praksis vil vi ofte kunne fylle ut slike hull ut fra den kunnskapen vi har om saksområdet, eller ut fra gjetning. Vi bør imidlertid være oppmerksom på usikkerheten som ligger i dette, idet vi lett ubevisst kan legge inn forutsetninger som ikke nødvendigvis er sanne. Dette kan være farlig ! For en diskusjon av begrepsmodeller hvor også handlinger og videre aspekter av språket trekkes inn, henvises til John F. Sowas bok "Conceptual Structures. Information Processing in Mind and Machine" (Sowa 1984). Boka integrerer stoff fra filosofi, psykologi, informatikk, matematikk, naturlige språk og kunnskapsbaserte systemer på en svært interessant måte. To andre eksempler på sammenhengen mellom datamodeller og språk, helt kort:

Ord med flere, hierarkisk ordnede betydninger.

Jeg henviser til kap. 3.8, hvor det beskrives en rekke flertydigheter med begrep, bl.a. hvorledes ordet Vare kan ha minst 4 forskjellige betydninger, som er på forskjellige generaliseringsnivåer. Her vil datamodeller kunne hjelpe til å avsløre flertydigheter i språket.

Utsagn med 3 ledd som ikke kan splittes.

I kap. 6.7 tok vi opp problematikken omkring setninger som beskrev forhold mellom tre begreper:

"Hver ansatt kan jobbe i flere avdelinger.... For hver avdeling som den ansatte jobber i, skal vedkommende være ansatt i bare en stillingstype." Den siste setningen kan vi ikke klare å uttrykke hvis vi deler den opp i flere mindre deler som inneholder bare to og to av begrepene ansatt, avdeling, stillingstype. Dette var eksakt grunnen til at vi ikke klarte å beskrive den direkte i vår datamodelleringsdialekt, som forutsetter at relasjonstyper alltid skal være binære (dvs. toleddede). Vi hadde altså en m:m:m-situasjon.

Den eneste muligheten for å splitte den opp, er ved å "finne på et nytt ord", f.eks. beskjeftigelse, og så beskrive regelen ut fra denne. Dette trikset bruker vi stadig i naturlig språk også: Vi forklarer eller definerer nye begreper ut fra gamle, og bruker de nye begrepene i den videre forklaringen. Dermed får man redusert kompleksiteten i vanlige norske setninger.

Til slutt: Jeg har påstått at datamodellering/begrepsmodellering først og fremst har med språk å gjøre. Jeg utfordrer derfor norsklærere til å ta opp dette temaet i sin undervisning !!

8.2.

Arbeidsgangen med datamodellering.

Vi skal her forsøke å sammenfatte en anbefalt framgangsmåte for hvorledes man utvikler datamodeller. Det bør imidlertid pekes på at en slik utviklingsprosess først og fremst er en iterativ prosess, hvor man stadig går tilbake til tidligere arbeide som er gjort og sammenholder det med problemstillingen, eventuelt forsøker å finne / spørre om nye opplysninger om den virkeligheten man skal beskrive osv. Det følgende må derfor bare ses på som en grovskisse, og skillet mellom de forskjellige deler vil derfor være litt tilfeldig. Vær oppmerksom på at denne oppdelingen er min egen, og jeg er overbevist om at andre ville kunne gjøre oppdelingen noe anneledes.

1. •

104

Grovutforming av modellen.

Finn de opplagte entitetstyper fra problemstillingen sammen med opplagte relasjonstyper mellom disse.

Kap. 8 •

• •

•

•

2.

• • • • • •

UTVIKLING AV DATAMODELLER - EN SAMMENFATNING.

For relasjonstyper: • Legg på verbal- eller rollebeskrivelser, i alle fall der det kan være noe tvil om hva relasjonstypen gjelder. • Vær spesielt oppmerksom på tidsdimensjonen for hver relasjonstype, og dokumenter gjeme dette via verbalbeskrivelser. • Vent gjerne med minimum, i alle fall der hvor dette ikke er opplagt. Når den grafiske modellen begynner å finne form slik at man ikke regner med mye forandringer på denne, legger man etterhvert inn "opplagte" attributter35. "Opplagte" identifikatorer kan gjeme også markeres. Gå gjennom problemstillingen og punktene over på nytt, og bruk bl.a. entitetisering for å få fram nye entitetstyper, relasjonstyper og attributter. Dersom man jobber relativt nøye med en slik grov-utforming, får man fram de aller fleste entitetstyper og relasjonstyper, og dermed en modell som er relativt stabil. Som nevnt tidligere: hvis man legger mye arbeide i denne delen av utviklingen, vil som regel attributtene "falle på plass av seg selv". Siden relasjonsdatabaser og datamodeller ligger såpass nærme hverandre i grunnfilosofi, kan det også være lurt å "skifte pespektiv" mellom disse. Hvis man er i tvil om en struktur, så tegn opp en liten database med noen poster i, og se om du på den måten kan fa ytterligere klarhet.

Finutforming av modellen.

Sett på minima der hvor dette ikke er gjort. Legg inn eventuelle ytterligere attributter som må være med ut fra problemstillingen. Legg inn identifikatorer og fremmednøkler. (Som tidligere nevnt vil ofte fremmednøkler brukes som en del av identifikator, og det er derfor praktisk å ta disse to tingene samtidig.) Ofte vil en slik finutforming av modellen føre til at man må lage,nye entitetstyper for å få en normalisert modell. Ta for deg hver enkelt entitetstype og kontrollsjekk at det ikke finnes normaliseringsproblemer. M:m-relasjonstyper som ikke behøver å splittes for å få med nye attributter, kan vi gjerne beholde på m:mform.

Dersom modellen skal kunne overføres direkte til en relasjonsdatabase, må det gjøres en del tilpasninger:

3. • • •

• •

•

Tilpasning til overgang til relasjonsdatabase.

Dersom datatype- og beskrivelse av Nødvendig-egenskapen ikke er gjort tidligere, må dette spesifiseres. Av og til bør man gjøre en "denormalisering", dvs. sammenslåing av entitetstyper som gjør at modellen ikke lenger er normalisert fullt ut, bl.a. for å få til en tilstrekkelig rask søking i databasen.36 Man bør vurdere andre tilpasninger. En typisk tilpasning er at avledede attributter av og til likevel bør tas med som fysisk attributt/felt i databasen, for dermed å slippe å gjøre samme type beregninger (f.eks. summeringer) en rekke ganger. Et slikt ekstra felt vil gjøre at ting går raskere, men til gjengjeld må programmer rundt databasen sørge for å "holde summen korrekt" til enhver tid. Eventuelle gjenværende m:m-relasjonstyper må splittes. Dette er en rent mekanisk prosess. Spørsmål om indekser (litt forenklet sagt: sorterte hjelpefiler) o.l. er aktuelt å ta opp. I versjon 4 av Modelator kan indekser settes opp sammen med datamodellen. Dessuten kan systemet generere indekser automatisk på alle fremmednøkler m.m. Det kan også være rene tilpasninger til spesialiteter for det databasesystemet man velger.

35 Jeg forutsetter her at man ikke bare skal ha en overordnet modell på entitets- og relasjonstypenivå. 36Det kan virke unødvendig å normalisere først, deretter eventuelt å "denormalisere" etterpå. Saken er imidlertid at man ved normaliseringen får fram en meget presis beskrivelse og dermed også bedre forståelse av virkeligheten. Hvis man senere denormaliserer, vet man nøyaktig hvilke konsekvenser dette har, og dermed kan man f.eks. programmere sjekker som kontrollerer at man ikke får inkonsistenser i databasen. Generelt gir en slik denormalisering mere arbeide i en utviklingsfase, og gjør også at databasestrukturen kan bli vanskeligere å endre senere.

105

UTVIKLING AV DATAMODELLER - EN SAMMENFATNING.

Kap. 8 4.

Overgang til databasesystem.

Her vil f.eks. Modelator kunne hjelpe deg til en automatisk generering. Det vil likevel ofte være noen spesialtilpasninger som man vil ønske å gjøre i selve databasesystemet.

Som vi ser, er flere av forholdene under 3 begrunnet i hastighet. Ved slike tilpasninger vil det derfor være forhold som ligger utenfor selve datamodellen som er bestemmende. De viktigste av disse er: • hvor store datamengder man vil få i databasen. • om man arbeider på et nettverk som gjør at aksessering går tregere. Hvis flere personer skal kunne jobbe mot databasen samtidig, vil dette kreve ekstra hensyn - dette kalles gjerne samtidighetsproblematikk. • hvor rask maskinen(ene) er. Det kan godt være at man av ytelseshensyn "må" gjøre en denormalisering hvis systemet skal gå på en "treg" maskin, mens det på en raskere maskin er unødvendig. • hvor "tunge" koblinger man kommer til å foreta, og hvor ofte de foretas.

Problemstillinger av denne typen er viktige for design av omfattende databaser. Som vi har sett, er nettopp noe av hovedsaken i forbindelse med datamodeller at man ikke skal konsentrere seg om implementasjonsorienterte detaljer. Vi tar derfor ikke opp disse temaene ytterligere.

Illustrasjon av utviklingsprosessen. Utviklingsprosessen kan dermed illustreres slik:

De stiplede pilene viser at også når man stort sett er ferdig med grovarbeidet innen en av disse, må man av og til ga tilbake p.g.a. endringer som følger at man se flere detaljer etter hvert som modellen tar form. Dersom man •e s. regner seg temmelig ferdig med entitets- og relasjonstypenivået, vil de fleste attributtene komme "falle på p ass' i de riktige entitetstypene. Dersom ikke det er mulig, bør man sjekke om problemet kan løses ved å legge ti eller endre en relasjonstype. Dersom ikke det går, må man legge til en ny entitetstype og antagelig nye relasjonstype(r) før man kan finne fornuftig plassering av det eller det attributtet. En siste bemerkning til overgang fra datamodell til relasjonsdatabase, er at denne overgangen samtidig er et skifte av begrepsapparat:

Datamodell Entitetstype

Relasjonstype

Attributt

Identifikator

106

Database Tabell,———————

Fil, Relasjon (forsvinner, men fremmednøklene gjør nesten samme nytten) Kolonne, Attributt, Felt Primæmøkkel

Kap. 8

UTVIKLING AV DATAMODELLER - EN SAMMENFATNING.

Parallelt med utviklingen av modellen, er det viktig at man gjør en stadig dokumentasjon underveis, bl.a. • forutsetninger som man legger til grunn • skriftlig definisjon av entitetstyper, attributter, evt. også relasjonstyper. Vi har i denne beskrivelsen tatt "problemstillingen" for gitt, som en fast og klart avgrenset helhet. 1 praksis er dette langt fra tilfelle. Det mest vanlige er at: • problemstillingen er langt fra klarlagt • grensen mellom hva som er "innenfor" og hva som er "utenfor" den aktuelle problemstillingen er uklar. • forskjellige personer og grupper har forskjellig syn på problemstillingen, ønsker og hva som er grensen for det aktuelle systemet. • samme personer og grupper vil gi forskjellig svar på de samme spørsmålene til forskjellige tider. • problemstillingen endrer seg etterhvert som modellerings-prosessen skrider fram.

Et av de viktigste elementer i en datamodellerings- (og annen system- og organisasjons-) utviklingsprosess, er en læringsproses som både • systemutviklere • brukere/oppdragsgivere • organisasjonen som sådan (organisasjonslæring) går gjennom.

8.3.

En enkel utviklingsmodell.

Prototyping og datamodellering.

Det å utvikle en datamodell er ofte en iterativ prosess, dvs. at man gjør de samme prosessene flere ganger, men at man stadig finner nye ting i hver "runde". Hvis man skal ende opp med en database, vil det ofte lønne seg å gå helt til generering av databasen, slik at man kan legge inn noen data i den foreløpige databasen, vinne erfaringer osv., for så å gå tilbake til datamodellen og gjøre endringer ut fra de erfaringene man har gjort. Dette er et eksempel på det som i systemeringsfaget kalles for eksperimentell systemutvikling. En to-tre gangers prototyping vil kunne hjelpe mye i så måte.

"Reverse engineering"

Mange sitter med eksisterende databaser, og har behov for å dokumentere disse i form av en datamodell. Årsakene kan være mange, bl.a. • Nye krav til dokumentasjon av "alt" som finnes av systemer i firmaet. • Behov for endring/videreutvikling, og man må dermed se hva som "egentlig er gjort", kanskje av andre personer. • Systemet skal legges over på en annen plattform, f.eks. et annet databasesystem. Dette betyr kort sagt at det er et behov for å gå motsatte veien, eller å foreta en såkalt reverse engineering:

107

Kap. 8

UTVIKLING AV DATAMODELLER - EN SAMMENFATNING.

Erfaring har vist at det å lage en datamodell av en eksisterende database gir mye innsikt i hvorledes denne er bygd opp, og ikke minst, hvilke tabber man gjorde da man konstruerte databasen første gang. Derfor fører ofte også en reversering til at man går tilbake til databasen og retter opp strukturen i denne - som vist med den prikkete linjen over.

En enkel utviklingsmodell.

Disse to delene kan slås sammen til en enkel utviklingsmodell som kan anvendes i databaseorientert systemutvikling:

MODELLERING/ .................. PROTOTYPINCJ.

læring, feiloppdaging m.m.

I modellering/prototyping er det datamodelleringen som er i fokus, men man kan generere en prototype eller flere for å se om det man gjør er riktig - m.a.o. at man veksler mellom totaloversikten som datamodellen gir og det mer detaljerte og konkrete i databasen (bl.a. ved å legge inn noen få testdata).

I utvikling/feilretting arbeider man i databasesystemet. Hvis man gjør forandringer i strukturen, kan det lønne seg å gå tilbake til en datamodell og se på hva som er gjort. Eventuelt kan man gå via en datamodell dersom det er snakk om å bytte databaseplattform, se prikket rektangel til høyre i figuren. I Modelator har man både mulighet til å gjøre en generering og en reverse engineering og til å lage en sammenligning mellom ulike versjoner av en datamodell eller en database. Dermed kan man få ut en endringsrapport som viser hvilke forandringer som har skjedd med databasen siden sist gang man hadde en modell av den. Dette er svært nyttig bl.a. når man arbeider i et prosjekt, og dermed kan dokumentere hvilke endringer som er gjort, f.eks. i forbindelse med prosjektmøter.

108

Kap. 9

DATAMODELLER OG KONSTRUKSJON AV SKJERMBILDER.

9. Datamodeller og konstruksjon av skjermbilder. Skjermbilder i et system bygges gjerne opp på grunnlag av datamodellen. Det typiske er at man • bygger skjermbildet med utgangspunkt i en entitetetstype som er sentral for den behandlingen som skal gjøres. • i tillegg plukker attributter fra direkte eller indirekte relaterte entitetstyper. • ofte har med summeringer o.l. som gjelder denne eller relaterte entitetstyper. • ofte har med dato el.l. som hentes automatisk fra datamaskinens klokke.

I moderne grensesnitt (Windows-type) bruker man ulike grafiske objekter i skjermbildet. En vanlig måte å designe skjermbilder på er denne (den sentrale entitetstypen er her kalt Utgangspunkt):

1-er-retning: komboboks Bruk komboboks for å vise/velge en verdi i A.

Bruk tekstboks for å vise verdier i entitetstypen du har utgangspunkt i.

Mange-retning: listeboks Bruk delskjema på tabellform, listeboks el.l. for å vise/velge blant alle relaterte verdier i B.

La oss ta et enkelt eksempel, et skjermbilde for å fylle ut eller endre data om en ansatt og de kurs vedkommende har tatt. Vi tar utgangspunkt i ANSATT - med forenklet skjermbilde:

vanlige" attributter

fremmednøkler + felt hentet fra relatert entitetstype (stillingstype / avdeling)

hentes fra relatert (kursdeltagelse)

rent beregningsfeil

Noen fa kommentarer:

109

Kap. 9 •

• • • • •

DATAMODELLER OG KONSTRUKSJON AV SKJERMBILDER.

De grå feltene er rene oppslag eller beregninger, og som derfor ikke skal kunne endres. For oppslagene er det rett og slett snakk om at de determineres av de andre attributtene, nemlig Stillkode Stillbetagnelse, Avdkode + Avdnavn og Kurskode -> Kursnavn. For å kunne navigere oppover eller nedover i strukturen, har vi brukt små 3', både på 1-siden (for å gå

"oppover" i strukturen) og på mange-siden (for å se på detaljene i den aktuelle posten på mange-siden). Skulle det være flere underordnede, kan de f.eks. hver få si egen kategori (fane, flik), slik det er vanlig å kunne lage i moderne verktøy. Prinsippene over kan tenkes på som generelle design-prinsipper, det vil gjøre at man sentrerer seg om en ting pr. skjermbilde, samtidig som man har mulighet til lett å gå til relaterte data. Totalt antall kurs er muligens noe kunstig her. I andre sammenhenger er den imidlertid helt realistisk, f.eks. som en sum av beløp for alle ordrelinjer som hører til en ordre. En annen ting som er kunstig med dette eksempelet, er at skjermbildet omfatter attributter fra alle entitetstypene i modellen. Det sier seg selv at det ikke vil være tilfelle for en litt større modell.

Forskjellige 4. generasjonssystemer er forskjellige med hensyn til fleksibiliteten i et slikt skjermbilde. Eksempler på forskjeller: • Om man kan taste inn data fra forskjellige entitetstyper i samme skjermbilde (slik det er forutsatt med kursdeltagelse her). • Om man kan gå fra et skjermbilde til et annet under inntastingen, f.eks. hvis man taster inn et avdelingsnr som ikke Finnes fra før. Her Finnes forskjellige muligheter: • systemet oppdager ikke at det er et nytt avdelingsnummer (manglende referanseintegritet) • systemet sier på en eller annen måte fra at det er ukjent og gir mulighet for å velge et skjermbilde for inntasting av avdelingsdata. • systemet går automatisk til skjermbilde for avdelingsdata. • avdelingsdata kan fylles inn direkte i dette skjermbildet, og legges inn i relaterte filer. • Graden av programmering som eventuelt er nødvendig for å få til slikt, varierer også fra system til system • Om summer og beregning, som f.eks. antall kurs totalt lett kan legges inn slik at beregningen følger med når data endres.

Ofte tar vi det samme utgangspunktet ved laging av rapporter, men her vil gruppering av data gjeme stå mer sentralt. For et større firma som driver med (masse-)saig, er vi neppe interessert i en rapport som gir detaljene pa hvert salg. Vj vil antagelig gruppere alle salgene innenfor en vare, innenfor et tidsrom eller lignende.

Det er en kjent sak at skjermbilder kan være effektive til å finne fram endel av de behov en bruker har f.eks. i forbindelse med et administrativt system. Vi vil imidlertid advare mot å bygge en applikasjon ut fra enkeltskjermbilder som en bruker eller brukergruppe foreslår. Grunnen til dette er at man i et slikt tilfelle risikerer å konsentrere seg for mye om én måte å bruke data på, i stedet for å gjøre en analyse av hvilke data en trenger totalt sett, og hvorledes disse data henger sammen. Når man har denne oversikten, er det som vi har sett lett å lage forskjellige skjermbilder mot brukeren.

110

Kap. 10

DATAMODELLER - PÅ KURS OG I VIRKELIGHETEN.

10. Datamodeller - på kurs og i virkeligheten. Vi skal her kort ta opp en del forhold omkring datamodellering slik den skjer i praksis, og hvorledes den skiller seg fra det vi har sett på i denne boka. Jeg vil peke på følgende punkter:

1)

Størrelsen på prosjektene. Mens vi i en øvelsessammenheng har jobbet med små modeller (la oss si fra 4-5 og opp til en 10-15 entitetstyper), vil mange av de datamodellene som trengs for å beskrive selv mindre deler av en virksomhet fort ende opp i ganske mange titalls entitetstyper. Et tall på f.eks. 30-60 entitetstyper regnes i ofte som en for et "passe stor" modell for et delområde. Det finnes imidlertid eksempler på modeller for større virksomheter med mange hundre entitetstyper37.

2)

Antallet attributter pr, entitetstype.

Mens vi her gjeme har hatt 3-4 attributter pr. entitetstype, vil endel av entitetstypene for reelle virksomheter ha 10 - 20 og av og til enda flere attributter. Jeg har sett bortimot 100 i noen tilfelle, men det er neppe å anbefale, og har sannsynligvis mange brudd på normaliseringsprinsippene. 3)

Unntakene utgjør de fleste problemene.

Den aller største delen av modellen skyldes at man må ha mulighet for å takle lite brukte særtilfelle, endringer, feil av forskjellig slag osv. 4)

Vanskeligheten med å få ensartede begreper, en felles begrepsforståelse osv.

I en øvelsessammenheng arbeider vi med relativt velavgrensede problemstillinger, og hvor man på forhånd har prøvd å klargjøre begreper osv. I praksis har svært mange begrep uklare betydninger, overlappende betydninger og forskjellige grupper bruker samme begrep i litt forskjellig betydning. Det fortelles om et forsikringsselskap som i forbindelse med en datamodell ville lage en presis beskrivelse av begrepet polise. Etter adskillige timer ga de opp, det var altfor komplisert ! Dette, sammen med manglende tid til å jobbe gjennom problemstillingen, er kanskje den største vanskeligheten i praksis. Det at det er vanskelig å finne fram til en ensartet språkbruk osv. skulle ikke være noe argument mot å bruke datamodellering som et ledd i en system- eller organisasjonsutvikling. Snarere er det vel slik at disse problemene viser nødvendigheten av å forsøke å få fram en felles begrepsforståelse osv.! 5)

Sjelden entydige hierarkier.

Et eksempel: I et større firma har vi en oppdeling i divisjoner, som igjen er delt i avdelinger (1 :m), hvor det jobber flere ansatte (1 :m). Dette gir en enkel modell. Imidlertid finnes det også noen ansatte som er direkte knyttet til divisjonen, uavhengige av avdelinger. I tillegg har man også noen produksjonsavdelinger som er felles for flere divisjoner... 6)

Kommentarer på mange av entitetstypene.

Det er ofte en god idé å legge inn en kommentar på mange av entitetstypene, ofte kombinert med en dato, slik at man kan lage en fritekst på ting som har skjedd med eller hva som er spesialitet med den eller den bestemte forekomsten. Ofte legges det også egne Endret av og Endret_dato, for å kunne spore de siste endringer med den bestemte forekomsten.

37Ved å antyde tall i denne sammenhengen står en selvsagt i fare for å bli misforstått til at en modell for slik og slik bør inneholde så og så mange entitetstyper, relasjonstyper og attributter. Dette er selvsagt ikke tilfelle, jeg angir bare tall som temmelig realistiske i forhold til praksis. 111

Kap. 10

7)

DATAMODELLER - PÅ KURS OG I VIRKELIGHETEN.

Hensyn til lagring av gamle data. På tross av f.eks. bruk av statusattributter, vil det ofte være behov for å flytte over "gamle data" (eventuelt kun for utvalgte attributter) til andre tabeller for varig lagring av historikk. Dette tas det gjeme ikke hensyn til i datamodeller.

8)

Hensyn til / problemer med tidligere klassifiseringer og strukturering.

Selv om vi har funnet en fornuftig måte å identifisere f.eks. varer på, er det ikke sikkert at den passer med tidligere klassifisering. Hva hvis vi slår sammen to bedrifter og må samordne varenummer - og helst kunne finne ut både via de gamle og de nye nummer. Hva med utgått kontotyper i en bank? Et annet eksempel fra et helt annet område: Anta at du etter OL i 2000 skal lage en presis oversikt over plasseringer for de forskjellige land i OL de siste 20 årene. Hva gjør du med idrettsmenn fra det tidligere Sovjet-Unionen? Skal de fordeles etter den staten de nå bor i (Russland, Ukraina, Kazakstan osv.)? Hva med personer fra Estland? Hva med personer fra Scotland, som i visse sammenhenger regnes som et eget land? 9)

Mindre presis domenebeskrivelse. Man må ofte bruke en mindre presis domenebeskrivelse enn ønskelig. Et par eksempler: Vi legger opp postnummer med 4 siffer - som kjent er Oslo også etterhvert innordnet i dette. Så kommer det første behov for å lagre et svensk postnummer - med 5 siffer. I England er postidentifikasjonen helt anneledes, bl.a. med mye bruk av bokstaver. Hva med ulike former for telefonnummer i forskjellige land? I USA tillater man t.o.m. bokstaver i telefonnummeret (selv om det egentlig er tall..). Konklusjonen på begge disse enkle eksemplene, er at man antagelig må tillate alle tegn (tekst / character / alfanumerisk) i begge disse tilfellene. Slike forhold finnes det mange av i praksis.

1°)

Nesten ikke-normaliserte entitetstyper. En av de mest brukte oppgaver i en kurssammenheng er "Lag en datamodell som viser kunder, hvilke ordre hver kunde plasserer...... Løsningsforslaget blir gjerne Kunde

Dersom man hadde tatt med Kundenavn, Adresse osv. som attributter på ordre, ville man ha fått en struktur som ikke er normalisert, og dette bør unngås..... Kundenavn Som løsningsforslag på en oppgave er dette en riktig løsning ut fra forutsetningen om at Kundenavn osv. kan leses fra kunden. plasserer * I praksis vil slike systemer imidlertid så og si måtte inneholde Kundenavn, Adresse osv. på ordren, fordi man i noen tilfelle ønsker å ha en annen Ordre adresse enn den vanlige. Hvis kunden flytter, vil vi vel likevel beholde gamle kundenavn, adresser osv. på gamle ordre. 1 praksis kan vi antagelig Ordrenr determinere de aller fleste kundenavn, adressser osv. i ordren fra Ordredato kundenavnet i ordren - men siden vi ikke kan determinere alle er det ikke gjort noe brudd på normaliseringen. Den fornuftige måten å gjøre dette på i et praktisk system, er naturligvis at Kundenavn, Adresse osv. hentes fra kunde i det man lager en ny ordre, men at dette kan overskrives, jfr. også kap. 6.4.1. Kundenr

11)

Delsystemer, tilstøtende systemer.

Systemene som skal lages, blir så store at man må dele det i delsystemer, og med tildels kompliserte grensesnitt. I andre tilfelle er svært mye av problematikken at mye av de data som man skal ha i det nye systemet også delvis finnes i andre systemer. Hvor skal da grensen mellom det nye og de gamle systemene gå? Må vi ta en total redesign av "bedriftens totale datamodell"?

112

Kap. 10 12)

DATAMODELLER - PÅ KURS OG I VIRKELIGHETEN.

Kun del av en total systemutvikling / org.utvikling. Datamodellering er bare en liten del av en system- eller organisasjonsutvikling, og må samordnes med andre perspektiver og med manuelle rutiner. I praksis vil man i dag ofte bruke teknikker fra objektorientering som en del av en slik beskrivelse, evt. bruke datamodellering som en av flere innfallsvinkler til å lage en objektorientert modell. Ulike personer har ulike preferanser i så måte.

13)

Oppgavene er allerede "halvtyggede". Se innledningen til oppgavesamlingen.

Min erfaring er også at mange ikke gjør en god nok datamodelleringsjobb i forbindelse med systemutvikling. Svært typiske trekk ved slik det ofte skjer i praksis, er: • datamodellen ses kun på som en databasebeskrivelse. Man tar umiddelbart utgangspunkt i "hvorledes skal databasen se ut", evt. "hvorledes skal skjermbildene se ut", i stedet for å ta utgangspunkt i den virkeligheten som man vil beskrive. Et vanlig symtom på dette er at man kaller entitetstypene f.eks. for ANSATTFIL, AVDELINGSFIL (evt. -REGISTER) osv. • man "gidder ikke" å ta med verbal- eller rolle-beskrivelser, minima osv. Hvis dette er bevisst ut fra målet med datamodelleringen, kan det godtas. Imidlertid vil slike utelatelser ofte føre til at man ikke får den innsikt i problemstillingen som skulle vært ønskelig. • hvis datamodellen skal være utgangspunkt for konstruksjon av en database, er det lett for å bli utålmodig. Det blir derfor lett til at man lager databasestrukturen i databasesystemet før man egentlig har full oversikt på modellnivå. Det som er typisk i denne forbindelse, er at man starter med svært gode forsetter, men ikke helt klarer å følge opp etterhvert. • mange har problemer med mer komplekse strukturer, f.eks. der vi må foreta en entitetisering av 3 eller flere relasjonstyper. • kunnskaper orn normalisering er ofte mangelfulle. Dette er kanskje ikke så kritisk dersom man likevel lager modeller som er godt normaliserte. Vi ser imidlertid også eksempler hvor en manglende normalisering fører til håpløse strukturer.

På tross av dette vil jeg trygt kunne si at man vil kjenne svært godt igjen de fleste av de problemstillingene som er tatt opp.

113

Kap. 11

ANDRE DATAMODELLERINGSDIALEKTER

11. Andre datamodelleringsdialekter Når vi tar opp to andre datamodelleringsdialekter, er det først og fremst for å kunne se at ting også kan gjøres på en annen måte, og for at du skal kunne samarbeide med personer som er vant til en annen notasjon. Du vil forhåpentlig også se at kunnskaper om den ene dialekten ofte kan overføres i en annen. Formålet er ikke å gi en fullstendig innføring i de andre dialektene, og derfor er begrepsapparat etc. fra disse holdt på et minimumsnivå.

11.1.

Variasjoner innenfor vår dialekt.

Innenfor vår kråkefotorienterte dialekt finnes det noen variasjoner. Vi skal se på noen av dem under, uten å gi en fullstendig oversikt.

Kosmetiske endringer. Noen av dem er rent kosmetiske, i den forstand at det kun er utseendet på grafen som er anneledes. Eksempelvis kan minima og maksima vises på ulike måter. Noen eksempler:

b) pil og dobbeltpil

c) Antall

d) "kan/må

Disse er alle tegnet i Modelator, hvor en modell tegnet i en notasjon automatisk kan tegnes om i en annen notasjon. Dette viser jo med all tydelighet at forskjellen kun gjelder presentasjonslaget av en modell. Den eneste som kanskje trenger litt forklaring er den siste, hvor "kan"-delen er stiplet, mens "må"-delen er heltrukket strek. En avdeling kan (—-) ha mange ansatte, en ansatt må (------ ) jobbe i en avdeling.

Reiatering enten til den ene eller til den andre entitetstypen. I noen situasjoner er det behov for å tegne at en relasjonstype enten går til en entitetstype eller til en annen, men i e begge samtidig, eller at hvis den går til en, så må den også gå til den andre. Noen varianter av ER tillater en slik beskrivelse. En vanlig form er:

Buene er lagt til etterpå. Vi kommer tilbake med eksempler på slike situasjoner i forbindelse med NIAM, kap.

114

ANDRE DATAMODELLERINGSDIALEKTER

Kap. 11

Undertyper Av og til ønsker man å kunne uttrykke subtyper/undertyper av en entitetstype. Det kan f.eks. gjøres med at man tegner en entitetstype inni en annen. Eksempelet under skulle være illustrerende nok: • Ansatt kan enten være fast ansatt eller midlertidig ansatt. Man kan dermed ha en del felles attributter for Ansatt, og ulike tilleggsattributter for de to undertypene. • Fast ansatte må være tilknyttet en avdeling, de midlertidige ansatte er uten avdelingstilhørlighet.

Problemet er at dette kan omformes på flere ulike måter i en relasjonsdatabase. Noen vil se det som en fordel at at man beskriver systemet på logisk nivå, uavhengig av implementasjon, mens andre synes dette er unødvendig.

En mulig implementasjon av dette er:

Felles attributter legges i Ansatt, de spesielle i hhv. Fast ansatt og Midlertidig ansatt. Modellen beskriver imidlertid ikke at den den ansatte enten er fast eller midlertidig, men ikke begge deler.

En annen implementasjon er at attributter for både faste og midlertidig finnes i en felles Ansatt, og at det er minimum 0 fra Ansatt til Avdeling. Man må da på annet vis kontrollere hva som skal fylles ut for faste hhv. midlertidige, og at alle som har ansattkode = fast (og bare de) må være koblet til en avdeling.

Implementasjonen vil avhenge bl.a. av hvor mye som er felles for faste og midlertidig ansatte.

11.2.

Chen’s opprinnelige notasjon.

Vi skal her bare peke på noen få hovedforskjeller mellom vår notasjon (som er den vanlige bl.a. her i Norge) og den opprinnelige definisjonen fra Chen. Grafene er tegnet i Word (uffamegl), men det finnes også datamaskin­ baserte verktøy for denne dialekten.

De to hovedforskjellene vi tar opp er at • relasjonstyper kan ha attributter • det er et skille mellom selvstendige entitetstyper og avhengige entitetstyper (sterke og svake entitetstyper).

En forenklet del av ordresystemet er alt som skal til for å illustrere dette (bare noen få attributter er tatt med).

115

Kap. 11

ANDRE DATAMODELLERINGSDIALEKTER

Vi ser en rekke forskjeller mellom vår notasjon og Chens notasjon: • at relasjonstypen gjeme skrives som 1 hhv. m i stedet for en kråkefot • at man ofte har med attributtene i grafen, tegnet som ovaler • at de doble strekene viser "minimim 1", altså f.eks. at en Ordre må gjelde minimum en Kunde Dette er imidlertid ting som godt kan gjøres innenfor vår ER-dialekt, og som dermed ikke danner noen pnnsippiell forskjell. Underpunktene under beskriver de to hovedforskjellene som vi nevnte tidligere

Relasjonstyper har et eget symbol og kan ha egne attributter.

Relasjonstypene er, som vi ser, illustrert med et eget symbol, en rombe, og gitt et eget navn. Dette virker unødvendig tungvindt ved 1 :m, slik som for Kunde-Ordre (kunne eventuelt vært kalt Ordreplassering el 1) og for Kunde-Kundekontakt. * 5 Det at man har et eget symbol for relasjonstype gjør imidlertid at man kan legge atttributter direkte på disse, slik som vjst for Ordrehnje. En m:m behøver dermed ikke å entitetiseres, men man kan sette opplysninger som gjeJder forholdet mellom de to opprinnelige entitetstypene direkte på relasjonstypen. Blir relasjonstypen "for innviklet , f.eks. fordi det finnes underliggende entitetstyper under denne igjen, må man imidlertid foreta en entitetisering ay denne. Det kunne f.eks. være at ordrelinjen kunne deles opp i flere dellinjer. Dersom man ikke entitetiserte ville man fått to relasjonstyper relatert til hverandre, noe som ikke er lovlig. For 1 m er det i ikke aktuelt a sette på egne attributter på relasjonstypene.

Det at relasjonstypen har et eget symbol, betyr også at det er lett å tegne relasjonstyper av høyere ordren, jfr. kap. 6.7.1. Eksempelet med Avdeling, Ansatt og Stillingstype-koblingen kunne dermed tegnes:

Avdeling 1

116

Kap. 11

ANDRE DATAMODELLERINGSDIALEKTER

En utvidelse til 4 eller flere roller er også uproblematisk. Eventuelle skranker mht. tillatte kombinasjoner måtte i tilfelle vises via at fremmednøklene inngår i identifikatoren, som for vår notasjon. Svake entitetstyper.

Kundekontakt er en svak entitetstype, fordi den er avhengig av Kunde for å eksistere. Fjernes en gitt Kundeforekomst, må også tilhørende Kundekontakt-forekomster Qernes. Dette vises med det dobbelte rektangelet. Det er Kunde-Kundekontakt som gjør Kundekontakt svak, og dermed er denne relasjonstypen også svak, som vist med den doble romben. Vanlige entitetstyper kalles naturlig nok for sterke.

Noen andre forskjeller. Chen’s notasjon tillater repeterende attributter (som hos oss måtte splittes i 1 :m), og at attributter kan være sammensatte. De utvidelsene som er nevnt i 11.1 finnes også i noen beskrivelser av Chens notasjon.

Vurdering - Chen's notasjon.

•

•

•

•

Notasjonen har utvilsomme fordeler m.h.t. å håndtere relasjoner av høyere orden. Imidlertid er det da et definisjonsspørsmål når relasjonstypen er såpas komplisert at den bør entitetiseres, og dermed forsvinner den egentlige forskjellen mellom entitets- og relasjonstyper. Det er mindre klar sammenheng mellom Chen’s notasjon og relasjonsdatabaser. Dette vil noen se som en fordel dersom språket på en mer naturlig måte beskriver virkeligheten - men det er kanskje tvilsomt om denne notasjonen med sine romber blir betraktet som mer naturlig. Andre vil se det slik at en nær sammenheng mellom datamodelldialekten og relasjonsdatabaser er en stor fordel. Dialekten er antagelig vanskeligere å lære for en nybegynner. Det er antagelig lettere å få en som begynner med datamodellering til å forstå en 1 :m med kråkefot enn det er å ha en rombe for å fortelle at det er en relasjonstype mellom det eller det. Begrep som svake entitetstyper er også med på å gjøre dialekten vanskeligere å forstå i begynnelsen. Grafene blir større, og dermed mindre oversiktlige p.g.a. alle rombene.

11.3.

NIAM/ORM

NIAM og ORM står for henholdsvis • Nijssens Informasjons Analyse Metode og • Object Role Model

NIAM ble utviklet av belgieren Gerardus M. Nijssen. ORM er en noe viderearbeidet variant av NIAM. NIAM/ORM gir mulighet for en svært presis beskrivelse av et informasjonssystem i form av mer avanserte former for skranker enn det vi har i vår notasjon. Grunnen til at dette er mulig, er først og fremst at NIAM kun arbeider på ett nivå - det vi i ER ville kalle attributta i vået. En eventuell sammenslåing, gruppering, av attributtene skjer på et senere tidspunkt, gjerne hvis man skal bruke modellen for å konstruktrere en database.

Dette underkapittelet innholder først de delene av NIAM som tilsvarer "vår" dialekt, deretter avanserte deler av NIAM, og tilslutt noen oppsummeringskommentarer.

11.3.1. Entydighetsskranker. En grunnleggende tanke er å ta utgangspunkt i språket, for å se hvilke skranker som naturlig framkommer ved en språklig beskrivelse. Vi tar for oss den gamle, gode Avdeling og Ansatt i ulike former. Vi har en rekke setninger av typen 3 jobber i Avdelingsnr Ansattnr 107 jobber i Avdelingsnr 5 Ansattnr 101 jobber i Avdelingnr 3 Ansattnr 102

117

Kap. 11

ANDRE DATAMODELLERINGSDIALEKTER

Vi ser at det her er noe fast, mens annet varierer. En NIAM-graf for dette vil se forskjellig ut avhengig av hvilke skranker man setter når det gjelder entydighet.

Entydighetsskranke på én av rollene: Vi tegner her en NIAM-modell. Sirklene beskriver som nevnt begrepene. De ble tidligere kalt for objekttyper men er i de senere utgavene kalt for entitetstyper. Men: de kan altså ikke ha egne attributter, så vi er på attributtnivå. ’ H

Vi ser at den siste er strøket. Vi vil ikke tillate at nr. 107 jobber i både avdeling nr. 3 og 5. Vi vil altså at ansattnr skal være entydig i denne sammenhengen. Dette kalles en entydighetsskranke, og markeres med en strek over den eller de elementer som skal være entydige. Altså:

Entydighetsskranke på en kombinasjon.

Vi tenker oss i stedet at hver ansatt kan jobbe i flere avdelinger. Er da alle kombinasjoner tillatt? Nei, vi må fremdeles sørge for at samme kombinasjonen ikke kommer flere ganger, jfr. tabellen under:

107 101 102 102 107

3 5 3 5 V

OK

ikke tillatt

Konklusjonen er at entydighetsstreken skal gjelde kombinasjonen av disse, som ikke kan gjentas sammen.

Ansatt (ansattnr)

11

Avdeling (avdelingsnr)

jobber i

har ansatt

Entydighetsskranken gjelder kombinasjonen.

Kap. 11

ANDRE DATAMODELLERINGSDIALEKTER

To entydighetsskranker.

Vi forandrer situasjonen igjen og sier at forholdet mellom Ansatt og Avdeling gjelder hvem som er leder for avdelingen. Vi krever at hver ansatt bare har en leder, og at hver person bare kan lede en avdeling.

Her er det altså to entydighetsskranker, en på leder, og en på ledes av. Dermed bør figuren se slik ut:

I praksis: l:m, m:m og 1:1

Erfaring har vist at det er lett å bomme på hvor entydighetsstreken skal stå i 1 :m-tilfellet. Det beste er selvsagt å huske opplegget med entydighetsbeskrankninger og ut fra dette kunne fastslå hvor streken skal stå. Latmannsvarianten for å huske 1 :m er at streken skal stå på samme side som mange-markeringen.

119

Kap. 11

ANDRE DATAMODELLERINGSDIALEKTER

Sammenhengen mellom modellen og setninger.

Vi begynte dette under-underkapittelet med på påpeke sammenhengen mellom språk og modell. Vi skal oppsummere med en av modellene som vi har sett på over. Vi tar det første tilfellet, en person kan jobbe i max 1 avdeling.

Følg den stiplede linjen og se at hele setningen framkommer på denne måten! Tilsvarende kunne selvsagt også den andre setningen, Avdeling med avdelingsnr xx har ansatt Ansatt med ansattnr yy, tegnes opp.

11.3.2. ”Nødvendig’’-skranken Denne uttrykker det samme som minimum 1 i vår notasjon. Vi vil uttrykke at alle ansatte må jobbe i minimum 1, maksimum 1 avdeling. Det blir dermed en form for nødvendig-egenskap mellom objekttypene.

At rollen ikke er nødvendig (påkrevd) betyr dermed minimum 0. Vi ser at modellen inneholder akkurat det samme som det vi er vant til:

Ansatt

I . jobber i

[° Ansattnr

"1

Avdeling

Avdelingsnr

Riktignok kommer symbolet for nødvendig på motsatt side av minimum 1, men det beskriver det samme.

120

Kap. 11

ANDRE DATAMODELLERINGSDIALEKTER

11.3.3. Entitetisering og flerroller i NIAM. Entitetisering. Sirklene i NIAM har tradisjonelt vært kalt objekter - slik at vi her tidligere snakket om objektering, men som nevnt i innledningen er begrepet objekt nå forlatt i NIAM.

Vi tenker oss Avdeling og Ansatte, og at hver ansatt kan jobbe i flere avdelinger, men bare en jobbtype pr. avdeling. Entitetiseringen kan • enten gjøres "halvveis", dvs. som en begrepsdannelse uten at vi gjør en splitting • eller med splitting på vanlig måte.

Kun begrepsdannelse:

Vi har satt en sirkel rundt m:m-forholdet, og gitt det et eget navn. Sagt med andre ord: vi har definert begrepet Beskjeftigelse. Dermed kan man også knytte andre ting opp mot begrepet, som vist med Jobbtype. Alternativet er at man gjør entitetiseringen fullt ut, som man ville gjøre i vår dialekt. Det ser slik ut:

121

Kap. 11

ANDRE DATAMODELLERINGSDIALEKTER

For å vise at kombinasjonen av ansattnr og avdelingsnr er entydig, settes det vanligvis på en koblet entydighetsskranke (som er et eksempel på en såkalt koblet entydighetsskranke), se den prikkede linjen over Igjen: denne modellen kan fullt ut uttrykkes i vår dialekt, se under:

Relasjonstyper mellom flere roller

I kap. 6.7.2 brukte vi samme eksempel på problemstillingen rundt "relasjoner mellom 3 eller flere". I NIAM kan vi, på samme måte som i Chens notasjon (se kap. 11.2), ha relasjoner mellom mer enn 2. Vi utvider ganske enkelt broen til å gjelde en rolle til, slik at vi får:

For a fa entydighetsbeskrankningen sammenhengende har vi byttet om på plasseringen i forhold til de andre gra ene. Dersom dette ikke er mulig, lager man en prikking mellom de ulike delene av entydighetsskranken. I flerrollesammenhenger vil det av og til være flere sett av entydighetsskranker som kan gjelde samtidig. Dette er lett a spesifisere. La oss si at en person heller ikke kunne ha samme jobbtype i to forskjellige avdelinger. Dermed bhr altså (ansattnrjobbkode)-kombinasjonen også entydig, dvs. at både (ansattnr,avdelingsnr) og (ansattnr,jobbkode) er kandidatnøkler. Skrankene kan dermed skrives:

ansattnr

avdelingsnr

jobbkode

En videreutvidelse av modellen til 4 eller flere roller er også helt uproblematisk.

122

ANDRE DATAMODELLERINGSDIALEKTER

Kap. 11

11.3.4. Avanserte skranker: enten-eller, både-og, først-siden De skrankene som beskrives her. er ting som ikke lar seg beskrive i vår notasjon Enten-eller:

Vi skal beskrive at du ikke kan være deltaker og lærer samtidig og bruker tegnet * for å vise at en person ikke kan ha deltagerrollen og lærerrollen samtidig. Vi tenker her på kurs som en kursavholdelse (med tid og sted).

Alternativ 1:

Her står det altså at hvis du er lærer, så kan du ikke være deltager på et kurs. Dette blir imidlertid litt for firkantet. Du bør kunne være lærer på ett kurs, men deltager på et annet. Vi burde heller uttrykke at samme (Kurs,Person)-kombinasjon ikke kan forekomme i begge.

Alternativ 2:

Du kan ikke være deltager på samme kurs som du er lærer på. (Noen organiasjoner prøvde seg for en stund tilbake å sette opp kurslæreren som deltager, for dermed å få mer statsstøtte ... Det bør ikke være tillatt). Sagt med andre ord: lærerrollen på et kurs er uforenelig med deltagerrollen på samme kurs. For å klargjøre forskjellen på de to variantene av at en lærer ikke kan være deltager på et kurs, ser vi på noen forekomster (hhv. den nederste og den øverste "broen" på hver av grafene):

Lærer Kursnr 1001

Alternativ 1: Alternativ 2:

(nederst) Lærerpersonid 1

Deltager Kursnr 1000 1001

(øverst)

DeltagerPersonid 1 1

Lærer_personid og Deltager_personid må være forskjellige ==> Begge forekomstene i Deltager er ulovlige. (Kursnr,Lærer_personid) og (Kursnr,Deltager_personid) -kombinasjonene må være forskjellige = > Første forekomst i Deltager er OK (du går på et annet kurs enn du er lærer på), andre forekomsten er ikke tillatt (du er deltager på samme kurs som du er lærer på).

123

Kap. 11

ANDRE DATAMODELLERINGSDIALEKTER

Både-og På kurs på høgskolenivå er faglærer alltid intern sensor (i tillegg er det en ekstern sensor)

Er du lærer på et kurs, så er du også intern sensor på det samme kurset og motsatt. Uten klammerparantesene ville vi ha uttrykt at en lærer nødvendigvis må være sensor (i et eller annet kurs, ikke nødvendigvis sitt eget).

Dersom en student klager på eksamensresultatet, vil det bli oppnevnt en såkalt klagekommisjon. Regelen er at den interne sensoren for ordinær eksamen ikke kan kan sitte i klagekommisjonen for det samme kurset Utvider vi modellen over med dette, får vi en enten-eller og både-og i samme modell.

Først-siden-skranken (delmengde-skranken).

Siden vi har eksempler fra skoleverdenen kan vi tenke oss at vi vil uttrykke at det bare er personer som er lærde i et fag som får lov til å undervise i faget (hva "lærd" er måtte i tilfelle defineres nærmere).

c - delmengdesymbolet fra matematikken brukes som tegn på delmengde. For å være lærer i et fag må du altså være lærd i faget. Med mengdesymboler blir det dermed at Lærer c Lærd for et gitt fag. Med mengdediagram (Venn-diagram): &

Det betyr også at dersom du mister status som lærd i faget, mister du også status som lærer i faget Dersom delmengdeskranken bare hadde vært over lærer/lærd, ville det betydd at du må være lærd i et eller annet fag for a være lærer i et eller annet fag (men du kan godt være lærd i et annet fag enn det du er lærer i).

124

Kap. 11

ANDRE DATAMODELLERINGSDIALEKTER

De som jobber i skoleverket vet at dette eksemplet ikke er helt realistisk La oss derfor ta et annet som er realistisk, nemlig: for å være leder for en avdeling, må du også være ansatt i den avdelingen.

Dette betyr altså at en person først må være ansatt, deretter kan vedkommende bli leder. Dersom vedkommende slutter i avdelingen, må han/hun også slutte som leder i denne avdelingen. Alternativt: for å være leder i en avdeling må du være ansatt i en eller annen avdeling. Hvis du slutter i firmaet, må du også slutte som leder. Vi har da

11.3.5. Noen andre aspekter. Vi skal her bare peke på to andre aspekter av NIAM:

Undertyper.

Undertyper kan beskrives i NIAM. Vi vil uttrykke at en person enten kan være fast eller midlertidig, ikke begge deler:

125

Kap. 11

ANDRE DATAMODELLERINGSDIALEKTER

Domener i NIAM.

En NIAM-modell for ansatte, avdelinger og telefonnummer kan f.eks. se slik ut:

Vi ser her at det er en felles beskrivelse av telefonlinjen, uavhengig av om de forekommer som jobbnr, privatnr. mobilnr el.l. Dermed vil regler om f.eks. utseende av telefonnr etc. kunne beskrives felles, altså fungerer sirklene egentlig som domener (jfr. kap. 3.4). Det samme gjelder også for avdelingsnummeret etc. I en modell på ER-form ville dette i stedet ha blitt vanlige attributter, og man ville dermed bare ha sett domenene dersom disse var spesifisert i attributtlisten.

(Det spørs vel om ikke flere av disse blir m:m, men det er uvesentlig i denne sammenhengen).

11.3.6. Vurdering av NIAM. Sammenligning av NIAM med vår ER-dialekt.

En såpas kort gjennomgang gir selvsagt ikke alle detaljene i en teknikk. Vi skal likevel peke på en del momenter: • • •

•

126

Teknikken er svært presis, og mange skranker som beskrives i NIAM kan ikke beskrives i ER-dialekter. Det er implisitt støtte for domenetenkning. Normaliseringsbrudd er lettere å se. Alt er på ett nivå, mens vanlige ER-modeller er tonivås, nemlig entitets/relasjonstypenivå og attributtnivå. ammenhengen med relasjonsdatabaser er mindre opplagt, selv om det er mulig å automatisere overgangen til en relasjonsdatabase (m.a.o at det finnes en grupperingsalgoritme). den Inneholder så manSe deltaljer som ikke lar seg beskrive i dagens databasesystemer (i alle tall ikke deklarativt), vil en reversering fra en database til en datamodell på NIAM-form være umulig. iden entitetisering kan gjøres fullt eller delvis, vil samme fakta kunne vises på to forskjellige måter. Utgangspunktet er et helt annet enn ER: mens ER tar utgangspunkt i "ting" og generaliseringer i den forbindelse, tar NIAM utgangspunkt i språket. NIAM er antagelig vanskeligere å forstå for en som skal begynne med datamodellering. I og med at alle attributter skal være med i den grafiske modellen, blir den lett svært omfattende - og overfyllt av en rekke tvivielle deler.

Kap. 11

ANDRE DATAMODELLERINGSDIALEKTER

Det siste poenget er kanskje et av de viktigste: dersom Ansatt har 20 attributter, vil det blir 20 sirkler og sammenhenger i NIAM i stedet for en eneste rektangel i ER. I det norske miljøet har bruk av den ene eller den andre notasjonen vært et stadig diskusjonspunkt, ikke minst fordi ulike utdanningsinstitusjoner har hatt sterke preferanser for det ene eller det andre. Personer preges gjeme av sin utdannelse, og dermed vil den nest-siste påstanden antagelig bestrides av de som først og fremst kjenner NIAM. Jeg tror det er viktig å være klar over de likhetene som finnes, og dermed også kunne se hverandres synspunkter. Samtidig er det lurt å kunne flere teknikker, slik at f.eks. NIAM kan brukes på små, men kompliserte problemstillinger, mens ER i en eller annen form brukes ellers. Det bør også sies at NIAM er relativt lite brukt i næringslivet, bl.a. av de grunner som er nevnt over. I praksis har dette også sammenheng med at mange av reglene som NIAM er gode til å beskrive, er vanligvis-regler, men som det av og til gjøres unntak på, og som man dermed ikke kan implementere strikt i et informasjonssystem. Tre eksempler: • Regelen om at læreren alltid skal være sensor i sitt fag følges ikke alltid. • Man vil muligens kunne kunne ha en avdelingsleder som jobber ved en annen avdeling, og kanskje til og med ha en ekstern person som avdelingsleder for en periode. • Det høres naturlig ut at fylkesadministrasjonssenteret for et fylke også ligger i en kommune i dette fylket, f.eks. ligger ikke administrasjonssenteret for Hordaland i Trondheim. Imidlertid finnes det et unntak på dette et sted i landet, som gjør at denne regelen ikke kan håndheves. Svar følger i fotnote nr38.

Kombinasjon NIAM / ER? Gerhard Skagestein, en av nestorene innen datamodellering her til lands, har tatt til orde for å kombinere ER og NIAM ved å trekke sammen attributter som "hører sammen" og som ikke har spesielle skranker utover Nødvendig-egenskapen inn i samme entitetstype, mens avanserte skranker (enten-eller, både-og, først-siden) kan tegnes mellom entitetstypene . Modellen blir da mer kompakt (trivielle attributter samles inn i samme entitetstype), samtidig som flere skranker kan håndteres, se Skagestein 1996.

I Modelator finnes en notasjon som kalles NIAM-lignende, men hvor man tegner entitetstyper med attributter, slik Skagestein foreslår. Man kan skifte notasjon når man måtte ønske, og modellen blir automatisk tegnet opp på nytt med ny notasjon. Der kan det aller meste (alt unntatt spesifiserte minima og maksima, og minima > 1) tegnes på NIAM-form. Det kan være lærerikt å teste ut dette ved å gå over til NIAM-notasjon. Prøv f.eks. en entitetisering - dere vil se at egentlig er det samme sak uavhengig av notasjon. Det NIAM-spesifikke er imidlertid ikke med - det ville uansett gått tapt ved overgang til f.eks. kråkefotnotasjon. Det ville heller ikke vært med dersom modellen ble laget på grunnlag av en reversering fra en database.

Vårt ansattsystem ser slik ut i NIAM-form fra Modelator (kun identifikatorer og fremmednøkler er tatt med).

38 Fylkesadministrasjonen for Akershus ligger i Oslo kommune. Dessuten har mange fylker spredt hovedadministrasjonen til flere kommuner.

127

Kap. 12

TILLEGG A: MER OM NORMALISERING.

12. TILLEGG A: Mer om normalisering. Vi går her mer grundig til verks enn i kap. 7.

Hva er normalformene / normaliseringsreglene?

Regler for normalisering er ulike krav som vi ønsker sette til en entitetstype i en datamodell eller en tabell i en database. At entitetstypen/tabellen er godt normalisert betyr altså at den er fri for visse former for uheldig struktur. Det er imidlertid viktig å være klar over at normaliseringsreglene bare fanger opp visse former for en uheldig struktur, og er derfor ikke er noen garanti for at strukturen ellers er bra. Reglene er formet slik at de stiller strengere og strengere krav til hvorledes entitetstypen eller tabellen ser ut. Disse blir kalt hhv. 1., 2. og 3. normalform, Boyce-Codds normalform og 4. og 5. normalform. Vi kan illustrere det slik:

Vanligvis blir 2. og 3. normalform forklart via begrepet funksjonell avhengighet. Determinantbegrepet (se kap.. 7) duger imidlertid også i disse tilfellene, og vi vil derfor bruke dette begrepet i stedet.

Gjennomgående eksempel: et sykehussystem. Den beste måten å vise normalformene på, er antagelig å gi eksempler på strukturer som bryter mot reglene og eretter mer presist a finne ut ' hva som er galt". Eksemplene er hentet fra en datamodell for et sykehus. Første gang man legges inn på et sykehus, får man et såkalt PersonIdentifikasjonsNr, PIN. I tillegg har man en gangnr for denne personen", som første gang selvsagt blir 1. Hvis man så kommer på sykehuset for annen gang, beholder man PIN, mens gangnr blir 2. Man har også med det 11-sifrede fødselsnummeret, men dette brukes ikke som identifikator. Dette opplegget brukes i alle fall i et av de mest brukte syskehussystemer her i

Strengt tatt skulle vi beskrive hver av de forutsetningene vi tar, som at postnr determinerer poststed og ikke omvendt osv. Vi tar imidlertid for gitt at man i Norge har en felles referanseramme når det gjelder disse ting. For å rendyrke de forskjellige typer problemer, tar vi med litt forskjellige detaljer i hver av attributtlistene i eksemplene som følger.

128

Kap. 12

TILLEGG A: MER OM NORMALISERING.

Eksempel 1: Ikke atomisk; brudd på 1. normalform. Vi samler opplysninger om personer og alle innleggelser i samme entitetstype, med følgende attributter:

PIN Gangnr Personnavn Telefonnr Innleggelsesdato Dette fører imidlertid til at Gangnr og Innleggelsesdato blir "repeterende", slik at kravet til atomiske attributter ikke er oppnådd:

PIN Personnavn Gangnr,Inni.dato/Gangnr,Innkdato/Gang ...osv.

Første normalform (INF): Ethvert attributt skal være atomisk.

Eksempel 2: Determinering fra deler av identifikatoren; brudd på 2. normalform.

For å hindre repeterende attributter kan det være en idé å gjøre identifikatoren mer omfattende: PIN Gangnr Personnavn Telefonnr Innleggelsesdato

Problemet her er imidlertid at personnavnet og telefonnr gjentas for hver innleggelse. Dette er unødvendig, og skaper redundans og dermed svært lett inkonsistens. Et determineringsdiagram avslører problemet:

2. normalform (2NF): INF må være oppfyllt, og dessuten: Vi tillater ikke at deler av identifikatoren skal determinere andre attributter.39

Hvis vi hadde gjort et bra datamodelleringsarbeide på forhånd, hadde vi sett at det her egentlig er en sammenblanding av to begreper, nemlig Person og Innleggelse. Datamodellen for dette ville se slik ut:

39For spesielt interesserte: Formuleringen har gjerne vært at deler av identifikatoren ikke får lov til å determinere ikke-identifikator-attributter. Ikke-identifikator-attributter er imidlertid unødvendig. Hvis en del av identifikatoren determinerer en annen del av identifikatoren, så oppfyller ikke identifikatoren irredusibilitetskravet. 129

Kap. 12

TILLEGG A: MER OM NORMALISERING.

Denne er nå normalisert korrekt. Som vanlig betegnes fremmednøkkelen med *. Merk at problemstillinger som angår 2. normalform kun er aktuell dersom man har en sammensatt identifikator.

Eksempel 3: Indirekte determinering; brudd på 3. normalform.

Vi tar nå for oss Person på nytt, men legger inn postnummer og poststed.

PIN Personnavn Telefonnr Postnr Poststed

(som del av en full adresse, ikke som sykehuspost!)

Hvis de fleste pasienter kommer fra samme sted, vil de antagelig fordele seg på noen få postnummer, som vil gjentas gang på gang. Også her vil et determineringsdiagram være nyttig:

Igjen er det samme leksen: Postnummer og poststed hører sammen som en enhet, og burde vært splittet ut som en egen entitetstype:

Post er som tidligere et forsøk på å finne et naturlig navn for "postnr/poststed-kombinasjonen

130

Kap. 12

TILLEGG A: MER OM NORMALISERING.

I andre tilfelle vil det være mye lettere å finne naturlige navn. Anta f.eks. at man i utgangspunktet la inn kommunenr og kommunenavn i PERSON. Denne vil gi samme problematikk, og disse attributtene bør splittes ut i en egen entitetstype KOMMUNE. Det å legge inn både Avdelingsnr og Avdelingsnavn i ANSATT, slik vi gjorde i det innledende eksempelet i dette kapittelet, er enda et eksempel på den samme problemstillingen med indirekte deteriminering. 3. normalform (3NF): 2NF må være oppfyllt, og dessuten: det må ikke finnes indirekte determineringer.

Eksempel 4: Determinering fra annet attributt til deler av identifikator; brudd på Boyce-Codds normalform uten å være er brudd på 2NF eller 3NF.

Jeg har ikke klart å finne noe eksempel som viderefører sykehuseksempelet på dette punktet. Jeg har brukt flere timer før jeg fant et eksempel som kunne brukes i det hele tatt. Jeg presenterer følgende: Som kjent finnes samme gatenavn mange steder i landet. For å hindre sammenblanding vil vi imidlertid kreve at kombinasjonen (gatenavn,poststed )er entydig. Skal vi ha med dette i tillegg til postnr, får vi en slik struktur:

Brudd på Boyce-Codds normalform, uten å være brudd på 1., 2. eller 3. normalform

Denne entitetstypen er både på 1., 2. og 3. normalform, men er antagelig ikke heldig likevel, på grunn av determineringen fra postnr til poststed. Uten å gå nærmere inn på det, kan det nevnes at slike problemet har sin bakgrunn i at det i tillegg til identifikatoren finnes en annen kandidatnøkkel (her: (postnr,gateadresse)), og at det finnes et felles attributt (her: gateadresse) i begge kandidatnøklene.

Det som Boyce-Codds normalform (BCNF) tar for seg, og som ikke avsløres av 2. og 3. normalform, er determinering fra et annet attributt til deler av identifikator. Vi skal snart se hvorledes denne regelen sammen med 2. og 3. normalform kan formuleres på en positiv måte (dvs. hva som positivt er tillatt, ikke bare hva som bryter med reglene).

Brudd både på 2., 3. og Boyce-Codds normalform har angått determinanter som går • fra deler av identifikator (2NF-brudd) • fra ikke-identifikator-attributter til • andre ikke-identifikator (slik at man får indirekte determinering, 3NF-brudd). • fra ikke-identifikator til del av identifikator (BCNF-brudd). Det eneste som det ikke er gitt forbud mot, er altså følgelig determinering fra hele identifikatoren og til de andre (ikke-identifikator)-attributtene. Konklusjonen etter dette vil være følgende foreløpige formulering: Foreløpig formulering: Den eneste determinanten som bør tillates, er (hele) identifikatoren.

Formuleringen av BCNF snakker imidlertid om kandidatnøkler, og ikke bare om identifikatorer. Før vi konkluderer med en endelig formulering, skal vi derfor i det neste eksempel se på hvorfor kandidatnøkler kan være determinanter.

131

Kap. 12

TILLEGG A: MER OM NORMALISERING

Eksempel 5. Hvorfor snakker vi om kandidatnøkler, ikke bare om identifikatorer?

Her duger eksempler fra sykehuset igjen! For en entitetstype PERSON har vi:

PfN Personnavn Gateadresse Postnr Fødselsnr

hvor Fødselsnr er kandidatnøkkel. Determineringsdiagrammet ser slik ut:

Selv om vi far mange determineringer, vil vi ikke fa noen problemer med denne strukturen, verken med hensyn til dobbeltlagring eller endring av data. Skulle vi f.eks. splittet ut Fødselsnr sammen med PIN i en egen entitetstype, ville det blitt et 1:l-forhold mellom PERSON og denne entitetstypen, og dermed en god kandidat for sammenslåing.

De eneste determineringer som bør tillates, er fra kandidatnøkkelen (dvs. identifikator eller andre entydige attributter(-kombinasjoner)) til andre attributter. Slik ender vi altså opp med hovedregelen for normalisering:

Hovedregelen for normalisering, Boyce-Codds normalform (BCNF): 1) alle attributter er atomiske (kravet til INF) 2) enhver determinant er en kandidatnøkkel.

Litt om 4. normalform-problemer. 4. normalform knytter seg til problemer med at vi har en identifikator som består av minst 3 attributter og at et av attributtene har knytninger til "faste" sett med flere verdier for hven av to (evt. flere) andre attributter som ogsa finnes i identifikatoren. Fra et sykehus kan man tenke seg at man vil ha en entitetstype med alle leger hvilke spesialiteter de har, og hvilke avdelinger de jobber på. Skal man ha dette i samme entitetstype, må identifikator bestå av kombinasjonen (Legeid, Spesialitetid Avdehngid). LSA Legeid LI LI LI LI LI LI

132

Spesialitetid Sl S2 'si S2 Sl S2

Avdelingid Al Al A2 A2 A3 A3

Kap. 12

TILLEGG A: MER OM NORMALISERING.

Her har vi bare skrevet ...id som å antyde identifikator for de forskjellige entitetstypene.

For hver ny spesialitet som legen far, vil vi måtte registrere legen med denne en rekke ganger, for dermed å dekke alle kombinasjoner med avdelinger. I stedet for at legen determinerer en enkelt verdi (altså at han/hun f.eks. bare har en spesialitet), determineres flere verdier hver gang, men alltid det samme settet av verdier. Vi snakker derfor om en flerverdideterminering i stedet for en "vanlig" eller enverdideterminering. En flerverdideterminering beskrives med en dobbeltpil, altså Legeid Spesialitetid. Hvis en slik flerverdideterminering bare eksisterte for ett attributt, ville det være brudd på 1. normalform. Det ville i tilfelle betydd at Legeid var identifikator, og for hver slik hadde man mange spesialiteter. Problemet kunne løses ved at identifikator i stedet besto av kombinasjonen Legeid,Spesialitetid. Problemet kommer først når vi har flere slike flerverdidetermineringer i samme entitetstype. Vi snakker derfor om et (trekk pusten!) flerverdideterminantpar, her Legeid Spesialitetid og Legeid Avdelingid.

Legg merke til at en enverdideterminering bare er et spesialtilfelle av en flerverdideterminering, nemlig der hvor "flerverdien" egentlig bare er 1.

Skjematisk kan 4NF-problemer tegnes slik:

Brudd på 4. normalform.

I tillegg blir forholdet mellom B og C en "alle-ti 1-alle" (se kap. 6.6). Strukturen gir opphav til mye redundans, og er selvsagt uheldig. Igjen er problemet at vi blander sammen flere ting i samme entitetstype. Vi burde naturligvis ha splittet dette i to entitetstyper, f.eks. Legespesialitet og Lege_på_avdeling. Eventuelle determineringer ville i tilfelle være en-verdi-determineringer.

4. normalform (4NF): En entitetstype eller tabell er på 4NF dersom eventuelle flerverdidetermineringer egentlig er enverdidetermineringer.

133

Kap. 12

TILLEGG A: MER OM NORMALISERING.

Siden vi forutsetter at hvilke spesialiteter legen har og hvilke avdelinger hun/han jobber på er uavhengig av hverandre, så bør de også struktureres uavhengig av hverandre. En normalisering til 4. normalform blir dermed:

LS Legeid LI LI

Spesialitetid Sl S2

LA Legeid LI LI LI

Avdelingid Al 1A2 A3

Dette gir både færre data og en enklere struktur, med mindre mulighet for feil. Det bør bemerkes at den opprinnelige entitetstypen / tabellen kan fås gjennom å koble sammen LS og LA på det felles attributtet, nemlig Legeid. Sagt med andre ord: LSA = LS koblet med40 LA. Jeg vil påstå at dersom man lager en fornuftig datamodell først, vil man ikke komme bort i problemer med 4 normalform. Jeg gjentar samme råd som jeg har nevnt tidligere, nemlig at man bør tegne en god datamodell deretter bruke BCNF som kontroll.

Enda mindre om 5. normalform-problemer.

5. normalform er adskillig verre å forstå enn de andre. Vi skal likevel gi en antydning om hva slags problemer den handler om. For ikke å blande det sammen med 4NF, henter vi problemstillingen fra noe annet, nemlig ansatte, avdelinger og stillingstyper. Vi antar at hver ansatt kan jobbe i flere avdelinger, og har ulike stillingstyper. Som vi så i kap. 6.7.1, måtte vi ha en entitetstype med 3 attributter for å beskrive dette AAS Ansnr

Avdnr

Stiilkode

Dette bhr en m:m:m, som i utgangspunktet ikke kan splittes. Men: hva hvis vi hadde en form for parvis alle-tilalle mellom 2 og 2 av disse i stedet (jfr. alle-til-alle i kap. 6.6). Vi kunne da tenke oss at vi splittet i 3 ulike entitetstyper, nemlig

AnAs Ansnr

AnSt

Avdnr

Ansnr

AvSt Stiilkode

Avdnr

Stiilkode

Dersom dette skulle være en lovlig splitting, måtte det bety at en kobling4’ mellom disse 3 entitetstypene skulle gi den opprinnelige entitetstypen tilbake. I så tilfelle måtte det være slik at

Hvis og og

(Ansnr,Avdnr) (Ansnr,Stiilkode) (Avdnr,Stiilkode)

finnes i AnAs finnes i AnSt finnes i AvSt

så må også

(Ansnr,Avdnr,Stillkode)

finnes i AAS.

Det ville betydd at hvis en ansatt (f.eks. Ole) jobber i en avdeling (f.eks. utenlandsavdelingen), og hvis Ole har en gitt stilling (f.eks. sekretær), og hvis Utenlandsavdelingen har sekretærer, så må Ole være sekretær i utenlandsavdelingen.

4° Denne "koblet med"-formen kalles en natural join i relasjonsalgebra, se bøker innenfor databaseteori. Koblingen måtte gå på like verdier av korresponderende attributt, f.eks. Ansnr i de to første. Igjen en natural join. "

134

Kap. 12

TILLEGG A: MER OM NORMALISERING.

Vanligvis er det vel slik at selv om en person er sekretær i én avdeling, så kan vedkommende være sentralbordbetjent i en annen avdeling. Hvis 5NF skal brytes, måtte det altså være slik at hvis du først var sekretær, så måtte du være det i alle avdelinger som du jobber i. Dette ville imidlertid være en meget "sær" regel, en form for regel som "biter seg selv i halen". Hvis vi ikke har en slik regel, er en struktur på 4NF også automatisk på 5NF, og vi har behov for å ha en "mellomliggende entitetstype", her AAS, som sier hvilken delmengde av koblingen mellom de 3 entitetstypene som er aktuell.

Vi har også flere ganger nevnt det språklige aspektet ved slike m:m:m, nemlig at de inneholder et utsagn som gjelder 3 attributter, og som ikke lar seg splitte i to og to utsagn uten at vi mister meningsinnhold (se kap. 6.7.1, 8.1). I de tilfelle de virkelig lar seg splitte, er det nettopp brudd på 5NF - altså slik vi så det i de 3 2-leddede hvis-setningene over, som ved brudd på 5NF var det samme som å si den 3-leddede setningen. Prosjektleveranse

To andre eksempler hvor det kan være spørsmål om brudd på 5NF: • Hvis det er slik at firma Fl leverer varer til prosjekt Pl, firma Fl leverer varen VI og firmanr varen VI brukes i prosjekt Pl, er det da slik at firma Fl nødvendigvis leverer varen prosjektnr VI til prosjekt Pl? Hvis ja er det brudd på 5 NF å ha en entitetstype, og entitetstypen varenr til høyre bør splittes i tre. • Hvis en lærer LI underviser klasse Kl, lærer LI har fag Fl og klasse Kl har fag Fl, er Undervisning det da nødvendigvis slik at lærer LI har klasse Kl i fag Fl? Igjen: hvis Ja bør en splitte entitetstypen undervisning i 3. • Forbryterligaer opererer i mange land og stjeler mange varer og mange av de samme Lærerid varer finnes i flere land. Er det da slik at hvis en gitt forbryterliga FLI opererer i et gitt Klasseid Fagid land LI, at FLI stjeler (bl.a.) varen VI, og at varen VI finnes i landet LI, så stjeler forbryterligaen FLI nødvendigvis varen VI i landet LI? Hvis vi får ja på dette spørsmålet så bør vi ha tre entitetstyper med to og to av disse attributtene. Hvis ikke vil vi ha behov for en m:m:m for å si hvilke vareliga- og land-kombinasjoner som er aktuelle (altså hvilke ligaer som stjeler hvilke varer i hvilke land). En dypere innføring i 5NF krever at man kan noe om relasjonsalgebra, noe som er standardstoff i de fleste databasebøker. For både dette og videre beskrivelse av 5NF, se f.eks. Date 1995.

Veier til en god struktur. Vi har vært inne på at man f.eks. i NIAM i utgangspunktet ser på attributtene som uavhengig av hverandre, og deretter grupperer dem sammen til en fornuftig struktur - som gjeme vil være den samme som den man far ved vanlig ER-modellering.

Det motsatte utgangspunktet er også mulig. Man kan tenke seg at alle attributter fantes i samme entitetstype (en "universell entitetstype"), slik at man ved utsplitting nådde fram til en god struktur. Som nevnt i kap. 3.6 brukes gjerne begrepet relasjon i databaseteori grovt sett som synonym til det vi kaller en tabell i en database. Vi snakker derfor om en slik altomfattende entitetstype som en "universalrelasjon". En slik universalrelasjon vil høyst sannsynligvis være dårlig normalisert, slik at vi bør normalisere for å fa en god struktur. Vi ser altså at vi kan ta ulike utgangspunkt for å nå fram til en god struktur:

Målet: God tabellstruktur. 135

Kap. 13

TILLEGG B: OPPGAVESAMLING.

13. TILLEGG B: Oppgavesamling. Litt om oppgaver slik man møter dem på kurs og hva som er "de virkelige problemene".

Når man kommer i en arbeidssituasjon, er det vanskeligste ofte å "finne hva problemet egentlig er", inkl, det å avgrense det, sammenligne med tilstøtende systemer, finne den overordnede strukturen som finnes i problemet og beskrive denne mer formelt, i på norsk og/eller i form av en datamodell. Når det skal lages oppgaver, er disse gjeme laget slik at man skal komme fram til et nogenlunde felles resultat - bl.a. fordi de antagelig skal gjennomgås i en undervisningssituasjon eller at løsningsforslagene på en eller annen måte skal være normgivende.

Problemløsning i forbindelse med kurs blir ofte:

Problemløsning i praktisk arbeide:

lag modell av det presiserte problemet dette er jobben for kurs­ deltagerne

Litt om tolkning av oppgaven

Typiske oppgaver i datamodellering vil altså bare ta for seg en avgrenset del av den totale problemløsningen, g: det a lage en datamodell ut fra en relativt presis beskrivelse er adskillig lettere enn å komme inn enda tidligere i en slik prosess.

Det er derfor viktig at man også gir mer ustrukturerte problemer, gjerne nærme den sitasjonen en står i, f.eks. problemsti linger fra den bedriften en jobber i, eller laging av et generelt system for skoleadministrasjon, bibliotek el.l. Dermed får studentene også en følelse av hvor omfattende de fleste problemstillingene av denne typen er. & En annen typisk forskjell er at mens løsning av "kursoppgaver" i alle fall tilnærmet er en engangsprosess, så er pro emløsmng t praktisk arbeide i større grad en iterasjonsprosess, men "mange runder" og mye tidsforbruk før man kommer fram til et godt resultat.

136

Kap. 13

I:

TILLEGG B: OPPGAVESAMLING.

Enkle oppgaver, uten identifikatorer eller fremmednøkler.

For de første oppgavene behøver du kun ta med entitetstyper, relasjonstyper med markering av minimum og maksimum, samt attributter for noen av oppgavene. Ta også med verb/roller, som f.eks. hvorvidt det er PERSON eier BIL eller PERSON leier BIL. Bruk gjerne m:m-relasjonstyper der det er naturlig, uten å splitte dem opp.

1.

Vei(u)vesenet.

a)

Det skal lages en datamodell som viser sammenhengen mellom kommuner (kommunenummer og kommunenavn) og hvilket fylke kommunen ligger i (det interessante er fylkesnummer og fylkesnavn), samt hvilke riksveier som finnes, og hvilke fylker og kommuner disse går gjennom.

b)

Det er mulig at du har laget en relasjonstype mellom fylke og riksvei. Denne er unødvendig. Hvorfor?

c)

Datamodellen skal også vise hvilke fylker som er nabofylker til hverandre, dvs. hvilke fylker som grenser til hvilke fylker. Utvid datamodellen. NB! Dette kan løses uten bruk av flere entitetstyper.

2.

Statskirken.

NB! Ta bare med entitets- og relasjonstyper, ingen attributter.

a)

Den Norske Kirke (Statskirken) har som kjent bispedømmer, som er delt opp i prostier, som igjen består av flere menigheter. Det kan være flere menigheter innen samme kommune. En prest er normalt knyttet til en menighet, men kan også være knyttet til flere. Tegn en datamodell som viser dette.

b)

Et prestegjeld kan bestå av flere menigheter som "deler på" de samme prestene. En prest er med i bare ett prestegjeld. Et prestegjeld er alltid innen samme kommune. Gjør om datamodellen!

3.

Olympiaderesultater.

NB! Ta bare med entitets- og relasjonstyper, ingen attributter.

Noen er svært systematiske med å ta vare på resultater fra idrettsstevner, bl.a. olympiader. For å hjelpe dem med strukturering av dataene, skal du lage en datamodell i denne forbindelse. Anta at det bare er snakk om enkeltidretter.

a)

Vi ønsker data om idrettsutøvere, hvilken nasjon hun/han kommer fra, hvilken olympiade (f.eks. vinterOL i 1994) det var, hvilken idrettsgren (f.eks. Ski) og hvilken enkeltøvelse (f.eks. 30 km. for menn), og hvilket resultat (plassering) som vedkommende oppnådde i hver slik øvelse i hvert OL. Om alle resultater eller bare de beste resultatene skal være med, spiller ingen rolle for modellen. Lag en datamodell som inneholder de understrekede ordene som entitetstyper. Jobben din blir altså å sette fornuftige relasjonstyper, med min., max. og verb/roller.

b)

Som kjent hender det at en person "bytter land"; altså at hun/han deltar for ett land i ett OL, men i et senere OL deltar for et annet land. Vi regner imidlertid med at personen ikke kan "bytte land" i løpet av ett OL. Gjør om modellen etter dette. Hint: Lag en ny entitetstype, f.eks. deltagelse (altså en idrettsutøvers deltagelse i en olympiade).

137

Kap. 13 4.

TILLEGG B: OPPGAVESAMLING.

Avisdistribusjon.

Vi skal lage en enkel datamodell i forbindelse med distribusjon av aviser. Vi tenker oss et distribusjonsselskap som distribuerer de aktuelle avisene i et gitt distrikt. 1 a)

En del sentrale begreper i denne sammenheng er AVIS (f.eks. Aftenposten, Dagsavisen Fredriksstad Blad), ABONNENT, ABONNEMENT, AVISBUD. RUTE (dvs. den ruten avisbudet følger når hun leverer avisene). Bruk disse begrepene som entitetstyper i en datamodell og sett på riktige relasjonstyper mellom disse. NB! Det er viktig med begrepsavklaring, f.eks. hva som er forskjellen på en abonnent og et abonnement.

b)

Plassér følgende attributter: Avisens navn og adresse, ansattnr, navn og adresse for de som har de forskjellige rutene, dato den enkelte abonnent begynte å abonnere på avisen.

c)

I teksten over er begrepet AVIS brukt flere ganger i flere betydninger. Presisér ulike mulige betydninger av dette begrepet, gjerne gjennom en utvidelse av datamodellen du har laget.&

•> 5.

Kontorer og ansatte.

Tenk deg et firma med ansatte (ansattnr, navn, osv.) og kontorer (romnr, kvadratmeterantall, etasjenr, osv.). Forholdet mellom disse kan være 1:1, l:m, m:l eller m:m. Tegn opp og forklar endel ulike muligheter, bl.a ved hjelp av verb/roller. Minima kan kuttes ut. a)

Dersom det alltid er snakk om nåtid

b)

Dersom det kan være snakk om fortid eller nåtid.

c)

Hva må du gjøre dersom du i tillegg vil ha med når den enkelte holdt til på de enkelte kontorene.

6.

Ship o hoi.

Oppgaven gjelder skip, havner de besøker etc. Vi skal også ha med diverse opplysningner om ulike land. a)

Det primære er opplysninger om hver båt, hvilket verft båten er bygget ved (med diverse opplysninger om dette verftet, bl.a. i hvilket land verftet ligger), hvilket land som skipet er registrert i, hvilke firmaer som eier skipet (ofte er det mange eiere på samme skip) og hvilket land hvert eierfirma holder til i.

b)

Videre ønsker man opplysninger om hvilke havner som skipet har vært innom (med opplysninger om hver havn, inkl, hvilket land som havnen ligger i).

c)

Vi vil utvide modellen med opplysninger om hvert anløp som skipet har hatt i hver havn Hva må gjøres med modellen for å få med dette?

d)

Ta utgangspunkt i c) og plassér følgende attributter: Båtnr (som entydig identifiserer en båt) Båtnavn Landsnavn, Anløps- og avgangsdato for båten til en gitt havn, Navn på havnen, Verftsnavn, Byggeår, irmanr, flimanavn og -adresse for de firmaene som er (med)eiere i båten, Bruttotonn.

138

Kap. 13

II:

TILLEGG B: OPPGAVESAMLING.

Enkle oppgaver med identifikatorer og fremmednøkler.

I oppgavene som folger skal du ta med identifikatorer og fremmednøkler. M:m behøver ikke å splittes dersom du ikke "må", dvs. hvis du ikke har mer å si om nvm-forholdet.

7.

Identifisering av en bil.

Drøft ulike mulige identifikatorer for en bil. Sett først opp mulige kandidatnøkler, deretter bestem deg for hva du ønsker å bruke. Hva er forresten en bil i denne sammenhengen?

8.

Domene for kjennetegn for kjøretøy.

Hva er domenet for kjennetegn på norske kjøretøy? (Det er vanskeligere enn du tror først, spesielt hvis du skal ta hensyn til gamle kjennetegn, spesialkjennetegn for gamle Oslo-biler etc.)

9.

Identifisering av et bokeksemplar.

Hvilke kandidatnøkler finnes for et bokeksemplar innenfor et gitt bibliotek? Sjekk deretter med bibliotektet du har i nærheten hva som brukes som identifikator i deres bibliotekssystem.

10.

Telefonnummer som identifikator?

Som noen sikkert har lagt merke til, bruker enkelte pizza-firmaer telefonnummeret ditt som identifikator når du bestiller pizza. Har du bestilt pizza hos dem før, kan du bare oppgi telefonnummeret ditt, så vet de hvor de skal kjøre!

Drøft dette valget av identifikator.

11.

Identifikator i et bokklubbfirma

I et bokklubbfirma med mange bokklubber består abonnentnummeret av tre sifre først som angir hvilken bokklubb du er medlem av, deretter 6 sifre som viser medlemsnummeret innenfor denne bokklubben. Forklar hvorfor dette er en uheldig struktur. (Det er flere grunner. -1Hustrer gjerne med en datamodell).

12.

Brudd på referanseintegritet.

Lag en datamodell med minst 3 entitetstyper. Tenk deg disse som tabeller i en database og sett inn noen data. Lag 2-3 sett med data som viser brudd på referanseintegritet (og som dermed altså ikke burde finnes i databasen).

13.

Referanseintegritetsformer.

Ta for deg ansatt-eksempelet og ordre-eksempelet og drøft hvike former for referanseintegritet (betinget = restrict = RES, kaskade = cascades = CAS, nullstill = set null = SN, evt. andre) som bør brukes.

139

Kap. 13 14.

TILLEGG B: OPPGA VESAMLING.

Referanseintegritet - hvem overstyrer.

Gitt modellen over. Anta at det finnes underliggende data til en gitt verdi av identifikator i A i alle de andre Hva skjer hvis: a) A-B er definert med CAS, de andre med RES? b) Alle, bortsett fra én er definert med CAS, én er definert med RES. c) A-C defineres med SN, de andre med CAS. d) A-C defineres med SN, de andre med RES.

15.

Ship o hoi II.

Ta for deg Ship o hoi-oppgaven på nytt og legg inn identifikatorer og fremmednøkler. Vær spesielt oppmerksom på identifikator for anløp.

16.

Miljøstiftelsen Boliena.

.. ;L i, ff1B° T Vl sys'ematlsere opplysninger om firmaer i Norge som slipper ut kjemiske stoffer. Hvert kjemisk stoff har en bestemt identifikasjon (vi behøver ikke her å bekymre oss over hvorledes dette er bygget opp), tillegg vil man vite det norske og engelske navnet på stoffet. For hvert firma har man et firmanummer vn og adresse, tillegg skal man ha en oversikt over antatt utslippsmengde (i kg) pr. måned av det eller de ’ stoffene som firmaet slipper ut.

a)

Lag en datamodell som viser disse forhold.

Utvid datamodellen til også å ha med fareklasser for de forskjellige stoffene (A = ufarlig B = syrer C - organisk materiale osv.) 5’ y ’ Diskuter gjerne forskjellige løsninger på dette (f.eks. om det finnes stoffer som er ufarlige samtidig som de er syrer). 5 «uuuuig c)

1 teksten over kan ordet utslippsmengde forstås på flere måter. Hvilke?

17.

Hotelloversikt.

Vi ønsker oss en oversikt over hotell i Norge og diverse opplysniger i denne sammenhengen,

a)

Først og fremst vil vi ha med hotellnr, og -navn, telefonnr og hvor de holder til (postnr, poststed)

b)

Dersom hotellet er medlem av en hotellkjede (f.eks. Rica Hotels), skal vi ha med hvilken hotellkjede som hotellet er medlem av. Slike hotellkjeder har ofte en felles bestillingstelefon, og denne skal i tilfelle finnes i y bicin cl.

140

Kap. 13

TILLEGG B: OPPGAVESAMLING.

c)

Hotell har gjerne ulike faste aktiviteter (f.eks. Golf, Svømming, Dans, Biljard) etc. Vi trenger en liste over slike "mulige" aktiviteter, samt hvilke hoteller som har hvilke aktiviteter.

d)

Hvilken endring må gjøres dersom vi for hver slik aktivitet på hvert hotell også skal kunne knytte en kommentar (f.eks. "svømmehallen er nyoppusset")?

18.

Arbeidskontorer.

Arbeidskontorene registrerer både ledige jobber og ledige personer, og prøver å "matche" disse.

a)

Stillingene er delt opp i ulike kategorier og underkategorier, f.eks. er kategori 09 Helsevesenet, og underkategori 03 er Hjelpepleier. For de enkelte jobbene som blir registrert ledige, blir det notert hvilket firma det gjelder (vanlige opplysninger som arb.givernummer, navn og sted på firmaet), kategori og underkategori på jobben, samt hvilket arbeidskontor denne registreringen opprinnelig ble foretatt hos. Man bør også ha adressen til arbeidskontoret. Tegn datamodell.

b)

For de arbeidssøkende blir det tilsvarende registrert personalia, samt hvilke forskjellige underkategorier han/hun søker jobber i. Også det arbeidskontoret som de primært står knyttet til, blir registrert. Utvid datamodellen.

19.

Enkelt ordresystem (har noe til felles med det gjennomgående eksempelet, men også noe som er forskjellig).

For alle varer skal man vite: hvilket lager som varen finnes på. Firmaet har flere lagre, men hver vare finnes bare på ett lager. Lagrene er nummerert, og har i tillegg et navn. hvilke leverandører som finnes for varen (leverandømummer, navn, adresse inkl, postnr og poststed). hvilke deler en vare består av. Eksempelvis kan et bestemt møbel inngå i flere andre møbler (tenk på IKEA)!

Når man får en ordre, noteres et ordrenummer, ordredato, samt hvilken kunde dette gjelder (kundenummer, navn og full adresse). Kundedata er som regel registrert på forhånd, eller blir eventuelt registrert samtidig med orderen. Av provisjonshensyn m.m. trenger vi også å vite hvilken selger som mottar ordren (selgernavn, selgernr). Kundene er delt opp i kundekategorier (nummerert 1,2, 3 etc.), hvor hver kategori har sin rabattprosent.

For hver ordre noteres det hvilke varer som orderen består av, og i hvilket antall.

Man vil naturligvis forsøke å effektuere ordren med en gang, men noen ganger fører en ordre til at man lager en egen restordre for de varene som ikke kan effektueres med en gang. Selv om det neppe forekommer ofte i praksis, antar vi at det også kan lages en "restordre på restordren" igjen, osv.

141

Kap. 13

TILLEGG B: OPPGAVESAMLING.

Bankdata.

20.

Vi tenker oss noen av data som finnes om konti en bank. Et første forsøk pa a lage en datamodell var: Konto

Kontonr

——

Kontohaver Adresse

Telefonnr Postnr

! med dato,

Poststed

] beløp osv.

Transaksjoner

A”

a)

Forklar hvorfor denne strukturen ikke er særlig god.

b)

Lag et bedre forsøk selv.

21.

Et regnskapssystem.

Et regnskapssystem er egentlig enkle saker dersom man ser bort fra alle kontroller, periodiseringer etc. i skal her se på data for et regnskapssystem, men ikke tenke på summeringer etc. Det som det er snakk om, er altså selve bilagene, med bilagsnummer, dato for føringen av bilaget samt bilagstekst (f.eks. "Betaling av .:"). Hvert bilag kan bestå av flere deler (bilagslinjer), på samme måte som f.eks. en faktura. For hver slik bilagslinje føres beløpet til en debetkonto og en kreditkonto. Man sier dessuten ra hvilken momskode som skal gjelde for denne bilags!injen (momskode 0 = ingen moms, 1 = momspliking 2 = mvesteringsavgiftsphktig) osv. z Lag en datamodell for et slikt system.

III.

Omtrent her stiger vanskelighetsgraden ett hakk ....

22.

Administrasjon av prosjekter.

rye Tr utv* ^ inSsarbeic|et i ulike virksomheter ved at en oppretter et eget prosjekt som står for . . V kf age et forenklet system for de administrative delene av dette. Vi tar ikke opp milepæler og delmål i prosjektet, men bare den personellmessige siden. Vi skal ha med opplysninger om de ansatte, de ulike avdelingene og de ulike prosjektene. Ta med vanlige opplysninger som nummer og navn, og for prosjektene også en kort beskrivelse. Vi må dessuten kunne '■egistrere hvilke personer som er med i de ulike prosjektene, og hvor mange timer det er planlagt at de skal ®.P J?r0Sle1k Vl skal ogsa kunne registrere hvem som er prosjektleder. Endelig skal vi ha med hvilken avdeling de ulike personer arbeider i, og hvilken avdeling som er ansvarlig for hvert prosjekt. a) Tegn datamodell for dette.

For hver uke rapporterer hver prosjektdeltaker hvor mange timer hun eller han faktisk har brukt på prosjektet må dessuten tenke på at de ulike personene i prosjektet har ulike utgifter i forbindelse med prosjektet (eller sagt med andre ord: de forbruker ressurser). Disse utgiftene kategoriseres etter M - maskinkostnader R reisekostnader, osv. Vi skal holde styr på hvor mange kroner som er forbrukt, og datoen for hver utgift. b) Utvid datamodellen med dette.

142

Kap. 13

TILLEGG B: OPPGAVESAMLING.

23.

Bilutleie.

a)

Et firma for bilutleie leier ut biler i forskjellige priskategorier. For hver bil man har, er det interessant å vite priskategori og pris. Som "bil" regnes også her f.eks. tilhengere o.L, som også er gruppert på pris­ kategorier. Når en kunde gjør en utleieavtale, kan den ofte bestå av flere deler samtidig, f.eks. bil nr. xx fra 01.09 - 03.09, samt tilhenger nr. yy samme tid og bil zz fra 06.09 - 09.09. Vi antar (temmelig urealistisk) at man allerede ved bestillingstidspunktet bestemmer nøyaktig hvilken bil (dvs. med et bestemt kjennemerke) man vil ha. Lag en datamodell som dekker dette databehovet.

b)

Hvis man tenker seg at denne datamodellen ble realisert i et informasjonssystem, ville man hatt mesteparten av grunnlaget for å lage fakturaer. Det bør være slik at systemet bør ha mulighet for å lagre fakturaer. Man ønsker det slik at fakturaen kan inneholde data fra flere utleieavtaler, men det kan også være at samme utleieavtale kan deles på flere fakturaer. Utvid datamodellen til å ta med dette også. (Det finnes en svært enkel løsning på dette.)

c)

Kan det være slik at selve utleien registreres på én kunde, mens en annen kunde får fakturaen? Kan man dele samme utleie på ulike firmaer? Utred dette og eventuelle følger dette får for datamodellen.

d)

Anta at du skulle lage en funksjonsorientert beskrivelse av det samme systemet, f.eks. via dataflytdiagrammer (DFD) eller virksomhetsgrafer (V-grafer). Pek på hvilke aspekter som ville bli vektlagt i så tilfelle. NB! Dette er avhengig av om slike ting er tatt opp i dette eller andre kurs.

24.

Programmer på TV.

For å være sikker at du skal få med alle TV-programmer som du ønsker å se, tenker vi at vi lager et system hvor data om alle TV-program blir lagt inn. Følgende er av interesse: Programtyper (f.eks. underholdning, krim, sport), selve programmet (bl.a. tittel og lengde i minutter) og når det ble vist (inkl, på hvilken TV-kanal). Noen programmer kan være del av en serie, men de fleste er frittstående program. Programmet kan også gå i reprise opptil flere ganger.

Diskuter ulike muligheter for datamodell i dette tilfelle. Du skal altså ikke primært til en fasit, men først og fremst diskutere de ulike mulighetene og problemene som finnes.

25.

Klasse - lærer - fag.

Ved en skole vil samme klasse ha flere lærere, hver klasse ha flere fag, og hver lærer (oftest) ha flere fag.

a)

(Svært enkel.) Tegn en datamodell som viser dette. Lag identifikatorer etter ønske.

b)

("Tenke-oppgave", som gir ny innsikt). Vi antar imidlertid følgende: Hver klasse har bare en lærer i hvert fag. Hvorledes kan dette formuleres i en datamodell?

143

Kap. 13

TILLEGG B: OPPGAVESAMLING.

IV:

Et hakk til ....

26.

Ambassadører (eksamen i systemering høst’89, SLHK, nå: Høgskolen i Buskerud, Ringerike).

Som mental forberedelse til denne oppgaven anbefales at du spiller Øystein Sundes plate "Ambassanova” (fra Gitarkameratenes kassett "Typisk Norsk"). H nuassanova (tra Norge har ambassader i de fleste europeiske land, samt i en del land utenfor Europa. For de land hvor Norge ikke har egen ambassade, er landet underlagt en norsk ambassade i et nærliggende land De ansatte ved ? ambassadene bhr forflyttet, både fra en ambassade til en annen, og mellom jobb på ambassader og hjemme i orge. Utenriksdepartementet ønsker nå å systematisere endel opplysninger som er relevante i forbindelse med ambassader og deres personell. Framstillingen under er naturligvis forenklet. torbmdelse med

a)

For hver ambassade vil det være av interesse å vite: hvilket land ambassaden ligger i adressen til ambassaden hvilke land som er underlagt denne ambassaden, jfr. innledningen. hvilke stillinger som finnes på hver ambassade. Det er her snakk om faste stillingsnavn (f.eks. ambassadør, 1 .ambassadesekretær, kontorassistent osv.)

For hvert land vil vi vite: hvilke naboland som dette landet har. kømn2 datam°d|ellso™ viser del,e-1 de"ne deloppgaven behøver du ikke å ta med minimum men uklarLter rteks±vererSOm "‘ m°de"en Ska' lageS el,er “ de‘ -

b)

For hver person som er ansatt/har vært ansatt, skal vi kunne finne fram: vanlige personalopplysninger (navn, adresse osv.) "Xls^toXrr^^ deieiSk7’ i’® hVOrg°dt De"e karaktcrlseres med stikkordene o dels , toodt eller flytende . Andre kategorier kan også være aktuelle nar (fra- evt også til) som personen jobbet ved de enkelte ambassadene, og hvilken stilline vedkommende hadde på ambassaden. S g

uteattfor tidem

“ 8'“ ambaSSade f°r ^eblikket-

moXTlen^kai min^mmn^pesTfiseres^verait^æ5^

om stillingen er

31 ^'SSe mOrnentene °gS^ kOmmer meddenne

c)

m d“Xderrvrisrlede5 dU reSSOne"e f°r ' 'ØSe PUnk‘b)- Gi °m mU,ig ,OrSkJdl'Se “iver

27.

Lov & dom. (eksamen i systemering vår'92, SLHK, nå: Høgskolen i Buskerud, Ringerike).

a)

NoreTf ek^“f* S°m Væ'e aktUe“e ' forbindelse med domfelte forbrytere i bare tar med d^ i r et,erforsknmS' Som ™nlig dreier det seg her om en forenkling, bl.a. ved at vi

persone medI norsk f Tl PerS°ner (ikke firmaer ol) og ved at vi ku"tenker P‘> personer med norsk fødselsnummer og lovbrudd som er gjort i Norge. P XutmXm°mur„Ve":vn)a

adresse og bostedskommune

flere temmeHo^ked a™65 f°rh°ld td en bestemt Person> selv om man i en del tilfelle vil ha temmehto like dommer. Det kan være interessant å ha opplysninger om dommen, som om den er

144

Kap. 13

TILLEGG B: OPPGAVESAMLING.

ubetinget eller ikke, eventuelt antall dager i fengsel osv. Dommene avsies på grunnlag av en eller flere registrerte lovbrudd. For lovbruddene vil dato, sted, samt en beskrivelse av lovbruddet være interessant. Lovbruddene kan grupperes i forskjellige kategorier (Bl = bilinnbrudd, RA = ran osv.) - og dette bør gjenspeiles i modellen. Det er av interesse å få med hvilket politikammer som registrerte det aktuelle lovbruddet. Dersom man tenker seg datamodellen som grunnlag for en database, bør man ha mulighet for å hente fram bl.a. telefonnummer til politikamrene, f.eks. slik at disse kan ringes raskt. Merk at vi i denne oppgaven antar at det kun er lovbrudd som fører til domfellelser som er tatt med, og at vi antar at et lovbrudd kun er utført av én person. Derimot kan det være at ett og samme lovbrudd kan trekkes inn i flere dommer (f.eks. at man første gang fikk betinget, men at man senere får en ubetinget dom). I et slikt tilfelle og i mange andre tilfelle vil det være av interesse at en dom kan referere til eventuelle tidligere dommer.

Dommene kan føre til soning (som regel i et fengsel). Under soningen vil man i en del tilfelle flyttes fra sted til sted (jfr. Arne Treholt). I tillegg til å vite hvilken dom en person som er eller har vært på soning soner for, er det derfor av interesse å få med fra- og til-dato for personen på soningsstedet. Vi holder i denne sammenheng såkalte soningsavbrudd utenfor. På samme måte som for politikamre, vil det være av interesse å ha en oversikt over de forskjellige soningsstedene. Lag datamodell for dette, og presiser de forutsetninger du har tatt.

b)

Et godt norsk rettsprinsipp sier: "Ingen soning uten dom". Forklar kort hvorledes dette prinsippet er avspeilet i datamodellen.

c)

(Uavhengig av resten av oppgaven). Vi har en datamodell med en l:m-relasjonstype, og bruker denne som grunnlag for å lage en database. Hvilken forskjell gjør det hvorvidt man på "maksimum 1 "-siden har minimum 0 eller minimum 1.

28.

Hønefoss International Business University (HiBu). (Eksamen i systemering, Høgskolen i Buskerud (HiBu), Hønefoss, vår'95) litt omarbeidet, siden oppgaven inngikk i et større oppgavesett.

Som kjent finnes det en rekke firmaer og organisasjoner, Friundervisningen o.l. som tilbyr kurs innen forskjellige områder. Vi skal se på et forenklet system for Hønefoss International Business University (HiBu).

Det skal lages en datamodell som illustrerer hvilke data som trengs for å administrere kurs i HiBu. Del a) gjelder kursene som sådan, mens del b) gjelder påmelding, betaling o.l. Du kan gjeme lage hele datamodellen samlet dersom du markerer hva som er spesifikt for del b).

a)

For hvert kurs som avholdes, må man ha et eller annet som identifiserer dette, samt kursnavn, starttid og -dato, max. antall deltagere og hvilket sted (inklusive romnummer) hvor kurset avholdes. HiBu bruker en del faste kurssteder (f.eks. skoler, kurslokaler, hotell o.l.) i distriktet, og modellen bør ta høyde for en oversikt over telefonnr, adresse o.l. til hvert av kursstedene. Det er viktig å ha med informasjon om hvilke lærere (navn, adresse, telefonnr etc.) som holder de forskjellige kursene. For mange av kursene er det snakk om at samme kurs holdes flere ganger, og gjerne gjentas hvert semester. Det kan imidlertid også være at samme kurs går på forskjellige steder eller at det settes opp parallelle kurs. Mange av kursene er også slik at de bygger på hverandre. Eksempelvis må du ha tatt KREPSFISKE-1 før du kan begynne på KREPSF1SKE-2. Endelig antar vi at de ulike kursene tilhører forskjellige kurskategorier, f.eks. SPR = språkkurs, MAT = matlagingskurs, PEN = pensjonistkurs etc. Dette vil være nyttig å ha med, bl.a. fordi denne kategoriseringen brukes i kurskatalogen, og fordi man ofte får spørsmål av typen kan du gi meg en liste over alle pensjonistkursene dere har dette semesteret"? Lag en datamodell som viser det som er beskrevet over.

145

Kap. 13

TILLEGG B: OPPGAVESAMLING.

For å organisere kursene må man naturligvis vite hvem som er påmeldt som deltager på de forskjellige kursene og påmeldingsdato. Vi antar her at en person som melder seg på flere kurs bare blir registrert en gang, med et entydig studentnr, samt med adresse, telefonnr. etc. I mange tilfelle skal firmaet betale kurset, og endel firmaer har ganske ofte kursdeltagere på HiBu-kurs. I de tilfellene hvor firmaet skal betale for kurset, må man derfor vite hvilket firma det gjelder, og man må ha med vanlige firmaopplysninger. Det skal være mulig å skrive ut fakturaer fra systemet, både til enkeltpersoner og til bedrifter. Det må kunne skrives ut fakturaer f.eks. for flere deltagere på samme kurs eller forskjellige kurs (f.eks. fordi firmaet vil ha en felles faktura) og med flere kurs på samme person. Vi antar at det må være mulig med purringer. Det er imidlertid bare aktuelt med en purring pr. faktura - hvis man ikke har betalt på tross av purring, blir man strøket fra kurset. Systemet skal gi grunnlag for å lage reviderte lister (bl.a. strykninger pga. manglende betaling) og kursbevis. Utvid modellen til å ta med dette.

c)

Ta for deg de utvidelsene du gjorde i punkt b) på nytt. For alle km-relasjonstyper skal du kort kommentere det valget du har gjort av minima (0 eller 1) på "I-siden" av relasjonstypen.

29.

Bilsalg- og servicesystem. (Eksamen i systemering, Høgskolen i Buskerud (HiBu), Hønefoss, høsf 95)

Anta at du har blitt engasjert til å lage en datamodell for et bilimportfirma. De ønsker å lage et system som skal plasseres ut til deres forhandlere rundt omkring i landet, og slik at systemet på en eller annen måte skal kunne ente data som gjelder andre forhandlere. Grovt sett skal systemet kunne gi oversikt over hvilke nye, usolgte i er som innes hos de forskjellige forhandlere og servicer og reparasjoner som er foretatt. Fremstillingen nødvendig^ 8VIS 1 ytterHgere attHbutter der hvor du sVnes det er Merk:

Minima identifikatorer og fremmednøkler skal være med overalt, verb/roller tas med der de ikke er helt opplagte.

a)

Oversikt over biler og salg. Systemet skal gi en oversikt over hvilke biler som til enhver tid finnes usolgt i de ulike forretninger med oversikt over merke (f.eks. Ford) og modell/type (f.eks. Escort CLX 16V/ANL). Poenget er at’ dersom en forhandler f.eks. i Hønefoss far forespørsel om en rød Escort av denne typen, og selv ikke ar denne inne, sa kan han søke for å finne ut om noen nærliggende forhandlere har denne slik at de kan avregne et slikt salg forhandlerne i mellom. Når bilen er solgt, skal man naturligvis registrere hvem som er eier av bilen (kunden) og hvilken forhandler den ble solgt av.

Lag en datamode11 som viser dette- Drøft relativt detaljert ulike mulige utforminger av denne modellen og konkluder opp med de valg du har gjort.

b)

Oversikt over eiere, service og reparasjoner. Den aktuelle bilen vil selvsagt kunne selges til andre etter en stund. For å kunne følge opp eierne f.eks. ved a gi dem spesialtiIbud, ved å kunne sende ut importørens informasjonsblad osv. ,vil importøren ogsa prøve a holde orden på hvem som til enhver tid eier bilen, og også slik at man kan finne ut når orskjellige eiere har eid den aktuelle bilen. I praksis får man greie på slike eierendringer enten ved at det sendes adresseforandring når man får informasjonsbladet, eller f.eks. hvis man ser at bilen har skiftet eier nar den kommer inn på service. Dersom bilen har endret eier på en slik måte at den nærmeste forhandler" er endret, må dette også tas med. Eksempel: Hvis en bil som ble kjøpt på øne oss r byttet eier til en person i Narvik, er det naturlig at man må kunne endre hvilken forhandle’ som skal følge opp denne bileieren.

146

Kap. 13

TILLEGG B: OPPGAVESAMLING.

Systemet skal også inneholde opplysninger om service eller reparasjon hos en av forhandlerne, slik at man i ettertid f.eks. skal kunne fa en opplisting over de servicer som er foretatt på bilen (fordel når man skal selge den). Ved en slik service eller reparasjon registreres det detaljert hva som skal gjøres (f.eks. cluchbytte, standard 15.000 km sjekk, eksosanleggbytte el.l.). Det er naturligvis slik at man forsøker å få gjort så mye som mulig når bilen likevel er inne til reparasjon. De enkelte standardoperasjoner (jfr. cluchbytte etc.) har sine standardpriser, men den virkelige prisen kan naturligvis bli noe høyere eller lavere enn denne. Vi antar at standardprisen for slik standardoperasjoner er uavhengig av modell. Vi antar at beskrivelsen over er så detaljert at det skal kunne skrives ut fakturaer på grunnlag av dette. Det skal kunne være mulig at en annen enn bileieren betaler fakturaen (f.eks. at firma betaler), samt at en faktura skal kunne gjelde flere reparasjoner/servicer.

Utvid datamodellen til å dekke dette. Drøft de momentene som du var i tvil om.

30.

Kontroll av matvarer. (Eksamen i databaser, Høyskolen i Østfold, Sarpsborg, høst'96).

Som kjent utfører Statens Næringsmiddeltilsyn en omfattende kontroll av mat som selges i Norge. Vi skal systematisere en del av de data som er interessante i denne sammenhengen. Oppgaven er forenklet, og muligens også noe urealistisk i forhold til hvorledes dette skjer i virkeligheten.

Det testes innhold av en rekke forskjellige stoffer som finnes i matvarer, f.eks. protein, ulike hjelpestoffer etc. Det brukes bestemte forkortelser på de forskjellige stoffene, slik som Pr = Protein, E33O = sitronsyre etc. Stoffene er svært ulike med hensyn til konsentrasjon o.l., slik at vi også må ha med en måleenhet (mg = milligram, g = gram, p = pund m.m.). For at man skal kunne få en standardisering av slike måleenheter, må "settet av lovlige måleenheter" og deres tilsvarende forkortelser finnes i systemet. Selve målingen oppgis alltid ut fra 100 gram av den aktuelle matvaren.

En kompliserende faktor er at man for noen matvarer gjør en "grovmåling", f.eks. kun på protein generelt, mens man på andre varer gjør en detaljkontroll, f.eks. på ulike typer av protein. Det er derfor slik at et stoff må kunne detaljeres i ulike undergrupper av stoffer, som igjen må kunne detaljeres i nye undergrupper osv. i et vilkårlig antall nivåer. For hver matvare trengs det en kode, norsk og engelsk navn, samt en oversikt over hvilke stoffer som normalt skal testes for denne matvaren. For hvert stoff som testes i hver matvare skal man også ha med verdier for mini­ mums-, normal- og maksimumsinnhbld.

a) Lag en datamodell for de data som trengs ifølge spesifikasjonen over.

De prøvene/testene vi skal konsentrere oss om her, er prøver som tas med fra faste prøvesteder, som f.eks. faste butikker eller slakterier. Det skal være mulig å lage enkle planer for slike prøvebesøk, f.eks. at kontrollinspektør Anne Helene Olsen (AHO) skal ta med seg Gulbrandsdalsost, kjøttdeig og wienerbrød fra Prix på Torp den 19. desember 1996. b) Utvid datamodellen til også å ta med dette.

Når prøvene tas med, kan det også gjøres notater i forbindelse med besøket, både generelt om besøket og knyttet spesielt til hver av matvareprøvene. Prøvene tas så med til laboratoriet, hvor det som regel foretas tester som er nevnt over for hver matvare. Det kan imidlertid gjøres flere prøver, og det hender at noen av normalprøvene kuttes ut. Resultatet av disse prøvene lagres, bl.a. for å kunne gjøre sammenligninger over tid, og for å kunne rapportere resultatene tilbake til de enkelte prøvesteder. d) Utvid datamodellen til også å få med disse forholdene.

147

Kap. 13

31.

TILLEGG B: OPPGAVESAMLING.

Messearrangement. (Eksamen i databaser, Høyskolen i Østfold, Sarpsborg, høst'97, Eksamen i systemutvikling, Høgskolen i Buskerud, Ringerike, vår'96).

Siom kjent arrangeres det messer i en rekke messehaller o.l. rundt omkring i landet. Det skal lages et svstem for ulike foX ’ Pr°dUkter SOm Sti"es Ut 0SV' Hensik,en er ‘‘ kunne a et system som kan brukes til to mlssTn 8rUnn'ag for l"ike Utskrifter ,H en messekatalog sont skal trykkes og deles ut til besøkende på UlvuDvO. * ’ h‘„XSte?e7kal kTne h™?65 avadministrasjonen på messen, slik at de f.eks. raskt skal kunne finne fram til hvilke stands som har produkter innen en gitt kategori el.l. «XZmår"1'31" firma0Versikten- firmakategoriene og rommene, skal systemet gjelde bare for en messe i

r88ende.he' ei' natul;iigv's hvilke firmaer som deltar, og hvilke stands som finnes. Om firmaer skal n lagre firmanr, firmanavn, kontaktperson, adresse, postnr, poststed og telefonnr, og hvilken firmakateaori (firmakategorikode, firmakategorinavn) som firmaet hører under. Hver stand tildeles et standnr og vi er 8 uten interessert i hvor mange kvadratmeter standen er, samt en kort beskrivelse av eventuelle tpesialavtaler som er gjort (f.eks. at de har fått tillatelse til å bruke et musikkanlegg). ' spesialavtaler Som oftest er det bare ett firma pr. stand, men det hender også at flere firmaer stiller ut på samme stand Hvis de er flere firmaer som stiller ut på samme stand, skal disse betraktes som fullverdige firmaer men ett av dem er likevel hovedansvarlig for standen. Et firma kan også delta på flere stands.

En del av messekatalogen gjelder de produktene som stilles ut. I tillegg til produktnavnet skal man kunne ha med kort beskrivelse av produktet, og hvilken produktkategori (mfd kategorik de o

flere firmaer stiller ut det samme produktet, er det viktig at det blir betaktet som ett produkt ikke som pr. firma som stiller det ut. Vi vil videre vite hvilke firmaer som har de forkjellige produktene utstilt 02 hvis irmaet er representert pa flere stands, hvilke(n) av disse som produktet er stilt ut på. ’ 8’ Medarrangøren har en del rom til rådighet, slik at finnene kan leie disse for å kjøre spesielle produktpresentasjoner. For planleggig av dette må systemet inneholde opplysning om størrelsen nå rommet ma simak antall personer som det kan ta, og eventuelle spesialiteter (somfæks. ft det fX en videokanon

pre enteres) oghvilk^fnma s P™duktpresentasj°ner (‘^punkt, hvilket rom, hvilket produkt som skal picsemeresj, og hvilket turna som står for presentasjonen.

tX“meéd Maktima’ minima’ ide"tifto‘°™ «g fremmednøkler skal være med. verb/ro ler tas med dersom det ikke er opplagt. Det er ønskelig med forklaringer på hvorledes du kom fram til forslaget d.tt, bl.a. opplegget rundt hvilke produkter sotn vises på hvilke (dele! av en) stand(s)

32.

Datamodellering i Stortinget. (Eksamen i databaser, Høyskolen i Østfold, Sarpsborg, høst'98).

Det ska! lages en datamodell som viser en del forhold rundt representanter, partier saker etc nå Stortineet Vi

“ x—r ~samme pani heie

(det -

a)

løpenummer), navn, adresse, postnr og -sted samt hvilket fylke (fylkesnr og -navn) og parti som de parthiavnetTf eks A' “Tb man ha med både den vanii®e forkortelsen for partinavnet og det fulle p rtinavnet (f.eks. Ap - Arbeiderpartiet, Sp - Senterpartiet), samt adresse med postnr og poststed for ovedkontoret. Videre skal vi ha med hvem som er parlamentarisk leder for hvert parti Vi skal også ha med nar representantene var på Stortinget. Noen kan ha vært der sammenhengende i hele perioden mens andre har vært fra og til (permisjoner etc.), slik at de altså har et eller flfre slike tidsrom som

148

Kap. 13

TILLEGG B: OPPGAVESAMLING.

representanter. Vi skal vite fra- og evt. til-datoer for hver slikt tidsrom. For vararepresentanter skal det også vises hvem han/hun er vikar for. Dette kan variere fra gang til gang. b)

For å kartlegge hvilke interesser hver av stortingsrepresentantene har, er det laget en liste med interesser, f.eks. utenriks, naturvern, historie, skipsfart osv. Det skal lages en oversikt over hvem som er interessert i hva, og det skal sies fra "grad av interesse" for hver av disse, hvor gradene han være S stor, M - middels og N - noe interesse. Denne oversikten kan tenkes brukt til å gi riktig og riktig mengde informasjon til hver enkelt representant.

c)

De ulike sakene som tas opp i Stortinget tildeles et saksnummer, samt en tittel på saken. Man vil dessuten at en sak skal kunne referere til en eller flere andre saker. Vi skal også ha med hvem som tok ordet i hver sak. I hver sak blir det dessuten oppnevnt en representant som hovedtalsmann for hvert parti. Det er viktig at det blir kontrollert at hvert parti bare har en hovedtalsmann pr. sak.

d)

Modellen inneholder ett eller flere sett av kandidater for ekvivalente stier. Påpek disse, og sett opp kriteriet (i vanlig norsk) for at disse virkelig er ekvivalente. (Alternativt: hvis du ikke finner noen slike i din modell kan du beskrive generelt hva ekvivalente stier går ut på. Dette vil imidlertid ikke gi full uttelling).

e)

I forbindelse med hovedtalsmann har du forhåpendligvis kommet fram til en entitetstype med attributtene partikode, saknr, rcpresentantnr, hvor altså de to første utgjør identifikatoren. Analyser denne entitetstypen for å finne hvilken normalform den er på. Gå inn på hver av normalformene og begrunn hvorfor den er/ikke er normalisert ifølge denne normalformen.

Oppgave 33.

Administrasjon av prosjekter - Chen-form.

Ta for deg oppgaven om administrasjon av prosjekter på nytt, tegn den på Chen-form.

Oppgave 34.

Administrasjon av prosjekter - NIAM-form.

Ta for deg oppgaven om administrasjon av prosjekter på nytt, tegn den på NIAM-form.

Oppgave 35. NIAM-skranker. a)

Lag en liten NIAM-modell som viser at en stortingsrepresentant må være medlem av det partiet hun/han er valgt inn for.

b)

Vis forskjellen på dette og at en stortingsrepresentant må være medlem av et eller annet parti.

c)

(Fortsett ut fra modellen i a)). En stortingsrepresentant blir alltid plassert i en stortingskomité (finanskomitéen, justiskomitéen osv.). Vis dette på modellen.

d)

En av medlemmene i hver komité blir valgt som leder for denne komitéen. Vis dette.

e)

Vis at en person ikke kan være (aktiv) stortingsrepresentant samtidig som hun/han er statsråd (dvs. bestyrer et departement).

149

Kap. 14

TILLEGG C: KORT LITTERATURLISTE.

14. TILLEGG C: Kort litteraturliste. [Andersen 1988] Andersen, Erling S: Systemutvikling. NKl-forlaget, 1988. lærebok i systemutvikling for høyskoler. God til oversikt over systemutvikling generelt, men svært lite omfattende på datamodellering. [Bostrøm 1993] Bostrøm, Edgar. Datamodeller og relasjonsdatabaser: kardinalitet, attributtegenskaper og fremmednøkkelstrukturer. Upublisert materiale, 1993.

[Bostrøm 1998] Bostrøm, Edgar; Kolderup, Erik: Systemutvikling, 2.utgave. Gyldendal, 1998. lærebok i systemutvikling for videregående skole. Inneholder også en mer elementær innføring i datamodellering og normalisering. [Date 1990] Date, Chris: Databases. Selected Writings. Addison-Wesley, 1990. [Date 1995] Date, Chris: Introduction to Database Systems. 6.utgave. Addison-Wesley, 1995. Omfattende standardverk innen databaser. [Halpin 1995] Halpin, Terry: Conceptual Schema & Relational Database Design. 2.utgave. Prentice Hall, 1995 Omfattende innføring i NIAM/ORM.

[Kent 1978] Kent, William: Data and Reality. Elsivier Science Publishers, 1978. inneholder inteiessante diskusjoner om data , bl.a. med en grunnleggende diskusjon. [Skagestein 1996]: Skagestein, Gerhard: Dataorientert systemutvikling. Universitetsforlaget, 1996. tar opp ER-dialekten i de første sidene, men går så over til NIAM. Bra supplement og noe mer omfattende denne boka.

[Sowa 1984] Sowa, J. F. : Conceptual Structures. Information Processing in Mind and Machine. svært grunnleggende diskusjon med emner som strekker seg fra filosofi og psykologi til formelle sprak.

[Sundgren 1992] Sundgren, Bo: Databasorienterad systemutveckling. Studentlitteratur, 1992. Noe mer formell lærebok i datamodellering, bl.a. med vekt på grunnleggende begrep. [Øren 1985] Ole Øren: Datamodellering - en innføring. NKS-forlaget, 1985. [Øren 1999] Ole Øren. Semantisk datamodellering, 2. utgave Tano-Aschehaug, 1992.

150

Kap. 15

STIKKORDSREGISTER

15- STIKKORDSREGISTER i l-er sti.......................................................................... 89; 90; 93; 94

A alle-til-alle............................................................... 82; 83; 133; 134 atomær............................................ 28; 29; 30; 31; 47; 48; 54; 129 avledbart attributt............................................................................ 23 avledet relasjonstype............................................................... 43; 92

B bill-of-material.................................................................................. 50 både-og........................................................................ 123; 124; 127

c Chen............................................. 3; 4; 47; 85; 115; 116; 117; 122

kardinalitet.................................................................10; 15; 62; 150 kartesisk produkt....................................... 82 kodetabell......................................................................................... 69

M Maldivene.......................................................................................... 3 matriseform............................................................................... 48; 80 minimalitetskravet........................................................................ 24

TV natural join.................................................................................... 134 nettverk............................................. 4; 17; 50; 77; 79; 80; 81; 106 NIAM3; 4; 85; 114; 117; 119; 121; 122; 125; 126; 127; 135; 150 nullverdi (NULL)............. 23; 24; 27; 28; 57; 62; 65; 67; 72; 77 nødvendig-egenskapen23; 24; 25; 27; 28; 51; 55; 61; 63; 65; 102;105; 120; 127

D databasesystem3; 6; 7; 30; 31; 33; 77; 92; 96; 105; 106; 107; 108;113 Det store kategoriseringssporsmålet.............................................88 determinant.............................................................. 98; 99; 100; 132 domene.................................. 22; 31; 32; 33; 37; 69; 86; 126; 139

E egenrelasjon............................................................................... 56; 78 ekvivalente stier...................... 70; 71; 89; 90; 91; 93; 94; 95; 149 enten-eller.............................................................. 71; 123; 124; 127 entitetisering44; 47; 48; 50; 51; 52; 56; 58; 59; 60; 63; 73; 79; 84; 105;113;116; 117;126; 127 entitetsintegritet......................................................... 25; 26; 27; 72 entydighet........................................................................ 26; 27; 117 enverdideterminering.....................................................................133 ER-notasjon................................................................................. 3; 85

F flerverdideterminering.................................................................. 133 fremmedattributt..................................................... 9; 22; 26; 53; 55 fremmednøkkel; 9; 10; 11; 28; 31; 35; 46; 50; 53; 54; 55; 56; 57; 58; 59; 60; 61; 62; 63; 71; 72; 78; 83; 84; 85; 86; 87; 89; 91; 94; 95;96;105; 106; 109;116; 127;130;137;139;140; 146;148 først-siden..............................................................................123; 127

hierarki................................................................ 44; 45; 78; 81; 104 historikk..............................................................39; 49; 60; 67; 112 hode-linje-struktur........................................................................... 39

identifikator4; 9; 11; 23; 24; 25; 26; 27; 28; 31; 35; 46; 53; 54; 55; 56; 58; 59; 60; 61; 62; 63; 65; 67; 71; 72; 75; 76; 77; 78; 83; 84; 85; 87; 94; 95; 96; 97; 99; 100; 102; 105; 116; 127; 128;129;130;131;132;133;137;139;140;143;146;148; 149 inkonsistens.......... 19; 20; 23; 42; 43; 81; 89; 97; 101; 105; 129 irredusibilitet................................................. 24; 25; 26; 27; 28; 85 iterativ prosess...................................................................... 104; 107

K

primæmokkel pseudoentiteter

24; 26; 27;28;57 35

R redundans. 15; 19; 20; 36; 81; 86; 89; 93; 97; 99; 101; 129; 133 redundant................................................................19; 43; 69; 92; 93 referanseintegritet................................................... 61; 62; 110; 139 regel og unntak............................................................................... 69 relasjonsbegrepet i matematikk................................................... 37 repeterende..........................................29; 30; 31; 56; 70; 117; 129 rettet graf....................................................................................79; 80 reverse engineering.............................................................. 107; 108 rolle8; 11; 34; 43; 67; 68; 85; 86; 87; 116; 118; 120; 122; 137; 138;146;148

sammenkoblingsfellen (the connection trap)............................. 65 sammensatt identifikator......................................... 24; 25; 59; 130 semantisk datamodell................................................. 6; 32; 96; 102 skjermbilde....................................................... 4; 77; 109; 110; 113 SQL.......................................................................... 6; 30; 62; 77; 78 standardverdi...................................................................... 69; 70; 74 supernøkkel...................................................................................... 27 svak entitetstype........................................................................... 117 svak gruppering............................................................................... 66 symmetrisk..................................................... 52; 57; 58; 63; 80; 81 systemavgrensning.......................................................................... 12

tidsdimensjon/tidsperspektivet............................... 39; 40; 93; 105 trigger......................................................................................... 66; 92

ubestemt relasjonstype..................................................... 62; 68; 74 undertyper...................................................................................... 115 unikhet (entydighet)...................................................27; 28; 57; 76 Universe of Discourse (UoD)..................................................... 12

V vanligvis-regel................................................................. 41; 42; 127 verb/rolle....................................................8; 11; 34; 137; 138; 146 verbal..................................................................11; 40; 86; 105; 113

kandidatnøkkel ...4; 23; 25; 27; 28; 99; 100; 122; 131; 132; 139

151