Создание клиентских частей SQL БД под ОС Windows'95 и WindowsNT

| Категория реферата: Рефераты по информатике, программированию
| Теги реферата: план реферата, дипломная работа формирование
| Добавил(а) на сайт: Jazykov.

Фирма IBM является крупнейшей фирмой в мире, занимающейся компьютерной техникой и информационными технологиями. Среди многочисленных аппаратных и программных решений, предлагаемых IBM, весьма почетное место всегда занимали компоненты для сохранения и использования данных. Семейство DB2 систем управления реляционными базами данных является ключевым программным компонентом, предлагаемым фирмой IBM для хранения и интенсивного использования больших объемов данных.
Прикладные системы, для которых используется DB2, - это стандартные OLTP
(on-line transaction processing) системы. Кроме того, DB2 широко применяется для информационных систем различного назначения, для построения информационных хранилищ данных и для систем поддержки принятия решений.
Еще некоторое время назад IBM рассматривала DB2, в первую очередь, как необходимое средство поддержки для аппаратных платформ, производимых и продаваемых IBM (DB2 для MVS, VM, VSE, AIX, OS/400, OS/2), и не выпускала
DB2 для серверных операционных систем других фирм. Бурное развитие программного рынка в последние годы дало жизнь версиям DB2 для разнообразных вариантов ОС Unix и Windows NT.
Появление работы E. Кодда в 1970 г. с предложением реляционного подхода для создания баз данных положило начало исследовательской активности в области реляционных баз данных в ряде лабораторий IBM. Первые проекты и прототипы были консолидированы в лаборатории Санта-Тереза, Калифорния в середине семидесятых годов и завершились созданием System R. Эта система во многом определила архитектуру современных реляционных баз данных, в частности использование непроцедурного языка запросов SQL. После исследовательской стадии, в 1981 г. появился коммерческий продукт SQL/DS для VM, а в 1983 г. - собственно DB2 для мэйнфреймов под MVS и MVS/ESA.
Другим интересным проектом, влияние которого ощутимо в DB2, был Starburst на рубеже 80-90-x.
Многочисленные современные проекты, ведущиеся в настоящее время вокруг семейства DB2 в Альмадене, Санта-Тереза и Торонто позволяют судить о том, в каких направлениях видят развитие баз данных разработчики DB2.
Значительная часть ведущихся проектов касается расширения сферы применения реляционных баз данных для новых задач, связанных с хранением и использованием новых сложных типов данных, поддержки объектно- ориентированных расширений и реализаций новых методов поиска и анализа данных. Другая часть исследований касается вопросов повышения производительности и масштабируемости, использования методов распараллеливания в работе серверов баз данных. Часть результатов этих проектов уже воплотилась в текущей версии DB2, другие проекты должны получить развитие в следующей DB2 Universal Server (DB2 версия 5, согласно новой унифицированной нумерации).
Программные решения IBM, наряду с DB2, включают и другие программные средства, например: транзакционные продукты CICS, Encina, MQSeries, которые вместе с DB2 могут образовывать более гибкую и подходящую для конкретного случая архитектуру, чем основанное только на использовании СУБД решение.
Продукты семейства DB2. DB2 Parallel Edition ориентирована на технологию распараллеливания запросов к очень большим базам данных (VLDB), размещенным на системах с массовым параллелизмом (MPP). Серверы из семейства DB2 Common
Server представляют общее решение для рабочих групп, малых и средних организаций, переносимое и масштабируемое на серверах, работающих под управлением OS/2, Windows NT, AIX, HP-UX, Sun Solaris, SCO, SINIX.
Существуют также более специализированные серверные продукты типа
DataJoiner, который предоставляет клиентам-приложениям оптимизированный доступ к распределенным данным, управляемым Oracle, Sybase, MS SQL Server,
DB2, и предлагает единую базу-образ гетерогенной среды.
Поддержка существующих международных отраслевых стандартов, таких как SQL
92 Entry Level, ODBC, XA, JDBC, новых версий SQL и корпоративных стандартов фирмы IBM, является необходимым качеством семейства DB2, обеспечивающим взаимодействие разнообразных программных и аппаратных средств.
Вокруг базовой группы продуктов существует разнообразная инфраструктура комплектующих и дополнительных продуктов, предназначенных для администрирования баз данных – DataHub и компоненты Tivoli, для репликации данных - DataPropagator, семейство средств разработки VisualAge для различных языков программирования (С++, Smalltalk, 4GL, Java, Basic) с CASE- средствами IBM DataAtlas и VisualAge PackBase, пакеты средств формирования запросов и создания отчетов Intelligent Decision Server и QMF, комплексное решение для построения локальных информационных хранилищ данных - Visual
Warehouse, средства анализа и поиска информации в базах данных Intelligent
Miner, средство для работы с метаданными и построения каталога информационных ресурсов DataGuide, решения для поддержки OLAP-приложений -
DB2 OLAP Server and IDS, и так далее.
DB2 как сервер поддержки OLTP. На сегодняшний момент большинство реляционных баз данных занято хранением операционных данных, полученных от
OLTP (OnLine Transaction Processing) приложений. Такие приложения предназначены для поддержки текущей деловой активности финансовых, административных и промышленных организаций, где данные, в основном, числовые и символьные.
OLTP-приложения оперируют с критически-важными данными, которые требуют защиты от несанкционированного доступа, от нарушений целостности, от аппаратных и программных сбоев. Типичной является ситуация, когда система должна поддерживать быстрый доступ к данным большого числа пользователей, выполняющих относительно несложные запросы на поиск и обновление данных.
Критическим показателем для OLTP является время ожидания выполнения типичных запросов, которое не должно превышать нескольких секунд.
В условиях постоянного роста объема хранимых данных, необходимым требованием к DB2 становится возможность масштабировать систему при увеличении объемов данных, при увеличении потока транзакций и количества пользователей, в первую очередь, путем наращивания аппаратных ресурсов, при сохранении времени отклика системы в допустимых пределах.
До появления реляционных СУБД задачи поддержки OLTP решались с использованием дополнительного программного обеспечения - мониторов транзакций, например CICS. Однако практика внедрения архитектуры клиент- сервер без применения промежуточного монитора транзакций потребовала универсализации сервера баз данных и оснащения его некоторыми свойствами мониторов транзакций для внешнего взаимодействия и повышения производительности.
Наглядными примерами тенденции преобразования многих СУБД и, в частности,
DB2 в легкие мониторы транзакций могут служить появившиеся у СУБД функции поддержки хранимых процедур и компонентов для координации изменений в распределенной базе данных.
DB2 для OS/390 как корпоративный сервер. DB2 для мэйнфреймов появилась в эпоху вычислительных центров и с самого своего появления была ориентирована на поддержку очень крупных централизованных систем, для которых главными требованиями являлись производительность и очень высокая надежность.
DB2 предназначалась для взаимодействия с приложениями, работающими под
MVS-TSO, транзакционными продуктами CICS, IMS, и поддержки пакетной обработки больших объемов данных. Последующие версии DB2 стали поддерживать архитектуру клиент-сервер.
Более высокая надежность платформы OS/390 по сравнению с вычислительными системами других типов вместе с развитием и удешевлением технологий хранения данных и высокопроизводительных коммуникаций определяет использование DB2 для OS/390 как корпоративного сервера баз данных и центра массивной обработки данных.
Для DB2/390 основными тенденциями развития являются, с одной стороны, стремление к наращиванию производительности, что связано с тенденцией физического роста корпоративных баз данных, а с другой стороны, укрепление интеграции с прочими программными средствами на различных платформах.
DB2 для MVS версии 3, появившаяся в 1992 году, обладала серьезными улучшениями в области производительности, на основе распараллеливания операций ввода/вывода и работы с независимыми разделами дисковых устройств, использования возможностей аппаратного обеспечения и операционной системы, например методов компрессии данных и аппаратной поддержки сортировки.
В DB2 для MVS версии 4 важные добавления были сделаны в поддержку архитектуры клиент-сервер, использования DB2 в масштабируемой архитектуре
Parallel Sysplex, возможности распараллеленного исполнения запросов.
Появились также хранимые процедуры как важное средство снижения сетевого трафика и перенесения бизнес-логики приложений на сервер баз данных. Также увеличились возможности DB2 по поддержке клиентов до 25 тысяч на один сервер, а с учетом возможности параллельной работы в группе до 32 узлов DB2 в Parallel Sysplex - до 800 тысяч клиентов.
Для архитектуры клиент-сервер наиболее важные улучшения связаны с поддержкой клиентов в сетях TCP/IP, хранения данных в ASCII-форматах, более развитых механизмов хранимых процедур, стандартизацией DB2 SQL и появлением продукта DB2 WWW Connection для доступа к данным из Internet.
Архитектура DRDA. При изначальной ориентации DB2 на платформах MVS, VM,
VSE на централизованные приложения впоследствии, в условиях распространения архитектуры клиент-сервер, потребовалась дополнительная поддержка удаленного доступа для PC- и Unix-рабочих станций к базам данных на мэйнфреймах и на системах типа AS/400.
Решая проблему поддержки архитектуры клиент-сервер, IBM предложила архитектуру DRDA (Distributed Relational Database Architecture) в виде открытой спецификации, описывающей протоколы взаимодействия удаленного клиента с базами данных. Реализация DRDA должна была позволить продуктам от разных производителей баз данных прозрачно взаимодействовать и, в частности, образовывать единую распределенную базу данных.
Подход DRDA позволяет решить многочисленные проблемы кросс-платформенного взаимодействия, в частности конвертацию ASCII- и EBCDIC-данных, различия в диалектах SQL, командах, типах данных, строении каталогов. В настоящее время архитектуру DRDA поддерживают прежде всего все серверы семейства DB2; остальные производители реализовали продукты типа DRDA-реквесторов, которые позволяют прикладным программам-клиентам иметь доступ к базам DB2, например к DB2/390.
Типичный пример такого DRDA-реквестора производства IBM - продукт DDСS, работающий на OS/2, AIX, Windows, Windows NT, служащий многопользовательским шлюзом к DB2 для пользователей локальной сети или, в случае однопользовательского варианта, работающий на компьютере клиента.
Реализация поддержки DRDA по протоколам TCP/IP, в добавление к традиционной поддержке протоколов SNA, в новых версиях серверов DB2 и шлюзов DDCS значительно упрощает многочисленным пользователям доступ к базам данных DB2 на мэйнфреймах и AS/400.
DB2 Common Server. Эксплуатация реляционных баз данных поставила перед разработчиками практические задачи по дополнению СУБД новыми возможностями и привела к появлению нового поколения систем управления базами данных, так называемых расширенных реляционных (extended relational) СУБД. К этому классу относят системы управления базами данных, поддерживающие ряд дополнительных возможностей, которые выходят за рамки реляционной алгебры,
- триггеры, хранимые процедуры, контроль целостности и т. д.
На сегодняшний день практически все системы управления реляционными базами данных ведущих производителей, в том числе DB2, можно отнести к категории расширенных.
Целью проекта IBM Starburst в конце восьмидесятых годов было создание такой расширяемой системы управления реляционными базами данных.
Практическим результатом проекта Starburst и его продолжения проекта
Starwings было появление семейства DB2 Common Server в 1993 г.
Для поддержки OLTP-приложений в DB2 Common Server реализовано большое число механизмов, улучшающих производительность, включая разнообразные алгоритмы буферизации, алгоритмы контроля ресурсов и методы мониторинга, конфигурации и настройки параметров системы, использующие статистику системы.
Система управления буферизацией использует алгоритмы распараллеливания операций ввода/вывода, предварительного чтения данных и индексов, асинхронной записи на диск и многие другие. DB2 Performance Monitor, поставляемый вместе с DB2, предоставляет широкие возможности для сбора и анализа данных о производительности системы, включая информацию о событиях и периодические срезы параметров производительности.
Оптимизатор DB2 является одним из наиболее важных компонентов, обеспечивающих DB2 высокую производительность и адаптацию к различным задачам. DB2 строит так называемую QGM (Query Graph Model) для внутреннего представления запросов и использует ее на этапах проверки семантики запросов, преобразования запросов к оптимальному виду и построения плана исполнения запроса. Расширяемость QGM позволяет легко добавлять к SQL DB2 новые конструкции.
При анализе плана исполнения запроса оптимизатор, используя статистику каталогов и параметры аппаратной части, оценивает эффективность того или иного плана исполнения запроса и выбирает наилучший. Один из административных компонентов DB2, Visual Explain, позволяет наглядно представить выбранный план исполнения запроса и даже оценить его эффективность при изменении параметров системы.
Объектно-реляционные свойства DB2. В настоящее время существует множество приложений, оперирующих с данными, которые имеют гораздо более сложную и чаще изменяемую структуру, чем традиционно используемая в реляционных базах данных. Стремительно растет число мультимедийных приложений. Кроме того, актуальна более гибкая поддержка серверами баз данных бизнес-логики приложений.
DB2 Common Server, появившаяся в 1995 году, уже содержит инфраструктуру для реализации объектно-ориентированных функций, на основании которой построены реляционные расширения DB2 (relational extenders). Расширения позволяют определять структуру, атрибуты и поведение новых типов данных, сохранять эти данные в таблицах DB2 и затем использовать их в SQL- выражениях. В общем случае при создании новых типов данных используется UDT
(User Defined Type - определяемые пользователем типы данных) DB2, часто основанные на применении больших объектов DB2, поведение новых типов данных определяется с помощью нескольких UDF (User Defined Function - определяемая пользователем функция). При этом механизмы триггеров (triggers) и ограничений (constrains), предлагаемые DB2, оснащающие базу данных возможностями хранить правила поведения данных, могут использоваться для управления внутренней структурой новых сложных типов данных.
Подобно некоторым другим базам данных, DB2 Common Server позволяет хранить данные в больших бинарных (BLOB) и символьных (CLOB) объектах.
Размер объекта может достигать 2 Гбайт.
Поскольку размер таких объектов сильно отличается от традиционных данных, на обработку которых настроены серверы реляционных баз данных, то DB2 содержат ряд функций помогающих обеспечить нормальную производительность: переменные типа локаторов, ссылки, специальные режимы при журналировании.
Кроме того, IBM предлагает специализированные программные и аппаратные решения, такие как Digital Library, ориентированные на хранение и высокопроизводительную обработку мультимедийных данных и на взаимодействие с DB2.
Постоянно растущие объемы текущих операционных данных представляют собой значительную ценность для решения разнообразных задач управления, поскольку являются объективным отражением происходящих деловых процессов.
На сегодняшний день задача построения информационных хранилищ представляет весьма сложный комплекс проблем и решений, касающихся пополнения хранилищ информацией, трансформации, хранения, представления и использования информации. Причем важнейшую роль в этом комплексе играют весьма сложные инструментальные средства. Качественное изменение характера данных в информационных хранилищах и изменение характера работ, производимых над базой данных, требуют определенных технологических изменений в ядре самой СУБД, в частности поддержания новых методов хранения и размещения данных и новых методов поиска.
DB2 кроме естественной роли быть источником операционных данных для пополнения хранилищ обеспечивает хранение самих информационных данных и эффективное выполнение сложных запросов, включающих многочисленные соединения таблиц, вычисления и методы группировки данных. В частности, уже сейчас оптимизатор DB2 Common Server поддерживает оптимизацию запросов к базам данных, смоделированным по принципу звезды (Star Schema), широко используемым для OLAP (Online Analytical Processing) приложений и состоящим из большой таблицы фактов и нескольких таблиц размерностей.
Для поддержки очень больших баз данных объемом в сотни гигабайт и даже терабайт семейство DB2 предлагает два решения, основанные на технологиях распараллеливания - DB2/390 в Parallel Sysplex (архитектура Data Sharing) и
DB2 Parallel Edition.
Архитектура DataSharing позволяет масштабировать решения путем подключения дополнительных серверов и при увеличении объемов данных, и при увеличении количества и сложности запросов. При выполнении сложных запросов поддерживается техника разделения запроса на отдельные задачи и выполнение этих задач параллельно несколькими серверами DB2, входящими в Sysplex.
DB2 Parallel Edition создана на основе DB2 для RS/6000 и предназначена для поддержки приложений, требующих выполнения сложных запросов к большим массивам данных. DB2 Parallel Edition использует технологию Sharing
Nothing, позволяющею почти линейно масштабировать систему до сотен и даже тысяч параллельно работающих узлов.
DB2 Parallel Edition разработана для работы на различной аппаратной архитектуре, на системах POWERparallel SP2, на комплексах HACMP/6000 и группе рабочих станций RISC/6000, связанных локальной сетью.
Данные любой базы данных распределяются между несколькими узлами DB2
Parallel Edition с использованием схемы хеширования. При этом алгоритмы распределения данных обеспечивают сбалансированность работы между узлами, позволяющую избежать перегрузки одних узлов и простоя других, и минимизирование передачи данных между узлам во время исполнения запросов, например.
IBM предлагает набор продуктов для репликации данных между серверами семейства DB2, а также между DB2 и базами данных других производителей.
Решение от IBM DataReplication состоит из двух типов компонентов Capture и
Apply для всех платформ, где функционирует DB2. Компоненты Capture предназначены для выборки из базы данных источника измененных данных и организации таблиц для промежуточного хранения и обработки реплицируемых данных. Компоненты Apply ответственны за передачу реплицируемых данных между серверами баз данных и добавление их в целевые таблицы.
Сложность построения хранилища данных, охватывающего все источники данных большой корпорации или предприятия, заставляет иногда предпочесть локальные и более дешевые варианты внедрения небольших информационных хранилищ для отдельного подразделения или конкретной предметной области. Продукт IBM
Visual Warehouse использует в качестве основы административной базы данных для хранилища DB2 для OS/2 или Windows NT и серверы из семейства DB2 для самого хранилища.
Компоненты собственно Visual Warehouse обеспечивают процесс преобразования данных из баз данных DB2, Oracle, Informix, Sybase, ODBC - источников в информационные данные, и организуют семантически значимые представления (business view) для разнообразных аналитических, статистических и отчетных приложений клиентов. Другой важнейшей функцией, которую выполняют административные компоненты Visual Warehouse, является автоматизация непрерывных процессов создания и управления хранилища.
Продукт IBM Intelligent Miner представляет собой интегрированное средство для сложного анализа данных, хранящихся в реляционных базах данных и файлах. Он позволяет добывать из баз данных ранее неизвестную и содержательную информацию, предоставлять ее для анализа и принятия решений.
Набор API для приложений-клиентов позволяет разработчикам создавать свои собственные приложения, использующие алгоритмы Intel-ligent Miner. Для конечных пользователей Intelligent Miner имеет функцию подготовки данных к поиску и представления найденной информации в графическом виде. Серверные компоненты Intelligent Miner функционируют в настоящее время под AIX,
OS/390, OS/400.
По сравнению с многочисленными средствами создания отчетов и запросов для персональных компьютеров и рабочих станций, аналогичных средств для хост- систем не так много. В своем составе QMF (Query Management Facility для
DB2/390) имеет средство формирования запросов, редактор таблиц, средство составления отчетов и обеспечивает интерфейсы для поддержки приложений. QMF поддерживает несколько методов формирования интерактивных запросов.
Результаты запроса могут быть выведены на экран в самых разных форматах, включая табличный, матричный, свободный и графический. QMF является достаточно мощным продуктом, даже с точки зрения специалистов в области обработки данных. Последние версии QMF поддерживают работу в среде рабочих станций, а также содержат ряд усовершенствований для среды мэйнфреймов.
Клиентский компонент QMF для работы в среде Windows, который известен под названием Shuttle, дает пользователям возможность выполнять запросы QMF к центральному хост-компьютеру и выводить результат на экран рабочей станции для встраивания в другие программные продукты для рабочих станций, например в электронные таблицы Lotus 1-2-3 или Microsoft Excel.
Стремительное развитие Internet и рост популярности WWW, наблюдаемые в настоящее время, открывают новые возможности использования баз данных.
С одной стороны, многое обещает организация доступа огромного числа пользователей Internet к коммерческим OLTP-системам. Распространение intranet как технологии для корпораций делает эту задачу еще более актуальной.
С другой стороны, перспективным является построение новых Web-серверов с использованием мультимедиа. Применение баз данных позволяет создавать информационные узлы, сочетающие возможности эффективного поиска, обеспечиваемого реляционными базами данных с наглядным представлением информации и удобным к ней доступом, предоставляемыми Internet. При этом требуется не только статическое хранение Web-страниц, но и динамическая их генерация с использованием реляционных данных.
Использование в Internet потребовало создания определенных дополнений для
DB2, таких как поддержка JDBС, приложений, хранимых процедур и UDF, написанных на Java, и дополнительных программных средств для взаимодействия с серверами Internet, такими как DB2 WWW Connection и являющимся его развитием Net Data.

