Какую обычную форму нарушает суррогатный ключ?

Question

У меня есть вопрос:

"Какая обычная форма нарушает суррогатный ключ?"

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

Answer 1

Возможно, суррогатный ключ не является естественным ключом таблицы, поэтому можно сказать, что нарушает 'Ничего, кроме ключа' Принцип 3nf. На практике суррогатный ключ - это всего лишь владелец для естественного ключа, поэтому этот аргумент в лучшем случае является академическим.

Некоторые неясные нормальные формы требуют, чтобы композитные клавиши стали актуальными. 5NF приходит на ум в этом случае, так как это требует множества перекрывающихся композитных клавиш на отношениях M: M, чтобы было возможным нарушение 5NF.

Answer 2

Возможно, это не так.

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

То есть введение суррогатных ключей в начале процесса проектирования неправильно. Хотя мы все это делаем ...

Answer 3

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

Это правда, что добавление суррогатного ключа подразумевает дополнительный набор зависимостей от этого ключа. По определению эти дополнительные зависимости - это присоединяются зависимости, подразумеваемые Superkeys, что означает, что 5NF и DKNF, например, не нарушаются. Единственным возможным исключением является то, что некоторое правильное подмножество атрибутов (частичное ключ) суррогата является определяющим фактором само по себе. Учитывая, что «суррогат» обычно означает единый ключ атрибута, значения которых являются произвольными, такая частичная зависимость ключа маловероятна.

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

Answer 4

Принятый ответ неверен; Ответы, данные @SQLVOGEL и @GBN, верны.

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

Например, у нас может быть таблица с независимыми непересекающимися ключами (таблица с именем People с id, ssn, а также email как ключи). Оба ssn а также email Это естественные ключи (мы решили, что, учитывая только номер социального страхования или просто электронное письмо, которое мы можем однозначно идентифицировать человека). id является суррогатным ключом-ключом, который мы добавили для явной цели уникальной идентификации человека. Люди не склонны иметь ids, но отношения обычно имеют суррогатный ключ названный id. Анкет Итак id Ключ не вытекает из области личности.

Что сказано, id, email, а также ssn каждый функционально определяет все другие атрибуты на Person стол. Все это ключи от кандидатов (и, следовательно, насорешники).

Нарушения BCNF происходят, когда либо не ключевые атрибуты функционально определяют другие атрибуты, либо когда только часть ключа-кандидата определяет другие атрибуты. Поскольку каждый атрибут сам по себе является ключом кандидата, нарушений BCNF не существует.

Разве ключ не должен быть минимальным?

Что, если суррогатный ключ стоит для составного естественного ключа? Например, Films стол, где title а также original_release_date объединить, чтобы сформировать естественный ключ и id Поле действует как суррогатный ключ. Разве {title, original_release_date} ключ нарушает требование, чтобы ключ был минимальным?

Это заблуждение об определении минимальности. То, что суррогатный ключ состоит из меньшего количества атрибутов, чем естественный ключ, не означает, что это единственный минимальный ключ. Ключ -кандидат минимален, если нет надлежащего подмножества ключа, которое также является ключом кандидата. title не уникально идентифицирует Film, и тоже тоже original_release_date. Анкет Следовательно, даже в случае, когда суррогатный ключ стоит для составного естественного ключа, нет нормального нарушения формы.

Answer 5

Они нарушают 3nf.

Это нормально, когда у вас есть нормальная модель и решайте денормализовать здесь и там разумно. Но не тогда, когда вы моделируете с суррогатами с самого начала.

• Как узнать, что вы нарушаете 3NF?

Цитата из книги «Использование SQLite», Jay A. Kreibich, O'Reilly

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

...

Хороший способ распознать столбцы, которые могут сломать 3NF, - это искать пары или наборы не связанных столбцов, которые необходимо хранить в синхронизации друг с другом.

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

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

Цитата от Грега Максвелла, Core-Developer или Bitcoin:

... для экспертов в базе данных: реальная проблема заключается в том, что MT Gox (и другие обмены) используют суррогатный идентификатор транзакции, а не естественный ключ в своих базах данных: «Недостаток не столько в биткойнах, сколько в обмене- Системы. Многие обмены используют TX-ID для уникальной идентификации транзакций, но, как выясняется, злоумышленник может изменить TX-ID без изменения фактической транзакции, переключите измененную транзакцию (эффективно создавая двойное воздействие) и если он изменил Транзакция принимается в блок вместо законной транзакции, злоумышленник получает свои монеты и может жаловаться на обмен, который он не сделал. блокчейн и не найти его. Таким образом, они могут сделать вывод, что транзакция действительно потерпела неудачу и зачислена учетная запись с монетами. ... Простой обходной путь-не использовать TX-ID для идентификации транзакций на стороне обмена, но (сумма, Адрес, временная метка) вместо этого. "

Цитата от здесь а также здесь

Так что спросите себя:

• Есть ли в этой таблице единый атрибут без PK, который, если бы он был изменен произвольным, не позволят пользователю извлечь данные?

Если это так, вы нарушаете 3NF.

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