数据库规范化设计理论摘要

对于一个大项目来讲，数据库的设计命名规范是很重要的一个环节，好的表设计，让人看得很舒服，一看就明白是什么意思了，下面看到一篇很不错的数据库对象命名参考文档，所以整理分享给大家。
引言
编码规范是一个优秀程序员的必备素质，然而，有很多人非常注重程序中变量、方法、类的命名，却忽视了同样重要的数据库对象命名。这篇文章结合许多技术文章和资料，以及我自己的开发经验，对数据库对象的命名规则提出了一点建议，希望能为大家提供一些参考。
NOTE：虽然这篇文章名为“数据库对象命名参考”，实际上，在这篇文章中我不仅介绍了数据库命名的规则，连带讲述了在数据库设计与开发时所需要注意的几个问题。
基本命名规则
表1. 基本数据库对象命名
数据库对象 前缀 举例
表(Table)

字段(Column)

视图(View)

存储过程(Stored procedure)

触发器(Trigger)

索引(Index)

主键(Primary key)

外键(Foreign key)

Check约束(Check Constraint)

Unique约束
用户定义数据类型(User-defined data type)

用户定义函数(User-defined function) 无
无
v

pr

tr

ix_

pk_

fk_

ck_

uq_

udt

fn Student

Title

vActivity

prDelOrder

trOrder_D

ix_CustomerID

pk_Admin

fk_Order_OrderType

ck_TableColumn

uq_TableColumn

udtPhone

fnDueDate

 

关于命名的约定
变量(T-SQL编程中声明的变量)、过程(存储过程或触发器等)、实体(表、字段)应该根据他们所代表的实体意义和进程作用来命名：
表2.好的命名 和 不好的命名 范例
好的命名 不好的命名
@CurrentDate

@ActivityCount

@EquipmentType

prCalculateTotalPrice @D

@ActNum

@ET

@prRunCalc

 

还有一个常见的错误就是只使用面向计算机的术语，而不是面向公司业务的术语，比如ProcessRecord就是一个含糊不清的命名，应该使用一个进程业务描述来替换它，比如CompleteOrder.

如果完全根据上一条的要求，那么根据业务描述的过程名可能会变得很冗长，比如下面：
prCountTotalAmountOfMonthlyPayments (计算每月付费的总金额)

prGetParentOrganizationalUnitName (获取上级单位名称)

此时则应该考虑使用缩写：
如果可以在字典里找到一个词的缩写，就用这个做为缩写，比如：Mon(Monday)、Dec(December)

可以删除单词元音(词首字母除外)和每个单词的重复字母来缩写一个单词。比如：Current = Crnt、Address = Adr、Error = Err、Average = Avg

不要使用有歧异的缩写(一般是语音上的歧义)。比如b4(before)、xqt(execute)，4tran(Fortran)

表格、字段的命名：
单数表名、字段名 还是 复数表名、字段名？
可能大家很少会考虑到给表名起单数还是复数，比如，对存储客人信息的表，我们应该起Customer，还是Customers？我主张起单数表名，下面是来自《SQL Server 2000 宝典》的一段引用：
主张用复数表名的阵营认为：表是由一组记录构成的，所以应当使用复数名词来命名它。他们经常使用的理由是：客户表是客户们的集合，而集合意味着多个，因此应当称他们为Customers表。除非你只有一个客户，但这种情况你根本用不着数据库。
根据笔者的非正式调查，有3/4的SQL Server开发人员支持使用单数命名。这些开发人员认为，客户表是客户的集合，而不是客户们的集合。一组行不应当也不会被成为rows set(行们的集合)，而会被称为row set(行集)。并且，通常在讨论时人们会使用单数名称来称呼表，说Customer表比说Customers表听起来更为清晰。
避免无谓的表格后缀
这两点我想大家都知道：1、表是用来存储数据信息的。2、表是行的集合。那么如果表名已经能够很好地说明其包含的数据信息，就不需要再添加体现上面两点的后缀了。
实际工作中，我看到有的同事对表这样命名：GuestInfo，用于存储客户信息。这个命名与上面所说的第1点重复，谁都知道表本来就是存储信息(information)的，再加个Info无异于画蛇添足，个人认为直接用Guest做表名就可以了。
对于存储航班信息的表，他又命名为FlightList。这个命名又与之前说的第2点相重复，表是行的集合，那么自然是列表(List)，加上List后缀显得很多余，命名为 Flight 不是很好么？可见，他给自己都没有订立一个明确的命名规则，不然这两个表一定是要么命名为：GuestList、FlightList 要么命名为 GuestInfo、FlightInfo，而不会是两者的混合。
多对多关系中连接表的命名
大家知道，如果要实现两个实体间的多对多关系，需要三张表，其中一张是解析表。考虑下面这样一个多对多关系，这是一个经典的学生选课问题：一个学生可以选很多门课，一门课可以有很多学生。此时为了实现上面的关系，就需要一张解析表(这张表只存储学生ID和课程ID，而学生的信息和课程信息分别存在各自的表中)，这个表的起名，建议的写法是将两个表的表名合并(如果表名比较长可做简化)，此处如 StudentCourse。这个表中字段分别命名为StudentId、CourseID(既是此表的复合主键，同时分别为连接Student表和Course表的外键，等下到主键和外键的命名处再说)，这样就实现了学生和课程之间的多对多关系，当然，这个关系还可以加点额外的东西，比如给StudentCourse表中加AccessLevel字段，值域D{只读,完全,禁止}，就可以实现访问级别。
约定俗成的字段名前/后缀
数据库开发的时间久了，慢慢就会摸索出一个规律来：就是很多的字段都有些共同的特性。比如说，有的字段是代表时间的(例如发帖时间，评论时间)，有的是代表数量的(例如浏览数，评论数)，有的是代表真假类型的(例如是否将博客随笔显示在首页)。对于这种同一类型的字段，应该使用统一的 前缀 或者 后缀去标识它。
我们来举几个例子看得更明白一点。
以大家都熟悉的论坛来说，需要记录会员最后一次登录的时间，这时候一般人都会把这个字段命名为LoginTime 或者 LoginDate。这时候，已经产生了一个歧义：对于另一名开发者来说，如果仅看表的字段名称，不去看表的内容，很容易将LoginTime理解成 登录的次数，因为，Time还有一个很常用的意思，就是次数。
为了避免这种情况发生，应该明确的规定：所有表示时间的字段，统一以 Date 来作为结尾。
我们经常需要统计发帖数、回帖数信息，这时候，开发人员通常会这样去命名字段：PostAmount、PostTime、PostCount，同样，由于Time的歧义，我们首先排除掉不使用PostTime作为字段名。接下来，Amount 和 Count 都可以表示计数的意思，用哪个合适呢？这里，我推荐使用Count。为什么呢？如果你做过Asp开发，相信一定知道 RecordCount 这个属性，命名的时候有一个原则：就是使用约定俗成的名称，而不要去自创名称。既然微软都用Count后缀来表示数目，我们为什么不呢？
于是，所有表示数目的字段，都应该以Count作为结尾。将这一概念做以推广，很容易得出，浏览次数为 ViewCount，登录次数为LoginCount 等等。
再举一个例子，我们很少在数据库里直接保存图片等二进制数据，通常是仅保存图片的URL路径；在文章管理系统中，如果是转载文章，也会用到记录文章出处的字段。个人建议所有代表链接的字段，均为Url结尾。于是，图片路径的字段命名为 ImageUrl，文章出处字段的命名为SourceUrl。
最后一个例子，我们经常需要用到布尔值，比方说，这篇随笔要不要显示到首页，这篇随笔是不是保存到草稿箱等等。同样，按照微软的建议，布尔类型的值均以 Is、Has 或者 Can开头。
如果让我来建表示是否将随笔放到首页的字段，它的名字一定是这样的：IsOnIndex

