数据库设计
概要：
数据库是企业信息的核心，其应用水平的高低直接影响到企业管理水平。选择了一个高性能的数据库产品不等于就有一个好的数据库应用系统，如果数据库系统设计不合理，不仅会增加客户端和服务器端程序的编程和维护的难度，而且还会影响系统实际运行的性能。主要涉及数据库各种性能优化技术，从而避免磁盘I/O瓶颈、减少CPU利用率、大内存的设置和减少资源竞争。
大型数据库的设计与开发要复杂得多，因此在设计、开发过程中，除了要遵循数据库范式理论、增加系统的一致性和完整性外，还要在总体上根据具体情况进行分布式设计，紧紧把握集中控制、统一审核的基本原则，保证数据库设计结构紧凑、分布平衡、定位迅速。
数据库设计考虑工作
一、成立数据小组
大型数据库数据元素多，在设计上有必要成立专门的数据小组。由于数据库设计者不一定是使用者，对系统设计中的数据元素不可能考虑周全，数据库设计出来后，往往难以找到所需的库表，因此数据小组最好由熟悉业务的项目骨干组成。
数据小组的职能并非是设计数据库，而是通过需求分析，在参考其他相似系统的基础上，提取系统的基本数据元素，担负对数据库的审核。审核内容包括审核新的数据库元素是否完全、能否实现全部业务需求；对旧数据库（如果存在旧系统）的分析及数据转换；数据库设计的审核、控制及必要调整。
二、设计原则
１．规范命名。所有的库名、表名、域名必须遵循统一的命名规则，并进行必要说明，以方便设计、维护、查询。
２．控制字段的引用。在设计时，可以选择适当的数据库设计管理工具，以方便开发人员的分布式设计和数据小组的集中审核管理。采用统一的命名规则，如果设计的字段已经存在，可直接引用；否则，应重新设计。(必免出现不同位置的多义项目字段，如A表分类，类型) ３．表重复控制。在设计过程中，如果发现大部分字段都已存在，开发人员应怀疑所设计的库表是否已存在。通过对字段所在库表及相应设计人员的查询，可以确认库表是否确实重复。4．必要的讨论。数据库设计完成后，数据小组应与相关人员进行讨论，通过讨论来熟悉数据库，从而对设计中存在的问题进行控制或从中获取数据库设计的必要信息。
三、设计技巧
1．分类拆分数据量大的表。
（1）（根据数据析分不同表）对于经常使用的表（如某些参数表或代码对照表），由于其使用频率很高，要尽量减少表中的记录数量。（分好主从关系表的关系）例如，银行的户主账表原来设计成一张表，虽然可以方便程序的设计与维护，但经过分析发现，由于数据量太大，会影响数据的迅速定位。如果将户主账表分别设计为活期户主账、定期户主账及对公户主账等，则可以大大提高查询效率。
（2）（数据库级的分割）发现某个表的记录太多，例如超过一千万条，则要对该表进行水平分割。水平分割的做法是，以该表主键PK的某个值为界线，将该表的记录水平分割为两个表。若发现某个表的字段太多，例如超过八十个，则垂直分割该表，将原来的一个表分解为两个表。
2．索引设计。对于大的数据库表，合理的索引能够提高整个数据库的操作效率。在索引设计中，索引字段应挑选重复值较少的字段；在对建有复合索引的字段进行检索时，应注意按照复合索引字段建立的顺序进行。例如，如果对一个５万多条记录的流水表以日期和流水号为序建立复合索引，由于在该表中日期的重复值接近整个表的记录数，用流水号进行查询所用的时间接近３秒；而如果以流水号为索引字段建立索引进行相同的查询，所用时间不到１秒。因此在大型数据库设计中，只有进行合理的索引字段选择，才能有效提高整个数据库的操作效率。
3．避免长事务。对单个大表的删除或插入操作会带来大事务，较好的解决方法是，把整个事务分解成几个较小的事务，再由应用程序控制整个系统的流程。这样，如果其中某个事务不成功，则只需重做该事务，因而既可节约时间，又可避免长事务。（可减少排它锁时间）
4．将SQL的中的计算放在数据库这处理，最后才入库增加到表，这是电信计费系统的设计。
5．必免采用自增主键，不利数据的移植、及对业务主键不明而造成不易理解，增加开发难度及错误率。
6、
SQL的优化
1、多线程并发访问数据库（合并SQL：查询+更新，查询+增加的SQL）
2、在使用面向数据的SQL语言进行程序设计时，尽量采取优化算法。
（distinct改写成Exist）(in 语句改写成多个=式)
数据库设计
概要：
基于第三范式的数据库表的基本设计，建立主键和索引的策略和方案，然后从数据库表的扩展设计和库表对象的放置等角度概述了数据库管理系统的优化方案。
1.基本表的设计规范是第三范式（3NF）。第三范式的基本特征是非主键属性只依赖于主键
属性。基于第三范式的数据库表设计具有很多优点：一是消除了冗余数据，节省了磁盘存储空间；二是有良好的数据完整性限制，即基于主外键的参照完整限制和基于主键的实体完整性限制，这使得数据容易维护，也容易移植和更新；三是数据的可逆性好，在做连接（Join）查询或者合并表时不遗漏、也不重复；四是因消除了冗余数据（冗余列），在查询（Select）时每个数据页存的数据行就多，这样就有效地减少了逻辑I/O，每个Cash 存的页面就多，也减少物理I/O；五是对大多数事务(Transaction)而言，运行性能好；六是物理设计(Physical Design)的机动性较大，能满足日益增长的用户需求。
2.主键(Primary Key)：主键被用于复杂的SQL语句时，频繁地在数据访问中被用到。一个
表只有一个主键。主键应该有固定值（不能为Null或缺省值，要有相对稳定性），不含代码信息，易访问。把常用的列作为主键才有意义。短主键最佳（小于25bytes），主键的长短影响索引的大小，索引的大小影响索引页的大小，从而影响磁盘I/O。主键分为自然主键和人为主键。自然主键由实体的属性构成，自然主键可以是复合性的，在形成复合主键时，主键列不能太多，复合主键使得Join*作复杂化、也增加了外键表的大小。
人为主键是，在没有合适的自然属性键、或自然属性复杂或灵敏度高时，人为形成的。
人为主键一般是整型值（满足最小化要求），没有实际意义，也略微增加了表的大小；
但减少了把它作为外键的表的大小。
3.外键（Foreign Key）：外键的作用是建立关系型数据库中表之间的关系（参照完整性），
主键只能从独立的实体迁移到非独立的实体，成为后者的一个属性，被称为外键。
4. 索引(Index)：利用索引优化系统性能是显而易见的，对所有常用于查询
中的Where子句的列和所有用于排序的列创建索引，可以避免整表扫描或访问，在不改变表的物理结构的情况下，直接访问特定的数据列，这样减少数据存取时间；利用索引可以优化或排除耗时的分类*作；把数据分散到不同的页面上，就分散了插入的数据；主键自动建立了唯一索引，因此唯一索引也能确保数据的唯一性（即实体完整性）；索引码越小，定位就越直接；新建的索引效能最好，因此定期更新索引非常必要。索引也有代价：有空间开销，建立它也要花费时间，在进行Insert、Delete和Update*作时，也有维护代价。索引有两种：聚族索引和非聚族索引。一个表只能有一个聚族索引，可有多个非聚族索引。使用聚族索引查询数据要比使用非聚族索引快。在建索引前，应利用数据库系统函数估算索引的大小。
5. 锁：锁是并行处理的重要机制，能保持数据并发的一致性，即按事务进
行处理；系统利用锁，保证数据完整性。因此，我们避免不了死锁，但在设计时可以充分考虑如何避免长事务，减少排它锁时间，减少在事务中与用户
的交互，杜绝让用户控制事务的长短；要避免批量数据同时执行，尤其是耗时并用到相同的数据表。锁的征用：一个表同时只能有一个排它锁，一个用户用时，其它用户在等待。若用户数增加，则Server的性能下降，出现“假死”现象。如何避免死锁呢？从页级锁到行级锁，减少了锁征用；给小表增加无效记录，从页级锁到行级锁没有影响，若在同一页内竞争有影响，可选择合适的聚族索引把数据分配到不同的页面；创建冗余表；保持事务简短；同一批处理应该没有网络交互。
6. 查询优化规则
①尽可能少的行；
②避免排序或为尽可能少的行排序，若要做大量数据排序，最好将相关数据
放在临时表中*作；用简单的键（列）排序，如整型或短字符串排序；
③避免表内的相关子查询；
④避免在Where子句中使用复杂的表达式或非起始的子字符串、用长字符
串连接；
⑤在Where子句中多使用“与”（And）连接，少使用“或”(Or)连接；
⑥利用临时数据库。在查询多表、有多个连接、查询复杂、数据要过滤时，
可以建临时表（索引）以减少I/O。但缺点是增加了空间开销。
7. 分割表分为水平分割表和垂直分割表两种
数据库设计规范、技巧与命名规范 一、数据库设计过程 数据库技术是信息资源管理最有效的手段。 数据库设计是指：对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据， 满足用户信息要求和处理要求。 数据库设计的各阶段： A、需求分析阶段：综合各个用户的应用需求(现实世界的需求)。 B、在概念设计阶段：形成独立于机器和各DBMS产品的概念模式(信息世界模型)，用E-R图来描述。 C、在逻辑设计阶段：将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式。 然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图(VIEW)形成数据的外模式。 D、在物理设计阶段：根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。 1. 需求分析阶段 需求收集和分析，结果得到数据字典描述的数据需求(和数据流图描述的处理需求)。 需求分析的重点：调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。 需求分析的方法：调查组织机构情况、各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。 常用的调查方法有：跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。 分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法(Structured Analysis， 简称SA方法)从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并把每一层用数据流图和数据字典描述。 数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典(Data Dictionary，简称DD)来描述。 2. 概念结构设计阶段 通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型，可以用E-R图表示。 概念模型用于信息世界的建模。概念模型不依赖于某一个DBMS支持的数据模型。概念模型可以转换为计算机上某一 DBMS 支持的特定数据模型。 概念模型特点： (1) 具有较强的语义表达能力，能够方便、直接地表达应用中的各种语义知识。 (2) 应该简单、清晰、易于用户理解，是用户与数据库设计人员之间进行交流的语言。 概念模型设计的一种常用方法为IDEF1X方法，它就是把实体-联系方法应用到语义数据模型中的一种语义模型化技术， 用于建立系统信息模型。 使用IDEF1X方法创建E-R模型的步骤如下所示:
数据库设计方法及命名规范
- - 2 数据库设计方法、规范与技巧 (5) 一、数据库设计过程 (5) 1. 需求分析阶段 (6) 2. 概念结构设计阶段 (9) 2.1 第零步——初始化工程 (10) 2.2 第一步——定义实体 (10) 2.3 第二步——定义联系 (11) 2.4 第三步——定义码 (11) 2.5 第四步——定义属性 (12) 2.6 第五步——定义其他对象和规则 (12) 3. 逻辑结构设计阶段 (13) 4. 数据库物理设计阶段 (15) 5. 数据库实施阶段 (15) 6. 数据库运行和维护阶段 (16) 7.建模工具的使用 (16) 二、数据库设计技巧 (18) 1. 设计数据库之前（需求分析阶段） (18) 2. 表和字段的设计（数据库逻辑设计） (19) 1) 标准化和规范化 (19) 2) 数据驱动 (20)
- - 3 3) 考虑各种变化 (21) 4) 对地址和电话采用多个字段 (22) 5) 使用角色实体定义属于某类别的列 (22) 6) 选择数字类型和文本类型尽量充足 (23) 7) 增加删除标记字段 (24) 3. 选择键和索引（数据库逻辑设计） (24) 4. 数据完整性设计（数据库逻辑设计） (27) 1) 完整性实现机制： (27) 2) 用约束而非商务规则强制数据完整性 (27) 3) 强制指示完整性 (28) 4) 使用查找控制数据完整性 (28) 5) 采用视图 (28) 5. 其他设计技巧 (29) 1) 避免使用触发器 (29) 2) 使用常用英语（或者其他任何语言）而不 要使用编码 (29) 3) 保存常用信息 (29) 4) 包含版本机制 (30) 5) 编制文档 (30) 6) 测试、测试、反复测试 (31) 7) 检查设计 (31) 三、数据库命名规范 (31) 1. 实体（表）的命名 (31) 2. 属性（列）的命名 (34)
数据库设计的重要性和设计原则 发布时间: 2012-10-31 09:31 作者: wangpeng047 来源: 51Testing软件测试网采编 字体: 小中大| 上一篇下一篇| 打印| 我要投稿| 推荐标签：软件开 发数据库 说起数据库设计，相信大家都明白怎么回事，但说起数据库设计的重要性， 我想大家也只是停留在概念上而已，到底如何重要？怎么重要呢？今天就将我 至今为止的理解向大家阐述下。 一个不良的数据库设计，必然会造成很多问题，轻则增减字段，重则系统 无法运行。我先来说说数据库设计不合理的表现吧： 1、与需求不符 因为这个原因造成的改动量往往是最大。如果进入编码阶段的话，很可能 会直接让你崩溃掉。 2、性能低下 含有大数据量的表之间的关联过多；没有合理的字段设计来用于查询而造 成的SQL查询语句很复杂；对于大数据量的表没有采用有效的手段去处理；滥 用视图等。 3、数据完整性丧失 含有主外键关系的表之间关联字段的设计方式不合理，造成更新与删除操 作后程序容易出错或不完善；使用了已经删除或丢失掉的数据。 4、可扩展性性太差 表设计的与业务绑定的太紧密、单一，造成表的可拓展性、可修改性太差， 无法新需求的要求。 5、非必要数据冗余量太大 没用的垃圾数据存储过多，不仅占用资源，还影响查询效率。 6、不利于计算或统计
缺少必要的联系性或统计性字段或用于计算统计的字段分散于多个表中，造成计算统计的步骤繁琐，甚至无法计算统计。 7、没有详尽的数据记录信息 缺少必要的字段，造成无法跟踪数据变化、用户操作，也无法进行数据分析。 8、表之间的耦合性太大 多张表之间关联的过于紧密，造成一张表发生变化而影响到其他表。 9、字段设计考虑不周 字段长度过短或字段类型过于明确，造成可发挥、可拓展的空间太小。 大多数的程序员对于软件开发的出发点认识不是很明确，总是认为实现功能才是重要的，在简单了解完基本需求后就急忙进入编码阶段，对于数据库设计思考的比较少、比较简单，大多设计都只停留在表面上，这往往是要命的，会为系统留下很多隐患。要么是写代码开发过程中才发现问题，要么就是系统上线运转后没多久就出现问题，还有可能给后期维护增加了很多工作量。如果到了那个时候再想修改数据库设计或进行优化等同于推翻重来。 数据库是整个软件应用的根基，是软件设计的起点，它起着决定性的质变作用，因此我们必须对数据库设计高度重视起来，培养设计良好数据库的习惯，是一个优秀的软件设计师所必须具备的基本素质条件！ 那么我们要做到什么程度才是对的呢？下面就说说数据库设计的原则： 1、数据库设计最起码要占用整个项目开发的40%以上的时间 数据库是需求的直观反应和表现，因此设计时必须要切实符合用户的需求，要多次与用户沟通交流来细化需求，将需求中的要求和每一次的变化都要一一体现在数据库的设计当中。如果需求不明确，就要分析不确定的因素，设计表时就要事先预留出可变通的字段，正所谓“有备无患”。 2、数据库设计不仅仅停留于页面demo的表面 页面内容所需要的字段，在数据库设计中只是一部分，还有系统运转、模块交互、中转数据、表之间的联系等等所需要的字段，因此数据库设计绝对不是简单的基本数据存储，还有逻辑数据存储。
数据库设计和编码规范 Version
目录
简介 读者对象 此文档说明书供开发部全体成员阅读。 目的 一个合理的数据库结构设计是保证系统性能的基础。一个好的规范让新手容易进入状态且少犯错，保持团队支持顺畅，系统长久使用后不至于紊乱，让管理者易于在众多对象中，获取所需或理清问题。 同时，定义标准程序也需要团队合作，讨论出大家愿意遵循的规范。随着时间演进，还需要逐步校订与修改规范，让团队运行更为顺畅。 数据库命名规范 团队开发与管理信息系统讲究默契，而制定服务器、数据库对象、变量等命名规则是建立默契的基本。 命名规则是让所有的数据库用户，如数据库管理员、程序设计人员和程序开发人员，可以直观地辨识对象用途。而命名规则大都约定俗成，可以依照公司文化、团队习惯修改并落实。 规范总体要求 1.避免使用系统产品本身的惯例，让用户混淆自定义对象和系统对象或关键词。 例如，存储过程不要以sp_或xp_开头，因为SQL SERVER的系统存储过程以 sp_开头，扩展存储过程以xp_开头。 2.不要使用空白符号、运算符号、中文字、关键词来命名对象。 3.名称不宜过于简略，要让对象的用途直观易懂，但也不宜过长，造成使用不方 便。 4.不用为数据表内字段名称加上数据类型的缩写。 5.名称中最好不要包括中划线。
6.禁止使用[拼音]+[英语]的方式来命名数据库对象或变量。 数据库对象命名规范 我们约定，数据库对象包括表、视图（查询）、存储过程（参数查询）、函数、约束。对象名字由前缀和实际名字组成，长度不超过30。避免中文和保留关键字，做到简洁又有意义。前缀就是要求每种对象有固定的开头字符串，而开头字符串宜短且字数统一。可以讨论一下对各种对象的命名规范，通过后严格按照要求实施。例如：
数据库表设计的几条准则 前言：数据库设计在平时的工作是必不可少的，良好的表设计可以让我们查询效率更高，加快网站访问速度，提升用户体验，并且方便于我们查询数据。本篇博客就来聚焦一下，如何设计出高可复用，优良的表结构，从而在实际的工作中使我们写出更好的代码。 数据库表设计的几条黄金准则： 一：字段的原子性 解释：保证每列的原子性，不可分解，意思表达要清楚，不能含糊，高度概括字段的含义，能用一个字段表达清楚的绝不使用第二个字段，可以用两个字段表达清楚的绝不使用一个 字段 二：主键设计 解释：主键不要与业务逻辑有所关联，最好是毫无意义的一串独立不重复的数字，常见的比如UUID或者将主键设置为Auto_increment; 三：字段使用次数 解释：对于频繁修改的字段（一般是指状态类字段）最好用独立的数字或者单个字母去表示，不用使用汉字或者英文 四：字段长度 解释：建表的时候，字段长度尽量要比实际业务的字段大3-5个字段左右（考虑到合理性和伸缩性），最好是2的n次方幂值。不能建比实际业务太大的字段长度，这是因为如果字段长度过大，在进行查询的时候索引在B- Tree树上遍历会越耗费时间，从而查询的时间会越久；但是绝对不能建小，否则mysql数据会报错，程序会抛出异常； 五：关于外键 解释：尽量不要建立外键，保证每个表的独立性。如果非得保持一定的关系，最好是通过id 进行关联 六：动静分离 解释：最好做好静态表和动态表的分离。这里解释一下静态表和动态表的含义，静态表：存储着一些固定不变的资源，比如城市/地区名/国家。动态表：一些频繁修改的表 七：关于code值 解释：使用数字码或者字母去代替实际的名字，也就是尽量把name转换为code，因为name 可能会变（万一变化就会查询处多条数据，从而抛出错误），但是code一般是不会变化的.另一方面，code值存储的字符较少，也能减少数据库的压力 八：关于Null值 解释：不要有null值，有null值的话，数据库在进行索引的时候查询的时间更久，从而浪费更多的时间！
规范化－数据库设计原则 关系数据库设计的核心问题是关系模型的设计。本文将结合具体的实例，介绍数据库设计规范化的流程。摘要 关系型数据库是当前广泛使用的数据库类型，关系数据库设计是对数据进行组织化和结构化的过程，核心问题是关系模型的设计。对于数据库规模较小的情况，我们可以比较轻松的处理数据库中的表结构。然而，随着项目规模的不断增长，相应的数据库也变得更加复杂，关系模型表结构更为庞杂，这时我们往往会发现我们写出来的SQL语句的是很笨拙并且效率低下的。更糟糕的是，由于表结构定义的不合理，会导致在更新数据时造成数据的不完整。因此，就有必要学习和掌握数据库的规范化流程，以指导我们更好的设计数据库的表结构，减少冗余的数据，借此可以提高数据库的存储效率，数据完整性和可扩展性。本文将结合具体的实例，介绍数据库规范化的流程。 序言 本文的目的就是通过详细的实例来阐述规范化的数据库设计原则。在DB2中，简洁、结构明晰的表结构对数据库的设计是相当重要的。规范化的表结构设计，在以后的数据维护中，不会发生插入（insert）、删除（delete）和更新（update）时的异常。反之，数据库表结构设计不合理，不仅会给数据库的使用和维护带来各种各样的问题，而且可能存储了大量不需要的冗余信息，浪费系统资源。 要设计规范化的数据库，就要求我们根据数据库设计范式――也就是数据库设计的规范原则来做。但是一些相关材料上提到的范式设计，往往是给出一大堆的公式，这给设计者的理解和运用造成了一定的困难。因此，本文将结合具体形象的例子，尽可能通俗化地描述三个范式，以及如何在实际工程中加以优化使用。规范化 在设计和操作维护数据库时，关键的步骤就是要确保数据正确地分布到数据库的表中。使用正确的数据结构，不仅便于对数据库进行相应的存取操作，而且可以极大地简化使用程序的其他内容（查询、窗体、报表、代码等）。正确进行表设计的正式名称就是"数据库规范化"。后面我们将通过实例来说明具体的规范化的工程。关于什么是范式的定义，请参考附录文章1. 数据冗余 数据应该尽可能少地冗余，这意味着重复数据应该减少到最少。比如说，一个部门雇员的电话不应该被存储在不同的表中，因为这里的电话号码是雇员的一个属性。如果存在过多的冗余数据，这就意味着要占用了更多的物理空间，同时也对数据的维护和一致性检查带来了问题，当这个员工的电话号码变化时，冗余数据会导致对多个表的更新动作，如果有一个表不幸被忽略了，那么就可能导致数据的不一致性。 规范化实例 为了说明方便，我们在本文中将使用一个SAMPLE数据表，来一步一步分析规范化的过程。 首先，我们先来生成一个的最初始的表。 CREATE TABLE "SAMPLE" ( "PRJNUM" INTEGER NOT NULL, "PRJNAME" VARCHAR(200), "EMYNUM" INTEGER NOT NULL, "EMYNAME" VARCHAR(200), "SALCATEGORY" CHAR(1), "SALPACKAGE" INTEGER)
11-个重要的数据库设计规则
?简介 在您开始阅读这篇文章之前，我得明确地告诉您，我并不是一个数据库设计领域的大师。以下列出的11点是我对自己在平时项目实践和阅读中学习到的经验总结出来的个人见解。我个人认为它们对我的数据库设计提供了很大的帮助。实属一家之言，欢迎拍砖: ) 我之所以写下这篇这么完整的文章是因为，很多开发者一参与到数据库设计，就会很自然地把“三范式”当作银弹一样来使用。他们往往认为遵循这个规范就是数据库设计的唯一标准。由于这种心态，他们往往尽管一路碰壁也会坚持把项目做下去。 如果你对“三范式”不清楚，请点击这里（FQ）一步一步的了解什么是“三范式”。 大家都说标准规范是重要的指导方针并且也这么做着，但是把它当作石头上的一块标记来记着（死记硬背）还是会带来麻烦的。以下11点是我在数据库设计时最优先考虑的规则。 ?规则1：弄清楚将要开发的应用程序是什么性质的（OLTP 还是OPAP）？
当你要开始设计一个数据库的时候，你应该首先要分析出你为之设计的应用程序是什么类型的，它是“事务处理型”（Transactional）的还是“分析型”（Analytical）的？你会发现许多开发人员采用标准化做法去设计数据库，而不考虑目标程序是什么类型的，这样做出来的程序很快就会陷入性能、客户定制化的问题当中。正如前面所说的，这里有两种应用程序类型，“基于事务处理”和“基于分析”，下面让我们来了解一下这两种类型究竟说的是什么意思。 事务处理型：这种类型的应用程序，你的最终用户更关注数据的增查改删（CRUD，Creating/Reading/Updating/Deleting）。这种类型更加官方的叫法是“OLTP”。 分析型：这种类型的应用程序，你的最终用户更关注数据分析、报表、趋势预测等等功能。这一类的数据库的“插入”和“更新”操作相对来说是比较少的。它们主要的目的是更加快速地查询、分析数据。这种类型更加官方的叫法是“OLAP”。 那么换句话说，如果你认为插入、更新、删除数据这些操作在你的程序中更为突出的话，那就设计一个规范化的表否则的话就去创建一个扁平的、不规范化的数据库结构。
1概述 1.1目的 软件研发数据库设计规范作为数据库设计的操作规范，详细描述了数据库设计过程及结果，用于指导系统设计人员正确理解和开展数据库设计。 1.2适用范围 1.3术语定义 DBMS：数据库管理系统，常用的商业DBMS有Oracle, SQL Server, DB2等。 数据库设计：数据库设计是在给定的应用场景下，构造适用的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。 概念数据模型：概念数据模型以实体-关系 (Entity-RelationShip,简称E-R)理论为基础，并对这一理论进行了扩充。它从用户的观点出发对信息进行建模，主要用于数据库概念级别的设计，独立于机器和各DBMS产品。可以用Sybase PowerDesigner工具来建立概念数据模型（CDM）。 逻辑数据模型：将概念数据模型转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式。可
以用Sybase PowerDesigner工具直接建立逻辑数据模型（LDM），或者通过CDM转换得到。 物理数据模型：在逻辑数据模型基础上，根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。可以用Sybase PowerDesigner工具直接建立物理数据模型（PDM），或者通过CDM / LDM转换得到。 2数据库设计原则 按阶段实施并形成该阶段的成果物 一般符合3NF范式要求；兼顾规范与效率 使用公司规定的数据库设计软件工具 命名符合公司标准和项目标准 3数据库设计目标 规范性：一般符合3NF范式要求，减少冗余数据。 高效率：兼顾规范与效率，适当进行反范式化，满足应用系统的性能要求。 紧凑性：例如能用char(10)的就不要用char(20)，提高存储的利用率和系统性能，但同时也要兼顾扩展性和可移植性。 易用性：数据库设计清晰易用，用户和开发人员均能容
数据库设计方法、规范与技巧 一、数据库设计过程 数据库技术是信息资源管理最有效的手段。数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。 数据库设计中需求分析阶段综合各个用户的应用需求（现实世界的需求），在概念设计阶段形成独立于机器特点、独立于各个DBMS产品的概念模式（信息世界模型），用E-R图来描述。在逻辑设计阶段将E-R图转换成具体的数据库产品支持的数据模型如关系模型，形成数据库逻辑模式。然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图（VIEW）形成数据的外模式。在物理设计阶段根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。 1. 需求分析阶段 需求收集和分析，结果得到数据字典描述的数据需求（和数据流图描述的处理需求）。 需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。 需求分析的方法：调查组织机构情况、调查各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。 常用的调查方法有：跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。 分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法（Structured Analysis，简称SA方法）从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并把每一层用数据流图和数据字典描述。 数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典（Data Dictionary，简称DD）来描述。 数据字典是各类数据描述的集合，它是关于数据库中数据的描述，即元数据，而不是数据本身。数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五个部分(至少应该包含每个字段的数据类型和在每个表内的主外键)。 数据项描述＝｛数据项名，数据项含义说明，别名，数据类型，长度， 取值范围，取值含义，与其他数据项的逻辑关系｝ 数据结构描述＝｛数据结构名，含义说明，组成:｛数据项或数据结构｝｝ 数据流描述＝｛数据流名，说明，数据流来源，数据流去向， 组成:｛数据结构｝，平均流量，高峰期流量｝ 数据存储描述＝｛数据存储名，说明，编号，流入的数据流，流出的数据流， 组成:｛数据结构｝，数据量，存取方式｝ 处理过程描述＝｛处理过程名，说明，输入:｛数据流｝，输出:｛数据流｝, 处理:｛简要说明｝｝ 2. 概念结构设计阶段 通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型，可以用E-R图表示。概念模型用于信息世界的建模。概念模型不依赖于某一个DBMS支持的数据模型。概念模型可以转换为计算机上某一DBMS支持的特定数据模型。 概念模型特点： (1) 具有较强的语义表达能力，能够方便、直接地表达应用中的各种语义知识。 (2) 应该简单、清晰、易于用户理解，是用户与数据库设计人员之间进行交流的语言。 概念模型设计的一种常用方法为IDEF1X方法，它就是把实体-联系方法应用到语义数据模型中的一种语义模型化技术，用于建立系统信息模型。 使用IDEF1X方法创建E-R模型的步骤如下所示: 2.1 第零步——初始化工程
数据库设计规范 一、数据库设计过程 数据库技术是信息资源管理最有效的手段。数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。 数据库设计中需求分析阶段综合各个用户的应用需求（现实世界的需求），在概念设计阶段形成独立于机器特点、独立于各个dbms产品的概念模式（信息世界模型），用e-r图来描述。在逻辑设计阶段将e-r图转换成具体的数据库产品支持的数据模型如关系模型，形成数据库逻辑模式。然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图（view）形成数据的外模式。在物理设计阶段根据dbms特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。 1. 需求分析阶段 需求收集和分析，结果得到数据字典描述的数据需求（和数据流图描述的处理需求）。 需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。 需求分析的方法：调查组织机构情况、调查各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。 常用的调查方法有：跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。 分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法（structured analysis，简称sa方法）从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并把每一层用数据流图和数据字典描述。 数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典（data dictionary，简称dd）来描述。 数据字典是各类数据描述的集合，它是关于数据库中数据的描述，即元数据，而不是数据本身。数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五个部分(至少应该包含每个字段的数据类型和在每个表内的主外键)。 数据项描述＝｛数据项名，数据项含义说明，别名，数据类型，长度， 取值范围，取值含义，与其他数据项的逻辑关系｝ 数据结构描述＝｛数据结构名，含义说明，组成:｛数据项或数据结构｝｝ 数据流描述＝｛数据流名，说明，数据流来源，数据流去向， 组成:｛数据结构｝，平均流量，高峰期流量｝ 数据存储描述＝｛数据存储名，说明，编号，流入的数据流，流出的数据流， 组成:｛数据结构｝，数据量，存取方式｝ 处理过程描述＝｛处理过程名，说明，输入:｛数据流｝，输出:｛数据流｝, 处理:｛简要说明｝｝
根据建立的领域模型进行数据库表的映射，此时应参考数据库设计第二范式：一个表中的所有非关键字属性都依赖于整个关键字。应针对所有表的主键和外键建立索引，有针对性的（针对一些大数据量和常用检索方式）建立组合属性的索引，提高检索效率。 (1)不应针对整个系统进行数据库设计，而应该根据系统架构中的组件划分，针对每个组件所处理的业务进行组件单元的数据库设计；不同组件间所对应的数据库表之间的关联应尽可能减少，如果不同组件间的表需要外键关联也尽量不要创建外键关联，而只是记录关联表的一个主键，确保组件对应的表之间的独立性，为系统或表结构的重构提供可能性。 (2)采用领域模型驱动的方式和自顶向下的思路进行数据库设计，首先分析系统业务，根据职责定义对象。对象要符合封装的特性，确保与职责相关的数据项被定义在一个对象之内，这些数据项能够完整描述该职责，不会出现职责描述缺失。并且一个对象有且只有一项职责，如果一个对象要负责两个或两个以上的职责，应进行分拆。 (3)根据建立的领域模型进行数据库表的映射，此时应参考数据库设计第二范式：一个表中的所有非关键字属性都依赖于整个关键字。关键字可以是一个属性，也可以是多个属性的集合，不论那种方式，都应确保关键字能够保证唯一性。在确定关键字时，应保证关键字不会参与业务且不会出现更新异常，这时，最优解决方案为采用一个自增数值型属性或一个随机字符串作为表的关键字。 (4)由于第一点所述的领域模型驱动的方式设计数据库表结构，领域模型中的每一个对象只有一项职责，所以对象中的数据项不存在传递依赖，所以，这种思路的数据库表结构设计从一开始即满足第三范式：一个表应满足第二范式，且属性间不存在传递依赖。 (5)同样，由于对象职责的单一性以及对象之间的关系反映的是业务逻辑之间的关系，所以在领域模型中的对象存在主对象和从对象之分，从对象是从1－N或N－N的角度进一步主对象的业务逻辑，所以从对象及对象关系映射为的表及表关联关系不存在删除和插入异常。 (6)在映射后得出的数据库表结构中，应再根据第四范式进行进一步修改，确保不存在多值依赖。这时，应根据反向工程的思路反馈给领域模型。如果表结构中存在多值依赖，则证明领域模型中的对象具有至少两个以上的职责，应根据第一条进行设计修正。第四范式：一个表如果满足BCNF，不应存在多值依赖。 (7)在经过分析后确认所有的表都满足二、三、四范式的情况下，表和表之间的关联尽量采用弱关联以便于对表字段和表结构的调整和重构。并且，我认为数据库中的表是用来持久化一个对象实例在特定时间及特定条件下的状态的，只是一个存储介质，所以，表和表之间也不应用强关联来表述业务（数据间的一致性），这一职责应由系统的逻辑层来保证，这种方式也确保了系统对于不正确数据（脏数据）的兼容性。当然，从整个系统的角度来说我们还是要尽最大努力确保系统不会产生脏数据，单从另一个角度来说，脏数据的产生在一定程度上也是不可避免的，我们也要保证系统对这种情况的容错性。这是一个折中的方案。 (8)应针对所有表的主键和外键建立索引，有针对性的（针对一些大数据量和常用检索方式）建立组合属性的索引，提高检索效率。虽然建立索引会消耗部分系统资源，但比较起在检索时搜索
保密级别：□绝密□机密□秘密■内部公开 数据库设计规范
变更记录
目录 1 编写目的 (1) 2 数据库策略 (1) 2.1 数据库对象长度策略 (1) 2.2 数据完整性策略 (1) 2.3 规范化设计与性能之间的权衡策略 (1) 2.4 字段类型的定义与使用策略 (1) 3 命名规范 (3) 3.1 数据库命名规则 (3) 3.2 数据库对象命名的一般原则 (4) 3.3 表空间(Tablespace)命名规则 (4) 3.4 表(Table)命名规则 (4) 3.5 字段命名规则 (5) 3.6 视图(View)命名规则 (5) 3.7 序列(Sequence)命名规则 (5) 3.8 存储过程(Procedure)的命名规则 (5) 3.9 函数(Function)的命名规则 (5) 3.10 索引(Index) 命名规范 (5) 3.11 约束(Constraint) 命名规范 (5) 4 数据模型产出物规范 (5) 附录A：xml文件使用说明 (7) 附录B：保留关键字 (8)
可编辑 1编写目的 本文的目的是提出针对Oracle数据库的设计规范，使利用Oracle数据库进行设计开发的系统严格遵守本规范的相关约定，建立统一规范、稳定、优化的数据模型。 参照以下原则进行数据库设计： 1)方便业务功能实现、业务功能扩展； 2)方便设计开发、增强系统的稳定性和可维护性； 3)保证数据完整性和准确性； 4)提高数据存储效率，在满足业务需求的前提下，使时间开销和空间开销达到优化平衡。 2数据库策略 1)数据模型全局单一，所有公共的数据模型得到共享。 2)数据库建模要基于统一的元数据管理机制。 3)数据库设计遵循关系数据库的规范化理论。 4)OLTP与OLAP分开设计。 2.1数据库对象长度策略 数据库字段的长度要考虑业务对象的类型、数据库所用字符集、时间格式来设定出相对准确的长度，满足业务需要，同时保证数据库的高效，避免不必要的开销。 2.2数据完整性策略 1)必须遵循数据库设计的第二范式，根据业务需要尽量满足第三范式。 2)数据完整性尽量通过业务逻辑实现，数据库设计应尽量避免使用大量的外键约束，避免使用触发 器。 2.3规范化设计与性能之间的权衡策略 数据的标准化有助于消除数据库中的数据冗余。如果数据冗余低，数据的一致性容易得到保证，如无特殊理由，OLTP系统的设计应当遵循第三范式，对于OLAP系统，为了减少表间连接查询的操作，提高系统的响应时间，合理的数据冗余是必要的。 2.4字段类型的定义与使用策略 1)数据类型的选用原则 精品
数据库设计和编码规范 Version 1.0
目录 1简介 .................................................................................................. 1.1读者对象 ............................................................................................................................ 1.2目的.................................................................................................................................... 2数据库命名规范 .............................................................................. 2.1规范总体要求 .................................................................................................................... 2.2数据库对象命名规范 ........................................................................................................ 2.3变量命名规范 .................................................................................................................... 3数据库设计规范 .............................................................................. 3.1选择有效的设计工具 ........................................................................................................ 3.2表的设计 ............................................................................................................................ 3.2.1遵守范式要求 .................................................................................................... 3.2.2字段设计 ............................................................................................................ 3.2.3适当的合理的冗余 ............................................................................................ 3.2.4注意大类型的字段设计 .................................................................................... 3.3表关系和约束设计 ............................................................................................................ 3.3.1主键设计 ............................................................................................................ 3.3.2 外键设计 .................................................................................................................. 3.3.3 检查约束 .................................................................................................................. 3.4索引的设计 ........................................................................................................................ 3.4.1聚集索引和非聚集索引 .................................................................................... 3.4.2索引的初始创建原则 ........................................................................................ 3.4.3索引的注意事项 ................................................................................................ 3.4.4索引的后期维护工作 ........................................................................................ 3.5物理存储设计 .................................................................................................................... 3.5.1日志文件另外存放 ............................................................................................ 3.5.2存储空间的设计 ................................................................................................ 4T-SQL编码规范 ............................................................................. 4.1书写基本规范 .................................................................................................................... 4.2使用可搜索参数（WHERE使用原则）............................................................................ 4.3少用触发器和禁用游标 .................................................................................................... 4.4联合查询尽可能使用UNION ALL.................................................................................. 4.5尽可能避免的地方 ............................................................................................................ 4.6避免返回和使用多余的数据 ............................................................................................ 4.7操作符优化 ........................................................................................................................ 4.8数据库事务处理原则 ........................................................................................................ 4.9最少次数的访问表 ............................................................................................................ 4.10避免隐含的数据类型转换 ........................................................................................
一、数据库设计过程 数据库技术是信息资源管理最有效的手段。数据库设计是指对于一个给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,有效存储数据,满足用户信息要求和处理要求。 数据库设计中需求分析阶段综合各个用户的应用需求(现实世界的需求,在概念设计阶段形成独立于机器特点、独立于各个DBMS产品的概念模式(信息世界模型,用E-R图来描述。在逻辑设计阶段将E-R图转换成具体的数据库产品支持的数据模型如关系模型,形成数据库逻辑模式。然后根据用户处理的要求,安全性的考虑,在基本表的基础上再建立必要的视图(VIEW形成数据的外模式。在物理设计阶段根据DBMS特点和处理的需要,进行物理存储安排,设计索引,形成数据库内模式。 1.需求分析阶段 需求收集和分析,结果得到数据字典描述的数据需求(和数据流图描述的处理需求。需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。 需求分析的方法:调查组织机构情况、调查各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。 常用的调查方法有:跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。 分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法(Structured Analysis,简称SA方法从最上层的系统组织机构入手,采用逐层分解的方式分析系统,并把每一层用数据流图和数据字典描述。 数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典 (Data Dictionary,简称DD来描述。
数据字典是各类数据描述的集合,它是关于数据库中数据的描述,即元数据,而不是数据本身。数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五个部分(至少应该包含每个字段的数据类型和在每个表内的主外键。 数据项描述={数据项名,数据项含义说明,别名,数据类型,长度, 取值范围,取值含义,与其他数据项的逻辑关系} 数据结构描述={数据结构名,含义说明,组成:{数据项或数据结构}} 数据流描述={数据流名,说明,数据流来源,数据流去向, 组成:{数据结构},平均流量,高峰期流量} 数据存储描述={数据存储名,说明,编号,流入的数据流,流出的数据流, 组成:{数据结构},数据量,存取方式} 处理过程描述={处理过程名,说明,输入:{数据流},输出:{数据流}, 处理:{简要说明}} 2.概念结构设计阶段 通过对用户需求进行综合、归纳与抽象,形成一个独立于具体DBMS的概念模型,可以用E-R图表示。 概念模型用于信息世界的建模。概念模型不依赖于某一个DBMS支持的数据模型。概念模型可以转换为计算机上某一DBMS支持的特定数据模型。 概念模型特点: (1具有较强的语义表达能力,能够方便、直接地表达应用中的各种语义知识。