Skip to Content

Data Vault. Серия 3: Даты окончания действия и основы соединений

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

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

Аннотация

Назначение этого документа – представить и обсудить заявленную на патент технологию под названием Data Vault™ (прим. переводчика: статья была написана в 2001 году, в предоставлении патента было отказано в январе 2005; сейчас архитектура Data Vault – общедоступна – FREE and PUBLIC DOMAIN). Data Vault™ – новый этап эволюции моделирования данных для хранилищ данных масштаба предприятия. Это - третья статья в ряду публикаций о Data Vault. Эта статья исследует пример Data Vault, приведенный во 2-ой статье Серии, расширяет понятие «даты окончания действия» и содержит некоторое введение в методы соединения (join techniques). Это обсуждение охватывает также способности архитектуры Data Vault к обработке данных в режиме близком к реальному времени (на уровне 1 - 20 секунд). Следующая статья в серии будет сосредоточена на таблицах Связи с дополнительными методами соединения. Завершающая статья обсудит такие темы, как: вставка, обновление, удаление, управление фактами, агрегаты, режим близкий к реальному времени и пакеты (batch). В этой статье мы начинаем рассматривать некоторые аспекты, связанные с запросами данных и с логикой управления данными в Data Vault. Рекомендуется, чтобы Вы были знакомы с концепцией Data Vault, и прочитали предыдущие две на http://www.tdan.com (или у нас на сайте).

1.0 Введение

Назначение этого документа – представить и обсудить заявленную на патент технологию под названием Data Vault(прим. переводчика: статья была написана в 2001 году, в предоставлении патента было отказано в январе 2005; сейчас архитектура Data Vault – общедоступна – FREE and PUBLIC DOMAIN). Data Vault™ – новый этап эволюции моделирования данных для хранилищ данных масштаба предприятия. Целевая аудитория этой статьи: проектировщики данных, желающие построить модель Data Vault, или специалисты в области хранилищ данных и BI, интересующиеся запросами к Data Vault. Здесь представлены на первый взгляд не связанные темы: даты загрузки (load date), даты окончания действия (end-date), и введение в операции соединения (join operations). Соединения (Join) данных могут быть проблемой при применении Data Vault, но сделанные должным образом могут быть очень эффективными. Следующая статья серии охватит соединения более подробно: таблицы Связи (Link), Спутники (Satellites) таблиц Связи и дополнительные методы запросов. В этой же статье рассмотрим следующие темы:

  • Стили моделирования дат окончания (End-Date Styles).
  • Введение в операции соединения (проходит нитью через весь документ)
  • Резюме и выводы.

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

  • Как моделировать конечные даты в зависимости от различных требований.
  • Как моделировать при требованиях практически нулевого времени задержки.
  • Обработка различных запросов к структурам Спутников и Хабов.
  • Как подготовить запросы к структурам Data Vault (возможности соединения).

Наибольшие задачи моделирования хранилищ составляют: архитектура для больших объемов (терабайты); создание стандартов загрузки и восстановления; установление синхронизации содержания; запросы информации, зависимой от даты/времени; а также настройка модели, позволяющей загрузку в реальном времени. Архитектору данных или проектировщику остается искать способы встроить эти функциональности в модель. Архитектура Data Vault обеспечивает структурные компоненты, которые соответствуют вышеперечисленным аспектам. Хотя каждый из этих аспектов и описан в высокоуровневой дескриптивной форме в этом документе – в центре внимания все же остаются даты окончания и введение в методы соединений.

Даты окончания могут обрабатываться несколькими способами (с точки зрения Data Vault)

  1. Таблицы Point-In-Time (system of record / snapshot / picture tables).
  2. Поля с датами окончания, помещенные в Спутники.
  3. Комбинация двух вышеупомянутых методов.

Пожалуйста, имейте в виду, что загрузка в режиме реального времени – функция архитектуры и техники моделирования. Это не функция наличия или отсутствия PIT таблицы (point-in-time). Другими словами, для загрузки в режиме близком к реальному времени модели Data Vault достаточно Хабов, Связей и Спутников. PIT таблица – специализированная производная Спутника.

