用友NC语义模型红皮书-2011-07

用友软件股份有限公司

高级分析平台语义模型红皮书

版本：V6.0.0.20100924

目录

一、前言 (3)

1.概念 (3)

2.定位 (3)

二、结构 (3)

1.应用模型 (3)

2.语义模型 (4)

a) 定义形态 (4)

b) 执行流程 (6)

c) 数据形态 (7)

3.语义提供者 (7)

a) 接口 (7)

b) 扩展 (10)

4.函数 (14)

a) 函数解析 (14)

b) 函数扩展 (14)

5.参数 (17)

a) 参数定义 (17)

b) 参数引用 (17)

c) 参数设置 (18)

6.宏变量 (19)

7.描述器 (20)

8.数据加工 (22)

9.物化策略 (24)

10.复合语义模型 (25)

11.语义上下文 (29)

三、语义模型的管理 (32)

1.对象管理 (32)

2.环境配置 (35)

四、功能扩展 (36)

1.扩展语义提供者 (37)

2.扩展业务函数 (37)

3.使用数据加工 (37)

4.自定义执行策略 (37)

五、附录 (38)

1.入门 (38)

2.语义模型API (43)

3.语义函数 (45)

4.其他函数 (45)

5.脚本引擎 (47)

6.针对查询引擎的改进 (47)

一、前言

1.概念

SMART，即Semantic Modeling for Analysis Report Toolkit, 分析报表语义建模工具。

2.定位

二、结构

1.应用模型

上图为语义模型应用结构图。语义模型通过语义提供者，可以将多个数据源的数据进行整合。

2.语义模型

a)定义形态

下图展示了语义模型的内部结构，

a)元数据

元数据是指描述数据的数据，是为了外界使用数据而对数据本身含义的阐述。拿我们最常见的二维数据（行列结构）举例来说，如果只有这些行列结构的数据，对我们来说这将毫无意义。因为我们无法知道哪一列的数据代表什么含义，无法知道如何操作这些数据，更别提由这些数据分析出有用的信息。反过来，如果针对这些数据指定了元数据，我们就可以了解哪一列代表的业务含义，并且知道该列的数据类型、长度、精度等。这样，我们就能对这些数据进行加工处理，分析提取出有价值的信息。

同理，语义模型的元数据是对执行语义模型后获取的二维数据的描述。元数据针对结果数据的每一列都提供了下列信息：数据类型、字段显示名、字段名、备注、长度、精度等。有了这些信息，我们就能知道在业务应用中该如何使用语义模型。

b)语义提供者

语义提供者，表述了一类取数方式，或者说如何提供数据的方式。在语义模型中，语义提供者负责把一类业务取数过程以语义脚本的形式描述出来。

为了能更好的理解这个概念，我们可以打这样一个比方：NC元数据、数据仓库、报表数据、总账数据等这些可提供数据的对象好比“数据水源”，而语义提供者好比“水泵”，语义模型好比“抽水机”。每种“数据水源”只支持特定的“水泵”

来抽取数据。我们有了一种语义提供者“水泵”，就能抽取其对应的“数据水源”

里的数据。语义模型中能指定多个语义提供者，就相当于“抽水机”挂接了多个“水泵”，我们就能从多个不同类型的“数据水源”来抽取数据。

语义提供者负责抽取数据，同时对外提供元数据来描述这些数据。语义提供者的元数据一般是在语义模型内部使用。

更多细节以及语义提供者的扩展说明参见章节《语义提供者》。

c)描述器

描述器是指对数据操作的描述，例如：过滤、排序、分页、汇总等。在语义模型中，描述器表述了对语义提供者抽取的数据的加工处理过程。

更多细节参见章节《描述器》。

d)首选项

语义模型中的首选项包括三类数据：参数、宏变量、配置项。下面将分别介绍：

i.参数

参数是模型中代表动态信息的元素,用于响应用户的输入。参数给用户提供了

控制模型执行过程的机会。

更多细节参见章节《参数》。

ii.宏变量

宏变量与参数类似，区别是，参数在模型执行时需要用户输入值；而宏变量不

需要与用户交互，系统后台会根据上下文计算该值。

更多细节参见章节《宏变量》。

iii.配置项

配置项用于控制语义模型的执行方式。

b)执行流程

语义模型的执行流程如下图所示：

语义提供者:

NC元数据

QDI元数据

业务数据

语义模型

...

语义函数:

nc_metadata()

smart()

report()

parameter()

macro()

...

语义模型执行过程可分为以下步骤：

第一步：语义模型脚本化

语义模型中的对象结构将转变为字符串形式的语义脚本。

第二步：脚本对象化

通过脚本引擎把语义脚本解析为脚本模型，即把字符串形式的脚本对象化。

第三步：脚本模型翻译为SQL

基于脚本模型，处理其中的语义函数，把脚本模型翻译为标准SQL语句。

运行态描述器会在这一步被处理。

第四步：执行sql，把结果集封装为DataSet，返回DataSet。

由于运行态描述器的存在，每次执行语义模型时获取的最终sql都是不同的，但是，语义模型本身对应的脚本模型是相同的。基于性能考虑，我们可以把语义模型对应的脚本模型缓存起来。这样一来，只有第一次执行语义模型时，我们需要完整执行上述四个步骤，接下来的每次执行，我们只需取得该缓存的脚本模型，再做第三、四步的处理即可。