нормализация БД

Содержание

Слайд 2

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

Иерархическая модель

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

каждый узел содержит свой тип данных (сущность). На верхнем уровне дерева имеется один узел – корень, на следующем уровне располагаются узлы, связанные с этим корнем, затем узлы, связанные с узлами предыдущего уровня, и т. д. Каждый узел может иметь только одного предка.

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

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

Слайд 3

В сетевой модели возможны связи всех информационных объектов со всеми. Например,

В сетевой модели возможны связи всех информационных объектов со всеми. Например,

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

Сетевая модель

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

Слайд 4

Реляционная модель(РМД) Реляционная модель(РМД) была разработана в начале 1970-х годов Эдгаром

Реляционная модель(РМД)

Реляционная модель(РМД) была разработана в начале 1970-х годов Эдгаром

Ф. Коддом. В ней информация представляется в виде двумерных таблиц, а операции сводятся к манипуляциям с таблицами. В 1980-х годах она получила широкое распространение, а реляционные СУБД стали промышленным стандартом.

Причины доминирования РМД обусловлены тем, что имеются:
· развитая теория (реляционная алгебра);
· аппарат сведения других моделей данных к РМД;
·специальные средства ускоренного доступа к информации;
· стандартизированный высокоуровневый язык запросов к БД, позволяющий манипулировать данными без знания физической организации БД.

Слайд 5

Объектно-ориентированная модель Объектно-ориентированная модель начала разрабатываться в 1990-е годы с появлением

Объектно-ориентированная модель

Объектно-ориентированная модель начала разрабатываться в 1990-е годы с появлением

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

Основные понятия реляционной модели данных (1) В математических дисциплинах понятию «таблица»

Основные понятия реляционной модели данных (1)

В математических дисциплинах понятию «таблица» соответствует

понятие «отношение» (relation).
Таблица отражает объект реального мира – сущность, а каждая ее строка отражает конкретный экземпляр сущности.
Каждый столбец имеет уникальное для таблицы имя. Строки не имеют имен, порядок их следования не определен, а количество логически не ограничено. Одним из основных преимуществ РМД является однородность (каждая строка таблицы имеет один формат). Пользователь сам решает вопрос, обладают ли соответствующие сущности однородностью. Этим решается проблема пригодности модели. Основные элементы РМД показаны на рисунке
Слайд 7

Основные понятия реляционной модели данных (2) Отношение представляет собой двумерную таблицу,

Основные понятия реляционной модели данных (2)

Отношение представляет собой двумерную таблицу, содержащую

некоторые данные. Сущность – объект любой природы, данные о котором хранятся в БД. Атрибуты – свойства, характеризующие сущность (столбцы). Степень отношения – количество столбцов. Схема отношения – список имен атрибутов, например, СОТРУДНИК (№, ФИО, Год рождения, Должность, Кафедра). Домен – совокупность значений атрибутов отношения (тип данных). Кортеж – строка таблицы. Кардинальность (мощность) – количество строк в таблице.
Слайд 8

Основные понятия реляционной модели данных (3) Первичный ключ – это атрибут,

Основные понятия реляционной модели данных (3)

Первичный ключ – это атрибут, уникально

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

Основные понятия реляционной модели данных (4) Отношения СТУДЕНТ (ФИО, Группа, Специальность)

Основные понятия реляционной модели данных (4)

Отношения СТУДЕНТ (ФИО, Группа, Специальность) и

ПРЕДМЕТ (Назв Пр, Часы) связаны отношением СТУДЕНТ_ПРЕДМЕТ (ФИО, Назв Пр, Оценка), в котором внешние ключи ФИО и Назв_Пр образуют составной ключ.

Внешний ключ – это атрибут (атрибуты) одной таблицы, который может служить первичным ключом другой таблицы. Является ссылкой на первичный ключ другой таблицы

Слайд 10

Целостность реляционных данных (1) Логические ограничения, накладываемые на данные, называются ограничениями

Целостность реляционных данных (1)

Логические ограничения, накладываемые на данные, называются ограничениями целостности.


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

В РМД существует два вида внутренних ограничений целостности. Целостность по существованию

В РМД существует два вида внутренних ограничений целостности.
Целостность по существованию

– потенциальный ключ отношения не может иметь пустого значения (NULL).
2. Целостность по связи – определяется понятием внешнего ключа
отношения и означает систему правил, используемых для поддержания связей между записями в связанных таблицах. Обеспечивает защиту от случайного удаления или изменения связанных данных, от некорректного изменения ключевых полей

Целостность реляционных данных (2)

Слайд 12

Операции над отношениями (1) РМД стала первой работоспособной моделью данных, поскольку

Операции над отношениями (1)

РМД стала первой работоспособной моделью данных, поскольку имела

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

Реляционная алгебра включает две группы операций.
1. Традиционные операции над множествами (модифицированные с учетом того, что их операндами являются отношения) – объединение, пересечение, разность (вычитание), декартово произведение и деление.
2. Специальные реляционные операции – выборка, проекция, соединение.

