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

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

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

Безналичные расчеты существуют в следующих формах: - расчеты платежными поручениями;

- расчеты по аккредитиву;

- расчеты чеками.

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

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

1. Системный анализ и анализ требований к базе данных

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

- сведения о расчетах по аккредитиву: номер документа, номер расчетного аккредитива, банк - поручитель, тип аккредитива, ФИО получателя, дата открытия аккредитива, сумма;

- сведения о расчетах чеками: номер документа, номер расчетного чека, вид чека, ФИО получателя, дата открытия чека, срок действия чека;

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

2. Концептуальная (инфологическая) модель предметной области

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

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

Состав атрибутов и их описание для сущностей «Расчетные поручения», «Расчеты по аккредитивам», «Расчеты по чекам» представлены в таблицах 1, 2, 3.

Таблица 1 - Атрибуты сущности «Расчетные поручения»

Имя атрибута Описание

Номер документа Первичный ключ - уникальный номер, однозначно идентифицирующий расчетные средства

Номер расчетного поручения Внешний ключ

ФИО получателя Получатель расчетного поручения

Дата подачи расчетного поручения Дата, после которой в течение 2 дней поручение должно поступить

Предоставленная услуга За какие предоставленные услуги подается поручение

Цель расчетного поручения Возврат долга, за оказанную услугу

Сумма Расчетное поручение на сумму в виде денежных показателей

Таблица 2 - Атрибуты сущности «Расчеты по аккредитивам»

Имя атрибута Описание

Номер документа Первичный ключ - уникальный номер, однозначно идентифицирующий расчетные средства

Номер расчетного аккредитива Внешний ключ

Банк - поручитель Через данный банк проходит аккредитив

Дата подачи расчетного аккредитива Дата, согласно которой аккредитив поступил в банк

Тип аккредитива Покрытый или открытый

ФИО получателя Получатель аккредитива

Сумма Расчетный аккредитив на сумму в виде денежных показателей

Таблица 3 - Атрибуты сущности «Расчеты чеками»

Имя атрибута Описание

Номер документа Первичный ключ - уникальный номер, однозначно идентифицирующий расчетные средства

Номер расчетного чека Внешний ключ

ФИО получателя Получатель расчетного поручения

Дата открытия чека Дата, согласно которой чек был открыт

Срок действия чека Период, согласно которому чек должен быть погашен

Вид чека Тип чековой операции

Сумма Расчетный чек на сумму в виде денежных показателей

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

Таблица 4 - Состав базы данных информационной системы

№ п/п Сущности концептуальной модели Таблицы физической модели

Название Информация

1. Расчетные поручения Porychens Информация о расчетных поручениях

2. Расчеты по аккредитивам Accreditivs Информация о расчетах по аккредитиву

3. Расчеты чеками Cheks Информация о расчетах по чекам

Таблица 5 - Связи между объектами базы данных информационной системы

№ п/п Концептуальная модель Физическая модель

1. Расчетные поручения - расчеты по аккредитивам Porychens - Accreditivs

2. Расчеты по аккредитивам - расчеты по чекам Accreditivs - Cheks

Для создания концептуальной модели выполняются в CASE-средстве методологии IDEF1X с помощью ERWIN. CASE-средство ERWIN поддерживает методологию IDEF1X и стандарт IE (Information engineering).

Первым шагом при создании логической модели БД является построение диаграммы ERD (Entity Relationship Diagram). ERD-диаграммы состоят из трех частей: сущностей, атрибутов и взаимосвязей. Сущностями являются существительные, атрибуты - прилагательными или модификаторами, взаимосвязи - глаголами.

3. ERD-диаграмма

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

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

Рисунок 1 - Логическая модель базы данных

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

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

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

• никакой из атрибутов первичного ключа не должен иметь нулевое значение;

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

Следующим этапом при построении логической модели является определение ключевых атрибутов и типов атрибутов. Типы атрибутов представлены в таблице 6.

Таблица 6 - Типы атрибутов

Атрибут Тип

Номер документа Number

ФИО получателя String

Дата открытия документа Date

Сумма документа Number

Цель расчетного документа String

Предоставленная услуга String

Тип документа String

Далее проводится нормализация базы данных.

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

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

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

