Dinesh Chandrasekar 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

DATABASE THEORY FOR

SIEBEL ENTERPRISE

APPLICATIONS




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.

S_CONTACT

ROW_ID LAST_NAME FST_NAME MID_NAME

1-3K Johnson Pat K

1-3L Grothe Steven J

1-3M Shimizu Kanae A

Figure 1: Features of a Database Table

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

Table Name

Column Name

Column

Row




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.


07/29/10

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 SIERRA PROPRIETARY AND CONFIDENTIAL – DO NOT DISTRIBUTE Page 13 of 31

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



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 PR_DEPT_OU_ID

S_CONTACT

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.

Documents

Dinesh Chandrasekar Database Theory For Siebel Enterprise Applications