Developing with specs

There are two ways to extend the data model. One is the traditional method of persisting hardened attributes to the database, and the other is by using specs to persist soft attributes to the database as XML.

In InfoSphere® MDM, the soft attribute extension method employs InfoSphere MDM specs as a type of metadata to define extensions to class entities within the InfoSphere MDM data model. Specs are attached to product types and can be cascaded down to product subtypes. Specs provide you with a unique flexibility to extend class entities in the data model without the need to alter the physical definition of the database schema.

Important: The term specs in this context is not a shortened version of the word specifications.

The heart of a spec is a set of XML schemas. There are three types of XML schemas for specs: internal, external, and localized. Spec schemas are XSD files that you design according to your business needs. Once you have designed your product model and defined the entity type hierarchy, you can use specs to define and extend the attributes for each of the subtypes within that hierarchy. You can model and propagate changes to the logical data model without the need to revise or rewrite the physical data model.

Specs are supported for the following domains in the following ways:

in the product domain, the product entity inherits its type from the product type. A product, therefore, inherits the specs from its type and provides values in the form of XML.
in the party domain, the party demographic inherits its type from the party demographic type as defined in the party demographics type code table. A party demographic, therefore, inherits the specs from the party type code table and provides values in the form of XML.
in the account domain, the contract entity inherits its type from the agreement type as defined in the agreement type code table. A contract entity, therefore, inherits the specs from the agreement type code table and provides values in the form of XML.

An implementation of specs includes the following:

the appropriate XSD schemas, to define the structure of data you intend to use to extend a class entity
an XML document adhering to the structure laid out in the XSD provides the data, the spec values or dynamic attributes, that are used to extend the class entity
a spec value business object, or a business object with an underlying class entity that supports specs that is associated to the XML document

You can use the following table to help you to determine when to use specs:

Table 1. Determining when to use specs
Consideration	Yes	No	Comments
Can consumers of the data tolerate XML?	use specs	extend the database table	If the consumer of the data cannot tolerate XML, you may choose to use a pluggable parser layer in InfoSphere MDM to convert non-XML data both from and back to the consumer in a format that is compatible (for example, .csv).
Do the extensions have a complex structure?	use specs	extend the database table	Specs give you the flexibility to describe complex structures using the inherent ability to describe nested XML, something you cannot do with traditional database tables.
Are there constraints on the extensions?	use specs	extend the database table	Specs are recommended because the XSD has the ability to describe constraints. However, if there are constraints on the extensions, but you cannot use specs, you may be able to use external validations to achieve the same functionality of validating your constraints.
Might the extensions evolve over time?	use specs	extend the database table	Specs are recommended because you can use spec formats (versions) to make changes to update the XSD.
Will product data be in multiple languages?	use specs	extend the database table	Specs are recommended because you can use include locale-sensitive information and support for translation of the schema itself as well as the schema’s XML output.
Should other structures/features be used?		extend the database table	If you need to put a foreign key constraint between an extended attribute and another table, a traditional extension approach is more appropriate.