2.5. Приведение модели к требуемому уровню нормальной формы

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

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

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

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

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

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

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

2.6. Описание физической модели

	Наименование поля	Тип данных	Размер	Примечание
Информация о читателе
	Номер билета	Счетчик
	Фамилия	Текстовый	60
	Имя	Текстовый	60
	Отчество	Текстовый	60
	Телефон	Текстовый	20
	Адрес	Текстовый	60
Информация о книге
1	Шифр книги	Счетчик
2	Название	Текстовый	60
3	Код издательства	Числовой	Длинное целое	Ссылка на код издательства
4	Год издания	Текстовый	10
5	Объем книги	Числовой	Длинное целое
6	Цена	Денежный
7	Количество	Числовой	Длинное целое
8	Код раздела	Числовой	Длинное целое	Ссылка на код раздела
Выдача книг
1	Код выдачи	Счетчик
2	Шифр книги	Числовой	Длинное целое
3	Код читательского билета	Числовой	Длинное целое	Ссылка на код читательского билета
4	Дата выдачи книги	Дата/время	Краткий формат даты
5	Дата возврата книги	Дата/время	Краткий формат даты
Бронирование книг
1	Код брони	Счетчик
2	Шифр книги	Числовой	Длинное целое	Ссылка на библиотечный шифр книги
3	Код читательского билета	Числовой	Длинное целое	Ссылка на код читательского билета
4	Дата заказа	Дата/время	Краткий формат даты
Издательства
1	Код издательства	Счетчик		Код издательства
2	Наименование	Текстовый	60	Наименование издательства
3	Код города	Числовой	Длинное целое	Ссылка на город издательства
Авторы
1	Код автора	Счетчик
2	Фамилия	Текстовый	60
3	Имя	Текстовый	60
4	Отчество	Текстовый	60
Авторы книг
1	Код записи	Счетчик		Код записи
2	Шифр книги	Числовой	Длинное целое	Ссылка на шифр книги
3	Код автора	Числовой	Длинное целое	Ссылка на код автора
Города
1	Код города	Счетчик
2	Наименование	Текстовый	60
Разделы библиотеки
1	Код раздела	Счетчик
2	Научная литература	Логический		Да или нет
3	Журнальные публикации	Логический		Да или нет
Задолжники
1	Код задолжника	Счетчик
2	Фамилия	Числовой		Ссылка на фамилию
3	Имя	Числовой		Ссылка на имя
4	Отчество	Числовой		Ссылка на отчество
5	Дата выдачи	Числовой		Ссылка на дату выдачи

Расставим связи между таблицами (рисунок 5).

Рисунок 26– Схема данных

Все таблицы связаны между собой связью типа "Один-ко-многим". На примере таблиц "Издательства" и "Города" это означает, что одно издательство может иметь только один город, но в таблице "Издательства" может присутствовать множество записей таблицы "Города". Т.е. разные издательства могут иметь одинаковые названия городов.

Отчет по схеме:

Рисунок 27 – Схема данных

Аналогично связаны между собой остальные таблицы.

Основные характеристики используемой СУБД

В результаты мы получили СУБД, обладающую рядом характеристик.

Разработанная СУБД позволяет выполнять простейшие операции с данными:

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

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

- обновлять значения некоторых полей в одной или нескольких записях;

- находить одну или несколько записей, удовлетворяющих заданному условию.

Разработанная СУБД организует хранение информации таким образом, чтобы ее было удобно:

- просматривать;

- пополнять;

- изменять;

- искать нужные сведения,

- делать любые выборки.