Начало развития реляционных баз данных - конец 1960-х гг., в это время появились первые работы с обсуждением возможностей использования привычных способов формализованного представления данных в виде таблиц, который называли таблицами решений или табличными алгоритмами.
Прародителем теории реляционных БД считают сотрудника фирмы IВM доктора Э. Ф. Кодда, опубликовавшего 6 июня 1970 года статью о реляционной модели данных для больших коллективных банков данных, в которой впервые использовали термин «реляционная модель данных», что и стало началом развития реляционных баз данных.
Э.Ф. Коддом было доказано, что любые наборы данных могут быть представлены двумерными таблицами особого вида, известными в матема-тике как отношения. Название «реляционная модель данных» произошло от английского «relation» («отношение»). Отсюда следует, что реляционная БД - это информация об объектах, которая представлена двумерными массивами - таблицами, которые объединены определенными связями. БД может быть представлена и одной таблицей.
Основные термины и определения
Таблица БД - это двумерный массив, в котором содержится информация об одном классе объектов.
В теории реляционной алгебры двумерный массив (таблицу) называют отношением.
В состав таблицы входят следующие элементы: поля, ячейки, записи.
В каждом поле содержится значение одного из признаков, который характеризует объект БД. Число полей в таблице будет соответствовать числу признаков объектов БД.
Ячейка – это наименьший структурный элемент таблицы, содержащий конкретное значение соответствующего поля (признака одного объекта).
Запись представляет собой строку таблицы, содержащую значения всех признаков, которые характеризуют 1 объект. Количество записей (строк) соответствует количеству объектов, данные о которых содержатся в таблице.
Одним из важных понятий, используемых в построении оптимальной структуры реляционной БД, является понятие ключа, или ключевого поля. Ключ - это поле, значением которого однозначно определяются значения всех остальных полей в таблице. К примеру, поле «Номер паспорта» однозначно определяет характеристику физического лица и используется при составлении соответствующих таблиц БД для отделов кадров или бухгалтерии организации. В качестве ключа таблицы могут использоваться несколько полей, а не одно. Ключевое поле должно обязательно удовлетворять двум независимым от времени условиям: уникальности и минимальности. Поля, не входящие в первичный ключ, называются не ключевыми полями таблицы.
Уникальность ключа обозначает, что в любое время таблица БД не может содержать две различные записи, которые имеют одинаковые значения ключевых полей. Уникальность является обязательным признаком ключевого поля.
Условие минимальности ключевого поля обозначает, что лишь сочетание значений выбранных полей отвечает требованиям уникальности записей таблицы БД. Ни одно из полей ключа нельзя исключить из него, не нарушив уникальности ключа.
При создании ключа таблицы БД из нескольких полей рекомендуется:
- не включать в состав ключа поля таблицы, значения которых сами по себе однозначно идентифицируют записи в таблице. К примеру, не следует создавать ключ, который содержит одновременно поля «номер паспорта» и «идентификационный номер налогоплательщика», так как каждый из данных признаков однозначно идентифицирует запись в таблице;
- не включать в состав ключа неуникальные поля, т.е. поля со значениями, которые могут повторяться в таблице.
В каждой таблице должен иметься хотя бы один ключ, использующийся в качестве первичного. В случае наличия в таблице полей, значения которых однозначно определяют записи, данные поля могут быть использованы в качестве альтернативных ключей. К примеру, в случае выбора в качестве первичного ключа идентификационного номера налогоплательщика номер паспорта может стать альтернативным ключом.
Нормализация таблиц реляционной БД
Реляционная БД состоит из некоторого множества таблиц, которые связаны между собой. Количество таблиц, входящих в состав одного файла или одной базы данных, зависит от ряда факторов. Основными из них являются:
- состав пользователей БД;
- обеспечение целостности информации (особо важно для мно-гопользовательских ИС);
- обеспечение наименьшего объема требуемой памяти и минимального времени обработки данных.
Учет приведенных факторов в процессе проектирования реляционных БД выполняется с помощью методов нормализации таблиц и установления связей между ними.
Нормализация таблиц – это процесс разделения одной таблицы БД на несколько таблиц, которые будут отвечать указанным выше требованиям.
Нормализация таблицы заключается в последовательном изменении структуры таблицы до тех пор, пока она не станет соответствовать требованиям последней формы нормализации.
Различают 6 форм нормализации:
- Первая нормальная форма (1NF).
- Вторая нормальная форма (2NF).
- Третья нормальная форма (ЗNF).
- Нормальная форма Бойса-Кодда (BCNF).
- Четвертая нормальная форма (4NF).
- Пятая нормальная форма (нормальная форма проекции-соединения) (5NF (PJ/NF)).
Для описания нормальных форм используют пнятия: функциональной зависимости между полями, полной функциональной зависимости между полями, многозначной функциональной зависимости между полями, транзитивной функциональной зависимости между полями, взаимной независимости между полями.
Функциональная зависимость между полями А и В - это зависимость, определяющая каждому значению А в любой момент времени соответствие единственного значения В из всех возможных. В качестве примера функциональной зависимости можно привести связь между идентификационным номером налогоплательщика и номером его паспорта.
Полная функциональная зависимость между составным полем А и полем В - это зависимость, при которой поле В функционально зависит от поля А и в то же время функционально не зависит от любого подмножества поля А. Многозначную функциональную зависимость между полями можно определить следующим образом. Полем А многозначно определяется поле В, если для каждого значения поля А существует опре-деленное множество соответствующих значений поля В.
К примеру, рассмотрим таблицу успеваемости ученика, которая включает в себя поля «Предмет» (поле А) и «Оценка» (поле В), то поле В будет иметь определенное множество допустимых значений: 1, 2, 3, 4, 5, т.е. каждому значению поля «Предмет» будет соответствовать многозначное определенное множество значений поля «Оценка». Транзитивная функциональная зависимость между полями А и С будет существовать только в том случае, когда поле С станет функционально зависеть от поля В, а поле В станет функционально зависеть от поля А, однако функциональной зависимости между полями А и В не будет.
Взаимную независимость между полями определяют так: несколько полей будут взаимно независимыми только в том случае, если ни одно из них не будет являться функционально зависимым от другого.
-
Первая нормальная форма. Таблица будет находиться в первой нормальной форме лишь в том случае, когда ни одно из ее полей не будет содержать более 1 значения и любое ключевое поле не будет пустым.
Данная форма является основой реляционной модели данных. Любая таблица реляционной базы данных автоматически будет находиться в первой нормальной форме. В подобной таблице не содержатся поля (признаки), которые можно разделить на несколько полей (признаков).
Ненормализованные таблицы не предназначены для компьютерной обработки содержащейся в них информации.
Замечание 2Отсюда следует, что такой состав таблиц и их структура имеют явную избыточность информации, что потребует дополнительного объема памяти. Поэтому требуется привести таблицы ко второй или третьей нормальной форме.
-
Вторая нормальная форма. Таблица находится во второй нор-мальной форме, когда она удовлетворяет требованиям первой нормальной формы и все ее поля, которые не входят в первичный ключ, будут функционально связаны полной зависимостью с первичным ключом.
В случае наличия в таблице простого первичного ключа, состоящего из одного поля, она автоматически станет находиться во второй нормальной форме. В случае наличия составного первичного ключа нахождение таблицы во второй нормальной форме будет не обязательным. В данной ситуации таблицу нужно разделить на две или более, чтобы первичный ключ однозначно идентифицировал значение в любом поле. Когда таблица имеет хотя бы одно поле, которое не зависит от первичного ключа, то в него включают дополнительные колонки. Если подобных колонок нет, то добавляют новую колонку. Общий объем памяти для хранения информации в данной форме нормализации значительно меньше, чем в исходных таблицах.
Помимо этого, новая структура БД сможет обеспечить возможность заполнения таблиц специалистами разного профиля. Дальнейшая оптимизация таблиц БД сведется к приведению их к третьей нормальной форме.
-
Третья нормальная форма. Таблица будет находиться в третьей нормальной форме, когда станет удовлетворять определению второй нор-мальной формы и ни одно из ее простых (не ключевых) полей не станет зависеть функционально от другого такого же.
Нормальная форма Бойса - Кодда. Таблица находится в нор-мальной форме Бойса-Кодда лишь тогда, когда любая функциональная зависимость между ее полями будет сводиться к полной функциональной зависимости от ключа. Дальнейшая оптимизация таблиц БД сведется к полной декомпозиции таблиц, под которой понимают такую совокупность произвольного числа ее проекций, соединение которых полностью совпадает с содержимым таблицы.
Определение 6Проекция - это копия таблицы, которая не содержит одну или несколько колонок новой таблицы.
-
Четвертая нормальная форма. Четвертая нормальная форма - это частный случай пятой нормальной формы, когда полная декомпозиция является соединением двух проекций.
-
Пятая нормальная форма. Таблица находится в пятой нормальной форме лишь в том случае, когда в каждой ее полной декомпозиции во всех проекциях содержится возможный ключ. Таблица, в которой нет ни одной полной декомпозиции, тоже будет находиться в пятой нормальной форме.
На практике оптимизация таблиц БД заканчивается третьей нормальной формой.
