|
Как на основе одной и той же таблицы измерений лучше организовать два измерения?
|
|||
---|---|---|---|
#18+
Коллеги! Вот задумался над простым вопросом. Есть SQL таблица измерений "Контрагенты". В таблице фактов, есть два поля, связываемых по ID, с таблицей "Контрагенты" (например): - Контаргенты получатели - Контрагенты поставщики Т.е. в кубе мне нужно получать информцию по этим двум "срезам". Как это лучше организовать? Завести два отдельных измерения или мож ещё как? А то как то процессить два отдельных измерения по сути одного и того же выглядит нелепо. Мож для этого и предназначены так называемые иерархии, которые можно создать при проектировании измерений? Тока я не понял как их использовать. Подскажите пожалуйста. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2003, 08:04 |
|
Как на основе одной и той же таблицы измерений лучше организовать два измерения?
|
|||
---|---|---|---|
#18+
Не уверен, что это самый оптимальный вариант, но я воспользовался им. Сделал две вьюхи - в одной Получатели, в другой Поставщики и уже по вьюхам делать измерения. А вьюхи сделать совсем несложно...Фильтровать таблицу контрагентов по наличию кода контрагента в поле "получатель" или "поставщик" таблицы фактов. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2003, 10:04 |
|
Как на основе одной и той же таблицы измерений лучше организовать два измерения?
|
|||
---|---|---|---|
#18+
Спасибо Пашка! Я так и сделал. Похоже это единственный вариант. Только я сделал одну View. Одно измерение строю непосредственно по таблице, а другое - по View. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2003, 10:17 |
|
Как на основе одной и той же таблицы измерений лучше организовать два измерения?
|
|||
---|---|---|---|
#18+
А тогда у тебя в том измерении, которое ты строишь непосредственно по таблице будет много лишних элементов, что наверное не удобно для пользователя. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2003, 18:10 |
|
Как на основе одной и той же таблицы измерений лучше организовать два измерения?
|
|||
---|---|---|---|
#18+
Почему? Набор элементов (членов) абсолютно идентичен в обоих измерениях. Я просто не совсем удачный пример привел с контрагентами. На самом деле у меня измерения по подразделениям. И в процессе бюджетирования любое подразделение может быть как исполнителем (измерение №1) так и заказчиком (измерени №2). Поэтому на таблицу фильтры накладывать ненадо. Или мож я чего не понял? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2003, 05:40 |
|
Как на основе одной и той же таблицы измерений лучше организовать два измерения?
|
|||
---|---|---|---|
#18+
А-а, если контрагент может и тем и тем быть, тогда все нормально :) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2003, 09:34 |
|
Как на основе одной и той же таблицы измерений лучше организовать два измерения?
|
|||
---|---|---|---|
#18+
А что, нельзя вынести одну и туже таблицу дважды ??? Обычно для такой задачи одна и таже таблица просто выступает под разными альясами. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2003, 13:09 |
|
Как на основе одной и той же таблицы измерений лучше организовать два измерения?
|
|||
---|---|---|---|
#18+
Что значит вынести таблицу дважды? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2003, 13:17 |
|
Как на основе одной и той же таблицы измерений лучше организовать два измерения?
|
|||
---|---|---|---|
#18+
Во-первых, в чем вы строите запрос ? В большинстве средств есть так называемые QueryBuilder'ы, где все можно строить интерактивно. Для чего выносятся таблицы, расставляются нужные связи и т.п. В случае такого средства вам достаточно одну и туже таблицу вынести 2 раза. Если вы пишете запрос вручную, то надо написать что-то типа select t1.* from fact_table t1, contr t2, contr t3 where t1.poluchatel = t2.id and t1.postavschik = t3.id В данном случае таблица контрагентов (contr) имеет альяс t2 и t3, что делает ее разной таблицей в запросе !!! ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2003, 13:35 |
|
Как на основе одной и той же таблицы измерений лучше организовать два измерения?
|
|||
---|---|---|---|
#18+
Пашка, можно обойтись без вьюх - создать два измерения на одной таблице, и указать в свойствах измерения фильтр. Это если свойство покупатель/продавец указывается прямо в таблице контрагентов. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.02.2003, 14:18 |
|
Как на основе одной и той же таблицы измерений лучше организовать два измерения?
|
|||
---|---|---|---|
#18+
Да зачем вам эти пизнаки-то нужны? Ну есть таблица заказов, например, в ней два поля (покупатель и продавец), ну ссылаются они на контрагентов оба. постройте одно измерение на жойне заказов с контрагентами по покупателю, а другое - на жойне по продавцу. Ей богу в обеих измерениях будет то, что вам нужно без всяких вьюх и признаков. Иля ч чего-то сильно не понимаю? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.02.2003, 16:33 |
|
Как на основе одной и той же таблицы измерений лучше организовать два измерения?
|
|||
---|---|---|---|
#18+
Всем здрасти и с окончаниям праздника Вас! :) Признаки не нужны, и это понятно если прочитать тексты моих сообщения. Сделать два измерения по одной и той же таблице измерний, и связать с ID этой таблицы измерений с обеими полями таблицы фактов - ну что же, это мысль! А вы сами пробовали? Если так сделать, то в куб попадают те строки из таблицы фактов, у которых поля ID (допустим покупателя и поставщика) равные! Хотя по идее здравому смыслу эта идея не противоречит. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.02.2003, 07:23 |
|
Как на основе одной и той же таблицы измерений лучше организовать два измерения?
|
|||
---|---|---|---|
#18+
А если вставить еще раз таблицу в схему куба? Вставить можно, и, соответсвенно, не будет как бы двух ссылок на одну таблицу... но вот как работать будет - это надо проверять. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.02.2003, 09:49 |
|
Как на основе одной и той же таблицы измерений лучше организовать два измерения?
|
|||
---|---|---|---|
#18+
И это проверял. Алгоритм так и не понял, но в моём тестовом примере, весь факт суммировался на одного контрагента, хотя продажи были по двум. Т.е. всё равно кривулина. Измерение то всё равно строится по одной и той же таблице измерений. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.02.2003, 10:57 |
|
Как на основе одной и той же таблицы измерений лучше организовать два измерения?
|
|||
---|---|---|---|
#18+
А если строить приват измерение, и в нем потом указать на всех уровнях иерархии не имя основной таблицы, а альяс повторно вставленной? Куб при этом процессится, я проверил. Но вот что с данными - это надо смотреть... ... |
|||
:
Нравится:
Не нравится:
|
|||
25.02.2003, 11:21 |
|
Как на основе одной и той же таблицы измерений лучше организовать два измерения?
|
|||
---|---|---|---|
#18+
Все будет хорошо, если использовать алиас для второй таблицы. Я так всегда делаю и все очень даже замечательно работает. Вообще-то правила на этот счет в MDX такие же, как и в SQL и никакую америку тут открывать не надо. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.02.2003, 15:45 |
|
Как на основе одной и той же таблицы измерений лучше организовать два измерения?
|
|||
---|---|---|---|
#18+
Мож тогда поделитесь как в кубе (не MDX запросе, а именно в Cube Editor) использовать алиасы? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2003, 05:36 |
|
Как на основе одной и той же таблицы измерений лучше организовать два измерения?
|
|||
---|---|---|---|
#18+
Конечно поделюсь. Когда строите измерение, в построителе измерений (а не в Cube Editor) надо правой кнопочкой щелкнуть на таблице, выбрать Change Alias из контекстного меню и указать алиас, отличный от названия таблицы. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2003, 08:58 |
|
Как на основе одной и той же таблицы измерений лучше организовать два измерения?
|
|||
---|---|---|---|
#18+
Собственно, и в редакторе куба так же :) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2003, 09:27 |
|
Как на основе одной и той же таблицы измерений лучше организовать два измерения?
|
|||
---|---|---|---|
#18+
Вот это действительно дельный совет! Спасибо Julius!!! ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2003, 09:54 |
|
Как на основе одной и той же таблицы измерений лучше организовать два измерения?
|
|||
---|---|---|---|
#18+
Но похоже что можно только расшаренное измерение можно натравить на "самопальный" алиас. У приватного измерения в Cube Editor доступны к изменению источников только поля уровней. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2003, 11:14 |
|
Как на основе одной и той же таблицы измерений лучше организовать два измерения?
|
|||
---|---|---|---|
#18+
А почему бы не сделать без вьюверов и кубов, прямо с OLTP ? Какие проблемы? Тем более на такой мелкой таблице! ... |
|||
:
Нравится:
Не нравится:
|
|||
27.02.2003, 18:37 |
|
Как на основе одной и той же таблицы измерений лучше организовать два измерения?
|
|||
---|---|---|---|
#18+
VZL: А кто сказал, что таблица мелкая, или я что-то пропустил? Сфера применения локального OLAP (средств построения сводных таблиц на основе "плоских данных") - очень узкая. Тормоза начинаются даже при уже очень небольшом количестве записей в таблице. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.02.2003, 18:58 |
|
Как на основе одной и той же таблицы измерений лучше организовать два измерения?
|
|||
---|---|---|---|
#18+
>Но похоже что можно только расшаренное измерение можно натравить на "самопальный" алиас. У приватного измерения в Cube Editor доступны к изменению источников только поля уровней. Собственно, больше ничего и не нужно :) Как раз вчера такая потребность возникла, было сделано два приват измерения, у одного - изменены мембер кей и мембер нэйм колумны, и все ок. ------------- Мимо шел, решил остаться ... |
|||
:
Нравится:
Не нравится:
|
|||
27.02.2003, 21:26 |
|
Как на основе одной и той же таблицы измерений лучше организовать два измерения?
|
|||
---|---|---|---|
#18+
Re: Julius > А кто сказал, что таблица мелкая, или я что-то пропустил? Это очевидно по поставленной задаче: количество контрагентов (получателей и поставщиков) в любой фирме конечно. > Сфера применения локального OLAP (средств построения сводных > таблиц на основе "плоских данных") - очень узкая. Я бы такими фразами не бросался. Во-первых. Потому, что даже OLAP все понимают по разному. Я в числе тех, кто считает что там, где нет ON LINE обработки (т.е. требуются "кубы", сортировки и пр. предварительная суета) - это не OLAP, а отложенная, "посмертная" обработка, что во многих случаях равносильно выяснению вопроса "потел ли покойничек перед смертью?". Я допускаю, что кому-то это м.б. интересно - с академической точки зрения, но не с практической В-вторых. Кто Вам сказал, что средство для поддержки принятия решений в динамике - очень узкая сфера? Мой опыт прямо противоположен. В-третьих. Где Вы провели черту между "локальным" и "глобальным" OLAP. Я не встречал такого деления. М.б. следует сначала договориться о терминах? Не там ли она, где встает вопрос: делать или не делать "кубы"? Но тогда мы опять вернемся к вопросу: OLAP - это On-Line Analytic Processing или просто Analytic Processing, без приставки On-Line? > Тормоза начинаются даже при уже очень небольшом > количестве записей в таблице. Конечно, никто не мешает с Тверской на Арбат ехать через Нью Йорк и жаловаться на "тормоза" - это дело вкуса. Однако, кто же мешает выбрать путь покороче? Например, обработку за один проход, распараллеливание этого одного прохода, использование данных только периода управления, а не со времен Ноева Потопа, грамотное проектирование БД, использование индексов, оптимизация запроса и т.д. и т.п. А для более предметного разговора и обмена опытом хочу предложить "детское" решение: выложить аналогичную тестовую таблицу, (если встает вопрос о корпоративных секретах) куда-нибудь на общедоступный ресурс (например narod.ru) и протестировать на ней всем заинтересованным лицам разные системы, методы, подходы, термины, время обработки и т.д. (Даже самому предложение понравилось!) ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2003, 13:04 |
|
|
start [/forum/topic.php?fid=49&fpage=413&tid=1873520]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
28ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
104ms |
get tp. blocked users: |
1ms |
others: | 15ms |
total: | 188ms |
0 / 0 |