Изучили вторую нормальную форму? Отлично, так держать! Но этого не достаточно для того, чтобы проектировать БД, мой друг! Самое время изучить 3-ю НФ и закрепить материал с видео о секретах нормализации (ссылки в описании). Успехов в обучении!

@Dirkiz

4 жыл бұрын

Отличный материал, спасибо!

Блин, ну есть же те, кто может рассказать понятно, а не как преподы в универе.

Блин, нашла канал, и очень расстроена, что новых видео не было уже год 😢 надеюсь, ты ещё читаешь новые комментарии, потому что хочу сказать большое спасибо 😊

Прекрасная серия уроков: всё доходчиво и непринуждённо представлено - спасибо большое!

Наконец-то кто-то идеально продемонстрировал составной первичный ключ, благодаря чему стало понятно что же такое 2НФ. Огромное спасибо!!!

Благодарю за урок!

Отличное видео! Спасибо!

Спасибо! Молодец! Очень всё понятно!!!

а почему на 2:19 не создать полностью уникальный идентификатор, то есть автоинкремент, как и говорилось? почему именно два инкремента нужно?

Спасибо за урок! Все очень просто и доходчиво!

Спасибо. Очень все понятно. В универе бы так объясняли в свое время

Спасибо за понятные объяснения!

Отлично объяснили, было полезно, спасибо!

Спасибо!

Спасибо, все доходчиво и понятно

Наконец-то доступным языком, спасибо!

Спасибо!!!

Очень хорошо и доступно! Больше вам просмотров!

@JohnnySvarog

6 жыл бұрын

большое спасибо! а вам - успехов в обучении!

@user-mh4cv1jy2s

2 жыл бұрын

@@JohnnySvarog а что значит скалярное значение?

@karinalazareva6123

Жыл бұрын

@@user-mh4cv1jy2s скалярное значение = одно значение из списка. В видео пример с ингредиентами, то есть, есть список ингредиентов (мука, соль, сахар и тд.) из которых можно готовить различные блюда.. В соответствии с 1НФ в таблице необходимо писать одно значение каждому продукту: шарлотка - мука, шарлотка - соль, шарлотка - сахар..

Большое спасибо! Всё чётко и понятно. Изучаю Д.Л.Осипова "Технологии проектирования БД". Ваш видеокурс - прекрасное наглядное дополнение для лучшего усвоения материала!

блин, да ты крут! лайк подписка, все по списку

Спасибо

супер!

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

@wob03omsan38

3 жыл бұрын

Просто там составной ключ, состоящий из 2-ух внешних, но сочетание их уникально: обычная практика

Какая музыка играет в фоне?

А если к примеру один поставщик нам поставляет несколько ингредиентов ?)

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

@mossdi

5 жыл бұрын

"Описывает ключ" означает, что по идентификатору вы можете получить строку из таблицы, в которой будут поля с атрибутами, которые привязаны исключительно к этому идентификатору. Если же оставить в исходной таблице столбец с ингредиентами, то можно нарваться на неприятности. К примеру вы захотите изменить Мука в/с на Мука высшего сорта, и тогда придется делать это во всех строчках, где в качестве атрибута мы имеем Мука в/с. А если мы храним это в отдельной таблице, то только там и надо будет сделать изменения. **************************************** SELECT * FROM Products LEFT JOIN ProductIngredients ON (Products.ProductID = ProductIngredients.ProductID) LEFT JOIN Ingredients ON (ProductIngredients.IngredientsID = Ingredients.IngredientsID) WHERE ProductID = 1;

@JohnnySvarog

5 жыл бұрын

