Databaser - Design och programmering. Databasdesign. Funktioner. Relationsmodellen. Relationsmodellen. Funktion = avbildning (mappning) Y=X 2

Transkript

1 Databaser Desig och programmerig Relatiosmodelle Databasdesig Förstudie, behovsaalys defiitioer ER-modell -> relatiosmodell ycklar Relatiosmodelle Itroducerades av Edward Codd 1970 Mycket valig Stödjer kraftfulla och ädå ekla deklarativa språk Matematisk grud i relatiosalgebra Fuktioer Fuktio = avbildig (mappig) Y=X 2 Defiitiosmägde mappas till värdemägde Ka represeteras med tabell Varje värde i defiitiosmägde mappas på ett värde i värdemägde (me ej omvät)

2 Relatio = geeraliserad fuktio varje värde i defiitiosmägde ka mappas på flera värde i värdemägde Fler ä två kolumer Mägde som värde dras frå: domä, e för varje kolum Formellt: E relatio är e delmägd av kartesiska produkte av ett atal domäer Exempel om D1 ={Aa, Oskar} och D2 ={ma, kvia} så blir D1xD2 = {<Aa, ma>, <Aa, kvia>, <Oskar, ma>, <Oskar, kvia>} Relatioe R ka då t.ex vara de verklighetsbaserade delmägde {<Aa, kvia>, <Oskar, ma>} Relatioer - som tabeller Relatioe har attribut och är e mägd av tupler Attribut Attributvärde Studet Tupel Pr Nam epost Aa B abe Oskar A oska Relatioer som tabeller tupel = ordad lista av attributvärde. <Oskar, , > atalet värde kallas tupels grad. attributvärdea är atomära (odelbara).

3 Relatiosschema Alterativa otatioer: relatiosam (attributam1, attributam2,... attributamn). exempel: Perso (Nam, Adress, Telefo, Födelsedatum, Kö) Perso Nam Adress Föddat Kö Tel Perso Nam Adress Föddat Kö Tel Flera relatioer E databas består av flera relatioer med koppligar mella sig. Ex: studeter och kurser Studet Nam Adress Föddat epost Kurs Kurs Kurskod Nam Examiator Istitutio Referesattribut pr koto e-am tel.r. Uiversitetet: ER-diagram e-am am am f-am tjästerum f-am studet aställd e-post 1 ast.r löse m reg. på hålls av jobbar på betyg am kurskod 1 am läsperiod kurs asv. av 1 istitutio 1 driver projekt år poäg adress budget am tidspla

4 Frå ER till Relatiosmodell 1. För varje etitetstyp: defiiera motsvarade relatiosschema. Varje tupel i relatioe kommer att represetera e etitetsistas Valiga attribut blir attribut (kolumer) (1) Sammasatta attribut represeteras av delara (8) Multipelattribut blir e ege relatio med yckel till etitetstype och attributet ekelt (9) Svag etitetstyp får som extra attribut yckel till de ägade etitetstype (7) Frå ER till Relatiosmodell 2.För varje sambadstyp: 1:N sambad; lägg i 1-etitetes yckel i relatioe för N-etitete (2) 1:1 sambad; lägg i yckel till de ea etitete i de adras relatio (3) N:M sambad blir e ege relatio beståede av ycklara till båda etitetera (4) Flervägssambad blir e ege relatio som N:M (5) Ägadesambad igoreras Attribut på sambad läggs i i respektive relatio (6) Frå ER till Relatiosmodell 3.Markera ycklar Relatiosmodelle - ycklar ER-modelle har vissa ycklar (yckelattribut på etitetstyper) E viss tupel i relatiosmodelle represeterar e viss etitetsistas i ER-modelle. Relatioer som ej är baserade på etitetstyper vad har de för ycklar? Ka det fias alterativ?

5 Nycklar: Defiitioer Om ågot eller ågra av attribute i e relatio ka avädas för att idetifiera hela tupel så är det/de attribute e yckel E yckel är alltså e delmägd av attribute i e relatio. Superyckel Om k är e delmägd av attribute i e relatio R såda att k ka avädas för att idetifiera tuplera i R så är k e superyckel för R. Kadidatyckel = miimal superyckel E superyckel k är miimal om vi ite ka ta bort ågot attribut ur k så att de ya k, k', fortfarade är e superyckel. Geerellt fis det flera kadidatycklar för e relatiostabell De attribut som igår i ågo kadidatyckel kallas primattribut Primäryckel De kadidatyckel som väljs av databasdesiger som huvudyckel för e relatiostabell R kallas primäryckel eller yckel till R. Aväds i adra relatioer för att referera till e viss tupel i R. Primäryckel markeras i relatiosschemat

