Conceptualize or die

Not long ago I have a big argument while approving the requirement for a not existent software platform: is it enough to make ER for logical data models and why do we ever need to conceptualize what we think we understand clearly? That question makes me feel very uncomfortable, if I’m wrong, what if some models are small and clear enough to design them “ad hoc”?

The short answer I give to myself is “no, it is not ”. Let imaging we have simple entities and relation. Let’s talk about Company and Worker (forestall I ask my workmate to draw ERD for a company and worker entities, and he draw many-to-many relation between “Employer” and “Worker” and it is indicatively). What I see at first glance:

Fig. 1: First look at Company-Worker relation

Ok, at first sight, we have one (and only one) to the one-to-many relationship between Company and Worker so one and only one Company can be in a relationship with one or more Workers. It looks very simple and complete, so we should go and create some tables… or not?

Let’s put that picture into the perspective of the model user, what do you see here? It is two tables without context telling us only technical information. The user can not get formalized context of what is going on here. Even if we name relation, we cannot cover every case that is critical for business and should be marked. We should get back and draw or write down some concepts. Let’s make a conceptual class model instead:

Fig. 2: Conceptual class model (CCM) for Company and Worker

What point represents ERD in figure one? We can see, representation of paySalaryTo cardinality (it is one to many) but what about a Worker who is not currently working for a Company? That’s where have uncertainty. For one business (for example recruit agency), it is ok to have workers in job search, they do not have companies now and our ERD is right for implement, we have a non-identifying relationship. But here on CCM we design entities that connected mandatory one-to-one, and our ERD is wrong, it should be identifying relationship where companyID foreign key should become part of workerID, so companyID cannot be Null.

Fig.3: Second look at Company-Worker relation

And there is more. Look at figure 2, you will see Agent class: Company and Worker is the subclass of that abstraction. Why do we mention it and why it is important? That’s the reason why you need to use conceptual modeling to implement business rules to specify your data architecture.

Abstraction adds a context to make the right decisions through your architecture process. Do you ever want to resolve a 1:n relationship? I think a lot of DBA will say “no, why you ever need this?”, and I say “maybe, show me a business task”.

Look at our example, what if you want to check if there is a collision where the worker works for one company, but his job is paid by another company? It is not the optimal way to check if somewhere in the Payment table destination Worker has an ID which is corresponding with the payment source ID in the Worker table. Or do you need to design a membership relation which is not monetary (for example add Crew class in your CCM)?

Here you go with mutual approval with business users of your conceptual models. They help you and other people understand concepts, processes, and goals, why you ever need to implement something. If data modeling is a process of delivering a data requirement to DBA, conceptual modeling is the process of understanding and approval that your vision of implementation is correct.

Let’s add a new entity — Membership. It can help us to rule over collisions in business processes. Like we mentioned before — you may check if the worker you pay is a member of a company just by looping through the Membership table.

Fig.4: New entity in ERD

Notice, that it is not “resolving” like many to many relationships because you have no private key violations in figure 3, it is about resolving business entities, making ER model complete, and meeting business requirements.

The point of this short article is about data management and business, which should determine realization, not other ways. You may have great business processes, good conception, and business strategy and goals, but to meet business requirements in your data models, you should translate it from business not directly, but through conceptual modeling and mutual approval. It should give you the ontology defining a basic set of classes and properties as a common vocabulary to describe business objects to making reasonable decisions in your models and data architecture.

Take your time, be sure to approve your vision with all stakeholders and fix it in a conceptual model. Remember, your implementation does not exist in a vacuum but serves business goals.