Разработка модуля отчетности в среде Oracle BI Publisher для оптимизации нагрузки на АБИС

Содержание
Введение................................................................................................................... 111
1 ОБЩАЯ ЧАСТЬ .................................................................................................. 114
1.1 Потребность в анализе данных .................................................................... 114
1.2 Хранилища данных ....................................................................................... 114
1.3 Архитектура и компоненты хранилища данных ...................................... 115
1.4 Таблицы фактов и измерений в хранилищах данных ............................... 116
1.5 Основные схемы многомерной модели ...................................................... 118
1.6 Базовый процесс управления хранилищами данных – ETL .................... 120
1.6.1 Извлечение данных в ETL..................................................................... 121
1.6.2 Преобразование данных ........................................................................ 121
1.6.3 Загрузка данных ..................................................................................... 121
1.7 Централизованное хранилище данных с ETL ........................................... 122
1.8 Расширенная модель ХД с витринами данных .......................................... 124
1.9 Oracle Business Intelligence ........................................................................... 126
1.10 Инструменты генерации запросов и отчетов ........................................... 129
1.11 Структура программы на PL/SQL ............................................................. 130
1.12 Приведение типов ....................................................................................... 131
1.13 Коллекции .................................................................................................... 132
1.14 Объектно-ориентированное программирование в PL/SQL .................... 134
1.15 Пакеты языка PL/SQL................................................................................. 137
1.16 Внешние процедуры ................................................................................... 138
2 СПЕЦИАЛЬНАЯ ЧАСТЬ.................................................................................... 140
2.1 Общая постановка задачи............................................................................. 140
2.2 Описание выгружаемых отчетов ................................................................. 141
2.2.1 Связи фактов и измерений для выгружаемых отчетов ...................... 141
2.2.2 Требования и процесс создания пакета для «Отчета о финансовых
потоках и запасах» .......................................................................................... 150
2.2.3 Основные финансовые инструменты «Отчета о финансовых
потоках и запасах» .......................................................................................... 152
2.2.4 Выгрузка коллекции в PL/SQL Developer ........................................... 158
2.2.5 Требования и процесс создания пакета для «Отчета об остатках на
балансовых счетах за вычетом резервов (провизий)» ................................. 160
2.2.6 Требования и процесс создания пакета для отчета «Основные
показатели баланса»........................................................................................ 165
2.3 Создание модели данных для отчетов ........................................................ 170
2.4 Создание отчета в среде Oracle Business Intelligence Publisher ................ 175
2.5 Выгрузка отчета средствами Oracle Business Intelligence Publisher......... 177
2.6 Планирование запуска отчета ...................................................................... 178
2.7 Витрины данных............................................................................................ 181
3 ТЕХНИКО – ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ ПРОЕКТА ................. 184
3.1 Описание работы и обоснование необходимости ..................................... 184
3.2 Трудовые ресурсы, используемые в работе ............................................... 185
3.3 Оборудование и программное обеспечение, используемое в работе ...... 185
3.4 Расчет стоимости разработки программного обеспечения ...................... 186
3.5 Сроки реализации проекта ........................................................................... 187
3.5.1 Расчет затрат на оплату труда............................................................... 188
3.5.2 Расчет затрат по социальному налогу.................................................. 193
3.5.3 Расчет амортизационных отчислений.................................................. 194
3.5.4 Расчет затрат на электроэнергию ......................................................... 195
3.5.5 Расчет затрат на накладные расходы ................................................... 196
3.5.6 Расчет стоимости по всем статьям затрат ........................................... 196
3.6 Цена интеллектуального труда .................................................................... 197
3.7 Вывод.............................................................................................................. 198
4 БЕЗОПАСНОСТЬ ЖИЗНЕДЕЯТЕЛЬНОСТИ, ОХРАНА ТРУДА И
ПРОМЫШЛЕННАЯ ЭКОЛОГИЯ ........................................................................ 198
4.1 Описание работы и обоснование необходимости ..................................... 198
4.2 Анализ условий труда в производственном помещении ......................... 199
4.3 Трудовые ресурсы и требования ................................................................. 200
4.4 Расчет освещенности на рабочем месте точечным методом.................... 201
4.5 Вывод.............................................................................................................. 207
Заключение .............................................................................................................. 208
Перечень сокращений ............................................................................................. 210
Список литературы ................................................................................................. 211
Приложение А. Листинг созданных пакетов для отчетов ..................................

1.1 Потребность в анализе данных

