Skip to Content

Data Vault. Серия 2: Компоненты Data Vault

Автор(ы): 
Dan E. Linstedt
Перевод: 
Игорь Бралгин
Источник: 

Эта статья была первоначально издана на www.tdan.com, и доступна там на английском языке

Аннотация

Назначение этого документа – представить и обсудить заявленную на патент технологию под названием Data Vault™ (прим. переводчика: статья была написана в 2001 году, в предоставлении патента было отказано в январе 2005; сейчас архитектура Data Vault – общедоступна – FREE and PUBLIC DOMAIN). Data Vault™ – новый этап эволюции моделирования данных для хранилищ данных масштаба предприятия. Это – вторая статья в ряду публикаций о Data Vault. Эта статья исследует конкретный приме: преобразование базы данных Northwind (Microsoft SQL Server 2000) в Data Vault. Одной из наиболее интересных концепций сопутствующих Data Vault является объединение идей S.E.I. и CMM уровня 5. Это относится к вопросу: может ли Data Vault быть автоматически перепроектирована (reverse engineered) из существующей модели? Ответ: «Да, это возможно». Будет ли это совершенство? Нет, но алгоритм, который был разработан, создает модель Data Vault из существующей оперативной модели 3-ей нормальной формы. Дело в том, что этот процесс повторим и последователен; поэтому частично это может быть автоматизировано.

1.0 Введение

Назначение этого документа – представить и обсудить заявленную на патент технологию под названием Data Vault™ (прим. переводчика: статья была написана в 2001 году, в предоставлении патента было отказано в январе 2005; сейчас архитектура Data Vault – общедоступна – FREE and PUBLIC DOMAIN). Data Vault™ – новый этап эволюции моделирования данных для хранилищ данных масштаба предприятия. Этот документ, предназначен для аудитории, состоящей из проектировщиков данных, желающих разработать модель Data Vault.

Здесь мы сосредотачиваемся на конкретном примере: базе данных Northwind (Microsoft SQL Server 2000). Это подразумевает, что в целях обсуждения, читатель, станет обладателем, как минимум, ограниченной по времени копией СУБД SQL Server 2000. Пожалуйста, прочитайте первую статью серии, определяющую архитектуру Data Vault, чтобы узнать, что это за модель данных и как это вписывается в бизнес. В этой статье рассмотрены следующие темы:

  • Исследование модели OLTP в 3NF для преобразования.
  • Процесс моделирования хранилища Data Vault.
  • Наполнение Data Vault.
  • Выводы и заключение.

Прочитав это документ, Вы можете узнать:

  • Как компоненты Data Vault взаимодействуют друг с другом.
  • Как моделировать Data Vault.
  • Как наполнять Data Vault.
  • Как конвертировать систему OLTP из 3NF в корпоративное хранилище Data Vault (Enterprise Data Warehouse, EDW).

Давайте представим на мгновение, что возможно перепроектировать модель данных в хранилище. Что это означало бы для проекта по созданию хранилища данных? Предположим, что это можно сделать в автоматическом режиме, это было бы лучше или хуже? Что, если необходимо только подтверждение, чтобы интегрировать различные аспекты генерируемых моделей данных? Эти и многие другие вопросы приходят на ум, когда начинают рассматривать автоматизацию моделирования данных для хранилищ, особенно когда рассмотрение касается механизации инженерной работы.

Для наших целей, наличие этих функциональных возможностей, порождающих основу Data Vault, оказало огромную помощь. Модель данных Northwind была преобразована и вручную, и автоматизированным способом. При сравнении двух моделей данных были обнаружены только незначительные различия. Дальнейшая экспертиза показала, что ручное преобразование создало возможности для ошибок в таблицах Связи, где автоматизированный конвертер сохранил Связи чистыми. Некоторые из наиболее важных моментов для автоматизации процесса это: соглашения о наименованиях, соглашения об аббревиатурах и спецификация первичных / внешних ключей.

