OLTP Universe Design

Dennis W. Disney of BO4EBS

Learning Points
OLTP design issues OLTP design philosophy An OLTP design methodology

2009 SAP BusinessObjects User Conference

Who am I and why should you listen to me?

I have been doing reporting against Oracle Applications since 1993 I have been building universes for Oracle Applications reporting since 1999 I have built universes for Oracle Applications for 5 very different clients For each new generation of universes, I develop a coding standard based on what I have learned with prior universes

2009 SAP BusinessObjects User Conference

BO4EBS
BO4EBS provides customized reporting solutions for Oracle E-Business Suite to clients The reporting solution includes universes, reports, tables, PL/SQL code whatever is necessary to meet the clients reporting needs All done for a fixed price

2009 SAP BusinessObjects User Conference

Strategic Versus Tactical Reporting

Strategic reporting is about identifying trends, star performers and dogs Strategic reporting is best done with a star schema and summary tables Tactical reporting is about what needs to be done now or the details of one record Tactical reporting is best done querying against Production data tables Reporting against an OLTP should only be tactical reporting Strategic reporting against OLTP tables is too slow and puts too much of a load on the OLTP database

2009 SAP BusinessObjects User Conference

Issues An OLTP Universe Design Must Address

Double outer joins an invoice may or may not have a purchase 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 of tables, almost all of which are used for multiple purposes Performance how to build efficient queries should be fairly obvious

2009 SAP BusinessObjects User Conference

Skills An OLTP Universe Designer Should Have

Knowledge of the tables and business processes of the OLTP system Know how to describe tables and determine their indexes The ability to guess foreign key relationships based upon column names Query tuning skills

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 will never get answered

2009 SAP BusinessObjects User Conference

Universe Coding Standards

Every company that does universe development should have a coding standard for universes The universe coding standard should embody your companies best practices A universe coding standard provides consistency across universes This presentation is BO4EBSs universe coding standard This standard is for Oracle E-Business Suite, but should work for any OLTP system

2009 SAP BusinessObjects User Conference

Physical Layout Of Universe

The physical layout of the universe is key to usability/maintainability The tables that are used together should be grouped together 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

2009 SAP BusinessObjects User Conference

3 Types Of Classes
Main classes these are typically documents such as invoices, receipts and purchase orders Set up classes these are typically lists of how things are set up such as customers, suppliers and buyers General purpose classes these are classes that arent tied to a table such as objects for unions and WebI configuration

2009 SAP BusinessObjects User Conference

Class Naming
Each main and set up class should have an acronym, usually two or three letters which is at the end of every object and subclass with that class The names of main and set up classes should be in UPPER CASE and the name of all subclasses should be in mixed case Example main/set up class names PURCHASE ORDERS PO, CASH RECEIPTS CR, SUPPLIERS SUP Example subclass names Supplier PO, Cash Receipt Details CR, Supplier Sites SUP

2009 SAP BusinessObjects User Conference

Object Layout In A Class

Within a class, any objects that uniquely identify a record should be first Below those objects in the class should be the rest of the dimensions in alphabetical order After the dimensions should be the measures in alphabetical order Consistently ordering objects in this manner make them easier for users to find

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 alphabetical order.

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 derived tables 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.
2009 SAP BusinessObjects User Conference

Example Table Layout

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 to provide better performance when only summary level information is needed. In that case, each context should be the name of the class in mixed case without the acronym and with the word "Summary" or "Detail" at the end.

2009 SAP BusinessObjects User Conference

Alias Layout For Classes

The aliases for each class should be laid out in a horizontal band in the Structure pane The bands should be in the same order as the classes in the Universe window. For most classes, there will be a series of parent-child tables, with lookups for each level of detail. For example, a typical class is the JOURNAL ENTRIES JE class, which has the GL_JE_BATCHES table as a parent, the GL_JE_HEADERS table as a child and the GL_JE_LINES table as the grandchild.

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 of detail and above it should be its lookups The tables should continue to the right for each level of detail. Aliases should be in the view mode where you see the joins

2009 SAP BusinessObjects User Conference

Example Alias Layout

