D T S E A: Atabase Heory For Iebel Nterprise Pplications

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 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
NORMALIZATION......................................................................................................7
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
07/29/10
Page 2 of 31
OVERVIEW
This document is intended to develop a readers 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 Siebels 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.
07/29/10
Page 3 of 31
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 Siebels Contact table, S_CONTACT, to illustrate these features.
Table Name
S_CONTACT ROW_ID LAST_NAME FST_NAME 1-3K Johnson Grothe Shimizu Pat Steven Kanae 1-3L 1-3M MID_NAME K J A
Column Name
Row
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
07/29/10
Page 4 of 31

the number of times that the record has been modified. The ROW_ID will be explained in the next section.
07/29/10
Page 5 of 31
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 contacts 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, lets 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
ROW_ID LAST_NAME FIRST_NAME MID_NAME PR_DEPT_OU_ID 1-3K 1-3L 1-3M Johnson Grothe Shimizu Pat Steven Kanae K J A 1-1VDB 1-1VDB 1-1VDC 1-1VDB 1-1VDC
S_ORG_EXT
ROW_ID NAME Acme LOC HQ
ABC Corp. East
Figure 2: Foreign Keys
07/29/10
Page 6 of 31
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 Johnson Grothe Shimizu Pent Bjorkegren FIRST_NAME Pat Steven Kanae John Cecilia MID_NAME K J A D U ACCNT_NAME Acme Acme ABC Corp ABC Corp ABC Corp ACCNT_LOC HQ HQ East East 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.
07/29/10
Page 7 of 31

S_CONTACT
ROW_ID LAST_NAME FIRST_NAME 1-3K 1-3L 1-3M 1-3N 1-3O Johnson Grothe Shimizu Pent Bjorkegren Pat Steven Kanae John Cecilia MID_NAME PR_DEPT_OU_ID K J A D U 1-1VDB 1-1VDB 1-1VDC 1-1VDC 1-1VDC
S_ORG_EXT
ROW_ID NAME 1-1VDB 1-1VDC Acme LOC HQ
ABC Corp. East
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 Johnson Grothe Shimizu Shimizu Shimizu Pent Bjorkegren
Pat Pat Steven Kanae Kanae Kanae John Cecilia
K K J A A A D U
Accounting system AMCO POS servers AMCO POS servers AMCO POS servers NAPA A/R project PC Deal PC Deal PC Deal
Very High Fair Fair Fair Excellent High High 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.
07/29/10
Page 8 of 31

S_CONTACT
LAST_NAME FIRST_NAME MID_NAME OPTY_ID Johnson Johnson Grothe Shimizu Shimizu Shimizu Pent Bjorkegren Pat Pat Steven Kanae Kanae Kanae John Cecilia K K J A A A D U 1+SD6 1+SD7 1+SD7 1+SD7 1+SD8 1+SD9 1+SD9 1+SD9 1+SD6 1+SD7 1+SD8 1+SD9
S_OPTY
ROW_ID NAME Accounting system AMCO POS servers NAPA A/R project PC Deal LOC Very High Fair Excellent High
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
Page 9 of 31

