Grunderna för relationsmodellen!

(1)

©Silberschatz, Korth and Sudarshan!

Database System Concepts!

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

(2)

Exempel på en relation!

tupler"

(eller rader)"

attribut  (eller kolumner)"

instructor!

3

relationens"

namn"

En annan relation!

■  Relationen course innehåller information om kurser "

●  Fyra attribut: course_id, title, dept_name och credits !

●  Varje kurs identifieras entydigt av attributet course_id "

course!

4

(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 ID 45556, namnet Katz, finns vid institutionen Comp. Sci. och har en lön på 75000. 

"

■  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 ID."

●  Attributet ID 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 ID i relationen instructor är femsiffriga heltal, dvs. heltal mellan 0 och 99999."

●  Domänen för attributet dept_name ä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." ₆

(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."

7 ID! namn!

12345" Mats Aspnäs"

12356" Annamari Soini"

ID! förnamn! efternamn!

12345" Mats" Aspnäs"

12356" Annamari" Soini"

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). 

"

■  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. 

"

●  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

ID! namn! tel.nr!

12345" Mats Aspnäs" 02-2154118"

046-9207983"

12356" Annamari Soini" 02-2154672"

046-9207500"

ID! förnamn! efternamn! adress!

12345" Mats" Aspnäs" Joukahainengatan 3-5, 20520 Åbo"

12356" Annamari" Soini" Biskopsgatan 8, 20500 Åbo"

(5)

Relationsschema och instanser!

■  A₁, A₂, …, A_n är attribut i en relation!

■  Ett relationsschemat betecknas R = (A₁, A₂, …, A_n ) där R är relationens namn"

●  Exempel: instructor = (ID, name, dept_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₁, A₂, …, A_n ) 

"

■  Matematiskt uttryckt:"

●  Om vi har mängderna D₁, D₂, …. D_n så är en relation en delmängd av 

" D₁ x D₂ x … x D_n"

●  D₁ x D₂ x … x D_n är den kartesiska produkten av mängderna D₁, D₂, …. 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₁, a₂, …, a_n) där element a_i hör till mängden D_i   (dvs. a_i ∈ Di )!

■  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" ₉

Relationsschema!

■  A₁, A₂, …, A_n är attribut"

■  R = (A₁, A₂, …, 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

(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-ID, name, dept_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(building, room_number, capacity)!

●  department(dept_name, building, budget)!

●  course(course_id, title, dept_name, credits)!

●  instructor(ID, name, dept_name, salary)!

●  section(course_id, sec_id, semester, year, building, room_nr, time_slot_id)!

●  teaches(ID, course_id, sec_id, semester, year)!

●  student(ID, name, dept_name, tot_credit)!

●  takes(ID, course_id, sec_id, semester, year, grade)!

●  advisor(s_ID, i_ID)!

●  time_slot(time_slot_id, day, start_time, end_time)!

●  prereq(course_id, prereq_id)!

12

(7)

Relationen prereq!

■  Relationen prereq lagrar information om förkunskapskrav för en kurs"

●  Schema: prereq (course_id, prereq_id) "

●  tupeln (BIO-301, BIO-101) anger att kursen BIO-301 Genetics kräver som förkunskap kursen BIO-101 Intro. to Biology "

13 prereq!

course!

Relationen department!

■  Relationen department anger för varje institution i vilken byggnad den finns, samt dess budget"

●  Schema: department (dept_name, building, budget) "

14 department!

instructor!

(8)

Relationen section!

■  Relationen section lagrar information om när de olika kurserna föreläses, och var"

■  section (course_id, sec_id, semester, year, building, room_number, time_slot_id)"

section! 15

Relationen teaches!

■  Relationen teaches lagrar information om vem som föreläser de olika kurserna"

■  teaches (ID, course_id, sec_id, semester, year)"

teaches! 16

(9)

Schemadiagram för universitetsdatabasen!

17 IDcourse_id

sec_id semester yeargrade

IDname dept_name tot_cred

building room_no capacity

s_idi_id

IDcourse_id sec_id semester year

takes

section

classroom

teaches

prereq course_id prereq_id course_id title dept_name credits

course

student

dept_name building budget department

instructor

IDname dept_name salary

advisor time_slot

time_slot_id daystart_time end_time course_id

sec_id semester yearbuilding room_no time_slot_id

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(ID, name, dept_name, salary)"

●  course(course_id, title, dept_name, credits)!

●  department(dept_name, building, budget)!

●  classroom(building, room_number, capacity)! ¹⁸

(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 {ID} och {ID, 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 course_id en supernyckel i relationen course, och  ID ä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(building, room_number, capacity)"

●  {building, room_number} är en kandidatnyckel för tabellen classroom, eftersom det är en supernyckel och ingen delmängd av det är en supernyckel."

20 building! room_number! capacity!

ICT" A3058" 60"

ICT" B3039" 30"

ASA" B311" 50"

(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. e-mail 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 ID och course_id 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.!

22

IDcourse_id sec_id semester yeargrade

IDname dept_name tot_cred

building room_no capacity

s_idi_id

IDcourse_id sec_id semester year

takes

section

classroom

teaches

prereq course_id prereq_id course_id title dept_name credits

course

student

dept_name building budget department

instructor IDname dept_name salary

advisor time_slot

time_slot_id daystart_time end_time course_id

sec_id semester yearbuilding room_no time_slot_id