Проектирование, разработка и внедрение БД ИС в экономическую деятельность предприятия (на примере ГП "Алушталифт") (стр. 12 из 15)

Выводы по Разделу 2

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

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

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)