数据库设计

数据库设计

问题 • 数据库是怎么产生的？ • 设计的数据库与后期系统开发有关系吗？ • 设计数据库应注意些什么？ • 如何设计数据库？

数据库设计概述 • 数据库设计目的数据库是为应用程序存储数据服务，因此数据库必须能够满足应用的需求，简化应用程序的设计，维护数据完整性。 • 数据库设计概念 • 广义上数据库设计是根据信息要求、处理要求和给定的数据库的支撑环境，设计数据库及其应用程序，即指的是整个数据库应用系统。 • 侠义上设计出相应的数据模式（外模式、逻辑模式、内模式）、数据库对象，并建立数据库。

现实世界 信息世界(概念模型) 用户观点机器世界(数据模型) 机器观点数据库设计概述 • 数据模型 • 为何要定义数据模型？什么是数据模型? 因为信息系统就是要将现实中的事物采用计算机中的数据进行描述。通俗的说数据模型（Data Mode）就是对现实世界的事物的模拟。是计算机世界对现实世界进行抽象、表示和处理的工具。 • 对现实世界进行抽象的过程

数据库设计的方法 • 数据库设计的方法包括： • 新奥尔良方法需求分析、概念设计、逻辑设计和物理设计。 • 基于E-R模型的设计方法（适用于关系数据库） • 面向对象方法（适用于面向对象数据库）。构造类、构造对象等。设计工具：PowerDesigner、ERWin等数据库设计软件。

数据库设计步骤 数据库设计方法必须采用规范化的设计方法。与软件工程类似，数据库设计一般分几个阶段：需求分析、概念机构设计、逻辑结构设计、物理设计数据库实施、数据库运行和维护等几个阶段。总结：每一个阶段是下个阶段的前提和依据，同时下一层的修改会反馈到上层的修改，当物理设计确定后，才可进行数据库实施。

需求分析 • 目的需求分析是与用户进行交流，收集和分析资料，以致能够准确、详细的描述出目标系统的功能和性能要求，这是系统开发和数据库设计的重要一步。 • 方法结构化分析的方法，面向对象的分析方法等。 • 产生的文档数据流程图（DFD）、数据字典。

需求分析 • 需求分析的方法 • 获取用户需求 • 将那种以“如何实现”的表述方式转换为“实现什么”的方式，因为需求分析阶段关注的目标是“做什么”，而不是“怎么做”； • 通过建立模型的方式来描述用户的需求，为客户、用户、开发方等不同参与方提供一个交流的渠道，并检验对业务的理解。 • 需求建模的方法有很多种，最常用的包括数据流图（DFD）。DFD尤其适用于MIS系统的表述。DFD使用四种基本元素来描述系统的行为，过程、实体、数据流和数据存储。DFD方法直观易懂，使用者可以方便地得到系统的逻辑模型和物理模型。

数据流图 • 常用符号

数据流图 • VISIO符号

图书管理数据流图 • 图书管理数据流图

数据流图 • 案例—分层数据流程图绘制 • 汽车配件公司：第一层数据流程图配件库存 1 订货单订货单顾客供应商处理业务发货单发货单

向供应商的订货单 1－1 1－2 订货单订货单到货通知顾客供应商销售采购发货单发货单应付款通知收据配件库存 1－3 会计数据流图 • 汽车配件公司：第二层数据流程图

采购业务员 D3 配件库存 1.1.1 1.1.3 1.1.5 不合格不满足的订货到货通知订货单顾客产生暂存订货单确定顾客订货合格的订货单编辑订货单新顾客 1.1.2 可发订货 D4 暂存订货单顾客 D2 登录新顾客数据 1.1.4 1.1.6 对照暂存订货单开发货单并修改库存 D3 配件库存询问库存 1.1.7 1.1.8 编制销售和库存报表经理检索库存库存状态 D5 销售历史 D10 应收款明细账数据流图-第三层数据流程图

销售数据流

举例 • (1)接受顾客的订单，检验订单，若库存有货，进行供货处理，即修改库存，给仓库开备货单，并且将订单留底；若库存量不足，将缺货订单登入缺货记录。(2)根据缺货记录进行缺货统计，将缺货通知单发给采购部门，以便采购。(3)根据采购部门发来的进货通知单处理进货，即修改库存，并从缺货记录中取出缺货订单进行供货处理。(4)根据留底的订单进行销售统计，打印统计表给经理。

数据字典 • 作用数据字典是关于数据流程图内所包含的数据元素（数据存储、数据流、数据项）的定义及说明的集合。 • 内容数据字典由数据流、文件（数据存储）和数据项（数据元素）三类条目组织。 • 要求 • 完整性 • 一致性 • 可用性

数据字典 • 数据项类目：数据的最小单位，描述数据的静态特性

数据字典 • 数据流类目：由一个或一组固定的数据项组成。

数据字典 • 文件类目：描述数据的逻辑存储结构。

