ファクト テーブル (次元的にモデル化されたデータ ウェアハウス) のメジャー フィールドで NULL 値が通常 0 としてマップされる理由は何ですか?
4 に答える
すでに別の回答を受け入れていますが、いくつかの理由から、NULL を使用する方が実際にはより良い選択であると言えます。
最初の理由は、集計は NULL が存在する場合は「正しい」回答 (つまり、ユーザーが期待する傾向のある回答) を返しますが、ゼロを使用すると「間違った」回答を返すことです。次の 2 つのクエリで AVG() の結果を考えてみましょう。
-- with zero; gives 1.5
select SUM(measure), AVG(measure)
from
(
select 1.0 as 'measure'
union all
select 2.0
union all
select 3.0
union all
select 0
) dt
-- with null; gives 2
select SUM(measure), AVG(measure)
from
(
select 1.0 as 'measure'
union all
select 2.0
union all
select 3.0
union all
select null
) dt
ここでの尺度が「アイテムを製造する日数」であり、NULL がまだ製造されているアイテムを表すと仮定すると、ゼロは間違った答えになります。同じ理由が MIN() と MAX() にも当てはまります。
2 番目の問題は、ゼロがデフォルト値である場合、デフォルト値としてのゼロと実際の値としてのゼロをどのように区別するかということです。たとえば、「EUR での配送料」の尺度を考えてみましょう。ここで、NULL は顧客が自分で注文を受け取り、配送料がかからなかったことを意味し、0 は注文が顧客に無料で出荷されたことを意味します。データの意味を完全に変更せずにゼロを使用して NULL を置き換えることはできません。他の次元 (配送方法など) との区別は明確であるべきだと主張することはできますが、それによってレポートやデータの理解がさらに複雑になります。
何をモデル化するかによって異なりますが、一般的には、集計を実行する際の複雑さを避けるためです。そして、多くのシナリオでは、それらの目的のためNULL
に扱うことが理にかなっています。0
たとえばNULL
、一定期間注文のある顧客です。または、売上高のある営業担当者NULL
(彼に恥をかかせてください!)。
主な理由は、人間の目には空白やゼロのように見えても、データベースではnullが空白やゼロとは異なる方法で扱われるためです。
これは、同じトピックに関するRalph Kimballによる古いデザインのヒントへのリンクです。
このブログ投稿では、メジャーでの null の回避について説明し、いくつかの提案を示します。