You’ve decided to learn a new shelf from the NetWeaver fridge and have picked NetWeaver MDM, congratulations! After downloading from the SMP an installation pack and studying the e-learning material you’re eager for getting the hang on it. While your installation is running I want to help you preparing to this, definitely pleasant, playing and quickly remind the basic concepts of NetWeaver MDM 5.5.
The Main table.
There is one and only one main table in the system that stores main objects. It differs from other types of tables in that only the main table may have taxonomy (and families), and qualified lookup tables. No other tables can use the main table as a picklist for a lookup field.
Lookup tables.
These tables store information that the main table and other lookup tables refer to. The only limitation of the lookup tables is they can neither have taxonomy nor refer qualified lookup tables. Besides that they’re very similar to the main table and can be used in the same way. I mean there is no limitations for amount of data or data complexity for lookup tables though lookup tables are expected to have few records relative to the main table, generally by a factor of about 100.
Qualified tables.
This is an interesting animal. It probably deserves to have its own blog. In a few words such tables are comprised of two groups of fields: a group of qualifiers and a group of non-qualifiers. The non qualifiers specify dimensions or levels of details. The qualifiers, in turn, contain qualified data that further specifies each link between a main table record and qualified table record.
A typical example is state-driven prices. We want to store product’s price and we define a field for it (Price) in the main table (storing products) of type Qualified Flat pointing to the Prices table. Now the Prices table has the State field as a non qualifier and the Price as a qualifier. What we did is we put all different prices in the same main table’s field but qualify every price by its state. You may be perplexed now and ask what field and what data belongs to whom? It’s actually simple. Non qualifiers belong solely to the qualified flat table. In our example a list of states is defined in the Prices table. Qualifiers, in turn, belong to the main table or rather qualify the main table’s records. (I definitely will write something about how to deal with these tables and how to gain from them most)
There are special tables, as I said, for families, layout, relationships and different binary data but I won’t cover them here – don’t touch it unless you fully understand the basic concepts.
Attributes vs. Fields
When you design your repository and want to introduce a new parameter you have two options of creating it in the system – either as an attribute or as a field. What is the difference? A field is defined as part of the data model. I.e. every object needs a place to store a value in this field. It’s part of the record and it’s for everyone. As opposite - attributes belong to the taxonomy. They’re not part of the repository model but repository metadata. You manage them not in the Console (as fields) but in the Client (as any other data). So if your attribute is linked to a branch of the taxonomy then every object of that taxonomy branch may have it. And if it’s not linked then there is no place for storing its value for records assigned to that branch. If fields, part of every record, then attributes are only part of subset of the records.
Another difference between fields and attributes is fields may be of any type including lookup (flat or hierarchical) and hence point to another table. Attributes are defined in the client and have a predefined set of parameters associated with them. The last difference is attributes can’t have type ’free text’ but predefined enumeration of values only.
NULL values and Required attribute.
NULL value is not actually a value. It’s a special mark denoting fields with not defined yet values. It treats records with such values as not complete and hence don’t take them into account enforcing rules of uniqueness – a unique field may have many records containing NULL.
For people with the database background the Required term has obvious meaning. It’s a synonym to Mandatory. In NetWeaver MDM Required is an advisory or a flaggy attribute. It doesn’t oblige a user to fill a field but servers as a flag for a special kind of validations. It allows to create a validation rule with a formula ’check that all required fields are not NULL’. If there weren’t Required attribute we would need to create such IS_NULL validation for every field. Such validation operands are not exposed to the expression editor in SP1 yet but are planned for next releases.
Primary keys. Display fields. Uniqueness.
There is no special notion for primary keys in NetWeaver MDM. We have uniqueness tools instead. You may define a field or a set of fields as unique ones. The former is defined on a field-level view and the latest is on a table-level view in the Console. Again, NULL containing records don’t participate in uniqueness enforcements!
Display fields are delegated representatives of a table when it’s linked from another table. If you use a table as a lookup its display fields will be shown when the field’s combo-box is dropped down. All display fields will be shown there separated by a delimiter. It makes sense then to opt such fields that together identify a record uniquely to let a user pick up right records.
Mask vs. Searches
Though the difference is quite easy to grasp it’s worth reminding to one flooded by the new terminology. Saved search saves only search criteria and not results. Results are brought every time dynamically depending on how the data has changed and what the user running the search is permitted to see. As opposite - masks are static lists of selected object and not executed every time. Though even in case of masks permissions for the user retrieving the mask are checked.
Now I’m sure your installation has successfully completed. I promised to remind you fast the basic concepts but it’s too much for a blog and many things yet to mention. I’ll do it in another blog and I’ll spend some SDN space explaining key mapping and agencies, few tricks with the import manager and syndicator and the multilingual functionality. I’m waiting for your feedback as well to cover other next topics in high demand.
