Нормализация отношения многие ко многим в sql

У меня есть таблица продуктов, содержащая два столбца

ProductID   Desc
  1         Fan
  2         Table
  3         Bulb

У меня есть еще одна таблица, содержащая информацию о поставщиках

SupplierID    Desc
   1          ABC
   2          XYZ
   3          HJK

Теперь один поставщик может поставлять несколько продуктов, а один продукт может поставляться несколькими поставщиками. Для этого я создал другую таблицу tbl_Supplier_Product

 SupplierID    ProductID 
     1            1
     1            2
     2            1
     2            2
     2            3

Это хороший способ связать эту таблицу с таблицей поставщиков и продуктов через первичный составной ключ. В этой таблице первичный ключ будет составным ключом (SupplierID и ProductID), или я должен добавить дополнительный идентификатор строки столбца для каждой записи, а затем использовать его в качестве первичного ключа и добавить уникальное ограничение в столбцы SupplierID и ProductID.

 SupplierID    ProductID    Row ID
         1            1       1
         1            2       2
         2            1       3
         2            2       4
         2            3       5
UNIQUE CONSTRAINT(SupplierID, ProductID)

Каким будет отношение этой таблицы к таблице поставщиков? Я немного запутался здесь, потому что я добавил эту таблицу, чтобы разрешить отношения «многие ко многим» и избыточные данные, но все же кажется, что эта таблица имеет отношения «многие ко многим» с обеими таблицами ??


sql database-normalization normalization
person Abhi.Net    schedule 25.04.2013    source источник

Ответы (1)


arrow_upward
4
arrow_downward

Вам не нужен дополнительный столбец: все, что вам нужно - это составной ключ

Я бы создал уникальный индекс, противоположный PK: это полезно для многих запросов, а также предоставляет индекс FK для ProductID.

После комментария:

CREATE TABLE SupplierProduct (
    SupplierID int NOT NULL,
    ProductID int NOT NULL,

    PRIMARY KEY (SupplierID, ProductID)
);
GO
CREATE UNIQUE NONCLUSTERED INDEX IXU_ReversePK ON SupplierProduct (ProductID, SupplierID);
GO

Для большего

И также используйте это в целом, чтобы убедиться, что все ваши FK имеют индексы

SELECT  fk.name AS [Missing FK Index]
FROM    sys.foreign_keys fk
WHERE   EXISTS
        (
        SELECT  *
        FROM    sys.foreign_key_columns fkc
        WHERE   fkc.constraint_object_id = fk.object_id
                AND NOT EXISTS
                (
                SELECT  *
                FROM    sys.index_columns ic
                WHERE   ic.object_id = fkc.parent_object_id
                        AND ic.column_id = fkc.parent_column_id
                        AND ic.index_column_id = fkc.constraint_column_id
                )
        );
GO

В ERD (случайный из имеющегося у меня PowerPoint):

введите описание изображения здесь

person gbn    schedule 25.04.2013
comment
не могли бы вы уточнить, будет ли создан уникальный индекс, который также является ОБРАТНЫМ для PK: это полезно для многих запросов, а также предоставляет индекс FK для ProductID - person Abhi.Net; 25.04.2013
comment
Спасибо за объяснение, но как эта таблица будет связана с таблицей поставщиков и продуктов, если они будут показаны на диаграмме ER? от того, что я думаю, будет много ко многим. - person Abhi.Net; 25.04.2013
comment
И последнее, с этой страницы stackoverflow.com/questions/ 13499096 /, если вы посмотрите ответ, в котором говорится, что если у вас есть составной первичный ключ, то все внешние ключи, которые на него ссылаются, ДОЛЖНЫ использовать все столбцы составного первичного ключа. Это означает, что мне нужно будет добавить productID в таблицу поставщиков и идентификатор поставщика в таблицу продуктов. - person Abhi.Net; 25.04.2013
comment
Не в твоем случае. @marc_s относится к простой дочерней таблице, которая относится к единственному родителю, а единственный родитель имеет составной ключ. Это не такой уж большой случай, как ваш стол. - person gbn; 25.04.2013