前回の振り返り

●エンティティ内の情報を一意に識別する最小のデータの組合せをキーと呼ぶ。

●キーにはその構造や機能が異なるいくつかの種類が存在する。

●キーは重複なくデータを蓄積するために無くてはならないものである。

はじめに

このブログを執筆中のタイミングで気象庁から3か月予報が発表されました。

どうやらこの夏の気温は平年並もしくは高くなるようです。

「やだな～こわいな～」なんて思っていたら、執筆が終わった時点では雨で肌寒いのなんのって。

心構えと逆の状況になったので何か損した気分です。

今回のブログでは前回の主要トピックである「キー」の話が続くので、まだお読みになっていない方はぜひ前回分のブログをお読みください。

キーってレコードを一意に識別するためのものでしょ？

いきなり私見から始まりますが、情報システム開発でデータベースまわりの設計や実装に携わったことのある方々（例. システムエンジニア、プログラマー）に『キーって何ですか？』と尋ねると

といった感じの回答をする人が多いんじゃないかなと思います。

『一意制約を設定するための項目』と回答する人もいるかもしれません。

（キーの話題なので厳密には主キー制約と記す方が正しいかと思いつつ、以後一意性と記述することにします。）

決してそれが間違っているわけではないのですが、ただ“キー”と耳にした際に“一意性を担保するもの”と頭に浮かぶだけじゃもったいないな～と思うわけです。

そこで今回はキーが持つ重要な役割について書いてみます。

※ちなみに前述のテーブルやレコードという用語は、物理データベースの分野でよく使われます。

エンティティがテーブル、エンティティ内の1行1行がレコードと読み替えるとイメージしやすいと思います。

キーを考える際に重要なこと

キーとはエンティティ内の情報同士が同一か否かを判断するための最小のデータ項目の組合せのことでしたね。

前回の買い物の例では、“購入者”、“購入日”、“購入場所”、“商品名”の組み合わせをビジネスキーとしました。

さて、ここで以下をみてみましょう。

購入者が従兄弟である情報が追加されています。

購入場所を見てみると、これまでは食品小売店って感じでしたがこちらは家電量販店です。

購入した商品はノートパソコンですからこれまでの食品とは違い電子機器です。

商品の価格も飛び抜けて高いですよね。結果、これまでとは異なるタイプの情報だという印象を受けるはずです。

では異なるタイプの情報だから誤りか？

といえば、そうとは言えません。

むしろキーの値に重複はないので一意性という点では全く問題ありません。

一方、正しいか？

といえばそう断言することもできません。

ここで重要なことは“買い物エンティティ”で管理する情報は何なのか？ということです。

購入者の視点なら誰の買い物を管理対象とするか、ということになります。

家族に限定するのか、祖父母や従兄弟まで含めるのか、はたまた友人まで広げるのか等。

購入場所の視点なら食品小売店に限定するのか、家電量販店も含めるのか、あるいは場所は限定しないか等。

実店舗かECサイトかという考え方もありそうです。

商品の視点でも同様に、食品のみ、電子機器も含める、限定しない等。有形（モノ）か無形（コト）かという考え方もありますね。

購入日の視点にも触れましょう。

基本的には購入した日時と考えられますが、購入予定を含めるならば未来日付を許容する可能性もあり得ます。

これらが全てしっかり定義されていれば、管理対象としてどの情報が正しく、どの情報が誤りかを明確にすることができますよね。

キーを構成するそれぞれの項目において“何を含み、何を含まないか”を意識して正しく理解することがキーを考える際に重要なことなのです。

一意性というのは、管理対象として正しい範囲が定められた上で、守られるべきものだと考えるのが適当でしょう。

キーはエンティティの定義を決める

本ブログを読み続けてくれていた方ならここまで読んで気づいたことがあるのではないでしょうか？

（え、気づかなかったですか？それはきっと私の構成力不足ですね。精進します…ｳｳｯ）

今回の内容は第四回の最後に書いた「必要な“情報”のメタデータを定義する」ことと密接に関係しています。

エンティティのビジネスキーが取り得る値の範囲を定義することは、エンティティのメタデータを定義することになります。

これが冒頭で触れた“キーが持つ重要な役割”です。

ただ前回触れたように「出来事」を表すエンティティではビジネスキーを用いるケースは稀で、意味を持たない連番がキーであることがほとんどです。

（下図を参照）

このような連番のキーをみかけたら、その裏側にあるビジネスキーを想定するクセをつけましょう。

そして発番対象となる「出来事」の文脈（＝発番する対象範囲）を把握するよう心がけましょう。

これだけで皆さんのデータマネジメント力は大幅にアップすること間違いなしです。

※記載内容は執筆当時のものです。株式会社リアライズは2023年1月1日に株式会社NTTデータ バリュー・エンジニアに社名変更しました。

他の人気ブログ