| In parts 1 & 2 of this article series, we | | | | literature as 'dependent data mart' approach, |
| described the staging area of a data warehouse | | | | given that the data marts depend on the |
| architecture and the presentation area according | | | | 'Enterprise Data warehouse'. According to Inmon, |
| to the Kimball approach. In the present article we | | | | the development of independent data marts |
| shall describe the presentation area of the data | | | | (which are fed directly from operational systems) |
| warehouse, according to the Inmon approach. | | | | creates information silos which are uncoupled, do |
| The Inmon approach (marketed as Corporate | | | | not assure the single version of truth and do not |
| Information Factory) involves the holistic view of | | | | allow the combined information analysis. Moreover, |
| the Enterprise and its informational needs. First | | | | Inmon asserts that the existence of many |
| implementation step, according to this approach, is | | | | independent data marts increases the staging |
| the design of the Enterprise data model, | | | | area complexity (this assertion assumes that |
| supporting all its activities with completeness and | | | | datamarts are unconnected). |
| sufficient detail (('atomic data model'). This is not | | | | The Inmon approach has received criticism |
| any existing database model, but an abstract | | | | focused on the following: |
| model of the information, actually used by the | | | | - The design method of the abstract Enterprise |
| Enterprise. The data model of the so called | | | | 'data model' is not clarified, given that in most |
| 'Enterprise Data warehouse' is designed based on | | | | cases information use is not standardised nor |
| this abstract model. Data are extracted from all | | | | documented. The concept of the Enterprise 'data |
| operational systems and other sources and the | | | | model' is abstract and unclear, therefore it is |
| unique 'Enterprise Data warehouse' is updated | | | | difficult to design such a model which can reflect |
| through an ETL process (as described in Part 1). | | | | successfully the reality for a long term period. The |
| Moreover, implementation of an integrated | | | | argument is further enforced by the fact that the |
| operational database, covering all the Enterprise, is | | | | business environment is rapidly changing in many |
| proposed if operational systems are not | | | | markets. |
| integrated. This is known as an Operational Data | | | | - one-off development of the information model |
| Store (ODS), and has a dual role: | | | | does not follow the general principle for |
| · Serving operational processes | | | | phased-iterative development supported by post |
| · Support operational reporting & | | | | implementation review of each phase. |
| decision making. If an ODS is developed, it | | | | - it is a high risk approach, since it requires high |
| becomes the primary source of the Enterprise | | | | investment in money and time for the design of |
| Datawarehouse. In that way, the implementation | | | | the data model and the development of the |
| of ETL (extraction-transformation-loading) | | | | Enterprise Data warehouse-EDW) which covers all |
| streams from multiple data sources is avoided. | | | | the needs of the Enterprise. This argument is |
| According to the Inmon approach, data marts | | | | countered by suggesting a phased implementation |
| should be 'fed' exclusively from the 'Enterprise | | | | of the EDW, dealing in each phase with one or |
| Data warehouse', in order to assure the single | | | | few enterprise subject areas. |
| version of truth. This approach is known in the | | | | |