Разработка отношений 1:1 и 1: m в SQL Server

Ответ 1

Любые отношения требуют, чтобы "родительская" таблица (с одной стороны) имела первичный (или уникальный) ключ (PK), который однозначно идентифицирует каждую строку, а таблица "child" (другая сторона) имеет внешний ключ столбец или столбцы, которые должны быть заполнены значениями, которые совпадают с существующим значением [s] основного ключа в родительской таблице. Если вам требуется отношение от одного до нескольких (1-М), то внешний ключ должен быть обычным атрибутом (столбцом или столбцами) в дочерней таблице, который может повторяться (может быть много строк с одинаковым значением)

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

Отношения 1-1 эффективно разбивают атрибуты (столбцы) таблицы на две таблицы. Это называется вертикальной сегментацией. Это часто делается для подклассификации объектов таблицы или, по другой причине, если шаблоны использования в столбцах в таблице указывают на то, что некоторые из столбцов должны быть доступны значительно чаще, чем остальные столбцы. (Скажем, один или два столбца будут доступны 1000 раз в секунду, а остальные 40 столбцов будут доступны только один раз в месяц). Таким образом, разделение таблицы таким образом позволит оптимизировать шаблон хранения для этих двух разных запросов.

Sub-причислять. Вышеописанное фактически создает отношение 1 к нулю или одно отношение, которое используется для так называемого отношения подкласса или подтипа. Это происходит, когда у вас есть два разных объекта, которые имеют большое количество атрибутов, но у одного из объектов есть дополнительные атрибуты, которые другим не нужны. Хорошим примером могут быть сотрудники и SalariedEmployees. Таблица Employee будет иметь все атрибуты, которыми обладают все сотрудники, а таблица SalariedEmployee будет существовать в отношениях (1-0/1) с сотрудниками с дополнительными атрибутами (Salary, AnnualVacation и т.д.), Которые нужны только работникам, работающим с зарплатой.

Если вам действительно нужны отношения 1-1, вам нужно добавить еще один механизм, гарантирующий, что в дочерней таблице всегда будет одна запись для каждой записи/строки в родительской таблице. Как правило, единственный способ сделать это - обеспечить это в коде, используемом для вставки данных (либо в триггер, хранимую процедуру или код за пределами базы данных). Это связано с тем, что если вы добавили ограничения ссылочной целостности на две таблицы, которые требуют, чтобы строки всегда были в обоих, было бы невозможно добавить строку в одну из них без нарушения одного из ограничений, и вы не можете добавить строку для обоих таблицы в то же время.

Ответ 2

Индивидуальное отношение

Create Table ParentTable
    (
    PrimaryKeyCol ... not null Primary Key
    , ...
    )

Create Table ChildTable
    (
    , ForeignKeyCol ... [not] null [Primary Key, Unique]
    , ...
    , Constraint FK_ChildTable_ParentTable
        Foreign Key ( ForeignKeyCol )
        References ParentTable( PrimaryKeyCol )
    )

В этом случае у меня никогда не может быть более одной строки в ChildTable для данного значения первичного ключа ParentTable. Обратите внимание, что даже в отношениях "один-к-одному" одной из таблиц является "родительская" таблица. Что отличает отношения "один-к-одному" от отношений "один-ко-многим" исключительно с точки зрения реализации, является ли значение внешнего ключа ChildTable уникальным или основным ключом.

Отношения "один-ко-многим"

Create Table ParentTable
    (
    PrimaryKeyCol ... not null Primary Key
    , ...
    )

Create Table ChildTable
    (
    , ForeignKeyCol ... [not] null 
    , ...
    , Constraint FK_ChildTable_ParentTable
        Foreign Key ( PrimaryKeyCol )
        References ParentTable( PrimaryKeyCol )
    )

В этом случае я могу иметь несколько строк в ChildTable для данного значения первичного ключа ParentTable.

Ответ 3

Отношения 1:1 существуют, когда таблица A и таблица B существуют только один раз в отношении друг к другу. Пример: У студента есть 1 запись студента-хозяина. Студентом будет таблица A и запись в таблице B. Таблица B будет содержать внешний ключ для записи ученика в таблице A (и, возможно, наоборот)

Отношение 1: m существует, где таблица A может ссылаться или привязываться к множеству записей в таблице B. Пример: студент может взять несколько книг из библиотеки. Студент снова будет таблицей A, а книга может быть записью в таблице B. Запись в таблице B будет содержать внешний ключ для того, кто проверил книгу, и многие книги могут ссылаться на одного и того же ученика.