Какую цель преследует нормализация баз данных обеспечить
Обновлено: 04.07.2024
Проектирование реляционной БД заключается в разработке структуры данных, т.е. в определении состава таблиц и связей между ними. При этом структура должна быть эффективной и обеспечивать: быстрый доступ к данным; отсутствие дублирования (повторения) данных; целостность данных.
Проектирование БД можно представить следующим образом:
- Сбор всей информации об объектах решаемой задачи в рамках одной таблицы (одного отношения)
- Разбиение полученной таблицы на несколько взаимосвязанных таблиц на основе принципа нормализации отношений.
Нормализация – это разбиение таблицы на две или более, обладающих лучшими свойствами при включении, изменении и удалении данных. Цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, т.е. исключена избыточность информации. Это делается не столько с целью экономии памяти, сколько для исключения возможной противоречивости хранимых данных.
В теории реляционных баз данных обычно выделяется следующая последовательность нормальных форм:
первая нормальная форма (1NF); вторая нормальная форма (2NF); третья нормальная форма (3NF); нормальная форма Бойса-Кодда (BCNF); четвертая нормальная форма (4NF); пятая нормальная форма, или нормальная форма проекции-соединения (5NF или PJ/NF).
Основные свойства нормальных форм: каждая следующая нормальная форма в некотором смысле лучше предыдущей; при переходе к следующей нормальной форме свойства предыдущих нормальных свойств сохраняются.
Теория нормализации основывается на наличии той или иной зависимости между полями таблицы.
Основными считаются первые 3 нормальные формы:
1НФ - таблица находится в первой нормальной форме (1НФ) тогда и только тогда, когда ни одна из ее строк не содержит в любом своем поле более одного значения и ни одно из ее ключевых полей не пусто. (Любое поле таблицы содержит неделимую информацию и в таблице определен первичный ключ)
2НФ - Таблица находится во второй нормальной форме (2NF) в том и только в том случае, когда находится в 1NF, и каждый ее неключевой атрибут полностью зависит от первичного ключа. (Таблица должна удовлетворять 1NF и любое неключевое поле должно однозначно идентифицироваться ключевыми полями.)
3НФ – Таблица находится в третьей нормальной форме (3NF) в том и только в том случае, если находится в 2NF и каждый неключевой атрибут нетранзитивно зависит от первичного ключа. (Таблица должна удовлетворять 2NF и ни одно из неключевых полей не должно однозначно идентифицироваться значением другого неключевого поля (полей))
27 Проектирование баз данных
В реляционных базах данных любая таблица рассматривается как отношение между ключем и остальными элементами данных в строке (сам термин "реляционная" от relation - отношение). Таким образом, процесс проектирования базы данных - это определение состава отношений.
Процесс проектирования состоит из следующих этапов:
1) определение объектов, сведения о которых отображаются в базе данных;
2) определение связей между объектами;
3) определение атрибутов объектов;
4) нормализация отношений.
Различают три типа взаимосвязей между объектами:
1) взаимосвязь "один к одному" (обозначается ): каждому экземпляру объекта одного типа соответствует один и только один экземпляр объекта другого типа. На практике такой тип взаимосвязи встречается достаточно редко, т.к. такие отношения можно без потери общности объединить в одно. Разделение информации между двумя отношениями может иметь смысл из соображений производительности и секретности. Например, все сведения о преподавателях разделяются на активно используемую небольшую таблицу основных сведений (табельный номер, ФИО, должность, кафедра) и большую, редко используемую таблицу анкетных данных, доступ к которой ограничен соответствующим уровнем полномочий;
2) взаимосвязь "один ко многим" (обозначается >): одному экземпляру первого (родительского) объекта соответствует несколько экземпляров второго (дочернего) объекта. Это основной вид связи между объектами.
3) взаимосвязь "многие ко многим" (обозначается >): одному экземпляру первого объекта соответствует несколько экземпляров второго и наоборот. Такой вид связи не допускается в реляционных базах данных непосредственно и реализуется путем введения промежуточного объекта, хранящего идентификаторы связанных объектов.
Третий этап проектирования - определение атрибутов объектов.
В состав атрибутов объекта должны быть включены:
1) ключевые атрибуты, однозначно определяющие экземпляр объекта;
2) ключи связанных объектов. Для связи "один к одному" каждый объект должны содержать ключ связанного, или оба объекта должны иметь одинаковое значение ключа для связанных экземпляров (например, табельный номер преподавателя как ключ в обоих таблицах: основных сведений и анкетных данных). Для связи "один ко многим" дочерний объект должен содержать ключ родительского;
3) неключевые атрибуты, характеризующие объект.
Состав отношений и группировку атрибутов по отношениям в базе данных можно определить различными способами. Для получения наиболее рациональной совокупности отношений используется их нормализация (4-й этап проектирования БД).
Нормализация базы данных - это процесс структурирования базы данных , обычно реляционной базы данных , в соответствии с серией так называемых нормальных форм с целью уменьшения избыточности данных и улучшения целостности данных . Впервые он был предложен Эдгаром Ф. Коддом как часть его реляционной модели .
Нормализация влечет за собой организацию столбцов (атрибутов) и таблиц (отношений) базы данных, чтобы гарантировать, что их зависимости должным образом обеспечиваются ограничениями целостности базы данных. Это достигается путем применения некоторых формальных правил либо путем синтеза (создание нового проекта базы данных), либо декомпозиции (улучшения существующего проекта базы данных).
СОДЕРЖАНИЕ
Цели нормализации за пределами 1NF (первая нормальная форма) были сформулированы Коддом следующим образом:
- Чтобы освободить коллекцию отношений от нежелательных зависимостей вставки, обновления и удаления.
- Чтобы уменьшить потребность в реструктуризации коллекции отношений по мере появления новых типов данных и, таким образом, увеличить срок службы прикладных программ.
- Сделать реляционную модель более информативной для пользователей.
- Сделать набор отношений нейтральным по отношению к статистике запросов, где эта статистика может меняться с течением времени.
Вставки аномалии . До тех пор, пока новому преподавателю, доктору Ньюсому, не будет поручено вести хотя бы один курс, их подробности не могут быть записаны.
Удаления аномалия . Вся информация о докторе Гидденсе теряется, если они временно перестают быть назначенными на какие-либо курсы.
Когда делается попытка изменить (обновить, вставить или удалить) отношение, в отношениях, которые не были в достаточной степени нормализованы, могут возникнуть следующие нежелательные побочные эффекты:
Минимизация редизайна при расширении структуры базы данных
Полностью нормализованная база данных позволяет расширять ее структуру для размещения новых типов данных без значительного изменения существующей структуры. В результате это минимально влияет на приложения, взаимодействующие с базой данных.
Нормализованные отношения и отношения между одним нормализованным отношением и другим отражают концепции реального мира и их взаимосвязи.
Нормальные формы
Кодд ввел понятие нормализации и то, что сейчас известно как первая нормальная форма (1NF) в 1970 году. Кодд определил вторую нормальную форму (2NF) и третью нормальную форму (3NF) в 1971 году, а Кодд и Раймонд Ф. Бойс определил нормальную форму Бойса – Кодда (BCNF) в 1974 году.
Нормальные формы (от наименее нормализованных до наиболее нормализованных):
- UNF: ненормализованная форма
- 1NF: первая нормальная форма
- 2NF: Вторая нормальная форма
- 3NF: Третья нормальная форма
- EKNF: нормальная форма элементарного ключа
- BCNF: нормальная форма Бойса – Кодда
- 4NF: Четвертая нормальная форма
- ETNF: основная нормальная форма кортежа
- 5NF: Пятая нормальная форма
- DKNF: нормальная форма доменного ключа
- 6NF: Шестая нормальная форма
Пример пошаговой нормализации
Нормализация - это метод проектирования базы данных, который используется для проектирования таблицы реляционной базы данных до более высокой нормальной формы. Процесс является прогрессивным, и более высокий уровень нормализации базы данных не может быть достигнут, если не будут выполнены предыдущие уровни.
Это означает, что, имея данные в ненормализованной форме (наименее нормализованной) и стремясь достичь наивысшего уровня нормализации, первым шагом будет обеспечение соответствия первой нормальной форме , вторым шагом будет обеспечение соответствия второй нормальной форме , и так далее в указанном выше порядке, пока данные не будут соответствовать шестой нормальной форме .
Однако стоит отметить, что нормальные формы, выходящие за рамки 4NF, представляют в основном академический интерес, поскольку проблемы, которые они существуют, для решения редко возникают на практике.
Обратите внимание, что данные в следующем примере были специально разработаны, чтобы противоречить большинству обычных форм. В реальной жизни вполне возможно пропустить некоторые шаги нормализации, потому что таблица не содержит ничего, что противоречило бы заданной нормальной форме. Также часто бывает, что исправление нарушения одной нормальной формы также устраняет нарушение более высокой нормальной формы в процессе. Также была выбрана одна таблица для нормализации на каждом этапе, а это означает, что в конце этого примера процесса все еще могут быть некоторые таблицы, не удовлетворяющие высшей нормальной форме.
Исходные данные
Пусть существует таблица базы данных со следующей структурой:
В этом примере предполагается, что у каждой книги только один автор.
В качестве предварительного условия для соответствия реляционной модели таблица должна иметь первичный ключ , который однозначно идентифицирует строку. Две книги могут иметь одинаковое название, но номер ISBN однозначно идентифицирует книгу, поэтому его можно использовать в качестве первичного ключа:
Удовлетворение 1NF
Чтобы удовлетворить Первой нормальной форме , каждый столбец таблицы должен иметь одно значение. Столбцы, содержащие наборы значений или вложенные записи, не допускаются.
В исходной таблице Subject содержит набор значений темы, что означает, что он не соответствует.
Для решения задачи предметы извлекаются в отдельную таблицу Subject :
В таблицу Subject добавляется столбец внешнего ключа , который относится к первичному ключу строки, из которой была извлечена тема. Таким образом, представлена та же информация, но без использования непростых доменов.
Вместо одной таблицы в ненормализованной форме теперь есть две таблицы, соответствующие 1NF.
Удовлетворение 2NF
Таблица Book имеет один ключ-кандидат (который, следовательно, является первичным ключом ), составной ключ . Рассмотрим следующий фрагмент таблицы:
Все атрибуты, которые не являются частью ключа кандидата, зависят от заголовка , но только цена зависит от формата . Чтобы соответствовать 2NF и устранить дублирование , каждый атрибут, не являющийся ключом-кандидатом, должен зависеть от всего ключа-кандидата, а не только от его части.
Чтобы нормализовать эту таблицу, сделайте (простым) ключом-кандидатом (первичным ключом), чтобы каждый атрибут, не являющийся ключом-кандидатом, зависел от всего ключа-кандидата, и удалите Price в отдельную таблицу, чтобы ее зависимость от Format могла быть сохранено:
Теперь таблица Book соответствует 2NF .
Удовлетворение 3NF
Таблица Book по- прежнему имеет транзитивную функциональную зависимость ( зависит от , которая зависит от ). Аналогичное нарушение существует для жанра ( зависит от , который зависит от ). Следовательно, таблица Book не входит в 3NF. Чтобы сделать это в 3NF, давайте воспользуемся следующей структурой таблицы, тем самым исключив транзитивные функциональные зависимости, поместив и в соответствующие таблицы:
Удовлетворение EKNF
Удовлетворение 4NF
Предположим, что база данных принадлежит франшизе книжного ритейлера, у которой есть несколько франчайзи, владеющих магазинами в разных местах. Поэтому ритейлер решил добавить таблицу с данными о наличии книг в разных местах:
| ID франчайзи | Заголовок | Место нахождения |
|---|---|---|
| 1 | Начало проектирования и оптимизации базы данных MySQL | Калифорния |
| 1 | Начало проектирования и оптимизации базы данных MySQL | Флорида |
| 1 | Начало проектирования и оптимизации базы данных MySQL | Техас |
| 1 | Реляционная модель для управления базами данных: версия 2 | Калифорния |
| 1 | Реляционная модель для управления базами данных: версия 2 | Флорида |
| 1 | Реляционная модель для управления базами данных: версия 2 | Техас |
| 2 | Начало проектирования и оптимизации базы данных MySQL | Калифорния |
| 2 | Начало проектирования и оптимизации базы данных MySQL | Флорида |
| 2 | Начало проектирования и оптимизации базы данных MySQL | Техас |
| 2 | Реляционная модель для управления базами данных: версия 2 | Калифорния |
| 2 | Реляционная модель для управления базами данных: версия 2 | Флорида |
| 2 | Реляционная модель для управления базами данных: версия 2 | Техас |
| 3 | Начало проектирования и оптимизации базы данных MySQL | Техас |
Поскольку эта структура таблицы состоит из составного первичного ключа , она не содержит никаких неключевых атрибутов и уже находится в BCNF (и, следовательно, также удовлетворяет всем предыдущим нормальным формам ). Однако, если предположить, что все доступные книги предлагаются в каждой области, Title не привязан однозначно к определенному Location, и поэтому таблица не удовлетворяет 4NF .
Это означает, что для удовлетворения четвертой нормальной формы эта таблица также должна быть разложена:
Теперь каждая запись однозначно идентифицируется суперключом , поэтому 4NF удовлетворяется.
Удовлетворение ETNF
Предположим, франчайзи также могут заказывать книги у разных поставщиков. Пусть на отношение также действует следующее ограничение:
- Если определенный поставщик поставляет определенное название
- и название предоставляется франчайзи
- и франчайзи поставляется поставщиком,
- затем поставщик передает право собственности франчайзи .
Эта таблица находится в 4NF , но идентификатор поставщика равен объединению ее прогнозов: , , >. Ни один из компонентов этой зависимости соединения не является суперключом (единственный суперключ - это весь заголовок), поэтому таблица не удовлетворяет ETNF и может быть дополнительно разложена:
Декомпозиция обеспечивает соответствие ETNF.
Удовлетворение 5NF
Чтобы определить таблицу, не удовлетворяющую 5NF , обычно необходимо тщательно изучить данные. Предположим, что таблица из примера 4NF с небольшими изменениями в данных, и давайте посмотрим, удовлетворяет ли она 5NF :
| ID франчайзи | Заголовок | Место нахождения |
|---|---|---|
| 1 | Начало проектирования и оптимизации базы данных MySQL | Калифорния |
| 1 | Изучение SQL | Калифорния |
| 1 | Реляционная модель для управления базами данных: версия 2 | Техас |
| 2 | Реляционная модель для управления базами данных: версия 2 | Калифорния |
Декомпозиция этой таблицы снижает избыточность, в результате чего получаются следующие две таблицы:
Запрос, соединяющий эти таблицы, вернет следующие данные:
| ID франчайзи | Заголовок | Место нахождения |
|---|---|---|
| 1 | Начало проектирования и оптимизации базы данных MySQL | Калифорния |
| 1 | Изучение SQL | Калифорния |
| 1 | Реляционная модель для управления базами данных: версия 2 | Калифорния |
| 1 | Реляционная модель для управления базами данных: версия 2 | Техас |
| 1 | Изучение SQL | Техас |
| 1 | Начало проектирования и оптимизации базы данных MySQL | Техас |
| 2 | Реляционная модель для управления базами данных: версия 2 | Калифорния |
JOIN возвращает на три строки больше, чем должно; добавление еще одной таблицы для выяснения взаимосвязи приводит к трем отдельным таблицам:
Удовлетворение DKNF
Давайте посмотрим на таблицу Book из предыдущих примеров и посмотрим, удовлетворяет ли она нормальной форме ключа домена :
Это соглашение технически является ограничением, но не ограничением домена или ключевым ограничением; поэтому мы не можем полагаться на ограничения домена и ключевые ограничения для сохранения целостности данных.
Чтобы решить эту проблему, создается перечисление таблицы, определяющее толщину , и этот столбец удаляется из исходной таблицы:
Таким образом, нарушение целостности домена устранено, и таблица находится в DKNF .
Удовлетворение 6NF
Это означает, например, что таблица Publisher, созданная при создании 1NF
| Publisher_ID | Имя | Страна |
|---|---|---|
| 1 | Apress | Соединенные Штаты Америки |
необходимо дополнительно разложить на две таблицы:
Очевидным недостатком 6NF является большое количество таблиц, необходимых для представления информации об одном объекте. Если таблица в 5NF имеет один столбец первичного ключа и N атрибутов, для представления одной и той же информации в 6NF потребуется N таблиц; обновления нескольких полей для одной концептуальной записи потребуют обновления нескольких таблиц; а вставки и удаления аналогичным образом потребуют операций с несколькими таблицами. По этой причине в базах данных, предназначенных для обслуживания нужд онлайн-обработки транзакций , не следует использовать 6NF.
Однако в хранилищах данных , которые не допускают интерактивных обновлений и которые предназначены для быстрого запроса больших объемов данных, некоторые СУБД используют внутреннее представление 6NF, известное как хранилище данных по столбцам . В ситуациях, когда количество уникальных значений столбца намного меньше количества строк в таблице, хранение, ориентированное на столбцы, позволяет значительно сэкономить пространство за счет сжатия данных. Столбцовое хранилище также позволяет быстро выполнять запросы диапазона (например, отображать все записи, в которых конкретный столбец находится между X и Y или меньше X.)
Одни и те же данные могут группироваться в таблицы (отношения) различными способами. Группировка атрибутов в отношениях должна быть рациональной, т. е. минимизирующей дублирование данных и упрощающей процедуры их обработки и обновления. Устранение избыточности данных является одной из важнейших задач проектирования баз данных и обеспечивается нормализацией.
Нормализация таблиц (отношений) — это формальный аппарат ограничений на формирование таблиц (отношений), который позволяет устранить дублирование, обеспечивает непротиворечивость хранимых в базе данных, уменьшает трудозатраты на ведение (ввод, корректировку) базы данных. Процесс нормализации заключается в разложении (декомпозиции) исходных отношений БД на более простые отношения. Каждая ступень этого процесса приводит схему отношений в последовательные нормальные формы. Для каждой ступени нормализации имеются наборы ограничений, которым должны удовлетворять отношения БД. Нормализация позволяет удалить из таблиц базы избыточную неключевую информацию.
Процесс нормализации основан на понятии функциональной зависимости атрибутов: атрибут зависит от атрибута (), если в любой момент времени каждому значению атрибута соответствует не более одного значения атрибута .
Зависимость, при которой каждый неключевой атрибут зависит от всего составного ключа и не зависит от его частей, называется полной функциональной зависимостью. Если атрибут зависит от атрибута , а атрибут зависит от атрибута (), но обратная зависимость отсутствует, то зависимость от называется транзитивной.
Информационный объект (или сущность) находится в первой нормальной форме (1НФ), когда все его атрибуты имеют единственное значение. Если в каком-либо атрибуте есть повторяющиеся значения, объект (сущность) не находится в 1НФ, и упущен еще по крайней мере один информационный объект (еще одна сущность).
ПРЕДМЕТ (Код предмета, Название, Цикл, Объем часов, Преподаватели)
не находится в 1НФ, так как атрибут Преподаватели подразумевает возможность присутствия нескольких фамилий преподавателей в записи, относящейся к какому-то конкретному предмету, что соответствует участию нескольких преподавателей в ведении одной дисциплины Переведем атрибут с повторяющимися значениями в новую сущность, назначим ей первичный ключ (Код преподавателя) и свяжем с исходной сущностью ссылкой на первичный ключ последней (Код предмета). В результате получим две сущности, причем во вторую сущность ПРЕПОДАВАТЕЛЬ добавлены характеризующие ее атрибуты:
ПРЕДМЕТ (Код предмета, Название, Цикл, Объем часов),
ПРЕПОДАВАТЕЛЬ (Код преподавателя, Фамилия И О , Должность, Оклад, Адрес, Код предмета)
Полученные выражения соответствуют случаю, когда несколько преподавателей могут вести один предмет, но каждый преподаватель не может вести более одной дисциплины. А если учесть, что на самом деле один лектор может читать более одной дисциплины, так же как одну и ту же дисциплину могут читать несколько лекторов, необходимо отказаться от жесткой привязки преподавателя к предмету в сущности ПРЕПОДАВАТЕЛЬ, создав дополнительную сущность ИЗУЧЕНИЕ, которая будет показывать, как связаны между собой пре подаватели и предметы:
ПРЕДМЕТ (Код предмета, Название, Цикл, Объем часов),
ПРЕПОДАВАТЕЛЬ (Код преподавателя, Фамилия И О , Должность, Оклад, Адрес),
ИЗУЧЕНИЕ (Код предмета, Код преподавателя)
Информационный объект находится во второй нормальной форме (2НФ), если он уже находится в первой нормальной форме, и каждый неидентифицирующий (описательный) атрибут зависит от всего уникального идентификатора информационного объекта. Если некий атрибут не зависит полностью от уникального идентификатора сущности, значит, он внесен ошибочно и должен быть удален. Нормализация в этом случае производится путем нахождения существующего информационного объекта, к которому данный атрибут относится, или созданием нового информационного объекта, в который атрибут должен быть помещен.
Возвращаясь к предыдущему примеру, замечаем что атрибут Цикл в сущности ПРЕДМЕТ, характеризующий принадлежность предмета к циклу гуманитарных, естественно-научных, общепрофессиональных или специальных дисциплин, не полностью зависит от уникального идентификатора Код предмета, так как разные предметы могут иметь одно и то же значение атрибута Цикл. Перенесем атрибут в новую сущность ЦИКЛ и получим четыре взаимосвязанные сущности
ПРЕДМЕТ (Код предмета, Название, Объем часов, Код цикла),
ЦИКЛ (Код цикла, Название цикла),
ПРЕПОДАВАТЕЛЬ (Код преподавателя, Фамилия И О , Должность, Оклад, Адрес),
ИЗУЧЕНИЕ (Код предмета, Код преподавателя)
Информационный объект (или сущность) находится в третьей нормальной форме (ЗНФ), если он уже находится во второй нормальной форме и ни один описательный атрибут не зависит от каких-либо других описательных атрибутов. Атрибуты, зависящие от других неидентифицирующих атрибутов, нормализуются путем перемещения зависимого атрибута и атрибута, от которого он зависит, в новый информационный объект.
В данном примере неключевые атрибуты Должность и Оклад находятся в транзитивной зависимости. В чем опасность такой зависимости? Во-первых, несколько человек могут работать в одной и той же должности. При изменении должностного оклада в этом случае нужно будет менять данные в каждой записи, содержащей эту должность. В рассмотренной ситуации нужно создать новую сущность ДОЛЖНОСТЬ с находящимися в транзитивной зависимости атрибутами — Название должности и Оклад и сделать ссылку от сущности ПРЕПОДАВАТЕЛЬ на сущность ДОЛЖНОСТЬ:
ПРЕДМЕТ (Код предмета, Название, Объем часов, Код цикла),
ЦИКЛ (Код цикла, Название цикла),
ПРЕПОДАВАТЕЛЬ (Код преподавателя, Фамилия И О., Код должности, Адрес),
ДОЛЖНОСТЬ (Код должности, Название должности, Оклад),
ИЗУЧЕНИЕ (Код предмета, Код преподавателя)
2. Средства ускоренного доступа к данным
Чтобы пользователь чувствовал себя комфортно, время ожидания ответа на запрос к БД не должно превышать нескольких секунд. В связи с этим требованием специально разрабатываются методы ускорения выборки, позволяющие обойтись без полного перебора строк при выполнении реляционных операций модификации отношений и отбора данных.
Наибольший эффект дают метод индексирования и метод хеширования значений ключей отношения.
Индексирование — логическая сортировка строк таблицы. Оно заключается в создании вспомогательных файлов, содержащих упорядоченные списки значений ключей отношения со ссылками на строку отношения, в которой они находятся. Индексные файлы занимают дополнительную память, но резко ускоряют поиск, благодаря применению метода половинного деления. Для одного отношения может быть создано несколько индексов. Кроме того, можно создавать индекс для нескольких отношений, если они содержат одинаковые атрибуты, что позволяет ускорить выполнение операций соединения отношений.
Индексы позволяют находить строки, в которых значения ключевых полей совпадают с заданным значением или принадлежат заданному интервалу.
Хеширование (hashing) — использование хэш-функций, которые вычисляют вес строки таблицы по значению ее ключевых атрибутов. Результат вычисления хэш-функции — целое число в диапазоне физических номеров строк таблицы.
Идеальная хэш-функция должна давать разные значения весов для разных ключевых атрибутов. Но это не всегда возможно. На практике обычно используют простые хэш-функции, например, , где — целое число, первичный ключ отношения; — простое целое число; — операция, вычисляющая остаток при целочисленном делении. Если ключевой атрибут — строка символов, то для вычисления выбирается один из методов преобразования строки в число, например вычисление контрольной суммы.
Для организации доступа к данным при хешировании создается таблица с пустыми строками, которая заполняется следующим образом:
• по первичному ключу новой строки вычисляется значение хэш-функции и результат трактуется, как номер строки в созданной таблице;
• если строка уже занята, производится проверка следующих строк по специальному алгоритму до тех пор, пока не будет обнаружено свободное место.
Аналогично производится поиск нужной строки:
• если после вычисления на месте в таблице, которое соответствует вычисленному значению, оказывается пустая строка, значит, искомой строки просто нет;
• иначе (строка занята);
• если значение ключа совпало с искомым, поиск заканчивается;
• • иначе (значение не совпало) — проверяются следующие строки до строки с нужным ключом — строка найдена или до пустой строки — строка отсутствует.
Хеширование используют для поиска строк по точному совпадению значения ключевого атрибута кортежа с нужным значением ключа.
Ссылочной целостностью называют особый механизм, осуществляемый средствами СУБД или программистом, ответственный за поддержание непротиворечивых данных в связанных релятивными отношениями таблицах . Ссылочная целостность подразумевает, что в таблицах , имеющих релятивные связи, нет ссылок на несуществующие записи. Взгляните на рис. 1.3. Если мы удалим из списка студента Иванова И.И., и при этом не изменим таблицу со сданными экзаменами, ссылочная целостность будет нарушена, в таблице с экзаменами появится "мусор" - данные, на которые не ссылается ни одна запись из таблицы студентов. Ссылочная целостность будет нарушена.
Таким образом, если мы удаляем из списка студента Иванова И.И., следует позаботиться о том, чтобы из таблицы со сданными экзаменами также были удалены все записи, на которые ранее ссылалась удаленная запись главной таблицы. Существует несколько видов изменений данных, которые могут привести к нарушению ссылочной целостности:
- Удаляется запись в родительской таблице , но не удаляются соответствующие связанные записи в дочерней таблице .
- Изменяется запись в родительской таблице , но не изменяются соответствующие ключи в дочерней таблице .
- Изменяется ключ в дочерней таблице , но не изменяется значение связанного поля родительской таблицы.
Многие СУБД блокируют действия пользователя, которые могут привести к нарушению связей. Нарушение хотя бы одной такой связи делает информацию в БД недостоверной. Если мы, например, удалили Иванова И.И., то теперь номер 1 принадлежит Петрову П.П.. Имеющиеся связи указывают, что он сдал экзамены по математике и физике, но не сдавал экзаменов по русскому языку и литературе. Достоверность данных нарушена. Конечно, в таких случаях в качестве ключа обычно используют счетчик - поле автоинкрементного типа. Если удалить запись со значением 1, то другие записи не изменят своего значения, значение 1 просто невозможно будет присвоить какой-то другой записи, оно будет отсутствовать в таблице. Путаницы в связях не случится, однако все равно подчиненная таблица будет иметь "потерянные" записи, не связанные ни с какой записью главной таблицы. Механизм ссылочной целостности должен запрещать удаление записи в главной таблице до того, как будут удалены все связанные с ней записи в дочерней таблице .
Нормализация базы данных
Каждый программист обычно по-своему проектирует базу данных для программы, над которой работает. У одних это получается лучше, у других - хуже. Качество спроектированной БД в немалой степени зависит от опыта и интуиции программиста, однако существуют некоторые правила, помогающие улучшить проектируемую БД . Такие правила носят рекомендательный характер, и называются нормализацией базы данных .
Процесс нормализации данных заключается в устранении избыточности данных в таблицах.
Существует несколько нормальных форм, но для практических целей интерес представляют только первые три нормальные формы.
Первая нормальная форма ( 1НФ ) требует, чтобы каждое поле таблицы БД было неделимым (атомарным) и не содержало повторяющихся групп.
Неделимость означает, что в таблице не должно быть полей , которые можно разбить на более мелкие поля. Например, если в одном поле мы объединим фамилию студента и группу, в которой он учится, требование неделимости соблюдаться не будет. Первая нормальная форма требует, чтобы мы разбили эти данные по двум полям.
Под понятием повторяющиеся группы подразумевают поля, содержащие одинаковые по смыслу значения. Взгляните на рисунок:
Верно, такую таблицу можно сделать, однако она нарушает правило первой нормальной формы. Поля "Студент 1", "Студент 2" и "Студент 3" содержат одинаковые по смыслу объекты, их требуется поместить в одно поле "Студент", как в рисунке 1.4. Ведь в группе не бывает по три студента, правда? Представляете, как будет выглядеть таблица , содержащая данные на тридцать студентов? Это тридцать одинаковых полей ! В приведенном выше рисунке поля описывают студентов в формате "Фамилия И.О.". Однако если оператор будет вводить эти описания в формате "Фамилия Имя Отчество", то нарушается также правило неделимости. В этом случае каждое такое поле следует разбить на три отдельных поля, так как поиск может вестись не только по фамилии, но и по имени или по отчеству.
Вторая нормальная форма ( 2НФ ) требует, чтобы таблица удовлетворяла всем требованиям первой нормальной формы, и чтобы любое не ключевое поле однозначно идентифицировалось полным набором ключевых полей . Рассмотрим пример: некоторые студенты посещают спортивные платные секции, и ВУЗ взял на себя оплату этих секций. Взгляните на рисунок:
В чем здесь нарушение? Ключом этой таблицы служат поля "№ студента" - "Секция". Однако данная таблица также содержит отношение "Секция" - " Плата ". Если мы удалим запись студента № 110, то потеряем данные о стоимости секции по скейтборду. А после этого мы не сможем ввести информацию об этой секции, пока в нее не запишется хотя бы один студент. Говорят, что такое отношение подвержено как аномалии удаления , так и аномалии вставки.
В соответствие с требованиями второй нормальной формы, каждое не ключевое поле должно однозначно зависеть от ключа. Поле " Плата " в приведенном примере содержит сведения от стоимости данной секции, и ни коим образом не зависит от ключа - номера студента. Таким образом, чтобы удовлетворить требованию второй нормальной формы, данную таблицу следует разбить на две таблицы, каждая из которых зависит от своего ключа:
Мы получили две таблицы, в каждой из которых не ключевые данные однозначно зависят от своего ключа.
Третья нормальная форма ( 3НФ ) требует, чтобы в таблице не имелось транзитивных зависимостей между не ключевыми полями, то есть, чтобы значение любого поля, не входящего в первичный ключ , не зависело от другого поля, также не входящего в первичный ключ . Допустим, в нашей студенческой базе данных есть таблица с расходами на спортивные секции:
Как нетрудно заметить, ключевым полем здесь является поле "Секция". Поля " Плата " и "Кол-во студентов" зависят от ключевого поля и не зависят друг от друга. Однако поле "Общая стоимость " зависит от полей " Плата " и "Кол-во студентов", которые не являются ключевыми, следовательно, нарушается правило третьей нормальной формы.
Поле "Общая стоимость " в данном примере можно спокойно убрать из таблицы, ведь если потребуется вывести такие данные, нетрудно будет перемножить значения полей " Плата " и "Кол-во студентов", и создать для вывода вычисляемое поле .
Таким образом, нормализация данных подразумевает, что вы вначале проектируете свою базу данных: планируете, какие таблицы у вас будут, какие в них будут поля, какого типа и размера. Затем вы приводите каждую таблицу к первой нормальной форме. После этого приводите полученные таблицы ко второй, затем к третьей нормальной форме, после чего можете утверждать, что ваша база данных нормализована.
Однако такой подход имеет и недостатки: если вам требуется разработать программный комплекс для крупного предприятия, база данных будет довольно большой. При нормализации данных, вы можете получить сотни взаимосвязанных между собой таблиц. С увеличением числа нормализованных таблиц уменьшается восприятие программистом базы данных в целом, то есть вы можете потерять общее представление вашей базы данных , запутаетесь в связях. Кроме того, поиск в чересчур нормализованных данных может быть замедлен. Отсюда вывод : при работе с данными большого объема ищите компромисс между требованиями нормализации и собственным общим восприятием базы данных .
Читайте также: