前回はブロックチェーン技術の活用事例として、サプライチェーン全体にまたがるトレーサビリティ管理を実現するシステムの概要を紹介した。EDI（Electronic Data Interchange）を含む複数企業の業務システムを、ブロックチェーンを通じて連携させるものだ。
今回はブロックチェーンを使ったシステム開発の具体的なノウハウを明らかにしたい。トレーサビリティ管理を例に、リコールなどに備え商品データを管理するデータモデルの設計を取り上げる。
ブロックチェーンは台帳を記録・参照する技術であり、データモデルの設計は記録・参照の処理性能や使い勝手を決める重要な要素となる。
我々はパーミッションド型の代表的なブロックチェーン基盤であるHyperledger Fabricを用いたトレーサビリティ管理のプロトタイプシステムを実際に開発した。この知見を元に、データモデル設計のコツを従来のRDB（Relational Database）と比較しながら解説したい。
KVSによるデータ記録
これまでの連載で紹介したとおり、ブロックチェーンとは複数の取引をブロックとしてまとめ、数珠つなぎに記録する分散台帳の仕組みである。その際、スマートコントラクトと呼ばれる事前に決められたルール（Hyperledger Fabricではチェーンコードと呼ばれる）に従い自動的に履行する仕組みを介して、台帳のデータを読み書きする。
Hyperledger Fabricを含む多くのブロックチェーン基盤では、台帳はKVS（Key-Value Store）と呼ばれるデータの保存・管理方式により実装されている。我々が開発したトレーサビリティ管理のプロトタイプでは、製造・商品売買を記録した伝票データは以下に示すようなJSON （JavaScript Object Notation）形式の文字列として記録している。
記録したデータを頻繁に参照するアプリケーションを開発する場合、データの記録形式次第で性能が左右される。KVSはRDBと異なり、アプリケーション側から台帳へのアクセス手段はキーによるサーチとストア処理のみに限られる。Hyperledger Fabricの場合、台帳へのアクセス手段は以下の4つのパターンに整理できる。
記録したデータを頻繁に参照するアプリケーションでは、属性値（Value）の参照回数が多くなると性能に影響が出る恐れがある。そのため、属性値を台帳から取得した後に必要かどうかを判定するのではなく、事前にキーを参照して必要なデータかどうかを判別し、必要な属性値のみを取得できるようなデータモデリングが重要になる。
ノウハウ（1）キーの名称規則で参照データを絞り込む
開発したプロトタイプシステムでは、データのキーに名称規則を設けることで参照するデータを事前に絞れるようにした。
例えば伝票データにキーを付与する際、"ORD-"+"数字"という規則を用いることにより、"ORD-1", "ORD-2",…"ORD-NNNNN"と順に検索していけば、伝票データを列挙できる。台帳へは様々なデータが書き込まれるため、キーにプリフィックス（文字列の先頭に付ける符号）を付与して管理することが重要となる。プリフィックスに続く文字列は、例えばソートが必要なアプリケーションの場合、ソートを意識してフォーマットを決定する必要がある。
さらに命名規則を多段にすることで、様々な用途に応じて参照するデータを絞れるようになる。そのためにはまず、扱うデータをツリー状に分解して検討する必要がある。そのうえで、ツリー状のデータモデルが実際に開発するアプリケーションの参照仕様を十分に満たすかを見極めることが大切である。以下、プロトタイプシステムが持つ商品データを例に説明しよう。
商品データが持つ属性値は、メーカID、型式、製造番号の順に枝分かれする形で付与されていく。このようにツリー状のデータモデルを決めたうえで、プリフィックス（"PROD"）にツリーの枝分かれの順に属性値を連結してキーを作成した。その結果、キーに"PROD＋メーカID＋型式"を含むインスタンスでKVSを検索することで、「特定メーカー」の「特定型式」に該当する全商品のデータを列挙できる。一方で"PROD＋メーカID"で検索すると、「特定メーカー」の全商品データを列挙できる。
この例では、商品データのメーカIDと型式、製造番号が決まると、商品を一意に特定できる。そのため、これらの情報をキーとしてデータを管理する場合、他の情報（例えば製造日など）は属性値として記録することになる。
一方、アプリケーションに特定の製造日を持つ商品データを検索する機能がある場合、以下のように「製造日」も含んだデータモデルとすればよい。
この場合、“PROD＋メーカID＋型式＋製造日”で検索を行うと、「特定の製造日」に製造された全ての商品データを列挙できる。このように、ツリー状のデータモデルを検討する際は、アプリケーション側の検索要件を反映した形にする必要がある。