1.1.3 RDMS Oracle

Компания Oracle проникла на российский рынок более десяти лет назад, и продукция этой фирмы хорошо известна. В 1979 г. небольшая компания Silicon
Valley разработала Oracle - первую коммерческую реляционную базу данных с языком доступа к данным SQL. Первой СУБД клиент/сервер стал выпущенный в
1985 г. Oracle5. До недавнего времени, Oracle7 была последней версией сервера базы данных Oracle, появившейся в 1992 г. В прошлом году фирма выпустила новую версию Oracle8. К сожалению, пока еще очень мало литературы по новой версии, так что придется рассматривать технологию уже не самую
"горячую". С другой стороны практически все направления развития серверной технологии, получившие отражение в Oracle8, в той или иной степени уже заложены в Oracle7.3.
Oracle7 это реляционная СУБД и семейство продуктов, обеспечивающих создание автоматизированных и информационных систем различного назначения.
В состав семейства входят: СУБД Oracle7 RDBMS, средства проектирования приложений CDE CASE (Designer/2000), средства разработки приложений CDE
Tools (Developer/2000), средства конечного пользователя, средства интерфейса с программными продуктами третьих фирм, коммуникационные средства и т.д.
Общие функциональные возможности. Версия 7.3 сервера Oracle содержит ряд функциональных новшеств, направленных как на расширение возможностей разработчиков приложений, так и на развитие возможностей самой системы по обслуживанию большого числа одновременных пользователей. Обусловлено это целым рядом архитектурных решений, и не в последнюю очередь хорошо выверенным механизмом блокировок. Oracle устроен так, что разработчик приложений может не заботиться об эффектах многопользовательского режима работы. Сервер сам обеспечивает все необходимые блокировки (хотя позволяет выпонять их и "вручную"), причем осуществляет их всегда на минимально возможном уровне: скажем при изменении записи только эта запись и будет заблокирована от изменений другими пользователями (до завершения транзакции). В Oracle необходимость обеспечения блокировок учитывается уже в организации хранения данных, а сам этот механизм является неотъемлемой частью ядра сервера, "переплетаясь" со всеми его внутренними алгоритмами.

