Community Comment: Part 36 - Data modelers need to understand patterns
- Data modelers need to understand patterns
- Like programming, don't reinvent the wheel
- Universal patterns & metapatterns exist
- Remember "The Data Model Resource Book"
The comments I provided in reaction to a community discussion thread.
Vice President at Data Modeling Training Firm:
I am always wondering why people like to use an #universal #datamodel. Is there someone who can tell me what this model is all about or even for what industry this model is?
Gfesser:
[Vice President at Data Modeling Training Firm] this data model doesn't concern a specific industry / domain. This model is about combining several universal patterns: a metapattern, so-to-speak, that combines party, event, document, and location. This metapattern can be used to drive design sessions, and many data models can be derived from this simple metapattern. Let's face it, most data models consist of tracked events, which are performed by parties at given locations, and these events can leave audit trails / documents. I've designed a lot of databases in the past by using the ideas provided by the multi-volume series "The Data Model Resource Book" as a starting point, and volume 3 is all about universal patterns.
Vice President at Data Modeling Training Firm:
I like design sessions, especially if done with business people, but I am not sure if metapatterns work there. And I agree if you abstract enough you can see parties involved in Events/Arrangments at locations etc. but does this stick?
Gfesser:
[Vice President at Data Modeling Training Firm] I wasn't specifically referring to design sessions with business folks, because design often happens in phases. Yes, patterns such as this typically stick, keeping in mind that terms such as "party" can be used loosely just like "user": a user, for example, can refer to a system even though many might be inclined to assume that this refers to a human.
Vice President at Data Modeling Training Firm:
Ah the datamodel for tech not business. A reason to have this post
Gfesser:
I don't really differentiate between "tech" and "business" for this type of discussion. Instead, I differentiate between those who are adept modelers, and those who aren't. I've taken a look at a lot of models used by packaged products over the years, and some over-implement patterns by shoehorning what doesn't really belong into a given table, making analysis more complicated than it needs to be. Of course, the vendors behind these products arguably want individuals such as you and I to depend on them for support, so for them this may be a moot problem. But complicated, problematic models tend to rear their ugly heads when it comes time to consume this data for analytics.