Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Расчет статфункций в перенасыщенных кубах?
|
|||
|---|---|---|---|
|
#18+
Допустим, в таблице фактов есть несколько записей, попадающих в одну и ту же ячейку куба. Как считается в этом случае среднеквадратичное отклоенение или, скажем, медиана? Как функция от нескольких значений (реально лежащих в табл фактов) или как функция от аггрегированного значения? Как какой OLAP смотрит на это? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2003, 18:32 |
|
||
|
Расчет статфункций в перенасыщенных кубах?
|
|||
|---|---|---|---|
|
#18+
Если я правильно понял вопрос Я взял пример в лоб составил такую табличку: Код: plaintext 1. 2. 3. 4. 5. 6. 7. Потом составил такой SQL Код: plaintext 1. 2. 3. И использовал этот запрос как объект в Oracle Discoverer и построил репорт типа Table. Получилось, что я могу резать по людям или департаментам, при этом STDDEV считается внутри каждого департамента и то, что на ячейку ИМЯ-ДЕПАРТАМЕНТ встречается больше одной записи, все равно STDDEV вычисляется правильно. Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2003, 20:38 |
|
||
|
Расчет статфункций в перенасыщенных кубах?
|
|||
|---|---|---|---|
|
#18+
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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2003, 01:34 |
|
||
|
Расчет статфункций в перенасыщенных кубах?
|
|||
|---|---|---|---|
|
#18+
2 Tsaryov S: Volj: Ведь вы не будете отрицать, надеюсь, что в случае работы с аггрегированными значениями (саггрегированными любой функцией), статфункции выдадут вам неверный результат? Tsaryov S: Я буду. Зря будете :) Математическое доказательство этого настолько очевидно, что его просто не имеет смысла здесь приводить. Tsaryov S: Сгласен с теми, кто говорит, что в каждая ячейка определяется уникальными значениями измерений. Это не более чем допущение, навязанное маркетологами. Как Вы, в таком случае, будете создавать измерения для таблицы, одним из полей которой является timestamp (время записи поля в базу). Фиксируются, допустим, нейтрино в нейтринном детекторе, которым ничто не мешает "проявиться" в нем в одно и то же время (с точки зрения БД). Что теперь? Суммировать их характеристики? Или наложить на базу уникальный индекс, и объявить второе нейтрино несуществующим? ;-) Я уж не рассматриваю случаи, когда записи добавляются в какую-нибудь базу, скажем, каждые несколько секунд, а в качестве предельно высокого уровня детализации меня интересует час. Что тогда делать? Можно, конечно, наложить дополнительные измерения, но это все-таки извращение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2003, 13:46 |
|
||
|
Расчет статфункций в перенасыщенных кубах?
|
|||
|---|---|---|---|
|
#18+
2 Birkhoff, Константин: Что-то идеологи MOLAP замолчали, что не может не навести на некоторые размышления ;-) Вообще, логично предположить, что именно ROLAP будет нормально переваривать сабж. Для MOLAP-серверов, наверное, слишком велико искушение аггрегировать данные при закачке их с сервера... А это - кранты :( И остается говорить фразы вроде: "... каждая ячейка определяется уникальными значениями измерений". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2003, 13:57 |
|
||
|
Расчет статфункций в перенасыщенных кубах?
|
|||
|---|---|---|---|
|
#18+
"... каждая ячейка определяется уникальными значениями измерений" Это по моему я и написал :) Ну в MOLAP это так, что тут можно поделать. У вас задача осложнена двумя моментами - статистикой и тем, что вы называете несколькими значениями для одной ячейки. MOLAP технология все таки обычно работает с чем то попроще. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2003, 14:24 |
|
||
|
Расчет статфункций в перенасыщенных кубах?
|
|||
|---|---|---|---|
|
#18+
2 Birkhoff: Ну в MOLAP это так, что тут можно поделать. Вообще, действительно, странно... Ситуация нескольких записей на одну ячейку теоретически может возникнуть в любом кубе, в котором из timestamp-измерения формируются измерения даты и времени. Это, опять же, приводит к некорректному вычислению статистических функций. Неужели это всем пофигу??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2003, 14:32 |
|
||
|
Расчет статфункций в перенасыщенных кубах?
|
|||
|---|---|---|---|
|
#18+
OLAP в основном используется в коммерческих приложениях, где такие ситуации встречаются редко. Не могу представить две одинаковые проводки, или две одинаковые услуги, которые ничем не различаются кроме суммы. :) А если они отличаются только по TIMESTAMP, то время является в таких системах одним из основных измерений и его выкинуть не представляется возможным. А ваш пример это скорее из области науки, где OLAP тоже не часто используется. Также OLAP обычно бесполезен при исследовании функций от многих параметров. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2003, 15:38 |
|
||
|
Расчет статфункций в перенасыщенных кубах?
|
|||
|---|---|---|---|
|
#18+
Термин "перенасыщенных" - видимо, новое слово OLAP... А вообще, постараюсь без субъективизма. OLAP подразумевает уникальность. Если значения лежат отдельно, то либо они должны анализироваться отдельно, либо их можно свернуть. Как свернуть - другой вопрос. Если две частицы возникли в один момент, а вы анализируете их энергии, то вы либо применяете какую-то функцию (не обязательно сумму :)) либо нумеруете их и кладете в разные ячейки. У нас с вами разное определение ячейки. Даже примеры, приведенные выше из ROLAPа показывают, что к одинаковым строкам применяются функции агрегации (STDEV и Median). Если Константин в Microstrategy создаст куб, я уверен, на нижнем уровне иерархии будут уникальные ячейки, показатели в которых будут например STDEV1, Median1 от выших исходных атомарных данных. Если говорить о Cognos в частности, то стандартное отклонение в нем посчитать возможно, а вот с медианой труднее. Так как тут речь пошла о стат функциях, с Microstrategy трудно спорить. Можно поиграть другими мускулами, но ими уже играли вначале (иерархии, простота, цены, скорость). Можно подключить внешние предрасчитанные агрегаты. Успехов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2003, 15:57 |
|
||
|
Расчет статфункций в перенасыщенных кубах?
|
|||
|---|---|---|---|
|
#18+
2 Birkhoff: OLAP в основном используется в коммерческих приложениях, где такие ситуации встречаются редко. Ну уж не скажите :) Работал я на телефонной станции в прошлом, занимался анализом прохождения по транкам телефонных разговоров. И была у меня примерно такая база: -- данные, определяющие маршрут N транка N канала Вх. узел Исх. узел -- данные, определяющие разговор время начала (TIMESTAMP) - делятся на "день" и "час" (данные за месяц) код завершения длительность теоретически (да и, практически бывает частенько, при нашей-то телефонии в райцентрах) на один транк пытается "сесть" один и тот же абонент, и получает, допустим, "отлуп" через секунду разговора, потому что транк глючный. В этом случае возникают две и более совершенно одинаковых записей с разным временем начала. А в качестве "гольного" измерения TIMESTAMP заводить не хочется, т.к. в этом измерении будут десятки миллионов членов (при анализе данных за месяц) Можно, конечно, добавить измерения "минута" и "секунда" - это, наверное, гарантировало бы уникальность, но зачем? Эти измерения никогда не пригодились бы для анализа. Что, неужели это нетривиальная задача??? 2 Tsaryov S: Если две частицы возникли в один момент, а вы анализируете их энергии, то вы либо применяете какую-то функцию (не обязательно сумму :)) либо нумеруете их и кладете в разные ячейки. Наверное, Ваше предложение (про искусственную уникальность) - единственная возможность корректного расчета статфункций. Но почему об этом нигде не говорится??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2003, 17:09 |
|
||
|
Расчет статфункций в перенасыщенных кубах?
|
|||
|---|---|---|---|
|
#18+
2 Volj Ну вот вы сами говорите что можно было их разделить по секундам, но не нужно было, так же думаю что на статистику эти глючные записи не сильно влияют и ими можно или пренебречь либо просуммировать разговоры. И что, в этом анализе время вам вообще не было нужно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2003, 17:16 |
|
||
|
Расчет статфункций в перенасыщенных кубах?
|
|||
|---|---|---|---|
|
#18+
2 Birkhoff: И что, в этом анализе время вам вообще не было нужно? Не столько время, сколько длительность. Время я анализировал лишь в контексте измененного, по моим заявкам, оборудования. А интересовали меня именно глючные разговоры :D. Искал я их потому, что другой, сравнительно незатратной методики выявить "сбойные" транки, не существует (при имеющемся техническом оснащении). Другое дело, что работал я не через OLAP, но это потому, что тогда внедрить его у меня банально руки не дошли - пришлось переехать в другой город. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2003, 17:27 |
|
||
|
Расчет статфункций в перенасыщенных кубах?
|
|||
|---|---|---|---|
|
#18+
To Volj: Что-то идеологи MOLAP замолчали, что не может не навести на некоторые размышления ;-) Молчание идеологов MOLAP объясняется тем, что они сегодня посещали конференцию по BI-продуктам. Интересно было послушать про крупные проекты Cognos... :) Более подробно я прокомментирую Ваш вопрос на след. неделе, но сейчас могу сказать, что надо выбирать из двух альтернатив - либо MOLAP (быстрый анализ но не очень глубокий), либо ROLAP (медленный анализ но любой сложности). У Cognos для первого подхода есть PowerPlay, для второго - Impromptu или представленный на сегодняшней конференции ReportNet. Или же пытаться найти золотую середину - создание виртуальной вьюшки в ROLAP и ее кручение в кубиках MOLAP. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2003, 18:06 |
|
||
|
Расчет статфункций в перенасыщенных кубах?
|
|||
|---|---|---|---|
|
#18+
Вопрос: а при расчетах моды и медианы, учитывается характер распределения или нет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.12.2003, 23:55 |
|
||
|
Расчет статфункций в перенасыщенных кубах?
|
|||
|---|---|---|---|
|
#18+
2 AISOFT А это как? Медиана - это величина, которая при сортировке выборки занимает среднюю позицию, а мода - это величина, вероятность появления которой в выборке максимальна для данной выборки. Я не большой спец в статистике. Посвятите, пожалуйста, что Вы имели в виду? С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2003, 13:02 |
|
||
|
Расчет статфункций в перенасыщенных кубах?
|
|||
|---|---|---|---|
|
#18+
Как я понимаю, медиана - это значение переменной, которое приходится на середину распределения частот, т. е. одна половина всех значений больше медианы, а другая половина меньше. С модой я погорячился, но я тоже не большой специалист в статистике. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2003, 13:42 |
|
||
|
Расчет статфункций в перенасыщенных кубах?
|
|||
|---|---|---|---|
|
#18+
2 AISOFT, Константин: Вопрос: а при расчетах медианы, учитывается характер распределения или нет? Характер распределения учитывается, только когда зависимость Y от X выражена функцией. Для случаев одномерных массивов, с которыми оперирует OLAP, характер распеределения не может учитываться по определению, и медиана считается так, как написал в своем ответе Константин. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2003, 17:37 |
|
||
|
Расчет статфункций в перенасыщенных кубах?
|
|||
|---|---|---|---|
|
#18+
2 Volj: Характер распределения учитывается, только когда зависимость Y от X выражена функцией. Для случаев одномерных массивов, с которыми оперирует OLAP, характер распеределения не может учитываться по определению, и медиана считается так, как написал в своем ответе Константин. Наверное, так. Но, думаю, что мы не ограничены возможностью выборки только одномерных данных. OLAP, всё-таки, подразумевает многомерный анализ. Я уж не рассматриваю случаи, когда записи добавляются в какую-нибудь базу, скажем, каждые несколько секунд, а в качестве предельно высокого уровня детализации меня интересует час. Что тогда делать? Можно, конечно, наложить дополнительные измерения, но это все-таки извращение. Надо правильно спроектировать структуру таблицы фактов. Я бы пронумеровал записи (например, возрастающей целочисленной последовательностью номеров). Таким образом, в таблице фактов каждое событие (строка таблицы) имело бы уникальный номер, который был бы первичным ключём. Дальше, если хотим рассчитать какой-нибудь статистический параметр (то же стандартное отклонение), просто делаем GROUP BY по этому первичному ключу. Это гарантирует, что при расчёте будет использоваться максимально детальный уровень данных. В этом смысле ROLAP, на мой взляд, выигрывет, поскольку, что бы ни говорили про масштабируемость MOLAP, реляционные СУБД способны обрабатывать гораздо большие объёмы данных. С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2003, 10:06 |
|
||
|
|

start [/forum/topic.php?fid=49&msg=32337955&tid=1872965]: |
0ms |
get settings: |
11ms |
get forum list: |
17ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
54ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
78ms |
get tp. blocked users: |
1ms |
| others: | 230ms |
| total: | 413ms |

| 0 / 0 |
