Что предпринимают производители реляционных баз данных для Unix, чтобы выжить в следующем поколении архитектур клиент/сервер

Билл Розенблатт

Manager, Information Resources Moody"s Investor Services, New York, billr@panix.com

1. Часть первая
2. Часть вторая: Unix RDBMS - разрабатывая будущее
3. Глоссарий
4. RDBMS: Фирмы-игроки

1. Часть первая

Производители реляционных баз данных для Unix проявляют активность, не только соревнуясь друг с другом, но и для того, чтобы обеспечить новыми продуктами и услугами, лучше удовлетворяющими требованиям следующего поколения архитектур клиент/сервер, распределенные вычислительные системы и их пользователей. Первое поколение баз данных, которые появились на рынке Unix, работало, в основном, на локальных однородных сетях типа клиент/сервер. Архитектурные требования следующего поколения не столь просты. Для того чтобы удовлетворить запросам следующего поколения, реляционным базам данных (РБД) придется обеспечивать большее разнообразие типов данных на большем разнообразии компьютеров, работающих в гетерогенных сетях масштаба предприятия. И производители должны будут обеспечить постоянно растущие потребности разработчиков и пользователей в быстром и удобном доступе к данным. Будут ли производители РБД в состоянии выжить, традиционно опираясь на свои силы, или же они должны завоевать рынки, обслуживаемые сейчас другими производителями? Является ли концепция реляционно-серверной технологии достаточно мощной, чтобы переносить ее на 1995 год и далее? Мы можем достаточно ясно представить себе очертания будущего, если тщательно изучим технологические требования следующего поколения СУБД, работающих на Unix, и то, как три ведущих поставщика баз данных на рынке Unix - Oracle, Informix, и Sybase, а также "темная лошадка" (В этой области - прим. ред.) - новаторский Borland, могут ответить и как они отвечают на эти вопросы.

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

1.1. Увеличивая производительность

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

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

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

1.2. Параллельная обработка передачи данных

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

Многопотоковая архитектура, впервые реализованная Sybase, а теперь используемая всеми четырьмя производителями систем (последним присоединился Informix в версии 6.0) позволяет избежать состояний простоя (например, во время операций ввода/вывода) путем создания нитей управления (threads), которые представляют из себя специальные, "облегченные" процессы, использующие меньше ресурсов сервера. Сервер базы данных назначает запросы нитям управления и может динамически выбирать нить с выполняющимся на ней запросом, многим напоминая переключение между процессами в Unix. Когда выполнение запроса приостанавливается, сервер выгружает его из соответствующей нити и заменяет другим запросом, в то время как первый будет находится в состоянии ожидания.

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

Для увеличения производительности серверы могут также использовать параллельную обработку: разбивая отдельные запросы на части, которые можно выполнять независимо, возможно на разных серверах - способ, повсеместно известный как параллельные запросы к данным (PDQ). Главная задача - как идеально разбить программу на части, которые можно будет выполнять одновременно (параллелизация) - это открытый вопрос в компьютерной науке и останется таковым, по всей видимости, еще некоторое время. До сих пор производители баз данных не смогли существенно улучшить PDQ. Informix и Sequent Computer Systems показали одну из работающих демонстраций в июле 1993 на восьмипроцессорной системе, который имел коэффициент ускорения более семи единиц. Это близко к идеальной восьмерке - хотя, по-видимому, сказались оптимальные условия при демонстрации. Они предполагают внедрение этого варианта PDQ в свои продукты в первой половине 1994 года.

Oracle планирует распространять PDQ технологию со следующей редакцией версии Oracle7. Предполагается, что Navigation Server фирмы Sybase для серий компьютеров NCR 3500/3600 будет поддерживать PDQ в первой половине 1994 года. Между тем, Oracle сделал шаг дальше, реализовав обработку транзакций на многопроцессорных компьютерах: Oracle поддерживает свою технологию параллельного сервера (Parallel Server) на слабосвязанных (кластеризованных) процессорах. Версия Oracle Parallel Server для VAXClusters фирмы Digital, работающая под управлением VAX/VMS, была завершена в 1991 году, а версия, функционирующая на сети ptx/CLUSTERS фирмы Sequent, реализована в июне 1993. Oracle также анонсировал версии для кластерных систем фирм Pyramid Technology Corp. и NCR.

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

1.3. Распределение данных

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

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

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

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

Транзакция, как абстракция, также может быть использована на уровне распределенных данных для гарантии, что связанные группы данных и операций перемещаются от клиента к серверу или от одного сервера к другому дискретными логическими единицами. Мониторы обработки транзакций (TP) - это средства, в основном от третьих фирм, управляющие прохождением распределенных транзакций по гетерогенным сетям. Принятым, стандартным методом связи между TP-мониторами и СУБД является протокол X/A группы разработки стандартов X/Open. System 10 фирмы Sybase и Oracle7 поддерживают стандарт X/A; Informix OnLine поддерживает его посредством дополнительного продукта, Informix TP/XA.

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

