С помощью SAP BusinessObjects Voyager ваши бизнес-аналитики смогут быстро исследовать OLAP-данные, вырабатывать бизнес-рекомендации и отвечать на запросы, а затем совместно с коллегами работать надо полученной аналитикой. Voyager позволяет распространять знание поверх границ рабочего места, отдела или группы аналитики.

SAP BusinessObjects Voyager это:

• мощный анализ и совместное использование данных OLAP;
• всесторонний доступ к данным;
• низкая стоимость развертывания.

Анализ и совместное использование данных OLAP

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

Однако быстрый доступ к данным - это решение только половины реальной проблемы. Аналитикам необходимо так же иметь возможность производить определенные вычисления и осуществлять обзор потенциальных бизнес-сценариев. Voyager отвечает этим потребностям, обеспечивая возможность любых видов вычислений, в том числе и тех, которые свойственны функциональности ведущих современных OLAP-хранилищ. Средства визуализации Voyager в комбинации с подсветкой предельных значений позволяют аналитикам быстро обнаруживать тенденции и идентифицировать сложные шаблоны (рис. 1)

Рис. 1. Визуализация в SAP BusinessObjects Voyager

Как только аналитики завершили свою работу, они могут предоставить результаты для совместного применения как внутри организации, так и за ее пределы, используя при этом другие решения  Business Intelligence. Кроме этого, Voyager позволяет экспортировать результаты анализа как в формат Excel, так и в формат PDF. Таким образом, эти результаты могут быть легко распечатаны, сохранены или пересланы через каналы передачи информации.

Всесторонний доступ к данным

Ключевым требованием при осуществлении финансового - или бизнес - анализа является доступ к как можно более широкому диапазону источников данных OLAP в организации. Voyager позволяет не только осуществлять полноценный доступ к различным источникам данных, но и объединять данных из разных информационных систем и источников в одном рабочем пространстве. Это существенно сокращает время на консолидацию и проведение анализа данных, и освобождает аналитиков от зависимости от группы консолидации данных.

Voyager так же позволяет для получения ответа на определенный вопрос обновлять только нужные для данной процедуры данные. Это дает возможность получать ответы быстро, легко и элегантно.  Аналитики в Voyager могут получить различные представления одного и того же OLAP-куба, или разных OLAP-кубов в пределах одного рабочего пространства (рис. 2). Например, аналитики могут совместить оценку тенденции продаж с просмотром учетных записей клиентов. Voyager поддерживает практически все известные OLAP-хранилища, включая SAP, Microsoft и Oracle.

Рис. 2. Одновременный доступ к различным OLAP-кубам

Низкая стоимость развертывания

Для успешного проведения OLAP-анализа, аналитик должен иметь возможность доступа к данным независимо от того, где они располагаются географически. SAP BusinessObjects Voyager выполнен на основе современных web-технологий, и насыщен самыми последними достижениями в этой области. В результате получился тонкий клиент, наделенный самыми богатыми возможностями настольного приложения. Такое решение позволяет основательно понизить стоимость развертывания. Для работы Voyager нет необходимости отдельно разрабатывать, поставлять и поддерживать независимое решение для OLAP - аналитики, он входит в состав комплексного решения SAP BusinessObjects XI, таким образом вы можете централизованно управлять вопросами безопасности, подключения, выбора данных и сохранения документов, тем самым так же значительно снижая стоимость развертывания решения.

И это только часть айсберга

Надо добавить, что OLAP-кубы используются не только Voyager, они служат источниками данных для множества других технологий  Business Intelligence, включая генерацию отчетов, запросы и аналитику по требованию, и другие. SAP BusinessObjects Voyager является частью стратегии, назначение которой - предоставление необходимых инструментов каждому пользователю.

Технология Crystal Reports имеет прямой доступ к OLAP-кубам, что позволяет на их основе генерировать отчеты, в то время как технология SAP BusinessObjects Web Intelligence обеспечивает аналитику по специфицированным запросам на основе данных, извлеченных из OLAP-кубов.

