Всем добрый вечер. Передо мной стоит задача формирования задания на разработку OLAP-отчета.
Задача для меня новая, поэтому у меня возникли сложности при подготовке вопросов для выявления требований к отчету, и, соответственно, при формировании технического задания: нет четкого представления о содержимом этого документа.
К сожалению, примеров документов по подобной задаче мне найти не удалось
Отсутствие шаблона документа ставит меня в тупик при формировании перечня открытых вопросов, а также определении состава необходимых для формирования задания исходных данных.
Наставьте на путь истинный, подскажите, пожалуйста, примерный состав ТЗ на разработку OLAP-отчета (в т.ч. каком виде следует описывать требования к измерениям и показателям, кроме указания их названия, источника...).

Я выскажу некие свои мысли, если неправ, пускай знающие поправят.
Во-первых, нужно чётко определить бизнес-пользователя, то есть кто будет использовать результыты. Далее, для каких целей, к примеру, для поддержки принятия оперативного решения будет весьма критично время. Далее, вопрос источников информации - если есть хранилище данных - это одно, если нет, то возникает вопрос сбора, консолидации, очистки данных и регламента этих процессов. То есть, это всё в первую очередь.
ИМХО.

... Далее, вопрос источников информации - если есть хранилище данных - это одно, если нет, то возникает вопрос сбора, консолидации, очистки данных и регламента этих процессов. То есть, это всё в первую очередь.
ИМХО.

Тут STUTK абсолютно прав. Если Вы делаете то что вы называете OLAP-отчет не над готовым хранилищем, то я Вам не завидую, ибо инфу надо собрать сконсолидировать, проверить целостность и т.п. Тогда задача построения отчета перерастает совсем в другую задачу!!!

я так понимаю что OLAP отчет отличается от просто отчета гибкостью представления данных. т.е. в отличии от обычного отчета форма которого более менее жестко задана внешнее представление OLAP отчета не может и не должно быть жестко регламентировано. Если Вы вкладываете в термин OLAP отчет чтото еще напишите - интересно..

Поэтому при описании таких отчетов мне кажется надо описывать какие факты и в каких размерностях будут отображаться. Ну еще может возникнуть требования к хранилищу - если то что нужно для такого отчета не хранится в нем, а считать налету дорого... Можно еще описать дефолтный вид отчета при открытии..

Раз задача для Вас новая, возможно Вы некорректно ее формулируете. Что значит для Вас "разработка OLAP-отчета"?

Вам нужно отдельный отчет разработать в имеющейся OLAP-системе? или саму OLAP-систему?
Хранилище есть? Там есть первичные данные для Вашего отчета? или Вам нужно эти данные еще и собрать? (впрочем коллеги об этом уже спросили).

P.S. В качестве простейшего и одного из доступных OLAP-средств посмотрите сводные таблицы (pivot table) Excel. Если у Вас есть хранилище, то можно попробовать смоделировать Ваш отчет в нем. Так Вы лучше поймете, что должно быть в ТЗ с предметной точки зрения.


 

Передо мной стоит задача формирования задания на разработку OLAP-отчета.
Задача для меня новая

Какая задача для Вас новая, написание ТЗ на OLAP, или вообще работа с OLAP? Вряд ли можно написать ТЗ, не имея личного опыта работы с OLAP в конкретных практических целях.

Не могу не согласиться со всеми высказанными замечаниями по поводу некорректности формулировки задачи.

Раз задача для Вас новая, возможно Вы некорректно ее формулируете. Что значит для Вас "разработка OLAP-отчета"?

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

Вам нужно отдельный отчет разработать в имеющейся OLAP-системе? или саму OLAP-систему?
Хранилище есть? Там есть первичные данные для Вашего отчета? или Вам нужно эти данные еще и собрать? (впрочем коллеги об этом уже спросили).

Хранилища данных как раз и нет, мне необходимо сформулировать требования как к хранилищу данных, так и к необходимым представлениям.

Тут STUTK абсолютно прав. Если Вы делаете то что вы называете OLAP-отчет не над готовым хранилищем, то я Вам не завидую, ибо инфу надо собрать сконсолидировать, проверить целостность и т.п. Тогда задача построения отчета перерастает совсем в другую задачу!!!

В этом вопросе коллеги обещали в некоторой степени помочь.

Во-первых, нужно чётко определить бизнес-пользователя, то есть кто будет использовать результыты.

Именно этим и планирую заняться в ближайшее время: выявить всех заинтересованных лиц и определить их запросы, отсюда получить перечень необходимых измерений и показателей. Разработкой самой OLAP-системы (если с термином опять не путаю) будет заниматься сторонняя организация, для которой, собственно, и необходимо подготовить ТЗ. В связи с этим, как мне кажется, возникает задача формулирования источника этих измерений и показателей (предполагаю, что на уровне конкретных запросов к БД). Поправьте меня, если я ошибаюсь.

Далее, для каких целей, к примеру, для поддержки принятия оперативного решения будет весьма критично время.

Очень интересное замечание.

Всех благодарю за ответы, появилось много мыслей и вопросов (!), что, несомненно, большой шаг вперед при изучении новой области. Так что работать, работать и снова работать.

