NkeyТочнее если добавить AD->C, то всё равно же ее удалять. Не понятно. :)
Не понял что имеется в виду под "добавить" и "удалять".
Эта ФЗ просто есть. А ФЗ A->C. Делает ее транзитивной.

NkeyСледуя Вашей инструкции. AD->A, A->C, то по идеи должна удалится по транзитивности AD->C, но ее нет.
Даже есть и удалить A->C, то останется ли AD->A? Или это просто для удаления делается?
транзитивности AD->C есть. Если "удалить" A->C, то транзитвности не станет. Что и сделано в окончательной схеме.

Nkey,
возможно Вас сбивает с толку транзитивность AD->A, A->C из за того, что А входит в AD. И Вы думаете, что транзитивности якобы нет. Но последнее обстоятельство не имеет значения. AD - это обозначение множество атрибутов {A,D}. Вы вправе обjзначить это множество, например, буквой X. Тогда будет выглядеть X->A, A->C. И что входит в X не имеет значения для факта транзитивной зависимости. Важно, лишь, чтобы не было зависимости A->X.

Nkeyvadiminfo,

Допустим. Но какой смысл выносить ключ в одно отношение r(A,D) ? Вроде так не нужно делать...
Как какой "смысл"? Без этого схема не находится не только в НФБК, но даже в 2НФ.

А выходя за рамки задачи, еще имеет "смысл" то, что это позволит навязать схеме ФЗ A->C, объявив A ключом в r(A,C;[A]). А в r(A,C,D) ключом может быть только AD.

SQL*PlusSQL*PlusNkey,

R1 ([A], C)
R2 ([C,D], B)
R3 ([B], E, F)

В квадратных скобках первичные ключи.

Можно так:
CA ([C], A)
CDB ([C,D], B)
BEF ([B], E, F)

В квадратных скобках первичные ключи.

Функциональная зависимость С от А дает AC ([A], C)
эквивалентна
Функциональной зависимости A от C дает CA ([C], A)

Функциональной зависимости A от C не выводится из заданных (тем более из A->C):
Вот пример отношение содержит соответствует всем ФЗ задачи. Но в нем не выполняется C->A
A C D B E F
1 1 1 1 1 1
2 1 1 1 1 1

Т.е. это отношение является допустимым по условиям задачи, но не может быть получено при вашей схеме.

Т.е. так нельзя:


CA ([C], A)
CDB ([C,D], B)
BEF ([B], E, F)

NkeyИ останется r1([B],E,F) r2([C,D],B) R3([A],C)
Ну Вы просто не прочитали предыдущую страницу. Такая схема приведет к потере информации. А я стрался придумывал пример. А Вы не читаете. Найдите плиз тот пример и опровергните его.

Nkeyr(A,D) вроде, является избыточным

Из
r2(A,С)
r3(С,D,B)
r4(B,E,F)

Нельзя получить исходное в общем случае. Значит ему чего-то не хватает.

Этим чем-то и является
r1(A,D)
Так как из

r1(A,D)
r2(A,С)
r3(С,D,B)
r4(B,E,F)

Можно получить исходное без потерь. Первое со вторым соединяем по А - ключ второго, потому нет потерь.
Полученное соединяем с третьим по CD - ключ третьего - нет потерь. Дальше просто.

Значить r1(A,D) не избыточно.

Павел Воронцовvadiminfo,

([A],C) + ([A],D) != ([A],{C,D}), возможно появление фантомных записей при соединении.


при соединении по A отношений
r1(A,D)
r2(A,С)
потерь информации быть не может, в силу того, что A является ключем в r2(A,С), так как по условию задачи A->C. Действительно, все значения А уникальны в этом отношении. Откуда там возьмутся "фантомных записей".

Впрочем, Вы можете привести пример их появления, что опровергнуть это.


Павел ВоронцовC и D в предложенной схеме не существуют независимо. Можно попробовать обойтись так

([A],C) + ([C,D]) + ([C,D],B) + etc

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

r1(A,D)
r2(A,С)
r3(С,D,B)
r4(B,E,F)

vadiminfo

Можно получить исходное без потерь. Первое со вторым соединяем по А - ключ второго, потому нет потерь.
Полученное соединяем с третьим по CD - ключ третьего - нет потерь. Дальше просто.



Нужно все таки опровергнуть это с помощью примера, если не согласны. Действительно, один пример может опровергнуть всеобщее суждение.
Иначе, Вы как бы возражаете, но формально не показываете мою ошибку.

Я же опровергал SQL*Plus с помощью простейших примеров. Там все просто как трусы по рубль двадцать. Пока эти опровержения вроде не опровергнуты, потому варианты типа

r2(A,С)
r3(С,D,B)
r4(B,E,F)
выглядят не удовлетворяющими требованиям задачи.
выглядят

Павел Воронцовvadiminfo,

Да, набор

r1([A],C)
r2([A],D)

действительно является одной из возможных схем, прошу прощения. Возможные фантомные записи исчезнут при соединении с r3([C,D],B). Единственная загвоздка - ФЗ A->D не существует изначально.

Загвоздки нет, так как у меня не r2([A],D), а r2(A,D). По условиям задачи не требовалось выделять ключи, поэтому я их не рисовал. Но если надо выделить, то
r2(A,D;[AD]). Т.е. можно ключом объявить только [AD].

ПыСы
Ключей может быть много, поэтому лучше отделить от атрибутов.

SQL*Plusvadiminfoпропущено...

Функциональной зависимости A от C не выводится из заданных (тем более из A->C):
Вот пример отношение содержит соответствует всем ФЗ задачи. Но в нем не выполняется C->A
A C D B E F
1 1 1 1 1 1
2 1 1 1 1 1

Т.е. это отношение является допустимым по условиям задачи, но не может быть получено при вашей схеме.
Нет. такое отношение не является допустимым по условию задачи,
поскольку в нем нарушена функциональная зависимость С от А (или А от С, что то же самое).

По условию задачи
NkeyЕсть задание:
Дан набор функциональных зависимостей.
Выполнить преобразование отношения в набор НФБК – отношений.
То есть кроме набора функциональных зависимостей больше не дано ничего.
К.Дейт. Введение в системы баз данных, М., Наука, 1980, 464 с. Функциональная зависимость

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

Если задано отношение R, то мы говорим, что атрибут Y отношения R
функционально зависит от атрибута X отношения R тогда и только тогда,
когда каждое значение X в отношении R в каждый момент времени
связано точно с одним значением Y.

Заметим, что одно и то же значение X может появиться в нескольких различных кортежах отношения R.
Если Y функционально зависит от X, то по определению каждый из этих кортежей должен содержать также одно и то же значение Y .


И? Какое из нарисованных ФЗ нарушено? А->C не нарушено.У С всего одно значение = 1. Вообще если обратили внимание, там для простоты у всех одно значение, кроме А. Потому все ФЗ с картинки не нарушены. Но зато там нарушено C->А. Это показывает, что C->А не выводится из заданных в задаче.
А без него CA ([C], A) не позволит все допустимые состояния отношения по условию задачи состояния. И Ваша схем не подходит.

Там же простой пример. Укажите, плиз, вот на картинке есть ФЗ, а в примере оно нарушено, потому оно не допустимо.


Т.е. Вы начать то начали "с введения понятия", но как бы не закончили.

SQL*PlusНет. такое отношение не является допустимым по условию задачи,
поскольку в нем нарушена функциональная зависимость С от А (или А от С, что то же самое).


Так мой пример показывает, что не одно и то же. И если бы было одно и то же, то боюсь что-то не срослось в нынешнем определении НФ3 и НФБК как минимум.