逻辑数据库设计 - 多态关联

先说明什么是多态关联。

假设我们有一张地址表，其中的地址可能是对于User中的，也可能是对于Orders中的。

以上，只是举个例子，实际的例子还有很多，比如我们要设计一个内容管理系统(CMS)，我们的CMS有一个文章表，一个软件表。还要求支持评论，那么我们的评论表的Id是引用文章表还是引用软件表呢？

对于以上例子的缺点，貌似书本上有故意为此多态关联的模式走软的嫌疑。缺点不说了，主要是查询麻烦，其次不能够支持外键约束。

交叉表

对于这种需要外键引用为多个表的情况，可以建立一张交叉表。让Address不再依赖Orders或Users。

优点：

引用完整性支持。

缺点：

如果我们希望一个给定的地址，只能够在一张交叉表中出现一次，上面的复合主键已经做到了。如果希望一个地址可以在一张交叉表中出现多次，可以取消复合主键。但是不能够保证一个地址不在多张交叉表中出现，这需要我们再程序代码中实现。

实际上，多态关联与上篇文章提到的，实体-属性-值有关系。

如果前面采用的是类表的设计，根本不会出现这个问题，上面的地址，也可以依赖倒置。比如在Order表中添加一个AddressId、User表中添加一个AddressId解决。

假设，采用类表继承的方法。直接将Address用外键指向基表就OK了根本就没这个问题。书中的这一篇写得有点莫名其妙。既然我已经写完了，算了，不管了。

逻辑数据库设计 - 多态关联

标签：

小编还为您整理了以下内容，可能对您也有帮助：

数据库逻辑设计的主要工作是什么？

将E-R图转换到关系模式时，实体与联系都可以表示成：关系。

数据库逻辑设计的主要工作是将E－R图转换成指定RDBMS中的关系模式。首先，从E－R图到关系模式的转换是比较直接的，实体与联系都可以表示成关系，E－R图中属性也可以转换成关系的属性。实体集也可以转换成关系。

E－R图提供了表示实体类型、属性和联系的方法，用来描述现实世界的概念模型。

注意事项：

实体－联系数据模型中的联系型，存在3种一般性约束：一对一约束（联系）、一对多约束（联系）和多对多约束（联系），它们用来描述实体集之间的数量约束：

（1）一对一接触（1：1）

对于两个实体集A和B，如果A中的每个值在B中最多有一个对应的实体值，反之亦然，则称为实体集A和实体集B具有A一一对应关系。

一个学校只有一个校长，一个校长只服务一个学校，所以学校和校长之间是一对一的联系。

（2）一对多连接（1∶N）

对于A和B两个实体集，如果每个值在一个有多个实体在B值对应于它，反之，每个实体价值B最多一个实体对应的价值，然后实体集A和B是一对多的关系。

例如，在一所学校里，教师与课程“教学”是一对多的关系，即每位教师可以教授几门课程，但每门课程只能由一位教师教授。一个专业有几个学生，每个学生只学习一个专业，那么专业和学生之间就有一对多的联系

数据库逻辑结构设计包含哪些内容

逻辑结构设计是将概念结构设计阶段完成的概念模型，转换成能被选定的数据库管理系统(DBMS)支持的数据模型。这里主要将E-R模型转换为关系模型。需要具体说明把原始数据进行分解、合并后重新组织起来的数据库全局逻辑结构，包括所确定的关键字和属性、重新确定的记录结构和文件结构、所建立的各个文件之间的相互关系，形成本数据库的数据库管理员视图。

逻辑结构设计一般分为三步进行：

1.从E-R图向关系模式转化数据库的逻辑设计主要是将概念模型转换成一般的关系模式，也就是将E-R图中的实体、实体的属性和实体之间的联系转化为关系模式。在转化过程中会遇到如下问题：

(1)命名问题。命名问题可以采用原名，也可以另行命名，避免重名。

(2)非原子属性问题。非原子属性问题可将其进行纵向和横行展开。

(3)联系转换问题。联系可用关系表示。

