Оперативная обработка транзакций (OnLine Transaction Processing - OLTP) - важнейшее средство взаимодействия с информацией, находящейся в внутри «умных» железяк. Между тем, построение сложных, высокопроизводительных OLTP-систем - непростая задача. Многообразие технологий, модные веяния зачастую ставят разработчика в тупик при выборе конкретного решения или заставляют «натягивать» известные технологии на поставленную задачу, что порой ведет к непредсказуемым результатам. Когда в одном проекте фигурирует несколько платформ, задача становится на порядок сложнее.

С точки зрения прикладных задач любая интерактивная система имеет три основных уровня: хранение данных; прикладная логика; представление (интерфейс с конечным пользователем). Соответственно, с точки зрения реализации, система может включать сервер данных, сервер прикладной логики (сервер приложения) и набор интерфейсов для представления информации конечному пользователю. В качестве основы для сервера данных, как правило, используют СУБД SQL-типа, файловые структуры или специальные источники данных. С интерфейсными формами тоже все понятно: можно реализовывать графические интерфейсы, текстовые «зеленые экраны», Web-интерфейсы и т.п. А вот вопрос реализации сервера приложения не так прост, как может показаться на первый взгляд. Если посмотреть на существующие отечественные реализации систем, можно выделить две тенденции:

логика размещается вместе с интерфейсами («толстый» клиент);
логика размещается на стороне сервера данных (встречается гораздо чаще).

В последнем случае, как правило, используются СУБД SQL-типа, которые наделены некоторыми функциями поддержки сервера приложения в виде механизма хранимых процедур. Трехзвенная схема при реализации трансформируется в двухзвенную клиент-серверную архитектуру. Для небольших систем это вполне приемлемое решение, однако такой архитектуре присущ ряд недостатков, в том числе ограниченная масштабируемость. Ее реализация, даже на мощных платформах класса S/390, позволяет достичь пиковой производительности не более 200 транзакций в секунду .

В некоторых реализациях разработчики выделяют сервер приложений в самостоятельный компонент. Но эти реализации, как правило, представляют лишь набор прикладных программ, которые не опираются на какие-либо специальные службы, а пользуются стандартными механизмами операционной системы, что, вообще говоря, не выводит систему на иной качественный уровень по сравнению с двухзвенной архитектурой. Это справедливо практически для любой платформы, за исключением AS/400 и VM/ESA, где сами операционные системы являются транзакционным сервером. На других платформах подобная функциональность может быть достигнута только при помощи дополнительных специальных продуктов, которые в числе прочих и будут затронуты в данной статье.

Мозаика технологий

Начиная с платформы ПК, используя на начальных этапах технологии Borland и Microsoft, наша компания реализовала несколько проектов в двухзвенной архитектуре. По мере роста размеров проектов, включения в них нескольких платформ, встал вопрос поиска и оптимизации применяемых технологий для построения систем с необходимыми потребительскими свойствами.

Опробовав различные технологии и инструменты, мы остановили свой выбор на технологиях IBM, предоставляющей широкий спектр открытых аппаратно-программных решений. Учитывая, что мы реализуем OLTP-проекты для заказчиков, которые часто уже применяют технологии Microsoft, Oracle и других компании, возможность совместного использования решений IBM и альтернативных поставщиков была весьма кстати (рис. 1).

Для реализации особо тонких системных моментов мы прибегаем также к программированию на языках С++ или Кобол, однако это занимает не более 1-2% от общего объема работ.

Монитор транзакций IBM CICS

Монитор транзакций CICS (Custom Information Control System), имеющий богатую историю, более чем за 30 лет своего существования стал в своей области лидером. Именно программное обеспечение промежуточного слоя является надежным хребтом для построения OLTP-систем.

Монитор транзакций - достаточно сложный продукт, который привносит функции контроля целостности данных при выполнении операций . Сложная OLTP-система может иметь несколько источников данных (СУБД, файлы и т.д.); монитор транзакций позволяет прикладной программе работать с ними одновременно и изменять их состояние. При этом, если в рамках транзакции хотя бы один источник данных не будет переведен в последующее состояние, то и остальные источники будут возвращены в состояние до начала транзакции. Это гарантирует целостность данных, предотвращает рассогласование данных в источниках. Такая служба отсутствует в большинстве операционных систем. При этом источники данных могут быть как локальными, так и распределенными, находясь на различных серверах и платформах. Если в системе используется монитор транзакций, то со стороны разработчика не требуется ощутимых затрат для поддержки функций контроля целостности на уровне прикладной логики.

Будучи реализован практически для всех основных платформ, CICS позволяет построить сложную распределенную гетерогенную транзакционную среду. CICS использует интерфейс X/Open XA для взаимодействия с различными менеджерами ресурсов и организации интерфейсов с продуктами основных производителей СУБД. Применение монитора транзакций делает систему более масштабируемой по сравнению решениями, «в центр» которых помещена СУБД. Так, на базе стандартных редакций CICS можно строить системы с пиковой производительностью 500 транзакций в секунду, а при помощи специальных версий (например, ПО Transaction Processing Facility, применяемое в системах оперативного резервирования авиабилетов) и с более высокими пиковыми нагрузками.

Заметим, что TPC, отраслевые тесты на пиковую производительность СУБД (www.tpc.org ), проводятся с применением мониторов транзакций, что позволяет получить наилучшие показатели. Почему? Монитор транзакций играет роль «турбонаддува» для СУБД, помимо прочего, ускоряя выполнение SQL-запросов из-за особенностей конструкции как своего ядра, так и интерфейса с СУБД (интерфейс в двухзвенной клиент-серверной архитектуре очень ограничен по производительности). Это позволяет минимизировать время на диспетчеризацию запроса перед его обработкой ядром СУБД. Кроме того, в мониторах транзакций лучше, чем в СУБД, решен вопрос с балансировкой нагрузки .

CICS поддерживает пять типов высокоуровневого взаимодействия между серверами, которые могут быть организованы поверх любых сетевых протоколов (TCP/IP, SNA, NetBIOS и др.).

Function Shipping (FS). Изменение источников данных (файлов), которые являются удаленными по отношению к локальному серверу CICS. При обращении из транзакции на локальном сервере CICS к такому источнику, он автоматически перенаправляет запрос к тому серверу, который владеет этим источником данных. Обеспечивается целостность данных в случае каких-либо сбоев.
Transaction Routing (TR). Перенаправление вызова транзакции между серверами CICS. Можно «переселять» транзакцию с сервера на сервер, при этом требуется лишь переопределить ссылку на сервере CICS без изменения кода программы.
Asynchronous Processing (AP). Асинхронный запуск транзакции на другом сервере CICS. Новая транзакция начинает «жить» самостоятельно, а управление немедленно возвращается в вызвавшую транзакцию.
Distributed Program Link (DPL). Вызов удаленной транзакции с возвратом управления после окончания работы вызванной транзакции. Этот тип взаимодействия в прикладных системах используется наиболее часто.
Distributed Transaction Processing (DTP). Диалог в оперативном режиме двух транзакций, работающих на разных серверах CICS. С точки зрения разработки и отладки это наиболее экзотический и сложный тип взаимодействия.

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

Транзакционный сервер очередей MQSeries

Концепция работы программного обеспечения промежуточного слоя типа MOM, в частности MQSeries, довольно проста. Прикладная программа кладет некоторую структуру данных (сообщение) в очередь на локальном сервере MQSeries и заканчивает работу. Сохраненное сообщение из локальной очереди передается канальным агентом MQSeries (channel agent) на удаленный сервер MQSeries и сохраняется там во входной очереди. При этом из локальной очереди сообщение удаляется. MQSeries гарантирует транзакционность передачи - сообщение не будет потеряно или передано дважды (это основное преимущество перед почтовыми системами, которые нередко используются для реализации функций распределенной обработки). После получения сообщения на удаленном сервере прикладная программа может прочитать его в любой удобный момент и выполнить необходимые действия; пока приложение не прочтет это сообщение, оно будет храниться в MQSeries.

MQSeries может быть подключен к монитору транзакций CICS наравне с СУБД. В этом случае CICS выступает как внешний координатор транзакций (External Transaction Coordinator - ETC), что исключает ситуации, когда при каком-либо сбое данные в СУБД были изменены, а сообщение не отправлено или наоборот - данные не изменились, а сообщение об изменении было отправлено. Это, в конечном счете, приводит к ситуации рассогласования данных на распределенных узлах OLTP-системы. Использование монитора транзакций позволяет избежать таких ситуаций.

Возглавляя рынок MOM (более 70%), MQSeries дополняет CICS возможностью построения сложной гетерогенной распределенной транзакционной среды с асинхронным типом взаимодействия.

