I was new to MDM 5 months ago, back in April 2005 on a project to implement MDM as a product data hub. Coming up the learning curve with the tool has been a very interesting exercise. I discovered several learning strategies and tips that could make things easier for new users. Here, my objective is to share these strategies and tips with others.
I used a three-pronged approach for learning that may be helpful to you:
- Cursory read through the manuals available on web (related to the MDM service pack version) to get familiarized with new features and terminology
- Open the modules (console, data manager, import manager, etc.) and start playing- add tables and fields, add records, import records, etc.
- Prototype some of your business requirements, and ask questions of SAP resources when you are stuck.
I compiled my learnings by module, and the first one is about console. I will publish the tips on data manager configuration, and import manager easy loads in my next blog.
Console- Configure the Data Model:
- Understand the different tables types (look-up, main, qualified look-up, hierarchy, etc.), field types (text, integer, BLOB, multi-valued, etc.) of MDM.
- Explore taxonomy option for your data; taxonomy is very suitable if (a) the data you are working with represents true hierarchies, and (b) when you do not need check table (look-up table) validation for your attribute values.
- Taxonomy attributes, as opposed to fields on the tables, are NOT part of console configuration. They are defined using data manager UI screens.
- Qualified look-ups hang off from main table, and help further define the main table data for levels of detail (for example, goods sold in different seasons, countries, costing, etc.)
- Qualified tables have a set of non-qualifiers (in MDM terms) that are basically the reference lists of differentiators (a list of countries for example); and qualifiers which are simple fields that further qualify/define the relationship of main table record to the non-qualifier.
- While translating business requirements into MDM physical objects, try to meet more business requirements with fewer tables.
- If you want to use a field in drill-downs of your data in data manager, use a look up table to back up the field.
Key-Mapping and Display Fields:
- Set the key-mapping to Yes on all tables you want to generate keys for. This generates a remote key for every record in the table using the display fields of that table.
- Display fields selection needs to take into account a) the primary key of the (data of) table and b) the fields that you want displayed if the table is used as a pop-down list.
- The remote key is used for record matching in import manager loads for accurate inserts and updates to the table.
- Import manager loads generate a key for every record automatically while for manually entry records, you edit the key mapping on the record in data manager module (right click and select edit key mapping option).
- A field of data type literal date cannot currently be marked as display field, and hence cannot be part of key definition for that table.
- Lastly, you cant delete a field if the field is marked as a display field. Turn off the display field property first.
Uniqueness at table and Field level:
- Selecting Yes on the field level uniqueness setting will override the uniqueness created at the table level. So, please beware.
- I identify the uniqueness definition for my table data; I also identify other fields whose data needs to be unique in the table, and set them all at the table level unique field box. I found this less confusing, and it gave me a holistic view in the context of the table.
- When creating uniqueness at the table level, if the uniqueness is composed of 2 fields, always use the combine option to create the unique key. On the other hand, if you want 2 fields to be unique independently, add both of them without using combine option.
- You cannot define uniqueness on a multi-valued field.
- Last but not least, uniqueness is implemented at save during manual data entry in data manager. Import manager loads, however, do not enforce the uniqueness definition during the loads. It is when you unload and reload the catalog (for admin reasons) that you get errors.
Verify, Check and Repair:
- Whenever I am ready to load the catalog after modeling changes, I use verifyàcheck option to identify the errors, warnings, etc.
- The unique field related errors that I was describing above pop up now- the good thing is the log/report at the end of check operation lists out, very clearly, which field is violating unique constraint on which table.
- Alter the console configuration to fix the errors, and to be able to load the catalog. (Of course, you need to review the errors to identify data cleansing or redo the spec definitions J)
- The repair option fixes most of the non-fatal errors, and is very useful.
- Set the Modify Once option to yes for the primary key field(s) of every table. This feature will be fully implemented in SP3.
- If a field attempts to further differentiate the primary key of the data but you do not want to add it to key, make that field a multi-valued field.
- A multi-valued field can be only a look up field (look up on flat/qualified flat/hierarchy, etc. or external BLOB look up) or a measurement. Cannot be a plain text or integer or any other data type other than the above two.
Table and Field Deletes:
- You cannot change the data type of a table or a field once created. You need to delete the table/field, and create another one.
- If you want to divest the same look up field from several tables, the easiest way is to delete the look up flat. It cascade deletes the table as well as all the fields in other tables that are backed up by the original table.
- If you delete a look up table that is used as display field and/or unique field in other look up tables, you need to reassign the keys at the table level.
- Required by definition means that it cannot have NULL as one of its values.
- Setting the required option to yes does NOT make sure that field is a required (not null) when data is populated. Currently, we need to write a validation expression on per table per field basis.
- A required field does not always have to be a unique field. A field that is marked as NOT required, however, can never be a unique field in the context of that table.
- Calculated fields are currently possible only on the main table, not on simple look up or qualified look-ups. Also, you can write calculated expressions only on the fields of data types of Boolean, Currency, Integer, Real, and Text.
- Validation expressions are part of data manager programming, not a console configuration.
- You cannot specify length for an integer. Need to write a validation expression to implement the length.
- Text field length enforces the upper limit of the length. If you are concerned about the lower limit of text length, you need to write the validation expression.
- Always choose the translations for True and False values for a Boolean field. If a default value applies, always choose one. I found this useful.
- Multilingual field is a nice way to implement the translations. MDM lets you set up languages by country, with ISO country code indicated in the parenthesis next to the language code (for e.g., ESPANOL[MX]).
- The unique field definitions disappear during the modeling process (defining fields/tables/changing data types)- hit F5; if that does not work, close the console and restart. This happened to me a couple of times.
- When you upgrade MDM with a new service pack, pre-existing repositories are marked Outdated Stopped when mounted. Right click on the repository, and Update.
- As the number of tables in the repository increases, as well as when you have more security roles defined, the time it takes to add or delete a field goes up. Do not close the console thinking that it is hung.