Databaser - Design och programmering. Relationsmodellen. Relationer - som tabeller. Relationer som tabeller. Alternativa notationer: Relationsschema

Transkript

1 Databaser Design och programmering Relationsmodellen definitioner ER-modell -> relationsmodell nycklar, olika varianter Relationsmodellen Introducerades av Edward Codd 970 Mycket vanlig Stödjer kraftfulla och ändå enkla deklarativa språk Matematisk grund i relationsalgebra Relationer - som tabeller Relationen har attribut och är en mängd av tupler Kolumn (Attribut) Attributvärde Student Rad (Tupel) Pnr Namn epost 8022 Anna B annbe 8500 Oskar A oskan Relationer som tabeller Tabellen består av en mängd rader Rader får ej ha dubletter Raderna betraktas som osorterade attributvärdena är atomära (odelbara). Relationsschema Alternativa notationer: relations (attribut, attribut2,... attributn). exempel: Person (Namn, Adress, Telefon, Födelsedatum, Kön) Person Namn Adress Föddat Kön Tel Person Namn Adress Föddat Kön Tel

2 Flera relationer En databas består av flera relationer med kopplingar mellan sig. Ex: studenter och kurser Student Namn Adress Föddat epost Kurs Kurs Kurskod Namn Examinator Institution Referensattribut Referensintegritet Universitetet: ER-diagram e- f- läsperiod betyg år kurskod e-post poäng n kurs pnr reg. lösen på n n student m ansv. av hålls av e- f- institution adress jobbar på anställd driver tel.nr. n n tjänsterum anst.nr projekt budget tidsplan. För varje entitetstyp: definiera motsvarande relationsschema. Varje tupel i relationen kommer att representera en entitetsinstans Vanliga attribut blir attribut (kolumner) () Sammansatta attribut representeras av delarna (8) Multipelattribut blir en egen relation med nyckeln till entitetstypen och attributet enkelt (9) Svag entitetstyp får som extra attribut nyckeln till den ägande entitetstypen (7) 2.För varje sambandstyp: :N samband; lägg in -entitetens nyckel i relationen för N-entiteten (2) : samband; lägg in nyckeln till den ena entiteten i den andras relation (3) N:M samband blir en egen relation bestående av nycklarna till båda entiteterna (4) Flervägssamband blir en egen relation som N:M (5) Ägandesamband ignoreras Attribut på samband läggs in i respektive relation (6) 3.Markera nycklar Relationsmodellen - nycklar ER-modellen har vissa nycklar (nyckelattribut på entitetstyper) En viss tupel i relationsmodellen representerar en viss entitetsinstans i ER-modellen. Relationer som ej är baserade på entitetstyper vad har de för nycklar? Kan det finnas alternativ?

3 Nycklar: Definitioner Om något eller några av attributen i en relation kan användas för att identifiera hela tupeln (raden) så är det/de attributen en nyckel Supernyckel Om k är en delmängd av attributen i en relation R sådan att k kan användas för att identifiera raderna i R så är k en supernyckel för R. En nyckel är alltså en delmängd av attributen i en relation. Kandidatnyckel = minimal supernyckel En supernyckel k är minimal om vi inte kan ta bort något attribut ur k så att den nya k, k', fortfarande är en supernyckel. Generellt finns det flera kandidatnycklar för en relationstabell De attribut som ingår i någon kandidatnyckel kallas primattribut Primärnyckel Den kandidatnyckel som väljs av databasdesignern som huvudnyckel för en relationstabell R kallas primärnyckel eller nyckeln till R. Används i andra relationer för att referera till en viss rad i R. Primärnyckeln markeras i relationsschemat med understrykning. en : Nycklar Relationer baserade på: vanlig entitetstyp svag entitetstyp multipelattribut Får som primärnyckel: nyckeln ur ERdiagrammet. nyckeln till den ägande entitestypen plus den partiella nyckeln. nyckeln till entitetstypen plus attributet självt. en : nycklar, forts Relationer baserade på: sambandstyp, M:N flervägssambandstyp Får som primärnyckel: nycklarna ur de två entitetstyperna nycklarna till de sammanbundna entitetstyper som kan ingå i flera sambandsinstanser

4 en 4. Kontrollera redundans: Förenkla vid behov. Normalisera (jfr föreläsning om detta) 5. Specificera integritetsvillkoren, t.ex: att referensattribut måste referera till en existerande tupel. semantisk integritet Universitetet: Relationer Student (pnr, e-, f-, epost, konto, lösen) Kurs (, kurskod, läsår, period, poäng, kursansv, institution) Anställd (f-, e-, anstnr, rum, institution) Telefon (anstnr, telnr) Institution (, adress) Projekt(institution,, tidsplan, budget) RegistreradPå (studentpnr, kursnr, läsår, betyg) Kokbok Exempel 2. Entitetstyper -> relationer (kom ihåg alla attribut) 2. Sambandstyper in i relationer eller blir egna relationer 3. Nycklar 4. Redundanskontroll, normalisering 5.Integritetsvillkor Ett större varuhusföretag har anställda, med och lön, som arbetar på varuhusets olika avdelningar ( och nummer), där man säljer olika varor ( och nummer). Varje avdelning har en chef, en av de anställda. Varorna levereras av olika leverantörer ( och adress), och flera leverantör kan leverera samma varor, men till olika priser. Exempel 2, forts Exempel 2 ER-diagram Varuhuset har hemkörningsservice. Kunder som har konto hos varuhuset och anmält en adress för leveranser kan beställa varor och få dem levererade hem. Varje sådan beställning har ett ordernummer och ett orderdatum, utöver listan av ingående varor (naturligtvis kan man beställa mer än en av varje vara vid ett visst tillfälle).

5 Exempel 2: Relationer 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:) DEPT# läggs in i EMPS MANAGES (:) ENAME läggs in i DEPTS CARRIES (:N) DEPT# läggs in i ITEMS SUPPLIES(SNAME, ITEM#, PRICE) INCLUDES(O#, ITEM#, QUANTITY) PLACED-BY (N:) CNAME läggs in i ORDERS (IS-A behövs inte när MANAGERS finns) Exempel 2, nycklar. 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: Kontrollera redundans och integritetsvillkor: EMPS(ENAME, SALARY, DEPT#) MANAGERS(ENAME) DEPT(DNAME,DEPT#, ENAME) En relation med bara ett attribut? Är inte MANAGERS en delmängd av EMPS? Men om vi kodar MANAGERS som attribut i EMPS: semantiskt integritetsvillkor behövs