数据库设计规范Word格式文档下载.docx

1、加工：数据处理，表示输入数据在此进行变换，产生输出数据（圆角巨型或圆形表示）。数据流：表示流动着的数据（箭头线表示）。数据存储：用来表示要存储的数据（开门矩形或两条平行横线表示）。订单处理系统顶层流程图：0层数据流图：2.3数据库设计2.3.1概念结构设计 对事务加以抽象以E-R图的形式描述出来 E-R图（实体联系图）：包括实体，联系，属性实体：现实中的事物例如，学生，老师联系：两个实体之间的关系，1:1、1：N、M:N三种关系属性：实体所具有的属性，例如 学生的学号、姓名、性别等例如：一个学生属于一个班级，一个班级拥有多名学生，E-R图如下网上购物系统E-R图，该系统数据之间存在下列约束1.

2、 一个客户（编号唯一）可以拥有多个订单，每个订单仅属于一个客户。2. 一个订单（编号唯一）可以包含多个订购细目，每个订购细目只属于一个订单。3. 一个商品可以出现多个订购细目中，一个订购细目只包含多个商品。4. 一个商品类别可以包含多种商品，一种商品只属于一个商品类别。图2.22.3.2逻辑结构设计2.3.2.1E-R图转换成关系模式 将E-R图转换成关系模式将每个实体转换成一个关系模式，实体的属性即关系模式的属性，实体的标识即关系模式的键。 根据规则合并E-R图中的1:1,1:N,M:N之间的联系1. 若实体的联系是（1:1），则可以将两个实体转换成两个关系模式，任意一个关系模式的属性中加入

3、另一个关系模式的主键（作为外键）和联系自身的属性2. 若实体间的联系是一对多（1：n），则将n端的实体类型转换成关系模式中加入1端实体类型的主键（作为外键）和联系类型的属性。3. 若实体间的联系是多对多（m:n），则将联系类型也转换成关系模式，其属性为2实体类型的主键（作为外键）加上联系类型自身的属性，而该关系模式的主键为2端实体主键的组合。4. 若关系模式是1：1：1的关系，转换原则同1：15. 若关系模式是1：n的联系，转换原则同1：n6. 若关系模式是1：n：m的联系，则可以将联系类型也转换成关系模式，其属性为m端和n端实体类型的主键（作为外键）加上联系类型自身的属性，而关系模式的主键为

4、n和m端实体主键的组合7. 若关系模式是n:m:p的联系，转换规则同m:根据E-R图实体之间的联系可以转换成以下关系模式：客户（客户编号，姓名，电话，E-mail）。关系的主键：客户编号；外键：无订单（订单编号，订购时间，客户编号）。订单编号；客户编号订购细目（订购明细编号，订购数量，支付金额，订单编号）。关系主键：订购明细编号；订单编号。出现（订购明细编号，商品编号，类型）。订购明细编号，商品编号；订购明细编号，商品编号。商品：（商品编号，商品名称，单价，生产日期，商品类别号，商品类别名）。商品编号；在关系模式设计中可能会出现以下几个问题：数据冗余、数据修改不一致、数据插入异常、数据删除异常

5、，所以提出范式的要求，目的就是最低限度地冗余，避免插入、删除、修改异常。2.3.2.2范式主属性：包含键的所有属性。 关系模式要求达到4NF （减少冗余，消除操作异常）第一范式（1NF）：若关系模式R的每一个分量是不可分的数据项，则关系模式属于第一范式。即每个属性都是不可拆分的.第二范式（2NF）：R属于1NF,且每一个非主属性完全依赖于键（没有部分依赖），则R属于2NF选课关系（学号，课程号，成绩，学分）该关系的主键是（学号，课程号），但是课程号学分，所以学分属性部分依赖于主键，即关系部满足第二范式，可以拆分为（学号，课程号，成绩），（课程号，学分）两个关系第三范式（3NF）：R属于2NF,

6、且每个非主属性即不部分依赖于码，也不传递依赖于码学生关系（学号，姓名，所属系，系地址）该关系的主键是:学号学号所属系，所属系学号，所属系系地址；根据函数的依赖公理，系地址传递函数依赖于学号，即关系不满足第三范式，可以拆分关系为（学号，姓名，所属系），（所属系，系地址）如果不拆分会存在数据修改异常，比如该学生的换了系，修改了所属系，但是系地址没有修改，这样就造成了修改异常BCNF：R属于3NF,且不存在主属性对码的部分和传递函数依赖关系R（零件号，零件名，厂商名），如果设定每种零件号只有一个零件名，但不同的的零件号可以有相同的零件名，每种零件可以有多个厂商生产，但每家厂商生产的零件应有不同的零件

7、名。这样可以得到：零件号零件名，（厂商名，零件名）零件号所以主属性包括（零件号，厂商名，零件名），但是“零件名”传递依赖于码“厂商名，零件名”，所以关系R不满足BCNF，当一个零件由多个生产厂商生产时，由于零件号只有一个而零件名根据厂商不同而又多个，零件名与零件号之间的联系将多次重复，带来数据冗余和操作异常现象可以将关系分解为（零件号，厂商名），（零件号，零件名）4NF：关系模式R属于1NF,若对于R的每个非平凡多值依赖XY且Y不包含于X时，X必含码，则R属于4NF5NF:对关系进行投影，消除关系中不是由候选码所蕴含的连接依赖对于上面的商品关系，由于关系的主键是商品编号，而商品类别号商品类别名

