Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
2 ПРОЕКТИРВАНЕ ПРОГРАММНОГО ПРОДУКТА (мой)++.doc
Скачиваний:
6
Добавлен:
26.11.2019
Размер:
2.14 Mб
Скачать

2.3.3 Нормализация данных

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

Первая нормальная форма требует, чтобы все значения полей были атомарными и все записи уникальными:

– в каждой строке таблицы должны содержаться данные, соответст­вующие некоторому объекту или его части;

– в каждом столбце должны находиться данные, соответствующие од­ному из атрибутов отношений;

– в каждой ячейке таблицы должно находиться только единственное значение;

– у каждого столбца должно быть уникальное имя;

– все строки (записи) в таблице должны быть различными;

– порядок расположения столбцов и строк в таблице не имеет значе­ния.

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

Модель находится во второй нормальной форме, если она:

– во-первых, находится в первой нормальной форме;

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

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

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

Так как в отношениях нет транзитивных зависимостей, и отсутствует избыточность данных, то можно сказать, что они находятся в третьей нормальной форме.

2.3.4 Физическое проектирование базы данных

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

– объекты становятся таблицами в физической базе данных;

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

– уникальные идентификаторы становятся колонками, не допускающими значение «NULL». В физической базе данных они называются первичными ключами («primary keys»);

– отношения моделируются в виде внешних ключей («foreign keys»).

Главными вопросами физического проектирования являются: оптимизация времени выполнения основных запросов к базе данных и обеспечение безопасности данных.

Для повышения производительности реляционные системы управления базами данных (СУБД) используют специальные объекты, называемые индексами.

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

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

Результат проведенного проектирования базы данных для данного дипломного проекта можно представить в виде полного описания свойств полей для всех таблиц (рисунки 2.2 – 2.8).

Рисунок 2.2 – Сведения, относящиеся к таблице «Ответы к тестам»

Рисунок 2.3 – Сведения, относящиеся к таблице «Лекции»

Рисунок 2.4 – Сведения, относящиеся к таблице «Проектирование»

Рисунок 2.5 – Сведения, относящиеся к таблице «Вопросы к тестам»

Рисунок 2.6 – Сведения, относящиеся к таблице «Результаты тестов»

Рисунок 2.7 – Сведения, относящиеся к таблице «Пользователи»

Рисунок 2.8 – Сведения, относящиеся к таблице «Пользователи»