ПЕРМСКИЙ ГОСУДАРСТВЕННЫЙ ИНСТИТУТ ИСКУССТВА И КУЛЬТУРЫ
ФАКУЛЬТЕТ ДОКУМЕНТАЛЬНО-ИНФОРМАЦИОННЫХ КОММУНИКАЦИЙ
КАФЕДРА ИНФОРМАТИКИ И ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ
Информационная система
«АВТОСАЛОН»
Выполнил:
студент 3 курса
группы ИР-33
Карпов К.А.
Руководитель:
преподаватель
Нечаев В.Г.
Пермь 2010
Оглавление
Оглавление
Введение.. 3
1.Постановка задачи.. 3
2. Анализ предметной области.. 3
2.1. Построение инфологической модели. 3
2.2. Создание даталогической модели. 1
2.2.1. Нормализация таблиц. 3
Введение
Целью курсовой работы является разработка реляционной базы данных «Автосалон».
Для достижения данной цели были поставлены следующие задачи для БД «Автосалон»:
· хранение информации об автомобилях, клиентах, сотрудниках, производителях;
· количество проданных автомобилей отдельным сотрудником и автосалоном в целом за определенный период времени;
· наличие автомобилей в автосалоне;
1.Постановка задачи
Объем информации, циркулирующей во всех отраслях деятельности человека очень быстро растет. Информация и данные должны быть организованы так, чтобы ценность их была по возможности максимальной. Перерабатывать большой объем информации в малые сроки практически невозможно без специальных средств обработки информации. Тем более, что хранить данные в файлах ЭВМ дешевле, чем на бумаге. Особое внимание, при разработке БД, следует уделять тому, чтобы информация, хранящаяся в ней могла быть широко использована, изменяема и легко доступна.
Процесс разработки БД состоял из следующих этапов:
Начальная стадия
1. Анализ предметной области.
Проектирование и создание БД
1. Построение инфологической модели БД.
2. Нормализация.
3. Построение даталогической модели БД.
2. Анализ предметной области
Для обозначения структуры базы данных определяют сущности предметной области, которые отразятся в базе данных. Анализ предметной области проводится на основе известных сведений о автосалоне.
Сбор необходимой информации, ее анализ и структурирование помогли создать модель предметной области. Модель включает в себя объекты, информация о которых храниться в БД.
«Автосалон»:
· Автомобили;
· Сотрудники;
· Клиенты;
· Продажа;
2.1. Построение инфологической модели
Выделена стержневая сущность: «Автомобили» ассоциативная сущность «Продажа» с сущностью «Клиент».
Автомобили 1 М Продажа М 1 Клиенты
М
1
Сотрудники
Где:
Автомобили
– Будет содержать информацию о материальных ценностях.
Продажа
– операции, заключающиеся в продаже автомобиля.
Клиенты
- лица, заинтересованные в покупке.
Сотрудники
– лица, которые принимают участие в продаже.
В результате анализа были определены следующие сущности с атрибутами:
«Автомобили»:
· Марка;
· № кузова;
· № двигателя;
· № ПТС;
· Цвет;
· Дата выпуска;
· Дата прихода;
· Комплектация;
· Производитель;
· Цена;
«Клиенты»:
· Фамилия;
· Имя;
· Отчество;
· Паспортные данные;
· Город;
· Адрес;
· Телефон;
«Продажа»:
· Дата продажи;
· Оплата;
· Форма оплаты.
«Сотрудники»
· Фамилия;
· Имя;
· Отчество;
· Город;
· Адрес;
· Телефон;
· Должность;
Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ER). С их помощью определяются важные для предметной области объекты (сущности), их свойства (атрибуты) и отношения друг с другом (связи). ER непосредственно используются для проектирования реляционных баз данных.
На основе объектной модели создали ER модель. Все объекты преобразовали в сущности, а характеристики объектов в их свойства. Связи между объектами реализовали в связи между сущностями.
|
||
2.2. Создание даталогической модели
После создания инфологической модели можно переходить к созданию даталогической модели. Структура БД должна состоять из нормализованных таблиц или отношений. Процесс нормализации имеет своей целью устранение избыточности данных и заключается в приведении к нормальной форме.
Для ликвидации избыточности и потенциальной противоречивости данных добавим в таблицу АВТОМОБИЛИ
столбец Код автомобиля
, в таблицу ПРОДАЖА
столбец Код продажи
, в таблицу КЛИЕНТЫ
столбец Код клиента
, в таблицу СОТРУДНИКИ
столбец Код сотрудника
. Содержимое добавленных столбцов будет однозначно идентифицировать каждую строку таблиц Рис.2.
|
2.2.1. Нормализация таблиц
Нормализация – это процесс последовательной замены таблицы ее полными декомпозициями до тех пор, пока они все не будут находиться в 5НФ, но достаточно привести к 3НФ. Процедура приведения к 3НФ основывается на том, что единственными функциональными зависимостями в любой таблице должны быть зависимости вида А – К, где К – первичный ключ, а А – некоторый атрибут. Принцип «один факт в одном месте» говорит о том, что не должно существовать в рамках таблицы никаких других функциональных зависимостей.
· Все построенные таблицы находятся в первой нормальной форме, если каждый столбец неделим и в рамках одной таблицы нет столбцов с одинаковыми по смыслу значениями. (1НФ)
· Первичные ключи однозначно определяют запись и не избыточны, все поля каждой из таблиц зависят от ее первичного ключа. (2НФ)
· Значение любого поля, не входящего в первичный ключ, не зависит от значения другого поля, тоже не входящего в первичный ключ. (3НФ)
Таблица АВТОМОБИЛИ не соответствует 1НФ, т.к. поле производитель
может многократно повторяться. Для приведения этой таблицы к нормальной форме создаем таблицу ПРОИЗВОДИТЕЛЬ. В эту таблицу добавляем первичный ключ Код производителя
, поле производитель
(наименование производителя). Для обеспечения ссылочной целостности в таблицу АВТОМОБИЛИ добавляем внешний ключ Код производителя
на таблицу ПРОИЗВОДИТЕЛЬ, идентифицирующий производителя.
В таблице АВТОМОБИЛИ присутствует поле комплектация
(Описание автомобиля), данное поле будет содержать краткое описание автомобиля, для предоставления клиенту данных. Более рационально будет данное поле вынести в отдельную сущность, так данное поле несет большую смысловую нагрузку. И установить у него первичный ключ Код автомобиля
.
В таблица ПРОДАЖА присутствует поле форма оплаты
, данное поле будет содержать информацию о виде расчета с продавцом (автосалоном). Более рационально будет данное поле вынести в отдельную сущность, так данное поле несет смысловую нагрузку. И установить у него первичный ключ Код формы
.
Таблица КЛИЕНТ и таблица СУТРУДНИКИ соответствуют всем нормальным формам.
В результате получилась следующая схема (рис. 3).
|
||||
|
||||
На даталогическом этапе проектирования все названия таблиц и их поля записываются на латинице. С определение доменов – следующий этап проектирования – определение доменов (типов) данных, хранящихся в столбцах таблиц. Параллельно с определением типа необходимо сформулировать ограничения целостности, связанные с типом, - перечень допустимых значений типа. Исходя из особенностей данных и их функционального назначения, требуется задать способ представления и границы возможных значений для каждого из столбцов таблиц. Необходимо определить данные, каких типов должны храниться в столбцах и какова их максимальная длинна. Следующий важный момент – задание для столбцов значений по умолчанию. Значение по умолчанию впоследствии будет автоматически вводиться в указанный столбец для каждой строки таблицы. Далее в каждой таблице должны быть столбцы, которые обязательно должны быть заполнены при создании отдельной строки таблицы. Также устанавливается размер и тип полей.
Даталогическая модель строится для СУБД Interbase
В результате получилась следующая модель. Рис.4
|