Salesforceのデータモデリング手法の記事のリンク

@hatsanhatさんの記事「データモデリングしてますか？」がとても参考になるのでメモ。
詳しくは下記の記事を参照。

【参考１】
データモデリングしてますか？ - TECH BLOG | 株式会社テラスカイ

参考になった箇所は下記の通り。
サロゲートキーだけの開発環境の場合、「複合キーの制約をNotNull制約と更新不可制約で実現する」点が参考になる。

(引用開始)
スキーマビルダーで描画すればそのまま実装も出来るところは大変便利ですが、データモデル構造だけをシンプルに見たいという用途には向きません。
そこで筆者はオープンソースのモデリングツール「X-TEA（エクスティ） Modeler」を使用しています。
モデリングツールは何種類か試しましたが、１：Ｎの関係を親子関係と参照関係で明示的に表現出来る事と、項目に「更新不可属性」を設定出来る（何故必要かは後述）ためこのツールを重宝しています（作者に感謝）。
(中略)

顧客・顧客担当者・商談だけを関係付けたデータモデルです。
「顧客」と「顧客担当者」の間は鳥の足のような特徴的な線で結ばれています。
これが親子関係を表します。

「顧客担当者」と「商談」の間は先が点々になっています。
これは同じ１：ＮでもＮ側にＮｕｌｌを許す参照関係を表しています。

この２つの書き分けが出来るツールは珍しいのでSalesforceに向いています。
(引用終了)

(引用開始)
本当に複雑なデータモデルの時に主キーも正確に表したい時は、外部キー（foreign key）を使います。
複合主キーと外部キーの違いはNotNull制約と更新不可制約だけです。

・主キーはSalesfordeIdの単独主キーとする
・複合主キーとしたい他の項目はNotNULL制約＋更新不可制約を付ける
（このためにX-TEA Modelerの「更新不可属性」が必要になります）
(引用終了)

(引用開始)
顧客オブジェクトの先頭の項目「011-id」は顧客オブジェクト(011)のSalesforceIdを示しています。
SalesforceIdとはオブジェクトの各レコードに一意に付けられる番号です。
この値を見れば、会社の中でレコードを1つに特定出来ます。
一般に言う「オブジェクトキー」とほぼ同じです。
Salesforceはこの値をURLに指定するとレコードを検索出来るという奇跡のようなURI設計（笑）になっています。
(引用終了)

【参考２】
あわせて、渡辺さんのBlogとさかばさんのBlogも参考になるのでメモ。
特に、さかばさんの指摘「RDBだから複合キーを使わずに実装できてしまう。モデリングの問題(注：実装と対比して、設計の問題という意味と推測)ではなく実装の問題です」も参考になる。

単独主キーでもDB設計は楽にならない: 設計者の発言

「単独主キー専用環境」と賢くつきあうために: 設計者の発言

複合主キーの扱い方: ソフトウェアさかば

(引用開始)
RDBなのに複合主キーを使わないのではなく、RDBだからサロゲートキーを作りやすいので、複合キーを使わない開発が簡単にできてしまうのだと思います。

つまり、単独主キーで開発を安易に行うことが問題です。

本来、複合主キーで表現されるデータをどう扱うかは、モデリングの問題ではなく実装の問題です。

複合主キーを使わないのは実装の都合なので、そこにある危険性を周知することが重要だと思います。
(引用終了)