Нормализация базы данных с многозначной зависимостью (4NF / 5NF) - PullRequest
0 голосов
/ 17 февраля 2012

Я планирую сделать работу базы данных портала. Здесь у меня есть несколько кандидатов, подписывающихся на некоторые уведомления.

Table preview

(конечно, имя кандидата будет идентификатором, и у кандидата будет больше столбцов, связанных с человеком, которые не показаны.) Я запутался, является ли это 4-й или 5-й нормальной проблемой формы! и мне нужна помощь, чтобы уменьшить избыточность.

Могу ли я разделить это на что-то вроде этих таблиц, не теряя информацию IsEnabled, чтобы я мог удалить избыточность?

Candidate Table

и

Notification Table

Возможно ли это или это случай неизбежной избыточности?

1 Ответ

4 голосов
/ 17 февраля 2012

Это не нормальная проблема формы, с какой бы стороны вы на нее ни смотрели.

Если вы хотите сохранить эту первую таблицу такой, какая она есть (включая логический атрибут), то у вас есть CONSTRAINT . В этой первой таблице должна присутствовать строка для каждой возможной комбинации (кандидат, тип уведомления). Но это не проблема НФ! Это было бы только проблемой NF, если бы было как-то возможно определить, каким должно быть логическое значение, учитывая только кандидата или только тип уведомления.

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

Отключите логический атрибут и запишите только те строки в этой первой таблице, которые имеют "true". Теперь у вас больше нет этого ограничения, и все, что есть - это просто обычная таблица «соединений», связывающая кандидатов с включенными типами уведомлений, точно так же, как в базах данных по всему миру существует миллионы таблиц «соединений».

...