Базы данных -> SQL -> Перспективы развития систем управления базами данных

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

Почему SQL становится международным стандартом.

Кому выгодна стандартизация SQL.

Почему стандарт SQL не имеет будущего.

Почему все СУБД будут в скором времени распределенными.

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

систем баз данных.

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

1. Введение

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

Благодаря позиции фирмы IBM, ведущая роль SQL в этом развитии не подлежит сомнению. Некоторые исследователи указывают на многочисленные серьезные недостатки SQL [Date85]. В этой статье не будут обсуждаться технические проблемы языка; наоборот, внимание будет сосредоточено на последствиях стандартизации SQL. Будет приведено краткое обсуждение того, почему появился этот стандарт. Однако, и это более важно, может случиться, что от введения стандартизации прямую выгоду получит лишь очень малое число организаций. В результате на проектирование стандар-тов затрачиваются значительные усилия, но от этого занятия будет отно-сительно небольшая окончательная польза.

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

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

И последнее, в статье подымается ряд очень серьезных проблем, с которыми приходится сталкиваться большинству пользователей СУБД. А именно, их возможности ограничены недостатками систем предыдущих поко-лений, перенесенными в современные программные средства, а также нали-чием большого количества прикладных программ, написанных на Коболе или других языках третьего поколения, обращавшихся к СУБД предыдущего по-коления (таким, как IMS и другие системы с устаревшей технологией об-работки данных, также как и СУБД собственной разработки).

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

Почему SQL?

Примерно в 1984 году началась кампания по восхвалению SQL. Перво-начально эта идея была выражена поставщиками вычислительной техники в поиске общепринятой системы управления данными. Коротко эта идея зву-чала так: "IBM делает большую ставку на DB2 и SQL. Я хочу, чтобы мои технические средства были совместимы с разработками IBM." Подобная идея высказывалась так называемыми разработчиками дополнительных прог-раммных средств (value-added resellers - VARS), которые говорили: "Я хочу, чтобы написанная мною прикладная программа работала как в вашей системе управления данными, так и в DB2." Дискуссии с VARS или постав-щиками вычислительной техники относительно того, что конкретно они имеют в виду под SQL и что конкретно они понимают под термином "сов-местимость", обычно заканчивалась ответом: "Я не знаю." Несмотря на это, преждевременные восхваления в адрес SQL продолжались произносить-ся людьми, которые конкретно не были уверены, чего же они хотят.

Позднее к хору хвалебных голосов присоединились представители крупнейших организаций-пользователей средств баз данных. Обычно идея, которую они провозглашали, была следующей: " Мне нужно, чтобы мои прикладные системы работали на вычислительных машинах фирмы IBM и на машинах фирм X, Y и Z. Я планирую опираться на DB2 как на мою основную систему фирмы IBM, и я хочу быть уверен, что написанные мною в DB2 прикладные системы могут быть перенесены на машины других перечислен-ных фирм. SQL - это механизм, который позволит мне достичь этой цели."

Поставщики коммерческих систем управления данными не так глупы. Они прислушиваются к этому хору восхвалений и реагируют соотвтетсвую-щим образом. В результате, все разработчики СУБД скоро будут реализо-вывать в своих системах SQL, если они уже этого не сделали. Более то-го, все другие языки запросов (например, QUEL, Datatrieve и другие), несмотря на привлекательность своих интеллектуальных возможностей, бу-дут превращаться в отмирающие интерфейсы, то есть они, по-видимому, постепенно исчезнут. Я хотел бы рассмотреть несколько более подробно два момента.

Во-первых, за пределами США меньше заинтересованных в стандарти-зации SQL. Фактически, зарубежные пользователи СУБД более склонны ис-пользовать языки четвертого поколения, и, следовательно, они менее за-висимы от SQL. Этот момент обсуждается далее в следующем разделе. Так-же, пользователи однородных вычислительных средств (то есть организа-ции, которые используют исключительно вычислительные средства одной конкретной фирмы) не будут заинтересованы в использовании SQL (если, конечно, они не выбрали IBM в качестве своего поставщика). Например, организации, использующие только VAX/VMS, не будут склонны иметь дело с SQL. Следовательно, степень заинтересованности в использовании SQL сильно различается в зависимости как от географических, так и от орга-низационных причин.

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

3. Кто выиграет от введения стандарта SQL

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

3.1. Уровни стандартизации

Возможны три следующие способа интерпретации SQL:

1) SQL как язык описания данных;

2) SQL как язык запросов;

3) SQL, встроенный в некоторый базовый язык.

