<?xml version="1.0" encoding="utf-8" ?><feed xmlns="http://www.w3.org/2005/Atom" xmlns:tt="http://teletype.in/" xmlns:opensearch="http://a9.com/-/spec/opensearch/1.1/"><title>Artem</title><author><name>Artem</name></author><id>https://teletype.in/atom/legko_v_it</id><link rel="self" type="application/atom+xml" href="https://teletype.in/atom/legko_v_it?offset=0"></link><link rel="alternate" type="text/html" href="https://teletype.in/@legko_v_it?utm_source=teletype&amp;utm_medium=feed_atom&amp;utm_campaign=legko_v_it"></link><link rel="next" type="application/rss+xml" href="https://teletype.in/atom/legko_v_it?offset=10"></link><link rel="search" type="application/opensearchdescription+xml" title="Teletype" href="https://teletype.in/opensearch.xml"></link><updated>2026-04-19T17:12:46.632Z</updated><entry><id>legko_v_it:ocVpiCZ5nPs</id><link rel="alternate" type="text/html" href="https://teletype.in/@legko_v_it/ocVpiCZ5nPs?utm_source=teletype&amp;utm_medium=feed_atom&amp;utm_campaign=legko_v_it"></link><title>Нормальные формы 4-6+</title><published>2022-12-30T23:31:54.950Z</published><updated>2022-12-30T23:31:54.950Z</updated><summary type="html">&lt;img src=&quot;https://img1.teletype.in/files/82/0f/820f2a67-faeb-4e44-be16-7a30712fe529.png&quot;&gt;Здесь настало время рассказать про виды связей таблиц:</summary><content type="html">
  &lt;h2 id=&quot;CSgc&quot;&gt;Четвертая НФ&lt;/h2&gt;
  &lt;p id=&quot;l9hm&quot;&gt;Здесь настало время рассказать про виды связей таблиц:&lt;/p&gt;
  &lt;ul id=&quot;CDd9&quot;&gt;
    &lt;li id=&quot;deyi&quot;&gt;1 к 1, когда на 1 запись из первой таблице всегда соответствует только 1 запись из второй таблицы. По сути один кортеж данных, разнесенный на 2 таблицы. Пример: Таблицы сотрудников и их рабочих телефонов, при учете, что у каждого сотрудника может быть только один телефон и один телефон может принадлежать только одному сотруднику. Это неправильное отношение. В данном случае данные должны быть слиты в одну таблицу, но иногда, в особых случаях приходится делать и такое, жертвуя логикой в угоду производительности.&lt;/li&gt;
    &lt;li id=&quot;Gwoe&quot;&gt;1 ко многим, ну тут просто: у одной записи в первой таблице может быть много связей в другой. В нашем случае - это таблица товаров и таблица заказов, ведь у одного вида товара может быть несколько заказов.&lt;/li&gt;
    &lt;li id=&quot;qeSB&quot;&gt;многие ко многим. Вот об этом виде связей и есть четвертая НФ.&lt;/li&gt;
  &lt;/ul&gt;
  &lt;p id=&quot;tQ35&quot;&gt;Смотри, допустим, у нас появляется таблица поставщиков&lt;/p&gt;
  &lt;figure id=&quot;1i4v&quot; class=&quot;m_original&quot;&gt;
    &lt;img src=&quot;https://img1.teletype.in/files/82/0f/820f2a67-faeb-4e44-be16-7a30712fe529.png&quot; width=&quot;504&quot; /&gt;
  &lt;/figure&gt;
  &lt;p id=&quot;cejq&quot;&gt;И нам как-то надо их связать с таблицей товаров, чтобы всегда знать, к какому поставщику адресовать рекламацию. Но если мы напрямую свяжем эти две таблицы, то у нас получится связь многие-ко-многим, ведь у одного поставщика может быть несколько видов товаров и в то же время, один и тот же вид товара может поставляться несколькими поставщиками. То есть многие товары ко многим поставщикам. Чтобы решить эту проблему, мы должны добавить промежуточную таблицу что-то вроде Товары_Поставщики.&lt;/p&gt;
  &lt;figure id=&quot;UtJ7&quot; class=&quot;m_original&quot;&gt;
    &lt;img src=&quot;https://img4.teletype.in/files/7a/69/7a69cf1c-b13c-4b68-8bf9-ff6104f1e9aa.png&quot; width=&quot;243&quot; /&gt;
  &lt;/figure&gt;
  &lt;p id=&quot;dkYL&quot;&gt;Теперь обе таблицы опосредованно (через третью) связаны друг с другом и мы можем сказать, кто нам что поставил.&lt;/p&gt;
  &lt;h2 id=&quot;yv89&quot;&gt;Пятая НФ&lt;/h2&gt;
  &lt;p id=&quot;EPuC&quot;&gt;Это как обычно предыдущая, плюс еще некоторые условия. В нашем примере есть зависимость товара от поставщика а еще зависимость заказа от товара и поставщика. При объединении этих трех таблиц (привет, объединение множеств!), мы получим полную билеберду, не связанную с реальностью&lt;/p&gt;
  &lt;p id=&quot;VfQC&quot;&gt;Так вот, чтобы отношение находилось в 5 нормальной форме, нам надо иметь однозначные кортежи данных для всех возможных вариантов поставщиков, заказов и товаров, а это еще три таблицы:&lt;/p&gt;
  &lt;p id=&quot;VImG&quot;&gt;Товары_Заказа, Товары_Поставщика, Поставщики_Заказов. В общем, штука, которая может и мозг пополам поломать. Но реальность состоит в том, что как правило, при проектировании ПО, 5 НФ уже является избыточной и поэтому ее не используют так часто.&lt;/p&gt;
  &lt;h2 id=&quot;VKAo&quot;&gt;Шестая НФ&lt;/h2&gt;
  &lt;p id=&quot;ilmQ&quot;&gt;Про нее я тебе расскажу справочно, лично я ее не использовал ни разу за 15+ лет своей карьеры. Но то, что она есть тебе знать надо - на интервью могут спросить. Таблица находится в 6 нормальной форме, когда она не может быть подвергнута дальнейшим декомпозициям без потерь. Бред какой-то, мы уже в 5 все оптимизировали по самые помидоры.&lt;/p&gt;
  &lt;p id=&quot;k2ka&quot;&gt;Так вот, собственно, почему ее очень мало где используют. Ее используют в так называемых хронологических базах, то есть БД, в которых данные хранятся не только в их текущем виде, но и хранятся их прошлые значения. И если ты такое скажешь на собесе, то или поразишь собеседующего в самое сердечко или в чувство собственной важности, так как он может этого просто не знать. И если честно, я его понимаю.&lt;/p&gt;
  &lt;h2 id=&quot;Yvop&quot;&gt;Дополнительные Нормальные Формы&lt;/h2&gt;
  &lt;p id=&quot;7ytB&quot;&gt;Эти 6 форм - стандартные для всех реляционных баз данных, но есть и их дополнения в виде еще двух форм:&lt;/p&gt;
  &lt;ul id=&quot;JWKZ&quot;&gt;
    &lt;li id=&quot;Psry&quot;&gt;Форма Бойса-Кодда - это расширенная 3 НФ. Наконец-то здесь необходимо сказать про ключевые значения. Ключ - это то, по чему можно однозначно идентифицировать строку в таблице. В нашем случае есть Код товара, это и есть ключ, так как он уникальный во всей таблице. Так же, если нельзя однозначно идентифицировать запись по одному полю, то к нему добавляют второе, а иногда и третье поле, то есть необходимый минимум полей, которые помогают идентифицировать запись. Например в таблице Товары_Поставщики у нас составной ключ из двух полей, так как если мы добавим поле Статус (не знаю чего, просто статус), и оно с большой долей вероятности будет не ключевым. Так вот, эта форма Бойса-Кодда действует только в случае составных ключей, расширяя третью НФ и говорит нам, что ключевые атрибуты того самого составного ключа не должны зависеть от атрибутов не ключевых&lt;/li&gt;
    &lt;li id=&quot;liVB&quot;&gt;Доменно-ключевая НФ и она скорее про ограничения по данным, которые могут быть записаны в каких-либо ячейках таблицы. И записаны там могут быть только данные из заранее определенного списка. Помимо ограничения доменов, есть еще и ограничение ключей: некоторая комбинация атрибутов может являть собой потенциальный ключ.&lt;/li&gt;
  &lt;/ul&gt;
  &lt;p id=&quot;ZQfR&quot;&gt;Все, я попытался максимально просто раскрыть достаточно сложную тему, но если у тебя есть вопросы - задавай, буду ждать комментариев! А еще - подписок!&lt;/p&gt;

