Hoofdstuk 7 analyse van informatiebehoeften en ontwerp van gegevensmodellen
This presentation is the property of its rightful owner.
Sponsored Links
1 / 72

Hoofdstuk 7: Analyse van informatiebehoeften en ontwerp van gegevensmodellen PowerPoint PPT Presentation


  • 62 Views
  • Uploaded on
  • Presentation posted in: General

Hoofdstuk 7: Analyse van informatiebehoeften en ontwerp van gegevensmodellen. Overzicht. Analyse van informatiebehoeften Gegevensmodellering Het E.R. model Het E.E.R. model Het relationele model Verband tussen beide modellen. Analyse van informatiebehoeften: voorbeeld.

Download Presentation

Hoofdstuk 7: Analyse van informatiebehoeften en ontwerp van gegevensmodellen

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Hoofdstuk 7 analyse van informatiebehoeften en ontwerp van gegevensmodellen

Hoofdstuk 7: Analyse van informatiebehoeften en ontwerp van gegevensmodellen


Overzicht

Overzicht

  • Analyse van informatiebehoeften

  • Gegevensmodellering

  • Het E.R. model

  • Het E.E.R. model

  • Het relationele model

  • Verband tussen beide modellen


Analyse van informatiebehoeften voorbeeld

Analyse van informatiebehoeften: voorbeeld

  • Prioritair deelgebied: aankoop- en ontvangstsysteem

  • Bedrijfsprocessen: aankopen, ontvangen, inspecteren van geleverde kwaliteit, ...

  • Functies: aankoop, ontvangst, crediteurenadministratie

  • Activiteiten:

    • ontvangst van bericht van noodzaak van aankoop

    • beslissing tot aankoop

    • selectie van leverancier

    • aanmaak van aankooporder

    • controle op bevestiging van aankooporder door leverancier:

  • Informatiebehoeften

    • prodnr, prodnaam, levnr, levnaam, aankoopprijs, levertermijn ,...


Analyse van informatiebehoeften

Analyse van informatiebehoeften

  • Achterhalen van informatiebehoeften niet gemakkelijk

    • Irrelevante info, gebrek aan info, onjuiste selectie-of aggregatieniveau, …

  • Informatieanalyst

    • Deskundig in analyseren en structureren van informatiebehoeften en vertaling naar eerste systeemopzet

    • Materiedeskundigheid en technisch onderlegd

    • Architect


Analyse van informatiebehoeften1

Analyse van informatiebehoeften

  • informatieanalysten en eindgebruikers moeten samenwerken

  • Problemen

    • Mensen refereren altijd naar bestaande systemen

    • Meer gewicht aan recente informatiebehoeften

    • Moeilijk vaststellen van oorzaak/gevolg relaties

    • Foutieve inschatting van kans en relevantie van gebeurtenis


Veel gebruikte technieken van informatiebehoeftebepaling

Veel gebruikte technieken van informatiebehoeftebepaling

  • Waarneming

  • Interview

  • Enquêtering

  • Document-analyse

  • Steekproefgewijze waarneming

    • random sampling, stratified sampling, clustered sampling

  • Brainstorming

  • Delphi-methode

    • gestructureerde ondervraging met het doel consensus te bereiken of extreme visies met argumenten te onderbouwen

  • Beslissingsanalyse technieken (OR, ...)

  • Prototyping

  • Beslissingstabellen


Data modellering

Data modellering

Het ontwikkelen van een conceptueel gegevensmodel

  • d.i. de activiteit waarbij men de informatiebehoeften van groepen van gebruikers in een organisatie op een natuurgetrouwe wijze modelleertzonder dat men rekening houdt met implementatiedetails of met beperkingen in de (database)software waaronder de implementatie later gebeurt.

  • daarvoor gebruikt men bijvoorbeeld het ER-model

  • dit ER-model wordt later naar een relationeel database model omgezet.


Het er model e ntity r elationship model

Het ER-model: Entity Relationship-model

  • Wat?

    • formalisme om een conceptueel gegevensmodel te bouwen

  • Oorsprong?

    • Peter CHEN (1976)

  • Belang?

    • combineert een werkelijkheidsgetrouwe afbeelding met een hoge graad van formalisering

    • compromis tussen uitdrukkingsvermogen en verstaanbaarheid

  • Bouwstenen van het ER-model:

    • entiteittypen

    • attribuuttypen

    • relationshiptypen

  • Grafische voorstelling?

    • ER-diagram

  • Uitbreidingen?

    • Enhanced Entity Relationship-Model (EER-model)


Hoofdstuk 7 analyse van informatiebehoeften en ontwerp van gegevensmodellen

lev-prod

ao-

prod

lev-ao

prod-lev

prod-

ao

ao-lev

lev-

naam

lev-

adres

levnr

(0...n)

leverancier

(1...1)

aank-

prijs

aankoop-

voorwaarden

in_bestelling

lever-

term

(0...n)

(0...n)

aankooporder-

regel

product

aankoop-

order

(0...n)

(1...n)

hoev-in-

voorr

aonr

bestel-

hoev

prodnr

ao-

datum

prod-

naam


Entiteittypen

