Normalisering av objektorienterte systemer

Presentasjon om: "Normalisering av objektorienterte systemer"— Utskrift av presentasjonen:

1 Normalisering av objektorienterte systemer
Knut W. Hansson Førstelektor Høgskolen i Buskerud Jeg oppdager – fra tid til annen – at studentene gjør noe dumt. Jeg ser at konsekvensene er uheldige, men kan ikke fortelle dem hvordan de må tenke for å unngå det. Hvilke ”regler” kan jeg gi dem? Studentene lager ofte ”håpløse” OO-modeller med stor redundans. Våre cases har mye data som skal lagres, oglikner på datamodelleringsoppgaver. Da setter jeg meg ned og tenker og skriver til studentene. De gir tilbakemeldinger, spør, bruker og etter hvert blir det til noe. Dette har foreløpig ikke vært igjennom denne kvalitetssikringen. Presentasjonen har vært holdt for kolleger ved Institutt for Informasjonsteknologi ved Høgskolen i Buskerud, som ga mange nyttige tilbakemeldinger. De er nå innarbeidet i denne presentasjonen.

2 Behovet Normalisering av RDBMS reduserer unødvendig redundans
Også OO lagrer data OO er annerledes pga teknologiske forskjeller Finner ikke teori på området Normaliseringsteorien for RDBMS er solid underbygget og vel utprøvet Bygge normaliseringsregler for OO på RDBMS? ”Normalisering” av modeller for relasjonsdatabaser (RDBMS) for å unngå unødig redundans er kjent og vanlig. Det er meget god teori på feltet. Også objektorienterte systemer (OO) lagrer data. Det er stor forskjell på systemene som modelleres: (1) tekniske systemer (automater, pasientovervåking o.l.) der hvert objekt i OO-modellen representerer en fysisk ting  Lite lagring og opplagt struktur (2) administrative systemer  Meget lagring og ikke selvsagt struktur. I lærebøker, kurs, foredrag osv er det mest av den første kategorien. Hvis administrative systemer er med, så er eksemplene ofte trivielle.  Jeg må skrive noe selv. Jeg tenker at man kan bygge på normaliseringsreglene for RDBMS. De er vel underbygd og utprøvde og skal løse samme problem! KWH, august 2003 Normalisering av OO 2

3 Noen forskjeller Entiteter lagres gruppert i tabeller (relasjoner)
RDBMS Entiteter lagres gruppert i tabeller (relasjoner) Entitetene knyttes sammen med logiske referanser Data og program holdes logisk atskilt En tabell kan ikke ”inneholde” en tabell Dataene struktureres separat (”datamodellering”) OO Objekter lagres hver for seg Objektene knyttes sammen med direkte referanser Data og program er logisk samlet Et objekt kan ”inneholde” et annet objekt Data og program struktureres i samme modell (”objektmodellering”) OO ≠ RDBMS, jfr foilen. Selv om data og program (attributter og metoder) logisk ses som en enhet i OO, vet vi at de rent faktisk lagres hver for seg i RAM. I mer utviklede RDBMS finnes triggere, dvs. beskrivelse av handlinger som skal gjøres når noe bestemt skjer med dataene i databasen. Jeg anser dette for å være noe annet enn metodene i OO, bl.a. fordi de ikke håndterer meldinger fra andre objekter slik metodene i OO gjør. KWH, august 2003 Normalisering av OO 3

4 Antall instanser RDBMS Funksjonalitet og data holdes atskilt
Hver tabell kan ha flere linjer Alle tabellene skal normaliseres OO ”All” funksjonalitet skal legges til objekter Har ofte klasser med bare ett objekt (f.eks. ”lokal printer”, ”system-administrator”) Ett attributt kan representere mange objekter i en struktur I OO kan ett, enkelt attributt vise til en liste, en mengde, en bag, en array osv som inneholder mange objekter. Selv om det altså bare lages én instans av en klasse, kan denne ene instansen inneholde mange objekter. Det sies ofte på konferanser at ”god programmeringsskikk” i OOP er å legge funksjonaliteten så nær dataene som mulig – helst i samme objekt (klasse). Det gir (1) bedre modularitet  Enklere vedlikehold og (2) bedre informasjonsskjuling  Enklere vedlikehold. Da vil modelleringen av data direkte påvirke programstrukturen (og omvendt). RDBMS modellerer sjelden tabeller som bare skal ha én linje (én instans) – de kan ofte legges i programmet. OO har ofte klasser med bare én instans. De kan jo ikke gi redundans = ”Glem dem”  Regel 1. Regel 1: Normaliser bare klasser med flere objekter, men vær spesielt oppmerksom på at ett attributt kan representere mange objekter KWH, august 2003 Normalisering av OO 4

