PowerDesigner は、データベースモデル設計のほぼすべてのプロセスを含むシステムの分析と設計に便利に使用できる、Sybase Corporation のソフトウェアです。PowerDesigner を使用して、データフロー図、概念データモデル、物理データモデル、およびオブジェクト指向モデルを作成します。これらのモデルの出力は、標準の開発プロセスで正式なコーディングを行う前に完了する必要がある作業でもあります。(以下、PowerDesignerをpdと呼びます)

2.1 PowerDesigner のコア機能

2.1.1 複数のモデリング機能の統合

データモデル (E/R、Merise) エンティティ関係図。
ビジネスモデル (BPMN、BPEL、ebXML)。
アプリケーションモデル (UML)。

2.1.2 自動コード生成機能

PowerDesigner は、データモデルを通じて次のようなさまざまなコードを生成できます。

SQL スクリプト (mysql、pg、oracle など、50 を超えるデータベースシステムをサポート)。データベースに直接インポートして使用できます。
Java は、オブジェクト指向モデリングを通じて、簡単な変更で使用できる基本的な Java オブジェクトエンティティクラスファイルを迅速に出力できます。
.NETなど...

2.1.3 強力なリバースエンジニアリング機能

PowerDesigner を使用すると、言語やデータベースを越えてライブラリテーブルを設計、変換、移行でき、設計のための mysql へのオンライン接続をサポートするなど、非常に実用的な機能です。

2.1.4 スケーラブルなエンタープライズライブラリソリューション

強力なセキュリティとバージョン管理機能により、マルチユーザーの共同設計をサポートできます。

2.2 PowerDesigner で一般的に使用されるいくつかのモデル

実際に pd を使用し始める前に、pd が提供するいくつかのコアモデルを包括的に理解する必要があります。

2.2.1 概念モデル

概念データモデル (CDM)。CDM は、ソフトウェアやデータストレージ構造から独立した、データベースの全体的な論理構造を表します。

概念モデルには、物理データベースにまだ実装されていないデータオブジェクトが含まれることがよくあります。
これは、プログラムまたはビジネス活動を実行するデータの正式な表現を提供します。
概念的なデータモデルは、データストレージに対するエンドユーザーの見解であり、ユーザーの包括的な情報ニーズを反映しています。
物理的な実装の詳細に関係なく、エンティティ間の関係のみが考慮されます。

CDM はシステム分析フェーズに適したツールです。

2.2.2 論理データモデル

情報システムの構造の分析に役立つ論理データモデル (LDM) も、特定の物理データベースの実装には依存しません。

LDM は概念データモデル (CDM) よりも具体的ですが、ビュー、インデックス、および物理データモデル (PDM) で処理されるその他の詳細を定義することはできません。論理データモデルはデータベース設計の中間ステップとみなすことができ、概念データモデルと物理データモデルの間にあります。

2.2.3 物理モデル

物理モデル (PDM) は、物理構造とデータクエリを詳細に定義するために使用されるデータベース設計ツールです。設計されているターゲットデータベースの種類に応じて、PDM ではさまざまな種類の図を使用できます。

主な目的は、CDM で確立された現実世界モデルから特定の DBMS スクリプトを生成し、データベースに情報を保存するためのストレージ構造を生成し、データベース内のデータの整合性と一貫性を確保することです。PDMはシステム設計フェーズに適したツールです。

2.2.4 オブジェクト指向モデル

オブジェクト指向モデル (OOM)。開発言語としての Java のモデル設計に必要なモデルです。具体的には、

OOM は、一連のパッケージ、クラス、インターフェイス、およびそれらの関係で構成されます。
これらのオブジェクトは一緒になって、ソフトウェアシステムの論理設計ビューのすべて (またはその一部) のクラス構造を形成します。
OOM は本質的にソフトウェアシステムの静的な概念モデルです。

OOM には、ユースケース図、シーケンス図、クラス図が含まれており、最後に、モデルウェアハウス (リポジトリ)、モデルレポート (レポート)、データベース SQL スクリプト、ユーザーデータベース構造、およびアプリケーションコード。

