数据库的逻辑结构设计的图向关系

模型的转换 E-R图如何转换为关系模型呢？我们先看一个例子。

图21是学生和班级的E-R图，学生与班级构成多对一的联系。根据实际应用，我们可以做出这个简单例子的关系模式：

学生（学号，姓名，班级）

班级（编号，名称）

“学生班级”为外键，参照“班级编号”取值。

这个例子我们是凭经验转换的，那么里面有什么规律呢？在22节，我们将这些经验总结成一些规则，以供转换使用。 (1)一个实体型转换为一个关系模式

一般E-R图中的一个实体转换为一个关系模式，实体的属性就是关系的属性，实体的码就是关系的码。

(2)一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。

图22是一个一对一联系的例子。根据规则（2），有三种转换方式。

(i) 联系单独作为一个关系模式

此时联系本身的属性，以及与该联系相连的实体的码均作为关系的属性，可以选择与该联系相连的任一实体的码属性作为该关系的码。结果如下：

职工（工号，姓名）

产品（产品号，产品名）

负责（工号，产品号）

其中“负责”这个关系的码可以是工号，也可以是产品号。

(ii) 与职工端合并

职工（工号，姓名，产品号）

产品（产品号，产品名）

其中“职工产品号”为外码。

(iii) 与产品端合并

职工（工号，姓名）

产品（产品号，产品名，负责人工号）

其中“产品负责人工号”为外码。

(3)一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。

(i) 若单独作为一个关系模式

此时该单独的关系模式的属性包括其自身的属性，以及与该联系相连的实体的码。该关系的码为n端实体的主属性。

顾客（顾客号，姓名）

订单（订单号，……）

订货（顾客号，订单号）

(ii) 与n端合并

顾客（顾客号，姓名）

订单（订单号，……，顾客号）

(4)一个m:n联系可以转换为一个独立的关系模式。

该关系的属性包括联系自身的属性，以及与联系相连的实体的属性。各实体的码组成关系码或关系码的一部分。

教师（教师号，姓名）

学生（学号，姓名）

教授（教师号，学号）

(5)一个多元联系可以转换为一个独立的关系模式。

与该多元联系相连的各实体的码，以及联系本身的属性均转换为关系的属性，各实体的码组成关系的码或关系码的一部分。

(6)具有相同码的关系模式可以合并。

(7)有些1：n的联系，将属性合并到n端后，该属性也作为主码的一部分

这类问题多出现在聚集类的联系中，且部分实体的码只能在某一个整体中作为码，而在全部整体中不能作为码的情况下才出现（其它情况本人还没碰到，呵呵，欢迎指教）。

比如上篇文章介绍的管理信息系统中订单与订单细节的联系。

关于什么是聚集，23节介绍。 这部分本应在概念设计中介绍的，用到了才想起来，这里补充一下。

关于现实世界的抽象，一般分为三类：

（1） 分类：即对象值与型之间的联系，可以用“is member of”判定。如张英、王平都是学生，他们与“学生”之间构成分类关系。

（2） 聚集：定义某一类型的组成成分，是“is part of”的联系。如学生与学号、姓名等属性的联系。

（3） 概括：定义类型间的一种子集联系，是“is subset of”的联系。如研究生和本科生都是学生，而且都是集合，因此它们之间是概括的联系。

例：猫和动物之间是概括的联系，《Tom and Jerry》中那只名叫Tom的猫与猫之间是分类的联系，Tom的毛色和Tom之间是聚集的联系。

订单细节和订单之间，订单细节肯定不是一个订单，因此不是概括或分类。订单细节是订单的一部分，因此是聚集。 有了关系模型，可以进一步优化，方法为：

（1） 确定数据依赖。

（2） 对数据依赖进行极小化处理，消除冗余联系（参看范式理论）。

（3） 确定范式级别，根据应用环境，对某些模式进行合并或分解。

以上工作理论性比较强，主要目的是设计一个数据冗余尽量少的关系模式。下面这步则是考虑效率问题了：

（4） 对关系模式进行必要的分解。

如果一个关系模式的属性特别多，就应该考虑是否可以对这个关系进行垂直分解。如果有些属性是经常访问的，而有些属性是很少访问的，则应该把它们分解为两个关系模式。

如果一个关系的数据量特别大，就应该考 虑是否可以进行水平分解。如一个论坛中，如果设计时把会员发的主贴和跟贴设计为一个关系，则在帖子量非常大的情况下，这一步就应该考虑把它们分开了。因为 显示的主贴是经常查询的，而跟贴则是在打开某个主贴的情况下才查询。又如手机号管理软件，可以考虑按省份或其它方式进行水平分解。 这部分主要是考虑使用方便性和效率问题，主要借助视图手段实现，包括：

（1） 建立视图，使用更符合用户习惯的别名。

（2）对不同级别的用户定义不同的视图，以保证系统的安全性。

（3）对复杂的查询 *** 作，可以定义视图，简化用户对系统的使用。

物理设计主要工作是选择存取方法（索引），以及确定数据库的存储结构，这里就不说明了。

数据库管理员的任务。

设计关系模式是数据库管理员的任务，它的目的是将数据存储在一个有效的方式，以便用户可以容易地访问和检索它们，关系模式定义了数据库中不同表之间的关系，并指定了每个表中包含的字段，以及字段之间的关系。

关系数据库是一种数据库，它将数据存储在不同的表中，使用关系来表示数据之间的关系，允许用户跨多个表查询数据。

其实微信朋友圈的数据库设计模式无非就是符合了三种设置模式，其中最常用的是第三种。

第一范式（1NF）

在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。

所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。例如，对于图3-2 中的员工信息表，不能将员工信息都放在一列中显示，也不能将其中的两列或多列在一列中显示；员工信息表的每一行只表示一个员工的信息，一个员工的信息在表中只出现一次。简而言之，第一范式就是无重复的列。

第二范式（2NF）

第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。如图3-2 员工信息表中加上了员工编号（emp_id）列，因为每个员工的员工编号是惟一的，因此每个员工可以被惟一区分。这个惟一属性列被称为主关键字或主键、主码。

第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。简而言之，第二范式就是非主属性非部分依赖于主关键字。

第三范式（3NF）

满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在图3-2的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性。

利用ER方法进行数据库的概念设计,可分成三步进行:首先设计局部ER模式,然后把各局部ER模式综合成一个全局模式,最后对关系数据库的逻辑设计 由于概念设计的结果是ER图,DBMS一般采用关系型,因此数据库的逻辑设计过程就是把ER图转化为关系

以上就是关于数据库的逻辑结构设计的图向关系全部的内容，包括:数据库的逻辑结构设计的图向关系、在关系数据库设计中设计关系模式是谁的任务、微信朋友圈数据库模式如何设计的等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！