3. Физический дизайн системы

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

3.1 Уровень представления

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

При реализации графической части уровня представлений, использовались языки программирования: PHP, MySQL.

3.2 Уровень данных

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

• действия (например, фиксация или откат транзакций в СУБД), направленные на обеспечение целостности хранимых данных;

• операции чтения и записи данных для СУБД и других компонент.

3.2.1 Нормализация

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

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

Ниже приведен пример нормализации таблицы monitor:

Таблица 3 - Начальная структура таблицы monitor.

ID	ФИО
1	Тушков Константин Юрьевич
2	Моторин Сергей Викторович

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

Таблица 4 – Нормализованная таблица monitor.

ID	Фамилия	Имя	Отчество
1	Тушков	Константин	Юрьевич
2	Моторин	Сергей	Викторович

Теперь таблица monitor находится в первой нормальной форме.

3.2.2. ER-диаграмма

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

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

ER-модель является одной из самых простых визуальных моделей данных (графических нотаций).

Существует два уровня представления модели - логический и физический.

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

Физическая модель данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация о всех объектах БД. Поскольку стандартов на объекты БД не существует, физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах и т. д.

Рисунок 3 - Логическая ER-диаграмма

3.2.3 Выбор системы хранения

Основными критериями при выборе системы хранения служат:

1. Поддержка транзакций и высокая производительность

2. Наличие документации и справочной информации

3. Дистрибутив под ОС «Windows XP»

Из известных на сегодняшний момент СУБД, наиболее популярными являются: MySQL, PostgreSQL. В данном курсовом проекте используются MySQL, предоставляемый свободным дистрибутивом XAMPP.

Рисунок 4 - Физическая ER-диаграмма