Разработка АРМ менеджера по продажам автомобилей в автосалоне

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

 

 

Факультет информационных технологий

Кафедра информационных технологий и телекоммуникаций

 

 

 

 

Курсовая работа

 

по дисциплине «Инструментальные средства разработки корпоративных экономических систем»

 

на тему: «Разработка АРМ менеджера по продажам автомобилей в автосалоне»

 

 

 

Выполнил студент

Петров А.Н

 

Проверила

 

Оценка:_________________

 

 

 

 

Москва, 2013 г.

Оглавление

 

Введение

Целью данной курсовой работы является разработка приложения для учета поступлений и продаж автомобилей в автосалоне.

С помощью созданного приложения работники (менеджеры) автосалона смогут вести учет поступления и реализации автомобилей.

Данное приложение актуально, так как позволит получать пользователю (менеджеру автосалона) всю необходимую информацию о поступлениях и продажах автомобилей в наглядной и понятной ему форме. При этом все манипуляции с данными не потребуют затрат большого количества времени.

В соответствии с поставленной целью определены следующие задачи:

1. Исследование предметной области.
2. Выделение объектов – сущностей и процессов в предметной области.
3. В соответствии с выделенными объектами и процессами предметной области разработка логической модели данных.
4. Создание базы данных.
5. Разработка отдельных объектов базы данных (представлений, хранимых процедур, пользовательских функций, отчетов).
6. Разработка клиентского приложения для созданной БД.

 

1. ) Описание предметной области

Предметная область включает в себя информацию о клиентах, менеджерах автосалона, поставщиках, марках и моделях автомобилей.

Определение требований проекта

В базе данных созданы таблицы для учета поставок и продаж.

Информация о поставщиках включает в себя: название фирмы, телефон, электронный адрес, страну поставщика.

Информация о клиентах включает: ФИО, пол, телефон, e-mail, страну, город.

Информация о моделях содержит: марку, название модели, тип кузова, модификацию, мощность и объем двигателя, год выпуска, цвет и фотографию автомобиля.

Информация о менеджерах включает: ФИО менеджера и его рабочий телефон.

Таблица поставки содержит: название фирмы поставщика, менеджера, дату поставки, модель автомобиля, количество единиц поставки, цену за еденицу поставленного товара и общую сумму поставки.

Таблица продажи соответственно содержит: дату продажи, модель, клиента, менеджера, количество единиц поставки, цену за единицу товара и сумму продажи.

Таблица дополнительная комплектация показывает перечень дополнительных комплектующих.

Таблица дополнительная комплектация к продаже показывает выбранные клиентами дополнительные комплектующие к автомобилю при заказе.

 

 

 

 

С помощью приложения можно сформировать отчеты:

• отчет по поставкам за период;
• отчет по продажам за период.

Программа позволяет вести упрощенный учет автомобилей в автосалоне.

2. ) Инфологическая модель данных

На данном этапе проектирования необходимо выделить основные сущности предметной области, определить их атрибуты, и описать связи между ними.

Основными сущностями предметной области являются: поставщики, клиенты, менеджеры, марки автомобилей, модели, поставки, продажи, дополнительная комплектация и дополнительная комплектация к продаже.

На рисунке (Рис. 2.1) приведена инфологическая модель, где показаны основные отношения между указанными сущностями.

Рис. 2.1 Модель «Сущность-связь»

 

3. ) Логическая модель базы данных

На основе модели «сущность-связь» создается логическая модель данных (Рис. 3.1).

Модель сущности, построенная просто на основе перечисления его атрибутов может не удовлетворять важным требованиям к БД. Это требования целостности данных их непротиворечивости, и минимальности. Эти требования в основном удовлетворяются в случае, когда объекты БД представлены нормализованной форме.

Нормализация предусматривает определение требуемых атрибутов с последующим созданием из них нормализованных таблиц, основанных на функциональных зависимостях между этими атрибутами. Отношение, в котором на пересечении каждой строки и каждого столбца содержится атомарное (или единственное), значение, находится в 1-ой нормальной форме. При этом отношение должно иметь первичный ключ.

Вторая нормальная форма применяется к отношениям с составными ключами, т.е. к таким отношениям, первичный ключ которых состоит из двух или больше атрибутов. Отношение с первичным ключом на основе единственного атрибута всегда находится во 2-ой нормальной форме. Отношение, которое находится в 1-ой нормальной форме и каждый атрибут которого, не входящий в состав первичного ключа, зависит только от полного значения ключа и не зависит ни от какого отдельного атрибута, входящего в состав первичного ключа, имеет 2-ую нормальную форму (каждый неключевой атрибут функционально полно зависит от ключа).

Отношение находится в 3-ей нормальной форме, если оно представлено во 2-ой нормальной форме и не имеет не входящих в первичный ключ атрибутов, которые находились бы в транзитивной функциональной зависимости от этого первичного ключа.

Рис. 3.1 Логическая модель данных

 

Разработанная модель находится в 3-ей нормальной форме:

