2022年CWM元模型分析研究及其在广发银行数据仓库中的应用 .docx

《2022年CWM元模型分析研究及其在广发银行数据仓库中的应用 .docx》由会员分享，可在线阅读，更多相关《2022年CWM元模型分析研究及其在广发银行数据仓库中的应用 .docx（18页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、精品_精品资料_CWM 元模型争辩及其在广发银行数据仓库中的应用李珊珊一 数据仓库的描述需求数据仓库是企业级信息治理的一项新兴技术.它的目的是为了将企业的大量历史数据按主题集成在一起,并以一种统一的模式供分析和学问挖掘使用. 数据仓库中技术种类繁多,不象数据库系统那样单一,典型的数据仓库技术包 括数据抽取技术、 OLAP 技术、数据挖掘技术等.构建一个数据仓库需要考虑到它的创建、治理、使用和爱护等诸多方面,如创建过程中要考虑旧数据库系统的数据模型、数据集成的 ETL Extract, Tansfomation and Load 规章、仓库中新数据模型的建立等,使用过程要考虑数据的物理模型和出现

2、方式、对数据进行操作的各种统计分析算法、数据挖掘规章等.对于这些应用需求,数据仓库建模应当具备描述它们的才能,无论是底层的数据源信息,仍是高层的各种操作信息,方方面面都应尽量涉及到.经过分析争辩,发觉OMG 组织的 CWM具备了这种才能,它供应了描述数据源、数据目标、转换、分析、处理、操作1等与建设和治理数据仓库相关的元数据基础框架（构成规章集）,使不同厂商产品的元数据通信和共享有了一个切实可行的标准.在深化懂得 CWM的基础上, 1.2 节总结了 CWM的内容框架和各个组成部分的依靠关系.二、 CWM的内容框架参考数据仓库的描述需求,课题中对CWM 的内容体系进行了总体争辩, 深化分析了它的

3、组成及结构 23 .CWM 基本描述了数据仓库的各个方面,包括基本类型信息、数据资源信息、数据分析信息、仓库治理信息等.当然,它不可能囊括数据仓库中的全部信息,随着数据仓库技术的不断进步,需要描述的新信息也越来越多,这些信息只能被包含进 CWM 的后续扩展规范中. OMG 的CWM 工作小组也在时刻关注数据仓库的最新进展动向.目前的 CWM 版本所包含的信息基本涉及了数据仓库领域的各个方面,虽然不是完全的但至少是描述仓库操作所需的最少信息.另外,对于其所描述的元数据,语义都是精确的、无歧义的.图 1-1 是 CWM 的内容结构图 1,从图中可以看出, CWM 的内容按包组织,每个包尽量涉及一个

4、独立的领域,这样极大的便利了开发者的建模工作,由于在建模时只取所需的包即可.并且,包的数目没有太大,结构更易于扩展, CWM 目前的版本中包含了18 个包和一个 ObjectModel,CWM 的这种特性也使得它易于懂得.每个包都由一系列UML 表示的类图组成.虽然这些包描述的领域不尽相同,但它们组织结构并不完全独立,事实上,它们之间有着紧密的依靠关系.在CWM 的内容框架中,全部包按功能和抽象层次组织成四层,同层的包的功能角色类似,如其次层中的包描述的都是数据仓库的数据资源.每一层中的包都为同层或上层的包供应服务,如第三层包描述的操作都是基于其次层包描述的数据资源,层次越高描述的内容越抽象.

5、在包的结构方可编辑资料 - - - 欢迎下载精品_精品资料_面,或者上层包中的类和关联继承下层包中的类和关联,或者在上层的包直接使用下层包中定义的类或关联,这样做既使整个元模型组织更精练,又使CWM 在功能结构上特殊清楚.图 1-1 CWM的内容结构图如图 1-1 所示,最底层的是 ObjectModel ,分析 CWM的继承图,会发觉它是整个 CWM的基础. ObjectModel 实际是 UML的一个子集, CWM最大程度的重用了 UML中与描述数据仓库领域相关的一些模型元素1,7 .CWM全部包的类与关联都是直接或间接的继承ObjectModel中的类与关联,这样, CWM 可以看作是从

