Skip to main content
Announcements
Have questions about Qlik Connect? Join us live on April 10th, at 11 AM ET: SIGN UP NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
jjordaan
Partner - Specialist
Partner - Specialist

Developments datawarehouse within QlikView

Hi all,

I am new to working with QlikView. I'm also inexperienced in working in BI.
Can anyone recommend a book if I want more depth in the development of BI and especially the ideas behind the development of data warehouses (within QlikView) models with the Star Schema and Snowflake schemas and how to develop these.

Thanks for your help.

1 Solution

Accepted Solutions
Jason_Michaelides
Luminary Alumni
Luminary Alumni

Hi Jeroen,

Your data model looks pretty good to me on the face of it.  I would make a few further changes to reduce the number of joins:

  1. ItemVC, ItemHC and ItemCat - use ApplyMap() to bring the xxxDesc fields into the main Item table. (The F1 help gives a good description of how to use ApplyMap() if you've never done it before)
  2. ItemCR - is this 1 to 1 on ItemVariantID?  If so, consider either using ApplyMap() or a Left Join to bring this table into the Item table as well.
  3. I would Left Join the Transactions table into the Headers table (assuming a standard 1 to many relationship applies from Header to Transactions) - LEFT JOIN (Headers) LOAD * FROM Transasctions...;
  4. What is the field "Document"?  Good practice is not to use fields in the joins that you may use in counts etc in the UI.  So maybe create a new key here.
  5. How many transactions are you dealing with?  If it's a large number then consider adding a customer counter table to avoid using COUNT(DISTINCT CustNo) for your customer counts (see below link)

So, as I say, it already looks pretty good to me - although I obviosuly can't speak for the data itself!  To help you further, see this thread for links to some best practice documents - there are some real gems in there.

Good luck!

Jason

View solution in original post

5 Replies
Jason_Michaelides
Luminary Alumni
Luminary Alumni

Hi,

If you are only looking to use QlikView for your reporting and analysis them you may find that you don't need a traditional data warehouse. If this is the case, start with the QlikView white papers and presentations that are available and go from there. There are loads of discussions on this forum about data modelling etc. have a good read and start to play!

Hope this helps,

Jason

jjordaan
Partner - Specialist
Partner - Specialist
Author

Jason,

Thanks for your comment.
Now I use QlikView indeed mainly for analysis and reporting.
However, I want to get involved more.
Now I have made a QVD generator ​​that extract the data from the source and generated QVD.
Then I make the data model in the dashboard on the QVD and also some ETL operations.
However I wish to improve data model within the dashboards and perhaps the star schema system to work.

Jason_Michaelides
Luminary Alumni
Luminary Alumni

In most cases a star-type schema will be most efficient in QlikView. Post an image of your current data model with some information on the tables (field types and numbers of records etc) and we may make some suggestions.

jjordaan
Partner - Specialist
Partner - Specialist
Author

Hi Jason,

It is a dashboard on Microsoft Navision.
Below the explanation of the tables:
- QV Transactions table > these are the Sales Lines, Sales History Line, via Concatenate.
- QV Headers > Headers are the Sales (orders) and the Sales History Header via a concatenate.
- QV Season Exchange Rate > Here are the currency used for calculation values ​​of other currencies.
- QV Item> These are the articles
- QV Item HC> This is within NAV within a specific module for Size (Medium, Large, etc.)
- QV Item VC> This is within NAV within a particular module used for colors (Black, Brown, etc.)
- QV Item Cat> This it the item categories (item (main) groups), set up

I hope I've given you enough information so.

Jason_Michaelides
Luminary Alumni
Luminary Alumni

Hi Jeroen,

Your data model looks pretty good to me on the face of it.  I would make a few further changes to reduce the number of joins:

  1. ItemVC, ItemHC and ItemCat - use ApplyMap() to bring the xxxDesc fields into the main Item table. (The F1 help gives a good description of how to use ApplyMap() if you've never done it before)
  2. ItemCR - is this 1 to 1 on ItemVariantID?  If so, consider either using ApplyMap() or a Left Join to bring this table into the Item table as well.
  3. I would Left Join the Transactions table into the Headers table (assuming a standard 1 to many relationship applies from Header to Transactions) - LEFT JOIN (Headers) LOAD * FROM Transasctions...;
  4. What is the field "Document"?  Good practice is not to use fields in the joins that you may use in counts etc in the UI.  So maybe create a new key here.
  5. How many transactions are you dealing with?  If it's a large number then consider adding a customer counter table to avoid using COUNT(DISTINCT CustNo) for your customer counts (see below link)

So, as I say, it already looks pretty good to me - although I obviosuly can't speak for the data itself!  To help you further, see this thread for links to some best practice documents - there are some real gems in there.

Good luck!

Jason