2.0 Стили моделирования дат окончания действия

Первый стиль – поместить поле, содержащее значение даты загрузки или даты наблюдения/измерения (observation date), в Спутник, и предположить, что информация действительна, пока не появится новая строка. Таким образом, промежуток времени между датами загрузки – по существу и есть период действия информации. Второй стиль – поместить поле, содержащее значение даты начала наблюдения/загрузки (start date), и поле, содержащее значение даты окончания (end date), в каждую строку Спутника. Третий метод должен быть использован, когда доступно достаточно дискового объема – чаще всего используется в режиме загрузки близкой к реальному времени, но так же может быть очень эффективной техникой для пакетной загрузки. Каждый метод работоспособен, ниже мы обсудим «за и против» для каждого.

Синхронизация временных отметок (date-time stamp) и систем, управляющих этими временными отметками, помогает решить проблемы географически разделенного хранилища Data Vaults. Во всяком случае, упрощает эти проблемы. Временная отметка также магически работает в другом случае – она предоставляет собой основу для того, что называют двойным датированием. Мы взяли GAAP (generally accepted accounting principles – общепринятые принципы бухгалтерского учета) – принципы, определяющие двойной ввод для главной бухгалтерской книги (general ledger), и повторно применили для логики дат в хранилище. Это также помогает нам с бухгалтерским представлением детальной информации – только с точки зрения времени. Помните, Data Vault ориентировано для массовой вставки (основанной только на изменениях/дельтах). Data Vault не приспособлено для обновлений или удалений (мы обсудим это в других статьях этой серии).

2.1 Дата загрузки и структуры Point-In Time.

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

Почему используются «Даты Загрузки»?

Необходимо применять Даты Загрузки (Load Date) или Даты Начала Наблюдения (Observation Start Date), чтобы вся информация, внесенная в хранилище, оставалась согласованной по временной шкале. Без использования даты о появлении информации в хранилище, такие действия, как восстановление, отмена, удаление или сворачивание старых данных, будут трудноосуществимы или невозможны. Это не единственная причина. Запросы конечного пользователя требуют данных, бывших действительными в определенный момент времени. Эта возможность выбирать данные за определенный период должна присутствовать в хранилище.

Что, если мои исходные системы имеют даты создания и даты обновления, разве я не могу использовать их?

Это не рекомендуется, однако если необходимо использовать именно это, пусть так оно и будет. Как правило, это – не вариант, поскольку большинство имеющихся на предприятии систем-источников не содержат дат создания или дат обновления, и даже если содержат, то не хранят историю изменений. Вами должен быть разработан единый согласованный метод фиксации даты/времени. Абсолютно обязательно, чтобы все строки содержали дату последнего обновления в едином стандарте.

Если у меня есть несколько Data Vaults географически распределенных по различным часовым поясам, то это означает, что я должен синхронизировать часы серверов?

Этого не требуется, потому что, обычно, когда объединяются данные различных хранилищ Data Vaults, то преобразование часовых поясов может делаться согласно Среднему времени по Гринвичу (GMT). Однако, может быть полезным синхронизировать часы всех серверов по стандарту «Гринвич + X», чтобы загрузка временных отметок была точной. Фактически, как только часы синхронизированы, становится намного легче объединять информацию из географически распределенных хранилищ и избежать проблем, связанных со значениями времени.

Хорошо, теперь я понимаю, почему дата загрузки необходима, но как она работает?

Этот метод легок для загрузки, но может вызвать проблемы при запросах информации. Для того чтобы получить последнюю строку на определенную дату, запрос без структуры Point-in-time (PIT) должен иметь вложенные подзапросы. Примечание: Мы используем термины PIT (point in time), PIC (picture table), and SOR (system of record) как синонимы. Ниже для примера приведен Спутник, содержащий несколько строк

Data Vault Model. Customer Name Hub and Satellite

Рисунок 2-1. Customer Name Hub и Satellite

В случае отсутствия PIT-таблицы, запрос к этому Спутнику должен выглядеть следующим образом (на дату: 1-ое декабря 2000 г.):

