我需要从EDW表（它确实维护历史记录）加载维度，并且类型为Key-Value-Parameter。
如果在EDW中获得如下记录
，我的情况就可以了Key1 Key2 Code Value EffectiveDate EndDate CurrentFlag
100 555 01 AAA 2010-01-01 11.00.00 9999-12-31 Y
100 555 02 BBB 2010-01-01 11.00.00 9999-12-31 Y
需要通过将其旋转为
来加载到DM中key1和key2组合使得DM的自然键
SK NK 01 02 EffectiveDate EndDate CurrentFlag
1 100-555 AAA BBB 2010-01-01 11.00.00 9999-12-31 Y
我的ssis包完成了这一切所有良好的转动...在DIM中查找传入的NK ..如果new将插入.. else进一步查找生效日期并确定相同自然键的传入是否有任何新的（更改） ）in attribute .. if so如果更新当前记录，则设置其结束日期并插入具有新属性值的新记录并拉出其他属性的最近记录值。
我的问题是，如果相同的自然键在单个提取中使用相同的属性两次，我的第一个查找在自然键上...将允许两个记录通过并尝试插入..其失败。如果我在NK上获得了不同的记录，那么第二个就没有被选中，需要再次运行包。
所以我的问题是如何配置查找或alernative方式来处理这种情况，当相同的NK在单个提取中出现两次时，如果在Dim表中不存在则可以插入第一条记录，而第二条记录应该能够更新为参考上面插入的更改。
不确定这是什么意思解释。将屏幕截图重新附加到办公桌上（星期一）。
由于
答案 0 :(得分：0)
查找对此不利 - 使用缓存和所有内容，它只是无法查找以前设置的值。
您可能最好将其传递给SQL Command任务，并让存储过程执行插入或过期/插入，具体取决于它找到的内容。
您也可以将它们流式传输到表中并批量执行。
要解决您的流程和正在尝试填充的模型：
首先，当输入中的行顺序导致行为差异时总是很尴尬 - 即NK = A，Val = 1然后NK = A，Val = 2给出与NK = A不同的行为，Val = 2然后NK = A，Val = 1.人们不得不怀疑这是否是正确的尺寸设计。请记住，所有维度属性都基于实用选择分配给维度表。最终尺寸可以随意排列成表格 - 因此不同的设计可能更有意义。如果在一次加载中事情发生变化，这可能表明您需要分解该负载以匹配谷物（不要尝试一次加载2天数据）。
我注意到维度中有生效日期和结束日期。现在这听起来很像维度行为的属性（你的01和02代码在NK上发生了变化），而不是这个维度将被附加到的事实。这可能表明它需要在一个单独的无事实的事实表中跟踪，比如说（SK，EffectiveDate，EndDate） - 或者说它并不重要，因为你所关心的只是一个附着在事实上的NK，01,02组合，在这种情况下，你的自然键实际上是NK，01,02。
我建议回到您的事实表和传入的Feed以及预期的使用情况，然后更仔细地查看它，看看这是否需要是一个跟踪这些维度更改的单独的无事实事实表。
另外，如果您可以发布更多详细信息，这可能有所帮助，当我看到更多商业案例时，我会看到Kimball的材料有什么说法。
答案 1 :(得分：0)
凯德的评论是现货 - 但我相信你的主要问题是重复，期间。您在“源”流中有两个相同NK版本的事实是否表示两个独立的，有意义的版本？或者仅“最后”版本是否重要？
如果两个版本中反映的更改都应反映在维度表中，那么我会回应Cade的建议，将您的处理划分为多个批次。您可以按NK（和更改时间）对输入进行排序，然后使用行计数脚本枚举每个NK的“版本”，然后按版本号处理“批次”。
如果只需要将最后一个“版本”合并到维度表中，我建议您在使用查找之前消除重复。