Grunderna för relationsmodellen!

Transkript

1 Grunderna för relationsmodellen! 1 Varför behöver jag lära mig relationsmodellen?! Relationsmodellen är den totalt dominerande datamodellen i moderna databassystem Beskriver databaser som en mängd tabeller En relation är det matematiska begreppet som motsvaras av en tabell Relationer används för att beskriva innehållet i en databas och för att utföra operationer på databasen När man accesserar data i en relationsdatabas beskriver man operationerna med hjälp av utryck på relationer Det här görs med användning av relationsalgebra T.ex. för att göra sökningar av olika slag i databasen, eller för att sätta in ny information i databasen Relationsalgebra är grunden för frågespråk som SQL 2 1!

2 Exempel på en relation! attribut (eller kolumner) tupler (eller rader) instructor! relationens namn 3 En annan relation! Relationen course innehåller information om kurser Fyra attribut:, title, och credits! Varje kurs identifieras entydigt av attributet course! 4 2!

3 Relationer! En rad i en tabell kallas en tupel En tupel representerar ett samband mellan värdena i tupeln. T.ex. följande tupel-instans anger att just den här läraren har 45556, namnet Katz, finns vid institutionen Comp. Sci. och har en lön på En relation kan inte innehålla två identiska tupler, eftersom en relation är en mängd av tupler. En mängd kan per definition inte innehålla duplikat. Relationer är oordnade, dvs. det spelar ingen roll i vilken ordning tuplerna förekommer. Varje tupel kan entydigt identifieras av någon delmängd av attributen. I relationen instructor identifieras varje tupel av attributet. Attributet har ett unikt värde för varje lärare. 5 Attribut! Varje attribut i en relation har ett unikt namn. Samma namn får förekomma i flera olika relationer men det måste vara unikt inom relationen. Mängden av de tillåtna värdena för ett attribut kallas attributets domän! Domänen för attributet i relationen instructor är femsiffriga heltal, dvs. heltal mellan 0 och Domänen för attributet är mängden av alla de namn på institutioner som finns vid universitetet. Attributvärden är (vanligtvis) atomära, dvs. odelbara. Ett attribut kan anses vara atomärt om det alltid behandlas som en odelad helhet. Om det kan finnas behov av att dela upp attributvärden är det inte atomärt. En domän sägs vara atomär om alla dess medlemmar är atomära. Det speciella värdet null hör till varje domän Betecknar att värdet är okänt eller inte existerar Nollvärden orsakar komplikationer i definitionen av flera operationer. 6 3!

4 Atomära attribut! Attribut skall vara atomära, dvs. icke-delbara. Om ett attribut är atomärt eller inte beror inte bara på hurudana värden attributet kan anta, men också på hur det används. Exempel: Attributet namn är inte atomärt, för det kan delas upp i förnamn och efternamn Men om man vet att man aldrig kommer att gör det när man använder tabellen så kan man ändå anse att det är atomärt (för det används alltid atomärt). Om man behöver använda förnamn eller efternamn skilt för sig så skall man dela upp det i två olika attribut. Hur man använder sig av ett attribut har avgörande betydelse för att avgöra om det är atomärt eller inte.! namn! Mats Aspnäs Annamari Soini! förnamn! efternamn! Mats Aspnäs Annamari Soini 7 Atomära attribut (forts.)! I följande tabell är attributet tel.nr inte atomärt, eftersom det kan innehålla flera telefonnummer (hemtelefon, jobbtelefon, mobiltelefon).! namn! tel.nr! Mats Aspnäs Annamari Soini Om man bestämmer att ett attribut alltid kommer att behandlas odelat så kan det anses vara atomärt, fastän det tekniskt sett inte är det.! förnamn! efternamn! adress! Mats Aspnäs Joukahainengatan 3-5, Åbo Annamari Soini Biskopsgatan 8, Åbo Man kan dela upp attributet adress i gatunamn, nummer, postnummer och stad, men om man inte har behov att göra det så kan man behandla det som ett atomärt attribut. 8 4!

5 Relationsschema och instanser! A 1, A 2,, A n är attribut i en relation! Ett relationsschemat betecknas R = (A 1, A 2,, A n ) där R är relationens namn Exempel: instructor = (, name,, salary ) Ett relationsschema beskriver strukturen på en tabell i en databas I schemadeklarationen anger vi relationens namn (R) och listar namnen på de attribut som ingår i den (A 1, A 2,, A n ) Matematiskt uttryckt: Om vi har mängderna D 1, D 2,. D n så är en relation en delmängd av D 1 x D 2 x x D n D 1 x D 2 x x D n är den kartesiska produkten av mängderna D 1, D 2,. D n Består av alla kombinationer som kan bildas av elementen i mängderna En relation är en mängd av n-tupler (a 1, a 2,, a n ) där element a i hör till mängden D i (dvs. a i D i )! Ett element t i en relation r är en tupel, som representeras av en rad i en tabell! De nuvarande värdena (relationsinstansen) av en relation ges i en tabell en instans av en relation anger vilka värden vi just för tillfället har i en tabell 9 Relationsschema! A 1, A 2,, A n är attribut R = (A 1, A 2,, A n ) är ett relationsschema! Exempel: Customer_schema = (customer_name, customer_street, customer_city) Scheman brukar ges namn som börjar med en stor bokstav r(r) betecknar en relation (dvs. tabell) med namnet r som har relationsschemat R Exempel: customer (Customer_schema)!!Relationer brukar ges namn som består av små bokstäver Jämför med deklaration av datatyper och variabler i ett programmeringsspråk Schemadeklarationer motsvarar typdeklarationer Relationer motsvarar variabler som har en viss typ och som kan ges ett visst värde (i en instans av relationen). 10 5!