Отличный вопрос! Чтобы правильно сформировать сущность, нужно провести хороший анализ данных, предусмотреть варианты использования таблицы, предвидеть возможные аномалии и прочие подводные камни. Описывать ключ - значит иметь прямое отношение к этому ключу, зависеть от него функционально. Вообще, при нормализации используют понятие естественного ключа. Id - это искусственно созданный ключ, которого нет в природе, а следовательно - и в логической модели данных, он появляется только на физическом уровне (в СУБД). В этом видео Id приведены только для того, чтобы показать, как будет выглядеть таблица в СУБД. Поехали дальше =). Ключ должен однозначно идентифицировать какую-то сущность. Допустим, мы просто добавим в таблицу уникальный id, а остальное оставим как есть. При таком раскладе напрашивается вопрос: что есть этот Id с точки зрения логики? Если мы сделаем выборку SELECT ProductName, Ingredient FROM Tbl WHERE id = 1, что мы получим? Продукт с идентификатором 1? Ингредиент с идентификатором 1? Судя по всему - Ингредиент + Продукт с идентификатором 1. Тогда ингредиент + продукт - это что за двухглавый зверь такой? Можно ли для этого хотябы название придумать? Выходит, что это "Таблица пар ингридиент-продукт". Звучит довольно странно. Если пройти по столбцам, то получаетя, что - ProductName - описывает название некоего Продукта; - Ingredient описывает наименование некоего Ингредиента; - Id - описывает, как мы выяснили, некую "пару Ингредиент-Продукт". Выходит, что ключ живет сам по себе, также как и остальные столбцы. А должно быть, чтобы они логически были связаны. Движемся дальше, допустим, нам нужно изменить наименование продукта "Пирожок с капустой" на "Пирожок с кислой капустой". Как будет выглядеть запрос? UPDATE Tbl SET ProductName = 'Пирожок с кислой капустой' WHERE ProductName= "Пирожок с капустой". Выходит, что у продукта ключ - вовсе не Id, а ProductName, потому что, если менять по ID, то поменяются имена только у части продуктов, которые должны поменяться. Вот вам аномалия обновления. Такая же ситуация и с ингредиентом. Теперь попробуйте то же самое сделать для таблиц Product, Ingredients, которые получились в конце видео. Мы знаем, что у пирожка с капустой есть свой уникальный Id, по которому ему можно найти. Он равен 1. И если мы обновим запись по этому Id, то у ВСЕХ пирожков с капустой поменяется наименование. Чтобы получился более наглядный пример, то представьте лучше таблицу Физ. лицо: Индивидуальный номер(как в паспорте), Имя, Фамилия. Вот тогда станет понятнее. Если вы в паспортном столе сообщите свой индивидуальный номер, то вам скажут точно вашу фамилию и имя, потому что по этому номеру у них всего одна единственная запись. И ваши ФИО - это атрибуты, которые функционально зависят от ИН, другими словами - описывают его. К сожалению, при проектировании БД не всегда можно найти реально существующий уникальный номер, поэтому его создают искусственно. Но в вашей базе для вашей сущности он должен быть так же как ИН в паспортном столе - уникальным и неизменным, для всей системы. По нему таблица будет связана с другими сущностями. Это обеспечит целостность данных и исключит дублирование и прочие неприятные вещи. Ключ - это гарант. Такая штука, по которой 100% можно отличить один предмет от другого. К примеру, если заходишь в деревню, прашиваешь - "где генка живет"? а в ответ - "какой Генка? Кудрявый, что ли?" - значит, в рамках деревни вместо ИИН вполне можно было бы использовать ключ "Погоняло" со значением "Кудрявый" + "Имя" со значением "Генка". Поставить базу данных в сельсовете, и все бы отлично работало до тех пор, пока бы не появился второй Генка Кудрявый, либо пока деревню к какому городу не присоединили, а так как такая вероятность появления есть, то следует выбрать другой ключ, и снова все сводится к ИН. В двух словах - как-то так.

@JohnnySvarog

5 жыл бұрын

