NCV61-语义模型红皮书(整理后)(共69页)_第1页
NCV61-语义模型红皮书(整理后)(共69页)_第2页
NCV61-语义模型红皮书(整理后)(共69页)_第3页
NCV61-语义模型红皮书(整理后)(共69页)_第4页
NCV61-语义模型红皮书(整理后)(共69页)_第5页
已阅读5页,还剩65页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、精选优质文档-倾情为你奉上UAP 6.1语义模型技术红皮书 产业链开发部 编著目录第一章 前言专心-专注-专业本章内容概要:l 概念l 定位1.1 概念SMART,即Semantic Modeling for Analysis Report Toolkit , 分析报表语义建模工具。1.2 定位语义模型把面向技术的数据,组织成面向业务的数据,供业务人员查询分析使用。第二章 结构本章内容概要:l 应用模型l 语义模型l 语义提供者l 函数l 参数l 宏变量l 描述器l 数据加工l 物化策略l 复合语义模型l 语义上下文l 脚本规则2.1

2、 应用模型上图为语义模型应用结构图。语义模型通过语义提供者,可以将多个数据源的数据进行整合。2.2 语义模型2.2.1 定义形态下图展示了语义模型的内部结构:语义模型主要由以下几部分构成:n 元数据元数据是指描述数据的数据,是为了外界使用数据而对数据本身含义的阐述。拿我们最常见的二维数据(行列结构)举例来说,如果只有这些行列结构的数据,对我们来说这将毫无意义。因为我们无法知道哪一列的数据代表什么含义,无法知道如何操作这些数据,更别提由这些数据分析出有用的信息。反过来,如果针对这些数据指定了元数据,我们就可以了解哪一列代表的业务含义,并且知道该列的数据类型、长度、精度 等。这样,我们就能对这些数

3、据进行加工处理,分析提取出有价值的信息。同理,语义模型的元数据是对执行语义模型后获取的二维数据的描述。元数据针对结果数据的每一列都提供了下列信息:数据类型、字段显示名、字段名、备注、长度、精度 等。有了这些信息,我们就能知道在业务应用中该如何使用语义模型。n 语义提供者语义提供者,表述了一类取数方式,或者说如何提供数据的方式。在语义模型中,语义提供者负责把一类业务取数过程以语义脚本的形式描述出来。为了能更好的理解这个概念,我们可以打这样一个比方:NC元数据、数据仓库、报表数据、总账数据 等 这些可提供数据的对象好比“数据水源”,而语义提供者好比“水泵”,语义模型好比“抽水机”。每种“数据水源”

4、只支持特定的“水泵”来抽取数据。我们有了一种语义提供者“水泵”,就能抽取其对应的“数据水源”里的数据。语义模型中能指定多个语义提供者,就相当于“抽水机”挂接了多个“水泵”,我们就能从多个不同类型的“数据水源”来抽取数据。语义提供者负责抽取数据,同时对外提供元数据来描述这些数据。语义提供者的元数据一般是在语义模型内部使用。更多细节以及语义提供者的扩展说明参见章节。n 描述器描述器是指对数据操作的描述,例如:过滤、排序、分页、汇总 等。在语义模型中,描述器表述了对语义提供者抽取的数据的加工处理过程。更多细节参见章节。n 首选项语义模型中的首选项包括三类数据:参数、宏变量、配置项。下面将分别介绍:u

5、 参数参数是模型中代表动态信息的元素,用于响应用户的输入。参数给用户提供了控制模型执行过程的机会。更多细节参见章节。u 宏变量宏变量与参数类似,区别是,参数在模型执行时需要用户输入值;而宏变量不需要与用户交互,系统后台会根据上下文计算该值。更多细节参见章节。u 配置项配置项用于控制语义模型的执行方式。2.2.2 执行流程语义模型的执行流程如下图所示:语义模型执行过程可分为以下步骤:n 第一步:语义模型脚本化语义模型中的对象结构将转变为字符串形式的语义脚本。n 第二步:脚本对象化通过脚本引擎把语义脚本解析为脚本模型,即把字符串形式的脚本 对象化。n 第三步:脚本模型翻译为SQL基于脚本模型,处理

