drmike bibikoff AlTkа Вы #id для начала уберите, или альтернативный ключ укажите.

не очень понял зачем

затем, чтобы получить вашу пресловутую "неизбыточную схему данных", поскольку id, как синтетический ключ, никакого смысла не несет в предметной области

Вот попробуйте сами ответить на вопрос - что означает id???

bibikoff AlTk
или у Вас для разных #id могут существовать записи с одинаковыми тройками(ртикул, Название, Вес)?
нет не могут
Ну и нафига тут тогда id?

А вы в своих боевых БД тоже от Id избавляетесь? Наверное чтобы 3НФ получить? ;)

А если серьезно без id очень плохо. Если сделать артикул ключом то подумайте, на что мы попадаем при необходимости изменить артикул. Придется ходить по всей первичке, ссылающейся на этот товар и тоже менять там артикул. Одной транзакцией.
У нас тут на работе тоже, кто-то "нормализовал" так справочник товаров. Артикул за ночь обновиться не успевает, если товар ходовой :).

basА Вы читали про функциональные зависимости????? Понали что такое и для чего они нужны????? Я сомневаюсь что поняли, хотя м.б. про них в книге (кот. Вы читали) и упоминалось!!!!
Нормализация не односторонняя, а двусторонняя!!!!
Вот так.
Блин, если не забуду сегодня посмотрю Дейта и выпишу вам оттуда цитату!
С функциональными зависимостями, в том числе и транзитивными мне все как раз понятно. На сегодняшний день у меня непонятки восновном по поводу 4, 5 НФ - очень уж неконкретно везде это излагается или просто сообщается факт, что это вам нафиг не надо :) )

Вот про двустороннесть нормализации - действительно интересно. Вы хотите сказать, что любую схему данных формальными методами можно привести к некой ОднойНенормализованнойСовсемТаблице (как вариант к ОднойТаблицеВ1НФ), которая потом очень хорошо поддается нормализации "как в книжках"? Сомневаюсь в реалистичности такой возможности.

guest_20040621
Позвольте поинтересоваться, чем вредна "перенормализация"?
Живой пример - см. в моем ответе drmike про необходимость поля id.
Ну или тот пример с которого начался флэйм - когда таблица в НФБК разбивается на 4 таблицы. Чтобы вы сказали проектировщику боевой БД, когда бы он притащил вам схему с 4 таблицами?

guest_20040621
Нет таких, если я правильно помню. Фишка в том, что - по Дейту - вообще нельзя _утверждать_, что переменная-отношение находится в определенной НФ, можно _предполагать, основываясь на_. Если честно, не очень понятна задача, которую Вы хотите решить этим обсуждением. Вам интересно теоретическое обоснование разумной степени декомпозиции при проектировании? - так его нет. Разные условия - разная степень декомпозиции. Интересно, интересно. Получается без знания контекста задачи ничего нельзя сказать про достаточную степень нормализации отдельных таблиц. Т.е. иногда достаточно 1НФ, а иногда - вперед до 5НФ. Скорей всего иногда и полностью ненормализованная таблица подойдет. Если я вас, конечно, правильно понял.

guest_20040621
Если честно, не очень понятна задача, которую Вы хотите решить этим обсуждением.

Зачем и кому? Кто-то добивается этих советов и рекомендаций?
Сначала я просто хотел услышать ответ типа "Да вы, батенька, такую-то НФ нарушили, когда разбили эту прекрасную таблицу на 4 нелепых части." Очень скоро обнаружилось, что я ничего не нарушил.
Т.е. обнаружилось, что НФ, как доказательный инструмент в дискуссии о боевых схемах данных достаточно слаб. (Заведомо плохая схема из 4х нелепых таблиц была "нормальнее" жизненной схемы из 1 таблицы)

А потом я восновном пытался еще раз объяснить суть спрашиваемого и отбивался от наездов в том, что пока я не читал Дейта незачем вообще рот открывать. :)

Кстати, в электронном виде Дейта ни у кого нет ?

