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

Введение

 

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

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

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

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

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

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

 

 

1.   Разработка требований к программному обеспечению

 

1.1      Анализ предметной области

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

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

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

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

-          Бюджетный кодекс Российской Федерации и федеральные законны о федеральном бюджете на соответствующий год принятые в соответствии с ним;

-          законы субъектов Российской Федерации о бюджетах субъектов Российской Федерации на соответствующий год;

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

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

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

-          единство бюджетной системы Российской Федерации;

-          разграничение доходов и расходов между уровнями бюджетной системы Российской Федерации;

-          самостоятельность бюджетов;

-          равенство бюджетных прав субъектов Российской Федерации и муниципальных образований;

-          полнота отражения доходов и расходов бюджетов;

-          сбалансированность бюджета;

-          эффективность и экономичность использования бюджетных средств;

-          гласность;

-          достоверность бюджета;

-          адресность и целевой характер бюджетных средств.

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

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

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

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

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

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

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

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

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

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

-          формирование и утверждение проекта бюджета;

-          формирование и утверждение бюджетной росписи;

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

-          финансирование расходов подведомственных распорядителей и получателей бюджетных средств;

-          контроль над поступлением доходов на счета бюджета;

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

-          формирование и предоставление отчетных данных в вышестоящие контролирующие органы.

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

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

При описание системы активно используется Unified Modeling Language 2.0, который позволяет в наглядной графической форме отобразить все аспекты проектируемой системы и CASE‑средство Enterprise Architect фирмы Sparx Systems.

1.2      Анализ существующих решений по автоматизации предметной области

Среди существующих программных решений по автоматизации деятельности администраций следует отметить автоматизированную информационную систему АС «Бюджет» НПО «Криста», которая предназначена для комплексной автоматизации деятельности финансовых органов субъектов РФ и муниципальных образований на всех этапах исполнения бюджета. Данная ИС позволяет организовать исполнение бюджета в соответствии с действующим бюджетным законодательством, обеспечивает создание системы управленческого бюджетного учета и отчетности финансового органа, поддерживает различные варианты кассового обслуживания исполнения бюджета в органах Федерального казначейства. Информационная система АС «Бюджет» обеспечивает выполнение следующих функций:

-          автоматический бюджетный контроль;

-          множественное визирование документов с применением ЭЦП;

-          многобюджетный режим работы;

-          расширенный аудит действий пользователей;

-          сбора информации;

-          учет государственных контрактов и договоров;

-          учет бюджетных обязательств;

-          электронный обмен с банком);

-          сканер двухмерного штрих-кода платежных поручений.

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

Функция множественного визирования документов с применением ЭЦП позволяет внедрить во внутренний документооборот средства ЭЦП и шифрования.

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

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

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

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

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

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

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

Комплексная система АЦК-Финансы, разработанная компанией «Бюджетные Финансовые Технологии» предназначена для обеспечения автоматизации всего процесса исполнения бюджета и управления бюджетным процессом /6/.

АЦК-Финансы обеспечивает комплексную оптимизацию и автоматизацию всех участков и всех участников бюджетного процесса, в том числе автоматизацию всех структурных подразделений внутри финансового органа, подчиненных территориальных подразделений ФО, распорядителей и получателей бюджетных средств. Кроме того, система АЦК-Финансы решает задачи связи ФО с МНС и УФК, а при необходимости и с обслуживающим банком или РКЦ.

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

-          бухгалтерия ФО;

-          бюджетный и отраслевые отделы ФО;

-          отдел ценных бумаг и неденежных форм расчетов ФО;

-          отдел доходов ФО;

-          казначейский отдел ФО;

-          отдел управления и обслуживания государственного долга ФО;

-          отдел учета бюджетных обязательств ФО;

-          отдел автоматизации систем финансовых расчетов ФО;

-          РБС;

-          ПБС и прочие.

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

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

Система АЦК-Финансы, являясь комплексным решением автоматизации ФО, помимо осуществления казначейского расхода, автоматизирует все функции ФО, такие, как:

-          формирование проекта бюджета;

-          проведение взаимных расчетов между уровнями бюджета;

-          расчет / принятие лимитов бюджетных обязательств;

-          учет бюджетных обязательств;

-          исполнение бюджета по расходам;

-          исполнение бюджета по доходам;

-          операции с привлеченными средствами и средствами, размещенными на возвратной основе;

-          бухгалтерский учет;

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

-          учет гарантий и поручительств;

-          исполнение бюджета по источникам покрытия дефицита бюджета;

-          исполнение доходов и расходов целевых бюджетных фондов;

-          проведение операций с ценными бумагами;

-          анализ исполнения бюджета, получение и свод отчетности об исполнении бюджета;

