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

[@dahtes2107]

зашёл на 5 минут глянуть видос (на тим лид сказал ужасающие слова "Мы начинаем нормализвывать БД"), и пропал на все 40 минут. Определенно, у тебя талант притягивать внимание своих слушателей. Главное, что после просмотра, у меня в квартире сухо и без осадков, а это первое свидетельство того, что данный материал был "без воды") Подписку кинул, лайк!

[@Enigmikh]

Он просто все по статье в описании прочитал, поэтому и без воды😅

[@rsh3852]

Норм

[@privet2pizza]

Переписываю в кучу, чтобы запомнить лучше. Может, пригодится. *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; - Ключевые атрибуты составного ключа не должны зависеть от неключевых атрибутов. а теперь пойду в магазин, пока не закрылся. допишу потом.

[@kaawaabaanga]

вы так и не вернулись из магазина?)

[@fimdi]

Вы пошли за хлебом?

[@vanekonste3120]

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

[@dramster3518]

На авторе просто легенда, очень понятно и интересно объяснил, подача очень хорошая с понятными примерами, ещё и дизайн ненапряжный. Спасибо большое!

[@darkcrusaderzxc]

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

[@gskodnik]

Спасибо! Отличный материал как и его подача!

[@ListenIT_channel]

Ну, за материал тут, скорее, автору статьи спасибо, а за подачу благодарю :)

[@armorunit6970]

Очень грамотно преподносите материал, уже не первый раз ваши видео помогают. Хотелось бы ещё список литературы по обсуждаемому вопросу видеть в конце. Именно ваши рекомендации. Спасибо!

[@rendi5799]

Круто. Интересно. Понятно, особенно со второго раза (для такой тяжёлой абстрактной темы - невероятно). Без воды, но абсолютно не сухое изложение (поразительно)!

[@ListenIT_channel]

Спасибо, очень приятно! И спасибо тут автору статьи, конечно, прежде всего

[@ДевятыйДан]

Вот это красота, шикарный видос, супердоступно, душевно братишечка!

[@tsoer2976]

Это лучшие видео, причем нет ошибки про нулевую форму, которые некоторые считают первой)

[@StepanVorobiov]

Отличное видео. Круто что с примерами! Очень полезно. Спасибо)

[@takecare-q8b]

Лучший канал, суть вещей без воды!

[@Luv1c]

Спасибо! Вы очень классно и понятно объясняете материал, мне это помогло в зачетах :)

[@ListenIT_channel]

Круто, рад, что помог)

[@Игорь-ж9е4з]

Парень, ты просто красавчик! Это лучшее что я видел ))) что нужно, чтобы ты и дальше выпускал ролики?

[@ListenIT_channel]

Спасибо, очень приятно! Можно подписаться на канал - этого будет вполне достаточно) Но если очень сильно хочется поддержать, то есть в описании к видео ссылки на Юмани и Бусти (ролики, естественно, и без этого продолжу выпускать, но будет приятно :)

[@Игорь-ж9е4з]

@@ListenIT_channel от души!

[@Devivl]

Очень круто. Спасибо за материал!

[@enkifirm]

Контент супер Хорошо объясняешь. Спасибо

[@zakarmoy]

Классное видео! Очень много полезной информации. Было бы интересно послушать про JIRA и Confluence - так как на канале видосов не нашел) Спасибо!

[@ListenIT_channel]

Услышали, добавим в очередь!

[@anonsd5521]

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

[@KarenGarushian]

Огонь. Разок пересмотрю и туман рассеится

[@TheSeko786]

Божественное видео, зашел от скуки, затянуло

[@Laegmerill1306]

Если бы нам так объясняли по ходу семестра, я бы сдала лабораторную работу за пять минут :\ Спасибо

[@ListenIT_channel]

Очень приятно слышать :)

[@iam21h]

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

[@Laegmerill1306]

@@iam21h мда, откуда ты взял, что предмет я не осилила? Чисто выводы из жопы

[@iam21h]

​@@Laegmerill1306 ну раз осилила эт хорошо

[@ДанилДмитриев-я5м]

@@iam21h зачем ты это пишешь? алеша

[@ilikegeorgiabutiveonlybeen6705]

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

[@ВладимирГавриленко-з7л]

Классный канал!!!

[@By-pf6bw]

