Нормальные формы баз данных: Объясняем на пальцах
HTML-код
- Опубликовано: 11 май 2024
- Listen IT на Я.Дзене - zen.yandex.ru/listenit
Телеграм-канал Digital Media - t.me/digital_epoch
00:00 - О чём пойдёт речь в статье
00:45 - Коротко о реляционных БД
01:20 - Что такое нормализация
01:46 - Зачем нужна нормализация БД
02:08 - Что такое избыточность данных с примерами
04:51 - Какие бывают нормальные формы БД и о процессе нормалиции в целом
08:00 - Ненормализованная форма или нулевая нормальная форма с примером
09:37 - Первая нормальная форма с примером нормализации
11:24 - Вторая нормальная форма с примером нормализации
15:29 - Что такое декомпозиция
16:18 - Третья нормальная форма с примером нормализации
18:54 - Нормальная форма Бойса-Кодда с примером нормализации
21:54 - Четвертая нормальная форма с примером нормализации
27:45 - Почему обычно никто не нормализует БД до 5 или 6 нормальной формы
29:14 - Пятая нормальная форма с примером нормализации
34:23 - Доменно-ключевая нормальная форма
35:39 - Шестая нормальная форма
38:02 - Выводы и заключение
Поддержать канал разово - yoomoney.ru/to/410012243709514
Поддержать канал подпиской - boosty.to/listenit
Телеграм-канал - t.me/listenit_channel
По вопросам сотрудничества - t.me/ed_akimov
Ссылка на статью - info-comp.ru/database-normali...
Что такое SQL и реляционные базы данных - • Что такое SQL и реляци...
Синтаксис SQL запросов: Часть 1 - • Синтаксис SQL запросов...
Что такое ДЕНОРМАЛИЗАЦИЯ БД за 13 минут - • Video
Моделирование данных за 9 минут - • Что такое ERD за 9 минут
Что такое NoSQL за 6 минут - • Что такое NoSQL за 6 м...
Что такое ACID за 9 минут - • Что такое ACID за 9 минут
Что такое HTTP и HTTPS за 9 минут - • Что такое HTTP и HTTPS...
Что такое UML за 7 минут - • Что такое UML за 7 мин...
Машинное обучение для чайников - • Машинное обучение для ...
Что такое Big Data за 6 минут - • Что такое Big Data за ...
Что такое CRUD за 6 минут - • Что такое CRUD за 6 минут
Введение в REST API за 7 минут - • Введение в REST API за...
Различия REST и SOAP за 4 минуты - • Различия REST и SOAP з...
Что такое middleware за 7 минут - • Что такое middleware з...
зашёл на 5 минут глянуть видос (на тим лид сказал ужасающие слова "Мы начинаем нормализвывать БД"), и пропал на все 40 минут. Определенно, у тебя талант притягивать внимание своих слушателей. Главное, что после просмотра, у меня в квартире сухо и без осадков, а это первое свидетельство того, что данный материал был "без воды") Подписку кинул, лайк!
Он просто все по статье в описании прочитал, поэтому и без воды😅
Мне кажется тот кто придумал дизайн подачи материала для данного канала гений, смотришь на синие буквы на бирюзовом фоне и хочется все видосы посмотреть.
очень нужны такие видео
легче и быстрее информацию принимаешь
спасибо
Переписываю в кучу, чтобы запомнить лучше. Может, пригодится.
*0. Нулевая нормальная форма - **08:00** ( UNF)*
- Строки в таблицах не должно быть пронумерованы (порядок строк и столбцов не имеет значения).
*1. Первая нормальная форма - **09:37** (1NF)*
- В таблице не должно быть дублирующих строк;
- В каждой ячейке таблицы хранится атомарное значение (одно не составное значение);
- В столбце хранятся данные одного типа;
- Отсутствуют массивы и списки в любом виде.
*2. Вторая нормальная форма - **11:24** (2NF)*
- Таблица должна находиться в 1NF;
- Таблица должна иметь ключ;
- Все неключевые столбцы таблицы должны зависеть от полного ключа (если ключ составной).
_Таблица должна иметь правильный ключ, по которому можно идентифицировать каждую строку_ .
*3.1. Третья нормальная форма - **16:18** (3NF)*
- В таблицах не должно быть транзитивной зависимости (неключевые столбцы зависят от других неключевых столбов)
_Неключевые столбцы не должны играть роль ключа в таблице_ .
*3.2. Нормальная форма Бойса-Кодда - **18:54** (BCNF)*
_Требования BCNF актуальны для таблиц с составными ключами. Таблицы 3NF с полным ключом автоматически становятся BCNF_ .
- Таблица должна находиться в 3NF;
- Ключевые атрибуты составного ключа не должны зависеть от неключевых атрибутов.
а теперь пойду в магазин, пока не закрылся. допишу потом.
Вот это красота, шикарный видос, супердоступно, душевно братишечка!
Очень круто. Спасибо за материал!
Отличное видео. Круто что с примерами! Очень полезно. Спасибо)
Очень грамотно преподносите материал, уже не первый раз ваши видео помогают.
Хотелось бы ещё список литературы по обсуждаемому вопросу видеть в конце. Именно ваши рекомендации.
Спасибо!
Спасибо за видео!
Спасибо! Отличный материал как и его подача!
Контент супер
Хорошо объясняешь. Спасибо
Лучший канал, суть вещей без воды!
Это лучшие видео, причем нет ошибки про нулевую форму, которые некоторые считают первой)
как всегда все круто! :D
Очень хорошо, спасибо
Спасибо, очень хорошее видео и объяснения
Спасибо. Это было супер полезно 😊
Если бы нам так объясняли по ходу семестра, я бы сдала лабораторную работу за пять минут :\
Спасибо
Очень приятно слышать :)
базы данных один из самых легких курсов в универе, у нас его осилили все без исключений, я удивлен, что ты его не осилил
@@iam21h мда, откуда ты взял, что предмет я не осилила? Чисто выводы из жопы
@@Laegmerill1306 ну раз осилила эт хорошо
Очень хорошее изложение.
Спасибо!!
Огонь. Разок пересмотрю и туман рассеится
Круто. Интересно. Понятно, особенно со второго раза (для такой тяжёлой абстрактной темы - невероятно). Без воды, но абсолютно не сухое изложение (поразительно)!
Спасибо, очень приятно! И спасибо тут автору статьи, конечно, прежде всего
Божественное видео, зашел от скуки, затянуло
Классное видео! Очень много полезной информации. Было бы интересно послушать про JIRA и Confluence - так как на канале видосов не нашел) Спасибо!
Услышали, добавим в очередь!
Классный канал!!!
очень полезно, спасибо. нам на лекциях транзитивные и функциональные зависимости пытаются пояснять через реляционную алгебру (а точнее показывают нам белиберду на одном слайде которая моментально забывается и не разбирается толком даже). тут слава богу нет такого.
Классное видео, спасибо.
Упрощенно:
Приводите таблицы к как можно меньшему виду, следуя этому принципу вы незаметно для себя пройдете через все уровни нормализаций. Не стесняйтесь создавать таблицы исключительно для связывания двух других таблиц, например по их индексу
Обобщение: Основное правило программирования - не повторятся, оно же действует и здесь. Повторение - зло, устраняйте повторения этапами нормализаций.
Исключение: Не уходите в фанатизм.
все круто !!!
хороший материал спасибо!
Спасибо за отзыв, стараемся!
про 6НФ посмотрите на якорное моделирование и Data Vault и значимость DE/DWH для компаний
Благодарю
Парень, ты просто красавчик! Это лучшее что я видел ))) что нужно, чтобы ты и дальше выпускал ролики?
Спасибо, очень приятно! Можно подписаться на канал - этого будет вполне достаточно) Но если очень сильно хочется поддержать, то есть в описании к видео ссылки на Юмани и Бусти (ролики, естественно, и без этого продолжу выпускать, но будет приятно :)
@@ListenIT_channel от души!
Очень прям хорошо! Браво!
Я бы дополнил, что 6нф не обязательно высшая форма с поддержанием историчности. Для этого обычно применяют медленно-изменяющиеся измерения типа 2. И под scd-2 можно подстроить сущность в третьей нормальной форме, получив необходимую и достаточную нормализацию данных, и отсутствие ограничений в периодах актуальности этих данных. Как для прошлого, так и для периодов в будущем. 😊
graet,thanks.)😎😎😎😎
Просто лучший видос! Нам его препод на парах показывал
Спасибо, очень приятно! Но тут, конечно, прежде всего, спасибо автору статьи, за такую классную содержательную статью.
похоже, что я спроектировал 3NF для своей CRM еще до того, как узнал о каких то правилах. Наверное, это хороший знак ))
20:53 тут можно составной ключ из 3 частей сделать, да и "направление" это скорее информация относящаяся строго к проекту и должна находится внутри таблицы проектов
Однако... Инфа супер!
Если это было снять с 1ого дубля, то вообще респект
А у вас нет случайно только аудио? Хотелось бы слушать при езде в метро или при топании на работу
хотел бы посмотреть материал JAVA+SQL
Жуть как круто!
Звук во вступлении будто из Героев Меча и Магии III, момент регенерации, кажется.
Ого, какие вы крутые.
В общем руководствуемся здравым смыслом )
🔥
Про 4 НФ немного не понятно, самый первый пример препод-курс-аудитория не поддается декомпозиции без потерь. Разбив таблицу препод-курс-аудитория на две таблицы курс-препод и курс-аудитория мы теряем информацию. Например теряем информацию что Иванов ведет курс SQL в 101 аудитории (представим что это реально расписание и реально нужна именно эта связь (курс-препод-аудитория)). Хотя в первой таблице эта информация была и она явно важная (как для расписания). Это не претензия к автору видоса, просто нужно знать что некоторые данные не поддаются декомпозиции без потерь.Поэтому форма Бойса Кодда это максимум "нормальности" который можно выжать из подобных данных.
Знание предметной области и руководство разумными решениям это хорошо, но никто не застрахован от того что в будущем придет манагер и не выдаст что-то вроде: "Так, сейчас кризис, поэтому каждый сотрудник теперь обязан работать в двух отделах на трёх должностях, и имееть соответственно по два рабочих телефона для каждого отдела, а на один телефон до двух должностей. К завтрашнему дню пожалуйста внесите вот эти кадровые изменения в программу!".
А еще, приготовьте мне кофе и вымойте пол, поскольку Вы теперь не только программист, но и секретарь-уборщица )))
Знающие подскажите, если идентификаторы зависит друг от друга то это 2НФ?(пример: в таблице клиенты 10 строк и в таблице заказы, заказы не могут превышать 10). Если таблице есть два идентификатора то это 3НФ?
Отличный пример отсутствия нормализации данных - это фильтры в торговых площадках, типа озона или вайлдберис, где параметры товара заполняет продавец. Зачастую ни один из этих фильтров использовать невозможно, кроме цены и, может быть, бренда. Хотя и там умудряются внести несколько вариаций одного названия.
15:54 , но ведь при просмотре таблицы с проектами и участниками не будет понятно сразу что за проекта в конкретной ячейке и какой участник прикреплен за ним, или это я не понял?
18:32 здесь лучше бы подошла связывающая таблица "сотрудники_департаменты"
Получил порцию слова нормально на 15 лет вперед
нормальной формы
а разве на 21:43 таблица Кураторов не нарушает 3NF? Ведь первичным ключом является идентификатор куратора, но при этом атрибуты направления могут зависеть от атрибутов ФИО (где оба являются неключевыми). Или же мы не должны проверять на условие NF таблицы полученные путем декомпозиции, а лишь проверять таблицу связи?
Конкретно на примере из статьи похоже, что таблица кураторов достаточно нормализована. Нет смысла (чаще всего) выносить направления в отдельную таблицу, если у направления нет своих атрибутов (можно, конечно, сделать справочник направлений только с ИД направления и его названием, но это не всегда оправдано). Иногда можно и вынести направления в отдельную таблицу, но для этого примера это было бы ни к чему и слишком громоздко
Декомпозиция - это процесс разделения чего угодно на более мелкие составные части, а не только таблиц
В любой непонятной ситуации - декомпозируй
Думаю, если короче, то 1нф - как организовать таблицы, 2нф - как организовать связи
понял ... ! теперь свою рукож#пость буду аномалией называть !
9:00 это же вторая нормальная форма по-факту
Ккллласссссссссссс !!!
4:01 или создать констрейнт со списком допустимых имен
В таком кейсе, как в примере, нежелательно, т. к. перечень значений может динамически меняться, и в этом случае лучше использовать справочники. Плюс, если у значений справочников чуть более сложная структура, чем просто одно название (например, перевод на разные языки и ещё другие атрибуты), то тут уже точно справочник нужен.
@@ListenIT_channel отдельная таблица имеет смысл только при динамическом изменении, так как в случае со справочником наоборот удобнее использовать enum как ключ
@@N5O1 проблема в том, что справочники, как правило, имеют свойство обновляться, даже если бизнес говорит, что это самый стабильный перечень значений в мире)
по dknf просто с Википедии зачитали, я это и сам видел там, ни фига не понятно
12:35 Разве все значения в этой таблицу атомарны? Ведь Ф.И.О. можно разделить отдельно на фамилию, имя и отчество. Так что, извините, не соглашусь.
Это всё-таки просто пример - понятно, что никто не будет хранить ФИО в одной ячейке (редко разве что) да ещё с инициалами :)
@@ListenIT_channel согласен :) Доброго вечера!
лучшее что я видел по НФ
10:27 а разве там не может быть 2 джона смита? просто они живут в одном домохозяйстве и предоставили один и тот же номер телефона
Всё от бизнес-контекста зависит. Чаще всего такого не может быть, но если в системе подразумевается, что у разных людей с одним именем может быть один номер телефона, то почему бы и нет, возможно.
Зачем делать ключом какое то поле, если можно просто добавить поле ID и сделать его ключом во всех таблицах. Такое поле гарантированно будет уникальным.
9:16 а если использовать значение первой колонки как PK то вполне всё получается =)
Можно, но называть это "порядковым номером" не стоит, так как ключ означает не порядковый номер, а идентификатор
На счет уникального табельного номера Вы не правы. Человек может уволиться, после года работы, а потом вновь поступить на работу в ту же организацию, и 100% под новым табельным номером.. и если искать по ФИО + дата рождения то выпадут 2, а то и 3 записи. Бывало, что целыми цехами по 200-500чел увольняли-принимали сотрудников, но в уже другой цех-подразделение (на то был свои причины). Так что, я бы не рассматривал табельный номер, как единственный идентификатор. Просто такое-же поле как и фио.
Я бы не удалял номера, а при повторном устройстве на работу, использовал бы их же.
28:55 автор не сталкивался с "настоящими" программистами, чей могз изуродован бесконечным количеством литературы которую они поглащают и такое чувство, что они уже оторваны от реальности и пишут код только лишь бы это бы так как написано в книжке =)
вот вёрстка по БЭМ это меня одного бесит?
а разве наличие первичного ключа нельзя считать пронумерованием строк???? тогда и ненорм.форма даже не соблюдается ведь
Не совсем. Первичный ключ - это уникальный идентификатор строки, т. е. это не порядковый номер. Порядковый номер = 5 означает, например, что эта строка пятая в таблице. А ключ = 5 у строки только означает, что идентификатор равен 5, и это уникальный номер строки. Какой бы мы запрос не сделали, сколько бы мы строк не запросили из таблицы, и на каком бы порядковом месте в таблице не оказалась эта строка, она всё равно будет иметь ID = 5. Т. е. да, идентификатор действительно иногда генерируется как нумерация строк по порядку, но только этот номер "железно" присваивается строке и не означает порядковый номер, а именно что уникальный идентификатор, и не изменяется при разном положении этой строки в таблице.
Поле ФИО не является атомарным
что такое транзитивная зависимость?))) и откуда этот термин вообще вылез, так плохо обьясняется 3NF, что плакать хочется, хотя там все супер просто
gadgetshelp.com/prilozheniia/chto-takoe-tranzitivnaia-zavisimost-v-baze-dannykh/
видимо я слишком тупой для этого...
аьоьа
глубоко
Одно понятно - Илон Маск скорость на своей залупе в космос летать будет.
лол, а как сделать декомпозицию к 3-ей нормальной форме если ты ее уже сделал , что бы привести таблицу ко 2 нормальной форме ??? то есть у тебя 2-я нормальная форма - это 3 таблицы допустим разбитых на части,
Спасибо! Отличный материал как и его подача!
Спасибо! Отличный материал как и его подача!
Ну, за материал тут, скорее, автору статьи спасибо, а за подачу благодарю :)