guest_20040621>
> Советы и рекомендации Дейта за теорему не катят. Советы и рекомендации я
> сам могу дать.
Зачем и кому? Кто-то добивается этих советов и рекомендаций?
> Меня интересует ФОРМАЛЬНОЕ правило, теорема итп.
Может, Вам все-таки почитать Дейта вместо того, чтобы требовать пересказа в форуме? Явно быстрее и дешевле. Зачем я добивался Формального правила? Скажем, с определенного момента дискуссии меня осенило, что нормализация это не только нормальные формы :)
Но с другой стороны эмпирические советы (например не перенормализовывать), от кого бы они не исходили, все таки не могут быть частью Формальной Теории. Ведь нормализация БД - это же не white paper про best practices ?
Отвергая таковые я пытался понять занимается ли ФормальнаяТеория моими жизненными проблемами.

А жизненные пробемы у меня простые- как попроще аргументировать разработчику, что его схема неправильна, с минимальными затратами и желательно не переходя на личности :)

guest_20040621> Живой пример - см. в моем ответе drmike про необходимость поля id.
Что я в этом ответе должен увидеть?
О том как стремление к теоретической правильности ведет к практически глупым поступкам.

guest_20040621
> Ну или тот пример с которого начался флэйм - когда таблица в НФБК
А кто Вам сказал, что исходная таблица удовлетворяла НФБК?
вобщето в исходной таблице 2 потенциальных ключа - id и артикул, а все остальные атрибуты зависят от них, что это если не НБФК?

guest_20040621
> Сначала я просто хотел услышать ответ типа "Да вы, батенька, такую-то НФ
> нарушили, когда разбили эту прекрасную таблицу на 4 нелепых части."
Как минимум две фактические ошибки в Вашем рассуждении: 1. Нельзя нарушить НФ; можно говорить о том, что некоторая таблица удовлетворяет критериям некоторой нормальной формы; Вы причину со следствием переставили местами. Не мудрствуйте. Имхо очевидно, что под "нарушением" я имел в виду "несоответствие НФ"
guest_20040621
2. Декомпозиция - абсолютно естественный процесс.
В начале обсуждения мне вобще то казалось, что декомпозицией можно вывести таблицу из нормализованного состояния. Вспомните исходный вопрос. Так что в цитируемом вами утверждении никаких ошибок я не вижу :)

guest_20040621
> Т.е. обнаружилось, что НФ, как доказательный инструмент в дискуссии о
> боевых схемах данных достаточно слаб.
Хм... imho жуткая каша в Вашей голове. Это неправильная постановка вопроса. Нормальную форму можно рассматривать как компоненту правил проектирования. Нельзя говорить, что нормальная форма может доказывать что-то сама по себе. Именно к этому выводу я пришел к концу нашего флэйма. Не стоит утверждать, что эта мысль настолько самоочевидна.

guest_20040621
> Заведомо плохая схема из 4х нелепых таблиц была "нормальнее" жизненной
> схемы из 1 таблицы
Разочарую: обе схемы никуда не годились. Ни в качестве примера, ни для практического применения. Вы сами себе противоречите. Не зная контекста вы делаете выводы о качестве схемы. 1я схема вобщем-то взята из боевой системы и претензий к ней ни у кого нет. А что вторая схема никуда не годится в любом контексте я утверждал с самого начала. Она неэффективно расходует серверные ресурсы ничего не давая взамен.

guest_20040621
Imho нет. Формальная теория дает Вам инструмент, которым Вы (с учетом подготовки) можете пользоваться. А решение реальных задач - это не только и не столько приемы проектирования; я бы (в порядке убывания значимости) предложил такой список: 1. техническое задание, 2. стандарты, 3. правила проектирования, 4. особенности предметной области.
Вобщем согласен. Правда список пунктов достаточно странный ;)

guest_20040621
> как попроще аргументировать разработчику, что его схема неправильна, с
> минимальными затратами и желательно не переходя на личности
В общем случае - никак. Есть техническое задание, которое обязано включать в себя требования к базе данных. Так что критерий оценки разработчика базы данных один: соответствует/не соответствует заданию. У нас разработчики сами делают ТЗ по некой постановке задачи. И с их фантазиями мне собственно и приходится иногда бороться.

bas
И еще раз вслушайтесь в фразу: первоначальная таблица и все разбитые таблицы НАХОДЯТСЯ В 3 НФ, т.о. берем наиболее полную таблицу, п.ч. :
1. С ней удобнее работать
2. Она занимает меньший объем
3. Понятнее она