Очень хорошо, спасибо

[@АлександрОсипов-г7е]

Очень хорошее изложение.

[@selfcreator8921]

Спасибо, очень хорошее видео и объяснения

[@НастяГераськина-м5я]

спасибо огромное, стало очень понятно🥰

[@ListenIT_channel]

Рад, что помогло :)

[@ЕкатеринаЗиберт-у1ю]

Спасибо за видео!

[@ИльяМакаров-г1г]

очень качественное объяснение

[@meepo1020]

как всегда все круто! :D

[@RaptorT1V]

Просто лучший видос! Нам его препод на парах показывал

[@ListenIT_channel]

Спасибо, очень приятно! Но тут, конечно, прежде всего, спасибо автору статьи, за такую классную содержательную статью.

[@MrMonMonach]

Введение в реляционные базы данных и нормальные формы 1. База данных - это любой набор данных, который можно хранить и управлять. 2. Реляционная модель - это структура для организации и хранения данных, где информация представляется в виде отношений (таблиц). 2.1 Отношения - таблицы, состоящие из множества записей (строк), каждая из которых состоит из атрибутов (столбцов). Описание: Каждая строка в таблице можно рассматривать как элемент отношения, а атрибуты определяют характеристики этих элементов. 2.2 Кортежи - это строки таблицы (записи). Описание: Упорядоченная коллекция (набор) элементов, соответствующих атрибутам таблицы. Порядок имеет значение, так как он соответствует структуре таблицы и представляет отдельные записи, связанные с сущностями (например, конкретный клиент или товар). 2.3 Атрибуты - это поля таблицы (столбцы). Описание: Атрибуты описывают свойства или характеристики записей (сущностей). Они могут быть разных типов. Например, у клиента могут быть атрибуты: имя, адрес, возраст, вес. 3. Реляционная база данных - это упорядоченная информация, связанная между собой определенными отношениями. Такие базы данных состоят из таблиц, в которых и содержится вся информация. 4. Связь между данными Описание: Отношение также описывает связь между данными. Например, в таблице "Клиенты" могут храниться данные о клиентах, а в таблице "Заказы" - информация о заказах этих клиентов. Связи между таблицами (например, через первичные и внешние ключи) позволяют связывать данные и обеспечивать целостность. 5. Основные понятия 5.1 Избыточность данных - это ситуация, когда одни и те же данные хранятся в нескольких местах, что приводит к аномалиям, требующим обновления или удаления одинаковых данных в нескольких местах. 5.2 Нормальная форма базы данных - это набор правил и критериев, которым должна отвечать база данных, чтобы избежать избыточности и аномалий. 5.3 Нормализация - это последовательный процесс приведения базы данных к нормальным формам, начиная с ненормализованной формы (UNF) и переходя к более высоким нормальным формам. Процесс: Удаление избыточных данных. Устранение аномалий. Повышение производительности. Повышение удобства управления

[@olzhikggg6915]

хороший материал спасибо!

[@ListenIT_channel]

Спасибо за отзыв, стараемся!

[@artetl]

Очень прям хорошо! Браво! Я бы дополнил, что 6нф не обязательно высшая форма с поддержанием историчности. Для этого обычно применяют медленно-изменяющиеся измерения типа 2. И под scd-2 можно подстроить сущность в третьей нормальной форме, получив необходимую и достаточную нормализацию данных, и отсутствие ограничений в периодах актуальности этих данных. Как для прошлого, так и для периодов в будущем. 😊

[@illusionsoftworks7866]

Видео добротное, лично мне было бы приятно увидеть список дополнительной литературы (не обязательно книги, это могут быть и просто статьи на Хабре, и материалы конференций - что угодно) и больше наглядных примеров, по нескольку для каждой нормальной формы.

[@tonybard]

про 6НФ посмотрите на якорное моделирование и Data Vault и значимость DE/DWH для компаний

[@Комедиявдеталях]

похоже, что я спроектировал 3NF для своей CRM еще до того, как узнал о каких то правилах. Наверное, это хороший знак ))

[@elf8641]

Спасибо ❤

[@N5O1]

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

[@MrSatan662]

Спасибо. Это было супер полезно 😊

[@artemky3bmu45]

Спасибо!!

[@johnb7657]

Благодарю

[@alexandrsargsyan2202]

все круто !!!

