2.1 Загрузка сущностей Хабов
В сущность Хаб делаются запись только при первом появлении бизнес ключа в системе системы Data Vault. В Хабы не записывают последующие загрузки или любые изменения тех же самых данных. Чтобы загрузить хаб, мы должны сначала проверить, была ли запись уже загружена (уже существует). Это будет учитывать как ранее прервавшийся процесс загрузки, так и дублирование информацию в пределах одного и того же механизма загрузки. Захват измененных данных (Change Data Capture, CDC) в исходной системе хорошо помогает, пока процесс загрузки в хранилище не прерывается. На этом этапе нам требуется стандартизированный механизм для того, чтобы обнаружить изменения, происходящие при обработке хаба. Ниже показана последовательность процессов для загрузки хаба:
Рисунок 2-1 Загрузка сущности Хаб
Загрузка Хабов довольно проста. При загрузке Хабов необходимо помнить несколько вещей. Необходимо учитывать следующее:
Все бизнес ключи Хабов должны быть уникальными, и находиться в соотношении один к одному с суррогатами.
Ключи Хаба не зависят от времени
Ключи Хабов не могут дублироваться
Ключи Хаба определены в тех же самых семантических слоях
Загрузка хаба состоит, во-первых, из идентификации основной «мастер» системы – системы, где по мнению бизнеса фактически генерируется большинство ключей; конечно это предположение должно быть проверено на реальных наборах данных, прибывающих из этой системы. Как только основная система идентифицирована, то первоначально извлекают данные из нее. Загружается уникальный список ключей, не существующих в преемнике данных, и во время загрузки им обеспечивается соответствующий суррогатный ключ. Остальные системы сортируются с точки зрения важности. Из второй системы (наиболее вероятно, генерирующей ключи, даже если бизнес заявляет, что эта система никогда их не производит), загружают данные подобным образом.
Этот процесс повторяется для каждой исходной системы, которая содержит ключевые поля хаба. Это понятия «содержит ключ хаба» никак не поддерживается фактическим дизайном исходный системы – другими словами, поле, используемое для ключей хаба, может быть, а может и не быть внешним ключ в исходной системе. Мы констатируем тот факт, что ключ действительно существует, и поэтому он должен быть помещены в Хаб. Наконец, существуют информационные компоненты, у которых нет никакого ключа; например, таблица содержит основную информацию о продукте, и является вторичным источником для номера или адреса клиента; в нашем случае номер клиента является пустым, а адрес клиента заполнен. Что мы делаем? Мы заполняем номер клиента пустышкой, поместив его к строке хаба, называемой строкой с нулевым ключом или UNKNOWN), так, чтобы данные об адресе клиента не были потеряны во время загрузки Спутников.
Дубликаты в Хабах вызовут много других проблем, начиная от проблем SQL запросов до проблем дополнительного моделирования. Не рекомендуется загружать дубликаты в ключевые поля Хаба. Хорошо, а что относительно «плохих данных»? Существует конкретный пример неправильных данных. Другими словами, в исходной системе есть номер счета клиента, но эта система была «продана» в разные штаты, и поэтому есть дубликаты номеров счетов (для различных клиентов). Как мы загрузим эти данные?
Одна из идей заключается в том, чтобы фиксировать источник в составном бизнес ключе – это типичное решение, обычно предлагаемое для обеспечения уникальности, но на горизонте был другой подход: добавить к номеру счета клиента «код штата» или другую идентифицирующую часть данных, чтобы синтезировать уникальность. Это будет работать, но только ограниченное время. В конечном счете, если вторичный или третичный ключ, выбранный для добавления к бизнес ключу, начнет обладать квалифицирующими или идентифицирующие свойствами, тогда он должен будет выделен в свой собственный Хаб.
Другими словами, мы можем временно исправить положение, используя «Код Штата», но если мы должны будем начать захватывать информацию о коде штата, мы будем вынуждены создать для этого отдельный Хаб. Основные правила здесь следующие: плохо идентифицированные входные элементы вызывают архитектурные разрывы, приводящие к разрушению дизайна Data Vault. Это обычно означает, что у системы источника есть некоторые проблемы в проектировании, уходящие глубже, чем только набор данных.
Когда мы смотрим на реальные процессы загрузки, все Хабы могут и должны быть загружены параллельно на первом шаге. Таким образом, мы можем создать хорошо масштабируемую архитектуру – больше данных, больше Хабов, более простая загрузка обрабатывающая все параллельно. Мы можем также инвестировать в аппаратные средства, и тем самым поддержать проект, когда увеличится нагрузка и потребуются новые аппаратные средства. Это для пакетно-ориентированного решения, когда данные готовы, загрузите их.