|
Действия ...
Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
16.02.2005, 19:09
|
|||
|---|---|---|---|
|
|||
один куб или два |
|||
|
#18+
Какие основные плюсы и минусы 1.иметь один куб для плановых и фактических данных 2.иметь два разных куба (ну скорость и время процессинга я понимаю, а с концептуальной точки зрения???) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.02.2005, 19:23
|
|||
|---|---|---|---|
|
|||
один куб или два |
|||
|
#18+
Ещё один Пожалуйста, ознакомпьтесь с правилами форума на предмет оформления сообщений. С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.02.2005, 19:27
|
|||
|---|---|---|---|
|
|||
один куб или два |
|||
|
#18+
Константин ЛисянскийЕщё один Пожалуйста, ознакомпьтесь с правилами форума на предмет оформления сообщений. С уважением, Константин Лисянский http://lissianski.narod.ru Константин, мне кажется, что поставленный вопрос не имеет отношения к конкретному инструментарию и достоин обсуждения как отрыве от инстументария так и применительно к любому инструменту. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.02.2005, 19:30
|
|||
|---|---|---|---|
|
|||
один куб или два |
|||
|
#18+
Согласен. Но что-то мне подсказывает, что автор вопроса имел в виду какой-то конкретный продукт. И если ему начнут отвечать про, например, Hyperion Essbase или Oracle Express, а он имел в виду MS AS, то он начнёт задавать уточняющие вопросы, и окажется, что люди зря старались. Только из этих соображений писал. 2Boom: Сорри, если не по делу наехал. С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.02.2005, 19:50
|
|||
|---|---|---|---|
один куб или два |
|||
|
#18+
2 Booom: Какие основные плюсы и минусы 1.иметь один куб для плановых и фактических данных 2.иметь два разных куба (ну скорость и время процессинга я понимаю, а с концептуальной точки зрения???) Я думаю, что правильнее иметь один куб и для плановых, и для фактических данных (поскольку по отдельности план и факт менее интересны, чем в совокупности). Но не все OLAP-сервера умеют делать кубы на основе более чем одной таблицы фактов... Например, Cognos PowerPlay позволяет это сделать, MS Analysis Services - не позволяет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.02.2005, 20:27
|
|||
|---|---|---|---|
|
|||
один куб или два |
|||
|
#18+
Подымался подобный вопрос в свое время... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.02.2005, 20:39
|
|||
|---|---|---|---|
один куб или два |
|||
|
#18+
Jurii Но не все OLAP-сервера умеют делать кубы на основе более чем одной таблицы фактов... Например, Cognos PowerPlay позволяет это сделать, MS Analysis Services - не позволяет.А что MS AS-у мешает создать куб на основе вьюхи, объединяющей две таблицы фактов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.02.2005, 20:59
|
|||
|---|---|---|---|
один куб или два |
|||
|
#18+
2 Birkhoff: А что MS AS-у мешает создать куб на основе вьюхи, объединяющей две таблицы фактов? Такую вьюху невозможно написать, поскольку у таблиц фактов - разная гранулярность, и в реляционной таблице невозможно разнести агрегированные значения плана по детальным записям факта. Подобная разноска возможна только при многомерном OLAp-моделировании. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.02.2005, 21:35
|
|||
|---|---|---|---|
|
|||
один куб или два |
|||
|
#18+
JuriiMS Analysis Services - не позволяет. MS AS 2000 позволяет делать следующее: 1. Если гранулярность fact tables одинаковая, т.е. они описывают одни и те же метрики, но в разных срезах, например таблица на каждый год, то можно создать один куб со мновеством partitions. При этом fact tables могут быть из разных источников. 2. Если гранулярность разная - как в примере Booom - план и фактические данные, то можно построить один виртуальный куб который будет это обьединять. В MS AS 2005, #1 без изменений, a #2 выглядит для пользователя проще (хотя функциональность примерно такая же) - создается один куб с несколькими measure groups. Моша ---------------------------------------------------- This posting is provided "AS IS" with no warranties, and confers no rights ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.02.2005, 23:06
|
|||
|---|---|---|---|
|
|||
один куб или два |
|||
|
#18+
JuriiНо не все OLAP-сервера умеют делать кубы на основе более чем одной таблицы фактов... Например, Cognos PowerPlay позволяет это сделать, MS Analysis Services - не позволяет. Смотря что называть кубом. Если рассматривать виртуальный куб AS2K, то за ним может стоять несколько таблиц фактов. А начиная с AS2K5 и физический куб можеи базироваться на нескольких таблицах фактов. Кстати в AS2K5 уже нет деления на виртуальные и физические кубы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.02.2005, 11:25
|
|||
|---|---|---|---|
|
|||
один куб или два |
|||
|
#18+
JuriiТакую вьюху невозможно написать, поскольку у таблиц фактов - разная гранулярность, и в реляционной таблице невозможно разнести агрегированные значения плана по детальным записям факта. Подобная разноска возможна только при многомерном OLAp-моделировании. Юра, это рассуждения человека, не понимающего возможностей SQL. Видимо, не в меру "интеллектуальный конструктор выражений", ввёл Вас в заблуждение. С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.02.2005, 12:51
|
|||
|---|---|---|---|
|
|||
один куб или два |
|||
|
#18+
Константин Лисянский JuriiТакую вьюху невозможно написать, поскольку у таблиц фактов - разная гранулярность, и в реляционной таблице невозможно разнести агрегированные значения плана по детальным записям факта. Подобная разноска возможна только при многомерном OLAp-моделировании. Юра, это рассуждения человека, не понимающего возможностей SQL. Видимо, не в меру "интеллектуальный конструктор выражений", ввёл Вас в заблуждение. С уважением, Константин Лисянский http://lissianski.narod.ru Константин, а не могли бы вы более содержательно это прокомментировать. Правильно ли я представляю, что в случае соединения 2 таблиц с разной гранулярностью одна из них должна быть аггрегрована для приведения гранулярности. Какие еще возможности еще есть? Где про это можно почитать? Кимбал? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.02.2005, 13:29
|
|||
|---|---|---|---|
|
|||
один куб или два |
|||
|
#18+
Допустим, есть таблица с планами продаж: месяц, продукт, план И есть с фактами: дата, продукт, план Есть ещё таблица месяцв, в которое есть количество дней в месяце и таблица дней. 1. Делаем джойн таблицы дней с таблицей месяцев: месяц, день, кол-во дней в месяце Назовём это явление месяц/день 2. Делаем джойн таблицы планов с таблицой месяц/день день, продукт, план/кол-во дней в месяце 3. Делайм джойн план-факт. У них теперь одинаковая гранулярность. Получили простейшее разнесение плана на месяц по дням недели. Даже Кимбала читать не обязательно :) Просто напрячься надо слегка :) SQL писать ломает. Извините. Но, поверьте, во вьюху это всё засунуть проблем не составит. Причём можно и посложнее вещи делать. То, что, например, простыми алгоритмами разнесения не во всяком OLAP-тулзе сделаешь. С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.02.2005, 13:29
|
|||
|---|---|---|---|
|
|||
один куб или два |
|||
|
#18+
backfireПравильно ли я представляю, что в случае соединения 2 таблиц с разной гранулярностью одна из них должна быть аггрегрована для приведения гранулярности. Какие еще возможности еще есть? Где про это можно почитать? Кимбал? Прошу прошения, что отвечаю на вопрос, не ко мне адресованный, но тем не менее... Насколько я понял, второй путь - это то, что у Кимбала называется allocation - значение факта из таблицы с аггрегированными показателями по какому-либо правилу разносится на несколько записей в более детальной таблице фактов. Собственно, все об этом прописано в "The data warehouse toolkit, Second Edition", Chapter 5 "Order Management", p. 121, "Header and Line Item Fact with Different Granularity" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.02.2005, 13:30
|
|||
|---|---|---|---|
|
|||
один куб или два |
|||
|
#18+
backfireПравильно ли я представляю, что в случае соединения 2 таблиц с разной гранулярностью одна из них должна быть аггрегрована для приведения гранулярности. Какие еще возможности еще есть? Где про это можно почитать? Кимбал? Я встречался с такими ситуациями: 1) Действительно агрегация данных из таблицы с бОльшей гранулярностью до уровня таблицы с меньшей гранулярностью 2) Дублирование данных из таблицы с большей гранулярностью до уровня таблицы с меньшей гранулярностью. Например, цены заданы на уровне месяца и просто дублируются до уровня отдельных продаж за этот месяц. 3) Преобразование показателя с большей гранулярностью до меньшего уровня. Например, есть затраты на доставку на уровне заказа, нужно распределить их до уровня отдельных товаров. Затраты можно распределить пропорционально весу или количеству единиц товара. Вариантов может быть много. Читал я об этом в документации по MicroStrategy, там использование фактов с разной гранулярностью называется fact extension. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.02.2005, 13:45
|
|||
|---|---|---|---|
|
|||
один куб или два |
|||
|
#18+
По сути задача объединения двух таблиц с разной гранулярностью в терминах DW более общая и часто решается в других областях человеческой деятельности. В частности, как указывал Андрей Прохоров, это например задача разнесения непрямых затрат на виды продукции (или на подразделения фирмы, или на центры дохода и т.п.). В основе метода решения лежит выбор корректного базиса для распределения (в примере Константина - кол-во дней, в примере Андрея - весу или количеству единиц товара.; или занимаемой товаром площади склада, или суммам оплаты основных производственных рабочих разных подразделений, или температуре воздуха в те дни, когда у жены начальника критические дни и т.п.). Я думаю, что почти все, кто здесь присутствует, когда-либо сталкивались с такими задачами. Но это уже имеет мало отношения к обсуждаемой теме и технологии DW/OLAP вообще. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.02.2005, 15:52
|
|||
|---|---|---|---|
один куб или два |
|||
|
#18+
2 Константин Лисянский: Допустим, есть таблица с планами продаж: месяц, продукт, план И есть с фактами: дата, продукт, план Не завидую я той компании, у которой так ведется план и факт... План обычног ведется на уровне групп товаров, регионов и месяцев. А факт - это широкая таблица, с полями дата-время, товар, регион (фед. округ, область, город, район), клиент, менеджер, склад, тип операции и т.д. По некоторым измерениям план надо разносить до того или иного уровня детализации, для разных измерений - разные базисы распределения, для некоторых измерений - план разносить нельзя. Я на 99.9% уверен, что с помощью SQL-запроса (вьюшки) такую задачу решить нельзя (это не просто очень сложно - а скорее - невозможно). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.02.2005, 16:24
|
|||
|---|---|---|---|
|
|||
один куб или два |
|||
|
#18+
JuriiЯ на 99.9% уверен, что с помощью SQL-запроса (вьюшки) такую задачу решить нельзя (это не просто очень сложно - а скорее - невозможно). Спасибо, что сообщили мне об этом. Я и не знал, что это невозможно. Мне показалось, что я показал решение задачи в общем виде. В принципе, готов решить и в частном, если Вы поставите условие более формально. Однако я при этом тоже готов поставить условие - Вы не будете даже заикаться о возможностях SQL и реляционных СУБД на этом форуме. Ну как? С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.02.2005, 17:08
|
|||
|---|---|---|---|
|
|||
один куб или два |
|||
|
#18+
Андрей Прохоров backfireПравильно ли я представляю, что в случае соединения 2 таблиц с разной гранулярностью одна из них должна быть аггрегрована для приведения гранулярности. Какие еще возможности еще есть? Где про это можно почитать? Кимбал? Я встречался с такими ситуациями: 1) Действительно агрегация данных из таблицы с бОльшей гранулярностью до уровня таблицы с меньшей гранулярностью 2) Дублирование данных из таблицы с большей гранулярностью до уровня таблицы с меньшей гранулярностью. Например, цены заданы на уровне месяца и просто дублируются до уровня отдельных продаж за этот месяц. 3) Преобразование показателя с большей гранулярностью до меньшего уровня. Например, есть затраты на доставку на уровне заказа, нужно распределить их до уровня отдельных товаров. Затраты можно распределить пропорционально весу или количеству единиц товара. Вариантов может быть много. Читал я об этом в документации по MicroStrategy, там использование фактов с разной гранулярностью называется fact extension. Да видно что то с утра был сонный и не сообразил. Однако юзал я уже все эти 3 вида :-), и давно все это было, что сходу у меня даже ассоциации на эту тему не возникли. JuriiЯ на 99.9% уверен, что с помощью SQL-запроса (вьюшки) такую задачу решить нельзя (это не просто очень сложно - а скорее - невозможно). Если запросы строить, елозя мышем по столу, то вы скорее всего правы - невозможно, а если головой думать и руками писать, то все возможно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.02.2005, 18:02
|
|||
|---|---|---|---|
|
|||
один куб или два |
|||
|
#18+
to backfire -- Поддерживаю SQL это рульная штука! Я даже могу нарастающий итог посчитать на диалекте Oracle. -- Юрий дайте пример. У меня есть опыт реализации декомпазиции планов по дням с учетом их доли в прошом периоде. Это прогноз между прочем!!! И работает этот запрос пулей.. Ответ на топик.... Я бы посоветовал сделать один куб, так проше работат и это не так сложно как кажеться и проше в обслужевании. Один куб не два... P.S. OLAP всеволишь измерительный инструмент, это только благодоря всяким оптимистам типа Константина и Юрия он стал нечно таким уж запредельным, а в целом он просто может промерить вам факт с учетом ваших размеров! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.02.2005, 18:31
|
|||
|---|---|---|---|
один куб или два |
|||
|
#18+
backfire Если запросы строить, елозя мышем по столу, то вы скорее всего правы - невозможно, а если головой думать и руками писать, то все возможно. Да, но тогда зачем нужен интеллектуальный построитель запросов Impromptu. Наверное, он не такой уж "интеллектуальный". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.02.2005, 20:55
|
|||
|---|---|---|---|
один куб или два |
|||
|
#18+
2 Константин Лисянский: Я на 99.9% уверен, что с помощью SQL-запроса (вьюшки) такую задачу решить нельзя (это не просто очень сложно - а скорее - невозможно). Спасибо, что сообщили мне об этом. Я и не знал, что это невозможно. Отлично, теперь Вы это знаете :) Мне показалось, что я показал решение задачи в общем виде. Вспомните математику. Корни полиномиального многочлена до третьей степени можно найти по формулам, но вот начиная с четвертой степени - это невозможно. Примерно то же самое относится к количеству полей в таблице фактов. В принципе, готов решить и в частном, если Вы поставите условие более формально. Я постараюсь, хотя это довольно трудоемко - набить вручную то, что годами пользователи заносят в учетную систему... Однако я при этом тоже готов поставить условие - Вы не будете даже заикаться о возможностях SQL и реляционных СУБД на этом форуме. Вы хотите, чтобы содержание форума обеднело? Я может не самый крутой эксперт в РСУБД и SQL, но и не ламер... 2 backfire & noodle: Если запросы строить, елозя мышем по столу, то вы скорее всего правы - невозможно, а если головой думать и руками писать, то все возможно. Да, но тогда зачем нужен интеллектуальный построитель запросов Impromptu. Наверное, он не такой уж "интеллектуальный". Господа, представьте, что Вы написали ручками сложный SQL-запрос, потом вас уволили, а через месяц Вашему бывшему руководителю захотелось по-другому распределить значение плана по уровням иерархии факта... Он попросит это сделать программиста, который будет работать после вас, этот программист не сможет разобраться в вашем сложном запросе... Трагедия какая-то. Вот поэтому разумные руководители, когда выбирают для себя аналитическую систему, всегда задумываются, не будут ли они зависеть от разработчиков и программистов? Если в системе есть конструктор выражений - то в его формулах разбораться несложно, а в рукописном коде - сложно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.02.2005, 21:03
|
|||
|---|---|---|---|
|
|||
один куб или два |
|||
|
#18+
Jurii Вы написали ручками сложный SQL-запрос, потом вас уволили Богатый жизненный опыт? ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.02.2005, 21:09
|
|||
|---|---|---|---|
один куб или два |
|||
|
#18+
2 Злобный ныпэрс: Вы написали ручками сложный SQL-запрос, потом вас уволили Богатый жизненный опыт? ;) Увы, в этой области у меня вообще нет никакого опыта. Меня никогда не увольняли :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.02.2005, 21:44
|
|||
|---|---|---|---|
|
|||
один куб или два |
|||
|
#18+
JuriiГоспода, представьте, что Вы написали ручками сложный SQL-запрос, потом вас уволили, а через месяц Вашему бывшему руководителю захотелось по-другому распределить значение плана по уровням иерархии факта... Юра, всегда есть люди, кто готов и стоит даже в очереди чтобы платить за езду на Mазерати ручной сборки, хотя большинство ездит на Меринах конвейрных. Обычно спецы экстракласса уходят сами.... Работодатель в таком случае само виноват, что не смог удержать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=49&tablet=1&tid=1871743]: |
0ms |
get settings: |
9ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
81ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
64ms |
get tp. blocked users: |
2ms |
| others: | 257ms |
| total: | 450ms |
| 0 / 0 |