Исходя из первой интерпретации, будут стандартизованы операторы CREATE, DROP, ALTER и другие команды управления хранением данных и создания или модификации схем. Эта часть SQL используется администра-торами баз данных, и стандартизация SQL в этой области может быть вы-годной этой группе людей.

Исходя из второй интерпретации, будет стандартизован язык запро-сов SQL. Это повлечет включение операторов SELECT, UPDATE, INSERT в список стандартных команд. При этом конечный пользователь, использую-щий стандартный SQL, вправе ожидать, что указываемые им команды SQL будут выполняться на любой СУБД, поддерживающей этот стандарт.

Исходя из третьей интерпретации, SQL будет стандартизован как вы-полняющийся в среде некоторого базового (host) языка. Этот интерфейс включает команды DECLARE CURSOR, OPEN CURSOR, FETCH, UPDATE и CLOSE CURSOR. При этом программист вправе ожидать, что его программа на ба-зовом языке будет работать во всем множестве СУБД, придерживающихся этого стандарта.

Попросту говоря, мы можем выделить следующие три уровня: уровень 1: уровень администратора баз данных; уровень 2: уровень конечного пользователя; уровень 3: уровень прикладного программиста.

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

уровень 1: никто;

уровень 2: Informix, Sybase, Unify;

уровень 3: ANSI, DB2, INGRES, ORACLE.

В результате покупатель СУБД при выборе системы управления данны-ми, основанной на SQL, должен предусмотрительно интересоваться, что в действительности означает "поддержка SQL".

Последнее, что следует отметить, это то, что языки ANSI SQL, DB2 и SQL/DS являются совершенно различными версиями языка SQL. Следова-тельно, концепция "стандартного SQL" должны быть тщательно выверена по отношению к тому, что все SQL-системы третьего уровня имеют по крайней мере минимальные различия. Это также непосредственно относится и к те-кущему состоянию рынка систем UNIX, где предлагаемые различными фирма-ми системы UNIX также имеют небольшие различия.

3.2. Кто выиграет от стандартизации SQL

3.2.1. Введение

Как упоминалось ранее, ANSI стандартизировал третий уровень ин-терфейса SQL. Такая стандартизация может быть выгодна:

- администраторам баз данных;

- конечным пользователям;

- прикладным программистам;

- разработчикам языков программирования четвертого поколения;

- разработчикам распределенных систем баз данных.

В следующих нескольких подразделах мы рассматриваем, какие из этих групп, по-видимому, выиграют от стандартизации SQL.

3.2.2. Администраторы баз данных

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

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

Во-вторых, существуют различия в хранении информации словарей данных (системных каталогов). Администратор базы данных сохраняет свою схему в каталоге, и затем он обычно желает обращаться к системным ка-талогам для получения информации о схеме. Современный стандарт ANSI не рассматривает этого аспекта, и каждая система со стандартным SQL будет иметь различные представления для словаря. Более того, существуют раз-личия в различных видах индексов и средств поддержки представлений данных, что может повлиять на детали проектирования баз данных. И пос-леднее, некоторые разработчики предлагают ключи и так называемую це-лостность ссылок (reference integrity) [DATE81], в то время как другие этого не предлагают. Современный стандарт SQL не учитывает эти разли-чия, и они ограничивают выигрыш администратора баз данных по сравнению с ожидаемым. Следует отметить, что ANSI работает над устранением неко-торых из этих недостатков, что будет подытожено в дополнении 1 к стан-дарту SQL, публикация которого ожидается в 1988 году.

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

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

3.2.3. Конечные пользователи

Так как разработки ANSI по стандартизации включают средства SQL уровня 2 как подмножество, можно заявить, что конечные пользователи выиграют, так как они могут изучить язык SQL для одной системы баз данных и затем смогут перенести свои знания в другие стандартные сис-темы баз данных. Однако за этим заявлением стоят серьезные упущения.

Во-первых, конечные пользователи не собираются использовать SQL. Исследования пользовательских характеристик м первоначальное использо-вание реляционных систем с очевидностью показали, что конечные пользо-ватели будут использовать специальный интерфейс, ориентированный на их предметные области, обычно имеющий вид "заполнения форм" [ROWE85]. Та-кие проблемно-ориентированные интерфейсы будут написаны программиста-ми. Следовательно, конечные пользователи не получат выгод от стандар-тизации SQL, так как они не хотят использовать этот язык.

Даже если конечные пользователи и используют SQL, они все же име-ют дело со значительно различающимися средствами представления данных. Например, EASE SQL в системе ORACLE очень отличается от QMF разработки IBM, хотя оба предоставляют пользователю возможность конструировать схемы и выполнять команды SQL в диалоге. Эти различия ограничат полу-чаемый выигрыш и возможности использования всего набора существующих средств.

