Файл: З. Н. Трубачев.docx

2.4.1 Инфологическое проектирование базы данных

Инфологическое проектирование является первоочередным этапом проектирования БД. На первом этапе проектирования БД определяется предметная область рассматриваемой системы, и формируется взгляд на БД со стороны будущего пользователя. Также на этом этапе строится семантическая модель рассматриваемой области с наиболее высоким уровнем абстракции.

К особенностям создания такой модели можно отнести отсутствие привязки к конкретной модели данных или СУБД. В большинстве случаев для проектирования БД используется графический способ с использованием модели «сущность-связь» посредством создания ER-диаграммы.

Рисунок 2.5 - ER-диаграмма сематической модели БД

Так как база данных создается для обслуживания сотрудников салона. Она должна содержать информацию о сотрудниках, автомобилях, клиентах, и завершенных сделках. Исходя из этих задач была построена ER-диаграмма, представленная на рисунке 2.5.

На втором этапе осуществляется проектирование БД, суть которого заключается в создании схемы данных на основании ранее построенной ER-диаграммы с последующим выбором модели данных [6].

2.4.2 Даталогическое проектирование базы данных

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

Таблица 2.1 – Выделенные сущности системы

Название сущности	Описание класса
Сотрудник	таблица хранящие данные о сотрудниках
Клиенты	таблица хранящие данные о клиентах салона
Покупка	таблица хранящая данные о завершённые сделках по покупке авто
Заказ	таблица, хранящая данные о заказ авто у поставщиков
Тест-драйв	таблица, хранящая данные о результатах тест драйва авто
Авто	таблица, хранящая данные о автомобилях салона
Поставщик	таблица содержащие сведения о поставщиках автомобилей

---

Определение необходимых атрибутов, а также выделение связей для данных сущностей представлено в ER-диаграмме схемы данных на рисунке 2.6. В ходе проектирования и разработки, в зависимости от задач количество сущностей и их атрибутов может уменьшаться или увеличиваться. Так в таблице 2.1, количество выделенных сущностей было 7, а в ходе построения ER-диаграмме схемы данных БД, у чет требований нормализации и соблюдением правил проектирований и разработки БД, количество сущностей увеличилось до 17. В ходе проектирование БД, были добавлены сущности для Авторизации, и отслеживания авторизации сотрудников фирмы, также отдельные атрибуты выделенных сущностей в таблице 2.1, были вынесены в отдельные справочники [6].


Рисунок 2.6 - ER-диаграмма схема данных

Использование специализированного ПО позволяет сделать процесс проектирования БД комфортным и приятным. Так при использовании, draw.oi для построения UML диаграмм в частности ER-диаграмма и использование встроенных шаблонов, позволяет прописать первичные и внешние ключи.


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

Нормализация – это процесс преобразования БД к виду, соответствующе требованиям нормальных форм.

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

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

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

В случаях, когда после процесса нормализации БД, превращается в «табличного гиганта» существует обратный процесс – денормализацияя, намеренное приведение БД в состояние противоречащие условиям нормализации. На практике это способствую ускорению процесса чтения из БД за счет добавление избыточных данных. Так что, процесс нормализации требует тонкой чуйки от специалиста, который проводит нормализацию.

---

Приведем понятия и определения о трех типах НФ:

Первая нормальная форма – кортеж каждого атрибут БД, содержит только одно значения, тогда говорят, что отношение находится в первой нормальной форме.

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

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

Подход к нормализации БД с учетом первых трех форм нормализации, в ходе их проектирование, позволяет избежать в дальнейшей работе затраты времени, но нормализацию БД. Так базы данных используемых в разрабатываемой информационной системе соответствуют первым трём нормальным формам нормализации, а требования к детальной нормализации отсутствуют [6].

---

3. Проектирование и разработка БД

При выборе системы управления базами данных были рассмотрены существующие и наиболее распространенные реляционные на СУБД рынке: Oracle Database, PostgreSQL, Microsoft SQL, MySQL.

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

Проведя анализ и рассмотрев преимущества распространенных СУБД, для разработки автоматизированной системы была выбрана система управления базами данных Microsoft SQL,так как она имеет ряд преимуществ по сравнению с остальными:

• 
  хорошая поддержка работы с другими решениями Microsoft;
  
• 
  на начальных этапах разработки бесплатная лицензия перекрывает весь спектр задач без ограничений, а в случае расширения объёма работы приобретение лицензии позволит без проблем расширить базу данных;
  
• 
  высокая производительность;
  
• 
  высокая надёжность СУБД.
  

3.1 Описание групп пользователей и прав доступа

Завершающим этапом перед физическим проектированием БД является описание групп пользователей и их права доступа к каждой таблице. Стоит заметить, что для каждого объекта БД должен быть хотя бы один пользователь, который имеет право добавлять и удалять данные из объектов [7].

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

S – Чтение данных (select);

I – Добавление данных (insert);

U – Модификация данных (update);

D – Удаление данных (delete).

Таблица 3.1 - Группы пользователей и прав доступа

---

Таблицы	Группы пользователей
	Инженер-программист	Директор и его заместитель	Начальники отделов	Главный бухгалтер	Остальные сотрудники
Авто	SIUD	SIUD	SIU	S	S
Марка	SIUD	SIUD	SIU	S	S
Модель	SIUD	SIUD	SIU	S	S
Цвет	SIUD	SIUD	SIU	S	S
Склад	SIUD	SIUD	SIU	S	S
Статус заказа	SIUD	SIUD	SIU	S	S
Заказ	SIUD	SIUD	SIU	SIU	SI
Тест-драйв	SIUD	SIUD	SIU	S	SI
Поставщик	SIUD	SIUD	SIU	SI	SI
Покупка	SIUD	SIUD	SIU	SIU	S
Сотрудники	SIUD	SIUD	SIU	S	S
Клиент	SIUD	SIUD	SIU	S	SI
Должность	SIUD	SIUD	SI	S	S
Авторизация	SIUD	SIUD	-	-	-
Логи авторизации	SIUD	SIUD	-	-	-
Пол	SIUD	SIUD	-	-	-

---