Разработка базы данных автоматизированной системы поверки приборов учёта электроэнергии

· Обеспечение процедур проверки достоверности информации обеспечение процедур ограничения доступа к данным;

· Совмещение требований к использованию БД со стороны различных пользователей ИС.

Концептуальная схема - это (от слова concept - понятие) представляет собой описание структуры всех единиц информации, хранящихся в БД.

Под структурой понимается вхождение одних единиц информации в состав других единиц информации.

Информационный процессор - это механизм, который в ответ на получение команды выполняет операции с БД и концептуальной схемой. Информационный процессор состоит из вычислительной системы, системы управления базой данных - СУБД, а также включает администратора базы данных.

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

Обычно современная СУБД содержит следующие компоненты:

· Ядро, которое отвечает за управление данными во внешней и оперативной памяти и журнализацию;

· Процессор языка базы данных, обеспечивающий оптимизацию запросов на извлечение и изменение данных и создание, как правило, машинно-независимого исполняемого внутреннего кода;

· Подсистему поддержки времени исполнения, которая интерпретирует программы манипуляции данными, создающие пользовательский интерфейс с СУБД;

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

Основным функциям СУБД относится:

· Управление данными во внешней памяти (на дисках);

· Управление данными в оперативной памяти;

· Журнализация изменений;

· Восстановление базы данных после сбоев (механизм транзакций);

· Поддержание языков БД (язык определения данных, язык манипулирования данными).

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

3.2 Архитектура MicrosoftAccess

MicrosoftAccess обладает всеми чертами классической СУБД. Access - это не только мощная, гибкая и простая в использовании СУБД, но и система для разработки приложений баз данных. К числу наиболее мощных средств Accessотносятся средства разработки объектов - мастера, которые можно использовать для создания таблиц, запросов, различных типов форм и отчетов. В MicrosoftAccess включены мастера, помогающие производить анализ структуры данных, импортировать электронные таблицы и текстовые данные, повышать быстродействие приложения, создавать и настраивать одно из более, чем двадцати типов приложений с использованием встроенных шаблонов. Чтобы полностью автоматизировать работу приложения, можно использовать макросы для связывания данных с формами и отчетами. Большинство приложений можно создать, не написав ни единой строки программного кода. Однако при необходимости построения действительно сложного приложения можно использовать язык программирования - VisualBasic для приложений.

MicrosoftAccess называет объектами все, что может иметь имя (в смысле Access). В базе данных Access основными объектами являются таблицы, запросы, формы, отчеты, макросы и модули. В других СУБД, как правило, термин база данных обычно относится только к файлам, в которых хранятся данные. В MicrosoftAccess база данных включает в себя все объекты, связанные с хранимыми данными, в том числе и те, которые определяются для автоматизации работы с ними. Ниже приведен список основных объектов базы данных Access.

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

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

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

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

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

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

Концептуальные взаимосвязи объектов Access показаны на рисунке3.1. В таблицах хранятся данные, которые можно извлекать с помощью запросов. Используя формы, можно выводить данные на экран или изменять их. Формы и отчеты получают данные как непосредственно из таблиц, так и через запросы. Для выполнения нужных вычислений и преобразования данных запросы могут использовать встроенные функции или функции, созданные с помощью VisualBasic для приложений. События, происходящие в формах или отчетах, могут запускать макросы или процедуры VBA. Событие - любое изменение состояния объекта MicrosoftAccess. Например, событием является открытие формы, закрытие формы, ввод новой строки в форму, изменение содержимого текущей записи или элемента управления (объекта формы или отчета, который может содержать данные). Для обработки события можно создать макрос или процедуру VisualBasic для приложений.

С помощью макросов и модулей можно изменять ход выполнения приложения; открывать, фильтровать и изменять данные в формах и отчетах; выполнять запросы и создавать новые таблицы. Используя VisualBasic для приложений, можно создать, модифицировать и удалить любой объект Access, обрабатывать данные по строкам или по столбцам, а также каким-либо другим способом. Можно также вызывать процедуры из библиотек динамической компоновки (DLL) MicrosoftWindows, чтобы использовать в своем приложении не только встроенные в Access функции, но и возможности Windows.

Рисунок3.1- Взаимосвязи основных объектов в MicrosoftAccess

3.3 Структурная схема таблиц

В таблице “тКонтролер” фиксируются данные контролера, его квалификация и даты последней и следующей аттестации. Ключевым полем является “Код контролера”, представленная типом данных “Счетчик”. Для полей: “Фамилия”, “Имя”, “Отчество”, “Квалификация” - выбран тип данных “Короткий текст (256 символов)”. Для полей: “Дата последней аттестации”, “Дата следующей аттестации” - выбран тип данных “Дата и время”. Структура таблицы “тКонтролер” имеет следующий вид:



Рисунок 3.2 - Структура таблицы тКонтролер

В таблице “тЛицензия” фиксируются данные лаборатории поверки, её данные о лицензии и даты действия лицензии. Ключевым полем является “Код лицензии лаборатории”, представленная типом данных “Счетчик”. Для полей: “Наименование лицензии”, “Наименование лицензиата” - выбран тип данных “Короткий текст (256 символов)”. Для полей: “Дата выдачи лицензии”, “Дата окончания лицензии” - выбран тип данных “Дата и время”. Структура таблицы “тЛицензия” имеет следующий вид:

Рисунок 3.3 - Структура таблицы тЛицензия

