以服务导向架构的走动式指令重组的设计实现于实时商业智能系统
阅读：907发布：2020-05-08
专利汇可以提供以服务导向架构的走动式指令重组的设计实现于实时商业智能系统专利检索，专利查询，专利分析的服务。并且一种以服务导向架构(SOA)的走动式指令重组的设计实现于实时 商业智能 系统，包括一走动式指令重组模 块 由一指令重组及剖析模块、一第一服务定义档、一第二服务定义文件及一继承模块组成，实时依该走动式指令重组模块重组后的指令获得取得数据的来源语法，再以来源语法自多个营运系统或数据仓储取得所需数据，并以服务为导向，以之获得具有数据仓储的多维度数据的分析环境及运算，该使用者端变换需求后，就算不同维度、不同营运系统或多个营运系统及数据仓储或同质或异类 数据库 ，亦可立即获得变换后数据的实时性。透过第一服务定义档及第二服务定义档的结合的架构设计整合异类数据来源。，下面是以服务导向架构的走动式指令重组的设计实现于实时商业智能系统专利的具体信息内容。
1.一种以服务导向架构的走动式指令重组的设计实现于实时商业智能系统，其特征在于，包括：
一服务导向架构、一用户端及一信息科技人员端，该服务导向架构包括一走动式指令重组模块，该走动式指令重组模块包括由一指令重组及剖析模块、一第一服务定义档、一第二服务定义档及一继承模块组成，该第一服务定义档及该第二服务定义档由该信息科技人员端简单定义，数据取自营运系统或数据取自多个营运系统或数据取自多个营运系统及数据仓储，其系实时依该走动式指令重组模块重组后的指令获得取得的数据源，再由数据源取得所需数据，该服务导向架构更包含一语法转换模块，借由该语法转换模块得以沟通该指令重组及剖析模块与各个营运系统或数据仓储的同质或异质的数据库，使所有数据的自动取得无障碍，该继承模块可在各服务间透过继承的方式修改该使用者端的需求及透过服务间的再结合成为一个新的服务完成多重数据源整合，该指令重组及剖析模块负责将服务的定义及使用者端输入的参数设定以走动式指令重组的运算模式完成实时的需求服务分析，并以服务为导向，当该用户端需求改变，该指令重组及剖析模块提供应变的弹性，以之获得具有数据仓储的多维度数据的分析环境及运算，该使用者端变换需求后，就算不同维度、不同营运系统或多个营运系统及数据仓储的同质或异质数据库，亦可立即获得变换后数据的实时性，且不用各别写独立的特定应用程序编程接口。
2.如权利要求1所述的以服务导向架构的走动式指令重组的设计实现于实时商业智能系统，其特征在于：该指令重组及剖析模块建构有完整的撷取指令，该指令重组及剖析模块更具有重组后的指令优化，以缩短数据撷取的时间。
3.如权利要求1所述的以服务导向架构的走动式指令重组的设计实现于实时商业智能系统，其特征在于：该用户端取用数据方式，包括下探、上卷、枢钮分析或切片。
4.如权利要求1所述的以服务导向架构的走动式指令重组的设计实现于实时商业智能系统，其特征在于：该服务导向架构更包含有一多重数据源整合模块，该多重数据源整合模块链接该走动式指令重组模块、该语法转换模块及同质或异质数据库，以该多重数据源整合模块进行多重数据计算整合。
5.如权利要求4所述的以服务导向架构的走动式指令重组的设计实现于实时商业智能系统，其特征在于：该服务导向架构更包含有一数据集及一高速缓存，该数据集链接该走动式指令重组模块、该多重数据源整合模块、同质或异质数据库与该用户端，指令重组后进至该数据集，该数据集由该高速缓存找不到数据时才会至指令对应的数据库撷取数据。
6.如权利要求5所述的以服务导向架构的走动式指令重组的设计实现于实时商业智能系统，其特征在于：该服务导向架构更包括一维度整合模块，该维度整合模块链接该数据集与该使用者端，该维度整合模块得整合衡量值与分析维度分散在不同数据库的数据，再以整合后的数据展示在该用户端。
7.如权利要求6所述的以服务导向架构的走动式指令重组的设计实现于实时商业智能系统，其特征在于：该服务导向架构更包括一过滤器，该过滤器链接该维度整合模块与该用户端，该过滤器以该使用者端设定的条件，过滤掉该维度整合模块整合后数据的多余部分，再以过滤后的数据展示在该用户端。
8.如权利要求7所述的以服务导向架构的走动式指令重组的设计实现于实时商业智能系统，其特征在于：该服务导向架构更包括一用户接口控制模块，该用户接口控制模块链接该用户端、该信息科技人员端、该走动式指令重组模块、该数据集及该过滤器，该用户接口控制模块接受该用户端控制输入，并将输入讯号送至相关该信息科技人员端、该走动式指令重组模块、该数据集及该过滤器，或接收该信息科技人员端、该走动式指令重组模块、该数据集及该过滤器讯号控制往该用户端的输出。
9.如权利要求8所述的以服务导向架构的走动式指令重组的设计实现于实时商业智能系统，其特征在于：该服务导向架构更包括一用户接口输出模块，该用户接口输出模块链接该过滤器、该用户接口控制模块及该用户端，该用户接口输出模块可输出数据至该用户端显示器。
以服务导向架构的走动式指令重组的设计实现于实时商业智
能系统
技术领域
[0001] 本发明一种商业智能系统的技术领域，尤指其技术上提供一种以服务导向架构(SOA)的走动式指令重组的设计实现于实时商业智能系统，以服务为导向，当用户需求改变指令重组及剖析模块提供应变的弹性，以的获得具有数据仓储的多维度数据的分析环境及运算，使用者变换需求后，就算不同维度、不同营运系统或多个营运系统及数据仓储的同质或异质数据库，亦可立即获得变换后数据的实时性，且不用各别写独立的特定应用程序编程接口(API)。
背景技术
[0002] 按，参阅图1所示，图1为一个目前BIS(Business Intelligence System)标准的系统模型，其流程可概分为三阶段：
[0003] (1)资料汇整：使用ETL(Extract-Transform-Load)工具(参阅图2)将源数据库数据源10萃取、转换及加载11，汇入Operational data store数据库；再经整理，累积数据储存12于数据仓储(Data Warehouse)数据库中。
[0004] (2)资料分析：使用ETL工具(参阅图2)将数据仓储24的数据萃取而出，储存于基于分析而建构的数据超市(Data Mart)数据库中(有些情况Data Mart可以省略而直接从交易系统20撷取21、转换22、加载23取得分析数据)。然后再以OLAP(Online Analytical Processing)或数据探勘(Data Mining)技术作资料分析。
[0005] (3)资料展现13：以报表工具产出报表或Web Portal等方式将数据分析结果呈现予用户。
[0006] 而企业现今所面临问题，是不是建置了好的BIS，就可以达成企业BI的梦想之前BIS呼声喊得震天价响，而企业投入了大量的成本、时间及人力等资源后，使用者从BIS所获得的效益与预期认知上对信息质量(Information Quality,IQ)及对系统的有用性(the use of Information)往往存在着很大的落差。到最后企业内部的员工九成还是使用Excel来进行数据的分析，而造成BI的成效不彰。本发明在用户对信息质量不佳的认知层面上大致归纳为下列两点：
[0007] (1)数据仓储在BIS中扮演一个核心的角色，也是后续所有信息分析的基础，但随着企业营运环境快速变化，在激烈的竞争环境下，数据仓储中的数据无法提供决策者及时而稳定的信息，因此纵使有好的BIS也无法满足企业需要。另一方面数据仓储的开发必然是一项极为庞大而复杂的投资，不但风险性高，且须投入企业大量的资源，若在一个没有明确商业事实(business case)的情况下，它可能是一个长期的“进展中的工作(work in progress)”或“计划黑洞(project black hole)”，因此许多企业基于投资成本及风险因素而十分迟疑；Gartner Group在2004年一份从智慧企业(Intelligent Enterprise)的调查显示，有55％的企业用户质疑，认为他们的数据仓储提供的信息并没有击中目标。而另一缺点是开发相当费时，若以传统的系统开发方法通常需要数年的时间，若因开发过程中需求会不断地增加，会采用雏型法先行制作一个雏型，而后反复开发，然而所费时间不赀；到最后企业投入了大量成本及时间其所获得效益与期待之间存在显著显著的落差。
[0008] (2)很多企业会误认为导入了BIS就可以顺利的运作获取应有的分析数据。但企业并没有想到数据仓储中的数据也会随着分析需求的改变及企业型态的改变而需要实时调整，而且另一方面IT人员常常需花费巨额的时间才能整合大量不同的异质数据来源，尤其数据整合(data integration)扮演信息质量(IQ)重要角色，尤其是信息内容质量(Information content quality)最后影响信息的使用结果；BIS的有效性在于它能提供及时的商业信息的能力，因此BIS的导入成功或失败取决于可用的信息；当仰赖IT人员的时间越久或是IT人员的技术不足时(the lack of IT skills)，意谓着决策者等待分析的时间就越长，如此所产生的分析报表也绝对无法满足该决策者随需(on demand)的期望，意即已难反应当下营运环境的变化，这般决策，做了也无太大意义。
[0009] 在2006年所提出BI 2.0赋予不同的思维则主张实时性但要实现BI 2.0概念确实存在诸多落差与障碍，以当前多数企业的BI应用现况来看，若与BI 2.0主要诉求逐一比对，将不难发现，其间落差可谓甚大，在此之中，究竟存在着哪些目前BI障碍？以下说明之：
[0010] (1)传统BIS目的在将数据转换为信息，然后再把信息转换成智能，若企业只为了使用BI而导入BIS，便容易在评估工具的过程中，陷入执着于比较谁的延展性好、谁的计算速度快的盲点，最终BIS充其量仅能提升信息获取的准确性、时效性及整合性，未必能纵深到企业营运管理需求，而导致企业在于导入BIS后，才惊觉现实与期望之间有显著落差，且效益难以评估；而且数据整合IT人员耗时费力，最后BIS沦为报表产生器，诸如此类的运用价值，效益自然不会太高，更与BI 2.0诉求理念相差甚远。
[0011] (2)综观BI 2.0论点，有许多的学者坦承确实不易实现。尤其在实时性的决策中，由于前提是得将企业复杂信息系统之中的细部数据经过诸多整理、运算，况且数据传递也得浪费一些时间，有时就连「增加1个字段」等看似简单的需求，都可能耗费数个工作天。因此，实时性诉求，无疑正是决策者所面临的一大关键障碍，因为，一但数据整合的时程被拖长，便意谓商业决策是奠基于非实时性的数据上，已难反应当下营运环境的变化，更何况决策者为了因应市场的快速变化，其分析的需求会随时而改变，当现行先汇整后的数据(数据仓储)无法满足其需求时，必须再仰赖IT人员再次投入大量的时间(其间若IT人员的专业素养不足时其下达决策的时间点无疑再被延后)，这般的过程对于实时的决策需求，做了也无太大意义。
发明内容
[0012] BI 2.0环境所产出的分析型数据，必须要能嵌入到不同作业流程之中，而过去BIS以特定应用程序编程接口(Application Program Interface,API)为基础，借由IT人员透过开发程序，才能大费周章撷取到分析结果。至于要采取何等新作法，才可让工作流程之中的任一组件，都能轻易取得BIS分析结果，前提便是要跳脱IT人员利用程序所开发一个个独立的API，而改以服务导向架构(SOA)的方式。
[0013] 本发明的设计提供组织(企业)在管理及决策层面效益，以企业交易信息系统(operational IS)为基础导入以服务导向架构的智能型“走动式指令重组”设计，克服了组织(企业)在没有建立数据仓储环境下实时地获得『具有数据仓储的多维度数据的分析环境及运算(drilldown,rollup,slice或pivoting等)』实现实时性决策的诉求，并且已实际导入至企业内部的信息系统(operational IS)，验证了用户与信息需要来源、BIS间达到实时的互动关系而具体的反应在信息质量上的评估及对系统认知上有用性的程度，进而提高信息的使用而大幅提高BIS成功；值得一提的是本发明所设计的SOA架构，透过服务间的再结合成为一个新的服务的创新设计架构，让异质数据整合变得容易。
[0014] 本发明所提出的设计架构能立即从企业内部的交易信息系统(operational IS)中验证前述所提到的BIS成功的关键因素，也就是说数据整合、信息质量及信息的使用等因素，而不需等至投入了大量的成本、时间及人力等资源后，才发现与预期获得的效益之间存在着很大的落差；另外，数据仓储中的数据在提供给用户之前已经过清洗(cleaned)、解碼(decoded)、重组(reorganized)及重排(reordered)，然而透过使用原始事务数据(raw transactional data)，破损的和丑陋的数据在分析过程中才能与良好资料一起被揭露，企业决策者将有机会评估什么是破损的数据及为什么，以便有机会来解决它。因此，从IT发展BIS的效益构面来说，可以预期这样的设计架构其价值可以提高对问题的了解程度与使用者在认知上关键因素的相互关联性，大幅度减少企业导入实时BIS所投入的资源以及满足后续使用者需求的改变，实时地提供用户所需的分析数据、提高BIS的信息使用效率，更可让IT人员节省介入数据整合时间，而更专注于企业其他的商业流程(business process)让IT发挥最大的效益。
[0015] 为达上述目的，本发明的解决方案是：
[0016] 一种以服务导向架构(SOA)的走动式指令重组的设计实现于实时商业智能系统，包括：
[0017] 一服务导向架构(SOA)、一用户端及一信息科技(Information Technology,IT)人员端，该服务导向架构(SOA)包括一走动式指令重组模块(ReSQL)，该走动式指令重组模块(ReSQL)包括由一指令重组及剖析模块、一第一服务定义档(eistable.def)、一第二服务定义档(valueSQL.def)及一继承模块组成，该第一服务定义档(eistable.def)及该第二服务定义档(valueSQL.def)由该信息科技(IT)人员端简单定义，数据取自营运系统或数据取自多个营运系统或数据取自多个营运系统及数据仓储，其系实时依该走动式指令重组模块(ReSQL)重组后的指令获得取得的数据源，再由数据源取得所需数据，该服务导向架构(SOA)更包含一语法转换模块，借由该语法转换模块得以沟通该指令重组及剖析模块与各个营运系统或数据仓储的同质或异质的数据库，使所有数据的自动取得无障碍，该继承模块可在各服务间透过继承的方式修改该使用者端的需求及透过服务间的再结合成为一个新的服务完成多重数据源整合，该指令重组及剖析模块负责将服务的定义及使用者端输入的参数设定以走动式指令重组的运算模式完成实时的需求服务分析，并以服务为导向，当该用户端需求改变，该指令重组及剖析模块提供应变的弹性，以之获得具有数据仓储的多维度数据的分析环境及运算，该使用者端变换需求后，就算不同维度、不同营运系统或多个营运系统及数据仓储的同质或异质数据库，亦可立即获得变换后数据的实时性，且不用各别写独立的特定应用程序编程接口(API)。
[0018] 进一步，该指令重组及剖析模块建构有完整的撷取指令，该指令重组及剖析模块更具有重组后的指令优化，以缩短数据撷取的时间。
[0019] 进一步，该用户端取用数据方式，包括下探(Drill-down)、上卷(Roll-up)、枢钮分析(Pivot)或切片(Slice)。
[0020] 进一步，该服务导向架构(SOA)更包含有一多重数据源整合模块，该多重数据源整合模块链接该走动式指令重组模块(ReSQL)、该语法转换模块及同质或异质数据库，以该多重数据源整合模块进行多重数据计算整合。
[0021] 进一步，该服务导向架构(SOA)更包含有一数据集(DS,dataset)及一高速缓存(cache)，该数据集链接该走动式指令重组模块(ReSQL)、该多重数据源整合模块、同质或异质数据库与该用户端，指令重组后进至该数据集，该数据集由该高速缓存(cache)找不到数据时才会至指令对应的数据库撷取数据。
[0022] 进一步，该服务导向架构(SOA)更包括一维度整合模块，该维度整合模块链接该数据集(DS,dataset)与该使用者端，该维度整合模块得整合衡量值与分析维度分散在不同数据库的数据，再以整合后的数据展示在该用户端。
[0023] 进一步，该服务导向架构(SOA)更包括一过滤器，该过滤器链接该维度整合模块与该用户端，该过滤器以该使用者端设定的条件，过滤掉该维度整合模块整合后数据的多余部分，再以过滤后的数据展示在该用户端。
[0024] 进一步，该服务导向架构(SOA)更包括一用户接口控制模块，该用户接口控制模块链接该用户端、该信息科技人员端、该走动式指令重组模块(ReSQL)、该数据集及该过滤器，该用户接口控制模块接受该用户端控制输入，并将输入讯号送至相关该信息科技人员端、该走动式指令重组模块(ReSQL)、该数据集及该过滤器，或接收该信息科技人员端、该走动式指令重组模块(ReSQL)、该数据集及该过滤器讯号控制往该用户端的输出。
[0025] 进一步，该服务导向架构(SOA)更包括一用户接口输出模块，该用户接口输出模块链接该过滤器、该用户接口控制模块及该用户端，该用户接口输出模块可输出数据至该用户端显示器。
[0026] 因此，本发明在这样的设计架构下，系统具有高度扩展弹性而落实了SOA所强调抽象(abstraction)、可组性(composability)、可重用性(reusability)的核心精神而实现BI 2.0实时分析服务，帮助企业达到：
[0027] (1)增加企业盈收，或提升企业竞争力。
[0028] (2)提供可变动的服务型态。
[0029] (3)降低企业导入的成本及时间。
[0030] (4)降低开发服务的时间以达成实时需求。
[0031] (5)整合企业的网络服务技术资源。
[0032] (6)降低整体风险及意外。
[0034] 图1为习知商业智能(BI)系统架构；
[0035] 图2为习知数据提取转换加载(ETL)架构；
[0036] 图3为本发明服务导向架构(SOA)系统图；
[0037] 图4为本发明走动式指令重组模块(ReSQL)架构系统图；
[0038] 图5为本发明范例一执行结果：94年分季汇整数据(尚未下探)；
[0039] 图6为本发明范例一执行结果：下探至部科维度的汇整资料；
[0040] 图7为本发明范例一执行结果：下探至科室维度的汇整资料；
[0041] 图8为本发明范例一执行结果：下探至医师维度的汇整资料；
[0042] 图9-1为本发明范例一执行结果：该医生看诊申报明细资料；
[0043] 图9-2为本发明范例一执行结果：季份资料汇总；
[0044] 图9-3为本发明范例一执行结果：Drill-down将第一季资料下钻至月份；
[0045] 图9-4为本发明范例一执行结果：Drill-down至2月份部科汇总资料；
[0046] 图9-5为本发明范例一执行结果：Drill-down将2月份内科汇总资料；
[0047] 图9-6为本发明范例一执行结果：Drill-down将2月份外科汇总资料下钻至每日；
[0048] 图10为本发明范例二执行结果：继承范例一的定义，改变维度属性；
[0049] 图11为本发明范例二执行结果：下探至给付类别维度的汇整数据；
[0050] 图12为本发明范例二执行结果：下探至住院案件分类维度的汇整资料；
[0051] 图13为本发明范例二执行结果：部科枢钮(pivot)分析资料；
[0052] 图14为本发明范例三执行结果：继承范例一的定义，在eistable.def中产生新的定义；
[0053] 图15为本发明范例三执行结果：下探至医生维度的汇整资料；
[0054] 图16为本发明范例三执行结果：该医生年度汇整资料；
[0055] 图17-1为本发明范例四：多重数据源整合架构图，其进行衡量值整合；
[0056] 图17-2为本发明多重数据源整合架构示意图，其进行维度整合；
[0057] 图18为本发明范例四执行结果：多重数据源衡量值整合；
[0058] 图19为本发明范例四执行结果：多重数据源整合(下探维度为科室)；
[0059] 图20为本发明范例四执行结果：多重数据源整合(下探至HR数据库的医师明细数据)；
[0060] 图21-1为本发明范例四执行结果：多重数据源整合(与去年同期比较)，以一般维度显示；
[0061] 图21-2为本发明范例四执行结果：多重数据源整合(与去年同期比较)，以期间维度显示；
[0062] 图21-3为本发明范例四执行结果：多重数据源整合(与去年同期比较)，以下探维度显示；
[0063] 【符号说明】
[0064] 习知：
[0065] 10 资料来源 11 萃取、转换及载入
[0066] 12 资料存储 13 资料展现
[0067] 20 交易系统 21 撷取
[0068] 22 转换 23 载入
[0069] 24 资料仓储
[0070] 本发明:
[0071] 30 交易系统 31 资料仓储
[0072] 40 服务导向架构(SOA)
[0073] 41 走动式指令重组模块(ReSQL)
[0074] 411 指令重组及剖析模块
[0075] 412 第一服务定义档(eistable.def)
[0076] 413 第二服务定义档(valueSQL.def)
[0077] 414 继承模块 42 数据集
[0078] 43 语法转换模块 44 多重数据源整合模块
[0079] 45 唯独整合模块 461 用户接口输出模块
[0080] 462 用户接口控制模块 47 过滤器
[0081] 48 同质或异质的数据库 49 高速缓存(cache)。
具体实施方式
[0082] 本发明提供一种以服务导向架构(SOA)的走动式指令重组的设计实现于实时商业智能系统的设计者。
[0083] 为使贵审查委员对本发明的目的、特征及功效能够有更进一步的了解与认识，兹配合实施方式及图式详述如后：
[0084] 参阅图3所示，本发明提供一种以服务导向架构(SOA)的走动式指令重组的设计实现于实时商业智能系统，包含有：
[0085] 一服务导向架构(SOA)40、一用户端及一信息科技(Information Technology,IT)人员端，该服务导向架构(SOA)40包括一走动式指令重组模块(ReSQL)41，该走动式指令重组模块(ReSQL)41包括由一指令重组及剖析模块411、一第一服务定义档(eistable.def)412、一第二服务定义档(valueSQL.def)413及一继承模块414组成，该第一服务定义档(eistable.def)412及该第二服务定义档(valueSQL.def)413由该信息科技(IT)人员端简单定义，数据取自营运系统或数据取自多个营运系统或数据取自多个营运系统及数据仓储，其系实时依该走动式指令重组模块(ReSQL)41重组后的指令获得取得的数据源，再由数据源取得所需数据，该服务导向架构(SOA)40更包含一语法转换模块43，借由该语法转换模块43得以沟通该指令重组及剖析模块411与各个营运系统或数据仓储的同质或异质的数据库48，使所有数据的自动取得无障碍，该继承模块414可在各服务间透过继承的方式修改该使用者端的需求及透过服务间的再结合成为一个新的服务，该指令重组及剖析模块411负责将服务的定义及使用者端输入的参数设定以走动式指令重组的运算模式完成实时的需求服务分析，并以服务为导向，当该用户端需求改变，该指令重组及剖析模块411提供应变的弹性，以之获得具有数据仓储的多维度数据的分析环境及运算，该使用者端变换需求后，就算不同维度、不同营运系统或多个营运系统及数据仓储的同质或异质数据库48，亦可立即获得变换后数据的实时性，且不用各别写独立的特定应用程序编程接口(API)。
[0086] 所述的以服务导向架构(SOA)40的走动式指令重组的设计实现于实时商业智能系统，其中该指令重组及剖析模块411建构有完整的撷取指令，该指令重组及剖析模块411更具有重组后的指令优化，以缩短数据撷取的时间。
[0087] 所述的以服务导向架构(SOA)的走动式指令重组的设计实现于实时商业智能系统，其中该用户端取用数据方式，包括下探(Drill-down)、上卷(Roll-up)、枢钮分析(Pivot)或切片(Slice)。
[0088] 所述的以服务导向架构(SOA)的走动式指令重组的设计实现于实时商业智能系统，其中该服务导向架构(SOA)40更包含有一多重数据源整合模块44，该多重数据源整合模块44链接该走动式指令重组模块(ReSQL)41、该语法转换模块43及同质或异质数据库48，以该多重数据源整合模块44进行多重数据计算整合。
[0089] 所述的以服务导向架构(SOA)的走动式指令重组的设计实现于实时商业智能系统，其中该服务导向架构(SOA)40更包含有一数据集(DS,dataset)42及一高速缓存(cache)49，该数据集42链接该走动式指令重组模块(ReSQL)41、该多重数据源整合模块44、同质或异质数据库48与该用户端，指令重组后进至该数据集42，该数据集42由该高速缓存(cache)
49找不到数据时才会至指令对应的同质或异质数据库48撷取数据。
49找不到数据时才会至指令对应的同质或异质数据库48撷取数据。
[0090] 所述的以服务导向架构(SOA)的走动式指令重组的设计实现于实时商业智能系统，其中该服务导向架构(SOA)40更包括一维度整合模块45，该维度整合模块45链接该数据集(DS,dataset)42与该使用者端，该维度整合模块45得整合衡量值与分析维度分散在不同数据库的数据，以整合后的数据展示在该用户端。
[0091] 所述的以服务导向架构(SOA)的走动式指令重组的设计实现于实时商业智能系统，其中该服务导向架构(SOA)40更包括一过滤器47，该过滤器47链接该维度整合模块45与该用户端，该过滤器47以该使用者端设定的条件，过滤掉该维度整合模块45整合后数据的多余部分，再以过滤后的数据展示在该用户端。
[0092] 所述的以服务导向架构(SOA)的走动式指令重组的设计实现于实时商业智能系统，其中该服务导向架构(SOA)40更包括一用户接口控制模块462，该用户接口控制模块462链接该用户端、该IT人员端、该走动式指令重组模块(ReSQL)41、该数据集42及该过滤器47，该用户接口控制模块462接受该用户端控制输入，并将输入讯号送至相关该IT人员端、该走动式指令重组模块(ReSQL)41、该数据集42及该过滤器47，或接收该IT人员端、该走动式指令重组模块(ReSQL)41、该数据集42及该过滤器47讯号控制往该用户端的输出。
[0093] 所述的以服务导向架构(SOA)的走动式指令重组的设计实现于实时商业智能系统，其中该服务导向架构(SOA)40更包括一用户接口输出模块461，该用户接口输出模块461链接该过滤器47、该用户接口控制模块462及该用户端，该用户接口输出模块461可输出数据至该用户端显示器。
[0094] 以服务导向架构(SOA)，背后由不同组件所组成，这些组件可依不同的目地放置在不同的流程中，以完成企业随需(on demand)服务。其设计的架构归纳为三大层面：
[0095] (1)本发明设计的BIS是建构在企业的operational IS之上(如在线交易系统、ERP、MES、CRM等)，节省了数据转换及整合至数据仓储的时间而且提供最实时的分析数据(数据仓储的开发往往在金钱、人员及时间是一项极为庞大的投资)。
[0096] (2)基于外在环境的改变、竞争压力增强，企业除了必须仰赖实时数据做出实时分析、下达决策之外，而另一方面IT人员必须在最短的时间内支持及满足决策者随时调整分析的需求；再者，由于分析的数据源并非来自汇整过的资料仓储(Data warehouse)，而是从在线交易该时段的当时「状态」数据或是数据需整合同质或异质数据库等不同的数据源，因此为了要实时地获得「具有数据仓储多维度数据的分析环境及运算(drilldown,rollup,slice或pivot等)」，本发明设计一个以服务导向架构(SOA)的走动式指令重组模块(ReSQL)，IT人员端根据决策者分析需求在极短的时间内透过简单的定义设定提供实时分析服务，如多维度下探、上卷、切片、年度比较、多重数据源整合及比较、年度趋势、明细数据进阶维度分析等；此走动式指令重组模块(ReSQL)动态地自动重组优化指令及正确剖析(parse)数据源，提供实时的数据而达成实时决策分析。
[0097] (3)由于资料仓储是汇整后的「历史数据」，可预测未来趋势与结果及快速提供决策者分析数据，或是企业内部已建置数据仓储，基于企业在不同弹性需求因素下，走动式指令重组模块(ReSQL)可同步支持数据源是来自于数据仓储。另一方面，当数据来自于数据仓储，决策者在分析的过程中同时又需要查看更详细的实时数据(raw data或是某种程度汇整过的数据)，然而这些数据并不存在于数据仓储中，基于此，服务导向架构(SOA)支持可在浏灠数据来自于数据仓储的同时，实时串连至交易系统中呈现完整的明细数据。
[0098] 在服务导向架构(SOA)中，软件资源是被封装成服务，将此服务模块化后，提供标准的商业功能。为了要支持共有的商业流程，服务可以被视为建立版块(building block)以便于与其他的服务沟通而支持共有的商业流程；服务在服务导向架构(SOA)中是功能面中的一小部份伴随着有些重要的特性，包括了服务是自主的(Services are autonomous)、服务隐藏了底层的逻辑(Services hide underlying logic)、服务是松散耦合(Services are loosely coupled)及完整的服务定义(Services are well defined)。服务导向架构(SOA)提供了一个弹性的架构，模块化的应用程序至服务中。另外服务导向架构(SOA)允许企业创建，部署和整合多种服务。因此在这种方式中，服务导向架构(SOA)可以提供企业用户灵活性和敏捷性的需要，而且定义服务可整合和重用而成为关键区块，以促进持续的和不断变化的业务需求。
[0099] 服务导向架构(SOA)目的是为企业建构一个具弹性、可重复使用的整合性接口，其组合的元素通常包括软件组件、服务及流程三个部份。当决策者面对新的需求时，流程负责定义决策者要求的处理步骤；服务包括特定步骤的所有程序组件，而软件组件则负责执行工作的程序。以下分别说明本发明的设计架构如何以服务导向架构(SOA)为基础以实现BI 2.0实时的分析环境。
[0100] 图3为服务导向架构(SOA)BIS架构，其中走动式指令重组模块(ReSQL)在服务导向架构(SOA)扮演着实时分析环境的主要核心角色，负责建构使用者需求(服务)定义中所需的多维度数据环境及处理流程，以实时地提供决策者分析服务；无庸置疑的指令重组及剖析模块除了需建构完整的撷取指令之外，还需将重组后的指令优化以缩短数据撷取的时间；期间决策者依其分析模式(或决策者需求服务)，如drilldown,rollup或pivot等走动式的运算，以服务导向架构(SOA)方式透过走动式指令重组模块(ReSQL)及传讯式链接的设计，动态将数据加载至数据集(DS,dataset)中以达成实时因应使用者的需求与改变；再者该走动式指令重组模块(ReSQL)能快速地解决前述所提到若分析数据是整合不同的数据源(同质或异质数据库)时所面临的问题。
[0101] 服务导向架构(SOA)中的数据集(DS,dataset)数据加载是利用server的cache key-value设计概念，当指令重组后所得到的key不在高速缓存(cache)中才会至营运系统数据库撷取数据。
[0102] 参阅图4所示，图4说明走动式指令重组模块(ReSQL)运作的设计架构。本发明在走动式指令重组模块(ReSQL)下设计了第一服务定义档(eistable.def)对应交易系统30或数据仓储31及第二服务定义档(valueSQL.def)对应交易系统30或数据仓储31为服务流程的入口(或服务接口)，主要负责IT人员端根据使用者端的需求，透过该接口与行为属性来定义该需求(服务)所需要的数据环境及流程步骤，做为描述、存取、传输、了解各项服务的要素；本发明提出一个服务创新的设计架构包括不同的定义(服务)之间可透过继承模块修改决策者的需求及透过服务间的再结合成为一个新的服务。而走动式指令重组模块(ReSQL)负责将该服务的定义及使用者参数的设定，以“走动式指令重组”的设计方式完成实时的需求(服务)分析；而且以服务为导向概念，当用户需求改变时，指令重组及剖析模块提供应变的弹性。从图4可知走动式指令重组模块(ReSQL)是整个服务导向架构(SOA)的核心，提供走动式分析模式而达成实时的分析环境。
[0103] 以下本发明导入实际医院内部operational IS发展主管信息系统(EIS)为范例说明在服务导向架构(SOA)下，指令重组及剖析模块设计的架构及执行结果：
[0104] (1)第一服务定义档(eistable.def)的行为属性设定-多维度数据体(Data cube)[0105] 以下范例说明IT人员如何在第一服务定义档定义使用者分析需求(服务)。表一是第一服务定义文件中服务的属性、属性设定值及代表的意义，而“住院日期”，“部科”，“科室”等分别是对应至维度属性名称及衡量属性表达式。当服务定义完成设定，指令重组及剖析模块将借由第一服务定义档(国科范一)函数取得定义内容，结合使用者参数设定，重组数据运算撷取指令将数据加载至数据集(DS)中，如图5所示；随后根据用户分析需求提供多维度数据的分析环境，进行如下探(drilldown)或上卷(rollup)等运算时，指令重组及剖析模块便能辨识目前所在的维度动态的提供实时的分析数据，使得阶层式的景观变的容易，执行结果请参考图6至图8；甚至在不同的维度中可检视其该层较详细数据或进行枢纽(pivoting)分析，执行结果请参考图9。由表一得知IT人员端只需了解企业内部数据库架构及简单的SQL指令用以简单编写第一服务定义档便可结合本发明服务导向架构(SOA)快速建构出具有数据仓储多维度数据的分析环境，提供决策者drilldown,rollup等分析运算。另外指令重组及剖析模块411所产生的指令(commands of ReSQL,COR)其结构请参阅图10说明，图中的COR是由resql()函数所包装，而且根据使用者走动式的分析需求，COR会有多层(multi stage)的巢状resql(nested resql)的组合，其主要的目的是建构多维度模型(multi-dimensional modeling)的分析环境。
[0106] 表一、范例一之eistable.def服务属性定义
[0107]
[0108] Fig.10.An example ofthe structure of COR
[0109]
[0110]
[0111] 前面提到数据集(DS)中的数据加载是利用server的cache key-value设计概念，当指令重组后所得到的key不在高速缓存中才至营运系统数据库撷取数据。为了加速读取时间第一服务定义文件会加载至高速缓存(当第一服务定义档有所修改会自动将高速缓存中相关的key-values移除)。
[0112] (2)服务定义继承模块设计
[0113] 本发明融入了面向对象的继承特性，允许子定义透过继承父定义的方式修改决策者的需求(子定义字段设定可以override或extend父定义的设定)，其继承的方式有两种(1)继承之后在第一服务定义档中不产生新的定义(2)继承之后在第一服务定义档中产生新的定义。以下说明这两种继承的方式：
[0114] 继承之后在第一服务定义档中不产生新的定义：倘若决策者下探的资料需求有所调整，IT人员端透过eistable函数取得范例一定义内容并重新定义drilldown的设定，修改成决策者所需的维度，如表二所示。图10至图12分别说明继承之后下探维度的改变，但数据源维持范例一的设定，另外值得一提的是若下探维度不包括原分析需求维度，如决策者需看部科的汇整数据，则可进入明细，指令重组及剖析模块将重新组合撷取指令至营运系统数据库撷取明细数据，提供决策者进行枢纽(pivot)分析(维度分析)，请参考图13。
[0115] 表二、范例二数据源(继承范例一的定义，但下探维度改变)
[0116]
[0117] 继承原范例一的定义，在第一服务定义档中产生新的定义(可允许再被继承)：假如维度属性欲修改成部科及医师，请参考表三及图14至图15的说明，其中表三中“ref＝国科范一”将继承国科范一的所有的定义而“xcols＝部科”指定第一层维度属性为部科，而“drilldown＝部科，医师”覆盖父定义的设定重新定义维度属性。另外指令重组及剖析模块支持用户端在不同的维度间走动式提供分析服务(请参考图16年度分析数据)。
[0118] 表三、范例三的eistable.def服务定义继承(继承范例一的定义)
[0119]
[0120] (3)第二服务定义档(valueSQL.def)-多重数据源整合：企业营运的环境里往往有不同的交易系统运作，这些系统因建置时间不同而使用不同的数据库管理系统(DBMS)，甚至不同系统上的属性命名方式(data naming)、数据表示法(data representation)、数据编码(data encoding)或数据内容(data content)、数据单位(data scaling)都不一致。一个BI解决方案必须要和企业的整体信息环境能无缝地整合在一起。在没有建置数据仓储或是额外的存储器(physical data repository)的情况下要如何快速的直接整合多重数据源至单一个实时的分析环境以提供决策者实时的分析数据，是具有高难度挑战的任务；另一方面IT人员常常需花费大量的时间才能完成整合的工作。本发明所导入服务导向架构(SOA)透过服务间的再结合成为一个新的服务的创新设计架构，让异质系统整合变得容易，不仅快速地解决企业经常所面临异质数据整合的问题，而且满足企业动态的流程需求，支持商业模式的创新。表四为住院申报的范例数据库(EIS1)及人事数据库(HR)，EIS1储存着医院每天病患住院的交易信息，每一笔事务历史记录着哪个住院病患由哪一位医生看诊及所需的药费(MedFee)、病患部分负担费用(PortFee)及申请费用(AppFee)。而HR数据库储存着每位医生人事数据及等级归类的信息，为了分析医疗费用相关的数据，目前BIS必须架构在一个多维度模型的数据仓储环境下，如表五所示。该数据仓储C(Data Mart C)利用ETL(Extraction,Transformation,and Load)分别从EIS1及HR数据库中取得信息，目的是为了横跨所有相关医疗分析维度及根据现有及可用的运营数据达成决策流程。其中医生维度整合了从EIS1及HR数据库中的医生数据表。一旦多维度的数据仓储建置完成时，通常使用OLTP的工具允许使用者根据不同的维度分析数据。相反的若资料仓储未建置，假设要将等级A(主任医师)的医师在过去三年中八月份看诊的资料汇整至单一个实时的分析环境以提供决策者实时的分析数据，是具有高复杂及高难度挑战的任务。
[0121] 表四、EIS及HR database范例数据
[0122]
[0123] 表五、Data Mart C范例数据
[0124]
[0125]
[0126] 表六、范例四valueSQL.def服务定义-整合多重数据源
[0127]
[0128] 表七、范例四eistable.def定义-整合多重数据源(衡量值整合)
[0129]
[0130] 表八、范例五valueSQL.def服务定义-整合多重数据源(维度整合)
[0131]
[0132] 表九、范例五eistable.def定义-整合多重数据源(等级分类)
[0133]
[0134] 表十、valueSQL·def定义-整合多重数据源
[0135]
[0136] 本发明利用以下范例说明在没有建置数据仓储的基础下，如何具有数据仓储多维度数据的分析环境及运算，而快速达成多重数据源整合。假设前述范例中的数据源为EIS1数据库(医院申报数据库)，其中“医疗费用”是指该科医生与病人之间有医疗行为而产生需申报至健保局的总费用(包括看诊费、药费、检查费及仪器使用费等)，基于主管的分析角度，“医疗费用”应该包含了该科所有介入的资源(包括该科的护士、行政人员或是有些未看诊的医生等资源)，而主管欲了解其该科医师总人数以便于分析收入与付出成本是否有落差，进一步下达某些决策；然而要取得该科医师总人数并不能从EIS1单一数据库获得，还必须从另一个数据库才能取得完整数据。以下将说明如何透过服务间的再结合成为一个新的服务以达成多重数据的整合：
[0137] 表六是本发明所设计第二服务定义文件提供处理多重资料整合的服务机制，其中“专科医师”是指该服务的数据源名称经由数据源内容设定后，也就是前述中该科所有医生(假设包括该月有看诊及未看诊医生)的人数，其数据源是从HR数据库；而在“专科医师.setting”中是指该数据源属性设定，如本范例中的数据源是HR数据库及若要下探至医师的明细数据则在
[0138] 另外如何有效的解决前述中提到数据整合所面临的问题如属性命名、数据表示法等不一致的问题。本发明以属性命名不一致为例说明解决的方法。倘若在图18中多重数据源之间的key(维度)的属性名称或数据表示法不一致；例如，假设在第一服务定义档所定义的数据源key的属性名称为xyz,xyz1,…，而第二服务定义档所定义的数据源key的属性名称为abc,abc1…,本发明设计的方式则在第二服务定义文件中定义属性的mapping，即可达成一致。请参阅表十的设定；若是数据表示法(数据型态)上的冲突，可搭配使用数据库管理系统所提供的函数(如convert,substring,…)或自定函数(如:to_char,:substr,…)，如表十中xyz＝:to_char(abc)，转换成一致的数据型态。
[0139] 再举个例子说明第二服务定义档与第一服务定义档服务间的结合，解决不同类型多重数据整合的问题。假设决策者需要某个分析数据，此数据根据不同的下探维度需从两个不同数据库中汇整(可能加总、平均其他运算)不同数据表中某个(些)域值(域名不一定是一致)，只要类似表六在第二服务定义档分别定义两个数据源(假设DS1及DS2)，接下来在第一服务定义档将DS1及DS2加入vcols中(如表七中的“专科医师”)，再利用compute(如表七中的“平均看诊人数”)进行汇整而达成整合。
[0140] 综观上述第二服务定义档设计目的除了快速整合数据源分别是从不同的数据库，在某些情况需要较复杂的运算，只要在第二服务定义档中定义再与第一服务定义档结合而达到整合的目的，请参考表十一我们再更深入地探讨此创新的设计架构，如表六中所定义的“专科医师”，实际上它所代表的是一个对象的设计观念，而这个对象可以在第一服务定义档中任何一个服务定义的流程中被使用(只要该服务流程与对象间是可以链接)，透过传讯的链接达到整合及对象重用性目的，也呼应了前面所叙述服务间可以再结合成为一个新的服务。
[0141] 由上述说明第二服务定义档与第一服务定义档服务定义间的结合快速完成使用者不同的服务需求，并且解决较复杂问题及快速达到多重数据源整合。另外值得一提的是，架构在走动式指令重组模块(ReSQL)的基础上，可以容易地扩展不同的服务流程的定义，完成不同的服务功能，也说明走动式指令重组模块(ReSQL)严谨的架构设计、完整的结合性及高度的凝聚力。
[0142] 表十一、valueSQL.def定义(数据需较复杂运算)
[0143]
[0144]
[0145] (3)数据仓储及在线交易系统数据同步整合
[0146] 前述中提到数据仓储具有某种程度支持的必要性或是企业内部已建置了数据仓储，基于企业在不同弹性需求因素下，本发明所设计服务导向架构(SOA)亦适用于数据仓储基础上，更进一步的可同时整合数据仓储(或Cube)及交易系统数据，其整合方法如表十二所示。在数据源起始设定中指定该来源是从何种数据库系统，如CUBE1＝汇总一(假设CUBE1的数据源是数据仓储环境)；EIS1＝实时一(假设EIS1的数据源是医院申报交易系统)，而交易系统内数据的取得则可指定从EIS1，如表十二所述Cube1.RawDataDB＝EIS1及EIS1.IsCubeDB＝false。本发明修改范例一说明如何在第一服务定义文件同步整合数据仓储(Cube)及交易系统数据；请参考表十三中“table.cube＝eiscubeview(DTLFBC)”意指维度属性的数据源是从CUBE1中的数据表“DTLFBC”取得，而实时事务数据来源则是从EIS1。前述所列举范例二至范例四其数据源定义皆是继承范例一的定义，一旦范例一的定义有所修改所有继承的范例皆一并修改。因目前CUBE1汇整后的数据与前述范例的数据源为EIS1所执行结果是一致，所以在此无需提供整合结果画面。
[0147] 表十二、数据源起始设定
[0148] EIS_DBMS＝CUBE1＝汇总一；EIS1＝实时一；EIS2＝医院二；EIS3＝医院三Cube1.RawDataDB＝EIS1EIS1.IsCubeDB＝false
[0149] 表十三、eistable.def定义-数据仓储(Cube)及交易系统数据同步整合[0150]
[0151] (4)整合其他服务功能的定义文件
[0152] 综合以上的说明，本发明所设计走动式指令重组模块(ReSQL)真正落实了服务导向架构(SOA)的核心精神，也就是说强调抽象(abstraction)、可组性(composability)、可重用性(reusability)以实现BI 2.0实时分析服务。
| 标题 | 发布/更新时间 | 阅读量 |
|---|---|---|
| 工作流系统中的BI节点执行方法、装置、设备及介质 | 2020-05-12 | 227 |
| 构造用于针对多维数据结构执行的查询 | 2020-05-16 | 210 |
| 一种双向多种角度调节一体支架 | 2020-05-17 | 481 |
| 以服务导向架构的走动式指令重组的设计实现于实时商业智能系统 | 2020-05-08 | 907 |
| 基于机器学习的自适应知识图谱技术 | 2020-05-12 | 643 |
| 一种商业智能仪表盘的组件布局方法 | 2020-05-19 | 741 |
| 远程诊断系统 | 2020-05-14 | 136 |
| LED工业照明有线远程多通道智能调光控制系统 | 2020-05-19 | 526 |
| 一种集物资采购与交易为一体的业务监控系统及方法 | 2020-05-14 | 40 |
| 一种适应性更广的电子价签基站 | 2020-05-18 | 155 |
高效检索全球专利专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台，是提供专利分析，专利查询，专利检索等数据服务功能的知识产权数据服务商。
我们的产品包含105个国家的1.26亿组数据，免费查、免费专利分析。
分析报告
专利汇分析报告产品可以对行业情报数据进行梳理分析，涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度，系统通过AI智能系统对图表进行解读，只需1分钟，一键生成行业专利分析报告。
商业智能热门专利
QQ群二维码
意见反馈
意见反馈