Создание куба на основе существующих таблиц
Ранее уже создано измерение Date (дата). Оно отвечает за дату заказа, дату исполнения/оплаты и дату отгрузки. Можно было бы создавать измерения по одному, но здесь показан другой путь: сразу создать куб (cube) без отдельного создания каждого измерения. Для этого в папке кубы (cubes) выбираем «Новый куб» и идём по мастеру.
Выбор таблицы фактов
В мастере выбираем использование существующих таблиц, потому что исходные таблицы уже готовы. Мастер спрашивает, где таблица фактов (fact table). Можно не выбирать вручную: достаточно нажать, чтобы мастер сам определил её. Таблица, в которую приходят все ключи измерений, и есть таблица фактов. Мастер правильно отмечает Internet Sales (интернет-продажи).
Отбор полей и мер
Далее мастер спрашивает, какие поля брать из таблицы фактов. Ключи Promotion Key (ключ промоакции), Currency Key (ключ валюты), Sales Territory Key (ключ территории продаж) и Revision Number (номер ревизии) не нужны, потому что соответствующих измерений нет. Order Quantity (количество заказа) и Unit Price (цена за единицу) и последующие поля — это меры (measures). Их нужно оставить. Лишние ключи без измерений снимаем.
Подключение измерений
Мастер спрашивает, есть ли готовое измерение для подключения. Да, Dimension Date уже создано. Затем мастер предлагает рассмотреть Customer (клиент), Product (продукт) и Internet Sales. Но Internet Sales — не измерение, а таблица фактов. Мастер видит, что измерение Customer представлено таблицей Customer и раскладывается на подтаблицу Geography (география). Отмечаем создание измерений Product и Customer. Нажимаем Next, задаём имя куба — OLAP Test — и завершаем работу.
Структура созданного куба
В созданном кубе жёлтым подписана центральная таблица фактов. Синим показаны соответствующие измерения. Измерения уже созданы, но если открыть отдельное измерение, видно: есть источник и автоматически пришедшие ключи, но другой информации в измерение не попало. Получается измерение по умолчанию (default dimension): только первичный ключ и больше ничего. Зато не нужно создавать каждое измерение отдельно, указывать связи и ключи — это сделано автоматически. Измерение Product уже есть; всего измерений три, но два из них пока реализованы не очень хорошо.
Особенность измерения Date
Итоговый куб показывает связи. Измерение Date отдельно представлено как Order Date (дата заказа), Due Date (дата исполнения/оплаты) и Ship Date (дата отгрузки). Одно измерение даты раскладывается на три виртуальных измерения (virtual dimensions), которые символизируют каждую связь. Фильтрация и агрегация по каждой дате должны идти независимо: можно запросить заказы с одной даты, а доставку — с другой. Логики разные, поэтому каждая роль становится отдельным виртуальным измерением, хотя физически источник один — таблица Date. Это также произошло автоматически.
Меры и дальнейшая доработка
Наверху видны меры, соответствующие таблице фактов. Все показатели можно считать в разрезе пяти измерений. Теперь нужно немного доработать куб и отдельные измерения, после чего можно разворачивать проект.
Краткие итоги
Автоматическое создание куба на основе готовых таблиц решает задачу быстрого получения каркаса аналитической модели. Ключевая логика — сначала определяется центральный объект, то есть таблица фактов, затем из неё исключаются ключи, для которых нет соответствующих измерений, а оставшиеся числовые поля становятся мерами. Такой порядок снижает риск включения в модель лишних связей и позволяет сосредоточиться на показателях, которые действительно будут анализироваться. Мастер не только выбирает факт, но и предлагает подключить уже существующие измерения, а также создаёт новые на основе доступных таблиц. Это ускоряет работу, однако автоматизм не означает полной готовности: созданные измерения часто остаются пустыми, содержат только первичный ключ и источник, но не имеют атрибутов, иерархий и логики отображения. Поэтому практическая ценность такого куба зависит от последующей ручной доработки. Отдельного внимания требует измерение даты. Одна физическая таблица даты может использоваться в разных ролях: дата заказа, дата исполнения или оплаты, дата отгрузки. Эти роли нельзя смешивать, потому что фильтры и агрегаты по ним имеют разный смысл. Разложение одного измерения на несколько виртуальных ролей позволяет сохранить единый источник, но дать пользователю независимые срезы анализа. Это важный принцип моделирования: физическая структура данных и логическая структура анализа не обязаны совпадать. В практическом применении такой подход полезен при быстром прототипировании, когда нужно оценить состав фактов, мер и измерений до детальной настройки. Он также показывает, какие ключи в таблице фактов не обеспечены измерениями и, следовательно, не могут использоваться в анализе без дополнительного моделирования. После автоматического создания куба необходимо проверить корректность связей, заполнить измерения атрибутами, настроить иерархии и только затем переходить к построению отчётов. Таким образом, основной эффект достигается не самим фактом генерации, а правильным распределением ролей между фактами, мерами и измерениями, а также пониманием границ автоматизации.
Ранее уже создано измерение Date (дата). Оно отвечает за дату заказа, дату исполнения/оплаты и дату отгрузки. Теперь можно сразу создать куб (cube), не создавая каждое измерение отдельно. В папке кубы (cubes) выбираем «Новый куб» и идём по мастеру.
Мастер предлагает использовать существующие таблицы, потому что исходные данные уже готовы. Он спрашивает, где таблица фактов (fact table). Можно не выбирать вручную: мастер сам определяет таблицу, в которую приходят все ключи измерений. Это Internet Sales (интернет-продажи).
Далее нужно выбрать поля из таблицы фактов. Ключи Promotion Key (ключ промоакции), Currency Key (ключ валюты), Sales Territory Key (ключ территории продаж) и Revision Number (номер ревизии) не нужны, потому что для них нет измерений. Order Quantity (количество заказа), Unit Price (цена за единицу) и последующие числовые поля — это меры (measures). Их оставляем, лишние ключи снимаем.
Мастер спрашивает, есть ли готовое измерение. Да, Dimension Date уже создано. Затем он предлагает Customer (клиент), Product (продукт) и Internet Sales. Но Internet Sales — не измерение, а таблица фактов. Мастер видит, что Customer связан с подтаблицей Geography (география). Отмечаем создание Product и Customer. Задаём имя куба — OLAP Test — и завершаем работу.
В созданном кубе жёлтым показана центральная таблица фактов, синим — измерения. Измерения уже созданы, но при открытии отдельного измерения видно: есть источник и автоматически пришедшие ключи, но других данных нет. Это измерение по умолчанию (default dimension): только первичный ключ. Зато не нужно вручную создавать каждое измерение, указывать связи и ключи. Измерение Product уже есть; всего измерений три, но два из них пока реализованы не очень хорошо.
Итоговый куб показывает связи. Измерение Date отдельно представлено как Order Date (дата заказа), Due Date (дата исполнения/оплаты) и Ship Date (дата отгрузки). Одно измерение даты раскладывается на три виртуальных измерения (virtual dimensions). Фильтрация и агрегация по каждой дате должны идти независимо: можно запросить заказы с одной даты, а доставку — с другой. Логики разные, поэтому каждая роль становится отдельным виртуальным измерением, хотя физический источник один — таблица Date. Это произошло автоматически.
Наверху видны меры, соответствующие таблице фактов. Все показатели можно считать в разрезе пяти измерений. После этого нужно немного доработать куб и отдельные измерения, чтобы можно было разворачивать проект.
1. Куб можно создать сразу на основе существующих таблиц, не создавая каждое измерение отдельно.
2. Таблица фактов определяется по входящим ключам измерений; мастер может найти её автоматически.
3. Из таблицы фактов удаляются ключи, для которых нет измерений.
4. Числовые поля таблицы фактов становятся мерами.
5. Internet Sales — таблица фактов, а не измерение.
6. Customer может раскладываться на подтаблицу Geography.
7. Автоматически созданные измерения содержат только первичный ключ и источник, без атрибутов.
8. Готовое измерение Date можно подключить к кубу и использовать в нескольких ролях.
9. Одно измерение Date разложилось на Order Date, Due Date и Ship Date.
10. Роли даты должны фильтроваться и агрегироваться независимо.
11. Виртуальные измерения позволяют одной физической таблице выполнять разные логические роли.
12. После автоматического создания куба требуется доработка куба и измерений.
1. Почему при создании куба можно выбрать использование существующих таблиц?
2. Как определить, какая таблица является таблицей фактов?
3. Почему из таблицы фактов исключают некоторые ключи?
4. Какие поля таблицы фактов относятся к мерам?
5. Почему Internet Sales не выбирается как измерение?
6. Что мастер обнаружил в связи измерения Customer?
7. Какие измерения были добавлены при создании куба?
8. Чем автоматически созданное измерение отличается от полностью настроенного?
9. Почему одно измерение Date представлено тремя виртуальными измерениями?
10. Какие роли даты выделяются в кубе?
11. Почему фильтрация по Order Date и Ship Date должна быть независимой?
12. Что нужно сделать после автоматического создания куба перед развёртыванием проекта?
