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

Waar in DB ontwerp proces?

Implementation model oude stijl (hiërarchisch) D1engineering500,000 E1John E2Joe E3Jack Marydaughter Suewife D2sales200,000 E4Will Suziedaughter Tomson Marywife E5Bridget

Implementation model nieuwe stijl (relationeel) DEPARTMENT D#NAMEBUDGET D1engineering500,000 D2sales200,000 DEPENDENT EMPLOYEE E#NAME REL E#NAME BDATE D# E3Mary daughter E1John D1 E3Sue wife E2Joe D1 E4Suzie daughter E3Jack D1 E4Tom son E4Will D2 E4Mary wife E5Bridget D2

Voorbeeld relatie (fig 7.1)

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, ), (E2, Joe, ), (E3, Jack, ), (E4, Will, ), (E5, Bridget, ) } Voor ieder tupel (e, n, b) uit deze relatie moet gelden: –e  E# -domein –n  NAME -domein –b  BDATE -domein

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

Voorbeeld bij de uitgebreide(re) definitie ( {(E#, EMPNRS),(NAME, FNAMES),(BDATE, DATES)}, { {(E#, E1), (NAME, John),(BDATE, )}, {(E#, E2), (NAME, Joe),(BDATE, )}, {(E#, E3), (NAME, Jack),(BDATE, )}, {(E#, E4), (NAME, Will),(BDATE, )}, {(E#, E5), (NAME, Bridget),(BDATE, )} } )

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)

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

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 )

Primary keys en foreign keys (fig 7.7)

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)

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)

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)

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

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)

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

Voorbeeld referential integrity D#NAMEBUDGET D1engineering500,000 E#: on delete cascade D2sales200,000 / E#NAME REL E#NAME BDATE D# E3Mary daughter E1John D1 E3Sue wife E2Joe D1 E4Suzie daughter E3Jack D1 E4Tom son E4Will D2 E4Mary wife E5Bridget D2 \ D#: on delete nullify

Onjuist voorbeeld D#NAMEBUDGET D1engineering500,000 E#: on delete nullify D2sales200,000 / E#NAME REL E#NAME BDATE D# E3Mary daughter E1John D1 E3Sue wife E2Joe D1 E4Suzie daughter E3Jack D1 E4Tom son E4Will D2 E4Mary wife E5Bridget 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 !!