Header-lines tables design pattern头表/行表设计模式

简介

头表、行表（Header-Details）是一种常见的关系型数据库表设计模式，用于存储具有父子关系的数据，例如订单和订单项、发票和发票明细等。

在头表、行表模式中，父表（Header）存储主要信息，如订单号、日期、客户信息等，而子表（Details）存储与父表相关的详细信息，如订单项、发票明细等。子表与父表之间通过外键关联，一般是父表的主键作为子表的外键。

建立头表和行表，是为了避免冗余数据的出现，头表和行表由一对多的关系联系。

具体来说，头表、行表模式通常包含以下几个方面：

• 头表：头表是父表，通常包含一些关键信息，如订单号、日期、客户信息等。头表的主键通常是唯一的，可以用于与子表进行关联。

  • 包含主键
  • 包含 entire object 的属性

• 行表：行表是子表，包含与头表相关的详细信息，如订单项、发票明细等。行表通常包含一个外键列，与头表的主键进行关联，以便将子表数据与父表数据关联起来。

  • 包含其自己的主键
  • 有联系到头表的非空外键
  • 包含 specific subitems 的属性（每条明细不同）

• 关联：头表和行表通过外键关联，建立父子关系。具体来说，头表的主键列作为行表的外键列，行表通过外键列引用头表的主键，建立与头表的关联关系。

所有头表的外键和退化维度都应包含在行表（事实表）中。

一个例子

• 头表：订单信息（头ID，超市编号、购买时间、收款员），主键（头ID）
• 行表：订单明细（头ID，行ID，细目名称，数量，单价），主键（头ID，行ID），外键（头ID）

张三买3个面包、30代牛奶和1块黄油的订单，数据这样存储：

• 头表:
  • 1,1,2012-12-13,“小王”
• 行表：
  • 1,1,面包,3,3.00
  • 1,2,牛奶,30,1.20
  • 1,3,黄油,1,5.00

如果存在一张表中(订单ID,细目ID，超市编号，购买时间，收款员，细目名称，数量，单间）就会变成这样（前面的数据就是冗余的），不符合2NF

• 1,1,2012-12-13,“小王”,3,面包,3,3.00
• 1,2,2012-12-13,“小王”,30,牛奶,2.00
• 1,3,2012-12-13,“小王”,1,黄油,1,5.00

如果串资料时，如果不涉及详细内容，比如统计订单数量，或者收款员的工作量，可以只取头表信息
如果要详细信息的内容，比如统计牛奶、面包卖了多少
就要头表和行表做关联查询

缺点

头表、行表模式也存在一些缺点，如需要进行复杂的查询和连接操作，容易出现性能问题；同时，在数据模型发生变化时需要进行复杂的维护操作。因此，在具体的应用场景中需要根据实际情况选择适当的数据模型。

复习：3NF范式

• 1NF:原子性
• 2NF:部分依赖
• 3NF:传递依赖

参考

https://dataedo.com/kb/data-design-patterns/header-lines-tables
ChatGPT