Sql 在数据仓库中处理空值

我想询问您的意见，当涉及到数据仓库和SSI/SSA时，处理空数据值或空数据值的最佳实践是什么

我有几个事实和维度表，它们在不同的行中包含空值

具体内容：

1）处理空日期/时间值的最佳方法是什么？我是否应该在时间或日期维度中创建一个“默认”行，并在找到空值时将SSI指向默认行

2）处理维度数据内部的空值/空值的最佳方法是什么。例如：我在“Accounts”维度中有一些行，它们在Account Name列中有空（非NULL）值。我应该将列中的这些空值或null值转换为特定的默认值吗

3）类似于上面的第1点-如果我的Facttable行在某个维度列中没有记录，我该怎么办？如果发生这种情况，是否需要每个维度的默认维度记录

4）关于如何在Sql server integration services（SSIS）中处理这些操作，有什么建议或提示吗？最好的数据流配置或使用最好的转换对象会很有帮助

谢谢：-）

NULL或日期维度中具有适当含义的保留id。请记住，NULL确实可以有许多不同的含义，它可能是未知的、不适用的、无效的等等

我更喜欢空字符串（并且不能为NULL），但在我现在正在处理的项目中，将空字符串转换为NULL，并允许在数据库中使用它们。需要讨论的一个潜在问题是，空白中间首字母（没有中间名，所以中间首字母为空）与未知中间首字母或类似语义不同。为了钱，我们的模型允许空值-事实上我对此有一个很大的问题，因为通常情况下，它们真的应该是0，它们总是作为0使用，并且它们总是必须用ISNULL（）包装。但由于将空字符串转换为NULL的ETL策略，它们被设置为NULL-但这只是固定宽度传输文件格式的工件，在某些源系统中有空格而不是0

我们的事实表通常有一个基于所有维度的PK，所以这是不允许的——它将链接到一个虚拟维度或未知维度

在SSIS中，我制作了一个修剪组件，用于修剪所有字符串末端的空间。我们通常必须在SSI中进行大量的日期验证和转换，这在组件中是最好的

---

正如前面的回答所述，维度的空值可能有许多不同的含义，如未知、不适用、未知等。如果能够在应用程序中区分它们是有用的，添加“伪”维度条目会有所帮助

在任何情况下，我都可以避免使用Null事实外键或维度字段，即使只有一个“未知”维度值也可以帮助用户定义包含数据质量不是100%（而且从来都不是100%）的全覆盖分组的查询

我一直在使用的一个非常简单的技巧并没有让我感到厌烦，就是在t-sql中使用int-IDENTITY（1,1）定义我的维度代理键（从1开始，每行递增1）。伪密钥（“不可用”、“未分配”、“不适用”）定义为负整数，并由ETL过程开始时运行的存储过程填充

例如，创建为

    CREATE TABLE [dbo].[Location]
    (
        [LocationSK] [int] IDENTITY(1,1) NOT NULL,
        [Name] [varchar](50) NOT NULL,
        [Abbreviation] [varchar](4) NOT NULL,
        [LocationBK] [int] NOT NULL,
        [EffectiveFromDate] [datetime] NOT NULL,
        [EffectiveToDate] [datetime] NULL,
        [Type1Checksum] [int] NOT NULL,
        [Type2Checksum] [int] NOT NULL,
    ) ON [PRIMARY]

以及用

Insert Into dbo.Location (LocationSK, Name, Abbreviation, LocationBK, 
                      EffectiveFromDate,  Type1Checksum, Type2Checksum)
            Values (-1, 'Unknown location', 'Unk', -1, '1900-01-01', 0,0)

我已经制定了一个规则，每个维度至少有一个这样的伪行，用于维度查找失败的情况，并构建异常报告来跟踪分配给这些行的事实的数量

谢谢你的意见

我在最近的项目中做了两件事：

1） 使用Steve关于未知/特殊维度值的负ID键的建议。这项工作非常有效，在SSAS多维数据集构建过程中没有出现任何问题

2） 创建转换以检查值是否为空，如果为空，则转换为-1（维度中的未知记录），如果是度量值，则转换为0。下面的表达式作为示例显示（我在派生列转换中使用了这些表达式）：

---

希望这对将来的其他人有所帮助；-）

我可以建议的另一个解决方案是，在

ETL步骤中定义一个传输表，在所有必要的转换之后，将导入的记录临时存储到其中。
我会添加一些额外的属性，以转移表允许有人；旁边的原始值属性可以为NULL或其他一些不需要的值；插入一个“编码”值，一方面识别问题，另一方面插入出现错误值的属性名称

这样做之后，我仍然可以在以后的步骤中决定如何使用非规范化和传输的数据。。。可能会过滤出错误值，或在单独的错误维度中提及错误值，以便包含在报告中，说明哪些值是异常值，以及它们如何可能影响聚合值

e、 g

另一个属性=
IdOrder
，
出生日期
，
订单金额
，等等

当然，如果记录可能有超过1个错误（NULL）值，您会遇到更多的麻烦，但是在这种情况下，您可以扩展“跟踪”属性的数量或“返回到源”，并找出问题发生的位置和原因（与开发部门一起）

这是一个有点复杂的步骤，但是为了完整性和正确性，我认为这是不可避免的和必要的，因为否则可能会遇到严重聚合的信息

也许这也会帮助某人；）
 有趣的是，你有没有遇到过SSA关于负面身份值的争论
ISNULL(netWeight) ? 0 : netWeight // This is an example of a Measure column
ISNULL(completeddateid) ? -1 : completeddateid // This is an example of a dimension key column

error-code attribute= -1 = NULL date -2 = NULL numerical value -3 = NULL PK -4 = NULL text value