Configuring Composite Objects

Transcription

1 Configuring Composite Objects Informatica Corporation. No part of this document may be reproduced or transmitted in any form, by any means (electronic, photocopying, recording or otherwise) without prior consent of Informatica Corporation. All other company and product names may be trade names or trademarks of their respective owners and/or copyrighted materials of such owners.

2 Abstract A composite object is a grouping of MDM Hub base objects, with each base object containing a different type of information about a parent base object. Administrators define composite objects to build a data model. This article describes how to define a composite object by using an XML configuration file that you import into the MDM Hub environment. Supported Versions MDM Multidomain Edition Table of Contents Composite Objects Entity 360 Data View Smart Search Composite Object Configuration Composite Object Configuration File Header Composite Object Structure Root Object Configuration Lookup Configuration Foreign Key Relationships Child Object Configuration field Element Parent Object and Child Object Configuration Example Cyclical Dependencies Enabling State Management Validation Filters Composite Object Structure Example Composite Object XML Configuration Example Uploading the Composite Object Configuration File to the MDM Hub Updating the Composite Object Configuration File Composite Objects A composite object brings together the information related to a root base object into a single entity. A composite object consists of a nested structure of base objects. The other base objects in the composite object are nested as child nodes. You can nest base objects as child nodes within other child nodes. There is no limit to the number of nested levels. Composite objects reside in the MDM Hub and you can validate the composite object configuration using the Repository Manager in the Hub Console. You view the data in a composite object in the Entity 360 view in Informatica Data Director. You must configure composite objects to use the Entity 360 view in Informatica Data Director and Smart Search in the MDM Hub. 2

3 To define a composite object, define the columns in the base object and the relationships between the base objects. You do not need to define system fields for the base objects. For example, a composite object named Person has a base object named C_Party as the root node. Under the root node are child nodes for telephone numbers, addresses, and organization. When you view the Person composite object in the Entity 360 view, you also can see the telephone, address, and organization data that relates to the person. The Person composite object gives you a complete view of all data that relates to the C_Party root node. When you define the data model, the MDM Hub creates the required artifacts, such as base objects and foreign key relationships. Entity 360 Data View The Entity 360 data view displays the data in a composite object. For example, you have a composite object with a Person base object as the root node and a Phone base object as a child node. The following image shows the composite object structure for a composite object with a Person root node and Phone child node: When you view the composite object in the Entity 360 data view, you can view a Person record and all the Phone records that are associated with the person. The following image shows the Entity 360 data view for a composite object with a Person root node and Phone child node: Smart Search Perform a smart search to find data within a specific collection or all the collections of composite objects based on a string value. The Informatica Data Director application displays the matching fields that can be searched and displayed. The results are ranked based on how closely the results match the string value. You can apply filters to narrow down the results. 3

4 Composite Object Configuration You can configure composite objects by manually configuring the composite object configuration file or by converting an Informatica Data Director Configuration to a composite object configuration. You can also convert an Informatica Data Director Configuration to a composite object configuration and then manually adding additional composite objects. The easiest way to configure composite objects is to use Informatica Data Director Configuration Manager to convert an Informatica Data Director configuration to a composite objects configuration. When you convert an Informatica Data Director configuration to a composite objects configuration, composite objects can only be three levels deep. The Informatica Data Director configuration restricts you to a root node, a child node, and a grandchild node. See the Informatica MDM Multidomain Edition Informatica Data Director Configuration Manager Online Help for more information about converting an Informatica Data Director configuration to a composite objects configuration. You can manually add composite objects to the composite objects configuration that Informatica Data Director Configuration Manager generates. After you generate a composite objects configuration with Configuration Manager, you can change the XML file in the CONFIG_BLOB column in the row with a CONFIG_TYPE of Composite_Objects in repository table C_REPOS_CO_CS_CONFIG. You can only add composite objects to the configuration file. If you change the configuration for a composite object that Informatica Data Director Configuration Manager, the changes are overwritten when you save an Informatica Data Director application configuration. You can also manually configure the complete composite objects, but it is easier to edit a composite object configuration that was generated by Configuration Manager. After you upload the configuration to repository table C_REPOS_CO_CS_CONFIG, use the Repository Manager in the MDM Hub to validate the configuration. Composite Object Configuration File Header The composite object configuration file header contains the coconfiguration element. The configuration for all composite objects resides in the composite object configuration file within the coconfiguration element The follow code sample shows the composite object configuration file header: <?xml version="1.0" encoding="utf-8" standalone="yes"?> <coconfiguration xmlns=" Composite Object Structure A composite object has a root node under which can be multiple levels of child nodes that contain information that relates to the root node. Child nodes can also have child nodes. There is no limit to the depth of composite objects. For example, you have a composite object with an Organization object as the root node. Under the Organization root node is and Address node and Employee node. Under the Employee node is a Phone node that contains employee phone numbers. When you view an Organization record, you can also see the associated address record, and the associated employee records. The composite object contains all the detailed information that relates to the Organization root node. 4

