OLTP Universe Design

8/2/2019 OLTP Universe Design

1/41

OLTP Universe Design

Dennis W. Disney of BO4EBS


2/41

2009 SAP BusinessObjects User Conference

Learning Points

OLTP design issues

OLTP design philosophy

An OLTP design methodology


3/41


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


4/41


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


5/41


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


6/41


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


7/41


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/41


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


9/41


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


10/41


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


11/41


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


12/41


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


13/41


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


14/41


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.


15/41


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.


16/41


Example Table Layout


17/41


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.


18/41


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.


19/41


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


20/41


Example Alias Layout


21/41


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


22/41


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"


23/41


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"


24/41


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


25/41


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.


26/41


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.


27/41


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


28/41


Examples Of Self-Joins


29/41


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


30/41


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


31/41


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


32/41


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


33/41


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


34/41


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


35/41


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


36/41


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


37/41


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


38/41


Key Learning Points

OLTP universe design is different than star schemauniverse design

A design philosophy for OLTP universes A coding standard for OLTP universes


39/41


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)


40/41


Questions

Ask away

My background is Oracle E-Business Suite, but I will do mybest to apply what I have learned to your OLTP


41/41


Thank you for participating

Please remember to complete and return

your evaluation form following this session.

SESSION CODE:

1009

Documents

OLTP Universe Design