Тема 1.2. Взаимосвязи в моделях и реляционный подход к построению моделей

Основы реляционной алгебры

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

Рассмотрим некоторые из них.

Объединение – возвращает отношение, содержащее все кортежи, принадлежащие первому или второму отношению.

Пример: До операции «объединение» существовало две таблицы:

ФИО	Год рождения	Пол		ФИО	Год рождения	Пол
Иванов С.Н	1989	м		Иванов С.Н.	1989	м
Смирнова Р.М.	1989	ж		Сергеева Е.Д.	1990	ж
Радченко С.В.	1990	ж
Уткин О.Ф.	1990	м

После операции «объединение» получена одна таблица, содержащая все данные, находившиеся ранее хотя бы в одной из таблиц.

ФИО	Год рождения	Пол
Иванов С.Н	1989	м
Смирнова Р.М.	1989	ж
Радченко С.В.	1990	ж
Уткин О.Ф.	1990	м
Сергеева Е.Д.	1990	ж

Пересечение – возвращает отношение, содержащее все кортежи, принадлежащие и первому и второму отношению.

Пример: До операции «пересечение» существовало две таблицы:

ФИО	Год рождения	Пол		ФИО	Год рождения	Пол
Иванов С.Н	1989	м		Иванов С.Н.	1989	м
Смирнова Р.М.	1989	ж		Сергеева Е.Д.	1990	ж
Радченко С.В.	1990	ж
Уткин О.Ф.	1990	м

После операции «пересечение» получена одна таблица, содержащая все данные, находившиеся ранее в обеих таблицах.

ФИО	Год рождения	Пол
Иванов С.Н	1989	м

Разность – возвращает отношение, содержащее все кортежи, принадлежащие и первому и не принадлежащие второму отношению.

Пример: До операции «разность» существовало две таблицы:

ФИО	Год рождения	Пол		ФИО	Год рождения	Пол
Иванов С.Н	1989	м		Иванов С.Н.	1989	м
Смирнова Р.М.	1989	ж		Сергеева Е.Д.	1990	ж
Радченко С.В.	1990	ж
Уткин О.Ф.	1990	м

После операции «Разность» получена одна таблица, содержащая все данные, находившиеся ранее в обеих таблицах.

ФИО	Год рождения	Пол
Смирнова Р.М.	1989	ж
Радченко С.В.	1990	ж
Уткин О.Ф.	1990	м
Сергеева Е.Д.	1990	ж

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

Пример: До операции «Произведение» существовало две таблицы, содержащие в частности, следующие поля:

Должность		Номер кафедры
Зав. Кафедрой		21
Старший преподаватель		22
Преподаватель

После операции «Произведение» получена одна таблица, содержащая

Должность	Номер кафедры
Зав. Кафедрой	21
Старший преподаватель	21
Преподаватель	21
Зав. Кафедрой	22
Старший преподаватель	22
Преподаватель	22

Выборка (селекция) – возвращает отношение, содержащее все кортежи из данного отношения, которые удовлетворяют указанным условиям.

На практике эту операцию удобно представить как отбор из таблицы ряда строк, удовлетворяющих указанному критерию.

Пример: – из списка студентов выбрать юношей 1990-го года рождения.

До операции «выборка» существовала таблица:

ФИО	Год рождения	Пол
Иванов С.Н	1989	м
Смирнова Р.М.	1989	ж
Радченко С.В.	1990	ж
Уткин О.Ф.	1990	м
Сергеева Е.Д.	1990	ж

После этой операции:

ФИО	Год рождения	Пол
Уткин О.Ф.	1990	м

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

Пример: До операции «проекция» существовала таблица:

ФИО	Год рождения	Пол
Иванов С.Н	1989	м
Смирнова Р.М.	1989	ж
Радченко С.В.	1990	ж
Уткин О.Ф.	1990	м
Сергеева Е.Д.	1990	ж

После этой операции:

ФИО	Год рождения
Иванов С.Н	1989
Смирнова Р.М.	1989
Радченко С.В.	1990
Уткин О.Ф.	1990
Сергеева Е.Д.	1990

Соединение двух отношений по заданному условию – возвращает новое отношение, которое является, по сути, выборкой из произведения.

Реляционное деление отношений с длиной кортежей к1 и к2, (к1>к2), возвращает новое отношение, состоящее из кортежей длины (к1-к2), таких, что для всех кортежей s, принадлежащих S кортеж ts принадлежит R.

Алгоритм вычисления:

Пусть – n количество строк отношения S.

а) цикл: от i=1 до n

начало:

- выделить из R кортежи с окончанием, равным i-ой строке S.

- полученный результат сохранить в виде множества кортежей Qi.

конец.

б) результат деления равен пересечению полученных множеств Qi, i = 1,…, n.

Индексирование

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

Термин «индекс» тесно связан с понятием «ключ», хотя между ними есть некоторое отличие.

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

Индекс выполняет роль оглавления таблицы, просмотр которого предшествует обращению к записям. Доступ к данным зависит от следующих факторов:

- вида содержимого в ключевом поле индексного файла;

- типа используемых ссылок на запись основной таблицы;

- метода поиска нужных записей.

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

Для организации ссылки на запись таблицы могут использоваться три типа адресов:

- абсолютный (действительный),

- относительный,

- символический (идентификатор).

На практике чаще всего используются два метода поиска:

- последовательный,

-бинарный (основанный на делении интервала поиска пополам).

Главная причина повышения скорости выполнения различных операций в индексированных таблицах состоит в том, что основная часть работы производится с небольшими индексными файлами, а не с таблицами. Наибольший эффект повышения производительности работы с индексированными таблицами достигается для значительных по объему таблиц. Индексирование требует небольшого дополнительного места на диске и незначительных затрат процессора на изменение индексов в процессе работы. Индексы в общем случае могут изменяться перед выполнением запросов к БД, после выполнения запросов к БД, по специальным командам пользователя или программным вызовам приложений.

