BEGIN:VCALENDAR VERSION:2.0 PRODID:-//hacksw/handcal//NONSGML v1.0//EN METHOD:PUBLISH BEGIN:VEVENT DTSTAMP:20240328T110914Z DESCRIPTION:Click for Latest Location Information: http://graphorum2019.dat aversity.net/sessionPop.cfm?confid=132&proposalid=10926\n
As data teams i terate on ever-expanding data models, they create complexity. The complexit y created can impact the ability of data consumers to easily comprehend and consume data assets. It also creates a higher likelihood of introducing er rors that lead to wrong decisions being taken on data.
\nWhethe
r data is consumed directly from data mart tables/files or by creating a le
ns on a dataset in a Business Intelligence (BI) tool, without a deep unders
tanding of the underlying data model and field relationships, users can gen
erate results that have no validity. The deep understanding of the underlyi
ng data model resides with subject matter experts (SMEs) who have to be inv
olved or validate every dataset that undergoes any transformation in the BI
layer. To make better use of SMEs, their knowledge field relationships can
be encoded in an ontology that is automatically accessed by BI tools. 
;
\n
\nHere are examples of possible scenarios that would create
errant results:
\n
\nSumming non-additive measures<
/strong>
\nSemi-additive measures can be summed across some dimensions
, but not all; balance amounts are common semi-additive facts because they
are additive across all dimensions except time. Some measures are completel
y non-additive, such as ratios. Our approach for non-additive facts is
, where possible, to store the fully additive components of the non-additiv
e measure and sum these components into the result set before calculat
ing the non-additive fact. This calculation is done in the BI lay
er or OLAP cube, however, end users may sum non-additive measures in a 
;BI layer or in SQL when querying a table. Without knowledge of which measu
res are additive, the user may report false numbers.
\n
\n<
strong>Filtering/Grouping on dimensions that are not applicable to measure<
/strong>
\nCareful adherence to the grain of measure is necessary to a
ccurately report results. The BI layer needs a systematic way to ensure tha
t an end user correctly groups/filters on applicable dimensions. Ideal
ly, users would be systematically warned or restricted from grouping at any
level lower than that of the highest grain measure.
\n
\n<
strong>ETL/Visualization Errors
\nMeasure naming/formul
ation within Business Intelligence apps is often ungoverned. This can resul
t in measures that are inconsistently named and defined across reports and
dashboards.
\n
\nWithin a table OR analytics da
taset:
Across ALL tables AND analytics datasets:
\n\n Same measure name; different calculation. This would indicate that the name or calculation within 1 of the dashboards needs to be corrected by alignin g to the established naming/dashboard. \n Different measure name, same calculation, with or w/o filter. This would in dicate that the name or calculation within 1 of the dashboards needs to be corrected by aligning to the established naming/dashboard. \n Highly used measures that are not defined KPIs in Ontology Model.\n New/Sparsely used measures. This may indicate a measure that needs to be &l dquo;officially” defined and owned by a steward or a measure that is not justified or a use case which is covered by another existing measure.\n \n DTSTART:20191017T094000 SUMMARY:Ontological Representation of Business Data Models DTEND:20191017T103959 LOCATION: See Description END:VEVENT END:VCALENDAR