04数据库.docx

PAGE30 / NUMPAGES30 数据库 数据库设计的三大范式：*-* 第一范式1NF：做到每列不可再拆分(数据表字段保持原子性，不可再分) 第二范式2NF：确保一个表只做一件事情 第三范式3NF：要求一个数据库表中不包含已在其它表中已包含的非主关键字信息（一般使用id关联）。从而减少数据库的冗余。(在满足2NF，消除表中的传递依赖) 满足这些规范的数据库是简洁的、结构明晰的，同时，不会发生插入（insert）、删除（delete）和更新（update）操作异常。 详解 第一范式：的合理遵循需要根据系统的实际需求来定。比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市”部分，那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储，这样在对地址中某一部分操作的时候将非常方便。这样设计才算满足了数据库的第一范式，如下表所示。 create table aa(id int,NameAge varchar(100)) insert aa values(1,无限-女) 没有达到第一范式 create table aa(id int,name varcahr(10),age char(2)) insert aa values(1,无限,女) 说明：在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。 第二范式：订单信息表，因为订单中可能会有多种商品，如果把商品名称、单位、商品价格等信息存到订单表中就违反了第二范式的设计原则，应该设计成两张表，一张订单表、一张商品表。根据商品id查询出对应的商品。 假定选课关系表为SelectCourse(学号,姓名,年龄,课程名称,成绩,学分) 建表:(学号,课程名称)→(姓名,年龄,成绩,学分) 选课关系表会存在如下问题： (1)数据冗余：同一门课程由n个学生选修，学分就重复n-1次；同一个学生选修了m门课程，姓名和年龄就重复了m-1次。 (2)更新异常：若调整了某门课程的学分，数据表中所有行的学分值都要更新，否则会出现同一门课程学分不同的情况。 (3)插入异常：假设要开设一门新的课程，暂时还没有人选修。这样，由于还没有学号关键字，课程名称和学分也无法记录入数据库。 (4)删除异常：假设一批学生已经完成课程的选修，这些选修记录就应该从数据库表中删除。但是，与此同时，课程名称和学分信息也被删除了。很显然，这也会导致插入异常。 把选课关系表SelectCourse改为如下三个表： 学生：Student(学号,姓名,年龄)； 课程：Course(课程名称,学分)； 选课关系：SelectCourse(学号,课程名称,成绩)。 这样的数据库表是符合第二范式的，消除了数据冗余、更新异常、插入异常和删除异常。 第三范式：比如在设计一个订单数据表的时候，可以将客户编号作为一个外键和订单表建立相应的关系。而不可以在订单表中添加关于客户其它信息（比如姓名、所属公司等）的字段。 存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。 假定学生关系表为Student(学号,姓名,年龄,所在学院,学院地点,学院电话)，关键字为单一关键字学号，因为存在如下决定关系： (学号)→(姓名,年龄,所在学院,学院地点,学院电话) 这个数据库是符合2NF的，但是不符合3NF，因为存在如下决定关系： (学号)→(所在学院)→(学院地点,学院电话) 把学生关系表分为如下两个表： 学生：(学号,姓名,年龄,所在学院)； 学院：(学院,地点,电话)。 事务：*-* 要么全部执行成功，要么撤销不执行。通俗的理解，事务是一组原子操作单元，从数据库角度说，就是一组SQL指令，要么全部执行成功，若因为某个原因其中一条指令执行有错误，则撤销先前执行过的所有指令。 4个属性（ACID）： 原子性（atomicity）：一个事务是一个不可分割的工作单位，事务中包括的诸操作要么都做，要么都不做。 一致性（consistency）：事务结束后系统状态是一致的。一致性与原子性是密切相关的。 隔离性（isolation）：一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。 持久性（durability）：持久性也称永久性（permanence），指一个事务一旦提交，它对数据库中数据的改变就应