Файл: Учебное пособие СанктПетербург 2017.pdf

ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 10.11.2023

Просмотров: 176

Скачиваний: 5

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

20 2. Отсутствие кортежей-дубликатов
То свойство, что отношения не содержат кортежей-дубликатов, следует из определения отношения как множества кортежей.
В классической теории множеств каждое множество, по определе-
нию, состоит из различных элементов.
Из этого свойства вытекает наличие у каждого отношения, так на-
зываемого, первичного ключа – набора атрибутов, значения которых одно-
значно определяют кортеж отношения.
Понятие первичного ключа является исключительно важным в связи с понятием целостности баз данных. Первичный ключ, является одним из ос- новных видов ограничений в базе данных. Он предназначен для однозначной идентификации записи в таблице, и должен быть уникальным
Первичным ключом (ключом отношения, ключевым атрибу-
том)называется атрибут отношения, однозначно идентифицирующий каж- дый из его кортежей.
Первичные ключи находятся в таблицах, которые принято называть родительскими. Например, в отношении СОТРУДНИК(ФИО, Отдел, Долж- ность, Д_Рождения) первичным ключом является атрибут «ФИО». Ключ мо- жет быть составным (сложным),то есть состоять из нескольких атрибутов.
Ключи обычно используют для достижения следующих целей:
1) исключения дублирования значений в ключевых атрибутах (ос- тальные атрибуты в расчет не принимаются);
2) упорядочения кортежей;
3) ускорения работы с кортежами отношения;
4) организации связывания таблиц (подраздел 2.3).
Пусть в отношении R
1
имеется неключевой атрибут А, значения которо- го являются значениями ключевого атрибута В другого отношения R
2
. Тогда говорят, что атрибут А отношения R
1
есть внешний ключ.
Внешний ключ – это столбец или набор столбцов в дочерней таблице, который в точности соответствует столбцу или набору столбцов, определен- ных в родительской таблице как первичный (или уникальный) ключ, и ссы- лается на них.
С помощью внешних ключей устанавливаются связи между отноше- ниями. Например, имеются два отношения СТУДЕНТ(ФИО, Группа, Специ- альность) и ПРЕДМЕТ(Назв.Пр, Часы), которые связаны отношением СТУ-
ДЕНТ_ПРЕДМЕТ(ФИО, Назв.Пр, Оценка) (рис. 10). В связующем отношении атрибуты ФИО и Назв.Пр образуют составной ключ. Эти атрибуты представ- ляют собой внешние ключи, являющиеся первичными ключами других отно- шений.


21
Рисунок 10 – Связь отношений
Реляционная модель накладывает на внешние ключи ограничение для обеспечения целостности данных, называемое ссылочной целостностью. Это означает, что каждому значению внешнего ключа должны соответствовать строки в связываемых отношениях.
Поскольку не всякой таблице можно поставить в соответствие отноше- ние, приведем условия, выполнение которых позволяет таблицу считать от- ношением.
1. Все строки таблицы должны быть уникальны, то есть не может быть строк с одинаковыми первичными ключами.
2. Имена столбцов таблицы должны быть различны, а значения их про- стыми, то есть недопустима группа значений в одном столбце одной строки.
3. Все строки одной таблицы должны иметь одну структуру, соответст- вующую именам и типам столбцов.
4. Порядок размещения строк в таблице может быть произвольным.
В общем случае можно считать, что БД включает одну или несколько таблиц, объединенных смысловым содержанием, а также процедурами кон- троля целостности и обработки информации в интересах решения некоторой прикладной задачи. Например, при использовании СУБД MicrosoftAccess в файле БД наряду с таблицами хранятся и другие объекты базы: запросы, от- четы, формы, макросы и модули.
К отношениям можно применять систему операций, позволяющую по- лучать одни отношения из других. Например, результатом запроса к реляци- онной БД может быть новое отношение, вычисленное на основе имеющихся отношений.
В таблицах БД должны сохраняться все данные, необходимые для ре- шения задач предметной области. Причем каждый элемент данных должен храниться в базе только в одном экземпляре. Для создания таблиц, соответ- ствующих реляционной модели данных, используется процесс, называемый нормализацией данных. Нормализация — это процесс, который позволяет получить таблицы без повторяющихся данных. Минимальное дублирование данных в реляционной базе обеспечивает высокую эффективность поддер- жания БД в актуальном и непротиворечивом состоянии, однократный ввод и корректировку данных.