类似的例子是很多的，我在这里仅举出典型的几个范例，大家可以自行拓展，如果我能起到一个抛砖引玉的作用就很满足了。
字段命名时需注意的一个问题
我发现有很多开发人员喜欢给字段加上表名作为它的前缀，举个例子，如果有个表叫User，那么他就会将这个表中的字段命名为：UserId、UserPassword、UserName、UserPhone　等等。个人认为，这是没有必要的，因为你已经确切的知道了这个表存储的是User的信息，那么其中的字段必然是针对于User的。而且，在Join连接操作中，你的SQL代码看上去也会更加的精简一些，诸如　[User].UserName = Aritcle.ArticleAuthor 这样的代码完全可以实现为　[User].Name = Article.Author。
这里还存在一个特例，就是表的外键包含的字段。在这种情况下，我倾向于使用表名+ID　的方式，比如　CategoryId 、UserId 等。假设有表Article，那么它的主键我会命名为Id，关联用户表User的外键包含的字段，我会命名为UserId。之所以这样，是因为在语言(比如C#)中创建对象时，有时候会使用代码生成器(根据数据库的字段名生成对象的字段、属性名)，此时生成的代码更规整一些。
 

 

文章来自学IT网：http://www.xueit.com/Mssql/show-5196-1.aspx

SQL数据库设计规范参考之数据库对象命名详细文档
时间:2009-12-16 13:23:29 来源:www.cnblogs.com 作者:

-

 

建表时需要注意的问题
数据库不仅是用来保存数据，还应负责维护数据的完整性和一致性
我看过很多的开发人员设计出来的数据库，给我的感觉就是：在他们眼里，数据库的作用就如同它的名称一样――仅仅是用来存放数据的，除了不得不建的主键以外，什么都没有...没有 Check约束，没有索引，没有外键约束，没有视图，甚至没有存储过程。
在这里，我提出如下数据库设计的建议：
如果要写代码来确保表中的行都是唯一的，就为表添加一个主键。
如果要写代码来确保表中的一个单独的列是唯一的，就为表添加一个约束。
如果要写代码确定表中的列的取值只能属于某个范围，就添加一个Check约束。
如果要写代码来连接 父－子 表，就创建一个关系。
如果要写代码来维护“一旦父表中的一行发生变化，连带变更子表中的相关行”，就启用级联删除和更新。
如果要调用大量的Join来进行一个查询，就创建一个视图。
如果要逐条的写数据库操作的语句来完成一个业务规则，就使用存储过程。
NOTE：这里我没有提到触发器，实践证明触发器会使数据库迅速变得过于复杂，更重要的是触发器难以调试，如果不小心建了个连环触发器，就更让人头疼了，所以我更倾向于根本就不使用触发器。
以Not Null的思路建表
我发现很多开发人员在建表的时候，如果要新建一个字段，他的思路是这样的：默认这个字段是可以为Null的，然后去判断是不是非要Not Null不可，如果不是这样，OK，这个字段可以为Null，接着继续进行下一个字段。结果往往是一张表除了主键以外所有的字段都可以为Null。
之所以会有这样的思路，是因为Null好啊，程序不容易出错啊，你插入记录的时候如果不小心忘输了一个字段，程序依然可以Run，而不会出现 “XX字段不能为Null”的错误消息。
但是，这样做的结果却是很严重的，也会使你的程序变得更加繁琐，你不得不进行一些无谓的空值处理，以避免程序出错。更糟的是，如果一些重要数据，比如说订单的某一项值为Null了，那么大家知道，任何值与Null相操作(比如加减乘除)，结果都是Null，导致的结果就是订单的总金额也为Null。
你可以运行下面的代码尝试一下：
Select Null + 5 As Result

你可能会说，就算我将字段设置成Not Null，但是它依然可以接受空字符串，这样一来在程序中还是要进行空值处理。请别忘了，数据库还赋予你一个强力武器，就是 Check 约束，当你需要确保一个字段既不可以为Null，又不可以为空的时候，可以这么写：
ColumnName    Varchar(50)       Not Null Constraint ck_ColumnName Check(Len(ColumnName) > 0)

所以，合理的思维方式应该是这样的：默认这个字段是 Not Null的，然后判断这个字段是不是非为Null不可，如果不是这样，OK，这个字段是Not Null的，进行下一个字段。
一个建表的范例脚本
我正在建立我自己的个人空间，其中的文章表是这样写的：
Create Table Article

(

    Id            Int Identity(1,1) Not Null,

    Title         Varchar(50)       Not Null Constraint uq_ArticleTitle Unique,

    Keywords      Varchar(50)       Not Null,

    Abstract      Varchar(500)      Not Null,

    Author        Varchar(50)       Not Null Default '张子阳',

    Type          TinyInt           Not Null Default 0 Constraint ck_ArticleType Check(Type in (0,1,2)),  -- 0,原创；1,编译；2,翻译
    IsOnIndex     Bit               Not Null Default 1,   -- 是否显示在首页
    Content       Text              Not Null,

    SourceCode    Varchar(100)      Null,  -- 程序源码的下载路径
    Source        Varchar(50)       Not Null Default 'TraceFact',   -- 文章出处
    SrcUrl        Varchar(150)      Null,  -- 文章出处的URL

    PostDate      DateTime          Not Null Default GetDate(),

    ViewCount     Int               Not Null Default 0,

    ClassId       Int               Not Null   -- 外键包含的字段，文章类别
 

    Constraint pk_Article Primary Key(Id)   -- 建立主键
)

可以看到，在这里我使用了 Check 约束，以确保文章类型只能为 0,1,2。这里，我想说的是Check 约束的命名规则：尽管Check约束是针对字段的，但在同一数据库中，却不能有同名的Check约束。所以，建议使用 ck_ + 表名 + 字段名 来命名它，比如这个范例脚本中的 ck_ArticleType。
除此以外，我还使用了Unique约束，以确保文章标题的唯一性。由于这是我的博客文章表，不应该出现重复的题目，这样可以避免在使用 Insert 语句时插入重复值。类似于Check约束，这里的命名规则是：uq_ + 表名 + 字段名。
主键的命名
按照SQL Server 的默认规范(使用企业管理器创建主键时默认产生的主键名)，主键的命名为 pk_TableName。主键是针对一个表的，而不是针对一个字段的，大家有时候在企业管理器中会见到一个表的两个字段前面都会有钥匙的图标(比如SQL Server 2000自带的NorthWind范例数据库的EmployeeTerritories表)，就会误以为主键是针对字段的，即是说一个表上有两个主键，其实错了，只有一个主键，但包含了两个字段，这就是常说的复合主键。为了有个更生动的认识，看下建立复合主键的SQL语句，以上面说到的多对多连接表StudentCourse为例：
Alter Table StudentCourse

Add Constraint pk_StudentCourse Primary key(StudentId, CourseId)

可见，对于主键pk_StudentCourse，包含了两个字段StudentId 和 CourseId。
外键的命名
外键的命名为 fk_外键所在的表名_外键引用的表名。因为外键所在的表为从表，所以上式可以写为 fk_从表名_主表名。
外键包含的字段的命名，外键包含的字段和外键是完全不同的概念。外键包含字段的命名，建议为：外键所在的表名 + Id。
考虑这样一个关系，表Hotel，字段Id, Name, CityId。表City,字段Id,Name。因为一个城市可能有好多家酒店，所以是一个一对多的关系，City是主表(1方)，Hotel是从表(多方)。在Hotel表中，CityId是做为外键使用。
在实现外键的时候我们可以这样写：
Alter Table HotelInfo

Add Constraint fk_HotelInfo_City Foreign Key (CityID) References City(ID)

On Delete No Action On update No Action

很明显，fk_HotelInfo_City是外键的名字，CityId是外键包含的字段的名字。
NOTE：在创建数据库表的时候，一般需要写成三个SQL脚本文件。第一个文件仅包含所有的创建表的SQL语句，即Create Table 语句。第二个文件包含删除关系和表的语句，其中，所有删除关系的语句，即Drop Constraint 语句集中在这个文件的上半部分，所有删除表的语句，Drop Table语句，集中在这个文件的下半部分。第三个文件包含建立表之间关系的语句。这种做法会在你移植数据库的时候产生较大的便利，原因我就不解释了，您一试便知。
而对于多对多关系中解析表的外键包含的字段，顺理往下推，我们可以这样写(再次回到学生选课的多对多例子中)：
建立解析表StudentCourse与Student表的外键关系：
Alter Table StudentCourse

Add Constraint fk_StudentCourse_Student Foreign Key (StudentId) References Student (Id)

On Delete No Action On Update No Action

建立解析表StudentCourse与Course 表的外键关系:

Alter Table StudentCourse

Add Constraint fk_StudentCourse_Course Foreign Key (CourseId) References Course(Id)

On Delete No Action On Update No Action

触发器的命名
由三部分构成：
前缀(tr),描述了数据库对象的类型。
基本部分，描述触发器所加的表。
后缀(_I、_U、_D)，显示了修改语句(Insert, Update及Delete)

存储过程的命名
大家知道，系统存储过程的前缀是 sp_，为了避免将用户存储过程与系统存储过程混淆，这里我推荐大家使用 pr 作为自己定义的存储过程的命名。
同时，命名的规则是：采用自解释型的命名，比如：prGetItemById。
这里，有个有意思的地方值得深思。我们按上面规则命名存储过程的时候，可以用两种方式：
动词放前面，名词放后面。
名词放前面，动词放后面。
我个人推荐使用方式2，现在说说原因：
以NorthWind 为例，假如对于 Employees 表你有4个存储过程，分别命名为：prEmployeeInsert、prEmployeeUpdate、prEmployeeDelById、prEmployeeGetById

同时对于 Products 表你有类似的4个存储过程，分别命名为：prProductInsert、prProductUpdate、prProductDelById、prProductGetById

这时，你用企业管理器查看时，会发现存储过程像下面这样整整齐齐的排列：
prEmployeeDelById

prEmployeeGetById

prEmployeeInsert

prEmployeeUpdate

prProductDelById

prProductGetById

prProductInsert

prProductUpdate

很容易就会发现，当你的存储过程越多时，这种命名方法的优势就越明显。
存储过程中参数的命名
存储过程中的入口参数，我建议与其对应的字段名相同，这里，假设要写一个更新Northwind数据库Employees表的存储过程(做了简化)，可以这么写：
Create Procedure prEmployeeUpdateById

    @EmployeeId       Int,

    @LastName     NVarchar(20),

    @FirstName    NVarchar(10)

As

    Update Employees Set

       LastName = @LastName,

       FirstName = @FirstName

    Where

       EmployeeId = @EmployeeId

 

    If @@error <> 0 or @@RowCount = 0

       Raiserror 16001 ‘更新用户失败’
总结
在这篇文章中，我首先提出了开发人员对数据库对象命名不够重视的问题，随后列出了一张数据对象命名的简表。
接着我按照 表、字段、主键、外键、触发器、存储过程的顺序，详细讲述了数据库对象命名的规则。
其间，我还穿插着讲述了在数据库开发中常见的一些问题，包括建表时需要注意的问题，以及在管理存储过程时可以采取的技巧。
 

 

文章来自学IT网：http://www.xueit.com/Mssql/show-5196-2.aspx

数据库设计规范（命名规范）时间:2009-12-15 11:21:16来源:网络 作者:未知 点击:101次 1 目的
规范数据库设计。
2 概述
从数据库的设计原则 设计文档几方面论述数据库设计的规范思想及命名规则。
3 数据库应用结构
根据对一般业务系统的分析，将数据库和程序系统统一进行整体描述，展示数据库的表之间以及与
1 目的
规范数据库设计。
2 概述
从数据库的设计原则 设计文档几方面论述数据库设计的规范思想及命名规则。
3 数据库应用结构
根据对一般业务系统的分析，将数据库和程序系统统一进行整体描述，展示数据库的表之间以及与程序模块间的关系。
3.1 数据表和程序模块的分类
根据“处理特点”，将数据表和程序模块进行分类如下：
数据表分类：业务数据表、基本编码表、辅助编码表、系统信息表、累计数据表、结算数据表、决策数据表。
程序模块分类：初始化、业务处理、完整性检测与修正、结算处理、统计处理。
3.1.1 数据表分类说明
业务数据表：记录业务发生的过程和结果。如，合同、出仓单、申请单、凭证。
基本编码表：描述业务实体的基本信息和编码。如，产品、客户、供应商、雇员。
辅助编码表：描述属性的列表值。如，合同类型、职称、民族、付款方式。
系统信息表：存放与系统操作、业务控制有关的参数。如，用户信息、权限、用户配置信息、成本核算方式。
累计数据表：存放业务的当前值和累计值。如，当前库存、当前存款、累计销售、累计支出、应收账款。
结算数据表：存放各个时期末的结存数。如，月末库存、月末银行存款、应收账款月结。
决策数据表：存放各个时期内发生的统计值。如，月销售统计、月回款统计、出入库统计。
3.1.2 程序模块分类说明
初始化：系统运行前对系统进行数据的初始化。如，库存初始化。
业务处理：业务过程的控制和结果记录。如，合同录入、费用审批、出入库。
完整性检测与修正：对累计数据表进行检查并自动修正。如对当前库存、当前存款、累计销售的检查和重新计算。
结算处理：计算并记录各个时期末的结存数。库存月结、应收账款月结。
统计处理：计算并记录各个时期内发生的统计数。如，统计月销售、统计月回款、统计出入库。
3.2 数据表间的关系
业务数据表<-->基本编码表 主-外键关系。如，合同表<-->客户编码表;

业务数据表<-->辅助编码表 主-外键关系。如，合同表<-->付款方式;

业务数据表、累计数据表、结算数据表：累计数据表=结算数据表(上期末) + 业务数
 

据表(本期内发生)。如当前库存=上月末库存数+(本月入库数-本月出库数);

决策数据表<-->业务数据表 决策数据表的数据是由业务数据表中数据导出(统计)的；
3.3 数据表与程序模块间的关系
由一个例子(仓库管理)来说明数据表与程序模块之间的关系：
. 系统使用前，由初始化模块对库存数(累计数据表)和上月末库存数(结存数据表)进行初始化；. 当有入库业务发生时，由入库模块(业务处理)将入库单录入并保存到入库单明细帐( 业务数据表)中，同时将入库数累加到库存数(累计数据表)中；. 定期或不定期，库存数核算模块(检查完整性检测与修正)根据上月末的库存数(结存数据表)、本月已发生数(业务数据表)检查当前的库存数(累计数据表)是否符合，不符合则给出提示，可手工或自动进行更正(当前库存数=上月末库存数+本月入库数-本月出库数)； . 每月初，进行上月的月结处理。月结模块(结算处理)根据上月初的库存数(结存数据表)、上月发生数(业务数据表)计算出上月末的库存数(累计数据表)。公式为：上月末库存数=上月初库存数+上月入库数-上月出库数；. 每个月月结后，库存业务月统计模块(统计处理)统计上月的各种库存商品的入库和出库数，便于查询和生成报表，也作为决策支持的数据基础。
3.4 数据表命名时对数据表分类的考虑
. 业务数据表：t_d_<系统标识>_<表标识>。如销售系统的合同表 t_d_SH_Contract或 t_d_SH_合同； . 基本编码表：t_b_[<系统标识>]_<表标识>。如客户编码表t_b_Customer 或 t_b_客户； . 辅助编码表：t_a_[<系统标识>]_<表标识>。如合同类别t_a_ContType 或 t_a_合同类别； . 系统信息表：t_s_[<系统标识>]_<表标识>。如用户表t_s_User 或 t_s_用户；. 累计数据表：t_t_<系统标识>_<表标识>。如当前库存表t_t_SO_Stock 或 t_t_SO_库存； . 结算数据表：t_c_<系统标识>_<表标识>。如库存月结表t_c_SO_StockMonth 或t_c_SO_库存月结； . 决策数据表：t_w_<系统标识>_<表标识>。如月销售统计表t_w_SH_SellMonth 或t_w_SH_月销售统计； 注：[]内的内容表示可选。如“t_s_[<系统标识>]_<表标识>”表示t_s_SH_User 和t_s_User 都是符合规则的。
4 数据库结构原则
规定除数据库设计所遵循的范式外的一些适用原则，在遵循数据库设计范式的基础上，合理地划分表，添加状态和控制字段等。
4.1 辅助编码表
为了使辅助编码表能起到预期的效能，又不因过多的辅助编码表难以管理，故对辅助编码表的使用作如下规定：
1. 当某辅助编码表的编码允许用户添加时，应设计成“独立”的数据表；否则，将不允许用户添加编码的各辅助编码表合并成一个“通用”的辅助编码表。
2. “独立”的辅助编码表与主表的列采用主-外约束保证列数据完整性。
3. “通用”的辅助编码表与各主表间没有约束关系，主表列的数据完整性由列说明的“域”来保证。
4. “通用”的辅助编码表除编码和名称列外，还有一个标识列，用来标识合并前的各码表，该标识列+编码列作为该表的主键。
5. 对于“独立”的辅助编码表，用户只可添加新的编码和改变名称，并且不能改变一个编码所代表的意义；对于“通用”的辅助编码表，原则上不允许用户修改，或只有限地允许修改名称。
4.2 基本编码表
1. 基本编码表可以有如下的标识列：内编码、外编码、助记码、简称、全称。内编码（唯一编码）作为主键有程序自动生成，用户不可见；外编码（唯一编码）由用户按某种规则自行定义，用户可见；助记码为拼音缩，方便录入，不唯一，重码时由列表选择；简称用于列表显示和报表，以便缩短行宽。以上的列在实现时可视情况和习惯加以删减。
2. 当码表的列较多且也行较多时，可将上述的标识列和常用的信息存于一个表，将其它的信息另表存储。
4.3 业务数据表
1. 设有‘录入人’和‘录入日期’列，由系统自动记录。
2. 记录单据的表中设置“自动单据号”，由两个字符开始以区分单据类型，后跟一数字序列表示序号。‘自动单据号’由系统自动生成，作为主表的主键，不允许用户修改。
当有对应的纸质单据时，设置“单据号”用于记录纸质单据的单据号。
3. 明细表中设有行序号，自动记录行的录入顺序。
4. 设置“存档标记”列，用于抽取数据到决策数据库时的更新标记。插入新行或修改已有行时设置该标记；数据抽取后清除该标记。
5. 对于用于查询过滤条件的列，不可为空，以免行“丢失”。
6. 对于数值列，不可为空，“0”作为默认值。
7. 对于必要的“冗余”列，如客户名称，应有相应的程序保持各“冗余”列的同一性，以免出现异议。
8. 设置“过程状态”列和“记录状态”列。过程状态列用于记录如创建、审核、记账、冲红等状态；记录状态用于记录如有效、删除等状态。
5 数据库命名原则
5.1 表名
. 业务数据表：t_d_<系统标识>_<表标识>。
. 基本编码表：t_b_[<系统标识>]_<表标识>。
. 辅助编码表：t_a_[<系统标识>]_<表标识>。
. 系统信息表：t_s_[<系统标识>]_<表标识>。
. 累计数据表：t_t_<系统标识>_<表标识>。
. 结算数据表：t_c_<系统标识>_<表标识>。
. 决策数据表：t_w_<系统标识>_<表标识>。
5.2 视图
v_<视图类型>_[<系统标识>]_<视图标识>。视图类型参见《表的分类》。
5.3 存储过程
p_[<系统标识>]_<存储过程标识>

5.4 函数
f_[<系统标识>]_<函数标识>

5.5 触发器
tr_<表名>_<i,u,d的任意组合> (after)

ti_<表名>_<i,u,d的任意组合> (instead)

5.6 自定义数据类型
ud_<自定义数据类型标识>_<数据类型>

5.7 Default

df_<Default标识>

5.8 Rule

ru_<Rule标识>

5.9 主键
pk_<表名>_<主键标识>

5.10 外键
fk_<表名>_<主表名>_<外键标识>

 

本篇文章来源于：开发学院 http://edu.codepub.com   原文链接：http://edu.codepub.com/2009/1215/18753.php

小龟MR

123456MINGr

一、数据库设计过程
数据库技术是信息资源管理最有效的手段。数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。
数据库设计中需求分析阶段综合各个用户的应用需求（现实世界的需求），在概念设计阶段形成独立于机器特点、独立于各个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 第零步——初始化工程
这个阶段的任务是从目的描述和范围描述开始，确定建模目标，开发建模计划，组织建模队伍，收集源材料，制定约束和规范。收集源材料是这阶段的重点。通过调查和观察结果，业务流程，原有系统的输入输出，各种报表，收集原始数据，形成了基本数据资料表。
2.2 第一步——定义实体
实体集成员都有一个共同的特征和属性集，可以从收集的源材料——基本数据资料表中直接或间接标识出大部分实体。根据源材料名字表中表示物的术语以及具有“代码”结尾的术语，如客户代码、代理商代码、产品代码等将其名词部分代表的实体标识出来，从而初步找出潜在的实体，形成初步实体表。
2.3 第二步——定义联系
IDEF1X模型中只允许二元联系，n元联系必须定义为n个二元联系。根据实际的业务需求和规则，使用实体联系矩阵来标识实体间的二元关系，然后根据实际情况确定出连接关系的势、关系名和说明，确定关系类型，是标识关系、非标识关系（强制的或可选的）还是非确定关系、分类关系。如果子实体的每个实例都需要通过和父实体的关系来标识，则为标识关系，否则为非标识关系。非标识关系中，如果每个子实体的实例都与而且只与一个父实体关联，则为强制的，否则为非强制的。如果父实体与子实体代表的是同一现实对象，那么它们为分类关系。
2.4 第三步——定义码
通过引入交叉实体除去上一阶段产生的非确定关系，然后从非交叉实体和独立实体开始标识侯选码属性，以便唯一识别每个实体的实例，再从侯选码中确定主码。为了确定主码和关系的有效性，通过非空规则和非多值规则来保证，即一个实体实例的一个属性不能是空值，也不能在同一个时刻有一个以上的值。找出误认的确定关系，将实体进一步分解，最后构造出IDEF1X模型的键基视图（KB图）。
2.5 第四步——定义属性
从源数据表中抽取说明性的名词开发出属性表，确定属性的所有者。定义非主码属性，检查属性的非空及非多值规则。此外，还要检查完全依赖函数规则和非传递依赖规则，保证一个非主码属性必须依赖于主码、整个主码、仅仅是主码。以此得到了至少符合关系理论第三范式的改进的IDEF1X模型的全属性视图。
2.6 第五步——定义其他对象和规则
    定义属性的数据类型、长度、精度、非空、缺省值、约束规则等。定义触发器、存储过程、视图、角色、同义词、序列等对象信息。
3. 逻辑结构设计阶段
    将概念结构转换为某个DBMS所支持的数据模型（例如关系模型），并对其进行优化。设计逻辑结构应该选择最适于描述与表达相应概念结构的数据模型，然后选择最合适的DBMS。
将E-R图转换为关系模型实际上就是要将实体、实体的属性和实体之间的联系转化为关系模式,这种转换一般遵循如下原则：
1）一个实体型转换为一个关系模式。实体的属性就是关系的属性。实体的码就是关系的码。
2）一个m:n联系转换为一个关系模式。与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性。而关系的码为各实体码的组合。
3）一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为n端实体的码。
4）一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。
5）三个或三个以上实体间的一个多元联系转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性。而关系的码为各实体码的组合。 
6）同一实体集的实体间的联系，即自联系，也可按上述1:1、1:n和m:n三种情况分别处理。
7）具有相同码的关系模式可合并。
为了进一步提高数据库应用系统的性能，通常以规范化理论为指导，还应该适当地修改、调整数据模型的结构，这就是数据模型的优化。确定数据依赖。消除冗余的联系。确定各关系模式分别属于第几范式。确定是否要对它们进行合并或分解。一般来说将关系分解为3NF的标准，即：
表内的每一个值都只能被表达一次。
· 表内的每一行都应该被唯一的标识（有唯一键）。
表内不应该存储依赖于其他键的非键信息。  
4. 数据库物理设计阶段
为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）。根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。
5. 数据库实施阶段
运用DBMS提供的数据语言（例如SQL）及其宿主语言（例如C），根据逻辑设计和物理设计的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。 数据库实施主要包括以下工作：用DDL定义数据库结构、组织数据入库 、编制与调试应用程序、数据库试运行 
6. 数据库运行和维护阶段
数据库应用系统经过试运行后即可投入正式运行。在数据库系统运行过程中必须不断地对其进行评价、调整与修改。包括：数据库的转储和恢复、数据库的安全性、完整性控制、数据库性能的监督、分析和改进、数据库的重组织和重构造。

建模工具的使用
为加快数据库设计速度，目前有很多数据库辅助工具（CASE工具），如Rational公司的Rational Rose，CA公司的Erwin和Bpwin，Sybase公司的PowerDesigner以及Oracle公司的Oracle Designer等。
ERwin主要用来建立数据库的概念模型和物理模型。它能用图形化的方式，描述出实体、联系及实体的属性。ERwin支持IDEF1X方法。通过使用ERwin建模工具自动生成、更改和分析IDEF1X模型，不仅能得到优秀的业务功能和数据需求模型，而且可以实现从IDEF1X模型到数据库物理设计的转变。ERwin工具绘制的模型对应于逻辑模型和物理模型两种。在逻辑模型中，IDEF1X工具箱可以方便地用图形化的方式构建和绘制实体联系及实体的属性。在物理模型中，ERwin可以定义对应的表、列，并可针对各种数据库管理系统自动转换为适当的类型。
设计人员可根据需要选用相应的数据库设计建模工具。例如需求分析完成之后，设计人员可以使用Erwin画ER图，将ER图转换为关系数据模型，生成数据库结构；画数据流图，生成应用程序。
二、数据库设计技巧
1. 设计数据库之前（需求分析阶段）
1) 理解客户需求，询问用户如何看待未来需求变化。让客户解释其需求，而且随着开发的继续，还要经常询问客户保证其需求仍然在开发的目的之中。
2) 了解企业业务可以在以后的开发阶段节约大量的时间。
3) 重视输入输出。
在定义数据库表和字段需求（输入）时，首先应检查现有的或者已经设计出的报表、查询和视图（输出）以决定为了支持这些输出哪些是必要的表和字段。
举例：假如客户需要一个报表按照邮政编码排序、分段和求和，你要保证其中包括了单独的邮政编码字段而不要把邮政编码糅进地址字段里。
4) 创建数据字典和ER 图表
ER 图表和数据字典可以让任何了解数据库的人都明确如何从数据库中获得数据。ER图对表明表之间关系很有用，而数据字典则说明了每个字段的用途以及任何可能存在的别名。对SQL 表达式的文档化来说这是完全必要的。
5) 定义标准的对象命名规范
数据库各种对象的命名必须规范。
2. 表和字段的设计（数据库逻辑设计）
表设计原则
1) 标准化和规范化
数据的标准化有助于消除数据库中的数据冗余。标准化有好几种形式，但Third Normal Form（3NF）通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。简单来说，遵守3NF 标准的数据库的表设计原则是：“One Fact in One Place”即某个表只包括其本身基本的属性，当不是它们本身所具有的属性时需进行分解。表之间的关系通过外键相连接。它具有以下特点：有一组表专门存放通过键连接起来的关联数据。
举例：某个存放客户及其有关定单的3NF 数据库就可能有两个表：Customer 和Order。Order 表不包含定单关联客户的任何信息，但表内会存放一个键值，该键指向Customer 表里包含该客户信息的那一行。
事实上，为了效率的缘故，对表不进行标准化有时也是必要的。
2) 数据驱动
采用数据驱动而非硬编码的方式，许多策略变更和维护都会方便得多，大大增强系统的灵活性和扩展性。
举例，假如用户界面要访问外部数据源（文件、XML 文档、其他数据库等），不妨把相应的连接和路径信息存储在用户界面支持表里。还有，如果用户界面执行工作流之类的任务（发送邮件、打印信笺、修改记录状态等），那么产生工作流的数据也可以存放在数据库里。角色权限管理也可以通过数据驱动来完成。事实上，如果过程是数据驱动的，你就可以把相当大的责任推给用户，由用户来维护自己的工作流过程。
3) 考虑各种变化
在设计数据库的时候考虑到哪些数据字段将来可能会发生变更。
举例，姓氏就是如此（注意是西方人的姓氏，比如女性结婚后从夫姓等）。所以，在建立系统存储客户信息时，在单独的一个数据表里存储姓氏字段，而且还附加起始日和终止日等字段，这样就可以跟踪这一数据条目的变化。