DB2 Universal Database

DB2 - флагманская СУБД корпорации IBM. Ее применение в качестве основы сервера данных OLTP-систем позволяет реализовать сложную обработку данных и хранение больших массивов. Эти функции перекладываются на сервер данных, разгружая сервер приложения. Но если необходимо сделать систему, где хранение и обработка данных не очень сложны, а требования к производительности и минимизации ресурсов выходят на первый план (код ядра СУБД требует значительных ресурсов), то можно использовать файловые структуры, подключенные к транзакционному серверу CICS. Например, многие известные крупные западные OLTP-системы для мэйнфреймов S/390 построены на базе CICS и VSAM.

WebSphere Application Server

Семейство программных продуктов, обозначаемых маркой WebSphere Application Server, включает три версии - Standard, Advanced и Enterprise. Если говорить о поддержке транзакционности, то версия Standard этой службы не имеет, версия Advanced поддерживает службу Java Transaction Service (JTS), равно как и спецификации Enterprise JavaBeans, а версия Enterprise содержит специальные коннекторы для взаимодействия с «полноприводными» транзакционными системами наподобие CICS.

Говоря о WebSphere, часто имеют в виду только Internet-составляющую этого продукта - Application Server , мощный кросс-платформный сервер приложений, поддерживающий практически все известные спецификации и протоколы.

В реальных проектах мы избегаем программирования бизнес-логики средствами языка Java, поскольку реализация сервера приложения, например, в формате Enterprise JavaBeans, приводит к значительному снижению производительности приложения и заставляет вести разработку на языке третьего поколения, что менее эффективно по сравнению с инструментарием VisualAge Generator. Однако применение Web-браузеров на рабочих местах дает определенные преимущества для интерактивных систем: не надо платить за дополнительные лицензии для клиентских машин; имеется возможность отображать графическую информацию; нет необходимости копировать приложение по клиентским местам.

Обеспечение соединения браузеров с мощными системами «заднего плана» (back-end) требует применения Internet-серверов. WebSphere Application Server можно рассматривать как своего рода адаптер, который позволяет коду из браузера через вызов сервлета (servlet) обратиться к транзакции в CICS и, получив результат, возвратить его в браузер, создав на ходу интерфейсную HTML-страницу.

Заметим, что для OS/390 поддерживается интерфейс CICS Web Support, посредством которого браузер может напрямую подсоединиться к серверу CICS. Но для унификации архитектуры между платформами и, учитывая, что средство разработки приложений VisualAge Generator строит системы с использованием WebSphere Application Server, мы применяем этот продукт и на S/390. Это помогает решить проблемы переноса кода таких приложений между платформами.

Разработка на VisualAge Generator

VisualAge Generator - средство быстрой разработки приложений. Именно этот продукт является тем «клеем», который позволяет достаточно просто соединить все перечисленные выше технологии в единую картину.

Широко распространенные средства разработки, как правило, поддерживают классический цикл создания приложения. При любом изменении в исходном коде необходимо заново проходить весь цикл, что требует значительных временных затрат. Кроме этого, с самого начала разработки нужно иметь целевую платформу для запуска и отладки кода времени выполнения (runtime), что усложняет и замедляет процесс отладки логики приложения (рис. 2).

Цикл разработки приложения средствами VisualAge Generator выглядит несколько иначе (рис. 3). В основе этой среды разработки лежит универсальная виртуальная машина Universal Virtual Machine (UVM), которая является базой для таких сред разработки, как VisualAge for Smalltalk и VisualAge for Java, поверх которых устанавливается VisualAge Generator.

Для запуска и отладки приложения нет необходимости производить компиляцию и сборку приложения. Для отладки работы логики и интерфейсных форм пользуются «малым» циклом (операции 1 и 2), что сокращает время разработки и не требует наличия целевой платформы. В этом цикле производится 80-90% работ и можно обойтись компьютером с Windows NT или OS/2, на котором может быть установлен VisualAge Generator Developer.

После того, как приложение отлажено, можно перейти к созданию кода времени выполнения (runtime) как для серверных, так и для клиентских платформ. При этом целевая платформа нужна только на момент выполнения операции 3. Замечу, что хотя в VisualAge Generator можно создавать приложения любой архитектуры, основное его предназначение - это разработка многоуровневых систем с четким разделением сервера данных, сервера приложения и уровня представления. В качестве клиентских интерфейсов поддерживаются графические, текстовые и Web-ориентированные интерфейсы. Цикл генерации исполняемого кода клиента значительно короче, чем для серверных компонентов. Фактически эта генерация производится в один этап, в результате которого создаются все необходимые компоненты для запуска приложения на клиентской стороне.

В качестве целевой платформы для сервера приложения поддерживаются более 20 платформ, включая CICS и MQSeries. После создания серверного кода времени исполнения его можно отлаживать из среды VisualAge Generator, т.е. проверить работоспособность окончательного кода (большой цикл из операций 3, 4, 5, 6).

В составе VisualAge Generator отсутствуют инструменты для разработки и программирования серверов данных, например, СУБД. Но, имея готовую структуру базы данных, можно автоматически создать всю структуру приложения, включая серверные и клиентские компоненты при помощи средства VisualAge Generator Templates (VAGT), которое входит в поставку. Предопределив некоторые условия, можно автоматически создать практически полную инфраструктуру приложения, что составляет до 80% работ по программированию. Это избавляет разработчика от «ручного» создания таких элементов, как серверные программы, процессы, бизнес-объекты, элементы форм, обработчики исключительных ситуаций и т.д. Учитывая, что в реальных проектах такие элементы исчисляются сотнями и тысячами, VAGT значительно сокращают время создания кода приложения. Далее необходимо лишь наполнить приложения соответствующей бизнес-логикой, которая пишется на языке 4GL.

«Обобщающее обобщение»

На рис. 4 показана общая архитектура распределенной OLTP-системы, которая базируется на описанных технологиях.

Основой системы является CICS (CICS A, например, на платформе Windows NT, CICS B - на платформе S/390). Два этих транзакционных сервера могут взаимодействовать как синхронно (TR, AC, FS, DPL, DTP), так и асинхронно, через MQSeries (менеджеры MQ1 и MQ2 для соответствующих платформ). Менеджеры очередей подсоединены к соответствующим серверам CICS через интерфейс XA. Также к серверам CICS подсоединены различные источники данных (на Windows NT - DB2 и/или СУБД Oracle и Microsoft SQL Server, на S/390 - DB2 и файловые структуры VSAM, которые определены в CICS через Resource Definition Online).

WebSphere Application Server (WSAS) играет роль конвертора вызовов от Web-клиентов к системе «заднего плана» (транзакции P1, P2, P3), написанной на VisualAge Generator.

VisualAge Generator Server (VAGen Srv) - платформнозависимый продукт, необходимый для запуска программ, разработанных на VisualAge Generator.

Возможны прямые соединения с CICS для клиентов с графическим или текстовым интерфейсом пользователя. При этом программы P1, P2 в CICS A могут быть определены как удаленные, тогда их вызовы в CICS A будут автоматически перенаправлены методом TR в CICS B и там запущены. P3 - локальная транзакция в CICS A, которая может посылать сообщения в CICS B через MQSeries.

Надо сказать, что экземпляры CICS, подобные CICS A и CICS B (в CICS их обозначают термином «регион») могут находиться не только на разных машинах, но и на одном сервере или в кластере. Работа регионов изолирована и «падение» одного из них не влияет на работу других. Это так же дает преимущества в масштабируемости, позволяя разделить задачи по регионам с точки зрения специализации. Такой подход наиболее часто практикуется на системах S/390, особенно в кластерах Sysplex. Реальные системы имеют несколько сотен регионов и десятки тысяч транзакций.

Однако сама по себе технология без соответствующих инструментов не дает ожидаемого «выхлопа». Скажем, CICS очень хорош, но если вы попробуете реализовать систему на С++ или Коболе, то это потребует от разработчика бизнес-логики хорошего знания как языка программирования, так и API-интерфейсов CICS, которые сродни API-интерфейсам операционных систем. Масса времени будет потрачена на создание инфраструктурных элементов (описание функций, переменных и т.д.) и отладку такого проекта. Но если взять VisualAge Generator, это избавит разработчика бизнес-логики от необходимости знать CICS, позволив ему сосредоточиться на своих прямых задачах. Конечно, для реализации сложных проектов требуется владение CICS, но это требование уже распространяется не на всех разработчиков, а на двух-трех специалистов, отвечающих за среду выполнения приложения.

