I feel like the essential principles of data modeling are now baked into my thinking. So much so that I find myself using the concepts and terminology in my day-to-day business life as well.
I know, call me weird, but it really has helped me in business and to communicate more clearly. Let me explain with a few points.
- Entities. Entities define business objects, and often have several synonyms. Getting clear definitions can clarify ambiguous roles and responsibilities. For example, we have various types of customers: A few key ones include private onsite customers who arrange training for groups, individual public open-enrollment students needing training for themselves, and licensees/distributors who license courseware from us.
They are all customers to us yet have different needs and we work with each type differently, even having different people assigned to help each type. Minimally we need unique names for each and if we extended that to a data model we’d have a customer supertype and various subtypes. Each customer has things in common with each other type (part of the supertype) and some data and processes unique to their type (the subtypes).
The clarity this brings is to remind us that subtypes might seem separate and distinct, especially with their various names. But there are many functions and data points that unite them and can be leveraged to take advantage of. Examples include marketing, accounting, or customer care to name a few.
- More Subtypes and Supertypes. Speaking of subtypes, we sponsor and exhibit at several events a year. They include everything from local events in one city to regional conferences that attract a wider audience to national ones that pull in international attendees.
These events are more a repeatable process than a project, and we tend to do the exhibit materials planning similarly for each of the three types. To simplify the planning, we organize the event materials and logistics according to the size. For instance, we only ship our large booth to the national events. We bring smaller batches of literature to the smaller shows since we usually only have a table for us to exhibit them.
What occurred to me long ago was that an event is a supertype, with some commonalities between them all. The subtypes are the three types of small to large conferences I mentioned earlier. This has simplified planning for us, especially reducing the amount of decision-making for each one and making them more repeatable.
- Relationships. I read in a sales and marketing book a while back that sales is a 1-1 activity while marketing is 1-Many. Is that not data modeling language? The distinction helps us at Watermark decide which tactics should be sales activities and which would be better done as marketing.
- Relationships redux. It’s helpful to remind anyone doing data modeling that relationships between entities are business rules. For one company’s example, say a Service Technician is assigned to a repair. He or she can only work on one repair at a time. But once we factor in time, a technician might be assigned to 5 or 10 in a day.
A given repair is usually handled by a single tech in most instances. Is it always? When we assign a trainee to shadow an experienced technician, then there are multiples. What starts out as a seemingly simple relationship quite often ends up being a more complex, Many-to-Many one needing an associative entity to resolve them. When setting company policies and business rules, I find it helpful to think about a rule over time and the M-M type of relationship helps guide me.
- Flexibility. Associative entities remind me that every business needs flexibility. Example: today we have one duration and price combination for our self-paced ATLs, but would like the flexibility to offer multiple combinations. Some ATLs might have only one but others may have, 2, 3, or more. I won’t bore you here with how to solve this in a data model. But, the associative entity concept provides guidance that every business needs the flexibility that they provide to account for changes and future expansion.
Now, I don't want to leave you with the impression I go around thinking like a data modeler most of the time. I don’t! But, when a problem arises that has any sort of categorization or complexity of objects, data modeling certainly helps. Post your thoughts about this – I’m curious if anyone else has also found these benefits.