Во всем мире в процессе своей деятельности организации накапливают
или уже накопили очень большие объемы данных. Эти коллекции данных
хранят в себе большие потенциальные возможности по извлечению новой,
аналитической информации, на основе которой необходимо выявлять
тенденции развития рынка, строить стратегию фирмы, находить новые
решения, обусловливающие успешное развитие в условиях конкурентной
борьбы. Для большинства фирм, у которых динамическое развитие такой
анализ является неотъемлемой частью их повседневной деятельности, но
большинство, только начинает приступать к нему всерьез.
Попытки строить системы принятия решений, которые обращались бы
непосредственно к базам данных систем оперативной обработки транзакций,
оказываются в большинстве случаев неудачными. Во-первых, аналитические
запросы «конкурируют» с оперативными транзакциями, блокируя данные и
вызывая нехватку ресурсов. Во-вторых, структура оперативных данных
предназначена для эффективной поддержки коротких и частых транзакций и
в силу этого слишком сложна для понимания конечными пользователями и,
кроме того, не обеспечивает необходимой скорости выполнения
аналитических запросов. В-третьих, в организации, как правило,
функционирует несколько оперативных систем; каждая со своей базой
данных. В этих базах используются различные структуры данных, единицы
измерения, способы кодирования и т.д. Для конечного пользователя задача
построения какого-либо сводного запроса по нескольким подобным базам
данных практически неразрешима.

1.2 Хранилища данных

Для того чтобы обеспечить возможность анализа накопленных данных,
организации стали создавать хранилища данных, которые представляют
собой интегрированные коллекции данных, которые собраны из различных
систем оперативного доступа к данным. Хранилища данных становятся
основой для построения систем принятия решений. Несмотря на различия в
подходах и реализациях, всем хранилищам данных свойственны следующие
общие черты:
предметная ориентированность. Информация в хранилище данных
организована в соответствии с основными аспектами деятельности
предприятия (заказчики, продажи, склад и т.п.); это отличает хранилищ
данных от БД, где данные организованы в соответствии с процессами
(выписка счетов, отгрузка товара и т.п.). Предметная организация данных в
хранилище способствует как значительному упрощению анализа, так и
повышению скорости выполнения аналитических запросов. Выражается она,
в частности, в использовании иных, чем в оперативных системах, схемах
организации данных. В случае хранения данных в реляционной системы
управления базами данных.(СУБД) применяется схема «звезды» (star) или
«снежинки» (snowflake). Кроме того, данные могут храниться в специальной
многомерной СУБД в n-мерных кубах;
 интегрированность. Исходные данные извлекаются из оперативных
БД, проверяются, очищаются, приводятся к единому виду, в нужной степени
агрегируются (то есть вычисляются суммарные показатели) и загружаются в
хранилище. Такие интегрированные данные намного проще анализировать;
 привязка ко времени. Данные в хранилище всегда напрямую
связаны с определенным периодом времени. Данные, выбранные их
оперативных БД, накапливаются в хранилище в виде «исторических слоев»,
каждый из которых относится к конкретному периоду времени. Это
позволяет анализировать тенденции в развитии бизнеса;
 неизменяемость. Попав в определенный «исторический слой»
хранилища, данные уже никогда не будут изменены. Это также отличает
хранилище от оперативной БД, в которой данные все время меняются,
«дышат», и один и тот же запрос, выполненный дважды с интервалом в 10
минут, может дать разные результаты. Стабильность данных также облегчает
их анализ.

1.3 Архитектура и компоненты хранилища данных
Англоязычный термин «Data Warehousing», который означает в
широком смысле «создание, поддержку, управление и использование
хранилища данных» и хорошо подтверждает тот факт, что речь идет о
процессе. Цель этого процесса непрерывная поставка необходимой
информации нужным сотрудникам организации. Этот процесс подразумевает
постоянное развитие, совершенствование, решение все новых задач и
практически никогда не кончается, поэтому его нельзя уместить в более или
менее четкие временные рамки, как это можно сделать для разработки
традиционных систем оперативного доступа к данным.
Хранилища данных могут быть разбиты на два типа: корпоративные
хранилища данных и киоски данных.
Корпоративные хранилища данных содержат информацию,
относящуюся ко всей корпорации и собранную из множества оперативных
источников для консолидированного анализа. Обычно такие хранилища
охватывают целый ряд аспектов деятельности корпорации и используются
для принятия как тактических, так и стратегических решений.
Корпоративное хранилище содержит детальную и обобщающую
информацию; его объем может достигать от 50 Гбайт до одного или
нескольких терабайт. Стоимость создания и поддержки корпоративных
хранилищ может быть очень высокой. Обычно их созданием занимаются
централизованные отделы информационных технологий, причем создаются
они сверху вниз, то есть сначала проектируется общая схема, и только затем
начинается заполнение данными. Такой процесс может занимать несколько
лет.
Киоски данных содержат подмножество корпоративных данных и
строятся для отделов или подразделений внутри организации. Киоски
данных часто строятся силами самого отдела и охватывают конкретный
аспект, интересующий сотрудников данного отдела. Киоск данных может
получать данные из корпоративного хранилища или, что более
распространено, данные могут поступать непосредственно из оперативных
источников.
Киоски и хранилища данных строятся по сходным принципам и
используют практически одни и те же технологии.
Основными компонентами хранилища данных являются следующие:
 оперативные источники данных;
 средства проектирования/разработки;
 средства переноса и трансформации данных;
 СУБД;
 средства доступа и анализа данных;
 средства администрирования [1].

