Dinesh Chandrasekar Database Theory For Siebel Enterprise Applications

Database Theory for Siebel Enterprise Applications

DATABASE THEORY FOR
SIEBEL ENTERPRISE
APPLICATIONS

07/29/10 Dinesh Chandrasekar - Practice Head CRM & MDM CoE
Sierra Atlantic White Paper Page 1 of 31


OVERVIEW .................................................................................................................3
DATABASE TABLES ...................................................................................................4
Features of Tables ........................................................................................................................ 4
Standard Columns ...................................................................................................................... 4
KEYS ...........................................................................................................................6
Primary Keys............................................................................................................................... 6
User Keys .................................................................................................................................... 6
Foreign Keys ................................................................................................................................ 6
NORMALIZATION......................................................................................................7
Definition of Normalization ........................................................................................................ 7
Normalizing a 1:M or a M:1 Relationship.................................................................................. 7
Normalizing a M:M Relationship ............................................................................................... 8
Mapping Data in Siebel Enterprise Applications ..................................................................... 11
JOINS ........................................................................................................................13
Purpose of a Join ........................................................................................................................ 13
Inner Joins ................................................................................................................................. 13
Outer Joins ................................................................................................................................ 14
Defining a Join in Siebel Tools .................................................................................................. 17
Using a Join in Siebel Tools ...................................................................................................... 19
LINKS .......................................................................................................................21
Purpose of a Link ....................................................................................................................... 21
1:M Links .................................................................................................................................. 21
M:M Links ................................................................................................................................ 22
Defining a Link in Siebel Tools ................................................................................................. 22
Using a Link in Siebel Tools ..................................................................................................... 24
INDICES....................................................................................................................25
Purpose of an Index ................................................................................................................... 25
Performance Gains from Indices ............................................................................................... 25
Enforcement of Data Uniqueness with Indices ......................................................................... 30



OVERVIEW
This document is intended to develop a reader’s expertise with Siebel Tools through an
introduction to database theory and design. Since a vast majority of the configuration work
done with Siebel involves configuring Siebel’s interaction with the database, this type of theory
is extremely useful. One will not attain expertise in Siebel Front-End Configuration if one does
not understand how a database works.
All content herein is geared specifically towards Siebel Enterprise Applications. Aspects of
database theory and design that do not apply to Siebel Enterprise Applications are not included.
Those with introductory exposure to database theory may wish to skip past the first few
sections. The chapters are arranged in increasing order of complexity.



DATABASE TABLES

Features of Tables
Tables are the building blocks of a database. Tables contain information about an Entity. An
Entity can be any thing – a person, a business, a service request, and so on. All of the tables in
the database (there are 463 main tables in Siebel 98) contain all of the information used by
Siebel.
A table contains rows and columns. Figure 1 uses part of Siebel’s Contact table, S_CONTACT,
to illustrate these features.

Table Name S_CONTACT
ROW_ID LAST_NAME FST_NAME MID_NAME Column Name
1-3K Johnson Pat K
Row 1-3L Grothe Steven J
1-3M Shimizu Kanae A
Figure 1: Features of a Database Table

Column

Every table has a name. In a database, all tables follow a standard naming convention. In
Siebel, all standard tables are named S_XXX where XXX describes the Entity that resides in that
table. Each row contains information about a specific record. For example, the record
containing information for Steven Grothe is highlighted. All of the information pertaining to
Steven Grothe as a Contact will be stored in this record. Each column contains information
about an attribute of the Entity. For example, the MID_NAME column contains the middle
initials for each record in that database table. Table names and column names are always in
upper case and always use underscores (_) instead of spaces.

Standard Columns
Every Siebel database table contains a standard set of columns. These columns appear in every
table. These are the CONFLICT_ID, CREATED, CREATED_BY, LAST_UPD, LAST_UPD_BY,
MODIFICATION_NUM, and ROW_ID. The CONFLICT_ID column will be explained later.
CREATED contains the date that the record was created. CREATED_BY is the person who
created the record. LAST_UPD contains the date that the record was last modified.
LAST_UPD_BY is the person who last updated the record. MODIFICATION_NUM contains


the number of times that the record has been modified. The ROW_ID will be explained in the
next section.



KEYS

