Лекция 5. Ссылочная целостность данных. Внешние ключи. Индексирование.

• Ссылочная целостность данных;

• Внешний ключ;

• Индекс;

• Курсор.

5.1. Ссылочная целостность данных

В самом общем виде понятие целостности БД подразумевает соответствие имеющейся в ней информации внутренней структуре БД, ее логике.

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

Всё это — правила ограничения целостности, которые помогают поддерживать указанное выше соответствие.

Задача. Создадим БД городов мира. В этой БД мы будем хранить название города и название страны, в которой находится город.

ID города	Название города	Страна
1	Киев	1
2	Москва	2
3	Львов	1

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

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

ID города	Название города	Страна
1	Киев	1
2	Москва	2
3	Львов	1

ID страны	Название страны
1	Украина
2	Россия

Таким образом, у нас появилось 2 таблицы — таблица стран и городов. При этом таблица стран — это т. н. справочник. Почему? Очень легко понять на примере. Итак, имеем таблицу стран с двумя странами: Украина (id=1) и Россия (id=2). В таблице стран имеем 3 города: Киев (id=1), Москва (id=2), Львов (id=3). Для принадлежности каждого города к конкретной стране поставили идентификаторы: у Киева и Львова — это 1, а у Москвы — 2. А расшифровка этих идентификаторов находится в таблице стран, т. е. в справочнике.

Теперь, если у страны изменится название, то мы меняем его только в справочнике, а таблицу городов не трогаем вообще, поскольку в ней нет названий стран (они в справочнике). Согласитесь, удобно. Фактически мы получили ситуацию, когда идентификатор страны из справочника (родительская таблица) используется в другой таблице (дочерней). Это как раз и есть упоминавшийся выше внешний ключ, который связывает поле дочерней таблицы с полем родителя.

Но пока что эта связь только у нас в уме. Для сервера ее нет. Соответственно, никаких ограничений такая связь не накладывает. Что нам мешает сейчас добавить в таблицу городов город с идентификатором страны 3? Т. е. это страна, не представленная в справочнике. Абсолютно ничего не мешает. Добавив указанную запись в таблицу городов мы как раз нарушаем целостность данных. К примеру, мы выводим на сайт список стран и по клику на страну выводим список городов этой страны. Наш «блудный» город без страны, таким образом, никогда выведен не будет. Получается, что это «лишняя», «болтающаяся» запись.

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