2.数据模型的优化数据库逻辑设计的结果不是唯一的。为了进一步提高数据库应用系统的性能，还应该适当修改数据模型的结构，提高查询的速度。

3.关系视图设计关系视图的设计又称为外模式的设计，也叫用户模式设计，是用户可直接访问的数据模式。同一系统中，不同用户可有不同的关系视图。关系视图来自逻辑模式，但在结构和形式上可能不同于逻辑模式，所以它不是逻辑模式的简单子集。

关系视图主要有三个作用：

(1)通过外模式对逻辑模式的屏蔽，为应用程序提供了一定的逻辑性。

(2)更好地适应不同用户对数据的不同需求。

(3)为不同用户划定了访问数据的不同范围，有利于数据的保密。

数据库设计的基本步骤

数据库设计的基本步骤如下：

1、需求分析阶段

准确理解和分析用户需求（包括数据和处理），它是整个设计过程的基础，也是最困难、最耗时的一步。

2、概念结构设计阶段

是整个数据库设计的关键，通过对用户需求的集成、归纳和抽象，形成了一个于特定数据库管理系统的概念模型。

3、逻辑结构设计阶段

将概念结构转换为DBMS支持的数据模型，对其进行优化。

4、数据库物理设计阶段

为逻辑数据模型选择最适合应用程序环境的物理结构（包括存储结构和存取方法）。

5、数据库实现阶段

根据逻辑设计和物理设计的结果，使用数据库管理系统提供的数据语言、工具和主机语言，建立数据库，编写调试应用程序，组织数据仓库，并进行试运行。

6、数据库运行维护阶段

数据库应用系统经试运行后可投入正式运行，在数据库系统运行过程中，需要不断地对其进行评估、调整和修改。

注：在设计过程中，将数据库的设计与数据库中数据处理的设计紧密结合起来，在每个阶段同时对这两个方面的要求进行分析、抽象、设计和实现，相互借鉴和补充，从而完善这两个方面的设计。

扩展资料：

数据库设计技术

1、清晰的用户需求：作为计算机软件开发的重要基础，数据库设计直接反映了用户的需求。数据库必须与用户紧密沟通，紧密结合用户需求。在定义了用户开发需求之后，设计人员还需要反映具体的业务关系和流程。

2、注意数据维护：设计面积过大、数据过于复杂是数据库设计中常见的问题，设计人员应注意数据维护。

3、增加命名规范化：命名数据库程序和文件非常重要，不仅要避免重复的名称，还要确保数据处于平衡状态。为了降低检索信息和资源的复杂度和难度，设计人员应了解数据库程序与文件之间的关系，并灵活使用大小写字母命名。

数据库设计多对多关系的几种形态

数据库设计多对多关系的几种形态 前言：多对多关系至少需要3个表，我们把一个表叫做主表，一个叫做关系表，另外一个叫做字典表或者副表（字典表是纪录比较少，而且基本稳定的，例如：版块名称；副表是内容比较多，内容变化的，例如）。 www.2cto.com 按照数数据库设计多对多关系的几种形态

前言：多对多关系至少需要3个表，我们把一个表叫做主表，一个叫做关系表，另外一个叫做字典表或者副表（字典表是纪录比较少，而且基本稳定的，例如：版块名称；副表是内容比较多，内容变化的，例如）。 www.2cto.com

按照数据库的增删查改操作，多对多关系的查找都可以用inner join或者select * from 主表 where id in (select 主表id from 关系表)

1，角色任命型

特点：关系表两外键组合无重复纪录，关系表一般不需要时间字段和主键，有一个表是字典类型的表。

界面特点：显示主表，用checkbox或多选select设置多选关系。

例如：任命版主（用户表-关系表-版块名称表），角色权限控制等，用户是5个版块版主，只要关系表5行纪录就可以确立，关系表的两个外键具有联合主键性质。

增加关系：如果没有组合纪录，insert之。

删除关系：如果有组合纪录，删除之。

2，集合分组型

特点：同角色任命型类似，关系表两外键组合无重复纪录，关系表一般不需要时间字段和主键。区别是主副表都不是字典表，可能都很大不固定。