6、 ObjectModel 生长出来的一棵大树,树的根部就是ObjectModel.ObjectModel 以 上的 四个 层 次依 次为 ： Foundation 层 、 Resource 层、 Analysis 层、Management 层. 每个 层次 中 的包都为 高层 （ 或 同层 ） 的 包提 供服 务.Foundation层的元模型主要是代表上层CWM包共享的概念与结构,如表达式、 索引、数据类型、软件配置信息等,虽然这些都是很基本的信息,但它们与ObjectModel中的元素又有所不同,由于这些模型元素专有于CWM领域,而ObjectModel中的元素就更具一般性和通用性. Fo

7、undation层中的包以字母次序给出. Resource 层中包含了 OLTP系统与数据仓库所使用的各种数据资源, 有关系的、层次的、多维的等等,这些数据源都要用到Foundation层的通用信息,如关系包中描述索引和关键字的类都是从Foundation层的 Keys and Indexs包中继承而来.此外, ObjectModel恰好是面对对象的数据源,因此, ObjectModel在整个 CWM承担着两种角色,一方面作为整个CWM的基础,另一个方面又代表了面对对象数据源. Analysis层供应了数据仓库各种操作的元模 型,包括 OLAP、数据挖掘、转换等,它们会被映射到由Resourc

8、e 层的包所定义的数据储备中去.例如, Transformation元模型描述了数据仓库中的数据源 到数据目标的转换, OLAP元模型答应储备在关系或多维数据引擎中的数据仓库以多维视图显示. Management 层定义了操作任务及其调度信息（WarehouseProcess包） 并记 录 了数 据仓 库活 动以 及 相 关的 统 计 信 息（ Warehouse Operation Package ）.CWM 的全部包中的类与关联都尽量利用了UML 中的继承机制,复用已有的元素.并且,全部的基类都只显现在Object Model 、Foundation 和 Resource层中,在更高的层中

9、（ Aanlysis 层和 Management层）, 已经没有基类显现.这样做的主要目的是为了简化高层包中的类图,由于更高层中的类一般都要比低层多.这种组织方式也使得类图更易于懂得,由于类的可编辑资料 - - - 欢迎下载精品_精品资料_总数削减了.图 1-2 是分析得出的包依靠关系图,箭头指向代表依靠方向,即箭头始发处的包中的类和关联继承箭头指向的包中的类和关联.Warehouse可编辑资料 - - - 欢迎下载精品_精品资料_ManagementWarehouse ProcessOperation可编辑资料 - - - 欢迎下载精品_精品资料_可编辑资料 - - - 欢迎下载精品_精品资

10、料_AnalysisResourceFoundationTransformat ionObject ModelOLAPRelationalData MiningRecordInformation VisualizationMultidimension alBusiness NomenclatureXML可编辑资料 - - - 欢迎下载精品_精品资料_可编辑资料 - - - 欢迎下载精品_精品资料_Business InformationData typesExpressionKeys and IndexesType MappingSoftware Deployme可编辑资料 - - - 欢迎下

11、载精品_精品资料_ObjectModelCoreBehaviorRelationshipInstance图 1-2 CWM各包依靠关系图CWM 中的每个包都由一组类图和相应的约束组成,约束使用OCL 来描述.全部的类都只包含静态属性,没有包含任何操作属性,CWM 把操作信息留给工具自定义,从而为CWM 开发商保留更大的灵敏性.另外,类之间的关联使用引用方式表达.考虑到工作量的问题,在1.1 节将以一个独立完整的数据仓库过程为主线详细分析部分包的内容.三、CWM各层内容剖析考虑到工作量的问题,本文将不对CWM 中的全部包进行分析,而是依据实际数据仓库开发的体会只在四个层次中选一部分进行争辩和实现

12、,它们是描述一个 独立 完整 的数 据仓 库 过程 所需要的 最少 建模 元素 . 分 别挑 选了Management层的 Warehouse Process包和 Warehouse Operation包、Analysis 层的Transformation 包和 OLAP 包、Resource层的 Relation 包和 Multidimensional 包以及 Foundation 层中的全部包.在分析这些包之前,先深化剖析ObjectModel.ObjectModel 是整个 CWM 的基础,它为创建和描述CWM 的其它包供应了基本构架.分析过程需要对比CWM 规范中的类图,由于 CWM

