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

Question

Что такое ПОЦЕЛУЙ (Keep it Simple, Stupid), способ запомнить, что такое нормальная форма Бойса-Кодда и как взять ненормализованный стол и BCNF?

Википедия * Информация о 1004 *: не очень полезна для меня.

Answer 1

Определение Криса Дейта на самом деле очень хорошее, если вы понимаете, что он имеет в виду:

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

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

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

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

о ключе,

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

весь ключ,

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

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

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

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

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

Answer 2

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

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

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

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

Крис Дата адаптирует мнемонику Кента для определения нормальной формы Бойса-Кодда:

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

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

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

Answer 3

Я погуглил "нормальную форму Бойса Кодда" и после википедии это второй результат. Мой учебник дает очень простое определение в терминах систем управления реляционными базами данных:

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

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

Answer 4

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

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

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

Answer 5

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

По сути, таксономия сходит с ума (..но видео не настолько захватывающее) до атомного или конечного уровня; см. комментарий Билла Карвина выше для более технического объяснения.

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

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

Answer 6

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