2.2 Загрузка сущностей Связей
Таблицы Связи без суррогатных ключей загружаются точно таким же образом, как и Хабы. Однако, так как сегодня большинство корпоративных хранилищ данных использует суррогатные ключи, мы укажем дополнительный шаг в процессе загрузки, чтобы найти соответствующие строки Хабов.
В этом контексте загрузка таблиц Связи выполняется следующим образом (имейте в виду, что эта презентация последовательности загрузки основана на пуританском подходе). Во-первых, мы формулируем список всех уникальных бизнес ключей, которые составляют связанные данные (relationship data) для связи. Затем, мы находим или определяем местонахождение каждого соответствующего им суррогатного ключа в Хабе. Наконец, мы проверяем, существуют ли они в целевой таблице, если нет, то вставляем запись с новым суррогатным ключом Связи, если существуют, то запись выбывает из обработки.
Дубликаты в таблицах Связи обычно означают плохое определение гранулярности, или неправильное смоделированную сущность Хаб. В этом случае «дубликат» означает дублирование бизнес ключей, а не дублирование суррогатов, конечно же. Проблема, как правило – гранулярность. Если процессы не могут найти старую спутниковую запись для датирования окончания (притом, что она существует), то это недостаток гранулярности модели таблицы связи. В таком случае таблица Связи должна быть перепроектирована, чтобы соответствовать степени детализации
Загрузка таблицы Связи успешны, когда ВСЕ отношения между бизнес ключами были записаны. Если есть пропавшие бизнес ключи, тогда подобно Хабам, мы загружаем «нулевые» ключи и связываем их отношениями с «unknown» строками Хабов. Это позволяет продолжать загружать данные без поломок. Захват всех отношений, даже неполноценных, предоставляет бизнес пользователям все возможности аудиторского исследования (ИТ и Бизнес могут проследить происхождение информацию до исходных систем). Все загрузки Связей можно также запускать параллельно. Фактически, если доступно достаточно аппаратных средств, рекомендуется загружать Связи одновременно с загрузкой Спутников Хабов. Это позволяет достичь максимальной пропускной способности.
2.3 Загрузка сущностей Спутников
Загрузка Спутников является легкой частью. Датирование окончания действия записей Спутника иногда требует немного больше работы. Конечно это - краткий высокоуровневый обзор процесса загрузки. Полное изложение информации о процессах загрузки будет в моей готовящейся книги, части которой Вы можете найти на www. DanLinstedt.com. Для загрузки Спутников используется следующая архитектура:
Этот рисунок представляет загрузку Спутника. В этой загрузке мы, во-первых, создаем список уникальных атрибутов. Это необходимо, чтобы не загружать «задвоенные строки атрибутов» в целевой Спутник. Все строки, которых есть в источниках, должны быть учтены и загружены в приемник данных. Это означает использовать заданные по умолчанию наборы данных для некоторых колонок, поэтому мы советуем задать эти значения как часть процесса. Однако значения, заданные по умолчанию, не используются для численных данных, они остаются со значением NULL. Конечно, высшей ценностью является оставить все поля NULL, если они прибывают в этом формате, однако это делает запросы и сравнения трудными.
Затем, мы ищем ключ любо Хаба либо родительский ключ Связи так, чтобы строка Спутника могла быть связана надлежащим образом. Если родительский ключ не существует – у нас механическая ошибка в наших процессах загрузки Хабов или Связей – в этом месте необходимо сгенерировать оповещение и остановить процесс загрузки. Как только ошибка устранена, это должно остаться неизменным на долгое время. Затем, мы сравниваем прибывшие данные в колонках с текущим состоянием данных Спутника. Это делается для гарантии того, что мы НЕ загружаем дубликаты данных. Мы не хотим проблемы взрыва данных в Спутниках, поэтому здесь заставляем Спутники соответствовать скорости изменения и типу информации.
Если элементы строки содержат измененные значения (дельту), или просто еще не существуют в таблице приемнике, эта строка вставляется. Есть вспомогательная таблица, поддерживаемая в буферной области (staging area). При каждой загрузки эта таблица очищается и перезагружается только первичными ключами записей спутника, который вставлены во время обработки. Это облегчает получение первичных ключей Спутника, и завершить процесс, датирующий окончания действия строк, не просматривая при этом весь набор данных в Спутнике, чтобы узнать, что новое, а что нет. Архитектура процесса датирующего окончания действия может выглядеть подобным образом:
В этом процессе загрузки, записи Спутника, которые не были датированы датой окончания, получат значения дат окончания. Этот специфический процесс полностью перезапускаемый и масштабируемый. Только в необходимых строках Спутника будет проставлена дата окончания. Если вставленные строки были уже обновлены, то они не будут датированы снова. Датирование датами окончания строк Спутника важно, чтобы знать какие данные являются активными. Все процессы разработаны таким образом, чтобы быть по своей природе повторяемыми, последовательными, масштабируемыми и перезапускаемыми. Вместе с тем, нужно учитывать загрузка данных в режиме близком к реальному времени немного меняет дизайн процессов загрузки.