Моделирование хранилища данных - Data vault modeling

Моделирование хранилища данных это база данных метод моделирования, который предназначен для обеспечения длительного исторического хранения данные поступает из нескольких операционных систем. Это также метод просмотра исторических данных, который касается таких вопросов, как аудит, отслеживание данных, скорость загрузки и устойчивость к изменениям, а также подчеркивает необходимость отслеживания происхождения всех данных в базе данных. Это означает, что каждый ряд в хранилище данных должны сопровождаться атрибутами источника записи и даты загрузки, что позволяет аудитору отслеживать значения обратно к источнику. Он был разработан Даниэль (Дэн) Линстедт в 2000 г.

Моделирование хранилища данных не делает различий между хорошими и плохими данными («плохие» означают несоответствие бизнес-правилам).[1] Это резюмируется в заявлении о том, что в хранилище данных хранится «одна версия фактов» (также выраженная Дэном Линстедтом как «все данные за все время»), в отличие от практики хранения других хранилищ данных » а единственная версия правды "[2] где данные, не соответствующие определениям, удаляются или «очищаются».

Метод моделирования разработан так, чтобы быть устойчивым к изменениям в бизнес-среде, из которой поступают хранимые данные, путем явного отделения структурной информации от описательных атрибутов.[3] Хранилище данных предназначено для максимально возможной параллельной загрузки,[4] так что очень большие реализации могут масштабироваться без необходимости серьезной модернизации.

История и философия

В хранилище данных Моделирование существует два хорошо известных конкурирующих варианта моделирования слоя, на котором хранятся данные. Либо вы моделируете по Ральф Кимбалл, с согласованными размерами и корпоративной шиной данных, или вы моделируете в соответствии с Билл Инмон с базой данных нормализованный[нужна цитата ]. У обоих методов есть проблемы при работе с изменениями в системах, питающих хранилище данных.[нужна цитата ]. Для согласованных размеров вам также необходимо очистить данные (чтобы согласовать их), что в ряде случаев нежелательно, так как это неизбежно приведет к потере информации.[нужна цитата ]. Хранилище данных предназначено для предотвращения или сведения к минимуму воздействия этих проблем путем перемещения их в области хранилища данных, которые находятся за пределами области исторического хранения (очистка выполняется в витринах данных) и путем разделения структурных элементов (бизнес-ключи и ассоциации между бизнес-ключами) из описательных атрибутов.

Дэн Линстедт, создатель метода, описывает получившуюся базу данных следующим образом:

«Модель Data Vault - это детально ориентированный, исторический отслеживающий и однозначно связанный набор нормализованных таблиц, которые поддерживают одну или несколько функциональных областей бизнеса. Это гибридный подход, охватывающий лучшее в своем классе между 3-ей нормальной формой (3NF) и звездная схема. Дизайн гибкий, масштабируемый, согласованный и адаптируемый к потребностям предприятия »[5]

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

Другая проблема, на которую отвечает хранилище данных, заключается в том, что все больше и больше возникает потребность в полной проверяемости и отслеживаемости всех данных в хранилище данных. Из-за Сарбейнс-Оксли Требования в США и аналогичные меры в Европе - это актуальная тема для многих реализаций бизнес-аналитики, поэтому в центре внимания любой реализации хранилища данных является полная прослеживаемость и контролируемость всей информации.

Хранилище данных 2.0 это новая спецификация, это открытый стандарт.[6] Новая спецификация содержит компоненты, которые определяют передовой опыт реализации, методологию (SEI / CMMI, Six Sigma, SDLC и т. Д.), Архитектуру и модель. Хранилище данных 2.0 фокусируется на включении новых компонентов, таких как Big Data, NoSQL, а также на производительность существующей модели. Старая спецификация (по большей части задокументированная здесь) сосредоточена на моделировании хранилищ данных. Это описано в книге: Создание масштабируемого хранилища данных с помощью Data Vault 2.0.

Необходимо развить спецификацию, чтобы включить в нее новые компоненты, а также лучшие практики, чтобы поддерживать системы EDW и BI в соответствии с потребностями и желаниями современного бизнеса.

История

