Таблица с уникальным идентификатором в третьей нормальной форме?

Повторите свой первоначальный вопрос:

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

Но давайте предположим, что {first_name,last_name} и {person_id} действительно являются единственными CK и что нет никаких FD, кроме тех, которые подразумеваются тем фактом, что каждый CK определяет все атрибуты, не входящие в него.

Функционально между этим идентификационным номером и днем ​​рождения нет никакой связи.

Я не знаю, что вы подразумеваете под «функционально между ними нет никакой связи». Возможно, вы пытаетесь сказать, что {person_id} функционально не определяет {день рождения}. Но это так, потому что CK определяет все атрибуты не в нем. Возможно, вы имеете в виду, что не видите ограничение приложения между идентификаторами людей и днями рождения и/или ограничение таблицы, включающее значения таблицы person_id и дня рождения. Но есть: у данного человека только один день рождения за раз, а в таблице person_id только один день рождения за раз. Это следствие значения и правил, касающихся «людей», «дней рождения», person_id и дня рождения. Ограничение на person_id и день рождения выражается как "{person_id} -> {birthday}", и вы должны знать, так ли это, как часть определения исходного списка всех FD (который предшествует определению CK).

S транзитивно определяет T, когда существует такое X, что S -> X и X -> T и not(X -> S). S нетранзитивно определяет T, когда оно не транзитивно определяет его.

1. Означает ли это, что существует транзитивная зависимость (день рождения зависит от [first_name, last_name], и ​​каждая комбинация [first_name, last_name] соответствует идентификатору) и, следовательно, не в 3NF?

Я не знаю, что вы пытаетесь сказать, говоря, что «каждая комбинация сопоставляется с идентификатором», не говоря уже о том, почему это подразумевает не-3NF. Возможно, вы пытаетесь сказать, что, взяв {person_id} за S и {день рождения} за T и {first_name, last_name} за X, мы имеем S -> X и X -> T, поэтому (ошибочно) непростой атрибут транзитивно зависим на CK, поэтому отношение не в 3NF. Но вас не удовлетворило не (X -> S).

Для {person_id} как S и {день рождения} как T единственная возможность для X -> T имеет {first_name,last_name} как X, но X -> S, потому что X является ключом, поэтому S -> T не является транзитивным.

Точно так же для {first_name,last_name} как S и {dayday} как T единственная возможность для X -> T имеет {person_id} как X, но X -> S, потому что X является ключом, поэтому S -> T не является транзитивным.

2. Означает ли это, что зависимости вообще нет, а значит, и не в 3NF?

Поскольку отношение in во 2NF и каждый непростой атрибут нетранзитивно зависит от каждого CK, отношение находится в 3NF.

3. Я неправильно истолковываю сложный язык, и эта таблица находится в 3NF?

Вы не утверждали, что это было или не было, не так ли?

(Пожалуйста, отредактируйте свой вопрос, чтобы использовать правильные технические термины.)

Повторите свою версию EDIT

(Вы признали в комментариях, что ваша последняя пуля должна была иметь CK 2 и что она была ненадежной. И что мои предположения о ваших неясных формулировках были более или менее тем, что вы имели в виду.)

• Все поля могут содержать только атомарные значения, поэтому таблица находится в первой нормальной форме.

Нормализация имеет смысл только для реляционных "таблиц", то есть отношений. Это означает уникальные неупорядоченные атрибуты («столбцы») и кортежи («строки»). С одним значением для каждого атрибута в кортеже. Все отношения находятся в 1NF.:

Реляционная таблица всегда находится в 1NF. Каждый столбец строки имеет одно значение типа столбца. Нереляционная база данных "нормализована" до таблиц, т.е. 1NF (первое значение слова "нормализованный"), что избавляет от повторяющихся групп. Затем эти таблицы/отношения «нормализованы» до более высоких нормальных форм (второе значение слова «нормализовано»).

"Атомный" не помогает: "Атомный" изначально означал не отношение.:

В исходной статье Кодда 1970 года он объяснил, что "атомный" имелось в виду не отношение (т.е. не таблица):

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

Ко времени выхода книги Кодда 1990 года Реляционная модель управления базами данных: Версия 2:

С точки зрения базы данных данные можно разделить на два типа: атомарные и составные.

