База данных прокат автомобилей. Курсовая. 1 Структуры базы данных

Название	1 Структуры базы данных
Анкор	База данных прокат автомобилей
Дата	23.01.2022
Размер	121.5 Kb.
Формат файла
Имя файла	Курсовая.doc
Тип	Документы #339547

1 Структуры базы данных

На первом этапе разработки базы данных, перед составлением структуры БД, нужно подготовить краткое описание предметной области:

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

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

1.1 Семантическое моделирование предметной области

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

Основной задачей семантического моделирования является выяснение смысловых взаимосвязей между элементами данных. Эти взаимосвязи должны быть отражены на диаграмме «объект/отношение».

Рассмотрим положения этого метода моделирования на примере разработки структуры базы данных проката автомобилей.

Работа компании проката автомобилей построена следующим образом:

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

На диаграмме «объект/отношение», сначала выделяются объекты, сведения о которых участвуют в приведенном выше описании. Такие объекты называются правильными и изображаются на диаграмме «объект/отношение» в виде прямоугольников. К ним относятся объекты: «Клиент», «Заказ», «Автомобиль», «Сотрудник».

Затем для каждого объекта указывается в виде эллипса ключевое свойство, которое будет использоваться в качестве первичного ключа таблицы, и помечается знаком, например, «#».

Для правильных объектов выбраны ключевые свойства:

«Клиент» – код клиента (КодК#),
«Заказ» – код заказа (КодЗ#),
«Автомобиль» – Номер(НомерА#),
«Сотрудник» –Табельный номер (НомерТ#).

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

Если одному экземпляру первого объекта могут соответствовать несколько экземпляров второго объекта, а одному экземпляру второго объекта – один и только один экземпляр первого объекта, то речь идет об отношении типа один - ко - многим (1-М).

1-М (один-ко-многим) – «Клиент» - «Заказ», «Сотрудник» - «Заказ», «Автомобиль» – «Заказ»,

Если одному экземпляру первого объекта могут соответствовать несколько экземпляров второго объекта, а одному экземпляру второго объекта несколько экземпляров первого объекта, то говорят об отношении типа многие-ко-многим (М - М).

М-М (многие-ко-многим) – на диаграмме нет,

Если одному экземпляру первого объекта соответствует один и только один экземпляр второго объекта, а одному экземпляру второго объекта один и только один экземпляр первого объекта, то говорят об отношениитипа один-к-одному (1-1) между двумя объектами.

1-1 (один-к-одному)– на диаграмме нет.

Затем для каждого смыслового отношения один – ко – многим и многие-ко-многим указываем внешние ключи для связи с соответствующими объектами.

Внешний ключ - это столбец или набор столбцов в дочерней таблице, который в точности соответствует столбцу или набору столбцов, определенных в родительской таблице как первичный (или уникальный) ключ, и ссылается на них.

«Заказы» (КодК##, НомерА##, НомерТ##).

Затем проставляем неключевые свойства для объектов и отношений:

"Клиент" (ФИО, Дата рождения, Серия и номер, Регистрация),
"Сотрудник" (ФИО, Дата рождения, Паспорт, Оклад, Стаж),
"Заказ" (Дата заказа, Дата окончания аренды, Срок заказа),
"Автомобиль" (Марка, Цвет, Объем двигателя, Год выпуска, Привод, Цена).

1.2 Проектирование структуры базы данных

На основании построенной диаграммы «Объект/отношение» выполняется проектирование структуры базы данных. Для этого используется простейший алгоритм, состоящий из пяти этапов:

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

«Клиент» – код клиента (КодК#),
«Заказ» – код заказа (КодЗ#),
«Автомобиль» – Номер(НомерА#),
«Сотрудник» –Табельный номер (НомерТ#).

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

3. Выделила отношения типа многие-к-одному в которых участвуют только правильные объекты. Это отношения руководят и участвуют. Для них новые базовые отношения не создаются. Но в базовое отношение, соответствующее стороне «многие», добавляется внешний ключ для доступа к базовому отношению, соответствующему стороне «один». В качестве внешнего ключа используется первичный ключ базового отношения стороны «один». Определяем правила внешних ключей:

Заказ (кодЗ#)

PRIMARY KEY (кодЗ#)

FOREIGN KEY (кодК##) REFERENCES Клиент

ON DELETE NO ACTION

ON UPDATE CASCADE

FOREIGN KEY (НомерТ##) REFERENCES Сотрудники

ON DELETE NO ACTION

ON UPDATE CASCADE

FOREIGN KEY (НомерА##) REFERENCES Автомобиль

ON DELETE NO ACTION

ON UPDATE CASCADE

Выделяются отношения многие-к-одному, в которых участвуют слабые объекты. Для каждого слабого объекта создается базовое отношение и определяется первичный ключ. Для отношений многие-к-одному новые базовые отношения не создаются, но ставится внешний ключ со стороны «многие» к стороне «один». При указании правил внешних ключей разрешается удаление значений первичных ключей (даже при наличии ссылок на них) вместе с соответствующими значениями внешних ключей.

ON DELETE CASCADE

ON UPDATE CASCADE

Каждому неключевому свойству объектов и отношений во всех созданных базовых отношениях ставится в соответствие неключевой атрибут.

Итоговая диаграмма "объект-отношение" представлена на рисунке А.1.

1.3 Функциональные зависимости и нормализация

Функциональные зависимости определяют не текущее состояние БД, а все возможные ее состояния, то есть они отражают те связи между атрибутами, которые присущи реальному объекту, моделируемые в БД.

Атрибут Y некоторого отношения функционально зависит от X (атрибуты могут быть составными), если в любой момент времени каждому значению X соответствует одно значение Y. Функциональная зависимость обозначается X >Y.

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

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

Транзитивная функциональная зависимость. Пусть X, Y, Z - три атрибута некоторого отношения. При этом X > Y и Y > Z, но обратное соответствие отсутствует, т. е. Z -/-> Y и Y -/-> X. Тогда Z транзитивно зависит от X.

Многозначная зависимость. Пусть X. Y, Z - три атрибута отношения R. В отношении R существует многозначная зависимость R. X -» R. Y только в том случае, если множество значений Y. соответствующее паре значений X и Z. зависит только от X и не зависит от Z.

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

Отношение находится в 1НФ (первой нормальной форме) если значения всех его атрибутов атомарны.

Отношение находится во 2НФ, если оно находится в 1НФ и каждый неключевой атрибут функционально полно зависит от ключа.

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

Отношение находится в BCNF(нормальная форма Бойса-Кодда), если оно находится в 3НФ и в ней отсутствуют зависимости атрибутов первичного ключа от неключевых атрибутов.

Ситуация, когда отношение будет находится в 3NF, но не в BCNF, возникает при условии, что отношение имеет два (или более) возможных ключа, которые являются составными и имеют общий атрибут.

Отношение «Клиент»: данное отношение находится в 1НФ, т.к. относится к реляционной БД и содержит только скалярные значения. Также оно находится во 2 НФ, т.к. есть 1НФ и не имеет составного первичного ключа, и находится в 3 НФ, т.к. находится во 2НФ и не имеет транзитивных зависимостей. Отношение находится в Нормальной форме Бойса - Кодда (НФБК), так как нет нескольких потенциальных составных ключей.

Отношение «Заказ»: данное отношение находится в 1НФ, т.к. относится к реляционной БД и содержит только скалярные значения. Также оно находится во 2 НФ, т.к. есть 1НФ и не имеет составного первичного ключа, и находится в 3 НФ, т.к. находится во 2НФ и не имеет транзитивных зависимостей. Отношение находится в Нормальной форме Бойса - Кодда (НФБК), так как нет нескольких потенциальных составных ключей.

Отношение «Сотрудник»: данное отношение находится в 1НФ, т.к. относится к реляционной БД и содержит только скалярные значения. Также оно находится во 2 НФ, т.к. есть 1НФ и не имеет составного первичного ключа, и находится в 3 НФ, т.к. находится во 2НФ и не имеет транзитивных зависимостей. Отношение находится в нормальной форме Бойса - Кодда (НФБК), так как нет нескольких потенциальных составных ключей.

Отношение «Автомобиль»: данное отношение находится в 1НФ, т.к. относится к реляционной БД и содержит только скалярные значения. Также оно находится во 2 НФ, т.к. есть 1 НФ и не имеет составного первичного ключа, и находится в 3 НФ, т.к. находится во 2НФ и не имеет транзитивных зависимостей. Отношение находится в Нормальной форме Бойса - Кодда (НФБК), так как нет нескольких потенциальных составных ключей.

Построенные диаграммы функциональных зависимостей представлены на рисунке Б.1.

1.4 Описание таблиц

Таблицы базы данных создавались при помощи конструктора. Созданные поля таблицы «Клиенты» и их тип представлены на рисунке 1.
Создание таблиц на языке SQL:

CREATE TABLE Заказы

(КодЗ INTEGER NOT NULL,

КодК INTEGER NOT NULL,

НомерА INTEGER NOT NULL,

НомерТ INTEGER NOT NULL,

Дата заказа DATE,

Дата окончания аренды DATE,

Срок заказа INTEGER,

PRIMARY KEY (КодЗ#)

FOREIGN KEY (КодК#) REFERENCES Клиент

ON DELETE NO ACTION

ON UPDATE CASCADE

FOREIGN KEY (НомерА#) REFERENCES Автомобили

ON DELETE NO ACTION

FOREIGN KEY (НомерТ#) REFERENCES Сотрудники

ON DELETE NO ACTION

ON UPDATE CASCADE);

CREATE TABLE Клиент

(КодК INTEGER NOT NULL,

ФИО СНАR(50),

Дата рождения DATE,

Серия и номер паспорта СНАR(150),

Регистрация СНАR(50),

PRIMARY KEY (КодК));

CREATE TABLE Сотрудники

(НомерТ INTEGER NOT NULL,

ФИО CHAR(50),

дата рождения DATE,

Паспорт INTEGER,

Оклад INTEGER,

Стаж INTEGER,

PRIMARY KEY (НомерТ)

CREATE TABLE Автомобили

(НомерА INTEGER NOT NULL,

Марта CHAR(25),

Цвет CHAR(15),

Объем двигателя CHAR(5),

Год выпуска CHAR(4),

Привод CHAR(10),

Цена INTEGER,

PRIMARY KEY (НомерА));
1.5 Описание форм базы данных

главная кнопочная форма

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

При разработке главной кнопочной формы используют диспетчер кнопочных форм, который создает функционирующую кнопочную форму и позволяет редактировать существующие формы. форма «Запрос»;

форма «Формы»;
форма «Отчеты».

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

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

форма «Автомобили»;
форма «Сотрудники»;
форма «Клиенты»;
форма «Заказы».

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

2 Общие и частные ограничения целостности

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

Целостность БД не гарантирует достоверности содержащейся в ней информации, но обеспечивает, по крайней мере, правдоподобность этой информации, отвергая заведомо невероятные, невозможные значения. Таким образом, не следует путать целостность БД с достоверностью БД. Достоверность (или истинность) есть соответствие фактов, хранящихся в базе данных, реальному миру. Очевидно, что для определения достоверности БД требуется обладание полными знаниями как о содержимом БД, так и о реальном мире. Для определения целостности БД требуется лишь обладание знаниями о содержимом БД и о заданных для неё правилах. Поэтому СУБД может (и должна) контролировать целостность БД, но принципиально не в состоянии контролировать достоверность БД. Контроль достоверности БД может быть возложен только на человека, да и то в ограниченных масштабах, поскольку в ряде случаев люди тоже не обладают полнотой знаний о реальном мире.

2.1 Общие ограничения целостности

Общие ограничения целостности - ограничения, которые справедливы для любой БД. К ним относятся правила целостности и ссылочной целостности объекта.

Правило целостности - среди значения потенциального ключа не должно быть null-значений. Null-значение - неопределённое, пропущенное значение в столбце.

Правило ссылочной целостности - внешний ключ не должен содержать значения, не содержащиеся в первичном ключе ссылочной таблицы, и null-значения.

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

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

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

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

2.2 Частные ограничения целостности

Частные ограничения целостности распространяются только для отдельных таблиц некоторых БД. В рамках СУБД ACCESS частные ограничения целостности можно задать несколькими способами.

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

В курсовой работе частные ограничения целостности реализованы путем установки условия на значение в поле «Дата заказа». Нельзя указать дату, которая уже прошла.

В форме Заказ для поля «Номер» задала следующее условие для проверки: Len ([Номер])=10 . Данное условие подразумевает собой то, что в поле «Номер» должно вводиться не более 10 знаков, включая пробелы, иначе будет выдано сообщение об ошибке с текстом «Не соответствует формату номера машины. Введите номер содержащий не более 9 символов». 3 Надежность взаимодействия пользователя с системой
К надежности базы данных (БД) предъявляются особо жесткие требования, поскольку информация, хранимая в них, используется обычно многократно.

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

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

При создании базы данных для повышения надежности были проделаны следующие действия:

изменена последовательность перехода в формах в соответствии с логическим порядком. Под последовательностью перехода понимается порядок перемещения курсора по элементам управления при нажатии клавиши Tab в Режиме формы. Последовательность заполнения формы существенно влияют на точность и скорость ввода данных,
созданы поля подстановки значений для полей «код заказа», в форме «Заказы» и «код клиента» в форме «Клиент».

4 Разработка средств автоматизации взаимодействия пользователя и системы

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

Гиперссылка является проводником от нашей базы данных до объекта информации, где бы он ни находился. В базе данных была создана гиперссылка на сайт компании.

5 Обработка данных с помощью запросов

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

В созданной базе данных были решены следующие задачи при помощи "Мастера запросов" и "Конструктора":

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

6 Автоматизация подготовки документов

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

В базе данных «Прокат автомобилей» были созданы следующие отчеты:

«Автомобиль» на основе таблицы «Автомобили»;
«Премия» на основе запроса «Заказы»;
«Заказы за месяц» на основе запроса «Заказы за месяц».

8 Обеспечение безопасности данных

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

Для моей базы данных был установлен пароль «1». Для этого в меню "Сервис" выбрано "Защита"/"Задать пароль базы данных". В открывшемся диалоговом окне «Задание пароля базы данных» введен пароль и подтверждение.

9 Руководство пользователя
Областью данных разработанной базы данных является деятельность

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

Для того чтобы приступить к работе с системой, необходимо открыть файл «Прокат автомобилей». Выйдет диалоговое окно с просьбой ввести пароль. Паролем является значение - 1.

Открывается главная кнопочная форма. На главной форме расположены кнопки: «Запросы», «Отчеты», «Формы», «Выход».

Запросы

При обращении к кнопке запросы, открывается форма с кнопками «Дата заказа», «Окончание аренды», «Оплата», «Зарплата», «Главная».

При нажатии на кнопки:

«Дата заказа» и «Дата окончание аренды» открывается окно для ввода даты, после ввода открывается таблица с данными по дате заказа или аренды;
«Оплата» и «Зарплата» открываются таблицы с данными о заработной плате и о оплате аренды.

Отчеты

При обращении к кнопке «Отчеты» откроется страница, на которой находятся все отчеты, имеющиеся в БД и кнопка «Главная», для возвращения пользователя на главную страницу. При нажатии на соответствующую кнопку открывается отчет «Автомобили», «Заказы за месяц», «Премия». С отчетами можно не только ознакомиться, но и распечатать.

Формы

При нажатии на кнопку Формы открывается список с формами. Можно открыть следующие формы: «Автомобили», «Сотрудники», «Клиенты», «Заказы» и кнопка «Главная», которая позволяет вернуться на Главную кнопочную форму.

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

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

Для того чтобы вводить новые данные в выбранную форму необходимо учесть:

значения «Код клиента», «Табельный номер», «Код заказа», «Номер автомобиля» в соответствующих формах «Клиент», «Сотрудник», «Заказ», «Автомобиль» должны иметь уникальное неповторяющееся значение,
значения «Номер автомобиля», «Табельный номер» в форме «Заказ» обязательно выбираются из списка, нажатием на стрелочку справа от поля ввода,
в формах «Сотрудник», «Заказ», «Клиент» установлены календари для удобства ввода даты,
на главной форме есть гиперссылка, позволяющая открыть веб-сайт компании,

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

Заключение

В результате выполнения курсовой работы была создана база данных "Прокат автомобилей". Были обеспечены общие и частные ограничения целостности. Проведена обработка данных с помощью операций реляционной алгебры и созданы запросы. Также были созданы документы «Автомобили», «Докладная записка» и «Заказы за месяц». Разработано руководство пользователя.

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

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

Для проектирования базы данных и организации интерфейса пользователя использовались сведения из источников

Курсовая работа оформлена в соответствии с ГОСТ 7.32-2017. [8]

Разработка осуществлялась с использованием средств СУБД Microsoft Access.