Entiteittypen

  • Objecten waarover wij gegevens willen verzamelen

  • Fysiek (klant, leverancier) of conceptueel (beroep, job)

  • Een entiteit heef kenmerken of eigenschappen (attributen)

    • levnr, leveranciersnaam, leveranciersadres, …

  • Onbekende waarden (null values)

  • Type versus individueel voorkomen

    • Classificatie versus instantiatie

    • Entiteittype versus entiteit

  • Entiteittype is een verzameling van entiteiten met gelijksoortige kenmerken (attributen)

  • Attribuut versus attribuuttypen


Soorten van attribuuttypen

Soorten van attribuuttypen

  • Enkelvoudige en samengestelde attribuuttypen

    • Enkelvoudig (atomic): bv. levnummer

    • Samengesteld: bv. levadres

  • Single-valued en multiple-valued attribuuttypen

    • single-valued: bv. levnummer

    • multi-valued: bv. levadres (onder de assumptie dat een leverancier tegelijk meerdere adressen kan hebben)

  • Sleutelattribuuttypen

    • verzameling van één of meer attribuuttypen waarvan de waarden toelaten om een entiteit op een unieke wijze te identificeren

    • één: bv. leverancier (levnummer)

    • meer: bv. vlucht (vluchtnummer, datum)

    • Uniqueness constraint


Relationshiptype

Relationshiptype

  • Een relationshiptype representeert een verzameling gelijksoortige verbanden tussen entiteiten

    • een relationship is een individueel voorkomen van dergelijk verband

    • een relationshiptype heeft een naam

      • bv. het relationshiptype in_bestelling modelleert de verbanden tussen leveranciers en aankooporders

  • Ook relationshiptypen kunnen over attribuuttypen beschikken

    • Indien de waarden van sommige attributen bepaald worden door een samenstelling van entiteiten uit een relationship, treden er attribuuttypen op voor dat relationshiptype

      • bv. het relationshiptype aankoopvoorwaarden: levtermijn


Relationshiptype vervolg

Relationshiptype (vervolg)

  • Graad van een relationshiptype: het aantal entiteittypen dat gebruikt is bij het tot stand komen van het verband

    • 1 -> unair relationshiptype

    • 2 -> binair relationshiptype (bv. relationshiptype ‘in bestelling’)

    • 3 -> ternair relationshiptype

  • Associatie-typen (rollen) bepalen de zin waarin een verband moet worden opgevat

    • bv. het verband (‘in bestelling’) tussen leveranciers en aankooporders kan zowel vanaf leverancier, als vanaf aankooporder beschouwd worden

    • iedere rol heeft een naam

      • bv. relationshiptype ‘in_bestelling’: rollen lev-ao en ao-lev


Relationshiptype vervolg1

Relationshiptype (vervolg)

  • Cardinaliteit van een rol: het aantal keren dat een entiteit in die rol kan of moet optreden

    • minimale cardinaliteit: 0 of 1

      • 0: als het in die rol niet is vereist dat elke entiteit met een andere entiteit is gekoppeld (partiële participatie), bv. lev-ao

      • 1: iedere entiteit moet minstens éénmaal in die rol optreden (bestaansafhankelijkheid), bv. ao-lev

    • maximale cardinaliteit: 1 of n

      • 1: als het in een rol is vereist dat met een entiteit maximaal één ander entiteit mag zijn gekoppeld, bv. ao-lev

      • n: als een entiteit, in een rol, met een onbepaald aantal entiteiten mag zijn gekoppeld, bv. lev-ao

    • 4 mogelijke combinaties: 0..1, 0..n, 1..1, 1..n


Hoofdstuk 7 analyse van informatiebehoeften en ontwerp van gegevensmodellen

lev-ao

ao-lev

voorbeeld: relationshiptype ‘in_bestelling’

levnr

aonr

aankooporder

leverancier

(1..1)

(0..n)

levnaam

aodatum

in_bestelling


Hoofdstuk 7 analyse van informatiebehoeften en ontwerp van gegevensmodellen

krijgt leiding van

geeftleiding aan

voorbeeld: relationshiptype ‘leiding’

leiding

werknemer

(0..n)

(0..1)


Entiteittype

Entiteittype

  • Gewoon entiteittype

  • Zwak entiteittype (‘weak entity type’)

    • entiteittype dat niet over (voldoende) eigen attribuuttypen beschikt om een sleutel te vinden

    • voorbeeld: datamodel van hotelketen

      • entiteittypen: hotel, kamer, ...

      • attribuuttypen: hotel: hotelnaam, ...kamer: kamernummer, prijs, ...

      • kamer is een zwak entiteittypesleutel kamer: kamernummer, hotelnaam

    • een zwak entiteittype is altijd bestaansafhankelijk

      • het omgekeerde gaat niet op: bestaanafhankelijkheid hoeft niet noodzakelijk het bestaan van een zwak entiteittype te impliceren.


Hoofdstuk 7 analyse van informatiebehoeften en ontwerp van gegevensmodellen

ao-lev

kam-hot

lev-ao

hot-kam

voorbeeld: bestaansafhankelijkheden en zwakke entiteittypen

levnr

hotelnaam

leverancier

hotel

levnaam

(1..1)

(1..1)

hotelkamer

in_bestelling

hotelnaam

(0..n)

(0..n)

aonr

aankooporder

kamer

kamernr

aodatum

prijs


Problemen met er modellering

