sap bw data modeling guide-part 2

7/28/2019 Sap Bw Data Modeling Guide-part 2

1/47

Page 1 of 1

www.SAPBWConsulting.comE-Mail:[email protected]

SAPBWDataDimension

Modeling

www.SAPBWConsulting.com

LonnieD.Ayers,PMPInthisGuide,WeCoverSomeofOurModelingGuidelinesforInfoCubeDimensions-PartII


2/47

Page 2 of 2


ShareonFaceBookPostonLinkedINTweetThisGuide

IntroductiontoDataModeling ........................................................................................... 4

TraditionalEntityRelationshipModeling ...................................................................... 4

SAPBWDimensionDesign................................................................................................... 8

FirstPassAtDimensionalModeling ...........................................................................................9Compoundkeys .............................................................................................................................. 16CombiningDimensions ................................................................................................................ 24

BroadDimensions........................................................................................................................................ 24OptimalFactTableSize................................................................................................................ 25LineItemDimensions................................................................................................................... 25OtherPerformanceEnhancementTechniques .................................................................... 25

Aggregates....................................................................................................................................................... 26DemographicCharacteristics.................................................................................................................. 26CategorizationDuringQueryRuntime ............................................................................................... 26TimeDependencyasCategorizationCharacteristic ..................................................................... 26DealingWithHistoricalDataChangesAKASlowlyChangingDimensions......................... 27

AdditionalCategorizationTechniques ................................................................................... 27Partitioning..................................................................................................................................................... 29DegeneratedDimensions.......................................................................................................................... 33

SAPExtendedStarSchemaDiagram ....................................................................................... 35

SAPBWConsultingDataModelingBestPractices .....................................................36KeyFigureBasedApproach........................................................................................................ 37Bottom-UpScenario ...................................................................................................................... 39

DeterminingDataFlows .....................................................................................................41

ModelingSAPBWMulti-Providers..................................................................................42

SAPBWConsultingDataModelingValueProposition .............................................44

Figure1PreliminaryInfoCubeDesign ............................. Error!Bookmarknotdefined.Figure2AircraftStructureSample-F-4Phantom........................................................................9Figure3TechnicalStructure ............................................ ............................................ .................... 10Figure4RelationshipofCharacteristicsinDimensionTables.............................................9Figure5M:NRelationshipofMasterData.......................... ............................................ ............ 10Figure6M:NRelationships:TwoDimensions......................................... .................................. 11Figure7M:NRelationship:OneDimension...................................... ......................................... 12

Figure8UseSE38toseeSAP_IINFOCUBE_DESIGN ............................................. ................... 15Figure9ExamineInfoCubeforLineItemApplicability.............................. ........................... 15Figure10CompoundMasterKeys.... ............................................ ............................................ ..... 14Figure11MultiProviderOverview......................................... ............................................ ............ 16Figure12AdditionalModelingFeatures............................................ ......................................... 17Figure13MoreModelingFeatures............................................... ............................................ ..... 20


3/47

Page 3 of 3



Figure14UnrelatedCharacteristicsintheSameDimension............................................. 21Figure15MixedDimension(1)........................................ ............................................. ................... 22Figure16MixedDimension(2)...................................................... ............................................. .... 23Figure17BroadDimensions............................................ ............................................ .................... 25Figure18CategoryDimensions...................................... ............................................. ................... 27

Figure19CategoryCharacteristic.......................................... ............................................ ............ 28Figure20Partitioning:ModelingFeatures ....................................... ......................................... 26Figure21PartitioningExample(1)....................................... ............................................ ............ 31Figure22PartitioningExample(2)....................................... ............................................ ............ 32Figure23DegeneratedDimensionorLineItemDimensions.......... .................................. 33


4/47

Page 4 of 4



IntroductiontoDataModelingIntraditionalEntityRelationshipModeling,thecoreconceptisverysimple.It

essentiallyboilsdowntothefactthatatanelementarylevel,athing,sayaproduct,isrelatedtoanotherthing,sayacustomer.Theentities,ProductandCustomer,inthiscase,arerelatedinsomeway.Therelationshipisthekeypoint,asitcanbeone-to-one,one-to-many,ormany-to-manyandistraditionallydenotedwiththefollowingsymbols.

One-to-One

One-to-Many

Many-to-Many

Tomaketheserelationshipsmeansomethingtothetwoentities,youneedakey,orawaytolinkthetwo.Aswewilldiscusslater,keysareeverything!

TraditionalEntityRelationshipModeling

Inhisbook,Case*Method:EntityRelationshipModeling,byRichardBarker,1990,thesubjectofEntityRelationshipModelingisdealtwithatlength.Notmuchhaschangedsincethisbookwaswritten,butIbelieveforanevenmorein-depthunderstandingyouwouldbewellservedbyreadingthebook,Data

ModelPatterns,ConventionsofThoughtbyDavidC.Hay.Inthissecondbook,youwillfinddatamodelpatternsforvirtuallyanybusinessscenarioyouareliabletorunacross.


5/47

Page 5 of 5



ThediagramaboveismeantonlytogiveyouanideaofwhatanEntityRelationship

Diagramlookslike.Inafullsizedsystemdesign,theERDmayhavehundredsifnotthousandsofentitiesallconnectedinasimilarfashion.WithoutattemptingtoprovideacompletetreatmentonEntityRelationshipModeling,Iwouldliketojustmakeyouawareofthefollowingfivepoints:

1. TheexistenceofMany-to-Many,denotedasM:M,usuallyindicatestheexistenceofanunidentifiedintersectionentity.Intheexampleabove,thismissingentitymightwellbePurchaseOrder,whichwouldhavebothheaderanddetailsectionentities.

2. ThereexistaconceptcalledNormalization,whichrangesfrom1stdegreeto5thdegreeofnormalization.Therearecertainmodelingpreceptsthatdictatewhichlevelyoumusttakethenormalizationtoo.

3. Therearemanymodelingconceptsthatdriveyoutointentionallyintroduceredundantnormalizationtechniques.


