powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / Расчет статфункций в перенасыщенных кубах?
18 сообщений из 18, страница 1 из 1
Расчет статфункций в перенасыщенных кубах?
    #32337135
Volj
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Допустим, в таблице фактов есть несколько записей, попадающих в одну и ту же ячейку куба. Как считается в этом случае среднеквадратичное отклоенение или, скажем, медиана? Как функция от нескольких значений (реально лежащих в табл фактов) или как функция от аггрегированного значения?

Как какой OLAP смотрит на это?
...
Рейтинг: 0 / 0
Расчет статфункций в перенасыщенных кубах?
    #32337210
Birkhoff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если я правильно понял вопрос
Я взял пример в лоб
составил такую табличку:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
   	ID	VALUE	NAME	DEPARTMENT
 	 1 	 1 	VASYA	SALES
 	 2 	 2 	VASYA	SALES
 	 3 	 1 	MASHA	HR
 	 4 	 1 	MASHA	HR
 	 5 	 3 	PETYA	DIR
 	 6 	 2 	PETYA	DIR


Потом составил такой SQL
Код: plaintext
1.
2.
3.
select distinct Name, department, 
STDDEV(Value) OVER(PARTITION BY Department ) stdev 
from std


И использовал этот запрос как объект в Oracle Discoverer и построил репорт типа Table.
Получилось, что я могу резать по людям или департаментам,
при этом STDDEV считается внутри каждого департамента и то, что
на ячейку ИМЯ-ДЕПАРТАМЕНТ встречается больше одной записи,
все равно STDDEV вычисляется правильно.

Код: plaintext
1.
2.
3.
4.
   	NAME	DEPARTMENT	STDEV
 	PETYA	DIR		 0 , 707106781186548 
 	MASHA	HR		 0 
 	VASYA	SALES		 0 , 707106781186548 
...
Рейтинг: 0 / 0
Расчет статфункций в перенасыщенных кубах?
    #32337295
Константин Лисянский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Microstrategy смотрит на это нормально (хотя некоторые тут не хотят его воспринимать как OLAP :)

Я тут поупражнялся с ним немного.

База данных Northwind (MS SQL Server).
В Microstrategy создаю 3 метрики:
Unitprice = Sum(Unitprice) {~}
Stdev of Unitprice = Stdev(Unitprice) {~}
Median of Unitprice = Median(Unitprice) {~}

Создаю отчёт. В строке номер заказа, в столбцах созданные метрики.
Получается результат (приведён частично):

Metrics Unit Price Stdev of Unitprice Median of Unitprice
Order
10248 58,60 13,39 14,00
10249 61,00 16,83 30,50
10250 66,90 17,99 16,80
10251 49,20 0,69 16,80
10252 94,00 31,60 27,20
10253 40,40 3,11 14,40
10254 30,80 8,04 8,00

SQL, который при этом сгенерировался:

Pass0 - Duration: 0:00:00.01
select a11.OrderID OrderID,
a11.ProductID ProductID,
a11.UnitPrice WJXBFS1
from [Order Details] a11

Pass1 - Duration: 0:00:00.01
[An Analytical SQL]

Отсюда видно, что Microstrategy выбирает из базы все детальные данные,
а метрики рассчитывются дальше на сервере OLAP - [An Analytical SQL].

Проверка правильности расчёта медианы для заказа 10250 (выполняется врукопашную через SQL Analyzer):

select
UnitPrice
from
dbo.[Order Details]
where
OrderID=10250
order by
1 desc

Результат:

42.4000
16.8000
7.7000

Видим, что 16.8 ровно посредине.

Далее я немного упростил отчёт и включил в него только метрику StDev.
Вот, какой SQL был сгенерирован:

Pass0 - Duration: 0:00:00.04
select a11.OrderID OrderID,
STDEV(a11.UnitPrice) WJXBFS1
from [Order Details] a11
group by a11.OrderID

Вот результат:

Metrics Stdev of Unitprice
Order
10248 13,39
10249 16,83
10250 17,99
10251 0,69
10252 31,60
10253 3,11
10254 8,04

В этот раз в силу того, что MS SQL Server поддерживает функцию STDEV
(что оказалось прятным сюрпризом :), она была явно включена в SQL
и весь расчёт производился на MS SQL Server.

В первом варианте был выбран расчёт на сервере OLAP из-за того, что, видимо, вычисление медианы не поддерживается в MS SQL.

Потом я посчитал моду
Mode of Unitprice = Mode(Unitprice) {~}

