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

Поделиться
HTML-код
  • Опубликовано: 23 дек 2024

Комментарии • 144

  • @dahtes2107
    @dahtes2107 2 года назад +146

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

    • @Enigmikh
      @Enigmikh Год назад

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

    • @rsh3852
      @rsh3852 26 дней назад

      Норм

  • @privet2pizza
    @privet2pizza 10 месяцев назад +34

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

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

    • @fimdi
      @fimdi 5 месяцев назад +8

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

  • @darkcrusaderzxc
    @darkcrusaderzxc Год назад +53

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

  • @vanekonste3120
    @vanekonste3120 2 года назад +27

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

  • @tsoer2976
    @tsoer2976 Год назад +3

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

  • @takecare-q8b
    @takecare-q8b 9 месяцев назад +1

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

  • @rendi5799
    @rendi5799 Год назад +3

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

    • @ListenIT_channel
      @ListenIT_channel  Год назад

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

  • @Luv1c
    @Luv1c 2 дня назад

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

  • @armorunit6970
    @armorunit6970 Год назад +6

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

  • @MrMonMonach
    @MrMonMonach 2 месяца назад +1

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

  • @anonsd5521
    @anonsd5521 9 месяцев назад +1

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

  • @ДевятыйДан
    @ДевятыйДан Год назад +2

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

  • @Laegmerill1306
    @Laegmerill1306 2 года назад +54

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

    • @ListenIT_channel
      @ListenIT_channel  2 года назад +5

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

    • @iam21h
      @iam21h Год назад

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

    • @Laegmerill1306
      @Laegmerill1306 Год назад +22

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

    • @iam21h
      @iam21h Год назад

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

    • @ДанилДмитриев-я5м
      @ДанилДмитриев-я5м 6 месяцев назад

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

  • @gskodnik
    @gskodnik 2 года назад +27

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

    • @ListenIT_channel
      @ListenIT_channel  2 года назад +4

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

  • @KarenGarushian
    @KarenGarushian Год назад +1

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

  • @StepanVorobiov
    @StepanVorobiov Год назад +5

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

  • @TheSeko786
    @TheSeko786 Год назад +1

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

  • @N5O1
    @N5O1 Год назад

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

  • @BellCranel-c3p
    @BellCranel-c3p 6 месяцев назад +1

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

    • @ListenIT_channel
      @ListenIT_channel  6 месяцев назад

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

  • @illusionsoftworks7866
    @illusionsoftworks7866 4 месяца назад

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

  • @zakarmoy
    @zakarmoy 2 года назад +10

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

    • @ListenIT_channel
      @ListenIT_channel  2 года назад +2

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

  • @ИльяМакаров-г1г
    @ИльяМакаров-г1г 5 месяцев назад +1

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

  • @Devivl
    @Devivl Год назад +2

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

  • @Игорь-ж9е4з
    @Игорь-ж9е4з Год назад +1

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

    • @ListenIT_channel
      @ListenIT_channel  Год назад +1

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

    • @Игорь-ж9е4з
      @Игорь-ж9е4з Год назад

      @@ListenIT_channel от души!

  • @enkifirm
    @enkifirm 2 года назад +4

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

  • @АлександрОсипов-г7е
    @АлександрОсипов-г7е 2 года назад +3

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

  • @tonybard
    @tonybard 2 года назад +2

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

  • @Комедиявдеталях
    @Комедиявдеталях Год назад +2

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

  • @elf8641
    @elf8641 Месяц назад +1

    Спасибо ❤

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

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

  • @ilikegeorgiabutiveonlybeen6705
    @ilikegeorgiabutiveonlybeen6705 2 года назад +12

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

  • @selfcreator8921
    @selfcreator8921 Год назад +1

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

  • @By-pf6bw
    @By-pf6bw 2 года назад +3

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

  • @RaptorT1V
    @RaptorT1V Год назад +3

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

    • @ListenIT_channel
      @ListenIT_channel  Год назад +1

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

  • @ЕкатеринаЗиберт-у1ю
    @ЕкатеринаЗиберт-у1ю 2 года назад +1

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

  • @artetl
    @artetl Год назад

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

  • @malinam785
    @malinam785 Месяц назад

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

    • @ListenIT_channel
      @ListenIT_channel  Месяц назад +1

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

  • @НастяГераськина-м5я
    @НастяГераськина-м5я 7 месяцев назад +1

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

  • @constantsvariables866
    @constantsvariables866 2 года назад +3

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

  • @dariaandrukevich858
    @dariaandrukevich858 3 месяца назад +1

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

    • @ListenIT_channel
      @ListenIT_channel  3 месяца назад +1

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

  • @olzhikggg6915
    @olzhikggg6915 2 года назад +3

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

    • @ListenIT_channel
      @ListenIT_channel  2 года назад +1

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

  • @ArtemGurtikov
    @ArtemGurtikov 5 месяцев назад +1

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

    • @ListenIT_channel
      @ListenIT_channel  5 месяцев назад

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

  • @MrCursedsin
    @MrCursedsin 2 года назад +1

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

  • @bulatnikoffdmitrii4438
    @bulatnikoffdmitrii4438 Год назад +2

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

  • @meepo1020
    @meepo1020 2 года назад +1

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

  • @johnb7657
    @johnb7657 7 месяцев назад +1

    Благодарю

  • @artemky3bmu45
    @artemky3bmu45 Год назад +1

    Спасибо!!

  • @AM-pd9dj
    @AM-pd9dj 2 года назад +5

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

    • @niceandquickly
      @niceandquickly 2 года назад +5

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

  • @KrokodiLNR
    @KrokodiLNR 2 года назад +2

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

  • @Aurelius1221
    @Aurelius1221 2 года назад +1

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

    • @ListenIT_channel
      @ListenIT_channel  2 года назад +2

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

  • @Miko-pe6oe
    @Miko-pe6oe 9 месяцев назад

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

  • @maxamly
    @maxamly Год назад +2

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

  • @alexandrsargsyan2202
    @alexandrsargsyan2202 2 года назад +1

    все круто !!!

  • @bunta8789
    @bunta8789 4 месяца назад

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

  • @olzhikggg6915
    @olzhikggg6915 2 года назад +3

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

  • @Vic-o2h
    @Vic-o2h 5 месяцев назад

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

  • @alexeysavitski5005
    @alexeysavitski5005 2 года назад +9

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

  • @N5O1
    @N5O1 Год назад +3

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

    • @Ролтун
      @Ролтун Год назад

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

  • @sergpil7534
    @sergpil7534 2 года назад +6

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

  • @Bibliophilos
    @Bibliophilos Год назад

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

  • @saitama-s9w
    @saitama-s9w Год назад +1

    graet,thanks.)😎😎😎😎

  • @0imax
    @0imax 10 месяцев назад

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

  • @МиколаМельник-ж1м
    @МиколаМельник-ж1м 5 месяцев назад

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

  • @N5O1
    @N5O1 Год назад

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

  • @roboheat752
    @roboheat752 Год назад

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

  • @indigolight6007
    @indigolight6007 24 дня назад

    ruclips.net/video/zqQxWdTpSIA/видео.html но ведь должность зависит от фио а не от табельного номера. значит должна быть еще одна таблица - должности. и передавать также вторичный ключ как и подразделение. или в таблице сотрудники добавить айдинишники, которые будут ключом,
    хотя и в этом случае придется должность выносить в отдельную таблицу так как не будет соответствовать второй нормальной форме

  • @vlad-bruce
    @vlad-bruce 5 месяцев назад

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

  • @N5O1
    @N5O1 Год назад

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

    • @ListenIT_channel
      @ListenIT_channel  Год назад +1

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

    • @N5O1
      @N5O1 Год назад

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

    • @ListenIT_channel
      @ListenIT_channel  Год назад

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

  • @MrSatan662
    @MrSatan662 Год назад +2

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

  • @amwake7810
    @amwake7810 6 месяцев назад

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

  • @rockstation768
    @rockstation768 Год назад

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

  • @dchenk
    @dchenk Год назад

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

  • @isop7547
    @isop7547 13 дней назад

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

  • @MrMonMonach
    @MrMonMonach 2 месяца назад

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

  • @СергейИгнатов-ф6у
    @СергейИгнатов-ф6у 4 месяца назад

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

  • @N5O1
    @N5O1 Год назад

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

    • @ListenIT_channel
      @ListenIT_channel  Год назад

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

  • @FISI_Deutschland
    @FISI_Deutschland Год назад

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

    • @ListenIT_channel
      @ListenIT_channel  Год назад +2

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

    • @FISI_Deutschland
      @FISI_Deutschland Год назад

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

  • @useragent000
    @useragent000 Год назад

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

  • @mikhail8376
    @mikhail8376 10 месяцев назад

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

  • @MacxaD
    @MacxaD Год назад

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

  • @itdev4680
    @itdev4680 10 месяцев назад

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

  • @Bfiabecksjbdicbsjzkkxnsh
    @Bfiabecksjbdicbsjzkkxnsh Год назад

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

  • @N5O1
    @N5O1 Год назад

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

    • @ListenIT_channel
      @ListenIT_channel  Год назад

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

  • @black_sea99
    @black_sea99 Год назад

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

    • @furybarzha
      @furybarzha Год назад

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

  • @РустамРаджабов-ц3м
    @РустамРаджабов-ц3м 8 месяцев назад

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

    • @ListenIT_channel
      @ListenIT_channel  8 месяцев назад +1

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

  • @kiryajan
    @kiryajan 10 месяцев назад

    🔥

  • @DanielLenskiy
    @DanielLenskiy Год назад

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

  • @vesterertesterer2459
    @vesterertesterer2459 7 месяцев назад

    16:23

  • @alexandrsargsyan2202
    @alexandrsargsyan2202 2 года назад +2

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

  • @otahjuelasso130
    @otahjuelasso130 5 месяцев назад

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

    • @dreamingMary
      @dreamingMary 4 месяца назад

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

    • @otahjuelasso130
      @otahjuelasso130 4 месяца назад

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

  • @ordossanktorum
    @ordossanktorum Год назад

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

  • @nikolay4362
    @nikolay4362 Год назад +1

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

    • @ListenIT_channel
      @ListenIT_channel  Год назад +1

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

    • @ktoeto8094
      @ktoeto8094 6 месяцев назад

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

  • @KrazyHell
    @KrazyHell Год назад

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

  • @hellhound4138
    @hellhound4138 Год назад

    аьоьа

  • @ЕвгенийМирошниченко-е5м
    @ЕвгенийМирошниченко-е5м 4 месяца назад +1

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

    • @ListenIT_channel
      @ListenIT_channel  3 месяца назад

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

    • @ЕвгенийМирошниченко-е5м
      @ЕвгенийМирошниченко-е5м 3 месяца назад +1

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

    • @ListenIT_channel
      @ListenIT_channel  3 месяца назад

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

    • @ЕвгенийМирошниченко-е5м
      @ЕвгенийМирошниченко-е5м 3 месяца назад +1

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

    • @ЕвгенийМирошниченко-е5м
      @ЕвгенийМирошниченко-е5м 3 месяца назад +1

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

  • @KrokodiLNR
    @KrokodiLNR 2 года назад

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

  • @mms4096
    @mms4096 2 года назад +1

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

  • @alexandrsargsyan2202
    @alexandrsargsyan2202 2 года назад +2

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

  • @alexandrsargsyan2202
    @alexandrsargsyan2202 2 года назад +2

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