Моделирование хранилищ данных было первоначально задумано Дэном Линстедтом в 1990-х годах и было выпущено в 2000 году как метод моделирования общественного достояния. В серии из пяти статей в Информационном бюллетене администрирования данных расширены и объяснены основные правила метода Data Vault. Они содержат общий обзор,[7] обзор компонентов,[8] обсуждение дат окончания и присоединений,[9] связать таблицы,[10] и статья о способах загрузки.[11]

Альтернативное (и редко используемое) название метода - «Общая архитектура моделирования интеграции».[12]

Хранилище данных 2.0[13][14] появился на сцене в 2013 году и предлагает большие данные, NoSQL, неструктурированную, полуструктурированную бесшовную интеграцию, а также лучшие методологии, архитектуру и внедрение.

Альтернативные интерпретации

Согласно Дэну Линстедту, Модель данных основана на упрощенном представлении о нейронах, дендритах и ​​синапсах, где нейроны связаны с концентраторами и сателлитами-концентраторами, ссылки являются дендритами (векторами информации), а другие ссылки являются синапсы (векторы в обратном направлении). Используя набор алгоритмов интеллектуального анализа данных, ссылки можно оценивать по степени уверенности и прочности. Их можно создавать и удалять на лету в соответствии с изучением отношений, которых в настоящее время не существует. Модель может автоматически трансформироваться, адаптироваться и корректироваться по мере использования и загрузки новых структур.[15]

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

Другой способ представить модель хранилища данных - это модель графа. Модель хранилища данных фактически предоставляет модель «на основе графа» с концентраторами и отношениями в мире реляционных баз данных. Таким образом, разработчик может использовать SQL для установления отношений на основе графа с ответами менее секунды.

Основные понятия

Простая модель хранилища данных с двумя концентраторами (синий), одним каналом (зеленый) и четырьмя спутниками (желтый)

Хранилище данных пытается решить проблему обработки изменений в среде путем отделения бизнес-ключей (которые не изменяются так часто, потому что они однозначно идентифицируют бизнес-объект) и связей между этими бизнес-ключами от описательных атрибутов этих ключей. .

Бизнес-ключи и их ассоциации являются структурными атрибутами, образующими каркас модели данных. Одна из основных аксиом метода хранилища данных состоит в том, что реальные бизнес-ключи меняются только при изменении бизнеса и, следовательно, являются наиболее стабильными элементами, из которых можно получить структуру исторической базы данных. Если вы используете эти ключи в качестве основы хранилища данных, вы можете организовать остальные данные вокруг них. Это означает, что выбор правильных ключей для концентраторов имеет первостепенное значение для стабильности вашей модели.[16] Ключи хранятся в таблицах с некоторыми ограничениями на структуру. Эти таблицы ключей называются концентраторами.

Концентраторы

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

Хаб содержит как минимум следующие поля:[17]

  • суррогатный ключ, используемый для подключения других структур к этой таблице.
  • бизнес-ключ, драйвер для этого хаба. Бизнес-ключ может состоять из нескольких полей.
  • источник записей, который можно использовать, чтобы увидеть, какая система первой загрузила каждый бизнес-ключ.
  • при желании вы также можете иметь поля метаданных с информацией об обновлениях вручную (пользователь / время) и дате извлечения.

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

Хабы обычно должны иметь хотя бы один спутник.[17]

Пример концентратора

Это пример таблицы-концентратора, содержащей автомобили, которая называется «Автомобиль» (H_CAR). Ключ вождения идентификационный номер транспортного средства.

Имя поляОписаниеОбязательный?Комментарий
H_CAR_IDИдентификатор последовательности и суррогатный ключ для концентратораНетРекомендуется, но необязательно[18]
VEHICLE_ID_NRБизнес-ключ, который управляет этим центром. Может быть более одного поля для составного бизнес-ключада
H_RSRCИсточник записи этого ключа при первой загрузкеда
LOAD_AUDIT_IDИдентификатор в таблице с аудиторской информацией, такой как время загрузки, продолжительность загрузки, количество строк и т. Д.Нет

Ссылки

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