5 Transiens/persistens
RDBMS Alle data i modellen skal lagres – det er arkivet selv vi modellerer Midlertidige og transiente data/variable modelleres ikke OO Alle objekter modelleres Bare persistente objekter skal lagres Transiente objekter kan bare gi midlertidig redundans OO skiller mellom transiente og persistente objekter. Alle må være med i modellen, men bare de persistente skal lagres. I RDBMS modelleres bare lagringsarkivet = ”alle data i modellen skal lagres”. Transiente objekter kan gi (midlertidig) redundans i RAM, men det får neppe(?) de samme uheldige konsekvensene og kan ”glemmes”  Regel 2. Merk at også RDBMS har transiente data, f.eks. views og ad hoc søk, men vi tar dem ikke med i modellen på samme måte. Forskjellene er bl.a. også at: i RDBMS lagres data på eksternt lagringsmedium. De havner i RAM uten at vi bryr oss om strukturen på lagringsmediet i OO ligger data i RAM med struktur (referanser mellom klasser/objekter) og de kan lagres på ytre lagringsmedium Regel 2: Konsentrer innsatsen om persistente klasser KWH, august 2003 Normalisering av OO 5

6 Entitets-, kontroll- og grenseklasser i OO (Booch)
Entitetsklasser modeller objekter i omverden Kontrollklasser koordinerer og styrer dynamisk – mest i RT systemer Grenseklasser er på ”innsiden” av systemet og representerer/håndterer omgivelsene på ”utsiden” Alle disse kan være persistente, men entitets-klassene instansieres mest Mange deler klassene inn i tre grupper (se foil). Det blir flest instanser av entitetsklassene  Vi bør konsentrere innsatsen om dem (men i prinsippet bør alle bearbeides). Eksempel – se ”Parkeringsautomat” på neste foil. Kontrollklasser er først og fremst aktuelle når det opereres med flere tråder eller prosesser og asynkrone kall (meldinger), det vil gjerne si tekniske RT-systemer. I administrative systemer er de fleste kall (meldinger) synkrone, og det blir ikke behov for tidsmessig koordinering. Regel 3: Normaliser alle persistente klasser, eller i alle fall entitetsklassene KWH, august 2003 Normalisering av OO 6

7 Parkeringsautomat (eksempel)
P_Salg er entitetsklasse og persistent. ControlUnit er kontrollklasse som sikrer at de andre objektene opererer i riktig rekkefølge, mens de øvrige er grenseklasser. KWH, august 2003 Normalisering av OO 7

8 Assosiasjonsklasser RDBMS
Mange-til-mange assosiasjoner må entitetiseres Den entitetiserte tabellen inngår i normaliseringen OO Mange-til-mange assosiasjoner kan realiseres direkte Evt. som assosiasjonsklasse Får mange instanser Se eksempel ”Aksjefond” (neste foil). Regel 4: Normaliser også assosiasjonsobjekter, og med særlig oppmerksomhet og kontroller at det ikke mangler en assosiasjonsklasse (da finnes isteden attributter som beskriver assosiasjonen). KWH, august 2003 Normalisering av OO 8

9 Aksjefond (eksempel) KWH, august 2003 Normalisering av OO 9
Eksemplet ”Aksjefond” til forrige foil. Øverst til venstre er eksempelet modellert slik det er naturlig i OO, med assosiasjonsklasse (en undergruppe av entitetsklasser) som lagrer andelsprosenten for hver kombinasjon Eier/Aksjefond. Nederst til høyre er eksemplet modellert uten assosiasjonsklasse. Mange-til-mange-relasjonen EierAksjefond er isteden modellert med to indre klasser som begge har attributtet prosent. Dette er redundant, men denne redundansen er vanskelig å finne, særlig hvis man tilfeldigvis velger forskjellige navn på de to prosent-attributtene. KWH, august 2003 Normalisering av OO 9