Primary Keys
A “key” refers to something that identifies one and only one record in a table. The primary key
is the most unique identifier for a record. In other words, every record in a table has a unique
primary key. Thus, the primary key is said to “uniquely identify” a record in the database. In
Siebel, the ROW_ID is the primary key for every table. Each record in a table will have its own
unique ROW_ID.

User Keys
User keys are also unique identifiers for a record. They often consist of more than one column.
The columns that make up a user key are usually more business-rule related than database
related. For example, the user key for a contact is the contact’s First Name, Middle Name, Last
Name, and the Account of which they are a part. From a business standpoint, this user key
means that there can never be two contacts that have the name First Name, Middle Name, and
Last Name at the same Account. In this way, user keys are unique identifiers – if I know the
First Name, Middle Name, Last Name, and Account of a contact, then that will point me to one
and only one record in the S_CONTACT table.

Foreign Keys
A foreign key is used to relate records in one table to records in another table. For example, let’s
say you wanted to join a Contact to its Account. You would need to join the record in
S_CONTACT (the table that contains contacts) to the record in S_ORG_EXT (the table that
contains ORGanizations that are EXTernal to the client). To do this, the record in S_CONTACT
would need a “pointer” to the one Account record in S_ORG_EXT. The best way to uniquely
identify the one Account record is for this pointer to contain the primary key, or ROW_ID, of
the Account. This is illustrated in Figure 2 where PR_DEPT_OU_ID in S_CONTACT is a
foreign key to the ROW_ID in S_ORG_EXT.
S_CONTACT S_ORG_EXT
ROW_ID LAST_NAME FIRST_NAME MID_NAME PR_DEPT_OU_ID ROW_ID NAME LOC
1-3K Johnson Pat K 1-1VDB 1-1VDB Acme HQ
1-3L Grothe Steven J 1-1VDB 1-1VDC ABC Corp. East
1-3M Shimizu Kanae A 1-1VDC

Figure 2: Foreign Keys



NORMALIZATION

Definition of Normalization
Normalization refers to the process of optimally constructing a database schema. The word
“schema” refers to the collection of tables in a database and the way they are designed to
interrelate. An understanding of normalization can help a developer decide where to store data
in the database. It can also help developers decide where to add extension columns or
extension tables. At a high level, normalization refers to storing data in such a way that
duplication is minimized.

Normalizing a 1:M or a M:1 Relationship
Databases can have “many-to-one” relationships and “one-to-many” relationships. For
example, there can be many Opportunities at one Account. Many-to-one relationships are
simply designated as “M:1”. From the Account point of view, one Account can have many
Opportunities. One-to-many relationships are simply designated as “1:M”.
In Siebel, there can be many Contacts for an Account. If this information were stored in one
table, the Account information would be duplicated several times as shown in Figure 3.
LAST_NAME FIRST_NAME MID_NAME ACCNT_NAME ACCNT_LOC
Johnson Pat K Acme HQ
Grothe Steven J Acme HQ
Shimizu Kanae A ABC Corp East
Pent John D ABC Corp East
Bjorkegren Cecilia U ABC Corp East
Figure 3: Duplication from Denormalized Data in a 1:M or a M:1 Relationship

If the ABC Corp changed its name to the XYZ Corporation, this change would need to be made
in several rows in the database. This is one of the problems associated with insufficient
normalization. It would be best to store the Account information in a separate table as
illustrated in Figure 4.



S_CONTACT S_ORG_EXT
ROW_ID LAST_NAME FIRST_NAME MID_NAME PR_DEPT_OU_ID ROW_ID NAME LOC

1-3K Johnson Pat K 1-1VDB 1-1VDB Acme HQ
1-3L Grothe Steven J 1-1VDB 1-1VDC ABC Corp. East

1-3M Shimizu Kanae A 1-1VDC
1-3N Pent John D 1-1VDC

1-3O Bjorkegren Cecilia U 1-1VDC

Figure 4: Normalizing a Many-to-One Relationship

With the tables constructed in this fashion, there is no duplication. This is the best way to
represent a M:1 or a 1:M relationship.

Normalizing a M:M Relationship
Databases can also have “many-to-many” relationships. For example, an Opportunity can have
many Contacts, and a Contact can be a part of many Opportunities. Many-to-many
relationships are simply designated as “M:M”.
If a M:M relationship were stored in one table, information for both entities would be
duplicated many times as shown in Figure 5.
LAST_NAME FIRST_NAME MID_NAME OPTY_NAME OPTY_LEAD_QUALITY

