База данных комиссионное вознаграждение отдела продаж

Содержание. 1. ВВЕДЕНИЕ. 2. ТЕОРИТИЧЕСКАЯ ЧАСТЬ. 2.1. Классификация информационных систем 2.2. Варианты построения информационных приложений
2.2.1. Файл-серверные приложения 2.2.2. Приложения клиент-сервер 2.2.3. Информационные системы на основе Internet/Intranet-технологии 2.3. Модели данных 2.3.1. Иерархическая модель 2.3.2. Сетевая модель. 2.3.3. Реляционная модель. 3. ПОСТАНОВКА ЗАДАЧИ. 4. РЕАЛИЗАЦИЯ ПОСТАВЛЕННОЙ ЗАДАЧИ. 4.1. Преимущества использования архитектуры «клиент-сервер». 4.2. Выбор модели данных. 4.3. Выбор СУБД и средства разработки базы данных. 4.3.1. Новый формат проектов Access. 4.3.2. ODBC и OLE DB 4.4. Проектирование. 4.4.1. Определение сущностей 4.4.2. Определение взаимосвязей между сущностями 4.4.3. Задание первичных ключей, определение атрибутов сущностей 4.5. Схема данных. 4.6. Описание работы информационной системы. 4.6.1. Описание интерфейса. 4.6.2. Техническое описание работы информационной системы. 4.6.3. Защита информационной системы. 5. ЭКОНОМИЧЕСКАЯ ЧАСТЬ. 6. ЭКОЛОГИЧЕСКАЯ ЧАСТЬ. 6.1. Характеристика санитарно-гигиенических условий труда 6.2. Электрическая безопасность 6.3. Пожарная безопасность 6.4. Требования к рабочему месту программиста и режимам работы 7. ЗАКЛЮЧЕНИЕ. 8. СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ.
1. Введение. 28 января 2002 года утвержден постановлением правительства Российской Федерации окончательный проект Федеральной Целевой Программы «Электронная Россия (2002 – 2010 годы)». «Развитие и широкое применение информационных и коммуникационных технологий (далее именуются - ИКТ) является глобальной тенденцией мирового развития и научно-технической революции последних десятилетий. Применение ИКТ имеет решающее значение для повышения конкурентоспособности экономики, расширения возможностей ее интеграции в мировую систему хозяйства, повышения эффективности государственного управления и местного самоуправления».[1] Важнейшее место в современных информационных технология занимают хранилища данных различного уровня от маленьких «настольных» баз данных до огромных корпоративных цифровых хранилищ. В настоящей работе хотелось бы остановиться более подробно на решениях, которые рассчитаны на использование в компаниях среднего масштаба. Компания «Вэб Плас» - крупнейший Интернет провайдер в Санкт-Петербурге относится к классу организаций, где используются хранилища данных различного уровня. Существуют большая информационная система, отвечающая задачам компании в целом, но параллельно с ней соседствуют решения на базе Microsoft Office, помогающие работать с информацией внутри подразделений компании, например, в рамках коммерческого отдела, именно на это подразделение будет обращено внимание в настоящей работе.
2. Теоритическая часть. 2.1. Классификация информационных систем Информационные системы, прежде всего, различаются по масштабу на одиночные, групповые и корпоративные. Одиночные информационные системы реализуются на автономном компьютере, как правило, ПК. Такая система может содержать несколько простых приложений, связанных общим информационным фондом, и рассчитана на работу одного пользователя или группы пользователей, разделяющих по времени одно рабочее место. Подобные приложения создаются с помощью так называемых "настольных СУБД" (Clarion, Clipper, FoxPro, Paradox, dBase, MS Access) или с помощью файловой системы и диалоговой оболочки для ввода, редактирования и обработки данных. Групповые информационные системы ориентированы на коллективное использование информации членами рабочей группы (одного подразделения), чаще всего строятся как локальная вычислительная сеть ПК или реже как многотерминальная централизованная вычислительная система. Однотипные или специализированные рабочие места обеспечивают вызов одного или нескольких конкретных приложений. Общий информационный фонд представляет собой базу данных или совокупность файлов документов. Совместное использование информации организуется с помощью блокировок записей и файлов. При разработке таких приложений используются многопользовательские "настольные СУБД", серверы БД для рабочих групп (Btrieve, NetWare SQL, Gupta SQLBase, Sybase Anywhere SQL, MS SQL Server, Progress, Informix-SE, Workgroup Oracle и др.) и соответствующие инструменты разработки или системы управления документами и их инструментальные средства. Взаимодействие пользователей происходит через централизованную базу данных или посредством сетевой файловой системы или через электронную почту. Корпоративные информационные системы являются развитием систем для рабочих групп и ориентированы на масштаб предприятия, могут поддерживать территориально разнесенные узлы или сети. Они могут иметь иерархическую структуру из нескольких уровней. Главная особенность - обеспечение доступа из подразделения к центральной или распределенной базе данных предприятия (организации) помимо доступа к информационному фонду рабочей группы. Для таких систем характерна архитектура клиент-сервер со специализацией серверов. Они строятся на корпоративных SQL-серверах БД (Oracle7, Informix-OnLine, Informix- DSA, Sybase, CA-Ingress и др.) и соответствующих инструментальных средствах. Помимо собственных средств разработки часто находят применение независимые многоплатформенные инструментальные средства, дополненные интерфейсами, драйверами и шлюзами для связи с разными СУБД. Для таких систем повышаются требования к надежности функционирования и сохранности данных. Последнее свойство обеспечивается поддержкой целостности данных, ссылок и транзакций в серверах баз данных. Транзакция представляет собой неделимый набор операций с БД, она завершается успешно, когда выполнены все ее операции, в противном случае происходит откат в состояние, предшествующее выполнению транзакции. По оперативности обработки данных различают пакетные и оперативные информационные системы (реального времени). Информационные системы с пакетной обработкой в чистом виде можно встретить на больших централизованных ЭВМ. В информационных системах организационного управления преобладает режим оперативной обработки транзакций OLTP (OnLine Transaction Processing) для отражения актуального состояния предметной области в любой момент времени, а пакетная обработка занимает весьма ограниченную нишу. Для систем OLTP характерен регулярный (возможно, интенсивный) поток довольно простых транзакций, играющих роль заказов, платежей, запросов и т. п. Важными требованиями являются высокая производительность обработки транзакций и гарантированная доставка информации при удаленном доступе к БД по телекоммуникациям.
2.2. Варианты построения информационных приложений Групповые и корпоративные информационные системы и соответствующие приложения могут строиться различными способами: ü системы на основе локальной сети ПК (файл-серверные приложения); ü системы с архитектурой клиент-сервер;
ü системы на основе Internet/Intranet-технологий. Для лучшего понимания ограничений различных архитектур информационных систем, разделим приложения на типовые компоненты: PS (Presentation Services) - средства представления. Обеспечиваются устройствами, принимающими ввод от пользователя и отображающим то, что сообщает ему компонент логики представления PL, плюс соответствующая программная поддержка. Может быть текстовым терминалом или Х-терминалом, а также ПК или рабочей станцией в режиме программной эмуляции терминала или Х-терминала. PL (Presentation Logic) - логика представления. Управляет взаимодействием между пользователем и ЭВМ. Обрабатывает действия пользователя по выбору альтернативы меню, по нажатию кнопки или при выборе элемента из списка. BL (Business or Application Logic) - прикладная логика. Набор правил для принятия решений, вычислений и операций, которые должно выполнить приложение. DL (Data Logic) - логика управления данными. Операции с базой данных (SQL-операторы SELECT, UPDATE и INSERT), которые нужно выполнить для реализации прикладной логики управления данными. DS (Data Services) - операции с базой данных. Действия СУБД, вызываемые для выполнения логики управления данными, такие как манипулирование данными, определения данных, фиксация или откат транзакций и т. п. СУБД обычно компилирует SQL-предложения. FS (File Services) - файловые операции. Дисковые операции чтения и записи данных для СУБД и других компонент. Обычно являются функциями ОС. Можно привести несколько схем построения информационных систем в зависимости от размещения типовых компонентов приложения по узлам сети. 2.2.1. Файл-серверные приложения Системы "файл-сервер" (Рисунок 1) не имеет сетевого разделения компонентов диалога PS и PL, использует ПК для функций отображения, что облегчает построение графического интерфейса. Файл-сервер только извлекает данные из файлов, так что дополнительные пользователи и приложения добавляют лишь незначительную нагрузку на ЦП. Каждый новый клиент добавляет вычислительную мощность к сети. Рисунок 1. «Варианты построения файл-серверных приложений» Объектами разработки в файл-серверном приложении являются компоненты приложения, определяющие логику диалога PL, а также логику обработки BL и управления данными DL. Разработанное приложение реализуется либо в виде законченного загрузочного модуля или в виде специального кода для интерпретации. Однако такая архитектура имеет два основных недостатка: некоторые запросы к БД могут перекачивать всю БД клиенту, загружая сеть и имея непредсказуемое время реакции, тем самым, создавая значительный сетевой график, а также возникающая проблема "толстого клиента" - Windows-интерфейс, коды приложения и СУБД могут перегрузить даже мощный ПК. Первый недостаток особенно сказывается при организации удаленного доступа к базам данных на файл- сервере через низкоскоростные каналы связи. В этом случае система с удаленными рабочими станциями оказывается практически неработоспособной. В данном случае единственное решение - удаленное управление файл-серверным приложением в сети. В локальной сети ставится сервер приложений, совмещенный с телекоммуникационным сервером (сервер доступа). В многозадачной среде этого сервера выполняются обычные файл-серверные приложения. Особенность состоит в том, что диалоговый ввод-вывод поступает через телекоммуникации от удаленных клиентов. Приложения не должны быть слишком сложными, иначе шансы перегрузки сервера увеличиваются, или же нужна очень мощная платформа для сервера приложений. На клиентских узлах работают программы удаленного управления или эмуляции терминалов, которые передают сигналы от клавиатуры и мыши серверу приложений, а в ответ получают копии экранов и отображают их на видеомониторе. Помимо перечисленных недостатков нужно отметить, что многие "настольные СУБД", как традиционные инструменты файл-серверных приложений, не отвечают требованиям сохранности данных, в частности не поддерживают транзакции. Однако СУБД для ПК привлекают простотой использования и доступностью, поэтому файл-серверные приложения еще будут использоваться для рабочих групп. Основой разработки файл-серверных приложений для локальных сетей ПК является инструментальное окружение различных "персональных" СУБД: FoxPro, Clipper, Paradox, Clarion, Paradox, dBase и т. п. 2.2.2. Приложения клиент-сервер Архитектура клиент-сервер предназначена для разрешения проблем файл-серверных приложений путем разделения компонентов приложения и размещение их там, где они будут функционировать более эффективно. Особенностью архитектуры клиент-сервер является использование выделенных серверов баз данных, понимающих запросы на языке структурированных запросов SQL и выполняющих поиск, сортировку и агрегирование информации на месте без излишней перекачки данных на рабочие станции. Другая отличительная черта серверов БД - наличие справочника данных, в котором записаны структура БД, ограничения целостности данных, форматы и даже серверные процедуры обработки данных по вызову или по событиям в программе. Объектами разработки в таких приложениях помимо диалога и логики обработки являются, прежде всего, реляционная модель данных и связанный с ней набор SQL-операторов для типовых запросов для этой БД. Большинство конфигураций клиент-сервер использует двухзвенную модель, состоящую из клиента, который обращается к услугам сервера (рисунок 2). Для эффективной реализации такой схемы часто применяют неоднородную сеть. Как минимум, предполагается, что диалоговые компоненты PS и PL размещаются на клиенте, что позволяет обеспечить графический интерфейс. Далее возможно разместить компоненты управления данными DS и FS на сервере, а диалог (PS, PL), логику BL и DL на клиенте. Типовое определение архитектуры клиент-сервер - приложение на клиенте, СУБД - на сервере - использует эту схему. Рисунок 2. «Варианты построения приложения клиент-сервер» Поскольку эта схема предъявляет наименьшие требования к серверу, она обладает наилучшей масштабируемостью. Однако сложные приложения, вызывающие большое взаимодействие с БД, могут жестко загрузить как клиента, так и сеть. Результаты SQL-запроса должны вернуться клиенту для обработки, потому что там находится логика принятия решения. Такая схема возлагает дополнительное бремя администрирования приложений, разбросанных по различным клиентским узлам.
Можно сократить нагрузку на клиента и сеть, переместив целиком компонент BL на сервер, при этом вся логика принятия решений оформлена в виде хранимых процедур и выполняется на сервере БД. Хранимая процедура - процедура с операторами SQL для доступа к БД, вызываемая по имени с передачей требуемых параметров и выполняемая на сервере БД. Компиляция повышает скорость исполнения хранимых процедур и сокращает нагрузку на сервер. Но, перегрузив хранимые процедуры прикладной логикой, можно потерять преимущества по производительности. Хранимые процедуры улучшают целостность приложений и БД, гарантируют актуальность коллективно используемых операций и вычислений. Улучшается сопровождение таких процедур, а также безопасность (нет прямого доступа к данным).
Переместив с клиента часть логики приложения на сервер, получим систему клиент-сервер с разделенной логикой. Часть прикладной логики может быть реализована на клиенте, а другая часть логики - в виде обработчиков событий (триггеров) и хранимых процедур на сервере БД. Такая схема при удачном разделении логики приводит к сбалансированной загрузке клиентов и сервера, но при этом затрудняется сопровождение приложений. 2.2.3. Информационные системы на основе Internet/Intranet-технологии Изначально технология Internet/Intranet/ WWW предназначалась для облегчения доступа к информации и публикации документов. Программа-клиент выполняет функции интерфейса пользователя и обеспечивает доступ практически ко всем информационным ресурсам Internet. База данных HTML-документов - это часть файловой системы, которая содержит текстовые файлы в формате гипертекста и связанные с ними графику и другие ресурсы. Фактически браузер является интерпретатором HTML-текста. И, как типичный интерпретатор, клиент в зависимости от команд разметки выполняет различные функции. В круг этих функций входит не только размещение текста на экране, но и обмен информацией с сервером по мере анализа полученного HTML-текста, что наиболее наглядно происходит при отображении встроенных графических образов. При анализе URL-спецификаций или по командам сервера клиент запускает дополнительные внешние программы для работы с документами в форматах, отличных от HTML, например GIF, JPEG, MPEG, Postscript и т. п. В последнее время все большее распространение получает механизм согласования запускаемых программ через MIME-типы. До недавнего времени сеть Internet была "улицей с односторонним движением" - информация с Web-страниц поступала к пользователю от Web-сервера при наличии запроса. Обратная связь с пользователем - анкетные листы и параметры запроса для работы поисковых систем. При этом программирование серверной части осуществляется с использованием CGI-скриптов. Если Web-сервер использует традиционные статичные Web-страницы, то в ответ на запрос клиента Web-сервер передает страницу в формате HTML. Однако при работе с приложениями базы данных адрес URL указывает не на Web-страницу, а на программу или сценарий, который запускает запрос к базе данных и преобразует результаты в формат HTML. Затем Web-сервер посылает полученную HTML-страницу Web-клиенту. Так как этот процесс основан на технологии Web, клиентской платформой может стать любой компьютер, на котором исполняется Web-браузер, а серверной платформой - любая ЭВМ под управлением Web-сервера. 2.3. Модели данных Существует несколько моделей данных, полагаемых в основу информационных систем. Наиболее часто используются следующие три: иерархическая, сетевая и реляционная. Остановимся подробнее на этих моделях. 2.3.1. Иерархическая модель Первые иерархические и сетевые СУБД были созданы в начале 60-х годов. Причиной послужила необходимость управления миллионами записей (связанных друг с другом иерархическим образом), например при информационной поддержке лунного проекта Аполлон. Отношения в иерархической модели данных организованы в виде совокупностей деревьев, где дерево - структура данных, в которой тип сегмента потомка связан только с одним типом сегмента предка. Графически: Предок - точка на конце стрелки, а Потомок - точка на острие стрелки. В базах данных определено, что точки - это типы записей, а стрелки представляют отношения один - к - одному или один - ко - многим. К ограничениям иерархической модели данных можно отнести: § Отсутствует явное разделение логических и физических характеристик модели; § Для представления неиерархических отношений данных требуются дополнительные манипуляции; § Непредвиденные запросы могут требовать реорганизации базы данных. 2.3.2. Сетевая модель. Сети - естественный способ представления отношений между объектами. Они широко применяются в математике, исследованиях операций, химии, физике, социологии и других областях знаний. Сети обычно могут быть представлены математической структурой, которая называется направленным графом. Направленный граф имеет простую структуру. Он состоит из точек или узлов, соединенных стрелками или ребрами. В контексте моделей данных узлы можно представлять как типы записей данных, а ребра представляют отношения один-к-одному или один-ко-многим. Структура графа делает возможными простые представления иерархических отношений (таких, как генеалогические данные). Сетевая модель данных - это представление данных сетевыми структурами типов записей и связанных отношениями мощности один-к-одному или один-ко-многим. В сетевой модели существует две основные структуры данных: типы записей и наборы: § Тип записей. Совокупность логически связанных элементов данных. § Набор. В модели DTBG отношение один-ко-многим между двумя типами записей. § Простая сеть. Структура данных, в которой все бинарные отношения имеют мощность один-ко-многим. § Сложная сеть. Структура данных, в которой одно или несколько бинарных отношений имеют мощность многие-ко-многим. § Тип записи связи. Формальная запись, созданная для того, чтобы преобразовать сложную сеть в эквивалентную ей простую сеть. 2.3.3. Реляционная модель. Основными элементами реляционной модели данных являются таблицы, представляющие сущности, в которых столбцы представлют атрибуты сущностей, а строки описывают экземпляры сущностей. Модель данных также подразумевает наличие операторов для генерации новых таблиц на основе существующих (называемых запросами), именно таких образом пользователи могут манипулировать данными и получать необходимую информацию. Существует два подхода к проектированию реляционной базы данных. § Первый подход заключается в том, что на этапе концептуального проектирования создается не концептуальная модель данных, а непосредственно реляционная схема базы данных, состоящая из определений реляционных таблиц, подвергающихся нормализации. § Второй подход основан на механическом преобразовании функциональной модели, созданной ранее, в нормализованную реляционную модель. Этот подход чаще всего используется при проектировании больших, сложных схем баз данных, необходимых для корпоративных информационных систем. 3. Постановка задачи. Целью данной практической части дипломной работы является разработка многопользовательской информационной системы, которая будет включать в себя базу данных и приложение, обладающее интерфейсом просмотра и правки, а также средствами обработки хранящейся в базе данных информации.
Функции, выполняемые информационной системой, во многом будут зависеть от ролей пользователей, использующих данные, хранящиеся в инфосистеме. Роли определяются позицией, занимаемой пользователем в структуре коммерческого отдела компании Вэб Плас. Ниже приведена структурная схема части коммерческого отдела, которая будет использовать базу данных. Схема 1. «Структура коммерческого отдела». Хранящиеся в информационной системе данные представляют собой информацию и сделках компании Вэб Плас со своими клиентами. Рассмотрим более подробно функции выполняемые системой: 3.1. Определение комиссионного вознаграждения сотрудников отдела продаж. Поиском клиентов, переговорами, заключением договоров в Вэб Плас, то есть полным оформлением сделки между клиентом и компанией занимаются сотрудники отдела продаж, именно они будут основными пользователями нашей системы. Сотрудники отдела продаж имеют определенную схему мотивации своей деятельности (продаж услуг Вэб Плас). Каждая сделка в зависимости от количества проданных подобных услуг или общей суммы продаж за месяц и других факторов имеет определенное вознаграждение. Одна из многочисленных функций инфосистемы - это расчет вознаграждения для сотрудников отдела продаж. Результаты работы специалистов по продажам должны накапливаться в виде статистики в специальной таблице база данных. 3.2. Внесение в систему совершенных сделок. Для реализации вышеприведенной функции необходимо обязательное внесение в базу данных информации обо всех сделках, заключенных специалистом по продажам. Обеспечение возможности внести эту информацию с помощью удобного интерфейса – это вторая функция системы. Для удобства внесения данных о сделках в информационной системе должна быть опорная таблица с перечнем всех услуг компании с их стоимостными и другими параметрами. В этой же опорной таблице должна быть заложена схема мотивации труда отдела продаж. Специалист по продажам с помощью специального интерфейса вносит название клиента, номер договора с компанией Вэб Плас, выбирает название проданной услуги, а система автоматически добавляет к этим данным параметры указанной услуги и вносит информацию в систему. 3.3. Формирование отчета о заработной плате. Сотрудникам отдела продаж ежемесячно выплачивается заработная плата. Заработная плата состоит из двух частей: оклад + вознаграждение в зависимости от результатов продаж. Система должна иметь возможность сформировать отчет, используемый для выплаты бухгалтерией заработной платы сотрудникам отдела продаж. Сразу после выплаты заработной платы за определенный период все сделки совершенные в данный период и до этого периода должны быть защищены от изменения – удаления. 3.4. Просмотр, редактирование и удаление сделок. Случается так, что некоторые параметры сделки могут изменяться во времени, следовательно, в информационной системе должна быть заложена возможность просмотра всех параметров внесенной сделки и внесения изменения, если это необходимо. При внесении изменений – удалении информации о сделках система должна автоматически произвести проверку изменились ли общие результаты в статистике. Если изменения в статистике произошли, то необходимо обновить статистические показатели. Редактирование – удаление сделок возможно лишь в том периоде, вознаграждение за который еще не получено специалистом по продажам. 3.5. Отчет о работе отдела продаж за период. Данная функция предназначена будет использоваться менеджером отдела продаж. Для принятия управленческих решений всегда необходимо располагать оперативной информацией о результативности деятельности, как отдельного подчиненного, так и всего отдела в целом. Информационная система должна в кратчайшие сроки выдавать отчеты о результатах деятельности каждого сотрудника отдела продаж и всего отдела за обозначенный пользователем период. 3.6. Разделение доступа к данным. Все данные в информационной системе разбиваются по уровням доступа к ним. Каждый пользователь системы имеет определенную роль и собственные параметры авторизации (имя пользователя, пароль). Параметры авторизации и права доступа могут быть изменены только лишь администратором информационной системы. Итак, в информационной системе должны существовать следующие роли: Менеджер по продажам. Менеджер по продажам имеет разрешение на чтение всех данных информационной системы, на редактирование опорной таблицы, где хранится информация об услугах компании, на редактирование - удаление информации о сделках всех подчиненных за период, который еще не является закрытым, на редактирование данных о результатах деятельности отдела, окладов и вознаграждений специалистов по продажам. Менеджер может добавлять в список подчиненных новых специалистов по продажам, самостоятельно определяя их оклад и другие необходимые параметры. Координатор коммерческого отдела. Координатор коммерческого отдела имеет право на формирование отчетов о результатах деятельности отдела продаж, за исключением тех отчетов, которые связаны с денежным вознаграждением сотрудников отдела (Эта информация является конфиденциальной). Сотрудник отдела продаж. Специалист по продажам имеет право на добавление новых сделок, на просмотр информации обо всех своих сделках, на редактирование и удаление сделок, совершенных в открытом еще периоде. Сотрудник отдела продаж имеет возможность просмотреть информацию о результатах своей работы, объем продаж любого коллеги и отдела в целом, и не имеет никакой возможности, используя собственные параметры доступа просмотреть размер вознаграждения других специалистов по продажам. Администратор информационной системы. Администратор информационной системы – пользователь, имеющий право на просмотр, редактирование и удаление любой информации, хранящейся в системе. Администратор не имеет право на изменение структуры системы, редактирование существующих объектов инфосистемы (формы, таблицы, отчеты, запросы, тексты программ). Администратор имеет право на добавление новых пользователей в систему и определение уровня прав их доступа к информации.
4. Реализация поставленной задачи. 4.1. Преимущества использования архитектуры «клиент-сервер». § снижение сетевого трафика при выполнении запросов. Например, при необходимости выбора пяти записей из таблицы, содержащей миллион, клиентское приложение посылает серверу запрос, который сервером компилируется и выполняется, после чего результат запроса (те самые пять записей, а вовсе не вся таблица) передается обратно на рабочую станцию.
§ Высокая защищенность системы. Шире возможности управления пользовательскими привилегиями и правами доступа к различным объектам базы данных. § Выше производительность информационной системы. § возможность параллельной обработки данных, особенно в случае использования многопроцессорных компьютеров в качестве сервера баз данных.
§ Выше маштабируемость системы – возможность поддержки большего количества пользователей. Исходя из вышеперечисленных преимуществ, для реализации поставленной задачи будет использоваться архитектура «клиент-сервер». Рисунок 3 «Схема построения информационной системы». 4.2. Выбор модели данных. Среди перечисленных выше логических моделей данных реляционная обладает значительными преимуществами: § достоинства для пользователя: o реляционная БД представляет собой набор таблиц, с которыми пользователь привык работать; o не нужно помнить пути доступа к данным и строить алгоритмы и процедуры обработки своего запроса; o реляционные языки легки для изучения и освоения, в то время как языки общения с иерархической и сетевой моделями предназначены для программистов и мало пригодны для пользователей; § достоинства обработки данных реляционной БД: o Связность. Реляционное представление дает ясную картину взаимосвязей атрибутов из различных отношений; o Точность. Направленные связи в реляционной БД отсутствуют. Отношения по своей природе обладают более точным смыслом и поддаются манипулированию с использованием таких средств, как алгебра и исчисление отношений, обеспечивающих наглядность и гибкость модели данных; o Гибкость. Операции проекции и объединения позволяют разрезать и склеивать отношения, так что программист может получать разнообразные файлы в нужной форме; o Секретность. Контроль секретности упрощается. Для каждого отношения имеется возможность задания правомерности доступа, засекреченные показатели можно выделить в отдельные отношения с проверкой прав доступа. o Простота Внедрения. Физическое размещение однородных (табличных) файлов намного проще, чем размещение иерархических и сетевых структур. o Независимость данных. БД должна допускать возможность расширения, т.е. добавления новых атрибутов и отношений. 4.3. Выбор СУБД и средства разработки базы данных. В качестве системы управления базами данных (СУБД) для реализации поставленной задачи остановимся на процессоре данных MSDE (Microsoft Data Engine), входящем в состав Microsoft Office 2000. В качестве средства разработки базы данных делаем выбор в пользу Access 2000 также входящего в Microsoft Office 2000. Почему именно такой выбор? § Microsoft Office 2000 установлен на каждом компьютере компании Вэб Плас. § Решения, созданные в Access легко интегрируются в другие приложения Microsoft Office 2000: MS Word, MS Excel и другие. Подготовленный в проекте Access отчет легко может быть перенесен в другие приложения Office. § Решения на базе Access + MSDE легко переносятся под управление MS SQL Server. Это означает, что приложение созданное в Access для использования с MSDE имеет высокий уровень масштабируемости. 4.3.1. Новый формат проектов Access. По умолчанию Access хранит все объекты данных и интерфейса в одном общем файле MDB. В Access 2000 появилась мощная технология построения приложений – проекты Access (Access Data Project, ADP). В ней используется файл нового формата (ADP), который заменил базу данных Jet в части хранения объектов приложения (форм, отчетов макросов и модулей). Хранение и обработка данных возложены на SQL Server, к которому приложение подключается непосредственно через OLE DB (см. описание ниже). 4.3.2. ODBC и OLE DB ODBC (Open DataBase Connectivity) задумывалось как средство для решения важнейшей проблемы первых серверов баз данных, а именно доступа к их данным из приложений-клиентов. Раньше единственным способом решения такой проблемы было включение в клиентские приложения библиотеки функций для работы с конкретным сервером. Поэтому сменить серверную технологию было невероятно сложно, поскольку для этого приходилось переписывать все клиентские приложения. Объединившись с несколькими ведущими производителями реляционных баз данных, Microsoft разработала стандарт ODBC, представлявший собой интерфейс прикладного программирования (API) для доступа к данным. Этот интерфейс обеспечивал динамическую загрузку драйверов для работы с любыми серверами бах данных и форматами файлов. Однако у ODBC было два серьезных недостатка. Во-первых, она предназначалась для реляционных баз данных, но в электронном мире оставалось еще много не реляционной информации, такой как сообщения электронной почты, документы, Web-страницы. Эти данные не могут хранится в формате реляционных СУБД. Во-вторых доступ к драйверам ODBC осуществлялся посредством API. Для выполнения самых простых задач программисту приходилось вызывать десятки сложных функций, по своей сути ODBC была очень уж сложной технологией Рисунок 4. «Сравнение ODBC и OLE DB» Технология OLE DB[2] пришла на смену ODBC, с тем, чтобы устранить ее недостатки. OLE DB основана не на API, а на COM[3] Это облегчает разработку не только конечных приложений, но и функциональных эквивалентов драйверов ODBC – средств доступа к данным OLE DB, называемых также провайдерами OLE DB. Ведь теперь в их роли могут выступать любые COM -компоненты. OLE DB предназначена для работы с любыми данными, а не только с реляционными. Производители ПО могут теперь разрабатывать средства доступа OLA DB для своих специфических данных, обеспечивая программистам свободный доступ к таковым и возможность их интеграции в свои решения. Однако и OLE DB считается довольно сложной технологией. Чтобы упростить выполнение самых стандартных действий, Microsoft разработала библиотеку объектов доступа к данным ActiveX Data Object (ADO) и включила ее в OLE DB в качестве интегрированного компонента. Именно технологии OLE DB и ADO будут использоваться в разработанном приложении для доступа к данным. 4.4. Проектирование. 4.4.1. Определение сущностей Исходя из поставленной задачи, описанной выше, выделим следующие сущности: § Sales – таблица, содержащая информацию о сотрудниках отдела продаж. § Services – таблица, содержащая информацию о сервисах компании. § Deals – таблица, содержащая информацию о сделках, совершаемых сотрудниками отдела продаж § ExtraTrafic – таблица, содержащая информацию о превышении трафика по сделкам § Results – таблица, содержащая информацию о результатах деятельности каждого сотрудника отдела продаж за каждый месяц работы. 4.4.2. Определение взаимосвязей между сущностями
Рисунок 5 «Связи между сущностями». 4.4.3. Задание первичных ключей, определение атрибутов сущностей Первичный ключ – это атрибут (или группа атрибутов), которые единственным образом идентифицируют каждую строку в таблице. Для каждой сущности определим атрибуты, которые будем хранить в БД.
Таблица 1. Атрибуты и первичные ключи сущностей информационной модели Сущность Первичный ключ Атрибуты Sales SalesID SalesID – номер сотрудника отдела продаж SalesName – Фамилия Имя сотрудника Oklad – размер оклада сотрудника Username – имя пользователя в базе TP – схема премирования Services ServiceID ServiceID – Код сервиса ServiceType – тип сервиса ServiceName – наименование сервиса StartPayment – установочная плата сервиса MthPayment – ежемесячная плата сервиса PcentBonus – размер процентового бонуса от установочной платы Bonus – размер одноразового бонуса MinimalCount – минимальное количество данных сервисов PcentTrafic – размер процентового бонуса от ежемесячной платы Lines – количество линий-эквивалентов сервиса Deals DealId DealId – код сделки SalesID – код сотрудника отдела продаж, Client – наименование клиента Dogovor – номер договора с клиентом Trafic – сделка – это трафик Corporative – корпоративный клиент или частный MNew – новый клиент компании или существующий Barter – бартерная сделка или нет Date – дата закрытия сделки ServiceID – код сервиса Lines – количество линий-эквивалентов DealClose – флаг Results ResultId ResultId – код строки результата SalesID – код сотрудника отдела продаж, Date – дата начала отчетного месяца SalesPlan – обеъем продаж за месяц Lines – количество линий-эквивалентов проданных за месяц Oklad – оклад торгового специалиста по продажам Bonus – размер премии за данный месяц ForBest – премия за лучшего ForDiligence – пермия за отсутвие нарушений в работе ExtraBonus – дополнительная премия ZarPlata – Итоговая заработная плата за данный месяц ExtraTrafic id id – код строки превышения по трафику DealId – код сделки Date ExtraTrafic – объем превышения по трафику в данной сделке Bonus – размер премии за превышение по трафику Date – дата начала месяца в котором было превышение по трафику в указанной сделке 4.5. Схема данных. Рисунок 6 «Схема данных информационной системы». 4.6. Описание работы информационной системы. 4.6.1. Описание интерфейса. После запуска базы данных из программы Access СУБД выводит окно авторизации, куда нужно ввести свое имя пользователя и пароль (представиться базе данных): Рисунок 7. «Окно ввода пароля». В случае если соединение прошло успешно, то пользователь допускается к работе с базой данных. Главное меню информационной системы выглядит следующим образом (Рисунок 8): Рисунок 8 «Главное меню базы данных». Ниже описана работа с Информационной системой. Меню «Сделки» Работа со сделками включает в себя: - Добавление новой сделки в систему; - Удаление сделок; - Редактирование сделок; Добавление новой сделки в систему Договор заключается специалистом по продажам с клиентом компании «Вэб Плас» на предоставление одной или нескольких услуг из спектра услуг «Вэб Плас». Сотрудник отдела продаж вводит в форму базы данных (рисунок 9) название клиента, номер договора, дату закрытия сделки, определяет значение радиокнопки «Бартер» (если сделка оформлена по бартеру, то радиокнокпа включена, в противном случае выключена. По умолчанию кнопка выключена), определяет значение радиокнопки «Корпоративный» (если сделка заключена с юридическим лицом, то радиокнокпа включена, в противном случае клиент – частное лицо и кнопка выключена. По умолчанию кнопка включена), определяет значение радиокнопки «Новый» (если сделка заключена с новым клиентом, то радиокнокпа включена, в противном случае клиент существующий и кнопка выключена. По умолчанию кнопка включена). Рисунок 9. «Добавление новой сделки». Далее необходимо выбрать услугу, предоставленную заказчику. Это делается в поле со списком всех имеющихся в компании услуг. Все атрибуты являются обязательными для заполнения. Если одно из полей не будет заполнено, то система выдаст ошибку (рисунок 10) Рисунок 10. «Ошибка: Не заполнены поля». Специалист имеет возможность внести услугу двумя способами: 1. Начать кнопку «Внести и Добавить еще услугу». Нажатие на данную кнопку приводит к внесению данных из формы в базу данных и очистке поля со списком «Услуга» с целью предоставления возможности внести указанному клиенту еще одну услугу, не занося информацию о клиенте вторично. 2. Нажать кнопку «Внести сделку и Очистить форму». Нажатие на данную кнопку тоже приводит к внесению данных из формы в базу данных и очистке всех полей в форме с целью внесения информации о другом клиенте. Удаление сделок. Для того чтобы удалить какую-либо сделку из системы нужно в главном меню выбрать пункт «Сделки» и в предлагаемом списке нажать на «Удалить». В результате этих действий пользователю будет предложена форма со списком сделок (рисунок. 11), которые доступны для удаления в данный момент (Для удаления доступны сделки, комиссионные по которым еще не выплачены, т.е. «открытые сделки»). Рисунок 11. «Форма для удаления/редактирования сделок». Для удаления нужно выделить сделку (сделки), которые необходимо удалить и нажать кнопку «Удалить». Система выдаст предупреждение об удалении сделки/сделок (рисунок 12). Данное предупреждение страхует от случайного удаления сделок. Автоматически удалятся все записи связанные с удаляемой сделкой (превышение по трафику, если есть). В форме редактирования и удаления сделок обновиться поле с доступными сделками, то есть из списка исчезнут, данные об удаленных сделках.
Рисунок 12. «Предупреждение об удалении сделок». Редактирование сделок. Для редактирования сделок нужно в главном меню выбрать пункт «Сделки» и в предлагаемом списке нажать на «Редактировать». В итоге пользователю будет выведена форма «ChangeDeal» для редактирования информации о выбранной сделке (рисунок 13).
Рисунок 13. «Форма для редактирования сделок». В форме необходимо внести требующиеся изменения и нажать кнопку «Сохранить изменения». Внесенные изменения будут автоматически сохранены, а форма «ChangeDeal» закрыта. Если изменения влияют на другие параметры сделки, которые вычисляются в системе автоматически (Например, размер бонуса за сделку), то эти данные тоже будут изменены автоматически. В случае отсутствия каких-либо изменений в форме, система выдаст предупреждение. Это реализовано для исключения лишних обращений к базе данных. Меню «Показатели» Работа с показателями включает в себя: § Форму «Показатели персональные». § Форму «Показатели всего отдела». Показатели персональные. Сотрудник отдела продаж имеет возможность просмотреть свои показатели за любой, определенный им месяц. Форма «CommissionSales» реализует эту возможность (рисунок 14). Для просмотра показателей необходимо выбрать любую дату из желаемого месяца в поле «Дата отчета» и нажать кнопку «Обновить данные». Рисунок 14. «Персональные показатели». Показатели всего отдела. Сотрудник отдела продаж имеет возможность просмотреть показатели работы всего отдела за любой, определенный им месяц. Форма «Commission» реализует эту возможность (рисунок 15). Для просмотра показателей необходимо выбрать любую дату из желаемого месяца в поле «Дата отчета» и нажать кнопку «Обновить данные». Рисунок 15. «Показатели всего отдела». Меню «Отчеты». Работа с отчетами включает в себя следующие возможности: - Просмотреть и распечатать отчет за любой из месяцев. - Просмотреть и распечатать отчет за год. - Просмотреть и распечатать отчет за любой указанный период. Меню «Трафик». Работа с трафиком включает в себя: - Добавление превышения по трафику; - Удаление превышения по трафику; - Редактирование превышения по трафику; Добавление превышения по трафику. Для того чтобы добавить превышение по трафику нужно войти в меню «Трафик» и выбрать пункт «Добавление превышения по трафику». Далее необходимо заполнить форму добавления превышения по трафику (Рисунок 16) и сохранить данные. Рисунок 16. «Добавление превышения по трафику». Редактирование и удаление превышения по трафику. Для редактирования и удаления превышения по трафику нужно в главном меню выбрать пункт «Трафик» и в предлагаемом списке нажать на «Редактировать» либо «Удалить». В итоге пользователю будет выведена форма «ChangeTrafic» для редактирования или удаления информации о выбранной сделке. Работа производится аналогично подобной работе со сделками. 4.6.2. Техническое описание работы информационной системы. Создание подключения к серверной базе данных. Для нормальной работы пользовательского приложения необходимо в первую очередь организовать подключение к базе данных (к СУБД). Для создания подключения к серверной базе данных используется метод Open объекта Connection. При этом необходимо правильно выбрать провайдера OLE DB. Для подключения к MSDE нужно в строке подключения задать для параметра Provider значение SQLOLEDB. Вся информация о подключении задается в параметре ConnectionString метода Open. Set cnn = New ADODB.Connection With cnn .ConnectionString = "Provider=SQLOLEDB.1;Password=25375;Persist " & _ "Security Info=True;User ID=lucky;Initial Catalog=Commisson;Data Source=192.168.200.38" .Open End With Создание наборов записей. Для создания наборов записей, которые потом можно использовать в приложении, можно применять один следующих подходов: § Запускать сохраненную процедуру, которая скомпилирована и находится на сервере. § Запускать директиву SQL прямо из текста программы VBA. В настоящей работе использовался как тот, так и другой способ создания наборов записей. С помощью сохраненной процедуры: Прежде всего, необходимо установить подключение к базе данных. Этот процесс описан выше. Текст процедуры: Alter Procedure ServiceName @ServiceID int As SELECT ServiceName FROM Services WHERE (ServiceID = @ServiceID) Return Чтобы использовать данную сохраненную процедуру, необходимо ей сначала передать параметр @ServiceID . Для этого создается объект ADODB.Parameter. Dim prm As ADODB.Parameter Set prm = cmd.CreateParameter("@sales", adInteger, adParamInput, , SalesID) Далее с помощью метода Append этот параметр передается на сервер. cmd.Parameters.Append prm Для выполнения любых взаимодействий с сервером создается объект Command. В том числе для создания и передачи параметра на сервер используется именно этот объект. Вот как выглядит его объявления и создание: Dim cmd As ADODB.Command Set cmd = New ADODB.Command Прежде чем запросить теперь данные у сервера необходимо подготовить переменную, куда они будут помещены. Для этого используется объект RecordSet: Dim rst As ADODB.Recordset Set rst = New ADODB.Recordset Лишь теперь обращаемся к серверу с запросом на выполнение сохраненной процедуры и помещения данных в объект RecordSet это можно сделать с помощью метода Open объекта RecordSet: rst.Open cmd, , adOpenKeyset, adLockReadOnly, adCmdStoredProc Далее возможны любые манипуляции с полученными данными. С помощью запросов SQL: Использование SQL запросов похоже на работу с сохраненными процедурами. Аналогично описанному выше способу получения данных при реализации SQL запроса к серверу необходимо также создать подключение, объект Command и RecordSet. Далее используя все тот же метод Open объекта RecordSet создается набор записей: strSQL = "SELECT SalesID FROM Sales WHERE (SalesName ='" & Me.SalesName.Value & "')" rst.Open strSQL, cnn, adOpenKeyset, adLockReadOnly, adCmdText Для запуска SQL запросов, которые не возвращают набора записей, в информационной системе используется метод Execute объект Command: strSQL = "UPDATE Deals" & _ " SET Bonus = " & Bonus & " " & _ "WHERE ( ServiceID = '" & Me.ServiceName.Value & "')" & _ " AND (Year (Date) = Year ('" & Me.Date.Value & "')) AND (Month (Date) = Month ('" & Me.Date.Value & "'))"
cmd.CommandText = strSQL cmd.Execute Существуют и другие методы создания наборов записей и исполнения SQL запросов, но в настоящей работе используются только описанные выше. Из вышеуказанных методик доступа к данным SQL сервера наибольшей скоростью работы обладают сохраненные процедуры, т.к. они находятся на сервере и к тому же уже скомпилированы.
4.6.3. Защита информационной системы. § Для защиты модулей можно применить пароль VBA-проекта. § Для защиты таблиц, хранимых процедур и других объектов SQL Server/MSDE должна использоваться система защиты SQL Server. § Для защиты форм, отчетов и модулей можно удалить из проекта исходный код, конвертировав проект в ADE-файл. Делается с помощью команды Tools/Database Utilities/Make ADE File. Только обязательно необходимо сохранить ADP-файл, иначе невозможно будет модифицировать проект. § Применение параметров запуска для ограничения доступа к стандартным меню и панелям инструментов, диалоговому окну База данных и специальным комбинациям клавиш. Защита модулей Программный код в настоящей информационной системе защищается с помощью пароля на открытие проекта VBA. Для его установки необходимо выбрать из меню редактора VBA команду Tools/ Commission Properties, на вкладке Protection диалогового окна Project Properties установить флажок Lock project for viewing, после чего нужно ввести пароль и подтвердить его. При попытке открыть программный код система будет спрашивать у пользователя пароль (Рисунок 17). Рисунок 17. «Пароль на открытие кода программы». Основные понятия системы защиты SQL Server. • Учетные записи. Чтобы пользователь мог подключиться к SQL Server, ему должен быть назначен идентификатор учетной записи — login ID. SQL Server может интегрироваться с системой защиты Windows NT или Windows 2000, благодаря чему учетные записи этих операционных систем могут быть зарегистрированы в SQL Server. Кроме того, учетные записи можно создавать и непосредственно в SQL Server — в таком случае к серверу смогут подключаться пользователи Windows 95/98. • Пользователи. Учетная запись позволяет человеку подключиться к серверу, но не позволяет ему работать с базой данных, если он не является ее пользователем. Идентификатору учетной записи SQL Server поставлено в соответствие имя пользователя базы данных (которое может отличаться от этого идентификатора). • Группы. SQL Server поддерживает два способа объединения пользователей, применяемых для управления доступом к объектам базы данных, а именно создание групп и ролей. Группа SQL Server соответствует группе пользователей Windows NT/2000. Если необходимо назначить одинаковые разрешения нескольким пользователям SQL Server, которые не являются группой Windows NT/2000, вам нужно определить для SQL Server новую роль и назначить разрешения этой роли. • Роли. В SQL Server определен набор фиксированных ролей (например, public, sysadmin, db_owner), в дополнение к которым можно создавать и собственные роли. Для роли могут быть назначены пользователи, группы и даже другие роли. • Роли приложений. Кроме стандартных ролей SQL Server позволяет создавать специальные роли приложений. Посредством ролей приложения подключаются к SQL Server и получают нужные разрешения независимо от пользователей. • Разрешения. Разрешения на объекты SQL Server могут назначаться пользователям, группам и ролям (в том числе и ролям приложений). Управление защитой SQL Server из проекта Access В Access имеется диалоговое окно, позволяющее управлять системой защиты SQL Server прямо из проекта Access. Открывается оно по команде Tools/Security/Database Security и называется SQL Server Security (рисунок 18). Рисунок 17. «Диалоговое окно SQL Server Security». Из этого окна можно управлять учетными записями, пользователями, группами, ролями и разрешениями на объекты SQL Server. Управление учетными записями, пользователями и ролями MSDE Прежде чем назначить разрешения на объекты базы данных, необходимо создать учетные записи для подключения к SQL Server, определить пользователей и роли. Как правило, сначала определяют роли, а затем создают учетные записи пользователей баз данных. По умолчанию в SQL Server существует учетная запись с идентификатором sa. Учетная запись SA Установленный SQL Server имеет только одну встроенную учетную запись — SA (server administratur — администратор сервера), с пустым паролем. Ей назначена серверная роль System Administrators, благодаря чему запись имеет полный доступ ко всем базам данных сервера. Для защиты SQL Server первым делом задаем пароль этой важнейшей учетной записи, после чего ею желательно не пользоваться вовсе. Учетной записи SA соответствует пользователь DBO — владелец базы данных (database owner), имеющийся у каждой базы данных SQL Server. Создание ролей Для создания новой роли в диалоговом окне SQL Server Security нужно выбрать вкладку Database Roles и щелкнуть на кнопке Add. Access откроет окно Database Role Properties — New Role Вводим в поле Name имя новой роли. Далее сохраняем введенные данные. Создание учетных записей SQL Server Прежде чем приступить к созданию учетной записи, определяющей пользователя базы данных, необходимо создать учетную запись для подключения к SQL Server. Учетная запись SQL Server (server login) позволяет пользователю подключиться к серверу, а учетная запись пользователя базы данных (database user) ~ к конкретной базе данных. Для того чтобы создать учетные записи SQL Server и пользователя базы данных для начала нужно открыть вкладку Server Logins диалогового окна SQL Server Security и щелкнуть на кнопке Add. Access откроет диалоговое окно SQL Server Login Properties — New Login. Далее вводим имя пользователя в поле Name, а его пароль — в поле Password. Теперь, независимо от типа создаваемой учетной записи, необходимо задать для нее используемую по умолчанию базу данных и язык. После нажатия ОК учетная запись будет создана. Предоставление учетным записям доступа к базам данных Чтобы новый пользователь SQL Server мог работать с одной или несколькими базами данных, нужно в диалоговом окне SQL Server Login Properties — New Login открыть вкладку Database Access, связать учетную запись с нужными базами данных и назначить ей одну или несколько ролей баз данных. Связав учетную запись пользователя с базой данных, можно назначить ему одну или несколько ролей в этой базе. Выбераем имя базы данных в верхнем списке, а в нижнем установите флажки нужных ролей. Можно выбирать как стандартные роли баз данных, так и роли, определенные пользователем. Вот перечень стандартных ролей баз данных. • public. Эта роль автоматически назначается всем пользователям. • db_owner. Пользователи, назначенные для этой роли, имеют полные права на базу данных.
• db_accessadmin. Пользователи, назначенные для этой роли, могут связывать с базой данных учетные записи. • db_datareader. Пользователи, назначенные для этой роли, могут читать данные всех таблиц базы данных. • db_datawriter. Пользователи, назначенные для этой роли, могут модифицировать данные всех таблиц базы данных.
• db_ddladmin. Пользователи, назначенные для этой роли, могут создавать, удалять и модифицировать схемы объектов базы данных. • db_securityadmin. Пользователи, назначенные для этой роли, могут управлять разрешениями на объекты базы данных и ее ролями. • db_backupoperator. Пользователи, назначенные для этой роли, могут создавать резервную копию базы данных. • db_denydatareader. Пользователи, назначенные для этой роли, лишены права читать данные таблиц базы данных. • db_denydatawriter. Пользователи, назначенные для этой роли, лишены права модифицировать данные таблиц базы данных. Защита объектов SQL Server В диалоговом окне SQL Server Security можно просматривать и устанавливать Разрешения на объекты баз данных как для пользователей, так и для ролей. Как вообще работают Разрешения SQL Server. Явные и неявные разрешения SQL Server Пользователь SQL Server получает все разрешения назначенных ему ролей. SQL Server поддерживает два вида удаления разрешений пользователей и ролей. • При отмене разрешений (revoke) удаляются только явные разрешения (или роли) пользователя, но неявные, унаследованные от назначенных ему ролей, сохраняются, благодаря чему пользователь может получить доступ к объекту. • При запрете доступа (deny) пользователь (или роль) лишается права доступа к объекту, независимо от того, имеются ли разрешения на доступ к этому объекту у назначенных ему ролей. Только после того, как вы явно предоставите пользователю разрешение на объект, он сможет получить к нему доступ. Просмотр и установка разрешений SQL Server Для просмотра либо установки разрешений роли или пользователя выбираем в окне SQL Server Security соответствующую вкладку (Database Users либо Database Roles), выделяем пользователя или роль, щелкаем по Edit и, когда Access откроет диалоговое окно Database User Properties или Database Role Properties, щелкаем в нем на кнопке Permissions, чтобы открыть одноименную вкладку (рисунок 18). Рисунок 18. «Диалоговое окно для назначения разрешений на объекты и инструкции SQL Server». Устанавливая соответствующие флажки, можно задать разрешение на выбранный объект или инструкцию: • установленный флажок означает, что разрешение предоставлено; • сброшенный флажок означает, что явное разрешение на доступ к объекту отменено; • красный крестик означает, что доступ к объекту запрещен; Настроив разрешения, нужно их сохранить с помощью кнопки OK. На рисунке 18 показан простой пример установки разрешений. Пользователям, исполняющим роль Sales, разрешено читать строки из таблицы Sales, но запрещено удалять и обновлять строки. Программное управление защитой с помощью ADOX. Для управления учетными записями пользователей и групп в ней задействуются методы семейств Users и Groups. ADOX используется для определения входит ли пользователь в ту или иную группу. Определение с помощью ADOX, входит ли пользователь в группу. И эту задачу благодаря симметрии семейств Users и Groups можно решить двумя способами: проверить, содержится ли интересующая группа в семействе Groups объекта User, или проверить, содержит ли семейство Users объекта Group интересующего вас пользователя. Function IsUserMemberADOX(strGroup As String, Optional varUser As _ Variant) As Boolean ‘Определяет с помощью ADOX, входит ли указанный ‘пользователь в заданную группу. Dim cat As ADOX.Catalog ' Отключаем сообщения об ошибках. On Error Resume Next Set cat = New ADOX.Catalog cat.ActiveConnection = CurrentProject.Connection If IsMissing(varUser) Then varUser = CurrentUser() End If IsUserMemberADOX = _ (cat.Groups(strGroup).Osers(varUser).Name = varUaer) Set cat = Nothing End Function Чтобы сделать эту функцию более универсальной, включаем в нее вызов функции CurrentUser — на тот случай, если имя пользователя не задано. (Функция CurrentUser возвращает имя текущего пользователя.) Используя вышеприведенную функцию, определяем, имеет ли право пользователь произвести ту или иную операцию. Установка параметров запуска. Используя диалоговое окно Параметры запуска, сбрасываем все флажки, определяющие доступ пользователя у меню и панелям инструментов приложения Access. Здесь можно было бы подробно не останавливаться на этом вопросе. Единственное, что можете быть интересно, - это то, что пользователь может запустить приложение, удерживая нажатой клавишу «Shift», тем самым, игнорируя ограничения параметров запуска. Для предотвращения запуска приложения в обход параметров запуска включим в событие загрузки основной формы системы следующую функцию: Sub Init () Dim db as Databse, prp As Variant Const conPrompNotFoundEror = 3270 Set db = CurrentDb On Error GoTo Init_Err Bd.Properties (“AllowBypassKey”)= False Init_Exit: Exit Sub Init_Err: If Err = Const conPrompNotFoundEror Then Set prp = db.CreateProperty (“AllowBypassKey”, dbBoolean, False) Resume Next End If End Sub
5. Экономическая часть. Оценка эффективности инвестиций на разработку и отладку Информационной Системы. Цель данной главы заключается в расчете чистой приведенной величины дохода при реализации дипломного проекта. Этот показатель определяется как разность между возможными доходами, получаемыми при осуществлении проекта, и обеспечивающими эти доходы инвестициями. Для расчета ЧПВД весь процесс инвестиционной деятельности представляется в виде последовательности множества распределенных во времени первоначальных вложений и последующих доходов (поток платежей). При определении ЧПВД для каждого члена потока платежей определяются потери от неиспользованных нами возможностей. Дисконтирование по сложной ставке процента с определением дисконтного множителя Jt за каждый год из n лет вложения по следующей формуле: Jit=(1+i)-t , где i – ставка сложных процентов, t=1,2,…,n. Итоговая величина искомого показателя ЧПВД может быть определена по следующей формуле: Где n1 – продолжительность осуществления инвестиций, n2 – продолжительность периода отдачи от инвестиций, Зl - ежегодные инвестиции в периоде j, j=1,2,…,n1, pi – ежегодная отдача (чистый доход) в периоде j, j=1,2,…,n2. В дипломном проекте сравниваемые варианты обеспечивают равенство продолжительности периодов отдачи и ежегодной отдачи от инвестиций по двум сравниваемым вариантам создания ПО, поэтому формула упрощается и может быть представлена в следующем виде:
Где З – современная величина совокупных затрат за весь период реализации проекта. Величина показателя З определяется в виде суммы современных величин затрат по всем этапам периода реализации для основного и альтернативного сравниваемых проектов. Наиболее предпочтительным и, следовательно, подлежащим финансированию принимается проект, обеспечивающий З®min.
Основная задача данной дипломной работы является программный продукт, который выполняет следующие функции: 1. Создание базы данных в Access, обладающую защитой от несанкционированного доступа. 2. Обеспечение схемы разграничения доступа к информации. С технической точки зрения мы имеем несколько возможностей реализации поставленной задачи с учетом перечисленных ранее требований к данной системе. В дипломном проекте ограничимся рассмотрением двух возможных способов реализации. Для нас важно то, что оба из рассматриваемых вариантов дают одинаковый конечный результат (рассматриваемый с точки зрения равенства функциональных возможностей ). Требуемый на момент окончания процесса автоматизации. Итак, два способа реализации поставленной задачи. Основной вариант – создание программного продукта при использовании объектно-ориентированного языка программирования Visual Basic for Application (VBA) и MS Access. Второй вариант – реализация подобного проекта с использованием объектно-ориентированного языка программирования Borland Delphi и MS SQL Server. Первый вариант реализации данного проекта при дальнейших расчетах будет принят за основной, второй вариант будет рассматриваться как альтернативный. Автор данной дипломной работы уже имел ранее опыт выполнения аналогичных проектов. В результате чего были накоплены некоторые статистические данные, которые мы можем использовать при задании исходных данных для расчета эффективности инвестиций. Таблица 5.1. Исходные данные для расчетов. Наименование показателей Условные обозначения Значения по вариантам Основной Альтернативный Основные технико-эксплу­ата­ционные показатели, использу­­емые в последующих расчетах: (перечень) В том числе планируемый объем выпуска, шт. Общая продолжительность этапа разработки, лет. Общая численность исполни­телей в течении 1-го года раз­ра­ботки, чел. В том числе по категориям: Программисты N Tниокр U1 1 1 1 1 1 1 2 2 Наименование показателей Условные обозначения Значения по вариантам Основной Альтернативный Общая численность исполни­телей в течении 2-го года раз­работки, чел. Среднемесячная заработная плата исполнителей по катего­риям, р./мес.: Программисты Норматив удельных капиталь­ных вложений на ед. себестои­мости разрабатываемого ПО Общая продолжительность этапа эксплуатации, лет. Коэффициент сопутствующих капитальных вложений на единицу себестоимости ПО. U2 З g Tз V - 5000 0,9 3 10% -­ 4000 0,92 3 10% Выбор ставки сложного процента Без сомнений выбор ставки сложного процента является одним из самых важных действий при расчетах по определению эффективности инвестиций. Очевидно, что неправильно выбранная величина процента может привести к весьма приближенным или вовсе неправильным результатам. Но на момент написания дипломного проекта экономическое положение достаточно стабильно и поэтому мы можем уверенно взять ставку процента из расчета усредненной ставки, равной 15%. Следующим шагом мы должны определить дисконтный множитель Jt по каждому году для расчетного периода. Для этого воспользуемся данными из таблицы 1: Общая продолжительность разработки – 1 год Общая продолжительность эксплуатации – 3 года. Итого – 4 года. Сроки альтернативного проекта совпадают. Графически процесс вложения инвестиций выглядит следующим образом: Рис.1. t нач=0 1 2 3 4 5 t, Этап разработки Этап эксплуатации Общий расчетный период Таким образом, для ставки сложного поцента, равной 15%, следует, что дисконтный множитель J154 по годам вложений имеет следующие значения: Таблица 5.2. Значения дисконтного множителя по годам вложений. Период приведения 1-ый год 2-ой год 3-ий год 4-ый год J154 0,8695 0,7561 0,6575 0,5717 Расчет вложений по годам этапа разработки и отладки. Планирование разработки и производства ПО выражается в составлении календарных планов выполнения работ, определении денежных средств, необходимых для их реализации, а также потребных трудовых и материальных ресурсов. Успешное выполнение плановых заданий предполагает также осуществление оперативного управления ходом работ, включая контроль за выполнением планов и регулирование процесса случая выявления отклонения от намеченных плановых заданий. Основными задачами планирования разработки и отладки ПО являются: · Взаимная увязка всех работ по разработке и отладки ПО · Согласование выполнения отдельных этапов работ во времени; · Определение длительности работ и обеспечение их выполнения в уста­новленные сроки.
· Распределение общего объема работ, · Достижения наилучшего использования ресурсов. Решение этих задач обеспечивается соответствующими методами планирования разработки и производства ПО. В дипломной работе для этого используется календарный график. Разработка календарного графика производится в следующей последовательности:
· Составление перечня работ, · Определение трудоемкостей и продолжительности работ, ·Построение календарного графика, · Расчет сметы затрат. Подготовительные данные для построения графика разработки и отладки программного продукта представлены в таблице 3. В дипломном проекте под этапом НИОКР подразумевается этап постановки задачи, создание пользовательского интерфейса, отладка программы – вплоть до окончательной версии программы, способной решать поставленные перед системой задачи. Для того, чтобы рассчитать и распределить необходимые нам финансовые вложения, нам нужно рассчитать сметную стоимость по отдельным статьям сметной калькуляции методом прямого расчета, исходя из данных по технической подготовке процесса разработки ПО. Таблица 5.3. Календарное планирование разработки и отладки ПО. Для основного варианта. N n/n Этап разработки Оценка трудоем­ко­­сти, чел/дней Исполнители Итого Машин­­ное время Кол-во Должность 1 Согласование и утверждение ТЗ на разработку системы 6 1 программист 6 2 Изучение литерату­ры и патентный поиск 17 1 программист 17 3 Разработка блок схе­мы и алгоритмов системы 59 1 программист 59 4 Разработка программы 59 1 программист 59 + 5 Тестирование 14 1 программист 14 + 6 Разработка документации 30 1 программист 30 + 7 Составление прог­раммы испытаний­ 6 1 программист 6 8 Комплексная отладка 46 1 программист 46 + 9 Корректировка сис­тем и документации по результатам ком­п­лексной отладки 23 1 программист 23 + Всего 1 260 Таблица 5.3. Календарное планирование разработки и отладки ПО. Для альтернативного варианта. N n/n Этап разработки Оценка трудоем­ко­­сти, чел/дней Исполнители Итого Машин­­ное время Кол-во Должность 1 Согласование и утверждение ТЗ на разработку системы 6 2 программист 12 2 Изучение литерату­ры и патентный поиск 17 2 программист 34 3 Разработка блок схе­мы и алгоритмов системы 59 2 программист 118 4 Разработка программы 59 2 программист 118 + 5 Тестирование 14 2 программист 28 + 6 Разработка документации 30 2 программист 60 + 7 Составление прог­раммы испытаний­ 6 2 программист 12 8 Комплексная отладка 46 2 программист 92 + 9 Корректировка сис­тем и документации по результатам ком­п­лексной отладки 23 2 программист 46 + Всего 2 520 Т.о., трудоемкость выполнения работ для основного варианта составит: Tоб1 =260чел/дней Для альтернативного: Tоб2 =520чел/дней/ Из данных таблицы 3 мы можем рассчитать затраты машинного времени, можем рассчитать годовой действительный фонд рабочего времени ПЭВМ Фг . При длительности рабочего дня 8 часов затраты машинного времени Фг составят :
Фг1=8*(59+14+46+23)=1136 Фг2=8*(118+28+92+46)=2272 Таблица 5.4. Расчет затрат по материалам для выполнения работы. Для основного варианта: N п/п Материалы Стоимость, Руб. 1 2 3 Канцелярские товары Компьютерные расходные материалы и комплектующие Дополнительные материалы 1600 2800 800 Для альтернативного варианта: N п/п Материалы Стоимость, Руб. 1 2 3 Канцелярские товары Компьютерные расходные материалы и комплектующие Дополнительные материалы 2400 5600 1200 Расчет затрат на приобретение специального оборудования и аренду. В основном варианте исполнения проекта, работу выполняет один программист. Соответственно нет необходимости снимать дополнительное помещение для выполнения этой работы – необходимый объем работ программист может выполнить на уже имеющейся площади – поэтому необходимость в аренде помещения отпадает. Для альтернативного варианта необходимо помещение для совместной разработки ПП – для его согласования и отладки. С целью уменьшения затрат, выберем для работы такое помещение, которое соответствовало бы гигиеническим нормам и нормам охраны труда при работе за ПЭВМ. Площадь такого помещения составит 24 кв.м. На момент начала реализации проекта у нас уже имеется необходимая компьютерная техника с программным обеспечением, поэтому нам нет необходимости покупать оборудование и ПО. Таблица 5.5. Расчет затрат на приобретение специального оборудования и аренду. Для основного варианта: N n/n Тип затрат Стоимость, руб. 1 Арендная плата - Для альтернативного варианта: N n/n Тип затрат Стоимость, руб. 1 Арендная плата (24кв.м.*60руб/кв.м*12) 17280 Таблица 5.6. Расчет основной заработной платы Для основного варианта N n/n Категория работника Заработная плата, руб. 1 Программист (5000руб/мес*12мес) 60000 Для альтернативного варианта N n/n Категория работника Заработная плата, руб. 1 Программист (2чел*4000руб/мес*12мес) 80000 Расчет дополнительной заработной платы и отчислений на социальное страхование. Расчет дополнительной заработной платы выполняется по следующей формуле: Зд =Нд * Зо /100, Где Зо - основная заработная плата персонала Нд - % дополнительной заработной платы персонала (14%). Расчет отчислений на социальное страхование: Зсс =Нсс *(Зо + Зд )/100, Нсс – процент отчислений на социальное страхование (38,5%). Таблица 5.7. Расчет дополнительной заработной платы и отчислений на социальное страхование. Для основного варианта Вид оплаты Размер оплаты,руб. 1 Дополнительная з/пл (14*60000/100) 8400 2 Отчисления на соц.страх.(38,5*(60000+8400)/100) 26334 Для альтернативного варианта Вид оплаты Размер оплаты,руб. 1 Дополнительная з/пл (14*80000/100) 11200 2 Отчисления на соц.страх.(38,5*(80000+11200)/100) 35112 Расчет расходов на служебные командировки. При разработке и отладке ПО не потребуются командировочные поездки т.к. все необходимые участники и техника находятся в зоне досягаемости. Таблица 5.8.Расчет расходов на служебные командировки. Командировки Величина затрат Местные Иногородние - - Таблица 5. 9. Расчет затрат по работам выполняемым сторонними организациями. Тип работ Стоимость, руб. Работы выполняемые сторонними организациями - При выполнении работ не требуется привлечение сторонних организаций. Формулы Условные обозначения С=Зо +Зд +Зсс +Зм +Зээ +За +Зпр Зо – основная з/пл. персонала, р/час Зд– дополнительная з/пл. персонала, р/час Зсс – отчисления на соц.страх. р/час Зм – затраты на материалы р/час Зээ – затраты на потребляемую электро­энергию, р/час За– амортизация вычислительных средств, р/час Зпр– прочие расходы р/час Зээ =å qj*Nj*S qj – число j-х технических средств ПЭВМ Nj – потребляемая мощность j-х технических средств, кВт. S – стоимость кВт/час электроэнергии(57коп) Зо = Зо1 + Зо2 Зо1 =12*å Зм (i)/Фг Зо1- основная заработная плата программистов, р/час Зо2 - основная заработная плата консультанта, р/час Зм (i)- месячная заработная i-го работника, р/час Фг – годовой действительный фонд рабочего времени работы ПЭВМ, час. Зд =Нд*Зо /100 Нд - % дополнительной заработной платы персонала (14%) Зсс =Нсс*(Зо +Зд )/100 Нсс - % отчислений на соц.страх. (38,5%) Зм=å mi *Цi mi – норма расхода материала i-го типа, руб. Цi– цена расхода материала i-го типа, руб. За =А*SПЭВМ /100* Фг А – годовая норма амортизации ПЭВМ (20%) SПЭВМ - балансовая стоимость ПЭВМ, руб. (15000 – основной вариант, 30000 – альтерна­­тивный ). Зпр =Нпр*(Зо +Зээ +За )/100 Нпр – процент прочих производственных расходов (50%). Таблица 5.10.Формулы для расчета себестоимости машино-часа работы на ПЭВМ. Кроме затрат, необходимых на корректировку существуют затраты на отладку не учтенные выше, для их расчета определим себестоимость машино-часа работы на ПЭВМ. Таблица 5.11. Расчет себестоимости машино-часа работы ПЭВМ.
Основной вариант Альтернативный Основная заработная плата Зо =12*(5000руб/мес)/ Фг Зо =12*(2*4000руб/мес)/ Фг Фг= 142(дня)*8(ч.)=1136ч. Фг= 284(дня)*8(ч.)=2272ч. Зо =12*(5000руб/мес)/ 1136=52,8 Зо =12*(8000руб/мес)/ 2272=42,3 Дополнительная заработная плата Зд =(14/100)*52,8=7,39руб/час. Зд =(14/100)*42,3=6руб/час. Отчисления на социальное страхование Зсс=(38,5/100)*(52,8+7,39)=23,17р/час Зсс=(38,5/100)*(42,3+6)=18,6р/час Затраты на материалы Зм=5200/1136=4,57руб/час Зм=9200/2272=4,05руб/час Затраты на электроэнергию Зээ=0,3*0,57=0,17руб/час Зээ=0,6*0,57=0,342руб/час Амортизация За=(20/100)*15000/1136=2,64руб/час За=(20/100)*30000/2272=2,64руб/час Прочие производственные расходы Зпр=(50/100)*(52,8+0,17+2,64)=27,81 руб/час Зпр=(50/100)*(42,3+0,342+2,64)=22,6 руб/час Таким образом, себестоимость машино-часа работы ПЭВМ составит: С=52,8+7,39+23,17+4,57+0,17+2,64+ 27,81=118,5 С=42,3+6+18,6+4,05+0,342+2,64+ 22,65=97,6 Но при расчете себестоимости машино-часа учитывались затраты лишь на ПЭВМ, занятых для решения задачи, и совсем не были учтены затраты на ремонт оборудования. Затраты на ремонт составляют 10% от стоимости оборудования: Зр=(10/100)*(15000/1136)=1,3 руб/час Зр=(10/100)*(30000/2272)=1,3 руб/час Таким образом, себестоимость машино-часа работы равна С=118,5+1,3=119,8руб/час С=97,6+1,3=98,9руб/час Зная себестоимость машино-часа работы ПЭВМ, мы можем определить затраты на отладку программы. Зотлад=С*T, Где T-время отладки(пункты 8 из таблицы 3), часов. Для основного варианта T=46*8=368ч. Зотлад=119,8*364час=43607руб. Для альтернативного T=92*8=736ч. Зотлад=98,9*736=72790руб. Таблица 5.12 Калькуляция сметной стоимости работ Наименование статей затрат Всего по теме, руб. Основной вариант Альтернативный вариант Материалы 5200 9200 Специальное оборудование для экспере­ментальных работ­ 0 0 Основная заработная плата 60000 80000 Дополнительная заработная плата 8400 11200 Все виды соц.страхования 26334 35112 Затраты на отладку программы 43607 72790 Арендная плата 0 17280 Расходы на служебные командировки 0 0 Расходы на работы, выполняемые сторонними организациями 0 0 Итого 143541 225582 В целом показатели на этапе разработки для дипломного проекта характеризуются только двумя величинами: - Стоимость НИОКР по теме = 143541 руб. - Дисконтный множитель J151=0,8695 Для альтернативного варианта эти величины - Стоимость НИОКР по теме = 225582 руб. - Дисконтный множитель J151=0,8695 Т.о., современная величина затрат на стадии НИОКР для основного проекта равна: КНИОКР1*J151=0,8695*143541=124736 Для альтернативного проекта КНИОКР2*J151=0,8695*186810=196144 Расчет вложений по годам эксплуатации. Наш программный продукт будет введен в эксплуатацию сразу после его разработки. Использоваться будет в течении 3-х лет. Таблица 5.13. Расчет основной, дополнительной заработных плат и отчислений на социальное страхование за год эксплуатации. Для основного варианта N п/п Виды начислений Размер оплаты, руб. 1 2 3 Основная заработная плата(12мес.*5000руб/мес) Дополнительная з/пл (14/100*60000руб.) Отчисления на соц.страх. (38,5/100*(60000+8400)) Итого 60000 8400 26334 94734 Для альтернативного варианта N п/п Виды начислений Размер оплаты, руб.
1 2 3 Основная заработная плата(12мес.*4000руб/мес) Дополнительная з/пл (14/100*48000руб.) Отчисления на соц.страх. (38,5/100*(48000+6720)) Итого 48000 6720 21067 75787 Для обоих вариантов в период эксплуатации требуется только один программист по ставке оклада. Таблица 5.14. Расчет годовых издержек при работе ПЭВМ за период эксплуатации. В этот период использование нашего программного продукта наПЭВМ будет происходить из расчета 2 часов в день. Таким образом, для сравниваемых проектов: Tэ=2ч/день*260дней=520 часов. Для основного варианта Для альтернативного Стоимость годовой эксп­лу­атации ПЭВМ (стои­мость машино-часов) =119,85*520=62322 руб. =98,9*520=51430 руб Таблица 5.15. Расчет величины годовых эксплуатационных издержек на единицу ПО. Наименование издержек Стоимость, руб. Основной проект Альтернативный проект З/пл. обслуживающего персонала 94734 75787 Затраты на эксплуатацию компьютерной техники 62322 51430 Итого 157056 127217 Т.к. в рассматриваемом проекте отсутствует период производства, то в дальнейших расчетах у нас не будут учитываться сопутствующие капитальные вложения. В таблице 16 представлена динамика показателей по рассматриваемым вариантам вложений. Таблица 5.16. Динамика показателей по рассматриваемым вариантам вложений. Показатели Год этапа эксплуатации 1-ый год 2-ой год 3-ий год осн альт осн альт осн альт Сопутствующие капи­таль­ные вложения, тыс.руб. 0 0 0 0 0 0 Годовые издержки эксплуатации, тыс.руб. 157 127,2 157 127,2 157 127,2 Итого 157 127,2 157 127,2 157 127,2 Дисконтный множитель 0,7561 0,6575 0,5717 В результате современная величина затрат на стадии эксплуатации будет равна : Для основного варианта=118,7+103+89,7=311,4 Для альтернативного варианта= 96,2+84+73=253,2 Расчет показателя итоговой современной величины затрат по сравниваемым вариантам инвестиций. З1=124324+311400=435724 З2=196144+253200=449344 Итоговые общие результаты анализа и вычислений представлены в таблице 17. Таблица 5.17. Показатели технико-экономической эффективности. Наименование показателей Значения показателей по вариантам основной Альтернативный Технико-эксплуатационные показатели Технические требования Процессор Опер. Память, не менее, Мб. Операционная система необходи­мая для работы ПО. Экономические показатели Общий период приведения, лет В том числе: Период разработки и отладки ПО Период эксплуатации ПО Ожидаемая ставка процента, % Современная величина затрат на разработку и отладку ПП, тыс руб. Эксплуатационные издержки, тыс.руб. Показатель итоговой величины современных затрат, тыс.руб. 0т Pentium 233 МГЦ 32 Windows 9X, MS Access, MSDE 4 1 3 15 124,3 311,4 435,7 0т Pentium 233МГЦ 32 Windows 9X, Borland Delphi, MS SQL Server 4 1 3 15 196,1 253,2 449,9 Выводы Сравнение сумм современных затрат по двум рассматриваемым нами вариантам вложений инвестиций показывает, что предпочтительным для финансирования является основной вариант проекта, для осуществления которого при прочих равных условиях требуется меньшая современная сумма затрат.
6. Экологическая часть. 6.1. Характеристика санитарно-гигиенических условий труда Микроклимат Микроклимат производственного помещения определяется температурой (0С), относительной влажностью (%), скоростью движения воздуха (м/с). Согласно ГОСТ 12.1.005-88 «ССБТ. Общие санитарно-гигиенические требования к воздуху рабочей зоны», нормирование параметров микроклимата в рабочей зоне производится в зависимости от периода года, категории работ по энергозатратам, наличия в помещении источников явного тепла.
Работа, которой я занимался во время дипломного проектирования: производимая сидя и сопровождающиеся незначительными физическими напряжениями с энергозатратами до 120 ккал/ч (до 500,5 кДж/ч) относится к лёгкой физической работе категории Ia. В холодный период оптимальная температура согласно ГОСТ 12.1.005-88 для этой категории 22-24 0С, допустимая верхняя граница 25 0С, нижняя 21 0С. Фактическая температура составляет 25 0С.
Оптимальная влажность согласно ГОСТ 12.1.005-88 в данном случае составляет 40-60 %, допустимая – 75 %. Фактическая влажность составляет 50 %. Оптимальная скорость движения воздуха в холодный период для работы категории Ia – не более 0,1 м/с, что и выполнялось на практике. Вредные вещества и пыль В компании «Вэб Плас», в котором я проектировал дипломную работу нет источников вредных выбросов. Фактическая концентрация нетоксичной пыли в помещении значительно ниже предельно допустимой концентрации, равной 2 мг/м3. Микроклимат и вентиляция Для нормализации воздушной среды производится расчёт воздухообмена в производственном помещении. Фактический объём моего рабочего помещения = 5 * 6 * 3 = 90 м3. Количество работающих = 6 чел. На одного работающего приходится 15 м3. Согласно санитарным нормам проектирования промышленных предприятий СН 245-71, в производственных помещениях с объёмом на одного работающего менее 20 м3 следует проектировать подачу наружного воздуха в количестве не менее 30 м3 /ч на одного работающего. Поскольку в рабочем помещении находится в допустимых пределах температура, влажность и концентрация вредных веществ, то нет необходимости проводить расчёт приточного воздуха используя формулы кратности воздухообмена. Необходимая подача наружного воздуха обеспечивается периодически действующей естественной вентиляцией. Вибрация и шум Исходными данными для оценки необходимости защиты людей от шума и проведения соответствующих расчётов является спектр шума, измеренного на рабочем месте. Таблица фактического и нормативного спектра шума на рабочем месте Показатели Среднегеометрические частоты октавных полос, Гц Уровни звука и эквивалентные уровни звука дБА 31,5 63 125 250 500 1000 2000 4000 8000 Уровни звукового давления на рабочих местах дБ Фактические уровни 73 66 56 49 44 39 37 34 33 45 Предельно-допустимые для рабочих мест программистов ЭВМ. 86 71 61 54 49 45 42 40 39 50 На рабочем месте нет превышения предельно-допустимого уровня звукового давления. 6.2. Электрическая безопасность Анализ электрической опасности Анализ электрической опасности целесообразно проводить на примере наиболее опасного двухфазного (двухполюсного) прикосновения. При этом сопротивление тела человека Rч для напряжения 5 В и выше переменного тока 50 Гц можно рассчитать по формуле: кОм где Uпр – напряжение прикосновения. В нашей стране в качестве расчётных значений приняты Rч = 1000 Ом при Uпр= 50 В и выше, при этом продолжительность воздействия тока на человека считается менее 1 с, и Rч =6000 Ом при Uпр= 36 В и менее при длительности воздействия тока более 1с. Следует учитывать что при Uпр около 200 В всегда происходит пробой рогового слоя кожи и Rч становится равным примерно 300 Ом. В моём рабочем помещении используются питающие напряжения 220 В, 50 Гц. Для данных условий стандарт предусматривает следующие нормы для электроустановок. Наибольшие допустимые значения : 1. Нормальный режим работы. Uпр= 2 В, Iч = 0,3 мА. 2. Аварийный режим работы производственных электроустановок. Таблица аварийного режима работы производственных электроустановок. Норм. Вели-чина Продолжительность воздействия tс. 0,01-0,08 0,1 0,2 0,4 0,5 0,8 1,0 Более 1,0 Uпр, В 550 340 160 120 105 75 60 20 Iч, мА. 650 400 190 140 125 75 50 6 Аварийный режим работы бытовых электроустановок. Таблица аварийного режима работы производственных электроустановок. Нормируемая величина Продолжительность воздействия tс. 0,01-0,08 0,1 0,2 0,4 0,5 0,8 1,0 Более 1,0 Uпр, В 220 200 100 55 50 30 25 12 Iч, мА. 220 200 100 55 50 30 25 2 Необходимые меры Моё рабочее помещение сухое (50 %), нежаркое (25 0С), с токонепроводящим полом, без токопроводящей пыли, отсутствует возможность одновременного прикосновения человека к имеющим соединение с землёй металлоконструкциям зданий, технологическим аппаратам, механизмам и т. п. c одной стороны и к металлическим корпусам электрооборудования, которые при пробое изоляции могут оказаться под напряжением, - с другой.
Следовательно, помещение относится к помещениям без повышенной опасности. Согласно ГОСТ 12.1.030-81 в таких помещениях защитному заземлению и занулению подлежат металлические нетоковедущие части оборудования при напряжении ³ 380 В переменного и ³ 440 В постоянного тока. Во взрывоопасных помещениях все установки обязательно заземляются независимо от величины питающих напряжений. Поскольку помещение без повышенной опасности и U = 220В, то металлические нетоковедущие части оборудования в заземлении и занулении не нуждаются. 6.3. Пожарная безопасность Основными причинами пожаров от электроустановок является короткое замыкание, перегрузка, большое переходное сопротивление, искрение и электрическая дуга. Эффективным средством защиты электрооборудования от токов перегрузки и короткого замыкания является использование плавких предохранителей и автоматов защиты. Наиболее широкое применение получили стеклянно- плавкие предохранители (СП) и малоинерционные предохранители (МП). Значение тока плавкой вставки определяют из соотношения: Iвст. = (1,21 … 1,37) Iном. где Iном – номинальное значение тока в приборе. Инерционно-плавкие предохранители (ИП), защищают электрические цепи с большими пусковыми токами и рассчитываются по номинальному току потребителя без учёта пусковых токов: Iвст. = (1,25 … 1,5) Iном. Тугоплавкие предохранители (ТП) защищают электрические цепи только от коротких замыканий и не защищают от прегрузок: Iвст. = (1,4 … 1,5) Iном. В моём рабочем помещении применяются сетевые фильтры Pilot GL c Iвст. = 10 А. Стены здания (силикатный кирпич) относятся к несгораемым материалам. Количество эвакуационных выходов должно быть не менее двух. Допускается использование одного эвакуационного выхода, если расстояние от наиболее удалённого рабочего места до этого выхода не превышает 25 м. Из моего рабочего помещения (1 этаж) один выход и расстояние до эвакуационного выхода более 25 м. Для приведения в соответствие стандартам без реконструкции здания необходимо модернизировать решётки на окнах для открытия при пожаре и использовании окон в качестве выхода. По правилам ГОСТ необходимо наличие углекислотного огнетушителя. Это требование выполнено. Предельно допустимые значения излучений В настоящее время весь диапазон радиочастот разбит на 3 поддиапазона: высоких частот /ВЧ/ от 60 кГц до 30 МГц, ультравысоких частот /УВЧ/ от 30 МГц до 300 МГц и от 300 МГц до 300 ГГц. Стандартом (ГОСТ 12.1.006-84) ПДУ нормируются в диапазонах ВЧ и УВЧ предельно допустимые значения напряжённости электрического поля Е /В/м/ и магнитного поля Н /А/м/, а в диапазоне СВЧ – предельно допустимая плотность потока энергии /ППЭ, Вт/м2/. Установлены следующие предельно допустимые значения Е и Н: Е /В/м/ - 50 в диапазоне 60 кГц … 300 МГц, - 20 в диапазоне 3 МГц … 30 МГц, - 10 в диапазоне 30 МГц … 50 МГц, - 5 в диапазоне 50 МГц … 300 МГц, Н /А/м/ - 5 в диапазоне 60 кГц … 1,5 МГц, - 0,3 в диапазоне 30 кГц … 50МГц. Предельно допустимую плотность потока энергии ЭМП в диапазоне частот 300 МГц … 300 ГГц на рабочих местах и в местах возможного нахождения персонала, связанного с воздействием ЭМП, устанавливают исходя из допустимого значения энергетической нагрузки на организм и времени пребывания в зоне облучения, однако во всех случаях она не должна превышать 10 Вт/м2 / 1000 мкВт/см2/, а при наличии рентгеновского излучения или высокой температуры воздуха в рабочих помещениях /выше 280С/ - 1 Вт/ м2 / 100 мкВт/см2 /. 6.4. Требования к рабочему месту программиста и режимам работы Требования к видео дисплейному терминалу (ВДТ) ВДТ должен иметь гигиенический сертификат соответствия нормам эргономичности и безопасности. Конструкция ВДТ должна обеспечивать комфортное, надёжное считывание информации. Должна быть возможность фронтального наблюдения экрана поворотом корпуса в горизонтальной плоскости вокруг вертикальной оси в пределах ±300 и вокруг вертикальной оси в пределах ±300. Системный блок и монитор должны иметь матовую поверхность с коэффициентом отражения 0,4 – 0,6, без блестящих деталей. ВДТ на моём рабочем месте имеет гигиенический сертификат соответствия нормам эргономичности и безопасности. Визуальные эргономические параметры. 1. Яркость знака (фона) кд/кв.м. минимальная – 35, максимальная – 120. 2. Внешнее освещение минимальное – 100, максимальное – 250. 3. Угловые размеры знака 16-60. Должна присутствовать регулировка яркости и контрастности. Требования по визуальным эргономическим параметрам выполнены. Используемые в ЗАО "Вэб Плас" (где я проходил практику) ВДТ соответствуют визуальным эргономическим параметрам. Защита от излучения. Хотя современные мониторы обладают значительно более безопасными характеристиками по электромагнитному и ионизирующему излучению, но излучение, всё-таки имеет место. От электромагнитных и электростатических полей допускается применение приэкранных фильтров, специальных экранов и других средств индивидуальной защиты, имеющих гигиенические сертификаты. Мощность рентгеновского излучения на расстоянии 0,05 м от монитора не должна превышать 7,74*10 А/кг., то есть 0,1 мбер/час (100 мр/час). Мощность рентгеновского излучения на расстоянии 0,05 м от монитора не превышает 7,74*10 А/кг на всех ВДТ в компании «Вэб Плас». Вышеназванные параметры относятся к лицевой стороне ВДТ. Но гораздо более значительное излучение идёт от электронно-лучевой трубки в обратную от пользователя сторону . Это не имело бы существенного значения, если бы все мониторы стояли задней частью к стене или другому, не пропускающему излучение материалу. Два рабочих места не удовлетворяют этому условию. Необходимо либо переставить мониторы так, чтобы они не направляли значительное излучение в направлении, в котором могут находиться люди, либо установить перегородку из не пропускающего излучение материала. При воздействии излучений могут быть использованы следующие способы защиты: - защита временем; - защита расстоянием; - экранирование источника излучения или рабочего места; - применение индивидуальных средств защиты. От ионизирования воздуха необходимо проводить профилактику: распыление воды в помещении (например перед перерывом).
Поскольку нет возможности полностью избавиться от излучения, необходимо применять защиту временем. Надо ограничить время работы непосредственно за монитором до максимум 6 часов. Вредное излучение можно устранить путём перехода на жидкокристаллические мониторы, работающие по другому принципу и практически не имеющие вредных излучений.
Требования к клавиатуре Необходимо наличие возможности свободного перемещения. - изменение угла наклона клавиатуры 5 – 150; - высота ряда клавиш не более 30 мм; - наиболее часто используемые клавиши должны находиться в центре, а менее используемые по бокам, сверху и снизу. - необходимо выделение цветом функциональных клавиш, начертание разными цветами букв русского и латинского алфавита; - оптимальный размер клавиши – 15 мм; - у всех клавиш должен быть одинаковый ход. На фактически применяющихся клавиатурах в моей организации эти требования выполнены. Требования к помещению и рабочему месту Требования к помещению Коэффициент естественного освещения не менее 1,2%. Естественный свет должен падать сбоку, желательно слева. Площадь рабочего места не менее 6 м2, объём не менее 20 м3. Расстояние между рабочими столами не менее 2 м. Между боковыми местами не менее 1,2 м. Помещение не должно граничить с помещением с источником шума; должно быть отапливаемым, кондиционируемым, с вытяжной вентиляцией. Требования к внутренней отделке. Коэффициент отражения поверхности потолка 0,7 – 0,8, стен 0,5 – 0,6, пола 0,3 – 0,5. Фактически не выполняется требование по объёму рабочего пространства минимальное – 20 м3 , фактическое 16 м3. Необходимо переместить одного работника в другое помещение. Требования к рабочему месту Эргономические параметры стола должны соответствовать современным стандартам. - высота: 680 – 800 мм. - минимальная высота рабочей поверхности – 725 мм. - ширина не менее 800 мм; - глубина не менее 450 мм. Высота спинки стула – 300 ± 20 мм. Угол наклона спинки стула ± 30°. Высота подлокотника не менее 250 мм, ширина 55 – 70 мм. В соответствии со способом защиты от излучения расстоянием расстояние от работника до экрана ВДТ должно быть 600 – 700 мм, минимум 500 мм. Требования к рабочему месту на моём рабочем месте были выполнены. Объём работы за компьютером Нормативы работы за компьютером Работа за компьютером подразделяется на 3 категории: А – работа по считыванию информации с экрана с предварительным запросом. В – работа по вводу информации. С – творческая работа в режиме диалога с машиной. Основная – та работа, которая выполняется более 50% рабочего времени. Устанавливаются 3 категории тяжести: Для работ А по суммарному числу считанных знаков за смену - не более 60000. Для работ В по суммарному числу введённых знаков за смену – не более 40000. Для работ С – по суммарному времени непосредственной работы с ПЭВМ – не более 6 часов в день. Фактическая работа за компьютером Работа, которой я занимался при дипломном пректировании относится к работам типа С. Продолжительность рабочего дня – 8 часов. Для выполнения нормативов при необходимости постоянной работы нужно каждый час делать перерыв в 15 минут. Суммарное время работы составит 6 часов. Фактически такой график не всегда выполнялся: время работы за компьютером превышало 6 часов. Медицинское обслуживание К работе на ПЭВМ должны допускаться лица без медицинских противопоказаний. Необходимо предварительное медицинское обследование каждого работника. К работе на ПЭВМ не допускаются беременные и женщины во время кормления. Меры профилактики. В помещения с ПЭВМ должна проводится влажная уборка минимум 2 раза день (чем чаще тем лучше). Необходимо наличие аптечки, углекислотного огнетушителя. Фактически влажная уборка производится 1 раз в день, есть аптечка и углекислотный огнетушитель.
7. Заключение. В результате работы над дипломным проектом была создана информационная система для учета комиссионного вознаграждения сотрудников отдела продаж компании «Вэб Плас». Данная система сократит время работы менеджера по продажам при работе с показателями отдела, также позволить за короткое время получить самую свежую информация, что очень важно при принятии управленческих решений. Созданные удобные интерфейсы упростят механизм внесения информации о заключенных сделках, что сэкономит время сотрудников отдела продаж при работе с комиссионными. Разработанная информационная система, благодаря использованию MS Accss полностью совместима с MS Office. Это позволит легко переносить любые данные из базы данных в Word или Excel для последующего анализа и частичного редактирования. Данный дипломный проект разрабатывался не с коммерческой целью, а с целью удовлетворения потребностей определенного заказчика. Тем не менее разработанный программный продукт мог бы быть перенесен в адптирован под нужды другого заказчика. Подводя итог, можно отметить, что рассматритваемый проект имеет фактическое применение и использует самые соверменные технологий.
8. Список использованной литературы. 1. Федеральная целевая программа "Электронная Россия" на 2002 - 2010 годы, http://www.economy.gov.ru/erussia.html 2. Грабер Мартин. «Введение в SQL». Пер. с англ. - М.: Издательство “ЛОРИ”, 1996. - 375 с. 3. Горев А., Ахаян Р., Макашарипов С. «Эффективная работа с СУБД» - СПб.: Питер, 1997. –704 стр. 4. Пол Литвинг, Кен Гетц, Майкл Гилберт, «Access 2000. Руководство разработчика. Том 2. Корпоративные приложения». Пер. с англ., Издательская группа BHV, Киев, 2001 – 912 c. 5. Харитонова И.А., Михеева В.Д., «Microsoft ACCESS 2000: разработка приложений», Издетельство «БХВ-Санкт-Петербург», 2000 – 832 с. 6. Артемьев В. И., «Обзор способов и средств построения информационных приложений», 30.09.1996 http://www.osp.ru/dbms/1996/05/52.htm 7. Власов А.И., Лыткин С.Л., Яковлев В.Л., «Краткое практическое руководство разработчика информационных систем на базе субд Oracle». Москва, 2000 г., http://www.citforum.ru/database/oraclepr/index.shtml 8. Дино Эспозито , «OLE DB или ODBC? Семь раз отмерь». Журнал "Windows 2000 Magazine", #01, 2000 год. Издательство "Открытые Системы" (www.osp.ru), http://www.osp.ru/win2000/2000/01/063.htm [1] Федеральная целевая программа "Электронная Россия" на 2002 - 2010 годы, http://www.economy.gov.ru/erussia.html [2] Аббревиатура OLE расшифровывается как Object Linking and Embedding и обозначает собой стандарт, поддерживаемый операционными системами Windows, который позволяет создавать объекты с помощью одного приложения и внедрять их затем в данные другого приложения или ссылаться на него из другого приложения. [3] Common Object Model. Программная архитектура Microsoft, поддерживающая компонентный подход к разработке при ложений.