この話のモチベーション
下記シーンも増えてきて、ちらほら考え直すこともあったので
- これまではDWHにおいて制約は重視してこなかった（クラウドサービスのDWHでは実際に制約が反映されるわけではないため）
- 直近DWHへのデータの集約が楽になり、OLAP + α的な利用ケースもある
- シンプルにRDBMSから完全シンク（同期）目的でデータを転送するシーンも増えてきた
- BigQueryなども最適化の観点でも押し出してきている
確かにDWHを使い始めた（または旧基盤から移行した）というケースから、少し時間も経ってきて
特段設定を入れずに回しても成り立ってたけど、、というシーンもあるかと思う。それぐらい、クラウド上のDWHはシンプルに使える楽さは改めて感じる。
制約について
SnowflakeやBigQuery, Redshiftでほぼ同様に下記制約が利用可能な状態である。
しかしデータが強要されるわけではないので、設定しても重複可能が可能な状況があり得る。
- UNIQUE（ユニーク制約）
- PRIMARY KEY（主キー制約）
- FOREIGN KEY（外部キー制約）
- NOT NULL（NOT NULL制約）
制約設定におけるメリット
冗長なクエリを最適化してくれる
このカラムが制約付きですよっていうことを明確に示せる
グラフでオブジェクト同士の関係線が引ける（リレーションとはいいがたいが）
カラムの物理名をしっかり揃えようという気持ちが溢れてくる
- このあたりは外部キー制約まで、しっかり運用できる（する）必要があればという印象
最適化する（クエリのパフォーマンスを上げる）というよりも、2点目に書いた
制約付きをしっかり示せることが一番効果的でメリットが溢れる点だと個人的には思っている。
特に、トランザクションデータで複数の属性が加味されたようなデータを連携するような場合
パッと見で一意となるカラムが判別できるかというとそれは無理。
また転送元のDBから、テーブル情報を直ぐに引っ張れない（管轄が違うなど）ことも多い。
制約情報が最終的にBI側や分析側まで引っ張れるなら、そこまで情報を引き継いだ方が良いこともある。
例え、分析の過程で「このカラムはユニークだな」と気づいたとしても
それは業務的に必然なのか、たまたまそうなっているだけなのかが切り分けつかないことも多いからでもある。
制約設定におけるデメリット
基本的には上記の裏返しである
- 制約を付与しておきながら実際は制約が満たされていない場合、想定外（クエリパフォーマンスが当初よりも悪くなることがある？）
- メンテナンスの苦労
検証するのも良いかもしれないが、データ次第で当初（制約を設定しない状況）よりもパフォーマンスが落ちるのかなと。
良くも悪くも処理が止まるわけではないので、そういう点ではメンテンスの苦労は少ない。
ただし、上流システムにより必然的に制約状態が形成されるデータと、上流で加工処理を挟んだり結合が挟んだデータでは
制約テーブルに対してのデータチェック対応は異なるべきだと思う。
まとめ
将来的に利用が拡張するデータ基盤などには、積極的に制約は活用していきたい。
特に転送後に結合などを多用しないケースなどは、あまり深く考えずに上流のテーブルに従って制約を保持するのでも良さそう。
結合などを多用する場合は、転送元の上流テーブルの制約をしっかり確認の上で
その制約を引き継いで問題ないか、それでも転送後にデータチェックが必要になるか、検討すべきという印象。
特に結合時において、駆動となるテーブル（結合時に一番左に来て、べスプラ的には一番サイズが大きくいテーブル）には
制約に対応したデータチェックを忍ばせるのがよさそう。
なんにせよやっぱ制約が設定されているテーブルって少し安心するよね。