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

Евгений Григорьев

Обсуждение статьи

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

"Умный в гору не пойдет – умный гору обойдет"
Русская поговорка.

Введение

Эта работа возникла как реакция на статью " Интеграция языков программирования с базами данных: в чем состоит проблема?"[1]. По её прочтении возникает то же впечатление, которое производит и все текущее состояние поднятой в ней темы в целом. Все идеи и замечания по отдельности выглядят верными – но в целом появляется картина то ли лабиринта, то ли завала - в общем, чего-то такого, куда лучше не соваться.

Мы этого делать и не будем – в первую очередь потому, что проблема импеданса, которая рассматривается в указанной статье как фундаментальная, вызывает некоторые сомнения - по крайней мере, в том, что касается этой фундаментальности. Импеданс возникает во вполне конкретной конфигурации, которая, в самом общем виде, включает ОО-систему программирования и реляционную систему управления БД (в самых разных её воплощениях). Надо понимать, что, несмотря на распространенность, эта конфигурация есть результат хаотичной, зависящей от тысяч случайных фактов эволюции взаимодействия систем с быстрой (ОЗУ) и медленной (внешние накопители) памятью [2]. У создателей этих самых ОО-языков и РСУБД на момент создания было множество гораздо более важных задач, чем грядущая проблема взаимосуществования[15, 16].

В связи с этим мне представляется интересным обратить внимание на возможные безимпедансные альтернативы – тем более, что подходы к их созданию уже существуют. При этом я буду исходить из необходимости реализовать, во-первых, основные черты ОО-систем программирования [3] – поскольку это является залогом богатых выразительных возможностей системы, и, во-вторых, реляционную модель данных [4, 5] (далее РМД) – поскольку она может служить формальным фундаментом системы хранения данных, обеспечивающей групповой доступ к данным и, в этом смысле, не имеет сегодня альтернативы. А начну я с вопроса о том, как эти требования не могут быть совмещены.

ОО- и Р-. Может ли существовать объектно-ориентированная модель данных?

Отмечу, что я вопрошаю именно про модель данных и не в коем случае не утверждаю, что невозможными или ненужными является ОО-парадигма (концепция) или ОО-системы (в конце концов, это наша цель). Дело в том, что мне неоднократно встречалось очень расплывчатое представление о том, что кроется за самим понятием "модель данных" – хотя он имеет весьма четкое формальное определение, данное Е. Коддом [6, 17], более известным в качестве автора реляционной модели данных. Модель данных определяется как совокупность коллекции типов (где тип – это множество значений), коллекции возможных операций над экземплярами этих типов и коллекции применимых к ним ограничений целостности.

Следуя данному формальному определению понятия "модель данных", реляционная модель данных

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

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

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

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

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

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

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

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

Эти принципиальные различия позволяет мне утверждать, что попытки создать "ОО-модель данных" (то есть смешать эти две концепции) лишены какого либо смысла. Важно понимать, однако, что указанные различия нельзя рассматривать как свидетельство их несовместимости - скорее наоборот. Говоря образно, "модель данных" можно сравнить с архитектурным стилем, определяющей облик конкретного здания, а "ОО-" – с конкретным набором современных строительных технологий, позволяющих построить любое здание. Можно воспользоваться терминами, предложенным В.Турчиным [7], - тогда модель данных определяет то, как будет выглядеть "система", а "ОО-" является парадигмой "метасистемного перехода". Это ортогональные, несмешивающиеся вещи, однако развитие возможно только в их гармоничном совместном использовании. Именно поэтому, говоря о бессмысленности "ОО-моделей данных", я настаиваю, что необходимой является система, которая не смешивает, но объединяет эти ортогональные идеи, а именно ОО-система хранения данных, реализующая реляционную модель данных. Я называю такую систему RxO-системой, обозначая знаком "x" ортогональность реализуемых ею концепций.

Заинтересованный читатель здесь, конечно же, спросит – "А как это? Если фРМД вводит единственный тип "отношение", и, наоборот, ОО-система позволяет описывать любые типы, как это вообще можно совместить в рамках единой системы? Это же явное противоречие (тот самый пресловутый импеданс)!"

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

