Hvad er et en-til-en forhold i datamodellering? Hvordan implementerer du dette forhold i en database? Eksemplerne i denne artikel vil besvare disse spørgsmål.
Der er tre typer relationer mellem enheder (tabeller) i datamodellering:
- En-til-mange-forhold (også betegnet som 1:M).
- Mange-til-mange-relationer (M:N).
- En-til-en-forhold (1:1).
Den mest almindelige type relation er en en-til-mange-relation, hvor en post i en enhed kan refereres af flere poster i en anden enhed. En anden almindelig type er et mange-til-mange forhold. Denne type relation bruges kun i logiske datamodeller. I en fysisk database skal den implementeres ved at bruge en-til-mange-relationer og en forbindelsestabel.
I denne artikel vil vi diskutere den tredje type forhold:en-til-en-forholdet . Dette er den mindst almindelige type forhold i en datamodel. Vi giver eksempler på en-til-en-relationer, viser notationen for en-til-en-relationer i et ER-diagram og diskuterer en-til-en-relationer i praksis.
Eksempler på en-til-en-forhold
For det første, hvad er et en-til-en forhold? Det er et forhold, hvor en post i én enhed (tabel) er knyttet til nøjagtig én post i en anden enhed (tabel).
Lad os se nogle eksempler fra det virkelige liv på en-til-en-forhold:
- Land – hovedstad :Hvert land har præcis én hovedstad. Hver hovedstad er hovedstaden i præcis ét land.
- Person - deres fingeraftryk . Hver person har et unikt sæt fingeraftryk. Hvert sæt fingeraftryk identificerer præcis én person.
- E-mail - brugerkonto . For mange websteder er én e-mailadresse knyttet til præcis én brugerkonto, og hver brugerkonto identificeres ved sin e-mailadresse.
- Ægtefælle – ægtefælle :I et monogamt ægteskab har hver person præcis én ægtefælle.
- Brugerprofil - brugerindstillinger . Én bruger har ét sæt brugerindstillinger. Et sæt brugerindstillinger er knyttet til præcis én bruger.
For klarhedens skyld, lad os sammenligne disse eksempler med forhold, der ikke er én-til-én:
- Land – by: Hver by er i præcis ét land, men de fleste lande har mange byer.
- Forælder – barn :Hvert barn har to forældre, men hver forælder kan have mange børn.
- Medarbejder - leder :Hver medarbejder har præcis én direkte leder eller leder, men hver leder fører normalt tilsyn med mange medarbejdere.
Betegnelse af et en-til-en-forhold i et ER-diagram
En en-til-en-relation i et ER-diagram betegnes, som alle relationer, med en linje, der forbinder de to enheder. "En"-kardinaliteten er angivet med en enkelt lige linje. (Den "mange" kardinalitet er angivet med et kragefodssymbol.)
En-til-en-forholdet mellem land og hovedstad kan betegnes således:
De vinkelrette lige linjer betyder "obligatorisk ”. Dette diagram viser, at det er obligatorisk for en hovedstad at have et land, og det er obligatorisk for et land at have en hovedstad.
En anden mulighed er, at en eller begge sider af forholdet er valgfri . En valgfri side er markeret med en åben cirkel. Dette diagram siger, at der er et en-til-en forhold mellem en person og deres fingeraftryk. En person er obligatorisk (fingeraftryk skal tildeles til en person), men fingeraftryk er valgfrit (en person har muligvis ingen fingeraftryk tildelt i databasen).
En-til-en-relationer i en fysisk database
Der er et par måder at implementere en en-til-en-relation i en fysisk database.
Primær nøgle som fremmednøgle
En måde at implementere en en-til-en relation i en database på er at bruge den samme primærnøgle i begge tabeller. Rækker med samme værdi i den primære nøgle er relaterede. I dette eksempel er Frankrig et country med id 1 og dens hovedstad er i tabellen capital under id 1.
country
| id | navn |
|---|---|
| 1 | Frankrig |
| 2 | Tyskland |
| 3 | Spanien |
capital
Teknisk set skal en af de primære nøgler markeres som fremmednøgle, som i denne datamodel:
Den primære nøgle i tabel capital er også en fremmednøgle, som refererer til id-kolonnen i tabellen land . Siden capital.id er en primær nøgle, er hver værdi i kolonnen unik, så hovedstaden kan højst referere til ét land. Det skal også referer til et land – det er en primær nøgle, så den kan ikke stå tom.
Yderligere fremmednøgle med unik begrænsning
En anden måde, hvorpå du kan implementere en en-til-en-relation i en database, er at tilføje en ny kolonne og gøre den til en fremmednøgle.
I dette eksempel tilføjer vi kolonnen country_id i tabellen capital . Hovedstaden med id 1, Madrid, er forbundet med land 3, Spanien.
country
| id | navn |
|---|---|
| 1 | Frankrig |
| 2 | Tyskland |
| 3 | Spanien |
capital
| id | navn | country_id |
|---|---|---|
| 1 | Madrid | 3 |
| 2 | Berlin | 2 |
| 3 | Paris | 1 |
Teknisk set er kolonnen country_id skal være en fremmednøgle, der refererer til id kolonne i tabellen country . Da du ønsker, at hver hovedstad skal være knyttet til præcis ét land, bør du lave fremmednøglekolonnen country_id enestående.
En-til-en-relationer i praksis
Få en-til-en-relationer sidste
En-til-en-forhold er den mindst hyppige forholdstype. En af grundene til dette er, at meget få en-til-en-forhold eksisterer i det virkelige liv. De fleste en-til-en-forhold er kun en-til-en i en periode. Hvis din model indeholder en tidskomponent og fanger ændringshistorik, som det meget ofte er tilfældet, vil du have meget få en-til-en-relationer.
Et monogamt forhold kan gå fra hinanden, eller en af partnerne kan dø. Hvis du modellerer virkeligheden af monogame forhold (såsom ægteskaber eller civile foreninger) over tid, bliver du sandsynligvis nødt til at modellere det faktum, at de kun varer i en vis periode.
Man skulle tro, at en person og deres fingeraftryk aldrig ændrer sig. Men hvad hvis personen mister en finger, eller fingeren er slemt forbrændt? Deres fingeraftryk kan ændre sig. Det er ikke et meget hyppigt scenarie; stadig, i nogle modeller skal du muligvis tage højde for dette.
Selv noget tilsyneladende så stabilt som lande og deres hovedstæder ændrer sig over tid. For eksempel plejede Bonn at være hovedstaden i Vesttyskland (Bundesrepublik Deutschland) efter Anden Verdenskrig, da Berlin var en del af Østtyskland. Dette ændrede sig efter den tyske genforening; hovedstaden i Tyskland (Bundesrepublik Deutschland) er nu Berlin. Om du bør eller ikke bør tage højde for dette, afhænger af din virksomheds virkelighed og den applikation, du arbejder på.
Et gennemførligt 1:1-scenarie:Valgfri dele af tabellen
Jeg kan komme i tanke om et muligt scenarie for et rigtigt en-til-en-forhold:valgfri dele af en tabel. Forestil dig, at du har tabellen bruger med brugerdata. Tabellen indeholder generelle brugeroplysninger, såsom brugernes navne, e-mailadresser og tilmeldingsdatoer. Den indeholder også brugerindstillinger, såsom farvetemaet eller automatisk login for den pågældende app. De fleste brugere har dog ingen brugerindstillinger; de bruger standardindstillingerne.
user
| id | navn | tilmeldingsdato | tema | autolog | |
|---|---|---|---|---|---|
| 1 | Nathanael Talbot | [email protected] | 2020-12-12 | mørkt | sandt |
| 2 | Talitha Yates | [email protected] | 2020-12-14 | ||
| 3 | Markus Weir | [email protected] | 2020-12-15 | lys | falsk |
| 4 | Nathalie Hays | [email protected] | 2020-12-18 | ||
| 5 | Maurice Kirke | [email protected] | 2020-12-20 | ||
| 6 | Arwa Valdez | [email protected] | 2020-12-21 |
Der er mange tomme felter i denne tabel. Du kan opdele user tabel i to tabeller:user og user_settings , som indeholder oplysninger om brugerindstillinger for dem, der valgte at vælge dem.
user
| id | navn | tilmeldingsdato | tema | autolog | |
|---|---|---|---|---|---|
| 1 | Nathanael Talbot | [email protected] | 2020-12-12 | mørkt | sandt |
| 2 | Talitha Yates | [email protected] | 2020-12-14 | ||
| 3 | Markus Weir | [email protected] | 2020-12-15 | lys | falsk |
| 4 | Nathalie Hays | [email protected] | 2020-12-18 | ||
| 5 | Maurice Kirke | [email protected] | 2020-12-20 | ||
| 6 | Arwa Valdez | [email protected] | 2020-12-21 |
user_settings
| bruger_id | tema | autolog |
|---|---|---|
| 1 | mørkt | sandt |
| 3 | lys | falsk |
Opdeling af data i to tabeller gør tabelforespørgsel mere kompleks:du skal sammenføje data fra begge tabeller. På den anden side er den vigtigste bruger tabellen er nemmere at administrere.
Få mere at vide om databaserelationer
En en-til-en-relation er en relation, hvor en post i én tabel er knyttet til nøjagtig én post i en anden tabel. Denne type forhold er sjælden i det virkelige liv. Hvis du inkluderer tid i din datamodel, bliver mange en-til-en-relationer til en-til-mange eller mange-til-mange relationer. Det mest almindelige scenarie for at bruge en en-til-en-relation i en database er at opdele en tabel i to:en med obligatoriske kolonner, den anden med valgfrie kolonner.
Hvis du kunne lide denne artikel, så tjek andre artikler om en-til-mange og mange-til-mange forhold på vores blog.
Hvis du er studerende, der tager databasekurser, skal du sørge for at oprette en gratis akademisk konto i Vertabelo, vores online ER-diagramtegneværktøj. Vertabelo giver dig mulighed for at tegne logiske og fysiske ER-diagrammer direkte i din browser. Det understøtter PostgreSQL, SQL Server, Oracle, MySQL, Google BigQuery, Amazon Redshift og andre relationelle databaser. Prøv det og se, hvor nemt det er at komme i gang!