8、所以商品关系部满足第三范式，非主属性商品类别名传递依赖于商品编号，会存在数据冗余，数据修改异常问题。将商品关系分解为：商品（商品编号，商品名称，单价，生产日期，商品类别号）商品类别（商品类别号，商品类别名）2.3.3物理结构设计为一个给定的逻辑数据模型设计一个最合适应用要求的物理结构的过程 数据库的建立 数据表的建立 索引的建立 视图的建立 触发器的建立 存储过程设计 用户自定义函数设计 对关系模式的数据项加以约束，如检查约束、主键约束、参照完整性约束以保证数据正确性2.4应用程序设计采用高级语言以结构化设计方法或面向对象方法进行设计2.5系统实现3.优化策略3.1.查询优化策略1. 尽可能地

9、减少多表查询或建立物化视图2. 只检索需要的列3. 用带IN的条件字句等级替换or字句4. 经常提交COMMIT，以尽早释放锁3.2表设计1.如果频繁地访问涉及的是对两个相关的表进行连接操作，则考虑将其合并2.如果频繁地访问只是在表中的某一部分字段上进行，则考虑分解表，将该部分单独作为一个表3.对于很少更新的表，引入物化视图4. 当系统中有一些少量的，重复出现的值时，使用字典表来节约存储空间和优化查询。如地区、系统中用户类型的代号等。这类值不会在程序的运行期变化，但是需要存储在数据库中。就地区而言，如果我们要查询某个地区的记录，则数据库需要通过字符串匹配的方式来查询；如果将地区改为一个地区的代

10、号保存在表中，查询时通过地区的代号来查询，则查询的效率将大大提高。程序中宜大量的使用字典表来表示这类值。字典表中保存这类值的代号和实体的集合，以外键的方式关联到使用这类值的表中。然而，在编码阶段，程序员并不使用字典表，因为首先查询字典表中实体的代号，违背了提高查询效率的初衷。程序员在数据字典的帮助下，直接使用代号来代表实体，从而提高效率。虽然字典表在实际上并不使用，但是仍应该保留在数据库中（起码是在开发期内保留）。字典表作为另一种形式上的“数据字典文档”出现，以说明数据库中哪些表的哪些字段是使用了字典表的。为了提高数据库的数据完整性，在开发阶段可以保留完整的字典表和普通表的外键约束。但是在数据

11、库的运行阶段，应该将普通表和字典表的外键删除，以提高运行效率，特别是某些表使用了很多字典表的情况。案例：某数据库中有百万条用户信息，应用系统中常常需要按照地区要查询用户的信息。用户信息表以前是按照具体的地区名称来保存的，现在将具体的名称改为字典表中的地区代号，查询效率大大提高。3.3索引1. 如果查询是瓶颈，则在关系上建立适当的索引；通常，作为查询条件的属性上建立索引可以提高查询效率。2. 如果更新是瓶颈，因为每次更新都会重建表上的索引，引起效率降低，则考虑删除某些索引。3. 选择适当索引，如果经常使用范围查询，则B树索引比散列索引更高效4. 将有利于大多数查询和更新的索引设为聚集性索引。3.

12、4提高IO效率1. 索引文件和数据文件分开存储，事务日志文件存储在高速设备上2. 经常修改数据文件和索引文件的页面大小3. 定期对数据进行排序4. 增加必要的索引项4.数据库命名规范4.1数据库对象对象前缀数据库表视图VI索引IX存储过程SP函数FN触发器TR自定义数据类型udDefaultDF主键pk外键FKruleru序列SqUNIQUEuq数据库对象采用26个英文字母（区分大小写）和09这十个自然数，加上下划线_组成，共63个字符。不能出现其他字符（注释除外）。同一个数据库中这些对象名都是不能重复C CHECK_CONSTRAINTD DEFAULT_CONSTRAINTF FOREIG

13、N_KEY_CONSTRAINTIT INTERNAL_TABLEP SQL_STORED_PROCEDUREPK PRIMARY_KEY_CONSTRAINTS SYSTEM_TABLESQ SERVICE_QUEUETR SQL_TRIGGERU USER_TABLEUQ UNIQUE_CONSTRAINTV VIEW4.2命名规范规定1.表名使用单数名对存储客人信息的表（Customer）不使用Customers2.避免无谓的表格后缀1、 表是用来存储数据信息的,表是行的集合。那么如果表名已经能够很好地说明其包含的数据信息，就不需要再添加体现上面两点的后缀了。2、 GuestInfo（存储客户信息）应写成Guest，FlightList（存储航班信息的表）应写成Flight3.所有表示时间的字段，统一以 Date 来作为结尾（而不是有的使用Date,有的使用Time）以大家都熟悉的论坛来