Во что же мы уперлись?

Достаточно часто в статьях, посвященных проблемам создания систем хранения данных следующего поколения, критике подвергается реляционная модель данных (РМД). Обычными обвинениями [10, 11, 12, 13, 14] являются "бедная система типов", "двумерное представление данных", "атомарность хранимых значений", "невозможность адекватно описать предметную область", "недостаточная семантика" – и это не далеко полный список. Когда же начинаешь вчитываться в статью или общаться с её авторами, вылезают (обычно вместе) два обычных заблуждения.

1) РМД пытаются использовать как средство инфологического уровня. Или, по другому, РМД рассматривается как инструмент, служащий для описания предметной области. Обычными в таких случаях является утверждение "предметная область должна быть описана как набор отношений" и рассуждения, почему такое описание предметной области выглядит корявым и почему необходимы более изящные способы.

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

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

Никакой "бедной" (или "богатой") "семантики" в фРМД , конечно, не существует - она оперирует абстрактными понятиями. Чтобы понять это, сравним фразы "существует некое отношение" и "существует отношение со схемой (a, b, c)". В первом случае говорится об отношении в самом общем смысле, то есть об отношении, которое удовлетворяет вводимому в фРМД определению именно такого абстрактного, "некоего" отношения. Во втором случае речь идет об отношении, заголовок которого содержит конкретные значения (называемые также "именами атрибутов") "a", "b" и "c". Ну а для отношения со схемой (Артикул#, Количество, Цена) "семантика" кажется вообще очевидной, но это опять-таки не есть семантика фРМД – это всего лишь семантика имен атрибутов (каждое из которых есть значение), содержащихся в данной конкретной схеме.

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

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

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

Сложность данных в инкапсулированных доменах. Третий Манифест.

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

Здесь, конечно, нельзя не вспомнить "Третий Манифест" Дейта и Дарвена [8], предлагающий возможный путь к созданию СУБД следующего поколения. Одним из его ключевых моментов является утверждение, что "в реляционной модели нет ничего, для чего требовалось бы ограничить типы данных только простыми формами. Единственным требованием является то, что значениями домена можно манипулировать только посредством определенных для него операций; внутреннее представление должно быть инкапсулировано". "Третий Манифест" также утверждает, что по совокупности признаков класс (ОО-термин) не отличается от типа, и это является ключевым моментом в объединении двух технологий в рамках единой системы.

Третий Манифест хорошо известен. Его основные идеи не вызывает сомнения (во всяком случае у меня). Однако, помимо доменов, в фРМД существует еще одно "место", которое по своей способности вместить "сложные данные" (точнее, выразить "сложность данных") ничуть не уступает доменам. Это имена.

Сложность данных в именах.

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

Однако современные языки программирования позволяют использовать гораздо более интересные выражения. Рассмотрим, например, выражение "CurrentOrder.items.Count() + History.OrdersDetails.TotalOfCounts". Здесь мы также складываем два числа, однако имена или комбинации имен, используемых для обозначения этих чисел не в пример сложнее. Переменные, содержащие эти значения, являются частью гораздо более сложных структур, они не существуют вне этих структур (т.е. в отличие от переменной "х" не были созданы явно и отдельно от других). Более того, эти целочисленные переменные, возможно, вообще не существуют, а складываемые значение вычисляется.

Но рискнет ли кто-нибудь утверждать, что эта система реализует арифметику хуже или не так правильно, чем система, позволяющая выполнять только "x+y", т.е. манипулировать значениями явно созданных числовых переменных? Конечно, нет! Самое главное, чтобы, говоря образно, 2+2 давало 4, а откуда система берет эти значения, какие структуры их скрывают, как эти структуры определены, как система именует переменные, содержащие эти значения, какие имена и комбинации имен при этом используются – это внутреннее дело системы. С точки зрения арифметики, являющейся формальным (можно сказать бессмысленным – в смысле "не имеющим никакого отношения к предметной области") построением, выражение "CurrentOrder.items.Count()", которое отражает факт наличия в системе некой сложной структуры и, без сомнения, представляется осмысленным для пользователей, ничем не отличается от простого, бессмысленного имени "x".

Возвращаясь к ложной идее "РМД требует, чтобы предметная область была описана как множество отношений", попытаемся вообразить себе аналогичное требование: "арифметика требует, что бы предметная область была описана как множество чисел". Не получилось? До кучи можно добавить следующее: "Исходя из арифметики, все данные в системе должны быть описаны только как значения числовых переменных" и "Арифметика предполагает, что некоторые числовые переменные являются хранимыми, а некоторые – вычисляемыми". Абсурд? Конечно абсурд! Но представьте на секунду, что к таким требованиям люди относятся серьезно, считая их чуть ли не аксиомами, – получилось ли бы у них создать ОО-языки в том виде, в котором они существуют сейчас? Нет, у них было бы возможно только "x+y". И тот факт, что такая система являлась бы правильной реализацией арифметики, вряд ли бы сделал более легким её использование в качестве инструмента описания предметной области. К величайшему сожалению, дело с реляционной моделью данных обстоит сейчас именно таким образом.

Вспомним еще раз, что модель данных – это:

• коллекция типов, где тип – это множество значений,
• коллекция возможных операций над экземплярами этих типов и
• коллекция применимых к ним ограничений целостности.

Здесь нет ни слова о предметной области – модель данных формальна и бессмысленна. Также здесь нет ни слова о возможных реализациях, о переменных и о языке.

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

Пример системы, реализующей принцип "Сложность данных в именах". НадРеляционный манифест.

Примером системы, которая 1) позволяет пользователю описать данные достаточно произвольным образом и 2) при этом гарантирует, что эти данные будут представлены для пользователя как множество значений отношений, является RxO-система, описанная в "НадРеляционном Манифесте" [9] (далее НРМ), автором которого является ваш покорный слуга.

