BI EE Technical Check-List

Version 1.0
Helping Your Business Intelligence Journey

Your Delivery Quality Scores Are:

Data-Warehouse
BI Server
BI Presentation Services
Operations & Support
Overall

0.0%
0.0%
0.0%
0.0%
0.0%

NOTES
1) Scores are calculated by counting the check-list items with Status = 'Confirmed'
2) Check-list items with Status = 'Not Applicable' are ignored

Peak Indicators Limited

Area

Design

Id

DW Consultant/Architect to Confirm:

1.01

Table, View, Index, Column and Primary/Surrogate/Foreign Key naming

conventions and design standards have been outlined in a DW Design
Standards document

1.02

A High-Level Design (HLD) for the DW Data-Model has been produced

1.03

The entire Development team are aware of and understand the

standards imposed by the DW Design Standards and HLD documents

1.04

The Customer understands and has approved both the DW Design

Standards and HLD documents

1.05

All standards outlined in the DW Design Standards document have been

followed, and any exceptions have been documented

1.06
1.07
1.08

STAR_TRANSFORMATION_ENABLED database parameter been set to

TRUE
All Foreign Key indexes been created as Bitmap indexes

1.11

The data-model contains no "snow-flaking"

Fact tables only contain:
- Primary / Surrogate Key
- Unique Key (Optional)
- Fact Columns (Metrics)
Any excpetions documented
Dimension Tables only contain:
- Primary / Surrogate Key
- Unique Key (Optional)
- Dimension Attributes
Any excpetions documented
Every table has a Surrogate Key

1.12

All table joins are achieved via a Surrogate Key

1.13

The database block size is 16K or greater

1.14

All Foreign Key columns have been indexed

1.15

Primary / Unique Keys have been used on columns containing unique

data (rather than standard B-Tree / Bitmap Indexes)

1.16

The Development/UAT databases contain realistic production data

volumes

1.17

Aggregate tables (or Materialized Views) have been used to summarise

all large Fact tables (e.g. Ones that generate >500K records per year)

1.18

Aggregate tables are incrementally updated, not fully rebuilt during each
ETL cycle

1.19

Aggregate tables are simple in that they summarise only the raw data,
leaving the BI Server to apply any "Business Logic"

Documentation

1.20

Table definitions have been documented, with descriptions given for all
columns whose exact purpose is not immediately obvious or implied by
the DW Design Standards document

Knowledge Transfer

1.21

Walk-through of data-model and associated documentation has been

delivered to Customer

1.09
Star-Schema

1.10

Performance

Status

Total Score

0.0%

Verified By

Comments

Area

Id
2.01

Design

2.02
2.03
2.04
2.05
2.06
2.07

RPD Physical Layer

2.08
2.09
2.10
2.11
2.12
2.13

The Customer understands and has approved the RPD High-Level Design
All standards outlined in the RPD Design document have been followed,
and any exceptions have been documented
Foreign Key joins only have been used in the Physical Layer, no Complex
Joins
For a star-schema data-model, all Physical Tables have been aliased
(prefixed with either Dim_, Fact_ or Fact_Agg_)
"Native" drivers have been used in the DB Connection Pools wherever
possible e.g. OCI not ODBC
"Max Connections" has been appropriately calculated for each
Connection Pool (and increased from the default value of 10 where
necessary)
The Caching property of each and every Physical Table has been
appropriately configured
The names of each Physical Catalogue are "generic" to all environments
and are not just set to the names of the Development databases e.g.
SalesDW instead of ORCL
Connection Pooling has been configured appropriately (to ensure re-use
of open database connections)
All Logical Tables have been prefixed with either Dim , Fact or
Fact Compound
No physical column names are present in the Business Model layer, all
naming conventions are business oriented. For example $ Revenue
rather than DOLLARS

2.14

No Physical Primary Keys or Surrogate Keys should are present on the

Business Model layer (unless, for example, you have a Primary Key such
as Order Id which will be displayed on reports)

2.15

All Dimension Logical Tables have a Logical Key assigned. The Logical Key
is business oriented such as Employee Login rather than
EMPLOYEE_PK

2.16

Dimension Logical Tables only contain dimension attributes, they do not

contain any measure columns (which have an Aggregate Rule)