Главная выгода

SAP BusinessObjects Voyager входит в состав технологий, на которые распространяются условия об OEM-партнерстве. Это значит, что интегрировав Voyager в свой программный продукт (информационную систему или интеграционное решение),  вы получаете возможность поставлять эту технологию под своей торговой маркой.  При этом вы получаете явные финансовые, конкурентные, имиджевые и маркетинговые выгоды.  Надо учесть и тот факт, что такой путь гораздо дешевле (в сравнении с покупкой технологии), а спрос на Business Inelligence у конечного заказчика постоянно растет. 

Ключевые моменты

• Быстрый доступ к OLAP-данным - возможность быстрее получить ответы на бизнес - вопросы при анализе многомерных данных.
• Всесторонний доступ к данным - проистекает из возможности подключаться к широкому диапазону источников OLAP-данных.
• Визуализация и подсветка при выходе за предельные значения - позволяет выявить и проанализировать тенденции и сложные шаблоны.
• Совместный доступ к результатам и данным - данные могут совместно использоваться и внутри организации, и за ее пределами.
• Современный и богатый возможностями интерфейс пользователя - полностью соответствует специфическим потребностям аналитика.

Бизнес - преимущества

• Увеличивает производительность и самостоятельность, поскольку аналитики получают доступ ко всем OLAP-данным быстрее и эффективнее.
• Выработка более обоснованных решений обеспечивается широким и легким доступом к результатам анализа всех заинтересованных лиц.
• Уменьшение времени на консолидацию данных, и меньшая зависимость аналитиков от IT-подразделений.
• Более связное восприятие данных, благодаря возможности одновременно просматривать несколько OLAP-кубов на одном рабочем пространстве.
• Уменьшение стоимости развертывания благодаря использованию тонкого клиента и интеграции в другие технологии SAP BusinessObjects business intelligence.

С современным уровнем развития дисциплины управления требованиями, хранение и работа с требованиями в текстовых документах кажется анахронизмом. Существует множество систем управления требованиями, и многопользовательских клиент-серверных, и однопользовательских локальных, позволяющих работать со структурой и иерархией требований, формулировками и оформлением, а также предопределенными и пользовательскими метаданными. Однако часто возникают ситуации, когда текстовый документ является необходимым. Например: техническое задание как формальный документ, подписываемый заказчиком и исполнителем; спецификация требований для согласования с заказчиком; план-график реализации требований и т.д. Фактически все эти документы - это определенный срез данных из единой базы требований по проекту. Соответственно, у пользователя должна быть возможность быстрой и удобной генерации требуемого документа, содержащего актуальную информацию.

В данной статье мы рассмотрим процесс генерации документов в системе управления требованиями Borland/Microfocus CaliberRM.

В системе Borland/Microfocus CaliberRM для генерации документов предназначена утилита Document Factory. Document Factory может генерировать документы в форматах .doc, .rtf и .txt. Принцип действия Document Factory довольно прост - это анализ шаблона документа и замена ключевых слов значениями из базы данных требований, а также выполнение команд и операторов, указанных в теле шаблона. При подготовке шаблона используются следующие термины:

• Команды (commands). С помощью команд определяется выборка, сортировка и группировка требований из базы данных.
• Ключевые слова (keywords). Ключевые слова в шаблоне подменяются на соответствующие значения из базы данных требований.
• Операторы (operators). Операторы представляют собой определенные критерии для поиска групп требований.

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

