Conceptueel databaseontwerp Principes van databases Conceptueel databaseontwerp Hoofdstuk 3

Het databaseontwerpproces Het (uitgebreid) ‘entity-relationship’ model Overzicht Het databaseontwerpproces Het (uitgebreid) ‘entity-relationship’ model Het ontwerp van een (E)ER-diagram

Het databaseontwerpproces Het (uitgebreid) ‘entity-relationship’ model Overzicht Het databaseontwerpproces Het (uitgebreid) ‘entity-relationship’ model Het ontwerp van een (E)ER-diagram

Het databaseontwerpproces Overzicht informatie- vergaring domeinanalyse functionele analyse behoefteanalyse conceptueel ontwerp conceptueel model (bijvoorbeeld EER-diagram) functionele beschrijving databasemodel- onafhankelijk logisch ontwerp dbms- onafhankelijk logisch databaseschema (bijvoorbeeld relationeel) gedragspecificaties fysieke ontwerp DDL-scripts implementatie van gedrag

Het databaseontwerpproces Informatievergaring Communicatie Onderzoek Software Data Handleidingen Rapporten Abstrahering, modellering en implementatie Abstrahering Modellering (EER of UML)

Het databaseontwerpproces EER-diagram Stuk stuknr plaatsnr opge- voerd reser- vatie 1 N betaald titel soort organisator uitvoerder duur Voorstelling tijdstip datum beginuur Klant klantnr naam adres Plaats Zone tarief M prijs in

Het databaseontwerpproces Functionele beschrijvingen Controle_periode (IN Periode IN Artiest.Geboren IN Artiest.Gestorven OUT Status) EXCEPTIE (OnmogelijkePeriode) –operatie om te controleren of de periode van het schilderij wel valt binnen de leefperiode van de schilder van het schilderij. Ouderdom (IN Periode OUT Ouderdom) EXCEPTIE (PeriodeOnbekend) –operatie om de ouderdom van een schilderij te bepalen. Daartoe wordt de periode van het schilderij vergeleken met de huidige datum. Opmerking: UML doet beiden

Het databaseontwerpproces CASE-tools

Het databaseontwerpproces COMPANY TOOL FUNCTIONALITY Embarcadero Technologies ER Studio Database Modeling in ER and IDEF1X DB Artisan Database administration and space and security management Oracle Developer 2000 and Designer 2000 Database modeling, application development Popkin Software System Architect 2001 Data modeling, object modeling, process modeling, structured analysis/design Platinum Technology Platinum Enterprice Modeling Suite: Erwin, BPWin, Paradigm Plus Data, process, and business component modeling Persistence Inc. Pwertier Mapping from O-O to relational model Rational Rational Rose Modeling in UML and application generation in C++ and JAVA Rogue Ware RW Metro Resolution Ltd. Xcase Conceptual modeling up to code maintenance Sybase Enterprise Application Suite Data modeling, business logic modeling Visio Visio Enterprise Data modeling, design and reengineering Visual Basic and Visual C++

Het databaseontwerpproces Het (uitgebreid) ‘entity-relationship’ model Overzicht Het databaseontwerpproces Het (uitgebreid) ‘entity-relationship’ model Het ontwerp van een (E)ER-diagram

Het uitgebreid ‘entity-relationship’ model Entiteittypes en relatietypes Structurele aspecten Een entiteit is een ‘ding’ dat een zelfstandig bestaan leidt in de reële wereld Een entiteittype karakteriseert een collectie van entiteiten en wordt gekenmerkt door een naam en een verzameling van attributen

Het uitgebreid ‘entity-relationship’ model Voorbeelden en visualisatie Artiest Eigenaar Schilderij Naam Plaats Land ID Periode Waarde Gestorven Voornaam Geboren

Het uitgebreid ‘entity-relationship’ model Een relatietype is een verwantschap tussen twee of meer al dan niet verschillende entiteittypes. Men spreekt respectievelijk van een binair, ternair of n-air (n>3) relatietype. Verder wordt elk relatietype gekenmerkt door een naam. Een relatietype kan attributen hebben.

Het uitgebreid ‘entity-relationship’ model Voorbeelden en visualisatie Werknemer Schilderij Plaats is partner Procent werkt plan- ning Bedrijf Persoon Tentoonstelling

