|
№
п/п
|
Концептуальная
модель
|
Физическая
модель
|
|
1.
|
Расчетные
поручения - расчеты по аккредитивам
|
Porychens
- Accreditivs
|
|
2.
|
Расчеты
по аккредитивам - расчеты по чекам
|
Accreditivs
- Cheks
|
Для создания концептуальной модели выполняются в
CASE-средстве методологии IDEF1X с помощью ERwin. CASE-средство ERwin
поддерживает методологию IDEF1X и стандарт IE (Information engineering).
Первым шагом при создании логической модели БД
является построение диаграммы ERD (Entity Relationship Diagram). ERD-диаграммы
состоят из трех частей: сущностей, атрибутов и взаимосвязей. Сущностями
являются существительные, атрибуты - прилагательными или модификаторами,
взаимосвязи - глаголами.
3. ERD-диаграмма
диаграмма позволяет рассмотреть систему целиком
и выяснить требования, необходимые для ее разработки, касающиеся хранения
информации.
При создании концептуальной модели были
определены сущности и атрибуты сущностей. Была выделена одна основная сущность.
Из этих данных составлена логическая модель базы данных представленная на
рисунке 1.
Рисунок 1 - Логическая модель базы данных
В логической модели базы данных использованы
связи один ко многим. Это означает, что несколько экземпляров первой сущности
взаимодействует с несколькими экземплярами второй сущности. Взаимосвязи
отображаются линиями, соединяющими две сущности с точкой на одном конце и
глаголом, располагаемым над линией.
Каждая сущность содержит горизонтальную линию,
разделяющую атрибуты на две группы. Атрибуты, расположенные над линией,
называются первичным ключом. Первичный ключ предназначен для уникальной
идентификации экземпляра сущности.
При создании сущности необходимо выделить группу
атрибутов, которые потенциально могут стать первичным ключом (потенциальные
ключи), затем произвести отбор атрибутов для включения в состав первичного
ключа, следуя следующим рекомендациям:
• первичный ключ должен быть подобран таким
образом, чтобы по значениям атрибутов, в него включенных, можно было точно
идентифицировать экземпляр сущности;
• никакой из атрибутов первичного ключа не
должен иметь нулевое значение;
• значения атрибутов первичного ключа не должны
меняться. Если значение изменилось, значит, это уже другой экземпляр сущности.
Следующим этапом при построении логической
модели является определение ключевых атрибутов и типов атрибутов. Типы
атрибутов представлены в таблице 6.
Таблица 6 - Типы атрибутов
|
Атрибут
|
Тип
|
|
Номер
документа
|
Number
|
|
ФИО
получателя
|
String
|
|
Дата
открытия документа
|
Date
|
|
Сумма
документа
|
Number
|
|
Цель
расчетного документа
|
String
|
|
Предоставленная
услуга
|
String
|
|
Тип
документа
|
String
|
Далее проводится нормализация базы данных.
Нормализация - процесс проверки и реорганизации
сущностей и атрибутов с целью удовлетворения требований к реляционной модели
данных. Нормализация позволяет быть уверенным, что каждый атрибут определен для
своей сущности, значительно сократить объем памяти для хранения данных.
Для рассмотрения видов нормальных форм введем
понятия функциональной и полной функциональной зависимости.обеспечивает только
поддержку нормализации, но не содержит в себе алгоритмов, автоматически
преобразующих модель данных из одной формы в другую. В ERwin есть поддержка
первой нормальной формы.
В модели каждая сущность или атрибут
идентифицируется с помощью имени. ERwin поддерживает корректность имен
следующим образом:
• отмечает повторное использование имени
сущности и атрибута;
• не позволяет внести в сущность более одного
внешнего ключа;
• запрещает присвоение неуникальных имен
атрибутов внутри одной модели, соблюдая правило «в одном месте - один факт».
Нормализуем БД до третьей нормальной формы. Для
приведения базы данных в первую нормальную форму необходимо выполнить условие,
при котором все атрибуты содержат атомарные значения. Рассматривая все сущности
БД можно убедиться, что все атрибуты содержат атомарные значения и,
следовательно, БД находится в первой нормальной форме.
Проверим соответствие БД второй нормальной
форме. Все не ключевые атрибуты полностью должны зависеть от первичного ключа.
Это условие выполняется для всех сущностей БД; следовательно, можно сделать
вывод о том, что она находится во второй нормальной форме.
Для приведения БД к третьей нормальной форме
необходимо обеспечить отсутствие транзитивных зависимостей не ключевых
атрибутов. Получим БД в третьей нормальной форме, так как транзитивных
зависимостей не ключевых атрибутов нет. Из этого следует, что полученная
логическая модель базы данных не изменится.
4. Физическая модель проектируемой
базы данных
.1 Трансформационная модель
Целью трансформационной модели является
предоставление информации администратору БД для создания эффективной структуры
хранения, включающей в себя записи, формирующие БД. Трансформационная модель
должна помочь разработчикам выбрать структуру хранения данных и реализовать
систему доступа к ним.
.2 Модель СУБД
Модель СУБД напрямую транслируется из
трансформационной модели, являясь отображением системного каталога. 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 отчета,
которые представлены в приложениях А, Б и В.
Рисунок 10 - Query Designer - запрос получателя
по расчетным поручениям
Рисунок 11 - Полученная информация
) Запрос банка «Сбербанк» (рисунок 12) и
информация о них по выбранным полям на рисунке 12.
Рисунок 12 - Query Designer - запрос банка
«Сбербанк»
Рисунок 13 - Полученная информация
На основе этих запросов были созданы отчеты. Они
представлены в приложениях Г и Д.
Заключение
Проанализировав безналичные формы отчетности
видны их преимущества и недостатки. Руководствуясь ими можно выбрать более
подходящий способ проведения операции для ведения деятельности предприятия. Из
анализа предметной области были выбраны следующие виды расчетов для
автоматизации движения денежных средств через кассу: расчетные поручения,
расчеты по аккредитивам, расчеты по чекам.
Для более удобной работы с базой данных были
созданы формы по каждой из таблиц. В дальнейшем возможно улучшение интерфейса
форм.
Созданы запросы, с помощью которых можно
систематизировать данные о безналичных расчетах.
Список использованных источников
1. Мусина
Т.В.
Visual FoxPro 8.0. Учебный курс - К.: ВЕК +, СПб.:
КОРОНА принт, К.: НТИ, 2004. - 464 с.
2. Хомоненко
А.Д., Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для высших учебных
заведений / Под ред. проф. А.Д. Хомоненко. - 5-е изд., доп. и перераб. - СПб.:
КОРОНА принт, 2006. - 736 с.
. Бухгалтерский
учет в организации/ Козлова Е.П., Бабченко Т.Н., Галанина Е.Н. - М.: Финансы и
статистика, 2005. - 322 с.
. Управление
финансами: Учеб. пособие для вузов/ Н.Н. Тренев. - М.: "Финансы и
статистика", 2005. - 215 с.
5. www.aup.ru/books/m169/2_4.htm
<#"656504.files/image014.gif">
Приложение Б
Приложение В
Приложение Г
база данные инфологический модель
Приложение Д
Похожие работы на - Разработка базы данных информационной системы для автоматизации движения денежных средств через кассу по целевому рынку