• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Dinesh Chandrasekar  Database Theory For Siebel Enterprise Applications
 

Dinesh Chandrasekar Database Theory For Siebel Enterprise Applications

on

  • 1,321 views

Database Theory for Siebel Enterprise Applications - Dinesh Chandrasekar

Database Theory for Siebel Enterprise Applications - Dinesh Chandrasekar

Statistics

Views

Total Views
1,321
Views on SlideShare
1,314
Embed Views
7

Actions

Likes
1
Downloads
65
Comments
0

2 Embeds 7

http://www.lmodules.com 5
http://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Dinesh Chandrasekar  Database Theory For Siebel Enterprise Applications Dinesh Chandrasekar Database Theory For Siebel Enterprise Applications Document Transcript

    • 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 07/29/10 Dinesh Chandrasekar - Practice Head CRM & MDM CoE Sierra Atlantic White Paper Page 2 of 31
    • Database Theory for Siebel Enterprise Applications 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. 07/29/10 Dinesh Chandrasekar - Practice Head CRM & MDM CoE Sierra Atlantic White Paper Page 3 of 31
    • Database Theory for Siebel Enterprise Applications 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 07/29/10 Dinesh Chandrasekar - Practice Head CRM & MDM CoE Sierra Atlantic White Paper Page 4 of 31
    • Database Theory for Siebel Enterprise Applications the number of times that the record has been modified. The ROW_ID will be explained in the next section. 07/29/10 Dinesh Chandrasekar - Practice Head CRM & MDM CoE Sierra Atlantic White Paper Page 5 of 31
    • Database Theory for Siebel Enterprise Applications 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 07/29/10 Dinesh Chandrasekar - Practice Head CRM & MDM CoE Sierra Atlantic White Paper Page 6 of 31
    • Database Theory for Siebel Enterprise Applications 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. 07/29/10 Dinesh Chandrasekar - Practice Head CRM & MDM CoE Sierra Atlantic White Paper Page 7 of 31
    • Database Theory for Siebel Enterprise Applications 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. 07/29/10 Dinesh Chandrasekar - Practice Head CRM & MDM CoE Sierra Atlantic White Paper Page 8 of 31
    • Database Theory for Siebel Enterprise Applications 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 Dinesh Chandrasekar - Practice Head CRM & MDM CoE Sierra Atlantic White Paper Page 9 of 31
    • Database Theory for Siebel Enterprise Applications 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
    • Database Theory for Siebel Enterprise Applications 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
    • Database Theory for Siebel Enterprise Applications 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
    • Database Theory for Siebel Enterprise Applications 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 SIERRA PROPRIETARY AND CONFIDENTIAL – DO NOT DISTRIBUTE Page 14 of 31
    • Database Theory for Siebel Enterprise Applications 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 07/29/10 SIERRA PROPRIETARY AND CONFIDENTIAL – DO NOT DISTRIBUTE Page 15 of 31
    • Database Theory for Siebel Enterprise Applications 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 SIERRA PROPRIETARY AND CONFIDENTIAL – DO NOT DISTRIBUTE Page 16 of 31
    • Database Theory for Siebel Enterprise Applications 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 SIERRA PROPRIETARY AND CONFIDENTIAL – DO NOT DISTRIBUTE Page 17 of 31
    • Database Theory for Siebel Enterprise Applications 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 SIERRA PROPRIETARY AND CONFIDENTIAL – DO NOT DISTRIBUTE Page 18 of 31
    • Database Theory for Siebel Enterprise Applications 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 SIERRA PROPRIETARY AND CONFIDENTIAL – DO NOT DISTRIBUTE Page 19 of 31
    • Database Theory for Siebel Enterprise Applications 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 SIERRA PROPRIETARY AND CONFIDENTIAL – DO NOT DISTRIBUTE Page 20 of 31
    • Database Theory for Siebel Enterprise Applications 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 SIERRA PROPRIETARY AND CONFIDENTIAL – DO NOT DISTRIBUTE 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 SIERRA PROPRIETARY AND CONFIDENTIAL – DO NOT DISTRIBUTE Page 22 of 31
    • Database Theory for Siebel Enterprise Applications 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 SIERRA PROPRIETARY AND CONFIDENTIAL – DO NOT DISTRIBUTE Page 23 of 31
    • Database Theory for Siebel Enterprise Applications 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 SIERRA PROPRIETARY AND CONFIDENTIAL – DO NOT DISTRIBUTE Page 24 of 31
    • Database Theory for Siebel Enterprise Applications 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 SIERRA PROPRIETARY AND CONFIDENTIAL – DO NOT DISTRIBUTE Page 25 of 31
    • Database Theory for Siebel Enterprise Applications 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. 07/29/10 SIERRA PROPRIETARY AND CONFIDENTIAL – DO NOT DISTRIBUTE Page 26 of 31
    • Database Theory for Siebel Enterprise Applications 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 07/29/10 SIERRA PROPRIETARY AND CONFIDENTIAL – DO NOT DISTRIBUTE Page 27 of 31
    • Database Theory for Siebel Enterprise Applications 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 SIERRA PROPRIETARY AND CONFIDENTIAL – DO NOT DISTRIBUTE Page 28 of 31
    • Database Theory for Siebel Enterprise Applications 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 07/29/10 SIERRA PROPRIETARY AND CONFIDENTIAL – DO NOT DISTRIBUTE Page 29 of 31
    • Database Theory for Siebel Enterprise Applications 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 SIERRA PROPRIETARY AND CONFIDENTIAL – DO NOT DISTRIBUTE Page 30 of 31
    • Database Theory for Siebel Enterprise Applications 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 SIERRA PROPRIETARY AND CONFIDENTIAL – DO NOT DISTRIBUTE Page 31 of 31