2.2.5 ビジネスプロセスモデル

ビジネスプロセスモデルはBPMです。BPMは、ビジネスのさまざまな内部タスクと内部プロセスを記述します。ユーザーは、BPMモデルを通じて、これらのタスクとプロセスの関係と相互影響を明確に確認できます。

BPM は、ビジネスロジックとルールをビジネス担当者の観点から詳細に記述し、フローチャートを使用して 1 つ以上の開始点から終了点までの処理、プロセス、メッセージ、およびコラボレーションプロトコルを表す概念モデルです。
BPM を通じて、システムの動作と要件を記述し、オブジェクトの概念的な組織構造をグラフィカルに表現して、必要なドキュメントを生成できます。
概念的レベルのモジュールとして、BPM は、システム要件の分析とロジック設計を完了するアプリケーションシステムのシステム分析段階に適しています。

PowerDesigner BPM には 3 つのフロー図が含まれています

1) プロセス階層図: システムの機能を階層的に識別します。

2) ビジネスプロセス図 (ビジネスプロセス図): グループプロセスの具体的な実装メカニズムを分析するために使用されます。

3) プロセスサービス図：業務フローチャートを業務サービスの形式で表現します。

3、PowerDesignerのインストール

PowerDesigner の現在の主流バージョンは 16.5 であり、インストールの詳細については詳しく説明しませんが、オンラインのインストールチュートリアルが多数ありますので、興味のある学生は確認してください。

4 番目、PowerDesigner のコア機能の使用

現在、pd は非常に多くの機能を開発しており、川や湖のベテランであっても、pd に関わるすべての機能に携わることはできないかもしれません。実際、pd は主に、日常の開発におけるデータベース設計段階のデータベースモデリングに使用されます。実際には、コアデータベースモデリングだけでほとんどのシナリオに対応できます。次に、データベースモデリングに関連する技術的なポイントについて詳しく説明します。

4.1 データモデルの作成

テーブルを設計する前に、それを運ぶモデルが必要なので、まずデータモデルを作成する必要があります。

4.1.1 方法 1

ファイル -> 新しいモデル -> 新しい物理モデル経由。

4.1.2 方法 2

ファイルの下にあるアイコンをクリックして作成します

モデルを入力して [OK] をクリックすると、現在のプロジェクトスペースにモデルが作成されます。

4.2 データテーブルの作成

データモデルを作成したら、次のステップはテーブル構造を設計することです. 以降の操作指示を容易にするために、設計する必要があるテーブルがユーザーテーブル、ロールテーブル、 3 つのテーブルは、実際のビジネスシナリオにおけるユーザーとロールの関係を表しており、user、role、role_user の 3 つのテーブルです。

4.2.1 3 つのテーブルを作成する

右側のフローティングメニューでテーブルアイコンを選択し、作業領域をクリックするとテーブルが表示されます。ここでは 3 つのテーブルが必要なので、3 回クリックします。

4.2.2 3 つのテーブルのフィールドと属性を設定する

現在のテーブルをダブルクリックして、下のテーブルデザイン領域に入ります。そこには多くのメニューバーがあります。現在、主な焦点はテーブルのフィールドに関連するメニューです。

「列」メニューに入り、フィールドを設計します。各フィールドの属性設定には主に次のものが含まれます。

フィールドの設計が完了したら、[適用] をクリックして確認します。この時点で、ユーザーテーブルが設計されます。後でテーブルのフィールドを追加または変更する場合は、テーブルをダブルクリックして、次のインターフェイスに再度入ることができます。手術;

上記と同じ方法で、role テーブルと role_user テーブルを設計します。

4.3 テーブルの関連関係を設定する

現在のインターネットプロジェクトのデータベース設計では、外部キーの存在がその後のビジネスプロセス、特にデータ移行の際に多くの問題を引き起こすため、業界は主キーと外部キーの概念を徐々に薄めています。しかし、PD モデリング段階の重要な目的は、データテーブルを通じてテーブルの背後にあるビジネス関係を提示することであり、この関係は主キーと外部キーを通じて PD テーブルに反映される必要があります。

