Free Press

Datamodellen Entity Relationship (ER) har funnits i över 35 år. Den är väl lämpad för datamodellering för användning med databaser eftersom den är ganska abstrakt och lätt att diskutera och förklara. ER-modeller kan lätt översättas till relationer. ER-modeller, även kallade ER-scheman, representeras av ER-diagram.

ER-modellering bygger på två begrepp:

• Entiteter, definierade som tabeller som innehåller specifik information (data)
• Relationer, definierade som associationer eller interaktioner mellan entiteter

Här är ett exempel på hur dessa två begrepp kan kombineras i en ER-datamodell: I resten av det här kapitlet kommer vi att använda en exempeldatabas kallad COMPANY-databasen för att illustrera begreppen i ER-modellen. Denna databas innehåller information om anställda, avdelningar och projekt. Viktiga punkter att notera är bland annat:

• Det finns flera avdelningar i företaget. Varje avdelning har en unik identifiering, ett namn, kontorets placering och en viss anställd som leder avdelningen.
• En avdelning styr ett antal projekt som alla har ett unikt namn, ett unikt nummer och en budget.
• Varje anställd har ett namn, ett identifieringsnummer, en adress, en lön och ett födelsedatum. En anställd är knuten till en avdelning men kan delta i flera projekt. Vi behöver registrera den anställdes startdatum i varje projekt. Vi behöver också veta vilken direkt chef varje anställd har.
• Vi vill hålla reda på anhöriga för varje anställd. Varje anhörig har ett namn, födelsedatum och en relation till den anställde.

Entitet, entitetsuppsättning och entitetstyp

En entitet är ett objekt i den verkliga världen med en självständig existens som kan särskiljas från andra objekt. En entitet kan vara

Entiteter kan klassificeras utifrån sin styrka. En entitet anses vara svag om dess tabeller är existensberoende

• Det vill säga, den kan inte existera utan en relation med en annan entitet
• Dess primära nyckel härleds från den överordnade entitetens primära nyckel
  • Tabellen Äkta maka, i databasen FÖRETAG, är en svag entitet eftersom dess primära nyckel är beroende av tabellen Anställd. Utan en motsvarande post för anställda skulle posten för maka/make inte existera.

En entitet anses vara stark om den kan existera åtskild från alla dess relaterade entiteter.

• Kärnor är starka entiteter.
• En tabell utan främmande nyckel eller en tabell som innehåller en främmande nyckel som kan innehålla nollor är en stark entitet

En annan term att känna till är entitetstyp som definierar en samling liknande entiteter.

En entitetsuppsättning är en samling av entiteter av en entitetstyp vid en viss tidpunkt. I ett entitetsrelationsdiagram (ERD) representeras en entitetstyp av ett namn i en ruta. I figur 8.1 är entitetstypen till exempel EMPLOYEE.

Existensberoende

En entitets existens är beroende av den relaterade entitetens existens. Den är existensberoende om den har en obligatorisk främmande nyckel (dvs. ett främmande nyckelattribut som inte kan vara noll). I databasen COMPANY är till exempel en entitet Spouse existensberoende av entiteten Employee.

Slag av enheter

Du bör också känna till olika typer av enheter, inklusive oberoende enheter, beroende enheter och karakteristiska enheter. Dessa beskrivs nedan.

Oberoende enheter

Oberoende enheter, även kallade kärnor, är databasens ryggrad. De är det som andra tabeller baseras på. Kärnor har följande egenskaper:

• De är databasens byggstenar.
• Primärnyckeln kan vara enkel eller sammansatt.
• Primärnyckeln är inte en utländsk nyckel.
• De är inte beroende av en annan entitet för sin existens.

Om vi återknyter till vår databas COMPANY är exempel på en oberoende entitet kundtabellen, anställdtabellen eller produkttabellen.

Avhängiga entiteter

Avhängiga entiteter, även kallade härledda entiteter, är beroende av andra tabeller för att få sin betydelse. Dessa enheter har följande egenskaper:

