У меня есть набор кубов OLAP, в виде схемы снежных хлопьев, каждая из которых представляет один завод.Возможно ли иметь условные агрегаторы измерения OLAP?
У меня есть три понятия, которые для некоторых заводов явно ведут себя как 3 измерения, а для других заводов явно ведут себя как 2 измерения.
Концепции всегда одни и те же: «продукты», «агенты по продажам» и «клиенты».
Но в некоторых случаях я сомневаюсь, что я должен моделировать его как чисто 3-мерный куб, или я должен поиграть с некоторой трюкой или трюком с двухмерным кубом.
Случаи A и B - это те, которые ясны для меня, и Case C - это тот, который порождает мои недоумения.
СЛУЧАЙ A: Очевидно, что 3 мерный куб
Любой агент может продавать любой продукт для любой компании. Несколько агентов объединяются для одного и того же набора клиентов.
я модель в этом случае, как это:
СЛУЧАЙ B: Очевидно, что 2 мерный куб
Каждый агент 'несет ответственность' за портфель клиентов, и он может продавать любой продукт, но только своим клиентам. Анализ сделан на «текущую ответственность по портфелю», поэтому, если агент покидает компанию, все его клиенты переназначаются новому агенту, и клиент однозначно принадлежит новому агенту.
я модель в этом случае, как это:
СЛУЧАЙ 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
продукта?
Хотелось бы посмотреть, как бы вы это сделали. Спасибо заранее.
Мне не нужно сохранять историю, и даже для примера дата там не отображается. Так что даже Type1 является okey. Я могу считать «рушится». Проблема в том, что я не знаю, как моделировать эту «таблицу мостов», которую вы упоминаете в концепции OLAP-Cube. Я использую таблицы мостов для многих-ко-многим в обычных реляционных базах данных, но я не знаю, как использовать их в «руках» звезды или снежинки, чтобы они были полезны для подхода OLAP. –
Лучший ресурс по методам моделирования размеров - форум Кимбалла. Вместо того, чтобы суммировать чужую работу, вот ссылка, которая приведет вас к необходимой вам информации. [link] http://forum.kimballgroup.com/search?search_keywords=bridge+two+dimensions –
Кроме того, вам может потребоваться пересмотреть свою потребность в датах. Именно так вы будете управлять изменением отношений между Агентом и Клиентом. Практически немыслимо, чтобы размерная модель не содержала таблицу дат, и ваши измерения, похоже, имеют атрибуты, которые могут меняться со временем, изменяя свертывание данных. Примерами могут быть клиенты, которые могут изменять местоположение, продукты, которые могут изменять категорию, и агенты, которые могут изменять Менеджер. Конечно, вы знаете свое требование лучше меня, но я был бы поражен, если бы ваши пользователи не поразили вас такими вопросами, как когда куб будет построен. –