Здесь важно, что это первый шаг в применении «динамического хранилища данных», или динамического изменения модели (пожалуйста, см. мою другую статью: «Bleeding Edge Data Warehousing», которая должна выйти в журнале «Data Warehousing Fall» в 2002). Она также представила модель данных через десять минут (для этого конкретного примера), когда потребовалось около двух часов, чтобы преобразовать вручную. Затем потребовались дополнительные двадцать минут, чтобы настроить модель немного, и осуществить ее. Имейте в виду, что это - маленькая модель данных и все, что предложено автоматически изменяет только одну модель данных OLTP. Автоматизированный процесс еще не достаточно умен, чтобы интегрировать модели данных Data Vault с окончательным результатом.

Код DDL доступен на сайте: www coreintegration.com (прим. переводчика: в настоящее время уже не доступен, если у кого-то из читателей сохранился код, пришлите, пожалуйста, выложим на сайте)…

Пожалуйста, имейте в виду; что это не лучший образец Data Vault и не стоит и думать передавать такие модели клиентам. Это задумывалось только в качестве примера для ознакомления. Не стесняйтесь обращаться непосредственно ко мне с вопросами и замечаниями.

«Вы должны стремиться делать то что, по Вашему мнению, Вы не сможете сделать»,
Элеонора Рузвельт.

2.0 Исследование OLTP модели для конверсии

Некоторые модели данных OLTP могут быть конвертированы из 3-ей нормальной формы легче, чем другие. Впрочем, есть несколько особенностей, делающих процесс преобразования простым. Вот несколько моментов, которые надо выяснить:

  1. Насколько хорошо модель данных соответствует соглашениям о наименованиях? Это окажет влияние на интеграцию полей. Если поля (атрибуты) названы одинаково по всей модели, то результирующее хранилище Data Vault будет легче построить, а также легче определить, какие компоненты были переведены.
  2. Как много независимых таблиц в модели данных? Независимые таблицы обычно не очень хорошо интегрируются в Data Vault. Это вынуждает интегрировать таблицы через сравнение имен полей. Обычно эти независимые таблиц копируются в Data Vault как автономные таблицы, до тех пор, пока точки интеграции не могут быть найдены.
  3. Определены ли отношения между первичными и внешними ключами? Если ссылочная целостность была отключена в данной модели, то будет чрезвычайно трудно создать модель Data Vault. Это делает практически невозможным автоматическое преобразование, однако, засучив рукава и совершив напряженную работу (рытье в бизнес-требованиях), можно это сделать..
  4. Использует ли модель суррогатные ключи вместо натуральных ключей? Преобразованная модель данных предпочитает естественные ключи вместо суррогатных ключей. Модели, которые преобразованы вручную, требуют, чтобы проектировщик данных понял бизнес достаточно хорошо, чтобы идентифицировать бизнес ключи (естественные ключи) и их сопоставление с суррогатными ключами.
  5. Соответствует ли модель бизнес требованиям к хранилищу данных? Если есть требования интегрировать или консолидировать данные по системе OLTP (например, единственное представление клиента, или единственное представление адреса) тогда, процесс преобразования в Data Vault может быть немного сложнее. Процесс может потребовать перекрестного отображения элементов данных в целях интеграции..
  6. Можно ли разделить информацию по классу или типу данных? Другими словами, могут все адреса быть помещены в одну таблицу, все роли – в другую таблицу, все служащие, и т. д.? Разделение классов данных помогает в усилиях по интеграции. Обычно это – ручное перекрестное отображение и перегруппировка атрибутов.
  7. Насколько часто меняются атрибуты? Хранилищу Data Vault «нравится» разделять по темпам изменений. Легче смоделировать Data Vault, если есть понимание темпов изменения базовой информации.

Это только ряд предлагаемых пунктов к рассмотрению прежде, чем приступить к преобразованию модели данных. Это – далеко не полный список. Прежде всего, модель хранилища данных должна всегда следовать требованиям бизнеса, независимо от того, создается на основе чего-либо или создается с нуля. Предполагая, что был разработан подход оценочных показателей. Со временем эти показатели пункты будут шкалой сложности, когда это произойдет - она обеспечит хорошую директиву относительно «обратимости» определенной модели данных. Следующая статья охватит миграцию на схему Data Vault согласованных витрин данных и других видов 3-ей нормальной формы, адаптированных к нуждам хранилищ данных.