字段设计原则
4) 每个表中都应该添加的3 个有用的字段
· dRecordCreationDate，在VB 下默认是Now()，而在SQL Server 下默认为GETDATE()
· sRecordCreator，在SQL Server 下默认为NOT NULL DEFAULT USER
· nRecordVersion，记录的版本标记；有助于准确说明记录中出现null 数据或者丢失数据的原因
5) 对地址和电话采用多个字段
描述街道地址就短短一行记录是不够的。Address_Line1、Address_Line2 和Address_Line3 可以提供更大的灵活性。还有，电话号码和邮件地址最好拥有自己的数据表，其间具有自身的类型和标记类别。
6) 使用角色实体定义属于某类别的列
在需要对属于特定类别或者具有特定角色的事物做定义时，可以用角色实体来创建特定的时间关联关系，从而可以实现自我文档化。
举例：用PERSON 实体和PERSON_TYPE 实体来描述人员。比方说，当John Smith, Engineer 提升为John Smith, Director 乃至最后爬到John Smith, CIO 的高位，而所有你要做的不过是改变两个表PERSON 和PERSON_TYPE 之间关系的键值，同时增加一个日期/时间字段来知道变化是何时发生的。这样，你的PERSON_TYPE 表就包含了所有PERSON 的可能类型，比如Associate、Engineer、Director、CIO 或者CEO 等。还有个替代办法就是改变PERSON 记录来反映新头衔的变化，不过这样一来在时间上无法跟踪个人所处位置的具体时间。
7) 选择数字类型和文本类型尽量充足
在SQL 中使用smallint 和tinyint 类型要特别小心。比如，假如想看看月销售总额，总额字段类型是smallint，那么，如果总额超过了$32,767 就不能进行计算操作了。
而ID 类型的文本字段，比如客户ID 或定单号等等都应该设置得比一般想象更大。假设客户ID 为10 位数长。那你应该把数据库表字段的长度设为12 或者13 个字符长。但这额外占据的空间却无需将来重构整个数据库就可以实现数据库规模的增长了。
8) 增加删除标记字段
在表中包含一个“删除标记”字段，这样就可以把行标记为删除。在关系数据库里不要单独删除某一行；最好采用清除数据程序而且要仔细维护索引整体性。
3. 选择键和索引（数据库逻辑设计）
键选择原则：
1) 键设计4 原则
· 为关联字段创建外键。
· 所有的键都必须唯一。
· 避免使用复合键。
· 外键总是关联唯一的键字段。
2) 使用系统生成的主键
设计数据库的时候采用系统生成的键作为主键，那么实际控制了数据库的索引完整性。这样，数据库和非人工机制就有效地控制了对存储数据中每一行的访问。采用系统生成键作为主键还有一个优点：当拥有一致的键结构时，找到逻辑缺陷很容易。
3) 不要用用户的键(不让主键具有可更新性)
在确定采用什么字段作为表的键的时候，可一定要小心用户将要编辑的字段。通常的情况下不要选择用户可编辑的字段作为键。
4) 可选键有时可做主键
把可选键进一步用做主键，可以拥有建立强大索引的能力。