6、其中的语义函数,把脚本模型翻译为标准SQL语句。运行态描述器会在这一步被处理。n 第四步:执行sql,把结果集封装为DataSet,返回DataSet。由于运行态描述器的存在,每次执行语义模型时获取的最终sql都是不同的,但是,语义模型本身对应的脚本模型是相同的。基于性能考虑,我们可以把语义模型对应的脚本模型缓存起来。这样一来,只有第一次执行语义模型时,我们需要完整执行上述四个步骤,接下来的每次执行,我们只需取得该缓存的脚本模型,再做第三、四步的处理即可。2.2.3 数据形态语义模型提供的数据可以以两种形态存在:数据集DataSet、数据表DbTable。从数据流转的角度来说,语义模型代表了一

7、种取数管道,数据可以从管道中抽取出来。数据集DataSet代表了内存中的数据,或者说,数据在内存中以数据集DataSet为载体。数据表DbTable代表了数据库中的数据,或者说,数据在数据库中以数据表DbTable为载体。语义模型、数据集、数据表 这三者之间还存在互相转换的关系,下图形象的展示了这点:数据从语义模型这种数据管道中加载到内存,就以数据集的形式存在;如果把数据集中的当前数据持久化到数据库中,数据就以数据表的形式存在;把数据从数据库中加载到内存中,就完成了数据表到数据集的转换;数据表可以以语义提供者的形式构成语义模型,完成数据从数据表到语义模型的流转;并且,语义模型经由视图化执行,最

8、终的结果集将以数据表的形式呈现。数据在不同形态间流转时,改变的是数据载体,不变的数据本身的结构,即元数据。2.3 语义提供者语义提供者,表述了一类取数方式,或者说如何提供数据的方式。在语义模型中,语义提供者负责把一类业务取数过程以语义脚本的形式描述出来。2.3.1 接口接口方法方法说明String getCode()获取编码。该编码用于标示语义提供者MetaData getMetaData()获取元数据。元数据中包含了该提供者提供的数据的描述信息,例如:字段名、字段数据类型、字段精度 等String getTitle()获取标题,即该提供者的显示名称MetaData provideMetaDa

9、ta(SmartContext context)构造元数据。入参参数context是提供者构造元数据时的执行环境。此方法通常在设计态使用,用于重新构造元数据。String provideScript(SmartContext context)构造语义脚本。入参参数context是提供者构造脚本时的执行环境。此方法通常在运行态使用,用于把业务取数过程转换为语义脚本。void setCode(String code)设置编码void setMetaData(MetaData metaData)设置元数据。此方法通常在设计态使用,一般是先调用provideMetaData(context)构造元数据

10、,然后调用此方法来把元数据保存在语义提供者。void setTitle(String title)设置标题,即显示名语义提供者包括NC元数据、DW元数据、以及语义脚本和业务代码扩展提供者(提供总帐、HR、供应链、报表等业务数据扩展)。其整个体系结构可由下图表示:其中,Provider是语义提供者的接口;SemanticProvider是基础扩展抽象类,对能把取数过程以脚本形式描述的语义提供者可继承此类;SemanticDataProvider是语义数据扩展抽象类,对不能以脚本形式描述取数过程,只能提供二维数据的提供者,可继承此类。SemanticSqlProvider适用于提供者在运行时根据执

11、行环境context返回不同取数sql,其与SqlProvider的区别在于:u SqlProvider的sql结构在定义态已经确定;u SemanticSqlProvider是在运行时,经过一系列业务处理,返回最终取数sql。上述图中,蓝色代表具体实现类。通过以上的介绍我们可以得知,Provider定义了语义提供者的接口规范,SemanticProvider、SemanticDataProvider、SemanticSqlProvider则是我们具体实现提供者时要继承的抽象类。现对这四个类的主要接口做重点介绍。n Provider接口方法方法说明String getCode()获取编码。该编

12、码用于标示语义提供者MetaData getMetaData()获取元数据。元数据中包含了该提供者提供的数据的描述信息,例如:字段名、字段数据类型、字段精度 等String getTitle()获取标题,即该提供者的显示名称MetaData provideMetaData(SmartContext context)构造元数据。入参参数context是提供者构造元数据时的执行环境。此方法通常在设计态使用,用于重新构造元数据。String provideScript(SmartContext context)构造语义脚本。入参参数context是提供者构造脚本时的执行环境。此方法通常在运行态使用,

