<br><font size=2 face="sans-serif">Hi,</font>
<br>
<br><font size=2 face="sans-serif">For now we are leaving All Members vs
Aggregate issue open and proceeding with getting Grouping sets functionality
working.</font>
<br>
<br><font size=2 face="sans-serif">We have developed a Proof of concept
to achieve the Grouping sets functionality, with this we have managed to
get all the tests except 2 tests passing. Two failing tests are because
of All member queries getting orphan rows(InlineTableTests).</font>
<br>
<br><font size=2 face="sans-serif">Limitations of our POC:</font>
<br><font size=2 face="sans-serif">1. &quot;All value&quot; will not be
consistent in cases where there are extra fact rows (i.e, rows that don't
connect to the dimension of interest).</font>
<br>
<br><font size=2 face="sans-serif">2. The implementation doesn't reduce
the number of queries in cases like <i>select {member,member.children}
...</i></font>
<br><font size=2 face="sans-serif">This is because, it becomes very tricky
to identify that members.children roll up to member, since the roll-up
logic heavily relies on constraint bit key to identify batch that can be
grouped into a single sql query</font>
<br>
<br><font size=2 face="sans-serif"><b>Note:</b> POC is a hacky solution,
it doesn't consider issues like Concurrency..</font>
<br>
<br><font size=2 face="sans-serif"><i>Logic for identifying the Batches
which can be grouped :</i></font>
<br><font size=2 face="sans-serif">1. If Batch A's constraint columns list
is super set of Batch B's constraint columns </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;and</font>
<br><font size=2 face="sans-serif">2. If matching columns of the Batch
A and Batch B has the same value </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;and</font>
<br><font size=2 face="sans-serif">3. If Non matching columns of super
set have All values </font>
<br>
<br><font size=2 face="sans-serif">We are sending this for an early feed
back, if you see any issues with our approach please let us know, we will
be starting our actual implementation next week.</font>
<br>
<br><font size=2 face="sans-serif">Attached the tar file created using
packChanges containing our POC in the forum post : http://forums.pentaho.org/showthread.php?t=53644</font>
<br>
<br><font size=2 face="sans-serif">Thanks,</font>
<br><font size=2 face="sans-serif">Thiyagu &amp; Raghu</font>
<br>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Richard Emberson &lt;remberson@edgedynamics.com&gt;</b>
</font>
<br><font size=1 face="sans-serif">Sent by: mondrian-bounces@pentaho.org</font>
<p><font size=1 face="sans-serif">04/24/2007 07:02 PM</font>
<table border>
<tr valign=top>
<td bgcolor=white>
<div align=center><font size=1 face="sans-serif">Please respond to<br>
Mondrian developer mailing list &lt;mondrian@pentaho.org&gt;</font></div></table>
<br>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">Mondrian developer mailing list &lt;mondrian@pentaho.org&gt;</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: [Mondrian] All Members vs Aggregate</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2>In our local usage, this has been know for a while;<br>
dimensions can have<br>
only partial coverage of the base fact table. If you<br>
have orphan rows in the fact table for a given<br>
dimension, then for an<br>
aggregate the sum across a lower level will not equal<br>
the sum at the top, all level. This is because for<br>
lower levels the sql is joining across from fact table<br>
foreign key to dimension table primary key. But for<br>
the top level result, there is an optimization(?)<br>
and the generated sql does not assure that only fact<br>
table rows with matching entries in the dimension table<br>
make up the result.<br>
One might wish that there was a property that controled<br>
this behavior, so that, if one wished, that no<br>
orphan rows be counted. The alternative is to have<br>
your dbs make sure that there is no bad data in the<br>
fact tables (we have experienced that, as with much of<br>
life, dirt happens; over time bad data creeps into<br>
fact tables).<br>
<br>
Richard<br>
<br>
<br>
Thiyagu Palanisamy wrote:<br>
&gt; <br>
&gt; As of now mondrian uses multiple sql queries to get data for a MDX
with <br>
&gt; &nbsp;members at different levels. We are working on changing this
behavior <br>
&gt; to combine these multiple sqls to single one.<br>
&gt; <br>
&gt; For an example this MDX generates 2 sqls, one for all gender and another
<br>
&gt; for male,female<br>
&gt; <br>
&gt; select gender.members on 0 from [sales 2] where measures.[Sales Count];<br>
&gt; <br>
&gt; sql:<br>
&gt; 1. /select &nbsp;&quot;time_by_day&quot;.&quot;the_year&quot; as &quot;c0&quot;,
&nbsp;&quot;customer&quot;.&quot;gender&quot; as <br>
&gt; &quot;c1&quot;, &nbsp;count(&quot;sales_fact_1997&quot;.&quot;product_id&quot;)
as &quot;m0&quot;<br>
&gt; from &quot;time_by_day&quot; &quot;time_by_day&quot;, &nbsp;&quot;sales_fact_1997&quot;
&quot;sales_fact_1997&quot;, <br>
&gt; &nbsp;&quot;customer&quot; &quot;customer&quot;<br>
&gt; where<br>
&gt; &nbsp; &nbsp;&quot;sales_fact_1997&quot;.&quot;time_id&quot; = &quot;time_by_day&quot;.&quot;time_id&quot;
and<br>
&gt; &nbsp; &nbsp;&quot;time_by_day&quot;.&quot;the_year&quot; = 1997 and<br>
&gt; &nbsp; &nbsp;&quot;sales_fact_1997&quot;.&quot;customer_id&quot; =
&quot;customer&quot;.&quot;customer_id&quot;<br>
&gt; group by &nbsp;&quot;time_by_day&quot;.&quot;the_year&quot;, &quot;customer&quot;.&quot;gender&quot;
/<br>
&gt; <br>
&gt; 2. /select &quot;time_by_day&quot;.&quot;the_year&quot; as &quot;c0&quot;,
<br>
&gt; &nbsp;count(&quot;sales_fact_1997&quot;.&quot;product_id&quot;) as
&quot;m0&quot;<br>
&gt; from &quot;time_by_day&quot; &quot;time_by_day&quot;, &quot;sales_fact_1997&quot;
&quot;sales_fact_1997&quot;<br>
&gt; where<br>
&gt; &nbsp; &nbsp;&quot;sales_fact_1997&quot;.&quot;time_id&quot; = &quot;time_by_day&quot;.&quot;time_id&quot;
and<br>
&gt; &nbsp; &nbsp;&quot;time_by_day&quot;.&quot;the_year&quot; = 1997<br>
&gt; group by<br>
&gt; &nbsp; &nbsp;&quot;time_by_day&quot;.&quot;the_year&quot;<br>
&gt; /<br>
&gt; <br>
&gt; with our prototype, these sqls are grouped into one (this query will
<br>
&gt; only &nbsp;work with DBs that support grouping sets):<br>
&gt; <br>
&gt; 1. /select &quot;time_by_day&quot;.&quot;the_year&quot; as &quot;c0&quot;,
&nbsp;&quot;customer&quot;.&quot;gender&quot; as <br>
&gt; &quot;c1&quot;, &nbsp;count(&quot;sales_fact_1997&quot;.&quot;product_id&quot;)
as &quot;m0&quot;<br>
&gt; from &quot;time_by_day&quot; &quot;time_by_day&quot;, &nbsp;&quot;sales_fact_1997&quot;
&quot;sales_fact_1997&quot;, <br>
&gt; &nbsp;&quot;customer&quot; &quot;customer&quot;<br>
&gt; where<br>
&gt; &nbsp; &nbsp;&quot;sales_fact_1997&quot;.&quot;time_id&quot; = &quot;time_by_day&quot;.&quot;time_id&quot;
and<br>
&gt; &nbsp; &nbsp;&quot;time_by_day&quot;.&quot;the_year&quot; = 1997 and<br>
&gt; &nbsp; &nbsp;&quot;sales_fact_1997&quot;.&quot;customer_id&quot; =
&quot;customer&quot;.&quot;customer_id&quot;<br>
&gt; group by &nbsp;grouping sets((&quot;time_by_day&quot;.&quot;the_year&quot;,
&quot;customer&quot;.&quot;gender&quot;), <br>
&gt; (&quot;time_by_day&quot;.&quot;the_year&quot;)) /<br>
&gt; <br>
&gt; Although the grouping set implementation looks fine and works in most
<br>
&gt; cases, there is a tricky problem associated with it. The problem is
<br>
&gt; grouping &quot;all&quot; (aggregate) value got from rolling up is
equal to <br>
&gt; aggregate of the members involved and not the all value<br>
&gt; <br>
&gt; to reproduce it, alter fact table and insert rows for null customers:<br>
&gt; <br>
&gt; --modify fact table to allow nulls for customer_id<br>
&gt; alter table &quot;sales_fact_1997&quot; modify &quot;customer_id&quot;
null &nbsp; &nbsp; &nbsp; &nbsp;<br>
&gt; --add sales records with no customers<br>
&gt; insert into &quot;sales_fact_1997&quot; values (337,371,null,0,2,6.3455,2.3445,4)<br>
&gt; insert into &quot;sales_fact_1997&quot; values (337,440,null,0,2,6.3355,2.335,2)<br>
&gt; <br>
&gt; results:<br>
&gt; remains same with grouping sql:<br>
&gt; Axis #0:<br>
&gt; {[Measures].[Sales Count]}<br>
&gt; Axis #1:<br>
&gt; {[Gender].[All Gender]}<br>
&gt; {[Gender].[All Gender].[F]}<br>
&gt; {[Gender].[All Gender].[M]}<br>
&gt; Row #0: 86,837 &nbsp; &nbsp; &nbsp;<br>
&gt; Row #0: 42,831<br>
&gt; Row #0: 44,006<br>
&gt; <br>
&gt; without grouping (mondrian's current behavior):<br>
&gt; ...<br>
&gt; Row #0: 86,839 &nbsp; &nbsp; &nbsp; &nbsp; //includes 2 records that
don't belong to any gender<br>
&gt; Row #0: 42,831<br>
&gt; Row #0: 44,006<br>
&gt; <br>
&gt; In summary &quot;All&quot; in mondrian is not really an aggregate
of all the <br>
&gt; members, it also includes data from rows that don't join to fact table.
<br>
&gt; This behavior is not consistent with AS 2000 (MOLAP).<br>
&gt; How should we handle this issue?<br>
&gt; &nbsp;One of the options that we can think of is, to use outer joins.
The <br>
&gt; problem with this is it returns addition row for &quot;null&quot;
gender.<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; Thanks,<br>
&gt; Thiyagu &amp; Raghu<br>
&gt; <br>
&gt; <br>
&gt; ------------------------------------------------------------------------<br>
&gt; <br>
&gt; _______________________________________________<br>
&gt; Mondrian mailing list<br>
&gt; Mondrian@pentaho.org<br>
&gt; http://lists.pentaho.org/mailman/listinfo/mondrian<br>
<br>
<br>
-- <br>
Quis custodiet ipsos custodes:<br>
This email message is for the sole use of the intended recipient(s) and<br>
may contain confidential information. &nbsp;Any unauthorized review, use,<br>
disclosure or distribution is prohibited. &nbsp;If you are not the intended<br>
recipient, please contact the sender by reply email and destroy all<br>
copies of the original message.<br>
_______________________________________________<br>
Mondrian mailing list<br>
Mondrian@pentaho.org<br>
http://lists.pentaho.org/mailman/listinfo/mondrian<br>
</font></tt>
<br>