今でも データモデリング してますか？

ワクチン接種が広がりつつあり、コロナ禍も落ち着くと期待されています。その予約システムが市町村コードすらチェックしてなかったというニュースが流れていました。今回は「巧遅拙速を尊ぶ」という精神でつくられたシステムでしょうから、ある意味仕方がなかったと思います。本当のところはわかりませんが、紙に入力して提出するという、アクター２のシステムを作ったのだと思いました。

アクターとはユースケース図（USE CASE diagram）の用語です。システムの中でユーザが果たす役割を表します。人間だけでなく、ハードウェア、外部システムなどがアクターになります。システムが存在しない場合を考えてみましょう。必要事項を紙に書いて提出するか、FAXで送付します。受け取った人間がチェックして、記入内容がOKなら予約表で空いているかを確認して予約を受け付けます。紙に書く段階で自動でチェックすることはできませんよね？これをエミュレーションしたシステムだと考えると理解できます。

ワクチン接種予約を「アクター２」で作るというのはこういう意味です。

このようにアクター３以上のシステムは、他の役割を含めた俯瞰した目がないと設計ができません。つまりデータモデルを基礎とする情報管理システムなのです。私が主催しているIT勉強会では＜「新型コロナワクチン接種管理システム」をローコード開発してみた＞というイベントでデータモデルを公開して動くシステムも無料公開したのですが、残念です。

「私、失敗しないので」というドラマがありましたね。Salesforceという基盤を使うと、手作りプログラムと比べて圧倒的に失敗しにくいプロジェクトになります。その理由は明白です。データモデルがないとプロジェクトが開始しないためです。データモデルが決まらずにプロジェクトがスタートしないことはありますが、データモデルが決まれば開発に失敗することはほとんどありません。
ではそのデータモデルとは何でしょうか？前回、「データモデリングしてますか？」というブログを書きました。つい先日書いたような気になってましたが、調べると4年も前でした。歳を取るのは嫌ですね。難しいと何人かからクレームをいただいたこともありますので、今回は初級編としてデータモデルの入口にお連れしたいと思います。
最も重要な2つの原則を述べます。データモデリングはこの2つを知らないと始まらないほど重要ですが、聞いたことがない方が多いと思います。他のことは全部忘れても良いので、この2つだけは覚えて帰って下さい。

オブジェクトであっても項目であっても、１つの事実を表すものは１箇所に記述せよという原則です。すべての設計の通奏低音として響きます。20年近く前にこの世界の有名人の椿正明さんと飲みに行くと、よくこの言葉を言われました。このブログを書くに当たりこの言葉のルーツを調べましたがよくわかりませんでした。椿氏の本（名人椿正明が教えるシステム分析・モデリング100の処方箋P.142）ではRDBを発明したE.F.コッド氏の12のルールを椿氏が解釈した言葉として載っていました。椿氏の言葉なのかもしれません。
気をつけなければならないのは、この「fact」という深みです。例えば商品単価という「fact」を一箇所に持つのでしょうか？それが正しいとは限りませんよね。売上伝票にこの単価をどう持つかについて少なくとも3つのパターンがあります。One Fact in One Placeを誤って解釈すると①になってしまいます。
今回のシステムはどれにするのかを決定する行為が設計です。椿氏が提唱したTHモデルでは項目がどのパターンかを示す記号が定義されていました。

　　　　①商品マスタの参照（=数式）とする　　　　　　→単価変更のときどうするの？
　　　　②売上伝票にコピーするが変更不可とする　　　　→受注時点の金額を持つ
　　　　③売上伝票にコピーして変更可能とする　　　　　→値引／割引との関連は？

主キーが決まると、どの項目が決まるのかを見定めて、それをオブジェクトとするという考え方です。Salesforceの場合、物理的な主キーはSalesforceIDですが、モデリングする時には論理的な主キーを考えてオブジェクトを定義します。次に解説する「リレーションシップ」と混同して覚えている方もいらっしゃいますが、全く違います。
こう教えられたことがあります。「全部の項目を広場にば～っとばらまきます。主キーになりそうな項目（候補キー）を１つ持ち上げると、それにくっついてツルツルっと上がってくる項目を関数従属しているといいます。それがエンティティです。」また、「おいでおいですると集まってくる」と表現される方もいました。
かんたんな例では＜社員番号　→　社員名＞がわかりやすいでしょう。ｙ＝ｆ（ｘ）のｘが社員番号でｙが社員名です。オブジェクトの項目を読む時に「それは主キーと関数従属しているか？」を常に意識しましょう。これさえ意識すれば最低でも第３正規形になっているはずです。

データモデリングできる人が、無意識に使う３つの単語があります。大したことは言ってませんので怖がらずに使いましょう。

１）エンティティ（Entity）
モデルの管理対象のことです。Salesforceでは「オブジェクト」ですが、厳密に言うと選択リスト値セット（昔のグローバル選択リスト）や、静的リソース、カスタム表示ラベル、カスタムメタデータ型などもエンティティと考えるべきです。