Johnson Pat K Accounting system Very High
Johnson Pat K AMCO POS servers Fair
Grothe Steven J AMCO POS servers Fair
Shimizu Kanae A AMCO POS servers Fair
Shimizu Kanae A NAPA A/R project Excellent
Shimizu Kanae A PC Deal High
Pent John D PC Deal High
Bjorkegren Cecilia U PC Deal High
Figure 5: Duplication from Denormalized Data in a M:M Relationship

If either Contact information or Opportunity information were changed, this change would
need to be made in several rows in the database. However, because this is a M:M relationship,
moving only one of the entities into its own table would still lead to duplicated data as shown
in Figure 6.

S_CONTACT S_OPTY
LAST_NAME FIRST_NAME MID_NAME OPTY_ID ROW_ID NAME LOC
Johnson Pat K 1+SD6 1+SD6 Accounting system Very High

Johnson Pat K 1+SD7 1+SD7 AMCO POS servers Fair
Grothe Steven J 1+SD7 1+SD8 NAPA A/R project Excellent

Shimizu Kanae A 1+SD7 1+SD9 PC Deal High
Shimizu Kanae A 1+SD8

Shimizu Kanae A 1+SD9
Pent John D 1+SD9
Bjorkegren Cecilia U 1+SD9

Figure 6: Duplication from Improperly Normalized Data in a M:M Relationship

M:M relationships are best represented by the use of what is called an intersection table. An
intersection table stores the ROW_IDs of each of the entities. Thus, the data from each entity is
stored in its own table, and duplication is avoided as shown in Figure 7. In this example,
S_OPTY_CON is the intersection table.



S_CONTACT S_OPTY_CON S_OPTY
ROW_ID LAST_NAME FIRST_NAME MID_NAME PER_ID OPTY_ID ROW_ID NAME LEAD_QUALITY_CD

1-3K Johnson Pat K 1-3K 1+SD6 1+SD6 Accounting system Very High
1-3L Grothe Steven J 1-3K 1+SD7 1+SD7 AMCO POS servers Fair

1-3M Shimizu Kanae A 1-3L 1+SD7 1+SD8 NAPA A/R project Excellent
1-3N Pent John D 1-3M 1+SD7 1+SD9 PC Deal High

1-3O Bjorkegren Cecilia U 1-3M 1+SD8
1-3M 1+SD9

1-3N 1+SD9
1-3O 1+SD9

Figure 7: Normalizing a M:M Relationship

With the tables constructed in this fashion, there is no duplication. This is the best way to represent a M:M relationship.

Mapping Data in Siebel Enterprise Applications
An understanding of normalization can be of assistance when developers are mapping data in Siebel. Data mapping refers to the
process that is done during design of deciding what information is going to be stored in which table and in which column. During
this process it is important to store data in a normalized fashion. Let us take the example of a client that wants to store information
about the role that a Contact is playing on an Opportunity. Developers must choose where to store this information. If a Contact is
always going to have the same role regardless of the Opportunity, then it makes sense to store this information in the Contact table
(S_CONTACT). However, a Contact may have a different role depending on the Opportunity. For example, they may serve as
“Decision Maker” on one Opportunity and as “Influencer” on another Opportunity. If this is the case, it does not make sense to store
this information on S_CONTACT because the role could be different on each of the many Opportunities of which the Contact is a
part. It does not make sense to store this information on the Opportunity table (S_OPTY) because an Opportunity can have many

07/29/10

Contacts. If a Contact can have a different role on various Opportunities, it makes sense to store this on the intersection table
(S_OPTY_CON) as shown in Figure 8.
S_CONTACT S_OPTY_CON S_OPTY
ROW_ID LAST_NAME FIRST_NAME MID_NAME PER_ID ROLE_CD OPTY_ID ROW_ID NAME LEAD_QUALITY_CD

1-3K Johnson Pat K 1-3K Decision Maker 1+SD6 1+SD6 Accounting system Very High

1-3L Grothe Steven J 1-3K Approver 1+SD7 1+SD7 AMCO POS servers Fair

1-3M Shimizu Kanae A 1-3L Decision Maker 1+SD7 1+SD8 NAPA A/R project Excellent

