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

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

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

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

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

История и философия [ править ]

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

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

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

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

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

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

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

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

История [ править ]

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

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

Data Vault 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 Series 5 - Загрузки практики ). Сначала вам нужно загрузить все концентраторы, создав суррогатные идентификаторы для любых новых бизнес-ключей. Сделав это, вы можете преобразовать все бизнес-ключи в суррогатные идентификаторы, если запросите концентратор. Второй шаг - разрешить связи между концентраторами и создать суррогатные идентификаторы для любых новых ассоциаций. В то же время вы также можете создать все спутники, подключенные к концентраторам, поскольку вы можете разрешить ключ в суррогатный идентификатор. После того, как вы создали все новые ссылки с их суррогатными ключами, вы можете добавить спутники ко всем ссылкам.

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

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

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

Хранилище данных и многомерное моделирование [ править ]

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

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

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

Методология хранилища данных [ править ]

Методология хранилища данных основана на передовых практиках SEI / CMMI уровня 5. Он включает в себя несколько компонентов CMMI уровня 5 и объединяет их с лучшими практиками Six Sigma , 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)