3.4 Выбор архитектуры функционирования подсистемы документооборота

Применение Internet-технологий и Intranet-технологий в корпоративной сети в российских и зарубежных банках получает все более широкое распространение. Существует множество причин такого стремительного развития, но основными являются максимум удобства и возможность предлагать более выгодное обслуживание для клиентов и пользователей. Другой немаловажной причиной развития данной технологии является то, что пользователю для доступа к web-приложению достаточно использование только браузера в качестве необходимого клиентского программного обеспечения, что значительно уменьшает административные расходы на покупку и установку программных продуктов [15].

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

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

Основные преимущества при использовании Intranet-технологией.

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

На рисунке 3.9 изображена трехуровневая архитектура функционирования подсистемы документооборота.

Рисунок 3.9 - Архитектура функционирования подсистемы документооборота

Если перечислять слева направо, это WEB - броузер на клиентском компьютере, web-сервер, Active-Directory сервер (контроллер домена), сервер базы данных. Каждый из этих уровней может работать под управлением своей операционной системы. В минимальной конфигурации вся серверная часть, разработанного ПО, может работать на одном сервере.

В Северо-Кавказском банке на сегодняшний день применяется следующее операционные системы:

- операционные системы Windows 2000, Windows XP - на рабочих станциях пользователей ЛВС;

- операционные системы Windows 2000 Server, Windows 2003 Server, IBM AIX 5.3, Solaris 8 - на серверах ЛВС.

Система разрабатывается как веб-приложение на платформе Windows. Основные программно-аппаратные требования к серверу и клиентскому рабочему месту выглядят следующим образом:

Требования к серверам:

- PIV 3 Ггц, RAM 5Гб;

- Windows 2003 Server SP1, IIS 6.0;

- MS SQL 2005 SP2.

Требования к клиентскому рабочему месту:

- Windows 2000 SP4, Windows XP SP2;

- Internet Explorer 6.0 и выше.

Для доступа к серверам баз данных используются стандартные технологии Microsoft. Стандарт ODBC (Open Database Connectivity standard) - это интерфейс, с помощью которого прикладные программы могут обращаться к SQL-базам данных и обрабатывать их независимым от СУБД способом. ODBC важен для систем баз данных, использующих web-технологии, потому что можно разработать приложение, которое будет обрабатывать базы данных, поддерживаемые различными СУБД. OLE DB - это то, на чем основывается доступ к данным в мире Microsoft. OLE DB - объектно-ориентированный интерфейс, имеющий функциональность сервера данных. OLE DB был разработан не только для реляционных баз данных, но и для многих других типов источников данных. Будучи СОМ-интерфейсом, OLE DB непосредственно доступен из C++, С# и Java, но недоступен из Visual Basic и сценарных языков. Поэтому компания Microsoft разработала ADO (Active Data Objects) - набор объектов, позволяющий использовать OLE DB из любых языков программирования [19].

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

3.5 Проектирование информационной базы данных

Современные CASE (Computer-Aided Software Engineering) - средства охватывают обширную область поддержки многочисленных технологий проектирования информационных систем (ИС): от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл программного обеспечения (ПО) [17].

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

Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла ПО и обладающее следующими основными характерными особенностями:

- мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности;

- интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки ИС;

- использование специальным образом организованного хранилища проектных метаданных (репозитория).

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

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

Одна из наиболее распространенных программ автоматизации разработки баз данных - AllFusion ERwin Data Modeler фирмы Computer Associates International. Эта программа позволяет не только спроектировать, но и создать базу данных на сервере.

В данном дипломном проекте при проектировании базы данных использовалось CASE-средство CA ERwin Data Modeler version 7.1.2.

CA ERwin Data Modeler (ERwin) - CASE-средство для проектирования и документирования баз данных, которое позволяет создавать, документировать и сопровождать базы данных, хранилища и витрины данных. Модели данных помогают визуализировать структуру данных, обеспечивая эффективный процесс организации, управления и администрирования таких аспектов деятельности предприятия, как уровень сложности данных, технологий баз данных и среды развертывания [18].

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

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

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

ERwin не привязан к технологии какой-либо конкретной фирмы, поставляющей СУБД или средства разработки. Он поддерживает различные серверы баз данных и настольные СУБД, а также может обращаться к базе данных через интерфейс ODBC. В текущей версии ERwin встроена поддержка следующих СУБД: Oracle, DB2/UDB (включая iSeries), SQL Server, Teradata, ODBC, Sybase, Informix, Ingres, Progress, Access. Заметим лишь, что речь идет только о реляционных СУБД.

