Ребят, а кто-то может подсказать, как такие зависимости решаются через

НФ в БД?

То есть есть клиенты, которые могут переподписывать договоры - в данный момент активный только один договор.
Тип выше норм решение?

Приемлемо. Не очень понятно, почему понятие "активный" это не элемент всяких статусов в таблицэ ClientOffer -- ну, то есть я понимаю, что так проще по ресурсам обеспечить уникальность, зато возникает проблема, что LastContract можэт не оказаться в ClentOffer. Что, впрочем, само по себе мелочи -- а важнее, конечно, что статус clientoffer размазаывается по нескольким таблицам ни за что ни про что. Но в общем -- рабочая схема.

Ну тип если проводить аналогию на интернет провайдера, где клиент может переподписывать договора. Хм, предлагаете убрать LastContract из Client, и оставить только ClientOffer и тогда искать просто по активному? Ну да, так кажется логичнее, спасибо. Для эффективности можно разделить ClientOffer на историческую таблицу и активную тогда.

Что-то я сомневаюсь, что у вас скоро появится столько записей, чтобы это разделение имело смысл.

Та не появится вообще, понял. Просто тренируюсь проектировать БД под разные предметные области в 3+ НФ, чтобы нормально на них писать запросы было ) Спасибо 😄

А почему приемлимо? Вас разве не смущает 100500 связей contact?

У клиента не может быть больше одного договора? И еще, такие случая решаются обычно каким-нибудь scd

Видимо, может, ок. Поэтому лучше вынести во вторую таблицу ClientOffer, да. Или вообще соеденить ClientOffer и Offer, при этом вынести часть данных в другой тип. Про scd спасибо, почитаю.

Нет, не смущает. У меня вообще обычно в схемах есть поля, на которые есть 100500 связей из разных таблиц. (Ну, или я просто безстыдник, да). Хотя в данном случае это, конечно, не слишком красиво и не слишком удобно.

Ну так проектирование "в 3+ НФ" идёт от функциональных зависимостей (а какие они в этом случае, мне лично не очевидно). И то же самое касается вопросов "почему не отвечает 3НФ?" и т.п.

У вас судя по выделенным первичным ключам БД находится уже 5 НФ. По причине того, что неключевых атрибутов везде не менее одной штуки - не задумываясь можно говорить , что это 3НФ. Потому что приведение до 3НФ решает проблемы зависимостей между неключевыми атрибутами. Далее Там, где первичный ключ не более двух атрибутов, также можно смело говорить , что это 5НФ. Так как приведение до 5НФ решает проблемы зависимостей между ключевыми атрибутами.

А вот правильно ли выделен первичный ключ в таблице КлиентЗаказ зависит от предметной области. Такой ключ как у вас говорит о том, что один клиент может делать много Заказов. И! Это важно, И один заказ могут делать несколько клиентов. Это так? Если в заказе может быть учтён только один клиент, то достаточно поле Клиент вставить в таблицу заказ и связать их (Клиента и Заказ) один ко многим. Это не вопрос нормализации, а вопрос концептуального проектирования и анализа предметной области. Что должно выполняться ДО нормализации то бишь логического проектирования. И что обычно разработчики игнорят

Напомните, в какой нф наличие суррогатного ключа обязательно, вместо составного?

> У вас судя по выделенным первичным ключам БД находится уже 5 НФ. Эээ... Вы понимаете, что так рассуждать вообще нельзя?! К примеру, если есть отношение tournament_winners(tournament, year, winner) (в котором ФЗ: tournament, year → winner), то его "преобразование" в table1(tournament); table2(year); table3(winner); вовсе не приводит его в 5NF, а просто уничтожает эту ФЗ (т.е. это уже просто неправильная модель предметной области)! > не задумываясь можно говорить , что это 3НФ. Лучше не говорить не задумываясь. А ещё лучше — перечитать теорию нормализации. ;) > Далее Там, где первичный ключ не более двух атрибутов, также можно смело говорить , что это 5НФ. Хмм... а это Вы откуда взяли?!

А что тебя тут смущает?

Разве. Я думал максимальная декомпозиция

