BIAppsArchitecture详解.ppt

* * DAC Background – There are a variety of things to be deployed and managed in a data warehouse DW objects (tables/indices) ETL Code Seed data Variety of configurations for ETL etc This is our tool to administer/install/maintain and monitor ETL runs Also used by ETL administrators in production to monitor and restart jobs Significant TCO and performance improvements since DAC was released. Several customers have improved their ETL run timings several times * The data model is a dimensional model Can load data from multiple sources One of the key methods to conform data from various sources is “code standardization” ie define and convert source specific codes into a normalized warehouse code. Eg Invoice Types etc Supports all 4 major databases and has been tested and optimized for all of them * In this slide, talk about features and benefits of single comprehensive enterprise data model and how it enables “cross-value-chain” analytics Our solution provides that capability by something called “Conformed Dimensions” as we discussed earlier. They are shared by the fact tables in each of the different areas, and enables what we call “cross-value-chain” analytics. For example if you had only a “Sales” analytics system, how would you derive a metric on say “profitability by product” or “profitability by sales area”. It would take significant additional effort to get those answers. It is automatically provided by our solution. This is a key advantage over other vendor solutions on the market that only address a specific functional silo of information. This is very limiting for many of the metrics that will be required. As another differentiator from other solutions, particularly those based on cube architectures, the detailed transaction data is also stored in the data model. It is stored at the lowest level possible. For example, we take “sales quantity” and even match it to “delivery schedule”. Then we match the real deliveries to that schedule. That way