03 Technology Overview1

3
Technology Overview
Copyright 2009, Oracle. All rights reserved.
Agenda
The following slides provide a high level overview of the
following topics
3-2
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
N-Tiered Architecture
4 Tiers & Supported Platforms

- UNIX (IBM, HP, Sun, Linux)
- Windows 2003
- z/OS
- IE 6.0+
Web
Server
Application
Server
- WebLogic
- WebSphere
- Tomcat*
- Oracle AS
DB
- Oracle
- DB2
- MSS
* Tomcat doesn't allow for the physical splitting of web and app
server onto separate physical boxes
3-4
The Location Of The Business Rules
Web
Server
Application
Server
There are no business rules

on the Web Server
All business rules on the UI tier are
redundant (e.g., a dropdown that
contains valid choices is not a
substitute for a backend business rule
that checks the user's choice is valid)
3-5
DB
There are no business rules

in the database (i.e., no
stored procedures or
PL/SQL)
This is where youll find all of the

business rules and all of the
database access
A Quick Word About The UI Tier
Web
Server
Application
Server
For now, accept that the UI is 100%

HTML / JavaScript where the data is
exchanged via XML documents
We'll be discussing the UI at

length later in this course
3-6
DB
We'll now describe the

database tier
Entity Relationship
Diagramming Standards
Entity Relationship Diagramming (ERD)

Throughout this class you will see many ERD's that illustrate
the tables involved in a functional area
This section describes the diagramming standard
Note well, this standard is used in blueprints and external
designs to describe new / changed tables
3-8
Information Is Stored in Tables,

Each Box In An ERD Is a Table
Customer
Class
Person
Account
Bill Msg
Code
3-9
Color-coding Highlights The "Subsystem" Where The

Table's Rows Are Typically Maintained
Customer Info
Customer
Class
Control Table
N/A
Most students find this color to be the most significant as it

highlights a table whose rows control significant business rules
(we frequently refer to these as "admin" objects and they are
accessible from the Admin menu)
Person
Account
Bill Msg
Code
3 - 10
The Power Points Use Color-coding to Logically Group

Entities
Control
Tables
Customer
Information
Billing
Rates
Meter
Management
Meter Read
Financial
Transaction
Adjustment
Field Order
Payment
To Do
Background
Process
Credit &
Collections
Workflow &
Notification
Maintained
on higher
level page
Sales and
Marketing
Framework
Meta-Data
3 - 11
Each Entity Has a Unique Identifier Called a Prime Key
Customer Info.
Customer
Class
Control Table
PK: Cust Class Code
N/A
Person
Account
PK: Person ID
PK: Bill Message Code
3 - 12
PK: Account ID
Bill Msg.
Code
We Use ERD's to Highlight Important Business

Relationships
Customer Info.
Customer
Class
Control Table
N/A
Person
PK: Cust Class Code
An account belongs to a customer class.

A customer class may have many
accounts.
A person can have many
accounts. An account
may be linked to many
persons.
PK: Person ID
Account
PK: Account ID
An account may have many bill

messages. A bill message may be
associated with many accounts.
3 - 13
Bill Msg.
Code
Relationships Between Entities Are Highlighted With

Arrows Between Boxes
Customer Info.
Customer
Class
Control Table
N/A
An account belongs to a customer class.

A customer class may have many
accounts.
PK: Account ID + Person ID
Person
PK: Person ID
3 - 14
Person/
Account
Account
A person can have many

accounts. An account
may be linked to many
persons.
Bill Msg.
Code
PK: Cust Class Code
PK: Account ID
PK: Account ID + Bill Message Code
Bill
Message
An account may have many bill

messages. A bill message may be
associated with many accounts.
Dashed Lines Represent Columns on Entities With

Predefined Lookup Values
Account
Bill
Message
The bullets show the valid values
Appearance
Flag
Values:
Always appears on bills
Appears on next bill
The Appearance Flag is not a separate table. Rather, the dashed line
means that there's a column on the Bill Message table whose valid
values are defined on the "Lookup" table. The "lookup" table is a
single table that holds valid values for many columns on many tables.
In this example, this means that the lookup table contains two valid
values for the appearance flag.
3 - 15
The Data Dictionary Is Your Primary Documentation

During the course, you will be exposed to many ERDs on PPT
slides
These ERDs are logical subsets used to reinforce important
concepts, i.e., there are typically many more tables involved in
a functional area than shown on the slides
The complete data model is viewable using the Application
Viewer
Note, most of the ERDs in this course use entity names that
match those in the Application Viewer
3 - 16
Table / Field Meta-data
The Application Viewer Is Generated From Meta-Data

The application viewer's Data Dictionary is generated by a
batch process that converts the system's "table / field"
meta-data into this graphical representation
This same table / field meta-data is also used by the
application server framework logic when it generates the
logic necessary to add, change, delete and read data
This means that the data dictionary is reliable
documentation
3 - 18
In other words, if the data dictionary is wrong, the backend SQL will
also be wrong
The "Table" and "Field" Tables

Every table has an entry on the "table" table
Every field has an entry on the "field" table
Table
A table has 1 or more

fields; a field can be on
one or more tables
Table /
Field
Constraint
Constraint
/ Field
Field
3 - 19
A table has constraints to

define its prime key and its
foreign keys
Common Data Design Patterns
Theory = Practice
We slavishly follow relational theory and design our databases
to Codd's 3rd normal form rule:
all columns are related to the key, the whole key, and nothing but the
key
If you don't know what "3rd normal form" means, you have some
homework tonight
This means: no recurring groups and no redundant data

Your intuition may tell you that a database designed according
to pure relational theory wont perform; don't believe it
Violation of Codd's rule is only allowed when youve confirmed there is
a performance problem and there is no other way to solve it
To date, we have not violated relational theory and our

systems scale to millions of customers
Both in respect of batch processing and online presentation
So you might have some trouble getting any such violation through
design review
3 - 21
A Few More Things to Keep in Mind

We avoid database-specific functions or fields
We have Oracle, DB2 and MSS customers using the same system
We are proud of our database structures and like to show

them off (our competitors typically fall apart in this area)
The data models feature prominently in our training courses
Make sure that what you design mimics the real world so it can be
explained by our colleagues and understood by our customers
3 - 22
No Recurring Groups
You won't find recurring groups of columns on our tables
Rather, we create a "child table" so each implementation can have as many different entries
as it needs
Person Id
Person
Person Id
ID Type
ID
123819812
SSN
123-23-2992
123819812
DL
CA 992829
123412352
SSN
229-20-2900
The person table doesn't

contain two columns one for
social security number and
another for drivers license.
Rather, a person's various ID's
are kept on the Person / Id
table (where each entry
references an identifier type)
3 - 23
123819812
123412352
Person /
ID
Person /
Phone
Identifier
Type
Phone
Number
Type
Person Id
Phone
Type
Phone
Number
123412352
Home
415-393-2202
123412352
Work
415-388-9474
The same is true for a

person's phones (and
names, and addresses).
You'll find this pattern
throughout the application
Prime Keys
The prime key of many "non
admin" tables is a systemassigned, random number
Person Id
"Child" tables frequently have

