ER设计基础教程

  • 格式:ppt
  • 大小:1.47 MB
  • 文档页数:43

下载文档原格式

  / 43
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

删除表

删除表的语法:
DROP TABLE 表名 [CASCADE CONSTRAINTS];
DROP TABLE TEST_MASTER CASCADE CONSTRAINTS;
回顾约束的类型

约束的目的:确保表中数据的完整型 常用的约束类型: 主键约束(Primary Key Constraint):要求主键列数据唯一, 并且不允许为空 唯一约束(Unique Constraint):要求该列唯一,允许为空,但 只能出现一个空值。 检查约束(Check Constraint):某列取值范围限制、格式限制 等,如有关年龄的约束 默认约束(Default Constraint):某列的默认值,如默认处理日 期为系统日期 外键约束(Foreign Key Constraint):用于两表间建立关系, 需要指定引用主表的列


版块名称 版主 本版格言 点击率 发贴数
设计数据库的步骤4-4

标识对象之间的关系(Relationship)
跟贴和主贴有主从关系:我们需要在跟贴对象中表明它是谁的跟贴 版块和用户有关系:可以根据版块对象查出对应的版主用户的情况 主贴和版块有主从关系:需要表明发贴是属于哪个版块的 跟贴和版块有主从关系:需要表明跟贴是属于哪个版块的
数据库设计与实现
本章目标
了解设计数据库的步骤
掌握如何绘制数据库的E-R图
理解数据库的规范化-三来自百度文库范式
为什么需要设计数据库 2-1
修建茅屋需要设计吗?
修建大厦需要设计吗?
当数据库比较复杂时我们需要设计数据库
为什么需要设计数据库 2-2
良好的数据库设计:
节省数据的存储空间 能够保证数据的完整性 方便进行数据库应用系统的开发
规范化实例 5-2
工程号 工程名称 职工号
1001 A1 花园大厦 1002
姓名
齐光明 李思岐
职务
工程师 技术员
小时工资率
65 60
工时
13 16
实发工资
845.00 960.00
1004
葛宇宏
小计
技术员
60
19
1140.00
2945.00
1001 A2 立交桥 1003
齐光明 鞠明亮
工程师 工人
总结 2-1
在详细设计阶段,设计数据库的步骤为: 绘制E-R图 将E-R图转换为表结构
应用三大范式规范化表
总结 2-2

为了设计结构良好的数据库,需要遵守一些专门 的规则,称为数据库的设计范式
第一范式(1NF)的目标:确保每列的
原子性 第二范式(2NF)的目标:确保表中的 每列,都和主键相关 第三范式(3NF)的目标:确保每列都 和主键列直接相关,而不是间接相关
职工号
1001 1002 1001 1003 1002 1004
姓名
齐光明 李思岐 齐光明 鞠明亮 李思岐 葛宇洪
职务
工程师 技术员 工程师 工人 技术员 技术员
小时工资率
65 60 65 55 60 60
工时
13 16 13 17 18 14
某公司的项目工时表
1. 表中包含大量的冗余,可能会导致数据异常:
密码
状态
昵称
电子邮件 生日
点击率
1
1
发表
论坛E-R图
M 所在版块 贴子编号 M 状态 正文 发贴人
发贴(BBSTopic)
属于
M M
标题 发贴人
贴子编号 正文
点击率
1
跟随
M
跟贴(BBSReply)
标题 发贴时间 点击率 回复数量 发贴表情 最后回复时间
发贴时间 所在版块 最后回复时间 发贴表情
如何将E-R图转换为表 3-1
添加约束

添加约束的语法:
约束类型 具体的约束说明;
ALTER TABLE 表名 ADD CONSTRAINT 约束名
约束名的取名规则推荐采用:约束类型_约束字段 主键(Primary Key)约束:如 PK_stuNo 唯一(Unique Key)约束:如 UK_stuID 检查(Check Key) 约束:如 CK_stuAge 外键(Foreign Key)约束:如 FK_stuNo

如果一个关系满足1NF,并且除了主键以外的其他列,都依 赖与该主键,则满足第二范式(2NF) 第二范式要求每个表只描述一件事情
第三范式 (3rd NF)
Orders
Orders
字 段 例 子 字 段 例 子 订单编号 001 订购日期 2000-2-3 顾客编号 AB001 … …
订单编号 001 订购日期 2000-2-3 顾客编号 AB001 顾客姓名 Tony … …
设计数据库的步骤4-2

