Inner Joins: BC based on S_PARTY table, this user property specifies an extension table to S_ PARTY for which the

join to the extension table is an inner join. BC User Property: Name: Inner Join Extension Table 1 Value: S_CONTACT Name: Inner Join Extension Table 2 Value: S_USER Name: Inner Join Extension Table 3 Value: S_EMP_PER Note: Here the first one is the primary extension table. If we create a new BC that is based on the Siebel Party Model; then we need to s pecify the 'Inner Join Extension Table' property at the BC level. We may need to create such a BC in order to configure visibility for a group tha t does not fit any of the existing Siebel Party Model BC. Outer Joins: - Outer join does not require each record in the two joined tables to have a mat ching record in the other table. - Example is b/w S_ORDER & S_ORG_EXT (Orders and Billing Account). Normally all the Orders should be visible even though there is NO billing account exists for that order. In other word all the parent records should be visible even though there is NO j oined table record exists. SQL statement: SELECT so.ORDER_NUM OrderNumber, sorg.NAME BillingAccount FROM siebel.s_order so, siebel.s_org_ext sorg WHERE so.BL_OU_ID = sorg.row_id(+) SELECT so.ORDER_NUM OrderNumber, sorg.NAME BillingAccount FROM siebel.s_order so LEFT OUTER JOIN siebel.s_org_ext sorg ON so.BL_OU_ID = sorg.row_id -----Implicit Joins: Implicit join exists b/w tables having 1:1 relationship. Implicit meaning implied join already exists b/w tables and need to be configure d. NO Join Spec defined and its an hidden object using field "ID" and PAR_ROW_ID of (S_CONTACT_X). Ex: S_CONTACT_X is the extension table for S_CONTACT and the relationship b/w th em is 1:1 which is already defined within the BC. EXplicit Joins: Opposite of Implicit Join. Explicit joins exists b/w tables which doesn't have direct relationship. Join has to be defined explicitly. Join is to defined b/w tables to create 1:1 relationship.

Ex: Join b/w S_CONTACT and S_ADDR_PER where a contact can have only one primary address. Join Definition: S_CONTACT.PR_PER_ADDR_ID = S_ADDR_PER.ROW_ID. Ex2: S_ORG_EXT and S_CONTACT (where one A/C can have only one primary contact). Join Definition: S_ORG_EXT.PR_CON_ID = S_CONTACT.PAR_ROW_ID ------------Links: 1:M relationship 1:M relationship b/w tables means that for every record in the first table there could be corresponding multiple records in the second table. In siebel this type of r/w found b/w base table and extension table. Ex (S_CONTACT & S_CONTACT_XM). Extension table (Many Side) consists of FKey (PAR_ROW_ID) points to the PKey (RO W_ID) of base. Base table here (First table) consists of PKey (ROW_ID). Scenario: Contact person could have multiple types of loans with varying interest rates. T his type of info can be stored in the S_CONTACT_XM table and still be related to a single contact. This r/w will be defined in tools using object called LINK. We dont refer directly to the table columns. We define a link b/w Parent BC (based on S_CONTACT) and Child BC (based on S_CON TACT_XM) and mentioned Source (ROW_ID) & Destination Field (PAR_ROW_ID).