Отчет по преддипломной практике

Отчет содержит в себе описание этапов разработки базы данных и клиентского приложения для компании занимающейся оказанием услуг. Место прохождения практики в ООО «КИП-СЕРВИС» в г.Пенза. Отчет сдан на оценку 5. База данных разработана с помощью ­СУБД Firebird 2.5. клиентское приложение написано на Delphi. ...

Введение ………………………………………………………………………….4
1 Анализ предметной области …………………………………………………..7
2 Техническое задание ………………………………………………………….11
2.1 Основание для разработки ……………………………………………….11
2.2 Назначение разработки …………………………………………………..11
2.3 Требования к программе …………………………………………………11
2.3.1 Требования к функциональным характеристикам ………………...11
2.3.2 Требования к надежности …………………………………………...12
2.3.3 Требования к составу и параметрам технических средств ……….13
2.3.4 Требования к информационной и программной совместимости ...13
2.4 Требования к программной документации ……………………………..14
2.5 Стадии и этапы разработки ……………………………………………....14
2.6 Порядок контроля и приемки ……………………………………………15
3 Обоснование целесообразности использования заданных средств
разработки ………………………………………………………………………..16
4 Проектирование автоматизированной системы …………………………….23
4.1 Концептуальное проектирование ……………………………………….23
4.2 Логическое проектирование ……………………………………………..35
4.3 Физическое проектирование …………………………………………….41
Заключение ………………………………………………………………………46
Список использованных источников…………………………………………...47

Автоматизированная информационная система — это совокупность различных программно-аппаратных средств, которые предназначены для автоматизации какой-либо деятельности, связанной с передачей, хранением и обработкой различной информации.
Использование современных информационных систем позволяет:
­ работать с огромными объемами данных;
­ хранить какие-либо данные в течение довольно длительного временного периода;
­ связать несколько компонентов, которые имеют свои определенные локальные цели, задачи и разнообразные приемы функционирования, в одну систему для работы с информацией;
­ существенно снизить затраты на доступ и хранение к любым необхо-димым данным;
­ быстро найти всю необходимую информацию.
На сегодняшний день, автоматизированная информационная система, является совокупностью техниче ских (аппаратных), математических, телекоммуникационных, алгоритмических средств, методов описания и поиска объектов программирования и сбора и хранения информации.
Неотъемлемой частью современной повседневной жизни стали базы данных, для поддержки которых требуются системы управления базами данных (СУБД).
База данных – это информационная модель, позволяющая упорядоченно хранить данные о группе объектов, обладающих одинаковым набором свойств. Система управления базами данных (СУБД) - программное обеспечение, с помощью которого пользователи могут определять, создавать и поддерживать базу данных, а также получать к ней контролируемый доступ.
Системы управления базами данных позволяют объединять большие объемы информации и обрабатывать их, сортировать, делать выборки по определенным критериям.
В качестве примера современной информационной системы, стоит упо-мянуть автоматизированные системы управления предприятиями, системы резервирования железнодорожных или авиационных билетов, банковские системы.
Компания ООО «КИП-СЕРВИС» зарегистрирована 3 июля 2009 года регистратором Инспекция Федеральной налоговой службы по Железнодорожному району г. Пензы.
Основная цель деятельности ООО «КИП сервис» заключается в оказании услуг физическим и юридическим лицам. Основным видом деятельности компании являются:
- монтаж, пуско-наладочные работы систем автоматического отключе-ния газа;
- техническое обслуживание и ремонт на опасных производственных объектах, системах газопотребления, средств контроля и защиты газового оборудования газоиспускающих установок (котлоагрегатов);
- монтаж на опасных производственных объектах, системах газопотребления, средств контроля и защиты газового оборудования газоиспускающих установок (включая, пуско-наладочные работы).
Услуги, предоставляемые компанией, пользуются большим спросом, и количество клиентов постоянно растёт, в связи с этим компания нуждается в расширении возможностей обслуживания клиентов.
Базы данных являются эффективным средством представления структур данных и манипулирования ими. Для конечного пользователя удобнее работать с приложением БД, поскольку оно имеет дружественный интерфейс, понятную структуру.
В представленной работе описывается автоматизированная система базы данных учёта договоров, позволяющая вести обслуживание клиентов, оформлять отчетные документы, вести учет предоставленных услуг.
При проектировании автоматизированной системы использовались средства разработки базы данных IBExpert.и Firebird 2.5 и CASE-средство Open ModelSphere 3.2.