я вас тоже не поняла. вот после "эээ" я разве предлагала делить на таблицы по одному атрибуту :) декомпозицию отношений надо проводить аккуратно чтобы не потерять связей, по этой причине некотроые атрибуты будут дублироваться. Чтобы эту самую исходную связь сохранить. ответ на "Хм.." оттуда, что при приведении к НФБК, 4НФ и 5НФ нарушение условиям соответствующим нормальным формам отыскивается ТОЛЬКО в сложных первичных ключах НФБК каждый детерминант является возможным ключом. Несоответстве будет ТОЛЬКО там, где есть НЕСКОЛЬКО ПЕРЕСЕКАЮЩИХСЯ ВОЗМОЖНЫХ КЛЮЧЕЙ. поскольку про ВОЗМОЖНЫЕ ключи вообще все забывают а помнят только о первичном, то также могу сказать с уверенностью в 100%, что 3НФ= НФБК. ПЕРЕСЕКАЮЩИЕСЯ ВОЗМОЖНЫЕ КЛЮЧИ - читай должно быть не менее 2х ключей по 2 атрибута. (да здесь 2 атрибуа, хоть я и писала про более 2х, но пример не тот случай, там нет нескольких возможных ключей) 4НФ: ИЩЕМ многозначные нетривиальные зависимости, а они будут ТОЛЬКО внутри ключа состоящего из 3х атрибутов. 5НФ: зависимости соединения, это года СЛОЖНЫЙ ключ может разделить на несколько помельче без потери смысла, а это значит, что эти несколько поменьше мы должны мочь соединить вместе, а это значит как минимум в новых ключах как минимум должно быть по два атрибута. Ваше возмущение праведно и радует, НО я не противоречу ни одному определению, я описала случаи, когда бессмысленно искать те или иные зависимости, потому что их там быть не может

На мой взгляд. Нормально. Но, как сказала Оленька, дБ не лошадь в вакууме, надо знать предметную область и что требуется.

Если я не права приведите пример таблицы с одним первичным атрибутом и одним непервичным, которая не будет в 5НФ

Как сказала Оленька все зависит от предметной области :)

а где такое утверждается?

