Qlik Community

QlikView App Development

Discussion Board for collaboration related to QlikView App Development.

thomas_wang
Contributor

Re: Should We Stop Worrying and Love the Synthetic Key?

Hi Marcus

What you describe is a correct thing, but not everyone knows. Many people who are new to QlikView™ do not know these things, because QlikView™ does NOT give a reminder to users (Different from circular loops). Professionals (as good as you) know how to do it when building a data model. but in the face of a mess like mine, the only thing you can do is reconstruct it. I'd like to hear a better way from you.

Thanks!

- T&W

thomas_wang
Contributor

Re: Should We Stop Worrying and Love the Synthetic Key?

If you are surprised how we passed the test...

Unfortunately, there may not be such null values in our test data. I think this might be the negligence of the testers, but it is not unforgivable. After all, these null values were fabricated by me for Section Access. I tried to fill up a whole row of data, but this does not make the code elegant. So I spent two days to reconstruct it.

thomas_wang
Contributor

Re: Should We Stop Worrying and Love the Synthetic Key?

I am sorry that I replied to a 8-year-old post. But I still thought it's necessary to have a little discussion here.

About I called it “defect”, I have a reason, and I think it is quite sufficient. Fact tables are used to record facts - iron facts. You can't distort it, use any way. The fact table indicates that when A is ‘x’, KEY1 is ‘x’. But this relationship was destroyed by QlikView, without any reminder. This is an incredible thing for a relational database which is as a data provider.

Another thing, I wonder if this phenomenon is different on QlikView12. I did all these things on QlikView11 (11.20.12235.0 SR5 64-bit Edition).

Thanks!

Re: Should We Stop Worrying and Love the Synthetic Key?

It is worth mentioning that QlikView is not a relational database, actually it's not a database at all. The fact that QlikView stores data does not mean the product is intended for data storage, which is not. Perhaps I should have started by with that.

With that in mind, QlikView does not care about "fact tables", "relations", "keys" or "dimensional tables". QlikView reads from whatever source and creates "tables" made up of "rows" and "columns". That's it.

If those tables where somehow related in the data source is irrelevant for QlikView. It is not irrelevant, though, for the application developer.

It is the developer who understands the input, that is, the source data whatever it storage and format is: plain text fields, database tables, JSON requests, SAP queries or etc., and who understands the output required for the analysis and front-end, that is, the user interface in QlikView with which the user will interact, for example, of all the available attributes in the database, which ones are required to perform analysis and therefore must be loaded into QlikView and which others are not.

With this understanding, the developer is the one who associates tables by using the same field name in two tables and can perform an ETL of sorts via the QlikView loading script, like JOINing tables, using ApplyMap() or formatting date and numeric values.

The developer must understand that QlikView is intended for analytics, not for storage, and it will likely not behave as the traditional relational database you might be accustomed to. It has its own syntax and its own rules.

One of this rules is that to make QlikView associate two tables, they must share at least one field with the same name, case sensitive. And if they do in the source but they were not intended to be associated, like my example about Customer ID and Product ID, is the developer who must rename those fields or not load them altogether to avoid such association.

QlikView will record an error if there is an error. This is not an error. QlikView does not know if you do want to have two tables with two fields named alike, therefore it cannot break a load when there is nothing broken. It is not a syntactic error and it may not even be a data modelling error if you know what you are doing and you are doing it on purpose. That's why this is not a defect.

This "phenomenon" is exactly the same in QlikView 12, because QlikView 12 is not a database either. What it does change is performance, what causes an app to perform better and what it makes it perform worse, there are changes between QlikView 11 and QlikView 12.

For all things performance, the Qlik Scalability‌ has a lot of good documentation.

thomas_wang
Contributor

Re: Should We Stop Worrying and Love the Synthetic Key?

Alright, you could say QlikView is something, and is not something else. You said developer who use QlikView must understand something, that is alright, too. But I think the more demanding QlikView is, the more unfriendly it is. Especially when it is out of line with similar products around.

I might say a little more, you can ignore the above paragraph if you like. Let's cut to the chase. If a phenomenon can not be explained, it can not be used, and then it has no value. Moreover, this phenomenon is easy to cause confusion. I hope it is not a "defect", but someone must give a rigorous explanation on it.

I did an additional experiment. When the TTT.qvw file is quoted by binary, and do anything else in the script then. data will change. I do not think this is a reasonable phenomenon, and it will cause confusion.

捕获.JPG

I very much hope that you or others can rationalize these two phenomena.

Thanks!

thomas_wang
Contributor

Re: Should We Stop Worrying and Love the Synthetic Key?

Please see my simple example above.

thread-message-1563181

MVP
MVP

Re: Should We Stop Worrying and Love the Synthetic Key?

Very disturbing. The part I find logical is that if there is any script other than the binary, QlikView would rebuild the synthetic keys, because the script could have changed the data, even though here it did not. What I don't find logical is that the results would be different when the underlying data forcing the creation of the synthetic keys should be exactly the same. Like you, I hope someone can explain.

Re: Should We Stop Worrying and Love the Synthetic Key?

Good to read from you John!

I'd file a bug with Qlik Support if you can provide them with steps so they can reproduce the issue.

MVP & Luminary
MVP & Luminary

Re: Should We Stop Worrying and Love the Synthetic Key?

I don't want to say that the behaviour of Qlik isn't explainable even if nobody here want to struggle with your application. Usually the development of an application (and not only within Qlik) should take the opposite approach as your application - using the recommended best practices and starting simply instead of loading a whole bunch of not validated data and trying to fix all the issues within a complex datamodel. Probably it will be possible in this way but it's much harder and more time consuming as the "common" simple way.

- Marcus

thomas_wang
Contributor

Re: Should We Stop Worrying and Love the Synthetic Key?

Hi Marcus

It is usually more convincing to test the friendliness of a product against people who have never touched it. They will start from the human instinct of thinking and do something that they think is "simple". As a new user of QV, I want to be helped when I fall into a trap similar to that of the ignorant. When the functionality of a product has reached a near perfect level, its friendliness will become an important area for improvement. Talking about these things may deviate from the original theme of this discussion, but we can continue if you like.

My humble opinion.