Het uitgebreid ‘entity-relationship’ model Karakteristieken en restricties Attributen Meerwaardige versus enkelwaardige attributen Samengestelde versus enkelvoudige attributen Afgeleide attributen Sleutelattributen (sleutel en surrogaatsleutel) Talen meerwaardig Plaats samengesteld Straat Nummer Postcode Leeftijd afgeleid Naam sleutelattribuut

Het uitgebreid ‘entity-relationship’ model Zwakke entiteittypes Identificerende entiteittypes Identificerend relatietype Partiële sleutel Een zwak entiteittype karakteriseert zwakke entiteiten. Dit zijn entiteiten die niet op zichzelf kunnen bestaan, maar voor hun bestaan afhankelijk zijn van het bestaan van andere, identificerende entiteiten.

Het uitgebreid ‘entity-relationship’ model Voorbeelden en visualisatie Artiest Patiënt Student Cursus Naam PID Nummer Code maakt voor legt af Naam Jaar Zittijd Schilderij Medisch dos. Examen

Het uitgebreid ‘entity-relationship’ model Relatietypes Kardinaliteitrestricties één of meerdere Participatierestricties totaal of partieel Voorbeelden en visualisatie Werknemer Boek Schilderij Plaats M N 1 1 Procent is partner werkt leent plan- ning N 1 1 1 N Bedrijf Persoon Lezer Tentoonstelling

Het uitgebreid ‘entity-relationship’ model Alternatieve notatie: (min,max)-notatie Werknemer Boek Schilderij Plaats (1,M) (0,N) (0,1) (0,1) Procent is partner werkt leent plan- ning (0,1) (0,1) (0,N) (0,1) (1,N) Bedrijf Persoon Lezer Tentoonstelling

Het uitgebreid ‘entity-relationship’ model Subtypes, supertypes en overerving Structurele aspecten Het subtype ‘erft’ alle attributen en verwante relatietypes van het supertype kan daarnaast nog eigen attributen en relatietypes hebben Een subtype is een entiteittype dat een sub- collectie van entiteiten karakteriseert. Het entiteittype van de collectie waarbinnen deze subcollectie wordt beschouwd, wordt het supertype genoemd.

Het uitgebreid ‘entity-relationship’ model Voorbeelden en visualisatie Kunstwerk Werknemer         Schilderij Beeldhouw Administratie Technicus Manager Wandtapijt Juweel Kaderlid

Het uitgebreid ‘entity-relationship’ model Supertype/subtype-netwerken Supertype/subtype-hiërarchieën Meervoudige overerving: beperking Het creëren van specifiekere subtypes voor een een gegeven entiteittype noemen we speciali- satie. Het creëren van een algemeen supertype dat de gemeenschappelijke attributen en relatietypes van een aantal gegeven entiteit- types verenigt, noemen we generalisatie.

Het uitgebreid ‘entity-relationship’ model Voorbeeld en visualisatie Doek Hout Perkament Schilderij Kunstwerk Juweel Beeldhouw Wandtapijt  Papier Olieverf Was Waterverf Acryl Outfit Kledij

Het uitgebreid ‘entity-relationship’ model Karakteristieken en restricties Overlappende versus disjuncte subtypes Kunstwerk Artiest d o        Schilderij Beeldhouw Schilder Beeldhouwer Wandtapijt Juweel Tekenaar

Het uitgebreid ‘entity-relationship’ model Geconditioneerde subtypes Attribuutgedefinieerde supertype/subtype-verwantschap Naam ID Periode Waarde Schilderij Kunstwerk Wandtapijt Beeldhouw Juweel  d Type ‘sch’ ‘wnd’ ‘jwl’ ‘bld’

Het uitgebreid ‘entity-relationship’ model Categorieën Structurele aspecten Elke entiteit van de categorie is slechts entiteit van juist één van de supertypes Een categorie of unietype is een ‘speciaal’ sub- type met verschillende supertypes, dat wordt ingevoerd om de entiteiten van deze super- types te groeperen

Het uitgebreid ‘entity-relationship’ model Voorbeeld en visualisatie Persoon Eigenaar Bedrijf  U Museum

Het uitgebreid ‘entity-relationship’ model Karakteristieken en restricties Geconditioneerde supertypes Persoon Eigenaar Bedrijf  U Museum Soort ‘particulier’ ‘bedrijf’ ‘museum’

Het databaseontwerpproces Het (uitgebreid) ‘entity-relationship’ model Overzicht Het databaseontwerpproces Het (uitgebreid) ‘entity-relationship’ model Het ontwerp van een (E)ER-diagram

