FrameworkManager分析.ppt

* * * * * Best Practice - 3 This is an iterative process. Depending on how you model, you may need to revisit query subjects to modify them to behave dynamically at run-time or to retrieve different data sets. We will examine Dynamic SQL elsewhere in this course. In our particular data source, COUNTRY_MULTILINGUAL has multiple instances of each country; one for each supported language in the database. We only require English for this particular model, so we will return only the English versions of each country. If we did not handle this situation, it would result in unexpected results where multiple instances of the same country would be returned per country code. * Handling multi-lingual query subjects, for example, can change the nature of the cardinality between the customized query subject and the other query subjects it is related to. In the slide example, COUNTRY and COUNTRY_MULTILINGUAL changed from a one-to-many to a one-to-one because after customizing COUNTRY_MULTILINGUAL only one row will be returned per row in the COUNTRY table based on the filter. * Before the language filter is put in place, the internal cardinality for the multi-part key is 1..1 to 1..n. Each COUNTRY_CODE has multiple languages. Therefore, the nature of the relationship between COUNTRY and COUNTRY_MULTILINGUAL is 1..1 to 1..n. Once the language filter is in place, the internal cardinality of the multi-part key changes to 1..1 to 1..1. This changes the relationship with the COUNTRY query subject * Best Practice - 5 Ensure that a dimension query subject only has 1:1 associated to it and a fact query subject only has 1:n associated to it. This can be accomplished by merging snowflake query subjects together. This will create duplicate keys. Keep the keys from the unique query subjects (1..1) and delete the others. In the slide example, SALES_BRANCH and SALES_STAFF both can be considered ambiguous query subjects. Depending on the query, ReportNet can treat them as either facts or dim