Multi-Pass SQLmeetthetaylors.com/files/Multi-Pass SQL PPT.pdf · The additional features ease...

BUSINESS OBJECTS CONFIDENTIAL. COPYRIGHT © 2008 BUSINESS OBJECTS S.A.

Multi-Pass SQL

Techniques for BOE XIr2


Multi-Pass SQL

BOE Release DependencyAll the information and examples contained within thispresentation are based upon Business ObjectsEnterprise XIr2. The service pack (SP) level is at SP2or higher. At this time Business Objects Enterprise 3.0has just been released. BOE 3.0 has new features thatimpact multi-pass SQL implementation. A revision ofthis presentation is currently planned. None of thefeatures in BOE 3.0 render the techniques reviewedobsolete. The additional features ease multi-pass SQLimplementation and provide new techniques that cansimplify the process.


Multi-Pass Definition

Creation of Multiple Queries Against a DatabaseCreate a number of simple queries to be processed separately bythe DBMS

Combine Query Results to Achieve Desired OutcomeTraditional Approach

Use temporary tables to store intermediate results of queriesCombine temp tables with each other or with permanent tablesfor final result

Query Tool ApproachCombine query results in an intelligent way for final resultUtilize reporting tier


Multi-Pass Competitive Landscape

All BI Vendors Claim CapabilityTruth is all doBut to various degrees

MicrostrategyOnes who are more likely to stress capabilityClaim all other vendors are limited to single pass

Implementing Multi-Pass within Business ObjectsHow is it invoked?Where is burden placed?

Semantic layerReport builderEnd user

How much effort at each level?


Multi-Pass Scenarios

Sharing Dimensions Across Fact TablesCalculations Which Require End Results

Ratios: Pct of product sales to total salesBlending Grains of Measurements

Time: Year-To-Date, Month-To-Date, Last-Year-To-Date, etcNeed for Semi-Additive Measures

Inventory as of: end of quarter, end of month, end of weekAnalyzing a Subset of Data

Last transaction for each account, latest status record for account


Sharing Dimensions

One Dimension TableProduct Category

Two Fact TablesSales CallsSales Amounts

Report requires the totalnumber of Sales Calls, totalSales Amount by ProductCategory


Sharing Dimensions

Proposed SQL leads toincorrect resultsNature of SQL

Not specific to BusinessObjectsNot specific to any RDBMS

Nbr Calls duplicated bynumber of times that acategory has a sales amountrecordedSales duplicated by number oftimes that a category has asales call recorded

SELECT

MP_T1_CAT.Category, MP_T1_CAT.Cat_Id,

sum(MP_T1_Calls.Nbr_Calls),

sum(MP_T1_Sales.Sales)

FROM

MP_T1_Cat, MP_T1_Calls, MP_T1_Sales

WHERE

MP_T1_Cat.Cat_Id = MP_T1_Calls.Cat_id

AND MP_T1_Cat.Cat_Id = MP_T1_Sales.Cat_Id

GROUP BY MP_T1_CAT.Category,

MP_T1_CAT.Cat_Id


Sharing Dimensions

Traditionalist approachCreate a temp table withcolumns of Cat_ID,Nbr_Sales_Calls, and SalesInsert number of calls bycategory in table

Insert total sales amount bycategory in table

Select results for report

Drop table

CREATE TABLE Sales_and_Calls(Cat_Id integer, Nbr_Calls integer,Sales decimal(10,2))

INSERT INTO Sales_and_Calls (Cat_Id,Nbr_Calls, Sales)SELECT MP_T1_Calls.Cat_ID,sum(MP_T1_Calls.Nbr_Calls), 0FROM MP_T1_CallsGROUP BY MP_T1_Calls.Cat_Id

INSERT INTO Sales_and_Calls (Cat_Id,Nbr_Calls, Sales)SELECT MP_T1_Sales.Cat_ID, 0,sum(MP_T1_Sales.Sales)FROM MP_T1_SalesGROUP BY MP_T1_Sales.Cat_Id

SELECT MP_T1_Cat.Cat_Id, Category,sum(Nbr_Calls), sum(Sales)