«Сплав» технологий и инструментов как раз и дает оптимальный результат; рассмотрение же отдельных продуктов вне системного прикладного контекста для разработчиков сложных не «коробочных» решений не имеет большого смысла. Точно так же мало проку судить о СУБД вне рамок прикладной задачи. Скажем, вы большой поклонник Oracle. Но что делать, если заказчик требует приложение для целевой платформы AS/400? Или у вас большая любовь к DB2, а прикладная система заказчика на S/390 использует VSAM и заказчика полностью устраивает, и речь идет лишь о замене «зеленого» экрана на Web-браузер, чтобы, к примеру, показывать не только алфавитно-цифровые данные.

Реализация OLTP-системы для Внешторгбанка

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

В качестве центрального узла OLTP-системы используется S/390; возможно использование кластера Sysplex. В качестве «банковской машины» применяется пакет от Altel, реализованный на базе CICS TS, VSAM и имеющий «зеленый» интерфейс формата 3270. Кроме центрального узла банк имеет несколько десятков периферийных узлов, в которых используются серверы AS/400 и Windows NT (рис. 5).

Взаимодействие серверов осуществляется посредством MQSeries. Для того чтобы разработчики прикладной логики были изолированы от механизмов вызова транзакций из серверных процессов, написанных на 4GL в VisualAge Generator, была использована методика и набор программ («оборачивающие» транзакции), при помощи которых можно обращаться к функциям из 4GL. Стремясь унифицировать интерфейсы доступа к данным и снизить расходы на рабочие места, заказчик выдвинул требование использования Web-интерфейсов. При этом работа через Web-браузер должна вестись не по принципу «один к одному», как через терминалы 3270, а через HTML-страницу, создаваемую несколькими экранами 3270. При этом необходимо было обеспечить совместимость с системой безопасности. Все это порождало ряд проблем, которые пришлось решать в комплексе.

Проблема № 1. Для вызова транзакции CICS, которая работает с «зеленым экраном», используется протокол EPI (External Presentation Interface), работающий с потоком 3270. При активизации такой транзакции CICS использует терминальное устройство - структуру, которая идентифицирует соединение и является основным атрибутом для транзакции. Так, эта структура содержит четырехсимвольное поле TERMID (идентификатор терминала), которое используется транзакциями для собственной системы безопасности. Такой тип соединения в CICS называют терминальным.

Однако соединение, которое строится для работы Web-браузера, НЕ является терминальным, т. е. для этого соединения НЕ существует такой структуры (в понимании транзакции 3270), что сразу приведет к сбою выполнения транзакции.

Для вызова транзакций 3270 из нетерминальных соединений или из других транзакций CICS, которые были вызваны через протокол ECI (External Call Interface), в мониторе CICS для OS/390 был реализован механизм, называемый 3270 Bridge. Была добавлена новая команда EXEC CICS START BREXIT и при активизации транзакции 3270 через эту команду, CICS создает специальную структуру, называемую Bridge Facility, так называемый суррогатный терминал, который «предъявляется» транзакции 3270 в момент ее инициализации. Но при создании суррогатного терминала CICS самостоятельно генерирует идентификатор для поля TERMID по своей внутренней логике. Этот сгенерированный TERMID никак не связан с реальным идентификатором пользовательского соединения. Это и порождает проблему № 2.

Команда EXEC CICS START BREXIT не поддерживается и со стороны VisualAge Generator - нельзя установить такие параметры, чтобы он сгенерировал команду вызова, так как она появилась только в последних версиях CICS (начиная с версии 1.3). Для решения этой проблемы на Коболе была написана программа, принимающая необходимые параметры и активизирующая транзакцию через эту новую команду. Это пример использования Кобола как языка третьего поколения для реализации тонких системных функций. Программу на Коболе можно вызывать из прикладных транзакций, написанных на 4GL в VisualAge Generator.