6/47

Page 6 of 6



4. WhenconvertingfromtheERDmodeltotheStarSchema,thestructureofrelationshipmodelingchanges,however,onekeyelementremainsofvitalimportance,theidentificationofandproperutilizationofPrimary,Secondary,CompoundandForeignKeyrelationships.WithintherealmofERD,thesekeysconnecttheEntities.WithintheStarSchema,theybecome

DIMID,andSIDIDs,andservethesamebasicpurpose.5. WithinERDmodels,thedatabasemanagementsystemtakescareofthe

indexesandinternalhashtables(acompleteseparateandcomplexsubjectitself)withfarlessinvolvementrequiredoftheDBA,althoughsomeremainsnecessary.WithintheSAPBWStarSchemabasedsystem,theefforttokeepthesekeys,i.e.,DIMandSIDkeys,requireseffortonthepartofthefunctionalSAPBWconsultant,theSAPBWBASISAdministratorandcanlargelybuttotallybeautomatedviaproperuseofprocesschains.

WhatisespeciallyimportanttorealizeisthattheuseofCASEorComputerAidedSystemEngineeringtools,ofwhichthereareseveralvendors,allowsyoutoquickly

modelnotonlytheEntityRelationshipDiagram,butaswell,theProcessFlowDiagram,FunctionHierarchyDiagram,andtodirectlygeneratecompletefunctionalsystemsfromthetools.ThisauthorsexpertisewasintheuseintheOracleDesigner2000toolset,nowmuchevolved,togeneratefullyfunctioningbusinesssystems.TherecurrentlyarenosuchtoolsfordevelopingSAPExtendedStarSchemasnorofgoingstraighttothefullyfunctioningsystemyouneed.Thereis,however,avastlibraryofwhatisreferredtoasSAPBusinessContentandacoupleofminimallyusefultoolsavailablefromSAPtonavigatetheSAPBusinessContent.ThisiswhyyoumusthaveSAPBWconsultantswhonotonlyknowtheSAPBWTool,butwhoalsohavereadandareknowledgeableofthecontentsoftheSAPBusinessContent,andcantranslatefromtheBusinessContenttoyourBusiness

Requirement.Withthisbriefbackground,whichifyoureadpartoneofourseriesonDataModeling,youwillbefamiliarwith,wenowmoveontoDimensionalModeling.


7/47

Page 7 of 7




8/47

Page 8 of 8


SAPBWDimensionDesignOneofthemostcriticalaspectsofSAPBWissystemperformance,mosttypically

experiencedbytheuserasqueryperformanceresponsetimes.Whetheritisfastorslow,fromauserperspective,itisneverfastenough!ThoughtherearemanyitemswhichyoucanreportonintheSAPBW,calledInfoProviders,oneofthemostinfluentialdesignelementsisthedesignoftheInfoCubeDimensions.ShownbelowisatypicalStarSchemaarrangement,inthiscase,foranairlinerouteprofitabilitysolution,whichisnotstandardSAPBWBusinessContentbutwillserveourpurposestoillustratehowtodesignefficientdimensions

Inourexampleabove,whichisnotdisplayedintheextendedStarSchemainorder

tofacilitatecommunicationbetweentheBusinessUserandtheBWConsultingteam(andisourBestPracticerecommendationforhowyoushoulduseitwheninteractingwithyourbusinessuser),youcanseethatwehavedefinedthedimensionsbasedontheirsemanticmeaning.Inlaymensterms,wehavegroupedcharacteristicsaccordingtowhattheusersawasrelatedorhavingarelationship.


9/47

Page 9 of 9



FirstPassAtDimensionalModeling

Inourfirstpassatdefiningthedimensionalmodel,wefirsthadtothinkaboutwhatwasrelatedinthebusinesscontextathand.Inthiscase,AirlineRouteProfitability,wedecidedthatonenaturallyrelatedsubjectareawithinAirlineRouteProfitability

wasaircraft.Aircrafthaveahighlydefinedstructuredefinedbygoverningagencies,suchastheIATAandFAA.Themilitaryhasaverysimilarsystem,andifyouknowhowtoreadtheaircraftdesignation,sayF-4CPhantom,youcaneasilydeterminethespecifictechnicalspecificationoftheaircraft.Intermsofdimensionalmodeling

Figure1AircraftStructureSample-F-4Phantom

thismeansyoucandefineadimensioninsuchawaythatcanyouassignorroll-upcost,fromthelowestlevel.InthecaseofAirlineRouteProfitability,thelowestlevelisaFlightSegment,flownbyaparticularaircraft,onaparticulardateandtime,withaspecificsetofpassengersandcargo,eachofwhompaidaspecificpriceandflewinaparticularclass,i.e.,1st,BusinessClass,EconomyClass.

Inourexamplebelow,wedefinedadimensionusingtheAircraftAllandAircraftSubTypeMasterDatatables.EachofthesetablescreatesaSIDorSurrogateIdentificationNumber,whichisanumberpresentinboththeexternalMasterDataTableandtheDimensionTable.ThisprocessisreplicatedforeachoftheotherDimensions.Inturn,eachDimensionTablehasaDIM(DimensionIdentificationNumber)whichislinkedtothecentralFactTableoftheInfoCube.


10/47

Page 10 of 10



Figure2TechnicalStructure

Inordertominimizequeryresponsetime,oneofthemostimportantdecisionstheBWConsultantmustmakeishowtoassignthevariousCharacteristicstothedimensiontables.Ideally,therelationshipis1:N(One-to-ManyorEachMothermay

haveoneormorechildrenbuteachchildcanhaveonlyonebiologicalmother,thoughtheymayhavemanymothers).Inadimension,foreveryuniquecombinationofCharacteristicSIDs,i.e.,AircraftSubType,AircraftAll,thereisauniqueDIMIDassigned.Atanygivenpointintime,thismeansthereisonlyonesingleDIMIDassignedforthatrow.However,ifthecombinationofSIDValueschangesatalaterpointintime,anewDIMIDwillbeassigned.Inthiscase,youhaveaN:Mor(Many-to-ManyrelationshiporEachAircraftcanflyoneormoreroutesandeachroutecanbeflownbyormoreaircraftsubtypes).Thesesituationstypicallywillresultinlargedimensiontablesandsluggishperformancefromtheuserperspective.Youwanttoavoidthisatallcost.

