Автоматизация Автосалона

ПЕРМСКИЙ ГОСУДАРСТВЕННЫЙ ИНСТИТУТ ИСКУССТВА И КУЛЬТУРЫ

ФАКУЛЬТЕТ ДОКУМЕНТАЛЬНО-ИНФОРМАЦИОННЫХ КОММУНИКАЦИЙ

КАФЕДРА ИНФОРМАТИКИ И ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ













Информационная система

«АВТОСАЛОН»







Выполнил: 

студент 3 курса

группы ИР-33

Карпов К.А.



Руководитель:

преподаватель

Нечаев В.Г.



























Пермь  2010

Оглавление

Оглавление

Введение	3

1.Постановка задачи	3

2. Анализ предметной области	3

	2.1. Построение инфологической модели	3

	2.2. Создание даталогической модели	1

	2.2.1. Нормализация таблиц	3




Введение

Целью курсовой работы является разработка реляционной базы данных «Автосалон». 

Для достижения данной цели были поставлены следующие задачи для БД «Автосалон»: 

хранение информации об автомобилях, клиентах, сотрудниках, производителях;

количество проданных автомобилей отдельным сотрудником и автосалоном в целом за определенный период времени;

наличие автомобилей в автосалоне;




1.Постановка задачи

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

	Процесс разработки БД состоял из следующих этапов:

	Начальная стадия

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

	Проектирование и создание БД

	Построение инфологической модели БД.

	Нормализация.

	Построение даталогической модели БД.


2. Анализ предметной области

Для обозначения структуры базы данных определяют сущности предметной области, которые отразятся в базе данных. Анализ предметной области проводится на основе известных сведений о автосалоне. 

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



	 «Автосалон»:

	Автомобили;

	Сотрудники;

	Клиенты;

	Продажа;


2.1. Построение инфологической модели

Выделена стержневая сущность: «Автомобили» ассоциативная сущность «Продажа» с сущностью «Клиент».

Автомобили 1             М  Продажа   М                        1  Клиенты

		М

		1

Сотрудники

Где:

Автомобили – Будет содержать информацию о материальных ценностях. 

Продажа – операции, заключающиеся в продаже автомобиля.

Клиенты - лица, заинтересованные в покупке.

Сотрудники – лица, которые принимают участие в продаже.


В результате анализа были определены следующие сущности с атрибутами:

«Автомобили»:

	Марка;

	№ кузова;

	№ двигателя;

	№ ПТС;

	Цвет;

	Дата выпуска;

	Дата прихода;

Комплектация;

Производитель;

Цена;

«Клиенты»:

Фамилия;

Имя;

Отчество;

Паспортные данные;

Город;

Адрес;

Телефон;













 «Продажа»:

Дата продажи;

Оплата;

Форма оплаты.



 «Сотрудники»

Фамилия;

Имя;

Отчество;

Город;

Адрес;

Телефон;

Должность;



Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ER). С их помощью определяются важные для предметной области объекты (сущности), их свойства (атрибуты) и отношения друг с другом (связи). ER непосредственно используются для проектирования реляционных баз данных. 

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

























Рис.1 ER модель

 




2.2. Создание даталогической модели

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

Для ликвидации избыточности и потенциальной противоречивости данных добавим в таблицу АВТОМОБИЛИ столбец Код автомобиля, в таблицу ПРОДАЖА столбец Код продажи, в таблицу КЛИЕНТЫ столбец Код клиента, в таблицу СОТРУДНИКИ столбец Код сотрудника. Содержимое добавленных столбцов будет однозначно идентифицировать каждую строку таблиц Рис.2.

 





























Рис.2 Логическая модель без нормализации




2.2.1. Нормализация таблиц

Нормализация – это процесс последовательной замены таблицы ее полными декомпозициями до тех пор, пока они все не будут находиться в 5НФ, но достаточно привести к 3НФ. Процедура приведения к 3НФ основывается на том, что единственными функциональными зависимостями в любой таблице должны быть зависимости вида А – К, где К – первичный ключ, а А – некоторый атрибут. Принцип «один факт в одном месте» говорит о том, что не должно существовать в рамках таблицы никаких других функциональных зависимостей. 

		Все построенные таблицы находятся в первой нормальной форме, если каждый столбец неделим и в рамках одной таблицы нет столбцов с одинаковыми по смыслу значениями. (1НФ)

		Первичные ключи однозначно определяют запись и не избыточны, все поля каждой из таблиц зависят от ее первичного ключа. (2НФ)

		Значение любого поля, не входящего в первичный ключ, не зависит от значения другого поля, тоже не входящего в первичный ключ. (3НФ)

Таблица АВТОМОБИЛИ не соответствует 1НФ, т.к. поле производитель может многократно повторяться. Для приведения этой таблицы к нормальной форме создаем таблицу ПРОИЗВОДИТЕЛЬ. В эту таблицу добавляем первичный ключ Код производителя, поле производитель (наименование производителя). Для обеспечения ссылочной целостности в таблицу АВТОМОБИЛИ добавляем внешний ключ Код производителя на таблицу ПРОИЗВОДИТЕЛЬ, идентифицирующий производителя. 

В таблице АВТОМОБИЛИ присутствует поле комплектация (Описание автомобиля), данное поле будет содержать краткое описание автомобиля, для предоставления клиенту данных. Более рационально будет данное поле вынести в отдельную сущность, так данное поле несет большую смысловую нагрузку. И установить у него первичный ключ Код автомобиля.

В таблица ПРОДАЖА присутствует поле форма оплаты, данное поле будет содержать информацию о виде расчета с продавцом (автосалоном). Более рационально будет данное поле вынести в отдельную сущность, так данное поле несет смысловую нагрузку. И установить у него первичный ключ Код формы.

Таблица КЛИЕНТ и таблица СУТРУДНИКИ соответствуют всем нормальным формам.

В результате получилась следующая схема (рис. 3).



	

	

	

	

Рис.3 Логическая модель 

























Рис.3 Инфологическая модель 




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

Даталогическая модель строится для СУБД Interbase

В результате получилась следующая модель. Рис.4



	

	

	

	

	

	

	

	

Рис.4 Даталогическая модель 

2