Ниже приводятся функциональные возможности ERwin:

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

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

- Управление большими моделями. ERwin помогает управлять большими корпоративными моделями с помощью предметных областей (Subject Areas) и хранимых отображений (Stored Displays). Предметные области предоставляют сфокусированное представление для отдельных специалистов по моделированию, делящее модель на меньшие управляемые подмножества. Хранимые отображения предлагают различные графические представления модели или ее предметных областей, что облегчает обмен информацией между специализированными группами пользователей.

- Полное сравнение. Эта мощная функция автоматизирует полную двунаправленную синхронизацию моделей, сценариев и БД.

- Генерация дизайна баз данных. ERwin включает в себя оптимизированные шаблоны триггеров целостности ссылочных данных и широкофункциональный межплатформенный макроязык для БД, позволяющий настраивать триггеры и хранимые процедуры. Настраиваемые шаблоны облегчают создание физического дизайна и полных определений (в соответствии с конечной БД).

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

- Отчеты и распечатки. ERwin предоставляет гибкие и настраиваемые возможности для создания отчетов и вывода на печать. Отчеты можно генерировать в различных форматах, включая html, pdf, rtf и txt.

Таким образом, CASE средство AllFusion ERwin Data Modeler является идеальным средством проектирования реляционных баз данных.

Процесс моделирования в ERwin Data Modeler базируется на методологии проектирования реляционных баз данных IDEF1X.

Метод IDEF1X, разработанный Т. Рэмей, также основан на подходе Питера Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. Основными компонентами данной модели являются сущность, связь, атрибут. Сущность - это любой реальный или представляемый объект, информацию о котором необходимо хранить в базе данных. Связь - это ассоциация двух или более сущностей. Атрибут - именованная характеристика сущности, представляющая собой элементарную единицу структуры понятия [17].

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

IDEF1X является методом для разработки реляционных баз данных и использует условный синтаксис, специально разработанный для удобного построения концептуальной схемы. Концептуальной схемой называется универсальное представление структуры данных в рамках коммерческого предприятия, независимое от конечной реализации базы данных и аппаратной платформы. Использование метода IDEF1X наиболее целесообразно для построения логической структуры базы данных после того, как все информационные ресурсы исследованы и решение о внедрении реляционной базы данных, как части корпоративной информационной системы, было принято.

Разработку информационных систем принято разбивать на следующие этапы:

- этап анализа предметной области;

- этап проектирования;

- этап непосредственного кодирования;

- этап тестирования и сопровождения.

Для построения логической модели, прежде всего, необходимо определить набор сущностей и задать связи между ними. По результатам обследования предметной области можно выделить несколько объектных областей с необходимым набором сущностей:

1. Пользователи системы:

- пользователь.

2. Права и роли пользователей системы:

- права пользователей;

- роль пользователя.

3. Структурные подразлеления:

- ОСБ;

- подразделения;

4. Руководители и исполнители подразделений:

- руководители;

- исполнители.

5. База зарегистрированных документов:

- типы документов;

- зарегистрированные документы.

ERwin DM имеет два уровня представления модели - логический и физический. Логический уровень - это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД. В данном дипломном проекте на логическом уровне разработана ER-диаграмма на уровне атрибутов (рисунок 3.10).

Рисунок 3.10 - ER-диаграмма на логическом уровне

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

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

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

Неидентифицирующая связь - это связь между независимыми сущностями.

Рисунок 3.11 - Изображение связей в нотации IDEF1X

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

На рисунке 3.12 представлена ER-диаграмма на физическом уровне.

Рисунок 3.12 - ER-диаграмма на физическом уровне

Реализация хранимых процедур.

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

Хранимые процедуры могут:

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

- принимать входные параметры;

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

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

Хранимые процедуры имеют много преимуществ, перечислим их:

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

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

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

- Повышают производительность. Хранимые процедуры реализуют многие задачи как последовательность инструкций Transact-SQL.

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

- Уменьшают уязвимость по отношению к атакам с использованием изменения SQL-запроса. Использование явно определенных параметров в коде SQL уменьшает возможность отправки хакерами внедренных инструкций SQL в значения параметров.

