Программная система учета и анализа товарооборота на ИПТД "Скарлет"
Автоматизация учета и анализа товарооборота на предприятии. Разработка архитектуры программной системы. Рассмотрение физической модели базы данных, алгоритма программы. Прогнозирование уровня продажи товаров в программном средстве Borland C++ 6.0.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | дипломная работа |
Язык | русский |
Дата добавления | 01.05.2015 |
Размер файла | 1,6 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО
ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
«ОРЕНБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»
Факультет информационных технологий
Кафедра программного обеспечения вычислительной техники и автоматизированных систем
ДИПЛОМНАЯ РАБОТА
Программная система учета и анализа товарооборота на ИПТД "Скарлет"
Руководитель Е.Н. Ишакова
Дипломник А.К.Агишева
Консультанты по разделам: Р.Р.Рахматуллин
Е.Л.Горшенина
Нормоконтролер В.Н.Костин
Рецензент А.В.Каменев
Введение
Среди многообразия хозяйственных операций предприятия ИПТД «Скарлет», занимающейся продажей бытовой химии, учет товара является наиболее трудоемким. Одна из основных задач учета товарооборота, состоит в правильной организации предоставляемой отчетности, позволяющей своевременно получать информацию о ходе поступления товара, о выполнении договорных обязательств с поставщиками и получателями продукции/1/.
Основной упор в рассмотрении вопросов, будет сделан именно на специфику ведения складского учета, ведения оперативного учета и составления разного рода отчетности перед контрагентами по данному роду деятельности.
Ввиду того, что весь процесс документооборота и нормативно-правовых отношений уже сформирован и устоялся на данном предприятии, будущая программная система, и весь ее функционал возможностей, будут разрабатываться в строгом соответствии с этими правилами и устоями.
При разработке программного средства была поставлена задача практической реализации автоматизации следующих задач сотрудника (оператора) отдела сбыта:
- ведение расходных и приходных накладных;
- ведение информации по типам товаров с выводом на печать;
- печать прайс листа;
- ведение документации договоров по работе с персоналом;
Для составления договора ранее необходимо было находить данные путем ручного просмотра всей документации по клиентам, номенклатуре, что в условиях большого количества последних занимает продолжительное время, требует от сотрудника большого внимания, что приводит к значительному психологическому напряжению. Ведение расходных и приходных накладных очень часто приводит к ошибкам, так раннее это все велось вручную. Разработка программной системы позволит оптимизировать работу сотрудника(оператора) в частности и работу всего предприятия в целом, что в свою очередь позволит повысить прибыль.
Целью дипломной работы является автоматизация учета и анализа товарооборота на предприятии ИПТД «Скарлет».
Для достижения поставленной цели необходимо решить следующие инженерные задачи:
1) системный анализ предметной области:
а) анализ информационных потоков предприятия;
б) анализ существующих аналогов программной системы;
в) разработка математической модели задачи;
2) разработка программной системы:
а) обоснование выбора метода и инструментальных средств разработки;
б) разработка архитектуры программной системы;
в) реализация функционального назначения программной системы;
г) проектирование базы данных:
- разработка инфологической модели БД;
- разработка даталогической модели БД;
- разработка физической модели БД;
д) разработка алгоритма приложения;
3) разработка сопровождающей документации программной системы (программисту, пользователю);
4) оценка экономической эффективности от внедрения программной системы;
5) разработка мероприятий по обеспечению безопасности труда.
1. Аналитический раздел
1.1 Анализ предметной области
Товарооборот -- это процесс обмена товаров на деньги. Владелец товара -- торговое предприятие -- за деньги продает товар в собственность другому юридическому или физическому лицу. Товарооборот характеризует процесс движения товаров посредством актов купли-продажи. Как экономическая категория товарооборот характеризуется наличием одновременно двух признаков: товара как объекта продажи; продажи как формы движения товара от производителя к потребителю.
Товарооборот торгового предприятия можно рассматривать:
1) как результат деятельности предприятия торговли, его экономический эффект;
2) как показатель товарного снабжения населения, один из показателей уровня жизни. В торговом предприятии товарооборот выражается в объеме денежной выручки за проданные товары -- по его размеру можно судить о значимости данного предприятия на потребительском рынке/1/.
Оптовый товарооборот -- это продажа товаров торговыми предприятиями другим предприятиям, использующим эти товары либо для последующей реализации, либо для производственного потребления в качестве сырья и материалов, либо для материального обеспечения хозяйственных нужд. В результате оптового товарооборота товары не переходят в сферу личного потребления, а остаются в сфере обращения или поступают в производственное потребление. Иными словами, при оптовом обороте товар реализуется для последующей переработки или перепродажи. Оптовый товарооборот классифицируется:
1) по назначению;
2) форме организации товародвижения.
В зависимости от назначения оптовый товарооборот разделяется:
1) на оптовый товарооборот по реализации;
2) на внутрисистемный оптовый товарооборот.
Оптовый товарооборот по реализации -- это продажа товаров предприятиям розничной торговли, общественного питания, поставки внерыночным потребителям, на экспорт и по клирингу.
Таким образом, оптовый товарооборот по реализации характеризует процесс непосредственной оптовой продажи товаров, а внутрисистемный оптовый товарооборот -- движение товаров между звеньями оптовой торговли. Сумма двух видов оптового товарооборота составляет валовой оптовый товарооборот.
В зависимости от организации товародвижения каждый из двух видов оптового товарооборота делится: складской, транзитный.
Складской оптовый товарооборот -- эта продажа товаров со складов оптовых торговых предприятий.
Транзитный оптовый товарооборот -- это поставка товаров производителями непосредственно розничной торговле, минуя складские звенья.
Анализируя данные предметной области разрабатываемой программной системы, необходимо рассмотреть организационную структуру предприятия (рисунок 1.1), а также информационные потоки (рисунок 1.2) между структурными подразделениями предприятия, которые в последствии будут автоматизированы.
Размещено на http://www.allbest.ru/
Рисунок 1.1 Структура предприятия ИПТД «Скарлет»
Размещено на http://www.allbest.ru/
Рисунок 1.2 Информационные потоки предприятия
Описание всех информационных потоков представленных выше:
1 - должностные инструкции
2 - сведения о результатах работы
3 - положение о работе
4 - сведения о результатах работы отдела
5 - информация о денежных средствах
6 - запрос об информировании денежных средств
7 - приходный ордер;
8 - расходный ордер;
9 - запрос на закупку;
10 - информация о денежных потоках;
11 - информация о результатах деятельности;
12 - выдача приказов.
Толстыми стрелками обозначены потоки, подлежащие автоматизации. Объектом автоматизации в рамках разрабатываемой программной системы являются функции сотрудника отдела сбыта.
1.2 Анализ аналогов программных средств
автоматизация учет товарооборот алгоритм
В результате анализа был произведен поиск аналогов подобных программных систем.
Была выявлена следующая программная система
"1С:Торговля и склад" автоматизирует работу на всех этапах деятельности предприятия.
Типовая конфигурация позволяет:
- вести раздельный управленческий и финансовый учет;
- вести учет от имени нескольких юридических лиц;
- вести партионный учет товарного запаса с возможностью выбора метода списания себестоимости (FIFO, LIFO, по средней);
- вести раздельный учет собственных товаров и товаров, взятых на реализацию;
- оформлять закупку и продажу товаров;
- производить автоматическое начальное заполнение документов на основе ранее введенных данных;
- вести учет взаиморасчетов с покупателями и поставщиками, детализировать взаиморасчеты по отдельным договорам;
- формировать необходимые первичные документы;
- оформлять счета-фактуры, автоматически строить книгу продаж и книгу покупок, вести количественный учет в разрезе номеров ГТД;
- выполнять резервирование товаров и контроль оплаты;
- вести учет денежных средств на расчетных счетах и в кассе;
- вести учет товарных кредитов и контроль их погашения;
- вести учет переданных на реализацию товаров, их возврат и оплату;
Основное назначение средств работы с распределенными информационными базами - организация единой системы автоматизированного учета на предприятиях, имеющих территориально удаленные объекты: филиалы, склады, магазины, пункты приема заказов и иные подобные подразделения, не связанные локальной сетью:
- ведение неограниченного количества автономно работающих информационных баз;
- полная или выборочная синхронизация данных;
- настройка состава синхронизируемых данных;
- произвольный порядок и способ передачи изменений;
Программа 1С Торговля+Склад представлена на рисунке 1.4.
Рисунок 1.3 1С Торговля+Склад
Программа «Триумф 2007» предназначена для оперативного учета товара и денег. Можно вести учет на нескольких складах, магазинах или торговых точках, контролировать долги, остатки товара, вести учет продаж и поступления товара, расход денег и поступление денег/2/.
Всегда можно узнать объем продаж для товара, группы товаров за любой период времени.
Кроме текущих остатков товара, вы можете узнать какие были остатки товара на определенную дату.
С помощью программы "Триумф-2007" вы напечатаете счет, счет-фактуру, накладную, прайс-лист и многие другие документы/2/. Программа «Триумф 2007» изображена на рисунке 1.4.
Рисунок 1.4 Программа «Триумф 2007»
Представленные программные системы имеют такие недостатки, как сложный интерфейс, высокая стоимость, являются комплексным прикладным решением, охватывающим практически все основные контуры управления и учета на предприятии, полностью не удовлетворяет условиям предметной области и половина функций вообще не используется, т.е. придется нанимать программиста, а это еще дополнительные расходы. Таким образом, было принято решение о разработке нового программного продукта.
1.3 Выбор математического аппарата
Для прогноза объема продажи товара, был выбран метод корреляционно-регрессионного анализа.
Рассмотрим более подробно математический аппарат, используемый при данном виде анализа статистических данных.
Регрессионный анализ -- это статистический метод исследования зависимости случайной величины -отклик от переменной () или переменных () - предикторы; рассматриваются в регрессионном анализе как неслучайные величины, независимо от истинного закона их распределения. В выходе регрессионного анализа при помощи выбранного метода: строится математическая модель, описывающая форму связи переменных - уравнение регрессии. Как правило, регрессионному анализу предшествует анализ корреляционной зависимости переменных, который позволяет установить наличие связи между анализируемыми переменными, оценить ее тесноту и определить направление (прямая или обратная связь
В ходе множественного корреляционного анализа рассчитываются следующие характеристики:
- парные коэффициенты корреляции - оценки тесноты линейной корреляционной связи между всеми парами анализируемых признаков с учетом их взаимного влияния и взаимодействия. Совокупность парных коэффициентов корреляции, относящихся ко всем исследуемым признакам, может быть представлена в виде корреляционной матрицы R, которая рассчитывается по формуле:
, (1.1)
где - матрица стандартизованных значений исходных переменных. Ее элементы рассчитываются по формуле
. (1.2)
На главной диагонали матрицы R стоят дисперсии стандартизованных переменных
В множественном регрессионном анализе исследуется связь между несколькими независимыми переменными (предикторами) и результативным признаком (откликом) :
.
Обычно предполагается, что случайная величина () имеет нормальный закон распределения с условным математическим ожиданием и постоянной, не зависящей от аргументов дисперсией . В анализе чаще всего используются уравнения регрессии линейного вида
. (1.3)
Коэффициенты регрессии показывают, на какую величину в среднем изменяется результативный признак , если независимая переменная , изменяется на единицу ее измерения.
В матричной форме регрессионная модель имеет вид , где - случайный вектор-столбец размерности () наблюдаемых значений результативного признака (); X - матрица размерности () наблюдаемых значений аргументов. Элемент матрицы рассматривается как неслучайная величина (;;); А - вектор-столбец размерности () неизвестных параметров, подлежащих оценке в ходе регрессионного анализа (вектор коэффициентов регрессии); - случайный вектор-столбец размерности () - вектор остатков, которые являются независимыми нормально распределенными случайными величинами с нулевым математическим ожиданием () и неизвестной дисперсией .
Для расчета вектора оценок коэффициентов регрессии по методу наименьших квадратов используется формула , где
;;; (1.4)
- транспонированная матрица X; - матрица, обратная матрице .
После того как рассчитано само уравнение регрессии и перечисленные выше характеристики корреляционных связей, необходимо убедиться в адекватности полученных результатов/3/.
Значимость уравнения регрессии в целом, т.е. нулевая гипотеза , проверяется по F-критерию Фишера. Его наблюдаемое значение определяется по формуле:
, (1.5)
где ,
По таблице распределения значений F-критерия Фишера, при заданных , , ,находят . Гипотеза отклоняется с вероятностью , если . Из этого следует, что уравнение является значимым, т.е. хотя бы один из коэффициентов регрессии существенно отличен от нуля.
Для проверки значимости отдельных коэффициентов регрессии также используется F-критерий Фишера, где вычисляем для каждого и коэффициентов регрессии по формуле
.
Если >, то коэффициент регрессии значимо отличается от нуля.
1.4 Постановка задачи дипломной работы
Настоящее техническое задание распространяется на разработку программной системы по учету и анализу товарооборота на предприятии ИП ТД «Скарлет».
В настоящее время существует много программ, которые решают данные задачи, но данные программные средства являются коммерческими и стоят очень дорого к тому же в них есть много других функции, которые нам не нужны.
Реализовать выше перечисленные задачи можно, опираясь на современные технологии, которые обеспечивают наилучший результат. Разрабатываемое программное средство позволит облегчить труд сотрудников отдела сбыта.
Основание для разработки
Система разрабатывается на основании приказа №513 - С от 23.03.2009г. на дипломное проектирование по специальности 230105.65 ПОВТАС.
Назначение
Основное назначение программы является помощь сотруднику отдела сбыта - оператору. Программная система позволит:
- хранить данные;
- снизить временные затраты и трудоемкость осуществления обработки данных;
- облегчить внесение, хранение и выборку данных;
- оперативно генерировать отчёты.
Требование к программе или программному изделию
Программа должна обеспечивать выполнение следующих функций:
- ввод, новой информации в базу данных (БД): «Тип улицы», «Улица», «Тип телефона», «Телефон», «Единица измерения», «Вид товара», «Товар», «Контрак о работе».
- изменение или удаление информации в БД;
- просмотр информации из БД;
- вывод информации по запросам;
- прогнозирование объема продажи определенного товара на определенный месяц.
Исходные данные
- информация о сотрудниках;
- информация о товаре;
- информация о поступлении товара;
- информация о предприятии.
- информация о поставщиках;
- информация о клиентах;
Требования к надежности
- предусмотреть контроль вводимой информации;
- предусмотреть блокировку не корректных действий пользователя при работе системы;
- обеспечить целостность информации, хранящейся в базе данных;
Требования к составу и параметрам технических средств
Система должна работать на IBM/PC совместимом компьютере.
Минимальная конфигурация:
- процессор не ниже Pentium 166;
- оперативная память - 32 Мб;
- свободное место на диске - 70 Мб.
Требования к информационной и программной совместимости
Система должна работать под системой Windows9X/ME/2000/XP.
Требование к программной документации
Разрабатываемые программные модули должны быть само документированы, т.е. тексты программ должны содержать все необходимые комментарии.
В состав сопровождающей документации должны входить:
- пояснительная записка, содержащая описание разработки
- руководство пользователя.
- руководство программиста
Выводы
1 В результате анализа предприятия были выявлены информационные потоки организации, подлежащие автоматизации с целью облегчения труда оператору (работник отдела сбыта).
2 Анализ аналогов программных средств показал необходимость разработки нового программного продукта.
3 Исследование методов статистического анализа позволяет обосновать корреляционно - регрессионный анализ, как наиболее подходящий для решения данной задачи, так как требуется спрогнозировать объем продажи определенного товара на заданную дату.
4 Проанализировав предметную область, были сформированы цель и требования к программной системе.
2. Разработка программной системы
2.1 Обоснование выбора инструментальных средств разработки
Рассмотрим в качестве возможных СУБД (Система управления базы данных) следующие:
- Microsoft Access 2003;
- InterBase 7.5;
- MySQL.5.0.18.
Сравнительная характеристика этих СУБД приведена в таблице 2.1.
Таблица 2.1 Сравнительные характеристики СУБД
Название |
MySQL |
Access |
Inter Base |
|
1 |
2 |
3 |
4 |
|
1. Название, версия, фирма производитель, поддерживаемые ОС |
MySQL 5.0.18 T.c.X. DataConsaltAB |
Access 2003, Microsoft Windows |
InterBase 7.5 Borland/Inprise Windows и Unix |
|
2. Требования к аппаратному обеспечению |
Unix-платформa, а также под управлением Windows 9x, Windows NT и OS/2. Для Windows 9x и Windows NT |
Intel Pentium 133, ОЗУ 16 Мб, Windows 95 |
Intel Pentium 486, ОЗУ 16 Мб, Windows 95, |
|
3. Поддерживаемая модель данных |
Реляционная |
Реляционная |
Реляционная |
|
4. Формат файла (файлов) БД |
*.myd |
*.mdb |
*.gdb |
|
5. Поддерживаемые объекты БД |
Таблицы, последовательности, индексы |
Таблицы, последователь-ности, индексы |
Домены, хранимые процедуры и триггеры, индексы, последовательности |
|
6. Технология создания БД и объектов БД |
Визуально, с использованием SQL-скриптов |
Визуально, с использованием SQL-скриптов |
С использованием SQL-скриптов |
|
7.Возможность создания локальной БД |
Да |
Да |
Да |
|
8. Поддержка сервера БД |
Клиент-сервер, файл-сервер |
Клиент-сервер, файл-сервер |
Клиент-сервер, файл-сервер |
|
9. Наличие встроенного языка для разработки приложений |
PHP |
Visual Basic |
нет |
|
10. Средства поддержки ограничения целостности БД |
Первичный и внешние ключи, индексы |
Первичный и внешние ключи, индексы |
Первичный и внешние ключи, индексы |
|
11.Поддержка стандарта SQL |
да |
да |
да |
|
12. Наличие средств передачи данных в формат MS Exсell и MS Word |
да |
да |
нет |
|
Название |
MySQL 5.0.22 |
Access |
InterBase |
|
13. Наличие средств для получения отчётов |
да |
да |
да |
|
Название |
MySQL 5.0.22 |
Access |
Inter Base |
|
14. Возможность реализации прав доступа для отдельных пользователей (роли и привилегии) |
Получение или отказ в доступе ко всей БД |
Получение или отказ в доступе ко всей БД |
Возможность доступа отдельного пользователя к отдельным таблицам |
|
15. Наличие средств для создания резервной копии БД и восстановления БД |
да |
да |
да |
|
16. Простота/сложность работы СУБД |
Прост в работе, наглядно. |
Прост в работе, наглядно. |
Работа производится по средствам SQL-запросов, трудно для начинающих. |
По результатам сравнения трех СУБД наилучшей для разработки, является InterBase. InterBase представляет собой полнофункциональный SQL-сервер. Одной из особенностей InterBase, является многоверсионная архитектура. Это означает, что когда пользователь редактирует запись, он редактирует ее копию - так называемую версию. При этом транзакции на чтение не блокируют транзакции записи и обновления и наоборот. Ядро сервера отслеживает версии и приводит базу к актуальному виду/4/. Это позволяет существенно повысить производительность. Кроме того, это снижает требования к ресурсам, поскольку версии хранят только изменения данных. Все настольные базы данных позволяют осуществлять передвижения от одной записи к другой. В реляционных базах для достижения этого необходимо использовать особые средства. Но из всякого правила существуют исключения. Таким исключением является InterBase. Ядро этого сервера позволяет осуществлять навигационный, позаписный (построчный) доступ к данным/5/.
Таблица 2.2 - Сравнительные характеристики средств разработки ПО
Характеристика |
Visual Studio .Net |
C++ Builder |
|
1 |
2 |
3 |
|
Версия |
Visual Studio .Net 2005 |
C++ Builder 6.0 |
|
Фирма производитель |
Microsoft |
Borland |
|
Зависимость от платформы |
Windows 2000, XP, Vista |
Microsoft Windows 2000, Windows 95, 98 |
|
Подход к разработке программного обеспечения |
Объектно-ориентированный |
Объектно-ориентированный |
|
Механизмы доступа к БД; |
ADO, DAO |
ADO, BDE, dbExpress, IntegererBase |
|
Утилиты для работы с БД |
Server Explorer |
SQL-Explorer, SQL-Monitor, Database Desktop |
|
Наличие компонент для работы с БД |
Connection, DataSet, DataAdapter |
Connection, Table, Query, Database |
|
Наличие компонент построения отчетов и диаграмм |
Crystal Reports |
Quick Report |
|
Поддержка Windows-подобного (оконного) интерфейса |
Да |
Да |
|
Средства поддержки транзакций |
поддерживает |
поддерживает |
|
Простота/ сложность работы с инструментальным средством; |
Просто |
Просто |
|
Возможность создания запускаемого файла |
Да |
Да |
В качестве используемого программного средства для решения задачи проектирования был выбран язык С++Builder 6. C++Builder, как следует из названия, построен на языке C++, который наиболее распространен в крупных фирмах, занимающихся разработкой математического обеспечения профессионального уровня.
C++ Builder предоставляет свою мощность и широкие возможности языка C++ всему семейству систем объектно-ориентированного программирования. C++ Builder может быть использован везде, где требуется дополнить существующие приложения расширенным промышленным стандартом языка C++, повысить быстродействие и придать пользовательскому интерфейсу профессиональный облик/6/.
2.2 Разработка архитектуры ПС
При написании подобных систем обычно используется метод нисходящего проектирования, то есть составляется сценарий работы программы, затем общая задача разбивается на подзадачи, выделяются объекты, для каждого из них определяются свойства и методы их обработки, то есть процедуры, реализующие эти свойства. Затем объекты, обладающие схожими свойствами, объединяются в группы, определяется иерархия объектов /7/.
Метод нисходящего проектирования призван сократить временные затраты на написание алгоритма и последующую отладку программы. Основная идея метода нисходящего проектирования - не программировать сразу. Пошаговая детализация (программирование "сверху вниз") автоматически заставляет формировать понятную структуру программы. После завершение трансляции (также автоматически) формируется первичный набор тестов; каждый тест отлаживает конкретную подзадачу. Аккуратное проектирование обычно приводит к тому, что программист хорошо представляет себе работу каждой конкретной подзадачи, ее входные и выходные данные, и потому в состоянии протестировать именно ее. По окончании тестирования конкретной подзадачи, можно тестировать другие подзадачи независимо. Эта независимость дает также возможность тестировать подзадачи по ходу реализации программы, генерируя после трансляции уже первично отлаженный код.
Программная система состоит из проекта Project.dpr в который входит 7 модулей: Unit1, Unit2, Unit3, Unit4, Unit5, Unit6, Unit7 (расширение *.cpp).
Модули, реализующий основные функции, вызываются, если пароль введен верно. Вспомогательные модули используются в процессе работы основного модуля.
Иерархическая соподчиненность модулей программного комплекса представлена на рисунке 2.1
Рисунок 2.1 Иерархическая соподчиненность модулей
Таблица 2.3 Спецификация модулей ПС
Название модуля |
Назначение |
Входные данные |
Выходные данные |
|
1 |
2 |
4 |
5 |
|
Unit1 |
Форма аутентификации пользователя |
Имя пользователя и пароль |
Основная форма |
|
Unit2 |
Основная форма, реализованная компонентом Page Control |
Имя пользователя и пароль. Запрос |
Соединение с базой данных |
|
Unit3 |
Формирование отчета прайс лист в виде QReport |
Выбор пользователем действия |
Сформированный отчет |
|
Unit4 |
Модуль, содержащий таблицу Фишера |
Выбор пользователем действия |
Результат текущего действия - просмотр таблицы Фишера |
|
Unit5 |
Формирование отчета прайс лист по типу товара в виде QReport |
Выбор пользователем действия |
Сформированный отчет |
|
Unit6 |
Формирование отчета договор в виде QReport |
Выбор пользователем действия |
Сформированный отчет |
|
Unit7 |
Модуль, содержащий информацию о программе |
Выбор пользователем действия |
Информация о программе и разработчике |
2.3 Реализация функционального назначения
Функциональная схема программного продукта строится с целью однозначного понимания всех функций, выполняемых данной АИС. В большинстве случаев функциональная спецификация формулируется на естественном языке при помощи специальных объектов и утверждений, конкретно описывающих функции программной системы/7/.
Исходя из требований, предъявляемых к программной системе, выделим основные функции, которые реализованы в системе.
Вход в систему - при запуске программы производится запрос имени и пароля пользователя. При успешном вводе пароля пользователь подключается к базе данных и получает возможность работать с АИС. При неудаче - выдаётся сообщение об ошибке.
Сведения о товарах - работа с учетными данными таблиц: «Документ о расходах», «Документ о поступлении», «Позиция документа о расходах», «Позиция документа о поступлении».
Ведение справочных данных - работа со справочной информацией. Справочники, которые используется в АИС: «Тип улицы», «Улица», «Тип телефона», «Телефон», «Единица измерения», «Вид товара», «Товар», «Контракт о работе».
Прогнозирование объема продажи товара методом корреляционно - регрессионного анализа:
а) Х1 - объем поступления товара;
б) Х2 - средняя цена товара;
в) Y - количество проданного товара.
Формирование отчетов - представляет собой формирование, просмотр и печать отчётов.
Справочная информация - дополнительные сведения о работе с АИС.
Разработанная функциональная схема представлена на рисунке 2.2.
Рисунок 2.2 Функциональная схема программной системы
2.4 Проектирование базы данных
2.4.1 Иерархия функций
Иерархия функций, реализуемая системой, представлена в виде таблицы 2.4 иерархии функций, выполнение которых должна обеспечивать проектируемая ПС.
Таблица 2.4 Иерархия функций
Ведение справочных данных |
Тип улицы |
Добавление/Обновление |
Ф1 |
|
Просмотр |
Ф2 |
|||
Улица |
Добавление/Обновление |
Ф3 |
||
Просмотр |
Ф4 |
|||
Тип населенного пункта |
Добавление/Обновление |
Ф5 |
||
Просмотр |
Ф6 |
|||
Населенный пункт |
Добавление/Обновление |
Ф7 |
||
Просмотр |
Ф8 |
|||
Адрес |
Добавление/Обновление |
Ф9 |
||
Просмотр |
Ф10 |
|||
Тип телефона |
Добавление/Обновление |
Ф11 |
||
Просмотр |
Ф12 |
|||
Телефон |
Добавление/Обновление |
Ф13 |
||
Просмотр |
Ф14 |
|||
Единица измерения |
Добавление/Обновление |
Ф15 |
||
Просмотр |
Ф16 |
|||
Должность |
Добавление/Обновление |
Ф17 |
||
Просмотр |
Ф18 |
|||
Пол физического лица |
Добавление/Обновление |
Ф19 |
||
Просмотр |
Ф20 |
|||
Физическое лицо |
Добавление/Обновление |
Ф21 |
||
Просмотр |
Ф22 |
|||
Группа товара |
Добавление/Обновление |
Ф23 |
||
Просмотр |
Ф24 |
|||
Товар |
Добавление/Обновление |
Ф25 |
||
Просмотр |
Ф26 |
|||
Контракт о работе |
Добавление/Обновление |
Ф27 |
||
Просмотр |
Ф28 |
|||
Тип структурной единицы |
Добавление/Обновление |
Ф29 |
||
Просмотр |
Ф30 |
|||
Клиенты |
Структурная единица\ Юридическое лицо |
Добавление/Обновление |
Ф31 |
|
Просмотр |
Ф32 |
|||
Реализация |
Поступление товара |
Добавление/Обновление |
Ф33 |
|
Просмотр |
Ф34 |
|||
Добавление/Обновление |
Ф35 |
|||
Продажа товара |
Просмотр |
Ф36 |
||
Печать |
Ф37 |
|||
Формирование отчетов |
Перечень товара по выбору из списка |
Формирование |
Ф38 |
|
Просмотр |
Ф39 |
|||
Прайс лист |
Формирование |
Ф40 |
||
Просмотр |
Ф41 |
|||
Формирование договора |
Формирование |
Ф42 |
||
Просмотр |
Ф43 |
|||
Корреляционно-регрессионный анализ |
Прогнозирование объема продажи определенного товара |
Выборка данных |
Ф44 |
|
Просмотр |
Ф45 |
2.4.2 Пользователи ПС. Уровни доступа пользователей
Для решаемой задачи достаточным является наличие четырех пользователей.
1 Администратор базы данных - имеет полные права на все операции с данными БД.
2 Прикладной программист - может производить добавление, изменение и просмотр всех таблиц.
3 Директор предприятия - имеет доступ на чтение всех таблиц.
4 Оператор - добавляет и изменяет таблицы: группа товара, товар, документ о расходах, позиция документа о расходах, документ о поступлении товара, позиция документа о поступлении товара, продажа, телефон, структурная единица\Юридическое лицо.
Уровни доступа пользователей представлены в таблице 2.5
Таблица 2.5 Уровни доступа пользователей
Пользователи |
Администратор БД |
Прикладной программист |
Оператор |
Директор |
|
Классы объектов и их свойства |
|||||
1 |
2 |
3 |
4 |
5 |
|
ТИП УЛИЦЫ |
|||||
Код |
I, U, D, R |
I, U, R |
R |
R |
|
Название |
I, U, D, R |
I, U, R |
R |
R |
|
Краткое название |
I, U, D, R |
I, U, R |
R |
R |
|
УЛИЦА |
|||||
Код |
I, U,D, R |
I, U, R |
R |
R |
|
Название |
I, U, D,R |
I, U, R |
R |
R |
|
ТИП НАСЕЛЕННОГО ПУНКТА |
|||||
Код |
I, U, D, R |
I, U, R |
R |
R |
|
Название |
I, U, D, R |
I, U, R |
R |
R |
|
Краткое название |
I, U, D, R |
I, U, R |
R |
R |
|
НАСЕЛЕННЫЙ ПУНКТ |
|||||
Код |
I, U, D, R |
I, U, R |
R |
R |
|
Название |
I, U, D, R |
I, U, R |
R |
R |
|
АДРЕС |
|||||
Номер |
I, U, D, R |
I, U, R |
R |
R |
|
Дом |
I, U, D, R |
I, U, R |
R |
R |
|
Корпус |
I, U, D, R |
I, U, R |
R |
R |
|
Офис |
I, U, D, R |
I, U, R |
R |
R |
|
ДОЛЖНОСТЬ |
|||||
Код |
I, U, D, R |
I, U, R |
R |
R |
|
Название |
I, U, D, R |
I, U, R |
R |
R |
|
Краткое название |
I, U, D, R |
I, U, R |
R |
R |
|
КОНТРАКТ О РАБОТЕ |
|||||
Код |
I, U, D, R |
I, U, R |
R |
R |
|
Название |
I, U, D, R |
I, U, R |
R |
R |
|
Краткое название |
I, U, D, R |
I, U, R |
R |
R |
|
ПОЛ ФИЗИЧЕСКОГО ЛИЦА |
|||||
Код |
I, U,D, R |
I, U, R |
R |
R |
|
Название |
I, U, D,R |
I, U, R |
R |
R |
|
Краткое название |
I, U, D,R |
I, U, R |
R |
R |
|
ФИЗИЧЕСКОЕ ЛИЦО |
|||||
Номер |
I, U, D, R |
I, U, R |
R |
R |
|
Фамилия |
I, U, D, R |
I, U, R |
R |
R |
|
Имя |
I, U, D, R |
I, U, R |
R |
R |
|
Отчество |
I, U, D,R |
I, U, R |
R |
R |
|
Дата рождения |
I, U, D,R |
I, U, R |
R |
R |
|
ТИП ТЕЛЕФОНА |
|||||
Код |
I, U, D, R |
I, U, R |
R |
R |
|
Название |
I, U, D, R |
I, U, R |
R |
R |
|
Краткое название |
I, U, D,R |
I, U, R |
R |
R |
|
ТЕЛЕФОН |
|||||
Код |
I, U, D, R |
I, U, R |
I, U, R |
R |
|
Номер |
I, U, D, R |
I, U, R |
I, U, R |
R |
|
ТИП СТРУКТУРНОЙ ЕДИНИЦЫ |
|||||
Код |
I, U, D, R |
I, U, R |
R |
R |
|
Название |
I, U, D,R |
I, U, R |
R |
R |
|
Краткое название |
I, U, D,R |
I, U, R |
R |
R |
|
СТРУКТУРНАЯ ЕДИНИЦА |
|||||
Код |
I, U, D,R |
I, U, R |
I, U, R |
R |
|
Название |
I, U, D,R |
I, U, R |
I, U, R |
R |
|
Краткое название |
I, U, D,R |
I, U, R |
I, U, R |
R |
|
ДОКУМЕНТ О ПОСТУПЛЕНИИ |
|||||
Номер |
I, U, D,R |
I, U, R |
I, U, R |
R |
|
Дата |
I, U, D,R |
I, U, R |
I, U, R |
R |
|
ПОЗИЦИЯ ДОКУМЕНТА О ПОСТУПЛЕНИИ |
|||||
Номер |
I, U, D, R |
I, U, R |
I, U, R |
R |
|
Количество |
I, U, D, R |
I, U, R |
I, U, R |
R |
|
Цена за единицу |
I, U, D, R |
I, U, R |
I, U, R |
R |
|
ДОКУМЕНТ О РАСХОДАХ |
|||||
Код |
I, U,D, R |
I, U, R |
I, U, R |
R |
|
Название |
I, U, D,R |
I, U, R |
I, U, R |
R |
|
ПОЗИЦИЯ ДОКУМЕНТА О РАСХОДАХ |
|||||
Номер |
I, U, D, R |
I, U, R |
I, U, R |
R |
|
колличество |
I, U, D, R |
I, U, R |
I, U, R |
R |
|
Цена за единицу |
I, U, D, R |
I, U, R |
I, U, R |
R |
|
ГРУППА ТОВАРА |
|||||
Код |
I, U, D, R |
I, U, R |
I, U, R |
R |
|
Название |
I, U, D, R |
I, U, R |
I, U, R |
R |
|
ТОВАР |
|||||
Код |
I, U, D, R |
I, U, R |
I, U, R |
R |
|
Название |
I, U, D, R |
I, U, R |
I, U, R |
R |
|
ЕДИНИЦА ИЗМЕРЕНИЯ |
|||||
Код |
I, U, D,R |
I, U, R |
R |
R |
|
Название |
I, U, D,R |
I, U, R |
R |
R |
В таблице использованы сокращения операций, производимых с данными: R - read (чтение); I - insert (добавление); U - update (обновление) ; D - delete (удаление).
2.4.3 Формализованное описание предметной области
Формализованное описание предметной области содержит описание классов объектов (сущностей), выявленных на этапе анализа предметной области и связей (отношений) между ними. Оно необходимо для того, чтобы определить, какие данные будут в таблицах разрабатываемой БД, а также логические ограничения полей этих таблиц /7/.
В таблицах 2.6 и 2.7 приведено формализованное описание классов объектов и связей между ними.
Таблица 2.6 Классы объектов и их свойства
Класс объектов/Свойство |
Ключ (уникальный, первичный) |
Физические характеристики (тип, длина) |
Опцион. свойства |
Логические ограничения |
Процессы для значений свойств |
|
1 |
2 |
3 |
4 |
5 |
6 |
|
ТИП УЛИЦЫ |
||||||
Код |
УК, ПК |
число, 2 |
д.б |
>0 |
Г, Пр |
|
Название |
Символ, 70 |
д.б |
прописные, строчные буквы |
ВВ, ПР, ОБ |
||
Краткое название |
Символ, 20 |
м.б |
прописные, строчные буквы |
ВВ, ПР, ОБ |
||
УЛИЦА |
||||||
Код |
УК,ПК |
число, 2 |
д.б |
>0 |
Г, Пр |
|
Название |
Символ, 80 |
д.б |
прописные, строчные буквы |
ВВ, ПР, ОБ |
||
ТИП НАСЕЛЕННОГО ПУНКТА |
||||||
Код |
УК, ПК |
число, 2 |
д.б |
>0 |
Г, ПР |
|
Название |
Символ, 80 |
д.б |
прописные, строчные буквы |
ВВ, ПР, ОБ |
||
Краткое название |
Символ, 30 |
м.б |
прописные, строчные буквы |
ВВ, ПР, ОБ |
||
НАСЕЛЕННЫЙ ПУНКТ |
||||||
Код |
УК, ПК |
число, 2 |
д.б |
>0 |
Г, ПР |
|
Название |
Символ, 70 |
д.б |
прописные, строчные буквы |
ВВ, ПР, ОБ |
||
АДРЕС |
||||||
Номер |
УК, ПК |
число, 2 |
д.б |
>0 |
Г, ПР |
|
Дом |
число, 10 |
д.б |
>0 |
ВВ, ПР, ОБ |
||
Корпус |
число, 10 |
м.б |
>0 |
ВВ, ПР, ОБ |
||
Офис\Квартира |
число, 10 |
д.б |
>0 |
|||
ДОЛЖНОСТЬ |
||||||
Код |
УК, ПК |
число, 10 |
д.б |
>0 |
Г, ПР |
|
Название |
Символ, 80 |
д.б |
прописные, строчные буквы |
ВВ, ПР, ОБ |
||
Краткое название |
Символ, 30 |
д.б |
прописные, строчные буквы |
ВВ, ПР, ОБ |
||
КОНТРАКТ О РАБОТЕ |
||||||
Номер |
УК, ПК |
число, 2 |
д.б |
>0 |
Г, Пр |
|
Дата начала |
Дата |
д.б |
Дд.мм.гг.. |
ВВ, ПР, ОБ |
||
Дата окончания |
Дата |
м.б |
Дд.мм.гг. |
ВВ, ПР, ОБ |
||
ПОЛ ФИЗИЧЕСКОГО ЛИЦА |
||||||
Код |
УК,ПК |
число, 2 |
д.б |
>0 |
Г, Пр |
|
Название |
Символ, 10 |
д.б |
прописные, строчные буквы |
ВВ, ПР, ОБ |
||
Краткое название |
Символ, 4 |
м.б |
прописные, строчные буквы |
ВВ, ПР, ОБ |
||
ФИЗИЧЕСКОЕ ЛИЦО |
||||||
Номер |
УК,ПК |
число, 2 |
д.б |
>0 |
Г, Пр |
|
Фамилия |
Символ, 40 |
д.б |
прописные, строчные буквы |
ВВ, ПР, ОБ |
||
Имя |
Символ, 40 |
д.б |
прописные, строчные буквы |
ВВ, ПР, ОБ |
||
Отчество |
Символ, 40 |
д.б |
прописные, строчные буквы |
ВВ, ПР, ОБ |
||
Дата рождения |
Дата |
м.б. |
Дд.мм.гг. |
ВВ, ПР, ОБ |
||
ТИП ТЕЛЕФОНА |
||||||
Код |
УК, ПК |
число, 2 |
д.б |
>0 |
Г, ПР |
|
Название |
Символ, 40 |
д.б |
прописные, строчные буквы |
ВВ, ПР, ОБ |
||
Краткое название |
Символ, 20 |
м.б |
прописные, строчные буквы |
ВВ, ПР, ОБ |
||
ТЕЛЕФОН |
||||||
Код |
УК, ПК |
число, 2 |
д.б |
>0 |
Г, ПР |
|
Номер |
число, 10 |
м.б |
прописные, строчные буквы |
ВВ, ПР, ОБ |
||
ТИП СТРУКТУРНОЙ ЕДИНИЦЫ |
||||||
Код |
УК, ПК |
число, 2 |
д.б |
>0 |
Г, ПР |
|
Название |
Символ, 80 |
д.б |
прописные, строчные буквы |
ВВ, ПР, ОБ |
||
Краткое название |
Символ, 40 |
м.б |
прописные, строчные буквы |
ВВ, ПР, ОБ |
||
СТРУКТУРНАЯ ЕДИНИЦА\ЮР.ЛИЦО |
||||||
Код |
УК, ПК |
число, 2 |
д.б |
>0 |
Г, ПР |
|
Название |
Символ, 80 |
д.б |
прописные, строчные буквы |
ВВ, ПР, ОБ |
||
Краткое название |
Символ, 40 |
м.б. |
прописные, строчные буквы |
ВВ, ПР, ОБ |
||
ГРУППА ТОВАРА |
||||||
Код |
УК, ПК |
число, 10 |
д.б |
>0 |
Г, ПР |
|
Название |
Символ, 70 |
д.б |
Дд.мм.гг. |
ВВ, ПР, ОБ |
||
ТОВАР |
||||||
Код |
УК, ПК |
число, 10 |
д.б |
>0 |
Г, Пр |
|
Название |
Символ, 80 |
д.б |
прописные, строчные буквы |
ВВ, ПР, ОБ |
||
ДОКУМЕНТ О ПОСТУПЛЕНИИ ТОВАРА |
||||||
Номер |
УК,ПК |
число, 2 |
д.б |
>0 |
Г, Пр |
|
Дата |
Дата |
д.б |
дд.мм.гг |
ВВ, ПР, ОБ |
||
ПОЗИЦИЯ ДОКУМЕНТА О ПОСТУПЛЕНИИ ТОВАРА |
||||||
Номер |
УК, ПК |
число, 2 |
д.б |
>0 |
Г, ПР |
|
Количество |
число, 10 |
д.б |
>0 |
ВВ, ПР, ОБ |
||
Цена за единицу |
число, 10 |
д.б |
>0 |
ВВ, ПР, ОБ |
||
ЕДИНИЦА ИЗМЕРЕНИЯ |
||||||
Код |
УК, ПК |
число, 2 |
д.б |
>0 |
Г, ПР |
|
Единица измерения |
Символ, 20 |
д.б |
прописные, строчные буквы |
ВВ, ПР, ОБ |
||
Кратко |
Символ, 10 |
м.б |
прописные, строчные буквы |
ВВ, ПР, ОБ |
||
ДОКУМЕНТ О РАСХОДАХ |
||||||
Номер |
УК, ПК |
число, 2 |
д.б |
>0 |
Г, ПР |
|
Дата |
Дата |
д.б |
Дд.мм.гг. |
ВВ, ПР, ОБ |
||
ПОЗИЦИЯ ДОКУМЕНТА О РАСХОДАХ |
||||||
Номер |
УК, ПК |
число, 2 |
д.б |
>0 |
Г, ПР |
|
Количество |
число, 10 |
д.б |
прописные, строчные буквы |
ВВ, ПР, ОБ |
||
Цена за единицу |
Число, 10 |
д.б |
прописные, строчные буквы |
ВВ, ПР, ОБ |
В данной таблице используются следующие сокращения: УК - уникальный идентификатор, ПК - первичный ключ, д.б - должно быть, м.б - может быть, Г - генерация, ПР - просмотр, ВВ. - ввод, ОБ. - обновление.
Таблица 2.7 Связи между классами
Классы Объектов |
Опциональность |
Имя связи |
Тип связи |
|||||
Главная |
Подчиненная |
Главная |
Подч. |
Главная |
Подч. |
Главная |
Подч |
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
|
Тип улицы |
Улица |
м.б. |
д.б. |
соотв. |
относ. |
1 |
М |
|
Тип населенного пункта |
Населенный пункт |
м.б. |
д.б. |
соотв. |
относ. |
1 |
М |
|
Улица |
Адрес |
м.б. |
д.б. |
соотв. |
относ. |
1 |
М |
|
Населенный пункт |
Адрес |
м.б. |
д.б. |
соотв. |
относ. |
1 |
М |
|
Тип структурной единицы |
Структурная единица\Ю.Л. |
м.б. |
д.б. |
соотв. |
относ. |
1 |
М |
|
Структурная единица\Ю.Л. |
Документ о поступлении |
м.б. |
д.б. |
соотв. |
относ. |
1 |
М |
|
Структурная единица\Ю.Л. |
Документ о расходах |
м.б. |
д.б. |
соотв. |
относ. |
1 |
М |
|
Структурная единица\Ю.Л. |
Телефон |
м.б. |
д.б. |
соотв. |
относ. |
1 |
М |
|
Структурная единица\Ю.Л. |
Адрес |
м.б. |
д.б. |
соотв. |
относ. |
1 |
1 |
|
Тип телефона |
Телефон |
м.б. |
д.б. |
соотв. |
относ. |
1 |
М |
|
Пол физического лица |
Физическое лицо |
м.б. |
д.б. |
соотв. |
относ. |
1 |
М |
|
Контракт о работе |
Физическое лицо |
м.б. |
д.б. |
соотв. |
относ. |
1 |
М |
|
Физическое лицо |
Документ о расходах |
м.б. |
д.б. |
соотв. |
относ. |
1 |
М |
|
Физическое лицо |
Телефон |
м.б. |
д.б. |
соотв. |
относ. |
1 |
М |
|
Документ о поступлении |
Позиция документа о поступлении |
м.б. |
д.б. |
соотв. |
относ. |
1 |
М |
|
Документ о расходах |
Позиция документа о расходах |
м.б. |
д.б. |
соотв. |
относ. |
1 |
М |
|
Группа товара |
Товар |
м.б. |
д.б. |
соотв. |
относ. |
1 |
М |
|
Товар |
Позиция документа о поступлении |
м.б. |
д.б. |
соотв. |
относ. |
1 |
М |
|
Товар |
Позиция документа о расходах |
м.б. |
д.б. |
соотв. |
относ. |
1 |
М |
|
Единица измерения |
Позиция документа о расходах |
м.б. |
д.б. |
соотв. |
относ. |
1 |
М |
|
Единица измерения |
Позиция документа о поступлении |
м.б. |
д.б. |
соотв. |
относ. |
1 |
М |
|
Должность |
Контракт о работе |
м.б. |
д.б. |
соотв. |
относ. |
1 |
М |
В таблице использованы сокращения: м.б. - может быть; д.б. - должно быть, подч.-подчиненная, М-многим, 1-один;
2.4.5 Инфологическая модель предметной области
Инфологическая модель создана по методологии Ричарда Баркера. Далее приводится ее краткое описание.
Сущность изображается в виде блока с закругленными концами, внутри которого заглавными буквами записывается имя сущности, а строчными - ее атрибуты. Две сущности могут быть связаны между собой/7/.
Размещено на http://www.allbest.ru/
Рисунок 2.3 Графическое представление объектов и связей
Эти связи можно "читать", используя специальный синтаксис. Связь, изображаемая сплошной линией, читается как "должен" (обязательная связь), а пунктирной - как "может" (необязательная связь).
Значения некоторых атрибутов могут в какие-то моменты просто отсутствовать или же быть недоступны. В таких случаях перед именем атрибута на схеме ставится буква "o", что говорит о том, что атрибут - необязательный (optional),а атрибуты, значения которых должны быть известны всегда, имеют перед своим именем значок "*". Сущность может иметь несколько альтернативных способов уникальной идентификации: первый метод состоит в обозначении тех атрибутов, которые составляют уникальный идентификатор, символом "#" и в перечеркивании входящих в уникальный идентификатор связей.
Элементарные правила построения схем направлены на облегчение чтения схем, их восприятия пользователями, а также повышение их качества и точности.
Нужно постараться довести схему до такой степени, чтобы блоки на схемах выстраивались в ряд, а линии связей были по возможности прямые, горизонтальные или вертикальные. Пересечения линий были сведены к минимуму. Если же пересечения не удается избежать, надо, чтобы линии пересекались под углом 30-60 градусов, облегчая тем самым зрительное восприятие.
Надо стараться, чтобы разветвляющийся конец (воронья лапка) связи находился слева или в верхней части линии связи. Как оказалось, это повышает точность модели, ибо модель при этом читается от более часто встречающихся сущностей к более редким. (Большинство людей просматривает схемы слева направо и сверху вниз, так что такое расположение информации совпадает с естественным путем ее восприятия.
Размеры и форма блоков не имеют особого значения. Блоки могут быть вытянутыми, увеличенными или сжатыми, если это необходимо в целях обеспечения большей наглядности представления/8/.
Таблица 2.8 Перекрестная проверка иерархии функций и модели предметной области
ФУНКЦИИ |
ТИП УЛИЦЫ. |
УЛИЦА |
ТИП НАСЕЛЕННОГО ПУНКТА |
НАСЕЛЕННЫЙ ПУНКТ |
АДРЕС |
ТИП ТЕЛЕФОНА |
ТЕЛЕФОН |
ЕДИНИЦА ИЗМЕРЕНИЯ |
ДОЛЖНОСТЬ |
ПОЛ ФИЗИЧЕСКОГО ЛИЦА |
ФИЗИЧЕСКОЕ ЛИЦО |
ГРУППА ТОВАРА |
ТОВАР |
КОНТРАКТ О РАБОТЕ |
ТИП СТРУКТУРНОЙ ЕДИНИЦЫ |
СТРУКТУРНАЯ ЕДИНИЦА\Ю.Л |
.ДОКУМНТ О ПОСТУПЛЕНИИ |
ПОЗИЦИЯ ДОКУМЕНТА О ПОСТУПЛЕНИИ |
ДОКУМЕНТ О РАСХОДАХ |
ПОЗИЦИЯ ДОКУМЕНТА О РАСХОДАХ |
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
|
Ф1 |
I,U |
||||||||||||||||||||
Ф2 |
R |
||||||||||||||||||||
Ф3 |
I,U |
||||||||||||||||||||
Ф4 |
R |
||||||||||||||||||||
Ф5 |
I,U |
||||||||||||||||||||
Ф6 |
R |
||||||||||||||||||||
Ф7 |
I,U |
||||||||||||||||||||
Ф8 |
R |
||||||||||||||||||||
Ф9 |
I,U |
||||||||||||||||||||
Ф10 |
R |
||||||||||||||||||||
Ф11 |
I,U |
||||||||||||||||||||
Ф12 |
R |
||||||||||||||||||||
Ф13 |
I,U |
||||||||||||||||||||
Ф14 |
R |
||||||||||||||||||||
Ф15 |
I,U |
||||||||||||||||||||
Ф16 |
R |
||||||||||||||||||||
Ф17 |
I,U |
||||||||||||||||||||
Ф18 |
R |
||||||||||||||||||||
Ф19 |
I,U |
||||||||||||||||||||
Ф20 |
R |
||||||||||||||||||||
Ф21 |
I,U |
||||||||||||||||||||
Ф22 |
R |
||||||||||||||||||||
Ф23 |
I,U |
||||||||||||||||||||
Ф24 |
R |
||||||||||||||||||||
Ф25 |
I,U |
||||||||||||||||||||
Ф26 |
R |
||||||||||||||||||||
Ф27 |
I,U |
||||||||||||||||||||
Ф28 |
R |
||||||||||||||||||||
Ф29 |
I,U |
||||||||||||||||||||
Ф30 |
R |
||||||||||||||||||||
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
|
Ф31 |
I,U |
||||||||||||||||||||
Ф32 |
R |
||||||||||||||||||||
Ф33 |
I,U |
I,U |
|||||||||||||||||||
Ф34 |
R |
R |
|||||||||||||||||||
Ф35 |
I,U |
I,U |
|||||||||||||||||||
Ф36 |
R |
R |
|||||||||||||||||||
Ф37 |
R |
R |
В таблице использованы сокращения: I - операция добавления; U - операция обновления, R - операция чтения (выборки), Ф - конечная функция «ветки» иерархии функций.
Анализируя результат перекрестной проверки надо отметить, что в таблице нет пустых строк и столбцов, значит полученная инфологическая модель предметной области достаточна и не избыточна.
2.4.6 Даталогическая модель БД
Основная задача даталогической модели - получение структурных данных описанных на языке конкретной математической модели, ориентированной на выбранную СУБД.
Модель данных рассматривается как инструмент для получения структурных данных и состоит из трех компонентов:
- правила организации структур данных;
- правила манипулирования данными;
- ограничения модели;
Процесс преобразования инфологической модели предметной области в даталогическую модель достаточно формализован, рассмотрим алгоритмы применявшиеся для этих целей в данном проекте
Простые объекты - это объекты, информация о которых первой появляется в предметной области, они не имеют рекурсивных связей и не входят в супертипы и арки. Связи на стороне этих объектов называются родительскими или главными. Именем реляционного отношения становится имя класса объектов, каждое свойство класса объектов становится атрибутом отношения. Первичный ключ выделяется, уникальные потенциальные ключи помечаются. Все свойства входящие в состав первичного ключа должны быть обязательными.
Связь «один ко многим» реализуется копированием первичного ключа из реляционного отношения на стороне «один» в реляционное отношение на стороне «много», т.е. из главного отношения в подчиненное, новому атрибуту присваивается уникальное в пределах отношения имя. В имени хорошо использовать имя таблицы откуда осуществляется копия, этот атрибут помечается как внешний ключ. Если на ER - диаграмме опциональность свойств на стороне много была обязательной, то опциональность внешнего ключа также обязательна, либо наоборот.
Преобразование связи «один к одному» в ER - диаграмме может иметь разную опциональность, от этого зависит ее отображение в схеме БД. Если связь «один к одному» обязательна с одной сторон, то поле с внешним ключом добавляется в отношение на обязательной стороне и это отношение становится подчиненным. Опциональность внешнего ключа будет обязательной, если связь не обязательна или обязательна в обоих направлениях. Необходимо выбрать в какую таблицу будет помещен внешний ключ. Если строка в одном отношении создается обычно раньше, чем в другом, то это отношение назначается главным, а внешний ключ создается в подчиненном. Если в одном отношении будет меньше строк чем в другом, т.е его размер будет изменятся менее динамично, тогда это отношение назначается главным и внешний ключ создается в подчиненном. Внешний ключ отражающий такую связь, должен быть уникальным./7/.
2.4.7 Анализ схем отношений на соответствие 3НФ
Проведем анализ полученной схемы отношений на соответствие 3НФ и НФБК:
- полученная схема отношений соответствуют 1НФ так как все атрибуты атомарны;
- первичный ключ во всех отношениях не составной, значит отсутствуют частичные функциональные зависимости, поэтому схема отношений находится во 2НФ;
- отсутствуют транзитивные зависимости между первичным ключом и атрибутами, значит схема отношений находится в 3НФ;
- в полученной схеме отношений каждый детерминант является потенциальным ключом, значит схема отношений соответствует НФБК/6/.
2.4.8 Описание проектируемых объектов БД
СУБД InterBase поддерживает следующие объекты:
- домены;
- таблицы;
- индексы;
- представления;
- процедуры;
- функции;
- генераторы;
- триггеры;
- исключения;
- роли;
- пользователи.
В проектируемой СУБД будут использованы следующие объекты
- таблицы;
- генераторы;
- триггеры;
- роли ;
- пользователи.
2.4.9 Язык описания данных выбранной СУБД
- Текстовый (число) - обозначение текстового формата поля. Число в скобках это максимальное количество букв, которое можно будет ввести в это поле;
- дата/время - в данном поле можно вводить только данные в формате даты или времени;
- числовой, длинное целое - в поле вводятся только цифры. Их диапазон ограничивается типом числа (длинное целое).
2.4.10 Техническое описание объектов БД
Техническое описание представлено в таблицах 2.14 - 2.33
Таблица 2.14 Реляционная таблица «DOLZHNOST»
Имя поля |
Kod |
nazv |
Kr_nazv |
|
Ключ |
Primary Key |
|||
Тип, длина |
Integer |
Varchar(70) |
Varchar(30) |
|
Обязательность Значения |
Not Null |
|||
Логическое ограничение на поле |
Check (value>0 ) |
|||
Примеры данных |
1 |
программист |
прогр. |
Таблица 2.15 Реляционная таблица «KONTR_O_RAB»
Имя поля |
Nomer |
Data_n |
Data_ok |
Kod_ur_l |
Kod_fiz_l |
Kod_dol |
|
Ключ |
Primary Key |
Foreign key |
Foreign key |
Foreign key |
|||
Тип, длина |
Integer |
data |
data |
Integer |
Integer |
Integer |
|
Обязательность Значения |
Not Null |
Not Null |
|||||
Логическое ограничение на поле |
Check (value>0 ) |
||||||
Примеры данных |
1 |
12.09.05 |
12.07.09 |
12 |
23 |
1 |
Таблица 2.16 Реляционная таблица «POL_FIZ_L»
Имя поля |
Kod |
nazv |
Kr_nazv |
|
Ключ |
Primary Key |
|||
Тип, длина |
Integer |
Varchar(10) |
Varchar(4) |
|
Обязательность Значения |
Not Null |
|||
Логическое ограничение на поле |
Check (value>0 ) |
|||
Примеры данных |
1 |
женский |
жен. |
Таблица 2.17 Реляционная таблица «TIP_TELEFON»
Имя поля |
kod |
nazv |
|
Ключ |
Primary Key |
||
Тип, длина |
integer |
Varchar(30) |
|
Обязательность значения |
Not Null |
||
Логическое ограничение на поле |
Check (value>0 ) |
||
Примеры данных |
1 |
городской |
Таблица 2.18 Реляционная таблица «TELEFON»
Имя поля |
kod |
kod ur_lica |
kod t_tel |
kod Fiz_l |
Nom_t |
|
Ключ |
Primary Key |
Foreign key |
Foreign key |
Foreign key |
||
Тип, длина |
integer |
integer |
Integer |
integer |
Integer |
|
Обязательность значения |
Not Null |
Not Null |
Not Null |
|||
Логическое ограничение на поле |
Check (value>0 ) |
|||||
Примеры данных |
13 |
214 |
512 |
41 |
223322 |
Таблица 2.19- Реляционная таблица «FIZ_LICO»
Имя поля |
kod |
imja |
fam |
Otch |
N_ser |
N_pasp |
Kod_pola |
|
Ключ |
Primary Key |
|||||||
Тип, длина |
Integer |
Varchar(40) |
Varchar(40) |
Varchar(40) |
Integer |
Integer |
Integer |
|
Обязательн. значения |
Not Null |
Not Null |
Not Null |
Not Null |
||||
Лог. огран. на поле |
Check (value>0 ) |
Check (value>0 ) |
Check (value>0 ) |
|||||
Примеры данных |
21 |
Петров |
Иван |
Сидорович |
1213 |
212231 |
12 |
Таблица 2.20 Реляционная таблица «TIP_STR_ED»
Имя поля |
Kod |
Nazv |
Kr_nazv |
|
Ключ |
Primary Key |
|||
Тип, длина |
integer |
Varchar(70) |
Varchar(50) |
|
Обязательность значения |
Not Null |
|||
Логическое ограничение на поле |
Check (value>0 ) |
|||
Примеры данных |
1 |
завод |
зав. |
Таблица 2.21 Реляционная таблица «UR_LICO»
Имя поля |
kod |
kod tip |
nazv |
Kr-nazv |
|
Ключ |
Primary Key |
Foreign key |
|||
Тип, длина |
integer |
integer |
Varchar(50) |
Varchar(30) |
|
Обязательность значения |
Not Null |
Not Null |
Not Null |
||
Логическое ограничение на поле |
Check (value>0 ) |
||||
Примеры данных |
31 |
1 |
Шинторгспб |
Шинторг |
Таблица 2.22 Реляционная таблица «VID_TOV»
Имя поля |
Kod |
Nazv |
|
Ключ |
Primary Key |
||
Тип, длина |
integer |
Varchar(30) |
|
Обязательность значения |
Not Null |
||
Логическое ограничение на поле |
Check (value>0 ) |
||
Примеры данных |
1 |
химия |
Таблица 2.23 Реляционная таблица «TOVAR»
Имя поля |
Kod |
Nazv |
|
Ключ |
Primary Key |
||
Тип, длина |
integer |
Varchar(50) |
|
Обязательность значения |
Not Null |
||
Логическое ограничение на поле |
Check (value>0 ) |
||
Примеры данных |
1 |
Колбаса |
Таблица 2.24 Реляционная таблица «ED_IZM»
Имя поля |
kod |
nazv |
Kr_nazv |
|
Ключ |
Primary Key |
|||
Тип, длина |
Integer |
Varchar(30) |
Varchar(10) |
|
Обязательность значения |
Not Null |
|||
Логическое ограничение на поле |
Check (value>0 ) |
|||
Примеры данных |
1 |
тонна |
т. |
Таблица 2.25 Реляционная таблица «DOC_O_POST_TOV»
Имя поля |
Nomer |
Kod_str_ed1 |
Kod_Str_ed2 |
Data |
|
Ключ |
Primary Key |
Foreign key |
Foreign key |
||
Тип, длина |
integer |
integer |
Integer |
date |
|
Обязательность значения |
Not Null |
Not Null |
Not Null |
||
Логическое ограничение на поле |
Check (value>0 ) |
Check (value>0 ) |
Check (value>0 ) |
||
Примеры данных |
21 |
11 |
2 |
12.05.07 |
Таблица 2.26 Реляционная таблица «DOC_O_RASH»
Имя поля |
Nomer |
data |
Kod_str_ed1 |
Kod_str_ed2 |
Kod_fiz_l |
|
Ключ |
Primary Key |
Foreign key |
Foreign key |
Foreign key |
||
Тип, длина |
integer |
data |
Integer |
integer |
integer |
|
Обязательность начения |
Not Null |
Not Null |
Not Null |
Not Null |
Not Null |
|
Логическое ограничение на поле |
Check (value>0 ) |
Check (value>0 ) |
Check (value>0 ) |
|||
Примеры данных |
1 |
21.2.2009 |
2 |
30 |
90 |
Таблица 2.27 Реляционная таблица «POZICIYA_DOC_O_POST»
Имя поля |
Nomer |
Kol_vo |
Cena_ed |
Kod_t |
N_doc_p |
Kod_ed1 |
Kod_ed2 |
|
Ключ |
Primary Key |
Foreign key |
Foreign key |
Foreign key |
Foreign key |
|||
Тип, длина |
integer |
Integer |
Integer |
Integer |
integer |
inteher |
integer |
|
Обязательн. Значения |
Not Null |
Not Null |
Not Null |
Not Null |
Not Null |
Not Null |
Not Null |
|
Логическое ограничение на поле |
Check (value>0 ) |
Check (value>0 ) |
Check (value>0) |
Check (value>0) |
Check (value>0) |
|||
Примеры данных |
2 |
234 |
24 |
1 |
34 |
44 |
12 |
Таблица 2.28 Реляционная таблица «POZICIYA_DOC_O_RASH
Имя поля |
Nomer |
Kol_vo |
Cena_ed |
Kod_t |
N_doc_r |
Kod_ed1 |
Kod_ed2 |
Kod_fiz |
|
Ключ |
Primary Key |
Foreign key |
Foreign key |
Foreign key |
Foreign key |
Foreign key |
|||
Тип, длина |
integer |
Integer |
Integer |
Integer |
integer |
inteher |
integer |
integer |
|
Обязательн. значения |
Not Null |
Not Null |
Not Null |
Not Null |
Not Null |
Not Null |
Not Null |
Not Null |
|
Логическое ограничение |
Check (value>0 ) |
Check (value>0 ) |
Check (value>0) |
Check (value>0) |
Check (value>0) |
Check (value>0) |
|||
Примеры данных |
23 |
2343 |
244 |
2 |
34 |
44 |
445 |
12 |
Таблица 2.29 Реляционная таблица «TIP_UL»
Имя поля |
Kod |
nazv |
Kr_nazv |
|
Ключ |
Primary Key |
|||
Тип, длина |
Integer |
Varchar(50) |
Varchar(30) |
|
Обязательность значения |
Not Null |
|||
Логическое ограничение на поле |
Check (value>0 ) |
|||
Примеры данных |
1 |
Улица |
ул. |
Таблица 2.30 Реляционная таблица «ULICA»
Имя поля |
Kod |
Nazv |
Kod tipa_ul |
|
Ключ |
Primary Key |
Foreign key |
||
Тип, длина |
integer |
Varchar(50) |
Integer |
|
Обязательность значения |
Not Null |
Not Null |
||
Логическое ограничение на поле |
Check (value>0 ) |
Check (value>0 ) |
||
Примеры данных |
1 |
Победы |
1 |
Таблица 2.31 Реляционная таблица «TIP_N_PUNKTA»
Имя поля |
Kod |
nazv |
Kr_nazv |
|
Ключ |
Primary Key |
|||
Тип, длина |
integer |
Varchar(50) |
Varchar(10) |
|
Обязательность значения |
Not Null |
|||
Логическое ограничение на поле |
Check (value>0 ) |
|||
Примеры данных |
1 |
поселок |
пос. |
Таблица 2.32 Реляционная таблица «NAS_PUNKT»
Имя поля |
Kod |
Kod_tipa |
nazv |
Kr_nazv |
|
Ключ |
Primary Key |
Foreign key |
|||
Тип, длина |
integer |
integer |
Varchar(50) |
Varchar(30) |
|
Обязательность значения |
Not Null |
Not Null |
|||
Логическое ограничение на поле |
Check (value>0 ) |
Check (value>0 ) |
|||
Примеры данных |
1 |
1 |
город |
г. |
Таблица 2.33 Реляционная таблица «ADRES»
Имя поля |
kod |
kod_ ul |
Kod_ n_p |
Nomer_ fiz_l |
Kod_ ur_l |
dom |
korpus |
ofise |
|
Ключ |
Primary Key |
Foreign key |
Foreign key |
Foreign key |
Foreign key |
||||
Тип, длина |
integer |
integer |
Integer |
integer |
integer |
integer |
integer |
integer |
|
Обязательн. значения |
Not Null |
Not Null |
Not Null |
Not Null |
Not Null |
||||
Логическое ограничение на поле |
Check (value>0 ) |
Check (value>0 ) |
Check (value>0 ) |
Check (value>0 ) |
Check (value>0 ) |
||||
Примеры данных |
1 |
21 |
44 |
231 |
1 |
53 |
1 |
32 |
При построении физической модели использовались следующие конструкции языка SQL:
- Рrimary Key - первичный ключ; Foreign key - внешний ключ; Not Null - запрет на пустое поле; Сheck - условие ограничения.
SQL - скрипты созданных объектов, приведены в приложении А.
2.4.11 Реализация ограничения целостности БД
Создаваемая и эксплуатируемая реляционная база данных должна быть целостной и надежной.
Обязательно должны поддерживаться:
- уникальность строк таблицы. Должен быть определен первичный ключ таблицы, и значение его должно быть определено;
- все уникальные (потенциальные) ключи, выявленные в ходе анализа предметной области.
Эти ограничения реализуются в командах создания и модификации таблиц. Например, в языке SQL это команды Create Table. В этих командах для описания полей - первичных ключей используется конструкция Primary Key, для описания полей - уникальных ключей конструкция Unique, обязательность значений полей задается конструкцией Not Null.
Ссылочная целостность. Каждая таблица проектируемой БД должна быть связана с другими посредством соответствующих первичных и внешних ключей, т.е. быть либо родительской (главной) по отношению к другим таблицам, либо дочерней (подчиненной), либо той и другой для разного уровня связей. Назначение внешнего ключа - связывать каждую строку дочерней таблицы с соответствующей строкой родительской таблицы. Значение внешнего ключа может иметь и пустое значение (Null), если он реализует необязательную связь, выявленную в предметной области. В качестве значения внешнего ключа может выступать значение и любого уникального (потенциального) ключа.
Подобные документы
Проектирование программного продукта. Разработка базы данных средствами Microsoft Access. Разработка прикладных решений для информационной системы 1С: Предприятие 8.2. Изучение первичной, вторичной документации. Автоматизация учета и управление компанией.
курсовая работа [1,4 M], добавлен 14.12.2017Анализ существующей методики воинского учета. Схема архитектуры и программная реализация разрабатываемого АРМ специалиста отдела мобилизационной работы и комплектования. Логическая структура реляционной базы данных. Результаты тестирования программы.
дипломная работа [1,4 M], добавлен 16.05.2013Разработка программы учета занятости компьютеров в лаборатории. Анализ требований, метод решения. Разработка алгоритма в виде структурных схем. Программная реализация в среде Borland Delphi. Минимальные системные требования для ее корректной работы.
дипломная работа [6,3 M], добавлен 10.06.2013Склад ОАО "Ориенбанк", его специфика и структура. Описание структуры базы данных складского учета для предприятия. Разработка пользовательского интерфейса программы. Инструкция к применению базы данных. Автоматизация операций и учета средств банка.
курсовая работа [4,7 M], добавлен 26.02.2010Роль оптовой торговли в рыночной экономике. Сортовой и партионный способы учета товаров. Организация бухгалтерского учета и документооборота на предприятии. Разработка базы данных для автоматизации учета переоценки стоимости товаров на оптовом складе.
дипломная работа [2,8 M], добавлен 15.01.2012Анализ входной и выходной информации на предприятии. Осуществление функционального и информационного моделирования базы данных, создание ее структуры. Программная реализация системы автоматизации учета работы автотранспорта. Оценка трудоемкости проекта.
дипломная работа [1,2 M], добавлен 09.07.2012Технико-экономическая характеристика предприятия. Выбор комплекса задач автоматизации, анализ бизнес-процессов. Концептуальный уровень архитектуры базы данных, ее физическая модель. Программная реализация информационной системы для учета ремонтных работ.
дипломная работа [8,8 M], добавлен 27.06.2012- Разработка информационной системы для автоматизации учета ремонта электрооборудования на предприятии
Архитектура и функции информационной системы для автоматизации учета ремонта электрооборудования. Построение модели прецедентов, потоков данных и процессов в стандарте IDEF0. Проектирование концептуальной и логической модели интегрированной базы данных.
курсовая работа [442,9 K], добавлен 06.08.2013 Создание информационной системы товарооборота на основе использования технологий баз данных кирпичного завода. Физическая модель базы данных. Проектирование БД в СУБД Microsoft SQL Server. Схема функциональной структуры программной системы. Запросы к БД.
курсовая работа [3,5 M], добавлен 05.03.2015Разработка программной системы для поддержки генеалогических деревьев. Модели вариантов использования и анализа системы. Морфологическая и функциональная модели, диаграммы состояний, деятельности и взаимодействия. Хранение сведений в базах данных.
курсовая работа [535,2 K], добавлен 01.02.2013