Configuring Siebel Business Applications > About Tables and Columns >

Guidelines for Configuring the Data Objects Layer

This topic describes guidelines to configure the data objects layer. It includes the following topics:

• Overview of Guidelines for Configuring the Data Objects Layer
• Guidelines for Creating a New Table
• Guidelines for Adding an Extension Column to a Base Table
• Guidelines for Creating a Custom Index
• Guidelines for Creating a LONG Column
• Guidelines for Modifying a Predefined One-to-One Extension Table
• Guidelines for Creating a Custom One-to-One Extension Table
• Guidelines for Configuring a Base Table or Configuring a One-To-Many Extension Table
• Guidelines for Configuring a Foreign Key That Affects Enterprise Integration Manager
• Guidelines for Creating a Custom Docking Rule

For more information, see Guidelines for Reusing a Predefined Table.

Overview of Guidelines for Configuring the Data Objects Layer

If you configure the data objects layer, then use the following guidelines:

• Do not modify a predefined base table or the columns of a predefined base table.
• Do not modify a predefined one-to-one extension table or the column of a predefined one-to-one extension table. For more information, see Options to Use a Predefined One-to-One Extension Table.
• The predefined user interface that Siebel CRM displays in the Siebel client does not use all of the relationships that are available in the underlying data objects layer. Most entity relationships are available for you to use. It is recommended that you use predefined objects in the data objects layer, if possible.
• To minimize the effect of your modifications on other developers, make any bulk modifications to the Siebel schema at the beginning of each project phase. If you make modifications during a project phase, then you must distribute these modifications to all other remote users. You can use Siebel Anywhere to distribute a schema modification. Otherwise, you must create a new database extract for each remote user before you can progress to the next phase.
• If your deployment runs in a DB2 environment, then do not create a column that contains a name that is longer than 18 characters.
• The data objects layer includes over 2,000 database tables. Each of these tables uses a consistent naming format to help you identify each individual table. For information on naming formats for tables, see About Siebel Tables.

Guidelines for Creating a New Table

If you create a new table, then use the following guidelines:

• You can only create the following types of tables:
  • Data (Public)
  • Data (Intersection)
  • Extension
• You must explicitly grant permissions on any table that you define.
• Create a new table only after you explore other ways of meeting your business requirements, such as using a predefined extension table.

Guidelines for Adding an Extension Column to a Base Table

You can add an extension column to a predefined base table. Adding an extension column avoids having to add another join to an extension table to store custom data. You can add an extension column to any of the following table types:

• Data table
• Intersection table
• Interface table
• Predefined extension table
• Custom extension table
• Extension (Siebel) table

You cannot add an extension column to a private data table that contains a value of Data (Private) in the Type property. Some interface tables are private, but most are public. Use the following guidelines if you add a column to a table:

• Any column you add must conform to the data type limitations of all the RDBMS types that your enterprise uses. Consider your server database and any regional or remote databases.
• If you add a new column to a predefined table with one or more rows of data, then the RDBMS does not allow you to add the column unless you include a default value.
• You cannot remove a column after you add it to a table. For more information, see the documentation for your database technology.
• If you add a column to a table, then do not use a column name that includes a word that is reserved on your server or client database. If you use an underscore (_) at the beginning and end of the reserved word, then you can use a reserved word. For more information, see Naming Format for a Siebel Table.
• If you create a new extension column in the Siebel schema, then padding problems might occur with Siebel Remote. For more information, see Siebel Remote and Replication Manager Administration Guide.

Guidelines for Creating a Custom Index

You can create a custom index to improve performance. If you create a custom index, then use the following guidelines:

• If you create a custom table, then the custom table typically requires new indexes.
• Use caution if you create an index. A custom index can result in a situation where objects reference the custom index instead of the predefined indexes. This situation can result in poor performance.
• If at some point you no longer require a custom index that you have defined, then do not delete it from the Siebel repository. Instead, you can deactivate it. Make sure the Inactive property of the index contains a check mark.
• You must thoroughly test any custom index in a test environment before you implement it in a production environment.
• In a DB2 environment, do not create an index that contains a name that is longer than 18 characters.

Guidelines for Creating a LONG Column

If you create a LONG column, then use the following guidelines:

• Only one LONG column can exist for each table.
• You can add a LONG column only to a one-to-one extension table whose Base Table property includes a valid base table.
• You cannot add a LONG column to a one-to-many extension table because it is a Data (Public) table.
• You cannot add a LONG column to a Data (Public) table, such as the S_EVT_ACT table. Only Oracle can create a LONG column in a Data (Public) table.
• You can use a LONG column to store a maximum of 16 KB or 16383 characters.
• Querying a LONG column starts more input and output operations in your RDBMS that are not necessary with other types of column data. This extra input and output increases the time Siebel CRM requires to get each row of data from the database. This increase can add up to a noticeable reduction in performance if Siebel CRM gets many rows of data from the database.
• For DB2 on z/OS, use a 32K tablespace if 16K is too small. If 32K is too small, then convert the LONG type to a CLOB type. For more information, see Implementing Siebel Business Applications on DB2 for z/OS.

