TECHNICAL NOTE 0063: Implied Joins

Last Modified: Area(s): Release(s): Latest release tested against:

28 November 2001 Configuration - General V5 (Siebel 99-Enterprise), V6 (Siebel 2000-Enterprise), V7 (Siebel 7) V7 (Siebel 7)

Background Usually, if a business component contains fields that come from a different database table than the primary table of the business component itself, a join is used to include the other tables into the business component. This technical note describes two exceptions to this rule: extension tables and intersection tables. In both of these cases, the join is implied and should not be specified explicitly. Summary Each business component in Siebel eBusiness Applications is based upon a single primary database table, the name of which is specified in the Table property of the business component. For a given business component, every field in that business component is either: 1. a calculated field that is not mapped to any database column, 2. mapped to a database column from the primary table of the business component, or 3. mapped to a database column from a table which is not the primary table of the business component but which can be joined to that table via a primary key and foreign key relationship. When the field is based on a column from the primary table of the business component (the second case above), the Col property of the field indicates the name of the database column to which it maps. When the field is based on a column from another table (the third case above), the Join property of the field must be specified in addition to its Column property in order to identify the database column to which the field maps. As a general rule, if the Join property is used on a field, then the referenced table name must correspond to the Destination Table property of a join in the same business component. In other words, in order to use a table that is not the primary table of the business component, Siebel eBusiness Applications needs to know how the two tables are related; the join defines this relationship between the tables. In the following example, table S_ORG_EXT is joined into the Internal Product business component, which is itself based on the S_PROD_INT table. The join is necessary in order to populate the Vendor [Field] from table S_ORG_EXT (bold added for emphasis):

[Business Component] Name = "Internal Product" Table ="S_PROD_INT" [Join] Source Field = "Vendor Id" Destination Table = "S_ORG_EXT" Outer Join Flag = "True" [Field] Name = "Vendor" Column = "NAME" Join = "S_ORG_EXT" TextLength = "50" PickList = "PickList Vendor" [Field] Name = "Vendor Id" Column = "VENDR_OU_ID" Type = "DTYPE_ID" Two Exceptions There are two general cases where Siebel eBusiness Applications already knows the relationship between a pair of database tables and therefore does not need an explicit join to describe the relationship: 1. the relationship between an extension table and its corresponding base table, and 2. the relationship between a business component's table and the intersection table that was used to link the business component with it s parent business component. In both of these cases, the business component field must still include a table property [via a join or a link] to indicate its data source, but the specified database table does not need to be explicitly defined as a join into the business component. Extension Tables Unlike most primary key and foreign key relationships in Siebel eBusiness Applications (which are usually one-to-many), the relationship between an extension table and its associated base table is a (optional) one-to-one relationship. This relationship between the two tables, which enables the extension table to 'extend' the base table with additional columns, is automatically defined when the extension table is created via the Database Schema view; so Siebel eBusiness Applications are already aware of this relationship. Therefore, if the Join property of a field refers to a database table that is an extension table for the primary table of the business component, an implied Join will automatically be created between the two tables, and the join should not be specified explicitly. For example: a column has to be added from extension table S_PROD_INT_X to the Internal Product business component above. Since the join is already implied, just add the field as follows:

[Field] Name = "New Field" Column = "ATTRIB_01" Join = "S_PROD_INT_X" TextLength = "100" Note that, although the Join to the S_PROD_INT_X table is implied, the Join property for the field itself must always be specified if it is not the primary table of the business component. The join for an extension table is only implied if the associated base table is the primary table of the business component. For example, if a column is to be added from the extension table S_ORG_EXT_X, another join would be necessary since the base table for this extension table, S_ORG_EXT, is not the primary table of the business component: [Join] Source Field = "Vendor Id" Destination Table = "S_ORG_EXT_X" Destination Column = "PAR_ROW_ID" Outer Join Flag = "True" [Field] Name = "Another New Field" Column = "ATTRIB_01" Join = "S_ORG_EXT_X" Text Length = "100" In this case, S_ORG_EXT_X is treated just like any other explicitly joined table, rather than like a special extension table; for example, it cannot be updated directly via this business component since joined tables do not support updates. Intersection Tables When two database tables share a many-to-many relationship via an intersection table, that intersection table is identified in the link between any two business components that are based on those tables. For example, consider the link between Opportunity and Contact via the S_OPTY_CON intersection table: [Link] Name = "Opportunity/Contact" Parent Business Component = "Opportunity" Child Business Component = "Contact" Inter Table = "S_OPTY_CON" Inter Parent Column = "OPTY_ID" Inter Child Column = "PER_ID" Now, when such a link is used to retrieve all of the child business component records for the current record in the parent business component, columns from the intersection table can be accessed by adding fields to the child business component. Each of these fields that are based on a column from the intersection table must specify that table in their

Table property. For example, when all of the Contacts for a given Opportunity are retrieved, the role that each Contact plays for that Opportunity can be included by creating the necessary multi-value link and adding a new Role field to the Contact business component which references the link. No join is needed for S_OPTY_CON because Siebel eBusiness Applications is already using that intersection table to create the link between the Contact business component and its parent, Opportunity business component. Of course, the Contact business component is used in a variety of ways throughout Siebel eBusiness Applications; it is not always a child of the Opportunity business component. In those instances where the Contact business component is not linked to the Opportunity business component via S_OPTY_CON, any fields that are based on that intersection table will simply be ignored. So, the configurator should make sure that fields from an intersection table are only exposed through UI Columns and UI Fields on views where data from the intersection table will be available via a link. There are two types of joins that can be defined for a business component, explicit and implied. Explicit joins are used to display fields that come from a different database table than the primary table of the business component itself; these additional fields do not have any predefined relationship with the target business component. Implied joins are used when Siebel eBusiness Applications already knows the relationship between a pair of database tables and therefore does not need an explicit join to describe the relationship. Implied joins are used when users want to join to an extension tables or make use of the intersection tables.