13、中的图繁多,因此在正文中只附Core 包的图帮忙讲解.另外,分析由下往上按层次开放.3.1.1 Object ModelObjectModel 是 UML的一个子集,它只含有 UML 中与描述数据仓库有关的部分. ObjectModel 又包括四个包： Core 包 、Behavioral包、Relationship 包和 Instance包.Core 包是核心,其余三个包都依靠且只依靠于Core 包.除此之外, ObjectModel 中再没有其他依靠关系.Core 包Core 中总共有三个图,分别见图 1-3,1-4,1-5.可编辑资料 - - - 欢迎下载精品_精品资料_图 1-3 Co

14、re 包类图 1从图中可以看出, Element 类位于最顶层,事实上,它也是CWM 中全部类的祖先,假如把CWM 想成一个树状的类继承结构,那么Element 就是这棵树的根. Element 中没有任何属性,只是一个抽象元类,包含表达语义信息的模型元素和用于表示的表达元素. ModelElement 是 Element 的子类,前者只描述模型元素.模型元素与表达元素不同,表达元素是以表现模型为目的的图形元素,它们不含有语义信息,而在CWM 中,绝大多数类都是带有语义信息的模型元素. ModeElement 包含了一个最基本且最重要的属性Name.除了少数几 个 类 , 如 Multipli

15、city, 几 乎 所 有 CWM类 都 是 直 接 或 间 接 的 继 承ModelElement.并且 ModelElement 仍作为这些类相互关联的连接点,绝大多数供应通用服务的类,如Dependency,Constraint 等都直接关联到 ModelElement 表示可以为全部的模型元素供应这种服务.Core 包中供应通用服务的类主要有以下这些： Constraint：一种扩展机制,用于描述对模型元素的行为约束. Dependency：定义了模型元素之间的依靠关系,与Dependency 相关联的两个模 型元 素中 , 一 个作 为 依 赖 方（ client ） , 另 一个

16、作为 被依 赖方（supplier）.TaggedValue： 一 种名字值 对的 形式 , 表 示与 详细 应用 相关 的属性,TaggedValue是一种扩展机制.任何模型元素或表达元素都可以带有零或多个名字值对 24 .Stereotype：该类也为 CWM 供应了一种扩展机制.在实际建模过程中,开发人员可能想要传递某种语义差别,但是供使用的可能只有一种建模元素,为了表示这种差别,更精确的反映该模型元素所表达的语义,就可以可编辑资料 - - - 欢迎下载精品_精品资料_用 Stereotype24 .比如说类可以分为实体类,边界类和把握类,而在用UML 建模时就只能用 Class 统一表

17、示,为了在必要的时候加以区分,就可以使用 Stereotype.再从 ModelElement 沿着继承链往下看, Namespace的含义就象通常所说的容器, 它的 目的 是为 了按 某 种逻 辑意义将 元素 分组 .组 包含 一系 列的ModelElement , 且它 与 ModelElement 的 关 系 是 强 聚 合 关联 . 除了 顶级Namespace,几乎全部的 ModelElement 都会属于且只能属于一个Namespace.同 一 Namespace 中 ModelElement 的 命 名 是 唯 一 的 , 命 名 规 就 一 般 为“ Namespace名： M

18、odelElement 名”.因此,使用 Namespace仍可以防止在整个模型范畴内的命名冲突.Classifier 和 Package都是 Namespace的子类,可以这样懂得这两个子类的意义： Classifier 的作用类似于 C+中的.h 文件,而 Package的作用类似于 C+ 中的.cpp 文件,一个描述静态结构,而另一个就描述详细实现.Classifier 有多种详细的形式,包括 Class, DataType等, Classifier 常用作类型（ Type）.作为一个 Namespace,一个 Classifier 仍可以嵌套定义其它的 Classifier.Class

