Метод моделирования "Свод данных"

Алгоритм построения модели "Свод данных" (Data Vault)

При создании модели "Свод данных" необходимо сначала создать сущности и описать их атрибуты, а затем установить связи между ними. Сущности должны создаваться в следующем порядке.

1. Сущности-концентраторы, которые должны содержать бизнес-ключи предметной области.
2. Сущности-связи для поддержки взаимосвязей между бизнес-ключами, т. е. информация о деятельности организации в контексте бизнес-ключей.
3. Сущности-сателлиты для описания полной картины деятельности организации с точки зрения бизнес-процедур.
4. Сущности "Момент времени" для обеспечения поиска моментов времени изменения описательной информации.

При создании связей в структуре модели "Свод данных" следует соблюдать правила поддержки ссылочной целостности (referential integrity).

1. Ключи концентраторов не могут мигрировать в другие концентраторы, т.е. не поддерживается отношение "родитель-потомок" для концентраторов.
2. Концентраторы взаимодействуют между собой через сущности-связи.
3. Сущность-связь может быть использована для связи более двух концентраторов.
4. Сущности-связи могут быть связаны друг с другом.
5. Сущности-связи должны связывать, по крайней мере, два концентратора.
6. Суррогатные ключи могут использоваться для концентраторов и связей.
7. Ключи концентраторов всегда мигрируют.
8. Бизнес-ключи концентраторов никогда не изменяются, так же, как и их первичные ключи.
9. Сателлиты могут связываться с концентраторами и сущностями-связями.
10. Могут быть использованы стандартные таблицы временных меток (standalone table), такие как календарь, время, код и описание.
11. Сателлиты всегда содержат либо временную метку загрузки, либо числовой указатель на временную метку загрузки (на стандартные таблицы временных меток)
12. Сущности-связи могут иметь суррогатные ключи.
13. Если концентратор имеет более двух сателлитов, то может быть создана сущность "Момент времени".
14. В сателлитах не должно быть строк-дубликатов.
15. Данные в сателлитах разделяются по типу информации или по скорости изменения.

Изменения в данных собираются в сателлитах. Если размер сателлитов растет очень быстро, то можно создать два новых сателлита, чтобы ограничить такой процесс роста. Данные в новых сателлитах могут разделяться по типу информации или по скорости изменения.

Концентраторы хранят бизнес-ключи основных направлений деятельности организации (предметных областей). Обычно бизнес-ключи меняются очень редко. Первичный ключ концентратора используется в сущностях-связях, чтобы представить операции основных направлений деятельности.

Теперь рассмотрим применение вышеизложенного алгоритма на учебном примере, т.е. построим модель "Свод данных" для схемы учебного примера.

Пример проектирования модели "Свод данных"

Учебная база данных

Рассмотрим БД Northwind, которая разработана Microsoft в учебных целях. Ее модель данных приведена на рис. 18.8.

Как видно из рисунка, для этой модели характерно использование нестандартных типов данных: bit, ntext, image, money. Использование нестандартных типов данных может привести к проблемам преобразования данных, если для создания ХД будет использована другая СУБД, чем в OLTP-системе. В нашем случае "Свод данных" будет построен на основе той же СУБД, что и OLTP, а именно для MS SQL Server 2008 компании MicroSoft.

увеличить изображение
Рис. 18.8. Схема учебной БД в третьей нормальной форме

Процесс моделирования "Свода данных"

Рассмотрим процесс преобразования нормализованной модели примера ( рис. 18.7) в модель "Свод данных". Процесс преобразования, как было рассмотрено в предыдущих разделах, включает следующие этапы.

1. Идентификация бизнес-ключей и создание набора суррогатных ключей, формирование концентраторов модели.
2. Идентификация взаимосвязей между таблицами, которые должны поддерживаться, формирование сущностей-связей модели.
3. Идентификация описательной информации, формирование сателлитов модели.
4. Нормализация (перегруппировка) сателлитов либо по скорости изменения, либо по типу информации. Добавление сущностей-мостов и сущностей "Момент времени".

Отметим сразу же, что для модели учебного примера добавление сущностей-мостов и сущностей "Момент времени" не требуется.

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

Теперь перейдем к реализации пунктов 1-3 процесса формирования модели "Свод данных" для учебного примера.

Формирование сущностей-концентраторов

Будем следовать рассмотренному нами процессу построения модели "Свод данных". Сначала идентифицируем бизнес-ключи и поместим их в сущности-концентраторы стандартной структуры. Так как концентраторы являются по определению списком бизнес-ключей, важно разместить их вместе с суррогатными ключами, если такие существуют в модели.

Проведя исследование модели на рис. 18.8 (уникальные индексы, запросы к данным и т.д.), мы сможем построить следующие группы бизнес-ключей/суррогатных ключей и определим сущности, претендующие на роль концентраторов в модели "Свод данных".

