DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

今回は、DBスキーマ内のデータ操作を図式化する方法を紹介してみたい。多少なりともデータベースに触れた方であればSQLがあれば良いのでは？と思われる人も多いと思われるが、SQLは言語であり図表現ではない。SQLコーダーはSELECT文を書きながら、DB関係演算におけるデータの集合（コレクション）をイメージしている。本ブログでは、このイメージを図表現する道具として、SQLが世の中に登場する以前から存在する”SPF（Schema Process Flow）チャート”なる物を紹介したい。本ブログシリーズのバックナンバーでも2014.7.28「業務アプリ指向」、2014.12.3「攻めへの布石（マスタ変換ブリッジ）」などでこのSPFが登場しているが、今回はその全容を公開したい。

そもそも、このスキーマ操作モデルは（株）データ総研・元会長の椿氏によるもので、先生のTHモデルと並ぶ発明であると言える。1982年、私はこの発案のモルモットとして基幹系システムの数百本のプログラムをSPFで表記した。その後、1990年代にも大規模基幹系システムのメインロジック記述に採用し、コーディングをアウトソースした実績がある。図1に基本的な12個のデータ操作記号を、Before→Afterのレコード変化の例とともに記載したので、ご覧いただきたい。属性（Attribute）の並びはレコードの変遷を縦に繋げて記述できるように横書きとなっている。E.F.Coddによるリレーショナル演算のP（射影）、E（選択）、J（結合）などをベースに、現実のビジネスアプリケーションで登場するあらゆるデータ操作をカバーすべく拡張した物だ。D（導出）、S（サマリー）、Ｕ（更新）は頻繁に登場するし、G（汎化）、Sp（特化）はレコード縦横変換にしばしば用いられる。また、Dy（ダイナミックジョイン）やM（マージ）も時々登場する。通常はレコードデザインの変化を伴うが、最後の、Csソートに至ってはご愛嬌だ。（図1の操作記号は82年当時の前職のものを掲載しており、先生のモデルはその後進化を遂げ多少表記は変わっている）。

どうであろうか、このSPFチャートからSQLのSELECT 文によるWHERE 句、JOIN句、UNION句などが彷彿とされるはずである。英語を母国語としない日本人がSQLより先に思いついた普遍性の高いものである。おそらく、ここに記載された操作以外の操作記号は必要なく、これらの組み合わせで全てのレコード処理を表すことができる。レコード操作以外の四則演算等はSPFチャートの該当箇所に※印を付与して、別紙に補足説明するなどの工夫をすると見易いものになる。 一見、バッチ処理に向いているように思われがちだがオンライン処理も記述可能であり、画面内の明細行を仮想レコードと位置付け、徐々に値が埋まり最後にU（更新処理）に至るといったバッチ処理と逆の流れ図になる。さらに、このSPFチャートのもう１つの重要な役割として、“DB設計の検証”がある。SPFチャートを用いてユーザVIEWを導こうとした際に、どうしてもそれができないケースは、DB設計に何らかの問題があるという事になる。DB設計がユーザVIEWからのある種リバースエンジニアリングとすれば、SPFチャートはフォワードエンジニアリングと位置付けられる。

ところで、非構造化NoSQL-DBが活況を呈してきた今日、今ごろ何で擬似SQLかと思われる読書もいると思われる。しかし、NoSQLはSQL不要論ではなく、近年では Not Only SQLの略と捉える向きが多く、完全にSQLに置き換わるものではないとの認識が一般的である。NoSQL-DBはACID制約を犠牲にせざるを得ないような大容量の処理や、構造が非定型なデータ格納に向いているが、現時点の企業内基幹系システムでは未だRDBに頼るところが大きい。また予め定義されたスキーマを持たないNoSQL-DBこそ動的に生成されるレコードの意味を可視化する必要性があるのではないかとも思われる。

「PG自動生成ツールを使えばそんなものは必要ない」、「SQL記述でプログラムを内製するから問題ない」とおっしゃる向きもいるかもしれないが、大規模エンタープライズ・システムの全てを内製する事は不可能に近い。ユーザVIEWと格納スキーマの間をSPFチャートのような図で表す事は、プログラム製造をアウトソースする際に極めて有効である。多くの企業で、文書による（議事録の如き）ロジック説明書を書き続けているのを今も目にするが、システムの見える化には、ルールが定まった科学的図表現（＝モデル図）をベースに、これに言語表現を付加したものが、第三者にとって最も理解し易いのではないだろうか。