МИНИСТЕРСТВО ВЫСШЕГО ОБРАЗОВАНИЯ, НАУКИ И
ИННОВАЦИЙ РЕСПУБЛИКИ УЗБЕКИСТАН ТАШКЕНТСКИЙ
УНИВЕРСИТЕТ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ ИМЕНИ
МУХАММАДА АЛЬ-ХОРАЗМИЙ
Cамостоятельная
Работа
по предмету База данных на тему:
« Нормализация базы данных и нормальные формы 1NF, 2NF, 3NF и
Кодда. »
Группа: 065-23
Выполнил(a): Садуллаева Мунира
Проверил(a): Мухторова Г.Х.
Ташкент 2025г.
План:
1. Введение
2.Основная часть:
2.1. Нормализация базы данных
2.2. Нормализация СУБД: пример базы данных 1NF, 2NF, 3NF
2.3. Нормализация баз данных, определение 1-3 нормальных форм.
3.Заключение
4.Список использованной литературы
Введение
У
рассмотренной
ранее
переменной-отношения
SCP
имеется
существенный недостаток – избыточность. Эта избыточность заключается в
том, что для каждого кортежа, описывающего поставку деталей каким-либо
поставщиком повсюду дублируется информация о городе, из которого
осуществляется поставка, хотя он является одним и тем же для одного и того же
поставщика. Таким образом, информация о городе, в котором находится
поставщик, повторяется столько раз, сколько он осуществляет поставок. Эта
избыточность может привести к некоторым проблемам. Например, описывая
различные поставки, осуществляемые поставщиком, может быть указаны
различные значения города, что является заведомо неверным, так как в нашей
базе данных свойство «город, в котором находится поставщик» является
однозначным.
Для избегания подобных ситуаций и создания хорошего макета БД
следует придерживаться принципа «по одному факту в одном месте» (т.е.
следует
избегать
избыточности
данных). Предметом
нормализации,
в
сущности, является всего лишь формализация подобных простых идей, однако
это должна быть формализация, которая действительно будет иметь большое
практическое значение при проектировании базы данных.
Конечно, как мы уже отмечали во второй лекции, отношения в
реляционной модели всегда нормализованы. Можно также сказать, что
переменная-отношение также нормализована, поскольку ее допустимыми
значениями являются нормализованные отношения. Следовательно, в контексте
реляционной модели переменная-отношение также всегда нормализована.
Нормальные формы
Процесс дальнейшей нормализации, который ниже будет упоминаться
просто как нормализация, основывается на концепции нормальных форм.
Говорят, что переменная-отношение находится в определенной нормальной
форме, если она удовлетворяет некоторому набору условий. Например,
переменная-отношение находится во второй нормальной форме (2НФ), если она
находится
в
первой
нормальной
форме
и
удовлетворяет
некоторым
дополнительным условиям.
2.Основная часть:
2.1. Нормализация базы данных
Процесс проектирования баз данных (БД) не может обходиться без
нормализации. Это необходимая процедура, которая чем-то напоминает
оптимизацию. Выполнение нормализации осуществляется по определённым
правилам. Если пренебречь ими, база будет неэффективна и поиск информации
в такой БД будет сильно затруднён. Поэтому стоит рассмотреть основные типы
нормализации
БД,
принципы
её
выполнения
и
подкрепить
теорию
определёнными примерами из реальной жизни. Так будет проще понять
процедуру, а также её важность для базы данных.
Что такое нормализация БД
Под нормализацией понимают процесс организации данных в базе
определённым
образом
в
соответствии
с
рекомендациями
по
проектированию. То есть, все таблицы, а также необходимые связи между ними
должны создаваться по определённым правилам. Благодаря этому БД
становится максимально гибкой, исчезают несогласованные зависимости,
устраняется избыточность. Для того, чтобы лучше понять необходимость
процесса нормализации стоит подробнее рассмотреть его плюсы.
Преимущества:

Пользователь может получить нужную ему информацию, используя
только простые запросы.

Существенно снижается вероятность потери данных, а также
минимизируется возможное искажение информации.

Если всё делать по правилам, то в дальнейшем не будет проблем с
наращиванием БД.

Можно избежать избыточности (дублирования данных), что позволит
оптимизировать размер БД (будет занимать меньше места).