3.2.4. Программисты

Можно утверждать, что программисты выиграют при стандартизации SQL на уровне 3, так как программы, написанные для одной SQL-системы, будут затем выполняться в другой стандартной СУБД. Более того, изучив единожды средства определения, открытия и ведения курсора для одной системы, они смогут непосредственно писать программы для других СУБД. Эти аргументы имеют серьезные недостатки.

Во-первых, эти аргументы относятся только к разработчикам, кото-рые выбрали поддержку стандарта для уровня 3. Ясно, что это не отно-сится к разработчикам Sybase, Informix, Unify и к разработчикам любых других систем, которые выбрали реализацию стандарта только на уровне

2.

Во-вторых, и, вероятно, наиболее важно, программисты не собирают-ся использовать интерфейс уровня 3. Большинство из разработчиков СУБД используют так называемые языки четвертого поколения (4 Generation Languages - 4GLs). Программные продукты, написанные на языках четвер-того поколения, включают Natural, Ramis, Adds-online, Ideal, INGRES/ABF и SQL-формы. В общем эти программные продукты позволяют программисту:

- описывать экраны;

- определять операции, которые должны выполняться как результат ввода пользователем информации в зоны экранов;

- в диалоге обращаться к подсистемам, таким, как генератор отче-тов.

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

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

С другой стороны, предположим, что пользователь решает _н_е_ ис-пользовать язык программирования четвертого поколения, так как он за-интересован в переносимости своих программ или наслышан о скудности средств программных продуктов этого поколения. Его приложения все так же требуют средств описания экрана, спецификаций отчетов и графических спецификаций. У каждого разработчика эти средства оригинальны и ника-ким образом не согласуются со стандартом SQL. Чтобы перейти от одной стандартной СУБД к другой, необходимо наново изучать средства каждой из этих областей. Как результат, SQL, стандартизованный ANSI, регла-ментирует всего лишь около 10-20% из всех спецификаций системы. Чтобы избежать необходимости такого переобучения, пользователь должен либо писать и переносить свои собственные средства в этих областях (очевид-но, это мало привлекательная стратегия), либо он должен зависеть от некоторого разработчика, специально занимающегося разработкой стандар-тного набора средств во всех важных для пользователя областях. Ясно, что SQL не может помочь в решении этой проблемы.

3.2.5. Разработчики языков четвертого поколения

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

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

1) IMS;

2) DB2;

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

поколения должен разрабатывать полный набор интерфейсов для систем 1 и

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

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

3.2.6. Разработчики неоднородных распределенных СУБД

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

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

3.2.7. Резюме

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

Администраторы             Эта группа получит выигрыш благодаря  тому  факту,

баз данных             что  во  всех реляционных базах данных естественно

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

Конечные пользо-             Эта группа не будет использовать SQL, и стандарти-

ватели             зация на ней никак не отразится.

Программисты             Эта группа будет преимущественно использовать язы-

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

Разработчики язы- Эта группа безразлична к стандартизации, если ков четвертого по- только они не производят СУБД. В таком случае коления стандартизация принесет им очень много дополни-

тельной работы.

Разработчики рас- Их позиция аналогична позиции разработчиков языков пределенных СУБД четвертого поколения.

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

4. Почему стандарт SQL обречен

4.1. Введение

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

поколение 1: иерархические и сетевые системы;

поколение 2: реляционные системы;

поколение 3: пост-реляционные системы.

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

EXODUS [CARE86];

GEM [TSUR84];

IRIS [FISH87];

NF2 [DATA86];

ORION [BANE87];

POSTGRES [STON86a];

STARBURST [LIND87].

Хотя в этих системах используются различные концепции, можно сде-лать следующее заключение:

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

Таким образом, очевидно, что предприимчивые разработчики быстро расширят свои SQL-системы реляционными версиями удачных средств этих прототипов. Идя этим путем, разработчики будут создавать системы, яв-ляющиеся существенными "надмножествами" SQL. Так как каждый разработ-чик будет делать собственные уникальные расширения, то они будут не-совместимы. Более того, фирма IBM будет медленнее всех вводить расши-рения в DB2.

Эти расширения позволят решить ряд задач, настолько важных для больших классов пользователей, что они с удовольствием будут использо-вать расширенные возможности. Таким образом, любое приложение, напи-санное пользователем в системе разработчика А, не будет выполняться без существенной переработки на системе разработчика В, и наоборот. Это в значительной мере приведет к тому, что стандарт SQL будет обре-чен как не относящийся к существу дела.

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

