Реляционная модель данных.

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

Таблица 1.1. Отношение Студент.

ФИО	Дата_рождения	Курс	Специальность
Иванов И.И.	01.09.83	3	История
Петров П.П.	09.12.84	2	Физика
Сидоров С.С.	07.10.85	1	История
Соловьев С.С.	07.10.85	1	Биология

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

Реляционная БД – это набор взаимосвязанных таблиц, содержащих всю необходимую для решения задачи информацию.

Однако таблицы реляционной БД – это не любые таблицы. На них накладываются определенные ограничения. Одним из главных ограничений является запрет на присутствие в таблице двух одинаковых строк, а точнее - строк, имеющих одинаковые первичные ключи.

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

Первичный ключ, однако, не должен иметь лишних атрибутов. Попытаемся определить, какой атрибут или совокупность атрибутов являются первичным ключом отношения Студент. Нетрудно заметить, что ни один из атрибутов этого отношения и даже все они, вместе взятые, не являются однозначным идентификатором конкретного студента. Разные студенты могут иметь одинаковые фамилии и инициалы, они могут родиться в один день и, тем более, обучаться на одном и том же курсе по одной специальности. Если добавить в отношение атрибут Домашний_Адрес, то это в какой-то степени решит проблему. Совокупность атрибутов ФИО и Домашний_Адрес будет являться первичным ключом, если, конечно, речь не идет о близнецах, которые имеют не только одинаковые фамилии, но и инициалы, учатся вместе и вместе живут. Если же добавить в отношение Студент атрибут №Зачетки, то он без всяких оговорок будет однозначно определять каждого студента. Таким образом, первичным ключом отношения Студент может быть атрибут №Зачетки или совокупность атрибутов ФИО и, если пренебречь случаем с близнецами. Если отношение имеет несколько потенциальных первичных ключей, то выбирают тот из них, который короче. В нашем случае первичным ключом будет №Зачетки, другие потенциальные ключи называются возможными ключами или ключами – кандидатами. Отношение Студент после добавления в него атрибута №Зачетки примет вид:

Таблица 1.2. Отношение Студент после добавления атрибута №Зачетки

№Зачетки	ФИО	Дата_рождения	Курс	Специальность
13/3-5	Иванов И.И.	01.09.83	3	история
14/1-2	Петров П.П.	09.12.84	2	физика
15/2-2	Сидоров С.С.	07.10.85	1	история
15/2-1	Соловьев С.С.	07.10.85	1	биология

Отношения реляционной базы данных делятся на два типа: объектные и связные.

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

Связное отношение содержит атрибуты, характеризующие связь между объектами. Оно обязательно содержит первичные ключи участвующих в связи объектных отношений, а также атрибуты, которые функционально зависят от этой связи. Связное отношение не обязательно содержит первичный ключ. Оно служит для того, чтобы можно было, выбрав информацию из одного отношения, использовать ее для поиска соответствующей информации в другом отношении. Примером связного отношения может служить отношение Сдал, если кроме отношения Студент в предметной области есть еще и отношение Предмет с атрибутами Название и Количество_Часов, первый из которых является первичным ключом. Отношение Сдал в этом случае имеет атрибуты №Зачетки, Название, Оценка и, может быть, Дата_Сдачи. Два последних атрибута в равной мере характеризуют как студента, так и предмет, который он сдает. Это оценка, полученная определенным студентом по определенному предмету, и дата ее получения. В этом отношении совокупность атрибутов №Зачетки, Название является первичным ключом отношения Сдал, если повторная сдача студентом одного и того же предмета не допускается. В противном случае в первичный ключ должен быть добавлен еще и атрибут Дата_Сдачи. Атрибут Название является первичным ключом отношения Предмет, а атрибут №Зачетки - первичным ключом отношения Студент.

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

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

Таблица 1.3. Отношение Предмет

Название	Количество_Часов
физика	50
информатика	40
история	30
математика	40
иностранный язык	40

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

15/2-1

химия

4

27.01.03

является недопустимой для таблицы Сдал, поскольку в таблице Предмет нет химии. Недопустимой является также строка

