Configuring Siebel Business Applications > About Tables and Columns >

Guidelines for Customizing the Data Objects Layer

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

• Overview of Guidelines for Customizing 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 Customizing a Base Table or Customizing a One-To-Many Extension Table
• Guidelines for Customizing 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 Customizing the Data Objects Layer

If you customize 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 displayed in the Siebel client does not use all the relationships that are available in the underlying data objects layer. However, most entity relationships are available for you to use. Use predefined objects in the data objects layer, if possible.
• To minimize the affect of your changes on other developers, make any bulk changes to the Siebel schema at the beginning of each project phase. If you make changes during a project phase, then you must distribute these changes to all remote users. You can use Siebel Anywhere to distribute a schema change. Otherwise, you must generate a new database extract for each remote user before you can progress to the next phase.
• Do not create a column that contains a name that is longer than 18 characters in the DB2 environment.
• The data objects layer includes over 2,000 database tables. Each of these tables follows a consistent naming format to help you identify an 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.
• Use the New Table Wizard 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, which is identified with a Type property of Data (Private). Some interface tables are private, although 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 are used in your enterprise. Consider your server database and any regional or remote databases.
• In an Oracle database, the maximum length of an extension column with a VARCHAR data type is 2000 characters. If you create a VARCHAR column that is longer than 2000 characters, then the Siebel schema automatically implements it as a column with a LONG data type.
• 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 also provide a default value.
• After you add a column to the physical table, you cannot remove the column. For more information, see the documentation for your database technology.
• 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.
• 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. You can use a reserved word if you use an underscore (_) at the beginning and end of the word. For more information, see Naming Format for a Siebel Table.

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, do not delete it from the Siebel repository. Instead, to 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 only add a LONG column 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 slightly increases the time Siebel CRM requires to retrieve each row of data from the database, which can add up to a noticeable reduction in performance if Siebel CRM retrieves 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. Also, 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:

• All columns in a predefined extension table are not available to use because Siebel CRM uses some of the columns. 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 the table might cause behavior that you cannot predict.
• Because an upgrade effort might use the extension table, you cannot predict future use of the table.
• Because docking rules use some extension columns, the 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 on which Siebel CRM executes the query. This situation can become a problem if the table is joined 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 only permits 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 if 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 customize 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 which base table to extend. For example, the S_CONTACT table is an extension table of the S_PARTY table. Because the S_CONTACT table is an Extension (Siebel) table, you cannot use it as a parent table for an extension table. Instead, 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 data in this table according to the docking rules of the parent table.

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

To decide to add an extension column to a base table or to use columns in a one-to-many extension table, consider the following guidelines:

• 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 modification of 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 extension columns to a base table if the data you must store almost always exists for a given base record and is accessed regularly. By avoiding the join that an extension table uses, this technique often results in better performance. However, note that 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.

  NOTE:  If a user query regularly includes an extension column, then it is likely that an index is required on the column that must be included on another base table column. Therefore, you must add it to the base table.

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

Guidelines for Customizing 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 generates an EIM mapping or if Siebel CRM 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 govern how Siebel CRM downloads data to the local database. These rules use predefined relationships to determine which data from which tables Siebel CRM routes to the local database of the remote user.

If you create a new relationship, then there are no Dock Object Visibility rules that allow relevant data to be downloaded to the local database. This situation might result with a user who cannot view data. To resolve this problem, you can use a feature of the Docking Wizard to create custom docking rules for custom foreign keys. You must analyze how your customization affects performance before you create a new Dock Object Visibility rule or object. This analysis is required to avoid performance problems with the Transaction Processor and Transaction Router.

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

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