Рамиля Латыпова - Базы данных. Курс лекций. Учебное пособие

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

При работе с таблицами часто используют два представления: собственно таблицу и структуру таблицы. Пример приведен на рис. 5.

Таблица «Студенты»

Номер

Фамилия

Имя

Рост

Вес

Структура таблицы «Студенты»

Поле

Тип поля

Номер

Счетчик

Фамилия

Текстовый

Имя

Текстовый

Рост

Числовой

Вес

Числовой

Рис. 5.Пример описания таблицы и ее структуры

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

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

Например, если рассматривается таблица «Студенты», то в качестве первичного ключа нельзя использовать фамилию, имя или дату рождения, поскольку эта информация не уникальна.

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

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

Между двумя и более таблицами БД могут существовать отношения подчиненности . Это означает, что для каждой записи главной таблицы (родительской, или мастер-таблицы (англ.: master)) может существовать одна или несколько записей в подчиненной (или детальной (англ.: detail)) таблицы.

Связывание таблиц выполняется для устранения избыточности информации.

Существуют три разновидности связей между таблицами:

1. Связь «один-ко-многим» (или «многие-к-одному»);

2. Связь «один-к-одному»;

3. Связь «многие-ко-многим».

Связываемые поля не обязательно должны иметь одинаковые имена, но они должны иметь одинаковые типы данных.

Отношение «один-ко-многим» является самым распространенным, оно моделирует иерархию данных.

Рассмотрим пример, когда одной записи в родительской таблице соответствует несколько записей в дочерней таблице (рис. 6). В этом примере одной записи в родительской таблице «Товары» соответствует несколько записей в дочерней таблице «Отпуск товаров».

Отношение «один-к-одному» применяется тогда, когда стремятся сократить объем информации в одной таблице или защитить часть информации от доступа. Но здесь приходится выполнять больше операций чтения при извлечении связанных данных. В этом случае одной записи в главной таблице соответствует одна запись в подчиненной таблице (рис. 7).

Рис. 6.Связь «один-ко-многим»

Рис. 7.Связь «один-к-одному»

Такие связи также могут быть жесткими и нежесткими.

Рассмотрим отношение «многие-ко-многим». В этом случае возможны два варианта:

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

записи в дочерней таблице соответствует более одной записи в родительской таблице.

Пример приведен на рис. 8.

Рис. 8.Связь «многие-ко-многим»

Здесь имеется в виду, что один преподаватель читает разные курсы, а один и тот же курс могут читать разные преподаватели.

Любая связь «многие-ко-многим» может быть заменена на одну или более связей «один-ко-многим». Для этого нужно ввести промежуточную таблицу (рис. 9).

Рис. 9.Преобразование связи «многие-ко-многим»

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

Рассмотрим наиболее часто встречающуюся связь «один-ко-многим». Пример приведен на рис. 10.

Рис. 10.Пример связывания таблиц

Эти две таблицы связаны по общему полю «Товар». Таблица «Товары» является главной, таблица «Отпуск товаров» – подчиненной. Потеря связей возможна в двух случаях:

1. Изменяется значение в поле связей главной таблицы без изменения значений полей связи в соответствующих записях дочерней таблицы. Например, если вместо товара «Сахар» в таблице «Товары» написать «Песок», то все записи в дочерней таблице для «Сахар» потеряют связь и не будут иметь единицы измерения и цены;

2. Изменяется значение поля связи одной из записей дочерней таблицы без изменения значения поля связи в соответствующих записях главной таблицы. Например, если вместо товара «Сахар» в одной из записей таблицы «Отпуск товаров» написать «Песок», то будут недостоверными записи об отпуске товара «Сахар». Запись в дочерней таблице для «Песок» не будет иметь связи и, следовательно, единицы измерения и цены.

Таким образом, в обоих случаях возникает нарушение целостности БД.

Действия, нарушающие ссылочную целостность БД, должны блокироваться.

Для сохранения ссылочной целостности может использоваться также механизм каскадных изменений:

1. Синхронные изменения поля связи в дочерней таблице при внесении изменений в поле связи главной таблицы;

2. Синхронные удаления поля связи в дочерней таблице при удалении поля связи главной таблицы.

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

Обычно в СУБД для реализации ссылочной целостности в дочерней таблице создают внешний ключ , ссылающийся на родительскую таблицу, и указывают вид каскадных воздействий.

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