1-3N Pent John D 1-3M Evaluator 1+SD7 1+SD9 PC Deal High

1-3O Bjorkegren Cecilia U 1-3M Influencer 1+SD8

1-3M Decision Maker 1+SD9

1-3N Decision Maker 1+SD9

1-3O Approver 1+SD9

Figure 8: Normalizing Data in a M:M Relationship

Again, the important factor in making this decision is to understand the data that are being represented. If a Contact is always going
to have the same role regardless of the Opportunity, it is best to store this information in S_CONTACT. If it were stored in
S_OPTY_CON, it would be duplicated several times. However, if a Contact can have a different role on different Opportunities, then
these data should be stored in the intersection table S_OPTY_CON.

07/29/10


JOINS

Purpose of a Join
A join is used to represent either a 1:1 relationship or a M:1 relationship. A join hooks one
record in one table to one record in another table. This is accomplished by matching the foreign
key in the “source” table to the ROW_ID of the “target” table.

Inner Joins
An inner join retrieves all records where the foreign key in the source table has a matching
ROW_ID in the target table. Figures 9a and 9b illustrate an inner join. This is a bit of a
confusing example, but will be explained following Figure 9b. Figure 9a represents the data
that exist in the database. Figure 9b illustrates how this information is retrieved into the
Business Component and displayed in Siebel.
S_OPTY S_OPTY_PROD S_PROD_INT
ROW_ID NAME OPTY_ID PROD_ID ROW_ID NAME
1-7XJ AMCO POS servers 1-7XJ 1-A8 1-A8 486-100 Desktop
1-5HII Accounting system 1-5HII 1-A8 1-DX MS Back Office
1-5HII 1-DX 1-AM MS Office
1-5HII 1-AM 1-4Y6 486-100 Laptop
1-5HII 1-4Y6 1-4Y0 486-66 Laptop
1-5HII 1-4Y0

Figure 9a: M:M Relationship Between Opportunities and Products in the Database

07/29/10 SIERRA PROPRIETARY AND CONFIDENTIAL – DO NOT DISTRIBUTE Page 13 of 31


9b: Inner Joins Displayed in Siebel

At first glance, this may appear to be a confusing example. This is because it was just stated
that joins represent 1:1 or M:1 relationships, but the relationship between Opportunities and
Products is M:M. The Product Applet shown above is actually based off of the S_OPTY_PROD
table. This is not standard in Siebel, but this Applet is the most common example of an inner
join. Usually, the child Applet in a M:M relationship is based off of the child table, not off of the
intersection table.
The Product column in this Applet is displayed by joining from the S_OPTY_PROD record to
the Product in S_PROD_INT. From the perspective of a record in S_OPTY_PROD, this is in fact
a join. Each record in S_OPTY_PROD has one and only one corresponding record in
S_PROD_INT.

Outer Joins
An outer join retrieves all records in the source table, and those records in the target table where
the foreign key in the source table has a matching ROW_ID in the target table. This difference
from an inner join is critical, and will be illustrated shortly. Figures 10a and 10b illustrate an


outer join. Figure 10a represents the data that exist in the database. Figure 10b illustrates how
this information is retrieved into the Business Component and displayed in Siebel.
S_CONTACT S_ORG_EXT
ROW_ID LAST_NAME FST_NAME PR_DEPT_OU_ID ROW_ID NAME
1-3BX Atkins Charlie 1-2PO 1-2PO Acme Inc.
1-33H Franklin Bill 1-W 1-W A. K. Parker Distribution
1-BZZ Lindberg Don 1-A Parker Manufacturing
1-6M Ling Henry 1-A 1-2LF AMCO Pipe & Line, Co.
1-43G Martin Jonathon 1-2PO
1-5EIJ Martin Ken
1-BZR Weinberg Stephen 1-2LF

Figure 10a: M:1 Relationship Between Contacts and Accounts in the Database

10b: Outer Joins Displayed in Siebel