[@ArtemGurtikov]

почему на 18:50 мы не выносим должности в отдельную таблицу?

[@ListenIT_channel]

@@ArtemGurtikov да, вы правы, должности тоже нужно выносить в отдельную таблицу 100%. Думаю, автор опустил это, чтобы много не расписывать, а просто принцип показать. Либо просто не заметил :)

[@dariaandrukevich858]

Материал отличный. Делала заметки и конспект в процессе просмотра, чтобы лучше запомнить важные аспекты. Но у меня возник вопрос по третьей нормальной форме. НА промежутке 18:36 говорится о том, что в таблице будет храниться ФИО, должность и по сути id подразделения. Но почему бы не вынести должность так же в отдельный справочник\таблицу? Ведь должность такой аспект, который может повторяться, и при вводе данных о должности можно ошибиться. Например, сотрудник введет должность как "праграмист", и это уже будет аномалия. Так как при поиске программистов в организации, человек с должностью "праграмист" в выборке присутствовать не будет. Поправьте, если не правильно рассуждаю.

[@ListenIT_channel]

Спасибо за отзыв, очень приятно! Да, всё правильно говорите. Должности нужно обязательно выносить в отдельную таблицу и прописывать её ИД в таблице сотрудников. Думаю, автор просто оставил названия должностей, чтобы переусложнять восприятие таблицы (правда, суть 3NF потерялась для должностей, получается - факт :) Вообще, на практике таблица сотрудников обычно выглядит как несколько атрибутов сотрудника и куча внешних ключей-идентификаторов: его должность, направление, отдел, локация и пр.

[@BellCranel-c3p]

То самое чувство, когда в универе льют воду на 4 пары и все равно нормально не объясняют, а тут вы за 40 минут все по полочкам раскидали... Большое спасибо за видео)

[@ListenIT_channel]

Спасибо, рад, что помог :)

[@Miko-pe6oe]

15:54 , но ведь при просмотре таблицы с проектами и участниками не будет понятно сразу что за проекта в конкретной ячейке и какой участник прикреплен за ним, или это я не понял?

[@malinam785]

В 14:36, объясните кто нибудь, почему нельзя вместо составного ключа, просто создать какой то ID или условный N°- (number) для идентификации строки? Так тоже ведь будет понятно про какую строку идет речь

[@ListenIT_channel]

Всё верно, обычно так и делают - добавляют uid строки просто.

[@saitama-s9w]

graet,thanks.)😎😎😎😎

[@constantsvariables866]

лучшее что я видел по НФ

[@MrCursedsin]

Если это было снять с 1ого дубля, то вообще респект

[@KrokodiLNR]

Однако... Инфа супер!

[@bulatnikoffdmitrii4438]

В общем руководствуемся здравым смыслом )

[@Aurelius1221]

а разве на 21:43 таблица Кураторов не нарушает 3NF? Ведь первичным ключом является идентификатор куратора, но при этом атрибуты направления могут зависеть от атрибутов ФИО (где оба являются неключевыми). Или же мы не должны проверять на условие NF таблицы полученные путем декомпозиции, а лишь проверять таблицу связи?

[@ListenIT_channel]

Конкретно на примере из статьи похоже, что таблица кураторов достаточно нормализована. Нет смысла (чаще всего) выносить направления в отдельную таблицу, если у направления нет своих атрибутов (можно, конечно, сделать справочник направлений только с ИД направления и его названием, но это не всегда оправдано). Иногда можно и вынести направления в отдельную таблицу, но для этого примера это было бы ни к чему и слишком громоздко

[@AM-pd9dj]

Знание предметной области и руководство разумными решениям это хорошо, но никто не застрахован от того что в будущем придет манагер и не выдаст что-то вроде: "Так, сейчас кризис, поэтому каждый сотрудник теперь обязан работать в двух отделах на трёх должностях, и имееть соответственно по два рабочих телефона для каждого отдела, а на один телефон до двух должностей. К завтрашнему дню пожалуйста внесите вот эти кадровые изменения в программу!".

[@niceandquickly]

А еще, приготовьте мне кофе и вымойте пол, поскольку Вы теперь не только программист, но и секретарь-уборщица )))

[@olzhikggg6915]

хотел бы посмотреть материал JAVA+SQL

[@maxamly]