13、用于把业务取数过程转换为语义脚本。void setCode(String code)设置编码void setMetaData(MetaData metaData)设置元数据。此方法通常在设计态使用,一般是先调用provideMetaData(context)构造元数据,然后调用此方法来把元数据保存在语义提供者。void setTitle(String title)设置标题,即显示名n SemanticProvider接口方法方法说明MetaData provideMetaData(SmartContext context)同Provider对于继承此类的提供者,必须实现此方法。String p

14、rovideScript(SmartContext context)同Provider对于继承此类的提供者,必须实现此方法。n SemanticDataProvider接口方法方法说明DataSet provideData(SmartContext context)提供二维数据。入参context提供执行环境;返回结果数据以DataSet形式展现。DataSet主要包含两部分:二维数据数组、元数据。对于继承此类的提供者,必须实现此方法。n SemanticSqlProvider接口方法方法说明String provideSql (SmartContext context)提供sql。入参con

15、text提供执行环境;返回结果数据以sql形式展现。对于继承此类的提供者,必须实现此方法。2.3.2 扩展前面介绍了语义提供者的整个体系结构,现在我们拿一个具体例子来讲解如何实现一个语义提供者。我们以比较简单的“数据表”这类取数方式来做示例。扩展语义提供者可分为以下三步: 实现语义提供者类由前文介绍,我们知道实现一个提供者有三种方式:n 继承SemanticProvider:能把取数过程以脚本形式描述的语义提供者可继承此类我们现以数据表提供者为例来讲解如何以此种方式实现语义提供者。数据表提供者对应的实现类为:DbTableProvider,该类继承于SemanticProvide

16、r,实现了接口provideMetaData(SmartContext context) , provideScript(SmartContext context)。数据表提供者,是把NC元数据底层数据模型中的一张表作为操作对象,从中抽取数据。其在语义模型中的操作是这样的:在上级“模块”目录上选中模块“平台”,展开后在子节点上选中“sm_user”这张表。在数据表提供者DbTableProvider中,我们只需要存储一条信息:表名。这些信息可以看做取数过程的业务描述,接下来我们做的就是把这些业务描述转换为以语义模型中的概念来进行描述。实现provideMetaData(SmartContext

17、 context)接口:有了表名信息,我们就可以把其列信息拿到,列Column解析为字段Field,每列对应一个字段,多个列对应的多个字段就组合为元数据MetaData。实现provideScript(SmartContext context)接口:数据表提供者比较简单,直接返回表名即可。到此,我们的数据表语义提供者类就实现完毕。n 继承SemanticDataProvider:不能以脚本形式描述取数过程,只能提供二维数据的提供者,可继承此类例如,供应链中有些查询并不能直接通过一条sql就能查出,中间可能经过一系列复杂的代码运算逻辑来构造这个结果数据,这时我们就可以继承SemanticData

18、Provider来实现语义提供者。继承此类只需要实现provideData(SmartContext context)接口:在该方法中,我们编写运算逻辑,构造最终的结果数据DataSet,返回之即可。在此我们有必要介绍下DataSet的结构。DataSet主要包含两部分:元数据MetaData,数据容器Object(即二维数组)。Object即是最终的结果数据,MetaData是对数据的描述信息,包含对应字段信息:字段名、数据类型、数据精度 等。n 继承SemanticSqlProvider:应用方式与SemanticDataProvider类似,不同在于,SemanticDataProvid

19、er最终返回二维数据,而SemanticSqlProvider返回sql语句。 实现语义提供者设计向导类有了语义提供者类,我们还需要一个设计器来设计语义提供者。每个设计器都需要实现接口IProviderDesignWizard。该接口只有一个方法:/* * param parent 父窗口。为ProviderStepPanel,藉此可获得SmartModelWizardShareObject(向导模型,包含向导共享数据) * param provider 待修改的语义提供者 * param context 上下文 * return 设计完成后的语义提供者 */public Pro

20、vider design(Container parent, Provider provider, SmartContext context);当设计语义提供者时,会调用此方法,调用完成返回提供者实例。数据表提供者设计向导类为DbTableProviderDesigner。其界面效果如下图所示:其具体处理流程为:调用design()方法,打开一如上图所示对话框,用户选中表后,点“确定”按钮,构造一个DbTableProvider实例,返回之。 配置文件注册编写完语义提供者类、设计向导类,我们还需在配置文件中注册该种语义提供者,以便在语义模型能加载到。所谓注册,即在配置文件中增加相