22
2.3 Виды связей между таблицами
Между двумя или более таблицами базы данных могут существовать отношения подчиненности, которые определяют, что для каждой записи главной таблицы (родительской) возможно наличие одной или нескольких записей в подчиненной таблице (дочерней).
В нормализованной реляционной БД выделяют три разновидности свя- зи между таблицами:
1) «один-ко-многим» (1:М);
2) «один-к-одному»(1:1);
3) «многие-ко-многим» (М:М).
Отношение «один-ко-многим» имеет место, когда одной записи роди- тельской таблицы может соответствовать несколько записей дочерней. Связь "один-ко-многим" иногда называют связью "многие-к-одному". И в том, и в другом случае сущность связи между таблицами остается неизменной. Связь "один-ко-многим" является самой распространенной для реляционных БД.
На рис. 11 показаны две таблицы со списком покупателей и перечнем заключенных договоров, которые находятся в отношении типа 1: M и логи- чески связаны с помощью общего поля (столбца) Код покупателя — ключа связи. Это поле является уникальным ключом в главной таблице — ПОКУ-
ПАТЕЛЬ, и неключевым полем в подчиненной таблице — ДОГОВОР.
Рисунок 11 – Взаимосвязанные таблицы реляционной БД
Размещение сведений о каждой сущности в отдельной таблице и свя- зывание таблиц позволяет избежать повторения значений данных в разных таблицах. При этом обеспечивается однократный ввод данных при загрузке и корректировке БД. При хранении данных в двух таблицах сведения о поку- пателе хранятся в единственном экземпляре, а в таблице договоров повторя- ются только значения ключевого поля с кодом покупателя.


23
Отношение «один-к-одному» имеет место, когда одной записи в роди- тельской таблице соответствует одна запись в дочерней. Это отношение встречается намного реже, чем отношение "один-ко-многим".
Отношение «один-к-одному» может использоваться для разделения таблиц, содержащих много полей, для отделения части таблицы по сообра- жениям безопасности, а также для сохранения сведений, относящихся к под- множеству записей в главной таблице.
Отношение «многие-ко-многим» имеет место, когда каждая запись в одной таблице связана с несколькими записями в другой таблице и наоборот.
Всякую связь "многие-ко-многим" в реляционной базе данных необхо- димо заменить на связь "один-ко-многим" (одну или более) с помощью вве- дения дополнительных таблиц (рис. 12).
Рисунок 12 – Устранение связи «многие-ко-многим»
2.4 Нормализация отношений
Главная цель нормализации отношений базы данных – устранение из- быточности и дублирования информации. В идеале при нормализации надо добиться, чтобы любое значение хранилось в базе в одном экземпляре, при- чем значение это не должно быть получено расчетным путем из других дан- ных, хранящихся в базе.
Приведение модели к требуемому уровню нормальной формы является
основой построения реляционной базы данных.
В теории реляционных баз данных обычно выделяется следующая по- следовательность нормальных форм:
1) первая нормальная форма (1NF);
2) вторая нормальная форма(2NF);
3) третья нормальная форма(3NF);
4) нормальная форма Бойса-Кодда (BCNF);
5) четвертая нормальная форма(4NF);
6) пятая нормальная форма, или нормальная форма проекции-соединения
(5NF или PJ/NF).
Основные свойства нормальных форм:

каждая следующая нормальная форма в некотором смысле лучше предыдущей;

при переходе к следующей нормальной форме свойства предыду- щих нормальных форм сохраняются.

24
В основе нормализации лежит декомпозиция отношения, находящегося в предыдущей нормальной форме, в два или более отношений, удовлетво- ряющих требованиям следующей нормальной формы.
Наиболее важные на практике нормальные формы отношений основы- ваются на фундаментальном в теории реляционных баз данных понятии
функциональной зависимости:
1. В отношении R атрибут Y функционально зависит от атрибута X(X и
Y могут быть составными) в том и только в том случае, если каждому значе- нию X соответствует в точности одно значение Y: R.X→R.Y.
2. Функциональная зависимость R.X → R.Y называется полной, если атрибут Y не зависит функционально от любого подмножества X.
3. Функциональная зависимость R.X→ R.Y называется транзитивной, если существует такой атрибут Z, что имеются функциональные зависимости
R.X →R.Z и R.Z → R.Y и отсутствует функциональная зависимость R.Z → R.X.
При отсутствии последнего требования имелись бы транзитивные зави- симости в любом отношении, обладающем несколькими ключами.
Неключевым атрибутом называется любой атрибут отношения, не вхо- дящий в состав первичного ключа (в частности, первичного).
Два или более атрибута взаимно независимы, если ни один из этих ат- рибутов не является функционально зависимым от других.
База данных считается нормализованной, если ее таблицы представле- ны как минимум в третьей нормальной форме. Часто многие таблицы норма- лизуются до четвертой нормальной формы, иногда, наоборот, производится денормализация. Использования таблиц в пятой нормальной форме в реаль- ных базах данных встречается редко.
Первая нормальная форма (1NF)
Отношение R находится в первой нормальной форме (1NF) в том и
только в том случае, если значения его атрибутов атомарны (неделимы).
Например, отношение КНИГА(АВТОР, НАЗВАНИЕ, ВЫХОД-
НЫЕ_ДАННЫЕ)не находится в первой нормальной форме, так как атрибут
ВЫХОДНЫЕ_ДАННЫЕ можно разделить на атрибуты: ИЗДАТЕЛЬСТВО,
ГОД, КОЛИЧЕСТВО_СТРАНИЦ.
Вторая нормальная форма (2NF)
Отношение R находится в2NF в том и только в том случае, когда на-
ходится в 1NF, и каждый неключевой атрибут функционально полно зави-
сит от первичного ключа.
Если допустить наличие нескольких ключей, то данное определение примет следующий вид:
Отношение R находится в2NF в том и только в том случае, когда оно
находится в 1NF, и каждый неключевой атрибут полностью зависит от
каждого ключа R.