5 The following illustration shows a simple composite object: The Address node and Employee node are children of the Organization root node. Employee is a parent of the Phone node. When you configure the composite object, you must define the foreign key relationship between Organization and Address, between Organization and Employee, and between Employee and Phone. Root Object Configuration To configure the root object, configure the attributes for the coroot element. The root object is the top-most object in the composite object structure. You can define the following attributes for the coroot element: name The name of the composite object. hubobject The name of the root object base object. statemanagementenabled Determines if the repository manager performs state management validation checks on the composite object. Set to true for the repository manager to validate that all base objects in the composite object are statemanagement enabled. Set to false to allow both state management-enabled base objects and base objects that are not state management-enabled base objects. Default is false. Lookup Configuration You can configure base objects in a composite object to be a lookup. A lookup contains lookup values that users can select from a menu in Informatica Data Director. You configure a lookup node in the same way that you configure a root node, but you use the lookup element instead of the coroot element. You cannot configure child nodes for a lookup. A lookup is handled the same way as any other child object. You must not change the value of a referenced lookup field. If you change the value of a referenced lookup field, some object might reference the old value and other objects might reference the new value. The following XML code shows how to configure a lookup for the gender field: <lookup hubobject="c_lu_gender" name="lugender"> <field name="gendercode" column="gender_code"/> <field name="genderdisp" column="gender_disp"/> </lookup> 5

6 When you configure a lookup element, the MDM Hub enables the advanced base object Lookup Indicator property. Foreign Key Relationships The MDM Hub uses foreign keys to maintains relationships between child objects and parent objects. In a foreign key relationship, the child object has a foreign key column and the parent object has a primary key column. The MDM Hub uses the keys to associate a parent record with a child record. The foreign key column of the child record contains the value of the associate parent primary key. The following image shows a Phone child object linked to a Person parent object by a foreign key relationship: The Person object has a primary key column called ID and the Phone object has a foreign key column called Person_ID. The primary key value of 3 links the record for Tom to the record for the phone number Use the constraint attribute of the one, many, referenceone, or referencemany elements to specify the foreign key relationship that the child object has with the parent object. The constraint attribute requires the following syntax: <child base object name>(<foreign key column name>).<parent base object name>(primary key column name>) The following code shows the constraint attribute for the example: constraint="c_phone(person_id).c_person(rowid_object)" One-to-Many Relationships A one-to-many relationship links a parent record to multiple child records. An example of a one-to-many relationship is a relationship between a person record and phone records. A record for a person can have multiple phone numbers associated with it. Many-to-One Relationships A many-to-one relationship links multiple parent records to a child record. An example of a many-to-one relationship is a relationship between person records and an address record. Records for multiple people can have the same address record associated with them when the people are living at the same address. 6

7 Child Object Configuration When you configure a child object, you can specify the fields for the associated base object and you also specify the relationship to the parent object. Use the one, referenceone, many, and referencemany elements to define relationships between the base objects. When you define a child object, you specify the relationship it has with the parent object. Use the one or referenceone element to configure a child object with a one-to-many relationship with the parent. Use the many or referencemany element to configure a child object with a many-to-one relationship with the parent. one Element Use the one element to define a child object that has a one-to-many relationship with a parent object. Configure the following attributes for the one element: hubobject The name of the child base object in the MDM Hub. name The name to use to refer to the child base object within the composite object. constraint Defines the foreign key relationship that links the parent base object and the child base object. referenceone Element Specifies a one-to-many relationship between a child object you have already defined and a parent object. Use the referenceone element when you have used the one or many element to define the fields of the child object. You cannot use the referenceone element if you have not defined the child object. Configure the following attributes for the referenceone element: object name constraint The name of the child base object in the MDM Hub. The name to use to refer to the child base object within the composite object. Defines the foreign key relationship that links the parent base object and the child base object. many Element Use the many element to define a child base object that has a many-to-one relationship with the parent. Configure the following attributes for the many element: hubobject Specifies the name of the child base object in the MDM Hub. name Specifies the name to use to refer to the child base object within the composite object. constraint Defines the foreign key relationship that links the parent base object and the child base object. 7

