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

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

Рисунок 2.1 - Концептуальная модель бюджетной классификации доходов

В таблице 4 представлено описание классов и их атрибутов концептуальной модели бюджетной классификации доходов.

Таблица 4 - Описание классов концептуальной модели бюджетной классификации доходов

Класс	Атрибут	Описание
1	2	3
Бюджетная Классификация		Бюджетная классификация РФ
	Год	Год для которого действительна бюджетная классификация
Группа Доходов		Группа доходов
	Код	Код группы доходов
	Наименование	Наименование группы доходов
Подгруппа Доходов		Подгруппа доходов
	Код	Код подгруппы доходов
	Наименование	Наименование подгруппы доходов
Статья Доходов		Статья бюджетной классификации доходов
	Код	Код статьи доходов
	Наименование	Наименование статьи доходов
Прог Доход		Программа бюджетной классификации доходов
	Код	Код программы доходов
	Наименование	Наименование программы доходов

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

Рисунок 2.2 - Концептуальная модель бюджетной классификации расходов

В таблице 5 представлено описание классов и их атрибутов концептуальной модели бюджетной классификации расходов.

Таблица 5 - Описание классов концептуальной модели бюджетной классификации расходов

Класс	Атрибут	Описание
1	2	3
Раздел Расходов		Раздел бюджетной классификации расходов
	Код	Код раздела расходов
	Наименование	Наименование раздела расходов
Подразд Расходов		Подраздел бюджетной классификации расходов
	Код	Код подраздела расходов
	Наименование	Наименование подраздела расходов
ЦСР		Целевая статья расходов
	Код	Код целевой статьи расходов включающий программный срез
	Наименование	Наименование целевой статьи расходов
Вид Расходов		Вид расходов
	Код	Код вида расходов
	Наименование	Наименование вида расходов
Эконом Класс Расходов		Экономический класс расходов
	Код	Код экономического класса расходов
	Наименование	Наименование экономического класса расходов
Расход		Расход
	Код	Код расхода

На рисунке 2.3 представлена часть концептуальной модели, которая отображает бюджетную классификацию источников финансирования дефицита бюджета.

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

Рисунок 2.3 - Концептуальная модель бюджетной классификации источников финансирования дефицита

Таблица 6 - Описание классов концептуальной модели бюджетной классификации источников финансирования дефицита

Класс	Атрибут	Описание
1	2	3
ГруппаИФД		Группа источников финансирования дефицита
	Код	Код группы источников финансирования дефицита
	Наименование	Наименование группы источников финансирования дефицита
ПодгрИстФинДеф		Подгруппа источников финансирования дефицита
	Код	Код подгруппы источников финансирования дефицита
	Наименование	Наименование подгруппы источников финансирования дефицита
СтатьяИФД		Статья источников финансирования дефицита
	Код	Код статьи источников финансирования дефицита
	Наименование	Наименование статьи источников финансирования дефицита
ПодстатьяИФД		Подстатья источников финансирования дефицита
	Код	Код подстатьи источников финансирования дефицита
	Наименование	Наименование подстатьи источников финансирования дефицита
ПрогИФД		Программа источников финансирования дефицита
	Код	Код программы источников финансирования дефицита
	Наименование	Наименование программы источников финансирования дефицита
ЭкономКлассИФД		Экономических класс источников финансирования дефицита
	Код	Код экономического класса источников финансирования дефицита
	Наименование	Наименование экономического класса источников финансирования дефицита
ИФД		Источник финансирования дефицита
	Код	Код источника финансирования дефицита

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



Рисунок 2.4 - Объекты, участвующие в процессах составления смет доходов администраторов бюджетных средств и доходной части проекта бюджета

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

Таблица 7 - Описание классов объектов, участвующих в процессах составления смет доходов администраторов бюджетных средств и доходной части проекта бюджета

Класс	Атрибут	Описание
1	2	3
Проект Бюджета		Проект бюджета
	Год	Год на который составляется проект бюджета
	Статус	Текущее состояние проекта бюджета
	Наименование	Название проекта бюджета
Юр Лицо		Юридическое лицо
	ИНН	Индивидуальный номер налогоплательщика
	Наименование	Название организации
	Адрес	Адрес организации