1.4 Таблицы фактов и измерений в хранилищах данных

Таблица фактов является основной таблицей хранилища данных. Как
правило, она содержит сведения об объектах или событиях, совокупность
которых будет в дальнейшем анализироваться.
Обычно говорят о четырех наиболее часто встречающихся типах
фактов. К ним относятся:
 факты, связанные с транзакциями (англ. Transaction facts). Они
основаны на отдельных событиях (типичными примерами которых являются
телефонный звонок или снятие денег со счета с помощью банкомата);
 факты, связанные с «моментальными снимками» (англ. Snapshot
facts). Основаны на состоянии объекта (например, банковского счета) в
определенные моменты времени, например на конец дня или месяца.
Типичными примерами таких фактов являются объем продаж за день или
дневная выручка;
 факты, связанные с элементами документа (англ. Line-item facts).
Основаны на том или ином документе (например, счете за товар или услуги)
Архипенков С.В., Голубев Д. К. Хранилища данных. От концепции до внедрения. М.: Диалог-МИФИ
и содержат подробную информацию об элементах этого документа
(например, количестве, цене, проценте скидки);
 факты, связанные с событиями или состоянием объекта (англ. Event
or state facts). Представляют возникновение события без подробностей о нем.
Таблица фактов, как правило, содержит уникальный составной ключ,
объединяющий первичные ключи таблиц измерений. Чаще всего это
целочисленные значения либо значения типа «дата/время» в целочисленном
формате ведь таблица фактов может содержать сотни тысяч или даже
миллионы записей, и хранить в ней повторяющиеся текстовые описания, как
правило, невыгодно лучше поместить их в меньшие по объему таблицы
измерений. При этом как ключевые, так и некоторые не ключевые поля
должны соответствовать будущим измерениям OLAP-куба. Помимо этого
таблица фактов содержит одно или несколько числовых полей, на основании
которых в дальнейшем будут получены агрегатные данные.
Для многомерного анализа пригодны таблицы фактов, содержащие как
можно более подробные данные (то есть соответствующие членам нижних
уровней иерархии соответствующих измерений). Бывает предпочтительнее
взять за основу факты продажи товаров отдельным заказчикам, а не суммы
продаж для разных стран последние все равно будут вычислены OLAP-
средством, в случае использования такового. Исключение можно сделать,
пожалуй, только для клиентских OLAP-средств, поскольку в силу ряда
ограничений они не могут манипулировать большими объемами данных.
Необходимо отметить, что в таблице фактов нет никаких сведений о
том, как группировать записи при вычислении агрегатных данных.
Например, в ней есть идентификаторы продуктов или клиентов, но
отсутствует информация о том, к какой категории относится данный продукт
или в каком городе находится данный клиент. Эти сведения, в дальнейшем
используемые для построения иерархий в измерениях куба, содержатся в
таблицах измерений. В случае построения отчетов напрямую из хранилища
данных, минуя промежуточный шаг создания OLAP-кубов, также могут
использоваться т.н. агрегатные таблицы фактов,содержащие более
крупнозернистую информацию, например суммарные траты покупателя в
выбранном магазине за месяц, вместо или в дополнение к детальной таблице
фактов с подробной.
Таблица измерений таблица в структуре многомерной базы данных,
которая содержит атрибуты событий, сохраненных в таблице фактов.
Атрибуты представляют собой текстовые или иные описания, логически
объединенные в одно целое. Например, имя покупателя может являться
атрибутом в таблице измерений покупателей, а наименование товара, в
таблице измерений товаров. В то время как сумма транзакции является
величиной аддитивной, и ее значение должно храниться в таблице фактов.
Таблица фактов связана с таблицами измерений с помощью внешнего
ключа
1.5 Основные схемы многомерной модели

