在QlikView的数据模型中，可能会遇到一些未预期的合成键（Synthetic Keys）和合成表（Synthetic Tables）。这些合成键和表是在加载具有共同字段名的两个或多个表时自动创建的。这种自动关联是基于共同字段的功能。然而，当两个或多个表之间存在多个共同字段时，QlikView会创建合成键和合成表。合成表（如$Syn表）和合成键（如$Syn符号）被添加到用户上传的表中，并用于与合成表的连接。
合成键是QlikView处理复合键的一种方法。合成表包含了一个合成键，该合成键是由连接表的所有多个键字段的组合构成的。在数据模型中，有两个共同的字段“Branch”和“Region”，因此QlikView自行创建了合成键和合成表。如果查看表查看器中的源表视图，它显示这两个表之间有两个字段是连接的。
根据QlikView参考手册，当复合/合成键的数量增加时，根据数据量、表结构和其他因素，QlikView可能或不可能优雅地处理它们。QlikView可能最终会使用过多的时间和/或内存。不幸的是，实际的限制几乎无法预测，这使得试错成为确定它们的唯一实用方法。
这也是许多人移除合成键的原因之一。但是，这个说法适用于当数据模型中有多个合成键时。然而，如果数据模型中有多个合成键，这很可能意味着数据模型存在严重问题，而不是合成键的问题。
当有两个或更多的表，并且它们有多个共同字段时，合成键提供了一个正确、紧凑和高效的解决方案。合成键并不是性能和内存问题的原因。它们通常比手动复合键稍微好一些或相似，后者通常用于移除合成键。
记得有一次，一个同事说，由于合成键，数据模型的输出显示不正确或者存在性能问题，但当他移除了合成键后，问题就解决了。这里实际的问题不是合成键，而是一个糟糕的数据模型，而在移除合成键的同时，它得到了改善。目前，没有关于使用或不使用合成键的性能和内存比较的详细信息（如果有，请分享）。
为什么应该移除合成键？如上所述，合成键可能是由于糟糕的数据建模而创建的。每当创建了意外的合成键时，应该再次查看数据模型，进行必要的更改，最终会得到一个好的数据模型。请注意，最后一句话中的关键词是“意外”。否则，合成键不会造成伤害。
逐渐意识到的第二个原因是，每当创建自己的复合键而不是合成键时，对数据模型的理解就更加清晰。否则，可以说合成键是好的，并且如果在一个好的数据模型上工作，它们提供了处理复合键的便利。
如何移除合成键？要移除合成键，首先查看数据模型，并在需要时进行必要的更改。有多种方法可以移除合成键，但这取决于需求。
当导致合成键的共同字段在数据模型中不需要，并且这样做不会影响两个表之间的关系时，可以通过注释或从加载脚本中移除字段来移除字段。
当导致合成键的共同字段不是相同的字段（不包含相似的值）时，这些实际上是名称相同的不同字段。可以通过使用“AS”子句来重命名。还可以通过使用QUALIFY语句来实现这一点。通过QUALIFY语句，字段名称被转换为“TableName.FieldName”格式。
SELECT * FROM Table1 AS T1, Table2 AS T2 QUALIFY T1.Field = T2.Field;