索引使用原则：
索引是从数据库中获取数据的最高效方式之一。95%的数据库性能问题都可以采用索引技术得到解决。
1)      逻辑主键使用唯一的成组索引，2)      对系统键（作为存储过程）采用唯一的非成组索引，3)      对任何外键列采用非成组索引。考虑数据库的空间有多大，4)      表如何进行访问，5)      还有这些访问是否主要用作读写。
6)      大多数数据库都索引自动创建的主键字段，7)      但是可别忘了索引外键，8)      它们也是经常使用的键，9)      比如运行查询显示主表和所有关联表的某条记录就用得上。
10)      不11)      要索引memo/note 字段，12)      不13)      要索引大型字段（有很多字符），14)      这样作会让索引占用太多的存储空间。
15)      不16)      要索引常用的小型表
不要为小型数据表设置任何键，假如它们经常有插入和删除操作就更别这样作了。对这些插入和删除操作的索引维护可能比扫描表空间消耗更多的时间。

4. 数据完整性设计（数据库逻辑设计）
1)      完整性实现机制：
实体完整性：主键
参照完整性：
父表中删除数据：级联删除；受限删除；置空值
父表中插入数据：受限插入；递归插入
父表中更新数据：级联更新；受限更新；置空值
DBMS对参照完整性可以有两种方法实现：外键实现机制（约束规则）和触发器实现机制
用户定义完整性：
    NOT NULL；CHECK；触发器
