В предыдущих статьях, мы познакомились с основами DATA VAULT, расширением DATA VAULT до более подходящего для анализа состояния и созданием BUSINESS DATA VAULT. Настало время завершать серию третьей статьей.
Как я анонсировал в предыдущей публикации, эта статья будет посвящена теме BI, а точнее подготовке DATA VAULT в качестве источника данных для BI. Рассмотрим, как создать таблицы фактов и измерений и, тем самым, создать схему звезда.
Когда я начал изучать англоязычные материалы по теме создания витрин данных над DATA VAULT у меня возникло ощущение достаточной сложности процесса. Так как статьи имеют внушительный объем, там присутствуют отсылки к изменениям в формулировках, появившихся в методологии Data Vault 2.0, обозначается важность этих формулировок.
Однако, углубившись в перевод, стало понятно, что процесс этот не так уж и сложен. Но, возможно у вас сложится другое мнение.
И так, давайте переходить к сути.
Самое сложная для понимания информация:
И это очевидно, после прочтения статьи об основах DATA VAULT. Хабы хранят уникальные ключи бизнес объектов, их сателлиты состояния атрибутов бизнес объектов привязанные ко времени, сателлиты, привязанные к линкам поддерживающим транзакции, хранят числовые характеристики этих транзакций.
На этом теория, в принципе заканчивается.
Но, все же, на мой взгляд, необходимо отметить пару понятий, которые могут встретиться в статьях о методологии DATA VAULT:
Понятие “Raw Data Marts” – обозначает витрины построенные, над данными DATA VAULT путем выполнения достаточно простых JOIN’ов. Подход “Raw Data Marts” позволяет гибко и в короткие сроки расширить проект хранилища информацией, подходящей для анализа. Такой подход не подразумевает выполнение сложных трансформаций данных и исполнения бизнес правил перед помещение в витрину, однако, данные “Raw Data Marts” должны быть понятны бизнес пользователю и призваны служить основой для дальнейшего преобразования, например, инструментами BI.
Понятие “Information Marts” появилось в методологии Data Vault 2.0, оно заменило старое понятие “Data Marts”. Это изменение обусловлено осознанием задачи по реализации модели данных для построения отчетов как преобразование данных в информацию. Схема “Information Marts”, в первую очередь, должна обеспечивать бизнес пригодной для принятия решений информацией.
Достаточно многословные определения отражают два простых факта:
Если обратиться к примерам хранения информации о сотруднике можно сказать, что витрина отображающая текущий (действующий на сегодня) номер телефона сотрудника — это витрина типа “Raw Data Marts”. Для формирования такой витрины используется бизнес ключ сотрудника и функция MAX(), использованная на атрибуте даты загрузки в сателлит (MAX(SatLoadDate)). Когда требуется хранения истории изменения атрибута в витрине – используется, нужно понимать с какой по какую дату телефон был актуален, первичным ключом такой таблице сложит компиляция бизнес ключа и даты загрузки в сателлит, также добавляется поле даты окончания периода актуальности.
Создание витрины, хранящей актуальную информацию каждого атрибута нескольких сателлитов, входящего в хаб, например, номер телефона, адрес, ФИО, подразумевает использование PIT таблицы, через обращение к которой легко получить все даты актуальности. Витрины такого типа относят к “Information Marts”.
Оба подхода актуальны как для измерений, так и фактов.
Для создания витрин, хранящих информацию о нескольких линках и хабах может быть задействовано обращение к BRIDGE таблицам.
Этой статьей я завершаю цикл о концепции DATA VAULT, надеюсь информация, которой я поделился будет полезна в реализации ваших проектов.
Как всегда, в завершении, несколько полезных ссылок:
Как я анонсировал в предыдущей публикации, эта статья будет посвящена теме BI, а точнее подготовке DATA VAULT в качестве источника данных для BI. Рассмотрим, как создать таблицы фактов и измерений и, тем самым, создать схему звезда.
Когда я начал изучать англоязычные материалы по теме создания витрин данных над DATA VAULT у меня возникло ощущение достаточной сложности процесса. Так как статьи имеют внушительный объем, там присутствуют отсылки к изменениям в формулировках, появившихся в методологии Data Vault 2.0, обозначается важность этих формулировок.
Однако, углубившись в перевод, стало понятно, что процесс этот не так уж и сложен. Но, возможно у вас сложится другое мнение.
И так, давайте переходить к сути.
Таблицы измерений и фактов в DATA VAULT
Самое сложная для понимания информация:
- Таблицы измерений строятся на информации хабов и их сателлитов;
- Таблицы фактов строятся на информации линков и их сателлитов.
И это очевидно, после прочтения статьи об основах DATA VAULT. Хабы хранят уникальные ключи бизнес объектов, их сателлиты состояния атрибутов бизнес объектов привязанные ко времени, сателлиты, привязанные к линкам поддерживающим транзакции, хранят числовые характеристики этих транзакций.
На этом теория, в принципе заканчивается.
Но, все же, на мой взгляд, необходимо отметить пару понятий, которые могут встретиться в статьях о методологии DATA VAULT:
- Raw Data Marts – витрины “сырых” данных;
- Information Marts – информационные витрины.
Понятие “Raw Data Marts” – обозначает витрины построенные, над данными DATA VAULT путем выполнения достаточно простых JOIN’ов. Подход “Raw Data Marts” позволяет гибко и в короткие сроки расширить проект хранилища информацией, подходящей для анализа. Такой подход не подразумевает выполнение сложных трансформаций данных и исполнения бизнес правил перед помещение в витрину, однако, данные “Raw Data Marts” должны быть понятны бизнес пользователю и призваны служить основой для дальнейшего преобразования, например, инструментами BI.
Понятие “Information Marts” появилось в методологии Data Vault 2.0, оно заменило старое понятие “Data Marts”. Это изменение обусловлено осознанием задачи по реализации модели данных для построения отчетов как преобразование данных в информацию. Схема “Information Marts”, в первую очередь, должна обеспечивать бизнес пригодной для принятия решений информацией.
Достаточно многословные определения отражают два простых факта:
- Витрины типа “Raw Data Marts” строятся на сыром (RAW) DATA VAULT, хранилище содержащем только базовые понятия: HUBS, LINKS, SATELLITES;
- Витрины “Information Marts” строятся с использование элементов BUSINESS VAULT: PIT, BRIDGE.
Если обратиться к примерам хранения информации о сотруднике можно сказать, что витрина отображающая текущий (действующий на сегодня) номер телефона сотрудника — это витрина типа “Raw Data Marts”. Для формирования такой витрины используется бизнес ключ сотрудника и функция MAX(), использованная на атрибуте даты загрузки в сателлит (MAX(SatLoadDate)). Когда требуется хранения истории изменения атрибута в витрине – используется, нужно понимать с какой по какую дату телефон был актуален, первичным ключом такой таблице сложит компиляция бизнес ключа и даты загрузки в сателлит, также добавляется поле даты окончания периода актуальности.
Создание витрины, хранящей актуальную информацию каждого атрибута нескольких сателлитов, входящего в хаб, например, номер телефона, адрес, ФИО, подразумевает использование PIT таблицы, через обращение к которой легко получить все даты актуальности. Витрины такого типа относят к “Information Marts”.
Оба подхода актуальны как для измерений, так и фактов.
Для создания витрин, хранящих информацию о нескольких линках и хабах может быть задействовано обращение к BRIDGE таблицам.
Этой статьей я завершаю цикл о концепции DATA VAULT, надеюсь информация, которой я поделился будет полезна в реализации ваших проектов.
Как всегда, в завершении, несколько полезных ссылок:
- Статья Кента Грациано, в которой помимо детального описания содержатся схемы модели;
- Книга: “Building a Scalable Data Warehouse with DATA VAULT 2.0”;
- Статья “Основы Data Vault”;
- Статья “Развитие DATA VAULT и переход к BUSINESS DATA VAULT”.