标识对象(实体-Entity)
标识数据库要管理的关键对象或实体
实体一般是名词:

用户:论坛普通用户、各版块的版主。 用户发的主贴 用户发的跟贴(回贴) 版块:论坛的各个版块信息
设计数据库的步骤4-3
标识每个实体的属性(Attribute)
论坛用户:

设计数据库的步骤4-1

收集信息
与该系统有关人员进行交流、坐谈,充分理解数据库需要 完成的任务
BBS论坛的基本功能:

用户注册和登录,后台数据库需要存放用户的注册信息和在线 状态信息 用户发贴,后台数据库需要存放贴子相关信息,如贴子内容、 标题等 论坛版块管理:后台数据库需要存放各个版块信息,如版主、 版块名称、贴子数等
通过在给定的表中添加额外的字段,
以大量减少需要从中搜索信息所需 的时间 通过在给定的表中插入计算列(如 成绩总分),以方便查询

进行规范化的同时,还需要综合考虑数据库的性能,必 要的时候需要较低规范化的程度,即非规范化 (Denormalize)

在需求分析阶段,设计数据库的一般步骤为:
收集信息 标识对象 标识每个对象的属性 标识对象之间的关系
第二范式 (2nd NF)
Orders 字 段 例 子 Orders 字 段 例 子
订单编号 001
产品编号 A001 订购日期 2000-2-3 价 格 … $29.00 …
订单编号 001 订购日期 2000-2-3 产品编号 A001 Products




产品编号 A001
价 格
$29.00
第一范式 (1st NF)
BuyerID 1 Address 中国北京市 BuyerID 1 Country 中国 City 北京
2
3
美国纽约市
英国利物浦
1
4
中国
日本
北京
东京
4

日本东京市

2

美国

纽约


第一范式的目标是确保每列的原子性 如果每列都是不可再分的最小数据单元(也称为最小的原 子单元),则满足第一范式(1NF)

映射基数
X X X X 一对一
Y Y Y Y
X X X X 一对多
Y Y Y Y
客户
X X X X
1
N
订单
M
N
产品
Y Y Y Y 多对多
Y Y Y 多对一
X X X X
绘制E-R图
用户积分 性别 用户等级 备注信息 注册日期 版块名称 本版留言 发贴数 论坛用户(BBSUser)
1
管理
M
版块(BBSSection) 版主

规范化实例 5-4


更新异常 例如,修改职工号=1001的职务,则必须修改所有职工号 =1001的行 添加异常 若要增加一个新的职工时,首先必须给这名职工分配一 个工程。或者为了添加一名新职工的数据,先给这名职 工分配一个虚拟的工程。(因为主关键字不能为空) 删除异常 例如, 1001 号职工要辞职,则必须删除所有职工号= 1001 的数据行。这样的删除操作,很可能丢失了其它有 用的数据
糟糕的数据库设计:
数据冗余、存储空间浪费 内存空间浪费 数据更新和插入的异常
现实世界
软件项目开发周期
信息世界 数据库世界
建模 模型转换 规范化




需求分析阶段:分析客户的业务和数据处理需求; 概要设计阶段:设计数据库的E-R模型图,确认需求信息的正确和完整; 详细设计阶段:将E-R图转换为多张表,进行逻辑设计, 并应用数据库设计的三大范式进行审核; 代码编写阶段:选择具体数据库进行物理实现, 并编写代码实现前端应用; 软件测试阶段:…… 安装部署阶段:……
列的特征: 包括该列是是否为空(NULL)、是否有默认值、是否为主键等。
建表示例
CREATE TABLE TEST_DETAIL ( ID NUMBER(10) NOT NULL, MASTER_ID NUMBER(10), SCORE NUMBER(3) NULL, REG_DATE DATE DEFAULT SYSDATE NOT NULL );
规范化实例 5-5
2 .采用这种方法设计表的结构,虽然很容易产
生工资报表,但是每当一名职工分配一个工程
时,都要重复输入大量的数据。这种重复的输
入操作,很可能导致数据的不一致性。
应用范式规范化设计
一张表描述了多个实体的信息
项目工时信息
工程号 工程名称 职工号 姓名 职务 小时工资率 工时
工程信息
员工信息
函数依赖图
应用第二范式规范化
工程号 工程名称
工程表
职工号
姓名
职务
小时工资率
员工表
满足第三范式吗?
工程号 职工号 工时
项目工时表
应用第三范式规范化
工程号 工程名称
工程表
职工号
姓名
职务
员工表
职务
小时工资率
职务表
工程号
职工号
工时
工程表
规范化和性能的关系

