3 个表之间的一对一关系(背靠背 - 1 对 1 关系)

发布于 2024-11-08 23:15:05 字数 367 浏览 3 评论 0原文

有3张表,分别是FN、ADM、USR,分别代表一个 功能、功能管理员、参加功能的用户。 Admin 将是一个用户,ADM 必须从 USR 继承。
FN_I,USR_I 应该是 FN 和 USR 的主键。(这被许多其他表引用)
ADMN 是新添加的

在此处输入图像描述

我需要实现以下约束。
  1. 一个功能只能有一个管理员。(1-1)
  2. 一名管理员只能管理一项功能。(1-0/1)

我尝试通过将 FN_ADM_I 设置为 FN_I 的外键来实现 1。
有人可以帮助我解决可以实现这两个要求的约束/关系吗?

There are 3 tables namely FN, ADM, USR representing a
function, admin for the function, users who attend the function.
Admin will be a user and ADM has to be inherited from the USR.
FN_I,USR_I should be the prim key for FN and USR.(This is referenced by many other tables)
ADMN is the new able added

enter image description here

I need to implement the following constraints.
  1. One Function can have only one admin.(1-1)
  2. One Admin can administer only one Function.(1-0/1)

I tried achieving 1 using by setting FN_ADM_I as foreign key to FN_I.
Could some one help me with constraints/relationships that can achieve both the requirement?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

·深蓝 2024-11-15 23:15:05

您可能想要创建一个链接表:

FN_ADMIN_REL

FN_I, -- PK
ADMIN_I --PK 

其中两个字段都是具有 UNIQUE 约束的主键:

ALTER TABLE FN_ADMIN_REL
ADD CONSTRAINT uc_Func_Admin UNIQUE (FN_I, ADMIN_I)

You may want to create a link table:

FN_ADMIN_REL

FN_I, -- PK
ADMIN_I --PK 

where both fields are primary key with UNIQUE constraint:

ALTER TABLE FN_ADMIN_REL
ADD CONSTRAINT uc_Func_Admin UNIQUE (FN_I, ADMIN_I)
江挽川 2024-11-15 23:15:05

我认为您在这里混淆了术语。我认为1-1(一对一)的关系并不完全是你想象的那样。

无论如何,如果我正确理解你的问题(很可能不是这种情况),这就是你所做的。

  • 您已经拥有 FN 和 USR 表,每个表上都有主键。
  • 逻辑上,参加某个功能的用户是多对多的关系:一个用户可以参加多个功能,每个功能可以由多个用户参加。多对多关系传统上由 SQL Server 中的“链接”表建模。您创建具有 FN_I 字段和 USR_I 字段的 FN_USR 表,并将这些外键分别设置为 FN 和 USR。这就是您将功能与出席用户联系起来的方式。 (请注意,在您的图表上,这两个表之间没有关系,所以我只是猜测您想要多对多,您没有明确指定这一点。)
  • 现在让我们看看 ADM 表。这一个“继承”自苏联。在sql server中没有表继承的概念。这通常通过一对零或一的关系来建模。您创建 ADM 表,并将主 ADM_I 设置为该表中的主键。您还可以将其作为 USR 表中 USR_I 列的外键。这就是管理员/用户关系的建模方式。每个管理员都是一个用户(每个ADM记录都有相关的USR记录),但不是每个用户都是管理员(不是每个USR记录都有相关的ADM记录)
  • 最后一部分是Admins和Functions之间的关系。由于没有管理员可以管理多个功能,这也是一对零或一的。然而,在这种情况下,我们会将 ADM_I 列添加到 FUN 表中,并将其作为 ADM 表中 ADM_I 列的外键。这将为我们提供一对多。现在我们可以在 FUN 表中的 ADM_I 列上创建 UNIQUE 约束,使这种关系成为一对零一。

这有道理吗?

I think that you mixed up terminology here. I think 1-1 (one to one) relationship is not exactly what you think it is.

Regardless, if I understood your question correctly (which very easily might not be the case) here is what you do.

  • You already have FN and USR tables with primary key on each one.
  • Logically user who attends a function is many-to-many relationship: a user can attend many functions and each function can be attended by many users. Many-to-many relationships a traditionally modelled by a "link" table in sql server. You create FN_USR table that has FN_I field and USR_I field and make those foreign keys into FN and USR respectively. This is how you connect functions with attending users. (Note that on your diagram there is NO relationship between these two tables, so I'm just guessing that you want many-to-many, you have not explicitly specified this.)
  • Now let's look at the ADM table. This one "inherits" from USR. In sql server there is no concept of table inheritance. This is usually modelled via one-to-zero-or-one relationship. You create and ADM table and you make a primary ADM_I the primary key in this table. You also make it a foreign key into USR_I column in the USR table. This is how admin/user relationship is modelled. Every admin is a user (every ADM record has relevant USR record) but not every user is admin (not every USR record has relevant ADM record)
  • The last part is the relationship between Admins and Functions. Since no admin can administer more than one function this is also one-to-zero-or-one. In this case however we will add ADM_I column to the FUN table and make it a foreign key into ADM_I column in the ADM table. This will give us one-to-many. Now we can create a UNIQUE constraint on the ADM_I column in the FUN table to make this relationship one-to-zero-one.

Does this make sense?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文