Нормальные формы баз данных: Объясняем на пальцах

Привет, это канал Lee Send It, и сегодня мы слушаем статью "Нормализация баз данных простыми словами" с сайта info-comp.ru. Спасибо ресурсу за статью. В этой статье мы обсудим в целом процесс нормализации, узнаем, зачем проводить нормализацию базы данных, что такое нормальная форма базы данных, а также какие нормальные формы существуют. Мы подробно с примерами расскажем про каждую нормальную форму. Но сначала хочу вам порекомендовать отличный канал на тематику digital media. Там автор канала делится своим опытом работы, публикует подборки интересных материалов, которые будут полезны вообще всем, кто хоть как-то связан с сайтом: и разработчикам, и тестировщикам, и дизайнерам, и даже менеджерам. Так что подписывайтесь на Digital Media, ссылка, конечно, будет в описании. Ну а теперь обратно к нашей статье. Сначала традиционная база данных.

В целом под базой данных можно понимать любой набор информации, которую можно найти в этой базе данных и воспользоваться ею. Однако, если говорить в контексте SQL, то речь будет идти, конечно, о реляционных базах данных. А что же такое реляционная база данных? Это упорядоченная информация, связанная между собой определёнными отношениями. Логически такая база данных представлена в виде таблиц, в которых и лежит вся информация. Сейчас мы не будем подробно останавливаться на реляционных базах данных, тем более у нас была уже отдельная статья на эту тему, ссылочка в описании будет. Так что пойдемте к нормализации баз данных.

В реляционных базах есть такое понятие, как нормализация. Нормализация — это процесс удаления избыточных данных. Также нормализацию можно рассматривать с позиции проектирования баз данных. В таком случае мы можем сформулировать определение нормализации следующим образом: нормализация — это метод проектирования базы данных, который позволяет привести базу к минимальной избыточности. Избыточность устраняется, как правило, за счёт декомпозиции отношений, то есть разбиения одной таблицы на несколько. У вас может возникнуть вопрос: а зачем вообще нормализовать базу данных и бороться с этой избыточностью? Дело в том, что избыточность данных создаёт предпосылки для появления различных аномалий, снижает производительность и делает управление данными менее гибким и не очень удобным. Отсюда можно сделать вывод, что нормализация нужна для устранения аномалий, повышения производительности и повышения удобства управления данными. Теперь давайте поговорим о самой избыточности данных.

Что же это такое? Избыточность данных — это когда одни и те же данные хранятся в базе в нескольких местах. Именно это и приводит к аномалиям. А проблема в том, что приходится добавлять, менять или удалять одни и те же данные в нескольких местах. Например, если не выполнить операцию в каком-нибудь одном месте, то возникает ситуация, когда одни данные не соответствуют, вроде как, точно таким же данным в другом месте. Давайте рассмотрим пример. Допустим, у нас есть следующая таблица. Она хранит информацию о предметах мебели, в частности наименования предмета и материала, из которого изготовлен этот предмет. Таблица на экране. Теперь допустим, что у нас возникла необходимость подкорректировать название материала: вместо "массив дерева" нужно написать "натуральное дерево". И чтобы это сделать, вам необходимо внести изменения сразу в несколько строк, так как предметов, изготовленных из массива дерева, несколько, а именно стол и шкаф. А теперь представьте, что по каким-то причинам внесли изменения только в одну строку, и в итоге в нашей таблице будет и "массив дерева", и "натуральное дерево". Какое из этих названий будет правильным? А если представить, что мы можем внести ещё какое-то новое значение при добавлении новых записей, например просто "дерево"? В этом случае в нашей таблице в скором времени будет и "массив дерева", и "натуральное дерево", и "просто дерево", и вообще что угодно, ведь это просто текст. Однако по своей сути это один и тот же материал. Мы просто решили подкорректировать его название или ошиблись при добавлении новой записи. И то есть аномалия, когда одни данные в одном месте соответствуют, вроде как, точно таким же данным в другом месте. Это всего лишь один вид аномалий. Однако в процессе добавления, изменения и удаления данных может возникать много других противоречивых ситуаций, то есть аномалий. Поэтому обязательно стоит отметить, что в нашей таблице всего 5 записей. А теперь представьте, что их миллион. Именно поэтому мы должны устранять избыточность данных в базе, то есть проводить так называемую нормализацию базы данных. В данном конкретном случае мы должны название материала, из которого изготовлены предметы мебели, вынести в отдельную таблицу, а в таблице с предметами сделать всего лишь ссылку на нужный материал. Тем самым, соотнося эту ссылку с исходной записью, мы будем понимать, из какого материала сделан тот или иной предмет. То есть вот две таблицы, которые у нас появляются. Посмотрите на экран: первая — это предмет мебели, и у каждого наименования предмета есть свой идентификатор материала, ссылка на другую таблицу материалов, из которых изготовлен предмет мебели. И во второй таблице как раз только эти материалы. В этом случае, когда нам потребуется изменить название материала, мы будем вносить изменения только в одном месте, то есть править только одну строку. Таким образом, представляя материалы в виде отдельной сущности и создавая для неё отдельную таблицу, мы устраняем описанную выше аномалию. Другими словами, каждая сущность должна храниться отдельно, а в случае необходимости использования этой сущности в другой таблице на неё делается всего лишь ссылка, то есть выстраивается связь.

