Циркулярные ссылки в дизайне базы данных - следует ли их избегать? - PullRequest
3 голосов
/ 27 сентября 2010

В настоящее время я занимаюсь разработкой базы данных с помощью MS Access 2003 и застрял в проблеме циклических ссылок.По сути, это сводится к следующему треугольнику отношений (это упрощенная форма моей таблицы отношений):

                     Positions
                 oo            oo
                /                \
               /                  \
              /                    \
             /                      \
            /                        \
           /                          \
          /                            \
         /                              \
        /                                \
       /                                  \
      oo                                  oo
  Employees  oo -------------------- oo Software,

, где Таблицы позиций, Сотрудники и Программное обеспечение представляют собой таблицы, а "oo-------...-------oo" отображает множество-множество отношений между ними.

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

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

Заранее спасибо, VS.

Ответы [ 4 ]

1 голос
/ 27 сентября 2010

Ваша диаграмма является эллиптической в ​​том смысле, что вы исключили таблицы соединений N: N между всеми вашими сущностями.Они имеют ОГРОМНОЕ различие в отношении побочных эффектов круговых отношений.Прямые отношения 1: N с CASCADE DELETE могут вызвать реальные проблемы и потенциальные взаимоблокировки.Но с промежуточными таблицами N: N у вас не должно быть этой проблемы, поскольку CASCADE DELETE будет работать только "под уклон" от таблицы 1 к N, и не будет выполнять резервное копирование цепочки от таблицы N: N к другой.родительская таблица.

Мне кажется, что это общая проблема, изоморфная проблеме адресации, т. е. человек может иметь личный адрес и наследовать адрес от работодателя, и решение @Saif Khan об устранениинаследование программного обеспечения от позиции является формой денормализации, в которой вы свели две сложные взаимосвязи сущностей в одну.Я никогда не знаю, как смоделировать это, не из-за потенциальных циклических связей, а из-за проблем с производительностью (и невозможности редактирования), возникающих при сборке единого результирующего набора всех программ / адресов, для которого требуется UNION.Я хотел бы использовать триггер для дублирования программного обеспечения, унаследованного от должности, с записью, связывающей человека с программным обеспечением.

До A2010 это было невозможно на уровне ядра в Access / Jet / ACE, но в A2010 добавлены макросы данных на уровне таблицы, которые можно использовать для реализации эквивалента триггеров.Это может быть случай, когда эта новая функция может позволить вам реализовать эту структуру с помощью триггеров.

Но я не уверен, что мне удобно дублировать данные, хотя триггеры позволят вам сохранить дублированные данныесинхронно на уровне двигателя.

0 голосов
/ 28 сентября 2010

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

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

Не пытайтесь напрямую связать Сотрудника с программным обеспечением.

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

Запросбудет проще. Как отметил Дэвид-В-Фентон, вам придется использовать множество профсоюзов, чтобы выяснить, кто может использовать какое программное обеспечение, или наоборот.

0 голосов
/ 27 сентября 2010

Вам необходимо правильно нормализовать БД. ИМХО - я бы не использовал отношения в таблице позиций. Вот что я бы сделал

Таблица

  • Employee
  • Программное обеспечение
  • EmployeeSoftware
  • Должность

Таблица "ПОЗИЦИИ" в вашем случае, я полагаю, соответствует вашим ролям. Обратите внимание, что БД должна использоваться как хранилище, и там должна быть размещена минимальная бизнес-логика. Как говорится, ... позвольте мне продолжить

Будет существовать связь между Employee и EmployeeSoftware (empid присутствует как внешний ключ в EmployeeSoftware. То же самое для программного обеспечения и EmployeeSoftware (программное обеспечение присутствует как внешний ключ в EmployeeSoftware.

Приложение сначала проверяет, находится ли человек в таблице должностей (ПОЛОЖЕНИЯ), прежде чем вставить запись. Для дополнительной проверки БД вы можете добавить контрольный запрет на ПО EmployeeSoftware для проверки БД ПОЗИЦИЙ до того, как ... тогда должна быть взаимосвязь между программным обеспечением и позициями.

0 голосов
/ 27 сентября 2010

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

...