<?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: Which is the best Data Model in QlikView</title>
    <link>https://community.qlik.com/t5/QlikView/Which-is-the-best-Data-Model/m-p/1063793#M935109</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;To compare only the app-size isn't enough to decide which approach might be the most suitable - especially by rather small apps like this one. Furthermore you would need to check the records and sizes of tables and fields and the calculation times of your objects with a mem-file analysis: &lt;A href="https://community.qlik.com/qlik-blogpost/2916"&gt;Recipe for a Memory Statistics analysis&lt;/A&gt; in conjunction with various optimizing technics: &lt;A href="https://community.qlik.com/message/963937"&gt;Document Analyzer update 2.7&lt;/A&gt; and &lt;A href="https://community.qlik.com/qlik-blogpost/3632"&gt;The Importance Of Being Distinct&lt;/A&gt;.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Another important point are load-times and also the efforts to develop and maintain such a datamodel: &lt;A href="https://community.qlik.com/qlik-blogpost/3398"&gt;Data Modelling: Clarity vs. Speed&lt;/A&gt;.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Personal I prefer the star-scheme with a single fact-table and some dimension-tables around and I implement a link-table approach only if it's necessary (by having more then one fact-table which I didn't could merge into one single fatc-table without other disadvantages) and I never use your preferred second approach and if you looked through various material here within the community: &lt;A href="https://community.qlik.com/docs/DOC-9040"&gt;More advanced topics of qlik datamodels&lt;/A&gt; or within books: &lt;A href="https://community.qlik.com/docs/DOC-8898"&gt;Books and literature&lt;/A&gt; to the topic of creating datamodels you wouldn't find a recommendation for it (this doesn't meant it won't in general work but it has definite disadvantages).&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;- Marcus&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Wed, 02 Mar 2016 08:55:55 GMT</pubDate>
    <dc:creator>marcus_sommer</dc:creator>
    <dc:date>2016-03-02T08:55:55Z</dc:date>
    <item>
      <title>Which is the best Data Model</title>
      <link>https://community.qlik.com/t5/QlikView/Which-is-the-best-Data-Model/m-p/1063790#M935104</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;&lt;SPAN style="text-decoration: underline;"&gt;&lt;STRONG&gt;&lt;A href="https://community.qlik.com/qlik-users/171708"&gt;sunindia&lt;/A&gt;‌ &lt;A href="https://community.qlik.com/qlik-users/27943"&gt;Marcus_Sommer&lt;/A&gt;‌ &lt;BR /&gt;&lt;/STRONG&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="text-decoration: underline;"&gt;&lt;STRONG&gt;&lt;BR /&gt;&lt;/STRONG&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="text-decoration: underline;"&gt;&lt;STRONG&gt;Hi,&lt;/STRONG&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="text-decoration: underline;"&gt;&lt;STRONG&gt;&lt;BR /&gt;&lt;/STRONG&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="text-decoration: underline;"&gt;&lt;STRONG&gt;Total I have created 3 schemas for my dashboard. Not sure which schema to use. &lt;/STRONG&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;UL style="list-style-type: disc;"&gt;&lt;LI&gt;&lt;STRONG&gt;Pure star schema&lt;/STRONG&gt;&lt;/LI&gt;&lt;LI&gt;&lt;STRONG&gt;Schema with Link table&lt;/STRONG&gt;&lt;/LI&gt;&lt;LI&gt;&lt;STRONG&gt;Star schema with out Center Fact Table&lt;/STRONG&gt;&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;&lt;STRONG&gt;Now I should suggest my organization to use the BEST Schema depending on Performance wise. Please provide me with advantages, disadvantages and the best method use ?&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="text-decoration: underline;"&gt;&lt;STRONG&gt; &lt;/STRONG&gt;&lt;/SPAN&gt;&lt;SPAN style="font-size: 10pt; line-height: 1.5em;"&gt;&lt;STRONG&gt;1.&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; &lt;SPAN style="text-decoration: underline;"&gt;PURE STAR SCHEMA:&lt;/SPAN&gt;&lt;/STRONG&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="line-height: 1.5em; font-size: 10pt; text-decoration: underline;"&gt;&lt;STRONG&gt;&lt;IMG __jive_id="116475" alt="purestar schema.png" class="jive-image image-1" src="/legacyfs/online/116475_purestar schema.png" style="height: 455px; width: 620px;" /&gt;&lt;BR /&gt;&lt;/STRONG&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;In this schema &lt;SPAN style="background: yellow;"&gt;Mem Id&lt;/SPAN&gt; and &lt;SPAN style="background: yellow;"&gt;Month_Year&lt;/SPAN&gt; is the common field in all the tables. DW_MEM_MONTH_XTRA&amp;nbsp; is the fact table and rest of them were dimension tables.&lt;/P&gt;&lt;P&gt;With this pure star schema the size of the QVW application became &lt;SPAN style="background: yellow;"&gt;89MB&lt;/SPAN&gt;. Total &lt;SPAN style="background: yellow;"&gt;59 field&lt;/SPAN&gt;s.&lt;/P&gt;&lt;P&gt;In this schema I have used so many &lt;SPAN style="background: yellow;"&gt;# of distinct values&lt;/SPAN&gt; in the expressions.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;OL style="list-style-type: decimal;"&gt;&lt;LI&gt;&lt;STRONG&gt;&lt;SPAN style="font-size: 12.0pt;"&gt;2. &lt;/SPAN&gt;&lt;SPAN style="font-size: 12.0pt; text-decoration: underline;"&gt;STAR SCHEMA WITH OUT CENTER FACT TABLE:&lt;/SPAN&gt;&lt;/STRONG&gt;&lt;/LI&gt;&lt;/OL&gt;&lt;P&gt;&lt;IMG __jive_id="116476" alt="star schema without.png" class="jive-image image-2" src="/legacyfs/online/116476_star schema without.png" style="height: 442px; width: 620px;" /&gt;&lt;/P&gt;&lt;P&gt;In this schema &lt;SPAN style="background: yellow;"&gt;Mem Id&lt;/SPAN&gt; and &lt;SPAN style="background: yellow;"&gt;Month_Year&lt;/SPAN&gt; is the common field in all the tables. DW_MEM_MONTH_XTRA&amp;nbsp; is the fact table and rest of them were dimension tables.&lt;/P&gt;&lt;P&gt;With this star schema the size of the QVW application became &lt;SPAN style="background: yellow;"&gt;42MB&lt;/SPAN&gt;. Total &lt;SPAN style="background: yellow;"&gt;55 field&lt;/SPAN&gt;s.&lt;/P&gt;&lt;P&gt;In this schema I have used so many &lt;SPAN style="background: yellow;"&gt;# of distinct values&lt;/SPAN&gt; in the expressions.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;OL style="list-style-type: decimal;"&gt;&lt;LI&gt;&lt;STRONG&gt;&lt;SPAN style="font-size: 12.0pt;"&gt;3. &lt;/SPAN&gt;&lt;SPAN style="font-size: 12.0pt; text-decoration: underline;"&gt;SCHEMA WITH LINK TABLE:&lt;/SPAN&gt;&lt;/STRONG&gt;&lt;/LI&gt;&lt;/OL&gt;&lt;P&gt;&lt;SPAN style="; font-size: 12.0pt; text-decoration: underline;"&gt;&lt;STRONG&gt;&lt;IMG __jive_id="116480" alt="linktable.png" class="jive-image image-3" src="https://community.qlik.com/legacyfs/online/116480_linktable.png" style="height: 404px; width: 620px;" /&gt;&lt;BR /&gt;&lt;/STRONG&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;In this schema &lt;SPAN style="background: yellow;"&gt;Mem Id&lt;/SPAN&gt; and &lt;SPAN style="background: yellow;"&gt;Month_Year&lt;/SPAN&gt; is the common field in all the tables. DW_MEM_MONTH_XTRA&amp;nbsp; is the fact table and rest of them were dimension tables.&lt;/P&gt;&lt;P&gt;With this star schema the size of the QVW application became &lt;SPAN style="background: yellow;"&gt;49MB&lt;/SPAN&gt;. Total &lt;SPAN style="background: yellow;"&gt;65 field&lt;/SPAN&gt;s. Because of the Link table the # of&amp;nbsp; rows increased=2586767&lt;/P&gt;&lt;P&gt;In this schema I have &lt;SPAN style="; background: yellow; text-decoration: underline;"&gt;&lt;STRONG&gt;NOT&lt;/STRONG&gt;&lt;/SPAN&gt; used &lt;SPAN style="background: yellow;"&gt;# of distinct values&lt;/SPAN&gt; in the expressions.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;please help.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks,&lt;/P&gt;&lt;P&gt;Rajitha&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 01 Mar 2016 17:12:22 GMT</pubDate>
      <guid>https://community.qlik.com/t5/QlikView/Which-is-the-best-Data-Model/m-p/1063790#M935104</guid>
      <dc:creator>Anonymous</dc:creator>
      <dc:date>2016-03-01T17:12:22Z</dc:date>
    </item>
    <item>
      <title>Re: Best Schema</title>
      <link>https://community.qlik.com/t5/QlikView/Which-is-the-best-Data-Model/m-p/1063791#M935106</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi, &lt;/P&gt;&lt;P&gt;In general, go for START SCHEMA, which is easy to maintain.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;As per your analysis, 3 seems to be good in terms memory and less number of distinct expression (I am not sure its impact on application).&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;What are your key business constraints?&lt;/P&gt;&lt;P&gt;How large this data can grow further?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Rgds&lt;/P&gt;&lt;P&gt;Ravi&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 01 Mar 2016 17:33:49 GMT</pubDate>
      <guid>https://community.qlik.com/t5/QlikView/Which-is-the-best-Data-Model/m-p/1063791#M935106</guid>
      <dc:creator>ravishankarqv</dc:creator>
      <dc:date>2016-03-01T17:33:49Z</dc:date>
    </item>
    <item>
      <title>Re: Best Schema</title>
      <link>https://community.qlik.com/t5/QlikView/Which-is-the-best-Data-Model/m-p/1063792#M935107</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Ravi ,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;let me put like this and correct if i am wrong as per my understanding the Model number is 2&amp;nbsp; good because: &lt;/P&gt;&lt;P&gt;1. When we compare model 2 with that of model 1 . The link Key is present in the all the tables we are replicating the same column 5 times in the center table in order to get to the true look of the start schema. Because of this additional columns the size of the app is increasing to 89 MB. So the memory consumption when opening the app would be more &lt;IMG src="https://community.qlik.com/legacyfs/online/emoticons/sad.png" /&gt;. &lt;/P&gt;&lt;P&gt;2. When the model 2 is compared to model 3 , the disadvantage in model 3 is since we are creating a link table in the memory which is an additional table concatenated from all the tables . This additional table is also taking some additional space of 9 MB in the disk which and little more memory consumption when opening up the app. I know which is very minor. But wanted to come to the true comparision. &lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 01 Mar 2016 19:40:47 GMT</pubDate>
      <guid>https://community.qlik.com/t5/QlikView/Which-is-the-best-Data-Model/m-p/1063792#M935107</guid>
      <dc:creator>Anonymous</dc:creator>
      <dc:date>2016-03-01T19:40:47Z</dc:date>
    </item>
    <item>
      <title>Re: Which is the best Data Model</title>
      <link>https://community.qlik.com/t5/QlikView/Which-is-the-best-Data-Model/m-p/1063793#M935109</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;To compare only the app-size isn't enough to decide which approach might be the most suitable - especially by rather small apps like this one. Furthermore you would need to check the records and sizes of tables and fields and the calculation times of your objects with a mem-file analysis: &lt;A href="https://community.qlik.com/qlik-blogpost/2916"&gt;Recipe for a Memory Statistics analysis&lt;/A&gt; in conjunction with various optimizing technics: &lt;A href="https://community.qlik.com/message/963937"&gt;Document Analyzer update 2.7&lt;/A&gt; and &lt;A href="https://community.qlik.com/qlik-blogpost/3632"&gt;The Importance Of Being Distinct&lt;/A&gt;.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Another important point are load-times and also the efforts to develop and maintain such a datamodel: &lt;A href="https://community.qlik.com/qlik-blogpost/3398"&gt;Data Modelling: Clarity vs. Speed&lt;/A&gt;.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Personal I prefer the star-scheme with a single fact-table and some dimension-tables around and I implement a link-table approach only if it's necessary (by having more then one fact-table which I didn't could merge into one single fatc-table without other disadvantages) and I never use your preferred second approach and if you looked through various material here within the community: &lt;A href="https://community.qlik.com/docs/DOC-9040"&gt;More advanced topics of qlik datamodels&lt;/A&gt; or within books: &lt;A href="https://community.qlik.com/docs/DOC-8898"&gt;Books and literature&lt;/A&gt; to the topic of creating datamodels you wouldn't find a recommendation for it (this doesn't meant it won't in general work but it has definite disadvantages).&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;- Marcus&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 02 Mar 2016 08:55:55 GMT</pubDate>
      <guid>https://community.qlik.com/t5/QlikView/Which-is-the-best-Data-Model/m-p/1063793#M935109</guid>
      <dc:creator>marcus_sommer</dc:creator>
      <dc:date>2016-03-02T08:55:55Z</dc:date>
    </item>
  </channel>
</rss>

