De presentatie wordt gedownload. Even geduld aub

De presentatie wordt gedownload. Even geduld aub

1 Conceptueel databaseontwerp Hoofdstuk 3 Principes van databases.

Verwante presentaties


Presentatie over: "1 Conceptueel databaseontwerp Hoofdstuk 3 Principes van databases."— Transcript van de presentatie:

1 1 Conceptueel databaseontwerp Hoofdstuk 3 Principes van databases

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

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

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

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

6 6 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 N M prijs in 1 N naam N M 1

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

8 8 Het databaseontwerpproces CASE-tools

9 9 Het databaseontwerpproces COMPANYTOOLFUNCTIONALITY Embarcadero Technologies ER StudioDatabase Modeling in ER and IDEF1X DB ArtisanDatabase administration and space and security management OracleDeveloper 2000 and Designer 2000 Database modeling, application development Popkin SoftwareSystem Architect 2001Data 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.PwertierMapping from O-O to relational model RationalRational RoseModeling in UML and application generation in C++ and JAVA Rogue WareRW MetroMapping from O-O to relational model Resolution Ltd.XcaseConceptual modeling up to code maintenance SybaseEnterprise Application Suite Data modeling, business logic modeling VisioVisio EnterpriseData modeling, design and reengineering Visual Basic and Visual C++

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

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

12 12 Het uitgebreid ‘entity-relationship’ model Artiest Eigenaar Schilderij Naam Plaats Land NaamID PeriodeWaarde Gestorven Naam Voornaam Geboren Voorbeelden en visualisatie

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

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

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

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

17 17 Het uitgebreid ‘entity-relationship’ model Voorbeelden en visualisatie Artiest Schilderij maakt StudentCursus Patiënt Medisch dos. voor Examen legt af JaarZittijdNaamPIDNaamCodeNummer

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

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

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

21 21 Het uitgebreid ‘entity-relationship’ model Voorbeelden en visualisatie ManagerAdministratieWerknemerKaderlidTechnicusSchilderijKunstwerkWandtapijtBeeldhouwJuweel        

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

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

24 24 Het uitgebreid ‘entity-relationship’ model –Karakteristieken en restricties Overlappende versus disjuncte subtypes SchilderijKunstwerkWandtapijtBeeldhouwJuweel     SchilderArtiestTekenaarBeeldhouwer    d o

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

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

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

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

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

30 30 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 entiteittypes, subtypes, supertypes en categorieën

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

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

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

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

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

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

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

38 38 Het ontwerp van een (E)ER-diagram Eindoplossing Stuk stuknrplaatsnr opge- voerd reser- vering 1 N betaaldtitelsoortorganisatoruitvoerderduur Voorstelling tijdstipdatumbeginuur Klant klantnrnaamadres PlaatsZone tarief N M prijs in 1 N naam N M 1

39 39 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 adres bijgehouden (indien bekend).

40 40 Het ontwerp van een (E)ER-diagram Eindoplossing werknemernr Product van 1 N datum Versie voor M Ext_Gebr.  U Int_Gebr.Rapport   d Gebruiker door Int_RapportExt_Rapport telefoonadres rapportnromschr.statusprioriteit gebruikerID naambedrijf Registratie 1 N productnrbeschr.versienrdatumregistratienrdatum 1 N bezit over 1 N 1 N N


Download ppt "1 Conceptueel databaseontwerp Hoofdstuk 3 Principes van databases."

Verwante presentaties


Ads door Google