Разработка и проектирование БД ИС на предприятии ГП "АЛУШТАЛИФТ"

3. Разработка и проектирование БД ИС на предприятии ГП "АЛУШТАЛИФТ"

3.1 Проектирование БД ИС "Вызов"

Проектирование баз данных – процесс решения класса задач, связанных с созданием баз данных.

При выполнении данного процесса решаются следующие основные задачи:

-     обеспечение хранения в БД всей необходимой информации;

-     обеспечение возможности получения данных по всем необходимым запросам;

-     сокращение избыточности и дублирования данных;

-     обеспечение целостности данных (правильности их содержания): исключение противоречий в содержании данных, исключение их потери и т.д.

В процессе написания был использован язык SQL, так как базовым требованием к реляционным СУБД является наличие мощного и в тоже время простого языка, позволяющего выполнять все необходимые пользователям операции. В последние годы таким повсеместно принятым языком стал язык реляционных БД SQL - Structured Query Language.

На основе описания предметной области во втором разделе и ER метода проектирования баз данных, описанной в первом разделе, разработаем модель базы данных проектируемой ИС.

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

Для каждой заявки будет заводиться отдельная строка в таблице базы данных, в которой указываются:

-           Номер вызова;

-           Дата вызова;

-           № лифта;

-           Вид работы;

-           Лифтер.

При занесении данных о новой заявке, необходимо заполнить форму "Вызов", в открывающемся окне будет расположено несколько полей для заполнения:

-                 "Выбор лифтера", где будет отображаться список лифтеров и их допуск к работе с возможностью добавления нового лифтера;

-                 "Вид ремонта", где будет показано его описание, какова цена и нужный допуск работника;

-                 "Выбор лифта", где будет список из лифтов с указанием точного адреса и номера подъезда;

-                 "Календарь", где надо будет выбрать дату получения заявки;

Данные в таблице можно редактировать по мере необходимости. Их можно будет сортировать по дате, сотруднику, городу и т.д. Программа "Вызов" будет служить для облегчения работы диспетчера предприятия. Наиболее рутинными и в то же время наиболее ответственными процессами являются: поиск нужного лифтера, заполнение бланка заявки.

Согласно ER – методу проектирования на первом этапе определяем сущности и их атрибуты. При проектировании БД ИС ГП "Алушталифт" выделены следующие сущности:

-           Дом;

-           Вызов;

-           Лифт;

-           Ремонтные работы;

-           Лифтер.

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

-           Сущность "дом" включает в себя следующие атрибуты: код дома, город и адрес. Ключевое поле "Рег. № дома";

-           Сущность "вызов" включает в себя следующие атрибуты: код вызова, код работы, код лифтера, код лифта и дату вызова. Ключевое поле "номер вызова";

-           Сущность "лифт" включает в себя следующие атрибуты: код лифта, имя, тип лифта, тип дверей, подъезд и код дома. Ключевое поле "С/№ лифта";

-           Сущность "ремонтные работы" включает в себя следующие атрибуты: код работы, тип работы, цена, описание и допуск работника. Ключевое поле "Код рем. Работы";

-           Сущность "лифтер" включает в себя следующие атрибуты: код лифтера, ФИО, адрес лифтера, допуск и дату приема на работу. Ключевое поле "Рег. № лифтера"

На втором этапе проектирования определим степени связей между сущностями и класс принадлежностей. Предположим что в вызове может находится множество ремонтных работ, в то время как ремонтная работа может относится только к одному вызову. Ремонтные работы обязаны, относится к вызову, а вызов должен включать в себя ремонтные работы. Таким образом, степень связи между отношениями "ремонтные работы" и "вызов" - один ко многим (1:N), а класс принадлежности N – связной сущности – обязательный. Следовательно, по правилу 4 генерации предварительных отношений достаточным является наличие двух отношений, по одному на каждую сущность, при условии, что ключ сущности служит в качестве первичного ключа для соответствующего отношения. Дополнительно ключ 1-связной сущности должен быть добавлен в качестве атрибута в отношение, отводимое N-связной сущности.

Аналогичным образом в вызове может находится множество лифтов, в то время как лифт относится только к одному вызову. Лифт обязан относится к вызову, а вызов должен включать в себя лифт. Таким образом, степень связи между отношениями "лифт" и "вызов" - один ко многим (1:N), класс принадлежности – обязательный. Следовательно, по правилу 4 генерации предварительных отношений достаточным является наличие двух отношений, по одному на каждую сущность, при условии, что ключ сущности служит в качестве первичного ключа для соответствующего отношения. Дополнительно ключ 1-связной сущности должен быть добавлен в качестве атрибута в отношение, отводимое N-связной сущности.

В вызове может находится множество лифтеров, но лифтер может относится только к одному вызову. Лифтер обязан относится к вызову , а вызов должен включать в себя лифтера. Таким образом, степень связи между отношениями "лифтер" и "вызов" - один ко многим (1:N), класс принадлежности – обязательный. Следовательно, по правилу 4 генерации предварительных отношений достаточным является наличие двух отношений, по одному на каждую сущность, при условии, что ключ сущности служит в качестве первичного ключа для соответствующего отношения. Дополнительно ключ 1-связной сущности должен быть добавлен в качестве атрибута в отношение, отводимое N-связной сущности.

В лифте может содержатся множество домов, но дом может содержать только один лифт. Дом обязан относится к лифту, а лифт должен включать в себя дом. Таким образом, степень связи между отношениями "дом" и "лифт" - один ко многим (1:N), класс принадлежности – обязательный. Следовательно, по правилу 4 генерации предварительных отношений достаточным является наличие двух отношений, по одному на каждую сущность, при условии, что ключ сущности служит в качестве первичного ключа для соответствующего отношения. Дополнительно ключ 1-связной сущности должен быть добавлен в качестве атрибута в отношение, отводимое N-связной сущности.

В результате мы получили инфологическую модель БД ИС "Вызов" в виде ER – диаграммы (см. Рис. 3.1)

Рис 3.1. ER – диаграмма БД ИС "Вызов"

На основе полученной инфологической модели построим даталогическю модель в виде просто сети (см. Рис. 3.2)

Рис 3.2. Даталогическая модель БД ИС "Вызов"

Теперь мы можем на основе даталогической модели построить физическую модель БД ИС "Вызов" в нотации СУБД Paradox.

Рис 3.3. Физическая модель БД ИС "Вызов"

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