4.2. Управление базами знаний

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

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

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

1) Все платежные документы с суммой больше 100 долларов должен подписывать менеджер.

2) Все платежные документы с суммой больше 1000 долларов должен подписывать президент.

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

4) Все платежные документы для консультантов должны проверяться на необходимость их привлечения.

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

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

1) Поместить правила вывода в прикладную программу, а данные - в базу данных.

2) Поместить правила вывода и данные в оболочку экспертной систе-мы.

3) Поместить правила вывода в оболочку экспертной системы, а дан-ные - в базу данных.

4) Поместить и правила вывода, и данные в многокомпонентную базу данных/правил вывода.

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

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

Второй вариант - поместить и данные, и правила в среду экспертной системы, такой как Prolog, OPS 5, KEE, ART или S1. Сложностью при этом подходе является то, что во всех этих системах, без исключения, пред-полагается, что данные, доступные механизмам правил вывода, должны на-ходиться в оперативной памяти. Но помещать большую базу данных в вир-туальную память Лиспа просто непрактично. Даже если бы это было воз-можно, для такой базы данных не обеспечивается обработка транзакций, и она не может совместно использоваться несколькими пользователями. Ко-роче говоря, средства экспертных систем не включают подержку баз дан-ных, и вариант 2 просто непригоден.

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

Для соединения этих двух подсистем используется уровень "склейки" (a layer of "glue"). Примером такой архитектуры является KEE Connection из Intellicorp.

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

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

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

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

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

"Сильное сопряжение" может быть реализовано различными способами. Может быть использовано расширение средств описания представлений, также как и непосредственно расширение языка SQL [STON87]. В [ULLM85, IOAN87, ROSE86, BANC86] были исследованы алгоритмы обработки запросов для результирующих запросов. Другие алгоритмы обработки обсуждаются в [STON87, LIND87].

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

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

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

4.3. Управление объектами

Когда я в очередной раз слышу высказывание: "Объектом является все",- мне хочется кричать. Питер Бьюнеман (Peter Buneman) в [BUNE86] сформулировал эту эмоциональную реакцию более точно: "Предметно-ориен-тированный" - это семантически перегруженное понятие. Более того, во время обсуждения стендовых докладов о предметно-ориентированных базах данных (Object-Oriented Data Bases - OODBs) на конференции VLDB87, шесть участников были полностью не согласны с предлагавшимся мнением, что конкретно должна представлять собой OODB.

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

В общем, эти приложения плохо обслуживаются современными система-ми баз данных независимо от поддерживаемых в них моделей данных. Этот вопрос подробно обсуждается в [STONE83], а здесь мы рассмотрим только один очень простой пример. Предположим, пользователь хочет хранить в памяти план Манхэттена, то есть множество данных, состоящих из двумер-ных прямоугольных блоков. Очевидно, блок может быть представлен коор-динатами своих двух угловых точек (X1,Y1) и (X2,Y2). Следовательно, приемлемой схемой для этих данных будет отношение БЛОК, построенное следующим образом:

БЛОК (имя,X1,Y1,X2,Y2)

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

select *

from БЛОК

where X1<=1 and

X2>=0 and

Y1<=1 and

Y2>=0

Более того, обычно необходимо несколько попыток, прежде чем опыт-ный пользователь SQL придет к этому представлению. Следовательно, трудно программировать даже тривиальные запросы. Кроме того, не имеет значения, какой набор В-деревьев или хэш-индексов строится по каждому ключу или набору ключей. Этот запрос потребует времени для проверки по некоторому индексу, в среднем, половины из всех индексированных запи-сей. Если имеется 1 000 000 блоков, то по среднему запросу должны быть просмотрены 500 000 записей. С уверенностью можно сказать, что это приведет к плохой производительности даже на очень большой машине.

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

1) Поддержка "блока" как типа данных. Таким образом, отношение БЛОК будет иметь теперь только два поля, например:

БЛОК (имя,описание)

2) Поддержка && как оператора SQL, означающего наложение шаблона. Таким образом, рассматриваемый запрос может быть выражен так:

select *

from БЛОК

where описание && "(0,0),(1,1)"

3) Поддержка пространственного метода доступа, такого как R-де-ревья [GUTM84] или K-D-B-деревья [ROBI81]. Это дает нам уверенность в том, что введенная выше как расширение SQL команда будет эффективно выполняться.

Предложения в этом направлении содержатся в [STON86b, CARE86, BANE87, FISH87], и в ближайшее время они будут внесены в промышленно эксплуатируемые системы. Предприимчивые разработчики будут включать такие средства как расширения SQL.