Администратор		Администратор бюджетных средств
	Код	Код администратора бюджетных средств
Смета Доходов		Смета доходов администратора бюджетных средств
	Номер	Номер документа
	Статус	Текущее состояние сметы доходов
Строка Смет Доход		Строка табличной части сметы доходов
	Сумма	Предполагаемых объем доходов
	Примечание	Примечание служит для любых пояснений

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

Рисунок 2.5 - Объекты, участвующие в процессах составления смет расходов распорядителей бюджетных средств и расходной части проекта бюджета

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

Таблица 8 - Описание классов объектов, участвующих в процессах составления смет расходов распорядителей бюджетных средств и расходной части проекта бюджета

Класс	Атрибут	Описание
1	2	3
Распорядитель		Распорядитель бюджетных средств
	Код	Код распорядителя бюджетных средств
Смета Расходов		Смета расходов распорядителя бюджетных средств
	Номер	Номер документа
	Статус	Текущее состояние сметы расходов
Строка Смет Расх		Строка табличной части сметы расходов
	Сумма	Предполагаемый объем расходов
	Примечание	Комментарии
Справ Уведомление Расходы		Справка-уведомление по расходам
	Номер	Номер документа
	Дата	Дата внесения
	Примечание	Комментарии к справке-уведомлению
	Статус	Текущее состояние справки-уведомления
Строка Спр Увед Расх		Строка табличной части справки-уведомления по расходам
	Сумма	Объем средств, на который увеличиваются или уменьшаются расходы
	Примечание	Комментарии
Поселение		Городское или сельское поселение
	Код	Код поселения
	Наименование	Название поселения
Тип Документа		Тип документа основания для справок-уведомлений
	Код	Код типа документа
	Наименование	Название типа документа

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



Рисунок 2.6 - Объекты, участвующие в процессе составления смет источников финансирования дефицита бюджета

В таблице 9 представлено описание классов объектов, участвующих в процессе составления смет источников финансирования дефицита бюджета.

Таблица 9 - Описание классов объектов, участвующих в процессе составления смет источников финансирования дефицита бюджета

Класс	Атрибут	Описание
1	2	3
Администратор ИФД		Администратор источников финансирования дефицита
	Код	Код администратора источников финансирования дефицита
Смета ИФД		Смета источников финансирования дефицита
	Номер	Номер документа
	Статус	Текущее состояние сметы источников финансирования дефицита
Строка Сметы ИФД		Строка табличной части сметы источников финансирования дефицита
	Сумма	Предполагаемый объем средств направляемых на покрытие дефицита
	Примечание	Комментарии
Справка Уведомление ИФД		Справка-уведомление по источникам финансирования дефицита
	Номер	Номер документа
	Дата	Дата внесения
	Примечание	Комментарии
	Статус	Текущее состояние справки-уведомления

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

Рисунок 2.7 - Объекты, участвующие в процессе составления консолидированного проекта бюджета территории

В таблице 10 представлено описание классов объектов, участвующих в процессе составления консолидированного проекта бюджета территории.

Таблица 10 - Описание классов объектов, участвующих в процессе составления консолидированного проекта бюджета территории

Класс	Атрибут	Описание
1	2	3
Территория		Территория для которого составляется проект бюджета
	Код	Код территории
	Наименование	Название территории
Проект Консолид Бюджета		Проект консолидированного бюджета территории
	Год	Год на который составляется проект бюджета
	Наименование	Название консолидированного проекта бюджета территории

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



Рисунок 2.8 - Объекты, участвующие в процессе управления пользователями системы и их правами доступа

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

Таблица 11 - Описание классов объектов, участвующих в процессе управления пользователями системы и их правами доступа

Класс	Атрибут	Описание
1	2	3
Пользователь		Пользователь системы
	Логин	Имя учетной записи пользователя
	Пароль	Хэш пароля учетной записи пользователя
	Ф.И.О.	Имя пользователя
Пользовательская Группа		Группа пользователей
	Код	Код пользовательской группы
	Наименование	Название пользовательской группы
Право Доступа		Право доступа к функциональности системы
	Наименование	Название права доступа
Группа Прав Доступа		Группа объединяющая несколько прав доступа
	Код	Код группы прав доступа
	Наименование	Название группы прав доступа