Нормализация
позволяет
убрать
несогласованные
зависимости,
которые существенно замедляют доступ к данным, хранящимся в базе.
Если подробнее рассмотреть преимущества процедуры, становится
понятно, что она является необходимой для поддержки нормального
функционирования БД. Но стоит заметить, что данный процесс может занять
достаточно продолжительное время. И желательно на время проведения
процедуры отключать базу. Впрочем, всё зависит от того, по какой схеме была
реализована СХД для хранения базы.
Основные термины
В этой главе мы рассмотрим основные термины, которые будут
использованы в данной статье. Это необходимо для того, чтобы можно было
свободно понимать, о чём вообще идёт речь. Эти термины также используются
специалистами, которые занимаются построением баз данных, их оптимизацией
и нормализацией.

Атрибут. Под этим термином в большинстве случаев понимается поле
таблицы. Однако в книгах подаётся определение немного иное —
«свойство некой сущности».

Домен атрибута. Характеристика домена атрибута включает в себя
разрешенные варианты значений, которые атрибут может принимать.
Обычно таких значений бывает множество.

Кортеж. Термин «кортеж» обозначает набор атрибутов, описывающих
конкретный объект или сущность. Как правило, кортеж ассоциируется
с строкой в таблице данных.

Отношение. Представляет собой готовую таблицу, то есть, набор уже
сформированных кортежей.

Схема отношения. Описывает структуру таблицы и включает в себя
набор определенных полей.

Проекция. Представляет
собой
таблицу,
полученную
путем
перестановки некоторых атрибутов.

Нормальная форма (НФ). Это требование к структуре таблицы в
теории баз данных.
Метод НФ включает в себя процесс сбора и
максимально эффективного использования информации об объектах в
пределах одного конкретного отношения, а затем разбиение этого
отношения.