上記の 3 つの表を例にとると、ビジネスを理解している学生なら 3 つの関係がわかるかもしれませんが、他のビジネスについてはどうでしょうか。どうすればすぐに確認できるでしょうか? 3 つのテーブルの主キーと外部キーの関係を設定してみましょう。

4.3.1 ユーザーテーブルとロールテーブルの外部キーの設定

右側のアイコンをクリックして主キーと外部キーを設定します。2 つのテーブル間の関係を設定するときは、2 つのテーブルを線で結び、矢印の方向に注意するだけです。

一般に、接続を設定すると、pd は 2 つの間の主キーと外部キーの関係を自動的に検出します。上記の接続の効果から、接続が完了すると、ユーザーテーブル内のユーザー ID とロールはそれぞれ次のようになります。テーブルの ID では、fk ロゴが表示され、このフィールドが外部キーでもあることを示します。

外部キー関係が 2 つの間に実際に確立されていることを確認するにはどうすればよいでしょうか? 中央の接続をダブルクリックして [プレビュー] 列に切り替えると、そこに SQL ステートメントの行が表示されます。

SQL ステートメントは次のとおりです。この SQL が、テーブルの構築時に 2 つのテーブル間のカスケード関係を指定していることを理解するのは難しくありません。

alter table user add constraint FK_Reference_3 foreign key (id)
      references role_user (id) on delete restrict on update restrict;

4.3.2 主キーと外部キーのカスケード関係の変更

デフォルトでは、2 つのテーブルが主キーと外部キーを介して接続されている場合、データベーススクリプトを生成するときに、SQL を使用して 2 つのテーブル間の関係を指定しますが、デフォルトでは、このメソッドは、前述したように、強い関連関係に属します。実際の開発では、2 つのテーブルのバインド関係が強すぎると、その後のメンテナンスで問題が発生するため、望ましくありません。これには、このカスケード関係を手動で変更する必要があります。どうすればよいですか? ? 以下の手順に従ってください。

接続矢印をクリックして次のインターフェイスに入り、[なし] ラジオボックスをオンにして、[OK] をクリックします。

このステップを完了するだけでは不十分ですが、最終的に生成されるデータベーススクリプトで参照関係を設定する SQL も削除する必要があります。

PD を使用して外部キー関係を設定する場合、オンライン接続後に外部キーフィールドが正確でないか、外部キーフィールドを変更したい場合があります。このとき、次の設定の [結合] 列に切り替えることができます。

4.4 データベースのエクスポート

データテーブルを設計したら、次のステップはデータベースが実行できる SQL スクリプトをエクスポートすることです。これも pd では非常に簡単で、以下のステップに従うだけです。

4.4.1 SQLスクリプトのエクスポート

「データベース」→「データベースの生成」をクリックします。

エクスポートされた SQL の場所と名前を設定します。

「プレビュー」列には、元のテーブル作成 SQL が表示されます。

エクスポートが完了すると、ローカルデータディレクトリに元の SQL スクリプトファイルが表示されます。

4.4.2 SQLを使用してテーブルを作成する

上記の SQL を navicat にインポートします。

インポートが成功すると、次のテーブルが表示されます。また、navicat の逆関係マップを通じて、3 つのテーブル間の主キーと外部キーの関係を確認できます。

4.5 リバースエンジニアリング

4.5.1 リバースエンジニアリングとは

リバースエンジニアリング（リバーステクノロジーとも呼ばれます）は、製品設計技術の再現プロセス、つまり、対象製品を逆に分析および研究して、製品の処理フロー、組織構造、機能特性、および技術仕様を推定して取得することです。など、機能は似ているが同一ではない製品を製造するための要素を設計します。

4.5.2 リバースエンジニアリングの手順

