实施例一
本发明实施例提供了一种生成数据库的对象定义的方法。如图1所示,该方法包括步骤如下:
步骤S10,获取用户预先设定的数据库的数据结构信息,数据结构信息包括数据库的根目录。
这里需要说明的是,在本文中出现的数据库均可以为Analysis Service数据库即分析服务数据库。
具体的,由于不同用户可能将上述Analysis Service数据库安装在不同的根目录下,因此在本方案中,可以先获取由用户设定或提供的已安装的Analysis Service数据库的根目录,在获取到上述根目录后,Analysis Service数据库的数据结构就可以确定了。
步骤S12,遍历根目录下的数据库对象文件,获取数据库对象文件中的多个数据库对象组的组信息,其中,上述多个数据库对象组的组信息包括:多个对象组名称以及每个数据库对象组中的数据库对象的名称。
具体的,上述根目录下的数据库对象文件中可以包含多个数据库对象组,在本方案中,可以通过遍历的方法来获取上述多个数据库对象组的组信息,可选的,在一种可选的实施例中,数据库对象文件中的一个数据库对象组的组信息如表1所示。表1中所示的是同一个数据库对象组的具体的两个数据库对象的信息。
表1:
组名称 |
数据库对象名称 |
Ad |
AdSource |
Ad |
AdGroup |
步骤S14,根据数据库对象组的组信息生成目标对象文件,目标对象文件包括Analysis Service数据库的对象定义。
具体的,在本方案中,可以根据上述获取的组信息生成目标对象文件,上述目标对象文件中可以为xml文件、代码文件、资源文件,在上述三个文件中只保存数据库的对象定义,该三个文件中的对象定义用于被解析,进而生成查询语句以对数据库发起查询。
本实施例首先通过在用户安装Analysis Service数据库的根目录中的存储数据结构的文件中读取数据库对象的定义,再根据上述数据库的定义自动生成目标对象文件中的对象定义,解决了现有技术中将Analysis Service数据库中大量的对象定义手动的添加到只保存数据库对象定义的目标文件中导致容易出错的问题,实现了自动生成AnalysisService数据库的对象定义的方法,这里需要说明的是,如果Analysis Service数据库中的数据结构发生了变化,***会自动生成变化之后的对象定义,无需人工修改。
在一种可选的实施例中,上述数据库对象文件中的多个数据库对象组包括:维度组、指标组,其中,维度组中包含多个维度称,指标组包含多个指标。
具体的,上述数据库对象文件中可以包括维度的定义和指标的定义。而在本方案中则根据数据库对象文件中的维度的定义和指标的定义生成目标文件中的新的维度的定义和新的目标指标的定义,上述数据库对象文件中的维度的定义可以体现为维度组和维度组中每个维度的信息,指标的定义可以体现为指标组和指标组中每个指标的信息,关于维度组和维度组中每个维度的信息如表2所示,关于指标组和指标组中每个指的的信息如表3所示,表2示出的为同一维度组的具体两个不同的维度的信息,表3示出的为同一指标组的具体的两个不同的指标的信息。
表2:
维度组名称 |
维度名称 |
Ad |
AdSource |
Ad |
AdGroup |
表3:
指标组名称 |
指标名称 |
Session |
Impressions |
Session |
Visits |
这里需要说明的是,由于上述数据库的对象文件包含着维度的定义和指标的定义,因此在步骤S12中,遍历根目录下的数据库对象文件,获取数据库对象文件中的多个数据库对象组的组信息的步骤可以包括:
步骤S121,遍历根目录下用于定义维度组的第一文件,读取第一文件中的每个维度组的名称以及维度组中的每个维度的名称。
具体的,在本方案中,上述第一文件可以是上述安装Analysis Service数据库的根目录下的以.dim.xml结尾的文件,该第一文件中为对数据库中的维度的定义。如下是Ad.dim.xml文件的一个例子,需要说明的是,该例子删除了无关的元素、属性,删除了大多数Analysis Service数据库的维度对象,只保留了一部分Analysis Service数据库的维度对象:
这里需要说明的是,在本方案中,可以在上述xml文件中获取Dimension元素下Name元素的值Ad以及Attribute元素下的Name元素的值AdSource、AdGroup,这里还需要说明的是,在上述xml文件中获取的为上述第一文件中的每个维度组的名称,在上述xml文件中获取的AdSource、AdGroup为上述维度组中的每个维度的名称。
步骤S122,遍历根目录下用于定义指标组的第二文件,读取第二文件中的每个指标组的名称以及指标组中的每个指标的名称。
具体的,在本方案中,上述第二文件可以是上述安装Analysis Service数据库的根目录下的Cub结尾目录下的以.det.xml结尾的文件,该文件中为对数据库中的指标的定义。如下是Ad.det.xml文件的一个例子,需要说明的是,该例子删除了无关的元素、属性,删除了大多数Analysis Service数据库的指标对象,只保留了一部分Analysis Service数据库的指标对象:
这里需要说明的是,在本方案中,可以在上述xml文件中获取MeasureGroup元素下Name元素的值Session以及Measures元素下的Name元素的值Visits、Impressions,这里还需要说明的是,在上述xml文件中获取的Session为上述第一文件中的每个指标组的名称,在上述xml文件中获取的Visits、Impressions为上述指标组中的每个指标的名称。
可选的,在步骤S14,根据数据库对象组的组信息生成目标对象文件之前,本实施例提供的方法还可以包括:
步骤S131,创建待替换文件,其中,待替换文件为以下任意一个或多个文件:xml文件、代码文件以及资源文件。
步骤S132,在待替换文件中预先定义每个数据库对象组的名称所对应的一个或多个位置,并定义每个数据库对象的名称所对应的一个或多个位置。
步骤S133,在每个数据库对象组的名称所对应的一个或多个位置上设定相同的第一占位符,并在每个数据库对象的名称所对应的一个或多个位置上设定相同的第二占位符。
具体的,在本方案中,由于在待替换文件(xml文件,代码文件以及资源文件)中,欲生成的相同的每个数据库对象组名称和每个数据库对象会出现多次,因此,在上述待替换文件中设定多个相同的第一占位符和第二占位符。
这里说明的是,由于资源文件分为xml文件、代码文件以及资源文件,而数据库对象定义分为维度的定义和指标的定义,所以本文在每一种具体的应用场景展开描述来解释上述步骤S131至步骤S133。
下面以在xml文件中生成维度的定义来解释上述步骤S131至步骤S133:
在本案中,在读取了数据库对象文件中的维度的定义即每个维度组名称以及维度组中的每个维度名称之后,可以创建xml文件,首先,在xml文件中创建ViewportGroup元素,在ViewportGroup元素下添加ViewportID元素,在一种可选的实施例当中,上述xml文件可以包含下列代码:
具体的,在上述代码中,多个占位符“0”与维度组是对应的,多个占位符“1”和“2”与维度组中具体的维度是对应的。
下面结合在代码文件中为生成维度而设定占位符为例解释上述步骤S131至步骤S133:
具体的,上述代码文件可以为如下代码:
具体的,在上述代码中,多个占位符“0”与维度组是对应的,多个占位符“1”和“2”与维度组中具体的维度是对应的。
下面结合在资源文件中为生成维度而设定占位符为例解释上述步骤S131至步骤S133:
具体的,在本方案中,由于需要对Analysis Service数据库中的对象定义根据不同的语言进行翻译,因此添加多语言的资源文件,每个语言资源文件存储的是AnalysisService对象在该语言下的翻译。以下是英文资源的一个例子:
具体的,在资源文件中添加data元素,name属性为维度组的名称,因为上述资源文件有两个维度,占位符“1”和“2”与维度组中具体的维度是对应的。
下面结合在xml文件中为生成指标而设定占位符为例解释上述步骤S131至步骤S133:
具体的,在上述xml文件中,占位符“3”对应指标组名称,“4”“5”分别对应指标组中指标的名称。
在一种可选的实施例中,在本方案中,结合上述xml代码,可以在上述xml文件中添加GroupRelationships元素,并在GroupRelationships元素下添加string元素,其
格式为[MetricGroup].[3]+[ViewportGroup].[0]。
下面结合在代码文件中为生成指标而设定占位符为例解释上述步骤S131至步骤S133:
具体的,在上述代码文件中,占位符“3”对应指标组名称,“4”“5”分别对应指标组中指标的名称。
下面结合在资源文件中为生成指标而设定占位符为例解释上述步骤S131至步骤S133:
具体的,在上述资源文件中,占位符“4”对应指标组名称,“5”对应指标组中指标的名称。
可选的,在步骤S14,根据数据库对象组的组信息生成目标对象文件的步骤可以包括:
在步骤S141,根据读取到的数据库对象文件中的每个数据库对象组的名称从待替换文件中获取任意一个数据库对象组的名称所对应的第一占位符。
在步骤S142,根据读取到的数据库对象文件中的每个数据库对象的名称从待替换文件中获取任意一个数据库对象的名称所对应的第二占位符。
在步骤S143,使用数据对象文件中读取到的第一数据库对象组名称来替换其在待替换文件中对应的第一占位符。
在步骤S144,使用数据库对象文件中读取到的第一数据库对象名称来替换其在待替换文件中对应的第二占位符。
具体的,在本方案中,在读取到数据库对象文件中任意一个对象组的名称后,可以获取与上述对象组的名称对应的第一占位符,具体的,结合在xml文件中生成维度为例:
在上述以Ad.dim.xml文件中获取到维度组名称Ad和维度名称AdSource与AdGroup之后,则上述维度组名称Ad在xml文件、代码文件以及资源文件对应的第一占位符为“0”,上述AdSource对应的第二占位符则为“1”,上述AdGroup对应的第二占位符则为“2”,在本方案中,可以获取上述占位符,再用上述Ad和AdSource、AdGroup去替换各自对应的占位符,从而生成维度的对象定义。
同样的,在上述以Ad.det.xml文件中获取到指标组名称Session和指标名称Visits与Impressions之后,则上述指标组名称Session在xml文件、代码文件以及资源文件对应的第一占位符为“3”,上述Visits对应的第二占位符则为“4”,上述Impressions对应的第二占位符则为“5”,在本方案中,可以获取上述占位符,再用上述Session和Visits、Impressions去替换各自对应的占位符,从而生成指标的对象定义。
可选的,在本方案中,在上述xml、代码文件、资源文件中生成新的指标和维度的定义之后,本实施例提供的方法还可以包括:
步骤S16,接收用户的查询指令。
步骤S18,根据查询指令加载待替换文件,读取待替换文件中维度和指标的定义并生成针对数据库的查询语句。
具体的,在本方案中,可以通过前端网站来根据上述待替换文件(xml、代码文件、资源文件)中的指标和对象的定义来生成查询语句,进而发起对数据库的访问。
下面结合具体场景对本申请进行详细描述:
基于OLAP数据仓库技术开发的产品可以使用Analysis Service数据库作为后端数据存储。前端网站就是根据Analysis Service对象生成查询语句,对Analysis Service数据库发起查询,因此,前端需要记录Analysis Service数据库定义了哪些AnalysisService对象。具体记录方式为如下三个文件:
(1)XML文件,前端统一将这些Analysis Service对象定义存储在XML文件中,***启动时会加载这个XML,读取XML文件中的定义。如下所示是该XML文件的一个例子,这里限于篇幅进行了删减,实际***中包含上百个Analysis Service对象:
(2)代码文件,定义维度和指标等Analysis Service对象Id,Id唯一标识了一个Analysis Service对象,方便在代码中引用这些Analysis Service对象。如下所示是一个例子,进行了删减:
(3)资源文件,需要对Analysis Service对象根据不同的语言进行翻译,因此添加多语言的资源文件,每个语言资源文件存储的是Analysis Service对象在该语言下的翻译。
以下是英文资源的一个例子,进行了删减:
从上述三个文件可知,Analysis Service数据库中通常包含多个上百个AnalysisService对象定义,我们需要将这上百个对象定义添加到上述的保存Analysis Service对象定义的文件中。同时,Analysis Service数据库结构发生变化时,我们还需要修改这些文件。这里最大的问题是添加这些文件工作量巨大,增加开发时间,且十分繁琐、易于出错、效率低下。每次修改数据库结构,也需要手动修改,如果遗漏的话,发起查询就会失败,影响产品使用和稳定性。
基于此,本申请提出如下方案:
Analysis Service数据库的结构是在多个XML文件中定义的,通过解析这些XML文件,我们最终可以生成Analysis Service对象定义。由于每个用户可能将AnalysisService数据库安装在不同目录下,因此Analysis Service数据库没有固定的根目录,这里需要本解决方案使用者提供Analysis Service数据库结构的根目录。知道根目录以后,根目录下的目录和文件组织结构就是确定的了。具体步骤如下:
(1)由使用者提供Analysis Service数据库结构定义的根目录。
(2)遍历根目录下所有以.dim.xml结尾的文件,这些都是数据库中维度相关对象定义,根据这些文件生成维度相关对象定义。具体的:如下是Ad.dim.xml文件的例子,删除了无关的元素、属性,删除了大多数Analysis Service对象,只保留了一部分AnalysisService对象:
如上所示,Dimension元素是ViewportGroup定义,和上述三个文件中的xml文件中的ViewportGroup元素是等价的,Attribute元素是Viewport定义,和三个文件中的xml文件中的Viewport元素是等价的,由此,本方案可以包括:
1.读取Dimension元素下Name元素的值。
2.生成在XML文件中定义。
2.1在上述三个文件中的xml文件中的ViewportGroups元素下添加ViewportGroup元素,Id属性为[ViewportGroup].[{0}],第0个占位符处使用Dimension的Name元素值替换,Name属性为Dimension的Name元素值.
2.2读取所有Attribute元素下Name元素值,首先在上一步的ViewportGroup元素下添加ViewportIDs元素,然后依次添加string元素,该元素值格式如下:[{0}].[{1}],第0个占位符处使用Dimension的Name元素值替换,第1个占位符处使用Attribute的Name元素值替换。
2.3生成在代码文件中定义。具体的:
2.3.1在上述三个文件中的代码文件中PreDefinedAnalysisObjectID类中,***维度组定义,格式如下:public static readonly string{0}ViewportGroup=“[ViewportGroup].[{0}]”;第0个占位符处有Dimension的Name元素值替换。
2.3.2在上述三个文件中的代码文件中PreDefinedViewportID类下依次***维度定义,格式如下:public static readonly string{1}=“[{0}].[{1}]”;第0个占位符处使用Dimension的Name元素值替换,第1个占位符处使用Attribute的Name元素值替换
2.4生成在资源文件中定义。
2.4.1为维度组添加data元素,Name属性为Dimension的Name元素值,Value元素值为空。
2.4.2为每个维度添加data元素,Name属性为Attribute的Name元素值,Value元素值为空。
需要说明的是,Value值是由每个应用程序开发者填充,因为Analysis Service数据库中的对象的翻译根据每个应用程序的需求决定的,这些翻译不是在Analysis Service数据库中定义的
3.1读取根目录下cub结尾目录下.det.xml结尾的文件,这些都是数据库中指标相关对象定义,根据这些文件生成指标相关对象定义,具体的:
3.2读取MeasureGroup元素下Name元素的值。
3.2.1生成在XML文件中定义。
在上述三个文件中的xml文件中的MetricGroups元素下添加MetricGroup元素,Id属性为[MetricGroup].[{0}],第0个占位符处使用MeasureGroup的Name元素值替换,Name属性为MeasureGroup的Name元素值。
3.2.2读取所有Measure元素下Name元素值,首先在上一步的MetricGroup元素下添加MetricIDs元素,然后依次添加string元素,该元素值格式如下:[Measures].[{0}],第0个占位符处使用Measure的Name元素值替换
3.2.3读取Dimensions元素下所有Dimension元素CubeDimensionID元素,在1.1节GroupRelationships元素下添加string元素,其格式如下:[MetricGroup].[{0}]+[ViewportGroup].[{1}],第0个占位符处使用MeasureGroup元素Name元素值替换,第1个占位符处使用Dimension元素CubeDimensionID元素值替换。
3.3生成在代码文件中定义。具体的:
3.3.1在上述三个文件中的代码文件中PreDefinedAnalysisObjectID类,***指标组定义,格式如下:public static readonly string{0}MetricGroup=“[MetricGroup].[{0}];上述第0个占位符处有MeasureGroup的Name元素值替换。
3.3.2在上述三个文件中的代码文件中PreDefinedMetricID类下依次***维度定义,格式如下:
public static readonly string{0}=“[Measures].[{0}]”;第0个占位符处使用Measure的Name元素值替换。
3.4生成在资源文件中定义的键值。
3.4.1为指标组添加data元素,Name属性为MeasureGroup的Name元素值,Value元素值为空。
3.4.2为每个指标添加data元素,Name属性为Measure的Name元素值,Value元素值为空。
需要说明的是,Value值是由每个应用程序开发者填充,因为Analysis Service对象的翻译根据每个应用程序的需求决定的,这些翻译不是在Analysis数据库中定义的。综上,本申请的发明点在于:根据Analysis Service数据库结构自动生成Analysis Service对象定义,无需手动添加和修改Analysis Service对象定义。这样极大提高开发效率,而且还减少出错的概率,提升***稳定性。其中,根据Analysis Service数据库结构生成Analysis Service对象定义,具体包括:根据以.dim.xml结尾的XML文件生成维度组和维度定义和根据以.det.xml结尾的XML文件生成指标组和指标定义,以及生成维度组和指标组关系定义。
实施例二
本发明实施例还提供了一种生成Analysis Service数据库的对象定义的装置,如图2所示,该装置可以包括:
第一获取模块20,用于获取用户预先设定的Analysis Service数据库的数据结构信息,数据结构信息包括Analysis Service数据库的根目录。
具体的,由于不同用户可能将上述Analysis Service数据库安装在不同的根目录下,因此在本方案中,可以先获取由用户设定或提供的已安装的Analysis Service数据库的根目录,在获取到上述根目录后,Analysis Service数据库的数据结构就可以确定了。
遍历模块22,用于遍历根目录下的数据库对象文件,获取数据库对象文件中的多个数据库对象组的组信息,其中,上述多个数据库对象组的组信息包括:多个数据库对象组的组名称以及数据库对象组中的每个数据库对象的名称。
具体的,上述根目录下的数据库对象文件中可以包含多个数据库对象组,在本方案中,可以通过遍历的方法来获取上述多个数据库对象组的组信息,可选的,在一种可选的实施例中,数据库对象文件中的一个数据库对象组的组信息如表4所示。表4中所示的是同一个数据库对象组的具体的两个数据库对象的信息。
表4:
生成模块24,用于根据数据库对象组的组信息生成目标对象文件,其中目标对象文件包括Analysis Service数据库的对象定义。
具体的,在本方案中,可以根据上述获取的组信息生成目标对象文件,上述目标对象文件中可以为xml文件、代码文件、资源文件,在上述三个文件中只保存数据库的对象定义,该三个文件中的对象定义用于被解析,进而生成查询语句以对数据库发起查询。
本实施例首先通过在用户安装Analysis Service数据库的根目录中的存储数据结构的文件中读取数据库对象的定义,再根据上述数据库的定义自动生成目标对象文件中的对象定义,解决了现有技术中将Analysis Service数据库中大量的对象定义手动的添加到只保存数据库对象定义的目标文件中导致容易出错的问题。实现了自动生成AnalysisService数据库的对象定义的方法,这里需要说明的是,如果Analysis Service数据库中的数据结构发生了变化,***会自动生成变化之后的对象定义,无需人工修改。
可选的,数据库对象文件中的多个数据库对象组包括:维度组、指标组,其中,维度组中包含多个维度,指标组包含多个指标。
可选的,本实施例提供的装置还可以包括:创建模块,定义模块,设定模块。
其中,创建模块,用于创建待替换文件,其中,待替换文件为以下任意一个或多个文件:xml文件、代码文件以及资源文件。定义模块,用于在待替换文件中预先定义每个数据库对象组的名称所对应的一个或多个位置,并定义每个数据库对象的名称所对应的一个或多个位置。设定模块,用于在每个数据库对象组的名称所对应的一个或多个位置上设定相同的第一占位符,并在每个数据库对象的名称所对应的一个或多个位置上设定相同的第二占位符。
可选的,上述生成模块还可以包括:第二获取模块、第三获取模块、第一替换模块、第二替换模块。
其中,第二获取模块,用于根据读取到的数据库对象文件中的每个数据库对象组的名称从待替换文件中获取任意一个数据库对象组的名称所对应的第一占位符;第三获取模块,用于根据读取到的数据库对象文件中的每个数据库对象的名称从待替换文件中获取任意一个数据库对象的名称所对应的第二占位符;第一替换模块,用于使用数据对象文件中读取到的第一数据库对象组名称来替换其在待替换文件中对应的第一占位符;第二替换模块,用于使用数据库对象文件中读取到的第一数据库对象名称来替换其在待替换文件中对应的第二占位符。
可选的,本实施例提供的装置还可以包括:接收模块、查询模块。
其中,接收模块,用于接收用户的查询指令,其中,查询指令用于查询数据库;查询模块,用于根据查询指令加载待替换文件,读取待替换文件中维度和指标的定义并生成针对数据库的查询语句。
需要说明的是,对于前述的各方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本发明并不受所描述的动作顺序的限制,因为依据本发明,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作和模块并不一定是本发明所必须的。
在上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。
在本申请所提供的几个实施例中,应该理解到,所揭露的装置,可通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如所述模块的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个模块或组件可以结合或者可以集成到另一个***,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或模块的间接耦合或通信连接,可以是电性或其它的形式。
所述作为分离部件说明的模块可以是或者也可以不是物理上分开的,作为模块显示的部件可以是或者也可以不是物理模块,即可以位于一个地方,或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。
另外,在本发明各个实施例中的各功能模块可以集成在一个处理模块中,也可以是各个模块单独物理存在,也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现,也可以采用软件功能模块的形式实现。
所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可为个人计算机、移动终端、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述仅为本发明的优选实施例而已,并不用于限制本发明,对于本领域的技术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。