Типы данных

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

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

- Поле MEMO (Memo) — предназначено для ввода букв, цифр и знаков препинания (длинные тексты и комментарии — не более 65535 символов). Поле этого типа не может быть ключевым.

- Числовой (Number) — содержит только цифровую информацию (за исключением денежных величин), которую в дальнейшем можно использовать для вычислений.  Данные этого типа могут содержаться в 1, 2, 4, 8 байтах в зависимости от «Размера поля». При выборе размера поля надо оценить предварительно, какого вида числа будут храниться в данном поле (целые, дробные и т.д.). В таблице 1.3 представлены некоторые возможные значения Размеров числовых полей:

Таблица 1.3 Значения размеров числовых полей

Размер поля	Десятичные знаки	Диапазон значений
Байт	-	0 – 225
Целое	-	от –32768 до +32768
Длинное целое	-	от – 2147483648 до +2147483648
Одинарное с плавающей запятой	7	от – 3,4 10 38 до + 3,4 10 38
Двойное с плавающей запятой	15	от - 1,7976.. 10 308 до + 1,7876.. 10 308
Действительное	28	От – 10 -28 до + 10 28

- Денежный (Currency) — предназначен для ввода денежных величин. Стандартный шаблон для полей этого типа предусматривает использование двух десятичных знаков, т.е. учет копеек. Максимальное число отображаемых десятичных знаков не превышает четырех. Он используется для предотвращения ошибок при округлении.

- Дата/время (Date/Time) — содержит информацию о дате и времени. Дата и время хранятся в виде числа, целая часть которого представляет дату, дробная — время. Дата и время могут выводиться в различных форматах.  (Краткий, средний, длинный формат даты; краткий, средний, длинный формат времени).

- Счетчик (AutoNumber) — имеет формат длинного целого (Long Integer) . При добавлении новой записи значение этому полю присваиваются автоматически. Это поле можно использовать в качестве ключевого.

- Логический (Yes/No) — применяется для полей содержащих значения Да (Yes) или Нет (No). Например, в таком поле можно указать имеет ли данный сотрудник детей или нет. В логические поля можно записать число 0, которое интерпретируется как Ложь (False) или 1 — подразумевается Истина (True) . В MS Access при применении такого типа данных в поле таблицы появляется (см. рис. 1.4):

Рис.1.4 Отображение логического типа данных в MS Access

Логическое поле не может быть ключевым, но по нему можно индексировать таблицу.  

- Поле объекта OLE (OLE Object) — содержит объекты из других программ (растровые и векторные рисунки, фотографии, аудио и видео файлы, электронные таблицы и т.д.). Это поле не может быть ключевым или индексным.

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

-   Гиперссылка (Hyperlink) — предназначено для хранения адреса веб-страницы, расположенной в Интернете, локальной сети или на автономном компьютере. После щелчка мышью на этом поле автоматически запускается обозреватель. Гиперссылки позволяют выполнять переходы между объектами Microsoft Access без помощи программирования. Для создания ссылки, открывающей объект Access, надо ввести имя объекта в поле гиперссылки.

Свойства полей

В СУБД MS Access в свойствах полей имеются две вкладки: «Общие» и «Подстановка». На вкладке «Общие» реализуются следующие основные свойства полей в структурах таблиц базы данных:

-  Размер поля (Field Size) — для текстового поля определяет максимальное число символов, которое может быть введено (не более 255). В СУБД MS Access установлен по умолчанию размер поля, равный 50 символам. Для числовых полей выбирается длинное целое, целое и т.п. Чем шире поле, тем труднее пользоваться таблицей, так как она может не помещаться на экране. Однако поле, имеющее слишком маленький размер, может не вместить требуемую информацию. У некоторых типов полей: Дата/время, Денежный, Мемо MEMO, Поле объекта OLE этого свойство отсутствует.

- Формат поля (Format) — позволяет изменить отображение данных на экране или при печати. Например, для поля «Дата/время»: длинный формат даты отображает: «Вторник, 18 декабря 2001 г.», короткий — «18.12.2001». Формат выбирается из раскрывающегося списка. По умолчанию он определяется региональными настройками, сделанными в окне «Панель управления» операционной системы. У полей типа Поле объекта OLE (OLE Object) это свойство отсутствует.  

- Новые значения (New Value) — определяет способ вычисления нового значения для добавляемой в таблицу записи. Это свойство есть только у полей Счетчик. Из раскрывающегося списка выбирается одно из двух возможных значений: «случайные» или «последовательные». При выборе значения «Последовательные» новое значение поля увеличивается на 1.  

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

- Число десятинных знаков (DecimalPlaces) — используется для числовых полей. Из раскрывающегося списка можно выбрать значение «Авто» или определенное значение. Число десятичных знаков можно так же ввести вручную.  

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

- Значение по умолчанию (Default Value) — предусматривает автоматический ввод определенного значения, например, если почти все представленные в таблице компьютеры имеют процессор Pentium, то в столбце Процессор можно предусмотреть ввод по умолчанию этого названия. Для числовых полей  по умолчанию вводится число «0».

- Условие на значение (Validation Rule) — предусматривает ввод условия, которое будет проверяться каждый раз после изменения значения поля.  

- Сообщение об ошибке (Validation Text ) — появляется в строке состояния при вводе в таблицу значения не соответствующего условию проверки.  

- Обязательное поле (Required) — после ввода значения Да (Yes) для этого свойства, все записи таблицы в указанном поле должны быть заполненными. Если указанное поле не будет заполнено, Access отобразит на экране соответствующее предупреждение.  

