给开发者瞅的关系型数据库设计
日期：2014-05-16 浏览次数：20424 次
给开发者看的关系型数据库设计
目录
一 Codd的RDBMS12法则——RDBMS的起源
二 关系型数据库设计阶段
三 设计原则
四 命名规则
数据库设计，一个软件项目成功的基石。很多从业人员都认为，数据库设计其实不那么重要。现实中的情景也相当雷同，开发人员的数量是数据库设计人员的数倍。多数人使用数据库中的一部分，所以也会把数据库设计想的如此简单。其实不然，数据库设计也是门学问。
从笔者的经历看来，笔者更赞成在项目早期由开发者进行数据库设计（后期调优需要DBA）。根据笔者的项目经验，一个精通OOP和ORM的开发者，设计的数据库往往更为合理，更能适应需求的变化，如果追其原因，笔者个人猜测是因为数据库的规范化，与OO的部分思想雷同（如内聚）。而DBA，设计的数据库的优势是能将DBMS的能力发挥到极致，能够使用SQL和DBMS实现很多程序实现的逻辑，与开发者相比，DBA优化过的数据库更为高效和稳定。如标题所示，本文旨在分享一名开发者的数据库设计经验，并不涉及复杂的SQL语句或DBMS使用，因此也不会局限到某种DBMS产品上。真切地希望这篇文章对开发者能有所帮助，也希望读者能帮助笔者查漏补缺。
一 Codd的RDBMS12法则——RDBMS的起源
Edgar Frank Codd（埃德加·弗兰克·科德）被誉为“关系数据库之父”，并因为在数据库管理系统的理论和实践方面的杰出贡献于1981年获图灵奖。在1985年，Codd 博士发布了12条规则，这些规则简明的定义出一个关系型数据库的理念，它们被作为所有关系数据库系统的设计指导性方针。
1、信息法则 关系数据库中的所有信息都用唯一的一种方式表示——表中的值。
2、保证访问法则 依靠表名、主键值和列名的组合，保证能访问每个数据项。
3、空值的系统化处理 支持空值（NULL），以系统化的方式处理空值，空值不依赖于数据类型。
4、基于关系模型的动态联机目录 数据库的描述应该是自描述的，在逻辑级别上和普通数据采用同样的表示方式，即数据库必须含有描述该数据库结构的系统表或者数据库描述信息应该包含在用户可以访问的表中。
5、统一的数据子语言法则 一个关系数据库系统可以支持几种语言和多种终端使用方式，但必须至少有一种语言，它的语句能够一某种定义良好的语法表示为字符串，并能全面地支持以下所有规则：数据定义、视图定义、数据操作、约束、授权以及事务。（这种语言就是SQL)
6、视图更新法则 所有理论上可以更新的视图也可以由系统更新。
7、高级的插入、更新和删除操作 把一个基础关系或派生关系作为单个操作对象处理的能力不仅适应于数据的检索，还适用于数据的插入、修改个删除，即在插入、修改和删除操作中数据行被视作集合。
8、数据的物理独立性 不管数据库的数据在存储表示或访问方式上怎么变化，应用程序和终端活动都保持着逻辑上的不变性。
9、数据的逻辑独立性 当对表做了理论上不会损害信息的改变时，应用程序和终端活动都会保持逻辑上的不变性。
10、数据完整性的独立性 专用于某个关系型数据库的完整性约束必须可以用关系数据库子语言定义，而且可以存储在数据目录中，而非程序中。
11、分布独立性 不管数据在物理是否分布式存储，或者任何时候改变分布策略，RDBMS的数据操纵子语言必须能使应用程序和终端活动保持逻辑上的不变性。
12、非破坏性法则 如果一个关系数据库系统支持某种低级（一次处理单个记录）语言，那么这个低级语言不能违反或绕过更高级语言（一次处理多个记录）规定的完整性法则或约束，即用户不能以任何方式违反数据库的约束。
二 关系型数据库设计阶段
（一）规划阶段
规划阶段的主要工作是对数据库的必要性和可行性进行分析。确定是否需要使用数据库，使用哪种类型的数据库，使用哪个数据库产品。
（二）概念阶段
概念阶段的主要工作是收集并分析需求。识别需求，主要是识别数据实体和业务规则。对于一个系统来说，数据库的主要包括业务数据和非业务数据，而业务数据的定义，则依赖于在此阶段对用户需求的分析。需要尽量识别业务实体和业务规则，对系统的整体有初步的认识，并理解数据的流动过程。理论上，该阶段将参考或产出多种文档，比如“用例图”，“数据流图”以及其他一些项目文档。如果能够在该阶段产出这些成果，无疑将会对后期进行莫大的帮助。当然，很多文档已超出数据库设计者的考虑范围。而且，如果你并不精通该领域以及用户的业务，那么请放弃自己独立完成用户需求分析的想法。用户并不是技术专家，而当你自身不能扮演“业务顾问”的角色时，请你选择与项目组的相关人员合作，或者将其视为风险呈报给PM。再次强调，大多数情况，用户只是行业从业者，而非职业技术人员，我们仅仅从用户那里收集需求，而非依赖于用户的知识。
记录用户需求时，可以使用一些技巧，当然这部分内容有些可能会超出数据库设计人员的职责：
努力维护一系列包含了系统设计和规格说明信息的文档，如会议记录、访谈记录、关键用户期望、功能规格、技术规格、测试规格等。
频繁与干系人沟通并收集反馈。
标记出你自己添加的，不属于客户要求的，未决内容。
与所有关键干系人尽快确认项目范围，并力求冻结需求。
此外，必须严谨处理业务规则，并详细记录。在之后的阶段，将会根据这些业务规则进行设计。
当该阶段结束时，你应该能够回答以下问题：
需要哪些数据？
数据该被怎样使用？
哪些规则控制着数据的使用？
谁会使用何种数据？
客户想在核心功能界面或者报表上看到哪些内容？
数据现在在哪里？
数据是否与其他系统有交互、集成或同步？
主题数据有哪些？
核心数据价值几何，对可靠性的要求程度？
并且得到如下信息：
实体和关系
属性和域
可以在数据库中强制执行的业务规则
需要使用数据库的业务过程
（三）逻辑阶段
逻辑阶段的主要工作是绘制E-R图，或者说是建模。建模工具很多，有不同的图形表示方法和软件。这些工具和软件的使用并非关键，笔者也不建议读者花大量时间在建模方法的选择上。对于大多数应用来说，E-R图足以描述实体间的关系。建模关键是思想而不是工具，软件只是起到辅助作用，识别实体关系才是本阶段的重点。
除了实体关系，我们还应该考虑属性的域（值类型、范围、约束）
（四）实现阶段
实现阶段主要针对选择的RDBMS定义E-R图对应的表，考虑属性类型和范围以及约束。
（五）物理阶段
物理阶段是一个验证并调优的阶段，是在实际物理设备上部署数据库，并进行测试和调优。
三 设计原则
（一）降低对数据库功能的依赖
功能应该由程序实现，而非DB实现。原因在于，如果功能由DB实现时，一旦更换的DBMS不如之前的系统强大，不能实现某些功能，这时我们将不得不去修改代码。所以，为了杜绝此类情况的发生，功能应该有程序实现，数据库仅仅负责数据的存储，以达到最低的耦合。
（二）定义实体关系的原则
当定义一个实体与其他实体之间的关系时，需要考量如下：
牵涉到的实体 识别出关系所涉及的所有实体。
所有权 考虑一个实体“拥有”另一个实体的情况。
基数 考量一个实体的实例和另一个实体实例关联的数量。
关系与表数量
描述1:1关系最少需要1张表。
描述1:n关系最少需要2张表。
描述n:n关系最少需要3张表。
（三）列意味着唯一的值
如果表示坐标（0,0），应该使用两列表示，而不是将“0,0”放在1个列中。
（四）列的顺序
列的顺序对于表来说无关紧要，但是从习惯上来说，采用“主键+外键+实体数据+非实体数据”这样的顺序对列进行排序显然能得到比较好的可读性。
（五）定义主键和外键
数据表必须定义主键和外键（如果有外键）。定义主键和外键不仅是RDBMS的要求，同时也是开发的要求。几乎所有的代码生成器都需要这些信息来生成常用方法的代码（包括SQL文和引用），所以，定义主键和外键在开发阶段是必须的。之所以说在开发阶段是必须的是因为，有不少团队出于性能考虑会在进行大量测试后，在保证参照完整性不会出现大的缺陷后，会删除掉DB的所有外键，以达到最优性能。笔者认为，在性能没有出现问题时应该保留外键，而即便性能真的出现问题，也应该对SQL文进行优化，而非放弃外键约束。
目录
一 Codd的RDBMS12法则——RDBMS的起源
二 关系型数据库设计阶段
三 设计原则
四 命名规则
数据库设计，一个软件项目成功的基石。很多从业人员都认为，数据库设计其实不那么重要。现实中的情景也相当雷同，开发人员的数量是数据库设计人员的数倍。多数人使用数据库中的一部分，所以也会把数据库设计想的如此简单。其实不然，数据库设计也是门学问。
从笔者的经历看来，笔者更赞成在项目早期由开发者进行数据库设计（后期调优需要DBA）。根据笔者的项目经验，一个精通OOP和ORM的开发者，设计的数据库往往更为合理，更能适应需求的变化，如果追其原因，笔者个人猜测是因为数据库的规范化，与OO的部分思想雷同（如内聚）。而DBA，设计的数据库的优势是能将DBMS的能力发挥到极致，能够使用SQL和DBMS实现很多程序实现的逻辑，与开发者相比，DBA优化过的数据库更为高效和稳定。如标题所示，本文旨在分享一名开发者的数据库设计经验，并不涉及复杂的SQL语句或DBMS使用，因此也不会局限到某种DBMS产品上。真切地希望这篇文章对开发者能有所帮助，也希望读者能帮助笔者查漏补缺。
一 Codd的RDBMS12法则——RDBMS的起源
Edgar Frank Codd（埃德加·弗兰克·科德）被誉为“关系数据库之父”，并因为在数据库管理系统的理论和实践方面的杰出贡献于1981年获图灵奖。在1985年，Codd 博士发布了12条规则，这些规则简明的定义出一个关系型数据库的理念，它们被作为所有关系数据库系统的设计指导性方针。
1、信息法则 关系数据库中的所有信息都用唯一的一种方式表示——表中的值。
2、保证访问法则 依靠表名、主键值和列名的组合，保证能访问每个数据项。
3、空值的系统化处理 支持空值（NULL），以系统化的方式处理空值，空值不依赖于数据类型。
4、基于关系模型的动态联机目录 数据库的描述应该是自描述的，在逻辑级别上和普通数据采用同样的表示方式，即数据库必须含有描述该数据库结构的系统表或者数据库描述信息应该包含在用户可以访问的表中。
5、统一的数据子语言法则 一个关系数据库系统可以支持几种语言和多种终端使用方式，但必须至少有一种语言，它的语句能够一某种定义良好的语法表示为字符串，并能全面地支持以下所有规则：数据定义、视图定义、数据操作、约束、授权以及事务。（这种语言就是SQL)
6、视图更新法则 所有理论上可以更新的视图也可以由系统更新。
7、高级的插入、更新和删除操作 把一个基础关系或派生关系作为单个操作对象处理的能力不仅适应于数据的检索，还适用于数据的插入、修改个删除，即在插入、修改和删除操作中数据行被视作集合。
8、数据的物理独立性 不管数据库的数据在存储表示或访问方式上怎么变化，应用程序和终端活动都保持着逻辑上的不变性。
9、数据的逻辑独立性 当对表做了理论上不会损害信息的改变时，应用程序和终端活动都会保持逻辑上的不变性。
10、数据完整性的独立性 专用于某个关系型数据库的完整性约束必须可以用关系数据库子语言定义，而且可以存储在数据目录中，而非程序中。
11、分布独立性 不管数据在物理是否分布式存储，或者任何时候改变分布策略，RDBMS的数据操纵子语言必须能使应用程序和终端活动保持逻辑上的不变性。
12、非破坏性法则 如果一个关系数据库系统支持某种低级（一次处理单个记录）语言，那么这个低级语言不能违反或绕过更高级语言（一次处理多个记录）规定的完整性法则或约束，即用户不能以任何方式违反数据库的约束。
二 关系型数据库设计阶段
（一）规划阶段
规划阶段的主要工作是对数据库的必要性和可行性进行分析。确定是否需要使用数据库，使用哪种类型的数据库，使用哪个数据库产品。
（二）概念阶段
概念阶段的主要工作是收集并分析需求。识别需求，主要是识别数据实体和业务规则。对于一个系统来说，数据库的主要包括业务数据和非业务数据，而业务数据的定义，则依赖于在此阶段对用户需求的分析。需要尽量识别业务实体和业务规则，对系统的整体有初步的认识，并理解数据的流动过程。理论上，该阶段将参考或产出多种文档，比如“用例图”，“数据流图”以及其他一些项目文档。如果能够在该阶段产出这些成果，无疑将会对后期进行莫大的帮助。当然，很多文档已超出数据库设计者的考虑范围。而且，如果你并不精通该领域以及用户的业务，那么请放弃自己独立完成用户需求分析的想法。用户并不是技术专家，而当你自身不能扮演“业务顾问”的角色时，请你选择与项目组的相关人员合作，或者将其视为风险呈报给PM。再次强调，大多数情况，用户只是行业从业者，而非职业技术人员，我们仅仅从用户那里收集需求，而非依赖于用户的知识。
记录用户需求时，可以使用一些技巧，当然这部分内容有些可能会超出数据库设计人员的职责：
努力维护一系列包含了系统设计和规格说明信息的文档，如会议记录、访谈记录、关键用户期望、功能规格、技术规格、测试规格等。
频繁与干系人沟通并收集反馈。
标记出你自己添加的，不属于客户要求的，未决内容。
与所有关键干系人尽快确认项目范围，并力求冻结需求。
此外，必须严谨处理业务规则，并详细记录。在之后的阶段，将会根据这些业务规则进行设计。
当该阶段结束时，你应该能够回答以下问题：
需要哪些数据？
数据该被怎样使用？
哪些规则控制着数据的使用？
谁会使用何种数据？
客户想在核心功能界面或者报表上看到哪些内容？
数据现在在哪里？
数据是否与其他系统有交互、集成或同步？
主题数据有哪些？
核心数据价值几何，对可靠性的要求程度？
并且得到如下信息：
实体和关系
属性和域
可以在数据库中强制执行的业务规则
需要使用数据库的业务过程
（三）逻辑阶段
逻辑阶段的主要工作是绘制E-R图，或者说是建模。建模工具很多，有不同的图形表示方法和软件。这些工具和软件的使用并非关键，笔者也不建议读者花大量时间在建模方法的选择上。对于大多数应用来说，E-R图足以描述实体间的关系。建模关键是思想而不是工具，软件只是起到辅助作用，识别实体关系才是本阶段的重点。
除了实体关系，我们还应该考虑属性的域（值类型、范围、约束）
（四）实现阶段
实现阶段主要针对选择的RDBMS定义E-R图对应的表，考虑属性类型和范围以及约束。
（五）物理阶段
物理阶段是一个验证并调优的阶段，是在实际物理设备上部署数据库，并进行测试和调优。
三 设计原则
（一）降低对数据库功能的依赖
功能应该由程序实现，而非DB实现。原因在于，如果功能由DB实现时，一旦更换的DBMS不如之前的系统强大，不能实现某些功能，这时我们将不得不去修改代码。所以，为了杜绝此类情况的发生，功能应该有程序实现，数据库仅仅负责数据的存储，以达到最低的耦合。
（二）定义实体关系的原则
当定义一个实体与其他实体之间的关系时，需要考量如下：
牵涉到的实体 识别出关系所涉及的所有实体。
所有权 考虑一个实体“拥有”另一个实体的情况。
基数 考量一个实体的实例和另一个实体实例关联的数量。
关系与表数量
描述1:1关系最少需要1张表。
描述1:n关系最少需要2张表。
描述n:n关系最少需要3张表。
（三）列意味着唯一的值
如果表示坐标（0,0），应该使用两列表示，而不是将“0,0”放在1个列中。
（四）列的顺序
列的顺序对于表来说无关紧要，但是从习惯上来说，采用“主键+外键+实体数据+非实体数据”这样的顺序对列进行排序显然能得到比较好的可读性。
（五）定义主键和外键
数据表必须定义主键和外键（如果有外键）。定义主键和外键不仅是RDBMS的要求，同时也是开发的要求。几乎所有的代码生成器都需要这些信息来生成常用方法的代码（包括SQL文和引用），所以，定义主键和外键在开发阶段是必须的。之所以说在开发阶段是必须的是因为，有不少团队出于性能考虑会在进行大量测试后，在保证参照完整性不会出现大的缺陷后，会删除掉DB的所有外键，以达到最优性能。笔者认为，在性能没有出现问题时应该保留外键，而即便性能真的出现问题，也应该对SQL文进行优化，而非放弃外键约束。
免责声明： 本文仅代表作者个人观点，与爱易网无关。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请读者仅作参考，并请自行核实相关内容。