В таблице характеристик приборов поверки “тПоверяющееОборудование” фиксируются данные поверяющего оборудования, его точность, название, производитель и даты последней и следующей поверки, а также даты изготовления и ввода в эксплуатацию. Ключевым полем является “Код поверяющего оборудования”, представленная типом данных “Счетчик”. Для полей: “Наименование оборудования”, “Производитель”, “Класс точности прибора” - выбран тип данных “Короткий текст (256 символов)”. Для полей: “Дата изготовления”, “Дата ввода в эксплуатацию”, “Дата последней поверки”, “Дата следующей поверки” - выбран тип данных “Дата и время”. Структура таблицы “тПоверяющееОборудование” имеет следующий вид:

Рисунок 3.4- Структура таблицы тПоверяющееОборудование

В таблице характеристик приборов “тПараметрыИзмерения” фиксируются параметры измерения поверяющего оборудования, наименование прибора, его параметры измерения и диапазон измерения, а также погрешность прибора измерения. Ключевым полем является “Код параметров измерения”, представленная типом данных “Счетчик”. Для поля “Наименование параметра измерения” выбран тип данных “Короткий текст (256 символов)”. Для полей: “Нижний предел измерения”, “Верхний предел измерения”, “Погрешность измерения” - выбран тип данных “Числовой”. Поле “Код поверяющего прибора” является полем подстановки ключевого поля из таблицы “тПоверяющееОборудование”. Структура таблицы “тПараметрыИзмерения” имеет следующий вид:

Рисунок 3.5- Структура таблицы тПараметрыИзмерения

В таблице измерений “тОперацииПоверки” фиксируются измерения, сделанные контролером, прибор, производящий измерения, и его параметр измерения, название операции и допустимый диапазон. Ключевым полем является “Код Операции”, представленная типом данных “Счетчик”. Для полей: “Наименование операции”, “Наименование параметра контроля” - выбран тип данных “Короткий текст (256 символов)”. Для полей: “Значение параметра контроля”, “Допустимое Мин_значение”, “Допустимое Макс_значение” - выбран тип данных “Числовой”. Поле “Код контролирующего прибора” является полем подстановки ключевого поля из таблицы “тПоверяющееОборудование”. Структура таблицы “тОперацииПоверки” имеет следующий вид:



Рисунок 3.6 - Структура таблицы тОперацииПоверки

В таблице характеристик приборов “тПоверяемоеОборудование” фиксируются характеристики счетчика, периодичность поверки, имя контролера, результат измерения (контроля) и даты изготовления и ввода в эксплуатацию. Ключевым полем является “Код заводской счетчика”, представленная типом данных “Счетчик”. Для полей: “Наименование счетчика”, “Класс счетчика”, “Мощность”, “Периодичность поверки”, “Производитель”, “Показания на момент поверки” - выбран тип данных “Короткий текст (256 символов)”. Для полей: “Дата изготовления”, “Дата ввода в эксплуатацию” - выбран тип данных “Дата и время”. Поле “Контролер” является полем подстановки ключевого поля из таблицы “тКонтролер”. Поле “Тип счетчика” является полем подстановки из раннее созданного списка выбора. Структура таблицы “тПоверяемоеОборудование” имеет следующий вид:

Рисунок 3.7 - Структура таблицы тПоверяемоеОборудование

В главной таблице “тПоверка” фиксируются все данные о поверки: лицензия, на основе которой проходит поверка, наименование операции поверки, имя контролера, производящего поверку, и показание его прибора, название и характеристики счетчика, вид поверки и даты последней и следующей поверки электросчетчика. Ключевыми полями является “Код поверки” и “Код операции поверки”, представленные типами данных “Счетчик”. Для полей: “Периодичность”, “Показания контролирующего” - выбран тип данных “Числовой”. Для полей: “Дата поверки”, “Дата предыдущей поверки” - выбран тип данных “Дата и время”. Ключевое поле “Код операции поверки” является полем подстановки ключевого поля из таблицы “тОперацииПоверки”. Поле “Код лицензии лаборатории” является полем подстановки соответствующего ключевого поля из таблицы “тЛицензия”. Поле “Код счетчиков” является полем подстановки ключевого поля из таблицы “тПоверяемоеОборудование”. Поле “Код поверяющего” является полем подстановки ключевого поля из таблицы “тКонтролер”. Поле “Вид поверки” является полем подстановки из раннее созданного списка выбора. Структура таблицы “тПоверка” имеет следующий вид:

Рисунок 3.8- Структура таблицы тПоверка

В таблице данных пользователей БД “тВход” фиксируются данные пользователя такие как уникальное имя пользователя “Логин”, должность, занимаемая в учреждение, а также уникальный пароль защищающий запись от посторонних, и уникальный индикатор присваивающий системой. Ключевым полем является “ИД”, представленная типом данных “Счетчик”. Для полей: “Логин” и “Пароль” - выбран тип данных “Короткий текст (256 символов)”. Поле “Должность” является полем подстановки из раннее созданного списка выбора. Структура таблицы “тВход” имеет следующий вид:

Рисунок 3.9 - Структура таблицы тВход

3.4 Структурная схема базы данных

