Требования к структурным элементам работы

 

3.1 Титульный лист

Титульный лист является первым листом пояснительной записки и выполняется в соответствии с ГОСТ 2.105 и СТП 3.4.204-01 - Требования к оформлению текстовых документов. Форма титульного листа приведена в Приложении Б.

3.2 Задание

3.3 Реферат

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

3.4 Содержание

Содержание оформляют после того, как работа над текстовым документом закончена. Содержание включает наименование всех структурных элемен­тов пояснительной записки: «Введение», заголовки всех разделов и под­разделов, «Заключение», «Библиографическийсписок» и перечень прило­жений.

3.5 Введение

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

3.6 Основная часть

Основную часть составляют следующие разделы:

- Постановка цели и задач работы БД.

- Концептуальное проектирование реляционной БД.

- Описание предметной области (объекты, их свойства и связи).

- Анализ зависимостей полей, определение ключей и нормализация таблиц или построение ЕR-модели на основе правил формирования отно­шений.

- Построение реляционной схемы данных.

- Реализация отношений (описание полей, типов данных, свойств по­лей и таблиц, связей таблиц с обеспечением целостности данных, различ­ных видов объединения записей).

- Создание простых и составных форм для ввода и просмотра дан­ных.

- Обоснование и описание назначения запросов различных типов (5).

- Реализация запросов с помощью языков QBE и SQL и отображение результатов их исполнения.

- Реализация интерфейса приложения (структура главной кнопочной формы, простые, составные, кнопочные формы, макросы, VBA-модули)

- Реализация других объектов ACCESS в приложении (отчетов, стра­ниц доступа к данным)

- Защита базы данных.

3.7 Заключение

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

3.8 Библиографический список

Библиографический список должен содержать перечень источ­ников, ссылка на которые имеется в тексте. Сведения об источниках необ­ходимо давать в соответствии с ГОСТ 7.1 2003, СТП 3.4.204-01.

 

Теоретические основы проектирования базы данных

 

Метод нормальных форм

 

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

Выделяют следующую последовательность нормальных форм:

- первая нормальная форма (1НФ);

- вторая нормальная форма (2НФ);

- третья нормальная форма (3НФ);

- усиленная третья нормальная форма, или нормальная форма Бойса-Кодда (БКНФ);

- четвертая нормальная форма (4НФ);

- пятая нормальная форма (5НФ).

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

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

Повторяющиеся группы – это атрибуты, определенные на одних и тех же доменах.

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

Такая декомпозиция должна обеспечить то, что запросы к исходному отношению и к отношениям, получаемым в результате декомпозиции, да­дут одинаковый результат. Основной операцией метода является проекция. Поясним ее на примере. Предположим, что в отношении R (A, B, C, D, E…) устранение функциональной зависимости C D позволит перевести его в следующую нормальную форму. Для решения этой задачи выполним декомпозицию отношения R на два новых отношения R1 (A, B, C, E) и R2 (C, D). Отношение R2 является проекцией отношения R на атрибуты C и D.

Например, исходное отношение ПРЕПОДАВАТЕЛЬ (ФИО, Предмет, Группа, ВидЗанятия, Должность, Оклад, Стаж, Кафедра), которое

используется для иллю­страции метода, имеет составной ключ ФИО, Предмет, Группа и находится в 1 НФ, поскольку все его атрибуты простые.

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

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

- в отношении присутствует явное и неявное избыточное дублирова­ние данных, например:

· повторение сведений о стаже, должности и окладе преподавателей, про­водящих занятия в нескольких группах и/или по разным предметам;

· повторение сведений об окладах для одной и той же должности;

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

Часть избыточности устраняется при переводе отношения в 2НФ.

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

Для устранения частичной зависимости и перевода отношения в 2НФ необходимо, используя операцию проекции, разложить его на не­сколько отношений следующим образом:

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

- построить проекции на части составного первичного ключа и атрибуты, зависящие от этих частей. В результате получим два отношения: R1- во второй НФ и отношение R2 (рисунок 4.1).

R1

ФИО	Предмет	Группа	ВидЗанятия
Иванов И.И.	SQL	23-1	Практ.
Иванов И.И.	SQL	22-3	Практ.
Петров М.И.	БД	25-6	Лекция
Петров М.И.	Паскаль	25-6	Практ.
Егоров В.В.Г.	Алгол	25-6	Лекция
Егоров В.В.	SQL	24-4	Лекция

R2

ФИО	Должность	Оклад	Стаж	Кафедра
Иванов И.И.	Ассистент
Петров М.И.	Ст.преп.
Сидоров Н.Г.	Ассистент
Егоров В.В.	Доцент

 

Рисунок 4.1 - Декомпозиции исходного отношения на 2 отношения в 2НФ

 

