Стержневые идеи современных информационных технологий базируются на концепции баз данных.
Согласно этой концепции, основой информационных технологий являются данные, которые должны быть организованы в базы данных в целях адекватного отображения изменяющегося реального мира и удовлетворения информационных потребностей пользователей.
Увеличение объема и структурной сложности хранимых данных, расширение круга пользователей информационных систем выдвинуло требование создания удобных общесистемных средств интеграции хранимых данных и управления ими. Это и привело к появлению в конце 1960-х годов первых промышленных систем управления базами данных (СУБД) — специализированных программных средств, предназначенных для организации и ведения баз данных. Сначала это были системы с инвертированными списками, иерархические и сетевые системы. В 1969 году была предложена реляционная модель данных, а в конце 1970-х и начале 1980-х годов стали появляться первые промышленные реляционные СУБД. Сейчас преобладающее большинство СУБД являются реляционными, несмотря на появление объектно-ориентированных СУБД. Это не в последнюю очередь связано с тем, что в конце 1990-х годов большинство ведущих производителей реляционных СУБД создали объектные надстройки к реляционной схеме, что привело к появлению объектно-реляционных СУБД, поддерживающих некоторые технологии, реализующие объектно-ориентированный подход.
В данной работе будет использована одна из широко распространённых реляционных СУБД, к которым и относится Access. MicrosoftAccess — одна из самых популярных в мире систем управления базами данных для операционной системы Windows. Кроме того, Access — мощная платформа разработки офисных приложений с очень гибкой и функциональной интегрированной средой пользователя.относится к классу так называемых «настольных» СУБД, которые имеют высокоразвитые языковые средства, предназначенные для облегчения работы с ними пользователей разной квалификации, в том числе и пользователей, не являющихся специалистами в области информационных технологий.
Реляционная база данных представляет собой множество взаимосвязанных таблиц, каждая из которых содержит информацию об объектах определенного вида. Каждая строка таблицы содержит данные об одном объекте (например, автомобиле, компьютере, клиенте), а столбцы таблицы содержат различные характеристики этих объектов — атрибуты (например, номер двигателя, марка процессора, телефоны фирм или клиентов).
Проектирование и разработка реляционной базы данных для информационной ...
... такую информационную систему, которая бы удовлетворяла все требованиям торговой организации по хранению и анализу информации. Целью данной курсовой работы является создание реляционной базы данных зоомагазина и ... разработка приложения для работы с данной базой. В совокупности данная ...
Строки таблицы называются записями. Все записи таблицы имеют одинаковую структуру — они состоят из полей (элементов данных), в которых хранятся атрибуты объекта. Каждое поле записи содержит одну характеристику объекта и представляет собой заданный тип данных (например, текстовая строка, число, дата).
Для идентификации записей используется первичный ключ. Первичным ключом называется набор полей таблицы, комбинация значений которых однозначно определяет каждую запись в таблице.
Компоненты MSAccess.состоит из отдельных компонентов (объектов), из которых создается БД:
- Таблицы
Таблицы являются центральным объектом базы данных. Их целью является хранение информации. Целью всех других объектов базы данных является взаимодействие тем или иным способом с одной или несколькими таблицами. В базе данных Access могут содержаться тысячи таблиц, а число записей в каждой из таблиц ограничено в первую очередь местом, доступным на вашем жестком диске.
Каждый объект Access имеет два или более способов представления. Для таблиц двумя наиболее часто используемыми представлениями являются представление Режим таблицы и представление
- Запросы
База данных, кроме выполнения роли информационного хранилища, должна обеспечивать быстрое предоставление актуальных данных.
Запросы — мощный инструмент управления данными, позволяющий извлекать из таблиц БД сведения, которые соответствуют определенному критерию. Данные, положенные в основу запроса, могут быть сохранены в одной или нескольких таблицах результат запроса представляет собой динамический набор записей.
- Формы
Форма представляет собой созданный пользователем «бланк» для отображения на экране отдельных записей из одной или нескольких таблиц базы данных. С помощью форм можно вводить информацию в таблицы, редактировать и удалять ее, а также ограничить доступ к данным и отображать их только в режиме просмотра.
- Отчеты
Отчет используется для отображения данных, содержащихся в базе, в наглядной форме. Возможности отчета выходят далеко за пределы обычного представления данных в таблице: записи можно сгруппировать по отдельным критериям, для отдельных групп записей и для всего отчета можно выполнить необходимые вычисления.
- Страницы
Страницы доступа к данным представляют собой средство просмотра, добавления, изменения и обработки записей базы данных в расчете на использование в среде Internet для удаленного доступа к БД.
6. Макросы
Макросы используются для автоматизации основных или часто повторяющихся рабочих процедур. Каждый макрос содержит одну или несколько макрокоманд, каждая из которых выполняет определенное действие.
- Модули
Модули содержат программы на VisualBasic для приложений (VBA).
Используются для настройки, оформления и расширения возможностей БД.
Существует 2 основных типа модулей: модули класса и стандартные модули. К модулям класса относятся модули форм и модули отчетов, связанные с определенной формой или отчетом. Процедуры обработки событий используются для управления поведением формы или отчета и их откликом на события, такие как нажатие кнопки.
В стандартных модулях содержатся общие процедуры, не связанные ни с каким объектом, которые могут быть запущены из любого окна базы данных.
Создание структуры базы данных библиотеки
... которых была написана данная курсовая работа. Цель работы: Формирование структуры БД библиотеки. 1. ГЛАВНЫЕ ПОНЯТИЯ 1.1 Понятие о базе данных В методической литературе присутствует понятие о БД, как ... в памяти. После того как закончено описание всех элементов будущей БД, начинается создание ее структуры, т. е. устанавливаются связи между элементами. Детально остановимся на данном ниже, ...
- Элементы управления
Элементы управления (надписи, линии, поля, списки, кнопки, переключатели, флажки, графические объекты и т.д.) используются для получения от пользователя ввода/вывода результатов работы приложения, данных графики или сообщений. Входят в состав других компонентов.
1. Проектирование реляционных баз данных. Метод нормальных форм
1.1 Создание БД. Этапы проектирования
Создание БД начинается с проектирования.
Этапы проектирования БД:
- Исследование предметной области;
- Анализ данных (сущностей и их атрибутов);
- Определение отношений между сущностями и определение первичных и вторичных (внешних) ключей.
В процессе проектирования определяется структура реляционной БД (состав таблиц, их структура и логические связи).
Структура таблицы определяется составом столбцов, типом данных и размерами столбцов, ключами таблицы.
Определение отношений между сущностями и определение первичных и вторичных (внешних) ключей
Процесс проектирования представляет собой процесс нормализации схем отношений, причем каждая следующая нормальная форма обладает свойствами лучшими, чем предыдущая.
Каждой нормальной форме соответствует некоторый определенный набор ограничений, и отношение находится в некоторой нормальной форме, если удовлетворяет свойственному ей набору ограничений.
Проектирование заключается в определении числа и структуры таблиц, формировании запросов к БД, определении типов отчетных документов, создании форм для ввода и редактирования данных в базе, разработке алгоритмов обработки информации. Решение этих задач во многом определяется спецификой задач предметной области. Первой и наиболее важной задачей здесь является проектирование структур данных. В процессе ее решения происходит сбор информации об объектах будущей БД в рамках одной таблицы (исходного отношения) с последующим разбиением ее на несколько взаимосвязанных таблиц на основе метода нормализации отношений.
Набор таблиц, полученных в процессе нормализации, называется нормализованным. Он исключает избыточность информации в отношениях и обладает лучшими свойствами при различных операциях с БД по сравнению с другими возможными наборами таблиц, в которых могут быть представлены те же данные.
В теории реляционных баз данных обычно выделяется следующая последовательность нормальных форм:
- первая нормальная форма (1NF);
- вторая нормальная форма (2NF);
- третья нормальная форма (3NF);
- нормальная форма Бойса-Кодда (BCNF);
- четвертая нормальная форма (4NF);
пятая нормальная форма, или нормальная форма проекции-
соединения (5NF или PJ/NF);
- доменно-ключевая нормальная форма.
Основные свойства нормальных форм:
каждая следующая нормальная форма в некотором смысле лучше
предыдущей;
- при переходе к следующей нормальной форме свойства предыдущих нормальных свойств сохраняются.
В основе процесса проектирования лежит метод нормализации, декомпозиция отношения, находящегося в предыдущей нормальной форме, в два или более отношения, удовлетворяющих требованиям следующей нормальной формы.
Наиболее важные на практике нормальные формы отношений основываются на фундаментальном в теории реляционных баз данных понятии функциональной зависимости.
Нормализация — это разбиение таблицы на две или более, обладающих лучшими свойствами при включении, изменении и удалении данных. Окончательная цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, т.е. исключена избыточность информации. Это делается не столько с целью экономии памяти, сколько для исключения возможной противоречивости хранимых данных.
Каждая таблица в реляционной БД удовлетворяет условию, в соответствии с которым в позиции на пересечении каждой строки и столбца таблицы всегда находится единственное атомарное значение, и никогда не может быть множества таких значений. Любая таблица, удовлетворяющая этому условию, называется нормализованной.
1.2 Исходное отношение
Проектирование базы данных начинается с определения всех объектов, сведения о которых включены в базу, и определения их атрибутов.
На первом этапе атрибуты сводятся в одну таблицу — исходное отношение.
Схема исходного отношения: АВТОБАЗА (ФИО, Н_авто, Км, Дата, Катег, Оклад, Вредн, Н_вредн, Зван, Н_зван, Марка, Год).
Отношение имеет составной ключ, который может однозначно определить любую запись. В него входят три атрибута — ФИО, Н_авто, Дата. Данное отношение содержит избыточное дублирование данных как явного характера (строки с ФИО водителей и датами выездов этих водителей повторяются несколько раз, строки с ФИО водителей за которыми закреплен один автомобиль), так и неявного (одинаковый оклад у водителей с одинаковой категорией, одинаковые надбавки за звание и вредность).
Проведя анализ атрибутов в отношении АВТОБАЗА, выделим следующие зависимости между атрибутами (исключая зависимости между атрибутами составного ключа):
ФИО→Км — функциональная зависимость, за каждым водителем закреплен конкретный автомобиль, на котором он проехал определенное количество километров. Но за одним автомобилем могут быть закреплены один, два и более водителей.
ФИО→ Катег- функциональная зависимость, водители имеют определенную категорию водительских прав, но ту же самую категорию имеют разные водители.
ФИО→ Оклад — функциональная зависимость, каждый водитель получает конкретный оклад, но одинаковый оклад имеется у разных водителей. Зависимость транзитивна, поскольку имеются зависимости ФИО→ Катег и Катег ↔ Оклад.
ФИО→ Вредн- функциональная зависимость, у каждого водителя определенная категория вредности работы, которая может быть и у других водителей. Зависимость транзитивна, поскольку имеются зависимости Н_авто→ Марка и Марка → Вредн, а также Вредн ↔ Н_вредн.
ФИО→ Зван — функциональная зависимость, у каждого водителя свое конкретное звание, но есть другие водители с таким же званием. Зависимость транзитивна, поскольку имеются зависимости ФИО→ Н_зван и Зван ↔ Н_зван.
Н_авто→ Марка — функциональная зависимость, у каждого автомобиля имеется свой определенный регистрационный номер, но у разных автомобилей одной марки номер обязательно разный.
Н_авто↔ Год — функциональная взаимозависимость.
Рисунок 1
1.3 Нормализация
Для того чтобы устранить зависимость неключевых атрибутов от части первичного ключа, необходимо произвести декомпозицию отношения АВТОБАЗА на несколько отношений. Проведём операцию разделения, разложив исходное отношение на несколько:
- отношения без атрибутов, находящихся в частичной функциональной зависимости от составного ключа;
- отношения для атрибутов, являющихся частью составного ключа, и атрибутов, зависящих от них.
Таблица 1
|
ФИО |
Н_авто |
Км |
Катег |
Оклад |
Вредн |
Н_вредн |
Зван |
Н_зван |
||||||||||
|
Алексеев А.А. |
а111ро |
20000 |
C |
12 000р. |
3 |
30.00% |
рядовой |
0.00% |
||||||||||
|
Борисов Б.Б. |
б222ро |
10000 |
B |
11 000р. |
1 |
0.00% |
ефрейтор |
5.00% |
||||||||||
|
Борисов Б.Б. |
в333ро |
5000 |
B |
11 000р. |
1 |
0.00% |
ефрейтор |
5.00% |
||||||||||
|
Васильев В.В. |
б222ро |
4000 |
B |
11 000р. |
1 |
0.00% |
мл.сержант |
10.00% |
||||||||||
|
Васильев В.В. |
в333ро |
15000 |
B |
11 000р. |
1 |
0.00% |
мл.сержант |
10.00% |
||||||||||
|
Григорьев Г.Г. |
г444ро |
10000 |
C |
12 000р. |
2 |
20.00% |
ефрейтор |
5.00% |
г444ро |
8000 |
C |
12 000р. |
2 |
20.00% |
ефрейтор |
5.00% |
||
|
Ежов Е.Е. |
и777ро |
2000 |
B |
12 000р. |
1 |
0.00% |
ефрейтор |
5.00% |
||||||||||
|
Иванов И.И. |
и777ро |
15000 |
B |
11 000р. |
1 |
0.00% |
рядовой |
0.00% |
||||||||||
|
Карасёв К.К. |
к999ро |
12000 |
C |
12 000р. |
4 |
40.00% |
сержант |
20.00% |
||||||||||
Таблица 2 — Автомобили
|
Н_авто |
Марка |
Год |
|
а111ро |
ЗИЛ -130 |
05.05.2005 |
|
б222ро |
ВАЗ 2199 |
11.11.2010 |
|
в333ро |
ГАЗ 2131 |
01.05.2011 |
|
г444ро |
ГАЗ 33021 |
01.02.2009 |
|
и777ро |
ВАЗ 2107 |
10.10.2011 |
|
к999ро |
Камаз 5511 |
05.08.2008 |
Таблица 3 — Выезды
|
Дата |
ФИО |
Н_авто |
||
|
05.10.2012 |
Иванов И.И. |
и777ро |
||
|
05.10.2012 |
Григорьев Г.Г. |
г444ро |
||
|
05.10.2012 |
Борисов Б.Б. |
б222ро |
Карасёв К.К. |
к999ро |
|
06.10.2012 |
Денисов Д.Д. |
г444ро |
||
|
06.10.2012 |
Васильев В.В. |
б222ро |
||
|
08.10.2012 |
Борисов Б.Б. |
б222ро |
||
|
10.10.2012 |
Борисов Б.Б. |
в333ро |
||
|
10.10.2012 |
Ежов Е.Е. |
и777ро |
||
|
10.10.2012 |
Алексеев А.А. |
а111ро |
||
|
11.10.2012 |
Иванов И.И. |
и777ро |
||
|
11.10.2012 |
Васильев В.В. |
в333ро |
||
|
12.10.2012 |
Ежов Е.Е. |
и777ро |
||
|
12.10.2012 |
Алексеев А.А. |
и777ро |
Рисунок 2
После операции декомпозиции мы получили три отношения находящиеся во 2-й нормальной форме. Но в отношении ФИО всё ещё имеется неявное дублирование данных. Для перевода его в 3-ю нормальную форму исключим транзитивные зависимости.
Рисунок 3
Таблица 4
|
Катег |
Оклад |
|
B |
11 000р. |
|
C |
12 000р. |
Таблица 5
|
ЗванН_зван |
|
|
рядовой |
0.00% |
|
ефрейтор |
5.00% |
|
мл.сержант |
10.00% |
|
сержант |
20.00% |
Таблица 6
|
Вредн |
Н_вредн |
|
1 |
00% |
|
2 |
20% |
|
3 |
30% |
|
4 |
40% |
Таблица 7
|
ФИО |
Н_авто |
Км |
Катег |
Зван |
|
|
Алексеев А.А. |
а111ро |
20000 |
C |
3 |
рядовой |
|
Борисов Б.Б. |
б222ро |
10000 |
B |
1 |
ефрейтор |
|
Борисов Б.Б. |
в333ро |
4000 |
B |
1 |
ефрейтор |
|
Васильев В.В. |
б222ро |
5000 |
B |
1 |
мл.сержант |
|
Васильев В.В. |
в333ро |
15000 |
B |
1 |
мл.сержант |
|
Григорьев Г.Г. |
г444ро |
10000 |
C |
2 |
ефрейтор |
|
Денисов Д.Д. |
г444ро |
8000 |
C |
2 |
ефрейтор |
|
Ежов Е.Е. |
и777ро |
2000 |
B |
1 |
ефрейтор |
|
Иванов И.И. |
и777ро |
15000 |
B |
1 |
рядовой |
|
Карасёв К.К. |
К999РО |
12000 |
C |
4 |
сержант |
В таблице №9 мы всё ещё видим дублирование зависимости неключевых атрибутов от основного ключа. Для того чтобы исключить лишнее дублирование информации разобьём таблицу на две отдельные.
Таблица 8
|
ФИО |
Катег |
Вредн |
Зван |
|
Алексеев А.А. |
C |
3 |
|
|
Борисов Б.Б. |
B |
1 |
ефрейтор |
|
Васильев В.В. |
B |
1 |
мл.сержант |
|
Григорьев Г.Г. |
C |
2 |
ефрейтор |
|
Денисов Д.Д. |
C |
2 |
ефрейтор |
|
Ежов Е.Е. |
B |
1 |
ефрейтор |
|
Иванов И.И. |
B |
1 |
рядовой |
|
Карасёв К.К. |
C |
4 |
сержант |
Таблица 9
|
ФИО |
Н_авто |
Км |
|
Алексеев А.А. |
а111ро |
20000 |
|
Борисов Б.Б. |
б222ро |
10000 |
|
Борисов Б.Б. |
в333ро |
4000 |
|
Васильев В.В. |
б222ро |
5000 |
|
Васильев В.В. |
в333ро |
15000 |
|
Григорьев Г.Г. |
г444ро |
10000 |
|
Денисов Д.Д. |
г444ро |
8000 |
|
Ежов Е.Е. |
и777ро |
2000 |
|
Иванов И.И. |
и777ро |
15000 |
|
Карасёв К.К. |
К999РО |
12000 |
Таким образом, в результате преобразований, применив к исходному отношению метод нормальных форм и исключив избыточное дублирование информации, мы получили семь взаимосвязанных отношений (табл.№4,5,6,7,8,10,11).
2. Создание базы данных
Согласно проекту создадим таблицы базы данных средствами MicrosoftAccess.
Для каждой создаваемой таблицы требуется описать все поля. Задаётся имя поля, затем описывается тип данных, которые будут в нём содержаться, и в зависимости от типа данных описываются свойства создаваемого поля.
После этого задаётся ключевое поле каждой таблицы. Это действие может быть не обязательным в том случае, если база данных представлена одной таблицей, или если база данных состоит из нескольких не связанных между собой таблиц.
Рисунок 4
3. Организация связей
У нас каждая из зависимостей между атрибутами исходного отношения, ставшая причиной его разделения, трансформировалась в связь между соответствующей главной и подчиненными таблицами (рисунок 6,7).
Рисунок 6
3.1 Обеспечение целостности данных
При создании связей используется параметр «обеспечение целостности данных», для предотвращения появления данных в подчиненной таблице, не имеющих соответствующих записей в главной таблице. Дополнительный параметр «каскадное обновление связанных полей» позволяет изменением данных содержащихся в какой либо из записей главной таблицы вызывать соответствующие изменения во всех связанных подчинённых.
Рисунок 7
Рисунок 8
4. Формирование запросов
В создаваемой базе данных запросы будут создаваться при помощи инструмента «Конструктор запросов».
В задании на курсовой проект требовалось организовать запросы к БД, которые бы позволяли продемонстрировать в созданной БД:
) ФИО и категорию прав водителя.
Данный запрос является простым. Для его создания в режиме конструктора была использована таблица «Водители», в которой отмечены требуемые поля для вывода при вызове запроса.
Рисунок 9
Рисунок 10
) Сумму денежного содержания водителя и значения компонентов, из которых она формируется. Сведения в запросе упорядочить в порядке убывания денежного содержания, а при равном денежном содержании — в алфавитном порядке фамилий водителей.
Требуемый запрос формируется выборкой данных из нескольких таблиц, с последующей обработкой в вычисляемом поле «Зарплата». Поля, используемые для вычисления, по условию отображаются в таблице запроса. В поле «Зарплата» установлено условие сортировки записей, и далее, в следующем поле, даётся дополнительное условие для сортировки в алфавитном порядке.
Рисунок 11
Рисунок 12
) ФИО водителей, удовлетворяющих хотя бы одному из двух наборов условий из графы «Условия отбора записей»:
а) категория вредности — 1 или 4, звание — «рядовой»
б) оклад равен 5000р, ФИО начинается на буквы от «А» до «К».
Рисунок 13
Рисунок 14
) Количество выездов водителя на каждом из закрепленных за ним автомобилей (перекрестный запрос).
Рисунок 15
Рисунок 16
) Общий километраж, пройденный водителем на каждом из закрепленных за ним автомобилей.
Рисунок 17
Рисунок 18
5. Отчёт
В задании на курсовую работу требуется разработать ленточный отчет, содержащий заголовок, дату, данные о составителе отчета, справочную информацию о каждом водителе автобазы, включая номера автомобилей, закрепленных за ним. В отчете отразить итоговые данные: километраж, пройденный каждым водителем на всех прикрепленных автомобилях, и общее количество выездов всех водителей на прикрепленных автомобилях в рассматриваемом периоде.
Для составления отчёта используется инструмент «Мастер отчётов». Выбор информации производится из таблиц «Водители» и «Пробег», а также запросов «Количество выездов» и «Зарплата».
Рисунок 19
Заключение
база данная мicrosoft аccess
В процессе выполнения курсовой работы были изучены и освоены принципы проектирования и построения реляционных баз данных. Для практического изучения и применения, в качестве системы управления базами данных был применен программный продукт MicrosoftAccess.
В соответствии с заданием была составлена таблица исходного отношения атрибутов данных подлежащих учёту и систематизации, произведена её декомпозиция с целью нормализации отношений. После того как все таблицы приведены к 3-й нормальной форме и установлены их связи, посредством инструментов MicrosoftAccess создана база данных с заданными атрибутами. Таблицы сконструированы с помощью инструмента «Конструктор таблиц». Для связи таблиц между собой, в соответствии с проектом, применён инструмент «Схема данных». Для формирования запросов использовался «Мастер запросов». И, в конечном итоге, результат систематизации данных представлен в ленточном отчёте созданном посредством «Мастера отчётов».
Использованная литература
[Электронный ресурс]//URL: https://liarte.ru/kursovaya/tehnologiya-razrabotki-i-zaschityi-baz-dannyih/
1. Абумова Г.А. Методические указания и задания на курсовую работу по курсу БАЗЫ ДАННЫХ. М.: МТУСИ, 2005.
. Базы данных: Учебник для высших учебных заведений / Под ред. проф. Хомоненко А.Д. СПб.: КОРОНА принт, 2004.
. Бураков П.В., Петров В.Ю. Введение в системы баз данных. СПб: 2010.
. Громов Г.Ю., Кириллов В.В. Введение в реляционные базы данных. СПб.: БХВ-Петербург, 2009.
. Диго С.М. Создание баз данных в среде СУБД Access. Учебное пособие. М.: МГУСЭИ, 2001.