InadditiontotheDIMIDasthekeyofthedimensiontable,thereisonecolumnforeverycharacteristicinthedimensiontable.ThesecolumnscontaintheSID(SurrogateID)valuesforeachcharacteristicvalue.TheactualcharacteristicvlaueisthekeytotheSIDtable.TheseSIDvaluesareassignedtothecorrespondingcharacteristicvaluewhenmasterdataisloadedtothemasterdatatables.Inturn,


11/47

Page 11 of 11



whentransactiondataisloadedtotheInfoCube,theappropriateSIDvaluesforthecharacteristicvaluesofthetransactionareplacedinthedimensiontables.

ThemaximumnumberofentriesofinthedimensiontableisthecartesianproductofallSIDs.Forexample,ifthereare1000flightsand1000routes,thecartesianproducthas1,000,000possibleentriesinthedimensiontable.

Figure3RelationshipofCharacteristicsinDimensionTables


12/47

Page 12 of 12



Figure4M:NRelationshipofMasterData


13/47

Page 13 of 13



AlthoughitistechnicallypossiblethatallpossiblecombinationsofCharacteristicscouldbeloaded,thatnormallydoesnthappennorisitislikelytohappen.AstheBWConsultantyouneedtoevaluatewhatsortofdatacombinationsarelikelytoactuallybeloadedduringactualdataloadsgiventheBusinessProcessFunctionalityanddesignitsothatlargedimensiontablesdonotoccur.Inmostsituations,M:Nrelationshipsmeanthatthereisamissingintersectentityandthatthetwocharacteristicsshouldbestoredindifferentdimensions,forexampleAircraftandRoute.Thissortofrelationshipisnormallydefinedbyfactsorkeyfiguresthatarisewhentransactionsoccur,i.e.,flights.

IncompaniesthatusestandardSAPfunctionality,forexample,theFlightObject,whichcanbeusedtotrackplannedandactualflightoperationswithintheSAPIndustrySolutionforbothDefenseForcesandtheAirlineIndustry,severaltypesofflightsareoftenusedforeverytypeofairplane(orvoyagesforshipsortrucksortrains).Thissortofeventprovidesinformationthatreflectscharacteristic

Figure5M:NRelationships:TwoDimensions


14/47

Page 14 of 14



relationshipsthatexistatthetimeoftransactionorevent.Thistypeofsolutioncanhelpyoucaptureboththecostofaflight,aswellaswhetherittookoffontime,landedontime,orinthecaseofmilitaryoperations,whattypeofweaponsitdepartedwithandwhatkinditlandedwith.

Inmostcases,thealternativemodelingoptionistomodeltheN:Mrelationshipinonedimension,butthiswillnotbethebestsolution.

Afteryouhavebuiltyourmodel,andloadedsomedata,youshouldchecktheactualnumberofrecordsloadedinthedimensiontableversusthenumberofrecordsloadedinthefacttable.Thegeneralruleofthumbisthattheratioofdimensiontablerecordstofacttablerecordsshouldbebetween1:10to1:20.Ifyoucankeepyourratioswithinthisrangeyouwillendupwitharelativelysmalldimensiontableandlargerfacttable.

Figure6M:NRelationship:OneDimension


15/47

Page 15 of 15



Todeterminethisratio,youwillneedtogotoTransactionSE38,andunderprogramtype,enterSAP_INFOCUBE_DESIGNandexecute.

Figure7UseSE38toseeSAP_IINFOCUBE_DESIGN

Figure8ExamineInfoCubeforLineItemApplicability


16/47

Page 16 of 16



Compoundkeys

Inordertofacilitatetime-dependentreporting,itissometimesnecessarytousecompoundkeys.Inordertomodelacompoundkey,thereisacheckboxforcompoundkeysintheInfoObjectCharacteristic.Thesespecialattributesthenformthefirst,orsuperior,portionofthecompundkey.Thecharacteristicvalueitselfformsthesubordinateportionofthekey.Compoundkeysformasinglekeyofacharacteristicduringthestagingprocess.Therefore,whendataisextractedforthischaracteristic,valuesforeachofthekeycompoenentsmustbeavailableforextraction.ForbothMasterDataandTransactionalDataLoads,thisholdstrue.

Figure9CompoundMasterKeys


17/47

Page 17 of 17




18/47

Page 18 of 18



Figure10MultiProviderOverview


19/47

Page 19 of 19



Figure11AdditionalModelingFeatures


20/47

Page 20 of 20



Figure12MoreModelingFeatures


21/47

Page 21 of 21



Figure13UnrelatedCharacteristicsintheSameDimension

IfyoumergetwosmallDIMtables,yougetaslightlylargertable,butitmeansthatonlyonetablehastobeaccessedwhendataisloadedoraqueryisexecuted.Of

course,youwouldnotwanttoplacetwostrong(suchasMATERIALandCUSTOMER)inthesamedimensiontable.Inthemajorityofcases,13dimensiontablesaremorethanenoughforyourmodelingneeds.Theruleofthumbistogroupcharacteristicswithaparent:childrelationshipinthesamedimension.ThisassumesthatthisgroupingdoesnotincludeanyN:Mrelationships.Ifitdoes,thisassumesthatthecartesianproductofsuchagroupingisacceptablefromaperformancestand-point,asillustratedinthenexttwofigures.


22/47

Page 22 of 22



Figure14MixedDimension(1)

CharacteristicswithanN:Mrelationshipcanbecombinedinthesamedimension;ifthemaximumnumberofrecordsareclearlydefinedandthecartesianproductof

thecharacteristicresultsinonlyasmalldimensiontable.


23/47

Page 23 of 23



Figure15MixedDimension(2)

