C

TECHNICAL OVERVIEW

Overview
This section provides a high level overview of the following topics
N-tier architecture and supported platforms

Entity relationship diagramming standard

How to use the data dictionary

Table / field meta-data

Common table / field design patterns

Maintenance object meta-data

Data ownership (what you can change and what you can't)

How to add a new maintenance object

Chapter 3

Objectives
By the end of this chapter, you will be able to:

Understand how to read an ERD in a design document

Understand the basic meta-data objects that describe how data is physically
stored on the database
Understand how to use the application viewer to see the system's tables, fields
and maintenance objects
Understand how the system protects data from being changed in order to allow
future upgrades to run smoothly
Understand, at a high-level, the steps necessary to add a new maintenance
object to the system

2016 Oracle Proprietary and Confidential

Technical Overview

10-Oct-16

Oracle Configuration Tools Training Workbook

Walk Through Explore MOs, Tables, and Field Meta-Data

During this walk through, you will use the following transactions to explore the MO / table
/ field meta-data:

Admin Application Viewer (both MO and table modes)

Admin Maintenance Object

Admin Table (you should be able to drill to this from the MO page)

Admin Field (you should be able to drill to this from the Table page)

Admin FK Reference (you'll have to find this using the search)

Admin Installation Options Framework

For this exercise you should split up into teams. Each team should do the following:
Read the portion of the Adjustment Approval blueprint that describes the
design's new / changed MO's (don't go past the MO section).
Prepare a presentation describing the differences between the MO / tables /
columns designed in the blueprint versus what was released.
In addition, try to change the description on one of the fields on the approval
profile table and see what happens; please include an explanation of why you
couldn't change the description in your presentation.
Also, prepare a list of table and column naming conventions that you were able
to discern while using the application viewer.

Instructors Notes
The approval profile design in the blueprint is very close to what was released. The
only differences are:
-The addition of VERSION (all tables must have this column to control concurrency)
-The addition of the long description column on the language table. This is a pretty
strong standard.
The approval request design is also very similar to what was released. The only
differences are:
-The addition of VERSION (as above)
-Notice how the blueprint just says "standard char table" and "standard log table".
Explain that the columns on char and log tables are always the same for all MO's. If
you get asked, feel free to elaborate on the use of these tables on transactional
MO's (chars are meant for implementations to add new fields that they need to join
to and the log is meant to hold significant events over the MO's life (e.g., when
created, when completed, state transition stuff). Logs will be discussed in detail in
the Lifecycle chapter a bit later in the course.
-You might want to point out the standard normalized table that holds the values of
fields substituted into the log's message parms as this highlights how the message
table is multi-lingual with substitution parameters.

3 - 2 Technical Overview

2016 Oracle Proprietary and Confidential

Oracle Configuration Tools Training Workbook

10-Oct-16

Note, the students won't know what the BO FK is yet that is referenced on both the
approval profile and the approval request MO's. If it comes up, explain all will be
unveiled in the next chapter.
The reason why they can't change the column's description is because the owner
flag on the installation framework (main) page is Customer Modification and the
owner flag on the field is Base. Because these don't match, the framework won't let
them change the field's description.
Some simple naming conventions:
-Tables have a 2 digit prefix that should match the owner (you'll notice that it's not
exact as these tables should have a prefix of C1 and they've been prefixed CI this
is because we only instituted this rule after the original release where we had
prefixed tables with CI and we felt it was better to be consistent). For all other
products, we are abiding by this rule.
-Admin objects have a user assigned PK that is suffixed with _CD (code)
-Transaction objects have a system assigned PK that is suffixed with _ID (id)
-CLOB's are frequently called BO_DATA_AREA
-Language tables always reference a column called LANGUAGE_CD
-DT is the standard abbreviation for columns holding dates
-DTTM is the standard abbreviation for columns holding time
-_FLG is the standard suffix for columns referencing "lookup" values
-NBR is the standard abbreviation for number

2016 Oracle Proprietary and Confidential

Technical Overview

Chapter 3

-Most tables have a VERSION column that's used by the FW to control concurrency
(the only tables that don't have this are "key" tables tables that hold the PK of
transaction tables that are maintained even after the transaction row is archived off
the database.

10-Oct-16

Oracle Configuration Tools Training Workbook

Review Questions
1. You must create an entry in the Field table for every column on every table.
True/False
The only reason we say False is because some columns on a table might already
exist in the field meta-data and therefore they can be reused on new tables.
2. The translation team translates every field's description into the released languages.
Therefore, it's important to reuse fields when possible. True/False
3. If you see a Description field on a screen, you will find a "language table" in the
database because the description will differ for each released language. True/False
4. New table names are always prefixed with the owner flag of the product that owns
the table. True/False
5. Every table has a column called OWNER_FLG. True/False
Only tables that hold meta-data have this column.
6. The prime key of most "admin" tables is a user-defined code whereas the prime key
of most "transaction" tables is a system-assigned number. True/False
7. All rows in a table that has an owner flag column will have the same owner.
True/False
A given table can have rows that belong to many different owners.
8. A base-product development environment can change data owned by the
framework. True/False
9. There are 100's of maintenance objects in the product shipped to the customer.
True/False
10. Most of these maintenance objects are constructed of multiple tables, but there are
some MO's with a single table. True/False
11. The Application Viewer is simply a concise way to view the MO, table, and field
meta-data. True/False
12. If you change the MO or table meta-data, you must submit a batch job to regenerate
the Application Viewer. True/False
13. An implementation team can add new columns to base-product owned tables.
True/False
14. Adding a new MO is something you can do entirely from the system's Administration
menu. True/False
Youd need to generate the annotations and you need Eclipse to do this. In addition,
youd need to generate the DDL to physically add the table(s), columns, indexes, and
constraints.
15. What would happen if an implementation team added a table and then, in the next
release, the base-package team added a table with the same name?
The upgrade process would overwrite the implementation team's table with the basepackage table. This is why we practice naming conventions of prefixing all tables
with the owner flag. There are some historical tables where this was not done (e.g.,
CI_PER).

3 - 4 Technical Overview

2016 Oracle Proprietary and Confidential

Oracle Configuration Tools Training Workbook

10-Oct-16

Chapter 3

2016 Oracle Proprietary and Confidential

Technical Overview