Теперь про нормальные формы базы данных. В целом процесс нормализации базы данных выглядит следующим образом: мы, следуя определённым правилам и соблюдая определённые требования, проектируем таблицы в базе данных. При этом все эти правила и требования можно сгруппировать в несколько наборов. И если спроектировать базу данных с соблюдением всех правил и требований, которые включаются в тот или иной набор, то база данных будет находиться в определённом состоянии, то есть форме. И такая форма называется нормальной формой базы данных. Иными словами, следуя определённым правилам и соблюдая определённые требования, мы приводим базу данных к определённой нормальной форме. То есть нормальная форма базы данных — это набор правил и критериев, которым должна отвечать база данных. Каждый следующий нормальная форма содержит более строгие правила и критерии. Тем самым, приводя базу данных к определённой нормальной форме, мы устраняем определённый набор аномалий. Отсюда можно сделать вывод, что чем выше нормальная форма, тем меньше аномалий в базе будет. Так что вот ещё одно определение, которому мы пришли: процесс нормализации — это последовательный процесс приведения базы данных к той или иной нормальной форме, то есть переход от одной нормальной формы к следующей. Существует 5 основных нормальных форм базы данных: первая нормальная форма, вторая нормальная форма, третья, четвёртая и пятая нормальная форма. Однако выделяют ещё дополнительные нормальные формы, такие как ненормализованная форма или 0 нормальная форма, она же UNF, также нормальная форма Бойса-Кода (BCNF), доменно-ключевая нормальная форма (DKNF) и шестая нормальная форма. Если объединить оба этих списка и упорядочить нормальные формы от менее нормализованной до самой нормализованной, то есть начиная с формы, при которой база данных по своей сути не является нормализованной, и заканчивая самой строгой нормальной формой, то мы получим следующий перечень: в самом начале идёт ненормализованная форма или 0 нормальная форма, потом первая нормальная форма, потом вторая, третья нормальная форма, Бойса-Кода, четвёртая, пятая, доменно-ключевая нормальная форма и последняя — шестая нормальная форма. База данных считается нормализованной, если она находится как минимум в третьей нормальной форме. В реальном мире нормализация до третьей нормальной формы является обычной стандартной практикой, так как третья форма устраняет достаточное количество аномалий, при этом производительность базы данных, а также удобство её использования не снижается, что нельзя сказать о всех последующих формах. Ситуации, при которых требуется нормализовать базу данных до...

будет так что пойдемте к нормализации баз данных в реляционных базах есть такое понятие как нормализация нормализация это процесс удаления избыточных данных также нормализацию можно рассматривать с позиции проектирования баз данных в таком случае мы можем сформулировать определение нормализации следующим образом

нормализация это метод проектирование базы данных который позволяет привести базука минимальные избыточности избыточность устраняются как правило за счет декомпозиции отношений то есть разбиение одной таблицы на несколько у вас может возникнуть вопрос а зачем вообще нормализовать базу данных и бороться с этой избыточностью дело в том

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

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

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

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

как предметов изготовленных из массива дерева несколько а именно 2 стол и шкаф а теперь представьте что по каким-то причинам и внесли изменения только в одну строку и в итоге в нашей таблице будет и массив дерева и натуральное дерево какой из этих название будет

правильным а если представить что мы можем внести еще какое-то новое значение при добавлении новых записей например просто дерево в этом случае в нашей таблице в скором времени будет и массив дерева и натуральное дерево и просто дерево и вообще что угодно ведь это

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

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

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

всего лишь ссылку на нужный материал тем самым соотнеся эту ссылку с исходной записью мы будем понимать из какого материала сделан тот или иной предмет то есть вот две таблицы которые нас появляются посмотрите на экран 1 это предмет мебели и у каждого наименования

предмета есть свой идентификатор материалов ссылка на другую таблицу материалы из которых изготовлен и предметы мебели и во второй таблице как раз только эти материалы в этом случае когда нам потребует изменить название материала мы будем вносить изменения только в одном месте то есть править

только одну строку таким образом представляем материалы в виде отдельной сущности и создавая для нее отдельную таблицу мы устраняем описано выше аномалию другими словами каждая сущность должна храниться отдельно а в случае необходимости использования этой сущностью другой таблицы на неё делается

всего лишь ссылка то есть выстраивается связь теперь про нормальной формы базы данных в целом процесс нормализации базы данных выглядит следующим образом мы следуя определенным правилам и соблюдая определенные требования проектируем таблицы в базе данных при этом все эти правила и требования можно сгруппировать

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

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

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

процесс нормализации это последовательный процесс приведения базы данных катал он нам уведу то есть переход от одной нормальной формы к следующей существует 5 основных нормальных форм базы данных первая нормальная форма вторая нормальная форма 3 4 и 5 нормальная форма однако выделяют

еще дополнительные нормальной формы такие как не нормализованная форма или 0 нормальная форма она же you in f также нормальная форма бойса кода би си неф домен на ключевая нормальная форма дикие неф и 6 нормальная форма если объединить оба этих списка и упорядочить нормальной

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

нормальная форма потом первая нормальная форма потом вторая третья нормальная форма бойся кода 4 5 домен на ключевая нормальная форма и последняя шестая нормальная форма база данных считается нормализована если она находится как минимум в третьей нормальной форме в реальном мире нормализации до 3

нормальной формой является обычной стандартной практикой так как третья форма устраняет достаточное количество аномалий при этом производительность базы данных а также удобство ее использования не снижается что нельзя сказать о всех последующих формах ситуации при которых требуется нормализовать базу данных до 4

нормальной формы в реальном мире встречаются достаточно редко если говорить о всех последующих нормальных формах опята и домена ключевой и 6 то в реальной жизни трудно даже представить ситуацию при которых потребуется нормализовать базу данных до этих форм иными словами эти последние три формы

это в большей степени теоретические нормальной формы немного отстраненные от реального мира стоит отметить что при ведение базы данных какой-то конкретной нормальной форме обязательно требует чтобы эта база уже находилась предыдущий нормальной форме другими словами если вы хотите нормализовать базу данных до 3

нормальной формы то база уже должна находиться во второй нормальной форме то есть нельзя нормализовать базу данных до 3 формы если она еще не нормализована до 2 теперь давайте пройдемся по всему списку из девяти форм и посмотрим на каждую не нормализованная форма или 0

нормальная форма ю н ф обычно данную форму как отдельную нормальную форму базы данных не выделяют но мы решили об этом рассказать чтоб показать вам какие таблицы являются реляционными а какие нет перед тем как переходить к процессу нормализации приведению базы данных к

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

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

теории мы не можем обратиться к определенной строке или столбцу по ее номеру и если все ваши таблицы соблюдают эти принципы то можно переходить к нормализации базы данных давайте рассмотрим небольшой пример достаточно часто в excel можно встретить таблицы и

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

приступить к нормализации нашей таблице нам необходимо как минимум удалить столбец порядковым номером и не учитывать порядок столбцов например задав им более корректные имена не а и b как было у нас в начале а все с ним например и last name теперь можно

сказать что это таблица соблюдает базовые принципы реляционной теории мы можем начинать приводить ее к той или иной нормальной форме например к первой нормальной форме требований первой нормальной формы очень простое и оно заключается в том чтобы таблица соответствовали реляционной модели

данных и соблюдали определенный реляционный принципы таким образом чтобы базы данных находилась первой нормальной форме необходимо чтобы ее таблицы соблюдали следующий реляционный принципы в таблице не должно быть дублирующих строк в каждой ячейке таблицы хранится атомарные значение то есть одно не

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

хранятся списки значений в контактах есть номера телефонов указано через запятую чтобы привести эту таблицу к первой нормальной форме необходимо удалить дублирующие строки вещей как хранить один номер телефона они список от тип телефона домашний или рабочий и вынести в отдельный столбец так как

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

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

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

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

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

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

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

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

дублирующих строк и все значения от амарны теперь мы можем начать процесс нормализации до 2 нормальные формы для чего нам нужно это сделать нам нужно внедрить первичный ключ поработав немного с примету областью мы выясняем что в этой организации каждому

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

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

новых записей в таблицу тем самым мы бы точно четко бы идентифицировали каждую строку в таблице таким образом чтобы привести эту таблицу ко второй нормальной форме мы должны добавить в нее еще один атрибут то есть столбец с табельным номером вот наша таблица

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

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

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

первичного ключа поэтому давайте его делать но посмотрев на таблицу мы понимаем что четко идентифицировать каждую строку мы можем только с помощью комбинации столбцов например название проекта плюс участник иными словами зная название проекта и участника мы можем четко определить конкретную запись в

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

что все не ключевые столбцы таблицы должны зависеть от полного ключа чтобы это проверить зададим себе несколько вопросов можем ли мы определить должность знает только название проекта нет для этого нам необходимо знать и участника значит пока все хорошо и по

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

этом случае мы будем выполнять действие которое выполняется наверное в 99 процентах случаев на протяжении всего процесса нормализации базы данных это декомпозиция декомпозиция это процесс разбиения 1 отношения на несколько чтобы декомпозировать нашу таблицу привести базу данных нормальной форме мы должны

создать следующие таблицы таблицы проектов там будет идентификатор проекта название проекта и срок проекта таблица участников где будет идентификатор участника участник и должность и таблица со связью проектов и участников в этих проектов там будет и нотификатор проекта и идентификатор участника и так мы

создали три таблицы проекты в нее мы добавляем искусственно первичный ключ 2 участники в нее мы также добавили искусственный первичный ключ и третье это связь между проектами участниками она нужна для реализации связи многие ко многим так как между этими таблицами

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

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

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

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

правильные не ключевые столбцы для рассмотрения примера давайте возьмем нашу таблицу сотрудниками которые мы приводили к второй нормальной форме еще раз выведем ее на экран тут есть табельный номер фио должность подразделения и описание подразделения чтобы определить находится ли эта

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

подразделения не зависит напрямую от первичного ключа мы это выяснили когда задали себе один вопрос каким образом описание подразделения связано с сотрудником и наш ответ звучит следующим образом атрибут описание подразделения содержит детальные сведения того подразделение в котором работает сотрудник отсюда следует что столбец

описание подразделения не связан напрямую сотрудникам он связан и прямом со столбцом подразделения которые напрямую связан с сотрудником ведь сотрудник работает в каком-то конкретном подразделении и это и есть транзитивной а зависимость когда один не ключевой столбец связано с первичным ключом через

другой не ключевой столбец что мы должны сделать чтобы привести эту таблицу к третьей нормальной форме правильно декомпозицию мы должны эту таблицу разбить на 2 в 1 хранить сотрудников во второй подразделения для реализации связи в таблице сотрудников создать ссылку на таблицу подразделений то есть

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

идентификатор подразделения подразделение и описание подразделения таким образом в наших таблиц их отсутствует транзитивной зависимости они находятся в третьей нормальной форме итак мы привели таблицу базы данных 3 нормальной форме и мы можем переходить к следующей нормальной форме в частности к

нормальной форме boys обхода би си н.ф. между 3 и 4 нормальной формы есть еще промежуточную нормальная форма и она называется как вы уже поняли нормальная форма бойца кода иногда еще ее называют усиленной трети нормальной формой так ее называют потому что ситуации в которых

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

формы бойса кода следующие таблицы должна находиться в третьей нормальной форме и ключевые атрибуты составного ключа не должны зависеть этот не ключевых атрибут отсюда следует что требование нормальной формы бойся кода предъявляются то и к таблицам у которых привычной ключ составной таблицу которых

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

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

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

знает только проект мы не можем определить куратор направления также как зная только направлении мы не можем определить куратора нам нужно знать и проект и направление чтобы определить кураторы этого направления в этом проекте в итоге мы реализуем следующую таблицу в которой первичный ключ

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

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

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

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

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

зависимости в таблицах многозначной зависимость выглядит следующим образом начнем с того что таблицы должны иметь как минимум три столбца допустим а b и c при этом бейтс и между собой никак не связаны и не зависят друг от друга но по

отдельности зависит от а и для каждого значения есть множество значений б а также множество значений c в данном случае многозначная зависимость обозначается вот так а.б. а це если подобная многозначная зависимость есть таблиц то на не соответствуют 4 нормальной форме представим что мы

