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

Question

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

У меня есть бизнес-процесс, в котором клиенты и неклиенты проводят конференц-звонки с некоторыми из наших сотрудников.

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

Должен ли я использовать согласованное измерение «Клиент» и создать измерение «Неклиент» (для вызывающих абонентов, которые еще не являются клиентами) таким образом (опуская измерения, которые не являются частью этих вопросов):

Или было бы нормально/лучше иметь несогласованное измерение «Посещение», связанное с согласованным измерением «Клиент» следующим образом:

Или существует лучший/стандартный механизм для моделирования подобных бизнес-процессов?

Редактировать:

А как насчет использования модели 2, описанной выше, но создания представления поверх таблицы измерений клиента и измерения обслуживания, чтобы оно выглядело так, как будто это только одно измерение?

Это приемлемая альтернатива ответу Дамира ниже?

Answer 1

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

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

sum(cost_of_connection)
from factAudience
where call_id = 123;

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

РЕДАКТИРОВАТЬ

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

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

Answer 2

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

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

Там есть хорошая дискуссия об этом здесь:

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

Answer 3

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

Answer 4

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