Problemen met ER-modellering

  • Semantisch relativisme

    • entiteittype of relationshiptype?

    • attribuuttype of entiteittype met nieuw relationshiptype?

  • ER model is momentopname

    • temporele aspecten niet modelleerbaar

  • Deel semantiek gaat verloren

    • integriteitsbeperkingen niet modelleerbaar

  • Ambiguïteit

    • betekenis cardinaliteit bij ternaire relationshiptypes?


Methodologie voor het opstellen van een er model

Methodologie voor het opstellen van een ER-model

  • Bepalen en benoemen van entiteittypen

  • Bepalen en benoemen van relationshiptypen

  • Benoemen van rollen

  • Bepalen van cardinaliteiten

  • Bepalen en benoemen van attribuuttypen en verbinden van attribuuttypen met entiteittypen of relationshiptypen

  • Aanduiden van sleutelattributen


Voorbeeld cursusadministratie

Voorbeeld: Cursusadministratie

  • Van een cursus wordt een aantal gegevens bijgehouden.

  • Het gevolgd hebben van een cursus kan vereist zijn om andere cursussen te mogen volgen. Om een cursus te mogen volgen kan het vereist zijn meerdere andere cursussen gevolgd te hebben.

  • Een bepaalde cursus wordt een aantal keren georganiseerd, telkens in een lokalisatie, en op een bepaalde datum.

  • Van een docent wordt een aantal gegevens bijgehouden.

  • Een docent kan bij meerdere organisaties van cursussen betrokken zijn. De organisatie van een cursus kan door meerdere docenten worden verzorgd.

  • Van een student wordt een aantal gegevens bijgehouden.

  • Een student kan voor meerdere organisaties van cursussen zijn ingeschreven. Per organisatie wordt naderhand zijn/haar resultaat bijgehouden.

  • Vanzelfsprekend kunnen er voor een specifieke organisatie van een cursus meerdere studenten zijn ingeschreven.


Het e nhanced e ntity r elationship model eer model

Het Enhanced Entity Relationship model (EER-model)

Het ER-model uitgebreid met een aantal abstracties die nog beter moeten toelaten om de semantiek van de gegevens uit de werkelijkheid te modelleren.

Voorbeelden van deze abstracties:

  • Generalisatie / specialisatie

  • Categorisatie

  • Aggregatie


Superklasse subklasse

Superklasse-subklasse

  • Een entiteittype bepaalt het soort object waarover men gegevens wil vastleggen

    • een entiteittype fungeert als een klasse van entiteiten met gelijksoortige kenmerken.

  • Vaak kunnen er in een klasse allerlei subklassen worden onderscheiden.

    • een subklasse is een deelverzameling van entiteiten van een entiteittype die zich op een bijzondere wijze onderscheidt en waarvan het zinvol is om deze te expliciteren

    • een superklasse is het entiteittype waarbinnen subklassen worden onderscheiden

  • Overerving

    • een entiteit die tot een subklasse behoort heeft attribuuttypen die de bijzondere kenmerken van de entiteiten van die subklasse voorstellen

    • een entiteit die tot een subklasse behoort erft alle attribuuttypen die de algemene kenmerken voorstellen die gedeeld worden door alle entiteiten van zijn superklasse


Superklasse subklasse1

Superklasse-subklasse

  • Voorbeeld

    • superklasse: werknemers

    • subklasse: werknemers die een vast maandelijks salaris ontvangen

    • subklasse: werknemers die volgens effectief gepresteerde tijd worden vergoed

    • subklasse: werknemers die als contractuele consulenten in dienst zijn

  • Voordelen:

    • het is waarschijnlijk dat werknemers van een groep kenmerken hebben die bij werknemers van een andere groep niet toepasselijk zijn: door het opdelen in subklassen kan worden vastgelegd welke bijzondere kenmerken bij welke werknemers moeten voorkomen.

    • het is mogelijk dat verbanden enkel bestaan voor sommige groepen van werknemers: door het expliciteren van groepen kan worden afgedwongen voor welke werknemers de verbanden relevant zijn.


Specialisatie generalisatie

Specialisatie/generalisatie

  • Generalisatie:is het proces volgens hetwelk wij de verschillen tussen een aantal entiteittypen over het hoofd zien en wij hen ‘generaliseren’ tot één enkel super entiteittype (bottom-up synthese)

  • Specialisatie:is het proces volgens hetwelk wij de verschillen tussen sommige entiteiten van een entiteittype expliciteren door dit entiteittype te ‘specialiseren’ naar een aantal subtypen. (top-down analyse)

  • Overerving

    • Meervoudige overerving


Specialisatie generalisatie soorten

Specialisatie/generalisatie: soorten

  • Criterium: disjointness constraint

    • wanneer de subklassen van een specialisatie disjunct (d) zijn, mag een entiteit van ten hoogste één subklasse van de specialisatie deel uitmaken.

    • niet-disjunct of overloop (o) betekent dat een entiteit van meerdere subklassen van een specialisatie deel mag uitmaken.

  • Criterium: completeness constraint

    • bij een totale specialisatie (t) moet iedere entiteit in de superklasse deel uitmaken van een of andere subklasse van de specialisatie

    • bij een partiële specialisatie (p) is het toegelaten dat sommige entiteiten van de superklasse van geen enkele subklasse deel uitmaken.


