MDS Architecture Notes

While I was creating the recent series of walkthrough posts on I put together a diagram of the major objects that make up an MDS model. I figured it was worth sharing.

The diagram below shows a single MDS instance containing a single model: Product. The aim is to show, at a high level, the relationships and some of the functionality found within an individual model. I’ve provided a brief sentence or two on my understanding of the objects contained in the diagram as a basic primer. Wherever possible I have linked to the online documentation for that particular feature.

MDS (Instance) the container of containers, the Master Data Services application itself.

Models are the primary container for specific groupings of master data. The example architecture diagram shows an MDS instance containing a single model: Product.

Entities are containers created within a model. Entities provide a home for members, and are in many ways analogous to database tables. Product, Color, SubCategory and Category entities exist in the sample diagram.

Members are analogous to the records in a database table (Entity). Members are contained within entities. Each member is made up of two or more attributes.

Attributes are analogous to the columns within a table (Entity). Attributes exist within entities and help describe members (the records within the table). Name and Code attributes are created by default for each entity and serve describe and uniquely identify leaf members. Attributes can be related to other attributes from other entities as seen in the diagram. For example the Color attribute of the Product entity is linked to the members contained in the Color attribute, so too the SubCategory and Category entities are related in the same way. These relationships are analogous to foreign key constraints.

Attribute Groups are explicitly defined collections of particular attributes. Say you may have an entity that is comprised of 50 different attributes; too much information for many of your users. Attribute groups enable the creation of custom sets of hand-picked attributes that are relevant for specific audiences.

Hierarchies organize members into either Derived or Explicit hierarchical structures.

• Derived hierarchies, as the name suggests, are derived by the MDS engine based on the relationships that exist between attributes.
• Explicit hierarchies are created by hand using both leaf and consolidated members. Explicit hierarchies can be further classified as mandatory or non-mandatory.
• Mandatory hierarchies must include all entity leaf members.
• Non-mandatory hierarchies do not require all leaf members be included, although unused members are by default collected in a hierarchy node named “Unused”.

Collections are customized subsets of members contained within hierarchies or other collections. Any entity that has a hierarchy associated with them supports the creation of collections. Shaun Ryan has put together a useful post on creating collections here.

Business Rules can be created and applied against model data to ensure that custom business logic is adhered to. In order to be committed into the system data must pass all business rule validations applied to them. In its current CTP version the business rules UI takes a bit of getting used to, nonetheless there is a lots of good functionality when it comes to information running the gauntlet before it is allowed in. Jeremy Kashel has a good introductory post on business rules here.

Subscription Views are views that can be created by appropriately privileged MDS admins in order to provide an appropriately named view for external systems to subscribe to. It should be noted MDS automatically creates views based on objects created within a model. Subscription views are separate from these and give admins control over the names and content. Shaun Ryan has written a post on the creation of subscription views here.

Versions provide system owners / administrators with the ability to Open, Lock or Commit a particular version of a model and the data contained within it at a particular point in time. As the content within a model varies / grows / shrinks over time versions provide a way of managing metadata so that subscribing systems can access to the correct content.