２）属性（Atribute、アトリビュート）
データ項目のことです。実はこの項目名の決め方を見ると、その技術者がデータモデルを理解しているかどうか一目瞭然になります。プログラムで項目名をつけるのが難しいのと同様に、項目名の付け方は重要な設計要素です。後で解説します。この属性の型をドメインと呼びます。例えば売上を8桁通貨としたり10桁数値としたりバラバラだと扱いにくくなるため「売上ドメインは通貨10桁」と定義します。ただ、ドメイン駆動設計が広がってから誤解されやすくなったためこの言葉はあまり使わなくなりました。悪貨は良貨を駆逐するというところでしょうか。

３）リレーションシップ（Relationship）
エンティティ間の関係を示すものです。「リレーション（Relation）」はきっちりとした関数という意味ですが「リレーションシップ」はもう少しゆるい関係と訳します。これにはカーディナリティ（CARDINALITY、多重度）が重要になります。これも後で説明しましょう。

ＥＲ（Entity Relationship）図とは、「データベース設計（データモデリング）で使う設計手法」です。設計手法という言葉を使うと「いや、単なる記法である」と過剰反応される方もいらっしゃいますが、ここでは設計手法のひとつだと緩く理解しましょう。ただしＥＲ図と呼んでしまうと表記法が厳格に決まっています。そこでSalesforce界隈の業界用語として「オブジェクト構成図」と呼ぶことが多いようです。私もあえてそう呼んでます。基本的にはER図を簡略化したものです。

ＥＲ図には多くの記法があります。前回のブログでは三要素分析法で記述しましたが、多く使われいるのは「ＩＤＥＦ１Ｘ記法」と「ＩＥ記法」です。三要素分析法はＩＥ記法を発展させたものです。Salesforceは「スキーマビルダー」というＥＲ図を自動作成する機能が標準であります。そこではＩＥ記法が採用されています。ただ、パワーポイントなどで作図する時はIDEF1Xの方が簡単に描けます。

＜IDEF1X(Integration DEFinition 1st edition eXtended)記法＞
米国のNIST（国立標準技術研究所）によってFIPS（連邦情報処理標準）として標準化されたモデル記述言語です。
＜IE(Information Engineering）記法
ジェームズ・マーティン氏が提唱したモデリング手法で用いられた記法です。「カラスの足」とも呼ばれます。

※カッコ内はSalesforce用語です

１）依存関係（主従関係）
取引先と取引先責任者のように、子エンティティが親エンティティに依存しているものを依存関係と呼びます。Salesforceでは主従関係です。
レコード共有範囲も親に依存します。親を消すと子も削除されます。（カスケード）
取引先には複数の取引先責任者があります。取引先責任者は取引先なしでは存在しません。（無理に設定すればできますが特殊なレコードができてしまいます。主従関係ならできません）

２）非依存関係（参照関係）
組織と社員のように、対応する親エンティティがない場合を許すとき、非依存関係と呼びます。Salesforceでは参照関係です。１人も社員がいない組織があります。どの組織にも所属しない社員を許します（新入社員、パートなど）

３）多対応関係
N:Nを実装することは可能ですが、それでは運用できないシステムになります。分析が足らないと考えましょう。Salesforceでは連結オブジェクトという便利な特殊オブジェクトがあります。ここでは詳しくは説明しませんが、それを使います。

４）分類関係（レコードタイプ）
サブセットと呼ぶこともあります。Salesforceでは１つのオブジェクトをレコードタイプで分割することが多いでしょう。

カーディナリティを網羅した例を次に挙げます。読み取れるでしょうか？

同じ実体を違う名称で呼ぶことを「シノニム（異名同義語）」と呼びます。「宵の明星」と「明けの明星」が同じ金星を表すようなものです。工場でつくったものを配送センター経由で送るとき、工場の「出庫予定日」は配送センターの「入庫予定日」になります。部署が違うと呼び方が違うことは普通ですので、それを統一する必要はありません。ただシステム上の呼び名は同じにしましょうということです。
また逆に、同じ言葉で違うものを表すことを「ホノニム（同音異義語）」と呼びます。Salesforceではありがちですが、「金額」という項目が商談金額、見積金額、仕入金額のいずれをさすのか分からないようなものです。
表示名はお客様がわかりやすいようにすれば良いのですが、API参照名はできる限りユニークになるようにつけます。これらを意識して付けましょう。ネーミング標準は企業の数だけあります。
ここでは古典的な「主要語（Prime)、修飾語（Qualifire)、分類区分語（Class)」の組み合わせのネーミング標準を紹介します。

１．主要語（Prime)、修飾語（Qualifire)、分類区分語（Class)の組み合わせで項目名とする
２．各単語の間に連結子は付けない
３．日本語では[Q] + P + C とする（例：日別商談金額）
４．各語は「データ項目構成単語帳」から選ぶ。ない場合は登録する。
５．各語の論理名に対応したローマ字名をつけ、API参照名として採用する

どうでしょうか。データモデリングの入り口に立てたでしょうか？今回ご説明した内容が実践できるようになれば、前回私が書いたブログを読んでみて下さい。

ではまた。