-          капитальное строительство и другие.

Рассмотренные автоматизированная информационная система АС «Бюджет» и комплексная система АЦК-Финансы обеспечивает построение эффективной системы управления бюджетным процессом региона за счет централизации всей информации о ходе бюджетного процесса и автоматизации всех участков и всех участников бюджетного процесса. Однако бюджетный процесс в региональных финансовых органах имеет ряд специфических особенностей и требует специальных методов и инструментов. В результате этого финансовое управление администрации Новоегорлыкского сельского поселения поставило перед информационным отделом задачу разработки информационной системы автоматизации процесса планирования бюджета, которая должна учитывать особенности в части многовариантности расчетов проекта бюджета, а также оперативности и точности расчетов параметров бюджета.

 

1.3    Моделирование бизнес-процессов предметной области

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

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

Рисунок 1.1 – Бизнес-процесс «Формирование сметы расходов распорядителя»

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

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

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

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

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

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

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

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

Рисунок 1.2 – Бизнес-процесс «Формирование сметы доходов администратора бюджетных средств»

На рисунке 1.3 представлена схема бизнес-процесса по формированию сметы администратора источников финансирования дефицита.

Рисунок 1.3 – Бизнес-процесс «Формирование сметы администратора источников финансирования дефицита бюджета»

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

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

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

Рисунок 1.4 – Бизнес-процесс «Формирование доходной части проекта бюджета»

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

В рамках данного бизнес процесса производится суммирование объемов доходов администраторов бюджетных средств, представленных во входных документов – сметах доходов администраторов бюджетных средств – в соответствии с бюджетной классификацией Российской Федерации.

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

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

Рисунок 1.5 – Бизнес-процесс «Формирование расходной части проекта бюджета»

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

В рамках данного бизнес-процесса производится суммирование объемов расходов распорядителей бюджетных средств, представленных во входных документах – сводных сметах расходов распорядителей бюджетных средств – в соответствии с бюджетной классификацией Российской Федерации.

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

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

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

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

Рисунок 1.6 – Бизнес-процесс «Формирование источников финансирования дефицита бюджета»

На рисунке 1.7 представлена схема бизнес-процесса направленного на поддержание проекта бюджета в актуальном состоянии в течение всего года.

Рисунок 1.7 – Бизнес-процесс «Корректировка проекта бюджета»

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

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

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

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

Рисунок 1.8 – Бизнес-процесс «Формирование консолидированного бюджета территории»

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

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

1.4      Анализ и моделирование требований

 

1.4.1   Формирования функциональных требований

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

Заинтересованные в системе пользователи, которые были выявлены в процессе исследования бизнес-процессов и предпроектного обследования Финансового управления, представлены на рисунке 1.9.

Рисунок 1.9 – Пользователи системы

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

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

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

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

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

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

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

На рисунке 1.10 представлены варианты использования системы распорядителем бюджетных средств.

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

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

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

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

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

Рисунок 1.10 – Варианты использования системы распорядителем бюджетных средств

На рисунке 1.11 представлены варианты использования системы администратором бюджетных средств.

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

Рисунок 1.11 – Варианты использования системы администратором бюджетных средств

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

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

В процессе выполнения прецедента «Передача сметы доходов в Финансовое управление» происходит передача сметы доходов администратора бюджетных средств в Финансовое управление для проверки и окончательного утверждения.

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

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

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

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

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

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

Рисунок 1.12 – Варианты использования системы администратором источников финансирования дефицита бюджета

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

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

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

Рисунок 1.13 – Прецеденты управлении пользователями ИС

В процессе выполнения прецедента «Регистрация пользователя» администратор регистрирует в системе новую учетную запись.

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

В процессе выполнения прецедента «Удаление пользователя» администратор удаляет учетную запись пользователя и списка зарегистрированных в системе.

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

На рисунке 1.14 представлены варианты использования системы администратором автоматизированной информационной системы при управлении пользовательскими группами.

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

В процессе выполнения прецедента «Удаление пользовательской группы» администратор удаляет выбранную пользовательскую группу из списка зарегистрированных в системе групп.

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

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

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

Рисунок 1.14 – Прецеденты управления пользовательскими группами

В процессе выполнения прецедента «Формирование справочников бюджетной классификации» администратор производит заполнение справочников бюджетной классификации.

В процессе выполнения прецедента «Импорт справочников бюджетной классификации» администратор производит формирование справочников бюджетной классификации путем импорта данных из справочников бюджетной классификации прошлых лет. После импорта данных администратор проводит их корректировку, для того чтобы данные, содержащиеся в справочниках, соответствовали бюджетной классификации Российской Федерации для текущего года.

Рисунок 1.15 – Прочие варианты использования системы администратором

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

