Datavault или моделирование хранилища данных — это метод моделирования базы данных , который предназначен для обеспечения долгосрочного исторического хранения данных , поступающих из нескольких операционных систем. Это также метод просмотра исторических данных, который решает такие вопросы, как аудит, отслеживание данных, скорость загрузки и устойчивость к изменениям, а также подчеркивает необходимость отслеживания того, откуда взялись все данные в базе данных . Это означает, что каждая строка в хранилище данных должна сопровождаться атрибутами источника записи и даты загрузки, что позволяет аудитору отслеживать значения обратно к источнику. Концепция была опубликована в 2000 году Дэном Линстедтом .
Моделирование хранилища данных не делает различий между хорошими и плохими данными («плохие» означает не соответствующие бизнес-правилам). [1] Это резюмируется в утверждении, что хранилище данных хранит « единственную версию фактов » (также выраженное Дэном Линстедтом как «все данные, все время») в отличие от практики в других методах хранения данных, когда хранится «единственная версия истины » [2] , где данные, не соответствующие определениям, удаляются или «очищаются». Корпоративное хранилище данных хранилища данных предоставляет и то, и другое; единственную версию фактов и единственный источник истины. [3]
Метод моделирования разработан таким образом, чтобы быть устойчивым к изменениям в бизнес-среде, из которой поступают хранимые данные, путем явного разделения структурной информации от описательных атрибутов . [4] Хранилище данных разработано для обеспечения максимально возможной параллельной загрузки, [5] чтобы очень большие реализации могли масштабироваться без необходимости серьезной переработки.
В отличие от схемы «звезда» ( многомерное моделирование ) и классической реляционной модели (3NF), моделирование хранилищ данных и якорей хорошо подходят для фиксации изменений, которые происходят при изменении или добавлении исходной системы, но считаются передовыми методами, требующими опытных архитекторов данных . [6] И хранилища данных, и якорные модели являются моделями на основе сущностей , [7] но якорные модели имеют более нормализованный подход. [ требуется ссылка ]
В ранние годы Дэн Линстедт называл технику моделирования, которая должна была стать хранилищем данных, общей фундаментальной архитектурой хранилища [8] или общей фундаментальной архитектурой моделирования . [9] В моделировании хранилища данных есть два известных конкурирующих варианта моделирования слоя, где хранятся данные. Либо вы моделируете в соответствии с Ральфом Кимбаллом , с согласованными измерениями и корпоративной шиной данных , либо вы моделируете в соответствии с Биллом Инмоном с нормализованной базой данных . [10] Оба метода имеют проблемы при работе с изменениями в системах, питающих хранилище данных [ необходима ссылка ] . Для согласованных измерений вам также приходится очищать данные (чтобы согласовать их), а это нежелательно в ряде случаев, поскольку это неизбежно приведет к потере информации [ необходима ссылка ] . Хранилище данных предназначено для предотвращения или минимизации влияния этих проблем путем перемещения их в области хранилища данных, находящиеся за пределами области исторического хранения (очистка выполняется в витринах данных), и путем отделения структурных элементов (бизнес-ключей и связей между бизнес-ключами) от описательных атрибутов.
Дэн Линстедт, создатель метода, описывает полученную базу данных следующим образом:
«Модель хранилища данных — это ориентированный на детали, исторический отслеживающий и уникально связанный набор нормализованных таблиц, которые поддерживают одну или несколько функциональных областей бизнеса. Это гибридный подход, охватывающий лучшее из 3-й нормальной формы (3NF) и схемы «звезда» . Дизайн гибкий, масштабируемый, последовательный и адаптируемый к потребностям предприятия» [11]
Философия хранилища данных заключается в том, что все данные являются релевантными данными, даже если они не соответствуют установленным определениям и бизнес-правилам. Если данные не соответствуют этим определениям и правилам, то это проблема для бизнеса, а не для хранилища данных. Определение того, что данные «неправильны», — это интерпретация данных, которая исходит из определенной точки зрения, которая может быть недействительной для всех или в любой момент времени. Поэтому хранилище данных должно собирать все данные, и только при составлении отчетов или извлечении данных из хранилища данных данные интерпретируются.
Другая проблема, на которую хранилище данных является ответом, заключается в том, что все больше и больше возникает потребность в полной прослеживаемости и отслеживаемости всех данных в хранилище данных. Из-за требований закона Сарбейнса-Оксли в США и аналогичных мер в Европе это является актуальной темой для многих внедрений бизнес-аналитики, поэтому фокус любого внедрения хранилища данных заключается в полной прослеживаемости и отслеживаемости всей информации.
Data Vault 2.0 — это новая спецификация. Это открытый стандарт . [12] Новая спецификация состоит из трех столпов: методология ( SEI / CMMI , Six Sigma , SDLC и т. д.), архитектура (среди прочего, входной слой (этап данных, называемый постоянной промежуточной областью в Data Vault 2.0) и уровень представления (витрина данных), а также обработка служб качества данных и основных служб данных) и модель. В рамках методологии определяется реализация лучших практик. Data Vault 2.0 фокусируется на включении новых компонентов, таких как большие данные , NoSQL , а также фокусируется на производительности существующей модели. Старая спецификация (задокументированная здесь по большей части) в значительной степени сосредоточена на моделировании хранилища данных. Она задокументирована в книге: Building a Scalable Data Warehouse with Data Vault 2.0. [13]
Необходимо развивать спецификацию, включив в нее новые компоненты, а также передовой опыт, чтобы системы EDW и BI соответствовали потребностям и желаниям современного бизнеса.
Моделирование хранилища данных было первоначально задумано Дэном Линстедтом в 1990-х годах и выпущено в 2000 году как метод моделирования, доступный для общественности. В серии из пяти статей в The Data Administration Newsletter основные правила метода Data Vault расширены и объяснены. Они содержат общий обзор, [14] обзор компонентов, [15] обсуждение конечных дат и объединений, [16] таблицы ссылок, [17] и статью о методах загрузки. [18]
Альтернативное (и редко используемое) название метода — «Общая фундаментальная архитектура моделирования интеграции». [19]
Data Vault 2.0 [20] [21] появился на рынке в 2013 году и предлагает возможности бесшовной интеграции Big Data, NoSQL, неструктурированных и полуструктурированных данных, а также передовые методы методологии, архитектуры и внедрения.
По словам Дэна Линстедта, модель данных вдохновлена (или создана по образцу) упрощенным представлением нейронов, дендритов и синапсов, где нейроны связаны с концентраторами и сателлитами концентраторов, связи являются дендритами (векторами информации), а другие связи являются синапсами (векторами в противоположном направлении). Используя набор алгоритмов добычи данных, связи могут быть оценены с уверенностью и рейтингами прочности . Их можно создавать и удалять на лету в соответствии с изучением взаимосвязей, которые в настоящее время не существуют. Модель может автоматически трансформироваться, адаптироваться и корректироваться по мере ее использования и подачи новых структур. [22]
Другая точка зрения заключается в том, что модель хранилища данных предоставляет онтологию предприятия в том смысле, что она описывает термины в домене предприятия (концентраторы) и отношения между ними (ссылки), добавляя описательные атрибуты (спутники) при необходимости.
Другой способ думать о модели хранилища данных — это графическая модель . Модель хранилища данных фактически предоставляет модель «на основе графа» с концентраторами и связями в мире реляционных баз данных. Таким образом, разработчик может использовать SQL для получения графических связей с ответами менее чем за секунду.
Хранилище данных пытается решить проблему реагирования на изменения в среде путем отделения бизнес-ключей (которые не так часто меняются, поскольку они уникально идентифицируют бизнес-сущность) и связей между этими бизнес-ключами от описательных атрибутов этих ключей.
Бизнес-ключи и их ассоциации являются структурными атрибутами, образующими скелет модели данных. Метод хранилища данных имеет в качестве одной из своих основных аксиом то, что реальные бизнес-ключи изменяются только при изменении бизнеса и, следовательно, являются наиболее стабильными элементами, из которых можно вывести структуру исторической базы данных. Если вы используете эти ключи в качестве основы хранилища данных, вы можете организовать остальные данные вокруг них. Это означает, что выбор правильных ключей для концентраторов имеет первостепенное значение для стабильности вашей модели. [23] Ключи хранятся в таблицах с несколькими ограничениями на структуру. Эти таблицы ключей называются концентраторами.
Хабы содержат список уникальных бизнес-ключей с низкой склонностью к изменению. Хабы также содержат суррогатный ключ для каждого элемента Хаба и метаданные, описывающие происхождение бизнес -ключа . Описательные атрибуты для информации на Хабе (например, описание ключа, возможно, на нескольких языках) хранятся в структурах, называемых таблицами-сателлитами, которые будут рассмотрены ниже.
Хаб содержит как минимум следующие поля: [24]
Концентратору не разрешается содержать несколько бизнес-ключей, за исключением случаев, когда две системы предоставляют один и тот же бизнес-ключ, но с коллизиями, имеющими разное значение.
Обычно концентраторы должны иметь по крайней мере один спутник. [24]
Это пример таблицы-концентратора, содержащей автомобили, называемой "Car" (H_CAR). Ключом вождения является идентификационный номер транспортного средства .
Ассоциации или транзакции между бизнес-ключами (например, связывающие хабы для клиента и продукта друг с другом через транзакцию покупки) моделируются с использованием таблиц связей. Эти таблицы в основном являются таблицами соединений «многие ко многим» с некоторыми метаданными.
Ссылки могут ссылаться на другие ссылки, чтобы иметь дело с изменениями в гранулярности (например, добавление нового ключа в таблицу базы данных изменит гранулярность таблицы базы данных). Например, если у вас есть связь между клиентом и адресом, вы можете добавить ссылку на ссылку между хабами для продукта и транспортной компании. Это может быть ссылка с названием «Доставка». Ссылка на ссылку в другой ссылке считается плохой практикой, поскольку она вводит зависимости между ссылками, которые затрудняют параллельную загрузку. Поскольку ссылка на другую ссылку — это то же самое, что и новая ссылка с хабами из другой ссылки, в этих случаях создание ссылок без ссылок на другие ссылки является предпочтительным решением (см. раздел о методах загрузки для получения дополнительной информации).
Ссылки иногда связывают концентраторы с информацией, которая сама по себе недостаточна для построения концентратора. Это происходит, когда один из бизнес-ключей, связанных со ссылкой, не является настоящим бизнес-ключом. В качестве примера возьмем форму заказа с «номером заказа» в качестве ключа и строки заказа, которые помечены полуслучайным числом, чтобы сделать их уникальными. Скажем, «уникальный номер». Последний ключ не является настоящим бизнес-ключом, поэтому он не является концентратором. Однако нам нужно использовать его, чтобы гарантировать правильную гранулярность для ссылки. В этом случае мы не используем концентратор с суррогатным ключом, а добавляем сам бизнес-ключ «уникальный номер» к ссылке. Это делается только тогда, когда нет возможности когда-либо использовать бизнес-ключ для другой ссылки или в качестве ключа для атрибутов в сателлите. Дан Линстедт на своем (ныне несуществующем) форуме назвал эту конструкцию «ссылкой с привязной ногой».
Ссылки содержат суррогатные ключи для связанных хабов, их собственный суррогатный ключ для ссылки и метаданные, описывающие происхождение ассоциации. Описательные атрибуты для информации об ассоциации (например, время, цена или сумма) хранятся в структурах, называемых таблицами-сателлитами , которые обсуждаются ниже.
Это пример таблицы связей между двумя хабами для автомобилей (H_CAR) и людей (H_PERSON). Связь называется «Водитель» (L_DRIVER).
Хабы и ссылки формируют структуру модели, но не имеют временных атрибутов и не содержат описательных атрибутов. Они хранятся в отдельных таблицах, называемых спутниками . Они состоят из метаданных, связывающих их с родительским хабом или ссылкой, метаданных, описывающих происхождение ассоциации и атрибутов, а также временной шкалы с датами начала и окончания для атрибута. В то время как хабы и ссылки предоставляют структуру модели, спутники предоставляют «мясо» модели, контекст для бизнес-процессов, которые фиксируются в хабах и ссылках. Эти атрибуты хранятся как в отношении деталей вопроса, так и временной шкалы и могут варьироваться от довольно сложных (все поля, описывающие полный профиль клиента) до довольно простых (сателлит на ссылке только с допустимым индикатором и временной шкалой).
Обычно атрибуты группируются в спутники по исходной системе. Однако описательные атрибуты, такие как размер, стоимость, скорость, количество или цвет, могут изменяться с разной скоростью, поэтому вы также можете разделить эти атрибуты в разных спутниках на основе скорости их изменения.
Все таблицы содержат метаданные, минимально описывающие, по крайней мере, исходную систему и дату, когда эта запись стала действительной, что дает полное историческое представление данных по мере их поступления в хранилище данных.
Спутник эффективности – это спутник, построенный на связи, «и регистрирующий период времени, когда соответствующая связь регистрирует начало и конец эффективности». [26]
Это пример спутника на водителей-связи между хабами для автомобилей и людей, называемого "Страхование водителя" (S_DRIVER_INSURANCE). Этот спутник содержит атрибуты, которые являются специфическими для страхования отношений между автомобилем и человеком, который им управляет, например, индикатор, является ли это основным водителем, название страховой компании для этого автомобиля и человека (также может быть отдельным хабом) и сводка количества аварий с участием этой комбинации транспортного средства и водителя. Также включена ссылка на справочную или справочную таблицу под названием R_RISK_CATEGORY, содержащую коды для категории риска, в которую, как считается, попадает это отношение.
(*) по крайней мере один атрибут является обязательным. (**) порядковый номер становится обязательным, если он необходим для обеспечения уникальности нескольких допустимых спутников на одном концентраторе или канале.
Справочные таблицы являются нормальной частью здоровой модели хранилища данных. Они существуют для предотвращения избыточного хранения простых справочных данных, на которые много ссылаются. Более формально Дэн Линстедт определяет справочные данные следующим образом:
Любая информация, которая считается необходимой для разрешения описаний из кодов или для перевода ключей в (sic) согласованным образом. Многие из этих полей являются «описательными» по своей природе и описывают определенное состояние другой более важной информации. Таким образом, справочные данные находятся в отдельных таблицах от необработанных таблиц Data Vault . [27]
Справочные таблицы ссылаются на Satellites, но никогда не связываются с физическими внешними ключами. Для справочных таблиц нет предписанной структуры: используйте то, что лучше всего подходит в вашем конкретном случае, от простых таблиц поиска до небольших хранилищ данных или даже звезд. Они могут быть историческими или не иметь никакой истории, но рекомендуется придерживаться естественных ключей и не создавать суррогатных ключей в этом случае. [28] Обычно хранилища данных имеют много справочных таблиц, как и любое другое хранилище данных.
Это пример справочной таблицы с категориями риска для водителей транспортных средств. На нее можно ссылаться с любого спутника в хранилище данных. На данный момент мы ссылаемся на нее со спутника S_DRIVER_INSURANCE. Справочная таблица — R_RISK_CATEGORY.
(*) по крайней мере один атрибут обязателен.
ETL для обновления модели хранилища данных довольно прост (см. Data Vault Series 5 – Loading Practices). Сначала вам нужно загрузить все концентраторы, создав суррогатные идентификаторы для любых новых бизнес-ключей. Сделав это, вы теперь можете разрешить все бизнес-ключи в суррогатные идентификаторы, если вы запросите концентратор. Второй шаг – разрешить связи между концентраторами и создать суррогатные идентификаторы для любых новых ассоциаций. В то же время вы также можете создать все сателлиты, которые подключены к концентраторам, поскольку вы можете разрешить ключ в суррогатный идентификатор. После того, как вы создали все новые ссылки с их суррогатными ключами, вы можете добавить сателлиты ко всем ссылкам.
Поскольку хабы не соединены друг с другом, кроме как через ссылки, вы можете загружать все хабы параллельно. Поскольку ссылки не соединены друг с другом напрямую, вы можете загружать все ссылки также параллельно. Поскольку спутники могут быть присоединены только к хабам и ссылкам, вы также можете загружать их параллельно.
ETL довольно прост и легко поддается автоматизации или шаблонизации. Проблемы возникают только со ссылками, относящимися к другим ссылкам, поскольку разрешение бизнес-ключей в ссылке приводит только к другой ссылке, которую также необходимо разрешить. Из-за эквивалентности этой ситуации со ссылкой на несколько концентраторов, этой трудности можно избежать путем ремоделирования таких случаев, и это фактически рекомендуемая практика. [18]
Данные никогда не удаляются из хранилища, если только не возникает техническая ошибка при загрузке данных.
Слой, смоделированный хранилищем данных, обычно используется для хранения данных. Он не оптимизирован для производительности запросов, и его нелегко запрашивать с помощью известных инструментов запросов, таких как Cognos , Oracle Business Intelligence Suite Enterprise Edition , SAP Business Objects , Pentaho и др. [ требуется цитата ] Поскольку эти вычислительные инструменты для конечных пользователей ожидают или предпочитают, чтобы их данные содержались в размерной модели , обычно необходимо преобразование.
Для этой цели концентраторы и связанные с ними спутники на этих концентраторах можно рассматривать как измерения, а ссылки и связанные с ними спутники на этих ссылках можно рассматривать как таблицы фактов в размерной модели. Это позволяет быстро прототипировать размерную модель из модели хранилища данных с использованием представлений.
Обратите внимание, что хотя переместить данные из модели хранилища данных в (очищенную) размерную модель относительно просто, обратный процесс не так прост, учитывая денормализованную природу таблиц фактов размерной модели, принципиально отличную от третьей нормальной формы хранилища данных. [29]
Методология хранилища данных основана на передовых практиках SEI / CMMI Level 5. Она включает в себя несколько компонентов CMMI Level 5 и объединяет их с передовыми практиками Six Sigma , всеобщего управления качеством (TQM) и SDLC. В частности, она ориентирована на гибкую методологию Скотта Эмблера для сборки и развертывания. Проекты хранилища данных имеют короткий, контролируемый по объему цикл выпуска и должны состоять из производственного выпуска каждые 2–3 недели.
Команды, использующие методологию хранилища данных, должны легко адаптироваться к повторяющимся, последовательным и измеримым проектам, которые ожидаются на уровне CMMI 5. Данные, проходящие через систему хранилища данных EDW, начнут следовать жизненному циклу TQM, который долгое время отсутствовал в проектах BI (бизнес-аналитики).
Вот некоторые примеры инструментов: [ требуется пояснение ]