Слайд 13

Операции над отношениями (2)

Операции над отношениями (2)

Слайд 14

Операции над отношениями (3)

Операции над отношениями (3)

Слайд 15

Операции над отношениями (4)

Операции над отношениями (4)

Слайд 16

Операции над отношениями (5)

Операции над отношениями (5)

Слайд 17

Операции над отношениями (6)

Операции над отношениями (6)

Слайд 18

Рассмотренные выше операции в той или иной мере реализуются в языке

Рассмотренные выше операции в той или иной мере реализуются в языке

манипулирования данными СУБД (SQL, QBE, другие языки запросов). Язык SQL является более чем реляционно-полным, так как кроме операций реляционной алгебры содержит полный набор операторов над кортежами – Включить, Удалить, Изменить, а также реализует арифметические операции и операции сравнения.

К достоинствам РМД относятся:
·   простота представления данных благодаря табличной форме;
·   минимальная избыточность данных при нормализации отношений;
·   обеспечение независимости приложений пользователя от данных, допускающей включение или удаление отношений, изменение их атрибутного состава;
К недостаткам РМД можно отнести то, что нормализация данных приводит к значительной их фрагментации, в то время как в большинстве задач необходимо объединение фрагментированных данных.

Слайд 19

Нормализация баз данных (1) Данные могут группироваться в таблицы (отношения) разными

Нормализация баз данных (1)

Данные могут группироваться в таблицы (отношения) разными способами.

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

При использовании универсального отношения возникают две проблемы: · избыточность данных; ·

При использовании универсального отношения возникают две проблемы:
·     избыточность данных;
·    

потенциальная противоречивость (аномалии).

Под избыточностью понимают повторение данных в разных строках одной таблицы или в разных таблицах БД. Так, для каждого сотрудника отдела 128 повторяются данные «128, Отдел проектирования».

Аномалии – это проблемы, возникающие в данных из-за дефектов проектирования БД.
Существуют три вида аномалий: вставки, удаления и модификации.
Аномалии вставки проявляются при вводе данных в дефектную таблицу. Добавляя информацию о новом сотруднике, мы должны добавить номер и название отдела. Если ввести данные, не соответствующие имеющимся в таблице (например, 42, отдел проектирования), будет не ясно, какая из строк БД содержит правильную информацию
Аномалии удаления возникают при удалении данных из дефектной схемы. Предположим, что все сотрудники отдела 128 уволились в один и тот же день. После удаления записей этих сотрудников в БД больше не будет ни одной записи, содержащей информацию об отделе 128.
Аномалии модификации возникают при изменении данных дефектной схемы. Предположим, что отдел 128 решили переименовать в отдел передовых технологий. Необходимо изменить соответствующие данные о каждом сотруднике отдела. Если мы пропустим хотя бы одну запись, возникнет аномалия модификации.

Слайд 21

Правилом разработки хорошей структуры БД является необходимость избегать схем с большим

Правилом разработки хорошей структуры БД является необходимость избегать схем с большим

числом пустых атрибутов. Если мы хотим указать, что один из ста служащих имеет особую квалификацию, для хранения этой информации не следует добавлять в таблицу еще один столбец, поскольку для остальных 99 работников значением столбца будет NULL. Вместо этого следует добавить новую таблицу, в которой будут храниться только кодовые номера и информация о квалификации тех работников, которых это касается.
Решение перечисленных проблем состоит в разделении данных и связей, что обеспечивается процедурой нормализации. Концепции и методы нормализации были разработаны Э. Ф. Коддом.

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

Нормализация баз данных (2)

Слайд 22

Теория нормализации основана на наличии зависимостей между атрибутами отношения. Основными видами

Теория нормализации основана на наличии зависимостей между атрибутами отношения. Основными видами

зависимостей являются:
· функциональные;
· многозначные;
· транзитивные.
Базовым является понятие функциональной зависимости, поскольку на его основе формируются определения всех остальных видов зависимостей. Атрибут В функционально зависит от атрибута А, если каждому значению А соответствует в точности одно значение В. Математически функциональную зависимость В от А обозначают А ’ В. Это означает, что во всех кортежах с одинаковым значением атрибута А атрибут В будет иметь также одно и то же значение. При этом А и В могут быть составными, то есть состоять из двух и более атрибутов.

Нормализация баз данных (3)

Зависимость, при которой каждый неключевой атрибут зависит от всего составного ключа и не зависит от его частей, называется полной функциональной зависимостью. Если атрибут А зависит от атрибута В, а атрибут В зависит от атрибута С (С ’ В ’ А), но обратная зависимость отсутствует, то зависимость А от С называется транзитивной.

Слайд 23

Многозначная зависимость. Говорят, что один атрибут отношения многозначно определяет другой атрибут

Многозначная зависимость. Говорят, что один атрибут отношения многозначно определяет другой атрибут

