第7章 数据库设计
为什么需要设计数据库？ 修建茅屋需要设计吗？ 修建大厦需要设计吗？ 结论：当数据库比较复杂时我们需要设计数据库
为什么需要设计数据库？ 良好的数据库设计： 糟糕的数据库设计： 节省数据的存储空间 能够保证数据的完整性 方便进行数据库应用系统的开发 数据冗余、存储空间浪费 内存空间浪费 数据更新和插入的异常
什么是数据库设计 数据库设计是指对于一个给定的应用环境，构造（设计）优化的数据库逻辑模式和物理结构，并据此建立数据库及其应用系统，使之能够有效地存储和管理数据，满足各种用户的应用需求，包括信息管理要求和数据操作要求。 目标：为用户和各种应用系统提供一个信息基础设施和高效率的运行环境
数据库设计专业人员应具备哪些知识？ 数据库的基本知识和数据库设计技术 计算机科学的基础知识和程序设计的方法和技巧 软件工程的原理和方法 应用领域的知识
数据库设计方法 手工试凑法 设计质量与设计人员的经验和水平有直接关系 缺乏科学理论和工程方法的支持，工程的质量难以保证 数据库运行一段时间后常常又不同程度地发现各种问题，增加了维护代价
数据库设计方法 规范设计法 计算机辅助设计 手工设计方法 基本思想：过程迭代和逐步求精 典型方法 ORACLE Designer 2000 新奥尔良（New Orleans）方法 将数据库设计分为四个阶段 基于E-R模型的数据库设计方法 概念设计阶段广泛采用 3NF（第三范式）的设计方法 逻辑阶段可采用的有效方法 ODL（Object Definition Language）方法 面向对象的数据库设计方法 计算机辅助设计 ORACLE Designer 2000 SYBASE PowerDesigner
良构设计的目标 数据库支持设定的和实时的信息提取。数据库必须存储必要的信息，支持在设计时确定的信息需求，并支持用户可能提出的实时查询。 表应当正确、有效地构造。数据库中的每个表都代表一个主题，由一些相关的字段组成，数据的冗余度尽可能小，并且在整个数据库中通过一个具有唯一值的字段表示。 数据的完整性强加在字段、表和关系级。这些完整性帮助确保数据结构和它们的值始终是有效的和正确的。 数据库支持与组织机构有关的业务规则。数据必须提供合法和正确的信息，这些信息对于企业总是有意义的。 数据库支持未来的增长。随着企业的信息需求的变化和增长，数据库的结构应当易于修改和扩充。
开发周期 需求分析阶段：分析客户的业务和数据处理需求; 概要设计阶段：设计数据库的E-R模型图，确认需求信息的正确和完整; 现实世界 信息世界 数据库世界 建模 模型转换 规范化 需求分析阶段：分析客户的业务和数据处理需求; 概要设计阶段：设计数据库的E-R模型图，确认需求信息的正确和完整; 详细设计阶段：将E-R图转换为多张表，进行逻辑设计，并应用数据库设计的三大范式进行审核； 代码编写阶段：选择具体数据库进行物理实现; 软件测试阶段：…… 安装部署：……
数据库设计的基本步骤 需求分析 概念结构设计 逻辑结构设计 物理结构设计 数据库实施 数据库运行和维护 数据库设计分6个阶段 需求分析和概念设计独立于任何数据库管理系统 逻辑设计和物理设计与选用的DBMS密切相关
数据库设计准备工作 准备工作： 选定参加设计的人 1. 数据库分析设计人员 数据库设计的核心人员 3. 程序员 自始至终参与数据库设计 其水平决定了数据库系统的质量 2.用户 在数据库设计中也是举足轻重的 主要参加需求分析和数据库的运行维护 用户积极参与带来的好处 加速数据库设计 提高数据库设计的质量 3. 程序员 在系统实施阶段参与进来，负责编制程序 4. 操作员 在系统实施阶段参与进来，准备软硬件环境
准确了解与分析用户需求（包括数据与处理） 是整个设计过程的基础，是最困难、最耗费时间的一步 是整个数据库设计的关键 需求分析阶段 准确了解与分析用户需求（包括数据与处理） 是整个设计过程的基础，是最困难、最耗费时间的一步 概念结构设计阶段 是整个数据库设计的关键 通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型 逻辑结构设计阶段 将概念结构转换为某个DBMS所支持的数据模型 对其进行优化 数据库物理设计阶段 为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法） 数据库实施阶段 运用DBMS提供的数据语言、工具及宿主语言，根据逻辑设计和物理设计的结果 建立数据库 编制与调试应用程序 组织数据入库 并进行试运行
An Introduction to Database System 数据库设计过程中的各级模式 数据库设计不同阶段形成的数据库各级模式 数据库的各级模式 An Introduction to Database System
需求分析-任务 需求分析就是分析用户的需要与要求 需求分析的任务 需求分析是设计数据库的起点与难点 需求分析的结果是否准确地反映了用户的实际要求，将直接影响到后面各个阶段的设计，并影响到设计结果是否合理和实用 需求分析的任务 通过详细调查现实世界要处理的对象（组织、部门、企业等），充分了解原系统（手工系统或计算机系统）工作概况，明确用户的各种需求，在此基础上确定新系统的功能。新系统必须充分考虑今后可能的扩充和改变，不能仅仅按当前应用需求来设计数据库。
需求分析-重点 调查的重点是“数据”和“处理”，获得用户对数据库要求 信息要求 处理要求 安全性与完整性要求
需求分析-难点 确定用户最终需求 用户缺少计算机知识 设计人员缺少用户的专业知识 解决方法 设计人员必须不断深入地与用户进行交流
需求分析-方法 调查清楚用户的实际需求并进行初步分析 与用户达成共识 进一步分析与表达这些需求
需求分析-调查步骤 ⑴ 调查组织机构情况 ⑵ 调查各部门的业务活动情况。（调查重点之一） ⑶ 在熟悉业务活动的基础上，协助用户明确对新系统的各种要求。（调查重点之二） ⑷ 确定新系统的边界
需求分析-调查方法 做需求调查时，往往需要同时采用多种方法 常用调查方法 无论使用何种调查方法，都必须有用户的积极参与和配合 设计人员应该和用户取得共同的语言，帮助不熟悉计算机的用户建立数据库环境下的共同概念，并对设计工作的最后结果共同承担责任 常用调查方法 ⑴跟班作业 ⑵开调查会 ⑶请专人介绍 ⑷询问 ⑸设计调查表请用户填写 ⑹查阅记录
需求分析-分析方法 自顶向下的结构化分析方法（Structured Analysis，简称SA方法） 分析和表达用户的需求的常用方法
需求分析-分析方法-DFD 1. 首先把任何一个系统都抽象为： 2．分解处理功能和数据 （1）分解处理功能 1. 首先把任何一个系统都抽象为： 2．分解处理功能和数据 （1）分解处理功能 将处理功能的具体内容分解为若干子功能，再将每个子功能继续分解，直到把系统的工作过程表达清楚为止。 （2）分解数据 在处理功能逐步分解的同时，其所用的数据也逐级分解，形成若干层次的数据流图 （3）表达方法 处理逻辑：用判定表或判定树来描述 数据：用数据字典来描述 3．将分析结果再次提交给用户，征得用户的认可 信息要求 处理要求
需求分析-分析方法-DFD举例
需求分析-分析方法-数据字典 数据字典的用途 是各类数据描述的集合 进行详细的数据收集和数据分析所获得的主要结果 数据字典的内容 数据项：不可两分的数据单位 数据结构：反映数据之间的组合关系，由若干数据项构成 数据流：数据结构在系统内部传输的路径 数据存储：数据的来源或去向 处理过程：具体处理逻辑
需求分析-分析方法-数据字典 各项的描述： 数据依赖 各项的描述： 数据项描述 = {数据项名，数据项含义说明，别名，数据类型，长度，取值范围，取值含义，与其它数据项的逻辑关系，数据项之间的联系} 数据结构描述 = {数据结构名，含义说明，组成：{数据项或数据结构}} 数据流描述 = {数据流名，说明，数据流来源，数据流去向，组成：{数据结构}，平均流量，高峰期流量} 数据存储描述 = {数据存储名，说明，编号，输入的数据流，输出的数据流，组成：{数据结构}，数据量，存取频度，存取方式} 处理过程描述 = {处理过程名，说明，输入：{数据流}，输出：{数据流}，处理：{简要说明}} 数据完整性约束 数据完整性约束
需求分析-分析方法-数据字典 例：学生学籍管理子系统的数据字典。 数据项，以“学号”为例： 数据项名：学号 含义说明：唯一标识每个学生 别名： 学生编号 类型： 字符型 长度： 8 取值范围：00000000至99999999 取值含义：前两位标别该学生所在年级， 后六位按顺序编号 与其他数据项的逻辑关系：
需求分析-分析方法-数据字典 例：学生学籍管理子系统的数据字典。 数据结构，以“学生”为例 “学生”是该系统中的一个核心数据结构： 例：学生学籍管理子系统的数据字典。 数据结构，以“学生”为例 “学生”是该系统中的一个核心数据结构： 数据结构：学生 含义说明：是学籍管理子系统的主体数据结构， 定义了一个学生的有关信息 组成： 学号，姓名，性别，年龄，所在系，年级
需求分析-分析方法-数据字典 例：学生学籍管理子系统的数据字典。 数据流，“体检结果”可如下描述： 数据流： 体检结果 数据流： 体检结果 说明： 学生参加体格检查的最终结果 数据流来源：体检 数据流去向：批准 组成： …… 平均流量： …… 高峰期流量：……
需求分析-分析方法-数据字典 例：学生学籍管理子系统的数据字典。 数据存储，“学生登记表”可如下描述： 数据存储： 学生登记表 数据存储： 学生登记表 说明： 记录学生的基本情况 流入数据流：…… 流出数据流：…… 组成： …… 数据量： 每年3000张 存取方式： 随机存取
需求分析-分析方法-数据字典 例：学生学籍管理子系统的数据字典。 处理过程，“分配宿舍”可如下描述： 处理过程：分配宿舍 说明： 为所有新生分配学生宿舍 输入： 学生，宿舍 输出： 宿舍安排 处理： 在新生报到后，为所有新生分配学生宿舍。 要求同一间宿舍只能安排同一性别的学生， 一个学生只能安排在一个宿舍中。 每个宿舍安排4-6名学生。 安排新生宿舍其处理时间应不超过15分钟
需求分析-分析方法-数据字典 数据字典是关于数据库中数据的描述，是元数据，而不是数据本身 数据字典在需求分析阶段建立，在数据库设计过程中不断修改、充实、完善
需求分析-小结 设计人员应充分考虑到可能的扩充和改变，使设计易于更改，系统易于扩充 必须强调用户的参与
概念结构设计 需求分析阶段描述的用户应用需求是现实世界的具体需求 将需求分析得到的用户需求抽象为信息结构即概念模型的过程就是概念结构设计 概念结构是各种数据模型的共同基础，它比数据模型更独立于机器、更抽象，从而更加稳定。 概念结构设计是整个数据库设计的关键 现实世界 机器世界 信息世界 需求分析 概念结构设计
概念结构设计 概念结构设计的特点 描述概念模型的工具 能真实、充分地反映现实世界 易于理解 易于更改 易于向关系、网状、层次等各种数据模型转换 描述概念模型的工具 E-R模型
概念结构设计-方法 设计概念结构的四类方法 自顶向下 首先定义全局概念结构的框架，然后逐步细化
概念结构设计-方法 自底向上 首先定义各局部应用的概念结构，然后将它们集成起来，得到全局概念结构
概念结构设计-方法 逐步扩张 首先定义最重要的核心概念结构，然后向外扩充，以滚雪球的方式逐步生成其他概念结构，直至总体概念结构
概念结构设计-方法 混合策略 将自顶向下和自底向上相结合，用自顶向下策略设计一个全局概念结构的框架，以它为骨架集成由自底向上策略中设计的各局部概念结构。
概念结构设计-方法 常用策略 自顶向下地进行需求分析 自底向上地设计概念结构
概念结构设计-方法 自底向上设计概念结构的步骤 第1步：抽象数据并设计局部视图 第2步：集成局部视图，得到全局概念结构
概念结构设计-数据抽象与局部视图 数据抽象 三类抽象 抽象是对实际的人、物、事和概念中抽取所关心的共同特性，忽略非本质的细节，并把这些特性用各种概念精确地加以描述。 概念结构是对现实世界的一种抽象。 三类抽象 分类 聚集 概括
概念结构设计-数据抽象与局部视图 分类 将一类具有共同特性和行为的对象定义为一种某类型，在E-R模型中的实体型就是这种抽象，如学生，课程 抽象了对象的值和型之间“is member of”语义 学生 “is member of” 张英 王平 赵斌 实体型 课程 C语言 数据库 操作系统
概念结构设计-数据抽象与局部视图 聚集 定义某类型的组成成分，对应E-R模型中实体的属性 抽象了对象类型和其成分之间的“is part of”语义 学生 学号 姓名 专业 班级 仓库号 面积 主任 仓库 年龄 性别 工资 “is part of” 实体型 属性
概念结构设计-数据抽象与局部视图 概括 定义类型之间的子集联系，形成超(父)类、子类 抽象了类型之间“is subset of”语义 概括的重要性质：继承，即子类集成超类的所有抽象 是E-R模型的抽象机制的扩充 学生 本科生 研究生 概括的E-R表示 “is subset of” 超类 子类 学号, 姓名, 性别, 年龄 专业， 综合排名 导师， 研究方向
概念结构设计-第一步 利用抽象机制，对需求分析阶段收集到的数据进行分类、组织（聚集） 形成实体，实体的属性，标识实体的码，确定实体间的联系类型 设计局部E-R图 ⒈选择局部应用 ⒉逐一设计分E-R图
概念结构设计-设计局部E-R图1 选择局部应用 需求分析阶段形成多层数据流图和数据字典
概念结构设计-设计局部E-R图2 逐一设计分E-R图(确定实体、属性与联系) 数据字典是进行ER设计的主要依据 从数据字典中抽取与每个局部应用相关的数据 参照数据流图，标定局部应用中的实体、实体的属性、标识实体的码 确定实体之间的联系及其类型（1:1、1:n、m:n）。 数据字典是进行ER设计的主要依据 用户需求说明也是确定实体、属性及联系重要参考：名词通常指实体或属性，动词则主要指联系。
概念结构设计-设计局部E-R图2 例如：课程管理的需求说明 各二级学院根据各专业的人才培养方案与课程信息确定开设课程，并安排任课教师；教务处再根据教学资源（教室）安排学校总课表，形成课表信息；最后学生根据学校公布的开课信息来选课，形成选课信息，生成学生个人课表。学生学习某门课程通过考核取得成绩。 实体：二级学院、专业、课程、教师、教室、学生 联系：确定、安排、选课
概念结构设计-设计局部E-R图2 关于实体与属性的两条准则： 遵照简单原则 关于实体与属性的两条准则： （1）属性不能再具有需要描述的性质。即属性必须是不可分的数据项，不能再由另一些属性组成 （2）属性不能与其他实体具有联系。联系只发生在实体之间
An Introduction to Database System 概念结构设计-设计局部E-R图 职称作为一个实体 An Introduction to Database System
An Introduction to Database System 概念结构设计-设计局部E-R图 病房作为一个实体 An Introduction to Database System
An Introduction to Database System 概念结构设计-设计局部E-R图 仓库作为一个实体 An Introduction to Database System
An Introduction to Database System 概念结构设计-设计局部E-R图例 ［实例］销售管理子系统分E-R图的设计 销售管理子系统的主要功能： 处理顾客和销售员送来的订单 工厂是根据订货安排生产的 交出货物同时开出发票 收到顾客付款后，根据发票存根和信贷情况进行应收款处理 An Introduction to Database System
An Introduction to Database System 概念结构设计-设计局部E-R图例 下图是第一层数据流图，虚线部分划出了系统边界 An Introduction to Database System 图7.18 销售管理子系统第一层数据流图
An Introduction to Database System 概念结构设计-设计局部E-R图例 上图中把系统功能又分为4个子系统，下面四个图是第二层数据流图 An Introduction to Database System 图7.19 接收订单
An Introduction to Database System 概念结构设计-设计局部E-R图例 图7.20 处理订单 An Introduction to Database System
An Introduction to Database System 概念结构设计-设计局部E-R图例 图7.21 开发票 An Introduction to Database System
An Introduction to Database System 概念结构设计-设计局部E-R图例 图7.22 支付过账 An Introduction to Database System
An Introduction to Database System 概念结构设计-设计局部E-R图例 分E-R图的框架 An Introduction to Database System
An Introduction to Database System 概念结构设计-设计局部E-R图例 参照第二层数据流图和数据字典，遵循两个准则，进行如下调整： (1) 订单与订单细节是1∶n的联系 (2) 原订单和产品的联系实际上是订单细节和产品的联系。 (3) 图7.21中“发票主清单”是一个数据存储，不必作为实体加入分E-R图 (4) 工厂对大宗订货给予优惠 An Introduction to Database System
An Introduction to Database System 概念结构设计-设计局部E-R图例 得到分E-R图如下图所示 销售管理子系统的分E-R图 An Introduction to Database System
An Introduction to Database System 概念结构设计-设计局部E-R图例 对每个实体定义的属性如下： 顾客：{顾客号，顾客名，地址，电话，信贷状况，账目余额} 订单：{订单号，顾客号，订货项数，订货日期，交货日期，工种号，生产地点} 订单细则：{订单号，细则号，零件号，订货数，金额} 应收账款：{顾客号，订单号，发票号，应收金额，支付日期，支付金额，当前余额，货款限额} 产品描述：{零件号，零件名，单价，重量} 折扣规则：{产品号，订货量，折扣} An Introduction to Database System
概念结构设计-设计局部E-R图例 学生选课局部
概念结构设计-设计局部E-R图例 教师任课局部
An Introduction to Database System 概念结构设计-E-R图集成 各个局部视图即分E-R图建立好后，还需要对它们进行合并，集成为一个整体的数据概念结构即总E-R图。 An Introduction to Database System
An Introduction to Database System 视图集成的两种方式 多个分E-R图一次集成 一次集成多个分E-R图 通常用于局部视图比较简单时 An Introduction to Database System
An Introduction to Database System 概念结构设计-E-R图集成 逐步集成 用累加的方式一次集成两个分E-R图 An Introduction to Database System
An Introduction to Database System 概念结构设计-E-R图集成 集成局部E-R图的步骤 合并 修改与重构 An Introduction to Database System
An Introduction to Database System 合并分E-R图，生成初步E-R图 各分E-R图存在冲突 各个分E-R图之间必定会存在许多不一致的地方 合并分E-R图的主要工作与关键 合理消除各分E-R图的冲突 属性冲突 命名冲突 结构冲突 An Introduction to Database System
An Introduction to Database System ⒈ 属性冲突 两类属性冲突 属性域冲突 属性值的类型 取值范围 取值集合不同 属性取值单位冲突 An Introduction to Database System
An Introduction to Database System ⒉ 命名冲突 两类命名冲突 同名异义：不同意义的对象在不同的局部应用中具有相同的名字 异名同义（一义多名）：同一意义的对象在不同的局部应用中具有不同的名字 An Introduction to Database System
An Introduction to Database System ⒊ 结构冲突 三类结构冲突 同一对象在不同应用中具有不同的抽象 同一实体在不同分E-R图中所包含的属性个数和属性排列次序不完全相同 实体之间的联系在不同局部视图中呈现不同的类型 An Introduction to Database System
An Introduction to Database System 消除不必要的冗余，设计基本E-R图 基本任务 消除不必要的冗余，设计生成基本E-R图 合并 初步E-R图 分E-R图 可能存在冗余的数据 和冗余的实体间联系 基本E-R图 消除不必要的冗余 An Introduction to Database System
消除不必要的冗余，设计基本E-R图（续） 冗余的数据是指可由基本数据导出的数据 冗余的联系是指可由其他联系导出的联系 冗余数据和冗余联系容易破坏数据库的完整性，给数据库维护增加困难 消除冗余的方法 以数据字典和数据流图为依据 根据数据字典中关于数据项之间的逻辑关系 An Introduction to Database System
An Introduction to Database System 消除冗余的方法（续） 消除冗余 An Introduction to Database System
An Introduction to Database System 消除冗余的方法（续） 效率VS冗余信息 需要根据用户的整体需求来确定 若人为地保留了一些冗余数据，则应把数据字典中数据关联的说明作为完整性约束条件 Q4=∑Q5 一旦Q5修改后就应当触发完整性检查，对Q4进行修改 An Introduction to Database System
An Introduction to Database System 消除冗余的方法（续） 规范化理论 函数依赖的概念提供了消除冗余联系的形式化工具 An Introduction to Database System
An Introduction to Database System 消除冗余的方法（续） 规范化理论 函数依赖的概念提供了消除冗余联系的形式化工具 1. 确定分E-R图实体之间的数据依赖 ，并用实体码之间的函数依赖表示。 An Introduction to Database System 劳动人事管理的分E-R图
An Introduction to Database System 消除冗余的方法（续） 上图中， 部门和职工之间一对多的联系可表示为： 职工号→部门号 职工和产品之间多对多的联系可表示为： （职工号，产品号）→工作天数 得到函数依赖集FL An Introduction to Database System
An Introduction to Database System 消除冗余的方法（续） 2. 求FL的最小覆盖GL ，差集为D = FL-GL。 逐一考察D中的函数依赖，确定是否是冗余的联系，若是，就把它去掉。 (1) 冗余的联系一定在D中，而D中的联系不一定是冗余的； (2) 当实体之间存在多种联系时要将实体之间的联系在形式上加以区分。 An Introduction to Database System
An Introduction to Database System 支持的数据模型，它是各种数据模型的共同基础，因而比数据模型更一般、更抽象、更接近现实世界。 消除冗余，设计生成基本E-R图实例 ［实例］ 某工厂管理信息系统的视图集成 书中图1.14(c)、图7.24、图7.29分别为该厂物资、销售和劳动人事管理的分E-R图 图7.30为该系统的基本E-R图 An Introduction to Database System
消除冗余，设计生成基本E-R图实例（续） 支持的数据模型，它是各种数据模型的共同基础，因而比数据模型更一般、更抽象、更接近现实世界。 消除冗余，设计生成基本E-R图实例（续） 该厂物资管理分E-R图 图1.14(c) 工厂物资管理E-R图 An Introduction to Database System
消除冗余，设计生成基本E-R图实例（续） 支持的数据模型，它是各种数据模型的共同基础，因而比数据模型更一般、更抽象、更接近现实世界。 消除冗余，设计生成基本E-R图实例（续） 该厂销售管理分E-R图 图7.24 销售管理子系统的分E-R图 An Introduction to Database System
消除冗余，设计生成基本E-R图实例（续） 支持的数据模型，它是各种数据模型的共同基础，因而比数据模型更一般、更抽象、更接近现实世界。 消除冗余，设计生成基本E-R图实例（续） 该厂劳动人事管理分E-R图 图7.29 劳动人事管理的分E-R图 An Introduction to Database System
消除冗余，设计生成基本E-R图实例（续） 支持的数据模型，它是各种数据模型的共同基础，因而比数据模型更一般、更抽象、更接近现实世界。 消除冗余，设计生成基本E-R图实例（续） 系统的基本E-R(图7.30) 职工：仓库 某工厂管理信息系统的基本E-R图 An Introduction to Database System
消除冗余，设计生成基本E-R图实例（续） 集成过程，解决了以下问题： 异名同义，项目和产品含义相同 库存管理中职工与仓库的工作关系已包含在劳动人事管理的部门与职工之间的联系之中，所以可以取消 职工之间领导与被领导关系可由部门与职工（经理）之间的领导关系、部门与职工之间的从属关系两者导出，所以也可以取消 An Introduction to Database System
概念结构设计-验证整体概念结构 视图集成后形成一个整体的数据库概念结构，对该整体概念结构还必须进行进一步验证，确保它能够满足下列条件： 整体概念结构内部必须具有一致性，不存在互相矛盾的表达 整体概念结构能准确地反映原来的每个视图结构，包括属性、实体及实体间的联系 整体概念结构能满足需求分析阶段所确定的所有要求 整体概念结构最终还应该提交给用户，征求用户和有关人员的意见，进行评审、修改和优化，然后把它确定下来，作为数据库的概念结构，作为进一步设计数据库的依据。
概念结构设计-E-R图集成 例 学会选课系统实例-基本ER图
概念结构设计-实例 收集信息： 与该系统有关人员进行交流、坐谈，充分理解数据库需要完成的任务 BBS论坛的基本功能： 用户注册和登录：后台数据库需要存放用户的注册信息和在线状态信息； 用户发贴：后台数据库需要存放贴子相关信息，如贴子内容、标题等； 论坛版块管理：后台数据库需要存放各个版块信息，如版主、版块名称、贴子数等；
概念结构设计-实例 标识对象（实体－Entity） 标识数据库要管理的关键对象或实体 实体一般是名词： 用户：论坛普通用户、各版块的版主。 用户发的主贴 用户发的跟贴（回贴） 版块：论坛的各个版块信息
概念结构设计-实例 标识每个实体的属性 （Attribute） 论坛用户： 主贴 回贴 版块 呢称 密码 电子邮件 生日 性别 用户的等级 备注信息 注册日期 状态 积分 主贴 发贴人 发贴表情 回复数量 标题 正文 发贴时间 点击数 状态： 最后回复时间 回贴 贴子编号 回贴人, 回贴表情 标题 正文 回贴时间 点击数 版块 版块名称 版主 本版格言 点击率 发贴数
概念结构设计-实例 标识对象之间的关系（Relationship） 跟贴和主贴有主从关系：我们需要在跟贴对象中表明它是谁的跟贴； 版块和用户有关系：从用户对象中可以根据版块对象查出对应的版主用户的情况； 主贴和版块有主从关系：需要表明发贴是属于哪个版块的； 跟贴和版块有主从关系：需要表明跟贴是属于哪个版块的；
概念结构设计-实例 E-R（Entity－Relationship）实体关系图 管理 bbsUser （用户，版主） bbsSection …… 出生日期 昵称 版块名称 版主 bbsSection （版块）
概念结构设计-绘制ER图 映射基数 管理 发表 属于 跟随 1 M 用户积分 性别 用户等级 备注信息 注册日期 版块名称 本版留言 发贴数 状态 密码 昵称 电子邮件 生日 论坛用户（BBSUser） 管理 发表 跟随 属于 点击率 版主 标题 发贴人 贴子编号 正文 版块（BBSSection） 发贴（BBSTopic） 所在版块 最后回复时间 发贴表情 回复数量 发贴时间 跟贴（BBSReply） 概念结构设计-绘制ER图 映射基数
概念结构设计-小结 概念结构设计的步骤 抽象数据并设计局部视图 集成局部视图，得到全局概念结构 验证整体概念结构
逻辑结构设计 逻辑结构设计的任务 逻辑结构设计的步骤 把概念结构设计阶段设计好的基本E-R图转换为与选 用DBMS产品所支持的数据模型相符合的逻辑结构 逻辑结构设计的步骤 将概念结构转化为一般的关系、网状、层次模型 将转换来的关系、网状、层次模型向特定DBMS支持 下的数据模型转换 对数据模型进行优化
逻辑结构设计
逻辑结构设计-向关系模型的转换 1．实体的转换规则 2．实体间联系的转换规则 将E-R图中的每一个常规实体转换为一个关系，实体的属性就是关系的属性，实体的码就是关系的码。 2．实体间联系的转换规则 （1）一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端所对应的关系模式合并。 （2）一个1:n联系可以转换为一个独立的关系模式，也可以与n端所对应的关系模式合并。 （3）一个m:n联系转换为一个关系模式。转换的方法为：与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，新关系的码为两个相连实体码的组合。 （4）三个或三个以上实体间的多元联系转换为一个关系模式。
逻辑结构设计-向关系模型的转换 3．关系合并规则 为了减少系统中的关系个数，如果两个关系模式具有相同的主码，可以考虑将它们合并为一个关系模式。合并的方法是将其中一个关系模式的全部属性加入到另一个关系模式中，然后去掉其中的同义属性，并适当调整属性的次序。
逻辑结构设计-一对一关系的转换 方法一 方法二 联系转换为独立的关系模式 模式的属性由联系本身的属性及两个实体的键构成 主键由两个实体中的任意一个键构成 方法二 将联系与一端的实体的关系模式合并，即将联系的属性加入到实体的关系模式内 主键不变
逻辑结构设计-一对一关系的转换 实体对应关系模式分别为： 班级（班号，专业，人数） 班长（学号，姓名，专长） 联系 管理（班号，学号） 建立独立的关系模式 实体对应关系模式分别为： 班级（班号，专业，人数） 班长（学号，姓名，专长） 联系 管理（班号，学号） 关系模式“管理”的主键也可以选择学号
逻辑结构设计-一对一关系的转换 合并到实体的关系模式 将联系“管理”合并到实体“班级”对应的模式后为： 原实体对应关系模式分别为： 班级（班号，专业，人数，学号） 班长（学号，姓名，专长） 原实体对应关系模式分别为： 班级（班号，专业，人数） 班长（学号，姓名，专长） 联系“管理”也可以合并到实体“班长”对应的模式
逻辑结构设计-一对多关系的转换 方法一 方法二 联系转换为独立的关系模式 模式的属性由联系本身的属性及两个实体的键构成 主键由n端实体的键组成 方法二 将联系与n端的实体的关系模式合并，即将联系的属性加入到实体的关系模式内 主键不变
逻辑结构设计-一对多关系的转换 实体对应的关系模式 系（系号，系名，系主任，电话） 教师（教师号，姓名，专业，职称，性别，年龄） 建立独立的关系模式 实体对应的关系模式 系（系号，系名，系主任，电话） 教师（教师号，姓名，专业，职称，性别，年龄） 联系对应的关系模式 管理（教师号，系号）
逻辑结构设计-一对多关系的转换 实体对应的关系模式 系（系号，系名，系主任，电话） 合并到实体“教师”后 合并到实体的关系模式 教师（教师号，姓名，专业，职称，性别，年龄） 合并到实体“教师”后 教师（教师号，姓名，专业，职称，性别，年龄，系号） 只能合并到“多”的一端
逻辑结构设计-多对多关系的转换 联系只能转换为独立模式 模式的属性由联系本身的属性及两个实体的键构成 主键由两端实体的键组合而成
逻辑结构设计-多对多关系的转换 课程（课程号，课程名，学时，类别） 学生（学号，姓名，性别，专业，出生日期，照片） 选修（学号，课程号，分数）
逻辑结构设计-三个或三个以上实体间的一个多元联系 三个或三个以上实体间的一个多元联系转换为一个关系模式。 关系的属性：与该多元联系相连的各实体的码以及联系本身的属性 关系的码：各实体码的组合 例，“讲授”联系是一个三元联系，可以将它转换为如下关系模式，其中课程号、职工号和书号为关系的组合码： 讲授（课程号，职工号，书号）
逻辑结构设计-自联系的转换原则 同一实体集的实体间的联系，即自联系，也可按上述1:1、1:n和m:n三种情况分别处理。 教师：｛职工号，姓名，性别，职称，系主任｝
例：公司部门管理系统的E-R图及其转换成的关系模式 部门号，预算费， 领导人职工号 办公室号，面积 项目号，预算费 n 1 1 n 办公室 包含 部门 承担 项目 1 1 n 安装 包括 参与 分担任务 n m n 电话 1 担任 1 职务 职工 电话号码，说明 职工号，姓名，办公电话 担任时期，工资 部门(部门号，部门预算费，领导人职工号) 职工(职工号，姓名，办公电话，部门号) 办公室(办公室号，面积，部门号) 项目(项目号，项目预算费，部门号) 电话(电话号码，说明，办公室号) 项目承担情况(职工号，项目号，分担任务) 工资历史(职工号，职务，担任时期，工资)
系（系号，系名，系主任，电话） 学生（学号，姓名，性别，出生日期，专业，照片） 管理（教师号，系号） 注册（学号，系号） 课程评价（教师号，课程号，评价） 选修（学号，课程号，分数） 教师（教师号，姓名，专业，职称，性别，年龄） 课程（课程号，课程名，学时，类别）
逻辑结构设计-优化 数据库逻辑设计的结果不是唯一的。 得到初步数据模型后，还应该适当地修改、调 整数据模型的结构，以进一步提高数据库应用 系统的性能，这就是数据模型的优化 关系数据模型的优化通常以规范化理论为指导
逻辑结构设计-数据规范化 第一范式(1st NF －First Normal Fromate) 仅有好的RDBMS并不足以避免数据冗余，必须在数据库的设计中创建好的表结构 Dr E.F.codd 最初定义了规范化的三个级别，范式是具有最小冗余的表结构。这些范式是： 第一范式(1st NF －First Normal Fromate) 第二范式(2nd NF－Second Normal Fromate) 第三范式(3rd NF－ Third Normal Fromate)
逻辑结构设计-第一范式1NF 第一范式的目标是确保每列的原子性 BuyerID Address 1 2 3 4 中国北京市 美国纽约市 英国利物浦 日本东京市 … BuyerID Country City 1 4 2 中国 日本 美国 北京 东京 纽约 … 第一范式的目标是确保每列的原子性 如果每列都是不可再分的最小数据单元（也称为最小的原子单元），则满足第一范式（1NF）
逻辑结构设计-第二范式2NF 如果一个关系满足1NF，并且除了主键以外的其他列，都依赖与该主键，则满足第二范式（2NF） Orders 字 段 例 子 订单编号 订购日期 001 2000-2-3 Products 产品编号 价 格 A001 $29.00 Orders 字 段 例 子 订单编号 产品编号 订购日期 价 格 001 A001 2000-2-3 $29.00 … 如果一个关系满足1NF，并且除了主键以外的其他列，都依赖与该主键，则满足第二范式（2NF） 第二范式要求每个表只描述一件事情
逻辑结构设计-第三范式3NF 如果一个关系满足2NF，并且除了主键以外的其他列都不传递依赖于主键列，则满足第三范式（3NF） Orders 字 段 例 子 订单编号 订购日期 顾客编号 001 2000-2-3 AB001 顾客姓名 Tony … 如果一个关系满足2NF，并且除了主键以外的其他列都不传递依赖于主键列，则满足第三范式（3NF）
逻辑结构设计-规范化实例 假设某建筑公司要设计一个数据库。公司的业务规则概括说明如下： 公司承担多个工程项目，每一项工程有：工程号、工程名称、施工人员等 公司有多名职工，每一名职工有：职工号、姓名、性别、职务（工程师、技术员）等 公司按照工时和小时工资率支付工资，小时工资率由职工的职务决定（例如，技术员的小时工资率与工程师不同） 公司定期制定一个工资报表，如图1所示
逻辑结构设计-规范化实例 图1 某公司的工资表 工程号 工程名称 职工号 姓名 职务 小时工资率 工时 实发工资 A1 花园大厦 1001 齐光明 工程师 65 13 845.00 1002 李思岐 技术员 60 16 960.00 1004 葛宇宏 律师 19 1140.00 小计 2945.00 A2 立交桥 15 975.00 1003 鞠明亮 工人 55 17 935.00 1910.00 A3 临江饭店 18 1080.00 葛宇洪 14 840.00 1920.00 图1 某公司的工资表
逻辑结构设计-规范化实例 工程号 工程名称 职工号 姓名 职务 小时工资率 工时 图2 某公司的项目工时表 A1 花园大厦 1001 齐光明 工程师 65 13 1002 李思岐 技术员 60 16 1003 鞠明亮 工人 55 17 A3 临江饭店 18 1004 葛宇洪 14 图2 某公司的项目工时表
逻辑结构设计-规范化实例 1.表中包含大量的冗余，可能会导致数据异常： 更新异常 例如，修改职工号=1001的职务，则必须修改所有职工号=1001的行 添加异常 若要增加一个新的职工时，首先必须给这名职工分配一个工程。或者为了添加一名新职工的数据，先给这名职工分配一个虚拟的工程。（因为主关键字不能为空） 删除异常 例如，1001号职工要辞职，则必须删除所有职工号＝1001的数据行。这样的删除操作，很可能丢失了其它有用的数据
逻辑结构设计-规范化实例 采用这种方法设计表的结构，虽然很容易产生工资报表，但是每当一名职工分配一个工程时，都要重复输入大量的数据。这种重复的输入操作，很可能导致数据的不一致性。
逻辑结构设计-应用1NF 一张表描述了多件事情，如图3所示。 项目工时信息 工程信息 员工信息 图3 函数依赖图 工程号 工程名称 职工号 姓名 职务 小时工资率 工时 工程信息 员工信息 图3 函数依赖图
逻辑结构设计-应用2NF 工程表 员工表 满足第三范式吗？ 项目工时表 图4 应用第二范式 工程号 工程名称 职工号 姓名 职务 小时工资率
逻辑结构设计-应用2NF 工程号 工程名称 工程表 职工号 姓名 职务 员工表 职务 小时工资率 职务表 工程号 职工号 工时 工程表
逻辑结构设计-规范化和性能的关系 为满足某种商业目标，数据库性能比规范化数据库更重要 通过在给定的表中添加额外的字段，以大量减少需要从中搜索信息所需的时间 通过在给定的表中插入计算列（如成绩总分），以方便查询 进行规范化的同时，还需要综合考虑数据库的性能。
逻辑结构设计-规范化和性能的关系 例：在关系模式 学生成绩单(学号,英语,数学,语文,平均成绩) 中存在下列函数依赖： 学号→英语 学号→数学 学号→语文 学号→平均成绩 (英语, 数学, 语文)→平均成绩 显然有： 学号→(英语,数学,语文) 因此该关系模式中存在传递函数信赖，是2NF关系。 虽然平均成绩可以由其他属性推算出来，但如果应用中需要经常查询学生的平均成绩，为提高效率，我们仍然可保留该冗余数据，对关系模式不再做进一步分解。
逻辑结构设计-设计用户子模式 根据局部应用需求设计用户子模式 设计用户子模式的目的 DBMS中一般采用视图(View)机制 使用更符合用户习惯的别名 保证系统安全性 简化用户对系统的使用 DBMS中一般采用视图(View)机制
逻辑结构设计-论坛实例 将各实体转换为对应的表，将各属性转换为各表对应的列 标识每个表的主键列，需要注意的是：没有主键的表添加ID编号列，它没有实际含义，用于做主键或外键，例如用户表中的“UID”列，版块表中添加“SID”列，发贴表和跟贴表中的“TID”列 在表之间建立主外键，体现实体之间的映射关系
概念结构设计-绘制ER图 映射基数 管理 发表 属于 跟随 1 M 用户积分 性别 用户等级 备注信息 注册日期 版块名称 本版留言 发贴数 状态 密码 昵称 电子邮件 生日 论坛用户（BBSUser） 管理 发表 跟随 属于 点击率 版主 标题 发贴人 贴子编号 正文 版块（BBSSection） 发贴（BBSTopic） 所在版块 最后回复时间 发贴表情 回复数量 发贴时间 跟贴（BBSReply） 概念结构设计-绘制ER图 映射基数
逻辑结构设计-论坛实例 UID主键 TID主键 RID主键 SID主键
数据库物理设计 数据库在物理设备上的存储结构与存取方法称为数据库的物理结构，它依赖于选定的数据库管理系统 为一个给定的逻辑数据模型选取一个最适合应用环境的物理结构的过程，就是数据库的物理设计
数据库物理设计-步骤 确定数据库的物理结构，在关系数据库中主要指存取方法和存储结构； 对物理结构进行评价，评价的重点是时间和空间效率。 如果评价结果满足原设计要求，则可进入到物理实施阶段，否则，就需要重新设计或修改物理结构，有时甚至要返回逻辑设计阶段修改数据模型
数据库物理设计-步骤 数据库物理设计 确定数据库的物理结构 评价数据库的物理结构 逻辑结 构设计 数据库 实施 物理 模型 逻辑
数据库物理设计-准备工作 对要运行的事务进行详细分析，获得选择物 理数据库设计所需参数 充分了解所用RDBMS的内部特征，特别是系 统提供的存取方法和存储结构
数据库物理设计-选择参数 数据库查询事务 数据更新事务 每个事务在各关系上运行的频率和性能要求 查询的关系 查询条件所涉及的属性 连接条件所涉及的属性 查询的投影属性 数据更新事务 被更新的关系 每个关系上的更新操作条件所涉及的属性 修改操作要改变的属性值 每个事务在各关系上运行的频率和性能要求
数据库物理设计 关系数据库物理设计的内容 为关系模式选择存取方法(建立存取路径) 设计关系、索引等数据库文件的物理存储结构
数据库物理设计-关系模式存取方法 数据库系统是多用户共享的系统，对同一个关系要建立多条存取路径才能满足多用户的多种应用要求。 物理设计的第一个任务就是要确定选择哪些存取方法，即建立哪些存取路径。
数据库物理设计-关系模式存取方法 DBMS常用存取方法 索引方法，目前主要是B+树索引方法,经典存取方法，使用最普遍 聚簇（Cluster）方法 HASH方法
数据库物理设计-索引 索引存取方法的选择 根据应用要求确定 对哪些属性列建立索引 对哪些属性列建立组合索引 对哪些索引要设计为唯一索引
数据库物理设计-索引 索引存取方法的选择 选择索引存取方法的一般规则 如果一个(或一组)属性经常在查询条件中出现，则考虑在这个(或这组)属性上建立索引(或组合索引) 如果一个属性经常作为最大值和最小值等聚集函数的参数，则考虑在这个属性上建立索引 如果一个(或一组)属性经常在连接操作的连接条件中出现，则考虑在这个(或这组)属性上建立索引
数据库物理设计-索引 索引存取方法的选择 关系上定义的索引数过多会带来较多的额外开销 维护索引的开销 查找索引的开销
数据库物理设计-聚簇 聚簇存取方法的选择 为了提高某个属性（或属性组）的查询速度，把这个或这些属性（称为聚簇码）上具有相同值的元组集中存放在连续的物理块称为聚簇。
数据库物理设计-聚簇 聚簇的用途 1. 大大提高按聚簇属性进行查询的效率 例：假设学生关系按所在系建有索引，现在要查询信息系的所有学生名单。 信息系的500名学生分布在500个不同的物理块上时，至少要执行500次I/O操作。 如果将同一系的学生元组集中存放，则每读一个物理块可得到多个满足查询条件的元组，从而显著地减少了访问磁盘的次数。
数据库物理设计-聚簇 聚簇的用途 2. 节省存储空间 聚簇以后，聚簇码相同的元组集中在一起了，因而聚簇码值不必在每个元组中重复存储，只要在一组中存一次就行了
数据库物理设计-聚簇 聚簇的局限性 1. 聚簇只能提高某些特定应用的性能 2. 建立与维护聚簇的开销相当大 对已有关系建立聚簇，将导致关系中元组移动其物理存储位置，并使此关系上原有的索引无效，必须重建 当一个元组的聚簇码改变时，该元组的存储位置也要做相应移动
数据库物理设计-聚簇 聚簇的适用范围 1. 既适用于单个关系独立聚簇，也适用于多个关系组合聚簇 例：假设用户经常要按系别查询学生成绩单，这一查询涉及学生关系和选修关系的连接操作，即需要按学号连接这两个关系，为提高连接操作的效率，可以把具有相同学号值的学生元组和选修元组在物理上聚簇在一起。这就相当于把多个关系按“预连接”的形式存放，从而大大提高连接操作的效率。
数据库物理设计-聚簇 聚簇的适用范围 2. 当通过聚簇码进行访问或连接是该关系的主要应用，与聚簇码无关的其他访问很少或者是次要的时，可以使用聚簇。 尤其当SQL语句中包含有与聚簇码有关的ORDER BY，GROUP BY，UNION，DISTINCT等子句或短语时，使用聚簇特别有利，可以省去对结果集的排序操作
数据库物理设计-聚簇 选择聚簇存取的方法 1.设计候选聚簇 对经常在一起进行连接操作的关系可以建立组合聚簇； 如果一个关系的一组属性经常出现在相等比较条件中，则该单个关系可建立聚簇； 如果一个关系的一个(或一组)属性上的值重复率很高，则此单个关系可建立聚簇。即对应每个聚簇码值的平均元组数不太少。太少了，聚簇的效果不明显。
数据库物理设计-聚簇 选择聚簇存取的方法 2.优化聚簇设计 从聚簇中删除经常进行全表扫描的关系； 从聚簇中删除更新操作远多于连接操作的关系； 从聚簇中删除重复出现的关系 当一个关系同时加入多个聚簇时，必须从这多个聚簇方案(包括不建立聚簇)中选择一个较优的，即在这个聚簇上运行各种事务的总代价最小。
数据库物理设计-HASH存取 选择HASH存取方法的规则 当一个关系满足下列两个条件时，可以选择HASH存取方法 该关系的属性主要出现在等值连接条件中或主要出现在相等比较选择条件中 该关系的大小可预知，而且不变； 或 该关系的大小动态改变，但所选用的DBMS提供了动态HASH存取方法
数据库物理设计-确定物理结构 1. 确定数据的存放位置和存储结构 关系 索引 聚簇 日志 备份 2. 确定系统配置
数据库物理设计-物理存储位置 影响数据存放位置和存储结构的因素 硬件环境 应用需求 存取时间 存储空间利用率 维护代价 这三个方面常常是相互矛盾的 例：消除一切冗余数据虽能够节约存储空间和减少维护代价，但往往会导致检索代价的增加 必须进行权衡，选择一个折中方案。
数据库物理设计-物理存储位置 基本原则 根据应用情况将 易变部分与稳定部分 存取频率较高部分与存取频率较低部分分开存放，以提高系统性能
数据库物理设计-物理存储位置 例如： 数据库数据备份、日志文件备份等由于只在故障恢复时才使用，而且数据量很大，可以考虑存放在磁带上。 如果计算机有多个磁盘，可以考虑将表和索引分别放在 不同的磁盘上，在查询时，由于两个磁盘驱动器分别在 工作，因而可以保证物理读写速度比较快。 可以将比较大的表分别放在两个磁盘上，以加快存取速度，这在多用户环境下特别有效。 可以将日志文件与数据库对象（表、索引等）放在不同 的磁盘以改进系统的性能。
数据库物理设计-系统配置 DBMS产品一般都提供了一些存储分配参数 同时使用数据库的用户数 同时打开的数据库对象数 内存分配参数 使用的缓冲区长度、个数 存储分配参数 …….
数据库物理设计-系统配置 系统都为这些变量赋予了合理的缺省值。但是这些值不一定适合每一种应用环境，在进行物理设计时，需要根据应用环境确定这些参数值，以使系统性能最优。 在物理设计时对系统配置变量的调整只是初步的，在系统运行时还要根据系统实际运行情况做进一步的调整，以期切实改进系统性能。
数据库物理设计-评价物理结构 评价内容 对数据库物理设计过程中产生的多种方案进行细致的评价，从中选择一个较优的方案作为数据库的物理结构
数据库物理设计-评价物理结构 评价方法（依赖于DBMS） 定量估算各种方案 对估算结果进行权衡、比较，选择出一个较优的合理的物理结构 存储空间 存取时间 维护代价 对估算结果进行权衡、比较，选择出一个较优的合理的物理结构 如果该结构不符合用户需求，则需要修改设计
数据库的实施与维护-数据装入 数据库结构建立好后，就可以向数据库中装载数据了。组织数据入库是数据库实施阶段最主要的工作。 数据装载方法 人工方法 计算机辅助数据入库
数据库的实施与维护-应用程序的编码和调试 数据库应用程序的设计应该与数据设计并行进行 在组织数据入库的同时还要调试应用程序
数据库的实施与维护-试运行 在原有系统的数据有一小部分已输入数据库后，就可以开始对数据库系统进行联合调试，称为数据库的试运行 数据库试运行主要工作包括： 1）功能测试 实际运行数据库应用程序，执行对数据库的各种操作，测试应用程序的功能是否满足设计要求 如果不满足，对应用程序部分则要修改、调整，直到达到设计要求阶段，修改逻辑结构
数据库的实施与维护-试运行 2）性能测试 测量系统的性能指标，分析是否达到设计目标 如果测试的结果与设计目标不符，则要返回物理设计阶段，重新调整物理结构，修改系统参数，某些情况下甚至要返回逻辑设计阶段，修改逻辑结构
数据库的实施与维护-试运行 强调两点： 分期分批组织数据入库 待试运行基本合格后再大批量输入数据 逐步增加数据量，逐步完成运行评价 重新设计物理结构甚至逻辑结构，会导致数据重新入库。 由于数据入库工作量实在太大，费时、费力，所以应分期分批地组织数据入库 先输入小批量数据供调试用 待试运行基本合格后再大批量输入数据 逐步增加数据量，逐步完成运行评价
数据库的实施与维护-试运行 强调两点： 数据库的转储和恢复 在数据库试运行阶段，系统还不稳定，硬、软件故障随时都可能发生 系统的操作人员对新系统还不熟悉，误操作也不可避免 因此必须做好数据库的转储和恢复工作，尽量减少对数据库的破坏。
数据库的实施与维护-运行与维护 数据库试运行合格后，数据库即可投入正式运行。 数据库投入运行标志着开发任务的基本完成和维护工作的开始 对数据库设计进行评价、调整、修改等维护工作是一个长期的任务，也是设计工作的继续和提高。 应用环境在不断变化 数据库运行过程中物理存储会不断变化
数据库的实施与维护-运行与维护 在数据库运行阶段，对数据库经常性的维护工作主要是由DBA完成的，包括： 数据库的转储和恢复 数据库的安全性、完整性控制 数据库性能的监督、分析和改进 数据库的重组织和重构造
数据库的实施与维护-重组织和重构造 重组织的形式 全部重组织 部分重组织 只对频繁增、删的表进行重组织 重组织的目标 提高系统性能
数据库的实施与维护-重组织和重构造 重组织的工作 按原设计要求 重新安排存储位置 回收垃圾 减少指针链 数据库的重组织不会改变原设计的数据逻辑结构和物理结构
数据库的实施与维护-重组织和重构造 数据库重构造 根据新环境调整数据库的模式和内模式 增加新的数据项 改变数据项的类型 改变数据库的容量 增加或删除索引 修改完整性约束条件
作业补充 某商业集团有三个实体集：商品—商品名、规格、单价；商店—商店号、商店名、地址；供应商—供应同编号、供应商名、地址。每个供应商可供应多种商品，每种商品可向多个供应商订购，供应商供应商品有月供应量，每个商店可销售多种商品，每种商品可在多个商店销售，商店销售商品有月计划数。 试设计ER图，再转换成关系模式，并进行适当的规范化。