《关系型数据库的设计精选培训课件》由会员分享，可在线阅读，更多相关《关系型数据库的设计精选培训课件（37页珍藏版）》请在金锄头文库上搜索。
1、数据库实用技术SQL Server 2008,第三章 关系型数据库的设计,第二章 数据库基础,关系型数据库的定义,关系型数据库是基于关系模型的数据库。 关系模型的三要素： 关系数据结构： 关系模型的数据结构非常单一。 现实世界中的实体以及实体之间的各种联系统一用关系表示。 在用户看来，一个关系就是一张二维表。 关系数据操作。 关系数据完整性约束。,第三章 关系型数据库的设计,关系型数据库的定义,关系型数据库是基于关系模型的数据库。 关系模型的三要素： 关系数据结构。 关系数据操作： 数据操作是指对数据库中各种数据对象允许执行的操作的集合。 主要有查询和更新（插入、删除、修改）两大类操作。 数据
2、模型必须定义这些操作的确切含义、操作符号、操作规则及实现操作的语言。 关系数据完整性约束。,第三章 关系型数据库的设计,关系型数据库的定义,关系型数据库是基于关系模型的数据库。 关系模型的三要素： 关系数据结构。 关系数据操作。 关系数据完整性约束： 数据的约束是一组完整性规则的集合。 完整性规则是数据模型中数据及其联系所具有的制约和依存规则，用以保证数据的正确性、有效性和一致性。,第三章 关系型数据库的设计,关系型数据库的定义,关系数据结构： 关系术语： 关系（Relation）：是满足一定条件的二维表。每个关系有一个关系名。 元组（Tuple）：关系表中的一行，描述一实体或联系。也被称为记
3、录。 属性（Attribute）：关系表中的各列，也被称为字段。每一个属性都有一个名字，即表中的列标题称为属性名；表中各列对应的数据称为属性值，描述实体或联系的特征。 域（Domain）：属性的取值范围，即不同的元组对同一个属性的取值所限定的范围。,第三章 关系型数据库的设计,关系型数据库的定义,关系数据结构： 关系术语： 候选码（Candidate Key）：若关系表中的某一属性或属性组（多个属性的最小组合）的值能唯一地确定一个元组，称该属性或属性组为候选码。候选码可以有多个。 主键（Primary Key，PK）：如果候选码有多个，取其中某一个作为关系的主键。主键也被称为关键字。其值不允许
4、为NULL，而且唯一标识一行。 NULL表示该字段的值为空，它不是0，也不是空格。,第三章 关系型数据库的设计,关系型数据库的定义,关系数据结构： 关系术语： 外键（Foreign Key，FK）：是一个关系中的属性或属性组，但不是本关系的主键，而是另一关系的主键，则称该属性或属性组是该关系的外键，也被称为外关键字。 关系型数据库的表间关系必须借助外键来建立。 主属性（Primary Attribute）：能作为候选码的属性。一个关系表中至少必须有一个候选码。 非主属性（Non-primary Attribute）：不包含在任何候选码中的属性。即不是候选码的属性。,第三章 关系型数据库的设计,
5、关系型数据库的定义,关系数据结构： 关系：关系是一个二维表，它必须满足以下特性： 关系（表）的每一元组（行）定义实体集的一个实体，每一列定义实体的一个属性。 每一列表示一个属性（字段），且列名不能重复。 关系必须有一个主键（关键字），用来唯一标识一个元组（行），即实体。 列的每个值必须与对应属性的类型相同。 列是不可分割的最小数据项。 行、列的顺序无关紧要。,第三章 关系型数据库的设计,关系型数据库的定义,关系数据结构： 关系：关系是一个二维表，它必须满足以下特性： 例如客户信息关系：,第三章 关系型数据库的设计,关系型数据库的定义,关系数据结构： 关系模式：关系模式是对关系的结构及其特征的抽
6、象描述，一般由关系名、关系中的属性名及主键构成。 描述方式： 关系名（属性1，属性2，属性n） 有下划线的“属性1”为主键。 例如客户信息： 客户信息（客户ID，客户名称，密码，注册日期，联系人ID，类别，状态，预存费余额）,第三章 关系型数据库的设计,关系型数据库的定义,关系数据操作： 常用的数据操作可分为查询和更新（插入、删除、修改）两大类。其中，查询是最主要也最频繁执行的操作。 关系数据操作的执行过程以关系代数为理论基础。 将数据库的各表视作集合，执行并、交、差和笛卡儿积等集合运算。 专门用于数据库操作的关系运算： 选择运算：从参与运算的关系中选择满足给定条件的那些元组构成一个新关系。
7、投影运算：从参与运算的关系中选择给定的若干属性构成一个新关系。 连接运算：从两个关系的广义笛卡儿积中选择属性值满足一定条件的元组构成一个新关系。,第三章 关系型数据库的设计,关系型数据库的定义,关系数据完整性约束： 实体完整性（Entity Integrity）： 关系的主属性值不能取空值。 参照完整性（Referential Integrity）： 参照关系（子表）的外键取值不能超出被参照关系（父表）的主键取值。 用户定义的完整性（User-defined Integrity）： 属性取值满足某种条件或函数要求，包括对每个关系的取值限制（或称约束）的具体定义。,第三章 关系型数据库的设计,E
8、-R模型到关系模型的转换,实体（E）的转换： 一个实体转换为一个关系模式，实体的属性就是关系的属性，实体的主键就是关系的主键。 为实体和属性命名时，建议尽量使用英文或拼音，以适应各种数据库管理系统（DBMS）的兼容操作。 例如，客户实体转换为关系模式： 实体：客户信息（客户ID，客户名称，密码，注册日期，类别，状态，预存费余额），其中主键为“客户ID”。 关系：Customer(CID,CName, Cpassword, CRegistrationDate,CType,CStatus,CAccountBalance) PK：CID,第三章 关系型数据库的设计,E-R模型到关系模型的转换,联系（
9、R）的转换： 一对一联系的转换： 将联系与任意端实体所对应的关系模式合并，并加入另一端实体的主键和联系本身的属性。 一对多联系的转换： 方法一：把联系与多的一端实体所对应的关系模式合并，加入一的那端实体的主键和联系的属性。 方法二：联系可独立转换成一个关系模式，其属性包括联系自身的属性以及相连的两端实体的主键。 多对多联系的转换： 实体直接可转换为关系模式，联系则只能独立转换成一个关系模式，其属性包括联系自身的属性以及相连的各实体的主键。,第三章 关系型数据库的设计,E-R模型到关系模型的转换,联系（R）的转换： 【例3-1】 有下列实体，实体之间存在一对一联系，将其转换为关系模式。 客户（客
10、户ID，客户名称，密码，注册日期，类别，状态，预存费余额） 联系人（联系人ID，姓名，身份证号码，职务，地址，通信方式） 关系模型： Customer(CID，CName，RID，CPassword，CRegistrationDate，CType，CStatus，CAccountBalance) PK：CID；FK：RID Relation（RID，RName，RIndentityNo，RDuty，RAddress，RContactinfo） PK：RID,第三章 关系型数据库的设计,E-R模型到关系模型的转换,联系（R）的转换： 【例3-2】客户实体与产品（产品号码，产品名称，购买日期，安装
11、地址，单价）实体存在一对多的购买联系，将其转换为关系模式。 关系模型： 由于客户与产品之间存在的购买联系没有属性，所以使用方法一，将购买联系与产品合并，转换成一个关系模式： Customer(CID，CName，RID，CPassword，CRegistrationDate，CType，CStatus，CAccountBalance) PK：CID；FK：RID EProduct（ENo，EName，CID，EJoinDate，EAddress，EUnivalence） PK：Eno；FK：CID,第三章 关系型数据库的设计,E-R模型到关系模型的转换,联系（R）的转换： 【例3-3】客户实体
12、与产品（产品号码，产品名称，购买日期，安装地址）实体存在一对多的支付联系，支付联系（支付时间，付款方式，对应帐号），将客户、产品和支付联系转换为关系模式。 关系模型： 由于客户与产品之间的支付联系存在属性，所以使用方法二，将支付联系独立转换成一个关系模式： Customer(CID，CName，RID，CPassword，CRegistrationDate，CType，CStatus，CAccountBalance) PK：CID；FK：RID Payment (CID，ENo，PayDate，PaymentWay，PayAccountNo) PK：CID，Eno；FK：CID和Eno EPr
13、oduct2（ENo，Ename，EJoinDate，EAddress，EUnivalence） PK：Eno,第三章 关系型数据库的设计,E-R模型到关系模型的转换,联系（R）的转换： 【例3-4】产品实体与附加服务（附加服务ID，附加服务名称，附加服务收费）实体存在多对多的联系，由主产品绑定开通附加服务项目，开通联系有开通时间属性。现将其转换为关系模式。 关系模型： EProduct（ENo，EName，CID，EJoinDate，EAddress，Eunivalence） PK：Eno；FK：CID StartAdditionalService（ENo，ASID，SATime） PK：E
14、No，ASID；FK：ENo和ASID AdditionalService（ASID，ASitem，ASPrice） PK：ASID,第三章 关系型数据库的设计,关系规范化,关系规范化： 就是能够确保所建立的数据库具有较少的数据冗余、较高的数据共享度、较好的数据一致性，以及较灵活和方便的数据更新能力。 关系模型要求关系必须是规范化的，即必须满足三个范式： 第一范式1NF： 关系表R中的每一个属性（字段）是不可再分的。 第二范式2NF 关系表R是1NF，而且它的每一非主属性（即不是候选码里的属性）完全依赖于全部主属性。 第三范式3NF 关系表R是2NF，而且它的每一非主属性不传递依赖于主属性。
15、传递依赖的含义是指经由其他属性而依赖于主属性的字段。,第三章 关系型数据库的设计,关系规范化,关系规范化举例： 第一范式1NF： 不符合第一范式： 符合第一范式：,第三章 关系型数据库的设计,关系规范化,关系规范化： 第二范式2NF ： 不符合第二范式： 客户与联系人是一对一联系，可以将它们合并为一个关系表： 客户信息（客户ID，客户名称，密码，注册日期，类别，状态，预存费余额，联系人ID，姓名，身份证号码，职务，地址，电话，邮编，Email，传真）， 主属性有：客户ID，联系人ID，身份证号码。 有非主属性部分依赖主属性的情况。 符合第二范式： 将该关系表分解成客户关系表和联系人关系表： 客
16、户（客户ID，联系人ID，客户名称，密码，注册日期，类别，状态，预存费余额）；主键：客户ID；外键：联系人ID 联系人（联系人ID，姓名，身份证号码，职务，地址，电话，邮编，Email，传真）；主键：联系人ID,第三章 关系型数据库的设计,关系规范化,关系规范化： 第三范式3NF ： 不符合第三范式： 用一个关系表来表示帐单和明细，其关系为： 帐单明细（明细ID，产品号码，客户ID，对方号码，日期，起始时间，持续时间，发生费用，帐单ID，帐单日期，固定费用，通信费用） 主属性有：明细ID。 帐单ID是非主属性，它是依赖于明细ID的，而帐单日期、固定费用、通信费用又是依赖于帐单ID，有传递依赖主属性的情况。 符合第三范式： 将该关系表分解成明细关系表和帐单关系表： 明细： (明细ID，产品号码，对方号码，日期，起始时间，持续时间，发生费用，帐单ID)；主键：明细ID；外键：帐单ID 帐单：（帐单ID，产品号码，客户ID，帐单日期，固定费用，通信费用）；主键：帐单ID,第三章 关系型数据库的设计,关系规范化,数据模型的优化： 关系模型要求关系必须规范化。 设