25
Например, отношение УСПЕВАЕМОСТЬ(НОМЕР, ФАМИЛИЯ, ДИС-
ЦИПЛИНА, ОЦЕНКА) находится в 1НФ и имеет составной ключ НОМЕР +
ДИСЦИПЛИНА. Это отношение не находится в 2НФ, так как атрибут ФА-
МИЛИЯ функционально зависим от поля НОМЕР составного ключа. Чтобы привести это отношение к 2НФ необходимо разбить его на два связанных от- ношения:
УСПЕВАЕМОСТЬ(НОМЕР, ДИСЦИПЛИНА, ОЦЕНКА),
СПИСОК(НОМЕР, ФАМИЛИЯ).
Связь между отношениями осуществляется по полю НОМЕР.
Третья нормальная форма (3НФ)
Отношение находится в 3НФв том и только в том случае, когда нахо-
дится в 2НФ, и отсутствуют транзитивные функциональные зависимости
неключевых атрибутов от ключевых.
Транзитивная зависимость присутствует в отношении, если существует два неключевых поля, первое из которых зависит от ключа, а второе от пер- вого.
Отношение ДИСЦИПЛИНА(НАЗВАНИЕ, ЛЕКТОР, УЧ_СТЕПЕНЬ,
ГРУППА) не находится в 3НФ, так как поле УЧ_СТЕПЕНЬ зависит от поля
ЛЕКТОР, но не от составного ключа, поэтому отношение необходимо раз- бить на два связанных отношения
ДИСЦИПЛИНА(НАЗВАНИЕ, ЛЕКТОР, ГРУППА),
ПРЕПОДАВАТЕЛЬ(ЛЕКТОР, УЧ_СТЕПЕНЬ).
На практике третья нормальная форма схем отношений достаточна в большинстве случаев, и приведением к третьей нормальной форме процесс проектирования реляционной базы данных обычно заканчивается. Однако иногда полезно продолжить процесс нормализации.
Нормальная форма Бойса-Кодда (BCNF)
Эта форма применяется к отношениям, имеющим детерминант.
Детерминант – любой атрибут, от которого полностью функцио-
нально зависит некоторый другой атрибут.
Отношение R находится в нормальной форме Бойса-Кодда (BCNF) в
том и только в том случае, если каждый детерминант является возмож-
ным ключом.
Если в отношении между двумя атрибутами существует многозначная зависимость, то нормализовать его можно с помощью четвертой нормальной формы.
Четвертая нормальная форма (4NF)
В отношении R (A, B, C) существует многозначная зависимость
R.A

R.B в том и только в том случае, если множество значений B, соот-

26
ветствующее паре значений A и C, зависит только от A и не зависит от С.
Отношение R находится в четвертой нормальной форме (4NF) в том
и только в том случае, если в случае существования многозначной зависимо-
сти A

B все остальные атрибуты R функционально зависят от A.
Пятая нормальная форма (PJ/NF)
Во всех рассмотренных до этого момента нормализациях производи- лась декомпозиция одного отношения в два. Иногда это сделать не удается, но возможна декомпозиция в большее число отношений, каждое из которых обладает лучшими свойствами.
Отношение R (X, Y, ..., Z) удовлетворяет зависимости соединения * (X,
Y, ..., Z) в том и только в том случае, когда R восстанавливается без потерь
путем соединения своих проекций на X, Y, ..., Z.
Под проецированием без потерь понимается такой способ декомпози- ции отношения, при котором исходное отношение полностью и без избыточ- ности восстанавливается путем естественного соединения полученных отно- шений.
Отношение R находится в пятой нормальной форме (нормальной
форме проекции-соединения – PJNF) в том и только в том случае, когда лю-
бая зависимость соединения в R следует из существования некоторого воз-
можного ключа в R.
Пятая нормальная форма – это последняя нормальная форма, которую можно получить путем декомпозиции. Ее условия достаточно нетривиальны, и на практике 5NF не используется. Заметим, что зависимость соединения является обобщением, как многозначной зависимости, так и функциональной зависимости.
1   2   3   4   5   6   7   8   9   ...   12

