|
|
|
В предыдущей статье данного цикла, опубликованной в № 4’2000 нашего журнала, мы рассмотрели наиболее популярные настольные СУБД, такие как dBase, Paradox, FoxPro, Access, MSDE. Настоящая статья посвящена серверным СУБД — Oracle, Informix, DB2, Sybase, Microsoft SQL Server.
Прежде чем обратиться к конкретным продуктам, следует рассмотреть, что представляет собой архитектура «клиент-сервер», чем серверные СУБД отличаются от настольных и каковы общие черты современных серверных СУБД.
Как было отмечено в предыдущей статье, обработка данных с помощью мэйнфреймов и мини-ЭВМ, популярная в 70-е годы, имела свои преимущества, в определенной степени утраченные позже, в эпоху персональных компьютеров и настольных СУБД. В частности, одним из таких преимуществ была централизация хранения и обработки данных. Однако повсеместное увлечение настольными СУБД и их сетевыми версиями, вызванное доступностью и дешевизной как самого программного обеспечения, так и его эксплуатации, заставило многих пользователей на долгие годы забыть о «мэйнфреймовой» модели вычислений.
Мы уже говорили о том, что недостатки настольных СУБД обычно проявляются не сразу, а лишь в процессе длительной эксплуатации, когда объем хранимых данных и число пользователей становятся достаточно велики — это приводит к снижению производительности приложений, использующих такие СУБД.
Поскольку настольные СУБД не содержат специальных приложений и сервисов, управляющих данными, а используют для этой цели файловые сервисы операционной системы, вся реальная обработка данных в таких СУБД осуществляется в клиентском приложении, и любые библиотеки доступа к данным в этом случае также находятся в адресном пространстве клиентского приложения. Поэтому при выполнении запросов данные, на основании которых выполняется такой запрос (это может быть одна или несколько таблиц целиком либо, если повезет, один или несколько индексов и выбранные с их помощью части таблиц), должны быть доставлены в то же самое адресное пространство клиентского приложения. Это и приводит к перегрузке сети при увеличении числа пользователей и объема данных, а также грозит иными неприятными последствиями, например разрушением индексов и таблиц. Недаром до сих пор столь популярны утилиты для «ремонта» испорченных файлов настольных СУБД.
Известно много случаев, когда для решения подобных проблем закупалось дорогое сетевое оборудование с целью увеличения пропускной способности сети, а также применялись иные «ухищрения» наподобие хранения метаданных или наиболее часто используемых данных в клиентских приложениях или просто на локальных жестких дисках. Нередко также применялся подход, приводящий к децентрализации хранения данных. Типичный пример подобного подхода — создание нескольких однотипных локальных баз данных, например для различных подразделений компании или для разных временных периодов (лет, кварталов, месяцев), что облегчало работу, связанную с вводом данных, но повышало стоимость их статистической обработки и анализа — в этом случае нужно было обрабатывать данные из разных источников. Однако все эти меры позволяли лишь отложить на время решение проблемы снижения производительности, но не устраняли главного недостатка информационных систем, основанных на настольных СУБД, — обработки данных в клиентском приложении.
Радикальным решением проблемы сетевого трафика и иных проблем, возникающих при увеличении объема данных и числа пользователей, стал переход к архитектуре «клиент-сервер», позаимствовавшей многие достоинства старой «мэйнфреймовой» модели вычислений, в частности централизацию хранения и обработки данных.
Принцип централизации хранения и обработки данных является базовым принципом архитектуры «клиент-сервер». Для его реализации используется так называемый сервер баз данных, выполненный как приложение или сервис операционной системы, и только он может реально манипулировать файлами, в которых хранятся данные, — для клиентских приложений эти файлы абсолютно бесполезны (и, при правильной организации доступа пользователей к файлам в сети, вообще не должны быть доступны).
Сервер баз данных осуществляет целый комплекс действий по управлению данными. Основными его обязанностями являются:
В качестве рабочего места пользователя может быть использован обычный персональный компьютер, что позволяет не отказываться от привычной рабочей среды. Иными словами, в простейшем случае клиент-серверная информационная система состоит из двух основных компонентов:
Существуют и более сложные реализации архитектуры «клиент-сервер», например многозвенные информационные системы с использованием серверов приложений, реализующих бизнес-логику и осуществляющих обработку данных. Однако обсуждение архитектуры таких систем находится за пределами данного обзора — о подобных системах мы, возможно, поговорим в конце данного цикла.
Информационные системы, использующие архитектуру «клиент-сервер», обладают серьезными преимуществами по сравнению с их аналогами, созданными на основе сетевых версий настольных СУБД. Ниже будут рассмотрены наиболее важные из них.
Одним из важнейших преимуществ архитектуры «клиент-сервер» является снижение сетевого трафика при выполнении запросов. Hапример, при необходимости выбора пяти записей из таблицы, содержащей миллион записей, клиентское приложение посылает серверу запрос, который сервером анализируется на корректность и, если запрос корректен, компилируется, оптимизируется и выполняется. После этого результат запроса (те самые пять записей, а вовсе не вся таблица) передается обратно клиенту. При этом, формулируя запрос, можно не задумываться о том, есть ли в базе данных индексы, способные облегчить поиск нужных записей, — если они есть, то они будут использованы сервером, а если нет,запрос все равно будет выполнен, хотя, возможно, это займет больше времени, чем при использовании индексов. Но в любом случае — есть индексы или нет — в клиентское приложение передается только результат запроса, и в этом случае сетевой трафик не зависит ни от их наличия, ни от числа записей в таблицах, к которым произведен запрос.
Вторым преимуществом архитектуры «клиент-сервер» является возможность хранения бизнес-правил (например, правил ссылочной целостности или ограничений на значения данных) на сервере, что позволяет избежать дублирования кода в различных клиентских приложениях, использующих общую базу данных. Кроме того, в этом случае любое редактирование данных, в том числе и редактирование средствами, не предусмотренными разработчиками информационной системы (например, различными утилитами администрирования сервера), может быть произведено только с учетом этих правил. Если последние версии некоторых настольных СУБД и способны хранить ограничения на значения данных либо тексты SQL-запросов, триггеры и хранимые процедуры в них, как правило, отсутствуют — их просто некому выполнять. Исключением здесь, пожалуй, является только Microsoft Data Engine, но, как мы уже говорили в предыдущей статье данного цикла, отнести к настольным эту СУБД можно весьма условно — фактически MSDE представляет собой локальный сервер баз данных, обладающий всеми характерными для серверной СУБД атрибутами, включая отдельный серверный процесс.
В первой статье данного цикла (см. КомпьютерПресс №3’2000) мы уже упоминали о том, что для описания серверных бизнес-правил в наиболее типичных ситуациях (например, при реализации связей master/detail) нередко используются так называемые CASE-средства (CASE означает Computer-Aided System Engineering) для создания диаграмм «сущность-связь». Эти инструменты позволяют описать подобные правила на уровне логической и физической моделей данных без какого бы то ни было программирования, а затем сгенерировать код соответствующих серверных объектов — триггеров, хранимых процедур, серверных ограничений. В этом случае клиентские приложения будут избавлены от значительной части кода, связанного с реализацией бизнес-правил непосредственно в приложении. Отметим также, что часть кода, связанного с обработкой данных, также может быть реализована в виде хранимых процедур сервера, что позволяет еще больше «облегчить» клиентское приложение, а это означает, что требования к рабочим станциям могут быть не столь высоки. Это в конечном итоге снижает стоимость информационной системы даже при использовании дорогостоящих серверной СУБД и аппаратного обеспечения.
Помимо перечисленных выше трех преимуществ следует также отметить, что современные серверные СУБД обладают широкими возможностями управления пользовательскими привилегиями и правами доступа к различным объектам базы данных. Как правило, в базе данных хранятся сведения о ее пользователях, их паролях и привилегиях, а каждый объект базы данных принадлежит какому-либо пользователю. Владелец объекта может предоставить другим пользователям право использовать его тем или иным способом (например, позволить читать из него данные какому-либо другому пользователю). Большинство серверных СУБД поддерживает так называемые роли, представляющие собой совокупность прав на доступ к тем или иным объектам базы данных. В этом случае каждый пользователь может иметь одну или несколько ролей и соответственно определенные в этих ролях привилегии.
Современные серверные СУБД обладают также широкими возможностями резервного копирования и архивации данных, а нередко и оптимизации выполнения запросов. Они также, как правило, предоставляют возможность параллельной обработки данных, особенно в случае использования многопроцессорных компьютеров в качестве сервера баз данных.
Итак, мы рассмотрели преимущества архитектуры «клиент-сервер» и убедились, что эта технология решает многие проблемы, возникающие при использовании настольных СУБД. Однако перед тем, как обсуждать наиболее популярные серверные СУБД, давайте обратим внимание на то, какими способами решается проблема модернизации устаревших информационных систем, основанных на настольных СУБД, с целью перехода к архитектуре «клиент-сервер», и с какими проблемами можно при этом столкнуться.
С проблемой модернизации устаревших информационных систем рано или поздно сталкивается почти каждый разработчик или IT-менеджер. В нашей стране все еще нетрудно встретить банковские системы, использующие dBase, а также относительно свежие коммерческие разработки, созданные с помощью Clipper, средством обмена данными которым служат отнюдь не Internet и не сетевые протоколы, а курьер с дискетами и электричка (это вовсе не всегда происходит из-за неосведомленности разработчиков — просто у их клиентов нет и в ближайшее время не будет денег на приличное оборудование и соответствующую инфраструктуру). Именно поэтому мы полагаем, что проблема модернизации информационных систем в России еще долго будет оставаться актуальной.
В каждой организации, переживающей процесс модернизации информационной системы, возникают свои проблемы. В одной пользователи требуют сохранить привычный пользовательский интерфейс (те, кто давно программирует на Delphi, наверное, помнят популярную задачу из серии «угоди пользователю, привыкшему к DOS», — как в форме ввода данных заставить клавишу Enter делать то, что обычно делает клавиша Tab); в другой нужно суметь не просто перенести в новую базу унаследованные данные, но и изменить их в соответствии с вновь возникшими потребностями (например, исправить ошибки, допущенные много лет назад при проектировании данных, или объединить данные из нескольких разных источников); в третьей организации сохранилось и используется большое количество отчетов, созданных с помощью старой настольной СУБД, и нужно обеспечить возможность их использования в новой информационной системе; в четвертой процесс ввода новых данных происходит непрерывно, и это накладывает ограничения на то, как именно производить процесс замены СУБД и клиентских приложений.
В целом варианты модернизации информационной системы можно условно разделить на следующие категории:
1. Замена СУБД с сохранением структуры базы данных и пользовательских приложений (или относительно небольшой их модернизацией).
2. Замена и СУБД, и пользовательских приложений с сохранением структуры базы данных.
3. Замена СУБД, пользовательских приложений и одновременная модернизация структуры базы данных.
На первый взгляд, первый вариант представляется наиболее безболезненным для пользователей и разработчиков, и он широко пропагандировался несколько лет назад. Именно в тот период на рынке программного обеспечения появились две категории продуктов, «обслуживающих» подобный вариант модернизации.
Первая категория представляла собой драйверы различных серверных СУБД для средств разработки, ориентированных в целом на использование настольных баз данных (например, драйверы Oracle для Clipper, преобразовывающие функции Clipper в вызовы функций клиентского API Oracle — Oracle Call Interface); обычно эти драйверы поставлялись в виде библиотек, компилируемых вместе с приложением. «Потомки» подобного программного обеспечения существуют и сейчас — одним из них является, например, библиотека Borland SQL Links, изначально предназначенная для использования приложений Paradox с серверными СУБД.
Вторая категория продуктов, ныне практически забытая, представляла собой некое подобие серверов баз данных, управлявших набором файлов настольных СУБД. Типичными примерами таких продуктов являлись разнообразные «dBase-серверы», управлявшие набором dBase-таблиц и перехватывавшие обращения к ним клиентских приложений. Подобные «серверы» в определенной степени решали проблему сетевого трафика и даже поддержки ссылочной целостности, но в силу ограничений, накладываемых на хранимый объем данных, характерных для форматов настольных СУБД, достаточно быстро уступили место «настоящим» серверам баз данных.
Если говорить о первом варианте модернизации, в этом отношении больше всего повезло пользователям Microsoft Access — процесс замены базы данных Microsoft Access на MSDE (или Microsoft SQL Server) происходит достаточно безболезненно, и пользовательские приложения при этом обычно сохраняют свою работоспособность. Так как в данном случае все эти СУБД (Access, MSDE и SQL Server) принадлежат одному производителю, перенос данных между ними осуществляется вполне корректно, с сохранением всех определенных в базе данных бизнес-правил. Кроме того, утилиты переноса данных из Access содержатся в комплекте поставки и других серверных СУБД (например, Oracle). Относительно безболезненно можно осуществить перенос данных из Visual FoxPro в Microsoft SQL Server.
Что касается замены других версий настольных СУБД на серверные, здесь могут возникнуть определенные проблемы. Например, при переносе данных из dBase или Paradox в какую-нибудь серверную СУБД обслуживающее их приложение, написанное на Delphi, вполне может отказаться работать даже после корректной перенастройки библиотек доступа к данным, особенно если оно содержит сведения о метаданных. Возможны также различные неприятности, связанные с использованием строчных и прописных букв в наименованиях полей, применением русских наименований полей (и вообще локализованных версий, поддерживающих национальные традиции написания чисел и дат и нередко превращающих числовые данные и даты в при переносе в другую СУБД в нечто невообразимое), несовместимости некоторых типов данных (это особенно часто происходит при переносе таблиц Paradox в другие СУБД). Наконец, если в серверной СУБД определены какие-либо бизнес-правила, нет никакой гарантии, что они идеально соблюдались в настольной СУБД, из которой переносятся данные, и в этом случае некоторое количество «ручного» труда по разбору данных, не соответствующих этим правилам, вам или вашим пользователям гарантировано.
Отметим, однако, что переход к архитектуре «клиент-сервер» отнюдь не исчерпывается переносом данных в новую СУБД. Чтобы воспользоваться всеми преимуществами этой архитектуры, следует также реализовать бизнес-правила, содержащиеся в клиентском приложении, в виде триггеров и хранимых процедур, а затем модифицировать код клиентского приложения, удалив реализацию бизнес-правил или заменив ее на обращения к соответствующим объектам базы данных. И если исходное клиентское приложение содержало код, отличный от чисто презентационного, было бы более чем наивно полагать, что оно не нуждается в модернизации, что бы ни говорилось в рекламе средств разработки по поводу масштабируемости созданных с их помощью приложений или о их независимости от СУБД. Как известно, реальные приложения очень отличаются от тех, что демонстрируются на выставках и презентациях...
Второй вариант модернизации информационной системы представляет собой по существу создание нового проекта по готовой модели данных плюс только что рассмотренный перенос данных в новую СУБД. Что касается третьего варианта модернизации, его можно рассматривать как два самостоятельных проекта. Первый из них представляет собой создание информационной системы практически «с нуля», второй — заполнение базы унаследованными данными. При этом, поскольку структуры баз данных различны, стандартными утилитами переноса данных (имеющимися в комплектах поставки многих средств разработки и серверных СУБД) здесь обычно обойтись не удается — как правило, в этом случае создаются «одноразовые» приложения, производящие нужные преобразования данных в процессе их переноса.
Обсудив проблемы, возникающие при переносе информационных систем, использовавших настольные СУБД, в архитектуру «клиент-сервер», можно перейти к обсуждению того, какие сервисы предоставляют современные серверные СУБД и чем с этой точки зрения следует руководствоваться при их выборе.
Выше мы обсудили преимущества архитектуры <клиент-сервер>, обусловленные ее базовыми принципами и не зависящие от того, какая конкретно СУБД выбрана. Однако помимо собственно средства современные серверные СУБД обычно предоставляют дополнительный набор сервисов, связанных с обслуживанием хранения и обработки данных, созданием клиентских приложений, сменой СУБД или ее версии, обслуживанием нескольких баз данных, публикацией данных в Internet. Поскольку в условиях конкуренции между различными производителями СУБД каждый из них стремится к завоеванию как можно большей части рынка, это приводит к тому, что все они пытаются перегнать друг друга и предоставить потенциальному потребителю (а также производителям средств разработки, средств проектирования данных и генераторов отчетов) как можно больше сервисов различного назначения, так как при выборе СУБД потребитель обычно ориентируется на то, что поддерживает в данная СУБД, с одной стороны, и чем она поддерживается - с другой. И, как и в случае настольных СУБД, в этой области также происходит процесс заимствования идей, решений и интерфейсов.
Ниже перечислены наиболее характерные для сегодняшнего дня сервисы, предоставляемые серверными СУБД.
Почти все современные серверы баз данных существуют в нескольких версиях для различных платформ (как правило, различные коммерческие версии UNIX - Solaris, HP/UX и др., а также Windows NT Server и, с недавнего времени, Windows 2000). Многие производители серверных СУБД также выпускают версии своих серверов для Windows NT Workstationи Windows 95/98 (а иногда даже для Windows CE). В последнем случае такие серверы нередко бывают персональными (однопользовательскими), либо в их реализации отсутствуют возможности, характерные для полнофункциональных версий этих серверов. Подобные персональные серверы, как правило, используются в <переносных> системах, например на ноутбуках, применяемых для работы с базой данных отдельно от центрального офиса компании с последующей репликацией данных. Иногда такие серверы используются при создании приложений для изоляции разработчика от сервера баз данных, находящегося в процессе эксплуатации.
В последнее время многие производители серверных СУБД выпускают также версии для Linux - с этой точки зрения Linux в последние два года была весьма <модной> платформой.
Исключением из этого правила является Microsoft SQL Server. Однако для данной СУБД это вполне оправданно - компания Microsoft сама производит серверные операционные системы и в отличие от большинства других производителей серверных СУБД может себе позволить создавать серверы баз данных, тесно интегрированные с сервисами операционной системы собственного производства и поддерживающие исключительно их.
Администрирование сервера баз данных, конечно, - удел профессионалов. Однако и профессионал предпочтет удобные утилиты администрирования унылому окну с интерфейсом командной строки. Наличие удобных утилит администрирования, как ни странно, иногда оказывается одним из решающих факторов при выборе СУБД. Именно поэтому подавляющее большинство современных СУБД обычно поставляется с подобными утилитами, и их интерфейс в последнее время напоминает интерфейс Windows Explorer (даже неинтересно помещать в эту статью иллюстрации - все они нынче похожи, как близнецы).
Следует отметить, что производители СУБД, вовремя не заметившие эту тенденцию, оказались лишенными значительной части рынка или практически вытесненными с него. Весьма показателен здесь пример IB Database (InterBase Corporation) - производители этой СУБД, очень неплохой с точки зрения хранения данных и скорости обработки запросов, не позаботились вовремя об удобных утилитах администрирования (а также о средствах репликации данных), положившись на продукты третьих фирм и на продвижение этой СУБД в составе популярных средств разработки, - и в результате многие ее потенциальные пользователи сделали выбор в пользу других СУБД, а сама IB Database практически перешла в разряд некоммерческих продуктов с доступными исходными текстами.
Резервное копирование данных и журналов транзакций поддерживается всеми без исключения коммерческими серверными СУБД. Различия между СУБД в поддержке резервного копирования заключаются в том, возможно ли производить резервное копирование в процессе работы пользователей, и если да, то какие пользовательские операции в это время нельзя выполнять. Помимо этого в комплекте поставки некоторых СУБД могут содержаться утилиты для использования различных внешних устройств (например, накопителей на магнитных лентах) в качестве средств хранения резервных копий.
Репликация по существу представляет собой гарантированное копирование информации из одной базы в несколько других. Репликации используются для разделения нагрузки между серверами в сети, для перемещения поднаборов данных на вспомогательные серверы, для синхронизации данных на нескольких серверах и многих других целей.
В том или ином виде репликации поддерживаются всеми современными серверными СУБД. Различия могут быть лишь в поддержке тех или иных конкретных сценариев репликаций (например, внесение изменений одновременно на нескольких серверах, возможность шифрования реплицируемых данных и др.). Исключение здесь составляет IB Database, в текущей версии не поддерживающая репликаций, но об этой СУБД мы уже упоминали.
Если вы планируете иметь несколько серверов баз данных с необходимостью синхронизации данных (например, у вашего предприятия существует несколько филиалов), стоит обратить внимание на то, какие сценарии репликаций поддерживаются в выбранной вами СУБД.
О возможностях повышения производительности с помощью параллельной обработки запросов в многопроцессорных системах начали говорить несколько лет назад, после появления первого продукта такого класса - Oracle Parallel Server. Серверы, поддерживающие параллельную обработку, разрешают нескольким процессорам обращаться к одной базе данных, что позволяет обеспечить высокую скорость обработки транзакций.
В настоящее время подавляющее большинство производителей современных серверных СУБД поставляют на рынок версии, поддерживающие параллельную обработку данных. Обычно это версии для Windows NT и коммерческих версий UNIX.
Если вы рассчитываете использовать многопроцессорный компьютер в качестве сервера баз данных, вам имеет смысл обратить внимание на то, поддерживает ли выбранная вами СУБД параллельную обработку данных.
OLAP (On-Line Analytical Processing) представляет собой технологию построения многомерных хранилищ данных (Data Warehouses), как правило, агрегатных, то есть являющихся результатом обработки набора данных, нередко состоящего из нескольких таблиц. Такие хранилища данных в последнее время широко используются в системах поддержки принятия решений. Более подробно об идеях, лежащих в основе OLAP, будет рассказано в одной из последующих статей данного цикла, здесь же мы ограничимся лишь упоминанием этой возможности.
Многомерные хранилища данных могут быть реализованы как в виде набора обычных реляционных таблиц, так и в виде нереляционной многомерной базы данных. В последнем случае такое хранилище обычно управляется отдельным сервером. Многие производители серверных СУБД поставляют такие серверы отдельно (Oracle, Informix), некоторые включают их в состав сервера реляционных баз данных (Microsoft SQL Server 7.0). Нередко с целью повышения конкурентоспособности подобные OLAP-системы строят многомерные хранилища на основе данных из других СУБД, как это сделано, например, в Microsoft SQL Server OLAP Extensions и в Sybase Adaptive Server IQ.
Если вы планируете создавать системы поддержки принятия решений, вам необходимо обратить внимание на то, какие OLAP-серверы можно использовать на выбранной вами платформе, и поддерживают ли они выбранную вами СУБД.
О распределенных транзакциях и запросах заговорили в последнее время, когда наличие нескольких серверов баз данных в одной организации стало обычным явлением. Нужно отметить, что возможности выполнения распределенного запроса или распределенной транзакции поддерживаются сейчас почти всеми серверными СУБД, по крайней мере в том случае, когда все вовлеченные в транзакцию серверы - от одного и того же производителя. С этой целью используется механизм двухфазного завершения транзакций (two-phase commit), когда на первом этапе серверы, вовлеченные в транзакцию, сигнализируют о готовности ее завершить, а на втором этапе происходит реальная фиксация изменений в базах данных.
Что касается распределенных транзакций с участием <чужих> серверов, то они, как правило, реализуются с помощью мониторов транзакций или иных подобных сервисов, например Microsoft Distributed Transaction Coordinator.
Если вы планируете использовать несколько серверов баз данных и совершать операции, затрагивающие данные на нескольких серверах, есть смысл поинтересоваться, поддерживают ли выбранные вами СУБД двухфазное завершение транзакций.
Многие производители серверных СУБД производят также средства анализа бизнес-процессов и проектирования данных, иногда универсальные (как в случае Sybase DataArchitect), а порой ориентированные главным образом на конкретную СУБД (как в случае Oracle Designer/2000). Многие производители СУБД не имеют в своем арсенале собственных средств проектирования данных, ориентируясь на универсальные CASE-средства типа Platinum ERwin. Нередко производители СУБД встраивают в административные утилиты несложные средства проектирования данных, позволяющие визуально редактировать схемы данных, как это сделано, например, в Microsoft SQL Server 7.0.
Выбирая CASE-средство, обратите внимание на то, поддерживает ли оно выбранную вами СУБД.
Многие производители серверных СУБД выпускают также средства разработки и генераторы отчетов. Иногда данные средства разработки используют тот же язык программирования, что применяется при написании триггеров и хранимых процедур (в этом случае, как правило, клиентское приложение должно включать интерпретатор этого языка), что позволяет отлаживать хранимые процедуры, помещая их в клиентское приложение. Типичный пример подобного подхода реализован в Oracle Developer/2000. Однако чаще средства разработки производителей серверных СУБД используют языки программирования, отличные от языков создания серверного кода (характерный пример - четыре средства разработки Microsoft).
Практически все производители серверных СУБД делают все возможное для того, чтобы клиентские приложения для их СУБД можно было создавать с помощью других средств разработки. С этой целью они предоставляют разработчикам описания API клиентской части, ODBC-драйверы, OLE DB-провайдеры, а нередко и объектные модели, позволяя использовать COM-объекты клиентской части в приложениях (как, например, это сделано в клиентских частях Oracle, Microsoft SQL Server, Informix).
Производители серверных СУБД, ориентирующиеся только на собственные средства разработки, как правило, оказываются вытесненными с рынка или теряют его часть. Показательной в этом плане явилась ситуация 1997 года, когда в комплекте поставки некогда популярного сервера SQLBase компании Gupta (ныне Centura) содержался ODBC-драйвер производства компании Intersolv, не поддерживавший хранимые <процедуры>. Это вызвало недовольство пользователей Visual Basic и Delphi, и в конечном итоге они перешли на другой продукт, более совместимый с их средствами разработки.
Выбирая СУБД и средство разработки, обратите внимание на то, какие механизмы доступа к данным при этом можно использовать и какие именно серверные объекты в этом случае будут доступны клиентскому приложению. Есть смысл попробовать поработать с оценочными версиями этих продуктов, чтобы убедиться, что вы не попадете в ситуацию, описанную выше.
Без поддержки публикации данных в Internet или получения данных от удаленных Internet-клиентов сегодня не обходится практически ни одна коммерческая СУБД, в том числе настольные базы данных. Тем или иным способом производители серверных СУБД поддерживают Web-технологии. Чаще всего эта поддержка осуществляется с помощью Web-серверов собственного производства, либо посредством создания расширений для существующих Web-серверов, либо просто путем включения в комплект поставки утилит, генерирующих Web-страницы согласно определенному расписанию.
Обсудив, какие сервисы предоставляют современные серверные СУБД, мы можем наконец поговорить и о конкретных серверах баз данных. Ниже мы рассмотрим наиболее популярные из них.
На сегодняшний день известно более двух десятков серверных СУБД, однако наиболее популярными, исходя из числа продаж и инсталляций, следует признать Oracle, Microsoft SQL Server, Informix, Sybase, DB2.
Сведения о производителях перечисленных выше СУБД педставлены в следующей таблице:
| СУБД | Производитель | Url |
|---|---|---|
| Oracle | Oracle Corp. | http://www.oracle.com |
| Microsoft SQL Server | Microsoft | http://www.microsoft.com |
| Informix | Informix | http://www.informix.com |
| Sybase | Sybase | http://www.sybase.com |
| DB2 | IBM | http://www-4.ibm.com |
Далее мы рассмотрим каждую из этих СУБД в отдельности. Начнем с Oracle - семейства СУБД, популярности и престижности которого могут позавидовать многие производители.
Oracle была первой коммерческой реляционной СУБД, поддерживающей ставший ныне индустриальным стандартом язык SQL; ее первая версия появилась в 1979 году. Фактически все это время Oracle является бессменным лидером на рынке производителей коммерческих СУБД и второй (после Microsoft) по величине компанией, производящей программное обеспечение.
Ранние версии этой СУБД были предназначены для мэйнфреймов, а в качестве рабочих мест использовались <неинтеллектуальные> терминалы. Однако со временем появились версии Oracle, предназначенные для использования в архитектуре <клиент-сервер> (первой такой версией была Oracle 5, выпущенная в 1985 году). Первоначально эти версии были предназначены для различных серверных платформ - различных версий UNIX, VMS и др. Позже были выпущены версии сервера Oracle для Novell NetWare. Первые версии этого сервера для персональных компьютеров появились в середине 90-х (Personal Oracle 7 for Windows 3.1, Personal Oracle 7 for Windows 95, Personal Oracle Lite, Oracle Workgroup Server 7 for Windows NT). До появления этих версий персональные компьютеры могли использоваться исключительно в качестве клиентских рабочих станций - в состав Oracle для серверных платформ обычно входила клиентская часть для DOS.
Отметим, что Oracle была первой компанией, создавшей СУБД, использовавшую предоставляемые некоторыми серверными платформами средства параллельных вычислений - Oracle Parallel Server (до его появления параллельные вычисления использовались только для решения научных задач). При использовании параллельных вычислений Oracle Parallel Server дает возможность нескольким процессорам обращаться к одной базе данных, что позволяет обеспечить высокую скорость обработки транзакций, а более поздние его версии дают возможность осуществить декомпозицию операций с большими объемами данных с целью параллельного выполнения их на нескольких процессорах.
На сегодняшний день последней версией Oracle является версия Oracle 8i, отличительными свойствами которой являются:
Oracle 8i существует в трех редакциях: Oracle 8i, Oracle 8i Enterprise Edition, Oracle 8i Personal Edition.
Для создания многомерных хранилищ данных существует и отдельный продукт - Oracle Express OLAP.
Помимо различных версий сервера баз данных среди продуктов Oracle имеется также Designer/2000 - ориентированное на эту СУБД CASE-средство для анализа бизнес-процессов и проектирования данных, а также средства разработки клиентских приложений. Одно из них - Developer/2000 (называвшееся ранее Oracle*Forms) - весьма популярно среди пользователей Oracle; были и другие средства разработки (например, Oracle Power Objects). Отметим, что приложения, созданные с помощью Developer/2000, могут выполняться на различных платформах. Язык PL/SQL, используемый в этом средстве разработки, является интерпретируемым и представляет собой тот же самый язык, что используется в Oracle для написания серверного кода. Это позволяет отлаживать с помощью Developer/2000 серверный код.
Производя собственные средства разработки, Oracle предоставляет своим пользователям возможность создавать клиентские приложения с помощью других средств. В частности, помимо стандартного в таких случаях клиентского API (Oracle Call Interface) клиентская часть Oracle содержит также объектную модель (Oracle Objects for OLE), позволяющую использовать клиентскую часть Oracle как набор COM-объектов для доступа к данным. Кроме того, обычно клиентская часть Oracle содержит также ODBC-драйвер для доступа к данным этой СУБД.
Отметим, что и многие другие компании производят ODBC-драйверы и OLE DB-провайдеры для доступа к Oracle (в частности, Microsoft). Компании, производящие средства разработки, использующие собственные библиотеки доступа к данным (такие как Inprise или Gupta/Centura), также включают библиотеки доступа к Oracle в состав наиболее дорогих версий своих продуктов.
Из готовых информационных систем на базе Oracle следует особо отметить несколько крупных систем управления предприятием, в частности SAP/R3. На Западе также нередко используются готовые решения от самой Oracle Corporation, объединенные под общим названием Oracle Applications, такие как Oracle Financials, Oracle Human Resources, Oracle Market Management, Oracle Project Systems и др.
Первая версия Microsoft SQL Server, совместно разработанная в 1988 году компаниями Microsoft и Sybase, предназначалась для платформы OS/2. Последующие версии этого сервера баз данных предназначались для платформы Windows NT и со временем были тесно интегрированы с этой операционной системой. Для других платформ версии этого сервера не выпускались и не выпускаются.
Удобный пользовательский интерфейс утилит администрирования в сочетании с достаточно высокой производительностью и относительно невысокой стоимостью эксплуатации сделал эту серверную СУБД второй по популярности - после Oracle. Наибольший рост популярности этой СУБД пришелся на конец 90-х годов, когда были выпущены Microsoft SQL Server 6.0 (1995 год), обладавший централизованными функциями администрирования и встроенными возможностями репликации данных, Microsoft SQL Server 6.5 (1996 год) и Microsoft SQL Server 6.5 Enterprise Edition, поддерживающий параллельные вычисления в многопроцессорных системах.
На сегодняшний день наиболее широко используемой является выпущенная в 1998 году версия Microsoft SQL Server 7.0. Эта версия отличается от предыдущих тем, что была полностью переписана фирмой Microsoft исключительно под платформу Windows NT. В состав Microsoft SQL Server 7.0 входят еще более простые утилиты администрирования (Enterprise Manager), сервисы преобразования данных (Data Transformation Services), облегчающие перенос данных в SQL Server из других типов СУБД, поддержка распределенных запросов и транзакций, OLAP-сервер и утилиты для создания хранилищ данных (в том числе данных из других серверных СУБД), расширенная поддержкой функций для создания Web-приложений.
Помимо собственно Microsoft SQL Server 7.0 в качестве встроенной СУБД для настольных приложений и приложений для небольших рабочих групп можно также использовать Microsoft Data Engine (MSDE) - настольный сервер баз данных, совместимый с Microsoft SQL Server и предназначенный для использования в настольных системах или в сетевых приложениях с небольшим (до 2 Гбайт) объемом данных и небольшим количеством пользователей. Базы данных MSDE полностью совместимы с базами данных Microsoft SQL Server и могут при необходимости управляться этим сервером. Подробнее об MSDE и правилах его лицензирования можно прочесть в предыдущей статье данного цикла.
Клиентские приложения для Microsoft SQL Server и MSDE можно создавать как с помощью средств разработки Microsoft - Visual Basic, Visual C++, Access и Visual FoxPro, так и с помощью средств разработки других производителей. Для этой цели имеются ODBC-драйвер и OLE DB-провайдер, а также содержащий их набор библиотек Microsoft Data Access Components (MDAC), позволяющий использовать в средствах разработки объекты ActiveX Data Objects (ADO) - COM-объекты для доступа к данным. MDAC является составной частью Windows 2000, а для пользователей других Windows-платформ доступен отдельно на Web-сайте Microsoft.
В отличие от Oracle, Microsoft не производит средств разработки, использующих тот же самый язык программирования, что и язык для создания кода триггеров и хранимых процедур, однако производит средства отладки серверного кода (например, SQL Server Debugger входит в состав Visual Basic и Visual C++).
Серверные продукты компании Sybase происходят от двух <предков>. Первым из них является одна из ранних версий Microsoft SQL Server, созданная совместно Microsoft и Sybase. Начиная с 1994 года Microsoft и Sybase разрабатывают свои серверные продукты независимо друг от друга, и результатом деятельности компании Sybase в этом направлении является продукт под названием Adaptive Server Enterprise (в настоящее время используются его версии 11 и 12). Этот продукт существует для Windows NT и некоторых версий UNIX (включая Linux) и предназначен для обслуживания крупных предприятий. В настоящее время этот сервер поддерживает:
Еще одна линия серверных продуктов Sybase ведет свое начало от сервера баз данных Watcom SQL Anywhere, отличавшегося компактностью и простотой администрирования. Последняя версия этого продукта называется Adaptive Server Anywhere 6.0.3. Этот сервер предназначен для обслуживания небольших рабочих групп, для применения в портативных компьютерах в качестве персонального сервера с периодической репликацией, а также в мобильных устройствах - существуют версии этого сервера для Windows CE 2.1 и версия UltraLite для разнообразных мобильных устройств (исключая разве что тамагочи).
Для управления распределенными транзакциями Sybase выпускает монитор транзакций - Jaguar CTS.
Для создания многомерных хранилищ данных у Sybase существует еще один серверный продукт - Adaptive Server IQ, позволяющий создавать хранилища на основе данных не только из СУБД производства Sybase, но и из СУБД других производителей. Отметим также, что существует ряд продуктов под общим названием Sybase Industry Warehouse Studio, ориентированных на обслуживание конкретных предметных областей: торговли (Retail Warehouse Studio), здравоохранения (Healthcare Warehouse Studio), страхования (Life Insurance Warehouse Studio) и др.
Помимо серверных продуктов Sybase производит средства разработки, ориентированные на создание клиентских приложений для них (PowerBuilder, PowerJ, PowerSite; последнее предназначено для создания Web-приложений), и средства проектирования данных и генерации кода приложений. Последние можно отнести к универсальным средствам - CASE-средство DataArchitect поддерживает широкий спектр СУБД различных производителей, а генератор приложений AppModeler способен генерировать код не только для PowerBuilder и Optima++, но и для Delphi, Visual Basic, Web-приложений с использованием ASP.
Ведущий продукт фирмы Informix - Informix Dynamic Server, последняя версия которого называется Informix Dynamic Server.2000 (выпущена в сентябре 1999 года). Данный продукт поддерживает платформы UNIX и Microsoft Windows NT и обеспечивает эффективную работу как на одно-, так и на многопроцессорных системах, а также в кластерах. Сервер построен по архитектуре Dynamic Scalable Architecture (DSA), обеспечивающей мощные средства для параллельной обработки данных. В числе основных характеристик Informix Dynamic Server следует отметить:
Сервер поддерживает двухфазное завершение транзакций, гетерогенные транзакции (в этом случае в транзакциях может принимать участие и не-Informix сервер, доступный через Informix Enterprise Gateway).
Расширения функциональности сервера реализуются на базе DataBlade - коллекций объектов баз данных и подпрограмм на языке С, подключаемых к базе данных. Для разработки DataBlades необходимо использовать DataBlade Developer's Kit. Фирма Informix и целый ряд независимых производителей выпускают модули DataBlade, такие, например, как Excalibur Text DataBlade Module, Informix Geodetic DataBlade Module, Informix TimeSeries DataBlade Module, Excalibur Image DataBlade Module, Informix Web DataBlade Module и ряд других.
Входящие в состав Informix Dynamic Server клиентские утилиты предназначены для подключения к серверу и обработки информации (DB-Access) и для выполнения функций администрирования (DB/Cockpit).
Клиентские приложения могут создаваться с использованием языков Informix ESQL (средство для разработки на языке С, позволяющее включать в приложения запросы к данным на языке SQL), а также С, С++, Java, Visual Basic и Delphi. Помимо этого существует собственное средство разработки - Informix-4GL и Informix Client Software Developer's Kit.
Фирма Informix выпускает Informix ODBC Driver, OLE DB Provider для Informix Dynamic Server и Informix JDBC Driver.
В состав продукта входят собственно сервер, а также Informix Connect 2.30, DataBlade Developer's Kit 4.0 и Informix Server Administrator 1.0.
Для генерации отчетов предлагается Informix-ViewPoint - визуальное средство, рассчитанное на пользователей. Версия Pro также содержит средства администрирования.
Говоря о сервере фирмы Informix, следует упомянуть и поддержку OLAP: продукт под названием Informix MetaCube поставляется как часть Informix Decision Frontier - комплексного решения для создания хранилищ данных.
Среди других продуктов фирмы Informix следует отметить:
Семейство серверных СУБД фирмы IBM, известное под названием DB2 Universal Database, представляет собой стратегию IBM по объединению продуктов DB2 для различных платформ в единую линию. Впервые появившееся в 1996 году семейство DB2 Universal Database объединяло в себе функциональные возможности таких продуктов фирмы, как DB2 Common Server, DB2 Parallel Edition (DB2 PE), Net.Data, Data Propagator и технологии DataHub, и предназначалось для платформ UNIX, OS/2 и Microsoft Windows NT.
Отметим, что при переносе DB2 на не-IBM-платформы фирма старается максимально использовать уникальные функциональные возможности конкретной платформы. Например, в DB2 for Windows 2000 для обеспечения безопасности используется Windows NT LAN Manager, полностью поддерживается Windows Performance Monitor, Systems Management Server, интеграция с Active Directory для каталогизации баз данных, а также такие интерфейсы доступа к данным, как ODBC, ADO и OLE DB. Помимо этого DB2 for Windows 2000 поддерживает Microsoft Transaction Services (MTS) в качестве координатора при создании приложений, использующих распределенные транзакции.
Для разработчиков, использующих Microsoft Visual Studio, становятся доступными дополнительные модули, например Stored ProcedureBuilder, включаемый непосредственно в среду Visual Studio. IBM также предлагает собственные средства разработки, например IBM VisualAge for Java, позволяющие создавать приложения, работающие с данными в DB2. Продукт также поддерживает создание хранимых процедур на языке Java (Java Stored Procedure Builder).
Помимо этого IBM предлагает бесплатное средство для миграции данных из Microsoft Access в DB2, а также средства для миграции данных из Oracle, Microsoft, Sybase и Informix.
К основным характеристикам СУБД можно отнести поддержку реляционных и комплексных данных через объектные расширения, возможность работы на мультипроцессорных платформах, поддержку кластеров, 64-битную архитектуру памяти и распараллеливание запросов, возможность создания Web-приложений (поддерживаются такие технологии, как Java, JDBC, SQLJ, XML) и наличие средства для гетерогенного администрирования и обработки данных.
Семейство DB2 функционионирует на системах AS/400 и RISC System/6000, мэйнфреймах IBM, машинах от Hewlett-Packard и Sun Microsystems и на таких операционных системах, как Windows NT и Windows 95/98, OS/2, AIX, HP-UX, SCO UnixWare, Linux, NUMA-Q и Sun Solaris, и сейчас поддерживает портативные устройства под управлением Windows CE и Palm OS.
DB2 Universal Database выпускается в редакциях DB2 Universal Database Enterprise - Extended Edition (платформы AIX, Solaris и Windows NT), DB2 Universal Database Enterprise Edition (платформы AIX, HP-UX, Linux, OS/2, Solaris и Windows NT), DB2 Universal Database Workgroup Edition (платформы Linux, OS/2 и Windows NT) и DB2 Universal Database Personal Edition (платформы OS/2, Linux, Windows 9x и Windows NT).
К дополнительным продуктам можно отнести:
В данной статье мы рассмотрели преимущества архитектуры <клиент-сервер>. Мы узнали, что по сравнению с информационными системами, основанными на настольных СУБД, системы, использующие серверные СУБД, обладают более высокой производительностью, меньшим сетевым трафиком, более совершенными средствами обеспечения безопасности, а также возможностями перенести на сервер баз данных часть кода, связанную с реализацией бизнес-правил и обработкой данных. Кроме того, мы обсудили возможные проблемы, которые могут возникнуть в процессе перехода от настольной СУБД к серверной, а также задачи, стоящие перед разработчиками, осуществляющими такой переход.
Мы также рассмотрели наиболее популярные на сегодняшний день серверные СУБД и признаки, которыми они характеризуются. Как правило, все или почти все данные СУБД:
Иными словами, существующие на сегодняшний день возможности наиболее популярных серверных СУБД отражают современные тенденции развития информационных систем, такие как использование многопроцессорных систем и распределенной обработки данных, создание распределенных систем, в том числе с использованием технологий Internet, применение средств быстрой разработки приложений, создание систем поддержки принятия решений с использованием аналитической обработки данных, а также все более повышающиеся требования к надежности и отказоустойчивости информационных систем.
Следующая статья данного цикла будет посвящена различным механизмам доступа к данным, используемым в приложениях.
КомпьютерПресс №5'2000