2) 用约束而非商务规则强制数据完整性
采用数据库系统实现数据的完整性。这不但包括通过标准化实现的完整性而且还包括数据的功能性。在写数据的时候还可以增加触发器来保证数据的正确性。不要依赖于商务层保证数据完整性；它不能保证表之间（外键）的完整性所以不能强加于其他完整性规则之上。
3) 强制指示完整性
在有害数据进入数据库之前将其剔除。激活数据库系统的指示完整性特性。这样可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。
4) 使用查找控制数据完整性
控制数据完整性的最佳方式就是限制用户的选择。只要有可能都应该提供给用户一个清晰的价值列表供其选择。这样将减少键入代码的错误和误解同时提供数据的一致性。某些公共数据特别适合查找：国家代码、状态代码等。
5) 采用视图
为了在数据库和应用程序代码之间提供另一层抽象，可以为应用程序建立专门的视图而不必非要应用程序直接访问数据表。这样做还等于在处理数据库变更时给你提供了更多的自由。
5. 其他设计技巧
1) 避免使用触发器
触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器，你最好集中对它文档化。
2) 使用常用英语（或者其他任何语言）而不要使用编码
在创建下拉菜单、列表、报表时最好按照英语名排序。假如需要编码，可以在编码旁附上用户知道的英语。
3) 保存常用信息
让一个表专门存放一般数据库信息非常有用。在这个表里存放数据库当前版本、最近检查/修复（对Access）、关联设计文档的名称、客户等信息。这样可以实现一种简单机制跟踪数据库，当客户抱怨他们的数据库没有达到希望的要求而与你联系时，这样做对非客户机/服务器环境特别有用。
4) 包含版本机制
在数据库中引入版本控制机制来确定使用中的数据库的版本。时间一长，用户的需求总是会改变的。最终可能会要求修改数据库结构。把版本信息直接存放到数据库中更为方便。
5) 编制文档
对所有的快捷方式、命名规范、限制和函数都要编制文档。
采用给表、列、触发器等加注释的数据库工具。对开发、支持和跟踪修改非常有用。
对数据库文档化，或者在数据库自身的内部或者单独建立文档。这样，当过了一年多时间后再回过头来做第2 个版本，犯错的机会将大大减少。
6) 测试、测试、反复测试
建立或者修订数据库之后，必须用用户新输入的数据测试数据字段。最重要的是，让用户进行测试并且同用户一道保证选择的数据类型满足商业要求。测试需要在把新数据库投入实际服务之前完成。
7) 检查设计
在开发期间检查数据库设计的常用技术是通过其所支持的应用程序原型检查数据库。换句话说，针对每一种最终表达数据的原型应用，保证你检查了数据模型并且查看如何取出数据。
三、数据库命名规范
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) 小心保留词，要保证你的字段名没有和保留词、数据库系统或者常用访问方法冲突
17)      保持字段名18)      和类型的一致性，19)      在命名20)      字段并为其指21)      定数据类型的时候一定要保证一致性。假如数据类型在一个表里是整数，22)      那在另一个表里可就别变成字符型了。
数据库设计规范化的五个要求2009-05-19 14:05:15 来源：作者不详 浏览次数：513  [收藏此页]  复制 分享到i贴吧
-

