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