Intheexampleabove,thecharacteristicsVERSIONandCOLORhaveanN;Mrelationship.Nevertheless,theycanbeusedinthesamedimensionbecausethe

maximumnumberofrecordsis3X4=12.Characteristicswithalargenumberofvaluesreceiveaseparate(lineitem)dimension(material,customer).ModelingScenario:ThePRODUCTcharacteristichastheattributesPROMOTIONCHANNEL(TV,Radio,Newspaper,andsoon)andSalesOrganization(Hamburg,Bremen,Munich,andsoon).TheSalesOrganizationandPromotionChannel combinationchangesfrequently.Inthiscase,youshouldnotmodelthesematerialpropertiesastime-dependentattributes.YoushouldinsteadmodelthemascharacteristicsintheInfoCube.Usingthistechnique,youcanavoidhavingtouselargeattributetableswhenmakingyourselection.TheAttributescombinationissavedintheDimensionTables


24/47

Page 24 of 24



CombiningDimensions

Insomecases,forperformanceenhancementreasons,youmaywanttocombinetwosmalldimensions.Thiscombineddimensionmeansthatthetableonlyhastobeaccessedoncewhendataisloadedoraqueryisexecuted.However,youwouldnotwanttocombineaDimensionthatcontainedtwostrongentities,suchasAircraftandRoute.Besidesthe3defaultDimensionTablesthateachInfoCubecomeswith,the13DimensionTablesprovideplentyofdimensionforallbutthemostcomplexofsituations.Thegeneralruleofthumbwhenmodelingistogroupcharacteristicsthathaveaparent:childrelationshipinthesamedimension.ThisassumesthegroupdoesnothaveanyN:Mrelationships(Many-to-Many).IfitdoeshavetheseN:Mrelationship,theycangenerallybecombinedwhenthecartesian

productoftheseN:Mrelationshipsresultinalow,fixednumber,forexample,AircraftwithalimitednumberofAircraftSubtypesavailable.Whenthecomplexityorotherreportingrequirementsrequireit,youcancreateMulti-Providers,whichwilldiscussshortly.

BroadDimensions


25/47

Page 25 of 25



Figure16BroadDimensions

OptimalFactTableSize

Ingeneral,arelationshipof10-20-1betweenthesizeofthefacttableandthesizeoftheDimensionTableisdesirable.Thismayormaynotbepreciselypossible,butingeneral,yourdesignshouldresultinasmallDimensionTableandLargeFactTable.Ifnot,youwillfindperformancegraduallybutcontinuallydegrading.

LineItemDimensions

Note:TheremaybecaseswhereyouwanttodefineaLineItemDimension.A

typicalexampleiswhenaRetailcompanywithalargenumberofcustomerswouldplacetheCUSTOMERcharacteristicinaseparatedimensionandmakeitaLineItemDimension.

OtherPerformanceEnhancementTechniques


26/47

Page 26 of 26



Aggregates

AggregatesarereallysmallInfoCubes,asubsetofanexistingInfoCube.Thesystemcanrecommendaggregatesandyoucandesignateaggregatesmanually.Atypicalexamplewouldbeprofitabilitybyroutebyregion.Theaggregatewouldhavethis

totaledalready,andthiswoulddecrease(makeitfaster)yourqueryresponsetime.

DemographicCharacteristics

Demographiccharacteristicscanbeusedtocategorizealargenumberofcharacteristicswithlargevaluesets.Categorizationmeansyouuseasmallnumberofcharacteristicstogroupalargenumberofothercharacteristicsintosmallergroups.Themajorbenefitofcategorizationisinreducingtheamountofdatathatmustbepresentedinaqueryresultorthatmustbehandledduringdatastagingand

storage.InSAPBW,thiscategorizationcanbedoneinseveralwaysandatseveraltimes.Indatastaging,thelogicconvertsacharacteristicvalueforMasterDataorTransactionDataintospecificcategoryvaluesforstorage.Youcanusethelogicin:

TransferRules UpdateRules

EachRouteflowncouldbeconvertedintoaGroupofallflightsflownbydifferentaircraft.

CategorizationDuringQueryRuntimeYoucanalsousecategorizationduringqueryexecution.Thetechniquewouldbetouseacategorizationcharacteristic,likeCustomerClass,versusreportingaseparaterowinthereportforeachindividualreport.Todothis,onemethodwouldbetouseanavigationattributeorHierarchyinthequeryinsteadofthecharacteristicfoundinthedimensiontableofanInfoCube.

TimeDependencyasCategorizationCharacteristic

AsthetimedimensionisprovidedbydefaultforeveryInfoCube.Itisthereforeoneoftheeasierwaystoreduceyourqueryresultset.Byreportingonatime-dependentattributeinsteadofthecharacteristicitself,datasenttothequeryresultisrestrictedtojustthosevaluesthatvalidonthekeydataofthequery.Supposeyouwantedtoreducethenumberofrowsinadimensiontojust3?Intheexampleabove,wecreateacategorydimensionthatcontainsthecharacteristic


27/47

Page 27 of 27



IncomeBracketinsteadofactualcustomernumbers.Whenyouloadtransactiondata,thecustomernumberisusedderivetheincomebracketusingaformula.Youcouldalsoderivetheincomebracketwhenthecustomermasterdatawasloadedandstorethatvalueasanattributeofthecustomer.ThiswouldsignificantlyreducethetimerequiredtocalculatetheIncomeBracketforeachtransactionsinceitcould

bereaddirectlyfromthecustomernumber.Then,inaquery,IncomeBracketisusedtocategorizecustomerdataintooneofthethreecategories.

DealingWithHistoricalDataChangesAKASlowlyChangingDimensions

Customerssometimeschangeincomelevelsandtherefore,wouldneedtoberecategorized.Thereareatleast2possiblewaystodealwiththis.

Haveincomebracketsasanattributeofthecustomer StoreitintheCustomerdimension

AdditionalCategorizationTechniques

