97
Модель;
Год;
Заводской номер;
Статус авто.
Макет данного отчета представлен на Рисунке 2.15.
Рисунок 2.15 Макет отчета за период о проведенных работах в разрезе
автомобилей
Отчет за период о проведенных работах в разрезе видов работ содержит:
Дата;
Вид работ;
Единица;
Стоимость за ед., руб.;
Кол-во;
Стоимость работы, руб.;
Стоимость запчастей, руб.;
Ответственный.
Макет данного документа представлен на Рисунке 2.16.
98
Рисунок 2.16 Макет отчета за период о проведенных работах в разрезе видов
работ
Общий отчет по продажам содержит данные по общей сумме продаж за
период.
Отчет по работе менеджеров по продажам содержит данные по объему
продаж каждого продавца за период.
Аналитика продаж по категориям содержит сведения по продажам
автомобилей с разбиением по маркам, запчастей и аксессуаров за период.
2.3 Программное обеспечение задачи
2.3.1 Общие положения (дерево функций и сценарий диалога)
Диалог – это процесс обмена информацией между пользователем и
программной системой, осуществляемый через интерактивный терминал и по
определенным правилам [12]. Общение компьютера и пользователя при работе с
информационной системой осуществлено в диалоговом режиме, управляемого
программой.
Пользовательский интерфейс построен по технологии WIMP (Window –
окно, Image – образ, Menu – меню, Pointer - указатель). Использованы основные
элементы графического интерфейса: окна приложения, окна диалога, окна
контекстного меню, иерархическое меню, компоненты ввода-вывода, пиктограммы
панели инструментов, программные пиктограммы и т.д. Элементы графического
интерфейса реализуют как служебные, так и основные функции программы.
Разрабатываемое ИС содержит следующие основные функции:
Учетные операции, связанные с продажей автомтбилия и
оформлением договора;
99
Учётные операции, связанные с учетом автомобилей и проводимых
работ;
Операции работы со справочниками, к которым относятся единицы
измерений, марки и модели автомобилей, типы запчастей, виды работ;
Операции по формированию отчетных документов, основными
отчетами среди которых являются:
общий отчет по продажам;
отчет по работе менеджеров по продажам;
аналитика продаж по категориям.
Отчет по движению запчастей;
Отчет по работам за автомобиль;
Отчет за период о проведенных работах в разрезе автомобилей;
Отчет за период о проведенных работах в разрезе видов работ.
Отчет Склад.
Также в системе присутствуют служебные функции в виде настроек
системы.
Работу с системой осуществляет сотрудник компании. Дерево функций
системы представлено на Рисунке 2.17.
100
Рисунок 2.17 Дерево функций системы учета продаж в автосалоне
Сотрудник при работе в системе имеет возможность заполнения
справочников, в том числе добавления, удаления записей, поиска по ним и
получения списка записей, содержащихся в справочниках.
Сценарии диалога, формирующийся на основе дерева функций, приведен на
Рисунке 2.18.
101
Рисунок 2.18 Сценарий диалога Системы учета продаж в автосалоне
2.3.2 Характеристика базы данных
Методика хранения данных в ИБ должна соответствовать некоторым
требованиям:
• достаточность хранящейся информации для выполнения любых
операций управления и решения экономических задач;
• целостность данных, т.е. поддержание непротиворечивости данных
при занесении информации в ИБ;
• одновременность и своевременность обновлений данных во всех
используемых копиях;
• адаптивность и гибкость системы ИБ к изменяющимся
информационным потребностям потребителей;
• Развёртывание системы, обеспечивающей нужный уровень сложности
структуры информационной базы;
102
• релевантность, т.е. соответствие ИБ, под которым подразумевается
возможность системы реализовывать поиск и отображать информацию, которая
точно соответствует исходному запросу пользователей;
• понятность интерфейса системы, позволяющая оперативно создавать
запрос к ИБ;
• разграничение прав доступа, подразумевающее разделение для
каждого пользователя открытых типов записей, полей, файлов и доступных типов
операций над ними.
Есть два основных подхода к разработке систем БД: снизу-вверх или сверху
вниз. Первый подходит для создания небольших БД с ограниченным числом
атрибутов. Использование такого подхода усложняется при создании БД с
огромным числом атрибутов, описать среди которых все доступные
функциональные зависимости проблематично. При создании сложных систем БД
лучше всего применять нисходящий подход, хорошо зарекомендовавший себя в
рамках модели «сущность-связь». Тут работа связана с определением сущностей и
процессом их взаимодействия, которые очень важны для подобной разработки.
Весь путь создания БД включает 3 фазы: концепция, логическая модель и
проектирование прототипа. Любая фаза состоит из необходимой модели данных,
которая становится источником данных для другой фазы. Основное значение тут
возложено на концепцию, реализуемую в ракмкх параметров, указанных в
спецификации пользовательских требований. Подготовка концепции БД никак не
пересекается в такие подробности ее реализации, как тип применяемой целевой
СУБД, тип используемой вычислительной платформы и т.п., но качество
концепции тут уже имеет решающее значение, позволяющее отразить
трудозатраты на создание системы, ее скорость работы и текущий успех. Опыт
создания и использования ИС говорит о том, что ошибки, возможные в процессе
этого этапа, очень трудно выявить и устранить, поскольку они встречаются обычно
уже на последующих этапах создания системы – при реализации и поддержке.
На этапе проектирования логической модели концепция данных переходит в
логическую модель, создаваемую в рамках указанной модели хранения
информации основной СУБД. По итогу, этот этап отражает, какая СУБД
используется в качестве целевой - иерархическая, сетевая, реляционная или
103
объектно-ориентированная. Тут проходят все остальные аспекты начальной СУБД
– к примеру, некие особенности физической реализации хранения данных.
Логическая модель, отражающая особенности отображения о создаваемой системе
больше одного типа пользователей, считается глобальной логической моделью
данных. Есть пара базовых подходов для создания совокупной логической модели:
метод внедрения представлений и централизованный способ. Если создается
крупная ИС, лучше и эффективнее использовать второй подход, когда общая
логическая модель реализуется методом слияния отдельных моделей,
показывающих представления отдельных групп пользователей.
В процессе создания прототипа принимаются решения о вариантах
реализации текущей БД. Поэтому физическое проектирование очень сильно
завязано на конкретной СУБД. Между разработкой логической модели и
подготовкой прототипа есть постоянная обратная связь, т.к. все решения,
принимаемые на этапе создания прототипа для повышения производительности
системы, очень влияют и на структуру логической модели. Цель создания
прототипа БД заключается в описании варианта итоговой реализации проекта всей
БД.
Схема таблиц базы данных представлена на Рисунке 2.19.
104
Рисунок 2.19 Схема базы данных в среде проектирования
Характеристика таблиц базы данных приведена в Таблицах 2.19-2.28.
Таблица 2.18
Структура таблицы sale
Поле
Тип
Null
По умолчанию
idsale
int(11)
Нет
salecol
varchar(255)
Да
NULL
Contract_id
int(11)
Да
NULL
datesale
date
Да
NULL
summa
varchar(255)
Да
NULL
Status
varchar(255)
Да
NULL
Таблица 2.19
Структура таблицы contract
Поле
Тип
Null
По умолчанию
idContact
int(11)
Нет
User_id
varchar(255)
Да
NULL
Auto_id
int(11)
Да
NULL
Dateadd
double
Да
NULL
105
Продолжение Таблицы 2.20
Поле
Тип
Null
По умолчанию
Status
int(11)
Да
NULL
id_manager
int(11)
Да
NULL
Summa
varchar(255)
Да
NULL
Dateclos
date
Да
NULL
Primech
varchar(255)
Да
NULL
Таблица 2.20
Структура таблицы auto
Поле
Тип
Null
По умолчанию
Id
int(11)
Нет
registration_date
datetime
Да
NULL
id_brand
int(11)
Да
NULL
id_model
int(11)
Да
NULL
issue_year
int(11)
Да
NULL
factory_number
varchar(255)
Да
NULL
Cost
double
Да
NULL
id_auto_status
int(11)
Да
NULL
work_total
double
Да
NULL
spare_part_total
double
Да
NULL
service_total
double
Да
NULL
VIN
varchar(255)
Да
NULL
Rama
varchar(255)
Да
NULL
Kuzov
varchar(255)
Да
NULL
Engine
varchar(255)
Да
NULL
Pts
varchar(255)
Да
NULL
Sts
varchar(255)
Да
NULL
Autocol
varchar(255)
Да
NULL
Таблица 2.21
Структура таблицы auto_model
Поле
Тип
Null
По умолчанию
Id
int(11)
Нет
Title
varchar(255)
Да
NULL
Таблица 2.22
Структура таблицы brand
Поле
Тип
Null
По умолчанию
Id
int(11)
Нет
Title
varchar(255)
Да
NULL
106
Таблица 2.23
Структура таблицы spare_part
Поле
Тип
Null
По умолчанию
Id
int(11)
Нет
Title
varchar(255)
Да
NULL
id_unit
int(11)
Да
NULL
Cost
double
Да
NULL
Amount
int(11)
Да
NULL
id_spare_part_type
int(11)
Да
NULL
Таблица 2.24
Структура таблицы user
Поле
Тип
Null
По умолчанию
Id
int(11)
Нет
Username
varchar(255)
Нет
password_hash
varchar(255)
Нет
auth_key
varchar(32)
Нет
password_reset_token
varchar(255)
Да
NULL
activation_token
varchar(255)
Да
NULL
Email
varchar(255)
Нет
Status
smallint(6)
Нет
10
created_at
int(11)
Нет
updated_at
int(11)
Нет
Nikname
varchar(255)
Да
NULL
id_user_type
int(11)
Да
NULL
last_name
varchar(255)
Да
NULL
first_name
varchar(255)
Да
NULL
middle_name
varchar(255)
Да
NULL
Phone
varchar(255)
Да
NULL
report_date_1
datetime
Да
NULL
report_date_2
datetime
Да
NULL
Таблица 2.25
Структура таблицы work
Поле
Тип
Null
По умолчанию
Id
int(11)
Нет
work_date
datetime
Да
NULL
id_auto
int(11)
Да
NULL
id_work_kind
int(11)
Да
NULL
cost
double
Да
NULL
amount
int(11)
Да
NULL
work_total
double
Да
NULL
spare_part_total
double
Да
NULL
total
double
Да
NULL
id_user
int(11)
Да
NULL