12/2-1

физика

4

17.01.03

, поскольку в таблице Студент нет сведений о студенте с номером зачетки 12/2-1.

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

Таблица 1.4. Таблица Сдал, не являющаяся отношением.

№Зачетки	Название	Оценка	Дата_Сдачи
15/2-1	физика, информатика, история	5, 4, 3	02.01.03, 07.01.03, 15.01.03
15/2-2	физика, информатика, история	4, 4, 4	02.01.03, 07.01.03, 15.01.03
13/3-5	физика, информатика, история	4, 3, 5	03.01.03, 08.01.03, 17.01.03

Необходимо преобразовать его к виду:

Таблица 1.5. Отношение Сдал.

№Зачетки	Название	Оценка	Дата_Сдачи
15/2-1	Физика	5	02.01.03
15/2-1	Информатика	4	07.01.03
15/2-1	История	3	15.01.03
15/2-2	Физика	4	02.01.03
15/2-2	Информатика	4	07.01.03
15/2-2	История	4	15.01.03
13/3-5	Физика	4	03.01.03
13/3-5	Информатика	3	08.01.03
13/3-5	История	5	17.01.03

Подведем итоги. Итак, реляционная модель накладывает на таблицы следующие ограничения:

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

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

3. Значения каждого атрибута должны быть взяты из некоторого фиксированного множества значений.

4. Значения атрибутов должны быть атомарными.

5. В целях непротиворечивости базы данных должна соблюдаться ссылочная целостность для внешних ключей.

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

Большинство СУБД реляционного типа, но не все, осуществляют контроль ссылочной целостности данных. Контроль данных на непротиворечивость осуществляется СУБД автоматически в следующих случаях:

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

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

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

Например, в таблицу Сдал нельзя добавить строку

15/2-1

химия

4

27.01.03

или строку

12/2-1

физика

4

17.01.03

, поскольку в первом случае в таблице Предмет ни одна из строк не имеет в качестве значения поля Названия «химия», а во втором случае в таблице Студент нет строки со значением номера зачетки 12/2-1. Удаление первой строки из таблицы Предмет должно быть либо запрещено, либо одновременно с ее удалением следует удалить 1, 4 и 7 строки таблицы Сдал. То же и для удаления сведений о каком - нибудь студенте из таблицы Студент, например, о первом по фамилии Иванов с номером зачетки 13/3-5. Поскольку в таблице Сдал содержатся сведения о том, что этот студент сдал 3 экзамена по физике , информатике и истории, то следует выполнить каскадное удаление, в результате которого вместе с первой строкой таблицы Студент будут удалены и 3 последних строки таблицы Сдал. Примером использования каскадной модификации значений полей связи может служить изменение номера зачетки студента Иванова с 13/3-5 на 23/3-15. В таблице Сдал будут автоматически изменены значения поля №Зачетки в трех последних строках. Изменение названия какого –либо предмета, например «информатика» на «информационные технологии»в Таблице Предмет повлечет за собой соответствующую замену значения поля Название в строках 2, 5, 8 таблицы Сдал.

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

После того, как решение о составе таблиц принято, средствами выбранной СУБД описывается структура каждой из них, то есть определяется, какие атрибуты составляют каждую из таблиц. При описании атрибутов необходимо указать их имя, тип и размер. Затем устанавливаются связи между таблицами и таблицы заполняются данными.

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

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

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

Знакомству со средствами СУБД Access, предназначенными для создания базы данных и обеспечения удобного доступа к хранящимся в ней данным посвящены приведенные ниже лабораторные работы.

1. Создание и модификация структуры таблицы. Типы и свойства полей.

2. Упорядочение записей файла БД. Типы индексов. Простые и сложные индексные файлы. Создание первичного ключа и других индексов. Главный индекс.

3. Понятие ссылочной целостности.

4. Определение постоянных и временных связей между таблицами.

5. Работа с данными в режиме таблицы. Ввод, корректировка и удаление данных.

6. Импорт и экспорт данных.

7. Диалект SQL, реализованный в СУБД Visual FoxPro.

8. Создание представлений, их отличие от запросов.