Разработка информационной системы финансового планирования для малого предприятия (стр. 10 из 14)

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

Рис. 3.1. Контекстная диаграмма

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

После описания планирования в целом производится его декомпозиция по функциям. Диаграмма декомпозиции планирования состоит из трёх основных функций, соответствующих функциям выполняемых в процессе организации планирования (см. рис. 3.2.).

Рис. 3.2. Диаграмма декомпозиции основной функции.

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

После описания общей структуры происходит подробное описание работы каждой функции, например «Организации планирования». Декомпозиция позволяет полностью отразить организацию функционирования финансового планирования. На диаграмме декомпозиции происходит детализация функции, которая разбивается на подфункции, при этом происходит более подробное разделение входных, выходных, управляющих потоков данных по этим функциям, вплоть до разделения потоков до отдельных документов (см. рис. 3.3).

Рис. 3.3. Диаграмма декомпозиции «Организации планирования».

На диаграмме декомпозиции «Организации анализа планирования» представляется алгоритм составления аналитических данных, для использования, как управляющих, так и планирующих деятельностях (см. рис. 3.4.).

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

Рис. 3.4. Диаграмма «Организации анализа планирования».

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

4. РАЗРАБОТКА ИНФОРМАЦИОННОЙ МОДЕЛИ ФИНАНСОВОГО ПЛАНИРОВАНИЯ

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

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

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

1) Таблицы с фактическими данными.

2) Системные таблицы.

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

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

Таблица TS_PLANпредставляет собой справочник планов, основная ее функция это хранение данных о текущих планах.

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

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

Таблицы фактических данных TKREDFAKT и TKREDZADFAKT тоже достаточно похожи на предыдущие таблицы TDEBZAD и TKREDZAD, но с одним отличаем – фактические данные не разбиваются на базовые, оптимистические и пессимистические.

Справочник TS_TIME необходим для наглядного представления данных хранящихся в таблицах TKREDFAKT, TKREDZADFAKT, TDEBZAD, TKREDZAD. Дело в том, что данные о месяце в этих таблицах хранятся в числовом формате, а для удобства пользования эти данные необходимо преобразовать.

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

4.2 Логическая структура данных планирования

После создания всех сущностей и атрибутов, необходимых для описания всего документооборота начинается разработка логической модели базы данных. Внесение сущностей и их атрибутов в логическую модель осуществляется путем импорта данных из BPwin в Erwin. Сущности и их атрибуты, определенные в BPwin переместятся в логическую модель в ERwin. Импортированные сущности не имеют первичного ключа и не связаны друг с другом. Назначение атрибутов первичным ключом и связывание сущностей осуществляется только средствами Erwin, т. е. сущности и атрибуты, созданные в BPwin и затем импортированные в Erwin, рассматривают как заготовку для создания полноценной модели данных, а не как готовую модель (см. рис. 4.1).

Рис. 4.1. Модель данных после импорта сущностей и атрибутов

Далее заносится описание и комментарии сущности. Каждая сущность должна быть полностью определена с помощью текстового описания.

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

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

В результате выполнения этих действий получаем ненормализованную логическую модель данных (см. рис. 4.2).

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

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

Первая нормальная форма требует, чтобы все атрибуты были атомарными. Для этого атрибут "FC_ADRESS" был разбит на атрибуты "FC_COUNTRY", "FC_REGION", "FC_TOWN", "FC_STREET", "FC_OFIS" и добавлен атрибут “FP_TYPE” для определения типа документа. (см. рис. 4.3)

Рис. 4.3. Модель данных после нормализации первой формы

Вторая нормальная форма требует, чтобы каждый неключевой атрибут зависел от всего первичного ключа, не должно быть зависимости от части ключа. Для приведения ко второй нормальной форме создадим новую сущность «TPLAN», в которую перенесем атрибуты “FC_FAM”, “FC_NAME”, “FN_KOLV”, “FC_OTKLON”, «FN_SALARY», зависящие от части ключа (“FN_TAB_NUM”). В новой сущности создаем новый первичный ключ «FK_PLANID» и устанавливаем идентифицирующую связь от новой сущности к старой, аналогично выделяем сущность «TADRESS» (см. рис. 4.4).

Рис. 4.4. Модель данных после нормализации второй формы

5. РАЗРАБОТКА ИНФОРМАЦИОННОЙ СИСТЕМЫ ФИНАНСОВОГО ПЛАНИРОВАНИЯ

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

· Система регламентирования;

· Система планирования;

· Система контроля и учёта;

· Система консолидации и анализа данных;

· Система формирования выходных форм;

· Система оповещения и временного контроля;

· Система безопасности.

5.1. Архитектура системы

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