Het ontwerp van een (E)ER-diagram Casestudie: Database voor een jeugdvereniging Een jeugdvereniging wenst een database op te zetten, ter ondersteuning van haar ledenadministratie en werking. Daarbij moet rekening worden gehouden met de volgende aspecten. Bij de inschrijving krijgt elk lid een uniek lidnummer. Gegevens zoals naam, voornaam, adres, geslacht en geboortedatum worden geregistreerd. In het begin van het werkjaar worden de leden ingedeeld in verschillende groepen volgens leeftijdsklassen. Er kunnen meerdere groepen zijn voor één leeftijdsklasse. Elke groep heeft een leid(st)er. Een leid(st)er is maximaal verantwoordelijke voor één groep. De leiding vormt zelf ook een groep, die correspondeert met de hoogste leeftijdsklasse. De leid(st)ers organiseren allerhande activiteiten voor de leden. Een dergelijke activiteit kan bestemd zijn voor één of meerdere groepen tegelijkertijd. Tevens kunnen meerdere activiteiten voor dezelfde groep worden gepland (op verschillende uren). Aan sommige activiteiten kunnen extra kosten verbonden zijn. Los daarvan kan het zijn dat de leden zich op voorhand voor een activiteit moeten inschrijven (en de kosten vereffenen). subtypes, supertypes en categorieën identificatie van entiteittypes,

Het ontwerp van een (E)ER-diagram Oplossing Lid Groep Activiteit creatie entiteittypes

Het ontwerp van een (E)ER-diagram Casestudie: Database voor een jeugdvereniging Een jeugdvereniging wenst een database op te zetten, ter ondersteuning van haar ledenadministratie en werking. Daarbij moet rekening worden gehouden met de volgende aspecten. Bij de inschrijving krijgt elk lid een uniek lidnummer. Gegevens zoals naam, voornaam, adres, geslacht en geboortedatum worden geregistreerd. In het begin van het werkjaar worden de leden ingedeeld in verschillende groepen volgens leeftijdsklassen. Er kunnen meerdere groepen zijn voor één leeftijdsklasse. Elke groep heeft een leid(st)er. Een leid(st)er is maximaal verantwoordelijke voor één groep. De leiding vormt zelf ook een groep, die correspondeert met de hoogste leeftijdsklasse. De leid(st)ers organiseren allerhande activiteiten voor de leden. Een dergelijke activiteit kan bestemd zijn voor één of meerdere groepen tegelijkertijd. Tevens kunnen meerdere activiteiten voor dezelfde groep worden gepland (op verschillende uren). Aan sommige activiteiten kunnen extra kosten verbonden zijn. Los daarvan kan het zijn dat de leden zich op voorhand voor een activiteit moeten inschrijven (en de kosten vereffenen). identificatie van attributen, hun karakteristieken en hun restricties

Het ontwerp van een (E)ER-diagram Oplossing leeftijd minimum maximum naam lidnummer geb.datum voornaam adres straat postcode nummer omschrijving kost tijdstip geslacht Lid Groep Activiteit creatie attributen

Het ontwerp van een (E)ER-diagram Casestudie: Database voor een jeugdvereniging Een jeugdvereniging wenst een database op te zetten, ter ondersteuning van haar ledenadministratie en werking. Daarbij moet rekening worden gehouden met de volgende aspecten. Bij de inschrijving krijgt elk lid een uniek lidnummer. Gegevens zoals naam, voornaam, adres, geslacht en geboortedatum worden geregistreerd. In het begin van het werkjaar worden de leden ingedeeld in verschillende groepen volgens leeftijdsklassen. Er kunnen meerdere groepen zijn voor één leeftijdsklasse. Elke groep heeft een leid(st)er. Een leid(st)er is maximaal verantwoordelijke voor één groep. De leiding vormt zelf ook een groep, die correspondeert met de hoogste leeftijdsklasse. De leid(st)ers organiseren allerhande activiteiten voor de leden. Een dergelijke activiteit kan bestemd zijn voor één of meerdere groepen tegelijkertijd. Tevens kunnen meerdere activiteiten voor dezelfde groep worden gepland (op verschillende uren). Aan sommige activiteiten kunnen extra kosten verbonden zijn. Los daarvan kan het zijn dat de leden zich op voorhand voor een activiteit moeten inschrijven (en de kosten vereffenen). identificatie van reguliere relatietypes, hun attributen, karakteristieken en restricties

