Создание таблиц PostgreSQL + отношения-проблемы с отношениями-один к одному
поэтому я должен создать эту схему + отношения точно так, как это изображает ERD. Здесь я показываю только таблицы, с которыми у меня возникают проблемы:
поэтому я пытаюсь сделать это один к одному, но по какой-то причине, независимо от того, что я меняю, я получаю один ко многим на любой таблице с внешним ключом.
Это мой SQL для этих двух таблиц.
CREATE TABLE lab4.factory(
factory_id INTEGER UNIQUE,
address VARCHAR(100) NOT NULL,
PRIMARY KEY ( factory_id )
);
CREATE TABLE lab4.employee(
employee_id INTEGER UNIQUE,
employee_name VARCHAR(100) NOT NULL,
factory_id INTEGER REFERENCES lab4.factory(factory_id),
PRIMARY KEY ( employee_id )
);
здесь я получаю то же самое. Я не получу один к одному. отношения только один ко многим. Invoiceline является слабой сущностью.
и вот мой код для второго изображения.
CREATE TABLE lab4.product(
product_id INTEGER PRIMARY KEY,
product_name INTEGER NOT NULL
);
CREATE TABLE lab4.invoiceLine(
line_number INTEGER NOT NULL,
quantity INTEGER NOT NULL,
curr_price INTEGER NOT NULL,
inv_no INTEGER REFERENCES invoice,
product_id INTEGER REFERENCES lab4.product(product_id),
PRIMARY KEY ( inv_no, line_number )
);
Я был бы признателен за любую помощь. Спасибо.
1 ответов
One-To-one не очень хорошо представлен как тип отношений первого класса в стандартном SQL. Как и многие ко многим, что достигается с помощью таблицы соединителей и двух отношений "один ко многим", в SQL нет истинного "один к одному".
есть несколько вариантов:
создайте обычное ограничение внешнего ключа (стиль" один ко многим"), а затем добавьте
UNIQUE
ограничение на ссылочный столбец FK. Это означает, что не более одного из упомянутых значения могут отображаться в ссылочном столбце, Что делает его необязательным. Это довольно простой и довольно прощающий подход, который хорошо работает.используйте нормальное отношение FK, которое может моделировать 1:m, и пусть ваше приложение гарантирует, что это только 1: 1 на практике. Я не рекомендую это, есть только небольшой недостаток производительности записи для добавления уникального индекса FK, и это помогает обеспечить достоверность данных, найти ошибки приложения и избежать путаницы кого-то еще, кому нужно изменить схема позже.
создать взаимные внешние ключи-возможно, только если ваша база данных поддерживает отложенные ограничения внешнего ключа. Это немного сложнее для кода, но позволяет реализовать обязательные отношения один к одному. Каждый объект имеет ссылку внешнего ключа на ПК других в уникальном столбце. Одно или оба ограничения должны быть
DEFERRABLE
иINITIALLY DEFERRED
либо сSET CONSTRAINTS
вызов, так как вы должны отложить одну из проверок ограничений для настройки циклическая зависимость. Это довольно сложный прием, который не является необходимым для большинства приложений.используйте триггеры предварительной фиксации, если ваша база данных поддерживает их, поэтому вы можете убедиться, что при вставке сущности A вставляется ровно одна сущность B, и наоборот, с соответствующими проверками обновлений и удалений. Это может быть медленным и обычно ненужным, плюс многие системы баз данных не поддерживают триггеры предварительной фиксации.