4.4. Резюме

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

Основным выводом является то, что стандартизация проводится в не-подходящий период в эволюции интерфейсов СУБД. Это можно увидеть на примере стандартизации Фортрана. Этот язык был разработан в начале пя-тидесятых годов, и затем прошел через период примерно 15-ти лет "вы-держки", прежде чем был начат процесс стандартизации. Следовательно, стандартизация была начата после того, как был накоплен огромный опыт работы с этим языком, и лишь затем язык был "упорядочен". Конечно, предварительная стандартизация Фортрана 2 в середине 50-х была большой ошибкой, очевидной задержкой в развитии языка и препятствием к его ши-рокому распространению.

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

В завершение этого раздела мы прокомменируем SQL-2, предложенный как последующий стандарт, разрабатываемый ANSI. Эта разработка предла-гает возможности, такие как синтаксис "если-то-иначе" и использование данных типа интервалов, которые в настоящее время не реализованы ни в одной SQL-системе. Более того, это расширение спроектировано так, что-бы оно было полностью совместимым подмножеством существующего стандар-та SQL. Таким образом, целью является вести за собой рынок, предлагая стандарт в качестве некоторого "маяка", на который разработчики должны ориентироваться. Это напоминает стандартизацию языка программирования ADA, которая выполнялась подобным образом. Принцип "маяка" хорош для новых языков, которые стандартизируются во избежание недостатков при разработке их реализации, в то время как принцип "выдержки" подходит для более старых языков, развивающихся как важный, представляющий ин-терес продукт исходя из потребностей рынка.

Конечно, для ANSI возможно переключение с принципа "маяка" на принцип "выдержки" при доработке нового языка. Это вполне может прои-зойти в последующем развитии языка программирования ADA. Однако, есть небольшой умозрительный аргумент за переход от принципа "выдержки" к принципу "маяка", так как "выдержанный" язык всегда будет содержать "огрехи прошлого", которые будут препятствовать попыткам использовать его как маяк. По этой причине никогда не будет предложено строить но-вый язык, например, такой как ADA, путем расширения языка Фортран-77. Однако это именно то, что пытается делать ANSI в разработке SQL-2, и я должен выразить свою убежденную оппозицию их концепции. Они должны ли-бо "выдержать" современную версию SQL, пока разработчики не расширят его возможности, либо они должны в качестве "маяка" предоставить новый язык, не основанный на ошибках проектирования SQL.

Конечно, подход "маяка" имеет очень мало шансов на успех, если его не поддерживает значительная сила (например, DOD, IBM). На совре-менном рынке систем баз данных такая сила, повидимому, отсутствует, поэтому я порекомендовал бы ANSI придерживаться принципа "выдержки".

5. Распределенные базы данных

5.1. Почему распределенные СУБД?

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

1) либо сетевой файловой системой (network file system - NFS),

2) либо распределенной СУБД.

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

Рассмотрим пользователя в Сан-Франциско, обращающегося к отноше-нию EMP, содержащему сведения о служащих и ноходящемуся в Лондоне, и к отношению DEPT, содержащему сведения об отделениях фирмы и находящему-ся в Гонконге. Чтобы найти имена служащих нижнего уровня с использова-нием сетевой файловой системы, оба отношения будут постранично переда-ны по сети, и операция объединения будет выполнена в Сан-Франциско. При использовании распределенной СУБД эвристический оптимизатор выбе-рет интеллектуальную стратегию доступа и, возможно, предпочтет перес-лать сведения об отделениях нижнего уровня в Лондон, выполнить там об-ъединение, и затем переслать конечный результат в Сан-Франциско. Эта стратегия в общем будет выполняться на много порядков быстрее, чем стратегия сетевой файловой системы. Как однажды сказал Билл Джой (Bill Joy):

"Думайте об удаленных процедурах, а не об удаленных данных."

Иначе говоря, можно посылать запросы к данным, а не данные к зап-росам.

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

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

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

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

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

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

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

5.2. Аспекты исследований в области распределенных СУБД

Было проведено огромное количество исследований по алгоритмам поддержки распределенных баз данных в областях обработки запросов [SELI80], управления параллельным доступом [BERN81], восстановления после сбоев [SKEE82] и одновременного обновления нескольких копий фай-лов [DAVI85]. В этом разделе я выделяю две важные проблемы, требующие дальнейших исследований.

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

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

6. Другие технологии

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

6.1. Машины баз данных

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

1 млн.операций/в секунду = 2**(год - 1984)

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

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

