|
|
|
правильная организация проектов и баз
|
|||
|---|---|---|---|
|
#18+
в MSAS2000 можно было создавать олап-базы, внутри которых делать нужное кол-во кубов. Например, сделать базу "продажи" и создать там несколько кубов разных направлений продаж. А рядом создать базу "Склады" и создать кубы по складам. Внутри базы можно было сделать SharedDimensions и использовать эти общие размерности в разных кубах одной базы (например, размерность дат или менеджеров). Так же можно было внутри каждого куба создавать размерности только для этого куба. Все просто, наглядно и удобно - древовидная структура: заходим внутрь и видим объекты. Подскажите, как сделать такую же организацию кубов на новом для меня СКЛ2012 ? Сейчас все размерности лежат в общей куче одной базы. И если мне нужно для разных кубов одной базы сделать разные размерности клиентов, то в MSAS2000 я бы просто внутри каждого куба создал бы свои размерности. А сейчас приходится создавать их в общей куче с именами Clients_Cube1, Clients_Cube2. Или же делать разные базы Sales1, Sales2 с соответствующими кубами внутри. Правильно ли я понимаю, что теперь внутри одной базы все размерности являются SharedDimension'ами? И по какому принципу правильно собирать кубы в одной базе? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2018, 01:24 |
|
||
|
правильная организация проектов и баз
|
|||
|---|---|---|---|
|
#18+
нуб987, по множеству принципов - в зависимости от приоритетов. в объединении есть преимущества и недостатки. если по сходу по быстрому придумать то примерно так: во первых архивирование/восстановление базы имеющей сотни кубов может занять много времени и потребовать ощутимого дискового пространства. во вторых полный процесинг одного измерения может вывести из строя сразу несколько кубов. в третьих обслуживание с ProcessUpdate на тяжелом измерении в одной базе где это измерение используется в нескольких кубах (или даже несколько раз в одном кубе) - займёт намного меньше времени чем обслуживание такого измерения между несколькими базами (т.е. временные и серверные ресурсы расходуются намного меньше). при больших нагрузках со стороны пользователей - базы легче разнести по разным серверам. дальше идут безопасность (разные админы баз для разных департаментов), риски вылетов/сбоев, патчей/обновлений, тяжесть большого проекта для среды разработки (VisualStudio), удобство для пользователей (или IT персонала) в обслуживании источников/линков для отчётности, и множество прочих косметических преимуществ/недостатков до чего-то посерьёзнее.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2018, 02:16 |
|
||
|
правильная организация проектов и баз
|
|||
|---|---|---|---|
|
#18+
а по измерениям - потенциально да: могут, но: нет, не обязательно все измерения являются Shared Dimension (между кубами), это уже как настроишь - собственно включать (добавлять) измерение в куб или нет - чисто вопрос необходимости (для Master Data или связи с фактами), отдельным пунктом - где настраивать безопасность/права доступа (и/или видимости) для пользователей - на уровне куба или на корневом уровне самой базы. с точки зрения наименований в корне каталога проекта/базы и имени измерения в самом кубе - это тоже на своё усмотрение / по необходимости, в корне базы называй как хочешь, в кубах - как нужно пользователям. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2018, 02:27 |
|
||
|
правильная организация проектов и баз
|
|||
|---|---|---|---|
|
#18+
нуб987, ну в общем-то , почти тоже и осталось: база --> кубы, измерения "измерения" да, лежат в базе , и их с тех пор использовать в одном, или в нескольких кубах (в пределах базы). выход - создаем префиксы в имени ~cube1_измерение2 , но согласен, что возможность группировки была бы удобна >>Сейчас все размерности лежат в общей куче одной базы. вобще-то можно создавать разные "data source view", под свои кубы "размерности" строго говоря это "measure group", они появляются именно внутри куба (у каждого свои) ------------------------- выбор общей концепции - "все кубы в одной базе" vs "для каждого куба своя база", неоднозначен, и в любом случае будет где-то неудобно: или в разработке, или в ресурсах сервера ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2018, 10:38 |
|
||
|
правильная организация проектов и баз
|
|||
|---|---|---|---|
|
#18+
нуб987, Есть измерения многомерной базы данных, отдельные из которых могут включаться в куб, т.е. это уже измерения куба. Измерения нужно проектировать правильно, системно, вопросы прорабатывать еще на этапе DWH. Не зря у Кимбалла называется MultiDimensional - согласованные измерения, на пересечении которых вы смотрите факты, т.е. анализируете метрики событий. Согласованность измерений - это основа основ, принцип не принадлежит конкретной реализации. Могут быть разные иерархии как пути навигации (разные взгляды) к ключевым атрибутам. Но если, например, у вас несколько разных измерений "Отделения Компании" или "Продукты", то забудьте об "единой правде" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2018, 12:37 |
|
||
|
|

start [/forum/topic.php?fid=49&msg=39624397&tid=1857920]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
168ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
37ms |
get tp. blocked users: |
1ms |
| others: | 235ms |
| total: | 479ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...