Про 4 НФ немного не понятно, самый первый пример препод-курс-аудитория не поддается декомпозиции без потерь. Разбив таблицу препод-курс-аудитория на две таблицы курс-препод и курс-аудитория мы теряем информацию. Например теряем информацию что Иванов ведет курс SQL в 101 аудитории (представим что это реально расписание и реально нужна именно эта связь (курс-препод-аудитория)). Хотя в первой таблице эта информация была и она явно важная (как для расписания). Это не претензия к автору видоса, просто нужно знать что некоторые данные не поддаются декомпозиции без потерь.Поэтому форма Бойса Кодда это максимум "нормальности" который можно выжать из подобных данных.

[@bunta8789]

21:03 Я что-то не понимаю. Если у нас есть зависимость ключевого атрибута (направление) от неключевого атрибута (куратор) в данной таблице, то она также сохранилась в этой таблице 21:37 Просто теперь это зависимость одного неключевого атрибута (направление) от другого неключевого (ФИО, то же самое, что куратор до декомпозиции). Только теперь эти таблицы даже не соответствуют 3NF, т. к. есть транзитивная зависимость

[@Bibliophilos]

Звук во вступлении будто из Героев Меча и Магии III, момент регенерации, кажется.

[@Vic-o2h]

Это неправда, что высокая нормализация встречается крайне редко. Якорная модель (anchor), например, использует 5NF. Вместе с Data Vault (тоже высоконормализованным) они составляют основу современных классических хранилищ данных в больших компаниях. Если в DWH более 50Тб, и у него есть детальный слой, то он почти наверняка высокономализованный.

[@dchenk]

Ого, какие вы крутые.

[@rockstation768]

Знающие подскажите, если идентификаторы зависит друг от друга то это 2НФ?(пример: в таблице клиенты 10 строк и в таблице заказы, заказы не могут превышать 10). Если таблице есть два идентификатора то это 3НФ?

[@N5O1]

28:55 автор не сталкивался с "настоящими" программистами, чей могз изуродован бесконечным количеством литературы которую они поглащают и такое чувство, что они уже оторваны от реальности и пишут код только лишь бы это бы так как написано в книжке =)

[@Ролтун]

вот вёрстка по БЭМ это меня одного бесит?

[@aliceboyarkina5546]

А у меня такой вопрос появился касаемо примера про 1 нормальную форму, у нас в столбце «сотрудник» дублируются имена, я вижу тут связь 1 ко многим (1 сотрудник может иметь несколько телефонов), значит чтобы данный пример окончательный стал 1 нормальной формой нам необходимо вынести сотрудников в отдельную таблицу и связать их? Опираюсь на принцип: «у первой нормальной формы в таблице не должно быть дублирующихся строк»? Буду рада, если подскажите правильность моей мысли!

[@МиколаМельник-ж1м]

Як на мене на початку проєктування якщо правельно розставити звязки то і таблиці получаться нормальними, ну а ці правила можуть знадобитись коли до таблиці в ході використання ми видаляємо чи додаємо якісь поля

[@roboheat752]

А у вас нет случайно только аудио? Хотелось бы слушать при езде в метро или при топании на работу

[@amwake7810]

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

[@N5O1]

18:32 здесь лучше бы подошла связывающая таблица "сотрудники_департаменты"

[@0imax]

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

[@indigolight6007]

kzbin.info/www/bejne/sKK0qYqaidWGf6M но ведь должность зависит от фио а не от табельного номера. значит должна быть еще одна таблица - должности. и передавать также вторичный ключ как и подразделение. или в таблице сотрудники добавить айдинишники, которые будут ключом, хотя и в этом случае придется должность выносить в отдельную таблицу так как не будет соответствовать второй нормальной форме

[@isop7547]

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

[@FISI_Deutschland]

12:35 Разве все значения в этой таблицу атомарны? Ведь Ф.И.О. можно разделить отдельно на фамилию, имя и отчество. Так что, извините, не соглашусь.

[@ListenIT_channel]

Это всё-таки просто пример - понятно, что никто не будет хранить ФИО в одной ячейке (редко разве что) да ещё с инициалами :)

[@FISI_Deutschland]

@@ListenIT_channel согласен :) Доброго вечера!

[@alexeysavitski5005]

Получил порцию слова нормально на 15 лет вперед

[@anastasiabruks9700]