> я вас тоже не поняла. Посыл был в том, что наличие вообще каких угодно ключей в множестве таблиц, которое некорректно нормализовано, не говорит вообще ни о чём. > вот после "эээ" я разве предлагала делить на таблицы по одному атрибуту :) Это была аналогия. Вы её не поняли, или преднамеренно придираетесь к словам? ;) > нарушение условиям соответствующим нормальным формам отыскивается ТОЛЬКО в сложных первичных ключах Но обратное неверно, понимаете? Вот в приведённом мной примере таблицы/отношения не в 4/5/6NF, потому что я "потерял" ФЗ — и они уже не в 3NF! Т.е. если Вам дали произвольные таблицы с любыми ключами, по ним одним невозможно (не считая явных нарушений 1NF и т.п. крайних случаев) определить, в каких NF они находятся, если Вы не знаете ограничений предметной области. > поскольку про ВОЗМОЖНЫЕ ключи вообще все забывают Да ладно Вам. ;) > Ваше возмущение праведно и радует, НО я не противоречу ни одному определению Вы их просто применяете неверно / не по делу. :(

Неочевидные функ зависимости некоторые, поэтому не могу ответить про НФ

Да, кстати. Херня чета

Я уже приводил подобный пример. Если Вам нужно именно про 5NF, то: К примеру, есть отношение tournament_winners(tournament, year, winner) (в котором ФЗ: tournament, year → winner). "Преобразуем" его в year_winners(year, winner, PK(year)) и who_cares(tournament, year) — и вот формально что Вы просили... только это "мусор", который уже не в 3NF (и мы это знаем только потому, что исходная ФЗ тут потеряна!).

на каком основании вы его так поделили. я такого не просила

Захотел и поделил. Вы хотели "приведите пример таблицы с одним первичным атрибутом и одним непервичным, которая не будет в 5НФ" — и получили его.

Уважаемый Yaroslav ваш стиль общения не делает вас правым... так и не пойму где вы углядели противоречие и что от меня хотите... Давайте берем tournament_winners(tournament, year, winner) да будет вам известно, что прежде чем тыкать в ФЗ , надо найти ПК.... А потом уже приводить к НФ последовательно, к какой хотите.... надеюсь согласитесь, что это отношение в 1НФ, раз называете его отношением? Чтобы отношение было в 2НФ нужно что? нужно проверить, что каждый неключевой атрибут зависит от ВСЕГО ключа. Что это значит? а это значит, что если в вашем исходном отношении, состоящем из трех атрибутов, первичный ключ - это все три атрибута РАЗОМ, то неключевых нет вообще и отношение находится в 2НФ аналогично и в 3НФ (достаточно вспомнить что там надо избавиться от транзитивных зависимостей)... Если предполагать, что первичный ключ - два атрибута, то неключевых - один. Он стопудово зависит от всего первичного ключа, иначе это был бы не первичный ключ, если один единственный неключевой вдруг определялся бы его частью. согласитесь? то есть снова 2НФ, аналогично, один единственный неключевой атрибут зависит от всего ПК и транзитивных зависимостее быть не может => 3НФ Если предполагать, что ПК - один атрибут, то? части ключа быть не может => 2НФ. вот возможно будет транзитивная может, например: year -> tournament -> winner вот пожалуйтса, тогда и делим на: (year , tournament) и (tournament , winner)

разбирать 4НФ и 5НФ или достаточно?

> Уважаемый Yaroslav ваш стиль общения не делает вас правым... Безусловно. Но стиль общения у меня портится не просто так, а после неоднократных объяснений вот этого: > так и не пойму где вы углядели противоречие и что от меня хотите... с моей стороны... которые Вы, у меня такое впечатление, не читаете. :( > да будет вам известно, что прежде чем тыкать в ФЗ , надо найти ПК.... Не будет — это просто неправда, извините. При таком подходе PK (на самом деле, потенциальные ключи) выводятся из ФЗ, а ни в коем случае не наоборот. > А потом уже приводить к НФ последовательно, к какой хотите.... И, опять-таки, это только один из подходов. Понимаете, у каждой стадии нормализации есть цель (грубо говоря, 3NF "разбирается" с Functional Dependencies, 4NF — с Multivalued Dependencies, 5NF — с Join Dependencies). > Давайте берем tournament_winners(tournament, year, winner) Давайте. > что если в вашем исходном отношении, состоящем из трех атрибутов РАЗОМ А зачем Вы вообще рассматриваете неправильный PK? Я явно указал ФЗ для этой модели, из чего следует, что PK — (tournament, year). Поэтому эту часть я пропускаю. > Если предполагать, что первичный ключ - два атрибута, то неключевых - один. Да-да, всё это так. И теперь Вы в очередной раз как будто не прочитали мной написанное. :( И ещё раз (да сколько можно-то! ;) ): > Преобразуем" его в year_winners(year, winner, PK(year)) и who_cares(tournament, year) — и вот формально что Вы просили... только это "мусор", который уже не в 3NF (и мы это знаем только потому, что исходная ФЗ тут потеряна!). Да, кстати... Вы подчёркнутое прочитали в первый раз, хотя бы!? Тут прямым текстом указано, что я уже знаю, что исходное отношение было в 3NF, не так ли? Зачем Вам было "расписывать" проверку этого? ;) > разбирать 4НФ и 5НФ или достаточно? Да, разберите. Разберите то, что я Вам уже в разных формулировках писал, наконец! Потому что по факту, Вы пока не разобрали ничего, извините. :(

>Не будет — это просто неправда, извините. При таком подходе PK (на самом деле, потенциальные ключи) выводятся из ФЗ, а ни в коем случае не наоборот. Ну да, ПК - это тоже ФЗ, но еще раз, определение 2НФ: каждый неключевой атрибут функционально полно зависит полно от ПК... нет?

> А потом уже приводить к НФ последовательно, к какой хотите.... И, опять-таки, это только один из подходов. Понимаете, у каждой стадии нормализации есть цель (грубо говоря, 3NF "разбирается" с Functional Dependencies, 4NF — с Multivalued Dependencies, 5NF — с Join Dependencies). и? что опять не так? да, ФЗ, многозначные зависимости, зависимости соединения, я это и писала по-русски только ... выше...

Я просто "сдеру" определение, пожалуй (потому что, с моей точки зрения, к обсуждаемой теме это совсем не относится): 1. It is in first normal form. 2. It does not have any non-prime attribute that is functionally dependent on any proper subset of any candidate key of the relation. A non-prime attribute of a relation is an attribute that is not a part of any candidate key of the relation. 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.

Пожалуйста, перечитайте то, что я Вам писал. У меня такое ощущение, что Вы не хотите понимать, а хотите только спорить, извините. Ещё раз, всё это началось с: У вас судя по выделенным первичным ключам БД находится уже 5 НФ. По причине того, что неключевых атрибутов везде не менее одной штуки - не задумываясь можно говорить , что это 3НФ. Потому что приведение до 3НФ решает проблемы зависимостей между неключевыми атрибутами. Далее Там, где первичный ключ не более двух атрибутов, также можно смело говорить , что это 5НФ. Так как приведение до 5НФ решает проблемы зависимостей между ключевыми атрибутами. И это (Вами написанное!) просто совершенная чушь! Я пытаюсь Вам объяснить, что то, что Вы не понимаете, почему это так — это Ваша проблема, понимаете?

как бы смешно это не звучало, но только что столкнулся, похоже, судя по проблеме, с аналогичной структурой связи у rebrain сервиса 😂🙈