21、应配置项。为方便各模块扩展语义提供者,在开发环境下,配置文件存放位置为各模块resources下的smart目录:$NC_Project/resources/smart/smart_$模块号.xml。如总帐项目扩展配置文件路径为:gl/resources/smart/smart_gl.xml 这样在安装盘中,各模块扩的扩展配置文件将都在NC_HOME/resources/smart/目录中。具体配置信息如下。每个语义提供者注册项包含五种属性:名称、图标路径、类型、语义提供者类名、设计向导类名。其格式为:<nc.vo.smart.config.ProviderConfig> <

22、title></title> <icon></icon><type></type> <providerClzName></providerClzName> <designWizardClzName></designWizardClzName></nc.vo.smart.config.ProviderConfig> 其中,type类型是用于区分预置的语义提供者和用户自定义的语义提供者,其有效值有: preset、custom。分别对应系统预置、用户自定义两种类别。一般用户

23、在自己扩展实现自定义的语义提供者时,可以直接去掉type项,或者把该项设置为custom。以数据表提供者举例,其配置项为: <nc.vo.smart.config.ProviderConfig> <title>数据表</title> <icon>./dbtableprovider.gif</icon><type>preset</type> <providerClzName> vider.impl.DbTableProvider</providerClzName&

24、gt;<designWizardClzName>vider.DbTableProviderDesigner</designWizardClzName></nc.vo.smart.config.ProviderConfig> 至此,我们的语义提供者就全部实现了,在语义模型的设计向导中就会支持该类型的语义提供者。2.4 函数2.4.1 函数解析语义脚本支持sql语法和自定义函数的混合编写。系统默认函数有smart(), nc_metadata(), qdi_metadata(), parameter(),m

25、acro(),后续会扩展字符串函数、时间函数等。NC公式统一走宏变量定义。2.4.2 函数扩展语义模型支持对其函数进行扩展,用户可以根绝业务需求添加自定义函数。具体步骤如下:n 根据函数接口(ISemanticCommand)实现自定义函数。类图示意如下:接口中API如下:public interface ISemanticCommand /* * 执行计算 * param context 上下文环境 * param params 参数值 * return 执行结果 */Object run(SmartContext context, Object params);/* * 函数名称 * re

26、turn */String getFunctionName();/* * 函数描述 */String getFunctionDesc();/* * 函数参数类型 * 为null表示不作约束 */Class getParameterTypes();/* * 函数设置向导类 * 为null标识无设置向导 * return see IFunctionDesignWizard */String getFunctionDesignWizardClz(); n 在函数扩展配置文件进行配置。默认配置文件路径为$NC_Home/resources/smart/function_default.xml。为方便各

27、模块扩展函数,在开发环境下,配置文件存放位置为各模块resources下的smart目录:$NC_Project/resources/smart/function_$模块号.xml。如总帐项目扩展配置文件路径为:gl/resources/smart/function_gl.xml 这样在安装盘中,各模块的扩展配置文件将都在NC_HOME/resources/smart/目录中。配置文件示例如下:配置文件中是根据驱动名称进行组织的,驱动总共分为两类SmartFunctionDriver和DBFunctionDriver。之所以对驱动进行区分是因为在不同的功能点,加载的函数驱动可能不同。在实际配置

28、过程中,用户可以根据自己的需要把自定义的函数类全路径名放在已有的驱动定义或新增加自定的驱动定义中,即可完成函数的扩展。2.5 参数参数是模型中代表动态信息的元素,用于响应用户的输入。在模型的执行过程中,可以根据参数值的不同来影响结果数据。参数常用于对筛选条件的设置上。示意图如下:2.5.1 参数定义参数是与具体的模型绑定的,在每个模型的设计过程中都可以对参数进行定义。参数的类型分为:字符,数值,枚举和参照。当类型为枚举时,枚举项为用“”分隔的枚举值,或者是一个单字段的查询SQL;当类型为参照时,枚举项为基础参照名,或者是用尖括号括起的自定义参照的类名。在定义的时候需要注意,参数的编码要保证互不

