データベース・アプリケーション表統合リファレンス

Oracle Access Governanceとの統合が認定されたDatabase Application Tablesコンポーネント

次に、統合可能なデータベース・アプリケーション表コンポーネントを示します。

動作保証されたコンポーネント

動作保証されたコンポーネント
コンポーネント・タイプ コンポーネント
Oracle固有の要件
システム ターゲット・システムは、次のいずれかのRDBMSのデータベース表。
  • Oracle Autonomous Database
  • Oracle Database 23ai、19c、18cまたは12c(単一データベース、プラガブル・データベース(PDB)またはOracle RAC実装の場合)
  • Oracle Database 10gおよび11g (単一データベースまたはOracle RAC実装のいずれかの場合)。
JDK JDK 1.6以上
Microsoft SQL Server固有の要件
システム Microsoft SQL Server 2016, 2017
JDBCドライバ Microsoft SQL Server 2014の場合: sqljdbc4バージョン4.0
Microsoft MySQL固有の要件
システム MySQL 5.x、MySQL 8.x
JDBCドライバ mysql-connector-java-5.1.12-bin
一般的な要件
ユーザー・データがシステムに格納される形式

Database Application Tablesコネクタを使用できるのは、ユーザー・データが次のいずれかの形式でターゲット・システムに格納されている場合のみです。

  • すべてのユーザー・データが1つの表またはビューに格納されている場合。
  • ユーザー・データが、1つの親表全体および1つ以上の子表に分散している場合。このターゲット・システムは、管理対象システムとしてのみ構成でき、認可ソースとしては構成できません。
  • すべてのユーザー・データが、(1つ以上の表に基づく)単一の更新可能なビューに格納されている場合。
  • ユーザー・データが、(1つ以上の表に基づく)単一の更新可能なビュー、および(1つ以上の表に基づく)1つ以上の子ビューに分散している場合。このタイプのシステムは、管理対象システムとしてのみ構成でき、このコネクタの認可ソースとしては構成できません。つまり、認可ソースには子データを格納できません。
システムのその他の要件

システムは、次の要件を満たす必要があります。

  • 親表と子表が外部キーで結合していない場合(ビューを使用している場合など)は、両方の表の外部キー列の名前を同じにする必要があります。
  • ターゲット・システムで使用される表の主キーは、アイデンティティ表、アカウント表、権限表および参照表の単一列で指定する必要があります。コンポジット主キーは、権限表とアイデンティティ表/アカウント表をリンクする表でのみサポートされます。

データベース・アプリケーション表の統合でサポートされる構成モード

Oracle Access Governance統合は、アイデンティティ・データのオンボーディングおよびアカウントのプロビジョニングの要件に応じて、様々な構成モードで設定できます。

サポートされているモード

Database Application Tables Orchestrated Systemでは、次のモードがサポートされています。

  • 認可ソース
    次の場合、Oracle Access Governanceのアイデンティティ情報の信頼できるソースとしてデータベース・アプリケーション表を使用できます。
    • すべてのユーザー・データが1つの表またはビューに格納されている場合
    • すべてのユーザー・データが、単一の更新可能なビュー(1つ以上のテーブルに基づく)に格納されている場合。
    .
  • 管理対象システム
    次の場合、Database Application Tables権限を管理できます。
    • すべてのユーザー・データが1つの表またはビューに格納されている場合
    • すべてのユーザー・データが、単一の更新可能なビュー(つまり、1つ以上のテーブルに基づく)または
    • ユーザー・データが、1つの親表全体および1つ以上の子表に分散している場合。あるいは
    • ユーザー・データが、(1つ以上の表に基づく)単一の更新可能なビュー、および(1つ以上の表に基づく)1つ以上の子ビューに分散している場合。

最小特権サービスユーザーの構成

データベース・アプリケーション表の最小特権サービス・ユーザーの構成(Oracle)

Oracle Access GovernanceとDatabase Application Tables (Oracle)データベース間のセキュアな接続を有効にするには、統合の構成に必要な最小限の権限を持つサービス・ユーザーを作成します。

認可ソース・モードに必要な権限