Het ontwerp van een (E)ER-diagram Oplossing leeftijd minimum maximum naam lidnummer geb.datum voornaam adres straat postcode nummer omschrijving kost tijdstip geslacht Lid Groep Activiteit lid van N leider voor schrijft in 1 M betaald creatie relatietypes

Het ontwerp van een (E)ER-diagram Eindoplossing lid van N Lid Groep Activiteit leeftijd minimum maximum naam lidnummer geb.datum voornaam adres straat postcode nummer omschrijving kost tijdstip leider voor schrijft in 1 M betaald geslacht

Het ontwerp van een (E)ER-diagram Casestudie: Reservatiesysteem voor een theater In een theaterzaal worden verschillende stukken opgevoerd (toneel, ballet, opera enzovoort). Doorgaans worden verschillende voorstellingen van een bepaald stuk opgevoerd. Voor elk stuk wordt de titel, de duur, de soort, de organisator, de uitvoerder en een uniek nummer bewaard. Van iedere voorstelling wordt de datum en het beginuur opgeslagen. Aangezien er maar één zaal is, kan op hetzelfde ogenblik maar één voorstelling worden geprogrammeerd. De zitplaatsen in de zaal worden doorlopend genummerd en zijn ingedeeld in zones die een aparte naam hebben. De toegangsprijs is afhankelijk van de zone van de zitplaats. De verkoop van tickets verloopt uitsluitend via reservering. De klant moet hierbij zijn naam en adres opgeven en kan dan één of meerdere zitplaatsen reserveren voor een voorstelling. Er wordt bijgehouden of voor deze reservering reeds werd betaald.

Het ontwerp van een (E)ER-diagram Eindoplossing datum beginuur naam titel tijdstip soort klantnr adres stuknr 1 opge- voerd N Stuk Voorstelling Klant organisator M 1 M duur uitvoerder reser- vering betaald tarief prijs N N 1 N naam Zone in Plaats plaatsnr

Het ontwerp van een (E)ER-diagram Casestudie: Database voor een softwarefirma Een softwarefirma wil een database opzetten als hulp bij het controleren en corrigeren van fouten die ontdekt worden in haar softwareproducten. Aan elk softwareproduct wordt een uniek productnummer toegekend en een beschrijving toegevoegd. Van een product worden verschillende versies uitgebracht, die per product een versienummer krijgen. Daarnaast wordt ook de datum waarop de versie werd uitgebracht bewaard. Een versie van een product kan zowel door externe als door interne gebruikers (bijvoorbeeld programmeurs en systeemtesters) worden gebruikt. Interne gebruikers mogen alle versies van alle producten gebruiken zonder voorafgaande aanvraag. Externen dienen de versie van het product eerst aan te kopen. Bij de verkoop wordt voor elk verkocht exemplaar een uniek registratienummer –dat geldt voor één of meerdere externe gebruikers– en de registratiedatum vastgelegd. Wanneer een gebruiker een probleem constateert, kan hij of zij hierover een probleemrapport opstellen (en overmaken aan de onderhoudsafdeling). Zo’n rapport kan zowel door een interne als door een externe gebruiker worden opgemaakt en vermeldt naast een verwijzing naar het product en de versie, ook de datum en een omschrijving van het probleem. Aan elk rapport wordt verder een uniek rapportnummer, een prioriteit en een status (aan te passen door de onderhoudsafdeling) toegekend. Aangezien externe gebruikers enkel een rapport mogen sturen in verband met de versies waarvoor zij geregistreerd zijn, dienen zij steeds hun registratienummer te vermelden. Interne gebruikers dienen enkel hun werknemernummer op te geven, terwijl externen geïdentificeerd worden via de combinatie van hun naam en de naam van hun bedrijf. Van alle gebruikers wordt tenslotte ook nog het telefoonnummer, adres en e-mail adres bijgehouden (indien bekend).

Het ontwerp van een (E)ER-diagram naam werknemernr Eindoplossing gebruikerID Ext_Gebr. Int_Gebr. bedrijf productnr N Product U  telefoon beschr. 1 Gebruiker adres bezit van 1 e-mail datum door rapportnr N versienr Versie 1 N omschr. Rapport datum 1 status over d prioriteit voor   N M Int_Rapport Ext_Rapport registratienr N 1 Registratie N over datum