нормальной формы

[@N5O1]

10:27 а разве там не может быть 2 джона смита? просто они живут в одном домохозяйстве и предоставили один и тот же номер телефона

[@ListenIT_channel]

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

[@vlad-bruce]

28:28 я подумал, у меня глаз начал дёргаться. до этого не замечал

[@useragent000]

Думаю, если короче, то 1нф - как организовать таблицы, 2нф - как организовать связи

[@MrMonMonach]

Нормальные формы 0NF Нулевая нормальная форма (ненормализованная форма) Цель: Определить начальную структуру данных. Действие: Собрать (Записывать) данные без соблюдения реляционных принципов, не структурируя их в таблицы. 1NF (Первая нормальная форма) Цель: Устранить дублирование строк и обеспечить атомарность данных. Действие: Заполнить все атрибуты, чтобы они содержали только одно атомарное значение без повторяющихся атрибутов. Последовательность: 1. Разделить составные значения на отдельные атрибуты. 2. Убедиться, что в каждом атрибуте содержится только одно значение (атомарность). 3. Удалить повторяющиеся атрибуты с одинаковым смыслом. Результат: - нет дублирующихся строк - все атрибуты атомарны (содержат одно не составное значение) - нет повторяющихся атрибутов с одинаковым смыслом 2NF (Вторая нормальная форма) Цель: Устранить частичные зависимости от первичного ключа. Центр внимания: Первичный ключ (Полная функциональная зависимость от PK) Действие: Разделить таблицы так, чтобы каждый неключевой атрибут зависел от всего первичного ключа, исключив зависимости от его частей. Последовательность: 1. Определить составные ключи в таблице. 2. Убедиться, что все неключевые атрибуты зависят от всего составного ключа, а не от его части. 3. Разделить таблицы, если неключевые атрибуты зависят только от части ключа. Результат: - отношение находится в первой нормальной форме - есть первичный ключ - все неключевые атрибуты функционально зависят от первичного (PK) ключа целиком, а не от его части Ключ: Столбец или набор столбцов, по которым гарантировано можно отличить строки друг от друга. Содержит уникальное значение. Пример: В таблице с атрибутами (ID_студента, Курс, Имя_студента), где (ID_студента, Курс) является составным первичным ключом, имя студента должно зависеть от всего ключа (ID_студента, Курс), а не только от ID_студента. 3NF (Третья нормальная форма) Цель: Устранить транзитивные зависимости между неключевыми атрибутами. Центр внимания: Прямые зависимости от PK Действие: Устранить транзитивные зависимости, гарантируя, что каждый неключевой атрибут зависит только от первичного ключа, без влияния других неключевых атрибутов. Последовательность: 1. Проверить зависимости между неключевыми атрибутами. 2. Определить, имеются ли транзитивные зависимости (неключевые атрибуты, зависящие от других неключевых атрибутов). 3. Разделить таблицы, чтобы убрать транзитивные зависимости, перенесенные в новые таблицы. Результат: - отношение находится во второй нормальной форме - Неключевые атрибуты напрямую зависят только от первичного ключа и не имеют зависимостей от других атрибутов (отсутсвие транзитивной зависимости). Транзитивная зависимость: Зависимость неключевых столбцов от значений других неключевых столбцов. Исключение транзитивной зависимости: Производится путем декомпозиции - разнесением атрибутов в разные таблицы. Пример: Если в таблице есть (ID_студента, Курс, Имя_студента, Адрес_преподавателя), и Адрес_преподавателя зависит от Курс, то это транзитивная зависимость. Чтобы перейти в 3NF, нужно разделить данные на две таблицы.

[@sergpil7534]

понял ... ! теперь свою рукож#пость буду аномалией называть !

[@itdev4680]

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

[@СергейИгнатов-ф6у]

"привести базу к минимальной избыточности" на мой взгляд не отражает сути нормализации - грамотнее сказать что данные и базы данных ПРОЕКТИРОВАТЬ нужно в компактной лаконичной и удобной для понимания форме - причем понимать эти данные должен потом не только проектировщик БД, но и пользователь БД... С тех пор как связи между таблицами стали визуализировать нужно было давно модифицировать и определение нормализации

[@MacxaD]

В любой непонятной ситуации - декомпозируй

[@Bfiabecksjbdicbsjzkkxnsh]