Существуют несколько схем для многомерного моделирования данных.
Две из них считаются основными: схема «звезда» и схема «снежинка». В
более сложных случаях используются так называемые «многозвездочные»
схемы или схема с несколькими таблицами фактов.
Схема «звезда» имеет одну таблицу фактов и несколько таблиц
измерений. Схема «снежинка» имеет одну таблицу фактов и несколько
нормализованных таблиц измерений.
Схема «звезда» имеет те же самые элементы, что диаграммы
«сущность-связь». Это сущности, атрибуты, первичные и внешние ключи,
взаимосвязи, кардинальность связи. На рисунке 1.1 приведен пример схемы
«звезда», созданной для учета продажи бакалейных товаров. Таблица фактов
«Продажи бакалеи» (учет операций продажи бакалейных товаров торговой
компании) имеет один первичный ключ «Номер счета», четыре внешних
ключа (по числу измерений) и два параметра: «Количество» и «Стоимость
товара».
Рисунок 1.1 - Схема «звезда»

Измерение «Время» является одним из критических элементов модели
хранилища данных (ХД). Если данные в OLTP-системах запросы
фокусируются на текущем моменте времени, то в системах поддержки
принятия решений, для которых проектируются и создаются ХД, запросы
фокусируются на задачах анализа данных, а именно как данные изменялись
в различные периоды времени. Например, каков был объем продаж торговой
компании за последний квартал, месяц или тенденции в покупках в течение
последнего квартала.
Измерение «Магазин» позволяет сгруппировать операции продаж по
магазинам с учетом их географического положения.
Измерение «Товары» позволяет анализировать типовые схемы закупок
товаров и отвечать на вопрос, какие товары, как правило, покупаются
одновременно покупателями.
Измерение «Покупатели» позволяет анализировать покупки с учетом
их частоты, географического положения и количества.
Таблицы измерений являются своеобразным путеводителем при
выборке строк из таблицы фактов. Таблицы фактов имеют большое
количество строк. Таблицы измерений, как правило, имеют гораздо меньшее
число строк. Одним из главных преимуществ использования такой схемы
является то, что производительность операции СУБД соединения таблицы
фактов и таких таблиц соединений будет близка к оптимальной.
Схема «снежинка» (рисунок 1.2) добавляет иерархию в таблицы
измерений. Например, измерение «Регион» группирует магазины по
географическим регионам, измерение «Категория товара» группирует товары
по категориям, измерение «Категория покупателей» группирует покупателей
по категориям, а измерение «Период продаж» группирует продажи по
периодам времени.
Рисунок 1.2 - Схема «снежинка»
Таким образом, использование иерархий превращает схему «звезда» в
схему «снежинка». Можно расширять схемы «снежинка» за счет добавления
в нее новых иерархий [2].
1.6 Базовый процесс управления хранилищами данных – ETL

ETL (от англ. Extract, Transform, Load извлечение, преобразование,
загрузка) один из базовых процессов управления ХД, а также наименование
класса утилит автоматизации этого процесса. ETL в узком смысле относится
к технологиям консолидации данных, но современные решения,
представленные на рынке, поддерживают помимо реализации, федерализации данных и консолидации, а также обмена данными.
Цель ETL-приложения состоит в том, чтобы своевременно предоставить необходимые
данные его пользователям. Традиционно
предприятия использовали программы ETL для передачи операционных
Спирли Эрик. Корпоративные хранилища данных. Планирование, разработка, реализация. – М.: Изд.:
Вильямс, 2001. т. 1.
данных в системы бизнес-интеллекта, такие как ХД или киоски данных или
переноса информации из унаследованных приложений в новые.
В целом приложения ETL извлекают информацию из исходной базы
данных, преобразуют ее в формат, поддерживаемый базой данных
назначения, а затем загружают в нее преобразованную информацию.

1.6.1 Извлечение данных в ETL
Начальным этапом процесса ETL является процедура извлечения
записи из источников данных и подготовка их к процессу преобразования.
При разработки процедуры извлечения данных, в первую очередь
необходимо определить частоту выгрузки данных из OLTP-систем (Online
Transaction Processing), или отдельных источников. В зависимости от объема
извлекаемых данных, сложности доступа к ним и скорости работы
оборудования выгрузка данных занимает определённое время, которое
называется окном выгрузки.
Процедуру извлечения можно реализовать двумя способами:
 извлечение данных с помощью программных средств;
 извлечение данных средствами той системы, в которой они
хранятся.
После извлечения данные помещаются в так называемую
«промежуточную область», где для каждого источника данных создаётся
своя таблица или отдельный файл, или и то и другое.....