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

Question

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

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

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

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

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

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

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

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

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

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

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

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

Спасибо!

Answer 1

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

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

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

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

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