Развитие теории и практики баз данных (стр. 2 из 4)

В реляционных СУБД для задания таких связей выполняют операцию их связывания.

Связывание таблиц позволяет:

а) средствами СУБД автоматически выполнять контроль целостности вводимых в базу данных;

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

Связывание выполняется по полям связи, которые могут быть обычными или ключевыми.

Используются следующие основные типы связей:

а) один ко многим (1: M);

б) много к одному (M:

1):

в) один к одному (1:

1);

г) много ко многим (M: M).

Из перечисленных видов связи наиболее широко используется связь вида 1: М. Связь вида 1: 1 можно считать частным случаем связи 1: М, когда одной записи главной таблицы соответствует одна запись вспомогательной таблицы. Связь М: 1 по сути, является "зеркальным отображением" связи 1: М. Оставшийся вид связи М: М характеризуется как слабый вид связи или даже как отсутствие связи. Поэтому в дальнейшем рассматривается связь вида 1: М.

При образовании связи вида 1: М одна запись главной таблицы (главная, родительская запись) оказывается связанной с несколькими записями дополнительной (дополнительные, подчиненные записи).

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

каждой записи основной таблицы соответствует нуль или более записей дополнительной таблицы;

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

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

ввод новых записей,

модификацию записей,

удаление записей.

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

целостности.

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

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

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

Структура объектно-ориентированной БД графически представима в виде дерева, узлами которого являются объекты. Свойства объектов описываются некоторым стандартным типом (например, строковым - string) или типом, конструируемым пользователем (определяется как class).

Пример логической структуры объектно-ориентированной БД библиотечного дела приведен на рис.1.

Рис.1. Логическая структура БД библиотечного дела

Здесь объект типа БИБЛИОТЕКА является родительским для объектов-экземпляров классов АБОНЕНТ, КАТАЛОГ и ВЫДАЧА. Различные объекты типа КНИГА могут иметь одного или разных родителей. Объекты типа КНИГА, имеющие одного и того же родителя, должны различаться по крайней мере инвентарным номером (уникален для каждого экземпляра книги), но имеют одинаковые значения свойств isbn, удк, название и автор.

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

Рассмотрим кратко понятия инкапсуляции, наследования и полиморфизма применительно к объектно-ориентированной модели БД.

Инкапсуляция ограничивает область видимости имени свойства пределами того объекта, в котором оно определено. Так, если в объект типа КАТАЛОГ добавить свойство, задающее телефон автора книги и имеющее название телефон, то мы получим одноименные свойства у объектов АБОНЕНТ и КАТАЛОГ. Смысл такого свойства будет определяться тем объектом, в который оно инкапсулировано.

Наследование, наоборот, распространяет область видимости свойства на всех потомков объекта. Так, всем объектам типа КНИГА, являющимся потомками объекта типа КАТАЛОГ, можно приписать свойства объекта - родителя: isbn, идк, название и автор. Если необходимо расширить действие механизма наследования на объекты, не являющиеся непосредственными родственниками (например, между двумя потомками одного родителя), то в их общем предке определяется абстрактное свойство типа abs. Так, определение абстрактных свойств билет и номер в объекте БИБЛИОТЕКА приводит к наследованию этих свойств всеми дочерними объектами АБОНЕНТ, КНИГА и ВЫДАЧА. Не случайно поэтому значения свойства билет классов АБОНЕНТ и ВЫДАЧА, показанных на рисунке, будут одинаковыми - 00015.

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

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

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

Рис 2. Фрагмент БД с объектом-целью

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

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

4. Нормализация отношений

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

Выбор схемы БД определяет возникновение в процессе ее эксплуатации тех или иных аномалий обновления.

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

Аномалии модификации - возникновение несогласованности записей в

таблице при изменении данных в одной записи.

Для отношения "Студент" (ФИО, Группа, Староста), где в столбце "Группа" хранится полное название группы, а столбец "Староста" содержит ФИО старосты группы, изменение значения "Староста" (например, для устранения ошибки) может привести к существованию более одного старосты одной и той же группы.

Аномалии удаления - удаление лишней информации при удалении записи.

Для отношения "Студент" (ФИО, Группа, Староста), удаление студента может привести к удалению из БД и ФИО старосты группы (в том случае, если для данной группы запись - единственная).

Аномалии вставки - добавление лишней информации или возникновение противоречащих значений в некоторых столбцах при вставке новой записи

Для отношения "Студент" (ФИО, Группа, Староста), где в столбце "Группа" хранится полное название группы, а столбец "Староста" содержит ФИО старосты группы, добавление названия новой группы повлечет обязательное определение ФИО студента и старосты, в то время как эти данные могут быть пока не известны. В то же время, при добавлении нового студента значение поля "Староста" в новой записи может не совпадать со значением данного поля для другого студента этой же группы.

Для сохранения корректности БД необходимо устранять данные аномалии, выполняя дополнительные операции по просмотру и модификации данных.

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