И никто даже Код и Дейт никогда не говорили, что если Вы доведете таблицы в БД до 5 (или 3) НФ, то все у вас будет зашибись. НЕ БУДЕТ, т.к. теория это одно, а практика другое.
ВО ВСЕХ БД ЕСТЬ НЕ НОРМАЛИЗОВАННЫЕ ТАБЛИЦЫ!!!!!
Надо исходить из здравого смысла!!!! Млин, ну зачем же с таким пафосом излагать прописные истины с которыми вобщем то никто и не спорит :)

Скажем так, мне интересно было посмотреть, можно ли при помощи Теории Нормализации делать утверждения о качестве проектирования жизненных схем БД. Соответственно оказалось что скорей всего нельзя.

Цитата по теме:

Моделирование структуры базы данных при помощи алгоритма нормализации, описанного в предыдущих главах, имеет серьезные недостатки:
1. Первоначальное размещение всех атрибутов в одном отношении является очень неестественной операцией. Интуитивно разработчик сразу проектирует несколько отношений в соответствии с обнаруженными сущностями. Даже если совершить насилие над собой и создать одно или несколько отношений, включив в них все предполагаемые атрибуты, то совершенно неясен смысл полученного отношения.
2. Невозможно сразу определить полный список атрибутов. Пользователи имеют привычку называть разными именами одни и те же вещи или наоборот, называть одними именами разные вещи.
3. Для проведения процедуры нормализации необходимо выделить зависимости атрибутов, что тоже очень нелегко, т.к. необходимо явно выписать все зависимости, даже те, которые являются очевидными.

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

http://www.citforum.ru/database/dblearn/dblearn08.shtml

PArth2 bibikoff

Вы хотели правило или цитату? Ловите:

Д. Мейер. Теория реляционных баз данных. Мир. 1987 г.
" гл. 6.4. Недостатки нормализации методом декомпозиции.
... число порожденных процессом декомпозиции схем отношения может оказаться большим, чем в действительности необходимо для 3НФ."типичное эмпирическое правило, причем здесь Теория Нормализации?

Хехе
Прихожу к выводу, что ТеориюНормализации надо учить только для того, чтобы "по понятиям" посылать на фиг СпециалистовПоНормализации, чтобы они не портили работающие схемы данных, мотивируя это одними им понятными соображениями :)

guest_20040621>
> вобщето в исходной таблице 2 потенциальных ключа - id и артикул, а все
> остальные атрибуты зависят от них, что это если не НБФК?
Вообще, конечно, хотелось бы знать о задаче чуть больше, чтобы предлагать схемы. Однако, очень сильно сомневаюсь, что артикул в данном случае - потенциальный ключ.
Артикул-так сказать подлинный ключ, а Id-суррогатный

guest_20040621
citforum никогда не был источником информации, Вас кто-то обманул.
Никто цитфорум Дейту не противопоставляет. Маловероятно, что Дейт проектирует свои базы данных путем ФормальнойНормализации :) Он просто описывает в своей книге, что же это такое.
Вобще-то рекомендую все же сходить по ссылке. Опубликованный курс имхо неплох, тем более что Дейта в свободном доступе не наблюдается.

PArthА дальше он (Мейер) пишет про "нормализацию посредством синтеза"... Мейер в сети есть?

guest_20040621>
Формальная теория дает Вам инструмент, которым Вы (с учетом подготовки) можете пользоваться. А решение реальных задач - это не только и не столько приемы проектирования; я бы (в порядке убывания значимости) предложил такой список: 1. техническое задание, 2. стандарты, 3. правила проектирования, 4. особенности предметной области.

Слишком короткий - возможно (развернуто - долго писать). А в чем странность, позвольте поинтересоваться?
Имхо он должен выглядет так: 1) наличие мозга у проектировщика 2) понимание предметной области проектировщиком 3) опыт проектировщика. Знание теории желательно, но не обязательно.

Правила проектирования и стандарты? Хехе - вы сами пробовали их написать? Дальше соглашения об именованиях я думаю вы врядли продвинетесь :)