10 Metoder (funksjonalitet)
RDBMS Alt er data OO Både data og metoder i samme objekt Objektene inneholder referanse til, eller kopi av koden Evt. kopier av koden er transiente Også metoder kan være redundante f.eks. hvis man legger samme kode helt eller delvis i flere subklasser istedenfor i metaklasse. Det er likevel en vesentlig forskjell på data og metoder: Man vil aldri lagre mange instanser av samme kode. Når man skal bruke en RDBMS, og først har valgt å foreta datamodellering, så spiller det liten rolle for sluttresultatet i hvilken rekkefølge man arbeider med attributter, relasjoner og entiteter. I OO-modellering, kan man velge om man vil arbeide entitetsorientert eller funksjonsorientert, fra utsiden (grenseklasser) eller innsiden (entitets- og kontrollklasser). I administrative systemer, der enn god datastruktur ofte betyr mer for drift og vedlikehold enn funksjonaliteten, foreslår jeg her entitetsorientert arbeid: Begynn med entitetsklassene og legg til metodene etterpå. (Jeg har ikke noen nærmere begrunnelse for dette, men det stemmer med det som ofte anbefales for slike systemer.) I tillegg anbefaler jeg også normalisering før metodene legges til – det kan bli nødvendig å flytte attributter fra en klasse til en annen under normaliseringen. Jeg innser likevel at nye attributter kan komme til fordi en metode krever den, f.eks. til mellomlagring av verdier. I slike tilfelle vil jeg anbefale at man igjen normaliserer dataene, altså en iterert fremgangsmåte. Det kan også nevnes at i simuleringssystemer, kan man skille mellom objekter som ”deltar i modellen” (de er aktive komponenter og ofte modell av virkelige objekter) og de som bare er ressurser for dem (som f.eks. kontrollobjekter, objekter som tar vare på mellomresultater, lager statistikk osv). Det anbefales da å starte modelleringen med dem som ”deltar”. Regel 5: Normaliser bare dataene, ikke metodene. KWH, august 2003 Normalisering av OO 10

11 Private data I OO kan data skjules i objekter som Private og det er generelt anbefalt Normalisering kan føre til flytting av data, så metoden(e) ”mister dem av syne” Da må Hele/deler av metoden(e) flyttes, eller Dataene gjøres synlige Hvis metodene er lagt til før normaliseringen (noe jeg ikke anbefaler) så kan både metoder i den klassen der dataene var før flyttingen ”miste dem”, men også kall fra andre klasser kan gå galt. Det er uheldig å gjøre dataene synlig utenfor klassen – det fører til ”patologiske koblinger” mellom objekter – ett objekt kan endre data i et annet  Tungt vedlikehold. KWH, august 2003 Normalisering av OO 11

12 Arv Arv kan skape egne problemer
Attributtene fra metaklassen arves av subklassen, men oftest uten at den uttrykkelig skrives inn der i modellen De arvede attributtene kan gi redundans, hvis de er funksjonelt avhengige av attributter der, eller de er determinander for attributter der (alene eller sammen med andre attributter der) Se eksempel ”Arv” på neste foil. Regel 6: Start normaliseringen øverst i arvehierarkier og ta med alle arvede attributter under normaliseringen av subklasser. KWH, august 2003 Normalisering av OO 12

13 Kunder med arv (eksempel)
Hvis man her normaliserer attributtene postNr og postSted allerede i klassen Kunde, vil det som arves (en referanse til objektet med de to attributtene) ikke være redundant. Attributtet årsomsetning må tas med i analysen av underliggende. Det kan f.eks. godt tenkes at årsomsetningen determinerer rabatten for Kontantkunder eller kredittgrensen for Kreditkunder. Det kan være lett å overse hvis ikke alle arvede attributter tas med i subklassene. KWH, august 2003 Normalisering av OO 13

