Your SlideShare is downloading. ×
Agreggates ii
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Agreggates ii

454
views

Published on

Published in: Technology, Business

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
454
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
6
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Designing AggregatesIng. Julio Ernesto Carreño Vargas
  • 2. Designing Aggregates Once you have chosen dimensional aggregates, they must be designed and documented. This is the point of greatest risk for aggregate implementation. 2
  • 3. Definig The Base Schema3
  • 4. The Base Schema Declaration of grain is an essential part of schema design. Proper definition of grain not only enables the future identification of aggregates, it is crucial to the success of the base schema itself. 4
  • 5. Rollup dimensions Conforming rollup dimensions and their natural keys 5
  • 6. Rollup dimensions Rollup dimensions should be sourced from the base dimensions, and their attributes must follow the same rules for slow change processing. 6
  • 7. Hierarchies Documenting dimensional hierarchies may be important for business intelligence software and database features such as materialized views and materialized query tables. The hierarchies identify potential aggregation points and can aid in estimating degree of summarization. 7
  • 8. Housekeeping Columns they are present for a purely technical reason 8
  • 9. Design Principles for the Aggregate Schema9
  • 10. A Separate Star for Each Aggregation Dimensional aggregates should be stored in separate tables for each aggregation. 10
  • 11. A Separate Star for Each Aggregation Do not store different levels of aggregation in the same schema. The schema will be capable of providing wrong results. 11
  • 12. Aggregate facts Aggregate facts should be stored in separate tables for each level of aggregation. These may be separate aggregate fact tables or separate prejoined aggregate tables 12
  • 13. Naming Conventions Facts and dimensional attributes should receive the same name in anaggregate schema as they do in the base schema. The name of an aggregate dimension table should describe the contents of its rows. The names of aggregate fact tables are always problematic. The best you can do is establish a convention and stick to it. 13
  • 14. Aggregate Dimension Design Attributes of the aggregate dimension must be identical to those in the base dimension in name and data type. Slow change processing rules must be identical. The natural key of an aggregate dimension will be different from the base dimension. Source aggregate dimensions from the base dimension, rather than the original source system. This eliminates redundant processing, and ensures uniform presentation of data values. 14
  • 15. Aggregate Dimension Design Aggregate dimension tables are often shared by multiple aggregates, and sometimes used by base fact tables. These shared dimension tables do not need to be built redundantly; the various fact tables can use the same dimension table. If the shared table is to be instantiated more than once, build it a single time and then replicate it.  The documentation for a shared dimension must enumerate all dependent fact tables, whether part of the base schema or aggregates. In some cases, frequent updates to a dimension may require updates to fact tables outside their normal load windows. 15
  • 16. Aggregate Fact Table Design Aggregate Facts: Names and Data Types  The aggregate fact should have the same business definition and column name as the base fact  Unlike dimensional attributes, the aggregate fact may have a different data type than its counterpart in the base schema No New Facts, Including Counts  Counts cannot be accurately performed against aggregate schemas, even if all attributes are the same. All counts must be performed against the base schema.  As a general rule of thumb, the only count to be added to an aggregate should show the number of base rows summarized. If this fact is added to the aggregate, it should also appear in the base fact table with a constant value of 1. Counts of any other attribute should be directed to the base schema only. 16
  • 17. Aggregate Fact Table Design Audit Dimension:  The audit record associated with a row in the aggregate fact table does not summarize the audit data associated with the base fact table. It describes the process by which the aggregate row was inserted or updated. Sourcing Aggregate Fact Tables  Facts will be sourced from the base fact table and aggregated by the load process as appropriate. 17
  • 18. Documenting the Aggregate Schema18
  • 19. Documenting the Aggregate Schema Identify Schema Families Identify Dimensional Conformance 19
  • 20. Documenting the Aggregate Schema Documenting Aggregate Dimension Tables Documenting Aggregate Fact Tables 20
  • 21. Bibliografía Mastering Data Warehouse Aggregates.Solutions for Star Schema Performance. Christopher Adamson. 21

×