Wat is een één-op-één relatie in datamodellering? Hoe implementeer je deze relatie in een database? De voorbeelden in dit artikel zullen deze vragen beantwoorden.
Er zijn drie soorten relaties tussen entiteiten (tabellen) bij gegevensmodellering:
- Een-op-veel-relaties (ook wel aangeduid als 1:M).
- Veel-op-veel-relaties (M:N).
- Een-op-een relaties (1:1).
Het meest voorkomende type relatie is een één-op-veel-relatie, waarbij naar een record in de ene entiteit kan worden verwezen door meerdere records in een andere entiteit. Een ander veelvoorkomend type is een veel-op-veel-relatie. Dit type relatie wordt alleen gebruikt in logische datamodellen. In een fysieke database moet het worden geïmplementeerd met behulp van één-op-veel-relaties en een verbindingstabel.
In dit artikel bespreken we het derde type relaties:de één-op-één-relatie . Dit is het minst voorkomende type relatie in een datamodel. We geven voorbeelden van één-op-één-relaties, tonen de notatie voor één-op-één-relaties in een ER-diagram en bespreken één-op-één-relaties in de praktijk.
Voorbeelden van één-op-één-relaties
Ten eerste, wat is een één-op-één relatie? Het is een relatie waarbij een record in de ene entiteit (tabel) is gekoppeld aan precies één record in een andere entiteit (tabel).
Laten we enkele voorbeelden uit de praktijk van één-op-één-relaties bekijken:
- Land - hoofdstad :Elk land heeft precies één hoofdstad. Elke hoofdstad is de hoofdstad van precies één land.
- Persoon - hun vingerafdrukken . Elke persoon heeft een unieke set vingerafdrukken. Elke set vingerafdrukken identificeert precies één persoon.
- E-mail - gebruikersaccount . Voor veel websites is één e-mailadres gekoppeld aan precies één gebruikersaccount en wordt elk gebruikersaccount geïdentificeerd door zijn e-mailadres.
- Echtgenoot - echtgenoot :In een monogaam huwelijk heeft elke persoon precies één echtgenoot.
- Gebruikersprofiel - gebruikersinstellingen . Eén gebruiker heeft één set gebruikersinstellingen. Eén set gebruikersinstellingen is gekoppeld aan precies één gebruiker.
Laten we voor de duidelijkheid deze voorbeelden vergelijken met relaties die niet één-op-één zijn:
- Land - stad: Elke stad ligt in precies één land, maar de meeste landen hebben veel steden.
- Ouder - kind :Elk kind heeft twee ouders, maar elke ouder kan veel kinderen hebben.
- Medewerker - manager :Elke werknemer heeft precies één directe supervisor of manager, maar elke manager geeft meestal leiding aan veel werknemers.
Een één-op-één-relatie aanduiden in een ER-diagram
Een één-op-één-relatie in een ER-diagram wordt, net als alle relaties, aangeduid met een lijn die de twee entiteiten verbindt. De "één" kardinaliteit wordt aangegeven met een enkele rechte lijn. (De kardinaliteit "veel" wordt aangegeven met een kraaienpootsymbool .)
De één-op-één relatie tussen land en hoofdstad kan als volgt worden aangeduid:
De loodrechte rechte lijnen betekenen "verplicht ”. Dit diagram laat zien dat het voor een hoofdstad verplicht is om een land te hebben en dat het voor een land verplicht is om een hoofdstad te hebben.
Een andere mogelijkheid is dat een of beide zijden van de relatie optioneel . zijn . Een optionele zijde wordt aangeduid met een open cirkel. Dit diagram zegt dat er een één-op-één relatie is tussen een persoon en zijn vingerafdrukken. Een persoon is verplicht (vingerafdrukken moeten aan een persoon worden toegewezen), maar vingerafdrukken zijn optioneel (een persoon mag geen vingerafdrukken in de database hebben).
Een-op-een-relaties in een fysieke database
Er zijn een paar manieren om een één-op-één relatie in een fysieke database te implementeren.
Primaire sleutel als externe sleutel
Een manier om een één-op-één-relatie in een database te implementeren, is door in beide tabellen dezelfde primaire sleutel te gebruiken. Rijen met dezelfde waarde in de primaire sleutel zijn gerelateerd. In dit voorbeeld is Frankrijk een country met de id 1 en de hoofdstad staat in de tabel capital onder id 1.
country
| id | naam |
|---|---|
| 1 | Frankrijk |
| 2 | Duitsland |
| 3 | Spanje |
capital
Technisch gezien moet een van de primaire sleutels worden gemarkeerd als externe sleutel, zoals in dit gegevensmodel:
De primaire sleutel in tabel capital is ook een externe sleutel die verwijst naar de id-kolom in de tabel land . Sinds capital.id is een primaire sleutel, elke waarde in de kolom is uniek, dus de hoofdstad kan naar maximaal één land verwijzen. Het moet . ook verwijzen naar een land - het is een primaire sleutel, dus deze kan niet leeg worden gelaten.
Aanvullende externe sleutel met unieke beperking
Een andere manier waarop u een één-op-één-relatie in een database kunt implementeren, is door een nieuwe kolom toe te voegen en er een externe sleutel van te maken.
In dit voorbeeld voegen we de kolom country_id . toe in de tabel capital . De hoofdletter met id 1, Madrid, wordt geassocieerd met land 3, Spanje.
country
| id | naam |
|---|---|
| 1 | Frankrijk |
| 2 | Duitsland |
| 3 | Spanje |
capital
| id | naam | country_id |
|---|---|---|
| 1 | Madrid | 3 |
| 2 | Berlijn | 2 |
| 3 | Parijs | 1 |
Technisch gezien is de kolom country_id moet een externe sleutel zijn die verwijst naar de id kolom in de tabel country . Aangezien u wilt dat elke hoofdstad aan precies één land wordt gekoppeld, moet u de kolom voor de buitenlandse sleutel country_id maken uniek.
Een-op-een-relaties in de praktijk
Weinig één-op-één-relaties als laatste
Eén-op-één relaties zijn het minst frequente relatietype. Een van de redenen hiervoor is dat er in het echte leven maar heel weinig één-op-één-relaties bestaan. Bovendien zijn de meeste één-op-één-relaties slechts voor een bepaalde periode één-op-één. Als uw model een tijdcomponent bevat en de wijzigingsgeschiedenis vastlegt, zoals vaak het geval is, heeft u weinig één-op-één-relaties.
Een monogame relatie kan uiteenvallen of een van de partners kan overlijden. Als je de realiteit van monogame relaties (zoals huwelijken of burgerlijke unies) in de loop van de tijd modelleert, moet je waarschijnlijk het feit modelleren dat ze slechts een bepaalde periode duren.
Je zou denken dat een persoon en zijn vingerafdrukken nooit veranderen. Maar wat als de persoon een vinger verliest of de vinger ernstig verbrand is? Hun vingerafdrukken kunnen veranderen. Het is niet een zeer frequent scenario; toch moet u bij sommige modellen hier rekening mee houden.
Zelfs iets dat schijnbaar zo stabiel is als landen en hun hoofdsteden veranderen in de loop van de tijd. Bonn was bijvoorbeeld de hoofdstad van West-Duitsland (Bundesrepublik Deutschland) na de Tweede Wereldoorlog, toen Berlijn nog deel uitmaakte van Oost-Duitsland. Dit veranderde na de Duitse hereniging; de hoofdstad van Duitsland (Bundesrepublik Deutschland) is nu Berlijn. Of u hier wel of geen rekening mee moet houden, hangt af van uw zakelijke realiteit en de applicatie waaraan u werkt.
Een haalbaar 1:1 scenario:optionele delen van de tabel
Ik kan één haalbaar scenario bedenken voor een echte één-op-één relatie:optionele delen van een tabel. Stel je voor dat je de tabel gebruiker . hebt met gebruikersgegevens. De tabel bevat algemene gebruikersinformatie, zoals gebruikersnamen, e-mailadressen en aanmeldingsdatums. Het bevat ook gebruikersinstellingen, zoals het kleurenthema of automatisch inloggen voor die app. De meeste gebruikers hebben echter geen gebruikersinstellingen; ze gebruiken de standaardinstellingen.
user
| id | naam | aanmeldingsdatum | thema | autologin | |
|---|---|---|---|---|---|
| 1 | Nathanael Talbot | [email protected] | 2020-12-12 | donker | waar |
| 2 | Talitha Yates | [email protected] | 2020-12-14 | ||
| 3 | Markus Weir | [email protected] | 2020-12-15 | licht | false |
| 4 | Nathalie Hays | [email protected] | 2020-12-18 | ||
| 5 | Maurice Kerk | [email protected] | 2020-12-20 | ||
| 6 | Arwa Valdez | [email protected] | 21-12-2020 |
Er zijn veel lege velden in deze tabel. Je zou de user tabel in twee tabellen:user en user_settings , die informatie bevat over gebruikersinstellingen voor degenen die ervoor hebben gekozen om ze te selecteren.
user
| id | naam | aanmeldingsdatum | thema | autologin | |
|---|---|---|---|---|---|
| 1 | Nathanael Talbot | [email protected] | 2020-12-12 | donker | waar |
| 2 | Talitha Yates | [email protected] | 2020-12-14 | ||
| 3 | Markus Weir | [email protected] | 2020-12-15 | licht | false |
| 4 | Nathalie Hays | [email protected] | 2020-12-18 | ||
| 5 | Maurice Kerk | [email protected] | 2020-12-20 | ||
| 6 | Arwa Valdez | [email protected] | 21-12-2020 |
user_settings
| user_id | thema | autologin |
|---|---|---|
| 1 | donker | waar |
| 3 | licht | false |
Het splitsen van gegevens in twee tabellen maakt het opvragen van tabellen complexer:u moet gegevens uit beide tabellen samenvoegen. Aan de andere kant, de belangrijkste gebruiker tabel is eenvoudiger te beheren.
Meer informatie over databaserelaties
Een één-op-één-relatie is een relatie waarbij een record in de ene tabel is gekoppeld aan precies één record in een andere tabel. Dit type relatie is zeldzaam in het echte leven. Als u tijd opneemt in uw gegevensmodel, worden veel één-op-één-relaties één-op-veel- of veel-op-veel-relaties. Het meest voorkomende scenario voor het gebruik van een één-op-één-relatie in een database is het splitsen van één tabel in twee:één met verplichte kolommen, de andere met optionele kolommen.
Als je dit artikel leuk vond, bekijk dan andere artikelen over een-op-veel- en veel-op-veel-relaties op onze blog.
Als je een student bent die databaselessen volgt, zorg er dan voor dat je een gratis Academic-account aanmaakt in Vertabelo, onze online tool voor het tekenen van ER-diagrammen. Met Vertabelo kunt u logische en fysieke ER-diagrammen rechtstreeks in uw browser tekenen. Het ondersteunt PostgreSQL, SQL Server, Oracle, MySQL, Google BigQuery, Amazon Redshift en andere relationele databases. Probeer het uit en zie hoe gemakkelijk het is om aan de slag te gaan!