И все-таки, проблема блокировки (моды изоляции чтения) продолжает существовать (пока один пользователь читает данные, другой пользователь может эти данные изменять). Стандарт ANSI SQL-92 описывает требования к реализации нескольких мод изоляции операций чтения от выполняющихся одновременно с ним транзакций. Они варьируются от самой "слабой" моды -
"незафиксированного" (часто называемого "грязного") чтения, при котором допускается считывание данных незафиксированных транзакций, до самой
"сильной" - "повторяемого" чтения, при котором гарантируется повторяемость результата при повторении операции в рамках транзакции. Беда в том, что само наличие всех этих различных мод изоляции в стандарте SQL отражает отнюдь не потребности пользователей, а различные степени компромисса с возможностями разработчиков СУБД. Пользователей же волнует совсем другое: как избежать тех неприятных эффектов, которые могут быть связаны с использованием всех стандарных мод изоляции, кроме самой "сильной" из них.
Сущность моды изоляции "согласованное чтение", реализуемой сервером
Oracle состоит в том, что любая операция чтения в Oracle выдает пользователю данные только тех транзакций, которые были завершены к моменту начала операции. Oracle реализует "согласованное чтение" без использования блокировок вообще. Операция чтения в Oracle никогда не блокируется и никогда не блокирует других. Данный режим работы является среди коммерческих СУБД уникальным. Мода "согласованного чтения" не совпадает ни с одной из мод изоляции, принятых в стандарте SQL-92. Она "сильнее" (и следовательно покрывает) все моды, кроме "повторяемого чтения", но она
"слабее" последней. Действительно, при повторе операции в моде
"согласованного чтения" можно получить совсем другой результат, ибо изменится момент времени, по которому синхронизуется "срез" данных. Oracle, правда, предоставляет возможность объединять несколько операций чтения в read-only транзакцию, синхронизуя их при этом к одному моменту времени. В версии 7.3 Oracle позволяет в явном виде установить моду изоляции
"repeatable read", причем опять без использования блокировок.
Функциональные новшества. В Oracle 7.3 появилась возможность читать и писать поля таблиц типа Long по частям (на уровне Oracle Call Interface), что безусловно полезно, ибо размер таких полей может доходить до 2 Гбайт.
Расширился набор типов представлений (views), для которых допускается их непосредственная модификация. Появился ряд новшеств в языке PL/SQL
(процедурном расширении SQL), самое заметное из которых - поддержка таблиц, хранимых в памяти сервера. Новые алгоритмы обработки запросов. Выполнение
SQL-запроса - особенно имеющего сложную структуру - обычно распадается на несколько взаимосвязанных операций. Само это разбиение, а тем более выбор методов выполнения операций, как правило, допускают множество альтернативных решений. Выбор оптимальной их комбинации - задача оптимизатора, который на основании как характера запроса, так и имеющейся информации о задействованных таблицах и индексах, наличии тех или иных системных ресурсов (в Oracle 7.3 расширен набор видов предоставляемой оптимизатору информации: теперь он может учитывать частотные гистограммы индексируемых полей) строит оценку стоимости разных вариантов решения.
Помимо "джентльменского" набора более или менее универсальных методов существует также целый ряд более узкоспециализированных, т. е. таких, которые очень хорошо работают в некоторых ситуациях, но могут быть совсем неэффективными (или даже неприменимыми) в других. Несмотря на такой недостаток, применение этих методов может дать очень заметный эффект, особенно при выполнении сложных запросов над большими объемами данных, что характерно для систем поддержки принятия решений (DSS) (хранилищ данных). В
Oracle 7.3 введен целый ряд таких специализированных алгоритмов.
• "Звездообразные запросы" (star queries). В DSS-системах довольно часто применяются запросы, выполняющие соединение одной большой таблицы (таблицы фактов) с несколькими маленькими (справочными таблицами). При выполнении подобных запросов оказывается эффективным достаточно экзотический алгоритм, выполняющий сначала вычисление декартова произведения справочных таблиц, а затем слияние сортировкой полученного результата с таблицей фактов.
• "Слияние хэшированием". Альтернативный слиянию сортировкой метод выполнения соединений таблиц (еще одна альтернатива - вложенные циклы).
• Применение битовых строк для индексирования. До версии 7.3 Oracle применял для индексирования только B-деревья и хэш-функции (если таблица помещалась в хэш-кластер). В версии 7.3 появилась возможность использования индексов с битовыми строками (bit-map indexes). Их идея очень проста. Если некоторое поле таблицы может принимать ограниченное число значений, то каждому такому значению можно сопоставить битовую строку (количество бит равно количеству записей в таблице), в которой единицы находятся в позициях, соответствующих тем записям, которые имеют данное значение в индексируемом поле. Ясно, что такой индекс позволяет очень быстро находить нужные записи по значениям проиндексированного поля (и любым их логическим комбинациям), а также выполнять операции агрегирования опять-таки по этому полю. Метод эффективен лишь для полей с небольшим количеством допустимых значений, неэффективны операции сравнения с предшествованием
(больше/меньше), неэффективны операции вставки, удаления и модификации записей. В действительности "в чистом виде" битовые строки не применяются: они размещаются в листьях B-дерева, что позволяет смягчить указанные недостатки, но очевидно, что в целом они носят принципиальный характер, а потому не устранимы полностью. Oracle позволяет применять bit-map индексирование в сочетании с другими методами индексирования на одной и той же таблице.
До версии Oracle 7.3 основным средством администратора являлся Server
Manager - программный продукт с графическим интерфейсом, но ориентированный на управление одной БД (в случае нескольких БД приходилось использовать несколько сессий), не имевший удобных средств графического мониторинга системы и не позволявший непосредственно управлять удаленными заданиями, требовавшими привлечения системных команд и ресурсов, не находящихся под контролем СУБД Oracle. Пробел заполнялся достаточно многочисленными программными продуктами третьих фирм, специализирующихся именно на средствах администрирования. Однако обеспечение единообразного администрирования распределенных систем стало настолько актуальной задачей, что стимулировала развитие новой стратегии корпорации в области средств администрирования сервера БД.
В комплекте с сервером версии 7.3 (в вариантах Workgroup и Enterprise) поставляется Oracle Enterprise Manager. В состав этого программного продукта входит набор утилит управления, интегрированных в единую консоль администратора. Через специальный связной процесс - Communication Deamon - эта консоль может взаимодействовать с интеллектуальными агентами - специальными процессами, функционирующими на компьютерах-серверах, обеспечивающими возможность удаленного управления (впрочем, агент требуется только для выполнения удаленных заданий и контроля за событиями - все основные административные функции реализуются через непосредственную связь консоли с сервером БД). Все управляемые компоненты - БД, серверы (узлы), процессы - отображаются на консоли в навигаторе объектов, позволяющем быстро находить требуемый объект и детализировать представление его структуры до нужного уровня. Непосредственно административные функции выполняются с помощью явного или неявного вызова соответствующих утилит.
Для выполнения некоторых действий (перенос пользователя из одной БД в другую, присвоение новой роли пользователю и др.) достаточно "буксировки" мышкой.
Принципиально новой особенностью Enterprise Manager по сравнению с более ранними аналогичными продуктами Oracle является возможность определения и управления выполнением удаленных заданий, реализация которых выходит за рамки возможностей самой СУБД (сбросы, команды ОС и т. п.), а также возможность заставить систему саму извещать администратора о возникших (или даже предполагаемых) проблемах с помощью механизма событий.
Задания могут выполняться по заданному расписанию, причем непосредственный контроль за этим осуществляется локально интеллектуальным агентом, так что в принципе постоянная поддержка связи консоли с сервером не требуется (хотя для того, чтобы изменить задание или время его выполнения, необходимо, чтобы "агент вышел на связь"). Помимо использования набора стандартных типов заданий и их комбинаций администратор может определять принципиально новые, исользуя системно-независимый язык TCL
(Task Control Language). Фактически и "стандартные" типы заданий строятся с применением "шаблонов" на этом языке, тексты которых можно использовать в качестве образцов. Интерпретация TCL в конкретной ОС того или иного сервера осуществляется соответствующим интеллектуальным агентом, что делает управление СУБД почти не зависящим от платформы сервера (а таких платформ
Oracle поддерживает более 80).
Набор возможных регистрируемых событий варьирует от самых простых типа запуска и останова сервера БД до достаточно "тонких" типа превышения частоты обращений к диску заданного администратором порога. События регистрируются интеллектуальными агентами и передаются на консоль администратора (точнее, на те из консолей, которые "интересуются" данным событием), а если потребуется, сообщение о событии может быть послано администратору по электронной почте или на пейджер.
Еще одной важной особенностью Oracle Enterprise Manager является то, что он имеет открытые интерфейсы на всех своих уровнях, что открывает возможность наращивания его функциональности за счет добавления новых административных утилит, управляющих процессов и пр. Эта возможность прежде всего ориентирована на фирмы, являющиеся поставщиками средств администрирования, но ею могут воспользоваться и сами пользователи СУБД.
Отдельного упоминания заслуживают поставляемые Oracle утилиты, входящие в
Performance Package. В него входят: утилита мониторинга системы (несколько десятков стандартных динамических диаграмм плюс возможность определять свои собственные); утилита, показывающая в наглядной форме физическое расположение объектов БД в файлах данных и позволяющая выполнять оптимизирующие операции (дефрагментацию); утилита, показывающая информацию о сессиях, потребляющих наибольшее количество ресурсов (есть возможность сортировки сессий по различным параметрам, для любой из выбранных сессий можно легко "спуститься" по лестнице детализации информации о ней вплоть до используемых курсоров и планов выполнения соответствующих им запросов).
Наконец, есть еще две утилиты, стоящие несколько особняком. Это Oracle
Trace - управляемая событиями трассировка - и Oracle Expert - экспертная система, проводящя анализ структуры, параметров и функционирования СУБД и генерирующая рекомендации (а также готовые административные скрипты) для ее оптимизирующей настройки.
Поддержка параллельных систем. Одно из общепризнанных достоинств сервера
Oracle - его высокая степень масштабируемости: как горизонтальной, так и вертикальной. Oracle владеет в настоящий момент абсолютными рекордами производительности как в OLTP-тестах TPC-C (причем этот рекорд держится с апреля 1996 года), так и в DSS-тестах TPC-D (в варианте с объемом данных
300 Гбайт). Наиболее широко распространены симметрично-параллельные (SMP) системы, т. е. такие, где процессоры равноправно используют все остальные системные ресурсы (прежде всего оперативную память и диски), являющиеся общими для них. Количество процессоров в таких системах, предлагаемых на рынке, может доходить до 64. Для SMP-систем часто еще употребляют определение "система с полным разделением ресурсов" (shared-everything system). Следующий тип параллельной архитектуры - кластер: в нем узлы, имеющие свою собственную оперативную память (а возможно и собственные диски), через специальный контроллер имеют доступ к общим дискам ("система с разделяемыми дисками" - shared-disks system). Как правило, каждый из узлов кластера представляет собой SMP-систему, а количество узлов в кластерах, предлагаемых на рынке, доходит до 8. Наконец, третий тип архитектуры - массивно-параллельный (MPP). В ней узлы живут практически независимой жизнью, но между ними каким-то образом реализуется очень быстрая связь. Количество узлов в такой системе вполне может достигать ста и больше. Безусловно система должна в той или иной степени обеспечивать взаимодействие и совместное пользование ресурсами для своих узлов, тем не менее к системам с данной архитектурой часто применяют определение "система без разделения ресурсов" (shared-nothing system).
Сервер Oracle в любой конфигурации поддерживает параллелизм при выполнении потока операций в SMP-архитектуре, для параллельного выполнения отдельных запросов требуется установка Parallel Query Option. Для кластеров и MPP-систем Oracle предлагает архитектуру, позволяющую всем узлам этих систем параллельно осуществлять доступ к одной БД: чтобы добиться этого, достаточно установить Parallel Server Option. Для обеспечения параллелизма в SMP-системах Oracle предлагает возможность использования многопотоковых разделяемых серверных процессов.
Опция Oracle Parallel Server позволяет нескольким узлам системы
(фактически всем, функционирующим в данный момент времени) параллельно работать с одной БД, находящейся на общих дисках (в MPP-системе это будут
"виртуальные" общие диски, поддерживаемые ОС). Пользовательские сессии взаимодействуют каждая со своим узлом, но при этом фактически работают с одними и теми же данными (помимо возможности использования полной мощности параллельной системы для работы с БД). Можно заметить, что в Oracle8 даже эта операция не обязательна: новая версия сервера позволяет выполнять автоматическое переключение сессий со сбойного узла, так что, например, прерванные запросы попросту продолжают выполняться после небольшой задержки.
Однако нельзя утверждать, что при применении OPS не возникает никаких проблем. По сравнению с SMP-системами возникает одна проблема: синхронизация кэшей в оперативной памяти узлов – каждый узел системы кэширует данные БД в своей оперативной памяти и может держать их там достаточно долгое время без переписывания на диск. Если один из узлов модифицировал некую запись БД, но не переписал ее на диск, то при обращении к той же записи другой узел не имеет права ни пользоваться ее копией в своей памяти (она уже не актуальна), ни даже считать ее с диска. Для разрешения этой проблемы вводятся блокировки параллельного кэша: при модификации данных узел параллельной системы как бы вешает на них свой
"замок", так что любой другой узел при обращении к этим данным должен сначала "снять замок", что включает в себя передачу ему актуальных данных.
Ясно, что если различные узлы будут часто модифицировать одни и те же данные, то блокировки параллельного кэша могут заметно снизить производительность сервера в целом.
К сожалению, от данной проблемы нельзя полностью избавиться ни с помощью технических ухищрений, ни с помощью альтернативных решений. К счастью, если пользователи, работающие с разными узлами, редко модифицируют одни и те же записи, то и блокировки параллельного кэша возникают редко. Такой режим легко обеспечивается, если на разные узлы сервера "назначаются" пользователи, работающие с разными приложениями, или работающие с данными различных отделов (филиалов) и пр. Приложения, осуществляющие "хаотичные" обращения к большой БД, также имеют слабую тенденцию к порождению блокировок параллельного кэша. Тем не менее, распределение пользователей между узлами сервера должно осуществляться не наобум, а с учетом того, с какими данными и в каком режиме они работают. Как бы то ни было, OPS уже достаточно давно и успешно используется - особенно в инсталляциях, требующих повышенной надежности системы. Нелишне заметить, что и рекорд в тестах TPC-C поставлен с использованием OPS на кластере (Digital Alpha
8400). Надо сказать, что до последнего времени понятия "кластер" и
"параллельный сервер" ассоциировались только с весьма мощными и дорогостоящими конфигурациями аппаратуры. Отчасти это было связано с реальными потребностями рынка, а отчасти с тем фактом, что поддержка кластерного режима работы требует весьма значительных системных ресурсов.
Одним из первых пожирателей ресурсов является менеджер распределенных блокировок (Distributed Locks Manager - DLM). Это программный компонент
(реализованный обычно в виде набора процессов), обычно поставляемый фирмой- разработчиком ОС, задача которого - управление доступом к разделяемым ресурсам на уровне системы в целом. Именно с помощью DLM Oracle реализует блокировки параллельного кэша и вообще синхронизацию работы узлов.
Универсальность DLM в сочетании с тем, что он является "внешней составляющей" OPS, приводит к тому, что общее количество блокировок параллельного кэша становится критичным ресурсом. Чтобы снизить потребность в нем, в Oracle 7.3 введен ряд усовершенствований в управлении выделением этих блокировок, но для радикального решения проблемы безусловно требовался другой подход к реализации DLM. В частности, по этой причине уже в версии
7.3 Oracle постепенно переходит к реализации DLM собственными средствами в составе ядра сервера - окончательно этот процесс завершен в Oracle 8. Как бы то ни было, уже в релизе Oracle 7.3.3 существует параллельный сервер для кластеров, функционирующих под управлением таких "легковесных" ОС, как SCO
UnixWare и Windows NT (последняя - как для платформы Intel, так и для DEC
Alpha).
При параллелизме, в задачах типа DSS, при выполнении отдельных операций оптимизатор выбирает один из возможных алгоритмов выполнения запросов (при этом важно, что в Oracle он с самого начала при оценке стоимости того или иного решения учитывает заданную для данного запроса степень параллелизма), затем каждый шаг алгоритма разбивается на несколько параллельных потоков.
Координатор выполнения запроса запускает нужное число процессов (при этом используются все наличные процессоры - включая различные узлы кластера или
MPP-системы) и обеспечивает как внутриоперационный (параллельные потоки внутри шага алгоритма), так и межоперационный параллелизм. В список операций, подлежащих распараллеливанию, помимо просмотра таблиц включены также все алгоритмы соединения (и "антисоединения") таблиц, сортировки, операции агрегирования, вложенные подзапросы, объединения и некоторые другие. Кроме того, возможно параллельное выполнение таких операций, как создание таблицы по результатам запроса, загрузка данных, сброс и восстановление БД, выполнение операций тиражирования данных. В Oracle8 к этому списку добавятся операции INSERT, UPDATE и DELETE.
Одним из наиболее фундаментальных вопросов, которые приходится решать при реализации параллельного выполнения запросов, является выбор метода распределения данных между параллельными потоками при выполнении таких операций, как полный просмотр таблиц. Самым простым (и исторически реализованным первым - фирмой Tandem) методом является "привязка" параллелизма к статическому разбиению нужных таблиц на разделы, проводимому по правилу, заданному администратором системы. Этот метод и до сих пор является краеугольным камнем параллелизма в ряде СУБД.
В идее разбиения таблиц на разделы безусловно есть серьезные положительные стороны, особенно когда это разбиение осуществляется на основе диапазонов значений содержательных параметров либо функций от них.
Тогда, во-первых, может быть облегчена работа администратора БД в случае, когда таблица содержит большой объем данных (например, если разбить таблицу фактических продаж по месяцам, то можно выполнять сбросы только последнего раздела таблицы), во-вторых, становится возможным исключение разделов при выполнении запросов, содержащих условие на параметр разбиения. Однако когда параллелизм в выполнении запросов ставится в зависимость от статичного разбиения таблиц, это приводит к ряду проблем. Дело в том, что для достижения оптимального параллелизма в этом случае требуется (по очевидным причинам), чтобы данные были распределены по разделам равномерно. В принципе этого нетрудно добиться, если помещать каждую новую запись в новый раздел по циклическому алгоритму (round-robin). Но в этом случае, как нетрудно заметить, полностью теряются указанные выше два преимущества. И наоборот, если выполнять разбиение по содержательному критерию, то весьма часто получается, что данные распределяются по разделам неравномерно, что неизбежно приводит к тому, что, закончив свою работу, параллельные процессы ждут "отстающего товарища", которому не повезло с разделом. Если речь идет об устоявшихся (т. е. фактически не обновляемых) данных и о конкретном запросе с небольшими вариациями, то практически всегда можно найти некий компромиссный вариант разбиения, но в реальных системах типа DSS запросы как правило носят нерегламентированный характер (ad-hoc), а данные - опять- таки как правило - периодически обновляются. Все это как минимум приводит к серьезной административной работе, связанной с перестройкой разделов (что становится попросту обязательным, если требуется сменить степень параллелизма), но даже это не гарантирует оптимального параллельного выполнения запросов.
Такие соображения побудили разработчиков Oracle7 отказаться от принципа
"статичного" параллелизма и реализовать алгоритм динамического разбиения таблиц при параллельном выполнении запросов. Упрощенно его суть в том, что таблица логически "разбивается" непосредственно при выполнении запроса в соответствии с заданной степенью параллелизма. Это не означает, впрочем, что она попросту делится на равные части произвольным образом - все гораздо изощреннее. Дело в том, что скорость обработки одного и того же объема данных в разных разделах может быть различна в зависимости как от характера запроса, так и от того, на каких физических устройствах располагается динамический раздел, да и от других порой трудно предсказуемых причин.
Поэтому таблица делится реально на число разделов гораздо большее, чем степень параллелизма (и разделы эти бывают различного размера), а их назначение параллельным процессам регулируется динамически в зависимости от того, с какой скоростью они справляются с уже порученной работой.
Надо сказать, что алгоритм динамического разбиения таблиц весьма непрост, и было бы нечестно утверждать, что в нем с самого начала все было сделано самым оптимальным образом. Однако одно из самых важных преимуществ этого алгоритма в его гибкости, поэтому в него постоянно вносились усовершенствования на основании накопленного опыта эксплуатации в реальных инсталляциях, в результате чего от релиза к релизу Oracle7 добивался все более оптимальных характеристик параллелизма в выполнении запросов. К примеру, в релизе 7.3 основные усовершенствования были связаны с поддержкой
MPP-архитектур. Дело в том, что в них диски не равноценны по скорости доступа для каждого из узлов системы (к "своим" дискам доступ осуществляется быстрее, чем к "чужим"), поэтому и динамические разделы стали выделяться параллельным процессам преимущественно на локальных для соответствующих узлов дисках (преимущественно - опять-таки потому, что, завершив свою "локальную" работу, процесс не прекращает деятельность, а начинает помогать "отстающим").
Как бы то ни было, сейчас можно с уверенностью констатировать, что метод динамического разбиения таблиц оправдал себя, позволив при минимальной дополнительной нагрузке на администратора БД добиться, тем не менее, практически оптимального распраллеливания выполнения запросов. Высокая масштабируемость Oracle в параллельном выполнении запросов на системах с различной архитектурой иллюстрируется также и тем фактом, что Oracle 7.3 сумел показать рекордные параметры в TPC-D тесте (в варианте с объемом данных 300 Гбайт) как среди MPP-систем (на IBM SP/2), так и среди SMP- систем (на Sun Enterprise Server 10000).
Oracle 7, к сожалению, не включает в себя явной операции построения статических разделов таблицы (эта возможность вводится в Oracle 8), но в неявном виде это тем не менее можно сделать с помощью имитации разделов отдельными таблицами, объединенными в единое представление с помощью операции UNION ALL. При выполнении запросов к такому представлению оптимизатор Oracle7 трактует его именно как таблицу, разбитую на разделы, в частности выполняет исключение разделов, если это возможно.
Oracle традиционно славится как поставщик СУБД для крупных инсталляций, однако в связи с этим бытует (и активно поддерживается конкурентами) также и мнение о том, что для небольших систем Oracle слишком тяжеловесен, сложен, дорог и пр. Oracle прикладывает немало усилий, чтобы по всем параметрам (включая цены) утвердиться в качестве основного поставщика во всех сегментах рынка СУБД, начиная с небольших рабочих групп. С 1994 года помимо уже привычного "сервера масштаба предприятия" поставляются другие его варианты: "сервер для рабочих групп" (Workgroup server) и "персональный
Oracle" (Personal Oracle) в двух редакциях - полной и "облегченной"
(Personal Oracle Lite). В этих продуктах особый упор сделан на их относительную дешевизну, простоту установки и сопровождения. При этом все варианты сервера Oracle функционально идентичны, за исключением некоторых опций (только в нынешней версии Personal Oracle Lite отсутствует часть базовой функциональности: он не поддерживает многопользовательские схемы данных и процедурные расширения SQL).
Oracle 7 в одинаковой степени может быть оптимизирован и для OLTP- приложений, и для приложений DSS, причем их вполне можно исполнять одновременно, не беспокоясь о дополнительных блокировках, модах изоляции и прочих темах, способных вызвать головную боль у знакомых с ними на практике специалистов при одном только их упоминании. Это не означает впрочем, что оба режима будут одинаково оптимальны при одном и том же выборе параметров системы. Безусловно, по крайней мере часть параметров требуют разного подхода при их оптимизации для OLTP- и DSS-систем. По этой причине поддержка "смешанного" режима обязательно сопряжена с некоторым компромиссом, и не следует трактовать приведенное утверждение как рекомендацию совмещать оперативную систему с хранилищем данных. Более разумно на практике говорить о том, что, скажем, если основной режим системы - OLTP, то совсем не обязательно дожидаться ночной паузы в работе, чтобы выполнить на ней сложный - но срочный - отчет, и Oracle гарантирует, во-первых, корректность результатов отчета, во-вторых, что его выполнение не повлияет сколько-нибудь заметно на работу пользователей.
Oracle поддерживает любой тип данных. В сущности, речь идет о расширении стандартного набора типов данных, характерного для РСУБД, а в перспективе о переходе к объектно-реляционной модели СУБД. В свою очередь, эта задача может быть разделена на две:
- поддержка поставщиками СУБД дополнительных "базовых" типов данных;
- возможность расширять набор типов данных за счет модулей третьих производителей или самими пользователями.
Oracle развивает свой сервер в обоих направлениях. В версии 7.3 уже поддерживается несколько новых типов данных: неструктурированные тексты, пространственные данные, видеоданные. Собственно говоря, хранить такие данные в БД и осуществлять к ним доступ можно было и раньше: новизна в том, что если раньше этот доступ осуществлялся через самостоятельно работающие серверные процессы, и для работы с ними требовалось использование специального интерфейса на уровне приложений, то теперь данная функциональность интегрирована в "базовый" сервер.
Опция для работы с пространственными данными (Spatial Data Option) фактически вводит тип данных "пространственная точка" и операции над ним в
СУБД, позволяя хранить соответствующие данные в таблицах оптиальным образом и на порядок (а порой и на два) ускорять выполнение запросов.
Что касается видеоданных, то соответствующая им опция - Video Option - единственная, "живущая самостоятельной жизнью" по отношению к серверу РСУБД
(но не к БД). Более того, рекомендуется конфигурация, в которой Video
Server запускается на отдельном компьютере от сервера БД. Связано это с тем, что воспроизведение видеофрагментов в реальном времени (особенно по нескольким каналам) - что как раз и обеспечивает Video Server - трудно совместимо на современных массово производимых компьютерах с функционированием сервера СУБД из-за чисто аппаратных ограничений. Тем не менее приложение, работающее с Video Server, может осуществлять поиск видеофрагментов по описательным атрибутам и воспроизведение этих фрагментов
- как единую интегрированную операцию.
Относительно Web Option, пожалуй, не совсем правильно говорить о функциональных расширениях сервера, поскольку, в сущности, главная задача опции - обеспечение интерфейса с Web Application Server и соответственно через него с пользователями Intranet/Internet.
Oracle OLAP Option едва ли можно было рассматривать как интегрированную компоненту сервера Oracle (продукты OLAP работают с собственным - многомерным - представлением данных, хранимым отдельно) до недавнего времени, когда с помощью Access Manager появилась возможность устанавливать динамическую связь многомерного куба OLAP с реляционными данными, стирая тем самым грань между MOLAP и ROLAP (для аналитика, работающего с приложениями OLAP, стало совершенно незаметно, работает ли он с предварительно сформированным многомерным кубом или с динамическим многомерным представлением реляционных данных).
Развитие подхода в Oracle 8. В отличие от Oracle 7 восьмая версия сервера
Oracle не просто предоставляет расширенный набор встроенных типов данных, но и позволяет конструировать новые типы данных со спецификацией методов доступа к ним. Это означает фактически, что разработчики получают в руки не просто систему для хранения и обработки, скажем, видеоданных (что, понятно, нужно далеко не в каждом приложении), а и инструмент, позволяющий строить структурированные типы данных, непосредственно отображающие сущности предметной области. Влияние этого фактора на возможности разработчиков можно сравнить с эффектом от перехода на реляционные СУБД в начале 80-х годов.
Oracle8 фактически опирается на новый стандарт SQL, позволяющий описывать определения новых типов объектов, состоящих из атрибутов (скалярных - т. е. других типов, множеств объектов, ссылок на объекты), и обладающих ассоциированными с ним методами. Любая колонка таблицы может быть любого типа, поддерживаются также вложенные таблицы и массивы объектов переменной длины.
Что касается методов доступа, то они могут быть определены несколькими способами. Более простой из них предполагает контроль ядра сервера за выполнением метода: это достигается, если методы реализуются на PL/SQL
(который также расширен для поддержки объектно-реляционных структур) или
Java. Поскольку PL/SQL практически не уступает по своей функциональности универсальным языкам программирования, для подавляющего большинства составных типов данных таких возможностей будет достаточно. Если же новый тип данных требует специальной обработки, не реализуемой стандартными средствами ядра СУБД (к примеру, работа с мультимедийными данными, хранимыми в BLOB-полях в БД), можно использовать вызовы внешних процедур
(call-outs), которые могут быть написаны, допустим, на языке C.
При использовании внешних процедур возникает серьезная проблема организации их взаимодействия с ядром сервера. Наиболее соблазнительная - на первый взгляд - идея включения их непосредственно в ядро таит в себе угрозу нарушения стабильности этого ядра, поскольку оно оказывается незащищенным перед "чужим" кодом, и, следовательно, при любом сбое (или неправильном функционировании) становится практически невозможно определить, явилось ли это следствием ошибки в самом ядре, или же это
"наведенный" эффект от внешней процедуры. Поэтому Oracle изначально отказался от такой идеи и реализует взаимодействие ядра сервера с внешними процедурами в защищенном режиме (т. е. в различных адресных пространствах).
Для реализации такого взаимодействия и для доступа из внешних процедур к данным БД требуется наличие специального программного интерфейса. Oracle в данном вопросе пошел по пути поддержки имеющегося стандарта интерфейса
Corba, позволяя оформлять расширения ядра сервера как "картриджи данных"
(Data Cartridges), входящие в более общую архитектуру сетевых вычислений
(Network Computing Architecture).
Для обеспечения постепенной миграции приложений и данных в новую объектно- реляционную среду введены объектные представления (object views), которые позволяют использовать в новых приложениях объектный интерфейс, работая при этом с обычными реляционными таблицами (т. о. сохраняя работоспособность старых приложений).
Новые возможности в администрировании Oracle 8 - управляемые сервером сбросы и восстановления (собственно говоря, это расширенная интеграция применявшейся в Oracle 7 утилиты Enterprise Backup), централизованное хранение паролей (в Oracle 7 достигалось при использовании Advanced
Networking Option или при идентификации пользователей через ОС, имеющую соответствующую функциональность), контроль за назначением и устареванием паролей (в Oracle7 - при идентификации пользователей через ОС). Новые режимы взаимодействия с сервером - поддержка очередей приоритетных сообщений, задающих описание транзакции или ее части (эта функциональность, кстати, может быть использована мониторами транзакций), возможность мультиплексирования сессий как на физических, так и на логических каналах связи. Фактическое снятие ограничений на количество BLOB-колонок в таблицах, возможность их тиражирования. Возможность разбиения BLOB-полей и их отдельного хранения (даже вне БД). Расширение функциональных возможностей тиражирования данных, введение программного интерфейса тиражирования, позволяющего реализовать поддержку репликации с самыми разнообразными системами хранения данных. Поддержка таблиц, целиком хранимых в индексах. Это далеко не полный список. Большая часть новшеств возникла не на пустом месте, а скорее представляет собой развитие тех черт, которые уже содержались в том или ином виде в Oracle7. Это не случайность:
Oracle гарантирует совместимость версий сервера снизу вверх, при переходе к
Oracle8 пользователям даже не потребуется перестраивать свои БД.

