Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

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

Liknende presentasjoner


Presentasjon om: "Normalisering av objektorienterte systemer Knut W. Hansson Førstelektor Høgskolen i Buskerud."— Utskrift av presentasjonen:

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

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

3 KWH, august 2003Normalisering av OO3 Noen forskjeller RDBMS 1.Entiteter lagres gruppert i tabeller (relasjoner) 2.Entitetene knyttes sammen med logiske referanser 3.Data og program holdes logisk atskilt 4.En tabell kan ikke ”inneholde” en tabell 5.Dataene struktureres separat (”datamodellering”) OO 1.Objekter lagres hver for seg 2.Objektene knyttes sammen med direkte referanser 3.Data og program er logisk samlet 4.Et objekt kan ”inneholde” et annet objekt 5.Data og program struktureres i samme modell (”objektmodellering”)

4 KWH, august 2003Normalisering av OO4 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 Regel 1: Normaliser bare klasser med flere objekter, men vær spesielt oppmerksom på at ett attributt kan representere mange objekter

5 KWH, august 2003Normalisering av OO5 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 Regel 2: Konsentrer innsatsen om persistente klasser

6 KWH, august 2003Normalisering av OO6 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 Regel 3: Normaliser alle persistente klasser, eller i alle fall entitetsklassene

7 KWH, august 2003Normalisering av OO7 Parkeringsautomat (eksempel)

8 KWH, august 2003Normalisering av OO8 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 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).

9 KWH, august 2003Normalisering av OO9 Aksjefond (eksempel)

10 KWH, august 2003Normalisering av OO10 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 Regel 5: Normaliser bare dataene, ikke metodene.

11 KWH, august 2003Normalisering av OO11 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

12 KWH, august 2003Normalisering av OO12 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.

13 KWH, august 2003Normalisering av OO13 Kunder med arv (eksempel)

14 KWH, august 2003Normalisering av OO14 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

15 KWH, august 2003Normalisering av OO15 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

16 KWH, august 2003Normalisering av OO16 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.

17 KWH, august 2003Normalisering av OO17 ”The Quick Hansson Way for Real Experts!” STEP A ‑ "DATABASESYN": Gjør om modellen slik at: 1.Alle entitetstyper har minimal identifikator, og 2.Alle relasjonstyper er eksplisitt gitt ved fremmednøkkel, og 3.Alle attributtyper er atomære STEP B ‑ 4NF: Gjør om modellen slik at 4. Alle determinander er kandidatnøkkel

18 KWH, august 2003Normalisering av OO18 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)

19 KWH, august 2003Normalisering av OO19 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.

20 KWH, august 2003Normalisering av OO20 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.

21 KWH, august 2003Normalisering av OO21 ”Kunde med indre klasse” (eksempel)

22 KWH, august 2003Normalisering av OO22 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 Midlertidig regel 8: Alle objektattributter som er determinander, må determinere alle de andre, enkle objektattributtene i klassen inklusive objektets ID-attributt.

23 KWH, august 2003Normalisering av OO23 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.

24 KWH, august 2003Normalisering av OO24 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.

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

26 KWH, august 2003Normalisering av OO26 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.

27 KWH, august 2003Normalisering av OO27 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.

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


Laste ned ppt "Normalisering av objektorienterte systemer Knut W. Hansson Førstelektor Høgskolen i Buskerud."

Liknende presentasjoner


Annonser fra Google