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 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 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 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 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 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 modelleert zonder 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: 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)

leverancier aankoop- product order lev- naam lev- adres levnr aonr (1...1) aank- prijs ao-lev lev-ao prod-lev lev-prod aankoop- voorwaarden in_bestelling lever- term (0...n) aankooporder- regel (0...n) aankoop- order product prod- ao ao- prod (0...n) (1...n) hoev-in- voorr aonr bestel- hoev prodnr ao- datum prod- naam

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 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 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) 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 (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

voorbeeld: relationshiptype ‘in_bestelling’ levnr aonr aankooporder leverancier (1..1) (0..n) levnaam aodatum ao-lev lev-ao in_bestelling

voorbeeld: relationshiptype ‘leiding’ geeft leiding aan krijgt leiding van werknemer (0..n) (0..1)

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 entiteittype sleutel 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.

voorbeeld: bestaansafhankelijkheden en zwakke entiteittypen levnr hotelnaam leverancier hotel levnaam (1..1) (1..1) ao-lev lev-ao kam-hot hot-kam hotelkamer in_bestelling (0..n) (0..n) hotelnaam aonr aankooporder kamer kamernr aodatum prijs

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

Voorbeeld van een disjuncte, totale specialisatie. wnr werknemer wnaam t wadres d acad- graad aantal jaaruur wetensch. graad status ‘zap’ ‘aap’ ‘atp’

Voorbeeld van een niet-disjuncte, totale specialisatie. product pnr pnaam t fabricage- tijd o aankoopproduct fabricageproduct lever- termijn (0...n) prod-lev lev-prod aankoop- voorwaarden aank- prijs (1...n) levnr leverancier levnaam

Voorbeeld van een entiteittype met meerdere specialisaties werknemer t p t d d ‘zap’ ‘aap’ ‘atp’ vast benoemd personeel tijdelijk benoemd personeel POC-lid (1..1) (1..1) mvl-tbp tbp-mvl op-poc poc-op (0..n) (0..n) onderwijs- project mandaat- verlenging

Specialisatiehiërarchie versus Specialisatieraster Iedere subklasse in één enkel superklasse- /subklasseverband Specialisatieraster Subklasse in meerdere superklasse- /subklasseverbanden Meervoudige overerving

Voorbeeld van een specialisatieraster met meervoudige overerving. persoon t o werknemer student t t d d ‘zap’ ‘aap’ ‘atp’ student- assistent kandidatuur- student licentie- student t d onderwijs- assistent onderzoeks- assistent

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 Bouwen van een samengesteld object Bouwen van een samengesteld entiteittype op basis van een aantal entiteittypen en hun relationshiptypen

Voorbeeld van een EER model

gebruiker informatiebehoeften ER-model relationeel model DB gebruiker

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 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 Voorstellingsvormen van enkele relationele concepten: tabel - relatie rij - tupel kolom - attribuuttype kolomwaarde - attribuutwaarde Voorstelling van de relatie ‘Product’ prodnr prodnaam hoev_in_voorr 014 Ricon fax 10 136 009 Siemens Fx 12 19 027 Canon CX 30 - :

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 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 prodnr attribuuttype minor_prodnr domein prodnr attribuuttype 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 Entiteit integriteitsregel: 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: prodnr kandidaatsleutel: 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, prodnaam primaire sleutel: prodnr alternatieve sleutel: prodnaam Entiteit integriteitsregel: een attribuuttype dat deel uitmaakt van een primaire sleutel mag geen null waarden aannemen

Sleutels (vervolg) Vreemde sleutel: Referentiële integriteitsregel 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

Vreemde sleutel: voorbeeld DNR DNAAM DLOCATIE 15 Marketing Brussel 23 Finance Brussel 38 R&D Leuven 47 Logistiek Antwerpen Departement PNR PNAAM PDUUR DNR 1142 InvestOptim 1200 23 1231 NewProduct 4500 38 1648 PlantLayout 1000 47 1721 CapitalRet 1000 23 Project

Vreemde sleutel: voorbeeld (2) WNR WNAAM WADRES 1 Albers Brussel 2 Bogaerts Brussel 3 Celis Leuven 4 Dokmans Antwerpen Werknemer WNR PNR GEWERKT 1 11 30 2 11 20 2 17 40 4 16 10 Werkt_aan PNR PNAAM PDUUR DNR 11 InvestOptim 1200 23 12 NewProduct 4500 38 16 PlantLayout 1000 47 17 CapitalRet 1000 23 Project

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? Werknemer Werknemer Departement WNR WNAAM WADRES DNR DNAAM DLOCATIE 1 Albers Brussel 23 Finance Brussel 2 Bogaerts Brussel 23 Finance Brussel 3 Celis Leuven 38 R&D Leuven 4 Dokmans Antwerpen 47 Logistiek 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 WNR WNAAM WADRES DNR DNR DNAAM DLOCATIE 1 Albers Brussel 23 2 Bogaerts Brussel 23 3 Celis Leuven 38 4 Dokmans Antwerpen 47 15 Marketing Brussel 23 Finance Brussel 38 R&D Leuven 47 Logistiek Antwerpen

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 -> wnaam wnaam -/-> wnr

Normalisatiestappen

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) Departement DNR DNAAM DLOCATIE 15 Marketing Brussel 23 Finance Brussel 38 R&D Leuven, Gent 47 Logistiek Antwerpen, Zeebrugge Departement Deplocatie DNR DNAAM DNR DLOCATIE 15 Marketing 23 Finance 38 R&D 47 Logistiek 15 Brussel 23 Brussel 38 Leuven 38 Gent 47 Antwerpen 47 Zeebrugge

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

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 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) 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) -> GEWERKT WNR -/-> GEWERKT PNR -/-> 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)