CASE-средство ERwin позволяет проектировать хранимые процедуры на языке Transact-SQL. На рисунке 3.13 представлено диалоговое окно "Stored Procedures", где выбрана хранимая процедура "SP_ADMIN_ADDNEWUSER". В вкладке "Code" можно отредактировать код данной процедуры (в качестве примера листинг процедуры "SP_ADMIN_ADDNEWUSER" представлен в Приложении A). Полный список хранимых процедур для подсистемы документооборота представлен на рисунке 3.14.

Рисунок 3.13 - Диалоговое окно создания хранимых процедур



Рисунок 3.14 - Список хранимых процедур системы

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

Microsoft Active Server Pages (ASP - активные серверные страницы) - представляют собой инструмент для эффективной разработки серверных web-приложений, интегрирующих в своем составе HTML-код, VBScript, JavaScript и компоненты ActiveX. Технология ADO позволяет писать клиентские приложения для доступа и манипулирования данными, хранящимися в БД. Основными преимуществами ADO являются простота использования, высокая скорость, требуемый малый объем памяти и дискового пространства. Для вызова параметризованных хранимых процедур и получения от них возвращаемых значений используются объекты Connection, Recordset и Command - основные элементы ADO для взаимодействия с данными [15].

Выбор СУБД.

В настоящее время в Северо-Кавказском банке Сбербанка России в основном используются СУБД семейства MS SQL Server. В данном дипломном проекте использовалась СУБД Microsoft SQL Server 2005 SP2.

Microsoft SQL Server 2005 является решением следующего поколения для управления и анализа данных, которое предоставляет повышенную безопасность, стабильность данным предприятия и аналитическим приложениям, облегчая их построение, развёртывание и управление [19]. СУБД SQL Server 2005 представляет собой интегрированное решение по управлению и анализу данных, которое поможет организациям различного масштаба:

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

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

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

- Контролировать стоимость, не жертвуя качеством выполнения, доступностью, масштабируемостью и безопасностью.

Microsoft SQL Server 2005 упрощает развёртывание, управление и оптимизацию данных предприятия и аналитических приложений. Как платформа управления данными предприятия, он предоставляет единую консоль управления, которая позволяет администраторам данных, находящимся в любом месте вашей организации, отслеживать, управлять и настраивать все базы данных и связанные службы по всему предприятию. Продукт Microsoft SQL Server 2005 представляет собой нечто большее, чем просто систему управления базами данных и состоит из большого количества компонентов, выполняющих различные функции.

Microsoft SQL Server 2005 включает в себя:

- Ядро SQL Server по управлению базами данных - это самый важный компонент, отвечающий за организацию хранения и безопасности данных, а также позволяющий модифицировать и обновлять данные. Новое ядро обеспечивает возможность хранения XML и работы с ним на уровне БД, новую систему безопасности, работу с разделенными таблицами, DDL триггера и многое другое.

- Analysis Service (аналитическая служба) - позволяет организовать работу с OLAP базами данных.

- SQL Server Integration Service - этот компонент позволяет создавать решения, предназначенные для экспорта и импорта данных между различными источниками.

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

- Reporting Service - позволяет создавать различного рода отчеты на основе выбранных данных.

- Service Broker - механизм, позволяющий управлять очередью сообщений между различного рода службами.

- Встроенная поддержка HTTP - данный компонент позволяет взаимодействовать с SQL Server через HTTP.

- Replication (репликация) - технология, позволяющая распределять данные и объекты на различные сервера с последующей их синхронизацией.

- Full-text Search (Полнотекстовый поиск) - позволяет организовывать быстрые индексы для организации поиска по текстовым полям;

- интеграция с CLR - за счет этой возможности решения могут включать хранимые процедуры, триггера, типы, функции, реализованные на С# или VB.NET.

Генерация схемы базы данных в ERwin.

Перед генерацией БД в системе ERwin DM необходимо выбрать целевой сервер, который можно выполнить несколькими способами:

- На этапе создания новой модели - диалоговое окно Create Model - Select Template (Создание модели - Выбор шаблона).

- Только на физическом уровне - через диалоговое окно "ERwin Data Modeler - Target Server" (рисунок 3.15), вызываемое в главном меню "Database" | "Choose Database...".

Диалог "ERwin Data Modeler - Target Server" позволяет задать тип и версию сервера, тип данных и условие NULL для вновь созданных колонок.

Рисунок 3.15 - Диалоговое окно выбора целевого сервера