Она также считается на сервере OLAP, поскольку нет прямой поддержки в MS SQL.

Результат:

Metrics Mode of Unitprice
Order
10248
10249
10250
10251 16,80
10252
10253
10254
10255 15,20

Для проверки выполняем следующий SQL

select
UnitPrice
from
dbo.[Order Details]
where
OrderID=10251

Результат:

16.8000
15.6000
16.8000

Видим, что, действительно 16,8 повторяется дважды, соответственно, является наиболее вероятной величиной.

Таким образом, мы убедились, что с одним измерением всё в порядке.

Добавим теперь в самый первый отчёт ещё одно измерение - Customer.
Получим следующие результаты:

Metrics Stdev of Unitprice
Customer Order
Alfreds Futterkiste 10643 17,92
Alfreds Futterkiste 10692
Alfreds Futterkiste 10702 5,66
Alfreds Futterkiste 10835 29,70
Alfreds Futterkiste 10952 14,57
Alfreds Futterkiste 11011 5,83
Ana Trujillo Emparedados y helados 10308 11,88
Ana Trujillo Emparedados y helados 10625 10,01
Ana Trujillo Emparedados y helados 10759
Ana Trujillo Emparedados y helados 10926 13,07
Antonio Moreno Taqueria 10365
Antonio Moreno Taqueria 10507 23,51
Antonio Moreno Taqueria 10535 17,72
Antonio Moreno Taqueria 10573 13,02
Antonio Moreno Taqueria 10677 20,32
Antonio Moreno Taqueria 10682 7,34
Antonio Moreno Taqueria 10856 3,54

Для его получения был сгенерирован следующий SQL:

Pass0 - Duration: 0:00:00.09
select a12.CustomerID CustomerID,
max(a13.CompanyName) CompanyName,
a11.OrderID OrderID,
STDEV(a11.UnitPrice) WJXBFS1
from [Order Details] a11
join Orders a12
on (a11.OrderID = a12.OrderID)
join Customers a13
on (a12.CustomerID = a13.CustomerID)
group by a12.CustomerID,
a11.OrderID



В результате видим, что все вычисления производятся по детальным данным.
Что ещё будет интересно узнать?


С уважением,
Константин Лисянский
http://lissianski.narod.ru
...
Рейтинг: 0 / 0
Расчет статфункций в перенасыщенных кубах?
    #32337777
Volj
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Tsaryov S:

Volj: Ведь вы не будете отрицать, надеюсь, что в случае работы с аггрегированными значениями (саггрегированными любой функцией), статфункции выдадут вам неверный результат?
Tsaryov S: Я буду.

Зря будете :) Математическое доказательство этого настолько очевидно, что его просто не имеет смысла здесь приводить.

Tsaryov S: Сгласен с теми, кто говорит, что в каждая ячейка определяется уникальными значениями измерений.

Это не более чем допущение, навязанное маркетологами.
Как Вы, в таком случае, будете создавать измерения для таблицы, одним из полей которой является timestamp (время записи поля в базу). Фиксируются, допустим, нейтрино в нейтринном детекторе, которым ничто не мешает "проявиться" в нем в одно и то же время (с точки зрения БД). Что теперь? Суммировать их характеристики? Или наложить на базу уникальный индекс, и объявить второе нейтрино несуществующим? ;-)

Я уж не рассматриваю случаи, когда записи добавляются в какую-нибудь базу, скажем, каждые несколько секунд, а в качестве предельно высокого уровня детализации меня интересует час. Что тогда делать? Можно, конечно, наложить дополнительные измерения, но это все-таки извращение.
...
Рейтинг: 0 / 0
Расчет статфункций в перенасыщенных кубах?
    #32337806
Volj
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Birkhoff, Константин:

Что-то идеологи MOLAP замолчали, что не может не навести на некоторые размышления ;-)

Вообще, логично предположить, что именно ROLAP будет нормально переваривать сабж. Для MOLAP-серверов, наверное, слишком велико искушение аггрегировать данные при закачке их с сервера... А это - кранты :(
И остается говорить фразы вроде:
"... каждая ячейка определяется уникальными значениями измерений".
...
Рейтинг: 0 / 0
Расчет статфункций в перенасыщенных кубах?
    #32337849
Birkhoff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
"... каждая ячейка определяется уникальными значениями измерений"

Это по моему я и написал :)
Ну в MOLAP это так, что тут можно поделать.
У вас задача осложнена двумя моментами - статистикой и тем, что вы называете несколькими значениями для одной ячейки.
MOLAP технология все таки обычно работает с чем то попроще.
...
Рейтинг: 0 / 0
Расчет статфункций в перенасыщенных кубах?
    #32337854