Select * from HUB_CUST, SAT_CUST_NAME scst
Where hub_cust.CSID = scst.CSID
And scst.load_dts <=
(select max(z.LOAD_DTS) from SAT_CUST_NAME z
where scst.CSID = z.CSID
and z.LOAD_DTS <= ’12-1-2000 23:59:59’)

У этого запроса есть один изъян. Если в Спутнике не существуют строки с названием клиента и в условии задана дата, более ранняя, чем первая строка для этого клиента, equal-join не вернет никаких результатов. Даже если мы включим в запрос и другие Спутники, такие как Адрес. Например, если мы изменим дату в условии запроса на 1-ое октября 2000 г. (10-1-2000), мы не получим строк, независимо от количества присоединенных Спутников. Далее мы обсудим эту проблему и ее решение.

Этот запрос будет выбирать все текущие названия для всех клиентов по состоянию на 1 декабря 2000. Проблема заключается не в отдельном Спутнике. Каждый Спутник, необходимый для подробностей о состоянии на определенный момент времени, требует вложенных подзапросов такого же типа. Это является проблематичным, по крайней мере, в двух основных случаях: 1) таблиц в запросе две, одна для внешнего запроса, одна для подзапроса. Для некоторых СУБД максимальное количество таблиц в запросе составляет 16; и 2) возможность соединения в пределах одной таблицы. В таком случае может произойти полное сканированию таблицы, если не будет должного индекса.

При таком подходе загрузка очень проста. Мы запускаем дельта-сравнение «последней картинки» каждой строки (с учетом конкретного ключа), и, если существуют какие-нибудь различия, мы вставим новую строку. Никаких обновлений, никаких удалений не требуется. Однако, как мы видели, запросы могут быть сложными. Чтобы способствовать запросам, мы вводим то, что называется point-in-time таблицей (или system of record таблицей). Она выглядит следующим образом:

Data Vault Model. Customer Hub, Name Satellite and Point-In-Time Table

Рисунок 2-2. Customer Hub, Name Satellite и таблица Point-In-Time Table

Таблица point-in-time позволяет нам сохранить точное описание истории ВСЕХ произошедших изменений. Бизнес-правила будут диктовать, когда текущий снимок данных должен быть сделан, и соответствующий процесс будет делать обновление PIT таблицы. В этом случае, отслеживаются оба изменения: наименования и адреса. Конечно, это не зависит от времени поступления информацией в каждый спутник. Это позволяет загружать спутники в режиме близком к реальному времени, и при этом полностью оставаясь в рамках ограничений ссылочной целостности, и при этом без воздействий на:
а) систему запросов витрины данных;
б) зависимую цепочку (нижележащие зависимости, отношения родитель-потомок),
или
в) частоту загрузки каждого спутника.
Иными словами, имена могут изменяться каждые 15 минут, в то время как адреса могут измениться один раз в день.

Таблица point-in-time (PIT) позволяет нам соединиться с одной таблицей, выбрав point-in-time, как систему записей (system of record), а затем непосредственно соединиться со спутниками. Измененный код SQL:

Select hub.cust_num, sat_1.name, sat_2.address
from HUB_CUST hub, SAT_CUST_PIT sat_pit, SAT_CUST_NAME sat_1, SAT_CUST_ADDR sat_2
where hub.CSID = sat_pit.CSID and hub.CSID = sat_1.CSID and hub.CSID = sat_2.CSID and sat_pit.NAME_LOAD_DTS = sat_1.LOAD_DTS and sat_pit.ADDRESS_LOAD_DTS = sat_2.LOAD_DTS and sat_pit.load_dts <=
(select max(z.LOAD_DTS) from SAT_CUST_PIT z where sat_pit.CSID = z.CSID and z.LOAD_DTS <= ’12-1-2000 23:59:59’)

Опять же, у нас есть фундаментальная проблема с датами – если в качестве условия задана слишком ранняя дата, то не получим строк для этого идентификатора клиента. Другая проблема: Что, если у клиента вообще нет записей в адресном Спутнике? Тогда, этот клиент будет также полностью выпадать из этого соединения. Мы обсудим эту проблему и ее решение далее в этом документе.

