Нормализация базы данных - насколько глубоко я должен связать таблицы вместе?

Question

У меня есть три таблицы: сообщение, вложение и медиа.

Сообщения имеют вложения, а вложения имеют медиа.

В настоящее время таблицы Post и Attachment связаны внешними ключами, как и таблицы Attachment и Media. Мой вопрос заключается в том, чтобы ради правильного проектирования и нормализации баз данных, я должен установить отношения внешнего ключа между Почтой и СМИ? Я не уверен, насколько глубоко я должен связать эти таблицы вместе.

Спасибо

Answer 1

ради правильного проектирования и нормализации базы данных, я должен установить отношение внешнего ключа между Почтой и СМИ?

Для "правильной нормализации" вы должны убедиться, что нет "аномалий обновления".

Если кто-то обновляет сообщение, что происходит с вложениями и медиафайлами? Будет ли переименование сообщения отключать вложения и / или медиа? Если это так, то ваш FK не так. [Подсказка, для работы вашего ФК вы должны использовать суррогатные ключи, а не название поста.]

Если кто-то хочет «переместить» вложение из одного сообщения в другое [то есть обновить ссылку на ФК вложения], что произойдет со СМИ? Останется ли это с приложением и переместится на новое сообщение?

Не могли бы вы получить сообщение с вложениями и медиа, а также с вложениями медиа? Могут ли Почта и Вложения не соглашаться в отношении СМИ, потому что Вложение было «перемещено», но Сообщение также не обновлялось?

Если у вас могут быть противоречия, вы нарушили 2-ую нормальную форму, и у вас есть повторяющиеся ключевые отношения, которые вы не должны были повторять.

Правильная нормализация проста.

Данные зависят от ключа и ничего, кроме ключа.

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

Answer 2

Нет, для нормализации так глубоко, как 3NF касается вас, что является обычным уровнем нормализации, структура в порядке.

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

Нормализуется и денормализуется на свой страх и риск:)

Answer 3

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

Answer 4

Я думаю, что ты в порядке.

Кажется возможным, что POST может иметь несколько ATTACHMENT и что ATTACHMENT может иметь несколько POST, в таком случае вам понадобится объект ссылки для третьей нормальной формы:

  Post

    |
    |
  -----
  | | |

Post_Attachment

  | | |
  -----
    | 
    |

Attachment

    |
    |
  -----
  | | |

  Media

Но из вашего описания, похоже, нет никакой ключевой связи между POST и MEDIA.

Answer 5

Во-первых, вам не нужно использовать суррогатные ключи. Подходящая база данных будет каскадно обновляться, если вы захотите. При нормализации базы данных вы обычно пытаетесь достичь третьей нормальной формы или даже BCNF. 2-я нормальная форма не всегда защищает ваши данные от аномалий обновления. Определение функциональных зависимостей в вашей схеме должно быть простым, как только вы создадите диаграмму ER и решите, какие данные являются частью сущностей (сообщения, вложения, медиа) и какие данные являются частью отношений. В зависимости от кардинальности ваших отношений, вам могут понадобиться или не понадобиться объединенные столы. Лучше всего смоделировать ваши данные на диаграмме, а затем решить проблемы с реализацией.

Answer 6

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