Более важно, что 2PC не работает во многих ситуациях, особенно со сложными, глобальными сетями, в которых вероятность отказа достаточно велика, и с высококритичными системами, которые должны иметь высокую степень готовности. Не практично, например, заставлять Токио прекращать работу только потому, что связь с главной конторой в Нью-Йорке выключена, или, аналогично, приостанавливать операции в Нью-Йорке потому, что производится сохранение информации сервера в Токио.

Oracle, Sybase и Informix решили пойти дальше 2PC и предложили подходы к распределенным данным, основанные на другой "абстракции" - парадигме репликации. (InterBase планирует включить репликацию в будущую редакцию системы). Репликация - это процесс хранения несколькими серверами идентичных копий базы данных. Это полезно по нескольким причинам, таким как, например, обеспечение доступности данных, назначения выделенных серверов для специальных задач и минимизации сетевого трафика путем хранения полной копии базы данных на удаленной установке.

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

Одним из средств репликации является утилита Table Snapshots продуктов Oracle7, которая копирует только измененные (отличающиеся) части всех или выбранных таблиц в дискретные моменты времени и затем распространяет моментальный снимок по сети к другим машинам.

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

Механизм репликации Informix похож на схему "моментальных снимков" Oracle. Как и другие механизмы базы данных Informix OnLine, его схема репликаций извлекает преимущества из предыстории функционирования системы настолько, насколько это возможно: Informix использует информацию об изменениях в базе данных из сохраняемых журналов протоколирования для определения того, какие данные тиражировать. В назначенные интервалы - установленные системным администратором - реплицируемая база данных осуществляет "прокрутку вперед"(roll forward) по сети Informix-Star на удаленную машину (машины). Этот механизм прост и обеспечивается проверенной технологией, но он имеет те же недостатки, связанные с логической целостностью данных, что и моментальные снимки Oracle.

Oracle рекомендует альтернативный подход к репликации, известный как "запоминание-и-передача" (store-and-forward), работающий аналогично электронной почте. Этот механизм позволяет программистам конфигурировать репликацию так, что она происходит в граничных точках транзакций, а не в фиксированные интервалы времени, как при схеме с моментальными снимками, тем самым сильно улучшая шансы, что все базы данных будут находиться в состоянии логической согласованности. Один сервер выбирается в качестве главного. Когда происходят изменения в базе данных главного сервера, они передаются другим серверам как очереди сообщений. Если удаленная машина выключается, сообщения накапливаются, до тех пор пока она снова не включится и не внесет их в базу данных.

Реализовать механизм репликации типа запоминание-и-передача можно с использованием триггеров и некоторого дополнительного кода, такого как специальное задание Unix - задание cron. Oracle объявил, что компания скоро будет предлагать дополнительный пакет (пока безымянный), который автоматизирует процесс, исключив большую часть необходимого дополнительного кода.

Sybase System 10 имеет дополнительный компонент, называемый Replication Server, который увеличивается до больших размеров при реализации схемы запоминание-и-передача надежным способом. Специальному серверу поручена вся задача управления репликацией, а отличный от главного сервер назначается "горячим резервом" и продолжает обработку при отключении главного сервера. Целями, конечно же, являются отказоустойчивость и высокая степень готовности.

Replication Server в комбинации с административными средствами System 10 поможет клиентам Sybase пройти долгий путь по решению трудных проблем распределения данных. Однако, Replication Server настолько сложен, что его собственные недостатки и ограничения еще предстоит отыскать. А Sybase должна потратить уйму усилий для обучения и подготовки администраторов базы данных по уходу и поддержке Replication Server. Моментальные снимки Oracle и схема прокрутки-вперед Informix, напротив, очень просты и ясны, и они могут удовлетворить многие потребности организаций.

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

1.4. Интероперабельность

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

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

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

Различные поставщики баз данных типа клиент/сервер придерживаются разных стратегий обеспечения интероперабельности. Borland имеет самый широкий спектр продуктов, поэтому не удивительно, что компания разработала (в содружестве с IBM, Novell и WordPerfect Corp.) свой собственный стандарт взаимодействия - Integrated Database Application Programming Interface (IDAPI).

Как программный интерфейс, IDAPI позволяет иметь построчный доступ к реляционным таблицам в стиле dBASE - или, как называет это сам Borland, используя "навигационный стиль Xbase". С другой стороны, IDAPI позволяет применять SQL-команды к записям Xbase и получать отношения в качестве результатов, а не просто получать первую запись, удовлетворяющую условию, как это обычно делают базы данных типа Xbase.