- Пустые строки (Allow Zero Length) — поле должно содержать хотя бы один символ, если для него установлено значение Да (Yes) . Это свойство предусмотрено только для тестовых, MEMO полей и гиперссылок.

 -  Индексированное поле (Indexed) — определяет индекс, создаваемый по одному полю, что ускоряет поиск значений в этом поле. Если в этом поле часто будет выполняться поиск значений, то в раскрывающемся списке значений свойства выбирается «Да (Совпадения допускаются)». Если две записи не могут иметь одинаковое значение для данного поля, то устанавливается значение «Да (Совпадения не допускаются)». Значение «Нет» удаляет значение индекса, кроме единственного ключевого поля. Нельзя индексировать таблицы по следующим полям: MEMO, Поле объекта OLE и Гиперссылка.

На вкладке «Подстановка» (Lookup) можно выбираться Тип элемента управления, который влияет на отображение данных при вводе. Например, если задан тип данных: Текстовый, то можно отобразить его как «Поле», «Список» или «Поле со списком».

Связывание таблиц

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

Между таблицами могут устанавливаться бинарные (между двумя таблицами), тернарные (между тремя таблицами) и, в общем случае, n-арные связи. Рассмотрим наиболее часто встречающиеся бинарные связи. Суть связывания состоит в установлении соответствия полей связи двух таблиц.  В зависимости от того, как определены поля связи основной и дополнительной таблиц (как соотносятся ключевые поля с полями связи), между двумя таблицами в общем случае могут устанавливаться связи различного вида. В таблице 1.4 представлены различные виды связей.

Таблица 1.4 Связи между таблицами

Характеристика полей связи по видам	1:1	1:М	М:1	М:М
Поля связи первой таблицы	являются ключом	являются ключом	не являются ключом	являются ключом
Поля связи второй таблицы	являются ключом	не являются ключом	являются ключом	являются ключом

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

На практике связи вида 1:1 используются сравнительно редко, так как хранимую в двух таблицах информацию легко объединить в одну таблицу, которая занимает гораздо меньше места в памяти компьютера. Возможны случаи, когда удобнее иметь не одну, а две и более таблицы. Причинами этого может быть необходимость ускорить обработку, повысить удобство работы нескольких пользователей с общей информацией, обеспечить более высокую степень защиты информации и т. д.

Например:     Имеются сведения о выполняемых в некоторой организации научно-исследовательских работах. (Таблица 1.5) Эти данные включают в себя следующую информацию по каждой из работ – тему (девиз и полное наименование работ), шифр (код), даты начала и завершения работы, количество этапов, головного исполнителя и другую дополнительную информацию. Все работы имеют гриф "Для служебного пользования" или "секретно".      В такой ситуации всю информацию целесообразно хранить в двух таблицах: в одной из них - всю секретную информацию (например, шифр, полное наименование работы и головной исполнитель), а в другой - всю оставшуюся несекретную информацию. Обе таблицы можно связать по шифру работы (Рис. 1.5).

Таблица 1.5 «Работы»

Код	Наименование	Дата начала работы	Дата завершения работы	Кол-во этапов	Головной исполнитель	Примечания	…
1	Анализ информационных потоков фирмы	30.10.2008	30.10.2009	3	Аналитический отдел	Для служебного пользования
2	Создание БД	10.09.2008	10.12.2009	5	Администратор	Секретно

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

Р ис 1.5 Преобразование таблицы «Работы» в две таблицы, связанные 1:

Д ругой пример: предположим, что часть сведений о сотрудниках принадлежит категории «для служебного пользования» (ФИО, год рождения, фотография, должность, отдел, дата приема на работу, стаж работы и т.д.). Другая часть сведений принадлежит категории «секретно» (домашний адрес, телефон, оклад, …). В этом случае таблицу «Сотрудники» так же можно разделить на две (Рис 1.6).

Рис 1.6 Преобразование таблицы «Сотрудники» в две таблицы, связанные 1:1

Связь вида 1:М имеет место в случае, когда одной записи из первой таблицы может соответствовать несколько записей из второй таблицы, но каждой записи из второй таблицы может соответствовать только одна запись из первой таблицы. Это самый распространенный тип связи. При связывании двух таблиц выделяют основную и дополнительную (подчиненную) таблицы. Логическое связывание таблиц производится с помощью ключа связи.   Ключ связи, по аналогии с обычным ключом таблицы, состоит из одного или нескольких полей.

Такой тип связи применяется, например, в следующем случае: имеется две таблицы. Первая содержит сведения о владельцах квартир (ФИО, личные данные, адрес прописки, …), а вторая – сведения о жилье (адрес, общая площадь, жилая площадь, число комнат, …). Каждый из владельцев может иметь в собственности несколько квартир; но у каждой из квартир должен быть только один хозяин. В приведенном примере основной является таблица «владельцы квартир», а дополнительной – «жилье».

Другой пример. Имеется база данных, составленная для библиотеки колледжа. Одна из таблиц содержит сведения о читателях. Другая – сведения о имеющихся произведениях. Каждый из читателей может взять на руки несколько произведений, но каждое из произведений может находиться на руках у одного из читателей. В данном случае основная таблица – «читатели», дополнительная «произведения».

Для организации такого вида связи в основной таблице выбирают ключевое поле (ключ связи). Это поле добавляют в подчиненную таблицу. Таблицы связываются по этим полям. Добавленное в дополнительную таблицу из основной поле называется альтернативным ключом. В отличие от ключевого поля основной таблицы, данные здесь могут повторяться. Однако значениями альтернативного ключа могут быть только такие данные, которые есть в ключевом поле основной таблицы.

Например:     Имеются две таблицы, содержащие сведения о сотрудниках и их окладах, зависящих от разряда (Рис 1.7). Таблица «Оклад» - является основной, таблица «Сотрудники» - альтернативной.

Заполнение таблиц, связанных между собой связью 1:М начинается с основной таблицы.

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

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