FROM Sales_and_Calls JOIN MP_T1_CatON MP_T1_Cat.Cat_Id = Sales_and_Calls.Cat_IdGROUP BY MP_T1_Cat.Cat_Id, CategoryORDER BY MP_T1_Cat.Cat_Id

DROP TABLE Sales_and_Calls


Sharing Dimensions

Data inserted into thetemporary table containsseparate rows for Nbr_Callsand SalesOnce pulled together forreport, results are correctProcess is very databasecentric


Sharing Dimensions

How does Business Objectshandle this?

Business Objects does notcreate work tables within thedatabaseBut it does create multipleSELECT statementsResults are combined on theBusiness Objects tierNot on the database tier

SELECT

MP_T1_CAT.Category, MP_T1_CAT.Cat_Id,

sum(MP_T1_Sales.Sales)

FROM

MP_T1_Cat, MP_T1_Sales

WHERE

MP_T1_Cat.Cat_Id = MP_T1_Sales.Cat_Id


MP_T1_CAT.Cat_Id

SELECT

MP_T1_CAT.Category, MP_T1_CAT.Cat_Id

sum(MP_T1_Calls.Nbr_Calls)

FROM

MP_T1_Cat, MP_T1_Calls

WHERE

MP_T1_Cat.Cat_Id = MP_T1_Calls.Cat_id


MP_T1_CAT.Cat_Id


Sharing Dimensions

Within the query panel selectthe desired objectsThe two SELECT statementsare generatedResult sets from the twoSELECTs are combined on theBusiness Objects tier and thendisplayedResults are identical to thetraditional hand coding method


Sharing Dimensions

Universe parameter controls creation of multiple SELECTEnabled by defaultActually the label, Multiple SQL statements for each measure, is alittle misleading

Notice section name for parameter, Multiple PathsOnly applies when measures being retrieved are from different tables


Sharing Dimensions

Contexts can also be used tosolve this multi-pass scenarioContexts separate multiplepaths between tables

From MP_T1_Cat toMP_T1_CallsFrom MP_T1_Cat toMP_T1_Sales

Proper Universe designdictates that contexts shouldalways be identified within aUniverse

If cardinalities have beenproperly identified, contextscan automatically detected byUniverse Designer


Sharing Dimensions

Universe parameter, Multiple SQL statements for each context,controls creation of multiple SELECTs due to contextsEnabled by defaultExtremely useful when Multiple SQL statements for each measure isdisabled


Sharing Dimensions

Must Business Objects combine the query result sets?JOIN_BY_SQL, Universe parameter was introduced in BOE XIr2 SP1Creation of multiple SELECT statements controlled by previouslyreviewed parameters

JOIN_BY_SQL affects SQL generation onlyEach SELECT statement generates a derived tableResults sets of derived table combined by the databaseBusiness Objects receives only one result set from the database


Sharing Dimensions

Same objects used in querypanel as before

SELECTCOALESCE( F__1.Axis__1,F__2.Axis__1 ),COALESCE( F__1.Axis__2,F__2.Axis__2 ),F__1.M__3, F__2.M__4

FROM( SELECT

MP_T1_Cat.Cat_Id AS Axis__1,MP_T1_Cat.Category AS Axis__2,sum(MP_T1_Calls.Nbr_Calls) AS M__3

FROM MP_T1_Cat, MP_T1_CallsWHERE

( MP_T1_Calls.Cat_id=MP_T1_Cat.Cat_Id)GROUP BY

MP_T1_Cat.Cat_Id,MP_T1_Cat.Category ) F__1

