57
Заявления компании могут содержать различного рода информацию: как о
принятии на работу, увольнении, так и о предоставлении отпуска или больнич-
ного отпуска.
2.2.3. Характеристика результатной информации
Выходная информация – информация, образующаяся в результате обра-
ботки входной информации на выходе системы. Она является результатом при-
нятого управленческого решения и может быть представлена в виде документов,
письменных и устных сообщений и прочее.
Для предприятия ООО «АлексАвто» поток результатной информации
можно представить схематически в виде структуры, показанной на рисунке 2.3.
Рисунок 2.3 – Поток результатной информации
На основании проведения операций покупки или продажи автомобилей
выходной документацией можно считать договор купли-продажи, договор ко-
миссии.
Договор купли-продажи включает в себя условия, по которым компания
продает покупателю автомобиль с определенными характеристиками. Договор
58
содержит условия передачи имущества, цену товара, порядок расчета и акт при-
ема-передачи по договору купли-продажи.
Договор комиссии - договор, по которому комиссионер принимает на себя
обязанность по поручению комитента совершить от своего имени за вознаграж-
дение реализацию автомобиля. Договор включает в себя информацию о праве
собственности, стоимости автомобиля, сроках поступления на продажу, тесто-
вом использовании автомобиля, порядок выплаты денежных средств в случае
продажи автомобиля и акт приема-передачи по договору комиссии.
Результативной информацией в случае оформления купли-продажи или
договора комиссии является также информирование клиента об итогах продажи,
поступления денежных средств на счет компании, после чего договор считается
полностью выполнен. Компания предоставляет своим клиентам предпродажное
информирование о дополнительных услугах, предоставляемых организацией:
сервисные услуги, услуги комиссии, доставки и продажи. Компания постоянно
информирует клиентов о поступлениях новых автомобилей, рассылает свои
прайс-листы и рекламные афиши.
2.3. Программное обеспечение задачи
2.3.1. Общие положения (дерево функций и сценарий диалога)
В данной работе автоматизации подлежит процесс работы менеджеров по
продажам ООО «АлексАвто». Функционал программы можно разделить на ос-
новной, с помощью которой достигается основная цель автоматизации и слу-
жебный [8]. Дерево функций наглядно демонстрирует разделение данных функ-
ций (рисунок 2.4).
59
Рисунок 2.4 – Дерево функций автоматизированной системы
Основное окно программы предоставляет статистические данные о поку-
пателях, поставщиках, автомобилях на складе, поставках и продажах. На рисун-
ке 2.5 представлен сценарий диалога автоматизированной системы.
Рисунок 2.5 – Сценарий диалога автоматизированной системы
2.3.2. Характеристика базы данных
Основным этапом проектирования базы данных является её логическое
проектирование. В основе этого этапа лежит процедура нормализации БД.
Нормализация – это метод создания набора отношений с заданными свой-
ствами на основе требований к данным, установленным в некоторой организа-
ции.
Нормализация представляет собой вариант восходящего подхода к проек-
тированию базы данных, который начинается с установления связей между ат-
рибутами. Однако нормализация также используется и при нисходящем подходе
к проектированию базы данных (который начинается с выявления основных
60
сущностей и связей) в качестве метода проверки корректности полученного ре-
зультата. Нормализация – это формальный метод анализа отношений на основе
их первичного ключа и существующих функциональных зависимостей.
Ненормализованная форма – это таблица, содержащая одну или несколько
повторяющихся групп данных.
Первая нормальная форма – это отношение, в котором все используемые
домены содержат только скалярные значения.
Вторая нормальная форма – это отношение, которое находится в первой
нормальной форме и каждый атрибут которого, не входящий в состав первично-
го ключа, характеризуется полной функциональной зависимостью от этого пер-
вичного ключа.
Третья нормальная форма – это отношение, которое находится в первой и
второй нормальных формах и не имеет не входящих в первичный ключ атрибу-
тов, которые находились бы в транзитивной функциональной зависимости от
этого первичного ключа.
Отношение находится в нормальной форме Бойса-Кодда только тогда, ко-
гда каждая нетривиальная и неприводимая слева функциональная зависимость
обладает потенциальным ключом в качестве детерминанта.
На первоначальном этапе проектирования структуры базы данных всю
информацию сводим в одну таблицу без составных полей и повторяющихся
групп. Эти данные представлены в таблице 2.1.
61
Таблица 2.1
Ненормализованные данные
Фамилия покупателя
Имя покупателя
Отчество покупателя
Паспортные данные покупателя
Адрес покупателя
Название поставщика
Адрес
Телефон
E-mail
Марка машины
Номер
V двигателя
Цвет
Мощность
Масса
Цена поставки
Цена продажи
Далее выделяем следующие таблицы:
данные для поставки автомобиля на склад представлены в таблице 2.2;
сведения об автомобиле сведены в таблицу 2.3;
данные о проданных автомобилях сведены в таблицу 2.4;
информация о поставщике представлена в таблице 2.5;
сведения о проданных автомобилях в таблице 2.6;
информация о покупателе представлена в таблице 2.7.
62
Таблица 2.2
Поставка на склад
Поставщик
Марка
Адрес
Телефон
Цена поставки
Таблица 2.3
Автомобиль
Марка
Цвет
Номер
V двигателя
Масса
Мощность
Цена
Таблица 2.4
История продаж
Марка автомобиля
Покупатель
Дата продажи
Таблица 2.5
Поставщик
Поставщик
Адрес
Телефон
E-mail
63
Таблица 2.6
Продажа
Поставщик
Марка автомобиля
Цена продажи
Таблица 2.7
Покупатель
Фамилия покупателя
Имя покупателя
Отчество покупателя
Паспорт
Адрес
Существуют классификации таблиц БД по виду изменений информации,
которая содержится в таблицах, а именно:
справочные таблицы – содержат информацию справочного характера,
обладают невысокой степенью изменчивости. Они находятся с операционными
и транзакционными таблицами в отношении 1:М, являясь при этом родитель-
скими таблицами.
операционные таблицы – в них происходит непрерывное или перио-
дическое обновление информации. Они находятся в подчиненном отношении со
справочными. На основании данных операционных таблиц формируются итого-
вые отчеты.
В разрабатываемой БД справочными являются таблицы 2.8-2.10, приве-
денные ниже.
64
Таблица 2.8
Автомобили
Марка
Модель
Номер кузова
Цвет
Номер двигателя
Модель двигателя
Масса
Цена поставки
Цена продажи
Поставщик
Год выпуска
Транзитный знак
Таблица 2.9
Поставщики
Поставщик
Адрес
E-mail
Телефон
65
Таблица 2.10
Покупатель
Фамилия
Имя
Отчество
Адрес
Паспорт
Дата рождения
ИНН
Телефон
E-mail
К операционным таблицам относятся таблица 2.11 и таблица 2.12, в кото-
рых приведена информация о поступающих на склад автомобилях и сведения о
проданных автомобилях соответственно.
Таблица 2.11
Поставки
Поставщик
Автомобиль
Дата поставки
Таблица 2.12
Продажи
Покупатель
Автомобиль
Транзитный знак
Дата продажи
Рисунок 2.6 иллюстрирует модель логического проектирования базы дан-
ных автосалона «АлексАвто».
66
Рисунок 2.6 – Логическая схема базы данных автосалона «АлексАвто»
Физическое проектирование базы данных
Физическое проектирование базы данных – это процесс создания описа-
ния конкретной реализации базы данных, размещаемой во вторичной памяти.
Предусматривает описание структуры хранения данных и методов доступа,
предназначенных для осуществления наиболее эффективного доступа к инфор-
мации.
Фаза физического проектирования базы данных предусматривает приня-
тие разработчиком окончательного решения о способах реализации создаваемой
базы. Поэтому физическое проектирование обязательно производится с учетом
всех особенностей используемой СУБД. Между фазами физического и логиче-
ского проектирования всегда имеется определенная обратная связь, поскольку
решения, принятые на этапе физического проектирования с целью повышения
производительности разрабатываемой системы, могут потребовать некоторого
пересмотра логической модели данных.
Ниже приведена структура таблиц, используемых в БД (таблицы 2.13-
2.20).