Avoiding data model conflicts: Synthetic Key

Dealing with synthetic keys

When any two tables share more than one common field, QlikView creates a complex
key, or synthetic key, to try and associate both tables through the combination of all
of the common fields between them. This takes the form of an additional table
containing the shared fields and an additional key field added to all involved tables.
There are several methods we can use to remove synthetic keys:

1. Renaming / Qualifying
We can rename those fields that are a part of the synthetic key but should not be a
part of the association between the two tables.

2. Removing Fields
We can remove conflicting fields from one of the two tables. To remove a field, we
just erase the corresponding line of code from the Load script.

3.Composite Key
We can create an explicit complex key with the concatenation of all common fields
that actually represent the link between the two tables.
Note: After creating the new complex key, we can remove the conflicting fields from
either table.

Dealing with circular references

Similar to how synthetic keys are created, a circular reference can also be the result
of unwanted associations in our data model and, as such, they can be fixed using the
same principles described earlier like Renaming fields, Qualifying fields or using a
Resident Load .

Using Resident Load

Loading data from already loaded Qlikview table is possible using Resident Load.
Transformations and Calculations can be performed in the resident load script.
Loading an existing field or a succeeding table is possible too.

Using inline Data

Using Inline Load the user can define their own data and load within Qlikview scritpt.
The Inline data can be defined in the inline Data Wizard / Statement.
Example:
LOAD * INLINE [
A
B
C

];

Manipulating tables
The JOIN statement
The JOIN statement is a prefix to the LOAD statement. It is used to join the table that
is being loaded to a previously loaded table. The two tables are joined using a
natural join, this means that the columns in both tables are compared and the join
is made over those columns that have the same column names. This means that if
multiple columns are shared between tables, the match will be made over the
distinct
combinations of those columns.
IMP : By default, QlikView performs an outer join. This means that the rows for both
tables are included in the resulting table. When rows do not have a corresponding
row in the other table, the missing columns are assigned null values.
Note: When using just the bare JOIN statement, the join will be made to the table loaded
directly before the JOIN statement. If the table to join to was loaded somewhere earlier in the
script, that table can be joined to by supplying its name in parentheses.

The JOIN statement can be prefixed with the statements INNER, OUTER, LEFT, and
RIGHT, which performs an inner, outer, left, or right join respectively. This has the
following results:
INNER JOIN: Only rows that can be matched between both tables will be kept in the
result.
OUTER JOIN: All rows will be kept in the result, rows that do not have a
corresponding value in the other table will get null values for the fields that are
unique to that table. When no prefix is specified, this is the default join type that will
be used.
LEFT JOIN: All rows from the first table and those rows from the second table that
have a corresponding key in the first table, will be included in the result. When no
match is found, null values will be shown for the columns that are unique to the
second table.
RIGHT JOIN: All rows from the second table and those rows from the first table which
have a corresponding key in the second table, will be included in the result. When no
match is found, null values will be shown for the columns that are unique to the first
table.

The KEEP statement

The KEEP statement works in the same way that the JOIN statement does, with a
small difference. Instead of joining the result in a single table, the KEEP statement
keeps both original tables and filters (keeps) rows in one table based on matching
rows in another table. The same logic for INNER, OUTER, LEFT, and RIGHT KEEP applies
here as did with the JOIN statement.

The CONCATENATE statement

The CONCATENATE statement is also a prefix to the LOAD statement, but instead of
matching and merging rows between tables, this statement appends the rows of one
table to another table.

The NOCONCATENATE statement

When two tables share the exact same columns, QlikView will automatically
concatenate them. We can prevent this from happening by prefixing the LOAD
statement for Table2 with the NOCONCATENATE statement. This statement instructs
QlikView to create a new table, even if a table with the same columns already exists.
Note: However, in reality, if two tables contain the exact same columns, QlikView
will implicitly concatenate Table2 onto Table1. The result of this script is a single table.
We can prevent this from happening by prefixing the LOAD statement for Table2 with
the NOCONCATENATE statement.

Using MAPPING tables

The MAPPING statement provides an alternative to the JOIN statement in a very
specific scenario: when you want to replace a single key value with a value from a
lookup (mapping) table.
By prefixing the LOAD statement with the MAPPING statement, we tell QlikView that
we want to create a mapping table. This is a specific type of table that has the
following properties:
It can only have two columns, the first being the lookup value and the second
being the mapping value to return.
It is a temporary table. At the end of the script, QlikView automatically removes the
table from the data model.
Use of The ApplyMap() function : It uses three parameters:
The name of the mapping table to use
The search value, a field value or expression from the source table, that is looked
up in the mapping table.
An optional value that specifies what value to use when no match is found in the
mapping table; here we used the value Unknown. When no value is specified, the
search value is returned.

Adding comments

The COMMENT statement can be used to add comments to tables and fields. These
comments will be shown when hovering the mouse cursor over table and field names
in various dialogs and the Table Viewer window, and are a very useful aid for
understanding the data.

Storing tables
In an environment with multiple documents, it is very likely that we will want to reuse the same table in different apps. Fortunately, there is an easy way to export a
QlikView table to an external QVD file; the STORE statement.

STORE [ABC] INTO '..\Data Files\QVDs\ABC.qvd' (qvd);

This tells QlikView to store the table [ABC] into the sub-folder DataFiles\QVDs with the
filename ABC.qvd. The .qvd suffix at the end of the statement tells QlikView to use the
QVD format. The other option is (txt) to store the table in text format.

Renaming tables and fields

Renaming tables or fields in QlikView is done using the RENAME statement.
RENAME TABLE [ABC] TO [XYZ];
RENAME FIELD [%ABCD] TO [ABCD ID];
RENAME FIELD [ABCD] to [AB], [WXYZ] to [WX];

Deleting tables and fields

Deleting tables or fields is done using the DROP statement.

DROP TABLE [ABC];
DROP FIELD [%ABCD];
DROP FIELD [%ABCD] FROM [ABC];

The first line deletes the table [ABC]. The second line deletes the field [%ABCD]. The
third line also deletes the field [%ABCD], but only from the [ABC] table. If any other
tables contain the same field, those are left unaffected.