IDAPI имеет целью стать надмножеством своего главного конкурента: ODBC (Open Database Connectivity) фирмы Microsoft. ODBC, в свою очередь, поддерживает SAG-CLI, (SQL Access Group"s Call Level Interface). Другим важным конкурирующим стандартом является DRDA (Distributed Relational Database Architecture), который IDAPI также поддерживает.

Так как IDAPI способствует интероперабельности среди широкого круга продуктов, включая две базы данных для PC, электронную таблицу и ряд систем языков программирования помимо InterBase, Borland затушевывает различия между взаимодействием с клиентом и взаимодействием с сервером. Это разумная стратегия. То же верно и для ODBC - хотя в меньшей степени, так как он не поддерживает навигационный доступ. Однако задержка Borland с реализацией IDAPI дала ODBC существенное преимущество: многие продукты третьих фирм и собственные продукты баз данных Microsoft уже поддерживают ODBC. А козырная карта Microsoft заключается в том, что ее база данных старшего класса SQL Server является портированной версией Sybase для PC, тем самым обеспечивая ODBC также шлюзом к миру Sybase.

Интересно, что Sybase, по всей видимости, проигнорирует Microsoft Connection. Продукты компании, обеспечивающие интероперабельность, по прежнему осуществляют разделение взаимодействия с клиентской частью и с серверной частью, предлагая две различные парадигмы, базирующиеся, соответственно, на архитектурах Open Client и Open Server, бывших в течение некоторого времени средствами компании. Open Client и Open Server - это, по существу, программные интерфейсы, которые служат тому, чтобы "раскрыть" собственную схему взаимодействия клиент/сервер Sybase; таким образом, разработчики могут разрабатывать компоненты любой из сторон. Например, программа, разработанная для Open Server, может функционировать как промежуточный слой между приложениями клиента и SQL Server, или она может заменить SQL Server. Большая часть дополнительных модулей в Sybase System 10, включая Replication Server и Navigation Server, разработаны как Открытые Серверы - как программы, обрабатывающие вызовы Open Server API.

Проще объяснить работу Open Client API. Это собственный (Sybase) реляционный интерфейс уровня-вызова (call-level interface), похожий на SAG-CLI или ODBC (см. выше). Sybase предпринимала попытки продвинуть интерфейсы прикладных программ Open Client и Open Server в качестве запатентованных стандартов взаимодействия, предоставляя разработчикам гибкость, если они предпримут усилия и сделают свои продукты Sybase-совместимыми. Эта стратегия, однако, не увенчалась успехом. Таким образом, с System 10 Sybase распространяет и предлагает лучшую интероперабельность продуктов, работающих на основе Open Client и Open Server.

Со стороны сервера, новый продукт OmniSQL Gateway фирмы Sybase - интерфейс, позволяющий другим реляционным системам баз данных, включая Informix, Oracle, и различным располагающимся на мэйнфреймах нереляционным системам работать с клиентом почти так же, как и Sybase SQL Server. Это означает, что приложения, написанные на диалекте Transact-SQL фирмы Sybase, могут использовать данные на серверах данных, отличных от серверов компании Sybase.

Sybase предлагает набор надстроек над Open Client, которые позволяют им выглядеть как IDAPI, ODBC или SAG-CLI. Informix также анонсировал поддержку ODBC и предоставляет возможности взаимодействия с менеджерами индексированных данных на мэйнфреймах при помощи своего средства Informix DataExtract.

Продуктом фирмы Oracle, обеспечивающим интероперабельность со стороны сервера, является SQL*Gateway, который аналогичен OmniSQL*Gateway фирмы Sybase и имеет доступ к одинаковому набору источников данных. Компания также анонсировала совместный с Novell продукт, названный OracleWare, который ориентирован на среду персональных компьютеров, и с обработкой сообщений не хуже, чем у сервера базы данных. Любопытно, что OracleWare применяется при входе в систему сообщений - электронную почту Oracle. Это сотрудничество обеспечивает интероперабельность между Oracle Office и системой передачи сообщений Novell Netware Global MHS. Но многие разработчики уже раздражены войной API-интерфейсов в области передачи сообщений (MAPI фирмы Microsoft против ведомого фирмой Lotus консорциума VIM), которая в настоящее время является наиболее серьезным техническим препятствием для проведения разработок уровня рабочих групп. Другой интерфейс передачи сообщений добавлен здесь только для того, чтобы внести путаницу. Продуктом фирмы Oracle, обеспечивающим интероперабельность со стороны клиента, является Oracle Glue, утилита, работающая с протоколами управления объектами в клиентах как Windows, так и Macintosh. С помощью Oracle Glue программисты без дополнительного программирования могут сделать так, чтобы данные с Oracle-сервера стали доступны в Windows-приложениях.

Хотя Динамический Обмен Данными (Dynamic Data Exchange - DDE), Связывание и Встраивание Объектов (Object Linking and Embedding - OLE) и их аналоги для Apple Publish и Subscribe были изначально разработаны для обеспечения интероперабельности на уровне приложений отдельной машины, распределенные файловые системы превратили их в нечто другое. Вы можете рассматривать эти средства как верхние уровни стека сетевых протоколов, что-то вроде мифических 6 и 7 уровней сетевой модели OSI.

В таком контексте Oracle Glue - важное нововведение. Это делает Oracle единственным производителем баз данных, кроме, разумеется, Borland, который предоставляет интероперабельность на уровне приложений в современных средах настольных систем.

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

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

2. Часть вторая: Unix RDBMS - разрабатывая будущее

Системы масштаба предприятия, второе поколение архитектуры клиент/сервер, требуют наличия опыта во многих областях технологии - их разнообразие может разорить сегодняшних производителей реляционных СУБД, доминирующих в мире Unix. Что они делают и что им нужно делать для того, чтобы выжить в следующем поколении? В первой части публикации мы представили ведущих производителей реляционных СУБД мира Unix (Informix, Sybase и Oracle), а также, как и "темную лошадку" Borland. Завершая статью, мы рассмотрим, как эти поставщики решают вопросы масштабируемости, сложных типов данных и целостности данных, разработки приложений, и бросим беглый взгляд на будущее серверов баз данных для Unix.

2.1. Масштабируемость

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

Сегодня все выбранные нами производители реляционных СУБД обеспечивают масштабируемость - пока вы работаете с их базами данных на всех ваших серверах. Informix, InterBase и Oracle позволяют создавать таблицы на удаленных машинах и оперировать с ними посредством синонимов, которые представляют из себя локальные псевдонимы для удаленных таблиц. Sybase предлагает схожую технику посредством дополнительного компонента System 10, называемого Navigation Server. Возможность оперирования синонимами во всех этих продуктах баз данных позволяет также программистам осуществлять распределенные соединения, возможно даже без знания о том, что они являются распределенными, и перемещать таблицы с одного сервера на другой без переработки существующего SQL-кода. Одна из задач планирования масштабируемости в следующем поколении заключается в определении того, какие данные на какой машине располагать. Наиболее часто это делается из чисто прагматических соображений, таких как географические потребности, например. Но это также еще одна возможность ускорения работы с запросами - распределить локальные данные на несколько серверов. Это может включать в себя размещение отдельных таблиц данных на отдельных машинах, репликацию некоторых таблиц на множество машин или комбинацию этих двух подходов. В любом случае, такая задача - некоторая вариация на тему распараллеливания, обсуждавшуюся выше. Программисты также могут распараллелить многосерверные запросы вручную, экспериментируя с местами размещения таблиц, до тех пор пока заданная задача не будет выполняться быстрее всего - очень утомительная работа. Navigator Server фирмы Sybase, когда он будет реализован, поможет автоматизировать процесс при его использовании совместно с другой компонентой System 10, называемой Configurator. Configurator собирает статистику об использовании и производительности сервера и может быть использован Navigator Server, чтобы определить, где нужно размещать данные для получения максимальной производительности.

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

2.2. Больше типов данных

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

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

Рассмотрим, например, Большие Двоичные Объекты (Binary Large Objects - BLOB): они позволяют программистам выделять произвольно большие объемы пространства базы данных для наборов двоичных данных, не имеющих оговоренного назначения. (В объектной модели, напротив, семантика - как данные классифицируются и как ими можно манипулировать - входит в определение интерфейса.) Вы можете хранить все что угодно в BLOB; во многих случаях вы можете интерпретировать BLOB как любое другое поле данных в реляционных запросах.

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

Рынок средств разработки увеличился на 78% (91-92 гг.). (Смотрите News, March 1994, для получения подробностей двух других подходов к расширению типов данных - производителя объектных баз данных Objectivity и вновь возникшего поставщика реляционных баз данных Montage.) Другим очень нужным типом данных, который не поддерживает стандартный SQL, является массив, использование которого является решающим для многих приложений, особенно в науке, в инженерной практике и в финансах. В программах, созданных с помощью других распространенных языков, содержащих тип массива, массивы занимают пространство, необходимое лишь для хранения их элементов данных, и доступ к любому элементу в массиве обходится только в один шаг. Без типа данных "массив", однако, реляционная СУБД должна обеспечивать хранение даже простого линейного массива, используя таблицу с двумя столбцами, где один столбец содержит действительно элементы данных, а другой - индексы к этим элементам данных - колоссальная трата пространства. И это приводит к усложненному без необходимости и трудному для понимания программированию.

InterBase - единственная из четырех реляционных СУБД рассматриваемых нами, поддерживающая массивы. Ее собственный язык программирования, GDML, который может объединяться с SQL в пределах программ для баз данных, поддерживает многомерные массивы, трактуя их как BLOB.

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

Стандарты SQL89 и SQL92 позволяют вам указать, что нужно делать, когда, например, строка с информацией о подразделении удаляется из базы данных: служащие, номер отделения которых удаляется, могут получить либо некий номер по умолчанию, либо NULL. Или, что более уместно для деловой практики ранних 90-х, запись о служащем тоже может быть удалена. Такая ссылочная целостность данных называется каскадом (cascade) в стандарте SQL92; вы можете реализовать ее в виде триггеров, если ваша база данных не поддерживает SQL92.

Возможность проверки целостности доменов в SQL92 намного более интересна: она позволяет вам определить условие, которому должны удовлетворять вводимые данные. Например, пол служащего может быть "M" или "F", а их зарплата должна быть меньше, чем у ее или его начальника.

Язык GDML в InterBase поддерживает схожие механизмы целостности доменов и добавляет к этому кое-что еще. Наиболее существенной является маска редактирования, аналогичная той, что использовалась в средствах генерации отчетов и накладывала ограничения на значения строк. Например, телефонный номер должен иметь следующую форму "(xxx) xxx-xxxx", где все "х" должны быть цифрами.

2.3 Средства пользователя и разработчика

Революция в разработке приложений и средствах запросов к базе данных с графическим пользовательским интерфейсом стали особо важным вопросом для поставщиков на рынке реляционных СУБД. Теперь те многие организации, которые оправились от начальной гонки при переходе от мэйнфреймов и мини-ЭВМ ("downsizing"), столкнулись с работой по переводу доставшихся по наследству программ и разрабатываемых приложений на новые архитектуры клиент/сервер. Исследование, проведенное International Data Corp., показывает, что рынок средств разработчика вырос на ошеломляющие 78% в 1992 году по сравнению с 1991, и предполагается его дальнейший рост в 1993 на 45%.

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

Во-вторых, независимые "новички", которые предоставляли более современный инструментарий, решили не искать поддержки производителей баз данных, потому что это привязало бы их к конкретной платформе. Вместо этого, независимые поставщики часто отчуждали себя от производителей операционных систем клиентов, как, например, Easel от IBM, или же они использовали повальное увлечение бизнесменов архитектурой клиент/сервер и искали деньги там, как поступили Powersoft, KnowledgeWare, Gupta и другие.

В результате, производители баз данных борются не только против легких на подъем, независимых разработчиков-"новичков", но также против отсутствия своего опыта по разработке средств следующего поколения для клиентов. Самые последние средства разработки приложений включают целый спектр продуктов, от простых средств построения запросов, работающих по принципу "укажи-и-нажми" (point-and-shoot) и предназначенных для пользователей, таких как Quest фирмы Gupta, Forest & Trees фирмы Trinzic и PowerViewer фирмы Powersoft, до универсальных сред для профессиональных программистов, например, SQLWindows фирмы Gupta, PowerBuilder фирмы Powersoft, и ObjectView фирмы KnowledgeWare. Популярность этих продуктов третьих фирм резко возросла - особенно тех, что находятся в профессиональной категории, включающих средства с графическим интерфейсом пользователя (GUI) с полными системами языков программирования (обычно похожими на 4GL или BASIC), интероперабельностью с другими GUI-приложениями для персональных компьютеров (такими как электронные таблицы и текстовые процессоры) и программным обеспечением, преобразующим запросы в SQL для любой из широко известных сетевых платформ. Большинство из них также включает какую-либо разновидность программируемого окна типа электронной таблицы (в среде PowerBuilder такое окно называется DataWindow) для просмотра результатов запроса. Так как электронная таблица - широко известный интерфейс, хорошо подходящий для представления табличных данных, DataWindow - очень удобное средство.

Инструменты типа PowerBuilder могут также сократить время разработки и создать мощные, с привлекательным интерфейсом, и дружественные - хотя часто неэффективные - приложения (см. "GUI-based development tools", Апрель 1993). Производители реляционных СУБД теперь должны стараться изо всех сил, чтобы создать инструментарий, который либо сопоставим, либо превосходит эти образцы третьих фирм, если они хотят конкурировать в верхней части рынка средств разработки. До сих пор производителям реляционных СУБД удавалось определить пути существенного увеличения функциональности в духе PowerBuilder, но они не смогли своевременно поставить продукты, использующие эти новые идеи.

2.4. Развиваться или приобретать?

Sybase вышла на рынок средств разработки с помощью приобретения, а не в результате роста собственного опыта в этой области. В 1992 Sybase купила Gain Technologies - создателя среды визуального программирования GainMomentum. В этом продукте главное место отводилось парадигме объектно-ориентированной разработки и поддержке объектов мультимедиа. Но Gain использовала свою собственную объектно-ориентированную базу и только недавно была модифицирована для непосредственной интеграции с SQL Server фирмы Sybase. Еще одной проблемой GainMomentum является то, что она работает на рабочих станциях под Unix, а не с DOS или Windows на PC, или на Macintosh.

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

Oracle более успешно осуществляет работу по созданию инструментариев внутри фирмы, опираясь на свой большой опыт в инструментах CASE для мэйнфреймов. До настоящего времени компания создала несколько различных средств для разработки и скомпоновала их в слабо связанное семейство под общим названием Кооперативная среда разработки (CDE), которая включает в себя переносимость интерфейсов между Windows, Macintosh и Motif. Однако ни одно из средств Oracle не имеет всех желаемых свойств в одном пакете. Был модифицирован пакет Oracle Forms: от построителя форм, ориентированного на текстовые приложения, был осуществлен переход к GUI-построителю. Но пользователи должны приобретать другие пакеты для осуществления таких вещей, как генерация отчетов (Oracle Reports) и мультимедиа (Oracle Graphics).

При сравнении оказывается, что Informix имеет стратегию создания инструментария, которая будет наилучшим образом конкурировать с независимыми производителями. Так же, как и Oracle, Informix имеет много опыта по созданию средств разработчика своими силами. Но опыт Informix связан с рынком 4GL - где компания пользуется репутацией лидера, - а не с инструментами CASE. Она решила построить, непосредственно опираясь на этот опыт, средство, названное 4GL++, которое не только имеет полный набор необходимых средств, включая объектную ориентацию, средства для совместной разработки программ и полноценный отладчик, но и совместимое снизу-вверх с наиболее успешным продуктом компании - языком 4GL. (4GL++ планируется поставить к середине 1994).

Informix 4GL++ и Oracle Forms несут в себе еще одно замечательное свойство: независимость от базы данных. Оба производителя в своих соответствующих продуктах обеспечивают поддержку стандартов интероперабельности РБД, таких как ODBC. На этой основе они потенциально могут вплотную конкурировать с независимыми производителями. Informix и Oracle также подтверждают возрастающую реальность гетерогенных установок, где применяются не только их собственные продукты.

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

Как Oracle, так и Informix предлагают весьма конкурентоспособные средства, ориентированные на пользователя, для обработки запросов. Oracle Card фирмы Oracle предоставляет пользователю интерфейс к данным гипертекстового стиля - включая мультимедиа - как хорошо известный инструмент HyperCard фирмы Apple для Macintosh. HyperScript Tools фирмы Informix аналогичны, за исключением того, что они добавляют еще больше программной функциональности. И Oracle Card, и HyperScript Tools работают на множестве GUI-платформ, включая Windows, Macintosh и Motif. Oracle и Informix предлагают также средства просмотра данных с интерфейсом, схожим с электронными таблицами, Oracle Browser и электронная таблица Wingz, соответственно.

Новейшее средство ViewPoint фирмы Informix, занимает очень интересное промежуточное место в диапазоне между инструментариями для профессиональных программистов и пользователей. Средство SuperViews из ViewPoint расширяет пользовательские представления данных, по сравнению с доступными из стандартного SQL, посредством добавления более информативных соглашений об именах данных и разрешения большего количества типов соединения таблиц. Таким образом, позиция Informix состоит в том, что небольшое усилие по программированию, направленное на сокрытие несущественных деталей, приведет к тому, что база данных будет намного более полезным инструментом, обеспечивающим процесс принятия решений. Элемент ViewPoint - SuperViews - это интересный новый подход, который, тем не менее, должен пройти испытание временем на пользовательском рынке. (В настоящее время ViewPoint работает только на Windows, но Informix анонсировал свое намерение перенести его на Macintosh, Motif и Windows NT.)

Sybase не имеет сколько-нибудь серьезного продукта на рынке утилит для пользователя. InterBase, с другой стороны, похоже имеет лучший шанс при выступлении на этом поле битвы, так как у Borland, в целом, имеется больший опыт работы с пользовательским ПО, чем у какого-либо другого производителя баз данных. Компания имеет огромный опыт работы на рынке программного инструментария, будучи лидером по производству систем языков программирования для ПК. Итак, Borland расположил InterBase в центре стратегии средств разработки, что, в отличие от усилий других производителей, позволяет начать с потребностей пользователей и провести этот подход вплоть до сервера БД, а не наоборот. BOCA (Архитектура объектных компонент Borland) обещает интеграцию известных баз данных компании dBASE IV и Paradox, а также ее электронную таблицу Quattro Pro с InterBase. Однако это обещание выполняется довольно медленно. До сих пор Borland выпустила только SQL Link - клиент/сервер-интерфейс для Paradox 4.0. SQL Link дает пользователям возможность прозрачного доступа к реляционным данным на сервере. Версия SQL Link для InterBase добавляет также поддержку BLOB и других возможностей, свойственных InterBase.

Borland также опоздал с поставкой IDAPI, ответа компании на стандарт совместимости баз данных ODBC фирмы Microsoft, объединяющего функциональность реляционной СУБД c навигационными системами на базе плоских файлов, такими как dBASE. С применением IDAPI Borland подчеркнул возрастающую важность персональных баз данных, основанных на плоских файлах, в стратегиях компаний по интеграции систем масштаба предприятия. Но неспособность предоставить средства, основанного на этом ясном наблюдении, заставила многих пользователей и разработчиков - в который раз - обратиться к независимым производителям и к их решениям.

2.5. Будущее реляционных СУБД

Многие из вопросов, которые мы рассмотрели в этой статье, даже не считались важными в системах клиент/сервер первого поколения. Сегодня, однако, пользователи и разработчики требуют радикальных изменений по отношению к гетерогенной архитектуре клиент/сервер масштаба предприятия и к реляционным СУБД, которые либо удовлетворят этим требованиям, либо исчезнут. Как уже обсуждалось в первой части, в центре находится производительность: без существенных усовершенствований, привнесенных технологическими преимуществами для многопроцессорного и параллельного выполнения запросов, реляционные СУБД просто не будут в состоянии совладать с обилием транзакций, ожидаемым для будущих высоко интерактивных, распределенных систем баз данных.

Распределение данных и интероперабельность, которую мы также обсуждали в первой части, прямо связаны с переходом от гомогенных локальных сетей подразделений к гетерогенным архитектурам клиент/сервер масштаба предприятия. Только часть технологии, которую производители поставляют для решения этих проблем, относится непосредственно к серверу базы данных; многие другие решения лежат за пределами областей, традиционно обеспечиваемыми производителями баз данных. Действительно, средства разработки приложений уводят производителей реляционных СУБД еще дальше от основной области их деятельности. И проблемы, связанные со сложными типами данных и масштабируемостью, такие как механизмы репликации для распределенных баз данных, рассмотренные нами во второй части, еще только начинают осознаваться. Первые попытки их решения впечатляют, но поставщикам баз данных еще предстоит пройти долгий путь в этих областях.

Несмотря на это, все выбранные нами производители реляционных СУБД: Borland, Informix, Oracle и Sybase - достигли плато: каждый предлагает базовые возможности, которые необходимы для поддержки распределенных информационных архитектур клиент/сервер следующего поколения. Тем из вас, кто готов осуществить скачок от сетей подразделений к реляционным СУБД с архитектурой клиент/сервер масштаба предприятия, будет трудно ошибиться, ориентируясь на любого из этих поставщиков. Самые большие отличия между системами этих производителей больше связаны с совместимостью, нежели с производительностью, надежностью в работе или какими-то другими традиционными параметрами.

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

Язык PL/SQL фирмы Oracle - это наиболее продвинутый из расширений языков SQL, осуществленных производителями, и компания разработала впечатляющий набор собственных средств, что привело к созданию широкого спектра продуктов. Oracle просто нужно обеспечить, чтобы его многочисленные продукты и утилиты были соответствующим образом интегрированы; иначе он может пострадать от специфической структуры IBM, имеющей слишком много подразделений, пытающихся сделать слишком много вещей слишком мало связанных между собой. Среда CDE показывает, что Oracle движется в правильном направлении. Приобретение Borland, темной лошадки в гонке реляционных СУБД, - это InterBase, показывающий желание компании прийти к следующему поколению систем баз данных с уникального направления - от приложений пользователей и инструментов программистов к целому предприятию. InterBase имеет на самом деле некоторые уникальные черты, особенно в области программирования баз данных, она может дать им существенный рыночный толчок, но только если Borland правильно осуществит маркетинг этих продуктов. Равноправная архитектура InterBase ставит ее в превосходную позицию для разрешения загадок распределенных данных в будущем, без сомнения, потребующем более гибкого сетевого подхода, который даже превзойдет идею клиент/сервер.

Как и Oracle, Borland имеет широкий спектр отличных продуктов, которые могли бы выглядеть достаточно внушительно при условии их интеграции правильным образом. Однако, по сравнению с Oracle, у Borland есть преимущество в виде BOCA и IDAPI, которые обещают предоставить высокий уровень системной и программной интеграции. Теперь, если Borland только будет это распространять: хотя IDAPI - наиболее широко применимый стандарт интероперабельности баз данных, его задержка и аморфность привела некоторых аналитиков к отверганию его как "формирующего рынок". Borland предстоит впереди тяжелая работа по реализации своих совместимых продуктов интероперабельности в противовес утвердившемуся стандарту ODBC корпорации Microsoft.

Тем временем фирмы Sybase и Informix начали двигаться где-то с середины пути по направлению к системам следующего поколения. Обе надеются выиграть от совсем нового движения производителей открытых систем по направлению к "суперсерверам", таким как, например, SPARC-center 2000 фирмы Sun, которые, как они надеются, заменят мэйнфреймы и мини-ЭВМ. Системы, подобные этой, позволят соответствующим продуктам Sybase и Informix для серверов средней мощности вступить в мир больших денег и больших процессоров с минимальными усилиями с их стороны. Sybase и Informix также предлагают продукты для нижнего уровня спектра аппаратуры. Informix захватит рынок MS-DOS, с помощью системы Informix-SE, в то время как Sybase, чьи продукты младшего класса работают только на OS/2, выиграет от тесной связи с Microsoft. С System 10, Sybase разворачивается во всей своей мощи, как производитель архитектур клиент/сервер. Компания предпринимает несколько очень амбициозных шагов в надежде захватить лидерство в области перспективного распределения данных, включая репликацию данных, прозрачность расположения данных и PDQ. Однако вспомогательные продукты System 10 очень сложны, поэтому Sybase необходимо будет приложить максимум усилий для обучения потенциальных заказчиков. Но затраты себя оправдают, если абстракции высокого уровня, заложенные в System 10, окажутся верными для соответствия требованиям к распределению данных реального мира. Средства, распространяемые Informix, с другой стороны, просты, надежны в работе и предусмотрительны. Похоже, что они исходят из консервативной позиции, основанной на том, что сложные проблемы распределенных данных реального мира в большой степени неизвестны в настоящее время, и поэтому современные предлагаемые решения преждевременны. В результате, компания решила не затрачивать усилия на обширные решения распределения данных, а сконцентрировалась вместо этого на средствах разработки. С такими продуктами, как 4GL++ и ViewPoint, солидная репутация компании в области производства инструментария, похоже, останется хорошей и в будущем.

3. Глоссарий

Atomicity: Атомарность - гарантия, что транзакция либо выполнится до конца, либо совсем не выполнится.

Cluster: Кластер - группа компьютеров, соединенных высокоскоростной сетью, которые работают вместе как одна машина с несколькими центральными процессорами.

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

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

Parallel Query Decomposition (PDQ): Параллельная декомпозиция запросов - программный способ, при помощи которого запрос к базе данных разбивается на компоненты, которые могут быть выполнены параллельно многими процессорами.

Read consistensy: Согласованность данных по чтению - концепция, согласно которой данные, используемые одним процессом не будут некорректным образом изменены другим процессом.

Remote procedure call (RPC): Удаленный вызов процедуры - способ выполнения программы на удаленном компьютере, например, в архитектуре клиент/сервер; клиенты часто выполняют RPC на серверах.

Replication: Репликация данных - метод, при котором копии базы данных распределяются на удаленные серверы.

Schema: Схема - набор определений таблиц данных; они определяют форму для всех данных в базе.

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

Threads: Нити управления (Потоки) - Облегченные процессы, отличающиеся тем, что они могут переключаться быстрее, чем процессы в целом.

Transaction: Транзакция - завершенный набор операций с базой данных, который делает все необходимые изменения в базе, переводит базу из одного логически согласованного состояния в другое.

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

Two-phase commit (2PC): Двухфазная фиксация - механизм обеспечения атомарности транзакции. В базах с распределенными данными двухфазная фиксация используется так же, как способ, гарантирующий, что все серверы всегда хранят идентичные копии баз данных.

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

back end: База данных, расположенная на сервере.

cascade: Каскадирование - операция транзитивного замыкания, при которой действие предпринятое к записям одной таблицы данных, отражается на связанных записях данных в другой таблице. Например, когда удаляется запись из Таблицы 1, удаляются также соответствующие записи из Таблиц 2 и 3.

data view: Представление данных - "виртуальная" таблица базы данных, которая выглядит как реальная для пользователя, но на самом деле собранная из нескольких реальных таблиц.

distributed join: Распределенное соединение - связь между записями базы данных, которые хранятся в различных таблицах на разных машинах.

join: Соединение - основная операция в базах данных, которая связывает записи в одной таблице с записями в другой таблице; например, имя служащего в таблице с информацией о служащих с номером подразделения из соответствующей таблицы.

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

4. RDBMS: Фирмы-игроки

Informix OnLine 6.0, последнее предложенное кампанией ПО старшего класса, вышедшее в конце 1993 года; работает на всех основных Unix-платформах и Novell NetWare version 3.11. Informix-SE, ПО нижнего уровня, сервер базы данных, работает на MS-DOS и NetWare 2.2, так же как и на множестве Unix-платформ для ПК. Informix Software Inc., 4100 Bohannon Dr., Menlo Park, CA 94025, 415-926-6316.

InterBase 3.3 доступна для большинства Unix-платформ, VAX/VMS, и HP/Apollo Domain. Ко времени опубликования данной статьи будут доступны версии для Novell Netware 4.0 и NextStep для Intel386/486. Borland International Inc., 1800 Green Hills Rd., Scotts Valley, CA 95067-0001, 408-438-5300.

Oracle7, выпущенный в конце 1992 года, работает, как отметил мой коллега, "почти на всем, включая ящик из-под кукурузных хлопьев". Поддерживаемые платформы включают основные представляющие интерес Unix-платформы, включая SVR4 для Intel процессоров и AU/X для Macintosh, OS/2 2.1, Novell NetWare, Digital VAX OpenVMS (первичная платформа), IBM MVS и VM, и некоторые другие платформы для мэйнфреймов. Скоро должна появиться версия для Microsoft Windows NT. Oracle Corp., 500 Oracle Pkwy., Redwood Shores, CA 94065, 415-506-7000.

Sybase System 10 работает на большинстве наиболее важных Unix-платформ и VAX/VMS. Состоит из SQL Server 10, последней версии ядра базы данных, и нескольких вспомогательных продуктов, которые в основном реализованы с применением архитектуры Open Server фирмы Sybase. Sybase Inc., 6475 Christie Ave., Emeryville, CA 94608, 800-879-2273

*)Переведено и опубликовано с разрешения обладателя прав, Integrated Media Inc, San Francisco, CA, copyright 1994, из Advanced Systems Magazine, февраль 1994 года; для получения информации о подписке пошлите пустое письмо по адресу subscriptions@advanced.com.