Youcanfurtherenhanceperformance,sometimes,byplacingcategorizationattributesindimensionsascharacteristicsthemselves.ThisreducestheOLAPprocessingloadbecauseyouhaveeliminatedtheloadofdealingwithnavigationattributes.

Figure17CategoryDimensions


28/47

Page 28 of 28



Example:CategoryCharacteristic

IncomeBracket IncomeRange

A USD0to$50,000.00B USD$50,001to$100,000

C MorethanUSD$100,000Figure18CategoryCharacteristic

AcategorydimensionthatcontainstheIncomeBracketcharacteristicinthisexampleinsteadoftheactualcustomernumberwouldreducethenumberofrowsofdatainthedimensiontoamaximumofthreerows.W.henyouloadtransactiondata,thecustomernumberisusedtosearchforthecustomerattributeoftheIncome.TheIncomeBracketvaluecanthenbederivedfromaformula.Another

optionwouldbetoderivetheIncomeBracketvaluewhenthecustomermasterdatawasloadedandstorethevalueasanattributeofcustomer.ThiswouldsignificantlyreducethetimerequiredtocalculatetheIncomeBracketforeachtransactionsinceitcouldbereaddirectlyfromthecustomernumber.Inaquery,theIncomeBracketisusedtocategorizecustomerdataintooneofthethreecategories.


29/47

Page 29 of 29



Ifthecategorizationchanges,youneedtoaskhowthehistoricaldataistoberepresentedafterthechange(slow-changingdimension).Fromananalyticalpointofview,theattributesintheCategoryDimensionhavetobestoredintheMasterDataTableoftheCategorizedCharacteristic.UseAggregateswithCategoryAttributestofurtherimprovequeryperformance.Ifacustomermoves

fromoneincomebracketcategorytoanother,howdoyoumodelthischangeinthehistory?Wehavealreadydiscussedtrackinghistory.Fornow,itissufficienttosaythatthereareseveraloptionsastohowaCategoryCharacteristiccouldbeused.TwoobviousexampleswouldbetohaveIncomeBracketsaseitheranattributeofCUSTOMERorinadimensionalongwiththeCUSTOMERCharacteristic.Eachoftheseapproacheswouldchangehowhistoricaltransactiondataisreported.

Partitioning

Intheexamplepresentedintheabovefigure,thereisaVersioncharacteristicwiththreevalues:

Figure19Partitioning:ModelingFeatures


30/47

Page 30 of 30



Actual Plan Forecast.

ThecharacteristicVersionisinaseparatedimensiontable.ThisdimensioniscalledaPartitioningDimensionsinceitisnowusedtopartition,orseparate,values

storedforthetwobasicfacts: Sales Units

BecausethevaluesofVersionarestoredasmasterdata,itisveryeasytoaddotherscenarios,forexample,aquarterlyforecastormonthlyplans.ThisonlyinvolvesaddingtheadditionalmasterdatavaluesandthenprovidingtheassociatedlogicfordeterminingtheappropriatevalueforVersionintheupdaterulesforthetransactiondata.Thissolutionhastheeffectofusinganadditionalkeyfieldtosortfacttablerecords.TheBIContentInfoObject0VALTYPEisfrequentlyusedforthispurpose.OtherexamplesforsuchcharacteristicsarethePlanActualIndicatorortheValueType.

InBIContentFI/CO(FinancialandControlling)InfoCubes,theactualdataisusuallysavedseparatelytotheplandata.Ifneeded,MultiProviderscanbeusedtoprovideconsolidatedreports.ThisisanexampleofamodelingwithseveralkeyfiguresintheFactTable.Whilethereisnothinginherentlywrongwiththisapproach,itisveryinflexibleifthecategoriesused(Current,Plan,Forecast)changeovertime.Ifchangesarenecessary,anewInfoCubemustbecreatedwithnewKeyFigures,anddatamustbereloadedordeletedfromanexistingInfoCube.Furthermore,thestructureoftheFactTablemustbechangedandthedatamustbereloaded.Eitherway,thatcould

beanexpensiveandtimeconsumingprocess.


31/47

Page 31 of 31



Figure20PartitioningExample(1)


32/47

Page 32 of 32



Figure

21

PartitioningExample(2)

Inthisexample,onlytwokeyfiguresareusedintheFactTable.AnewdimensionwiththepartitioningcharacteristicVERSIONisadded.

AnynewvalueforthecharacteristicVERSIONcanbeusedtoenhancethereportingwithoutchangingthedatamodel.Normally,itmakessensetocombinetogetherKeyFigurevaluesacrosspartitioningcharacteristicvalues.Forexample,thesumofActualSalesandForecastSalesisnotausablenumberforanalysis.Inordertopreventthisfromhappeninginaquery,asettingcanbemadeinthepartitioningcharacteristic.IfthevalueUniqueforEveryCellhasbeenselected,thecharacteristicmustberestrictedtoonlyonevalueineverycolumnandineverystructureforallthequeries.Thecharacteristiccannotthenbeaggregated.Therefore,characteristicvaluescannotbeusedtoaggregatethekeyfiguresinceitisrestrictedbythecharacteristic.


33/47

Page 33 of 33



DegeneratedDimensions

Figure22DegeneratedDimensionorLineItemDimensions

ADegeneratedDimensionisalargedimensiontablethatisapproachingthesizeoftheFactTableasameasuredbythenumberofrowsinthetables.ThisscenarioistypicallybadforqueryperformancesincetheOLAPProcessormustjointhetwolargetablestoselecttherowsofdatarequiredfromtheFactTable.InaDegeneratedDimensionwithordernumbersasmembers,alldescriptiveattributesarelocatedinotherdimensions.InBW,suchaDegeneratedDimensioncanbemarkedasaLineItemDimension.Bydoingso,whenactivatingtheInfoCube,noactualdimensiontableiscreated.Therefore,insteadofusingtheDMIDforthisdimensioninthekeystructureoftheFactTable,theSIDoftheDegenerateddimensionisthenplacedintheKeyStructureoftheFactTablebythesystemwiththefieldnameRSSID.ThiscanbeviewedusingtransactionSE11forthetable/BIC/F.


