1. Pentaho Metadata Editor 基础知识
1.1 连接(connection)
连接表示了和数据库的连接信息,处在数据库中所有实体表、实体列的最上层。
Pentaho 元数据模型能够通过 jdbc 和几乎所有的关系数据库相连。
1.2 实体表(Physical Table)
实体表是一个和数据库表直接映射的表信息对象。
1.3 实体列(Physical Column)
实体列是一个和你的数据库表的列直接映射的列信息对象。
1.4 业务模型(Business Model)
一个业务模型包括所有的逻辑、抽象业务对象和通过一定方式形成的实体数据库
对象之间的关系。那种方式保证了实体数据库对象可能的变更对你的业务、业务
程序、最终用户影响最小。在一个单个的域中能有多个业务模型。一个业务模型
目前只支持一个数据库连接,它由业务表、关系、和一个业务视图构成。
1.5 业务表(Business Table)
业务表是实体表的逻辑表示。这些业务表模型形成的层次把你的应用、用户和数
据库的变化隔离开了。这些业务表模仿你的实体表,所以当数据库改变时,你只
需要业务层次上的元数据模型,而不用去更改数以百计的那些当初用户依赖数据
创建的报表、仪表盘、转换等
1.6 业务列(Business Column)
业务列是实体烈的逻辑表示。更多细节参照业务表。
需要注意的是业务列的“父亲”可以是业务表也可以是业务类。尽管他们的
“父亲”不同,他们表示的依然是相同的实体列,但这样做有不同的目的,如
果业务列是业务表的孩子,它有点像模仿实体列的角色,起的作用是展示和业
务表的关系(比如主键和外键);如果业务列是业务类的孩子,它代表能给用
户最终使用的列。
1.7 业务关系(Business Relationship)
业务关系描述两个表之间的关系,这意味着关键键值列在两表之间匹配,如
1:1, 1:N, N:N 关系,对所有有这种关系的模型表业务关系都需要定义,在选
择 join 方式的时候,系统会自动带出关系类型,经过测试,带出的默认关系
是正确的,不需要更改。
1.8 业务类(Business Category)
业务类表示的业务列的逻辑分组,需要注意的是向某个业务类中添加的业务列
可以来自多个不同的业务表。即使你可以从一个业务表创建一个业务类(一种
常见的例子),但一个业务类和业务表没有任何关系。业务类主要是用来重新
组织业务列,使那些让用户觉得独立的,互相联系不紧密的业务列按照某种逻
辑进行分组,使得用户使用元数据时更加清晰明了。
1.9 业务视图(Business View)
业务视图是业务类的集合,表示你的模型的视图,主要供最终用户使用。每个
模型有且仅有一个业务视图。业务视图是由一组业务类和业务列按照逻辑构成
的,这种逻辑是和你的组织结构和终端用户相关的。
1.10 属性 Property(Properties)
属性表示你将详细描述的元数据的特征。一个属性有一个标识(实际是 map
的键)和一个值。举个例子,“font”是标识,它的值是“arial”
1.11 概念(Concept)
概念是属性的集合,是你想运用在一个特殊业务对象(比如业务列和业务表)
的特征的映射,这个特征可能包含一个到多个属性。
每个业务对象(实体表、业务表、列等等)都有自己的概念,其中的属性可以
改变,覆盖其继承的概念或“父概念“中的属性。
根据这个对象和它处的模型层次,一个业务对象可以有一个、或者没有继承概
念。更多细节,参阅模型的继承和层次。回顾参阅 metadata business
modeloverview.
概念也可以是一些业务对象的继承定义,可以通过层次的继承方式,以更好地
组织管理你的元数据。除此之外,还有一种独立的“父概念“可以应用到一个
或多个业务对象。