OLAP // Неверные данные

[MironovI]

DTS настроить

[Alex_K]

Цитата:

Сообщение от farlander

Извиняйте мэтры 8)
Действительно затесалась еще одна компания... да еще и с такими же данными... странно, что фильтр на измерениях и кубе не отрабатывался :-/
В кубе и измерениях стоит фильтр dbo.таблица.dataareaid = 'компания'

А вот это лишнее... Мало того, что этот фильтр не видно во время строительства кубика, так ещё и в дальнейшем о нем помнить надо.

Категорически рекомендую создать в аксе хотя бы одну View с фильтром по компании и каким-нибудь именем, эту компанию идентифицирующим. А в кубе и измерениях настроить связи по dataareaid.

Правда и в таком случае есть одна тонкость - при синхронизации связи по dataareaid во View не переносятся, поэтому, если в ней несколько датасорсов, придется настраивать Range для каждого.

[glibs]

Я вообще предпочитаю и рекомендую под таблицу фактов и под измерения вьюхи делать. Не то, чтобы это принципиально, но работать и искать ошибки проще. И вероятность возникновения такой ситуации существенно снижается.

[farlander]

И правда... уперлись в момент, который не решается на данном уровне...
Будем ваять вьюхи...

[farlander]

С помощью вьюхи такое же точно задвоение происходит!

[farlander]

Получается чтоли нерешимая задача использовать несколько измерений?!
Когда смотрим представление одного измерения ссумируются строки по другому... то есть мера умножается в количество значений второго измерения...

[glibs]

Боюсь, что просто что-то вы не так настраиваете.

[farlander]

Тогда приведу пример.
Таблицы RPayTrans и RPayEmplTblSum связаны по EmplId и PayPeriod.
Например, возьмем измерения RPayTrans.PayCtype и RPayEmplTblSum.TimeCode.
Меры возьмем RPayTrans.Amount и RPayEmplTblSum.DayFact
В представлении TimeCode и DayFact получим одну строку, у которой мера будет включать СУММУ строк, равное количеству PayCtype при данном EmplId и PayPeriod. То есть если в этом периоде у этого человека есть 2 разных PayCtype, то сумма задвоится.

Думаю надо применить mdx-формулу: отношение меры к количеству отфильтрованных строк... подскажет кто-нить такой код?

[Recoilme]

Цитата:

Сообщение от farlander

Тогда приведу пример.
Таблицы RPayTrans и RPayEmplTblSum связаны по EmplId и PayPeriod.
Например, возьмем измерения RPayTrans.PayCtype и RPayEmplTblSum.TimeCode.
Меры возьмем RPayTrans.Amount и RPayEmplTblSum.DayFact
В представлении TimeCode и DayFact получим одну строку, у которой мера будет включать СУММУ строк, равное количеству PayCtype при данном EmplId и PayPeriod. То есть если в этом периоде у этого человека есть 2 разных PayCtype, то сумма задвоится.

Думаю надо применить mdx-формулу: отношение меры к количеству отфильтрованных строк... подскажет кто-нить такой код?

У меня в базе нет таблицы RPayEmplTblSum и соответсвенно я не знаю как она м.б. связана с RPayTrans что Вы хотите получить и не помню модуль зп и вообще честно говоря не понял ничего из того что Вы написали и почему она должна "незадвоится")) Но так как glibs в соседнем топике бросил тень на свет ОЛАП технологий)), попробую угадать:

Если вы хотите получить сумму деленное на количество (некое среднее) то можно сделать например так SUM(Amount ) / Count(PayCtype)
Если же Вам нужно делить на количество именно уникальных значений то вместо Count(PayCtype) можно попробовать DistinctCount(PayCtype)
Тип агрегации (Sum, Count, DistinctCount и т.п.) Задаются в свойствах мер.

Произвести требуемые вычисления можно как на стороне эскуэль так и непосредственно в кубе (заведя соответствующие меры и калькулируюмую меру сум/каунт). Если же непременно хочется через какой ть хитрый MDX поизвращаться попробуйте покурить функцию Avg

[glibs]

Цитата:

Сообщение от Recoilme

...
Но так как glibs в соседнем топике бросил тень на свет ОЛАП технологий))
...

Я не понял. Что за свинство?

В чем заключалось бросание мною тени на свет ОЛАП технологий?

Прошу аргументированно обосновать ваш наезд.

[Recoilme]

я пошутил)

[farlander]

Не знаю будет ли понятнее, но проблема аналогична этой http://www.olap.ru/iservices/message...6&topicId=9172
Только таблиц фактов 4, а измерений около 12, причем таких, что в общем итоге испльзуется около 10 таблиц...

[Recoilme]

Цитата:

Сообщение от farlander

Не знаю будет ли понятнее, но проблема аналогична этой http://www.olap.ru/iservices/message...6&topicId=9172
Только таблиц фактов 4, а измерений около 12, причем таких, что в общем итоге испльзуется около 10 таблиц...

