【連載】概念モデリングを習得しよう：概念情報モデルの活用（第15回）

ここでは、概念情報モデルの何たるかはおぼろげに分かったような気がするけれど、まだ、それが何の役に立つのかよく分かっていない読者のために、ソフトウェアの設計・開発における概念情報モデルの利用について解説しておくことにします。

一般的な IT システムでは、そのシステムが扱うさまざまなデータをリレーショナルデータベース（以降、略してRDBと記す）を使って保存します。RDB の基礎であるリレーショナルセオリーや論理モデルを図示化するER図に通じている読者であれば、これまで解説してきた概念情報モデルが、RDB のデータスキーマと同等であることがすんなり理解できていることと思います。なぜなら、概念情報モデルはis-a のリレーションシップを使うことを除けば、一般的なER図とほぼ同等だからです。is-a のリレーションシップにしても、二項リレーションシップの特殊形なので、ER図で表現できないことはないでしょう。

また、概念情報モデルは、その構成要素の組み立て方から、自動的にリレーショナルセオリーの第三正規化を満たすようなモデルになるはずです。

リレーショナルセオリーと概念情報モデルの違いは、前者が純粋な数学を基盤として組み立てられた理論であるのに対し、後者は現象学や言語哲学、論理学などを基盤としたオントロジー的な意味論をベースに組み立てられている点にあります。リレーショナルセオリーは単なる数学理論なので、カラムやリレーション、リレーションシップを現実の何に対応付けるかについて明確で統一的な指針は存在しません。そのため、リレーショナルセオリーを満たすデータモデルの作成は、モデル作成者の裁量に任されてしまい、各人の技量によって品質がバラバラになりがちです。出来の悪いデータモデルを持つ IT システムはたいていの場合、とても使いにくいというのが筆者のこれまでの経験からの素直な感想です。

一方で、概念情報モデルは、モデル化対象の意味論と直接結びついているので、この問題は発生しません。

あまり言及されてはいないようですが、リレーショナルセオリーに従ったデータモデルは、

• 情報の格納に必要な容量は最小である
• あるレコードを起点に別のレコードに最短でたどれる

ということが数学的に証明されています。

概念情報モデルは、結果としてリレーショナルセオリーと同型なので、この二つの事実は、概念情報モデルにも当てはまります。

RDB のデータスキーマを設計する技術者は、ぜひ概念モデリングをマスターしてスキーマ設計に役立ててください。

また、マイクロソフトがデジタルツインの実装用に提供している Azure Digital Twins というクラウドサービスがあります。このサービスは、Twin Modelという、概念情報モデルとほぼ同等のスキーマ定義用のモデルと、圏I に相当する Twin Graph が用意されています。Twin Graph が扱いたい現実世界の情報をデジタル化して写しとして IT システムが保持し、現実世界の変化を Twin Graph に反映（またはその逆）することにより、デジタルツインを実現するようになっています。スキーマを定義する Twin Model は、DTDL（Digital Twins Definition Language）で記述します。

概念情報モデルの is-a のリレーションシップの解釈と、Twin Model の extends の解釈が異なる点と、Twin Model のリレーションシップの定義が Twin（概念情報モデルの概念クラスに相当）に従属している点は異なるものの、両者はほぼ同等です。

Azure Digital Twins はオントロジーデータベースであるとうたっており、スキーマである Twin Model を実用レベルで作成できる技術者は、筆者が見渡した限り、日本だけでなく世界中でさえ、ほとんどいないように思えます。Azure Digital Twins の Twin Model の設計に必要なスキルは、全て概念情報モデルの考え方に含まれているので、こちらもぜひ活用していただきたいところです。

RDB や Digital Twin は、IT システムの心臓部です。この連載コラムの冒頭で、概念モデリングは開発対象を理解し記述するものであり、システム開発に当たっては開発対象を正しく理解することは大前提なので、概念モデリングは必須と説明しました。加えて、IT システムの心臓部の設計を支援するスキルであることもご理解いただければ、概念モデリングの重要性がより高まることと思います。

扱うデータが巨大化した2010年代以降、Redis、Amazon Dynamo、Azure Cosmos DB などNoSQL というジャンルのデータベースが使われるようになってきています。これらは圏C に相当するスキーマの定義を必要としません。スキーマなしで圏Iに相当するデータを保持するようになっています。NoSQL を使う場合、概念情報モデルのような、スキーマを記述する圏Cのモデルを必要としなさそうに見えます。しかし、NoSQL にデータを入力する時にスキーマは必要がないにしても、保持されているデータを取り出して活用する際に、そのデータが何を意味しているのか認識するために、スキーマは必ず必要となります。スキーマがなければビジネスシナリオを駆動するまともなアプリケーションは作れないし、スキーマがあればユーザーインターフェースの開発も多くの工程を自動化できるので、この場合でも、概念モデリングのスキル獲得は重要です。