Исследование отношений R1 и R2 показывает, что переход к 2НФ позволил исключить явную избыточность данных в таблице R2 – повторе­ние строк со сведениями о преподавателях.

Для дальнейшего совершенствования отношения необходимо преоб­разовать его в 3НФ.

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

Если в отношении R1 транзитивные зависимости отсутствуют, то в отношении R2 они есть:

ФИО Должность Оклад

ФИО Оклад Должность

Транзитивные зависимости также порождают избыточное дублиро­вание информации в отношении. Устраним их. Для этого используя опера­цию проекции на атрибуты, являющиеся причиной транзитивных зависи­мостей, преобразуем отношение R2, получив при этом отношения R3 и R4, каждое из которых находится в 3НФ (рисунок 4.2)

R3

ФИО	Должность	Стаж	Кафедра
Иванов И. И.	Ассистент
Петров М. И.	Ст. преп.
Сидоров Н. Г.	Ассистент
Егоров В. В.	Доцент

 

R4

Должность	Оклад
Ассистент
Ст. преп.
Доцент
Профессор

 

Рисунок 4.2 - Отношения БД в 3НФ

 

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

У нас подобной зависимости нет, поэтому процесс проектирования на этом заканчивается. Результатом проектирования является БД, состоящая из следующих отношений: R1, R3, R4, в полученной БД имеет место необходимое дублирование данных, но отсутствует избыточное

 

4.2 ER-моделирование реляционных БД и средства автоматиза­ции проектирования

Метод ER-диаграмм (ER – аббревиатура от слов Essence-сущность и Relation-связь) основан на использовании диаграмм, называемых соответственно диаграммами ER-экземпляров и диаграммами ER-типа.

4.2.1 Основные понятия метода

Сущность представляет собой объект, информация о котором хра­нится в БД. Экземпляр сущности – конкретный представитель данной сущности. Экземпляры отличаются друг от друга и однозначно идентифи­цируются. Названиями сущностей являются, как правило, существитель­ные, например: ПРЕПОДАВАТЕЛЬ, ДИСЦИПЛИНА, КАФЕДРА, ГРУППА.

Атрибут представляет собой свойство сущности. Имеет четкое смы­словое значение. Так, атрибутами сущности ПРЕПОДАВАТЕЛЬ может быть его Фамилия, Должность, Стаж и т. д.

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

Связь двух или более сущностей – предполагает зависимость между атрибутами этих сущностей. Название связи обычно представляется глаго­лом. Примерами связи между сущностями являются следующие: ПРЕПО­ДАВАТЕЛЬ ведет ДИСЦИПЛИНУ (Иванов И.И. ведет «SQL»), ПРЕПО­ДАВАТЕЛЬ преподает в ГРУППЕ (Иванов И.И. преподает в 223 группе), ПРЕПОДАВАТЕЛЬ работает на КАФЕДРЕ (Иванов рабо­тает на 439 кафедре).

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

· Диаграммы ER-экземпляров;

· Диаграммы ER-типа, или ER-диаграммы.

На рисунке 4.3 приведена диаграмма ER-экземпляров для сущностей ПРЕПОДАВАТЕЛЬ и ДИСЦИПЛИНА со связью ведет.

ПРЕПОДАВАТЕЛЬ	ведет	ДИСЦИПЛИНА
ИВАНОВ И. И. •		• БД
ПЕТРОВ М. И. •		• SQL
СИДОРОВ Н. Г. •		• Паскаль
ЕГОРОВ В. В. •		• Алгол
КОЗЛОВ А. С. •		• Фортран

 

Рисунок 4.3 - Диаграмма ER-экземпляров

 

Диаграмма ER-экземпляров показывает, какую конкретную дисцип­лину ведет каждый из преподавателей. На рисунке 4.4 представлена диа­грамма ER-типа, соответствующая рассмотренной диаграмме ER-экземп­ляров.

Рисунок 4.4 - Диаграмма ER-типа

 

На начальном этапе проектирования выделяют атрибуты, состав­ляющие ключи сущностей.

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

Степень связи является характеристикой связи между сущностями, которая может быть типа: 1:1, 1:М, М:1, М:М.

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

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

 

4.2.2 Этапы проектирования

Процесс проектирования базы данных является итерационным – до­пускающим возврат к предыдущим этапам для пересмотра ранее принятых решений и включает следующие этапы:

§ выделение сущностей и связей между ними.

§ построение диаграмм ER-типа с учетом всех сущностей и их свя­зей.

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

§ добавление неключевых атрибутов в отношения.

§ приведение предварительных отношений к нормальной форме Бойса-Кодда, например, с помощью метода нормальных форм.

§ пересмотр ER-диаграмм в следующих случаях:

- некоторые отношения не приводятся к нормальной форме Бойса-Кодда;

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

После преобразования ER-диаграмм осуществляется повторное вы­полнение предыдущих этапов пректирования.