Data Modelling ERwin.docx
《Data Modelling ERwin.docx》由会员分享，可在线阅读，更多相关《Data Modelling ERwin.docx（58页珍藏版）》请在冰豆网上搜索。
DataModellingERwin
DataModelling
说明：
本文档是平时工作的积累，正在完善和补充，这里基本采用80/20法则，大部分内容是工作中经常用到的，并且可以解决大部分的问题。
由于里面夹杂各种参考资料以及自己对这些资料的理解，其间可能存在许多不全面的，甚至错误的地方。
这里主要讲述与ERwin相关的建模知识。
作者：
Garfield
发布日期：
2008-06-05
修改日期及内容：
目录
第一章数据建模4
1模型初步4
1.1数据模型4
1.2关系模型实例4
2ER基础6
2.1实体、属性和关系6
2.1.1ER框图6
2.1.2框图语法6
2.1.3候选键属性6
2.1.4关系定义6
2.1.5读ER图7
2.1.6泛化结构和继承7
2.2关系和外键属性8
2.2.1标识关系8
2.2.2非标识关系8
2.2.3独立实体8
2.2.4依赖实体8
2.2.5角色名9
3命名与定义10
3.1命名原则10
3.1.1单数名称10
3.1.2清楚的名称10
3.2定义原则11
3.3域11
3.4数据类型与角色名12
3.5定义业务规则12
4模型深入12
4.1实体深入12
4.1.1实体类型12
4.1.2实体分类结构13
4.1.3完全与不完全分类结构15
4.1.4何时形成分类结构16
4.2关系类型与基数16
4.2.1基数16
4.2.2一对多-标识关系17
4.2.3一对多-非标识关系17
4.2.4递归关系17
4.2.5多对多关系17
4.2.6N-ary关系18
5规范化19
5.1规范化问题19
5.1.1重复数据组19
5.2.2一个属性多个用途20
5.2.3相同事实的多个值21
5.2.4相矛盾的事实22
5.2.5丢失信息24
5.2.6统一25
5.3范式汇总25
5.4ERwin支持的规范化26
6IDEFIx数据建模方法论26
6.1三层模式26
6.2建模方法26
6.3建模方法论27
第二章ERwin工具使用28
1ER使用指南28
1.1ERwin工作区28
1.1.1ERwin工作区28
1.1.2ERwin模型28
1.1.3ERwin建模方法28
1.1.4ERwin工具栏29
1.1.5ERwin导航栏29
1.2基本数据模型对象29
1.2.1实体与表29
1.2.2属性与列29
1.2.3键域与非键域29
1.2.4实体类型30
1.2.5关系Relationship30
1.3关系Relatioship31
1.4显示层级32
1.5主题区33
1.6创建索引34
1.7ERwin展示工具35
1.8设计层Layer36
2将表导入到数据库中37
3将数据库表结构导入到ERwin中47
第一章数据建模
1模型初步
1.1数据模型
DataModel（数据模型）：
一种运用一般业务知识來表現业务需求的一种数据结构规则。
DataModeling（数据建模）：
一个结构化的方法，去定义一个信息系统元件的规格说明。
信息模型的作用：
1、提供企业整体信息共享，2、以图形提供专业化业务规则与需求，3、作为技术人員与企业人員的桥梁，4、建立一致性5、建立一种静态数据模型。
目前的数据库主要有三种数据模型：
关系模型，层次模型和网状模型。
基于层次模型的数据库用嵌套的数据结构存储数据；基于网状模型的数据库，其数据被组织在网的节点和连接中；基于关系模型的数据库，其数据被存储在二维表中。
实体-关系图（Entity-RelationshipDiagram）或者ERD常用来表示数据模型。
ERD适用于所有三种模型，但最适用于关系模型。
下图一个关系模型中的二维表：
TEAM
Team-Name
Year
Team-City
Mets
1989
NYC
Yankees
1989
NYC
Dodgers
1989
LA
RedSox
1989
Boston
在关系模型中，所有数据值必须是原子的（不可再分），即在一个单元中不允许存储分离的值。
例如，如果我们想存储有关1990Mets的信息，不能把1990加入到已存在的行，（Mets，19891990，NYC）。
相反，我们必须单独在表中增加一行（Mets,1990,NYC）。
下图表示关系模型中两个实体（PLAYER、TEAM）以及实体间关系has。
读作”ATERMmanyPLAYERs”。
1.2关系模型实例
ERD是用来支持业务领域的数据结构和业务规则的规范，它表示一套业务信息需求。
数据建模是描述信息结构和捕获业务规则的过程，是信息系统设计的重要组成部分。
下图是一个ER实例：
对ER图作如下说明：
1、仓库中的一部电影MOVIE有１个或多个电影拷贝MOVIE-COPY，MOVIE中记录的信息包括电影的名称、等级、租用率。
2、消费者CUSTOMER租用电影拷贝MOVIE-COPY。
电影租金记录MOVIE-RENTAL-RECORD记录了消费者CUSTOMER租用的每个电影拷贝MOVIE-COPY。
有时相同的电影拷贝MOVIE-COPY租给多个消费者CUSTOMER。
3、每个电影租金记录MOVIE-RENTAL-RECORD也记录电影的期限日期，和一个指示是否超期的状态，根据消费者以前和商店关系，指定消费者CUSTOMER信用状态代码，它指示结帐方式：
记帐、信用卡、现金。
4、商店的雇员EMPLOYEE被包括在许多的电影-租金-记录中MOVIE-RENTAL-RECORD，至少一职员包括在每个记录。
由于同一天同一个职员EMPLOYEE也许多次包括在相同的租用记录中，将来通过时间邮戳来区分。
5、消费者CUSTOMER的支付的租金被记录在电影-租金-记录MOVIE-RENTAL-RECORD中，超期费用也记录在其中。
超期通知OVERDUE-NOTICE用来提醒消费者返还磁带，有时职员被列在超期通知中OVERDUE-NOTICE。
6、商店保存雇员的工资和地址信息在雇员表EMPLOYEEs中，有时需要查看消费者、雇员、电影名字，而不是他们的“编号”。
这是个相对小的模型，但是它说明许多有关视频租用商店的信息。
从它，我们不仅能获得业务数据库的思想，而且也到达对业务的一个好的形象描述。
在这个框图中有一些不同类型的图形：
实体、属性、关系和其它描述业务规则的符号。
2ER基础
2.1实体、属性和关系
2.1.1ER框图
ERwin框图主要由三种组件组成------实体、属性和关系。
如果我们把框图看成是表达业务语句的图形语言，那么实体是名词，属性是形容词或者修饰词，关系是动词。
用ERwin建模是一件简单的事情------找出正确的名词、动词、形容词集，并把放在一起。
2.1.2框图语法
在ERwin框图中，消费者CUSTOMER实体由一个带有名字的方框来表示，实体的所有属性在框内，实体名总是用单数名词。
实体框图中的水平线把属性分为上下部分，线上叫做键区，线下叫做数据区。
CUSTOMER的键属性是customer-number，非键属性是customer-name、customer-address。
标识实体的属性集称为实体的键。
键属性本身是一个属性，或者只有一个，或者与其它键属性结合，将形成对实体的唯一标识符。
主键被放置在线上方的键区域，非键属性是不能作为键的属性，它们被放置在数据区。
2.1.3候选键属性
选择实体的键是重要的一步，并且需要认真地考虑，一个实体也许有几个属性，或属性组作为主键。
那些被选择出来作为主键的属性、或属性组叫候选键属性，候选键必须唯一地标识实体的每一个实例，不允为NULL。
通常，主键的选择需要一定的判断力，而且必须仔细选择，不能仅凭想像。
2.1.4关系定义
关系表示实体间的连接connection、链接link或关联，他们是框图的“动词”，用来显示实体间的相互联系，下面是一些例子：
ATEAMmanyPLAYERs.
APLANE-FLIGHTmanyPASSENGERs.
ADOUBLES-TENNIS-MATCHexactly4PLAYERs.
ASALESPERSONmanyPRODUCTs.
所有这些，都是1---对---多的关系，意思是第一个实体的一个实例与第二个实体的多个实例关联或连接，在“1-端”的实体叫父实体，在“多端”或圆点端的实体称为子实体。
2.1.5读ER图
如果选择正确的动词短语，就可以使用动词短语从父实体到子实体来读关系。
如：
ACUSTOMERmanyMOVIE-RENTAL-RECORDs
AMOVIEmanyMOVIE-COPYs.
APERSONmanyHOBBYs.
下一个例子包括关联的实体（关联表），他们更难于”读”。
APERSONmanyADDRESS-USAGEs.
AnADDRESSismanyADDRESS-USAGEs.
动词短语也可以从子实体读起，如”被动动词”短语表达，例如：
AMOVIE-RENTAL-AGREEMENTaCUSTOMER.
AMOVIE-COPYaMOVIE.
AHOBBYaPERSON.
由上面可以看出，ERD揭示了许多业务规则，虽然他们不能精确地描述，但他们让看模型的人获得实体的初步了解。
把模型读回到业务，是验证业务规则正确性的主要方法之一。
2.1.6泛化结构和继承
泛化或继承层次也叫做子类，或子范畴层次，是实体集分组的一种方法，这些被分组的实体共享公共特性。
例如，一个银行中有几个不同类型的帐户ACCOUNTs存在，如支票、存款和贷款帐户叫做ACCOUNT的泛化实体（或类实体）。
IDEF1X使用category来引用”子类型”。
2.2关系和外键属性
ERwin使用共享键表示关系。
在ERwin框图中的实体通过关系来连接，关系贡献键给子实体，外键属性定义为父实体的主关键字属性，通过关系贡献给子实体，贡献的键称为父实体到子实体的迁移，在模型中外键属性通过属性名后的（FK）来表示。
2.2.1标识关系
在标识关系中，外键迁移到键区（线上）。
关系被称为标识，是因为父实体的键成了子实体标识的一部分，即子实体的标识依赖于父实体。
标识关系用连接两个实体间的带点实线来表示。
2.2.2非标识关系
非标识关系中，使用虚线连接父实体和子实体，外键迁移到数据区（线下）。
非标识关系中迁移的键不是子实体主关键字的一部分，因此子实体就不能由父实体来标识。
2.2.3独立实体
实体被指定作为独立实体，或依赖实体，取决于其键的获得方式。
独立实体由方角盒来指定，独立实体不依赖于模型中任何其它实体来标识。
如MOVIE实体由movie-number来标识。
2.2.4依赖实体
依赖实体被指定为圆角盒，依存于模型中的其它实体。
通常，关系引起实体间的依赖，目前有存在依赖和标识依赖。
存在依赖：
子实体的存在依赖于父实体的存在。
标识依赖：
不使用父实体的键就无法标识依赖实体。
标识关系总是导致存在依赖和标识依赖。
非标识关系不引起任何标识依赖，然而他们中有许多存在依赖。
标识依赖，如没有球队名就不能标识球员。
2.2.5角色名
Rolename是外键属性的新名字，角色名定义一个新属性，它用来描述由关系体现的业务。
这儿有一个简单例子：
球员PLAYER的键属性“player-team-id.team-id”给我们演示定义和显示角色名的语法，第一半（点号之前）是角色名role-name，第二半是外来键的原始名称，称基本名称base-name。
就象任何其他属性一样，角色名通过关系迁移。
如下例所示，演示了在各种比赛中各个球员的得分情况。
这里，我们为SCORING-PLAY的主键创建一个新角色，如下图所示。
角色的”链”沿着所有路径从SCORING-PLAY回朔到TEAM。
然而，注意只有一个链的”链接”被显示。
3命名与定义
3.1命名原则
模型中的各个对象命名非常重要，特别是实体和属性的命名。
好的命名和定义可以很好的帮助其他开发人员读懂模型。
3.1.1单数名称
实体命名使用单数名称。
由于两个实体由关系相连，这样我们可以从两个方向读关系。
如：
“AFLIGHTzeroormorePASSENGERs”
“APASSENGERoneFLIGHT.”
属性名称也用单数，因为他仅仅描述一个特征。
如“person-name”、“employee-SSN”、“person-hobby”。
如果有一个人有多个hobby，我们也不要定义为“person-hobbies”，而是另外创建一个HOBBY实体保存，然后在PERSON与HOBBY之间建立关联关系。
3.1.2清楚的名称
清楚地表达实体和属性的名称非常重要。
例如人、消费者、职员，虽然它们都表示一些个体，但其意义是有差别的，他们有不同的特性。
小心地挑选名称，不要把两个不同的东西叫做相同的名字。
选择名称要符合业务习惯。
通常，给实体和属性一个好的定义与取一个好名称一样重要。
一个好的名称来自对模型的理解和经验。
3.2定义原则
虽然ERwin并不强求为每个实体定义，但良好的习惯有助于其他开发人员理解模型。
其实给实体一个精确的定义是非常困难的。
精确的定义也有助于我们检查实体是否使用正确。
描述实体定义应当清楚、简明。
但是描述不能太概括或没有说清实体的概念。
给实体定义时提供典型的业务实例是一个好主意，好实例能够帮助读者理解定义。
但要避免用实例来定义，因为实例只是定义的个体，并不能完全说明定义，显得有点“不专业”。
通常应当给定义加入注释，如，它的状态，何时做的修改，来源等，它作为定义的一部分是非常有用的记录。
注释解释了被定义实体类似的东西，而不是其中的每一个实例，例如：
消费者CUSTOMER和主顾PROSPECT是有区别的，初看时它们好象是相同的东西，但他们的确不同。
对联合实体（关系表）下定义是有点困难的。
联合实体经常用于表示多对多的关系，多对多关系被拆分成中间带有联合实体的两个一对多关系。
同实体一样，属性的清晰定义也是非常重要的，定义规则也类似。
通常，属性的定义应当与实体定义的基本结构一样（如：
描述，例子，注释等），描述和注释肯定要用，有时业务实例也是有用的。
3.3域
域是属性所能接受的值的范围，简单说就是数据类型。
例如：
person-name如果定义为thepreferredformofaddresschosenbythePERSON，那么他的域就是字符串集合。
通常关系模型中，属性定义在域之上，属性的定义如代码，标识符，数量等，但这通常不用于业务例子。
包含属性域的描述通常都是好主意，定义域时也应列出属性可以采用的“值”，假设我们定义属性customer-status如下：
Customer-status：
描述消费者与商行间关系的代码
Domain
Meaning
A:
Active
TheCUSTOMERiscurrentlyinvolvedinapurchasingrelationshipwithourcompany.
P:
Prospect
Someonewithwhichweareinterestedincultivatingarelationship,butwithwhomwehavenocurrentpurchasingrelationship.
F:
Former
TheCUSTOMERrelationshiphaslapsed---i.e.,therehasbeennosaleinthepast24months.
N:
Never（dobusinesswiththisguy）
Thecompanyhasdecided（forreasonswemightgoontodescribe）thatnobusinesswillbedonewiththisCUSTOMER.
属性域已经定义，这些定义是属性定义的重要组成部分。
3.4数据类型与角色名
模型中的几个属性可以通过相同的域来定义，即他们将有相同允许值（数据类型），而不是相同定义。
ERD通过关系把外键贡献给实体，IDEF1X提供角色名来允许相同属性的不同出现，来扮演不同角色。
CURRENCY的键是currency-code，该键在不同的关系boughtby、soldby中的角色可以是
bought-currency-code、sold-currency-code。
我们把bought-currency-code和sold-currency-code看作是currency-code的数据类型，但它们与currency-code.是不同的。
FOREIGN-EXCHANGE-TRADE的实例bought-currency-code和sold-currency-code必须是不同的通过给不同定义两个角色名，可以获是两个不同的货币代码。
Attribute/Rolename
AttributeDefinition
currency-code
TheuniqueidentifierofaCURRENCY.
bought-currency-code
Theidentifier（"currency-code"）oftheCURRENCYboughtby（purchasedby）theFOREIGN-EXCHANGE-TRADE.
sold-＊currency-code
Theidentifier（"currency-code"）oftheCURRENCYsoldbytheFOREIGN-EXCHANGE-TRADE.
从上表可以看出，bought-currency-code、sold-currency-code的定义和域是基于currency-code.的，Currency-code叫基本属性baseattribute。
？
？
3.5定义业务规则
业务规则是完整信息模型的一部分，许多业务规则可以从实体、属性、域的定义中找到。
如CURRENCY实体，可被定义为“所有公认流通的有效货币”，也可定义为“公司日常业务中使用的货币”，这两个定义是不同的。
？
？
4模型深入
4.1实体深入
实体是信息模型的基本块；实体包含属性；实体间可以通过关系连接；实例是实体的单个具体取值；键属性标识实体。
属性有域，域描述了允许属性使用的值或值的范围。
关系连接两个实体，并且有基数。
基数表示两个实体中的每一个有“多少”被涉及；关系从父实体贡献外键到子实体；外键可能有角色名。
4.1.1实体类型
独立实体：
它的标识不依赖于模型中任何其他实体的实体。
依赖实体：
它的存在和标识都依赖于模型中其它实体的实体。
可以分为如下几种类型：
特征实体
特征实体表示一组属性，它们在一个实体中多次重复，并且不能由其它实体直接标识。
例如：
假若一个人有许多爱好，爱好就被说成是人的特征。
如图：
联合实体
联合实体记录两个以上实体间的关系。
例如，一个人有多个地址，一个地址可被多个人共用，ADDRESS-USAGE实体表示人和地址间的关系，ADDRESS-USAGE实体称为联合实体，联合实体携带有关关系信息。
指示器实体
指示器实体与联合实体非常相似，但其没有自己的属性。
在前面例子中，如果除了PERSON和ADDRESS的标识信息外，不保存别的信息，那么ADDRESS-USAGE实体就是一个指示器实体（从人的方面看，它“指定”地址；从地址方面看，它“指定”人）。
4、分类实体
前面我们介绍的ACCOUNT就是分类实体。
分类实体在子类关系中。
4.1.2实体分类结构
下面是一个实体分类结构的例子。
下面推导模型的建模过程。
首先我们有三个实际的实体，如下：
1、首先新建一个实体ACCOUNT，用它作为三个子类实体的父类实体，其键account-number。
为了区分各个账户，在父类实体增加属性account-type。
2、接下来分析三个子类实体，将他们共有的属性移到父类实体，各个子类实体不同的属性仍然保留在各自的子类实体中。
3、比较三个子类实体，他们都有属性open-date，如果三种实体的open-date是相同的，就把它们移到父类实体，同时从子类实体中删除该属性。
4、以相同方式处理属性account-review-date。
5、三个子类实体中都有结算金额，CHECKING-ACCOUNT中有checking-balance和available-balance，SAVINGS-ACCOUNT有saving-balance，LOAN-ACCOUNT有current-loan-balance，我们应当把它们移到父类实体中吗？
这要取决他们的定义，checking-balance、savings-balance、current-loan-balance含义是乎相同，但仔细分析后发现，checking-balance、savings-balance是相同的，而current-loan-balance差别却很大。
大部分属性相同，而只有少数不同，在这种情况下有两个选择：
要么把这些属性留在子类实体中；要么移动相同的属性，留下不同的属性。
这将意味着，没有移动的子类实体的在父实体的属性值是NULL，非键属性允许为NULL。
在高层次的模型中，如何决策取决于有多少实体共享公共属性，如果全都共享，移动它们，如果只有少数类共享，最好是不移动；在低层次的模型中，取决于目的，经常是不移动。
如下图，结算金额仍然留在子类实体中。
4.1.3完全与不完全分类结构
用不同的符号来标记父类实体的集合是否完全。
下图表示不完全分类结构（即父类实体还可能有其他子类实体，只是这里没有列出）。
职员EMPLOYEE可能是顾问CONSULTANT或者是专职职员FULL-TIME-EMPLOYEE，分类符号底部的单线表示也许还有其它没有包括的子类实体。
下图表示一个完全分类结构。
在这里职员EMPLOYEE要么是男职员MALE-EMPLOYEE，要么是女职员FEMALE-EMPLOYEE。
下图表示完全分类与不完全分类的结合。
职员EMPLOYEE是顾问CONSULTANT或者专职职员FULL-TIME-EMPLOYEE。
同时，职员EMPLOYEE也是男职员MALE-EMPLOYEE或女职员FEMALE-EMPLOYEE。
下图继续扩展这个分类结构：
4.1.4何时形成分类
升级会员 