从面向对象的角度规范数据库表的设计

　　在关系型数据库中，重要的概念就是实体与关系。设计一个商业数据库的过程，主要就是确定商业实体，研究实体关系，并在此基础上创建数据表的过程。至于建立在数据表之上的视图、索引、存储过程和触发器等优化和操作工作，则相对比较容易。

　　因此，数据库设计的重点，就在于商业实体的界定和实体关系的分解。而难点则在于从关系到实际建表的 转化。许多初学者，对这个转化往往感觉似是而非、难以把握!

　　本文根据作者多年的设计经验，从面向对象的角度，探讨了数据库的实体及其关系问题，并给出了数据表的设计原则和规范。供各位初级程序员和学生参考，期望对您的学习和工作有所启发。如有不认同之处，还望坦诚交流或批评指正。

　　一、实体与对象

　　数据库中的实体，其实就是我们程序设计中所说的对象。抽象地讲，实体就是一个独立存在，具备一定的行为能力和个体特征的事物(包括人和物)。比如：人、动物、微生物;汽车、火车、电动车;桌子、房子和票子(货币);电视、电脑、机器人等等，都是自然界的实体，也可以成为我们数据库中的实体。请记住：实体就是对象。只是数据库设计中，习惯称作实体。

　　二、实体具有属性和行为

　　凡是实体，都具有自己的属性特征。比如：人有姓名、性别、肤色、生日、学历、爱好等等，桌子有结构、形状、大小、颜色、承重能力等等。属性是我们辨认和描述实体的主要依据。不同的实体，属性不一样。

　　实体，还有自己的行为能力。比如：人会吃饭、睡觉、工作、交友、旅游、恋爱等，属于主动行为能力;房子能住人、货币能流通，属于被动行为能力。

　　如何区分属性和行为呢?

　　属性描述实体的名称和状态，包括结构、时间、空间、声音和光电状态等，是相对静态的;而行为描述实体的动作能力，一般表现为一个动态的过程。比如，张三的生日是 1990 年 7 月 20 日，描述了张三这个实体出生时的时间状态，是属性。而孕妇李四的分娩是行为，描述的是李四生产婴儿的动作过程。李四的分娩行为是一个可以重复的过程，每次正常怀孕的后都会分娩;而张三的生日属性值只能有一个，是只读属性，且不能更改。张三的身高也是属性，描述了他的空间高度状态，但在张三成长的行为过程中，身高属性是随成长 行为变化的，身高属于可读可写属性。

　　三、实体关系的本质

　　实体之间为什么会发生关系呢?其实这是因为实体的行为造成的。如果没有行为，实体之间可以永远不发生关系。正是因为人类有了旅行的行为能力和住宿的要求，才会发生旅客与宾馆客房的住宿关系。所以，实体关系的本质就是实体的行为能力。在发生关系的两个实体之间，一定有一个具备主动行为能力，而另一个具有被动行为能力。我们可以锁定一类实体，通过研究它的属性集，跟踪它们与当前项目相关的行为过程，逐步理清商业项目的逻辑流程和数据流程，完成数据库表的设计。而从关系出发，研究实体之间错综复杂的关系，往往让初学者理不清头绪，无从下手，容易弄糊涂。

　　因此，本文主张，在数据库设计的实践中，应该从面向对象的角度，来研究实体与当前项目需求相关的属性和行为，从而揭示出实体之间的抽象关系。这样有利于把抽象的实体关系，具体化为实体的属性和行为研究，更接近于人的感性认知习惯，不会有难以把握、琢磨不定的感觉。

　　四、创建数据库表的基本步骤和原则

　　既然与实体相关的信息，可以分为属性和行为两类，那么用于记载实体信息的数据库表，也就自然地要分成属性和行为两类了，即属性信息表和行为记录表。又由于有些属性的取值范围是确定的，比如：学历包括文盲、小学、初中、高中、、、硕士、博士和博士后等，当某个在线用户注册时，我们希望他能选取这些确定值当中的一个，来描述他自己的高学历，既规范了输入，又便于以后查询。因此，我们可以把这些学历值单独地保存在一张数据表里面，构成一个字典表。在用户注册时主动提供给用户选用。于是，数据库表就分成了基本属性表、字典表和行为记录表三大类。

　　创建数据库表的基本步骤和原则是：

　　1、 根据需求调查与分析，确定当前项目涉及到的所有实体类(即同一类实体的抽象描述)。比如：客户类，即是所有可能的宾馆客人的抽象描述。客房类，即是宾馆部可住房 间的抽象描述。

　　2、 根据需求分析，确定每个类的详细属性和行为集合。

　　3、 按照实体、属性、行为的逻辑，绘制 E-R 图(注意：行为的结果表现为关系)，用于开发团队内部以及与用户之间的交流与确认。

　　4、 按照如下原则创建数据表模型：

　　1 )一张表只描述一个实体类的属性信息;

　　2 )一张表只记录一个实体类的一种行为过程;

　　3 )一张表只记录一个属性的字典值。

　　换一个角度说，就是有多少类实体，就要建多少个属性信息表，有多少种行为(或者叫事件)就建多少个行为记录表，再加上为属性提供可选值的字典表，就是我们要设计的部数据表了。

　　5、 按照规范化的要求，使用三个范式标准检查每张表的属性字段是否符合原子性要求，以及属性字段是否与主键字段直接相关，并排除数据表中不必要的冗余字段。

　　6、 确定表之间的主外键关系 ，包含字典表的主外键关系 。

　　五、实例：宾馆住宿管理系统数据表

　　(一)实体属性表

　　员工属性表

　　证件类型字典表  

　　客房状态字典表

　　　住宿登记表

　　六、小结

　　本文的核心是在经典的关系数据库的设计思想中，引入了对象行为的概念，用行为来揭示关系的本质，用行为记录表来记载行为过程的详细信息，让描述行为特征的信息字段从属性集合中独立出来，即理清了实体关系的逻辑，又纯洁了实体的属性集合。再加上字典表概念的引入，使关系数据表的设计不再扑朔迷离，无从下手，而是脉络清晰，逻辑严密，便于理解。本文没有给出改进后的实体关系图—— E-R 图的画法，欢迎有兴趣的同行参与讨论并给出方案建议。