本記事について
本記事は、生成AI(ChatGPT)の支援を受けて作成しています。掲載しているSQLのうち、既存プロパティの更新とSELECTによる取得・検索は、実際のOracle Autonomous AI Database環境で動作確認を行っています。ただし、説明や解釈を含め、内容に誤りや不正確な記述が含まれる可能性があります。仕様や制約については、Oracle公式ドキュメントも併せてご確認ください。
はじめに
データベースに蓄積されたデータを活用しようとした際、「必要なデータがどのテーブルに格納されているのかわからない」という課題に直面することがあります。
Oracle Databaseでは、データディクショナリを参照することで、テーブル名、列名、データ型などの技術的なメタデータを取得できます。しかし、これらの情報だけでは、データが業務上どのような意味を持つのかを理解することは容易ではありません。
例えば、次のようなテーブルがあるとします。
| テーブル名 | 業務上の意味 |
|---|---|
| CUSTOMER | 契約者情報 |
| POLICY | 保険契約 |
| CLAIM | 事故受付 |
| AGENT | 代理店 |
テーブル名からある程度の意味は推測できますが、実際にデータを活用するには、業務上の名称や説明、管理部門、個人情報の有無、データ分類などの情報も必要になります。こうした情報は一般に「ビジネスメタデータ」と呼ばれ、データの発見や理解、適切な利用を支援します。
Oracle Autonomous AI Databaseには、データカタログを管理するためのDBMS_CATALOGパッケージが提供されています。本記事では、このパッケージの位置づけと、カスタムプロパティを利用したビジネスメタデータの登録・取得・検索方法を紹介します。
特に、Oracle標準のDBMS_CATALOGパッケージだけで、業務メタデータを持つテーブルを動的に検索できることを確認します。
1. DBMS_CATALOGパッケージとは
DBMS_CATALOGは、データカタログの管理やメタデータの取得・更新・検索を行うためのPL/SQLパッケージです。Oracle Autonomous AI DatabaseのData Studioで提供されるカタログ機能を、PL/SQLから操作するためのAPIを提供しています。
主な機能は以下のとおりです。
| 機能 | 概要 |
|---|---|
| カタログの管理 | カタログのマウント、解除など |
| メタデータの取得 | スキーマ、テーブル、列などの情報取得 |
| プロパティの管理 | カスタムプロパティの登録、更新、取得 |
| メタデータの検索 | カスタムプロパティなどを条件とした検索 |
| 外部カタログとの連携 | DB Linkや対応する外部カタログの利用 |
特に注目したいのが、カスタムプロパティの管理機能です。テーブル名やデータ型といった技術的なメタデータに加え、利用者が独自に定義した業務情報をカタログ上で管理できます。
1-1. カタログとデータベースの関係
DBMS_CATALOGでは、カタログを単位としてデータソースのメタデータを扱います。今回使用するLOCALカタログは、ローカルデータベースの情報を参照するためのカタログです。
また、DB Linkや外部カタログとの連携機能も提供されています。これにより、データが格納されている場所と、メタデータを管理する場所を分離した構成も検討できます。ただし、外部カタログで利用できる操作やプロパティ更新の可否は、接続方式やカタログの種類によって異なります。
本記事では、LOCALカタログを使用した基本操作を扱います。
1-2. DBMS_CATALOGを利用できる環境
DBMS_CATALOGはAutonomous AI Databaseで提供されてきた機能ですが、利用できる環境は拡大しています。
Oracle AI Database 26aiでは、リリース23.26.2以降、顧客管理型のOracle AI DatabaseにもData Studio関連パッケージを手動で導入できるようになっています。
| データベース環境 | DBMS_CATALOGの利用 |
|---|---|
| Oracle Autonomous AI Database | 提供される機能として利用可能 |
| Oracle AI Database 26ai (23.26.2以降) | 対応する手順で手動導入可能 |
| Oracle Database 19c | DBMS_CATALOGの直接利用は標準提供として確認できない |
| Oracle Database 21c / 23ai (非ADB) | 26aiと同じ導入条件での提供は確認できない |
顧客管理型の26aiでは、DBMS_CATALOGがあらかじめ導入されているわけではありません。利用するには、関連パッケージの準備やインストールが必要です。
また、DBMS_CATALOGを実行するデータベースと、カタログで管理するデータベースは必ずしも同じである必要はありません。例えば、対応するDB Linkを利用してOracle Database 19cをカタログの管理対象にする構成も考えられます。ただし、これは19c上でDBMS_CATALOGを直接実行できることを意味するものではありません。
本記事のSQLはAutonomous AI Database環境で検証しています。
参考: Oracle公式 - Oracle Data Studio Family of Packages
2. カスタムプロパティによるビジネスメタデータ管理
DBMS_CATALOGでは、カタログ内のオブジェクトに対してプロパティを設定できます。今回使用するのはCUSTOMプロパティです。
CUSTOMプロパティでは、独自に定義した名前と値の組み合わせを管理できます。例えば、以下のような属性を定義できます。
| プロパティ名 | 説明 | 設定例 |
|---|---|---|
BUSINESS_NAME |
業務名 | 保険契約 |
DESCRIPTION |
業務説明 | 保険契約の基本情報を保持するテーブル。 |
OWNER |
管理部門 | 契約部 |
PII |
個人情報区分 | NO |
CATEGORY |
データ分類 | 契約 |
UPDATE_FREQUENCY |
更新頻度 | Daily |
これらのプロパティ名はOracle Databaseに標準で定義された業務属性ではなく、利用者が独自に定義するものです。例えば、POLICYテーブルに対して以下のような情報を登録できます。
CUSTOM:BUSINESS_NAME = 保険契約
CUSTOM:DESCRIPTION = 保険契約の基本情報を保持するテーブル。
CUSTOM:OWNER = 契約部
CUSTOM:PII = NO
CUSTOM:CATEGORY = 契約
CUSTOM:UPDATE_FREQUENCY = Daily
このように、技術的なテーブル名とは別に、業務上の意味をカタログで管理できます。
2-1. CUSTOMとMETADATAの違い
DBMS_CATALOGには、CUSTOMのほかにMETADATAというプロパティもあります。両者は追加情報を保持できる点では似ていますが、用途が異なります。
| 項目 | CUSTOM | METADATA |
|---|---|---|
| データ形式 | 名前と値の組み合わせ | JSON形式 |
| 属性の管理 | 個別の属性として管理 | JSON構造として管理 |
| カタログ検索条件への利用 | 可能 | CUSTOMと同じ条件指定には対応しない |
| 主な用途 | 業務名、分類、管理部門など | 複雑な補足情報など |
業務名やデータ分類のように、検索条件として利用したい属性にはCUSTOMが適しています。今回は、このCUSTOMプロパティをSQLから取得し、検索条件として利用します。
3. 検証環境
今回の検証では、以下の環境を使用します。
| 項目 | 内容 |
|---|---|
| データベース | Oracle Autonomous AI Database |
| カタログ | LOCAL |
| スキーマ | CATALOG_DEMO |
| 対象データ | 保険業務を想定したサンプルテーブル |
| SQL実行環境 | Database ActionsのSQLワークシート |
対象のテーブルと列には、あらかじめDBMS_CATALOGのカスタムプロパティが登録されています。今回は既存のプロパティを更新して取得結果が変わることを確認し、その後元の値に戻しています。
また、SQL中ではCATALOG_DEMOというスキーマ名を使用しています。別の環境で試す場合は、対象スキーマ名に置き換えてください。
4. カスタムプロパティを登録・更新する
カスタムプロパティの登録・更新には、DBMS_CATALOG.UPDATE_TABLE_PROPERTYプロシージャを使用します。プロパティ名と値を指定することで、テーブルにビジネスメタデータを設定できます。
4-1. テーブルにカスタムプロパティを登録する
以下は、CATALOG_DEMOスキーマのPOLICYテーブルに、BUSINESS_NAMEというカスタムプロパティを設定する例です。
BEGIN
DBMS_CATALOG.UPDATE_TABLE_PROPERTY(
catalog_name => 'LOCAL',
schema_name => 'CATALOG_DEMO',
table_name => 'POLICY',
table_property => 'CUSTOM:BUSINESS_NAME',
new_value => '保険契約'
);
END;
/
各引数の意味は以下のとおりです。
| 引数 | 説明 | 指定例 |
|---|---|---|
catalog_name |
対象カタログ | LOCAL |
schema_name |
対象スキーマ | CATALOG_DEMO |
table_name |
対象テーブル | POLICY |
table_property |
設定するプロパティ | CUSTOM:BUSINESS_NAME |
new_value |
設定する値 | 保険契約 |
CUSTOM:BUSINESS_NAMEのようにCUSTOM:に続けて任意の属性名を指定することで、業務上必要なプロパティを管理できます。すでに同名のプロパティが登録されている場合は、その値を更新します。
例えば、業務説明や分類を追加する場合も、同じプロシージャを利用できます。
BEGIN
DBMS_CATALOG.UPDATE_TABLE_PROPERTY(
catalog_name => 'LOCAL',
schema_name => 'CATALOG_DEMO',
table_name => 'POLICY',
table_property => 'CUSTOM:DESCRIPTION',
new_value => '保険契約の基本情報を保持するテーブル。'
);
DBMS_CATALOG.UPDATE_TABLE_PROPERTY(
catalog_name => 'LOCAL',
schema_name => 'CATALOG_DEMO',
table_name => 'POLICY',
table_property => 'CUSTOM:CATEGORY',
new_value => '契約'
);
END;
/
4-2. 登録済みのカスタムプロパティを更新する
すでに登録されているカスタムプロパティも、同じUPDATE_TABLE_PROPERTYプロシージャで更新できます。
例えば、POLICYテーブルの業務名を「保険契約」から「保険契約情報」に変更する場合は、以下のSQLを実行します。
BEGIN
DBMS_CATALOG.UPDATE_TABLE_PROPERTY(
catalog_name => 'LOCAL',
schema_name => 'CATALOG_DEMO',
table_name => 'POLICY',
table_property => 'CUSTOM:BUSINESS_NAME',
new_value => '保険契約情報'
);
END;
/
今回の検証環境でも、既存のBUSINESS_NAMEを変更できることを確認しました。検証後は元の値に戻しています。
このように、カスタムプロパティは初期登録だけでなく、業務上の名称や説明が変更された際にも更新できます。登録・更新した値の取得方法については、次章で紹介します。
4-3. 列にカスタムプロパティを登録する
テーブルだけでなく、列単位にもカスタムプロパティを設定できます。列のプロパティを登録・更新する場合は、UPDATE_COLUMN_PROPERTYプロシージャを使用します。
以下は、POLICYテーブルのPREMIUM列に業務名「保険料」を設定する例です。
BEGIN
DBMS_CATALOG.UPDATE_COLUMN_PROPERTY(
catalog_name => 'LOCAL',
schema_name => 'CATALOG_DEMO',
table_name => 'POLICY',
column_name => 'PREMIUM',
column_property => 'CUSTOM:BUSINESS_NAME',
new_value => '保険料'
);
END;
/
テーブルと列の両方にビジネスメタデータを設定することで、テーブル全体の用途だけでなく、個々の項目が業務上どのような意味を持つのかも管理できます。
なお、本節ではテーブルの既存プロパティの更新を実機検証しています。新規プロパティの登録および列プロパティの更新については、APIの利用例として掲載しています。
5. テーブルのカスタムプロパティを取得する
POLICYテーブルに登録されている業務名を取得します。使用するのはDBMS_CATALOG.GET_TABLE_PROPERTY関数です。
SELECT
DBMS_CATALOG.GET_TABLE_PROPERTY(
catalog_name => 'LOCAL',
schema_name => 'CATALOG_DEMO',
table_name => 'POLICY',
table_property => 'CUSTOM:BUSINESS_NAME'
) AS BUSINESS_NAME
FROM DUAL;
実行結果:
| BUSINESS_NAME |
|---|
| 保険契約 |
POLICYテーブルに登録されている業務名「保険契約」を取得できました。
GET_TABLE_PROPERTYでは、カタログ名、スキーマ名、テーブル名、取得するプロパティを指定します。今回のCUSTOM:BUSINESS_NAMEは、利用者が独自に定義したBUSINESS_NAMEというカスタムプロパティを意味しています。
このように、カタログに登録されたビジネスメタデータは通常のSQLから取得できます。
6. 複数のカスタムプロパティを取得する
続いて、同じPOLICYテーブルに登録されている複数のプロパティをまとめて取得します。
SELECT
DBMS_CATALOG.GET_TABLE_PROPERTY(
'LOCAL', 'CATALOG_DEMO', 'POLICY',
'CUSTOM:BUSINESS_NAME'
) AS BUSINESS_NAME,
DBMS_CATALOG.GET_TABLE_PROPERTY(
'LOCAL', 'CATALOG_DEMO', 'POLICY',
'CUSTOM:DESCRIPTION'
) AS DESCRIPTION,
DBMS_CATALOG.GET_TABLE_PROPERTY(
'LOCAL', 'CATALOG_DEMO', 'POLICY',
'CUSTOM:OWNER'
) AS OWNER_NAME,
DBMS_CATALOG.GET_TABLE_PROPERTY(
'LOCAL', 'CATALOG_DEMO', 'POLICY',
'CUSTOM:PII'
) AS PII_FLAG,
DBMS_CATALOG.GET_TABLE_PROPERTY(
'LOCAL', 'CATALOG_DEMO', 'POLICY',
'CUSTOM:CATEGORY'
) AS CATEGORY,
DBMS_CATALOG.GET_TABLE_PROPERTY(
'LOCAL', 'CATALOG_DEMO', 'POLICY',
'CUSTOM:UPDATE_FREQUENCY'
) AS UPDATE_FREQUENCY
FROM DUAL;
実行結果を項目別に整理すると、以下のとおりです。
| SQLの列名 | 説明 | 取得結果 |
|---|---|---|
BUSINESS_NAME |
業務名 | 保険契約 |
DESCRIPTION |
業務説明 | 保険契約の基本情報を保持するテーブル。 |
OWNER_NAME |
管理部門 | 契約部 |
PII_FLAG |
個人情報区分 | NO |
CATEGORY |
データ分類 | 契約 |
UPDATE_FREQUENCY |
更新頻度 | Daily |
OWNER_NAMEとPII_FLAGはSQLのSELECT句で指定した列別名です。実際のカスタムプロパティ名は、それぞれOWNERとPIIです。
このように、1つのテーブルに対して複数のビジネスメタデータを管理できます。業務名だけでなく、管理部門や個人情報区分なども取得できるため、データカタログの詳細情報として活用できます。
7. 列レベルのカスタムプロパティを取得する
DBMS_CATALOGでは、テーブルだけでなく列単位のプロパティも管理できます。列のカスタムプロパティを取得する場合は、GET_COLUMN_PROPERTY関数を使用します。
今回は、データディクショナリのALL_TAB_COLUMNSと組み合わせて、POLICYテーブルの列名、データ型、業務名を一覧表示します。
SELECT
c.column_id,
c.column_name,
c.data_type,
DBMS_CATALOG.GET_COLUMN_PROPERTY(
catalog_name => 'LOCAL',
schema_name => 'CATALOG_DEMO',
table_name => 'POLICY',
column_name => c.column_name,
column_property => 'CUSTOM:BUSINESS_NAME'
) AS BUSINESS_NAME
FROM ALL_TAB_COLUMNS c
WHERE c.owner = 'CATALOG_DEMO'
AND c.table_name = 'POLICY'
ORDER BY c.column_id;
実行結果:
| COLUMN_ID | COLUMN_NAME | DATA_TYPE | BUSINESS_NAME |
|---|---|---|---|
| 1 | POLICY_ID | VARCHAR2 | 契約ID |
| 2 | CUSTOMER_ID | VARCHAR2 | 契約者ID |
| 3 | PRODUCT_ID | VARCHAR2 | 商品ID |
| 4 | AGENT_ID | VARCHAR2 | 代理店ID |
| 5 | START_DATE | DATE | 開始日 |
| 6 | END_DATE | DATE | 終了日 |
| 7 | PREMIUM | NUMBER | 保険料 |
| 8 | STATUS | VARCHAR2 | 契約状態 |
列名やデータ型といった技術メタデータに、業務名を組み合わせて取得できました。例えば、PREMIUMという列名だけでは意味がわからない利用者でも、BUSINESS_NAMEに「保険料」が登録されていれば、その列の用途を理解しやすくなります。
このような情報は、データカタログの列詳細画面や、データ分析時の項目説明などに利用できます。
8. カスタムプロパティを持つテーブルを動的に一覧表示する
ここまでは、対象のテーブル名を指定してカスタムプロパティを取得しました。実際のデータカタログでは、特定のテーブルだけでなく、カタログに登録されている複数のテーブルを一覧表示したいケースがあります。
このような場合に利用できるのが、DBMS_CATALOG.GET_TABLESです。GET_TABLESでは、カタログ内のテーブルを条件に基づいて検索できます。
今回は、BUSINESS_NAMEというカスタムプロパティが登録されているテーブルを検索し、業務名、分類、説明を取得します。
SELECT
t.table_name,
DBMS_CATALOG.GET_TABLE_PROPERTY(
catalog_name => 'LOCAL',
schema_name => 'CATALOG_DEMO',
table_name => t.table_name,
table_property => 'CUSTOM:BUSINESS_NAME'
) AS business_name,
DBMS_CATALOG.GET_TABLE_PROPERTY(
catalog_name => 'LOCAL',
schema_name => 'CATALOG_DEMO',
table_name => t.table_name,
table_property => 'CUSTOM:CATEGORY'
) AS category,
DBMS_CATALOG.GET_TABLE_PROPERTY(
catalog_name => 'LOCAL',
schema_name => 'CATALOG_DEMO',
table_name => t.table_name,
table_property => 'CUSTOM:DESCRIPTION'
) AS description
FROM TABLE(
DBMS_CATALOG.GET_TABLES(
catalog_name => 'LOCAL',
schema_name => 'CATALOG_DEMO',
conditions => '#BUSINESS_NAME'
)
) t
ORDER BY t.table_name;
ここで重要なのが、次の条件です。
conditions => '#BUSINESS_NAME'
#BUSINESS_NAMEは、BUSINESS_NAMEというカスタムプロパティが存在するテーブルを検索する条件です。これにより、テーブル名をSQLに列挙する必要がなくなります。
実際の検証では、22件のテーブルが取得できました。取得結果の一部を示します。
| TABLE_NAME | BUSINESS_NAME | CATEGORY |
|---|---|---|
| AGENT | 代理店 | 代理店 |
| AGENT_CAMPAIGN_RESULT | 代理店キャンペーン実績 | 販促活動 |
| AGENT_CONTRACT | 代理店契約 | 代理店契約 |
| AGENT_PERFORMANCE | 代理店営業評価 | 営業評価 |
| CUSTOMER | 契約者情報 | 顧客管理 |
| POLICY | 保険契約 | 契約 |
| POLICY_COVERAGE | 契約補償情報 | 契約 |
| POLICY_VEHICLE | 契約車両関連情報 | 契約 |
※ 上記は取得結果から一部を抜粋したものです。SQLではDESCRIPTIONも取得していますが、表の可読性を考慮して省略しています。
このSQLのポイントは、Oracle標準のDBMS_CATALOGパッケージだけで、登録済みのビジネスメタデータを持つテーブルを動的に取得できることです。独自のメタデータ管理テーブルを用意する必要はありません。
また、ALL_TABLESからすべてのオブジェクトを取得してプロパティを参照するのではなく、カタログの検索APIで対象を抽出している点も特徴です。
なお、#BUSINESS_NAMEはプロパティの存在を条件とするため、値が必ず有効な業務名であることまで保証するものではありません。
9. カスタムプロパティの値を条件に検索する
最後に、カスタムプロパティの値を指定した検索を試してみます。例えば、データ分類が「契約」のテーブルだけを取得したい場合です。
SELECT
table_name
FROM TABLE(
DBMS_CATALOG.GET_TABLES(
catalog_name => 'LOCAL',
schema_name => 'CATALOG_DEMO',
conditions => '#CATEGORY="契約"'
)
)
ORDER BY table_name;
実行結果:
| TABLE_NAME |
|---|
| POLICY |
| POLICY_COVERAGE |
| POLICY_VEHICLE |
分類が「契約」として登録されている3つのテーブルを取得できました。GET_TABLESのconditions引数を利用することで、カスタムプロパティの存在だけでなく、その値を条件とした検索も可能です。
例えば、特定の業務分類に属するテーブル、特定の管理部門が管理するテーブル、個人情報を含むテーブルなどを探す用途が考えられます。こうした検索を組み合わせることで、テーブル名に依存しない、ビジネスメタデータを利用したデータ探索を実現できます。
10. ビジネスメタデータの活用可能性
ここまで、DBMS_CATALOGパッケージを使ったカスタムプロパティの登録・取得・検索を紹介しました。登録したビジネスメタデータは、さまざまな用途に活用できます。
10-1. データカタログの構築
最も直接的な活用方法は、データカタログの構築です。テーブル名や列名などの技術メタデータと、業務名、説明、分類などのビジネスメタデータを組み合わせることで、データの意味を理解しやすくなります。
例えば、Oracle APEXを利用して、カタログの検索画面やテーブル詳細画面を構築することも考えられます。
10-2. 自然言語によるデータ探索
さらに、生成AIと組み合わせることで、自然言語によるデータ探索にも応用できます。
例えば、利用者が「保険契約に関するデータを探したい」と入力した場合を考えます。生成AIがテーブル名のPOLICYだけを見ても、それが保険契約を意味するとは限りません。しかし、カタログに「保険契約」という業務名や説明が登録されていれば、AIがデータの意味を判断するための追加情報として利用できます。
自然言語から検索条件を生成し、DBMS_CATALOGの検索APIを呼び出すことで、業務用語を使ったデータ探索を実現する構成が考えられます。ただし、これはDBMS_CATALOG単体の機能ではなく、生成AIサービスやアプリケーションとの連携によって実現するものです。
10-3. 複数データソースのメタデータ管理
DBMS_CATALOGは、ローカルデータベース以外のデータソースとの連携機能も提供しています。例えば、DB Link経由で参照するOracle Databaseや、対応する外部カタログを利用する構成が考えられます。
このような仕組みを利用すれば、メタデータを管理する側と、実際にデータを保持する側を分離できます。ただし、外部データソースに対するカスタムプロパティの登録・更新可否は、カタログの種類や対応するAPIによって異なるため、個別の確認が必要です。
11. アノテーションとの違いは?
Oracle Databaseには、テーブルや列に追加のメタデータを設定する仕組みとして、アノテーションも用意されています。アノテーションはOracle Database 23cから導入された機能で、データベースオブジェクトに名前付きの属性を付与できます。
一方、DBMS_CATALOGのカスタムプロパティは、カタログ側でメタデータを管理する仕組みです。両者の大きな違いの一つは、メタデータを保持する場所です。
アノテーションは対象となるデータベースオブジェクトに関連付けて管理しますが、DBMS_CATALOGではカタログを通じてメタデータを管理します。この違いは、管理対象のデータベースのバージョンや、複数データソースを横断して管理する場合に重要になります。
例えば、アノテーションをサポートしていないOracle Database 19cであっても、対応する接続方式でカタログ化できれば、カタログ側でビジネスメタデータを管理する構成を検討できます。
両者は単純な代替関係ではなく、用途によって使い分けたり、組み合わせたりすることが考えられます。この違いについては、次回の記事で詳しく紹介する予定です。
12. まとめ
今回は、Oracle DatabaseのDBMS_CATALOGパッケージを使って、ビジネスメタデータを登録・取得・検索する方法を紹介しました。
今回取り上げた内容は以下のとおりです。
| 機能 | 使用したAPI |
|---|---|
| テーブルプロパティの登録・更新 | UPDATE_TABLE_PROPERTY |
| 列プロパティの登録・更新 | UPDATE_COLUMN_PROPERTY |
| テーブルの業務名取得 | GET_TABLE_PROPERTY |
| 複数プロパティの取得 | GET_TABLE_PROPERTY |
| 列単位の業務名取得 | GET_COLUMN_PROPERTY |
| プロパティを持つテーブルの動的一覧取得 |
GET_TABLES + GET_TABLE_PROPERTY
|
| プロパティの値による検索 | GET_TABLES |
特に重要なのは、GET_TABLESとGET_TABLE_PROPERTYを組み合わせることで、独自のメタデータ管理テーブルを使用せず、Oracle標準APIだけでビジネスメタデータを持つテーブルを動的に検索・取得できることです。
これにより、テーブル名や列名といった技術メタデータに、業務上の意味を組み合わせたデータ探索が可能になります。また、ビジネスメタデータを整備することは、データカタログの構築だけでなく、生成AIによる企業データの理解や自然言語検索への応用にもつながります。
次回は、Oracle DatabaseのCOMMENT、アノテーション、DBMS_CATALOGの違いを比較し、メタデータの管理場所、データベースのバージョン、外部データソースへの対応といった観点から、使い分けを整理したいと思います。