Greg Young pointed out that I inadvertently perpetuated the canonical model stuff when I said the following:
To be clear, one misconception is that we were trying to deliver on the old promise of canonical schemas, when we said one common model we meant a single shape for a given concern in the org (say Customer). Specifically what we mean is a common representation or metamodel through which one can reason about the various concepts. For example, if an ecosystem of services (say Reporting Services, Sync, Analysis Services, Integration Services, Workflow) new how to reason about a common representation for an entity and a relationship then custom apps, packaged apps and database instances that exposed the metadata about their concepts in terms of this metamodel could play in terms of tooling, integration and the basic offerings of these services. The canonical example that we use is the idea of something like MS CRM or SharePoint exposing their metadata as EDM. If they could do so and if there was a mechanism for accessing these stores in terms of the EDM (say an ADO.NET provider like Entity Client) then one could get a reporting, synchronization and ETL experience over these solutions that would be consistent with what one could get over a SQL Server database.
I spaced on that paragraph. What I should have said is a common metamodel (entities and relationships) with which one could describe shapes. An example of a shape that could be described would be a Customer in terms of a Customer Entity. There may be "n" Customer Entity Types defined in a given enterprise ... the shape customer is not the thing that is interesting to be common. The notion of an Entity and the means for reasoning about Entities in a common way is interesting.
Thanks Greg... for pointing this out.
PingBack from http://housesfunnywallpaper.cn/?p=656
I'm still confused about what the "common metamodel" is. Maybe an example is needed. You said in the original post that "the end goal of the Common Data model was to unify data models that were emerging across the company" and went on to list all the products that would be able to use the common data model or metamodel.
So let's say that I have a customer in the domain of my transactional system that can place an order, make payments etc. It has relationships to orders and payments. Now in my reporting model I have a customer that has properties like NumberOfOrdersOver100DollarsInLastMonth and NumberOfLatePayments, but no relationships to individual orders or payments.
What is the common metamodel between these? How is it intended to be used? This is what I'm missing.
Consider the CLR.
In the CLR one can use the reflection API's to reason about any class. There are well known concepts... methods and members and from these you can understand the shape of a type, invoke behavior, dereference values etc.
The common metmamodel to which we refer loosely corresponds to an attempt to do likewise. If I am building services or tooling over a solution that exposes its metadata as an EDM model I can reason about the types, sets, relationships that exist and from their expose my desired functionality.
In the case of Reporting Services this means that I could conceivably look at some store that exposes its mid-tier model as the EDM (say a CRM solution) and which exposes a provider interface that is compliant with out 3.5 contracts. Reporting Services tooling would be able to work on top of this model (even though it is not the tables in the underlying store) and via the Entity Framework would be able to execute reports that went through any mid-tier logic encapsulated in their provider.
This does not mean that one has to define one model for OLTP and Reporting... the CRM solution itself may have different models with different representations of customer, much like a database may have multiple views over a given table... the tools that one uses with which model will be predicated on suitability of the model.
That clears it up. So it's not the model itself that is common, it's the model of the model that is common. :-) I think the term "metamodel" confused me, made me think that there would be one common model that all the distinct models would have to map to. This concerned me because any system large enough to require the use of many separate tools is usually too large to opperate off of a single model. Thanks for the clarification.
Perhaps you should borrow the term "type system" from the CLR. It may not be perfectly accurate, but most .NET programmers will immediately get the reference and the concept you are trying to explain will make a lot more sense.