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

Предположим, у меня есть таблица с колонками:

  • person_id (первичный ключ)
  • имя
  • Фамилия
  • день рождения

У меня также есть уникальное ограничение на комбинацию {first_name, last_name} (я знаю, что больше людей могут иметь одно и то же имя, но я хочу, чтобы мой пример был простым). Я хочу знать, находится ли эта таблица в третьей нормальной форме.

Мои рассуждения (до РЕДАКТИРОВАНИЯ):

  • Все поля могут содержать только атомарные значения, поэтому таблица находится в первой нормальной форме.
  • Ключи-кандидаты: 1) person_id, 2) [first_name, last_name]
  • Единственный непростой атрибут - это день рождения.
  • Атрибут дня рождения функционально не зависит от части ключа-кандидата 1 (что в любом случае невозможно, поскольку в ключе-кандидате 1 имеется только 1 атрибут)
  • Атрибут дня рождения функционально не зависит от части ключа-кандидата 2
  • Таким образом, эта таблица находится во второй нормальной форме.
  • Атрибут дня рождения (есть / нет) нетранзитивно зависит от ключа-кандидата 1
  • Атрибут дня рождения не зависит от ключа-кандидата 1

Вопрос (до РЕДАКТИРОВАНИЯ):

Вопрос, на который я не могу ответить, состоит в том, является ли день рождения нетранзитивно зависимым от person_id. Функционально, вообще нет никакой связи между этим номером и днем ​​рождения.

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

Мои рассуждения (после РЕДАКТИРОВАНИЯ):

  • Если вы знаете person_id, вы знаете его имя, фамилию и день рождения, поэтому есть FD {person_id} -> {first_name}, {person_id} -> {last_name} и {person_id} -> {birthday}.
  • Если вы знаете имя и фамилию человека, вы знаете его person_id и день рождения, поэтому есть FD {first_name, last_name} -> {person_id} и {first_name, last_name} -> {birthday}.

  • Если вы знаете день рождения человека, вы ничего не знаете о его person_id или имени, поэтому нет никаких FD от дня рождения до другого (набора) атрибутов.

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

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

  • Таким образом, эта таблица находится во второй нормальной форме.

  • Существует FD {person_id} -> {birthday}, поэтому атрибут {birthday} не транзитивно зависит от CK 1

  • Существует FD {first_name, last_name} -> {birthday}, поэтому атрибут {birthday} не транзитивно зависит от CK 2
  • Следовательно, эта таблица находится в третьей нормальной форме.

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

Вопрос (после РЕДАКТИРОВАНИЯ):

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

Третье рассуждение (второе РЕДАКТИРОВАНИЕ):

ФЗ:

  • Если вы знаете только person_id человека, вы знаете его имя, фамилию и день рождения (не может быть нескольких людей с одним person_id)
    • FD: {person_id} -> {first_name}
    • FD: {person_id} -> {last_name}
    • FD: {person_id} -> {день рождения}
  • Суперсеты, включающие {person_id}, больше не нужно рассматривать
  • Если вы знаете только имя человека, вы не знаете ни одного другого поля этого человека (может быть несколько человек с одним именем)
    • Не FD: {first_name} -> {person_id}
    • Не FD: {first_name} -> {last_name}
    • Не FD: {first_name} -> {день рождения}
  • Если вы знаете только фамилию человека, вы не знаете ни одного другого поля этого человека (может быть несколько человек с одним и тем же именем)
    • Не FD: {last_name} -> {person_id}
    • Не FD: {last_name} -> {first_name}
    • Не FD: {фамилия} -> {день рождения}
  • Если вы знаете только день рождения человека, вы не знаете ни одной другой области этого человека (может быть несколько человек с одним днем ​​рождения)
    • Не FD: {день рождения} -> {person_id}
    • Не FD: {день рождения} -> {имя_первой}
    • Не FD: {день рождения} -> {фамилия}
  • Если вы знаете имя и фамилию человека, вы знаете его идентификатор человека и его день рождения (не может быть нескольких людей с одинаковыми именем и фамилией)
    • FD: {first_name, last_name} -> {person_id}
    • FD: {имя, фамилия} -> {день рождения}
  • Суперсеты, включающие {first_name, last_name}, больше не нужно рассматривать
  • Если вы знаете его имя и день рождения, вы не знаете ни одного другого поля этого человека (может быть несколько человек с одинаковыми именем и днем ​​рождения)
    • Не FD: {имя, имя, день рождения} -> {person_id}
    • Не FD: {имя, имя, день рождения} -> {фамилия}
  • Если вы знаете фамилию и день рождения человека, вы не знаете ни одного другого поля этого человека (может быть несколько человек с одинаковыми фамилией и днем ​​рождения)
    • Не FD: {фамилия, день рождения} -> {person_id}
    • Не FD: {фамилия, день рождения} -> {первое имя}

Нормальные формы:

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

  • Глядя на FD, есть два ключа-кандидата: 1) {person_id}, 2) {first_name, last_name}

  • Единственный непростой атрибут - это день рождения.
  • Атрибут {birthday} не является FD на части CK 1 (что в любом случае невозможно, так как в CK 1 имеется только 1 атрибут)
  • Атрибут {birthday} не является FD на части CK 2 (т.е. нет FD {first_name} -> {birthday} или FD {last_name} -> {birthday})

  • Таким образом, эта таблица находится во второй нормальной форме.

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

  • Пусть S = CK1 = {person_id} и T = {день рождения}. Единственный X такой, что S -> X и X -> T - это когда X = {first_name, last_name}. Однако тогда также выполняется X -> S. Следовательно, S нетранзитивно определяет T.
  • Пусть S = CK2 = {first_name, last_name} и T = {birthday}. Единственный X такой, что S -> X и X -> T - это когда X = {person_id}. Однако тогда также выполняется X -> S. Следовательно, S нетранзитивно определяет T.
  • Следовательно, эта таблица находится в третьей нормальной форме.
Источник

1 ответ

Решение

Re ваш оригинальный вопрос:

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

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

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

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

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

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

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

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

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

  1. Означает ли это, что нет никакой зависимости вообще, и, следовательно, не в 3NF?

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

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

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

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

Re ваша версия EDIT

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Существует FD {person_id} -> {birthday}, поэтому атрибут {birthday} не транзитивно зависит от CK 1
  • Существует FD {first_name, last_name} -> {birthday}, поэтому атрибут {birthday} не транзитивно зависит от CK 2

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

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

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

Смотри выше: "прямой" - это неправильное представление. И, как я сказал в своем первоначальном ответе, это так: {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.)

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

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

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

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

Источник
Другие вопросы по тегам