Access数据模型：轻量关系型

Access这个数据库工具，说到底是微软塞给Office套件里的一件关系型数据库管理系统的外衣。很多人一打开它，看到那些表格、查询、窗体，心里会犯嘀咕，这玩意儿跟Excel有什么区别？其实区别大了。Excel是一张无限延展的大纸，你可以在上面随意涂写，而Access骨子里遵循的是一套严谨得近乎固执的数据模型规则，这套规则叫关系模型。

关系模型这个概念，听起来挺唬人，实际上你把它拆开看就明白了。它不像Excel那样把数据堆在一个大平面上，而是讲究把数据分门别类放进不同的表格里，然后用一种看不见的线把表与表之间串联起来。这条线就是关系。打个比方，你手头有一批客户和一批订单，Excel的做法是把客户名字、电话、地址和订单号、金额全塞在同一行里，看着方便，可一旦某个客户下了十个订单，你就得把这客户的信息重复抄十遍，抄错了还理所当然。Access不是这么干的，它会设计一张客户表，里面只有一个客户ID和对应的姓名、电话，再设计一张订单表，里面存订单号、金额，外加一个字段存客户ID，这个ID就是那条连接两张表的线。这就是关系模型里最核心的东西，主键和外键。客户ID在客户表里是主键，在订单表里就成了外键。

这种设计带来的好处，最直观的就是省地方，以及消掉了数据冗余。但比省地方更关键的，是它保证了数据的一致性。你想想，如果客户改了电话号码，Excel里要是那十行都存了旧号码，你得逐行改，改漏一行就出乱子。在Access的关系模型里，你只需要改客户表那一条记录，订单查询时自然关联出新的号码，永远不担心不同表里数据对不上。这叫做参照完整性，是关系模型里顶顶要紧的一条规矩。

Access这个系统在实现关系模型时，有它独特的脾气。它不像SQL Server或者Oracle那些大型数据库，动辄要你在服务器上配置半天，Access的一切都装在一个扩展名是accdb的文件里，表、查询、窗体、报表，甚至是背后的VBA代码，全在这一个文件里装着呢。这也决定了它的命数，它是一个文件型数据库，适合单机使用，或者小规模局域网里十来个人同时用。你要是拿它去做银行核心系统，那纯粹是找不自在。根据微软官方的说明，Access数据库文件的大小上限是2GB，这个硬指标在那儿摆着，就注定它不是吃那碗饭的料。

但Access让人称道的地方，在于它对关系模型的实现，采用了可视化的拖拽操作。你不必像在SQL Server里那样一字一句敲创建表的SQL语句，当然你要是习惯，它也有SQL视图供你折腾。在普通的表设计视图里，你定义字段类型，比如文本、数字、日期、是/否，还能设置主键，一个字段不想让人重复输入，你就把它设成主键，系统自动给你建索引，查询速度自然就上去了。这种设计思路，拉低了关系型数据库入门的门槛，很多做行政、做财务、做运营的普通办公族，通过Access也能搭出像模像样的业务数据管理系统。

Access的数据模型里还有一层，查询对象。你基于已建好的表，创建查询，这本质上就是在做关系运算。比如说你写一个查询，把客户表和订单表通过客户ID关联起来，再筛选出金额大于一千的记录，这放到数据库理论里，就是做了一次连接操作加上一次选择操作。Access把这种理论化的操作变得像填空一样简单，你用设计网格勾选字段、填入条件，后台自动转换成SQL语句去执行。所以你看，哪怕操作者完全不懂关系代数，也能用Access玩转关系模型。

窗体则是在表之上套了一层更友好的人机交互界面。你不想让操作员直接看到底层的表结构，怕他们乱改数据，那就做几个窗体，上面放几个文本框和按钮，操作员只需填写和点击。这层设计体现了关系模型里数据独立性的思想，底层的表结构再怎么调整，只要窗体上的绑定字段不变，用户根本感知不到变化。

综合来看，Access的数据模型，就是那种包着糖衣的关系模型。它的本质和那些企业级数据库没有差别，都是建立在集合论和谓词逻辑之上的数学结构。只是微软把它做成了一个人人可上手的桌面工具。你用它处理中小规模的业务数据，做仓储进销存、做客户管理、做项目跟踪，它这套模型完全扛得住，而且开发成本极低。你可能只需要一个下午的时间，就能把表和关系理清楚，这种敏捷性，是大数据库给不了你的日常乐趣。要说它的天花板在哪，大概就是并发访问能力受限，文件会被锁定，这是文件型数据库的天生缺陷，怨不得关系模型本身。所以理解Access，你得透过界面看底下的逻辑，理解了那层逻辑，你就明白了数据库世界的共通语言。