48
цвет;
открывание;
размер;
толщина;
вес;
цена;
наличие на складе.
Сведения о заявках включают номер заявки, дату, информацию о клиенте,
артикул товара, его цене, количестве, скидке и условиях доставки.
За актуализацию данных в справочниках несут ответственность менедже-
ра по продажам.
2.2.3. Характеристика результатной информации
В данной работе результирующей информацией является:
договор на покупку товара;
квитанция об оплате.
Квитанции формируются на основе таблиц:
клиенты;
товары;
заявки;
менеджеры.
Результирующая информация используется для оперативного управления
и принятия решений.
2.3. Программное обеспечение задачи
2.3.1. Общие положения (дерево функций и сценарий диалога)
В данной работе автоматизации подлежит процесс обработки заявок в
ООО «Сибирь-Профиль-Красноярск». Функционал программы можно разделить
на основной, с помощью которой достигается основная цель автоматизации и
служебный. Дерево функций наглядно демонстрирует разделение данных функ-
ций (рисунок 2.2).
49
Рисунок 2.2 – Дерево функций ПО
На рисунке 2.3 представлен сценарий диалога ПО.
Рисунок 2.3 – Сценарий диалога ПО
2.3.2. Характеристика базы данных
Для описания инфологической модели предметной области существует
несколько систем условных обозначений. Наиболее простые и понятные обозна-
чения имеет модель «сущность – связь» (кратко ER – модель) [7, 13]. На рисунке
2.4 приведена ER – модель данных.
50
Рисунок 2.4 – ER – модель
При проектировании базы данных, на этапе логического проектирования,
выполняется процедура нормализации отношений базы данных. Нормализация –
это метод создания набора отношений с заданными свойствами на основе требо-
ваний к данным, установленным в некоторой организации.
Нормализация представляет собой вариант восходящего подхода к проек-
тированию базы данных, который начинается с установления связей между ат-
рибутами. Однако нормализация также используется и при нисходящем подходе
к проектированию базы данных, который начинается с выявления основных
сущностей и связей, в качестве метода проверки корректности полученного ре-
зультата.
В результате нормализации по определенным правилам [7], получим 4
таблицы (таблицы 2.1. – 2.4).
Таблица 2.1
«Клиенты»
№
Атрибуты
1
2
1
ID клиента (ключ)
51
Продолжение таблицы 2.1
2
ФИО клиента (или юридическое наименование)
3
№ телефона
4
e-mail
5
реквизиты
Таблица 2.2
«Товар»
№
Атрибуты
1
артикул (ключ)
2
наименование
3
материал
4
наполнение
5
дизайн
6
цвет
7
открывание
8
размер
9
толщина
10
вес
11
цена
12
наличие на складе
Таблица 2.3
«Менеджеры»
№
Атрибуты
1
Табельный номер (ключ)
2
ФИО менеджера
3
№ телефона
52
Таблица 2.4
«Заказы»
№
Атрибуты
1
№ заказа (ключ)
2
дата заказа
3
ФИО клиента
4
артикул
5
количество
6
цена
7
скидка
8
ФИО менеджера
9
условия доставки
Таблица 2.5
«Работа с клиентами»
№
Атрибуты
1
ID клиента (ключ)
2
ФИО клиента (или юридическое наименование)
3
№ телефона
4
дозвон
5
дата дозвона
6
примечание
7
e-mail
8
отправка предложений
9
дата отправки
10
краткое содержание письма
В разрабатываемой БД справочной таблицей является таблица «Менедже-
ры», остальные будут операционными. Рисунок 2.5 иллюстрирует модель логи-
ческого проектирования базы данных.
53
Рисунок 2.5 – Логическая схема базы данных
На этапе физического проектирования предусмотрено описание структу-
ры хранения данных и методов доступа, предназначенных для осуществления
наиболее эффективного доступа к информации. Поэтому физическое проектиро-
вание обязательно производится с учетом всех особенностей используемой
СУБД.
Между фазами физического и логического проектирования всегда имеется
определенная обратная связь, поскольку решения, принятые на этапе физическо-
го проектирования с целью повышения производительности разрабатываемой
системы, могут потребовать некоторого пересмотра логической модели данных.
Самым первым заданием на этапе физического проектирования БД явля-
ется преобразование отношений, связанных на основе логической модели дан-
ных, в такую форму, которая может быть реализована в среде целевой СУБД.
Первая часть этого процесса предусматривает проверку информации, собранной
на этапе логического моделирования. Вторая часть процесса заключается в ис-
пользовании этой информации для разработки проекта таблиц базы данных си-
стемы.
Связи между таблицами дают возможность совместно использовать дан-
ные из разных таблиц. Связь каждой пары таблиц обеспечивается одинаковыми
полями в них – ключом связи (внешним ключом). Ключом связи всегда является
уникальный ключ главной таблицы [13].
Ниже приведена структура таблиц, используемых в БД (таблица 2.6-2.8).
54
Таблица 2.6
«Клиенты»
Атрибуты
Тип данных
ID клиента (ключ)
Счетчик (Длинное целое)
ФИО клиента (или юридическое наименование)
Текстовый (255)
№ телефона
Текстовый (255)
e-mail
Текстовый (255)
реквизиты
Мемо
Таблица 2.7
«Товар»
Атрибуты
Тип данных
артикул (ключ)
Текстовый (255)
наименование
Текстовый (255)
материал
Текстовый (255)
наполнение
Мемо
дизайн
Текстовый (255)
цвет
Текстовый (255)
открывание
Текстовый (255)
размер
Текстовый (255)
толщина
Числовой (Действительное)
вес
Числовой (Действительное)
цена
Денежный
наличие на складе
Числовой (Целое)
Таблица 2.8
«Менеджеры»
Атрибуты
Тип данных
Табельный номер (ключ)
Текстовый (255)
ФИО
Текстовый (255)
№ телефона
Текстовый (255)
55
Таблица 2.9
«Заказы»
Атрибуты
Тип данных
№ заказа (ключ)
Счетчик (Длинное целое)
дата
Дата
клиент
Текстовый (255)
артикул
Текстовый (255)
количество
Числовой (Целое)
цена
Денежный
скидка
Числовой (Действительное)
менеджер
Текстовый (255)
условия доставки
Мемо
Таблица 2.10
«Работа с клиентами»
Атрибуты
Тип данных
ID клиента (ключ)
Счетчик (Длинное целое)
ФИО клиента (или юридическое наименование)
Текстовый (255)
№ телефона
Текстовый (255)
дозвон
Логический
дата дозвона
Дата
примечание
Мемо
e-mail
Текстовый (255)
отправка предложений
Логический
дата отправки
Дата
краткое содержание письма
Мемо
2.3.3. Структурная схема пакета (дерево вызова программных модулей)
ПО представляет собой набор взаимосвязанных модулей (форм), позволя-
ющих редактировать, вводить и отображать данные, хранящиеся в БД. Описание
форм представлено в таблице 2.11.
56
Таблица 2.11
Формы проекта
Заголовок формы
Описание
Сибирь-Профиль-
Красноярск (Unit1)
Главная форма проекта, на которой располагаются
кнопки выбора (работа с товаром, с клиентами,
обработка заявок)
База клиентов (Unit2)
На форме отображается основная информация по
клиентам. Предназначена для редактирования и
просмотра информации о клиентах
База товаров (Unit3)
На форме располагается основное меню для рабо-
ты с базой товаров, отображается основная ин-
формация по товарам. На данной форме располо-
жена функция поиска информации
Товар(Unit5)
Предназначена для редактирования базы товаров
Обработка заявок (Unit4)
На форме располагается основное меню для рабо-
ты с заявками, отображается основная информа-
ция по заявкам. На данной форме расположена
функция поиска информации
Заявка (Unit8)
Предназначена для создания и редактирования за-
явок
Менеджеры (Unit6)
Предназначена для создания и редактирования
списка менеджеров
Квитанция (Unit9)
Предназначена для формирования отчета – кви-
танции об оплате оказанных услуг
Договор (Unit10)
Предназначена для формирования договора о по-
купке товара
Справка (Unit7)
Содержит сведения о ПО
2.3.4. Описание программных модулей
Все программные модули могут быть запущены с главной формы проекта
(рисунок 2.6).
57
Рисунок 2.6 – Дерево вызова программных модулей
ПО разработано с помощью объектно-ориентированного языка програм-
мирования Delphi. БД разработана с помощью Microsoft Access. Все модули про-
граммы хранятся в папке СП-Крк. БД ПО может быть модифицирована с помо-
щью других СУБД.
Для нормального функционирования программы необходимы модули
SPKrk.exe, data_base.mdb. Программа разработана как клиент-серверное прило-
жение.
Данная программа выполняет следующие функции:
1. Ввод, хранение и редактирование данных о:
клиентах;
заявках;
товаре;
менеджерах.
2. Возможность поиска информации по выбранным полям.
3. Формирование заявки.
4. Формирование отчетности.