我一直在学习数据库设计,对于1:1关系感到困惑。据我所知,您可以简单地向适当的表中添加列。能否有人提供一个现实世界的例子,说明何时需要或者获得了哪些重要优势?也就是说,我在什么情况下会使用1:1关系,它会是什么样子?
我一直在学习数据库设计,对于1:1关系感到困惑。据我所知,您可以简单地向适当的表中添加列。能否有人提供一个现实世界的例子,说明何时需要或者获得了哪些重要优势?也就是说,我在什么情况下会使用1:1关系,它会是什么样子?
这里有一个在SO上的相似问题。
我认为使用1:1的另一个原因是,如果你有一张有很多列的表格,并且只有其中几列涉及非常频繁和需要快速查询的数据,那么我会将其分成两个相关的1:1表格,在其中一个轻量级表格上进行查询并获得良好的性能,但仍然可以通过简单的连接轻松地获得与其相关的其他数据。
我认为表格设计应该考虑到领域背景。如果这些列形成了两个不同的实体,它们就不应该混在一个表中。从我的经验来看,1:1关系往往会随着时间的推移演变成1:n关系。
例如,您可能想存储个人的邮政地址。但是过一段时间后,您需要存储每个人的多个地址。将程序从1:1关系重构为1:n通常比从旧表中提取某些列到新表中容易得多。
许多数据库系统允许以非常简单的方式定义每个表的访问权限。但是定义每个列的权限通常是相当痛苦的。
如果X与Y有1:1的关系,Z也与Y有1:1的关系,则将Y抽象为共享表而不是在X和Z中重复会很有用。
编辑:一个现实世界的例子是客户,公司和地址。客户和公司之间可以有N:N的关系。但是客户和公司都与地址有1:1的关系。一些地址行可能与客户和人员都相关。
PROCEDURE
中执行多个语句。大多数Access从业者满足于使用1:0..1关系来模拟真正的1:1关系,所以我猜作者们满意于非正式地使用术语“1:1”来指代两者。然而,在给定的数据模型中,不同的实体类型可能扮演相同的角色。例如,“自然人”和“公司”都可以成为“公司”的官员。在数据模型中,我们可以有两种不同的实体类型“自然人官员”和“公司官员”,它们很可能具有许多共同的属性,来自相同的领域,例如任命日期、终止日期等;此外,它们的业务规则也是相同的,例如任命日期必须在终止日期之前。同时,它们都将参与等效的关系,例如“自然人代表”等。
数据模型可以在高层次上进行“拆分”,从而产生非常相似的表格对,例如“自然人官员”和“公司官员”,“自然人官员自然人代表”和“公司官员自然人代表”等。
然而,另一种方法是使用虚构的实体类型来建模共同的属性和关系。例如,“自然人”和“公司”都可以被视为“法人”(附注:在法律上确实存在“法人”这个概念,但这是否意味着它在现实世界中也存在?!)
因此,我们可以为“法人”设置一个超类表,并分别为“自然人”和“公司”设置子类型表。 “官员”表将引用“法人”表。所有后续关系表都可以引用“官员”表,从这一点开始减少表的数量。1:1关系是您在数据模型中建模的抽象概念,但在数据库级别(假设为RDBMS)并不存在。您始终会在一个表上有一个指向另一个表的外键,因此从技术上讲,被FK指向的父表可能有多个子项。这是您希望在业务逻辑中强制执行的内容。
建模意义上1:1关系的一个很好的例子是员工和人之间的关系。您有一些数据的人,然后您在同一个人上有额外的属性,将其放在员工上。在面向对象编程术语中,将其视为继承类的一种好方法。Employee类继承自Person。实际上,许多ORM系统将在数据库中使用共享主键来建模1:1关系。