• Dependenta enheter används för att koppla ihop två kärnor.
• De sägs vara existensberoende av två eller flera tabeller.
• Många till många-relationer blir associerande tabeller med minst två främmande nycklar.
• De kan innehålla andra attribut.
• Den främmande nyckeln identifierar varje associerad tabell.
• Det finns tre alternativ för primärnyckeln:
  1. Använd en sammansättning av främmande nycklar för associerade tabeller om de är unika
  2. Använd en sammansättning av främmande nycklar och en kvalificerande kolumn
  3. Skapa en ny enkel primärnyckel

Karaktäristiska entiteter

Karakteristiska entiteter ger mer information om en annan tabell. Dessa enheter har följande egenskaper:

• De representerar attribut med flera värden.
• De beskriver andra enheter.
• De har vanligtvis ett förhållande mellan en och många.
• Den främmande nyckeln används för att ytterligare identifiera den karakteriserade tabellen.
• Möjligheterna för den primära nyckeln är följande:
  1. Använd en sammansättning av den främmande nyckeln plus en kvalificerande kolumn
  2. Skapa en ny enkel primärnyckel. I databasen COMPANY kan dessa vara:
     • Employee (EID, Name, Address, Age, Salary) – EID är den enkla primärnyckeln.
     • EmployeePhone (EID, Phone) – EID är en del av en sammansatt primärnyckel. Här är EID också en främmande nyckel.

Attribut

