2008-04-07 TDDD12 Lecture 3: EER and mapping E 1 TDDD12 Database Technology Concepts learned this far Lecture 3: EER/ER and mapping to relations by Juha Takkinen 2008-04-07 1 2 2008-04-07 TDDD12 Lecture 3: EER and mapping E 2 3 2008-04-07 TDDD12 Lecture 3: EER and mapping E 3 4 2008-04-07 TDDD12 Lecture 3: EER and mapping E 4 Steg 1: För varje stark entitet E, skapa en relation som har samma enkla attribut som E. Observera: Kandidatnycklarna i E blir också kandidatnycklar i R. Vi väljer en som primärnyckel. Steg 2: För varje svag entitet W med ägarentitet E skapa en relation R som har samma enkla attribut som W. Lägg också till primärnyckelattributen från relationen som motsvarar E. 5 2008-04-07 TDDD12 Lecture 3: EER and mapping E 5 6 2008-04-07 TDDD12 Lecture 3: EER and mapping E 6
2008-04-07 Steg 3: För varje binär 1:1-relation, identifiera relationerna som motsvarar de relaterade entiteterna, S och T. Välj en av dessa och lägg till primärnyckeln från en av dem som främmande nyckel i den andra. 7 2008-04-07 TDDD12 Lecture 3: EER and mapping E 7 8 2008-04-07 TDDD12 Lecture 3: EER and mapping E 8 Steg 4: För varje binär 1:N-relation, identifiera relationerna som motsvarar de inkommande entiteterna, S och T. Välj relationen på 1-sidan och lägg till dess primärnyckel som främmande nyckel i relationen på N-sidan. Steg 5: För varje binär M:N-relation, identifiera relationerna som motsvarar inkommande entiteter. Skapa en ny relation R och använd primärnycklarna från S och T som främmande nycklar i R. Dessa två nycklar bildar också tillsammans primärnyckel i R. Om det finns attribut på relationen läggs dessa också till i R. 9 2008-04-07 TDDD12 Lecture 3: EER and mapping E 9 10 2008-04-07 TDDD12 Lecture 3: EER and mapping E 10 Steg 6: För varje n:är relation med n > 2, skapa en ny relation S som innehåller primärnycklarna från de inkommande relationerna som främmande nycklar. 11 2008-04-07 TDDD12 Lecture 3: EER and mapping E 11 12 2008-04-07 TDDD12 Lecture 3: EER and mapping E 12
2008-04-07 TDDD12 Lecture 3: EER and mapping E 13 Det resulterande schemat Steg 7: För varje flervärt attribut A i R, som inte är primärnyckel, skapa en ny relation R som innehåller ett attribut för varje attribut i A och primärnyckeln för R som främmande nyckel. SName FName Address Sex SupervisedBy Departm: Name Number Mgr Startdate Project: Name ContrBy Relative: Enr Name Address Sex WorksAt: Employ. Departm. WorksFor: Employ. Project Hours 13 14 2008-04-07 TDDD12 Lecture 3: EER and mapping E 14 Några frågor: Varför översatte vi inte det härledda attributet? Spelar det någon roll vilken sida man sätter de främmande nyckeln på vid översättning av 1:1-relationer? Varför? Kan man tänka sig att vi översätter 1:1- och 1:N-relationer på något annat sätt? När? Varför? E Steg 8: Mappa specialisering till relationer ENumber Employee Teleph o Technician Administrator 15 2008-04-07 TDDD12 Lecture 3: EER and mapping E 15 16 2008-04-07 TDDD12 Lecture 3: EER and mapping E 16 E E Fyra möjligheter för översättning Variant 1: Skapa en relation R för C med alla attribut i C. Skapa sedan en relation R i för varje subklass S i med alla attribut från S i och primärnyckeln från R 17 2008-04-07 TDDD12 Lecture 3: EER and mapping E 17 18 2008-04-07 TDDD12 Lecture 3: EER and mapping E 18
2008-04-07 TDDD12 Lecture 3: EER and mapping E 19 Exempel variant 1 E Administrator: Variant 2: Skapa en relation för varje subklass S i. Attributen för varje relation är attributen i C och attributen från S i. Fungerar bra för total eller partiell, disjunkt eller överlappande. 19 20 2008-04-07 TDDD12 Lecture 3: EER and mapping E 20 Exempel variant 2 E Administrator: Fungerar bra endast för disjunkt och total. Varför? Variant 3: För disjunkta subklasser. Skapa en relation R med alla attribut från C och alla subklasserna S i. Lägg också till ett typattribut för att skilja mellan subklasserna. 21 2008-04-07 TDDD12 Lecture 3: EER and mapping E 21 22 2008-04-07 TDDD12 Lecture 3: EER and mapping E 22 Exempel variant 3 E JobType Bra för disjunkt och partiell. Varför? Variant 4: Skapa en relation R med alla attribut från C och alla subklasser S i. Lägg också till ett flaggatribut F i till R för varje subklass S i. 23 2008-04-07 TDDD12 Lecture 3: EER and mapping E 23 24 2008-04-07 TDDD12 Lecture 3: EER and mapping E 24
2008-04-07 TDDD12 Lecture 3: EER and mapping E 25 Exempel variant 4 De fyra varianterna Teleph. Sal. TFlag AFlag Administrator: Administrator: JobType Bra för total, överlappande, disjunkt eller partiell. TFlag AFlag 25 26 2008-04-07 TDDD12 Lecture 3: EER and mapping E 26 Hur ska man välja? När man har disjunkt eller överlappande ärvning? Total eller partiell ärvning? Hur mycket data finns på de olika nivåerna? Hur viktiga är de för databasen? När det finns många eller få gemensamma attribut i superklassen? Många eller få speciella attribut i subklasserna? Finns det relationer från de olika subklasserna? EER to Relations Step 9: Mapping of nion Types a) If the defining superclasses have different primary keys, introduce a surrogate key in the union relation and use it as a foreign key in the superclasses. B CompanyID Y u Z C PersonID Y(CompanyID, B, XID) Z(PersonID, C, XID) A X X(XID, A) 27 2008-04-07 TDDD12 Lecture 3: EER and mapping E 27 28 2008-04-07 TDDD12 Lecture 3: EER and mapping E 28 EER to Relations Step 9: Mapping of nion Types Exampel: LARM-dagarna Town a) If the defining superclasses use the same primary key, no need for surrogate key. Name PID PhoneNum OrgNr Street Address PostNum B A PersonID Y u X Z C PersonID Y(PersonID, B) Z(PersonID, C) X(PersonID, A) * No FKs in Y and Z, unless total participation (error in figure 7.7 in the book). 1 1 Person is-contact-for o Teacher Student u N Responsible Organization N 1 displays M organizes Exhibition ID Description 29 2008-04-07 TDDD12 Lecture 3: EER and mapping E 29 30 2008-04-07 TDDD12 Lecture 3: EER and mapping E 30
2008-04-07 TDDD12 Lecture 3: EER and mapping E 31 Bra design? Kan man vara säker på att den databas som resulterar från en översättning har en bra design? Konfronterad med en relationsdatabas hur kan vi veta om den har en bra design? Vad är bra databasdesign? Fyra informella mått Ett formellt mått: Normalisering Informella designriktlinjer Lätt att förklara semantiken för ett relationsschema Reducera reduntant information i dina tupler Redundans förorsakar anomalier: Insättningsanomali Borttagningsanomali Modifieringsanomali EMP( EMPID, EMPNAME, DEPTNAME, DEPTMGR) 123 Smith Research 999 333 Wong Research 999 888 Borg Administration null 31 32 2008-04-07 TDDD12 Lecture 3: EER and mapping E 32 Informella designriktlinjer, forts. Reducera NLL-värden i tupler Varför tnyttja utrymmet effektivt ndvik kostsamma join Förhindra möjligheten att generera falska (spurious) tupler Kartesisk produkt genererar felaktiga tupler Endast join över primärnyckel/främmande nyckel 33 2008-04-07 TDDD12 Lecture 3: EER and mapping E 33