ontwerp een datamodel Criteria voor een goed model Ontwerppatronen

Hogeschool van Amsterdam - Interactieve Media – Internet Development – Jochem Meuwese - [email protected] - http://oege.ie.hva.nl/~meuwj/ - http://hva.jochem.nl

ontwerp een datamodel

Criteria voor een goed model

Ontwerppatronen


SQL deel 2: datamodel ontwerp

Datamodel

Criteria

Proces


Modulariteit

User interface

Bussines logic

Data repository


Op te leveren in week 9: één document met daarin

Domein afbakening Entiteiten Relatie Diagram Tabel Definities Eventueel voorbeeld Data Views / Voorbeeld Queries

Reflectie: wat heb je geleerd, wat heb je nog niet geleerd.


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


voorwaarden Op tijd inleveren:

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.


Ontwerpmethode1. Afbakening van het domein

1. Beschrijven van de relevante informatie2. Beschrijven van gebruiksmogelijkheden (use cases)

2. Conceptueel model: ERD op papier !1. Benoemen van entiteiten, attributen en relaties2. Entity relation diagram3. Functionele toetsing

3. Implementatie ERD in DBDesigner/OpenOffice/?1. Datatypen 2. Views

------------------------------------------------------------------------------------3. * Contraints 4. * Waarborgen integriteit ( stored procedures, triggers, etc)5. * Optimaliseren perfomance ( indexen e.a. maatregelen )

* Niet verplicht voor een V


Plan van aanpak

Wk 6: afbakening van het domein

Huiswerk: versie 1 van het conceptueel datamodel Wk 7: criteria voor goed datamodel

Huiswerk: versie 2 van het conceptueel datamodel Wk 8: afronden

implementatie en documentatie datamodel Wk 9: rooster vrij

di: inleveren definitief datamodel per email Wk 10: feedback

feedback en herkansing toets


Afbakening

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 )


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


Opdracht

Identificeer de belangrijkste ‘sterke’ entiteiten Identificeer relaties tussen deze entiteiten Maak een eerste ‘conceptueel’ datamodel

NB:

- Beperk je tot 2 tot 5 entiteiten


Vorige week.

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?


Criteria voor een goed datamodel


Stap 2: datamodel ( ERD )


1. Naamgevingsconventies

2. “3de normaalvorm”

Voor teggies volgende week3. Integriteit waarborgen.

Middels triggers, stored procedures, e.d.

4. Optimalisatie.Indexeren, views


Naamgeving (algemeen)

Geen spaties ( eventueel underscore _ ) Geen gekke karakters Geen afkortingen Niet beginnen met een cijfer Consistent gebruik hoofdletters Beschrijvend

De naam beschrijft het element precies, Laat niets te raden over. Liever een lange naam, dan een onduidelijke naam


Tabelnaam: enkelvoud

Tabel naam: Naam van de entiteit op één rij Enkelvoud

forum berichtID auteur tekst datum

bericht ID auteur tekst datum

berichten berichtID auteur tekst datum


Tabelnaam: enkelvoud

Tabel naam: Naam van de entiteit op één rij Enkelvoud

catalogus productID naam prijs datum

product ID naam prijs datum

producten productID naam prijs datum


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


Opdracht: datamodel versie 1

Controleer je datamodel op bovengenoemde naamgevingsconventies.


Stap 2: datamodel ( ERD )


1. Naamgevingsconventies

2. “3de normaalvorm”

Voor teggies3. Integriteit waarborgen.

Middels triggers, stored procedures, e.d.

4. Optimalisatie.Indexeren, views


“3de normaalvorm”

Regel 1: éénduidige betekenissen

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: géén redundantie

Data mag maar één keer voorkomen, zodat het praktisch ommogelijk is dat de database inconsistente informatie bevat (waarborgt de integriteit)


Data-elementen zijn ‘atomair’

Geen samengestelde waarden in één kolom Fout: Voor+achternaam, straat+nummer+plaats

Geen herhalende waarden in één tabelcel Fout: Komma gescheiden lijst productnummers

(wel: gebruik een aparte tabel)

Laat de betekenis niet afhangen van andere elementen Fout: Bij studenten is ‘contact’ een emailadres en bij

docenten is ‘contact’ een telefoonnummer.


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


Hoe ver moet je gaan?

voetballer ID naamID clubID adresID

club ID naam trainer

adres ID straat postcode plaats

naam ID voornaam achternaam


Hoe ver moet je gaan

persoon ID voornaam achternaam adresID

club ID naam trainerID adresID


Is_voetballer_bij_club persoonID clubID


Hoe ver moet je gaan

persoon ID voornaam achternaam adresID

club ID naam adresID


Is_lid_van_club persoonID clubID rol [speler,trainer]


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


Voorbeelden van misontwerp http://www.sum-it.nl/cursus/dbdesign/hollands/index.php3

http://www.sum-it.nl/cursus/dbdesign/hollands/index.php3


“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 Geen relaties die afgeleid kunnen worden


opdracht

Controleer je datamodel op ‘3de normaalvorm’ Verbeter indien nodig, en maak nieuwe ERD

Vergelijk met je use case. Is het datamodel een basis voor alle gewenste gebruiksmogelijkheden?


huiswerk Download DBDesigner4 of OpenOffice

Maak een genormaliseerde versie van een ERD voor jouw collectie database, waarbij de nadruk ligt op volledigheid

Zijn alle belangrijkste entiteiten gevonden Zijn de attributen in kaart gebracht Zijn de relaties in kaart gebracht

3de normaalvorm Atomaire data-elementen Geen redundante data Geen redundante relaties

Vergelijk met je use case. Is het datamodel een basis voor alle gebruiksmogelijkheden?


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


DataModellen

Ontwerppatronen

Lees reader deel 2


Opdracht ( vijf minuten )

Controleer je datamodel op de volgende punten:Naamgeving:1. Is de naamgeving goed? (enkelvoud)Normalisatie:2. Zijn alle data-elementen ‘atomair’?3. Bevat het model redundante data-elementen?Relaties:4. Is bij iedere relatie de multipliciteit bepaald?5. 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:4. Welke ontwerppatronen uit de reader gebruik je.?

Documents

ontwerp een datamodel Criteria voor een goed model Ontwerppatronen