Alla relationer kräver att "förälder"-tabellen (den ena sidan) har en primär (eller unik) nyckel (PK), som unikt identifierar varje rad, och "underordnad"-tabellen (den andra sidan) har en eller flera kolumner för främmande nyckel , som måste fyllas i med värden som är samma som vissa befintliga värden för den primära nyckeln i den överordnade tabellen. Om du vill ha en en till många (1-M) relation bör den främmande nyckeln vara ett vanligt attribut (kolumn eller kolumner) i den underordnade tabellen som kan upprepas (det kan finnas många rader med samma värde)
Om du vill ha ett ett till ett (1-1) förhållande bör den främmande nyckeln själv vara en primärnyckel eller ett unikt index i den underordnade tabellen som garanterar att det kan finnas högst en rad i den underordnade tabellen med det värdet.
En 1-1-relation delar effektivt upp attributen (kolumnerna) i en tabell i två tabeller. Detta kallas vertikal segmentering. Detta görs ofta för underklassning tabellentiteterna, eller, av annan anledning, om användningsmönstren på kolumnerna i tabellen indikerar att några av kolumnerna behöver nås betydligt oftare än resten av kolumnerna. (Säg att en eller två kolumner kommer att nås 1000-tals gånger per sekund och de andra 40 kolumnerna kommer bara att nås en gång i månaden). Partitionering av tabellen på detta sätt kommer att optimera lagringsmönstret för dessa två olika frågor.
Underklassning . Ovanstående skapar faktiskt en 1 till noll eller en relation, som används för vad som kallas en sub-klass eller subtyp relation. Detta inträffar när du har två olika enheter som delar ett stort antal attribut, men en av enheterna har ytterligare attribut som den andra inte behöver. Ett bra exempel kan vara Anställda , och SalariedEmployees . Anställd tabellen skulle ha alla attribut som alla anställda delar och SalariedEmployee tabellen skulle finnas i en (1-0/1) relation med anställda, med de ytterligare attributen (Lön , Årssemester etc.) som endast tjänstemän behöver.
Om du verkligen vill ha en 1-1-relation, måste du lägga till en annan mekanism för att garantera att den underordnade tabellen alltid kommer att ha en post för varje post/rad i den överordnade tabellen. I allmänhet är det enda sättet att göra detta genom att genomdriva detta i koden som används för att infoga data (antingen i en trigger, lagrad procedur eller kod utanför databasen). Detta beror på att om du lade till referensintegritetsbegränsningar på två tabeller som kräver att rader alltid finns i båda, skulle det inte vara möjligt att lägga till en rad till någon av dem utan att bryta mot en av begränsningarna, och du kan inte lägga till en rad till båda bord samtidigt.