Базы данных

Вид материала

Документы

Содержание Вопрос № 11 Методика построения объектно-реляционных моделей баз данных Стандарт SQL3 Тип компонента

Подобный материал:

• 1 научиться создавать таблицу базы данных в режиме таблицы, 54.71kb.
• Ms access Создание базы данных, 34.31kb.
• Лекция 2 10. Полнотекстовые базы данных, 133.46kb.
• Практическая работа № «Создание базы данных», 21.96kb.
• Информационные системы, использующие базы данных: оборудование, программное обеспечение,, 102.98kb.
• Конспект лекций по курсу "базы данных" (Ч., 861.92kb.
• Реферат на тему: Access. Базы данных, 274.77kb.
• Лекция №3 нормализация данных, 107.45kb.
• Курсовая работа по дисциплине «Базы данных» на тему: «Разработка базы данных для учета, 154.05kb.
• Создание базы данных “Классный, 73.09kb.

Вопрос № 11 Методика построения объектно-реляционных моделей баз данных

По мнению Стоунбрекера, существует три наиболее вероятных подхода к построению ОРСУБД:

• построить ядро объектно-реляционной СУБД;
  
• сделать "надстройку" над реляционным ядром;
  
• сделать "надстройку" над объектно-ориентированным ядром.
  

Рассмотрим по очереди каждый из них.

Для предоставления необходимых возможностей требуется ядро СУБД, ко­торое было бы таблично управляемо из базы метаданных, содержащих ин­формацию о таблицах, типах, функциях, операторах и наследовании. Каждый отдельный модуль СУБД должен взаимодействовать с этими метаданными:

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

Таким образом, вся СУБД должна быть таблично управляема этим обширным набором метаданных.

Теперь обратимся к архитектуре существующих реляционных СУБД. Все они содержат метаданные, описываемые набором таблиц, но не имеют ин­формации о типах, операторах, функциях или наследовании. К тому же, су­ществующие типы, операторы и функции ЗОЬ являются жестко-встроенными в ядро. Такие архитектуры крайне сложно расширить или изменить, вслед­ствие чего их практически невозможно уложить в концепцию ОРСУБД. Во избежание этих трудностей поставщики реляционных систем могут пойти одним из следующих двух путей:

• переписать ядра СУБД с самого начала;
  
• написать "надстройку" над своими текущими продуктами, которая обес­печивала бы требуемые возможности.
  

Первый путь рискован, труден и требует много времени и ресурсов, так что может быть использован только в долговременной перспективе. В настоя­щее время сложилось так, что поставщики, добавляющие поддержку объек­тов, делают это, используя второй подход, "надстройку". Ведущие фирмы в области разработки РСУБД, такие как Oracle, Informix и IBM, так и по­ступили. Но поскольку расширению подвергались уже существующие сис­темы, их функциональные возможности имеют свои особенности.

Основная идея заключается в том, чтобы создать "надстройку" между клиен­том и реляционным ядром. Эта "надстройка" позволяет создать ОРСУБД на основе существующих реляционных ядер. Все, что будет делать такая надстройка, — автоматизиро­вать эту функцию моделирования. Однако большинство пользователей, которые попытались создать собственные надстройки для существующих систем, столкнулись в итоге с очень плохой производительностью. В резуль­тате технология надстроек только замаскирует, но не решит любую из про­блем производительности, проистекающих из применения реляционных систем при решении задач, для которых они не были разработаны. И последний вариант — построение объектно-реляционной СУБД на основе существующей объектно-ориентированной СУБД. То есть построение ядра расширенного SQL над реализацией С++. Существует несколько препятст­вий для такого рода реализаций.

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

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

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

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

Таким образом, в отношении СУБД будущего поколения специалисты не пришли еще к общему мнению относительно принципов ее организации. Тем не менее, несмотря на продолжающиеся горячие споры по основопола­гающим концепциям этого вопроса, уже есть некоторый опыт построения первых образцов ОРСУБД. Одной из первых попыток создания ОРСУБД является система Postgres (Post Ingres). Это исследовательская система управления базами данных, которая разрабатывалась как наследник РСУБД INGRES (Stonebraker and Rowe 1986).


Стандарт SQL3

В 1998 году в стандарт SQL был предложен к включению ряд дополнитель­ных компонентов, необходимых для поддержки объектно-ориентированного управления данными. Данная версия стандарта получила название SQL-3. Стандарт SQL-3 спроектирован с учетом совместимости снизу вверх со стандартом SQL, а потому любые ОРСУБД, совместимые с SQL-3, должны удовлетворять этому условию.

Некоторые из данных компонентов, многие из которых уже обсуждались раньше, приведены в табл. 1.

Таблица 1. Дополнительные компоненты стандарта

Тип компонента	Пояснения
Типы-конструкторы для строковых и ссылочных типов	Тип-строка — это последовательность пар "имя поля”/ “тип данных", образующая тип данных, способный представлять типы строк в таблицах в виде переменных, которые могут быть использованы в качестве аргументов и возвращаемых значе­ний процедур и функций
Определенные пользователем типы	Типы, которые могут участвовать в связях супертип/подтип (UDT-типы) и использоваться так же, как и встроенные типы, и которые делятся на две категории: отдельные типы и структу­рированные типы
Определенные пользователем процедуры, функ­ции, операторы	Вызываемые средствами SQL UDR-подпрограммы могут оп­ределяться как часть UDT-типа или отдельно как часть схемы
Типы-конструкторы для типов коллек­ций	Используются для определения коллекций других типов (мас­сивы, множества, списки, мультимножества); могут приводить к образованию вложенных таблиц, представляющих много­уровневую структуру данных.
Поддержка боль­ших объектов	Большой объект— это поле таблицы, содержащее большое количество данных (большой текстовой или графический файл)

Как стало очевидно, развитие стандарта языка SQL идет по пути все боль­шего его усложнения. Это приводит к потере следующих неоспоримых пре­имуществ языка SQL-89:

• простота использования для конечных пользователей;
  
• простая структура команд и синтаксис.
  

Дальнейшее развитие концепций объектно-реляционных СУБД ожидается в стандарте SQL-4.

К. Дейт об объектно-реляционных СУБД

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

В этом плане заслуживает внимательного рассмотрения позиция по этому вопросу такого крупного специалиста в области баз данных, как К. Дейт. Приведем здесь некоторые его взгляды на принципы построения ОРСУБД.

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

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

Взяв упомянутую выше концепцию за основу, можно провести дальше параллель на более детальных уровнях:

• экземпляр — элемент домена;
  
• семейство — набор значений любого атрибута, определенного на дан­ном домене, причем доступ к отдельному экземпляру со стороны не­скольких семейств может быть достигнут с помощью внешних ключей значениям.
  

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

Полученный в результате таких посылок программный продукт будет со­четать в себе преимущества систем обоих классов и окажется способным использоваться для сложных прикладных областей.