Д ля схемы отношений (таблиц) БД «студенческая библиотека» (Рис. 1.9)

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

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

Н апример: предприятие выпускает несколько видов товаров и поставляет его нескольким потребителям. Каждый товар может быть приобретен несколькими потребителями и каждый потребитель может получить несколько видов товаров. Первая таблица содержит сведения о товарах, вторая – о потребителях. Обе таблицы являются равнозначными. Как и связь 1:1, связь М:М не устанавливает подчиненности таблиц. Для создания связи М:М надо создать третью таблицу, в которой поместить поля «Код товара» и «Код потребителя» из первых двух таблиц. Сюда же можно добавить, например, поле «количество». Тогда можно будет получить ответ на запрос о количестве товара, приобретенного каждой формой и его стоимости. Схема таблиц представлена на Рис. 1.10.

Сами таблицы могут иметь, например, следующий вид (Рис. 1.11):

ТОВАРЫ						ТАБЛИЦА СВЯЗИ			ПОТРЕБИТЕЛИ
Код Товара	Наименование	Ед.	Цена	…		Код Товара	Код потребителя		Код потребителя	Название	…
ПР12	Гайка	шт.				ПР12	1010		1010	ООО «НИКЛ»
						ПР12	1011
ПР13	Шайба	шт.				ПР13	1010		1011	ООО «Заря»
						ПР14	1010
ПР14	Болт	шт.				ПР14	1011		1012	ООО ГРАНД
ПР15	Шуруп

Рис 1.11 Содержание таблиц, связанных между собой связью М:М

Исходя из данных таблиц, следует, что товары с кодами «ПР12» и «ПР14» (т.е. гайки и шайбы) - поставляется в фирмы «ООО НИКЛ» и «ООО Заря». Товар «ПР 13» (шайбы) - только в фирму «ООО Заря». Фирма «ООО ГРАНД» - не заказывала ни одного из наименований товаров. Товар «ПР15» (шурупы) – не был приобретен ни одной из фирм.

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

Заполнение таблиц происходит следующим образом. Сначала заполняются таблицы, содержащие сведения о товарах и потребителях в любом порядке. (В общем случае – таблицы, содержащие описание каких-либо предметов (сущностей)). Затем – заполняется таблица, связывающая их.

Контроль целостности связей

Из перечисленных видов связи наиболее широко используется связь вида 1:М. Связь вида 1:1 можно считать частным случаем связи 1:М, когда одной записи главной таблицы соответствует одна запись вспомогательной таблицы. Связь М:1, по сути, является "зеркальным отображением" связи 1:М. Оставшийся вид связи М:М характеризуется как слабый вид связи или даже как отсутствие связи. Поэтому в дальнейшем рассматривается связь вида 1:М.     Как отмечалось ранее, при образовании связи вида 1:М одна запись главной таблицы (главная, родительская запись) оказывается связанной с несколькими записями дополнительной (дополнительные, подчиненные записи).

     Контроль целостности связей обычно означает анализ содержимого двух таблиц на соблюдение следующих правил:

- каждой записи основной таблицы соответствует нуль или более записей дополнительной таблицы;

- в дополнительной таблице нет записей, которые не имеют родительских записей в основной таблице;

- каждая запись дополнительной таблицы имеет только одну родительскую запись основной таблицы.

Рассмотрим действие контроля целостности при манипулировании данными в таблицах. Рассмотрим три основные операции над данными двух таблиц:

- ввод новых записей,

- модификацию записей,

- удаление записей.

При вводе новых записей возникает вопрос определения последовательности ввода записей в таблицы такой, чтобы не допустить нарушение целостности. Исходя из приведенных правил, логичной является схема, при которой данные сначала вводятся в основную таблицу, а потом - в дополнительную. Очередность ввода может быть установлена на уровне целых таблиц или отдельных записей (случай одновременного ввода в несколько открытых таблиц).      В процессе заполнения основной таблицы контроль значений полей связи ведется как контроль обычного ключа (на совпадение со значениями тех же полей других записей). Заполнение полей связи дополнительной таблицы контролируется на предмет совпадения со значениями полей связи основной таблицы. Если вновь вводимое значение в поле связи дополнительной таблицы не совпадет ни с одним соответствующим значением в записях основной таблицы, то ввод такого значения должен блокироваться.    

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

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

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

- изменения в полях связи основной таблицы мгновенно передавать во все поля связи дополнительной таблицы (каскадное обновление).

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

- удалять можно запись, которая не имеет подчиненных записей;

- запретить (блокировать) удаление записи при наличии подчиненных записей, либо удалять ее вместе со всеми подчиненными записями (каскадное удаление).

Проектирование баз данных

Проблема проектирования реляционной базы данных в обоснованном принятии решений по следующим пунктам:

- 1. – Из каких отношений (таблиц) должна состоять база данных.

- 2. – Какие атрибуты (заголовки полей) должны быть у этих отношений.

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

- первая нормальная форма (1НФ);

- вторая нормальная форма (2НФ);

- третья нормальная форма (3НФ);

- нормальная форма Бойса-Кодда (НФБК);

- четвертая нормальная форма (4НФ);

- пятая нормальная форма (5НФ).

Основные свойства нормальных форм: каждая следующая нормальная форма в некотором смысле лучше предыдущей. При переходе к следующей нормальной форме свойства предыдущих нормальных свойств сохраняются. В основе процесса проектирования лежит метод нормализации: декомпозиция отношения, находящегося в предыдущей нормальной форме, в два или более отношения, удовлетворяющих требованиям следующей нормальной формы. Наиболее важные на практике нормальные формы отношений основываются на фундаментальном в теории реляционных баз данных понятии функциональной зависимости.

Функциональная зависимость. В отношении R атрибут Y функционально зависит от атрибута X (X и Y могут быть составными) в том и только в том случае, если каждому значению X соответствует в точности одно значение Y.

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

