Может ли быть отношение 1 к 1 для ключей с несколькими полями?

Question

Я создаю веб-приложение для управления базами данных. База данных может быть создана с использованием диаграмм ER.
Вот экран из моего приложения:

Как вы можете видеть, этот псевдо-пример показывает 4х типов дел:
1 ) Первичный ключ -> Первичный ключ (1: 1)
2) Уникальный ключ -> Уникальный ключ (1: 1)
3) Первичный ключ, состоящий из двух полей -> Первичный ключ, состоящий из двух полей (1: 1)
4) Уникальный ключ, состоящий из двух полей -> Уникальный ключ, состоящий из двух полей (1: 1)

И вот мой вопрос:
Это все верно? Интересно об этих двойных ключах ... Это действительно отношение 1 к 1?
Вообще, мне интересно и об этих первых двух случаях. Есть ли также правда?

MySQL Верстак показывает, что это не так:

Я не знаю почему, но вы можете видеть MySQL Workbench показывает, что это отношение один ко многим ...

Oracle Sql Разработчик:

Может кто-нибудь говорит мне, когда отношение 1 к 1 на самом деле является?
Документация показывает, что я имею право:
https://docs.oracle.com/cd/E26180_01/Platform.94/RepositoryGuide/html/s1204onetoonewithauxiliarytable01.html
, но диаграммы ER в MySQL Workbench и Sql Разработчик показывает что-то другое ...

SQL код из этих таблиц:

CREATE USER "Student" IDENTIFIED BY "null";

CREATE TABLE "Student".Table1 (
    PK_FK NUMBER NOT NULL
);
CREATE TABLE "Student".Table2 (
    PK NUMBER NOT NULL
);
CREATE TABLE "Student".Table3 (
    PK NUMBER NOT NULL,
    UK_FK NUMBER
);
CREATE TABLE "Student".Table4 (
    PK NUMBER NOT NULL,
    UK NUMBER
);
CREATE TABLE "Student".Table5 (
    PK_1_FK NUMBER NOT NULL,
    PK_2_FK NUMBER NOT NULL
);
CREATE TABLE "Student".Table6 (
    PK_1 NUMBER NOT NULL,
    PK_2 NUMBER NOT NULL
);
CREATE TABLE "Student".Table7 (
    UK_1_FK NUMBER,
    UK_2_FK NUMBER
);
CREATE TABLE "Student".Table8 (
    UK_1 NUMBER,
    UK_2 NUMBER
);

ALTER TABLE "Student".Table1 ADD CONSTRAINT Table1_PK PRIMARY KEY (PK_FK);
ALTER TABLE "Student".Table2 ADD CONSTRAINT Table2_PK PRIMARY KEY (PK);
ALTER TABLE "Student".Table3 ADD CONSTRAINT Table3_PK PRIMARY KEY (PK);
ALTER TABLE "Student".Table4 ADD CONSTRAINT Table4_PK PRIMARY KEY (PK);
ALTER TABLE "Student".Table5 ADD CONSTRAINT Table5_PK PRIMARY KEY (PK_1_FK, PK_2_FK);
ALTER TABLE "Student".Table6 ADD CONSTRAINT Table6_PK PRIMARY KEY (PK_1, PK_2);
ALTER TABLE "Student".Table3 ADD CONSTRAINT Table3_UK1 UNIQUE (UK_FK);
ALTER TABLE "Student".Table4 ADD CONSTRAINT Table4_UK2 UNIQUE (UK);
ALTER TABLE "Student".Table7 ADD CONSTRAINT Table7_UK3 UNIQUE (UK_1_FK, UK_2_FK);
ALTER TABLE "Student".Table8 ADD CONSTRAINT Table8_UK4 UNIQUE (UK_1, UK_2);
ALTER TABLE "Student".Table1 ADD CONSTRAINT Table1_FK1 FOREIGN KEY (PK_FK)
REFERENCES "Student".Table2 (PK);
ALTER TABLE "Student".Table3 ADD CONSTRAINT Table3_FK2 FOREIGN KEY (UK_FK)
REFERENCES "Student".Table4 (UK);
ALTER TABLE "Student".Table5 ADD CONSTRAINT Table5_FK3 FOREIGN KEY (PK_1_FK, PK_2_FK)
REFERENCES "Student".Table6 (PK_1, PK_2);
ALTER TABLE "Student".Table7 ADD CONSTRAINT Table7_FK4 FOREIGN KEY (UK_1_FK, UK_2_FK)
REFERENCES "Student".Table8 (UK_1, UK_2);

Answer 1

Это вполне возможно. Вот пример для PostgreSQL:

create table t1 (
  a int not null,
  b int not null,
  constraint uq1 (a, b),
  constraint fk1 foreign key (a, b) references t2 (a, b)
    deferrable initially deferred
);

create table t2 (
  a int not null,
  b int not null,
  constraint uq2 (a, b),
  constraint fk2 foreign key (a, b) references t1 (a, b)
    deferrable initially deferred
);

В этом случае t1 (a, b) является уникальным и ссылается на t2 (a, b), который также является уникальным. Это соотношение 1: 1 с использованием «составных ключей».

Примечание : в этом примере используются «циклические ссылки», которые являются стандартной частью SQL, но реализуется [насколько мне известно] PostgreSQL и Oracle. Это не будет работать в MySQL.

Answer 2

Отношение «один к одному» все еще является отношением «мастер-деталь». Одна таблица является владельцем идентификатора, а другая таблица ссылается на него через внешний ключ. Это шоу отношений на фотографиях MySQL Workbench и SQL Developer.

Документация показывает, что я имею право:

Вы ссылаетесь на документацию Oracle для репозитория ATG, который является специализированным инструментом для общего представления данных, но даже там. из SQL видно, что USER_TBL является первичной таблицей и «владеет» столбцом идентификатора, а JOB_TBL является вспомогательной таблицей и ссылается на идентификатор.

CREATE TABLE usr_tbl (
        id                      VARCHAR(32)     not null,
        nam_col                 VARCHAR(32)     null,
        age_col                 INTEGER null,
        primary key(id)
);

CREATE TABLE job_tbl (
        id                      VARCHAR(32)     not null references usr_tbl(id),
        function                VARCHAR(32)     null,
        title                   VARCHAR(32)     null,
        primary key(id)

Другими словами, у нас может быть USER без работы, но у нас не может быть работы без ПОЛЬЗОВАТЕЛЯ. Но ПОЛЬЗОВАТЕЛЬ может иметь только одну РАБОТУ, и одна РАБОТА принадлежит только ОДНОМУ пользователю.

Ваша диаграмма неверна, поскольку она отображает TABLE7 и TABLE8 как одноранговые узлы. Но внешние ключи не работают так. Один стол откладывается на другой. Когда я смотрю на вашу запись, я не вижу, принадлежит ли TABLE8 TABLE7 или TABLE7 принадлежит TABLE8. Тогда как на диаграммах MySQL и Oracle это совершенно ясно. Цель модели данных - прояснить структуру базы данных, а не скрыть ее.

---

Обратите внимание, что вполне возможно определить две таблицы, которые имеют внешние ключи, которые ссылаются на первичный ключ друг друга. Хитрость заключается в том, чтобы вставить в них данные. Это требует отложить ограничения внешнего ключа. Я рассматриваю отложенные ограничения как красный флаг, признак сломанной модели данных.