Заранее извиняюсь за глупый вопрос, но сам для себя я ответа не нашел.
Берем таблицу скажем

ТОВАРЫ(#id, Артикул, Название, Вес)

и разбиваем её на 4 таблицы:
ТОВАРЫ (#id)
АРТИКУЛЫ_ТОВАРОВ(#id, Артикул)
НАЗВАНИЯ_ТОВАРОВ(#id, Название)
ВЕСА_ТОВАРОВ(#id, Вес)

Все 4 таблицы удовлетворяют, вроде бы, всем мыслимым нормальным формам. Но бред же :) Или я ошибаюсь?

Получается нормализация- это всего лишь способ борьбы со "слишком широкими" таблицами?

guest_20040621> Получается нормализация- это всего лишь способ борьбы со "слишком широкими"
> таблицами?

Нет.

> Все 4 таблицы удовлетворяют, вроде бы, всем мыслимым нормальным формам.

Формально - да, если они связаны отношением 1:1.

> Но бред же :)

Бред - использовать такие решения.


Спасибо, я знаю что использование такого разбиения- бред.
Хотя в одной системе я видел, что "слишком широкие" таблицы разбивались пополам.Это снижало использование серверных ресурсов. Люди действительно мерили и убедились в этом.

Наверное я плохо выразил свою мысль, на самом деле меня интересовало 2 вопроса:
1) Может быть все таки такое разбиение противоречит какой-нибудь НФ?
2) Если ответ на 1 вопрос отрицательный, то получается, что нормализация все таки не дает ответ на вопрос, как получить неизбыточную схему данных.

LSVБред говорите ?
Предложенная схема имеет право на существование. Почему ?
Товары - тут всё ясно
Артикулы - например для ведения артикулов поставщиков или даже клиентов (иногда очень даже нужно: некоторые VIP-клиенты требуют указывать их (!) артикулы)
Названия - например для мультиязычного представления
Веса - наверно имелось ввиду различные ед.измерения

Другое дело - как всем этим распорядиться и не перегнуть палку с нормализацией :)

Я подразумевал, что таблицы связано отношением 1:1

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

Хехе, если вы не можете по существу ответить на глупый вопрос, представляю что вы отвечаете на умные. Хотя, наверное, тоже отсылаете спрашивающих куда-нибудь в ленинку. Беспроигрышная позиция ;)

Andr2Существует мнение, что разбивка уже нормализованной таблицы
на несколько таблиц является одним из видов денормализации :)

Похоже на правду, хотя меня скорее интересует наличие НекогоФормальногоПравила.

guest_20040621> Если ответ на 1 вопрос отрицательный, то получается, что нормализация все
> таки не дает ответ на вопрос, как получить неизбыточную схему данных.

Именно это она и делает. См., например, Дейта, "Введение в системы баз данных".

так если эти 4 таблицы не нарушают ни одного формального правила нормализации, получается, что она этого не делает :)

Лох Позорный нормализация все таки не дает ответ на вопрос, как получить неизбыточную схему данных.
Что такое "неизбыточная схема данных"? И что такое "избыточная схема данных"?
Вы эти термины сами придумали?
Ну раз сами придумали, то сами и решайте, поможет ли вам нормализация в борьбе с этим невиданным зверем - избыточной схемой данных .

Я просто пытаюсь выражаться более понятно.
Вопрос в том какие ФОРМАЛЬНЫЕ правила нормализации нарушает такая схема данных.

Пока никаких идей не прозвучало, кроме заявлений о том что это бред. Что это бред я и сам знаю :)

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


не очень понял зачем
и где - в исходной таблице или в 4х "нормализованных" ?


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

нет не могут

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

Если бы все проблемы решались так просто то на все вопросы про НФ сразу бы давались простые ответы без долгого флэйма.
basПо существу:Где-то читал (просто не охота ща книжку листать....), что если есть таблица отвечающет нужной НФ (н-р, третьей), не должна быть нормализована дальше, т.е. НЕ НАДО ЕЕ РАЗБИВАТЬ ДАЛЬШЕ, т.к. цель для данной таблицы достигнута (приведена к нужной НФ).
Нет никакого формального правила доказывающего, что схема "перенормализована".
Аппелировать к тому, что изначально схема была в 3НФ некорректно. Откуда вы знаете? Может я сразу из 1НФ такую схему сваял? А может вобще, другую схему переделал?

В реальной жизни нормализация начинается отнюдь с ПлоскойТаблицыСИзыбыточнымиНеатомарнымиАтрибутами, как это любят демонстрировать нам в литературе.

Таким образом мы приходим к интересному выводу, что нормализация это процесс сугубо односторонний, работающий только в сторону "уменьшения ширины таблиц" причем начинать надо обязательно с ПлоскойТаблицыСИзыбыточнымиНеатомарнымиАтрибутами, иначе ничего не
получится.

Также получается, что просто глядя на схему данных мы, пользуясь только формальными правилами, ничего про степень её бредовости сказать не можем. Мой пример тому подтверждение. Формально схема нормализована.

guest_20040621> так если эти 4 таблицы не нарушают ни одного формального правила
> нормализации, получается, что она этого не делает :)
При чем здесь нарушения? Была 1НФ, с помощью Вашей декомпозиции получили 3НФ. Все.
Еще раз: читайте Дейта.Млин, мы не понимаем друг друга!
Я разве спрашиваю какая была НФ и какая стала?

Я вижу что схема данных с 4 таблицами бредовая с точки зрения здравого смысла и пытаюсь понять можно ли это доказать формально?

