Siebel 8.

0 Essentials

Data Layer Configuration 1 of 24

Module 32: Data Layer Configuration
Module Objectives

• Creating extension columns in a table

• Creating custom tables
–Standalone table
–1:1 extension table
–1:M extension table
–Intersection table

Data Layer Configuration 3 of 24

Business Requirement

• A company’s business requirement may include:

–Adding new fields to capture additional data
–Creating new business components to capture additional business entities

• Solution – Extending the Siebel database may be the required

solution
–Addition of columns to existing tables
–Creation of new standalone database tables to support new business
components

Data Layer Configuration 4 of 24

Prior to Extending..

• Prior to extending the Siebel database, consider using:

– Unused columns in an existing table
– Existing 1:M extension table

Data Layer Configuration 5 of 24

Unused columns in an Existing Table
• See if the new fields can be mapped to existing unused columns in
base or 1:1 extension tables
–Verify if the candidate column has the desired type
–Consider performance impact of a join to the 1:1 extension table

1:1 Extension
table of
S_CONTACT

Unused
columns

Data Layer Configuration 6 of 24

Existing 1:M Extension Tables

• See if the new BC can be mapped to an existing and appropriate

1:M extension table
– Verify that the business component has the correct M:1 relationship to the
parent BC

New BC has M:1

relationship with parent
(Contact). In this case can
use S_CONTACT_XM as
base table for BC

Data Layer Configuration 7 of 24

Extending the Database
• Extending the database changes the database schema
–Requires propagating the changes to:
• Other developers during development stage
• Mobile users after development for applications in production
• Production enterprise after development and testing

• Extending the database requires creating additional object definitions

to:
–Map columns in the EIM tables needed to import and export data to the
extension columns and tables
–Specify how data for these extension columns and tables are to be routed to
remote users (Dock Objects)

Data Layer Configuration 8 of 24

Using Siebel Tools to Extend the Database
• Using Siebel Tools, you can create new:
–Extension columns on Base tables
–Standalone tables
–1:1 extension tables
–1:M extension tables
–Intersection tables

• Creates new object definitions for database extension

–Invokes wizard to build new tables

• Makes the corresponding physical database changes

Data Layer Configuration 9 of 24

Best Practices for Extending the Siebel Database

• When adding a new column:

–If the column is not populated very often, use an existing column in an
extension table, if available
–If field is often populated, avoid join overhead by using adding an extension
column to base table

• If data for column appears in:

–A form applet - use an existing column in an extension table
–A list applet - use an extension column in the base table

Data Layer Configuration 10 of 24

Creating a Custom Extension Column
• The steps needed to follow to create a custom extension column are:
–Check out the appropriate project
–Select the table to be extended
–Create a new column with the desired properties (Right-Click->New Record)
• The name of the new column is automatically prefixed with ‘X_’

Data Layer Configuration 11 of 24

Creating a New Table
• Use the Table Wizard to create a new table
–Select File > New Object > Table

• Four types of tables can be created:

–Standalone table
–1:1 extension table
–1:M extension table
–Intersection table

Data Layer Configuration 12 of 24

Creating a Standalone Table
• The Table Wizard creates standalone tables with:
–Type - Data(Public)
–Nine system columns
–One index P1 on ROW_ID

Data Layer Configuration 13 of 24

Creating a 1:1 Extension Table
• The Table Wizard creates an extension table with:
–Ten system columns – an extra PAR_ROW_ID column as a foreign key
column to the base table
–Two indexes:
• P1 index on ROW_ID
• U1 index on PAR_ROW_ID and CONFLICT_ID
• When creating a 1:1 extension table, specify the base table as input to
the table wizard
–Has to be of type Data(Public)
• Multiple extension tables relate directly to the base table, and not to
each other

S_PROD_INT CX_PROD_INT_X

NEW_COLUMN

PAR_ROW_ID
PART_NUM
UOM_CD
ROW_ID

ROW_ID
NAME

Data Layer Configuration 14 of 24

Creating a 1:M Extension Table
• An extension table should be created only if the parent table does not
have an existing 1:M extension table
• Provide a parent table as input to the Table Wizard
–Must be of type Data(Public)

Data Layer Configuration 15 of 24

Creating a 1:M Extension Table…

• Table Wizard creates a 1:M Extension Table with:

–Type – Data(Public)
–Ten system columns – nine required and PAR_ROW_ID columns
–TYPE and NAME columns
–Three indexes:
• P1 index on ROW_ID
• U1 index on PAR_ROW_ID, TYPE, NAME and CONFLICT_ID
• M1 index on TYPE and NAME

Data Layer Configuration 16 of 24

Creating an Intersection Table
• Select both the parent tables
–Choices restricted to type Data(Public)
• Specify the foreign key column name for each parent table

Data Layer Configuration 17 of 24

Creating an Intersection Table…

• Table Wizard creates an intersection table with:

–Type – Data (Intersection)
–Nine system columns
–Two foreign key columns
–Three indexes:
• P1 index on ROW_ID
• U1 index on two foreign key columns, TYPE and CONFLICT_ID
• F1 index on foreign key to second parent table

Data Layer Configuration 18 of 24

Applying and Propagating Database Changes

• Changes must be tested locally before applying them onto the

server database
– Reduces likelihood of undesired changes to server schema

• Best practice to change the schema is:

1. Apply changes to the local database
2. Propagate changes to the server database
3. Propagate changes to other developers

Data Layer Configuration 19 of 24

1. Apply Changes to Local Database
• Click Apply/DDL to make the physical database changes
– Applies schema changes or generates DDL script
– Changes are preserved across Siebel application upgrades
• Compile relevant objects and projects
• Test the changes locally before checking in to server
– Use a SQL utility to check the tables and columns changes

DDL: Stands for Data

Definition Language, the
subset of SQL
statements used to
define and manipulate
database objects.
Typical SQL commands
used in DDL are
CREATE, DELETE,
ALTER, and so on.

Data Layer Configuration 20 of 24

2. Propagate Changes to Server Database
• Check the project into the server
–Copies the table and column object definitions
• Apply changes to the server database
–Press the Activate button on the Table object on the server machine, to
make the changes visible. The Activate button updates the schema version
in the S_APP_VER table. The schema version signals clients, mobile clients
and server components that a schema change has been made and that they
need to update their own logical or physical schemas
• Compile and test against the server database

Data Layer Configuration 21 of 24

3. Propagate Changes to Other Developers

• Other developers need to apply changes to their local database

–They need to Get or Check Out the project and apply the changes locally
–Alternatively, re-extract the developers and have them get all projects

Data Layer Configuration 22 of 24

Module Highlights

• Alternatives to extending Siebel database schema:

– Utilize unused columns in an existing table
– Use an existing 1:M extension table if appropriate
• Extend the Siebel database in Siebel Tools:
– Add an extension column to an existing table
– Use the Table wizard to create a new table:
• Standalone
• 1:1 extension table
• 1:M extension table
• Intersection table
• Best practices to modify Siebel database schema:
– Apply changes locally and test
– Propagate changes to the server database
– Propagate changes to other developers
33

Data Layer Configuration 23 of 24

Lab

• In the lab, you will:

–Create a custom extension column on a table in the sample database

Data Layer Configuration 24 of 24