組み込み制御系のソフトウェア開発においても、扱うデータの複雑化や巨大化が進んでいる昨今、制御の基盤となるデータモデルの重要性が高まっているのは間違いありません。

データベースなら関係ないと言わず、ぜひ、概念モデリングを習得して、ご自身の開発に役立ててください。

今どきのソフトウェア開発では、第三者が作成したライブラリやコンポーネント、サービスを使ってアプリケーションを実装するのが一般的です。その際、それらを使うための API に従ってコードを書いていきます。概念モデリングの観点からすると、

• API の定義 ＝ 圏C のモデル
• API を使ったアプリケーションコード ＝ 圏I のモデル

と考えられます。他にも、システム構成を記述するアーキテクチャダイヤグラムでは、一般的には、

• サービス提供者が提示する図 ＝ 圏C
• ユーザー側が作成する図 ＝ 圏I

です。 ソフトウェア開発だけでなく、業務、あるいは日常生活においてさえも、日々たくさんの図を目にすると思います。その都度、その図が圏C なのか、圏Iなのかを考えることも、概念モデリングのスキルを上げるトレーニングになるので、やってみてください。

今回の連載コラムの執筆に当たり、説明する順番に工夫を加えました。

この一連のコラムでは、まず現実世界の写しである圏I のモデルを、その後で圏C、つまり概念情報モデルを、という順番で解説してきました。

モデリングと称する作業を行う多くの技術者が、圏Iと圏Cの区別が付いていないようだ、というのが、筆者の30年以上の体験からの実感です。圏Cのモデルは、スケッチや多くの圏Iのモデルの断片を見ながら分類し、概念を抽出するという具体的な事項と抽象化された事項を行ったり来たりしながらの作業になります。この作業は、なかなか難しいというのが、区別が付きにくい一番の理由なのかもしれません。

しかし振り返ってみれば、概念モデリングの基になっている Shlaer-Mellor 法にしろ、その他のモデリング技法にしろ、いきなり圏C のモデルの説明から始まっている解説書がほとんどです。これも、圏Iと圏Cの区別が付かない要因なのではないかと筆者は考えたわけです。そういう事情で今回は、まず圏Iの何たるかを詳細かつ、くどいくらいに解説して読者に理解してもらった上で、その後に圏Cの詳細を解説するという戦略を採った次第です。

実際のところ、分類の世界を見ながら実世界を想像する難しさがあるのは確かです。しかし、概念モデリングのモデリング体系は、言語を前提とした人間の思考形態を基本にしているので、概念モデリングが人知を超越しているわけがありません。

基本にのっとって概念モデリングを繰り返していけば、そのうちあなたの脳内に概念モデリング回路が出来上がり、半自動的に概念情報モデルが湧き出るようになります。今、自分が相手にしているのは圏Iなのか圏Cなのかを明確に意識しながら概念モデリングにいそしんでください。

念のため、ここで圏I と圏Cのモデルの特徴を改めて書いておきます。

• 圏I のモデル
  ＞対象世界のある時点に対して、事柄と事柄間の意味的つながりを拾い上げた一覧

  　▶こんな性質と意味的つながりを持つ、〇〇を見つけた
  ＞記述要素
  　▶事柄 ＝ 概念インスタンス
  　▶事柄の性質 ＝ 概念インスタンスの特徴値
  　▶事柄の間の意味的つながり ＝ リンク
  　▶データ型 ＝ 特徴値の値を規定

• 圏C のモデル ＝ 概念情報モデル
  ＞対象世界に対する、意味的な枠組み
  　▶こんな性質と意味的つながりを持つなら、それは〇〇だ
  ＞記述要素
  　▶事柄の分類 ＝ 概念クラス
  　▶事柄の性質の分類 ＝ 概念クラスの特徴値
  　▶事柄の間の意味的つながりの分類 ＝ リレーションシップ
  　▶データ型 ＝ 特徴値の値を規定
• 圏C は圏Iに対して圏同値であり、圏Iのスキーマ圏である
  ＞圏I は意味の場の圏S と自然同値なので、結果的に圏Cは圏Sのスキーマ圏となる
• 圏Cのモデルは、どちらも概念ドメイン（意味の場）ごとに一つずつ記述する
  ＞概念ドメインの意味の枠組みの詳細な記述 ＝ 概念情報モデルである
  ＞圏C のモデルは、ウィトゲンシュタインの“論理空間”に相当する

もちろん、どちらも、概念ドメイン（意味の場）ごとに作成するのが前提であることをお忘れなく。

次回は、概念情報モデルを基盤とした、概念ドメインの状態の更新や参照について解説します。