по dknf просто с Википедии зачитали, я это и сам видел там, ни фига не понятно

[@N5O1]

9:16 а если использовать значение первой колонки как PK то вполне всё получается =)

[@ListenIT_channel]

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

[@kiryajan]

🔥

[@N5O1]

4:01 или создать констрейнт со списком допустимых имен

[@ListenIT_channel]

В таком кейсе, как в примере, нежелательно, т. к. перечень значений может динамически меняться, и в этом случае лучше использовать справочники. Плюс, если у значений справочников чуть более сложная структура, чем просто одно название (например, перевод на разные языки и ещё другие атрибуты), то тут уже точно справочник нужен.

[@N5O1]

@@ListenIT_channel отдельная таблица имеет смысл только при динамическом изменении, так как в случае со справочником наоборот удобнее использовать enum как ключ

[@ListenIT_channel]

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

[@mikhail8376]

9:00 это же вторая нормальная форма по-факту

[@alexandrsargsyan2202]

Ккллласссссссссссс !!!

[@black_sea99]

На счет уникального табельного номера Вы не правы. Человек может уволиться, после года работы, а потом вновь поступить на работу в ту же организацию, и 100% под новым табельным номером.. и если искать по ФИО + дата рождения то выпадут 2, а то и 3 записи. Бывало, что целыми цехами по 200-500чел увольняли-принимали сотрудников, но в уже другой цех-подразделение (на то был свои причины). Так что, я бы не рассматривал табельный номер, как единственный идентификатор. Просто такое-же поле как и фио.

[@furybarzha]

Я бы не удалял номера, а при повторном устройстве на работу, использовал бы их же.

[@DanielLenskiy]

Зачем делать ключом какое то поле, если можно просто добавить поле ID и сделать его ключом во всех таблицах. Такое поле гарантированно будет уникальным.

[@РустамРаджабов-ц3м]

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

[@ListenIT_channel]

Не совсем. Первичный ключ - это уникальный идентификатор строки, т. е. это не порядковый номер. Порядковый номер = 5 означает, например, что эта строка пятая в таблице. А ключ = 5 у строки только означает, что идентификатор равен 5, и это уникальный номер строки. Какой бы мы запрос не сделали, сколько бы мы строк не запросили из таблицы, и на каком бы порядковом месте в таблице не оказалась эта строка, она всё равно будет иметь ID = 5. Т. е. да, идентификатор действительно иногда генерируется как нумерация строк по порядку, но только этот номер "железно" присваивается строке и не означает порядковый номер, а именно что уникальный идентификатор, и не изменяется при разном положении этой строки в таблице.

[@vesterertesterer2459]

16:23

[@otahjuelasso]

Вы очень быстро читаете. Для доходчивости читайте медленно и с расстановкой.

[@dreamingMary]

А мне наоборот кажется что медленно читает, слушаю на х1,5 😅

[@otahjuelasso]

@@dreamingMary А вы попробуйте вспомнить через 5 минут, что он сказал хотя-бы на 1,5 скорости. Для фона слушать можно и на 2-й.

[@ordossanktorum]

Поле ФИО не является атомарным

[@nikolay4362]

что такое транзитивная зависимость?))) и откуда этот термин вообще вылез, так плохо обьясняется 3NF, что плакать хочется, хотя там все супер просто

[@ListenIT_channel]

gadgetshelp.com/prilozheniia/chto-takoe-tranzitivnaia-zavisimost-v-baze-dannykh/

[@ktoeto8094]

Это такое отношение;) вышку не надо было прогуливать

[@KrazyHell]

видимо я слишком тупой для этого...

[@hellhound4138]

аьоьа

[@karabas8902]

глубоко

[@ЕвгенийМирошниченко-е5м]

Случайно попал на видео. Увы, автор вообще мало что понимает в нормальных формах, уровень знаний крайне низкий. Огромное количество утверждений смехотворно ошибочные. Множество самопальных выдумок. Приводимые для иллюстрации примеры зачастую вообще не имеют отношения к рассматриваемой НФ. Это какой-то позор. Не нужно снимать такие видео, вы только запутываете людей.

[@ListenIT_channel]

Так, давайте разбираться. Напишите список ошибочных утверждений?

[@ЕвгенийМирошниченко-е5м]