Ссылки могут ссылаться на другие ссылки, чтобы иметь дело с изменениями в степени детализации (например, добавление нового ключа в таблицу базы данных изменило бы зернистость таблицы базы данных). Например, если у вас есть связь между клиентом и адресом, вы можете добавить ссылку на ссылку между концентраторами продукта и транспортной компанией. Это может быть ссылка под названием «Доставка». Ссылка на ссылку в другой ссылке считается плохой практикой, поскольку она вводит зависимости между ссылками, которые затрудняют параллельную загрузку. Поскольку ссылка на другую ссылку аналогична новой ссылке с концентраторами из другой ссылки, в этих случаях создание ссылок без ссылки на другие ссылки является предпочтительным решением (см. Раздел о методах загрузки для получения дополнительной информации).

Иногда ссылки связывают хабы с информацией, которой недостаточно для создания хаба. Это происходит, когда один из бизнес-ключей, связанных ссылкой, не является настоящим бизнес-ключом. В качестве примера возьмите форму заказа с «номером заказа» в качестве ключа и строки заказа, которые помечены полуслучайным числом, чтобы сделать их уникальными. Скажем, «уникальный номер». Последний ключ не является настоящим бизнес-ключом, поэтому он не является концентратором. Однако нам необходимо использовать его, чтобы гарантировать правильную детализацию ссылки. В этом случае мы не используем хаб с суррогатным ключом, а добавляем в ссылку сам бизнес-ключ «уникальный номер». Это делается только в том случае, если нет возможности когда-либо использовать бизнес-ключ для другой ссылки или в качестве ключа для атрибутов в сателлите. Эта конструкция была названа Дэном Линстедтом «привязанной к ноге связью» на своем (ныне несуществующем) форуме.

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

Пример ссылки

Это пример таблицы ссылок между двумя концентраторами для автомобилей (H_CAR) и людей (H_PERSON). Ссылка называется «Драйвер» (L_DRIVER).

Имя поляОписаниеОбязательный?Комментарий
L_DRIVER_IDИдентификатор последовательности и суррогатный ключ для ссылкиНетРекомендуется, но необязательно[18]
H_CAR_IDсуррогатный ключ для автомобильной ступицы, первый якорь ссылкида
H_PERSON_IDсуррогатный ключ для человека хаб, второй якорь ссылкида
L_RSRCИсточник записей этой ассоциации при первой загрузкеда
LOAD_AUDIT_IDИдентификатор в таблице с аудиторской информацией, такой как время загрузки, продолжительность загрузки, количество строк и т. Д.Нет

Спутники

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

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

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

Пример спутника

Это пример сателлита на водительской линии между узлами для автомобилей и людей, называемого «Страхование водителя» (S_DRIVER_INSURANCE). Этот сателлит содержит атрибуты, которые относятся к страхованию отношений между автомобилем и лицом, управляющим им, например, индикатор того, является ли он основным водителем, название страховой компании для этого автомобиля и человека (также может быть отдельным hub) и сводку количества аварий с участием этого автомобиля и водителя. Также включена ссылка на справочную или справочную таблицу под названием R_RISK_CATEGORY, содержащую коды для категории риска, к которой, как считается, относится эта взаимосвязь.

Имя поляОписаниеОбязательный?Комментарий
S_DRIVER_INSURANCE_IDИдентификатор последовательности и суррогатный ключ для спутника по ссылкеНетРекомендуется, но необязательно[18]
L_DRIVER_ID(суррогатный) первичный ключ для ссылки на драйвер, родительский для сателлитада
S_SEQ_NRПорядковый номер или порядковый номер для обеспечения уникальности при наличии нескольких допустимых спутников для одного родительского ключаНет(**)Это может произойти, если, например, у вас есть хаб COURSE, а название курса является атрибутом, но на нескольких разных языках.
S_LDTSДата загрузки (начальная дата) для действительности этой комбинации значений атрибутов для родительского ключа L_DRIVER_IDда
S_LEDTSДата окончания загрузки (конечная дата) для действительности этой комбинации значений атрибутов для родительского ключа L_DRIVER_IDНет
IND_PRIMARY_DRIVERИндикация того, является ли водитель основным водителем данного автомобиляНет (*)
СТРАХОВАЯ КОМПАНИЯНазвание страховой компании для этого автомобиля и этого водителя.Нет (*)
NR_OF_ACCIDENTSКоличество аварий, совершенных этим водителем на этом автомобилеНет (*)
R_RISK_CATEGORY_CDКатегория риска для водителя. Это ссылка на R_RISK_CATEGORYНет (*)
S_RSRCИсточник записи информации в этом спутнике при первой загрузкеда
LOAD_AUDIT_IDИдентификатор в таблице с аудиторской информацией, такой как время загрузки, продолжительность загрузки, количество строк и т. Д.Нет

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