В данном диалоговом окне, в блоке Target SQL DBMS необходимо выбрать переключатель SQL Server, а в раскрывающемся списке SQL Server Version - 2000/2005.

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

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

Эти установки задаются в диалоговом окне генератора схем Forward Engineer Schema Generation (рисунок 3.16).

Рисунок 3.16 - Диалог генератора физической схемы БД

При нажатии на кнопке Generate появится окно SQL Server Connection (рисунок 3.17), в котором необходимо указать имя сервера и название базы.

Рисунок 3.17 - Окно соединения с сервером базы данных

Для генерации БД необходимо нажать на кнопку Connect, после чего откроется окно Generate Database Schema (рисунок 3.18) c SQL-сценарием разрабатываемой подсистемы документооборота.

Рисунок 3.18 - Окно генерации базы данных

После проведенной процедуры сгенерированная база данных в системе Microsoft SQL Server 2005 выглядит следующим образом (рисунок 3.19).

Рисунок 3.19 - Диаграмма ИБД в Microsoft SQL Server Management Studio

3.6 Разработка клиентского приложения

3.6.1 Выбор web-сервера и среды разработки веб-приложения

Критериями выбора Web-серверов могут служить различные характеристики: установка, настройка конфигурации, управление сервером, администрирование, управление содержательным материалом, защита информации, контроль доступа, функции разработки приложений и производительность.

В Северо-Кавказском банке на сегодняшний день большинство серверов ЛВС работают под управлением операционных систем MS Windows, поэтому подсистема документооборота разрабатывалась для работы на сервере приложений Internet Information Services (IIS) 6.0, который является составной частью операционной системы Microsoft Windows Server 2003. IIS - ключевой компонент платформы приложений Windows Server 2003, представляет собой интегрированный набор сервисов и средств, обеспечивающих разработку и развертывание высокопроизводительных web-сайтов, web-приложений и web-сервисов [21].

В качестве среды разработки web-приложения подсистемы документооборота использовался Microsoft Office FrontPage 2003.

В качестве языков программирования для создания серверных страниц использовались HTML, VBScript, JavaScript.

ASP (Active Server Pages) - это мощная технология от Microsoft, позволяющая легко разрабатывать приложения. ASP работает на платформе Windows NT и IIS (Internet Information Server), начиная с версии 3. ASP - это не язык программирования, это внутренняя технология, позволяющая подключать программы к web-страницам. Основа успеха ASP - простой скриптовый язык (Visual Basic Script или JavaScript) и возможность использования внешних COM-компонент. Программные фрагменты заключаются в скобки <% %>.

Когда браузер клиента запрашивает файл, файл сначала интерпретируется сервером, на выходе производится HTML-код. Далее этот HTML-код посылается клиенту. Файлы с программами имеют расширение .asp. Файлы asp - это обычные текстовые файлы, содержащие исходные тексты программ.

Каталог, в котором размещены файлы asp, должен иметь права на выполнение, так как сервер исполняет эти файлы, когда браузер их запрашивает. Из ASP можно легко и просто работать с любыми базами данных. Это делается через две промежуточные технологии: ODBC и ADO.

Механизм доступа к БД на стороне сервера реализуется за счет наличия стандартизованных средств:

- поддержки диалоговых форм на уровне гипертекста (HTML);

- возможности запуска серверных программ, взаимодействие которых происходит через стандартный интерфейс CGI или прикладные интерфейсы Web-сервера.

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

3.6.2 Разработка системы разграничения доступа к данным

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

В данном дипломном проекте разрабатываемая подсистема документооборота использует разграничение доступа средствами Microsoft Active Directory (пользователь авторизуется в домене предприятия), СУБД (хранимыми процедурами), а также средствами технологии Microsoft - ASP (Active Server Pages).

3.7 Выводы

В третьем разделе проведено проектирование подсистемы документооборота ОАО "Сбербанк России" Северо-Кавказского банка. В процессе проектирования обоснована необходимость проектирования, проведен анализ общих принципов организации подсистемы документооборота. Приведены основные понятия делопроизводства и документооборота, определены основные действующие лица документооборота, основные понятия и типовые процессы документооборота. Описана технологическая схема работы подсистемы документооборота.

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

Дано детальное описание проектирования информационной базы данных с использованием CASE-средства CA ERwin Data Modeler. ERwin - это средство для проектирования и документирования баз данных, которое позволяет создавать, документировать и сопровождать базы данных, хранилища и витрины данных. Описаны и приведены в качестве рисунков два уровня представления модели ERwin DM - логический и физический.

