для приложения, работающего с базой данных, то локальное хранение
столбца Clprice повысит эффективность ввода/вывода.
Понятно, что даже в этом простом случае разработчики ОР СУБД не
могут сами справиться с отмеченными проблемами. Отсутствуют
стандартные определения типов данных и операторов, для хранения
элементов столбцов может потребоваться память объемом более одной
страницы, отсутствует информация о размерах и степени
устойчивости данных. Поэтому, в отличие от чисто реляционных
систем, за оптимизацию и распараллеливание в ОР-системах
совместно отвечают поставщик ОР СУБД, разработчики расширенных
типов данных и операторов, разработчики приложения и
администратор базы данных.
Как же на это реагируют разработчики ОР СУБД? Имеются два разных
архитектурных подхода, применяемых производителями для внедрения
объектно-реляционных свойств в реляционные продукты: федеративный
и интегрированный.
Федеративный подход является более простым и легче реализуемым. В
этом случае работающая реляционная СУБД существует отдельно от
объектной базы данных с расширенными возможностями типизации
данных. Этот факт скрывается от прикладной программы общим
внешним программным обеспечением. Кроме поддержки интерфейса
прикладной программы, это программное обеспечение отвечает за
выполнение операций внешнего уровня и восстановление, за создание
планов выполнения запросов, а также производит интеграцию
результатов от баз данных, генерируемых в ответ на частичные
запросы, которые возникают при поступлении от приложения полных
запросов.
Эта архитектура дает возможность полезно использовать доступную
технологию объектных СУБД и пригодна для работы с распределенными
данными. Архитектура может быть расширены путем добавления других
типов баз данных, например, текстовых или геопространственных.
Привлекает также то, что изменения, которые необходимо внести в
базы данных для включения их в федеративную организацию, могут
быть минимизированы до такой степени, что их можно производить