Free Press

Het entity relationship (ER) datamodel bestaat al meer dan 35 jaar. Het is zeer geschikt voor datamodellering voor gebruik met databases omdat het tamelijk abstract is en gemakkelijk te bespreken en uit te leggen. ER modellen laten zich gemakkelijk vertalen naar relaties. ER modellen, ook wel ER schema genoemd, worden weergegeven door ER diagrammen.

ER modellering is gebaseerd op twee concepten:

• Entiteiten, gedefinieerd als tabellen die specifieke informatie bevatten (data)
• Relaties, gedefinieerd als de associaties of interacties tussen entiteiten

Hier volgt een voorbeeld van hoe deze twee concepten kunnen worden gecombineerd in een ER datamodel: Prof. Ba (entiteit) geeft les (relatie) in de cursus Database Systemen (entiteit).

Voor de rest van dit hoofdstuk gebruiken we een voorbeelddatabase genaamd de BEDRIJF-database om de concepten van het ER-model te illustreren. Deze database bevat informatie over werknemers, afdelingen en projecten. Belangrijke punten om op te merken zijn:

• Er zijn verschillende afdelingen in het bedrijf. Elke afdeling heeft een unieke identificatie, een naam, de locatie van het kantoor en een bepaalde werknemer die de afdeling beheert.
• Een afdeling beheert een aantal projecten, die elk een unieke naam, een uniek nummer en een budget hebben.
• Elke werknemer heeft een naam, een identificatienummer, een adres, een salaris en een geboortedatum. Een werknemer is ingedeeld bij één afdeling, maar kan aan meerdere projecten meewerken. We moeten de startdatum van de werknemer in elk project vastleggen. Wij willen ook de directe chef van elke werknemer weten.
• Wij willen voor elke werknemer de afhankelijke personen bijhouden. Elke afhankelijke heeft een naam, geboortedatum en relatie met de werknemer.

Entity, Entity Set en Entity Type

Een entiteit is een object in de echte wereld met een onafhankelijk bestaan dat kan worden onderscheiden van andere objecten. Een entiteit kan

Entiteiten kunnen worden ingedeeld op basis van hun sterkte. Een entiteit wordt als zwak beschouwd als haar tabellen bestaansafhankelijk zijn.

• Dat wil zeggen, zij kan niet bestaan zonder een relatie met een andere entiteit
• Zijn primaire sleutel is afgeleid van de primaire sleutel van de bovenliggende entiteit
  • De tabel Echtgenoot, in de database BEDRIJF, is een zwakke entiteit omdat zijn primaire sleutel afhankelijk is van de tabel Werknemer. Zonder een overeenkomstig werknemersrecord zou het echtgeno(o)t(e) record niet bestaan.

Een entiteit wordt als sterk beschouwd als deze los van al zijn gerelateerde entiteiten kan bestaan.

• Kernen zijn sterke entiteiten.
• Een tabel zonder een foreign key of een tabel die een foreign key bevat die nulls kan bevatten, is een sterke entiteit

Een andere term om te kennen is entiteittype, dat een verzameling soortgelijke entiteiten definieert.

Een entiteitverzameling is een verzameling entiteiten van een entiteittype op een bepaald tijdstip. In een entiteitrelatiediagram (ERD) wordt een entiteittype weergegeven door een naam in een vakje. Bijvoorbeeld, in Figuur 8.1 is het entiteittype EMPLOYEE.

Existentieafhankelijkheid

Het bestaan van een entiteit is afhankelijk van het bestaan van de gerelateerde entiteit. Zij is bestaansafhankelijk als zij een verplichte foreign key heeft (d.w.z. een foreign key-attribuut dat niet null kan zijn). Bijvoorbeeld, in de database BEDRIJF is een entiteit Echtgenoot bestaansafhankelijk van de entiteit Werknemer.

Soorten entiteiten

