命名規則を決めずに属人的なルールで開発を進めていると、複数人での開発や、引き継ぎの際に混乱が生じるばかりか、品質面でも重大な課題を抱えてしまうリスクがあります。データの分析範囲が広がり、取り込むデータソースが増えるにつれて項目名の一貫性が保ちにくくなるため、設計当初から複数事業部、様々な利用目的を想定しておくことが大切です。
命名規則の設計例
QVWファイル名
DocumentCALはQVWファイル単位で設定するため、QVWのファイルが変更になるとDocumentCALの再登録が必要になります。
データソース取込フォルダ
利用部署や目的、データ更新サイクルが異なるデータソースが混在していると移行やメンテナンス時に漏れが生じる可能性が高くなります。
項目名
項目名でリレーションが行われるQlikViewにとって、項目名は大変重要な項目になります。
リレーションだけでなく、チャート上の項目見出しとしても整合性が取れている内容か慎重に判断する必要があります。
以下に項目名の命名パターンを列挙します。
・変数項目 V_
事業部別の項目 COS_ （化粧品事業） CARE_ （介護事業）
・キー項目 _key
・フラグ項目 _flg
・ワーク項目 _work
※後続の処理でDROP Fields、DROP Table文で削除します
たとえば、売上金額などの項目は事業部ごとの売上金額を個別に集計したいケースがあります。
その際にSet分析で条件を指定（QlikView独自の文法。if文よりも高速）することも出来ますが、ロードスクリプトでCOS_売上金額など、事業部別のプレフィックスを設定した項目に金額を振分けることで、より高速に集計することが出来ます。
BIをスモールスタートで導入する場合、後に分析対象の事業部が増えることが想定されますので、複数事業部の項目が混在しても分かりやすいような命名規則を設計することが重要です。
関連記事
QlikViewパーソナルエディションをインストールする
国内導入実績No1、Dr.SumとQlikViewを比較する
QlikViewの開発は命名規則が重要
ロードスクリプトはタブ分けすることで開発生産性が高まる
QlikViewが遅い時は数式の最適化を検討する