Hoofdstuk 7 analyse van informatiebehoeften en ontwerp van gegevensmodellen

Voorbeeld van een disjuncte, totale specialisatie.

wnr

werknemer

wnaam

t

wadres

d

acad-

graad

aantal

jaaruur

wetensch.

graad

status

‘zap’

‘aap’

‘atp’


Hoofdstuk 7 analyse van informatiebehoeften en ontwerp van gegevensmodellen

Voorbeeld van een niet-disjuncte, totale specialisatie.

lev-prod

prod-lev

product

pnr

pnaam

t

fabricage-

tijd

o

aankoopproduct

fabricageproduct

lever-

termijn

(0...n)

aankoop-

voorwaarden

aank-

prijs

(1...n)

levnr

leverancier

levnaam


Hoofdstuk 7 analyse van informatiebehoeften en ontwerp van gegevensmodellen

Voorbeeld van een entiteittype met meerdere specialisaties

op-poc

mvl-tbp

poc-op

tbp-mvl

werknemer

t

p

t

d

d

vast

benoemd

personeel

tijdelijk

benoemd

personeel

POC-lid

‘zap’

‘aap’

‘atp’

(1..1)

(1..1)

(0..n)

(0..n)

onderwijs-

project

mandaat-

verlenging


Specialisatiehi rarchie versus specialisatieraster

Specialisatiehiërarchie versus Specialisatieraster

  • Specialisatiehiërarchie

    • Iedere subklasse in één enkel superklasse- /subklasseverband

  • Specialisatieraster

    • Subklasse in meerdere superklasse- /subklasseverbanden

  • Meervoudige overerving


Hoofdstuk 7 analyse van informatiebehoeften en ontwerp van gegevensmodellen

Voorbeeld van een specialisatieraster met meervoudige overerving.

persoon

t

o

werknemer

student

t

t

d

d

‘aap’

‘atp’

student-

assistent

kandidatuur-

student

licentie-

student

‘zap’

t

d

onderwijs-

assistent

onderzoeks-

assistent


Categorisatie

Categorisatie

  • Superklasse-/subklasseverbanden met meerdere directe superklassen die respectievelijke entiteittypen voorstellen

  • Subklasse bestaat uit een geheel van entiteiten dewelke overeenkomt met de unie of met een deelverzameling van de unie van de entiteiten uit de respectievelijke superklassen

  • Voorbeeld

    • Rekeninghouders

  • Selectieve overerving

  • Totale categorisatie

    • Iedere entiteit uit elke superklasse moet deel uitmaken van de subklasse

  • Bij totale categorisatie, kan ook gebruik gemaakt worden van een specialisatie-/generalisatieproces

  • Niet mogelijk bij partiële categorisatie!


Aggregatie

Aggregatie

  • Bouwen van een samengesteld object

  • Bouwen van een samengesteld entiteittype op basis van een aantal entiteittypen en hun relationshiptypen


Voorbeeld van een eer model

Voorbeeld van een EER model


Hoofdstuk 7 analyse van informatiebehoeften en ontwerp van gegevensmodellen

gebruiker

informatiebehoeften

ER-model

relationeel

model

DB

gebruiker


Het relationele model

Het relationele model

  • Oorsprong

    • artikel van E. Codd (IBM) in Comm. of the ACM (1970)

  • Model heeft een formele, wiskundige onderbouw

    • gebaseerd op verzamelingenleer

    • relationele algebra, relationele calculus.

  • Model heeft geen grafische afbeelding.

    • tabelvoorstelling: te weinig semantiek

    • geen echt informatiemodel (zoals ER-model).

  • Model is wel geïmplementeerd in allerlei (relationele) database software

    • vandaar: database model.

  • Eindgebruiker moet begrippen kennen om gegevens te kunnen opvragen uit relationele databases

    • met behulp van talen als SQL


Het relationele model1

Het relationele model

  • Twee type-constructoren

    • Tupel constructor: enkel op atomic attribuuttypen; geen samengestelde attribuuttypen

    • Set constructor: enkel op tupels; geen meerwaardige attribuuttypen

  • Complexe objecten moeilijk te modelleren


Relatie tabelvoorstelling

Relatie: tabelvoorstelling

  • Voorstellingsvormen van enkele relationele concepten: tabel - relatie

    rij - tupel

    kolom - attribuuttype

    kolomwaarde - attribuutwaarde

  • Voorstelling van de relatie ‘Product’


Relaties tupels domeinen

Relaties, tupels, domeinen

  • Een relatie definieert het soort object waarover men gegevens wil vastleggen.

  • De elementen van een relatie zijn tupels.

    • een relatie (bijvoorbeeld ‘Werknemer’) bevat zoveel tupels als er op een gegeven ogenblik verschillende werknemers in een bedrijf zijn

    • tupels in een relatie zijn uniek en hebben geen volgorde.

  • Wiskundig is een relatie een deelverzameling van een cartesisch product over een aantal verzamelingen.

    • deze verzamelingen worden domeinen genoemd.

    • een domein is een verzameling van gelijksoortige waarden:domein prodnr numeric 1-9999

    • er zijn enkelvoudige en samengestelde domeinen.


Attributen