Справочные таблицы

Справочные таблицы являются нормальной частью работоспособной модели хранилища данных. Они предназначены для предотвращения избыточного хранения простых справочных данных, на которые часто ссылаются. Более формально Дэн Линстедт определяет справочные данные следующим образом:

Любая информация, которая считается необходимой для разрешения описаний кодов или преобразования ключей в (sic) согласованным образом. Многие из этих полей носят "описательный" характер и описывать конкретное состояние другой более важной информации. Таким образом, справочные данные хранятся в отдельных таблицах от необработанных таблиц Data Vault..[19]

Справочные таблицы ссылаются на спутники, но никогда не связаны с физическими внешними ключами. Для справочных таблиц нет предписанной структуры: используйте то, что лучше всего работает в вашем конкретном случае, от простых таблиц поиска до небольших хранилищ данных или даже звездочек. Они могут быть историческими или не иметь истории, но рекомендуется придерживаться естественных ключей и не создавать суррогатные ключи в этом случае.[20] Обычно в хранилищах данных есть множество справочных таблиц, как в любом другом хранилище данных.

Справочный пример

Это пример справочной таблицы с категориями риска для водителей транспортных средств. На него можно ссылаться с любого спутника в хранилище данных. Пока мы ссылаемся на него со спутника S_DRIVER_INSURANCE. Справочная таблица - R_RISK_CATEGORY.

Имя поляОписаниеОбязательный?
R_RISK_CATEGORY_CDКод категории рискада
RISK_CATEGORY_DESCОписание категории рискаНет (*)

(*) хотя бы один атрибут является обязательным.

Практика загрузки

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

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

ETL довольно прост и легко поддается автоматизации или шаблону. Проблемы возникают только со ссылками, относящимися к другим ссылкам, поскольку разрешение бизнес-ключей в ссылке приводит только к другой ссылке, которую также необходимо разрешить. Из-за того, что эта ситуация эквивалентна подключению к нескольким концентраторам, этой трудности можно избежать, изменив такие случаи, и это фактически рекомендуемая практика.[11]

Данные никогда не удаляются из хранилища данных, если при загрузке данных не возникла техническая ошибка.

Хранилище данных и многомерное моделирование

Смоделированный слой хранилища данных обычно используется для хранения данных. Он не оптимизирован для производительности запросов, а также его нелегко запрашивать с помощью известных инструментов запросов, таких как Cognos, OBIEE, SAP Business Objects, Пентахо и другие.[нужна цитата ] Поскольку эти вычислительные инструменты конечного пользователя ожидают или предпочитают, чтобы их данные содержались в размерной модели, преобразование обычно необходимо.

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

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

Методология хранилища данных

Методология хранилища данных основана на передовых практиках SEI / CMMI уровня 5. Он включает в себя несколько компонентов CMMI уровня 5 и объединяет их с лучшими практиками от Шесть Сигм, TQM и SDLC. В частности, он ориентирован на гибкую методологию построения и развертывания Скотта Амблера. Проекты хранилищ данных имеют короткий цикл выпуска с контролируемым объемом и должны состоять из производственного выпуска каждые 2–3 недели.

Команды, использующие методологию хранилища данных, должны легко адаптироваться к повторяемым, согласованным и измеримым проектам, которые ожидаются на уровне CMMI 5. Данные, проходящие через систему хранилища данных EDW, начнут следовать жизненному циклу TQM (общее управление качеством), который давно отсутствует в проектах BI (бизнес-аналитики).

Инструменты

2150 Datavault Builder

Wherescape

Vaultspeed

Рекомендации

