Dimensional modeling: Difference between revisions

Content deleted Content added
m References: fixed incorrect references formatting—commented out disused list reference—you can help!
m Fixed a reference. Please see Category:CS1 errors: unsupported parameter.
Line 4:
{{How-to|date=April 2025}}}}
{{Use dmy dates|date=July 2018}}
'''Dimensional modeling''' ('''DM''') is part of the ''[[The Kimball Lifecycle|Business Dimensional Lifecycle]]'' methodology developed by [[Ralph Kimball]] which includes a set of methods, techniques and concepts for use in [[data warehouse]] design.<ref name="ConBegg9"/>{{rp|1258–1260}}<ref name="MoodyKokink-1">{{cite web|url=http://neumann.hec.ca/sites/cours/6-060-00/MK_entreprise.pdf|title=From Enterprise Models to Dimensional Models: A Methodology for Data Warehouse and Data Mart Design|id=Dimensional Modelling|access-date=3 July 2018|first1=Daniel L.|last1=Moody|first2=Mark A.R.|last2=Kortink|url-status=live|archive-url=https://web.archive.org/web/20170517164505/http://neumann.hec.ca/sites/cours/6-060-00/MK_entreprise.pdf|archive-date=17 May 2017|df=dmy-all}}</ref> The approach focuses on identifying the key [[business process]]es within a business and modelling and implementing these first before adding additional business processes, as a [[Top-down and bottom-up design|bottom-up approach]].<ref name="ConBegg9"/>{{rp|1258–1260}} An alternative approach from [[Bill Inmon|Inmon]] advocates a top down design of the model of all the enterprise data using tools such as [[entity-relationship model]]ing (ER).<ref name="ConBegg9">{{cite book|title=Database Systems - A Practical Approach to Design, Implementation and Management|first1=Thomas|last1=Connolly|first2=Carolyn|last2=Begg|publisher=Pearson|isbn=978-1-292-06118-4|edition=6th|at=Part 9 Business Intelligence|date=26 September 2014|df=dmy-all}}</ref>{{rp|1258–1260}}
 
==Description==
Line 58:
* '''Understandability and simplicity.''' Dimensional models organize data by business processes and shared business terms (dimensions), which makes schemas easier for analysts to navigate than highly normalized designs.<ref name="kimball2013" />
 
* '''Query performance for analytic workloads.''' Star-schema queries typically join a large fact table to a few small dimensions; many systems implement star-join optimizations, and benchmarks specifically evaluate this workload (e.g., the Star Schema Benchmark).<ref name="kimball2013" /><ref name="ssb2009">{{cite conference |last1=O'Neil |first1=Patrick |last2=O'Neil |first2=Elizabeth |last3=Chen |first3=Xuedong |last4=Revilak |first4=Stephen |title=The Star Schema Benchmark and Augmented Fact Table Indexing |booktitlebook-title=Performance Evaluation and Benchmarking (TPCTC 2009) |year=2009 |publisher=Springer |doi=10.1007/978-3-642-10424-4_17 |url=https://link.springer.com/chapter/10.1007/978-3-642-10424-4_17}}</ref>
 
* '''Extensibility (resilience to change).''' New facts or dimensions can be added without breaking existing queries so long as the fact-table grain is preserved; this allows incremental evolution of the warehouse.<ref name="kimball2013" />