2.1 关系模型基础：表、字段与键
2.1 关系模型基础：表、字段与键
本节摘要：关系模型把数据组织成一张张二维表：列是字段（属性），行是记录（元组），主键负责唯一标记每一行，外键负责把两张表连起来。这四个词是全书的地基词汇，本节把它们一次讲透。
上一章末尾我们判断完"华彩的项目值得用 Access 做"，从这一节起正式动工。开工前先统一语言——建库领域很多争吵，其实是两个人嘴里的"表"根本不是同一个东西。
一、为什么偏偏是二维表
1970 年，IBM 研究员 E. F. Codd 发表论文提出关系模型时，数据库的主流还是层次模型和网状模型：记录之间靠指针硬连接，像一条焊死的流水线——业务稍变就要拆线重铺。Codd 的主张石破天惊：把所有数据统一组织成二维表，表与表之间不存物理指针，只在查询时按值匹配关联。表怎么摆、数据怎么找，从此解耦。
这个改动对使用者的意义可以用一个对比说清：在老式系统里回答"张三买过什么"要沿着指针爬格子；在关系模型里你只管提问"客户姓名等于张三的订单有哪些"，怎么翻找是引擎的事。检索意图与物理实现分离，业务再怎么变，表还是那些表。
Access 把这套理论藏在图形界面底下，于是很多人用了十年也没意识到自己天天在享受 Codd 的遗产。表设计器里每拖一条联接线，本质上都在上演一场五十年前的学术革命。
二、四个地基概念
表（Table）：一类事物的清单。客户是一张表，订单是一张表，货品也是一张表。判定某样东西配不配单独成表的粗略标准：它有没有需要独立维护的一批属性，以及会不会被别的单据反复引用。
字段（Field）：表格的列，对应事物的一个属性。"客户"表有客户名称、联系电话、结算方式这些列。每个字段必须声明类型——文本、数字、日期各归各位，这是 Access 与 Excel 最原则性的分歧。
记录（Record）：表格的行，一行代表一个具体对象的一次完整描述。记录无序是关系模型的另一个要点：你要第几名不重要，你要满足条件的集合才重要。
键（Key）：行的身份证与表间的桥梁。候选键中选定一个作主键；出现在另一张表里充当引用时叫外键。理解了键，就理解了整个数据库为何能"表散而神不散"。
上面这张 E-R 图读法：竖线加圈表示"零或多"，即一个客户可以没有任何订单，也可以下很多单；每个订单则必然归属恰好一个客户。形状本身就把业务规则画出来了——这正是建模的可视化价值。
三、选主键的三条铁律
Access 建表时会问要不要自动编号主键，很多新手随手点掉，给自己埋雷。挑主键记住三条：
- 永不变化。手机号、工牌号都不合格——总有人换号换部门。一旦主键被外键引用，改它等于连环车祸。
- 永不为空、永不重复。这条看起来废话，实际常被"用姓名当主键"的人打脸，同姓同名在企业里遍地都是。
- 尽量无业务含义。所以 Access 的自动编号类型是最常用的答案：一串系统生成的连续整数，跟任何现实属性脱钩，干净省心。
华彩案例中我们为每张表都设自动编号主键，同时另设一列带业务规则的编号（如订单号格式 HD202608001，HD 代表华彩）来满足人工沟通的需要。逻辑标识与现实编号分家，是这个技巧的核心：前者保证机器世界的稳定性，后者照顾人类的沟通习惯，两不相扰。
图题：自动编号主键与业务单号的分工
四、域的概念顺手讲一句
每个字段的取值范围叫域：性别字段的域是"男 / 女 / 未说明"，折扣字段的域是 0 到 1 之间的小数。Access 里控制域的手段依次有数据类型、查阅向导（下拉限定）、有效性规则三层。域约束做得越严，垃圾数据越进不来——第 4 章窗体校验只是这道防线的 UI 包装而已。
FAQ 时间。问：一张表可以没有主键吗？ 技术上可以，但会被排除在部分更新操作之外，且无法参与可靠联接，属于自残行为。问：主键一定要自动编号吗？ 不是，多字段组合也能做复合主键（比如"学生 + 课程"），但在 Access 桌面开发里九成情况自动编号更省心。
五、动手五分钟：把一段口语需求圈成实体
概念要趁热落地。拿华彩老板娘的原话来练手，她说："客户下单买货，我们发货，有的货还要从供应商那里调。月底我想知道每个客户买了多少、每家供应商供了多少。"三步把它变成骨架：
第一步，圈名词：客户、订单、货品、供应商、发货、月底统计。第二步，判断谁是实体：客户、货品、供应商是要长期记录的对象，留；"发货"是事件不是对象，它会长成一张订单明细表；"月底统计"是要提的问题，归第 3 章管，不属于结构。第三步，标关系基数：一个客户下多笔订单（一对多），一笔订单含多种货品（多对多，需要中间的明细实体拆解），货品与供应商之间也是多对多（同一货品可有多个货源）。
五分钟得到的草图虽然粗糙，但方向已定：四到五个实体、两条多对多关系。把它跟 2.5 节的成品对照着看，你能清楚看见"抽象"到底推进了哪些步。
初学者在这一步常走出三种歪路：把"统计报表"当成实体建了表（它是查询，不是存储）；把会发生多次的属性拍平成一堆列（买过八次的客户有八个购买日期列，就是拆表信号）；以及急着在纸上追求完美——草图的作用是暴露分歧、开启讨论，不是终稿。
E-R 草图的三个画法忠告
草图虽简，画法上也有三个常见走样要避开。其一，主外键别当普通属性写进实体框——它们是关系的产物，图上只画天然属性，落库时由关系自动生成对应列，提前手写反而会在建关系时造成同义不同名的断裂；其二，箭头方向统一"一对多的多端"，全图方向一致比 artistic 更重要，评审时混乱的方向感会消耗所有人的耐心；其三，动词命名关系线：客户—下单—订单比客户—拥有—订单精确得多，将来这张图直接就是查询设计的施工说明。
这三个忠告的共同指向只有一个目的：让图画出来是给人用的沟通工具，而不是供起来的装饰画。理解了这一点，你就不会纠结于工具选择——纸巾背面画的合格 E-R 图，胜过软件生成的漂亮乱线团。
这节的收获落袋
- 关系模型 = 二维表 + 键关联，检索意图与物理存储分离是它五十年来屹立不倒的原因。
- 表、字段、记录、键四个词务必用得精准；E-R 图是表达实体关系的通用手语。
- 主键三铁律：不变、非空唯一、无业务含义；自动编号默认首选。
- 业务单号与主键 ID 分家，机器逻辑与人类沟通互不干扰。
下一节进入动手环节：字段类型怎么选，规范化到底规范的是什么。