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

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

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

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

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

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

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

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

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

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

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

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

show tables;

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

show columns;

ФД можно описать следующим образом:

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

где Ai и Bj — столбцы. Вам нужно сгенерировать все возможные сценарии для Determinant и Dependent. Для каждого сценария вам нужно будет просмотреть, существуют ли хотя бы две отдельные записи, в которых столбцы определителя совпадают, а хотя бы один из зависимых столбцов не совпадает. Если да, то сценарий не является ФД, в противном случае - ФД. Пример: Предположим, что 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 у вас будут свои столбцы, но, надеюсь, вы поняли идею.