2.2 Обоснование выбора СУБД

Одним из требований заказчика является реализация информационного обеспечения на основе Microsoft SQL Server 2000 Enterprise Edition /24/, в связи с тем, что у них уже имеется лицензионная копия данного продукта. Это позволит в некоторой степени сократить первоначальные затраты на разработку и внедрение системы.

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

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

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

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

SQL Server 2000 состоит из ряда компонентов, таких, как механизм реляционных баз данных, Analysis Services и English Query. Все эти компоненты, каждый из которых играет определенную роль, работая совместно, формируют полнофункциональную реляционную СУБД.

Механизм реляционных баз данных SQL Server 2000 - это современное ядро с высокой степенью масштабируемости, предназначенное для хранения данных. Механизм баз данных сохраняет данные в таблицах. Каждая таблица представляет определенный класс объектов, в зависимости от интересов конкретной организации. Таблица состоит из столбцов, каждый из которых представляет атрибут объекта, который она моделирует, и строк. Каждая строка представляет один экземпляр объекта, моделируемого таблицей. Приложение передает механизму баз данных оператор SQL, механизм возвращает результат в виде набора данных в табличной форме. Интернет-приложение передает механизму баз данных оператор SQL или запрос XPath, а тот возвращает результат в виде документа XML. Механизм реляционных баз данных обеспечивает поддержку стандартных интерфейсов доступа к данным, таких, как ADO, OLE DB и ODBC.

Механизм реляционных баз данных обладает высокой масштабируемостью. SQL Server 2000 Enterprise Edition поддерживает группы серверов баз данных, формирующих базы данных терабайтного объема, к которым могут обращаться тысячи пользователей одновременно. Механизм баз данных также способен динамически настраиваться путем выделения дополнительных ресурсов по мере роста числа пользователей, подключенных к базе данных, и освобождения ресурсов после отключения пользователей. Другими словами, отдельные пользователи или небольшие рабочие группы, у которых нет администраторов баз данных, могут использовать более простые редакции SQL Server. С помощью административных утилит с графическим интерфейсом из комплекта поставки продукта легко администрировать даже крупные серверы баз данных под управлением Enterprise Edition, работающие в эксплуатационном режиме.

Механизм реляционных баз данных также обладает высокой степенью зашиты. Аутентификацию при регистрации допустимо интегрировать с проверкой подлинности Windows, поэтому SQL Server не хранит никаких паролей и не пересылает их по сети. На узлах разрешается задавать аудит всех пользователей, обращающихся к базе данных, соответствующий требованиям безопасности уровня С2, и применять протокол SSL для шифрования всех данных, передаваемых между приложением и базой данных.

Репликация SQL Server 2000 позволяет поддерживать несколько копий данных на различных компьютерах с целью повышения общей производительности системы, а также обеспечивает поддержку синхронизации всех копий. Репликация - важная и мощная технология распределения данных и некоторых типов объектов баз данных по всему предприятию. В репликации SQL Server используется принцип «публикации и подписки». Издатель данных, подлежащих репликации, определяет статьи, которые надо сделать доступными для подписчиков.

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

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

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

Analysis Services предоставляет инструменты для анализа данных, которые находятся в хранилищах и киосках данных, где итоговая информация содержится в таблицах фактов. Таблица фактов - центральная таблица в схеме хранилища данных, в ней хранятся численные меры и ключи, связывающие факты с таблицами измерений. Как правило, базовая таблица фактов содержит сведения, описывающие некоторые события в бизнесе, например банковские транзакции или факты продажи продукции. Приложения работают с данными Analysis Services с помощью многомерных расширений ADO и OLE DB. Обработка запросов OLAP посредством многомерных кубов Analysis Services выполняется существенно быстрее, чем с использованием подробной информации из баз данных OLTP.

В систему Analysis Services входит сервер, управляющий многомерными кубами, предназначенными для анализа. Он обеспечивает клиенту быстрый доступ к данным куба. Чтобы быстро выдавать ответы на сложные аналитические запросы. Analysis Services организует данные из хранилища в кубические массивы с помощью предварительно вычисленных агрегированных данных. Analysis Services также облегчает создание моделей извлечения информации для данных как из многомерных, так и из реляционных источников. Можно применять модели извлечения информации к обоим типам данных. Посредством службы PivotTable - компонента доступа, совместимого с OLE DB, Microsoft Excel и приложения других производителей могут получать данные с сервера и представлять их пользователю или создавать локальные кубические массивы для автономного анализа.

