Модуль1_Организация и управление БД

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

Операторы манипулирования данными в иерархической БД

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

•Найти запись заданного типа, удовлетворяющую условию на иерархический путь. Условие, определяющее иерархический путь к

искомой записи, задается в виде:

<Тип корневой записи>[(условие на значения полей в экземпляре корневой записи)], <Тип записи в нижележащем уровне>[(условие на значения полей записи в данном типе)],

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

<Тип искомой записи>[(условие на значения полей искомой записи)].

При отсутствии условия выбирается первая запись среди подобных записей в типе.

Примером такого оператора поиска может служить оператор извлечения информации о кафедре АСУ, радиофака в УГТУ-УПИ:

Найти:

22

ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ (Наименование = ‘УГТУ-УПИ’), ФАКУЛЬТЕТ (Название = ‘РТФ’), КАФЕДРА (Наименование = ‘АСУ’)

В данном операторе объектом поиска служит запись нижнего из указанных в запросе уровней – КАФЕДРА.

•Чтобы перейти к следующей из подобных записей, удовлетворяющих условию, используется модификация предыдущего оператора в виде

Найти следующую запись заданного типа, удовлетворяющую условию на иерархический путь.… .

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

Например, для поиска факультета УГТУ-УПИ, на котором имеется кафедра АСУ, можно применить оператор:

Найти иерархический путь:

ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ (Наименование = ‘УГТУ-УПИ’), ФАКУЛЬТЕТ, КАФЕДРА (Наименование = ‘АСУ’).

•Последовательный перебор всех экземпляров записей БД обеспечивает оператор: Найти следующую запись в соответствии с иерархическим

порядком.

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

Управление данными в базе реализуют операторы:

•Вставить (добавить) новую запись в указанную позицию базы. В операторе задаются значения полей добавляемой записи. Место вставки определяется положением текущей записи базы. Поэтому вставляемая запись должна иметь тип текущей записи.

23

•Заменить текущую запись. Оператор содержит новые значения полей текущей записи.

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

Ограничения целостности данных в иерархической базе

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

Обеспечивается контроль соответствия значения поля в экземпляре записи типу данных, определенному в схеме для типа записи.

Лекция 4. Модели данных, реализованные в СУБД. Сетевая, реляционная и объектная модели

Сетевая модель данных

Структура данных

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

Схема сетевой БД строится из типовых записей, образующих поименованные двухуровневые деревья, называемые наборами. Корневая запись набора называется владельцем набора, а типовые порожденные записи – члены набора. Между владельцем и любым членом набора поддерживается связь типа 1:М. В наборе владелец является сильным типом записи, а член – слабым, т.е. обязательно существующим в составе набора.

Набор изображается диаграммой Бахмана, имеющей вид, представленный на рис. 4.1.

24

Запись – владелец

. . . . . .

Рис. 4.1. Вид диаграммы Бахмана для представления набора в сетевой модели БД

Схема данных образуется из наборов с помощью следующих правил:

•один тип записи может быть владельцем многих наборов;

•тип записи, являющийся членом одного набора, может владеть другими наборами;

•один тип записи может являться членом нескольких наборов.

Легко видеть, что ранее рассмотренная схема иерархической БД

преобразуется в сетевую, если связи между уровнями иерархии преобразовать в отдельные наборы. Пример схемы данных в сетевой модели для ранее рассмотренной базы данных представлен на рис. 4.2.

25

ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ (ОУ) Наименование Адрес . . . .

Кафедры ф-та

КАФЕДРА Наименование Заведующий . . .

Рис. 4.2 Схема БД в сетевой модели

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

26

ИЗДЕЛИЕ

Состав

изделия

Б ЛОК

Состав

блока

ДЕТАЛЬ

Рис. 4.3. Схема данных для описания состава изделия В этой схеме тип записи ИЗДЕЛИЕ владеет набором Состав изделия,

членами которого являются БЛОК и ДЕТАЛЬ. В свою очередь БЛОК владеет набором Состав блока, куда также входит тип записи ДЕТАЛЬ. Если структура блока усложняется, и необходимо предусмотреть возможность вхождения блока в состав другого блока, в набор Состав блока можно включить дополнительный связывающий тип записи – члена СОДЕРЖИТ, которая владеет своим набором Блок в блоке. Членом этого набора можно сделать тип записи БЛОК и таким образом реализовать рекурсию: блок входит в блок. Полученная схема будет иметь следующий вид (рис. 4.4).

27

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

Поскольку в схеме сетевой базы все наборы равноправны, для входа в базу и поиска записей предусматриваются точки входа, называемые вычисляемыми записями. Эти записи в схеме помечают дополнительной стрелкой, например, вычисляемые типы записи ИЗДЕЛИЕ и БЛОК из примера на рис. 4.4. Экземпляр вычисляемой записи может быть найден по значению первичного ключа.

Поиск экземпляра вычисляемой записи реализует оператор:

Найти вычисляемую запись < Тип записи > <Значение ключа,

используемое для поиска экземпляра записи>.

Например, Найти вычисляемую запись БЛОК, «Корпус», где БЛОК – тип записи, а «Корпус» – значение ключа.

Вычисленный экземпляр записи создает текущие записи в БД, которые используются следующими поисковыми операторами:

•Найти следующую запись в заданном типе <Тип записи>;

•Найти следующую запись в текущем наборе <Тип набора>;

•Найти следующую запись заданного типа в текущем наборе <Тип набора> <Тип записи>;

•Найти (перейти на) запись, являющуюся владельцем текущего набора < Имя набора >;

•Найти следующую запись заданного типа , удовлетворяющую условиям на значения полей в текущем экземпляре заданного набора

<Имя набора >,<Тип записи>, <Логическое условие на значения полей>.

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

29

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

Реляционная модель данных

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

Реляционная БД состоит из множества связанных таблиц. Схема данных образуется описаниями «шапок» таблиц. Запросы выполняются на множестве таблиц с учетом логических связей их строк.

Для построения запросов разработан язык SQL, основанный на операциях, выполняемых на множествах строк таблиц.

Поскольку подавляющее большинство СУБД используют реляционную модель, она рассматривается подробно в следующем модуле.

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

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

-сложные информационные объекты – сущности представляются множеством равноправных отношений. Поэтому само понятие хранимого объекта отсутствует в РБД, а запрос к данным объекта требует соединения многих таблиц;

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

-способы обработки не принадлежат информационным объектам базы. Поддерживаемые серверами БД хранимые процедуры и функции существуют

30

как самостоятельные объекты базы, а не входят в состав хранимых объектов. Таким образом «собственное поведение» объекта не представимо в традиционных РБД.

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

Объектно–ориентированная БД состоит из множества связанных объектов. Каждый объект образует структуру из свойств и методов, хранящихся в БД. Для управления данными объект описывается внешним интерфейсом. Доступ к объектным БД осуществляется из прикладных программ.

Стандарт ODMG - 3, предложенный Object Database Management Group (ODMG) в 1993 г. для объектно-ориентированных баз данных (ООБД), содержит требования и рекомендации:

-по объектной модели БД – Object Data Model (ODM);

-по языку определения объектов – Object Definition Language (ODL);

-по языку запросов к объектной базе – Object Query Language (OQL);

-по интерфейсам языков программирования (обычно С++).

Объектная модель ODMG для БД включает понятия объектов и литералов. Каждый объект базы образует сложную структуру и обладает уникальным идентификатором. Литералы представляют значения данных в различных структурах, среди которых могут быть и массивы структур, содержащих свойства объектов. База данных состоит из набора объектов, а ее

31