Автотехцентр

 

Содержание 

Введение…………………………………………………………………………4

1. Проектирование базы данных……………………………………………..5
1. Описание предметной области………………………………………...5
2. Инфологическая модель базы данных………………………………...6
3. Даталогическая модель базы данных………………………………….7
4. Стратегия резервного копирования и восстановления……………….9
2. Реализация базы данных…………………………………………………12
1. Характеристика используемой СУБД………………………………...12
2. Создание структуры базы данных……………………………………15
1. База данных и таблицы…………………………………………..15
2. Создание индексов……………………………………………….19
3. Создание представлений……………………………………………....21
1. Однотабличный запрос на выборку по условиям……………...21
2. Многотабличный запрос………………………………………....22
3. Запрос с использованием подзапроса.............................................22
4. Итоговый запрос……………………………………………….....23
4. Примеры запросов на модификацию данных………………………..24
1. Простые запросы…………………………………………………24
2. Запросы с использованием подзапросов………………………..26
5. Описание триггеров…………………………………………………....28
6. Создание пользователей и назначение привилегий………………….32

Заключение………………………………………………………………….37

Список использованной литературы……………………………………...38

Приложение 1. Пример инфологической модели………………………...39

 

Введение

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

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

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

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

 

1. Проектирование базы данных
1. Описание предметной области

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

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

В данной базе данных будут храниться следующие таблицы:

1. Клиенты (Код_клиента, Фамилия, Имя, Отчество, Марка_машины, Телефон, Адрес)
2. Специалисты (Код_специалиста, Фамилия, Имя, Отчество,  Должность)
3. Ремонт (Код_ремонта, код_договора, Стоимость_ремонта)
4. Договор (Код_договора, Код_специалиста, Код_клиента, Код_ремонта,  Дата_ремонта, Время_ремонта, Стоимость_ремонта )

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

База данных будет выполнять следующие функции:

1) Хранение информации о клиентах;

2) Хранение информации о специалистах;

3) Учет, выполняемых работ.

 

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

Инфологическая модель базы данных представляет собой описание объектов (сущностей), с набором атрибутов  и связей между ними, которые выявляются в процессе исследования как входных, так и выходных данных. Она предназначается для структурного образования предметной области, с ориентированием на информационное внимание пользователей, разрабатываемой системы. Самая распространенная модель в инфологическом моделировании это модель "сущность-связь", к главным компонентам её относятся - сущности и связи.  Модель сущность-связь (ER-модель) (англ. entity-relationshipmodel, ERM) — модель данных, позволяющая описывать концептуальные схемы предметной области. ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями.

Выделим основные сущности:

• сущность «Клиенты»;
• сущность «Специалисты»;
• сущность «Договор»;
• сущность «Ремонт»;

Сущность «Клиенты»  содержит информацию обо всех клиентах. Отдельный экземпляр этой сущности содержит информацию о каждом конкретном клиенте. Договора заключаются клиентом, поэтому вводится сущность «Договор». Каждый экземпляр сущности «Договор» содержит информацию о конкретном договоре. Каждым клиентом может быть оформлено несколько договоров. Сущность «Специалисты» содержит информацию о людях, которые осуществляют ремонт попредоставлении договора. Каждому специалисту может быть предоставлено несколько договоров, но у каждого договора  только один специалист. Специалист является ответственным за ремонт машины. У каждого ремонта один ответственный. В каждом договоре прописывается один ремонт, и каждый ремонт выполняется по одному договору.

Связи с этим имеются следующие связи:

• Договор - клиент: «один-ко-многим»;
• Клиент – специалист: «один-ко-многим»;
• Договор – ремонт: «один-к-одному»

Определяются  ключи – уникальные идентификаторы экземпляров каждой сущности: для сущности «Клиенты» – это Код клиента, для сущности «Специалиста» – Код специалиста, для сущности «Договор» – Код договора, для сущности «Ремонт» - Код ремонта.

 

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

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

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

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

1. Клиенты (Код_клиента, Фамилия, Имя, Отчество, Марка_машины, Телефон, Адрес) (рисунок 1.3.1);

Рисунок 1.3.1 – Таблица  «Клиенты»

2. Специалисты (Код_специалиста, Фамилия, Имя, Отчество,  Должность) (рисунок 1.3.2);

Рисунок 1.3.2 –  Таблица «Специалисты»

3. Ремонт (Код_ремонта, код_договора, Стоимость_ремонта) (рисунок 1.3.3);

Рисунок 1.3.3 –  Таблица «Ремонт»

4. Договор (Код_договора, Код_специалиста, Код_клиента, Код_ремонта,  Дата_ремонта, Время_ремонта, Стоимость_ремонта ) (рисунок 1.3.4)

Рисунок 1.3.4 –  Таблица «Договор»

 

4. Стратегия резервного копирование и восстановления

Резервное копирование  – важнейшая задача системного администратора баз данных. Резервное копирование и восстановление – две неразрывно связанные задачи. Резервное копирование базы данных является одной из наиболее важных задач администратора баз данных (DBA -Databaseadministrator). Имея файлы резервной копии и тщательно планируя восстановление после аварии, DBA может восстанавливать систему в случае отказа. DBA несет ответственность за поддержку системы в работоспособном состоянии, насколько это возможно, и за максимально быстрое восстановление ее работы в случае отказа системы. Простой системы может доставлять неудобства и приносить большие убытки. Поэтому важно как можно быстрее восстановить базу данных и вернуть ее к работе. Здесь может компонент резервного копирования и восстановления SQL Server.

Операции резервного копирования  и восстановления  связаны друг с другом и предполагают сохранение информации базы данных для использования в будущем – аналогично операциям резервного копирования и восстановления, которые могут выполняться операционной системой. При резервном копировании данные копируются из базы данных и сохраняются в другом месте. Резервное копирование операционной системы и резервное копирование базы данных отличаются в том, что в первом случае происходит сохранение отдельных файлов, а во втором – сохранение всей базы данных. Обычно база данных совместно используется многими пользователями, в то время как многие файлы операционной системы принадлежат отдельным пользователям. Тем самым при резервном копировании базы данных создается резервная копия данных сразу всех пользователей. Поскольку SQL Server предназначен для максимально возможной непрерывной эксплуатации, процесс резервного копирования может выполняться во время работы базы данных и даже в то время, как пользователи осуществляют доступ к базе данных.

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

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

Для проектируемой базы данных будем использовать простую модель восстановления. Данная модель будет включать только полные резервные копии. Копию будем создавать на дисковом устройстве. Создание полной резервной копии проектируемой базы данных через запрос будет выглядеть так:

USE master;

GO

BACKUP DATABASE Автотехцентр

TO DISK='D:\backup\Автотехцентр.bak';