6.2. Системы с высокой частотой транзакций

Ясно, что для создания приложений, состоящих в основном из повто-ряющихся транзакций, каждая из которых является набором обращающихся к одной записи команд SQL, будут использоваться системы реляционных баз данных. Целью является выполнять 100, 500 или даже 1000 таких транзак-ций в секунду. Для большинства реляционных систем достигается все воз-растающая быстрота ответов, и это будет продолжаться в течение следую-щих нескольких лет. Более того, все коммерческие системы имеют, по су-ти, одинаковую архитектуру, так что любая уловка, используемая одним разработчиком для повышения производительности, может быть быстро ско-пирована другими разработчиками. Таким образом, "борьба за производи-тельность" постепенно превращается в нечто вроде "чехарды", и победи-телем на данный момент является обычно разработчик, предложивший новую систему последним. Более того, ожидается, что все системы будут разви-ваться, по сути, по направлению к достижению такой же максимальной производительности.

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

6.3. Базы данных в оперативной памяти

Происходит быстрое падение не только стоимости процессоров на миллион операций в секунду, но также и цены на оперативную память на-ходятся в "свободном падении". В настоящее время везде, где есть кон-куренция, цены на 1 Мбайт в большинстве вычислительных машин ниже 1 тыс. долларов, и продолжают падать. Более того, максимальный объем оперативной памяти, который может быть заложен в вычислительной маши-не, стремительно возрастает - обратно пропорционально стоимости. Это все больше позволяет размещать базы данных полностью (или почти пол-ностью) в оперативной памяти. Для современных СУБД типично проектиро-вание в предположении, что все (или большая часть) данных находится на диске. Как результат, в них должны были создаваться средства для эф-фективной обработки очень больших буферных областей, для реализации стратегий обработки хэш-соединений данных [SHAP86] и для эффективного ведения обработки протоколов (которые имеют место только при обработке операций ввода/вывода, преобладающих в такой конфигурации).

Привлекательна   также   возможность   использования

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

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

6.4. Архитектура новых запоминающих устройств

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

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

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

Эффективное использование наборов дисководов - это благодатная область для дальнейших исследований.

7. Как достичь независимости от поставщиков программного обеспечения и технических средств

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

7.1. Шаг 1: перейти в реляционную среду

Первым шагом для клиента является заменить свою систему управле-ния данными системой современного поколения. Многие компании уже расс-матривают именно этот вид перехода, и для выполнения этого шага сущес-твует несколько стратегий. В этом подразделе мы обсудим один из воз-можных подходов. Рассмотрим приобретение пользователем распределенной системы баз данных, позволяющей, чтобы данные в локальных базах данных управлялись различными локальными системами управления данными. Такая "открытая технология" распределенных систем управления данными имеет-ся, по крайней мере, в Relational Technology и в Oracle и, без сомне-ния, будет скоро и у других. Следовательно, пользователь из нашего примера должен рассматривать приобретение распределенной СУБД, управ-ляющей локальными данными как в IMS, так и в реляционной системе уп-равления данными, в которую он собирается переносить свои данные. Имея такое программное обеспечение, он может выполнять следующие виды прог-рамм:

- старые прикладные программы, которые могут выполняться непос-редственно на локальных базах данных под управлением IMS;

- новые прикладные программы, которые могут выполняться непосред-ственно в среде новой целевой реляционной СУБД;

- кроссовые прикладные программы для СУБД, которые могут выпол-няться с использованием распределенной СУБД.

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

7.2. Шаг 2: купить рабочую станцию

В ближайшем будущем все терминалы типа "экранного телетайпа" бу-дут неизбежно заменены рабочими станциями. Таким обраом, терминалы ти-па 3270 станут антикварной редкостью и будут заменены новыми устройст-вами, а именно вычислительными машинами типа Vaxstation 3000, Sun 3, PC/RT, Apollo, Macintosh или PS/2. Пользователи заменят свои терминалы рабочими станциями по двум причинам:

1) чтобы получить улучшенный человеко-машинный интерфейс;

2) ввиду стоимости.

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

Второй причиной, по которой служащим устанавливаются рабочие станции, является то, что она обеспечивает перенос прикладных программ из главной машины (например, IBM/370), для которой стоимость превышает 100 000 долларов на 1 млн.операций, на рабочую станцию, стоимость для которой, возможно, 1000 долларов на 1 млн.операций. Общая экономия средств может быть ошеломляющей.

