Ирина Эланс

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

Разработка базы данных "Автосервис"

СОДЕРЖАНИЕ

Введение 3

РАЗДЕЛ 1. Разработка базы данных 4

Постановка задачи 4
Анализ предметной области 5

РАЗДЕЛ 2. Моделирование структур данных 7

2.1. Разработка концептуальной модели базы данных 7

2.2. Разработка логической модели данных 9

2.3. Преобразование модели «сущность-связь» в реляционную

модель данных 10

РАЗДЕЛ 3. Проектирование базы данных 12

3.1. Разработка таблиц 12

3.2. Разработка форм для ввода данных 17

3.3. Разработка запросов к базе данных 21

3.4. Разработка отчетов 27

ЗАКЛЮЧЕНИЕ 30

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ 31

ПРИЛОЖЕНИЯ 32

ВВЕДЕНИЕ

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

Объектом курсовой работы является изучение технологий проектирования реляционной БД.

Предмет курсовой работы — изучение принципов разработки реляционных баз данных на примере проектирования и создания базы данных «Автосервис».

Цель проектирования базы данных состоит в отображении процесса ремонтной деятельности малого предприятия

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

определение и анализ предметной области;
разработка концептуальной модели базы данных;
построение таблиц базы данных «Автосервис»;
построение форм, запросов и отчётов данной БД.

Существует огромное количество различных источников информации, касающиеся проектирования реляционных баз данных и их применения. Из всех предложенных ресурсов, были выбраны те, которые подходят для проектирования баз данных в среде OpenOffice.org Base. Так, например, в книгах [2, 7] рассматриваются основные приемы и принципы работы и создании баз данных с помощью Base, входящей в состав OpenOffice.org. В источниках [5, 6, 8] изложены основные сведенья о создании таблиц, форм, запросов и отчётов. В книгах [1, 3, 4] описаны методические рекомендации по проектированию и реализации баз данных.

РАЗДЕЛ 1. Разработка базы данных

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

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

Основные функции БД относятся к учету всех автомобилей, когда-либо находящихся в автосервисе, хранение полной информации о каждом автомобиле (марка, серия и № технического паспорта, № шасси и № двигателя, цвет, год выпуска и т.п.).

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

Администрации автосервиса могут потребоваться следующие данные:

ФИО, серия и № технического паспорта автомобиля, год выпуска и марка производителя;
информация о дате приема данного заказа, с указанием стоимости ремонтных работ, ответственном мастере и дате оплаты заказа;
перечень устраненных неисправностей у автомобиля данного владельца;
ФИО работника автосервиса, устранявшего данную неисправность автомобиля данного владельца и его должность.

Оператор СУБД может вносить следующие изменения:

добавить или изменить информацию о заказах;
добавить или изменить информацию о работнике;
удалить информацию о работнике автосервиса.

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

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

База данных «Автосервис» разработана для администратора и сотрудников автосервиса, осуществляющих прием и оформление заказов на ремонт, и сервисное обслуживание автомобилей.

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

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

Предоставление большой совокупности информации в виде таблиц базы данных.
Формирование различных запросов по:

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

Вывод информации в виде отчетов:

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

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

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

К информации, содержащейся в базе данных, предъявляются требования:

значимости, полноты, достоверности, понятности, эффективности.

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

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

РАЗДЕЛ 2. Моделирование структур данных

2.1. Разработка концептуальной модели базы данных

При построении концептуальной модели БД воспользуемся рекомендациями Карповой И.П. [3]. Как отмечает автор концептуальная модель базы данных — это высокоуровневая объектно-ориентированная модель предметной области, представляющая объектную область в виде набора объектов, обладающих определенными свойствами и находящимися в некоторых отношениях. Основная цель разработки высокоуровневой модели данных заключается в создании модели пользовательского восприятия данных и согласовании большого количества технических аспектов, связанных с проектированием базы данных. Концептуальная модель данных не привязана к конкретной физической реализации баз данных и не зависит от конкретной СУБД. Концептуальная модель создается на основе представлений о предметной области каждого типа пользователей, представляющих собой набор данных, необходимых пользователю для решения своих задач [3, C. 36-38].

Концептуальная модель для базы «Автосервис» проектировалась, как модель «сущность-связь».

Основные концепции модели включают такие понятия: как сущность (объект), отношение (связь), типы сущностей, типы связей и атрибуты [3, C. 36].

Сущность — реальный или представляемый объект, информация о котором должна сохраняться и быть доступна. В диаграммах ER-модели сущность представляется в виде прямоугольника, содержащего имя сущности. Каждая сущность определяется набором атрибутов.

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