Транзитивная функциональная зависимость. Функциональная зависимость X -> Y называется транзитивной, если существует такой атрибут Z, что имеются функциональные зависимости X -> Z и Z -> Y и отсутствует функциональная зависимость Z -> X.

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

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

Взаимно независимые атрибуты. Два или более атрибута взаимно независимы, если ни один из этих атрибутов не является функционально зависимым от других.

Рассмотрим пример проектирования базы данных:

Предположим, что проектирование базы данных «Питание» начинается с выявления атрибутов и подбора данных. Таблица 1.6

Таблица 1.6 «Питание»

Блюдо

Вид

Рецепт

Порций

Дата Р

Продукт

Калорийность

Вес (г)

Поставщик

Город

Страна

Вес (кг)

Цена ($)

Дата П

Лобио

Закуска

…

158

1/9/94

Фасоль

3070

200

"Хуанхэ"

Пекин

Китай

250

0.37

24/8/94

Лук

450

40

"Наталка"

Киев

Украина

100

0.52

27/8/94

Масло

7420

30

"Лайма"

Рига

Латвия

70

1.55

30/8/94

Зелень

180

10

"Даугава"

Рига

Латвия

15

0.99

30/8/94

Харчо

Суп

...

144

1/9/94

Мясо

1660

80

"Наталка"

Киев

Украина

100

2.18

27/8/94

Лук

450

30

"Наталка"

Киев

Украина

100

0.52

27/8/94

Томаты

240

40

"Полесье"

Киев

Украина

120

0.45

27/8/94

Рис

3340

50

"Хуанхэ"

Пекин

Китай

75

0.44

24/8/94

Масло

7420

15

"Полесье"

Киев

Украина

50

1.62

27/8/94

Зелень

180

15

"Наталка"

Киев

Украина

10

0.88

27/8/94

Шашлык

Горячее

...

207

1/9/94

Мясо

1660

180

"Юрмала"

Рига

Латвия

200

2.05

30/8/94

Лук

450

40

"Полесье"

Киев

Украина

50

0.61

27/8/94

Томаты

240

100

"Полесье"

Киев

Украина

120

0.45

27/8/94

Зелень

180

20

"Даугава"

Рига

Латвия

15

0.99

30/8/94

Кофе

Десерт

...

235

1/9/94

Кофе

2750

8

"Хуанхэ"

Пекин

Китай

40

2.87

24/8/94

Этот вариант таблицы "Питание" не является отношением, так как большинство ее строк не атомарны. Атомарными являются лишь значения полей Блюдо, Вид, Рецепт (хотя он и большой), Порций и Дата_Р остальные же поля таблицы– множественные. Для придания таким данным формы отношения необходимо реконструировать таблицу. Наиболее просто это сделать с помощью простого процесса вставки, результат которой показан в таблице 1.7.

Таблица 1.7 Отношение: «Питание»

Блюдо

Вид

Рецепт

Порций

Дата Р

Продукт

Калорийность

Вес (г)

Поставщик

Город

Страна

Вес (кг)

Цена ($)

Дата П

Лобио

Закуска

…

158

1/9/94

Фасоль

3070

200

"Хуанхэ"

Пекин

Китай

250

0.37

24/8/94

Лобио

Закуска

…

108

1/9/94

Лук

450

40

"Наталка"

Киев

Украина

100

0.52

27/8/94

Лобио

Закуска

…

108

1/9/94

Масло

7420

30

"Лайма"

Рига

Латвия

70

1.55

30/8/94

Лобио

Закуска

…

108

1/9/94

Зелень

180

10

"Даугава"

Рига

Латвия

15

0.99

30/8/94

Харчо

Суп

...

144

1/9/94

Мясо

1660

80

"Наталка"

Киев

Украина

100

2.18

27/8/94

Харчо

Суп

...

144

1/9/94

Лук

450

30

"Наталка"

Киев

Украина

100

0.52

27/8/94

Харчо

Суп

...

144

1/9/94

Томаты

240

40

"Полесье"

Киев

Украина

120

0.45

27/8/94

Харчо

Суп

...

144

1/9/94

Рис

3340

50

"Хуанхэ"

Пекин

Китай

75

0.44

24/8/94

Харчо

Суп

...

144

1/9/94

Масло

7420

15

"Полесье"

Киев

Украина

50

1.62

27/8/94

Харчо

Суп

...

144

1/9/94

Зелень

180

15

"Наталка"

Киев

Украина

10

0.88

27/8/94

Шашлык

Горячее

...

207

1/9/94

Мясо

1660

180

"Юрмала"

Рига

Латвия

200

2.05

30/8/94

Шашлык

Горячее

...

207

1/9/94

Лук

450

40

"Полесье"

Киев

Украина

50

0.61

27/8/94

Шашлык

Горячее

...

207

1/9/94

Томаты

240

100

"Полесье"

Киев

Украина

120

0.45

27/8/94

Шашлык

Горячее

...

207

1/9/94

Зелень

180

20

"Даугава"

Рига

Латвия

15

0.99

30/8/94

Кофе

Десерт

...

235

1/9/94

Кофе

2750

8

"Хуанхэ"

Пекин

Китай

40

2.87

24/8/94

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

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

2. Потенциальная противоречивость (аномалии обновления). Вследствие избыточности можно обновить адрес поставщика в одной строке, оставляя его неизменным в других. Если поставщик кофе сообщил о своем переезде в Харбин и была обновлена строка с продуктом кофе, то у поставщика "Хуанхэ" появляется два адреса, один из которых не актуален. Следовательно, при обновлениях необходимо просматривать всю таблицу для нахождения и изменения всех подходящих строк.

