Minimal Modeling: processes and deliverables

Back in October 2023, I was outside, walking my cat Khatchapuri, when suddenly it all clicked, and I frantically drew the diagram of Minimal Modeling just as it has appeared before my mind’s eye.  Arrows are processes, rectangles are artifacts.

Arrow #1: textual description → logical model

Arrow #1 is how we build the logical model of the system, based on its textual description and our understanding.  This is basically the first half of the "Database Design" book.  This process is pretty straightforward, explained in detail in less than 100 pages. We use formalized sentences to validate schema design: if they make sense then the schema is correct.  This happens in mental space, so fixing mistakes is easy.  Changing and extending the logical model is an integral part of the entire process.

For novices in database design, starting with a logical model based on this approach should remove a lot of uncertainty and doubt.

Arrow #2: logical model → physical table schema

Arrow #2 is how we would design the physical tables given the logical model.  This is basically the second half of the "Database Design" book.

Note that the logical model exists even if it’s not defined explicitly; it’s just harder to work with.

There are many competing design concerns in physical space, so several different table designs are possible.  You must make a choice, and this is called "Game of Tables".

As the business grows and changes, your logical schema changes too.  You need to migrate the physical schema accordingly.  This is sometimes easy, sometimes harder (but always possible). Logical model helps with introducing such changes: you can validate them cheaply, using structured sentences.

The role of Minimal Modeling here is to structure the exploration of the design space. We do not prescribe any specific approaches to table design, you can use whatever suits your environment.  However, in the book, for teaching purposes we focus on one strategy, based on the third normal form.

One additional benefit observed in practice is that you can build secondary representations much faster.  Logical modeling helps a lot with designing the BI layer, data marts, data cleaning, data audits and more.

Arrow #3: physical table schema → logical model

Arrow #3 is about extracting the logical model from a given database.

Typically, the physical design of a real-world database has grown organically across the years.  Logical model is still there, but muddled by the physical table design concerns.

This may be the most interesting part for the practitioners. Minimal modeling process is designed to be lightweight, incremental and collaborative.  It can bring immediate results: onboarding time is significantly shorter, the data lineage becomes clear, business stakeholder communication improves.

You don't need to do anything with the underlying database: no refactoring or migration is ever needed.  Old-growth databases are perfect targets for Minimal Modeling.

I’m going to talk about this in the “Incremental documentation for your database” talk in a month: https://minimalmodeling.substack.com/p/talk-incremental-documentation-for.

Arrow #4: logical model → texts and diagrams

Arrow #4 refers to writing the actual documentation based on the minimal model.  We call it "narratives", and they include both texts and diagrams.  The key here is that the structured logical model and the narratives are clearly separated.  We believe that this separation removes a lot of friction from the documentation process.

Writing narratives is not necessary: a lot of value is already extracted on the previous step.

Deliverables

Let’s quickly go over the three deliverables.

Our approach removes a lot of uncertainty and doubt about what goes into documentation, and where. 

You can create as many different narratives as needed: for new employee onboarding, for project onboarding, for a specific topic (say, “how payments work”), etc.  A logical model would be a common structured foundation for all of them, separate from the free-form texts.

We heavily focus on the logical model (the catalog of anchors, attributes and links).  With our approach, the logical model is incremental and lightweight.  We never ask you to “document everything”.  Logical model is collaborative by design but you can also simply keep your personal notes about the database in the form of a logical model, and never tell anyone.

We never ask you to change the physical database. It is what it is. However, the minimal model can provide guidance on the database model migration when changes are required.

If anything here sounds promising, drop me an email, I’d be happy to see if I could help.