зашёл на 5 минут глянуть видос (на тим лид сказал ужасающие слова "Мы начинаем нормализвывать БД"), и пропал на все 40 минут. Определенно, у тебя талант притягивать внимание своих слушателей. Главное, что после просмотра, у меня в квартире сухо и без осадков, а это первое свидетельство того, что данный материал был "без воды") Подписку кинул, лайк!
Переписываю в кучу, чтобы запомнить лучше. Может, пригодится. *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; - Ключевые атрибуты составного ключа не должны зависеть от неключевых атрибутов. а теперь пойду в магазин, пока не закрылся. допишу потом.
Мне кажется тот кто придумал дизайн подачи материала для данного канала гений, смотришь на синие буквы на бирюзовом фоне и хочется все видосы посмотреть.
Классное видео, спасибо. Упрощенно: Приводите таблицы к как можно меньшему виду, следуя этому принципу вы незаметно для себя пройдете через все уровни нормализаций. Не стесняйтесь создавать таблицы исключительно для связывания двух других таблиц, например по их индексу Обобщение: Основное правило программирования - не повторятся, оно же действует и здесь. Повторение - зло, устраняйте повторения этапами нормализаций. Исключение: Не уходите в фанатизм.
Введение в реляционные базы данных и нормальные формы 1. База данных - это любой набор данных, который можно хранить и управлять. 2. Реляционная модель - это структура для организации и хранения данных, где информация представляется в виде отношений (таблиц). 2.1 Отношения - таблицы, состоящие из множества записей (строк), каждая из которых состоит из атрибутов (столбцов). Описание: Каждая строка в таблице можно рассматривать как элемент отношения, а атрибуты определяют характеристики этих элементов. 2.2 Кортежи - это строки таблицы (записи). Описание: Упорядоченная коллекция (набор) элементов, соответствующих атрибутам таблицы. Порядок имеет значение, так как он соответствует структуре таблицы и представляет отдельные записи, связанные с сущностями (например, конкретный клиент или товар). 2.3 Атрибуты - это поля таблицы (столбцы). Описание: Атрибуты описывают свойства или характеристики записей (сущностей). Они могут быть разных типов. Например, у клиента могут быть атрибуты: имя, адрес, возраст, вес. 3. Реляционная база данных - это упорядоченная информация, связанная между собой определенными отношениями. Такие базы данных состоят из таблиц, в которых и содержится вся информация. 4. Связь между данными Описание: Отношение также описывает связь между данными. Например, в таблице "Клиенты" могут храниться данные о клиентах, а в таблице "Заказы" - информация о заказах этих клиентов. Связи между таблицами (например, через первичные и внешние ключи) позволяют связывать данные и обеспечивать целостность. 5. Основные понятия 5.1 Избыточность данных - это ситуация, когда одни и те же данные хранятся в нескольких местах, что приводит к аномалиям, требующим обновления или удаления одинаковых данных в нескольких местах. 5.2 Нормальная форма базы данных - это набор правил и критериев, которым должна отвечать база данных, чтобы избежать избыточности и аномалий. 5.3 Нормализация - это последовательный процесс приведения базы данных к нормальным формам, начиная с ненормализованной формы (UNF) и переходя к более высоким нормальным формам. Процесс: Удаление избыточных данных. Устранение аномалий. Повышение производительности. Повышение удобства управления
Круто. Интересно. Понятно, особенно со второго раза (для такой тяжёлой абстрактной темы - невероятно). Без воды, но абсолютно не сухое изложение (поразительно)!
Очень грамотно преподносите материал, уже не первый раз ваши видео помогают. Хотелось бы ещё список литературы по обсуждаемому вопросу видеть в конце. Именно ваши рекомендации. Спасибо!
очень полезно, спасибо. нам на лекциях транзитивные и функциональные зависимости пытаются пояснять через реляционную алгебру (а точнее показывают нам белиберду на одном слайде которая моментально забывается и не разбирается толком даже). тут слава богу нет такого.
Видео добротное, лично мне было бы приятно увидеть список дополнительной литературы (не обязательно книги, это могут быть и просто статьи на Хабре, и материалы конференций - что угодно) и больше наглядных примеров, по нескольку для каждой нормальной формы.
Очень прям хорошо! Браво! Я бы дополнил, что 6нф не обязательно высшая форма с поддержанием историчности. Для этого обычно применяют медленно-изменяющиеся измерения типа 2. И под scd-2 можно подстроить сущность в третьей нормальной форме, получив необходимую и достаточную нормализацию данных, и отсутствие ограничений в периодах актуальности этих данных. Как для прошлого, так и для периодов в будущем. 😊
То самое чувство, когда в универе льют воду на 4 пары и все равно нормально не объясняют, а тут вы за 40 минут все по полочкам раскидали... Большое спасибо за видео)
20:53 тут можно составной ключ из 3 частей сделать, да и "направление" это скорее информация относящаяся строго к проекту и должна находится внутри таблицы проектов
Спасибо, очень приятно! Можно подписаться на канал - этого будет вполне достаточно) Но если очень сильно хочется поддержать, то есть в описании к видео ссылки на Юмани и Бусти (ролики, естественно, и без этого продолжу выпускать, но будет приятно :)
Нормальные формы 0NF Нулевая нормальная форма (ненормализованная форма) Цель: Определить начальную структуру данных. Действие: Собрать (Записывать) данные без соблюдения реляционных принципов, не структурируя их в таблицы. 1NF (Первая нормальная форма) Цель: Устранить дублирование строк и обеспечить атомарность данных. Действие: Заполнить все атрибуты, чтобы они содержали только одно атомарное значение без повторяющихся атрибутов. Последовательность: 1. Разделить составные значения на отдельные атрибуты. 2. Убедиться, что в каждом атрибуте содержится только одно значение (атомарность). 3. Удалить повторяющиеся атрибуты с одинаковым смыслом. Результат: - нет дублирующихся строк - все атрибуты атомарны (содержат одно не составное значение) - нет повторяющихся атрибутов с одинаковым смыслом 2NF (Вторая нормальная форма) Цель: Устранить частичные зависимости от первичного ключа. Центр внимания: Первичный ключ (Полная функциональная зависимость от PK) Действие: Разделить таблицы так, чтобы каждый неключевой атрибут зависел от всего первичного ключа, исключив зависимости от его частей. Последовательность: 1. Определить составные ключи в таблице. 2. Убедиться, что все неключевые атрибуты зависят от всего составного ключа, а не от его части. 3. Разделить таблицы, если неключевые атрибуты зависят только от части ключа. Результат: - отношение находится в первой нормальной форме - есть первичный ключ - все неключевые атрибуты функционально зависят от первичного (PK) ключа целиком, а не от его части Ключ: Столбец или набор столбцов, по которым гарантировано можно отличить строки друг от друга. Содержит уникальное значение. Пример: В таблице с атрибутами (ID_студента, Курс, Имя_студента), где (ID_студента, Курс) является составным первичным ключом, имя студента должно зависеть от всего ключа (ID_студента, Курс), а не только от ID_студента. 3NF (Третья нормальная форма) Цель: Устранить транзитивные зависимости между неключевыми атрибутами. Центр внимания: Прямые зависимости от PK Действие: Устранить транзитивные зависимости, гарантируя, что каждый неключевой атрибут зависит только от первичного ключа, без влияния других неключевых атрибутов. Последовательность: 1. Проверить зависимости между неключевыми атрибутами. 2. Определить, имеются ли транзитивные зависимости (неключевые атрибуты, зависящие от других неключевых атрибутов). 3. Разделить таблицы, чтобы убрать транзитивные зависимости, перенесенные в новые таблицы. Результат: - отношение находится во второй нормальной форме - Неключевые атрибуты напрямую зависят только от первичного ключа и не имеют зависимостей от других атрибутов (отсутсвие транзитивной зависимости). Транзитивная зависимость: Зависимость неключевых столбцов от значений других неключевых столбцов. Исключение транзитивной зависимости: Производится путем декомпозиции - разнесением атрибутов в разные таблицы. Пример: Если в таблице есть (ID_студента, Курс, Имя_студента, Адрес_преподавателя), и Адрес_преподавателя зависит от Курс, то это транзитивная зависимость. Чтобы перейти в 3NF, нужно разделить данные на две таблицы.
Это неправда, что высокая нормализация встречается крайне редко. Якорная модель (anchor), например, использует 5NF. Вместе с Data Vault (тоже высоконормализованным) они составляют основу современных классических хранилищ данных в больших компаниях. Если в DWH более 50Тб, и у него есть детальный слой, то он почти наверняка высокономализованный.
15:54 , но ведь при просмотре таблицы с проектами и участниками не будет понятно сразу что за проекта в конкретной ячейке и какой участник прикреплен за ним, или это я не понял?
Знание предметной области и руководство разумными решениям это хорошо, но никто не застрахован от того что в будущем придет манагер и не выдаст что-то вроде: "Так, сейчас кризис, поэтому каждый сотрудник теперь обязан работать в двух отделах на трёх должностях, и имееть соответственно по два рабочих телефона для каждого отдела, а на один телефон до двух должностей. К завтрашнему дню пожалуйста внесите вот эти кадровые изменения в программу!".
@@ArtemGurtikov да, вы правы, должности тоже нужно выносить в отдельную таблицу 100%. Думаю, автор опустил это, чтобы много не расписывать, а просто принцип показать. Либо просто не заметил :)
21:03 Я что-то не понимаю. Если у нас есть зависимость ключевого атрибута (направление) от неключевого атрибута (куратор) в данной таблице, то она также сохранилась в этой таблице 21:37 Просто теперь это зависимость одного неключевого атрибута (направление) от другого неключевого (ФИО, то же самое, что куратор до декомпозиции). Только теперь эти таблицы даже не соответствуют 3NF, т. к. есть транзитивная зависимость
Як на мене на початку проєктування якщо правельно розставити звязки то і таблиці получаться нормальними, ну а ці правила можуть знадобитись коли до таблиці в ході використання ми видаляємо чи додаємо якісь поля
Материал отличный. Делала заметки и конспект в процессе просмотра, чтобы лучше запомнить важные аспекты. Но у меня возник вопрос по третьей нормальной форме. НА промежутке 18:36 говорится о том, что в таблице будет храниться ФИО, должность и по сути id подразделения. Но почему бы не вынести должность так же в отдельный справочник\таблицу? Ведь должность такой аспект, который может повторяться, и при вводе данных о должности можно ошибиться. Например, сотрудник введет должность как "праграмист", и это уже будет аномалия. Так как при поиске программистов в организации, человек с должностью "праграмист" в выборке присутствовать не будет. Поправьте, если не правильно рассуждаю.
Спасибо за отзыв, очень приятно! Да, всё правильно говорите. Должности нужно обязательно выносить в отдельную таблицу и прописывать её ИД в таблице сотрудников. Думаю, автор просто оставил названия должностей, чтобы переусложнять восприятие таблицы (правда, суть 3NF потерялась для должностей, получается - факт :) Вообще, на практике таблица сотрудников обычно выглядит как несколько атрибутов сотрудника и куча внешних ключей-идентификаторов: его должность, направление, отдел, локация и пр.
а разве на 21:43 таблица Кураторов не нарушает 3NF? Ведь первичным ключом является идентификатор куратора, но при этом атрибуты направления могут зависеть от атрибутов ФИО (где оба являются неключевыми). Или же мы не должны проверять на условие NF таблицы полученные путем декомпозиции, а лишь проверять таблицу связи?
Конкретно на примере из статьи похоже, что таблица кураторов достаточно нормализована. Нет смысла (чаще всего) выносить направления в отдельную таблицу, если у направления нет своих атрибутов (можно, конечно, сделать справочник направлений только с ИД направления и его названием, но это не всегда оправдано). Иногда можно и вынести направления в отдельную таблицу, но для этого примера это было бы ни к чему и слишком громоздко
Знающие подскажите, если идентификаторы зависит друг от друга то это 2НФ?(пример: в таблице клиенты 10 строк и в таблице заказы, заказы не могут превышать 10). Если таблице есть два идентификатора то это 3НФ?
Здравствуйте , а можно вопрос, если мне надо создать таблицу с оборудованием и у меня в ней есть столбец характеристика, но оборудование разное и соответственно характеристики у всех разные, но если я не могу их написать списком, как мне поступить с учётом того что что у разного оборудования характеристики совершенно отличаются друг от друга и я не могу их всех занести в отдельную таблицу, мне для каждого оборудования заводить отдельно таблицу?
Про 4 НФ немного не понятно, самый первый пример препод-курс-аудитория не поддается декомпозиции без потерь. Разбив таблицу препод-курс-аудитория на две таблицы курс-препод и курс-аудитория мы теряем информацию. Например теряем информацию что Иванов ведет курс SQL в 101 аудитории (представим что это реально расписание и реально нужна именно эта связь (курс-препод-аудитория)). Хотя в первой таблице эта информация была и она явно важная (как для расписания). Это не претензия к автору видоса, просто нужно знать что некоторые данные не поддаются декомпозиции без потерь.Поэтому форма Бойса Кодда это максимум "нормальности" который можно выжать из подобных данных.
В 14:36, объясните кто нибудь, почему нельзя вместо составного ключа, просто создать какой то ID или условный N°- (number) для идентификации строки? Так тоже ведь будет понятно про какую строку идет речь
Отличный пример отсутствия нормализации данных - это фильтры в торговых площадках, типа озона или вайлдберис, где параметры товара заполняет продавец. Зачастую ни один из этих фильтров использовать невозможно, кроме цены и, может быть, бренда. Хотя и там умудряются внести несколько вариаций одного названия.
28:55 автор не сталкивался с "настоящими" программистами, чей могз изуродован бесконечным количеством литературы которую они поглащают и такое чувство, что они уже оторваны от реальности и пишут код только лишь бы это бы так как написано в книжке =)
"привести базу к минимальной избыточности" на мой взгляд не отражает сути нормализации - грамотнее сказать что данные и базы данных ПРОЕКТИРОВАТЬ нужно в компактной лаконичной и удобной для понимания форме - причем понимать эти данные должен потом не только проектировщик БД, но и пользователь БД... С тех пор как связи между таблицами стали визуализировать нужно было давно модифицировать и определение нормализации
Зачем делать ключом какое то поле, если можно просто добавить поле ID и сделать его ключом во всех таблицах. Такое поле гарантированно будет уникальным.
Всё от бизнес-контекста зависит. Чаще всего такого не может быть, но если в системе подразумевается, что у разных людей с одним именем может быть один номер телефона, то почему бы и нет, возможно.
На счет уникального табельного номера Вы не правы. Человек может уволиться, после года работы, а потом вновь поступить на работу в ту же организацию, и 100% под новым табельным номером.. и если искать по ФИО + дата рождения то выпадут 2, а то и 3 записи. Бывало, что целыми цехами по 200-500чел увольняли-принимали сотрудников, но в уже другой цех-подразделение (на то был свои причины). Так что, я бы не рассматривал табельный номер, как единственный идентификатор. Просто такое-же поле как и фио.
В таком кейсе, как в примере, нежелательно, т. к. перечень значений может динамически меняться, и в этом случае лучше использовать справочники. Плюс, если у значений справочников чуть более сложная структура, чем просто одно название (например, перевод на разные языки и ещё другие атрибуты), то тут уже точно справочник нужен.
@@ListenIT_channel отдельная таблица имеет смысл только при динамическом изменении, так как в случае со справочником наоборот удобнее использовать enum как ключ
@@N5O1 проблема в том, что справочники, как правило, имеют свойство обновляться, даже если бизнес говорит, что это самый стабильный перечень значений в мире)
Не совсем. Первичный ключ - это уникальный идентификатор строки, т. е. это не порядковый номер. Порядковый номер = 5 означает, например, что эта строка пятая в таблице. А ключ = 5 у строки только означает, что идентификатор равен 5, и это уникальный номер строки. Какой бы мы запрос не сделали, сколько бы мы строк не запросили из таблицы, и на каком бы порядковом месте в таблице не оказалась эта строка, она всё равно будет иметь ID = 5. Т. е. да, идентификатор действительно иногда генерируется как нумерация строк по порядку, но только этот номер "железно" присваивается строке и не означает порядковый номер, а именно что уникальный идентификатор, и не изменяется при разном положении этой строки в таблице.
Случайно попал на видео. Увы, автор вообще мало что понимает в нормальных формах, уровень знаний крайне низкий. Огромное количество утверждений смехотворно ошибочные. Множество самопальных выдумок. Приводимые для иллюстрации примеры зачастую вообще не имеют отношения к рассматриваемой НФ. Это какой-то позор. Не нужно снимать такие видео, вы только запутываете людей.
@@ListenIT_channel Ну, давайте начнём. Посмотрим хотя бы на первые две три минуты ролика. 00:49 «Под базой данных можно понимать любой набор информации, которую можно найти в этой базе данных». Как вам определение? Оно вообще рекурсивное. 02:34 Таблица («Идентификатор предмета», «Наименование предмета», «Материал») на самом деле удовлетворяет всем нормальным формам, но в ролике представлена как будто бы неправильная и требующая нормализации. На деле, если предложить автору ролика указать, какая НФ нарушена, он не сможет. Потому что никакая не нарушена. Пока хватит, попытайтесь ответить на эти замечания, потом могу продолжить.
@@ЕвгенийМирошниченко-е5м 1. Это "определение" не претендует на точное научное описание и не преподносится как определение, а упоминается для того, чтобы "на пальцах" новичку объяснить, что имеется в виду - думаю, эта фраза выполняет свою задачу (видео вообще не про определение БД, эта фраза упоминается вскользь). Академическое ли это определение? Нет. И не должно быть в данном контексте. Мне кажется, тут вы просто придрались, и непонятно зачем. 2. А вот это интересный вопрос. Тут транзитивную зависимость очень сложно уловить, но выделение материала в отдельную таблицу я бы назвал неявным приведением к 3NF. Но это спорный момент - согласен. То, что тут "однозначно не нарушена никакая НФ" - как минимум, точно не так однозначно, как вы об этом говорите. Ну и блок, в котором приведён пример, обсуждает избыточность данных - пока никакая конкретная НФ там не рассматривается. Ладно, давайте сэкономим друг другу время и не будем попусту спорить. Вам видео явно не понравилось (и это ваше право), и у вас явно настрой придраться к любой фразе, а я явно буду защищать статью автора, потому что почти во всём с ним согласен. Кстати, в видео действительно есть более важные условности, которые допустил автор, и мы их довольно успешно разбираем в комментариях выше со зрителями, без негатива. Вы же решили написать про "определение" БД и говорить про "самопальные выдумки". Могу вам пожелать только не быть таким категоричным во всём, ну и успехов :)
@@ListenIT_channel Неправда, я написал, что взял примеры (некорректных высказываний и нерелевантных примеров) из первых же двух-трёх минут ролика. И готов продолжить. Это всего лишь значит, что я двигаюсь последовательно. Например, уже на 5-й минуте автор вводит диковинный термин «нормальная форма базы данных». Такого понятия не существует. НФ бывает только у отдельного отношения. Это иллюстрирует степень владения автора терминологией. Далее, примером «самопальной выдумки» является «нулевая нормальная форма», о которой автор поведал на 6-й минуте. Нет никакой «нулевой нормальной формы». Затем автор ввёл понятия «основных» и «дополнительных» НФ. Это тоже выдумка, такого деления не существует. Например, BCNF ничем не менее «основная», чем другие. Затем автор на 7-й минуте заявляет, что «третья форма устраняет достаточное количество аномалий, при этом производительность базы данных, а также удобство ее использования не снижается, что нельзя сказать о всех последующих формах». Это полностью смехотворное утверждение по целому ряду факторов. Начиная с того, что нормализация вообще никак не связана с производительностью. Одни запросы она ускоряет, другие замедляет. Так я могу продолжать. Но в целом видно, что автор с терминологией знаком поверхностно и даёт слушателю сомнительные и даже ложные утверждения.
@@ListenIT_channel Если вы говорите, что в примере "нарушена НФ", то это легко доказать. Скажите, какая НФ конкретно нарушена. После этого я процитирую вам определение этой НФ и покажу, что оно соблюдается. По сути вы не опровергли ни одно из моих высказываний, о предоставлении которых сами же мне написали. Поскольку я прав, то фразы «вы придираетесь», «у вас явно настрой придраться», это не аргументация, а переход на эмоции. Утверждения о моём якобы "настрое" никак не заменит конструктивное развенчание моих якобы "придирок".
лол, а как сделать декомпозицию к 3-ей нормальной форме если ты ее уже сделал , что бы привести таблицу ко 2 нормальной форме ??? то есть у тебя 2-я нормальная форма - это 3 таблицы допустим разбитых на части,
![[LIVE] : ONE ลุมพินี 88 | คู่เอก "ป้อมเพชร vs อัสลามจอน"](http://i.ytimg.com/vi/1ZqTVVbMgbo/mqdefault.jpg)
зашёл на 5 минут глянуть видос (на тим лид сказал ужасающие слова "Мы начинаем нормализвывать БД"), и пропал на все 40 минут. Определенно, у тебя талант притягивать внимание своих слушателей. Главное, что после просмотра, у меня в квартире сухо и без осадков, а это первое свидетельство того, что данный материал был "без воды") Подписку кинул, лайк!
Он просто все по статье в описании прочитал, поэтому и без воды😅
Переписываю в кучу, чтобы запомнить лучше. Может, пригодится.
*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;
- Ключевые атрибуты составного ключа не должны зависеть от неключевых атрибутов.
а теперь пойду в магазин, пока не закрылся. допишу потом.
вы так и не вернулись из магазина?)
Вы пошли за хлебом?
Мне кажется тот кто придумал дизайн подачи материала для данного канала гений, смотришь на синие буквы на бирюзовом фоне и хочется все видосы посмотреть.
очень нужны такие видео
легче и быстрее информацию принимаешь
спасибо
Классное видео, спасибо.
Упрощенно:
Приводите таблицы к как можно меньшему виду, следуя этому принципу вы незаметно для себя пройдете через все уровни нормализаций. Не стесняйтесь создавать таблицы исключительно для связывания двух других таблиц, например по их индексу
Обобщение: Основное правило программирования - не повторятся, оно же действует и здесь. Повторение - зло, устраняйте повторения этапами нормализаций.
Исключение: Не уходите в фанатизм.
Лучший канал, суть вещей без воды!
Введение в реляционные базы данных и нормальные формы
1. База данных - это любой набор данных, который можно хранить и управлять.
2. Реляционная модель - это структура для организации и хранения данных, где информация представляется в виде отношений (таблиц).
2.1 Отношения - таблицы, состоящие из множества записей (строк), каждая из которых состоит из атрибутов (столбцов).
Описание: Каждая строка в таблице можно рассматривать как элемент отношения, а атрибуты определяют характеристики этих элементов.
2.2 Кортежи - это строки таблицы (записи).
Описание: Упорядоченная коллекция (набор) элементов, соответствующих атрибутам таблицы. Порядок имеет значение, так как он соответствует структуре таблицы и представляет отдельные записи, связанные с сущностями (например, конкретный клиент или товар).
2.3 Атрибуты - это поля таблицы (столбцы).
Описание: Атрибуты описывают свойства или характеристики записей (сущностей). Они могут быть разных типов.
Например, у клиента могут быть атрибуты: имя, адрес, возраст, вес.
3. Реляционная база данных - это упорядоченная информация, связанная между собой определенными отношениями.
Такие базы данных состоят из таблиц, в которых и содержится вся информация.
4. Связь между данными
Описание: Отношение также описывает связь между данными.
Например, в таблице "Клиенты" могут храниться данные о клиентах, а в таблице "Заказы" - информация о заказах этих клиентов. Связи между таблицами (например, через первичные и внешние ключи) позволяют связывать данные и обеспечивать целостность.
5. Основные понятия
5.1 Избыточность данных - это ситуация, когда одни и те же данные хранятся в нескольких местах, что приводит к аномалиям, требующим обновления или удаления одинаковых данных в нескольких местах.
5.2 Нормальная форма базы данных - это набор правил и критериев, которым должна отвечать база данных, чтобы избежать избыточности и аномалий.
5.3 Нормализация - это последовательный процесс приведения базы данных к нормальным формам, начиная с ненормализованной формы (UNF) и переходя к более высоким нормальным формам.
Процесс:
Удаление избыточных данных.
Устранение аномалий.
Повышение производительности.
Повышение удобства управления
Это лучшие видео, причем нет ошибки про нулевую форму, которые некоторые считают первой)
Круто. Интересно. Понятно, особенно со второго раза (для такой тяжёлой абстрактной темы - невероятно). Без воды, но абсолютно не сухое изложение (поразительно)!
Спасибо, очень приятно! И спасибо тут автору статьи, конечно, прежде всего
Очень грамотно преподносите материал, уже не первый раз ваши видео помогают.
Хотелось бы ещё список литературы по обсуждаемому вопросу видеть в конце. Именно ваши рекомендации.
Спасибо!
Спасибо! Отличный материал как и его подача!
Ну, за материал тут, скорее, автору статьи спасибо, а за подачу благодарю :)
Отличное видео. Круто что с примерами! Очень полезно. Спасибо)
Вот это красота, шикарный видос, супердоступно, душевно братишечка!
Огонь. Разок пересмотрю и туман рассеится
Божественное видео, зашел от скуки, затянуло
очень полезно, спасибо. нам на лекциях транзитивные и функциональные зависимости пытаются пояснять через реляционную алгебру (а точнее показывают нам белиберду на одном слайде которая моментально забывается и не разбирается толком даже). тут слава богу нет такого.
Если бы нам так объясняли по ходу семестра, я бы сдала лабораторную работу за пять минут :\
Спасибо
Очень приятно слышать :)
базы данных один из самых легких курсов в универе, у нас его осилили все без исключений, я удивлен, что ты его не осилил
@@iam21h мда, откуда ты взял, что предмет я не осилила? Чисто выводы из жопы
@@Laegmerill1306 ну раз осилила эт хорошо
@@iam21h зачем ты это пишешь? алеша
Очень круто. Спасибо за материал!
Видео добротное, лично мне было бы приятно увидеть список дополнительной литературы (не обязательно книги, это могут быть и просто статьи на Хабре, и материалы конференций - что угодно) и больше наглядных примеров, по нескольку для каждой нормальной формы.
Очень хорошее изложение.
Контент супер
Хорошо объясняешь. Спасибо
Классное видео! Очень много полезной информации. Было бы интересно послушать про JIRA и Confluence - так как на канале видосов не нашел) Спасибо!
Услышали, добавим в очередь!
Спасибо, очень хорошее видео и объяснения
Очень прям хорошо! Браво!
Я бы дополнил, что 6нф не обязательно высшая форма с поддержанием историчности. Для этого обычно применяют медленно-изменяющиеся измерения типа 2. И под scd-2 можно подстроить сущность в третьей нормальной форме, получив необходимую и достаточную нормализацию данных, и отсутствие ограничений в периодах актуальности этих данных. Как для прошлого, так и для периодов в будущем. 😊
про 6НФ посмотрите на якорное моделирование и Data Vault и значимость DE/DWH для компаний
похоже, что я спроектировал 3NF для своей CRM еще до того, как узнал о каких то правилах. Наверное, это хороший знак ))
Очень хорошо, спасибо
То самое чувство, когда в универе льют воду на 4 пары и все равно нормально не объясняют, а тут вы за 40 минут все по полочкам раскидали...
Большое спасибо за видео)
Спасибо, рад, что помог :)
Просто лучший видос! Нам его препод на парах показывал
Спасибо, очень приятно! Но тут, конечно, прежде всего, спасибо автору статьи, за такую классную содержательную статью.
очень качественное объяснение
Классный канал!!!
20:53 тут можно составной ключ из 3 частей сделать, да и "направление" это скорее информация относящаяся строго к проекту и должна находится внутри таблицы проектов
хороший материал спасибо!
Спасибо за отзыв, стараемся!
Парень, ты просто красавчик! Это лучшее что я видел ))) что нужно, чтобы ты и дальше выпускал ролики?
Спасибо, очень приятно! Можно подписаться на канал - этого будет вполне достаточно) Но если очень сильно хочется поддержать, то есть в описании к видео ссылки на Юмани и Бусти (ролики, естественно, и без этого продолжу выпускать, но будет приятно :)
@@ListenIT_channel от души!
спасибо огромное, стало очень понятно🥰
Рад, что помогло :)
Спасибо за видео!
Нормальные формы
0NF Нулевая нормальная форма (ненормализованная форма)
Цель: Определить начальную структуру данных.
Действие: Собрать (Записывать) данные без соблюдения реляционных принципов, не структурируя их в таблицы.
1NF (Первая нормальная форма)
Цель: Устранить дублирование строк и обеспечить атомарность данных.
Действие: Заполнить все атрибуты, чтобы они содержали только одно атомарное значение без повторяющихся атрибутов.
Последовательность:
1. Разделить составные значения на отдельные атрибуты.
2. Убедиться, что в каждом атрибуте содержится только одно значение (атомарность).
3. Удалить повторяющиеся атрибуты с одинаковым смыслом.
Результат:
- нет дублирующихся строк
- все атрибуты атомарны (содержат одно не составное значение)
- нет повторяющихся атрибутов с одинаковым смыслом
2NF (Вторая нормальная форма)
Цель: Устранить частичные зависимости от первичного ключа.
Центр внимания: Первичный ключ (Полная функциональная зависимость от PK)
Действие: Разделить таблицы так, чтобы каждый неключевой атрибут зависел от всего первичного ключа, исключив зависимости от его частей.
Последовательность:
1. Определить составные ключи в таблице.
2. Убедиться, что все неключевые атрибуты зависят от всего составного ключа, а не от его части.
3. Разделить таблицы, если неключевые атрибуты зависят только от части ключа.
Результат:
- отношение находится в первой нормальной форме
- есть первичный ключ
- все неключевые атрибуты функционально зависят от первичного (PK) ключа целиком, а не от его части
Ключ: Столбец или набор столбцов, по которым гарантировано можно отличить строки друг от друга. Содержит уникальное значение.
Пример: В таблице с атрибутами (ID_студента, Курс, Имя_студента), где (ID_студента, Курс) является составным первичным ключом, имя студента должно зависеть от всего ключа (ID_студента, Курс), а не только от ID_студента.
3NF (Третья нормальная форма)
Цель: Устранить транзитивные зависимости между неключевыми атрибутами.
Центр внимания: Прямые зависимости от PK
Действие: Устранить транзитивные зависимости, гарантируя, что каждый неключевой атрибут зависит только от первичного ключа, без влияния других неключевых атрибутов.
Последовательность:
1. Проверить зависимости между неключевыми атрибутами.
2. Определить, имеются ли транзитивные зависимости (неключевые атрибуты, зависящие от других неключевых атрибутов).
3. Разделить таблицы, чтобы убрать транзитивные зависимости, перенесенные в новые таблицы.
Результат:
- отношение находится во второй нормальной форме
- Неключевые атрибуты напрямую зависят только от первичного ключа и не имеют зависимостей от других атрибутов (отсутсвие транзитивной зависимости).
Транзитивная зависимость: Зависимость неключевых столбцов от значений других неключевых столбцов.
Исключение транзитивной зависимости: Производится путем декомпозиции - разнесением атрибутов в разные таблицы.
Пример: Если в таблице есть (ID_студента, Курс, Имя_студента, Адрес_преподавателя), и Адрес_преподавателя зависит от Курс, то это транзитивная зависимость. Чтобы перейти в 3NF, нужно разделить данные на две таблицы.
Спасибо ❤
Если это было снять с 1ого дубля, то вообще респект
В общем руководствуемся здравым смыслом )
лучшее что я видел по НФ
хотел бы посмотреть материал JAVA+SQL
Благодарю
Это неправда, что высокая нормализация встречается крайне редко.
Якорная модель (anchor), например, использует 5NF. Вместе с Data Vault (тоже высоконормализованным) они составляют основу современных классических хранилищ данных в больших компаниях. Если в DWH более 50Тб, и у него есть детальный слой, то он почти наверняка высокономализованный.
как всегда все круто! :D
Однако... Инфа супер!
15:54 , но ведь при просмотре таблицы с проектами и участниками не будет понятно сразу что за проекта в конкретной ячейке и какой участник прикреплен за ним, или это я не понял?
Знание предметной области и руководство разумными решениям это хорошо, но никто не застрахован от того что в будущем придет манагер и не выдаст что-то вроде: "Так, сейчас кризис, поэтому каждый сотрудник теперь обязан работать в двух отделах на трёх должностях, и имееть соответственно по два рабочих телефона для каждого отдела, а на один телефон до двух должностей. К завтрашнему дню пожалуйста внесите вот эти кадровые изменения в программу!".
А еще, приготовьте мне кофе и вымойте пол, поскольку Вы теперь не только программист, но и секретарь-уборщица )))
Спасибо!!
Спасибо. Это было супер полезно 😊
Звук во вступлении будто из Героев Меча и Магии III, момент регенерации, кажется.
почему на 18:50 мы не выносим должности в отдельную таблицу?
@@ArtemGurtikov да, вы правы, должности тоже нужно выносить в отдельную таблицу 100%. Думаю, автор опустил это, чтобы много не расписывать, а просто принцип показать. Либо просто не заметил :)
21:03 Я что-то не понимаю. Если у нас есть зависимость ключевого атрибута (направление) от неключевого атрибута (куратор) в данной таблице, то она также сохранилась в этой таблице 21:37 Просто теперь это зависимость одного неключевого атрибута (направление) от другого неключевого (ФИО, то же самое, что куратор до декомпозиции). Только теперь эти таблицы даже не соответствуют 3NF, т. к. есть транзитивная зависимость
Як на мене на початку проєктування якщо правельно розставити звязки то і таблиці получаться нормальними, ну а ці правила можуть знадобитись коли до таблиці в ході використання ми видаляємо чи додаємо якісь поля
А у вас нет случайно только аудио? Хотелось бы слушать при езде в метро или при топании на работу
все круто !!!
Материал отличный. Делала заметки и конспект в процессе просмотра, чтобы лучше запомнить важные аспекты. Но у меня возник вопрос по третьей нормальной форме. НА промежутке 18:36 говорится о том, что в таблице будет храниться ФИО, должность и по сути id подразделения. Но почему бы не вынести должность так же в отдельный справочник\таблицу? Ведь должность такой аспект, который может повторяться, и при вводе данных о должности можно ошибиться. Например, сотрудник введет должность как "праграмист", и это уже будет аномалия. Так как при поиске программистов в организации, человек с должностью "праграмист" в выборке присутствовать не будет. Поправьте, если не правильно рассуждаю.
Спасибо за отзыв, очень приятно! Да, всё правильно говорите. Должности нужно обязательно выносить в отдельную таблицу и прописывать её ИД в таблице сотрудников. Думаю, автор просто оставил названия должностей, чтобы переусложнять восприятие таблицы (правда, суть 3NF потерялась для должностей, получается - факт :) Вообще, на практике таблица сотрудников обычно выглядит как несколько атрибутов сотрудника и куча внешних ключей-идентификаторов: его должность, направление, отдел, локация и пр.
а разве на 21:43 таблица Кураторов не нарушает 3NF? Ведь первичным ключом является идентификатор куратора, но при этом атрибуты направления могут зависеть от атрибутов ФИО (где оба являются неключевыми). Или же мы не должны проверять на условие NF таблицы полученные путем декомпозиции, а лишь проверять таблицу связи?
Конкретно на примере из статьи похоже, что таблица кураторов достаточно нормализована. Нет смысла (чаще всего) выносить направления в отдельную таблицу, если у направления нет своих атрибутов (можно, конечно, сделать справочник направлений только с ИД направления и его названием, но это не всегда оправдано). Иногда можно и вынести направления в отдельную таблицу, но для этого примера это было бы ни к чему и слишком громоздко
Знающие подскажите, если идентификаторы зависит друг от друга то это 2НФ?(пример: в таблице клиенты 10 строк и в таблице заказы, заказы не могут превышать 10). Если таблице есть два идентификатора то это 3НФ?
Здравствуйте , а можно вопрос, если мне надо создать таблицу с оборудованием и у меня в ней есть столбец характеристика, но оборудование разное и соответственно характеристики у всех разные, но если я не могу их написать списком, как мне поступить с учётом того что что у разного оборудования характеристики совершенно отличаются друг от друга и я не могу их всех занести в отдельную таблицу, мне для каждого оборудования заводить отдельно таблицу?
понял ... ! теперь свою рукож#пость буду аномалией называть !
28:28 я подумал, у меня глаз начал дёргаться. до этого не замечал
Про 4 НФ немного не понятно, самый первый пример препод-курс-аудитория не поддается декомпозиции без потерь. Разбив таблицу препод-курс-аудитория на две таблицы курс-препод и курс-аудитория мы теряем информацию. Например теряем информацию что Иванов ведет курс SQL в 101 аудитории (представим что это реально расписание и реально нужна именно эта связь (курс-препод-аудитория)). Хотя в первой таблице эта информация была и она явно важная (как для расписания). Это не претензия к автору видоса, просто нужно знать что некоторые данные не поддаются декомпозиции без потерь.Поэтому форма Бойса Кодда это максимум "нормальности" который можно выжать из подобных данных.
В 14:36, объясните кто нибудь, почему нельзя вместо составного ключа, просто создать какой то ID или условный N°- (number) для идентификации строки? Так тоже ведь будет понятно про какую строку идет речь
Всё верно, обычно так и делают - добавляют uid строки просто.
Получил порцию слова нормально на 15 лет вперед
нормальной формы
graet,thanks.)😎😎😎😎
18:32 здесь лучше бы подошла связывающая таблица "сотрудники_департаменты"
Отличный пример отсутствия нормализации данных - это фильтры в торговых площадках, типа озона или вайлдберис, где параметры товара заполняет продавец. Зачастую ни один из этих фильтров использовать невозможно, кроме цены и, может быть, бренда. Хотя и там умудряются внести несколько вариаций одного названия.
Думаю, если короче, то 1нф - как организовать таблицы, 2нф - как организовать связи
Ого, какие вы крутые.
В любой непонятной ситуации - декомпозируй
Декомпозиция - это процесс разделения чего угодно на более мелкие составные части, а не только таблиц
28:55 автор не сталкивался с "настоящими" программистами, чей могз изуродован бесконечным количеством литературы которую они поглащают и такое чувство, что они уже оторваны от реальности и пишут код только лишь бы это бы так как написано в книжке =)
вот вёрстка по БЭМ это меня одного бесит?
"привести базу к минимальной избыточности" на мой взгляд не отражает сути нормализации - грамотнее сказать что данные и базы данных ПРОЕКТИРОВАТЬ нужно в компактной лаконичной и удобной для понимания форме - причем понимать эти данные должен потом не только проектировщик БД, но и пользователь БД... С тех пор как связи между таблицами стали визуализировать нужно было давно модифицировать и определение нормализации
по dknf просто с Википедии зачитали, я это и сам видел там, ни фига не понятно
Зачем делать ключом какое то поле, если можно просто добавить поле ID и сделать его ключом во всех таблицах. Такое поле гарантированно будет уникальным.
9:00 это же вторая нормальная форма по-факту
10:27 а разве там не может быть 2 джона смита? просто они живут в одном домохозяйстве и предоставили один и тот же номер телефона
Всё от бизнес-контекста зависит. Чаще всего такого не может быть, но если в системе подразумевается, что у разных людей с одним именем может быть один номер телефона, то почему бы и нет, возможно.
12:35 Разве все значения в этой таблицу атомарны? Ведь Ф.И.О. можно разделить отдельно на фамилию, имя и отчество. Так что, извините, не соглашусь.
Это всё-таки просто пример - понятно, что никто не будет хранить ФИО в одной ячейке (редко разве что) да ещё с инициалами :)
@@ListenIT_channel согласен :) Доброго вечера!
🔥
На счет уникального табельного номера Вы не правы. Человек может уволиться, после года работы, а потом вновь поступить на работу в ту же организацию, и 100% под новым табельным номером.. и если искать по ФИО + дата рождения то выпадут 2, а то и 3 записи. Бывало, что целыми цехами по 200-500чел увольняли-принимали сотрудников, но в уже другой цех-подразделение (на то был свои причины). Так что, я бы не рассматривал табельный номер, как единственный идентификатор. Просто такое-же поле как и фио.
Я бы не удалял номера, а при повторном устройстве на работу, использовал бы их же.
9:16 а если использовать значение первой колонки как PK то вполне всё получается =)
Можно, но называть это "порядковым номером" не стоит, так как ключ означает не порядковый номер, а идентификатор
4:01 или создать констрейнт со списком допустимых имен
В таком кейсе, как в примере, нежелательно, т. к. перечень значений может динамически меняться, и в этом случае лучше использовать справочники. Плюс, если у значений справочников чуть более сложная структура, чем просто одно название (например, перевод на разные языки и ещё другие атрибуты), то тут уже точно справочник нужен.
@@ListenIT_channel отдельная таблица имеет смысл только при динамическом изменении, так как в случае со справочником наоборот удобнее использовать enum как ключ
@@N5O1 проблема в том, что справочники, как правило, имеют свойство обновляться, даже если бизнес говорит, что это самый стабильный перечень значений в мире)
а разве наличие первичного ключа нельзя считать пронумерованием строк???? тогда и ненорм.форма даже не соблюдается ведь
Не совсем. Первичный ключ - это уникальный идентификатор строки, т. е. это не порядковый номер. Порядковый номер = 5 означает, например, что эта строка пятая в таблице. А ключ = 5 у строки только означает, что идентификатор равен 5, и это уникальный номер строки. Какой бы мы запрос не сделали, сколько бы мы строк не запросили из таблицы, и на каком бы порядковом месте в таблице не оказалась эта строка, она всё равно будет иметь ID = 5. Т. е. да, идентификатор действительно иногда генерируется как нумерация строк по порядку, но только этот номер "железно" присваивается строке и не означает порядковый номер, а именно что уникальный идентификатор, и не изменяется при разном положении этой строки в таблице.
Ккллласссссссссссс !!!
Поле ФИО не является атомарным
Вы очень быстро читаете. Для доходчивости читайте медленно и с расстановкой.
А мне наоборот кажется что медленно читает, слушаю на х1,5 😅
@@dreamingMary А вы попробуйте вспомнить через 5 минут, что он сказал хотя-бы на 1,5 скорости. Для фона слушать можно и на 2-й.
видимо я слишком тупой для этого...
что такое транзитивная зависимость?))) и откуда этот термин вообще вылез, так плохо обьясняется 3NF, что плакать хочется, хотя там все супер просто
gadgetshelp.com/prilozheniia/chto-takoe-tranzitivnaia-zavisimost-v-baze-dannykh/
Это такое отношение;) вышку не надо было прогуливать
16:23
аьоьа
глубоко
Случайно попал на видео. Увы, автор вообще мало что понимает в нормальных формах, уровень знаний крайне низкий. Огромное количество утверждений смехотворно ошибочные. Множество самопальных выдумок. Приводимые для иллюстрации примеры зачастую вообще не имеют отношения к рассматриваемой НФ. Это какой-то позор. Не нужно снимать такие видео, вы только запутываете людей.
Так, давайте разбираться. Напишите список ошибочных утверждений?
@@ListenIT_channel Ну, давайте начнём. Посмотрим хотя бы на первые две три минуты ролика.
00:49 «Под базой данных можно понимать любой набор информации, которую можно найти в этой базе данных». Как вам определение? Оно вообще рекурсивное.
02:34 Таблица («Идентификатор предмета», «Наименование предмета», «Материал») на самом деле удовлетворяет всем нормальным формам, но в ролике представлена как будто бы неправильная и требующая нормализации. На деле, если предложить автору ролика указать, какая НФ нарушена, он не сможет. Потому что никакая не нарушена.
Пока хватит, попытайтесь ответить на эти замечания, потом могу продолжить.
@@ЕвгенийМирошниченко-е5м
1. Это "определение" не претендует на точное научное описание и не преподносится как определение, а упоминается для того, чтобы "на пальцах" новичку объяснить, что имеется в виду - думаю, эта фраза выполняет свою задачу (видео вообще не про определение БД, эта фраза упоминается вскользь). Академическое ли это определение? Нет. И не должно быть в данном контексте. Мне кажется, тут вы просто придрались, и непонятно зачем.
2. А вот это интересный вопрос. Тут транзитивную зависимость очень сложно уловить, но выделение материала в отдельную таблицу я бы назвал неявным приведением к 3NF. Но это спорный момент - согласен. То, что тут "однозначно не нарушена никакая НФ" - как минимум, точно не так однозначно, как вы об этом говорите. Ну и блок, в котором приведён пример, обсуждает избыточность данных - пока никакая конкретная НФ там не рассматривается.
Ладно, давайте сэкономим друг другу время и не будем попусту спорить. Вам видео явно не понравилось (и это ваше право), и у вас явно настрой придраться к любой фразе, а я явно буду защищать статью автора, потому что почти во всём с ним согласен. Кстати, в видео действительно есть более важные условности, которые допустил автор, и мы их довольно успешно разбираем в комментариях выше со зрителями, без негатива. Вы же решили написать про "определение" БД и говорить про "самопальные выдумки". Могу вам пожелать только не быть таким категоричным во всём, ну и успехов :)
@@ListenIT_channel Неправда, я написал, что взял примеры (некорректных высказываний и нерелевантных примеров) из первых же двух-трёх минут ролика. И готов продолжить. Это всего лишь значит, что я двигаюсь последовательно. Например, уже на 5-й минуте автор вводит диковинный термин «нормальная форма базы данных». Такого понятия не существует. НФ бывает только у отдельного отношения. Это иллюстрирует степень владения автора терминологией.
Далее, примером «самопальной выдумки» является «нулевая нормальная форма», о которой автор поведал на 6-й минуте. Нет никакой «нулевой нормальной формы».
Затем автор ввёл понятия «основных» и «дополнительных» НФ. Это тоже выдумка, такого деления не существует. Например, BCNF ничем не менее «основная», чем другие.
Затем автор на 7-й минуте заявляет, что «третья форма устраняет достаточное количество аномалий, при этом производительность базы данных, а также удобство ее использования не снижается, что нельзя сказать о всех последующих формах». Это полностью смехотворное утверждение по целому ряду факторов. Начиная с того, что нормализация вообще никак не связана с производительностью. Одни запросы она ускоряет, другие замедляет.
Так я могу продолжать. Но в целом видно, что автор с терминологией знаком поверхностно и даёт слушателю сомнительные и даже ложные утверждения.
@@ListenIT_channel Если вы говорите, что в примере "нарушена НФ", то это легко доказать. Скажите, какая НФ конкретно нарушена. После этого я процитирую вам определение этой НФ и покажу, что оно соблюдается. По сути вы не опровергли ни одно из моих высказываний, о предоставлении которых сами же мне написали. Поскольку я прав, то фразы «вы придираетесь», «у вас явно настрой придраться», это не аргументация, а переход на эмоции. Утверждения о моём якобы "настрое" никак не заменит конструктивное развенчание моих якобы "придирок".
Одно понятно - Илон Маск скорость на своей залупе в космос летать будет.
лол, а как сделать декомпозицию к 3-ей нормальной форме если ты ее уже сделал , что бы привести таблицу ко 2 нормальной форме ??? то есть у тебя 2-я нормальная форма - это 3 таблицы допустим разбитых на части,
Спасибо! Отличный материал как и его подача!
Спасибо! Отличный материал как и его подача!