关系型数据库的设计.ppt

数据库实用技术 SQL Server 2008,第三章 关系型数据库的设计,第二章 数据库基础,SQL Server 2008,关系型数据库的定义,关系型数据库是基于关系模型的数据库。 关系模型的三要素： 关系数据结构： 关系模型的数据结构非常单一。 现实世界中的实体以及实体之间的各种联系统一用关系表示。 在用户看来，一个关系就是一张二维表。 关系数据操作。 关系数据完整性约束。,第三章 关系型数据库的设计,SQL Server 2008,关系型数据库的定义,关系型数据库是基于关系模型的数据库。 关系模型的三要素： 关系数据结构。 关系数据操作： 数据操作是指对数据库中各种数据对象允许执行的操作的集合。 主要有查询和更新（插入、删除、修改）两大类操作。 数据模型必须定义这些操作的确切含义、操作符号、操作规则及实现操作的语言。 关系数据完整性约束。,第三章 关系型数据库的设计,SQL Server 2008,关系型数据库的定义,关系型数据库是基于关系模型的数据库。 关系模型的三要素： 关系数据结构。 关系数据操作。 关系数据完整性约束： 数据的约束是一组完整性规则的集合。 完整性规则是数据模型中数据及其联系所具有的制约和依存规则，用以保证数据的正确性、有效性和一致性。,第三章 关系型数据库的设计,SQL Server 2008,关系型数据库的定义,关系数据结构： 关系术语： 关系（Relation）：是满足一定条件的二维表。每个关系有一个关系名。 元组（Tuple）：关系表中的一行，描述一实体或联系。也被称为记录。 属性（Attribute）：关系表中的各列，也被称为字段。每一个属性都有一个名字，即表中的列标题称为属性名；表中各列对应的数据称为属性值，描述实体或联系的特征。 域（Domain）：属性的取值范围，即不同的元组对同一个属性的取值所限定的范围。,第三章 关系型数据库的设计,SQL Server 2008,关系型数据库的定义,关系数据结构： 关系术语： 候选码（Candidate Key）：若关系表中的某一属性或属性组（多个属性的最小组合）的值能唯一地确定一个元组，称该属性或属性组为候选码。候选码可以有多个。 主键（Primary Key，PK）：如果候选码有多个，取其中某一个作为关系的主键。主键也被称为关键字。其值不允许为NULL，而且唯一标识一行。 NULL表示该字段的值为空，它不是0，也不是空格。,第三章 关系型数据库的设计,SQL Server 2008,关系型数据库的定义,关系数据结构： 关系术语： 外键（Foreign Key，FK）：是一个关系中的属性或属性组，但不是本关系的主键，而是另一关系的主键，则称该属性或属性组是该关系的外键，也被称为外关键字。 关系型数据库的表间关系必须借助外键来建立。 主属性（Primary Attribute）：能作为候选码的属性。一个关系表中至少必须有一个候选码。 非主属性（Non-primary Attribute）：不包含在任何候选码中的属性。即不是候选码的属性。,第三章 关系型数据库的设计,SQL Server 2008,关系型数据库的定义,关系数据结构： 关系：关系是一个二维表，它必须满足以下特性： 关系（表）的每一元组（行）定义实体集的一个实体，每一列定义实体的一个属性。 每一列表示一个属性（字段），且列名不能重复。 关系必须有一个主键（关键字），用来唯一标识一个元组（行），即实体。 列的每个值必须与对应属性的类型相同。 列是不可分割的最小数据项。 行、列的顺序无关紧要。,第三章 关系型数据库的设计,SQL Server 2008,关系型数据库的定义,关系数据结构： 关系：关系是一个二维表，它必须满足以下特性： 例如客户信息关系：,第三章 关系型数据库的设计,SQL Server 2008,关系型数据库的定义,关系数据结构： 关系模式：关系模式是对关系的结构及其特征的抽象描述，一般由关系名、关系中的属性名及主键构成。 描述方式： 关系名（属性1，属性2，属性n） 有下划线的“属性1”为主键。 例如客户信息： 客户信息（客户ID，客户名称，密码，注册日期，联系人ID，类别，状态，预存费余额）,第三章 关系型数据库的设计,SQL Server 2008,关系型数据库的定义,关系数据操作： 常用的数据操作可分为查询和更新（插入、删除、修改）两大类。其中，查询是最主要也最频繁执行的操作。 关系数据操作的执行过程以关系代数为理论基础。 将数据库的各表视作集合，执行并、交、差和笛卡儿积等集合运算。 专门用于数据库操作的关系运算： 选择运算：从参与运算的关系中选择满足给定条件的那些元组构成一个新关系。 投影运算：从参与运算的关系中选择给定的若干属性构成一个新关系。 连接运算：从两个关系的广义笛卡儿积中选择属性值满足一定条件的元组构成一个新关系。,第三章 关系型数据库的设计,SQL Server 2008,关系型数据库的定义,关系数据完整性约束： 实体完整性（Entity Integrity）： 关系的主属性值不能取空值。 参照完整性（Referential Integrity）： 参照关系（子表）的外键取值不能超出被参照关系（父表）的主键取值。 用户定义的完整性（User-defined Integrity）： 属性取值满足某种条件或函数要求，包括对每个关系的取值限制（或称约束）的具体定义。,第三章 关系型数据库的设计,SQL Server 2008,E-R模型到关系模型的转换,实体（E）的转换： 一个实体转换为一个关系模式，实体的属性就是关系的属性，实体的主键就是关系的主键。 为实体和属性命名时，建议尽量使用英文或拼音，以适应各种数据库管理系统（DBMS）的兼容操作。 例如，客户实体转换为关系模式： 实体：客户信息（客户ID，客户名称，密码，注册日期，类别，状态，预存费余额），其中主键为“客户ID”。 关系：Customer(CID,CName, Cpassword, CRegistrationDate,CType,CStatus,CAccountBalance) PK：CID,第三章 关系型数据库的设计,SQL Server 2008,E-R模型到关系模型的转换,联系（R）的转换： 一对一联系的转换： 将联系与任意端实体所对应的关系模式合并，并加入另一端实体的主键和联系本身的属性。 一对多联系的转换： 方法一：把联系与多的一端实体所对应的关系模式合并，加入一的那端实体的主键和联系的属性。 方法二：联系可独立转换成一个关系模式，其属性包括联系自身的属性以及相连的两端实体的主键。 多对多联系的转换： 实体直接可转换为关系模式，联系则只能独立转换成一个关系模式，其属性包括联系自身的属性以及相连的各实体的主键。,第三章 关系型数据库的设计,SQL Server 2008,E-R模型到关系模型的转换,联系（R）的转换： 【例3-1】 有下列实体，实体之间存在一对一联系，将其转换为关系模式。 客户（客户ID，客户名称，密码，注册日期，类别，状态，预存费余额） 联系人（联系人ID，姓名，身份证号码，职务，地址，通信方式） 关系模型： Customer(CID，CName，RID，CPassword，CRegistrationDate，CType，CStatus，CAccountBalance) PK：CID；FK：RID Relation（RID，RName，RIndentityNo，RDuty，RAddress，RContactinfo） PK：RID,第三章 关系型数据库的设计,SQL Server 2008,E-R模型到关系模型的转换,联系（R）的转换： 【例3-2】客户实体与产品（产品号码，产品名称，购买日期，安装地址，单价）实体存在一对多的购买联系，将其转换为关系模式。 关系模型： 由于客户与产品之间存在的购买联系没有属性，所以使用方法一，将购买联系与产品合并，转换成一个关系模式： Customer(CID，CName，RID，CPassword，CRegistrationDate，CType，CStatus，CAccountBalance) PK：CID；FK：RID EProduct（ENo，EName，CID，EJoinDate，EAddress，EUnivalence） PK：Eno；FK：CID,第三章 关系型数据库的设计,SQL Server 2008,E-R模型到关系模型的转换,联系（R）的转换： 【例3-3】客户实体与产品（产品号码，产品名称，购买日期，安装地址）实体存在一对多的支付联系，支付联系（支付时间，付款方式，对应帐号），将客户、产品和支付联系转换为关系模式。 关系模型： 由于客户与产品之间的支付联系存在属性，所以使用方法二，将支付联系独立转换成一个关系模式： 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 EProduct2（ENo，Ename，EJoinDate，EAddress，EUnivalence） PK：Eno,第三章 关系型数据库的设计,SQL Server 2008,E-R模型到关系模型的转换,联系（R）的转换： 【例3-4】产品实体与附加服务（附加服务ID，附加服务名称，附加服务收费）实体存在多对多的联系，由主产品绑定开通附加服务项目，开通联系有开通时间属性。现将其转换为关系模式。 关系模型： EProduct（ENo，EName，CID，EJoinDate，EAddress，Eunivalence） PK：Eno；FK：CID StartAdditionalService（ENo，ASID，SATime） PK：ENo，ASID；FK：ENo和ASID AdditionalService（ASID，ASitem，ASPrice） PK：ASID,第三章 关系型数据库的设计,SQL Server 2008,关系规范化,关系规范化： 就是能够确保所建立的数据库具有较少的数据冗余、较高的数据共享度、较好的数据一致性，以及较灵活和方便的数据更新能力。 关系模型要求关系必须是规范化的，即必须满足三个范式： 第一范式1NF： 关系表R中的每一个属性（字段）是不可再分的。 第二范式2NF 关系表R是1NF，而且它的每一非主属性（即不是候选码里的属性）完全依赖于全部主属性。 第三范式3NF 关系表R是2NF，而且它的每一非主属性不传递依赖于主属性。 传递依赖的含义是指经由其他属性而依赖于主属性的字段。,第三章 关系型数据库的设计,SQL Server 2008,关系规范化,关系规范化举例： 第一范式1NF： 不符合第一范式： 符合第一范式：,第三章 关系型数据库的设计,SQL Server 2008,关系规范化,关系规范化： 第二范式2NF ： 不符合第二范式： 客户与联系人是一对一联系，可以将它们合并为一个关系表： 客户信息（客户ID，客户名称，密码，注册日期，类别，状态，预存费余额，联系人ID，姓名，身份证号码，职务，地址，电话，邮编，Email，传真）， 主属性有：客户ID，联系人ID，身份证号码。 有非主属性部分依赖主属性的情况。 符合第二范式： 将该关系表分解成客户关系表和联系人关系表： 客户（客户ID，联系人ID，客户名称，密码，注册日期，类别，状态，预存费余额）；主键：客户ID；外键：联系人ID 联系人（联系人ID，姓名，身份证号码，职务，地址，电话，邮编，Email，传真）；主键：联系人ID,第三章 关系型数据库的设计,SQL Server 2008,关系规范化,关系规范化： 第三范式3NF ： 不符合第三范式： 用一个关系表来表示帐单和明细，其关系为： 帐单明细（明细ID，产品号码，客户ID，对方号码，日期，起始时间，持续时间，发生费用，帐单ID，帐单日期，固定费用，通信费用） 主属性有：明细ID。 帐单ID是非主属性，它是依赖于明细ID的，而帐单日期、固定费用、通信费用又是依赖于帐单ID，有传递依赖主属性的情况。 符合第三范式： 将该关系表分解成明细关系表和帐单关系表： 明细： (明细ID，产品号码，对方号码，日期，起始时间，持续时间，发生费用，帐单ID)；主键：明细ID；外键：帐单ID 帐单：（帐单ID，产品号码，客户ID，帐单日期，固定费用，通信费用）；主键：帐单ID,第三章 关系型数据库的设计,SQL Server 2008,关系规范化,数据模型的优化： 关系模型要求关系必须规范化。 设计的数据库逻辑结构必须满足三个范式。 设计步骤： 完成E-R图向关系模式转换 对所建立的关系模式进行三个范式的验证 对不优化的关系要进行拆分： 拆分原则： 概念单一。 数据完整。 尽量减少冗余。 注意：在实际设计中，完全消除冗余是很难做到的。有时为了提高数据检索等处理效率，也允许存在适当的冗余。,第三章 关系型数据库的设计,SQL Server 2008,实训：计费系统的逻辑设计,计费系统概念模型描述： 实体： 客户：客户ID，客户名称，密码，注册日期，客户类别，状态，预存费余额。 联系人：联系人ID，姓名，身份证号码，职务，地址，电话，邮编，Email地址，传真。 产品：产品号码，产品名称，购买日期，安装地址，单价。 附加服务项目：附加服务ID，附加服务名称，附加服务收费。 明细：明细ID，帐单ID，产品号码，对方号码，日期，起始时间，持续时间，发生费用。 帐单：帐单ID，客户ID，产品号码，帐单日期，固定费用，通信费用。 存在自身属性的联系： 支付：支付时间，付款方式，对应帐号。 开通：开通时间。,第三章 关系型数据库的设计,SQL Server 2008,实训：计费系统的逻辑设计,计费系统概念模型描述： 联系： 客户与联系人的一对一联系： 客户、产品、明细及帐单的一对多联系： 产品与附加服务的多对多联系：,第三章 关系型数据库的设计,SQL Server 2008,实训：计费系统的逻辑设计,E-R图向关系模式转换： 按照概念模型的描述，完成向关系模式的转换。 转换原则： 一个实体转换为一个关系模式。 按照联系的一对一、一对多、多对多的分类类型，其转换方法不同。 遵从三范式的准则。 数据模型的优化： 根据转换原则和三范式的准则完成E-R图向关系模式的转换后，还应该对得到的关系模式进行优化，可以尽量减少数据冗余，但不能完全消除冗余。 目标：根据计费系统的业务需求，对关系模式进行合理优化。,第三章 关系型数据库的设计,SQL Server 2008,使用Powerdesigner进行逻辑设计,PowerDesigner的物理数据模型（PDM）是定义模型的物理实现细节，与具体的数据库管理系统有关。 在PowerDesigner中建立PDM有三种方式： 直接新建物理模型。 设计好概念模型，然后由概念模型生成物理模型。 设计好逻辑模型，然后由逻辑模型生成物理模型。 注意：在此只介绍使用前两种方式建立PDM。,第三章 关系型数据库的设计,SQL Server 2008,使用Powerdesigner进行逻辑设计,在PowerDesigner中直接新建PDM： 新建PDM步骤： 启动PowerDesigner，并新建一个工程。 新建PDM： 在PowerDesigner窗口中选择“File”“New Model”； 在 “Model Type”中选择“Physical Data Model”。 创建表： 添加表图标：单击“表”按钮，然后在模型设计面板中单击一次便可添加一个表图标； 是创建表按钮； 是创建外键按钮。,第三章 关系型数据库的设计,SQL Server 2008,使用Powerdesigner进行逻辑设计,在PowerDesigner中直接新建PDM： 新建PDM步骤： 启动PowerDesigner，新建工程。 新建PDM。 创建表： 添加表图标； 定义表属性：双击一个表图标，打开表属性窗口，在选项卡“General” 中可以设置表的Name、Code等属性。 Name是在模型中显示的名称；Code是生成数据库时的实际表名。,第三章 关系型数据库的设计,SQL Server 2008,使用Powerdesigner进行逻辑设计,在PowerDesigner中直接新建PDM： 新建PDM步骤： 定义表主键： 定义单列主键：在“Columns”选项卡中，直接选中主键列的P列复选框。 定义自增主键：选中要设为自增主键的列，单击工具栏的“属性”按钮 ，选中Identity复选框，如图所示。 定义多列主键： 切换到“Keys”选项卡中，添加一行命名为PK_CID，单击工具栏的“属性”按钮，打开键属性窗口，在该窗口中切换到“Columns”选项卡，单击添加列按钮，弹出列选择窗口，选中主键中应该包含的列。,第三章 关系型数据库的设计,SQL Server 2008,使用Powerdesigner进行逻辑设计,在PowerDesigner中直接新建PDM： 新建PDM步骤： 启动PowerDesigner，并新建一个工程。 新建PDM。 创建表。 定义表主键。 定义表的外键： 通过PDM工具选项板的Reference按钮 来建立两表间的外键。 例如，客户表和帐单表是一对多的关系，在帐单表中添加CID列作为外键列的操作： 在PDM工具选项板中单击“Reference”按钮； 单击帐单表； 拖拽到客户表中放开鼠标。,第三章 关系型数据库的设计,SQL Server 2008,使用Powerdesigner进