
Basic Concepts Brio 2002
Copyright © 2002, Brio Software Page 4
Cross-row comparisons
The set orientation of SQL makes it difficult to build logic that compares
information in one row with another. Brio’s Next() and Prior() functions provide
the ability to create complex logic that depends on comparing data between
rows. Combine a computed item using these functions with local sorting of the
Results section to create controlled comparisons.
Grouping the data to provide ad-hoc organization
Your database may not be organized in the way you want to analyze it. You may
have a large number of discreet values that you would like to break out into a set
of ranges instead. Perhaps you only have a date field, but want to perform
analysis based on years or quarters. Or perhaps you have years and quarters, but
they are calendar based and you want to perform a fiscal year based analysis. All
of these data organization problems can be addressed by using combinations of
Computed Items, Grouping Columns and Date Groupings in the Results section.
Transforming the data into a more useful form
Sometimes what you get out of your database is not in the most useable form.
Data entry can be inconsistent. The data needs to be transformed into a
consistent representation of values. You may need to split out what is stored as a
single measure into multiple “dimensionalized facts” for the analysis you want
to perform. Or you may want to transform a dimension into a measure. Or the
values in a dimension may be too long to conveniently fit in a chart or pivot you
plan to build. Instead, you’d like to use some kind of short-hand value computed
from the actual ones. Computed Items using If-Then-Else logic can address these
issues.
Preparing for expanding the data’s use
For example, say you want to create a Pivot with a count of the number of
transactions for each item. You could drop the Customer_ID field into the data
items area in the Pivot Outliner, right-click on the column and change the data
function to be Count. Now, you want to add the dollar amounts and then expand
the use of the Customer_ID count to calculate the average per transaction. In
building the formula for the average, the Pivot will revert to the default data
function of summing the Customer_ID as if it were a number to be added instead
of an ID to be counted. This will not yield the correct average.
Back up a step to the Results section instead. Use a computed item to “translate”
the Customer_ID into a true count. Simply define the formula as a 1. Then you
can use this numeric field directly in the pivot to compute the correct number of
transactions and as part of the formula to yield the correct average per
transaction.
Where to Consolidate
The proper use of Computed Items in the Results section depends on
understanding how you want to consolidate your information. If the
consolidation is based on the “raw” data, use the power of the Results section.
Comentarios a estos manuales