34/47

Page 34 of 34



ThiseliminatesaTableJoinandthusimprovesqueryperformance.IfonlyalimitedhistoryofLineItemDetailisrequired,aDataStoreObject(DSO)shouldbeconsideredasanalternativetotheInfoCube.ThesettingforLineItemDimensionsissetbychoosingtheDimensionsiconon

theCharacteristicstabofInfoCubemaintenance.ThismustbedoneintheInfoCubebeforeanydataisloadedintotheInfoCube.OntheDefineTabforcreatingdimensions,thereisacheckboxformarkingadimensionasaLineItemDimension.DimensionssetasLineItemDimensionscanonlycontainonecharacteristic.Thisisbecausetheremustbea1:1relationshipbetweentheSIDvalueofthecharacteristicandtheDIMID.Ifthereweremorethanonecharacteristic,thenthis1:1relationshipwouldnotexistanditwouldbeimpossibletousetheSIDofthecharacteristicinplaceoftheDIMIDintheFactTablekey.ItisrecommendedthatyouuseDSOs,wherepossible,insteadofInfoCubesforLineItems.AnothersettingavailableadjacenttotheLineItemDimensionsettingistheHighCardinality

setting.DimensionscontainingmanyuniquevaluesaresaidtohaveaHighCardinality.Insuchcases,certaintypesofDimensionIndexesareeasiertomaintainthanothers.TheHighCardinalitysettingisusedtochangethemethodfordimensionindexinginOracleDatabasesOnly .

TheindicatordefineswhichtypeofIndexshouldbeused: Lowcardinality(BitmapIndexiscreatedwheredimension

valuesareoftenrepeated) Highcardinality(B-TreeIndexarecreatedwherevaluesare

notoftenrepeated)Switchontheflagifthedimensionsizeis>10%oftheFactTablesize.

UsetheoptioninconjunctionwiththeLineItemDimensionYouhavenowseenhowtomodelandoptimizevariousaspectsofSAPBWInfoCubeDimensions.Towrapthisup,wenowprovideyouwithanextendedoverviewoftheSAPExtendedStarSchemaDesignandsomeofourSAPBWDataModelingBestPractices.


35/47

Page 35 of 35



SAPExtendedStarSchemaDiagram

WhatismostsignificantaboutthisapproachisthatdataisnolongerstoredintheDimensionTables.Instead,MasterDataandattributesofMasterData,suchasCustomerandCustomerAddresses,arestoredinexternaltablesandlinkedtotheDimensiontablesviaSIDorSurrogateIdentificationNumbersandtheDimensionsarelinkedtotheFactTableviaDIMIDorDimensionIDNumbers .Thisapproachoffersseveralbenefits,themostimportantofwhichisthatNOdataotherthankeysisstoredindimensiontables.Thismeansyouonlyhavetoloadandstoredata,i.e.,customernameandaddress,onceanditcanbeusedinother

InfocubesorInfoproviders.WithanestimatedlosstotheU.Seconomyofmorethan$600,000,000,000.00(yes,billion)frombaddata,thisisacriticalimprovementandoneofseveralmethodsbeingusedtoreducedataerrors.ThechallengefacingallSAPBWDataModelersishowtotransformtheentityrelationshipmodeltotheSAPExtendedStarSchema.ThemethodSAPrecommendsistotransformtheERDintotheBubbleModel,asshowninthenextdiagram.Inthiscase,IhaveusedamodeloftheAirlineRouteProfitabilitymodel,whichisnotpartofthestandardSAPBusinessContentbutisofcriticalimportancetotheAirlineIndustry!ItisalsoapplicabletotheTransportationIndustryingeneral,including3PL(3rdPartyShippers),Railroadoperators,Ships,Ferrysand

Buscompanies.ForthepurposeofintroducingSAPBWConsultingExtendedStarSchemaBestPractices,itwillserveourpurposesjustfine.


36/47

Page 36 of 36



AirlineRouteProfitabilityBubbleDiagram

InourBubbleDiagramabove,wehavesevendimensionsdefinedaroundacentralfacttablerelatedtoRouteProfitability.Forthepurposesofclarity,wehavenotshownthattheMasterData,say,forFleet,isstoredinexternalMasterDataTables.

SpecialNotetoExperiencedOracleEntityRelationshipModelers:YoumayrecognizethatthetypicalscenariousedforteachingERDistheairlinereservationsystem.Pleasebeawarethatthismodel,AirlineRouteProfitability,isnotthesamemodelalthoughtheprinciplesarethesame.Infact,youwillnotfindagenerallyavailablepublicmodeloftheAirlineRouteProfitabilitymodelaseachairlinedoesthisinuniquewaysandconsiderittheirmostcriticalmeasurementofmerit.

SAPBWConsultingDataModelingBestPracticesTherearetwobasicapproachestoSAPBWDataModeling:


37/47

Page 37 of 37



1. TheTopDownKeyFigureBasedApproach2. TheBottomUpDataSourceApproach.

ThemainapproachyoushouldfocusonusingistheTopDownKeyFigurebased

approach,especiallywhenperformingyourBusinessContentcheck.KeyFigureBasedApproach(TopDown)

DataSourceApproach(Bottom

Up)

Getaclearunderstandingofyourlogicaldatamodel

FocusontheBusinessProcessof

yoursystem

Breakdownthegranularityofyour

performanceindicatorstobasickeyfigures

CheckyourDatasourcesforparticularmeasures(KPIs)

FindandcompareyourbasekeyfigureswiththeBusinessContentRepository

LookupDataSourceforCharacteristicsdefinedin

dimensionsinyourlogicaldata

model

ComparetheScenariosofyourlogicaldatamodel

withtheBusinessContentInfocubes,QueriesandWorkbooks

UnderstandhowBusinessContentmapstothefieldsyou

foundtoInfoObjects

Checkforperformanceindicators(KPIs)inBusinessContentQueries

Investigatethedataflowforidentified

keyfigures

KeyFigureBasedApproach