работаем в каком-то учебном заведении где есть курсы которые изучают студенты и преподаватели которые читают эти курсы аудитории в которых преподаватели проводят занятия по курсам у нас есть таблица курсов зададите fi котором курса и его названием таблицы преподавателей с

идентификатором преподавателя и его фио и таблица аудитории с и нотификатором аудиторий и названием аудитории при этом мы понимаем что один и тот же курс могут ввести разные преподаватели и не обязательно в какой-то одной аудитории один раз курс может считаться в одной

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

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

преподавать тот или иной курс а также в каких аудиториях тот или иной курс может считаться для этого нам нужно соединить эти 3 сущности в одной таблице в итоге у нас получается следующая таблица для наглядности здесь представлено текстовое значение они идентификаторы таблица

связи курсов преподавателей и аудитории в данном случае первичный ключ здесь состоит из всех трех столбцов поэтому это таблице автоматически находится в третьей нормальной форме и нормальной форме бойцы кода однако они находятся в 4 нормальной форме так как здесь есть

много- за на зная зависимость курс преподаватель курс аудитория то есть для каждого курса в этой таблице может быть несколько преподавателей а также несколько аудиторий при этом вы понимаете что преподавателю без разницы в какой аудитории читать лекцию ровно также и сам аудитории без разницы какой

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

чтобы ответить на этот вопрос мы можем задать себе несколько других вопросов что будет если например преподаватель иванов и.и. уволился нам нужно будет удалить две строки из этой таблицы но удалив эти строки мы удалим всю информацию и аудиториях 101 и 203 но они

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

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

неизбежно должны затронуть другую зависимость поэтому главное правило 4 нормальной формы звучит следующим образом в таблице не должно быть многозначных зависимости решение в данном случае как всегда декомпозиция мы должны вынести каждый многозначным зависимость в отдельную таблицу то есть разнести независимые друг от друга

атрибуты в нашем случае преподаватель и аудитория по разным таблицам таблица связь курсов и преподавателей вот она на экране и таблица связь курсов и аудиторий чтобы стало еще понятнее давайте закрепим знания и рассмотрим классический пример который обычно используется в литературе для пояснения

4 нормальной формы вот у нас есть таблица связи студентов курсов и хобби дана таблица хранит информацию о студентах в частности здесь хранятся курсы которые посещают студенты увлечение этого студента то есть хобби отсюда следует что каждый студент может посещать несколько курсов иметь

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

можем наблюдать в этой таблице нетривиально многозначной зависимости студент курс студент хобби поэтому эта таблица не находится в 4 нормальной форме кроме всех тех аномалий связанных с редактированием данных которые мы уже рассмотрели на предыдущем примере в данном случае еще и продемонстрирована

проблема неоднозначной выборки данных допустим нам необходимо получить информацию о хобби студентов которые посещают курс по иску эль очевидным действием станет выборка с условиям курс равно из quelle в результате мы получим 3 хобби футбол волейбол и теннис вот результат выборки на экране однако если

мы заглянем в исходную таблицу то мы четко увидим что иванов и и посещает курс по sql и имеет хобби хоккей но в нашей выборке этого хобби нет чтобы нормализовать эту таблицу мы должны точно так же как и предыдущем примере

разбить ее на 2 на таблицу связи студентов и курсов и таблицу связи студентов и хобби однако в реальности такую таблицу и ситуацию вряд ли можно встретить так как следуя здравому смыслу такие абсолютно не связанных друг с другом данные никто не будет хранить в

одной таблице поэтому этот пример чисто теоретически и приводится для демонстрации принципов 4 нормальной формы если говорить о реальных данных то нормализация до 4 нормальной формы и как и до всех последующих форм современном мире практически не встречается и за

четвертую нормальную форму еще как-то можно представить и даже встретить данные нормализованные до этой формы то встретить данные нормализованные до 5 или 6 нормальный форма практически невозможно вы можете спросить а почему не нормализуют данные до 5 или 6 нормальной формы ведь каждая нормальная

форма устраняет определенные иннамаль и если сделать полностью нормализованы базу данных то по сути она будет идеальна не содержащий ни одной аномалии и ведь это хорошо да совершенно верно база данных не будет содержать аномалий но давайте вспомним какие преимущества

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

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

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

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

нормализована чтобы не создавать anna marie для пользователей этой базы и в то же время она имеет хорошую производительность после того как мы привели таблицы из базы данных 4 нормальной форме мы можем переходить приведению таблиц до 5 вот требование 5