FULL OUTER JOIN( SELECT

MP_T1_Cat.Cat_Id AS Axis__1,MP_T1_Cat.Category AS Axis__2,sum(MP_T1_Sales.Sales) AS M__4

FROM MP_T1_Cat, MP_T1_SalesWHERE

( MP_T1_Cat.Cat_Id=MP_T1_Sales.Cat_Id)GROUP BY


ON ( F__1.Axis__1=F__2.Axis__1 ANDF__1.Axis__2=F__2.Axis__2 )



FROM( SELECT











Sharing Dimensions

Same objects used in querypanel as beforeDerived table F__1 retrievesthe Number of Calls along withthe two dimensions, Categoryand Category ID


Sharing Dimensions

Same objects used in querypanel as beforeDerived table F__1 retrievesthe Number of Calls along withthe two dimensions, Categoryand Category IDDerived table F__2 retrievesthe Total Sales along with thetwo dimensions, Category andCategory ID


FROM( SELECT












Sharing Dimensions

Same objects used in querypanel as beforeDerived table F__1 retrievesthe Number of Calls along withthe two dimensions, Categoryand Category IDDerived table F__2 retrievesthe Total Sales along with thetwo dimensions, Category andCategory IDPrimary SELECT combinesthe results from the derivedtables using the COALESCEfunction to return non-nullvalues of the dimensions

AXIS__1 is Category IDAXIS__2 is CategoryF__1.M__3 is Number of CallsF__2.M__4 is Sales Amount


FROM( SELECT


FROM MP_T1_Cat, MP_T1_CallsWHERE( MP_T1_Calls.Cat_id=MP_T1_Cat.Cat_Id )

GROUP BYMP_T1_Cat.Cat_Id,MP_T1_Cat.Category ) F__1



FROM MP_T1_Cat, MP_T1_SalesWHERE( MP_T1_Cat.Cat_Id=MP_T1_Sales.Cat_Id )

GROUP BYMP_T1_Cat.Cat_Id,MP_T1_Cat.Category ) F__2



Sharing Dimensions - Recap

Two Universe ParametersMultiple SQL statements for each measureMultiple SQL statements for each contextBoth enabled by defaultResults multiple SQL statements

Additional Universe ParameterJOIN_BY_SQLConverts multiple SELECT statements into derived tablesPrimary SELECT then uses derived tables as query sourceMethod is more database centric

More Innovative Approach Versus Traditional MethodBetter performance due to less database activityPartial shift of load from database to reporting tier


Advanced Calculations

Require end result as part ofthe calculation

Percentage of sales bycategory

RequiresTotal overall salesTotal sales by category



Traditionalist approachCreate a temp table with onecolumns, Total SalesInsert total overall sales

Select results for reportTotal sales used from thetemporary table to calculateratio

Drop table

CREATE TABLE Total_Sales(All_Sales decimal(10,2))

INSERT INTO Total_Sales (All_Sales)SELECT sum(MP_T1_Sales.Sales)FROM MP_T1_Sales

SELECT Category,sum(MP_T1_Sales.Sales),(cast(sum(MP_T1_Sales.Sales) asdecimal(10,4))/(All_Sales) ) * 100as Pct_of_SalesFROM MP_T1_Sales, Total_Sales,MP_T1_CatWHERE MP_T1_Cat.Cat_Id =MP_T1_Sales.Cat_IdGROUP BY Category, All_SalesORDER BY Category

DROP TABLE Total_Sales



One row of data inserted intothe temporary table whichcontains the overall total ofSalesResult can then be used toperform calculation in primarySELECT

SELECT between the SALESfact table and the temporarytable does produce CartesianproductResult is still accurate sinceonly one row exists in thetemporary table



How does Business Objectshandle this?

Commonly done as a variable atthe report level

AdvantagesSome calculations are verysimpleWith the For Each, For All, andWhere context operators manycalculations can be createdNo need to wait on semanticlayer development

DisadvantagesNot able to share report variablesIncorrect formulasMultiple versions of the TruthpossibleEase of use



Create derived table withinUniverse to calculate requiredmeasure

Derived table becomesanother fact table within theuniverse



Derived table SQL SELECTMP_T1_Sales.Cat_Id,(sum(MP_T1_Sales.Sales)/Company.All_Sales ) asCat_Sales_Ratio

FROM MP_T1_Sales,( SELECT sum(MP_T1_Sales.Sales) as

All_Sales FROM MP_T1_Sales ) asCompany

GROUP BY MP_T1_Sales.Cat_Id,

Company.All_Sales



Derived table SQLThe derived table also containsa derived tableThe interior derived tablereturns the total of all salesacross all categories

SELECTMP_T1_Sales.Cat_Id,(sum(MP_T1_Sales.Sales)/Company.All_Sales ) asCat_Sales_Ratio




Company.All_Sales


SELECTMP_T1_Sales.Cat_Id,(sum(MP_T1_Sales.Sales)/Company.All_Sales ) asCat_Sales_Ratio




Company.All_Sales


Derived table SQLThe derived table also containsa derived tableThe interior derived tablereturns the total of all salesacross all categoriesThe primary select uses theoverall sales total to calculatethe sales percentage bycategory



Derived table used as a fact table within the universeInclude in context when appropriate



Specify a databaseaggregation on the universeobject

Objects becomes a measureResults in object being omittedfrom GROUP BY in generatedSQLNo affect on results returnedfrom databaseAs there is only one row percategory, the databaseaggregations of avg, max, min,and sum can all be used



Within the query panel, theratio object is used as anyother object

Results returned are correct,the same as if a report variablehad been used

No further actions requiredfrom report author or adhocuser


Same objects used in querypanel as beforePass 1 - Result set of thisSELECT becomes known asCompany, which is used tocalculate the total overallsales that is then labeledAll_Sales.Pass 2 - Result set of thisSELECT becomes known asCat_Sales_Ratio, which usesAll_Sales from the first passto calculate the sales ratio bycategory.Pass 3 – Primary SELECTpulls results together with thecategory descriptions


SELECTMP_T1_Cat.Category, min(Category_Sales_Ratio.Cat_Sales_Ratio)

FROM MP_T1_Cat,( SELECT MP_T1_Sales.Cat_Id,(sum(MP_T1_Sales.Sales)/Company.All_Sales) as Cat_Sales_Ratio



GROUP BY MP_T1_Sales.Cat_Id,Company.All_Sales )Category_Sales_Ratio

WHERE (Category_Sales_Ratio.Cat_Id=MP_T1_Cat.Cat_Id )

GROUP BY MP_T1_Cat.Category



Category Sales Ratio only has meaning when usedCategory objectTwo concerns arise from this

Nothing forces the two objects to be used together in the querypanelNothing prevents the end user from deleting the Category columnfrom an existing report



Properties tab of a measure objectChoose how this measure will be projected when aggregatedOptions are: Average, Count, Max, Min, None, Sum

Avoid settings of Average, Max, Min, and CountDetermines report level aggregation after results returned by databaseNo affect on SQL generation or database aggregationDefault setting will be database aggregation used on the definition tab



For testing a region table isadded to the schema andincluded in the context

For all projection aggregateexamples, the same query isused



The initial results return data intwo blocks as the RegionName dimension is notassociated with the derivedtable containing CategorySales RatioWhen Category Sales Ratio isplaced into the same block asRegion Name, the projectionaggregate is used to determinehow to calculate the ratioacross category and region

As long as Category remainsin the report block, allprojection aggregates settingsreact the same



Projection aggregate of AverageSeven (7) categoriesSum of Category Sales Ratio is100%100% / 7 = 14.29%

Projection aggregate of CountSeven (7) categoriesAs field is formatted as apercentage, 700% is displayed



Projection aggregate of Maximum43.84% is largest ratio of allCategory Sales Ratio valuesBelongs to the Householdcategory

Projection aggregate of Minimum2.72% is the smallest of all theCategory Sales Ratio valuesBelongs to the Kids Kornercategory



Projection aggregate of SumSum of ratio across all categories is100%

Projection aggregate of NoneNo aggregate projection takes placeCategory Sales Ratio is notrecalculated or redistributedIn some aspects a setting of Nonecauses the Category Sales Ratio tobe treated as dimension once thecategory is removed

Original ratio values are maintainedpreventing Sales from beingaggregated to the region level



Compare with report variablesWithout the use of the ForEach,ForAll, Where, or In contextoperators a report variable will beprojected across all dimensions inthe report blockSales Percentage is by region andby category

If category is removed then ratio isby region only



Is Report Variable Multi-Pass?Initial passes are at the database levelSubsequent passes for calculations occur at the reporting tier

Utilize reporting tier for advanced functionalityDerived table utilizes the more traditional approach

All work done at the database


Advanced Calculations - Recap

Derived Table MethodReuse of formula via the Universe

Maintains one version of the truthEase of use as calculation is object available for query panelSingle location for maintenance if formula changesProjection aggregate controls behavior when associateddimensions not in report block

None or Sum should be used to maintain proper behavior

Report Variable MethodRecalculates according to dimensions in block

Context operators available if behavior is not desiredDoes not require Universe development to implement newcalculations


Grains of Measurement

Compare measures across timeframesCompare the number of units sold this month with the number ofunits sold last month

Business Objects offers many solutionsOne query for each timeframeCase statement parses date for appropriate timeframeMultiple SELECT statement generation

Focus on this solution



Traditionalist approachCreate a temp table withcolumns of Cat_ID,This_Month_Calls, andLast_Month_CallsInsert number of calls bycategory in table for the currentmonth

Insert number of calls bycategory in table for theprevious month

Select results for report

Drop table

CREATE TABLE This_and_Last(Cat_Id integer, This_Month_Calls integer,Last_Month_Calls integer)

INSERT INTO This_and_Last (Cat_Id,This_Month_Calls, Last_Month_Calls)SELECT MP_T1_Calls.Cat_ID,sum(MP_T1_Calls.Nbr_Calls), 0FROM MP_T1_Calls, MP_T1_Calendar

WHERE (MP_T1_Calendar.Month_ID =MPP_T1_Calls.Month_Id)and(MP_T1_Calendar.Month_Rpt_Desc ='CurrentMonth')GROUP BY MP_T1_Calls.Cat_Id

INSERT INTO This_and_Last (Cat_Id,This_Month_Calls, Last_Month_Calls)SELECT MP_T1_Calls.Cat_ID, 0,sum(MP_T1_Calls.Nbr_Calls)FROM MP_T1_Calls, MP_T1_Calendar

WHERE (MP_T1_Calendar.Month_ID =MP_T1_Calls.Month_Id)and(MP_T1_Calendar.Month_Rpt_Desc = 'Current Month- 1')GROUP BY MP_T1_Calls.Cat_Id

SELECT MP_T1_Cat.Cat_Id, Category,sum(This_Month_Calls), sum(Last_Month_Calls)

FROM This_and_Last JOIN MP_T1_CatON MP_T1_Cat.Cat_Id = This_and_Last.Cat_IdGROUP BY MP_T1_Cat.Cat_Id, CategoryORDER BY MP_T1_Cat.Cat_Id

DROP TABLE This_and_Last



Data inserted into thetemporary table containsseparate rows forThis_Month_Calls andLast_Month_CallsOnce pulled together forreport, results are correctProcess is very databasecentric

Very similar to the Sharing ofDimensions scenario



One query for each timeframeQueries usually identicalexcept for their filters



One query for each timeframeQueries usually identicalexcept for their filtersInitial results can be strange

Depends on SP levelDimensions are combinedMeasures are not





Report variables requiredUse measures from each queryMeaningful column headers





Report variables requiredUse measures from each queryMeaningful column headersVariables provide final results



One query for each timeframeQueries usually identical exceptfor their filtersInitial results can be strange


Report variables requiredUse measures from each queryMeaningful column headersVariables provide final results

Not a graceful solution for adhoc user; Burden placed onreport developerFor numerous requestsbecomes a tiresome processPrompts for each queryincreases potential forerroneous input



Need separate universeobjects which represent eachtimeframe

Removes filter from querypanelEliminate the need for reportvariables

Common solution: Use CASEstatement in object definitionto parse time span

Case statement parses datefor appropriate timeframe

Within timeframe, value isadded to the measureOutside of timeframe, zero isadded to the measure

One object for each timeframe



CASE based objects simplifyquery panel

No query filter neededNo promptsSingle query created by enduser

Single SELECT generated



CASE based objects return correct resultsIs this answer?NOIssue is performance

Every row in the fact table has to be read to determine if time span criteria is metFact table: 84 rows of which 15 meet time criteriaSQL Server Trace shows 85 reads occurring for SELECT using CASE objectsFor multiple query solution, SQL Server Trace indicates 37 reads per query



Combine the good of each approachSeparate objects for each timeframeEliminate query filtersMaintain performance

Force context for each timeframeAlias fact table for each timeframeMeasure objects from each aliased fact tableUtilize “Where” clause on measure objects



First, create alias for each factfor each timeframe

Alias for this month andprevious month

Insert joinsJoins to alias no different thanto original tableEnsure proper cardinality isidentified

Allows for automatic contextdetection

Access to alias tables will bedetermined by object filters



Create contextsUse Detect Context option in Designer if join cardinality has beenmaintainedDelete all contexts and regenerate as new dimension tables are addedor fact tables aliased for additional timeframes

Context created for each time based fact table aliasAlias table names are default names of contexts, so name aliases wisely



Create measures for eachtimeframe

Object names should reflecttimeframeSuch as This Month Calls andLast Month Calls

Where clause enforcestimeframe against the datetable

If moved to the join betweenalias and date table, thewhere clause only added tothe generated SQL whenobject from date table is alsoa result object in the querypanel



Alias based objects simplifyquery panel

No query filter neededSingle query created by enduserNo prompts

Correct results returned



Contexts result in separateSELECTs for each timeframeIf JOIN_BY_SQL setting isYes, then one SELECTstatement generated andderived tables created foreach timeframe

Database combines resultsets


Grains of Measurement - Recap

Alias fact table for each desired timeframeAll joins to each alias are identicalAll dimension tables joined to each alias

Create contextsMake use of Detect Context feature in Designer

Measure objects created from each alias reflecttimeframe

Where clause in object definition enforces timeframe


Semi-additive Measures

Additive MeasuresMost commonAggregation is applied consistently to all dimensionsMeasures roll up within a dimensional hierarchy

Semi-additive MeasuresSemi-additive measures are additive across some dimensionsBut are not additive across one or more of the dimensions

Time is the usually the exception dimensionOther aggregate functions such as average, minimum, maximum maybe valid over the dimension but not sum

ExamplesPeriodic measures such as account balancesLevel measures such as inventory and headcount



Traditionalist approachOLAP drivenNo relational solution beyond re-query of database

For Business Objects, only complete solution existsusing Web Intelligence

Desktop Intelligence can be used if drilling on the exceptiondimension is not required

Requires use of many featuresDerived tablesAggregate awarenessQuery drill option



Example will be based on 3 database tablesCalendar, MP_T2_Calendar, as a dimensionBase account table, MP_T2_Info, as a dimensionEnding balance by account by date, MP_T2_Account, as a fact



Need derived table to reflect last balance entered foreach account for each month

Date for balance entry should be last date of the month even ifentry is for an earlier dateUse Business Objects to create the required SQL



Create month end derivedtable by account

Returns latest date for eachaccount within the fact tableEntry in the ending balancetable only on those dayshaving activity



Sample results from using theaccount month end derivedtable

February 2006 month enddate for account 101 is2/28/2006February 2006 month enddate for account 104 is2/27/2006



Second derived table formonth ending dates

Used to force ending balancedates to be the same for allaccountsActual month end dates

Sample results from derivedtable

Month end for February 2006is 02/28/2006



Add derived tables to universeMonth end derived table is joined to calendar tableMonth end by account derived table is joined to the fact table



Resulting universe used tocreate query

SQL from this query will beused to create the derivedtable for the reportinguniverse

Sample results from queryAs previously seen, the lastending balance entry inFebruary 2006 for account104 was on 02/27/2006. Usingthe month ending date fromthe month end derived tablein the query has the monthend date show as 02/28/2006



SQL used for derived tablewithin reporting universe

Rename the account balancecolumn to reflect its monthending value



Add derived table for month end balance to universeBecomes a fact tableJoin additional dimension tables



Create Acct Ending Bal objectAggregate awareUses either the derived tableor the ending account balancetable

Setup aggregate navigationDerived table should not bereferenced if the CalendarDate object is part of thequeryIf Calendar Date is used thenthe ending account balancetable (MP_T2_Acount) isreferenced



Query to return month endingbalance for each account

Results are correctBalances within tableMP_T2_Acount are formattedas AYMMDD with:

A = account idY = yearMM = monthDD = day

Ending balance for account104 in February 2006occurred on the 27th while itoccurred for all other accountson the 28th



Generated SQL showsderived table being used

Drilling into time hierarchyrequires query drill to beenabled

Access the documentpropertiesEnable Use query drillDo not use Scope of Analysison the query panel



Drilling down to Year-Monthreveals balances by date

Query drill adds CalendarDate to the query

Since Calendar Date is nowpart of the query, aggregateawareness invokes thebalance ending table(MP_T2_Account) in place ofthe month end derived table



The next logical step is add more levels to the time hierarchyBuild a derived table for quarter ending balances

Modify the existing derived table for month ending balancesUse same technique used to develop month ending table

Add Year-Quarter object to the time hierarchy



Modify Acct Ending Bal objectAdd the quarter endingbalance table to the aggregateaware

Create the Year-Quarterobject



Add Year-Quarter object tothe time hierarchy

Alter the aggregate navigationThe new derived table forquarter ending balances is notcompatible with either theYear-Month object or theCalendar Date object



Query to return quarter endingbalance for each account

Results are correctRemember, balances withintable MP_T2_Acount areformatted as AYMMDD with:

A = account idY = yearMM = monthDD = day

Ending balance for account104 in 2006Q2 occurred onthe June 29th while it occurredfor all other accounts on theJune 30th



Drilling into Q2 shows the endingbalance for each account at theend of each month in Q2

Since Year-Month is now part ofthe query, aggregate awarenesswill use the derived table formonth ending balances instead ofthe quarter ending balances table

Drilling into June shows theending balance for each accountfor every day a transactionoccurred

Now that Calendar Date is part ofthe query, aggregate awarenesswill use the daily ending balancetable instead of the month endingderived table


Semi-additive Measures - Recap

Create derived table for each desired timeframeAll joins to each derived table should be identicalAll dimension tables joined to each derived table

Create contexts as a precautionObject definition for associated measure uses aggregateawareness to navigate across derived tablesCreate time dimensions that reflect granularity of derivedtablesSetup aggregate navigation such that each derived tableis compatible only with its time dimensionEnable Use query drill on the document properties withinWeb Intelligence

Do not use Scope of Analysis within the query panel


Data Subset

Analyze a subset of data against the wholeCompare the origins of most recent transactions to historicaltransaction origins – discover a change in user behavior

Analyze a subset of data that meet specific criteriaLocate latest status record of a customer, product and analyzethose that meet certain requirements

Business Objects offers many solutionsDerived tables used as a filter to obtain subsetSeparate queries for each subsetOr use Grains of Measurement methodology to refine


Data Subset

Traditionalist approachCreate a work table for mostrecent transaction date foreach accountObtain the most recenttransaction date for eachaccountCreate a work table for thehistorical and recenttransaction counts by channelInsert number of recenttransactions for each accountby channelInsert total number oftransactions by channelSelect results for report

Drop work tables

CREATE TABLE LAST_TRANS(Acct_Nbr char(16), Tran_Date date)

INSERT INTO LAST_TRANS (Acct_Nbr, Tran_Date)SELECT Acct_Nbr, max(Tran_Date)FROM checking_tran

GROUP BY Acct_Nbr

CREATE TABLE TRANS_COUNTS(CHANNEL CHAR(1), HIST_CNT INTEGER,RECENT_CNT INTEGER)

INSERT INTO TRANS_COUNTS (CHANNEL, HIST_CNT,RECENT_CNT)SELECT a.CHANNEL, 0, COUNT(a.TRAN_ID)FROM checking_tran a, LAST_TRANS tWHERE a.acct_nbr = t.Acct_NbrAND a.tran_date = t.Tran_DateGROUP BY a.channel

INSERT INTO TRANS_COUNTS (CHANNEL, HIST_CNT,RECENT_CNT)SELECT a.CHANNEL, COUNT(a.TRAN_ID), 0FROM checking_tran aGROUP BY a.channel

SELECT c.channel_descr, sum(t.HIST_CNT),sum( t.RECENT_CNT)

FROM channel_descr c, TRANS_COUNTS tWHERE c.channel_nbr = t.channelGROUP BY c.channel_descrORDER BY c.channel_descr

DROP TABLE LAST_TRANS

DROP TABLE TRANS_COUNTS


Data Subset

The LAST_TRANS work tablecontains one entry for eachaccount representing the lasttransaction date for thataccount.

The TRANS_COUNTS worktable contains separate rowsfor the historical and mostrecent counts


Data Subset

Once the results are pulled together from TRANS_COUNTS, thenumbers are correctProcess is very database centric

8 SQL statements sent to database2 work tables used to house temporary resultsVery similar to the Grains of Measurement scenario

Only worse


Data Subset

Derived table LAST_TRANSReturns most recent date foreach account number on whicha transaction took place

Add to universeJoin to the transaction tablechecking_tran.Acct_Nbr =LAST_TRANS.Acct_NbrAND checking_tran.Tran_Date =LAST_TRANS.last_date


Data Subset

Create a new filter objectSpecifies the join between thederived table (LAST_TRANS)and the transaction table


Data Subset

Does the filter work?List all transactions by account

Query returns all transactionsfor each account as expected


Data Subset

Does the filter work?Same query as before but withfilter object added

Query returns onlytransactions which occurred onthe most recent day for eachaccount


Data Subset

Generated SQL for the firstquery is fairly simple

Generated SQL for the secondquery is similar to the firstbut…

Derived table add to the FROMclauseFilter object enforces join in theWHERE clause which restrictstransactions to the most recentday for each account


Data Subset

Historical queryCount of transactions bychannel across all transactions

Recent transactionsSame as the historical querybut with filter object specifiedCount of transactions bychannel across the mostrecent transaction for eachaccount


Data Subset

Each query returns a separateblock

Counts for each channelcategory higher for historicalquery


Data Subset

Additional formatting requiredAdd percentage for eachchannelAdd additional header row toeach block to label which blockrepresents which count

Or with a bit more workCombine into a single blockAdd additional header row tolabel which count is whichAdd percentages


Data Subset

Solution #1Derived table returns most recent transaction day by accountJoin derived table to transaction history tableFilter object which references join between derived table andtransaction history table

Issues with current solution – Burden on report builderMultiple queries requiredExtensive formatting required once result sets are returned

Refinement to current solutionAlias transaction tableDerived table joined only to the transaction table aliasCreate contextsSeparate objects for historical and recent transaction countsSimilar techniques as used in Grains of Measurement scenario


Data Subset

Alias the transaction tableJoin same tables to the alias as joined to the transaction table itselfLAST_TRANS derived table is joined only to the aliasDetect/create contexts


Data Subset

Create channel classMove objects from thetransaction classAll objects reference thedimension tables joined to thetransaction table and the newlyaliased transaction table

New measure object whichcounts only the recent

Includes only the most recenttransactions for each accountWhere clause will enforce jointo the derived table(LAST_TRANS)


Data Subset

Single queryTrans Count counts alltransactionsRecent Trans Count countsonly the most recenttransactions on each accountNo filter required as it is part ofthe Recent Trans Count object

Initial ResultsSingle blockAppropriate column headers


Data Subset

Multiple SELECTs generatedMultiple SELECTs created asthe measures come fromseparate contextsFirst SELECT returns countagainst all transactionsSecond SELECT returns countagainst only the most recenttransactionsJOIN_BY_SQL rules still apply


Data Subset

Final formatted resultsUse the calculation wizard to add percentages to each measure

Can more be done?Use techniques in Advanced Calculations section to move percentagecalculations to the universe


Data Subset - Recap

Derived table used to identify data subset to be analyzedDerived table used as filtering mechanism

Solution #1Create filter object to force join to derived tableMultiple queries using filter object(s) when appropriateFormat report to properly label resulting figures

Solution #2Alias data table being segmentedCreate same joins to alias as to the original tableDerived table only joined to the aliasDetect/create contextsMeasure object from derived table forces join to derived table


Multi-Pass - Recap

Covered 5 different scenarios calling for multi-pass SQLSharing Dimensions Across Fact TablesCalculations Which Require End ResultsBlending Grains of MeasurementsNeed for Semi-Additive MeasuresAnalyzing a Subset of Data

Often not restricted to one solutionGood news….

Business Objects does not force you into a solutionBad news…

Business Objects does not force you into a solutionDecide where to place burden and to what degree

Think in terms of traditionalist approach to solve newsituations


Multi-Pass SQL

Questions?

Multi-Pass SQLmeetthetaylors.com/files/Multi-Pass SQL PPT.pdf · The additional features ease...

Documents

Transcript of Multi-Pass SQLmeetthetaylors.com/files/Multi-Pass SQL PPT.pdf · The additional features ease...