TheKeyFigurebasedapproachlookslikethebelowdiagraminprocessflowform.

KeyFigures

Infocube

InfoSources

Infocube

InfoSource

InfoObjects

DataSources


38/47

Page 38 of 38



ThemainapproachduringtheBusinessContentcheckshouldbea

top-downapproach.IfthesearchforcorrespondingKeyFiguresisnotsuccessful,abottom-upapproachinthespecialcasemaybethebestsolution.

Youmustunderstandthebusinessconceptbehindthismodel.Technicaldescriptionswillneverreveala100%solution

KeyFigures(alsoknownasPerformanceIndicatorsormeasures,dependingonthecultureyouareworkingin),maybeavailableinthe

businesscontent,andyouwillnormallyfindthemmodeledasCalculatedKeyFigures.IfyoudonotfindaKPIthatexactlymatchestheKPIyouarelookingfor,itmayonlymeanthateither:1.Itisavailablebutiscalledsomethingelse2.ThecomponentsneededtocreateyourKPIsmaybelocatedinseparatepieceswithinyourBusinessContentorarelocatedinMulti-providers.

A.Asyoucansee,thisindicatesandvalidateswhyyoumust

havespentaconsiderableamountoftimeunderstandingyourownbusinessandtheSAPBusinessContentinordertodevelop

avalidmodel!

ThereisaSAPBusinessContentBrowseravailableintheSAPBWBusinessContent,butitisnormallynotinstallednoravailable,unfortunately.Allofthepubliclyavailablebusinesscontentislocatedathelp.sap.comunderSAPNetweaver.Itisnolongeravailableinonespotnorasaseparateoff-linepdfdocument,soit

UnderstandLogical

DataModel

DeineKeyFigures

Find

BusinessContent

CompareBCto

LogicalModel

DetermineDataFlowforKPIs


39/47

Page 39 of 39



requiresagreatdealoftimetofind,studyandemployinyourenvironment.

WhenanalyzingSAPBusinessContent,focusonthefollowingissues:1.BusinessContexttocompareBusinessScenarios.Oftentimes,unrelatedbusinessareas,havemodelsthat,atheart,lookthesame

andcanbeleveraged.2.CheckCompounding,DimensionsandtheavailabilityofKeyFigures.Forinstance,KeyFiguresrequiredtocomputeyourKPIsmaybeavailableinMulti-Providersorcouldbemodeledthatway.InvestigatewhetherDimensionswithinInfocubescanberedefinedasnavigationalattributes.

VerifythatBusinessContentKPIsarecalculatedthesamewayyourKPIsneedtobecalculated.

Investigateandunderstandallprovideddataflowsandextractors.Extractorsmayneedtobeextendedtoprovideallthedataelementsrequiredforyourscenario.

Bottom-UpScenario

TheBottom-UporDataSourcebasedapproachlookslikethebelowdiagram.TheuseofthebottomupapproachmainlydependsonwhetheryouarerunningaSAPR/3drivensystem(meaningmostifnotallofyoursourcedatawillbecomingfromoneormoreSAPR/3systems)

R/3isPrimarySourceSystem?

FindDataSources

FindInfoObjects

FindInfoSources

FindInfoCubes

FindQueries


40/47

Page 40 of 40



1. Assumption:ProjectisbasedprimarilyonSAPR/3orR/3isatleastpartofthesourcedsystems.Ifeitherofthetwoconditionsarethecase,thenthebottomupapproachisrecommended.

2. ThemajoradvantageofthisapproachisthatthecustomeralreadyspeaksorshouldbevaguelyfluentinSAPenese.WhatisSAPenese?Well,itisthe

specializedlanguageoftheSAPsoftwaresystem,whichsoundslikespacealienstalkingwhenoutsidershearit.Likeanyspecialty,suchasaviation,auniquelanguageevolvesandSAPeneseistheresult.FortheSAPBWconsultant,thisgreatlyfacilitatesconversationsaboutbusinessrequirementsandallowsyoutofindrelativeSAPBusinessContentfareasierthanintheTopDownapproach.

3. OnceyouhaveanalyzedtheSAPDataSources,meaningyouhavetakenalookat,forexample,howPurchaseOrdernumberrangesaredefinedintheMaterialManagementIMG(ImplementationManagementGuide),youcanfindcorrespondingInfosources(andextendthemifnecessarytosupportyourscenario).

4. Thereisanearly100%chanceyoursystemenvironmentwillnotbepurelySAP.However,ifyoucanfindwhatyouneedinSAPandfindthecorrespondinginfosourceequivalentsintheothersystems,itisfareasiertomatchthedatatypesandgetthemintoSAPBW.IfyouareinamixedOracleandSAPenvironment,thereareseveralthirdpartyvendorswhohavedonethemappingandmatchingforyouandwerecommendyouinvestigatetheirusage,budgetpermitting.


41/47

Page 41 of 41



DeterminingDataFlows

Yourdatamodelwilldetermineyourrequireddataflow.Oncemodeled,youcanalwaysviewyourdataflowusingthemetadatarepositorybrowser,whichprovidesyouasnapshotofyourend-to-enddataflow.

BusinessContentCheck

TransactionDataMasterData

Enhancements

SourceSystem(DataSource)TransferRulesUpdateRulesGenericDataSource

AdditionalInfoProviders

DataConsolidationDataQualityManagement


42/47

Page 42 of 42



ModelingSAPBWMulti-Providers

ASAPBWMulti-ProviderisusedtocombinedatafromInfoproviderandtomakeitavailableforreporting.TheMulti-Providerdoesntactuallycontainanydataitselfasitismoreorlessequivalenttoadatabaseview.ThedesignofeffectiveMulti-ProvidersiscriticaltosuccesswiththeSAPBusinessWarehouse.DuringtheRequirementsAnalysisphaseofyourSAPBWproject,youmustdecideuponthefollowingdesignelements:

GranularityoftheData

TimeGranularity(Thiscanrangefromsecondstoyears) Aggregatedordetaileddata Snapshot/Inventory

