【連載】概念モデリングを習得しよう：圏Iのモデルにおける、特徴値のデータ型（第8回）

圏Iのモデルは、モデル化対象の「意味の場」の状態のスナップショットなので、概念インスタンスの特徴値の値は全て確定しています。そして、それらの値は何らかの単位を持っています。同じ１でも、1kg なのか 1￡なのか、はたまた、1m なのか 1ft なのかで、まったく意味が変わってしまうため、単位の明示はとても重要です。

さまざまな意味の場においては、単位を持つ数値以外のなんらかの値を持つ特徴値も頻出します。概念モデリングでは、それらの値を規定するものを“データ型（data type）”とまとめて呼ぶことにします。

これまで何度も、圏Iのモデルを構成する概念インスタンス、特徴値、リンクは、モデル化対象の意味の場において抽出せよと、繰り返してきました。データ型も同様に、モデル化対象の意味の場にふさわしい、データ型の名前と、必要であればその単位を決めることになります。それらの大まかな分類は以下の通りです。

1. 量や長さ、個数などの数値
2. 列挙型
3. 文字列
4. 識別子型
5. 1～3を組み合わせた複合型

1番目の量や長さは、さらに整数と実数の2種類に分かれます。個数の場合は、0以上の整数量や長さは必ず単位を持つため、それも併せて明確な定義が必要です。量や長さは、単位が同じならば、大小比較や四則演算が可能です。圏論では量圏として定義されています。

２番目の列挙型は、有限個の値の集合として定義されます。赤や青、黄といったリンゴの色などがこれに該当します。列挙の値は量や長さとは異なり、大小比較や四則演算はできません。このようなデータ型を列挙型（enumerated data type）と呼び、列挙型の構成要素を列挙子（enumeration）と呼びます。

３番目の文字列型は、有限の文字の列が値になります。この場合、モデル化対象の意味の場において、文字の並びを規定するフォーマットがある場合には、そちらも併せて定義します。文字列は、同じデータ型である場合に限り、文字列同士をつなげたり、重複部分を削除したりといった演算が可能な場合もあります。

前の例で示したように、一見すると一塊の文字列に見える値が、複数のデータ型の組み合わせになっているものもあります。このような場合は、文字列を構成する基本単位を特徴値として切り出すことを推奨します。特徴値を独立させた上で、ひと固まりの文字列としての扱いに意味があるなら、算術的な特徴値であると認識しましょう。

文字列の中には、日時のように、”2024/08/08-10:59:30“などと記載されるものがありますが、このような場合は、見た目の文字列として考えるのではなく、ある特有の意味を持つデータ型として考えるようにします。そのような特徴値を圏Iの要素として抽出したからには、ひも付いている概念インスタンスの特性として、日時という概念がモデル化対象の意味の場において重要ということを意味しているからです。

４番目の識別子型は、以前取り上げた、人為的な識別用の特性値を持たないような廉価のリンゴを識別するために定義した特性値の型です。概念モデリングにおいて、この特性値の値は、“概念インスタンスごとに異なっていること”だけが重要です。このような条件を満たすようなデータ型を概念モデリングでは識別子型と呼びます。実際の値は、連番の数字でも、異なる文字列でも構いません。

5番目は、速度や加速度など、複数の値がまとまって、意味の場的に一つの意味になるデータの型です。概念モデリングでは複合データ型（complex data type）と呼びます。他にも位置を表す緯度＆経度の組なども複合データ型です。

複合データ型は、モデル化対象の意味の場から拾い上げた、概念インスタンスの性質を表す存在をデータで記述しようとした時に、一つのデータだけでは意味を成さない場合に限って定義するデータ型です。プログラミングに慣れた読者の中には、複数の特徴値を束ねるように見える概念インスタンスもまた、複合データ型ではないかと疑問に感じる人がいるかもしれませんが、見た目がそういう風に見えるだけで、まったく異なる概念であることに注意してください。極端な話をすれば、概念モデリング中は、プログラミングのことは一切忘れるようにした方が望ましいでしょう。

さて、時間にしろ、位置にしろ、速度にしろ、圏Iのモデルの作成中は、それらのデータがどうやって測定されるのか、気になって仕方がない読者が一定数以上いることと思います。特に技術系の読者に多いのではないでしょうか。しかし、必要以上の深入りは避け、モデル化対象の意味の場だけに専念するのが概念モデリングの流儀であると思ってください。

例に挙げた果物屋や果樹園では、時間というデータ型を持つ特徴値が定義されています。この特徴値は、その意味の場において、“いつだったかという値”を保持していることだけが重要で、そのデータがどんなふうに計測されたかについては関心がありません。この意味の場において、時間の計測は、作業者の腕時計の表示でも、なんらかの機器（果物屋であればPOS端末など、果樹園であれば農耕機など）の内部時計による計測でも、対象の意味の場において問題ない程度の精度があれば十分です。

物理学の実験では、計測の誤差や偏差は大きな関心事です。しかし、本来なら実現確率や統計誤差を付つけて値を示さなければならないはずのビジネス上の年度売り上げ目標や、業務計画にそんな値がないことに誰も関心を示さないのと事情は同じです。大学時代、物理学先行だった筆者からすると、それはそれでとても不思議ではあったのですが……（苦笑）。

時間計測について話を戻すと、モデル化対象の意味の場が、精密時計やネットワーク上のノード群の時間合わせや、GPS制御といった、計測方法そのものが対象とする場合を除き、手段を問わず値は決まっていると考えれば十分です。

許される誤差は、圏Iのモデルが対象とする意味の場によって定まります。必要であれば、データ型の定義で記述しておくことにします。

そう言われても気になる……というコアな技術屋の性質を持った読者もいることと思いますので、もう少しだけ続けさせてください。

時間などの計測方法を無視して構わないのは、あくまでも、果物屋や果樹園といった意味の場を対象にして概念モデリングを行っているからです（図表１）。時間や位置、速度などの計測は、それぞれの意味の場を対象とした、別のモデルとして扱うのが概念モデリングの流儀です。最終的には、それぞれで作られた概念モデルの要素を対応付けて、コンピューティングリソースの上で実際に動作するソフトウェアを生成することになります。

このトピックの詳細は、本連載コラムのずっと後の方で、解説を予定しています。楽しみにしていてくださいね。

次回は、概念モデリングにおけるリンクに関して、二項リンクと関連リンクを解説します。