They definitely aren't dead. If you don't do some form of modeling, you will end up with a random assortment of tables or repeating data elements across tables.
Business are changing and perhaps faster than before. This can challenge the data modeling of the company. When you finally feel like you understand some domain with its entities and relations it has changed already and thus the process of managing and updating it becomes larger. It reminds me sort of documentation another disregarded task by a lot of data teams. I am not sure if it makes sense or it comes back to hit like a boomerang.
Hi Joe, I think you have pretty well nailed it wth the last 2 paragraphs - the levels are relevant but only if stakeholders find them valuable.
One time I have found them valuable is when navigating change across multiple SaaS source systems. The source-engineered physical data model has the potential to mislead, the logical model hardly helps so a conceptual model helps to align terms across multiple SaaS systems (oh so rate_plan in X is similar to price_plan in Y but the mapping of many rate_types in X which doesn’t exist in Y is why there is only one concept here not multiple)
Sadly, what you describe is quite normal these days. Table sprawl galore
They definitely aren't dead. If you don't do some form of modeling, you will end up with a random assortment of tables or repeating data elements across tables.
Business are changing and perhaps faster than before. This can challenge the data modeling of the company. When you finally feel like you understand some domain with its entities and relations it has changed already and thus the process of managing and updating it becomes larger. It reminds me sort of documentation another disregarded task by a lot of data teams. I am not sure if it makes sense or it comes back to hit like a boomerang.
Hi Joe, I think you have pretty well nailed it wth the last 2 paragraphs - the levels are relevant but only if stakeholders find them valuable.
One time I have found them valuable is when navigating change across multiple SaaS source systems. The source-engineered physical data model has the potential to mislead, the logical model hardly helps so a conceptual model helps to align terms across multiple SaaS systems (oh so rate_plan in X is similar to price_plan in Y but the mapping of many rate_types in X which doesn’t exist in Y is why there is only one concept here not multiple)
Everyone are talking about open table format as the new standard when it comes to data modeling. Eager to know your view on this Joe...
I don't see open table formats as a new standard or way of data modeling. It's just another place to store and query data.
Thanks for the clarification Joe.