7.3 概念结构设计

思维导图：

 

 

7.3 概念结构设计

概念结构设计的定义

• 过程：将需求分析得到的用户需求转化为信息结构（即概念模型）的过程。
• 重要性：这是整个数据库设计过程中的关键阶段。

7.3.1 概念模型

1. 从需求到概念模型：

   • 需求分析得到的应用需求首先抽象为信息世界的结构，作为数据库管理系统实现的基础。

2. 概念模型的特点：

   • 真实反映现实世界：包括实体之间的关系，满足用户数据处理需求。
   • 易于理解：便于与不熟悉计算机的用户沟通和交换意见。
   • 易于更改和扩充：能够适应应用环境和要求的变化。
   • 易于转换到不同数据模型：如关系、网状、层次等数据模型。

3. 概念模型与数据模型：

   • 概念模型比数据模型更独立于机器、更抽象，因此更稳定。
   • 描述概念模型的工具：E-R模型（实体-关系模型）。

我的理解：

理解7.3节《概念结构设计》的内容，关键在于把握概念模型在数据库设计中的重要角色及其特性。这一节的内容可以从以下几个方面来理解：

1. 概念结构设计的目的：

   • 将需求分析阶段得到的用户需求转化为信息结构，即概念模型。这是把用户的实际需求抽象成一个可被数据库系统实现的模型的过程。

2. 概念模型的特性：

   • 真实性：概念模型应真实、充分地反映现实世界的情况，包括各种实体及其相互关系，确保能满足用户对数据的处理要求。
   • 易理解性：概念模型应该易于理解，使得非技术背景的用户也能参与数据库设计讨论。
   • 灵活性：概念模型应易于更改和扩充，以适应应用环境和需求的变化。
   • 转换性：概念模型应能够方便地转换为各种具体的数据模型（如关系、网状、层次模型）。

3. 概念模型与数据模型的关系：

   • 概念模型是更为抽象的层面，独立于具体的数据库技术和机器，提供了一个更稳定的视角来观察数据和数据间的关系。

4. E-R模型的应用：

   • E-R模型（实体-关系模型）是描述概念模型的一个常用工具，它通过实体和实体间的关系来表达信息结构。

7.3.2 E-R模型

E-R模型简介

• 定义：由 P.P.S. Chen 提出，用于描述现实世界的概念模型。
• 组成：包括实体、属性、实体之间的联系等。
• 作用：帮助从需求分析到概念模型的转换。

实体之间的联系

1. 联系类型：

   • 一对一（1:1）：每个实体在另一实体集中最多只有一个对应实体。
   • 一对多（1:n）：一个实体对应多个实体，反之则最多对应一个。
   • 多对多（m:n）：双方实体都可能对应多个实体。

2. 表示方法：

   • 使用图形（如图7.6）来表示实体型之间的不同联系。

3. 多实体型联系：

   • 超过两个实体型之间也存在一对一、一对多和多对多联系。

4. 实体内部联系：

   • 同一实体集内的实体也可能存在联系。

E-R图的表示

1. 实体型表示：

   • 用矩形表示，内部写明实体名。

2. 属性表示：

   • 用椭圆形表示，并连接到相应的实体型。

3. 联系表示：

   • 用菱形表示，内部写明联系名，并连接到相关实体型。
   • 联系边旁标注联系类型（1:1、1:n、m:n）。

4. 联系的属性：

   • 如有，也用无向边与联系连接。

实例：工厂物资管理

• 描述了工厂物资管理的实体（如仓库、零件、供应商、项目、职工）及其属性和联系。
• 利用E-R图来表示实体属性和实体联系。

 我的理解：

理解7.3.2节《E-R模型》的概念，关键在于把握E-R模型（实体-关系模型）如何被用来描述现实世界的概念模型。这一节的概念可以从以下几个方面来理解：

1. E-R模型的基本组成：

   • 实体（Entity）：表示现实世界中的一个对象或事物，如“学生”、“教师”。
   • 属性（Attribute）：描述实体的特性，如学生的“姓名”、“学号”。
   • 关系（Relationship）：描述实体间的联系，如“学生”与“课程”的选修关系。

2. 实体之间的联系类型：

   • 一对一（1:1）：一个实体在另一个实体集中有且只有一个对应。
   • 一对多（1:n）：一个实体对应多个实体，但反过来不成立。
   • 多对多（m:n）：双方实体都可能对应多个实体。

3. E-R图的构建：

   • 实体用矩形表示，属性用椭圆形表示，关系用菱形表示。
   • 属性通过无向边连接到其所属的实体，关系通过无向边连接到它所涉及的实体。

4. E-R模型的实用性：

   • 可理解性：E-R模型易于理解，有助于与非技术背景的用户交流。
   • 灵活性：能够适应环境和需求的变化，容易修改和扩充。
   • 转换能力：可转换为关系、网状、层次等数据模型。

5. 应用实例：

   • 使用E-R模型来表示复杂的现实世界情况，如工厂物资管理，包括各种实体及其属性和实体之间的关系。