Вряд ли можно написать ТЗ, не имея личного опыта работы с OLAP в конкретных практических целях.

тут Вы неправы, иначе бы ни одной системы нельзя было бы создать в принципе, опыта работы с отсутствующей системой-то тоже не было бы :о))

тут Вы неправы, иначе бы ни одной системы нельзя было бы создать в принципе, опыта работы с отсутствующей системой-то тоже не было бы :о))

Каждая новая система нова только максимум на 5%. Чтобы написать на нее ТЗ надо досконально знать остальные 95%. А на 100% новую систему именно в принципе нельзя создать. Иначе почему бы было не начать создавать OLAP системы на следующий день после ввода в эксплуатацию ЭВМ ENIAC в 1946 году?

Может быть такая аналогия поможет: представьте себе человека, пишущего ТЗ на текстовый редактор, и никогда не работавший с MS Word или его функциональными аналогами, только с Notepad. Представили себе это ТЗ?
Чтобы что-то требовать, надо знать достигнутые на сегодня горизонты, и понимать, какие проблемы возникают у пользователя именно на этом горизонте.

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

Если задача действительно важна для Вашего руководства, то рекомендую потребовать отправить Вас на курсы, причем  именно по той платформе, которая у вас будет использоваться. Сэкономите себе и конторе массу времени и денег.

Каждая новая система нова только максимум на 5%. Чтобы написать на нее ТЗ надо досконально знать остальные 95%. А на 100% новую систему именно в принципе нельзя создать. Иначе почему бы было не начать создавать OLAP системы на следующий день после ввода в эксплуатацию ЭВМ ENIAC в 1946 году?

Может просто потому, что в ней на тот момент не было необходимости?

Каждая новая система нова только максимум на 5%. Чтобы написать на нее ТЗ надо досконально знать остальные 95%. А на 100% новую систему именно в принципе нельзя создать. Иначе почему бы было не начать создавать OLAP системы на следующий день после ввода в эксплуатацию ЭВМ ENIAC в 1946 году?

Может быть такая аналогия поможет: представьте себе человека, пишущего ТЗ на текстовый редактор, и никогда не работавший с MS Word или его функциональными аналогами, только с Notepad. Представили себе это ТЗ?
Чтобы что-то требовать, надо знать достигнутые на сегодня горизонты, и понимать, какие проблемы возникают у пользователя именно на этом горизонте.

в общем, я с Вами не согласен.
первичным вижу всё-таки потребности предметной области, а не существующие технические возможности.
В свою очередь напомню про покорение космоса, создание атомной бомбы и другие прорывные проекты в областях о которых было довольно смутное представление. Я конечно не отрицаю пропагандируемый Вами подход мелких шажков при реализации проектов, но с точки зрения рассматриваемого вопроса (разработка ТЗ) он неверен.

Разделяю точку зрения Водолея. Верхнеуровневые требования к OLAP системе (или репорту на ее основе) МОЖНО писать понимая только бизнес и его потребности. Но чем ниже уровень требований, т.е чем дальше отходите от чисто бизнесовых требований к реализации, тем сложнее общаться с архитектором системы (в данном случае с внешней компанией) и разработчиками. Знания же платформы на которой строят вашу OLAP систему можно ограничить пониманием концепции ее построения
 

В свою очередь напомню про покорение космоса, создание атомной бомбы и другие прорывные проекты в областях о которых было довольно смутное представление.

Рискую уйти в офтопик, но оба приведенные Вами примера знакомы мне не из художественной литературы, а по прошлой специальности. Уверяю, там все проекты шли именно мелкими шажками, которые пропустили, когда снимали про это кино Никакого смутного представления о том, чего нужно достигнуть, перед каждым новом шагом не было - было чрезвычайно конкретное ТТЗ Миноборны, невыполнение которого жестко наказывалось.
Да, эти мелкие шажки делались очень быстро, но Вы бы тоже быстро делали софт, если бы от этого зависела ваша жизнь и свобода Вашей семьи.
Типичный этап (от ТТЗ  до натурных испытаний) занимал в разгар этих проектов около месяца, так что эти проекты можно считать первыми проектами, проведенными по Agile методологии, а их проджект-менеджера (Л.П.Берию) - первым Agile-гуру. 

Всем добрый вечер. Передо мной стоит задача формирования задания на разработку OLAP-отчета <...> нет четкого представления о содержимом этого документа<...>

Начните с того, на какие вопросы хочет получить ответ пользователь при помощи "OLAP-отчётов". Дальше, если нужны именно отчёты, согласовать с заказчиком список и содержание отчётов. Возможно "OLAP" и "ad-hoc" на самом деле не нужно, а нужно ввести пару параметров в условии фильтрации, вывести таблицу и строчку "итого". Это и опишите.

Если заказчику непременно хочется именно слова "OLAP" - предложите ему SAS или Business Objects в качестве средства реализации. Дорого. А "восстанавливать" UC существующих платформ для построения "OLAP" - дело неблагодарное. В т.ч. потому, что приведёт к написанию собственного велосипеда.

Обобщая тему интересно было бы услышать о
1 особенностях работы аналитика/постановшика в DW/OLAP проектах
2 наборе документах создаваемых для таких проектах

на основе своего опыта или ссылки на статьи...