<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Data Model in QlikView</title>
    <link>https://community.qlik.com/t5/QlikView/Data-Model/m-p/1307765#M833650</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P style="margin-top: 11.25pt; margin-bottom: 11.25pt; background: white;"&gt;&lt;SPAN style="font-size: 11.0pt; font-family: 'Arial','sans-serif'; color: #231f20;"&gt;When a dimension table is snowflaked, the redundant many-to-one attributes are removed into separate dimension tables. For example, instead of collapsing hierarchical rollups such as brand and category into columns of a product dimension table, the attributes are stored in separate brand and category tables which are then linked to the product table. With snowflakes, the dimension tables are normalized to third normal form. A standard dimensional model often has 10 to 20 denormalized dimension tables surrounding the fact table in a single layer halo; this exact same data might easily be represented by 100 or more linked dimension tables in a snowflake schema.&lt;/SPAN&gt;&lt;/P&gt;&lt;P style="margin: 11.25pt 0; background: white;"&gt;&lt;SPAN style="font-size: 11.0pt; font-family: 'Arial','sans-serif'; color: #231f20;"&gt;We generally encourage you to handle many-to-one hierarchical relationships in a single dimension table rather than snowflaking. Snowflakes may appear optimal to an experienced OLTP data modeler, but they’re suboptimal for DW/BI query performance. The linked snowflaked tables create complexity and confusion for users directly exposed to the table structures; even if users are buffered from the tables, snowflaking increases complexity for the optimizer which must link hundreds of tables together to resolve queries. Snowflakes also put burden on the ETL system to manage the keys linking the normalized tables which can become grossly complex when the linked hierarchical relationships are subject to change. While snowflaking may save some space by replacing repeated text strings with codes, the savings are negligible, especially in light of the price paid for the extra ETL burden and query complexity.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="font-family: 'Arial','sans-serif';"&gt;&lt;A href="https://discuss.analyticsvidhya.com/t/what-is-the-difference-between-star-schema-and-snow-flake-schema-in-qlikview/819/2"&gt;https://discuss.analyticsvidhya.com/t/what-is-the-difference-between-star-schema-and-snow-flake-schema-in-qlikview/819/2&lt;/A&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="font-family: 'Arial','sans-serif';"&gt;&lt;A _jive_internal="true" href="https://community.qlik.com/docs/DOC-5830"&gt;https://community.qlik.com/docs/DOC-5830&lt;/A&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="font-family: 'Arial','sans-serif';"&gt;&lt;A _jive_internal="true" href="https://community.qlik.com/thread/124652"&gt;https://community.qlik.com/thread/124652&lt;/A&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Mon, 05 Jun 2017 04:02:23 GMT</pubDate>
    <dc:creator>prma7799</dc:creator>
    <dc:date>2017-06-05T04:02:23Z</dc:date>
    <item>
      <title>Data Model</title>
      <link>https://community.qlik.com/t5/QlikView/Data-Model/m-p/1307764#M833649</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;hello everyone please share what kind of challenges you faced during developing large Data Model and how to resolve it?&lt;/P&gt;&lt;P&gt;which schema is the best for it?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thank You&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 25 Nov 2020 16:16:04 GMT</pubDate>
      <guid>https://community.qlik.com/t5/QlikView/Data-Model/m-p/1307764#M833649</guid>
      <dc:creator>Anonymous</dc:creator>
      <dc:date>2020-11-25T16:16:04Z</dc:date>
    </item>
    <item>
      <title>Re: Data Model</title>
      <link>https://community.qlik.com/t5/QlikView/Data-Model/m-p/1307765#M833650</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P style="margin-top: 11.25pt; margin-bottom: 11.25pt; background: white;"&gt;&lt;SPAN style="font-size: 11.0pt; font-family: 'Arial','sans-serif'; color: #231f20;"&gt;When a dimension table is snowflaked, the redundant many-to-one attributes are removed into separate dimension tables. For example, instead of collapsing hierarchical rollups such as brand and category into columns of a product dimension table, the attributes are stored in separate brand and category tables which are then linked to the product table. With snowflakes, the dimension tables are normalized to third normal form. A standard dimensional model often has 10 to 20 denormalized dimension tables surrounding the fact table in a single layer halo; this exact same data might easily be represented by 100 or more linked dimension tables in a snowflake schema.&lt;/SPAN&gt;&lt;/P&gt;&lt;P style="margin: 11.25pt 0; background: white;"&gt;&lt;SPAN style="font-size: 11.0pt; font-family: 'Arial','sans-serif'; color: #231f20;"&gt;We generally encourage you to handle many-to-one hierarchical relationships in a single dimension table rather than snowflaking. Snowflakes may appear optimal to an experienced OLTP data modeler, but they’re suboptimal for DW/BI query performance. The linked snowflaked tables create complexity and confusion for users directly exposed to the table structures; even if users are buffered from the tables, snowflaking increases complexity for the optimizer which must link hundreds of tables together to resolve queries. Snowflakes also put burden on the ETL system to manage the keys linking the normalized tables which can become grossly complex when the linked hierarchical relationships are subject to change. While snowflaking may save some space by replacing repeated text strings with codes, the savings are negligible, especially in light of the price paid for the extra ETL burden and query complexity.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="font-family: 'Arial','sans-serif';"&gt;&lt;A href="https://discuss.analyticsvidhya.com/t/what-is-the-difference-between-star-schema-and-snow-flake-schema-in-qlikview/819/2"&gt;https://discuss.analyticsvidhya.com/t/what-is-the-difference-between-star-schema-and-snow-flake-schema-in-qlikview/819/2&lt;/A&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="font-family: 'Arial','sans-serif';"&gt;&lt;A _jive_internal="true" href="https://community.qlik.com/docs/DOC-5830"&gt;https://community.qlik.com/docs/DOC-5830&lt;/A&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="font-family: 'Arial','sans-serif';"&gt;&lt;A _jive_internal="true" href="https://community.qlik.com/thread/124652"&gt;https://community.qlik.com/thread/124652&lt;/A&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 05 Jun 2017 04:02:23 GMT</pubDate>
      <guid>https://community.qlik.com/t5/QlikView/Data-Model/m-p/1307765#M833650</guid>
      <dc:creator>prma7799</dc:creator>
      <dc:date>2017-06-05T04:02:23Z</dc:date>
    </item>
    <item>
      <title>Re: Data Model</title>
      <link>https://community.qlik.com/t5/QlikView/Data-Model/m-p/1307766#M833651</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;In general the star schema is the preferred model as it offers a good balance between the&lt;/P&gt;&lt;P&gt;various trade-offs.&lt;/P&gt;&lt;P&gt; In Qlikview also the preferred model is Star Schema, because during runtime there is only very&lt;/P&gt;&lt;P&gt;less number of joins, excellent response time.&lt;/P&gt;&lt;P&gt; Also QlikView doesn’t store the duplicate values in the file, it stores distinct values and uses&lt;/P&gt;&lt;P&gt;pointers to refer when there is a duplicate, so there is no issue of space consumption.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Hope it helps!!&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 05 Jun 2017 11:27:29 GMT</pubDate>
      <guid>https://community.qlik.com/t5/QlikView/Data-Model/m-p/1307766#M833651</guid>
      <dc:creator>Anonymous</dc:creator>
      <dc:date>2017-06-05T11:27:29Z</dc:date>
    </item>
    <item>
      <title>Re: Data Model</title>
      <link>https://community.qlik.com/t5/QlikView/Data-Model/m-p/1307767#M833652</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;According to me, Dates are the biggest hurdle in data model.&lt;/P&gt;&lt;P&gt;There will be scenarios where you'll have Dates in each dimension table and mapping correctly ti the Fact can be challenging.&lt;/P&gt;&lt;P&gt;Specially when Dim Dates has multiple entry and fact date has only one entry. Which means the Fact is not populated with all the Date changes happening in other Dim but only has important records stored.&lt;/P&gt;&lt;P&gt;I'm currently dealing with it...&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Sometimes you don't have primary key in a dim table and need to map it to fact.. it can also be challenging.&lt;/P&gt;&lt;P&gt;&lt;SPAN style="font-size: 13.3333px;"&gt;It mostly depends on what kind of data you get.&lt;/SPAN&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 05 Jun 2017 11:42:54 GMT</pubDate>
      <guid>https://community.qlik.com/t5/QlikView/Data-Model/m-p/1307767#M833652</guid>
      <dc:creator>MK9885</dc:creator>
      <dc:date>2017-06-05T11:42:54Z</dc:date>
    </item>
  </channel>
</rss>

