Databases I (H. 7: 1-3) Het Relationele Model Wiebren de Jonge Vrije Universiteit, Amsterdam versie 2003.

Presentatie over: "Databases I (H. 7: 1-3) Het Relationele Model Wiebren de Jonge Vrije Universiteit, Amsterdam versie 2003."— Transcript van de presentatie:

1 Databases I (H. 7: 1-3) Het Relationele Model Wiebren de Jonge Vrije Universiteit, Amsterdam versie 2003

2 Waar in DB ontwerp proces?

3 Implementation model oude stijl (hiërarchisch) D1engineering500,000 E1John28-08-1964 E2Joe04-04-1968 E3Jack03-09-1969 Marydaughter Suewife D2sales200,000 E4Will21-03-1971 Suziedaughter Tomson Marywife E5Bridget22-01-1972

4 Implementation model nieuwe stijl (relationeel) DEPARTMENT D#NAMEBUDGET D1engineering500,000 D2sales200,000 DEPENDENT EMPLOYEE E#NAME REL E#NAME BDATE D# E3Mary daughter E1John 28-08-1964 D1 E3Sue wife E2Joe 04-04-1968 D1 E4Suzie daughter E3Jack 03-09-1969 D1 E4Tom son E4Will 21-03-1971 D2 E4Mary wife E5Bridget 22-01-1972 D2

5 Voorbeeld relatie (fig 7.1)

6 Relatie (een eerste definitie) u Relatie: een deelverzameling van een Cartesisch produkt D 1  D 2  …  D n waarbij D i (i = 1…n) de domeinen zijn Het natuurlijke getal n heet de graad (degree / arity) van de relatie {(E1, John, 28-08-1964), (E2, Joe, 04-04-1968), (E3, Jack, 03-09-1969), (E4, Will, 21-03-1971), (E5, Bridget, 22-01-1972) } Voor ieder tupel (e, n, b) uit deze relatie moet gelden: –e  E# -domein –n  NAME -domein –b  BDATE -domein

7 Relatie: een uitgebreide(re) definitie u een relatie is: (1) een verzameling geordende paren (attribuutnaam, domein) waarbij elke attribuutnaam uniek is (=heading), èn (2) een verzameling tupels (=body), waarbij elk tupel een verzameling is van geordende paren (attribuutnaam, waarde) z.d.d.: a) elke attribuutnaam niet meer dan één keer voorkomt in laatstgenoemde verzameling van paren, èn moet voorkomen in de heading, i.e. de verzameling (attribuutnaam, domein)-paren van de relatie, èn b) waarbij de waarde moet komen uit het bij de attribuutnaam vermelde domein