1.1.4 MS SQL Server

Компания Microsoft широко известна рынке ПО. В 1988 г. фирма Microsoft совместно со своими партнерами Acton-Tate и Sybase представили свою первую версию SQL Server, построенную под операционную систему OS/2. В дальнейшем, фирма Microsoft перенесла SQL Server под Windows NT. Эти изменения потребовали коренных перестроек в ядре SQL Server, но, тем самым, обеспечили продукту SQL Server мощность мультипроцессорной RDBMS в среде
Windows NT. В 1992 г. фирма Microsoft начала процесс отделения от Sybase и стала сосредотачивать больше внимания на собственной версии SQL Server. В конце концов, Microsoft и Sybase закончили совместную работу, и к Microsoft перешел полный контроль над разработкой SQL Server. Далее в SQL Server были добавлены следующие возможности: поддержка RISC-платформы, MAPI-интерфейс для разработки приложений, выполняющих запросы в базу данных, инструменты переноса данных, интеграция с объектами OLE и системой программирования
Visual Basic и многое другое.
Microsoft SQL Server 6.5 является одним из наиболее стремительно развивающихся серверов баз данных на рынке корпоративных СУБД. Разумеется, невозможно подробно остановиться на характеристиках этого продукта в той мере, в какой это хотелось бы сделать и какой он, безусловно, заслуживает. рассмотрим хотя бы некоторые из базовых возможностей Microsoft SQL Server
6.5 применительно к перечисленным выше функциям сервера баз данных.
Симметричная мультипроцессорная архитектура Microsoft SQL Server 6.5 предусматривает использование "родных" сервисов операционной системы
Windows NT для управления потоками, памятью, операциями дискового чтения/записи, сетевыми службами, функциями безопасности, а также для поддержки параллельного выполнения потоков на нескольких CPU. Использование потоков Windows NT позволяет MS SQL Server автоматически масштабироваться при работе на многопроцессорных платформах, что исключает необходимость дополнительной конфигурации или программной настройки. Например, на Comdex была продемонстрирована работа MS SQL Server на платформе AlphaServer 8400 производства Digital, оснащенным 12 процессорами, 28 Гбайт памяти и 39-ти терабайтным хранилищем. В отличие от большинства распространенных СУБД, вынужденных иметь в своем составе механизмы дублирования ядра операционной системы для обеспечения кросс-платформенной переносимости, MS SQL Server обладает достаточно легковесной прозрачной архитектурой, не перетяжеленной несвойственными ей функциями. В результате, например, при смене типа процессора не требуется заново приобретать MS SQL Server для новой аппаратной платформы. Он ставится, по определению, на все, на чем работает
Windows NT (на сегодня это Intel, Alpha, MIPS и PowerPC). По мере того как
Windows NT завоевывает все большее признание и все ведущие производители
СУБД уже выпустили версии своих продуктов под этой операционной системой или уже заявили о своей готовности это сделать в ближайшее время, изначальная ориентированность MS SQL Server 6.5 на тесную интеграцию с
Windows NT выступает в качестве одного из серьезных преимуществ.
На каждое пользовательское соединение в MS SQL Server назначается отдельный рабочий поток (порядка 55К) в рамках единого серверного процесса.
Так как каждый из этих потоков в действительности является потоком Win32, на них распространяются соответствующие функции контроля операционной системы, включая защиту памяти, правила доступа к оборудованию и планирование выполнения потоков во времени (thread scheduling). Это предоставляет улучшенные способности к масштабированию при росте числа одновременно работающих пользователей, динамическую балансировку при загрузке процессоров и повышенную надежность, так как пользовательские запросы, исполняющиеся на разных потоках, защищены друг от друга. Несмотря на то что пул соединений ограничен 1024 потоками, динамическое управление пользовательскими соединениями и свободными потоками позволяет увеличить эту величину до 32 767. Кроме этого, другие пулы потоков могут использоваться для параллельного выполнения операций сканирования данных, удаления и обновления, резервного копирования, проверки целостности базы, индексирования, асинхронного опережающего чтения данных в кэш на основе алгоритмов предсказания, создания и управления курсорами и т. д.
Сетевые службы Windows NT обеспечивают MS SQL Server поддержку протоколов
TCP/IP, NWLink IPX/SPX, Named Pipes (NetBEUI), Banyan Vines, AppleTalk
(ADSP) и DECNet. В версии 6.5 к ним добавилась дополнительная сетевая библиотека – multi-protocol network library, которая "умеет слушать" порты
TCP/IP, сокеты SPX или поименованные каналы (named pipes), которые обычно выбираются динамически. Несомненным достоинством multi-protocol является наличие сетевого сервиса, обеспечивающего взаимодействие между процессами при помощи вызовов удаленных процедур, что позволяет, например, использовать шифрование при передаче данных.
Многопоточное ядро и интеграция со службами планирования потоков Windows
NT обеспечивает высокую производительность MS SQL Server при обработке OLTP- и DSS-запросов, что особенно заметно при одновременной работе нескольких сотен пользователей. В опубликованных результатах по тестированию MS SQL
Server 6.5 на максимальное число одновременно работающих пользователей приводится цифра 3500, хотя известны реально работающие приложения, где нагрузка доходила до 5000 одновременных пользовательских соединений. За период с октября 1996 г. по декабрь 1997 г. производительность MS SQL
Server , измеренная по тестам TPC-C, выросла более чем в 3 раза. Для сравнения заметим, что ежедневный объем транзакций в расчетной системе VISA составляет от 10 до 40 млн. Темп 7,5 тыс. транзакций в минуту означает, что один MS SQL Server способен при режиме работы 24х7 обслужить немногим менее
11 млн. транзакций в сутки. Существует еще один параметр, тесно связанный с производительностью, который, не являясь в строгом смысле слова техническим, очень популярен на Западе при оценке возможностей того или иного сервера баз данных, так как от него существенно зависит стоимость владения продуктом. Речь идет об удельной цене за транзакцию в минуту, иными словами, сколько придется заплатить за достижение такой скорости обработки запроса. За тот же самый период, в течение которого рассматривался рост производительности, показатель
"цена/производительность" стал менее 65 долл. за транзакцию в минуту, что говорит о разумной стоимости систем на базе MS SQL Server при высоких требованиях к скорости обработки.
Распределенная среда управления. В состав MS SQL Server 6.5 входит свыше
20 графических средств управления и утилит командной строки. Кроме этого,
MS SQL Server 6.5 включает Web-assistant - программу мастер для подготовки публикации на Web-страницах данных из базы, SQL Mail - утилиту, обеспечивающую интеграцию с электронной почтой MS Mail или MS Exchange, MS
Distributed Transaction Coordinator (MS DTC) для проведения распределенных транзакций и некоторые другие средства. SQL Server, MS DTC и SQL Executive функционируют как сервисы операционной системы. Согласованная работа этих компонентов достигается благодаря трехуровневой архитектуре SQL -DMF
(Distributed Management Frame-work).