通常情况下，可以从两个方面来判断数据库是否设计的比较规范。一是看看是否拥有大量的窄表，二是宽表的数量是否足够的少。若符合这两个条件，则可以说明这个数据库的规范化水平还是比较高的。当然这是两个泛泛而谈的指标。为了达到数据库设计规范化的要求，一般来说，需要符合以下五个要求。
　　
要求一：表中应该避免可为空的列
　　
虽然表中允许空列，但是，空字段是一种比较特殊的数据类型。数据库在处理的时候，需要进行特殊的处理。如此的话，就会增加数据库处理记录的复杂性。当表中有比较多的空字段时，在同等条件下，数据库处理的性能会降低许多。
　　
所以，虽然在数据库表设计的时候，允许表中具有空字段，但是，我们应该尽量避免。若确实需要的话，我们可以通过一些折中的方式，来处理这些空字段，让其对数据库性能的影响降低到最少。
　　
一是通过设置默认值的形式，来避免空字段的产生。如在一个人事管理系统中，有时候身份证号码字段可能允许为空。因为不是每个人都可以记住自己的身份证号码。而在员工报到的时候，可能身份证没有带在身边。所以，身份证号码字段往往不能及时提供。为此，身份证号码字段可以允许为空，以满足这些特殊情况的需要。但是，在数据库设计的时候，则可以做一些处理。如当用户没有输入内容的时候，则把这个字段的默认值设置为0或者为N/A。以避免空字段的产生。
　　
二是若一张表中，允许为空的列比较多，接近表全部列数的三分之一。而且，这些列在大部分情况下，都是可有可无的。若数据库管理员遇到这种情况，笔者建议另外建立一张副表，以保存这些列。然后通过关键字把主表跟这张副表关联起来。将数据存储在两个独立的表中使得主表的设计更为简单，同时也能够满足存储空值信息的需要。
　　
要求二：表不应该有重复的值或者列
　　
如现在有一个进销存管理系统，这个系统中有一张产品基本信息表中Ｕ飧霾房⒂惺焙蚩梢允且桓鋈送瓿桑惺焙蛴中枰喔鋈撕献鞑拍芄煌瓿伞Ｋ裕诓坊拘畔⒈聿房⒄哒飧鲎侄沃校惺焙蚩赡苄枰钊攵喔隹⒄叩拿帧?BR>　　如进销存管理中，还需要对客户的联系人进行管理。有时候，企业可能只知道客户一个采购员的姓名。但是在必要的情况下，企业需要对客户的采购代表、仓库人员、财务人员共同进行管理。因为在订单上，可能需要填入采购代表的名字;可是在出货单上，则需要填入仓库管理人员的名字等等。
　　
为了解决这个问题，有多种实现方式。但是，若设计不合理的话在，则会导致重复的值或者列。如我们也可以这么设计，把客户信息、联系人都放入同一张表中。为了解决多个联系人的问题，可以设置第一联系人、第一联系人电话、第二联系人、第二联系人电话等等。若还有第三联系人、第四联系人等等，则往往还需要加入更多的字段。
　　
可是这么设计的话，会产生一系列的问题。如客户的采购员流动性比较大，在一年内换了六个采购员。此时，在系统中该如何管理呢?难道就建立六个联系人字段?这不但会导致空字段的增加，还需要频繁的更改数据库表结构。明显，这么做是不合理的。也有人说，可以直接修改采购员的名字呀。可是这么处理的话，会把原先采购订单上采购员的名字也改变了。因为采购单上客户采购员信息在数据库中存储的不是采购员的名字，而只是采购员对应的一个编号。在编号不改而名字改变了的情况下，采购订单上显示的就是更改后的名字。这不利于时候的追踪。
　　
所以，在数据库设计的时候要尽量避免这种重复的值或者列的产生。笔者建议，若数据库管理员遇到这种情况，可以改变一下策略。如把客户联系人另外设置一张表。然后通过客户ID把供应商信息表跟客户联系人信息表连接起来。也就是说，尽量将重复的值放置到一张独立的表中进行管理。然后通过视图或者其他手段把这些独立的表联系起来。
　　
要求三：表中记录应该有一个唯一的标识符