Siebel retrieves all records in the source table, in this case S_CONTACT. For those records in
S_CONTACT that have a matching record in S_ORG_EXT, Siebel joins to the target record and
displays the name of the Account.
To illustrate the important difference between an inner join and an outer join, let us revisit the
definition of each. An inner join retrieves all records where the foreign key in the source table
has a matching ROW_ID in the target table. An outer join retrieves all records in the source
table, and those records in the target table where the foreign key in the source table has a
matching ROW_ID in the target table. If the join between S_CONTACT and S_ORG_EXT were
an inner join, then Siebel would not retrieve those records in S_CONTACT where there was no
matching ROW_ID in S_ORG_EXT. The result if this was an inner join is displayed in Figure
10c.

Figure 10c: Results of an Inner Join From Contacts to Accounts

As can be seen in Figure 10c, this should absolutely not be an inner join. It is not required that a
Contact belong to an Account. If this were an inner join, Siebel would not display any Contacts
that do not belong to an Account. This would obviously be a problem. If a user entered a
Contact and did not pick an Account for that Contact, the Contact would disappear. It would
never be displayed in this Business Component because of the inner join.

Databases can perform inner joins faster than outer joins. If a record in the source table will
always have a corresponding record in the target table, then an inner join should be used.
However, if there ever can be a case where a record in the source table would not have a
corresponding record in the target table then an outer join should be used. If not, records
would seem to disappear from the Business Component.

Defining a Join in Siebel Tools
Just because a table has a foreign key to another table does not mean that a join automatically
exists. Joins must be explicitly defined in Siebel. As a note, there are two exceptions. The first
is that a join is implicitly defined when an extension table is created. Joins should never be
explicitly defined in Siebel Tools to join a table with its extension table. The second is a bit more
complex. Due to the rarity with which this case exists in Siebel, it will not be discussed here in
detail. The brief explanation is that when data from a table is displayed in Siebel as the child in
a M:M relationship, a join is implicitly defined from the child table to the intersection table.
There are two components to a Join in Siebel Tools. The first is the Join itself. This identifies the
target table and whether the Join is an outer join or an inner join. The second component is the
Join Specification. This identifies the Source Field in the Business Component that serves as the
foreign key to the target table, and the Destination Column in the target table where Siebel
should look for a matching value. The Destination Column is almost always the ROW_ID.
Figure 11a illustrates the inner join used to join S_OPTY_PROD to S_PROD_INT. This Join is
defined in the Opportunity Product Business Component.



Figure 11a: Inner Join from the Opportunity Product Business Component to the Product Table

Let us examine this Join. The Join indicates that S_PROD_INT is the target table. The Outer
Join Flag is not checked, indicating this is an inner join. The Source Field in the Join
Specification indicates that the Product Id field in the Opportunity Product Business
Component contains the foreign key to the S_PROD_INT table. The Destination Column
indicates that Siebel should look in the ROW_ID column in the S_PROD_INT table for a value
that matches the Product Id field in the Opportunity Product Business Component.
Figure 11b illustrates the outer join used to join S_CONTACT to S_ORG_EXT. This Join is
defined in the Contact Business Component.



Figure 11b: Outer Join from the Contact Business Component to the Account Table

Let us examine this Join. The Join indicates that S_ORG_EXT is the target table. The Outer Join
Flag is checked, indicating this is an outer join. The Source Field in the Join Specification
indicates that the Account Id field in the Contact Business Component contains the foreign key
to the S_ORG_EXT table. The Destination Column indicates that Siebel should look in the
ROW_ID column in the S_ORG_EXT table for a value that matches the Account Id field in the
Contact Business Component.

Using a Join in Siebel Tools
Joins are used in Siebel Tools to define a field in a Business Component that is not in the table
off of which the Business Component is based. Figure 12 illustrates the use of the join to the
S_ORG_EXT table from the Contact Business Component.



Figure 12: Using a Join in Siebel Tools

As can be seen, the Account field uses the S_ORG_EXT join to get to the NAME column in the
S_ORG_EXT table. At runtime, here is what happens. To display the Account field in an
Applet, Siebel must perform the S_ORG_EXT join to get to the S_ORG_EXT table. So, based on
the Join Specification, Siebel gets the value from the Account Id field (the PR_DEPT_OU_ID
column in the S_CONTACT table) and looks for a match in the S_ORG_EXT table. If there is a
matching record, Siebel gets the value in the NAME column and displays it in the Account field.



LINKS

Purpose of a Link
A link is used to represent either a 1:M relationship or a M:M relationship. A link retrieves all
of the child records in the target table that belong to the parent record in the source table. This
is accomplished differently depending on whether the relationship is 1:M or M:M.

