To continue reading for free, register below or login
To read more you must become a member of SearchDataManagement.com
Well, I guess it all depends on how you define data mart, doesn't it? Let's start with one popular definition of a data mart as a smaller-scale data warehouse (not my favorite definition). The benefit of a data mart is that it can be implemented more quickly and can deliver quick payback, so the initial ROI of this "type" of data mart can be compelling. The problem is that it is almost like replicating the stove-pipe architecture that causes us all those problems in our operational systems. So you wind up with multiple departmental data marts with no integration or sharing between them. And what if multiple data marts use the same data (e.g.. customer or sales) but different sources or with different latency? One data mart gives one answer and the other gives another. So you've caused problem – at least when viewed at the macro level.
Another definition of data mart is a departmental spin-off from the data warehouse or ODS. This can help to rectify the stove-pipe problem while giving the benefits discussed above. So it is not really an issue of whether you "need a data mart" as much as it is an issue of ensuring the reliability and accuracy of the source for your analytical data, whether it be in departmental data marts, or a central data warehouse.
Of course, there are multiple additional issues we could discuss, but a Q&A forum such as this is not necessarily the place to discuss issues in extreme depth. I would suggest that you read up on data marts and here are some interesting links for doing so:
And even if you do read all of this it still can be confusing. Good luck.
|