Сначала я думал, что "схема с 4 таблицами" нарушает НФБК, 4 или 5 НФ, потому, что эти НФ я не очень пока понимаю. Судя по ответам, ни одной из НФ она не нарушает, иначе мне бы уже давно сказали об этом поклонники Дейта.

Соответственно постоянно раздаются разные советы "типа какой же ты дурак, почитай наконец Дейта, чтобы понять какую бредовую схему ты предложил" - отвечаю - я и сам знаю что схема бредовая. Я нарочно сделал её бредовой, чтобы мой вопрос был понятнее.

Также звучат эмпирические советы о вреде перенормализации. Прекрасно, можно вынести в студию некую теорему, лемму итд итп из того же Дейта, которая объясняет как понять что схема перенормализована? Советы и рекомендации Дейта за теорему не катят. Советы и рекомендации я сам могу дать. Меня интересует ФОРМАЛЬНОЕ правило, теорема итп.

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?

guest_20040621> Я понимаю, что вообще с точки зрения Абстрактного Товароведения, артикул
> совершенно не обязательно уникален. Но в нашей организации он уникален.
Первичный ключ должен быть еще и независимым. В случае артикула (паспорта, ТУ, или подобных идентификаторов) это условие не выполняется. Так кто, говорите, Вашу базу данных проектировал?
Не знаю про какие вы говорите артикулы. А у нас артикул это строка типа '111-222' которую придумывает отдел маркетинга. Так что не надо фантазировать.

guest_20040621
> odbc, sql - 89, sql -92, rfc по tcp ip.... - какое это отношение имеет к методике
> разработки БД?
В большинстве своем документы перечисленных мной организаций есть в Сети, - изучайте первоисточники (RFC - это совсем не только TCP; SQL уже имеет быть 2003 (а не 92); хм... жаль, что стандартов Вы тоже не знаете). А отношение самое непосредственное: от методов описания до конкретных спецификаций.
Я не просил ссылку на стандарт. Повторяю вопрос, где в этих стандартах говорится о МЕТОДИКАХ разработки БД?

guest_20040621
> Может быть знаете какие нибудь общедоступные аналоги?
Не сталкивался. ОК. А можно оглавление этого совершенно конфиденциального руководства увидеть. Хотя бы пару ключевых глав. А то совсем, смешно получается. С пафосом заявляете что есть РазумныеПравилаРазработки, но при этом ни кому их не показываете и никаких аналогов не упоминаете. Может быть вы его с RFC каким-нибудь перепутали или со стандартом SQL2003 ? А вы думали, что это руководство по разработке RFC бывают очень понятные, с примерами ;)

guest_20040621
> Можете дать ссылку поконкретнее чем www.rational.com?
Я имел в виду не программное обеспечение, а методику унифицированного проектирования.И я имел в виду не програмное обеспечение, а некую методику. В недрах rational'а много всяких методик валяется. Конкретный документ переработав который можно получить РазумныеПравилаРазработки.

Сорри в предыдущем посте замените РазумныеПравилаРазработки на РазумныеПравилаПроектирования.

guest_20040621> Не знаю про какие вы говорите артикулы. А у нас артикул это строка типа
> '111-222' которую придумывает отдел маркетинга. Так что не надо фантазировать.

Да какая разница, кто именно придумывает этот артикул? Ну, пусть отдел маркетинга (х. з. кто и зачем это сделал), это ничего не меняет: так или иначе артикул от чего-то зависит. Следовательно, не может быть использован в качестве первичного ключа. Что это за генератор уникальной последовательности такой - отдел маркетинга? Н-да...

> Я не просил ссылку на стандарт. Повторяю вопрос, где в этих стандартах
> говорится о МЕТОДИКАХ разработки БД?

Вы читать умеете? _Методы описания_ сущностей и _методики разработки баз данных_ - не эквивалентные понятия. Понимаете? Не, Вам Дейта рановато покупать. :(

> А то совсем, смешно получается.

Рад, что повеселил.

> С пафосом заявляете что есть РазумныеПравилаРазработки,

Не надо передергивать. Я принимал участие в написании документа, обобщающего правила проектирования (в том числе баз данных) для наших разработчиков. Насколько они разумны - мне сложно сказать. Пока никто не жаловался.

> но при этом ни кому их не показываете и никаких аналогов не упоминаете.

Аналогичных документов я не видел. А показывать кому бы то ни было служебные документы - мне оно зачем? Чтобы удовлетворить Ваше любопытство? Я не считаю повод достаточным.

> Конкретный документ переработав который можно получить
> РазумныеПравилаРазработки.

Хех, Вам не кажется, что хм... бестактно просить кого-то делать работу за Вас? Ищите, google работает.

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

Спасибо за Ваши ответы.
Уважаемый, отучайтесь от стиля общения Молодого Специалиста (возможно студента старших курсов). Когда вы говорите прописные истины вы почему то думаете, что собеседник идиот и они ему неизвестны.
После достаточно спорного общения про нормализацию, в ходе которого, кстати , выяснилось, что вы тоже не знаете что такое 4 и 5 НФ. Вы не сказали вообще ничего конкретного. Про ERдиаграммы вы ничего слышать не хотели, потому, что это написано на цитфоруме, а не у Дейта. Вы старательно пытались придраться к артикулу в справочнике товаров, рекомендовали мне поискать методики проектирования БД в стандарте sql 2003, и с важным видом сообщали что РФЦ бывают не только по TCP\IP. Также выяснилось, что вы даже участвовали в разработке некоего документа, который никто в глаза не видел и даже кусочек оглавления которого посмотреть нельзя, где на 100 страницах объясняется как проектировать базы данных. А об rational вы знаете только, что это программа такая.

Ну чтож, дальнейших вам творческих успехов в изучении Дейта.