Attributen

  • De toepassing van een domein bij de opbouw van een relatie levert een attribuuttype op voor die relatie

    • Relatie ‘Product’attribuuttype prodnr domein prodnr

    • Relatie ‘Productstructuur’attribuuttype major_prodnr domein prodnrattribuuttype minor_prodnr domein prodnrattribuuttype hoeveelheid domein hoeveelheid

  • Attribuutwaarde

    • de elementen van een domein die, bij toepassing van dat domein op de relatie, in de relatie optreden, worden de attribuutwaarden voor een attribuuttype genoemd.

    • deze waarden zijn een deelverzameling van het toepasselijke domein.

  • Elk tupel heeft voor elk attribuuttype exact één attribuutwaarde

    • wanneer een waarde onbekend is, of niet van toepassing is, spreekt men over een null-waarde

      • null ≠ nul !


Sleutels

Sleutels

  • Kandidaatsleutel: is een minimale determinant van een relatie

    • d.i. een (combinatie van) attribuuttype(n) van een relatie waarvoor geldt dat

      • met een waarde van de kandidaatsleutel precies één tupel wordt aangewezen

      • terwijl voor elk deel van de kandidaatsleutel geldt dat met een waarde meer dan één tupel kan worden aangewezen.

    • voorbeeld: relatie ‘Product’ (prodnr, prodnaam, hoev_in_voorr, ...)kandidaatsleutel: prodnrkandidaatsleutel: prodnaam

    • voorbeeld: relatie ‘Aankooporderregel’ (aonr, prodnr, bestelhoev, ...)kandidaatsleutel: (aonr, prodnr)

  • Primaire sleutel:

    • één van de kandidaatsleutels wordt tot primaire sleutel gepromoveerd.

    • de eventueel andere kandidaatsleutels worden alternatieve sleutels

    • voorbeeld: relatie ‘Product’ (prodnr, prodnaam, hoev_in_voorr, ...)kandidaatsleutels: prodnr, prodnaamprimaire sleutel: prodnralternatieve sleutel: prodnaam

  • Entiteit integriteitsregel:

    • een attribuuttype dat deel uitmaakt van een primaire sleutel mag geen null waarden aannemen


Sleutels vervolg

Sleutels (vervolg)

  • Vreemde sleutel:

    • d.i. een (combinatie van) attribuuttype(n) van een relatie R waarvoor geldt dat er een kandidaatsleutel in de relatie S is (S en R mogen dezelfde relaties zijn), zodanig dat de overeenkomstige attribuuttypen op dezelfde domeinen zijn gedefinieerd als de attribuuttypen van de vreemde sleutel.

    • in het relationeel model wordt de samenhang tussen objecten bewerkstelligd d.m.v. vreemde sleutels.

    • voorbeeld:(S) Departement (dnr, dnaam, dlokatie, ...)(R) Project (pnr, pnaam, pduur, dnr)

  • Referentiële integriteitsregel

    • de waarde van de vreemde sleutel in een tupel van R is:

      • ofwel helemaal gelijk aan de null-waarde

      • ofwel gelijk aan de waarde van de kandidaatsleutel in een tupel van S


Hoofdstuk 7 analyse van informatiebehoeften en ontwerp van gegevensmodellen

Vreemde sleutel: voorbeeld

DNR DNAAM DLOCATIE

15 MarketingBrussel

23 FinanceBrussel

38 R&DLeuven

47 LogistiekAntwerpen

Departement

PNRPNAAM PDUUR DNR

1142InvestOptim1200 23

1231NewProduct4500 38

1648PlantLayout1000 47

1721CapitalRet1000 23

Project


Hoofdstuk 7 analyse van informatiebehoeften en ontwerp van gegevensmodellen

Vreemde sleutel: voorbeeld (2)

WNR WNAAM WADRES

1 AlbersBrussel

2 BogaertsBrussel

3 CelisLeuven

4 DokmansAntwerpen

Werknemer

WNR PNR GEWERKT

1 1130

2 1120

2 1740

4 1610

Werkt_aan

PNRPNAAM PDUUR DNR

11InvestOptim1200 23

12NewProduct4500 38

16PlantLayout1000 47

17CapitalRet1000 23

Project


Genormaliseerde relaties en het normalisatieproces

Genormaliseerde relaties en het normalisatieproces

  • Het relationele model is een verzameling van genormaliseerde relaties

    • een relatie is minimaal in eerste normaalvorm

  • Waarom verder normaliseren?

    • om effectieve gegevensstructuur te verkrijgen zodat bij het gebruik geen anomalieën ontstaan.

  • Normaliseren is een stapsgewijs proces dat op een verzameling van relaties kan worden toegepast teneinde hun attribuuttypen op een zodanige manier over nieuwe relaties te verdelen, dat het datamodel geen overtolligheden en tegenspraak bevat.

    • het normaliseren is gesteund op functionele afhankelijkheden tussen attribuuttypen

    • normaliseren impliceert het uitvoeren van een aantal normalisatiestappen.


Waarom normaliseren

Waarom normaliseren?

Werknemer

WNR WNAAM WADRES DNR DNAAM DLOCATIE

1Albers Brussel23Finance Brussel

2BogaertsBrussel 23Finance Brussel

3CelisLeuven 38R&D Leuven

4DokmansAntwerpen 47Logistiek Antwerpen