Таблица "Категории" ( Categories ) имеет бизнес-ключ "Имя категории" ( CategoryName ) и суррогатный ключ "Идентификатор категории" ( CategoryID ). Они будут составными элементами сущности-концентратора "Концентратор_Категория" ( HUB_Category ).

Таблица "Товары" ( Products ) имеет бизнес-ключ "Наименование товара" ( ProductName ) и суррогатный ключ "Идентификатор товара" ( ProductID ). Они будут составными элементами сущности-концентратора "Концентратор_Товар" ( HUB_Product ).

Таблица "Поставщики" ( Suppliers ) имеет бизнес-ключ "Наименование поставщика" ( SupplierName ) и суррогатный ключ "Идентификатор поставщика" ( SupplierID ). Они будут составными элементами сущности-концентратора "Концентратор_Поставщик" ( HUB_Supplier ).

Таблица "Позиции заказа" ( Order Details ) не имеет бизнес-ключа, она не представляет бизнес-процесс и, следовательно, не может иметь свой концентратор.

Таблица "Заказы" ( Orders ) имеет суррогатный ключ, который может быть, а может и не быть связан с бизнес-ключом. Это зависит от бизнес-требований. Эта таблица является транзакционной по своей природе и является кандидатом более на сущность-связь, чем на концентратор.

Таблица "Грузоперевозчики" ( Shippers ) имеет бизнес-ключ "Наименование компании" ( CompanyName ) и суррогатный ключ "Идентификатор грузоперевозчика" ( ShipperID ). Они будут составными элементами сущности-концентратора "Концентратор_Перевозчик" ( HUB_Shippers ). Заметим, что если бизнес-требования требуют интеграции компаний-грузоперевозчиков, то поле "Наименование компании" ( CompanyName ) может быть использовано как бизнес-ключ. Однако если бизнес-требования требуют, чтобы грузоперевозчики поддерживались в системе отдельно друг от друга, то указанное поле не является достаточно описательным для бизнес-процесса и должно быть заменено полем "Наименование грузоперевозчика" ( ShipperName ).

Таблица "Покупатели" ( Customers ) имеет бизнес-ключ "Наименование компании" ( CompanyName ) и суррогатный ключ "Идентификатор покупателя" ( CustomerID ). Они будут составными элементами сущности-концентратора "Концентратор_Покупатели" ( 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 ).

Сейчас мы можем сформировать список сущностей-концентраторов модели, которые должны быть построены ( рис. 18.9).

• "Концентратор_Категория" - Hub_Categories
• "Концентратор_Товар" - Hub_Producst
• "Концентратор_Поставщик" - Hub_Suppliers
• "Концентратор_Перевозчик" - Hub_Shippers
• "Концентратов_Компания" - Hub_Customers
• "Концентратор_Демография_покупателей" - Hub_CustomerDemographics
• "Концентратор_Служащий" - Hub_Employees
• "Концентратор_Территория" - Hub_Territories
• "Концентратор_Регион" - Hub_Region

увеличить изображение
Рис. 18.9. Идентификация сущностей-концентраторов модели "Свод данных" для учебного примера

Для обозначения бизнес-ключей будем использовать иные наименования, чем на схеме рис. 18.8.

Рассмотрим список концентраторов на рис. 18.9. Обратим внимание на тот факт, что суррогатные ключи на схеме рис. 18.8 однозначно определяют бизнес-ключи соответствующих таблиц. Следовательно, мы можем заменить в концентраторах бизнес-ключи на соответствующие им суррогатные ключи. Это целесообразно сделать потому, что размеры суррогатных ключей, как правило, значительно меньше, чем размеры соответствующих бизнес-ключей. Так, тип суррогатного ключа "Идентификатор категории" ( CategoryID ) есть int, что составляет 2 байта, в противоположность 16 байтам бизнес-ключа "Имя категории" (CategoryName) (в концентраторе поле CTO_NAME ). Это обычная практика при проектировании ХД.

На рис. 18.10 приведен окончательный список сущностей-концентраторов для модели учебного примера.

Таблица концентратора для сущности-концентратора создается командой CREATE TABLE, как показано для концентратора "Концентратор_Категории" ( Hub_Categories ) ниже. Аналогично в БД создаются остальные концентраторы модели.

CREATE TABLE Hub_Categories (
    CategoryID int NOT NULL,
    CTO_LOAD_DTS datatime NOT NULL,
    CTO_REC_SRC nvarchar(20) NOT NULL,
PRIMARY KEY (CTO_SEQ_ID)
);
CREATE UNIQUE INDEX Hub_Categories_idx
ON Hub_Categories (CategoryID);

увеличить изображение
Рис. 18.10. Список сущностей-концентраторов модели "Свод данных" для учебного примера

Теперь мы можем перейти к формированию сущностей-связей для модели "Свод данных" учебного примера.