У нас все также 5 таблиц участвуют в соединение (joined) – но только одна таблица используется для ограничения временного интервала. Иными словами, кроме таблицы PIT, все соединения используют равенство в условиях соединения. Это прекрасно работает, если два или более спутника привязаны к табличной структуре хабов или связей. Если бы у нас было только два спутника без таблицы PIT, то запрос выглядел бы так:

Select hub.cust_num, sat_1.name, sat_2.address
from HUB_CUST hub, SAT_CUST_NAME sat_1, SAT_CUST_ADDR sat_2
where hub.CSID = sat_2.CSID and sat_1.LOAD_DTS <=
(select max(z.LOAD_DTS) from SAT_CUST_NAME z where sat_1.CSID = z.CSID and z.LOAD_DTS <= ’12-1-2000 23:59:59’)
AND sat_2.LOAD_DTS <=
(select max(z.LOAD_DTS) from SAT_CUST_ADDR z where sat_2.CSID = z.CSID and z.LOAD_DTS <= ’12-1-2000 23:59:59’)

В этом случае у нас в запросе есть два вложенных подзапроса и пять таблиц. Проблема по настоящему проявляется, когда модель содержит три или четыре спутника. Тогда большое количество связанных таблиц требует много работы во вложенных подзапросах.

Что происходит в этих вложенных подзапросах? С академической точки зрения, индекс соответствует ключу, вследствие чего, чтобы найти максимальную дату загрузки, индекс сканируется. Конечно, это зависит от того, как индексы были созданы, и, имеет ли спутник кластерный ключ или нет. Дело в том, что один подзапрос с соединением по условию равенства (equal-joins) обычно дешевле, чем несколько вложенных подзапросов с условием по диапазону (range joins). Это – только один из двух стилей, которые естественно соответствуют архитектуре Data Vault.

Резюмируя: наличие PIT таблицы помогает уменьшить работу по обработке вложенных запросов и соединений, только если есть два или более Спутников у одного Хаба. Использование стиля 1 означает, что отсутствует дата окончания в строках и не используется выражение «between» в SQL выборках. Это означает, что строки являются активными, пока не вставлена следующая картина (дельта).

Что еще может обеспечить point-in-time таблица?

PIT таблица может обеспечить следующее:

  • Темпы изменения истории без сканирования какого-либо из Спутников.
  • Временные разницы между изменениями в каждом Спутнике
  • Контроль над соединениями по равенству (equal-join) со Спутниками
  • Отметки о датах резервного копирования, восстановления или обновлений (при желании можно расширить перечень этих элементов).

Больше особо нечего сказать об этом стиле, разве что, используется генерируемые временные отметки. Не рекомендуется использовать дату создания из систем источников. Конечно, остается вопрос: как и где, следует хранить информационные данные типа «дата»? Это мы рассмотрим далее в этой статье.

2.2 Дата начала и Дата окончания

Если приведенный выше стиль не соответствует требованиям хранилища, то этот стиль может соответствовать парадигме немного лучше. В этом случае, нет места PIT таблицам и нет дополнительной работы в запросах. Иногда команда внедрения может взяться за разработку более сложных процессов загрузки. Когда эта происходит, то этот второй стиль лучше подходит для проекта. Кто интересовался Активным Хранилищем Данных (Active Data Warehousing) или Хранилищем Реального Времени (Real Time Data Warehousing), тот мог слышать эти слова: «Дата Начала Наблюдения» (Observation Start Date), «Дата Окончания Наблюдения» (Observation End Date). В данной статье мы полагаем, что эти, только что названные, термины эквивалентны «Дате Начала Загрузки» (Load Start Date) и «Дате Окончания Загрузки» (Load End Date).

Что представляет собой этот архитектурный тип?

Data Vault Model. Customer Hub, Name and Address Satellite – End-Dates

Рисунок 2-3. Customer Hub, Name Satellite и таблица Address Satellite с датами окончания
(Примечание: Поле «Record Source» не показано в Спутниках из-за экономии места. Имеем в виду, что оно должно присутствовать)