2009 SAP BusinessObjects User Conference

Table Acronyms
The following rules are very specific to Oracle E-Business Suite The acronym should be the first letter of each word in the table name, except no "A" should be used if the table name ends in "_ALL". For example, the acronym for MTL_SYSTEM_ITEMS_B should be "msib If two tables used together have the same acronym, one table should use a small word instead of a letter. For example xeventtt should be used for XLA_EVENT_TYPES_TL if xett has already be used for XLA_ENTITY_TYPES_TL

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 be the alias for the MTL_SYSTEM_ITEMS_B table in the class whose acronym is "PO"

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 each alias should be identified. For example, if the FND_USER table is a foreign key lookup for both the CREATED_BY and LAST_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. For example, if the table FND_USER is used for both the PO_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. In that case, the name of the table joined to should be before the purpose of the table, such as "po_ph_created_by_fu"

2009 SAP BusinessObjects User Conference

Alias Names For Derived Tables

Normally, the alias name for a derived table should be the acronym for the class, an underscore and then the derived table name If that would result in multiple aliases with the same name, the rules for base tables should be followed

2009 SAP BusinessObjects User Conference

Self-Joins
If there is a restriction that should be in the SQL for a query that applies to only one table, then that restriction should be added as a self-join to that table By doing this, the LOV for an object made from that table will be restricted to how it is used in the query.

2009 SAP BusinessObjects User Conference

Self-Join Example
An example of a self-join would be the restrictions on the FND_LOOKUP_VALUES table The po_fob_flv alias uses the FND_LOOKUP_VALUES table for the lookup value for the FOB_LOOKUP_CODE on the PO_HEADERS_ALL table The po_fob_flv alias has two self-joins: po_fob_flv.LOOKUP_TYPE='FOB' and po_fob_flv.VIEW_APPLICATION_ID=201 By creating the restrictions as self-join on the po_fob_flv alias, the LOV for an object from that table is restricted to only FOB lookups.

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 a circle to indicate that it is an outer join No cardinality should be specified

2009 SAP BusinessObjects User Conference

Examples Of Self-Joins

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 upper case

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

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 set up 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 be created and the set up classes should be copied and pasted as subclasses of the PURCHASE ORDER PO class

2009 SAP BusinessObjects User Conference

The Most Important Objects In The Main Class

For usability, the main class should have only the most important 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 have Supplier Name and Buyer objects as well as Buyer PO, Purchase Order Details PO and Supplier PO subclasses

2009 SAP BusinessObjects User Conference

Copying Main Classes Main classes should be copied to be subclasses in other main classes For example, the AP INVOICES API class should be copied and made into a AP Invoices PO class. Ditto for a Purchase Order API class These structure eliminates the double outer-join problem

2009 SAP BusinessObjects User Conference

Data Restrictions For Better Performance

Most of the queries built using an OLTP universe should have a restriction based upon an object in the main class If the query doesnt have a restriction based upon an object in the main class, it should have one based upon an object in 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

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 Entry subclass of a General Ledger class that pulls journal entry information. That way, the user doesnt have to build a completely new query if he/she wants to see the journal entries behind a general ledger balance

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

2009 SAP BusinessObjects User Conference

Creating Custom LOVs

To support the creation of custom list of values, there should be a class called For LOVs Objects whose default LOV SQL is too slow should be copied into that class and the SQL for the object should be changed 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
2009 SAP BusinessObjects User Conference

Key Learning Points

OLTP universe design is different than star schema universe design A design philosophy for OLTP universes A coding standard for OLTP universes

2009 SAP BusinessObjects User Conference

Contact Information
Phone: 214-924-6015 Email: dennis.disney@bo4ebs.com Feel free to email me questions and I will do my best to answer them I contribute regularly to BOB (www.forumtopics.com/busobj)

2009 SAP BusinessObjects User Conference

Questions
Ask away My background is Oracle E-Business Suite, but I will do my best to apply what I have learned to your OLTP

2009 SAP BusinessObjects User Conference

Thank you for participating Please remember to complete and return your evaluation form following this session.
SESSION CODE: 1009

2009 SAP BusinessObjects User Conference