В качестве СУБД выбрана Microsoft SQL Server 2005. Данная СУБД позволяет строить, развертывать и управлять промышленными приложениями, которые являются более безопасными, масштабируемыми и надежными, также позволяет увеличивать продуктивность информационных технологий, уменьшая сложность построения, развертывания и управления приложениями по работе с базами данных.

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

4. РАБОЧАЯ ДОКУМЕНТАЦИЯ НА ПРОЕКТ

4.1 Описание подсистемы документооборота

Разработанная информационная подсистема документооборота Северо-Кавказского банка Сбербанка Росси с web-интерфейсом позволяет упростить и автоматизировать внутренний документооборот предприятия. Внедрение данной подсистемы документооборота может дать следующие преимущества:

- ускорение доставки электронной корреспонденции от исполнителя к адресату;

- уменьшение отрицательного влияния человеческого фактора на при передаче электронной корреспонденции;

- возможность организовать полноценный корпоративный электронный архив документов;

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

4.2 Руководство администратора

4.2.1 Настройка сервера приложений

Для работы подсистемы документооборота администратору сервера необходимо проинсталлировать сервер приложений IIS 6.0, создать виртуальный каталог и скопировать из дистрибутива файлы (рисунок 4.1).

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

Рисунок 4.1 - Виртуальный каталог подсистемы документооборота

Так как пользователь подсистемы документооборота должен авторизоваться средствами операционной системы (рисунок 3.9), для этого необходимо отключить анонимный доступ и выбрать встроенную проверку подлинности Windows. Эта процедура позволяет блокировать доступ пользователей не прошедших авторизацию в Active Directory (рисунок 4.2).

Рисунок 4.2 - Безопасность виртуального веб-каталога

4.2.2 Генерация базы данных MS SQL Server

На сервере СУБД MS SQL Server необходимо создать базу данных

Рисунок 4.3 - Создание новой базы данных

После создания базы данных, в Microsoft SQL Server Management Studio необходимо открыть и запустить ранее созданный в ERwin SQL-сценарий (create_objects.sql) (рисунок 4.4).

Рисунок 4.4 - Создание таблиц и хранимых процедур

4.2.3 Создание технологических учётных записей

Для того чтобы из web-приложения можно было запускать хранимые процедуры, читать и обновлять записи в таблицах ИБД подсистемы документооборота, необходимо создать технологическую учётную запись "BANK\DELO_ADMIN" (рисунок 4.5) с ролью "db_owner" ранее созданной базы и схемой по умолчанию "dbo" (рисунок 4.6).

Рисунок 4.5 - Создание технологической учётной записи

Рисунок 4.6 - Раздача привилегий технологической учётной записи

Для считывания информации в Active Directory о пользователе, желающем получить доступ к подсистеме документооборота, необходимо создать технологическую учётную запись "delo_admin". Для этого администратору домена необходимо запустить - оснастку "Active Directory - пользователи и компьютеры" (рисунок 4.7) и создать пользователя delo_admin.

Рисунок 4.7 - Создание технологической учётной записи

Затем в следующем окне задайте пароль пользователя и нажмите кнопку "Далее" и в следующем нажмите кнопку "Готово".

4.2.4 Создание и настройка источника данных ODBC

Для доступа к базе данных с web-сервера необходимо создать источник данных для SQL сервера (см. рисунок 4.8, рисунок 4.9 и рисунок 4.10).

Рисунок 4.8 - Создание источника данных для SQL сервера

Рисунок 4.9 - Создание источника данных для SQL сервера

Рисунок 4.10 - Создание источника данных для SQL сервера

4.2.5 Завершение настройки сервера

В разработанной подсистеме документооборота предусмотрена возможность ведения электронного архива документов на сервере. Для этого на одном из дисков сервера необходимо создать директорию (например: E:\ARCHIVE) и дать право на "Полный доступ" группе "BANK\Пользова- тели домена" (рисунок 4.11).

Рисунок 4.11 - Создание директории для ведения архива документов

После этого необходимо отредактировать и сохранить конфигурационный файл global.asa, находящийся в директории, созданной в п. 4.2.3.:

- Application("DBName") = "DELO"; // имя ODBC источника;

- Application("SQLServerUserName") = "DELO_ADMIN"; технологический пользователь, созданный на SQL-сервере;