Между сущностями устанавливаются связи.

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

Таким образом, из описания предметной области извлечем все типы

сущностей:

– Заказчики;

– Заказы;

– Мастера;

– Перечень работ.

Каждой из сущностей определим свой набор атрибутов.

Сущность Заказчик определяется следующим набором атрибутов:

код заказчика;
Ф.И.О.;
паспортные данные;
серия и № тех. паспорта;
марка автомобиля;
цвет;
№ шасси;
№ двигателя;
год выпуска.

Атрибуты сущности Заказы определяются следующим образом:

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

Сущность Мастера документируется на основании следующих атрибутов:

№ мастера;
ФИО;
должность на данном предприятии;

Сущность Перечень работ определяется следующим набором атрибутов:

код запроса;
код работ;
деталировка.

В соответствии с моделью предметной области, представляется следующая концептуальная модель базы данных «Автосервис» (рис. 1).

Рис.1 Концептуальная модель базы данных «Автосервис».

2.2. Разработка логической модели данных

Преобразование локальной концептуальной модели данных в локальную логическую модель заключается в удалении из концептуальных моделей нежелательных элементов и преобразование полученных моделей в локальные логические модели [4, C. 569–568]. К нежелательным элементам относятся [1, C. 50]:

– связи типа «многие-ко-многим»;

– рекурсивные связи;

– связи с атрибутами.

В созданной концептуальной модели вышеперечисленных нежелательных элементов не обнаружено.

Логическая схема данных приведена на рис.2.

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

Преобразование модели «сущность-связь» в реляционную модель данных

Преобразование модели «сущность-связь» в реляционную модель данных

осуществляется путем последовательного выполнения ряда шагов [1, C. 56]:

– каждой сущности ставится в соответствие отношение реляционной модели данных;

– каждый атрибут сущности становится атрибутом соответствующего отношения;

– первичный ключ сущности становится первичным ключом соответствующего отношения. Атрибуты, входящие в первичный ключ отношения, автоматически получают свойство обязательности (NOT NULL). В каждое отношение, соответствующее подчиненной сущности, добавляется набор атрибутов основной сущности, являющейся первичным ключом основной сущности. В отношении, соответствующем подчиненной сущности, этот набор атрибутов становится внешним ключом.

Этот процесс рассмотрен ниже.

РАЗДЕЛ 3. Проектирование базы данных

Разработка таблиц

Таблица — это объект, предназначенный для хранения данных в виде записей (строк) и полей (столбцов) [2, С. 3].

В программе OpenOffice.org Base предусмотрено три различных способа создания таблицы базы данных:

создание таблиц в режиме дизайна;
использование мастера для создания таблицы;
создание представления.

В данной работе таблицы создавались с помощью мастера.

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

Разработка таблиц базы данных производится последовательно:

Определение необходимых таблиц и полей.

Таблица является основой базы данных, поэтому при разработке таблиц рекомендуется руководствоваться следующими основними принципами [2, C. 7]:

сведения не должны дублироваться в таблице или между таблицами;
данные, хранящиеся только в одной таблице, обновляются только в этой таблице;
каждая таблица должна содержать информацию только на одну тему.

Каждая таблица содержит сведения по конкретной теме, а каждое поле в таблице содержит конкретный факт по теме таблицы. Для каждой таблицы в базе данных необходимо определить свойства содержащихся в них.

База данных «Автосервис» содержит четыре таблицы:

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

код заказа (тип поля – целое [Integer], длинна – 10, обязательное);

Ф.И.О. (тип поля – текстовое [VARCHAR], длинна – 50, обязательное);
паспортные данные (тип поля – текстовое [VARCHAR], длинна – 100, обязательное);
серия и № тех. паспорта (тип поля – текстовое [VARCHAR], длинна – 15, обязательное);
Марка автомобиля (тип поля – текстовое [VARCHAR], длинна – 100, обязательное);
цвет автомобиля (тип поля – текстовое [VARCHAR], длинна – 100, не обязательное);
№ шасси (тип поля – текстовое [VARCHAR], длинна – 100, не обязательное);
№ двигателя (тип поля – числовое [NUMERIC], длинна – 100, не обязательное);
год выпуска (тип поля – дата [DATA], обязательное).

Рис. 3. Таблица Заказчики.

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

код заказа (тип поля – целоe [Integer], длинна – 10, обязательное);

