How Data Modeling Has Helped Me in Business. No, Really!

I’ve been working with and doing data modeling training for many years, more than I want to recount. I feel like the essential principles of data modeling are now baked into my thinking. I haven’t done much data modeling training lately, but I do find myself using the concepts and terminology in my day-to-day business life.

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.

1. 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.

2. 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 event planning similarly for each of the three event types. To simplify the planning, we organize the events 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.

3. Relationships. I read in a sales and marketing book a while back that sales are a one-to-one activity while marketing is one-to-many. Is that not data modeling language? The distinction helps us decide which tactics should be sales activities and which would be better done as marketing.

4. 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 (M-M) one needing an associative entity to resolve them. When setting company policies and business rules, I find it helpful to think about a given rule over time and the M-M type of relationship helps guide me.

5. Flexibility. Associative entities remind me that every business needs flexibility. Example: today we have one duration and price combination for our self-paced Anytime Learning (ATL), but would like the flexibility to offer multiple combinations. Some ATLs might have only one but others may have, 2, 3, or more. The easy solution for us was to create an associative table in the database to hold the combinations of duration and price. Again, the associative entity concept provided guidance for us to create the necessary flexibility that every business needs to account for changes and future expansion.

Don’t get the impression I go around thinking like a data modeling bot 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 me. Post your thoughts about this – I’m curious if anyone else has also found these benefits.