一对多关系和多对一关系的真正区别是什么?
我找不到任何关于这个主题的“好的和容易理解的”教程,除了这个: 初学者 SQL: 第3部分-数据库关系
从这个 关于数据库术语的页面
大多数表之间的关系是一对多的。 例如: 一个区域可以成为许多读者的栖息地。 一个读者可以有许多订阅。 一份报纸可以有很多订阅者。 多对一关系与一对多关系相同,但是从不同的角度来看。 许多读者生活在一个地区。 许多订阅可以是同一个读者。 许多订阅都是同一份报纸。
大多数表之间的关系是一对多的。
例如:
多对一关系与一对多关系相同,但是从不同的角度来看。
是的,反之亦然。这取决于实体所处的关系的哪一方。 例如,如果一个部门可以雇佣多个员工,那么部门对员工是一对多关系(一个部门雇佣许多员工) ,而员工对部门关系是多对一关系(许多员工在一个部门工作)。
更多关于关系类型的信息 :
数据库关系-IBM DB2文档
没有区别。这只是一个语言和偏好的问题,而不是你陈述关系的方式。
第一个问题的答案是: 两者都很相似,
对于你的第二个问题,答案是: 一对多—— > 男人(男人桌)可能有一个以上的妻子(女人桌)多对一—— > 不止一个女人嫁给了一个男人。
现在,如果您想将这种关系与两个表 MAN 和 WOMEN 关联起来,那么一个 MAN 表行可能与 WOMEN 表中的行有许多关系。希望你能明白。
One-to-many has 声明父类包含 n 个子类,因此它是一个集合映射。
Many-to-one has n number of children 含有一个父节点,因此它是一个对象映射
没有实际的区别。只要使用最有意义的关系给你的方式看你的问题,德文德拉说明。
这些术语之间存在概念上的差异,可以帮助您可视化数据,也可能存在生成的模式中应该完全理解的差异。不过,大多数情况下,两者的区别在于视角不同。
在 一对多关系中,本地表有一行可能与另一个表中的许多行关联。在来自 初学者的 SQL的例子中,一个 Customer可能与许多 Order相关联。
Customer
Order
在相反的 多对一关系中,本地表可能有许多行与另一个表中的一行相关联。在我们的示例中,许多 Order可能与一个 Customer相关联。这种概念上的差异对心智表征很重要。
此外,支持这种关系的模式在 Customer和 Order表中可能有不同的表示。例如,如果客户有 id和 name列:
id
name
id,name 1,Bill Smith 2,Jim Kenshaw
然后,对于与 Customer关联的 Order,许多 SQL 实现会在 Order表中添加一列,该列存储关联的 Customer的 id(在这个模式 customer_id中:
customer_id
id,date,amount,customer_id 10,20160620,12.34,1 11,20160620,7.58,1 12,20160621,158.01,2
在上面的数据行中,如果我们查看 customer_id id 列,我们会看到 Bill Smith(customer-id # 1)有两个与他相关的订单: 一个订单价格为12.34美元,一个订单价格为7.58美元。Jim Kenshaw(客户 ID # 2)只有一份158.01美元的订单。
Bill Smith
Jim Kenshaw
重要的是要认识到,通常一对多关系实际上并没有向表中添加任何列,这些列就是“ one”。Customer没有描述与 Order关系的额外列。事实上,Customer还可能与 ShippingAddress和 SalesCall表有一对多的关系,但是没有向 Customer表添加任何其他列。
ShippingAddress
SalesCall
但是,对于要描述的多对一关系,通常会向“ many”表添加一个 id列,这是“ one”表的外键——在本例中,向 Order添加一个 customer_id列。为了将价值12.34美元的 # 10关联到 Bill Smith,我们将 customer_id列分配给 Bill Smith的 id 1。
但是,也可能存在另一个描述 Customer和 Order关系的表,因此不需要向 Order表添加额外的字段。不需要向 Order表中添加 customer_id字段,可以使用包含 Customer和 Order键的 Customer_Order表。
Customer_Order
customer_id,order_id 1,10 1,11 2,12
在这种情况下,一对多和 多对一都是概念性的,因为它们之间没有模式更改。哪种机制取决于您的模式和 SQL 实现。
希望这个能帮上忙。
一对多和多对一在多重性方面是相似的,但是在方向性方面则不同。
实体类之间的 协会映射和表之间的 关系映射:
- 一对多-父母可以有两个或两个以上的孩子。
- 多对一-那三个孩子可以有一个单亲父母
两者都很相似。这可以根据需要使用。如果你想为特定的父母找到孩子,那么你可以选择一对多。或者,想为双胞胎找父母,你可以选择多对一。
在 SQL 中,只有一种关系,称为引用。(你的前端可能会做一些有帮助或令人困惑的事情(比如在一些答案中) ,但那是另一回事。)
一个表中的 外键(参考文献 < strong > ing 表) 参考文献 另一个表(参考文献 < strong > ed 表)中的 主键
在 SQL 术语中,< em > Bar 引用 Foo 而不是反过来
CREATE TABLE Foo ( Foo CHAR(10) NOT NULL, -- primary key Name CHAR(30) NOT NULL CONSTRAINT PK -- constraint name PRIMARY KEY (Foo) -- pk ) CREATE TABLE Bar ( Bar CHAR(10) NOT NULL, -- primary key Foo CHAR(10) NOT NULL, -- foreign key to Foo Name CHAR(30) NOT NULL CONSTRAINT PK -- constraint name PRIMARY KEY (Bar), -- pk CONSTRAINT Foo_HasMany_Bars -- constraint name FOREIGN KEY (Foo) -- fk in (this) referencing table REFERENCES Foo(Foo) -- pk in referenced table )
由于 Foo.Foo是一个主键,因此它是唯一的,对于任何给定的 Foo值只有一行
Foo.Foo
Foo
由于 Bar.Foo是一个引用,一个外键,并且没有唯一的索引,因此对于任何给定的 Foo值都可以有许多行
Bar.Foo
因此 Foo::Bar是一对多的关系
Foo::Bar
现在你可以反过来看看 感知的关系,Bar::Foo是多对一的
Bar::Foo
Bar
在 SQL 中,这是我们所拥有的全部,也是我们所需要的全部。
只有一种关系,因此没有区别。感知(从一个“终点”或另一个“终点”)或反向阅读,都不会改变这种关系。
基数首先在数据模型中声明,这意味着逻辑和物理(意图) ,然后在实现(意图实现)中声明。
一比零 在 SQL 中,(以上)是所有需要的。
一对一 您需要一个 交易来强制引用表中的 交易。
1比0比1 你需要在 Bar:
CONSTRAINT AK -- constraint name UNIQUE (Foo) -- unique column, which makes it an Alternate Key
在物理层次上没有这样的东西(回想一下,SQL 中只有一种类型的关系)。
在建模练习的早期逻辑层面,是 很方便来画这样一个关系。在模型接近实现之前,最好将其提升为只使用可能存在的内容。这种关系可以通过在物理[ DDL ]级别上实现 相联表来解决。
一对多和多对一的关系是在谈论同样的逻辑关系,例如一个业主可能有许多家,但家只能有一个业主。
所以在这个例子中,所有者是一个,而家庭是许多。 每个 Home 总是有一个 owner _ id (例如外键)作为额外的列。
这两者在实现上的区别在于,哪个表定义了关系。 在 One-to-Many 中,Owner 是定义关系的地方 在 Many-to-One,Home 是定义关系的地方,例如,home1.owner 列出了 owner 1的 owner _ id。
我实际上不知道在什么情况下您会实现多对一的安排,因为它看起来有点多余,因为您已经知道 owner _ id。也许它与删除和更改的清洁性有关。
根据我的经验,这是一个很好的问题,在 ERD 图表和关系数据库方向是隐含的。在 RDBMS 中,您总是定义许多到 > 一个(小例子一到 > 一个)关系。关系的多个方面,也就是子元素,引用了一个方面,也就是父元素,然后使用一个 Foreign Key 约束来实现这个约束。从技术上讲,你必须访问一个索引,获取一方的主键记录,然后访问这个记录,以获得更多的信息。
除非我们讨论对象关系数据库管理系统(如 Postgres、 Intersystems Cache 等) ,否则不能反过来做这件事。这些 DBMS 允许您定义两个实体(表)之间的双向关系。在这种情况下,通过使用引用数组(子元素)来访问记录,即 One-To-> Many。在 ORM 中,类之间相互引用的方式与我们在这里描述的相同。
警告: IT 市场上的大多数关系数据库都不是严格意义上的关系数据库管理系统,想想空值、重复记录等等,许多这些允许的特性打破了关系的定义。
对于这种关系,我能给出的最简单的解释就是借助于 evendra D. Chavan's的答案。
evendra D. Chavan's
一个部门可以有多个员工,因此从员工的角度来看,它是 one-to-many关系,从部门的角度来看,它是 many-to-one relationship关系
one-to-many
many-to-one relationship
但是如果一个员工也可以属于不止一个部门,我们也可以从员工的角度说,现在是 many而不是 one,所以这种关系变成了 many-to-many
many
one
many-to-many
换句话说,一个简单的理解就是,我们可以说一个关系是 many-to-many,如果 one-to-many可以从两边看 前提是;
我是 SQL 的新手,只有使用 SQLAlchemy 的经验。在我看来,SQLAlchemy 中关于关系的文档很好地解释了这一点。
通过阅读此 一部分,您可能会发现一些清晰的内容
而且,我必须用我自己的例子来思考这个问题。为了简单起见,我将尝试在不编写大量代码的情况下进行解释。
台车
表格制造商
一辆汽车只能有一个制造商(福特、特斯拉、宝马等)
制造商可以生产许多车辆
福特
在查看数据库行时,需要决定是否需要一个引用关系另一端的列。这就是 SQLAlchemy 文档在 backref 和 back _ popates 之间引入差异的地方。我理解,这就是表中有一列引用关系的另一端与没有一列引用关系的另一端之间的区别。
我希望这有所帮助,甚至更多,我希望我学习和理解的方式是正确的。
大部分答案我都读过了。问题根本不在于这里的关系。如果你从概念上看一对多或者多对一,它只是一个可逆的关系。然而,在您的软件或应用程序中实现这个概念时,它有很大的不同。
在 Multi to One 的情况下,我们通常希望首先编写包含许多方面的表,并希望它与包含 One 方面的表关联。如果将“多对一”概念转换为“一对多”概念,您将很难首先在代码中编写“一个方面”表。因为在设计数据库时定义了关系,所以许多方面表将寻找 One 方面表数据以保持完整性。因此,如果您计划通过使用外键-> 唯一键或外键-> 主键来实现,即使您将其视为一对多实现,也会有所不同。
在许多情况下,我个人并没有使用实际的关系概念来进行联想。每次使用数据库概念形成关系是没有界限的。只要确保你的数据库完整性按照你想要的方式维护,为你的搜索需求正确地建立索引,并且正常化。