Anomalieën:

  • wat als een departement van locatie verandert?

  • wat als een nieuw departement moet worden toegevoegd?

  • wat als de laatste werknemer van een departement verdwijnt?

  • ...

Werknemer

Departement

WNRWNAAM WADRES DNR

DNRDNAAM DLOCATIE

15 Marketing Brussel

23 Finance Brussel

38 R&D Leuven

47 Logistiek Antwerpen

1 Albers Brussel 23

2 Bogaerts Brussel 23

3 Celis Leuven 38

4 Dokmans Antwerpen 47


Functionele afhankelijkheid

Functionele afhankelijkheid

  • Een attribuuttype b is functioneel afhankelijk van een attribuuttype a indien, op elk tijdstip, bij elke waarde van a precies één waarde van b hoort.

    • notatiewijze:

      a -> b

    • voorbeeld:wnr -> wnaamwnaam -/-> wnr


Normalisatiestappen

Normalisatiestappen


Eerste normalisatiestap

Eerste normalisatiestap

  • De eerste normalisatiestap transformeert een ongenormaliseerde relatie (0 NF) naar een relatie in 1NF

  • Een relatie is in 1NF indien elk attribuuttype van de relatie zijn waarden haalt uit een enkelvoudig domein met atomic waarden en ieder tupel voor elk attribuuttype maar één waarde bezit uit het betreffende domein.

  • Voorbeeld: Departement (dnr, dnaam, dlocatie)Assumpties:

    • dnr is de kandidaatsleutel en de primaire sleutel van de relatie

    • elk departement kan over meerdere locaties beschikken

    • in een locatie kunnen er meerdere departementen bestaan

      Gevolg: departement is niet in 1NF

    • in tupels van de relatie Departement kunnen meerdere waarden tegelijk optreden voor het attribuuttype dlocatie.

      Oplossing:

    • dlocatie uit Departement verwijderen en onderbrengen in nieuwe relatie Deplocatie met primaire sleutel (dnr, dlocatie).

      Departement (dnr, dnaam)Deplocatie (dnr, dlocatie)


Eerste normalisatiestap voorbeeld

Eerste normalisatiestap (voorbeeld)

Departement

DNRDNAAM DLOCATIE

15Marketing Brussel

23Finance Brussel

38R&D Leuven, Gent

47Logistiek Antwerpen, Zeebrugge

Deplocatie

Departement

DNRDNAAM

DNRDLOCATIE

15Brussel

23Brussel

38Leuven

38Gent

47Antwerpen

47Zeebrugge

15Marketing

23Finance

38R&D

47Logistiek


Eerste normalisatiestap voorbeeld 2

Eerste normalisatiestap (voorbeeld 2)

  • Voorbeeld: Werknemer (wnr, wnaam, telefoon)

    Assumpties:

    • wnr is de kandidaatsleutel en de primaire sleutel van de relatie

    • werknemer kan meerdere telefoons hebben

    • een telefoon hoort bij 1 werknemer

      Gevolg: departement is niet in 1NF

    • in tupels van de relatie Werknemer kunnen meerdere waarden tegelijk optreden voor het attribuuttype telefoon.

      Oplossing:

    • telefoon uit Werknemer verwijderen en onderbrengen in nieuwe relatie Werknemer-telefoon met primaire sleutel telefoon.

      Werknemer (wnr, wnaam)

      Werknemer-telefoon (wnr, telefoon)

      Andere assumptie:

    • een telefoon kan door meer werknemers worden gedeeld ...

      Oplossing:

      Werknemer (wnr, wnaam)

      Werknemer-telefoon (wnr, telefoon)


Eerste normalisatiestap voorbeeld 3

Eerste normalisatiestap (voorbeeld 3)

  • Voorbeeld: R1 (WNR, WNAAM, PROJECT(PNR, PNAAM, PDUUR, GEWERKT) )

    Assumpties:

    • wnr is de kandidaatsleutel en de primaire sleutel van de relatie

    • een werknemer kan aan meerdere projecten werken

    • aan een project wordt door meerdere werknemers gewerkt

    • project is een samengesteld attribuuttype

      Gevolg:

    • R1 is niet in 1NF

      Oplossing:

      R11 (WNR, WNAAM)

      R12 (WNR, PNR, PNAAM, PDUUR, GEWERKT)


Tweede normalisatiestap

Tweede normalisatiestap

  • De tweede normalisatiestap transformeert een relatie in 1NF naar een relatie in 2NF

  • Een relatie is in 2NF indien de relatie in 1NF is én elk non-prime attribuuttype van de relatie volledig functioneel afhankelijk is van elke kandidaatsleutel van de relatie.

    • een prime attribuuttype maakt deel uit van een kandidaatsleutel van de relatie

    • een functionele afhankelijkheid X -> Y is volledig indien de verwijdering van om het even welk attribuuttype uit X zou betekenen dat de afhankelijkheid niet langer opgaat

    • indien een attribuuttype uit X zou mogen worden verwijderd en de afhankelijkheid blijft bestaan, dan is er sprake van een partiële functionele afhankelijkheid

    • opmerking: als X -> Y én X bestaat uit één enkel attribuuttype, dan is de functionele afhankelijkheid steeds volledig


Tweede normalisatiestap voorbeeld