通过理解这些关键点，可以把握E-R模型如何有效地用于数据库设计，将复杂的现实世界抽象为清晰的信息结构，为数据库的实际实现提供坚实的基础。

 

7.3.3 扩展的E-R模型

扩展E-R模型概述

• 目的：为了增强表达能力，对基本E-R模型进行扩展。
• 应用：更全面和准确地描述现实世界的概念模型。

1. ISA联系

• 定义：表示实体型之间的父类-子类关系，例如“研究生”是“学生”的子类型。
• 特性：子类继承父类的所有属性，并可有自己的属性。
• 表示：使用三角形表示ISA联系。

2. 分类方法

• 分类属性：根据分类属性的值将父实体型中的实体分配到子实体型中。
• 不相交约束与可重叠约束：确定父类实体是否能同时属于多个子类。
• 完备性约束：描述父类实体是否必须属于某个子类。

3. 基数约束

• 定义：说明实体间联系中，实体型中的实体出现的最少和最多次数。
• 表示：用数对min.max表示，如0..1、1..3、1..*（*代表无限）。
• 类型：强制参与（min=1）与非强制参与（min=0）。

4. Part-of联系

• 定义：表示实体型之间的部分-整体关系。
• 类型：
  • 非独占Part-of联系：部分实体可以独立于整体实体存在。
  • 独占Part-of联系：部分实体的存在依赖于整体实体，通常用弱实体型和识别联系表示。

注意

• E-R图的图形元素可能因教材或软件而异，重要的是理解其概念。

 我的理解：

理解7.3.3节《扩展的E-R模型》的概念，关键在于把握E-R模型如何通过扩展来更准确和全面地描述现实世界的复杂关系和结构。这一节的概念可以从以下几个方面来理解：

1. ISA联系的应用：

   • 描述实体型之间的父类-子类关系，如研究生和本科生都是学生的子类型。
   • 子类继承父类的所有属性，并可以有其独特的属性。
   • 用三角形表示ISA联系，反映了子类与父类之间的“是一个”关系。

2. 分类方法：

   • 分类属性：用于将父实体型中的实体根据特定属性分配到不同的子实体型中。
   • 不相交约束与可重叠约束：决定一个父类实体是否能同时属于多个子类。
   • 完备性约束：指明父类中的实体是否必须属于某个子类。

3. 基数约束：

   • 用于细化实体间一对一、一对多和多对多联系的次数。
   • 通过数对（如1..1, 1..n, m..n）来表示实体在联系中出现的次数范围。

4. Part-of联系：

   • 表示实体之间的部分-整体关系。
   • 分为非独占和独占两种类型，反映整体被破坏时部分实体的独立性。

通过理解这些关键点，可以把握扩展E-R模型如何在基础E-R模型上进行改进，提供更丰富的表达能力来描述现实世界中的实体关系。这些扩展功能使得E-R模型更加灵活和有力，能够应对更加复杂的数据建模需求。

 

7.3.4 UML在数据建模中的应用

UML概述

• 定义：统一建模语言（UML）是对象管理组织（OMG）的标准，用于软件开发的所有阶段的模型化和可视化。
• 用途：不仅限于数据建模，还涉及业务建模、对象建模、组件建模等。
• 特性：提供多种类型的描述图，使计算机应用系统开发中的应用程序更易理解。

UML与E-R图

• 类图：在UML中，类图可以用来表示E-R图。
• 实体型与类：UML中的类对应E-R图中的实体，但也包含面向对象的方法。
• 实体的码：在类图中，属性后面加“PK”（primary key）表示主键或码属性。
• 联系：用类图之间的关联来表示，早期UML只表示二元关联，现在也支持非二元关联。

基数约束

• 表示方法：UML中关联类之间基数约束的概念和表示方法与E-R图类似。
• 示例：在UML类图中，基数约束用数对min.max表示，如0..1、1..3、1..*。

UML中的子类

• 概念：支持超类-子类概念，子类可以继承超类的属性并有自己的属性。
• 与E-R图的关系：与E-R图的父类-子类联系或ISA联系一致。

使用建议

• 全程使用UML：如果计算机应用系统的设计和开发全程使用UML规范，则采用UML进行数据建模。
• 非UML项目：如果不是使用UML，则建议数据库设计采用E-R模型表示概念模型。

 我的理解：

理解7.3.4节《UML》的概念，关键在于把握统一建模语言（UML）如何在数据建模中作为一个可视化和模型化工具被应用。这一节的概念可以从以下几个方面来理解：

1. UML的定义和用途：

   • UML是一种广泛接受的模型化语言标准，用于支持软件开发的不同阶段，包括需求规格描述、系统设计、测试和维护。
   • UML不仅用于数据建模，还涉及业务、对象和组件建模等多个领域。

2. UML与E-R图的关系：

   • 在UML中，类图（Class Diagram）可用来表示E-R图。
   • UML中的类大体对应E-R图中的实体，但UML类具有面向对象的特点，包括属性和方法。

