svnvladНеприятности начинаются, когда у нас каскад из 3 или более зависимых сущностей. Тогда первичный ключ обязан целиком перекочевать в дочернюю сущность, т.е. в дочерней таблице появляются поля, которых в ней не было (id1, id2, id3, ...). И если для доступа к полю 3-ей таблицы в неидентифицирующем отношении мы обошлись бы двумя JOIN-ами
то в идентифицирующем по всем правилам необходимы 3 JOIN-а, т.к. атрибут id1 из первой перекочует в область первичного ключа 3-й таблицы!
По каким таким правилам ? Транзитивность уже отменили ? Если A=B и B=C, то A=C.
А неприятность при отказе от идентифицирующих связей можно получить запросто, конкретно просадив производительность определенного типа запросов. Например, пусть мы имеем 3-уровневый каскад, T1->T2->T3. В случае агрегирующих запросов на самом нижнем уровне(T3) относительно самого верхнего(T1), надо будет в запрос обязательно включать в слияние промежуточный уровень(T2). В случае же идентифицирующих связей достаточно слияния между T1 и T3, а то и вовсе обойтись без слияния, если интересует агрегация по заранее известному T1.ID.

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

Cane Cat FisherМне не нравится одна вещь.IMHO, одна из главных заблуждений многих проектировщиков заключается в уверенности, что нормализация каким-либо боком имеет отношение к оптимизации хранения и/или получения данных. Это не совсем так, я бы даже сказал, совсем не так. Её главная задача состоит в стремлении избежать аномалий данных, что может привести, если не к потере, то к недостоверности хранимой информации.
Сам процесс нормализации должен начинаться, по большому счету, не с выделения сущностей и установки между ними связей. А, скорее, наоборот, берется некий массив данных предметной области, представимый в табличной форме, а далее, опираясь на понятие нормальных форм, он анализируется на предмет возможного появления аномалий. Если анализ не обнаружил угрозы их появления, то фактически на этом нормализация и закончена. В противном случае, принимаются меры, чтобы устранить шансы их(аномалий) проявления. Как правило, это ведет к разбиению исходной таблицы на некоторое подмножество таблиц, взаимосвязанных друг с другом какими-то наборами атрибутов, и в каждой из которых, по возможности, проявление аномалий невозможно. Если какая-либо дочерняя таблица по прежнему имеет опасность появления аномалий, то процесс повторяется, но уже в применении к дочерней таблице. И так рекурсивно, до тех пор, пока нас не удовлетворит результат, в виде множества таблиц и связей между ними.
Таким образом, можно сказать, что связи являются следствием подобного разбиения, но не наоборот. И тогда "идентифицируемость" диктуется самим процессом нормализации, а не подгонкой типа потенциально возможных связей под существующий набор произвольно выбранных сущностей, как это, чаще всего, происходит на практике.

IMHO:
Насколько я понимаю, практический подход в значительной степени определяется популярностью объектно-ориентированного подхода(ООП), который никоим образом не является синонимом реляционной модели данных(РМД), который, по большому счету, идет от данных, а не от сущностей. И сущность в ООП, в общем случае, совсем не обязательно равна таблице в РМД, так как выбирается программистом-проектировщик исходя из своих, зачастую, искаженных понятий о предметной области, вплоть до полной абстракции оных. Тогда как РМД, отталкиваясь от понятия "данных", представимых в табличной форме, опирается на формализованный математический подход и выражает его(понятие) через понятийный аппарат теории множеств.

MasterZivЭто - да, но всё же говорить, что "нормализация (не) имеет отношения к
оптимизации хранения и/или получения данных" ни в коем случае нельзя.
Она имеет непосредственное отношение и к тому, и к другому.Можно, ибо отношение не только косвенное, но и неоднозначное. То, что в процессе нормализации может происходить уменьшение объема хранимых данных, можно считать дополнительным бонусом. Но может и не происходить, а может, для некоторых видов оптимизации, понадобится денормализация. Поэтому настаиваю, что нормализация в буквальном смысле не имеет никакого отношения к оптимизации, а предназначена только для устранения возможных противоречий(аномалий) в модели данных.
Некоторые виды аномалий действительно имеют отношение к дублированию данных, и, естественно, при их устранении естественным образом будет происходить "уплотнение" данных. Идеалом считается БД, в которой каждый факт предметной области будет хранится в одном-единственном месте. Но это будет следствием нормализации, а не оптимизации. Более того, сама по себе, нормализация имеет отношение к логическому проектированию, и в ходе его выполнения проектировщики не должны заниматься оптимизацией, впадая в грех так называемой "преждевременной оптимизации". Сначала надо сделать "правильную" БД, а потом уже думать об оптимизации в рамках физической реализации. И вот тогда-то все и начинается, выбор типов данных, добавление суррогатных ключей, конструирование индексов и т.д. и т.п.

AK-74UВы не могли бы более развернуто изложить вашу точку зрения о влиянии ООП на практику работы с реляционными моделями? Очень интересно.Ничего интересного. Достаточно посмотреть, как проектируют программисты, грубо говоря, "от сохи", т.е., те, кто никогда серьезно не занимался до этого проектированием БД и не читал литературу на эту тему. Они обычно пытаются мыслить в том же духе классов, свойств, агрегации, etc. А до этого точно так же мыслили записями. Т.е., их путь идет не от той информации, которую они будут обрабатывать, а от того, какие сущности(классы) они "увидели", не зная, да и не пытаясь охватить взглядом целостную модель.
Нормальное проектирование подразумевает предварительный этап плотного знакомства с предметной областью, выделения информационных потоков, включая их взаимодействие и преобразование. И только после такого анализа можно садиться за "конструирование реальности", выделяя информационные единицы и тестируя их на аномальность. Это очень грубое, схематичное, описание процесса, более внятно это описано во всякого рода книгах на тему проектирования БД. Несмотря на отдельные разногласия, в целом они говорят об одном - прежде чем проектировать, изучите ту предметную область, для которой собираетесь строить модель. И тогда не придется каждый раз перестраивать БД и переписывать код клиента, когда всплывут новые, неозвученные ранее, пожелания заказчика.
Обратный путь, характерный для практиков, ведет к итерационному процессу, когда после очередной итерации выясняется, что "классификация" выполнена неполно, так как не учитывает тех или иных нюансов предметной области, типичный вариант "из-за деревьев не увидели леса". И по новой, "на колу висит мочало - начинаем все сначала". Самое плохое, что переделка обычно задевает все уровни системы. От БД, до клиентского интерфейса.

P.S. А, вообще, в данной теме это уже злостный офтоп.

Cane Cat Fisher"Ой, не пойму я, чего вы спорите..."Действительно, о чем ?Cane Cat FisherНормализация - она одна. Движение от первой к пятой НФ, и точка.Как это одна ? Каждая нормальная форма борется с каким-либо конкретным недостатком представления данных. И, надеюсь, не сильно Вас удивлю, если упомяну о 6NF , вдобавок к наиболее известным шести ? Не удивлюсь, если со временем будут введены и более высокие, в полном соответствии с лозунгом "нет предела совершенству". Хотя на практике, как правило, все ограничивается 3НФ, или БКНФ. Впрочем, вынужден признать свою неправоту. Как утверждают апологеты, приведение к БКНФ достаточно, чтобы избежать всех известных аномалий. Более высокие НФ решают несколько иные задачи.

Cane Cat FisherА оптимизаций может быть много. Не бывает "оптимизации" вообще - бывают разные оптимизации по разным критериям, зачастую противоречащие друг другу. Иногда для достижения одной цели приходится "проваливать" оптимальность по большинству остальных параметров.Безусловно. Но какое отношение эти, извиняюсь, банальные рассуждения имеют к нормализации ? Или ведете к тому, что всё, что ни делается, к лучшему ? Ну, тогда любой процесс можно рассматривать как оптимизацию. "Баба с воза, кобыле легче". Но хотелось бы этого избежать, так как слишком вольная трактовка терминов не способствует взаимопониманию.

Cane Cat FisherО процессе нормализации можно лишь сказать, что при нем происходит оптимизация по критерию устранения аномалий обновления .Вот, вот, в полном соответствии с предыдущим абзацем. Не возникает ощущения неестественности выделенного словосочетания ?

Cane Cat FisherОб остальных критериях однозначно сказать нельзя: быстродействие - скорее улучшается, кроме некоторых типов запросов. Объем данных - скорее уменьшается, хотя можно придумать случаи, когда это не так. Число таблиц (если кто-то вздумает "оптимизировать" по этому критерию - ухудшается :-) Простота некоторых видов запросов - ухудшается.Какое-такое быстродействие ? Какие-такие запросы ? Мне кажется, что Вы тоже смешиваете процесс логического проектирования, на котором формально происходит нормализация, и физического. Готов согласится, что в повседневной практике часто они происходят одновременно, хотя не готов считать такую ситуацию нормой. Но именно об этом я и писал, упоминая преждевременную оптимизацию, которая вполне способна запутать ситуацию, порождая совершенно невообразимые формы, которые удовлетворяют понятию оптимальности конкретного проектировщика. Почему-то при этом нередко всплывает нарушение 1НФ, насмотрелся.
Еще раз повторюсь, сделай "правильную" БД, а потом хоть заоптимизируйся, по любому критерию, который больше нравится.

Cane Cat FisherChACane Cat FisherНормализация - она одна. Как это одна ?

Так, что это достаточно жестко заданный процесс. Если нескольким специалистам поставить одну и ту же задачу, например привести к НФБК набор таблиц, то результат у всех будет одинаков.Принимается. Но только при условии, если таковые "специалисты" имеют не только четкое понимание хотя бы первых трёх НФ, но и придерживаются их на практике. Что, увы, совсем необязательно. Я ведь не зря упомянул нарушение 1НФ в предпоследней фразе предыдущего поста. Вот вроде и основной ключ наличествует, и явных функциональной зависимостей между атрибутами, помимо ОК не наблюдается. Но нет, нет, да наткнешся на список значений в поле. Оно бы и ладно, если бы какой-нибудь вектор значений, который только клиент и разбирает, так ведь и запросы к таблице соответствующие, фултесктоподобные. Формально, при соблюдении 1НФ значения полей должны рассматриваться только как атомарные, каковые должны сравниваться только на равенство или неравенство в целом, а не какой-то их части. Это не считая проверки на NULL, который сам по себе вещь весьма неоднозначная, чему Дейт в своей классической книге уделил немало внимания.

Cane Cat FisherЯ хочу лишь сказать, что вот Вы рассуждали о связи нормализации и оптимизации, или отсутствии таковой, и ни разу рядом с оптимизацией не упомянули о ее критериях.Кхм. Начинаем прямо с первой фразы отсюда . Просто Вы потеряли контекст, явно зацепившись за фразу из моего ответа MasterZiv, который, в свою очередь, комментировал мою.

P.S. Форум предполагает обмен достаточно краткими сообщениями, а не статьями. Если что-то автор и не помянул, то вовсе не обязательно подозревать его в самом плохом или ставить это ему в упрек. А то обмен мнениями превращается в парафраз - "если что-то может быть понято неправильно, значит так оно и будет". И, понеслась, каждый о своем, особенно если используются вольные трактовки терминов.

P.P.S. Я вот вчера в словаре с удивлением обнаружил, что "амбициозный" - это "высокомерный" :) Хотя вполне можно наткнуться на формулировку типа "амбициозный проект" или "план". "Высокомерный" проект - неплохо звучит ? ;)