Легко масштабируемая распределенная среда управления позволяет значительно упростить процессы централизованного контроля над многими серверами, которые могут объединяться в группы по соображениям безопасности или с административными целями, и их объектами.
SQL Enterprise Manager интегрирует в себе все функции управления, включая создание баз данных и объектов внутри них, назначение прав доступа, резервное копирование, тиражирование и т.д. При желании имеется возможность автоматизировать процесс составления плана поддержки базы при помощи специальной программы-помощника (Database Main-tenance Wizard). Различные подходы к системному администрированию зачастую могут содержать ряд малоприятных моментов, например необходимость выполнять резервное копирование базы, командировать сотрудников в какой-нибудь удаленный филиал, где отсутствует должным образом подготовленный IT-персонал. MS SQL
Server 6.5 позволяет решить эти проблемы, во-первых, за счет централизованного управления удаленными серверами, во-вторых, за счет наличия мощного средства диспетчеризации задач во времени, предоставляемого
SQL Executive. Для каждой административной функции может быть назначен временной график ее выполнения. Практически все СУБД содержат развитые средства по ликвидации тех или иных неблагоприятных последствий. Microsoft
SQL Server, помимо этого, предоставляет обширный инструментарий диагностики, позволяющий своевременно предотвратить причины сбоев. Утилиты
SQL Performance Monitor и Alert Manager могут использоваться для программирования реакции сервера на различные классы событий, возникающих в системе, в том числе и на бизнес-события, MS SQL Server может послать вам
(или указанным вами лицам) по электронной почте или на пейджер соответствующее предупреждение и/или выполнить предусмотренный вами скрипт, cmd- или exe-файл для устранения ошибки, а также зафиксировать появление этого события в системном журнале. В целом можно сказать, что распределенная среда управления позволяет существенно упростить жизнь администратора базы данных.
SQL-DMO (Distributed Management Objects). В качестве промежуточного слоя в архитектуре распределенной среды управления выступают распределенные объекты управления (DMO), которые играют исключительно важную роль в концепции построения MS SQL Server и потому заслуживают более тщательного рассмотрения. По мере того как приложения приобретали все менее централизованный характер, поддержка распределенных баз данных становилась одним из самых актуальных вопросов построения современных СУБД. SQL
Enterprise Manager позволяет осуществлять удобное администрирование распределенных серверов из единого центра, однако наряду с этим хотелось бы иметь возможность программного обращения к административным функциям из высокоуровневых языков. Обычно использовавшимся для этих целей в других
СУБД сценарным языкам типа REXX или PERL недоставало функциональных возможностей, библиотек классов, отладчика и т. д.
Поэтому в случае с Microsoft SQL Server был избран более открытый подход: сервер был разработан как совместно с набором объектов управления, которые могли быть вызваны из любого языка программирования, поддерживающего технологию СОМ (Component Object Model). MS SQL Server 6.5 предоставляет интерфейс OLE Automation с более, чем 70 объектами, обладающими 1500 свойствами.
Это означает, что фактически любая из административных задач, включая операции над базами данных, ограничениями (constraints), триггерами, таблицами, представлениями, полями, индексами, пользователями, группами, публикациями и пр., может быть оформлена как вызов соответствующего метода соответствующего объекта и выполнена (при наличии прав доступа) из Visual
Basic, Visual C++, Visual J++, Visual FoxPro и т. д.
В основе практически всех вышеперечисленных утилит лежит код языка
Transact-SQL. Microsoft SQL Server 6.5 был первой СУБД, прошедшей сертификационные испытания Правительства США на соответствие входному уровню (entry level) федеральных стандартов обработки информации (FIPS)
127.2. Эти тесты основываются на известных стандартах ANSI SQL92 и включают дополнительные требования, в частности по поддержке трехуровневых архитектур. MS SQL Server 6.5 содержит большое количество черт и функций, относящихся к более высоким уровням стандарта ANSI SQL92 (intermediate и full), например скроллируемые в обоих направлениях курсоры с абсолютным и относительным позиционированием. Насколько мне известно, ни одна из СУБД на сегодня не достигла полного соответствия уровню ANSI SQL92, более высокому, чем входной.
Transact-SQL включает операторы для изменения настроек сервера, пользовательской сессии, просмотра и редактирования данных, создания и модификации баз и их объектов. В настоящее время в MS SQL Server поддерживается только строгий (restrict) тип ссылочной целостности.
Помимо обычных хранимых процедур MS SQL Server предоставляет возможность динамической загрузки и выполнения функций, которые называются расширенными хранимыми процедурами и выполнены в виде dll-библиотек. Расширенные процедуры объединены в dll-библиотеки в целях повышения производительности по сравнению с оформлением в виде отдельных процессов. Кроме расширенных процедур, входящих в Transact-SQL, MS SQL Server позволяет создавать пользовательские расширенные процедуры c использованием кода на C при помощи MS Open Data Service (ODS) API. MS ODS является мощным средством разработки и применяется также для создания шлюзов к неподдерживаемым штатно пользовательским ресурсам, программирования задач аудита, извещения о событиях и пр. Дополнительный уровень защиты обеспечивается обработчиком исключений MS SQL Server, который предотвращает сервер от сбоя в случае нарушений защиты памяти в расширенной процедуре.
В версии 6.5 в Transact-SQL вошли хранимые процедуры для работы с объектами OLE Automation. Таким образом, фактически появилась возможность писать расширенные хранимые процедуры на любом языке программирования, поддерживающем создание серверов OLE Automation: Visual Basic версии 4 и выше, Visual FoxPro 5.х и т. д. Экземпляр соответствующего объекта создается непосредственно в коде Transact-SQL.
Механизм вызовов удаленных хранимых процедур (RPC) позволяет организовать межсерверное взаимодействие и является мощным средством построения распределенных баз. RPC означает вызов с одного сервера процедуры, принадлежащей другому серверу баз данных. Клиентское приложение может вызывать процедуру на своем основном сервере, которая неявно для клиента может порождать каскад вызовов удаленных хранимых процедур на других серверах. RPC представляет собой достаточно удобный способ работы с распределенными данными без необходимости внесения изменений в клиентскую часть приложения.
MS Distributed Transaction Coordinator (DTC). Создание распределенных приложений приводит к тому, что транзакции также приобретают распределенный характер. Структуризация приложения в виде многих самостоятельных компонентов способна существенно повысить масштабируемость и повторную используемость, а также упростить его разработку. Однако при этом необходимо иметь в виду, что сбой в работе одного из компонентов (например, в результате выхода из строя компьютера, на котором она была запущена) не должен сказываться на целостности функционирования всего приложения в целом, т. е. компонент может временно выключиться из согласованной работы приложения, но связанные с ней сообщения должны быть обработаны корректно.
Участниками распределенной транзакции являются приложение, менеджеры транзакций, менеджеры ресурсов и сами ресурсы, затрагиваемые транзакцией. В этой цепочке MS DTC выполняет роль менеджера транзакций.
MS DTC содержит компоненты клиентской и серверной настройки. Установка клиентского компонента требуется только в том случае, если данный клиент будет сам инициировать распределенные транзакции, а не использовать транзакции, начатые на серверной стороне. MS DTC достаточно легок и удобен в настройке и управлении.
OLE Transaction выгодно отличается от некоторых других распространенных стандартов тем, что построен на основе объектной модели и поддерживает приложения, работающие одновременно со многими потоками. OLE Transaction обладает улучшенными характеристиками по сравнению с ранее разработанными стандартами, лишенными, например, возможности восстановления (recovery), инициированного менеджером ресурсов. Тем не менее при помощи процесса XA
Mapper MS DTC, выполняющего роль переводчика между XA и OLE Transaction, обеспечивается определенное взаимодействие с продуктами, совместимыми со стандартом X/Open DTP XA.
MS DTC может участвовать в транзакциях, координируемых мониторами транзакций Encina, TopEnd и Tuxedo, для которых он выглядит как некоторый менеджер ресурсов. Стандарт OLE Transaction содержит возможности расширения для работы с широким спектром транзакционно-защищенных ресурсов, к которым могут быть отнесены документы, образы, очереди сообщений и другие виды плохо структурированной информации.