29、相同。2.5.2 参数引用参数引用主要在模型设计中的筛选描述器部分,在筛选描述器的条目中,值类型选择为参数时候,则会在值字段的下拉列表中列出相应的参数。另外在模型设计的“Smart脚本”中,我们提供了“parameter”函数,在函数列表中双击,则会弹出参数选择框。范例请参考本文档第五章一节。2.5.3 参数设置运行态要求用户首先对参数进行设置,当报表引用了多个语义模型时,参数将通过多页签设置,每个页签代表一个模型。另外需要注意的是,模型在运行态时会对参数是否被引用进行检查,最终的设置界面上只会显示被引用的参数。2.5.4 参照依赖n 设计态增加“参照依赖”列,参照型的参数可以使用参照依赖,其

30、他类型即使设置也不会起作用n “参照依赖”中支持parameter,macro 函数;例如:n sm_user.cuid=parameter('param1') and pk_org=macro('m1')n 如果参照是树表形式的,并且需要分别对树和表进行设置,则输入框中输入的条件用“;”分割。n 定义态的默认值设置支持参照依赖,即参照显示的值会根据依赖的条件过滤。具体设置:2.5.5 自定义参照参照类型参数支持对参照编辑的自定义设置。实现方法:在设计态,属性列编辑框中通过注册自定义编辑器的方式实现,方式为“<类路径>”。相关的具体规则如下:编辑界面

31、基类:nc.ui.pub.smart.designer.preference.CustomParamDlg ,自定义编辑器必须实现以下方法:/* * 利用参数信息构建UI * param info 参数信息 * throws Exception */public abstract void buildUI(CustomParamInfo info) throws Exception;/* * 获取参数编辑的返回值&#

32、160;* return * throws Exception */public abstract String getParamValue() throws Exception;其中buildUI方法传递的参数CustomParamInfo相关说明:/* * 参照当前值 */private String currentValue;/* * 当前数据源 */private String dsNam

33、e;/* * 当前参数的哈希表 */private HashMap<String, Parameter> paramMap;使用说明,见下图:2.6 宏变量宏变量引申自程序设计中的宏,其表达式会被替换为字符串,并在最终的查询语句中可以被完全替换。宏变量根据作用域分为全局宏变量和模型宏变量。故名思意,全局宏变量用于全局共享,在任何语义模型中都可以直接引用。模型宏变量与具体的语义模型相关,其只在当前模型中其作用。全局宏变量中包含多个预置宏变量,如LoginDate,LoginUser等,方便共享。宏变量其定义与参数类似,不同之

34、处在于其类型有两种选择“公式”和“SQL语句”。公式只是其表达式支持NC公式的编辑;SQL语句是指一般的SQL语句,但默认情况下取值只能取第一行第一列的值。宏变量示意图如下:宏变量的引用与参数相同,分别在筛选描述器和Smart脚本的公式(macro)中可以对其引用。另外与参数区别的是,由于宏变量都是固定的值,因此不需要与用户进行交互,所有在浏览态没有相应的设置界面。2.7 描述器Descriptor是指对数据操作的描述,例如:过滤、排序、分页、汇总 等。现支持以下几种描述器:名称对应类用途结构对应界面设计类汇总描述器AggrDescriptor对数据做汇总处理,相当于sql中的group by

35、包含汇总条件、汇总字段两部分无数据唯一描述符DistinctDescriptor清除数据中的重复行,相当于sql中的distinct不持有属性,以其存在与否来判断是否做distinct处理无过滤描述器FilterDescriptor对数据做过滤处理,相当于sql中的where包含树形结构的过滤条件FilterDescPanel表连接描述器JoinDescriptor表示表之间的连接关系,相当于sql中的join。只用于设计态包含连接条件JoinStepPanel限制列描述器LimitColumnDescriptor只提供选定的那些列(以字段名指定)的数据包含指定的列名数组无分页描述器Pagin

36、alDescriptor对数据做数据库端分页处理包含页大小、页数无限制行描述器LimitRowDescriptor取最前 或 最后 多少行数据。属于分页的一种,一般用作top分析包含 最前 或 最后 标示,及数据行数无排序描述器SortDescriptor对数据做排序处理包含排序字段、排列顺序SortDescPanel描述器可在 设计态、运行态 两处使用。在设计语义模型时,我们通过设计向导能构造设计态的描述器,保存于语义模型中;在执行语义模型时,我们可以另外自己构造运行态的描述器,对语义模型进行再处理。对于语义模型的使用者,一般接触到的是运行态的描述器,现对这部分进行详细讲解。构造描述器:对于