Цитаты

  1. ^ Зарядите свое хранилище данных Super Charge, стр.74
  2. ^ EDW нового поколения
  3. ^ Зарядите свое хранилище данных Super Charge, стр.21
  4. ^ Супер зарядка хранилища данных, стр.76
  5. ^ Новая бизнес-супермодель, глоссарий, стр. 75
  6. ^ Краткое введение в # datavault 2.0
  7. ^ Data Vault Series 1 - Обзор Data Vault
  8. ^ Data Vault Series 2 - Компоненты Data Vault
  9. ^ Data Vault Series 3 - конечные даты и базовые соединения
  10. ^ Data Vault Series 4 - Связать таблицы, пункт 2.3
  11. ^ а б Data Vault, серия 5 - Практика загрузки
  12. ^ Хранилище данных для чайников, стр. 83
  13. ^ Краткое введение в #datavault 2.0
  14. ^ Анонсирование Data Vault 2.0
  15. ^ Зарядите свое хранилище данных Super Charge, п. 5.20, стр. 110
  16. ^ Зарядите свое хранилище данных Super Charge, стр. 61, почему важны бизнес-ключи
  17. ^ а б Форум Data Vault, раздел стандартов, раздел 3.0 Правила концентратора
  18. ^ а б c Спецификация моделирования хранилища данных v1.0.9
  19. ^ Зарядите свое хранилище данных Super Charge, п. 8.0, стр. 146
  20. ^ Зарядите свое хранилище данных Super Charge, п. 8.0, стр. 149

Источники

  • Халтгрен, Ганс (ноябрь 2012 г.). Моделирование гибкого хранилища данных с помощью Data Vault. Ханс Халтгрен. ISBN  978-0615723082.
  • Линстедт, Дэн (декабрь 2010 г.). Зарядите свое хранилище данных Super Charge. Дэн Линстедт. ISBN  978-0-9866757-1-3.
  • Томас С. Хаммергрен; Алан Р. Саймон (февраль 2009 г.). Хранилище данных для чайников, 2-е издание. Джон Вили и сыновья. ISBN  978-0-470-40747-9.
  • Рональд Дамхоф; Лидвин ван Ас (25 августа 2008 г.). «EDW следующего поколения - отказ от идеи единственной версии правды» (PDF). Журнал базы данных (DB / M). Array Publications B.V.
  • Линстедт, Дэн. «Data Vault Series 1 - Обзор Data Vault». Серия Data Vault. Информационный бюллетень управления данными. Получено 12 сентября 2011.
  • Линстедт, Дэн. «Data Vault, серия 2 - компоненты Data Vault». Серия Data Vault. Информационный бюллетень управления данными. Получено 12 сентября 2011.
  • Линстедт, Дэн. «Data Vault Series 3 - конечные даты и базовые соединения». Серия Data Vault. Информационный бюллетень управления данными. Получено 12 сентября 2011.
  • Линстедт, Дэн. «Data Vault, серия 4 - таблицы ссылок». Серия Data Vault. Информационный бюллетень управления данными. Получено 12 сентября 2011.
  • Линстедт, Дэн. «Data Vault, серия 5 - Практика загрузки». Серия Data Vault. Информационный бюллетень управления данными. Получено 12 сентября 2011.
  • Куненборг, Рональд. «Памятка по правилам хранилища данных v1.0.8» (PDF). Правила хранилища данных. Grundsätzlich IT. Получено 26 сентября 2012. Шпаргалка, отражающая правила в v1.0.8 и дополнительные разъяснения с форумов по правилам в v1.0.8.
  • Линстедт, Дэн. "Спецификация моделирования хранилища данных v1.0.9". Форум Data Vault. Дэн Линстедт. Получено 26 сентября 2012.
  • Линстедт, Дэн. "Спецификация загрузки хранилища данных v1.2". DanLinstedt.com. Дэн Линстедт. Получено 2014-01-03.
  • Линстедт, Дэн. «Краткое введение в #datavault 2.0». DanLinstedt.com. Дэн Линстедт. Получено 2014-01-03.
  • Линстедт, Дэн. "Объявление о выпуске Data Vault 2.0". DanLinstedt.com. Дэн Линстедт. Получено 2014-01-03.
Источники на голландском языке
  • Кетелаарс, M.W.A.M. (2005-11-25). «Datawarehouse-modelleren встретил Data Vault». Журнал базы данных (DB / M). Array Publications B.V. (7): 36–40.
  • Верхаген, К .; Врийкорте, Б. (10 июня 2008 г.). «Relationeel против Data Vault». Журнал базы данных (DB / M). Array Publications B.V. (4): 6–9.

внешняя ссылка