Database Application Tables (Oracle)オーケストレート済システムを認可モードで構成する場合は、アイデンティティを含む表に対する読取り権限をサービス・ユーザーに付与して、Oracle Access Governanceにロードできるようにする必要があります。この場合に必要な最小限の権限セットは、アイデンティティ情報または個人情報を含む表に対するSELECT権限です。

次に例を示します。
GRANT SELECT ON MYDBAT_PERSON TO SERVICEUSER;
ここで:
  • MYDBAT_PERSON: アイデンティティ情報を含むデータベース・アプリケーション表(Oracle)データベースの表です。
  • SERVICEUSER: サービス・アカウント・ユーザー。

管理対象システム・モードに必要な権限

データベース・アプリケーション表(Oracle)のオーケストレートされたシステムをマネージド・システム・モードで構成する場合、アカウント表および権限表に対する読取りおよび書込み権限を付与し、アカウントおよびアカウント権限のリコンシリエーション、作成、更新および削除を許可する必要があります。この場合に必要な最小限の権限セットは、アカウントおよびアカウントの権限表に対するSELECTINSERTUPDATEおよびDELETE権限です。

次に例を示します。
GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_PERSON TO SERVICEUSER;
GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_ROLES TO SERVICEUSER;
GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_GROUPS TO SERVICEUSER;
GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_PERSON_ROLE TO SERVICEUSER;
GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_PERSON_GROUP TO SERVICEUSER;
ここで
  • MYDBAT_PERSON: アカウント情報を含むデータベース・アプリケーション表(Oracle)データベースの表です。
  • MYDBAT_ROLES: ロール情報を含むデータベース・アプリケーション表(Oracle)データベースの表です。
  • MYDBAT_GROUPS: グループ情報を含むデータベース・アプリケーション表(Oracle)データベースの表です。
  • MYDBAT_PERSON_ROLE: ユーザー・ロール情報を含むデータベース・アプリケーション表(Oracle)データベースの表です。
  • MYDBAT_PERSON_GROUP: グループ・ロール情報を含むデータベース・アプリケーション表(Oracle)データベースの表です。
  • SERVICEUSER: サービス・アカウント・ユーザー。

カスタム・スクリプトに必要な権限

「Groovyを使用したデータベース・アプリケーション表(Oracle)のカスタム・スクリプトの開発」の説明に従って、データベース・アプリケーション表(Oracle)統合の操作用のカスタム・スクリプトを開発するには、カスタム・スクリプトで参照されるストアド・プロシージャまたはその他のデータベース・オブジェクトに権限を追加する必要があります。サービス・ユーザーを使用してストアド・プロシージャを作成する場合は、権限を必要としません。ストアド・プロシージャまたは他のデータベース・オブジェクトが別のユーザーに作成されている場合は、必要に応じて権限を付与する必要があります。

次に例を示します。
GRANT EXECUTE ON MYDBAT_CUSTOMDEV.GET_USERROLE TO SERVICEUSER;
ここで:
  • MYDBAT_CUSTOMDEV: ストアド・プロシージャの作成に使用したユーザーです。
  • GET_USERROLEは、ストアド・プロシージャの名前です。
  • SERVICEUSER: サービス・アカウント・ユーザー。

データベース・アプリケーション表(MSSQL)の最小特権サービス・ユーザーの構成

Oracle Access GovernanceとDatabase Application Tables (MSSQL)データベース間のセキュアな接続を有効にするには、統合の構成に必要な最小限の権限を持つサービス・ユーザーを作成します。

認可ソース・モードに必要な権限

データベース・アプリケーション表(MSSQL)オーケストレート済システムを認可モードで構成する場合は、アイデンティティを含む表に対する読取り権限をサービス・ユーザーに付与して、それらをOracle Access Governanceにロードできるようにする必要があります。この場合に必要な最小限の権限セットは、アイデンティティ情報または個人情報を含む表に対するSELECT権限です。

次に例を示します。
GRANT SELECT ON MYDBAT_PERSON TO SERVICEUSER;
ここで:
  • MYDBAT_PERSON: アイデンティティ情報を含むデータベース・アプリケーション表(MSSQL)データベースの表です。
  • SERVICEUSER: サービス・アカウント・ユーザー。

管理対象システム・モードに必要な権限