2.17
2.18
RPD Business Model Layer

BI Consultant/Architect to Confirm:
A High-Level Design (HLD) for the RPD has been produced (for example:
document the required Business Models, Logical Tables and Subject
Areas)
The entire Development team are aware of and understand the RPD HighLevel Design

2.19
2.20

No Fact Logical Tables have a Logical Key assigned

Every Logical Column within a Fact Logical Table is a measure column i.e.
has an Aggregation Rule assigned
Only Complex Joins have been used to join Logical Tables together (not
Foreign Key joins)
There is no "Snow-Flaking" in the Business Model

2.21

Every Dimension Logical Table has a corresponding Dimension Hierarchy

(with Total as a Grand Total level, and Detail at the lowest level)

2.22

Each level of every Dimension Hierarchy has its Number of Elements

appropriately set (there is a utility that can do this automatically)

2.23

Every Logical Table Source within every dimension and fact Logical Table
has Content Level appropriately set. The only time the Content
Level is not set for a particular dimension is when there is no logical
relationship existing

2.24

The measures in your Business Model have not all been merged into a
single Fact Logical Table, they have been split out into separate Logical
Fact Tables. For example, you should split Forecast Sales and Actual
Sales measures into two Logical Tables e.g. Fact Sales and Fact
Forecast

Status

Verified By

Comments

2.25

2.26

2.27

The Business have approved the design and structure of the Subject
Areas
Business Representatives have provided the Development team with
Business Definitions for each the Facts and Dimension objects available in
the Subject Areas. These Business Definitions will be visible to the End
Users
The Business have approved the naming conventions of the
Fact/Dimension objects within all the Subject Areas

2.28

When you have multiple Subject Areas, all the common Dimensions are
listed in the same order across all the Subject Areas

2.29

No Presentation Table names begin with Dim or Fact or Fact

Compound (i.e. The naming conventions from the Business Model
have been removed)

2.30

The Time presentation table is listed as the first Presentation Table in

each subject area. The Presentation Table containing the Facts is listed
right at the bottom, within a Presentation Table called Measures

2.31

There is absolutely no possibility of an End-User being able to select

objects from a Subject Area that have no logical relationship. The user
can select any combination of objects from a Subject Area and the
resulting query will be valid

2.32

The Presentation Layer does not consist of a single "one-size-fits-all"

Subject Area. Multiple Subject Areas exist each applicable for specific
areas of analysis

2.33

Presentation Catalouges (Subject Areas) have been given a Description in

the RPD, for the purposes of explaining their purpose to the End-Users

2.34

The "SA System" Subject Area has been implemented (to automatically
configure delivery profiles for each user)

2.35

Presentation Table/Columns within each Subject Area have been given

Descriptions to explain their purpose to the End-Users. Where the
purpose is obvious, an example of the column's content has been given
(For example: Year / Month e.g. 2007 / 12)

2.36

Aggregate Tables / Materialized Views have been modelled into the RPD

2.37

A BI Server "Caching" strategy has been defined and implemented

(including the seeding and purging of cache entries)

RPD Presentation Layer

Performance

2.38
2.39
Security

2.40
2.41

The Authentication / Authorization mechanism has been successfully

tested using BI Dashboards
The Authentication / Authorization mechanism has been successfully
tested using BI Delivers
The Authentication / Authorization mechanism has been successfully
tested using BI Office
The Authentication / Authorization mechanism has been successfully
tested using BI Publisher

2.42

The Development Team have tested the Dashboards/Reports as a "real"

End User and not just as Administrator

2.43

All redundant objects (Physical Tables, Columns etc) have been removed
from the BI Repository (RPD)

2.44

Variables have been used wherever possible to minimise the amount of

hard-coding in the RPD (e.g. Database connection strings)

2.45

Usage Tracking has been implemented

2.46

The RPD Consistency Check does not return any errors or warnings

Documentation

2.47

The "Generate RPD Metadata" feature has been utilised, and RPD
Metadata is available for Power Users to view within Answers

Knowledge Transfer

2.48

The Customer has received a walk-through of the BI Repository

implementation

General

Total Score

0.0%

Area

Id
3.01
3.02

Design

Configuration

The entire Development team are aware of and understand the HLD for
the Dashboards/Presentation Catalogue structure

3.04

