0

У меня есть набор кубов OLAP, в виде схемы снежных хлопьев, каждая из которых представляет один завод.Возможно ли иметь условные агрегаторы измерения OLAP?

У меня есть три понятия, которые для некоторых заводов явно ведут себя как 3 измерения, а для других заводов явно ведут себя как 2 измерения.

Концепции всегда одни и те же: «продукты», «агенты по продажам» и «клиенты».

Но в некоторых случаях я сомневаюсь, что я должен моделировать его как чисто 3-мерный куб, или я должен поиграть с некоторой трюкой или трюком с двухмерным кубом.

Случаи A и B - это те, которые ясны для меня, и Case C - это тот, который порождает мои недоумения.

СЛУЧАЙ A: Очевидно, что 3 мерный куб

Любой агент может продавать любой продукт для любой компании. Несколько агентов объединяются для одного и того же набора клиентов.

я модель в этом случае, как это:

enter image description here

СЛУЧАЙ B: Очевидно, что 2 мерный куб

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

я модель в этом случае, как это:

enter image description here

СЛУЧАЙ C: Мои сомнения

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

Например:

  • Alice управляет TablesAndWoods ltd и GreenForest ltd.
  • Bob руководит Chairs ltd и FastWheels ltd.
  • Carol управляет Forniture ltd ТОЛЬКО для ProductType = 'machinery', а также управляет FrozenBottles ltd для ЛЮБОГО типа продукта.
  • Dave также управляет Forniture ltd, но ТОЛЬКО для ProductType = 'consumables', а также управляет HighCeilings ltd для ЛЮБОГО типа продукта.

ВОПРОС:

В этом примере "Случай C":

ли customer и agent независимые размеры, поскольку Forniture ltd имеет отношение как к Carol и Dave, так что это 3D-куб?

Или это 2D куб, где agent не является самостоятельным измерение, но это является агрегатором customer «кондиционер» как-то агрегатор ProductCategory продукта?

Хотелось бы посмотреть, как бы вы это сделали. Спасибо заранее.

ответ

2

Вот как я бы моделировать его:

Ваш факт таблица продаж.

Ваши размеры (возможно) Дата, Продукт, Заказчик и Агент. Это наиболее близко к вашему делу A.

Свернуть ваши снежинки (белые сущности) в размеры. Наличие этих объектов предполагает, что вы должны рассмотреть вопрос о необходимости изменения медленно изменяющихся измерений типа 2 для анализа во время.

Рассмотрите таблицу Bridge, чтобы зафиксировать отношения между многими агентами и Продуктом.

+0

Мне не нужно сохранять историю, и даже для примера дата там не отображается. Так что даже Type1 является okey. Я могу считать «рушится». Проблема в том, что я не знаю, как моделировать эту «таблицу мостов», которую вы упоминаете в концепции OLAP-Cube. Я использую таблицы мостов для многих-ко-многим в обычных реляционных базах данных, но я не знаю, как использовать их в «руках» звезды или снежинки, чтобы они были полезны для подхода OLAP. –

+1

Лучший ресурс по методам моделирования размеров - форум Кимбалла. Вместо того, чтобы суммировать чужую работу, вот ссылка, которая приведет вас к необходимой вам информации. [link] http://forum.kimballgroup.com/search?search_keywords=bridge+two+dimensions –

+1

Кроме того, вам может потребоваться пересмотреть свою потребность в датах. Именно так вы будете управлять изменением отношений между Агентом и Клиентом. Практически немыслимо, чтобы размерная модель не содержала таблицу дат, и ваши измерения, похоже, имеют атрибуты, которые могут меняться со временем, изменяя свертывание данных. Примерами могут быть клиенты, которые могут изменять местоположение, продукты, которые могут изменять категорию, и агенты, которые могут изменять Менеджер. Конечно, вы знаете свое требование лучше меня, но я был бы поражен, если бы ваши пользователи не поразили вас такими вопросами, как когда куб будет построен. –