Проблема № 2. Для вызова транзакции 3270 используется механизм 3270 Bridge, который создает суррогатный терминал. Но некоторые поля, включая TERMID, CICS инициализирует сам, никак не привязываясь к клиентскому соединению, из которого вызывается эта транзакция. CICS для каждого такого вызова ставит TERMID в значение из интервала с?{AAA? по?{999?, увеличивая его последовательно. Использует стратегию безопасности, которая пришла еще со времен до эпохи SQL - каждому клиенту присваивается для входа через VTAM (Virtual Telecommunication Access Method) восьмисимвольный идентификатор, называемый LU (Logical Unit), который проверяет VTAM. Четыре последних символа из LU берутся для генерации TERMID. Транзакция, отвечающая за идентификацию пользователя, принимает с клавиатуры имя пользователя и его пароль, берет TERMID и смотрит в свой внутренний файл, в котором ищет соответствие имени пользователя и TERMID. Это гарантирует, что данный пользователь может обращаться к системе только с определенного компьютера, так как при конфигурировании SNA-соединения на стороне сервера прописывается и MAC-адрес сетевой платы клиентского компьютера. Но web-соединения идут в обход VTAM и не имеют терминального устройства. Каким образом передавать TERMID или нечто, заменяющее его, чтобы минимизировать переделку транзакций?

Эта проблема была решена путем задействования пользовательской области терминала (Terminal Control Table User Area - TCTUA), нашей собственной транзакции 3270 первичной аутентификации пользователя и инициализации TCTUA, написанной на VisualAge Generator. Это привело к минимизации переделок в транзакции, которая свелась к замене слова?TERMID? на?TCTUA? в «кобольных» текстах.

Помимо этого, были проблемы с реализацией вызова последовательности 3270-транзакций в рамках одной 4GL-транзакции с промежуточной обработкой результатов: было необходимо обрабатывать и передавать параметры («экраны») для каждого вызова 3270.

Распределенная OLTP-система с интеграцией унаследованных программ

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

Компания Panasonic использует программу PSI для AS/400 и для Windows NT. При этом на AS/400 программа использовала в качестве структуры данных собственные таблицы и таблицы из ERP-системы J.D. Edwards, работающей на этом сервере. Сервер AS/400 находится в Хельсинки, а серверы NT - в Москве и Киеве, причем связаны между собой не очень надежными линиями. Между тем, логика работы программы PSI должна обеспечивать доставку информации к узлам через сервер AS/400. Существующая версия использовала механизм репликации баз данных, что в условиях плохих линий связи было неприемлемо.

Для решения этой проблемы была предложена модель транспортной системы между серверами на базе MQSeries. При этом не требовалось изменять код существующего приложения PSI, которое отвечало за взаимодействие с конечным пользователем, а предлагалось задействовать триггерные механизмы баз данных. Т. е., на необходимые таблицы «подсаживались» триггеры, которые для каждой операции (вставка, удаление, редактирование) посылали соответствующие сообщения в систему MQSeries. Эти сообщения, попав на AS/400, рассылались во все остальные узлы системы.

Это решение поддерживает использование нескольких баз данных (в среде NT) и библиотек (в среде AS/400) для возможности отладки или других целей. При этом при помощи специальных утилит можно назначить, откуда и куда будут передаваться данные для конкретной таблицы. Набор и структура таблиц в базе данных жестко заданы. Для реализации этого проекта были задействованы как MQSeries и VisualAge Generator, так и программирование на C++. На NT были реализованы триггерные мониторы MQSeries в виде служб NT, а на AS/400 - триггеры DB2.

В данном проекте, на первом этапе, каждая операция в базе порождала одно сообщение с соответствующим кодом операции (I - insert, D - delete, U - update), которое расшифровывалось на удаленных узлах. Но в реальности оказалось, что программа PSI изменяет ключевые поля, что вообще-то не рекомендуется. Это делает невозможным выполнение операции U («изменить») на удаленном узле, так как записи с измененным ключевым полем там еще не существует и СУБД не может ее найти. Вставить в структуру таблиц собственные ключевые поля было нельзя, так как использовались таблицы приложения J.D. Edwards, структуру которых менять нельзя. После анализа ситуации, с тем, чтобы решить проблему с минимальными переделками, было предложено вместо одного сообщения с кодом U соответствующий триггер стал посылать пару сообщений: первое - с кодом D («удалить») и старым значением ключа; второе - с кодом I («вставить») и новым значением ключа.

Эта система пропускает в сутки около 60 тыс. сообщений средней длины около 2 Кбайт. Проект был реализован за 8 недель силами 4 инженеров.

Литература

Masaharu Murozumi, A Challenge To A High Transaction Volume Client/Server DB2 Data Shared OLTP System. IBM, 2000

Г. Ладыженский, Технология «клиент-сервер» и мониторы транзакций. «Открытые системы», 1994, № 3

М. Рузинкевич, А. Цикоцки, Определение и выполнение потоков транзакций. «СУБД», 1995, № 2

E. Cobb, J. Hamilton, G. Sharman, Do I Need A Transaction Processing Monitor and a Database? IBM, 1996

Николай Игнатович, IBM MQSeries: архитектура системы очередей сообщений. «Открытые Системы», 1999, № 9-10

Николай Игнатович, Интеграция технологий управления данными в DB2. «Открытые системы», 2001, № 7-8

P. Wakelin, S. Day, S. Read, F. McKenna, CICS Transaction Gateway V3.1. The WebSphere Connector for CICS. SG24-6133-00, IBM, 2001

Илья Афанасьев ([email protected]) - генеральный директор компании «Диджитал Эмпайр», (Москва).

Основные типы программного обеспечения промежуточного слоя

Монитор распределенной обработки транзакций (distributed transaction processing monitor). Контроль выполнения интенсивного потока транзакций в системах оперативной обработки транзакций в многоплатформенной среде.
Удаленный вызов процедур (remote procedure call - RPC). Синхронизация взаимосвязи процессов, путем их удаленного вызова. Транзакционность не поддерживается.
Взаимосвязь баз данных (database connectivity). SQL-запрос, направленный через это программное обеспечение, может обработаться несколькими СУБД от разных производителей.
Обработчик объектных запросов (object request broker - ORB). Обмен программными объектами между различными платформами и по различным протоколам.

Все перечисленные выше типы ПО промежуточного слоя поддерживают только синхронный вид соединений; при обрыве соединения операция прекращается и автоматически не возобновляется.

ПО промежуточного слоя, основанное на передаче сообщений (message oriented middleware - MOM). Асинхронный обмен сообщениями между приложениями, которые могут выполняться на различных платформах. Обмен производится с гарантированной доставкой; при потере соединения операция будет автоматически возобновлена после восстановления.

Вопросы к госэкзамену

Жизненный цикл КИС. Этапы жизненного цикла КИС

Модели жизненного цикла КИС (бизнес-приложений)

Технологические процессы создания КИС

CASE-средства поддержки жизненного цикла КИС

Методы и средства структурного системного анализа и проектирования

Основные элементы системной архитектуры предприятия: бизнес-архитектура, архитектура информации, архитектура приложений, технологическая архитектура

Корпоративные информационные системы. Их структура. Примеры КИС

Информационная архитектура КИС. Назначение и состав. Методы и средства описания архитектуры данных

Инструментарий для проектирования, разработки и сопровождения информационной архитектуры предприятия

Архитектурные шаблоны (OLTP, OLAP – системы) в информационной архитектуре предприятия

OLAP-системы

OLAP (англ. online analytical processing, аналитическая обработка в реальном времени) - технология обработки данных, заключающаяся в подготовке суммарной (агрегированной) информации на основе больших массивов данных, структурированных по многомерному принципу. Реализации технологии OLAP являются компонентами программных решений класса Business Intelligence.

Основоположник термина OLAP - Эдгар Кодд, предложил в 1993 году «12 законов аналитической обработки в реальном времени».

Часто в компаниях существует несколько информационных систем – системы складского учета, бухгалтерские системы, ERP системы для автоматизации отдельных производственных процессов, системы сбора отчетности с подразделений компании, а также множество файлов, которые разбросаны по компьютерам сотрудников.

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

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

Преимущества OLAP-систем

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

Разработка каждого отчёта требует работы программиста.

Отчёты формируются очень медленно (зачастую несколько часов), замедляя при этом работу всей информационной системы.

Данные, получаемые от различных структурных элементов компании не унифицированы и часто противоречивы.

OLAP-системы, самой идеологией своего построения предназначены для анализа больших объёмов информации, позволяют преодолеть ограничения традиционных информационных систем.

Создание OLAP-системы на предприятии позволит:

Интегрировать данные различных информационных систем, создав единую версию правды

Проектировать новые отчеты несколькими щелчками мыши без участия программистов.

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

Производить мониторинг и прогнозирование ключевых показателей бизнеса

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

Итоги внедрения OLAP-системы

Руководство получает полное ясное видение ситуации и единый механизм учёта, контроля и анализа.

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

Действие OLAP

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

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

Например, все клиенты могут быть сгруппированы по городам или по регионам страны (Запад, Восток, Север и т. д.), таким образом, 50 городов, 8 регионов и 2 страны составят 3 уровня иерархии с 60 членами. Также клиенты могут быть объединены по отношению к продукции; если существуют 250 продуктов по 2 категориям, 3 группы продукции и 3 производственных подразделения, то количество агрегатов составит 16560. При добавлении измерений в схему, количество возможных вариантов быстро достигает десятков миллионов и более.

OLAP-куб содержит в себе базовые данные и информацию об измерениях (агрегатах). Куб потенциально содержит всю информацию, которая может потребоваться для ответов на любые запросы. Из-за громадного количества агрегатов, зачастую полный расчёт происходит только для некоторых измерений, для остальных же производится «по требованию».

Вместе с базовой концепцией существуют три типа OLAP:

OLAP со многими измерениями (Multidimensional OLAP - MOLAP);

реляционный OLAP (Relational OLAP - ROLAP);

гибридный OLAP (Hybrid OLAP - HOLAP).

MOLAP - это классическая форма OLAP, так что её часто называют просто OLAP. Она использует суммирующую БД, специальный вариант процессора пространственных БД и создаёт требуемую пространственную схему данных с сохранением как базовых данных, так и агрегатов.

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

HOLAP использует реляционные таблицы для хранения базовых данных и многомерные таблицы для агрегатов.

Особым случаем ROLAP является ROLAP реального времени (Real-time ROLAP - R-ROLAP). В отличие от ROLAP в R-ROLAP для хранения агрегатов не создаются дополнительные реляционные таблицы, а агрегаты рассчитываются в момент запроса. При этом многомерный запрос к OLAP-системе автоматически преобразуется в SQL-запрос к реляционным данным.

Каждый тип хранения имеет определённые преимущества, хотя есть разногласия в их оценке у разных производителей. MOLAP лучше всего подходит для небольших наборов данных, он быстро рассчитывает агрегаты и возвращает ответы, но при этом генерируются огромные объёмы данных. ROLAP оценивается как более масштабируемое решение, использующее к тому же наименьшее возможное пространство. При этом скорость обработки значительно снижается. HOLAP находится посреди этих двух подходов, он достаточно хорошо масштабируется и быстро обрабатывается. Архитектура R-ROLAP позволяет производить многомерный анализ OLTP-данных в режиме реального времени.

Сложность в применении OLAP состоит в создании запросов, выборе базовых данных и разработке схемы, в результате чего большинство современных продуктов OLAP поставляются вместе с огромным количеством предварительно настроенных запросов. Другая проблема - в базовых данных. Они должны быть полными и непротиворечивыми

Реализации OLAP

Исторически первой многомерной системой управления базами данных, по существу являющейся OLAP-реализацией считается система Express, разработанная в 1970 году компанией IRI (позднее права на продукт были приобретены корпорацией Oracle и превращён в OLAP-опцию для Oracle Database). Термин OLAP ввёл Эдгар Кодд в публикации в журнале Computerworld в 1993 году, в которой он предложил 12 принципов аналитической обработки, по аналогии с 12 правилами для реляционных баз данных, сформулированными им же десятилетием ранее, в качестве референтного продукта, удовлетворяющего предложенным принципам, Кодд указал систему Essbase компании Arbor (поглощённой в 1997 году компанией Hyperion, которую, в свою очередь, в 2007 году купила Oracle). Примечательно, что впоследствии публикация была изъята из архивов Computerworld из-за возможного конфликта интересов, так как Кодд позднее оказывал консультационные услуги для Arbor.

Другие известные OLAP-продукты: Microsoft Analysis Services (ранее называвшиеся OLAP Services, часть SQL Server), SAS OLAP Server, TM1, PowerPlay, SAP BW, MicroStrategy Ingelligence Server, Mondrian, Аналитический комплекс ПРОГНОЗ.

C точки зрения реализации делятся на «физический OLAP» и «виртуальный» (реляционный, англ. Relational OLAP, ROLAP). «Физический», в свою очередь, в зависимости от реализации подразделяется на многомерный (англ. Multidimensional OLAP, MOLAP) и гибридный - (англ. Hybrid OLAP, HOLAP).

В первом случае наличествует программа, на этапе предварительной загрузки данных в OLAP из источников выполняющая предварительный расчёт агрегатов (вычислений по нескольким исходным значениям, например «Итог за месяц»), которые затем сохраняются в специальную многомерную базу данных, обеспечивающую быстрое извлечение и экономичное хранение. Примеры таких продуктов - Microsoft Analysis Services, Oracle OLAP Option, Essbase, SAS OLAP Server, TM1, PowerPlay.

Hybrid OLAP является комбинацией. Сами данные хранятся в реляционной базе данных, а агрегаты - в многомерной.

В ROLAP-реализациях все данные хранятся и обрабатываются реляционных системах управления базами данных, а агрегаты могут не существовать вообще или создаваться по первому запросу в СУБД или кэше аналитического ПО. Примеры таких продуктов - SAP BW, Microstrategy Intelligence Server, Mondrian.

С точки зрения пользователя все варианты выглядят похожими по возможностям. Наибольшее применение OLAP находит в продуктах для финансового планирования, хранилищах данных, решениях класса Business Intelligence.

OL T P-системы (Системы оперативной обработки транзакций)

OLTP (Online Transaction Processing), транзакционная система - обработка транзакций в реальном времени. Способ организации БД, при котором система работает с небольшими по размерам транзакциями, но идущими большим потоком, и при этом клиенту требуется от системы минимальное время отклика.

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

Проблема целостности – в обеспечении правильности данных БД в любой момент времени. Она может быть нарушена в след случаях: 1. при вводе и обновлении, когда подаются неверные сведения. 2. когда данным пользуются одновременно несколько userов. 3. при сбоях АПС.

Решение проблем целостности надо рассматривать с программной и организационной точки зрения. Для ПОбл 1. надо ряд организац мероприятий (чтобы следили за вводом), user должен знать правила ввода и ограничения. Для проблем 2-3 – стандартные средства СУБД или спец программные модули. СУБД – 2 основных ограничения целостности: 1. структурные ограничения (задаются функциональными связями и проверяются путем проверки равенства значений БД) 2. ограничения реальных значений. Требуют, чтобы значения поля принадлежали некоторому диапазону, либо это зависимость между значениями некоторых полей. (типы данных и маски ввода). Ограничения могут задаваться АБД в любой момент, но СУБД может не принять ограничение (если много записей ему уже не удовлетворяют), если соответствие есть – записывается в словарь и используется. Ограничения различаются по уровню сложности:

2. ограничения на совокупность атрибутов строки. (должность – разрядные ставки, края – города).

3. ограничения одновременно на множество строк.

Все эти ограничения статистические, но при переходе БД из 1 состояния в другое необходимо удовлетворять ограничениям целостности до начала всех изменений и после окончания всех, а не каждого. Такие ограничения называются отложенными и относительно их вводится понятие транзакций. Транзакция – законченное с точки зрения userа действие над БД. В то же время, это логическая единица работы системы. Транзакция реализует некоторую прикладную функцию, например, перевод денег с одного счета на другой в банковской системе.

Должна обладать 4 свойствами: 1. Атомарность (неделимость): выполняется как одинарная операция доступа к БД, должна выполняться полностью или не выполняться совсем. 2. Согласованность – гарантирует взаимную целостность данных после окончания обработки транзакций. 3. Изолированность (каждая транзакция может изменять данное, которое временно находится в несогласованном состоянии). При этом доступ других транзакций к этим данным запрещен, пока транзакция не завершится. 4. долговечности – если транзакция выполнена успешно, то изменения не будут потеряны. Результатом выполнения транзакции может быть её фиксация (действие по фиксации изменений в БД) или откат (отмена транзакции и возврат БД в состояние до начала её). Механизм фиксации и откат основан на использовании журнала транзакций, где сохраняется состояние ДО (в нескольких итерациях) и ПОСЛЕ. Некоторые диалекты SQL включают операторы промежуточной фиксации (откат от точки к точке).

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

На современном рынке мониторов транзакций основными "действующими лицами" являются такие системы, как ACMS (DEC), CICS (IBM), TOP END (NCR), TUXEDO Sytem (Novell).

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

При реализации транзакций возникает проблема: потеря обновлений (в БД фиксируется только изменения одного userа, остальные теряются). И 2 проблема – чтение незафиксированных данных. Для решения - спец механизмы обработки транзакций. Принципы: 1. транзакция не имеет доступа к незафиксированным данным. 2. результат совместного выполнения транзакций эквивалентен их последнему выполнению. Реализуется этот механизм через систему блокировок: СУБД блокирует часть БД, к которой обращается транзакция до момента её фиксации, т.е. 2-ю транзакцию надо поставить в очередь ожидания. Чем больше блокируемый элемент, тем медленнее обрабатывается транзакция. В системах OLTP обычно блокируется строка, при этом транзакции могут попадать в ситуацию взаимной блокировки. Для предотвращения СУБД периодически опрашивает блокировки и если такое есть, одна из транзакций прерывается. Для более удобной работы допускаются блокировки совместного использования данных: параллельно работающим userам запрещается изменять данные, но разрешается выборка их. Этот подход не единственный, можно, например использовать тиражирование данных в системах с распред доступом. Эта технология предполагает отказ от распределенности данных, и в каждом узле – своя копия БД. Средства, обеспечивающие это должны поддерживать согласованное состояние БД копированием изменений. Процесс переноса изменений исходной БД в БД отдельных узлов называется тиражированием данных. Эти функции выполняет определенный модуль (сервер тираж-я/ репликатор). Схема его работы – полное обновление содержимого БД на удаленных серверах (схема с полн обновлением) или обновление только изменяющихся данных (схема с быстрым обновлением) Если нет необходимости постоянно обновлять данные, то репликатор накапливает изменения и копир-т их в нужный момент.

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

Современные технологии БД предъявляют определенные требования в области архитектуры. До недавнего времени выделялось три класса задач:

задачи оперативной обработки транзакций;

задачи пакетной обработки;

задачи принятия решений.

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

Системы OLTP характеризуются:

поддержкой большого числа users;

малым временем отклика на запрос;

относительно короткими запросами;

короткими транзакциями;

участие в запросах небольшого числа таблиц.

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

Сервер оперативной обработки транзакций строится в предположении:

OLTP- операции поддерживают большое число user;

наиболее часто используются короткие простые транзакции;

обычно транзакции не использую одинаковые данные;

операторы обычно затрагивают небольшое число строк;

время отклика - доли секунды;

только несколько таблиц имеют большие размеры или могут быть изменены.

Реализация такого сервера опирается на:

физические методики сокращений операций с дисками;

обработку небольших объемов данных в памяти;

примитивный оптимизатор запросов;

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

Хранилища данных и Data Mining

Data Mining переводится как "добыча" или "раскопка данных". Нередко рядом с Data Mining встречаются слова "обнаружение знаний в базах данных" (knowledge discovery in databases) и "интеллектуальный анализ данных". Их можно считать синонимами Data Mining. Возникновение всех указанных терминов связано с новым витком в развитии средств и методов обработки данных.

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

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

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

Специфика современных требований к такой переработке следующие:

Данные имеют неограниченный объем

Данные являются разнородными (количественными, качественными, текстовыми)

Результаты должны быть конкретны и понятны

Инструменты для обработки сырых данных должны быть просты в использовании

Традиционная математическая статистика, долгое время претендовавшая на роль основного инструмента анализа данных, откровенно спасовала перед лицом возникших проблем. Главная причина - концепция усреднения по выборке, приводящая к операциям над фиктивными величинами (типа средней температуры пациентов по больнице, средней высоты дома на улице, состоящей из дворцов и лачуг и т.п.). Методы математической статистики оказались полезными главным образом для проверки заранее сформулированных гипотез (verification-driven data mining) и для “грубого” разведочного анализа, составляющего основу оперативной аналитической обработки данных (online analytical processing, OLAP).

В основу современной технологии Data Mining (discovery-driven data mining) положена концепция шаблонов (паттернов), отражающих фрагменты многоаспектных взаимоотношений в данных. Эти шаблоны представляют собой закономерности, свойственные подвыборкам данных, которые могут быть компактно выражены в понятной человеку форме. Поиск шаблонов производится методами, не ограниченными рамками априорных предположений о структуре выборке и виде распределений значений анализируемых показателей. Примеры заданий на такой поиск при использовании Data Mining приведены в табл. 1.

Важное положение Data Mining - нетривиальность разыскиваемых шаблонов. Это означает, что найденные шаблоны должны отражать неочевидные, неожиданные (unexpected) регулярности в данных, составляющие так называемые скрытые знания (hidden knowledge). К обществу пришло понимание, что сырые данные (raw data) содержат глубинный пласт знаний, при грамотной раскопке которого могут быть обнаружены настоящие самородки (рис.1).

Рисунок 1. Уровни знаний, извлекаемых из данных

В целом технологию Data Mining достаточно точно определяет Григорий Пиатецкий-Шапиро - один из основателей этого направления:

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

2. Кому это нужно?

Сфера применения Data Mining ничем не ограничена - она везде, где имеются какие-либо данные. Но в первую очередь методы Data Mining сегодня, мягко говоря, заинтриговали коммерческие предприятия, развертывающие проекты на основе информационных хранилищ данных (Data Warehousing). Опыт многих таких предприятий показывает, что отдача от использования Data Mining может достигать 1000%. Например, известны сообщения об экономическом эффекте, в 10–70 раз превысившем первоначальные затраты от 350 до 750 тыс. дол. . Известны сведения о проекте в 20 млн. дол., который окупился всего за 4 месяца. Другой пример - годовая экономия 700 тыс. дол. за счет внедрения Data Mining в сети универсамов в Великобритании.

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

ИЛИ

Что такое Data Mining

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

Подобного рода информация обычно используется при прогнозировании, стратегическом планировании, анализе рисков, и ценность ее для предприятия очень высока. Видимо, поэтому процесс ее поиска и получил название Data Mining (mining по-английски означает «добыча полезных ископаемых», а поиск закономерностей в огромном наборе фактических данных действительно сродни этому). Термин Data Mining обозначает не столько конкретную технологию, сколько сам процесс поиска корреляций, тенденций, взаимосвязей и закономерностей посредством различных математических и статистических алгоритмов: кластеризации, создания субвыборок, регрессионного и корреляционного анализа. Цель этого поиска - представить данные в виде, четко отражающем бизнес-процессы, а также построить модель, при помощи которой можно прогнозировать процессы, критичные для планирования бизнеса (например, динамику спроса на те или иные товары или услуги либо зависимость их приобретения от каких-то характеристик потребителя).

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

В области информационных технологий существуют два взаимно дополняющих друг друга направления:

Технологии, ориентированные на оперативную (транзакционную) обработку данных. Эти технологии лежат в основе экономических информационных систем, предназначенных для оперативной обработки данных. Называются подобные системы - OLTP (online transaction processing) системы ;

Технологии, ориентированные на анализ данных и принятие решений. Эти технологии лежат в основе экономических информационных систем, предназначенных для анализа

накопленных данных. Называются подобные системы - OLAP

(online analytical processing) системы .

Основное назначение OLAP -систем - динамический многомерный

анализ исторических и текущих данных, стабильных во времени, анализ

тенденций, моделирование и прогнозирование будущего. Такие

системы, как правило, ориентированы на обработку произвольных,

заранее не регламентированных запросов. В качестве основных

характеристик этих систем можно отметить следующие:

Поддержка многомерного представления данных, равноправие всех измерений, независимость производительности от количества измерений;

Прозрачность для пользователя структуры, способов хранения и обработки данных;

Автоматическое отображение логической структуры данных во внешние системы;

Динамическая обработка разряженных матриц эффективным способом.

Термин OLAP является сравнительно новым и в разных литературных источниках трактуется иногда по разному. Этот термин часто отождествляют с поддержкой принятия решений (DSS (Decision Support Systems)- системы поддержки принятия решения. А в качестве синонима для последнего термина используют Data Warehousing -хранилища (склады) данных, понимая под этим набор организационных решений, программных и аппаратных сре дств дл я обеспечения аналитиков информацией на основе данных из систем обработки транзакций нижнего уровня и других источников

“Склады данных” позволяют обрабатывать данные, накопленные за длительные периоды времени. Эти данные являются разнородными (и не обязательно структурированными). Для “складов данных” присущ многомерный характер запросов. Огромные объемы данных, сложность структуры как данных, так и запросов требует использования специальных методов доступа к информации.

В других источниках понятие Системы Поддержки Принятия Решений (СППР) считается более широким. Хранилища данных и средства оперативной аналитической обработки могут служить одними из компонентов архитектуры СППР.

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

Иногда различают " OLAP в узком смысле" - это системы которые обеспечивают только выборку данных в различных разрезах, и " OLAP в широком смысле", или просто OLAP , включающей в себя:

Поддержку нескольких пользователей, редактирующих БД.

Функции моделирования, в том числе вычислительные механизмы получения производных результатов, а также агрегирования и объединения данных;

Прогнозирование, выявление тенденций и статистический анализ.

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

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

OLAP - системы можно разбить на три класса.

Наиболее сложными и дорогими из них являются основанные на патентованных технологиях серверы многомерных БД . Эти системы обеспечивают полный цикл OLAP -обработки и либо включают в себя, помимо серверного компонента, собственный интегрированный клиентский интерфейс, либо используют для анализа данных внешние программы работы с электронными таблицами. Продукты этого класса в наибольшей степени соответствуют условиям применения в рамках крупных информационных хранилищ. Для их обслуживания требуется целый штат сотрудников, занимающихся как установкой и сопровождением системы, так и формированием представлений данных для конечных пользователей. Обычно подобные пакеты довольно дороги. В качестве примеров продуктов этого класса можно привести систему Essbase корпорации Arbor Software , Express фирмы IRI (входящей теперь в состав Oracle), Lightship производства компании Pilot Software и др.

Следует отметить, что одним из способов обеспечения быстрой обработки данных при их анализе является организация данных в виде многомерных БД (MDD). Информация в MDD хранится не в виде индексированных записей в таблицах, а в форме логически упорядоченных массивов. Единой общепризнанной многомерной модели хранения данных не существует. В MDD отсутствует стандартизованный метод доступа к данным, и они могут отвечать требованиям специфической аналитической обработки данных.

Принимая во внимание все перечисленное, сравнение между различными MDD - продуктами можно проводить только по самым обобщенным категориям. В более дешевом секторе рынка присутствуют лишь однопользовательские и предназначенные для небольших локальных сетей средства просмотра многомерных данных. Хотя они обладают довольно высоким уровнем функциональных возможностей и удобны в использовании, эти системы ограниченны по своему масштабу. и им недостает средств, необходимых для реализации OLAP - обработки в широком смысле. В данную категорию попадают такие продукты, как PowerPlay корпорации Cognos , PaBlo фирмы Andyne и Mercury компании Business Objects . Дорогой же сектор рынка представлен системами Acumate ES фирмы Kenan Technologies , Express корпорации Oracle , Gentium компании Planning Sciences и Holos фирмы Holistic Systems . Они настолько разнятся по своим возможностям, что любую из них можно смело выделять в отдельную категорию. И наконец, MDD -системы в чистом виде: Essbase корпорации Arbor Software , LightShip Server фирмы Pilot Software и TM /1 компании Sinper [ N . Raden (Рынок программных средств)].

Второй класс OLAP -средств - реляционные OLAP -системы (ROLAP). Здесь для хранения данных используются старые реляционные СУБД, а между БД и клиентским интерфейсом организуется определяемый администратором системы слой метаданных. Через этот промежуточный слой клиентский компонент может взаимодействовать с реляционной БД как с многомерной. Подобно средствам первого класса, ROLAP -системы хорошо приспособлены для работы с крупными информационными хранилищами, требуют значительных затрат обслуживания специалистами информационных подразделений и предусматривают работу в многопользовательском режиме. Среди продуктов этого типа - IQ / Vision корпорации IQ Software , DSS / Server и DSS / Agent фирмы MicroStrategy и DecisionSuite компании Information Advantage .

ROLAP - средства реализуют функции поддержки принятия решений в надстройке над реляционным процессором БД.

Такие программные продукты должны отвечать ряду требований, в частности:

Иметь мощный оптимизированный для OLAP генератор SQL -выражений, позволяющий применять многопроходные SQL -операторы SELECT и/или коррелированные подзапросы;

Обладать достаточно развитыми средствами для проведения нетривиальной обработки, обеспечивающей ранжирование, сравнительный анализ и вычисление процентных соотношений в рамках класса;

Генерирвать SQL -выражения, оптимизированные для целевой реляционной СУБД, включая поддержку доступных в ней расширений этого языка;

Предоставлять механизмы описания модели данных с помощью метаданных и давать возможность использовать эти метаданные для построения запросов в реальном масштабе времени;

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

Третий, сравнительно новый тип OLAP -средств - инструменты генерации запросов и отчетов для настольных ПК , дополненные OLAP -функциями или интегрированные с внешними средствами, выполняющими такие функции. Эти весьма развитые системы осуществляют выборку данных из исходных источников, преобразуют их и помещают в динамическую многомерную БД, функционирующую на ПК конечного пользователя. Указанный подход, позволяющий обойтись как без дорогостоящего сервера многомерной БД, так и без сложного промежуточного слоя метаданных, необходимого для ROLAP - средств, обеспечивает в то же время достаточную эффективность анализа. Эти средства для настольных ПК лучше всего подходят для работы с небольшими, просто организованными БД. Потребность в квалифицированном обслуживании для них ниже, чем для других OLAP -систем, и примерно соответствует уровню обычных сред обработки запросов. В числе основных участников этого сектора рынка -к омпания Brio Technology со своей системой Brio Query Enterprise , Business Objects с одноименным продуктом и Cognos с PowerPlay .

В настоящее время увеличивается число Web -совместимых продуктов OLAP .

Важным является вопрос приспосабливания OLAP к остальному ПО. Хотя поставщики OLAP начинают предлагать некоторые способы взаимодействия с SQL -СУБД и другими инструментами, но однако, пользователи и аналитики предупреждают, что уровень интеграции может быть различным и, вероятно, потребует значительного объема кодирования, включая написание запросов на языке SQL . Более того, для интеграции OLAP с остальным программным обеспечением предприятия не существует промышленного стандарта.

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

OLTP - системы , являясь высокоэффективным средством реализации оперативной обработки, оказались мало пригодны для задач аналитической обработки. Это вызвано следующим:

1. средствами традиционных OLTP -систем можно построить аналитический отчет и даже прогноз любой сложности, но заранее регламентированный. Любой шаг в сторону, любое нерегламентированное требование конечного пользователя, как правило, требует знаний о структуре данных и достаточно высокой квалификации программиста;

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

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

Круг задач, эффективно решаемых каждой из систем, определим на основе сравнительных характеристик OLTP - и OLAP -систем (табл. 8).

OLTP и OLAP-системы. Data Mining

Можно выделить некоторые классы информационных систем, для которых больше подходят сильно или слабо нормализованные модели данных.

Сильно нормализованные модели данных хорошо подходят для так называемых OLTP-систем (On-Line Transaction Processing - оперативная обработка транзакций ).

Типичными примерами OLTP-систем являются системы складского учета, системы заказов билетов, банковские системы, выполняющие операции по переводу денег, и т.п. Основная функция подобных систем заключается в выполнении большого количества коротких транзакций . Механизм транзакций будет подробно рассмотрен лекции 16, для понимания принципов работы OLTP-систем достаточно представлять транзакцию как атомарное действие, изменяющее состояние базы данных.

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

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

База данных, с которой работают OLTP-приложения, постоянно обновляется, в связи с этим ее обычно называют оперативной БД. Чем выше уровень нормализации оперативной БД, тем быстрее и надежнее работают OLTP-приложения. Отступления от этого правила могут происходить тогда, когда уже на этапе разработки известны некоторые часто возникающие запросы, требующие соединения отношений и от скорости выполнения которых существенно зависит работа приложений. В этом случае можно сознательно внести некоторую избыточность в базу данных для ускорения выполнения подобных запросов.

Другим типом информационных систем являются так называемые OLAP-системы (On-Line Analitical Processing - оперативная аналитическая обработка данных ). OLAP используется для принятия управленческих решений, поэтому системы, использующие технологию OLAP, называют системами поддержки принятия решений (Decision Support System - DSS ).

Концепция OLAP была описана в 1993 году Эдгаром Коддом, автором реляционной модели данных.

В 1995 году на основе требований, изложенных Коддом, был сформулирован так называемый тест FASMI (Fast Analysis of Shared Multidimensional Information - быстрый анализ разделяемой многомерной информации), включающий следующие требования к приложениям для многомерного анализа:

· предоставление пользователю результатов анализа за приемлемое время (обычно не более 5 с), пусть даже ценой менее детального анализа;

· возможность осуществления любого логического и статистического анализа, характерного для данного приложения, и его сохранения в доступном для конечного пользователя виде;

· многопользовательский доступ к данным с поддержкой соответствующих механизмов блокировок и средств авторизованного доступа;

· многомерное концептуальное представление данных, включая полную поддержку для иерархий и множественных иерархий (это - ключевое требование OLAP);

· возможность обращаться к любой нужной информации независимо от ее объема и места хранения.

OLAP-приложения оперируют с большими массивами данных, уже накопленными в оперативных баз данных OLTP-систем, взятыми из электронных таблиц или из других источников данных. Такие системы характеризуются следующими признаками:

· Добавление в систему новых данных происходит относительно редко крупными блоками (например, раз в квартал загружаются данные по итогам квартальных продаж из OLTP-системы).

· Данные, добавленные в систему, обычно никогда не удаляются и не изменяются.

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

· Запросы к системе являются нерегламентированными и, как правило, достаточно сложными. Очень часто новый запрос формулируется аналитиком для уточнения результата, полученного в результате предыдущего запроса.

· Скорость выполнения запросов важна, но не критична.

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

В последнее время активно развивается еще одно направление аналитической обработки данных, получившее название Data Mining (осмысление данных, иногда говорят «раскопка данных» ). Это направление направлено на поиск скрытых закономерностей в данных и решение задач прогнозирования. Приложения DataMining также не изменяют данные, с которыми они работают, поэтому для них более предпочтительной является денормализованная база данных.

Для того, чтобы подчеркнуть особый способ организации данных, которые могут эффективно использоваться для анализа приложениями OLAP и Data Mining, к ним применяют специальный термин «хранилища данных» (DataWare House ). Важно отметить, что хранилища данных, в отличие от оперативной БД, хранят исторические данные, т.е. отражают те факты из деятельности предприятия, которые уже произошли, следовательно, могут храниться в неизменном виде («историю не переписывают») и накапливаться годами, в связи с чем их размеры могут стать весьма внушительными. После перекачки данных в хранилище они обычно удаляются из оперативной БД, что позволять поддерживать ее размеры в заданных пределах.

Принимая во внимание все перечисленное, сравнение между различными MDDпродуктами можно проводить только по самым обобщенным категориям. В более дешевом секторе рынка присутствуют лишь однопользовательские и предназначенные для небольших локальных сетей средства просмотра многомерных данных. Хотя они обладают довольно высоким уровнем функциональных возможностей и удобны в использовании, эти системы ограниченны по своему масштабу. и им недостает средств, необходимых для реализации OLAPобработки в широком смысле. В данную категорию попадают такие продукты, как PowerPlay корпорации Cognos, PaBlo фирмы Andyne и Mercury компании Business Objects. Дорогой же сектор рынка представлен системами Acumate ES фирмы Kenan Technologies, Express корпорации Oracle, Gentium компании Planning Sciences и Holos фирмы

Holistic Systems. Они настолько разнятся по своим возможностям, что любую из них можно смело выделять в отдельную категорию. И наконец, MDD-системы в чистом виде: Essbase корпорации Arbor Software, LightShip Server фирмы Pilot Software и TM/1 компании Sinper .

Второй класс OLAP-средств -реляционные OLAP-системы (ROLAP). Здесь для хранения данных используются старые реляционные СУБД, а между БД и клиентским интерфейсом организуется определяемый администратором системы слой метаданных. Через этот промежуточный слой клиентский компонент может взаимодействовать с реляционной БД как с многомерной. Подобно средствам первого класса, ROLAP-системы хорошо приспособлены для работы с крупными информационными хранилищами, требуют значительных затрат обслуживания специалистами информационных подразделений и предусматривают работу в многопользовательском режиме. Среди продуктов этого типа - IQ/Vision корпорации IQ Software, DSS/Server и DSS/Agent фирмы MicroStrategy и DecisionSuite компании Information Advantage.

ROLAP-средства реализуют функции поддержки принятия решений в надстройке над реляционным процессором БД.

Такие программные продукты должны отвечать ряду требований,

в частности:

- иметь мощный оптимизированный для OLAP генератор SQLвыражений, позволяющий применять многопроходные SQL-операторы SELECT и/или коррелированные подзапросы;

- обладать достаточно развитыми средствами для проведения нетривиальной обработки, обеспечивающей ранжирование, сравнительный анализ и вычисление процентных соотношений в рамках класса;

Генерирвать SQL-выражения, оптимизированные для целевой реляционной СУБД, включая поддержку доступных в ней расширений этого языка;

- предоставлять механизмы описания модели данных с помощью метаданных и давать возможность использовать эти метаданные для построения запросов в реальном масштабе времени;

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

Третий, сравнительно новый тип OLAP-средств -инструменты генерации запросов и отчетов для настольных ПК , дополненные

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

компания Brio Technology со своей системой Brio Query Enterprise, Business Objects с одноименным продуктом и Cognos с PowerPlay.

В настоящее время увеличивается число Web-совместимых продуктов OLAP.

Важным является вопрос приспосабливания OLAP к остальному ПО. Хотя поставщики OLAP начинают предлагать некоторые способы взаимодействия с SQL-СУБД и другими инструментами, но однако, пользователи и аналитики предупреждают, что уровень интеграции может быть различным и, вероятно, потребует значительного объема кодирования, включая написание запросов на языке SQL. Более того, для интеграции OLAP с остальным программным обеспечением предприятия не существует промышленного стандарта.

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

OLTP-системы , являясь высокоэффективным средством реализации оперативной обработки, оказались мало пригодны для задач аналитической обработки. Это вызвано следующим:

1. средствами традиционных OLTP-систем можно построить аналитический отчет и даже прогноз любой сложности, но заранее регламентированный. Любой шаг в сторону, любое нерегламентированное требование конечного пользователя, как правило, требует знаний о структуре данных и достаточно высокой квалификации программиста;

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

Таблица 8

Круг задач решаемых OLTP- и OLAP-системами

Характеристика
Частота обновления	Высокая частота,	Малая частота, большие "порции"
	небольшие "порции"
Источники данных	В основном, внутренние	По отношению к аналитической
		системе, в основном,

Возраст данных	Текущие (несколько	Исторически (за годы) и
		прогнозируемые
Уровень агрегации	Детализированные данные	В основном
		агрегированные данные
Возможности	Регламентированные	Последовательность
аналитических		интерактивных очетов,
операций		динамическое изменение уровней
		агрегаций и срезов данных
Назначение	Фиксация, оперативный	Работа с историческими
	поиск и обработка данных,	данными, аналитическая
	регламентированная	обработка, прогнозирование,
	аналитическая обработка	моделирование

			Таблица 9
	Сравнение OLTP и OLAP
характеристика
Преобладающие		Ввод данных, поиск	Анализ данных
операции
Характер запросов			Сложные транзакции
		транзакций
Хранимые данные		Оперативные,	охватывающие
		детализированные
			агрегированные
Вид деятельности		Оперативная,	Аналитическая,
		тактическая	стратегическая
Тип данных		Структурированные	Разнотипные

3.7. Подходы к выбору экономических информационных систем

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

1. Насколько технологии бизнеса в фирме отличаются от традиционных.

Если отличия весьма серьезны и пути изменения этих технологий в направлении стандартизации видятся неприемлемыми или чрезмерно затратными, покупка и адаптация готовой ЭИС российского производства либо неприменима вовсе, либо может оказаться

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

2. Как часто потребуется вносить значительные изменения во внедряемую информационную систему.

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

3. Какие суммы готова вложить фирма в автоматизацию.

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

Таким образом, покупку и адаптацию готовой ЭИС следует выбирать для фирм со стабильными и более или менее традиционными методиками ведения дел и в том случае, когда на рынке программного обеспечения есть соответствующие информационные системы.

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

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

Более подробный анализ достоинств и недостатков методов автоматизации представлен в таблице.

Таблица 10

Достоинства и недостатки методов автоматизации

Достоинства подхода

Недостатки подхода

Ориентация

российские

Проблема

инвестиций

адаптация

законы, "особенности" бизнеса,

первоначальные

готовой ЭИС

бухгалтерского учета

абсолютные

величины

российского

оказаться

невелики,

дальнейшие

производства

Доступность

разработчиков

обучение,

поддержки

обслуживание

развитие

сопровождения, что в варианте

информационной

с зарубежным продуктом либо

быть весьма значительными). В

имеет куда меньше масштабы,

условиях

нестабильности

обходится

экономики

несовершенства

дороже (возможно в десятки и

законодательства,

сотни раз). Рабочий день одного

гарантии

стабильности

квалифицированного

производителя

программного

специалиста

настройке

обеспечения (ПО) на протяжении

адаптации систем такого класса

всего срока эксплуатации ПО.

западная фирма вполне может

оценить очень дорого.

1.2.Покупка и

Наибольшим

начальные

адаптация

подобного

является

готовой ЭИС

огромная

мощность

Весьма значительные

затраты на

зарубежного

потенциал западных продуктов

внедрение

продукта,

обучение

производства

и комплексов автоматизации.

персонала и связанные с этим

Обычно они состоят из ряда

изменения

комплектуются

коснуться

аппаратного

зависимости

обеспечения фирмы.

потребителя (хотя существует и

В связи со многими чисто

целый ряд систем, которые по

российскими факторами (большая

причинам

динамичность

модульными

являются;

обстановки,

системам

свойственна

человеческого

большая закрытость и большая

другое) величина риска подобного

трудность

эксплуатации

рода вложений очень высока.

внедрении).

Основной

проблемой

является

необходимость

переориентации

технических

аспектов деятельности фирмы под

то, как это представляли себе

разработчики продукта, что в

наших условиях возможно очень

редко, даже если эти технологии

признаны

общепринятыми.

Отсутствие

некоторых

продуктах

типичных

российского

пользователя

компонент,

недостаточная

локализация

затруднить

значительно

эффективность его применения.

Стратегии

и критерии выбора

западной

информационной

достаточно

непросты,

главными из требований, которые

могут быть предъявлены системе

подобного

являются:

функциональная

открытость,

модульность,

масштабируемость, способность к

работе в распределенной среде,

настраиваемость

поставки в исходных текстах),

ценовая политика производителя

продукта и его представителей в

2.Разработка

Этот подход в большинстве

Большое (причем подчас трудно

случаев применим лишь в двух

прогнозируемое) время разработки

собственным

вариантах: для достаточно

и, во многих случаях, большая

крупной фирмы, способной

величина затрат.

квалифицированных

разработчиков ПО и в том

случае, если комплекс

автоматизации не очень велик и

может быть разработан

достаточно ограниченными

ресурсами.

Обычно этот вариант

автоматизации используется в

том случае, когда ни один из

существующих коммерческих

продуктов не удовлетворяет

руководство предприятия, либо

если бизнес настолько

динамичен, что перенастройка

готового продукта окажется

дороже или менее

эффективной, чем своего.

Достоинства:

ориентированный

конкретную фирму

комплекс

автоматизации,

покрывающий

требуемый

качество,

эффективность и оперативность

"поддержки" (никто не знает

всех особенностей бизнеса

фирме лучше

ее собственных

сотрудников).

3.Разработка

Этот вариант перекликается с

Однако тут возникают проблемы,

предыдущим, но отличается от

сходные первым вариантом

совместно с

него следующим: фирме не

автоматизации, но обычно этими

проблемами легче управлять из-за

разработчико

программистов с одной

более тесных контактов

стороны, и она получает

потребителя информационной

ориентированный чисто на нее

системы и фирмы-разработчика

продукт - с другой.

(или интегратора).

В случае наличия у фирмы-

разработчика технологического

"конструктора" (ядра

информационной системы,

достаточно легко развиваемого

и адаптируемого под

меняющиеся условия) такой

вариант автоматизации может

оказаться дешевле и

эффективнее второго подхода и

динамичнее и технологичнее

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

Внедрение качественной ЭИС является одним из важнейших элементов рыночного успеха предприятия и условием ее динамичного развития.

3.8. Критерии выбора ЭИС

При выборе ЭИС необходимо учитывать следующие критерии:

репутация фирмы, репутация системы, стаж пребывания фирмы на рынке, число продаж.

сколько работающих систем в России. Имеются ли внедрения на родственных предприятиях? Потребовалась ли помощь внешних консультантов?

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

качество локализации западной системы. Есть области производства, где действуют стандарты - юридические и фактические. Например - методы бухгалтерского учета, бухгалтерская и налоговая отчетность. В конструкторской и технологической подготовке производства у отечественных предприятий повсеместно приняты стандарты ЕСКД и ЕСТД. На западных предприятиях принята предметно замкнутая организация производства, а для отечественных - более привычна технологическая специализация. На западе безцеховая структура управления, в России - цеховая. Все эти моменты должны быть отработаны при локализации. Желательно, чтобы система отрабатывала такие российские реалии как бартер, цепочки зачетов, предоплату, оплата в неденежной форме, неотфактурованные поставки и т.д.

какая российская команда стоит за западной системой. Кто ее русифицировал, кто внедряет? Знают ли они производство? Какое у них образование? Какой опыт? Какая за ними “история успехов”? Какой их подход к внедрению?

разумная цена . Покупая систему, необходимо помнить, что на весь цикл - покупка, внедрение, сопровождение, развитие - придется затратить в 3 - 10 раз больше денег, чем стоимость программных средств. Чем сложнее и дороже система, тем больше коэффициент. Если придется привлекать западных консультантов, это будет стоить минимум в 1000 $ в день, причем заранее неясно, то ли они будут учить работать с их системой, то ли сотрудники предприятия за эти деньги будут их знакомить с волнующими особенностями российской экономики,

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

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

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

архитектура. Желательна трехзвенная - сервер базы данных, сервер приложений, клиент - клиент-серверная архитектура с возможностью использования “тупых терминалов”. Клиент может быть “толстым” или “тонким”,

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