8/2/2019 OLTP Universe Design
1/41
OLTP Universe Design
Dennis W. Disney of BO4EBS
8/2/2019 OLTP Universe Design
2/41
2009 SAP BusinessObjects User Conference
Learning Points
OLTP design issues
OLTP design philosophy
An OLTP design methodology
8/2/2019 OLTP Universe Design
3/41
2009 SAP BusinessObjects User Conference
Who am I and why should you listen to me?
I have been doing reporting against Oracle Applicationssince 1993
I have been building universes for Oracle Applicationsreporting since 1999
I have built universes for Oracle Applications for 5 verydifferent clients
For each new generation of universes, I develop a codingstandard based on what I have learned with prior universes
8/2/2019 OLTP Universe Design
4/41
2009 SAP BusinessObjects User Conference
BO4EBS
BO4EBS provides customized reporting solutions for OracleE-Business Suite to clients
The reporting solution includes universes, reports, tables,PL/SQL code whatever is necessary to meet the clientsreporting needs
All done for a fixed price
8/2/2019 OLTP Universe Design
5/41
2009 SAP BusinessObjects User Conference
Strategic Versus Tactical Reporting
Strategic reporting is about identifying trends, starperformers and dogs
Strategic reporting is best done with a star schema andsummary tables
Tactical reporting is about what needs to be done now orthe details of one record
Tactical reporting is best done querying against Productiondata tables
Reporting against an OLTP should only be tactical reporting
Strategic reporting against OLTP tables is too slow andputs too much of a load on the OLTP database
8/2/2019 OLTP Universe Design
6/41
2009 SAP BusinessObjects User Conference
Issues An OLTP Universe Design Must Address
Double outer joins an invoice may or may not have apurchase order and a purchase order may or may not have
an invoice Context is this the customer site that ordered the item,
that received the item or that was billed for the item?
Volume of tables OLTP universes can have hundreds oftables, almost all of which are used for multiple purposes
Performance how to build efficient queries should be fairlyobvious
8/2/2019 OLTP Universe Design
7/41
2009 SAP BusinessObjects User Conference
Skills An OLTP Universe Designer Should Have
Knowledge of the tables and business processes of theOLTP system
Know how to describe tables and determine their indexes
The ability to guess foreign key relationships based uponcolumn names
Query tuning skills
8/2/2019 OLTP Universe Design
8/41
2009 SAP BusinessObjects User Conference
Design Philosophy Include Everything Useful
Data that cannot be reported on effectively does not exist
Data that cannot be reported on can quickly become
garbage If people have I wonder questions, the universe needs
to have the objects to answer those questions or they willnever get answered
8/2/2019 OLTP Universe Design
9/41
2009 SAP BusinessObjects User Conference
Universe Coding Standards
Every company that does universe development shouldhave a coding standard for universes
The universe coding standard should embody yourcompanies best practices
A universe coding standard provides consistency acrossuniverses
This presentation is BO4EBSs universe coding standard
This standard is for Oracle E-Business Suite, but shouldwork for any OLTP system
8/2/2019 OLTP Universe Design
10/41
2009 SAP BusinessObjects User Conference
Physical Layout Of Universe
The physical layout of the universe is key tousability/maintainability
The tables that are used together should be groupedtogether and be away from other tables
The tables should be laid out logically and consistently
Classes should be in a logical order Objects and subclasses should be created in a consistent
manner
8/2/2019 OLTP Universe Design
11/41
2009 SAP BusinessObjects User Conference
3 Types Of Classes
Main classes these are typically documents such asinvoices, receipts and purchase orders
Set up classes these are typically lists of how things areset up such as customers, suppliers and buyers
General purpose classes these are classes that arenttied to a table such as objects for unions and WebIconfiguration
8/2/2019 OLTP Universe Design
12/41
2009 SAP BusinessObjects User Conference
Class Naming
Each main and set up class should have an acronym, usually two orthree letters which is at the end of every object and subclass with thatclass
The names of main and set up classes should be in UPPER CASE andthe name of all subclasses should be in mixed case
Example main/set up class names PURCHASE ORDERS PO, CASHRECEIPTS CR, SUPPLIERS SUP
Example subclass names Supplier PO, Cash Receipt Details CR,Supplier Sites SUP
8/2/2019 OLTP Universe Design
13/41
2009 SAP BusinessObjects User Conference
Object Layout In A Class
Within a class, any objects that uniquely identify a recordshould be first
Below those objects in the class should be the rest of thedimensions in alphabetical order
After the dimensions should be the measures inalphabetical order
Consistently ordering objects in this manner make themeasier for users to find
8/2/2019 OLTP Universe Design
14/41
2009 SAP BusinessObjects User Conference
Derived Tables
Derived tables should be given names that start with DT_
Only aliases of derived tables will be used for objects,
conditions and joins Derived tables are laid out in a column at the bottom left of
the universe
The derived tables within the column are in alphabeticalorder.
8/2/2019 OLTP Universe Design
15/41
2009 SAP BusinessObjects User Conference
Base Tables
Only aliases of base tables should be used for objects,conditions and joins
Base tables should be laid out at the bottom of the universe
Base tables should be in columns to the right of the derivedtables
For Oracle E-Business Suite, similar tables start with the
same prefix (e.g. AP_, MTL_, PO_) Tables whose names start with the same prefix should be
placed in the same column
The columns should be laid out in alphabetical order of the
prefix The tables within the column should be in alphabetical
order.
8/2/2019 OLTP Universe Design
16/41
2009 SAP BusinessObjects User Conference
Example Table Layout
8/2/2019 OLTP Universe Design
17/41
2009 SAP BusinessObjects User Conference
Contexts
Each main/set up class should have its own context
The name of the context should be the name of the class,
except in mixed case and without the class acronym. Sometimes, there will be multiple contexts for a class, such
as if there is a summary-level and detail-level context toprovide better performance when only summary level
information is needed. In that case, each context should bethe name of the class in mixed case without the acronymand with the word "Summary" or "Detail" at the end.
8/2/2019 OLTP Universe Design
18/41
2009 SAP BusinessObjects User Conference
Alias Layout For Classes
The aliases for each class should be laid out in a horizontalband in the Structure pane
The bands should be in the same order as the classes inthe Universe window.
For most classes, there will be a series of parent-childtables, with lookups for each level of detail. For example, a
typical class is the JOURNAL ENTRIES JE class, whichhas the GL_JE_BATCHES table as a parent, theGL_JE_HEADERS table as a child and the GL_JE_LINEStable as the grandchild.
8/2/2019 OLTP Universe Design
19/41
2009 SAP BusinessObjects User Conference
Alias Layout For Classes (cont)
The alias layout should have the parent table on the left
Above it should be the lookups for the parent table. Ideally,
the lookups should be limited to three columns The lookups should be in alphabetical order, top to bottom
then left to right
To the right should be the table that is the next level ofdetail and above it should be its lookups
The tables should continue to the right for each level ofdetail.
Aliases should be in the view mode where you see the joins
8/2/2019 OLTP Universe Design
20/41
2009 SAP BusinessObjects User Conference
Example Alias Layout
8/2/2019 OLTP Universe Design
21/41
2009 SAP BusinessObjects User Conference
Table Acronyms
The following rules are very specific to Oracle E-BusinessSuite
The acronym should be the first letter of each word in thetable name, except no "A" should be used if the table nameends in "_ALL". For example, the acronym forMTL_SYSTEM_ITEMS_B should be "msib
If two tables used together have the same acronym, onetable should use a small word instead of a letter. Forexample xeventtt should be used forXLA_EVENT_TYPES_TL if xett has already be used for
XLA_ENTITY_TYPES_TL
8/2/2019 OLTP Universe Design
22/41
2009 SAP BusinessObjects User Conference
Alias Names For Base Tables
All aliases should be in lowercase
All aliases should start with the class acronym and then an
underscore Most alias names should be the class acronym, underscore
and the table acronym. For example, "po_msib" should bethe alias for the MTL_SYSTEM_ITEMS_B table in the class
whose acronym is "PO"
8/2/2019 OLTP Universe Design
23/41
2009 SAP BusinessObjects User Conference
Alias Names For Base Tables (cont)
If a table is used multiple times in a class, then the purpose of eachalias should be identified. For example, if the FND_USER table is aforeign key lookup for both the CREATED_BY andLAST_UPDATED_BY columns for the PO class, then the alias names
should be "po_created_by_fu" and "po_last_updated_by_fu" If a table is used multiple times in a class, it should be identified by
putting the abbreviation of the table join to in the alias name. Forexample, if the table FND_USER is used for both thePO_HEADERS_ALL and PO_LINES_ALL tables, then the two aliases
should be "po_ph_fu" and "po_pl_fu" To provide unique alias names, it may be necessary to provide the
table name joined to and the purpose of the table in the alias name. Inthat case, the name of the table joined to should be before the purposeof the table, such as "po_ph_created_by_fu"
8/2/2019 OLTP Universe Design
24/41
2009 SAP BusinessObjects User Conference
Alias Names For Derived Tables
Normally, the alias name for a derived table should be theacronym for the class, an underscore and then the derivedtable name
If that would result in multiple aliases with the same name,the rules for base tables should be followed
8/2/2019 OLTP Universe Design
25/41
2009 SAP BusinessObjects User Conference
Self-Joins
If there is a restriction that should be in the SQL for a querythat applies to only one table, then that restriction should beadded as a self-join to that table
By doing this, the LOV for an object made from that tablewill be restricted to how it is used in the query.
8/2/2019 OLTP Universe Design
26/41
2009 SAP BusinessObjects User Conference
Self-Join Example
An example of a self-join would be the restrictions on theFND_LOOKUP_VALUES table
The po_fob_flv alias uses the FND_LOOKUP_VALUEStable for the lookup value for the FOB_LOOKUP_CODE onthe PO_HEADERS_ALL table
The po_fob_flv alias has two self-joins:
po_fob_flv.LOOKUP_TYPE='FOB' andpo_fob_flv.VIEW_APPLICATION_ID=201
By creating the restrictions as self-join on the po_fob_flvalias, the LOV for an object from that table is restricted to
only FOB lookups.
8/2/2019 OLTP Universe Design
27/41
2009 SAP BusinessObjects User Conference
More Self-Join Rules
A self-join should be for only one column
The column name in the self-join should be in upper case
so that Designer can recognize the column used If the self-join is an outer join, the Outer join box on the right
should be checked. Designer will then give the self-join acircle to indicate that it is an outer join
No cardinality should be specified
8/2/2019 OLTP Universe Design
28/41
2009 SAP BusinessObjects User Conference
Examples Of Self-Joins
8/2/2019 OLTP Universe Design
29/41
2009 SAP BusinessObjects User Conference
Object / Condition SQL
Alias names should be in lower case
Column names should be in upper case
SQL Key Words should be in upper case
PL/SQL package and function names should be in uppercase
8/2/2019 OLTP Universe Design
30/41
2009 SAP BusinessObjects User Conference
Object Naming
Names of all objects should be in mixed case
Names should end with the acronym of the top-level class
that contains them Names should be unique within the universe (exception:
see List Of Values slide)
An example object name is Currency Code GL
8/2/2019 OLTP Universe Design
31/41
2009 SAP BusinessObjects User Conference
Coding Order
For a subject area, the set up classes should be built first
For the main class, the set up classes should be reused
For example, a universe for purchasing should have the setup classes created first buyers, locations, payment terms,suppliers
When the PURCHASE ORDER PO class is created,aliases of the aliases for the set up classes should becreated and the set up classes should be copied andpasted as subclasses of the PURCHASE ORDER PO class
8/2/2019 OLTP Universe Design
32/41
2009 SAP BusinessObjects User Conference
The Most Important Objects In The Main Class
For usability, the main class should have only the mostimportant objects
A Details class should be created for the less important
objects The most important object from copied set up classes can
be moved to the main class
For example, PURCHASE ORDER PO should haveSupplier Name and Buyer objects as well as Buyer PO,Purchase Order Details PO and Supplier PO subclasses
8/2/2019 OLTP Universe Design
33/41
2009 SAP BusinessObjects User Conference
Copying Main Classes
Main classes should be copied to be subclasses in othermain classes
For example, the AP INVOICES API class should be copiedand made into a AP Invoices PO class. Ditto for a PurchaseOrder API class
These structure eliminates the double outer-join problem
8/2/2019 OLTP Universe Design
34/41
2009 SAP BusinessObjects User Conference
Data Restrictions For Better Performance
Most of the queries built using an OLTP universe shouldhave a restriction based upon an object in the main class
If the query doesnt have a restriction based upon an objectin the main class, it should have one based upon an objectin of the main class subclasses
The deeper into the class you go to create a restriction, the
more likely your query will have poor performance
8/2/2019 OLTP Universe Design
35/41
2009 SAP BusinessObjects User Conference
Aggregate Awareness
Aggregate awareness is very useful for OLTP universes
The main use is to make objects reusable when getting
more details. For example, you could have a Journal Entrysubclass of a General Ledger class that pulls journal entryinformation. That way, the user doesnt have to build acompletely new query if he/she wants to see the journal
entries behind a general ledger balance
8/2/2019 OLTP Universe Design
36/41
2009 SAP BusinessObjects User Conference
List Of Values
Slow running list of values is a major blow to usability
Many times, the default SQL for a list of values will result in
the running of full table scan of large tables Therefore, liberally create custom lists of values
8/2/2019 OLTP Universe Design
37/41
2009 SAP BusinessObjects User Conference
Creating Custom LOVs
To support the creation of custom list of values, thereshould be a class called For LOVs
Objects whose default LOV SQL is too slow should becopied into that class and the SQL for the object should bechanged to something faster
Many times, the LOV object should use the SQL from an
object in one of the set up classes If an object is created in the For LOVs class, then the
object with the same name should have its list of values
edited to use the object in the For LOVs class Descriptions should be added to the custom list of values
whenever possible
8/2/2019 OLTP Universe Design
38/41
2009 SAP BusinessObjects User Conference
Key Learning Points
OLTP universe design is different than star schemauniverse design
A design philosophy for OLTP universes A coding standard for OLTP universes
8/2/2019 OLTP Universe Design
39/41
2009 SAP BusinessObjects User Conference
Contact Information
Phone: 214-924-6015
Email: [email protected]
Feel free to email me questions and I will do my best toanswer them
I contribute regularly to BOB (www.forumtopics.com/busobj)
8/2/2019 OLTP Universe Design
40/41
2009 SAP BusinessObjects User Conference
Questions
Ask away
My background is Oracle E-Business Suite, but I will do mybest to apply what I have learned to your OLTP
8/2/2019 OLTP Universe Design
41/41
2009 SAP BusinessObjects User Conference
Thank you for participating
Please remember to complete and return
your evaluation form following this session.
SESSION CODE:
1009
Top Related