3. Аномалии включения. В БД не может быть записан новый поставщик ("Няринга", Вильнюс, Литва), если поставляемый им продукт (Огурцы) не используется ни в одном блюде. Можно, конечно, поместить неопределенные значения в столбцы Блюдо, Вид, Порций и Вес (г) для этого поставщика. Но если появится блюдо, в котором используется этот продукт, не забудем ли мы удалить строку с неопределенными значениями? По аналогичным причинам нельзя ввести и новый продукт (например, Баклажаны), который предлагает существующий поставщик (например, "Полесье"). А как ввести новое блюдо, если в нем используется новый продукт (Крабы)?

4. Аномалии удаления. Обратная проблема возникает при необходимости удаления всех продуктов, поставляемых данным поставщиком или всех блюд, использующих эти продукты. При таких удалениях будут утрачены сведения о таком поставщике.

Многие проблемы этого примера исчезнут, если выделить в отдельные таблицы сведения о блюдах, рецептах, расходе блюд, продуктах и их поставщиках, а также создать связующие таблицы "Состав" и "Поставки" (Рис 1.12).

Блюда Блюдо Вид Лобио Закуска Харчо Суп Шашлык Горячее Кофе Десерт ... ...	Рецепты Блюдо Рецепт Лобио Ломаную очищ ... ...	Расход Блюдо Порций Дата_Р Лобио 158 1/9/94 Харчо 144 1/9/94 Шашлык 207 1/9/94 Кофе 235 1/9/94 ... ... ...
Продукты Продукт Калор. Фасоль 3070 Лук 450 Масло 7420 Зелень 180 Мясо 1660 ... ...	Состав Блюдо Продукт Вес (г) Лобио Фасоль 200 Лобио Лук 40 Лобио Масло 30 Лобио Зелень 10 Харчо Мясо 80 ... ... ...	Поставщики Поставщик Город Страна "Полесье" Киев Украина "Наталка" Киев Украина "Хуанхэ" Пекин Китай "Лайма" Рига Латвия "Юрмала" Рига Латвия ... ... ...
Поставки Поставщик Город Продукт Вес (кг) Цена ($) Дата_П "Полесье" Киев Томаты 120 0.45 27/8/94 "Полесье" Киев Масло 50 1.62 27/8/94 "Полесье" Киев Лук 50 0.61 27/8/94 "Наталка" Киев Лук 100 0.52 27/8/94 ... ... ... ... ... ...

Рис. 1.12 Решение проблем включения, удаления данных путем разбиения отношения «Питание» на несколько связанных таблиц

Включение. Простым добавлением строк (Поставщики: "Няринга", Вильнюс, Литва) и (Поставки: "Няринга", Вильнюс, Огурцы,) можно ввести информацию о новом поставщике. Аналогично можно ввести данные о новом продукте (Продукты: Баклажаны, 240) и (Поставки: "Полесье", Киев, Баклажаны, 50, …).

Удаление. Удаление сведений о некоторых поставках или блюдах не приводит к потере сведений о поставщиках.

Обновление. В таблицах рис. 1.12 все еще много повторяющихся данных, находящихся в связующих таблицах (Состав и Поставки). Следовательно, в данном варианте БД сохранилась потенциальная противоречивость: для изменения названия поставщика с "Полесье" на "Днепро" придется изменять не только строку таблицы Поставщики, но и множество строк таблицы Поставки. При этом не исключено, что в БД будут одновременно храниться: "Полесье", "Палесье", "Днепро", "Днипро" и другие варианты названий. Кроме того, повторяющиеся текстовые данные (такие как название блюда "Рулет из телячьей грудинки с сосисками и гарниром из разноцветного пюре" или продукта "Колбаса московская сырокопченая") существенно увеличивают объем хранимых данных. Для исключения ссылок на длинные текстовые значения последние обычно нумеруют: нумеруют блюда в больших кулинарных книгах, товары (продукты) в каталогах и т.д. Воспользуемся этим приемом для исключения избыточного дублирования данных и появления ошибок при копировании длинных текстовых значений. (Рис. 1.13).

Блюда БЛ Блюдо Вид 1 Лобио Закуска 2 Харчо Суп 3 Шашлык Горячее 4 Кофе Десерт ... ... ...	Рецепты Блюдо Рецепт Лобио Ломаную очищ ... ...	Расход Блюдо Порций Дата_Р Лобио 158 1/9/94 Харчо 144 1/9/94 Шашлык 207 1/9/94 Кофе 235 1/9/94 ... ... ...
Продукты ПР Продукт Калор. 1 Фасоль 3070 2 Лук 450 3 Масло 7420 4 Зелень 180 5 Мясо 1660 ... ... ...	Состав БЛ ПР Вес (г) 1 1 200 1 2 40 1 3 30 1 4 10 2 5 80 ... ... ...	Поставщики ПОС Поставщик Город Страна 1 "Полесье" Киев Украина 2 "Наталка" Киев Украина 3 "Хуанхэ" Пекин Китай 4 "Лайма" Рига Латвия 5 "Юрмала" Рига Латвия ... ... ... ...
Поставки ПОС ПР Вес (кг) Цена ($) Дата_П 1 6 120 0.45 27/8/94 1 3 50 1.62 27/8/94 1 2 50 0.61 27/8/94 2 2 100 0.52 27/8/94 ... ... ... ... ...

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

Теперь при изменении названия поставщика "Полесье" на "Днепро" исправляется единственное значение в таблице Поставщики. И даже если оно вводится с ошибкой ("Днипро"), то это не может повлиять на связь между поставщиками и продуктами (в связующей таблице Поставки используются номера поставщиков и продуктов, а не их названия).

Нормальные формы

Таблица находится в первой нормальной форме (1НФ), если значения ее атрибутов атомарные (простые). Из приведенных в предыдущем вопросе таблиц, только первая не удовлетворяет этим требованиям. Таким образом, универсальное отношение «Питание» (Таблица 1.7) является отношением в первой нормальной форме.

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

