Вам действительно нужно хранилище данных?

Методология моделирования Data Vault 2.0 приобрела огромную популярность с момента ее запуска в 2013 году. Это гибридная модель, сочетающая в себе преимущества третьей нормальной формы (3NF) и архитектуры звездообразной схемы, что делает ее идеальным решением для инженеров хранилищ данных.

Но стоит ли внедрять его в архитектуру вашего хранилища данных? Ответ не однозначен, поскольку необходимо учитывать множество факторов. Итак, давайте углубимся и выясним, подходит ли вам Data Vault 2.0.

Когда следует внедрять хранилище данных?

Архитектура хранилища данных призвана дополнять схема звезды методология моделирование вашего хранилища данных. Он действует как дополнительный уровень между уровнями подготовки и отчетности.

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

Вот тут-то и вступает в игру хранилище данных.

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

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

Дополнительным преимуществом этих таблиц ссылок является их способность поддерживать отношения «многие ко многим». В модели 3NF вам придется создать таблицу-мост для поддержания такого рода отношений, но таблицам связей присуща такая возможность. Никаких изменений схемы не потребуется, даже если вы измените отношение с «один-ко-многим» на «многие-ко-многим».

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

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

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

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

Когда это перебор?

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

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

Проектирование хранилища может оказаться утомительной и трудоемкой задачей. Если ваша единственная цель — создавать отчеты на основе ваших данных, зачем беспокоиться? Вы можете сразу перейти от промежуточной базы данных к звездообразной схеме, что, возможно, является лучшим выбором для создания отчетов.

Заключение

Теперь, когда мы обсудили все факторы, которые следует учитывать, вот вывод:

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

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

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

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

Узнайте, как лучше всего реализовать хранилище данных. Свяжитесь с нами по адресу [электронная почта защищена] Cегодня!