Читайте также:
|
Связи представляют бизнес-процессы, это клей, который связывает бизнес ключи друг с другом. Они описывают взаимодействия и взаимоотношения между ключевыми элементами. Важно понимать, что бизнес ключи и отношения между ними – наиболее важные элементы в хранилище. Без этой информации, данные трудно понять. Обычно транзакции и таблицы, хранящие отношения «многие ко многим», являются хорошей основой для создания таблиц Связей. Наряду с этим, любая таблица, не имеющая соответствующего бизнес ключа, подходит для сущности Связь. Таблицы с единственным атрибутивным первичным ключом могут быть хорошим Хабом, однако требуется все же наличие бизнес ключа. В случае с таблицей Orders бизнес-ключ не существует. Таблицы Связи в нашей модели следующие:
· Таблица Order Details: таблица с отношениями многие ко многим, прекрасная основа для таблицы Связи. Будет создана таблица LNK_OrderDetails.
· Таблица Orders: таблица с отношениями многие ко многим, содержащая родительские транзакции для таблицы Order Details, прекрасная основа для таблицы Связи. Будет создана таблица LNK_Orders. Однако, заметьте: эта таблица также может подходить, либо не подходить, для создания таблицы хаба: Hub_Orders, это завист от бизнеса и желания отслеживать значение Order ID. В нашем случае будет создана таблица Связи.
· Таблица CustomerCustomerDemo: таблица с отношениями многие ко многим, прекрасная основа для таблицы Связи. Будет создана таблица LNK_CustomerCustomerDemo.
· Таблица EmployeeTerritories: таблица с отношениями многие ко многим, прекрасная основа для таблицы Связи. Будет создана таблица LNK_EmployeeTerritories.
Мы получили все Связи? Нет. Смотрите снова. Есть некоторые родительско-дочерние отношения в таблицах, которые должны стать Хабами. Хабы не должны иметь родительских отношений и не должны решать проблемы степени детализации. Анализируя таблицу Products, мы видим и CategoryID, и SupplierID. Это составит таблицу LNK_Product, включающую поля ProductID, SupplierID, и CategoryID. В настоящем хранилище данных мы создали бы суррогатный ключ для этой таблицы связи – однако в нашем случае, модель данных утверждает, что поля ProductID достаточно, чтобы представить и поставщика, и категорию (как показывает таблица OrderDetails). Никакого суррогатного ключа не требуется.
В случаях интеграции (при наличии и других источников данных), может быть необходимым поместить суррогатный ключ в нескольких таблицах связи. Существуют ли другие родительско-детские отношения, которые нуждаются в создании Связей? Да, в таблице Employees есть рекурсивные отношения. Чтобы вытащить вовне эти рекурсивные отношения, мы создадим таблицу LNK_EMPLOYEE, так, чтобы отношения «reports to» могли быть обработаны через таблицу связи. Больше нет отношений, которые должны быть решены. Пример таблицы Связи показан ниже:
Create Table LNK_PRODUCTS (
ProductID int NOT NULL,
CategoryID int NOT NULL,
SupplierID int NOT NULL,
LOAD_DATE DateTime Not Null,
RECORD_SOURCE nvarchar(12) not null,
Primary Key (ProductID),
Foreign Key (SupplierID) references HUB_Supplier,
Foreign Key (CategeoryID) references HUB_Category
)
Теперь мы можем перейти к созданию сущностей Спутников.
Дата добавления: 2014-12-15; просмотров: 21 | Поможем написать вашу работу | Нарушение авторских прав |