Tweede normalisatiestap (voorbeeld) WNR PNR PNAAM PDUUR GEWERKT R12 1 11 InvestOptim 1200 30 2 11 InvestOptim 1200 20 2 17 CapitalRet 1000 40 4 16 PlantLayout 1000 10 WNR PNR GEWERKT Werkt_aan 1 11 30 2 11 20 2 17 40 4 16 10 Project PNR PNAAM PDUUR 11 InvestOptim 1200 12 NewProduct 4500 16 PlantLayout 1000 17 CapitalRet 1000

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) 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)

Derde normalisatiestap (voorbeeld) Werknemer WNR WNAAM DNR DNAAM MGNR 1 Albers 23 Finance 7 2 Bogaerts 23 Finance 7 3 Celis 38 R&D 9 4 Dokmans 47 Logistiek 11 … … … … … Werknemer Departement WNR WNAAM DNR DNR DNAAM MGNR 1 Albers 23 2 Bogaerts 23 Celis 38 Dokmans 47 … … … 7 Basemans 23 15 Marketing 8 23 Finance 7 38 R&D 9 47 Logistiek 11

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) 1NF Student (studentnr, studentnaam, straatnaam, straatnummer, postcode, gemeente) Volgt (studentnr, cursusnr, cursusnaam, profnr, profnaam) 2NF Student (studentnr, studentnaam, straatnaam, straatnummer, postcode, gemeente) Volgt (studentnr, cursusnr) Cursus (cursusnr, cursusnaam, profnr, profnaam) 3NF Student (studentnr, studentnaam, straatnaam, straatnummer, postcode, gemeente) Volgt (studentnr, cursusnr) Cursus (cursusnr, cursusnaam, profnr) Prof (profnr, profnaam)

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 (vervolg) Student (studentnr, studentnaam, straatnaam, straatnummer, postcode, gemeente) Volgt (studentnr, cursusnr) Cursus (cursusnr, cursusnaam, profnr) Prof (profnr, profnaam)

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 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

gebruiker informatiebehoeften ER-model relationeel model DB gebruiker

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 WERKNEMER (WNR, WNAAM, ADRES, SEKSE, GEBOORTEDATUM, LWNR, DNR) LWNR: vreemde sleutel, verwijst naar WNR in WERKNEMER, null toegelaten DNR: vreemde sleutel, verwijst naar DNR in DEPARTEMENT, null niet toegelaten DEPARTEMENT (DNR, DNAAM, DLOCATIE, MGNR) MGNR: vreemde sleutel, verwijst naar WNR in WERKNEMER, null niet toegelaten PROJECT (PNR, PNAAM, PDUUR, DNR) WERKT_AAN (WNR, PNR, GEWERKT) WNR: vreemde sleutel, verwijst naar WNR in WERKNEMER, null niet toegelaten PNR: vreemde sleutel, verwijst naar PNR in PROJECT, null niet toegelaten

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 relationshiptype Werknemer (WNR, WNAAM, ADRES, ..., LWNR) Assumptie: een werknemer krijgt leiding van maximaal één andere werknemer. Kan een werknemer dan leiding geven aan meerdere personen?