MS SQL Server использует следующие типы блокировок:
- shared - для операций, не изменяющих содержимое данных, например select;
- update - когда сервер намеревается изменить данные, во время непосредственной записи обновлений этот тип блокировки изменяется на exclusive (для таблиц см. intent);
- exclusive - при модификации данных (insert, update, delete).
Надежность хранения информации. В критических для бизнеса приложениях, когда сервер СУБД должен быть постоянно доступен для клиентов, большинство профилактических работ по поддержке базы данных приходится выполнять фактически в режиме on-line. MS SQL Server обладает возможностями динамического резервного копирования данных. В случае сбоя оборудования, отключения питания и т. д. механизм автоматического восстановления MS SQL
Server восстанавливает все базы данных до их последнего целостного состояния без вмешательства администратора. Все завершенные, но не отраженные в базе транзакции из журнала транзакций применяются к базе данных (это фактически то, что происходит при событии chekpoint), а незавершенные транзакции, т. е. те, которые были активными на момент сбоя , вычищаются из журнала.
MS SQL Server 6.5 предусматривает возможность зеркалирования устройств, переключения на зеркальные устройства в качестве основных, выключения зеркалирования и уничтожения зеркального устройства также "на лету", т. е. без остановки штатной работы сервера по обслуживанию пользовательских запросов. Зеркалирование и дуплексирование устройств для работы с MS SQL
Server может быть также выполнено средствами Windows NT, а также на аппаратном уровне (поддержка различных RAID-систем и т. д.). Появление следующей версии MS SQL Server должно обеспечить работу серверов в кластере как единого виртуального сервера.
Наличие развитого механизма тиражирования в любой серьезной системе управления базами данных обуславливается необходимостью приближения данных к местам их непосредственного потребления, что является особенно важным фактором при построении витрин данных в системах принятия решений, разгрузки приложений от избыточных функций чтения/поиска при создании отчетов и т. д. Создание распределенных приложений с использованием средств тиражирования положительно сказывается на относительной автономии сайтов, повышении масштабируемости и производительности. Традиционно в построении распределенных систем данных существуют два основных подхода. Один из них основан на плотной целостности данных (loose consistency). Протокол двухфазной фиксации гарантирует идентичность данных в любой момент времени на всех узлах сети, однако необходимо иметь в виду, что этот подход требует наличия высокоскоростных каналов передачи данных и постоянной доступности каждого узла. Другой подход, основанный на слабой целостности (loose consistency), допускает, вообще говоря, некоторый временной интервал между внесением изменений в оригинал и их отражением в образе. Приложения, основанные на принципе слабой целостности, являются значительно менее чувствительными к доступности узлов, а также пропускной способности и надежности каналов передачи данных. Тиражирование в MS SQL Server построено на использовании именно второго подхода.
На дистрибьюторе существуют еще два вида процесса: распространение и очистка. Задача распространения создается для каждой пары "тиражируемая база/подписавшаяся база", а задача очистки - для пары "издатель/подписчик".
Распространение (distribution task) применяет прочитанные из базы данных распространения sql-команды к базе данных подписчика. Процесс очистки
(cleanup task) уничтожает все выполненные работы (т. е. транзакции) из базы данных распространения через некоторый настраиваемый интервал после того, как они были доведены до подписчика. Несмотря на то что организация всего процесса тиражирования может быть записана в кодах при помощи вызовов специальных хранимых процедур, эта черта используется на практике крайне редко и главным образом в целях отладки. В обычных ситуациях настройка и управление тиражированием осуществляются из графической среды SQL
Enterprise Manager и планировщика задач SQL Executive.
Соединение дистрибьютора с издателем происходит на основе DB-Library, а с подписчиком - через ODBC. Таким образом, в качестве подписчиков MS SQL
Server может выступать широкий спектр ODBC-достижимых ресурсов, к которым, например, относятся другой Access, Sybase, Oracle, DB2 и т. д.
Тиражирование в MS SQL Server основано на интегрированном режиме безопасности (см. Безопасность), следовательно, между дистрибьютором и подписчиком должны быть установлены доверительные соединения (trusted connections) с использованием поименованных каналов (named pipes) или мультипротокола. Если серверы находятся в разных доменах, между доменами должны быть установлены двусторонние доверительные отношения. В случае небольших объемов тиражируемых данных издатель часто совмещает с дистрибьютором на одном MS SQL Server.

MS SQL Server обладает обширными возможностями настройки процесса тиражирования. Отметим, что для каждой статьи имеется возможность назначить к тиражированию только необходимые типы транзакций. В зависимости от административного акцента MS SQL Server позволяет организовать подписку на стороне издателя либо на стороне подписчика. Первый вид подписки (push subscription) используется при централизованном распространении, когда подписки создаются "выталкиванием" статей на те или иные серверы- подписчики, которые могут не иметь своих администраторов. Второй вид (pull subscription) предполагает известную автономию сервера-подписчика, администратор которого определяет, какие публикации ему принимать. По умолчанию все публикации создаются со статусом безопасности "неограничено", они видны и на них могут подписаться любые зарегистрированные серверы подписки. Ограниченная публикация может быть выписана только теми серверами, которые имеют на это соответствующие права.
Безопасность доступа. MS SQL Server использует в своей работе сервисы безопасности Windows NT. Напомним, что Windows NT на сегодня сертифицирована по классам безопасности С2/Е3. MS SQL Server может быть настроен на работу в одном из трех режимах безопасности. Интегрированный режим предусматривает использование механизмов аутентификации Windows NT для обеспечения безопасности всех пользовательских соединений. В этом случае к серверу разрешаются только трастовые, или аутентифицирующие, соединения (named pipes и multiprotocol). Стандартный режим безопасности предполагает, что на MS SQL Server будут заводиться самостоятельные login id и соответствующие им пароли. Смешанный режим использует интегрированную модель при установлении соединений по поименованным каналам или мультипротоколу и стандартную модель во всех остальных случаях.

MS SQL Server обеспечивает многоуровневую проверку привилегий при загрузке на сервер. Сначала идентифицируются права пользователя на установление соединения с выбранным сервером и выполнение административных функций: создание устройств и баз данных, назначение прав другим пользователям, изменение параметров настройки сервера и т.д. На уровне базы данных каждый пользователь, загрузившийся на сервер, может иметь имя пользователя (username) базы и права на доступ к объектам внутри нее.
Имеется возможность отобразить нескольких login id на одного пользователя базы данных, а также объединять пользователей в группы для удобства администрирования и назначения сходных привилегий. По отношению к объектам базы данных пользователю могут быть назначены права на выполнение различных операций над ними: чтение, добавление, удаление, изменение, декларативная ссылочная целостность (DRI), выполнение хранимых процедур, а также права на доступ к отдельным полям. Наконец, можно вообще запретить пользователю непосредственный доступ к данным, оставив за ним лишь права на выполнение хранимых процедур, в которых будет прописан весь сценарий его доступа к базе.
MS SQL Server в Internet/Intranet-приложениях. Времена статических страниц объявлений и рекламы миновали - бурное развитие бизнеса в Internet предполагает непосредственное участие клиента в совершении сделок. Говоря об использовании MS SQL Server при построении активных Internet/intranet- приложений, мы снова должны обратиться к преимуществам его тесной интеграции со всеми продуктами семейства Microsoft BackOffice. На этот раз речь пойдет об Internet Information Server (IIS).
Помимо исполнения CGI-скриптов MS IIS предоставляет разработчикам возможность создания с помощью соответствующего прикладного программного интерфейса (ISAPI) приложений в виде динамических библиотек, запуск которых происходит в ответ на команду или выбор линка на Web-странице. В отличие от
CGI, где каждый скрипт исполняется как иной, нежели Web-сервер, процесс, что быстро "съедает" ресурсы даже достаточно мощной машины при большом количестве заходов на сервер, ISAPI-приложение выполняется в адресном пространстве Web-сервера, что, естественно, повышает скорость работы и существенно экономит машинные ресурсы. В зависимости от сложности сайта и приложений, dll могут быть предзагружены одновременно с запуском сервера, либо подгружаться/выгружаться из памяти по мере необходимости. К наиболее известным средствам разработки приложений на основе ISAPI относятся входящий в состав MS IIS Internet Database Connector (IDC), а также свободно распространяемый dbWeb.
Microsoft dbWeb представляет собой шлюз между 32-битными ODBC-ресурсами и
MS IIS. dbWeb предусматривает создавание схемы, содержащей описание данных и связанных с ними Web-страниц. Он поддерживает исполнение запросов в реальном режиме времени на основе "pull"-модели публикации, позволяя тем самым создавать активные Web-страницы. Microsoft dbWeb структурно состоит из двух основных компонентов: dbWeb Service и dbWeb Administrator. dbWeb
Service является типичным ISAPI-приложением, которое обрабатывает пользовательские запросы, направляемые посетителем страницы через броузер, и управляет соединениями между броузером, ODBC-ресурсом и IIS. К функциям dbWeb Administrator относится создание HTML-страниц, содержащих результаты выполнения запросов на основе уже упоминавшихся схем, с помощью которых осуществляется управление публикуемыми данными.
IDC входит в состав MS IIS. С помощью вызовов функций ODBC API он обеспечивает прямую связь между полями HTML-формы и соответствующим ODBC- достижимым источником данных. Для доступа к данным и публикации на Web IDC использует файлы двух типов - .idc и .htx. Файл с расширением idc (см. пример) содержит всю необходимую информацию о соединении с источником данных, текст запроса, а также ссылку на соответствующий htx-файл. Файл с расширением htx (см. пример) служит шаблоном страницы, на которой будут опубликованы данные из базы, а также элементы оформления в виде статического текста, графики, видео и т. п.

SQL Web Assistant, входящий в состав MS SQL Server 6.5, в отличие от двух только что рассмотренных инструментов, не является ISAPI-приложением и работает только с MS SQL Server . Web Assistant имеет интерфейс мастера
(wizard), благодаря которому, администратор может сэкономить время по выполнению рутинного HTML-кодирования и получить готовую (в HTML-кодах) страницу, содержащую результаты опубликования произвольного запроса к базе.
Полученная страница не является активной в строгом смысле этого слова, так как публикуется при помощи push-метода, т. е. обновление происходит по инициативе сервера и не допускает обновления со стороны клиента. Однако сервер может производить обновление (перегенерацию) страницы на триггерной основе или на основе расписаний задач под управлением SQL Executive.
Active Data Objects (ADO) в достаточно грубом приближении служат VB- интерфейсом к OLE DB. Их роль видится особенно важной в развитии компонентного подхода и технологий универсального доступа к данным.
Активные серверные страницы представляют собой инструмент для эффективной разработки серверных Web-приложений, интегрирующих в своем составе HTML- код, VBScript и компоненты ActiveX. С их помощью в уже существующие наработки легко могут быть встроены фрагменты кода на VBScript или
JavaScript, а также вызовы соответствующих объектов ActiveX.
MS SQL Server 6.5 представляет собой мощный полнофункциональный сервер баз данных, отличающийся высокой производительностью, быстротой освоения и удобным интерфейсом администрирования. Под его управлением могут работать базы данных в широком диапазоне от уровня среднего звена предприятия до распределенных баз масштаба корпорации. Доступ к MS SQL Server возможен из большого числа средств разработки клиентских front-end, настольных баз данных и офисных продуктов. MS SQL Server изначально ориентирован на интеграцию с другими серверами MS BackOffice, что позволяет непосредственно охватить решение комплексных задач автоматизации хранения и обработки информации, электронной почты и документооборота, построения
Internet/intranet приложений и т. д. MS SQL Server работает в как в традиционных клиент-серверных платформах, так и в многоуровневых средах.
Заключение. В течение 80-х годов поставщики мэйнфреймов и мини- компьютеров пытались решить задачу создания систем обработки транзакций на базе языка SQL, способных обрабатывать более 1000 транзакций в секунду.
В период с 1989 по 1992 годы по таким параметрам, как производительность и отношение стоимость/производительность, первенство принадлежало патентованным системам. В частности, лучшие показатели имели компьютеры VAX компании Digital и Cyclone/CLX компании Tandem. Наилучшая производительность компьютеров компании HP была зарегистрирована для ее продукта Allbase. В то же время линия изделий AS/400 компании IBM также имела впечатляющие параметры (существенно превосходящие соответствующие характеристики изделий серии RS/6000-AIX). Характерно, что компания IBM никогда не публиковала результаты тестирования системы DB2 на своих мэйнфреймах. Конечно, СУБД DB2 имела превосходную производительность
(оценивавшуюся в сотнях транзакций в секунду), но она работала на дорогих мэйнфреймах. Вероятнее всего, IBM не хотела показывать неэкономичность своих мэйнфреймов путем публикации результатов контрольных испытаний на тесте TPC-A. Единственным поставщиком мэйнфреймов, рискнувшим опубликовать результаты тестирования, оказалась компания Unisys, система которой показала отношение стоимость/производительность примерно на уровне 45
K$/tps. В то время этот показатель вдвое превышал соответствующие показатели ее конкурентов.
В период между 1989 и 1993 годами операционные системы (SCO Unix,
NetWare, NT), системы управления базами данных (Oracle, Informix, Sybase,
Ingres) и мониторы транзакций (Tuxedo, VIS/TP, Encina), которые сегодня смело можно отнести к разряду продуктов массового потребления, резко улучшили свою производительность при решении задач обработки простых транзакций.
В 1993 году комбинация продуктов Unix/ Oracle/ Tuxedo стала лидером по отношению стоимость/производительность. Oracle, Tuxedo и операционная система Dynix, работающие на многопроцессорной системе компании Sequent, построенной на базе процессоров Intel 486, были первыми, преодолевшими барьер 1 Ktps, который продержался более десятилетия. Чуть позже СУБД Rdb и
Oracle преодолели этот барьер с несколько лучшим отношением стоимость/производительность при выполнении тестов на шестипроцессорной системе Alpha AXP компании Digital, работающей под управлением ОС VMS.
Аналогичных результатов добились и компании HP и Sun. В 1994 году лидером по отношению стоимость/производительность оказалась комбинация продуктов
Compaq/SCO Unix/Oracle. Системы компаний Digital, HP и Sun имели более высокую производительность, но и более дорогие решения.
Еще несколько лет назад о компьютерах, построенных на базе платформы
Intel (например ПК-совместимых системах компании Compaq), сравнивая их с системами компаний Digital, HP, IBM и Sun, можно было сказать, что в них отсутствует контроль четности в памяти или процессоре, что они используют сравнительно малонадежные диски, или что для них, например, отсутствует программное обеспечение для оперативной обработки транзакций (OLTP).
Естественно, такие машины, попросту говоря, не были конкурентоспособными.
Сегодня ситуация полностью изменилась. Компания Compaq является не только самым крупным в мире поставщиком серверов уровня рабочих групп, но и самым крупным поставщиком дисковых массивов уровня RAID-5. "Корпоративные" версии ее продуктов имеют мощные средства встроенной диагностики, удаленного обслуживания, интегрированные источники бесперебойного питания и даже некоторые средства резервирования узлов.
Еще два года назад наиболее отработанная технология кластеризации была ограничена операционной системой Guardian компании Tandem, системой
DBC/1024 компании Teradata и операционной системой VMS компании Digital.
Однако уже в то время практически каждый крупный поставщик вычислительных систем предлагал свои средства кластеризации на базе операционных систем
Unix и NT.

