Vad är en en-till-en-relation i datamodellering? Hur implementerar man denna relation i en databas? Exemplen i den här artikeln kommer att besvara dessa frågor.
Det finns tre typer av relationer mellan enheter (tabeller) i datamodellering:
- En-till-många-relationer (även betecknad som 1:M).
- Många-till-många-relationer (M:N).
- En-till-en-relationer (1:1).
Den vanligaste typen av relation är en en-till-många-relation, där en post i en enhet kan refereras av flera poster i en annan enhet. En annan vanlig typ är ett många-till-många-förhållande. Denna typ av relation används endast i logiska datamodeller. I en fysisk databas måste den implementeras genom att använda en-till-många-relationer och en kopplingstabell.
I den här artikeln kommer vi att diskutera den tredje typen av relationer:en-till-en-relationen . Detta är den minst vanliga typen av relation i en datamodell. Vi ger exempel på en-till-en-relationer, visar notationen för en-till-en-relationer i ett ER-diagram och diskuterar en-till-en-relationer i praktiken.
Exempel på en-till-en-relationer
För det första, vad är en en-till-en relation? Det är en relation där en post i en enhet (tabell) är associerad med exakt en post i en annan enhet (tabell).
Låt oss se några verkliga exempel på en-till-en-relationer:
- Land – huvudstad :Varje land har exakt en huvudstad. Varje huvudstad är huvudstad i exakt ett land.
- Person - deras fingeravtryck . Varje person har en unik uppsättning fingeravtryck. Varje uppsättning fingeravtryck identifierar exakt en person.
- E-post – användarkonto . För många webbplatser är en e-postadress kopplad till exakt ett användarkonto och varje användarkonto identifieras av sin e-postadress.
- Maka - make :I ett monogamt äktenskap har varje person exakt en make.
- Användarprofil – användarinställningar . En användare har en uppsättning användarinställningar. En uppsättning användarinställningar är kopplad till exakt en användare.
För tydlighetens skull låt oss kontrastera dessa exempel med relationer som inte är en-till-en:
- Land – stad: Varje stad ligger i exakt ett land, men de flesta länder har många städer.
- Förälder – barn :Varje barn har två föräldrar, men varje förälder kan ha många barn.
- Anställd - chef :Varje anställd har exakt en omedelbar chef eller chef, men varje chef leder vanligtvis många anställda.
Beteckna en en-till-en relation i ett akutdiagram
En en-till-en relation i ett ER-diagram betecknas, som alla relationer, med en linje som förbinder de två enheterna. "En"-kardinaliteten betecknas med en enda rak linje. (Den "många" kardinaliteten betecknas med en kråkfotssymbol .)
En-till-en-relationen mellan land och huvudstad kan betecknas så här:
De vinkelräta räta linjerna betyder "obligatorisk ”. Det här diagrammet visar att det är obligatoriskt för en huvudstad att ha ett land och det är obligatoriskt för ett land att ha en huvudstad.
En annan möjlighet är att en eller båda sidorna av relationen är valfri . En valfri sida betecknas med en öppen cirkel. Detta diagram säger att det finns ett en-till-en-förhållande mellan en person och deras fingeravtryck. En person är obligatorisk (fingeravtryck måste tilldelas en person), men fingeravtryck är valfria (en person kan inte ha några fingeravtryck tilldelade i databasen).
En-till-en-relationer i en fysisk databas
Det finns några sätt att implementera en en-till-en-relation i en fysisk databas.
Primärnyckel som främmande nyckel
Ett sätt att implementera en en-till-en-relation i en databas är att använda samma primärnyckel i båda tabellerna. Rader med samma värde i primärnyckeln är relaterade. I det här exemplet är Frankrike ett country
med id
1 och dess huvudstad finns i tabellen capital
under id
1.
country
id | namn |
---|---|
1 | Frankrike |
2 | Tyskland |
3 | Spanien |
capital
Tekniskt sett måste en av primärnycklarna markeras som främmande nyckel, som i denna datamodell:
Den primära nyckeln i tabellen capital
är också en främmande nyckel som refererar till id-kolumnen i tabellen land . Sedan capital.id
är en primärnyckel är varje värde i kolumnen unikt, så huvudstaden kan referera till högst ett land. Det måste också referera till ett land – det är en primärnyckel, så den kan inte lämnas tom.
Ytterligare främmande nyckel med unik begränsning
Ett annat sätt du kan implementera en en-till-en-relation i en databas är att lägga till en ny kolumn och göra den till en främmande nyckel.
I det här exemplet lägger vi till kolumnen country_id
i tabellen capital
. Kapitalen med id
1, Madrid, är associerad med land 3, Spanien.
country
id | namn |
---|---|
1 | Frankrike |
2 | Tyskland |
3 | Spanien |
capital
id | namn | country_id |
---|---|---|
1 | Madrid | 3 |
2 | Berlin | 2 |
3 | Paris | 1 |
Tekniskt sett är kolumnen country_id
bör vara en främmande nyckel som refererar till id
kolumnen i tabellen country
. Eftersom du vill att varje huvudstad ska associeras med exakt ett land bör du göra kolumnen för främmande nyckel till country_id
unik.
En-till-en-relationer i praktiken
Få en-till-en-relationer sista
En-till-en-relationer är den minst frekventa relationstypen. En av anledningarna till detta är att väldigt få en-till-en-relationer existerar i verkliga livet. Dessutom är de flesta en-till-en-relationer en-till-en endast under en viss tidsperiod. Om din modell innehåller en tidskomponent och fångar förändringshistorik, vilket ofta är fallet, kommer du att ha väldigt få en-till-en-relationer.
Ett monogamt förhållande kan splittras eller en av partnerna kan dö. Om du modellerar verkligheten av monogama relationer (som äktenskap eller civila förbindelser) över tid, måste du förmodligen modellera det faktum att de bara varar under en viss period.
Man skulle kunna tro att en person och deras fingeravtryck aldrig förändras. Men vad händer om personen tappar ett finger eller fingret är svårt bränt? Deras fingeravtryck kan ändras. Det är inte ett särskilt vanligt scenario; ändå, i vissa modeller kan du behöva ta hänsyn till detta.
Även något som till synes så stabilt som länder och deras huvudstäder förändras över tid. Till exempel brukade Bonn vara huvudstad i Västtyskland (Bundesrepublik Deutschland) efter andra världskriget, när Berlin var en del av Östtyskland. Detta ändrades efter den tyska återföreningen; Tysklands huvudstad (Bundesrepublik Deutschland) är nu Berlin. Om du bör eller inte bör ta hänsyn till detta beror på din affärsverklighet och applikationen du arbetar med.
Ett genomförbart 1:1-scenario:valfria delar av tabellen
Jag kan komma på ett möjligt scenario för en verklig en-till-en-relation:valfria delar av en tabell. Föreställ dig att du har tabellen användare med användardata. Tabellen innehåller allmän användarinformation, såsom användarnas namn, e-postadresser och registreringsdatum. Den innehåller också användarinställningar, som färgtema eller automatisk inloggning för den appen. De flesta användare har dock inga användarinställningar; de använder standardinställningarna.
user
id | namn | e-post | registreringsdatum | tema | autolog |
---|---|---|---|---|---|
1 | Nathanael Talbot | [email protected] | 2020-12-12 | mörkt | sant |
2 | Talitha Yates | [email protected] | 2020-12-14 | ||
3 | Markus Weir | [email protected] | 2020-12-15 | ljus | falskt |
4 | Nathalie Hays | [email protected] | 2020-12-18 | ||
5 | Maurice Church | [email protected] | 2020-12-20 | ||
6 | Arwa Valdez | [email protected] | 2020-12-21 |
Det finns många tomma fält i den här tabellen. Du kan dela upp user
tabell i två tabeller:user
och user_settings
, som innehåller information om användarinställningar för de som valde att välja dem.
user
id | namn | e-post | registreringsdatum | tema | autolog |
---|---|---|---|---|---|
1 | Nathanael Talbot | [email protected] | 2020-12-12 | mörkt | sant |
2 | Talitha Yates | [email protected] | 2020-12-14 | ||
3 | Markus Weir | [email protected] | 2020-12-15 | ljus | falskt |
4 | Nathalie Hays | [email protected] | 2020-12-18 | ||
5 | Maurice Church | [email protected] | 2020-12-20 | ||
6 | Arwa Valdez | [email protected] | 2020-12-21 |
user_settings
användar-id | tema | autolog |
---|---|---|
1 | mörkt | sant |
3 | ljus | falskt |
Att dela upp data i två tabeller gör tabellfrågor mer komplexa:du måste sammanfoga data från båda tabellerna. Å andra sidan, den huvudsakliga användaren tabellen är enklare att hantera.
Läs mer om databasrelationer
En en-till-en-relation är en relation där en post i en tabell är associerad med exakt en post i en annan tabell. Denna typ av relation är sällsynt i verkliga livet. Om du inkluderar tid i din datamodell blir många en-till-en-relationer en-till-många eller många-till-många-relationer. Det vanligaste scenariot för att använda en en-till-en-relation i en databas är att dela upp en tabell i två:en med obligatoriska kolumner, den andra med valfria kolumner.
Om du gillade den här artikeln, kolla in andra artiklar om en-till-många- och många-till-många-relationer på vår blogg.
Om du är en student som tar databasklasser, se till att skapa ett gratis akademiskt konto i Vertabelo, vårt online ER-diagramritningsverktyg. Vertabelo låter dig rita logiska och fysiska ER-diagram direkt i din webbläsare. Den stöder PostgreSQL, SQL Server, Oracle, MySQL, Google BigQuery, Amazon Redshift och andra relationsdatabaser. Testa det och se hur lätt det är att komma igång!