По какой из этих двух причин, ради улучшения человеко-машинного интерфейса или из соображений стоимости, пользователь решил переходить к рабочей станции, не имеет значения. Чтобы использовать получаемые преимущества, необходимо переносить прикладные программы с IBM/370 на рабочую станцию. Более того, единственный разумный путь сделать это - переписать их полностью, чтобы заменить "печать до конца экрана" на меню-подобный оконный тип интерфейса с побитовым отображением информа-ции и использованием манипулятора типа "мышь". При перепрограммирова-нии также следует перенести программы из CICS в некоторую другую прог-раммную среду (например, Unix, OS/2, Apple OS и так далее). Это ведет к шагу 3.

7.3. Шаг 3: переписать прикладные программы

Какая бы ни была тому причина, но пользователь должен перенести прикладные программы из среды CICS на рабочую станцию. Конечно, поль-зователь может использовать окно на рабочей станции, связанное с CICS, которое просто моделирует терминал 3270. Таким образом, пользователь может постепенно переносить свои прикладные системы в новую среду, в то время как старые программы продолжают выполняться в среде CICS пос-редством моделирования на рабочей станции интерфейса "экранного теле-тайпа". К некоторому моменту все прикладные программы из CICS будут переписаны, и на ЭВМ IBM/370 останется только реляционная СУБД. Конеч-но, такой переход может занять годы (или даже десятиления). Однако, настойчивый пользователь может продвигаться со скоростью, соответству-ющей его ресурсам. В конце концов это приведет к шагу 4.

7.4. Шаг 4: движение к мышлению в терминах обслуживающий модулей (серверов)

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

- рабочие станции являются обслуживающими (server) для прикладных программ;

- разделяемые главные ЭВМ являются обслуживающими для SQL (SQL servers).

Более того, под модулем, обслуживающим SQL, должен пониматься то-варный продукт. В силу того, что пользователь остается в рамках стан-дартного SQL, определенного ANSI, должно быть возможным заменять обс-луживающий SQL модуль, созданный одним разработчиком (в данном случае фирмой IBM), обслуживающим SQL модулем, купленным у другого разработ-чика (скажем, DEC), или даже набором обслуживающих модулей, работающих в системе распределенных баз данных (скажем, в сети вычислительных ма-шин Sun). Независимость от разработчика обеспечена, так как теперь очень просто приобрести SQL-модуль у разработчика, предлагающего самый лучший по стоимости/производительности/надежности пакет. Если разра-ботчик одного из вариантов не в состоянии обеспечить то же увеличение производительности, что и его конкуренты, то совсем не трудно отка-заться от вычислительной машины этого поставщика и заменить ее другой, созданной одним из его конкурентов, предлагающим самую высокую эффек-тивность.

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

7.5. Резюме

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

- реляционную СУБД;

- операционную систему для рабочей станции;

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

- сетевые технические средства и программное обеспечение;

- язык программирования прикладных программ.

Покупатель фирмы IBM, ориентируемый, конечно, коммивояжерами фир-мы, выберет следующее:

- реляционную СУБД: DB2 плюс СУБД расширенной версии OS 2;

- операционную систему для рабочей станции: OS 2;

- систему управления окнами: IBM Presentatiom Manager;

- сетевое и программное обеспечение: SNA;

- язык программирования прикладных программ: COBOL (?).

Вдобавок, его убедят в достоинствах SAA как части его решения. Если пользователь продвигается в этом направлении, то он достигнет не-зависимости от технических средств, по крайней мере в некотрой степе-ни.

Он может покупать рабочие станции любой из дочерних фирм и может использовать средства SQL, работающие на различных технических средст-вах фирмы IBM (например, System 36, 38, 370 и так далее).

Однако, пользователь может сделать выбор и альтернативной сово-купности вариантов:

- реляционная СУБД: одна из разработок независимых поставщиков;

- операционная система для рабочей станции: Unix;

- система управления окнами: X Window System;

- сетевое программное обеспечение: TCP/IP;

- язык программирования прикладных программ: C.

Сделав такой выбор, пользователь может быть уверен в том, что он может покупать обслуживающие модули для прикладных программ по крайней мере у следующих компаний: DEC, DG, IBM, HP, Sun, Apollo, ICL, Bull, Siemans, Sequent, Pyramid, Gould и их дочерних отделений.

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

7.6. Пересмотренные стандарты

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

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

Л и т е р а т у р а

[BANE86]  Banerjee, J. at.al., "Semantics and Implementation of Schema

Evolution in Object-oriented Databases," Proc. 1987 ACM-SIGMOD Conference on Management of Data, San Francisco, Ca., May 1897.

