作者：whisper

链接：http://proprogrammar.com:443/article/586

声明：请尊重原作者的劳动，如需转载请注明出处

    7.3.5 概念结构设计

    讲解：
    1．实体与属性的划分原则

• 对需求分析阶段收集到的数据进行分类、组织
• 确定实体、实体的属性、实体之间的联系类型

    2． E-R图的集成

• 设计各个子系统的分E-R图
• 消除冲突，进行集成
• 设计基本E-R图

    1. 实体与属性的划分原则

• 现实世界的事物能作为属性对待的，尽量作为属性对待。

    可以简化E-R图的处置

• 划分实体与属性的两条准则：

    （1）作为属性，不能再具有需要描述的性质。属性必须是不可分的数据项，不能包含其他属性。
    （2）属性不能与其他实体具有联系。
    E-R图中所表示的联系是实体与实体之间的联系。 

    实体与属性的划分

    [例1] 职工实体：职工号、姓名、年龄是职工的属性，如何设计职称？

• 如果不存储和处理与职称相关的工资、福利，根据准则（1）设计为职工的属性。
• 如果需要存储或处理：与职称相关的工资、津贴、附加福利等，则职称应设计为一个实体。

    [例2] 医院中病人实体，如何设计病房？

• 一个病人只能住在一个病房，病房号可以作为病人实体的一个属性；
• 如果病房还要与医生实体发生联系，即一个医生负责若干病房的病人的医疗工作则根据准则（2） 病房应作为一个实体。

    [例3] 货物实体，如何设计仓库？

• 如果一种货物只存放在一个仓库，可以把仓库号作为描述货物存放地点的属性。
• 如果一种货物可以存放在多个仓库中，或者仓库本身又用面积作为属性，或者仓库与职工发生管理上的联系，那么就应把仓库作为一个实体。

    2． E-R图的集成

    设计各个子系统的分E-R图

    某工厂开发信息系统，经过可行性分析，详细调查确定了该系统由物资管理、销售管理、劳动人事管理等子系统组成。
    [例7.1] 销售管理子系统E-R图的设计
    该子系统的主要功能是：

• 处理顾客和销售员送来的订单
• 工厂是根据订货安排生产的
• 交出货物同时开出发票
• 收到顾客付款后，根据发票存根和信贷情况进行应收款处理

    通过需求分析，知道销售子系统功能围绕“订单”和“应收账款”的处理来实现。

    先设计该E-R图的草图：
    数据结构中订单、顾客、顾客应收账目、产品是许多子功能、数据流共享的数据，因此设计为实体。（如图7.22所示）

    再对E-R图进行详细设计和调整：
    参照需求分析和数据字典中的详尽描述，遵循前面给出的两个准则。

    图7.22 分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图

（1）合并E-R图，生成初步E-R图

• 各个局部应用所面向的问题不同，各个子系统的E-R图之间必定会存在许多不一致的地方，称之为冲突。
• 子系统E-R图之间的冲突主要有三类：

    ①属性冲突
    ②命名冲突
    ③结构冲突

    ①属性冲突

• 属性域冲突，即属性值的类型、取值范围或取值集合不同。

    例如零件号，有的部门把它定义为整数，有的部门把它定义为字符型。
    年龄，某些部门以出生日期形式表示职工的年龄，有的用整数表示职工的年龄。

• 属性取值单位冲突。

    例如零件的重量有的以公斤为单位，有的以斤为单位，有的以克为单位。

    ②命名冲突

• 同名异义，即不同意义的对象在不同的局部应用中具有相同的名字。
• 异名同义（一义多名），即同一意义的对象在不同的局部应用中具有不同的名字。

    如对科研项目，财务科称为项目，科研处称为课题，生产管理处称为工程。

• 命名冲突

    可能发生在实体、联系一级上
    也可能发生在属性一级上
    通过讨论、协商等行政手段加以解决

    ③结构冲突

• 同一对象在不同应用中具有不同的抽象。

    例如，职工在某一局部应用中被当作实体，而在另一局部应用中被当作属性。
    解决方法：把属性变换为实体或把实体变换为属性，使同一对象具有相同的抽象。

• 同一实体在不同子系统的E-R图中的属性个数和属性排列次序不完全相同。

    解决方法：取各子系统的E-R图中属性的并集，再适当调整属性的次序。

• 实体间的联系在不同的E-R图中为不同的类型。

    例如，实体E1与E2在一个E-R图中是多对多联系，在另一个E-R图中是一对多联系
    解决方法是根据应用的语义对实体联系的类型进行综合或调整。

    合并E-R图 生成初步E-R图

    E-R图的集成

    E-R图的集成一般需要分两步

• 合并。 解决各分E-R图之间的冲突，将分E-R图合并，生成初步E-R图。
• 修改和重构。 消除不必要的冗余，生成基本E-R图。

     设计 基本E-R图

    （1）合并E-R图，生成初步E-R图
    （2）消除不必要的冗余，设计基本E-R图
    冗余的数据是指：可由基本数据导出的数据
    冗余的联系是指：可由其他联系导出的联系
    冗余带来的问题：破坏数据库的完整性，数据库维护困难，应当予以消除
    消除冗余方法：

• 分析方法
• 规范化理论的方法

    以数据字典和数据流图为依据，根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。 

    并不是所有的冗余数据与冗余联系都必须加以消除，有时为了提高效率，不得不以冗余信息作为代价。

    用规范化理论来消除冗余
    ①确定分E-R图实体之间的数据依赖。

• 实体之间一对一、一对多、多对多的联系可以用实体码之间的函数依赖来表示。于是有函数依赖集FL

    ②求FL的最小覆盖GL ，差集为 D= FL - GL

• 逐一考察D中的函数依赖，确定是否是冗余的联系，若是，就把它去掉

    应注意的问题：

• 冗余的联系一定在D中，而D中的联系不一定是冗余的；
• 当实体之间存在多种联系时，要将实体之间的联系在形式上加以区分。

    部门和职工之间一对多的联系
    可表示为：
    职工号→部门号
    职工和产品之间多对多的联系
    可表示为
    （职工号，产品号） →工作天数
    职工和产品之间一对一的联系
    负责人.职工号→产品号
    产品号→负责人.职工号
    等。

    [例7.2] 某工厂管理信息系统的视图集成。

    图7.11 工厂物资管理子系统的E-R图

    图7.23 销售管理子系统的E-R图

    图7.27 劳动人事管理子系统的E-R图

    异名同义：项目和产品含义相同。某个项目实质上是指某个产品的生产。统一用产品作实体名。
    库存管理中职工与仓库的工作关系已包含在劳动人事管理的部门与职工之间的联系之中，所以可以取消。
    职工之间领导与被领导关系可由部门与职工（经理）之间的领导关系、部门与职工之间的从属关系两者导出，所以也可以取消。

亲爱的读者：有时间可以点赞评论一下