19、ifier 也可能包含一系列 Feature,比如说 Attribute ,Operation 等.Class 是一种最常见的 Classifier,其实 Classifier 的每种子类都可按Class 的概念懂得,只是分别在内容和使用上有了某些特殊限制. DataType 既包含原始的数据类型（如整型, 字符串等）,又包含可定义的枚举类型.一般来说,DataType 常被用来作为属性或参数的类型. Package也供应了一个分组机制,虽然父类Namespace已经定义了“包含“的语义,但Package仍可以表示组织这些元素的依据和目的.一 个包可以通过“导入（ import ）”拜望其它包

20、中的模型元素.当包导入了其他模型元素后,包的范畴就被扩充了,加入了被导入的模型元素. Subsystem的直接父类（即多重继承）有两个：分别是 Package和 Classifier.Subsystem主要表示物理系统中的行为单元,描述一组模型元素的详细行为特点. Subsystem可以向外供应接口,这些接口描述了它与系统其他部分的关系以及使用环境.Model 是从不同视图的角度对系统进行的完整抽象.说它是完整的,是由于它从给定视图全面的描述了系统和实体.一个物理系统可以定义多个 Model,如分析模型,设计模型,实现模型.Feature也是 ModelElement 的子类,它表示一个详细特

21、性,既可以是静态特性（ StructureFeature）也可以是动态特性（BehavioralFeature）,静态特性的一个例子就是属性（ Attribute ）,动态特性的一个例子是操作（Operation）,它们被封装在一个 Classifier 中.有关动态特性的模型元素在Behavior 包中描述, Core 中只描述了与静 态特 性有 关的 模型 元素 . StructureFeature 的类 型由Classifier 确定,既可以是一种简洁的数据类型,也可以是一个复杂类型,如Class等等.可编辑资料 - - - 欢迎下载精品_精品资料_图 1-4 Core 包类图 2在图

22、1-4 中 , 列出了一 些 CWM中的支持类, 分 别是 Expression, Multiplicity和MultiplicityRange . Expression 即 通常 所说 的表 达 式, 它有 两种 子类 型：BooleanExpression 和 ProcedureExpression.BooleanExpression 描述布尔表达式的求值,而 ProcedureExpression描述一个过程表达式的运算,其运算结果可能会影响当前系统的运行状态. Multiplicity表示答应的候选值范畴,也就是通常 在关联端的使用的取值个数 约束.由 于取值空间 可能不 连续,所以

23、一个Multiplicity又可能包含多个 MultiplicityRange ,一个 MultiplicityRange 定义一个整数范畴,下限必需是非负数,上限没有限制,可以是无穷大.图 1-5 Core 包类图 1图 1-5 描述了CWM 的扩展机制,共有包含三个元素：TaggledValue, Stereotype,和 Constraint.上面已经提到过, TaggledValue答应信息以名字值对的形式附加到任何模型元素,详细的含义已经超出了CWM 的范畴,在交换元数据时,交换双方必需要有对名字值对的统一懂得才能交换这些名字值对.Constraint 和 Stereotype上面已

24、给出,这里不在赘述.Behavioral 包Behavioral 包中主要描述了Classifier 的行为特性,如附录中图A-4 所示.在该包中,最为重要的一个类就是BehavioralFeature, BehavioralFeature描述模型元素的动态特性.从日常的观点来看,BehavioralFeature代表程序规律中的可执行单元,因此,它包含一系列的输入输出参数以及返回值.BehavioralFeature 的参数用 Parameter类来表示. Method 和 Operation 都是 BehavioralFeature的子类, Operation 描述某种转换或查询,它有自己

25、的名称和参数列表,是程序规律的可直接调用的单元,而Method 就表示 Operation 的实现,它指定了完成Operation 的算法规章和过程描述,一个Operation 可以有多个 Method 实现,每个实现 可能 使用 不同的程 序语 言, 不同的算 法. CallAction描 述对一个可编辑资料 - - - 欢迎下载精品_精品资料_Operation 的详细调用,它仍指定此次调用的实参,实参用Argument 类表示, 它与 Parameter不同, Parameter主要是指形参. Interface 是 Classifier 的子类, 它是一系列 Operation 的集合

