Три манифеста баз данных ретроспектива и перспективы

       

Заключение Второго Манифеста


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

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

Основной вопрос, по которому авторы Второго манифеста расходились во мнениях с большей частью сообщества ООБД, – это возможность естественной эволюции современных реляционных систем к системам, поддерживающим возможности, обсуждаемые в данной работе.
Авторы данного манифеста верили в такую возможность. Уже в то время продукты основных поставщиков реляционных систем удовлетворяли принципам 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 в архитектуре клиент-сервер, поддержки представлений и языков программирования со стабильными данными. Кроме того, в них должны быть отменены любые жесткие требования наличия уникальных идентификаторов и прекращено поощрение навигации. Более того, в них необходимо построить языки четвертого поколения, внедрить поддержку распределенных баз данных и осуществить настройку системы для эффективного управления данными.
Конечно, воплотить предложения манифеста непросто – придется столкнуться со многими проблемами. Создание языка с поддержкой стабильных данных для разнообразных языков программирования – труднейшая задача. Другую проблему представляет включение в такие языки приемлемых конструкций языка запросов. Далее, логическое и физическое проектирование баз данных для современных реляционных систем считается непростой задачей, а с внедрением более богатой системы типов и правил она еще более усложнится. Для помощи пользователю здесь потребуются методологии и инструменты проектирования баз данных. Серьезную трудность представляет оптимизация выполнения правил. Кроме того, для успеха новых технологий крайне важна визуализация и отладка ориентированных на правила приложений.

Содержание раздела