3.1 Сущность Хаб
Поскольку Хабы – список бизнес ключей, важно, чтобы держать их вместе с любыми суррогатными ключами (если суррогаты доступны). Изучив модель, мы находим следующие группы бизнес и суррогатных ключей (проверка включала уникальные индексы и запросы данных):
Таблица Categories: поле CategoryName – бизнес ключ, поле CategoryID – суррогатный ключ. Это будет основой для таблицы HUB_Category.
Таблица Products: поле ProductName – бизнес ключ, поле ProductID – суррогатный ключ. Это будет основой для таблицы HUB_Product.
Таблица Suppliers: поле SupplierName – бизнес ключ, SupplierID – суррогатный ключ. Это будет основой для таблицы HUB_Supplier.
Таблица Order Details: не имеет бизнес ключа, и не может существовать «сама по себе». Поэтому эта таблица не Хаб.
Таблица Orders: Судя по всему, имеет суррогатный ключ – который может либо являться, либо нет, бизнес ключом (в зависимости от бизнес-требований). При дальнейшем исследовании мы находим много внешних ключей. Таблица по своей природе является транзакционной, что делает ее хорошим кандидатом на Связь, а не на Хаб.
Таблица Shippers: поле CompanyName – бизнес ключ, и ShipperID – суррогатный ключ. Таблица Shippers будет основой для хаба HUB_Shippers. Если бизнес требования гласят, что требуется интеграция «компаний», то поле CompanyName в таблице Shippers может быть использована. Однако, если бизнес требования говорят, что грузоотправители должны быть сохранены отдельно, тогда название поля «CompanyName» не является достаточно описательным, и должно быть изменено на «ShipperName», чтобы соответствовать текущим соглашениям о наименовании полей.
Таблица Customers: CompanyName – бизнес ключ и CustomerID – суррогатный ключ. Таблица Customers будет основой для хаба HUB_Customers. Опять же, если интеграция желательна, то, возможно, следует создать сущность с названием «HUB_Company» (чтобы интегрировать Клиентов и Грузоотправителей).
Таблица CustomerCustomerDemo: не имеет бизнес ключа, и не может существовать «сама по себе». Поэтому будет таблицей Связью.
Таблица CustomerDemographics: на первый взгляд, таблица CustomerDesc образует суррогатный ключ из бизнес ключа и поля CustomerTypeID, однако, это также может быть Спутником хаба Клиент. Помните, что хранилище предназначается для сбора исходных данных системы, а не соблюдение правил захвата данных. В целях этого обсуждения будет построен HUB_CustomerDemographics.
Таблица Employees: поле EmployeeName – бизнес ключ и EmployeeID – суррогатный ключ. Это будет основой для таблицы HUB_Employee.
Таблица EmployeeTerritories: не представлено реального бизнес ключа, не может быть хабом, скорее всего это таблица Связи.
Таблица Territories: поле TerritoryDescription – бизнес ключ и TerritoryID – суррогатный ключ. Это будет основой для таблицы HUB_Territories.
Таблица Region: поле RegionDescription – бизнес ключ и RegionID – суррогатный ключ. Это будет основой для таблицы HUB_Region.
Как только сделан анализ каждой таблицы, мы можем создать список таблиц Хабов, которые будут построены: Hub_Category, Hub_Product, Hub_Supplier, Hub_Shippers, Hub_Customer, Hub_CustomerDemographics, Hub_Employee, Hub_Territories. Есть несколько сомнительных элементов, структуру которых в зависимости от бизнес правил можно было бы объединить. Помните, что структуры всех хабов подобны друг другу. Пример скрипта для создания таблицы Hub_Category:
Create Table Hub_Category ( CategoryID int NOT NULL, CategoryName nvarchar(15) NOT NULL, LOAD_DATE DateTime Not Null, RECORD_SOURCE nvarchar(12) not null, Primary Key (CategoryID) ) Create unique index hub_category_i1 on Hub_Category (CategoryName)
Теперь, когда мы создали структуру хабов, мы можем перейти к связям. Функция хабов – интегрировать и централизовать бизнес вокруг бизнес ключей.