2.3 Разработка физической модели данных

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

На рисунке 2.9 представлены таблицы, относящиеся к бюджетной классификации доходов. В таблице 12 представлено описание таблиц, относящихся к бюджетной классификации доходов. Во всех таблицах поле ts с типом данных timestamp используются для оптимистического управления блокировками при многопользовательской работе с проектируемой системой. Это поле в описания таблиц, в связи с ограничением на объем дипломного проекта, не приводится.



Рисунок 2.9 - Бюджетная классификация доходов

Таблица 12 - Описание физической модели бюджетной классификации доходов

Таблица	Атрибут	Описание
1	2	3
BudgetClassifications		Бюджетные классификации за разные годы
	id	Уникальный идентификатор
	year	Год в течении которого действует бюджетная классификация
RevenueGroups		Группы доходов
	id	Уникальный идентификатор
	budgetClassificationId	Код бюджетной классификации. Внешний ключ.
	sid	Код группы доходов в соответствии с бюджетной классификацией
	name	Наименование группы доходов
RevenueSubgroups		Подгруппы доходов
	id	Уникальный идентификатор
	groupId	Код группы доходов. Внешний ключ.
	sid	Код подгруппы доходов в соответствии с бюджетной классификацией
	name	Наименование подгруппы доходов
RevenueClauses		Статья доходов
	id	Уникальный идентификатор
	subgroupId	Код подгруппы доходов. Внешний ключ
	sid	Код статьи доходов в соответствии с бюджетной классификацией
	name	Наименование статьи доходов
RevenueSubclauses		Подстатьи доходов
	id	Уникальный идентификатор
	clauseId	Код статьи доходов. Внешний ключ
	sid	Код подстатьи доходов в соответствии с бюджетной классификацией
	name	Наименование подстатьи доходов
Elements		Элементы бюджетной классификации
	id	Уникальный идентификатор
	budgetClassificationId	Код бюджетной классификации. Внешний ключ
	sid	Код элемента в соответствии с бюджетной классификацией
	name	Наименование элемента
RevenuePrograms		Программы доходов
	id	Уникальный идентификатор
	budgetClassificationId	Код бюджетной классификации. Внешний ключ
	sid	Код программы в соответствии с бюджетной классификацией доходов
	name	Наименование программы доходов

На рисунке 2.10 представлены таблицы, относящиеся к бюджетной классификации расходов.

В таблице 13 представлено описание таблиц, относящихся к бюджетной классификации расходов.

На рисунке 2.11 представлены таблицы, относящиеся к бюджетной классификации источников финансирования дефицита.

В таблице 14 представлено описание таблиц, относящихся к бюджетной классификации источников финансирования дефицита.

На рисунке 2.12 представлены таблицы, относящие к процессу формированию доходной части проекта бюджета.

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

Рисунок 2.10 - Бюджетная классификация расходов

Таблица 13 - Описание физической модели бюджетной классификации расходов

Таблица	Атрибут	Описание
1	2	3
OutlaySections		Разделы бюджетной классификации расходов
	id	Уникальный идентификатор
	budgetClassificId	Код бюджетной классификации. Внешний ключ
	sid	Код раздела бюджетной классификации расходов
	name	Наименование раздела бюджетной классификации расходов

Рисунок 2.11 - Бюджетная классификация источников финансирования дефицита

Таблица 14 - Описание физической модели бюджетной классификации источников финансирования дефицита

Таблица	Атрибут	Описание
1	2	3
SFDGroups		Группы бюджетной классификации источников финансирования дефицита
	id	Уникальный идентификатор
	budgClassifId	Код бюджетной классификации. Внешний ключ
	sid	Код группы источников финансирования дефицита в соответствии с бюджетной классификацией
	name	Наименование группы источников финансирования дефицита

Рисунок 2.12 - Формирование доходной части проекта бюджета

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

Таблица	Атрибут	Описание
1	2	3
Locations		Поселения, для которых формируются проекты бюджета
	id	Код поселения
	domains	Код территории к которой относится поселение
	name	Название поселения