Пока писал, удалили вопрос =) Жаль! Был вопрос: "если добавить в таблицу ProductIngredients еще и цену, то можно ли считать, что все три столбца образуют первичный ключ и таблица находится во 2 НФ?" то есть: ProductName, IngredientName, Price? В учебниках по нормализации, возможно скажут, что можно рассматривать "ProductName, IngredientName, Price" как один составной ключ (даже правильнее - ProductName, IngredientName - составной ключ, а Price - обычный не ключевой атрибут), в таком случае, отношение будет не только во 2 НФ но также и в 3НФ (а может и выше, нет времени анализировать), и будет показывать, во сколько фабрике обошелся ингредиент по себестоимости, для каждого продукта. Можно согласиться с тем, что 2НФ не будет нарушена, но только при одном условии: помните, что ключ таблицы - это такая вещь, которая может только добавляться или удаляться, но никак не изменяться. Другими словами, если есть гарантия, что ProdutName, IngridientName никогда, ни при каких условиях не будут меняться - то да, ок. Но что делать, если нужно поменять хоть немного наименование продукта? Если такая возможность МОЖЕТ когда-либо понадобиться в вашем приложении (завтра, через год или в любое время, пока программу не спишут за ненадобностью), то следует пересмотреть структуру. В этом случае, правильная таблица будет - ProductId, IngredientId, Price. Хотя, это уже вопрос даже не нормализации, а больше проектирования БД и анализа данных.

@Max-wn2gd

5 жыл бұрын

@@JohnnySvarog спасибо за подробнейший ответ!

@aleksandr977

4 жыл бұрын

@@JohnnySvarog "Если вы в паспортном столе сообщите свой индивидуальный номер, то вам скажут точно вашу фамилию и имя, потому что по этому номеру у них всего одна единственная запись. И ваши ФИО - это атрибуты, которые функционально зависят от ИН, другими словами - описывают его." А если есть полный однофамилец - значит по ФИО будет две записи с двумя ИНН. Т. е. скорее всего, как и для деревни, в налоговой используется еще какой-то идентификатор? И еще, в этом случае с однофамильцем, значит ли это что, атрибуты не "описывают первичный ключ целиком"? формулировка режет слух, может с непривычки?(((

У тебя нет видео которая объясняет эту тему вот так F = {A→C, BC→AG, BG→E, CE→B, D→H, G→A}? То что ты рассказал очень хорошо понял, но вот эту систему объяснения по которой у меня экзамен будет через 2 недели, и вопросы будут поставлены как я описал выше, никак понять не могу, если бы было как на видео то даже не волновался бы

@Sharp221

3 жыл бұрын

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

Разве можно сказать про таблицу ingredients что она приведена к 2НФ? Ведь, vendor contact не описывает пк вообще никак, а уловие 2НФ, все атрибуты должны описывать пк целиком.

@JohnnySvarog

5 жыл бұрын

В случае второй формы, трактовать нужно так: а) первичный ключ ДОЛЖЕН БЫТЬ. Проверяем себя: есть? есть! б) все атрибуты должны описывать первичный ключ ЦЕЛИКОМ, а НЕ ЧАСТЬ первичного ключа. Здесь смотрим, сколько столбцов в ключе, если больше одного - то проверяем, нет ли каких-либо зависимостей от части ключа. Если один - то зеленый свет. Что касается Vendor contact: описывать-то ключ - он описывает, в том плане, если id 2, то мы знаем, что, в случае чего, то писать на мейл 2@example.com. А вот дальше - вы правы, есть неоднозначность. В зависимости от того, какой смысл вкладывается в понятие contact, эта таблица может даже не соответствовать 1 НФ, не говоря о второй (этот пример разбирается здесь: kzread.info/dash/bejne/oItqzZeomrincbg.html). А вот тот факт, что VendorContact зависит от другого неключевого атрибута - это уже критерий 3НФ (ссылка также в описании).

@user-lc2yc8of2m

5 жыл бұрын

@@JohnnySvarog спасибо за ответ

Не понимаю восторга комментаторов, т.к. лектор, похоже, сам не до конца понимает теорию. Вернее, понимаю намерение объяснить "на пальцах" сложные для кого-то вещи и снимаю шляпу, но не могу удержаться от замечания. Дело в том, что таблица, перекочевавшая их первого урока про 1НФ, уже находится во 2НФ: 1) Таблица находится в 1НФ (показано в предыдущем уроке) 2) У таблицы должен быть первичный ключ (здесь есть, это составной ключ (Product_Name, Ingredient) - натуральный ключ) 3) Все атрибуты должны описывать первичный ключ целиком, а не какую-то часть первичного ключа (здесь вся таблица по сути состоит только из первичных составных ключей, нет неключевых атрибутов, как и у третьей таблицы в финальном примере) Требование, что первичный ключ должен состоять только из целочисленных значений, существует только в голове автора. Тип атрибутов составного ключа может быть любым. ru.wikipedia.org/wiki/%D0%9F%D0%B5%D1%80%D0%B2%D0%B8%D1%87%D0%BD%D1%8B%D0%B9_%D0%BA%D0%BB%D1%8E%D1%87 Наличие суррогатных ключей, которые потом добавил автор, совсем не обязательно, это - вопрос удобства и эффективности, но в данном случае не имеет отношения к нормализации ru.wikipedia.org/wiki/%D0%A1%D1%83%D1%80%D1%80%D0%BE%D0%B3%D0%B0%D1%82%D0%BD%D1%8B%D0%B9_%D0%BA%D0%BB%D1%8E%D1%87 А вот когда он добавил в эту таблицу атрибуты Product_Id и Ingredient_Id, эта таблица перестала соответствовать 2НФ, и дальнейшие рассуждения имеют смысл.