Я бы решал проблему объединения так: один куб по оплатам, второй по отгрузкам,а в связанном(виртуальном) кубе объединил бы их в один. Какого ... видеть оплаты по пунктам если они были по клиентам - не понимаю, но задвоения не будет.

Либо на уровне хранилища приводить к единой гранулярности. Подзапросом вытащить кол пунктов для клиента и поделить на него сумму оплаты, примерно так:
select
data,
KodClient,
((Select sum(sumOpl) from оплаты where data=otgr.data and KodClient=otgr.KodClient)
/
(select count(KodPunkt) from отгрузки where data=otgr.data and KodClient=otgr.KodClient)) as oplbypunkt,
sumOtgr
from
отгрузки otgr

[farlander]

Я так и сделал... поместил 4 куба в виртуальный... НО хоть и меры в них были в таблице фактов - некоторые измерения были в других таблицах... и задвоение вылазило уже ДО объединения в виртуальный...
Второй совет оппробую... я про это и спрашивал... только еще необходимо убедиться, что средняя будет правильным значением... очевидно, что не для всех комбинаций это верно :-/

[farlander]

ОК... попробуем другим образом...
Есть 3-4 таблицы фактов... у каждой свое временное измерение из своей таблицы...
Как в виртуальном кубе, их объединяющем, создать общее для всех мер временное измерение...

[Recoilme]

Создать общее для всех таблиц фактов временнОе измерение. Определить его как shared dimension. Заджойнить его к каждой таблице фактов и в дальнейшем использовать его. Я в своих проектах создал пару таблиц для финансового и физического временнОго измерения. Заполняю его единожды при помощи следующего job:

    #static void AxOlap_CreateObjects(Args _args)
    #{
    #AX_DATA_FIN datafin;
    #AX_DATA_PH  dataph;
    #date        datestart=01\01\2000;
    #date        dateend=31\12\2009;
    #int         i;
    #DictEnum    dictEnum;
    #ENUM_INVENT_DIRECTION   enum_inventdirection;
    #ENUM_INVENTTRANSTYPE    enum_inventtranstype;
    #;
    #/*
    #//Fin date
    #datafin.skipTTSCheck(1);
    #delete_from datafin;
    #datafin.DATA = 01\01\1900;
    #datafin.insert();
    #for (i=0;i<=64536;i++)
    #{
    #    datafin.DATA = datestart+i;
    #    datafin.SUMDAY = 1;
    #    datafin.insert();
    #    if (datafin.DATA == dateend) break;
    #}
    #//Phiz date
    #dataph.skipTTSCheck(1);
    #delete_from dataph;
    #dataph.DATA = 01\01\1900;
    #dataph.insert();
    #for (i=0;i<=64536;i++)
    #{
    #    dataph.DATA = datestart+i;
    #    dataph.SUMDAY = 1;
    #    dataph.insert();
    #    if (dataph.DATA == dateend) break;
    #}
    #*/
    #//Base enums

[Alex_K]

Цитата:

Сообщение от Recoilme

Я в своих проектах создал пару таблиц для финансового и физического временнОго измерения. Заполняю его единожды ...

Кстати, создавать ничего и не нужно. В Аксе есть замечательная табличка OLAPTimeByDate, предназначенная именно для создания общего временнОго измерения для всех компаний. Заполняется автоматически при указании диапазона лет в форме Параметры OLAP (Основное / Настройки / Бизнес-анализ / Параметры OLAP)

Правда, для её использования нужна лицензия на бизнес-анализ

[Recoilme]

Цитата:

Сообщение от Alex_K

Кстати, создавать ничего и не нужно. В Аксе есть замечательная табличка OLAPTimeByDate, предназначенная именно для создания общего временнОго измерения для всех компаний. Заполняется автоматически при указании диапазона лет в форме Параметры OLAP (Основное / Настройки / Бизнес-анализ / Параметры OLAP)

Правда, для её использования нужна лицензия на бизнес-анализ

Да бог с ней с лицензией)
Интересно создает ли данная функциональность "пустую" дату (01.01.1900) независимо от указанного диапазона?
Не случится ли так что все проводки с "Нет даты" будут торжественно потеряны при использовании временнОй таблицы созданной данным методом ?
(Конечно если не догадаться создать период от начала времен (с 1900 года) по наше время,про удобство работы с такой таблицей уж молчу)

[Alex_K]

Ну, сама она не создает. А кто мешает добавить её кусочком приведенного выше джоба?

У неё есть еще одна полезная особенность - там не только даты, но и названия дней недели, месяцев и кварталов на разных языках, что, на мой взгляд, совсем не бесполезно...

[Alex_K]

Кстати, сильно рекомендую книжку:
http://www.books.ru/shop/books/490547

Может помочь в разрешении многих вопросов, в т.ч. заданных в этой ветке.