26、,定义了能给外界供应的服务,只包含服务名而不包含实现. Event 类描述一次值得留意的大事,它也包含多个Parameter,如鼠标点击大事中的参数包含点击处的坐标等等.但是,在CWM 中并没有描述当大事发生以后将会实行什么行动,这个将留给详细的应用去处理.Relationship包Relationship 包比较简洁 ,主要描述对象（即元数据）之间如何关联,关联有 两类： Generalization和 Association,如附录中的 A-5 所示. Generalization 描述较为通用的 classifier 和较为特殊的 Classifier 之间的关联,就如同 UML 里的继

27、承,这种关联把类组织成一种层次的结构.很明显,与Generalization 相关联的两个 Classifier 所充当的角色一个叫child ,代表较为特殊的一方,另一个是parent,代表较为通用的一方.在CWM 中,答应显现多重继承的形式,即一个child 可以对应多个 parent,说明作为 child 的 Classifier 同时含有多个作为 Parent 的 Classifier 的特性.Association 即常说的关联.一个Association 可以有多个 AssociationEnd（ 至少 两个 ） 两 个的话被 称为 binary , 大于 两个 的被 称为 n-a

28、ry , Association 与 AssociationEnd 之间是通过 ClassifierFeature 关联起来的.有三种类型的 Association：ordinary association（一般关联） , composite aggregate（组合式聚合关联）和 shareable aggregate（共享式聚合关联）. ordinary association 是通常意义上的关联,任何有联系的模型元素之间都可以由这种关联建立联系.composite aggregate和 shareableaggregate只有在二元的 Association 下才有意义.在 compos

29、ite aggregate 中,被包含的模型元素最多只能被一个组合端所 拥有,组合与被组合端的生命期是一样的,即假如组合端被破坏,被组合端的模型元素也会随之破坏,从实现的意义上来看,组合端为它所包含的模型元素支配内存并负责回收.对于shareableaggregate,顾名思义,一个模型元素可以被多个组合端共享拥有,当聚合端被删除时,有可能它包含的部分照旧存在.Instance包在元数据进行交换时,有时候也需要附带一些实例数据（即M0 层的数据）. Instance包就是用来描述实例数据的构成规章,如附录中图A-6 所示.在 CWM中,每个 Instance 类对应一个详细的Classifie

30、r,用来定义该Instance 的静态和动态特性. Instance 有两种类型：要么是简洁数据值（如一整数值或字符串值等）,要么是对象.对象中拥有一些Slot（槽）,每个slot 对应一个静态特性,假如某个静态特性本身的类型又是一个Classifier,就该对象包含另一个 Classifier 的对象,后者本身又拥有自己的Slot.如此递归下去,直到全部 Slot 值都是简洁的数据类型为止.3.1.2 Foundation层Foundation层元模型描述其它 CWM 包所共享的概念与结构. Foundation层中主要有六个包： BusinessInformation, Expressio

31、n, KeyandIndexs, Typemapping, DataType, SoftwareDeploymen.tBusinessInformation包BusinessInformation 包描述了一些面对商业的信息,包括数据仓库系统的责任方,责任方的联系信息以及系统描述文档等.这些商业信息虽然不行能是有可编辑资料 - - - 欢迎下载精品_精品资料_关商业环境的完整表示,但包含了CWM 设计组认为是为了完成数据仓库元数据交换所必需携带的商业信息,如附录中图A-7 所示. BusinessInformation包只依靠 OjbectModel 中的 Core 包.该包主要定义了三个概念

32、：ResponsibleParty, Document 和 Description,它们都是 Namespace的子类.Description表示通用的描述信息,这些信息与CWM元数据存放在一起.一般而言, Description描述了对相关元数据的帮忙、指南信息或注释, Description甚至仍可以描述其它的Description.Document 与 Description 特殊类似,它们之间主要的区分在于Document不与元数据一起存放,而仅在元 数据中指明 Document 的位置.存在这两种方式的缘由是为了防止元数据交换被大且结构复杂的文件所累,由于Document 可能很大很

