Databaser Design och programmering Relationsmodellen definitioner ER-modell -> relationsmodell nycklar, olika varianter Programdesign, databasdesign Databasdesign Konceptuell design Förstudie, behovsanalys Kravspecifikation Konceptuell datamodell (ER) Logisk design Implementationsmodell (Relationsschema) Fysisk design Fysisk datamodell (datatyper, index...) Applikationsdesign (Funktionell design) Transaktionsdesign Implementation Relationsmodellen Introducerades av Edward Codd 970 Mycket vanlig Stödjer kraftfulla och ändå enkla deklarativa språk Matematisk grund i relationsalgebra Funktioner Funktion = avbildning (mappning) Y=X 2 Definitionsmängden mappas till värdemängden Kan representeras med tabell Varje värde i definitionsmängden mappas på ett värde i värdemängden (men ej omvänt) Relation = generaliserad funktion varje värde i definitionsmängden kan mappas på flera värden i värdemängden Fler än två kolumner Mängden som värden dras från: domän, en för varje kolumn Formellt: En relation är en delmängd av kartesiska produkten av ett antal domäner Exempel om D ={Anna, Oskar} och D2 ={man, kvinna} så blir DxD2 = {<Anna, man>, <Anna, kvinna>, <Oskar, man>, <Oskar, kvinna>} Relationen Person kan då t.ex vara den verklighetsbaserade delmängden {<Anna, kvinna>, <Oskar, man>}
Relationer - som tabeller Relationen har attribut och är en mängd av tupler Attribut Attributvärde Student Tupel Pnr Namn kön 8022 Anna B kvinna 8500 Oskar A man Relationer som tabeller tupel = ordnad lista av attributvärden. <Oskar, 8000, 0702345678> relation = mängd av tupler (ingen ordning) antalet värden kallas tupelns grad. attributvärdena är atomära (odelbara). Relationsschema Alternativa notationer: relationsnamn (attributnamn, attributnamn2,... attributnamnn). 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 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 Universitetet: ER-diagram e-namn f-namn namn läsperiod betyg år kurskod e-post poäng namn n kurs pnr reg. lösen på n n konto student m ansv. av hålls av e-namn f-namn institution namn namn adress jobbar på anställd driver tel.nr. n n tjänsterum anst.nr projekt budget namn tidsplan
Från ER till Relationsmodell. 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) Från ER till Relationsmodell 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) Från ER till Relationsmodell 3.Markera nycklar Från ER till Relation - 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? Nycklar: Definitioner Om något eller några av attributen i en relation kan användas för att identifiera hela tupeln så är det/de attributen en nyckel En nyckel är alltså en delmängd av attributen i en relation. Supernyckel Om k är en delmängd av attributen i en relation R sådan att k kan användas för att identifiera tuplerna i R så är k en supernyckel för R.
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 relation. 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 tupel i R. Primärnyckeln markeras i relationsschemat Från ER till Relationsmodellen : 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. Från ER till Relationsmodellen : 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 Från ER till Relationsmodellen 4. Kontrollera redundans: Förenkla vid behov. Normalisera (jfr föreläsning om detta) 5. Specificera integritetsvillkoren, t.ex: att värdena för ett attribut måste vara ur attributets domän, och atomiskt. att referensattribut måste referera till en existerande tupel. semantisk integritet Universitetet: Relationer Student (pnr, e-namn, f-namn, epost, konto, lösen) Kurs (namn, kurskod, läsår, period, poäng, kursansv, institution) Anställd (f-namn, e-namn, anstnr, rum, telefon, institution) Institution (namn, adress) Projekt(institution, namn, 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 namn och lön, som arbetar på varuhusets olika avdelningar (namn och nummer), där man säljer olika varor (namn och nummer). Varje avdelning har en chef, en av de anställda. Varorna levereras av olika leverantörer (namn 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). Exempel 2: Entitet->Relationer EMPS(ENAME, SALARY) MANAGERS(ENAME) DEPTS(DNAME, DEPT#) SUPPLIERS(SNAME, SADDR) ITEMS(INAME, ITEM#) ORDERS(O#, DATE) CUSTOMERS(CNAME, CADDR, BALANCE) Exempel 2, samband->relationer 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(N:M):(SNAME, ITEM#, PRICE) INCLUDES(N:M):(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