8 referencemany Element Specifies a many-to-one relationship between a child object you have already defined and a parent object. Use the referencemany element when you have used the one or many element to define the fields of the child object. You cannot use the referencemany element if you have not defined the child object. Configure the following attributes for the referencemany element: object name constraint The name of the child base object in the MDM Hub. The name to use to refer to the object within the composite object. Defines the foreign key relationship that links the parent base object and the child base object. field Element Use the field element with the one element, many element, coroot element, and lookup element. Use the field element within the one element to specify columns for the base object. The base object with the fields you specify are created in the MDM Hub after you import the composite object configuration file. You do not need to define system columns. The MDM Hub creates the necessary system columns. Configure the following attributes for the field element: name column Display name of the column. Name of the column in the base object. Parent Object and Child Object Configuration Example You want to configure a parent object named C_PARTY_PHONE with a child object named C_PHONE_CHILD in a one-to-many relationship The following image shows the fields of the C_PARTY_PHONE object and the C_PHONE_CHILD object: 8

9 The following code shows how to configure the two objects and their relationship: <coroot hubobject="c_party_phone" name="phone"> <field name="phonecountrycd" column="phone_country_cd"/> <field name="phonenumber" column="phone_num"/> <field name="phoneextnumber" column="phone_ext_num"/> <field name="isvalidind" column="is_valid_ind"/> <field name="effstartdate" column="eff_start_date"/> <field name="effenddate" column="eff_end_date"/> <field name="donotcallind" column="do_not_call_ind"/> <one constraint="c_phone_child(phone_id).c_party_phone(rowid_object)" hubobject="c_phone_child" name="phoneuse"> <field name="phoneid" column="phone_id"/> <field name="column1" column="column1"/> <field name="column2" column="column2"/> <field name="column3" column="column3"/> </one> </coroot> Cyclical Dependencies Avoid cyclical dependencies when you use the referenceone or referencemany element to define a child object. A cyclical dependency occurs when you use referenceone or referencemany element to define a child base object, but then use the referenceone or referencemany element to define the parent base object as the child base object. The following code shows an example of a cyclical dependency: <coroot name="aaa" hubobject="c_a" > <referenceone object="bbb"/> </coroot> <coroot name="bbb" hubobject="c_b" > <referencemany object="aaa"/> </coroot> To avoid the cyclical dependency, do not use a referenceone or referencemany element in one of the root objects. The following code shows one way to correct the preceding example and avoid the cyclical dependency: <coroot name="aaa" hubobject="c_a" > <referenceone object="bbb"/> </coroot> <coroot name="bbb" hubobject="c_b" > <many name="aaachild" hubobject="c_a"/> </coroot> Enabling State Management Validation To enable Repository Manager to check that state management is enabled consistently for all base objects in a composite object, set the attribute statemanagementenabled to true in the coroot element. The value of statemanagementenabled is false by default. When statemanagementenabled is true the Repository Manager validation checks that all base objects in the composite object are enabled for state management, except referenced lookups. When statemanagementenabled is false the Repository Manager does not verify that the base objects in the composite object are all state management enabled. The composite object can contain base objects that are state management enabled and base objects that are not state management enabled. The value of statemanagementenabled affects the Repository Manager validation check. The value of statemanagementenabled does not affect run-time operations. When you change statemanagementenabled from true to false, state management is not disabled for base objects. 9

10 Filters You can define a filter for a field in a composite object atomic element. Use the filter element to define a filter for a field. You can specify the following types of filters: IN NOT_IN The filter values are the only values allowed in the field. The filter values are not allowed in the field. IN Filter Example You want to create a filter that only allows a STATE_CD value of NY. The following code shows how to configure a filter for the STATE_CD field so that NY is the only value that STATE_CD can have: <field name= state code" column= STATE_CD"> <filter operator= IN"> <value>ny<value> </filter> </field> NOT_IN Filter Example You want to create filter to prevent the value Employee to be entered in the PARTY_TYPE field. The following code shows how to configure a filter for the PARTY_TYPE field so that the value Employee is not permitted: <field name= Party Type" column= PARTY_TYPE"> <filter operator= NOT_IN"> <value>employee<value> </filter> </field> 10