Рассмотрим структуру шаблона. Так как в базе данных может существовать несколько проектов по работе с требованиями, а в каждом проекте может быть несколько базовых линий (baseline) требований, в шаблоне документа нужно указать наименование проекта и базовой линии с помощью команд $PROJECT и $BASELINE. Соответственно, в документ попадут только требования из указанного проекта и отмеченные заданной базовой линией. В случае если в проекте не задано базовых линий (точнее, существует только одна - Current Baseline), то команду $BASELINE можно не указывать. В случае если задано несколько базовых линий, а в шаблоне документа команда $BASELINE не указана, то при генерации документа будет выдано диалоговое окно с возможностью выбора базовой линии требований, для которой необходимо генерировать документ. При отсутствии в шаблоне документа команды $PROJECT, при генерации документа будет выдано диалоговое окно для выбора проекта. Такой подход удобен, когда используется универсальный шаблон для нескольких проектов, а генерация документа выполняется вручную. Однако при автоматической генерации по расписанию (мы рассмотрим эту возможность ниже) такой вариант неприемлем.

Для отображения определенных групп требований используется понятие секций и команды $BEGIN_SECTION и $END_SECTION. Данные команды начала и окончания секции представляют собой своеобразный цикл по требованиям в базе данных. Например, если между этими командами указать ключевое слово <<name>>, то в документе будут выведены наименования всех требований в заданном проекте. Для того чтобы выводить ограниченный набор требований по какому-либо условию используются команда $FILTER. Например, чтобы вывести в секцию только бизнес-требования, необходим следующий код (точнее текст, а не код):

$BEGIN_SECTION

…

$FILTER{type = "1. Business Requirements"}

…

$END_SECTION

Важные замечания: секций в шаблоне может быть сколько угодно много, но они не должны быть вложенными; все команды, кроме $PROJECTS, $BASELINE и пары $BEGIN_SIGNATURES/ $END_SIGNATURES должны находиться внутри секций; в одной секции может быть только одно использование одной команды.

Рассмотрим следующий пример с использованием дополнительных команд:

$BEGIN_SECTION

$FILTER{type = "3. Functional Requirements"}

$SORT{hierarchy}

$INDENTION_LEVEL{3}

$INDENTION_SIZE{.5}

<<tag>><<id_number>>. <<name>>

<<description>>

$END_SECTION

В данном примере в документ будут выведены только функциональные требования (команда $FILTER), требования будут отсортированы в порядке возрастания по иерархии (команда $SORT). Команда $INDENTION_LEVEL{3} говорит о том, что будут выведены требования только трех верхних уровней вложенности, требования более глубоких уровней будут проигнорированы. Команда $INDENTION_SIZE{.5} задает размер отступа в дюймах при выводе требований из разных уровней вложенности. Непосредственно вывод производится с помощью ключевых слов <<tag>> (тэг требования), <<id_number>> (номер требования по базе данных), <<name>> (заголовок требования) и <<description>> (текст требования). В команде $FILTER можно использовать математические и логические операции, а также слова Like, Not Like, Between, Not Between, In и Not In.

Также интерес представляют следующие команды:

• $BEGIN_LIST/$END_LIST - используется для вывода списков, например, списка ответственных исполнителей назначенных за реализацию требования.
• $BEGIN_HISTORY/$END _HISTORY - используется для вывода истории изменений требований.
• $BEGIN_TRACES/ $END _TRACES - используется для вывода информации о связях трассировки с другими требованиями.
• $BEGIN_DISCUSSIONS/ $END_DISCUSSIONS - используется для вывода дискуссий, проводимых "вокруг" требований.
• $BEGIN_GLOSSARY/ $END_GLOSSARY - используется для вывода глоссария.
• $CALCULATE - используется для выполнения элементарных математических операций (умножение, деление, сложение, вычитание) над атрибутами требований.

Наиболее часто используются следующие ключевые слова:

• <<type>> - тип требования
• <<hierarchy>> - иерархический номер
• <<id_number>> - идентификатор требования по базе данных
• <<status>> - статус требования
• <<priority>> - приоритет требования
• <<description>> - детальное описание требования (текст требования)
• <<tag>> - тэг требований (код типа требования)
• <<name>> - имя (заголовок) требования
• <<version>> - номер версии требования
• <<owner>> - текущий владелец требования