管理対象システム・モードでデータベース・アプリケーション表(MSSQL)オーケストレート済システムを構成する場合、アカウントおよびアカウント権限のリコンシリエーション、作成、更新および削除を許可するために、アカウント表および権限表に対する読取りおよび書込み権限を付与する必要があります。この場合に必要な最小限の権限セットは、アカウントおよびアカウントの権限表に対するSELECTINSERTUPDATEおよびDELETE権限です。

次に例を示します。
GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_PERSON TO SERVICEUSER;
GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_ROLES TO SERVICEUSER;
GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_GROUPS TO SERVICEUSER;
GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_PERSON_ROLE TO SERVICEUSER;
GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_PERSON_GROUP TO SERVICEUSER;
ここで
  • MYDBAT_PERSON: アカウント情報を含むデータベース・アプリケーション表(MSSQL)データベースの表です。
  • MYDBAT_ROLES: ロール情報を含むデータベース・アプリケーション表(MSSQL)データベースの表です。
  • MYDBAT_GROUPS: グループ情報を含むデータベース・アプリケーション表(MSSQL)データベースの表です。
  • MYDBAT_PERSON_ROLE: ユーザー・ロール情報を含むデータベース・アプリケーション表(MSSQL)データベースの表です。
  • MYDBAT_PERSON_GROUP: グループ・ロール情報を含むデータベース・アプリケーション表(MSSQL)データベースの表です。
  • SERVICEUSER: サービス・アカウント・ユーザー。

カスタム・スクリプトに必要な権限

「Groovyを使用したデータベース・アプリケーション表(Oracle)のカスタム・スクリプトの開発」の説明に従って、データベース・アプリケーション表(MSSQL)統合での操作のカスタム・スクリプトを開発する場合は、カスタム・スクリプトで参照されるストアド・プロシージャまたはその他のデータベース・オブジェクトに権限を追加する必要があります。サービス・ユーザーを使用してストアド・プロシージャを作成する場合は、権限を必要としません。ストアド・プロシージャまたは他のデータベース・オブジェクトが別のユーザーに作成されている場合は、必要に応じて権限を付与する必要があります。

次に例を示します。
GRANT EXECUTE ON OBJECT::dbo.GET_USERROLE TO SERVICEUSER;
ここで:
  • OBJECT::dbo: Microsoft MSSQLデータベース・オブジェクトです。
  • GET_USERROLEは、ストアド・プロシージャの名前です。
  • SERVICEUSER: サービス・アカウント・ユーザー。

データベース・アプリケーション表の最小特権サービス・ユーザーの構成(MySQL)

Oracle Access GovernanceとDatabase Application Tables (MySQL)データベース間のセキュアな接続を有効にするには、統合の構成に必要な最小限の権限を持つサービス・ユーザーを作成します。

認可ソース・モードに必要な権限

データベース・アプリケーション表(MySQL)のオーケストレートされたシステムを認可モードで構成する場合は、アイデンティティを含む表に対する読取り権限をサービス・ユーザーに付与して、Oracle Access Governanceにロードできるようにする必要があります。この場合に必要な最小限の権限セットは、アイデンティティ情報または個人情報を含む表に対するSELECT権限です。

次に例を示します。
GRANT SELECT ON MYDBAT_PERSON TO SERVICEUSER;
ここで:
  • MYDBAT_PERSON: アイデンティティ情報を含むデータベース・アプリケーション表(MySQL)データベースの表です。
  • SERVICEUSER: サービス・アカウント・ユーザー。

管理対象システム・モードに必要な権限

データベース・アプリケーション表(MySQL)のオーケストレートされたシステムをマネージド・システム・モードで構成する場合、アカウント表および権限表に対する読取りおよび書込み権限を付与し、アカウントおよびアカウント権限のリコンシリエーション、作成、更新および削除を許可する必要があります。この場合に必要な最小限の権限セットは、アカウントおよびアカウントの権限表に対するSELECTINSERTUPDATEおよびDELETE権限です。

