Configuring Siebel eBusiness Applications > Configuring Tables and Columns >

Guidelines for Extending the Data Model

When extending the database consider the following:

• Do not modify standard base tables and their columns.
• In most cases, try to use static extension tables and columns to meet design requirements. They are preconfigured and already part of the Siebel data model so they do not require modification of the schema or the physical database. If static extension tables and columns are not available, then explore other options, such as creating new extension tables.
• When deciding whether to add an extension column to a base table or to use columns in an extension table, consider the following recommendations:
  • Add extension columns to base tables when the data you need to store almost always exists for a given base record and it is accessed regularly. By avoiding the join used with an extension table, this approach often results in better performance. However, note that it can result in slower access to the base table if there is a lot of data (that is, many large fields have been added and they are always populated), because fewer rows now fit on one page.

    NOTE:  When an extension column will be regularly specified in user queries, it is likely to need an index on the column that may need to include other base table columns; and therefore should be added to the base table.

  • Use columns in an extension table when a one-to-many extension fields are required, and the view displaying this data is accessed infrequently. In this case, the join is executed for the extension table, but only when this view is accessed.
  • As a general rule, if you plan to display additional attributes in a list applet, add extension columns to the base table; if you plan to display additional attributes in a form applet, use extension table columns.
• The standard user interface does not use all the relationships available in the underlying data model; however, most entity relationships are available for you to use. During the discovery phase of an implementation, try to meet business requirements using the existing data model and standard objects.
• To minimize the impact of your changes on other developers, make any bulk changes to the schema at the beginning of each project phase. If you make changes during a project phase, then these need to be distributed to all mobile users. You can use Siebel Anywhere to distribute a schema change; otherwise, you generate new database extracts for all of your mobile users before you can progress to the next phase.
• Use caution when configuring a extension column to hold foreign keys. Foreign key extension columns may be appropriate when pointing to enterprise-visible business objects, but they should be avoided when pointing to limited-visibility business objects such as Opportunity, Contact, Account, or Service Request. Using extension columns foreign key columns can cause problems when generating EIM mappings and when routing data to mobile users.

  You cannot configure EIM to import data into a foreign key column, because the necessary EIM object types cannot be configured by customers.

• Do not define columns with names longer than 18 characters in the DB2 environment.
• You cannot add EIM mappings for foreign key relationships to tables that do not have user key attributes.
• The Siebel Data Model consists of over 2,000 database tables. Each of these tables follows a standard naming convention to help users identify individual tables. For information on naming conventions for tables, see About Tables.
• When planning or implementing Mobile Web Client users, be aware that downloading data to the local database is governed by Dock Object Visibility rules. These rules use the standard relationships to determine which tables' data are routed to the mobile user's local database.

  Thus, when new relationships are created, there are no Dock Object Visibility rules that allow relevant data to be downloaded to the local database. This may cause users to not be able to see their data.

  To resolve this, you can use a Docking Wizard feature to create custom docking rules for custom foreign keys. However, you may encounter some performance concerns if you do not analyze the results of the functionality implemented by the Docking Wizard before you implement a new Dock Object Visibility rule or object. Primarily, the performance of your remote processes (such as the Transaction Processor and Router) may be affected.

  In addition, by adding a rule you may be inadvertently adding a significant number of database records to remote users, which could affect initialization and synchronization times. An increased number of records in the remote database may also impact the mobile user application's performance.

  For more information about Dock Objects, see Configuring Docking Rules.