Объектно-ориентированные СУБД

Основные данные о работе

Версия шаблона	1.1
Филиал	Смоленский филиал СГА
Вид работы	Курсовая работа
Название дисциплины	Базы данных
Тема	Объектно-ориентированные  СУБД
Фамилия студента	Величко
Имя студента	Татьяна
Отчество студента	Андреевна
№ контракта	07000110609003

 

Содержание

      Введение

      Основная часть

1. Общие понятия объектных СУБД.
1. Причины возникновения объектных СУБД.
2. Недостатки реляционных СУБД.
2. Объектно-ориентированные СУБД.
1. Концепции объектно-ориентированного подхода.
2. Объектно-ориентированная БД.
3. Объектно-ориентированная модель данных.
4. Связь объектно-ориентированных СУБД с общими понятиями объектно-ориентированного подхода.
5. Примеры объектно-ориентированных СУБД.
3. Языки программирования и языки запросов объектно-ориентированных СУБД.
1. Языки программирования объектно-ориентированных баз данных.
2. Языки запросов объектно-ориентированных баз данных

Заключение

Глоссарий

Список использованных источников

Приложения

Введение

1. Общие понятия объектных СУБД

 

1.  Причины появления объектно-ориентированных баз данных

 

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

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

 

2.  Недостатки реляционных СУБД

 

В реляционных базах  данных (Relational Database System, RDBS) все данные отображаются в двумерных таблицах. База данных, таким образом, это ни что иное,

как набор таблиц. RDBS и ориентированные на записи системы организованы на

основе стандарта B-Tree или методе доступа, основанном на индексации – Indexed

Sequential Access Method (ISAM) и являются  стандартными системами, использующимися в большинстве современных программных продуктов. Для

обеспечения комбинирования таблиц для определения связей между данными, которые практически полностью отсутствуют в большинстве программных реализаций B-Tree и ISAM, используется языки, подобные SQL (IBM), Quel (Ingres) и RDO (Digital Equipment), причем стандартом отрасли в настоящее время стал язык SQL, поддерживаемый всеми производителями реляционных СУБД. Оригинальная версия SQL – это интерпретируемый язык, предназначенный для выполнения операций над базами данных. Язык SQL был создан в начале 70‑х как интерфейс для взаимодействия с базами данных, основанными на новой для того времени реляционной теории. Реальные приложения обычно написаны на других языках, генерирующих код на языке SQL и передающих их в СУБД в виде текста в формате ASCII. Нужно отметить также, что практически все реальные реляционные (и не только реляционные) системы помимо реализации стандарта ANSI SQL, известного сейчас в последней редакции под именем SQL2 (или SQL-92), включают в себя дополнительные расширения, например, поддержка архитектуры клиент-сервер или средства разработки приложений. Строки таблицы составлены из полей, заранее известных базе данных. В большинстве систем нельзя добавлять новые типы данных. Каждая строка в таблице соответствует одной записи. Положение данной строки может изменяться вместе с удалением или вставкой новых строк. Чтобы однозначно определить элемент, ему должны быть сопоставлены поле или набор полей, гарантирующих уникальность элемента внутри таблицы. Такое поле или поля называются первичным ключом (primary key) таблицы и часто являются числами. Если одна таблица содержит первичный ключ другой, это позволяет

организовать связь  между элементами разных таблиц. Это  поле называется внешним ключом (foreign key). Так как все поля одной таблицы должны содержать постоянное число полей заранее определенных типов, приходится создавать дополнительные таблицы, учитывающие индивидуальные особенности элементов, при помощи внешних ключей. Такой подход сильно усложняет создание сколько- нибудь сложных взаимосвязей в базе данных. Желающим убедится, что это действительно так  и не пожалевшим на это определенный отрезок времени, компания POET Software любезно предоставляет возможность ознакомиться с примером в своей “белой книге” “POET Technical Reference”. База данных рядового предприятия общепита (клиенты – Джордж Буш и Эдди Мэрфи) состоит из четырех таблиц. Еще один крупный недостаток реляционных баз данных – это высокая трудоемкость манипулирования информацией и изменения связей.

 

      

   2. Объектно-ориентированные СУБД

 

2.1.  Концепции объектно-ориентированного подхода

 

Объектно-ориентированное, или объектное, программирование (в  дальнейшем ООП) — парадигма программирования, в которой основными концепциями  являются понятия объектов и классов.

Появление в ООП отдельного понятия класса закономерно вытекает из желания иметь множество объектов со сходным поведением. Класс в ООП — это в чистом виде абстрактный тип данных, создаваемый программистом. С этой точки зрения объекты являются значениями данного абстрактного типа, а определение класса задаёт внутреннюю структуру значений и набор операций, которые над этими значениями могут быть выполнены. Желательность иерархии классов (а значит, наследования) вытекает из требований к повторному использованию кода — если несколько классов имеют сходное поведение, нет смысла дублировать их описание, лучше выделить общую часть в общий родительский класс, а в описании самих этих классов оставить только различающиеся элементы.

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

 

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

 

Однако общность механизма обмена сообщениями имеет  и другую сторону — «полноценная»  передача сообщений требует дополнительных накладных расходов, что не всегда приемлемо. Поэтому в большинстве ныне существующих объектно-ориентированных языков программирования используется концепция «отправка сообщения как вызов метода» — объекты имеют доступные извне методы, вызовами которых и обеспечивается взаимодействие объектов. Данный подход реализован в огромном количестве языков программирования, в том числе C++, Object Pascal, Java, Oberon-2. В настоящий момент именно он является наиболее распространённым в объектно-ориентированных языках.

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

 

2.2. Объектно-ориентированная БД

 

Первые публикации об объектно-ориентированных базах  данных появились в середине 80-х  годов. Объектно-ориентированные базы данных обычно рекомендованы для тех случаев, когда требуется высокопроизводительная обработка данных, имеющих сложную структуру. Есть обязательные характеристики, которым должна отвечать любая ООБД. Их выбор основан на 2 критериях: система должна быть объектно-ориентированной и представлять собой базу данных.

 

Обязательные характеристики:

- Поддержка сложных  объектов. В системе должна быть  предусмотрена возможность создания  составных объектов за счет  применения конструкторов составных  объектов. Необходимо, чтобы конструкторы объектов были ортогональны, то есть любой конструктор можно было применять к любому объекту.

- Поддержка индивидуальности  объектов. Все объекты должны  иметь уникальный идентификатор,  который не зависит от значений  их атрибутов.

- Поддержка инкапсуляции. Корректная инкапсуляция достигается за счет того, что программисты обладают правом доступа только к спецификации интерфейса методов, а данные и реализация методов скрыты внутри объектов.

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

- Поддержка наследования типов и классов от их предков. Подтип, или подкласс, должен наследовать атрибуты и методы от его супертипа, или суперкласса, соответственно.

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

- Вычислительная полнота. Язык манипулирования данными должен быть языком программирования общего назначения.

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

 

Необязательные характеристики:

- Множественное наследование

- Проверка типов

- Распределение

- Проектные транзакции

 

Открытые характеристики:

- Парадигмы программирования (процедурное, декларативное)

- Система представления

- Система типов

- Однородность. Реализация — язык программирования — интерфейс.

2.3. Объектно-ориентированная  модель данных

 

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

 

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

 

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