{"id":1051,"date":"2015-07-28T10:30:08","date_gmt":"2015-07-28T09:30:08","guid":{"rendered":"http:\/\/dotnetsql.info\/net-sql\/?p=1051"},"modified":"2015-07-31T16:16:18","modified_gmt":"2015-07-31T15:16:18","slug":"one-assumption-that-could-crash-your-credit-risk-dw-project","status":"publish","type":"post","link":"http:\/\/dotnetsql.info\/net-sql\/index.php\/one-assumption-that-could-crash-your-credit-risk-dw-project\/","title":{"rendered":"First assumption that could CRASH your Credit Risk Data Warehouse project"},"content":{"rendered":"

Over the past two weeks I’ve covered a summary\u00a0for the implementation of a Credit Risk Reporting project which is available in two parts,\u00a0How to Implement a Credit Risk Data Warehouse – Part 1<\/a>\u00a0and\u00a0How to Implement a Credit Risk Data Warehouse – Part 2<\/a>\u00a0holding the\u00a0overview of the implications and a structured best practices approach to be considered when enrolling on the delivery of such a project.<\/p>\n

Today\u00a0I will focus on a\u00a0common preconception that could have a severe impact to the schedule, resources, cost, development and ultimately the delivery of your Credit Risk Data Warehouse & Reporting project.<\/p>\n

The preconception that I want to cover is “the data mart is a actually a quick and dirty data warehouse” and that\u00a0you can bring it up without going to the trouble of developing an overall architectural plan for the enterprise.Also in the same reasoning it is considered that it’s to \u00a0complex to develop an overall architecture, and actually impossible to\u00a0have the perspective to try that now.<\/p>\n

First of all the data mart should NEVER<\/strong>\u00a0be a quick and dirty data warehouse rather, it should be a single subject area implemented within the framework of an overall plan.<\/p>\n

A data mart can be loaded with data extracted directly from legacy sources. A data mart does not have to be downloaded formally from a larger centralized enterprise data warehouse.<\/p>\n

The key to a successful data mart strategy is quite simple. For any two data marts in an enterprise, the common dimensions must be conformed.<\/p>\n

Dimensions are conformed when they are the same or one is a strict rollup of another. For example in an Investment Bank, if the cash in-flows\u00a0is one data mart and the cash out-flows\u00a0is another data mart, the two data marts will form a coherent part of an overall enterprise data warehouse if their common dimensions (time, instrument, source system) conform.<\/p>\n

The “cash-in”s & “cash-out”‘s time dimensions might both be at the individual day level. Or perhaps the “cash-out”\u00a0time dimension is at the day level but the “cash-in”\u00a0time dimension is at the week level.<\/p>\n

Because days roll up to weeks, the two time dimensions are conformed. The time dimensions would not be conformed if the “cash-out”\u00a0time dimension was weeks and the “cash-in”\u00a0time dimension was months \u2013 weeks don\u2019 t roll up into months \u2013 and the two data marts could not usefully coexist in the same application.<\/p>\n

The beauty of conformed dimensions is that the two data marts don\u2019 t have to be on the same machine and don\u2019 t need to be created at the same time. Once both data marts are running, an over-arching application can request data simultaneously from both (in separate queries) and the answer set is likely to make sense.<\/p>\n

Logically, the only valid \u201crow headers\u201d in a joint report must come from common dimensions such as time and instrument\u00a0in our example but we have guaranteed that at least some of the row headers from these two data marts will be in common because the dimensions are conformed. Any of these common row headers can produce a valid report.<\/p>\n

The idea of developing an overall data warehouse architecture is daunting, but the key step in that architecture plan is simple:<\/p>\n