U dient ook bekend te zijn met verschillende soorten entiteiten, waaronder onafhankelijke entiteiten, afhankelijke entiteiten en kenmerkende entiteiten. Deze worden hieronder beschreven.

Onafhankelijke entiteiten

Onafhankelijke entiteiten, ook wel kernels genoemd, vormen de ruggengraat van de database. Zij vormen de basis voor andere tabellen. Kernels hebben de volgende kenmerken:

• Zij zijn de bouwstenen van een database.
• De primaire sleutel kan eenvoudig of samengesteld zijn.
• De primaire sleutel is geen foreign key.
• Zij zijn voor hun bestaan niet afhankelijk van een andere entiteit.

Als we teruggaan naar onze COMPANY-database, zijn voorbeelden van een onafhankelijke entiteit de Customer table, de Employee table of de Product table.

Dependent entities

Dependent entities, ook wel afgeleide entiteiten genoemd, zijn voor hun betekenis afhankelijk van andere tabellen. Deze entiteiten hebben de volgende kenmerken:

• Dependent entities worden gebruikt om twee kernels met elkaar te verbinden.
• Ze worden geacht bestaansafhankelijk te zijn van twee of meer tabellen.
• Many to many-relaties worden associatieve tabellen met ten minste twee foreign keys.
• Ze kunnen andere attributen bevatten.
• De foreign key identificeert elke geassocieerde tabel.
• Er zijn drie opties voor de primaire sleutel:
  1. Gebruik een composiet van foreign keys van geassocieerde tabellen indien uniek
  2. Gebruik een composiet van foreign keys en een kwalificerende kolom
  3. Maak een nieuwe eenvoudige primaire sleutel

Characteristic entiteiten

Characteristic entiteiten geven meer informatie over een andere tabel. Deze entiteiten hebben de volgende kenmerken:

• Zij vertegenwoordigen attributen met meerdere waarden.
• Zij beschrijven andere entiteiten.
• Zij hebben gewoonlijk een één-op-veel relatie.
• De foreign key wordt gebruikt om de gekarakteriseerde tabel verder te identificeren.
• Opties voor primary key zijn als volgt:
  1. Gebruik een composiet van foreign key plus een kwalificerende kolom
  2. Creëer een nieuwe eenvoudige primary key. In de database COMPANY zou dit kunnen zijn:
     • Employee (EID, Naam, Adres, Leeftijd, Salaris) – EID is de eenvoudige primaire sleutel.
     • EmployeePhone (EID, Telefoon) – EID is onderdeel van een samengestelde primaire sleutel. Hier is EID ook een foreign key.

Attributen