[BANC86] Bancilhon, F. and Ramakrishnan, R., "An Amateur's Introduction to Recursive Query Processing Stratagies," Proc. 1986 ACM-SIGMOD Conference on Management of Data, Washington, D.C., May 1986.

[BERN81]  Bernstein,  P.  and  Goodman,  N.  "Concurrency  Control  in

Database Systems," Computing Surveys, June 1981.

[BUNE86]  Buneman, P. and Atkinson, M. "Inheritance and Persistence in

Database Programming Languages," Proc. 1986 ACM-SIGMOD Conferense on Management of Data, Washington, D.C., May

1986.

[CARE86] Carey, M., et. al., "The Architecture of the EXODUS Extensible DBMS," Proc. International Workshop on Object-Oriented Database Systems, Pacific Grove, Ca., September 1986.

[DADA86]  Dadams, P.  et.  al.,  "A  DBMS  Prototype  to  Support  NF2

Relations," Proc. 1986 ACM-SIGMOD Conference on Management of Data, Washington, D.C., May 1986.

[Date81]  Date,   C.,             "Referential   Integrity,"  Proc.  1981  VLDB

Conference, Cannes, France, Sept. 1981.

[DATE85]  Date, C., "A Critique of SQL," SIGMOD Record, January, 1985.

[DAVI85] Davidson, S. et. al., "Consistency in Partitioned Networks," Computing Surveys, Sept. 1985.

[FISH87]  Fishman,  D.  et.  al.,  "Iris:  An Object-Oriented Database

Management System," ACM-TOOIS, January, 1987.

[GUTM84]  Gutman, A., "R-trees: A Dynamic Index Structure for  Spatial

Searching," Proc. 1984 ACM-SIGMOD Conference on Management of Data, Boston, Mass., June 1984.

[IOAN87] Ioannidis, Y. and Wong E., "Query Optimization Through Simulated Annealing," Proc. 1987 ACM-SIGMOD Conference on Management of Data, San Francisco, Ca., May 1987.

[LIND87]  Lindsay, B., "A  Data  Management  Extension  Architecture,"

Proc. 1987 ACM-SIGMOD Conference on Management of Data, San Francisco, Ca., May 1987.

[ROBI81] Robinson, J., "The K-D-B Tree: A Search Structure for Large Multidimensional Indexes," Proc. 1981 ACM-SIGMOD Conference on Management of Data, Ann Arbor, Mich., May 1981.

[ROSE86]  Rosenthal,  A.  et.  al.,  "Traversal Recursion: A Practical

Approach to Supporting Recursive Applications," Proc. 1986 ACM-SIGMOD Conference on Management of Data, Washington,

D.C., May 1986.

[ROWE85] Rowe, L., "Fill-in-the-form Programming," Proc. 1985 Very Large Data Base Conference, Stockholm, Sweden, August 1985.

[SELI80]  Selinger, P. and Adiba, M.,  "Access  Path  Selection  in  a

Distributed Database Management System," PROC ICOD, Aberdeen, Scotland, July 1980.

[SHAP86] Shapiro, L., "Join Processing in Database Systems with Large Main Memories," ACM-TODS, Sept. 1986.

[SKEE82]  Skeen,  D.,  "Non-blocking  Commit  Protocols,"  Proc.  1982

ACM-SIGMOD Conference on Management of Data, Ann Arbor, Mich., May 1982.

[STON83] Stonebraker, M., et.al., "Application of Abstract Data Types and Abstract Indexes to CAD Data," Proc. Engineering Applications Stream of 1983 Data Base Week, San Jose, Ca., May 1983.

[STON86a] Stonebraker, M. and Rowe,  L.,  "The  Design  of  POSTGRES,"

Proc. 1986 ACM-SIGMOD Conference on Management of Data, Washington, D.C., May 1986.

[STON86b] Stonebraker, M., "Inclusion of New Types in Relational Data Base Systems," Proc. Second International Conference on Data Engineering, Los Angeles, Ca., Feb. 1986.

[STON87]  Stonebraker, M.  et.  al., "The Design of the POSTGRES Rules

System," Proc. 1987 IEEE Data Engineering Conference, Los Angeles, Ca., Feb. 1987.

[TSUR84] TSUR, S. and Zaniolo, C., "An Implementation of GEM - Supporting a Semantic Data Model on a Relational Back-end," Proc. 1984 ACM-SIGMOD Conference on Management of Data, Boston, Mass., June 1984.

[ULLM85]  Ullman,  J.,  "Implementation  of Logical Query Language for

Data   Bases,"   Proceedings   of   the   1985      ACM-SIGMOD

International Conference on Management of Data, Austin, TX, May 1985.