7种数据建模的方法.docx
- 文档编号:26295695
- 上传时间:2023-06-17
- 格式:DOCX
- 页数:13
- 大小:381.33KB
7种数据建模的方法.docx
《7种数据建模的方法.docx》由会员分享,可在线阅读,更多相关《7种数据建模的方法.docx(13页珍藏版)》请在冰豆网上搜索。
7种数据建模的方法
7种数据建模的方法
1.EntityRelationshipModel-ER模型-实体关系模型
1976年PeterChen首次提出了EntityRelationshipModeling(实体关系建模)概念,并发明了陈氏表示法PeterChen'sNotation,因此ER模型也可以叫做Chen'sModel(陈氏模型)。
下面是一个ER模型(ERD-ERdiagram-EntityRelationshipdiagram)示例:
图:
ER模型-PeterChen'sNotation图:
ER模型-PeterChen'sModel,实际上这是一个EER-EnhancedEntity-RelationshipModel,扩展ER模型
Entity实体:
使用方框表示
Attribute属性:
使用圆或椭圆表示。
实体和实体关系都可以拥有属性,例如图中的Order-Line关系拥有3个属性
Relationship关联关系:
使用菱形表示,菱形中写上关联关系的名字
ER模型中关联关系也可以拥有属性,在多对多关联关系中不需要使用额外中间关联实体来表示,关联关系本身就可以作为这个中间实体。
另外ER模型的关联关系不限于2个实体之间,可以在多个实体间使用一个关联关系
UniqueIdentifier唯一标识
陈氏表示法没有很好的解决唯一标识问题,仅使用一种简单的标记方法,下图表示Party的ID作为PurchaseOrder唯一标识一员的情况,关联关系名称改为E,朝依赖实体方使用一个箭头,依赖实体使用一个额外的方框括起来
图:
ER模型中唯一标识的表示方法图:
ER模型中唯一标识的表示方法
Sub-type子类型
最初的陈氏表示法中不包含子类型概念,后来RobertBrown和MatFlavin添加了子类型表示法,这种ER模型称为扩展ER模型。
上图ER模型中有一个子类型例子,超类Party派生出子类Organization和Person
Constraintsbetweenrelationships关联关系的约束
最初的陈氏表示法中关联关系的每一端只使用一个数字表示,比如一对多的关联关系,在一端使用1,另一端实体上使用n表示,这对关联关系约束不充分。
上图的ER模型在关联关系每一端使用2个数字表示,这与Crow'sFoot表示法以及UML中的optionality(可选项)、cardinality(关联基数)有些类似又有较大的区别,详细说明如下:
上图中一个PurchaseOrder必须关联一个Party,必须关联一个或多个OrderLine,每个OrderLine要么是一个Product要么是一个Service
PurchaseOrder右边的(1,)1表示一个PurchaseOrder有且必须有一个Party
Party左边的(0,)n表示一个Party可以拥有多个PurchaseOrder,也可以没有
PurchaseOrder左边的(1,)n表示PurchaseOrder必须有一个或多个OrderLine
OrderLine右边的(1,)1表示每个OrderLien必须属于一个PurchaseOrder
OrderLine下面的(1,)1和菱形符号一起表示每个OrderLine要么是一个Product要么是一个Service
Product和Service上面的(0,)n表示Product和Service可以属于0个或多个OrderLine
Event和EventCategory的关联关系稍特殊(实际中这种n:
1的关系不多见),他不是一个普通的多对一关系。
Event可以关联一个EventCategory也可以不关联,而EventCategory则必须关联一个或多个Event
Order-Line和Product、Service之间是一个exclusiveor约束(异或、互斥约束,disjunctivemandatory约束)关系,使用超类和子类一样的表示法来表示。
因为exclusiveor的语义本身已经已经表明OrderLine必须是Product或者Service其中之一,因此上图中OrderLine右边和下面的(1,)1是多余的
EER-EnhancedEntity-RelationshipModel扩展ER模型
上面已经有些内容不属于最初的陈氏表示法,是后来其他人扩展的。
陈氏表示法出现的早也存在一些不足,因此存在一些扩展以弥补缺陷,不同文档中使用的ER图也不尽相同,例如下图是wiki上的一个示例ER模型
图:
Wiki上的ER模型示例图:
Wiki上的ER模型示例
属性带下划线表示主键属性;关联关系连接线为两条线的表示"最少一个,或多个"(用于n的一端);实体和关联关系使用两个框的,可能是上面讲到的唯一标识表示法,也可能是"最少一个,或多个"表示法的一部分(这一点有待确认)。
还有一些,例如属性与实体间用两条线连接的表示该属性为多值属性(上图中Region实体的Foliage属性)。
图中的部分解释如下:
1Accounthasn(atleastone)Character,Account的AcctName属性将成为Has的唯一标识的一员;
1Regioncontainsn(atleastone)Character,Region的RegionName属性将成为Character的唯一标识的一员;
2.InformationEngineering-IE模型
InformationEngineering采用Crow'sFoot表示法(也有叫做JamesMartin表示法的),中文翻译中对使用了Crow'sFoot表示法的模型也有笼统的称做鸭掌模型的(关联关系的关联基数中采用到了一个鸭掌形的三叉线来表示)。
他由CliveFinkelstein发明,与JamesMartin一起推广,后来两人各自做了些修正形成两份版本
前面示例模型的InformationEngineering表示如下:
图:
InformationEngineering-IE模型-Crow'sFootModel-鸭掌模型图:
InformationEngineering-IE模型
注意IE模型与ER模型的区别。
PurchaseOrder与Party是多对一n:
1的关联关系,在ER模型中n被放置在了Party的左边,而IE模型中n被放置在了PurchaseOrder的右边。
两种表示法的形式(相当于语法)不一样,但语义是一致的。
这一点也只有ER模型是特殊的,其他模型表示法中都与IE模型一致
Entity&Attribute:
实体属性并不出现在IE模型中,而是单独使用另外的文档记录
Relationship
Crow'sFoot的可选项optionality和关联基数cardinality表示法:
图:
Crow'sFoot的可选项optionality和关联基数cardinality表示法图:
Crow'sFoot的可选项optionality和关联基数cardinality表示法
Optionality可选项:
用来表示该关联关系是可选的,还是必须的。
对于可选的关联关系,通常表现为用于关联的外键字段允许为null值,或者对于使用中间关联关系表的情况下可以不出现关联数据,而必须的关联关系则不允许外键为null或者必须存在关联数据
Cardinality关联基数:
用来表示关联实体的数量上限,为1、n等
图中右边部分表示的意义如下:
1个A必须关联到1个或多个B,一个B可以关联0个或1个A
关联的约束如图所示,Product和Service通过一个圆连接到OrderLine。
如果是实心圆则表示Product和Service是exclusiveor;如果是空心圆则表示Product和Service是inclusiveor(相容的,conjunctive),表示可以是其中之一或者多个
在上面IE模型图中,OrderLine右侧是Finkelstein的一个特殊符号,表示一个PurchaseOrder初始时有0或n个OrderLine,但最终必须有1或n个OrderLine
Martin以动词命名关联关系,只命名一个方向(遵循从左到右、从上往下的方式),而Finkelstein不对关联关系命名
Sub-type:
图中Party子类的表示方法由Martin采用,Finkelstein则对每个子类使用单独的实体,使用ISA关联关系(关联关系名称为ISA,也有采用类似UML继承的三角形符合,在关联线上使用一个三角形的)表示其为子类
3.RichardBarker'sNotation
这个表示法最早是英国咨询公司CACI发明,经过了RichardBarker的推广,后来RichardBarker去了Oracle,开发了相关的建模工具,因此也叫做Oracle表示法(Oracle'sNotation)
示例模型的Barker表示法如下:
RichardBarker'sModel图:
RichardBarker模型
Entity&Attribute:
实体试用圆角的方框表示,属性出现在实体框中。
可选属性(允许null)前面带一个空心圆,必须的属性(不允许null)前面带一个实心圆,唯一标识属性前面带一个#符号(因为制图工具原因,有时可选属性前面不使用任何符号,必须属性前使用一个点)
Relationship:
Barker表示法中可选项通过半边连接线的虚实线表示,表示法如下图所示。
上面的模型中PurchaseOrder必须关联到一个Party,所以关联线在Party一侧的那一半是实线表示;而Party可以关联到0或多个PurchaseOrder,所以关联线在PurchaseOrder一侧的那一半是虚线表示
图:
RichardBarker'sNotation图:
RichardBarker'sNotation
关联基数为n时采用一个三叉线,线条末端没有符号时表示关联基数为1
另外Barker表示法中有一个表示aggregation、composition的特殊符号,例如示例模型中的PurchaseOrder和OrderLine的关系,在OrderLine右侧的三叉线边上添加一个竖线,注意与Crow'sFoot表示法之间的区别
Sub-type:
Barker表示法中子类型显示在父类型的实体框中
Constraint:
Barker表示法仅支持exclusiveor约束,如示例模型中所示,用一条弧线划过2个关联关系
4.IDEF1X模型
IDEF1X是美国联邦政府广泛使用的一种模型,前面示例模型的IDEF1X等效模型如下:
图:
IDEF1X模型图:
IDEF1X模型
Entity&Attribute:
实体使用方框和圆角框表示,独立实体(Independententities,主键不包含其他实体主键值)使用方框,非独立实体(dependententities,主键包含其他实体主键值)使用圆角框。
属性出现在实体框中,主键用线隔开
Relationship:
外键不是使用关联线表示,必须在实体属性中明确的标注外键属性
如果关联关系一方的唯一标识将作为另一方唯一标识的一部分(即identifyingrelationship),关联线使用实线,否则(即non-identifyingrelationship)使用虚线
不同于IE模型,IDEF1X中可选项和关联基数是分开表示的,关联线的一端表示关联基数,另一端表示可选项
图:
IDEF1XCardinality关联基数图示图:
IDEF1XCardinality关联基数图示
如IDEF1X示例模型中,关联基数的图示都是出现在关联关系的左端或者上面,可选项出现在右端或者下面。
对于可选的关联关系(即类似外键允许为null值的情况),在可选项一端使用一个菱形,例如示例模型中EventCategory左边的菱形;对于必须的关联关系(即外键必须为有效的实体标识值的情况),则在可选项一端直接将关联线与实体连接。
对于多对多的情况,两端均使用关联基数符号,可选项问题在模型中通过其他文档标注
关联关系的名称有几种表示方法。
默认情况下遵循从左至右从上至下的顺序,关联关系从左至右的名称放在关联线上方,从右至左的名称放在关联线下方。
也可以使用一个反斜杠将两个方向的名称分开,从左至右从上至下的在反斜杠前面,否则在后面
Sub-type&Constraint
IDEF1X中的子类和关联约束分别如示例模型中所示。
另外一点,示例模型中的子类和关联约束图例中,小圆圈下面都是使用2条横线,这表示模型中已经列举了所有的子类和约束情况,如果模型只是部分列举子类和约束情况,则使用1条横线
Domain:
IDEF1X中定义了domain,domain即数据类型的定义,比如数据类型、取值范围等各种需要运用到属性值上的约束
详尽的IDEF1X规范参考IDEF1X标准:
IntegrationDefinitionforInformationModeling
EXPRESS-G表示法
EXPRESS-G是一个ISO标准ISO10303-11。
示例模型的EXPRESS-G表示法如下(省略了Event、EventCategory部分):
图:
EXPRESS-G表示法图:
EXPRESS-G表示法
Entity&Attribute:
实体使用方框表示,实体名称出现在方框中
属性通过空心圆结束的线条连接到属性值类型,属性名称出现在线条上。
可选属性使用虚线条连接,必须属性使用实现连接
属性值类型使用右边多一条竖线的方框表示,ISO规范中确定的简单数据类型(String,Binary,Logical,Boolean,Number,Integer,Real等)均使用上图中所示的实体框表示。
扩展或者自定义的数据类型使用虚线框表示,例如上图示例中order_date属性的DATE类型。
枚举类型的表示方法如下图:
图:
EXPRESS-G的枚举表示方法图:
EXPRESS-G的枚举表示方法
Relationship:
使用空心圆结束的线条连接关联实体
关联关系的名称出现在关联线上,朝空心圆一端的方向为正向,相反则为反向,反向的关联关系名称前面使用(INV)表示
关联基数紧随关联名称之后,第一个字符可以是S、B、L、A,分别表示Set、Bag、List、Array,后面中括号的内容即为关联基数,问号表示多个。
默认情况下(没有明确标注)关联基数都为[1:
1],因此上图中出现[1:
1]的地方都可以省略
前面提到过的exclusiveor约束,EXPRESS-G中使用Select(可选类型)表示,如上图中的order_line_item
Sub-type:
如上图中Party、Person、Organization所示,连接线使用粗线条
ORM-Object-RoleModeling
下面是ORM2的部分表示法
基本元素
下面是ORM模型几个基本元素图示:
图:
ORM模型基本元素图:
ORM模型基本元素
唯一性约束表示法
ORM中唯一性约束是在相应角色上使用带箭头的线条表示,线条在哪些角色上,则这些角色的组合必须唯一,例如下图:
图:
ORM模型唯一性约束表示法图:
ORM模型唯一性约束表示法
图中PersonisofGender的关系中,Person必须唯一,因此这是一个n:
1的关系。
同样PersonwasborninCountry是1:
n,PersonspeaksLanguage是n:
m,PersonispresidentofCountry是1:
1
下面表格是用于理解PersonisofGender、PersonwasborninCountry的数据示例:
图:
数据示例
关联关系中必须的角色使用带圆点的线条表示,如上图中PersonwasborninCountry
上面示例中的唯一性约束都是位于一个关联关系(包括二元和多元关系)中,这种唯一约束叫做内部唯一约束InternalUC。
多个关联关系组合起来形成的唯一约束称为外部唯一约束ExternalUC,例如下图所示
图:
ORM模型ExternalUC图:
ORM模型ExternalUC
图中State具有2个外部唯一约束,一个是Country+StateCode,圆圈中使用2跟线条表示这个唯一约束作为State的主键;另一个是Country+StateName
Inclusiveor((disjunctivemandatoryrole)
图:
ORMInclusiveor表示每个Visitor必须有护照Passport或者驾驶执照DriverLicence,或者两样都有
Exclusive
图:
ORMExclusive约束表示Person不可能同时是married和widowed状态
exclusiveor则是inclusiveor和exclusive的结合,即必须是其中之一
图:
ORMExclusiveor约束
详细的ORM2图形表示法参考ORM2GraphicalNotationSummary
使用ORM建模的过程示例参考ObjectRoleModeling:
AnOverview
ORM2的完整介绍参考ORM2
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 种数 建模 方法
![提示](https://static.bdocx.com/images/bang_tan.gif)