ontwerp een datamodel Criteria voor een goed model Ontwerppatronen

1
ontwerp een datamodelCriteria voor een goed
modelOntwerppatronen
2
SQL deel 2 datamodel ontwerp

• Datamodel
• Criteria
• Proces

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

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

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

7
Ontwerpmethode

1. Afbakening van het domein
2. Beschrijven van de relevante informatie
3. Beschrijven van gebruiksmogelijkheden (use cases)
4. Formaliseren van entiteiten en relaties (ERD)
5. Benoemen van entiteiten, attributen en relaties
6. Entity relation diagram
7. Functionele toetsing
8. Datatypen en ------------------------------------
   -----------------------beperkingen
9. Optimaliseren van het model
10. Waarborgen integriteit ( stored procedures,
    triggers, etc)
11. Optimaliseren perfomance ( indexen e.a.
    maatregelen )

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

9
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 )
• Schrijf het resultaat op je blog !

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

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

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?

13
Criteria voor een goed datamodel
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

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

16
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

17
Naamgeving attribuut/kolom

• De scope van betekenis is de entiteit( de sql
  code wordt dan leesbaar )
• bij FKs 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

18
Opdracht datamodel versie 1

• Controleer je datamodel op bovengenoemde
  naamgevingsconventies.

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

20
3de normaalvorm
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)

22
Data-elementen zijn atomair

• Geen samengestelde waarden in één kolom
• Voorachternaam, straatnummerplaats
• 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 emailadres en bij
  docenten is contact een telefoonnummer.

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.

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

25
Hoe ver moet je gaan?

• voetballer
• ID
• naamID
• clubID
• adresID

• naam
• ID
• voornaam
• achternaam

• club
• ID
• naam
• trainer

• adres
• ID
• straat
• postcode
• plaats

26
Hoe ver moet je gaan

• Is_voetballer_bij_club
• persoonID
• clubID

• persoon
• ID
• voornaam
• achternaam
• adresID

• club
• ID
• naam
• trainerID
• adresID

• adres
• ID
• straat
• postcode
• plaats

27
Hoe ver moet je gaan

• Is_lid_van_club
• persoonID
• clubID
• rol speler,trainer

• persoon
• ID
• voornaam
• achternaam
• adresID

• club
• ID
• naam
• adresID

• adres
• ID
• straat
• postcode
• plaats

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

29
Voorbeelden van misontwerp

• http//www.sum-it.nl/cursus/dbdesign/hollands/inde
  x.php3

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

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?

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?

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 -gt connect
• Database Synchronization
• Model doorvoeren in mySQL

34
DataModellen

• ontwerppatronen

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, PKs/FKs
• Bepaal details database realisatie PKs/FKs ,
  datatypen

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

37
Belangrijke tip

• Geeft de relatie een naam
• boek is_geschreven_door auteurauteur
  is_schrijver_van boek
• student is_ingeschreven_bij vakvak
  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

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

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

40
Meer ontwerppatronen

• Lees de reader!

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