6 Frå ER till Relatiosmodelle : Nycklar Relatioer baserade på: valig etitetstyp svag etitetstyp multipelattribut Får som primäryckel: yckel ur ERdiagrammet. yckel till de ägade etitestype plus de partiella yckel. yckel till etitetstype plus attributet självt. Frå ER till Relatiosmodelle : ycklar, forts Relatioer baserade på: sambadstyp, M:N flervägssambadstyp Får som primäryckel: ycklara ur de två etitetstypera ycklara till de sammabuda etitetstyper som ka igå i flera sambadsistaser Frå ER till Relatiosmodelle 4. Kotrollera redudas: Förekla vid behov. Normalisera (jfr föreläsig om detta) 5. Specificera itegritetsvillkore, t.ex: att värdea för ett attribut måste vara ur attributets domä, och atomiskt. att referesattribut måste referera till e existerade tupel. sematisk itegritet Uiversitetet: Relatioer Studet (pr, e-am, f-am, epost, koto, löse) Kurs (am, kurskod, läsår, period, poäg, kursasv, istitutio) Aställd (f-am, e-am, astr, rum, telefo, istitutio) Istitutio (am, adress) Projekt(istitutio, am, tidspla, budget) RegistreradPå (studetpr, kursr, läsår, betyg)

7 Kokbok Exempel 2 1. Etitetstyper -> relatioer (kom ihåg alla attribut) 2. Sambadstyper i i relatioer eller blir ega relatioer 3. Nycklar 4. Redudaskotroll, ormaliserig 5.Itegritetsvillkor Ett större varuhusföretag har aställda, med am och lö, som arbetar på varuhusets olika avdeligar (am och ummer), där ma säljer olika varor (am och ummer). Varje avdelig har e chef, e av de aställda. Varora levereras av olika leveratörer (am och adress), och flera leveratör ka leverera samma varor, me till olika priser. Exempel 2, forts Exempel 2 ER-diagram Varuhuset har hemkörigsservice. Kuder som har koto hos varuhuset och amält e adress för leveraser ka beställa varor och få dem levererade hem. Varje såda beställig har ett orderummer och ett orderdatum, utöver lista av igåede varor (aturligtvis ka ma beställa mer ä e av varje vara vid ett visst tillfälle).

8 Exempel 2: Relatioer EMPS(ENAME, SALARY) MANAGERS(ENAME) DEPTS(DNAME, DEPT#) SUPPLIERS(SNAME, SADDR) ITEMS(INAME, ITEM#) ORDERS(O#, DATE) CUSTOMERS(CNAME, CADDR, BALANCE) Exempel 2, forts WORKS-IN (N:1) DEPT# läggs i i EMPS MANAGES (1:1) ENAME läggs i i DEPTS CARRIES (1:N) DEPT# läggs i i ITEMS SUPPLIES(SNAME, ITEM#, PRICE) INCLUDES(O#, ITEM#, QUANTITY) PLACED-BY (N:1) CNAME läggs i i ORDERS (IS-A behövs ite är MANAGERS fis) Exempel 2, ycklar 1. EMPS(ENAME, SALARY, DEPT#) 2. MANAGERS(ENAME) 3. DEPTS(DNAME, DEPT#, ENAME) 4. SUPPLIERS(SNAME, SADDR) 5. ITEMS(INAME, ITEM#, DEPT#) 6. ORDERS(O#, DATE, CNAME) 7. CUSTOMERS(CNAME, CADDR, BALANCE) 8. SUPPLIES(SNAME, ITEM#, PRICE) 9. INCLUDES(O#, ITEM#, QUANTITY) Exempel 2, forts: Kotrollera redudas och itegritetsvillkor: EMPS(ENAME, SALARY, DEPT#) MANAGERS(ENAME) DEPT(DNAME,DEPT#, ENAME) E relatio med bara ett attribut? Är ite MANAGERS e delmägd av EMPS? Me om vi kodar MANAGERS som attribut i EMPS: sematiskt itegritetsvillkor behövs