Нормальные формы базы данных. Три нормальных формы, нормализация и денормализация БД

Вообще нормальных форм 6.
Не считая 3НФБК = 3,5

Здорово! Спасибо! картинка очень приятная, все понятно, очень приятно слушать!

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

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

Thank you for video🔥🔥🔥

"атрибуты - поля таблицы" поле - жто вроде ячейка, а не колонка, а атрибут - колонка/графа
3.40

Что-то я не понял, как первичным ключом может быть owner_id в таблице телефонов, когда РК должен быть уникальным, а там он очевидно повторяется? (11 мин 15 сек)

Спасибо огромное за внятное объяснение!!!

спасибо!

Спасибо за краткость и доходчивость. Все правильно. Важно понимать материал, а не зубрить его.

Первичный ключ разве не должен быть уникален ? При разборе 2 НФ owner_id имеет два строки с одинаковым значение. Такое может быть ? Заранее благодарю за ответ!

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

спасибо!
кратко и информативно)

Спасибо

Спасибо большое!

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

Вынос операционной системы в отдельную таблицу даёт нам уникальную запись операционной системы. И это относится к нормализации. И да, надо делать join. Но если оставить ОС в виде слова в каждой записи, как было предложено, то появляется ненормализованное хранение названия ОС. Представьте что завтра возникла необходимость переименовать ОС. Вам придётся изменить все записи, где используется эта ОС. Что очень не оптимально. Другое вопрос что в случае высокой нагрузки на чтение этих данных можно намеренно пойти на такую денормализацию, чтобы избежать join операций

На основе прочитанных статей, книг у меня сложилось мнение о НФ, немного отличающееся от вашего:
1НФ - добавить то, что строки и столбцы неупорядочены. Не стоит ожидать, что при одном и том же SELECT-е порядок строк будет один и тот же.
2НФ - неключевые элементы могут зависеть или от первичного ключа (а если он составной, то ключа целиком) или от других неключевых элементов, которые в свою очередь прямо или опосредованно зависят от первичного ключа.
3НФ - строже, чем вторая: неключевые элементы могут зависеть только от первичного ключа.

Леша, Лёха, Алексей! Опять добро делаешь! Спасибо! Полезно и очень интересно смотреть такие видео!

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

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

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

phone1, phone2 - также допустимо и не нарушает первую нормальную форму
это возможно коробит взгляд
но формально не нарушает

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

Офигеть ❤ доступным языком объяснил, спасибо

Такой вопрос:

Рассмотрим в примере второй нормальной формы уже после декомпозиции таблицу справа со столбцами (owner_id, phone). Разве она не противоречит второй нормальной форме? В этой таблице же нет первичного ключа.

Прикольно 😊
Очень просто и понятно. Спасибо за объяснение. Пришёл ко всему этому собственным опытом, но здесь всё объяснено словами и почему-то не приходило в голову, что по БД есть теория и систематизация. Надо будет почитать 😅

Не стало яснее...

Как всегда замечательно, объяснил на примере за 15 минут то, что до нас препод за целый курс не донёс

По первой нормальной форме. Я бы вынес названия осей в отдельную таблицу. Нас когда учили, были 90е-начало 2000х. У нас как раз начинали угорать по всяким переименованиям улиц-сел-городов-оргпгизаций и тому подобное. Так вот, препод говорил, что прикинь, если ты китаец, тебя 2 миллиарда, в стране миллион населенных пунктов... Что будет если правительство решит переименовать все населенные пункты? Всегда надо брать наихудший вариант развития событий. Так вот, что проще: поменять содержимое миллиона записей в таблице с названиями городов-сел-поселков, или менять содержимое 2 миллиардов записей? Лучше подумать 5 лишних минут над джойном, чем потом рвать пятую точку с изменениями данных

Здравствуйте! А ваш курс на Stepik больше недоступен? На него можно как-то записаться или нужно ждать обновлённую версию?

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

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

Есть IDE с названием Pydroid, это один из множества примеров почему Пайтон лучше не называть Питоном

Алексей, в третьей нормальной форме в таблице phone, os не хватает телефона Samsung s22.

1. Должны быть первичные ключи
2. Должны быть внешние ключи
3. Нельзя хранить агрегаты в таблицах

Дальше здравый смысл должен работать

Наконец-то серьёзные темы пошли (без сарказма) 😊

Ох... Вот "войти в ит" наслушаются и потом на "голубом глазу" на собесах рассказывают, что индексы хранят в себе данные 🤦‍♀️

super

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

Грамотно объясняете, спасибо!

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

То есть и то, и то НФ, но разбиение таблицы - изменение структуры уже нормальной формы?

А куда делся Samsung S22 после приведения 3-й формы?

Ммм, вы перешли на Нойман (я про микрофон) 💪 моё почтение. Тогда уже добавьте к нему ламповый предвак, а потом уже на карту, ну что б совсем сладкий звук был 👍

не понял отличия 2-ой формы и 3-й, если честно

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

2 и 3 формы не понял

По моему, примеры таблиц не очень удачные. Иначе получается, для добавления ОС, нужно сначала добавить телефон. Голый SQL он конечно занятный, но для нормальной работы всё таки хочется всегда сверху иметь какую нибудь предметно ориентированную модель в виде контактов, лидов, сделок, а не таблиц.

Когда там рум тур?)