- Application("SQLServerUserPassword") ="123456"; //пароль технологического пользователя, созданного на SQL-сервере;

- Application("DomainUserName") = "delo_admin@bank"; //технологи- ческий пользователь, созданный в Active Directory;

- Application("DomainUserPassword") = "123456"; //пароль технологи-ческого пользователя, созданного в Active Directory;

- Application("UploadsDirVar") = "E:\\Archive";//директория архивов документов.

4.3 Руководство пользователя

Разработанная информационная подсистема документооборота Северо-Кавказского банка Сбербанка Росси с web-интерфейсом позволяет упростить и автоматизировать внутренний документооборот организации.

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

- Администратор-ТБ (регистрация новых ОСБ, подразделений, руководителей, администраторов ОСБ);

- Администратор-ОСБ (регистрация новых пользователей ОСБ, просматривать список подразделений, исполнителей в подразделениях ОСБ, назначение прав пользователей, блокировка пользователей);

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

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

Учитывая то, что в Северо-Кавказском банке за обеспечение централизованного документооборота отвечает подразделение - "Общий отдел", следовательно администраторами автоматизируемой системы должны являться сотрудники указанного подразделения.

Произведём первоначальную настройку системы. Создадим ОСБ под названием "Аппарат ТБ", затем создадим подразделение "Общий отдел" и руководителя, а в завершение создадим пользователя с ролью "Администратор-ТБ".

Для этого необходимо открыть в веб-браузер и набрать в адресной строке браузера: http://имя_сервера/виртуальный_каталог/setup.asp. В результате появится страница с формой на регистрацию нового ОСБ (рисунок 4.12).

Рисунок 4.12 - Запуск первоначальной настройки приложения

Рисунок 4.13 - Первоначальная настройка приложения. Регистрация нового ОСБ

После успешного создания ОСБ, необходимо зарегистрировать нового руководителя ОСБ (рисунок 4.14).



Рисунок 4.14 - Первоначальная настройка приложения. Регистрация нового руководителя ОСБ.

После успешной регистрации нового руководителя ОСБ, необходимо зарегистрировать новое подразделение ОСБ (рисунок 4.15).

Рисунок 4.15 - Первоначальная настройка приложения. Регистрация нового подразделения ОСБ.

В следующем шаге необходимо зарегистрировать нового администратора-ТБ (рисунок 4.16, рисунок 4.17). Для этого запускается форма поиска пользователя в Active Directory, где необходимо ввести сетевое имя пользователя или фамилию. Затем, выбрав нужного пользователя и нажать кнопку "Создать".

Рисунок 4.16 - Первоначальная настройка приложения. Запуск регистрации нового администратора-ТБ.

Рисунок 4.17 - Первоначальная настройка приложения. Регистрация нового администратора-ТБ

Итак, первоначальная настройка приложения закончена. Далее можно уже войти в систему Администратором-ТБ. Для этого необходимо авторизоваться в домене "BANK" под учётной записью "OPAL" и набрать в адресной строке браузера (рисунок 4.18): http://имя_сервера/виртуальный_каталог/. После этого данный пользователь может создавать и просматривать ОСБ, создавать и просматривать администраторов ОСБ, создавать и просматривать подразделения и их руководителей. Пользователи данной системы, входят в систему через форму входа. При нажатии на кнопку "Вход" система опрашивает текущее имя авторизовавшегося пользователя и его домен, ищет в базе такого пользователя и в зависимости от результата поиска либо пропускает дальше, либо выдаёт ошибку.

Рисунок 4.18 - Форма входа в подсистему документооборота

На рисунке 4.19, рисунке 4.20 и рисунке 4.21 представлены меню администратора-ТБ, администратора-ОСБ и обычного пользователя соответственно.

Рисунок 4.19 - Меню администратора-ТБ

Рисунок 4.20 - Меню администратора-ОСБ

Рисунок 4.21 - Меню пользователя

4.4 Описание контрольного примера

В качестве контрольного примера проверки работоспособности разработанной подсистемы документооборота Северо-Кавказского банка Сбербанка России, смоделируем ситуацию: из подразделения "Общий отдел" необходимо отправить в подразделение "Управление по работе с персоналом" служебную записку " Об внесении изменений в график отпусков Борцова А.А." за подписью начальника общего отдела Княжева Сергея Николаевича. Для этого делопроизводитель подразделения Москвина Галина Ивановна выбирает в меню "Работа с документами" > "Исходящие" > "Регистрация различных документов" (рисунок 4.22).