</content></entry><entry><id>legko_v_it:SOiN9j6FG5j</id><link rel="alternate" type="text/html" href="https://teletype.in/@legko_v_it/SOiN9j6FG5j?utm_source=teletype&amp;utm_medium=feed_atom&amp;utm_campaign=legko_v_it"></link><title>Нормальные формы: 1-3</title><published>2022-12-29T22:33:52.283Z</published><updated>2022-12-29T22:33:52.283Z</updated><summary type="html">&lt;img src=&quot;https://img4.teletype.in/files/ba/ae/baaebcd7-dbdf-40cd-ab35-fa49b6f1f342.png&quot;&gt;В прошлой статье я говорил про то, что нужно разделять сущности и не дублировать одну и ту же информацию, либо же наоборот, в некоторых особо не удобных случаев лучше эту информацию продублировать и провести денормализацию БД. Нормализация, денормализация, что это вообще за слова такие?</summary><content type="html">
  &lt;p id=&quot;2y9I&quot;&gt;В прошлой статье я говорил про то, что нужно разделять сущности и не дублировать одну и ту же информацию, либо же наоборот, в некоторых особо не удобных случаев лучше эту информацию продублировать и провести денормализацию БД. Нормализация, денормализация, что это вообще за слова такие?&lt;/p&gt;
  &lt;p id=&quot;jalU&quot;&gt;Существует такое понятие как нормальная форма. На собесе могут спросить: сколько нормальных форм ты знаешь? Так вот: многие, очень многие говорят, что их всего 5, что в корне не верно. Это самые часто используемые 5 НФ, а на самом деле их 6 + еще две специальные нормальные формы. Если так ответишь на собесе и потом расскажешь, что это за специальные формы - собеседующий почувствует собственную неполноценность и больше не будет задавать такие вопросы, иначе кто хочет упасть в грязь лицом перед кандидатом-занудой?&lt;/p&gt;
  &lt;p id=&quot;NIhN&quot;&gt;Пока что звучит страшно. Ну как обычно, пора привыкнуть. Сейчас объясню и все станет понятнее. Поэтому давай разберемся, что стоит за этими семью нормальными формами. Сразу скажу, что всю эту информацию ты можешь найти в Википедии, но оно тебе надо?&lt;/p&gt;
  &lt;blockquote id=&quot;oEtP&quot;&gt;Переменная отношения находится в первой нормальной форме (1НФ) тогда и только тогда, когда в любом допустимом значении отношения каждый его кортеж содержит только одно значение для каждого из атрибутов.&lt;/blockquote&gt;
  &lt;p id=&quot;3F4J&quot;&gt;Разве что надо еще ввести понятие Кортеж - это упорядоченный набор значений из фиксированного количества полей, по сути - строка таблицы. В общем, объясняю по-человечески:&lt;/p&gt;
  &lt;h2 id=&quot;ybMr&quot;&gt;Первая НФ&lt;/h2&gt;
  &lt;p id=&quot;AmdM&quot;&gt;Это когда на разный набор данных есть по отдельному кортежу, а не все в одной строчки пишется для каждого элемента&lt;/p&gt;
  &lt;p id=&quot;FrQD&quot;&gt;До приведения:&lt;/p&gt;
  &lt;figure id=&quot;OGo5&quot; class=&quot;m_original&quot;&gt;
    &lt;img src=&quot;https://img4.teletype.in/files/ba/ae/baaebcd7-dbdf-40cd-ab35-fa49b6f1f342.png&quot; width=&quot;606&quot; /&gt;
  &lt;/figure&gt;
  &lt;p id=&quot;748z&quot;&gt;После приведения:&lt;/p&gt;
  &lt;figure id=&quot;PlWG&quot; class=&quot;m_original&quot;&gt;
    &lt;img src=&quot;https://img1.teletype.in/files/cb/25/cb25b3d7-18fd-4fc9-8cb1-d42e6bf7c3c4.png&quot; width=&quot;605&quot; /&gt;
  &lt;/figure&gt;
  &lt;h2 id=&quot;ZS7C&quot;&gt;Вторая НФ&lt;/h2&gt;
  &lt;p id=&quot;xZmK&quot;&gt;Это когда мы не плодим одну и ту же сущность в одной таблице в виде разных кортежей данных, как в 1НФ&lt;/p&gt;
  &lt;p id=&quot;I6j6&quot;&gt;До приведения:&lt;/p&gt;
  &lt;figure id=&quot;SG34&quot; class=&quot;m_original&quot;&gt;
    &lt;img src=&quot;https://img3.teletype.in/files/a0/12/a0129012-be98-478b-b285-bfcba0a5a181.png&quot; width=&quot;604&quot; /&gt;
  &lt;/figure&gt;
  &lt;p id=&quot;61g3&quot;&gt;После приведения:&lt;/p&gt;
  &lt;p id=&quot;6vtB&quot;&gt;Таблица товаров:&lt;/p&gt;
  &lt;figure id=&quot;9y3p&quot; class=&quot;m_original&quot;&gt;
    &lt;img src=&quot;https://img3.teletype.in/files/a0/68/a0683bd7-51f9-4220-8dd2-cfa3ee0a46c6.png&quot; width=&quot;484&quot; /&gt;
  &lt;/figure&gt;
  &lt;p id=&quot;2ZLb&quot;&gt;Таблица заказов:&lt;/p&gt;
  &lt;figure id=&quot;LRhO&quot; class=&quot;m_original&quot;&gt;
    &lt;img src=&quot;https://img1.teletype.in/files/05/ce/05ce7ac8-9611-4b24-95e3-1469933c0e0d.png&quot; width=&quot;243&quot; /&gt;
  &lt;/figure&gt;
  &lt;h2 id=&quot;BAjD&quot;&gt;Третья НФ:&lt;/h2&gt;
  &lt;p id=&quot;Bh7i&quot;&gt;Тут посложнее, в третьей НФ мы должны избавиться от транзитивных зависимостей. В нашем примере такая зависимость есть в таблице товаров. Зависимости тут такие: если товар связан со складом, а склад связан со временем работы, то товар связан со временем работы&lt;/p&gt;
  &lt;p id=&quot;xhuQ&quot;&gt;До приведения:&lt;/p&gt;
  &lt;figure id=&quot;QnY8&quot; class=&quot;m_original&quot;&gt;
    &lt;img src=&quot;https://img2.teletype.in/files/5a/0f/5a0fce05-6153-448e-86e5-f7bdafbad936.png&quot; width=&quot;485&quot; /&gt;
  &lt;/figure&gt;
  &lt;p id=&quot;73QT&quot;&gt;После приведения:&lt;/p&gt;
  &lt;figure id=&quot;9tRd&quot; class=&quot;m_original&quot;&gt;
    &lt;img src=&quot;https://img2.teletype.in/files/9e/03/9e038806-41b9-4068-95ce-5f11c131fef6.png&quot; width=&quot;366&quot; /&gt;
  &lt;/figure&gt;

</content></entry></feed>