BudgetProjects		Проекты бюджетов
	id	Уникальный идентификатор
	locationId	Код поселения, которому принадлежит проект бюджета
	year	Год, на который составляется проект бюджета
	name	Название проекта бюджета
	status	Состояние проекта бюджета

На рисунке 2.13 представлены таблицы, относящие к процессу формированию расходной части проекта бюджета.

Рисунок 2.13 - Формирование расходной части проекта бюджета

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

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

Таблица	Атрибут	Описание
1	2	3
BCSteward		Распорядители бюджетных средств
	id	Уникальный идентификатор
	budgProjId	Код проекта бюджета. Внешний ключ
	legalId	Код юридического лица. Внешний ключ
	sid	Код распорядителя в соответствии с бюджетной классификацией
OutlayEstimates		Сметы расходов распорядителей бюджетных средств
	bcStewardId	Код распорядителя бюджетных средств
	id	Номер документа
	status	Состояние сметы расходов
OutlayEstimateRows		Строки табличной части сметы расходов распорядителя бюджетных средств
	id	Уникальный идентификатор
	estimateId	Код сметы расходов. Внешний ключ
	outlayId	Код расхода. Внешний ключ
	sum	Объем денежных средств
	description	Примечание
OutlayEnquirys		Справки-уведомления по расходам
	id	Номер документа
	bcStewardId	Код распорядителя бюджетных средств. Внешний ключ
	docId	Код документа основания. Внешний ключ
	date	Дата
	description	Примечание
	status	Состояние справки-уведомления
OutlayEnquiryRows		Строки табличной части справок-уведомлений по расходам
	id	Уникальный идентификатор
	enquiryId	Код справки-уведомления. Внешний ключ
	outlayId	Код расхода. Внешний ключ
	summ	Объем денежных средств
	description	Примечание

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

В таблице 17 представлено описание таблиц, относящихся к процессу формирования источников финансирования дефицита бюджета.



Рисунок 2.14 - Формирование источников финансирования дефицита бюджета

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

Таблица	Атрибут	Описание
1	2	3
SFDAdministrators		Администраторы источников финансирования дефицита бюджета
	id	Уникальный идентификатор
	legalId	Код юридического лица. Внешний ключ
	budgProjId	Код проекта бюджета. Внешний ключ
	sid	Код администратора источников финансирования дефицита в соответствии с бюджетной классификацией
SFDEstimates		Сметы источников финансирования дефицита бюджета
	sfdSdminId	Код администратора источников финансирования дефицита бюджета
	id	Номер документа
	status	Состояние сметы

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



Рисунок 2.15 - Формирования консолидированного проекта бюджета территории

В таблице 18 представлено описание таблиц, относящихся к процессу формирования консолидированного проекта бюджета территории.

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

Таблица	Атрибут	Описание
1	2	3
Domains		Территории
	id	Код территории
	name	Название территории
ConsBudgetProjects		Консолидированные проекты бюджетов территории
	id	Уникальный идентификатор
	year	Год, на который составляется консолидированный проект бюджета территории
	domainId	Код территории. Внешний ключ
	name	Название проекта бюджета

В процессе физического проектирования базы данных в среде MS SQL Server 2000 была создана база данных fin_budget, состоящая из файлов данных fin_budget.mdf и файлов журналов транзакций fin_budget_log.ldf. Принцип отдельного хранения данных и журналов транзакций, а также разбиение этих двух групп информации на различные файлы в SQL Server 2000 необходим для повышения надежности системы.

При создании физической модели сервера баз данных, посредством SQL Server Enterprise Manager, для всех суррогатных ключей было установлено свойство Identy, необходимое для вызова хранимой процедуры аутоинкремента. Для увеличения реактивности системы, индексам, закрепленными за суррогатными ключами присвоено значение Clustered.

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

В качестве СУБД обосновано применение Microsoft SQL Server 2000 Enterprise Edition.

На основании концептуальной модели данных для Microsoft SQL Server 2000 разработана физическая модель данных.

3. Проектирование программного комплекса

3.1 Разработка архитектуры программного комплекса

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

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

Расчленение системы на слои предоставляет целый ряд преимуществ:

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