14 Heath’s regel for ikke-taps projeksjon
Grunnlaget for det som gjøres under normaliseringen ”Enhver relasjon R(A, B, C) der R.B er fullt funksjonell avhengig av R.A kan alltid ”deles” i to relasjoner R1(A, B) og R2(A, C) uten at informasjon går tapt” Objekter kan deles på samme måte. Metodene må da også deles, omskrives eller flyttes til metaklasse Regelen antas kjent. Objekter kan også deles med projeksjon, på samme måte som tabeller i RDBMS. KWH, august 2003 Normalisering av OO 14

15 Redundans (”overflødighet”)
= Når noe lagres dobbelt Problem med oppdatering konsistens lagringsplass Mulige fordeler med raskere respons sikkerhet Noe redundans kan ikke unngås Disse problemene er vel kjent fra RDBMS og gjelder fullt ut også for OO-systemer KWH, august 2003 Normalisering av OO 15

16 Normalformer i RDBMS Normaliseringen skal fjerne unødvendig redundans.
Normalisering i seks trinn etter normalform: 1NF, 2NF, 3NF, BCNF, 4NF og 5NF. Oppstått over tid. Tungvint, vanskelig å huske og kun av historisk interesse! 5NF påtreffes ikke i praksis – 4NF er i praksis svært tilstrekkelig. KWH, august 2003 Normalisering av OO 16

17 ”The Quick Hansson Way for Real Experts!”
STEP A ‑ "DATABASESYN": Gjør om modellen slik at: Alle entitetstyper har minimal identifikator, og Alle relasjonstyper er eksplisitt gitt ved fremmednøkkel, og Alle attributtyper er atomære STEP B ‑ 4NF: Gjør om modellen slik at Alle determinander er kandidatnøkkel Dette har vist seg lettere å lære/huske enn den vanlige måten å gå gjennom normalform for normalform (fra 1NF til 5NF). Reglene er målorientert istedenfor aktivitetsorientert. Noe løses ved projeksjon, annet med andre teknikker – det avhenger av situasjonen (slette, flytte, projisere, entitetisere, splitte attributt, innføre nye attributter osv.) Reglene har vært kjapt sjekket av C. J. Date og brukt mye av studenter og meg. Jeg tar utgangspunkt i disse reglene her. KWH, august 2003 Normalisering av OO 17

18 Mål 1: Alle entitetstyper har minimal identifikator
Entiteter i RDBMS har ikke alltid ID-attributt slik de må ha – man må føye til én under modelleringen Objekter i OO kan alltid unikt identifiseres med minneadressen selv om de ikke har noen ID-attributt Selv om alle objekter har en ID, er det ikke sikkert at den er kjent for programmereren/brukeren. Det kan genereres såkalte ”anonyme objekter” der minneadressen kun er kjent for operativsystemet eller runtime systemet. Når dataene skal lagres i en RDBMS, foreslår noen forfattere å legge til en eksplisitt, logisk ID for alle objektklasser – den får da navn etter klassen (så f.eks. klassen Person får attributtet personID). Ingen regel – dette er automatisk oppfylt i OO-systemer (men må oppfylles hvis dataene skal lagres i en relasjonsdatabase) KWH, august 2003 Normalisering av OO 18

19 Mål 2: Alle relasjonstyper er eksplisitt gitt ved fremmednøkkel
Relasjonstyper i RDBMS = Assosiasjoner i OO Realiseres enkelt i OO-systemer, f.eks. med liste, mengde, bag eller array – også mange-til-mange (liste osv med pekere/referanser) Alle referanser bør vises eksplisitt under normaliseringen, da de kan gi opphav til redundans Se eksempel ”Aksjefond” på foil 7 hvordan dette kan gjøres (selv om det der er en redundant variant). OO har fysiske referanser, som er mye raskere enn logisk peker med fremmednøkkel i de fleste tilfelle. Ingen regel – dette oppfylles enkelt i OO-systemer under realiseringen når referanser til andre objekter vises i modellen. KWH, august 2003 Normalisering av OO 19

