我正在創建一個DW，用於吱吱聲的OLTP。數據倉庫設計 - 處理OLTP中的空值和空值
我面臨的問題是OLTP數據庫中沒有太多的數據完整性。一個例子是郊區字段。
這個郊區字段是OLTP用戶界面上的一個自由文本字段，這意味着我們在字段中有值，並且我們有空字符串，並且有NULL值。
我們通常會如何處理？我想出的方案是：
字符串和NULL的爲空字符串僅供參考，我使用的是微軟的BI堆棧（SQL服務器，SSIS，SSAS，SSRS）
簡短的回答是，它取決於NULL和空字符串在源系統中的含義。
這個一般問題（處理NULL）已經被討論了很多，例如， here,here,here等。我認爲最重要的一點是數據倉庫只是一個數據庫;它可能有一個非常特定類型的模式，並且是爲一個目的而設計的，但它仍然只是一個數據庫，並且仍然適用於任何關於NULL的一般建議。 （作爲一個方面說明，我有時候更喜歡談論「報告數據庫」而不是「數據倉庫」，因爲它讓事情保持透徹，一些DBA和開發人員開始爲巨大的服務器羣和多服務器羣制定計劃，但是最終它只是一個報告數據庫。）
無論如何，它並不是完全清楚你想使用哪一個NULL，但它看起來像它可能是維度上的屬性。
我（可能）不會使用你的三種方法中的任何一種，但它取決於你的數據的含義。按原樣導入數據並不實用，因爲數據倉庫的部分價值在於數據已被清理並且一致，這使得查詢和比較其他維度中的數據變得更加容易。
用'Unknown'替換空字符串可能正確也可能不正確：空字符串在源系統中的含義是什麼？ 「這意味着沒有郊區」和「這意味着我們不知道是否有郊區」有很大的區別。假設空字符串表示「沒有郊區」，並且NULL表示「未知」，那麼我會將空字符串原樣導入，但將NULL替換爲「未知」。這樣做的主要原因是，如果Suburb字段將用作報表中的過濾條件，則用戶（可能還有報表工具）會更容易使用「UNKNOWN」之類的非NULL值。如果源系統中沒有一致性，並且您不知道空字符串和NULL是什麼意思，那麼您需要先澄清並理想地修復源系統（DWH的另一個好處是它有助於識別不一致性和源系統中的數據處理錯誤）。
您最後的想法將NULL s轉換爲空字符串是相同的問題：NULL實際上在源系統中意味着什麼？如果它的意思是「沒有郊區」，那麼用空字符串替換它可能是一個好主意，但如果它意味着別的東西，那麼你應該把它當作別的東西來處理。因此，總而言之，我的首選是按原樣導入空字符串，並將NULL轉換爲「UNKNOWN」，但我無法確定這對您的情況是否有意義。這個問題沒有單一的答案，因爲這一切都取決於你的具體數據及其含義。但只要您始終如一地執行並清楚瞭解源系統如何處理數據，在數據倉庫（或任何其他數據庫）中使用NULL就沒有問題。
如果空字符串有多個可能的含義，它會變得更糟 - 如果這意味着「這個記錄沒有郊區，但它適用於該行;我們不知道是否有郊區;郊區存在但尚未加載;郊區不適用於此行「 –
@NWest是的，我完全同意，這就是爲什麼您需要非常好地瞭解源系統的原因。根據我的經驗，最糟糕的罪魁禍首是用戶可定義的自定義字段或不可修改的第三方應用程序，因此用戶（ab）使用現有的但未使用的字段來存儲那些從來不存在的奇怪數據。當兩個用戶使用相同的字段表示不同的東西時，情況會更糟糕，這在像CRM這樣的系統中並不少見：每個用戶都只能看到他們自己的數據，因此他們傾向於考慮數據，甚至將GUI視爲「他們的」。 – Pondlife
語義，NULL通常會是mea ñ未定義/未知。而空字符串將意味着該值已知爲空。在你的郊區例子中，NULL可能意味着不知道給定記錄是否有郊區，而「」可能意味着對於給定記錄肯定沒有郊區。
如果NULL和「的意思是」在你的情況相同，最好是歸兩個值，以同樣的事情（說「導入到DW之前」），以方便以後做你的報告（以免具有NULL = 50和「」= 34並且必須將它們加在一起）。
爲什麼NULL在DW中是不可以的？我不明白從70年代開始遵循DW概念的願望 - 如果出生日期不詳，那不是1900-01-01。 –
我可能會同意你的意見。這個問題更多的是關於在OLTP中處理空字符串V NULL的問題 – Paul
這個問題非常類似於您擔心在將數據移動到DW之後如何處理這些數據。如果你想糾正源OLTP系統，你應該在問題（和標題）中更加清楚。 –