Bak2Basics: The 4 levels of an information model

Posted on 8/16/2006 @ 9:31 AM in #Bak2Basics by | Feedback | 3761 views

Microsoft recently released a CTP for ADO.NET vNext. Before we can dive into the details and practical implications of what the next rev brings to the table, it is important to cover a few basics first.

At the very heart of it, the next release of ADO.NET vNext targets to bridge the gap between the Conceptual Model and the Logical Model. But what are the various models we deal with? Well, they are;

The Physical Model: Data, on a computer lives in bits and bytes. When we are working at the physical model level, we tend to talk in terms of bits and bytes, various file system structures, paging, caching, heaps, indexes, file allocation records etc. When we used to program for mainframes, frequently your business logic would target the physical model directly. This is no longer the case when working with modern day high level languages. It is safe to assume that today we have reached a maturity level where in order to solve a business solution, you do not need to worry about the physical model for the most part.

The Logical Model: This is where today’s applications target their data. This typically is the place where data lives in rows and columns and tables and databases. You define relationships, constraints, you normalize, de normalize data. Usually the RDBMS takes care of the impedance mismatch between the logical model and the physical model, and over the last 20 years RDBMS’s have matured to a level where you need to target the physical model directly in extremely infrequent instances.

The Conceptual Model: This is what your end-client will relate to better. So instead of talking about Employee records, at this level you can talk about a concept called Employee, and a specific employee called SalesPerson, and another called CEO. These are typically referred to as entities. At this level you have various other concepts besides entities introduced, such as Entities, Values, Factories, Aggregates, Repositories, and Services.

Various concepts have been introduced over the years that help you model conceptual models. An example most of us have heard of, is UML. (I am going to reserve my judgment on UML – But I am curious, what are your thoughts on UML?)

The translation between conceptual and logical models is usually labor intensive and problematic. Various processes have been defined by management schools, typically grouped under the umbrella called “Domain Driven Development” (Here’s a good book - http://domaindrivendesign.org/ ). The problem of course is that this process is terribly time consuming, and is almost always deemed to fail because in a real world scenario it is nearly impossible to account for every use case unless you are working in a fixed requirements scenario with years of time at hand. In short, Domain Driven Development is the least worst choice in today’s world.  Some folks will argue that Domain Driven Development is the anti-thesis of SCRUM/Agile. I strongly disagree with that statement. These two are essentially unrelated to each other. If a proper Agile process helps you reduce the cost of change, then the same reduction in cost of change also applies to the domain model. So in that sense they go hand in hand.

But there is still a huge gap between the logical model and the conceptual model. There have been software approaches to bridging this gap earlier – typically in the shape of ORMs. ADO.NET vNext aims to bridge this gap as well, but ADO.NET vNext does not intend to be a sophisticated ORM. I think going forward ADO.NET will become like ASP.NET controls, where the inbuilt controls get you started and give you reusable knowledge, but if you need steroids you need to look at companies like telerik (www.telerik.com) for advanced functionality. Similarly, ADO.NET vNext will help you some, but there will be scope for third parties such as llblgen (www.llblgen.com) and deklarit (www.deklarit.com). And I feel all of these will continue to flourish and advance in a Microsoft ecosystem.

Presentation Model: Once you have your data model represented in concepts, you still need to present it to the actors. The actors can be users or external systems. In order to do so, in a well architected system you would tie your conceptual model with a presentation layer using a typical design pattern such as the MVP (Model View Presenter) or MVC (Model View Controller) design pattern etc. This gives you the utmost flexibility going forward.

… Great!! With these basics behind us, I can now start using these terms left and right and use this blog post as a reference to WTF I’m talking about.

Sound off but keep it civil:

Older comments..