概念结构设计 • 目的根据需求分析的结果，综合成一个统一的概念模型，生成总体的E-R图，构建各个实体及其关系。 • 方法采用自底向上设计方法，即先定义局部的E-R图，然后将所有局部的E-R图合并成整体的E-R图。 • 步骤 • 确定实体和属性 • 分析实体间的联系类型。（勾画出局部的E-R图） • 集成初始的全局E-R图。

实体间的联系 • 实体间联系的重要性我们说实体之间不是相互独立的，它们可能存在一定的联系，如：学生与课程之间、教师与课程、分数与学生等。数据库设计最重要的就是描述实体间的联系。 • 实体型间联系的类型联系的类型包括：一对一、一对多（或多对一）、多对多。 • 多个实体间的联系实体间的联系有延续性，如若A实体与B实体有联系,B实体与C实体有联系，则A实体与C实体也有联系。

实体间联系 • 描述的方法采用E-R图（实体联系图）来描述实体间联系。 • 说明实体、属性、联系分别使用矩形、椭圆形、菱形来描述，中间标明实体名、属性名称、联系名称。注：在联系边上还必须标明联系类型。联系可以有属性？ • 属性与实体的区分现实世界的事物能够做属性对待的，尽量做属性。但作为属性时必须具备以下条件： • 作为“属性”，不能再具有需要描述的性质。 • “属性”不能与其它实体具有联系。

举例 • 图书管理系统能够完成图书馆日常操作，包括：图书管理、证件管理、图书借还等功能。则实体包括：图书、借书证件、图书借还情况。

图书管理E-R图 • 总体E-R图

图书管理E-R图 • 局部E-R图1

E-R图合并 • E-R图合并将局部E-R图集成起来，生成总的E-R图。通过合并，能够表示一个完整、一致的数据库模型。 • 要点 • 消除各种冲突 • 属性冲突相同的属性在不同的E-R图总具有不同的域 • 命名冲突实体名、属性名、联系名存在同名异义和异名同义。 • 结构冲突同一实体在不同的E-R图有不同的表示。

逻辑结构设计 • 任务将概念设计的E-R图转换成DBMS所支持的数据模型的逻辑结构。 • 主要步骤 • E-R图向关系模式的转换。 • 关系规范化处理如将上述实体转换为关系数据库的关系： Readers(Reader_id(PK),name,sex,class,app_dt,remark)

E-R图向关系模式的转换 • 转换的原则 • 实体属性的转换：实体的属性转换成关系的属性，实体的键转换成关系的键。 • 实体名的转换：实体的名可以转换成关系的名（常使用英文或拼音缩写代替）。 • 实体的联系转换：实体的联系可以考虑转换成一种关系。 • 联系的转换分以下几种情况。 • 1:1联系相连的各实体的键以及联系的属性转换成关系的属性，选择各实体的键作为该关系的候选键；或者不产生关系，采用外键的方式建立两者间的联系。

E-R图向关系模式的转换 • 1:M联系相连的各实体的键以及联系的属性转换成关系的属性，选择M端实体的键作为该关系的候选键。不产生关系，采用一端的主键作为外键的方式建立两者间的联系（要看联系是否有属性而言）。 • 举例所属书籍(book_kind(PK),book_id) 书籍(book_id(PK),name…)

E-R图向关系模式的转换 • M:N联系与该联系相连的各实体的键以及联系本身的属性均转换成为关系的属性，关系的键为各实体键的组合。借书情况(借书证号(PK)，条形码(PK)，日期)

逻辑结构设计-小节 • 每个实体最终转换为一个关系 • 实体间的联系由关系间的公共属性实现 • 对多对多联系，由独立的表来保存

关系规范化 • 关系模式及其描述方法关系名和其属性的集合称为该关系的关系模式,关系模式主要用于对一个关系的描述。其格式为：关系名（属性名1,属性名2…属性名N）如物资管理数据库的关系模式：仓库（仓库号、面积、电话号码）零件（零件号、名称、规格、单价、描述）供应商（供应商号、姓名、地址、电话号码、帐号）项目（项目号、预算、开工日期）职工（职工号、姓名、年龄、职称）

关系规范化 • 一个关系的实际应用例子教师任课关系(教师编号(PK)，教师姓名，职称，住址，所在系的编号，系名称，系地址，课程编号（PK），课程名称，教学水平，学分) • 该关系存在问题 • 数据冗余如：同在一个系的不同教师需要重复登记系信息； • 更新复杂如：当更改一个课程信息时，需更改多行记录； • 插入异常如：当没有给新来的教师安排课程时，教师记录不能登记； • 删除异常如：当删除一个课程信息时，同时将一些教师信息也删除了； • 造成的原因根本原因在于关系模式未设计好。