В процессе выполнения прецедента «Формирование сети распорядителей бюджетных средств» пользователей формирует список организаций являющихся распорядителями бюджетных средств. Каждому распорядителю присваивается код в соответствии с бюджетной классификацией Российской Федерации.

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

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

Рисунок 1.16 – Варианты использования формирования проекта бюджета

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

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

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

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

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

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

Рисунок 1.17 – Варианты использование формирования проекта консолидированного бюджета территории

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

На рисунке 1.18 представлены варианты использования системы специалистом отдела прогнозирования доходов и налоговой политики.

В процессе выполнения прецедента «Формирование сети администраторов бюджетных средств» пользователь формирует список организаций являющихся администраторами бюджетных средств. Каждому администратору бюджетных средств присваивается код в соответствии с бюджетной классификацией Российской Федерации.

Рисунок 1.18 – Варианты использования прогнозирования доходов и налоговой политики

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

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

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

Рисунок 1.19 – Варианты использования общие для всех пользователей

В процессе выполнения прецедента «Аутентификация в системе» пользователь осуществляет вход в систему посредством ввода логина и пароля.

В процессе выполнения прецедента «Смена пароля» пользователь меняет пароль для своей учетной записи.

1.4.2   Формирование нефункциональных требований

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

К операционной среде, в которой должна работать проектируемая система, предъявляются следующие требования:

-          компьютер, на котором размещается серверная часть приложения, должен работать под управлением операционной системы не ниже Microsoft Windows Server 2000. Также на компьютере должны быть установленные компоненты. Net Framework 2.0;

-          компьютеры, на которых размещается клиентская часть приложения, должны работать под управлением операционной среды не ниже Microsoft Windows XP Professional Edition SP2 с установленными компонентами. Net Framework 2.0;

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

К интерфейсу пользователя предъявляются следующие требования:

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

-          формы должны быть снабжены контекстной справкой.

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

-          система должна обслуживать одновременно до 100 пользователей в период пиковой активности с 9:00 до 18:00 по местному времени;

-          отклик системы не должен превышать 10 секунд с момента передачи запроса.

-          система должна быть доступна пользователям корпоративной сети интранет и клиентам удаленного доступа по коммутируемой линии 99% времени между 0:00 и 24:00 семь дней в неделю.

К безопасности, проектируемой системы, предъявляются следующие требования:

-          все сетевые транзакции должны быть зашифрованы;

-          функции системы становятся доступными пользователю только после его аутентификации в системе;

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

Система также должна позволять экспорт выходных документов в форматы Microsoft Word и Excel.

1.5    Спецификация состояний системы

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

Рисунок 1.20 – Объекты бюджетной классификации

Таблица 1 – Сущности бюджетной классификации

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

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

Рисунок 1.21 – Объекты и сущности процесса составления смет доходов, расходов и источников финансирования дефицита

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

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

Рисунок 1.22 – Объекты и субъекты процесса составления проекта бюджета

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

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

Таблица 3 – Субъекты и объекты, участвующие в процессе составления проекта бюджета

Рисунок 1.23 – Объекты процесса составления проекта бюджета

Объект ConsolidatedBudgetProject представляется проект консолидированного бюджета территории.

1.6      Аттестация требований

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

Существует набор методов аттестации, которые можно использовать как вместе, так и по отдельности:

-          обзор требований – процесс просмотра системной спецификации на предмет неточных описаний и ошибок;

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

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

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

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

Прототипы пользовательского интерфейса рассматриваются в п. 3.2, а тестовые сценарии – п. 3.4 дипломного проекта.

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

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

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

-          методология объектно-ориентированного проектирования.

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

Все компоненты информационной системы взаимосвязаны, система разрабатывается сверху - вниз. При разработке системы снизу – вверх целостность теряется, возникают проблемы состыковки компонентов.

Наиболее распространенные модели структурного подхода:

SADT – Structured Analysis and Design Techniques – описывает модели и функциональные диаграммы;

DFD – Data Flow Diagrams – диаграммы потоков данных;

ERD – Entity Relationship Diagrams – диаграммы «сущность – связь».

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

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

Для реализации проекта был выбран объектно-ориентированный подход в силу следующих факторов:

-          возможность повторного использования кода;

-          повышение безопасности кода за счет инкапсуляции;

-          гибкость при модификации и расширении системы;

-          отсутствие необходимости разработки классов с нуля, за счет наследования;

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

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

В качестве методологии проектирования обосновано применение объектно-ориентированного подхода.

2.         Разработка информационного обеспечения

 

2.1      Разработка концептуальной модели данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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 – Описание физической модели бюджетной классификации доходов

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

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

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

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

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

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

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

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

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

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