|Company|System |Thrughpu|Price/P|Database Software |
| | |t (tpmC)|erf | |
| | | |($/tpmC| |
| | | |) | |
|Compaq |ProLiant 5000 6/166 |6184.90 |$111 |Microsoft SQL |
| |4/Pentium Pro/200MHz | | |Server 6.5 |
|Digital|AlphaServer 8400 5/350 |14227.25|$269 |Oracle Rdb7 V 7.0 |
| |8/DECchip21164/350MHz | | | |
|Digital|AlphaServer 4100 5/400 |7985.15 |$174 |Oracle Rdb7 V 7.0 |
| |4/DECchip21164/400MHz | | | |
|Digital|AlphaServer 4100 5/400 |7998.63 |$152 |Sybase SQL Server |
| |4/DECchip21164/400MHz | | |1.0 |
|HP |HP 9000 Model D370 |5822.23 |$148 |Sybase SQL Server |
| |2/PA-RISC 8000/160MHz | | |1.0 |
|HP |HP 9000 Model K460 |12321.87|$187 |Sybase SQL Server |
| |4/PA-RISC 8000/180MHz | | |1.0 |
|IBM |RS6000 Power PC Server |577.07 |$243 |Sybase SQL Server |
| |J40 8/Power PC | | |1.0 |
| |604/112MHz | | | |
|SGI |Challenge XL Server |6313.78 |$479 |Informix OnLine |
| |16/R4400/250MHz | | |V.7.11.UDI |
|Sun |Ultra Enterprise 4000 |11465.93|$189 |Sybase SQL Server |
| |12/UltraSPARC/167 MHz | | |v.11.0.2 |
|Sun |Ultra Enterprise 3000 |6662.47 |$152 |Sybase SQL |
| |6/UltraSPARC/167 MHz | | | |

Кроме того, оказалось, что новое программное обеспечение существенно проще использовать. На пример, комбинация продуктов NT/Sybase обеспечивает единообразный механизм доменов наименования и секретности, графический интерфейс для администрирования и работы, а также современные инструментальные средства разработки. Хранимые процедуры SQL, генераторы приложений типа PowerBuilder, SQLWindows, Windows 4GL и другие средства значительно упрощают построение TP-приложений клиент-сервер, поддерживающих более сотни пользователей на каждом сервере. Правда, масштабирование системы для обслуживания значительно большего числа пользователей требует разделения задачи на несколько меньших серверов или использования традиционных мониторов обработки транзакций типа Tuxedo, Encina, ACMSxp или
CICS. Программное обеспечение для автоматизации построения подобного рода систем клиент-сервер может быть реализовано с помощью инструментальных средств типа Ellipse и Forte.
Таким образом, времена изменились. Полным ходом идет процесс перевода на массовую технологию систем, ранее базировавшихся на мэйнфреймах.
Программное обеспечение массового потребления установило и новые точки отсчета в области ценообразования.
Системы управления базами данных (СУБД) являются одним из наиболее распространенных классов прикладных систем для серверов, выпускаемых большинством компаний-производителей компьютерной техники. Следует отметить, что приложения, ориентированные на использование баз данных, и сами СУБД сильно различаются по своей организации. Если системы на базе файловых серверов сравнительно просто разделить по типу рабочей нагрузки на два принципиально различных класса (с интенсивной обработкой атрибутов файлов и с интенсивной обработкой самих данных), то провести подобную классификацию среди приложений баз данных и СУБД просто невозможно.
Стандартный язык реляционных СУБД (SQL) намного богаче, чем набор операций сетевой файловой системы.
Результаты испытаний многих систем на тестах TPC-A, TPC-B, TPC-C и TPC-D продемонстрировали, что на сегодняшний день имеются все предпосылки
(необходимая производительность и соответствующее ПО) для полного переноса приложений оперативной обработки транзакций и систем поддержки принятия решений с мэйнфреймов на системы, построенные на базе микропроцессоров. При этом одной из актуальных задач является выбор аппаратно-программной платформы и конфигурации системы.
Оценка конфигурации все еще остается некоторым видом искусства, но к ней можно подойти с научных позиций. Для выполнения анализа конфигурации система должна рассматриваться как ряд соединенных друг с другом компонентов. Ограничения производительности некоторой конфигурации по любому направлению (например, в части организации дискового ввода-вывода) обычно могут быть предсказаны исходя из анализа наиболее слабых компонентов.
Поскольку современные комплексы почти всегда включают несколько работающих совместно систем, точная оценка полной конфигурации требует ее рассмотрения как на макроскопическом уровне (уровне сети), так и на микроскопическом (уровне компонентов или подсистем).

1.2 Исследование предметной области

В последние годы экономическая система нашей страны переживает бурное развитие. Несмотря на существующие недостатки российского законодательства, ситуация неуклонно меняется к лучшему. Прошли времена, когда можно было легко зарабатывать на спекулятивных операциях с валютой и мошенничестве.
Сегодня все больше банков делает ставку на профессионализм своих сотрудников и новые технологии.
Трудно представить себе более благодатную почву для внедрения новых компьютерных технологий, чем банковская деятельность. В принципе почти все задачи, которые возникают в ходе работы банка достаточно легко поддаются автоматизации. Быстрая и бесперебойная обработка значительных потоков информации является одной из главных задач любой крупной финансовой организации. В соответствии с этим очевидна необходимость обладания вычислительной сетью, позволяющей обрабатывать все возрастающие информационные потоки. Кроме того, именно банки обладают достаточными финансовыми возможностями для использования самой современной техники.
Однако не следует считать, что средний банк готов тратить огромные суммы на компьютеризацию. Банк является прежде всего финансовой организацией, предназначенной для получения прибыли, поэтому затраты на модернизацию должны быть сопоставимы с предполагаемой пользой от ее проведения. В соответствии с общемировой практикой в среднем банке расходы на компьютеризацию составляют не менее 17% от общей сметы годовых расходов.
Интерес к развитию компьютеризированных банковских систем определяется не желанием извлечь сиюминутную выгоду, а, главным образом, стратегическими интересами. Как показывает практика, инвестиции в такие проекты начинают приносить прибыль лишь через определенный период времени, необходимый для обучения персонала и адаптации системы к конкретным условиям. Вкладывая средства в программное обеспечение, компьютерное и телекоммуникационное оборудование и создание базы для перехода к новым вычислительным платформам, банки, в первую очередь, стремятся к удешевлению и ускорению своей рутинной работы и победе в конкурентной борьбе.
Информатизация банка не может быть успешной и без предварительного анализа и моделирования. Даже покупка готового продукта предполагает понимание особенностей своего банка и информационных возможностей приобретаемой системы.
Создавая информационную модель банка, следует прежде всего обратить внимание на объекты (сущности) системы и их отношения, направление и характер потоков информации, которыми обмениваются эти объекты (а также на вид и характер носителей этой информации – бумажные документы, телефонные и электронные сообщения и пр.), и на операции, которые производятся над информационными потоками, порождая, поглощая и видоизменяя их.
Информационная система банка – настолько сложная и переменчивая структура, что изначально ставить задачу точного и однозначного ее описании и моделирования не только нереалистично, но и методически неверно.
Необходимо с самого начала ориентироваться на создание гибкой модели в условиях частичной неопределенности. Гибкость и легкость перестраивания модели согласно ежедневно выявляющимся требованиям банковской системы – свидетельство высокого качества разработки, залог ее успешного внедрения и долгой жизни.
Современные технические средства сделали вполне реализуемой давнюю мечту специалистов о создании систем, действующих по «безбумажной» технологии. Но переход на такую технологию обработки информации не означает полного отказа от бумажных документов. Для нужд обмена с партнерами, для работы с аудиторами и контролирующими организациями, для документарной фиксации внутрибанковского оборота подготовка твердых копий, заверенных подписями ответственных лиц, остается необходимой и сейчас. Тем не менее происходит смена акцентов, и становым хребтом информационной системы становятся данные в электронной форме, а необходимая документация продуцируется как отражение электронных данных на бумажных носителях. Только в отдельных случаях
(например, при введении "электронной подписи"), когда юридический статус электронного сообщения равен статусу бумажного документа, удается полностью отказаться от бумажного документооборота. Преимущества безбумажной технологии всегда были достаточно очевидны, а сегодня стали практически реализуемыми и экономически эффективными.
Применение безбумажных технологий ставит проблему оптимизации распределения информации между бумажными и электронными носителями. С этих позиций банковскую информацию можно разделить на три класса:
- данные, участвующие в расчетах (они обязательно должны быть представлены в электронной форме);
- часто используемая и поддающаяся формализации дополнительная информация

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

(идентификационные карточки, съемные блокирующие устройства и т.п.).
2) Предоставление полномочий, привилегий и прав доступа к АБС на уровне отдельного пользователя (сотрудника или клиента банка).
3) Средства централизованного обнаружения несанкционированных попыток проникнуть к ресурсам АБС, дающие возможность своевременно принять соответствующие меры.
4) Защита данных при их передаче по каналам связи (особенно актуально при использовании открытых каналов связи, например сети Internet). Здесь возможно использование "цифровой электронной подписи" и других криптографических методов.
5) Надежность системы. Отказы отдельных элементов АБС не должны приводить к ее полному выходу из строя. Кроме того, необходимо обеспечить высокую устойчивость работы АБС в условиях дестабилизирующих факторов (например помех в линиях связи или ошибочных действий персонала банка).
6) Наличие средств восстановления при сбоях. В АБС должны быть предусмотрены средства для прогноза, фиксации и локализации различных нештатных ситуаций и отказов оборудования (таких как: повреждений и перегрузок каналов связи; перегрузок устройств внешней памяти; нарушения целостности БД; попыток несанкционированного доступа в систему и т.д.)
7) Возможность адаптации к изменениям финансового законодательства или структуры банка и другим событиям.
8) Возможность работы в режиме реального времени. В настоящее время системы типа OLTP (On-line Transaction Processing) становятся все более распространенными при создании АБС. Внедрение систем OLTP требует от банка весьма больших инвестиций, но преимущества таких систем оправдывают все затраты.
Программные Платформы и Базы Данных. Среди операционных систем для АБС лидирует связка DOS + Novell (в качестве программной платформы DOS на рабочих станциях и операционная система Novell NetWare на файл-серверах) –
47,5% банков предпочитают именно такую, наиболее доступную в финансовом отношении конфигурацию. На втором месте среди операционных систем, в
«угрожающей близости» к Novell NetWare находится Windows NT, ее предпочитают 43,7% банков. Поскольку третье место занимает связки операционных систем Windows/Windows'95 - 32,2%, то здесь явно заметен качественный рост влияния продуктов фирмы Microsoft на развитие банковских технологий. Всего лишь четвертое место с показателем 29,0% занимает ОС
UNIX. Хотя по динамике изменений в 1994 – 1996 гг. казалось, что разрыв между вторым местом UNIX и бессменно лидирующей связкой DOS + Novell
NetWare неизбежно сократится.
Собственно эта тройка (четверка) операционных систем – Novell, Windows
(NT), UNIX – и составляет большинство программных платформ в российских банках, поскольку идущие на пятом-шестом местах OS/400 (на аппаратных средствах AS/400) и ОS/2 занимают незначительные доли рынка: 4,9 и 3,3% соответственно. На последнем, седьмом месте находится VAX/VMS с минимальной долей – 0,5%.
Соответственно распределению предпочтений по ОС среди СУБД лидирует
«родной» для Novell NetWare менеджер записей Btrieve – 42,6% банков предпочитают именно эти технологии. Второе место с небольшим отрывом занимает профессиональная СУБД Oracle – 35,5%.
Два явных лидера среди СУБД Btrieve и Oracle – опережают в три-четыре раза идущую на третьем месте Sybase (11,5%) и в пять-шесть раз занимающую четвертое место Informix (7,7%).
Эти соотношения позволяют сделать грубую оценку возможного перехода банков пользователей технологий на основе Btrieve на банковские системы нового поколения на основе СУБД Sybase без замены фирмы-разработчика. Так,
«новые Sybase-АБС» подготавливаются к промышленному внедрению в основном тремя фирмами – лидерами рынка: «Диасофт», «R-Style Software Lab.» и
«Кворум», чьи базовые системы сегодня реализованы на основе Btrieve.
Соотношение 42,6% против 11,5% говорит о том, что примерно одна пятая часть банков – пользователей Btrieve-AБC в перспективе может перейти на Sybase-
АБС.
Особого комментария заслуживает пятое место Microsoft SQL Server с небольшим показателем 4,9%. Огромная популярность операционной среды
Windows в сфере банковских технологий, казалось бы, могла обеспечить этой
«дочерней СУБД» более высокие цифры. Но здесь важно следующее: сам инструментарий MS SQL так интенсивно модернизируется и меняется, что серьезные финансовые системы типа АБС, требующие высокой надежности и сделанные на его основе, просто не успевают пройти необходимый цикл тестирования, отладки и обкатки. Конечно же, это существенно сдерживает возможности распространения финансовых приложений на основе Microsoft SQL
Server.
Шестое место занимает СУБД Progress – ее предпочитают 3,8% банков, далее с малыми значениями идут Interbase – 2,2%, Gupta/Centura – 1,6%, DB/2 –
1,1%, Ingress – 0,5%.
Примерно один из девяти банков предпочитает работать сразу на нескольких
СУБД. Если Windows NT и Windows'95 считать как одну и ту же ОС, то выходит, что примерно каждый третий российский банк работает в гетерогенных программных средах.
Известность фирм-разработчиков. Расчет рейтинговой известности фирм давно известен и неоднократно публиковался. И хотя его методика не совсем совершенна, только ее постоянство и неизменность позволяют корректно сравнивать показатели, полученные в разное время.
Основой расчета рейтинга известности и других сравнительных показателей являются ответы банков на вопросы анкеты об используемых программных продуктах, планах по модернизации АБС и мнения отдельных банкиров о состоянии и развитии рынка банковских программных технологий.