8 Voorbeeld bij de uitgebreide(re) definitie ( {(E#, EMPNRS),(NAME, FNAMES),(BDATE, DATES)}, { {(E#, E1), (NAME, John),(BDATE, 28-08-1964)}, {(E#, E2), (NAME, Joe),(BDATE, 04-04-1968)}, {(E#, E3), (NAME, Jack),(BDATE, 03-09-1969)}, {(E#, E4), (NAME, Will),(BDATE, 21-03-1971)}, {(E#, E5), (NAME, Bridget),(BDATE, 22-01-1972)} } )

9 Opmerking m.b.t. attributen u In het Relationele Model mogen attributen: –evt. wel composite zijn, –maar niet multi-valued !! u Composite was oorspronkelijk niet toegestaan; echter, wel toestaan kan best en is zelfs beter !! u Multi-valued niet toestaan, want geeft wel serieuze problemen u Elke relatie is dus per definitie in 1NF (= first Normal Form) N.B. Als verzamelingen wel toegestaan als attribuutwaarden, dan spreken we over NF 2 (= Non First Normal Form)

10 Enkele begrippen u intensie v/e relatie of DB: –geeft aan welke toestanden (waarden) en toestandsovergangen allemaal toegestaan/mogelijk zijn voor die relatie resp. DB u extensie: –een extensie:één mogelijke/toegestane inhoud –de extensie:de huidige inhoud u relatie-schema:beschrijving van de intensie v/e relatie u DB-schema:beschrijving van de intensie v/e DB

11 Keys / sleutels u superkey:verzameling attributen die ieder tupel van een relatie altijd (i.e. in elke extensie) uniek identificeert Dus geldt:  t 1,t 2  R: (t 1  t 2  t 1 [SK]  t 2 [SK]) u (candidate) key:minimale superkey primary key:één specifieke candidate key, die door de DB ontwerper is benoemd tot primary key alternate key:elke candidate key die géén primary key is u foreign key:attribuut of combinatie van attributen (verwijssleutel)die wordt gebruikt om vanuit een tupel naar een ander tupel te verwijzen (in dezelfde of in een andere relatie) Voorbeeld: Woning ( plaats 1, straat 1, huisnr 1,2, postcode 2, prijs, naam_makelaar ) Makelaar ( naam 1, KvKnummer 2, telefoon 3 )

12 Primary keys en foreign keys (fig 7.7)

13 Enkele constraints u entity integrity: geen enkel tupel mag de waarde null hebben in een attribuut dat tot de primary key behoort (unicity + no null in PK) u key constraints: betreffen (mate van) uniciteit; Primary Key:uniek + no nulls(altijd) Alternate Keys:nulls toegestaan(meestal) u referential integrity: de aanwezige waarden van foreign keys moeten: –òfwel: als sleutelwaarde voorkomen in de relatie waar de FK naar verwijst, i.e. verwijzen naar een aanwezig/bestaand tupel –òfwel: geheel null zijn (d.w.z. ieder attribuut van die FK bevat null)

14 Problemen overlapping foreign keys... u Voorbeeld: R(A, B, C, D, E) {B, C} FK naar S {C, D, E} FK naar T S(B, C, F) T(C, D, E, G) u Vanwege de referential integrity geldt in dit v.b.: geen verwijzing naar tupel van S d.e.s.d.a. geen verwijzing naar tupel van T (want null-waarden mogen uitsluitend als de gehele FK null is)

15 Relatie schema Een relatie-schema beschrijft (idealerwijs): u de naam v/d relatie u de namen v/d attributen u voor elk attribuut de naam van het bijbehorende domein (n.l. liefst beschreven in aparte domein schema’s) u alle intra-relationele constraints –key constraints –overige constraints (b.v.: als tupel.leeftijd > 23 dan tupel.salaris >= minimumloon) u wat er moet gebeuren indien constraint(s) geschonden worden (of geschonden dreigen te worden)

16 Database schema Een (conceptueel) DB-schema beschrijft (idealerwijs): u de naam v/d database u alle (sub)domeinen (het omvat dus alle (sub)domeinschema’s) u alle relaties (het omvat dus alle relatieschema’s) u alle view definities u alle inter-relationele constraints u wat er moet gebeuren als inter-relationele constraints geschonden (dreigen te) worden

17 Tupel-operaties die DB wijzigen u INSERT tupel –domain constraints –key constraints –entity integrity –referential integrity(als toegevoegde tupel een FK bevat) u DELETE tupel –referential integrity (als andere tupels verwijzen naar het tupel dat nu wordt verwijderd!) u MODIFY tupel, o.a.: –domain constraints –referential integrity(als in tupel een FK wordt gewijzigd) –key constraints(als modify van key attr. in PK of AK) –entity integrity(als modify van PK is toegestaan) Let op: het wijzigen van attributen v.d. PK wordt soms/vaak gezien en/of behandeld als een DELETE + INSERT (want “identiteit” van tupel wijzigt)

18 Referential integrity (on delete / modify) u restricted –on delete: delete van verwezen tupel mag niet –on modify: modify van PK van verwezen tupel mag niet u nullify –on delete: bij delete van verwezen tupel moet in alle (met deze FK) verwijzende tupels de FK geheel null gemaakt worden –on modify: bij modify van PK van verwezen tupel moet in alle (met deze FK) verwijzende tupels de FK geheel null worden u cascade –on delete: bij delete van verwezen tupel moeten alle tupels die (met deze FK) naar dat tupel wijzen, ook verwijderd worden –on modify: bij modify van PK van verwezen tupel moet in alle (met deze FK) verwijzende tupels de FK overeenkomstig aangepast worden

19 Voorbeeld referential integrity D#NAMEBUDGET D1engineering500,000 E#: on delete cascade D2sales200,000 / E#NAME REL E#NAME BDATE D# E3Mary daughter E1John 28-08-1964 D1 E3Sue wife E2Joe 04-04-1968 D1 E4Suzie daughter E3Jack 03-09-1969 D1 E4Tom son E4Will 21-03-1971 D2 E4Mary wife E5Bridget 22-01-1972 D2 \ D#: on delete nullify

20 Onjuist voorbeeld D#NAMEBUDGET D1engineering500,000 E#: on delete nullify D2sales200,000 / E#NAME REL E#NAME BDATE D# E3Mary daughter E1John 28-08-1964 D1 E3Sue wife E2Joe 04-04-1968 D1 E4Suzie daughter E3Jack 03-09-1969 D1 E4Tom son E4Will 21-03-1971 D2 E4Mary wife E5Bridget 22-01-1972 D2 \ D#: on delete cascade Omdat in DEPENDENT de FK (i.e. E#) behoort tot de PK, moet/kun je bij die FK zeker geen “on delete nullify” of “on modify nullify” specificeren !!