Может ли отношение быть в 3NF с несколькими внешними ключами?

Question

Я думаю, что это довольно просто, но я новичок в этом.Я пытаюсь нормализовать таблицу.Может ли отношение быть 3NF с несколькими внешними ключами?Это 3NF:

• TALENTPAYMENT (PAYMENTNUMBER, дата, промежуточный итог, налог, общая сумма, talentid, номер агента)

или его необходимо разбить на:

• TALENTPAYMENT (PAYMENTNUMBER, дата, промежуточный итог, налог, всего)

• TALENTPAYMENTID (PAYMENTNUMBER, talentid)

• ТАЛЕНТАГЕНТ (TALENTID, номер агента)

Answer 1

Я думаю, что большинство других ответов больше ориентированы на ваш пример, чем на ваш вопрос.

Если говорить непосредственно к вопросу, да, отношение может быть в 3NF, даже если оно имеет несколько внешних ключей. Ключевая (кашляющая) точка 3NF - удалить транзитивные зависимости, а не уменьшить количество внешних ключей.

Другими словами, нет такой вещи, как "У меня слишком много внешних ключей" в нормальной форме.

Answer 2

Это не 3NF, но не из-за ваших внешних ключей.У вас есть некоторые функциональные зависимости, левая сторона которых не является ключом-кандидатом:

subtotal,tax   -> total
subtotal,total -> tax
tax,total -> subtotal

Алгоритм сокращения до 3NF скажет разделить вашу схему на:

PAYMENTNUMBER | date | subtotal | tax | talentid | agentnumber

и

subtotal | tax | total

В этот момент, предполагая, что "talentid -> agentnumber" или наоборот не являются зависимостями, схема находится в 3NF, но ваша (промежуточный итог, налогИтого) таблица в основном бесполезна, так как при сохранении всех трех очевидная избыточность.Было бы лучше просто использовать:

PAYMENTNUMBER | date | subtotal | tax | talentid | agentnumber

И не хранить общее количество вообще.Если вы хотите получить его в запросе, вы можете просто SELECT (subtotal+tax) as total при условии, что промежуточный итог и налог оба являются числовыми типами.

Answer 3

Ваша схема из трех частей предполагает наличие функциональной зависимости talentid ⟶ agentnumber , в этом случае ваше отношение не может быть в BCNF (3NF), поскольку talendtid не является одним из ключей для отношения.

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

Answer 4

Это все равно не в 3NF, так как итог = промежуточный итог + налог (или наоборот; я плохо разбираюсь в итоговом и промежуточном итогах).

Чтобы быть в 3NF, у вас не должно быть транзитивных функциональных зависимостей с непростыми атрибутами. Удалите производный атрибут (итоговый или промежуточный), и я считаю, что ваше решение - ОК.

В этом отношении оригинал может быть в порядке, но для проблемы, о которой я упоминаю.