Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Метод_указ_л_р.doc
Скачиваний:
23
Добавлен:
14.08.2019
Размер:
8.67 Mб
Скачать

2. Лабораторная работа №2. Проектирование структуры базы данных

Цель работы: разработка базы данных, включающей в себя несколько взаимосвязанных таблиц.

Задачи работы:

  • познакомиться с назначением и содержанием этапа проектирования структуры базы данных;

  • освоить применение процедуры нормализации отношений;

  • овладеть средствами СУБД Microsoft Access, позволяющими определять, изменять и удалять связи между таблицами базы данных;

  • изучить способы удаления информации из связанных таблиц и восстановления этой информации;

  • закрепить навыки работы по созданию и модификации структуры таблиц, заполнению таблиц в среде Microsoft Access.

2.1. Общие сведения

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

2.1.1. Постановка задачи №1

Разработать структуру базы данных в соответствии с приведенным ниже описанием предметной области «Университет». Применить при разработке структуры БД процедуру нормализации.

Объекты предметной области: ФАКУЛЬТЕТ, СПЕЦИАЛЬНОСТЬ, АБИТУРИЕНТ.

Список характеристик (свойств, атрибутов) объектов предметной области:

  • код факультета, название факультета;

  • код специальности, название специальности;

  • код, фамилия, имя, отчество абитуриента, дата рождения, домашний адрес, телефон, пол, средний балл аттестата абитуриента, дата подачи документов;

Реализовать полученную структуру средствами СУБД Access путем модификации структуры БД УНИВЕРСИТЕТ, созданной в лабораторной работе №1.

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

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

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

Список характеристик (свойств, атрибутов) объектов предметной области:

  • код факультета, название факультета;

  • код специальности, название специальности;

  • код абитуриента, ФИО абитуриента;

  • дата проведения экзамена; название предмета; оценки каждого абитуриента по каждому предмету.

После определения совокупности атрибутов их необходимо свести в одну таблицу – исходное (или универсальное) отношение. Для небольших БД (включающих порядка 15 атрибутов) универсальное отношение может использоваться в качестве отправной точки при проектировании БД. Таблица считается отношением, если все ее атрибуты имеют атомарные (простые) значения. Другими словами, в таблице не должно быть ячеек, содержащих в себе несколько значений. Несколько значений, размещенных в одной ячейке, называют повторяющейся группой.

Первоначальным вариантом такой таблицы является таблица АБИТУРИЕНТЫ (табл. 2.1). Эта таблица не является отношением, поскольку в ней имеются повторяющиеся группы данных для атрибутов КодАбитуриента, ФИО, ДатаПодачиДокументов. Повторяющиеся группы выделены в таблице серым цветом.

Таблица 2.1 – Ненормализованная таблица АБИТУРИЕНТЫ

Код

Аб.

ФИО

Дата Подачи Документов

Код

Факуьтета

Название

Факультета

Код

Специальности

Название

Специальности

1

Петров П.П.

01.06.2009

ИС

Информационные системы

ПИ

Прикладная информатика (в экономике)

2

Иванов И.И.

12.06.2009

3

Сидоров И.И.

12.06.2009

4

Петров П.П.

01.06.2009

МСиЭ

Математики, статистики и эконометрики

Прикладная информатика (в экономике)

. . .

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

Таблица 2.2 – Нормализованная таблица АБИТУРИЕНТЫ

Код

Аб.

ФИО

Дата Подачи Документов

Код

Факуьтета

Название

Факультета

Код

Специальности

Название

Специальности

1

Петров П.П.

01.06.2009

ИС

Информационные системы

ПИ

Прикладная информатика (в экономике)

2

Иванов И.И.

12.06.2009

ИС

Информационные системы

ПИ

Прикладная информатика (в экономике)

3

Сидоров И.И.

12.06.2009

ИС

Информационные системы

ПИ

Прикладная информатика (в экономике)

4

Петров С.П.

01.06.2009

МСиЭ

Математики, статистики и эконометрики

МО

Менеджмент организации

. . .

Однако такое преобразование приводит к возникновению большого объема избыточных данных. Данные практически всех столбцов многократно повторяются (дублируются). Повторяются и некоторые наборы данных (КодФакультетаНазваниеФакультета, КодСпециальностиНазваниеСпециальности).

Избыточное дублирование не только требует расхода дополнительной памяти для хранения избыточных данных, но и является причиной аномалий в БД.

Аномалиями называют такую ситуацию в таблицах БД, которая приводит к противоречиям в БД, либо существенно усложняет обработку данных. Различают три основных вида аномалий: аномалии модификации (редактирования), аномалии удаления и аномалии добавления. Аномалии модификации проявляются в том, что изменение значения одного поля может повлечь за собой просмотр всей таблицы и соответствующее изменение некоторых других записей. Например, изменение названия факультета в таблице АБИТУРИЕНТЫ (табл. 2.2) потребует корректировки записей обо всех абитуриентах, поступающих на этот факультет. Аномалии удаления состоят в том, что при удалении какой либо записи таблицы может пропасть и другая информация, не связанная напрямую с удаляемыми данными. В той же таблице удаление записи о студенте Петрове С.П. приводит к исчезновению информации о факультете и специальности, на которые он поступает. Аномалии добавления возникают в случаях, когда информацию в таблицу нельзя поместить до тех пор, пока она неполная, либо вставка новой записи требует дополнительного просмотра таблицы. Примером может служить невозможность хранить в таблице АБИТУРИЕНТЫ (табл. 2.2) данные о факультетах и специальностях, пока ни один абитуриент не подал документы на данную специальность.

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

  • сэкономить объем используемой памяти;

  • уменьшить затраты на многократные операции обновления избыточных копий;

  • устранить возможность возникновения противоречий в БД из-за хранения в разных местах сведений об одном и том же объекте.

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

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

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

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

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

  • нормальная форма Бойса-Кодда (БКНФ);

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

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

Первые три этапа нормализации были описаны Э.Ф. Коддом в 1972 г. При решении практических задач обычно бывает достаточно выполнить первые три этапа, то есть привести отношение к 3НФ, поэтому в данной лабораторной работе мы рассмотрим первые 3 этапа нормализации отношения АБИТУРИЕНТЫ

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