The Customer understands and has approved the HLD for the
Dashboards/Presentation Catalogue structure

3.05

All standards outlined in the Dashboards/Presentation Catalogue HLD

have been followed, and any exceptions have been documented

3.06

BI Office has been enabled

3.07

BI Publisher has been enabled

3.08

BI Delivers has been enabled

3.09

"Act As" (Proxy User) has been implemented and enabled

3.10

The Customer has been made aware that BI Office, BI Publisher, BI

Delivers and "Act As" options have been enabled

3.12

There are no complex calculations applied in any Answers Requests (all

calculation logic is being perfomed by the BI Server)

3.14

Answers Requests are all consistent in terms of naming conventions

3.15

Answers Requests make appropriate use of Column Selectors

3.16

Answers Requests make appropriate use of View Selectors

3.17

Adequate use of Charts within Answers Requests

Drill-Down and Navigation has been implemented extensively to provide
an interactive End-User experience

3.19

No more than 5 Answers Requests are present on any single Dashboard

3.20

The Dashboards are consistent in terms of their layout and formatting

3.21

There is no "one-size-fits-all" Dashboard, so each type of user has their

own set of Dashboards which are role-based and personalised

Presentation Catalogue

3.22

Performance

3.23
3.24

Security
3.25
Documentation

Knowledge Transfer

Links to unused features have been disabled (e.g. Marketing,

Disconnected)
The user of Shared Filters have been adopted to avoid any hard-coding of
filters, and to encourage re-use of code

3.13

3.18

BI Dashboards

Status

3.03

3.11

BI Answers

BI Consultant/Architect to Confirm:
A High-Level Design (HLD) for the Dashboards and Presentation
Catalogue structure has been produced
A Dashboard Design workshop has been conducted in the presence of
Business Representatives

There is a separate Shared Folder for each Dashboard, containing a SubFolder for each Dashboard Page. Answers Request should go into the
relevant Sub-Folder
The perfomance of the Dashboards and Reports are being monitored
through the Usage Tracking feature
Security is in place to restrict System Privileges e.g. Answers access,
Delivers access
Security is in place to restrict access to Dashboards, Subject Areas and
Shared Folders

3.26

The Business have been made responsible for documenting how their
End Users should use the Dashboards and Answers

3.27

End Users are aware of how to use "Act As" (Proxy User) functionality

3.28

End-Users are aware of how to Bookmark URLs

3.29

End Users are aware of how to use "Saved Selections"

Customer is aware of the capabilities with BI Office, BI Publisher, BI
Delivers

3.30

Total Score

0.0%

Verified By

Comments

Area

Id

Architect to Confirm:

4.01

The entire solution is "supported" by Oracle Support

Customer Operations Team are in a position to administer and maintain
the BI solution once in Production
Customer Operations Team are aware of how to initiate the ETL and also
how to restart it in the event of failure

4.02
4.03
Administration / Support
4.04

The Customer Operations Team is aware of the steps needed when the
RPD Administrator password is changed (e.g. Cryptotools utility needs to
be run for BI Publisher, Delivers and Impersonator)

4.05

Customer Operations Team know when the ETL cycles will take start,
how long they should run for and which systems will be impacted

4.06
Release Management

Status

4.07

A Release Strategy for the initial deployment been defined and agreed
with the Customer
A Release Strategy for subsequent incremental upgrades has been
"discussed" with the Customer

4.08

The Release Strategy is as automated as possible (e.g. Environmentspecific settings in the RPD are scripted via NQcmd command line)

4.09

BI architecture has been sized in line with recommended guidelines

(Suggestion to view Architecture / Sizing presentation by Peak Indicators)

Architecture
4.10
4.11
4.12
Knowledge Transfer
4.13
4.14

The implementation will cater for anticipated user growth and data
volumes for the next 2-3 years
Customer has been given documentation on Adminstration / Support
procedures for Oracle BI (Suggestion to use BI EE Adminsitration &
Support presentation by Peak Indicators)
Customer has been presented with overview documentation on how the
ETL functions
A full and detailed "Installation Guide" has been produced for the
customer (suggestion to use sample install guide provided by Peak
Indicators)
Customer has been informed about all the potential Technical and End
User training that is available

Total Score

0.0%

Verified By

Comments