Принципы реляционной модели

Реляционная модель была разработана сотрудником фирмы IBM Эдгаром Франком Коддом (Edgar Frank Codd) и опубликована в 1970 г в работе «A Relational Model of Data for Large Shared Data Banks». Реляционная модель определяет способ представления данных (структуру данных), методы обеспечения целостности данных, и операции, которые можно выполнять с данными.

В начале 80-х годов прошлого столетия реляционная модель начала входить в моду. В 2002 журнал Forbes поместил реляционную модель данных в список важнейших инноваций последних 85 лет.

Основные принципы реляционных баз данных:

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

- каждому экземпляру сущности в отношении (таблице) соответствует кортеж или запись (строка таблицы);

- мощность отношения - число кортежей в отношении (проще говоря, число записей или строк в таблице);

- каждому атрибуту сущности соответствует столбец или поле в отношении (таблице);

- размерность - это число атрибутов в отношении;

- каждое отношение можно разделить на две части - заголовок и тело. На простом языке заголовок отношения - это список (названия) столбцов (полей), а тело - это сами записи (кортежи);

- каждый атрибут характеризуется таким понятием как "домен" или набор данных (тип данных). Понятие Домен можно интерпретировать как множество из которого "черпают" свои значения атрибуты.

Для того, чтобы не возникла путаница, еще раз акцентируем внимание на понятиях

- Relation – Отношение

- Relationship – Схема данных (схема связей)

В теории реляционных баз данных вводят реляционную алгебру - набор операций над отношениями, в результате которых получаются новые отношения. Реляционная алгебра в данной работе рассматриваться не будет.

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

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

Связь между таблицами называют связью 1:1 в том случае, если одной записи в одной таблице соответствует 1 запись в другой таблице. В качестве примера можно привести связь таблицы "студенты" и таблицы "зачетная_книжка". Одному студенту однозначно соответствует одна зачетная книжка. Обычно такие типы связи на практике реализуются путем добавления к искомой таблице дополнительного поля. В некоторых случаях такую связь все же реализуют для автоматического приведения таблиц ко второй нормальной форме (речь о нормальных формах пойдет ниже).

Часто используемыми типами связей между таблицами являются 1:M - один ко многим или М:1 - многие к одному. Такой тип связи используется в том случае, когда одной записи в одной таблице соответствует много записей в другой таблице. Например, у одного студента может быть несколько телефонных номеров (телефоны разных операторов связи). В этом случае в таблице "Телефон" создается поле "Key_stud", которое является внешним ключом для данной таблицы и в него заносятся значения поля "Key_stud", первичного ключа для таблицы "студенты", соответствующее экземпляру сущности "студент", имеющей данный телефонный номер. Таким образом следует помнить, что внешний ключ добавляется в ту таблицу, которая соответствует букве М в схеме связей.

Stud

key_stud	fio_stud
	Петров Владимир Владимирович
	Сидоров Александр Алексеевич
	Иванов Степан Сергеевич

Tel

key_tel	num_tel	komp_name_tel	key_stud
		МТС
		Билайн
		МТС

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

Stud

key_stud	fio_stud	key_town
	Петров Владимир Владимирович
	Сидоров Александр Алексеевич
	Иванов Степан Сергеевич

Town

key_town	name_town	reg_town
	Анапа	Россия
	Горно-Алтайск	Россия
	Майма	Россия

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

Stud

key_stud	fio_stud
	Петров Владимир Владимирович
	Сидоров Александр Алексеевич
	Иванов Степан Сергеевич
	Петрова Ирина Владимировна

Par

key_par	fio_par	status_par
	Петров Владимир Петрович	Отец
	Сидоров Аркаддий Семенович	Дед
	Иванова Степанида Григорьевна	Мать
	Иванова Ирина Петровна	Бабушка

Stud_Par

key_stud_par	key_stud	key_par

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

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

Но бывает, когда какой-то атрибут уникально не определяет значение одного атрибута, но ограничивает его набором нескольких значений. Например, у одного студента может быть несколько телефонов. В этом случае говорят о многозначной зависимости между первичным ключом и номерами телефонов. Для того, чтобы исключить многозначную зависимость "многозначно-зависимый" атрибут выделяют в отдельную сущность и применяют связь один ко многим (буква М относится к выделенному атрибуту).

