关系型数据库设计/关系
表中的每一行都代表关于世界的事实，这些事实涉及多个值之间的关系。例如，下表包含一行，将数字 75、字符串“Alice”和工程部门关联起来。该表适用于存储此信息，因为使用该数据库表的企业已经就以下规则达成一致：每个员工都有一个唯一的编号，并且每个员工都属于一个部门。需要存储的数据的“形状”完美地适应于该表。
| 员工编号 | 姓名 | 部门 |
|---|---|---|
| 75 | Alice | 工程 |
| 84 | Bob | 市场营销 |
| 98 | Charlie | 销售 |
但是，表中的所有行都必须具有相同数量的列，并非关于世界的所有事实都可以表示为固定数量事物的组合。例如，假设我们有一个用于 CRM 应用程序的数据库，该应用程序跟踪客户公司以及我们在每个公司中的各种联系人。一家公司可能与其关联了七个联系人，而另一家公司可能只有一个联系人。更糟糕的是，我们可以添加和删除公司联系人，并可能更改此数量。如果所有公司都将位于同一张具有固定列数的表中，那么我们就无法将联系人信息放入其中。
ER 图允许将简单的主语谓语宾语语句映射到图表上，然后映射到书面的模式定义中，例如，SQL 数据库定义语句。
例如：需求语句
一家公司拥有多家咨询服务业务，每家咨询服务业务都由一位经理、前台工作人员、按服务费百分比计酬的合同咨询师以及协助每位咨询师提供扩展服务的助理组成。所有承包商和固定工资的助理都必须具备正式资格。该企业的客户同意记录其人口统计数据，因为服务通常涉及一些后台处理，这些处理无法在咨询期间立即完成，但需要在服务产品完成后由咨询师传达给客户。
如何开始映射？
在 ER 映射中，2 个实体之间存在关系，这种关系类似于主语和宾语之间的动词。例如，从上面的需求陈述中，可以生成多个更简单的陈述，这些陈述采用主语谓语宾语格式。
公司拥有许多服务业务。
服务业务从地点运营。
服务业务拥有电话联系方式。
电话联系方式是类型化的。
一位经理管理一家服务业务。
许多办公室工作人员经营服务业务。
办公室工作人员获得薪水。
办公室工作人员有一个花名册。
一位办公室工作人员有一组工作班次。
一位办公室工作人员执行许多工作班次。
许多工作班次实现一个工作班次。
已经，简短的需求陈述产生了许多可用于 ER 映射的句子。
下一步似乎是将每个句子的主语或宾语映射为实体，该实体随后映射到关系或表。该符号是用矩形包围的主语名称。
此外，连接主语和宾语的动词可以映射到关系，关系有自己的象形图，即菱形，动词在其中。关系可能会映射到表中，但最常映射为一个表中的外键，引用另一个表。
关系象形图的每端通常都标记为描述此关系边的基数。基数在一侧可能是1，而在另一侧可能是many或*，这意味着与 many 侧的实体匹配的表将承载指向1 基数侧的实体的外键。
例如：公司拥有许多服务业务。
注意有一个箭头表示主语谓语宾语顺序的方向。
这将映射到类似于以下内容的内容
Corporation( Corp_Id , CorpName , GovtBusinessRegoNumber ) , Service_Business ( SB_id , Address, Corp_Id)
此处带下划线的属性是其拥有实体的主键列。Service_Business 的最后一列是公司的外键，代表“拥有”关系菱形中的信息。
现在，如果公司可以将服务业务出售给彼此，那么可能适用一段所有权时间，因此拥有关系必须进行两个更改：开始和结束属性，并且由于一家服务业务可以通过不同的拥有关系实例被许多公司拥有，因此拥有关系的左侧基数变为many。
ER 图中的属性通常建模为一个椭圆，其中包含属性名称，并链接到包含该属性的实体或关系。
_____ _____
________ ( start)-- ---- ( end )
(CorpName)---- """""" \ / """""
"""""""" \ V
------ \ ^ _________
(RegoNo)-- ---------------- / \ ------------------ ---- ( address )
====== \ | Corporation |--many--<Owns>--- many -->| Service_Business | """""""""
---------------- \ / ------------------ ---- _____________
V | 1 (business_name )
has =============
| many ________
------------------ ----( number )
| contact_number | ========
------------------ ---- ---------
( type )
"""""""""
以上情况有几个不同的 ER 设计选择，这些选择存在争议。Corporation.RegNo、Service_Business.Business_name 和 Contact_number.Number 是属性，但它们也带下划线，因此是各自实体的主键。
拥有关系已成为多对多关系，可以表示为 Owns (start, end, RegNo, Business_name)。
同样，使用了语义主键，但指向公司和服务业务的外键包含在主键中。
如果公司可以多次拥有服务业务，那么存在什么样的多值依赖？
如果存在多值依赖，那么 RegNo、Business_Name 可以出现多次。这是否违反了 4NF，因为 RegNo、Business_Name 不是 Owns 的超键？
4NF 还有另一个标准，是什么？