データコンサルYブログ：（第５回）「事実は一つあればよい」～データマネジメントのすべては分からないが基本的なことはよく分かるブログ
2021-06-02
このブログは、人当たりの良さとマニアックな知識で、世間の荒波を漂流しリアライズに流れ着いた「流浪のデータコンサルY」が、データマネジメントについて控えめに語るブログです。仕事の合間の息抜きにご利用ください。
前回の振り返り
●必要な情報は主体によって異なる。
●必要な情報が何であるかは、情報のメタデータとして定義する。
●同じ“情報”のかたまりのことを『エンティティ』と呼ぶ。
はじめに
「お待たせいたしました、お待たせし過ぎたかもしれません。」
とまぁ半年ぶりのブログです。
忙しさにかまけて執筆が疎かになっておりましたが、ファンからの熱い声援（注：妄想）に応えるために気持ちを新たに頑張ります。
今回のブログでは、前回までの「買い物」のネタを引き継いで話を進めていくので、まだお読みになっていない方は、ぜひ先に過去分、第１回、第２回、第３回、第４回のブログをお読みください。
前回は、必要な“情報”（＝データをつないで人間にとって意味をなす単位）は、それを受け取る主体によって異なることを説明しました。
ありていに言えば、“情報”は誰の日常にでも溢れるほど存在しており、人はそれらを無意識に取捨選択しているわけです。
ただ、データマネジメントを行うにあたっては必要な“情報”を意識して管理する必要があるので、それが何であるかを定義しなければならないという話でした。
また、「同じ“情報”のかたまりのことを『エンティティ』と呼ぶのでぜひ覚えてください！」と書きました。
せっかくなので今回からは「買い物」の情報のかたまりを”買い物エンティティ”と記述するようにします。
同じ情報？異なる情報？
夫が夕食にてガスパチョにありつけたか否かはさておき、その後の団らんの時間の会話をみてみましょう。
妻が今朝のトマトの特売の興奮冷めやらぬといった具合に今朝の買い物の話をしたところ、それを聞いた夫は既知の情報だと判断しました。
無味乾燥な返しをせず惨劇を回避した夫はナイスですね！
・・・とそれはさておき、ではなぜそのように判断できたのでしょうか？
答えは情報の重複に気づくことができたからです。
妻の話の情報が赤字の箇所だとすると、すでに蓄積されている情報の１つ（背景が黄色の箇所）と全てのデータの値が一致していることが分かりますよね。
このように、ある情報同士をデータ単位に比較し、その/それらの値が重複しているか否かを確認することで、それらが同じ情報なのか異なる情報なのかを判断することができます。
（※ツッコミどころはありますが、ヒトの言語能力の話ではなく、情報の重複判定プロセスの例えだと受け止めてください ^^;）
この夫の脳内ではもしかしたらこんなプロセスを経た結果として「既知の情報だ」と判断したのかもしれません。
必要な情報であったとしても、既存の情報と同一であれば、新たに蓄積する必要はありません。
これがここでの結論です。
エンティティ内の情報を一意に識別する最小のデータの組合せ＝キー
先の例では全てのデータの値が一致していることから同一の情報だと判断したわけですが、データの項目単位にもう少し詳しくみてみましょう。
「買い物」という文脈で考えると、“購入者”、“購入日”、“購入場所”、“商品名”はそれぞれWHO（誰が）、WHEN（いつ）、WHERE（どこで）、WHAT（何を）に相当します。
下の図1を見れば想像がつくとおり、この４つのいずれか１つでも値が異なれば別の買い物と判断できそうです。
では“商品価格(税抜)”や“購入数”はどうでしょう。
下の図2を見てシンプルに考えてみてください。
“購入者”、“購入日”、“購入場所”、“商品名”が同じであれば、必然的に“商品価格(税抜)”や“購入数”は同じになると思いませんか？
（※同じ商品でも片方は割引シールが貼られているなどのケースが考えられますが、今回は含めないことにします。）
要するに、この“買い物エンティティ”にて情報同士が同一か否かを判断するためには、全てのデータ項目を確認する必要はなく “購入者”、“購入日”、“購入場所”、“商品名”の４つだけを確認すれば良いのです。
このようなエンティティ内の情報同士が同一か否かを判断するための最小のデータ項目の組合せを『キー』と呼びます。
キーが一致している場合は情報同士が重複していることになり、異なれば別の情報と判断できます。
別の表現をすれば、キーの値が一致する情報は1つしか存在してはいけないということです。
データマネジメントにおいて『キー』は誰もが知っていて当然の用語です。
この機会に絶対に覚えましょうね！
キーの種類
キーにはその構造や機能の違いからいくつかの種類が存在します。
今回のブログではその一部に触れます。
詳しく知りたい方は、データマネジメントの参考書であるデータマネジメント知識体系ガイド第二版（以下DMBOK2）の第5章を参照すると良いでしょう。
まずは構造面からみてみます。
今回の例のように複数のデータ項目からなるキーを『複合キー』と呼びます。
一方で単一のデータ項目でキーとなる場合、これといった呼称はありません。
『単一キー』と呼ぶ時があるかな？くらいです。
DMBOK2には『シンプルキー』と書かれていますが、正直言って私は使ったことありません（^^;）
次に機能面からみてみます。
本例のキーは“購入者”、“購入日”、“購入場所”、“商品名”（誰が、いつ、どこで、何を）のように、その組み合わせから人が意味を推測し解釈できるものです。
このようなキーを『ビジネスキー』もしくは『ナチュラルキー』と呼びます。
私見ですが前者はデータマネジメントコンサルタントが、後者はデータベースエンジニアがよく使う印象です。
ちなみにDMBOK2には双方が書かれていますが『ビジネスキー』推しのようです。
キーの実際
最後にホンの少しだけ。
情報システムで使われるデータベースでは、“買い物エンティティ”のような「出来事」を表すエンティティにビジネスキーを用いるケースは稀なように思います。
その代わりに意味を持たない連番のデータ項目をキーとして設けることが一般的です。
（連番を設けるのには理由があるんですが、その説明はまたの機会にします。）
おわりに
ある一つの出来事を表す“情報”が、さも別の出来事として蓄積されていたらどうなるでしょう？
本当は一回の買い物が二回、三回とカウントされたり、一万円の売上が二万円、三万円と計算されたりしてしまいます。
間違いなくデータ活用に悪影響を及ぼしますよね。
これではデジタルトランスフォーメーションどころではありません。
キーは正しくデータを蓄積するために無くてはならないものだということを心に刻みましょう。
次回予告
次回はキーの話をもう少しだけ膨らませる予定です。
キーの奥深さを分かりやすくお伝えします。
お楽しみに。
※記載内容は執筆当時のものです。株式会社リアライズは2023年1月1日に株式会社NTTデータ バリュー・エンジニアに社名変更しました。
次回のデータコンサルYブログキーを考える際に重要なこと。正しくデータを蓄積するために、キーが持つ重要な役割とは？ |
前回のデータコンサルYブログ集めた情報を管理する上で大切なこととは。必要な情報は○○によって異る？？ |