Цена оказания услуги
Vipoln_rabota
id_rabot
Идентификатор работы
id_yslyg
Идентификатор услуги
kolvo_rabot
Количество работ
Rabota
id_rabot
Идентификатор работы
name_rabot
Название работы
opisanie
Описание работы
prise_rabot
Цена выполнения работы
Neobhodimie_material
id_postavhik
Идентификатор поставщика
id_material
Идентификатор материала
id_rabot
Идентификатор работы
kolvo_material
Количество материалов
Vkluch_material
id_postavhik
Идентификатор поставщика
id_material
Идентификатор материала
prise_material
Цена материала
Postavhik
id_postavhik
Идентификатор поставщика
name_postavhik
Название поставщика
adres_postavhik
Адрес поставщика
telephon_postavhik
Телефон поставщика
Material
id_material
Идентификатор материала
name_material
Название материала
parametr_material
Параметры материала
Таким образом, в результате концептуального проектирования были разработаны контекстная и детализирующая диаграммы, а также сформированы структуры данных.
4.2 Логическое проектирование
Дальнейшим этапом разработки системы является этап логического проектирования. На этапе логического проектирования необходимо преобразовать концептуальную модель данных в логическую модель данных с учётом выбранного типа СУБД (например, реляционной СУБД).
На основе разработанной контекстной и детализирующих диаграмм, а также сформированы структур данных, были определены первичные ключи сущностей, которые приведены в таблице 4.2.
Таблица 4.2 – Первичные ключи сущностей
Структура
Атрибут
Ключевые параметры
1
2
3
Kontragent
id_kontragent
РК
name_k
adress
kpp
inn
telefon_k
director
r_s
bik
k_s
Dogovor
id_dogovor
РК
date_d_n
summ_d
id_kontragent
srok_deistvia
Plateg
id_plateg
РК
id_dogovor
РК
date_pl
vid_pl
Prilog_dogovora
id_prilogen
РК
id_dogovor
РК
name_pril
soderganie
Продолжение таблицы 4.2
1
2
3
Vkluch_yslyg
id_stroki
РК
id_dogovor
РК
id_yslyg
kolvo_yslys
Defect
id_defect
РК
id_stroki
id_dogovor
opisanie_defect
summ_defect
data_defect
Akt_rabot
id_akt
РК
id_dogovor
id_stroki
date_akt
Yslyga
id_yslyg
РК
name_yslyg
prise_yslyg
Vipoln_rabota
id_rabot
РК
id_yslyg
РК
kolvo_rabot
Rabota
id_rabot
РК
name_rabot
opisanie
prise_rabot
Neobhodimie_material
id_postavhik
РК
id_material
РК
id_rabot
РК
kolvo_material
Vkluch_material
id_postavhik
РК
id_material
РК
prise_material
Postavhik
id_postavhik
РК
name_postavhik
adres_postavhik
telephon_postavhik
Продолжение таблицы 4.2
1
2
3
Material
id_material
РК
name_material
parametr_material
На основании анализа предметной области, один и тот же материал может поставляться несколькими поставщиками, в логическую модель включается сущность «Vkluch_material», имеющий составной первичный ключ: «id_material» и «id_postavhik». На основании анализа предметной области, так как на выполнение одной работы может потребоваться несколько видов материалов, а один и тот же материал может потребоваться для выполнения нескольких видов работ, в логическую модель включается сущность «Neobhodimie_material», имеющий составной первичный ключ: «id_rabot», «id_postavhik» и «id_material». Также на основании анализа предметной области, так как каждая работа входит в перечень работ при оказании услуг, в логическую модель включается сущность «Vipoln_rabota», имеющий составной первичный ключ: «id_yslyg» и «id_rabot». На основании анализа предметной области, так как по договору может выполняться несколько услуг, а каждая услуга может присутствовать в строках нескольких договоров, в логическую модель включается сущность «Vkluch_yslyg», имеющий составной первичный ключ: «id_yslyg» и «id_dogovor». На основании анализа предметной области, так как конкретный платёж относится только к одному договору и не может относиться к нескольким договорам, в логическую модель в сущности «Plateg» создаётся составной первичный ключ: «id_plateg» и «id_dogovor». На основании анализа предметной области, так как приложение относится только к одному договору и не может относиться к нескольким договорам, в логическую модель в сущности «Prilog_dogovora» создаётся составной первичный ключ: «id_prilogen» и «id_dogovor».
Степень участия между сущностями Kontragent - Dogovor частичная, так как данный контрагент мог ещё не заключать договоров с фирмой. Степень участия между сущностями Dogovor - Plateg полная, так как сущность Plateg без сущности Dogovor существовать не может. Степень участия между сущностями Dogovor - Prilog_dogovora полная, так как сущность Prilog_dogovora без сущности Dogovor существовать не может. Степень участия между сущностями Dogovor - Vkluch_yslyg полная, так как сущность Vkluch_yslyg без сущности Dogovor существовать не может. Степень участия между сущностями Vkluch_yslyg - Defect частичная, так как данный дефект может не относится к данной оказанной услуге. Степень участия между сущностями Vkluch_yslyg - Akt_rabot частичная, так как на каждую выполненную услугу может быть составлен акт работ, который по требованию предприятия представляет собой отдельный документ. Степень участия между сущностями Vkluch_yslyg - Yslyga частичная, так как оказание данной услуги может не предусматриваться данным договором. Степень участия между сущностями Yslyga - Vipoln_rabota полная, так как сущность Vipoln_rabota без сущности Yslyga существовать не может и к каждой услуге может быть перечень выполняемых работ. Степень участия между сущностями Rabota - Vipoln_rabota полная, так как сущность Vipoln_rabota без сущности Rabota существовать не может, и каждая работа входит в перечень работ при оказании услуг. Степень участия между сущностями Rabota - Neobhodimie_material полная, так как сущность Neobhodimie_material без сущности Rabota существовать не может и на выполнение одной работы может потребоваться несколько видов материалов, а один и тот же материал может использоваться для выполнения нескольких видов работ. Сущность Vibranie_postavhiki связанна с сущностью Neobhodimie_material. Степень участия между ними полная, так как выбранные материалы могут использоваться в процессе выполнения нескольких работ, но конкретный материал может не применятся для выполнения данной работы, и сущность Neobhodimie_material без сущности Vibranie_postavhiki существовать не может. Сущность Vibranie_postavhiki связанна с сущностями Postavhik и Material. Степень участия между сущностями ними полная, так как материал выбирается из общего списка материалов, он может быть изготовлен различными поставщиками, один поставщик может поставлять несколько видов материала.
Таким образом, была построена концептуальная модель данных. Концептуальная модель данных представлена на рисунке 4.4.
Рисунок 4.4 – Концептуальная модель данных
Исходя из анализа предметной области, были определены показатели кардинальности связей между сущностями, данные приведены в таблице 4.3.
Таблица 4.3 – Показатели кардинальности связей.
Связь
Показатель
Примечание
Kontragent - Dogovor
0:N
Один контрагент может заключить несколько договоров, но конкретный контрагент может ещё не заключать договоров с компанией.
Dogovor - Plateg
0:N
По одному договору может быть несколько платежей, но конкретный договор может быть ещё не оплачен
Dogovor - Prilog_dogovora
0:N
К одному договору могут прилагаться несколько документов, но к данному договору может не быть ни одного приложения
Dogovor - Vkluch_yslyg
1:N
Один договор может быть на оказание нескольких услуг, но договор заключается хотя бы на оказание одной услуги
Vkluch_yslyg - Defect
0:N
На одну из оказанных услуг может быть несколько дефектов, но на конкретную оказанную услугу может быть не заведено не одного дефекта
Vkluch_yslyg - Akt_rabot
0:1
На одну оказанную услугу может быть только один акт работ, но конкретная услуга может быть ещё не оказана
Vkluch_yslyg - Yslyga
0:N
Одна услуга может присутствовать в строках нескольких договоров, но данная услуга может не входить в конкретный договор
Yslyga - Vipoln_rabota
0:N
При оказании одной услуги можно выполнить несколько работ, но на конкретную услугу может не понадобится выполнение данных работ
Rabota - Vipoln_rabota
0:N
Одну и туже работу может быть необходимо выполнить при оказании нескольких услуг, но конкретная работа может не понадобится при оказании данной услуги
Продолжение таблицы 4.3.
Rabota - Neobhodimie_material
0:N
На выполнение одной работы может пригодится несколько материалов, но на выполнение конкретной работы материалы могут быть не нужны
Vkluch_material - Neobhodimie_material
0:N
Выбранные материалы могут использоваться в процессе выполнения нескольких работ, но конкретный материал может не применятся для выполнения данной работы
Postavhik - Vkluch_material
0:N
Один поставщик может поставлять несколько материалов, но данный поставщик может ещё не поставлять ни одного материала
Material - Vkluch_material
0:N
У одного материала может быть несколько поставщиков, но данный материал может ещё не поставляться не одним поставщиком
На рисунке 4.5 представлена логическая модель данных, разработанная с помощью среды Open ModelSphere 3.2.
Рисунок 4.5 – Логическая модель данных
Таким образом, была разработана концептуальная и логическая модель данных системы, были определены показатели кардинальности, степени участия и ограничения целостности.
4.3 Физическое проектирование
Этап физического проектирования базы данных предусматривает принятие разработчиком окончательного решения о способах реализации создаваемой базы (например, с помощью СУБД Firebird). Принятые на этом этапе решения оказывают определяющее влияние на производительность системы.
Созданная на этапе логического проектирования диаграмма «сущность-связь», была преобразована с помощью системы Open ModelSphere 3.2 в завершенную реляционную модель. Физическая модель данных представлена на рисунке 4.6.
Рисунок 4.6 – Физическая модель данных
На этапе физического проектирования были сгенерированы внешние ключи, определены типы данных атрибутов сущностей в соответствии с выбранной СУБД Firebird 2.5. описание атрибутов сущностей представлено в таблицах 4.4 – 4.17.
Таблица 4.4 – Сущность KONTRAGENT
Имя поля
Тип
ПК
ВК
Описание
ID_KONTRAGENT
INTEGER
+
-
Идентификатор контрагента
NAME_K
VARCHAR
-
-
Название контрагента
ADRESS
VARCHAR
-
-
Адрес контрагента
KPP
CHAR
-
-
КПП контрагента
INN
VARCHAR
-
-
ИНН контрагента
TELEFON_K
VARCHAR
-
-
Телефон контрагента
DIRECTOR
VARCHAR
-
-
ФИО директора контрагента
R_S
CHAR
-
-
Р\С
BIK
CHAR
-
-
БИК
K_S
CHAR
-
-
К\С
Таблица 4.5 – Сущность DOGOVOR
Имя поля
Тип
ПК
ВК
Описание
ID_DOGOVOR
INTEGER
+
-
Идентификатор договора
ID_KONTRAGENT
INTEGER
-
+
Идентификатор контрагента
DATE_D_N
DATE TIME
-
-
Дата заключения договора
SUMM_D
DOUBLE PRECISION
-
-
Сумма по договору
SROK_DEISTVIA
VARCHAR
-
-
Срок действия договора
Таблица 4.6 – Сущность PLATEG
Имя поля
Тип
ПК
ВК
Описание
ID_PLATEG
INTEGER
+
-
Идентификатор платежа
ID_DOGOVOR
INTEGER
+
+
Идентификатор договора
DATE_PL
DATE TIME
-
-
Дата платежа
VID_PL
VARCHAR
-
-
Вид платежа
Таблица 4.7 – Сущность PRILOG_DOGOVORA
Имя поля
Тип
ПК
ВК
Описание
ID_PRILOGEN
INTEGER
+
-
Идентификатор приложения к договору
ID_DOGOVOR
INTEGER
+
+
Идентификатор договора
NAME_PRIL
VARCHAR
-
-
Название приложения
SODERGANIE
VARCHAR
-
-
Содержание приложения
Таблица 4.8 – Сущность VKLUCH_YSLYG
Имя поля
Тип
ПК
ВК
Описание
ID_STROKI
INTEGER
+
-
Идентификатор строки договора
ID_DOGOVOR
INTEGER
+
+
Идентификатор договора
KOLVO_YSLYG
INTEGER
-
-
Количество услуг
ID_YSLYG
INTEGER
-
+
Идентификатор услуги
Таблица 4.10 – Сущность DEFECT
Имя поля
Тип
ПК
ВК
Описание
ID_DEFECT
INTEGER
+
-
Идентификатор дефекта
OPISANIE_DEFECT