Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Лишние члены измерения
|
|||
|---|---|---|---|
|
#18+
MSAS2000 sp4 Возможно, что ответ будет очень простой. Ситация такая: есть таблица фактов и есть таблицы измерений (в которых есть RN, не существующие в таблице фактов). Так вот при расчете в измерения попадают все значения а не только такое которые связаны с таблицей фактов. Есть самый простой способ: построить view на таблицу измерения, которая будет иметь только те записи RN которых есть в таблице фактов. Но так не очень красиво. Вопрос: как можно этого избежать на уровне многомерной модели? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2005, 13:09 |
|
||
|
Лишние члены измерения
|
|||
|---|---|---|---|
|
#18+
можно поставить фильтр на таблицу измерений ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2005, 13:14 |
|
||
|
Лишние члены измерения
|
|||
|---|---|---|---|
|
#18+
Avtaev NikolaiТак вот при расчете в измерения попадают все значения а не только такое которые связаны с таблицей фактов. А откуда знает измерение в скольки кубах (таблицах фактов) оно позднее будет использоваться? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2005, 13:22 |
|
||
|
Лишние члены измерения
|
|||
|---|---|---|---|
|
#18+
А где это можно поставить, чтобы не для конкретных измерений по таблице, а для всей? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2005, 13:22 |
|
||
|
Лишние члены измерения
|
|||
|---|---|---|---|
|
#18+
backfire Avtaev NikolaiТак вот при расчете в измерения попадают все значения а не только такое которые связаны с таблицей фактов. А откуда знает измерение в скольки кубах (таблицах фактов) оно позднее будет использоваться? Ну мы допустим говорим не о общих измерениях. Согласитесь что лишние члены тормозят работу с кубом и мешают при фильтрации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2005, 13:24 |
|
||
|
Лишние члены измерения
|
|||
|---|---|---|---|
|
#18+
Avtaev Nikolai Ну мы допустим говорим не о общих измерениях. Так у вас измерения приватные? Тогда это проще пареной репы - надо взять вырадение для Member key не из таблицы измерения, а из таблицы фактов. (мышкой в дизайнере или в DSO скрипте) Avtaev NikolaiСогласитесь что лишние члены тормозят работу с кубом и мешают при фильтрации. С этим не соглашусь. Это скорее дело вкуса при выборе элементов измерения в GUI. При выборе из измерения времени вы тоже хотите видеть только те дни, недели и т.п. для которых есть записи в фактах? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2005, 13:49 |
|
||
|
Лишние члены измерения
|
|||
|---|---|---|---|
|
#18+
Так у вас измерения приватные? Тогда это проще пареной репы - надо взять вырадение для Member key не из таблицы измерения, а из таблицы фактов. (мышкой в дизайнере или в DSO скрипте) А как быть в случае временных измерений, когда в таблице уже заранее подготовленные дни недели, дни года и т.п.? Или же например таблицу товаров в которой есть свойства товара, затем с этой таблицей связна таблица каталогов с измерением parent-chield (котрая по сути универсальная и содержит так же каталоги контрагентов, модификаций и т.п.) Это что придется создавать на каталог представления или же просто разбивать на мелкие таблицы? При выборе из измерения времени вы тоже хотите видеть только те дни, недели и т.п. для которых есть записи в фактах? Да, именно так ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2005, 14:22 |
|
||
|
Лишние члены измерения
|
|||
|---|---|---|---|
|
#18+
Avtaev Nikolai Это что придется создавать на каталог представления? Именно так. Avtaev Nikolai При выборе из измерения времени вы тоже хотите видеть только те дни, недели и т.п. для которых есть записи в фактах? Да, именно так Это ваше (вашего заказчика) частное желание, имеющее с main stream BI мало общего. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2005, 15:47 |
|
||
|
Лишние члены измерения
|
|||
|---|---|---|---|
|
#18+
backfireЭто ваше (вашего заказчика) частное желание, имеющее с main stream BI мало общего. Вообще то в mainstream datawarehousing это называется degenerate dimensions, когда измерение создается на таблице фактов. Правда действительно довольно необычно применять это к измерениу Время. Обычно degenerate dimension имеят кардинальность сравнимуя таблицы фактов (например Заказы) Avtaev NikolaiСогласитесь что лишние члены тормозят работу с кубом и мешают при фильтрации. Не согласен. Как они что то тормозят ? А вот создавать несколько приватных измерений вместо одного общего - это может тормозить... Моша ---------------------------------------------------- This posting is provided "AS IS" with no warranties, and confers no rights ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2005, 10:00 |
|
||
|
Лишние члены измерения
|
|||
|---|---|---|---|
|
#18+
Mosha backfireЭто ваше (вашего заказчика) частное желание, имеющее с main stream BI мало общего. Вообще то в mainstream datawarehousing это называется degenerate dimensions, когда измерение создается на таблице фактов. Правда действительно довольно необычно применять это к измерениу Время. Обычно degenerate dimension имеят кардинальность сравнимуя таблицы фактов (например Заказы) Когда я говорил о mainstream, я имел ввиду только измерение времени и ничего другого. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2005, 10:27 |
|
||
|
Лишние члены измерения
|
|||
|---|---|---|---|
|
#18+
Вопрос в итоге так и останется без ответа. Измерение времени просто как пример привел, неудачный. Приведу другой пример: есть таблица иерархических каталогов. Тут каталоги номенклатуры, лицевых счетов, тарифов и т.п. пусть их будет сто. Все в одной таблице, в которой есть поле-идентификатор каталога. Все ID уникальны. По ней строятся несколько parent-child или плоских измерений. И если я беру всю таблицу, то в членах будет все. Конечно при просмотре данные будут только по соотвествующим членам, но это все равно лишний мусор (и кстати на быстродействие куба это влияет, как бы в теории не говорилось). Опять же можно строить кучу предсталений и по ним строить измерения. Но это не интегрированный подход а поэтому вернемся к самому вопросу топика. Скажу сразу, что про общие измерения мы пока не говорим. Но если можно построить общее и его уже огранивать в применяемом кубе, то это будет ещё один ответ на важный вопрос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2005, 10:24 |
|
||
|
Лишние члены измерения
|
|||
|---|---|---|---|
|
#18+
Avtaev NikolaiВопрос в итоге так и останется без ответа. Измерение времени просто как пример привел, неудачный. Приведу другой пример: есть таблица иерархических каталогов. Тут каталоги номенклатуры, лицевых счетов, тарифов и т.п. пусть их будет сто. Все в одной таблице, в которой есть поле-идентификатор каталога. Все ID уникальны. По ней строятся несколько parent-child или плоских измерений. И если я беру всю таблицу, то в членах будет все. Конечно при просмотре данные будут только по соотвествующим членам, но это все равно лишний мусор (и кстати на быстродействие куба это влияет, как бы в теории не говорилось). Опять же можно строить кучу предсталений и по ним строить измерения. Но это не интегрированный подход а поэтому вернемся к самому вопросу топика. Скажу сразу, что про общие измерения мы пока не говорим. Но если можно построить общее и его уже огранивать в применяемом кубе, то это будет ещё один ответ на важный вопрос. Вам же уже ответили аж два раза: 1. взять выражение для Member key не из таблицы измерения, а из таблицы фактов 2. поставить фильтр на таблицу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2005, 10:38 |
|
||
|
|
start [/forum/topic.php?fid=49&tid=1870719]: |
0ms |
get settings: |
10ms |
get forum list: |
21ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
88ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
| others: | 262ms |
| total: | 455ms |
| 0 / 0 |
