Борис ПУважаемые корифеи! Я - студент из Киева. И совершенно запутался в одном вопросе: как можно "подвергнуть декомпозиции БКНФ", если в ней ключи А+В+С имеют стандартную "многозначность" А->>B и А->>C, но при этом имеются еще и атрибуты К, М и т.п., которые функционально зависят от суммарного ключа А+В+С? Фейджин "заставляет" разбивать на 2-а отношения, а зависимые атрибуты не дают этого сделать. Что говорит теория на этот счет? Почему ни в одном учебнике по БД я не нашел подобной ситуации? А ведь это же так просто:
R ("Сотрудники - отделы - проекты"): (А,В,С; К{"количество часов на проект сотрудника отдела"}, М {"количество денег на проект сотрудника отдела"}, "иные атрибуты, зависящие от А+В+С"). Почему такой простой ситуации не рассморено в учебниках? С одной стороны, стандартная многозначная зависимотсть в ключах. А с другой, разбивать их нельзя - потеряются данные. Значит, не всегда нужна 4НФ? Почему же об этом - ни слова. Или я что то путаю? А вообще, в какой форме находится это моё отношение? Как это определить? Помогите!!!! На всякий случай моё мыло: pr-bob@ukr.net
Борис ПУважаемые корифеи! Я - студент из Киева. И совершенно запутался в одном вопросе: как можно "подвергнуть декомпозиции БКНФ", если в ней ключи А+В+С имеют стандартную "многозначность" А->>B и А->>C, но при этом имеются еще и атрибуты К, М и т.п., которые функционально зависят от суммарного ключа А+В+С? Фейджин "заставляет" разбивать на 2-а отношения, а зависимые атрибуты не дают этого сделать. Что говорит теория на этот счет? Почему ни в одном учебнике по БД я не нашел подобной ситуации? А ведь это же так просто:
R ("Сотрудники - отделы - проекты"): (А,В,С; К{"количество часов на проект сотрудника отдела"}, М {"количество денег на проект сотрудника отдела"}, "иные атрибуты, зависящие от А+В+С"). Почему такой простой ситуации не рассморено в учебниках? С одной стороны, стандартная многозначная зависимотсть в ключах. А с другой, разбивать их нельзя - потеряются данные. Значит, не всегда нужна 4НФ? Почему же об этом - ни слова. Или я что то путаю? А вообще, в какой форме находится это моё отношение? Как это определить? Помогите!!!! На всякий случай моё мыло: pr-bob@ukr.net