concatenated prime keys
Person Id
ID Type
ID
123819812
SSN
123-23-2992
123819812
DL
CA 992829
123412352
SSN
229-20-2900
The prime key of most

"admin" tables is a userassigned mnemonic
ID Type
Description
SSN
Social security
number
Drivers
license
number
DL
3 - 24
Person
123819812
123412352
Person /
ID
Person /
Phone
Identifier
Type
Phone
Number
Type
Person Id
Phone
Type
Phone
Number
123412352
Home
415-393-2202
123412352
Work
415-388-9474
Prime and Foreign Keys In The Application Viewer
PK is gold
FKs are
blue
3 - 25
Very Little (Almost No) Redundant Data
There is almost no
redundant data (not even
a column on Account that
holds its balance)
Account Id
Account
12988382
43837729
Financial
Transaction
Financial
Transaction
Type
Master Data
FT Id
Transaction Data
Child Data
129829021
129899382
129829982
129872827
Account Id
12988382
12988382
12988382
12988382
FT Type
Bill
Pay
Bill
Pay
Amount
$390.34
$-192.66
$192.66
...
We accumulate the Amount's

of the individual financial
transactions to derive an
account's balance
3 - 26
No Multi-Purpose Columns
We don't have empty "user defined fields" on our tables. Why?
There are never enough