Volj
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Birkhoff:

Ну в MOLAP это так, что тут можно поделать.
Вообще, действительно, странно... Ситуация нескольких записей на одну ячейку теоретически может возникнуть в любом кубе, в котором из timestamp-измерения формируются измерения даты и времени. Это, опять же, приводит к некорректному вычислению статистических функций. Неужели это всем пофигу???
...
Рейтинг: 0 / 0
Расчет статфункций в перенасыщенных кубах?
    #32337955
Birkhoff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OLAP в основном используется в коммерческих приложениях, где такие ситуации встречаются редко.
Не могу представить две одинаковые проводки, или две одинаковые услуги, которые ничем не различаются кроме суммы. :)
А если они отличаются только по TIMESTAMP, то время является в таких системах одним из основных измерений и его выкинуть не представляется возможным.
А ваш пример это скорее из области науки, где OLAP тоже не часто используется. Также OLAP обычно бесполезен при исследовании функций от многих параметров.
...
Рейтинг: 0 / 0
Расчет статфункций в перенасыщенных кубах?
    #32337978
Tsaryov S
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Термин "перенасыщенных" - видимо, новое слово OLAP... А вообще, постараюсь без субъективизма.
OLAP подразумевает уникальность. Если значения лежат отдельно, то либо они должны анализироваться отдельно, либо их можно свернуть. Как свернуть - другой вопрос. Если две частицы возникли в один момент, а вы анализируете их энергии, то вы либо применяете какую-то функцию (не обязательно сумму :)) либо нумеруете их и кладете в разные ячейки. У нас с вами разное определение ячейки. Даже примеры, приведенные выше из ROLAPа показывают, что к одинаковым строкам применяются функции агрегации (STDEV и Median). Если Константин в Microstrategy создаст куб, я уверен, на нижнем уровне иерархии будут уникальные ячейки, показатели в которых будут
например STDEV1, Median1 от выших исходных атомарных данных.
Если говорить о Cognos в частности, то стандартное отклонение в нем посчитать возможно, а вот с медианой труднее. Так как тут речь пошла о стат функциях, с Microstrategy трудно спорить. Можно поиграть другими мускулами, но ими уже играли вначале (иерархии, простота, цены, скорость).
Можно подключить внешние предрасчитанные агрегаты.
Успехов.
...
Рейтинг: 0 / 0
Расчет статфункций в перенасыщенных кубах?
    #32338089
Volj
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Birkhoff:

OLAP в основном используется в коммерческих приложениях, где такие ситуации встречаются редко.
Ну уж не скажите :) Работал я на телефонной станции в прошлом, занимался анализом прохождения по транкам телефонных разговоров. И была у меня примерно такая база:
-- данные, определяющие маршрут
N транка
N канала
Вх. узел
Исх. узел
-- данные, определяющие разговор
время начала (TIMESTAMP) - делятся на "день" и "час" (данные за месяц)
код завершения
длительность
теоретически (да и, практически бывает частенько, при нашей-то телефонии в райцентрах) на один транк пытается "сесть" один и тот же абонент, и получает, допустим, "отлуп" через секунду разговора, потому что транк глючный.
В этом случае возникают две и более совершенно одинаковых записей с разным временем начала.
А в качестве "гольного" измерения TIMESTAMP заводить не хочется, т.к. в этом измерении будут десятки миллионов членов (при анализе данных за месяц)
Можно, конечно, добавить измерения "минута" и "секунда" - это, наверное, гарантировало бы уникальность, но зачем? Эти измерения никогда не пригодились бы для анализа.
Что, неужели это нетривиальная задача???

2 Tsaryov S:

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

Наверное, Ваше предложение (про искусственную уникальность) - единственная возможность корректного расчета статфункций.

Но почему об этом нигде не говорится???
...
Рейтинг: 0 / 0
Расчет статфункций в перенасыщенных кубах?
    #32338099
Birkhoff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Volj
Ну вот вы сами говорите что можно было их разделить по секундам, но не нужно было, так же думаю что на статистику эти глючные записи не сильно влияют и ими можно или пренебречь либо просуммировать разговоры.
И что, в этом анализе время вам вообще не было нужно?
...
Рейтинг: 0 / 0
Расчет статфункций в перенасыщенных кубах?
    #32338118
Volj
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Birkhoff:

И что, в этом анализе время вам вообще не было нужно?

Не столько время, сколько длительность. Время я анализировал лишь в контексте измененного, по моим заявкам, оборудования. А интересовали меня именно глючные разговоры :D. Искал я их потому, что другой, сравнительно незатратной методики выявить "сбойные" транки, не существует (при имеющемся техническом оснащении).
Другое дело, что работал я не через OLAP, но это потому, что тогда внедрить его у меня банально руки не дошли - пришлось переехать в другой город.
...
Рейтинг: 0 / 0
Расчет статфункций в перенасыщенных кубах?
    #32338160
Jurii
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
To Volj:

Что-то идеологи MOLAP замолчали, что не может не навести на некоторые размышления ;-)

Молчание идеологов MOLAP объясняется тем, что они сегодня посещали конференцию по BI-продуктам. Интересно было послушать про крупные проекты Cognos... :)
Более подробно я прокомментирую Ваш вопрос на след. неделе, но сейчас могу сказать, что надо выбирать из двух альтернатив - либо MOLAP (быстрый анализ но не очень глубокий), либо ROLAP (медленный анализ но любой сложности). У Cognos для первого подхода есть PowerPlay, для второго - Impromptu или представленный на сегодняшней конференции ReportNet. Или же пытаться найти золотую середину - создание виртуальной вьюшки в ROLAP и ее кручение в кубиках MOLAP.
...
Рейтинг: 0 / 0
Расчет статфункций в перенасыщенных кубах?
    #32341385
AISOFT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Вопрос: а при расчетах моды и медианы, учитывается характер распределения или нет?
...
Рейтинг: 0 / 0
Расчет статфункций в перенасыщенных кубах?
    #32341938
Константин Лисянский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 AISOFT

А это как?

Медиана - это величина, которая при сортировке выборки занимает среднюю позицию, а мода - это величина, вероятность появления которой в выборке максимальна для данной выборки.
Я не большой спец в статистике. Посвятите, пожалуйста, что Вы имели в виду?

С уважением,
Константин Лисянский
http://lissianski.narod.ru
...
Рейтинг: 0 / 0
Расчет статфункций в перенасыщенных кубах?
    #32342019
AISOFT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Как я понимаю, медиана - это значение переменной, которое приходится на середину распределения частот, т. е. одна половина всех значений больше медианы, а другая половина меньше. С модой я погорячился, но я тоже не большой специалист в статистике.
...
Рейтинг: 0 / 0
Расчет статфункций в перенасыщенных кубах?
    #32343965
Volj
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 AISOFT, Константин:

Вопрос: а при расчетах медианы, учитывается характер распределения или нет?
Характер распределения учитывается, только когда зависимость Y от X выражена функцией. Для случаев одномерных массивов, с которыми оперирует OLAP, характер распеределения не может учитываться по определению, и медиана считается так, как написал в своем ответе Константин.
...
Рейтинг: 0 / 0
Расчет статфункций в перенасыщенных кубах?
    #32344381
Константин Лисянский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Volj:

Характер распределения учитывается, только когда зависимость Y от X выражена функцией. Для случаев одномерных массивов, с которыми оперирует OLAP, характер распеределения не может учитываться по определению, и медиана считается так, как написал в своем ответе Константин.

Наверное, так. Но, думаю, что мы не ограничены возможностью выборки только одномерных данных. OLAP, всё-таки, подразумевает многомерный анализ.

Я уж не рассматриваю случаи, когда записи добавляются в какую-нибудь базу, скажем, каждые несколько секунд, а в качестве предельно высокого уровня детализации меня интересует час. Что тогда делать? Можно, конечно, наложить дополнительные измерения, но это все-таки извращение.

Надо правильно спроектировать структуру таблицы фактов. Я бы пронумеровал записи (например, возрастающей целочисленной последовательностью номеров). Таким образом, в таблице фактов каждое событие (строка таблицы) имело бы уникальный номер, который был бы первичным ключём.
Дальше, если хотим рассчитать какой-нибудь статистический параметр (то же стандартное отклонение), просто делаем GROUP BY по этому первичному ключу. Это гарантирует, что при расчёте будет использоваться максимально детальный уровень данных.
В этом смысле ROLAP, на мой взляд, выигрывет, поскольку, что бы ни говорили про масштабируемость MOLAP, реляционные СУБД способны обрабатывать гораздо большие объёмы данных.


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


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