Различия между Data Vault и многомерным моделированием?

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

Data Vault больше подходит для крупных корпоративных хранилищ данных, также рекомендованных Биллом Инмоном, но не подходящих для анализа и отчетности, так как вам все равно может потребоваться многомерное моделирование для создания «виртуальных» витрин данных. Загляните в блоги, например, от Martijn Evers, Hennie de Nooijer или Ronald Damhof.

Data Vault более гибкий, легче добавлять новые источники, больше возможностей для аудита и постоянно хранит все данные, так что вы всегда сможете воссоздать свои DM.

Таким образом, можно сделать вывод, что идеальной ситуацией является использование Data Vault для вашего корпоративного хранилища данных и многомерное моделирование для ваших Datamarts.

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

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

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

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

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

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

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

Я считаю, что Data Vault обеспечивает операционную гибкость, тогда как существующее обсуждение (Кимбалл / Инмон) больше вращается вокруг «гибкости бизнеса» (из-за отсутствия лучшей терминологии).

Data Vault позволяет вам оставаться ближе к источнику с точки зрения его детализированных объектов. Это делает модель «проверяемой» и масштабируемой. Это помогает с гибкостью спецификаций ИСТОЧНИКА.

Поэтому это полезно, например, между проекты миграции, служащие базой для подачи более ориентированных на бизнес DWH / Datamarts, которые требуют интегрированного представления как старых, так и новых. Однако мой опыт показывает, что если вы начнете заполнять карты данных непосредственно из этой модели, вы получите множество объединений и особенно рекурсий просто потому, что вы далеки от бизнес-концепций. Не совсем плохо для некоторых баз данных, поэтому выбор частично зависит от программного обеспечения (например, Teradata гораздо больше любит присоединяться, чем Oracle). Однако в целом я считаю, что если вам нужна гибкость в области TARGET (бизнес), вы попадете в дискуссию inmon-kimball, и было бы неплохо рассмотреть возможность пространственного моделирования вместо хранилища данных с этой стороны.

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

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

Подводя итог, я бы сказал, что по мере того, как среда бизнес-аналитики становится более «зрелой», бизнес узнает, что он может делать с данными, и требования с этой стороны становятся все более сложными. Data Vault - не лучший вариант.

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