Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / правильная организация проектов и баз / 5 сообщений из 5, страница 1 из 1
03.04.2018, 01:24
    #39624391
нуб987
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
правильная организация проектов и баз
в MSAS2000 можно было создавать олап-базы, внутри которых делать нужное кол-во кубов.
Например, сделать базу "продажи" и создать там несколько кубов разных направлений продаж. А рядом создать базу "Склады" и создать кубы по складам.
Внутри базы можно было сделать SharedDimensions и использовать эти общие размерности в разных кубах одной базы (например, размерность дат или менеджеров).
Так же можно было внутри каждого куба создавать размерности только для этого куба. Все просто, наглядно и удобно - древовидная структура: заходим внутрь и видим объекты.

Подскажите, как сделать такую же организацию кубов на новом для меня СКЛ2012 ?

Сейчас все размерности лежат в общей куче одной базы.
И если мне нужно для разных кубов одной базы сделать разные размерности клиентов, то в MSAS2000 я бы просто внутри каждого куба создал бы свои размерности.
А сейчас приходится создавать их в общей куче с именами Clients_Cube1, Clients_Cube2. Или же делать разные базы Sales1, Sales2 с соответствующими кубами внутри.

Правильно ли я понимаю, что теперь внутри одной базы все размерности являются SharedDimension'ами?

И по какому принципу правильно собирать кубы в одной базе?
...
Рейтинг: 0 / 0
03.04.2018, 02:16
    #39624397
vikkiv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
правильная организация проектов и баз
нуб987,

по множеству принципов - в зависимости от приоритетов. в объединении есть преимущества и недостатки.

если по сходу по быстрому придумать то примерно так:

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

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

в третьих обслуживание с ProcessUpdate на тяжелом измерении в одной базе где это измерение используется в нескольких кубах (или даже несколько раз в одном кубе) - займёт намного меньше времени чем обслуживание такого измерения между несколькими базами (т.е. временные и серверные ресурсы расходуются намного меньше).

при больших нагрузках со стороны пользователей - базы легче разнести по разным серверам.

дальше идут безопасность (разные админы баз для разных департаментов), риски вылетов/сбоев, патчей/обновлений, тяжесть большого проекта для среды разработки (VisualStudio), удобство для пользователей (или IT персонала) в обслуживании источников/линков для отчётности, и множество прочих косметических преимуществ/недостатков до чего-то посерьёзнее..
...
Рейтинг: 0 / 0
03.04.2018, 02:27
    #39624399
vikkiv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
правильная организация проектов и баз
а по измерениям - потенциально да: могут, но: нет, не обязательно все измерения являются Shared Dimension (между кубами), это уже как настроишь - собственно включать (добавлять) измерение в куб или нет - чисто вопрос необходимости (для Master Data или связи с фактами),

отдельным пунктом - где настраивать безопасность/права доступа (и/или видимости) для пользователей - на уровне куба или на корневом уровне самой базы.

с точки зрения наименований в корне каталога проекта/базы и имени измерения в самом кубе - это тоже на своё усмотрение / по необходимости, в корне базы называй как хочешь, в кубах - как нужно пользователям.
...
Рейтинг: 0 / 0
03.04.2018, 10:38
    #39624516
StarikNavy
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
правильная организация проектов и баз
нуб987,

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

"измерения" да, лежат в базе , и их с тех пор использовать в одном, или в нескольких кубах (в пределах базы). выход - создаем префиксы в имени ~cube1_измерение2 , но согласен, что возможность группировки была бы удобна


>>Сейчас все размерности лежат в общей куче одной базы.

вобще-то можно создавать разные "data source view", под свои кубы
"размерности" строго говоря это "measure group", они появляются именно внутри куба (у каждого свои)

-------------------------
выбор общей концепции - "все кубы в одной базе" vs "для каждого куба своя база", неоднозначен, и в любом случае будет где-то неудобно: или в разработке, или в ресурсах сервера
...
Рейтинг: 0 / 0
03.04.2018, 12:37
    #39624675
Alex_496
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
правильная организация проектов и баз
нуб987,

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

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

Не зря у Кимбалла называется MultiDimensional - согласованные измерения, на пересечении которых вы смотрите факты, т.е. анализируете метрики событий.

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

Но если, например, у вас несколько разных измерений "Отделения Компании" или "Продукты", то забудьте об "единой правде"
...
Рейтинг: 0 / 0
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / правильная организация проектов и баз / 5 сообщений из 5, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]