1:M Links
In a 1:M relationship, the child records contain foreign keys to the parent record. Refer to
Figure 10a. From the Contact point of view, this is a M:1 relationship. So, when displaying
Contacts, a join would be used to display the name of the one Account. From the Account point
of view, this is a 1:M relationship. So, when displaying Accounts, a link would be used to
display all of the child Contacts. Figure 13 shows the results of a 1:M link from Accounts to

Contacts in Siebel. The results shown assume the same data in the database as in Figure 10a.
Figure 13: Results of a 1:M Link from Accounts to Contacts

M:M Links
M:M relationships are represented in a semi-complex fashion in the database Refer to the M:M
relationship between Contacts and Opportunities in Figure 7. A M:M link needs seven things to
work: a) the parent table, b) the intersection table, c) the child table, d) the “inter parent”
column in the intersection table that contains the foreign key to the parent table, e) the source
column in the parent table to which the “inter parent” column points, f) the “inter child”
column in the intersection table that contains the foreign key to the child table, and g) the
destination column in the child table to which the “inter child” column points. Figure 14 shows
the results of a M:M link from Contacts to Opportunities in Siebel. The results shown assume
the same data in the database as in Figure 7.

Figure 14: Results of a M:M Link from Contacts to Opportunities

Defining a Link in Siebel Tools
Figure 15a shows the definition of the 1:M Account/Contact Link in Siebel Tools.



Figure 15a: 1:M Link from Accounts to Contacts

Let us examine this Link. The Account Business Component is the Parent Business Component
in this Link. The Contact Business Component is the Child Business Component in this Link.
The Destination Field is the field in the Child Business Component that contains the foreign key
to the Account Business Component. In this Link, the Destination Field is Account Id. The
Source Field is the field in the Parent Business Component to which the Destination Field
points. If this field is not specified, Siebel assumes that it is the Id field (this field is implicitly
defined in every Business Component as the ROW_ID). Since the Source Field is not defined in
this Link, Siebel will use the Id field.
Figure 15b illustrates the M:M Link from Contacts to Opportunities.



Figure 15b: M:M Link from Contacts to Opportunities

Let us examine this Link. The Contact Business Component is the Parent Business Component.
The Opportunity Business Component is the Child Business Component. S_OPTY_CON is the
intersection table in this M:M relationship. The Inter Parent Column is the column in the
intersection table that contains the foreign key to the Source Field in the Parent Business
Component. If the Source Field is not explicitly defined, Siebel uses the Id field (the ROW_ID).
In this Link we can see that the PER_ID column in S_OPTY_CON points to the Id field in the
Contact Business Component. The Inter Child Column is the column in the intersection table
that contains the foreign key to the Destination Field in the Child Business Component. If the
Destination Field is not explicitly defined, Siebel uses the Id Field. In this Link we can see that
the OPTY_ID column in S_OPTY_CON points to the Id field in the Opportunity Business
Component.

Using a Link in Siebel Tools
Links are used in two places in Siebel Tools. They are used in Business Object Components and
in Multi Value Links to tell Siebel how to get child records for a parent record. Without these
Links, Siebel will not know how to get child records in a View or in an MVG for a parent record.



INDICES

Purpose of an Index
An index is like a table of contents for a database table. It is separate from the database table. It
contains an organized list of all of the values in one or more columns in a database table. An
index serves two purposes for a table. First, by providing an organized list of all of the values
in a column, it can speed up the retrieval of data. Second, it can enforce uniqueness of data. We
will examine both of these in this section.

Performance Gains from Indices
Consider the Link from Accounts to Contacts shown in Figures 10a and 13. For Siebel to
display the Contacts for an Account, it must find all records in S_CONTACT where
PR_DEPT_OU_ID is equal to the ROW_ID of the Account in question. If there is no index on
the PR_DEPT_OU_ID column, Siebel will have to do what is called a table scan to find all of
these values. A table scan means that Siebel scans the entire table looking for matching values
in PR_DEPT_OU_ID.
The S_CONTACT table has an index named S_CONTACT_U2. The first column in this index,
based on the sequence of columns in the index, is the PR_DEPT_OU_ID column. In this
example, we will ignore the fact that there are several other columns in the index. Since
PR_DEPT_OU_ID is the first column, the database can get performance gains just by looking at
this one column. In this example, we will treat this index as if it were only on the
PR_DEPT_OU_ID column.
This index contains a table of contents of all of the values in PR_DEPT_OU_ID, and the rows in
the database in which these values are found. So, the database does not need to do a table scan
to find values in PR_DEPT_OU_ID. It can simply look in the index. A table and a
corresponding index are shown in Figure 16. This is not completely accurate from a technical
standpoint, but will suffice for the purposes of education.