Tweede normalisatiestap(voorbeeld)

  • Voorbeeld:R12 (WNR, PNR, PNAAM, PDUUR, GEWERKT)Assumpties:

    • (WNR, PNR) is de primaire sleutel van de relatie

    • PNAAM, PDUUR en GEWERKT zijn non-prime

    • omwille van de functionele afhankelijkheid PNR -> PNAAM is PNAAM slechts partieel functioneel afhankelijk van (WNR, PNR)

    • GEWERKT is volledig functioneel afhankelijk van (WNR, PNR).(WNR, PNR) -> GEWERKTWNR -/-> GEWERKTPNR -/-> GEWERKT

      Oplossing:

    • de non-prime attribuuttypen die partieel functioneel afhankelijk zijn van de primaire sleutel moeten uit de relatie worden verwijderd en worden ingevoerd in een nieuwe relatie met een primaire sleutel waarvan ze wel volledig functioneel afhankelijk zijn.Project (PNR, PNAAM, PDUUR)Werkt-aan (WNR, PNR, GEWERKT)


Hoofdstuk 7 analyse van informatiebehoeften en ontwerp van gegevensmodellen

Tweede normalisatiestap(voorbeeld)

WNR PNR PNAAM PDUUR GEWERKT

R12

1 11 InvestOptim1200 30

2 11 InvestOptim1200 20

2 17 CapitalRet1000 40

4 16 PlantLayout1000 10

WNR PNR GEWERKT

Werkt_aan

1 1130

2 1120

2 1740

4 1610

Project

PNRPNAAM PDUUR

11InvestOptim1200

12NewProduct4500

16PlantLayout1000

17CapitalRet1000


Derde normalisatiestap

Derde normalisatiestap

  • De derde normalisatiestap transformeert een relatie in 2NF naar een relatie in 3NF

  • Een relatie is in 3NF wanneer deze relatie in 2NF is én geen non-prime attribuuttype transitief afhankelijk is van een kandidaatsleutel van de relatie.

    • een functionele afhankelijkheid X -> Y is een transitieve afhankelijkheid indien er een verzameling van attribuuttypen Z bestaat die van geen sleutel van de relatie deel uitmaakt, terwijl zowel X -> Z en Z -> Y opgaan.

  • De attribuuttypen die transitief afhankelijk zijn moeten uit de relatie worden verwijderd en worden ingevoerd in een nieuwe relatie met primaire sleutel het attribuuttype waarlangs de transitieve afhankelijkheid eerder werd vastgesteld.


Derde normalisatiestap voorbeeld

Derde normalisatiestap(voorbeeld)

  • Voorbeeld:Werknemer (WNR, WNAAM, DNR, DNAAM, MGNR)

    Assumpties:

    • een werknemer werkt aan één departement

    • aan een departement werken meerdere werknemers

    • een departement heeft één manager

      Gevolg:

    • WNR -> MGNR is een transitieve afhankelijkheid

      DNR maakt geen deel uit van sleutel én

      WNR -> DNR

      DNR -> MGNR

    • R1 is niet in 3NF

      Oplossing:

    • de attribuuttypen die transitief afhankelijk zijn moeten uit de relatie worden verwijderd en worden ingevoerd in een nieuwe relatie met primaire sleutel het attribuuttype waarlangs de transitieve afhankelijkheid eerder werd vastgesteld Werknemer (WNR, WNAAM, DNR)Departement (DNR, DNAAM, MGNR)


Hoofdstuk 7 analyse van informatiebehoeften en ontwerp van gegevensmodellen

Derde normalisatiestap(voorbeeld)

Werknemer

WNR WNAAM DNR DNAAM MGNR

1Albers 23 Finance 7

2Bogaerts23 Finance 7

3Celis38 R&D 9

4Dokmans47 Logistiek 11

……………

Werknemer

Departement

WNR WNAAM DNR

DNRDNAAM MGNR

1Albers 23

2Bogaerts 23

Celis 38

Dokmans 47

…… …

7Basemans 23

15Marketing 8

23Finance 7

38R&D 9

47Logistiek 11


Normalisatie extra voorbeeld 1

Normalisatie: extra voorbeeld 1

R(studentnr, studentnaam, studentadres(straatnaam, straatnummer, postcode, gemeente), cursus(cursusnummer, cursusnaam, profnummer, profnaam))

Assumpties:

  • een student heeft één adres

  • een student volgt meerdere cursussen

  • een cursus wordt gedoceerd door één prof


Extra voorbeeld vervolg

Extra voorbeeld(vervolg)

1NFStudent (studentnr, studentnaam, straatnaam, straatnummer, postcode, gemeente)Volgt (studentnr, cursusnr, cursusnaam, profnr, profnaam)

2NFStudent (studentnr, studentnaam, straatnaam, straatnummer, postcode, gemeente)Volgt (studentnr, cursusnr)Cursus (cursusnr, cursusnaam, profnr, profnaam)

3NFStudent (studentnr, studentnaam, straatnaam, straatnummer, postcode, gemeente)Volgt (studentnr, cursusnr)Cursus (cursusnr, cursusnaam, profnr)Prof (profnr, profnaam)


Extra voorbeeld vervolg1

Extra voorbeeld(vervolg)

