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

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

по вашей ссылке речь идёт не об отношении ProfessorTable,
а об отношении Enrollment
И профессор в нём не может не быть частью первичного ключа, при условии, что профессор ведет единственный предмет.
p_id там - идентификатор студента, записавшегося на курс к профессору, а не идентификатор самого профессора, или курса, который он ведет.

Имхо, это целиком неверное утверждение.

ФЗ выводятся формально только из состава данных и вообще не предполагают
никакой модели предметной области.

"Модель предметной области" - это просто из другого контекста, и такой терминологии не предполагается и не используется для показа фактически существующих в данных ФЗ.
ФЗ выявляются и демонстрируются на фактических данных сейчас представляющих весь доступный для анализа мир.
Не только "модели предметной области" нет, но и никаких других данных нет.
Все дано статично и сразу.
На этом выявляется ФЗ. Только на (заданном) составе данных и больше ни на чём.


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

касательно введения суррогатного ключа - конечно ФЗ между суррогатным и естественным ключём просто всегда есть в обе стороны, и иначе быть не может.
Вместе они образуют суперключ.
И это не противоречит 3НФ, но не соответствует НФКБ

То есть зависимость между плотностью, объёмом и весом не может быть выявлена до наполнения
БД данными. Прелестно...

конечно не может.
нет ни "веса", ни "объёма".

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

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

тот, кто знает про вес и объем - иначе называется
У него и задача другая .
Не "функциональные зависимости в данных" выявлять,
а объяснять пользователю, почему отношение отказывается зафиксировать
свое новое состояние, когда в третье поле 7 вместо 5 записывают.

Путем навязывания пользователю через реализацию своего модельного знания о предметной области.

ChA,

Вам, видимо, я что-то должен ответить, на основании использования вашей цитаты в своем тексте.

авторВы уверены в своём утверждении ?
Да.

автор Какое количество кортежей будет достаточно, что бы можно было бы быть уверенным в том или ином ответе?
Такое, какое представляет весь мир конкретного отношения.

авторЦель РМД в проектировании баз данных, которые описывают множество данных, представимых в виде 2-мерных таблиц
а) В РМД нет таблиц . Совсем. Просто даже технического термина такого - таблица - в РМД нет .
б) Даже если бы они там были, то и этом случае, их проектированием РМД не интересуется .

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

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

авторЕсли бы такая ФЗ существовала, то, как ранее справедливо подметил Дмитрий, Вы бы смогли восстановить случайно стёртое значение EK по СК.
про затертое:

Никаких "стёртых значений" нет.
Само использование термина "стёртое" предполагает некую динамику.
Вот она ещё вчера была, а сегодня нету.
Число два ещё вчера существовало, как математический объект, а сегодня выпало из числового ряда, совсем пропало....
Допускаются пропущенные значения в неключевых атрибутах.
Так хотел Кодд, из практических соображений.
Дейт в этом месте видит теоретическую дырку.
Но это другой вопрос. А суть дела в том, что для целей алгебраических манипуляций,
когда речь идет о комбинировании набора отношений в новый объект
(это то, что в языке SQL обеспечивает Select) отношение всегда статический, целиком
заданный и неизменный в рамках операции объект.

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

Про восстановить:
Реляционную модель данных не интересует ваше умение восстановить "затертое"
значение плотности по сохранившимся значениям объема и массы.
Так же как ей не больно от того, что вы называете такое умение
знанием о функциональных зависимостях реального мира.

То, что она для себя называет функциональными зависимостями, относится только к тому специфическому способу анализа состава данных, который используется ею
в рассуждениях о нормальных формах представления отношений.
Любое утверждение о наличии или отсутствии такой зависимости происходит
по отношению только к составу данных и ни чему больше.
Только предъявив образец отношения с конкретным составом данных можно тыркать в него
пальцем и говорить - вот, видишь зависимость? - Смотри.
В этом смысле почти ничего нельзя восстановить.
И функциональные зависимости в данных не выявляются на пропущенных значениях.

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

-------------------------------------------
2 Pavel_from_Nsk
наверно вы правы.
я имел в виду то, что в НФБК стремятся к кратчайшей форме первичного ключа,
что в моём сознании ассоциируется с исключением избыточности.
Здесь, вероятно, перестарался.