37、提供了设计界面的描述器,可以调用界面类来构造描述器;也可在后台直接构造描述器。调用provide接口:把上述描述器封装到描述器数组Descriptor descs,然后传入语义模型相应的provide接口方法中:DataSet provideData(IContext context, Descriptor descs) 获得执行结果数据集;DbTable provideView(IContext context, Descriptor descs) 执行结果保存在视图上。String provideSQL(IContext context, Descriptor descs) 获得最终执行s

38、ql;Int provideCount(IContext context, Descriptor descs) 获取总行数; 上述方法中的Descriptor descs 即是运行态描述器,藉此提供了对语义模型进行再处理的可能。2.8 数据加工2.8.1 概念 数据加工是语义模型提供的一类取数方式,支持用户使用java代码来定义一段取数逻辑。2.8.2 定位考虑到在现实应用中业务逻辑的复杂性,单纯依赖sql语句,用户并不是总能得到想要的结果集,因此提供了在语义模型嵌入Java代码的功能,用于单纯sql处理不了的场景。由于数据加工是在从数据库中取出结果集后在内存中进行操作,考虑到资源和

39、效率问题,我们建议只有在SQL解决不了的数据处理要求,才使用数据加工实现。由于在数据加工中提供的通过Java代码实现相关数据处理的功能,理论上讲其可以满足任意相关的业务逻辑需求,复杂的业务逻辑算法需要在实际应用开发中按照不同情况和场景灵活使用。2.8.3 执行原理在使用时,数据加工分为两个步骤:n 第一步使用java代码定义取数逻辑,最终返回sql语句 或 结果集DataSet。基于性能考虑,推荐返回值为sql;n 第二步定义元数据,即对上述代码返回的数据的描述,包括:有哪几列、每一列的数据类型、长度、精度等;执行时,上述定义的java代码会在后台被调用,拿到返回的sql语句或结果集DataS

40、et(DataSet需要持久化到数据库中的临时表中),然后和其他逻辑表(provider)进行复合取数。2.8.4 使用使用方式如下: 弹出设计界面如下: 在上述编辑器中编辑java代码,左边提供了辅助代码片段生成向导。 步骤“元数据”,是要求代码设计者对代码执行完后的结果数据进行描述,即返回几列数据,每列的列名、数据类型等信息。 (该步骤的改进方案为:元数据自动生成,通过预执行一遍代码来实现。不过手工设置避免不了,因为大部分代码在设计态很难成功执行)2.8.5 常见问题n 数据加工java代码中,调用语义模型的类时,直接使用类名,而对业务部门的类,需要使用全路径

41、名。n java代码中封装DataSet时,需要设置元数据MetaData(具体参见相关类)。n java代码中通过调用代码setDataSet(DataSet)设置最终需要返回的结果数据集DataSet,通过调用代码setResultSQL(sql)设置sql返回值。n 这部分代码是在后台调用,切忌调用UI类n java代码最终生成的类继承于nc.pub.smart.model.code.CodeProcessor ,实现其process() 方法n java代码生成的类放在 NC_HomemodulesbapubMETA-INFvarclasses 下2.9 物化策略我们可以对一个语义模型

42、设置定时策略,定时把语义模型执行后的数据持久化到指定数据源上指定的数据表中。通过提供这种功能,我们就能把一些执行效率较低的语义模型预先调度执行,到真正取数时,直接从物化表中取数,减少执行等待过程。物化策略使用有其局限性,只有在只使用语义模型本身的字段时,才会从物化表直接取数;如果需要取语义模型本身未定义的字段(例如语义字段等),则会把语义模型从头执行一遍,不再使用物化表。2.10 复合语义模型复合语义模型,指的是,我们在定义语义模型时,可以引用已经存在的语义模型。对这种引用了其他语义模型的语义模型,我们称之为复合语义模型。下图形象的阐释了复合语义模型的嵌套结构。应用复合语义模型能够达到数据集成

