Typical table constraints

Creating Table-based Object Dependencies Made Easy

By Manfred Böhm and Manfred Münch, SAP AG

Introduction

During the most recent CWG meetings a fairly large group of modeling experts joined the workshops on constraint based modeling. The expert discussions reconfirmed that variant tables provide powerful and flexible means to design a robust product model that is easy to maintain and understand. The meaning of a variant table is part of general knowledge - reading and updating a variant table does not require special modeling skills.

But designing (and illustrating) a complex network of variant tables as well as setting up object dependencies that are based on variant tables still demand sophisticated expertise. Even typical straight forward thinking types of dependencies with single variant tables require the compilation of complex statements. In this article some quite simple but very typical applications of variant tables are listed. All these applications (besides the table itself) require only little information from the modeler.

Since the basic task always is pretty similar the process of creating appropriate object dependencies can be supported by a rather simple dialog.

The support of creating table based constraints is part of potential future improvements on the Product Modeling Environment for Variant Configuration - hence any feedback to this article is very much appreciated.

What is a Variant Table?

A variant table lists combinations of characteristic values (product options) in its rows. Each column represents a certain characteristic, as for example the MOTOR, the VOLTAGE, and the TPYE in the table MOTOR_DETERMINATION (the table MOTOR_DETERMINATION was introduced in "Picking One of Alternative Components via Options" - see CWG Newsletter 5 from March 2004).

Typical table

The highlighting of the first two columns (VOLTAGE and TYPE) indicates that these columns are treated somehow differently than the others (here the single column MOTOR). In the modeling example that introduced this table (see CWG Newsletter 5 from March 2004) the table was used to determine the MOTOR from the VOLTAGE and the TYPE.

In general key (input) and data (output) columns are to be distinguished in variant tables. Data columns can be derived from a table, while key columns can be used as (unique) entry points. Knowing that VOLTAGE and TYPE in combination form a key for this table the value combination {VOLTAGE: "400 V", TYPE: "X12"} allows the determination of the MOTOR - as "MOTOR_07". Since VOLTAGE and TYPE are defined as key, only one table row for the value combination {VOLTAGE: "400 V", TYPE: "X12"} is allowed in the table.

The inversion (to determine a fixed pair of values for VOLTAGE and TYPE from the MOTOR) would not work with the above table; (at least) two pairs of VOLTAGE and TYPE can be used for "MOTOR_07". Hence the MOTOR column alone cannot be a key for this table. In case the combination of VOLTAGE and TYPE would be unique for a given MOTOR, then the MOTOR column could be declared as alternative key for the table (one of the two rows with the value "MOTOR_07" would have to be deleted).

The structure of a variant table is defined by specifying the names and types of the columns (with SAP Variant Configuration this is done by assigning a characteristic to each column). In addition value assignment alternatives (i. e. alternative combinations of key columns) can be declared for a certain variant table.

What are typical applications for a Variant Table?

There are many ways to apply a variant table in the configuration process. For reasons of simplification only applications using the characteristics of a single configurable item are considered here. Furthermore only tables that are based on single value characteristics will be regarded here. In this context the following use cases could be viewed as straight forward applications that do not require special treatment or complex coding:

  • Mutual value filtering: Given values for any characteristic in the table will restrict the values of the other characteristics accordingly - unique values will be adopted. (Only restrictable characteristics will be taken into account - in the normal constraint syntax it is technically possible to also use non-restrictable characteristics as input – not being part of the filtering (domain inferences) but having influence on the effectiveness of the constraint. For reasons of simplification only restrictable characteristics are taken into account.)
  • Determination of a target characteristic (n->1): From a set of n given characteristic values the unique value of 1 special (target) characteristic will be derived (This is what has been done with the table MOTOR_DETERMINATION in "Picking One of Alternative Components via Options" - see CWG Newsletter 5 from March 2004.)
  • Derivations from a guiding characteristic (1-> n): Once the 1 value of a special key characteristic is defined, then a bunch of depending product options (other characteristics) is fixed automatically. (The guiding characteristic is key of the applied variant table.)
  • Checking against inconsistent combinations: If any of the option combinations in the table will occur a configuration conflict is thrown (i. e. the table lists inconsistent combinations).

In order to specify the intention of an according object dependency (that is based on a variant table) the modeler needs to:

  • Pick a configurable product (with a bunch of its options, i. e. characteristics)
  • Decide for one of the "typical table applications" (and maybe highlight one of the characteristics as target or guiding characteristic) as well as to
  • Select a variant table that fits for this purpose

The rest can be done by the system.

What might this mean for a concrete example?

Looking at the "Picking One of Alternative Components via Options" example (from the CWG Newsletter 5) once more again the steps would be as follows (basic assumption is that the product model already includes characteristics and variant tables - at least the structures of the variant tables are defined already):

  1. In your product model select the bunch of product options (characteristics of the configurable product) that you would like to work with: In the model tree of the configurable product SYSTEM_X you could select the assigned class SYSTEM that includes the characteristics VOLATAGE, TYPE and MOTOR.
  2. Invoke a user interface function called "Assign a typical table dependency".
  3. Choose "Determination of a target characteristic" as mode of action for your table dependency.
  4. From the list of characteristics that are assigned to the class SYSTEM select the characteristic MOTOR as target characteristic.
  5. From a list of variant tables that allow deriving the MOTOR from the VOLTAGE and the TYPE you select the table MOTOR_DETERMINATION - which you would like to use for the dependency.
  6. Finally you will define a name (e. g. DETERMINE_MOTOR), a short description and optionally an explanation for the table dependency.

The system would then create the following table constraint and assign it to the product model:

********************************
	* DETERMINE_MOTOR:                                          
	Objects:                                    
	X is_a (300) SYSTEM.                                                           
	Restrictions:                               
	TABLE MOTOR_DETERMINATION               
	( MOTOR   = X.MOTOR,                 
	VOLTAGE = X.VOLTAGE,               
	TYPE    = X.TYPE ).                                                          
	Inferences:                                 
	X.MOTOR.

Of course the set of "typical" table applications in product configuration might be easily extended. Nevertheless for a product that is easy to configure (and easy to model) a set of a few very common application types might be a good guideline for product modelers.

Manfred Münch
Manfred Böhm
SAP AG
e-mail: manfred.boehm@sap.com
e-mail: manfred.muench@sap.com