33、复杂. Document 可以以层次方式组织,即其中包含章,节,副标题等.ResponsibleParty主要描述对元数据负责的人或部门,由于是Namespace 的子类,所以它也可以形成层次树的结构, ResponsibleParty可以表示一个完整的组织机构图,答应每一个组织 单元都直接 和信 息系统中一个特定 方面 绑定 . ResponsibleParty与多个Contact 相关联.每个 Contact 信息代表该责任方的联系信息,如Telephone, E-mail , Location ,ResourceLocator ,它们都是 ModelElement 的子类,意义很直观,此

34、处不说明.DataTypes包DataTypes包为建模者供应了自定义所需特殊数据类型的一些模型元素.该 包只依靠于 Core 包.Core 包中的 DataType 类描述了简洁原始的数据类型,而这 个包 中主 要 供应 定义 较复杂 数 据类型 的 功能, 如 ： Struct , Union 和Enumration,如附录中图 A-8 所示. Struct 类型比较简洁,就是Classifier 的一个子类, 图中 没有直 接 给出. Struct 类型中 的每个 域对 应 Classifier 的一个StructureFeature.Enumration 类型即枚举类型,代表一些常量值

35、的命名集合,由于这些值的数据类型一样,即整个Enumeration 的类型是单一的,所以可以把Enumration 作为 Datatype 的子类,它包含的每个常量用EnumerationLiteral 来表示,留意,常量仍可以是某个固定的范畴,如47.TypeAlias 也是 DataType 的子类,它主要是为 Classifier 供应重命名的才能. Union 是较为复杂的数据类型,它可以被认为由一系列简洁、可选的结构类型Union Member 组成, 但在同一时间只答应一种Union Member 代表 Union 被使用. Union 有两种类型, 分 别是 ： Discrimi

36、nated Union 和 Undiscriminated Union . Discriminated Union 带有一个Discriminator 的属性,它可以用来指明当前使用的是哪一种Union Member,可以通过UnionDiscriminator 关联找到这个 Discriminator .而Undiscriminated Union就没 有 Discriminator属 性, 所 以 当 Union表 示为Undiscriminated Union 时, UnionDiscriminator 关联的 Discriminator 端的多样性为零.图中并没有画出全部 Union

37、和它所包含的 Union Member 之间的关联,直接 通过 继承 父 类之 间的 ClassifierFeature 关联 来 表示 这些 意义 . 另 外, QueryExpression（查询表达式）是PorcedureExpression的子类,描述要做的查 询操作,但不包括详细怎么做,其实例中所包含的查询声明与详细语言无关,把 QureyExpression放在此包的目的是由于表达式的返回值也可能是一种复杂的数据类型.Expression包Expression包描述了表达式的树型产生规章,实际应用可以据此追踪数值的来源. Expression包也只依靠于 Core包.可编辑资料 -

38、 - - 欢迎下载精品_精品资料_从附录图 A-9中可以看到,一棵表达式树的全部节点都从ExpressionNode派生,表达式可以看成是一些 ExpressionNode的子类的实例按层次的方式组织在一起的集合. ExpressionNode派生自 Element,它有三种子类型,分别是： ElementNode, ConstantNode,和 FeatureNode.FeatureNode描述了常规特性,如属性或操作,当是操作的情形下, FeatureNode通过与 ExpressionNode之间的OperationArgument关联描述操作的参数,参数可能是常量,用ConstantN

39、ode表示,也可能又是某种 FeatureNode,如此递归下去,假如 FeatureNode的参数为空,就说明这个 FeatureNode是一个属性或一个无参操作.参数仍有可能是ElementNode, ElementNode表示那些不能用 FeatureNode表示的模型元素.ExpressionNode与Classifier之间的关联说明这个 ExpressionNode的详细类型,意义同core中描述,该这个关联是可选的,只有在需要返回值的ExpressionNode节点（如等号操作的 FeatureNode）时才需要. ExpressionNode中的Expression属性给出表达

40、式的文字表述.这个包中所描述的表达式与 Core中的Expression类有所不同,ExpressionNode是一种白盒表达式,它不但给出了表达式的文本内容,仍定义了表达式的语义, Expression类是一种“黑盒”表达式,它只包含了表达式的文本内容以及交换和记录这种表达式所用的语言,而对这种表达式的懂得,就留给开发商去考虑.KeysandIndexes包由于在许多的数据源中都存在关键字和索引的概念,所以将这个包放置在Foundation层中.该包中的许多内容放到关系数据库中将会更好懂得,见附录中图A-10,这个包只依靠于 core包.围绕Keys有两个重要的类,分别是 UniqueKey

