Der findes forskellige relationstyper.
Et eksempel er en relation <person er gift med person> som forbinder entiteten [person] med sig selv. En anden relation <person ved, hvem person er> er retningsbestemt.
Et eksempel er relationen <Ingrediens i Opskrift> som forbinder entiteten [opskrift] og [Ingrediens]
Et eksempel kan være relationen <sælger har solgt vare til kunde>, som forbinder de tre entiteter [sælger], [vare], [kunde].
Et eksempel kan være relationen <sælger har solgt vare til kunde med leveranceform>, som forbinder de fire entiteter [sælger], [vare], [kunde], [leveranceform]
I adressedatabasen antog vi uden nærmere overvejelser, at data kunne indeholdes i to tabeller. Men hvis man ser på et forslag til E/R-diagrammet for relationen, så er der tilsyneladende tre tabeller. Nemlig [person] - <person har telefonnummer> - <telefonnummer>.
Da vi har antaget at en post indeholdende telefonnummer kun er relateret til én post i person-tabellen, kan vi flytte oplysningerne om hvilken person, der har telefonnummer fra relationen <person har telefonnummer> til entiteten [telefonnummer]. Så ender vi altså med at have sparet tabellen <person har telefonnummer> væk.
Generelt er reduktion mulig når reduceringen ikke forårsager repeterende grupper, redundans eller NULL-værdier.
|
En relation kan reduceres hvis relationstypen er rekursiv eller binær og enten relationsgraden er 1 til mange og deltagelsen er obligatorisk på mange-siden eller relationsgraden er 1 til 1 og deltagelsen er obligatorisk på mindst én af siderne. |
|
En entitet kan reduceres, hvis relationstypen er rekursiv eller binær, relationsgraden er 1 til 1 og deltagelsen på begge sider af relationen er obligatorisk. |
Selv om vi kan spare en tabel ved reducering af en relation, skal man dog stadig huske at beholde relationen i E/R-diagrammet, ellers forsvinder jo informationen om hvordan entiteterne er forbundet. Desuden kan der jo være andre relationer mellem de samme entiteter, som ikke kan reduceres. Markér den reducerede relation med en stjerne (*).
At en entitet kan reduceres betyder blot at oplysningerne i den ene entitet lige så godt kan indeholdes i den anden, og at opsplitningen for så vidt var overflødig. At man så måske alligevel vælger at beholde data opsplittet kan der være andre grunde til (f.eks sikkerhedsmæssige).
Tertiære og højere relationstyper kan være besværlige at holde styr på, eller de virker søgte i forhold til opfattelsen af den virkelighed som skal beskrives af datamodellen. Endelig kan der optræde null-værdier i et af benene i relationen, hvilket bør undgås.
Det er muligt omformulere relationen, så entiteterne grupperes i en pseudo-entitet som herefter ved en binær relation kan forbindes til en anden entitet (evt en anden pseudo-entitet). Processen kaldes aggregering.
Forestil dig en database med følgende entiteter: [album], [kunstner], [kopinummer] og den tertiære relation <kunstner optræder på album med kopinummer>.
Nu opretter vi en ekstra relation <kunstner optræder med kopinummer>.
Og herefter en pseudo-entitet [fortolkning], som omfatter alle de fortolkninger af kopinumrene som kunstnerne har udført. Denne pseudo-entitet forbindes nu til entiteten [album] med relationen <fortolkning på album>.
Vupti. Nu har vi kun binære relationstyper tilbage. Som det er nævnt tidligere kan forespørgsler i Access jo behandles som tabeller. I Access vil vi derfor i praksis kunne lave aggregeringen (pseudo-entiteten) [Fortolkning] som en forespørgsel.
Copyright © 1998 Forlaget Hedeskov I/S