パート2–大規模なデータベース図を整理する方法

このシリーズのパート1では、SuiteCRMデータベース構造をオンラインデータベースモデリングツールに正常にインポートしました。そのとき、モデルには関係のない201個のテーブルが含まれていることがわかりました。私たちは本当に散らかっているように見えるたくさんのテーブルを手に入れました。この記事では、このような大きなモデルを整理する方法を紹介します。

Vertabeloにインポートした直後、SuiteCRMデータベースモデルは次のようになります。

モデルは機能しますが、効率的ではありません。本当に役立つように変更する必要があります。 SuiteCRMデータベースを後に分析したいのでアクションはGUIで実行されるため、テーブル定義とテーブル間の関係を理解する必要があります。まず、テーブルをサブジェクトエリアにグループ化し、最も重要な関係を確立することから始めましょう。

Vertabeloは、大きな図を整理するのに役立つ3つの主要なツールを提供します。

主題分野
テーブルとビューのショートカット
参照ショートカット

この記事の後半で説明しますが、このビデオを見てさらに学ぶこともできます。

ステップ1.外部キーの自動生成を無効にする

まず、外部キーの自動生成を無効にします。デフォルトでは、プライマリテーブルから参照テーブルにリレーションをプルすると、Vertabeloは外部キー属性を生成します。これは通常は良いことですが、ここではそうではありません。外部キーを表す属性はすでにあります。私たちに欠けているのは、テーブル間の「実際の」関係です。このオプションをオフにするには、[マイアカウント]をクリックしますトップメニューで「個人設定」を見つけますセクション。

オプションはオフです。これで、テーブル間に参照線を引くと線が作成されますが、プライマリ側と外部側の両方で使用する属性を指定する必要があります。

ステップ2.プレフィックス付きテーブルをサブジェクトエリアでグループ化する

次に、いくつかのテーブルをグループ化します。これは、件名領域を使用して行います選択した基準に基づいてテーブルを関連付けることができるツール。この例では、関連するか、同じプロセスの一部であるテーブルを特定しようとしています。これにより、「通話」、「会議」、「キャンペーン」などのグループが作成されます。

[新しい領域を追加]をクリックすると、サブジェクト領域を作成できます。ツールボックスのアイコン：

次に、モデルに長方形を描画します：

サブジェクトエリアが作成されます。 「モデル構造」で確認できます。左側のパネル：

各サブジェクトエリアには、その境界内にあるすべてのオブジェクトのリストが含まれています。この場合、これらはテーブルと参照型です。

SuiteCRMには、共通のプレフィックスを共有する多くのテーブルがあります。そこで、プレフィックス付きのテーブルをグループ化し始めました。例として「acl」テーブルを見てください。「モデル構造」パネルで、名前が「acl _」で始まるすべてのテーブルを見つけました：

次に、モデルに「acl」サブジェクト領域を作成し、適切なすべてのテーブルをその領域にドラッグしました。（見やすくするために、背景色を紫に設定しました。）

これで、「サブジェクトエリア」の下に、それに属するすべてのテーブルのリストを含む「acl」グループが表示されます。 「モデル構造」 ：

残りのすべてのプレフィックス付きテーブルに対して同じ手順を繰り返しました。

ステップ3：残りのテーブルを配置します。

図の2回同じ表？テーブルのショートカット！

約80のプレフィックス付きテーブルがあります。それらをグループ化した後、私は約120の「ワイルド」テーブルを残されました。これらは意味があります。ユーザー、クライアント、通話、会議、その他のCRMに関する情報を保存します。これは大規模な情報であるため、これらのテーブルを並べ替えてみましょう。

これらのテーブルを配置するのに最も役立つと思った機能は、テーブルショートカットと呼ばれます。。モデルで同じテーブルを複数回使用したい場合があります。（なぜですか？モデルをフラットにして重複を避けるためです。）「コピー」を使用すると、これを簡単に行うことができます。および「ショートカットとして貼り付け」 ボタン。

ショートカットを作成するテーブルを選択し、[コピー]をクリックするだけです。上部のツールバーで（または Ctrl + Cを押します）：

ショートカットを作成するには、[ショートカットとして貼り付け]をクリックします （または Ctrl + Kを押します）。その後、輪郭が点線の新しいテーブルが表示されます：

これはではありません テーブルのコピーですが、元のテーブルの別のインスタンスです。モデルのどこにでも配置できます。参照の重複を避けるために、異なるサブジェクト領域で同じテーブルのインスタンスを使用しました。すべてのテーブルインスタンスには、そのサブジェクトエリア内にある間、（名前の横に）サブジェクトエリア名が割り当てられていることに注意してください。

