VII Международная студенческая научная конференция Студенческий научный форум - 2015

В статье кратко описывается этап проектирования базы данных для информационной системы, разрабатываемой в качестве дипломного проекта (Разработка информационной системы для автошколы ООО «Зебра» научн. рук. проф. Воронова Л.И.).

Автошкола ООО «Зебра» с каждым годом расширяется и открывает новые филиалы

в городах центрального региона. Объемы информации растут, и ее требуется систематизировать.

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

Целью работы является разработка базы данных для автоматизации работы Автошколы ООО «Зебра».

1. Разработка инфологической модели предметной области

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

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

Для информационной системы Автошколы «Зебра» на основе проведенного системного анализа предметной области выделены следующие сущности:

• лектор – сущность содержит информацию о лекторах;

• инструктор – сущность содержит информацию об инструкторах;

• автомобиль – сущность содержит информацию об автомобилях;

• студент – сущность содержит информацию о студентах;

• группа – сущность содержит информацию о составе групп и результатах экзаменов;

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

Рис.1 Инфологическая модель предметной области Автошколы ООО «Зебра»

2. Обоснование выбора модели данных

Даталогическая модель строится на основе инфологической модели. [1]

Существуют несколько типов даталогических моделей данных:

• сетевая модель;

• иерархическая модель;

• объектно-ориентированная модель;

• реляционная модель;

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

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

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

3. Алгоритм преобразования инфологическую модели в даталогическую

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

Основой анализа корректности схемы являются функциональные зависимости между атрибутами БД. Некоторые могут быть нежелательными.

Целью даталогического проектирования является построение корректной схемы БД, ориентированную на реляционную модель.

Корректной называется схема БД, в которой отсутствуют нежелательные зависимости между атрибутами отношений.

Процесс разработки корректной схемы РБД и является даталогическим проектированием. Возможны 2-а способа:

• Декомпозиция (разбиение);

• Синтез;

Для перехода от инфологической модели к реляционной существует специальный алгоритм:

1. каждой сущности ставится в соответствие отношение;

2. каждому атрибуту сущности ставится в соответствие соответствующий атрибут соответствующего отношения;

3. первичный ключ сущности становится PK соответствующего отношения, при этом атрибуты, входящие в PK, обязательны для заполнения (NOT NULL);

4. в каждое отношение, соответствующее подчинённой сущности, добавляется набор атрибутов основной сущности, являющийся в ней первичным ключом. В отношении, соответствующее подчинённой сущности эти атрибуты становятся FK (внешним ключом);

5. по умолчанию, все атрибуты, не входящие в PK, необязательны;

6. для отражения категоризации сущностей возможны несколько вариантов;

7. все связи М:М должны быть раскрыты;

Далее требуется привести отношения к нормальной форме.

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

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

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

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

Отношение находится во второй нормальной форме (2NF), если она находится в первой нормальной форме, и при этом любой её атрибут, не входящий в состав первичного ключа, функционально полно зависит от первичного ключа. Функционально полная зависимость означает, что атрибут функционально зависит от всего первичного составного ключа, но при этом не находится в функциональной зависимости от какой-либо из входящих в него атрибутов (частей). Или другими словами: в 2NF нет неключевых атрибутов, зависящих от части составного ключа.

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

Отношение находится в третьей нормальной форме (3NF), если она находится во второй нормальной форме 2NF и при этом любой ее неключевой атрибут зависит только от первичного ключа (Primary key, PK). Таким образом, отношение находится в 3NF тогда и только тогда, когда оно находится во 2NF и отсутствуют транзитивные зависимости неключевых атрибутов от ключевых.

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

Воспользуемся алгоритмом и опишем каждое отношение даталогической модели:

Лектор:

• ФИО лектора varchar NOT NULL PK

• дата рождения date

• адрес varchar

• телефон int

Инструктор:

• ФИО инструктора varchar NOT NULL PK

• дата рождения date

• адрес varchar

• телефон int

• данные о медосмотре varchar

Автомобиль:

• номер автомобиля int NOT NULL PK

• марка и модель автомобиля varchar

• ФИО инструктора varchar FK

• данные о техосмотре varchar

Студент:

• ФИО студента varchar NOT NULL PK

• дата рождения date

• адрес varchar

• телефон int

• номер группы varchar FK

• оплата varchar

Группа:

• номер группы varchar NOT NULL PK

• ФИО студента varchar FK

• внутренний теория varchar

• внутренний автодром varchar

• внутренний город varchar

• стоимость int

При переходе от инфологической модели к реляционной раскрыта связь М:М между отношениями «Лектор» - «Группа» и «Инструктор» - «Студент». Отношением-связкой в данном случае стали отношения «Расписание лекций» и «Расписание практик».

Расписание лекций :

• ФИО лектора varchar FK

• номер группы varchar FK

• дата date

• время int

Расписание практик :

• ФИО инструктора varchar FK

• ФИО студента varchar FK

• дата date

• время int

Рис.2 Даталогическая модель Автошколы ООО «Зебра» до нормализации

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

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

Все отношения не находятся в 1НФ из-за составного атрибута ФИО, но мы не будем его разбивать для удобства, поэтому можно сказать, что все отношения приведены к 1НФ.

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

Все отношения находятся в 2НФ кроме Группа , так как атрибуты Внутренний теория , Внутренний автодром , Внутренний город не зависят от ключа Номер группы. В связи с этим отношение группы распадается на два отношения: Группа и Экзамены.

Группа:

• номер группы varchar NOT NULL PK

• количество студентов int

Экзамены:

• ФИО студента varchar NOT NULL FK

• внутренний теория varchar

• внутренний автодром varchar

• внутренний город varchar

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

Все отношения модели находятся в 3НФ, т.к. ни в одном из них нет транзитивных зависимостей.

Рис.3 Даталогическая модель Автошколы ООО «Зебра» после нормализации

Выводы

В статье приведена разработка информационно-логической модели автошколы

ООО «Зебра». Выделены сущности, дано их описание и построена инфологическая модель предметной области.

Далее в ходе обоснования выбора модели данных представлены существующие модели данных (иерархическая, сетевая, реляционная, объектно-ориентированная), и сделан выбор в пользу реляционной модели.

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

Таким образом, завершено проектирование базы данных, необходимой для реализации проектируемой информационной системы в одной из реляционных СУБД.

Список источников литературы

[1] Т.С. Карпова «Базы данных: модели, разработка, реализация»

[2] П. Роб и К. Коронел «Системы баз данных: проектирование, реализация и управление»

[3] Л.И.Воронова Базы данных // Учебно-методическое пособие по подготовке и оформлению курсовых проектов. М.: МТУСИ, 2014. -28 с.

Код для цитирования: Скопировать