我目前正在通过MS Access 2003开发数据库，并陷入循环引用问题。基本上，它归结为以下关系三角形（它是我的关系表的简化形式）：
Positions
oo oo
/ \
/ \
/ \
/ \
/ \
/ \
/ \
/ \
/ \
/ \
oo oo
Employees oo -------------------- oo Software,
其中职位，员工和软件是表格，"oo-------...-------oo"显示他们之间的多对多关系。
简而言之，公司中的所有员工都被分配到特定职位（其中一些职位被分配到多个职位），并且有权根据职位使用特定的软件。但是，也有例外情况，除了根据职位允许的情况外，还允许一些员工使用少量其他软件包。
问题是，在这种数据库中允许循环关系是否可以？是否存在不需要非规范化的变通方法？
提前致谢， VS
答案 0 :(得分：1)
您的图表是椭圆形的，因为您在所有实体之间省略了N：N连接表。这些与圆形关系的副作用有很大的不同。直接1：与CASCADE DELETE的N关系可能导致实际问题和潜在的死锁。但是在它们之间有N：N表，你不应该有这个问题，因为CASCADE DELETE只能从1表“下坡”运行到N，而不是从N：N表到另一个表的链。父表。
在我看来，这是一个常见问题，与地址问题同构，即一个人可以拥有个人地址并继承雇主的地址，以及@Saif Khan从该职位中消除软件继承的解决方案是一种非规范化的形式，因为你已经将两个复杂的实体关系折叠成一个。我从来不知道如何对此进行建模，不是因为潜在的循环关系，而是因为组装所有软件/地址的单个结果集所产生的性能问题（和不可编辑性），这需要UNION。我很想使用触发器来复制从该位置继承的软件，并将该人与软件相关联。
在A2010之前，这在Access / Jet / ACE的引擎级别是不可能的，但A2010添加了表级数据宏，可用于实现等效的触发器。这可能是新功能允许您使用触发器实现此结构的情况。
但我不确定我是否熟悉复制数据，即使触发器允许您在引擎级别保持重复数据同步。
答案 1 :(得分：0)
您可以通过为每个例外生成新的位置来避免它。然后，如果需要，可以将布尔标志添加到该位置以区分实际位置和异常位置。
答案 2 :(得分：0)
您需要正确规范化数据库。恕我直言 - 我不会在职位表中使用关系。这就是我要做的事情
表
我认为，您的案例中的“POSITIONS”表是您的角色。请注意，DB应该用作存储，并且应该放置非常小的业务逻辑。话虽如此，......让我继续
Employee和EmployeeSoftware之间存在关系（empid在EmployeeSoftware中作为外键出现。对于Software和EmployeeSoftware也是如此（softid在EmployeeSoftware中作为外键出现。
在插入记录之前，应用程序首先检查某人是否处于正确的位置（POSITIONS）表。对于额外的数据库检查，您可以在EmployeeSoftware上添加检查约束，以便在...之前检查POSITIONS数据库，然后需要在软件和职位之间建立关系。
答案 3 :(得分：0)
我认为由于处理异常的方式，这个数据库设计变得太复杂了，
“部分员工被授予 使用一些其他软件 包装，除了它们之外 允许根据他们的 （多个）位置。
不要试图直接将员工链接到软件。
我只想创建另一个职位，因为在这种情况下，职位的主要目的是确定软件访问权限。即使一个人拥有唯一的软件列表，他们将来也会被替换，并且该人员可以被分配相同的职位。
查询会更容易。正如David-W-Fenton指出的那样，你将不得不使用很多工会来找出谁可以使用什么软件，反之亦然。