数据库技术ER图如何画
发布网友
共3个回答
懂视网
引言：数据库设计 Step by Step (3)中我们讨论了基本实体关系模型构件及其语义。这些概念非常重要，是今天这一讲的基础，在开始本文内容之前建议大家可以再回顾一下上一篇的内容。今天我们将讨论高级实体关系模型构件，与上一篇一起涵盖了ER模型构图的大部分
引言：数据库设计 Step by Step (3)中我们讨论了基本实体关系模型构件及其语义。这些概念非常重要，是今天这一讲的基础，在开始本文内容之前建议大家可以再回顾一下上一篇的内容。今天我们将讨论高级实体关系模型构件，与上一篇一起涵盖了ER模型构图的大部分内容。三元关系是今天这一讲的难点，大家可以重点关注。
泛化（Generalization）：超类型与子类型
原始的ER模型已经能描述基本的数据和关系，但泛化（Generalization）概念的引入能方便多个概念数据模型的集成。
泛化关系是指抽取多个实体的共同属性作为超类实体。泛化层次关系中的低层次实体——子类型，对超类实体中的属性进行继承与添加，美国服务器，子类型特殊化了超类型。
ER模型中的泛化与面向对象编程中的继承概念相似，但其标记法（构图方式）有些差异。
下图表示员工与经理、工程师、技术员、秘书之间的泛化关系。Employee为超类实体，并包含共同属性，Manager、Engineer、Technician、Secretary都是Employee的子类实体，它们能包含自身特有的属性。
泛化可以表达子类型的两种重要约束，重叠性约束（disjointness）与完备性约束（completeness）。
重叠性约束表示各个子类型之间是否是排他的。若为排他的则用字母“d”标识，否则用“o”标识（o -> overlap）。图1中各子类实体概念上是排他的。
对员工、客户实体进行泛化，抽象出超类实体个人，得到如下关系图。由于部分Employee也可能是Customer，故子类实体Employee与Customer之间概念是重叠的。
完备性约束表示所有子类型在当前系统中是否能完全覆盖超类型。若能完全覆盖则在超类型与圆圈之间用双线标识（可以把双线理解为等号）。在图2中子类实体Employee与Customer能完全覆盖超类Individual实体。
聚合（Aggregation）
聚合是与泛化抽象不同的另一种超类型与子类型间的抽象。
泛化表示“is-a”语义，聚合表示“part-of”语义。聚合中子类型与超类型间没有继承关系。
聚合关系的标记法是在圆圈中标识字母“A”来表示。
下图表示软件产品由程序与用户手册组成。
三元关系（Ternary Relationships）
当通过二元关系无法准确描述三个实体间的联系时，我们需要使用三元关系。
三元关系中“连通数”的确定方法：
a) 以三元关系中的一个实体作为中心，假设另两个实体都只有一个实例
b) 若中心实体只有一个实例能与另两个实体的一个实例进行关联，则中心实体的连通数为“一”
c) 若中心实体有多于一个实例能与另两个实体实例进行关联，则中心实体的连通数为“多”
注：什么时候需要使用三元关系的实例请参看：数据库设计 Step by Step (3)中的“关系的度（Degree of a Relationship）”小节。关系的“连通数”概念请参看：数据库设计 Step by Step (3)中的“关系的连通数（Connectivity of a Relationship）”小节。
我们来看几个三元关系的实例，注意各个图中关系的度，并理解其中的语义。
图4中蕴含的语义为：
a) 一名技术员对于每一个项目使用一本手册
b) 每一本手册对于每一个项目属于一名技术员
c) 一名技术员可能在做多个项目，对于不同的项目维护不同的手册
用数学中的函数依赖表示图4的关系：
a) emp-id, project-name -> notebook-no
b) emp-id, notebook-no -> project-name
c) project-name, notebook-no -> emp-id
图5中蕴含的语义为：
a) 每一个员工在一个地点只能被分配一个项目，但可以在不同地点做不同的项目
b) 在一个特定的地点，一个员工只能做一个项目
c) 在一个特定的地点，一个项目可以由多个员工来做
用数学中的函数依赖表示图5的关系：
a) emp-id, loc-name -> project-name
b) emp-id, project-name -> loc-name
图6中蕴含的语义为：
a) 一名经理手下的一名工程师可能参与多个项目
b) 一名经理管理的一个项目可能会有多名工程师
c) 做某一个项目的一名工程师只会有一名经理
用数学中的函数依赖表示图6的关系：
a) project-name, emp-id -> mgr-id
图7中蕴含的语义为：
a) 一名员工在一个项目中可以使用多种技能
b) 一名员工的一种技能可以在多个项目中使用
c) 一种技能在一个项目中可以被多名员工使用
图7各实体之间没有函数依赖
上述4种形式的三元关系，连通数为“一”的实体数量与该三元关系反映的函数依赖语义的数目一致。
三元关系也能有属性。属性值由三个实体的键的组合唯一确定。
n元关系（General n-ary Relationships）
三元关系可以扩展到n元关系，描述n个实体之间的关系。
一般而言，n元关系中每一个连通数为“一”的实体的键都会出现在一个函数依赖表达式的右侧。
对于n元关系，使用语言来表达其中的约束相对较为困难。建议使用数学形式即函数依赖（FD）来表现。
n元关系的函数依赖条目数量与关系图中“一”端实体的数量相同（0～n条）。
n元关系的函数依赖表达式包含n个元素，n-1个元素出现在表达式左侧，1个元素出现在右侧。
排他性约束（Exclusion Constraint）
一般（默认）情况下，多种关系之间是兼容的“或”关系，即允许任意或所有实体参与这些关系。
在某些情况下，多种关系之间是非兼容性“或”关系，即参与关系的实体只能选择其中一种关系，不能同时选择多种关系。
下图表示的语义为：一项工作任务要么被归为外部项目中，要么被归为内部项目中，不可能同时属于外部项目和内部项目。
我们对上一篇数据库设计 Step by Step (3)与本篇的重点内容做一个总的回顾
1. 我们讨论了ER模型及构图的基本概念
2. 一个实体可以是一个人，地方，免备案空间，东西或事件
3. 属性是实体的描述信息
4. 属性可以是唯一标识或非唯一的描述
5. 关系描述了实体之间“一对一”，“一对多”，“多对多”的联系
6. 关系的度反映了参与关系的实体数量，如二元关系，三元关系，n元关系
7. 角色（名）定义了一个实体在一个关系中所具有的功能
8. 关系的存在概念表示一个实体在关系中是强制存在还是可选的
9. 泛化允许把实体抽象成超类与子类
10. 三元关系可使用函数依赖来定义
，服务器
热心网友
如何画数据库ER图
数据库设计中重要的一环首先就是概念设计，也就是说，要从实际问题出发，排除非本质的东西，抽象出现实的数据结构之客观规律——即画出数据结构图——ER图。这是数据库设计的重点，也是数据库设计的难点。
那么，如何才能正确地反映客观现实，将ER图画好呢？
答案是，必须进行正确的需求分析。那么如何进行需求分析呢？需求分析一般有两种方法，一种是结构化分析(SA)，一种是面向对象分析(OOA).通过这两种方法的实施以后，都可以得到比较正确的ER图。现在以下面的实际问题为例，通过结构化分析(SA)方法的应用，讲述如何得到比较正确的ER图。
( 一 ) 校务管理系统
在要建立的系统中,有以下功能：
1.管理老师的功能：录入老师情况(姓名.地址.所教课程), 老师缺课记录(名字.时间.原因. 课程)
2.管理学生的功能: 录入学生情况 ( 姓名 . 所选课程 . 成绩 )
3.教务主任的功能 : 查询统计 1: 教师情况 2: 学生总成绩 3: 学生平均成绩
要求：
1）用结构化方法画出系统顶层图、 0 层图，数据字典。
2）画出该系统的数据模型ER图。
一、结构化分析的需求分析
1） 分析实际情况
根据实际情况，我们得到一下情况：
(一)教师任课流程：
(二)学生选择课程流程：
2）画数据流图
（一、）顶层数据流图
（二）0层数据流图
3）画数据字典DD（略）和软件初始结构图
1基本数据=学生基本信息|教师基本信息|课程基本信息|教室基本信息
2教师任课信息=教师任课数据|教师考勤信息
3学生选课请求和成绩=学生选课请求|学生成绩
学生基本信息=学号+姓名+性别+年龄+专业+班级
。。。。。。
热心网友
付费内容限时免费查看回答E-R图中的主要构件，如图所示。其中较常用的有矩形、菱形、椭圆、线段等。矩形表示实体集，在框内写明实体名；菱形表示联系集，在框内写明联系名；椭圆表示属性，在内写明属性名；线段表示属性与相关的实体连接或者实体与联系相连。
联系：用线段分别与有关实体连接，并在线段上标注上联系的类型（1:1、1：n或m：n）。两个不同实体之间之间的联系可分为一对一联系记为1：1，一对多联系记为1：n，多对多联系记为m：n；两个以上不同实体集之间的联系可分为1：1：1，1：1：n，1：m：n，r：m：n。
属性：实体某方面的特性。例如，学生实体集具有学号、姓名、年龄、学年等等属性。可作如下分类：简单属性和复合属性，单值属性和多值属性，NULL属性，派生属性。
提问按照这个图怎么画ER图
回答套用模板就好了
提问……