在数据库表设计的时候，数据库管理员应该养成一个好习惯，用一个ID号来
唯一的标识行记录，而不要通过名字、编号等字段来对纪录进行区分。每个表都应该有一个ID列，任何两个记录都不可以共享同一个ID值。另外，这个ID值最好有数据库来进行自动管理，而不要把这个任务给前台应用程序。否则的话，很容易产生ID值不统一的情况。
　　
另外，在数据库设计的时候，最好还能够加入行号。如在销售订单管理中，ID号是用户不能够维护的。但是，行号用户就可以维护。如在销售订单的行中，用户可以通过调整行号的大小来对订单行进行排序。通常情况下，ID列是以1为单位递进的。但是，行号就要以10为单位累进。如此，正常情况下，行号就以10、20、30依次扩展下去。若此时用户需要把行号为30的纪录调到第一行显示。此时，用户在不能够更改ID列的情况下，可以更改行号来实现。如可以把行号改为1，在排序时就可以按行号来进行排序。如此的话，原来行号为30的纪录现在行号变为了1，就可以在第一行中显示。这是在实际应用程序设计中对ID列的一个有效补充。这个内容在教科书上是没有的。需要在实际应用程序设计中，才会掌握到这个技巧。
　　
要求四：数据库对象要有统一的前缀名
　　
一个比较复杂的应用系统，其对应的数据库表往往以千计。若让数据库管理员看到对象名就了解这个数据库对象所起的作用，恐怕会比较困难。而且在数据库对象引用的时候，数据库管理员也会为不能迅速找到所需要的数据库对象而头疼。
　　
为此，笔者建立，在开发数据库之前，最好能够花一定的时间，去制定一个数据库对象的前缀命名规范。如笔者在数据库设计时，喜欢跟前台应用程序协商，确定合理的命名规范。笔者最常用的是根据前台应用程序的模块来定义后台数据库对象前缀名。如跟物料管理模块相关的表可以用M为前缀;而以订单管理相关的，则可以利用C作为前缀。具体采用什么前缀可以以用户的爱好而定义。但是，需要注意的是，这个命名规范应该在数据库管理员与前台应用程序开发者之间达成共识，并且严格按照这个命名规范来定义对象名。
　　
其次，表、视图、函数等最好也有统一的前缀。如视图可以用V为前缀，而函数则可以利用F为前缀。如此数据库管理员无论是在日常管理还是对象引用的时候，都能够在最短的时间内找到自己所需要的对象。
　　
要求五：尽量只存储单一实体类型的数据
　　
这里将的实体类型跟数据类型不是一回事，要注意区分。这里讲的实体类型是指所需要描述对象的本身。笔者举一个例子，估计大家就可以明白其中的内容了。如现在有一个图书馆里系统，有图书基本信息、作者信息两个实体对象。若用户要把这两个实体对象信息放在同一张表中也是可以的。如可以把表设计成图书名字、图书作者等等。可是如此设计的话，会给后续的维护带来不少的麻烦。
　　
如当后续有图书出版时，则需要为每次出版的图书增加作者信息，这无疑会增加额外的存储空间，也会增加记录的长度。而且若作者的情况有所改变，如住址改变了以后，则还需要去更改每本书的记录。同时，若这个作者的图书从数据库中全部删除之后，这个作者的信息也就荡然无存了。很明显，这不符合数据库设计规范化的需求。
　　
遇到这种情况时，笔者建议可以把上面这张表分解成三种独立的表，分别为图书基本信息表、作者基本信息表、图书与作者对应表等等。如此设计以后，以上遇到的所有问题就都引刃而解了。
　　
以上五条是在数据库设计时达到规范化水平的基本要求。除了这些另外还有很多细节方面的要求，如数据类型、存储过程等等。而且，数据库规范往往没有技术方面的严格限制，主要依靠数据库管理员日常工作经验的累积