Файл: Проектирование реализации операций бизнес-процесса «Разработка стратегии охраны окружающей среды»..pdf

ВВЕДЕНИЕ

Актуальность исследования.

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

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

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

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

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

Для достижения данной цели необходимо решение следующих задач:

• Описать документооборот на предприятию;
• Описать бизнес-процессы;
• Обосновать проектные решения по информационному обеспечению;
• Обосновать проектные решения по программному обеспечению;
• Описать информационную модель программы;
• Описать программное обеспечение;
• А так же описать пример реализации программы.

Объектом исследования данной курсовой работы школьное учебное заведение. Предметом исследования выступает процесс документооборота.

Работа состоит из введения, двух глав («Аналитическая часть», «Проектная часть»), заключения и списка использованной литературы.

ГЛАВА 1. АНАЛИТИЧЕСКАЯ ЧАСТЬ

1.1. Характеристика комплекса задач

1.1.1. Выбор комплекса задач автоматизации

Автоматизировать можно любую сферу деятельности. Главное в процессе автоматизации определиться что надо автоматизировать. То есть надо сформулировать точно задание для автоматизации. Так как правильность формулировки задания – это ключ к быстрому решению задачи.

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

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

1.1.2. Характеристика и существующих бизнес –процессов

Каждое предприятия ежедневно выбрасывают вредные вещества к окружающую среду. Но ежемесячно они предоставляют отчет в соответствующие государственные службы.

С данной информацией работает работник экологической службы. Он ежемесячно собирает информацию с каждого предприятия и работает с полученными данными.

Бизнес-процесс в данном случае который имеет место в данной области показан на рисунке 1:

Рисунок 1 – Бизнес-процессы

1.1.3. Характеристика документооборота, возникающего при решении задачи

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

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

Рисунок 2 – Схема документооборота

Проанализируем рисунок 2 более детально. Замечаем что, имеет место обработки информации в автоматизированном режиме. Но, следует отметить, что работники сталкиваются с некоторыми недочетами в таком режиме работы. Это происходи потому, что кроме заполнения электронных таблиц, работники параллельно ведут обработки информации в ручном режиме. А это приводит к тому, что есть следующие недостатки:

• Хранение большого объема информации;
• Работа с большим объемом данных;
• Большая вредоносность ошибки;
• Проблемы с исправлением, в случае ошибки;

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

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

1.2. Обоснование проектных решений

1.2.1. Обоснование проектных решений по информационному обеспечению

Для разработки базы данных была выбрана реляционная модель баз данных.

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

Итак, иерархическая модель баз данных. Это самая первая модель баз данных. Данные в ней хранятся в древовидном виде с дугами-связями и узлами-элементами данных. Иерархическая структура предполагала неравноправие между данными - одни жестко подчинены другим. Подобные структуры, безусловно, четко удовлетворяют требованиям многих, но далеко не всех реальных задач^[1].

Данная модель имеет недостатки, среди которых можно выделить следующие:

• Ограничения в организации отношении между сущностями. Иерархическая модель позволяет организовать последовательную связь "один ко многим" между данными, но не в состоянии реализовать отношения "многие ко многим".
• Структурная зависимость. Иерархическая структура предполагала, что физически данные также станут храниться в виде дерева. Серьезное изменение структуры (например, переподчинение узлов) могло привести к тому, что прикладные приложения теряли возможность навигации по данным.
• Сложность разработки прикладного программного обеспечения (ППО). Разработчик программ должен знать особенности физического хранения данных, иначе он мог просто заблудиться в запутанной системе указателей.

Ко всему прочему иерархическая модель не была стандартизирована. Как следствие всегда существовала проблема переносимости данных между приложениями различных разработчиков^[2].

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

Сетевая модель данных определяется в тех же терминах, что и иерархическая. Она состоит из множества записей, которые могут быть владельцами или членами групповых отношений. Связь между записью-владельцем и записью-членом также имеет вид 1:N.