Vanuit het huidige model bezien:

  • Kan een student meerdere cursussen volgen?

  • Kan een cursus door meerdere studenten worden gevolgd?

  • Kan een prof meerder cursussen doceren?

  • Waar zou het examenresultaat moeten opgenomen worden?

  • Wat als een cursus toch door meerdere proffen moet kunnen worden gedoceerd? Welke wijziging is er nodig om dit laatste mogelijk te maken?


Extra voorbeeld vervolg2

Extra voorbeeld(vervolg)

Student (studentnr, studentnaam, straatnaam, straatnummer, postcode, gemeente)Volgt (studentnr, cursusnr)Cursus (cursusnr, cursusnaam, profnr)Prof (profnr, profnaam)


Extra voorbeeld 2

Extra voorbeeld 2

  • In het kader van een bibliotheekadministratie wordt bijgehouden welke boeken door welke auteurs zijn geschreven en door welke uitgevers zijn uitgegeven.

  • Normaliseer de volgende relatie:

    • R(ISBN, titel, auteur(naam, geboortedatum), publisher(naam, adres(straatnummer, straatnaam, postcode, gemeente)), pagina’s, prijs)

  • Je mag het volgende veronderstellen:

    • Een boek heeft een uniek ISBN nummer

    • Een auteur heeft een unieke naam

    • Een publisher heeft een unieke naam

    • Een boek kan geschreven worden door meerdere auteurs

    • Een auteur kan meerdere boeken schrijven

    • Een publisher kan meerdere boeken uitgeven

    • Een boek wordt uitgegeven door 1 publisher

    • Een publisher heeft 1 adres

    • Duid duidelijk aan welke de primaire en vreemde sleutelattribuuttypen zijn.

  • Hoe zou u het model uitbreiden indien voor een boek meerdere uitgevers kunnen zijn?

  • Waar zou u het aantal gedrukte exemplaren van een boek opnemen?


Relationele model structuurbeperkingen

Relationele model: structuurbeperkingen

  • Voorbeeld:Aankooporder (aonr, aodatum, levnr)Leverancier (levnr, levnaam, levadres)Aankooporderregel (aonr, prodnr, bestel_hoev)Product (prodnr, prodnaam, hoev_in_voorr)

  • Cardinaliteiten

    • een minimumcardinaliteit 1 kan enkel worden afgedwongen indien ook de maximumcardinaliteit 1 moet zijn

      • een aankooporder is voor precies één leverancier (via vreemde sleutel)

      • een aankooporder heeft minstens één aankooporderregel (?)

  • Abstracties

    • disjointness en completeness constraints kunnen niet worden weergegeven

  • Oplossing

    • De controle van dergelijke regels en beperkingen moet op een andere manier worden georganiseerd


Hoofdstuk 7 analyse van informatiebehoeften en ontwerp van gegevensmodellen

gebruiker

informatiebehoeften

ER-model

relationeel

model

DB

gebruiker


Vertaling van een eer model naar een relationeel model

Vertaling van een EER model naar een Relationeel model

  • Enkele vuistregels

    • Ieder entiteittype wordt een relatie

    • Een meerwaardige attribuuttype wordt een aparte relatie

    • Een relationshiptype met een maximumcardinaliteit 1 wordt gerepresenteerd door een vreemde sleutel

    • Een relationshiptype waarvan alle maximumcardinaliteiten onbepaald zijn wordt een relatie; vreemde sleutels leggen de link naar de deelnemende entiteittypes

    • Een ternair relationshiptype wordt een relatie; vreemde sleutels leggen de link naar de deelnemende entiteittypes

    • De verbanden in een generalisatie/specialisatie hierachie worden gerepresenteerd met behulp van vreemde sleutels


Voorbeeld personeelsadministratie

Voorbeeld: personeelsadministratie

WERKNEMER (WNR, WNAAM, ADRES, SEKSE, GEBOORTEDATUM, LWNR, DNR)

LWNR: vreemde sleutel, verwijst naarWNR in WERKNEMER, null toegelaten

DNR: vreemde sleutel, verwijst naarDNR in DEPARTEMENT, null niet toegelaten

DEPARTEMENT (DNR, DNAAM, DLOCATIE, MGNR)

MGNR: vreemde sleutel, verwijst naarWNR in WERKNEMER, null niet toegelaten

PROJECT (PNR, PNAAM, PDUUR, DNR)

DNR: vreemde sleutel, verwijst naar DNR in DEPARTEMENT, null niet toegelaten

WERKT_AAN (WNR, PNR, GEWERKT)

WNR: vreemde sleutel, verwijst naarWNR in WERKNEMER, null niet toegelaten

PNR: vreemde sleutel, verwijst naarPNR in PROJECT, null niet toegelaten


Voorbeeld personeelsadministratie vervolg

Voorbeeld: personeelsadministratie(vervolg)

  • Opmerking i.v.m. vreemde sleutels:

    • het is volstrekt mogelijk dat de vreemde sleutel in dezelfde relatie voorkomt als de kandidaatsleutel waarnaar deze vreemde sleutel refereert.

    • Voorbeeld: beschouw in het ER model het unaire relationshiptypeWerknemer (WNR, WNAAM, ADRES, ..., LWNR)

      • Assumptie: een werknemer krijgt leiding van maximaal één andere werknemer.

      • Kan een werknemer dan leiding geven aan meerdere personen?


  • Login