Введение в реляционные базы данных и нормальные формы 1. База данных - это любой набор данных, который можно хранить и управлять. 2. Реляционная модель - это структура для организации и хранения данных, где информация представляется в виде отношений (таблиц). 2.1 Отношения - таблицы, состоящие из множества записей (строк), каждая из которых состоит из атрибутов (столбцов). Описание: Каждая строка в таблице можно рассматривать как элемент отношения, а атрибуты определяют характеристики этих элементов. 2.2 Кортежи - это строки таблицы (записи). Описание: Упорядоченная коллекция (набор) элементов, соответствующих атрибутам таблицы. Порядок имеет значение, так как он соответствует структуре таблицы и представляет отдельные записи, связанные с сущностями (например, конкретный клиент или товар). 2.3 Атрибуты - это поля таблицы (столбцы). Описание: Атрибуты описывают свойства или характеристики записей (сущностей). Они могут быть разных типов. Например, у клиента могут быть атрибуты: имя, адрес, возраст, вес. 3. Реляционная база данных - это упорядоченная информация, связанная между собой определенными отношениями. Такие базы данных состоят из таблиц, в которых и содержится вся информация. 4. Связь между данными Описание: Отношение также описывает связь между данными. Например, в таблице "Клиенты" могут храниться данные о клиентах, а в таблице "Заказы" - информация о заказах этих клиентов. Связи между таблицами (например, через первичные и внешние ключи) позволяют связывать данные и обеспечивать целостность. 5. Основные понятия 5.1 Избыточность данных - это ситуация, когда одни и те же данные хранятся в нескольких местах, что приводит к аномалиям, требующим обновления или удаления одинаковых данных в нескольких местах. 5.2 Нормальная форма базы данных - это набор правил и критериев, которым должна отвечать база данных, чтобы избежать избыточности и аномалий. 5.3 Нормализация - это последовательный процесс приведения базы данных к нормальным формам, начиная с ненормализованной формы (UNF) и переходя к более высоким нормальным формам. Процесс: Удаление избыточных данных. Устранение аномалий. Повышение производительности. Повышение удобства управления
Большое спасибо, пришлось самому учиться проектированию приложений и моделей данных для них. У Вас черпаю очень много полезной информации, спасибо большое за Ваш труд!
На основе прочитанных статей, книг у меня сложилось мнение о НФ, немного отличающееся от вашего: 1НФ - добавить то, что строки и столбцы неупорядочены. Не стоит ожидать, что при одном и том же SELECT-е порядок строк будет один и тот же. 2НФ - неключевые элементы могут зависеть или от первичного ключа (а если он составной, то ключа целиком) или от других неключевых элементов, которые в свою очередь прямо или опосредованно зависят от первичного ключа. 3НФ - строже, чем вторая: неключевые элементы могут зависеть только от первичного ключа.
Нормальные формы 0NF Нулевая нормальная форма (ненормализованная форма) Цель: Определить начальную структуру данных. Действие: Собрать (Записывать) данные без соблюдения реляционных принципов, не структурируя их в таблицы. 1NF (Первая нормальная форма) Цель: Устранить дублирование строк и обеспечить атомарность данных. Действие: Заполнить все атрибуты, чтобы они содержали только одно атомарное значение без повторяющихся атрибутов. Последовательность: 1. Разделить составные значения на отдельные атрибуты. 2. Убедиться, что в каждом атрибуте содержится только одно значение (атомарность). 3. Удалить повторяющиеся атрибуты с одинаковым смыслом. Результат: - нет дублирующихся строк - все атрибуты атомарны (содержат одно не составное значение) - нет повторяющихся атрибутов с одинаковым смыслом 2NF (Вторая нормальная форма) Цель: Устранить частичные зависимости от первичного ключа. Центр внимания: Первичный ключ (Полная функциональная зависимость от PK) Действие: Разделить таблицы так, чтобы каждый неключевой атрибут зависел от всего первичного ключа, исключив зависимости от его частей. Последовательность: 1. Определить составные ключи в таблице. 2. Убедиться, что все неключевые атрибуты зависят от всего составного ключа, а не от его части. 3. Разделить таблицы, если неключевые атрибуты зависят только от части ключа. Результат: - отношение находится в первой нормальной форме - есть первичный ключ - все неключевые атрибуты функционально зависят от первичного (PK) ключа целиком, а не от его части Ключ: Столбец или набор столбцов, по которым гарантировано можно отличить строки друг от друга. Содержит уникальное значение. Пример: В таблице с атрибутами (ID_студента, Курс, Имя_студента), где (ID_студента, Курс) является составным первичным ключом, имя студента должно зависеть от всего ключа (ID_студента, Курс), а не только от ID_студента. 3NF (Третья нормальная форма) Цель: Устранить транзитивные зависимости между неключевыми атрибутами. Центр внимания: Прямые зависимости от PK Действие: Устранить транзитивные зависимости, гарантируя, что каждый неключевой атрибут зависит только от первичного ключа, без влияния других неключевых атрибутов. Последовательность: 1. Проверить зависимости между неключевыми атрибутами. 2. Определить, имеются ли транзитивные зависимости (неключевые атрибуты, зависящие от других неключевых атрибутов). 3. Разделить таблицы, чтобы убрать транзитивные зависимости, перенесенные в новые таблицы. Результат: - отношение находится во второй нормальной форме - Неключевые атрибуты напрямую зависят только от первичного ключа и не имеют зависимостей от других атрибутов (отсутсвие транзитивной зависимости). Транзитивная зависимость: Зависимость неключевых столбцов от значений других неключевых столбцов. Исключение транзитивной зависимости: Производится путем декомпозиции - разнесением атрибутов в разные таблицы. Пример: Если в таблице есть (ID_студента, Курс, Имя_студента, Адрес_преподавателя), и Адрес_преподавателя зависит от Курс, то это транзитивная зависимость. Чтобы перейти в 3NF, нужно разделить данные на две таблицы.
Нормальная форма - это здравый смысл. Пытливый ум не увидет тут ответа на вопрос что такое нормализация баз данных. Нормализация делается для того чтобы не хранить в базе дублирующиеся данные. Если нам нужно хранить название операционной системы, то желательно хранить его в одной записи. А все остальные таблицы по хорошему должны иметь ссылку на эту запись. И таким образом все правила нормализации направлены именно на уменьшение размеров хранимых данных. Взглянув на таблицу можно сразу понять, нормализованные в ней данные хранятся или нет. Если мы видим повторяющиеся значения (например названия чего либо), то сразу можем сделать вывод, что данные не нормализованные.
Интересно было бы послушать на счет Нормальных Форм после 4, ибо, зачастую, они редко используются, потому что основная цель НФ - найти золотую середину скорости обращения к необходимым экземплярам записи БД и исключить аномалии, что достигается до 4 НФ, а последующие - загадка. Какие плюсы и минусы использования НФ с 5 по 6? Отрасли, в которых базы данных проектируется БД до 5-6 нормальных форм.
Мне кажется, что большинство бы предпочло чтобы Леша потратил свое драгоценное время на более нужные в разборе темы, нежели остальные НФ, вы уж извините меня))
В таких случаях хранятся нормализованные данные и на основе нормализованных генерируются денормализованные. И соответственно считаются за правду только нормализованные. Денормализованные только читаются и перезаписываются У нас такая схема
7:14 Это разделение становится полезным как только появляются атрибуты, связанные с ОС. Например компанию, разрабатывающую ОС, или какие-то её доп. свойства.
@@t0digital Для варианта с искусственным (суррогатным) первичным ключом ограничение предметной области можно не вводить. Но! Если это ограничение существует объективно (например, в фирме есть правило, запрещающее в одном и том же отделе на одной и той же должности работать людям с одинаковыми ФИО), нам придётся создать уникальный индекс на полях фамилия, позиция и отдел. Поэтому думаю, что для текущего примера - действительно странно вводить суррогатные ключи, можно ведь напротив каждого телефона указать его ось. Но я бы скорей сделал уточнение мол декомпозиция в следующих (2, 3 и тд) нормальных формах это адекватные вещи, а здесь она действительно избыточна. Верно же?
Когда-то давно (4-5 лет назад) в бауманке пропустил первую пару на кафедре по БД, потом долго догонял за их устройство очень)) И за нормальные формы и схемы БД очень жёстко всех спрашивали на экзамене, не всегда понимал тогда правила форм, особенно Бойса-Кодда, но путём применения здравого, как раз-таки, смысла догонять материал был легче. А так штука действительно полезная.
Прикольно 😊 Очень просто и понятно. Спасибо за объяснение. Пришёл ко всему этому собственным опытом, но здесь всё объяснено словами и почему-то не приходило в голову, что по БД есть теория и систематизация. Надо будет почитать 😅
Все так, только если все равно нужно будет джоинить лучше джоинить по serial id и его указывать внешним ключом, а не текстовые данные тем самым сократив размер базы и время джоина
9:00 Из какого источника взято требование для 2-НФ - "есть первичный ключ"? Википедия со ссылой на Кода говорит "Put simply, a relation is in 2NF if it is in 1NF and every non-prime attribute of the relation is dependent on the whole of every candidate key."
@@АртурЗарипов-ю9п в видео явно прозвучало, что owner_id есть первичный ключ (11:11). Также прозвучало, что это поле автоинкрементальное. В общем, объяснение понятно, но с картинкой не согласуется. И это запутывает
Запутанно да. Соглашусь. Но Алексей, наверное, имел в виду у таблички "owners" (которой там вообще на скрине нет, но он как бы ее имел в виду), owner id это первичный ключ. Так видимо он мыслил.
Вынос операционной системы в отдельную таблицу даёт нам уникальную запись операционной системы. И это относится к нормализации. И да, надо делать join. Но если оставить ОС в виде слова в каждой записи, как было предложено, то появляется ненормализованное хранение названия ОС. Представьте что завтра возникла необходимость переименовать ОС. Вам придётся изменить все записи, где используется эта ОС. Что очень не оптимально. Другое вопрос что в случае высокой нагрузки на чтение этих данных можно намеренно пойти на такую денормализацию, чтобы избежать join операций
Касательно того, относится вынос в отдельную таблицу к нормализации или нет - вы спорите с автором ВУЗовского курса по СУБД, учебником по СУБД, который писался под кураторством Postgres Professional, если вам это о чём-то говорит, цитату из этого учебника я приводил в видео. В цитате было даже пояснение, почему это не нормализация
По первой нормальной форме. Я бы вынес названия осей в отдельную таблицу. Нас когда учили, были 90е-начало 2000х. У нас как раз начинали угорать по всяким переименованиям улиц-сел-городов-оргпгизаций и тому подобное. Так вот, препод говорил, что прикинь, если ты китаец, тебя 2 миллиарда, в стране миллион населенных пунктов... Что будет если правительство решит переименовать все населенные пункты? Всегда надо брать наихудший вариант развития событий. Так вот, что проще: поменять содержимое миллиона записей в таблице с названиями городов-сел-поселков, или менять содержимое 2 миллиардов записей? Лучше подумать 5 лишних минут над джойном, чем потом рвать пятую точку с изменениями данных
Понятно что тут упрощённый пример для ролика, но глобально наверное было бы вернее вынести все по-максимуму в отдельные таблицы... Но это сугубо мое личное мнение
Ролик понравился , но с точки зрения памяти , разве id не лучше? . Например у нас 10 - 100 к ,записей в таблице , phons где по сути названия os дублируются , тут как поступать отдавать предпочтение pk или же название ios прописывать . Далее вопрос на счёт join , что лучше тут 1 запрос сделать с join или же два отдельных запросов , где в первом получаем id os по названию , а во втором получаем название телефонов по os_id?
В постгресе есть функция pg_column_size, которая показывает размер данных конкретного значения. pg_column_size('Android') - 8 байт pg_column_size(1::bigint) - те же 8 байт Если таблица большая, то идентификатор тоже делают bigint, не просто int. Или UUID - а это уже 16 байт. То есть строковое значение не обязательно занимает больше памяти. Во втором случае - как правило лучше сделать join, чем два запроса.
Не прийдется джоинить две таблички при поиске, так как поиск будет по ID! В любом селекте на фронте value = id_phone. И поиск будет по ID without extra joins
Знающие подскажите, если идентификаторы зависит друг от друга то это 2НФ?(пример: в таблице клиенты 10 строк и в таблице заказы, заказы не могут превышать 10). Если таблице есть два идентификатора то это 3НФ?
Привет! Спасибо за объяснение. 10:48 - я правильно понимаю, что таблица owner_id-phone будет являться 2НФ, только если первичный ключ у нас в ней составной из owner_id и phone? owner_id здесь же не может быть PK.
предполагаю автор ошибся, т.к. owner_id не уникален. А по вопросу, связка owner_i-phone может повторятся, кто мешает иметь одному челу два одинаковых телефона. Ну и я не встречал таблиц где все поля составляют первичный ключ.
Подобран такой себе пример для разбора второй нормальной формы. У нас имееется телефон и его владелец. Сказано, что первичныи ключом яаляется владелец, что в корне не верно поскольку у одного человека может быть несколько телефонов, то есть значения в поле владельца могут повторяться. Первичный ключ может быть и состовной, но у одного человека может быть два одинаковых телефона. Делаем вывод, что таблица не имеет первичного ключа, то есть мы имеем нарушение второй нормальной формы
пример на 6:44 не очень репрезентативный на мой взгляд. Если воспринимать этот пример "в лоб", то тут просто набор преобразований над таблицами, не меняющий форму - исходная таблица была в 1NF и получившиеся обе тоже в 1NF. Но он уж очень синтетический. Если исходная таблица обрастет дополнительными атрибутами (что на практике скорее всего и произойдет), а именно группой атрибутов связанных с описанием ОС и еще группой атрибутов с описанием телефонов, то похожее по своей сути преобразование над исходной таблицей вполне может привести её из 1NF к двум таблицам в 3NF, что уже будет называться именно нормализацией. Иными словами: разделение исходной таблицы на 2 как может быть нормализацией, так и может не быть.
Первичный ключ разве не должен быть уникален ? При разборе 2 НФ owner_id имеет два строки с одинаковым значение. Такое может быть ? Заранее благодарю за ответ!
Ммм, вы перешли на Нойман (я про микрофон) 💪 моё почтение. Тогда уже добавьте к нему ламповый предвак, а потом уже на карту, ну что б совсем сладкий звук был 👍
@@t0digital Ага, а по логотипу похож на Нойман зелёненький с трансформатором) Ну союз - да тоже хорошие микрофоны, но редкие. В целом - да, звук такой плотный. Ну и за нормализацию спасибо. Все равно бывает трудно отличить глядя на структуру "боевой" БД к какой форме она относятся. Может просто опыт большой нужен.
@@t0digital Ага, по уголку и фирменному стилю передней панели прибора)) У Михаила Лонга (лично с ним общался в том числе не на официальные темы) - огромный опыт в подобных приборах и его хвалят точно не зря )
Такой вопрос: Рассмотрим в примере второй нормальной формы уже после декомпозиции таблицу справа со столбцами (owner_id, phone). Разве она не противоречит второй нормальной форме? В этой таблице же нет первичного ключа.
А на счёт что лучше использовать в сервисе доставки или такси например, пара таблиц со множеством данных или много таблиц но распределить все данные? Люди с опытом можете подсказать?
По моему, примеры таблиц не очень удачные. Иначе получается, для добавления ОС, нужно сначала добавить телефон. Голый SQL он конечно занятный, но для нормальной работы всё таки хочется всегда сверху иметь какую нибудь предметно ориентированную модель в виде контактов, лидов, сделок, а не таблиц.
Тут надо понимать, есть ли задача работать с ОС отдельно от телефонов. Если есть, значит существует отдельная сущность ОС и её надо декомпозировать в свою таблицу
Насколько я понимаю, голым сиквелом осуществлять добавление чего либо в таблицы - это неправильно! Для этого пишут интерфейсы на процедурных языках типа PL или PLpg
@@НиколайХрипунов-щ4п да не, как правило на sql и пишут. Когда есть dba которые оч любят в pl/pgsql и оч хотят его писать, ну что-то могут написать, да
@@t0digital В моём мире ДБА ничего не пишут, у них совершенно другой функционал. Я совершенно не понимаю как и зачем совершать изменения или вставки в таблицы с ограничениями целостности на чистом сиквеле. Но я и не разработчик. Если это делать без интерфейсов, то гнусный человеческий фактор испортит жизнь ИМХО.
а зачем вообще джойнить в примере с вынесением в таблицу операционной системы? подменяя на ref id мы подменяем значение ios и назавние любоей другой ос на int которым оперируем на протяжении всего жизненного цикла
Подскажите, пожалуйста, по 3 форме. Почему мы используем Android как первичный ключ? А если потребуется, например, изменить название с Android на Android OS?
@@AlexandrZverev он не является правильным по умолчанию для всех возможных случаев, как и не является неправильным для всех возможных случаев. Вы пытаетесь упростить жизнь до единственно верного решения, это глупо.
Что-то я не понял, как первичным ключом может быть owner_id в таблице телефонов, когда РК должен быть уникальным, а там он очевидно повторяется? (11 мин 15 сек)
Как будто в примере про вторую нормальную форму есть ошибка, потому что первичный ключ - это ключ, который однозначно определяет строку и НЕ ПОВТОРЯЕТСЯ, а в примере первичный ключ (owner_id) повторяется. Я чего-то не понимаю или в видео реально допущена ошибка?
Ты про схему на 11:00? В таблице верхней ключ составной - phone и owner_id. 2 этих поля вместе уникальны. В таблице левой нижней ключ - phone. Это поле not null и уникально, а значит может быть первичным ключом. В таблице правой нижней ключ - составной, owner_id и phone.
@@t0digital я говорю про правую нижнюю таблицу. на 11:15 вы говорите, что в этой таблице первичным ключом является именно owner_id. Если первичным ключом является строка целиком, то вопросов нету (хотя странно, что строка целиком это и есть первичный ключ)
@@МаратСайфутдинов-ц7чда, я оговорился. Тут не показана таблица владельцев телефонов, там ключ будет числовой, в таблице телефонов строковый, а в связующей таблице составной из 2х колонок - числовой и строковой
@@t0digital спасибо за объяснение. может логично было бы этот момент перезаписать и перезалить ролик, раз там ошибка есть? потому что судя по комментариям не у меня одного такой вопрос возник
@@tumkir я имею в виду, что owner_id в правой таблице на 11:18 это Foreign Key на таблицу owner, в которой Primary Key это число. В самой правой таблице атрибут owner_id это не Primary Key, конечно
Я правильно понимаю, что не является нормализацией именно разбиение 1-ой нормальной формы на 2 таблицы, но разбиение в исходном варианте, когда таблица была некорректной (телефоны через запятую), является нормализацией? То есть и то, и то НФ, но разбиение таблицы - изменение структуры уже нормальной формы?
декомпозиция применяется для достижения нормальных форм. Верность декомпозиции проверяется по теореме Хеза, когда из производных таблиц должна получиться базовая через natural join, иначе она выполнена неверно. Т.е. для декомпозиции должны быть основания и она должна быть корректной.
Я начинал смотреть это видео, досмотрел до момента, где говорится о нормализации с примером, который нормализацией не является, закрыл после этого. Там автор делает видео по чужим статьям, как понял, так что претензия в первую очередь к автору статьи
8:00 если мы хотим подать данные на вход нейронки и принимаем андроид за 0, а айос за 1 - это тоже будет называться нормализацией. Но это совсем другая нормализация... Просто у людей в голове перемешиваются сведения из разных областей.
индексы - это не денормализация и реляционная модель нечего не говорит про них по этому же принципу хранение в кэше (в памяти) и в кэшах процессора тоже не денормализация хотя дублирование есть про атомарность тоже неправильно два телефона в одном поле вполне допустимо все зависит от смысла который вкладывается по сути телефон в данном случае некий комментарий но в том смысле, в котором эти телефоны используются дальше в примерах разбиение точно имеет смысл phone1, phone2 - также допустимо и не нарушает первую нормальную форму это возможно коробит взгляд но формально не нарушает по поводу двух таблиц с суррогатными идентификаторами тут опять заблуждение строго говоря реляционная модель ничего не знает про физическое хранение данных таблицы могут храниться физически "сджойненными" и написав запрос с join "физически" его не будет
Теория с вредным примером, когда утверждается что не надо разделять на две таблицы то, что на практике обязательно надо разделять на две таблицы. Здравый смысл негодует) Спасибо за напоминание о базовых знаниях по нормализации БД.
Ну давайте, аргументируете, раз уж накидываете. Конкретику только, пожалуйста, вот тут автор (я) сказал то-то, а вы считаете, что надо так-то. Чтобы без бла бла.
@@t0digital сразу скажу я не силен в этом всем, но я солидарен с коментатором. Когда была речь о первой нормальной форме, там был пример сделать таблицу «ось» как отдельную и просто через фк связывать и мол это лишний джоин и тд. Но разве это бы не исключило в то же время человеческий фактор? я делаю инсерт и пишу вместо “Android” “android” и как мне допустим фильтровать данные по «ос»? тогда сидеть делать через LIKE?) Я не истина и на нее не претендую) Просто имхо
@@ПашаКазачёнок я же говорю о нормализации в этом видео. Строковый аргумент вынести в отдельную таблицу и ссылаться на нее с суррогатным ключом это не нормализация и я об этом - некорректно такой пример называть нормализацией.
@@t0digital Я тоже порой люблю спрашивать у тех у кого вокруг все гвно. А что тогда не гвно?))) И с аргументами пожалуйста))) И Сашка Зверев сдулся))) Как я понял первый пример это разделение на две таблицы не есть нормализация. А все подробности того кто как сделал БЫ, это уже не важно. Спасибо за объяснение я теперь хоть знать буду что такое есть)))
@@t0digital Ну смотрите, сначала вы говорите, что нормализация - это здравый смысл, оформленный в определенных терминах, а затем зачем то приводите пример разделения на таблицы с числовым ключом, который абсолютно правильный и говорите что это не нормализация (хотя многие называют это нормализацией). Поэтому здравый смысл негодует, его отставили в сторонку, ради теории. Тогда лучше было бы его вообще не упоминать, или не упоминать этот пример. Ок, бла, бла, бла всё. По сути, почему пример, который не нормализация правильный: 1. Размер БД. 2. Выделение ОС отдельным объектом со своим уникальным идентификатором и свойствами. Прощайте копии с разными наименованиями одной оси, и привет удобной работе с данным объектом. 3. Числовой ключ быстрее текстового, если не вводить индексы. Почему то мне из изучения нормализации запомнились когда-то пример с числовыми ключами, может быть потому что тогда еще не было пайтона и мощных компьютеров, которые прощают любые проектные решения.
@@t0digital Признаю, это частный случай в pg. Есть частный случай в ms sql в виде included fields. Но вы же это не указывали. В общем случаи индексы не дублируют данные и хранят ссылки.
А как работает, например, btree-индекс не в pg? Как он может не хранить данные? Ссылки на таблицу там есть, конечно, но и сами данные тоже есть, в упорядоченном виде для ускорения поиска.
@@t0digital Да, конечно, сами индексируемые данные хранятся в индексе. Переслушал видео, понял, что меня тригернула фраза "избыточные данные" и неверно восприняв контекст я сморозил х...ю. Почему-то клинонуло на хранение значимых данных не являющихся индексом как в случае с включенными полями. Был не прав. Приношу извинения.
Как всегда замечательно, объяснил на примере за 15 минут то, что до нас препод за целый курс не донёс
так проблема в тебе, а не в преподавателе. Это в школе тебя учат, а в ВУЗе ты сам учишься.
@@DenisAvant выздоравливай
Ваш препод часы расстягивал!
Вышка и школа - это глобальное наебалово) то, что можно пройти за пару месяцев, растягивают на несколько лет
@@DenisAvant дружище, знаешь в чем отличие очки и заочки?
Введение в реляционные базы данных и нормальные формы
1. База данных - это любой набор данных, который можно хранить и управлять.
2. Реляционная модель - это структура для организации и хранения данных, где информация представляется в виде отношений (таблиц).
2.1 Отношения - таблицы, состоящие из множества записей (строк), каждая из которых состоит из атрибутов (столбцов).
Описание: Каждая строка в таблице можно рассматривать как элемент отношения, а атрибуты определяют характеристики этих элементов.
2.2 Кортежи - это строки таблицы (записи).
Описание: Упорядоченная коллекция (набор) элементов, соответствующих атрибутам таблицы. Порядок имеет значение, так как он соответствует структуре таблицы и представляет отдельные записи, связанные с сущностями (например, конкретный клиент или товар).
2.3 Атрибуты - это поля таблицы (столбцы).
Описание: Атрибуты описывают свойства или характеристики записей (сущностей). Они могут быть разных типов.
Например, у клиента могут быть атрибуты: имя, адрес, возраст, вес.
3. Реляционная база данных - это упорядоченная информация, связанная между собой определенными отношениями.
Такие базы данных состоят из таблиц, в которых и содержится вся информация.
4. Связь между данными
Описание: Отношение также описывает связь между данными.
Например, в таблице "Клиенты" могут храниться данные о клиентах, а в таблице "Заказы" - информация о заказах этих клиентов. Связи между таблицами (например, через первичные и внешние ключи) позволяют связывать данные и обеспечивать целостность.
5. Основные понятия
5.1 Избыточность данных - это ситуация, когда одни и те же данные хранятся в нескольких местах, что приводит к аномалиям, требующим обновления или удаления одинаковых данных в нескольких местах.
5.2 Нормальная форма базы данных - это набор правил и критериев, которым должна отвечать база данных, чтобы избежать избыточности и аномалий.
5.3 Нормализация - это последовательный процесс приведения базы данных к нормальным формам, начиная с ненормализованной формы (UNF) и переходя к более высоким нормальным формам.
Процесс:
Удаление избыточных данных.
Устранение аномалий.
Повышение производительности.
Повышение удобства управления
Теперь хочется остальные формы в таком же формате изучить)) Спасибо)
Большое спасибо, пришлось самому учиться проектированию приложений и моделей данных для них. У Вас черпаю очень много полезной информации, спасибо большое за Ваш труд!
О, отлично, рад, что полезно!
На основе прочитанных статей, книг у меня сложилось мнение о НФ, немного отличающееся от вашего:
1НФ - добавить то, что строки и столбцы неупорядочены. Не стоит ожидать, что при одном и том же SELECT-е порядок строк будет один и тот же.
2НФ - неключевые элементы могут зависеть или от первичного ключа (а если он составной, то ключа целиком) или от других неключевых элементов, которые в свою очередь прямо или опосредованно зависят от первичного ключа.
3НФ - строже, чем вторая: неключевые элементы могут зависеть только от первичного ключа.
Мне кажется он так и объяснил за исключением порядка строк в 1НФ. Впервые слышу об этом.
Леша, Лёха, Алексей! Опять добро делаешь! Спасибо! Полезно и очень интересно смотреть такие видео!
Нормальные формы
0NF Нулевая нормальная форма (ненормализованная форма)
Цель: Определить начальную структуру данных.
Действие: Собрать (Записывать) данные без соблюдения реляционных принципов, не структурируя их в таблицы.
1NF (Первая нормальная форма)
Цель: Устранить дублирование строк и обеспечить атомарность данных.
Действие: Заполнить все атрибуты, чтобы они содержали только одно атомарное значение без повторяющихся атрибутов.
Последовательность:
1. Разделить составные значения на отдельные атрибуты.
2. Убедиться, что в каждом атрибуте содержится только одно значение (атомарность).
3. Удалить повторяющиеся атрибуты с одинаковым смыслом.
Результат:
- нет дублирующихся строк
- все атрибуты атомарны (содержат одно не составное значение)
- нет повторяющихся атрибутов с одинаковым смыслом
2NF (Вторая нормальная форма)
Цель: Устранить частичные зависимости от первичного ключа.
Центр внимания: Первичный ключ (Полная функциональная зависимость от PK)
Действие: Разделить таблицы так, чтобы каждый неключевой атрибут зависел от всего первичного ключа, исключив зависимости от его частей.
Последовательность:
1. Определить составные ключи в таблице.
2. Убедиться, что все неключевые атрибуты зависят от всего составного ключа, а не от его части.
3. Разделить таблицы, если неключевые атрибуты зависят только от части ключа.
Результат:
- отношение находится в первой нормальной форме
- есть первичный ключ
- все неключевые атрибуты функционально зависят от первичного (PK) ключа целиком, а не от его части
Ключ: Столбец или набор столбцов, по которым гарантировано можно отличить строки друг от друга. Содержит уникальное значение.
Пример: В таблице с атрибутами (ID_студента, Курс, Имя_студента), где (ID_студента, Курс) является составным первичным ключом, имя студента должно зависеть от всего ключа (ID_студента, Курс), а не только от ID_студента.
3NF (Третья нормальная форма)
Цель: Устранить транзитивные зависимости между неключевыми атрибутами.
Центр внимания: Прямые зависимости от PK
Действие: Устранить транзитивные зависимости, гарантируя, что каждый неключевой атрибут зависит только от первичного ключа, без влияния других неключевых атрибутов.
Последовательность:
1. Проверить зависимости между неключевыми атрибутами.
2. Определить, имеются ли транзитивные зависимости (неключевые атрибуты, зависящие от других неключевых атрибутов).
3. Разделить таблицы, чтобы убрать транзитивные зависимости, перенесенные в новые таблицы.
Результат:
- отношение находится во второй нормальной форме
- Неключевые атрибуты напрямую зависят только от первичного ключа и не имеют зависимостей от других атрибутов (отсутсвие транзитивной зависимости).
Транзитивная зависимость: Зависимость неключевых столбцов от значений других неключевых столбцов.
Исключение транзитивной зависимости: Производится путем декомпозиции - разнесением атрибутов в разные таблицы.
Пример: Если в таблице есть (ID_студента, Курс, Имя_студента, Адрес_преподавателя), и Адрес_преподавателя зависит от Курс, то это транзитивная зависимость. Чтобы перейти в 3NF, нужно разделить данные на две таблицы.
Нормальная форма - это здравый смысл. Пытливый ум не увидет тут ответа на вопрос что такое нормализация баз данных. Нормализация делается для того чтобы не хранить в базе дублирующиеся данные. Если нам нужно хранить название операционной системы, то желательно хранить его в одной записи. А все остальные таблицы по хорошему должны иметь ссылку на эту запись. И таким образом все правила нормализации направлены именно на уменьшение размеров хранимых данных. Взглянув на таблицу можно сразу понять, нормализованные в ней данные хранятся или нет. Если мы видим повторяющиеся значения (например названия чего либо), то сразу можем сделать вывод, что данные не нормализованные.
Что ты несёшь?!
Это не так
Интересно было бы послушать на счет Нормальных Форм после 4, ибо, зачастую, они редко используются, потому что основная цель НФ - найти золотую середину скорости обращения к необходимым экземплярам записи БД и исключить аномалии, что достигается до 4 НФ, а последующие - загадка. Какие плюсы и минусы использования НФ с 5 по 6? Отрасли, в которых базы данных проектируется БД до 5-6 нормальных форм.
Мне кажется, что большинство бы предпочло чтобы Леша потратил свое драгоценное время на более нужные в разборе темы, нежели остальные НФ, вы уж извините меня))
@@baturin_m Никого не заставляю. Комментарий имеет право на существование 🙃
для того чтобы записать такое видео недостаточно будет просто вики прочитать, а надо будет хорошо так поизучать Кодда
Спасибо. Присоединяюсь к продолжению разговора о других формах и табличках
Да, а следующая ступень это как в хайлоаде делать бд) иногда там нужно положить болт на нормализацию в угоду скорости
Называется денормализация
В таких случаях хранятся нормализованные данные и на основе нормализованных генерируются денормализованные.
И соответственно считаются за правду только нормализованные. Денормализованные только читаются и перезаписываются
У нас такая схема
7:14 Это разделение становится полезным как только появляются атрибуты, связанные с ОС. Например компанию, разрабатывающую ОС, или какие-то её доп. свойства.
Да. Только PK не вводил бы суррогатный всё равно
@@t0digital А вдруг android переименуется )
@@t0digital Для варианта с искусственным (суррогатным) первичным ключом ограничение предметной области можно не вводить. Но! Если это ограничение существует объективно (например, в фирме есть правило, запрещающее в одном и том же отделе на одной и той же должности работать людям с одинаковыми ФИО), нам придётся создать уникальный индекс на полях фамилия, позиция и отдел. Поэтому думаю, что для текущего примера - действительно странно вводить суррогатные ключи, можно ведь напротив каждого телефона указать его ось. Но я бы скорей сделал уточнение мол декомпозиция в следующих (2, 3 и тд) нормальных формах это адекватные вещи, а здесь она действительно избыточна. Верно же?
@@SergeySenkin Да. В декомпозиции нет ничего плохого, просто не всегда декомпозиция одной таблицы на две это именно нормализация
Здорово! Спасибо! картинка очень приятная, все понятно, очень приятно слушать!
Спасибооо!
Наконец-то серьёзные темы пошли (без сарказма) 😊
Когда-то давно (4-5 лет назад) в бауманке пропустил первую пару на кафедре по БД, потом долго догонял за их устройство очень))
И за нормальные формы и схемы БД очень жёстко всех спрашивали на экзамене, не всегда понимал тогда правила форм, особенно Бойса-Кодда, но путём применения здравого, как раз-таки, смысла догонять материал был легче. А так штука действительно полезная.
самое понятное объяснение нормальных форм ) НО для первой формы уже нужны первичные ключи по определению формы так выходит )
Прикольно 😊
Очень просто и понятно. Спасибо за объяснение. Пришёл ко всему этому собственным опытом, но здесь всё объяснено словами и почему-то не приходило в голову, что по БД есть теория и систематизация. Надо будет почитать 😅
13:55 Samsung S22 куда-то затерялся)
Спасибо большое! Все на понятном для нас языке!
Спасибо за краткость и доходчивость. Все правильно. Важно понимать материал, а не зубрить его.
Все так, только если все равно нужно будет джоинить лучше джоинить по serial id и его указывать внешним ключом, а не текстовые данные тем самым сократив размер базы и время джоина
В очередной раз понять смысл намного проще, чем запомнить, что как называется)) И хотя важнее первое, спрашивать будут именно второе.
9:00 Из какого источника взято требование для 2-НФ - "есть первичный ключ"? Википедия со ссылой на Кода говорит "Put simply, a relation is in 2NF if it is in 1NF and every non-prime attribute of the relation is dependent on the whole of every candidate key."
Спасибо за видео! Было доступно и полезно!
Спасибо!
👌кратко !Ясно!Нет воды!👍
и рекламы
присоединюсь к другим комментариям, что хотелось бы видеть обьяснения других форм в таком же стиле)
Забавно, как часто реализуют на практике быстрое удаление данных из базы - реально не удаляются, а индексами помечаются как удаленные
Спасибо, все понятно!
Во второй табличке 11:11 разве owner_id с неуникальными значениями является первичным ключём?
Эта табличка показывает связь "один ко многим". Здесь owner id это внешний ключ. Внешний ключ может быть неуникальным.
@@АртурЗарипов-ю9п в видео явно прозвучало, что owner_id есть первичный ключ (11:11). Также прозвучало, что это поле автоинкрементальное. В общем, объяснение понятно, но с картинкой не согласуется. И это запутывает
Запутанно да. Соглашусь. Но Алексей, наверное, имел в виду у таблички "owners" (которой там вообще на скрине нет, но он как бы ее имел в виду), owner id это первичный ключ. Так видимо он мыслил.
пожалуй лучшее объяснение в интернете
Офигеть ❤ доступным языком объяснил, спасибо
Вынос операционной системы в отдельную таблицу даёт нам уникальную запись операционной системы. И это относится к нормализации. И да, надо делать join. Но если оставить ОС в виде слова в каждой записи, как было предложено, то появляется ненормализованное хранение названия ОС. Представьте что завтра возникла необходимость переименовать ОС. Вам придётся изменить все записи, где используется эта ОС. Что очень не оптимально. Другое вопрос что в случае высокой нагрузки на чтение этих данных можно намеренно пойти на такую денормализацию, чтобы избежать join операций
Касательно того, относится вынос в отдельную таблицу к нормализации или нет - вы спорите с автором ВУЗовского курса по СУБД, учебником по СУБД, который писался под кураторством Postgres Professional, если вам это о чём-то говорит, цитату из этого учебника я приводил в видео. В цитате было даже пояснение, почему это не нормализация
По первой нормальной форме. Я бы вынес названия осей в отдельную таблицу. Нас когда учили, были 90е-начало 2000х. У нас как раз начинали угорать по всяким переименованиям улиц-сел-городов-оргпгизаций и тому подобное. Так вот, препод говорил, что прикинь, если ты китаец, тебя 2 миллиарда, в стране миллион населенных пунктов... Что будет если правительство решит переименовать все населенные пункты? Всегда надо брать наихудший вариант развития событий. Так вот, что проще: поменять содержимое миллиона записей в таблице с названиями городов-сел-поселков, или менять содержимое 2 миллиардов записей? Лучше подумать 5 лишних минут над джойном, чем потом рвать пятую точку с изменениями данных
Понятно что тут упрощённый пример для ролика, но глобально наверное было бы вернее вынести все по-максимуму в отдельные таблицы... Но это сугубо мое личное мнение
ооо, флешбэки с первого курса универа))) спасибо)
спасибо!
кратко и информативно)
Классное видео! Кстати, а как твой микрофон называется?
Союз 013 fet
Здравствуйте! А ваш курс на Stepik больше недоступен? На него можно как-то записаться или нужно ждать обновлённую версию?
Нужно ждать новую версию
Спасибо огромное за внятное объяснение!!!
Ролик понравился , но с точки зрения памяти , разве id не лучше? . Например у нас 10 - 100 к ,записей в таблице , phons где по сути названия os дублируются , тут как поступать отдавать предпочтение pk или же название ios прописывать . Далее вопрос на счёт join , что лучше тут 1 запрос сделать с join или же два отдельных запросов , где в первом получаем id os по названию , а во втором получаем название телефонов по os_id?
В постгресе есть функция pg_column_size, которая показывает размер данных конкретного значения.
pg_column_size('Android') - 8 байт
pg_column_size(1::bigint) - те же 8 байт
Если таблица большая, то идентификатор тоже делают bigint, не просто int. Или UUID - а это уже 16 байт. То есть строковое значение не обязательно занимает больше памяти.
Во втором случае - как правило лучше сделать join, чем два запроса.
Когда там рум тур?)
Грамотно объясняете, спасибо!
Не прийдется джоинить две таблички при поиске, так как поиск будет по ID! В любом селекте на фронте value = id_phone. И поиск будет по ID without extra joins
Thank you for video🔥🔥🔥
Спасибо большое!
Знающие подскажите, если идентификаторы зависит друг от друга то это 2НФ?(пример: в таблице клиенты 10 строк и в таблице заказы, заказы не могут превышать 10). Если таблице есть два идентификатора то это 3НФ?
Привет! Спасибо за объяснение.
10:48 - я правильно понимаю, что таблица owner_id-phone будет являться 2НФ, только если первичный ключ у нас в ней составной из owner_id и phone? owner_id здесь же не может быть PK.
предполагаю автор ошибся, т.к. owner_id не уникален. А по вопросу, связка owner_i-phone может повторятся, кто мешает иметь одному челу два одинаковых телефона. Ну и я не встречал таблиц где все поля составляют первичный ключ.
Подобран такой себе пример для разбора второй нормальной формы. У нас имееется телефон и его владелец. Сказано, что первичныи ключом яаляется владелец, что в корне не верно поскольку у одного человека может быть несколько телефонов, то есть значения в поле владельца могут повторяться. Первичный ключ может быть и состовной, но у одного человека может быть два одинаковых телефона. Делаем вывод, что таблица не имеет первичного ключа, то есть мы имеем нарушение второй нормальной формы
согласен
"атрибуты - поля таблицы" поле - жто вроде ячейка, а не колонка, а атрибут - колонка/графа
3.40
пример на 6:44 не очень репрезентативный на мой взгляд. Если воспринимать этот пример "в лоб", то тут просто набор преобразований над таблицами, не меняющий форму - исходная таблица была в 1NF и получившиеся обе тоже в 1NF. Но он уж очень синтетический. Если исходная таблица обрастет дополнительными атрибутами (что на практике скорее всего и произойдет), а именно группой атрибутов связанных с описанием ОС и еще группой атрибутов с описанием телефонов, то похожее по своей сути преобразование над исходной таблицей вполне может привести её из 1NF к двум таблицам в 3NF, что уже будет называться именно нормализацией. Иными словами: разделение исходной таблицы на 2 как может быть нормализацией, так и может не быть.
Алексей, в третьей нормальной форме в таблице phone, os не хватает телефона Samsung s22.
Да, потерялся, Северная Корея спёрла:)
Спасибо!
Первичный ключ разве не должен быть уникален ? При разборе 2 НФ owner_id имеет два строки с одинаковым значение. Такое может быть ? Заранее благодарю за ответ!
Первичный ключ должен быть уникальным и not null, всё так
Там owner_id это не PK. Ключ надо делать или дополнительным полем, или составным из owner_id и phone, если оно уникально
@@t0digital Благодарю за ответ!
@@t0digital зачем вы тогда вводите в заблуждение - на 11 мин и 15 сек вы говорите, что owner_id это первичный ключ
Супер объяснил
Ммм, вы перешли на Нойман (я про микрофон) 💪 моё почтение. Тогда уже добавьте к нему ламповый предвак, а потом уже на карту, ну что б совсем сладкий звук был 👍
Это Союз:) идёт в аналоговый усилок (но не ламповый) и звуковуху:) но эхо бью уже на постпродакшн в изотопе, комната большая, не глушил
@@t0digital Ага, а по логотипу похож на Нойман зелёненький с трансформатором)
Ну союз - да тоже хорошие микрофоны, но редкие. В целом - да, звук такой плотный.
Ну и за нормализацию спасибо. Все равно бывает трудно отличить глядя на структуру "боевой" БД к какой форме она относятся. Может просто опыт большой нужен.
@@t0digital Ага увидел у вас в инсте Long, работал с ним - отличный предвак 👍😀
@@SergMirny_yt спасибо! По уголку определили:) Случайно на него натолкнулся и не мог не купить, больно хвалили:)
@@t0digital Ага, по уголку и фирменному стилю передней панели прибора)) У Михаила Лонга (лично с ним общался в том числе не на официальные темы) - огромный опыт в подобных приборах и его хвалят точно не зря )
Есть IDE с названием Pydroid, это один из множества примеров почему Пайтон лучше не называть Питоном
и то верно:)
Спасибо❤
Такой вопрос:
Рассмотрим в примере второй нормальной формы уже после декомпозиции таблицу справа со столбцами (owner_id, phone). Разве она не противоречит второй нормальной форме? В этой таблице же нет первичного ключа.
Вот я тоже заметил, где про 2ю нф, что в 2й таблице от owner_id не зависит фоне
А на счёт что лучше использовать в сервисе доставки или такси например, пара таблиц со множеством данных или много таблиц но распределить все данные? Люди с опытом можете подсказать?
Может быть лучше как одно, так и другое. Начать лучше с варианта множества таблиц
спасибо!
спасибо
По моему, примеры таблиц не очень удачные. Иначе получается, для добавления ОС, нужно сначала добавить телефон. Голый SQL он конечно занятный, но для нормальной работы всё таки хочется всегда сверху иметь какую нибудь предметно ориентированную модель в виде контактов, лидов, сделок, а не таблиц.
Тут надо понимать, есть ли задача работать с ОС отдельно от телефонов. Если есть, значит существует отдельная сущность ОС и её надо декомпозировать в свою таблицу
Насколько я понимаю, голым сиквелом осуществлять добавление чего либо в таблицы - это неправильно! Для этого пишут интерфейсы на процедурных языках типа PL или PLpg
@@НиколайХрипунов-щ4п да не, как правило на sql и пишут. Когда есть dba которые оч любят в pl/pgsql и оч хотят его писать, ну что-то могут написать, да
@@t0digital В моём мире ДБА ничего не пишут, у них совершенно другой функционал. Я совершенно не понимаю как и зачем совершать изменения или вставки в таблицы с ограничениями целостности на чистом сиквеле. Но я и не разработчик. Если это делать без интерфейсов, то гнусный человеческий фактор испортит жизнь ИМХО.
@@НиколайХрипунов-щ4п я работал в нескольких компаниях, в которых дба ещё как писали
А куда делся Samsung S22 после приведения 3-й формы?
Северные корейцы спёрли:)
а зачем вообще джойнить в примере с вынесением в таблицу операционной системы? подменяя на ref id мы подменяем значение ios и назавние любоей другой ос на int которым оперируем на протяжении всего жизненного цикла
Подскажите, пожалуйста, по 3 форме. Почему мы используем Android как первичный ключ? А если потребуется, например, изменить название с Android на Android OS?
Ответ есть на видео в разделе "Это не нормализация". 6:18
Ну как раз таки вариант с суррогатным ключем мне больше нравится.)
@@АртурЗарипов-ю9п да, потому что он правильный, по многим причинам.
@@AlexandrZverev он не является правильным по умолчанию для всех возможных случаев, как и не является неправильным для всех возможных случаев. Вы пытаетесь упростить жизнь до единственно верного решения, это глупо.
@@t0digital да, вы правы, глупо. Действительно, практика на однотипных учетных задачах приучила к этому шаблону, а случаи бывают разные.
Что-то я не понял, как первичным ключом может быть owner_id в таблице телефонов, когда РК должен быть уникальным, а там он очевидно повторяется? (11 мин 15 сек)
Не может быть двух Петь, но два человека могут показать на одного Петю. Тоже самое в примере
Спасибо
Как будто в примере про вторую нормальную форму есть ошибка, потому что первичный ключ - это ключ, который однозначно определяет строку и НЕ ПОВТОРЯЕТСЯ, а в примере первичный ключ (owner_id) повторяется. Я чего-то не понимаю или в видео реально допущена ошибка?
Ты про схему на 11:00?
В таблице верхней ключ составной - phone и owner_id. 2 этих поля вместе уникальны.
В таблице левой нижней ключ - phone. Это поле not null и уникально, а значит может быть первичным ключом.
В таблице правой нижней ключ - составной, owner_id и phone.
@@t0digital я говорю про правую нижнюю таблицу.
на 11:15 вы говорите, что в этой таблице первичным ключом является именно owner_id. Если первичным ключом является строка целиком, то вопросов нету (хотя странно, что строка целиком это и есть первичный ключ)
@@t0digital в общем получается вы просто оговорились?
@@МаратСайфутдинов-ц7чда, я оговорился. Тут не показана таблица владельцев телефонов, там ключ будет числовой, в таблице телефонов строковый, а в связующей таблице составной из 2х колонок - числовой и строковой
@@t0digital спасибо за объяснение. может логично было бы этот момент перезаписать и перезалить ролик, раз там ошибка есть? потому что судя по комментариям не у меня одного такой вопрос возник
11:18. А первичный ключ разве может быть не уникальным?
Название телефона уникальное поле и NOT NULL, и поэтому это PK в таблице телефона. Или вы о другом поле?
@@t0digital нет, я про слова на 11:18 именно. "Первичный ключ это owner_id"
@@tumkir я имею в виду, что owner_id в правой таблице на 11:18 это Foreign Key на таблицу owner, в которой Primary Key это число. В самой правой таблице атрибут owner_id это не Primary Key, конечно
@@t0digital ну то есть получается что во второй таблице РК нет и это просто оговорка. Кстати, первичный ключ не обязателен в этой НФ (и других)?
Я правильно понимаю, что не является нормализацией именно разбиение 1-ой нормальной формы на 2 таблицы, но разбиение в исходном варианте, когда таблица была некорректной (телефоны через запятую), является нормализацией?
То есть и то, и то НФ, но разбиение таблицы - изменение структуры уже нормальной формы?
декомпозиция применяется для достижения нормальных форм. Верность декомпозиции проверяется по теореме Хеза, когда из производных таблиц должна получиться базовая через natural join, иначе она выполнена неверно. Т.е. для декомпозиции должны быть основания и она должна быть корректной.
не понял отличия 2-ой формы и 3-й, если честно
👍👍
Сразу лайк, 0,3 секунда )))
Простите, но это же все взято из этого вот видео th-cam.com/video/zqQxWdTpSIA/w-d-xo.html
Я начинал смотреть это видео, досмотрел до момента, где говорится о нормализации с примером, который нормализацией не является, закрыл после этого. Там автор делает видео по чужим статьям, как понял, так что претензия в первую очередь к автору статьи
@@t0digital т.е. заимствовал без ссылок у того, кто сам так сделал и всё ок?
super
Завтра гос, это судьба🤭
8:00 если мы хотим подать данные на вход нейронки и принимаем андроид за 0, а айос за 1 - это тоже будет называться нормализацией. Но это совсем другая нормализация... Просто у людей в голове перемешиваются сведения из разных областей.
индексы - это не денормализация
и реляционная модель нечего не говорит про них
по этому же принципу хранение в кэше (в памяти) и в кэшах процессора тоже не денормализация
хотя дублирование есть
про атомарность тоже неправильно
два телефона в одном поле вполне допустимо
все зависит от смысла который вкладывается
по сути телефон в данном случае некий комментарий
но в том смысле, в котором эти телефоны используются дальше в примерах
разбиение точно имеет смысл
phone1, phone2 - также допустимо и не нарушает первую нормальную форму
это возможно коробит взгляд
но формально не нарушает
по поводу двух таблиц с суррогатными идентификаторами
тут опять заблуждение
строго говоря реляционная модель ничего не знает про физическое хранение данных
таблицы могут храниться физически "сджойненными"
и написав запрос с join "физически" его не будет
Спасибо за ваше мнение, лень спорить
Вообще нормальных форм 6.
Не считая 3НФБК = 3,5
Ага
Не услышал таких понятий как связи "один к одному", "один ко многим", "многие ко многим" в контексте нормализации. А это основные вещи для этой темы.
Нет
Так об этом же сказали)))
Не стало яснее...
Жаль...
Уксивт благодорит тебя
Теория с вредным примером, когда утверждается что не надо разделять на две таблицы то, что на практике обязательно надо разделять на две таблицы. Здравый смысл негодует) Спасибо за напоминание о базовых знаниях по нормализации БД.
Ну давайте, аргументируете, раз уж накидываете. Конкретику только, пожалуйста, вот тут автор (я) сказал то-то, а вы считаете, что надо так-то. Чтобы без бла бла.
@@t0digital сразу скажу я не силен в этом всем, но я солидарен с коментатором. Когда была речь о первой нормальной форме, там был пример сделать таблицу «ось» как отдельную и просто через фк связывать и мол это лишний джоин и тд. Но разве это бы не исключило в то же время человеческий фактор? я делаю инсерт и пишу вместо “Android” “android” и как мне допустим фильтровать данные по «ос»? тогда сидеть делать через LIKE?) Я не истина и на нее не претендую) Просто имхо
@@ПашаКазачёнок я же говорю о нормализации в этом видео. Строковый аргумент вынести в отдельную таблицу и ссылаться на нее с суррогатным ключом это не нормализация и я об этом - некорректно такой пример называть нормализацией.
@@t0digital Я тоже порой люблю спрашивать у тех у кого вокруг все гвно. А что тогда не гвно?))) И с аргументами пожалуйста))) И Сашка Зверев сдулся))) Как я понял первый пример это разделение на две таблицы не есть нормализация. А все подробности того кто как сделал БЫ, это уже не важно. Спасибо за объяснение я теперь хоть знать буду что такое есть)))
@@t0digital Ну смотрите, сначала вы говорите, что нормализация - это здравый смысл, оформленный в определенных терминах, а затем зачем то приводите пример разделения на таблицы с числовым ключом, который абсолютно правильный и говорите что это не нормализация (хотя многие называют это нормализацией). Поэтому здравый смысл негодует, его отставили в сторонку, ради теории. Тогда лучше было бы его вообще не упоминать, или не упоминать этот пример. Ок, бла, бла, бла всё.
По сути, почему пример, который не нормализация правильный:
1. Размер БД.
2. Выделение ОС отдельным объектом со своим уникальным идентификатором и свойствами. Прощайте копии с разными наименованиями одной оси, и привет удобной работе с данным объектом.
3. Числовой ключ быстрее текстового, если не вводить индексы.
Почему то мне из изучения нормализации запомнились когда-то пример с числовыми ключами, может быть потому что тогда еще не было пайтона и мощных компьютеров, которые прощают любые проектные решения.
Кайф
Ох... Вот "войти в ит" наслушаются и потом на "голубом глазу" на собесах рассказывают, что индексы хранят в себе данные 🤦♀️
Конечно, индексы хранят данные, вы откуда свалились? Почитайте про index only scan, когда вся выборка происходит из индекса, без обращения к таблице
@@t0digital Признаю, это частный случай в pg. Есть частный случай в ms sql в виде included fields. Но вы же это не указывали. В общем случаи индексы не дублируют данные и хранят ссылки.
А как работает, например, btree-индекс не в pg? Как он может не хранить данные? Ссылки на таблицу там есть, конечно, но и сами данные тоже есть, в упорядоченном виде для ускорения поиска.
@@t0digital Да, конечно, сами индексируемые данные хранятся в индексе. Переслушал видео, понял, что меня тригернула фраза "избыточные данные" и неверно восприняв контекст я сморозил х...ю. Почему-то клинонуло на хранение значимых данных не являющихся индексом как в случае с включенными полями. Был не прав. Приношу извинения.
Староват ты для котанов, дедуля
Хуясе заявочки!
Спасибо