Основное различие этих моделей состоит в том, что в сетевой модели запись может быть членом более чем одного группового отношения. Согласно этой модели каждое групповое отношение именуется и проводится различие между его типом и экземпляром. Тип группового отношения задается его именем и определяет свойства общие для всех экземпляров данного типа. Экземпляр группового отношения представляется записью-владельцем и множеством (возможно пустым) подчиненных записей. При этом имеется следующее ограничение: экземпляр записи не может быть членом двух экземпляров групповых отношений одного типа^[3].

К сожалению, сетевая модель также не свободна от недостатков:

• большое количество произвольных связей повышает сложность схемы БД и как следствие, вызывает дополнительные трудности при обеспечении целостности данных;

сложность разработки прикладного программного обеспечения^[4].

СУБД используют несколько моделей данных: иерархическую и сетевую (с 60-х годов) и реляционную (с 70-х). Основное различие данных моделей в представлении взаимосвязей между объектами.

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

Реляционная база данных – это база данных, вся информация которой содержится в таблицах, связанных между собой.

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

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

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

В структурной части реляционной модели базы данных зафиксировано, что нормализованное n-арное отношение является единственной структурой данных, которая используется в реляционных базах данных^[5].

БД состоит из таблиц, где хранятся все данных. Следует отметить, что каждая таблица обладает уникальны кодов.

В создаваемой программе должно быть выполнено ведение следующих классификаторов и справочников (с указанием их атрибутов):

• Сброс отравляющих веществ:
  • Код предприятия,
  • дата сброса,
  • концентрация,
  • размер сброса,
  • код единицы измерения,
  • сумма ущерба,
• предприятия:
  • код,
  • Наименование,
  • адрес,
  • телефон,
  • код города,
• единицы измерения:
  • код,
  • наименование,
• города:
  • код,
  • наименование, область.

1.2.2. Обоснование проектных решений по программному обеспечению

Для создания базы данных была СУБД Paradox .

СУБД Paradox - одна из самых старых локальных баз данных.

Система Paradox работает с таблицами по тому же принципу, что и dBase. То есть каждая таблица БД хранится в отдельном файле, MEMO- и BLOB-поля так же находятся отдельном файле, аналогичным образом организовано хранение индексов.

Если сравнить dBase с Paradox относительно формата данных, то следует отметить, что в Paradox не имеет открытый доступ, то есть нужны специальные библиотеки. Данное свойство является в некоторой степени и преимуществом данной системы. преимущество состоит в том, что доступ к данным выполняется только с помощью «знающих» этот формат библиотек, простое редактирование подобных данных по сравнению с данными открытых форматов типа dBase существенно затруднено.

Если рассмотреть более первые версии системы, то можно сказать, что программистам баз данных предоставлялись существенно более расширенные возможности, такие как применение деловой графики в DOS-приложениях, обновление данных в приложениях при многопользовательской работе, визуальные средства построения запросов, на основе интерфейса QBE — Query by Example, средства статистического анализа данных, а также средства визуального построения интерфейсов пользовательских приложений с автоматической генерацией кода на языке программирования PAL.

Кроме того, СУБД Paradox, позволяет манипулировать данными других форматов, в том числе dBase и данными, которые хранятся в серверных СУБД. Это возможно за счет применение библиотеки Borland Database Engine и драйверов SQL Links. Это позволило использовать Paradox в качестве универсального средства управления различными базами данных^[6].

Среди недостатков системы Paradox можно отметить, то что отсутствуют пакете компилятора для создания EXE-файлов, и, как следствие, автономных программных продуктов.

Система Paradox обладает практически такой-же или даже превосходящую производительность чем DBase/FoxPro, однако имеет значительно более слабую собственную среду программирования.

Язык прикладного программирования СУБД Paradox не очень сложный, поэтому его легко учить. Для создания простых прикладных программ система Paradox может запомнить последовательно вводимые команды и затем преобразовать их в файл сценария для последующего воспроизведения команд. Специалисты в области программирования с помощью данной системы могут разрабатывать очень сложные прикладные программы. В Paradox for Windows существует объектно-ориентированная версия PAL, называемая Object PAL.