改进的关系模式 若将上关系模式设计成为以下关系模式：教师（教师编号(PK)，教师姓名，职称，住址，系编号）系（系编号(PK)，系名称，系地址）课程（课程号(PK)，课程名，学分）教学（教师编号(PK,FK)，课程号(PK,FK)，教学水平）说明：虽将一个关系划分成4个关系，减少了他们的密切的联系，但它们通过外键建立另一种关系，通过这种关系，仍可表达上述关系。（只要做四个表的连接，即可形成上述一个表的完整关系）

改进的关系模式 • 问题的解决 • 数据冗余数据分存在不同的关系中，存储一个关系中的数据，并不会重新存储另一些数据。 • 更新异常更新教师信息、课程信息、教学信息、系信息只需修改某个关系的数据，而无需更改过多的记录，简化了更改的处理。 • 插入异常当要插入新的教师记录、课程记录、教学记录、系记录等，只要在其中的一个关系中插入，而无需插入无关的信息（注：当表中存在外键时，仍要考虑实体参照完整性）；无需为某些数据的未知而使插入异常。（与业务流程相冲突） • 删除异常由于关系的分开，删除某种信息时，只要在一个关系做删除即可，而不会产生删除其他相关数据。

关系规范化 • 结论一个初始的关系必须经过一定的处理，使其在实际应用中能排除异常，提高效率。该种方法就是关系规范化，规范化是通过对属性进行分解的方法改善一个不好的关系模式。（规范化是低级范式的关系模式转换成高级范式的关系模式的过程）要对关系进行规范化处理，首先应了解函数依赖。

关系规范化内容导航 • 依赖概念 • 规范化 • 规范化方法

函数依赖 • 数据依赖属性间的相互依赖，相互制约的联系称为数据依赖。数据依赖有两种类型：函数依赖和多值依赖。 • 函数依赖设R(U)是属性集U上的关系模式，X,Y是U的任一个子集。当且仅当R(U)中的每个X值只与R(U)中的唯一的一个Y值相对应（也可理解成当X值被确定后，Y值也就唯一的确定了。）。则称“Y函数依赖与X”或“X函数决定Y”，记为X→Y。

函数依赖 • 完全函数依赖，部分函数依赖完全函数依赖是指依赖与组合属性的全部，而不是它的部分。其具体定义为：设X→Y是关系模式R中的一个函数依赖，并且对于X中的任何一个真子集X’，都有X’ －/→Y，则称Y完全函数依赖于X，记做X→fY。反之若X→Y，但Y不完全依赖于X，则称Y对X部分函数依赖，记做X→pY。 • 举例教师→职称课程编号－/→ 教学水平

函数依赖 • 传递函数依赖 • 定义在关系模式R(U)中，如果存在X→Y(Y不是X的子集)，Y→Z，且Y－/→X，则称Z对X传递依赖，或Z传递依赖于X。 • 举例系名称传递依赖于教师编号

关系规范化 • 关系规范化将关系模式从低级范式向高级范式分解的过程。 • 范式(Normal Form) 满足某种级别要求的关系模式集合。 • 级别 1NF2NF3NFBCNF4NF5NF。 • 策略概念单一化：一个关系模式表示一个概念，一个实体，一个实体间联系；多余部分分解出去。

第一范式 • INF(第一范式) • 定义在关系范式中的每一个具体的关系R中，如果每个属性值都是不可分的基本数据项（也称为原子项），则称R满足第一范式的关系，记为R∈1NF。（理解：关系中的每个属性值没有多个项） • 下面R为非1NF（非规范关系模式）：

第一范式 • 转换将非1NF1NF • 去掉嵌套属性上层 • 重写行交叉处的值 • 存在问题如左边R1为1NF，存在冗余，修改麻烦，操作异常问题。

第一范式 • 原因非主属性部分依赖于候选码。 R1中：候选码：（XH,KH）,(XH,KM) 非主属性：XM,DZ,CJ ∵KH→KM ，XH→XM ∴（XH,KH）部分决定XM （XH,KH）部分决定DZ • 解决方法采用投影分解消去非主属性对候选码的部分依赖 1)满足完全fd的属性组成一个关系模式R2； 2)满足部分fd的属性组成一个关系模式R3。

改进 R2 R3

效果 • 效果 1）冗余减少多一个KH（三个分量值）；选同一课程的KM，XM，DZ仅出现一次。 2）避免了原修改麻烦 OS换教师、修改R3中一个元组。 3）避免了原插入异常新开课程无人选修仍可插入到DB中（R3）。 4）避免了原删除异常删除学生信息在R2中进行，R3中的课程、教师数据不受影响。

第二范式 • 第二范式(2NF) 任给R（U，F），若R∈1NF，且其每个非主属性都完全依赖于候选码，则R∈2NF。 1)R2 候选码：（XM，KH）非主属性：CJ 依赖：（XH,KH）CJ ∴R2∈2NF 2)R3 候选码：KH，KM 非主属性：XM，DZ 依赖：KHXM, KHKZ,KMXM,KMDZ ∴根据定义：R3∈2NF

数据库设计

数据库设计

Presentation Transcript