2. Целостность данных

Целостность данных означает систему правил, используемых в СУБД Accessдля поддер­жания связей между записями в связанных таблицах (таблиц, объединенных с помощью связи), а также обеспечивает защиту от случайного удаления или изменения связанных данных. Контролировать целостность данных можно, если выполнены следующие условия:

• связанное поле (поле, посредством которого осуществляется связь) одной таблицы яв­ляется ключевым полем или имеет уникальный индекс;

• связанные поля имеют один тип данных. Здесь существует исключение. Поле счетчи­ка может быть связано с числовым полем, если оно имеет тип Длинное целое;

• обе таблицы принадлежат одной базе данных Access. Если таблицы являются связан­ными, то они должны быть таблицамиAccess. Для установки целостности данных БД, в которой находятся таблицы, должна быть открыта. Для связанных таблиц из БД других форматов установить целостность данных невозможно.

2. Проектирование реляционной базы данных с использованием нормализации

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

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

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

Вторая нормальная форма (2НФ). Отношение R находится во второй нормальной форме в том и только в том случае, когда находится в 1НФ и каждый неключевой атрибут полностью зависит от первичного ключа.

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

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

2. Создание информационно-логической и логической моделей базы данных

Цель работы: разработать информационно-логическую модель реляционной БДДеканат; разработать логическую модель реляционной БДДеканат.

Выполнение и рекомендации:

1. Перед разработкой информационно-логической модели реляционной БД рассмотрим, из каких информационных объектов должна состоять эта БД. Можно выделить три объекта, которые не будут обладать избыточностью, — Студен­ты, Дисциплины и Преподаватели.

2. Представим состав реквизитов этих объектов в виде «название объекта (перечень реквизитов)»: Студенты (код студента, фамилия, имя, отчество, номер группы, дата рождения, стипендия, оценка), Дисциплины(код дисциплины, название дисциплины), Преподаватели (код преподавателя, фамилия, имя, отчество, дата рождения, телефон, заработная плата).

3. Рассмотрим связь между объектами СтудентыиДисциплины.Студент изучает несколько дисциплин, что соответствует многозначной связи и отражено на рис. 4.1 двойной стрелкой. Понятно, что каждая дисциплина изучается множеством студен­тов. Это тоже многозначная связь, обозначаемая двойной стрелкой (связь «один» обозначена одинарной стрелкой). Таким образом, связь между объектами СтудентыиДисциплины — Многие-ко-многим (М : N).

Студенты

Дисциплины

Преподаватели

Рис. 4.1. Типы связей между объектами Студенты, Дисциплины и Преподаватели

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

Студенты

Дисциплины

Преподаватели

Оценки

Рис. 4.2. Информационно-логическая модель реляционной базы данных

4. В реляционной БД в качестве объектов рассматриваются отношения, кото­рые можно представить в виде таблиц. Таблицы между собой связываются посред­ством общих полей, т.е. одинаковых по форматам и, как правило, по названию, имеющихся в обеих таблицах. Рассмотрим, какие общие поля надо ввести в таблицы для обеспечения связности данных. В таблицах Студенты и Оценки таким полем будет «Код студента», в таблицах Дисциплины и Оценки — «Код дисциплины», в таблицах Преподаватели и Дисциплины — «Код дисциплины». Выбор цифровых кодов вместо фамилий или названий дисциплин обусловлен меньшим объемом ин­формации в таких полях: например, число «2» по количеству символов значительно меньше слова «математика». В соответствии с этим логическая модель БД представлена на рис. 4.3, где жирными буквами выделены ключевые поля.

Студенты Оценки Дисциплины Преподаватели

Код студента	1:M	Код студента	1:M	Код дисциплины	1:M	Код дисциплины
Фамилия		Код дисциплины		Название дисциплины		Код преподавателя
Имя						Фамилия
		Оценки				Имя
Отчество						Отчество
Номер группы						Преподаваемая дисциплина
Дата рождения						Телефон
Стипендия

Рис. 4.3. Логическая модель базы данных