Professional Documents
Culture Documents
Business Intelligence
Topics
Introductions
Characteristics of a Business Intelligence Application
Demonstration
Design Issues
What is
Business Intelligence?
SDG Computing
www.sdgcomputing.com
Cognos (www.cognos.com)
Brio (www.brio.com)
Gartner Group
www.gartner.com
Greene (1966)
Thierauf (2001)
Dimension Applications
Dimension Focus
TPS Data transactions
MIS Information
INSIGHT
ANALYSIS
ACTION
Business
Intelligence
MEASUREMENT
Date
Region
Product
How much Chocolate did we sell in the South East in May 2003?
Front-End Tools
Client Client
Web Web
Server Server
SQL MDX
SQL Server 2000
Relational Analysis
Database Services
DTS
User Focus
– Management of user expectations becomes very important
Things to get right at design stage
Source data
– Do we have access?
– Often data in disparate sources and not always accessible
– Is it at the same level
– Budget data may be formulated at a higher summary level than
actual data is sourced at
– Process
– How and when does the data get into the Warehouse?
– What level of data cleansing & transformation will be required
– Who is responsible?
Things to get right at design stage
Source data
– Are we able to match outputs to inputs
– Merging and matching of data sources
– Requirement for company wide data standards and definitions
– Are there common keys?
– Hierarchy movements over time
– the need to restate or retain historic view?
– Timeliness of data
– Data volumes
– Handling of missing values and relationships
Things to get right at design stage
Can you deliver the user/business requirements with the
tools/skills available
– Some things that look easy are sometimes not
– Dimension changes
– Things that do not seem important to the developer are
important to the business user
– Format
– Performance
– Some things will be slow because they are slow
– Manage expectations
– Product limitations
Things to get right at design stage
Reporting vs Analysis
– They may seem the same but they are not
– Different tools
– Different approach
– Different audience
BI Design Parameters
Cubes
– Number of cubes – possibly defined by business functions
or security
– Number of dimensions per cube, shared or private
– Partitions relating to data volumes and update speeds (cube
processing times)
– Virtual cubes – cross functional analysis
– Data storage options
BI Design Parameters
Dimensions
– Types of hierarchies - multiple, ragged, parent\child,
balanced\unbalanced
– Size, number of members
– Member properties and how these could be used (attributes)
– Number of levels, children within each level
– Hierarchy changes over time
– Reporting views, scenarios
BI Design Parameters
Time Dimension
– Alternative time hierarchies – calendar, financial
– 13 period year – weeks to period
– Number of levels
BI Design Parameters
Timeliness of Data
– Real-time
– Next day
– Weekly reviews (possible weekend to process)
– Monthly reviews (month end processing)
BI Design Parameters
Measures
– Methods of aggregation
– Data entering cubes at differing levels required for
comparisons
– Custom rollups
– Non additive data
– Precision, format
BI Design Parameters
Calculated Measures
– Time series calculations
– SQL vs OLAP calculations (pre cube build vs post cube
build)
– Calculated cells
– Nature of equations required to derive the calculated
measures
– Currency exchange rates
– Distributed processing opportunities (server calcs vs client
side calcs)
– Application of MDX
BI Design Parameters
Write-Back requirements
– Allocations\break back requirements, level of data entry
– Audit log
– Validation
BI Design Parameters
Output requirements
– User report definitions – format, layout, precision
– Types of adhoc analysis
– Actions
– Requirements for printed output
– Quantitative vs Qualitative data output
– Browser\Office delivery
– OLAP database drill-through to SQL Server
– Number of users
– Report maintainability
– Security
BI Design Parameters
Security
– Cube
– Dimension
– Cell level
To consider when building BI
applications..
Users can fail to realise how much info they requested –
leads to poor perceived performance
Complexity due to a large number of dimensions – users
don’t understand the model/numbers
Hard to test because they are conceptually complex
Performance vs storage – consider
MOLAP/HOLAP/ROLAP, on-the fly versus pre-aggregated
data
There is a strong case for a BI
strategy
BI can drive significant value
It is an agile technology
– crosses functional boundaries
– crosses organisational boundaries
– Implementation can involve many stakeholders
Tactical BI applications may deliver significant value (and
prove BI’s worth) …
In a post boom business climate, BI offers a pragmatic
way of delivering high return in the short term without
major upheaval