第一章数据库及设计.pptVIP

表设计后，很可能结构不合理，出现数据重复保存，简称数据的冗余，这对数据的增删改查带来很多后患，所以我们需要审核是否合理，就想施工图设计后，还需要其他机构进行审核图纸是否设计合理一样。 如何审核呢？需要一些有关数据库设计的理论指导规则，这些规则业界简称数据库的范式。 relational database management system 　　关系型数据库管理系统 讲解每个范式的含义：关键是说明范式的目的，这样规定有什么好处。 为了算帐统计方便，会计可能喜欢这样设计表格，如幻灯片所示。 讲解目前这些表格可能出现的问题，可以采用提问方式。 我们根据三大范式，逐一审核是否规范化。 提问学员： 1.第一范式满足吗，引导回答：基本满足； 2.第二范式满足吗？第二范式要求表中的列必须与主键列相关，也就是要求一张表只能描述一件事情。 我们一起看看这张表描述了哪些事情？让学员思考几分钟，然后提问，最后归纳出如下事情： 1）工程信息 2）员工信息 3）项目的工时信息（每个工人做了多少活儿） 所以根据第二范式，拆分出了这些表。 提问学员：这些表满足第三范式吗？ 引导：员工表还需拆分，存在传递依赖关系，即小时工资率和职务有关，职务又和人有关， 最后传递后，小时工资率看起来就和姓名有关了。小时工资率和职务才之间相关，我们需要应用第三 范式做进一步拆分。 告诉学员，数据库的三大范式和数据库的性能有时是矛盾的。 打个比方：大家都知道，环境保护非常重要，西方总是拿环保问题和中国刁难， 说中国为了发展不顾环境保护、生态自然等。可中国目前的经济实力不够强大，如果人都吃不饱， 空谈环保还有什么用呢？所以我们只能是在保持地区经济发展的前提下，尽量注重环保问题。 这就是一种折中处理问题的典型。 本例同样如此：为了满足三大范式，我们在规范化表格时就会拆分出越来越明细的表格。 但客户喜欢综合的信息，为了满足客户，我们又需要把这些表同过连接查询还原为客户喜欢的综合数据。 这和从一张表中读出数据相比，大大影响了数据库的查询性能。 所以有时为了性能，需要做适当折中，适当牺牲规范化的要求，来提高数据库的性能。 再如：在成绩表中添加一列－“成绩总分”，属于数据冗余，因为总分在查询时可由各门成绩求出来。 但频繁查询成绩总分，并希望保存下来，所以有时表中就干脆添加总分这一列。 总结： 方式多样，例如：可以指定某些睡觉的学员总结，随机抽号总结，集体总结，调动课堂氛围。 第一范式 (1st NF) 第一范式的目标是确保每列的原子性 如果每列都是不可再分的最小数据单元（也称为最小的原子单元），则满足第一范式（1NF） * BuyerID Country City 1 1 4 2 中国 中国 日本 美国 北京 北京 东京 纽约 … … … BuyerID Address 1 2 3 4 中国北京市 美国纽约市 英国利物浦 日本东京市 … … 第一范式 (1st NF) 在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。 所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。 如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。 在第一范式（1NF）中表的每一行只包含一个实例的信息。 例如，对于员工信息表，不能将员工信息都放在一列中显示，也不能将其中的两列或多列在一列中显示；员工信息表的每一行只表示一个员工的信息，一个员工的信息在表中只出现一次。 简而言之，第一范式就是无重复的列。 * 第二范式 (2nd NF) 如果一个关系满足1NF，并且除了主键以外的其他列，都依赖与该主键，则满足第二范式（2NF） 第二范式要求每个表只描述一件事情 * Orders 字　段 例　子 订单编号 产品编号 订购日期 价 格 001 A001 2000-2-3 $29.00 … … Orders 字　段 例　子 订单编号 订购日期 001 2000-2-3 Products 字　段 例　子 产品编号 价 格 A001 $29.00 第二范式 (2nd NF) 第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。 第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。如员工信息表中加上了员工编号（emp_id）列，因为每个员工的员工编号是惟一的，因此每个员工可以被惟一区分。这个惟一属性列被称为主关键字或主键