По моему в примере на 1:39 потенциальных ключей все-таки 2: (project_id, task), (project_id, responsible). На 0:54 упрощенное утверждение: "ключевые атрибуты не должны зависеть от неключевых". И как-то не особо пример ложится на это упрощение, так как оно всегда истинно, так как неключевых атрибутов попросту нет в примере))). Следовательно согласно упрощенной формулировке таблица уже в BCNF. А вот если выписать минимальное множество функциональных зависимостей для этого же примера: 1fd: responsible -> task 2fd: (project_id, task) -> responsible 3fd: (project_id, responsible) -> task то увидим, что в 1fd - детерминантом будет responsible, который не является потенциальным ключом, и поэтому полноценному определению BCNF таблица уже не соответствует. Поэтому упрощённая формулировка урезает смысл значительно. Тогда уж так: 3NF и ключевые атрибуты не должны зависеть от любых зависимостей кроме потенциальных ключей.
@2:37 поясните пж, после декомпозиции в левой таблице имеются дублирующиеся строки с id=3, id=4, получается она не находится в 1-2 НФ, значит не находится и в 3НФ, и в НФБК? Также, правая таблица не имеет первичного ключа (project_id повторяются).
Два Ильи-то это ладно. Тёзки просто. А вот декомпозиция в НФБК привела к нарушению условия задачи, т.к. теперь к одному проекту можно добавить двух кураторов с одинаковыми направлениями.
Какая-то неточность на декомпозиции НФБК. почему связка Илья-Дизайн встречается 2 раза под разными id в таблице workers? И похоже, что в таблице workers тоже надо сделать декомпозицию, чтобы у каждого skill был свой id?
Спасибо, материал супер! Подскажите, я правильно понимаю, что на 2:33 строка id=4 таблицы workers избыточная? Второй вопрос - для 5НФ. Правильно ли, что три атрибуты могут быть связаны двумя отношениями, а третье отношение в 5НФ является ограничивающим для будущих добавлений и избыточным для текущего состояния таблицы. Иными словами таблицу из примера 5НФ можно восстановить по двум из трех таблиц после декомпазиции?
в третьей задаче есть небольшая ошибка в исходной таблице: у одного и того же дома не может быть разная этажность (если, конечно же, не имелась ввиду этажность квартиры, что маловероятно при значениях 8 и 10)
есть одна проблемка, называется расходы на композицию. обращения к базе могут начать загибаться из за избыточного количества джоинов. крч с декомпозицией главное не переусердствовать
Т.е. таблица может быть или не быть в 5НФ? Если Мишу в общую таблицу прописали как бека, то при декомпозиции - он потеряется(в этом смысл?) из-за нетривиальной зависимости по которой он может быть только фронтом? Или 5НФ - это приведение к декомпозированным таблицам? Предположим, Мишу НЕ заставляют писать бек, исходная таблица находится в 5НФ? Тогда почему по Гене, 5НФ - это устранение нетривиальных зависимостей, ведь они остались в таблице(Миша по прежнему только фронт). Или Гена не того чифирнул и имел в виду, что устраняются нарушения нетривиальных зависимостей?
@@Rclass А если у него будет 50 проектов придется хранить 50 одинаковых Илья-Дизайн? Противоречит определению Нормализации (Нормализация удаление избыточности данных)
2НФ: Если атрибут НЕКЛЮЧЕВОЙ, то он зависит только от каждого потенциального ключа ЦЕЛИКОМ. А в НФБК дополнительно рассматривается зависимость КЛЮЧЕВОГО (части потенциального ключа) от НЕ потенциального ключа. Последняя проявляется, когда ты нормализовал до 3NF включительно, но у тебя остались несколько разных потенциальных ключей из нескольких атрибутов ИЛИ эти разные потенциальные ключи пересекаются по атрибутам. В 3NF допустима зависимость A → B, где B - атрибут потенциального ключа, а A - НЕ потенциальный ключ. А НФБК такое принуждает нормализовать.
Не понимаю, блин, 2:50, так же ведь по имени в таблице воркерс можно определить скилл, то есть неключевой снова по неключевому можно идентифицировать, с чего это НФБК ? Столько видосов посмотрел, везде одно и то же, не могу понять, что я пропустил и не так понял... А если ключевой составной (id + name), то это даже не вторая. А вообще, разве не может быть двух имён с разным скиллом (два разных сотрудника)? Как пример подобный понимать...
думаю, у Вас непонимание из-за неточной вольной переформулировки НФБК в видео. рекомендую разобраться детально в оригинальной формулировке НФБК, в ней ничего лишнего, она сто раз продумана математиками и логиками, и как следствие однозначно понимаема, если освоить все понятия входящие в определение. там речь идет об идентификации только потенциальным ключом, а не его подмножеством(как сказано в видео).
Гена просто чёткий поцан ! Внатуре, пришёл значит и разложил чётенько всё и всем. Респект авторам.
Спасибо, мы старались)
По моему в примере на 1:39 потенциальных ключей все-таки 2:
(project_id, task), (project_id, responsible).
На 0:54 упрощенное утверждение: "ключевые атрибуты не должны зависеть от неключевых". И как-то не особо пример ложится на это упрощение, так как оно всегда истинно, так как неключевых атрибутов попросту нет в примере))). Следовательно согласно упрощенной формулировке таблица уже в BCNF.
А вот если выписать минимальное множество функциональных зависимостей для этого же примера:
1fd: responsible -> task
2fd: (project_id, task) -> responsible
3fd: (project_id, responsible) -> task
то увидим, что в 1fd - детерминантом будет responsible, который не является потенциальным ключом, и поэтому полноценному определению BCNF таблица уже не соответствует. Поэтому упрощённая формулировка урезает смысл значительно. Тогда уж так: 3NF и ключевые атрибуты не должны зависеть от любых зависимостей кроме потенциальных ключей.
Жги дальше. Всегда полезно вспомнить основы
Класс! Чётко! Умеете, могёте. Гене привет
Спасибо, мы старались :)
Очень нравятся Ваши видео❤️🙏🏻Спасибо
Вам спасибо что смотрите :)
и ни одного коммента про футболку Asking Alexandria) йеее рок
Еееее!
Очень информативно. Спасибо большое!
Смотрю перед экзаменом, спасибо! P.S Asking Alexandria - зачёт ❤
Удачи)
@2:37 поясните пж, после декомпозиции в левой таблице имеются дублирующиеся строки с id=3, id=4, получается она не находится в 1-2 НФ, значит не находится и в 3НФ, и в НФБК? Также, правая таблица не имеет первичного ключа (project_id повторяются).
просто огромное спасибо, статьи хабра читать невозможно! а это прям супер, Гена топ
Спасибо, мы старались :)
Гена красавчик как есть показывает🤣
Спасибо, мы старались :)
Очень хорошо объяснил. Огромное спасибо !
Спасибо, мы старались! ^_^
Спасибо, очень доходчиво!
Невероятно доступно, спасибо
Спасибо большое :)
Я когда учился вообще сложно было. Но тогда во времена диал ап модемов ютуба не было (
Интернет ночами по карточкам... Помним-помним)
Презентация 🔥🔥🔥
Спасибо, мы старались ^_^
Два Ильи-то это ладно. Тёзки просто.
А вот декомпозиция в НФБК привела к нарушению условия задачи, т.к. теперь к одному проекту можно добавить двух кураторов с одинаковыми направлениями.
Какая-то неточность на декомпозиции НФБК. почему связка Илья-Дизайн встречается 2 раза под разными id в таблице workers? И похоже, что в таблице workers тоже надо сделать декомпозицию, чтобы у каждого skill был свой id?
Это просто два разных Ильи )
Очень полезно и мемасики хорошие ))
великолепное объяснение материала
Спасибо большое :)
Спасибо, материал супер! Подскажите, я правильно понимаю, что на 2:33 строка id=4 таблицы workers избыточная?
Второй вопрос - для 5НФ. Правильно ли, что три атрибуты могут быть связаны двумя отношениями, а третье отношение в 5НФ является ограничивающим для будущих добавлений и избыточным для текущего состояния таблицы. Иными словами таблицу из примера 5НФ можно восстановить по двум из трех таблиц после декомпазиции?
Спасибо, все очень доступно и понятно!
Благодарим) Всё для вас :)
Друзья, очень крутые видео! Есть возможность добавить блок с ответами для самопроверки? Это был бы своего рода уникальный материал
Хм. Отличная идея. Почему мы сами не догадались? :) Попробуем организовать.
Почему на 2:55 Илья в таблице workers дублируется? Фича или ошибка?
БАГ! Однозначно)
Для 4-й нормальной формы пример таблицы, конечно, максимально суррогатный :)
Правильно я понял, чтобы привести к любой нормальной форме нужно провести декомпозицию или разделить таблицу на две таблицы?
Чаще всего да, но не всегда. У вас уже может быть 2 таблицы, но один из столбцов может быть не там, например.
в третьей задаче есть небольшая ошибка в исходной таблице: у одного и того же дома не может быть разная этажность (если, конечно же, не имелась ввиду этажность квартиры, что маловероятно при значениях 8 и 10)
Спасибо за отклик) Мы немного упростили реальный мир для данной задачи ^_^
есть одна проблемка, называется расходы на композицию.
обращения к базе могут начать загибаться из за избыточного количества джоинов. крч с декомпозицией главное не переусердствовать
Да, поэтому нужно всегда понимать что ты делаешь и грамотно рассчитывать нагрузку :)
Спасибо все понятно
Спасибо, мы старались :)
Лайк за Гену
Спасибо, мы старались! :)
Т.е. таблица может быть или не быть в 5НФ? Если Мишу в общую таблицу прописали как бека, то при декомпозиции - он потеряется(в этом смысл?) из-за нетривиальной зависимости по которой он может быть только фронтом? Или 5НФ - это приведение к декомпозированным таблицам? Предположим, Мишу НЕ заставляют писать бек, исходная таблица находится в 5НФ? Тогда почему по Гене, 5НФ - это устранение нетривиальных зависимостей, ведь они остались в таблице(Миша по прежнему только фронт). Или Гена не того чифирнул и имел в виду, что устраняются нарушения нетривиальных зависимостей?
Так стоп, почем в нфбк в таблице рабочие илья дважды записан, хотя скилл один???
Илья у нас один, и скилл один, а проекты разные :)
@@Rclass А если у него будет 50 проектов придется хранить 50 одинаковых Илья-Дизайн? Противоречит определению Нормализации (Нормализация
удаление избыточности данных)
@@mrlait5732 вы про 3:04, например? Там ошибка, да, Илья должен быть один раз указан, всё верно :)
@@Rclass Спасибо, кста за ролики) Выборочно пересматриваю правила нормализации
@@mrlait5732 вам спасибо, что подмечаете баги в роликах ^_^
Спасибо
Стараемся :)
Спасибо. Гене, тоже.
Гене как всегда отдельное спасибо) А вам спасибо что смотрите :)
вообще не понимаю, чем третья усиленная форма отличается от второй, если что там, что там, мы вводим таблицу связей
2НФ: Если атрибут НЕКЛЮЧЕВОЙ, то он зависит только от каждого потенциального ключа ЦЕЛИКОМ.
А в НФБК дополнительно рассматривается зависимость КЛЮЧЕВОГО (части потенциального ключа) от НЕ потенциального ключа.
Последняя проявляется, когда ты нормализовал до 3NF включительно, но у тебя остались несколько разных потенциальных ключей из нескольких атрибутов ИЛИ эти разные потенциальные ключи пересекаются по атрибутам. В 3NF допустима зависимость A → B, где B - атрибут потенциального ключа, а A - НЕ потенциальный ключ. А НФБК такое принуждает нормализовать.
Не понимаю, блин, 2:50, так же ведь по имени в таблице воркерс можно определить скилл, то есть неключевой снова по неключевому можно идентифицировать, с чего это НФБК ?
Столько видосов посмотрел, везде одно и то же, не могу понять, что я пропустил и не так понял...
А если ключевой составной (id + name), то это даже не вторая.
А вообще, разве не может быть двух имён с разным скиллом (два разных сотрудника)? Как пример подобный понимать...
думаю, у Вас непонимание из-за неточной вольной переформулировки НФБК в видео. рекомендую разобраться детально в оригинальной формулировке НФБК, в ней ничего лишнего, она сто раз продумана математиками и логиками, и как следствие однозначно понимаема, если освоить все понятия входящие в определение.
там речь идет об идентификации только потенциальным ключом, а не его подмножеством(как сказано в видео).
и как теперь без Гены другие НФ понимать?
Мы задумаемся)
чуть не забыл поставить LIKE
Спасибо :)