Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Colleagues, good afternoon!
I am trying to solve the simplest in terms of the database structure, the problem in the Qlik Sense. For example:
There is:
[Automatically generate a table of dates]
LOAD [Date]
[Table Counterparty]:
LOAD [ID Counterparty]
[Name of contractor]
[Table Procurement]
LOAD [Date]
[ID Counterparty]
[Amount]
[Table debts]
LOAD [Date]
[ID Counterparty]
[Debt]
In this case, the keys are synthetic, which must be removed.
I tried the link between [Table debts] and [Table Procurement] for the field [ID Counterparty] break by adding [Table Counterparty] more fields [ID Counterparty for the debts of the table] = [ID Counterparty] received cyclic communication ....
simple and transparent communication, enter ext. tables that logic does not spoil hand rises. Please tell me how to resolves such a situation? (In general, absolute standard)
- - -
Коллеги, добрый день!
Пытаюсь решить простейшую, с точки зрения структуры БД, задачу на Qlik Sense. Например:
Есть:
[автоматически сформированная таблица дат]:
LOAD [Дата]
[Таблица Контрагентов]:
LOAD [ИД Контрагента],
[Наименование контрагента]
[Таблица Закупок]:
LOAD [Дата],
[ИД Контрагента],
[Сумма]
[Таблица Задолжностей]:
LOAD [Дата],
[ИД Контрагента],
[Долг]
В этом случае создаются синтетические ключи, которые необходимо убрать.
Попытался связь между [Таблица Задолжностей] и [Таблица Закупок] по полю [ИД Контрагента] разорвать путем добавления в [Таблица Контрагентов] еще поля [ИД Контрагента для таблицы задолжностей] = [ИД Контрагента], получил циклические связи....
Связи простые и прозрачные, вводить доп. таблицы, которые портят логику не поднимается рука. Подскажите пожалуйста, как разруливаются такие ситуации? (В общем абсолютно типовые)
Note: Edited by Community Moderator to include English translation as a courtesy.
Hello, Eugene!
By and large the purchase date and the payable date do not match. This is different dates in different tables. A special date field - it's more like a table Calendar. With it you can communicate is directly in the interface.
I hope these ideas help you.
Yours faithfully
Elena
- - -
Здравствуйте, Евгений!
По большому счету Дата закупки и Дата задолженности не совпадают. Это разные даты в разных таблицах. Отдельное поле Дата - это больше похоже на таблицу Календарь. С ним можно организовать связь уже непосредственно в интерфейсе.
Надеюсь, эти мысли помогут Вам.
С уважением
Елена
Note: Edited by Community Moderator to include English translation as a courtesy.
Types of problems, and there are two types of solutions - Link Tables or Concatenated Facts. Explain long time, I suggest to read my book, there are all discussed in detail:
- - -
Задачи типовые, и есть два типовых решения - Link Tables or Concatenated Facts. Объяснять долго, предлагаю почитать мою книжку, там все подробно изложено:
cheers,
Oleg Troyansky
Check out my new book QlikView Your Business - The Expert Guide for QlikView and Qlik Sense
Note: Edited by Community Moderator to include English translation as a courtesy
Hi
try this
But you should have something like FROM for all these tables !!!!
FIRSTTABLE:
LOAD [ Date]
JOIN(FIRSTTABLE)
[ Table Counterparty ] :
LOAD [ ID Counterparty ]
[Name of contractor ]
[ Table Procurement ]
JOIN[ Table Counterparty ]
LOAD [ Date ]
[ ID Counterparty ]
[Amount ]
[ Table debts ]
JOIN[ Table Counterparty ]
LOAD [ Date ]
[ ID Counterparty ]
[Debt]
Hi, galax_allu!
Thanks fo reply!
Yes, using join is one way, but these tables are large and I not have to join it.
Thanks, Oleg Troyansky, Concatenated Facts (like Link Tables) is a logical solution to the problem within the framework of the platform features, though not quite accustomed to getting started with Qlik.
- - -
Спасибо, troyansky, Concatenated Facts (как и Link Tables) является логичным решением для задачи в рамках особенностей платформы, хотя и не совсем привычным для начинающих работать с Qlik.
Note: Edited by Community Moderator to include English translation as a courtesy
good day, Elena!
We did so, a table of dates - avtosobiraemy calendar. I agree that the Date and Date of purchase of debt of this example is not logically connected, but if we want to get a sample by month / quarter / year - the calendar gives us the right filtering both tables (and the purchase and debt), which is convenient.
If there is a more ergonomic way of grouping date, I will be grateful if prompt.
- - -
Добрый день, Елена!
Мы так и сделали, таблица дат - автособираемый календарь. Я согласен, что поля Дата закупки и Дата задолженности данного примера логически не связаны, однако если мы хотим получить выборку по месяцу/кварталу/году - то календарь даст нам фильтрацию сразу обеих таблиц (и закупки и задолженности), что удобно.
Если есть более эргономичный способ группировки дат, буду признателен, если подскажете.
Note: Edited by Community Moderator to include English translation as a courtesy.
Hello, Eugene!
Strictly speaking in the calendar you can attend DATE in procurement [DATE purchases] in debts - [DATE debt], respectively.
In the visualization as a filter, you can use the date, while not forgetting about the analysis of sets, where he will check the coincidence of the respective dates. In my opinion this is the most logical solution.
Then you need to add a field [DATE purchases] and [DATE debt] directly in the calendar and all comparisons are carried out in a single table. I hope this helps.
Yours faithfully
Elena
- - -
Здравствуйте, Евгений!
Строго говоря в календаре у Вас может присутствовать ДАТА, в закупках [ДАТА закупки], в задолженностях - [ДАТА задолженности] соответственно.
В визуализациях в качестве фильтра Вы можете использовать ДАТУ, при этом не забывая об анализе множеств, где и будете проверять совпадение соответствующих дат. На мой взгляд это самое логичное решение.
Тогда нужно добавить поля [ДАТА закупки] и [ДАТА задолженности] непосредственно в календарь и все сравнения проводить в рамках одной таблицы. Надеюсь, что это поможет.
С уважением
Елена
Note: Edited by Community Moderator to include English translation as a courtesy.