- можно выбирать альтернативную реализацию базовых слоев;

- зависимость между слоями можно свести к минимуму;

- созданный слой может служить основой для несколько слоев более высокого уровня.

Архитектура проектируемого приложения основывается на трех основных слоях:

- слой представления

- слой домена

- слой источника данных

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

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

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

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

В качестве базовой платформы для разработки приложения планируется использовать. Net Framework 2.0.

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

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

Библиотека классов .NET Framework содержит набор полезных типов, разработанных специально для СLR и доступных для многократного использования. Типы, поддерживаемые.NET Framework, являются объектно-ориентированными, полностью расширяемыми и обеспечивают бесшовную интеграцию приложений с .NET Framework.

Конструкция.NET Framework обеспечивает межъязыковую совместимость. Проще говоря, компоненты, реализованные с применением .NET Framework, способны взаимодействовать друг с другом независимо от языка, на котором они написаны. Так, приложение на Visual Basic.NET может обращаться к DLL, написанной на С#, а та, в свою очередь, способна вызвать ресурсы, созданные на управляемом C++ или любом другом NET-совместимом языке. Межъязыковая совместимость поддерживается и для наследования в ООП, например, на основе С#-класса можно объявлять классы в программах на Visual Basic.NET и наоборот.

В качестве языка программирования, при помощи которого, будет реализовываться проектируемая система, выбран язык C#. Этот выбор обусловлен, прежде всего, тем, что данный язык разрабатывался специально для платформы. Net Framework. Он сочетает в себе мощь C++ и простоту Visual Basic.

Для доступа к данным используется набор библиотек ADO. Net.

ADO. Net - это набор библиотек, поставляемых с Microsoft. Net Framework и предназначенный для взаимодействия с различными хранилищами данных из. Net-приложений. Библиотека ADO. Net включают классы для подсоединения к источнику данных, выполнения запросов и обработки их результатов. Кроме того, ADO. Net можно использовать в качестве надежного, иерархически организованного, отсоединенного кэша данных для автономной работы с данными. Главный отсоединенный объект, DataSet, позволяет сортировать, осуществлять поиск, фильтровать, сохранять отложенные изменения и перемещаться по иерархическим данным. Кроме того, объект DataSet включает ряд функций, сокращающих разрыв между традиционным доступом к данным и программированием с использованием XML.

Для взаимодействия между удаленными узлами, на которых расположены компоненты проектируемого приложения, используется технология. Net Remoting /17, 22/.

NET Remoting - это объектно-ориентированная архитектура для поддержки распределенных приложений в Microsoft .NET. Подобно тому как .NET Framework заменяет СОМ в качестве средства разработки компонентов .NET Remoting заменяет DCOM в качестве средства создания распределенных приложений на основе.NET Framework. Более того .NET Remoting является основой для .NET Web-сервисов. Таким образом, понимание основ .NET Remoting совершенно необходимо для разработки на основе .NЕТ Framework распределенных приложений, в том числе для Интернета.

NET Remoting позволяет объектам, исполняющимся внутри разных доменов приложений и контекстов, взаимодействовать друг с другом через границы .NET Remoting. Граница .NET Remoting ведет себя, как полупроницаемая мембрана: в некоторых случаях она позволяет экземпляру пройти сквозь нее без изменений; в других - заставляет экземпляр объекта за пределами домена или контекста взаимодействовать с внутренними объектами по строго определенному протоколу.

3.2 Разработка прототипов пользовательского интерфейса

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

На рисунке 3.1 представлена среда автоматизированной системы бюджетного процесса.

Рисунок 3.1 - Среда автоматизированной системы бюджетного процесса

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

- главное меню приложения;

- строка навигации по доступным проектам бюджета;

- панель навигации;

- основная часть.

Главное меню приложения служит для доступа ко всем функциям системы.

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

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

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

Структура главного меню приложения представлена в таблице 19.

Таблица 19 - Структура главного меню

