Before distributing the universe to the users, it is good to have a quality assurance session to review the universe. Table 15-3 provides a checklist that covers recommendations from the previous chapters. A review session is different from an integrity check; the integrity check ensures that the universe is technically correct but does nothing to ensure that the universe follows best practices or will be successful with the users.
Table 15-3: Quality Assurance Checklist
Chapter
Category
Item
Date Reviewed
Comments and Exceptions
5
Overall Universe
Subject area corresponds to business goal
Target user group identified
Number of objects appropriate for target user group
6
Universe Parameters
Universe description clear and complete
Connection synchronized with database username and password
Controls adequate for query results
Incremental export disabled
14
Linked universe points to same domain
SQL settings generate correct results (recommend all enabled)
Query test for split SQL with multiple measures
Query test for split SQL with multiple contexts
7
Joins
Joined fields indexed
Join fields that contain nulls use an outer join
All loops are resolved with a context
Tables with multiple meanings have an alias
Joins belong to at least one context (excluding short-cut joins)
Joins with composite keys are entered as complex joins
Short-cut joins created for faster join paths not through fact table
8
Objects
Class names logical and meaningful
Classes sorted logically
Dimension objects point to lookup table
Objects not used for drill-down marked as Detail objects
Column format and object type match
Measure includes SQL aggregate function
Separate measure provided for average unit price, and so on
Objects include description
Objects sorted logically within class (top to bottom for drill-down)
Object names are customer-oriented, clear, consistent, and concise
Object format is set, particularly for numeric ID fields
Unnecessary hidden objects removed
8 and 12
Security access levels match Supervisor settings
Object uses are sensical (recommend all enabled)
9
List of Values
List of values disabled for measure objects
List of values disabled for nonsensical detail objects
Long list of values are customized with prompt
Meaningless ID fields customized to include name or description
List of values access dimension table not fact table
Object.lov file does not unintentionally contain data
Export with universe set only for custom list of values
Shared list of values used for common dimension objects
10
Advanced Objects
Condition objects created for common conditions, particularly time
Condition objects use index or give satisfactory query performance
Objects with prompts are not overly restrictive
Prompted field is indexed or gives satisfactory query performance
Count objects point to key field or use Distinct
Ratios use SUM aggregate correctly SUM()/SUM()
13
Ratios in fact table recalculated in universe
13
Candidate objects for fact/dimension table insertion identified
10
Aggregate Objects
Aggregate table included in universe
Aggregate table has its own context
SUM function inserted correctly within Aggregate aware @ AGGREGATE_AWARE(SUM(AGG1)), SUM(AGG2), SUM(DETAIL))
Incompatible objects set
Incompatible objects include only relevant context
Query test accesses aggregate table and detail table as intended
Query test verifies summary answers match answers from detail table
11
Hierarchies
Custom Hierarchies created
Hierarchies sorted from top to bottom
Separate hierarchies for ID and Description objects
UDS Maps enabled at correct levels
Standard reports created in WebI
12
Supervisor
Password synchronized with universe connection
Object level security matches universe object
Row restrictions do not cancel each other out
Resources linked at appropriate level so inheritance flows down
Linking resources is used more than disabling resources
Timestamps used on limited basis
Other
Backup copy of universe available
Relevant documentation printed
Benchmark reports identified
The following people should ideally be involved in a quality assurance review:
DBA The DBA will help verify the correctness of certain SQL statements, assess their impact on response time if there are advanced SQL functions, consider join strategies to generate the fastest queries possible, and identify opportunities to create aggregate tables and to tune indexes for popular condition objects.
Data modeler/architect The data modeler or architect will help identify any possible problems with joins that arise from missing data—for example, if a particular field is not required. This person can also review business terminology, object descriptions, customized lists of values, and aliases (CUSTOMER versus CUSTOMER_SHIP_TO versus CUSTOMER_SOLD_TO). A source system expert may also be helpful in this role.
Power user/report authors Power users and report authors will provide input on the overall appearance, organization, and functionality of the universe. Did you, as the designer, actually deliver what they hoped for? Will they be able to build the reports they need to build using the current design of the universe? Power users will also provide input on similar items to the data modeler.
Other designers If your company has multiple universe designers, it’s useful to get an objective opinion from another designer on the universe. This is an excellent way to share tips and techniques and to provide a consistent user interface across universes (as an alternative to linked universes).