Confusion about 1:1 relationship
我一直在学习数据库设计，对1:1的关系感到困惑。根据我的理解，您可以简单地将列添加到适当的表中。有人能提供一个现实世界的例子，说明1:1的关系是必要的，还是提供了一些重要的好处？也就是说，我会在哪里使用1:1的关系，它会是什么样子？
我给你举个实际的例子。
在医疗账单领域，希望通过医疗保险获得报酬的医生通过为患者每次就诊创建口述报告来处理账单。实际上，这可能是一个由秘书转录的录音口述，但更常见的情况是，它只是一个书面描述，描述了他们所做的事情以及与患者谈论的事情，以及历史、印象等。然后，持有执照的医疗编码员将阅读这份口述，并决定医生可以开什么账单。
与口述不同，涉及患者的人口统计信息有：姓名、年龄、账单地址等。这些信息必须与口述信息严格分开，以防止编码人员允许偏见模糊其账单判断或侵犯患者隐私。
这些数据通常在数据系统的起始点通过1:many关系保持良好的规范化，并且只有正确的部分在正确的时间显示给正确的人。但是，有相当多的办公室将其计费功能外包给第三方。例如，通过这种方式，一个小型诊所不需要在工作人员中保留一个有许可证的医疗编码员；计费办公室的一个编码员可以处理许多诊所的需求。当数据从诊所发送到账单办公室时，患者的人口统计信息和口述需要作为单独的部分来传递，可能在不同的时间。此时，它们可能存储在完全独立的表中，关系为1:1，共享ID字段，以便稍后进行匹配。
在这种情况下，1:1关系与数据模型几乎没有关系。您可能会在导入时匹配记录，并且随着账单在系统中的移动，最终诊所的人口统计记录中接收到的省病患信息将与真实的人匹配，因此可以恢复1:many关系。否则你每次去看医生都会得到一份单独的账单。
相反，它几乎与系统设计有关。在我们想象的计费服务中，可能有完全不同的人在构建和使用计费部分和编码部分。这样，每一方都可以完全控制自己的领域，并且您确信没有人，甚至开发人员，违反任何隐私规则。
True one-to-one relationships seldom
occur in the real world. This type of
relationship is often created to get
around some limitation of the database
management software rather than to
model a real-world situation. In
Microsoft Access, one-to-one
relationships may be necessary in a
database when you have to split a
table into two or more tables because
of security or performance concerns or
because of the limit of 255 columns
per table. For example, you might keep
most patient information in
tblPatient, but put especially
sensitive information (e.g., patient
name, social security number and
address) in tblConfidential (see
Figure 3). Access to the information
in tblConfidential could be more
restricted than for tblPatient. As a
second example, perhaps you need to
transfer only a portion of a large
table to some other application on a
regular basis. You can split the table
into the transferred and the
non-transferred pieces, and join them
in a one-to-one relationship.
号
这是这里引用的一句话：关系数据库设计的基础
这里有一个类似的问题。
我可以看到使用1:1的另一个原因(我以前使用过它)是如果有一个表有很多列，并且只有少数列涉及非常密集和频繁的查询，这需要快速，我会将它分成两个相关的1:1表，在这里我可以查询轻量级表并获得良好的性能，但是sti通过一个简单的连接就可以轻松地获得与之相关的其他数据。
我相信表的设计应该有域背景。因此，如果这些列构成两个不同的实体，则不应将它们混合在一个表中。根据我的经验，随着时间的推移，1:1的关系往往演变成1:N的关系。
例如，您可能希望存储某人的邮政地址。但一段时间后，您需要为每个人存储多个地址。将程序从1:1关系重构为1:n通常比将旧表中的某些列提取到新表中容易得多。
许多数据库系统允许以非常简单的方式定义每个表的访问权限。但是在单个列上定义权限通常是非常痛苦的。
首先，因为他们谈论的是访问(jet，ace，随便什么)——归功于@richard deslonde发现了这一点——然后他们可能谈论的是1:0..1的关系。我不认为真正的1:1关系在访问中是可行的，因为它没有延迟约束的机制，也没有在SQL
当然，在现实世界中，1:1和1:1..0的关系很常见。我更倾向于认为他们试图传达(有效的)一点，即为了业务目的，在数据模型中创建了一些1:1和1:1..0关系。
考虑一个"自然人"(即人)和一个"公司"。它们没有共同的属性(当然，两者都有一个"名称"，但它们的域是不同的，例如，"自然人名称"的"族名称"、"名"和"标题"等具有子原子域。
但是，在给定的数据模型中，不同的实体类型可能扮演相同的角色。例如，"自然人"和"公司"都可以是"公司"的高级职员。在数据模型中，我们可以有两种不同的实体类型"自然人高管"和"公司高管"，它们可能具有许多共同的属性，并且来自相同的领域，例如任命日期、终止日期等；此外，它们的业务规则将是相同的，例如任命日期必须在终止日期之前。此外，双方都将参与对等关系，例如"自然人代表"等。
数据模型可以在高层进行"拆分"，从而产生两个非常相似的表，例如"自然人主管"和"公司主管"、"自然人主管自然人代表"和"公司主管自然人代表"等。
然而，另一种方法是使用一个虚构的实体类型来建模公共属性和关系。例如，"自然人"和"公司"都可以被视为"法人"(除此之外：法律中有这样一个"法人"的概念，但这是否意味着与现实世界中的"法人"相同？！)
因此，我们可以分别为"法人"和"自然人"和"公司"创建一个超类表和子类表。"官员"表将引用"法人"表。所有随后的关系表都可以引用"军官"表，从这一点开始，这将是表数的一半。
这种"子类化"方法存在实际问题。因为"自然人"和"公司"没有共同的属性，所以它们没有共同的键，因此"法人"表需要有一个人工键，这会带来所有的问题，特别是在应用程序中需要暴露的情况下。此外，由于"法人"、"自然人"和"公司"之间的关系确实是1:1，一些DBMS作为访问，将缺乏有效实施它们的必要功能，许多DBMS将不得不满足于使它们1:0..1。
如果x与y的关系为1:1，z与y的关系也为1:1，那么这很有用。y可以抽象为共享表，而不是同时在x和z中复制。
编辑：一个真实的例子是客户、公司和地址。客户和公司之间可以有N:N关系。但是客户和公司都与地址有1:1的关系。有些地址行可能与客户和个人都相关。
1:1关系是您在数据中建模的抽象概念，但在数据库级别(假设RDBMS)并不真正存在。在一个表上总是有一个指向另一个表的外键，因此从技术上讲，由FK指向的父表可以有多个子表。这是您希望在业务逻辑中强制执行的内容。
从建模的角度来看，1:1关系的一个好例子是员工和人之间的关系。你有一个拥有某些数据的人，然后你在同一个人身上有了额外的属性，这就是你对一个雇员所赋予的。用OO编程术语来考虑这一点的一个好方法是继承类。Employee类，从Person继承。实际上，ORM系统可能会对数据库中的1:1关系建模，每个表都有一个共享的主键。