Имеется следующая информация о визитах клиентов:
Объект, Город, Страна, Время начала визита, время конца визита, Доход.
Требуется создать куб на основе этих данных.
И если я правильно понимаю, всё было бы хорошо и просто:
Измерение времени (дата - месяц - квартал - год - имя месяца - месяц года - номер квартала года),
измерение объект (ID Объекта - Имя объекта),
измерение город (Id Города - Имя города - Имя Страны),
и меры Число визитов, Число визитов без оплаты, и ДоходПолученный.
Но... Но число визитов и доход надо разбить ещё и по продолжительности визитов (до 15 минут, до часа, до двух часов, до трёх часов, до 4 часов, более 4 часов).
Продолжительность визита вычисляется как



И вопрос вот в чём - создавать дополнительное измерение ВремяВизита или дополнительные меры для числа визитов и дохода? Что правильнее? И поправьте меня в остальных мерах и измерениях, если в чём ошибся. imho, правильнее создать измерение.

javajdbc,
Представил себе продвинутый эскорт-сервис с базами данных, отчетностью и кубами для аналитиков. Посмеялся.

javajdbc,

Что касается гранулярности - то в моём случае это совокупность визитов за день, а то и за месяц, а не отдельный визит.
При этом один из срезов, который сейчас делается - как раз по объектам и продолжительности визитов .

javajdbc,

Вопрос интересный появился: раз у меня зависимость объект - Локация, то делать Снежинку
create table dwh.DimObject
(DimObjectID int identity (1,1),
ObjectShortName varchar(4),
ObjectFullName varchar(40),
LocationID int
)

create table dwh.DimLocation
(LocationID int identity (1,1),
CityName varchar(40),
CountryName varchar(40),
)

или всё-таки Звезду

create table dwh.DimObject
(DimObjectID int identity (1,1),
ObjectShortName varchar(4),
ObjectFullName varchar(40)
)

create table dwh.DimLocation
(LocationID int identity (1,1),
CityName varchar(40),
CountryName varchar(40),
)

?
Пока иду по первому варианту.

По итогам размышлений у меня получается две таблицы фактов.
Первая - с измерение "Объект - Город - Страна" и измерением времени.
Вторая - с измерением "Объект - Город - Страна", измерением времени и измерением "Длительность визита на объект", предложенным javajdbc.

Причина в том, что к ряду мер применение измерения "Длительность визита на объект" невозможно (пример таких мер - число звонков или число людей, прошедших мимо объекта или число сорвавшихся заказов).
Как я понимаю, обе таблицы фактов можно засунуть в один и тот же куб.
А вот что делать потом, когда засунул в куб вторую таблицу фактов? Связывать их между собой, не связывать, добавлять в куб дополнительные копии таблиц измерений, или привязывать к таблицам фактов одни и те же копии таблиц измерений? Или надо сделать что-то ещё?
И будет ли возможность в один отчёт засунуть меры из обоих таблиц, или нет?

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

Коллеги, возвращаемся к нашим "эскорт-сервисам".

Вопрос первый: данные до доходам теперь требуется хранить в трёх валютах. То есть число строк с доходами утраивается. А данные по числу визитов от валюты не зависит. Как правильно хранить данные?
В двух таблицах фактов, связанных друг с другом по ID "эскорт-сервиса" и дате? Или оставить как есть - в большой таблице, а в отчётах по посещаемости ставить фильтр по коду одной из валют? Второй вариант мне не нравится из-за разбухания данных, а первый ещё не пробовал никогда.

И второй вопрос - требуется добавить в куб данные по плану и прогнозу посещаемости и дохода. Здесь доход тоже будет пересчитываться в три валюты, но проблема в другом. Проблема в том, что здесь данные свёрнуты по месяцам, а не по дням. Как их правильно связать с основными данными (основные данные свёрнуты по дням)?

vikkiv,

Я правильно понимаю, что для группы мер прогнозов надо будет делать отдельное измерение дат? Или привязывать существующее, но по столбцу месяцев?

vikkivDaniilSeryi,

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

Спасибо. Буду завтра пробовать.

И ещё один дополнительный вопрос:
Для некоторых расчётов в отчётах нужно использовать редко меняющиеся (раз в год или реже) переменные, как плановое "время работы".
Как эти данные хранить в кубе и подтягивать в отчёты?
Вариант с столбцом данных в мерах - тут избыточность данных, но минимум трудностей с использованием.
А какие ещё варианты?

StarikNavy,

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

Как это можно сделать?

Нашёл и сделал.

Возник другой вопрос - в настройках проекта стоит DeployChangesOnly. При этом после внесения изменений в куб (добавление новой меры) выбираю Build куб, затем Deploy куба, и оп-па - база данных будет rewritten! Соответственно, все созданные роли уничтожаются, надо давать права заново.
Вопрос - как избежать перезаписи базы данных куба на SSAS?

vikkivDaniilSeryi,

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

Как понимаю, у меня единая таблица измерения (где ключ даты, сама дата, месяц_года, квартал_года, год) для такого маневра должна быть распилена на четыре (дата-месяц-квартал-год) с соответствующими ключами, изменениями в иерархиях и кубе?