Описанная RxO-система является ОО-системой. Основное требование НРМ заключается в том, что спецификация объектов системы представляет собой множество компонентов следующих типов:

1. скалярные
2. кортежные типы (определенные на множестве скалярных типов),
3. типы отношение (также определенные на множестве скалярных типов).

Эти типы называются значимыми. По сути, они являются аналогом "типов, допускающих реляционное присваивание", определяемых в "Третьем Манифесте". Спецификация компонента объекта может содержать параметры любого из значимых типов.

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

CREATE
CLASS SHIPMENT 
{
  No INTEGER; // скалярный компонент типа (определенный на домене) INTEGER
  WareFrom WAREHOUSE // скалярный компонент ссылочного типа WAREHOUSE
  Items SET OF //компонент типа-отношения 
  {
    Article STRING; 
    Pieces INTEGER; 
  }..
  DoShip(ShipmentDate DATETIME) BOOL; //скалярный компонент, принимающий
                                      //скалярный параметр
}..

Как видно, объект "отгрузка" имеет сложную структуру (0НФ). Он является частью более сложной структуры, так как содержит ссылку на объект типа WAREHOUSE, доступ к  которому может быть описан путевым выражением "someSHIPMENT.WareFrom" (здесь someSHIPMENT -- это ссылка на объект объектного типа SHIPMENT). Возможно, в других частях системы могут существовать ссылки на объект "отгрузка". Компонент Items, содержащий строки заказа, имеет тип отношение (для краткости здесь и далее я буду опускать выражения, определяющие ключи).

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

«Если в системе корректным является путевое выражение "C.*.*.s", где "С" – имя, определяющее существование множества объектов (это может быть имя класса, определенное в глобальном контексте, или имя групповой или одиночной ссылки, определенное в некотором локальном контексте), "s" – имя скалярного компонента, определенного в структуре, входящей в это путевое выражение, а "*.*" – остальные имена, образующие путевое выражение между "C" и "s", то система гарантирует, что существует отношение с именем "C.*", в котором существует скалярный атрибут с именем "*.s", содержащий значение компонента "s", и атрибут с именем "С", содержащий ссылку на объект, в который входит указанный компонент "s"».

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

