Usually data models are made to fit a specific purpose of use. As reported in the post A Place in Time this often leads to data quality issues when the data is going to be used for purposes different from the original intended. Among many examples we not at least have heaps of customer tables like this one:
Compared to how the real world works this example has some diversity flaws, like:
- state code as a key to a state table will only work with one country (the United States)
- zipcode is a United States description only opposite to the more generic “Postal Code”
- fname (First name) and lname (Last name) don’t work in cultures where given name and surname have the opposite sequence
- The length of the state, zipcode and most other fields are obviously too small almost anywhere
More seriously we have:
- fname and lname (First name and Last name) and probably also phone should belong to an own party entity acting as a contact related to the company
- company name should belong to an own party entity acting in the role as customer
- address1, address2, city, state, zipcode should belong to an own place entity probably as the current visiting place related to the company
In my experience looking at the real world will help a lot when making data models that can survive for years and stand use cases different from the one in immediate question. I’m not talking about introducing scope creep but just thinking a little bit about how the real world looks like when you are modelling something in that world, which usually is the case when working with Master Data Management (MDM).
Liliendahl on Data Quality 
Hi Liliendahl,
We generally have the concept of “best practices”, which recommends to go outside the main purpose of building data models based on JUST business requirements. We usually think how to generalize the model to accommodate futuristic requirements. My point is, the real world alignment has been there under the name of best practices. Isn’t it ?
Warm regards,
Kadhir
Hi Henrik
You are quite right that a good logical model would show each of the entities represented in the table example as three separate entities with appropriate relationships.
However, it can, in certain circumstance, be acceptable to have a table in a format similar to what you show. De-normalising data structures (and this table is de-normalised) when designing databases is acceptable if it is required in order to achieve some stated business response. However, the de-normalisation decisions must be fully justified and documented. The Logical Data Model should alway remain fully normalised.
@Kadhir. There is no such thing a ‘JUST business requirements’. The only purpose for building data models is to support business requirements. Without them an enterprise would be unable to build the databases it requires to perform effectively. Best practice is always to build a fully normalised data model that fully supports the business requirements of the enterprise. Anything else is simply shoddy practice.
A good subject, Henrik.
Kind regards
John
Hi John,
Thanks for your comment. What I meant by ‘Just Business Requirements’ is, documented business requirements. Often it comes from single business department, which fails to take into account from enterprise perspective. We really do not want to redo / revisit the models by fulfilling one section of requirements.
@Kadhir
You are right, the functional and data requirements of a single project would definitely only represent a small part of the overall enterprise requirements. However, in any enterprise with a good information architecture, these requirements would a) already be covered by the existing enterprise function and data models or b) would add to them.
What data analysts must not do is simply ‘make things up’. If the DA does not know what Business Functions the data is meant to support, then anything that they do will be merely guessing. So, stage one in any project is to clearly identify the Business Functions. Once these are known, the data entities, attributes and relationships needed to support them can then be determined, modelled and added to the existing enterprise model.
Kind regards
John
in my experience building a model to support a specific business requirement is the sure recipe for falling short of your target. Business will ask for some information that may lead you to overlook some fields or other details that will be asked for the first time a business user sees the first report coming out of the system.
One of the purposes of BI is generating new questions, so it is better being prepared to answer them.
A good data model is a model that covers an entire process, encompassing all the available data and making them ready to be consumed when necessary.
@John Owens – I think Kadhir’s point (if I may) was aimed at the idea that there needs to be a deeper or broader or more universal modelling consideration than JUST the business requirements, and from the sound of it, you agree. The shoreline is a fine navigational aid but if you want to sail in bigger, more integrated waters you should consider adding a reference to a North (or South) Star.
Thanks, John. You got me right on this. One of the steps in designing data model, before delivering to final approval is to take a step back and/or get an aerial view of the requirements and proposed model and see what direction the business is getting to, what are the futuristic things that may/will have an impact on this. For example, the enterprise moves towards global presence, we should look for what other attributes (real world alignment) we can think of adding on the proposed model.
I agree with you. Good conversation.
@Gus
What you are saying is that data analysts should a) just guess at what data is needed by the enterprise or b) have such super intelligence that they just ‘know’. What your words are saying is that the ‘business’ does not know what it wants and that data analysts are somehow wiser, cleverer and know better. This is the type of thinking that has led to data analysts failing to deliver value to the enterprises for nearly three decades now.
There is a model that defines absolutely every single item of data that is needed by the any enterprise of any size in any sector and that model is the Business Function Model. This is the starting point for every competent data analyst. Without it analysts are simply stumbling in the dark – even though they might be spouting clever cliches.
The fact is that, if nobody has first built a properly structured, fully normalised data model that fully supports all of the data needs of the enterprise, then no amount of data mining or BI will provide any meaningful insights. As the saying goes, “You cannot make a silk purse out of a sow’s ear” or, if you prefer, you cannot be clever with stupid data. And, if you have not started with the Business Function Model, you will definitely have stupid data.
Kind regards
John
@John Owens:
Yes, it is a fact of life that often “business” does NOT “know” what “it” “wants”.
Who is “business”? A few employees who happened to be assigned to the project that the data analyst is working on.
What does “know” refer to, therefore? To how much these few know about the *entire* business. What if it is a global business ? Answer: these few do NOT know everything, therefore “the business” never knows enough.
Who is “it”? The entire set of organizational units and employees of the business, plus its partners and, most importantly, the entire set of customers. Does the data analyst have the possibility to interact with all? No.
Finally, we all ‘know’ from our own experience that what we want and what we need may be distinct (of course overlapping) sets. Same with businesses. What a “business” “says” it “wants” is not necessarily what it “needs” in its actual operations.
You said:
“There is a model that defines absolutely every single item of data that is needed by the any enterprise of any size in any sector and that model is the Business Function Model.”
An URL to at least a description of this model would be helpful, please.
I’m sure we’d all love to learn: how was this “Business Function Model” created for ALL enterprises in the WHOLE world, in ALL sectors, by whom, how long did it take to create it, who owns it now etc. etc.
@Data Obession
Your assertion that the “business does not know know what it wants”, sadly, smacks of an arrogance and disrespect for the business that I had hoped had disappeared from the analysis profession.
In all projects it is the business members that bring the business expertise and the analysts that (should) bring the analysis expertise. When analysts start to see themselves as the experts in business (and, everything else), then the game is lost. Remember, it is the “stupid” business that runs the enterprise that generates all of the revenue to pay the “clever” analysts to do their job. With IT and data analysts’ sad record in delivering any real business benefits to enterprises over the past three decades (in many instances making things worse), it is amazing that they should hold themselves in such high esteem.
Every enterprise ought to have a Business Function Model that unambiguously describes everything that it ought to be doing. From this model data analysts can derive all data entities, attributes and relationships required by the enterprise and build the Logical Data Model. You can see an introductory example of a Business Function Model at http://integrated-modeling-method.com/imm-bpm-business-process-modeling-method/business-function-modeling/
When dealing with analysts who “knew everything”, a great mentor of mine used say to them, “You should be very careful about labelling the business as ‘stupid’, as, like it or not, you always know less about the business than the business does, so what does that make you?”
Kind regards
John
Thanks guys for this very interesting exchange of opinions based on my original observation.
The question about the role of “the business” is ever recurring. Personally I don’t like the term “the business”. In my eyes everyone in an organization is part of “the business” and when you work as an outsider you should act as if you are part of the organization. Sometimes when working formally as a supplier to an organization it happens that I seem to have a broader view of the data landscape than subject matter experts, who of course have much deeper insights into a given function and the desired business outcome.
And believe me, I have been part of making data models that doesn’t reflect the perfect world but are suitable for the scope of the project at hand.