数据库设计概念
数据库概念设计
数据库概念设计
数据库概念设计，是一项广大范围而深入的工作，是软件开发的基础性技术，
参与到了系统设计、编程、实现及维护的各个阶段。
它结合了数据库的基本原理，在互联网上构建起网站的基础设施。
数据库概念设计基于数据库理论，根据不同的应用场景，分析识别数据及信息
间的特点，并考虑实体、属性、联系人和约束，透彻地揭示、描述数据之间的潜在逻辑联系，综合表示数据和逻辑关系，以实现系统中有效、高效的管理和处理数据的目的。
有效的数据库概念设计，有利于提高数据库的存储和管理效率，是建立数据库
的重要环节。
它能有效的保存和管理数据，提高数据库的信息处理效率，为实现数据库真正的多元、高效的管理提供了可能。
另外，数据库概念设计在互联网开发中也很重要。
互联网数据库与一般的数据
库有明显的不同，一般用于存储特定类型的复杂嵌套数据，而互联网系统为了满足高并发、海量数据存储和快速响应的需要，需要具有能够支持不同数据结构、分布式存储、弹性拓展和高可用性的数据构架设计。
数据库概念设计是软件开发的基础，是构建在互联网上的基础设施的关键技术，它的意义重大，贯穿于软件开发的各个阶段，是实现数据有效、高效管理的基础。
只有有效地实现这一步，才能构建良好的数据库，实现信息处理的要求，最终为客户提供更优质的互联网服务。
数据库概念设计
数据库概念设计数据库概念设计是指在设计数据库时所使用的一种方法。
“概念”指的是数据库中所需要记录和管理的信息的概念，“设计”指的是根据这些信息的概念来确定数据库的结构和关系。
数据库概念设计需要考虑以下几个方面：1. 实体：实体是指数据中的一个对象或者事物，比如学生、课程、教师等。
在数据库中，每个实体都有唯一的标识符，称为主键。
2. 属性：属性是实体的特征或者描述。
比如学生的属性可以包括姓名、年龄、性别等。
每个属性都有数据类型，比如字符型、整型、日期型等。
3. 关系：关系是不同实体之间的联系。
比如学生和课程之间存在选课关系，教师和课程之间存在授课关系。
关系通常用关联来表示，比如学生实体和课程实体之间的关系可以用学生ID属性关联课程ID属性。
4. 范式：范式是数据库设计的规范，用于避免数据冗余和不一致的问题。
常见的范式有第一范式、第二范式和第三范式。
第一范式要求每个属性都是原子的，第二范式要求每个非主键属性都完全依赖于主键，第三范式要求非主键属性之间不应该存在传递依赖。
数据库概念设计的过程包括以下几个步骤：1. 需求分析：确定数据库的需求和功能，了解用户对数据库的期望和要求。
这包括确定需要记录的实体和属性，以及实体之间的关系。
2. 概念设计：根据需求分析的结果，设计数据库的概念模型。
这包括确定实体的属性和关系，确定主键和外键。
3. 逻辑设计：将概念模型转化为逻辑模型。
逻辑设计的目标是根据数据库管理系统的特性和限制来确定数据库的结构和关系。
这包括确定表的结构、数据类型和约束条件，以及确定表之间的关系。
4. 物理设计：将逻辑模型转化为物理模型。
物理设计的目标是根据数据库管理系统的特性和硬件限制来确定数据库的物理存储结构和访问路径。
这包括确定表的分布、索引和分区，以及确定数据的备份和恢复策略。
数据库概念设计是数据库设计的重要步骤，它能够帮助设计人员全面理解和把握数据库的需求，从而设计出合理、高效的数据库结构。
数据库设计ppt课件
• 课程 • 开课教师 • 开课地点 • 选课学期
– 教室信息：教室号和座位数
学籍管理系统需求分析
• 数据完整性约束
– Id号唯一 – 注册的学生数目不能大于该课程的最大人数 – 在相同时间，不能为一个教员指派两门课程 – 相同的时间，一个教室不能有两门课程 – 若学生选修一门课程，若该课程有预备课程则学生
程序编码、 编译联结、 测试
Main( ) …… if…… then …… end
运 行 、 性能监测、转储/恢复
维护
数据库重组和重构
新旧系统转换、运行、维护（修正性、 适应性、改善性维护）
需求分析
• 需求分析就是分析用户的需要与要求
– 需求分析是设计数据库的起点 – 需求分析的结果是否准确地反映了用户的实际要求，
E-R集成冲突
• 两类命名冲突
– 同名异义：不同意义的对象在不同的局部应用中具 有相同的名字 例，局部应用A中将教室称为房间 局部应用B中将学生宿舍称为房间
– 异名同义（一义多名）：同一意义的对象在不同的 局部应用中具有不同的名字 例，有的部门把教科书称为课本 有的部门则把教科书称为教材
E-R集成冲突
3. 概括（Generalization）（子类）
– 它抽象了类型之间的“is subset of”的语义 – 概括有一个很重要的性质：继承性。
ER集成的两种方式
• 一次集成
• 一次集成多个分E-R图 • 通常用于局部视图比较简单时
• 逐步累积式（P224图6.25(b)）
• 首先集成两个局部视图（通常是比较关键 的两个局部视图）
• 混合策略
Байду номын сангаас
数据库的概念结构设计
数据库的概念结构设计数据库的概念结构设计是指在设计数据库之前，需要进行的一个抽象模型化的过程，它描述了数据库中各种对象和它们之间关系的逻辑结构。
数据库的概念结构设计是数据库设计的一个重要环节，它的目的是确定数据库的基本结构和用于描述和组织数据的各种概念、规则、关系和约束。
1.实体和实体类型：实体是现实世界中具有独立存在和区分性质的事物，实体类型是指一类具有相同性质的实体的集合。
在概念结构设计中，需要确定数据库中包含哪些实体类型，以及每个实体类型包含哪些属性。
2.属性和属性域：属性是指实体具有的其中一种特性或性质，属性可以是简单的或复杂的。
属性域是属性可能取值的范围或类型，例如整数、字符串等。
在概念结构设计中，需要确定每个实体类型包含哪些属性，并为每个属性定义属性域。
5.约束和规则：约束是指对数据库中数据有效性的限制，可以是简单的或复杂的逻辑条件。
规则是指对数据库中数据操作的限制和规范，例如插入、删除、更新等操作的规则。
在概念结构设计中，需要确定数据库中存在哪些约束和规则。
6.数据流和过程：数据流是指数据库中数据的流动过程，过程是指对数据库中数据进行操作的方法，例如查询、修改等过程。
在概念结构设计中，需要确定数据库中的数据流和过程，以及它们之间的关系和约束。
数据库的概念结构设计是数据库设计的基础，它为后续的物理结构设计、逻辑结构设计和实施提供了指导。
一个好的概念结构设计可以使数据库的性能和效率得到最大的提升，同时也可以保证数据库中数据的一致性和完整性。
因此，在进行数据库设计时，需要认真进行概念结构设计的工作，合理地组织和描述数据的逻辑结构，为后续的数据库设计和实施奠定良好的基础。
毕业设计数据库设计
毕业设计数据库设计一、引言毕业设计是大学生在校期间必须完成的重要任务，它不仅是对所学知识的综合运用，更是对自身能力的全面考验。
在毕业设计中，数据库设计是一个非常重要的环节，本文将从以下几个方面详细介绍毕业设计数据库设计的相关内容。
二、数据库设计概述数据库设计是指对一个系统或应用程序所需数据进行分析、分类、组织和存储的过程。
它包括数据模型设计、数据结构设计和数据操作规则等方面。
在毕业设计中，数据库设计通常分为以下几个步骤：1.需求分析：通过与用户交流和沟通，了解用户需求，明确系统功能和数据要素。
2.概念结构设计：根据需求分析结果，建立实体-关系图（ER图），确定实体之间的关系。
3.逻辑结构设计：将概念结构转化为逻辑结构，并进行范式化处理。
4.物理结构设计：确定数据库表的具体属性和实现方式。
5.实施和测试：将物理结构转化为具体实现，并进行测试和优化。
三、需求分析在毕业设计中，需求分析是最重要也是最基础的部分。
它涉及到对用户需求进行深入细致的了解和分析，明确系统功能和数据要素。
在需求分析阶段，需要考虑以下几个方面：1.系统功能：需要明确系统的基本功能和特殊功能，以及用户对这些功能的具体要求。
2.数据要素：需要明确系统所需处理的数据类型、数量、关系等信息。
3.用户界面：需要设计用户友好的界面，使用户能够方便地进行操作。
4.安全性：需要考虑系统的安全性，包括数据安全和操作安全等。
5.可扩展性：需要考虑系统的可扩展性，以便将来能够方便地进行升级和扩展。
四、概念结构设计概念结构设计是数据库设计中最重要也是最基础的部分。
它涉及到对实体之间关系进行建模，确定实体之间的联系。
在概念结构设计阶段，需要考虑以下几个方面：1.实体-关系图（ER图）：通过ER图来描述实体之间的关系，包括一对一、一对多、多对多等不同类型。
2.实体属性：确定每个实体所具有的属性，并设置主键和外键等属性。
3.关系模式：根据ER图来生成关系模式，并进行范式化处理。
数据库设计与实现
数据库设计与实现在当今数字化时代中，数据已成为企业和组织的重要资源之一，也成为决策的关键因素。
数据库的设计与实现成为一个优秀的系统程序的核心问题之一。
一个成功的数据库必须考虑到多种因素，如数据访问、数据完整性、数据可靠性、数据安全和数据可扩展性等，同时还需满足用户的需求，提高系统的性能和效率。
以下将介绍数据库设计和实现的过程和方法。
一、数据库设计的基本概念1. 数据库：指存储有组织的数据的计算机系统。
2. 数据库管理系统（DBMS）：是一种软件系统，用于管理、组织、存储、维护数据库。
3. 数据库设计：是指在满足用户需求的前提下，使用数据库模型、数据字典等工具，对数据进行结构化设计，确定各数据项之间的关系、属性和约束条件等，以实现更快、更高效、更安全的数据访问。
4. 数据库实现：是指将数据库设计的结果在DBMS中实现并运行，包括创建和管理数据库的对象、存储过程、触发器、索引等。
二、数据库设计的流程1. 需求分析在数据库设计前，需要了解和分析用户需求，了解业务状况，才能最终设计出一套合适的数据库系统。
需求分析包括：确定数据库系统的目的、确定要存储哪些数据和数据之间的关系。
2. 概要设计概要设计是数据库设计过程中的一项重要环节，通过概要设计，设计者将用户需求融入到系统设计中，对数据结构、数据属性、数据完整性和库表划分等方面进行规划和分析。
概要设计的主要目的是从系统的应用视角来设计系统。
3. 详细设计在对数据库系统的总体设计有了清晰的认识后，设计者开始进行详细设计，包括数据库模型设计、物理结构设计、存储结构设计、关系型映射设计等。
这一环节的目的是通过恰当的数据结构设计，高效、安全、可靠地存储和管理相关数据。
4. 实现和测试了解到如何设计数据库后，开发者可以基于所选的数据库管理系统开始实施数据库的物理设计。
在实施设计过程中，需要开发者计算存储要求、数据流程、索引等。
设计完成后，对于还未被系统接管的系统使用者来说，需要测试数据库以确保其准确性和完整性。
《数据库设计》ppt课件
数据库设计流程与步骤
步骤
1. 收集和分析用户需求，确定系统功能和性能要求。
2. 选择合适的数据模型，设计概念结构，形成概念模式。
数据库设计流程与步骤
02
03
04
01
数据库设计流程与步骤
3. 将概念模式转换为逻辑模式，进行逻辑优化。
4. 选择物理存储结构，设计物理模式，进行物理优化。
5. 用DDL定义数据库结构，组织数据入库，编制与调试应用程序。
《数据库设计》ppt课件
目录
数据库设计概述 需求分析 概念结构设计 逻辑结构设计 物理结构设计 数据库实施与维护 案例分析与实战演练
01
CHAPTER
数据库设计概述
数据库设计是指根据用户需求，运用数据库技术，设计数据库结构、建立数据库及其应用系统的过程。
定义
数据库设计是信息系统开发过程中的重要环节，直接影响系统的性能、可扩展性、可维护性等。
数据模型优化与规范化
外模式/内模式映射
定义用户子模式与逻辑模式之间的映射关系，实现数据的逻辑独立性和物理独立性。
安全性控制
在用户子模式设计中考虑数据的安全性控制，如访问权限、加密等。
视图设计
根据用户需求和安全控制要求，设计相应的视图来限制用户对数据的访问。
用户子模式设计
05
CHAPTER
物理结构设计
联系
用菱形表示，菱形框内写明联系名，并用无向边分别与有关实体连接起来，同时在无向边旁标上联系的类型（1:1, 1:n, m:n）。
码
在属性下方加上下划线表示该属性为码属性。
视图集成
将多个用户的局部视图合并成一个全局视图的过程。包括合并各个局部视图的实体、属性和联系，生成全局视图。
数据库设计基础知识
数据库设计基础知识摘要本文档旨在为新加入的初级开发人员提供数据库设计的基础知识，涵盖数据库的基本概念、关系数据库设计、数据库性能优化和索引设计等内容。
通过阅读本文档，开发人员将能够理解数据库设计原则和最佳实践。
1. 数据库基本概念1.1.1. 数据库模式•外键（Foreign Key）o外键是表中某列的值必须存在于另一个表的主键中的一项。
•索引（Index）o索引是用于提高数据库查询效率的数据结构，通过索引可以直接定位数据所在位置。
2. 关系数据库设计•概念设计o定义实体、属性和关系的过程。
•逻辑设计o将概念模型转化为数据库schema的过程。
•物理设计o根据逻辑设计和硬件条件，形成最终的物理存储方式。
3. 数据库性能优化•优化数据库查询，减少IO操作•优化数据库索引，减少索引碎片化•优化数据库存储，减少存储空间4. 索引设计•单列索引o在一个表的单列上建立的索引。
•组合索引o由两个或多个列组成的索引。
•唯一索引o确保索引列的值唯一的索引。
案例案例1-数据库设计某电商网站的数据库设计中，需要存储用户信息、订单信息和商品信息。
通过关系数据库设计，可以将这些信息组织成以下表格：案例2-数据库性能优化某电商网站的数据库查询性能较差，通过分析发现，主要原因是数据库索引设计不合理。
通过优化索引设计，可以显著提高数据库查询性能。
图表和模型图1-数据库设计流程1.概念设计2.逻辑设计3.物理设计模型-数据库设计模型•概念模型o实体o属性o关系•逻辑模型o表o列o索引•物理模型o存储方式o存储位置o存储空间结论数据库设计是数据库开发的基础，关系数据库设计、数据库性能优化和索引设计是数据库设计的核心内容。
通过理解数据库设计原则和最佳实践，可以设计出高性能、可扩展的数据库。
通过阅读本文档，开发人员将能够理解数据库设计的基础知识和最佳实践。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
数据库设计概念在设计数据库时，需要计划要存储有关哪些事物的信息，以及要保存有关各个事物的哪些信息。
您还需要确定这些事物的相互关系。
如果使用数据库设计中的术语，在这一步创建的数据库原型就称作概念数据库模型。
实体和关系要存储其相关信息的可识别对象或事物称作实体。
它们之间的关联称作关系。
在数据库描述语言中，可以将实体看做名词，将关系看做动词。
由于概念模型对实体和关系进行了明确的区分，因此这种模型非常有用。
这种模型将在任何特定数据库管理系统中实施设计所涉及的细节隐藏起来，从而使设计者可以集中考虑基础数据库结构。
因此，这种模型也成为了一种用于讨论数据库设计的通用语言。
实体关系图概念数据库模型主要由一个显示实体和关系的示意图构成。
这个示意图通常称作实体关系图。
因此，许多人也使用实体关系建模这个词来指创建概念数据库模型的任务。
概念数据库设计是一个由上至下的设计方法。
现在有许多功能完备的工具可以帮助您按照这种方法或其他方法进行设计，例如，Sybase PowerDesigner。
虽然本章的目的只是进行介绍，但也提供了足够的信息可以帮助您设计简单的数据库。
实体在数据库中，一个实体对应于一个名词。
可识别的对象，例如，雇员、订单项、部门和产品，都是实体的示例。
在数据库中用表代表各个实体。
置入数据库的实体都源于要使用数据库执行的活动，例如，跟踪销售电话和维护雇员信息，等等。
属性每个实体都包含一些属性。
属性是指要为事物存储的特定特性。
例如，在雇员实体中，需要存储雇员ID 号、姓氏和名字、地址，以及与一个特定雇员相关的其他信息。
属性也称作特性。
实体用一个矩形框表示。
在矩形框内部，列出与该实体相关联的属性。
标识符是指所有其他属性都依赖的一个或多个属性。
它在实体中唯一地标识一个项目。
在要组成标识符的属性名下面加上下划线。
在上面的Employee 实体中，Employee Number 唯一地标识一个雇员。
所有其他属性都存储只与那个雇员相关的信息。
例如，一个雇员编号唯一地确定一个雇员的名字和地址。
两个雇员可能具有相同的名字或相同的地址，但可以确保他们的雇员编号不同。
Employee Number 下面带有下划线，表示它是标识符。
为每个实体都创建一个标识符是一个良好的习惯。
这些标识符在表中将成为主键，下文中将对此进行说明。
主键值必须唯一，并且不能为空或未定义。
主键唯一地标识表中的每一行，并且提高数据库服务器的性能。
关系在数据库中，实体之间的一个关系对应于一个动词。
一个雇员属于一个部门，或者一个办事处位于一座城市。
数据库中的关系可能表现为表间的外键关系，也可能自身就成为独立的表。
您将在本章中看到这两种情况的示例。
数据库中的关系就是控制实体中数据的规则或惯例的编码。
如果每个部门有一个部门经理，可以在部门和雇员之间建立一对一的关系来标识该部门经理。
当关系置入数据库结构后，就不可能再出现例外。
没有地方可以输入另一个部门经理。
复制部门条目将复制部门ID，而它是标识符。
标识符不允许有重复。
提示严格的数据库结构有很大好处，因为它可以消除不一致的问题，例如一个部门有两个经理。
另一方面，作为设计者，您应该使设计具有足够的灵活性以便于进行扩展，以满足某些未预见到的需要。
对设计合理的数据库进行扩展通常并不很困难，但修改现有表结构可能会致使整个数据库及其客户端应用程序无法使用。
关系的基数表之间有三种关系。
这三种关系对应于关系中所涉及的实体的基数（数量）。
•一对一关系关系通过在两个实体间画一条连线表示。
连线上可以有其他标记，例如，下图中所示的两个圆圈。
这些标记的用途将在下文中进行说明。
在下图中，一个部门由一个雇员管理。
•一对多关系如果[实体1] 中包含的一项可以与[实体2] 中的多项相关联，这样一种关系用多条连线连接到[实体2]来表示。
在下图中，一个办事处可以有多部电话。
•多对多关系在这种情况下，两个实体的连接处都要画多条连线。
这表示一个仓库可以存放许多不同的部件，而同一类部件也可以存放在许多仓库中。
角色您可以用两个角色来描述每种关系。
角色是用于从每个观察点描述关系的动词或短语。
例如，雇员和部门之间的关系可以用以下两个角色来描述：1. 雇员属于部门。
2. 而部门包含雇员。
角色非常重要，因为它们为您提供了一种方便且有效的方法来验证您的工作。
提示不管是从左到右读取还是从右到左读取，下面的规则都会使读取这些图示变得容易：读取(1) 第一个实体的名称，(2) 第一个实体旁边的角色，(3) 到第二个实体的连接的基数，(4) 第二个实体的名称。
强制元素表示关系的连线末端的小圆圈具有非常重要的作用。
圆圈表示存在于该实体内的元素在另一个实体内不必有对应的元素。
如果出现的是一段交叉线而不是圆圈，则表示另一个实体中的每个元素在该实体中至少应有一个对应元素。
下面举例说明这些标记的含义。
此图具有以下四个含义：1. 一家出版社出版了零或多本书。
2. 一本书由恰好一家出版社出版。
3. 一本书由一或多位作者撰写。
4. 一位作者撰写了零或多本书。
提示可以把小圆圈看做数字0，把交叉线看做数字1。
圆圈表示至少零。
交叉线表示至少一。
反身关系有时，同一个实体内的条目之间也存在关系。
这种关系称作反身关系。
关系的两端都连接到同一个实体。
此图具有以下两个含义。
1. 一个雇员最多只向另外一个雇员报告。
2. 一个雇员管理零个或多个雇员。
请注意，在这个关系中，关系在两个方向上都应该是可选的。
某些雇员不是经理。
同样，至少应该有一个雇员是公司的总经理，因此不向任何人报告。
自然，还应指定一个雇员不能是他自己的经理。
这个限制是一种业务规则。
业务规则将在下文中作为设计过程的一部分进行讨论。
将多对多关系更改为实体如果有属性与关系相关联，而不是与实体相关联，则可以将该关系更改为实体。
有时，多对多关系可能会出现这种情况。
有些属性特定于关系，因此将其添加到任何一个实体中都不合理。
假设部件存放在多个不同的仓库中。
而您画的设计图如下所示。
但您希望记录各个部件在各个地点的存货数量。
该属性只能与关系相关联。
每个数量都依赖于所涉及的部件和仓库。
要表示这样一种情况，可以按以下方式重画设计图：请注意以下细节的变化：1. 两个新关系将关系实体分别与原有的两个实体连接起来。
这两个关系的名称继承自原有关系的两个角色：分别为存放在和包含2. Inventory 实体中的每个条目要求Parts 实体中有一个强制条目，Warehouse 实体中有一个强制条目。
这些关系都是强制的，因为仓储关系只在与一个特定部件和一个特定仓库相关联时才有意义。
3. 新实体既依赖于Parts 实体，也依赖于Warehouse 实体，表示新实体由这两个实体的标识符共同标识。
在这个新设计图中，Parts 实体中的一个标识符和Warehouse 实体中的一个标识符唯一地标识Inventory 实体中的一个条目。
圆圈和多线条之间的三角形将两个新关系连接到新的Inventory实体，并表示依赖性。
不要在Inventory 实体中添加Part Number 或Warehouse ID 特性。
Inventory 实体中的每个条目都依赖于一个特定部件和一个特定仓库，但这些三角形可以更清晰的表示这种依赖性。
设计过程设计过程包含五个主要步骤。
•第1 步：确定实体和关系•第2 步：确定所需数据•第3 步：规范化数据•第4 步：解析关系•第5 步：验证设计有关实现数据库设计的详细信息，请参见使用数据库对象。
第 1 步：确定实体和关系实体和关系示例第 2 步：确定所需数据第 3 步：规范化数据第 4 步：解析关系第 5 步：验证设计第 1 步：确定实体和关系确定设计中的实体及实体之间的关系：1. 确定高级别的活动确定要使用该数据库执行的一般活动。
例如，可能要用它来跟踪有关雇员的信息。
2. 确定实体对于这些活动，确定需要维护有关哪些类对象的信息。
这些对象将成为实体。
例如，聘用雇员，将雇员分配到某个部门，并确定其技能级别。
3. 确定关系对这些活动进行分析，然后确定实体间会有哪些关系。
例如，部件和仓库之间有关系。
定义两个角色来描述每个关系。
4. 分解活动开始时确定了高级别的活动。
现在，需要进一步分析这些活动，确定是否可以将其中一些分解为较低级别的活动。
例如，象维护雇员信息这样一个高级别活动可以分解为：o添加新雇员。
o更改现有雇员信息。
o删除已离职的雇员。
5. 确定业务规则对业务说明进行分析，确定应遵守哪些规则。
例如，[一个部门有且仅有一个经理] 就可以作为一个业务规则。
这些规则将被置入数据库的结构中。
实体和关系示例示例ACME Corporation 是一家小公司，它在五个地点设有办事处。
目前，ACME 有75 名雇员。
该公司正准备迅速发展，并且已经确定了九个部门，每个部门都有自己的部门经理。
为帮助公司招聘新雇员，人事部门确定了68 项技能，并且认为公司将来需要具有这些技能的雇员。
聘用了一个雇员后，将对该雇员在每项技能上的专业级别进行评定。
确定高级别的活动ACME Corporation 需要考虑的高级别活动有：•聘用雇员。
•解聘雇员。
•维护雇员的个人信息。
•维护有关公司所需技能的信息。
•维护有关哪个雇员具有哪项技能的信息。
•维护有关部门的信息。
•维护有关办事处的信息。
确定实体和关系确定实体（对象）和连接实体的关系（角色）。
根据以上说明和高级别的活动创建一个设计图。
用矩形框表示实体，用连线表示关系。
用两个角色标记每个关系。
还应使用适当的标注表示那些一对多、一对一和多对多关系。
下面是一个粗略的实体关系图。
在本章后面的部分将逐渐对其进行改进。
分解高级别的活动根据上述高级别的活动可以确定以下较低级别的活动：•添加或删除雇员。
•添加或删除办事处。
•列出某个部门的雇员。
•在技能列表中添加技能。
•确定某个雇员的技能。
•确定某个雇员在各项技能上的技能级别。
•确定在某项技能上具有相同技能级别的所有雇员。
•更改雇员的技能级别。
使用这些较低级别的活动可以确定是否需要新表或新关系。
确定业务规则业务规则通常可以表示为一对多、一对一和多对多关系。
可能相关的业务规则有以下几个：•现在有五个办事处；扩展计划允许增加到最多十个。
•雇员可以更换部门或办事处。
•每个部门有一个部门经理。
•每个办事处最多有三个电话号码。
•每个电话号码有一个或多个分机。
•聘用了一个雇员后，将对该雇员在各项技能上的专业级别进行评定。
•每个雇员具有三到二十项技能。
•可以将雇员分配到一个办事处，也可以不分配第 2 步：确定所需数据确定所需数据：1. 确定支持数据。
2. 列出所有需要跟踪的数据。
3. 为每个实体设置数据。
4. 列出每个实体的可用数据。
描述实体（对象）的数据可以回答涉及何人、何事、何处、何时以及何故的问题。