1.1跟我学软件系统概要设计中所涉及的数据库设计及相关的示例（第1部分）1.1.1软件系统的数据库设计1、什么是数据库设计数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。
2、数据库设计的五个步骤1)数据库需求分析（从而获得数据流图和数据字典）2)概念模型设计（根据数据流图和数据字典建立ER图）3)逻辑设计（根据ER图获得关系模式及表结构的设计）4)物理设计（实施物理数据模型---数据库关系表的物理设计等）5)加载测试我们的物理数据库。
3、数据库设计的五个步骤的说明（1）数据库需求分析1)需求收集和分析，结果得到数据字典描述的数据需求（和数据流图描述的处理需求）。
需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。
2)其主要的任务是将业务管理转化为数据流，划分主题之间的边界，绘制出DFD图，并完成相应的数据字典——定义应用程序中使用的所有数据元素和结构的含义、类型、数据大小、格式、度量3)单位、精度以及允许取值范围的共享仓库。
（2）概念模型设计1)通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型，可以用E-R图表示。
2)概念模型用于信息世界的建模概念模型不依赖于某一个DBMS支持的数据模型。
概念模型可以转换为计算机上某一DBMS支持的特定数据模型。
●主要的任务是从DFD出发，绘制出本主题的实体－关系图，并列出各个实体与关系的纲要表。
在概念设计阶段中，设计人员从用户的角度看待数据及处理要求和约束，产生一个反映用户观点的概念模式。
然后再把概念模式转换成逻辑模式。
（3）逻辑设计（关系模式及表结构的设计）●主要的任务是从E-R图与对应的纲要表出发，确定各个实体及关系的表名属性。
●把ER图转化为关系模式的过程并对其进行优化由于概念设计的结果是ER图，DBMS一般采用关系型，因此数据库的逻辑设计过程就是把ER图转化为关系模式的过程并对其进行优化。
将E-R图转换为关系模型实际上就是要将实体、实体的属性和实体之间的联系转化为关系模式●数据完整性设计（4）物理设计（数据库关系表设计）1)为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）。
根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。
2)其主要的任务是确定所有属性的类型、宽度与取值范围，设计出基本表的主键，将所有的表名与字段名英文化，实现物理建库，完成数据库物理设计字典（5）加载测试该工作应该贯穿于程序测试工作的全过程，整个录入、修改、查询、处理工作均可视为对数据库的加载测试工作。
数据库应用系统经过试运行后即可投入正式运行。
在数据库系统运行过程中必须不断地对其进行评价、调整与修改。
包括：数据库的转储和恢复、数据库的安全性、完整性控制、数据库性能的监督、分析和改进、数据库的重组织和重构造。
4、如何实现对数据库表的结构进行设计？----先设计好对象/类图，然后再设计数据库表（1）根据实体域对象的属性获得表结构中各个字段类型一般是根据项目中的域建模，获得各个实体域对象，同时再根据对每个实体域对象的数据抽象获得其属性，据此作为数据库表结构设计的基本依据；（2）建立出表结构再进行数据内部以及外在关系的分析（数据的属性和关系），从而有效地建立整个系统的数据结构（在关系数据库中通常称为表结构）。
（3）最后，把各种信息用不同的表来存储。
5、设计的一般原则（1）适当冗余减少数据库冗余的设计思路产生于70年代,它是促使 DBMS 进步的重要动力之一。
然而,犹如为了节省2个字节的存储空间而酿成了如今全球为之头痛的2000年问题一样,它是计算机硬件主导时代的产物。
以今天国内计算机市场价格为例,服务器的内存和硬盘的价格非常便宜，有适当的冗余并没有什么关系。
因为今天的世界已进入软件主导的计算机时代。
因此,最容易理解、应用开发工作量最少、维护最简单的数据库结构才是最好的。
只要数据完整性、一致性不受威胁,有些冗余,不足为虑。
换言之,最节省软件成本 (而不是硬件成本) 的是最好的-----适当增加冗余，达到以空间换时间的目的。
某个商品表的表结构商品名称商品型号单价数量金额电视机29吋2,500 40 100,000在上面的商品信息表中“金额”这个字段的存在，表明该表的设计有冗余字段（即不满足第三范式），因为“金额”可以由“单价”乘以“数量”得到，说明“金额”是冗余字段。
但是，我们增加“金额”这个冗余字段，主要的目的是提高查询统计的速度，这就是以空间换时间的作法。
下面为关于空间与时间的协调问题的示例：一个电子购物网站，是任何人都可以访问的，因此门户的访问量是很庞大的。
如今，存储空间已经基本不是问题，而如何尽可能提高访问速度才是最重要的。
因此，在进行数据库设计的时候，并没有严格的遵循范式的规范，一些频繁应用的字段有冗余的情况发生。
如：由于系统中涉及到发货仓库，省网商品可见性等因素，省公司代码（province_code）这个字段是频繁应用的。
因此，数据库设计时，使合作商信息表（partner_info），用户信息表（user_info），用户收藏商品表（user_collect_ware_info）等多个表中都出现了该字段。
（2）信息隐蔽并使数据库黑盒化 (透明度高)这是软件工程最重要的基本原则之一。
简言之即信息的作用域越小越好,数据库的透明度越大越好,因为应用程序需要知道得越多就越复杂。
使数据库黑盒化 (透明度高) 的方法很多,除了设计上的局部化处理外,还可以利用DBMS 的触发器、存储过程、函数等,把数据库中无法简化的复杂表关系封装到黑盒子里,隐藏起来,特别是对于服务器端的应用,其优越性更是多方面的。
1.1.2数据库设计的范式1、范式----都应满足一定的规范(约束条件)构造数据库必须遵循一定的规则。
在关系数据库中，这种规则就是范式。
范式是符合某一种级别的关系模式的集合。
关系数据库中的关系必须满足一定的要求，即满足不同的范式。
目前关系数据库有六种范式：1)第一范式（1NF）2)第二范式（2NF）3)第三范式（3NF）4)第四范式（4NF）5)第五范式（5NF）6)第六范式（6NF）满足最低要求的范式是第一范式（1NF）。
在第一范式的基础上进一步满足更多要求的称为第二范式（2NF），其余范式以次类推。
一般说来，数据库只需满足到第三范式（3NF）就行了----通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。
1)第一范式：1NF是对属性的原子性约束，要求属性具有原子性，不可再分解；2)第二范式：2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性；3)第三范式：3NF是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余。
2、第一范式（1NF）----满足最低要求的一级在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。
在第一范式（1NF）中表的每一行只包含一个实例的信息。
例如，对于员工信息表，不能将员工信息都放在一列中显示，也不能将其中的两列或多列在一列中显示；员工信息表的每一行只表示一个员工的信息，一个员工的信息在表中只出现一次。
简而言之，第一范式就是无重复的列。
如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。
在数据库表中应该提供主键，主键的存在就代表着表结构的完整性，表的记录应该有唯一区分的字段；另外，主键还可以用于其它表的外键关联，本记录的修改与删除。
当我们没有主键时，这些操作会变的非常麻烦。
3、第二范式（2NF）第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。
第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。
为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。
如员工信息表中加上了员工编号（emp_id）列，因为每个员工的员工编号是惟一的，因此每个员工可以被惟一区分。
这个惟一属性列被称为主关键字或主键。
第二范式（2NF）要求实体的属性完全依赖于主关键字。
所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。
为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。
简而言之，第二范式就是非主属性非部分依赖于主关键字。
4、第三范式（3NF）满足第三范式（3NF）必须先满足第二范式（2NF）。
简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。
例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。
那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。
如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。
简而言之，第三范式就是属性不依赖于其它非主属性。
5、数据库表的主键设计要点一般而言，一个数据库表不能既无主键又无外键。
并且主键与外键的配对，表示实体之间的连接。
（1）不要使用业务本身的数据作为Primary Key----比如身份证号码，公司编号等等早期的数据库系统，经常采用某种编号，比如身份证号码，公司编号等等作为数据库表的 primary key。
然而，很快，大家就发现其中的不利之处。
比如早期的医院管理系统，用身份证号码作为病人表的 primary key。
然而，第一，不是每个人都有身份证；第二，对于国外来的病人，不同国家的病人的证件号码并不见得没有重复-----因此，用身份证号码作为病人表的 primary key是一个非常糟糕的设计。
公司编号采用某种特定的编码方法，这也是早期的数据库系统常见的做法。
它的缺点也显而易见：很容易出现像千年虫的软件问题，因为当初设计数据库表的时候设计的位数太短，导致系统使用几年后不能满足要求，只有修改程序才能继续使用。
问题在于，任何人设计系统的时候，在预计某某编号多少位可以够用的时候，都存在预计不准的风险。
（2）采用自动递增（自增长）Primary key----可以提高性能使用自增长 primary key另外一个原因是性能问题。
略有编程常识的人都知道，数字大小比较比字符串大小比较要快得多。
