<?xml version="1.0" encoding="utf-8" ?><rss version="2.0" xmlns:tt="http://teletype.in/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:media="http://search.yahoo.com/mrss/"><channel><title>Artem</title><generator>teletype.in</generator><description><![CDATA[Artem]]></description><link>https://teletype.in/@legko_v_it?utm_source=teletype&amp;utm_medium=feed_rss&amp;utm_campaign=legko_v_it</link><atom:link rel="self" type="application/rss+xml" href="https://teletype.in/rss/legko_v_it?offset=0"></atom:link><atom:link rel="next" type="application/rss+xml" href="https://teletype.in/rss/legko_v_it?offset=10"></atom:link><atom:link rel="search" type="application/opensearchdescription+xml" title="Teletype" href="https://teletype.in/opensearch.xml"></atom:link><pubDate>Fri, 17 Apr 2026 10:03:57 GMT</pubDate><lastBuildDate>Fri, 17 Apr 2026 10:03:57 GMT</lastBuildDate><item><guid isPermaLink="true">https://teletype.in/@legko_v_it/ocVpiCZ5nPs</guid><link>https://teletype.in/@legko_v_it/ocVpiCZ5nPs?utm_source=teletype&amp;utm_medium=feed_rss&amp;utm_campaign=legko_v_it</link><comments>https://teletype.in/@legko_v_it/ocVpiCZ5nPs?utm_source=teletype&amp;utm_medium=feed_rss&amp;utm_campaign=legko_v_it#comments</comments><dc:creator>legko_v_it</dc:creator><title>Нормальные формы 4-6+</title><pubDate>Fri, 30 Dec 2022 23:31:54 GMT</pubDate><description><![CDATA[<img src="https://img1.teletype.in/files/82/0f/820f2a67-faeb-4e44-be16-7a30712fe529.png"></img>Здесь настало время рассказать про виды связей таблиц:]]></description><content:encoded><![CDATA[
  <h2 id="CSgc">Четвертая НФ</h2>
  <p id="l9hm">Здесь настало время рассказать про виды связей таблиц:</p>
  <ul id="CDd9">
    <li id="deyi">1 к 1, когда на 1 запись из первой таблице всегда соответствует только 1 запись из второй таблицы. По сути один кортеж данных, разнесенный на 2 таблицы. Пример: Таблицы сотрудников и их рабочих телефонов, при учете, что у каждого сотрудника может быть только один телефон и один телефон может принадлежать только одному сотруднику. Это неправильное отношение. В данном случае данные должны быть слиты в одну таблицу, но иногда, в особых случаях приходится делать и такое, жертвуя логикой в угоду производительности.</li>
    <li id="Gwoe">1 ко многим, ну тут просто: у одной записи в первой таблице может быть много связей в другой. В нашем случае - это таблица товаров и таблица заказов, ведь у одного вида товара может быть несколько заказов.</li>
    <li id="qeSB">многие ко многим. Вот об этом виде связей и есть четвертая НФ.</li>
  </ul>
  <p id="tQ35">Смотри, допустим, у нас появляется таблица поставщиков</p>
  <figure id="1i4v" class="m_original">
    <img src="https://img1.teletype.in/files/82/0f/820f2a67-faeb-4e44-be16-7a30712fe529.png" width="504" />
  </figure>
  <p id="cejq">И нам как-то надо их связать с таблицей товаров, чтобы всегда знать, к какому поставщику адресовать рекламацию. Но если мы напрямую свяжем эти две таблицы, то у нас получится связь многие-ко-многим, ведь у одного поставщика может быть несколько видов товаров и в то же время, один и тот же вид товара может поставляться несколькими поставщиками. То есть многие товары ко многим поставщикам. Чтобы решить эту проблему, мы должны добавить промежуточную таблицу что-то вроде Товары_Поставщики.</p>
  <figure id="UtJ7" class="m_original">
    <img src="https://img4.teletype.in/files/7a/69/7a69cf1c-b13c-4b68-8bf9-ff6104f1e9aa.png" width="243" />
  </figure>
  <p id="dkYL">Теперь обе таблицы опосредованно (через третью) связаны друг с другом и мы можем сказать, кто нам что поставил.</p>
  <h2 id="yv89">Пятая НФ</h2>
  <p id="EPuC">Это как обычно предыдущая, плюс еще некоторые условия. В нашем примере есть зависимость товара от поставщика а еще зависимость заказа от товара и поставщика. При объединении этих трех таблиц (привет, объединение множеств!), мы получим полную билеберду, не связанную с реальностью</p>
  <p id="VfQC">Так вот, чтобы отношение находилось в 5 нормальной форме, нам надо иметь однозначные кортежи данных для всех возможных вариантов поставщиков, заказов и товаров, а это еще три таблицы:</p>
  <p id="VImG">Товары_Заказа, Товары_Поставщика, Поставщики_Заказов. В общем, штука, которая может и мозг пополам поломать. Но реальность состоит в том, что как правило, при проектировании ПО, 5 НФ уже является избыточной и поэтому ее не используют так часто.</p>
  <h2 id="VKAo">Шестая НФ</h2>
  <p id="ilmQ">Про нее я тебе расскажу справочно, лично я ее не использовал ни разу за 15+ лет своей карьеры. Но то, что она есть тебе знать надо - на интервью могут спросить. Таблица находится в 6 нормальной форме, когда она не может быть подвергнута дальнейшим декомпозициям без потерь. Бред какой-то, мы уже в 5 все оптимизировали по самые помидоры.</p>
  <p id="k2ka">Так вот, собственно, почему ее очень мало где используют. Ее используют в так называемых хронологических базах, то есть БД, в которых данные хранятся не только в их текущем виде, но и хранятся их прошлые значения. И если ты такое скажешь на собесе, то или поразишь собеседующего в самое сердечко или в чувство собственной важности, так как он может этого просто не знать. И если честно, я его понимаю.</p>
  <h2 id="Yvop">Дополнительные Нормальные Формы</h2>
  <p id="7ytB">Эти 6 форм - стандартные для всех реляционных баз данных, но есть и их дополнения в виде еще двух форм:</p>
  <ul id="JWKZ">
    <li id="Psry">Форма Бойса-Кодда - это расширенная 3 НФ. Наконец-то здесь необходимо сказать про ключевые значения. Ключ - это то, по чему можно однозначно идентифицировать строку в таблице. В нашем случае есть Код товара, это и есть ключ, так как он уникальный во всей таблице. Так же, если нельзя однозначно идентифицировать запись по одному полю, то к нему добавляют второе, а иногда и третье поле, то есть необходимый минимум полей, которые помогают идентифицировать запись. Например в таблице Товары_Поставщики у нас составной ключ из двух полей, так как если мы добавим поле Статус (не знаю чего, просто статус), и оно с большой долей вероятности будет не ключевым. Так вот, эта форма Бойса-Кодда действует только в случае составных ключей, расширяя третью НФ и говорит нам, что ключевые атрибуты того самого составного ключа не должны зависеть от атрибутов не ключевых</li>
    <li id="liVB">Доменно-ключевая НФ и она скорее про ограничения по данным, которые могут быть записаны в каких-либо ячейках таблицы. И записаны там могут быть только данные из заранее определенного списка. Помимо ограничения доменов, есть еще и ограничение ключей: некоторая комбинация атрибутов может являть собой потенциальный ключ.</li>
  </ul>
  <p id="ZQfR">Все, я попытался максимально просто раскрыть достаточно сложную тему, но если у тебя есть вопросы - задавай, буду ждать комментариев! А еще - подписок!</p>

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

]]></content:encoded></item></channel></rss>