Elke entiteit wordt beschreven door een set attributen (bijv. Werknemer = (Naam, Adres, Geboortedatum (Leeftijd), Salaris).

Elk attribuut heeft een naam, en is geassocieerd met een entiteit en een domein van wettelijke waarden. De informatie over het domein van het attribuut wordt echter niet in het ERD weergegeven.

In het entiteitrelatiediagram, weergegeven in figuur 8.2, wordt elk attribuut weergegeven door een ovaal met daarin een naam.

Typen attributen

Er zijn een paar typen attributen waarmee je bekend moet zijn. Sommige daarvan moeten blijven zoals ze zijn, maar sommige moeten worden aangepast om de weergave in het relationele model te vergemakkelijken. Dit eerste deel zal de soorten attributen bespreken. Later zullen we ingaan op het aanpassen van de attributen zodat ze correct in het relationele model passen.

Simpele attributen

Simpele attributen zijn attributen uit de atomaire waardedomeinen; ze worden ook wel attributen met één waarde genoemd. In de COMPANY-database zou een voorbeeld hiervan zijn: Naam = {John} ; Leeftijd = {23}

Samengestelde attributen

Samengestelde attributen zijn attributen die bestaan uit een hiërarchie van attributen. Gebruikmakend van ons databasevoorbeeld, en weergegeven in figuur 8.3, kan Adres bestaan uit Nummer, Straat en Voorstad. Dit zou dus geschreven worden als → Adres = {59 + ‘Meek Street’ + ‘Kingsford’}

Meervoudig gewaardeerde attributen

Meervoudig gewaardeerde attributen zijn attributen die voor elke entiteit een reeks waarden hebben. Een voorbeeld van een multivalueerd attribuut uit de COMPANY database, zoals te zien in figuur 8.4, zijn de graden van een werknemer: BSc, MIT, PhD.

Afgeleide attributen

Afgeleide attributen zijn attributen die waarden bevatten die uit andere attributen zijn berekend. Een voorbeeld hiervan is te zien in figuur 8.5. Leeftijd kan worden afgeleid van het attribuut Geboortedatum. In deze situatie wordt de geboortedatum een opgeslagen attribuut genoemd, dat fysiek in de database wordt opgeslagen.

Keys

Een belangrijke constraint op een entiteit is de sleutel. De sleutel is een attribuut of een groep attributen waarvan de waarden kunnen worden gebruikt om een individuele entiteit in een verzameling entiteiten op unieke wijze te identificeren.

Typen sleutels

Er zijn verschillende typen sleutels. Deze worden hieronder beschreven.

Kandidaat-sleutel

Een kandidaat-sleutel is een eenvoudige of samengestelde sleutel die uniek en minimaal is. Hij is uniek omdat geen twee rijen in een tabel op een bepaald moment dezelfde waarde mogen hebben. Zij is minimaal omdat elke kolom noodzakelijk is om uniciteit te bereiken.

Vanuit ons voorbeeld van de database BEDRIJF, als de entiteit Werknemer(EID, Voornaam, Achternaam, SIN, Adres, Telefoon, Geboortedatum, Salaris, DepartementID) is, zijn mogelijke kandidaat-sleutels:

• EID, SIN
• Voornaam en Achternaam – in de veronderstelling dat er niemand anders in het bedrijf is met dezelfde naam
• Naam en AfdelingID – in de veronderstelling dat twee mensen met dezelfde achternaam niet in dezelfde afdeling werken

Samengestelde sleutel

Een samengestelde sleutel is samengesteld uit twee of meer attributen, maar hij moet minimaal zijn.

Gebruik makend van het voorbeeld uit de kandidaat-sleutel sectie, mogelijke samengestelde sleutels zijn:

• Voornaam en Achternaam – in de veronderstelling dat er niemand anders in het bedrijf is met dezelfde naam
• Achternaam en Afdeling-ID – in de veronderstelling dat twee mensen met dezelfde achternaam niet op dezelfde afdeling werken

Priminaire sleutel

De primaire sleutel is een kandidaatsleutel die door de databaseontwerper wordt geselecteerd om te worden gebruikt als een identificatiemechanisme voor de hele verzameling entiteiten. Zij moet op unieke wijze tupels in een tabel identificeren en mag niet null zijn. De primaire sleutel wordt in het ER-model aangegeven door het attribuut te onderstrepen.

• Een kandidaat-sleutel wordt door de ontwerper geselecteerd om tupels in een tabel op unieke wijze te identificeren. Hij mag niet null zijn.
• Een sleutel wordt door de ontwerper van de database gekozen om te worden gebruikt als identificatiemechanisme voor de gehele verzameling entiteiten. Dit wordt de primaire sleutel genoemd. Deze sleutel wordt aangegeven door het attribuut in het ER-model te onderstrepen.

In het volgende voorbeeld is EID de primaire sleutel:

Employee(EID, Voornaam, Achternaam, SIN, Adres, Telefoon, Geboortedatum, Salaris, DepartementID)

Secundaire sleutel

Een secundaire sleutel is een attribuut dat strikt voor opvraagdoeleinden wordt gebruikt (kan samengesteld zijn), bijvoorbeeld: Telefoon en Achternaam.

Alternatieve sleutel

Alternatieve sleutels zijn alle kandidaatsleutels die niet als primaire sleutel worden gekozen.

Foriginele sleutel

Een foreign key (FK) is een attribuut in een tabel dat verwijst naar de primaire sleutel in een andere tabel OF het kan null zijn. Zowel de foreign key als de primary key moeten van hetzelfde gegevenstype zijn.

In het onderstaande voorbeeld van de database COMPANY is DepartmentID de foreign key:

Employee(EID, Voornaam, Achternaam, SIN, Adres, Telefoon, Geboortedatum, Salaris, DepartmentID)

Nulls

Een null is een speciaal symbool, onafhankelijk van het gegevenstype, dat ofwel onbekend ofwel niet van toepassing betekent. Het betekent niet nul of blanco. Kenmerken van nulls zijn onder meer:

• Geen gegevensinvoer
• Niet toegestaan in de primaire sleutel
• Moet worden vermeden in andere attributen
• Kan vertegenwoordigen
  • Een onbekende attribuutwaarde
  • Een bekende, maar ontbrekende, attribuutwaarde
  • Een “niet van toepassing zijnde” voorwaarde
• Kan problemen veroorzaken wanneer functies als COUNT, AVERAGE en SUM worden gebruikt
• Kan logische problemen veroorzaken wanneer relationele tabellen worden gekoppeld

NOTE: Het resultaat van een vergelijkingsbewerking is null als een van beide argumenten null is. Het resultaat van een rekenkundige bewerking is null als een van beide argumenten null is (behalve functies die nulls negeren).

Voorbeeld van hoe null kan worden gebruikt

Gebruik de salaristabel (Salary_tbl) in figuur 8.6 om een voorbeeld te volgen van hoe null kan worden gebruikt.

Om te beginnen zoekt u alle werknemers (emp#) in Verkoop (onder de kolom Functienaam) waarvan het salaris plus commissie hoger is dan 30.000.

• SELECT emp# FROM Salary_tbl
• WAAR jobName = Sales AND
• (commissie + salaris) > 30.000 -> E10 en E12

Dit resultaat bevat niet E13 vanwege de null-waarde in de kolom commissie. Om er zeker van te zijn dat de rij met de null-waarde wordt opgenomen, moeten we naar de individuele velden kijken. Door commissie en salaris voor werknemer E13 op te tellen, zal het resultaat een null waarde zijn. De oplossing wordt hieronder getoond.

Relaties

Relaties zijn de lijm die de tabellen bij elkaar houdt. Ze worden gebruikt om gerelateerde informatie tussen tabellen te verbinden.

De sterkte van relaties is gebaseerd op hoe de primaire sleutel van een gerelateerde entiteit is gedefinieerd. Er is sprake van een zwakke, of niet-identificerende, relatie als de primaire sleutel van de verwante entiteit geen primaire sleutelcomponent van de bovenliggende entiteit bevat. Voorbeelden van bedrijfsdatabases zijn:

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

Een sterke, of identificerende, relatie bestaat als de primaire sleutel van de gerelateerde entiteit de primaire sleutelcomponent van de bovenliggende entiteit bevat. Voorbeelden zijn:

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

Types of Relationships

Hieronder vindt u beschrijvingen van de verschillende soorten relaties.

Een-op-veel (1:M) relatie

Een-op-veel (1:M) relatie zou de norm moeten zijn in elk relationeel database-ontwerp en komt voor in alle relationele database-omgevingen. Bijvoorbeeld, een afdeling heeft veel werknemers. Figuur 8.7 toont de relatie van een van deze werknemers tot de afdeling.

Eén-op-één-relatie (1:1)

Een één-op-één-relatie (1:1) is de relatie van één entiteit met slechts één andere entiteit, en omgekeerd. Het zou zeldzaam moeten zijn in elk relationeel databaseontwerp. In feite kan het erop wijzen dat twee entiteiten in feite in dezelfde tabel thuishoren.

Een voorbeeld uit de COMPANY-database is dat één werknemer is gekoppeld aan één echtgenoot, en één echtgenoot is gekoppeld aan één werknemer.

Vele tot vele (M:N) relaties

Voor een vele tot vele relatie moet u de volgende punten in overweging nemen:

• Het kan niet als zodanig in het relationele model worden geïmplementeerd.
• Het kan worden veranderd in twee 1:M relaties.
• Het kan worden geïmplementeerd door op te splitsen om een reeks van 1:M-relaties te produceren.
• Het betreft de implementatie van een samengestelde entiteit.
• Het creëert twee of meer 1:M-relaties.
• De samengestelde entiteittabel moet ten minste de primaire sleutels van de oorspronkelijke tabellen bevatten.
• De koppeltabel bevat meerdere exemplaren van de vreemde-sleutelwaarden.
• Extra attributen kunnen naar behoefte worden toegewezen.
• Het kan problemen voorkomen die inherent zijn aan een M:N-relatie door een samengestelde entiteit of bridge-entiteit te maken. Een werknemer kan bijvoorbeeld aan veel projecten werken OF een project kan veel werknemers hebben die eraan werken, afhankelijk van de bedrijfsregels. Of, een student kan vele klassen hebben en een klas kan vele studenten bevatten.

Figuur 8.8 toont nog een ander aspect van de M:N relatie waar een werknemer verschillende startdata heeft voor verschillende projecten. Daarom hebben we een JOIN-tabel nodig die de EID, Code en StartDate bevat.

Voorbeeld van het in kaart brengen van een M:N binair relatietype

• Voor elke M:N binaire relatie, identificeer twee relaties.
• A en B vertegenwoordigen twee entiteittypen die deelnemen aan R.
• Maak een nieuwe relatie S om R weer te geven.
• S moet de PK’s van A en B bevatten. Deze kunnen samen de PK in de tabel S zijn OF deze kunnen samen met een ander eenvoudig attribuut in de nieuwe tabel R de PK zijn.
• De combinatie van de primaire sleutels (A en B) vormt de primaire sleutel van S.

Unary relatie (recursief)

Een unary relatie, ook wel recursief genoemd, is er een waarin een relatie bestaat tussen occurrences van dezelfde entity set. In deze relatie zijn de primaire en de vreemde sleutel dezelfde, maar zij vertegenwoordigen twee entiteiten met verschillende rollen. Zie figuur 8.9 voor een voorbeeld.

Voor sommige entiteiten in een unaire relatie kan een aparte kolom worden gemaakt die verwijst naar de primaire sleutel van dezelfde entiteitenverzameling.

Ternaire relaties

Een ternaire relatie is een relatietype waarbij sprake is van veel-op-veel relaties tussen drie tabellen.

Refereer naar afbeelding 8.10 voor een voorbeeld van het toewijzen van een ternair relatietype. Opmerking n-ary betekent meerdere tabellen in een relatie. (Vergeet niet, N = veel.)

• Voor elke n-ary (> 2) relatie, creëert u een nieuwe relatie om de relatie weer te geven.
• De primaire sleutel van de nieuwe relatie is een combinatie van de primaire sleutels van de deelnemende entiteiten die de N (veel) kant houden.
• In de meeste gevallen van een n-ary relatie hebben alle deelnemende entiteiten een many-kant.

Attributie

Dit hoofdstuk van Database Design (inclusief afbeeldingen, tenzij anders vermeld) is een afgeleide van Data Modeling Using Entity-Relationship Model door Nguyen Kim Anh met een licentie onder Creative Commons Naamsvermelding Licentie 3.0 licentie

Het volgende materiaal is geschreven door Adrienne Watt:

1. Nulls sectie en voorbeeld
2. Key Terms
3. Exercises