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

 

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

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

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

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

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

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

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

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

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

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

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

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

 

2.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. Модель данных после нормализации второй формы

 

3. Разработка информационной системы финансового планирования

 

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

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

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

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

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

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

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

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

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

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

 

Рис. 3.1. Модель информационной системы финансового планирования

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

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

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

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

Система формирования выходных форм позволяет формировать интерфейс пользователя для различных АРМов. То есть различные формы для ввода и вывода данных. Эта система особенно активно используется при построении отчетов (см. рис. 3.2).

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

 

Рис. 3.2. Модель формирования форм в информационной системе

 

Система безопасности осуществляет идентификацию и аунтерификацию пользователя. Так же данная система осуществляет шифрование передаваемых данных (см. рис. 3.3).

Почти все представленные подсистемы по типу реализации можно разделить на три части.

· Системы реализованные на уровне СУБД.

· Системы реализованные на уровне приложения.

· Системы реализованные как на уровне СУБД так и на уровне приложений.

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

Рис. 3.3. Модель системы надёжности в информационной системе

 

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

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

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

· относительно низкие затраты на внедрение и эксплуатацию;

· повышение уровня эффективности использования оборудования;

· прикладные программные средства доступны с любого рабочего места, имеющего соответствующие права доступа;

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

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