Table of Contents

Search

  1. Introduction
  2. Configuring Hub Console Tools
  3. Building the Data Model
  4. Configuring the Data Flow
  5. Executing Informatica MDM Hub Processes
  6. Configuring Application Access
  7. MDM Hub Properties
  8. Viewing Configuration Details
  9. Search with Solr
  10. Row-level Locking
  11. MDM Hub Logging
  12. Table Partitioning
  13. Collecting MDM Environment Information with the Product Usage Toolkit
  14. Glossary

Step 3: Configuring Base Objects

Step 3: Configuring Base Objects

You created the two base objects (Product and Product Rel) in the previous section. This section describes how to configure them.
Configuring a base object involves filling in the criteria for the object’s properties, such as the number and type of columns, the content of the staging tables, the name of the cross-reference tables (if any), and so on. You might also enable the history function, set up validation rules and message triggers, create a custom index, and configure the external match table (if any).
Whether or not you choose these options and how you configure them depends on your data model and base object choices.
In the example, John configures his base objects as the following sections explain.
Not all components of the base-object creation are addressed here, only the ones that have specific significance for data that will be used in the
HM
. For more information on the components not discussed here, see Building the Schema.
The following figure shows the base object columns:
This table shows the Product BO after conversion to an
HM
entity object. In this list, only the Product Type field is an
HM
field.
Every base object has system columns and user-defined columns. System columns are created automatically, and include the required column: Rowid Object. This is the Primary key for each base object table and contains a unique, Hub-generated value. This value cannot be null because it is the
HM
lookup for the class code.
HM
makes a foreign key constraint in the database so a ROWID_OBJECT value is required and cannot be null.
For the user-defined columns, John choose logical names that would effectively include information about the products, such as Product Number, Product Type, and Product Description. These same column and column values must appear in the staging tables as shown in the following figure:
John makes sure that all the user-defined columns from the staging tables are added as columns in the base object, as the graphic above shows. The Lookup column shows the
HM
-added lookup value.
Notice that several columns in the Staging Table (Status Cd, Product Type, and Product Type Cd) have references to lookup tables. You can set these references up when you create the Staging Table. You would use lookups if you do not want to hardcode a value in your staging table, but would rather have the server look up a value in the parent table.
Most of the lookups are unrelated to
HM
and are part of the data model. The Rbo Bo Class lookup is the exception because it was added by
HM
.
HM
adds the lookup on the product Type column.
When you are converting entities to entity base objects (entities that are configured to be used in
HM
), you must have lookup tables to check the values for the Status Cd, Product Type, and Product Type Cd.
HM
Entity objects do not require start and end dates. Any start and end dates would be user defined. However, Rel Objects do use these. Do not create new Rel Objects with different names for start and end dates. These are already provided.

0 COMMENTS

We’d like to hear from you!