Рисунок 4.22 - Регистрация служебной записки

Далее выбираем вид документа "Служебная записка" и подразделение отправитель "Общий отдел", нажимаем кнопку "Далее" (рисунок 4.22). После этого выбираем исполнителя документа "Никитина Валентина Алексеевна", выбираем руководителя, подписавшего документ "Княжев Сергей Николаевич", вводим содержание документа и нажимаем кнопку "Сохранить" (рисунок 4.23).



Рисунок 4.23 - Регистрация служебной записки

После сохранения документа, в форме регистрации появляется его регистрационный номер и дата регистрации. Чтобы добавить файлы к документу и сохранить на сервере, нажимаем кнопку "Обзор", затем выбираем файл и нажимаем кнопку "Загрузить". К документу можно прикрепить четыре файла, общим размером не более 10 МБ. В следующем окне необходимо выбрать получателей документа и нажать кнопку "Cохранить"

Рисунок 4.24 - Регистрация служебной записки

На этом регистрация и отправление служебной записки завершена.

Каждому документу, сохранённому в подсистеме документооборота, присваивается уникальный идентификационный номер (GUID). Все файлы, приложенные к документу, сохраняются в одноимённой папке на сервере (рисунок 4.25).

Рисунок 4.25 - Проверка сохранения файла в сервере

Далее у делопроизводителя подразделения "Управление по работе с персоналом" Савельева Андрея Владимировича в окне программы, в левом углу экрана (рисунок 4.26), меняется количество новых входящих документов (в данном случае число входящих документов равно "1").

Рисунок 4.26 - Просмотр нового входящего документа

Затем нажимаем "Работа с документами" > "Входящие" > "Просмотр Входящих Документов" и выбираем входящий документ. Если необходимо скачать файл, приложенный к служебной записке, то нажимаем кнопку "Файл №1" и в результате появляется окно, в котором можно открыть файл, либо сохранить его на локальном диске компьютера. После прочтения письма и сохранения вложений можно отправить документ в архив нажав кнопку "Архив".

На этом обработка входящего документа завершена.

4.5 Выводы

В четвертом разделе проведена разработка рабочей документации на проект. Дано описание функционирования подсистемы документооборота ОАО "Сбербанк России" Северо-Кавказского банка.

В руководстве администратора кратко описана настройка сервера приложений в операционной системе Windows 2003 Server, настройка служб Microsoft Internet Information Services 6.0, создание и настройка источника данных ODBC.

В руководстве пользователя показана первоначальная настройка приложения.

В контрольном примере показана отправка служебной записки из подразделения "Общий отдел" в подразделение "Управление по работе с персоналом", обработка входящего документа и сохранения вложений.

5. ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ ПРОЕКТА

5.1 Общая характеристика проекта

Дипломный проект посвящен разработке подсистемы документооборота Северо-Кавказского банка Сбербанка России. При внедрении данного проекта возникает вопрос об экономической эффективности, а также его целесообразности.

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

5.2 Оценка экономической эффективности системы

Оценка эффективности системы необходима для определения форм и методов эффективного создания системы, а затем ее эффективного функционирования.

Экономическая эффективность АС определяется формулой:

, (5.1)

где Р - результат, получаемый от работы системы, руб/год;

З - суммарные затраты на ее создание, руб.

Экономическая эффективность АС характеризуется следующими основными показателями:

1. Экономией (стоимостной оценкой результата), получаемой в t-м году в результате функционирования АС (руб./год).

2. Экономическим эффектом функционирования АС (руб.).

3. Показатели эффективности единовременных затрат на АС (1/год) и сроком возврата этих затрат (лет).

5.2.1 Расчет капитальных затрат

Капитальные затраты - это расходы на покупку или значительным увеличением основного капитала, которым является, например, компьютерное оборудование (здание и основные производственные средства). Их часто называют "разовыми" затратами.

Единовременные затраты на создание системы определяются по формуле:

, (5.2)

где - предпроизводственные затраты, руб;

- капитальные затраты на создание системы, руб.

Предпроизводственные затраты на создание системы определяются по формуле:

, (5.3)

где - затраты на проектирование АС, руб;

- затраты на программирование, руб;

- затраты на подготовку информационного обеспечения длительного пользования, создание базы данных АС, руб;

