一、数据库命名规范
1. 实体（表）的命名
1) 表以名词或名词短语命名，确定表名是采用复数还是单数形式，此外给表的别名定义简单规则（比方说，如果表名是一个单词，别名就取单词的前4 个字母；如 果表名是两个单词，就各取两个单词的前两个字母组成4 个字母长的别名；如果表的名字由3 个单词组成，从头两个单词中各取一个然后从最后一个单词中再取 出两个字母，结果还是组成4 字母长的别名，其余依次类推）
对工作用表来说，表名可以加上前缀WORK_ 后面附上采用该表的应用程序的名字。在命名过程当中，根据语义拼凑缩写即可。注意，由于ORCLE会将字段名称统一成大写或者小写中的一种，所以要求加上下划线。
举例：
定义的缩写 Sales: Sal 销售；
Order: Ord 订单；
Detail: Dtl 明细；
则销售订单明细表命名为：Sal_Ord_Dtl;
2) 如果表或者是字段的名称仅有一个单词，那么建议不使用缩写，而是用完整的单词。
举例：
定义的缩写 Material Ma 物品；
物品表名为：Material, 而不是 Ma.
但是字段物品编码则是：Ma_ID;而不是Material_ID
3) 所有的存储值列表的表前面加上前缀Z
目的是将这些值列表类排序在数据库最后。
4) 所有的冗余类的命名(主要是累计表)前面加上前缀X
冗余类是为了提高数据库效率，非规范化数据库的时候加入的字段或者表
5) 关联类通过用下划线连接两个基本类之后，再加前缀R的方式命名,后面按照字母顺序罗列两个表名或者表名的缩写。
关联表用于保存多对多关系。
如果被关联的表名大于10个字母，必须将原来的表名的进行缩写。如果没有其他原因，建议都使用缩写。
举例：表Object与自身存在多对多的关系,则保存多对多关系的表命名为：R_Object；
表 Depart和Employee;存在多对多的关系；则关联表命名为R_Dept_Emp
2. 属性（列）的命名
1) 采用有意义的列名，表内的列要针对键采用一整套
数据库设计规则。每一个表都将有一个自动ID作为主健,逻辑上的主健作为第一组候选主健来定义,如果是数据库自 动生成的编码，统一命名为：ID;如果是自定义的逻辑上的编码则用缩写加“ID”的方法命名。如果键是数字类型，你可以用_NO 作为后缀；如果是字符类 型则可以采用_CODE 后缀。对列名应该采用标准的前缀和后缀。
举例：销售订单的编号字段命名：Sal_Ord_ID；如果还存在一个数据库生成的自动编号，则命名为：ID。
2) 所有的属性加上有关类型的后缀，注意，如果还需要其它的后缀，都放在类型后缀之前。
注: 数据类型是文本的字段，类型后缀TX可以不写。有些类型比较明显的字段，可以不写类型后缀。
3) 采用前缀命名
给每个表的列名都采用统一的前缀，那么在编写SQL表达式的时候会得到大大的简化。这样做也确实有缺点，比如破坏了自动表连接工具的作用，后者把公共列名同某些数据库联系起来。
3. 视图的命名
1) 视图以V作为前缀，其他命名规则和表的命名类似；
2) 命名应尽量体现各视图的功能。
4. 触发器的命名
触发器以TR作为前缀，触发器名为相应的表名加上后缀，Insert触发器加 _I ，Delete触发器加 _D ，Update触发器加 _U ，如：TR_Customer_I，TR_Customer_D，TR_Customer_U。
5. 存储过程名
存储过程应以 UP_ 开头，和系统的存储过程区分，后续部分主要以动宾形式构成，并用下划线分割各个组成部分。如增加代理商的帐户的存储过程为 UP_Ins_Agent_Account 。
6. 变量名
变量名采用小写，若属于词组形式，用下划线分隔每个单词，如@my_err_no。
7. 命名中其他注意事项
1) 以上命名都不得超过30个字符的系统限制。变量名的长度限制为29（不包括标识字符@）。
2) 数据对象、变量的命名都采用英文字符，禁止使用中文命名。绝对不要在对象名的字符之间留空格。
3) 小心保留词，要保证你的字段名没有和保留词、数据库系统或者常用访问方法冲突
4) 保持字段名和类型的一致性，在命名字段并为其指定数据类型的时候一定要保证一致性。假如数据类型在一个表里是整数，那在另一个表里可就别变成字符型了。
随着计算机技术越来越广泛地应用于国民经济的各个领域，在计算机硬件不断微型化的同时，应用系统向着复杂化、大型化的方向发展。数据库是整个系统的核心，它的设计直接关系系统执行的效率和系统的稳定性。因此在软件系统
开发中，数据库设计应遵循必要的数据库范式理论，以减少冗余、保证数据的完整性与正确性。只有在合适的数据库产品上设计出合理的数据库模型，才能降低整个系统的编程和维护难度，提高系统的实际运行效率。虽然对于小项目或中等规模的项目开发人员可以很容易地利用范式理论设计出一套符合要求的数据库，但对于一个包含大型数据库的软件项目，就必须有一套完整的设计原则与技巧。
二、数据建模步
分析需求，画出用例图；编写用例文本，设计界面原型，模拟功能性场景；找实体；识别实体的属性；识别实体之间的关系（一对一，一对多，多对多）；画出概念数据模型(ER图)； 将概念数据模型转化为物理数据模型(表格)；根据范式修改物理数据模型继续重复5
三、对象建模步凑
分析需求，画出用例图；编写用例文本，设计界面原型，模拟功能性场景；找出业务模型（领域对象）；找关键性的名词和动词，识别类的属性和职责；识别业务模型之间的关系（关联，依赖，组合，聚合，泛化，实现）；将业务模型转化为概念数据模型，重复数据建模的ER中的实体和OO中的领域对象的区别：
1. domain model抽象层次更高，更加贴近于现实世界和业务，而实体贴近于数据库
2. 一个实体必然对应一张表，而domain mode则可能是虚拟的只存在于业务层（如购物车）而不需要持久化到数据库，或者一个domain model由多张表的数据共同组合而成
3. 当业务复杂时，使用domain model描述需求效果更好，但是相应的在domain model和数据库表之间的映射会变得十分复杂，匹配程度很低
4. 以数据库为出发点进行数据建模，很容易上手（即界面上要显示的数据都来自于数据库的某张表格），但是业务复杂后正确的设计需要丰富的经验。以OO为出发点进行建模，不论业务复杂与否，很容易抽象出大致的domain model，但是当业务复杂后在做domain model和数据库表之间的映射则会变得非常困难
大致来说理论上咱们发起OO，发起DDD，但是因为客观条件（全部国内软件环境，中小公司急于求成的心态，不重视扩展性和保护性，主管人员 设计人员思维陈旧，项目周期 本钱约束）以及片面条件（
程序员本身的本质 对OO的理解）的约束，因而很多情况下依然运用DB建模或许打着DDD的幌子走DB的老路。不论如何，如今DDD的思维已经遍地开花，总的趋势是逐步向OO，向DDD上挨近。因而，处于这样的一个过度期间，既不能彻底地以DB为中间设计，也不能彻底地OO，而是应当联系2者，（相似中国特色的社会主义道路）取长补短。
一品威客网汇聚了数百万专业的
综合性网站、
资讯型网站、
团购网站、
电子商务网站、
宣传展示型网站、
手机WAP网站、
程序功能开发、
数据库设计、
接口开发、
服务器系统等优秀威客人才，只要您在网站发布任务需求，就能够吸引众多威客给您献上最好的创意服务。
推荐更多与“如何实现数据库设计规范化?_mysql数据库设计学习部分内容”相关推荐：
java网站开发 | 外贸网站建设 | vs2010网站开发 | 手机wap网站开发 | 企业制作wap网站
网站开发流程 | 团购网站开发 | 数据库设计方法 | 商城jsp网站开发 | wap网站开发教程
手机网站制作 | 网站开发框架 | 微信3g网站开发 | 数据库设计注意点| 数据库设计原则
请求处理中...
企业QQ
智能客服