№ п/п	Название	Описание
1	2	3
1	Файл
1.1	Войти в системы	Позволяет пользователю подключится к системе
1.2	Выйти из системы	Позволяет пользователю отключится от системы
1.3	Выход	Завершает работу приложения
2	Правка
2.1	Отменить	Позволяет отменить последнее произведенной пользователем действие
2.2	Повторить	Позволяет повторить отмененное ранее действие
2.3	Скопировать	Позволяет скопировать данные в буфер обмена
2.4	Вырезать	Позволяет вырезать данные в буфер обмена
2.5	Вставить	Позволяет вставить данные из буфера обмена
3	Проект бюджета
3.1	Доходы
3.1.1	Сметы доходов	Администраторам бюджетных средств позволяет вводить и передавать в Финансовое управление сметы доходов, а работникам Финансового управления проверять и утверждать сметы
3.1.2	Справки-уведомления	Администраторам бюджетных средств позволяет вводить справки-уведомления по доходам, а работникам Финансового управления проверять и утверждать их
3.2	Расходы
3.2.1	Сметы расходов	Распорядителям бюджетных средств позволяет вводить и передавать в Финансовое управление сметы расходов, а работникам Финансового управления проверять и утверждать сметы
3.2.2	Справки-уведомления	Распорядителям бюджетных средств позволяет вводить и передавать в Финансовое управление справки-уведомления по расходам, а работникам Финансового управления проверять и утверждать их

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

3.3 Проектирование структуры программного

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

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

Пользователь вводит логин и пароль своей учетной записи и нажимает на кнопку «Войти» формы AuthForm. Эта форма в свою очередь отправляет сообщение Connect управляющему объекту ClientImpl, который представляет собой клиентское приложение. Объект ClientImpl вызывает метод Connect объекта-сервера ServerImpl и передает себя в качестве параметра этого сообщения. ServerImpl проверяет наличие в системе зарегистрированной учетной записи, с введенными пользователем логином и паролем, при помощи управляющего объекта SecurityManager. Если учетная запись с введенными пользователем данными зарегистрирована в системе, то сервер регистрирует сессию для клиентского приложения и возвращает управление клиентскому приложению.

Рисунок 3.2 - Аутентификация пользователя в системе

На рисунке 3.3 представлена диаграмма, показывающая объекты и сообщения, передаваемые между ними в процессе регистрации нового пользователя в системе.

Администратор вводит на форме RegisterUserForm необходимые для регистрации нового пользователя данные, а затем запускает процедуру регистрации нового пользователя в системе. Форма RegisterUserForm передает сообщение Register управляющему объекту UserManager вместе с введенными администратором данными.

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



Рисунок 3.3 - Регистрация нового пользователя в системе

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

Пользователь вводит свой старый пароль и новый, и запускает процедуру смены пароля. Форма ChangePasswordForm передает сообщение ChangePass управляющему объекту UserManager, который в свою очередь при помощи SecureManager проверяет наличие у пользователя права на смену пароля на текущей учетной записи. Если у пользователя это право имеется, то SecureManager посылает сообщений объекту Users, который меняет пароль на учетной записи.

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



Рисунок 3.4 - Смена пароля на учетной записи пользователя

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

Дадим некоторые пояснения по структуре приложения.

Центральными классами являются ServerImpl и ClientImpl, которые соответственно представляют серверную и клиентскую часть приложения. Первый объект реализует интерфейс IServer, а второй IClient. Клиентская часть приложения имеет доступ к серверу только через интерфейс IServer. Такая реализация продиктована требованиями безопасности.

При проектировании класса ServerImpl использовался паттерн Singleton, что гарантирует существование единственного экземпляра этого класса в течение всего времени работы программы.

Класс ServerImpl управляет загрузкой подключаемых модулей и предоставляет доступ клиентскому коду к управляющим объектам.

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

Все управляющие объекты реализуют интерфейс IManager и доступ к ним осуществляется по названию менеджера через класс ServerImpl.

Рассмотрим назначение основных менеджеров.

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

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

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

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

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

DALManager управляет компонентами доступа к данным. При помощи этого менеджера в системе регистрируются DAL_компоненты, которые осуществляют сохранение объектов в базе данных, их модификацию и удаление, а также построение объектов из данных сохраненных в базе.

BudgetManager управляет проектами бюджета. Позволяет создавать, модифицировать и утверждать проекты бюджета.

BCAdminManager управляет администраторами бюджетных средств. Позволяет назначать и удалять администраторов бюджетных средств.

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

