Informationssystem och Databasteknik Föreläsning 4 Relationsmodellen Från konceptuell modell till relationsdatabasschema Inför projektarbetet: - sammansmältning av flera överlappande modeller av samma typ 1
HomonymsExEx Scaledifere HomonymsExEx Scaledifere Skillnader i terminologi Synonymer, tex: köpa, inhandla Homonymer, tex: artikel Skillnader i skala eller måttenhet, tex: kilo, gram, Euro, Dollar FENOMEN Namn: Textsträng 1..1 MÄTETAL Precision: Heltal 1..1 Kvantitet: Float 1..1 ENHETSTYP Namn: Textsträng 1..1 2
Skillnader i struktur Kvinna gift_med Man Person Kön: Boolean 1..1 Kvinna Man Person maka Äktenskap make Man Kvinna Skillnader i abstraktionsnivå Template-Copy strukturer (power types) Vissa objekt kan ses som mallar för andra objekt, kopior. En mall beskriver de generella dragen hos kopiorna som i sin tur kan innehålla ett antal idividuella drag. Mallar är ofta abstrakta objekt medan kopior är konkreta objekt. Kopior kan ses som materialiseringar av mallar. BOK är ett typiskt exempel på en mall, boken som ett litterärt verk. BOK:en har en titel, en författare osv. De individuella kopiorna är de fysiska exemplaren av det litterära verket som kan ha egenskaper som vikt, antal sidor etc. Observera att KOPIA inte utgör en delmängd av BOK. Template- Copies är inte samma sak som supertyp-subtyp. BOK titel Författare: String 1..1 UNIK Titel: String 1..1 1 0..* KOPIA av_typ Vikt: String 1..1 Antal_sidor 1..1 3
Vad är ett databashanteringssystem? En mängd program som tillåter användaren att skapa och underhålla databaser DATABASSYSTEM Användare/Programmerare Applikationsprogram/Frågor DBMS Program för att hantera frågor/program Program för att hantera lagrade data Lagrad databasdefinition (metadata) Lagrad databas 4
Tabell 2 Tabell 1 Namn Adress Telefon Lisa Byvägen 3 11111 Olle Solgränd 2 22222 Pelle Solgränd 4 23456 En relationsdatabas är en databas som uppfattas av användaren som en samling tabeller - oberoende av hur datamängden fysiskt är lagrad. Domän t.ex. Domänen för attributen BUDGET är Integer större än noll Grad - antal attribut (kolumner) 5
Pnr Start Slut Plats Budget Atomära värden i varje cell Värdena i varje kolumn är av samma typ Varje rad (tuple) är unik Ordningen mellan attributen är inte alltid oväsentlig Ordningen mellan raderna är oväsentlig Namnet för varje attribut är unikt för en relation 6
Enkelt objekt - envärda attribut Personnr: String 1..1 UNIK Namn: String 1..1 Person Personnr Namn 610234-7411 Blad Per 561224-5689 Löw Eva 231003-4433 Gren Ove Identifierande attribut är skuggat. Enkelt objekt - flervärda attribut Personnr: String 1..1 UNIK Namn: String 1..1 Titel: String 0..* Person Personnr Namn 610234-7411 Blad Per 561224-5689 Löw Eva 231003-4433 Gren Ove Titel Personnr Titel 561224-5689 Civ.ing. 231003-4433 Fil.dr 231003-4433 Civ.ing 7
Person Personnr Namn 610234-7411 Blad Per 561224-5689 Löw Eva 231003-4433 Gren Ove Nycklar? Titel Personnr Titel 561224-5689 Civ.ing. 231003-4433 Fil.dr 231003-4433 Tekn.dr En nyckel är ett antal attribut (t ex ett) som unikt identifierar en rad. Mängden av alla sådana attribut eller kombinationer av attribut kallas kandidatnycklar. Den/de attribut som väljs som identifierare kallas primärnyckel. Eventuella övriga nycklar blir alternativnycklar. En främmande nyckel är ett/flera attribut i en tabell som svarar mot primärnyckeln i en ANNAN tabell (eller i vissa specialfall mot samma tabell). Personnr i tabellen TITEL ingår i primärnyckeln för tabellen TITEL men utgör även främmande nyckel mot tabellen. Främmande nyckel-attribut är det som relaterar olika tabeller till varandra. Alla värden som förekommer i främmande-nyckel kolumerna måste ha sin motsvarighet som primärnyckel i en annan tabell, eller också måste de vara NULL. De två sista villkoren brukar kallas referential integrity. Entity integrity Ingen del av primärnyckeln får vara NULL (primärnyckeln identifierar ju en rad och måste alltid finnas). Referential integrity Alla värden för kolumner som utgör främmande nyckel kolumner mot en annan tabell måste svara mot existerande primärnyckel-värden för denna andra tabell. Eller också måste värdena i främmande nyckelkolumnerna vara NULL. Detta betyder bland annat att främmande nyckel kolumnerna i en tabell måste ha samma domäner som primärnyckel kolumnerna i den tabell som de refererar till. 8
Identifierare Objekt kan identifieras med hjälp av attribut och/eller samband mellan objekt. Avbildningsreglerna för ett attribut som ensamt ska tjäna som identifierare måste alltid vara UNIKT och TOTALT (se nedan). Detta betyder att alla sådana attribut kan väljas ensamma som primärnyckel. Motsatsen till totala attribut kallas f. ö. PARTIELL(a) attribut (eller partiella relationer). En identifierare för ett objekt kan sättas samma av ett eller flera attribut som hör till objektet eller ett attribut plus ett eller flera samband mellan objektet och andra objekt. A attributename: Datetype 1..1 UNIK Sammansatta identifierare KURSDELTAGANDE Personnr: String 1..1 Kurskod: String 1..1 Nivå: String 1..1 Entitetstypen KURSDELTAGANDE modellerar att en student går en viss kurs. Man kan läsa kurser på flera olika nivåer där C-nivån har en svårare tenta än A-nivån. Här finns inget attribut som ensamt är både unikt och totalt (en viss student kan läsa flera kurser än en så kurskod är inte unikt, en kurs har flera deltagare så personnummer är inte unikt. Detsamma gäller nivå där flera studenter kan läsa t ex B-nivån). Kombinerar man ihop attributen personnummer och kurskod får man dock en unik identifierare (detta under förutsättning att man inte kan läsa samma kurs på flera olika nivåer. Om detta gäller måste även nivå inkluderas i identifieraren). KURSDELTAGANDE Personnr Kurskod Nivå 9
Presentation Gränssnittet ger möjlighet att nå applikationsprogrammen och därmed data i databasen. Surrogatnycklar Vanliga användarspecificerade nycklar kan vara bristfällig ett par avseenden: 1. De kan förändras Exempelvis händer det att attribut som t ex avdelningsnummer/namn förändras när ett företag organiseras om. 2. Olika användarnamn kan användas för att identifiera samma entitet. T ex KUNDER KUND CUSTOMER jfr homonymer. Surrogat är systemgenererade entitetsidentifierare vars unikhet är garanterad för alltid och som alltså ej kan förändras. 10
Surrogatnycklar ANVÄNDARE BEHÖVER INTE VARA MEDVETNA OM ATT SURROGAT-NYCKLAR ANVÄNDS, EFTERSOM DESSA BARA ANVÄNDS INTERNT. FORTFARANDE HAR MAN "I LEVANDE LIVET" BEHOV AV ATT KUNNA IDENTIFIERA OBJEKT, OCH BEHOVET AV "ENTITY INTEGRITY" GÖR ATT (ANVÄNDARNAS) PRIMÄR-NYCKEL BEHÖVS. INTERNT KOMMER DOCK SURROGATET ATT ANVÄNDAS SOM ENVÄRDA UNIKA PRIMÄR-NYCKLAR OCH ÄVEN I REFERENSER SOM FRÄMMANDE NYCKLAR. Från konceptuellt schema till databas, fortsättning Partiella relationer (och för all del attribut) ger upphov till problem med NULL-värden. Har man inte modellerat bort risken för NULL-värden bör man ta hand om det vid transformationen från konceptuell modell till relationsschema. Partiella relationer och attribut undviks t ex om man använder isahierarkier. 11
NULL Vad betyder egentligen NULL? Värde saknas? Värde finns men är ej känt? (just nu...) Värde är ej tillämpligt? (jfr arvs-hierarkier ) NULL Null-värden kan ge problem vid join. ANSTÄLLDA AVDELNING Pnr Anst.nr Adress Avd.nr Avdelning Avd.nr 11111 1A Byv. 3 3 Forskning 3 22222 3B Solsv. 6 5 Försäljn. 5 33333 1AA Byv. 5 3 Admin. 1 44444 2B Byv.7 1 55555 1X Solv. 7 NULL 66666 3Y Byv. 11 NULL En join mellan anställda över Avd.nr kommer att resultera i att de två sista anställda inte kommer med. Beroende på omständigheterna kan detta vara vad som avsågs eller felaktigt. Pnr Anst.nr Adress Avd.nr Avdelning Avd.nr 11111 1A Byv. 3 3 Forskning 3 22222 3B Solsv. 6 5 Försäljn. 5 33333 1AA Byv. 5 3 Forskning 3 44444 2B Byv.7 1 Admin 1 12
Två saker: Hur översätta associationer i konceptuella scheman? Svar: vanligen som en främmande nyckel Hur ta hand om NULL-problematik vid översättningen? Svar: Analys av distribution av NULLvärden och/eller associationstabeller Namn: String 1..1 UNIK Ålder: String 1..1 0..1 äger 0..1 BIL Regno: String 1..1 UNIK Märke: String 1..1 Person Personnr Namn 610234-7411 Blad Per 561224-5689 Löw Eva 231003-4433 Gren Ove Bil Regnr Ägs-av Typ AIB 436 610234-7411 Volvo BPL 845 561224-5689 Fiat FJK 359 NULL Saab Det sammanbindande attributet läggs så att det får så få nullvärden som möjligt! Här antas att det finns fler personer utan bilar än tvärtom. 13
Partiella relationer alternativ lösning: Namn: String 1..1 UNIK Ålder: String 1..1 0..1 äger 0..1 BIL Regno: String 1..1 UNIK Märke: String 1..1 1 0 BIL- 0 1 ÄGANDE BIL Person Personnr Namn 610234-7411 Blad Per 561224-5689 Löw Eva 231003-4433 Gren Ove Bil / Person Ägs-av Regnr 610234-7411 AIB 436 561224-5689 BLP 845 Bil Regnr Typ AIB 436 Volvo BPL 845 Fiat FJK 359 Saab Implementering av associationer och sammansatta identifierare KURS Kurskod: String 1..1 UNIK Namn: String 1..1 Vad identifierar KURS? Jo, Kurskod! (Unikt och totalt) hör_till 1..1 0..* KURSTILLFÄLLE Kursansvarig: String 1..1 Starttid: String 1..1 Sluttid: String 1..1 Inget av attributen hos klassen KURSTILLFÄLLE är unikt och totalt. Inte ens om man kombinerar ihop alla attributen är det säkert att detta blir unikt (en lärare kan vara ansvarig för olika kurser som går under samma tidsperiod). Om vi däremot väljer att identifiera ett kurstillfälle med attributen starttid, sluttid och kurskod (dvs KURSTILLFÄLLES relation mot KURS) har vi en unik identifierare. 14
KURS Kurskod: String 1..1 UNIK Namn: String 1..1 hör_till 1..1 0..* KURSTILLFÄLLE Kursansvarig: String 1..1 Starttid: String 1..1 Sluttid: String 1..1 KURS Kurskod Namn Tabellen KURSTILLFÄLLE har en primärnyckel som består av kolumnerna Kurskod, Starttid och Sluttid. Kolumnen Kurskod ingår i PN men utgör även FN mot tabellen KURS. KURSTILLFÄLLE Kurskod Starttid Sluttid Kursansvarig Samband där avbildningarna har M ( många, * ) på en av sidorna Regel: Främmande nyckeln ska placeras i den.tabell som sitter på * ( många ) - sidan! 15
Namn: String 1..1 UNIK Ålder: String 1..1 0..1 äger 0..* BIL Regno: String 1..1 UNIK Märke: String 1..1 Person Personnr Namn 610234-7411 Blad Per 561224-5689 Löw Eva 231003-4433 Gren Ove Bil Regnr Ägs-av Typ AIB 436 610234-7411 Volvo BPL 845 610234-7411 Fiat FJK 359 NULL Saab M:M ( många till många, * : * ) måste lösas M:M- relationer måste alltid lösas med ett relationsobjekt (jämför med reifiering). Nullvärden undviks dessutom. Vid den första konceptuella modellen fick ju M:M samband finnas (såvida inte sambandet hade egna attribut). Vid övergång till ett relationsschema bildar man en en ny tabell som innehåller identiferarna från respektive entitet som sammankopplades via M:Msambandet. 16
Namn: String 1..1 UNIK Ålder: String 1..1 0..* äger 0..* BIL Regno: String 1..1 UNIK Märke: String 1..1 1 0 BIL- 0 1 ÄGANDE BIL Person Personnr Namn 610234-7411 Blad Per 561224-5689 Löw Eva 231003-4433 Gren Ove Bil / Person Ägs-av Regnr 610234-7411 AIB 436 561224-5689 AIB 436 561224-5689 BPL 845 561224-5689 JTL 739 Bil Regnr Typ AIB 436 Volvo BPL 845 Fiat FJK 359 Saab JTL 739 BMW Arvssamband Personnr :String 1..1 UNIK Namn: String 1..1 ANSTÄLLD KONSULT Avdelning: String 1..1 Projekt: String 1..1 Anställd Personnr Avd. 610234-7411 Dam 561224-5689 Herr Person Personnr Namn 610234-7411 Blad Per 561224-5689 Löw Eva 231003-4433 Gren Ove Konsult Personnr Projekt 231003-4433 PR 17
Översättning av entitet med sammansatta icke-lexikala identifierare Personnr: String 1..1 UNIK Namn: String 1..1 RUM 0..* 1..1 Rumsnr: String 0..* 1..1 bor_på 1..1 ingår_i HOTEL Hnamn: String 1..1 UNIK Typ: String 1..1 Rumsnummer räcker inte till för att identifiera (= vara möjlig att välja som primärnyckel) tabellen RUM! Personnr Namn Rumsnr HNamn 650321 Anna 2A Astoria 111111 Lisa 3B Ritz 222222 Eva 4S Astoria 444444 Pelle 2A Plaza RUM Rumsnr 2A 3B 4S 2A HNamn Astoria Ritz Astoria Plaza HOTEL HNamn Typ Astoria 5* Ritz 3* Plaza 5* Informationsförlust? Övning: Översätt följande två scheman til två olika relationsdatabasstrukturer: Personnr: String 1..1 UNIK Personnr: String 1..1 UNIK 1..1 ISA ANSTÄLLD Anstnr: String 1..1 UNIK gift_med 1..1 ANSTÄLLD Anstnr: String 1..1 UNIK 18
Från ett konceptuellt schema till en relationsdatabas Namn: String 1..1 UNIK Ålder: Integer 0..* äger 0..* BIL Regno: String 1..1 UNIK Märke: String 1..1 Ett sätt: ((Namn), Ålder) ÄGER((Namn, Regnr)) BIL((Regnr), Märke) Ett annat sätt: Namn ÄGANDE Namn BIL Regnr Ålder Regnr Märke Vart tog alla regler vägen? Vart tog alla regler vägen fortsättning? - Domänbeskrivningar - Referensregler (Främmande Nyckel-specifikationer) - Integritetsregler (triggers) Kontroll av data skall ske så tidigt (så nära källan) som möjligt! Systemet skall inte kontrollera att data inte är fel, utan undanröja möjligheterna till att det blir fel 19
Domändefinition Domänkarakteristika datatyp längd format Exempel numeric, integer, char* 5 siffror, 30 tkn ååmmdd, nnnn-nnnnnnn * siffra, heltal, tecken Inför SQL (DDL-delen): EMPLOYEE Eid: String 1..1 UNIK 1..* 1..1 works_at BUSINESS Bid: String 1..1 UNIK Detta blir två tabeller: EMPLOYEE((EID), BID) och BUSINESS(BID) Hur defineras tabellen EMPLOYEE ovan? SQL har en DDL-del (lite mer okänd än DML-delen). DDL betyder Data Definition Language. DML betyder Data Manipulation Language. Med DDL kan vi definiera tabeller, regler etc. Med DML kan vi sen ställa frågor mot de tabeller vi skapat. 20
SQL: DDL-exempel CREATE TABLE EMPLOYEE (EID VARCHAR(11) NOT NULL UNIQUE, BID CHAR(7) NOT NULL, PRIMARY KEY(EID), FOREIGN KEY(BID) REFERENCES BUSINESS ON DELETE CASCADE ON UPDATE CASCADE) Med hjälp av DDL-satsen ovan har vi realiserat ett antal regler. Entity integrity regler: Ingen del av primärnyckeln får vara NULL och PN måste vara unik för varje förekomst av entiteten. Alltså måste det (de) attribut som väljs till PN deklareras som NOT NULL och UNIQUE *. Vidare bör man ta ställning till vad som ska hända med främmande nyckel-attributet vid DELETE respektive UPDATE av en föräldra -entitet. DELETE och UPDATE-regler talar om just vilka effekter ett borttag eller en uppdatering av en föräldraentitet får på barn -entiteten. Här har vi valt att låta såväl DELETE som UPDATE vara CASCADES. Dvs ett borttag av en föräldraentiet innebär att även barnentiteten tas bort. En uppdatering av en föräldraentitet innebär att även främmande nyckelfältet i barnentiteten uppdateras. Vilka andra typer av effekter på DELETE/ INSERT kunde man valt? *) ibland innebär själva deklarationen av ett attribut som PN just att NOT NULL resp. UNIQUE upprätthålls. Då behöver man inte ange detta specifikt. Mera främmande nycklar... CREATE TABLE EMPLOYEE (EID VARCHAR(11) NOT NULL UNIQUE, BID CHAR(7) NOT NULL, PRIMARY KEY(EID), FOREIGN KEY(BID) REFERENCES BUSINESS ON DELETE CASCADE ON UPDATE CASCADE) Här talar man om att BID i tabellen EMPLOYEE refererar till (är främmande nyckel mot) tabellen BUSINESS. Det måste alltså finnas en primärnyckel i BUSINESS vars värden svarar mot värdena för BID i tabellen EMPLOYEE. Om man inte skriver SQL kan man fortfarande visa vilka främmandenyckelrelationer som råder. T ex genom EMPLOYEE. BID = BUSINESS.BID 21
händelse som utlöser (insert, update, delete, retrieve) objekt (attribut eller entitet) som berörs villkor som utlöser triggern åtgärder när triggern utlöses Triggers exempel CREATE TRIGGER Signalera_stora_ökningar: AFTER UPDATE OF SALARY ON EMPLOYEE REFERENCING NEW AS n OLD AS o FOR EACH ROW MODE DB2SQL IF n.salary > 1.1 * o.salary SIGNAL SQLSTATE 75000 ( Salary increase > 10 % ) EMPLOYEE Name Adress Salary Kalle Byvägen 3 10000 Olle Solstigen 4 20000 Stina Ekgränd 2 18000 Kurt Byvägen 5 17000 22