нормальный форма переменные отношения находятся 5 нормальной форме иначе в проекционной соединительной нормальной форме только тогда когда каждая нетривиальная зависимость соединения в ней определяется потенциальным ключом или ключами этого отношения это стандартное определение для 5 нормальной форме и к сожалению более простыми

словами сформулировать определение для 5 нормальной формы достаточно сложно однако на основании этого определения мы можем сделать следующий вывод требования 5 нормальной формы заключается в том чтобы в таблице каждая нетривиальная зависимость соединения определялась потенциальным ключом этой таблице как видите здесь вводится новое понятие

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

данные мы потеряем при соединении двух итоговых полученных после декомпозиции таблиц но если декомпозировать такую таблицу не на 2 она 3 таблицы то потери данных можно избежать и таблица будет находиться в 5 нормальной форме если при соединении то есть joy не этих трех

таблиц которые были получены в результате декомпозиции будут формироваться ровно те же самые данные что и восхода и таблицы до декомпозиции однако если этого происходить не будет то есть данные будут отличаться например какие-то строки были потеряны или созданы новые в этом случае возникает

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

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

нас есть таблицы которая хранит информацию о связи сотрудников с проектами и направлениями работы сотрудников в этих проектах сразу хочется отметить что если у вас когда-то попросит определить находится ли та или иная таблица в 5 нормальной форме в то

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

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

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

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

существуют некие зависимости и эти зависимости определяются не целым потенциальным ключом а только его частью поэтому чтобы устранить возможность внесения некорректных данных мы можем попытаться выполнить декомпозицию без потерь и тем самым привести таблицу к 5 форме чтобы выполнить декомпозицию без

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

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

соединения у нас нет и наши таблицы находятся в 5 нормальной форме если вы смотрите сейчас на экран на запрос не понимаете что там написано то можете посмотреть очень классные нашу статью по синтаксису иска или она очень понятно и

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

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

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

нормальной форме вы должны очень хорошо разбираться предметной области чтобы определить зависимости соединения иными словами если вам удастся определить все эти зависимости то только в этом случае вы сможете привести таблицу к 5 форме но несмотря на то что как мы только что

сказали 5 нормальная форма является окончательной нормальной формы по отношению к операциям разбиения таблиц на проекты и их соединения существуют и другие нормальные формы например домен накручивая нормальная форма детей nfv которая в отличие от рассмотренных ранее нормальных форм не определяется в

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

это ограничение утверждающие что некоторый атрибут или комбинации атрибутов представляет собой потенциальный ключ таким образом требование домена ключевой нормальной форму заключается в том чтобы каждый наложено ограничение на таблицу являлась с логическим следствием ограничений доменов и ограничений ключей которые накладываются на данную таблицу таблица

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

о том когда может быть выполнено такое привидение ну и наконец приступим к последней 6 нормальной форме 6 нормальная форма была введена при работе с хронологическими базами данных хронологической б.д. эта база который может хранить не только текущие данные но исторические данные то есть данные

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

декомпозиция процесс который очень сильно напоминает нашу классическую нормализацию которую мы рассматривали до 5 нормальный формы включить или иными словами декомпозиции таблиц который мы использовали для приведения этих таблиц кто или и на нормальной форме по факту и является вертикальной декомпозиции в

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

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

проекции была сформулирована новая нормальная форма основанная на обобщенное понятие зависимости соединения и поэтому новую форму назвали 6 нормальной формой требований 6 нормальной формы заключается в том что table ты должна удовлетворять всем нетривиальным зависимостям соединения из этого определения следует что таблица

находится в 6 форме когда она не при вадима то есть не может быть подвергнуто дальнейшей декомпозиции без потерь стоит отметить что таблицы которые находятся в 6 форме тоже находится и в 5 и во всех предыдущих как мы уже говорили 6

нормальной формы вводят такое понятие как декомпозиции до конца то есть максимальная возможно декомпозиция таблиц однако если в хронологических базы данных такая нормализация может быть полезно так как она позволяет бороться с избыточностью то не филологический базах нормализации таблиц до 6 нормальной форма приведет к

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

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

тогда принять решение на нормализации если короче то вы должны руководствоваться здравым смыслом ну а на этом все спасибо что послушали эту статью надеюсь вам как и мне было интересно спасибо ресурсы infocomm точка ру за предоставленные статьи и ссылочки

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

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