В реляционной модели есть только один тип составных данных: отношение.

А отношение — это единственное значение, поэтому нет ничего плохого в атрибутах со значением отношения. (Изменение мнения Пейса Кодда по этому поводу.)

• Ключи-кандидаты: 1) {person_id}, 2) {first_name, last_name}
• Единственным непростым атрибутом является {день рождения}.

Для нормализации вы должны знать для каждого подмножества атрибутов, какие атрибуты (нетривиально) функционально зависят от него. Хотя каждый надмножество определителя определяет, что он делает, так что это касается многих из них. Вы пропустили этот шаг.

Вы не можете показать, что {first_name,last_name} является CK, не показав, что {first_name} и {last_name} не являются CK через то, что каждый из них определяет. Предполагая, что вы это сделаете, вы все равно не будете рассматривать оставшиеся возможные детерминанты {first_name,birthday} и {last_name,birthday}.

Вы не можете показать, что это единственные CK, пока не покажете, что других CK нет. Вы должны показать для каждого подмножества атрибутов, является ли оно CK. Хотя ни один из надмножеств CK не является CK, так что это касается многих из них. Есть алгоритмы.

• Существует ФЗ {person_id} -> {день рождения}, поэтому атрибут {день рождения} нетранзитивно зависит от СК 1
• Существует ФЗ {имя, фамилия} -> {день рождения}, поэтому атрибут {день рождения} нетранзитивно зависит от СК 2

Ваши новые последние две пули неоправданны. Посмотрите на определение моего сообщения и использование «(не) транзитивно зависимого»; просто зная S -> T недостаточно. Когда есть нетранзитивное FD S -> X -> T, также должно быть, что S -> T; поэтому знание S -> T само по себе не говорит вам о том, транзитивно или нетранзитивно S определяет T. «->» не означает «непосредственно»; нетранзитивно - единственное значимое понятие «непосредственно».

Может быть, под «так» вы подразумеваете «так, как показано ниже для первого из этих двух случаев»?

Есть зависимость {person_id} -> {first_name, last_name} -> {день рождения}, но так как есть и прямая зависимость {person_id} -> {день рождения}, эта зависимость не является транзитивной.

См. выше: «прямой» — это заблуждение. И, как я уже сказал в своем первоначальном ответе, это с {first_name, last_name} -> {person_id} для CK1 и {person_id} -> {first_name, last_name} для CK 2.

У меня нет предопределенного набора FD из книги, поэтому я не уверен, верны ли FD. Может ли кто-нибудь подтвердить это или, если они выглядят не так, показать, как я могу найти FD в этом практическом примере?

Вы должны рассмотреть все возможные значения, которые может иметь таблица, из-за каждой возможной ситуации приложения, которая может возникнуть, и критерий (предикат), по которому вы должны помещать строки в таблицу, а не оставлять их. Вероятно, вы можете придумать контрпримеры к предполагаемым FD, где две строки могут иметь одно и то же значение для предполагаемого определителя. Например, для {first_name,birthday} и {last_name,birthday} вы можете ожидать, что у двух разных людей будут одинаковые имена и дни рождения. (Вы можете проверить два последних предполагаемых FD.)

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

Ваша вторая версия EDIT:

Теперь кажется, что вы, вероятно, все сделали добротно. (Хотя я не могу знать наверняка, потому что вы специально не разъясняете, что больше нет двухэлементных наборов атрибутов и больше нет наборов атрибутов; почему эта пара является набором CK; и 2NF/3NF " поэтому "с.)

Фразы типа «Если вы знаете фамилию и день рождения человека, вы не знаете никаких других полей этого человека» проблематичны. Я: Если я знаю только две области, то, конечно, я не знаю других; так что никогда не бывает FD? Вы: Для человека. Я: Но если я знаю человека, то я знаю его имя; так есть ФД? Вы: Если вы знаете имя и день рождения одного человека, но не знаете кого; вы не знаете никакой другой области. Я: Иногда я знаю другие области; таким образом, импликация ложна; так есть ФД? Оказывается, «знать» — это очень запутанное слово, которого лучше избегать. Пишите: "Дано... существует...". Как вы сделали в "(не может быть нескольких ...)".