Также существует так называемая частичная зависимость. Данная зависимость возникает тогда, когда помимо или вместо основного ключа в отношении существует составной ключ – несколько атрибутов, которые однозначно определяют экземпляр сущности. Например, в таблице работник, состоящей из атрибутов: Основной_ключ_работника, ФИО, Должность, Зарплата, Наличие_компьютера, помимо Основного_ключа_работника однозначно определяют экземпляр сущности еще два атрибута ФИО и Должность. Говорят, что в отношении существует частичная зависимость, если какой - то атрибут зависит от части составного ключа. Так, в данном примере Наличие_компьютера зависит только от Должности (компьютер нужен бухгалтеру, но не техничке, вне зависимости от личности), однако Зарплата определяется как Должностью (всегда существует вилка окладов), так и ФИО (например, техничке тете Маше директор может назначить заплату несколько больше, чем техничке тете Вале). Поэтому в случае Зарплаты частичной зависимости нет, а в случае Наличия_компьютера – есть. Для исключения частичной зависимости "частично-зависимый" атрибут вместе с атрибутом – частью составного ключа, от которого он зависит, выделяют в отдельную сущность. В рассматриваемом примере должно получиться два отношения: Основной_ключ_работника, ФИО, Внешний_ключ_должности, Зарплата и Основной_ключ_должности, Должность, Наличие_компьютера. Связь М:1 - многие работники могут иметь должность с одним названием.

Еще один тип зависимости, который выделяют особо – это транзитивная зависимость. Данный тип зависимости проявляется, когда какой-то атрибут зависит от первичного ключа не напрямую а через другой атрибут. Например это случается, когда в базу данных вносят так называемые "вычисляемые атрибуты" т.е атрибуты, значения которых можно получить из других атрибутов путем некоторых преобразований. Другими словами, если изменение значения какого–то атрибута обязательно влечет необходимость изменения другого атрибута, то говорят от транзитивной зависимости. Например, иногда хранят Фамилию и Фамилию в родительном падеже в одной таблице. Исправление ошибки в фамилии должно повлечь и исправлении ошибки в фамилии в родительном падеже. Для того, чтобы убрать такой тип зависимости вычисление значений "вычисляемых атрибутов" выполняют либо в хранимых процедурах, либо в представлениях при помощи агрегирующих функций языка SQL.

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

Итак, говорят, что таблица (отношение) находится в первой нормальной форме (1NF), если она соответствует следующим требованиям:

· Строки неупорядочены

· Столбцы неупорядочены

· Нет повторяющихся строк

· Значения ячеек (пересечений строк и столбцов) атомарны.

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

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

Говорят, что таблица (отношение) находится во второй нормальной форме (2NF), если она соответствует требованиям первой нормальной формы и между ее атрибутами отсутствует частичная функциональная зависимость. Вторая нормальная форма по определению запрещает наличие неключевых атрибутов, которые вообще не зависят от потенциального ключа. Таким образом, вторая нормальная форма запрещает создавать отношения как несвязанные (хаотические, случайные) наборы атрибутов. Например в таблице Студент не должно быть поля количество осадков за день.

Говорят, что таблица (отношение) находится в третьей нормальной форме (3NF), если она соответствует требованиям второй нормальной формы и между ее атрибутами отсутствует транзитивная функциональная зависимость. Другими словами, для обеспечения третьей нормальной формы желательно включать в таблицу только те поля, которые непосредственно (не через какую-то другую сущность) характеризуют искомый экземпляр сущности. Например, экземпляр сущности Студент непосредственно характеризуется своими ФИО, ключевым полем, указывающим на родителей, датой своего рождения, ключевым полем, указывающим на специальность по которой данный студент обучается. Однако, набор изучаемых дисциплин является уже характеристикой не студента, а специальности, которую студент для себя выбрал, а фамилии и имена преподавателей, являются характеристиками дисциплин, которые соответствуют специальности. Также профессия и доходы родителей не являются непосредственной характеристикой студента. Если преподавателей и названия дисциплин внести в таблицу Студенты, то данное отношение не будет соответствовать 3NF

Говорят, что таблица (отношение) находится в четвертой нормальной форме (4 NF), если она соответствует требованиям третьей нормальной формы и между ее атрибутами отсутствует многозначная зависимость.