Datamodelleren en databases 2011 Introductie Leen Breure 1/33 Opzet van de cursus Twee hoorcolleges in totaal week 1 en week 8 (14 juni) Wekelijks practicum: ca. 2 * 1 uur 1 uur: ontwikkeling van eigen database toepassing van de handboekstof team-van-2: ontwerp en implementatie 1 uur: hulp en feedback bij weekopdrachten Simon Pool Pauline Hovers 2/33 Werkwijze per week 1. Handboekstof lezen *) 2. Weekopdrachten maken 3. Practicum: eventueel hulp vragen bij opdrachten bespreking ingeleverde opdrachten 4. Practicum: voortgang eigen database bespreken (invullen template!) 5. Inleveren weekopdrachten *) Zie ook de slides bij elk hoofdstuk 3/33 1
Ontwerp eigen database Leerstof toepassen op je eigen wereld Begrenzing: niet te groot, niet te klein Requirements datamodel bevraging Ruimte voor individuele niveauverschillen Deliverable aan het einde: databaseontwerp (template) + database met data + queries 4/33 Toetsing A. Weekopdrachten (individueel): 25% alle opdrachten inleveren via Submit enkele worden nagekeken: 0..8 (bonus: 9, 10) niet te herkansen, wel te compenseren B. Eigen databaseontwerp (team): 25% C. Tentamen: 50% mc-deel modelleeropgaven (boek) Proeftoets (alleen mc): tijdens practicum: 6 juni 5/33 Feedback Handboekstof: bij eigen databaseontwerp Weekopdrachten: stud. ass. bespreken nagekeken opgaven Eigen databaseontwerp: wekelijks Tentamen: proeftoets inkijken na het tentamen 6/33 2
Groepen en timeslots N = 60 4 vaste groepen: elk ca. 15 personen lijst invullen! maandagmiddag 13-14 uur 14-15 uur 15-16 uur 16-17 uur database ontwerp Groep 1 Groep 2 Groep 3 Groep 4 weekopgaven Groep 2 Groep 1 Groep 4 Groep 3 BBL 103 overige zalen 7/33 Kalender 8/33 Is datamodelleren belangrijk? Data modeling is the hardest and most important activity in the RDBMS world. If you get the data model wrong, your application might not do what users need, it might be unreliable, it might fill up the database with garbage. Philip Greenspun http://philip.greenspun.com/sql/data-modeling.html 9/33 3
Opmerkingen Datamodelleren = regels toepassen voorbeelden nodig: running example: Pine Valley je eigen database Datamodelleren = communiceren met klant Vaak belang pas ingezien, als het fout gaat kost geld, conflicten Doel van de cursus: iedereen op redelijk niveau database ontwerpen en datamodel kan beoordelen 10/33 Vragen over het praktische gedeelte? Dan nu de inhoud van datamodelleren 11/33 Datamodelleren: ontwerpen van de database = kern van informatiesysteem data requirements bedrijfsproces datamodel theoretisch databasemodel b.v. relationele database model diagram 12/33 4
Dat wil zeggen Analyse van informatie & ontwerp database: soorten entiteiten en hun attributen verbanden en afhankelijkheden die bestaan in Universe of Discourse (UoD) = de mini-wereld van de database met als doel: datamodel database-structuur N.B. Er is meestal niet een enkel goed model (varianten) communiceren! 13/33 Database en informatiesysteem DBMS 14/33 Waarom een DBMS? Wat is het verschil tussen A en B (implicaties)? 15/33 5
DBMS data independence: Scheiding van de data en de programma s Data access staat los van (veranderingen in) fysieke dataopslag In de database velden toevoegen / verwijderen zonder noodzakelijk programma s aan te passen De data verwerkende programma s worden robuust: immuun voor veranderingen in de database 16/33 Voorbeeld datamodellering Hondenschool 17/33 Het begin lijkt makkelijk Maar wat te doen als iemand meer dan één hond heeft? Redundantie! 18/33 6
Dan anders Ook dit werkt niet: Voor hoeveel honden moeten er velden komen? Wat te doen met de attributen van hond (m/v, soort, etc.) Ingewikkeld bevragen: waar zit Nero (Hond1 / Hond2 / Hond3)? 19/33 Maar wel zó primary key primary key foreign key 1:N-relatie 20/33 Methodologie Datamodelleren gaat in stappen Verschillen, afhankelijk van de gekozen methodolgie voor systeemontwkkeling Meestal 3 niveau s: conceptueel logisch fysiek 21/33 7
Niveaus van datamodelleren Conceptueel de wereld die wordt vastgelegd in de database (Universe of Discourse) entitytypes en attributen Logisch een datamodel toegesneden op de implementatie-omgeving, b.v. een RDBMS tabellen en velden Fysiek technische specificatie van tabellen, veldlengte. veldtype, etc. indexen, etc. 22/33 Conceptueel: ER-model ER = Entity-Relationship top-down benadering bedacht door P. Chen (1976) entiteitsklassen (= entity types) met attributen relaties tussen deze entiteitsklassen requirements te modelleren - ERD te lezen als verzameling beweringen (assertions) over samenhang in UoD resulteert in ERD (entity-relationship diagram) 23/33 Varianten in notatie Entiteiten en relaties Entiteit met attribuut Relatie met attribuut De notatie met de kraaiepoot is eenvoudiger, maar ook beperkter (relaties geen attributen) 24/33 8
Voorbeeld ERD optionaliteit entiteitsklasse mag ook attribuutnamen bevatten, i.h.b. PK en FK Hoe het diagram te lezen? relatie met cardinaliteit (connectivity) en labels 25/33 Logisch: normaliseren Logische ontwerp houdt rekening met het theoretische opslagmodel meestal het relationele database model (tabellen) ERD verzameling tabellen normaliseren = techniek hiervoor Normaliseren in stappen = normaalvormen: 1NF 2NF 3NF etc. 26/33 Relationele tabel tabel = relatie KlantNr 134 135 136 etc. Altijd rechthoekig dus geen spreadsheet-tabel Init Naam Adres Plaats J.A.P. Pieters Westzoom 12 Breda K. Verhoog Voorstraat 1 Utrecht M.A. Jansen Zuidwal 3 Ede etc. etc. etc. etc. cel (atomaire waarde) kolom = veld rij = record = tuple records: verzameling volgorde niet relevant voor het model 27/33 9
Niet genormaliseerd Crse B74 B94 Coursename Comp Sci Comp Apps Level Ba Ma Mod B741 B742 B743 B744 B745 B951 B952 B741 Mod-name Program 1 Hardware 1 Data Proc 1 Program 2 Hardware 2 Information Web infosys Program 1 Status Basic Medium Advanced Basic Credit s Speadsheet format (GEEN relationele tabel) Repeating groups: 1 Course-name met N Mod-names 8 11 15 8 28/33 Doel van normaliseren De juiste indeling in tabellen welke attributen horen logisch bij elkaar elke tabel: één entiteitstype Sleutels (primary keys, foreign keys) vinden minimale PK FK verwijst naar PK Redundantie vermijden 29/33 Fysiek: dataopslag & -toegang Veldlengtes Datatypes Primaire en secundaire indexen Disk space Client/server Autorisatie en beveiliging etc. 30/33 10
Wat is een goed datamodel? 1. Compleet 2. Niet-redundant 3. Implementeert business-rules 4. Data herbruikbaar voor meerdere doelen 5. Stabiel (t.o.v. bedrijfspraktijk) 6. Flexibel (uitbreidbaar) 7. Elegant 8. Helder (communicatie van concepten en regels) 9. Past in bredere data-architectuur 31/33 Rest van de cursus I. Bevraging (SQL) II. Database-applicaties 32/33 Voor volgende week Lees handboek Maak weekopdrachten Kies een onderwerp voor je database 33/33 11