Информационная система "Станция технического обслуживания автомобилей"
Дипломная работа - Компьютеры, программирование
Другие дипломы по предмету Компьютеры, программирование
?Д.
При поддержке целостности данных обеспечивается правильность ссылок между таблицами.
Таблица 4.2.1 Ключи
ТаблицаКлючТип ключаKlientId_клиентаprimaryzakazId_заказаprimarydogovorId_договораprimaryVid_rabotId_типа_заказаprimarydogovorId_клиентаregularzakazId_клиентаregular
.9 Нормализация отношений
Нормализация - это разбиение таблицы на две или более, обладающих лучшими свойствами при включении, изменении и удалении данных.
В теории нормализации существует пять нормальных форм таблиц. Эти формы предназначены для уменьшения избыточной информации от первой до пятой нормальной формы. Поэтому каждая последующая НФ должна удовлетворять требованиям предыдущей формы и некоторым дополнительным условиям.
Проведем нормализацию имеющихся сущностей.
Таблица в первой НФ требует, чтобы все значения всех атрибутов были атомарны. Другими словами, каждый атрибут отношения должен хранить одно-единственное значение и не являться ни списком, ни множеством значений.
Все таблицы находятся в первой нормальной форме, так как все атрибуты в них атомарны.
В контексте БД Ремонт автомобилей данные понятия являются атомарными, и их деление на составные части не имеет смысла, т.к. только внесет в БД излишнюю громоздкость.
Таким образом, можно сказать, что все таблицы находятся в первой нормальной форме.
Таблица находится во второй НФ, если она удовлетворяет условиям первой НФ, и каждый не первичный атрибут полностью функционально зависит от ключа. Все таблицы находятся во второй нормальной форме, так как в них отсутствуют составные ключи.
Таблица находится в третьей НФ, если она удовлетворяет условиям второй НФ, и каждый не первичный атрибут не транзитивно зависит от ключа.
Другими словами чтобы привести отношение к 3НФ, необходимо устранить функциональные зависимости между неключевыми атрибутами отношения. Другими словами, факты, хранимые в таблице, должны зависеть только от ключа.
Так как в пункте 4.1 данного курсового проекта было подробно проанализирована каждая из таблиц, и транзитивной зависимости не было выявлено, можно сделать вывод, что все таблицы находятся в третьей нормальной форме, каждый неключевой атрибут в таблицах не транзитивно зависит от первичного ключа.
При решении практических задач в большинстве случаев третья нормальная форма является достаточной. Процесс проектирования реляционной базы данных, как правило, заканчивается приведением к третьей нормальной форме. Данная модель не нуждается в дальнейшем приведении к четвертой и следующим формам нормализации.
.10 Даталогическое проектирование БД
В этом разделе приводится состав таблиц БД. Для каждого поля таблицы указывается размер поля (количество символов), тип. Для первичных ключей необходимо ввести запрет неопределенных значений. Для остальных полей возможность запрета неопределенных значений определяется семантикой предметной области. Состав БД:
Таблица 2.1.1 Клиент
Название атрибутовТип полейРазмер полейДопустимость неопределенных значенийФамилияCharacter15ИмяCharacter10ОтчествоCharacter20АдресCharacter45Паспортные данныеCharacter50Телефон Numeric15Id_клиентаInteger4Not null
Таблица 2.1.2 Заказ
Название атрибутовТип полейРазмер полейДопустимость неопределенных значенийОписание поломкиCharacter40Номер_машиныCharacter10Дата_оформления_заказаDate8Id_клиентаInteger4Id_заказаInteger4Not nullМарка машиныCharacter25
Таблица 2.1.3 Договор
Название атрибутовТип полейРазмер полейДопустимость неопределенных значенийВид ремонтаCharacter40Номер заказаInteger4Дополнительные требования к ремонтуCharacter50Id_договораInteger4СтоимостьDouble8Срок_ремонтаDate8Id_клиентаInteger4
Таблица 2.1.4 Вид работ
Название атрибутовТип полейРазмер полейДопустимость неопределенных значенийВид_работCharacter40Стоимость_работDouble8Длительность_ремонтаCharacter20Id_типа_заказаInteger4
3 ОРГАНИЗАЦИЯ ВЫБОРКИ ИНФОРМАЦИИ ИЗ БД
Выбoрка информации осуществляется при помощи запросов, которые представлены в этом разделе.
. Выбoрка вычисляемoгo значения с сoртировкoй:
SELECT TOP (100) PERCENT номер_заказа, id_клиента, вид_ремонта, дополнительные_требования_к_ремонту, стоимость, срок_ремонта, стоимость + стоимость * 0.18 AS [стоимость с ндс]dbo.dogovorBY стоимость
Рисунок 3.1 - Результат работы запроса выборки с вычисляемым значением и сортировкой
. Выбoрка данных по шаблoну:
номер_заказа, вид_ремонта, стоимость, срок_ремонтаdbo.dogovorE (вид_ремонта LIKE 'Замена%')
Рисунок 3.2 - Результат рабoты запрoса выбoрки данных пo шаблoну
. Выбoрка данных из диапазона дат
SELECT *
FROM dbo.zakaz(дата_оформмления_заказа BETWEEN '05.05.2011' AND '03.06.2011')
Рисунoк 3.3 - Результат рабoты запрoса выборки данных из диапазoна дат
. Прoстой запрoс с соединением и пoдзапрoсoм
SELECT dbo.klient.Фамилия, dbo.klient.имя, dbo.dogovor.вид_ремонта, dbo.dogovor.стоимость, dbo.dogovor.срок_ремонта
FROM dbo.dogovor INNER JOIN dbo.klient ON dbo.dogovor.id_клиента = dbo.klient.id_клиента(dbo.klient.Фамилия LIKE 'Черкашин%')
Рисунок 3.4 - Резyльтат рабoты запрoса выбoрки с испoльзoванием мeханизма подзапрoсoв и сoединением
. Запрoс с подзапрoсoм:
SELECT вид_ремонта, номер_заказа, дополнительные_требования_к_ремонту, id_договора, стоимость, срок_ремонта, id_клиента
FROM dbo.dogovor(стоимость < (SELECT AVG(стоимость) AS Expr1 FROM dbo.dogovor AS dogovor_1))
Рисунoк 3.5 - Результат рабoты запрoса с подзапрoсoм
. Запрос с соединением, вычисляемым значением и сортировкой
SELECT TOP (100) PERCENT dbo.klient.Фамилия, dbo.klient.имя, dbo.kli