Hoofdstuk 7: Analyse van informatiebehoeften en ontwerp van gegevensmodellen

1. Hoofdstuk 7: Analyse van informatiebehoeften en ontwerp van gegevensmodellen

2. Overzicht • Analyse van informatiebehoeften • Gegevensmodellering • Het E.R. model • Het E.E.R. model • Het relationele model • Verband tussen beide modellen

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

36. Aggregatie • Bouwen van een samengesteld object • Bouwen van een samengesteld entiteittype op basis van een aantal entiteittypen en hun relationshiptypen

37. Voorbeeld van een EER model

38. gebruiker informatiebehoeften ER-model relationeel model DB gebruiker

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

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

41. Relatie: tabelvoorstelling • Voorstellingsvormen van enkele relationele concepten: tabel - relatie rij - tupel kolom - attribuuttype kolomwaarde - attribuutwaarde • Voorstelling van de relatie ‘Product’

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

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

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

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

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

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

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

49. Waarom normaliseren? Werknemer 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 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

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