Моделирование хранилища данных

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

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

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

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

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

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

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

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

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

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

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

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

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

История

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

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

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

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

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

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

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

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

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

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

Хабы

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

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

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

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

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

Пример хаба

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

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

Ссылки

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

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

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

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

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

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

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

Спутники

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

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

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

Спутник эффективности - это спутник, построенный на линии связи, «и записывает период времени, когда соответствующая ссылка записывает начало и окончание эффективности».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Слой модели хранилища данных обычно используется для хранения данных. Он не оптимизирован для производительности запросов, и его нелегко выполнять с помощью таких известных инструментов запросов, как Cognos , Oracle Business Intelligence Suite Enterprise Edition , SAP Business Objects , Pentaho и др. Поскольку эти вычислительные инструменты для конечных пользователей ожидают или предпочитают, чтобы их данные содержались в многомерной модели , обычно необходимо преобразование.

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

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

Методология

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

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

Инструменты

Некоторые примеры инструментов:

• 2150 Строитель хранилища данных
• Астера DW Строитель
• Где
• скорость свода
• АвтоматизироватьDV

См. также

• Билл Инмон – американский учёный-компьютерщик
• Озеро данных — система или хранилище данных, хранящихся в естественном/необработанном формате.
• Хранилище данных – Централизованное хранилище знаний
• Жизненный цикл Кимбалла — высокоуровневые последовательности задач, используемые для проектирования, разработки и развертывания хранилища данных или системы бизнес-аналитики. Страницы, отображающие описания викиданных в качестве запасного варианта , разработанные Ральфом Кимбаллом — американским ученым-компьютерщиком и соучредителем хранилища данных. Страницы, отображающие викиданные. описания как запасной вариант
• Зона подготовки — место, где предметы собираются перед использованием.
• Гибкая бизнес-аналитика

Ссылки

Источники

• Линстедт, Дэн (декабрь 2010 г.). Супер зарядите свое хранилище данных . Дэн Линстедт. ISBN  978-0-9866757-1-3 .
• Томас К. Хаммергрен; Алан Р. Саймон (февраль 2009 г.). Хранилище данных для чайников, 2-е издание . Джон Уайли и сыновья. ISBN  978-0-470-40747-9 .
• Рональд Дамхоф; Лидвин ван Ас (25 августа 2008 г.). «EDW следующего поколения – отказ от идеи единой версии истины» (PDF) . Журнал баз данных (DB/M) . Массив Публикаций Б.В.
• Линстедт, Дэн. «Data Vault Series 1 – Обзор хранилища данных» . Серия «Хранилище данных» . Информационный бюллетень по администрированию данных . Проверено 12 сентября 2011 г.
• Линстедт, Дэн. «Data Vault Series 2 – Компоненты хранилища данных» . Серия «Хранилище данных» . Информационный бюллетень по администрированию данных . Проверено 12 сентября 2011 г.
• Линстедт, Дэн. «Data Vault Series 3 – Даты окончания и основные объединения» . Серия «Хранилище данных» . Информационный бюллетень по администрированию данных . Проверено 12 сентября 2011 г.
• Линстедт, Дэн. «Data Vault Series 4 – Таблицы связей» . Серия «Хранилище данных» . Информационный бюллетень по администрированию данных . Проверено 12 сентября 2011 г.
• Линстедт, Дэн. «Data Vault Series 5 – Практика загрузки» . Серия «Хранилище данных» . Информационный бюллетень по администрированию данных . Проверено 12 сентября 2011 г.
• Куненборг, Рональд. «Шпаргалка по правилам хранилища данных v1.0.8» (PDF) . Правила хранилища данных . Grundsätzlich IT . Проверено 26 сентября 2012 г. Шпаргалка, отражающая правила в v1.0.8 и дополнительные разъяснения с форумов по правилам в v1.0.8.
• Линстедт, Дэн. «Спецификация моделирования хранилища данных v1.0.9» . Форум хранилища данных . Дэн Линстедт. Архивировано из оригинала 30 ноября 2012 года . Проверено 26 сентября 2012 г.
• Линстедт, Дэн. «Спецификация загрузки хранилища данных v1.2» . DanLinstedt.com . Дэн Линстедт. Архивировано из оригинала 3 января 2014 г. Проверено 3 января 2014 г.
• Линстедт, Дэн. «Краткое введение в #datavault 2.0» . DanLinstedt.com . Дэн Линстедт. Архивировано из оригинала 3 января 2014 г. Проверено 3 января 2014 г.
• Линстедт, Дэн. «Анонсировано Data Vault 2.0» . DanLinstedt.com . Дэн Линстедт. Архивировано из оригинала 21 августа 2012 г. Проверено 3 января 2014 г.

Источники голландского языка

• Кетелаарс, MWAM (25 ноября 2005 г.). «Моделирование хранилища данных с помощью Data Vault». Журнал базы данных (DB/M) (7). Публикации массива BV: 36–40.
• Верхаген, К.; Врейкорте, Б. (10 июня 2008 г.). «Реляционное хранилище против хранилища данных». Журнал базы данных (DB/M) (4). Публикации массива BV: 6–9.

Литература

• Патрик Куба: гуру хранилища данных. Прагматическое руководство по созданию хранилища данных. Самостоятельная публикация, без указания местоположения, 2020 г., ISBN 979-86-9130808-6.
• Джон Джайлз: Слон в холодильнике. Пошаговые инструкции по достижению успеха в хранилище данных посредством построения бизнес-ориентированных моделей. Техника, Баскин-Ридж, 2019, ISBN 978-1-63462-489-3.
• Кент Грациано: Лучшее моделирование данных. Введение в гибкую инженерию данных с использованием Data Vault 2.0. Data Warrior, Хьюстон, 2015 г.
• Ханс Хультгрен: Моделирование гибкого хранилища данных с помощью Data Vault. Брайтон-Гамильтон, Денвер, 2012 г., ISBN 978-0-615-72308-2.
• Дирк Лернер: Data Vault для гибких архитектур хранилищ данных. В: Стефан Трахаш, Майкл Циммер (ред.): Agile Business Intelligence. Теория и практика. dpunkt.verlag, Гейдельберг, 2016 г., ISBN 978-3-86490-312-0, стр. 83–98.
• Дэниел Линстедт: Супер зарядите свое хранилище данных. Бесценные правила моделирования данных для реализации вашего хранилища данных. Линстедт, Сент-Олбанс, Вермонт, 2011 г., ISBN 978-1-4637-7868-2.
• Дэниел Линстедт, Майкл Ольшимке: Создание масштабируемого хранилища данных с помощью Data Vault 2.0. Морган Кауфманн, Уолтем, Массачусетс, 2016 г., ISBN 978-0-12-802510-9.
• Дэни Шнайдер, Клаус Джордан и другие: Проекты хранилищ данных. Бизнес-аналитика на практике. Хансер, Мюнхен, 2016 г., ISBN 978-3-446-45075-2, стр. 35–37, 161–173.

Внешние ссылки

• Домашняя страница Дэна Линстедта, изобретателя моделирования Data Vault.