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

Инструментальные  средства RAD обладают удобным графическим  интерфейсом пользователя и позволяют  на основе стандартных объектов формировать  простые приложения без написания  кода программы. Это является большим  преимуществом RAD, так как в значительной степени сокращает рутинную работу по разработке интерфейсов пользователя (при использовании обычных средств разработка интерфейсов представляет собой достаточно трудоемкую задачу, решение которой отнимает много времени). Высокая скорость разработки интерфейсной части приложений позволяет быстро создавать прототипы и упрощает взаимодействие с конечными пользователями [10, С. 82].

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

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

Все наиболее распространенные методологии структурного подхода базируются на ряде общих  принципов [14, С.104]. В качестве двух базовых принципов используются следующие:

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

Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, поскольку игнорирование  любого из них может привести к  непредсказуемым последствиям (в  том числе и к провалу всего  проекта). Основными из этих принципов  являются следующие [14, С. 105]:

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

В структурном  анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и  отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенной среди которых являятся: ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".

На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные  схемы программ и диаграммы экранных форм [14, С.108].

Семантическая модель (концептуальная модель, инфологическая модель) – модель предметной области, предназначенная для представления  семантики предметной области на самом высоком уровне абстракции. Это означает, что устранена или  минимизирована необходимость использовать понятия "низкого уровня", связанные  со спецификой физического представления  и хранения данных [4, С 139].

Семантическое моделирование стало предметом  интенсивных исследований с конца 1970-х годов. Основным побудительным  мотивом подобных исследований (т.е. проблемой, которую пытались разрешить  исследователи) был следующий факт. Дело в том, что системы баз  данных обычно обладают весьма ограниченными  сведениями о смысле хранящихся в  них данных. Чаще всего они позволяют  лишь манипулировать данными определенных простых типов и определяют некоторые  простейшие ограничения целостности, наложенные на эти данные. Любая  более сложная интерпретация  возлагается на пользователя. Однако было бы замечательно, если бы системы  могли обладать немного более  широким объемом сведений и несколько  интеллектуальнее отвечать на запросы  пользователя, а также поддерживать более сложные (т.е. более высокоуровневые) интерфейсы пользователя [11, С. 35].

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

Наиболее  известным представителем класса семантических  моделей является модель "сущность-связь" (ER-модель).Методология построения баз  данных базируется на теоретических  основах их проектирования. Для понимания  концепции методологии приведем основные ее идеи в виде двух последовательно  реализуемых на практике этапов:

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

• понять специфику и структуру ее деятельности;
• построить схему информационных потоков:
• проанализировать существующую систему;
• определить информационные объекты и соответствующий состав реквизитов (параметров, характеристик), описывающих их свойства и назначение.

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

Модель  Сущность-Связь (ER-модель) (англ. entity-relationship model (ERM) или англ. entity-relationship diagram (ERD)) — модель данных, позволяющая описывать концептуальные схемы. Предоставляет собой графическую нотацию, основанную на блоках и соединяющих их линиях, с помощью которых можно описывать объекты и отношения между ними какой-либо другой модели данных. В этом смысле ER-модель является мета-моделью данных, то есть средством описания моделей данных [9, С. 37].

Модель "сущность-связь" была предложена в 1976 году Питером Пин-Шен Ченом (англ. Peter Pin-Shen Chen) – американским профессором компьютерных наук в университете штата Луизиана. Фактически Чен не изобретал модель, он взял идеи из более ранних работ таких практиков, как А. Браун и других. Однако Питер Чен сделал больше, чем кто бы то ни было до него для формализации и популяризации ER-модели, а также для её внедрения в научную литературу.

В связи  с наглядностью представления концептуальных схем баз данных ER-модели получили широкое  распространение в системах CASE, поддерживающих автоматизированное проектирование реляционных  баз данных. Среди множества нотаций ER-моделей одна из наиболее развитых – Unified Modeling Language (Унифицированный язык моделирования), сокр. UML – применяется  в системе CASE фирмы ORACLE. Нотация UML так  же используется и/или поддерживается: Borland Software Corporation, Университетом Бремена, Университетом Кента, Университетом.

Основные  преимущества ER-моделей [1, С. 68]:

• наглядность;
• модели позволяют проектировать базы данных с большим количеством объектов и атрибутов;

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

Основные  элементы ER-моделей:

• объекты (сущности);
• атрибуты объектов;
• связи между объектами.

Сущность - любой объект предметной области, имеющий атрибуты.

Связь между  сущностями характеризуется:

• типом связи (1:1, 1:М, М:М);
• классом принадлежности. Класс может быть обязательным и необязательным. Если каждый экземпляр сущности участвует в связи, то класс принадлежности – обязательный, иначе – необязательный.

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

Основные  элементы данной модели:

1. Описание объектов предметной области и связей между ними.
2. Описание информационных потребностей пользователей (описание основных запросов к БД).
3. Описание документооборота. Описание документов, используемых как исходные данные для БД и документов, составляемых на основе БД.
4. Описание алгоритмических зависимостей между данными.
5. Описание ограничений целостности, т.е. требований к допустимым значениям данных и к связям между ними.

Логическое (даталогическое) проектирование – отображение инфологической модели на модель данных, используемую в конкретной СУБД, например на реляционную модель данных. Для реляционных СУБД даталогическая модель – набор таблиц, обычно с указанием ключевых полей, связей между таблицами. Если инфологическая модель построена в виде ER-диаграмм (или других формализованных средств), то даталогическое проектирование представляет собой построение таблиц по определённым формализованным правилам, а также нормализацию этих таблиц. Этот этап может быть в значительной степени автоматизирован [11, С. 40].

Физическое  проектирование – реализация даталогической модели средствами конкретной СУБД, а также выбор решений, связанных с физической средой хранения данных: выбор методов управления дисковой памятью, методов доступа к данным, методов сжатия данных и т.д. – эти задачи решаются в основном средствами СУБД и скрыты от разработчика БД [11, С. 42].

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

1. основные объекты предметной области (объекты, о которых должна храниться информация в БД);
2. атрибуты объектов;
3. связи между объектами;
4. основные запросы к БД.

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

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

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

Выводы  по разделу 1

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

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

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

 

 

 

 

Раздел  2. Проектирование базы данных.

1. Построение функциональной модели предметной области в пакете BPwin.

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

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

 

Рис 2.1  Модель бизнес-процесса в стандарте IDEF0

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