If you've been reading my blog over the past year or so you'll have noticed that two things I've started to become really interested in are Master Data Management (MDM) and SQL Server Data Services (SSDS). The interest in SSDS, a cloud-based service in which an organisation can host their data, is a natural progression from my day job of the last few years as a SQL Server developer whilst the interest in MDM stems from a lengthy project engagement where I had responsibility for delivering a lightweight MDM tool.
MDM can loosely be defined as the discipline of centrally managing all the dimensions and the relationships between them that define an enterprise; those dimensions are things like products, customers & suppliers. The use of the word dimensions can lead to the misconception that MDM is wholly a BI discipline but I believe strongly that that is not the case. One facet of MDM that most certainly is true is that enterprises are always changing be it through acquisitions or organic growth and thus an MDM solution must be flexible enough to manage this changing environment. Flexibility though doesn't marry up too well with database management systems that exist today which by their very nature have rigidly defined schemas that are burdensome to change.
I have in the past defined, at a high-level, a possible approach for providing the flexibility required of a MDM solution in my blog entry Service Orientation in Oil and Gas (Part 5) - Attempting to solve the Master Data problem. At its heart is a basic entity-attribute-value (EAV) data model which presents a method for storing undefined (i.e. non-schema-bound/schema-less) "things" although instead of calling them "things" lets give them a more formal term : "entities". As it so happens storing schema-less entities is precisely what SSDS does as explained in the following excerpt from Develop Robust and Scalable Apps with SQL Server Data Services by David Robinson [emphasis is mine]:
An entity can be compared to a row in a table in a relational database. An entity is simply a property bag of name/value pairs. These name/value pairs are grouped into two categories: distinguished system properties and flexible properties.
Distinguished system properties are common to all entities and include ID, Kind, and Version ... Kind is used to categorize similar entities together. There is no schema attached to the entity, so having entities of the same Kind does not guarantee the same structure
David doesn't say that the underlying data model is EAV but I am assuming that it is because how else could they build such a model on top of SQL Server? [N.B. SSDS is built on SQL Server 2005 so the sparse column functionality of SQL Server 2008 is not being used here.]
So to sum up, MDM requires that we can store schema-less entities and storing schema-less entities is exactly what SSDS does. Building my lightweight MDM tool could have been done on SSDS - hopefully I'll get chance to do something similar in the future.
Comments are, as always, highly encouraged.
-Jamie