Исключение для циклической справочной базы данных - это одно?

У меня есть 4 таблицы, связанные в круговой ссылке - я помню из колледжа, что мне сказали, что это плохо, однако есть исключения...Я надеюсь, что это один из них:)

Моя база данных содержит 4 таблицы; учителя, классы, предметы и классы учителей.

Мои отношения суммируются следующим образом:

  • учитель может иметь много классов
  • класс может иметь много учителей (поэтому teachers_classes устраняет здесь много-ко-многим).
  • класс может иметь многие предметы
  • субъект может иметь только 1 класс
  • учитель может иметь много предметов

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

1 2
database database-design circular-reference

1 ответ:

Циклические ссылки могут быть плохими по нескольким причинам:

    В случае, когда отношения должны существовать (то есть учительдолжен иметь класс, А классдолжен иметь учителя, как с точки зрения бизнеса, так и с точки зрения технических требований), вы сталкиваетесь со сценарием "курица или яйцо": вы не можете добавить учителя без класса, и вы не можете добавить класс без учителя.
  1. это затрудняет вычисление того, что находится на "вершине" heirarchy (поскольку, по правде говоря, нет "верха")
Предполагая, что у вас могут быть учителя без классов и / или предметы без классов, похоже, что один из этих двух будет "верхним" (с точки зрения бизнеса, я бы предположил, что это будут предметы). Если то, что у вас есть, работает, я не вижу проблемы с дизайном, и я не вижу альтернативного способа его проектирования.

Редактировать после комментария

С этим нет проблем. односторонняя зависимость (это как раз то, что представляет собой обычный внешний ключ, не допускающий обнуления).

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

Вас несколько спасает тот факт, что у вас есть M:M отношения между учителями и классами, потому что это заставляет вас сделать оба способными существовать изолированно (поскольку соединение осуществляется в таблице ссылок, а не в самих таблицах участников. Из-за этого у вас нет истинной циклической зависимости. Ваша бизнес-логика такова: круговой, но это нормально, так как вы полностью контролируете, как он работает. Ваш макет либо выглядит так: 
   Teacher <----- TeacherClass -----> Class
      ^                                 ^
      |                                 |
      |                                 |
TeacherSubject --------------------> Subject

(если учитель может иметь несколько предметов)

Или вот это: 

   Teacher <----- TeacherClass -----> Class
      |                                 ^
      |                                 |
      |                                 |
      \----------------------------> Subject

(если учитель может иметь только один предмет)

Или вот это: 

   Teacher <----- TeacherClass -----> Class
      ^                                 ^
      |                                 |
      |                                 |
      \----------------------------- Subject

(если у предмета может быть только один учитель)

В первом случае и Teacher, и Class являются сущностями верхнего уровня, поскольку ни одна из них не указывает на что-либо другое (таблицы ссылок выполняют этот). Во втором случае только Class является сущностью верхнего уровня.

До тех пор, пока где-то на пути есть сущность верхнего уровня, вы в порядке. Во-первых, вы можете добавлять записи в следующем порядке: 
Teacher -> Class -> (TeacherClass -> Subject) -> TeacherSubject

(я вложил TeacherClass -> Subject в парены, потому что вы можете добавить их в любом порядке)

Во втором случае вы можете добавить их в следующем порядке: 
Class -> Subject -> Teacher -> TeacherClass

В третьем вы можете добавить их в следующем порядке: 

Class -> Teacher -> (TeacherClass -> Subject)
Таким образом, с технической точки зрения, у вас нет истинного круга зависимость.
2