В модели каждая сущность или атрибут идентифицируется с помощью имени. ERWIN поддерживает корректность имен следующим образом: • отмечает повторное использование имени сущности и атрибута;

• не позволяет внести в сущность более одного внешнего ключа;

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

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

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

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

4. Физическая модель проектируемой базы данных

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

4.1 Трансформационная модель

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

4.2 Модель СУБД

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

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

Таблица 7 - Сопоставление компонентов логической и физической модели

Логическая модель Физическая модель

Сущность Таблица

Атрибут Столбец

Логический тип (текст, число, дата) Физический тип (конкретный тип, зависящий от выбранной СУБД)

Первичный ключ Первичный ключ, индекс PK

Внешний ключ Внешний ключ, индекс FK

Альтернативный ключ AK - индекс - уникальный, не первичный индекс

В итоге получим физическую модель, сгенерированную ERWIN по умолчанию (рисунок 2).

Рисунок 2 - Физическая модель базы данных

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

Таблица 8 - Свойства колонок таблиц физической модели БД

Атрибут Тип Размер

Номер документа Numeric 5

ФИО получателя Character 25

Дата открытия документа Date 8

Сумма документа Numeric 10

Цель расчетного документа Character 30

Предоставленная услуга Character 30

Тип документа Character 20

Таким образом, проделав все вышеописанные действия, мы получили модель БД, готовую для помещения в СУБД. Для генерации кода создания БД необходимо выбрать пункт меню Tools- > Forward Engineer/Schema Generation, после чего откроется окно установки свойств генерируемой схемы данных. Для предварительного просмотра SQL-скрипта служит кнопка Preview, для генерации схемы - Generate. В процессе генерации ERWIN связывается с БД, выполняя SQL-скрипт.

5. Создание форм, запросов и отчетов в среде СУБД Visual FOXPRO 8.0

После генерации БД можно приступить к созданию связей, форм, запросов и отчетов непосредственно в СУБД Visual FOXPRO 8.0. Первоначально нужно занести данные в созданные таблицы.

Структура таблиц и связи между ними в FOXPRO 8.0 представлена на рисунке 3.

Рисунок 3 - Структура таблиц и связей между ними в FOXPRO 8.0

Часть занесенных данных представлена на рисунках 4, 5, 6.

Рисунок 4 - Данные таблицы «Расчетные поручения»

Рисунок 5 - Данные таблицы «Расчеты по аккредитивам»

Рисунок 6 - Данные таблицы «Расчеты по чекам»

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

Конечный вид форм представлен на рисунках 8, 9,10.

Рисунок 7 - Форма по таблице «Расчетные поручения»

Рисунок 8- Форма по таблице «Расчеты по аккредитивам»

Рисунок 9 - Форма по таблице «Расчеты по чекам»

По данным таблицам были созданы 3 отчета, которые представлены в приложениях А, Б и В.

Далее были созданы следующие запросы: 1) Выдать информацию получателях, сумма которых > 10 000 руб. (рисунок 10). В результате получили информацию, по полям, выбранным во вкладке Fields, об этом получателе (рисунок 10).

Рисунок 10 - Query Designer - запрос получателя по расчетным поручениям

Рисунок 11 - Полученная информация

2) Запрос банка «Сбербанк» (рисунок 12) и информация о них по выбранным полям на рисунке 12.

Рисунок 12 - Query Designer - запрос банка «Сбербанк»

Рисунок 13 - Полученная информация

На основе этих запросов были созданы отчеты. Они представлены в приложениях Г и Д.

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

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

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

1. Мусина Т.В. Visual FOXPRO 8.0. Учебный курс - К.: ВЕК , СПБ.: КОРОНА принт, К.: НТИ, 2004. - 464 с.

2. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для высших учебных заведений / Под ред. проф. А.Д. Хомоненко. - 5-е изд., доп. и перераб. - СПБ.: КОРОНА принт, 2006. - 736 с.

3. Бухгалтерский учет в организации/ Козлова Е.П., Бабченко Т.Н., Галанина Е.Н. - М.: Финансы и статистика, 2005. - 322 с.

4. Управление финансами: Учеб. пособие для вузов/ Н.Н. Тренев. - М.: "Финансы и статистика", 2005. - 215 с.

5. www.aup.ru/books/m169/2_4.htm

6. www.bankirsha.com