数据库如何建模 1:1 关系

发布于 2024-10-11 19:31:02 字数 500 浏览 2 评论 0原文

(VS2008,SqlCE 3.5)

我尝试建模1:1关系。所以我把外键放在父表中,保存着子表的PK。然后我将外键设置为 UNIQUE。不过,当我创建实体类(使用 SqlMetal)时,子类会引用父类的 EntitySet,而不仅仅是单个实体。这看起来像是一个m:1关系?那么我需要做什么才能使其达到 1:1 呢?


EDIT1:

我很困惑..尝试制作一组​​,如下所示:

StrategySet(ID, EntryStrategyID{Unique}, ExitStrategyID{Unique})   
EntryStrategy(ID) 
ExitStrategy(ID) 

这是 m:1 不是吗?虽然看起来 FK 在父级中,但我们不会将 StrategySet 命名为父级吗?现在我该如何将其更改为 1:1 呢?

(VS2008, SqlCE 3.5)

I try to model a 1:1 relationship. So I put the foreign key in the parent table, holding the PK of the child table. Then I set the foreign key to UNIQUE. Still when I create my entity classes (With SqlMetal), the child class has a reference to an EntitySet of the parent, not just a single entity. This seems like a m:1 relation? So what I need to do to make it 1:1 ?


EDIT1:

I'm confused.. Trying to make a set, like this:

StrategySet(ID, EntryStrategyID{Unique}, ExitStrategyID{Unique})   
EntryStrategy(ID) 
ExitStrategy(ID) 

Is this m:1 isn't it? Though it looks like FK's are in the parent, or wouldn't we name StrategySet the parent? And how would I now change this too 1:1 ?

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

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

发布评论

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

评论(3

往事风中埋 2024-10-18 19:31:02

首先,parent是FK从child引用的表。因此,您不能说您的父表引用子表:这是不正确的。

其次,可以通过以下方式建立 1:1 关系:

  • 两个表中的主键
  • 父表中的主键和子表中的唯一外键

因此,在您的情况下,架构是正确的。我想您应该再次检查结构,并仔细阅读这篇文章

First of all, the parent is table which is referenced by FK from child. So you can't say that your parent table references the child: it's not correct.

Secondly, 1:1 relations can be made through:

  • Primary Keys in both tables
  • Primary Key in parent and Unique Foreign Key in child

So in your case, the architecture is correct. I suppose you should check the structure again, and look through this article.

谢绝鈎搭 2024-10-18 19:31:02

如果 EntryStrategyExitStrategy 中的所有列都相同,那么您只需要这个(也添加所有其他列)。

alt text

如果 EntryStrategyExitStrategy 有一些不同的列,则用这个。将所有常见列保留在Strategy 表中。 EntryStrategyExitStrategy 仅具有各自特定的列。

alt text

这也是由于表的垂直分区而导致的 1:1 的通用示例。

之前

alt text

之后

替代文字

If all columns in EntryStrategy and ExitStrategy are the same, then all you need is simply this (add all other columns too).

alt text

If EntryStrategy and ExitStrategy have some different columns, then use this. Keep all common columns in the Strategy table. EntryStrategy and ExitStrategy have only columns specific to each one.

alt text

Here is also a generic example of 1:1 due to vertical partitioning of a table.

Before:

alt text

After:

alt text

北城半夏 2024-10-18 19:31:02

让我了解一下你所描述的情况。

您有一组构成“策略”的字段。这些字段的子集在概念上是“EntryStrategy”,并且这些字段的非相交子集是“ExitStrategy”。

在您的情况下,构成“EntryStrategy”的一组给定值可以与构成“ExitStrategy”的一组且仅一组值连接。这就是您说存在 1:1 对应关系时的意思。

正如 smirkingman 之前所说,在经典的关系数据库建模中,所有这些字段都属于单个表,因为字段的子集不会出现在多个记录中。

如果单个 EntryStrategy 可以有多个 ExitStrategies,那么您将拥有两个表,其中 EntryStrategy 为父表,ExitStrategy 为子表,并且 ExitStrategy 记录将具有指向 EntryStrategy 父记录的外键。

如果单个 ExitStrategy 可以有多个 EntryStrategies,那么您将拥有两个表,其中 ExitStrategy 为父表,EntryStrategies 为子表,并且 EntryStrategy 记录将具有指向 ExitStrategy 父记录的外键。

如果您可以有多个 EntryStrategies 与多个 ExitStrategies 关联,那么您将拥有多对多关系,需要第三个表来维护对应关系。

经典数据库建模的原则会将所有字段放在一张表中。

正如 St Woland 所写,您可以通过拥有两个表来强制执行 1:1 关系,其中子表中的外键是唯一索引。但两个表通常用于一对多关系。

正如 Damir 所写,您可以通过拥有三个表来强制执行 1:1 关系,其中第三个表具有其他两个表的外键,并且两个外键字段都标记为唯一索引。但是,当您具有多对多关系时,通常只以这种方式使用三个表。

我认为您对自动化数据建模工具的期望过高,以至于期望它们能够构建代表您非常规方法的实体。

您的主要问题的答案很简单。如何表示 1:1 关系?您将它们放在一个表的同一条记录中!

Let me understand the situation you are describing.

You have set of fields which make up a "Strategy". A subset of the fields are conceptually the "EntryStrategy" and a non-intersecting subset of the fields are the "ExitStrategy".

In your case a given set of values making up an "EntryStrategy" can be joined with one and only one set of values making up an "ExitStrategy". This is what you mean when you say there is a 1:1 correspondence.

As smirkingman said earlier, in classic relational database modeling, all of these fields belong in a single table because no subset of the fields appear in more than one record.

If you could have multiple ExitStrategies for a single EntryStrategy then you would have two tables with the EntryStrategy being the parent and the ExitStrategies being the children and the ExitStrategy records would have a Foreign Key pointing to the EntryStrategy parent record.

If you could have multiple EntryStrategies for a single ExitStrategy then you would have two tables with the ExitStrategy being the parent and the EntryStrategies being the children and the EntryStrategy records would have a Foreign Key pointing to the ExitStrategy parent record.

If you could have multiple EntryStrategies associated with multiple ExitStrategies then you would have a many-to-many relationship which requires a third table to maintain the correspondences.

The principles of classic database modeling would put all your fields in one table.

As St Woland wrote, you can enforce the 1:1 relationship by having two tables where the foreign key in the child table is a Unique index. But two tables are normally used for 1-to-many relationships.

As Damir wrote, you can enforce the 1:1 relationship by having three tables where the third table has a foreign key to each of the other two tables and both foreign key fields are marked as Unique indices. However, normally you only use three tables in this fashion when you have a many-to-many relationship.

I think you are expecting way too much from the automated data modeling tools to expect them to construct entities that represent your very unconventional approach.

The answer to your main question is simple. How do I represent a 1:1 relationship? You put them in the same record in a single table!

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