OBIEE Technical Check-List

8/10/2019 OBIEE Technical Check-List

1/6

BI EE Technical Check-ListVersion 1.0

Your Delivery Quality Scores Are: Data-Warehouse 0.0%

BI Server 0.0%

BI Presentation Services 0.0%

Operations & Support 0.0%

Overall 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

Helping Your Business Intelligence Journey

Peak Indicators Limited


2/6

Area Id DW Consultant/Architect to Confirm: Status Verified By Comments

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.03The entire Development team are aware of and understand the

standards imposed by the DW Design Standards and HLD documents

1.04The Customer understands and has approved both the DW Design

Standards and HLD documents

1.05All standards outlined in the DW Design Standards document have been

followed, and any exceptions have been documented

1.06 STAR_TRANSFORMATION_ENABLED database parameter been set toTRUE

1.07 All Foreign Key indexes been created as Bitmap indexes

1.08 The data-model contains no "snow-flaking"

1.09

Fact tables only contain:

- Primary / Surrogate Key

- Unique Key (Optional)

- Fact Columns (Metrics)

Any excpetions documented

1.10

Dimension Tables only contain:

- Primary / Surrogate Key - Unique Key (Optional)

- Dimension Attributes

Any excpetions documented

1.11 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.16The Development/UAT databases contain realistic production data

volumes

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

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

1.18Aggregate tables are incrementally updated, not fully rebuilt during each

ETL cycle

1.19Aggregate 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.21Walk-through of data-model and associated documentation has been

delivered to Customer

Total Score 0.0%

Design

Star-Schema

Performance


3/6

Area Id BI Consultant/Architect to Confirm: Status Verified By Comments

2.01

A High-Level Design (HLD) for the RPD has been produced (for example:

document the required Business Models, Logical Tables and SubjectAreas)

2.02The entire Development team are aware of and understand the RPD High-

Level Design

2.03 The Customer understands and has approved the RPD High-Level Design

2.04All standards outlined in the RPD Design document have been followed,

and any exceptions have been documented

2.05Foreign Key joins only have been used in the Physical Layer, no Complex

Joins

2.06 For a star-schema data-model, all Physical Tables have been aliased(prefixed with either Dim_, Fact_ or Fact_Agg_)

2.07"Native" drivers have been used in the DB Connection Pools wherever

possible e.g. OCI not ODBC

2.08

"Max Connections" has been appropriately calculated for each

Connection Pool (and increased from the default value of 10 where

necessary)

2.09The Caching property of each and every Physical Table has been

appropriately configured

2.10

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

2.11Connection Pooling has been configured appropriately (to ensure re-use

of open database connections)

2.12All Logical Tables have been prefixed with either Dim , Fact or

Fact Compound

2.13

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 suchas 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.16Dimension Logical Tables only contain dimension attributes, they do not

contain any measure columns (which have an Aggregate Rule)

2.17 No Fact Logical Tables have a Logical Key assigned

2.18Every Logical Column within a Fact Logical Table is a measure column i.e.

has an Aggregation Rule assigned

2.19Only Complex Joins have been used to join Logical Tables together (not

Foreign Key joins)

2.20 There is no "Snow-Flaking" in the Business Model

2.21Every Dimension Logical Table has a corresponding Dimension Hierarchy

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

2.22Each 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

Design

RPD Physical Layer

RPD Business Model Layer


4/6

2.25The Business have approved the design and structure of the Subject

Areas

2.26

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

2.27The Business have approved the naming conventions of the

Fact/Dimension objects within all the Subject Areas

2.28When 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.32The 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.33Presentation Catalouges (Subject Areas) have been given a Description in

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

2.34The "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.37A BI Server "Caching" strategy has been defined and implemented

(including the seeding and purging of cache entries)

2.38The Authentication / Authorization mechanism has been successfully

tested using BI Dashboards

2.39

The Authentication / Authorization mechanism has been successfully

tested using BI Delivers


tested using BI Office


tested using BI Publisher

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

End User and not just as Administrator

2.43All redundant objects (Physical Tables, Columns etc) have been removed

from the BI Repository (RPD)

2.44Variables 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

Security

General

Performance

RPD Presentation Layer


5/6

Area Id BI Consultant/Architect to Confirm: Status Verified By Comments

3.01A High-Level Design (HLD) for the Dashboards and Presentation

Catalogue structure has been produced

3.02A Dashboard Design workshop has been conducted in the presence of

Business Representatives

3.03The entire Development team are aware of and understand the HLD for

the Dashboards/Presentation Catalogue structure

3.04The Customer understands and has approved the HLD for the

Dashboards/Presentation Catalogue structure

3.05All 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.10The Customer has been made aware that BI Office, BI Publisher, BI

Delivers and "Act As" options have been enabled

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

Disconnected)

3.12The user of Shared Filters have been adopted to avoid any hard-coding of

filters, and to encourage re-use of code

3.13There 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

3.18Drill-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.21There 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

There is a separate Shared Folder for each Dashboard, containing a Sub-

Folder for each Dashboard Page. Answers Request should go into the

relevant Sub-Folder

Performance 3.23The perfomance of the Dashboards and Reports are being monitored

through the Usage Tracking feature

3.24Security is in place to restrict System Privileges e.g. Answers access,

Delivers access

3.25Security is in place to restrict access to Dashboards, Subject Areas and

Shared Folders

Documentation 3.26The 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

Design

Configuration

BI Answers

BI Dashboards

Knowledge Transfer

Security


6/6

Area Id Architect to Confirm: Status Verified By Comments

4.01 The entire solution is "supported" by Oracle Support

4.02Customer Operations Team are in a position to administer and maintain

the BI solution once in Production

4.03Customer Operations Team are aware of how to initiate the ETL and also

how to restart it in the event of failure

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.05Customer Operations Team know when the ETL cycles will take start,

how long they should run for and which systems will be impacted

4.06

A Release Strategy for the initial deployment been defined and agreed

with the Customer

4.07A Release Strategy for subsequent incremental upgrades has been

"discussed" with the Customer

4.08The Release Strategy is as automated as possible (e.g. Environment-

specific settings in the RPD are scripted via NQcmd command line)

4.09BI architecture has been sized in line with recommended guidelines

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

4.10The implementation will cater for anticipated user growth and data

volumes for the next 2-3 years

4.11

Customer has been given documentation on Adminstration / Support

procedures for Oracle BI (Suggestion to use BI EE Adminsitration &

Support presentation by Peak Indicators)

4.12Customer has been presented with overview documentation on how the

ETL functions

4.13

A full and detailed "Installation Guide" has been produced for the

customer (suggestion to use sample install guide provided by Peak

Indicators)

4.14Customer has been informed about all the potential Technical and End

User training that is available

Total Score 0.0%

Administration / Support

Knowledge Transfer

Architecture

Release Management

Documents

OBIEE Technical Check-List