48
нятого управленческого решения и может быть представлена в виде документов,
письменных и устных сообщений и прочее.
На основании проведения операций покупки или продажи автомобилей
выходной документацией можно считать договор купли-продажи, договор ко-
миссии.
Договор купли-продажи включает в себя условия, по которым компания
продает покупателю автомобиль с определенными характеристиками. Договор
содержит условия передачи имущества, цену товара, порядок расчета и акт при-
ема-передачи по договору купли-продажи.
Договор комиссии - договор, по которому комиссионер принимает на себя
обязанность по поручению комитента совершить от своего имени за вознаграж-
дение реализацию автомобиля. Договор включает в себя информацию о праве
собственности, стоимости автомобиля, сроках поступления на продажу, тесто-
вом использовании автомобиля, порядок выплаты денежных средств в случае
продажи автомобиля и акт приема-передачи по договору комиссии.
Результативной информацией в случае оформления купли-продажи или
договора комиссии является также информирование клиента об итогах продажи,
поступления денежных средств на счет компании, после чего договор считается
полностью выполнен. Компания предоставляет своим клиентам предпродажное
информирование о дополнительных услугах, предоставляемых организацией:
сервисные услуги, услуги комиссии, доставки и продажи. Компания постоянно
информирует клиентов о поступлениях новых автомобилей, рассылает свои
прайс-листы и рекламные афиши.
2.3. Программное обеспечение задачи
2.3.1. Общие положения (дерево функций и сценарий диалога)
В данной работе автоматизации подлежит процесс работы менеджеров по
продажам ООО «АлексАвто». Функционал программы можно разделить на ос-
новной, с помощью которой достигается основная цель автоматизации и слу-
жебный [8]. Дерево функций наглядно демонстрирует разделение данных функ-
ций (рисунок 2.3).
49
Рисунок 2.3 – Дерево функций автоматизированной системы
Основное окно программы предоставляет статистические данные о поку-
пателях, поставщиках, автомобилях на складе, поставках и продажах. На рисун-
ке 2.4 представлен сценарий диалога автоматизированной системы.
Рисунок 2.4 – Сценарий диалога автоматизированной системы
2.3.2. Характеристика базы данных
Концептуальное проектирование базы данных
Концептуальное проектирование базы данных – это процесс создания мо-
дели используемой на предприятии информации, не зависящей от любых физи-
ческих аспектов ее представления.
Первая фаза процесса проектирования базы данных заключается в созда-
нии концептуальной модели данных для анализируемой части предприятия. Эта
модель данных создается на основе информации, записанной в спецификациях
требований пользователей. Концептуальное проектирование базы данных абсо-
лютно не зависит от таких подробностей ее реализации, как тип выбранной це-
левой СУБД, набор создаваемых прикладных программ, используемые языки
50
программирования, тип выбранной вычислительной платформы, а также от лю-
бых других особенностей физической реализации. При разработке концептуаль-
ная модель данных постоянно подвергается тестированию и проверке на соот-
ветствие требованиям пользователей. Созданная концептуальная модель данных
предприятия является источником информации для фазы логического проекти-
рования базы данных [15].
Ниже приведена информация, необходимая для построения концептуаль-
ной модели данных в нашем случае:
название поставщика;
марка автомобиля;
номер;
объем двигателя;
масса;
цвет;
мощность;
адрес поставщика;
телефон;
E-mail;
закупочная цена;
продажная цена;
дата продажи;
фамилия покупателя;
имя покупателя;
отчество покупателя;
паспортные данные покупателя;
адрес покупателя.
На рисунке 2.5 приведена разработанная концептуальная модель данных.
51
Рисунок 2.5 – Концептуальная модель данных
Логическое проектирование базы данных
Следующим этапом проектирования базы данных является ее логическое
проектирование. В основе этого этапа лежит процедура нормализации БД.
Нормализация – это метод создания набора отношений с заданными свой-
ствами на основе требований к данным, установленным в некоторой организа-
ции.
Нормализация представляет собой вариант восходящего подхода к проек-
тированию базы данных, который начинается с установления связей между ат-
рибутами. Однако нормализация также используется и при нисходящем подходе
к проектированию базы данных (который начинается с выявления основных
сущностей и связей) в качестве метода проверки корректности полученного ре-
52
зультата. Нормализация – это формальный метод анализа отношений на основе
их первичного ключа и существующих функциональных зависимостей.
Ненормализованная форма – это таблица, содержащая одну или несколько
повторяющихся групп данных.
Первая нормальная форма – это отношение, в котором все используемые
домены содержат только скалярные значения.
Вторая нормальная форма – это отношение, которое находится в первой
нормальной форме и каждый атрибут которого, не входящий в состав первично-
го ключа, характеризуется полной функциональной зависимостью от этого пер-
вичного ключа.
Третья нормальная форма – это отношение, которое находится в первой и
второй нормальных формах и не имеет не входящих в первичный ключ атрибу-
тов, которые находились бы в транзитивной функциональной зависимости от
этого первичного ключа.
Отношение находится в нормальной форме Бойса-Кодда только тогда, ко-
гда каждая нетривиальная и неприводимая слева функциональная зависимость
обладает потенциальным ключом в качестве детерминанта.
На первоначальном этапе проектирования структуры базы данных всю
информацию сводим в одну таблицу без составных полей и повторяющихся
групп. Эти данные представлены в таблице 2.1.
Таблица 2.1
Ненормализованные данные
Фамилия покупателя
Имя покупателя
Отчество покупателя
Паспортные данные покупателя
Адрес покупателя
Название поставщика
Адрес
Телефон
E-mail
Марка машины
53
Продолжение таблицы 2.1
Номер
V двигателя
Цвет
Мощность
Масса
Цена поставки
Цена продажи
Далее выделяем следующие таблицы:
данные для поставки автомобиля на склад представлены в таблице 2.2;
сведения об автомобиле сведены в таблицу 2.3;
данные о проданных автомобилях сведены в таблицу 2.4;
информация о поставщике представлена в таблице 2.5;
сведения о проданных автомобилях в таблице 2.6;
информация о покупателе представлена в таблице 2.7.
Таблица 2.2
Поставка на склад
Поставщик
Марка
Адрес
Телефон
Цена поставки
Таблица 2.3
Автомобиль
Марка
Цвет
Номер
V двигателя
Масса
Мощность
54
Продолжение таблицы 2.3
Цена
Таблица 2.4
История продаж
Марка автомобиля
Покупатель
Дата продажи
Таблица 2.5
Поставщик
Поставщик
Адрес
Телефон
E-mail
Таблица 2.6
Продажа
Поставщик
Марка автомобиля
Цена продажи
Таблица 2.7
Покупатель
Фамилия покупателя
Имя покупателя
Отчество покупателя
Паспорт
Адрес
Существуют классификации таблиц БД по виду изменений информации,
которая содержится в таблицах, а именно:
55
справочные таблицы – содержат информацию справочного характера,
обладают невысокой степенью изменчивости. Они находятся с операционными
и транзакционными таблицами в отношении 1:М, являясь при этом родитель-
скими таблицами.
операционные таблицы – в них происходит непрерывное или перио-
дическое обновление информации. Они находятся в подчиненном отношении со
справочными. На основании данных операционных таблиц формируются итого-
вые отчеты.
В разрабатываемой БД справочными являются таблицы 2.8-2.10, приве-
денные ниже.
Таблица 2.8
Автомобили
Марка
Модель
Номер кузова
Цвет
Номер двигателя
Модель двигателя
Масса
Цена поставки
Цена продажи
Поставщик
Год выпуска
Транзитный знак
Таблица 2.9
Поставщики
Поставщик
Адрес
E-mail
Телефон
56
Таблица 2.10
Покупатель
Фамилия
Имя
Отчество
Адрес
Паспорт
Дата рождения
ИНН
Телефон
E-mail
К операционным таблицам относятся таблица 2.11 и таблица 2.12, в кото-
рых приведена информация о поступающих на склад автомобилях и сведения о
проданных автомобилях соответственно.
Таблица 2.11
Поставки
Поставщик
Автомобиль
Дата поставки
Таблица 2.12
Продажи
Покупатель
Автомобиль
Транзитный знак
Дата продажи
Рисунок 2.6 иллюстрирует модель логического проектирования базы дан-
ных автосалона «АлексАвто».
57
Рисунок 2.6 – Логическая схема базы данных автосалона «АлексАвто»
Физическое проектирование базы данных
Физическое проектирование базы данных – это процесс создания описа-
ния конкретной реализации базы данных, размещаемой во вторичной памяти.
Предусматривает описание структуры хранения данных и методов доступа,
предназначенных для осуществления наиболее эффективного доступа к инфор-
мации.
Фаза физического проектирования базы данных предусматривает приня-
тие разработчиком окончательного решения о способах реализации создаваемой
базы. Поэтому физическое проектирование обязательно производится с учетом
всех особенностей используемой СУБД. Между фазами физического и логиче-
ского проектирования всегда имеется определенная обратная связь, поскольку
решения, принятые на этапе физического проектирования с целью повышения
производительности разрабатываемой системы, могут потребовать некоторого
пересмотра логической модели данных.
Ниже приведена структура таблиц, используемых в БД (таблица 2.13-
2.20).