Varje entitet beskrivs av en uppsättning attribut (t.ex. anställd = (namn, adress, födelsedatum (ålder), lön).

Varje attribut har ett namn och är kopplat till en entitet och en domän av lagliga värden. Informationen om attributets domän presenteras dock inte i ERD.

I entitetsrelationsdiagrammet, som visas i figur 8.2, representeras varje attribut av en oval med ett namn inuti.

Typer av attribut

Det finns några typer av attribut som du behöver känna till. Vissa av dessa ska lämnas oförändrade, men vissa behöver justeras för att underlätta representationen i relationsmodellen. I detta första avsnitt kommer vi att diskutera typerna av attribut. Senare kommer vi att diskutera hur man fixar attributen så att de passar korrekt i relationsmodellen.

Enkla attribut

Enkla attribut är de som hämtas från de atomära värdedomänerna; de kallas också för enkelvärdesattribut. I databasen COMPANY skulle ett exempel på detta vara: Namn = {John} ; Ålder = {23}

Kompositattribut

Kompositattribut är sådana som består av en hierarki av attribut. Med hjälp av vårt databasexempel, som visas i figur 8.3, kan Address bestå av Number (nummer), Street (gata) och Suburb (förort). Detta skulle alltså skrivas som → Address = {59 + ’Meek Street’ + ’Kingsford’}

Multiverade attribut

Multiverade attribut är attribut som har en uppsättning värden för varje enhet. Ett exempel på ett multivaluerat attribut från databasen COMPANY, som visas i figur 8.4, är en anställds grader: BSc, MIT, PhD.

Avledda attribut

Avledda attribut är attribut som innehåller värden som beräknats från andra attribut. Ett exempel på detta kan ses i figur 8.5. Age kan härledas från attributet Birthdate. I den här situationen kallas Birthdate för ett lagrat attribut, som sparas fysiskt i databasen.

Nycklar

En viktig begränsning för en enhet är nyckeln. Nyckeln är ett attribut eller en grupp av attribut vars värden kan användas för att unikt identifiera en enskild enhet i en enhetsuppsättning.

Typer av nycklar

Det finns flera typer av nycklar. Dessa beskrivs nedan.

Kandidatnyckel

En kandidatnyckel är en enkel eller sammansatt nyckel som är unik och minimal. Den är unik eftersom inga två rader i en tabell kan ha samma värde vid någon tidpunkt. Den är minimal eftersom varje kolumn är nödvändig för att uppnå unikhet.

Från vårt exempel med databasen COMPANY, om enheten är Employee(EID, First Name, Last Name, SIN, Address, Phone, BirthDate, Salary, DepartmentID), är möjliga kandidatnycklar:

• EID, SIN
• Förnamn och efternamn – om man antar att det inte finns någon annan i företaget med samma namn
• Förnamn och DepartmentID – om man antar att två personer med samma efternamn inte arbetar på samma avdelning

Kompositnyckel

En kompositnyckel består av två eller flera attribut, men den måste vara minimal.

Med hjälp av exemplet från avsnittet om kandidatnycklar är möjliga sammansatta nycklar följande:

• Förnamn och efternamn – om man antar att det inte finns någon annan i företaget med samma namn
• Förnamn och avdelnings-ID – om man antar att två personer med samma efternamn inte arbetar på samma avdelning

Primärnyckel

Primärnyckeln är en kandidatnyckel som väljs ut av databaskonstruktören för att användas som identifieringsmekanism för hela entitetsuppsättningen. Den måste unikt identifiera tupler i en tabell och får inte vara noll. Primärnyckeln anges i ER-modellen genom att attributet är understruket.

• En kandidatnyckel väljs av konstruktören för att unikt identifiera tupler i en tabell. Den får inte vara ogiltig.
• En nyckel väljs av databaskonstruktören för att användas som en identifieringsmekanism för hela entitetsuppsättningen. Detta kallas primärnyckeln. Denna nyckel anges genom att attributet är understruket i ER-modellen.

I följande exempel är EID den primära nyckeln:

Employee(EID, Förnamn, Efternamn, SIN, Adress, Telefon, Födelsedatum, Lön, AvdelningsID)

Sekundär nyckel

En sekundär nyckel är ett attribut som enbart används för att hämta information (kan vara sammansatt), till exempel: En alternativ nyckel är alla kandidatnycklar som inte väljs som primärnyckel.

Alternativnyckel

Alternativnycklar är alla kandidatnycklar som inte väljs som primärnyckel.

Förändringsnyckel

En främmande nyckel är ett attribut i en tabell som hänvisar till primärnyckeln i en annan tabell ELLER den kan vara noll. Både främmande och primära nycklar måste vara av samma datatyp.

I databasexemplet COMPANY nedan är DepartmentID den främmande nyckeln:

Employee(EID, Förnamn, Efternamn, SIN, Adress, Telefon, Födelsedatum, Lön, DepartmentID)

Nulls

En null är en specialsymbol, oberoende av datatyp, som betyder antingen okänd eller oanvändbar. Den betyder inte noll eller tomt. Funktioner hos null är bland annat:

• Ingen datainmatning
• Inte tillåtet i primärnyckeln
• Bör undvikas i andra attribut
• Kan representera
  • Ett okänt attributvärde
  • Ett känt, men saknas, attributvärde
  • En ”ej tillämplig” förutsättning
• Kan skapa problem när funktioner som COUNT, AVERAGE och SUM används
• Kan skapa logiska problem när relationstabeller kopplas samman

NOTAT: Resultatet av en jämförelseoperation är noll när något av argumenten är noll. Resultatet av en aritmetisk operation är noll när något av argumenten är noll (utom funktioner som ignorerar nollor).

Exempel på hur null kan användas

Använd lönetabellen (Salary_tbl) i figur 8.6 för att följa ett exempel på hur null kan användas.

För att börja, hitta alla anställda (emp#) i Sales (under kolumnen jobName) vars lön plus provision är större än 30 000.

• SELECT emp# FROM Salary_tbl
• WHERE jobName = Sales AND
• (provision + lön) > 30 000 -> E10 och E12

Det här resultatet inkluderar inte E13 på grund av nollvärdet i provisionskolumnen. För att se till att raden med nollvärdet inkluderas måste vi titta på de enskilda fälten. Genom att lägga till provision och lön för anställd E13 blir resultatet ett nollvärde. Lösningen visas nedan.

Relationer

Relationer är limmet som håller ihop tabellerna. De används för att koppla samman relaterad information mellan tabeller.

Relationernas styrka baseras på hur primärnyckeln för en relaterad enhet definieras. Ett svagt, eller icke-identifierande, förhållande existerar om primärnyckeln för den relaterade enheten inte innehåller en primärnyckelkomponent för den överordnade enheten. Exempel på företagsdatabaser är:

• Customer(CustID, CustName)
• Order(OrderID, CustID, Date)

En stark, eller identifierande, relation existerar när den relaterade enhetens primära nyckel innehåller den primära nyckelkomponenten för den överordnade enheten. Exempel:

• Course(CrsCode, DeptCode, Description)
• Class(CrsCode, Section, ClassTime…)

Typer av relationer

Nedan följer beskrivningar av de olika typerna av relationer.

En till många (1:M)-relation

En en till många (1:M)-relation bör vara normen i alla relationsdatabaskonstruktioner och förekommer i alla relationsdatabasmiljöer. En avdelning har till exempel många anställda. Figur 8.7 visar relationen mellan en av dessa anställda och avdelningen.

En till en (1:1)-relation

En en till en (1:1)-relation är relationen mellan en enhet och endast en annan enhet, och vice versa. Det bör vara sällsynt i alla relationsdatabaser. I själva verket kan det tyda på att två enheter faktiskt hör hemma i samma tabell.

Ett exempel från databasen COMPANY är att en anställd är associerad med en make/maka och en make/maka är associerad med en anställd.

Många till många (M:N)-relationer

För en många till många-relation bör man beakta följande punkter:

• Den kan inte implementeras som sådan i relationsmodellen.
• Den kan ändras till två 1:M-relationer.
• Det kan implementeras genom att dela upp en uppsättning 1:M-relationer.
• Det innebär implementering av en sammansatt entitet.
• Skapar två eller fler 1:M-relationer.
• Den sammansatta entitetstabellen måste innehålla åtminstone primärnycklarna i de ursprungliga tabellerna.
• Länkningstabellen innehåller flera förekomster av värdena för de främmande nycklarna.
• Utvidare attribut kan tilldelas vid behov.
• Det går att undvika problem som är inneboende i ett M:N-förhållande genom att skapa en sammansatt entitet eller en bryggentitet. En anställd kan till exempel arbeta med många projekt ELLER ett projekt kan ha många anställda som arbetar med det, beroende på affärsreglerna. Eller så kan en elev ha många klasser och en klass kan ha många elever.

Figur 8.8 visar en annan annan annan aspekt av M:N-relationen där en anställd har olika startdatum för olika projekt. Därför behöver vi en JOIN-tabell som innehåller EID, Code och StartDate.

Exempel på mappning av en binär relationstyp M:N

• För varje binär relation M:N identifierar du två relationer.
• A och B representerar två enhetstyper som deltar i R.
• Skapa en ny relation S för att representera R.
• S måste innehålla A:s och B:s PK:er. Dessa kan tillsammans utgöra PK:n i tabellen S ELLER dessa kan tillsammans med ett annat enkelt attribut i den nya tabellen R utgöra PK:n.
• Kombinationen av primärnycklarna (A och B) kommer att utgöra primärnyckeln i S.

Unär relation (rekursiv)

En unär relation, även kallad rekursiv, är en relation mellan förekomster av samma entitetsuppsättning. I den här relationen är primärnyckeln och den främmande nyckeln desamma, men de representerar två enheter med olika roller. Se figur 8.9 för ett exempel.

För vissa enheter i ett unärt förhållande kan en separat kolumn skapas som hänvisar till primärnyckeln i samma enhetsuppsättning.

Ternära relationer

En ternär relation är en relationstyp som innebär många till många relationer mellan tre tabeller.

Se figur 8.10 för ett exempel på mappning av en ternär relationstyp. Observera att n-ary betyder flera tabeller i en relation. (Kom ihåg att N = många.)

• För varje n-ary (> 2)-relation skapar du en ny relation för att representera relationen.
• Primärnyckeln för den nya relationen är en kombination av primärnycklarna för de deltagande entiteterna som innehar den N (många) sidan.
• I de flesta fall av en n-ary-relation har alla deltagande enheter en många-sida.

Attribution

Detta kapitel i Database Design (inklusive bilder, om inget annat anges) är en härledd kopia av Data Modeling Using Entity-Relationship Model av Nguyen Kim Anh licensierad under Creative Commons Attribution License 3.0 license

Följande material är skrivet av Adrienne Watt:

1. Nulls avsnitt och exempel
2. Nyckelbegrepp
3. Övningar