Циклические ссылки в проектировании баз данных — следует ли их избегать?

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

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

где Должности, Сотрудники и Программное обеспечение — это таблицы, а "oo-------...-------oo" отображает отношения «многие ко многим» между ними.

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

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

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


database-design ms-access circular-dependency circular-reference
person user459459    schedule 27.09.2010    source источник

Ответы (4)


arrow_upward
1
arrow_downward

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

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

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

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

person David-W-Fenton    schedule 27.09.2010

arrow_upward
0
arrow_downward

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

person Nick Jones    schedule 27.09.2010

arrow_upward
0
arrow_downward

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

Столы

  • Наемный рабочий
  • Программное обеспечение
  • СотрудникПрограммное обеспечение
  • Должность

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

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

Приложение сначала проверяет, находится ли человек в таблице правильного положения (POSITIONS), прежде чем вставлять запись. Для дополнительной проверки БД вы можете добавить ограничение проверки в EmployeeSoftware, чтобы проверить БД POSITIONS до того, как ... тогда должна быть связь между программным обеспечением и позициями.

person Saif Khan    schedule 27.09.2010
comment
Спасибо вам, ребята. Однако действительно ли круговые отношения в моей исходной структуре являются здесь проблемой? Каковы возможные последствия его наличия? Есть ли какой-нибудь алгоритм для анализа возможных ошибок/странного поведения? - person user459459; 27.09.2010
comment
Можно разрешить все, что вы решите делать с БД, в вашем случае циклическую ссылку. Есть ли обходные пути? ... зависит. Вы смотрели на представления? ... возможно, вы можете использовать несколько представлений для структурирования данных так, как вы выберете. - person Saif Khan; 27.09.2010
comment
Если вы думаете достаточно далеко вперед, чтобы беспокоиться о последствиях неудачного дизайнерского решения, то почему вы все еще используете Access? - person sorpigal; 27.09.2010
comment
В этом случае мне необходим доступ. К сожалению, я не могу использовать SQL или Oracle, хотя очень хотелось бы. Итак, Саиф, вы имеете в виду, что циклическая ссылка в этом случае не вызовет у меня никаких проблем и не приведет к какому-то неожиданному поведению? Если да, то почему люди так боятся иметь его в своей структуре базы данных? - person user459459; 27.09.2010
comment
Вы можете получить разные результаты в зависимости от того, как вы запрашиваете данные. - person Saif Khan; 28.09.2010
comment
Здесь есть что почитать codeproject.com/KB/database/circular_reference.aspx - person Saif Khan; 28.09.2010

arrow_upward
0
arrow_downward

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

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

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

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

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

person JeffO    schedule 27.09.2010