Независимая организация Transaction Processing Council (ТРС - совет по средствам обработки транзакций) опубликовала серию собственных тестов (ТРС-А, ТРС-В и ТРС-С), чем только подогрела интерес к данной области со стороны поставщиков.

К концу 90-х годов реляционные базы данных на UNIX-серверах высокого класса преодолели рубеж 1000 транзакций в секунду. Системы клиент/сервер, включающие реляционные СУБД, стали признанной архитектурой для реализации OLTP-приложений. Таким образом, рассматривавщийся ранее как непригодный для оперативной обработки транзакций , язык SQL вырос до промышленного стандарта в области построения OLTP-приложений.

SQL и базы данных для рабочих групп

Стремительный рост популярности локальных сетей на базе персональных компьютеров в 80-е и 90-е годы создал предпосылки для распространения новой архитектуры систем управления базами данных масштаба подразделений, или рабочих групп . Первоначально СУБД, предназначенные для этого сегмента рынка, работали под управлением операционной системы OS/2 компании IBM. Даже СУБД SQL Server, играющая сейчас ключевую роль в стратегии компании Microsoft, связанной с платформой Windows, в свое время дебютировала как продукт для OS/2. В середине 90-х годов фирма Novell тоже изо всех сил старалась сделать свою сетевую операционную систему NetWare привлекательной платформой для серверов баз данных рабочих грулп. На заре эры локальных сетей NetWare прочно утвердилась в качестве доминирующей операционной системы для файл-серверов и серверов печати. Объединившись с Oracle и другими разработчиками, Novell рассчитывала распространить свое лидерство и на серверы рабочих групп.

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

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

Сегодня SQL стал общепризнанным стандартом в качестве языка работы с базами данных для рабочих групп. За SQL Server последовали Oracle, Informix, Sybase, DB2 и многие другие известные СУБД, работающие на платформе Windows NT/Windows 9х. Реляционные СУБД на базе Windows - это второй по величине сегмент рынка СУБД, причем наиболее быстрорастущий. Эти СУБД непрерывно внедряются в рынок систем разработки корпоративных баз данных, медленно, но верно вытесняя своих UNIX-конкурентов.

SQL и хранилища данных

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

Хотя теоретически реляционные базы данных без труда можно использовать и для оперативной обработки транзакций, и для поддержки принятия решений, на практике возникает ряд очень важных проблем. Рабочая нагрузка OLTP-систем состоит из коротких транзакций, выполняемых с большой частотой, причем время реакции системы должно быть минимальным. В противоположность этому запросы, связанные с принятием решений (например, Какова средняя стоимость заказов для данного региона? или Насколько увеличился сбыт продукции по сравнению с аналогичным периодом прошлого года? ), могут требовать сканирования огромных таблиц и выполняться минутами или даже часами. Если экономист-аналитик попытается выполнить подобный запрос во время пика деловых транзакций, это может вызвать серьезное снижение производительности всей системы, что для оперативной обработки транзакций просто недопустимо. Еще одну проблему составляет размещение данных, необходимых для получения ответов на вопросы из области делового анализа: они могут быть распределены между многими базами данных, причем, как правило, еще и поддерживаемыми разными СУБД и на разных компьютерных платформах.

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

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

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

Система на базе мэйнфрейма

Рис. 3.6. Концепция хранилищ данных

Для удовлетворения специфических потребностей приложений, работающих с хранилищами данных и часто назьшаемых приложениями для оперативной аналитической обработки данных (OLAP - Online Analytical Processing), стали появляться специализированные СУБД. Их производительность оптимизирована для выполнения сложных запросов, связанных только с выборкой данных. Они поддерживают расширенный набор статистических функций и имеют встроенные средства для других распространенных типов анализа данных, например хронологического. За счет заблаговременного вычисления статистических данных эти СУБД могут существенно ускорять получение средних и суммарных величин. Среди специализированных СУБД есть и такие, которые не используют язык SQL, но большинство использует его, благодаря чему получил распространение еще один сопутствующий термин - реляционная оперативная аналитическая обработка данных (ROLAP - Relational Online Analytical Processing). Как и во многих других сегментах рынка, язык SQL доказал свои преимущества и де-факто стал стандартным средством выполнения запросов А сегмент рынка СУБД, занимаемый хранилищами данных, - это уже ни много ни мало миллиард долларов, и реляционные СУБД твердо закрепили на нем свои позиции.