3 ПРОЕКТИРОВАНИЕ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ
3.1 Основные задачи и этапы проектирования
Проектирование баз данных — это процесс создания схемы базы дан-
ных и определения необходимых ограничений целостности. Основными за- дачами проектирования баз данных являются:

Обеспечение хранения в БД всей необходимой информации.

Обеспечение возможности получения данных по всем необходимым запросам.

Сокращение избыточности и дублирования данных.

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

27 области в терминах некоторой модели. В общем случае можно выделить сле- дующие этапы проектирования (рис. 13):
Рисунок 13 – Этапы проектирования БД
Решение проблем проектирования на физическом уровне во многом за- висит от используемой СУБД, зачастую автоматизировано и скрыто от поль- зователя. В ряде случаев пользователю предоставляется возможность на- стройки отдельных параметров системы, которая не составляет большой проблемы.
Логическое проектирование заключается в определении числа и струк- туры таблиц, формировании запросов к БД, определении типов отчетных до- кументов, разработке алгоритмов обработки информации, создании форм для ввода и редактирования данных в базе и решении ряда других задач.
Решение задач логического проектирования БД в основном определя- ется спецификой задач предметной области. Наиболее важной здесь является
проблема структуризации данных.
3.2 Методы проектирования реляционных баз данных
Основная проблема проектирования реляционной базы данных состоит в обоснованном принятии решений о том, из каких отношений должна состо- ять БД и какие атрибуты должны быть у этих отношений.
Для построения «хорошей» базы данных, которая находилась хотя бы в

28 третьей нормальной форме, можно использовать следующие методы:
1) Метод нормальных формметод пошаговой декомпозиции, за- ключающийся в последовательном разбиении исходной и промежу- точных схем отношений до тех пор, пока результирующие отноше- ния не будут удовлетворять заданным свойствам.
2) Метод синтеза, состоящий в конструировании (синтезе) набора декомпозиционных подсхем, удовлетворяющих определѐнным свойствам, из заданного множества атрибутов выбранной предмет- ной области на основе заданного множества функциональных зави- симостей, связывающих эти атрибуты.
3) Метод ER-диаграммемантическое моделирование) представ- ляет собой моделирование структуры данных, опираясь на смысл этих данных. В качестве инструмента семантического моделирова- ния используются различные варианты диаграмм сущность-связь
(ER – Entity-Relationship).
1. Метод нормальных форм (классический метод)представляет собой вариант восходящего подхода при проектировании БД. Нормализация преду- сматривает идентификацию требуемых атрибутов с последующим созданием из них нормализованных таблиц, основанных на функциональных зависимо- стях между этими атрибутами (подраздел 2.4).
Восходящий подход в наибольшей степени приемлем для проектиро- вания простых (как правило, централизованных) БД с относительно неболь- шим количеством атрибутов. Однако использование этого подхода сущест- венно усложняется при проектировании распределенных БД, особенно при интеграции локальных баз данных, которые могут быть выполнены с исполь- зованием различных моделей данных с большим количеством атрибутов, ус- тановить среди которых все существующие функциональные зависимости довольно затруднительно
2. Более подходящей стратегией проектирования сложных баз данных яв- ляется использование нисходящего подхода (метода синтеза). Начинается этот подход с разработки моделей данных, которые содержат несколько высокоуров- невых сущностей и связей, затем работа продолжается в виде серии нисходящих уточнений низкоуровневых сущностей, связей и относящихся к ним атрибутов.
Например, сначала можно было бы идентифицировать сущности ВЛАДЕЛЕЦ и
ОБЪЕКТ_НЕДВИЖИМОСТИ, затем установить между ними связь ВЛАДЕЛЕЦ владеет ОБЪЕКТОМ_НЕДВИЖИМОСТИ и лишь после этого определить свя- занные с ними атрибуты — например, ВЛАДЕЛЕЦ (номер_вл, имя_вл, адрес_вл) и ОБЪЕКТ_НЕДВИЖИМОСТИ(номер_об, адрес_об).
3. Все варианты диаграмм сущность-связь исходят из одной идеи – ри- сунок всегда нагляднее текстового описания. Все такие диаграммы исполь- зуют графическое изображение сущностей предметной области, их свойств
(атрибутов), и взаимосвязей между сущностями.