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