DataVolume NumberofDocuments NumberofProducts NumberofYearstoreporton(History)

RequiredAnalysisFeatures

Granularity

DataVolume

Analysis


43/47

Page 43 of 43



AnalysisMethod Multi-dimensionalorFlatFileReporting(oracombinationofboth) RequiredResponseTimes Urgency Real-Timeorsomelagtimeallowed

Theabovediagramshowshowyoucanconnectvirtuallyanytimeofinfoproviderintoamulti-provider.Eachparticularanalyticrequirementwillinvolveslightlydifferentconnectionsamongthevariousproviders.Thesecretistoprovidewhattheuserneedswithoutboggingdownthesystemwithtoomuchdata.


44/47

Page 44 of 44



SAPBWConsultingDataModelingValueProposition

ThisispartoneofaseriesofHow-ToGuidesweprovideonSAPBWDataModeling.WewillprovideacompletetreatmentofthesubjectinaseriesofupcomingHow-Toguides.ThisisoneofthemostcriticalareasofknowledgefortheSAPBWconsultant.Fromacustomervalueperspective,itisTHEMOSTCRITICALASPECTofyourBWsystem.

Withoutasolid,robustdata-model,youwillnotbeabletobuildorusethequerysyourbusinessusersneed.AsSeniorLevelSAPBusinessWarehouseConsultants,wearefrequentlyconfrontedwiththefollowingquestionsfromrecruiterswhichiswhywebelieveyoushouldbeusingourservices.QuestionswhichindicatelackofknowledgeandforwhichonlydeepSAPBW

expertisecananswer.

1. Doyouworkonthefront-endorback-end?a. IftheData-modelisnotdesignedproperlytosupportyourcurrent

analysisrequirements,bydefault,theSAPBWConsultanthastoworkonboththefront-endandback-endofthesystem.Fromapurely


45/47

Page 45 of 45



technicalstandpoint,thereisnosuchthingasfrontandbackend.Thereareonlycomponentsthatprovidevariousrequiredfunctionalities.

2. DoyouspecializeinaparticularSAPBW-SAPfunctionalarea?Translation:DoyouknowSAPFinancials,SAPLogistics,SAPHumanResources+SAPBW.

a. SAPdoesnotprovideanytrainingcoursesforSAPBW-FICOoranyotherareaofSAPBW+SAPR/3functionalknowledge.ASAPBWConsultant,ifheclaimsknowledgeofoneoftheSAPFunctionalAreasplusSAPBWgotitinoneofthefollowingwaysonly:

i. WasaSAPFunctionalConsultantinoneoftheSAPModules,suchasMMorSDorFI/CO.ThenhedecidedtobecomeaSAPBWconsultant.

ii. TheSAPBWConsultantworkedonanimplementationprojectonthebusinesssideinoneofthefunctionalareasroughlyrelatedtosay,financeorlogistics.

iii. GainedsomeknowledgeoftheSAPfunctionalmodule,suchasSAPFinanceorSAPHumanResources,fromworkingasaSAPBWconsultantonaprojectwherehehappenedtoworkonthatarea.Inthesecases,thefunctionalknowledgewillbelimitedtoonlythosefunctionalareascoveredduringthatparticularproject.

3. DoyouspecializeinaSAPBWIndustryspecialty?a. SAPdoesnotprovideanySAPBWIndustryTrainingnordoesit

provideSAPBWContentforallSAPIndustrySolutions.i. ASAPBWConsultantcanonlyhavegottenSAPBWIndustry

experienceinoneofthefollowingways:1. WorkedonaSAPBWIndustrySolution

implementation,suchasAirlineMROoperationsandlearnedsomeofit,on-the-job.

2. WorkedinaspecificindustrypriortojoiningSAP,butthenwillbelimitedtoknowledgeabouttheparticularareaheworkedinwithinthatindustrybeforebecomingaSAPBWConsultant.

Ourvaluepropositionisbaseduponthreeprimaryprinciples:

1. AllofourSAPBWconsultantsareeitherSAPCertifiedorareworkingtowardit.OurphilosophyissimplewhenitcomestoSAPCertification.SAP

Certificationmaynotmakeyouagoodconsultant,butitdoesindicateyouhaveputinsometimestudyingtheavailablematerial.Beingacompanyfoundedbypilots,embeddedsoftwaresystemengineersandex-militarymaintenanceofficers,weare,bynature,verydemandingofourteam.

2. WeknowthattheavailableSAPTrainingMaterialis,unfortunately,limited,oflessthanmilitaryclassqualityandusuallysomewhatout-of-date.Tofix


46/47

Page 46 of 46



that,weproducetheseHow-ToGuides.Theyrepresentourdeepexperienceintheindustryandourbackgroundinengineeredsoftwaresystems.

3. Wearefortunatetoworkinanindustrythatcontinuestoexhibitahigh-demandforexpertiselikeours.Wearelimitedinnumberswithhugegrowthtargets,andoursuccessdependsupon:

a. Providingourcustomerswithhigh-quality,highvaluesolutionsandprovingthevalue.b. Creatinghigh-performanceBusinessAnalyticsConsultantsby

continuouslyrecruiting,training,measuringandimprovingourconsultantsskills.

Wealsoknowthatintodaysevermoreconstrainedbudgetaryenvironment,wemustprovideourclientswiththemeanstoestimatewhattheirBWprojectwillcostandwhatbenefit(s)itwillprovidethebusiness.Tothatend,wehavedevelopedtwotools,theSAPBWResourceCalculator.

TheBWResourceEstimationCalculatorisavailablefordownloadhere,andweencourageyoutodownloadandgiveitwhirl.However,wewouldhighlyrecommendyouengagewithustowalkyouthroughitasthesubjectmatterrequiresextensiveknowledgeoftheSAPBWproduct.TheothercalculatorweprovidefocusesontheuseofSAPBWtoenableThrough-putAccountingcapabilities,whichissomethinguniquetoSAPBWConsulting,inc.


47/47

Page 47 of 47