код заказчика (тип поля – текстовое [VARCHAR], длинна – 10, не обязательное);
дата заказа (тип поля – дата [DATA], не обязательное);
общая калькуляция ремонтных работ (тип поля – десятичное [DECIMAL], длинна – 100, не обязательное);
ответственный мастер (тип поля – целое [Integer], длинна – 10, не обязательное);
дата оплаты (тип поля – дата [DATA], не обязательное);
дата приема (тип поля – дата [DATA], не обязательное);
замечания (тип поля – тестовое [VARCHAR], длинна – 100, не обязательное).

Рис. 4. Таблица Заказы.

Таблица Ремонтные работы (рис. 5) предназначена для описания всех видов ремонтных работ, которые были выполнены на данном предприятии.

Данная таблица содержит следующие атрибуты:

код работ (тип поля – целое [Integer], длинна – 10, обязательное);
код заказа (тип поля – целое [Integer], длинна – 10, обязательное);
деталировка (тип поля – текстовое [VARCHAR], длинна – 100, не обязательное).

Рис. 5. Перечень работ.

Мастера (рис. 6). Таблица мастера предназначена для ввода информации о сотрудниках. Данная таблица содержит следующие атрибуты:

№ мастера (тип поля – целое [Integer], длинна – 10, обязательное);

Ф.И.О. мастера (тип поля – текстовое [VARCHAR], длинна – 100, не обязательное);
должность (тип поля – текстовое [VARCHAR], длинна – 100, не обязательное).

Рис. 6. Мастера.

Установление первичных ключей.

Определим, для каждой сущности первичный ключ, при этом надо учитывать, что сильные сущности имеют только одно ключевое поле, а слабые — столько же, сколько и связей. При выборе первичного ключа будем руководствоваться правилами [3, C. 46]:

– ключ должен содержать минимальный набором атрибутов;

– использовать следует тот ключ, вероятность изменения значений которого минимальна;

– значение ключа должно иметь минимальную длину.

Исходя из вышесказанного, у имеющихся сущностей определим такие ключевые поля:

сущность Заказчики имеет ключевое поле Код заказчика;
сущность Заказы определяется ключом Код заказа;
сущность Мастера имеет ключевое поле № мастера;
сущность Ремонтные работы определяется ключом Код запроса;

Формирование связей между таблицами.

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

OpenOffice.org BASE поддерживает четыре типа отношений между таблицами [2, С. 31]:

– один-к-одному (каждая запись в одной таблице соответствует только одной записи в другой таблице);

– один-ко-многим (каждая запись в одной таблице соответствует многим записям в другой таблице);

– много-к-одному (аналогична записи «один-ко-многим);

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

Связи, установленные в БД «Автосервис» уже были представленны в предыдущем разделе на рис. 2.

Разработка форм ввода информации

Форма — объект, предназначенный для ввода, редактирования и просмотра табличных данных в удобном виде.

Формы содержат так называемые элементы управления, с помощью которых осуществляется доступ к данным в таблицах. Элементами управления являются текстовые поля для ввода и правки данных, кнопки, флажки, переключатели, списки, надписи. Создание форм, содержащих необходимые элементы управления, существенно упрощает процесс ввода данных и позволяет предотвратить ошибки.

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

OpenOffice.org Base предлагает несколько способов создания форм. Самым простым из них является использование средств автоматического создания форм на основе таблицы или запроса [6].

Для базы данных «Автосервис» предусмотрены четыре простые формы и три субформы.

Примеры простых форм приведены на рис.7-10.

Рис.7. Форма Заказчик.

Рис.8. Форма Заказы.

Рис.9. Перечень работ.

Рис.10. Мастера.

Составная форма содержит главную форму и подчиненную ей форму — субформу. Субформа — это по своему содержанию та же форма, но используемая не самостоятельно, а загружаемая всегда из какой-либо формы при открытии или создании документа. В субформе можно делать практически все то же, что и в форме, за тем исключением, что нельзя вставить в нее другую субформу.

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

Благодаря составным формам появляется возможность одновременно заполнять разные таблицы.

Примеры субформ представлены на рис. 11-13.

Рис. 11. Форма Заказчик с субформой Заказы.

Форма Заказчик с субформой Заказы — обеспечивает ввод необходимых данных для идентификации заказчика и просмотра выполненных работ по данному заказу. Эта форма позволяет вносить информацию в таблицы Заказчик и Заказы.

Рис. 12. Форма Заказы с субформой Ремонтные работы.

Эта форма позволяет вносить информацию в таблицы Заказы и Ремонтные работы.

Рис. 13. Форма Мастера с субформой Заказы.

