Иными словами, любая СУБД, рассчитывающая на широкую сферу применения, должна быть оснащена языком четвертого поколения (4GL ), разнообразными инструментами поддержки принятия решений, дружественным доступом из многих языков программирования, дружественным доступом из популярных подсистем, таких как LOTUS 1-2-3, интерфейсами с графическими бизнес-пакетами, возможностью запуска приложений из базы данных на другой машине и возможностью организации распределенной базы данных. Весь набор инструментов и СУБД должен эффективно функционировать на разнообразных аппаратных платформах с различными операционными системами.
Из этой посылки исходят два следствия. Во-первых, любая удачная система третьего поколения должна поддерживать большую часть перечисленного инструментария. Во-вторых, СУБД третьего поколения должны быть открытыми, то есть должны допускать реализацию доступа из дополнительных инструментов, функционирующих в различных средах. Более того, каждая система третьего поколения должна легко объединяться с другими СУБД для создания распределенных систем баз данных.
Во Втором манифесте выдвигались три группы детальных предложений, которым, по мнению авторов манифеста, должны были следовать удачные образцы систем баз данных третьего поколения 90-х годов. Предложения первой группы следуют из принципа 1 и уточняют требования к управлению объектами и правилами. Во второй группе содержится набор предложений, являющихся следствием того, что системы третьего поколения должны включать в себя системы второго поколения. Наконец, в третью группу сведены предложения, исходящие из требования открытости систем третьего поколения.
Авторы Манифеста баз данных следующего поколения во многом согласны с энтузиастами ООБД. Среди общих тем выделяются выгодность использования богатой системы типов, функций, наследования и инкапсуляции. Однако во многих областях позиции прямо противоположны. Во-первых, Манифест объектно-ориентированных баз данных слишком узко сфокусирован на вопросах управления объектами. Авторы Второго манифеста обращаются к более широкому кругу вопросов, включающих поддержку управления данными, правилами и объектами на основе полного набора инструментов при наличии интеграции СУБД и языка запросов в многоязычную среду. Предлагаемые многими энтузиастами ООБД одноязычные системы, не поддерживающие SQL , привлекательны лишь для довольно узкого рынка.
Во-вторых, представляется, что доступ к СУБД должен осуществляться при помощи языка запросов, и история подтверждают правильность такой точки зрения. Следует избегать физической навигации, выполняемой программами пользователей или происходящей внутри функций. В-третьих, необходимо всячески поощрять использование автоматических наборов, так как они предоставляют массу преимуществ по сравнению с явно поддерживаемыми наборами. В-четвертых, свойство стабильности данных может быть добавлено ко многим языкам программирования. Поскольку не существует языка программирования, аналогичного эсперанто, этого следует достигать путем изменения компилятора и написания специфичной для языка системы времени выполнения, взаимодействующей с единой СУБД. Таким образом, языки программирования с поддержкой стабильных данных мало связаны с моделями данных. В-пятых, уникальные идентификаторы должны задаваться либо пользователем, либо системой (здесь наличествует противоречие с одним из принципов Первого манифеста).
Второй манифест (или, вернее, работы, приведшие к его появлению) имел важные последствия. В 1995 г. компания Informix (ныне входящая в состав IBM ) купила компанию Майкла Стоунбрейкера Illustra, и Стоунбрейкер стал техническим директором Informix . В начале 1996 г. компания Informix объявила о выпуске принципиально нового продукта Informix Universal Server , в котором, как утверждала компания, сочетались лучшие черты Informix Online Server с развитыми объектными чертами, присущими Illustra .
К выпуску Informix Universal Server очень ревниво отнеслась компания Oracle , которая немедленно заявила, что у нее готов собственный объектно-реляционный продукт, по всем параметрам превосходящий систему компании Informix . Эта система, получившая название Oracle 8, была выпущена в конце лета 1996 г.
Годом позже группе производителей объектно-реляционных СУБД примкнула компания IBM , выпустившая продукт DB 2 Universal Database . (Как выяснилось позже – см., например, [11] – все наиболее важные свойства этого продукта были реализованы еще в 1995 г. в СУБД DB 2 for Common Servers. Просто компания IBM предпочла до поры не афишировать свои расширения.)
Первые пару лет вокруг объектно-реляционных СУБД стоял большой шум. Позже выяснилось, что маркетинговые ожидания компаний-гигантов оказались преувеличенными. (В частности, это было одной из основных причин падения компании Informix .) Сегодня объектные расширения SQL -ориентированных СУБД предлагаются пользователям лишь в качестве дополнительных, хотя и важных возможностей.
Объектные расширения языка SQL были зафиксированы в стандарте SQL :1999. В той или иной мере эти расширения поддерживаются во всех трех перечисленных выше продуктах. В настоящее время ближе всех к стандарту находятся продукты компании Oracle .
В марте 1995 г. была впервые официально опубликована статья Хью Дарвена и Кристофера Дейта, названная авторами “Третьим манифестом”.
Авторы статьи ищут прочные основы для будущего управления данными. При этом Хью Дарвена и Кристофера Дейта считают, во-первых, что такие основы не способен обеспечить язык баз данных SQL, во-вторых, любые такие основы должны твердо корениться в реляционной модели данных, впервые представленной миру Э.Ф.Коддом в 1969 году. При этом авторы сознают ценность поддержки горячо обсуждаемых возможностей объектно-ориентированного подхода, называя их «ортогональными реляционной модели». И в силу этого, следовательно, реляционная модель не нуждается в каких-либо расширении, коррекции или категоризации, а самое главное, в каких-либо искажениях для того, чтобы внедрить указанные возможности в какой-либо язык баз данных, способный представлять те основы, которые мы ищем. Основу Манифеста представляет описание такого языка, «Допустим, что такой язык имеется и называется D». Авторы приводят предписания и запреты языка D. Некоторые из этих предписаний проистекают из реляционной модели данных, и названы РМ-предписаниями. Предписания, которые не происходят из реляционной модели, названы остальными ортогональными предписаниями – ОО-предписаниями. Подобным же образом категоризованы и запреты для языка D.
Авторы отмечают, что РМ-предписания и запрещеты не могут быть предметом компромисса, что не относится к ОО-предписаниям и запретоам, поскольку не существует ясной и общепринятой модели, на которой они могли бы базироваться. Наряду с предписаниями и запретами этот манифест включает также некоторые весьма настоятельные предложения, также подразделяющиеся на РМ- и ОО-категории.
Рассмотрим некоторые РМ-предписания.
1. Домен – это именованное множество значений. Манипулирование такими значениями, которые могут быть произвольной сложности, должно быть возможно исключительно посредством операций, определенных для этого домена (этих доменов), т.е. значения домена должны быть инкапсулированы. Для каждого домена должна быть доступна нотация, позволяющая явно специфицировать (или "конструировать") произвольное значение из этого домена. Домен, тип данных, объектный класс – синонимы.
Обобщенно мы называем значения домена скалярными значениями (или для краткости скалярами). Допускаются "скалярные" значения произвольной сложности. Таким образом, например, массив стеков списков и т.д. в соответствующих обстоятельствах может рассматриваться как скалярное значение.
2. Скалярное значение всегда должно появляться с некоторой сопутствующей идентификацией того домена, к которому относится это значение. Иными словами, скалярные значения должны быть типизированы.
3. Для каждого упорядоченного списка n доменов, не обязательно различных (n ≥ 0), в D должны поддерживаться определения допустимых n-адических операций, которые применимы к соответствующим упорядоченным спискам из n значений, взятых по одному из каждого из этих n доменов. Определение каждого такого оператора должно включать спецификацию домена результата этой операции. Определения таких операций должны быть логически отделены от определений доменов, к которым они относятся (а не быть "встроенными" в эти определения). Термины операция, функция и метод, в данном случае, – синонимы.
4. Пусть V – некоторый домен. В состав определенных для V операций должны обязательно входить такие операции, явным назначением которых является раскрытие действительных представлений (actual representation) значений из V. Заметим, что эти операции – и только они – нарушают, таким образом, инкапсуляцию значений из V.
Целью этого предписания является возможность скрыть реальное представление значений домена от большинства пользователей. При наличии таких операций пользователь по сути будет способен оперировать значениями из V точно так же, как если бы он имел дело с фактическим представлением.
Если v1 и v2 – разные значения из домена V, ничто в языке D не требует, чтобы реальные представления v1 и v2 были бы одной и той же формы. Например, V может быть доменом "текст", а v1 и v2 – двумя документами, подготовленными с использованием разных текстовых процессоров.
5. D должен поставляться оснащенным некоторыми стандартными (встроенными) доменами, включающими, в частности, домен истинностных значений (true и false). Для этого домена должны поддерживаться обычные операции (NOT, AND, OR, IF ... THEN ..., IFF и т.д.).
6. Пусть H – некоторый заголовок кортежа (tuple heading), тогда должна существовать возможность определить домен, значения которого являются кортежами с заголовком H, – иными словами, TUPLE должен быть допустимым конструктором типов. Определенные для такого домена операции должны в точности составлять набор операций над кортежами (tuple operators), поддерживаемых D. Он включает операцию конструирования кортежа из указанных скаляров, а также операцию извлечения из кортежа указанных скаляров. Должны также включаться средства "вкладывания" и "выкладывания" ("nest"/"unnest") кортежей.
7. Пусть H – некоторый заголовок отношения, тогда должна существовать возможность определения домена, значениями которого являются отношениями с заголовком H. Иными словами, RELATION должен быть допустимым конструктором типов. Операции, определенные для такого домена, должны в точности представлять собой множество операций над отношениями, поддерживаемых D. В их число должна входить операция конструирования отношения из указанных кортежей, а также операция извлечения из отношения указанных кортежей. Должны иметься также возможности "вкладывания" и "выкладывания" ("nest"/"unnest") вложенных отношений.
8. Для каждого домена должен быть определен оператор сравнения на равенство (equals, "=").
9. Кортеж t – это множество упорядоченных триплетов вида <A,V,v>, где:
· A – имя атрибута t. Никакие два различных триплета в t не должны содержать одно и то же имя атрибута;
· V – имя (единственного) домена, соответствующего атрибуту A;
· v – некоторое значение из домена V, называемое значением атрибута A в кортеже t.
Множество упорядоченных пар <A,V>, которое получается в результате исключения компонента (значения) v из каждого триплета в t, представляет собой заголовок t. При заданном заголовке кортежа должна быть доступна нотация, позволяющая явно специфицировать (или "сконструировать") произвольный кортеж с таким заголовком.
10. Отношение R состоит из заголовка и тела. Заголовок R – это заголовок кортежа H, определенный в РМ-предписании 9. Тело R – это множество B кортежей таких, что все они имеют заголовок H. Атрибуты и соответствующие домены, указанные в H, – это атрибуты и соответствующие им домены R. При заданном заголовке отношения должна быть доступна нотация, позволяющая явным образом специфицировать (или "сконструировать") произвольное отношение с этим заголовком.
11. Скалярная переменная типа V – это переменная, допустимыми значениями которой являются скаляры из указанного домена V – объявленного домена (declared domain) для этой скалярной переменной. Создание скалярной переменной S должно приводить к инициализации S некоторым начальным скалярным значением – либо значением, явно специфицированным в операции создания S, либо некоторым значением, зависящим от реализации, если никакое значение явно не указано.
12. Кортежная переменная (tuple variable) типа H – это переменная, допустимыми значениями которой являются кортежи с указанным заголовком кортежа H – объявленным заголовком (declared heading) для этой кортежной переменной. Создание кортежной переменной T должно приводить к инициализации T некоторым начальным кортежным значением – либо значением, явно специфицированным в операции создания T, либо некоторым значением, зависящим от реализации, если никакое значение явно не указано.
13. Переменная отношения (relation variable) – для краткости R-переменная (relvar) – типа H – это переменная, допустимыми значениями которой являются отношения с указанным заголовком отношения H – объявленным заголовком для этой relvar.
14. Relvar могут быть базовыми (base) либо производными (derived). Производная relvar – это такая relvar, значение которой в любой заданный момент времени представляет собой отношение, определяемое посредством заданного реляционного выражения. Базовая relvar – это relvar, которая не является производной. Создание базовой relvar должно приводить к инициализации этой базовой relvar некоторым пустым отношением.
Базовые и производные relvar соответствуют тому, что обычно называется "базовыми отношениями" и "обновляемыми представлениями" соответственно.
15. Переменная базы данных (database variable) – dbvar – это именованное множество relvar. Каждая dbvar является предметом набора ограничений целостности. Значение данной dbvar в любой заданный момент времени представляет собой множество упорядоченных пар <R,r> (где R – имя relvar, а r – текущее значение этой переменной) таких, что: a) в этой dbvar существует одна такая упорядоченная пара для каждой relvar; b) эти значения relvar одновременно удовлетворяют соответствующим ограничениям. Такое значение dbvar называется базой данных (иногда состоянием базы данных, но мы не используем этот более поздний термин).
Каждая транзакция взаимодействует в точности с одной dbvar. Однако разные транзакции могут взаимодействовать с разными dbvar, и разные dbvar не обязательно являются непересекающимися. Кроме того, транзакция может динамически изменять ассоциированную с нею dbvar, добавляя и/или удаляя relvar.
В языке D должен обеспечиваться операции для создания (create) и разрушения (destroy) доменов, переменных (в том числе relvar) и ограничений целостности. Каждые явно созданные домен, переменная или ограничение целостности должны быть именованными. Каждая базовая relvar должна иметь, по крайней мере, один возможный ключ (candidate key), явно специфицированный в той операции, которая создает эту базовую relvar.
Создание и разрушение dbvar (которые, как мы предполагаем, должны быть "стабильными" (persistent) осуществляется вне среды языка D.
Многие РМ-запреты являются логическими следствиями РМ-предписаний.
Рассмотрим некоторые ОО-предписания.
1. В языке D должна допускаться проверка типов на стадии компиляции.
2. Простое наследование (Single Inheritance). Если язык D позволяет определять некоторый домен V' как поддомен некоторого супердомена V, то такая возможность должна соответствовать некоторой ясно определенной и общепринятой модели.
3. Множественное наследование (Multiple Inheritance). Если в языке D допускается определение некоторого домена V' как поддомена какого-либо супердомена V, то не следует препятствовать также и тому, чтобы V' мог быть дополнительно определен как поддомен и некоторого другого супердомена W, который не совпадает с V и не является каким-либо его супердоменом (если только требования ОО-предписания 2 не исключают такую возможность).
4. Язык D должен обладать вычислительной полнотой. Это означает, что D может, что не обязательно, поддерживать вызовы из так называемых "основных программ" (host program), написанных на языках, отличных от D. Подобным же образом, D может, что не обязательно, поддерживать использование других языков программирования для реализации функций, определяемых пользователем.
Идея состоит в том, что вычислительная полнота будет требоваться (в общем случае) для реализации функций, определяемых пользователем, и более удобно иметь возможность реализовать такие функции в самом D, чем по необходимости обращаться к другим языкам.
6. В языке D должны поддерживаться вложенные транзакции (nested transactions) – т.е. должно допускаться, чтобы какая-либо транзакция T1 могла начать другую транзакцию T2 до завершения собственного выполнения. При этом, откат T1 должен включать отмену результатов T2, даже если T2 была зафиксирована.
Рассмотрим ОО-запреты.
1. Relvar не являются доменами. Иными словами, категорически отвергается равенство вида "отношение = объектный класс".
2. Никакое значение (скалярное или любого другого вида) не должно обладать какого-либо рода идентификатором (ID), который как-либо отличается от значения самого по себе.
Иными словами, мы отвергается идея "объектных идентификаторов" (object ID). Как следствие, отвергается: a) идея о том, что "объекты" могли бы использовать такие идентификаторы для совместного использования "подобъектов"; b) идея о том, что пользователи могли бы вынуждаться "разыменовывать" (dereference) такие идентификаторы (либо явно, либо неявно), чтобы получать значения.
Отвергается идея "идентификаторов кортежей" (tuple ID).
Этот запрет не препятствует тому, чтобы объекты вне dbvar обладали идентификаторами, которые являются "каким-либо образом отличными" от самих объектов. Он также не препятствует появлению таких идентификаторов в dbvar. Поэтому, например, домен имен файлов базовой операционной системы является допустимым доменом.
3. Любая нотация "публичной переменной экземпляра" (public instance variable), обеспечиваемая для оперирования значениями в доменах, должна быть всего лишь сокращенной синтаксической формой для вызова некоторых специальных функций (и возможно, “ссылок на псевдопеременные”, если такие переменные экземпляра могут появляться в левой части операций присваивания). Какая-либо непосредственная взаимосвязь между такими переменными экземпляра и реальным представлением значений из соответствующего домена не должна иметь обязательного характера.
4. В D не должна поддерживаться ни концепция "защищенных" (protected) переменных экземпляра (в отличие от приватных (private)), ни концепция "друзей" (friends). Авторы полагают, что проблемы, в связи с которыми возникли намерения обратиться к таким понятиям, решаются лучшим образом с помощью системного механизма авторизации.
Должна существовать возможность спецификации одного или более возможных ключей для каждой производной relvar. Вместе с тем для каждой relvar (базовой или производной), для которой специфицированы возможные ключи, должна иметься возможность назначения в точности одного из них первичным ключом.
Комментарии:
Каждая relvar действительно обладает одним или более возможных ключей (из которых, по крайней мере, один, а предпочтительнее все, должны назначаться пользователем в случае базовых relvar, как это требуется в RM-предписании 17). Однако назначение одного из конкретных возможных ключей первичным ключом является факультативным по причинам, обсуждаемым в [13].
В язык D следует включить поддержку системно-генерируемых ключей, как это описано в [16] (глава 5) и [7] (глава 19).
В язык D следует включить какие-нибудь удобные краткие декларативные обозначения для выражения: a) ссылочных ограничений (referential constraints); b) ссылочных действий (referential actions), таким как "каскадное удаление".
Для системы желательно, хотя и в полной мере не осуществимо, обладать способностью выводить (независимые от времени) возможные ключи для каждого отношения R, выразимого в языке D, таким образом, что:
возможные ключи R становятся возможными ключами R', когда R присваивается R';
сведения о возможных ключах R могут включаться в информацию об отношении R, которая доступна пользователю D.
В языке D следует обеспечивать такие функциональные возможности, но без какой-либо гарантии относительно того, что выведенные ключи не являются собственными надмножествами фактических ключей, или даже что для каждого фактического ключа обнаруживается некоторое надмножество (собственное или иное). Реализации языка D могут, таким образом, состязаться друг с другом в степени успеха обнаружения возможных ключей.
Комментарии:
Рекомендация о том, что следует выводить возможные ключи для производных отношений (насколько это возможно), была фактически предложена в RM-предписании 23, в котором требовалась поддержка общего механизма вывода ограничений. Возможные ключи упоминаются здесь явным образом, поскольку считаются важным частным случаем по причинам, обсуждаемым в [16] (глава 10).
В D следует предоставлять какие-либо удобные (непроцедурные) средства выражения запросов с квотой (quota query) (например "найти трех самых молодых служащих"). Такая возможность не должна увязываться с механизмом, который конвертирует отношение в упорядоченный список (см. РМ-запрет 2).
В D следует обеспечивать какие-либо удобные (непроцедурные) средства выражения обобщенного транзитивного замыкания графового отношения, включая возможность выполнения обобщенных операций конкатенации и агрегирования, описанных в [21].
В D следует допускать использование параметров в функциях, значениями которых являются отношения, для представления кортежей, отношений, а также скаляров.
Комментарии:
Мы рассматриваем это только как предложение, а не как предписание, поскольку полагаем, что в настоящее время данный вопрос требует дальнейшего изучения.
В D обеспечить механизм для того, чтобы иметь дело с "отсутствующей информацией" в духе схемы значений по умолчанию, описанной в [16] (глава 21), но основанной на доменах, а не на атрибутах.
Комментарии:
Термин "значение по умолчанию" может привести к заблуждению, поскольку он предполагает такую интерпретацию, которая вовсе не имеется в виду – а именно то, что данное значение появляется настолько часто, что оно может быть с таким же успехом задано по умолчанию. Намерение же, скорее, заключается в том, чтобы использовать уместное значение "по умолчанию", отличное от всех возможных истинных значений, когда ни одно из подлинных значений не может быть использовано. Например, если подлинные значения атрибута ОТРАБОТАННЫЕ_ЧАСЫ – это положительные целые числа, то задание значения по умолчанию "?" может использоваться для того, чтобы показать, что (по каким-то причинам) никакое подлинное значение не известно. Следовательно, домен для атрибута ОТРАБОТАННЫЕ_ЧАСЫ – это не просто домен положительных целых чисел.
Следует обеспечить реализуемость SQL в среде D – не потому, что это желательно само по себе, а чтобы обеспечить безболезненный переход для текущих пользователей SQL. С той же целью следует обеспечить возможность конвертирования существующих баз данных SQL, чтобы с ними безошибочно могли оперировать программы на языке D.
Комментарии:
Из сказанного выше совсем не следует, что язык D должен быть надмножеством SQL; скорее следует предоставить возможность написания внешнего слоя кода D – надстройки над традиционными реляционными средствами D, которая:
будет воспринимать SQL-операции над конвертированными SQL- данными;
будет выдавать результаты, которые бы выдавали операции SQL, если бы они выполнялись над первоначальными не конвертированными данными SQL.
Следует подчеркнуть, что мы полагаем возможным конструирование такого внешнего слоя SQL без нарушения каким-либо предписаний и запретов, составляющих данный манифест.
