Download de presentatie
GepubliceerdStefanie Smeets Laatst gewijzigd meer dan 10 jaar geleden
1
ontwerp een datamodel Criteria voor een goed model Ontwerppatronen
Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
2
SQL deel 2: datamodel ontwerp
Criteria Proces Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
3
Modulariteit Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
4
Op te leveren in week 9: één document met daarin
Domein afbakening Entiteiten Relatie Diagram Tabel Definities Eventueel voorbeeld Data Views / Voorbeeld Queries ( reparatie onvoldoende toets ) Werk in groepjes van 3 onder leiding van één ‘expert’. De expert gaat voor een G als alle groepsleden een goed model opleveren. De anderen gaan voor een V als eigen model goed wordt opgeleverd. Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
5
Criteria Vaardigheden: SQL, genormaliseerd ERD
Jargon, terminologie, vaktermen Bronnen en gereedschappen Overdraagbaar, begrijpelijk: documentatie Zinvolle, relevante toepassing Samenwerking, advies vragen en geven Interesse en ontwikkeling Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
6
voorwaarden Op tijd inleveren: Correct nederlands:
Week 9 Correct nederlands: Weinig taalfouten Gestructureerd document Titel, inhoudsopgave, paginanummers, etc. Compleet : Met bijlagen of links naar broncode Voorzien van metadata: Naam, nummer, klas, datum, vak, beoordelaar Reflectie: Beschrijf waarom jij vind dat je aan de criteria voldoet. Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
7
Ontwerpmethode Afbakening van het domein
Beschrijven van de relevante informatie Beschrijven van gebruiksmogelijkheden (use cases) Formaliseren van entiteiten en relaties (ERD) Benoemen van entiteiten, attributen en relaties Entity relation diagram Functionele toetsing Datatypen en beperkingen Optimaliseren van het model Waarborgen integriteit ( stored procedures, triggers, etc) Optimaliseren perfomance ( indexen e.a. maatregelen ) Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
8
Plan van aanpak Wk 6: afbakening van het domein
Huiswerk: versie 1 van het datamodel Wk 7: criteria voor goed datamodel Huiswerk: versie 2 van het datamodel Wk 8: roostervrij Huiswerk: afronding van het datamodel Wk 9: oplevering presentatie en documentatie datamodel Wk 10: feedback feedback per team Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
9
Afbakening Schrijf het resultaat op je blog !
Welke informatie zal de database bevatten? Tot op welke details? entiteiten en/of functionaliteiten ? Welke ‘entiteiten’ behoren tot het domein? En welke niet? Welke functies zal de database moeten kunnen vervullen? Wat moet een gebruiker kunnen doen? ( use case diagram ) Schrijf het resultaat op je blog ! Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
10
Sterke en zwakke entiteiten
Niet alle entiteiten zijn even belangrijk in het datamodel. Sterke entiteiten 2 to 5 kern-entiteiten Worden in ieder geval in het model opgenomen, ook als andere entiteiten er niet zouden zijn. Raken de essentie van je concept Zwakke entiteiten Beschrijven veelal relaties tussen sterke entiteiten Zijn afhankelijk van sterke entiteiten. Opzoeklijstjes Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
11
Opdracht Identificeer de belangrijkste ‘sterke’ entiteiten
Identificeer relaties tussen deze entiteiten Maak een eerste ‘conceptueel’ datamodel NB: - Beperk je tot 2 tot 5 entiteiten Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
12
Opdracht. Maak een eerste versie van een ERD voor jouw collectie database, waarbij de nadruk ligt op Zijn alle belangrijkste entiteiten gevonden Zijn de attributen in kaart gebracht Zijn de relaties in kaart gebracht Vergelijk met je use case. Is het datamodel een basis voor alle gebruiksmogelijkheden? Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
13
Criteria voor een goed datamodel
Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
14
Stap 2: datamodel ( ERD ) Criteria voor een goed model
Naamgevingsconventies “3de normaalvorm” Voor teggies Integriteit waarborgen. Middels triggers, stored procedures, e.d. Optimalisatie. Indexeren, views Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
15
Naamgeving (algemeen)
Geen spaties ( eventueel underscore _ ) Geen gekke karakters Geen afkortingen Niet beginnen met een cijfer Consistent gebruik hoofdletters De naam beschrijft het element precies, Laat niets te raden over. Liever een lange naam, dan een onduidelijke naam Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
16
Tabelnaam: enkelvoud Tabel naam: Naam van de entiteit op één rij
forum berichtID auteur tekst datum berichten berichtID auteur tekst datum bericht ID auteur tekst datum Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
17
Naamgeving attribuut/kolom
De ‘scope’ van betekenis is de entiteit ( de sql code wordt dan leesbaar ) bij FK’s: de naam van de relatie als prefix. (vaak is dat ook de naam van de tabel waarnaar wordt verwezen) bericht berichtID berichtauteur berichtTekst datum bericht ID auteurID tekst datum Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
18
Opdracht: datamodel versie 1
Controleer je datamodel op bovengenoemde naamgevingsconventies. Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
19
Stap 2: datamodel ( ERD ) Criteria voor een goed model
Naamgevingsconventies “3de normaalvorm” Voor teggies Integriteit waarborgen. Middels triggers, stored procedures, e.d. Optimalisatie. Indexeren, views Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
20
3de normaalvorm Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
21
“3de normaalvorm” Regel 1: eenvoud
Als je ingewikkelde ‘als-dit,dan-dat’ constructies of procedures nodig hebt om de betekenis van je elementen uit te leggen zit je fout. Regel 2: vermijdt redundantie Data mag maar één keer voorkomen, zodat het praktisch ommogelijk is dat de database inconsistente informatie bevat (waarborgt de integriteit) Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
22
Data-elementen zijn ‘atomair’
Geen samengestelde waarden in één kolom Voor+achternaam, straat+nummer+plaats Geen herhalende waarden in één tabelcel Komma gescheiden lijst productnummers (gebruik een aparte tabel) Laat de betekenis niet afhangen van andere elementen Bij studenten is ‘contact’ een adres en bij docenten is ‘contact’ een telefoonnummer. Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
23
Data element zijn ‘atomair’
Fout Naam = “Fons van Kesteren” Goed Voornaam = “Fons” Achternaam = “Kesteren” Tussenvoegsel = “van” NB: dit hangt wel een beetje af van hoe je deze dataelement wilt gaan gebruiken. Als je denkt dat je voor en achternaam nooit hoeft te onderscheiden, dan hoef je ook geen aparte kolommen te maken. Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
24
Vermijdt redundantie ( 1 )
Iedere rij in een tabel bevat attributen van één entiteit en niets dan attributen van die ene entiteit. Iedere rij heeft een unieke sleutel ( of gecombineerde sleutel ) voetballer ID naam club trainer voetballer ID naam clubID club ID trainer Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
25
Hoe ver moet je gaan? voetballer ID naamID clubID adresID naam ID
voornaam achternaam club ID naam trainer adres ID straat postcode plaats Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
26
Hoe ver moet je gaan Is_voetballer_bij_club persoon persoonID ID
clubID persoon ID voornaam achternaam adresID club ID naam trainerID adresID adres ID straat postcode plaats Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
27
Hoe ver moet je gaan Is_lid_van_club persoon persoonID ID clubID
rol [speler,trainer] persoon ID voornaam achternaam adresID club ID naam adresID adres ID straat postcode plaats Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
28
Vermijdt redundantie (2)
Data-elementen die afgeleid kunnen worden mogen niet in de tabel voor komen product ID prijs btw Prijs_inc_btw product ID prijs btw Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
29
Voorbeelden van misontwerp
Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
30
“3de normaalvorm” Regel 1: eenvoud Data-elementen zijn atomair
Regel 2: vermijdt redundantie Per rij, een entiteit (zo niet dan tabel splitsen ) Geen kolommen die berekend kunnen worden Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
31
opdracht Controleer je datamodel op ‘3de normaalvorm’
Verbeter indien nodig, en maak nieuwe flap Vergelijk met je use case. Is het datamodel een basis voor alle gewenste gebruiksmogelijkheden? Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
32
huiswerk Download DBDesigner4 van fabforce.net
Maak een eerste versie van een ERD voor jouw collectie database, waarbij de nadruk ligt op Zijn alle belangrijkste entiteiten gevonden Zijn de attributen in kaart gebracht Zijn de relaties in kaart gebracht Vergelijk met je use case. Is het datamodel een basis voor alle gebruiksmogelijkheden? Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
33
Werken met DBdesigner Relaties leggen
Gebruik alleen de 1ste ( one-to-many) en de 3de (many-to-many) relatietype DBDesigner en mySQL Connectie met mySQL Database, naam, wachtwoord -> connect Database Synchronization Model doorvoeren in mySQL Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
34
DataModellen ontwerppatronen
Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
35
Logische Model vs. Fysiek Model
Logisch model: entiteiten, attributen en relaties Geen details met betrekking tot database realisatie Geef relaties een naam Fysiek model tabellen, kolommen, PK’s/FK’s Bepaal details database realisatie: PK’s/FK’s , datatypen Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
36
many-to-one, many-to-many, one-to-one
Hoe kunnen we deze verschillende logische relaties in een fysiek datamodel realiseren? one-to-one one-to-many / many-to-one many-to-many Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
37
Belangrijke tip Geeft de relatie een naam: Bepaal multipiliciteit :
boek is_geschreven_door auteur auteur is_schrijver_van boek student is_ingeschreven_bij vak vak wordt_gevolgd_door student Bepaal multipiliciteit : Logische: many-to-one, one-to-many : Fysiek: FK in ‘many’-tabel verwijst naar PK in ‘one’-tabel Logisch: many-to-many: Fysiek: creeer een ‘tussentabel’ Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
38
Many-to-one = FK to PK voetballer is_lid_van club
meer voetballers zijn lid van een club De Foreign Key verwijst naar de Primary Key voetballer ID naam clubID club ID trainer Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
39
Many-to-Many = tussentabel
persoon is_lid_van vereniging meer personen zijn lid van meer verenigingen Gebruik een tussentabel voor de relatie De relatie opvatten als entiteit ( ‘lidmaatschap’ ) ls_lid_van persoonID verenigingID ... persoon ID naam … ... vereniging ID Naam ... Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
40
Meer ontwerppatronen Lees de reader!
Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
41
Opdracht ( vijf minuten )
Controleer je datamodel op de volgende punten: Naamgeving: Is de naamgeving goed? (enkelvoud) Normalisatie: Zijn alle data-elementen ‘atomair’? Bevat het model redundante data-elementen? Relaties: Is bij iedere relatie de multipliciteit bepaald? Is de multipliciteit vertaald naar correcte relaties? many-to-one = FK in ‘many’-tabel naar PK in ‘one’-tabel Many-to-many = tussen tabel ( zwakke entiteit ) Ontwerppatronen: Welke ontwerppatronen uit de reader gebruik je.? Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese
Verwante presentaties
© 2024 SlidePlayer.nl Inc.
All rights reserved.