Normalisering av objektorienterte systemer

1. Normalisering av objektorienterte systemer Knut W. Hansson Førstelektor Høgskolen i Buskerud

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? KWH, august 2003 Normalisering av OO 2

3. 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”) Noen forskjeller KWH, august 2003 Normalisering av OO 3

4. 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 Antall instanser 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. 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 Transiens/persistens Regel 2: Konsentrer innsatsen om persistente klasser KWH, august 2003 Normalisering av OO 5

6. 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 Entitets-, kontroll- og grenseklasser i OO (Booch) Regel 3: Normaliser alle persistente klasser, eller i alle fall entitetsklassene KWH, august 2003 Normalisering av OO 6

7. Parkeringsautomat (eksempel) KWH, august 2003 Normalisering av OO 7

8. 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 Assosiasjonsklasser 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

10. 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 Metoder (funksjonalitet) 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 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) 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) 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 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 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 Wayfor 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 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 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 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) KWH, august 2003 Normalisering av OO 21

22. Mål 4: Alle determinander er kandidatnøkkel (1) • OO har ikke nøkler, men hardeterminander • 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 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 objekterRegel 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. Takker! Knut W. Hansson Førstelektor Høgskolen i Buskerud