@andrewtvorogov691

3 жыл бұрын

именно. таблица изначально во второй форме. в финале видео заменили ее на аналог из id.

@wob03omsan38

3 жыл бұрын

Вот да. Ну, понятно, это сделано для того, чтобы как можно проще всё объяснить. Ещё чисто субъективно не нравится слово "описывать", скорее "зависеть" они должны или "относиться".

я б таки хотел уточнить про таблицу привязки, она по правил не во 2-ой нормальной форме а в 1-ой, у нее нет ее собственного primary key, или я не прав?

@JohnnySvarog

4 жыл бұрын

у product_ingredients ключ - [Ingredient_id, product_id]

@makam6750

4 жыл бұрын

@@JohnnySvarog но ведь, когда в таблице есть primary key,, значения не могут посторяться. Выходит это внешний ключ?

@JohnnySvarog

4 жыл бұрын

@@makam6750 Когда мы говорим о нормализации, мы рассматриваем каждую таблицу (отношение) в отдельности. Внешних ключей здесь нет. Понятие "внешний ключ" возникнет, когда вы из этих нарисованных на бумаге таблиц создадите физические таблицы в БД и свяжете их через foreign key. Ingredient_Id будет foreign key с ссылкой на primary key таблицы ингредиентов, Product_Id- на таблицу продуктов. Вместе эти два бравых товарища образуют составной primary key таблицы. Условно, навесят на него CONSTRAINT Products_Ingredients_PK PRIMARY KEY (Product_ID, Ingredient_ID). И все.

Не пойму, чем первая таблица в начале, отличается от третей в конце?

@JohnnySvarog

4 жыл бұрын

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

У таблицы связей продуктов и ингридиентов разве не должно быть авто инкремента?

@Spin-2O

4 жыл бұрын

Мне тоже так думается, что должен быть отдельный первичный ключ, иначе это не 2НФ. Ведь ID продукта или ингредиента можно рассматривать не только как ключевые поля, но и как поля данных.

@JohnnySvarog

4 жыл бұрын

Автоинкремент - это физический уровень базы данных. Нормализация выполняется на логическом уровне, ей интересны лишь таблицы и связи между ними. Но даже в физической БД помимо полей Ingredient_Id, Product_Id дополнительных полей не нужно.

@ZEXthn

2 жыл бұрын

Ingredient_id и product_id это и есть автоинкременты.

Хоть кто-то нормально все обьяснил. Ф то умников много, а сказать толком ничего не могут. Спасибо!

что здесь атрибуты? атрибут == значение каждой отдельной ячейки? UPD: А, атрибуты это столбцы.. Правильно я понял?

@JohnnySvarog

4 жыл бұрын

в общем, да атрибуты сущности - это столбцы таблицы. Атрибуты - термин из Entity-Relationship

А вот за "Весёлого не***а" по нынешним временам может и прилететь;)

We Beiu

Абоба

я нихуя не понял

Веселый негр хывахывхфахвппхавыазрпхваызп

переделывай

Скомкано но понятно.