Звездообразная схема: отдельные измерения для клиентов и неклиентов или общие измерения для обслуживающего персонала?

Нет необходимости разделять клиентов на две таблицы (измерения). Просто поместите всех клиентов, активных и потенциальных клиентов в одну таблицу измерений. Затем вы можете ввести атрибут IsActive (столбец), чтобы различать платящих клиентов и потенциальных клиентов. Рано или поздно вы воспользуетесь инструментом интеллектуального анализа данных, чтобы узнать больше о клиентах и ​​о том, что отличает людей, которые готовы платить за ваши услуги, от тех, кто этого не делает. Чтобы алгоритм работал, вы должны предоставить данные для обеих групп людей - тех, кто платит, и тех, кто не платит. Подводя итог, потенциальные клиенты принадлежат к той же таблице, что и платящие клиенты.

При этом вы можете использовать свою модель № 1. Убедитесь, что меры в таблице фактов имеют смысл. Например, если в call_id = 123 участвовало 10 человек, то

sum(cost_of_connection)
from factAudience
where call_id = 123;

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

ИЗМЕНИТЬ

«Платящий клиент» и «потенциальный клиент» являются типами клиентов, поэтому принадлежат к одной и той же таблице измерений - dimClient. Где-то в ДВ есть factSale (или аналогичный) с FK на dimSale. Даже если у вас нет столбца в dimClient, чтобы различать платящих и потенциальных клиентов, вы все равно можете получить платящих клиентов, присоединившись к factSale и dimClient.

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

Я бы выбрал второе: он моделирует участников в их собственном, выделенном измерении, в то же время позволяя вам раскрыть их клиентскую принадлежность (или иным образом) через атрибут в этом измерении, что, вероятно, является тем способом, которым вы хотели бы детализировать реальная жизнь («покажите мне всех участников», а затем «а теперь кто из них - клиенты»).

В вашем клиентском измерении я бы заполнил client_id для всех участников в соответствии с "неизвестным" элементом, где участник не является клиентом.

Здесь есть интересное обсуждение:

http://crpit.com/confpapers/CRPITV75Riazati.pdf

Это не имеет большого значения. Вторая версия, возможно, более правильная, но поддерживает ли это ваша система olap?

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