How many of you still use data modelers for projects? Well, there are quite a few companies that still use data modelers. In fact, a good data modeler is hard to come by for most consulting firms.
I would never tell you that I am the BEST data modeler in the world, but I CAN data model. Sometimes when I am helping a client with a data model, I run into lots of issues. My favorite one is when we just throw requirements over the wall to the data modeler and expect him to understand exactly how the model should be designed. I am always thinking, WHAT?
One of my pet peeves is when requirements are gathered, the data modeler is not invited to the requirements gather sessions. This is a huge mistake! Here's why:
1. The data modeler must understand the source of the data coming into the environment to be able to model any type of staging areas.
2. The data modeler must understand the relationships between the business entities to be able to understand how to connect the data properly via foreign key relationships.
3. The data modelers must understand how this data is to be presented to the business user community. Is it a star schema and reporting tool or is it a cube used for sales analysis? This leads us to how the data should be indexed and updated. And YES, we have to design for that, too.
Being the data model is not an easy job. In fact, as part of design, it can be very stressful – so take it easy on those people!
1 Comment
All of the best data modelers are clairvoyant. They know precisely the reasoning behind the incoming data model, and know exactly how (and with what skill level) the end users will be interpreting the data on the outgoing side. All without having either side take the time to sit down and define the requirements.
I'm being sarcastic, but this last statement is very important - if you want data that is modeled appropriately (IMO, there is no 'right' way) for your business, you must take the time to sit with the modeling folks to define the requirements of the model. If you don't, you're leaving it to the modeler's best guess - which in some cases, may not be the best solution for your business.
And by making the modeler do the heavy lifting of reconciling business terms and determining level of granularity by trial and error, you not only make this task 3 times longer than if they had actual requirements, but you introduce a new level of uncertainty to your data that didn't exist before. Working with the modeler to confirm these definitions (which can also double as your data dictionary that, gasp, could be used by everyone in the enterprise) is important to both meeting delivery deadlines and overall data quality.
CH