Ко второй нормальной форме приведены почти все таблицы (Рис. 1.12), кроме таблицы Поставщики, в которой поле «Страна» зависит только от поля «Город», которое является частью первичного ключа (Поставщик: Город).

Последнее обстоятельство приводит к проблемам при:

- включении данных (пока не появится поставщик из Вильнюса, нельзя зафиксировать, что этот город Литвы),

- удалении данных (исключение поставщика может привести к потере информации о местонахождении города),

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

Что же касается таблиц Рис 1.13, то ввод в них отсутствующих в предметной области цифровых первичных и внешних ключей формально затрудняет процедуру выявления функциональных связей между этими ключами и остальными полями. Действительно, легко установить связь между атрибутом Блюдо и Вид (блюда): Харчо – Суп, Лобио – Закуска и т.п., но нет прямой зависимости между полями БЛ и Вид (блюда), если не помнить, что значение БЛ соответствует номеру блюда. Для упрощения нормализации подобных таблиц целесообразно использовать следующую рекомендацию:

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

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

После разделения таблицы Поставщики (Рис 1.12) на две части, все таблицы этого проекта удовлетворяют определению 2НФ, а так как в них нет неключевых полей, функционально зависящих друг от друга, то все они находятся в 3НФ.

Как ни странно, этого нельзя сказать об аналогичных таблицах Рис 1.13. Если забыть рекомендацию о подмене на время нормализации ключей БЛ, ПР и ПОС на Блюдо, Продукт и (Поставщик, Город), то среди этих таблиц появятся две, не удовлетворяющие определению 3НФ.

Действительно, так как после ввода первичных ключей БЛ и ПР поля Блюдо и Продукт стали неключевыми – появились несуществовавшие ранее функциональные зависимости между неключевыми полями:

Блюдо->Вид и Продукт->Калорийность.

Следовательно, для приведения таблиц Блюда и Продукты Рис. 1.13 к 3НФ их надо разбить на

Блюда: (БЛ, Блюдо),

Вид блюда: (БЛ, Вид);

Продукты: (ПР, Продукт);

Калорийность продукта (ПР,Калорийносить);

хотя интуиция подсказывает, что это лишнее разбиение, совсем не улучшающее проекта базы данных. Столкнувшись с подобными противоречиями, которые могут возникать не только из-за введения кодированных первичных ключей, теоретики реляционных систем Кодд и Бойс обосновали и предложили более строгое определение для 3НФ, которое учитывает, что в таблице может быть несколько возможных ключей.

Таблица находится в нормальной форме Бойса – Кодда (НФБК) только если любая функциональная зависимость между его полями сводится к полной функциональной зависимости от возможного ключа.

В соответствии с этой формулировкой таблицы Блюда и Продукты находятся в НФБК или 3НФ.

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

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

Например, естественным соединением таблиц, представленных на Рис. 1.12, 1.13 можно образовать исходную таблицу «Питание».

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

Четвертая нормальная форма (4НФ) является частным случаем 5НФ, когда полная декомпозиция должна быть соединением ровно двух проекций.

Процедура нормализации

На практике достаточно привести таблицы к НФБК.

Процедура приведения таблиц к этой форме основана на том, что единственными функциональными зависимостями в любой таблице должны быть зависимости вида K->F, где K – первичный ключ, а F – некоторое другое поле. Это следует из определения первичного ключа таблицы, в соответствии с которым K->F всегда имеет место для всех полей данной таблицы. Цель нормализации состоит именно в том, чтобы избавиться от других функциональных зависимостей, т.е. таких, которые имеют иной вид, чем K->F. Рассмотрим два случая:

1. Таблица имеет составной первичный ключ вида (К1, К2) и включает кроме прочих так же поле F, которое функционально зависит от части первичного ключа, например от К2, но не от полного ключа.

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

Заменить T: (К1, К2, F), первичный ключ (К1, К2), функциональная зависимость К2 -> F

на Т1: (К1, К2), первичный ключ (К1, К2) и Т2: (К2, F) первичный ключ К2.

2. Таблица имеет первичный ключ К; поле F1, которое не является ключом и функционально зависит от К, а так же другое неключевое поле F2, которое функционально зависит от К1.

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

Заменить Т: (К, F1,F2), первичный ключ К, функциональная зависимость F1->F2

на Т1:(К, F1), первичный ключ К и Т2: (F1, F2), первичный ключ F1.

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

Рассмотрим процедуру проектирования для универсального отношения «Питание» (Таблица 1.7).

Шаг 1. Определение первичного ключа таблицы.

Предположим, что каждое блюдо имеет уникальное название, относится к единственному виду и приготавливается по единственному рецепту, т.е. название блюда однозначно определяет его вид и рецепт. Предположим также, что название организации поставщика уникально для того города, в котором он расположен, и названия городов уникальны для каждой из стран, т.е. название поставщика и город однозначно определяют этого поставщика, а город – страну его нахождения. Наконец, предположим, что поставщик может осуществлять в один и тот же день только одну поставку каждого продукта, т.е. название продукта, название организации поставщика, город и дата поставки однозначно определяют вес и цену поставленного продукта. Тогда в качестве первичного ключа отношения "Питание" можно использовать следующий набор атрибутов:

Блюдо, Дата_Р, Продукт, Поставщик, Город, Дата_П.

Шаг 2. Выявление полей, функционально зависящих от части составного ключа.

Поле Вид функционально зависит только от поля Блюдо, т.е.

Блюдо->Вид.

Аналогичным образом можно получить зависимости:

Блюдо->Рецепт

(Блюдо, Дата_Р)->Порции

Продукт->Калорийность

(Блюдо, Продукт)->Вес

Город->Страна

(Поставщик, Город, Дата_П)->Цена

Шаг 3. Формирование новых таблиц.

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