次に例を示します。
GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_PERSON TO SERVICEUSER;
GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_ROLES TO SERVICEUSER;
GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_GROUPS TO SERVICEUSER;
GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_PERSON_ROLE TO SERVICEUSER;
GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_PERSON_GROUP TO SERVICEUSER;
ここで
  • MYDBAT_PERSON: アカウント情報を含むデータベース・アプリケーション表(MySQL)データベースの表です。
  • MYDBAT_ROLES: ロール情報を含むデータベース・アプリケーション表(MySQL)データベースの表です。
  • MYDBAT_GROUPS: グループ情報を含むデータベース・アプリケーション表(MySQL)データベースの表です。
  • MYDBAT_PERSON_ROLE: ユーザー・ロール情報を含むデータベース・アプリケーション表(MySQL)データベースの表です。
  • MYDBAT_PERSON_GROUP: グループ・ロール情報を含むデータベース・アプリケーション表(MySQL)データベースの表です。
  • SERVICEUSER: サービス・アカウント・ユーザー。

カスタム・スクリプトに必要な権限

「Groovyを使用したデータベース・アプリケーション表(Oracle)のカスタム・スクリプトの開発」の説明に従って、データベース・アプリケーション表(MySQL)統合の操作用のカスタム・スクリプトを開発する場合は、カスタム・スクリプトで参照されているストアド・プロシージャまたはその他のデータベース・オブジェクトに権限を追加する必要があります。サービス・ユーザーを使用してストアド・プロシージャを作成する場合は、権限を必要としません。ストアド・プロシージャまたは他のデータベース・オブジェクトが別のユーザーに作成されている場合は、必要に応じて権限を付与する必要があります。

次に例を示します。
GRANT EXECUTE ON MYSQLDB.GET_USERROLE TO 'SERVICEUSER';
ここで:
  • MYSQLDB: ストアド・プロシージャを作成したMySQLデータベースです。
  • GET_USERROLEは、ストアド・プロシージャ名です。
  • SERVICEUSER: サービス・アカウント・ユーザー。

データベース・アプリケーション表へのプロビジョニング時にサポートされる操作

Oracle Access GovernanceからDatabase Application Tablesにアカウントをプロビジョニングすると、特定の操作がサポートされます。

Database Application Tables Orchestrated Systemでは、ユーザーのプロビジョニング時に次のアカウント操作がサポートされます。
  • アカウントの作成
  • アカウントの有効化
  • アカウントの無効化
  • アカウントの取消
  • 権限の割当
  • 権限の削除

サポートされているデータ型

リコンシリエーションおよびプロビジョニング操作でサポートされるデータ型を以下の項で示します。

Oracle Databaseの場合

Oracle Databaseオーケストレート済システムのリコンシリエーションおよびプロビジョニング操作でサポートされているデータ型は、次のとおりです。

  • VARCHAR2
  • CHAR
  • NUMBER
  • NUMERIC
  • INTEGER
  • INT
  • SMALLINT
  • DOUBLE
  • FLOAT
  • DECIMAL
  • 12月
  • REAL
  • DATE
  • TIMESTAMP

Microsoft SQL Serverの場合

Microsoft SQL Serverデータベース・オーケストレート済システムのリコンシリエーションおよびプロビジョニング操作でサポートされているデータ型は、次のとおりです。

  • CHAR
  • VARCHAR
  • SMALLINT
  • INT
  • BIGINT
  • DECIMAL
  • NUMERIC
  • NVARCHAR
  • FLOAT
  • REAL
  • SMALLDATETIME
  • DATETIME

MySQLの場合

MySQLデータベースのオーケストレート済システムのリコンシリエーションおよびプロビジョニング操作でサポートされているデータ型は、次のとおりです。

  • ブール
  • SMALLINT
  • MEDIUMINT
  • INT
  • BIGINT
  • FLOAT
  • DOUBLE
  • DECIMAL
  • CHAR
  • VARCHAR
  • TINYTEXT
  • DATE
  • DATETIME
  • TIMESTAMP

デフォルトのサポートされる属性

データベース・アプリケーション表の統合にはスキーマの検出が必要であり、検出されたスキーマは固定されていないため、サポートされている特定の属性などはありません。必要に応じて、schema.jsonを変更してコア属性およびカスタム属性を追加できます。少なくとも、「コア・アイデンティティ属性」で定義されているように、Oracle Access Governanceアイデンティティに必要なuidおよびname属性を含める必要があります。