43、的效果。在上图中,我们注意到,每个语义模型均可以定义自己的执行数据源,也就是说,复合语义模型引用的原子语义模型的执行数据源可以互不相同,从而,我们就能支持多数据源取数功能。数据从不同数据源抽取出来,然后以语义模型这种统一的形式对外提供数据,这样就达到了数据集成的效果。创建复合语义模型有两种方式:设计向导、语义脚本。下面我们将针对这两种方式做分别介绍。2.10.1 设计向导方式在语义模型设计向导中,选择“选择表”步骤,单击右边的“语义模型”按钮,弹出语义模型参照对话框,选中语义模型,单击“确定”按钮。这样就可以把选中的语义模型引用到当前设计的语义模型中。这时,原子语义模型是以语义提供者的形式存在

44、于复合语义模型中。2.10.2 语义脚本方式我们可以在语义脚本中通过使用语义函数smart()来引用语义模型(smart() 的语法规则参见附录)。在语义模型设计向导中,选择“选择表”步骤,在右边单击“语义脚本”按钮,弹出“语义脚本编辑器”对话框,这时,我们可以以语义脚本的形式来创建语义模型。在“语义函数”页签选中“smart”函数,双击,弹出语义模型参照对话框,选中语义模型,单击“确定”按钮。这时,在脚本编辑框中会自动添加一段脚本“smart(user)”,当然,如果我们事先知道被引用的语义模型的编码,我们也可以在文本框中直接编辑脚本。2.11 语义上下文语义上下文SmartContext提

45、供了语义模型运行时环境,包括了如下有用信息:例如参数值、宏变量值、当前模型、执行数据源等。相关方法列表如下:方法名称参数功能SmartModel getBuildingSmartModel()获得当前正在build的模型。对复合模型,不一定是当前正在执行的模型String getDsName4Exec()获取执行数据源Object getMacroValue(String macro)macro:宏变量编码获得宏变量的值Object getParameterValue(String paramCode)paramCode:参数编码获得参数的值2.12 脚本规则脚本规则是指针对语义脚本的处理逻辑

46、,具体处理过程如下图所示:脚本规则支持扩展,业务部门可以通过扩展规则、直接操作内存脚本模型,藉此实现特定功能,例如:复杂权限控制等。规则的扩展机制如下:2.12.1 实现规则类规则的统一接口为:nc.pub.smart.script.engine.rule.IScriptRule主要接口方法为:/* * 执行规则*/public Select exec() throws Exception;在该接口中,我们可以操作传过来的脚本模型Select各部分,包括select字段列表、from、where、orderBy、groupBy等。修改完脚本模型,把其返回即可。我们可以继承AbsScriptRu

47、le来实现自定义的规则。2.12.2 配置文件注册编写完规则实现类,我们还需在配置文件中注册该规则,以便在语义模型能加载到。所谓注册,即在配置文件中增加相应配置项。为方便各模块扩展规则,在开发环境下,配置文件存放位置为各模块resources下的smart目录:$NC_Project/resources/smart/smart_rule_$模块号.xml。如总帐项目扩展配置文件路径为:gl/resources/smart/smart_rule_gl.xml 这样在安装盘中,各模块扩的扩展配置文件将都在NC_HOME/resources/smart/目录中。具体配置信息如下:每个规则注册项包含三

48、种属性:显示名、规则class全路径名、优先级。其格式为:<nc.pub.smart.script.engine.rule.config.ScriptRuleConfig><items><nc.pub.smart.script.engine.rule.config.ScriptRuleConfigItem><displayName></displayName><ruleClz></ruleClz><priority></priority></nc.pub.smart.script.

49、engine.rule.config.ScriptRuleConfigItem></items></nc.pub.smart.script.engine.rule.config.ScriptRuleConfig> 其中,priority优先级是用于确定各规则的调用顺序。至此,我们的规则扩展就全部实现了,在语义模型的设计向导中就会支持该规则。2.12.3 操作使用打开 语义模型设计向导-最后一步“选项”-配置项,“业务规则”配置项, 设置值时弹出规则选择对话框:勾选所需规则,支持多选。这些选中规则即可在脚本引擎解析时调用,来对语义脚本进行处理。第三章 语义

50、模型管理本章内容概要:l 对象管理l 环境配置l 导入导出语义模型的管理一般包括:语义模型目录的管理、语义模型的管理、语义模型的相关配置管理、全局变量的配置、监控、查询、权限管理等功能点。语义模型目录的管理:目录的新增、修改、删除、刷新等功能点。语义模型的管理:语义模型的新增、修改、删除、刷新和语义模型的设计、执行等功能点。语义模型的相关配置管理:主要是对数据源的管理,设置默认定义数据源,执行数据源全局变量的配置:预置宏变量,在整个系统中是全局的。监控:语义模型执行取数操作的性能监控功能,方便的定位效率瓶颈。查询:权限管理:语义模型管理的功能权限、数据权限、资源权限和NC权限规则一致以上介绍了