S_CONTACT
ROW_ID 1-3K 1-3L 1-3M 1-3N 1-3O LAST_NAME Johnson Grothe Shimizu Pent Bjorkegren FIRST_NAME Pat Steven Kanae John Cecilia MID_NAME K J A D U
S_OPTY_CON
PER_ID 1-3K 1-3K 1-3L 1-3M 1-3M 1-3M 1-3N 1-3O OPTY_ID 1+SD6 1+SD7 1+SD7 1+SD7 1+SD8 1+SD9 1+SD9 1+SD9 ROW_ID 1+SD6 1+SD7 1+SD8 1+SD9
S_OPTY
NAME Accounting system AMCO POS servers NAPA A/R project PC Deal LEAD_QUALITY_CD Very High Fair Excellent High
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
ROW_ID 1-3K 1-3L 1-3M 1-3N 1-3O LAST_NAME Johnson Grothe Shimizu Pent Bjorkegren FIRST_NAME Pat Steven Kanae John Cecilia MID_NAME K J A D U PER_ID 1-3K 1-3K 1-3L 1-3M 1-3M 1-3M 1-3N 1-3O
S_OPTY_CON
ROLE_CD Decision Maker Approver Decision Maker Evaluator Influencer Decision Maker Decision Maker Approver OPTY_ID 1+SD6 1+SD7 1+SD7 1+SD7 1+SD8 1+SD9 1+SD9 1+SD9 ROW_ID 1+SD6 1+SD7 1+SD8 1+SD9
S_OPTY
NAME Accounting system AMCO POS servers NAPA A/R project PC Deal LEAD_QUALITY_CD Very High Fair Excellent High
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
ROW_ID 1-7XJ 1-5HII NAME AMCO POS servers Accounting system
S_OPTY_PROD
OPTY_ID 1-7XJ 1-5HII 1-5HII 1-5HII 1-5HII 1-5HII PROD_ID 1-A8 1-A8 1-DX 1-AM 1-4Y6 1-4Y0
S_PROD_INT
ROW_ID 1-A8 1-DX 1-AM 1-4Y6 1-4Y0 NAME 486-100 Desktop MS Back Office MS Office 486-100 Laptop 486-66 Laptop
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
07/29/10
Page 14 of 31

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
ROW_ID 1-3BX 1-33H 1-BZZ 1-6M 1-43G 1-5EIJ 1-BZR LAST_NAME Atkins Franklin Lindberg Ling Martin Martin Weinberg FST_NAME Charlie Bill Don Henry Jonathon Ken Stephen 1-2LF 1-A 1-2PO PR_DEPT_OU_ID 1-2PO 1-W ROW_ID 1-2PO 1-W 1-A 1-2LF
S_ORG_EXT
NAME Acme Inc. A. K. Parker Distribution Parker Manufacturing AMCO Pipe & Line, Co.
Figure 10a: M:1 Relationship Between Contacts and Accounts in the Database 10b: Outer Joins Displayed in Siebel
07/29/10
Page 15 of 31

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.
07/29/10
Page 16 of 31

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.
07/29/10
Page 17 of 31
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.
07/29/10
Page 18 of 31
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.
07/29/10
Page 19 of 31
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.
07/29/10
Page 20 of 31
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
07/29/10
Page 21 of 31
Database Theory for Siebel Enterprise Applications 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.
07/29/10
Page 22 of 31
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.
07/29/10
Page 23 of 31
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.
07/29/10
Page 24 of 31
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.
07/29/10
Page 25 of 31

S_CONTACT_U2 Index of PR_DEPT_OU_ID PR_DEPT_OU_ID 1-77G 1-77G 1-77G 1-8D 1-8D 1-8D 1-JS9 ROW_ID 1-H45 1-H47 1-H50 1-H44 1-H46 1-H49 1-H48 ROW_ID 1-H44 1-H45 1-H46 1-H47 1-H48 1-H49 1-H50 S_CONTACT PR_DEPT_OU_ID 1-8D 1-77G 1-8D 1-77G 1-JS9 1-8D 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 Contacts 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.
07/29/10
Page 26 of 31

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

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.
07/29/10
Page 28 of 31

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
1-2J9 1-2J9 1-2J9 1-2J9 1-2J9 1-2J9 1-7FG 1-7FG 1-7FG 1-7FG 1-7FG 1-7FG 1-8WL 1-8WL 1-8WL 1-8WL 1-8WL 1-8WL 1-8WL 1-8WL 1-8WL 1-8WL 1-ES1 1-ES1 1-ES1 1-ES1 1-ES1 1-ES1 1-ES1 1-ES1 1-GFW 1-GFW 1-GFW 1-GFW 1-GFW 1-GFW 1-KS7 1-KS7 1-KS7 1-KS7 1-KS7 1-KS7 1-WE9 1-WE9 1-WE9 1-WE9 1-WE9 07/29/10
ROW_ID
1-5U 1-62 1-69 1-6I 1-6R 1-6V 1-5P 1-5Y 1-68 1-6F 1-6L 1-6U 1-5R 1-5T 1-5X 1-61 1-65 1-6C 1-6J 1-6N 1-6Q 1-6W 1-5S 1-60 1-64 1-6A 1-6D 1-6K 1-6T 1-6Z 1-5W 1-63 1-6B 1-6H 1-6O 1-6Y 1-5Q 1-5V 1-66 1-6E 1-6M 1-6S 1-5Z 1-67 1-6G 1-6P 1-6X
ROW_ID
1-5P 1-5Q 1-5R 1-5S 1-5T 1-5U 1-5V 1-5W 1-5X 1-5Y 1-5Z 1-60 1-61 1-62 1-63 1-64 1-65 1-66 1-67 1-68 1-69 1-6A 1-6B 1-6C 1-6D 1-6E 1-6F 1-6G 1-6H 1-6I 1-6J 1-6K 1-6L 1-6M 1-6N 1-6O 1-6P 1-6Q 1-6R 1-6S 1-6T 1-6U 1-6V 1-6W 1-6X 1-6Y 1-6Z
PR_DEPT_OU_ID
1-7FG 1-KS7 1-8WL 1-ES1 1-8WL 1-2J9 1-KS7 1-GFW 1-8WL 1-7FG 1-WE9 1-ES1 1-8WL 1-2J9 1-GFW 1-ES1 1-8WL 1-KS7 1-WE9 1-7FG 1-2J9 1-ES1 1-GFW 1-8WL 1-ES1 1-KS7 1-7FG 1-WE9 1-GFW 1-2J9 1-8WL 1-ES1 1-7FG 1-KS7 1-8WL 1-GFW 1-WE9 1-8WL 1-2J9 1-KS7 1-ES1 1-7FG 1-2J9 1-8WL 1-WE9 1-GFW 1-ES1 Page 29 of 31

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.
07/29/10
Page 30 of 31
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.
07/29/10
Page 31 of 31

