КУРСОВОЙ ПРОЕКТ
Тема: «Разработка
многопользовательской информационной системы ведения документации по аренде »
Содержание
Введение
1. Техническое задание.
1.1 Анализ предметной области.
1.2 Постановка задачи.
2. Технический проект.
2.1 Функциональная модель
2.1.1 Контекстная диаграмма и диаграммы детализации
процессов.
2.1.2 Диаграмма дерева узлов.
2.2 Информационная модель.
2.2.1 Идентификация сущностей и связей. ER-диаграмма
логического уровня.
2.2.2 Нормализация схемы данных. Разрешение неспецифических
отношений. Уточнение типов данных для атрибутов схем отношений. Реализация
ссылочной целостности. Проектирование индексов. ER-диаграмма физического
уровня.
2.3 Верификация логической модели системы.
3 Реализация системы.
3.1 Описание программного обеспечения, разработанного в
архитектуре «клиент - сервер».
3.2 SQL-определения
регламентированных запросов и представлений.
4 Исследование операционных характеристик ИСС.
4.1 Описание базы данных контрольного примера.
4.2 Анализ результатов тестирования ИСС.
5 Перечень графического материала
5.1 Функциональные диаграммы первого и второго уровней.
5.2 ER-диаграмма схемы базы данных физического уровня.
5.3 Диаграмма дерева узлов функциональной модели.
Заключение
Список использованных литературных источников
Введение
Проблема накопления, хранения,
получения быстрого доступа и автоматизации обработки больших объемов информации
возникла достаточно давно. С целью ее решения в настоящее время созданы и
получили широкое распространение различные системы управления базами данных
(СУБД). Среди них выделяются Paradox, dBase, FoxPro, Oracle и Access.
Для раскрытия всех потенциальных
возможностей, которые несет в себе использование баз данных, а также облегчения
создания структуры базы данных используются CASE-технологии. Их применение
увеличивает производительность труда, улучшение качества программных продуктов,
обеспечивает поддержку унифицированного и согласованного стиля работы.
В качестве системы управления
реляционными базами данных, по заданию на курсовой проект, задан Access 2000, в
качестве CASE-средств концептуального проектирования баз данных - ERwin 4.0 и
функционального моделирования – BPwin 4.0.
1. Техническое задание
1.1 Анализ предметной области
Информационная система
предназначена для автоматизации ведения документации по аренде. Она разработана
с целью существенно сократить время на ввод данных, поиск и обработку
информации, составление отчетов.
Ведением данной
документации занимается экономический и юридический отделы.
В задачи юриста входит
заключение договоров и ввод информации о номере и дате заключения договора,
соответствующем ему арендаторе, помещении и ставке арендной платы, а также
ведение базы данных с информацией обо всех арендаторах с которыми работает
предприятие.
Экономист имеет в своем
распоряжении базу данных по имеющимся в собственности предприятия помещениям.
Исходя из площади помещения, ставки арендной платы, коэффициентов расположения
и комфортабельности рассчитывается сумма арендной платы и НДС. Кроме того
экономист проверяет зачисление на счет предприятия соответствующих сумм в день
оплаты. Ежемесячно представляет арендаторам расчетную калькуляцию, содержащую
сумму выплат за текущий месяц, а начальнику предприятия отчет о прибыли
полученной предприятием по данному направлению.
1.2 Постановка задачи
Задачей данного курсового
проекта является реализация информационной системы.
Моделируемая
информационная система предназначена для ведения документации по аренде, а
именно призвана решать следующие практические задачи:
ввод и хранение сведений
об арендаторах, помещениях, заключенных договорах;
составление расчетной
калькуляции;
составление отчета о
прибыли;
контроль своевременной
оплатой аренды;
составление списка
заключенных договоров, соответствующих им арендаторов и помещений;
2. Технический проект
2.1 Функциональная модель
Для проведения анализа и
функционального проектирования информационной системы используется CASE – средство Bpwin. Bpwin
поддерживает три методологии: IDEF0,
DFD и IDEF3, позволяющие анализировать организационную систему.
Информационная система
функционирует следующим образом.
Все данные хранятся на
внешнем носителе (диске). При необходимости работы с данными, пользователь
запускает программу, адаптированную программистом для ввода и обработки данных
в конкретной предметной области. Эта программа предоставляет пользователю
интерфейс для работы с БД и возможности манипулирования данными.
Оператор может
осуществлять ввод и корректировку данных в отношениях посредством основной и
подчиненных форм, таблиц. При закрытии таблицы или запроса, результаты
сохраняются на диск. Обработка данных производится:
-
в формах – для
вывода наглядной информации для пользователя; после закрытия формы результаты
преобразования не сохраняются;
-
в запросах – по
данным пользователя отбирается и преобразуется в нужный вид интересующая его
информация, выводится в табличном виде на экран; после закрытия запроса его
результаты обычно не сохраняются, за исключением запросов на обновление.
Вывод данных на экран
осуществляется посредством вызова соответствующих таблиц, запросов, форм или
отчетов. Таблицы соответствуют физическим данным, которые хранятся на диске.
Результаты запросов также можно сохранять в отдельных таблицах. Результаты отчетов
выводят на принтер.
2.1.1 Контекстная диаграмма и диаграммы
детализации процессов
Первая диаграмма в
иерархии диаграмм IDEF0 изображает
функционирование в целом. Такие диаграммы называются контекстными. В контекст
входит описание цели моделирования, области (описания того, что будет
рассматриваться как компонент системы, а что как внешнее воздействие) и точки
зрения (позиции, с которой будет строиться модель).
После того как контекст
описан, проводится построение следующих диаграмм в иерархии. Каждая последующая
диаграмма является более подробным описанием (декомпозицией) одной из работ на
вышестоящей диаграмме.
рисунок 1 – Контекстная
диаграмма.
Функциональная модель
(диаграммы первого и второго уровней) рассматриваемой информационной системы
изображена в приложении 5.1.
2.1.2 Диаграмма дерева
узлов
Диаграмма дерева узлов
моделируемой информационной системы изображена в приложении 5.2. На ней
представлены иерархические зависимости моделируемых процессов.
2.2 Информационная модель
2.2.1
Идентификация сущностей и связей. ER-диаграмма логического уровня
Для
отображения информационной модели рассматриваемого процесса были использованы
следующие сущности:
Арендатор
(УНН
арендатора, Наименование_арендатора, Адрес_арендатора, Телефон арендатора)
Договор
(Номер
договора, УНН арендатора, Дата_заключения, Адрес_помещения, Ставка_арендной_платы)
Помещение
(Адрес_помещения,
Тип_помещения, Площадь_помещения, Коэффициент_комфортабельности, Коэффициент_расположения)
Арендная
плата
(Номер договора,
УНН арендатора, Дата оплаты, Сумма, НДС)
Связи
между сущностями представляется в виде линии, связывающей две сущности.
Существуют три основных типа связи: один к одному, один ко многим, многие ко
многим. Обязательный конец связи изображается сплошной линией, а необязательный
- прерывистой линией.
Рассмотрим
к какому типу относятся связи между сущностями в проектируемой базе данных.
1) связь
между Арендатор и Договор, Части и Машины - один ко многим;
2)
связь между Договор и Арендная плата - один к одному;
3) связь
между Договор и Помещение – многие ко многим, необязательная;
ER-диаграмма
логического уровня представлена на рисунке 2.2.
Все ее
отношения находятся в нормальной форме БКНФ так как удовлетворяют следующим
условиям:
Все
атрибуты отношений – атомарны;
Все
атрибуты каждой сущности функционально полно зависят от первичного ключа;
В
каждой сущности все не ключевые атрибуты не транзитивно зависят от первичного
ключа;
Во
всех отношениях каждый детерминант (любой атрибут от которого функционально зависит
другой атрибут) является возможным ключом.
Рисунок 2 ER-диаграмма
логического уровня.
2.2.2 Нормализация
схемы данных. Разрешение неспецифических отношений. Уточнение типов данных для
атрибутов схем отношений. Реализация ссылочной целостности. Проектирование
индексов. ER-диаграмма физического уровня
Под понятием домена
понимается допустимое множество потенциальных значений данного типа. Следует
отметить также семантическую нагрузку понятия домена: данные считаются
сравнимыми только в том случае, когда они относятся к одному домену.
Определим первичные ключи
в описанных ранее сущностях.
В сущности «Арендатор» первичный ключ - это атрибут: «УНН арендатора». В сущности «Помещение» первичный ключ - это атрибут: «Адрес_помещения».
В сущности «Арендная плата» - это мигрирующие атрибуты «УНН арендатора» и «Номер договора» и атрибут «Дата оплаты». В
сущности «Договор» - это мигрирующий атрибут «УНН арендатора» и атрибут «Номер договора».
Далее определяются
физические свойства атрибутов.
В сущности «Арендатор»
атрибуты «УНН арендатора» и «Телефон арендатора» - числового (целочисленного) типа, все
остальные атрибуты «Наименование арендатора» и «Адрес арендатора» - текстовые
поля.
В сущности «Договор»
атрибуты «Номер договора» и «УНН арендатора» - числового (целочисленного) типа.
«Дата заключения» - поле типа дата-время. «Адрес помещения» - текстовое поле.
«Ставка арендной платы» поле числового (вещественного) типа.
В сущности «Помещение»
атрибуты «Адрес помещения» и «Тип помещения» - текстовые поля, атрибуты «Площадь
помещения», «Коэффициент комфортабельности», «Коэффициент_расположения» - поля числового (вещественного)
типа.
В сущности «Арендная плата» атрибуты «Номер договора», «УНН
арендатора», «Сумма», «НДС» - числового (целочисленного) типа, атрибут «Дата
оплаты» - поле типа дата-время.
Очевидно, что во всех
сущностях ключевые атрибуты не могут не иметь значений.
Обеспечение целостности
базы данных.
Под целостностью
понимается соответствие информационной модели предметной области, хранимой в
базе данных, объектам реального мира и их взаимосвязям в каждый момент времени.
Любое изменение в предметной области, значимое для построенной модели, должно
отражаться в базе данных.
Внешние ключи используются
для организации связей между таблицами базы данных (родительскими и дочерними)
и для поддержания ограничений ссылочной целостности данных. Ссылочная
целостность проверяется при:
- удалении записей
родительской таблицы;
- модификации значений полей
родительской таблицы, на которые ссылаются поля внешнего ключа дочерней
таблицы.
Проектирование индексов.
В базах данных для
ускорения поиска информации в таблицах применяются индексы. Их наличие
предполагает анализ записей в соответствии с возрастанием (убыванием) значений
полей, из которых сформирован индекс таблицы. Индексы могут состоять из любого
числа полей таблицы в различных их сочетаниях. Некоторые индексы создаются
автоматически. Такие индексы формируются при определении первичных ключей и совокупностей
полей с признаками уникальности. При генерировании схемы на основе модели
данных, ERwin автоматически создает индекс для первичного ключа (РК) и
отдельный индекс для каждого альтернативного ключа (АК), внешнего ключа (FK),
Inversion Entry (IE). Если у сущности не было назначено альтернативных ключей и
Inversion Entry, то ERwin создает индексы только для первичного ключа и внешних
ключей.
ER-диаграмма схемы базы
данных физического уровня представлена в приложении 5.2
2.3 Верификация
логической модели системы
После
разработки информационной модели ее следует связать с функциональной моделью.
Такая связь гарантирует завершенность анализа, гарантирует, что есть источники
данных (сущности) для всех работ. Связывание моделей способствует согласованности,
корректности и завершенности анализа.
Результат
связывания объектов модели процессов:
Activity
Name
Arrow Name
Entity Name
Attribute
Name
Ввод данных
по арендаторам
Данные по
арендаторам
Наименование
арендатора
помещения
заключения
помещения
Коэффициент
расположения
за помещение
в месяц
Наименование
арендатора
помещения
Расчет
арендной
платы за
месяц
Данные
по помещениям
Наименование
арендатора
помещения
заключения
помещения
Коэффициент
расположения
Activity
Name
Arrow Name
Entity Name
Attribute
Name
расположения
отчета
договорах
договорам
помещения
заключения
заключенных
Наименование
арендатора
помещения
заключения
Таблица 1 -
Результат связывания объектов модели процессов.
3. Реализация системы.
3.1 Описание программного
обеспечения, разработанного в архитектуре «клиент - сервер»
Программное
обеспечение архитектуры клиент-сервер состоит из двух частей: программного
обеспечения сервера и программного обеспечения пользователя-клиента. Программа-клиент
выполняется на компьютере пользователя и посылает запросы программе-серверу,
которая работает на компьютере общего доступа.
Доступ
к базе данных от прикладной программы или пользователя производится путем
обращения к клиентской части системы. В качестве основного интерфейса между
клиентской и серверной частями выступает язык баз данных SQL.
В
сети в разных компьютерах может существовать различная адресация, представление
чисел, кодировка символов и т.д. Общим решением проблемы является опора на
программные пакеты, реализующие протоколы удаленного вызова процедур (RPC -
Remote Procedure Call). При вызове удаленной процедуры программы RPC производят
преобразование форматов данных клиента в промежуточные машинно-независимые
форматы и затем преобразование в форматы данных сервера. При передаче ответных
параметров производятся аналогичные преобразования. Если система реализована на
основе стандартного пакета RPC, она может быть легко перенесена в любую
открытую среду.
Основная обработка данных
выполняется мощным сервером, а на компьютер пользователя возвращаются только
результаты выполнения запроса. Рабочая станция предназначена для
непосредственной работы пользователя или категории пользователей и обладает
ресурсами, соответствующими локальным потребностям данного пользователя.
Централизованное
хранение и управление данными в SQL Server позволяет не загружать на компьютер
каждого клиента отдельные копии данных. Это гарантирует работу всех
пользователей с одними и теми же данными.
Данные
в базе Microsoft SQL – сервер организованы в логические компоненты, такие как
таблицы, представления, сохраняемые процедуры. Физически база данных сервера может
храниться в нескольких файлах на диске.
В
данном курсовом проекте созданы и перенесены на сервер запросы. При этом они
созданы один раз а не в каждом клиентском приложении. Запросы хранятся в виде
блоков SQL кода которые заранее откомпилированы и способны быстро
выполниться. При этом нет необходимости посылать запросы по сети из клиентского
приложения.
Как
было показано при анализе предметной области, основными пользователями базы
данных являются: экономический и юридический отделы. При этом выбран вариант,
когда таблицы и запросы хранятся на сервере. Это позволяет пользователям, имея
доступ к общему источнику данных.
При
работе с данной системой пользователь проделывает ряд уровней обработки
информации: уровень первичного сбора информации, уровень хранения первичной
информации, уровень обработки информации при помощи запросов.
Работа
с базой данных для каждого пользователя начинается с автоматического открытия
главной кнопочной формы. На форме располагаются кнопки, при нажатии на которые
на экран выводятся другие формы или запрос.
Моделируемое программное
обеспечение предполагает работу с двумя клиентами – экономистом и юристом,
которые пользуются одними данными, но выполняют различные виды работ с этими
данными. Поэтому было разработано два приложения «Экономический отдел» и «Юридический
отдел».
Работа с базой данных
начинается с автоматического открытия главной кнопочной формы.
Главная кнопочная форма
клиентского приложения «Экономический отдел» представлена на следующем рисунке.
Рисунок 3 - Главная форма
клиентского приложения «Экономический отдел»
Кнопки
«Сумма и дата оплаты», «Данные расчетной калькуляции», «Отчет» и «Тип помещения»
выводят на экран соответствующие запросы. Для ввода информации служат кнопки «Добавить
запись» вызывающие на экран формы для ввода данных в таблицы «Помещения» и
«Арендная плата»
Рисунок 4.1 Форма
«Помещение»
Рисунок 4.2 Форма «Арендная
плата».
Главная кнопочная форма
клиентского приложения «Юридический отдел» представлена на следующем рисунке.
Рисунок 5 - Главная
кнопочная форма клиентского приложения «Юридический отдел».
Кнопки «Номера
договоров», «Телефон арендатора» и «Ставка по договору» вызывают на экран
соответствующие запросы. Кнопки «Добавить запись» вызывают на экран формы
заполнения таблиц «Договор» и «Арендаторы».
Рисунок 6.1 Форма
«Договор»
Рисунок 6.2 Форма
«Арендаторы»
3.2 SQL-определения регламентированных
запросов и представлений.
На базе описанных выше
таблиц для обработки данных и для нахождения некоторой информации были
построены следующие запросы:
1. Сумма и дата оплаты
Запрос с параметром
(Наименование арендатора) с помощью которого на экран выводится сумма и дата
оплаты аренды указанного арендатора.
PARAMETERS [Наименование
арендатора] Text ( 255 );
SELECT
Арендатор.[Наименование арендатора], [Арендная плата].Сумма, [Арендная
плата].НДС, [Арендная плата].[Дата оплаты]
FROM Арендатор INNER JOIN
[Арендная плата] ON Арендатор.[УНН арендатора] = [Арендная плата].[УНН
арендатора]
WHERE
(((Арендатор.[Наименование арендатора])=[Наименование арендатора]));
2. Данные расчетной
калькуляции
Запрос с параметром
(Адрес помещения) с помощью которого на экран выводится следующая информация:
ставка арендной платы, площадь помещения, коэффициенты комфортабельности и
расположения.
PARAMETERS [Адрес
помещения] Text ( 255 );
SELECT Помещение.[Адрес
помещения], Помещение.[Площадь помещения], Помещение.[Коэфф расположения],
Помещение.[Коэфф комфортабельности], Договор.[Ставка арендной платы]
FROM Помещение INNER JOIN
Договор ON Помещение.[Адрес помещения] = Договор.[Адрес помещения]
WHERE (((Помещение.[Адрес
помещения])=[Адрес помещения]));
3. Отчет
Запрос выводящий на экран
наименование арендатора, сумму арендной платы и НДС.
SELECT
Арендатор.[Наименование арендатора], [Арендная плата].Сумма, [Арендная
плата].НДС
FROM Арендатор INNER JOIN
[Арендная плата] ON Арендатор.[УНН арендатора]=[Арендная плата].[УНН
арендатора]
ORDER BY
Арендатор.[Наименование арендатора];
4. Тип помещения
Запрос с параметром (Тип
помещения) с помощью которого на экран выводится адрес и площадь помещения
заданного типа.
PARAMETERS [Тип
помещения] Text ( 255 );
SELECT Помещение.[Тип
помещения], Помещение.[Адрес помещения], Помещение.[Площадь помещения]
FROM Помещение
WHERE (((Помещение.[Тип
помещения])=[Тип помещения]))
ORDER BY Помещение.[Тип помещения];
5. Номера договоров
Выводит номера договоров,
даты заключения, наименования арендаторов и адреса помещений.
SELECT Договор.[Номер
договора], Договор.[Дата заключения], Арендатор.[Наименование арендатора],
Помещение.[Адрес помещения]
FROM Помещение INNER JOIN
(Арендатор INNER JOIN Договор ON Арендатор.[УНН арендатора]=Договор.[УНН
арендатора]) ON Помещение.[Адрес помещения]=Договор.[Адрес помещения]
ORDER BY Договор.[Номер
договора];
6. Телефон арендатора
Запрос с параметром
(Наименование арендатора) с помощью которого на экран выводится наименование и
телефон указанного арендатора.
PARAMETERS [Наименование
арендатора] Text ( 255 );
SELECT
Арендатор.[Наименование арендатора], Арендатор.[Телефон арендатора]
FROM Арендатор
WHERE (((Арендатор.[Наименование
арендатора])=[Наименование арендатора]));
7. Ставка по договору
Запрос с параметром
(Номер договора) с помощью которого на экран выводится наименование арендатора,
адрес помещения и ставка арендной платы за 1м2 соответствующие
указанному договору.
SELECT
Арендатор.[Наименование арендатора], Помещение.[Адрес помещения],
Договор.[Ставка арендной платы]
FROM Помещение INNER JOIN
(Арендатор INNER JOIN Договор ON Арендатор.[УНН арендатора]=Договор.[УНН
арендатора]) ON Помещение.[Адрес помещения]=Договор.[Адрес помещения]
ORDER BY
Арендатор.[Наименование арендатора];
4. Исследование операционных
характеристик ИСС
4.1 Описание базы
данных контрольного примера
Для проведения испытаний
созданной ИСС разработан контрольный пример, позволяющий проверить работоспособность
и отказоустойчивость последней.
База данных контрольного
примера содержит в себе следующие данные, позволяющие протестировать работу
всех запросов.
4.2 Анализ результатов
тестирования ИСС
В качестве результатов
тестирования программы приведены данные полученные с помощью запросов.
В результате проведенного
тестирования разработанная ИСС показала себя как вполне надежная программа,
выполняющая все заявленные в описании задачи.
5. Перечень
графического материала
5.1 Функциональные
диаграммы первого и второго уровней.
5.2 ER-диаграмма схемы базы данных физического уровня
Заключение
Разработанное программное
обеспечение позволяет упростить ведение документации по аренде. Данная
программа обладает всеми необходимыми компонентами для выполнения любых задач
связанных с поиском и обработкой информации, удобным графическим интерфейсом,
средствами для форматированного вывода информации на печать
Созданное программное
приложение рассчитано на работу в многопользовательском режиме. Разработаны
структуры форм и запросов для работы каждого пользователя с общей базой данных.
Общая база данных может находиться на файловом сервере или на локальной машине.
Данное программное
обеспечение разработано в архитектуре «клиент-сервер» на языке SQL.
Возможно дальнейшее совершенствование
созданного программного обеспечения.
Разработанное
программное обеспечение позволяет автоматизировать процесс ведения записей по
направлению деятельности предприятия связанному со сдачей помещений в аренду,
контролировать своевременное перечисление соответствующих сумм на счет
предприятия, оценить эффективность данного вида деятельности. Упрощает поиск и
сортировку нужной информации.
Список использованных литературных источников
1. С.
Баркер. «Профессиональное программирование в среде Access 2002» – М.: Издательский дом «Вильямс», 2002. – 956
с., ил.
2. Вейскас Дж. «Эффективная работа с Access 2002» – СПб.: Питер, 2002. – 563 с., ил.