41、和KeyRelation.UniqueKey能唯独标识实例的身份,如同关系数据中的主关键字.KeyRelation的概念就象关系数据中的外键一样,它包含在一个实例中,但是可以标识与该实例相关的别的实例的身份. UniqueKey和KeyRelation都与StructureFeature相关联,标明哪些静态特性与它们相关.留意这里 UniqueKey和KeyRelation都是ModelElement的子类,而不是 Classifier的子类,缘由是 UniqueKey和KeyRelation可以被认为是相关StructureFeature所担当的角色,不需要用 Classifier来描述 U

42、niqueKey和KeyRelation的内部结构.而且,在 Core中已经规定,一个 Feature最多只属于一个Classifier.假如将 UniqueKey和KeyRelation 都建模为 Classifier, StructureFeature就会同时属于它的 Class又属于它所参与的关键字.Index对应通常意义的索引,指存放着元素实际位置的一个列表,它的序列并不代表元素的物理次序,当查询与索引的结构相匹配时,索引能加快检索的速度. Index与被加索引的 class之间的关系是 span而,不是拥有的关系,这样答应用一个并不属于这个 Class的Index来span它.当然在

43、实际情形中,被 span的Class 一般也是这个 index的拥有者. IndexedFeature用来将 Index连接到详细组成这个Index的StructureFeature上,另外,一个 StructureFeature可以参与多个 Index. SoftwareDeploymen包tSoftwareDeployment包描述了软硬件在数据仓库的配置状况.该包依靠于三个包： Core包, BusinessInformation包, TypeMapping包.先看附录中图 A- 11,SoftwareSystem是Subsystem的子类,代表软件的一个可安装单元.一个Software

44、System可能会引用一个或多个的TypeSystem,TypeSystem定义了 SoftwareSystem支持的数据类型,详细在可编辑资料 - - - 欢迎下载精品_精品资料_TypeMappings包中描述.一个 SoftwareSystem由多个 Component（Component描述的软件系统中的静态单位）组成,并且仍可以导入其它SoftwareSystem的Component.DeployedSoftwareSystem类表示在一个机器上实际安装的软件包.类似的, DeployedComponen表t示安装了的 Component.一个 SoftwareSystem可以有多个

45、配置方案,组成 SoftwareSystem的每个 Component也可能有多个配置方案.每个 DeployedComponen与t配置了它的 Machine相关联,而 Machine又放置在详细的Site中, Site代表了一个的理位置,它是 Location（在Business Information包中描述）的子类,可以以任何粒度记录,如一个国家,一座建筑物,或是建筑物里的一间房间.很自然,一个 Site很可能属于别的 Site也可能包括别的Site.再看图A-12,DataManager代表拜望数据库的软件组件,如数据库治理系统或文件系统等,它可能与一个或多个表模式、关系目录、文件或

46、其它数据容器的数据包相关联.实际上, Resource层中描述的每种数据源都会包含一个Package的子类,它们也继承了 Pachage与DataManager之间的关联, DataProvider描述拜望 DataManager所治理的数据库的客户端.例如： ODBC或JDBC客户端.一个 DataProvider可能含有多个 ProviderConnection,指明多个相同或不同 r 的数据库连接. DataProvider仍可以使用别名来拜望数据库,假如别名与DataManager治理的数据库的实际名字不同,可以使用PackageUsage来记录这个别名. PackageUsag是e Dependency的子类,表示一个 ProviderConnection所使用的别名依靠于详细的数据库.Typemapping包Typemapping包定义了类型系统的概念 ,类型系统包含一系列数据类型的集合以及不同类型系统之间的数据类型映射,定义这个包的主要目的是为了在元 数据交换时双方的数据类型能够兼容,该包只依靠于Core包.如附录图中 A-13所示,该包主要有两个类： TypeSystem和TypeMapping.TypeSystem描述一个类型系统中包含的数据类型,TypeMapping描述了类型映射,即一个TypeS