Форма Мастера с субформой Заказы позволяет контролировать выполнения работ конкретным мастером.

Разработка запросов к базе данных

Запрос — объект, позволяющий получить нужные данные из одной или нескольких таблиц.

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

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

По соответствующему запросу можно получить отсортированные и отфильтрованные нужным образом данные. Запросы также можно использовать в качестве источников записей для форм, отчетов и страниц доступа к данным [1].

Существует несколько типов запросов [8]:

Запрос на выборку. Запрос на выборку является наиболее часто используемым типом запроса. Запросы этого типа возвращают данные из одной или нескольких таблиц и отображают их в виде таблицы, записи в которой можно обновлять (с некоторыми ограничениями). Запросы на выборку можно также использовать для группировки записей и вычисления сумм, средних значений, подсчета записей и нахождения других типов итоговых значений.
Запрос с параметрами. Запрос с параметрами — это запрос, при выполнении отображающий в собственном диалоговом окне приглашение ввести данные, например условие для возвращения записей или значение, которое требуется вставить в поле. Запросы с параметрами удобно использовать в качестве основы для форм, отчетов и страниц доступа к данным.
Перекрестные запросы. Перекрестные запросы используют для расчетов и представления данных в структуре, облегчающей их анализ. Перекрестный запрос подсчитывает сумму, среднее, число значений или выполняет другие статистические расчеты, после чего результаты группируются в виде таблицы по двум наборам данных, один из которых определяет заголовки столбцов, а другой заголовки строк.
Запрос на изменение. Запросом на изменение называют запрос, который за одну операцию изменяет или перемещает несколько записей. Существует четыре типа запросов на изменение: на удаление записи, на обновление записи, на добавление записей, на создание таблицы.
Запрос SQL. Запрос SQL — это запрос, создаваемый при помощи инструкций SQL. Язык SQL (Structured Query Language) используется при создании запросов, а также для обновления и управления реляционными базами данных. Когда пользователь создает запрос в режиме конструктора запроса, автоматически создается эквивалентная инструкцию SQL. Фактически, для большинства свойств запроса, доступных в окне свойств в режиме конструктора, имеются эквивалентные предложения или параметры языка SQL, доступные в режиме SQL. При необходимости пользователь имеет возможность просматривать и редактировать инструкции SQL в режиме SQL. После внесения изменений в запрос в режиме SQL его вид в режиме конструктора может измениться.

OpenOffice.org BASE поддерживает не все рассмотренные типы запросов. Base, входящей в состав OpenOffice.org поддерживает такие запросы, как: запрос на выборку, запрос с параметрами и запросы SQL.

В разработанной базе данных было построено восемь различных по типам запросов:

интергальные запроси: «Количество заказов за определенный месяц», «Количество заездов на автосервис», «Общая сумма калькуляции за 2012 год»;
запросы на выборку: «Марки ремонтируемых авто», «Неоплаченные заказы с 2012», «Общая сумма не оплаты», «Общая сумма оплаты», «Процентное соотношение оплаты».

Детальнее рассмотрим два из них:

Запрос «Количество заказов за определённый месяц» (рис. 14).

Для его построения были использована таблица Заказы, из которой были выбраны такие атрибуты, как: Код заказа, Дата заказа. В поле Дата заказа был вписан критерий, который позволяет отобрать нужные данные из множества всей информации о датах заказов.

Данный запрос при выполнении дает информацию о всех заказах за определённый месяц.

Рис. 14. Запрос «Количество заказов за определённый месяц».

Результат выполнения данного запроса представлен на рис. 15.

Рис. 15. Результат выполнения запроса «Количество заказов за определённый месяц».

Запрос «Количество заездов на автосервис» (рис. 16).

Для его построения были использованы таблицы: Заказчик и Заказы. Из таблицы Заказчик бил выбран атрибут Коз заказчика, из таблицы Заказы выбираем аналогичный атрибут. В поле таблицы Заказы выбираем функцию количество. В результате, данный запрос при выполнении дает информацию о количестве заездов каждым заказчиком на автосервис.

Рис. 16. Запрос «Количество заездов на автосервис».

Результат выполнения данного запроса представлен на рис. 17.

Рис. 17. Результат выполнения запроса «Количество заездов на автосервис».

Результаты выполнения остальных запросов представлены на рис. 18-22.

Рис. 18. Результат выполнения запроса «Марки ремонтируемых автомобилей».

Рис. 19. Результат выполнения запроса «Общая калькуляция за 2012 год».

Рис. 20. Результат выполнения запроса «Неоплаченные заказы».