Размерное моделирование - запросы без фактов

Я создаю размерную модель «системы записи разговоров» для услуги VoIP. Я приведу небольшой пример, чтобы показать свой вопрос.

Предположим, у меня есть факт, который представляет собой единственный звонок. И у меня есть измерение под названием «Клиент» и еще одно под названием «Провайдер». (представьте, что есть другие измерения, например, дата, и т. д.)

(Dimension)Client ---> (Fact)Call <--- (Dimension)Provider

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

И давайте предположим, что один клиент связан с провайдером, и у одного провайдера может быть много клиентов.

Итак, вот и вопрос. Как я могу создать такой запрос: какие клиенты есть у каждого провайдера?

Кажется, что это запрос, который находится между двумя измерениями. Я не могу говорить об этом факте, потому что, если клиент никогда не использовал службу, он не будет в таблице фактов вызовов, и он не будет участвовать в этом запросе «Клиенты на поставщика».

Я подумал про себя, что один из способов сделать это - создать измерение ролевой игры, представление измерения клиента и добавить его непосредственно в измерение поставщика, просто чтобы выполнять подобные запросы. Это было бы примерно так:

(Dimension)Client ---> (Fact)Call <--- (Dimension)Provider <--- (Dimension)View Client

Конечно, при таком подходе пользователь должен быть очень осторожен, чтобы не использовать это измерение View Client с таблицей фактов, поскольку это может дублировать строки фактов.

Итак, это одна из ситуаций, когда мне нужно использовать известные таблицы фактов, не содержащие фактов?

Как правильно это сделать?

Спасибо!


person João Guilherme    schedule 14.06.2012    source источник


Ответы (1)


Ролевые измерения следует использовать, когда вы «перерабатываете» измерение, которое будет использоваться несколько раз в одной и той же таблице фактов (например, Дата звонка, Дата обслуживания и т. Д.).

Похоже, это не то, что вы ищете. Вместо этого, если связь действительно одна ко многим, я бы просто добавил идентификатор поставщика непосредственно в измерение клиента (без представления или чего-то еще), с пониманием того, что эта связь не имеет ничего общего с фактами.

По сути, когда дело доходит до такого рода запросов, думайте о «провайдере» как о просто атрибуте, созданном снежинкой клиента.

Однако похоже, что вы можете быть уверены, что у вас нет отношений «многие-ко-многим» между клиентами и поставщиками (клиент может использовать несколько поставщиков, а поставщик может иметь несколько клиентов). Отношение "многие ко многим" моделируется размерно как таблица фактов. Таблица фактов может быть снимком текущего момента времени с историей или без нее. Нужны всего два столбца, Client и Provider. Если вы хотите вести учет взаимоотношений между клиентом и поставщиком в какой-то период времени, вы просто добавляете отметку даты.

Обратите внимание, что не имеющий фактов факт также будет работать для моделирования отношения «один-много» (и если модель изменится на внутренней стороне, ваш ETL уже готов ...)

person N West    schedule 18.06.2012