Три класса характеристик:

1. Обязательные.
2. Необязательные.
3. Открытые – позволяют пользователю выбирать свойства.

Обязательные:

      СУБД

• Долговременное  хранение
• Использование внешней памяти
• Параллелизм
• Восстановление
• Нерегламентированные запросы

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

1. Поддержка сложных объектов. В системе должна быть предусмотрена возможность создания составных объектов за счет применения конструкторов составных объектов. Необходимо, чтобы конструкторы объектов были ортогональны, т.е. любой конструктор можно было применять к любому объекту.
2. Поддержка индивидуальности объектов. Все объекты должны иметь уникальный идентификатор, который не зависит от значений их атрибутов.
3. Поддержка инкапсуляции. Корректная инкапсуляция достигается за счет того, что программисты обладают правом доступа только к спецификации интерфейса методов, а данные и реализация методов скрыты внутри объектов.
4. Поддержка типов и классов.  Требуется, что бы  в ООБД поддерживалась хотя бы одна концепция различия между типами и классами. (Термин «тип» более соответствует понятию абстрактного типа данных. В языках программирования переменная объявляется с указание ее типа. Компилятор может использовать эту информацию для проверки выполняемых с переменной операций на совместимость с ее типом, что позволяет гарантировать корректность программного обеспечения. С другой стороны класс является неким шаблоном  для создания объектов и предоставляет методы, которые могут применяться к этим объектам. Таким образом, понятие «класс» в большей степени относится   ко времени исполнения, чем ко времени компиляции.)
5. Поддержка наследования типов и классов от их предков.  Подтип, или подкласс, должен наследовать атрибуты и методы от его супертипа, или суперкласса, соответственно.
6. Перегрузка в сочетание с полным связыванием.  Методы должны применятся к объектам разных типов. Реализация метода должна зависеть  от типа объектов, к которым данный метод применяется. Для обеспечения этой функциональности связывание имен методов в системе не должно выполнятся до времени выполнения программы.
7. Вычислительная полнота. Язык манипулирования данными должен быть языком программирования общего назначения.
8. Набор типов данных должен быть расширяемым. Пользователь должен иметь средства создания новых типов данных на основе набора предопределенных системных типов. Более того, между способами использования системных и пользовательских типов данных не должно быть никаких различий.

Необязательные:

1. Множественное наследование
2. Проверка типов
3. Распределение
4. Проектные транзакции

Открытые

1. Парадигмы программирования (процедурное, декларативное)
2. Система представления
3. Система типов
4. Однородность. Реализация – язык программирования – интерфейс.

Билет 17. Методология разработки ООБД

Цель  создания ООБД – необходимость поддержания  сложных приложений, которые адекватно  представляют объекты реального  времени.

Достоинства ООБД: возможность программирования ср-ми языков упр-я данными.

SQL – язык манипулирования данных для реляционных БД

FoxPRo – чисто реляционная БД

Большинство ООБД в качестве включаемых языков используют – С++ , Smalltalk

Есть  ещё 2 языка , кот. Могут быть в качестве включающих – Кобои и Ада, но  для этого нужно обеспечить интерфейс, написанный на Си.

Сейчас  принят стандарт , согласно которому для написания БД исп-ся спец-й язык UML (United Modiling Language).

UML – язык моделирования , предназначенный для спецификации, визуализации, конструирования и документирования материалов программных систем , для моделирования бизнеса и др. не программных систем.

В основе языка лежит 3 модели:

1 .BOOCH – описание объектов

2. OMI – моделирование объектов

3. OOSE – для разработки пр-х систем 

Билет 18. Соотношение расширенного и гибридного подхода

Создание  ООБД возможно на основе использование  реляционной технологии. При таком  подходе появляется возможность  сочетания лучшего из этих 2-х  технологий. Т.е. создаются БД которые  поддерживают как традиционные приложения управленческой ИС, так и ОО приложения.

Такое объединение м.б. достигнуто 2 способами:

Гибридный подход -  при котором ОО интерфейс добавляется к поддерживающей реляционной системе Бд.

Расширенный подход – предусматривает встраивание ОО возможностей в сервер БД.

1. Реляционный внешний интерфейс

Реляционный механизм управления данными

2. ОО внешний интерфейс

Реляционный механизм управления данными

3. ОО внешний интерфейс

ОО механизм управления данными

4. Как внешний интерфейс так и механизм упр-я данными явл-ся реляционными, но с объектно-ориентированными расширениями.

Также есть третья модель:

Модель  объединения – позволяет объединить ОО языки с внутренними поддерживающими реляц. СУБД

ОО  SQL – SQL3 = MOOSE(major object SQL extensions)

• включение языка Си

 

Билет 18. Стандарты ODMG

Целью стандарта Object Database Management Group является обеспечение переносимости приложений (схем данных, языки программирования, языки манипулирования данными, языки запросов).

Согласно  стандарту ООСУБД определяется как СУБД которая соединяет в себе возможности БД с возможностями ОО языка программирования.

      При использовании  ООСУБД объекты базы данных неотличимы от объектов языка  пр-я.

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

Обеспичение механизма наследования:

Супертипà подтип

Сам тип  является объектом

Абстрактный тип определяет хар-ки а не реализации

Группы  языков:

1. Язык определения объектов ODL
2. Язык манипулирования объектами  OML
3. Объектный язык запросов OOLàSQL2
1. ODL В основу языка положен язык определения интерфейса IDL (Interface Definition Language). В ОДЛ каждый объект имеет строго опр-й единственный тип. Поведение объекта опр-ся перечнем допустимых операций в соответствии с типом.
2. Операции манипулирования

• управление транзакциями

• динамические вызовы запросов

 

Билет 8. Тупиковые ситуации

Разрешение  тупиковых ситуаций

Обе транзакции ожидают друг друга и не могут  продолжаться. Возникла ситуация тупика.

Итак, при  использовании протокола доступа  к данным с использованием блокировок часть проблем разрешилось (не все), но возникла новая проблема – тупики.

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

Можно представить два принципиальных подхода к обнаружению тупиковой  ситуации и выбору транзакции-жертвы:

1.СУБД  не следит за возникновением  тупиков.Транзакции сами принимают  решение, быть ли им жертвой. 

2.За  возникновением тупиковой ситуации следит сама СУБД, она же принимает решение, какой транзакцией пожертвовать.

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

Билет 20. Целостность данных

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

Определитель  NULL

Определитель  NULL – указывает, что значение атрибута в настоящий момент неизвестно или неприемлемо для этого кортежа.

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

Целостность сущностей

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

Целостность сущностей – в базовом отношении ни один атрибут первичного ключа не может содержать отсутствующих значений, обозначаемых определителем NULL.

По определению, первичный ключ – это минимальный  идентификатор, который используется для уникальной идентификации кортежей. Это значит, что никакое подмножество первичного ключа не может быть достаточным для уникально идентификации кортежей. Если допустить присутствие определителя NULL в любой части первичного ключа, это равноценно утверждению, что не все его атрибуты необходимы для уникальной идентификации кортежей, что противоречит определению первичного ключа.

Если  рассмотреть это правило более  внимательно, то можно заметить несколько  его необычных свойств. Во-первых, почему оно применяется к первичным ключам, но не используется в отношении альтернативных ключей? Во-вторых, почему оно ограничивается только базовыми отношениями? (пример)