SFDAdminManager управляет администраторами источников финансирования дефицита. Позволяет назначать и удалять администраторов источников финансирования дефицита.

RevenueEstimateManager управляет сметами доходов администраторов бюджетных средств.

OutlayEstimateManager управляет сметами расходов распорядителей бюджетных средств.

SFDEstimateManager управляет сметами источников финансирования дефицита бюджета.

RevenueEnquiryManager управляет справками-уведомлениями по доходам.

OutlayEnquiryManger управляет справками-уведомлениями по расходам.

SFDEnquiryManager управляет справками-уведомлениями по источникам финансирования дефицита бюджета.

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

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

Разработанные классы объединены в компоненты, представленные в таблице 20.

Таблица 20 - Компоненты автоматизированной системы бюджетного процесса

Название компонента	Описание
1	2
ASBPServer.exe	Серверная часть приложения, выполненная в виде Windows_процесса
ASBPClient.exe	Клиентская часть приложения
ASBP. Common.dll	Динамическая библиотека, объединяющая базовые классы, используемые большинством компонентов автоматизированной системы бюджетного процесса
ASBP. BudgetProj. Server.dll	Динамическая библиотека, объединяющая классы серверной части приложения, которые используются при формировании проекта бюджета
ASBP. BudgetProj. Client.dll	Динамическая библиотека, объединяющая классы клиентской части приложения, которые используются при формировании проекта бюджета
ASBP. Exchange. Server.dll	Динамическая библиотека, объединяющая классы серверной части приложения, которые используются при обмене данными между Финансовым управлением, администраторами и распорядителями бюджетных средств, а также администраторами источников финансирования дефицита бюджета
ASBP. Exchange. Client.dll	Динамическая библиотека, объединяющая классы клиентской части приложения, которые используются при обмене данными между Финансовым управлением, администраторами и распорядителями бюджетных средств, а также администраторами источников финансирования дефицита бюджета
ASBP. ConsBudgProj. Server.dll	Динамическая библиотека, объединяющая классы серверной части приложения, которые участвуют в процессах составления консолидированного проекта бюджета территории
ASBP. ConsBudgProj. Client.dll	Динамическая библиотека, объединяющая классы клиентской части приложения, которые участвуют в процессах составления консолидированного проекта бюджета территории
ASBP. Revenue. Server.dll	Динамическая библиотека, объединяющая классы серверной части приложения, которые используются при формировании смет доходов администраторов бюджетных средств и справок-уведомлений по доходам
ASBP. Revenue. Client.dll	Динамическая библиотека, объединяющая классы клиентской части приложения, которые используются при формировании смет доходов администраторов бюджетных средств и справок-уведомлений по доходам
ASBP. Outlay. Server.dll	Динамическая библиотека, объединяющая классы серверной части приложения, которые используются при формировании смет расходов распорядителей бюджетных средств и справок-уведомлений по расходам
ASBP. Outlay. Client.dll	Динамическая библиотека, объединяющая классы клиентской части приложения, которые используются при формировании смет расходов распорядителей бюджетных средств и справок уведомлений по расходам
ASBP.SFD. Server.dll	Динамическая библиотека, объединяющая классы серверной части приложения, которые используются при формировании смет источников финансирования дефицита бюджета и справок-уведомлений по источникам финансирования дефицита бюджета
ASBP.SFD. Client.dll	Динамическая библиотека, объединяющая классы клиентской части приложения, которые используются при формировании смет источников финансирования дефицита бюджета и справок-уведомлений по источникам финансирования дефицита бюджета

3.4 Тестирование программной системы

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

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

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

Первое испытание направлено на тестировании работы автоматизированной системы бюджетного процесса по сохранению вводимых данных при вводе справок-уведомлений по доходам.

Рисунок 5.1 - Состояние таблицы RevenueEnquirys до внесения справки в систему

Рисунок 5.2 - Состояние таблицы RevenueEnquiryRows до внесения справки в систему

На рисунках 5.3 и 5.4 представлено состояние этих же таблиц после внесения справки-уведомления.

Рисунок 5.3 - Состояние таблицы RevenueEnquirys после внесения справки в систему

Рисунок 5.4 - Состояние таблицы RevenueEnquiryRows после внесения справки в систему

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

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

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

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