3. 实体的码与联系在UML中的表示：

   • 实体的主键或码属性在UML类图中通过在属性名后加“PK”来标识。
   • 实体间的联系在UML中通过关联（Association）表示，早期UML支持二元关联，而现代UML也支持非二元关联。

4. 基数约束的表示：

   • 类似于E-R图，UML也使用基数约束来表明实体间的联系频率，如0..1、1..3、1..*等。

5. UML中的子类概念：

   • UML支持超类-子类概念，与E-R图中的父类-子类关系或ISA联系相似。
   • 子类可以继承超类的属性，并具有自己的属性。

6. 使用场景建议：

   • 如果整个项目是基于UML进行的，那么使用UML进行数据建模是合适的。
   • 如果项目不基于UML，则建议使用E-R模型来表示概念模型。

.3.5 概念结构设计过程

概念结构设计的步骤

1. 分类和组织数据：从需求分析阶段收集的数据开始，对数据进行分类和组织。
2. 确定实体、属性和联系：基于分类的数据，定义实体、实体的属性以及实体间的联系类型，形成E-R图。

实体与属性的划分原则

1. 划分依据：在现实世界中，实体和属性通常已有自然的划分。
2. 简化原则：简化E-R图的目的，将能作为属性的事物尽量视为属性。
3. 划分准则：
   • 属性应是不可分的数据项，不包含其他属性。
   • 属性不应与其他实体有联系。

实例：职工实体

• 职工号、姓名、年龄可以作为职工的属性。
• 若职称与工资等因素相关，则可能需要视为独立的实体。

E-R图的集成

1. 过程：先设计各子系统的E-R图，然后集成为全局E-R图。
2. 步骤：
   • 合并：解决分E-R图间的冲突，生成初步E-R图。
   • 修改和重构：消除冗余，生成基本E-R图。

解决冲突的类型

1. 属性冲突：不同的属性域、单位等。
2. 命名冲突：同名异义和异名同义。
3. 结构冲突：不同的视图对同一对象的抽象不同。

冗余的处理

• 目标：消除E-R图中不必要的冗余数据和联系。
• 方法：分析方法和规范化理论。

实例：工厂管理信息系统视图集成

• 集成物资、销售、劳动人事管理的E-R图。
• 解决异名同义和结构冲突，合并相关实体和联系。

 我的理解：

理解7.3.5节《概念结构设计》的概念，关键在于把握如何从需求分析到E-R图的构建，并在此过程中处理冲突和冗余。这一节的概念可以从以下几个方面来理解：

1. 概念结构设计的目的：

   • 将需求分析阶段收集到的数据转化为清晰的概念模型，通过定义实体、属性和实体间的联系形成E-R图。

2. 实体与属性的划分原则：

   • 实体和属性通常在应用环境中已有自然的划分。
   • 简化原则：如果一个事物能作为属性处理，尽量作为属性。
   • 准则：属性应是不可再分的数据项，且不与其他实体有联系。

3. 实体与属性的划分实例：

   • 如职称与工资的关联决定其是否作为独立实体。

4. E-R图的集成过程：

   • 首先合并各子系统的分E-R图，解决属性、命名和结构冲突。
   • 然后修改和重构，消除不必要的冗余，形成基本E-R图。

5. 处理冲突的类型：

   • 属性冲突：不同属性域或单位的冲突。
   • 命名冲突：包括同名异义和异名同义的情况。
   • 结构冲突：同一对象在不同视图中的抽象差异。

6. 冗余的处理：

   • 使用分析方法和规范化理论来消除冗余。
   • 保留某些冗余可能出于提高效率的考虑。

 

 

 

 

 总结：

重点

1. 实体与属性的划分：

   • 正确区分实体和属性是关键，应根据是否可分和是否与其他实体有联系来判断。
   • 实体通常表示现实世界中的对象，而属性描述这些对象的特性。

2. E-R图的构建和集成：

   • 需要从各个子系统的分E-R图开始，逐步集成为一个完整的全局E-R图。
   • 在集成过程中，要注意解决各分E-R图之间的冲突。

难点

1. 处理冲突：

   • 解决属性、命名和结构冲突时可能会面临挑战，特别是在涉及多个部门或子系统时。
   • 命名冲突尤其常见，需要统一命名标准。

2. 冗余的处理：

   • 决定哪些冗余是必要的（为了效率）和哪些应当消除。
   • 适用分析方法和规范化理论来识别和消除冗余。

易错点

1. 错误地划分实体和属性：

   • 错误地将本应作为独立实体的概念划归为属性，或反之，可能导致模型不准确。
   • 例如，如果职称与工资、福利等有关联，将其错误地视为简单属性。

2. 忽略或过度处理冲突和冗余：

   • 忽视E-R图集成中的冲突，可能导致数据一致性问题。
   • 过度消除冗余可能会影响系统的性能和查询效率。