界面特点：显示主表，用搜索代替简单的checkbox或多选select，或者一条一条的添加。

例如：歌曲专集（专集表-关系表-歌曲表）。手机分组（分组表-关系表-手机表）。用户圈子（圈子表-关系表-用户表）。文章标签（文章表-关系表-标签表）

增加关系：同版主任命型。

删除关系：同版主任命型。

3，明细帐型

特点：关系表可以有重复纪录，关系表一般有时间字段，有主键，可能还有文字型的字段用来说明每次发生关系的原因（消费）。

界面特点：显示关系表，用radio或下拉设置单选关系。

例如：现金消费明细帐或订单（用户表-订单表-消费原因表），用户可能多次在同一事情上重复消费。积分变化纪录也属于这类。

增加关系：不管有没有组合纪录，insert之，纪录时间。

删除关系：根据关系表PK删除。

4，评论回复型

特点：同明细帐型关系表一般有时间字段，有主键，区别是重点在文字型的字段用来说明每次发生关系的内容（评论回复）。

界面特点：回复文本框。

例如：论坛回复（用户表-回复表-帖子表），用户可能多次在不同帖子上评论回复费。

增加关系：不管有没有组合纪录，insert之，纪录时间和文字。

删除关系：根据关系表（回复表）PK删除。

5，站内短信型

特点：主副表是同一个，关系表一般有时间字段，有主键，重点在关系表文字型的字段用来说明每次发生关系的内容（消息）或者其他标记位来表示文字已读状态时间等。

界面特点：回复文本框。

例如：站内短信（用户表-短信表-用户表），用户可能给用户群发或者单发，有标记位来表示文字已读状态时间等。

增加关系：不管有没有组合纪录，insert之，纪录时间和文字。

删除关系：根据关系表（回复表）PK删除。

6，用户好友型

特点：主副表是同一个，同集合分组型，关系表两外键组合无重复纪录，关系表一般不需要时间字段和主键。

界面特点：同集合分组型，显示主表，用搜索代替简单的checkbox或多选select，或者一条一条的添加。

例如：下载站点的文件，（文件表-关系表-文件表）可以被软件工具打开，软件工具本身也是一种文件，可以被下载。用户的好友，也是用户（用户表-好友关系表-用户表）

增加关系：同版主任命型。

删除关系：同版主任命型。

7，未知属性型

特点：在设计初期，主表的某些字段类型和名称是不确定的时候，关系表实际上是主表的可扩展字段，

一个[主表]（ID），

一个[属性名称表]（属性ID.属性名称)，

一个[属性值表]，包括3个字段：

属性值(属性Value varchar(500))

主表ID

属性ID

这样可以作到最小冗余度。

（和常见的多对多关系不同的是：值统一用varchar来存储，因为这类型的值一般不会用来计算）。

比如：

军队的数据库设计中有种物资叫做“战缴物资”，就是打仗的时候缴获的，军队自己都不知道这些物资有什么属性。

比如缴获的化学品有化学名，通用名，是否有辐射，计量单位，包装规格，数量等等，或者不是化学品是其他任何未知的东西。

这样东西就可以

某奇怪东西.属性集合["某某奇怪属性名"]="某某奇怪值"；

某东西.属性集合["某某属性名"]="某某值"；

这样存储。

再比如：

手机型号有几千种，除了共同属性外还有不同属性有几百个，属性名和值类型都不一样，有的手机有这属性，有的没有。

对于这样的“多态”，我们就采用上面的设计结构。

其效果相当于：

某奇怪手机.属性集合["某某奇怪属性名"]="某某奇怪值"；

某手机.属性集合["某某属性名"]="某某值"；

界面特点：设置主表一行纪录的属性时候，要列出所有可能的属性名称，每个对应一个文本框。

总结这个的目的是做通用的后台。

只要有：

1，通用的单个表维护（1-2种）。

2，通用的一对多关系维护（1-2种）。

3，通用的多对多关系维护（7-10种）。

4，通用的树型关系维护（2-3种）。

就大体完成了后台的80%工作。

而且，所有项目通用，如果一个团队同时有多个项目，可以节省大量劳动时间。