- •2 Проектирване программного продукта
- •2.1 Формирование структуры проекта
- •2.2 Выбор инструментальных средств разработки
- •2.3 Алгоритмическое обеспечение проекта
- •2.3.1 Концептуальное моделирование предметной области
- •2.3.2 Проектирование и оптимизация логической модели
- •2.3.3 Нормализация данных
- •2.3.4 Физическое проектирование базы данных
- •2.3.5 Проектирование модулей
- •2.4 Реализация и тестирование программного обеспечения
- •2.4.1 Реализация программного обеспечения
- •2.4.2 Тестирование программного обеспечения
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 – Сведения, относящиеся к таблице «Пользователи»