数据库中多对多的关系设计
数据库设计多对多关系的几种形态
前言：多对多关系至少需要3个表，我们把一个表叫做主表，一个叫做关系表，另外一个叫做字典表或者副表（字典表是纪录比较少，而且基本稳定的，例如：版块名称；副表是内容比较多，内容变化的，例如）。
按照数据库的增删查改操作，多对多关系的查找都可以用inner join或者select * from 主表where id in (select 主表id from 关系表)
1，角色任命型
特点：关系表两外键组合无重复纪录，关系表一般不需要时间字段和主键，有一个表是字典类型的表。
界面特点：显示主表，用checkbox或多选select设置多选关系。
例如：任命版主（用户表-关系表-版块名称表），角色权限控制等，用户是5个版块版主，只要关系表5行纪录就可以确立，关系表的两个外键具有联合主键性质。
增加关系：如果没有组合纪录，insert之。
删除关系：如果有组合纪录，删除之。
2，集合分组型
特点：同角色任命型类似，关系表两外键组合无重复纪录，关系表一般不需要时间字段和主
键。区别是主副表都不是字典表，可能都很大不固定。
界面特点：显示主表，用搜索代替简单的checkbox或多选select，或者一条一条的添加。例如：歌曲专集（专集表-关系表-歌曲表）。手机分组（分组表-关系表-手机表）。用户圈子（圈子表-关系表-用户表）。文章标签（文章表-关系表-标签表）
增加关系：同版主任命型。
删除关系：同版主任命型。
3，明细帐型
特点：关系表可以有重复纪录，关系表一般有时间字段，有主键，可能还有文字型的字段用来说明每次发生关系的原因（消费）。
界面特点：显示关系表，用radio或下拉设置单选关系。
例如：现金消费明细帐或订单（用户表-订单表-消费原因表），用户可能多次在同一事情上重复消费。积分变化纪录也属于这类。
增加关系：不管有没有组合纪录，insert之，纪录时间。
删除关系：根据关系表PK删除。
4，评论回复型
特点：同明细帐型关系表一般有时间字段，有主键，区别是重点在文字型的字段用来说明每次发生关系的内容（评论回复）。
界面特点：回复文本框。
例如：论坛回复（用户表-回复表-帖子表），用户可能多次在不同帖子上评论回复费。
增加关系：不管有没有组合纪录，insert之，纪录时间和文字。
删除关系：根据关系表（回复表）PK删除。
5，站内短信型
特点：主副表是同一个，关系表一般有时间字段，有主键，重点在关系表文字型的字段用来说明每次发生关系的内容（消息）或者其他标记位来表示文字已读状态时间等。
界面特点：回复文本框。
例如：站内短信（用户表-短信表-用户表），用户可能给用户群发或者单发，有标记位来表示文字已读状态时间等。
增加关系：不管有没有组合纪录，insert之，纪录时间和文字。
删除关系：根据关系表（回复表）PK删除。
6，用户好友型
特点：主副表是同一个，同集合分组型，关系表两外键组合无重复纪录，关系表一般不需要时间字段和主键。
界面特点：同集合分组型，显示主表，用搜索代替简单的checkbox或多选select，或者一条一条的添加。
例如：下载站点的文件，（文件表-关系表-文件表）可以被软件工具打开，软件工具本身也是一种文件，可以被下载。用户的好友，也是用户（用户表-好友关系表-用户表）
增加关系：同版主任命型。
删除关系：同版主任命型。
7，未知属性型
特点：在设计初期，主表的某些字段类型和名称是不确定的时候，关系表实际上是主表的可扩展字段，
一个[主表]（ID），
一个[属性名称表]（属性ID.属性名称)，
一个[属性值表]，包括3个字段：
属性值(属性Value varchar(500))
主表ID
属性ID
这样可以作到最小冗余度。
（和常见的多对多关系不同的是：值统一用varchar来存储，因为这类型的值一般不会用来计算）。
比如：
军队的数据库设计中有种物资叫做“战缴物资”，就是打仗的时候缴获的，军队自己都不知道这些物资有什么属性。
比如缴获的化学品有化学名，通用名，是否有辐射，计量单位，包装规格，数量等等，或者不是化学品是其他任何未知的东西。
这样东西就可以
某奇怪东西.属性集合["某某奇怪属性名"]="某某奇怪值"；
某变态东西.属性集合["某某变态属性名"]="某某变态值"；
这样存储。
再比如：
手机型号有几千种，除了共同属性外还有不同属性有几百个，属性名和值类型都不一样，有的手机有这属性，有的没有。
对于这样的“多态”，我们就采用上面的设计结构。
其效果相当于：
某奇怪手机.属性集合["某某奇怪属性名"]="某某奇怪值"；
某变态手机.属性集合["某某变态属性名"]="某某变态值"；
界面特点：设置主表一行纪录的属性时候，要列出所有可能的属性名称，每个对应一个文本框。
数据库的设计理论 第一节，关系模式的设计问题 一概念： 1. 关系模型：用二维表来表示实体集，用外键来表示实体间的联系，这样的数据模型，叫做关系数据模型。 关系模型包含内涵和外延两个方面： 外延：就是关系或实例、或当前值。它与时间有关，随时间的变化而变化。（主要是由于元组的插入、删除、修改等操作引起的） 内涵：内涵是与时间独立的，它包括关系属性、以及域的一些定义和说明。还有数据的各种完整性约束。 数据的完整性约束分为静态约束和动态约束。 静态约束包括数据之间的联系（称为数据依赖），主键的设计和各种限制。 动态约束主要定义如插入、删除和修改等操作的影响。 通常我们称内涵为关系模式。 2. 关系模式：是对一个关系的描述，二维表的表头那一行称为关系模式，又称为表的框架或记录类型。 关系模式的定义包括：模式名、属性名、值域名和模式的主键。关系模式仅仅是对数据特征的描述。 关系模式的一般形式为R ( U , D , DOM , F ) R 是关系名。 U 是全部属性的集合。 D 是属性域的集合。 DOM 是U 和D 之间的映射关系，关系运算的安全限制。 F 是属性间的各种约束关系，也称为数据依赖。
关系模式可以表示为： 关系模式（属性名1，属性名2 ，……，属性名n ） 示例：学生（学号，姓名，年龄，性别，籍贯）。 当且仅当U 上的一个关系r 满足 F 时，r 就称为关系模式R（U，F）上的一个关系，R是关系的型，r 是关系的值，每个值称为R 的一个关系。 关系数据库模式： 一个数据库是由多个关系构成的。 一个关系数据库对应多个不同的关系模式，关系数据库模式是一个数据库中所有的关系模式的集合。它规定了数据库的全局逻辑结构。 关系数据库模式可以表示为： S = { Ri < Ui , Di , DOM , Fi > | i = 1,2,…, n } 3. 关系子模式 关系子模式是用户所用到的那部分数据的描述。 外模式是关系子模式的集合。 4. 存储模式 存储模式及内模式。 关系数据库理论的主要内容： （1）数据依赖。数据依赖起着核心的作用。 （2）范式。 （3）模式的设计方法。 如何设计一个合理的数据库模式： （1）与实际问题相结合。 泛关系模式：把现实问题的所有属性组成一个关系模式 泛关系：泛关系模式的实例称为泛关系。 泛关系模式中存在的问题： a 数据冗余 b 更新异常， c 插入异常 d 删除异常。
关系型数据库设计原理 1．为E-R图中的每个实体建立一张表。 2．为每张表定义一个主键（如果需要，可以向表添加一个没有实际意义的字段作为该表的主键） 3．增加外键表示一对多关系。 4．建立新表表示多对多关系。 5．为字段选择合适的数据类型。 6．定义约束条件（如果需要）。 7．评价关系的质量，并进行必要的改进 数据库是存储数据库对象的容器。MySQL数据库的管理主要包括数据库的创建、选择当前操作的数据库、显示数据库结构以及删除数据库等操作。成功创建choose数据库后，数据库根目录下会自动创建数据库目录。使用MySQL命令show databases;即可查看MySQL服务实例上所有的数据库使用MySQL命令show create database choose;可以查看choose数据库的相关信息（例如MySQL版本ID号、默认字符集等信息）执行“use choose;”命令后，后续的MySQL命令以及SQL语句将自动操作choose数据库中所有数据库对象。删除student 数据库，使用SQL语句 drop database student 表是数据库中最为重要的数据库对象MyISAM和InnoDB存储引擎设置默认的存储引擎创建数据库表显示表结构表记录的管理 MySQL提供了插件式（Pluggable）的存储引擎，存储引擎是基于表的，同一个数据库，不同的表，存储引擎可以不同。甚至同一个数据库表，在不同的场合可以应用不同的存储引擎。 表记录的插入表记录的修改表记录的删除MySQL特殊字符序列 向数据库表插入记录时，可以使用insert语句向表中插入一条或者多条记录，也可以使用insert….select语句向表中插入另一个表的结果集。 本章详细讲解select语句检索表记录的方法， select语句概述使用where子句过滤结果集使用order by子句对结果集排序使用聚合函数汇总结果集使用group by子句对记录分组统计合并结果集子查询选课系统综合查询 使用正则表达式模糊查询全文检索 视图与表有很多相似的地方，视图也是由若干个字段以及若干条记录构成，视图也可以作为select语句的数据源。甚至在某些特定条件下，可以通过视图对表进行更新操作。视图中保存的仅仅是一条select语句，视图中的源数据都来自于数据库表，数据库表称为基本表或者基表，视图称为虚表。 1．使操作变得简单 2．避免数据冗余 3．增强数据安全性 4．提高数据的逻辑独立性 如果某个视图不再使用，可以使用drop view语句将该视图删除视图分为普通视图与检查视图。通过检查视图更新基表数据时，只有满足检查条件的更新语句才能成功执行
目录 一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. 数据完整性的独立性专用于某个关系型数据库的完整性约束必须可以用关系数据库子语言定 义，而且可以存储在数据目录中，而非程序中。
数据库设计方法及命名规范
- - 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)
关系数据库逻辑设计(一) (总分：116.98，做题时间：90分钟) 一、选择题(总题数：37，分数：37.00) 1.数据库逻辑设计的依据不包括______。 A) 概念模型 B) 安全性要求 C) 数据约束 D) 功能模型 （分数：1.00） A. B. C. D. √ 解析：[解析] 数据库逻辑设计的依据是数据库概念设计的结果，包括概念数据模型、数据处理要求、数据约束、安全性要求及DBMS的相关信息，因此本题答案为D。 2.以下关于数据库逻辑设计叙述错误的是______。 A) 数据库逻辑设计是面向机器世界的 B) 这个阶段将按照数据库管理系统支持的数据模型来组织和存储数据 C) 目标是得到实际的数据库管理系统可处理的数据库模式，并做到数据结构合理 D) 包括定义和描述数据库的局部逻辑结构、数据之间的关系、数据完整性及安全性要求等 （分数：1.00） A. B. C. D. √ 解析：[解析] 数据库逻辑设计包括定义和描述数据库的全局逻辑结构、数据之间的关系、数据完整性及安全性要求等。因此本题答案为D。 3.在关系数据库设计中，设计关系模式是数据库设计中哪个阶段的任务______。 A) 逻辑设计阶段 B) 概念设计阶段 C) 物理设计阶段 D) 需求分析阶段 （分数：1.00） A. √ B. C. D. 解析：[解析] 关系数据模型是常用的逻辑数据模型，所以设计关系模式是数据库设计中逻辑设计阶段的任务，因此本题答案为A。 4.对于关系的主码必须满足的条件，有下列说法： Ⅰ．一个关系中的主码属性或属性组能函数决定该关系中的所有其他属性 Ⅱ．一个关系中的主码属性不能与其他关系中的主码属性重名 Ⅲ．在一个关系中，一个主码属性的任一真子集都不能函数决定其他属性
关系型数据库和非关系 型数据库 集团标准化办公室：[VV986T-J682P28-JP266L8-68PNN]
关系型数据库和非关系型数据库 自1970年，埃德加·科德提出关系模型之后，关系数据库便开始出现，经过了40多年的演化，如今的关系型数据库具备了强大的存储、维护、查询数据的能力。但在关系数据库日益强大的时候，人们发现，在这个信息爆炸的“大数据”时代，关系型数据库遇到了性能方面的瓶颈，面对一个表中上亿条的数据，SQL语句在大数据的查询方面效率欠佳。我们应该知道，往往添加了越多的约束的技术，在一定程度上定会拖延其效率。 在1998年，CarloStrozzi提出NOSQL的概念，指的是他开发的一个没有SQL功能，轻量级的，开源的关系型数据库。注意，这个定义跟我们现在对NoSQL的定义有很大的区别，它确确实实字如其名，指的就是“没有SQL”的数据库。但是NoSQL的发展慢慢偏离了初衷，CarloStrozzi也发觉，其实我们要的不是"nosql"，而应该是"norelational"，也就是我们现在常说的非关系型数据库了。 在关系型数据库中，导致性能欠佳的最主要因素是多表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询。为了保证数据库的ACID特性，我们必须尽量按照其要求的范式进行设计，关系型数据库中的表都是存储一些格式化的数据结构，每个元组字段的组成都一样，即使不是每个元组都需要所有的字段，但数据库会为每个元组分配所有的字段，这样的结构可以便于表与表之间进行连接等操作，但从另一个角度来说它也是关系型数据库性能瓶颈的一个因素。 非关系型数据库提出另一种理念，他以键值对存储，且结构不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键值对，这样就不会局限于固定的结构，可以减少一些时间和空间的开销。使用这种方式，用户可以根据需要去添加自己需要的字段，这样，为了获取用户的不同信息，不需要像关系型数据库中，要对多表进行关联查询。仅需要根据id取出相应的value就可以完成查询。但非关系型数据库由于很少的约束，他也不能够提供想SQL所提供的where这种对于字段属性值情况的查询。并且难以体现设计的完整性。他只适合存储一些较为简单的数据，对于需要进行较复杂查询的数据，SQL数据库显得更为合适。 目前出现的NoSQL(NotonlySQL，非关系型数据库)有不下于25种，除了Dynamo、Bigtable以外还有很多，比如Amazon的SimpleDB、微软公司的AzureTable、Facebook使用的Cassandra、类Bigtable的Hypertable、Hadoop的HBase、MongoDB、CouchDB、Redis以及Yahoo!的PNUTS等等。这些NoSQL各有特色，是基于不同应用场景而开发的，而其中以MongoDB和Redis最为被大家追捧。 以下是MongoDB的一些情况： MongoDB是基于文档的存储的（而非表），是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。他支持的数据结构非常松散，是类似json 的bjson格式，因此可以存储比较复杂的数据类型。模式自由(schema-free)，意味着对于存储在MongoDB数据库中的文件，我们不需要知道它的任何结构定义。如果需要的话，你完全可以把不同结构的文件存储在同一个数据库里。Mongo最大的特点是他支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数 据库单表查询的绝大部分功能，而且还支持对数据建立索引。 Mongo主要解决的是海量数据的访问效率问题。因为Mongo主要是支持海量数据存储的，所以Mongo还自带了一个出色的分布式文件系统GridFS，可以支持海量的数据存储。由于Mongo可以支持复杂的数据结构，而且带有强大的数据查询功能，因此非常受到欢迎。 关系型数据库的特点 1.关系型数据库
第四章关系数据库设计理论练习题 一、选择题 1、关系规范化中的删除操作异常是指①A，插入操作异常是指②D A、不该删除的数据被删除. B、不该插入的数据被插入; C、应该删除的数据未被删除; D、应该插入的数据未被插入. 2、关系数据库规范化是为解决关系数据库中（）问题而引入的。 A、插入异常、删除异常和数据冗余； B、提高查询速度; C、减少数据操作的复杂性; D、保证数据的安全性和完整性。 3、假设关系模式R（A，B）属于3NF，下列说法中（）是正确的。 A、R一定消除了插入和删除异常； B、R仍可能存在一定的插入和删除异常; C、R一定属于BCNF； D、A和C都是. 4、关系模式的分解 A、唯一 B、不唯一. 5、设有关系W（工号，姓名，工种，定额），将其规范化到第三范式正确的答案是（） A、W1（工号，姓名），W2（工种，定额）； B、W1（工号，工种，定额），W2（工号，姓名）； C、W1（工号，姓名，工种），W2（工种，定额）; D、以上都不对. 6、设学生关系模式为：学生（学号，姓名，年龄，性别，平均成绩，专业），则该关系模式的主键是（） A、姓名； B、学号，姓名； C、学号; D、学号，姓名，年龄. 7根据数据库规范化理论，下面命题中正确的是（） A、若R∈2NF,则R∈3NF B、若R∈1NF,则R不属于BCNF C、若R∈3NF,则R∈BCNF D、若R∈BCNF,则R∈3NF 8、关系数据库设计理论中，起核心作用的是 A、范式； B、模式设计； C、函数依赖; D、数据完整性. 9、设计性能较优的关系模设称为规范化，规范化的主要理论依据是（） A、关系规范化理论; B、关系运算理论；
数据库表设计的几条准则 前言：数据库设计在平时的工作是必不可少的，良好的表设计可以让我们查询效率更高，加快网站访问速度，提升用户体验，并且方便于我们查询数据。本篇博客就来聚焦一下，如何设计出高可复用，优良的表结构，从而在实际的工作中使我们写出更好的代码。 数据库表设计的几条黄金准则： 一：字段的原子性 解释：保证每列的原子性，不可分解，意思表达要清楚，不能含糊，高度概括字段的含义，能用一个字段表达清楚的绝不使用第二个字段，可以用两个字段表达清楚的绝不使用一个 字段 二：主键设计 解释：主键不要与业务逻辑有所关联，最好是毫无意义的一串独立不重复的数字，常见的比如UUID或者将主键设置为Auto_increment; 三：字段使用次数 解释：对于频繁修改的字段（一般是指状态类字段）最好用独立的数字或者单个字母去表示，不用使用汉字或者英文 四：字段长度 解释：建表的时候，字段长度尽量要比实际业务的字段大3-5个字段左右（考虑到合理性和伸缩性），最好是2的n次方幂值。不能建比实际业务太大的字段长度，这是因为如果字段长度过大，在进行查询的时候索引在B- Tree树上遍历会越耗费时间，从而查询的时间会越久；但是绝对不能建小，否则mysql数据会报错，程序会抛出异常； 五：关于外键 解释：尽量不要建立外键，保证每个表的独立性。如果非得保持一定的关系，最好是通过id 进行关联 六：动静分离 解释：最好做好静态表和动态表的分离。这里解释一下静态表和动态表的含义，静态表：存储着一些固定不变的资源，比如城市/地区名/国家。动态表：一些频繁修改的表 七：关于code值 解释：使用数字码或者字母去代替实际的名字，也就是尽量把name转换为code，因为name 可能会变（万一变化就会查询处多条数据，从而抛出错误），但是code一般是不会变化的.另一方面，code值存储的字符较少，也能减少数据库的压力 八：关于Null值 解释：不要有null值，有null值的话，数据库在进行索引的时候查询的时间更久，从而浪费更多的时间！
目录 一 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.数据完整性的独立性?专用于某个关系型数据库的完整性约束必须可以用关系数据库子语言定 义，而且可以存储在数据目录中，而非程序中。
一，关系型数据库 关系型数据库，是指采用了关系模型来组织数据的数据库。 简单来说，关系模型指的就是二维表格模型，而一个关系型数据库就是由二维表及其之间的联系所组成的一个数据组织。 关系模型中常用的概念： ?关系：可以理解为一张二维表，每个关系都具有一个关系名，就是通常说的表名?元组：可以理解为二维表中的一行，在数据库中经常被称为记录 ?属性：可以理解为二维表中的一列，在数据库中经常被称为字段 ?域：属性的取值范围，也就是数据库中某一列的取值限制 ?关键字：一组可以唯一标识元组的属性，数据库中常称为主键，由一个或多个列组成 ?关系模式：指对关系的描述。其格式为：关系名(属性1，属性2， ... ... ，属性N)，在数据库中成为表结构 关系型数据库的优点： ?容易理解：二维表结构是非常贴近逻辑世界的一个概念，关系模型相对网状、层次等其他模型来说更容易理解 ?使用方便：通用的SQL语言使得操作关系型数据库非常方便 ?易于维护：丰富的完整性(实体完整性、参照完整性和用户定义的完整性)大大减低了数据冗余和数据不一致的概率 二,范式，英文名称是 Normal Form，它是英国人 E.F.Codd（关系数据库的老祖宗）在上个世纪70年代提出关系数据库模型后总结出来的，范式是关系数据库理论的基础，也是我们在设计数据库结构过程中所要遵循的规则和指导方法，以下就是对这三个范式的基本介绍： 第一范式（1NF）： 数据表中的每一列(字段)，必须是不可拆分的最小单元，也就是确保每一列的原子性。
通俗解释：一个字段只存储一项信息 例如： userInfo: '山东省烟台市 1318162008' 依照第一范式必须拆分成: userInfo: '山东省烟台市' userTel: '1318162008'两个字段 第二范式（2NF）： 满足1NF后要求表中的所有列，都必需依赖于主键，而不能有任何一列与主键没有关系（一个表只描述一件事情）。 通俗解释：任意一个字段都只依赖表中的同一个字段 例如： 订单表只能描述订单相关的信息，所以所有的字段都必须与订单ID相关。 产品表只能描述产品相关的信息，所以所有的字段都必须与产品ID相关。 因此在同一张表中不能同时出现订单信息与产品信息。 第三范式（3NF）：第三范式(3NF)：满足2NF后，要求：表中的每一列都要与主键直接相关，而不是间接相关（表中的每一列只能依赖于主键） 例如：订单表中需要有客户相关信息，在分离出客户表之后，订单表中只需要有一个用户ID即可，而不能有其他的客户信息，因为其他的用户信息是直接关联于用户ID，而不是关联于订单ID。 注意事项： 1.第二范式与第三范式的本质区别：在于有没有分出两张表。 第二范式是说一张表中包含了多种不同实体的属性，那么必须要分成多张表，第三范式是要求已经分好了多张表的话，一张表中只能有另一张标的ID，而不能有其他任何信息，（其他任何信息，一律用主键在另一张表中查询）。 2.必须先满足第一范式才能满足第二范式，必须同时满足第一第二范式才能满足第三范式。
系统名称：客户关系管理系统 一、系统需求分析： 客户管理系统是为了方便管理客户基本信息，完成公司决策的重要手段， 通过该系统， 系统管理员可以通过次系统查询客户的基本信息，以及客户所购产品的信息。并可以对新老客户进行添加和删除，也可对现有用户的基本信息进行更改。从而实现公司对其客户的管理。 客户可以通过该数据库查看自己的基本信息和消费情况。 职员可以通过该数据库查看自己的基本情况、业绩情况和工作计划。 该数据库包含5个实体，分别是客户，联系人，产品，任务计划，反馈信息。 通过该数据库，可以实现以下功能（举例） 简单查询： ①查询客户的基本信息 ②查询公司职员的业绩情况（即联系人发展的客户情况） ③查询公司职员的任务计划 复杂查询： ①查询客户对某一类型产品的反馈信息（通过产品表和反馈信息表连接实现） ②查询客户反馈信息的受理情况 插入功能： 增添新客户，新产品，新联系人，新反馈信息以及其相关属性 修改功能： 系统管理员修改客户的基本信息（如积分，联系方式等），修改联系人的工作计划，反馈信息的受理情况 二、E-R图
三、关系模式 系统中的实体有：客户，联系人，反馈信息，任务计划，产品 关系模式如下： 客户（客户编号，姓名，联系方式，联系地址，积分，信用度，所购产品，消费时间，联系人编号） 联系人（联系人编号，姓名，所属部门，产品类型，任务计划编号，工资） 反馈信息（反馈编号，反馈人姓名，反馈时间，反馈内容，产品编号，解决情况）任务计划（任务计划编号，联系人编号，客户数量，计划利润，计划时间，实施情况）产品（产品编号，产品名称，生产日期，产品类型，质量级别，价格，优惠情况）反馈（客户编号，反馈编号） 发展（联系人编号，客户编号） 购买（客户编号，产品编号，购买时间，购买数量） 制定（联系人编号，任务计划编号，制定时间） 四，物理设计
规范化－数据库设计原则 关系数据库设计的核心问题是关系模型的设计。本文将结合具体的实例，介绍数据库设计规范化的流程。摘要 关系型数据库是当前广泛使用的数据库类型，关系数据库设计是对数据进行组织化和结构化的过程，核心问题是关系模型的设计。对于数据库规模较小的情况，我们可以比较轻松的处理数据库中的表结构。然而，随着项目规模的不断增长，相应的数据库也变得更加复杂，关系模型表结构更为庞杂，这时我们往往会发现我们写出来的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系统总体设计 面向关系数据库的关键字查询系统主要有五部分组成，首先要分析输入的关键字，有几个关键字组成;然后调用全文索引，查看这些关键字所属，是表名、属性名还是属性值;接下来查询数据库的模式图，从而得到几种可能的元组连接树;最后将相应元组连接树转化成SQ L 语句查询关系数据库，生成查询结果，以二维表格形式显示。 2数据库设计 本系统为面向关系数据库的关键字查询系统，在实验中本文选取了M D B数据集，为了进行实验，将数据集整理为以下七个表数据结构。实验数据集(电影信息数据库):Actor(演员表),Consume(设计师),Director(导演信息),Busness股资),Edito r(编辑),Color(颜色信息),Keyw ord(关键词)。 3数据库索引设计 在关系型数据库中，例如0 racl,DB2,SQ L Server和M ySQ L等都提供了对关键字查询的扩展，可以为数据库的表属性建立全文索引，这为实现关系数据库的关键字查询提供了基础。已有多个关系数据库的关键字查询系统被开发出来，BANKS ,D ISCO VER,IR-style,SEKKER 等等。然而在已有的系统中，多数系统仅仅支持数据库中文本属性的查询，却忽略了对数据库中元数据的处理。如果用户给定的查询关键字是数据库中的元数据，则有些系统就不能够满足用户的查询需求，
或者查询结果不够精确，返回大量与查询不相关的结果。SEKKER虽然提出了支持数字属性和元数据的查询，但是却在查询语言上做了限定，只能通过给定的查询语言格式进行查询，所以系统的灵活性不高。 4数据库模式图的构建 在关系数据库中，关键字是通过主外键进行连接的，因此关系数据库采用的数据模型，即为基于模式图建模。模式图的节点对应数据库中的关系，边表示关系间的主外键约束。 模式图(Schem a Graph,GS)是将关系数据库的模式信息定义为模式图GS(V,E)，其中V表示模式图中的节点，与数据库中的关系一一对应，E表示模式图中的边，将具有主外码约束相对应的关系连接起来，关系R;和关系R中的主外键关系对应模式图一条边R -R， 本文数据库对应的数据库模式图如图 3所示。 5关键字检索设计 关键字检索技术主要是，通过分析用户输入的关键字所属类型来确定元组连接树，从而转换成相应的SQ L语句来查询关系数据库。如果用户输入的关键字都是表名，则将几个表自然连接后输出即可;若用户输入的关键字有表名、属性名，那么将属性列加到表中输出就是用户所检索的内容;若用户输入的关键字中有属性值，则将属性值对应属性与表或属性列连接，根据属性值对应元组来显示查询结果。由此可见，对于相同的关键字，如果它不止一种所属值，那么它就会对应不同的SQ L语句。
学科实验报告 班级2010级金融姓名陈光伟学科管理系统中计算机应用实验名称数据库的创建与表间关系的各种操作 实验工具Visual foxpro 6.0 实验目的1、掌握数据库结构的创建方式 2、表间的关联关系 实验步骤一、建立数据库。 1、在项目管理器中建立数据库。首先选择数据库，然后单击“新建”建立数据库，出现的界面提示用户输入数据库的名称，按要求输入后单击“保存”则完成数据库的建立，并打开i“数据库设计器”。 2、从“新建”对话框建立数据库。单击工具栏上的“新建”按钮或者选择菜单“文件——新建”打开“新建”对话框，首先在“文件类型”组框中选择“数据库”，然后单击“新建文件”建立数据库，后面的操作和步骤与1相同。 3、用命令交互建立数据库。命令是create database【databasename ▏？】 二、表间关系的各种操作。 1、创建索引文件。可以再创建数据表时建立其结构复合索引文件，但是也可以先建立好数据表，以后再创建或修改索引文件。 2、索引的操作。A、打开与关闭。要使用索引，必须先要打开索引。一旦数据表文件关闭所有相应的索引文件也就自动关闭了。B、确定主控索引。可以使用命令确定当前主控索引。命令格式1：set order to 【tag】<索引标识>【ascending| desceding】命令格式2：use<表文件名>order【tag】<索引标识>【ascending | esceding】C、删除索引标识。要删除结构复合索引文件中的索引标识，应当打开数据表文件，并打开其表设计器对话框。在“索引”页面中选定要删除的索引标识后，单击“删除”按钮删除。 3、创建关联。在创建数据表之间的关联时，把当前数据表叫做父表，而把要关联的表叫做子表。必须保证两个要建立关系的数据表中存在能够建立联系的同类字段；同时要求每个数据表事先分别以该字段建立了索引。A、建立表间的一对一的关系。在“数据库设计器”窗口中选择M表中的字段，并按住左键拖到关联表H中对应字段上，放开鼠标左键。这是可以看到在两个表之间的相关字段上产生了一条连线，表明两个表之间已经建立了“一对一”关系。B、建立表间一对多的关系。将M表的名称字段MC设定为主索引，或者候选索引；H表中的JG字段已经设置成普通索引。在“数据库设计器”窗口中将MC字段拖到关联表中对应字段JG上，放开鼠标左键。这时可以看到在两个表之间的相关字段上产生了一条显然与“一对一”关联不同形式的连线，表明两个表之间已经建立了“一对多”关系。 4、调整或删除关联。A、删除关联。在数据库设计器对话框窗口中，首先必须用鼠标左键单击关联线，该连线变粗了说明它已被选中。如果要删除可敲【del】。也可以单击鼠标右键在弹出对话框窗口中单击“删除关联”选项。B、编辑关联。在数据库设计器对话框窗口中，首先必须用鼠标左键单击关联线，该连线变粗了说明已被选中。在主菜单“数据库”选项的下拉菜单中的“编辑关系”选项，也可以单击鼠标右键在弹出对话框窗口中单击“编辑关系”选项。 5、设置数据表之间的参照完整性。在对数据库表建立关联关系后，就可以设置两个相关数据表之间操作的有效性原则。这些规则可以控制相关表中的记录的插入、删除或修改。
根据建立的领域模型进行数据库表的映射，此时应参考数据库设计第二范式：一个表中的所有非关键字属性都依赖于整个关键字。应针对所有表的主键和外键建立索引，有针对性的（针对一些大数据量和常用检索方式）建立组合属性的索引，提高检索效率。 (1)不应针对整个系统进行数据库设计，而应该根据系统架构中的组件划分，针对每个组件所处理的业务进行组件单元的数据库设计；不同组件间所对应的数据库表之间的关联应尽可能减少，如果不同组件间的表需要外键关联也尽量不要创建外键关联，而只是记录关联表的一个主键，确保组件对应的表之间的独立性，为系统或表结构的重构提供可能性。 (2)采用领域模型驱动的方式和自顶向下的思路进行数据库设计，首先分析系统业务，根据职责定义对象。对象要符合封装的特性，确保与职责相关的数据项被定义在一个对象之内，这些数据项能够完整描述该职责，不会出现职责描述缺失。并且一个对象有且只有一项职责，如果一个对象要负责两个或两个以上的职责，应进行分拆。 (3)根据建立的领域模型进行数据库表的映射，此时应参考数据库设计第二范式：一个表中的所有非关键字属性都依赖于整个关键字。关键字可以是一个属性，也可以是多个属性的集合，不论那种方式，都应确保关键字能够保证唯一性。在确定关键字时，应保证关键字不会参与业务且不会出现更新异常，这时，最优解决方案为采用一个自增数值型属性或一个随机字符串作为表的关键字。 (4)由于第一点所述的领域模型驱动的方式设计数据库表结构，领域模型中的每一个对象只有一项职责，所以对象中的数据项不存在传递依赖，所以，这种思路的数据库表结构设计从一开始即满足第三范式：一个表应满足第二范式，且属性间不存在传递依赖。 (5)同样，由于对象职责的单一性以及对象之间的关系反映的是业务逻辑之间的关系，所以在领域模型中的对象存在主对象和从对象之分，从对象是从1－N或N－N的角度进一步主对象的业务逻辑，所以从对象及对象关系映射为的表及表关联关系不存在删除和插入异常。 (6)在映射后得出的数据库表结构中，应再根据第四范式进行进一步修改，确保不存在多值依赖。这时，应根据反向工程的思路反馈给领域模型。如果表结构中存在多值依赖，则证明领域模型中的对象具有至少两个以上的职责，应根据第一条进行设计修正。第四范式：一个表如果满足BCNF，不应存在多值依赖。 (7)在经过分析后确认所有的表都满足二、三、四范式的情况下，表和表之间的关联尽量采用弱关联以便于对表字段和表结构的调整和重构。并且，我认为数据库中的表是用来持久化一个对象实例在特定时间及特定条件下的状态的，只是一个存储介质，所以，表和表之间也不应用强关联来表述业务（数据间的一致性），这一职责应由系统的逻辑层来保证，这种方式也确保了系统对于不正确数据（脏数据）的兼容性。当然，从整个系统的角度来说我们还是要尽最大努力确保系统不会产生脏数据，单从另一个角度来说，脏数据的产生在一定程度上也是不可避免的，我们也要保证系统对这种情况的容错性。这是一个折中的方案。 (8)应针对所有表的主键和外键建立索引，有针对性的（针对一些大数据量和常用检索方式）建立组合属性的索引，提高检索效率。虽然建立索引会消耗部分系统资源，但比较起在检索时搜索
数据库设计和编码规范 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避免隐含的数据类型转换 ........................................................................................