Data Model Patterns

Levels of Data Modeling Considerations - Ways to Speed Up Data Modeling

Data modeling is often seen as a bespoke, cold-start effort. This may be why some people are turned off by data model design. It’s hard work if you’re creating a model from scratch every single time. What if I told you there’s a way to speed up your data modeling efforts drastically? In some cases, you could get most of your data modeling efforts done with minimal effort. And what if you learned this ability has existed for decades? And you can gain this leverage with an investment in a handful of books?

Earlier, we mentioned John Giles’s Data Town Plan. When buildings are designed, many design patterns are borrowed from pre-existing blueprints and architectural designs. Very rarely is something architected completely from scratch. Most businesses and processes are not 100% unique. There are very often commonalities and underlying patterns that can be shared among seemingly different companies, use cases, and systems.

Using our e-commerce example, let’s first look at how you might model entities and their relationships without the use of patterns. It’s not uncommon to find databases with separate tables for Customers, Employees, Vendors, and so on. Each table might have similar columns, such as name, address, email, phone number, etc. You might also have foreign keys pointing all over the place, where Orders have a customer_id or Products have a vendor_id key. This leads to many-to-many duplication where tables have similar data schemas. The schemas are also very rigid. If you want to add a new type, person, or organization, the tendency is to create a new table. This leads to redundant table sprawl. And so it continues. More tables, more problems. Perhaps there’s a way to consolidate these tables into a single data model?

Figure x-y: Consolidating redundant data models into a single model