代表的な共通パターンはモノ（インスタンス）、モノのタイプ（型）、およびカテゴリ（種類）間のリレーションシップです。モノ（インスタンス）は実物で、モノのタイプ（型）は実物の類似した属性をまとめたテンプレートです。たとえば、車両運搬具という資産タイプがあり、その実物である資産はシリアル番号1番の○×社製大型トラックなどです。

「企業とその世界」で説明したように、企業の人やモノは物理的にどこかに配置される対象となります。地理的位置は国、都道府県、市区町村などと階層化され、複雑な組み合わせが必要になる場合があります。ここでは概念モデル レベルなので、再帰関係を使いシンプルにモデル化します。論理レベルに落とし込むときに詳細な対象ビジネスの用途にあった住所モデルを設計する必要があります。

演劇モデルに住所パターンを適用します。ここでは、どこで製作が行われるかを管理するために、製作とサイトを関連付けます。製作された場所で演技が行われるとします。役者は各地を巡業して回るので、位置情報を管理するのが大変です。したがって、ここでは役者の位置情報については管理しないと考えます。

「企業における活動」で説明したように、企業では活動や作業を割り当てる前に、これらを実行するパーティのロールタイプ（役割タイプ）を定義します。このパターンを適用すると、同一の人や組織を複数の企業活動を異なったロールに設定することもできます。たとえば、社長が定常業務を行いながらプロジェクト リーダーとして新規事業立ち上げ活動を行う場合です。

演劇モデルにロール（役割）パターンを適用します。演劇タイプには登場人物が定義されます。演劇ロールでは誰がどの登場人物を演じるかを管理します。場合によっては同一人物が同じ演劇で織田信長と徳川家康を演じるかもしれません。冗長しないように演劇ロールから演技および製作への関連はいずれかのみの排他的関連となります。

経営者は、リソース（経営資源）がどの程度消費されているかについて関心があります。リソース パターンを適用することで、人件費や資産の消費を管理できます。

演劇モデルにリソース パターンを適用します。ここでは、小道具がどの程度使用（消費）されているかを管理します。

同一のエンティティを構成する関係（リレーションシップ）を管理する必要があります。たとえば、誰が誰に報告をするのかといった報告関係や、活動の順序関係などです。

演劇モデルにリレーションシップ パターンを適用します。登場人物の関係を表現します。たとえば、主人公の山田さんは、鈴木さんの義理の母で斎藤さんの妹という関係です。

属性が異なるエンティティを管理する場合は、メタデータである属性をエンティティとして使用します。たとえば、資産タイプにポンプとドリルがある場合です。ポンプの属性には排出容量がありますが、ドリルの属性には穴あけ能力があり、両方で属性を共有することはできません。ここでは、メタデータ パターンを資産タイプと銀行口座に適用します。

通常は一人が脚本を書きますが、たまに複数の人が脚本を書く場合があります。この問題に対応するために、演劇モデルに著者エンティティを追加します。ここで、人から演劇タイプへの関連はそのまま残します。一見、冗長に見えますが、通常の関係は残します。人⇔演劇タイプ、および著者⇔演劇タイプはいずれか1つだけしか存在できないので、排他的関連をなります。

これまでの共通パターンを使えば我々の世界（ユニバース）をデータモデルとして表現できます。「Data Model Patterns」の著者であるDavid C. Hay氏は、「世界はメビウスの帯である。」と表現しています。一見、二次元的な表面にしか見えなくても、実は三次元的に繋がっているということです。この世界を表現するデータモデルもエンティティが三次元的に繋がっています。この程度のエンティティ数で世界は表現できないと思われる方は、「私達は0と1のみで世界を表現できること」という言葉を思い出してください。

これらの共通パターンを駆使して演劇モデルの最終形が完成しました。「世界を表現するモデル」と類似していることに気づかれたかもしれません。理由は、両モデルとも共通パターンを使って作成されているからです。「演劇モデル最終形」はメタモデルである「世界を表現するモデル」を演劇というドメインに適用されたと考えると、「世界が舞台」であると言えるでしょう。