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

Эта статья нужны дополнительные цитаты для проверка. Пожалуйста помоги улучшить эту статью к добавление цитат в надежные источники. Материал, не полученный от источника, может быть оспорен и удален. Найдите источники: «Моделирование хранилища данных»  – Новости  · газеты  · книги  · ученый  · JSTOR (Ноябрь 2016) (Узнайте, как и когда удалить этот шаблон сообщения)

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

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

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

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

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

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

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

«Модель 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) и людей (H_PERSON). Ссылка называется «Драйвер» (L_DRIVER).

Спутники

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В 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

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

Цитаты

Источники

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

• Дом для пользователей сообщества Data Vault
• Путь к сертификации
• Домашняя страница Дэна Линстедта, изобретателя моделирования Data Vault
• Веб-сайт, посвященный Data Vault, поддерживается Дэном Линстедтом.
• Видео на Youtube о подходе и методологии моделирования Data Vault
• Сайт для обмена слайдами Дэна Линстедта
• Сайт сертификации Data Vault
• Сайт Agile Data
• Сайт дисциплинированной гибкой доставки (DAD)