Давайте посмотрим. Почему вы уверены, что «разбивать их нельзя - потеряются данные»? Сделаем так. Пусть отношение Emp(E#, …) хранит общие данные о сотрудниках, Dept(D#, …) — об отделах, Proj(P#, …) — о проектах. Внутри них только обычные функциональные зависимости.

Далее, связь сотрудников с отделами, при условии «многие ко многим», занесем в отношение ED(E#, D#).

Теперь свяжем сотрудников с проектами в отношении EP(E#, P#, [Количество часов] , [Количество денег]). Вроде всё.

Отмечу, что в вашем примере мне представляются странными атрибуты типа "Количество денег/часов на проект сотрудника отдела". Если деньги/время проекта выделяются по конкретным сотрудникам, то это одно. Если деньги/время проекта выделяются по конкретным отделам, это другое. Но я не понимаю, что означает выделение денег/времени проекта по «сотрудникам отделов». Это реальная задача или вы её придумали? Если реальная, то поясните на примере.

Если я что-то важное упустил, напишите, пожалуйста, будем думать дальше.

Baykin Ilyaа вопрос на зысыпку можно? зачем вам от 3 НФ БК переходить в 4 НФ ?
во многих книжках утверждают- для хорошей работы вашей БД достаточно чтобы она находилась в 3 НФ (и не больше), ну а дальше уже смотрите без книг и анализируйте, как будут удаляться данные, и что нам вообще нужно....
Выкидывайте такие книги подальше, мой совет.

Васильев Андрей mirВыкидывайте такие книги подальше, мой совет.
Может всё-таки не стоит воспринимать нормализацию как панацею? Даже в рамках OLTP систем.
Панацей не существует.

Борис ПОгромное спасибо за внимание к теме! Особенно господину из Томска. Но я действительно имел ввиду конкретную прикладную задачку, в которй действительно и атрибут "количество денег на проект для отдела с сотрудником", и атрибут "время выполнения конкретного проекта конкретным сотрудником конкретного отдела" зависят от суммы трех атрибутов: отделы, сотрудники и, соответственно, проекты. Я ничего не придумывал. Дело в том, что в этом провинциальном заводском СКБ бюджеты просчитывают в разрезе отдела на каждого сотрудника по его зхатраченным часам на конкретный проект. Понятно, что сотрудники могут одновременно числитться в надцати отделах и на надцать проектах. Словом, четкая связь А+В+С->К, где и А, и В, и С - "многое". У меня вопрос касается именно 4НФ. Как разбивать? Видимо, в такой ситуации разбивать нельзя - некуда девать атрибуты. А что тогда это за ситуация такая будет? Почему об этом молчит Фейджин и все учебники - от Ульмана и Дейта и до Хомоненко и Малыхиной? Что тут не так? Дело в том, что это еще и дипломная работа. Мне нужно все обосновывать и все понимать, что я делаю...

Да подождите вы рассуждать о высоких материях, давайте сначала в вашей задаче разберёмся. По вашему, один и тот же человек, участвуя в проекте, может участвовать в нем на, скажем, 70% как сотрудник отдела D1 и на 30% как сотрудник отдела D2? Сама мысль об этом лишена физического смысла. Поэтому "время выполнения конкретного проекта конкретным сотрудником конкретного отдела" — бессмыслица, в отличие от понятного "время выполнения конкретного проекта конкретным сотрудником". Это первое.

Теперь рассмотрим делёжку денег. Скажем, сотрудник E1 работает в отделах D1 и D2 и участвует в проекте P1. На его участие в проекте положена сумма M. Вопрос: каким образом эта сумма будет учтена в бюджетах отделов D1 и D2? Поделена поровну? Тогда моё решение в предыдущем ответе данную ситуацию полностью покрывает. Предположим, что не поровну, то есть существуют коэффициенты делёжки. Если эти коэффициенты зависят только от самих отделов, приписываем их как атрибуты отделов. Если эти коэффициенты меняются от проекта к проекту, заводим отношение DP(D#, P#, “Процент”), где атрибут «Процент» хранит искомую информацию. Вариант, при котором проценты зависят ещё и от конкретного сотрудника, мягко говоря, сомнителен. Попахивает бредом.

Но даже и в этом случае, рассмотрим полученное отношение EDP(E#, D#, P#, “Процент”). Первичным ключом в нём является, разумеется, тройка {E#, D#, P#}. Определим внешние ключи. Их можно задать несколькими способами, но я рассмотрю только 2: неправильный и один из правильных.

1.Три независимых FK: E#, D#, P#. Это неверное решение, поскольку оно упускает информацию о жестко заданной связи сотрудников и отделов и позволяет задать несуществующую принадлежность сотрудника к к.-л. отделу.

2. Два FK: внешний ключ {E#, D#} ссылается на ранее описанное отношение ED, которое хранит правильные вхождения сотрудников в отделы. Второй внешний ключ P# ссылается на проект (отношение P). При таком раскладе введённое ранее отношение EP вообще не требуется.

Теперь вопрос: находится ли отношение EDP с учётом заданных ограничений в 4NF? Вспомним определение многозначной зависимости (привожу по Дейту, 7-е изд):

Пусть A, B, C — произвольное подмножества атрибутов отношения R. Тогда B многозначно зависит от A (A—>>B) тогда и только тогда, когда множество значений В, соответствующее данной паре (зн. А, зн. С) зависит от А, но не зависит от С.

Вот все возможные кандидаты на многозначные зависимости:
1) E# —>> D#|P#
2) D# —>> E#|P#
3) P# —>> E#|D#

Очевидно, что в нашем случае мн-во значений {P#} никогда не зависит только от значения E# или только от значения D# независимо, но всегда от пары значений (E#, D#) одновременно, поскольку таково заданное ограничение FK {E#, D#}.

На этом основании варианты 1 и 2 сразу отпадают.

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

Вывод: 4 NF имеется.

Борис ПЯ опять ничего не понял. Но ведь ситуация же стандартная:
Сотрудник 01 работает в отделах 01, 02, 03 и 04 (пусть он там лишь числится, но он там деньги получает - сами знаете, сегодня это очень даже можно).
Сотрудник 02 числитчся-работает в отделах 02, 03, 05, 07
Сотрудник 03 работает в отделах 05, 06,07,10
Для начала хватит. Нет, не хватит.
Борис ППри этом, в каждом отделе есть по чуть-чуть проектов: 01,02,03,04,05 (между прочим, стандартная ситуация...)
Все отделы участвуют во всех проектах, или нет?
Борис П
Итого получаем табличку:
С. - О. - П.- Время - Деньги
Вах, слющай, дарагой, так дело не пойдёт. Из предыдущей «постановки задачи» такая таблица не следует. Какое время? Какие деньги? Я об этом подробно спрашивал в предыдущем сообщении. Если вы хотите ответа на свои вопросы, прекратите гнать свой словесный понос, и отвечайте на уточняющие вопросы. Если вы ответа не хотите, до свидания.

Борис ПИ еще, господин из Томска, mir, кажется. Строчку "откуда" мелким шрифтом вы прочитать сумели, а в нике, написанном крупнее и выделенным цветом, сомневаетесь?
Борис ПВ этом то и парадокс - если нет свободных атрибутов - все как по книжкам - режим и получаем 4НФ.Если у вас такие книжки -- выбрасывайте их на помойку. Читайте что-нибудь пристойное, Дейта например. Так таких советов нет и быть не может. Впрочем, есть и такой вариант, что вы просто неверно понимаете прочитанное.
Борис ПА если эти атрибуты есть? Значит резать нельзя, так?Я вам в сообщении http://www.sql.ru/forum/actualthread.aspx?tid=470146#4623372 привел определение, цепь рассуждений, вывод. Нарушения 4NF нет, резать не надо (если выполняются подразумеваемые условия). Вам этого мало? Или это, по вашему выражению, "ненужные рассусоливания"?

Поймите, признак дилетанта -- рассуждать о решении задачи, не поняв как следует её условия. Вам несколько человек уже указали, что условия вы сформулировали плохо, а вы всё недовольны: дайте, мол, сразу готовый ответ, не лезьте вы в условия задачи. Как вы не понимаете, что функциональные и многозначные зависимости невозможно правильно выявить только по формальным признакам. Чтобы их правильно выявить, надо понимать задачу. Без этого понимания даже примера недостаточно, т.к. зависимости относятся не к значению отношения, а к переменной отношения, как об этом пишут все вменяемые авторы.

SenjaВам не надо разбивать ваше отношение.
На мой взгляд вы не совсем правильно понимаете что такое МЗ. Вот определение, взятое отсюда .

Пусть R(X, Y, Z) - схема отношения R, Х, Y, Z - непересекающиеся подмножества атрибутов R, и пусть Z = AR\ (X, Y).
Отношение R удовлетворяет МЗ X ->> Y, если для двух любых кортежей t1 и t2 из Ri, таких, что t1(x) = t2(x) (т.е. кортежи t1 и t2 совпадают по значению х) в Ri существует кортеж t3 такой, что t3(x) = t1(x), а t3(у) = t1(у) и t3(z) = t2(z).

Из симметрии определения относительно t1 и t2 (учитывая, что t1(x) = t2(x)) следует, что в Ri существует также кортеж t4, для которого t4(x) = t1(x), t4(y) = t2(y) и t4(z) = t1(z).


Обратите внимание на Z = AR\ (X, Y). Иными словами это значит, что Z - все остальные атрибуты отношения не входящие в X и Y. А вы пытаетесь рассуждать о многозначной зависимости не включая в рассмотрение некоторые атрибуты. Так делать нельзя. А если включить все, то МЗ на ваших данных не получается.
Уважаемый Senja. Несмотря на то, что в данном случае мой вывод совпал с вашим выводом, я позволю сделать несколько замечаний. Прошу, воспринимайте их как искреннее желание помочь, а не как что-либо иное.

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

Сразу это видно по приведенному вами оттуда «определению» МЗ (кстати, автор переводит «многозначные зависимости» на английский как «multi-valid dependencies», что сразу выдаёт его знание английского языка). Итак, начало:
«Пусть R(X, Y, Z) - схема отношения R, Х, Y, Z - непересекающиеся подмножества атрибутов R»
Схема отношения по определению состоит из атрибутов отношения , а не из подмножеств атрибутов . Поэтому самое начало определения указывает, что автор забыл, что такое схема отношения.

Глянул я еще в несколько мест. Вот раздел «1.3. Архитектура банка данных». В нём автор пишет какую-то фантастику про архитектуру СУБД, явно путая её с моделью ANSI/SPARC, о которой, кстати, сам же и пишет несколько ниже. Но при этом не может не удержать от перлов типа:
«Для каждого пользователя используется свой язык общения с базой данных. […] Для пользователя-непрофессионала – это специальный язык, разработанный с учетом его потребностей, т.е. это может быть специальное меню, реализованное с помощью языка типа SQL…»

Язык -- это меню. А меню, реализованное с помощью SQL,— это вообще сильно.

Далее, в разделе 2 автор вводит диковинный термин «состояние отношения», который я ни в одной книге не видел. Автор, похоже, современной терминологией не владеет, не зная понятия «переменная отношения».

А вот фраза: «каждый атрибут, описываемый в модели, как правило имеет определенное множество значений, которое он может принимать». «Как правило» — это так мило :)

Путаница между понятиями «домен» и «атрибут» у автора очевидна, вот характерный пример: «Собственно в базе данных хранятся конкретные комбинации значений различных сочетаний (таблиц) атрибутов».

Ну и просто перл: «в реляционных моделях его (отношение) […]на практике отождествляют с понятием двухмерной таблицы.» Как видишь у кого-то слова «двухмерная таблица», это уже диагноз.

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

Диковинность иногда используемой автором терминологии вновь меня поразила, когда я прочитал у него про «срез» отношения. Как оказалось, это авторская замена стандартному понятию «проекция», которое он то ли не знает, то ли не любит.

Мифотворчество автора проявилось в разделе 2.4, где автор изобрёл невиданное понятие: концептуальный уровень реляционной модели. Реляционная модель не имеет уровней вообще, ни концептуальных, ни других. Видно, автор опять перепутал с моделью ANSI/SPARC.

В этом разделе перл на перле. Вот, к примеру: «На данном этапе рассмотрения основ реляционной модели укажем, что реляционный подход основан на постулате единого (универсального) отношения, с помощью которого можно описать любой фрагмент предметной области». Излишне говорить, что такого постулата не существует.

Можно предъявить небольшую претензию и к фразе про 1NF:
«Все рассматриваемые отношения в реляционном подходе должны находиться в первой нормальной форме (1НФ), которая предполагает, что элементы доменов отношений не являются множествами (т.е. являются атомарными).» Представление о том, что все отношения обязаны находится в 1NF, является мифом, но автор тут виноват мало, так как этот миф широко распространён, и даже Крис Дейт только с 7 издания ВвСБД от него полностью отрёкся (с извинениями). Однако в списке источников автора есть классика: “Codd E.F. A Relational Model of Data for Large Shared Data Banks”, прочитав которую он мог бы убедиться, что Кодд, предложив понятие 1NF, преследовал только соображения простоты реализации РМД в будущих РСУБД, а никаких теоретических, принципиальных причин вообще не выдвигал.

До сих пор я был снисходителен к автору. Однако ознакомление с разделом «3.3.3. Неполнота средств идентификации объектов в модели» не оставляет иного выбора, кроме как назвать это раздел безграмотным и даже бредовым, как бы грубо это не звучало. На детальную критику нет сил и времени, но поверьте — там просто нагромождение чуши, завершающееся формулировкой автора «выявленных недостатков традиционной реляционной модели». Скорее, это выявленные дефекты мозга автора. Впрочем, прочтение раздела «Заключение» даёт ключ к пониманию того, почему автор любыми способами пытался «опустить» РМД. Настойчиво рекламируется «чудо-СУБД ORD», которая должна избавить от всех этих проблем и дать ЩЩЩАСТЬЕ.

Пособие просто переполнено орфографическими и грамматическими ошибками, которые я даже в приведенных выше цитатах был вынужден исправить.

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