Как определить функциональные зависимости

Ответ 1

Если "username" является как уникальным, так и обязательным (уникальным, а не нулевым), тогда это ключ-кандидат. В реляционном моделировании нет теоретической разницы между одним ключом кандидата и другим. Более конкретно, в реляционном моделировании нет никакой теоретической причины для выбора одного ключа-кандидата и маркировки его "первичного ключа". Ключ - это ключ.

Итак, ты прав. Здесь есть две функциональные зависимости. (Или 8, если вы разложите правую сторону на отдельные столбцы. user_id -> username, user_id -> regDate и т.д.)

Ответ 2

Функциональные зависимости определяются с теоретической точки зрения следующим образом (Wikipedia):

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

С технической точки зрения вы пытаетесь найти атрибуты, которые однозначно идентифицируют другие атрибуты. В качестве ярлыка определите ключи кандидата и атрибуты, которые зависят от них. Ваши примеры верны, потому что username, regDate, type, and subscription все зависит от значения user_id. Если username является уникальным и не является нулевым, это ключ-кандидат, а также идентифицирует набор атрибутов.

Ответ 3

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

• "Функциональная зависимость" A- > B просто означает, что никакие два разных значения B никогда не связаны с одним и тем же A. Немного более формальное определение дается на Wikipedia, но по существу это.
• Поскольку ключ должен быть уникальным, даже если два кортежа содержат одно и то же значение некоторого атрибута (-ов), значения ключа должны быть разными. Таким образом, разные значения никогда не могут относиться к одному и тому же значению ключа.

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

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

Ответ 4

Предполагаю, что вы используете MySQL, но если нет, вы можете реализовать свою идею в любой другой СУБД.

Выполните следующую команду, чтобы получить все ваши таблицы:

show tables;

Затем перетащите все таблицы и выполните следующую команду для каждого из них:

show columns;

FD могут быть описаны следующим образом:

Determinant -> Dependent,
Determinant = {A1, ..., Am},
Dependent = {B1, ..., Bn}

где Ai и Bj - столбцы. Вам нужно сгенерировать все возможные сценарии для Determinant и Dependent. Для каждого сценария вам нужно будет посмотреть, существует ли как минимум две отдельные записи, где совпадают столбцы определителя, и по крайней мере один из зависимых столбцов не совпадает. Если это так, то сценарий не является FD, иначе это FD. Пример: предположим, что m = 3 и n = 2:

select count(*) from mytable t1, mytable t2 where ((t1.A1 = t2.A1) and (t1.A2 = t2.A2) and (t1.A3 = t2.A3)) and ((t1.B1 <> t2.B1) or (t1.B2 <> t2.B2))

вернет число записей, которые нарушают правило FD. Если значение равно 0, то сценарий представляет собой FD.

Конечно, в вашем конкретном случае вы можете опустить несколько шагов, и у вас есть ваши столбцы вместо Ai и Bj, но вы, надеюсь, понимаете идею.