They are never the correct data type
Rather, many objects support the notion of "characteristics" where each

implementation sets up a characteristic type for each new column they
need
Person
Person /
Char.
Characteristic
Type
Most objects have a "char" table
so implementations can "add
columns" without changing the
database
3 - 27
Language Tables
The admin tables support multiple end-user languages
An earlier diagram implied
that there's a column on the
Identifier Type table that
holds its description this is
NOT true
ID Type
Description
SSN
Social security
number
Drivers
license
number
DL
3 - 28
Person
Person /
ID
This design allows each

"identifier type" to have a
different description depending
on the end-user's language
Identifier
Type
Language
Identifier
Type /
Language
ID Type
Language
Description
DL
English
Drivers license
DL
French
SSN
Permis de
conduire
The description that

matches the user's
language appears on
the UI
XML Extensions Via CLOB's

A subset of tables have a special column that can hold an XML document
This column's data type is CLOB
This XML document is meant to be used by implementations to hold

additional attributes
In the next chapter, we'll describe how data that's stored in this XML
document is added and retrieved
We use the following diagramming technique to highlight these tables
Person
CLOB
3 - 29
This means that the person table has a

"character large object" column that holds
an XML document (the XML document will
only hold data if business objects have
been configured more about this later)
Maintenance Objects
MO Definition
Most logical transactions are made up of several tables (due to the good
relational design practices described earlier)
We use the term "maintenance object" (MO) to reference the group of tables
that hold an object's physical data
The person
maintenance object's
data is held in several
tables
Person
Person
CI_PER
Person ID
Person / ID
CI_ID_TYPE
CI_PER_ID
Person /
Name
Person /
Phone
CI_PER_NAME
CI_PER_PHONE
Name Type
CI_LOOKUP_FIELD
3 - 31
Phone Type
CI_PHONE_TYPE
Note, this is a simplification

as this MO has more than
4 tables
Why MO's?
We don't like logical processing to communicate directly with tables
Rather, we prefer logic to "send messages" to a maintenance object (e.g., read a person, add a person, change a
person, etc.) and then the MO can determine how to satisfy the request
You will find that messages are sent to MO's via an XML document and that the MO will publish an XML document
in response
Person
To reiterate most of your

logic will work with MO's,
not with individual tables
Person
CI_PER
Person / ID
CI_PER_ID
3 - 32
Person /
Name
Person /
Phone
CI_PER_NAME
CI_PER_PHONE
Primary Table versus Child Tables

A MO has a single "primary" table (this is the top one)
A MO can have many "child" tables (and children can have
children)
Person
This is the person MO's

primary table
Person
These are all child

tables
CI_PER
Person ID
Person / ID
CI_ID_TYPE
CI_PER_ID
Person /
Name
Person /
Phone
CI_PER_NAME
CI_PER_PHONE
Name Type
CI_LOOKUP_FIELD
3 - 33
Phone Type
CI_PHONE_TYPE
MO, Table, Field ERD
The MO, table and field meta-data is very important as it is used to generate the
java classes that add, change, delete and read a maintenance object
If it's wrong, the system won't work
The MO meta-data is also used by many other "framework" processes (described

later)
Table
Table / Field
MO
MO Def /
Table
Primary
This symbol means that

there are different types of
rows on this table
Child
Field
3 - 34
MO's Are Also In The App Viewer

If you click this icon, you'll be
transferred to this table's MO (if the
table is part of multiple MO's, there are
multiple icons)
You are now shown the tables linked to