S_CONTACT_U2 Index of S_CONTACT
PR_DEPT_OU_ID
PR_DEPT_OU_ID ROW_ID ROW_ID PR_DEPT_OU_ID
1-77G 1-H45 1-H44 1-8D
1-77G 1-H47 1-H45 1-77G
1-77G 1-H50 1-H46 1-8D
1-8D 1-H44 1-H47 1-77G
1-8D 1-H46 1-H48 1-JS9
1-8D 1-H49 1-H49 1-8D
1-JS9 1-H48 1-H50 1-77G
Figure 16: An Index and the Table of Which it is a Part

We will complete two exercises to illustrate the performance gains derived from an index.
These exercises are not completely accurate from a technical standpoint, but will illustrate the
benefits of an index. To complete the exercises you will need a pen or pencil and a watch with a
second hand. In both of these exercises you will pretend to be the database looking for all
Contacts belonging to a particular Account. To display these Contacts in Siebel, you will need
to get a list of all of the ROW_IDs for the Contacts that belong to the Account. Exercise 1
contains data that is not indexed. Exercise 2 contains indexed data. To complete the exercise,
time how long it takes you to complete the list of Contact’s ROW_IDs. Each exercise has ten
Contacts that you will need to find. Complete each exercise and record the amount of time it
takes you to complete it.


Exercise 1: Retrieving Non-Indexed Data

S_CONTACT In this table, write the ROW_IDs of the ten
Contacts where PR_DEPT_OU_ID = 1-TGH
ROW_ID PR_DEPT_OU_ID
1-4A 1-3SD
1-4B 1-GH7
1-4C 1-Q5A
1-4D 1-3SD
1-4E 1-TGH
1-4F 1-15H
1-4G 1-SWS
1-4H 1-734
1-4I 1-JHJ
1-4J 1-TGH
1-4K 1-GH7
1-4L 1-3SD
1-4M 1-3VH
1-4N 1-TGH
1-4O 1-Q5A
1-4P 1-SWS
1-4Q 1-3SD
1-4R 1-15H
1-4S 1-GH7
1-4T 1-734
1-4U 1-JHJ
1-4V 1-TGH
1-4W 1-3VH
1-4X 1-3SD
1-4Y 1-TGH
1-4Z 1-15H
1-50 1-Q5A
1-51 1-3SD
1-52 1-SWS
1-53 1-GH7
1-54 1-TGH
1-55 1-734
1-56 1-3VH
1-57 1-3SD
1-58 1-TGH
1-59 1-JHJ
1-5A 1-734
1-5B 1-3SD
1-5C 1-15H
1-5D 1-GH7
1-5E 1-TGH
1-5F 1-3SD
1-5G 1-Q5A
1-5H 1-SWS
1-5I 1-734
1-5J 1-TGH
1-5K 1-JHJ
1-5L 1-TGH
1-5M 1-Q5A
1-5N 1-GH7
1-5O 1-JHJ


The correct answers are in the following table. The order of the answers is not important.
1-4E
1-4J

1-4N
1-4V
1-4Y
1-54
1-58
1-5E
1-5J
1-5L

Enter the time in seconds that it took to complete this exercise:____________________
Now turn the page and proceed to Exercise 2.


Exercise 2: Retrieving Indexed Data