Например, предположим, что в системе задана следующая спецификация

CREATE
CLASS Y
{
  a scalartype;    // здесь scalartype – некий скалярный тип (домен)
  b SET OF         // компонент b имеет тип отношение 
  {                // с атрибутами
    c scalartype;  // с (определен на домене scalartype)
    d scalartype;  // d (определен на домене scalartype)
   }..
}..

Тем самым, для объектов типа Y определена следующая иерархическая структура (подчеркнуты скалярные элементы структуры)

  Y
  |\
  a b
    |\
    c d

и корректными являются путевые выражения "Y.a", "Y.b.c" и "Y.b.d".

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

"Y" ("Y", "a", "b.c", "b.d")
"Y.b" ("Y", "c", "d") 

Отметим также, что если в некотором контексте определено имя "refY" ссылки на объект или множество объектов типа Y, то система гарантирует, что в этом контексте существуют еще и отношения

"refY" ("Y", "a", " b.c", " b.d")
"refY.b" ("Y", "c", "d") 

Данное правило действительно для структур любой вложенности. Рассмотрим объектный тип Х, содержащий ссылки на описанный тип Y:

CREATE
CLASS X
{
  e Y;             // у является компонентом ссылочного типа Y
  f SET OF         // компонент b имеет тип отношение 
  {                // с атрибутом       
    g Y;           // g (определен на ссылочном домене Y)
   }.. 
}..

Тем самым, для объектов типа X (с учетом вложенной структуры Y) определена следующая структура

     X
    / \
  e     f
  |\    |
  a b   g
    |\  |\
    c d a b
          |\
          c d

Исходя из этого описания, система гарантирует пользователю, что, помимо уже описанных отношений, в системе существуют следующие отношения:

"X" ("X", "e", "e.a", "e.b.c", "e.b.d", "f.g", "f.g.a", "f.g.b.c", "f.g.b.d")
"X.e" ("X", "a", "b.c", "b.d")
"X.e.b" ("X", "c", "d")
"X.f" ("X", "g", "g.a", "g.b.c", "g.b.d")
"X.f.g" ("X", "a", " b.c", "b.d")
"X.f.g.b" ("X", "c", "d")

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

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

Для того, чтобы показать это, вновь вернемся к типу SHIPMENT:

CREATE CLASS SHIPMENT 
{
  No INTEGER; 
  WareFrom WAREHOUSE; 
  Items SET OF //-- and this is a set of invoice lines 
  {
    Article STRING; 
    Pieces INTEGER; 
  }..
}..

Данное выражение описывает спецификацию типа, то есть интерфейс, который может использоваться пользователем для работы с объектами этого типа. В соответствии с этой спецификацией система гарантирует, что существует, например, отношение "SHIPMENT.ITEMS" ("SHIPMENT", "Article", "Pieces"); которое может быть использовано пользователем, например, для создания вида, содержащего данные об общем количестве отгруженного товара поартикульно:

CREATE ShippedGoods AS
SELECT si.Article,SUM(si.Pieces) 
FROM Shipment.Items si
GROUP BY si.Article;

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

ALTER CLASS SHIPMENT
REALIZE Items ...
AS STORED;

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

ALTER CLASS ...
REALIZE Items ... 
AS
SELECT ... ;  

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

ALTER CLASS Shipment …
REALIZE  DoShip(ShipmentDate DATETIME) BOOL
AS
BEGIN
…
END;

Реализацию можно менять в процессе наследования. Например, определим новый тип SALE, описывающий продажу. Естественно, продаваемый товар, так или иначе, должен отгружаться со склада, и поэтому тип SALE определяется как подтип типа SHIPMENT:

CREATE CLASS SALE EXTEND SHIPMENT
{
  ...
  SaleItems SET OF 
  {
     Article STRING; 
     Pieces INTEGER; 
     Price FLOAT; 
  }
}

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

