universe 联接问题_原创精品文档.pdfVIP

  1. 1、本文档共15页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  5. 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  6. 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  7. 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  8. 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多

Universe3大陷阱

环路

定义:环路指经过模式中一组表的闭合联接,联接形成维表之间多条路径时将出

现环路

结果:返回太少行

例:如下图的universe中存在一个环路,环路中本应该包含两个上下文,需要描述

的均是顾客与服务之间的关系,但是由于服务有已消费和已预约两种,

所以两个上下文在业务上分别表示预约顾客和服务间的关系和已消费顾

客和服务之间的关系。由于此universe未设置任何上下文,导致出现环

路错误。

在universe中创建3个对象,分别为:顾客姓名,服务,预约天数。

以下为在webi报表开发时,将以上3个对象均放入query中时生成的SQL,由于

没有未环路指定不同上下文,整个环路被当做一个上下文,在SQL的

where子句中会出现环路中所有表的关联限制。实际上我们只需要对SQL

进行其中一个上下文的限制。

联接应用了比预期更多的限制,导致返回的结果是既预约了又消费了的用户,导

致返回的数据不正确。

解决方法:

1.别名

2.定义上下文

别名有时候并不能解决所有环路的问题,或者有些环路问题需要定义不止一个

别名来解决,如下图:

为customer表定义别名后,发现city表仍然造成环路。

此时需要定义上下文解决环路。

指定上下文后,query会自动按相关的上下文生成SQL,此时where子句中的关联

限制来自同一上下文的表之间的联接。

断层陷阱

定义:断层陷阱是当两个“多对一”联接会聚在一个表上时三个表之间的一种

联接路径,并且没有适当地分隔会聚联接路径的上下文。需要注意的是:基于

以下即将描述的原因,联接的基数必须是“多对一”是才会产生断层陷阱。

结果:返回数据变大

例:universe中两张事实表invoice_line和reservation_line分别描述消费信息和

预订信息,均与service表多对一关联。此时Universe中未指定任何上下文。

为universe创建如下五个对象:

将所有对象放入query中,此时query生成的SQL如下图:

在webi报表上将下图所示3个字段拖入报表中,显示的数据如下:

通过在数据库端验证,此数据是错误数据。

错误原因如下图所示:之前的query的SQL截图中where语句中内容决定了结

果会产生笛卡尔积。

NumberoffutureServiceserviceserviceNumberofguest

guest

Reservetion_lineInvoice_line

10s1s140

s1

20s1s130

30s2s220

s2

40s2s210

由上图可知,为何必须是多对一关联才会出现断层陷阱问题。

解决方法:指定上下文

扇形陷进

当“一对多”连接链接了依次由另一个“一对多”连接链接的表时,扇形

陷阱是三个表之间的一种连接路径。当查询包括同时基于两个表的对象时,

“一对多”连接的分散影响可能会导致返回不正确的结果。

结果:返回的值变大。

例:

假设下图为以上涉及的3表中的相关数据:

文档评论(0)

184****8948 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档