|
Jurii
Вывести в шапку отчета те месяцы, в которые наилучшим образом продается копченая колбаса, в боковик отчета - вывести магазины, в которых наилучшим образом мы получаем прибыль от продаж ветчины, лучший магазин раскрыть в тех клиентов, которые за прошлый год вернули более 2 процентов от колбасы, которую они купили, и посмотреть при этом в ячейках отчета рентабельность продаж фарша... А чуть ниже вставить строку сумма продаж фарша по городу, и вычислить для каждого месяца из столбца отчета, сколько вышеперечисленные клиенты вышеперечисленного магазина составляют процентов в общем обороте города...
Подобный отчет с помощью OLAP делается элементарно, и производительность при этом - в стиле OLAP, в среднем не более 5 секунд на отчет.
А вот с помощью BO я слабо представляю, что можно такое сделать.
Юра, вам все-таки необходимо почерпнуть дополнительную информацию о БО, так как, то, что вы тут пишите, ничем кроме непрофессионализма не отдает.
В любом отчете БО можно разместить необходимое количество таблиц и графиков, причем они могут пожеланию пользователя изменяться в зависимости от дрилов, или таких понятий в БО как "Разрыв", "Фильтр", "Ранжирование" и т.д.
Так что, я не вижу ничего сложного в формировании этого отчета средствами БО.
ГликогенДа не быстр Cognos8 BI, не быстр, как всех уверяет Юра.
Разница между OLAP-источником и реляционной хорошо индексированной базой в Cognos 8 определяется не как "5 сек. vs 2 мин.", а, скорее, "1.5 мин. vs 2 мин."
Спасибо за информацию, отличную от Юриной. Но давайте не будем ему давать повода в ветке про БО свести всё обсуждение к посторонним вещам, таким как Cognos
Jurii В OLAP-клиенте пользователь видит не только измерения, но и уровни иерархии, и их мемберов, и может в боковик/шапку отчета в одном уровне перетащить мемберов из разных уровней (например в первую строчку - Россия, во вторую - Москва, в третью - Питер, а в четвертой сделать процент Москвы и Питера от всей России. Вот это уже проявление гибкости...
Так и быть открою для вас тайну. Иерархии в БО есть. Их можно задавать как на уровне юниверса, так и при создании микрокубов. Пример про структуру отчета по географии наоборот подчеркивает гибкость БО. Кто, работал с БО, подтвердят, что разбить отчет на уровни в зависимости от географии в вашем случае от силы 10 щелчков мыши и одна формула для получения процента Москвы и Питера.
Jurii В микрокуб не войдет много данных...
А сколько войдет, вы считали? Что за выводы из ничего?
JuriiЦенность микрокубов сомнительна. Не понимаю, почему BO до сих пор не научился делать не микро-кубы, а большие и мощные кубы...
Как вы оценивали микрокубы? Может быть, ваши глаза режет приставка "микро", так объясню, что это означает: таблицы фактов реляционного хранилища огромны (надеюсь все согласны) и имеют связь с большим количеством справочников. Было бы глупо выбирать в один БО-куб всю информацию по нескольким таблицам фактов и всем, привязанным к ним справочникам, так как для решения реальных задач пользователей в определенный момент времени достаточно иметь информацию, например, о 10 измерениях из 1000 и 10 мерах из 100 за период 1 год из 10. Поэтому БО и прибавляет к названиям кубов приставку "микро", так данные, получаемые пользователем, это только малая часть всей информации доступной ему, но вполне достаточной для решения поставленных задач.
И как пример:
Допустим, есть таблица фактов по продажам со следующими мерами: продажи в единицах, рублях, инвалюте, маржа, продажи по себестоимости, продажи по средним ценам, сумма скидки и т.д.
И следующие таблицы измерений: клиенты, сотрудники, товар, склады, офисы, календарь.
И три пользователя БО:
1) Мерчендайзер-аналитик
2) Логист
3) Директор офиса
1) Мерчендайзер в своей деятельности (анализ продаж товара, новых коллекций и т.д.) будет использовать такие меры как продажи в единицах, маржа, продажи по себестоимости, продажи по средним ценам и измерения товар и календарь.
2) Логист для контроля за шириной ассортимента и количеством товара на складах: меры продажи в единицах, измерения товар, календарь, офис, склад.
3) Директор офиса для анализа продаж клиентам и работы торговых представителей: меры продажи в рублях, продажи в инвалюте, сумма скидки.
Измерения: клиенты, сотрудники, офисы, календарь.
Каждый из этих пользователей нуждается только в части информации из реляционной таблицы и остальная информация была бы для них избыточна, находись она в большом кубе, и усложняла бы доступ к данным.А так при помощи БО каждый может на основе таблицы фактов построить нужный(ые) ему микрокуб(ы) и создать необходимый для анализа набор отчетности.
Из этого следует, что БО со своими микрокубами является универсальным средством для построения любых форм отчетности на основе реляционных хранилищ и olap-серверов(модуль OLAP Intelligence) и при этом не нуждается в больших и мощных кубах.
Jurii BO показывает высокую производительность в случаях, когда под каждый отчет имеется реляционная таблица с агрегатами, либо когда надо сделать выборку записей по индексам без агрегирований больших объемов данных, либо когда данных немного... А вот аналитические запросы, аналогичные вышеописанному, и даже не обязательно такие сложные, делаться быстро в BO не могут, если их вообще можно сделать, хоть небыстро...
БО как раз таки и заточен на работу с реляционными хранилищами данных, но и кроме этого содержит достаточно мощный функционал для доступа и создания отчетов из/совместно/ других источников данных. И быстрота доступа к данным напрямую зависит от проектирования структуры хранилища, а вот создание отчетов на основе полученных данных зависит от количества измерений, мер, и дополнительных вычислений (от "мгновенно" до "нескольких дней").
|