- затраты на отладку и ввод АС в работу, руб.

Затраты на проектирование и программирование рассчитываются исходя из затраченного времени и почасовой оплаты программиста. Предполагается, что общее руководство проектированием и внедрением подсистемы документооборота осуществляется ведущим специалистом 2 разряда, средняя заработная плата которого составляет 21700 руб. Таким образом, тариф почасовой оплаты программиста составляет 117,00 руб/час. В среднем на проектирование данной системы уйдет два месяца.

Предпроизводственные затраты и их стоимость показаны в таблице 5.1.

Таблица 5.1 - Структура предпроизводственных затрат

Наименование	Сумма, руб.
Затраты на проектирование и программирование	43 056,00
Затраты на создание базы данных	4 950,00
Затраты на отладку и ввод системы	2 500,00
Итого	50 506,00

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

Таблица 5.2 - Структура капитальных затрат

Наименование	Сумма, руб.
Приобретение ПО Windows Server 2003 SE	14 797,00
Приобретение ПО Microsoft SQL Server 2005	20 350,00
Приобретение ПО AllFusion ERwin Data Modeler v7.2	120 741,00
Итого	155 888,00

Рассчитаем единовременные затраты на создание системы по формуле (5.2):

206394 (руб.)

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

5.2.2 Расчет текущих затрат на функционирование системы

Расчет годовых текущих затрат в АС предполагает определение текущих затрат посредством расчета основных составляющих:

, (5.4)

где - годовые текущие затраты на эксплуатацию комплекса технических средств (КТС), руб;

- годовые затраты на зарплату специалистов в условиях функционирования АС, руб/год.

Затраты определяются по формуле:

, (5.5)

где - годовые затраты на эксплуатацию КТС, руб./год.

- годовые затраты на поддержание системы КТС, руб./год.

- годовые затраты на содержание производственных помещений, руб./год.

- годовая зарплата работников группы эксплуатации комплекса средств автоматизации (КСА) с начислениями, руб./год.

Годовые текущие затраты на эксплуатацию КТС , включающих сервер приложений, сервер баз данных, рассчитываются по формуле (5.5):

(руб.)

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

(руб.).

Рассчитаем годовые текущие затраты системы по формуле (5.4):

(руб).

Таким образом, годовые текущие затраты на функционирование подсистемы документооборота составляют 1 932 005 рублей. Следующими будут расчеты показателей эффективности системы.

5.2.3 Расчет показателей экономической эффективности системы

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

, (5.6)

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

, (5.7)

, (5.8)

где и - соответственно результаты и затраты в t-м году, руб.;

и - соответственно начальный и конечные годы расчетного периода, руб.;

- коэффициент приведения затрат и результатов к расчетному году:

, (5.9)

где - норматив приведения разновременных затрат и результатов ();

- расчетный период;

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

Отсюда по формуле (5.9), в течение расчетного периода - три года, будет иметь значение:

.

Затраты на создание и функционирование АС в течении расчетного периода (три года) определяются по формуле:

, (5.10)

где - единовременные затраты на создание АС в t-м году, руб./год;

- годовые текущие затраты на функционирование АС в t-м году, руб./год.

Подставляя в формулу (5.10) значения, полученные ранее по формулам (5.2), (5.4) и (5.9) получим следующий результат:

(руб.)

Экономия, получаемая в t-м году, рассчитывается следующим образом:

, (5.11)

где - экономия, получаемая в t-м году в результате сокращения затрат трудовых и материальных ресурсов в АС, руб./год.

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

- дополнительная прибыль в t-м году от приоритетной новизны решения, полученного в АС в кратчайшие сроки, руб./год.

- норматив эффективности капитальных вложений, .

- сокращение длительности автоматизируемого процесса, лет.

Таким образом по формуле (5.11) получим экономию, за счет сокращения трудовых и стоимостных затрат на зарплату сотрудникам в условиях функционирования подсистемы документооборота, а также за счет другой экономии:

(руб.).

По формуле (5.7), подставляя результаты полученные раннее (5.9) и (5.11), общий экономический результат в течение расчетного периода трех лет будет:

Рассчитаем экономический эффект функционирования подсистемы документооборота исходя из полученных ранее результатов по формуле (5.6):

2100387 (руб.).

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

5.3 Выводы

В пятом разделе проведен анализ экономической эффективности и технико-экономических показателей проекта.

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

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