@@ListenIT_channel Ну, давайте начнём. Посмотрим хотя бы на первые две три минуты ролика. 00:49 «Под базой данных можно понимать любой набор информации, которую можно найти в этой базе данных». Как вам определение? Оно вообще рекурсивное. 02:34 Таблица («Идентификатор предмета», «Наименование предмета», «Материал») на самом деле удовлетворяет всем нормальным формам, но в ролике представлена как будто бы неправильная и требующая нормализации. На деле, если предложить автору ролика указать, какая НФ нарушена, он не сможет. Потому что никакая не нарушена. Пока хватит, попытайтесь ответить на эти замечания, потом могу продолжить.

[@ListenIT_channel]

@@ЕвгенийМирошниченко-е5м 1. Это "определение" не претендует на точное научное описание и не преподносится как определение, а упоминается для того, чтобы "на пальцах" новичку объяснить, что имеется в виду - думаю, эта фраза выполняет свою задачу (видео вообще не про определение БД, эта фраза упоминается вскользь). Академическое ли это определение? Нет. И не должно быть в данном контексте. Мне кажется, тут вы просто придрались, и непонятно зачем. 2. А вот это интересный вопрос. Тут транзитивную зависимость очень сложно уловить, но выделение материала в отдельную таблицу я бы назвал неявным приведением к 3NF. Но это спорный момент - согласен. То, что тут "однозначно не нарушена никакая НФ" - как минимум, точно не так однозначно, как вы об этом говорите. Ну и блок, в котором приведён пример, обсуждает избыточность данных - пока никакая конкретная НФ там не рассматривается. Ладно, давайте сэкономим друг другу время и не будем попусту спорить. Вам видео явно не понравилось (и это ваше право), и у вас явно настрой придраться к любой фразе, а я явно буду защищать статью автора, потому что почти во всём с ним согласен. Кстати, в видео действительно есть более важные условности, которые допустил автор, и мы их довольно успешно разбираем в комментариях выше со зрителями, без негатива. Вы же решили написать про "определение" БД и говорить про "самопальные выдумки". Могу вам пожелать только не быть таким категоричным во всём, ну и успехов :)

[@ЕвгенийМирошниченко-е5м]

@@ListenIT_channel Неправда, я написал, что взял примеры (некорректных высказываний и нерелевантных примеров) из первых же двух-трёх минут ролика. И готов продолжить. Это всего лишь значит, что я двигаюсь последовательно. Например, уже на 5-й минуте автор вводит диковинный термин «нормальная форма базы данных». Такого понятия не существует. НФ бывает только у отдельного отношения. Это иллюстрирует степень владения автора терминологией. Далее, примером «самопальной выдумки» является «нулевая нормальная форма», о которой автор поведал на 6-й минуте. Нет никакой «нулевой нормальной формы». Затем автор ввёл понятия «основных» и «дополнительных» НФ. Это тоже выдумка, такого деления не существует. Например, BCNF ничем не менее «основная», чем другие. Затем автор на 7-й минуте заявляет, что «третья форма устраняет достаточное количество аномалий, при этом производительность базы данных, а также удобство ее использования не снижается, что нельзя сказать о всех последующих формах». Это полностью смехотворное утверждение по целому ряду факторов. Начиная с того, что нормализация вообще никак не связана с производительностью. Одни запросы она ускоряет, другие замедляет. Так я могу продолжать. Но в целом видно, что автор с терминологией знаком поверхностно и даёт слушателю сомнительные и даже ложные утверждения.

[@ЕвгенийМирошниченко-е5м]

@@ListenIT_channel Если вы говорите, что в примере "нарушена НФ", то это легко доказать. Скажите, какая НФ конкретно нарушена. После этого я процитирую вам определение этой НФ и покажу, что оно соблюдается. По сути вы не опровергли ни одно из моих высказываний, о предоставлении которых сами же мне написали. Поскольку я прав, то фразы «вы придираетесь», «у вас явно настрой придраться», это не аргументация, а переход на эмоции. Утверждения о моём якобы "настрое" никак не заменит конструктивное развенчание моих якобы "придирок".

[@KrokodiLNR]

Одно понятно - Илон Маск скорость на своей залупе в космос летать будет.

[@mms4096]

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

[@alexandrsargsyan2202]

Спасибо! Отличный материал как и его подача!