11 Composite Object Structure Example The composite object example has a parent node based on C_PARTY, with child nodes containing phone data. The following image shows the structure of the composite object example: Composite Object XML Configuration Example Use the composite object XML configuration example to create the composite object data model example. The following code sample shows a composite object configuration file: <?xml version="1.0" encoding="utf-8" standalone="yes"?> <coconfiguration xmlns=" <lookup hubobject="c_lu_phone" name="luphonetype"> <field name="phonetype" column="phone_type"/> <field name="phonetypedisp" column="phone_type_disp"/> </lookup> <coroot statemanagementenabled="false" hubobject="c_party" name="person"> <referenceone name="preferredphone" object="person.phone" constraint="c_party(preferred_phone).c_party_phone(rowid_object)"/> <many constraint="c_party_phone(party_id).c_party(rowid_object)" hubobject="c_party_phone" name="phone"> 11

12 <field name="phonecountrycd" column="phone_country_cd"/> <field name="phonenumber" column="phone_num"/> <field name="phoneextnumber" column="phone_ext_num"/> <field name="isvalidind" column="is_valid_ind"/> <field name="effstartdate" column="eff_start_date"/> <field name="effenddate" column="eff_end_date"/> <field name="donotcallind" column="do_not_call_ind"/> <referenceone name="phonetype" object="luphonetype" constraint="c_party_phone(phone_type_cd).c_lu_phone(phone_type)"/> <many constraint="c_phone_child1(phone_id).c_party_phone(rowid_object)" hubobject="c_phone_child1" name="phoneuse"> <field name="phoneid" column="phone_id"/> <field name="column1" column="column1"/> <field name="column2" column="column2"/> <field name="column3" column="column3"/> </many> <many constraint="c_phone_child3(phone_id).c_party_phone(rowid_object)" hubobject="c_phone_child3" name="phonepermissions"> <field name="phoneid" column="phone_id"/> <field name="column1" column="column1"/> <field name="column2" column="column2"/> <field name="column3" column="column3"/> </many> <many constraint="c_phone_child_rel(phone_id).c_party_phone(rowid_object)" hubobject="c_phone_child_rel" name="phoneservice"> <field name="phoneid" column="phone_id"/> <field name="effstartdate" column="eff_start_date"/> <one constraint="c_phone_child_rel(child_id).c_phone_child2(rowid_object)" hubobject="c_phone_child2" name="phonechild2"> <field name="column1" column="column1"/> <field name="column2" column="column2"/> <field name="column3" column="column3"/> </one> </many> <many constraint="c_phone_child4_rel(phone_id).c_party_phone(rowid_object)" hubobject="c_phone_child4_rel" name="testphone"> <field name="phoneid" column="phone_id"/> <field name="effstartdate" column="eff_start_date"/> <referenceone name="testphone" object="testphone" constraint="c_phone_child4_rel(child_id). C_PHONE_CHILD4 (ROWID_OBJECT)"/> </many> </many> </coroot> </coconfiguration> Uploading the Composite Object Configuration File to the MDM Hub To upload the composite object XML configuration file, use a database tool that can handle the BLOB data type. Upload the files to the C_REPOS_CO_CS_CONFIG repository database table. Populate the following columns in the C_REPOS_CO_CS_CONFIG repository database table when you upload the composite object configuration: CONFIG_TYPE Specifies the configuration type. The value must be COMPOSITE_OBJECTS. CONFIG_BLOB Contains the XML configuration file for the composite objects. 12

13 Updating the Composite Object Configuration File To update the composite object configuration file, update the LAST_UPDATE_DATE field and use the Repository Manager to validate the composite object configuration. 1. Edit coconfig.xml with the required updates to the composite object configuration. 2. Use a database tool that can handle the BLOB data type to upload the coconfig.xml file to repository table C_REPOS_CO_CS_CONFIG. Upload the coconfig.xml file to the CONFIG_BLOB column in the row with the CONFIG_TYPE of COMPOSITE_OBJECTS. Save the database changes. 3. In the row in table C_REPOS_CO_CS_CONFIG where you uploaded coconfig.xml, update the date in the LAST_UPDATE_DATE column to a newer time. Save the database changes. You must update the LAST_UPDATE_DATE value if the database tool that you use to update the repository table does not trigger an update to the date in the LAST_CHANGE_DATE column in table C_REPOS_DB_RELEASE. 4. In the MDM Hub, use the Repository Manager to validate the Operational References Store. The Repository Manager validation refreshes the repository data that is cached in the application server. Author MDM Documentation 13