数据仓库技术介绍.pptVIP

One school of thought advocates creating detailed physical data models in accordance with traditional entity-relationship (E-R) normalisation techniques, but with some modifications that make the results more suited to warehousing. Advocates of this approach tend to to also promote completing the enterprise data warehouse before any data marts. Another viewpoint is to use dimensional data modelling throughout, creating Star schemas everywhere. The discovery process tends to be different, but a detailed physical data model is created. Because time is often treated as a separate dimension, care needs to be taken that time and history are accurately preserved in the dimensional approach to physical modelling. Observe that the dimensional data model presented here is a logical model. A star schema need not be the physical result. This model nicely fits between the subject model and the more detailed logical data model. Also, it benefits from the dimensional modelling discovery process, without pre-determining the physical data store. The term “schema”, as in star schema, snowflake schema, and starflake schema implies a physical data model. The starflake schema is a combination of the star and snowflake schemas, allowing for flexible use of both the normalised (snowflake) and denormalised (star) versions of the dimension tables. Hybrid OLAP (HOLAP) architectures will combine tables (pre-joined, summary, star or snowflake), views, and multidimensional databases (MDDBs). Both normalised and denormalised physical data models will be examined more closely in later chapters. SAS/Warehouse Administrator software can implement any of these physical models. Normalised data models and snowflake schemas (a somewhat normalised star schema) tend to be difficult for non-SQL experts (and even some experts) to query to get the desired results. They are however, very well suited for updating, validation, handling change, and when used as source data for other models. Denormal