Аномалия. Это ситуация в таблице, которая может привести к
противоречиям в базе данных и значительно усложнить ее обработку.
Существуют аномалии модификации, удаления и добавления.
Выше были рассмотрены наиболее используемые термины, которые можно
найти в литературе, посвящённой проектированию и оптимизации СУБД.
Конечно, в рамках данного материала нет возможности рассмотреть все
понятия,
поэтому
приходится
довольствоваться
основами.
Что такое транзитивная зависимость
только
необходимыми
Транзитивной зависимостью (ТЗ) в БД обычно называют косвенную
связь между атрибутами в одном отношении (таблице), которая в свою очередь
вызывает функциональную зависимость. Практически во всех известных
ситуациях, ТЗ состоит из 3 атрибутов минимум (столбцов с данными), которые
в
то
же
время
являются
функционально
зависимыми.
Основным отличием транзитивной зависимости от функциональной является то,
что первая возникает только в том случае, если косвенная связь вызывает
функциональную зависимость. Иными словами, ТЗ не может существовать без
ФЗ и полностью зависит от неё. Эту информацию необходимо знать для
проведения успешной нормализации.
Нормальные формы
Теперь стоит рассмотреть нормальные формы, которые применяются при
проектировании любой базы данных. Знание основных форм не позволит
совершить ошибку в процессе нормализации БД. Эти формы являются
составляющими общей реляционной модели данных.
1НФ
Первая нормальная форма (1НФ) предполагает, что все атрибуты в таблице
должны быть простыми, а данные на пересечении строк и столбцов должны
иметь исключительно скалярные значения. Важным требованием также
является отсутствие дублирующих строк. Рассмотрим вариант нарушения
нормализации на примере таблицы:
Здесь можно наблюдать нарушение в строке о BMW – перечислено сразу
несколько моделей, чего делать категорически нельзя, ведь получается
отсутствие атомарности. Если преобразовать таблицу в соответствии с
требованиями 1НФ, то она примет такой вид:
Производитель
Модель
BMW
X5
BMW
318
BMW
X6
M2
BMW
Turbo
Porsche
Таким
образом,
Cayenne
после
нормализации
существенно
упростится
поиск
информации в базе данных, а также будет оптимизирован её размер. Но сейчас
была рассмотрена только самая простая форма 1НФ. Дальше всё гораздо
сложнее.
2НФ
Вторая нормальная форма подразумевает, что отношение будет соответствовать
ей в полной мере только при условии, что база данных уже находится в первой
нормальной форме, и каждый столбец (не являющийся ключом) зависит от
первичного ключа. Вот таблица, в которой 2НФ была проигнорирована и в
результате ей потребовалась нормализация:
Модель
Производитель
Стоимость
Скидка
X5
BMW
6500000
15%
X6
BMW
7600000
15%
M2 Turbo
BMW
8000000
15%
Cayenne
Porsche
5000000
25%
По своей структуре эта таблица соответствует первой нормальной форме, но
возникают трудности с второй нормальной формой. Стоимость автомобиля
зависит как от производителя, так и от модели, в то время как предоставляемая
скидка зависит только от производителя. Здесь присутствует частичная
зависимость от первичного ключа. Чтобы это исправить, необходимо разделить
данные на две отдельные таблицы, учитывая оба направления зависимости (то
есть, создать две отдельные правильные таблицы).
Таблица 1:
Модель
Производитель
Стоимость
X5
BMW
6500000
X6
BMW
7600000
M2 Turbo
BMW
8000000
Cayenne
Porsche
5000000
Таблица 2:
Производитель
Скидка
BMW
15%
Porsche
25%
Теперь отношения полностью соответствуют 2НФ, поскольку неключевые
атрибуты полностью зависят от первичного ключа.
3НФ
Третья нормальная форма предполагает, что вся таблица должна находиться в
2НФ, но любой неключевой столбец при этом обязательно должен зависеть
только от первичного ключа. Ниже будет представлена таблица, в которой
атрибут с первичным ключом слово «Модель», а атрибут «Телефон» от ключа
никак не зависит – отсюда ошибка.
Модель
Магазин
Телефон
Mercedes-Benz
Das Auto
55-68-67
Volkswagen
Next Auto
38-43-51
Toyota
Real Auto
21-21-56
В этой таблице имеются следующие зависимости: «Модель-Магазин»,
«Магазин-Телефон»,
«Модель-Телефон».
Зависимость «Модель-Телефон»
является неверной и потому отношение не соответствует 3НФ. Для исправления
ситуации нужно разделить таблицу на две отдельные, выставив корректные
зависимости. Выглядеть это будет так.
Эти две таблицы полностью соответствуют 3НФ, а это значит, что очередной
этап нормализации прошёл успешно.
НФБК
Нормальная форма Бойса-Кодда (усиленная версия 3НФ) используется в тех
случаях, когда отношение имеет два или более потенциальных ключа. Причём
таблица может находиться в НФБК только в том случае, если каждая
нетривиальная функциональная зависимость обладает потенциальным ключом,
который выполняет роль детерминанта. В качестве примера рассмотрим
таблицу, предоставляющую данные о бронировании платной стоянки.
Номер стоянки
Начало
Окончание
Тариф
1
07:00
07:30
Эконом
1
09:25
11:00
Стандарт
2
18:45
22:36
Премиум 1
2
17:35
20:19
Премиум 2
Причём стоит учитывать, что каждый тариф уникален и зависит от выбранной
стоянки и наличия льгот. В итоге наблюдаются составные первичные ключи
(например,
«Номер
стоянки-Окончание»).
Однако
таблица
полностью
соответствует 3НФ. Условия 2НФ также полностью выполнены, поскольку все
атрибуты входят в какой-либо из потенциальных ключей.
Но существует функциональная зависимость «Тариф-Номер стоянки», в
которой левая часть не является ключом отношения. Поэтому и нет соответствия
НФБК. К тому же, благодаря подобной структуре, можно по ошибке тариф
«Эконом» можно приписать ко второй стоянке, которая не предназначена для
льготников. Поэтому лучше декомпозировать отношение на два и добавить
атрибут.
2.2. Нормализация СУБД: пример базы данных 1NF, 2NF, 3NF
Нормализация — это метод проектирования базы данных, который уменьшает
избыточность данных и устраняет нежелательные характеристики, такие как
аномалии вставки, обновления и удаления. Правила нормализации делят
большие таблицы на меньшие и связывают их с помощью отношений. Целью
нормализации в SQL является устранение избыточных (повторяющихся)
данных и обеспечение логического хранения данных.
Изобретатель реляционная
модель Эдгар
Кодд
предложил
теорию
нормализации данных с введением первой нормальной формы и продолжил
расширять теорию с помощью второй и третьей нормальных форм. Later он
присоединился к Рэймонду Ф. Бойсу для разработки теории нормальной формы
Бойса-Кодда.
Виды нормальных форм в СУБД
Вот список нормальных форм в SQL:

1NF (первая нормальная форма): Гарантирует, что таблица базы
данных организована таким образом, что каждый столбец содержит
атомарные (неделимые) значения, а каждая запись уникальна. Это
исключает повторяющиеся группы, тем самым структурируя данные в
таблицы и столбцы.

