データ関連の仕組み

ここでは、Hexabase でデータベース間を関連付ける仕組みについて解説します。

データベース関連とデータリンク#

「データベース関連」とは、データベース間の関係性を定義したものです。

「データリンク」(アイテムリンク)とは、データベース内の各アイテム同士の関連を表したものです。

関連はそれぞれ方向を持っており、関連元データベース ⇒ 関連先データベースとして設定します。双方向の関連を持たせるには、それぞれの方向で設定する必要があります。

データベース関連とデータリンク

関連先データベースは、アプリケーションをまたいで設定できます。これは、次のようなケースで利用できます。

  • 共通マスタアプリケーションがマスタデータを持ち、各業務アプリケーションで参照する
  • 販売アプリケーションのデータを仕入アプリケーションで参照する

データベース関連の設定#

データベース関連の設定は、関連元になるデータベースで「データベース関連の設定」を行います。

データベース関連の設定

関連データの表示#

データベース関連を設定すると、アイテム詳細画面の『関連データ』タブに、関連するデータベースの一覧が表示されます。

関連データの表示

データリンクとは#

データリンクは、データアイテム(レコード)間の関連を表しています。ただし、一般的な RDB とは仕組みが異なり、大量のデータを処理することを優先して、ACID 特性を担保していません。

一般的な RDBHexabase (NoSQL)
関連の保持双方テーブルのキーフィールドを指定し、論理的に関連をもつ。関連データの実体を持たない。それぞれのデータアイテムごとに関連の実体データ(Item_links)を持つ。
テーブル間の結合検索SQL 発行時に、各テーブルデータを検索して、JOIN する。データ量や構造によってパフォーマンスが劣化するケースがある。クエリ実行時に、実体の関連データをたどって JOIN するため、高速。
データ登録・更新・削除時の挙動テーブルデータのみを更新し、関連情報の更新は発生しない。更新データをもとに、関連データを Update する。
リアルタイム性 ACID 特性ACID によるデータ整合が完全に担保される。関連データが作成されるまでの間に多少のタイムラグが発生

※論理設計では、どちらも、E-R 表記による表現が可能です。

※業務データの特性上、ACID 特性が必須要件となる場合には、外部マイクロサービスを開発することが適切な場合があります(例えば、在庫引き当てサービスなど)。 開発を省力化する部分は Hexabase の既存 API を最大限活用し、他で補完が必要なケースは『部品としてサービスを切り出す』という発想でマイクロサービスを設計します。

データリンクの作成方法#

データリンク(関連)を作成するには、3つの方法があります。

  1. API によるリンク生成
  2. アイテム登録時の関連データ指定
  3. バックグラウンドで自動リンク生成

API によるデータリンクの生成#

主に、以下3つの API でデータのリンクをプログラムから作成・更新・削除可能です。

  • Add アイテム Link
  • Update アイテム Link
  • Delete アイテム Link

APIによるデータリンクの生成

アイテム登録時の関連データ指定#

Hexabase API では、1つの JSON リクエストで、複数のリンクされたアイテムを作成・更新・削除できます。これは、ヘッダ+明細データの更新などに利用できます。

ExecuteAction API

/api/v0/applications/:app-id/datastores/:datastore-id/items/action/:item-id/:action-id

APIによるデータリンクの生成

JSON の例

POST https://api.hexabase.com/api/v0/applications/TestApp/datastores/TODO-SAMPLE/items/action/:item-id/:action-id
"comment": "test-comment",
"return_アイテム_result": true, // true指定すると、更新されたアイテム情報を返します
"アイテム": {
"5e256923aeae8e212cb2e03b": "value", // text tyepe
"58bbaa27fbfcba6098746061": "5d4c058baa39555618ac9e98", // select type
"58bbaa27fbfcba6098746067" : [ "58bbaa27fbfcba6098746015", "596e2327fbfcbab8283dde09"], // checkbox type
},
"rev_no":8, //現在のrevison番号
"related_ds_アイテムs" : { // 関連するデータストアの新規・更新・削除を指定
"RELATED_DS_1" : [
{
"operation" : 1, // new
"action_id" : "", // new actionID ※省略可 (省略するとデフォルトの新規アクションが利用される)
"アイテム": {
"FIELD_ID1" : "data",
"FIELD_ID2" : "data",
"FIELD_ID3" : "data",
"FIELD_ID4" : "data",
},
"related_ds_アイテムs" : { // related_ds_アイテムsをネストさせることも可能。(同一Datastoreの複数ネストさせることは不可)
"関連データストアID_3" : [{ },{ },{ },{ }... ] ,
}
},{
"operation" : 2, // update
"action_id" : "", // update actionID ※省略可 (省略するとデフォルトの更新アクションが利用される)
"i_id" : "58bbaa27fbfcba609874aaa3f", // 対象アイテムID
"アイテム": {
"FIELD_ID1" : "data",
"FIELD_ID3" : "data"
}
},{
"operation" : 3, // delete
"action_id" : "", // delete actionID ※省略可 (省略するとデフォルトの削除アクションが利用される)
"i_id" : "58bbaa27fbfcba609874aqr45", // 対象アイテムID
},{
// 関連する複数アイテムを指定可能。sample 省略
},{
// 関連する複数アイテムを指定可能。sample 省略
},{
// 関連する複数アイテムを指定可能。sample 省略
}
]
"RELATED_DS_2": [ ... ]
"RELATED_DS_3": [ ... ]
}
}

operation パラメータを渡すことで、新規・更新・削除の挙動を指定します。

  • 1 // 新規
  • 2 // 更新
  • 3 // 削除

APIによるデータリンクの生成

バックグラウンドで自動生成#

Hexabase では、データベースにあらかじめリンク設定をしておくことで、自動的にデータリンクを作成できます。このとき、フィールドの値が同じアイテムを見つけ出してリンクします。

バックグラウンドでの自動生成

データリンクキーの設定#

バックグラウンドで自動的にデータリンクを生成するには、「データリンクキー」を指定しておきます。データリンクキーは、データベースをリレーションするキーフィールド(外部キー)です。

利用するには、データベースの「データリンクキー設定」で、アイテムに付与するデータリンクキー名を定義します。

データリンクキーの設定

複数フィールドで結合する#

データリンクキーでは、複数のフィールドを結合した値により、データリンクを作成できます。

複数のフィールドを結合

複数データベースのデータ更新#

複数データベースのデータ更新には、ExecuteBulkAction API を利用できます。

  • ExecuteBulkAction API
    • ExecuteBulkAction:条件を指定して、アクションを一括実行する
    • Method:POST
    • Request URL Format:/api/v0/applications/:app-id/datastores/:datastore-id/items/bulkaction/:action-id

指定した条件にマッチした対象アイテムに対して一斉にアクションを実行し、アイテムに更新とコメントを付与します。

一括でステータスを変更するような利用シーン(一括承認、など)や、一括でフィールドの値を一斉更新する場合などで利用可能です。

同時処理実行件数は デフォルトで 100 件です。max_items パラメータで最大 300 件まで指定が可能です。

continue_proc オプションを true にすると、対象が最大件数を超えた場合に最大件数まで更新をおこないます。結果 JSON に含まれる matched = processed となるまでこの API を複数回実行することで、全件の更新が可能です。

この API で更新されたデータは常に最新の rev_no を判定して更新します(force_update オプション= true として実行し、排他制御はされません)。

※失敗した場合のリトライやロールバックする仕組みがないため、定期的に不整合なデータをチェックしたり、失敗した場合のリトライプログラムなどを実装するか検討したほうが良いでしょう。