デフォルト照合ルール

Oracle Access Governanceのアイデンティティにアカウントをマップするには、オーケストレート済システムごとに照合ルールが必要です。

Database Application Tablesオーケストレート済システムのデフォルト照合ルールは、次のとおりです。

デフォルト照合ルール
モード デフォルト照合ルール
認可ソース

アイデンティティ照合では、受信アイデンティティが既存のアイデンティティと一致するか、新しいアイデンティティであるかがチェックされます

画面値:

Employee user name = Employee user name

属性名:

Identity.userName = Identity.userName

管理されたシステム

アカウント照合では、受信アカウントが既存のアイデンティティと一致するかどうかがチェックされます。

画面値:

User login = Employee user name

属性名:

Account.name = Identity.userName

データベース・アプリケーション表のガイドライン

Oracle Access Governanceでデータベース・アクセス表を使用する場合は、表の設計および構造における次のガイドラインを考慮する必要があります。

一般ガイドライン

すべてのデータベース・アクセス表は、次のガイドラインに準拠している必要があります。
  • エンティティの「名前」列および「キー」列は、NOT NULLとして構成する必要があります。
  • 特定のエンティティの場合、同じデータベース列を「名前」および「キー」として構成できます。必要に応じて、これらの列に異なる列を使用することもできます。
  • ACCOUNTエンティティに含まれるコア属性は、次のルールに従う必要があります。
    • 列のデータ型には、Oracle Access Governance側のデータ型との互換性があることが必要です。
    • スキーマJSONファイルで"nature":["REQUIRED"]として構成される属性は、NOT NULLデータベース・フィールドに対応している必要があります。
  • ENTITLEMENTおよびLOOKUP表には、キー列に対する主キー制約が必要です。
  • ENTITLEMENTテーブルとLOOKUPテーブルの関連カラムが一致する場合、ACCOUNT/TARGETACCOUNTテーブルとENTITLEMENTテーブルとLOOKUPテーブルの間に外部キー関係を定義する必要はありません。詳細については、次のセクションを参照してください。

テーブル関係

ACCOUNT/TARGETACCOUNTエンティティにマップされるユーザー表には、ENTITLEMENT表およびLOOKUP表との関係がある場合があります。データベース・アプリケーション表コネクタがスキーマ検出を実行すると、最初に、ユーザー表とENTITLEMENT表またはLOOKUP表の間の関係を定義する、データベース表の制約として定義された外部キー(FK)が検索されます。これは、ユーザーの国に対するユーザー表と参照表の関係を示す例のようになります。
CREATE TABLE MYDBAT_PERSON
  (USERID VARCHAR2 NOT NULL ENABLE,
   USERNAME VARCHAR2 NOT NULL ENABLE,
   FIRSTNAME VARCHAR2,
   LASTNAME VARCHAR2,
   EMAIL VARCHAR2 NOT NULL ENABLE,
   HOMECOUNTRY VARCHAR2,
   FOREIGN KEY (HOMECOUNTRY) REFERENCES MYDBAT_COUNTRY(COUNTRYCODE));

CREATE TABLE MYDBAT_COUNTRY
  (COUNTRYCODE VARCHAR2 NOT NULL ENABLE,
   COUNTRYNAME VARCHAR2 NOT NULL ENABLE,
   CONSTRAINT MYDBAT_COUNTRY_PK PRIMARY KEY (COUNTRYCODE)
                        
外部キーが定義されていない場合、Database Application Tablesコネクタは列名での一致を試みます。列名が一致すると、関係が一致します。例:
CREATE TABLE MYDBAT_PERSON
  (USERID VARCHAR2 NOT NULL ENABLE,
   USERNAME VARCHAR2 NOT NULL ENABLE,
   FIRSTNAME VARCHAR2,
   LASTNAME VARCHAR2,
   EMAIL VARCHAR2 NOT NULL ENABLE,
   COUNTRYCODE VARCHAR2);

CREATE TABLE MYDBAT_COUNTRY
  (COUNTRYCODE VARCHAR2 NOT NULL ENABLE,
   COUNTRYNAME VARCHAR2 NOT NULL ENABLE,
   CONSTRAINT MYDBAT_COUNTRY_PK PRIMARY KEY (COUNTRYCODE)
ただし、表の間に外部キー関係が定義されておらず、列名が一致しない場合は、エラーがスローされます。これは、たとえば、次のように列を定義した場合に発生します。
CREATE TABLE MYDBAT_PERSON
  (USERID VARCHAR2 NOT NULL ENABLE,
   USERNAME VARCHAR2 NOT NULL ENABLE,
   FIRSTNAME VARCHAR2,
   LASTNAME VARCHAR2,
   EMAIL VARCHAR2 NOT NULL ENABLE,
   HOMECOUNTRY VARCHAR2);

CREATE TABLE MYDBAT_COUNTRY
  (COUNTRYCODE VARCHAR2 NOT NULL ENABLE,
   COUNTRYNAME VARCHAR2 NOT NULL ENABLE,
   CONSTRAINT MYDBAT_COUNTRY_PK PRIMARY KEY (COUNTRYCODE)

ユーザーと参照間の関係について前述したのと同じ原則が、ユーザーと権限の間の関係に対して表を定義するときに適用されます。

アイデンティティ属性とアカウント属性の関連付け

アカウント属性設定を編集することで、アイデンティティ属性をアカウント属性に関連付けることができます。

  1. Oracle Access Governanceコンソールにサインインし、「Service Administration」→「Orchestrated Systems」に移動します。
  2. アイデンティティ属性をアカウント属性に関連付けるDBATオーケストレート済システムの「統合の管理」を選択します。
  3. 「アカウント属性」タイルから「管理」を選択します。
  4. マップするアカウント属性について、アクション・メニューから「関連付けられたアイデンティティ属性の編集」を選択します。
  5. アカウント属性に関連付けるアイデンティティ属性を選択し、「保存」をクリックします。この値は、アカウント属性の「関連付けられたアイデンティティ属性」列に表示されます。

カスタム複数値アイデンティティ属性のDBAT提携サポート

DBATオーケストレート済システムは、Custom (Complex) Multivalued Attributesの実装を通じてアフィリエイト・データをサポートします。

提携は、必要な提携のカスタム表を追加し、それをアカウント表にリンクすることで有効になります。たとえば、次のようなユーザーというアカウント表があるとします。

アカウント(例: USERS)→PK (USER_ID)
USER_ID USER_NAME FIRST_NAME LAST_NAME 電子メール ステータス
1 USR001 ユーザー 1つ userone@email.com ACTIVE
2 USR002 ユーザー 2 usertwo@email.com ACTIVE

次に、表すアフィリエイトのカスタム表を作成する必要があります。たとえば、1つのIDに複数の肩書を割り当てられる所属関係を設定できます。これを行うには、次のような表ジョブを作成します:

所属関係(例: JOBS)→ 複合PK (USER_ID、JOBCODE)
職務コード USER_ID JOBNAME 説明
JB001 1 ジョブ これはジョブです
1 別のジョブ これは別のジョブです
2 新規ジョブ これは新規ジョブです

勘定科目テーブルは、複合主キー(USER_ID、JOBCODE)によって Affiliationテーブルに直接リンクされます。

最後に、次のスニペットに示すように、schema.jsonの塗りつぶしにアフィレーションを追加する必要があります。

[
  {
    "type": "ACCOUNT",
    "name": "ACCOUNT",
    "displayName": "Account",
    "attributes": [
      {
        "name": "JOBS",
        "targetName": "JOBS",
        "displayName": "",
        "dataType": "",
        "nature": ["MULTIVALUED"],
        "usage": [
          "READ"
        ],
        "relationship": {
          "relatedTo": "__CUSTOM_COMPLEX__", // Indicates the custom relationship 
          "relatedBy": "", 
          "relationshipProperties": [
            {
              "name": "JOBCODE",
              "dataType": "TEXT",
              "nature": ["REQUIRED"] 
            },
            {
              "name": "JOBNAME",
              "dataType": "TEXT",
              "nature": ["REQUIRED"]
            },
            {
              "name": "DESCRIPTION",
              "dataType": "TEXT",
              "nature": []
            }
          ]
        }
      }
    ]
  }
]

統合設定には、この表名とその他の関連表を含めます。詳細は、関係会社を参照してください。