20 Mål 3: Alle attributtyper er atomære
I OO kan attributter være komplekse Problemet er ”skjult redundans” I OO må kravet gjelde for ”bladene”, dvs de enkle, ustrukturerte attributtene som inngår i de komplekse, på laveste nivå Regel 7: Alle enkle (ustrukturerte) attributter skal være atomære – anvendes evt. rekursivt på alle strukturerte attributter som inngår i normaliseringen. KWH, august 2003 Normalisering av OO 20

21 ”Kunde med indre klasse” (eksempel)
Til venstre er klassen Kunde vist med en indre klasse Adresse som ikke er nærmere spesifisert. Problemet er at dette skjuler redundans, fordi attributtene postNr og postSted inngår i klassen Adresse. I midten er modellen vist med den indre klassen Adresse spesifisert. Det er da lett å se at de er avhengighet mellom attributtene postNr og postSted og det blir enkelt å normalisere modellen slik det er vist til høyre. KWH, august 2003 Normalisering av OO 21

22 Mål 4: Alle determinander er kandidatnøkkel (1)
OO har ikke nøkler, men har determinander Determinandene signaliserer uønsket redundans også i OO Klasseattributter (Static) gir ikke redundans – de har bare én instans Objektattributter gir redundans når de bare determinerer noen av de andre objektattributtene Hvis et attributt determinerer objektets ID-attributt er det å oppfatte som en ”alternativ nøkkel” i RDMBS-terminologi. Midlertidig regel 8: Alle objektattributter som er determinander, må determinere alle de andre, enkle objektattributtene i klassen inklusive objektets ID-attributt. KWH, august 2003 Normalisering av OO 22

23 Mål 4: Alle determinander er kandidatnøkkel (2)
Problem: Komplekse attributter. Usikker teori, men Et objekt kan inneholde to like objekter blant de strukturerte attributtene. Et objekt i en vektor kan determinere et annet objekt i vektoren. ”Løs opp” alle komplekse attributter. KWH, august 2003 Normalisering av OO 23

24 Mål 4: Alle determinander er kandidatnøkkel (3)
Ved å ”løse opp” alle strukturerte attributter, så alle attributter blir enkle, likner situasjonen på RDBMS Regelen anvendes på den ”oppløste” klassen. Endelig regel 8: Anta at all komplekse objektattributter er ”løst opp”, slik at alle de objektattributtene som er innkapslet i strukturen inngår direkte i klassen. Da må alle de enkle objektattributter som er determinander, determinere alle de andre, enkle objektattributtene i klassen, inklusive objektets ID. KWH, august 2003 Normalisering av OO 24

25 Konklusjon Jeg har laget 8 regler for normalisering av OO
Reglene er laget ved analogi og uformell analyse – men holder det? KWH, august 2003 Normalisering av OO 25

26 Oppsummering (1) Regler for hvordan
Regel 1: Normaliser bare klasser med flere objekter Regel 2: Konsentrer innsatsen om persistente objekter Regel 3: Normaliser alle persistente klasser, eller i alle fall entitetsklasser Regel 4: Normaliser også assosiasjonsklasser, og med særlig oppmerksomhet Regel 5: Normaliser bare dataene, ikke metodene. Plasser metodene til slutt etter OOP-prinsipper Regel 6: Start normaliseringen øverst i arvehierarkier og ta med alle arvede attributter under normaliseringen av subklasser. KWH, august 2003 Normalisering av OO 26

27 Oppsummering (2) Regler som angir mål
Regel 7: Alle enkle (ustrukturerte) attributter skal være atomære – anvendes evt. rekursivt på alle strukturerte attributter som inngår i normaliseringen. Regel 8: Anta at all komplekse objektattributter er ”løst opp”, slik at alle de objektattributtene som er innkapslet i strukturen inngår direkte i klassen. Da må alle de enkle objektattributter som er determinander, determinere alle de andre, enkle objektattributtene i klassen, inklusive objektets ID. KWH, august 2003 Normalisering av OO 27

28 Knut W. Hansson Førstelektor Høgskolen i Buskerud
Takker! Knut W. Hansson Førstelektor Høgskolen i Buskerud