在将HANA作为数据库创建universe建模时,有一条最佳实践,利用JOIN_BY_SQL特性。
这要从头说起,从一个另外相关的设置 - "Multiple SQL statements for each measure"。它的作用如同名字所表示的,对于使用的每一个measure单独生成一条SQL语句。目的是什么的?在基于数据库表设计universe建模的时候,有时候会遇到CHASM。在某些特殊场合下,报表的结果会不准确,比如产生笛卡尔积。解决方案之一便是将分别存在于不同表中的measure单独取出并在WEBI里面进行UNION操作。仅仅勾选这样一个选项,很棒。
我们看下面这样的例子来更好地理解(这里没有CHASM或者FAN,只是为了演示这个参数)
这是一个很简单的data foundation,而measure存在于两张表中
如果在WEBI的query panel里选择了这两个measure,而没有勾选这个选项,那么生成的SQL是什么样的呢?
- SELECT
- sum(Table__2."Quantity"),
- sum(Table__1."GrossAmount"),
- Table__1."OrderId",
- Table__2."OrderItem"
- FROM
- "OPENSAP.workshop::header" Table__1 INNER JOIN "OPENSAP.workshop::item" Table__2 ON (Table__1."OrderId"=Table__2."OrderId")
- GROUP BY
- Table__1."OrderId",
- Table__2."OrderItem"
我们看到是一条SQL语句,利用INNER JOIN来连接的,这就是可能产生CHASM的SQL。
那么我们勾选这个选项,再次运行同样的WEBI,结果如何呢?我们发现WEBI生成了两条SQL,然后用自己的UNION操作将他们组合起来。
但是如果每个查询返回的数据很多会怎样?在WEBI里面做UNION效率一定不高,这时就可能产生性能问题。
这时候我们就可以借助JOIN_BY_SQL,将操作推到数据库层面去做。那么问题是,这与最开始没有勾选‘Multiple SQL statements for each measure“默认产生INNER JOIN语句时的区别在哪呢?我们先去universe里设置一下看看结果再说。
再次运行同样的WEBI报表,获得的SQL语句:
- SELECT
- COALESCE( F__1.Axis__1,F__2.Axis__1 ),
- COALESCE( F__1.Axis__2,F__2.Axis__2 ),
- F__1.M__3,
- F__2.M__3
- FROM
- (
- SELECT
- Table__1."OrderId" AS Axis__1,
- Table__2."OrderItem" AS Axis__2,
- sum(Table__1."GrossAmount") AS M__3
- FROM
- "OPENSAP.workshop::header" Table__1 INNER JOIN "OPENSAP.workshop::item" Table__2 ON (Table__1."OrderId"=Table__2."OrderId")
- GROUP BY
- Table__1."OrderId",
- Table__2."OrderItem"
- )
- F__1
- FULL OUTER JOIN
- (
- SELECT
- Table__1."OrderId" AS Axis__1,
- Table__2."OrderItem" AS Axis__2,
- sum(Table__2."Quantity") AS M__3
- FROM
- "OPENSAP.workshop::header" Table__1 INNER JOIN "OPENSAP.workshop::item" Table__2 ON (Table__1."OrderId"=Table__2."OrderId")
- GROUP BY
- Table__1."OrderId",
- Table__2."OrderItem"
- )
- F__2
- ON ( F__1.Axis__1=F__2.Axis__1 AND F__1.Axis__2=F__2.Axis__2 )
我们看到操作是通过数据库的FULL OUTER JOIN进行的。这样既保证了单独为每一个measure取数又能够保证整个操作在数据库层面进行,提高效率。
由于HANA处理的高效率,所以在基于HANA建模时,我们都建议利用这样的设置进行操作。
不过没有万能的设计。如果取回的数据量足够小,小到WEBI可以很快速的处理UNION,而数据库本身处理UNION操作又造成了一定的问题,比如大量内存的消耗,CPU时间的消耗,这个时候就不要坚持JOIN_BY_SQL了。
相关推荐
SAP HANA官方SQL文档主要讲述了存储过程的各种语法:存储过程定义,存储过程各种类型变量定义,存储过程逻辑控制语句,游标定义和使用等
包含各种集成的内部调用方法的使用说明
sap hana的sql语句大全 包括sql语句的语法以及hana sql的各种函数
SAP HANA STUDIO 2.3.37
HANA_SQL语句和系统视图 了解Hana的SQL语句 内存数据库CURD的基本操作
HANA数据库检测运行状况的脚本包
HANA培训_基础架构,技术架构,组件,配置,日志,存贮点,介绍分布式体系架构
HANA SQL Statement - HANA_ABAP_ApplicationLog_OrphanRecords
SAP_HANA_STUDIO_2.3.15_X64版本,特殊环境可能需要。最新开发工具都是直接eclipse安装插件完成。
HA200_ZH_Col16_SAP_HANA_2.0_SPS04_安装和管理
SAP_Certified_Application_Associate___SAP_S_4HANA_Cloud__public____Supply_Chain_Implementation_2022_Badge20220829-46-issnpj.pdf
SAP_HANA_CLIENT_32bit.zip
HANA数据库的备份和还原。希望能帮助需要的朋友;
https://help.sap.com/viewer/e9146b36040844d0b1f309bc8c1ba6ab/3.2/en-US/734759c0c1c9440c857da0d366e47dda.html
HANA_SAP_Apriori算法_源码.zip
SAP_HANA_Developer_Guide_for_SAP_HANA_Studio_en 2018版
SAP-HANA数据库SQL参考手册是一个中文版的SAP HANA SQL参考文件,里面详细介绍了在SAP HANA 体系中SQL语言的使用规则,包括增删改查等语句
给有兴趣的人了解了解,英文版,SAP HANA ,
HANA SQL参考手册