Расчетно-графическая работа содержит текстовую часть (пояснительную записку) и графическую часть (схему данных, таблицы, иерархическую структуру главной кнопочной формы).
Пояснительная записка
Пояснительная записка включает:
- титульный лист;
- задание на проектирование;
- реферат;
- содержание;
- введение;
- основную часть;
- заключение;
- список использованных источников.
Объем пояснительной записки - до 30 листов рукописного или 20 листов машинописного текста формата А4 по ГОСТ 2.301-68.
Графическая часть
2.2.1 Графическая часть отражает основные результаты проекта и наглядно подтверждает изложенный в пояснительной записке материал.
2.2.2 Графическая часть включает:
- Реализованную схему данных.
- Графическое представление запросов (QBE).
- Таблицы и представления результатов запросов.
- Иерархическую структуру главной кнопочной формы.
2.2.3 Графическая часть расчетно-графической работы должна выполняться в соответствии с ГОСТ 2.105, СТП 3.4.205-01.
Требования к структурным элементам работы
Титульный лист
Титульный лист является первым листом пояснительной записки и выполняется в соответствии с ГОСТ 2.105 и СТП 3.4.204-01 - Требования к оформлению текстовых документов. Форма титульного листа приведена в Приложении А.
Задание
Реферат
3.3.1 Реферат представляет краткое содержание расчетно-графической работы: тема, цель, используемые методы.
3.3.2 В конце реферата указывают объем графической части и пояснительной записки - количество листов с указанием формата, иллюстраций, таблиц, использованных источников.
3.3.3 На листе реферата помещают основную надпись для текстовых документов по форме 2 (Приложение Б1).
Содержание
3.4.1 Содержание оформляют после того, как работа над текстовым документом закончена.
3.4.2 Содержание включает наименование всех структурных элементов пояснительной записки: «Введение», заголовки всех разделов и подразделов, «Заключение», «Список использованных источников» и перечень приложений с указанием номеров страниц, на которых размещены их заголовки.
3.4.3 Оформление содержания приведено в Приложении В.
Введение
Во введении приводится обоснование выбора метода проектирования и выбора СУБД создания БД, краткая характеристика задач исследования, используемых методов расчета, перечень задач проекта, выполненных с помощью компьютера.
Основная часть
Основную часть составляют следующие разделы:
1 Постановка цели и задач работы БД.
2 Концептуальное проектирование реляционной БД.
2.1 Описание предметной области (объекты, их свойства и связи).
2.2 Анализ зависимостей полей, определение ключей и нормализация таблиц или построение ЕR-модели на основе правил формирования отношений.
2.3 Построение реляционной схемы данных.
3 Реализация отношений (описание полей, типов данных, свойств полей и таблиц, связей таблиц с обеспечением целостности данных, различных видов объединения записей).
4 Создание простых и составных форм для ввода и просмотра данных.
5 Обоснование и описание назначения запросов различных типов(5).
6 Реализация запросов с помощью языков QBE и SQL и отображение результатов их исполнения.
7 Реализация интерфейса приложения (структура главной кнопочной формы, простые, составные, кнопочные формы, макросы, VBA-модули)
8 Реализация других объектов ACCESS в приложении (отчетов, страниц доступа к данным)
9 Защита базы данных.
Заключение
3.7.1 Заключение должно содержать выводы, сделанные на основании выполненной работы, в нем дается оценка полученных результатов.
Библиографический список
3.8.1 Список использованных источников должен содержать перечень источников, ссылка на которые имеется в тексте. Сведения об источниках необходимо давать в соответствии с ГОСТ 7.1 2003.
Теоретические основы проектирования базы данных
Метод нормальных форм
Процесс проектирования БД с использованием метода нормальных форм является итерационным и заключается в последовательном переводе отношений из первой нормальной формы в нормальные формы более высокого порядка по определенным правилам. Каждая следующая нормальная форма ограничивает определенный тип функциональных зависимостей, устраняет соответствующие аномалии при выполнении операций над отношениями БД и сохраняет свойства предшествующих нормальных форм.
Выделяют следующую последовательность нормальных форм:
- первая нормальная форма (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 в 2НФ (рисунок 4.1).
R1
| ФИО | Предм | Группа | ВидЗан |
| Иванов И.М. | СУБД | 25-6 | Практ |
| Иванов И.М. | SQL | 12-3 | Практ |
| Петров М.И. | СУБД | 25-6 | Лекция |
| Петров М.И. | Паскаль | 25-6 | Практ |
| Сидоров Н.Г. | SQL | 12-3 | Лекция |
| Сидоров Н.Г. | Паскаль | 25-6 | Лекция |
| Егоров В.В. | ПЭВМ | 24-4 | Лекция |
R2
| ФИО | Должн | Оклад | Стаж | Каф |
| Иванов И.М. | преп | 500 | 5 | 25 |
| Петров М.И. | ст.преп | 800 | 7 | 25 |
| Сидоров Н.Г. | преп | 500 | 10 | 25 |
| Егоров В.В. | преп | 500 | 5 | 24 |
Рисунок 4.1 - Отношения БД в 2НФ
Исследование отношений R1 и R2 показывает, что переход к 2НФ позволил исключить явную избыточность данных в таблице R2 – повторение строк со сведениями о преподавателях.
Для дальнейшего совершенствования отношения необходимо преобразовать его в 3НФ.
Третья нормальная форма. Отношение находится в 3НФ, если оно находится в 2НФ и каждый Неключевой атрибут нетранзитивно зависит от первичного ключа.
Если в отношении R1 транзитивные зависимости отсутствуют, то в отношении R2 они есть:
ФИО 
Должн Оклад
ФИО Оклад Должн
Транзитивные зависимости также порождают избыточное дублирование информации в отношении. Устраним их. Для этого используя операцию проекции на атрибуты, являющиеся причиной транзитивных зависимостей, преобразуем отношение R2, получив при этом отношения R3, R4 и R5, каждое из которых находится в 3НФ (рисунок 4.2)
R3
| ФИО | Должн | Стаж | Каф |
| Иванов И. М. | Преп | 5 | 25 |
| Петров М. И. | Ст. преп | 7 | 25 |
| Сидоров Н. Г. | Преп | 10 | 25 |
| Егоров В. В. | преп | 5 | 24 |
R4
| Должн | Оклад |
| Преп | 500 |
| Ст. преп | 800 |
R5
| Стаж |
| 5 |
| 7 |
| 10 |
Рисунок 4.2 - Отношения БД в 3НФ
На практике построение 3НФ схем отношений в большинстве случаев является достаточным и приведением к ним процесс проектирования реляционной БД заканчивается. Действительно, приведение отношений к 3НФ в нашем примере, привело к устранению избыточного дублирования.
У нас подобной зависимости нет, поэтому процесс проектирования на этом заканчивается. Результатом проектирования является БД, состоящая из следующих таблиц: R1, R3, R4, R5. в полученной БД имеет место необходимое дублирование данных, но отсутствует избыточное
Дата: 2018-11-18, просмотров: 611.