2NF (вторая нормальная форма): Создано на основе 1NF. Нам нужно
удалить избыточные данные из таблицы, которая применяется к
нескольким строкам. и разместить их в отдельных таблицах. Он требует,
чтобы все неключевые атрибуты были полностью функциональными в
первичном ключе.

3NF (Третья нормальная форма): Расширяет 2NF, гарантируя, что все
неключевые атрибуты не только полностью функциональны в первичном
ключе, но и независимы друг от друга. Это устраняет транзитивную
зависимость.

BCNF (нормальная форма Бойса-Кодда): Усовершенствование 3NF,
устраняющее аномалии, не обрабатываемые 3NF. Он требует, чтобы
каждый определитель был потенциальным ключом, обеспечивая еще
более строгое соблюдение правил нормализации.

4NF
(Четвертая
зависимости.
Это
нормальная
форма): Устраняет
гарантирует
отсутствие
в
многозначные
записи
нескольких
независимых многозначных фактов об объекте.

5NF (пятая нормальная форма): Также известная как «нормальная
форма соединения проекций» (PJNF). Она относится к реконструкции
информации из более мелких, по-разному организованных фрагментов
данных.

6NF (шестая нормальная форма): Теоретически и не получило
широкого применения. Он имеет дело с временными данными
(обработкой изменений с течением времени) путем дальнейшей
декомпозиции
таблиц
для
устранения
всей
нетемпоральной
избыточности.
Теория нормализации данных в MySQL сервер все еще находится в стадии
разработки. Например, есть дискуссии даже на 6th Нормальная форма. Однако в
большинстве
практических
приложений
нормализация
достигает
наилучшего результата за 3rd Нормальная форма. Эволюция нормализации в
теориях SQL проиллюстрирована ниже:
Нормальные формы базы данных
Нормализация базы данных с примерами
База данных Пример нормализации можно легко понять с помощью
тематического исследования. Предположим, видеотека ведет базу данных
фильмов, сдаваемых в прокат. Без какой-либо нормализации в базе данных вся
информация хранится в одной таблице, как показано ниже. Давайте разберемся
с базой данных нормализации на примере нормализации с решением:
Вот видишь Столбец «Прокат фильмов» имеет несколько значений. Теперь
перейдем к первой нормальной форме:
Первая нормальная форма (1NF)

Каждая ячейка таблицы должна содержать одно значение.

Каждая запись должна быть уникальной.
Приведенная выше таблица в 1NF-
Пример 1НФ
Пример 1NF в СУБД
Прежде чем мы продолжим, давайте поймем несколько вещей —
Что такое KEY в SQL
A КЛЮЧ в SQL — это значение, используемое для уникальной идентификации
записей в таблице. SQL KEY — это один столбец или комбинация нескольких
столбцов, используемых для уникальной идентификации строк или кортежей в
таблице. Ключ SQL используется для выявления повторяющейся информации,
а также помогает установить связь между несколькими таблицами в базе
данных.
Примечание. Столбцы таблицы, которые НЕ используются для однозначной
идентификации записи, называются неключевыми столбцами.
2.3. Нормализация баз данных, определение 1-3 нормальных форм.
Каждой нормальной форме соответствует определенный набор ограничений, и
отношение находится в некоторой нормальной форме, если удовлетворяет
свойственному
ей
набору
ограничений. Примером
может
служить
ограничение первой нормальной формы – значения всех атрибутов
отношения атомарны. Поскольку требование первой нормальной формы
является базовым требованием классической реляционной модели данных, мы
будем считать, что исходный набор отношений уже соответствует этому
требованию.
В
теории
реляционных
баз
данных
обычно
выделяется
следующая
последовательность нормальных форм:

первая нормальная форма (1NF);

вторая нормальная форма (2NF);

третья нормальная форма (3NF);

нормальная форма Бойса-Кодда (BCNF);

четвертая нормальная форма (4NF);

пятая нормальная форма, или нормальная форма проекции-соединения
(5NF или PJ/NF).
Основные свойства нормальных форм состоят в следующем:

каждая следующая нормальная форма в некотором смысле лучше
предыдущей нормальной формы;

