リバースエンジニアリング
リバースエンジニアリングは、データベーススキーマに基づいて JPA エンティティクラスをスキャフォールディングするプロセスです。
データベースから JPA エンティティを生成する
データベース接続が確立されていない場合は、 接続を作成します。
データベース ツールウィンドウで、 JPA ノードを展開し、データベースまたは特定のテーブルを右クリックして、 を選択します。

マップするデータベース接続、テーブル、属性を選択します。 詳細については、 DB ウィザードからのエンティティ を参照してください。
IDE が開いている間、データベースは他のクライアントによって変更される可能性があります。 データベースから最新のデータを取得するには、 DB からのエンティティ ウィンドウまたは データベース ツールウィンドウのいずれかで をクリックします。
DB ウィザードからのエンティティ

構成
ウィンドウの上部にあるメニューでは、次の設定を行うことができます。
生成されたエンティティが保存されるソースルートとパッケージ
インデックスと制約を移行する必要があるかどうか
@Tableアノテーションでスキーマ名を指定するかどうか
また、 その他の設定 ドロップダウンリストから、 エンティティ宣言と リバースエンジニアリング設定に移動できます。
マップされたリレーション、テーブル、ビュー
ウィンドウの左側に次のものが表示されます。
マップされた関係: JPA エンティティにマップされたテーブルとビュー
テーブル: DB 内に存在するがエンティティにマップされていないテーブル
ビュー: DB 内に存在するがエンティティにマップされていないビュー
ツリーから任意の要素を選択すると、列から属性を移行するためのパネルが表示されます。 また、対応するフィールドにクラス名を定義することもできます。
属性の移行
ウィンドウのメイン部分では、属性に関連するすべての設定を行うことができます。 追加する属性を選択し、 列名 を除くすべてのパラメーターを変更できます。 マッピングタイプと属性 / コンバーター / 休止状態のタイプは、ドロップダウンリストとして表されます。
すべての属性は 3 つのカテゴリに分類されます。
移行された列 - エンティティ内にすでに存在する列 (マップされたリレーションでのみ使用可能)
列 - エンティティまたは親 @MappedSuperclass にまだマップされていない新しい列
リファレンス - 観察されたテーブルの列として表されないオプションの関連付け
親エンティティ
IntelliJ IDEA では、 親 ドロップダウンボックスから @MappedSuperclass でアノテーションが付けられたクラスを選択して親エンティティを定義することができます。 これにより、生成されたエンティティは親クラスから拡張され、同じ名前とタイプを持つすべての属性を自動的に継承できます。
@MappedSuperclass の列名が子エンティティのテーブルと一致しない場合でも、 @AttributeOverride アノテーションを使用して属性を継承できます。 属性名を選択し、オーバーライドするものを選択するだけで、IntelliJ IDEA が継承の管理を支援します。

エンティティ生成中に、 @MappedSuperclass から継承された属性がデータベースにない場合、IntelliJ IDEA によって警告が表示されます。 モデルをデータベースに合わせるには、JPA 構造メニューの エンティティ別の DDL を生成 アクションにアクセスし、 既存 DB 更新 オプションを選択します。
列挙型の作成
String または 整数 タイプに一致する属性の場合、マッピングタイプを Basic から Enum に変更すると、IntelliJ IDEA によってプロジェクト内に対応する Enum クラスが作成されます。 enum に適切な値を手動で入力する必要があります。
未知の型への対処
一部の SQL タイプでは、Java クラスと完全に一致するものはありません。 この場合、IntelliJ IDEA は、機能しないコードが生成されないようにタイプを設定しません。 属性タイプは自分で選択する必要があります。 設定で各 DBMS のデフォルトのタイプマッピングを構成することもできます。
プロジェクトの依存関係リストに HibernateTypes ライブラリがある場合、IntelliJ IDEA はリバースエンジニアリング中にサポートされていない SQL タイプに対してライブラリから適切なタイプを自動的に提案できます。
// TODO Comments
特定の列の属性作成を延期したい場合は、マッピングタイプとして //todo コメントを選択できます。 IntelliJ IDEA は、列タイプに応じて、対応するクイックフィックスアクションを含む //todo コメントを生成します。 これらのアクションは、 Ctrl+B を押すことで呼び出すことができます。
既知の基本タイプと関連付けタイプについては、次のことができます。
そのままコメント解除
列マッピングの除去
不明な列タイプの場合は、次のことができます。
ターゲット Java 型の定義
そのままコメント解除
列マッピングの除去
以下は、不明な列タイプを持つ属性に対して生成された //todo コメントの例です。
ターゲット Java 型の定義 アクションを呼び出すと、次のウィンドウが表示されます。

IntelliJ IDEA は、後続のリバースエンジニアリングアクションのためにデータマッピングを記憶します。 設定でいつでも変更できます。
DB ビューを JPA エンティティにマップする
IntelliJ IDEA は、リバースエンジニアリング中に DB ビューの最も効率的なマッピングを提供するすべてのベストプラクティスに従います。
DB ビューには主キーがないため、IntelliJ IDEA では、ターゲットエンティティの識別子として使用するフィールドまたはフィールドセットを選択できます。
ほとんどの DB ビューは不変です。 そのため、IntelliJ IDEA はエンティティに
@Immutableアノテーションを追加し、getter のみを生成します。 これにより、アプリケーションのパフォーマンスが向上します。IntelliJ IDEA は、JPA 仕様に従って、DB ビューにマップされたエンティティに対して引数なしの protected コンストラクターのみを生成し、開発者がビジネスロジックコードでそのようなエンティティの新しいインスタンスを作成することを防ぎます。
列のリバースエンジニアリング
一部の開発者は、DB ファーストのアプリケーション開発アプローチを好みます。 まず、データベースに列を直接追加し、次に JPA モデルを更新します。 IntelliJ IDEA はこのプロセスを自動化できます。
データベースから属性を生成する
データベース接続が確立されていない場合は、 接続を作成します。
永続化 ツールウィンドウで、 JPA ノードを展開し、エンティティを右クリックして を選択します。
または、エンティティソースコードで、ガターのエンティティアイコン
をクリックし、 DB からエンティティ属性を作成する を選択します。
データベース接続、テーブルまたはビュー、マップする列を選択します。 属性の移行フローは、 DB ウィザードからのエンティティセクションで説明されているものと同じです。

スマートな参照検出
IntelliJ IDEA はモデルを深く理解します。 場合によっては、カーディナリティ @OneToOne、 @OneToMany、 @ManyToOne、 @ManyToMany を適切に検出できます。 最も素晴らしいのは、現在のテーブルに対応する列がない場合でも、IntelliJ IDEA が参照を表示できることです。
これらのそれぞれのケースを詳しく見てみましょう。
@OneToOne
リレーションのカーディナリティを @OneToOne として自信を持って仮定できる状況が 2 つあります。
テーブルには、別のテーブルの主キーを参照する一意制約が設定された列があります
テーブルの主キーは外部キーです
ケース 1:


IntelliJ IDEA は、User エンティティに @JoinColumn アノテーションを含む @OneToOne 関連付けを生成し、Profile エンティティに mappedBy パラメーターを含む @OneToOne 関連付けを生成します。
ケース№ 2:


@Id は永続エンティティではないため、IntelliJ IDEA は次を生成します。
基本タイプの
id属性に@Idアノテーションを付けるusers@OneToOneの関連付けと@MapsIdアノテーションのマーク付け
@OneToMany & @ManyToOne
テーブルに別のテーブルの主キーを参照する列がある場合、 @ManyToOne 関連付けである可能性が最も高くなります。 ただし、必要に応じてカーディナリティを @OneToOne に変更することもできます。 リバースエンジニアリングアクションを呼び出すテーブルに応じて、IntelliJ IDEA はマッピングタイプを @OneToMany または @ManyToOne として検出します。


IntelliJ IDEA は次のコードを生成します。
@ManyToMany
2 つのテーブル間に多対多の関係を確立するには、ジャンクションテーブルを使用する必要があります。 この場合、ジャンクションテーブルには 2 つの列 (外部キー) のみが含まれます。 IntelliJ IDEA は、このようなテーブルを自動的に検出し、ジャンクションテーブルで外部キーとして ID が @ManyToMany として表される 2 つのテーブル間の関係カーディナリティを識別できます。


この関連付けがいずれのエンティティにも存在しない場合、IntelliJ IDEA はリバースエンジニアリングアクションが呼び出されたエンティティにそれを生成します。
この関連付けがすでにエンティティの 1 つに存在する場合、IntelliJ IDEA は mappedBy パラメーターを使用して @ManyToMany 属性を生成します。
設定
一般
フェッチタイプ。 ベストプラクティスに従い、潜在的なパフォーマンスの問題を回避するために、IntelliJ IDEA はデフォルトで
@OneToOneおよび@ManyToOneの関連付けにFetchType.LAZYを設定します。検証アノテーション。 検証アノテーションは、DB 制約に加えて、もう 1 つの保護レイヤーを提供します。 デフォルトでは、IntelliJ IDEA はリバースエンジニアリング中にエンティティ属性にこのようなアノテーションを適用します。
複数形。 デフォルトでは、IntelliJ IDEA はエンティティ名に単数形を使用します。 例:
usersというテーブルがある場合、IntelliJ IDEA はユーザーエンティティを生成します。 このオプションを無効にすると、IntelliJ IDEA はテーブルの元の名前を保持し、最初の文字のみを大文字にしてUsersにします。基本型属性。 このオプションを有効にすると、IntelliJ IDEA はデータベーススキーマ内の ORM 参照を分析し、エンティティ間の関連付けや関係を作成する代わりに、基本型属性を生成します。 これは、複雑な関連付けではなく単純な属性タイプを使用する必要がある特定のシナリオで役立ちます。

テーブルと列のコメント
データベースオブジェクトに追加されたコメントを保持するために、IntelliJ IDEA は設定に応じて、Hibernate @Comment アノテーションまたは JavaDocs を使用して、それらのコメントを対応するエンティティに転送します。

命名ルール
構成経由

多くの場合、DBA スペシャリストは、データベースオブジェクトに対して特定の命名規則に従います。 たとえば、すべてのテーブル名または列名には、特定の接頭辞 / 接尾辞があります。 ただし、Java 開発者は通常、JPA モデルではこれらの接頭辞 / 接尾辞を削除することを好みます。 IntelliJ IDEA を使用すると、スキップする接頭辞と接尾辞を指定できます。 スキップする接頭辞として sys_ と p_ を設定したとします。 その後、 sys_user テーブルと p_product テーブルにリバースエンジニアリングを適用します。 その結果、対応するエンティティ名に接頭辞は表示されなくなります。 最終的なエンティティ名は、 SysUser と PProduct ではなく、 ユーザー と 製品 になります。 また、データベースの列名は、 予約済みの Java キーワード(英語)と一致する場合があります。 例: public、 interface など。 この場合、フィールド接尾辞を構成して、IntelliJ IDEA がそれを元の列名に追加するようにすることができます。 たとえば、 Field 接尾辞の場合、結果の名前は publicField と interfaceField になります。
アルゴリズム経由

接頭辞、接尾辞、予約語などを設定するための柔軟なオプションがあるにもかかわらず、場合によってはそれだけでは不十分な場合があります。 IntelliJ IDEA はこれらの設定だけに限定されません。 データベーステーブル / 列の名前を処理するためのカスタムコードを記述できます。 さらに、現在のエディターでコードを記述するだけでなく、既存のクラスをインポートしてそのメソッドを使用することもできます。
IntelliJ IDEA は、命名アルゴリズムで使用されるクラスの変更をリアルタイムで追跡しないことに注意してください。 アルゴリズムで使用されるクラスを変更した後は、設定を更新するか、IntelliJ IDEA を再起動してください。
型マッピング

アプリケーションが複数の DBMS で動作する場合、スキーマのデータ型はそれぞれの DBMS に対してわずかに異なる場合があります。
アプリケーションが PostgreSQL と MS SQL の両方をサポートする必要があり、文字列データに Unicode 文字を格納する必要があるとします。 PostgreSQL は VARCHAR の Unicode 文字をサポートしますが、MS SQL にはそれ用の別の NVARCHAR データ型があります。
IntelliJ IDEA では、各 DBMS の型マッピングを指定できます。 また、JPA コンバーターと Hibernate 型のマッピングを設定することもできます。
Hibernate 6 の @JavaType アノテーションを利用するために、IntelliJ IDEA でリバースエンジニアリング用の型マッピングを構成する方法を確認します。