того же отношения, если для каждого значения первого атрибута существует множество соответствующих значений второго атрибута. Многозначные зависимости могут быть:
·   один-ко-многим (1:М);
·   многие-к-одному (М:1);
·   многие-ко-многим (М:М).

Нормализация баз данных (4)

Слайд 24

Каждая ступень процесса нормализации приводит схему отношений в последовательные нормальные формы.

Каждая ступень процесса нормализации приводит схему отношений в последовательные нормальные формы.

Для каждой ступени имеются наборы ограничений. Выделяют следующую последовательность нормальных форм:
·   первая нормальная форма (1НФ);
·   вторая нормальная форма (2НФ);
·   третья нормальная форма (3НФ);
·   усиленная 3НФ или нормальная форма Бойса-Кодда (БКНФ);
·   четвертая нормальная форма (4НФ);
·  пятая нормальная форма (5НФ).

Нормализация баз данных (5)

Слайд 25

Отношение находится в первой нормальной форме (1НФ), когда каждая строка содержит

Отношение находится в первой нормальной форме (1НФ), когда каждая строка содержит

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

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

Нормализация баз данных (6)

Слайд 26

Отношение находится во второй нормальной форме (2НФ), если оно находится в

Отношение находится во второй нормальной форме (2НФ), если оно находится в

1НФ, и каждый неключевой атрибут полностью функционально зависит от всех составляющих первичного ключа. Если атрибут не зависит полностью от первичного ключа, то он внесен ошибочно и должен быть удален. Нормализация производится путем нахождения существующего отношения, к которому относится данный атрибут, или созданием нового отношения, в который атрибут должен быть помещен.
Таблица Квалификации_сотрудников (табл. 14) находится в 1НФ, но не удовлетворяет 2НФ. Первичный ключ должен уникальным образом идентифицировать каждую строку. Единственным вариантом является использование в качестве первичного ключа комбинации Код сотрудника и Квалификация. Это порождает схему: Квалификации_сотрудников (Код сотрудника, ФИО, Должность, Номер отдела, Наименование отдела, Квалификация).
Одной из имеющихся здесь функциональных зависимостей будет: Код сотрудника, Квалификация ’ ФИО, Должность, Номер отдела, Наименование отдела. Но, кроме того, мы также имеем: Код сотрудника ’ ФИО, Должность, Номер отдела, Наименование отдела. Другими словами, можно определить имя, должность и отдел, используя только код сотрудника. Это значит, что указанные атрибуты функционально зависимы только от части первичного ключа, а не от всего первичного ключа. Следовательно, указанная схема не находится в 2НФ.

Нормализация баз данных (7)

Слайд 27

Для приведения этой схемы в 2НФ необходимо декомпозировать исходное отношение на

Для приведения этой схемы в 2НФ необходимо декомпозировать исходное отношение на

два, в которых все неключевые атрибуты будут полностью функционально зависеть от ключа: сотрудники (Код сотрудника, ФИО, Должность, Номер отдела, Наименование отдела) и Квалификации_сотрудников (Код сотрудника, Квалификация) (табл. 15–16).
Таблица 15 Таблица 16

Нормализация баз данных (8)

Слайд 28

Отношение находится в третьей нормальной форме (ЗНФ), если оно находится во

Отношение находится в третьей нормальной форме (ЗНФ), если оно находится во

2НФ и ни один из его неключевых атрибутов не связан функциональной зависимостью с любым другим неключевым атрибутом. Атрибуты, зависящие от других неключевых атрибутов, нормализуются путем перемещения зависимого атрибута и атрибута, от которого он зависит, в новое отношение.
Формально, для приведения схемы в 3НФ необходимо исключить все транзитивные зависимости. Схема отношения сотрудники (табл. 15) содержит следующие функциональные зависимости: Код сотрудника ’ ФИО, Должность, Номер отдела, Наименование отдела и Номер отдела ’ Наименование отдела.
Первичным ключом является Код сотрудника, и все атрибуты полностью функционально зависимы от него (первичный ключ определяется единственным атрибутом). При этом Номер отдела ключом не является.

Нормализация баз данных (8)

Слайд 29

Функциональная зависимость Код сотрудника ’ Наименование отдела является транзитивной, поскольку содержит

Функциональная зависимость Код сотрудника ’ Наименование отдела является транзитивной, поскольку содержит

промежуточный шаг (зависимость Номер отдела ’ Наименование отдела). Для приведения в 3НФ необходимо исключить эту транзитивную зависимость, декомпозируя отношение на два: сотрудники (Код сотрудника, ФИО, Должность, Номер отдела) и отделы (Номер отдела, Наименование отдела) (табл. 17–18).
Таблица 17 Таблица 18

Нормализация баз данных (9)

Слайд 30

Нормальная форма Бойса-Кодда (БКНФ) является развитием ЗНФ и требует, чтобы в

Нормальная форма Бойса-Кодда (БКНФ) является развитием ЗНФ и требует, чтобы в

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

Рис. 15. Алгоритм приведения ненормализованных схем в 3НФ

Нормализация баз данных (10)