It's important when you're making gold-level data tables to make sure that your data model ONLY solves specific questions and not broad swathes of questions. If you don't, your end users will suffer tremendously as they try to figure out how to answer basic questions like "How many sales did we have?" last month. My team screwed up tremendously last year when I asked for "Sales post returns" and received a table that had sales, cancellations, returns, shipping, all of this junk that we didn't need and didn't ask for but had to account for in order to obtain the correct sales number. We ended up building 30 pages of analysis around incorrect data as a result. Instead, deliver super specific tables highly tailored to your customers' specific request in order to keep them happy, keep their analysis accurate, and keep their decision making grounded in reality. #dataengineering #data #datamodeling
a successful implementation leads to waste elimination and continuous improvement
Data Engineering @ Zip
2moThis is why data modeling must be business-process focused, using the correct terminology for a specific purpose. But I think it's good to design tables that answer a wide variety of questions, but they must be limited to a specific business process. Simply just throwing loosely related events/metrics into a table or set of tables just because it saves a few joins only creates confusion and misuse.