(по материалам третьего форума разработчиков)
|Разработчики |Испол|Извес|Лучша|Персп|Хотел|Хотят|Рейти|
|АБС |ьзуют|тност|я |ектив|и бы |купит|нг |
| | |ь | |ная |узнат|ь |Извес|
| | | | | |ь | |тност|
| | | | | | | |и |
|0 |1 |2 |3 |4 |5 |6 |7 |
|R-Style Soft. |37 |141 |37 |22 |19 |14 |380 |
|Lab. | | | | | | | |
|Диасофт |22 |153 |31 |13 |11 |12 |320 |
|ФОРС |6 |58 |21 |19 |10 |5 |170 |
|ПрограмБанк |13 |69 |4 |4 |2 |2 |117 |
|ЦФТ |10 |37 |9 |9 |5 |7 |112 |
|Кворум |13 |37 |6 |3 |1 |5 |92 |
|Инверсия |9 |38 |3 |2 |0 |1 |68 |
|Асофт |4 |19 |2 |0 |0 |0 |31 |
|МИМ-Технология |6 |3 |3 |1 |1 |1 |26 |
|Midas-Kapiti |3 |7 |3 |1 |4 |0 |25 |
|CSBI EE |2 |9 |1 |1 |2 |1 |21 |
|Temenos Systems|0 |1 |1 |3 |3 |0 |12 |
|Мебиус |4 |1 |0 |0 |0 |0 |9 |
|Канопус |2 |2 |1 |0 |0 |0 |8 |
|Киевский ОДБ |4 |0 |0 |0 |0 |0 |8 |
|БИС |1 |4 |0 |0 |0 |0 |6 |
|Сибирский Банк |0 |1 |1 |0 |0 |1 |5 |
|UniSAB |1 |1 |1 |0 |0 |0 |5 |

Примечания:
Рейтинг известности = “2” + “5” + 2*(“1” + “3” + “4” + “6”);

Заметно первое изменение на Олимпе банковской автоматизации; поколеблено единоличное лидерство фирмы «Диасофт», длившееся с начала 1994 г. до первой половины 1997 г. включительно (завидное постоянство!). Теперь она занимает второе место. Первую строчку с отрывом в 15,8% от второго места (380 баллов против 320) заняла «R-Style Software Lab.». Каждая из этих лидирующих фирм почти вдвое опережает идущую на третьем месте фирму ФОРС (170 баллов) и почти втрое следующих за ними – фирму «ПрограмБанк» (117 баллов – 4 место) и ЦФТ (112 баллов – 5 место).
Еще три фирмы – «МИМ-Технология», «Канопус», БИС – занимают неплохие места; девятое, четырнадцатое и шестнадцатое соответственно. Всего банкиры при ответах на вопросы называли 41 фирму.
Понятно, что абсолютная известность определяется как маркетинговой активностью фирмы, так и распространенностью и перспективностью ее программных технологий. Для характеристики потенциала фирм к расширению бизнеса, был введен дополнительный показатель – «Относительный рейтинг известности», показывающий усредненные (в пересчете на один банк) показатели известности фирмы.

|Разработчики |Испол|Извес|Лучша|Персп|Хотел|Хотят|Рейти|
|АБС |ьзуют|тност|я |ектив|и бы |купит|нг |
| | |ь | |ная |узнат|ь |Извес|
| | | | | |ь | |тност|
| | | | | | | |и |
|0 |1 |2 |3 |4 |5 |6 |7 |
|ФОРС |100% |9,67 |3,50 |3,17 |1,67 |0,83 |18,83|
|Диасофт |100% |6,95 |1,41 |0,59 |0,50 |0,55 |10,00|
|ЦФТ |100% |3,70 |0,90 |0,90 |0,50 |0,70 |6,70 |
|R-Style |100% |3,81 |1,00 |0,59 |0,51 |0,38 |6,30 |
|ПрограмБанк |100% |5,31 |0,31 |0,31 |0,15 |0,15 |6,23 |
|Инверсия |100% |4,22 |0,33 |0,22 |0,00 |0,11 |4,89 |
|Кворум |100% |2,85 |0,46 |0,23 |0,08 |0,38 |4,00 |
|МИМ |100% |0,5 |0,5 |0,17 |0,17 |0,17 |1,50 |

В относительном рейтинге картина значительно изменилась – на первое место с большим отрывом от других вышла фирма ФОРС (18,83 балла). Вторую строчку очень уверенно занимает «Диасофт» (10,00), далее идет весьма плотная по показателям группа – ЦФТ (6,70), «R-Style Software Lab.» (6,30) и
«ПрограмБанк» (6,23).
Привлекательность АБС. Такой показатель, как «коэффициент привлекательности» рассчитывается по результатам опроса банков – пользователей каждой фирмы. При расчете учитывались ответы банков на вопросы: «Удовлетворяет ли Ваш банк используемая автоматизированная банковская система?» и «Собирается ли Ваш банк и ближайшее время менять или модернизировать используемую АБС (отметьте и при необходимости расшифруйте нужные строки)?» – с вариантами ответов. В расчетах также учитывались значения графы “6” табл. 1 (число банков, собирающихся перейти на АВС каждой из фирм).
Поскольку разные представители одного и того же банка могли отвечать на один и тот же вопрос по разному, а в одной анкете респондент отметил даже несколько позиций, то для устранения некорректности вычислений по каждой фирме были рассчитаны максимальное и минимальное значения коэффициента.
При расчете максимального коэффициента все «многозначности» в ответах представителей одного банка трактовались «в пользу» фирмы-разработчика, а при расчете минимального – «против».
Вычисление такого диапазона значений, пожалуй, более корректно, чем вычисление методической погрешности по одному Банку. Поскольку величина расчетной погрешности по большинству показателей меньше, чем разница минимального и максимального значений, введение диапазона значений позволяет более корректно учитывать многозначные ответы.
Смысл этого коэффициента относительно несложен. Если все пользователи какой-либо АБС вполне удовлетворены этой системой, собираются обновлять версии или ни чего не собираются в ней менять, то эта АБС еще будет жить на рынке и ее «коэффициент привлекательности» равен единице. Если же какие- либо банки собираются переходить на эту ЛБС, то у нее есть перспективы дополнительного развития, и ее «коэффициент привлекательности» выше единицы. А если все пользователи отрицательно оценивают удовлетворенность системой и собираются закупать другую российскую или зарубежную разработку, то данная АБС морально устаревает и ее «коэффициент привлекательности» близок к минус единице.
Значения коэффициента, близкие к плюс единице, можно считать признаком поступательного развития как фирмы в целом, так и ее банковских разработок в частности. Любые положительные значения «коэффициента привлекательности» считаются вполне приемлемыми, а отрицательные – служат сигналом неблагополучия. Близкие к нулю значения позволяют говорить о некотором снижении числа банков-пользователей.

|Разработчик|О|Удовлетворяет |Закупка/модернизация |Привлек|
|и |п|ли АБС? |АБС |ательно|
| |р| | |сть |
| |о| | | |
| |ш| | | |
| |е| | | |
| |н| | | |
| |о| | | |
| | |Да|Ск|Не|Ск|Не|Не|Но|Др|За|До|До|Ку|мах|min|
| | | |ор|по|ор|т |т |ву|уг|ру|ра|ра|пи| | |
| | | |ее|лн|ее| | |ю |ую|бе|бо|бо|ть| | |
| | | |Да|ос|не| | |ве|ро|ж.|тк|тк|эт| | |
| | | | |ть|т | | |рс|с.|АБ|а |а |у | | |
| | | | |ю | | | |ию|АБ|С |мо|АБ|АБ| | |
| | | | | | | | | |С | |ду|С |С | | |
| | | | | | | | | | | |ле| | | | |
| | | | | | | | | | | |й | | | | |
|0 |1|2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|13|14 |15 |
|Форс |6|1 |3 |3 |0 |3 |1 |4 |0 |0 |3 |0 |5 |1,4|1,2|
| | | | | | | | | | | | | | |0 |0 |
|ЦФТ |1|1 |5 |3 |1 |1 |2 |6 |1 |1 |2 |0 |7 |1,1|0,9|
| |0| | | | | | | | | | | | |8 |7 |
|R-Style |3|2 |17|16|1 |1 |3 |34|2 |2 |11|1 |14|1,0|0,8|
| |7| | | | | | | | | | | | |0 |6 |
|Midas-Kapit|3|2 |0 |1 |0 |0 |0 |2 |0 |0 |1 |0 |0 |1,0|0,8|
|i | | | | | | | | | | | | | |0 |8 |
|Кворум |1|0 |8 |4 |2 |0 |5 |6 |0 |0 |3 |0 |5 |0,9|0,9|
| |3| | | | | | | | | | | | |9 |0 |
|Диасофт |2|2 |8 |9 |2 |1 |6 |13|3 |1 |7 |2 |12|0,9|0,8|
| |2| | | | | | | | | | | | |8 |2 |
|МИМ |6|1 |3 |2 |0 |0 |0 |4 |0 |0 |1 |0 |1 |0,9|0,9|
| | | | | | | | | | | | | | |0 |0 |
|Мебиус |4|0 |1 |3 |0 |0 |2 |2 |0 |0 |0 |0 |0 |0,6|0,6|
| | | | | | | | | | | | | | |3 |3 |
|ПрограмБанк|1|0 |5 |5 |2 |2 |4 |7 |3 |0 |1 |0 |2 |0,5|0,3|
| |3| | | | | | | | | | | | |0 |2 |
|Инверсия |9|0 |3 |4 |1 |1 |0 |6 |5 |0 |2 |0 |1 |0,2|-0,|
| | | | | | | | | | | | | | |5 |01 |
|АСофт |4|0 |1 |2 |0 |1 |0 |3 |2 |1 |0 |0 |0 |0,1|-0,|
| | | | | | | | | | | | | | |3 |13 |
|Собственная|5|5 |10|30|8 |6 |7 |8 |15|1 |19|21|0 |- |- |
| |9| | | | | | | | | | | | | | |
|Киевский |4|0 |0 |0 |4 |0 |0 |0 |3 |0 |0 |1 |0 |-0,|-0,|
|ОДБ | | | | | | | | | | | | | |91 |91 |

В первую очередь обращает внимание высокая плотность семи верхних результатов. Формально третье место «R-Style Software Lab.» и формально шестое место фирмы «Диасофт» разделяют всего 0,02 по максимальному значению и 0,04 – по минимальному; при этом пересечение диапазонов для этих фирм –
0,12. Кроме того, заметим, что среднее по всем фирмам значение
«коэффициента привлекательности» весьма велико. Следовательно, можно утверждать, что банки предпочитают в тяжелые времена технологического перехода к новым правилам бухгалтерского учета решать возникающие сложные проблемы со своими разработчиками, а не заменять АБС на «самую мощную и полно функциональную».
Стратегии развития АБС. Семилетняя история автоматизации российских банков позволяет узнать: есть ли общие черты в путях автоматизации российских банков. При описании базовых стратегий технологического развития банков (в части программных решений) удобно использовать классификацию, предложенную В. Колсаноным (в прошлом – начальник управления банковских технологий Тверьуниверсалбанка). Любая стратегия технологического развития банка подразумевает формулирование функциональных и экономических требований (с различной степенью детальности) к системе автоматизации и соответствующую реализацию этих требовании.
Собственная разработка. Этот этап в развитии автоматизированных технологий в разное время был пройден подавляющим большинством российских банков, поэтому ему стоит уделить внимание. В этот же сегмент включены так называемые «эксклюзивные» разработки, выполненные под заказ одного банка и не поддающиеся тиражированию. Основные признаки подобной стратегии:
- первыми автоматизируются исторически «базовые» функции банковской системы – бухгалтерия и расчетно-кассовое обслуживание, существующие по крайней мере в двух-трех десятках тиражируемых российских систем;
- не разделены служба разработки и служба эксплуатации банковской системы, не выделены моменты передачи версий банковской системы в эксплуатацию, и, как правило, понятие «версия АБС» вообще не приемлемо;
- неполноценное документирование системы (частичное наличие проектной и эксплутационной документации) либо полное отсутствие документации.
- С точки зрения специалистов, имеющих опыт создания и внедрения АБС в крупных и средних банках, разумными основаниями для собственной разработки могут являться:
- интеграция нескольких систем при числе автоматизированных рабочих мест в банке более 200;
- разработка целых модулей системы при числе автоматизированных рабочих мест в банке более 500;
- наличие у банка уникальных бизнес требований и уникальной стратегии информатизации, удовлетворить которые не в состоянии ни специализированные системные интеграторы, ни разработчики промышленных тиражируемых решений. В этом случае требования и стратегия должны быть явно сформулированы во внутренних документах банка с соответствующим контролем (аудитом) их реализации;
- столь динамичное развитие банка, что бизнес требования не могут быть выдвинуты даже на год вперед. В этом случае разрабатываемая система является только макетом будущей информационной системы. Сегодня это уже в прошлом: наступает этап стабильного развития банковской системы.
С точки зрения специалистов, имеющих опыт профессионального банковского консалтинга, помимо приведенных причин, собственная банковская разработка может быть оправдана:
- для небольшого по количеству персонала одно-филиального банка с небольшим количеством ежедневных операций – «домашнего» банка крупной промышленной либо торговой компании, консорциума, холдинга (примеров тому довольно много);
- как связующее звено для автоматизации головного офиса многофилиального банка при установке однотипных тиражируемых решений в филиалах и отделениях;
- для узкоспециализированного банка со значительным преобладанием операций, не характерных для банковского сообщества в целом;
- для крупного универсального банка в части автоматизации передовых финансовых технологий, пока еще недостаточно освоенных российским банковским рынком. При отсутствии адекватного предложения на рынке тиражируемых решений такая разработка бывает оправданной в части указанных финансовых технологий вплоть до их сопряжения с основной AБC.

Эта причина становится все менее определяющей, поскольку промышленные решения ведущих российских разработчиков быстро развиваются в функциональном отношении;
- для среднего банка, имеющего целью стать «законодателем технологической моды» в области автоматизации финансовых операций при сильной динамике развития банковского рынка в целом (например, Инком банк, Кредо банк,