Как привести таблицу к 3 нормальной форме
Третья нормальная форма предполагает, что каждый столбец, не являющийся ключом, должен зависеть только от столбца, который является ключом, то есть должна отсутствовать транзитивная функциональная зависимость (transitive functional dependency)
Транзитивная функциональная зависимость выражается следующим образом: А → В и В → С. То есть атрибут С транзитивно зависит от атрибута А, если атрибут С зависит от атрибута В, а атрибут В зависит от атрибута А (при условии, что атрибут А функционально не зависит ни от атрибута В, ни от атрибута С).
Если столбец зависит не только от первичного ключа, то данный столбец находится не в той таблице, в которой он должен находиться, либо же является производным от других столбцов.
Для нормализации из исходной таблицы те атрибуты, которые находятся в транзитивной зависимости от ключа, выносятся в отдельную таблицу с копией того атрибута, от которого они непосредственно зависят.
При применении третьей нормальной формы таблица должна находиться во второй нормальной форме. 3NF позволяет значительно снизить избыточность данных.
Для примера возьмем сформированную в прошлой теме таблицу Courses, которая содержит информацию о курсах и которая находится во второй нормальной форме:
| CourseId | Course | TeacherId | Teacher |
| 1 | Математика | 1 | Смит |
| 2 | JavaScript | 2 | Адамс |
| 3 | Алгоритмы | 2 | Адамс |
Какие функциональные зависимости здесь можно выделить:
CourseId → Course, TeacherId, Teacher
Course → CourseId, TeacherId, Teacher
Вторая зависимость фактически аналогична первой и говорит о том, что атрибут Course является потенциальным ключом.
Третья зависимость говорит о том, что, зная идентификатор преподавателя, мы можем узнать его фамилию и должность. То есть через атрибут TeacherId атрибут Teacher зависит от CourseId (CourseId→ TeacherId и TeacherId → Teacher). И в данном случае мы можем говорить о транзитивной зависимости Teacher, Position от CourseId.
Для нормализации необходимо вынести в отдельную таблицу атрибуты TeacherId и Teacher. Для этого пусть будет отдельная таблица Teachers:
| TeacherId | Teacher |
| 1 | Смит |
| 2 | Адамс |
А таблица Courses сократится следующим образом:
| CourseId | Course | TeacherId |
| 1 | Математика | 1 |
| 2 | JavaScript | 2 |
| 3 | Алгоритмы | 2 |
Приведение базы к 3-ей нормальной форме
Они соответствуют 1-ой нормальной форме, т.к. все строки различны,и не являются списками. Т.к соответствует 1-ой нормальной форме и имеет уникальный id, то значит и второй нормальной форме соответствует. Правильно рассуждаю? Вот с 3-ей формой немного непонятно. «Любой её не ключевой атрибут функционально зависит только от первичного ключа.»
Что значит функционально?
Третья нормальная форма (3NF) базы данных
Приветствую Вас на сайте Info-Comp.ru! Сегодня мы с Вами подробно рассмотрим третью нормальную форму (3NF) базы данных, Вы узнаете, какие требования предъявляются к таблицам, чтобы база данных находилась в третьей нормальной форме, и для наглядности мы конечно рассмотрим пример.
Перед тем как переходить к процессу приведения таблиц базы данных до третьей нормальной формы, необходимо чтобы эти таблицы уже находились во второй нормальной форме, подробно процесс приведения таблиц базы данных до второй нормальной формы, а также все требования, предъявляемые ко второй нормальной форме, мы рассматривали в предыдущей статье – вторая нормальная форма (2NF).
После того как таблицы базы данных находятся во второй нормальной форме, мы можем начинать приводить базу данных к третьей нормальной форме и рассматривать соответствующие требования.
Требования третьей нормальной формы (3NF)
Требование третьей нормальной формы (3NF) заключается в том, чтобы в таблицах отсутствовала транзитивная зависимость.
Транзитивная зависимость – это когда неключевые столбцы зависят от значений других неключевых столбцов.
Если в первой нормальной форме наше внимание было нацелено на соблюдение реляционных принципов, во второй нормальной форме в центре нашего внимания был первичный ключ, то в третьей нормальной форме все наше внимание уделено столбцам, которые не являются первичным ключом, т.е. неключевым столбцам.
Чтобы нормализовать базу данных до третьей нормальной формы, необходимо сделать так, чтобы в таблицах отсутствовали неключевые столбцы, которые зависят от других неключевых столбцов.
Иными словами, неключевые столбцы не должны пытаться играть роль ключа в таблице, т.е. они действительно должны быть неключевыми столбцами, такие столбцы не дают возможности получить данные из других столбцов, они дают возможность посмотреть на информацию, которая в них содержится, так как в этом их назначение.
Главное правило третьей нормальной форме (3NF) звучит следующим образом:
Таблица должна содержать правильные неключевые столбцы
Пример приведения таблиц базы данных к третьей нормальной форме
Для рассмотрения примера давайте возьмем нашу таблицу с сотрудниками, которую в предыдущем материале мы привели ко второй нормальной форме путем добавления в нее дополнительного атрибута «Табельный номер», который в результате стал первичным ключом.
Таблица сотрудников во второй нормальной форме.
| Табельный номер | ФИО | Должность | Подразделение | Описание подразделения |
| 1 | Иванов И.И. | Программист | Отдел разработки | Разработка и сопровождение приложений и сайтов |
| 2 | Сергеев С.С. | Бухгалтер | Бухгалтерия | Ведение бухгалтерского и налогового учета финансово-хозяйственной деятельности |
| 3 | John Smith | Продавец | Отдел реализации | Организация сбыта продукции |
Чтобы определить, находится ли эта таблица в третьей нормальной форме, мы должны проверить все неключевые столбцы, каждый из них должен зависеть только от первичного ключа, и никаким образом к другим неключевым столбцам он не должен относиться.
Однако, в результате проверки мы выясняем, что столбец «Описание подразделения» не зависит напрямую от первичного ключа. Мы это выяснили, когда задали себе один вопрос «Каким образом описание подразделения связано с сотрудником?». И наш ответ звучит следующим образом: «Атрибут описание подразделения содержит детальные сведения того подразделения, в котором работает сотрудник».
Отсюда следует, что столбец «Описание подразделения» не связан на прямую с сотрудником, он связан напрямую со столбцом «Подразделение», который напрямую связан с сотрудником, ведь сотрудник работает в каком-то конкретном подразделении. Это и есть транзитивная зависимость, когда один неключевой столбец связан с первичным ключом через другой неключевой столбец.
Чтобы привести эту таблицу к третьей нормальной форме, мы должны сделать что? Правильно, декомпозицию!
Мы должны эту таблицу разбить на две: в первой хранить сотрудников, а во второй подразделения. А для реализации связи в таблице сотрудников создать ссылку на таблицу подразделений, т.е. добавить внешний ключ.
Таблица сотрудников в третьей нормальной форме.
| Табельный номер | ФИО | Должность | Подразделение |
| 1 | Иванов И.И. | Программист | 1 |
| 2 | Сергеев С.С. | Бухгалтер | 2 |
| 3 | John Smith | Продавец | 3 |
Таблица подразделений в третьей нормальной форме.
| Идентификатор подразделения | Подразделение | Описание подразделения |
| 1 | Отдел разработки | Разработка и сопровождение приложений и сайтов |
| 2 | Бухгалтерия | Ведение бухгалтерского и налогового учета финансово-хозяйственной деятельности |
| 3 | Отдел реализации | Организация сбыта продукции |
Таким образом, в наших таблицах отсутствует транзитивная зависимость, и они находятся в третьей нормальной форме.
Заметка! Если Вас интересует язык SQL, то рекомендую почитать книгу «SQL код» – это самоучитель по языку SQL для начинающих программистов. В ней очень подробно рассмотрены основные конструкции языка.
После того как мы привели таблицы базы данных к третьей нормальной форме, мы можем переходить к приведению таблиц до следующей нормальной формы, в частности до нормальной формы Бойса-Кодда (BCNF). Описание, требования и пример приведения таблиц до нормальной формы Бойса-Кодда мы рассмотрим в следующем материале.
На сегодня это все, надеюсь, материал был Вам полезен, пока!
Руководство по SQL. Третья нормальная форма (3 НФ).
Таблица считается приведённой к тертьей нормальной форме (далее – 3НФ), если она выполняет следующие правила:
- Приведена ко второй нормальной форме (далее – 2НФ).
- Все не главные поля зависят от первичного ключа (primary key).
Предположим, что у нас есть талица developers, которая имеет следующий вид:
CREATE TABLE developers( DEVELOPER_ID INT NOT NULL, DEVELOPER_NAME VARCHAR (20) NOT NULL, DEVELOPER_SALARY INT, COMPANY_ID INT, COMPANY_NAME VARCHAR(100), COMPANY_ADDRESS VARCHAR(100), PRIMARY KEY (DEVELOPER_ID) );
Зависимость между id компании и именем компании называется транзитивной. Для того, чтобы привести нашу базу данных (далее – БД) к 3НФ, мы должны вынести COMPANY_ID, COMPANY_NAME и COMPANY_ADDRESS в отдельную таблицу:
CREATE TABLE companies( COMPANY_ID INT NOT NULL, COMPANY_NAME VARCHAR(200), COMPANY_ADDRESS VARCHAR(100), PRIMARY KEY (COMPANY_ID) );
CREATE TABLE developers( DEVELOPER_ID INT NOT NULL, DEVELOPER_NAME VARCHAR (20) NOT NULL, DEVELOPER_SALARY INT, COMPANY_ID INT, PRIMARY KEY (DEVELOPER_ID) );
Преимущество от удаления транзитивных связей заключается в том, что:
- Уменьшается количество повторяющихся данных.
- Интеграционность данных. Если у нас есть повторяющиеся данные, то увеличивается риск обновления только части этих данных.
Например, если одна и таже компании содержится в 1 записях, то мы легко можем по ошибке исправить адресс компании только у 9 из 10 разработчиков.
На этом мы заканчиваем изучение третьей нормальной формы (3НФ) БД.
Полезности
Туториалы
Системный дизайн
Собеседования
Студенты
Задачи
Немного о себе
Приветствую! Меня зовут Евгений. На этом сайте я пишу о разработке программного обеспечения. Связаться со мной вы можете по email: proselytear@yahoo.com Имеет смысл, предварительно ознакомиться вот с этим FAQ разделом.
Недавние публикации
- Механизмы CAS и FAA глазами Java разработчика
- ExecutorService в Java и примеры его применения.
- Особенности работы PreparedStatement в JDBC
- Основы кэширования в Hibernate
- Феномены чтения глазами разработчика
Copyright © 2024 PROSELYTE.
Omega WordPress Theme by ThemeHall