Первый основан на использовании
Java и JavaBeans, второй – на основе технологии
ActiveX. Безотносительно того, какая технология
используется, апплеты реализуют следующие
преимущества : небольшой объем, что обеспечивает
быструю загрузку ;большую интерактивность
и более дружественный интерфейс по сравнению
с обычными HTML-страницами;
легкость в разработке и сопровождении
.
СУБД
История развития СУБД тесно
связана с совершенствованием подходов
к решению задач хранения данных и управления
транзакциями. Развитый механизм управления
транзакциями в современных СУБД сделал
их основным средством построения OLTP-систем,
основной задачей которых является обеспечение
выполнения операций с БД.
Системы управления базами
данных остаются важными компонентами
всех OLTP систем, в том числе и WebOLTP. Для оптимизации
в архитектуре WebOLTP необходимо :
-поддержка нестабильных нагрузок
с отслеживанием таких свойств, как
запрос очередей и приоритетов ;
-высокая скорость соединения
с СУБД из Java-приложений;
-очереди приложений и управление
ресурсами как средства сокращения
общего объема ресурсов
в системе и достижения стабильной
производительности в рамках
Internet-транзакции;
-обеспечение безопасности,
как например, уполномоченная авторизация,
т.е. соответствие, для определенных WebOLTP-приложений;
-распределенная обработка
запросов, которая позволила бы обрабатывать
все многообразие типов данных, встречающихся
в среде WebOLTP
6.Преимущества и
недостатки
OLTP-системы оптимизированы для небольших
дискретных транзакций. А вот запросы
на некую комплексную информацию (к примеру
поквартальная динамика объемов продаж
по определённой модели товара в определённом
филиале), характерные для аналитических
приложений (OLAP), породят
сложные соединения таблиц и просмотр
таблиц целиком. На один такой запрос уйдет
масса времени и компьютерных ресурсов,
что затормозит обработку текущих транзакции
.
OLTP-системы оперативной обработки
транзакций характеризуются большим количеством
изменений, одновременным обращением
множества пользователей к одним и тем
же данным для выполнения разнообразных
операций — чтения, записи, удаления или
модификации данных. Для нормальной работы
множества пользователей применяются
блокировки и транзакции. Эффективная
обработка транзакций и поддержка блокировок
входят в число важнейших требований к
системам оперативной обработки транзакций.
К этому классу систем относятся,
кстати, первые СППР — информационные
системы руководства (ИСР, Executive Information
Systems). Такие системы, как правило, строятся
на основе реляционных СУБД, включают
в себя подсистемы сбора, хранения и информационно-поискового
анализа информации, а также содержат
в себе предопределенное множество запросов
для повседневной работы. Каждый новый
запрос, непредусмотренный при проектировании
такой системы, должен быть сначала формально
описан, закодирован программистом и только
затем выполнен. Время ожидания в таком
случае может составлять часы и дни, что
неприемлемо для оперативного принятия
решений.
8.Неэффективность
использования OLTP-систем для анализа данных
Практика использования OLTP-систем
показала неэффективность их применения
для полноценного анализа информации.
Такие системы достаточно успешно решают
задачи сбора, хранения и поиска информации,
но они не удовлетворяют требованиям,
предъявляемым к современным СППР. Подходы,
связанные с наращиванием функциональности
OLTP-систем, не дали удовлетворительных
результатов. Основной причиной неудачи
является противоречивость требований,
предъявляемых к системам OLTP и СППР.
В практике общения с представителями
информационных служб предприятий нередко
приходится сталкиваться с серьезным
недопониманием различий в возможностях,
назначении и роли технологий, предназначенных
для сбора информации, - OLTP-систем (On-Line
Transaction Processing) и технологий анализа информации.
Между тем они существенно различны по
функциональности, и каждая из них отвечает
за свою область в информационной системе
. Задачи OLTP-системы – это быстрый сбор
и наиболее оптимальное размещение информации
в базе данных, а также обеспечение ее
полноты, актуальности и согласованности.
Однако такие системы не предназначены
для максимально эффективного, быстрого
и многоаспектного анализа . Разумеется,
по собранным данным можно строить отчеты,
но это требует от бизнес-аналитика или
постоянного взаимодействия с IT-специалистом,
или специальной подготовки в области
программирования и вычислительной техники.Как
выглядит традиционный процесс принятия
решений в российской компании, использующей
информационную систему, построенную
на OLTP-технологии? Менеджер дает задание
специалисту информационного отдела в
соответствии со своим пониманием вопроса.
Специалист информационного отдела, по-своему
осознав задачу, строит запрос оперативной
системе, получает электронный
отчет и доводит его до сведения
руководителя. Такая схема принятия
критически важных решений
обладает следующими существенными недостатками:
используется ничтожное количество данных;
-процесс занимает длител
-требуется повторение
цикла в случае необходимости
уточнения данных или
рассмотрения данных в другом
разрезе, а также при возникновении дополнительных
вопросов. Причем этот медленный цикл
приходится повторять и, как правило, неоднократно,
при этом времени на анализ данных тратится
ещё больше; негативным образом сказывается
различие в профессиональной подготовке
и областях деятельности специалиста
по информационным технологиям и руководителя.
Зачастую они мыслят разными категориями
и, как следствие, не понимать друг друга;
неблагоприятное действие оказывает такой
фактор, как сложность электронных отчетов
для восприятия. У руководителя нет времени
выбирать интересующие цифры из отчёта,
тем более что их может оказаться слишком
много. Понятно, что работа по подготовке
данных чаще всего ложится на специалистов
информационных отделов. В результате
грамотный специалист отвлекается на
рутинную и малоэффективную работу по
составлению таблиц, диаграмм и т. д., что,
естественно, не способствует повышению
его квалификации.
Перечень основных
противоречий между этими системами приведен
в табл. I. I
Характеристика |
Требования к OLTP-системе |
Требования к системе
анализа |
Степень детализации
хранимых данных |
Хранение только
детализированных данных |
Хранение как детализированных,
так и обобщенных данных |
Качество данных |
Допускаются неверные
данные из-за ошибок ввода |
Не допускаются ошибки
в данных |
Формат хранения
данных |
Может содержать
данные в разных форматах в зависимости
от приложений |
Единый согласованный
формат хранения данных |
Допущение избыточных
данных |
Должна обеспечиваться
максимальная нормализация |
Допускается контролируемая
денормализация (избыточность) для эффективного
извлечения данных |
Управление данными |
Должна быть возможность
в любое время добавлять, удалять и изменять
данные |
Должна быть возможность
периодически добавлять данные |
Количество хранимых
данных |
Должны быть доступны
все оперативные данные, требующиеся в
данный момент |
Должны быть доступны
все данные, накопленные в течение продолжительного
интервала времени |
Характер запросов
к данным |
Доступ к данным пользователей
осуществляется по заранее составленным
запросам |
Запросы к данным
могут быть произвольные и заранее не
оформлены |
Время обработки
обращений к данным |
Время отклика системы
измеряется в секундах |
Время отклика системы
может составлять несколько минут |
Характер вычислительной
нагрузки на систему |
Постоянно средняя
загрузка процессора |
Загрузка процессора
формируется только при выполнении запроса,
но на 100 % |
Приоритетность характеристик
системы |
Основными приоритетами
являются высокая производительность
и доступность |
Приоритетными являются
обеспечение гибкости системы и независимости
работы пользователей |
Степень детализации
хранимых данных — типичный запрос в OLTP- системе,
как правило, выборочно затрагивает отдельные
записи в таблицах, которые эффективно
извлекаются с помощью индексов. В системах
анализа, наоборот, требуется выполнять
запросы сразу над большим количеством
данных с широким применением группировок
и обобщений (суммирования, агрегирования
и т. п.).
Например, в стандартных системах
складского учета наиболее часто выполняются
операции вычисления текущего количества
определенного товара на складе, продажи
и оплаты товаров покупателями и т. д. В
системах анализа выполняются запросы,
связанные с определением общей стоимости
товаров, хранящихся на складе, категорий
товаров, пользующихся наибольшим и наименьшим
спросом, обобщение по категориям и суммирование
по всем продажам товаров и т. д.
Качество данных — OLTP-системы, как правило, хранят
информацию, вводимую непосредственно
пользователями систем (операторами ЭВМ).
Присутствие "человеческого фактора"
при вводе повышает вероятность ошибочных
данных и может создать локальные проблемы
в системе. При анализе ошибочные данные
могут привести к неправильным выводам
и принятию неверных стратегических решений.
Формат хранения
данных— OLTP-системы, обслуживающие
различные участки работы, не связаны
между собой. Они часто реализуются на
разных программно-аппаратных платформах.
Одни и те же данные в разных базах могут
быть представлены в различном виде и
могут не совпадать (например, данные о
клиенте, который взаимодействовал с разными
отделами компании, могут не совпадать
в базах данных этих отделов). В процессе
анализа такое различие форматов чрезвычайно
затрудняет совместный анализ этих данных.
Поэтому к системам анализа предъявляется
требование единого формата. Как правило,
необходимо, чтобы этот формат был оптимизирован
для анализа данных (нередко за счет их
избыточности).
Допущение избыточных
данных — структура базы данных, обслуживающей
OLTP-систему, обычно довольно сложна. Она
может содержать многие десятки и даже
сотни таблиц, ссылающихся друг на друга.
Данные в такой БД сильно нормализованы
для оптимизации занимаемых ресурсов.
Аналитические запросы к БД очень трудно
формулируются и крайне неэффективно
выполняются, поскольку содержат в себе
представления (view), объединяющие большое
количество таблиц. При проектировании
систем анализа стараются максимально
упростить схему БД и уменьшить количество
таблиц, участвующих в запросе. С этой
целью часто допускают денормализацию
(избыточность данных) БД.
Управление данными — основное
требование к OLTP-системам — обеспечить
выполнение операций модификации над
БД. При этом предполагается, что они должны
выполняться в реальном режиме, и часто
очень интенсивно. Например, при оформлении
розничных продаж в систему вводятся соответствующие
документы. Очевидно, что интенсивность
ввода зависит от интенсивности покупок
и в случае ажиотажа будет очень высокой,
а любое промедление ведет к потере клиента.
В отличие от OLTP-систем данные в системах
анализа меняются редко. Единожды попав
в систему, данные уже практически не изменяются.
Ввод новых данных, как правило, носит
эпизодический характер и выполняется
в периоды низкой активности системы (например,
раз в неделю на выходных).
Количество хранимых данных—
как правило, системы анализа предназначены
для анализа временных зависимостей, в
то время как OLTP-системы обычно имеют дело
с текущими значениями каких-либо параметров.
Например, типичное складское приложение
OLTP оперирует с текущими остатками товара
на складе, в то время как в системе анализа
может потребоваться анализ динамики
продаж товара. По этой причине в OLTP-системах
допускается хранение данных за небольшой
период времени (например, за последний
квартал). Для анализа данных, наоборот,
необходимы сведения за максимально большой
интервал времени.
Характер запросов к данным
— в OLTP-системах из-за нормализации БД
составление запросов является достаточно
сложной работой и требует необходимой
квалификации. Поэтому для таких систем
заранее составляется некоторый ограниченный
набор статических запросов к БД, необходимый
для работы с системой (например, наличие
товара на складе, размер задолженности
покупателей и т. п.). Для СППР невозможно
заранее определить необходимые запросы,
поэтому к ним предъявляется требование
обеспечить формирование произвольных
запросов к БД аналитиками.
Время обработки обращений
к данным — OLTP-системы, как правило, работают
в режиме реального времени, поэтому к
ним предъявляются жесткие требования
по обработке данных. Например, время ввода
документов продажи товаров (расходных,
накладных) и проверки наличия продаваемого
товара на складе должно быть минимально,
т. к. от этого зависит время обслуживания
клиента. В системах анализа, по сравнению
с OLTP, обычно выдвигают значительно менее
жесткие требования ко времени выполнения
запроса. При анализе данных аналитик
может потратить больше времени для проверки
своих гипотез. Его запросы могут выполняться
в диапазоне от нескольких минут до нескольких
часов.
Характер вычислительной нагрузки
на систему — как уже отмечалось, работа
с OLTP-системами, как правило, выполняется
в режиме реального
времени. В связи с этим такие
системы нагружены равномерно в течение
всего интервала времени работы с ними.
Документы продажи или прихода товара
оформляются в общем случае постоянно
в течение всего рабочего дня. Аналитик
при работе с системой анализа обращается
к ней для проверки некоторых своих гипотез
и получения отчетов, графиков, диаграмм
и т. п. При выполнении запросов степень
загрузки системы высокая, т. к. обрабатывается
большое количество данных, выполняются
операции суммирования, группирования
и т. п. Таким образом, характер загрузки
систем анализа является пиковым. На рис.
1.3 приведены данные фирмы Oracle для систем
OLTP, на рис. 1.4— для систем анализа, отражающие
загрузку процессора в течение дня.