Подтвердить что ты не робот

Что такое хорошее описание KISS нормальной формы Бойса-Кодда?

Что такое способ KISS (Keep the Simple, Stupid), чтобы помнить, что является нормальной формой Boyce-Codd, и как принимать ненормализованную таблицу и BCNF?

Wikipedia info: не очень полезно для меня.

4b9b3361

Ответ 1

Определение даты Криса на самом деле неплохо, если вы понимаете, что он означает:

Каждый атрибут

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

должен представлять факт

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

о ключе,

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

весь ключ,

Один ключ должен быть достаточным [и необходимо!], чтобы идентифицировать ваши ценности; вы не можете иметь одни и те же данные, представленные разными ключами, и не может быть достаточным подмножество ключевых столбцов для идентификации факта. Предположим, у вас была адресная книга с ключом GUID, именем и адресом. Вполне возможно, что одно и то же имя появляется дважды с разными ключами, если они представляют разные люди и не являются "теми же данными". Если Мэри Джонс в бухгалтерском учете меняет свое имя на Мэри Смит, Мэри Джонс в Продажи не изменяет ее имя. С другой стороны, если Мэри Смит и Джон Смит имеют один и тот же адрес улицы, и это действительно одно и то же место, это не допускается. Вы должны создать новую пару ключ/значение с адресом улицы и новым ключом.

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

и ничего, кроме ключа

Не должно быть ничего, кроме ключа, который идентифицирует ваши значения. Например, если вам разрешен адрес "Тадж-Махал" (если есть только один), вам не разрешено значение города в той же записи, поскольку, если вы знаете адрес, вы также знаете город. Это также откроет возможность существования более одного Тадж-Махала в другом городе. Вместо этого вам нужно снова создать дополнительный ключ местоположения с уникальными значениями, такими как Taj, Белый дом в DC и т.д. И их города. Или запретите "адреса", которые уникальны для города.

Так помогите мне, Кодд.

Ответ 2

Вот некоторые полезные отрывки со страницы Википедии на Третья нормальная форма:

Билл Кент определяет третью нормальную форму следующим образом:

Каждый неключевой атрибут "должен обеспечивать факт о ключе, весь ключ, и ничего, кроме ключа".

Требование о том, чтобы неключевые атрибуты были в зависимости от "всего ключа" обеспечивает что таблица находится в 2NF; в дальнейшем требуя, чтобы неключевые атрибуты были в зависимости от "ничего, кроме ключа", гарантирует, что таблица находится в 3NF.

Chris Date адаптирует мнемонику Кента для определения нормальной формы Boyce-Codd:

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

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

Что касается того, как сделать таблицу удовлетворяющей BCNF, вам нужно представить дополнительную зависимость, с другим атрибутом и, возможно, путем разделения атрибутов на другую таблицу.

Ответ 3

Я googled "boyce codd нормальная форма", а после wikipedia это второй результат. Мой учебник дает очень простое определение в терминах систем управления реляционными базами данных:

Левая часть каждого нетривиального FD должна быть суперключем.

- "Системы баз данных Полная книга" Гарсиа-Молина, Ульман и Видом.

Ответ 4

В основном Boyce-Codd является "пятой нормальной формой". Он визуально узнаваем из-за существования "атрибутивных сущностей" в модели данных для таких вещей, как типы (например, роли, статус, состояние процесса, тип местоположения, тип телефона и т.д.). Атрибутивные объекты (подтипы) представляют собой списки конечных наборов значений, которые далее классифицируют объект уровня класса. Таким образом, у вас может быть тип учетной записи телефона ( "мобильный", "рабочий стол", "VOIP" ) ( "бизнес", "личный", "игровой" ), роль (диспетчер проектов, модель данных данных, супермодель) и т.д., Другим морфологическим понятием является существование супертипов (например, мастер-классы, суперклассы, мета-сущности), такие как "Стороны" (подтипы - компания, человек и т.д.).

В основном таксономия ушла в дикую природу (..не видео не так увлекательно) на атомный или листовой уровень; см. комментарий Билла Карвина выше для более подробного объяснения.

Модели уровня Boyce-Codd представляют собой, по существу, очень подробные логические модели, полученные из более упрощенных концептуальных моделей на основе бизнеса. ** Обычно они не реализованы в модели PHYSICAL, поскольку оптимизация PDM для производительности (или простота функциональности) может привести к тому, что супертипы и атрибутивные объекты будут управляться как выпадающие списки в пользовательских интерфейсах или в логике за кулисами в приложении или в ограничениях и методах базы данных для обеспечения ссылочной целостности. (т.е. они могут оказаться в качестве смотровых таблиц в схеме PDM, или они могут обрабатываться кодом и не представлены в базе данных).

Итак - зачем им это делать, если они не могут попасть в PDM? По той же причине вы строите хорошую модель 3NF до того, как будете "оптимизировать", чтобы структура базы данных отражала реальный мир и, следовательно, была более стабильной, чем типичные kludges, которые мы наследуем, и должны делать героические действия, чтобы сделать работу нашим бизнесом/клиентами изменение требований.

Ответ 5

Лучший неофициальный ответ, который я прочитал, заключается в том, что в BCNF каждая "стрелка" в каждой функциональной зависимости является "стрелкой" из ключа кандидата. Я не помню источник, но это, вероятно, было написано Крисом Дайтом.

Ответ 6

Часто бывает проще слушать вашу кишку, и это будет естественно. Вообще говоря, если вы встретите 3NF, вы встретились с BCNF. Это не охватывает подробный анализ ERD или примеры, но в соответствии с Codd существует тринадцать правил. Я считаю, что лучше следовать этим правилам, но всегда помните, что нет никакого правильного способа делать вещи, поэтому следуйте за ними свободно. Итак, что касается СУБД, вот правила:

http://www.87android.com/12-rules-of-relational-database-model-by-codd/

Это может не ответить на вопрос напрямую, но если вы спрашиваете о том, как добраться до BCNF или просто запомнить, тогда вы недостаточно хорошо понимаете нормализацию. Это не вызывает беспокойства. Реляционные базы данных занимают много форм, и очень немногие из них выполнены хорошо. Лучшее, что вы можете сделать, это знать, что значит быть реляционным, следовать приведенным выше правилам и не беспокоиться об уровне нормализации. Процесс нормализации устраняет дублирование данных. Каждый уровень больше, переходя в миграцию функциональных зависимостей. Имейте это в виду, и вы будете в порядке, ваши кишки и интеллект сделают все остальное.