Проектирование БД центра по продаже автомобилей.

ВВЕДЕНИЕ
В настоящее время рынок продаж автомобилей можно считать достаточно развитым, но вместе с тем развитие его не остановлено и продолжает набирать темпы. Существующие центры могут активно вести продажи не только готовых автомобилей, но составляющих узлов автомобильной техники.
Тенденции, складывающиеся на рынке, приводят к тому, что в целях повышения эффективности бизнеса и увеличения его прибыльности менеджерам и владельцам центров продаж необходимо решать задачи организации реального полномасштабного управления, что добавляет актуальности к реализуемому проекту.
Целью курсового проекта ставится закрепление теоретических знаний и навыков проектирования баз данных, полученных при изучении курса «Базы данных», а также проектирование системы учета движения автомобилей, «проходящих» через центр продажи.
Весь проект разделяется на фазы:
Анализ предметной области. На этой фазе предполагается использование одного из методов анализа, в частности объектно-ориентированного. Для этого метода характерно использование различного рода диаграмм, описывающих предметную область а объектно-ориентированном языке. В курсовом проекте, для анализа, будут использоваться диаграммы Use Case;
Проектирование системы. На этой фазе проводится проектирование физическое структуры базы данных, разработка и реализация интерфейса в среде выбранной СУБД, а также описание базы данных на языке моделей «сущность-связь», для описания системы на языке диаграмм используются диаграммы Буча и описание интерфейса пользователя при пользовании программным продуктом.

1.АНАЛИТИЧЕСКАЯ ЧАСТЬ
1.1.Описание предметной области. Постановка задачи.
Любой центр продаж в современном мире обслуживается определенным кругом лиц. Существующее информационное обеспечение призвано облегчить труд людей в различных направлениях. Спроектированная база данных имеет ту же задачу, а именно обеспечить более качественный учет товара (автомобилей) внутри центра.
Любая информация характеризуется некоторыми свойствами, и наш случай не исключение. Чтобы сохранить ценность информации и, непосредственно саму информацию, в СУБД организован доступ к предоставляемым функциям системы посредством авторизации. С использованием этого доступ к базе данных определен некоторым кругом лиц. Кроме того, после авторизации, предоставить доступ ко всем возможностям системы было бы абсолютно неправильно, поэтому в системе предусматривается такое понятие как «группа пользователей». Таким образом, каждый сотрудник, принадлежащий к одной из групп, будет иметь определенный функционал в системе. Например: консультирующему персоналу (продавцам) нет необходимости видеть историю заказов, а также отчеты разного характера (отчеты могут носить конфиденциальный характер).
В рамках проектируемой СУБД предполагается следующий механизм организации работы центра: клиент подает заявку (делает заказ) на интересующие его автомобили. На этом шаге он ведет переговоры с продавцом, либо с менеджером центра, что означает, что они будут иметь доступ к оформлению заявок. Заказ клиента может включать от одного до нескольких автомобилей. Каждый автомобиль регистрируется в системе как отдельная единица, поскольку по каждому автомобилю собирается максиму информации (номера двигателя и кузова, год, марка, цвет и пр.).
Поступление новых партий автомобилей в центр происходит на основании заказов клиентов, а также на основании спроса на автомобили с учетом объемов прошлых продаж. Продажа возможна только после постановки автомобиля на учет. На этом этапе выставляется цена на автомобиль, исходя из закупочной цены. Этим занимается менеджер центра. Система построена таким образом, что в один приход можно включить несколько автомобилей. Приход закрепляется за некоторым поставщиком.
Продажа автомобиля может также быть сделана продавцом, либо менеджером. Факт продажи может содержать несколько автомобилей и закрепляется за клиентом (покупателем) центра продажи.
В базе данных предусмотрена группа пользователей «Администраторы». Лица этой группы имеют доступ ко всей системе в целом, что обусловлено их задачей контролировать работоспособность всех узлов системы.
Группа пользователей «Руководители» характеризуется тем, что для нее наиболее важным представляется контроль выходной информации отчетов системы, поскольку именно отчеты о работе систем, об объемах продаж, о рентабельности центра позволяют принять единственно верное решение, которое позволит выжить центру продаж в условиях жесткой конкуренции.
Все вышесказанное в этом пункте можно схематично представить в виде диаграмм анализа UML Use Case. Это позволит наглядно отобразить поведение системе с точки зрения конечного пользователя.

СОДЕРЖАНИЕ
ВВЕДЕНИЕ 3
1.АНАЛИТИЧЕСКАЯ ЧАСТЬ 5
1.1.Описание предметной области. Постановка задачи. 5
1.2.Выбор средств/методологии проектирования. Выбор СУБД. 9
1.3.Построение инфологической (концептуальной) модели предметной области. 11
1.4.Проектирование логической структуры базы данных. 13
1.5.Ограничения целостности. Контроль целостности для каждого из ограничений. 16
2.ПРОЕКТНАЯ ЧАСТЬ 18
2.1.Проектирование физической структуры базы данных. 18
2.2.Организация ввода и корректировки данных в БД. 19
2.3.Информационные потребности пользователей и выбор способов их реализации. 19
2.4.Разработка интерфейса. 22
ЗАКЛЮЧЕНИЕ 23
СПИСОК ЛИТЕРАТУРЫ 25

СПИСОК ЛИТЕРАТУРЫ
1. Лешек А. Мацяшек Анализ требований и проектирование систем. Разработка информационных систем с использованием UML Москва, Санкт-Петербург, Киев: Издательский дом «Вильямс», 2002. 428 с.
2. Гради Буч Объектно-ориентированный анализ и проектирование. Второе издание. Перевод с английского под редакцией И. Романовского и Ф. Андреева.