Создание вьюшки и подготовка OLAP-куба
Создание представления для источника
Переходим к созданию представления (view) для источника данных. Правой кнопкой мыши выбираем создание нового представления. Открывается мастер. Нужно указать, из какого источника забирать данные. Источник уже создан на предыдущем шаге, поэтому двигаемся дальше. Затем выбираем таблицы, которые будут участвовать в создании OLAP-куба (Online Analytical Processing — аналитическая обработка в реальном времени).
Логика выбора таблиц и куба
Схема «звезда» (star schema) и схема «снежинка» (snowflake schema) уже рассмотрены. Снежинка может быть большой и детальной. Однако отдельный аналитик не работает со всеми размерностями и нюансами сразу. В рамках конкретной витрины он решает частную задачу. Поэтому столь детальный разбор продаж не выполняется постоянно.
Детальный анализ возможен, но он становится результатом объединения анализа по компонентам. В OLAP-кубе делают несколько кубиков на одной снежинке. Снежинка остаётся детальной, а задача куба — быть легковесным, чтобы построение отчётов и аналитика были максимально быстрыми.
Если в отчёте показатель всё равно суммируется, нет смысла хранить его детализированно в кубе. Поэтому OLAP-куб — это не вся витрина из всей снежинки, а небольшой вырез, который используется для построения витрины.
Если нужен другой срез, создаётся ещё один OLAP-куб. Существующий куб не насыщается новыми измерениями. Иначе теряется смысл многопользовательского режима: с одним кубом начнут работать все сотрудники. Одному нужна одна перспектива данных, другому — другая. Каждый работает со своим кубом. Источником для этих кубов остаётся одна и та же схема «звезда» или «снежинка».
Выбор таблиц
Выбираем таблицы. Первая — Dim Customer (измерение «Клиент»): продажи рассматриваются в разрезе клиентов. Dim Date (измерение «Дата») используется по умолчанию. Dim Geography (измерение «География») нужна, чтобы привязать клиентов к географии. Dim Product (измерение «Продукт») нужна, чтобы отслеживать продаваемый продукт. Разложение продукта на категорию и подкатегорию не рассматривается.
Также названы Sales Reason (причина продажи) и Sales Territory (территория продаж). Берём таблицу фактов Fact Internet Sales (факты интернет-продаж). Она касается только онлайн-продаж. Поэтому продавцы и персонал не нужны: интернет-продажи осуществляются без их участия. Итак, используются факт Internet Sales, Dim Product, Dim Date, Dim Geography и Dim Customer; при необходимости — Sales Reason и Sales Territory.
Создание представления
Нажимаем Next. Далее присваивается имя представления. Оставляем настройки по умолчанию, нажимаем Finish и ждём. Представление появляется в списке. По клику виден вырез. Унаследовались все связи по внешнему ключу: они были прочитаны в структуре данных. Это небольшой вырез из схемы «снежинка», наблюдаемой в SQL Server.
Упаковка данных в куб
Данные из источника получены. Теперь их надо упаковать в куб: задать измерения (dimensions) и центральную таблицу фактов. Первый подход — создавать измерения по одному вручную. Позже можно увидеть автоматизированный режим: структура куба создаётся сразу, пустая, без присоединённых данных. В центр помещается Fact Internet Sales, а измерения распределяются вокруг центральной таблицы.
Начинаем с ручного создания измерений. Сначала убираем префиксы в отображаемом имени. Источник как был DimProduct, так и остаётся. Но на уровне отображения префиксы не нужны: кто измерение, а кто центральная таблица, уточнять не требуется. Кроме того, идёт подготовка к фронту, где технические нюансы не важны. Поэтому таблицы переименовываются без префиксов. Получается красивый набор таблиц, и далее создаётся первое измерение.
Краткие итоги
Переход от детальной аналитической модели к рабочему кубу начинается с выбора не всех доступных данных, а только того среза, который нужен для конкретной аналитической задачи. Полная схема «снежинка» хранит много подробностей, но она не предназначена для одновременного использования всеми аналитиками: каждый решает свою задачу, а значит, нуждается в собственной перспективе. Практический смысл такого подхода в том, что куб остаётся легковесным, отчёты строятся быстрее, а детализация не дублируется там, где всё равно выполняется агрегация.
Ключевое проектное решение — не расширять один куб бесконечно, а создавать несколько кубов на общем источнике. Это сохраняет многопользовательский режим и разграничивает аналитические сценарии. Один и тот же источник в виде представления или схемы «звезда/снежинка» может обслуживать разные кубы, но каждый куб получает только необходимые измерения и факты. В практическом примере для интернет-продаж выбраны клиенты, дата, география, продукт и факты онлайн-продаж; продавцы и персонал исключены, поскольку не участвуют в онлайн-сделках. Причины продаж и территории могут добавляться как дополнительные разрезы, если они нужны для конкретной перспективы.
Создание представления упрощает доступ к данным и сохраняет связи по внешним ключам. Это уменьшает ручную работу при построении куба: структура уже прочитана из источника. Далее куб можно собирать вручную, создавая измерения по одному, или автоматизированно, когда сразу формируется пустой каркас. В обоих случаях важно определить центральную таблицу фактов и подчинённые измерения. Подготовка отображаемых имён — не косметика, а часть перехода к фронтенду: пользователю не нужны технические префиксы, ему важны понятные бизнес-сущности. Такой порядок действий снижает сложность модели, ускоряет аналитику и делает сопровождение кубов более управляемым.
Создание OLAP-куба начинается с представления (view). Правой кнопкой создаём новое представление, указываем уже созданный источник и выбираем таблицы для куба. Схема «звезда» или «снежинка» может быть большой и детальной. Но отдельный аналитик решает частную задачу, поэтому весь детальный разбор не нужен. В OLAP-кубе делают несколько кубиков на одной снежинке: снежинка остаётся детальной, а куб должен быть легковесным для быстрых отчётов. Если показатель всё равно агрегируется, хранить его детализированно в кубе не нужно. Куб — это небольшой вырез из снежинки. Если нужен другой срез, создают новый куб, а существующий не расширяют, иначе теряется многопользовательский режим: с одним кубом начнут работать все. Каждый аналитик работает со своим кубом, но источник у них общий — одна схема «звезда/снежинка».
Выбираем таблицы: Dim Customer, Dim Date, Dim Geography, Dim Product, а также Sales Reason и Sales Territory; таблица фактов — Fact Internet Sales. Dim Date используется по умолчанию. Dim Geography нужна для привязки клиентов к географии. Dim Product нужна для отслеживания продукта, без разложения на категории и подкатегории. Fact Internet Sales касается только онлайн-продаж, поэтому продавцы и персонал не включаются: интернет-продажи идут без их участия.
После выбора таблиц нажимаем Next, задаём имя представления, оставляем настройки по умолчанию, Finish. Появляется представление — небольшой вырез из снежинки SQL Server. В нём наследуются связи по внешнему ключу.
Теперь данные надо упаковать в куб: задать измерения и центральную таблицу фактов. Можно создавать измерения вручную по одному. Позже доступен автоматизированный режим: структура куба создаётся сразу, пустая, без данных. В центр помещается Fact Internet Sales, вокруг — измерения. При ручном создании сначала убираем префиксы в отображаемых именах. Источник остаётся прежним, например DimProduct, но на уровне отображения префиксы не нужны: для фронтенда технические нюансы не важны. Таблицы переименовываются без префиксов, получается красивый набор, и создаётся первое измерение.
1. OLAP-куб строится не по всей схеме «снежинка», а по компактному вырезу под конкретную задачу.
2. Представление (view) служит источником для куба и сохраняет связи по внешним ключам.
3. Для разных аналитических перспектив создаются отдельные кубы на общем источнике.
4. Расширение одного куба новыми измерениями ухудшает многопользовательский режим.
5. Куб должен быть легковесным, чтобы отчёты и аналитика работали быстро.
6. Если показатель агрегируется, его избыточная детализация в кубе не нужна.
7. Для интернет-продаж выбираются Dim Customer, Dim Date, Dim Geography, Dim Product и Fact Internet Sales.
8. Продавцы и персонал не включаются, так как онлайн-продажи идут без их участия.
9. Измерения можно создавать вручную по одному или автоматически — сразу пустой структурой.
10. В центре куба размещается таблица фактов, вокруг — измерения.
11. При подготовке к фронту технические префиксы в отображаемых именах убираются.
12. Источник данных при переименовании таблиц остаётся прежним, меняется только отображение.
1. Зачем перед созданием OLAP-куба создаётся представление?
2. Почему OLAP-куб не строится по всей схеме «снежинка»?
3. Что происходит, если один куб насыщать всё новыми измерениями?
4. Почему для разных аналитических задач лучше создавать разные кубы?
5. Какие таблицы выбираются для куба интернет-продаж?
6. Почему в куб не включаются продавцы и персонал?
7. Что наследуется в представлении после выбора таблиц?
8. Что нужно задать при упаковке данных в куб?
9. Чем ручное создание измерений отличается от автоматизированного?
10. Зачем убирать префиксы в отображаемых именах таблиц?
11. Что остаётся неизменным при переименовании таблиц для отображения?
12. Почему куб должен быть легковесным?