D T S E A: Atabase Heory For Iebel Nterprise Pplications

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

D T S E A: Atabase Heory For Iebel Nterprise Pplications

Uploaded by

Copyright:

Available Formats

Database Theory for Siebel Enterprise Applications

DATABASE THEORY FOR SIEBEL ENTERPRISE APPLICATIONS

Database Theory for Siebel Enterprise Applications

OVERVIEW .................................................................................................................3 DATABASE TABLES ...................................................................................................4

Database Theory for Siebel Enterprise Applications

Database Theory for Siebel Enterprise Applications

Figure 1: Features of a Database Table

Database Theory for Siebel Enterprise Applications

Database Theory for Siebel Enterprise Applications

ABC Corp. East

Figure 2: Foreign Keys

Database Theory for Siebel Enterprise Applications

Normalizing a 1:M or a M:1 Relationship

Database Theory for Siebel Enterprise Applications

ABC Corp. East

Normalizing a M:M Relationship

Johnson Johnson Grothe Shimizu Shimizu Shimizu Pent Bjorkegren

Pat Pat Steven Kanae Kanae Kanae John Cecilia

Very High Fair Fair Fair Excellent High High High

Database Theory for Siebel Enterprise Applications

Database Theory for Siebel Enterprise Applications

Figure 7: Normalizing a M:M Relationship

Mapping Data in Siebel Enterprise Applications

Database Theory for Siebel Enterprise Applications

Figure 8: Normalizing Data in a M:M Relationship

Database Theory for Siebel Enterprise Applications

SIERRA PROPRIETARY AND CONFIDENTIAL DO NOT DISTRIBUTE

Database Theory for Siebel Enterprise Applications

SIERRA PROPRIETARY AND CONFIDENTIAL DO NOT DISTRIBUTE

Database Theory for Siebel Enterprise Applications

SIERRA PROPRIETARY AND CONFIDENTIAL DO NOT DISTRIBUTE

Database Theory for Siebel Enterprise Applications

SIERRA PROPRIETARY AND CONFIDENTIAL DO NOT DISTRIBUTE

Database Theory for Siebel Enterprise Applications

Defining a Join in Siebel Tools

SIERRA PROPRIETARY AND CONFIDENTIAL DO NOT DISTRIBUTE

Database Theory for Siebel Enterprise Applications

SIERRA PROPRIETARY AND CONFIDENTIAL DO NOT DISTRIBUTE

Database Theory for Siebel Enterprise Applications

Using a Join in Siebel Tools

SIERRA PROPRIETARY AND CONFIDENTIAL DO NOT DISTRIBUTE

Database Theory for Siebel Enterprise Applications

SIERRA PROPRIETARY AND CONFIDENTIAL DO NOT DISTRIBUTE

Database Theory for Siebel Enterprise Applications

SIERRA PROPRIETARY AND CONFIDENTIAL DO NOT DISTRIBUTE

Database Theory for Siebel Enterprise Applications M:M Links

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

Defining a Link in Siebel Tools

SIERRA PROPRIETARY AND CONFIDENTIAL DO NOT DISTRIBUTE

Database Theory for Siebel Enterprise Applications

SIERRA PROPRIETARY AND CONFIDENTIAL DO NOT DISTRIBUTE

Database Theory for Siebel Enterprise Applications

Using a Link in Siebel Tools

SIERRA PROPRIETARY AND CONFIDENTIAL DO NOT DISTRIBUTE

Database Theory for Siebel Enterprise Applications

Performance Gains from Indices

SIERRA PROPRIETARY AND CONFIDENTIAL DO NOT DISTRIBUTE

Database Theory for Siebel Enterprise Applications

SIERRA PROPRIETARY AND CONFIDENTIAL DO NOT DISTRIBUTE

Database Theory for Siebel Enterprise Applications

SIERRA PROPRIETARY AND CONFIDENTIAL DO NOT DISTRIBUTE

Database Theory for Siebel Enterprise Applications