51、语义模型管理都有那些功能点。由面到点,下面针对每个功能点的用法和功能做一下详细描述。3.1 对象管理语义模型的管理调度功能由主界面完成,主界面左侧为语义模型目录,右侧为选中目录下的语义模型列表和语义模型属性卡片,如下图:3.1.1 目录管理增加/删除/修改:在根节点或目录节点之下可以增加目录,删除目录时会删除目录下的所有对象。目录的可修改属性为目录名称。同一目录下的目录和对象不能重名。3.1.2 语义模型管理增加/删除/修改:在根节点或目录节点之下可以增加语义模型。属性为编码、名称和备注其中编码一经使用,就不再建议作任何修改,因为此编码可能被其它对象引用。请注意语义模型的唯一标识是编码而不是显

52、示名称。3.1.3 监控语义模型执行取数操作的性能监控功能,方便的定位效率瓶颈。主要功能点:后台集群性能日志、客户端性能日志、执行队列管理、性能监控、集群调度管理、元数据管理、临时表管理。3.1.4 权限语义模型管理的功能权限、数据权限、资源权限和NC权限规则一致。具体可以查看NC权限相关文档,此处不再详细说明。3.1.5 全局变量配置预置宏变量,在整个系统中是全局的。界面效果如下:3.2 环境配置主要配置默认定义数据源,并从有效数据源中选择执行数据源。进入“数据源配置”模块,打开如下界面。此配置存放语义模型运行所需要的环境变量,这些变量被存储在后台datasource.xml中,位于NC_H

53、ome/resources/smart/目录下,由于本文下面的章节中还有需要涉及到环境变量设置的地方,所以这里只提及数据源环境变量的设置。n 有效数据源启动中间件时的所有能够连接的合法数据源,实际上也就是prop.xml文件中的所有定义过并且能够正常连接的数据源。n 执行数据源语义模型所能够引用的执行数据源列表,语义模型管理中所有的语义模型的取数数据源范围就在这个列表中定义。请注意一个查询执行数据源必须是一个有效数据源。n 默认定义数据源语义模型定义在哪个数据源上。各种数据源模型图如图所示:n 多数据源运作机制:语义模型的执行支持这样的模式NC业务在数据源A下运行,语义模型的定义放在数据源B,

54、通过语义模型执行的查询可以到数据源C去执行。n 各种数据源的功能区分:u 业务数据源(上面说的A)通常是指当前登陆账套的数据源,是NC运行所需要的业务数据源。u 定义数据源(上面说的B)是指语义模型自身的系统表所在的数据源,执行切换功能后,主界面上的对象树的内容会作相应改变。请注意语义模型的系统表可以和当前的业务数据源不是同一个数据源,例如当前登陆账套是Account1,数据源是datasource1,而语义模型的系统表可以不在该数据源下,而在另一个数据源datasource2下,datasource2可能是账套Account2的数据源,也可能是任何其他的数据源。但是前提是该数据源中必须含有语

55、义自身的系统表。u 执行数据源(上面所说到的C)是指该查询定义取数的数据源,我们知道语义模型定义设计的最终目的还是去特定的数据源查取用户所需的数据,执行数据源就是存储这些用户所需数据的数据源,语义模型本身的系统表所在数据源可以跟这个取数数据源不同,也就是说定义数据源和查询数据源可以分离。3.3 导入导出1233.3.1 导出逻辑 导出文件的规则导出文件中的数据结构是 目录类(目录定义子目录集子模型集),目前以ImportDirVO<Tdir extends SuperVO,Tdef extends SuperVO>来代替,语义模型的分类为SmartDirVO,定义为SmartDefVO。为了用于扩展需要,目录类的子模型集用ImportDefVO<T extends SuperVO>来代替而非直接SmartDefVO之类。由于语义模型导出有点特殊,在模型导出的时候,每个模型里还可能会单独存一个物化策略TimeSettingVO,因此在ImportDefVO<T>中增加一个Values来扩展一些特殊需要。这样导出容器结构就差不多了。 存储结构如下:<ImportDirVO><Smar

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论