the respective MO
These are all of the MO's
3 - 35
One More Piece Of The Puzzle

Every MO should have at least one FK reference
The FK reference defines:
The program used to construct the MO's info string (info strings appear
throughout the UI, for example, whenever an account is displayed on a page,
a description of the account appears, this description is what we refer to as an
"info string")
The transaction used to display / add / update instances of this MO
We point this out as you'll use FK Ref's extensively when you develop
business objects and user interface
Table
FK
Reference
This is the MO's primary table
3 - 36
Characteristic = User Defined Field
User-Defined Fields Extend

Birth Date =
12/10/64
Persons
County Parcel ID =
A234993
Places
Elevation =
1000ft
Customer
Count = 4
Contracts
Things
Other
Things
3 - 38
Number
Wires = 3
...
Volts
= 240
Most MO's Support Characteristics

We use the term characteristic rather than user-defined field
Implementations set up a characteristic type for each user-defined field
needed by any MO
A child table holds an MO's user-defined fields
In other words, most MO's can have an unlimited number of characteristics

Premise
Premise /
Char
Char
Type
An implementation
can set up an
unlimited number of
user-defined fields for
their premises (here's
an example of a
premise with 6 chars)
3 - 39
There Are 4 Types Of Char Types

Each characteristic's char type defines its category
The upcoming slides provide examples of each
Char
Type
Predefined
Value
3 - 40
Ad hoc
Value
Foreign Key
Reference
File
Location
Predefined Char Types

Pre-defined char types are used when the user-defined field
has a discreet set of valid values
Char
Type
Gender
Male
Female
3 - 41
Predefined
Value
Ad hoc
Value
Foreign Key
Reference
Valid Value
File
Location
Ad Hoc Characteristic Types

Ad hoc char types are used when the user-defined field holds
a date, a string, or a number
Birth
Date
Defined
Value
Ad hoc
Value
Char
Type
Foreign Key
Reference
File
Location
Valid Date
Validation
Algorithm
3 - 42
Optionally, a validation algorithm can be

defined (for example, you could indicate
the ad hoc char value must be a date in
the format YYYYMMDD)
Foreign Key Reference Characteristic Types

FK char types are used when the user-defined field holds a
foreign key
Char
Type
Defined
Value
Ad hoc
Value
Property
manager
Foreign Key
Reference
A FK ref char type must reference a FK ref

In this example, the foreign key reference
char type would reference the Person FK
ref. This means that the char value must
be a foreign key to the person table
3 - 43
FK
Reference
File
Location
File Location Characteristic Types

File location char types are used when the user-defined field
holds a reference to a file location or URL
Char
Type
Defined
Value
3 - 44
Ad hoc
Value
Foreign Key
Reference
Customers
Contract
File
Location
Characteristic Values Are Effective-Dated On Some

Entities
Note that some MO's char collection contains an effective
date
This allows the char value to change over time

Premise
Premise /
Char
Characteristic
Type
Notice how the Taxing
county changes (and
therefore the tax rate
will change on this
effective date)
3 - 45
A Char Type Can Be Used On Multiple Entities

When a char type is set up, in addition to defining its category
(ad hoc, predefine, FK ref, file location), you must define
which entities / MO's that it can be defined on
Char
Type
Entity
Char Type
/ Entity
3 - 46
Values:
- Person
- Account
- SA
- Premise
- SP
- Meter
- Item
- Meter Type
- Item Type
- SP Type
- SA Type
- Device Test
- Distrib. Code
etc..
Maintenance Objects Are More Than Data

Structures
MO's Encapsulate Core Business Rules

When an MO is created, we design both its physical tables and its core
business rules (e.g., validation)
These business rules are written in Java or Cobol
MO's that are owned by the framework are written in Java

Older MO's that are owned by the base-product are written in Cobol (over
time, these are being re-written in Java)
All new MO's are written in Java
These core business rules can be extended by an implementation team