В случае если используются пользовательские атрибуты требований - их также можно использовать в шаблоне обрамляя двойными скобками: <<пользовательский_атрибут>>.

Теперь рассмотрим процесс генерации документа на основе созданного шаблона с помощью утилиты Document Factory. Утилиту можно запустить из меню "Пуск" (отобразиться окно, представленное на рис.1) или с помощью нажатия кнопки "Document Factory" из клиентской части CaliberRM (отобразиться окно, представленное на рис.2, без запроса параметров подключения).

Рис.1. Параметры подключения к серверу CailberRM.

Рис.2. Указание пути к шаблону и конечному файлу.

Необходимо указать путь к файлу шаблона и путь к конечному файлу. Если необходимо при генерации создавать лог-файл - нужно поставить соответствующую галочку "Create Log File". Установка галочки "Warn about ambiguous tags" позволит выводить предупреждения о нераспознанных тегах, например, написанных с синтаксической ошибкой. После нажатия кнопки "Далее" отображается окно установки дополнительных параметров (рис.3).

Рис.3. Установка дополнительных параметров. 

В верхней части задается формат вывода даты - короткий или длинный, в нижней части задается режим вывода ключевых слов. При выборе значения Once замена ключевого слова происходит только один раз, то есть следующие вхождения данного ключевого слова заменены не будет. При выборе значения Multiple будут заменены все вхождения ключевого слова. После нажатия кнопки "Далее" отображается окно установки дополнительных параметров (рис.4).

Рис.4. Установка дополнительных параметров.

На данном окне задаются следующе параметры. Источник формирования требований: из базы данных (Use CaliberRM server data) или из ранее сохраненного набора данных (Use previously saved data). Для сохранения набора данных необходимо установить галочку "Save data for subsequent use", при этом данные будут сохранены в формате mdb-файла. При установке галочки "Create configuration file only" будет сформирован конфигурационный файл с выставленными параметрами. Данный файл можно использовать для автоматизированной генерации документов по расписанию. Установкой галочки "Requirement description will include formatted text, tables and images" пользователь задает, будет ли использовано оформление требования из базы данных CailberRM или из шаблона документа. После установки дополнительных параметров необходимо нажать кнопку "Готово" для начала генерации документа.

В случае если в шаблоне не был указан конкретный проект с помощью команды $PROJECT, будет выдано окно с выбором проекта (рис.5).

Рис.5. Выбор проекта

После выбора проекта и нажатия кнопки "Ок" начинается непосредственно генерация документа (рис.6).

Рис.6. Процесс генерации документа.

 

В случае если генерация прошла успешно, пользователю выдается запрос на открытие сгенерированного документа. При нажатии кнопки "Да" документ будет открыт в программе Microsoft Word.

Рис.7. Запрос на открытие документа.

Теперь рассмотрим возможности автоматической генерации документов по расписанию.

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

C:Program FilesBorlandCaliberRMDocfactory.exe /conffile.ini 

Затем данную команду можно запланировать на запуск с определенной периодичностью, например, с помощью стандартной программы Windows "Планировщик заданий".

Таким образом, возможности, предоставляемые CaliberRM и Document Factory, позволяют создавать практически любые документы с произвольным оформлением, содержащие информацию из базы данных требований CaliberRM.

Часть 2 Теперь, когда для приложения созданы таблицы EMP, DEPT и HR_REPS, напишем процедуру, которая позволит установить значения контекста приложения. Контекст приложения будет состоять из двух элементов данных - EMPNO пользователя, присоединенного в данный момент, и его роль (одна из EMP, MGR или HR_REP).

Проблемы эффективного использования данных Корпоративные системы управления предприятием, созданные на основе реляционных СУБД, как правило, эффективно решают задачи учета, контроля и хранения данных. Однако в силу своей специфики, реляционная структура не позволяет решать задачи анализа имеющейся информации с требуемой производительностью.

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