В данном примере представлены поля LOAD_DTS – «Дата Начала Загрузки» и LOAD_END_DTS – «Дата Окончания Загрузки». При выборе этого стиля, поле, содержащее дату окончания, не заполняется, пока не поступит следующее изменение. Это позволяет запросу вывести информацию, актуальную на определенную дату. Загрузка становится более сложной, так как при вставке новой записи нужно обновить значение даты окончания в предыдущей строке. Записи могут быть датированы будущим числом, если это предпочитаемая практика, хотя автор не рекомендует этого. 

Что представляют собой запросы?

Select hub.cust_num, sat_1.name, sat_2.address
from HUB_CUST hub, SAT_CUST_NAME sat_1, SAT_CUST_ADDR sat_2
where hub.CSID = sat_1.CSID and hub.CSID = sat_2.CSID
and ‘12-1-2000 23:59:59’ between sat_1.LOAD_DTS and sat_1.LOAD_END_DTS
and ‘12-1-2000 23:59:59’ between sat_2.LOAD_DTS and sat_2.LOAD_END_DTS

Запрос значительно упрощен. Но есть две проблемы, связанные с этим запросом:

  1. Не обрабатывается значение NULL в поле LOAD_END_DATES
  2. Не обрабатываются отсутствующие записи спутника до переданной в запрос даты.

Мы обсудим эти проблемы и их решения далее.

Заметьте, что запрос быстр, эффективен и основан на первичном ключе – всегда существует индекс по первичному ключу. Это происходит потому, что каждый первичный ключ Спутника создан на основе полей CSID и load_date. Оба этих поля эффективно используются в условиях на точное соответствие выражения «Where». Поскольку дата – константа – она может быть подобрана непосредственно по ключевым полям.

Что это означает для стратегии индексирования?

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

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

2.3 Комбинированный подход: даты окончания вместе с PIT таблицей

Это гибридный подход, применяющий оба предыдущих архитектурных стиля моделирования данных одновременно. Существует одно ухищрение: PIT-таблица не содержит долговременные данные. Иными словами, она становится полностью обновляемым Спутником, который пересоздается при каждой загрузке. Конечно, это один из вариантов. При желании (если позволяют объемы) можно просто обновлять существующие PIT-строки – что было бы приемлемой альтернативой пересоздания (rebuilding) всей таблицы.

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

Функция PIT-таблицы еще не обсуждалась с позиции запросов. Это придает таблице ряд преимуществ: 1) синхронность данных; 2) видимость конечному пользователю специфических «свежих данных» может быть спланированной по времени; 3) изолирует запросы конечных пользователей от данных подвергающихся изменению. Когда использовался исторический способ, PIT-таблица была гораздо полезнее для достижения этих целей. При использовании способа полного обновления (как показано в этом гибридном подходе), новая PIT-таблица должна быть построена с учетом изменений, а затем старая PIT-таблице удаляется. Это сохраняет согласованность данных в хранилище.

Почему предложен гибридный подход?

Использование единственного подхода – зачастую не самый лучший способ сделать образцовую модель для проекта, а то и напротив. В данном случае архитектура показывает свою гибкость. Кроме того, для обладателей достаточного дискового пространства и вычислительных мощностей, это действительно может быть полезным компонентом. На что это похоже?

Data Vault. End-Dates and Point-In-Time Table Combined Approach

Рисунок 2-4. Комбинированный подход: Даты окончания и Point-In-Time таблица

Обратите внимание, что поле LOAD_DTS ушло из PIT-таблицы. Это для того, чтобы хранить только наиболее свежую информации в спутнике. Если есть желание хранить историю в PIT-таблице, используя этот гибридный подход, то добавьте поле LOAD_DTS (дата загрузки) обратно в первичный ключ. Запрос, непосредственно выбирающий данные, может здесь измениться, чтобы приспособиться к некоторым ранее упомянутым проблемам (например, запрос более ранней даты или NULL в конечных датах). Также обратите внимание, всегда должна быть запись в PIT-таблице для каждого первичного ключа Хаба, независимо от решения хранить историю в PIT-таблице или нет. Запрос может выглядеть следующим образом:

-- GET MOST RECENT / CURRENT DATA ONLY
Select hub.cust_num, sat_1.name,sat_2.address
from HUB_CUST hub, SAT_CUST_PIT pit,SAT_CUST_NAME sat_1,SAT_CUST_ADDR sat_2
where hub.CSID = sat_1.CSID
and hub.CSID = sat_2.CSID
and pit.NAME_LOAD_DTS = sat_1.LOAD_DTS
and pit.ADDRESS_LOAD_DTS = sat_2.LOAD_DTS

Этот запрос является прямым соединением без каких-либо подзапросов, и всегда выбирает самую последнюю информацию (в соответствии с текущим обновлением PIT-таблицы). Запрос point-in-time (кроме текущего) по-прежнему нуждается либо в подзапросе, либо в выражении «between», или в исторической PIT-таблице.

2.4 Запросы к Спутнику при несогласованных данных

Как упоминалось ранее, может возникнуть необходимость искать более «ранние» данные, чем существуют. И в некоторых случаях, может не оказаться никаких соответствующих данных в Спутнике. В этом случае предложенные нами ранее запросы не возвращают данные. Один из самых быстрых способов решения этой проблемы является изменение запроса включением внешнего соединения (outside join). Это не всегда лучшая альтернатива; здесь мы дадим введение о вариантах размещения данных, а подробное обсуждение будет позже в другом документе.

Предположим, у нас есть то, что показано на Рисунке 2-1, и мы хотим получить данные по состоянию на 10-05-2000. Первоначальный запрос выглядел следующим образом:

Select * from HUB_CUST, SAT_CUST_NAME scst
Where hub_cust.CSID = scst.CSID
And scst.load_dts <=
(select max(z.LOAD_DTS) from SAT_CUST_NAME z
where scst.CSID = z.CSID
and z.LOAD_DTS <= ’12-1-2000 23:59:59’)

Новый запрос выглядит вот так:

-- NEW QUERY
Select * from HUB_CUST, SAT_CUST_NAME scst
Where hub_cust.CSID *= scst.CSID
And scst.load_dts =*
(select max(z.LOAD_DTS) from SAT_CUST_NAME z
where z.CSID = hub_cust.CSID
and z.LOAD_DTS <= ’10-05-2000 23:59:59’)

Это позволит выбрать все строки Хаба независимо от того, имеют ли они соответствие в Спутниках. Если строки Спутника не будут соответствовать ограничению даты, запрос вернет NULL для этих ключей Хаба. Одна из проблем в этом запросе – высокая стоимость подзапроса, выбирающего максимальную дату. При использовании PIT-таблицы с историей, запрос будет выглядеть следующим образом:

select * from HUB_CUST a, SAT_CUST_PIT b, SAT_CUST_NAME c, SAT_CUST_ADDR d
where a.CSID = b.CSID and a.CSID *= c.CSID and a.CSID *= d.CSID
and b.LOAD_DTS =
(select max(z.LOAD_DTS) from SAT_CUST_PIT z
where a.CSID = z.CSID and z.LOAD_DTS <= '10-11-2000')
and c.LOAD_DTS =* b.NAME_LOAD_DTS
and d.LOAD_DTS =* b.ADDR_LOAD_DTS

Если вы хотите получить все строки истории за все время, подзапрос, возвращающий значение для b.LOAD_DTS, удаляется из запроса. Одно условие заключается в том, что PIT-таблица должна содержать все идентификаторы клиента, которые существуют в Хабе. Условие внешнего соединения (outside join condition) позволяет нам выполнить запрос без необходимости существования строк в Спутнике для каждого ключа. Это быстрое решение, и работает очень хорошо, даже в условиях нагрузки.

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

3.0 Заключение

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

Как отмечалось выше, создавайте сложные запросы с помощь представлений (view). Если это необходимо, используйте вложенные представления. Стройте представления на основе Хабов и соответствующих им Спутников, Ссылок и их Спутников. Это позволит свести доступ к минимуму и наладить стандарты. Разграничьте доступы к текущей информации и к исторической, чтобы запросы были как можно быстрее. Когда возможно используйте значения NULL в ваших полях с датами – это поможет сохранить истинную природу данных. В следующей статье мы углубимся в таблицы Связей, их объединение и их Спутники.