Создание таблиц PostgreSQL + отношения-проблемы с отношениями-один к одному

поэтому я должен создать эту схему + отношения точно так, как это изображает ERD. Здесь я показываю только таблицы, с которыми у меня возникают проблемы:

I am supposed to have ONE TO ONE but I get ONE TO MANY

поэтому я пытаюсь сделать это один к одному, но по какой-то причине, независимо от того, что я меняю, я получаю один ко многим на любой таблице с внешним ключом.

Это мой 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 является слабой сущностью.

it needs to be ONE TO ONE

и вот мой код для второго изображения.

        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, и наоборот, с соответствующими проверками обновлений и удалений. Это может быть медленным и обычно ненужным, плюс многие системы баз данных не поддерживают триггеры предварительной фиксации.