Yesterday I brought up the topic of logical database modeling. In the discussion, and often considered in comments on the editorial, was this concept that the current trend is not to do modeling at all. There are still some holdouts such as myself, finding models easy to generate and useful for communication.
Unlike the typical ERD, if one is created, or reverse engineered from a database, there is this concept of a logical data model, which provides insight into the schema design based on entities and relationships, without all the heavy lifting of what a physical database may look like. The entities may be a group that is implemented as a single table, or an entity that becomes multiple tables. Columns may not be included, or if they are, then they are usually in generic terms rather than database engine specific data types.
I really appreciate the comments you folks leave, because they help direct my thoughts for aspects I didn’t cover or even think about. From yesterday’s comments I was again reminded that logical models are not only for the eyes of IT resource. They are not so complicated that they can communicate with the business people as well. A logical data model, reviewed with subject matter experts, helps to confirm that you really understand their problem space, and have created a model that can actually be implemented.
When you build an application from a set of screen specifications, and define your domain model and storage schemas based on the screen requirements, you may get your application working more quickly, which is something I have yet to prove to myself. However, there is a cost for that rapid development. For example, you don’t have a database diagram, and probable no a class diagram either. What happens when you come back to that application after a couple of years? You have no place to have an overview of how things are put together…you have to start digging through code to figure out how the thing works.
Additionally, there are other interactions taking place in your system that may or may not come through screens. When that is the case, it’s time to start documenting. Rapid development may say no documentation is needed. But Agile does not exclude documentation by any means. As I understand it, the intention is to not document anything that can be implemented in code that tests the application. A database diagram is a document that can’t be implemented as code, and if meaningful, should be done, even in an Agile world.
What if our modeling software allowed us to maintain a model, integrated with version control, generated migration code for deployment, and generated new ORM aligned with the model? This would be a true maintain in one place solution where you do the work once, and it implements it throughout your entire system. As I know it, ER Studio is the closest to that concept. There are a lot of tools, especially high end CASE tools, that I haven’t used, which may be more in tune with this concept.
Cheers,
Ben