4. Заключение

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

Во-вторых, представляется, что доступ к СУБД должен осуществляться при помощи языка запросов, и почти 20 лет истории подтверждают правильность такой точки зрения. Физической навигации, выполняемой программами пользователей или происходящей внутри функций, следует избегать. В-третьих, необходимо всячески поощрять использование автоматических наборов, так как они предоставляют массу преимуществ по сравнению с явно поддерживаемыми наборами. В-четвертых, свойство стабильности данных может быть добавлено ко многим языкам программирования. Так как не существует языка программирования, аналогичного эсперанто, этого следует достигать путем изменения компилятора и написания специфичной для языка системы времени выполнения, взаимодействующей с единой СУБД. Таким образом, языки программирования с поддержкой стабильных данных мало связаны с моделями данных. В-пятых, уникальные идентификаторы должны задаваться либо пользователем, либо системой (здесь мы вступаем в противоречие с одним из принципов из работы [ATKI89]).

Основной вопрос, по которому мы расходимся во мнениях с большей частью сообщества OODB, - возможность естественной эволюции современных реляционных систем к системам, поддерживающим возможности, обсуждаемые в данной работе. Мы верим в такую возможность. Продукты агрессивных поставщиков реляционных систем уже удовлетворяют принципам 1, 2 и 3 и обеспечивают хорошую поддержку предложений 1.3, 1.4, 1.5, 2.1, 2.3, 2.4, 3.1, 3.3 и 3.4. Для превращения в СУБД третьего поколения в эти продукты осталось добавить наследование и дополнительные конструкторы типов и внедрить языки программирования с поддержкой стабильных данных. Существуют прототипы систем, указывающие пути включения и этих средств.

С другой стороны, современные системы, провозглашаемые объектно-ориентированными, обычно не соответствуют нашим принципам и поддерживают лишь предложения 1.1 (частично), 1.2, 1.3 и 3.2. Для превращения в подлинные СУБД третьего поколения таким системам не хватает языка запросов и оптимизатора запросов, системы правил, поддержки SQL в архитектуре клиент/сервер, поддержки представлений и языков программирования со стабильными данными. Кроме того, в них должны быть отменены любые жесткие требования наличия уникальных идентификаторов и прекращено поощрение навигации. Более того, в них необходимо построить языки четвертого поколения, внедрить поддержку распределенных баз данных и осуществить настройку системы для эффективного управления данными.

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