これがどのように機能するかの良い例は、usersです。テーブル。これは、「ユーザーとアカウント」、「ロール」、「ドキュメント」、およびその他のサブジェクト領域にあります。これはモデルの後半で確認します。

テーブル間に確立された関係を持つサブジェクトエリアを作成するときは、テーブルショートカットを幅広く使用します。これがどのように機能するかを確認するには、以下にマップされている「Opportunities」サブジェクトエリアを見てください。そのサブジェクトエリア内のすべてのテーブルは、次のルールに従って名前が付けられていることに注意してください。 {テーブル名}：{サブジェクトエリア名} 。

{サブジェクトエリア名}を展開すると [モデル構造]パネルでは、テーブルと参照が含まれていることがはっきりとわかります。

これは、「電話」、「ケース」、「キャンペーン」、「連絡先」、「ドキュメント」、「会議とリード」、「oauth」、「プロジェクト」、「見込み客とメールマーケティング」、「ロール」、および「ユーザーとアカウント」。これらの領域はすべて水色の背景を共有しています。

残りのテーブルは、名前と推定される意味に基づいてグループ化されています：「Emails」、「Users（extra）」、および「Othertables」。これらのグループの背景色は明るい赤に設定されています。

ナビゲーションツリーでテーブル名をダブルクリックすると、ビューはモデル内のそのテーブルにズームして選択します。マウスホイールを回してズームインすると、ビューはマウスポインタの方向にズームインします。

配置されたモデル

前述のオプションを使用して、テーブルを論理的にグループ化しながら、モデルを可能な限りフラット化しました。結果は26のサブジェクト領域であり、そのうちのいくつかにはテーブルのみが含まれ、その他にはテーブルとリレーションが含まれます。各カテゴリを簡単に確認しましょう：

テーブルとリレーションを含むサブジェクトエリア：

「電話」、「キャンペーン」、「ケース」、「連絡先」、「ドキュメント」、「会議とリード」、「機会」、「プロジェクト」、「見込み客とメールマーケティング」、「役割」、「ユーザーとアカウント」

すべての関係は必須ではないものとして設定されています。これにより、これらのテーブルがどの属性を介して関連しているかという情報が保持されます。

テーブルのみを含むサブジェクトエリア：

「acl」、「am」、「aod」、「aok」、「aop」、「aor」、「aos」、「aow」、「Emails」、「fp」、「jwg」、「oauth」、「security_groups 」、「追加のユーザー」

これは、関係がここに存在しないという意味ではありません。強調されていないだけです。

「その他のテーブル」のサブジェクト領域は、特定のグループに実際には当てはまらないテーブル用です。

モデルはどのように見えますか？

再配置されたモデルは次のようになります：

明らかに、命名規則が使用されています。従ったガイドラインの概要は次のとおりです。

テーブル名はほとんど複数形です：users 、contracts 、folders 、roles 、tasks 。 projectなど、一部のテーブル名は単数形です。
ほとんどのテーブルの主キーは、単にidと呼ばれます。 char（36）タイプです。
1対多の関係が発生する場合、外部キーの名前は通常parent_idです。。（例：contacts_audit.parent_id contacts.idへの参照です。）
多対多の関係では、「parent_id 」を複数の列の名前として使用することはできません。代わりに、接尾辞「_id」が付いた単一のテーブル名が使用されます。（例：contacts_bugs.bug_id bug.idへの参照です。）
同じ列が複数のテーブルの外部キーとして使用される場合があります。（例：calls.parent_id 次の各テーブルのid列を参照しています。accounts 、bugs 、cases 、contacts 、leads 、tasks 、opportunities and prospects 。データベースの値を確認していませんが、これらのテーブルには同じキー値がないのではないかと思います。すべてchar（36）タイプであるため、おそらくテーブル名と自動インクリメントの組み合わせが使用されます。今後の記事で確認します。）
異なるテーブルで同じ意味を持つ列に同じ名前を使用します。（例：modified_user_id 、created_by およびassigned_user_id モデルの多くのテーブルにあります。それらはすべてusers.idを参照しています。）

次は何ですか？

今後の記事では、SuiteCRM GUIを使用して、これがデータベース内で引き起こす変更に注目します。その情報を使用して、モデルに変更を加え、サブジェクトエリアを再編成し、必要に応じて接続を確立しようとします。また、主キーの生成方法など、他のSuiteCRM固有のルールも探します。

大規模なデータベース図の処理は決して簡単な作業ではありません。家のための良い基盤を構築するように、今ファンダメンタルズにより多くの時間を費やすことは後で利点をもたらすでしょう。 SuiteCRMの背後にあるようなモデルを分析する場合は、モデル構造を整理してテーブルの関係を定義する前に分析することで、Sisyphusスタイルを実行します。