Лекция 4 Основные понятия реляционных баз данных
При работе с таблицами часто используют два представления: собственно таблицу и структуру таблицы. Пример приведен на рис. 5.
Таблица «Студенты»
Номер
Фамилия
Имя
Рост
Вес
Структура таблицы «Студенты»
Поле
Тип поля
Номер
Счетчик
Фамилия
Текстовый
Имя
Текстовый
Рост
Числовой
Вес
Числовой
Рис. 5. Пример описания таблицы и ее структуры
Таблица может иметь первичный ключ, под которым понимается поле или набор полей, однозначно идентифицирующих запись.
В таблице не должно быть записей с одним и тем же значением первичного ключа.
Например, если рассматривается таблица «Студенты», то в качестве первичного ключа нельзя использовать фамилию, имя или дату рождения, поскольку эта информация не уникальна.
В общем случае в качестве первичного ключа выгоднее использовать семантически незначащее (не несущее смысловой нагрузки) поле (счетчик), с помощью которого каждая запись получает уникальный номер.
Первичный ключ является разновидностью более общего понятия потенциального ключа, т. е. ключа, который может быть выбран в качестве первичного.
Между двумя и более таблицами БД могут существовать отношения подчиненности. Это означает, что для каждой записи главной таблицы (родительской, или мастер-таблицы (англ.: master)) может существовать одна или несколько записей в подчиненной (или детальной (англ.: detail)) таблицы.
Связывание таблиц выполняется для устранения избыточности информации.
Существуют три разновидности связей между таблицами:
1. Связь «один-ко-многим» (или «многие-к-одному»);
2. Связь «один-к-одному»;
3. Связь «многие-ко-многим».
Связываемые поля не обязательно должны иметь одинаковые имена, но они должны иметь одинаковые типы данных.
Отношение «один-ко-многим» является самым распространенным, оно моделирует иерархию данных.
Рассмотрим пример, когда одной записи в родительской таблице соответствует несколько записей в дочерней таблице (рис. 6). В этом примере одной записи в родительской таблице «Товары» соответствует несколько записей в дочерней таблице «Отпуск товаров».
Отношение «один-к-одному» применяется тогда, когда стремятся сократить объем информации в одной таблице или защитить часть информации от доступа. Но здесь приходится выполнять больше операций чтения при извлечении связанных данных. В этом случае одной записи в главной таблице соответствует одна запись в подчиненной таблице (рис. 7).
Рис. 6. Связь «один-ко-многим»
Рис. 7. Связь «один-к-одному»
Такие связи также могут быть жесткими и нежесткими.
Рассмотрим отношение «многие-ко-многим». В этом случае возможны два варианта:
записи в родительской таблице соответствует более одной записи в дочерней таблице;
записи в дочерней таблице соответствует более одной записи в родительской таблице.
Пример приведен на рис. 8.
Рис. 8. Связь «многие-ко-многим»
Здесь имеется в виду, что один преподаватель читает разные курсы, а один и тот же курс могут читать разные преподаватели.
Любая связь «многие-ко-многим» может быть заменена на одну или более связей «один-ко-многим». Для этого нужно ввести промежуточную таблицу (рис. 9).
Рис. 9. Преобразование связи «многие-ко-многим»
При связывании таблиц необходимо обеспечивать целостность данных, которая может быть нарушена при изменении полей связи.
Рассмотрим наиболее часто встречающуюся связь «один-ко-многим». Пример приведен на рис. 10.
Рис. 10. Пример связывания таблиц
Эти две таблицы связаны по общему полю «Товар». Таблица «Товары» является главной, таблица «Отпуск товаров» – подчиненной. Потеря связей возможна в двух случаях:
1. Изменяется значение в поле связей главной таблицы без изменения значений полей связи в соответствующих записях дочерней таблицы. Например, если вместо товара «Сахар» в таблице «Товары» написать «Песок», то все записи в дочерней таблице для «Сахар» потеряют связь и не будут иметь единицы измерения и цены;
2. Изменяется значение поля связи одной из записей дочерней таблицы без изменения значения поля связи в соответствующих записях главной таблицы. Например, если вместо товара «Сахар» в одной из записей таблицы «Отпуск товаров» написать «Песок», то будут недостоверными записи об отпуске товара «Сахар». Запись в дочерней таблице для «Песок» не будет иметь связи и, следовательно, единицы измерения и цены.
Таким образом, в обоих случаях возникает нарушение целостности БД.
Действия, нарушающие ссылочную целостность БД, должны блокироваться.
Для сохранения ссылочной целостности может использоваться также механизм каскадных изменений:
1. Синхронные изменения поля связи в дочерней таблице при внесении изменений в поле связи главной таблицы;
2. Синхронные удаления поля связи в дочерней таблице при удалении поля связи главной таблицы.
Разрешение или запрещение каскадных изменений реализуется при описании связей между таблицами БД.
Обычно в СУБД для реализации ссылочной целостности в дочерней таблице создают внешний ключ, ссылающийся на родительскую таблицу, и указывают вид каскадных воздействий.
Внешний ключ создается в дочерней таблице. В него входят поля связи дочерней таблицы. Для связей типа «один-ко-многим» внешний ключ должен совпадать по составу полей с первичным ключом главной таблицы или с частью первичного ключа (в этом случае нормализация таблиц БД выполнена не полностью).
При определении первичного и внешнего ключей СУБД автоматически строит индексы. Индекс, соответствующий внешнему ключу, строится для обеспечения связей родительской и дочерней таблиц [2].
Индексы обеспечивают механизм быстрого доступа к данным в таблицах. Индексы хранят значения индексных полей (по которым построен индекс) и указатель на запись в таблице.
Использование индексов позволяет использовать не просто последовательный, а индексно-последовательный доступ.
При последовательном доступе просматриваются все записи таблицы – от первой до последней, что неэффективно.
При индексно-последовательном доступе указатель в индексе устанавливается на первую строку, соответствующую условиям запроса (или его части), и считывается запись из таблицы по хранящемуся на нее в индексе указателю. Далее последовательно считываются остальные записи, удовлетворяющие условиям запроса.
Таким образом, во втором случае поиск ведется по индексу, а не по самой таблице. Таблица может быть неупорядоченна, а небольшой по объему индексный файл может быть легко отсортирован.
Например, рассмотрим табл. 1.
Таблица 1
Отпуск товара
Номер
Дата
Товар
Количество
1
06.01.14
Спички
2
2
02.01.14
Мыло
100
3
03.01.14
Мука
5000
4
08.01.14
Спички
10
Структура индексов по каждому из четырех полей показана в табл. 2.
Таблица 2
Индексированные поля таблицы
По дате прихода
По наименованию
По количеству
Дата
Номер записи
Товар
Номер записи
Количество
Номер записи
02.01.14
2
Мука
3
5000
3
03.01.14
3
Мыло
2
100
2
06.01.14
1
Спички
1
10
4
08.01.14
4
Спички
4
2
1
Если несколько товаров имеет одно и то же наименование, то достаточно найти в индексе, построенном по столбцу «Наименование», первую запись, а затем повторить чтение подряд для всех товаров с этим наименованием. То же самое касается даты и т. д.
Индексы наиболее выгодны для статичных таблиц, по которым часто выполняются запросы.