при переходе к следующей нормальной форме свойства предыдущих
нормальных форм сохраняются.
В основе процесса проектирования лежит метод нормализации, т. е.
декомпозиции отношения, находящегося в предыдущей нормальной форме, на
два или более отношений, которые удовлетворяют требованиям следующей
нормальной формы.
Переменная
отношения
находится
во второй
нормальной
форме
(2NF) тогда и только тогда, когда она находится в первой нормальной форме, и
каждый
неключевой
атрибут1) минимально
функционально
зависит
от
первичного ключа.
Переменная отношения находится в третьей нормальной форме (3NF) в
том и только в том случае, когда она находится во второй нормальной форме, и
каждый неключевой атрибут нетранзитивно функционально зависит от
первичного ключа.
Нормализация схемы базы данных способствует более эффективному
выполнению системой управления базами данных операций обновления базы
данных, поскольку сокращается число проверок и вспомогательных действий,
поддерживающих целостность базы данных. При проектировании реляционной
базы данных почти всегда добиваются второй нормальной формы всех
входящих в базу данных отношений. В часто обновляемых базах данных обычно
стараются обеспечить третью нормальную форму отношений. На нормальную
форму Бойса-Кодда внимание обращают гораздо реже, поскольку на практике
ситуации,
в
которых
у
отношения
имеется
несколько
составных
перекрывающихся возможных ключей, встречаются нечасто.
В этой лекции мы кратко рассмотрим некоторые черты одной из наиболее
популярных семантических моделей данных – модель «Сущность-Связь» (часто
ее называют кратко ER-моделью от Entity-Relationship).
Здесь следует сделать два замечания, касающиеся, главным образом,
терминологии. Оба термина relation и relationship могут быть переведены на
русский язык как отношение. Поэтому в русскоязычной литературе ER-модель
иногда называют моделью сущность-отношение, а иногда и реляционной
семантической моделью. Наверное, в этом нет ничего страшного, если говорить
о ER-модели в отрыве от тематики проектирования реляционных баз данных.
Но если требуется одновременно использовать термины ER-модели и
реляционной модели данных, то, безусловно, требуется применять для
терминов relation и relationship разные
русские
эквиваленты.
За
этими
терминами стоят весьма различные понятия. В реляционной модели отношение
(relation) – это единственная родовая структура данных. С помощью этого же
механизма представляются «связанные» сущности (вспомните, например, про
внешние ключи). Как мы увидим немного позже, в ER-модели для
представления схемы базы данных используются два равноправных понятия –
сущность и связь. Связи в ER-модели играют роль, отличную от той, какую
играют отношения в реляционной модели данных.
Кроме
того,
в
русскоязычную
терминологию
вошла
и
чистая
транслитерация термина relation именно в смысле отношение. Мы говорим,
например, про реляционную модель данных, реляционную алгебру и т. д.,
понимая модель данных, основанную на отношениях, алгебру отношений и т. п.
По этому поводу, по крайней мере, в контексте баз данных, разумно
окончательно зарезервировать термины relation и отношение для обозначения
понятий реляционной модели данных, а для термина relationship использовать
другой допустимый русскоязычный эквивалент – связь.
Заключение
На использовании разных вариантов ER-модели основано большинство
современных подходов к проектированию баз данных (главным образом,
реляционных). Модель была предложена Питером Ченом (Peter Chen) в 1976 г.
Моделирование предметной области базируется на использовании графических
диаграмм, включающих небольшое число разнородных компонентов. Простота
и наглядность представления концептуальных схем баз данных в ER-модели
привели к ее широкому распространению в CASE-системах, поддерживающих
автоматизированное
проектирование
реляционных
баз
данных.
Среди
множества разновидностей ER-моделей одна из наиболее популярных и
развитых применялась в системе CASE компании Oracle. Мы обсудим
некоторый упрощенный вариант этой модели. Если говорить более точно,
сосредоточимся на ее структурной и целостной частях.
Список использованной литературы
1. Толковый словарь по вычислительной технике. - М.: Издательский отдел
''Русская редакция'' ТОО ''Channel trading Ltd'', 2005.
2.
Материалы
сайта
''Сервер
информационных
технологий''.
WEB:
www.citforum.ru.
3. Хомоненко А. Базы данных: Учеб. Для вузов. - 2-е изд. - СПб., 2000.
4. Фёдорова А., Елманова Н. Базы данных для всех. -М.: Компьютер пресс , 2001.
5. Глушаков С.В., Ломотько. Базы данных (2001 год издания). - М.: АСТ, 2001.
6. Карпова Т. Базы данных: модели, разработка, реализация, 2001.
7. Когаловский М.Р. Энциклопедия технологий баз данных. -М.: Финансы и
статистика, 2002.
8. Конноли Т., Бегг Л., Страчан А. Базы данных. Проектирование, реализация и
сопровождение. Теория и практика. - 2-е изд. - Вильямс, 2000.