guest_20040621> Артикул-так сказать подлинный ключ, а Id-суррогатный
Подлинный ключ чего? Товара? Т. е. Вы полагаете, товар без артикула в принципе существовать не может? не знаю в какой области вы специализируетесь, но в нашей предметной области артикул однозначно идентифицирует товар

guest_20040621
Спасибо, я не читаю то, что пишут на заборах. абсолютно неконструктивная позиция :)

guest_20040621
> Дейта в свободном доступе не наблюдается.
Стоимость книги - не запредельная цифра. Мой интерес к теории нормализации пока не сильнее нежелания читать "только 100 страниц про одни нормальные формы".

guest_20040621
> Имхо он должен выглядет так: 1) наличие мозга у проектировщика 2)
> понимание предметной области проектировщиком 3) опыт проектировщика.
> Знание теории желательно, но не обязательно.
У-у-у... как все плохо. Мало того, что Вы теорию не знаете, так у Вас еще и неправильное представление о проектировании как таковом. 1) о дебилах, конечно, речь не идет; гением разработчику быть абсолютно необязательно; 2) проектировщику не нужно понимание предметной области - для понимания есть консультанты предметной области; 3) опыт на самом деле ничто иное, как правила (часто интуитивные) проектирования + разумные компромиссы; более за опытом ничто не стоит. хе-хе, вы во многих проектах участвовали? Возможно, конечно, вы работаете выделенным проектировщиком в компании которая консультантов чуть что нанимает, ну тогда я вам по белому завидую :)

guest_20040621
> Правила проектирования и стандарты? Хехе - вы сами пробовали их написать?
Правила - да. А стандарты не нужно писать, их нужно знать. Ну, или по крайней мере представлять себе, что, где, как и кем стандартизовано. Ссылку на правила проектирования в студию, пожалуйста. Дейт за рабочие правила проектирования не катит :)
Опять же ссылку на стандарты в студию.

guest_20040621
> Дальше соглашения об именованиях я думаю вы врядли продвинетесь :)
Позвольте полюбопытствовать, на основании чего Вы сделали такой вывод? Сам пытался писать. По ощущениям это будет или ОченьБольшойТалмуд, который никто не будет читать или АбстрактныеРекомендации, которые можно слишком широко трактовать. Возможно конечно надо делать делать документ вроде паттернов проектирования, ну да ладно...

guest_20040621Артикул - он декларативно присваивается некоторой организацией изделию с некоторым набором характеристик, правда?
артикулы ну совсем оффтопик имхо. Я понимаю, что вообще с точки зрения Абстрактного Товароведения, артикул совершенно не обязательно уникален. Но в нашей организации он уникален.

guest_20040621
Дело не в том, где я работаю и чем занимаюсь. Если Вы полагаете, что архитектор базы данных должен знать предметную область на уровне консультанта, Вы вряд ли вообще получите сколь-нибудь приемлемое решение. Каждый участник процесса проектирования должен заниматься своей работой. Дешевле и быстрее заплатить консультанту, чем парить девелоперов ненужной хренью.Я не говорил что он должен знать предметную область лучше специалиста. Он должен понимать предметную область достаточно, чтобы не собирать грабли. Но это все равно приличный объем знаний. И естественно у него должен быть выход на специалистов-предметчиков, чтобы уточнять вопросы. А наемных консультантов по предметной области ни разу не видел.
guest_20040621
> Опять же ссылку на стандарты в студию.
IETF, W3C, ITU и прочая, прочая, прочая. Ну, плюс отраслевые стандарты, разумеется. ага odbc, sql - 89, sql -92, rfc по tcp ip.... - какое это отношение имеет к методике разработки БД?

guest_20040621
Это среднего размера документ (немногим более сотни страниц), включающий в себя в числе прочего описание типовых структур данных, способы хранения метаинформации, способы решения типовых задач (разделение доступа, локализация и пр.). Он удобно адаптируется для конкретного проекта путем удаления ненужных частей и добавления нужных (связанных с предметной областью или особенностями приложения). Честно говоря, мне кажется, что это будет ТалмудКоторыйНиктоНеЧитает (и никто не понимает кроме автора). Но посмотреть все равно было бы интересно. Может быть знаете какие нибудь общедоступные аналоги?

guest_20040621За основу взят UP, если Вам интересно.Можете дать ссылку поконкретнее чем www.rational.com?