[ファイル] -> [リバースエンジニアリング] -> [データベース] を選択します。ここで行うことは、リバースエンジニアリングを使用して外部 SQL スクリプトの設計を変更し、再エクスポートすることです。

次のインターフェイスに入り、名前を入力します

[OK] をクリックすると、ここでは 2 つの方法が提供されます。1 つは既存のデータベーススクリプトに基づくもので、もう 1 つは外部データソースを直接構成して接続する方法です。

ここでは、ローカル SQL スクリプトの使用を選択し、上でエクスポートした SQL ファイルを選択します。

[OK] をクリックすると、以前のデータテーブルモデルがインポートされたことがわかり、このモデルに基づいて設計と使用を続けることができます。

4.5.3 pd は外部データソースに接続します

SQL スクリプトのロードの問題を軽減するために、特に元の SQL ファイルのエクスポートが許可されていない場合には、外部データソースに直接接続できます。これは非常に実用的な方法です。具体的な操作手順は次のとおりです。以下に続きます。

[データベース] -> [接続の構成] をクリックします。

下のボタンをクリックしてデータソース接続を設定します。

[OK] をクリックした後、システムデータソースを選択します

次のページをクリックした後、Mysql ODBC を選択します (これには落とし穴があり、これについては後で説明します)。他のデータソースに接続する場合は、対応するドライバーを選択するだけです。

最後に、次のインターフェイスに移動し、データソース接続の構成情報を設定し、[接続のテスト] をクリックすると、成功すれば問題ありません。

[リバースエンジニアリング] をもう一度クリックし、次のステップで実用的なデータソースを選択します。

「OK」をクリックすると、次のインターフェースが表示され、必要に応じてインポートするテーブルにチェックを入れます。

「OK」をクリックすると、外部データ・テーブルがインポートされたことがわかります。この方法は、データベースに直接接続してインポートするのと同じです。テーブルの数が多い場合、このプロセスは少し遅くなる可能性があります。

4.6 異なるデータベースモデルの変換

実際のプロジェクトでは、最初は mysql を使用していましたが、突然、oracle や postgresql などの他のデータソースをサポートする必要が生じたというシナリオに直面することがあります。最初の問題はデータベースを変更することですが、これは頭の痛い問題です。データの移行はもちろんのこと、データテーブルが多数あるプロジェクトの場合は特に、テーブル構造を再定義するだけでも大きな作業負荷となります。しかし、この時点で pd を使用して変換することを考えている場合、おめでとうございます。これにより、時間を大幅に節約できます。どうすればよいでしょうか? 以下の具体的な手順を参照してください。

完全な操作プロセスは次のとおりです

4.6.1 リバースエンジニアリングと SQL ファイルのインポート

ここでも例として、ローカルにエクスポートされたデータベースファイルを取り上げます。

ローカルスクリプトを使用するか、データベースに直接接続するかを選択できます。

輸入後の効果

4.6.2 現在の PDM に基づいて新しい PDM ファイルを生成する

ここでは、実際の状況に応じて新しいデータベースの種類を選択します。たとえば、ここでは postgresql を選択します。

確認すると、左側のメニューに新しいPDファイルが表示され、同時に右側のデータテーブルのフィールド「User ID」の型もmysqのintから変更されていることがわかります。ページ内の in4 へ

SQLファイルをエクスポートする

「OK」をクリックした後、エクスポートされた SQL ファイルを確認し、pg データベースにインポートします。

ここまでの手順でモデルデータベースのmysqlからpgへの変換が完了しました。

5、本文の最後に書いてあります

データベース設計は、完全なプロジェクト開発サイクルの中で非常に重要な部分です。ますます多くのインターネット製品が高速反復製品におけるデータベースの地位を薄めていますが、データベースは依然として非常に重要です。したがって、依然として PowerDesigner を深く理解する必要があります。データモデリングの使用、この記事はこれで終わりです。ご覧いただきありがとうございます。

PowerDesigner データベースモデリングの詳細な説明

I.はじめに

2. PowerDesignerの概要