看这篇文章之前，希望大家能够对数据库系统、数据模型有知识储备，如果有疑惑可以看我的另外一篇博客数据库系统。 还需要对关系型数据库基础知识有所了解，有疑惑朋友可以看关系型数据库基础知识

看下面的示例：

这里需要注意联系和实体一样是要存储起来的，所以要创建联系是要谨慎！联系不能有增删改原因请看下图： 如果管理员删除P0001，那么商品中就没有P0001，那么管理联系表中就不会有P0001不满足参照完整性，所以管理不能成为联系，而应该是中间没有，直接将管理员拥有管理权限就行，不需要将管理设置为联系。就是说不能将实体的功能当做联系 在下面这个ER图中，因为需要实现不同的功能，所以点赞数可以是联系也可以是功能： ➢ 作为联系：如果我们要存储哪个用户点赞了哪条动态，则要把点赞当作联系来处理。 ➢ 作为功能：若并不要存储哪个用户点赞了哪条动态，只想记录某条动态的点赞数，则把点赞当作功能来处理，在动态实体上加一属性点赞数。

❖ 某工厂开发信息系统，经过可行性分析，详细调查确定了该系统由 物资管理、销售管理、劳动人事管理等子系统组成。 ❖ 下面分别设计各子系统的分E-R图。

❖先设计该E-R图的草图： 数据结构中订单、顾客、顾客应收账目、 产品是许多子功能、数据流共享的数据， 因此设计为实体。 （如右图所示） ❖再对E-R图进行详细设计和调整：参照需求分析和数据字典中的详尽描述， 遵循前面给出的两个准则。 （1）每张订单由订单号、若干头信息和订单细节组成。订单细节又有订货 的零件号、数量等来描述。按照准则（2），订单细节就应该上升为实体。 一张订单可以订若干产品，订单与订单细节两个实体之间是1∶n的联系。 （2）原订单和产品的联系实际上是订单细节和产品的联系，增加了一个联系—参照2。订单处理时从中获得当前单价、产品重量等信息。 （3）工厂对大宗订货给予优惠。每种产品都规定了不同订货数量的折扣，应增加一个实体—“折扣规则” 存放这些信息。 ◼ 对每个实体定义的属性如下： ➢ 顾客：{顾客号，顾客名，地址，电话，信贷状况，账目余额} ➢ 订单：{订单号，顾客号，订货项数，订货日 期，交货日期，工种号，生产地点} ➢ 订单细则：{订单号，细则号，零件号，订货 数，金额} ➢ 应收账款：{顾客号，订单号，发票号，应收 金额，支付日期，支付金额，当前余额，货款 限额} ➢ 产品：{产品号，产品名，单价，重量} ➢ 折扣规则：{产品号，订货量，折扣}

➢ E-R图的集成一般需要分两步 ◼合并。解决各分E-R图之间的冲突，将分E-R图合并，生成 初步E-R图。 ◼修改和重构。消除不必要的冗余，生成基本E-R图。 合并E-R图，生成初步E-R图 ◼ 各个局部应用所面向的问题不同，各个子系统的E-R图之间必定会存在 许多不一致的地方，称之为冲突。 ◼ 子系统E-R图之间的冲突主要有三类： ①属性冲突 ②命名冲突 ③结构冲突

① 属性冲突 ➢属性域冲突，即属性值的类型、取值范围或取值集合不同。 ◼ 例如零件号，有的部门把它定义为整数，有的部门把它定义为字符型。 ◼ 年龄，某些部门以出生日期形式表示职工的年龄，有的用整数表示职工的年龄。 ➢属性取值单位冲突 ◼ 例如零件的重量有的以公斤为单位，有的以斤为单位，有的以克为单位。 ② 命名冲突 ➢同名异义，即不同意义的对象在不同的局部应用中具有相同的名字。 ➢异名同义（一义多名），即同一意义的对象在不同的局部应用中具有不 同的名字。 ◼ 如对科研项目，财务科称为项目，科研处称为课题，生产管理处称为工程。 ➢命名冲突 ◼ 可能发生在实体、联系一级上 ◼ 也可能发生在属性一级上 ◼ 通过讨论、协商等行政手段加以解决 ③ 结构冲突 ➢同一对象在不同应用中具有不同的抽象。 ◼ 例如，职工在某一局部应用中被当作实体，而在另一局部应用中被当作属性。 ◼ 解决方法：把属性变换为实体或把实体变换为属性，使同一对象具有相同的抽象。 ➢同一实体在不同子系统的E-R图中的属性个数和属性排列次序不完全相同。 ◼ 解决方法：取各子系统的E-R图中属性的并集，再适当调整属性的次序。 ➢实体间的联系在不同的E-R图中为不同的类型。 ◼ 例如，实体E1与E2在一个E-R图中是多对多联系，在另一个E-R图中是一对多联系 ◼又如，在某E-R图中E1与E2发生联系，而在另一个E-R图中E1、E2、E3三者有联系 ◼ 解决方法：根据应用的语义对实体联系的类型进行综合或调整。 （2）消除不必要的冗余，设计基本E-R图 ◼ 冗余的数据是指：可由基本数据导出的数据 ◼ 冗余的联系是指：可由其他联系导出的联系 ◼ 冗余带来的问题：破坏数据库的完整性，数据库维护困难，应当予以消除 ◼ 消除冗余方法：

逻辑结构设计的任务 ➢ 把概念结构设计阶段设计好的基本E-R图转换为与选用的DBMS产品所支持的逻辑结构。 ➢ 目前主要使用关系模型，关系模型的逻辑结构是一组关系模式的集合。

➢ 转换内容 ◼ 将E-R图转换为关系模型：就是将实体型、实体的属性和实体型之间的联系转化为关系模式。 ➢ 转换原则 ◼ 实体型的转换 ◼ 实体型之间联系的转换

❖ 数据库逻辑设计的结果不是唯一的。 ❖ 得到初步数据据模式后，还应该适当地修改、调 整数据库逻辑结构，以进一步提高数据库应用系统的性能，这就是数据模型的优化。 ❖ 关系数据模型的优化通常以规范化理论为指导。(范式)

❖ 数据库模式——全局模式。 考虑系统全局应用需求，时间效率、空间效率、易维护等。 ❖ 用户子模式——视图机制 考虑局部应用的特殊需求和用户人习惯与方便。包括： （1）使用更符合用户习惯的别名 ➢ 合并各分E-R图曾做了消除命名冲突的工作，以使数据库系统中同一关 系和属性具有唯一的名字。这在设计数据库整体结构时是非常必要的。 ➢ 在设计用户子模式时可以设计子模式时重新定义某些属性名，使其与用户习惯一致，以方便使用。 （2）针对不同级别的用户定义不同的视图，提高系统的安全性假设有关系模式: 产品（产品号，产品名，规格，单价，生产车间，生产负责人，产品成本，产品合格率，质量等级） ➢ 为一般顾客建立视图： 产品1（产品号，产品名，规格，单价） ➢ 为产品销售部门和管理部门建立视图： 产品2（产品号，产品名，规格，单价，生产车间，生产负责人） （3）简化用户对系统的使用 ➢ 某些局部应用中经常要使用一些很复杂的查询，为了方便用户，可以将这些复 杂查询定义为视图。 数据设计完整例子