ALTER CLASS SALE 
REALIZE SaleItems AS STORED;

Определенный же в родительском классе унаследованный компонент Items (он содержит данные об отгруженных количествах) переопределяется как вычисляемый, что отражает тот факт, что отгруженные количества в точности должны равняться количествам проданным:

ALTER CLASS SALE 
REALIZE Items ... 
AS
SELECT Article, Sum(Pieces) 
FROM SaleItems 
GROUP BY Article;

При этом создание класса наследника не влечет за собой необходимости изменять код, использующий спецификацию родительского класса (что присуще ОО-системам). Так, в нашем примере не придется изменять созданный ранее вид ShippedGoods. Это происходит из-за того, что при создании этого вида было использовано отношение Shipment.Items, которое впоследствии было переопределено. Фактически, это отношение содержит данные компонента, реализованного в одних объектах как хранимый, а в других - как вычисляемый (таким образом, само это отношение можно назвать полиморфным). Имеет место аналогия с вызовом полиморфных методов объектов в современных ОО-языках – отличие заключается в том, что при вызове полиморфного метода система неявно выбирает одну из реализаций, отношения же RxO-системы являются результатом неявного объединения (реляционная операция UNION) всех возможных реализаций компонента объектного типа, в том числе его типов-наследников.

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

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

Заключение.

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

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

Обсуждение статьи

Используемая литература.

1. ^{обратно} Вильям Кук, Али Ибрагим. Интеграция языков программирования с базами данных: в чем состоит проблема? Перевод: Сергей Кузнецов.
2. ^{обратно} Дж.Мартин. Организация баз данных в вычислительных системах. Изд. 2-е, Мир, (Москва), 1980
3. ^{обратно} Гради Буч. Объектно-ориентированое проектирование с примерами применений. Диалектика(Киев) & И.В.К. (Москва), 1992
4. ^{обратно} Codd, E.F. "A Relational Model of Data for Large Shared Data Banks." CACM 13(6), June 1970. Republished in Milestones of Research -- Selected Papers 1958-1982 (CACM 25th Anniversary Issue), CACM 26(1), January 1983.
5. ^{обратно} Д. Мейер. Теория реляционных баз данных. Мир (Москва), 1984
6. ^{обратно} Codd, E.F. "Data Models in Database Management. Proc. Workshop in Data Abstraction, Databases, and Conceptual Modelling (Michael L. Brodie and Stephen N. Zilles, eds.), Pingree Park, Colo. (June 1980): ACM SIGART Newsletter No. 74 (January 1981); ACM SIGMOD Record 11
7. ^{обратно} Турчин В.Ф. Феномен науки: Кибернетический подход к эволюции. Изд. 2-е – М.: ЭТС. — 2000. — 368 с.
8. ^{обратно} Х. Дарвин, К. Дейт. "Третий манифест", СУБД, No. 1/1996
9. ^{обратно} Григорьев Е.А. НадРеляционный Манифест.
10. ^{обратно} Андреев А.М., Березкин Д.В., Кантонистов Ю. А. Выбор СУБД для построения информационных систем корпоративного уровня на основе объектной парадигмы. СУБД №04-05/98
11. ^{обратно} McCammon K. ObjectiveView Journal, Issue #2, 1998
12. ^{обратно} McClure S. Object Database vs. Object-Relational Databases. IDC Bulletin #14821E - August 1997
13. ^{обратно} Шринивасан В., Чанг Д. Т. Долговременное хранение объектов в объектно-ориентированных приложениях Открытые системы №03/99
14. ^{обратно} Медников А. Ю. Соловьев А.Ю. Объектно-ориентированные базы данных сегодня или завтра? Открытые системы №04/1994
15. ^{обратно} МакДжонс Пол. Воссоединение SQL в 1995 г.: люди, проекты, политика.
16. ^{обратно} Кузнецов С.Д. Серия интервью в ACM SIGMOD Record.
17. ^{обратно} Дейт К. Реляционная модель выдержит испытание временем. Перевод С.Д. Кузнецова.

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