Guidelines for Modifying a Predefined One-to-One Extension Table

It is strongly recommended that you add custom extension columns to the base table to store your data instead of storing frequently accessed data in columns in a one-to-one extension column. It is strongly recommended that you do not modify a predefined one-to-one extension table or the column of a predefined one-to-one extension table for the following reasons:

• Some of the columns that reside in a predefined extension table are not available to use because Siebel CRM uses them. You must not modify or delete an extension column that Siebel CRM uses.
• A C++ class might use the extension table in a reserved way. Modifying this table might cause behavior that you cannot predict.
• An upgrade effort might use the extension table, so you cannot predict future use of this table.
• Docking rules use some extension columns, so these columns are reserved for use with Siebel Remote. For more information, see Configuring Dock Objects for Siebel Remote.
• Use of an extension table affects performance because Siebel CRM must include the table in all queries that use the field that Siebel CRM uses to run the query. This situation can become a problem if Siebel CRM joins the table to multiple business components, specifically if a number of extension tables are in use.

It is permissible to use a predefined one-to-one extension table in the following situations:

• If you must use a LONG column because the database permits only one LONG column for each database table.
• If the implementation of a database constraint is beneficial. For example, to realize the improved performance that results when maximum bytes in a row are used before record chaining occurs.

Guidelines for Creating a Custom One-to-One Extension Table

If you create a custom one-to-one extension table, then use the following guidelines:

• If you must configure a table whose type is Extension or Extension (Siebel), then you must extend from the base table of the table, not from the extension table. The Base Table property of the extension table describes the base table to extend. For example, the S_CONTACT table is an extension table of the S_PARTY table. The S_CONTACT table is an Extension (Siebel) table, so you cannot use it as the parent table for an extension table. Instead, you can extend the S_PARTY table and use an implicit join to display the data from the extension table.
• A custom one-to-one extension table does not require new docking rules because the Siebel schema implicitly routes the data that this table contains according to the docking rules that the parent table specifies.

Guidelines for Configuring a Base Table or Configuring a One-To-Many Extension Table

You can use the following guidelines to help you decide to add an extension column to a base table or to use columns in a one-to-many extension table:

• Try to use a predefined one-to-many extension table or column to meet design requirements. They are predefined and already part of the data objects layer so they do not require you to modify the Siebel schema or the physical database. If a predefined extension table or column is not available, then explore other options, such as creating a new extension table.
• Add an extension column to a base table if the data you must store almost always exists for a base record, and if Siebel CRM does not regularly access it. This configuration often results in better performance because it avoids the join that an extension table uses. It can result in slower access to the base table if a lot of data exists where numerous large fields are added and where these fields always contain data. In this situation, fewer rows fit on one page.

  If a user query regularly includes an extension column, then it is likely that an index is required on the column that Siebel CRM must include on another base table column. You must add it to the base table.

• If one-to-many extension fields are required, and if the user only infrequently accesses the view that displays this data, then you can use columns in a one-to-many extension table. In this situation, Siebel CRM uses the join for the extension table, but only if the user accesses this view.

Guidelines for Configuring a Foreign Key That Affects Enterprise Integration Manager

Use caution if you configure an extension column to contain a foreign key. An extension column that contains a foreign key might be appropriate if it references a business object that is visible to the enterprise. You must avoid an extension column that contains a foreign key if it references a business object whose visibility is limited, such as Opportunity, Contact, Account, or Service Request. Using an extension column as a foreign key column can cause problems if Siebel CRM creates an EIM mapping or if it routes data to a remote user.

You cannot configure EIM to import data to a foreign key column because you cannot configure the required EIM object types.

You cannot add an EIM mapping for a foreign key relationship to a table that does not include a user key.

Guidelines for Creating a Custom Docking Rule

If your enterprise uses the Siebel Mobile Web Client, then note that Dock Object Visibility rules determine how Siebel CRM downloads data to the local database. These rules use predefined relationships to identify the data that Siebel CRM uses from the tables to help it route data to the local database that the remote user uses.

If you create a new relationship, then no Dock Object Visibility rules exist that allow Siebel CRM to download relevant data to the local database. This situation might result in a user who cannot view data. To resolve this problem, you can use the Docking Wizard to create custom docking rules for custom foreign keys. To avoid performance problems with the Transaction Processor and Transaction Router, you must analyze how your configuration affects performance before you create a new Dock Object Visibility rule or object.

If you add a rule, then you might inadvertently add a significant number of database records for Remote users. This configuration might affect initialization and synchronization performance. An increased number of records in the Remote database might affect performance.

For more information, see Configuring Dock Objects for Siebel Remote.