2.1 База данных Northwind
База Northwind создана Microsoft и устанавливается с Microsoft SQL Server 2000. Она понятна и доступна с примерами данных. Модель данных показана ниже, на рисунке 2-1.
Первое, что настораживает в этой модели – использование нестандартных типов данных: «bit», «ntext», «image», «money». Они не очень хорошо портируются в другие реляционные базы данных. Это важный момент, который необходимо решить, потому что большинство хранилищ данных создаются не той же самой СУБД, что и оперативные OLTP система. В нашем случае Data Vault будет создано на той же самой СУБД. Другой заметный элемент в модели данных – рекурсивное отношение. Это должно немедленно сигнализировать о необходимости изменения в модели данных.
Соглашения о наименовании в модели представляются последовательными. Идентификаторы (ID) используются синонимично с первичными ключами, первичные и внешние ключи определены, нет никаких независимых таблиц, и модель, кажется, использует некоторые суррогатные и некоторые естественные ключи. Ради обсуждения, согласно бизнес требованиям необходимо загрузить все данные в хранилище и затем пополнять хранилище инкрементально-изменившимися данными.
Атрибуты могут быть классифицированы (нормализованы), такие элементы, как адрес, город, область, почтовый индекс могут быть сгруппированы. Меняются ли отдельные атрибуты быстрее, чем другие? Глядя на модель, две таблицы могут меняться больше других: «orders» (заказы) и «order details» (описание заказов). Действительно, нет метода, который поможет исследовать быстроту изменения элементов в этой модели. Обычно быстро меняющиеся элементы называются бизнес пользователями или обнаруживаются в результате аудита, использования логов или временных отметок в самих таблицах. В этом случае, ни что из этого не присутствует.
3.0 Процесс моделирования Data Vault
Для того чтобы сохранить дизайн простым и изящным, используется минимальное число компонентов, в частности: Хаб (Hub), Связь (Link) и традиционные навыки моделирования данных. Это было описано в 1-ой статье серии. Пожалуйста, обратитесь к первой статье для определения и настройки табличной структуры. В этой статье будет обсуждаться процесс преобразования вышеупомянутой модели данных в эффективное Data Vault. Шаги преобразования одной модели без интеграции следующие:
1. Выявите бизнес ключи и суррогатные ключевые группировки, смоделируйте Хабы.
2. Выявите отношения между таблицами, которые должны быть поддержаны, смоделируйте Связи.
3. Определите описательную информацию, смоделируйте Спутники.
4. Распределите (перегруппируйте) Спутники по темпам изменения или типам информации.
Для решения более чем одной модели, начинают с «мастер» системы, идентифицирующей бизнес. Постройте первую модель данных, и затем инкрементально отобразите другие модели и элементы данных в одно единое представление информации.
В архитектуре Data Vault применяются три стиля моделирования дат загрузки, и прежде чем начать моделировать, разумно будет выбрать стиль, соответствующий Вашим потребностям. Стили следующие:
1. Стандартный стиль – поле Load Date. Описан в этой и в предыдущей статьях. Легко загружать, сложнее делать запросы. При наличии у хаба более чем двух спутниковых таблиц может потребоваться дополнительная "picture table" или point-in-time таблица для хранения дельт изменений для эквивалентного соединения (equi-joins, соединения по эквивалентному условию).
2. Тип данных поля Load Date – целое число. Поле ссылается таблицу, содержащую даты загрузки. Целочисленная ссылка – автономный внешний ключ к таблице с датами загрузки и может использоваться, если использование даты не желательно. Будьте осторожны, это может вызвать трудности при перезагрузке и повторном упорядочивании ключей в хранилище. Это не рекомендуемая практика.
3. Ко всем спутникам добавляется поле Load End Date. Строки в спутнике датируются датой окончания при вставке новых строк. Это может помочь с точки зрения создания запросов и в то же время может сделать загрузку сложнее. При использовании этого стиля отпадает необходимость в создании «picture» таблицы (таблица point-in-time).
Выберите стиль, который лучше всего отвечает потребностям бизнеса, и реализуйте его в модели. Часть успешного моделирования Data Vault – последовательность. Поддерживайте стиль, который выбрали, и модель будет твердой с точки зрения обслуживания.