Блюда (Блюдо, Вид)

Рецепты (Блюдо, Рецепт)

Расход (Блюдо, Дата_Р, Порции)

Продукты (Продукт, Калорийность)

Состав (Блюдо, Продукт, Вес (г))

Города (Город, Страна)

Поставки (Поставщик, Город, Дата_П, Вес (кг), Цена).

Шаг 4. Корректировка исходной таблицы.

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

Поставщики (Поставщик, Город),

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

Таким образом, процедура последовательной нормализации позволила получить проект, лучший, чем приведен на Рис. 1.12.

Процедура проектирования

Большинство современных подходов к проектированию баз данных основано на использовании семантических моделей «Сущность - связь» (Entity-Relationship ). Часто такую модель кратко называют ER – моделью. Она была предложена в 1976 году и базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. Основными понятиями ER-модели являются сущность, связь и атрибут.

С ущность - это реальный или представляемый объект, информация о котором должна сохраняться и быть доступна. В диаграммах ER-модели сущность представляется в виде прямоугольника, содержащего имя сущности. При этом имя сущности - это имя типа, а не некоторого конкретного экземпляра этого типа. Имя сущности может сопровождаться примерами конкретных объектов этого типа. Например, сущность «Аэропорт», с примерными объектами «Шереметьево» и «Хитроу» представлена на Рис 1.14:

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

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

Например, связь между сущностями БИЛЕТ и ПАССАЖИР (Рис 1.15) связывает билеты и пассажиров. При том конец сущности с именем "для" позволяет связывать с одним пассажиром более одного билета, причем каждый билет должен быть связан с каким-либо пассажиром. Конец сущности с именем "имеет" означает, что каждый билет может принадлежать только одному пассажиру, причем пассажир не обязан иметь хотя бы один билет.

Устная трактовка изображенной диаграммы такова:

Каждый БИЛЕТ предназначен для одного и только одного ПАССАЖИРА; Каждый ПАССАЖИР может иметь один или более БИЛЕТОВ.

Д ругой пример: рекурсивная связь, связывающая сущность ЧЕЛОВЕК с ней же самой (Рис. 1.16). Конец связи с именем "сын" определяет тот факт, что у одного отца может быть более чем один сын. Конец связи с именем "отец" означает, что не у каждого человека могут быть сыновья.

Устной трактовкой изображенной диаграммы является следующая: Каждый ЧЕЛОВЕК является сыном одного и только одного ЧЕЛОВЕКА; Каждый ЧЕЛОВЕК может являться отцом для одного или более ЛЮДЕЙ.

Атрибутом сущности является любая деталь, которая служит для уточнения, идентификации, классификации, числовой характеристики или выражения состояния сущности. Имена атрибутов заносятся в прямоугольник, изображающий сущность, под именем сущности и изображаются малыми буквами, возможно, с примерами. Пример: Уникальным идентификатором сущности является атрибут, комбинация атрибутов, комбинация связей или комбинация связей и атрибутов, уникально отличающая любой экземпляр сущности от других экземпляров сущности того же типа.

Получение реляционной схемы из ER – схемы

Шаг 1. Каждая простая сущность превращается в таблицу. Простая сущность - сущность, не являющаяся подтипом и не имеющая подтипов. Имя сущности становится именем таблицы.

Шаг 2. Каждый атрибут становится возможным столбцом с тем же именем; может выбираться более точный формат. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, - не могут.

Шаг 3. Компоненты уникального идентификатора сущности превращаются в первичный ключ таблицы. Если имеется несколько возможных уникальных идентификатора, выбирается наиболее используемый. Если в состав уникального идентификатора входят связи, к числу столбцов первичного ключа добавляется копия уникального идентификатора сущности, находящейся на дальнем конце связи (этот процесс может продолжаться рекурсивно). Для именования этих столбцов используются имена концов связей и/или имена сущностей.

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

Шаг 5. Индексы создаются для первичного ключа (уникальный индекс), внешних ключей и тех атрибутов, на которых предполагается в основном базировать запросы.

Шаг 6. Если в концептуальной схеме присутствовали подтипы, то возможны два способа:

- все подтипы в одной таблице (а)

- для каждого подтипа - отдельная таблица (б).

При применении способа (а) таблица создается для наиболее внешнего супертипа, а для подтипов могут создаваться представления. В таблицу добавляется по крайней мере один столбец, содержащий код ТИПА; он становится частью первичного ключа. При использовании метода (б) для каждого подтипа первого уровня (для более нижних - представления) супертип воссоздается с помощью представления UNION (из всех таблиц подтипов выбираются общие столбцы - столбцы супертипа) – Таблица 1.8:

Таблица 1.8 Особенности расположения подтипов в одной или в нескольких таблицах

Все в одной таблице	Таблица - на подтип
Преимущества
Все хранится вместе; Легкий доступ к супертипу и подтипам; Требуется меньше таблиц.	Более ясны правила подтипов; Программы работают только с нужными таблицами.
Недостатки
Слишком общее решение; Требуется дополнительная логика работы с разными наборами столбцов и разными ограничениями; Потенциальное узкое место (в связи с блокировками); Столбцы подтипов должны быть необязательными; В некоторых СУБД для хранения неопределенных значений требуется дополнительная память.	Слишком много таблиц; Смущающие столбцы в представлении UNION; Потенциальная потеря производительности при работе через UNION; Над супертипом невозможны модификации .

Шаг 7. Имеется два способа работы при наличии исключающих связей (Таблица 1.9):

- общий домен (а)

- явные внешние ключи (б)

Таблица 1.9 Способы работы при наличии исключающих связей

Общий домен	Явные внешние ключи
Преимущества
Нужно только два столбца	Условия соединения - явные
Недостатки
Оба дополнительных атрибута должны использоваться в соединениях	Слишком много столбцов