#sql #database-design #data-modeling #normalization
#sql #database-design #моделирование данных #нормализация
Вопрос:
То, как спроектирована часть моей базы данных, у меня есть три таблицы:
Партнеры
- PartnerId
XYZPrograms
- xyzпрограммид
Программы partnerxyz
- PartnerId
- xyzпрограммид
У каждого партнера может быть ноль или одна XYZProgram. Таблица PartnerXYZPrograms связывает партнера с XYZProgram. Итак, у меня есть следующие отношения / ограничения в таблице PartnerXYZPrograms:
PartnerId и XYZProgramId являются внешними ключами; PartnerId является уникальным, а также XYZProgramId уникальным.
Теперь это, кажется, пахнет. Я возвращаюсь к дизайну БД спустя 6 лет, поэтому я не могу сразу сказать, какое правило нормализации это нарушает, но я подозреваю, что это что-то нарушает. Таблица PartnerXYZPrograms, скорее всего, избыточна, а таблица XYZPrograms, вероятно, должна содержать PartnerId.
Итак, мой вопрос в том, каковы запахи при разработке таблиц, которые предполагают, что нормализация базы данных, вероятно, ошибочна.
Комментарии:
1. Ваш пример — это дизайн «многие ко многим» из учебника — «запаха» нет. Оба столбца в
PartnerXYZProgramsдолжны быть первичным ключом…2. Может ли одна программа быть связана с более чем одним партнером? Если это так, то это стандартное отношение «многие ко многим», как говорит OMG Ponies.
3. Вы уверены, что это дизайн «многие ко многим»? Для каждого партнера может быть ноль или одна программа.
4. У каждого партнера есть уникальная программа или ее вообще нет.
5. @OMG Пони. Позвольте мне выразить это по-другому. Какие вещи вызывают красный флаг при рефакторинге дизайна базы данных?
Ответ №1:
Самый простой способ определить эти запахи — визуализировать, как будет выглядеть набор данных, когда он активен. Очевидные и наиболее фундаментальные запахи, связанные с нормализацией:
- Таблица содержит те же избыточные данные в столбце, значения которых не являются ключами (или частью составного ключа) к другой таблице. Это должно вызвать тревогу. Если у вас есть объект под названием Job Listing и один из столбцов «Category» содержит такие значения, как «Management», «Management», «Engineering», «Management», это должно сразу сказать вам, что существует дополнительная концепция, которую стоит представить.
- Таблица содержит избыточные данные в столбце, который иногда заполняется аналогично предыдущему значению, а иногда имеет значение null. Это немного похоже на описанное выше, но есть различие. Это означает, что существует отдельная идея, которую необходимо представить, но она является частью отношения композиции. Например, Объект Employee, называемый ManagerInfoID, который имеет ключ к записи в таблице manager с некоторой информацией. Это значение равно нулю для всех, не являющихся менеджерами. (Я видел это чаще, чем мне бы хотелось.
- Другой возможный запах — это таблица слияния, которая просто выглядит неправильно. Чаще всего люди по умолчанию используют таблицу ссылок или слияний (например, ManagerEmployee). Хотя на самом деле это оптимальное решение для работы со многими отношениями, иногда сложные отношения, подобные тому, который вы отметили выше, имеют характеристики, которые просто не кажутся правильными в таблице слияния. Лучшее (возможно?) Решение — смоделировать отношение ноль ко многим или один ко многим, аналогичное тому, что вы упомянули выше (поместив PartnerId в таблицу XYZPrograms).
По моему честному мнению, я думаю, что забыть правила нормализации и придерживаться запахов — это действительно хорошо. Это предотвращает возникновение таких вещей, как # 3, когда хаотичная борьба за создание правил из класса, который вы едва помните много лет назад, обычно приводит к несоответствию теории и практики и неправильному применению принципов.
Хорошая особенность реляционных баз данных в том, что ваши данные выглядят действительно уродливо, когда вы их видите, если они не были смоделированы должным образом. Это то, что происходит из-за того, что ненормализованные базы данных становятся битами (или, что еще хуже, приходится устранять последствия).
Какие еще запахи вы можете придумать?