2.1 База данных Northwind

База Northwind создана Microsoft и устанавливается с Microsoft SQL Server 2000. Она понятна и доступна с примерами данных. Модель данных показана ниже, на рисунке 2-1.

Northwind Data Base

 

Первое, что настораживает в этой модели – использование нестандартных типов данных: «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 – последовательность. Поддерживайте стиль, который выбрали, и модель будет твердой с точки зрения обслуживания.

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)

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

3.2 Сущность Связь

Связи представляют бизнес-процессы, это клей, который связывает бизнес ключи друг с другом. Они описывают взаимодействия и взаимоотношения между ключевыми элементами. Важно понимать, что бизнес ключи и отношения между ними – наиболее важные элементы в хранилище. Без этой информации, данные трудно понять. Обычно транзакции и таблицы, хранящие отношения «многие ко многим», являются хорошей основой для создания таблиц Связей. Наряду с этим, любая таблица, не имеющая соответствующего бизнес ключа, подходит для сущности Связь. Таблицы с единственным атрибутивным первичным ключом могут быть хорошим Хабом, однако требуется все же наличие бизнес ключа. В случае с таблицей 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
)

Теперь мы можем перейти к созданию сущностей Спутников.

3.3 Сущность Спутник

Остальные поля могут меняться с течением времени – поэтому они будут размещены в Спутниках. Следующие таблицы будут созданы как Спутники: Categories, Products, Suppliers, Order Details, Orders, Customers, Shippers and Employees. Первичный ключ Спутника состоит из первичного ключа Хаба и поля LOAD_DATE. Это – составной ключ, как это и было описано в первой статье серии. В интересах экономии времени и места, приведем лишь один пример Спутника:

Create Table SAT_Products (
ProductID int NOT NULL,
LOAD_DATE DateTime Not Null,
QuantityPerUnit nvarchar(20),
UnitPrice money,
UnitsInStock smallint,
UnitsOnOrder smallint,
ReOrderLevel smallint,
Discontinued bit,
RECORD_SOURCE nvarchar(12) not null,
Primary Key (ProductID,LOAD_DATE)
Foreign Key (ProductID) references HUB_Products
)

Физическая модель данных теперь выглядит следующим образом:

Physical Northwind Data Vault Model

Рисунок 3-3. Физическая модель Data Vault на основе Northwind

Если это изображение является трудночитаемым, полное изображение доступно в формате PDF на www coreintegration.com... (прим. переводчика: в настоящее время файл не доступен, если у кого-то сохранился, пришлите, пожалуйста; мы разместим на этом сайте). В этой модели все хабы светло-серого цвета, связи – красного, а спутники – белого. Для дат окончания здесь применен стиль 1, использующий только стандартные даты загрузки. В интересах экономии места другие стили будут представлены в будущей статье.

4.0 Populating a Data Vault

Если будет использоваться процесс авто-генерации Data Vault, то наряду с генерацией структур данных, будут сгенерированы представления (view), используемые для наполнения структуры данных. В нашем случае были сгенерированы представления. Мы покажем по одному примеру для Хаба, Связи и Спутника.

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

Другое назначение структуры Data Vault состоит в том, чтобы предоставлять «жилище» 100% поступающих данных в течение 100% времени. Это касается всего, до среды отчетов и витрин данных, чтобы можно было определить, какие данные не соответствуют с бизнес-правилам. Data Vault позволяет легко строить повторяемые, последовательные процессы, включая процессы загрузки. Архитектура обеспечивает первые шаги в направлении, позволяющем динамические изменения структуры.

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

CREATE VIEW V_INS_HUB_CATEGORIES AS

SELECT DISTINCT A.CATEGORYID,GETDATE() LOAD_DATE, 'NORTHWIND' RECORD_SOURCE
FROM NORTHWIND..[CATEGORIES] A with (NOLOCK)
WHERE NOT EXISTS
(SELECT * FROM HUB_CATEGORIES WITH (NOLOCK))

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

CREATE VIEW V_INS_LNK_ORDERS AS