Введение Автономные транзакции доступны в Oracle8i, Oracle8i EE и Oracle8i Workstation. Автономные транзакции предоставляют новый метод контролирования транзакций в хранимых процедурах. Автономные транзакции позволяют создавать новые подтранзакции (subtransaction), которые могут сохранять или отменять изменения вне зависимости от родительской транзакции.

Версия Oracle 8i (8.1), выпущенная в 1999 году после долгих задержек, содержит большой объем нововведений (как утверждает сама фирма, "более 150"). Многие из них коснулись такой базовой компоненты, как PL/SQL.

Часть 2 Физическая модель данных После создания полной и адекватной логической модели вы готовы к принятию решения о выборе платформы реализации. Выбор платформы зависит от требований к использованию данных и стратегических принципов формирования архитектуры корпорации. Выбор платформы - сложная проблема, выходящая за рамки данной книги. В ERwin физическая модель является графическим представлением реально реализованной базы данных.

Введение В настоящее время Delphi является одним из наиболее популярных программных продуктов для создания информационных систем. На его основе создаются как небольшие программы, так и системы масштаба предприятия.

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

22 января мы опубликовали на нашем сайте статью независимого эксперта А.Малинина "Правда о MS SQL Server". Статья сразу же вызвала бурный отклик у наших читателей. Предлагаем Вашему вниманию рецензию российского Представительства Microsoft, ее автор - ведущий специалист компании, системный инженер по SQL Server А.Шуленин. Рецензия на статью А.

Часть 3 Обработка ошибок и отладка За и против Демонстрационные скрипты Теперь присоединимся различными пользователями и протестируем функциональность приложения. SQL> @rls_adams SQL> -- Присоединимся как служащий, у которого нет способности управлять. SQL> connect rls_adams/rls_adams Connected.

Осенью 2000 года корпорация Oracle объявила о подготовке к выпуску новой версии своего базового продукта - версии Oracle 9i. На самом деле под именем Oracle 9i скрывается связка из двух продуктов. Это сервер приложений Oracle - Oracle 9i Application Server и СУБД Oracle - Oracle 9i Database. Основным новшеством Oracle 9i Application Server является его возможность кэшировать как данные, так и Web страницы.

Интерес к Интернет-технологиям чрезвычайно велик - число сайтов во всем мире растет катастрофическими темпами.

Вызов несуществующих процедур и обращение к несуществующим таблицам Известно, что MS SQL Server осуществляет компиляцию сохраненных процедур в момент первого выполнения процедуры. В документации на MS SQL Server можно прочитать: Referencing Objects SQL Server allows the creation of stored procedures that reference objects that do not yet exist. At creation time, only syntax checking is done.

Часть 1 Оглавление Common Type System Данные со значениями Перечисления Структуры Ссылочные типы Классы Методы События Делегаты Массивы Интерфейсы Указатели Заключение В предыдущей статье мы начали знакомство с Microsoft .NET Framework - ключевым компонентом Microsoft .NET, представляющим собой платформу для создания, внедрения и выполнения Web-сервисов и приложений. Мы рассмотрели основные компоненты Microsoft .

Новая самоуправляемая СУБД Oracle повышенной производительности и готовности уже приступает к коммерческим grid-вычислениям. Есть тенденции, и есть те, кто их устанавливает. В начале и середине 1990-х годов корпорация Oracle предвидела парадигму internet-вычислений, которую теперь организации всех типов внедряют в основу своего бизнеса. В рамках этого процесса ИТ-инфраструктура приобрела чрезвычайно важное значение для предприятий.

Выпустив в 1983 г. первую версию языка и среды программирования Turbo Pascal, компания Borland Software открыла новую страницу в истории развития средств разработки приложений. Через 12 лет, в 1995-м, увидела свет и первая версия Delphi (оказавшаяся в то же время последним 16-разрядным компилятором), в которой была реализована основанная на компонентах методология быстрой разработки приложений (RAD).