Note well:
3 - 48
You cannot change or remove core business rules, you can only add to them
MO's that are written in Cobol can be extended by writing Java or Cobol
MO's that are written in Java should only be extended by writing Java (but this
isn't strictly enforced)
Foreshadowing
However, rather than write and compile code, there are many
more elegant ways to add business rules to a MO
You'll learn about these in the next chapters
3 - 49
Data Ownership
Owning Meta-data
As you can probably guess, the meta-data is an integral part
of the system
Much of this meta-data is interpreted at execution time and is
therefore shipped with our software
We don't want implementations to change this meta-data
because:
These changes could cause the system to malfunction (e.g., removing

a field from a table would be very bad)
Future upgrades rely on the fact that we know how tables (and MO's)
look (imagine what would happen if an implementation added a field to
a table and then, in a future upgrade, we did too)
To prevent inadvertent changes, most meta-data tables have

a column called owner flag
3 - 51
Owner Flag ERD

The owner flag is simply a column on a table that references
the "product" that owns it
The installation record references the "product" that owns the
installed system. For example,
In a framework environment, the installation record references the F1

(framework) owner flag
In a CCB environment, this record references the C1 (base) owner
In a customer's environment, this record references the CM
(customer) owner
This flag cannot be changed after the system is installed

Owner Flag
3 - 52
Installation FW
Owner Flag Is Ubiquitous

MO
Field
Owner Flag
Table
Char Type
You've only been exposed
to a small percentage of the
tables that have "owned"
meta-data
3 - 53
The System Stamps Owner Flag On New Meta-Data

Rows
When you add a row to a meta-data table, the system flags it with the implementation's active owner
flag
Remember, the implementation's owner flag is on the installation record
The system will not allow changes to a row if the row's owner flag is not the same as the
implementation's owner flag
For example, an implementation will not be able to change data owned by the base-package
For example, if an implementation adds a new MO, the MO will be marked with an owner flag of CM
(given this is the value on the implementation's installation record)
CM
Owner Flag
3 - 54
Installation FW
If you were to look at an

implementation's installation,
you'll find an owner flag of CM
(customer modification)
A Table's Rows Can Span Owners

It may be obvious, but we wanted to stress that ownership is at the row level and therefore different rows
can have different owners
For example, the following is a sample of rows on the table that holds field meta data (a separate row
exists for every field in the system)
Field
Field
Description
VERSION
RS_CD
MSG_ID
DOB
Version
Rate Code
Message Id
Date of Birth
This field is owned by a

"subpackage" team and
cannot be changed by
anyone else
3 - 55
Owner Flag
Owner
F1
C1
A2
CM
This field is owned by the

framework team and cannot
be changed by anyone else
base (CCB) team and
cannot be changed by
anyone else

customer and cannot be
changed by anyone else
Typically, All Child Rows Are Governed By The Owner

On The MO's Primary Table
Message MO
Owner Flag
Message
Message /
Language
Language
3 - 56
The owner flag on the MO's

primary table TYPICALLY
governs all rows and columns
on all child tables
However, there are some

idiosyncratic child tables and
columns that can be added and
changed regardless of owner
For example, the CI_MSG_L table
has a column called
MESSAGE_TXT_OVRD that can
be populated regardless of the
value of the message's owner flag
(this is intentional so an
implementation can change
messages and have the changes
survive the upgrade)
Don't Even Think About It

If you don't like something someone else owns and you think
that you'll just change the row's owner flag outside of the
application (e.g., via ad hoc SQL), DON'T DO IT
If you do, when you next upgrade, the upgrade scripts will
override any such changes (as ownership is reapplied during
an upgrade)
Similarly, if you use SQL to change data on a row that your
implementation doesn't own, the next upgrade will revert your
changes
3 - 57
Adding A New MO
New MO's Are Designed Before Being Created

Many requirements will necessitate the creation of new MO's
and the related designs will describe the necessary tables
and columns
3 - 59
Steps To Add A New MO
Given a good design is your starting point, the following points describe
the steps necessary to create a new MO:
1. Create the tables, columns, indexes, and constraints in the database (this
typically involves a DBA; there are no tools within the application to do this)
2. Populate the system's table / field meta-data to match the information in the
database. You use the transactions you used in this chapter to do this.
3. Populate the system's MO meta-data with information about your new tables.
Again, you'll use the transactions you used in this chapter to do this.
4. Use the MO Wizard to generate the Java annotations (you must use Eclipse to
access this wizard). You'll learn about this wizard in the Java developer class.
5. Rebuild the shared Java environment with your new annotations
6. Create a FK reference meta-data object for your new MO
Bottom line - you should not have to write any Java (the system will use
the generated annotations to add, change, delete and read your new MO)
Note Java coding is only necessary if there is specific validation or

update logic called for in the design (and this is not terribly common (you'll
learn why soon))
3 - 60
Team Walk Through (60 minutes)

Explore MOs, tables and field meta-data
3 - 61
Break up into teams and follow the instructions in the workbook
Review Questions
3 - 62
3 - 63
3rd Normal Form (as per Date and Codd)

First Normal Form
Make attributes atomic, remove repeating fields
Second Normal Form
Remove attributes that are functionally dependent on any part of the

key
If a relation is in FNF and does not have a composite key, it is already in

SNF
Third Normal Form
3 - 64
Remove attributes that are functionally dependent on non-key

attributes.

03 Technology Overview1

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

03 Technology Overview1

Загружено:

Авторское право:

Доступные форматы

3

Copyright 2009, Oracle. All rights reserved.

N-tier architecture and supported platforms

Copyright 2009, Oracle. All rights reserved.

Copyright 2009, Oracle. All rights reserved.

4 Tiers & Supported Platforms

Copyright 2009, Oracle. All rights reserved.

The Location Of The Business Rules

There are no business rules

There are no business rules

This is where youll find all of the

Copyright 2009, Oracle. All rights reserved.

A Quick Word About The UI Tier

For now, accept that the UI is 100%

We'll be discussing the UI at

Copyright 2009, Oracle. All rights reserved.

We'll now describe the

Copyright 2009, Oracle. All rights reserved.

Entity Relationship Diagramming (ERD)

Copyright 2009, Oracle. All rights reserved.

Information Is Stored in Tables,

Copyright 2009, Oracle. All rights reserved.

Color-coding Highlights The "Subsystem" Where The

Most students find this color to be the most significant as it

Copyright 2009, Oracle. All rights reserved.

The Power Points Use Color-coding to Logically Group

Copyright 2009, Oracle. All rights reserved.

Each Entity Has a Unique Identifier Called a Prime Key

PK: Cust Class Code

PK: Bill Message Code

Copyright 2009, Oracle. All rights reserved.

We Use ERD's to Highlight Important Business

PK: Cust Class Code

An account belongs to a customer class.

An account may have many bill

Copyright 2009, Oracle. All rights reserved.

Relationships Between Entities Are Highlighted With

An account belongs to a customer class.

PK: Account ID + Person ID

PK: Bill Message Code

A person can have many

PK: Cust Class Code

PK: Account ID + Bill Message Code

Copyright 2009, Oracle. All rights reserved.

An account may have many bill

Dashed Lines Represent Columns on Entities With

The bullets show the valid values

Copyright 2009, Oracle. All rights reserved.

The Data Dictionary Is Your Primary Documentation

Copyright 2009, Oracle. All rights reserved.

Table / Field Meta-data

Copyright 2009, Oracle. All rights reserved.

The Application Viewer Is Generated From Meta-Data

Copyright 2009, Oracle. All rights reserved.

The "Table" and "Field" Tables

A table has 1 or more

Copyright 2009, Oracle. All rights reserved.

A table has constraints to

Common Data Design Patterns

Copyright 2009, Oracle. All rights reserved.

This means: no recurring groups and no redundant data

To date, we have not violated relational theory and our

Copyright 2009, Oracle. All rights reserved.

A Few More Things to Keep in Mind