6 Databas! En databas består av ett antal relationer (dvs. ett antal tabeller) Information om en organisation eller ett företag delas upp i delar, där varje relation lagrar en del av informationen. Till exempel i vår exempeldatabas över ett universitet har vi bl.a.: instructor: en tabell som lagrar information om lärare student: en tabell som lagrar information om studenter advisor: en tabell som lagrar information om vilken lärare som är handledare för en student Att lagra all information i en enda stor relation som t.ex.!!univ (instructor-, name,, salary, student_id, ) leder till upprepning av information, t.ex. om två studenter har samma handledare behov av nollvärden, t.ex. för att lagra information om en student som inte ännu har någon handledare Normaliseringsteorin presenterar hur man designar relationsscheman. 11 Schema för universitetsdatabasen! Universitetsdatabasen har följande scheman classroom(, room_number, capacity)! department(,, budget)! course(, title,, credits)! instructor(, name,, salary)! section(,,,,, room_nr, time_slot_id)! teaches(,,,, )! student(, name,, tot_credit)! takes(,,,,, grade)! advisor(s_, i_)! time_slot(time_slot_id, day, start_time, end_time)! prereq(, prereq_id)! 12 6!

7 Relationen prereq! Relationen prereq lagrar information om förkunskapskrav för en kurs Schema: prereq (, prereq_id) tupeln (BIO-301, BIO-101) anger att kursen BIO-301 Genetics kräver som förkunskap kursen BIO-101 Intro. to Biology prereq! course! 13 Relationen department! Relationen department anger för varje institution i vilken byggnad den finns, samt dess budget Schema: department (,, budget) department! instructor! 14 7!

8 Relationen section! Relationen section lagrar information om när de olika kurserna föreläses, och var section (,,,,, room_number, time_slot_id) section! 15 Relationen teaches! Relationen teaches lagrar information om vem som föreläser de olika kurserna teaches (,,,, ) teaches! 16 8!

9 Schemadiagram för universitetsdatabasen! section room_no time_slot_id takes grade time_slot time_slot_id day start_time end_time course title credits student name tot_cred department budget advisor s_id i_id classroom room_no capacity teaches prereq prereq_id instructor name salary 17 Nycklar! Tuplerna i en relation måste kunna skiljas från varandra det får inte finnas två identiska tupler i en relation med andra ord: det får inte finnas två identiska rader i en tabell Det måste finnas en mängd av attribut i en tupel som har sådana värden att de unikt identifierar tupeln ingen annan tupel i den samma relationen kan ha exakt samma värden på de här attributen De attribut som kan användas för att unikt identifiera tupler kallas för nycklar! En nyckel består av ett eller flera av relationens attribut I relationsscheman markeras de attribut som bildar en nyckel med understreckning Exempel: instructor(, name,, salary) course(, title,, credits)! department(,, budget)! classroom(, room_number, capacity)! 18 9!

10 Supernyckel! Låt K R, dvs. K är en delmängd av relationsschemat R K är en mängd av attribut i R, dvs. ett eller flera av attributen i relationsschemat Vi kallar K en supernyckel (superkey) av R om värdet på K är tillräckligt för att identifiera en unik tupel av varje möjlig relation r(r) med varje möjlig relation r avses en godtycklig relation r som kunde existera i den verksamhet som vi modellerar i databasen det skall inte kunna existera två tupler i tabellen som har identiska värden på attributen i K Exempel: både {} och {, name} är supernycklar till relationen instructor! Supernycklar kan användas för att unikt identifiera en tupel i en relation(dvs. de identifierar en unik rad i en tabell) Till exempel är attributet en supernyckel i relationen course, och är en supernyckel i relationen teacher 19 Kandidatnyckel! K är en kandidatnyckel om K är en minimal supernyckel! Att den är minimal betyder att ingen delmängd av K kan användas för att unikt identifiera en tupel i R. Med andra ord: om vi lämnar bort något av attributen i K så kan den inte mera unikt identifiera någon tupel i en tabell. Exempel: relationen classroom(, room_number, capacity) {, room_number} är en kandidatnyckel för tabellen classroom, eftersom det är en supernyckel och ingen delmängd av det är en supernyckel.! room_number! capacity! ICT A ICT B ASA B !

11 Primärnyckel! En primärnyckel är en kandidatnyckel som har valts att vara det främsta sättet att identifiera tupler i en relation. Den som designar databasen väljer ut en av kandidatnycklarna till att vara primärnyckel. Till kandidatnyckeln bör välja ett attribut vars värde aldrig, eller mycket sällan, ändras. Attribut som väljs till primärnyckel skall vara stabila (dvs. inte ändra) Ofta används id-nummer som primärnyckel (som t.ex. studentnummer, kursnummer, kundnummer, etc.) T.ex. adress är unik, men kan ändra. Personnamn (och andra namn på entiteter) är vanligtvis inte unika, så de lämpar sig inte som kandidatnyckel Man brukar lista de attribut som är primärnyckel först i ett relationsschema, och skriva dem understreckade. 21 Främmande nycklar! Ett relationsschema kan ha attribut som anger primärnycklar i en annan relation. Dessa attribut kallas främmande nycklar (foreign keys). T.ex. attributen och i tabellen takes är främmande nycklar, som identifierar tupler i relationerna student respektive course. Endast värden som förekommer i primärnyckelattributet i den refererade relationen kan förekomma i det attribut som är främmande nyckel i den refererande relationen.! section room_no time_slot_id takes grade time_slot time_slot_id day start_time end_time course title credits student name tot_cred department budget advisor s_id i_id classroom room_no capacity teaches prereq prereq_id instructor name salary 22 11!