SELECT DISTINCT A.ORDERID, A.CUSTOMERID, A.EMPLOYEEID, A.SHIPVIA, GETDATE() LOAD_DATE, 'NORTHWIND' RECORD_SOURCE
FROM NORTHWIND..[ORDERS] A with (NOLOCK)
WHERE NOT EXISTS
(SELECT * FROM LNK_ORDERS WITH (NOLOCK))

Чтобы загрузить Спутники, выберите ряд строк, соответствующих или соединенных с бизнес ключом (или составным ключом, если возможно), в которых есть, по крайней мере, одно изменение в полях источников по сравнению с полями приемников. Сравнивайте только с «последней картиной» хранящейся в спутнике.

CREATE VIEW V_UPD_SAT_EMPLOYEES AS

SELECT A.EMPLOYEEID,A.LASTNAME, A.FIRSTNAME, A.TITLE, A.TITLEOFCOURTESY, A.BIRTHDATE, A.HIREDATE, A.ADDRESS, A.CITY, A.REGION, A.POSTALCODE, A.COUNTRY, A.HOMEPHONE, A.EXTENSION, A.PHOTO, A.NOTES, A.REPORTSTO, A.PHOTOPATH, GETDATE() LOAD_DATE, 'northwind' RECORD_SOURCE
FROM northwind..[employees] A with (NOLOCK), SAT_EMPLOYEES B with (NOLOCK)
WHERE A.EMPLOYEEID = B.EMPLOYEEID
AND (isnull(A.LASTNAME,'x') != isnull(B.LASTNAME,'x')
OR isnull(A.FIRSTNAME,'x') != isnull(B.FIRSTNAME,'x')
OR isnull(A.TITLE,'x') != isnull(B.TITLE,'x')
OR isnull(A.TITLEOFCOURTESY,'x') != isnull(B.TITLEOFCOURTESY,'x')
OR isnull(A.BIRTHDATE,convert(datetime,'01/01/1960')) !=
isnull(B.BIRTHDATE,convert(datetime,'01/01/1960'))
OR isnull(A.HIREDATE,convert(datetime,'01/01/1960')) !=
isnull(B.HIREDATE,convert(datetime,'01/01/1960'))
OR isnull(A.ADDRESS,'x') != isnull(B.ADDRESS,'x')
OR isnull(A.CITY,'x') != isnull(B.CITY,'x')
OR isnull(A.REGION,'x') != isnull(B.REGION,'x')
OR isnull(A.POSTALCODE,'x') != isnull(B.POSTALCODE,'x')
OR isnull(A.COUNTRY,'x') != isnull(B.COUNTRY,'x')
OR isnull(A.HOMEPHONE,'x') != isnull(B.HOMEPHONE,'x')
OR isnull(A.EXTENSION,'x') != isnull(B.EXTENSION,'x')
OR isnull(CONVERT(varbinary(2000),A.PHOTO),0) != isnull(CONVERT(varbinary(2000),B.PHOTO),0)
OR isnull(CONVERT(varchar(2000),A.NOTES),'x') != isnull(CONVERT(varchar(2000),B.NOTES),'x')
OR isnull(A.REPORTSTO,0) != isnull(B.REPORTSTO,0)
OR isnull(A.PHOTOPATH,'x') != isnull(B.PHOTOPATH,'x')
)

Представление создано, с учетом необходимости сравнения пустых значений (NULL), и сравнения полей типа «text» и «image» только по первым 2000 символам. Сравнение очень быстро, и является короткой замкнутой Булевой оценкой (short-circuit Boolean evaluation). Эти представления используются с помощью выражения: «Insert Into… Select * from». Это спутниковое представление работает быстро, пока секционирование (partitioning) совпадает с первичным ключом.

Представления работают хорошо, когда источник и хранилище данных управляются одним и тем же экземпляром (instance) системы управления базами данных (СУБД). Если используются различные экземпляры, то предлагаем два решения: 1) буферизуйте исходные данные в область хранилища данных, чтобы могли использоваться представления; 2) используйте инструмент ETL, чтобы сделать перенос и сравнение информации. Вместе с тем, размещение информации в хранилище и использование представлений позволяют ядру базы данных держать данные локально, и в некоторых случаях использовать преимущества распараллеленных операций (это позволяет, например, Teradata). 

5.0 Заключение

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