INDEX S_CONTACT In this table, write
the ROW_IDs of the
ten Contacts where
PR_DEPT_OU_ID =
1-8WL
PR_DEPT_OU_ID ROW_ID ROW_ID PR_DEPT_OU_ID
1-2J9 1-5U 1-5P 1-7FG
1-2J9 1-62 1-5Q 1-KS7
1-2J9 1-69 1-5R 1-8WL
1-2J9 1-6I 1-5S 1-ES1
1-2J9 1-6R 1-5T 1-8WL
1-2J9 1-6V 1-5U 1-2J9
1-7FG 1-5P 1-5V 1-KS7
1-7FG 1-5Y 1-5W 1-GFW
1-7FG 1-68 1-5X 1-8WL
1-7FG 1-6F 1-5Y 1-7FG
1-7FG 1-6L 1-5Z 1-WE9
1-7FG 1-6U 1-60 1-ES1
1-8WL 1-5R 1-61 1-8WL
1-8WL 1-5T 1-62 1-2J9
1-8WL 1-5X 1-63 1-GFW
1-8WL 1-61 1-64 1-ES1
1-8WL 1-65 1-65 1-8WL
1-8WL 1-6C 1-66 1-KS7
1-8WL 1-6J 1-67 1-WE9
1-8WL 1-6N 1-68 1-7FG
1-8WL 1-6Q 1-69 1-2J9
1-8WL 1-6W 1-6A 1-ES1
1-ES1 1-5S 1-6B 1-GFW
1-ES1 1-60 1-6C 1-8WL
1-ES1 1-64 1-6D 1-ES1
1-ES1 1-6A 1-6E 1-KS7
1-ES1 1-6D 1-6F 1-7FG
1-ES1 1-6K 1-6G 1-WE9
1-ES1 1-6T 1-6H 1-GFW
1-ES1 1-6Z 1-6I 1-2J9
1-GFW 1-5W 1-6J 1-8WL
1-GFW 1-63 1-6K 1-ES1
1-GFW 1-6B 1-6L 1-7FG
1-GFW 1-6H 1-6M 1-KS7
1-GFW 1-6O 1-6N 1-8WL
1-GFW 1-6Y 1-6O 1-GFW
1-KS7 1-5Q 1-6P 1-WE9
1-KS7 1-5V 1-6Q 1-8WL
1-KS7 1-66 1-6R 1-2J9
1-KS7 1-6E 1-6S 1-KS7
1-KS7 1-6M 1-6T 1-ES1
1-KS7 1-6S 1-6U 1-7FG
1-WE9 1-5Z 1-6V 1-2J9
1-WE9 1-67 1-6W 1-8WL
1-WE9 1-6G 1-6X 1-WE9
1-WE9 1-6P 1-6Y 1-GFW
1-WE9 1-6X 1-6Z 1-ES1


The correct answers are in the following table. The order of the answers is not important.
1-5R
1-5T

1-5X
1-61
1-65
1-6C
1-6J
1-6N
1-6Q
1-6W

Enter the time in seconds that it took to complete this exercise:____________________
Compare the time it took you to retrieve the data without an index to the time it took you to
retrieve the data with an index. As you can see, data retrieval is faster with an index.

Enforcement of Data Uniqueness with Indices
If an index is a “unique” index, then it will enforce that no two records have the same values in
the columns that are part of the index. A unique index from the S_CONTACT table is shown in
Figure 17.



Figure 17: A Unique Index on the Contact Table

The columns in this unique index are LAST_NAME, FST_NAME, MID_NAME,
PR_DEPT_OU_ID, and CONFLICT_ID. This means that there can never be two Contacts that
have the same last name, first name, middle name, and Account.
The CONFLICT_ID column is a part of every index that represents a user key. Let us take the
example of two mobile Siebel users who each enter a new Contact named Pat K. Johnson at
ACME Corporation. When the first user synchronizes, the Contact would be added to the main
database. If the second user synchronized, there would be a conflict because this unique key
would be violated. So, if this happens Siebel will change the value in the CONFLICT_ID
column. This column is a system field used by Siebel Remote and should never be exposed in
the User Interface.
It is most accurate to say that there can never be two Contacts that have the same last name, first
name, middle name, Account, and CONFLICT_ID. However, the CONFLICT_ID can only be
modified by Siebel Remote. So, for all realistic purposes it is accurate to say that there can never
be two Contacts that have the same last name, first name, middle name, and Account.


Dinesh Chandrasekar Database Theory For Siebel Enterprise Applications

More Related Content

Similar to Dinesh Chandrasekar Database Theory For Siebel Enterprise Applications

More from Dr.Dinesh Chandrasekar PhD(hc)

Dinesh Chandrasekar Database Theory For Siebel Enterprise Applications