为满足某种商业目标,数据库性能比规范化数据库更重 要
如何将E-R图转换为表
添加各表之间的关系
数据规范化(Normalize)

仅有好的RDBMS并不足以避免数据冗余,必须在数据 库的设计中创建好的表结构 Dr. E.F.Codd 最初定义了规范化的三个级别,范式用于 降低表的冗余数据。这些范式是: 第一范式(1st NF -First Normal Form) 第二范式(2nd NF-Second Normal Form) 第三范式(3rd NF- Third Normal Form)
主贴

回贴

版块



呢称 密码 电子邮件 生日 性别 用户的等级 备注信息 注册日期 状态 积分


发贴人 发贴表情 回复数量 标题 正文 发贴时间 点击数 状态 最后回复时间


贴子编号 回贴人 回贴表情 标题 正文 回贴时间 点击数
数据库实现
目标



掌握建表的 SQL 语句 掌握加约束的 SQL 语句 掌握授权的 SQL 语句
回顾表的基础知识
建表的基本步骤:
确定表中有哪些列 确定每列的数据类型 给表添加各种约束 创建各表之间的关系
创建表

建表的语法
CREATE TABLE 表名 ( 字段1 数据类型 列的特征, 字段2 数据类型 列的特征, ... );

如果一个关系满足2NF,并且除了主键以外的其他列 都不传递依赖于主键列,则满足第三范式(3NF)
规范化实例 5-1
假设某建筑公司要设计一个数据库。公司的业务 规则概括说明如下:
公司承担多个工程项目,每一项工程有:工程号、工程
名称、施工人员等 公司有多名职工,每一名职工有:职工号、姓名、性别、 职务(工程师、技术员)等 公司按照工时和小时工资率支付工资,小时工资率由职 工的职务决定(例如,技术员的小时工资率与工程师不同) 公司定期制定一个工资报表如图所示
添加约束示例
-- Create primary key ALTER TABLE TEST_MASTER ADD CONSTRAINT PK_TEST_MASTER PRIMARY KEY (ID); -- Create unique key ALTER TABLE TEST_MASTER ADD CONSTRAINT UK_TEST_MASTER UNIQUE (NAME); -- Create check constraints ALTER TABLE TEST_MASTER ADD CONSTRAINT CK_TEST_MASTER_NAME CHECK (LENGTH(NAME)>=2); -- Create foreign key ALTER TABLE TEST_DETAIL ADD CONSTRAINT FK_TEST_DETAIL_ID FOREIGN KEY (MASTER_ID) REFERENCES TEST_MASTER (ID);

绘制E-R图 4-1

E-R(Entity-Relationship)实体关系图 符号 含义
实体,一般是名词 属性,一般是名词
关系,一般是动词
绘制E-R图 4-2
bbsUser (用户,版主)
昵称 出生日期 ……
管理
bbsSection (版块)
版块名称
版主
……
绘制E-R图 4-3
将各实体转换为对应的表,将各属性转换为各表 对应的列 标识每个表的主键列,需要注意的是:没有主键 的表添加ID编号列,它没有实际含义,用于做主 键或外键,例如用户表中的“UID”列,版块表中 添加“SID”列,发贴表和跟贴表中的“TID”列 在表之间建立主外键,体现实体之间的映射关系
如何将E-R图转换为表 3UID主键 TID主键 RID主键 SID主键 2
65 55
15 17
975.00 935.00
小计
A3 临江饭店 1002 1004 李思岐 葛宇宏 小计 技术员 技术员 60 60 18 14
1910.00
1080.00 840.00 1920.00
某公司的工资表
规范化实例 5-3
工程号
A1 A1 A2 A2 A3 A3
工程名称
花园大厦 花园大厦 立交桥 立交桥 临江饭店 临江饭店