Какую нормальную форму нарушает эта таблица? - PullRequest
4 голосов
/ 03 октября 2011

Рассмотрим эту таблицу:

   +-------+-------+-------+-------+  
   | name  |hobby1 |hobby2 |hobby3 |  
   +-------+-------+-------+-------+   
   | kris  | ball  | swim  | dance |  
   | james | eat   | sing  | sleep |  
   | amy   | swim  | eat   | watch |  
   +-------+-------+-------+-------+

Нет приоритета для типов хобби, поэтому все хобби принадлежат одному домену.То есть, хобби в таблице можно перенести на любой столбец hobby#.Не имеет значения, в каком столбце конкретное хобби может находиться в любом столбце.

Какое правило нормализации базы данных нарушает эта таблица?


Редактировать

Q.Является ли «список хобби [...] в произвольном порядке»?

A.Да.

Q.Есть ли у таблицы первичный ключ?

A.Да, предположим, что ключ имеет тип столбца AUTO_INCREMENT с именем user_id.

Вопрос в том, являются ли столбцы hobby# повторяющимися группами или нет.


Sidenote : Это не домашняя работа.Это своего рода дискуссия, которая началась в комментариях к вопросу SQL - сопоставление записей из одной таблицы в другую на основе нескольких столбцов .Я считаю, что этот вопрос является ярким примером нарушения 1NF.

Однако другой парень считает, что я " упал из-за одной из ошибок 1NF. " Этот аргумент основан на разделе "Неоднозначность повторяющихся групп" статьи Факты и заблуждения относительно первой нормальной формы .

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

Ответы [ 6 ]

10 голосов
/ 03 октября 2011

Вы говорите, что хобби принадлежат одному домену и что они могут перемещаться в столбцах.Если под этим вы подразумеваете, что для любого конкретного name список хобби находится в произвольном порядке, и крисс может так же легко танцевать, играть в мяч, плавать как мяч, плавать, танцевать, то я бы сказал, что у вас есть повторяющаяся группа итаблица нарушает 1NF.

Если, с другой стороны, существует фундаментальное семантическое различие между первым и вторым увлечением конкретного человека, то может быть аргумент, что хобби не являются повторяющимися группами, атаблица может быть в 3NF (при условии, что столбцы хобби соответствуют FK для таблицы хобби).Я хотел бы предположить, что этот аргумент, если он существует, является слабым.

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

6 голосов
/ 04 октября 2011

Ваш дизайн стола с тремя хобби, вероятно, нарушает то, что я обычно называю духом оригинального 1NF ( вероятно по причинам, указанным dportas и другими). ​​

Оказывается, однако, что чрезвычайно трудно найти [набор] формальных и точных «измеримых» критериев, которые точно выражают этот оригинальный «дух». Это то, что ваш другой парень пытался объяснить, говоря о «двусмысленности повторяющихся групп».

Здесь ударение «формальное», «точное» и «измеримое». Существуют определения для всех других нормальных форм, которые удовлетворяют «формальным», «точным» и «измеримым» (то есть объективно наблюдаемым). Для 1NF это просто сложно (/ невозможно ???) сделать. Если вы хотите понять почему, попробуйте это:

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

Нельзя просто сказать, что «имена столбцов совпадают, за исключением нумерованного суффикса». Для объективного наблюдения / измеримости нарушения такого правила потребуется перечислить все возможные способы суффиксов.

Нельзя просто сказать «плавать, играть в теннис» с тем же успехом, как «теннис, плавать», потому что для того, чтобы узнать это наверняка, необходимо проверить внешний предикат таблицы. Если это просто «человек имеет хобби и также имеет », то действительно оба одинаково действительны (за исключением: и из-за предположения о замкнутом мире это фактически потребовало бы всех возможных перестановок хобби для присутствовать в таблице !!!). Однако, если этот внешний предикат «человек тратит больше всего времени на и наименьшее на », то «плавать, теннис» может НЕ одинаково хорошо быть «теннисом, плавать» ». Но как вы делаете такие интерпретации внешнего предиката цели таблицы (для ВСЕХ ВОЗМОЖНЫХ ПРЕДИКАТОВ) ???

и т.д.. и т.д.

5 голосов
/ 03 октября 2011

Это явно "выглядит" как ошибка проектирования.

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

Давайте рассмотрим эти отношения:

  • Хобби1 - главное хобби в какой-то момент жизни человека (например, до 18 лет)
  • Хобби2 - это хобби в другом месте (19-30)
  • Хобби3 - это ее хобби в другом.

Тогда эта таблица, кажется, определенно хорошо спроектирована, и, хотя соблюдается соглашение 1NF, присвоение имен возможно "отстой".

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

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

Давайте учтем усилия, необходимые для работы с вашими данными, когда ваша база данных будет использоваться другим разработчиком или командой:

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

Вы в основном создаете разочарование, гнев и ненависть, и Сила встревожена.

3 голосов
/ 03 октября 2011

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

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

3 голосов
/ 03 октября 2011

Ну

Дело в том, что, пока все значения hobby1, hobby2 и hobby3 не равны null, И имена уникальны , эта таблица может считаться более или менее не соответствующей правилам 1NF (см. вот например ...)

Но у всех есть 3 хобби? Конечно, нет! Не забывайте, что базы данных в основном должны содержать данные как представление реальности! Таким образом, из всех теорий нельзя сказать, что у всех есть 3 хобби, кроме случаев, когда ... наша таблица создана для хранения данных, связанных с people that have three hobbies without any preference between them!

При этом, и если предположить, что мы в общем случае, правильная модель может быть

+------------+-------+
| id_person  |name   |
+------------+-------+  

для лиц (не забудьте уникальный ключ. Я не думаю, что «имя» является хорошим

+------------+-------+
| id_hobby   |name   |
+------------+-------+ 

для хобби. Ключ id_hobby теоретически не обязателен, так как ключом может быть имя хобби ...

+------------+-----------+
| id_person  |id_hobby   |
+------------+-----------+  

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

Мое предложение является базовым и удовлетворяет теории. Это можно улучшить многими способами ...

2 голосов
/ 03 октября 2011

Если любой из столбцов в таблице принимает пустые значения, то таблица нарушает первую нормальную форму.При условии отсутствия нулей, @dportas уже предоставил правильный ответ.

...