数据库建模-概念设计资料.pptVIP

回顾一：数据建模的概念 将现实世界的数据转换成信息世界的数据 的过程称为建模 回顾二：数据库设计的必要性 好的数据库结构有利于： 节省数据的存储空间 能够保证数据的完整性 方便进行数据库应用系统的开发 设计不好的数据库结构将导致 数据冗余、存储空间浪费 各种数据操作异常 内存空间浪费 数据库的设计步骤 需求收集和分析 设计概念结构 设计逻辑结构 设计物理结构 物理实现 数据库的设计步骤 需求收集和分析 用户关心什么 用户要什么结果 设计概念结构 设计逻辑结构 设计物理结构 物理实现 数据库的设计步骤 需求收集和分析 设计概念结构 存什么 关系（联系）如何 E/R图，是各种数据模型的共同基础 设计逻辑结构 设计物理结构 物理实现 数据库的设计步骤 需求收集和分析 设计概念结构 设计逻辑结构 用什么数据模型 数据库的模式（database schema） 用户子模式 设计物理结构 物理实现 数据库的设计步骤 需求收集和分析 设计概念结构 设计逻辑结构 设计物理结构 数据怎么存 根据DBMS产品、环境特点 物理实现 数据库的设计步骤 需求收集和分析 设计概念结构 设计逻辑结构 设计物理结构 物理实现 运行DDL 装入测试数据 应用程序 8.3.2：实体关系模型 实体关系模型：DB 设计过程，并且表示 DB 的整个逻辑结构 实体：实体可以是具体的（例如一个人或一本书），也可以是抽象的（如一个节日或一个概念） 属性：实体是由一组属性来表示的。例如：Person（个人）实体的属性有 Name（名称）、SSN、Age（年龄）、Street（街道）、City（城市） 关系：关系是两个或多个实体之间的联系 关系的类型 E-R 图的符号 E-R 图 E-R 图 E-R 图 8.3.3:采用ER的概念模型设计步骤 1、局部设计 8.3.3:采用ER的概念模型设计步骤 2、全局设计 8.3.3:采用ER的概念模型设计步骤 3、全局ER模式优化 8.3.4：范式理论 范式理论： 第一范式：1NF 第二范式：2NF 第三范式：3NF 带有问题的表格 问题分析 1．表中包含大量的冗余，可能会导致数据异常： a.更新异常 例如，修改职工号=1001的职务，则必须修改所有职工号=1001的行。 b. 添加异常 若要增加一个新的职工时，首先必须给这名职工分配一个工程。或者为了添加一名新职工的数据，先给这名职工分配一个虚拟的工程。（因为主关键字不能为空） c. 删除异常 例如，1001号职工要辞职，则必须删除所有职工号＝1001的数据行。这样的删除操作，很可能丢失了其它有用的数据。 什么是规范化 研究设计一个“好”的（没有“毛病”的）关系模式的办法。 第一范式 第二范式 第三范式 第一范式 第一范式的定义： 指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。 在第一范式（1NF）中表的每一行只包含一个实例的信息 第一范式 第二范式 第二范式的定义： 如果一个表属于1NF，且不包含部分依赖性，既没有任何属性只依赖于关键字的一部分，则这个表属于第二范式（常记成2NF ）。 第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分. 将1NF转换成2NF的方法是分解。 第二范式 第三范式 第三范式的定义： 如果一个表属于2NF，且不包含传递依赖性，则这个表是第三范式（常记成3NF）。 满足3NF的表中不包含传递依赖，即没有一个非关键属性依赖于另一个非关键属性，或者说没有一个非关键属性决定另一个非关键属性。 第三范式就是属性不依赖于其它非主属性。 第三范式 案例分析 规范化实例1-2 假设某建筑公司要设计一个数据库。公司的业务规则概括说明如下： 公司承担多个工程项目，每一项工程有：工程号、工程名称、施工人员等； 公司有多名职工，每一名职工有：职工号、姓名、性别、职务（工程师、技术员）等； 公司按照工时和小时工资率支付工资，小时工资率由职工的职务决定（例如，技术员的小时工资率与工程师不同）。 公司定期制定一个工资报表，如图-1所示。 规范化实例2-2 再看这三个表的函数依赖图 画出四个表的函数依赖图 从函数依赖图可见，已经消除职工表中的传递依赖，这四个表都属于第三范式。 在绝大多数情况下，一个数据库的所有表都满足3NF，就基本达到数据库设计的目标。 案例分析 案例分析及实现一 X员工在X日期收到X订单中的X货品X件到仓库中. X员工在X日期在仓库中提取X货品X件 案例分析及实现一 员工： 员工号 姓名 货品： 货品编号 货品描述 库仓： 库仓号 库仓