• атрибуты сущностей являются атомарными (единственными);
• каждый неключевой атрибут функционально полно зависит от первичного ключа;
• в модели отсутствуют транзитивные зависимости неключевых атрибутов от ключа.

 

4. ) Физическая модель данных

 

Физическая модель базы данных представлена на рисунке (Рис. 4.2).

Разрабатываемое приложение носит локальный характер: СУБД, БД и клиентская часть расположены на одном компьютере.

Для создания базы данных была выбрана СУБД Microsoft SQL Server 2008.

Для разработки пользовательского интерфейса была выбрана среда разработки Microsoft Visual Studio 2010, которая также является широко распространенной средой разработки и имеет развитые возможности быстрого создания пользовательских интерфейсов к базам данных, поддерживает все распространенные на данный момент технологии доступа к источникам данных (ADO.NET и т.п.). Помимо перечисленных особенностей, программы, созданные в Visual Studio 2010, являются легко переносимыми и не требуют для своей работы установки дополнительных программ или библиотек.

Выбор среды для создания базы данных.

Visual Studio 2010 включает в себя полный  набор новых и улучшенных функций, упрощающих все этапы процесса  разработки от проектирования до развертывания. Также предоставляет предопределенные коллекции параметров, настраивающие среду разработки (окна, меню и так далее) для обычных сценариев разработки. Даже если используется предопределенная коллекция параметров, можно настраивать интегрированную среду разработки с помощью собственных параметров, таких как шрифты и цвета, форматирование и поведение редактора.

 

 

 

База данных состоит из следующих таблиц:

• Марки – хранит список марок автомобилей (Таблица 4.1, Рис. 4.1);
• Модели – хранит список моделей (Таблица 4.2, Рис. 4.3);
• Поставщики – хранит список поставщиков (Таблица 4.3, Рис. 4.4);
• Клиенты – список клиентов (Таблица 4.4, Рис. 4.5);
• Менеджеры – список менеджеров (Таблица 4.5, Рис. 4.6);
• Поставки – список поставок (Таблица 4.6, Рис. 4.7);
• Продажи – список продаж (Таблица 4.7, Рис. 4.8).
• Дополнительная_комплектация – дополнительные комплектующие к автомобилю(Таблица 4.8, Рис. 4.9);
• Дополнительная_комплектация_к_продаже – проданные дополнительные комплектующие (Таблица 4.9, Рис. 4.10).

Таблица 4.1

Структура таблицы «Марки»

Имя поля	Тип данных	Длина	Краткое описание
ID_марки (Ключевое поле)	int		Порядковый номер
Название	nvarchar	50	Наименование марки

Рис. 4.1. Фрагмент заполненной таблицы «Марки»

Рис. 4.2 Физическая модель данных

Таблица 4.2

Структура таблицы «Модели»

Имя поля	Тип данных	Длина	Краткое описание
ID_модели (Ключевое поле)	int		Порядковый номер
марка	int	50	Номер марки
название	nvarchar	50	Название модели
Фото	image		Фото
Тип_кузова	nvarchar	50	Тип_кузова
Модификация	nvarchar	MAX	Модификация
Мощность	nvarchar	50	Мощность двигателя
Объем_двигателя	nvarchar	50	Объем двигателя
Год_выпуска	nvarchar	10	Год выпуска модели
Цвет	nvarchar	50	Цвет

Рис. 4.3. Фрагмент заполненной таблицы «Модели»

Таблица 4.3

Структура таблицы «Поставщики»

Имя поля	Тип данных	Длина	Краткое описание
ID_поставщика (Ключевое поле)	int		Порядковый номер
Название_фирмы	nvarchar	50	Название_фирмы
Телефон	nvarchar	50	Телефон
e_mail	nvarchar	50	e_mail
страна	nvarchar	50	страна

Рис. 4.4. Фрагмент заполненной таблицы «Поставщики»

Таблица 4.4

Структура таблицы «Клиенты»

Имя поля	Тип данных	Длина	Краткое описание
id_клиента	int		Порядковый номер
Фамилия	nvarchar	50	Фамилия
Имя	nvarchar	50	Имя
Отчество	nvarchar	50	Отчество
пол	nvarchar	10	пол
телефон	nvarchar	50	телефон
e_mail	nvarchar	50	e_mail
страна	nvarchar	50	страна
город	nvarchar	50	город

Рис. 4.5. Фрагмент заполненной таблицы «Клиенты»

Таблица 4.5

Структура таблицы «Менеджеры»

Имя поля	Тип данных	Длина	Краткое описание
id_менеджера	int		Порядковый номер
Фамилия	nvarchar	50	Фамилия
Имя	nvarchar	50	Имя
Отчество	nvarchar	50	Отчество
телефон	nvarchar	10	телефон

Рис. 4.6. Фрагмент заполненной таблицы «Менеджеры»

Таблица 4.6

Структура таблицы «Поставки»

Имя поля	Тип данных	Длина	Краткое описание
Поставщик	int		Код поставщика
Менеджер	int
Дата	date		Дата операции
Модель	int
Количество_ед_поставки	int		Количество
Цена_ед_поставки	money		Цена
Сумма_поставки	money		Цена*Количество