Структура БД представляется схемой взаимосвязей таблиц БД. В этих связях отображаются виды связей(`один к одному', `один ко многим'), характер связей(правая, левая, внутренняя связи). Структура базы данных представлена на Рисунке 3.10:



Рисунок 3.10 - Схема данных базы данных

В этой схеме отображены взаимосвязи таблиц БД.

Главной таблицей, объединяющей все остальные, является таблица “тПоверка”, в которой фиксируются “Код поверки”, “Код операции поверки”, “Код лицензии лаборатории”, “Код счетчиков”, “Вид поверки”, “Периодичность”, “Дата поверки”, “Дата предыдущей поверки”, “Код поверяющего”, “Показания контролирующего”. Через поле “Код счетчиков” в таблицу подставляются названия поверяемых приборов из таблицы “тПоверяемоеОборудование” через поле подстановки “Код заводской счетчиков”.

В свою очередь в таблицу “тПоверяемоеОборудование” подставляются данные проверяющих из таблицы “тКонтролер” такие как: “Код контролера”, “Фамилия”, “Имя”, “Отчество”, “Квалификация”, “Дата последней аттестации”, “Дата следующей аттестации” - через поле подстановки “Контролер”. Эти же поля таблицы “тКонтролер” подставляются в таблицу “тПоверка”. Также в таблицу “тПоверка” подставляются данные о лицензиях из таблицы “тЛицензия” через поле “Код лицензии лаборатории” и включает такие поля как: “Код лицензии лаборатории”, “Наименование лицензии”, “Наименование лицензиата”, “Дата выдачи лицензии”, “Дата окончания лицензии”.

Результаты поверки счетчика, наименование измерительного прибора и их параметров фиксируются в таблицах “тОперацииПоверки”, “тПоверяемоеОборудование”, “тПараметрыИзмерения”.

Схема БД отражает вид связей между таблицами: связь “тПоверяемоеОборудование” и “тПоверка” определена как “ один-ко-многим”, что означает, что в системе предусмотрена поверка множества поверяемых приборов; в свою очередь связь “ один-ко-многим” между таблицами поверки “тПоверка” и “тКонтролер” показывает, что предусмотрено использование в поверке множество контролеров, которые, как и поверяемые приборы связаны отношением “многие-к-одному” с таблицей характеристик приборов тПоверяемоеОборудование”, что определяет возможность описание множества данных для этих приборов.

Таблица “тВход” является обособленной таблицей в базе данных и взаимодействует только с формами “Вход”, “Регистрация” и “Главная кнопочная форма Администратор”. Что обеспечивает защиту этих данных от других пользователей, в виду отсутствия прямого доступа к данным.

В схеме БД отображена возможность использование в поверке множеством операций поверок, множеством поверяющего оборудования, которые имеют множества параметров (отношения “один-ко-многим” и “многие-к-одному”). Все поля связи на стороне “много” являются полями подстановки соответствующих ключевых полей на стороне один. Например, поле “Код Операции” таблицы “тПараметрыИзмерения” является полем подстановки “Код операции поверки” таблицы “тПоверка”.

3.5 Структурная схема запросов

Запрос“Запрос за текущий год” фильтрует информацию о электросчетчиках, которые надо поверить в текущем году. Структура запроса “Запрос за текущий год” представлена следующей схемой:



Рисунок 3.11- Схема запроса “Запрос за текущий год”

Представление запроса “Запрос за текущий год” в форме SQL имеет следующий вид:

SELECT тПоверка.[Код операции поверки], тПоверка.[Код счетчиков], тПоверка.[Вид поверки], тПоверка.[Дата поверки], тПоверка.[Код поверяющего], тПоверка.[Показание контролирующего]

FROM тПоверка

WHERE (((тПоверка.[Дата поверки])>=#1/1/2017# And (тПоверка.[Дата поверки])<=#12/31/2017#));

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

Запрос“Запрос за текущий месяц” фильтрует информацию о электросчетчиках, которые надо поверить в текущем месяце. Структура запроса “Запрос за текущий месяц” представлена следующей схемой:



Рисунок 3.12- Схема запроса “Запрос за текущий месяц”

Представление запроса “Запрос за текущий месяц” в форме SQL имеет следующий вид:

SELECT тПоверка.[Код операции поверки], тПоверка.[Код счетчиков], тПоверка.[Вид поверки], тПоверка.[Дата поверки], тПоверка.[Код поверяющего], тПоверка.[Показание контролирующего]

FROM тПоверка

WHERE (((тПоверка.[Дата поверки])>=#6/1/2017# And (тПоверка.[Дата поверки])<=#6/30/2017#));

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

Запрос“Запрос за Итоговую таблицу”выводит полную информацию о электросчетчиках. Структура запроса “Запрос за Итоговую таблицу” представлена следующими схемами:



Рисунок 3.13а- Схема запроса “Запрос за Итоговую таблицу”

Рисунок 3.13б- Схема запроса “Запрос за Итоговую таблицу”

Представление запроса “Запрос за Итоговую таблицу” в форме SQL имеет следующий вид:

SELECT тПоверка.[Код поверки], тПоверка.[Код операции поверки], тПоверка.[Код лицензии лаборатории], тЛицензия.[Наименование лицензиата], тЛицензия.[Дата выдачи лицензии], тЛицензия.[Дата окончания лицензии], тПоверка.[Код счетчиков], тПоверка.[Вид поверки], тПоверка.Периодичность, тПоверка.[Дата поверки], тПоверка.[Дата предыдущей поверки], тПоверка.[Код поверяющего], тКонтролер.Имя, тКонтролер.Отчество, тКонтролер.Квалификация, тКонтролер.[Дата последней аттестации], тКонтролер.[Дата следующей аттестации], тПоверка.[Показание контролирующего]

FROM тКонтролер INNER JOIN (тЛицензия INNER JOIN тПоверка ON тЛицензия.[Код лицензии лаборатории] = тПоверка.[Код лицензии лаборатории]) ON тКонтролер.[Код контролера] = тПоверка.[Код поверяющего];

Здесь перечислены наименования полей, включаемые в запрос, указываются таблицы, из которой они извлекаются, а также описываются условия выборки, участвующий в формировании запроса. Вид связи INNERJOIN показывает, что в запросе объединяются только те записи таблиц “тПоверка”, “тЛицензия” и “тКонтролер”, в которых связанные поля обеих таблиц совпадают.

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

Рисунок 3.14- Схема запроса “Запрос на количество использования прибора”

Представление запроса “Запрос на количество использования прибора” в форме SQL имеет следующий вид:

SELECT тПоверяющееОборудование.[Наименование оборудования], тПоверяющееОборудование.Производитель, тОперацииПоверки.[Наименование параметра контроля], Count(тОперацииПоверки.[Наименование параметра контроля]) AS Количество

FROM тПоверяющееОборудование INNER JOIN тОперацииПоверки ON тПоверяющееОборудование.[Код поверяющего оборудование] = тОперацииПоверки.[Код контролирующего прибора]

GROUP BY тПоверяющееОборудование.[Наименование оборудования], тПоверяющееОборудование.Производитель, тОперацииПоверки.[Наименование параметра контроля];

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

Запрос“Запрос не используемых приборов” фильтрует информацию о приборах поверки, которые ни разу не использовались. Структура запроса “Запрос не используемых приборов” представлена следующей схемой:

Рисунок 3.15- Схема запроса “Запрос не используемых приборов”

Представление запроса “Запрос не используемых приборов” в форме SQL имеет следующий вид:

SELECT тПоверяющееОборудование.[Наименование оборудования], тПоверяющееОборудование.Производитель, тПоверяющееОборудование.[Класс точности прибора]

FROM тПоверяющееОборудование LEFT JOIN тОперацииПоверки ON тПоверяющееОборудование.[Код поверяющего оборудование] = тОперацииПоверки.[Код контролирующего прибора]

WHERE (((тОперацииПоверки.[Код контролирующего прибора]) IsNull));

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

Запрос “Запрос на таблицу Даты поверок” создает наглядную таблицу информации о датах поверки и данных контролеров, которая создается на базе подчинённого запроса. Структура запроса “Запрос на таблицу Даты поверок” представлена следующей схемой:

Рисунок 3.16- Схема запроса “Запрос на таблицу Даты поверок”

Представление запроса “Запрос на таблицу Даты поверок” в форме SQL имеет следующий вид:

TRANSFORM Last([Запрос* на Даты поверок].[Дата поверки]) AS [Last-Дата поверки]

SELECT [Запрос* на Даты поверок].[Код счетчиков]

FROM [Запрос* на Даты поверок]

GROUP BY [Запрос* на Даты поверок].[Код счетчиков]

PIVOT [Запрос* на Даты поверок].Фамилия;

Здесь создана таблица с помощью команды TRANSFORM. А наименования его полей, формируются на основе полей подчиненного запроса “Запрос* на Даты поверок”. И на основе этого создается наглядная таблица.

Структура запроса “Запрос* на Даты поверок” представлена следующей схемой:

Рисунок 3.17- Схема запроса “Запрос* на Даты поверок”

Представление запроса “Запрос* на Даты поверок” в форме SQL имеет следующий вид:

SELECT тПоверка.[Код счетчиков], тПоверка.[Дата поверки], тКонтролер.Фамилия

FROM тКонтролер INNER JOIN тПоверка ON тКонтролер.[Код контролера] = тПоверка.[Код поверяющего];

Здесь перечисленные наименование полей включаемые в запрос, указываются таблицы, из которых они извлекаются, а также описываются взаимосвязи таблиц, участвующие в формирование запроса. Вид связи INNERJOIN показывает, что в запросе объединяются только те записи таблиц “тПоверка” и “тКонтролер”, в которых связанные поля обеих таблиц совпадают.

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

Рисунок 3.18- Схема запроса “Многотабличный Запрос”

Представление запроса “Многотабличный Запрос” в форме SQL имеет следующий вид:

SELECT тПоверка.[Код счетчиков], тПоверка.[Код операции поверки], тПоверка.[Показание контролирующего], тОперацииПоверки.[Допустимое Мин_значение], тОперацииПоверки.[Допустимое Макс_значение]

FROM тОперацииПоверки INNER JOIN тПоверка ON тОперацииПоверки.[Код Операции] = тПоверка.[Код операции поверки];

Здесь перечислены наименования полей, включаемые в запрос, указываются таблицы, из которой они извлекаются, а также описываются условия выборки, участвующий в формировании запроса. Вид связи INNER JOIN показывает, что в запросе объединяются только те записи таблиц “тПоверка” и “тОперацииПоверки”, в которых связанные поля обеих таблиц совпадают.

Запрос“Неповерятые счетчики” фильтрует информацию о электросчетчиках, которые еще предстоит проверить. Структура запроса “Не поверятые счетчики” представлена следующей схемой:

Рисунок 3.19 - Схема запроса “Не поверятые счетчики”

Представление запроса “Не поверятые счетчики” в форме SQL имеет следующий вид:

SELECT тПоверяемоеОборудование.[Наименование счетчика], тПоверяемоеОборудование.[Класс счетчика], тПоверяемоеОборудование.Производитель, тПоверяемоеОборудование.[Дата изготовления]

FROM тПоверяемоеОборудование LEFT JOIN тПоверка ON тПоверяемоеОборудование.[Код заводской счетчика] = тПоверка.[Код счетчиков]

WHERE (((тПоверка.[Код счетчиков]) IsNull));

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

Запрос“СЗапрос на вид поверки” фильтрует информацию о видах поверкиэлектросчетчиков, которымимы конкретно в данный момент интересуемся. Структура запроса “СЗапрос на вид поверки” представлена следующей схемой:

Рисунок 3.20- Схема запроса “СЗапрос на вид поверки”

Представление запроса “СЗапрос на вид поверки” в форме SQL имеет следующий вид:

SELECT тПоверка.[Код операции поверки], тПоверка.[Код счетчиков], тПоверка.[Вид поверки], тПоверка.[Дата поверки], тПоверка.[Код поверяющего], тПоверка.[Показание контролирующего]

FROM тПоверка

WHERE (((тПоверка.[Вид поверки])=[Введите вид поверки]));

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

Запрос “Обновление дат” обновляет информацию о поверках электросчетчиков. Структура запроса “Обновление дат” представлена следующей схемой:

Рисунок 3.21- Схема запроса “Обновление дат”

Представление запроса “Обновление дат” в форме SQL имеет следующий вид:

UPDATE тПоверка SET тПоверка.[Дата поверки] = [Введите дату которую надо установить]

WHERE (((тПоверка.[Дата предыдущей поверки])=[Какую надо дату обновить]));

Запрос UPDATE показывает начало условия по поиску записей, в которой надо обновить поле в SQL коде.

Запрос “Удаление счетчиков” удаляет записи о электросчетчиках. Структура запроса “Удаление счетчиков” представлена следующей схемой:

Рисунок 3.22- Схема запроса “Удаление счетчиков”

Представление запроса “Удаление счетчиков” в форме SQL имеет следующий вид:

DELETE тПоверяемоеОборудование.[Дата изготовления]

FROM тПоверяемоеОборудование

WHERE (((тПоверяемоеОборудование.[Дата изготовления])<=[До какой даты удалить счетчики]));

Запрос DELETE показывает начало условия по удалению в SQL коде.

3.6 Структурная схема форм

Главная форма для администратора, которая сделана так, чтоб легко было взаимодействовать со всей базой данных, и редактировать ее. Структура формы “Главная кнопочная форма Администратора” представлена следующей схемой:

Рисунок 3.23- Схема формы “Главная кнопочная форма Администратора”

Главная форма для контролера, которая сделана так, чтоб легко было взаимодействовать базой данных контролеру, и редактировать ее. Структура формы “Главная кнопочная форма Контролера” представлена следующей схемой:

Рисунок 3.24- Схема формы “Главная кнопочная форма Контролера”

Главная форма для проверяющего, которая сделана так, чтоб легко было взаимодействовать базой данных проверяющего, и следить с помощью ее за деятельностью учреждения. Структура формы “Главная кнопочная форма Проверяющего” представлена следующей схемой:



Рисунок 3.25- Схема формы “Главная кнопочная форма Проверяющего”

Главная форма для управляющего, которая сделана так, чтоб легко было взаимодействовать базой данных управляющего, и редактировать ее, а также проверять деятельность контролера. Структура формы “Главная кнопочная форма Управляющего” представлена следующей схемой:

Рисунок 3.26- Схема формы “Главная кнопочная форма Управляющего”

Форма фильтрует информацию в зависимости от выбранного контролера и выводит его статистику о поверках, которые расположены в более удобной форме. Структура формы “Карточка контролера” представлена следующей схемой:

Рисунок 3.27- Схема формы “Карточка контролера”

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

Структура формы “подчиненная форма Карточки контролера” представлена следующей схемой:

Рисунок 3.28- Схема формы “подчиненная форма Карточки контролера”

Здесь информация о счетчики представлена самой важной информацией о них. Вся информация представлена в компактном виде.

Форма выводит всю имеющуюся информацию из таблиц, имеющихся в БД. Структура формы “Карточка счетчика” представлена следующими схемами:

Рисунок 3.29- Схема формы “Карточка счетчика”

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

Форма фильтрует информацию о все таблица имеющих в БД, которые расположены в более удобной форме. Структура формы “Форма Архив” представлена следующими схемами:



Рисунок 3.30а - Схема формы “Форма Архив”

Рисунок 3.30б - Схема формы “Форма Архив”

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

Форма создана для того, что более удобно можно было разграничивать права пользователей в базе данных. Структура формы “Форма Вход” представлена следующими схемами:

Рисунок 3.31- Схема формы “Форма Вход”

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

Форма создана для удобной регистрации новых пользователей в базе данных и определения своего уровня прав в базе. Структура формы “Форма Регистрация” представлена следующими схемами:

Рисунок 3.32- Схема формы “Форма Регистрация”

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

Форма позволяет легко внести в БД информацию о новом счетчики. Структура формы “Форма Регистрации нового счетчика” представлена следующими схемами:

Рисунок 3.33- Схема формы “Форма Регистрации нового счетчика”

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

Форма фильтрует информацию о все таблица имеющих в БД, которые расположены в более удобной форме. Структура формы “Форма Регистрации новой поверки” представлена следующими схемами:



Рисунок 3.34- Схема формы “Форма Регистрации новой поверки”

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

3.7 Структурная схема отчетов

Отчет выводит информацию о поверяющем оборудование, которое имеется в учреждение. Структура запроса “Карточки Поверяющего Оборудования” представлена следующей схемой:

Рисунок 3.35- Схема отчета в конструкторе “Карточки Поверяющего Оборудования”

В форме представление отчета “Карточки Поверяющего Оборудования” имеет следующий вид:

Рисунок 3.36- Схема в форме представления отчета “Карточки Поверяющего Оборудования”

Здесь перечислены наименования полей, взятые из таблицы “тПоверяющееОборудование”, и представленные в виде актуального на текущее время отчета “Карточки Поверяющего Оборудования”. Отчет представлен таким образом, чтоб всю информацию можно был легко напечатать в удобной форме. С полезной сопутствующей информацией такой как: время распечатки, чтоб знать о дате формирования текущего отчета, количество страниц и текущая страница, чтоб было легко собрать весь отчет вместе или найти быстро интересующую страницу.

Отчет создает краткую информацию о поверке электросчетчика, которая распечатается и клеится на электросчетчики. Структура запроса “Наклейки Поверка” представлена следующей схемой:



Рисунок 3.37- Схема отчета в конструкторе “Наклейки Поверка”

В форме представление отчета “Наклейки Поверка” имеет следующий вид:

Рисунок 3.38- Схема в форме представления отчета “Наклейки Поверка”

Здесь перечислены наименования полей, взятые из запроса “Наклейки Поверка”, и представленные в виде актуального на текущее время отчета “Наклейки Поверка”. Отчет представлен таким образом, чтоб всю информацию было легко напечатать и поместить на электроприбор.

Отчет фильтрует информацию о электросчетчиках, которые надо поверить в текущем году. Структура запроса “Отчет за текущий год” представлена следующей схемой:

Рисунок 3.39- Схема отчета в конструкторе “Отчет за текущий год”

В форме представление отчета “Отчет за текущий год” имеет следующий вид:

Рисунок 3.40- Схема в форме представления отчета “Отчет за текущий год”

Здесь перечислены наименования полей, взятые из запроса “Запрос за текущий год”, и представленные в виде актуального на текущее время отчета “Отчет за текущий год”. Отчет представлен таким образом, чтоб всю информацию из одноименного запроса было легко напечатать в удобной форме. С полезной сопутствующей информацией такой как: время распечатки, чтоб знать о дате формирования текущего отчета, количество страниц и текущая страница, чтоб было легко собрать весь отчет вместе или найти быстро интересующую страницу.

Отчет фильтрует информацию о электросчетчиках, которые надо поверить в текущем месяце. Структура запроса “Отчет за текущий месяц” представлена следующей схемой:

Рисунок 3.41- Схема отчета в конструкторе “Отчет за текущий месяц”

В форме представление отчета “Отчет за текущий месяц” имеет следующий вид:

Рисунок 3.42- Схема в форме представления отчета “Отчет за текущий месяц”

Здесь перечислены наименования полей, взятые из запроса “Отчет за текущий месяц”, и представленные в виде актуального на текущее время отчета “Отчет за текущий месяц”. Отчет представлен таким образом, чтоб всю информацию из одноименного запроса было легко напечатать в удобной форме. С полезной сопутствующей информацией такой как: время распечатки, чтоб знать о дате формирования текущего отчета, количество страниц и текущая страница, чтоб было легко собрать весь отчет вместе или найти быстро интересующую страницу.

Отчет создает информацию о поверке электросчетчика, которую потом можно распечатать. Структура запроса “Отчет о поверке” представлена следующей схемой:

Рисунок 3.43- Схема отчета в конструкторе “Отчет о поверке”

В форме представление отчета “Отчет о поверке” имеет следующий вид:

Рисунок 3.44- Схема в форме представления отчета “Отчет о поверке”

Здесь перечислены наименования полей, взятые из запроса “Запрос за Итоговую таблицу”, и представленные в виде актуального на текущее время отчета “Отчет о поверке”. Отчет представлен таким образом, чтоб всю информацию из одноименного запроса было легко напечатать в удобной форме. С полезной сопутствующей информацией такой как: время распечатки, чтоб знать о дате формирования текущего отчета, количество страниц и текущая страница, чтоб было легко собрать весь отчет вместе или найти быстро интересующую страницу.

Отчет выводит краткую информацию о поверяющем оборудование, которое имеется в учреждение. Структура запроса “Отчет Поверяющее Оборудование” представлена следующей схемой:

Рисунок 3.45- Схема отчета в конструкторе “Отчет Поверяющее Оборудование”

В форме представление отчета “Отчет Поверяющее Оборудование” имеет следующий вид:

Рисунок 3.46- Схема в форме представления отчета “Отчет Поверяющее Оборудование”

Здесь перечислены наименования полей, взятые из таблицы “тПоверяющееОборудование”, и представленные в виде краткого актуального на текущее время отчета “Отчет Поверяющее Оборудование”. Отчет представлен таким образом, чтоб всю информацию из одноименного запроса было легко напечатать в удобной форме. С полезной сопутствующей информацией такой как: время распечатки, чтоб знать о дате формирования текущего отчета, количество страниц и текущая страница, чтоб было легко собрать весь отчет вместе или найти быстро интересующую страницу.

Отчет выводит информацию о поверке электросчетчика, которые оформлены в виде сертификата. Структура запроса “Отчет Сертификата” представлена следующей схемой:

Рисунок 3.47- Схема отчета в конструкторе “Отчет Сертификата”

В форме представление отчета “Отчет Сертификата” имеет следующий вид:



Рисунок 3.48- Схема в форме представления отчета “Отчет Сертификата”

Здесь перечислены наименования полей, взятые из таблицы “тПоверка”, и представленные в виде актуального на текущее время отчета “Отчет Сертификата”. Отчет представлен таким образом, чтоб всю информацию из одноименного запроса было легко напечатать в удобной форме. С полезной сопутствующей информацией такой как: время распечатки, чтоб знать о дате формирования текущего отчета, количество страниц и текущая страница, чтоб было легко собрать весь отчет вместе или найти быстро интересующую страницу. Этот сертификат подтверждает факт поверки.

3.8 Защита базы данных с помощью логина и пароля

Чтобы предотвратить несанкционированный доступ к базе данных Access, ее защищают уникальные данные такие, как Логин и Пароль известные только владельцу данных. Чтобы войти в базу данных и начать работать с базой данных, сотрудник вводит свои данные и проходит индикацию данных. Если данные совпадают, то ему доступ разрешен, и он получает доступ к данным соответствующий его классу доступа.

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

При открытии базы данных появится диалоговое окно,в которую надо ввести логин и пароль и нажать кнопку OK.

Пример открытия базы данных показан на рисунке 3.43.

Рисунок 3.49 -Диалоговое окно открытия базы данных.

4. Экономическое обоснование системы

4.1 Общая информация о системе

Главной целью данного проекта является организация базы данных в ФБУ«Пятигорский ЦСМ» с целью предоставления более удобного доступа к данным учреждения.

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

Основными целями, которые ставит перед собой руководство компании, являются:

· создать удобную и простую базу данных;

· получение самоокупаемую систему.

4.2 План анализа экономической эффективности

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

Произведем расчет экономической эффективности проекта. План анализа экономической эффективности при создании программного обеспечения следующий:

· Технико-экономическое обоснование разработки программного обеспечения

· Общие расходы на реализацию системы

· Эффективность внедрения для организации

4.3 Технико-экономическое обоснование разработки программного обеспечения

Таблица 4.1 - Фазы проектирования и разработки

Фаза	Содержание работ	Трудоемкость
		дни	%
Начальная стадия	Сбор информации, анализ требований	19	0,2
Стадия проектирования	Анализ требований и проектирование системы, планирование необходимых ресурсов	27	0,29
Разработка	Разработка информационной системы	40	0,43
Внедрение	Тестирование, обучение пользователей	7	0,08
Итого		93	100,00

Общая трудоемкость разработки программного обеспечения рассчитывается по формуле:

(4.1)

где Т_об- общая трудоемкость разработки, дни;

Т_i - трудоемкость по стадиям, дн;

n - количество стадий разработки.

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

4.4 Общие расходы на реализацию системы

Затраты на эксплуатацию данной системы определяются по формуле:

(4.2)

где Р - расходы на разработку;

Е - единовременные выплаты;

Н - накладные затраты;

4.4.1 Общие расходы на реализацию системы

Текущие расходы на разработку данной системы рассчитываются по формуле:

(4.3)

где Ф_от - фонд оплаты труда;

О_С - отчисления на соц. нужды;

А_о - амортизационные отчисления;

Э - электроэнергия для производственных нужд;

Фонд оплаты труда

Затраты по оплате труда состоят из основной и дополнительной заработных плат и рассчитываются по формуле:

(4.4)

где З_осн - основная заработная плата,

З_доп - дополнительная заработная плата.

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

Среднедневная заработная плата разработчика определена из расчета 27500руб. в месяц и равна:

З_{ср. дн. р} =27 500/22=1250руб./день

Получаем, заработная плата при проектировании и разработке равна:

З_осн =1 250*93 = 116250руб.

Дополнительная заработная плата составляет 10% от основной заработной платы и рассчитывается по формуле:

(4.5)

З_доп=0,1*116 250= 11 625руб.

Общий фонд оплаты труда за год составит:

Ф_от=116250 + 11625 =127875руб.

Социальный налог (30,2)

Отчисления на социальные нужды составляют на сегодняшний день 30.2%от общего фонда заработной платы, следовательно:

О_с= Ф_от*0,302 = 127875*0,302 = 38 618,25руб. (4.6)

Расчет затрат на амортизацию

Общие амортизационные отчисления берутся исходя из суммы всех амортизаций:

(4.7)

где А_о-общая амортизации;

А_м-машинная амортизации;

А_и-инструментальная амортизации;

Тогда машинные амортизационные отчисления составляют:

(4.8)

где А_м - амортизационные отчисления, руб.;

О_ф - стоимость ЭВМ и оборудования, руб.;

Н_ам - норма амортизации (принято 20%), %;

Т_м - время использования оборудования, дни

А_М = (30 000 * 20 * 67) / (365 * 100) = 40 200 000 / 36 500 = 1 101,37руб.

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

Норма амортизации для системного программного обеспечения 30%, а время применения 67 дня.

Использованные средства представлены в таблице 4.2.

Таблица 4.2 - Инструментальные средства

Наименование продукта	Стоимость (руб.)
MicrosoftOffice 2016	18 900
Итого	18 900

Рассчитаем амортизацию инструментального средства:

(4.9)

где А_м - амортизационные отчисления, руб.;

О_ф - стоимость ЭВМ и оборудования, руб.;

Н_ам - норма амортизации (принято 30%), %;

Т_м - время использования оборудования, дни

А_И = ((18 900 * 30) / (365 * 100)) * 67 = (567 000 / 36 500) * 67 = 15,53 * * 67 = 1 040,51руб.

Следовательно,

А_о = 1 101,37 + 1 040,51 = 2 141,88руб.

Расчет затрат на электроэнергию

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

, (4.10)

где З_{эл.обор.} - затраты на электроэнергию для оборудования;

З_{доп.нуж.} - затраты на дополнительные нужды;

Затраты электроэнергии на оборудование рассчитывается следующим образом:

Стоимость затрат электрооборудования З_{эл.обор.} зависит от себестоимости машино-часа работы ЭВМ С_МЧ, а также времени работы на ЭВМ Т_ЭВМ.

Себестоимость машино-часа ЭВМ равна:

С_ЭВМ=0,8 кВт/час * 4,16руб/кВт = 3,33руб./час

Время использования оборудования:

Т_ЭВМ=0,32*Т_общ+0,7*Т_проект+0,91*Т_реал+0,48*Т_внед=0,32*19++0,7*27+0,91*40+0,48*7=6,08 + 18,9 + 36,4 +3,36=64,74(дней) = =64,74 *8= 517,92(часов).

Затраты на электроэнергию:

З_{эл.обор.}= 517,92часов * 3,33руб./час=1724,67руб.

Затраты на дополнительные нужды составляют 5% от затрат на электроэнергию оборудования и рассчитываются по формуле:

(4.11)

где З_{ЭЛ.ОБОР} - затраты на электроэнергию для оборудования;

Затраты на электроэнергию для дополнительных нужд:

З_{доп.нуж.} = 0,05 * 1724,67= 86,23руб.

Тогда суммарные затраты на электроэнергию будут равны:

Э = 1724,67+ 86,23 = 1810,9руб.

Итак, план затрат на разработку приведен в таблице 4.3.

Таблица 4.3 - Разделение затрат по видам.

Вид затрат	Затраты (руб.)
Заработная плата	127875
Отчисления на социальные нужды	38 618,25руб.
Амортизационные отчисления	2 141,88
Затраты на электроэнергию	1 810,9
Итого	170 446,03

4.4.2 Стоимость внедрения программного обеспечения организацией

К единовременным затратам пользователя программного обеспечения относятся затраты на оплату:

· программного обеспечения Ц_по;

· инструментальных средств Ц_ис;

· обучение сотрудников К_осв.

Текущие расходы на разработку данной системы рассчитываются по формуле:

(4.12)

Стоимость программного обеспечения.

Стоимость программного обеспечения равна сумме себестоимости и прибыли разработчика (обычно составляет 20% себестоимости), а также налог на добавленную стоимость, который составляет 18%. Для расчета можно использовать следующую формулу

Ц_по= С_по + П + НДС, (4.13)

где С_по- себестоимость программного обеспечения,

П - прибыль разработчика,

НДС - налог на добавленную стоимость.

Следовательно, стоимость программного обеспечения составляет:

С_по=170 446,03руб.

НДС = 170 446,03*18% =30 680,29руб.

П = 170 446,03* 20% = 34 089,21руб.

Ц_по= 170 446,03+ 30 680,29 + 34 089,27 = 235 215,59руб.

Стоимость инструментальных средств

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

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

Стоимость обучения сотрудников организации.

Расчет производится по следующей формуле:

К_осв=Ч_пп*С_осв*t_осв, (4.14)

где Ч_пп - численность сотрудников на обучение,

С_осв - стоимость обучения одного сотрудника в день,

t_осв - время обучения.

Фактически в организации информационной системой будут пользоваться 20 сотрудников. Время необходимое для обучения приблизительно оценивается в семь рабочих дней для каждого. Стоимость обучения одного сотрудника в день составляет 1 250 рублей. В итоге получается затраты на обучение персонала:

К_осв= 20 * 1 250 * 7 = 175 000 руб.

Суммарные затраты для организации представлены в таблице 4.4.

Таблица 4.4 - Суммарные затраты для организации

Вид затрат	Затраты (руб.)
Цена программного обеспечения	235 215,59
Обучение персонала	175 000
Итого	410 215,59

4.4.3 Накладные расходы, общие затраты и инвестиционный план

Накладные расходы составляют 75 % от всех затрат и рассчитываются по формуле:

(4.15)

Тогда накладные затраты составят:

Н=0,75*(235 215,59 + 175 000)= 0,75 * 410 215,59 = 307 661,7руб.

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

Таблица 4.5 - Расход по проектированию системы

Показатель	Сумма руб.
Расходы на разработку	170 446,03
Единовременные выплаты	410 215,59
Накладные расходы	307 661,7
ИТОГО	888 323,32

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

Таблица 4.6 - Этапы реализации проекта

Этапы реализации	Январь	Февраль	Март	Апрель	Май
Начальная стадия	17	2
Стадия проектирования		16	11
Разработка			11	20	9
Внедрение					7

Составим инвестиционный план, с более детальными денежными инвестициями.

Таблица 4.6 - Инвестиционный план

Этапы реализации	Январь	Февраль	Март	Апрель	Май
Начальная стадия	162 381,68	19 103,72	0	0	0
Стадия проектирования	0	152 829,76	105 070,46	0	0
Разработка	0	0	105070,46	191 037,2	85 966,74
Внедрение	0	0			66 863,02
Итого	162 381,68	171 933,51	210 140,92	191 037,2	152 829,76

4.5 Эффективность внедрения для организации

Оценивая повседневную работу ФБУ«Пятигорский ЦСМ», постараемся оценить экономический эффект от внедрения информационной системы учета расходных материалов и комплектующих.

Диспетчер сервисного центра ежедневно в среднем оформляет 15 заявок в день. Стоимость таких запросов составляет в среднем 1 400руб. в день, что составит в месяц 21000руб. Безусловно, количество совершаемых ежедневно заявок и их стоимость не может быть постоянной величиной.

Возьмем 21 000руб. как среднее ежедневное значение, тогда за месяц будет:

Д = 21 000 * 22 = 462 000руб.

Срок окупаемости информационной системы по учету расходных материалов и комплектующих при затратах на разработку и внедрение 908 040,05 рублей.

Определим срок окупаемости по формуле:

С_ок=888 323,32/462 000 = 1,9 месяца.

Получаем, что через 1,9 месяца информационная система полностью себя окупит, значит, применение разработки является эффективным.

В ходе вычислений были получены результаты:

· Рассчитаны затраты на разработку - 888 323,32 рублей;

· Рассчитан экономический эффект от внедрения - 462 000 рублей;

· Срок окупаемости системы составляет 1,9 месяца.

5. Безопасность и экологичность системы

5.1 Анализ условий труда исследователя

Данная система была исследована на персональном компьютере типа IBMPC. Рассмотрим условия труда в помещении, характеризующиеся совокупностью факторов производственной сферы, оказывающих определенное воздействие на здоровье и работоспособность человека в процессе труда. Под условиями работы подразумевают комплекс физических, химических и психофизиологических факторов, установленных стандартами по безопасности труда (ССБТ).