Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p><strong>Short answer:</strong></p> <p>If your lookups / retrievals from your OLTP tables are <em>fast enough</em>, and your specific search requirements do <em>not</em> have such complications as are described below, then there should not be a need to get into any dimensional star-schemas.</p> <p><strong>Long answer:</strong></p> <p>Dimensional and Denormalized models have different purposes. Dimensional models are generally used for data warehousing scenarios, and are particularly useful where super-fast query results are required for computed numbers such as "quarterly sales by region" or "by salesperson". Data is stored in the Dimensional model after pre-calculating these numbers, and updated as per some fixed schedule.</p> <p>But even without a data warehouse involved, a Dimensional model could be useful, and its purpose could complement that of the Denormalized model, as in the following example:</p> <p>A <code>Dimensional model</code> enables <strong>fast search</strong>. Joins between the <code>dimension tables</code> and the <code>fact table</code> are set up in a <code>star-schema</code>. Searching for John Smith would be simplified because we'll search for John OR Smith only in the relevant dimension table, and fetch the corresponding person ids from the fact table (fact table FKs point to dimension table PKs), thereby getting all persons with either of the 2 keywords in their name. (A further enhancement would enable us to search for all persons having variations of "John Smith" in their names e.g. <em>John, Jon, Johnny, Jonathan, Smith, Psmith, Smythe</em> by building <code>snowflake</code> dimensions.)</p> <p>A <code>Denormalized model</code>, on the other hand, enables <strong>fast retrieval</strong>, such as returning back a lot of columns about a specific item without having to join multiple tables together.</p> <p>So in the above scenario, we would first use the Dimensional model to get a set of IDs for the persons of our interest, and then use the Denormalized table to get full details of those selected IDs without having to do any further joins.</p> <p>This kind of a search would be very slow if we directly query the Denormalized tables, because a text search will need to be done on the PersonName column. It becomes even slower if we try to include the name variations, or if we need to add more search criteria.</p> <p><strong>Excellent reference:</strong></p> <p>An excellent reference for learning about the vast (and very interesting) topic of Dimensional Modeling is Ralph Kimball's <code>The Data Warehouse Lifecycle Toolkit</code>. Its companion volume <code>The Data Warehouse Toolkit</code> covers a large number of actual use cases.</p> <p>Hope this helps!</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload