2009年11月16日 「実践編-12　実装形の作りかた」 を読む >> 目次にもどる
2018年 9月 1日 補遺 　


　

　文法 （生成規則・指示規則） に従って構成した モデル を できるかぎり そのままに実装するのが基本ですが、モデル を実装する際に、いくつかの調整点があります。その 「典型的な」 例として、以下の 3つを示していますが、それらのほかにも考慮したほうがいい点があります。

　　（1） 対照表
　　（2） サブセット
　　（3） みなし entity

　以上の調整点については、「赤本」 の説明を読んでもらうとして、ほかの考慮点を以下に述べてみます。
　なお、サブセット の実装形は、「赤本」 で説明した やりかた 以外にも やりかた があるので、本 ホームページ の 「データ 設計に関する FAQ」 を参照してください （本 ホームページ の 213 ページ）。

　実装形を いったん作成したあとでも、多量 データ を ストア している テーブル に対して高 パフォーマンス を もとめられている場合には、その テーブル を分割する場合があります──ただし、「INDEX-only」 を使っている、という前提です。モデル を作成したときに、構文論的・意味論的に完全である テーブル は、その状態が 「最小の意味単位」 なのですが、高 パフォーマンス を実現するために、意図的に いっそう分割する、ということです──したがって、「（完結した） 意味」 を崩した状態を作る、ということです。

　たとえば、以下の テーブル を使って、意図的な テーブル 分割を説明してみます。

　TABLE
　　( a, b, c, e, f ).

　「INDEX-only」 を前提にします。この テーブル に対して、index-key が すでに 5つ定義されている、とします。
　たとえば、以下のような index-key が定義されている、とします。

　　( a, b, c, e, f ).

　　( b, e ).

　　( c, f ).

　　( a, c ).

　　( f ).

　ちなみに、（使っている コンピュータ の CPU や メモリー 量にも依りますが、） ORACLE や DB2 では、高 パフォーマンス を実現するのであれば、UPDATE の対象になっている ひとつの テーブル に対して index-key は 5つ以内にしたほうが良いでしょう──なお、SQL/Server や PostgreSQL では、3つに止めたほうがいいでしょう。この テーブル に対して、以下の view を もとめられた、とします。

　　( c, a, f ).

　勿論、「INDEX-only」 で対応します。しかし、この テーブル に対して、index-key は、すでに 5つ定義されているので、それ以上の index-key を定義すれば、パフォーマンス に影響するかもしれないので、テーブル を以下のように分割したほうがいいでしょう。

　TABLE-1
　　( a, c, f ).

　TABLE-2
　　( a, b, e ).

　これらの テーブル では、以下のような index-key が定義されます。

　TABLE-1 に対して、

　　( c, a, f ).

　　( c, f ).

　　( a, c ).

　　( f ).

　TABLE-2 に対して、

　　( b, e ).

　そして、TABLE-1 と TABLE-2 を a で join して、TABLE を 構成します。
　そうすれば、TABLE-1 と TABLE-2 は、それぞれ、index-key を 5つずつ定義できるので、さらに、それぞれの テーブル に対して view をもとめられても 「INDEX-only」 で対応できます──index-key を定義できます。

　上述した例は、説明を簡単にするために view を使って説明したのですが、UPDATE も 当然 考慮して テーブル を分割します── commit を考慮しなければならないので。実地の設計では、それぞれの データ 項目を見極めて テーブル を分割してください。本文で私が謂いたかった点は、高 パフォーマンス を実現するために、時として、「最小の意味単位」 を さらに分割することもある、ということです。現場では、それを標語にして以下のように云っています。

　「（高 パフォーマンス を実現するには、テーブル を） ちぎって、ちぎって、ちぎる」 □

　



[ 補遺 ] （2018年 9月 1日）

　私が講師をしている モデル 技術の セミナー に対して、「実装形」 について語ってほしいという要望が 多々 出されますが、私自身は 「実装形」 について それほど拘っている訳ではない──「実装形」 について、私が一つ拘っている点は、「（F-真が いったん験証されたならば、） 実装形は どのような L-真の形を採ってもいい」 ということです。つまり、事業分析において F-真を いったん験証したならば、データ 構造は複数存在する L-真のいずれを使ってもいいというのが私の基本的態度です。ただし、L-真を崩すことは認めない。

　たとえば、次のような モデル があるとする──出荷してから請求する、という基本的な事業形態であるが、或る商品に対しては、請求してから出荷するという形態を導入しているとする。

　出荷
　｛ 出荷番号、商品番号 (R)、出荷日、出荷数、... ｝──────────────────┐
　　　　　┼　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 │
　請求　　┼　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 │
　｛ 請求書番号、出荷番号 (R)、請求日、請求金額、... ｝─┐　　　　　　　　　　　　　　│
　　　　　　　　　　　　　　　　　　　　　　　　　　　　 ├×─ 請求　　　　　　　　　 ├×─ 出荷
　請求　　　　　　　　　　　　　　　　　　　　　　　　　 ┘null （出荷番号、商品番号） │null （請求番号、商品番号）
　｛ 請求書番号、商品番号(R)、請求日、請求金額、... ｝　　　　　　　　　　　　　　　　 │
　　　　　┼　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 │
　出荷　　┼　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 　│
　｛ 出荷番号、請求番号 (R)、出荷日、出荷数、... ｝──────────────────┘
　事業分析の モデル では、この記述が F-真かつ L-真ですが、データ 構造としては、クラス （スーパーセット の 「請求」 「出荷」） で実装するかもしれない──すなわち、null 在りの状態で実装するかもしれない [ ただし、null が生じることは アトリビュート・リスト の 「制約・束縛」 欄に記述されている ]。

　どのような実装形になるかは、使っている ツール （OS、データベース、プログラム 言語あるいは フレームワーク など） の設計思想や機能に依存します。使っている ツール の設計思想や機能を加味して モデル を調整することを物理設計と云っています。

　たとえば、データベース が 「べつべつの物理 ファイル を一つの論理 ファイル として扱うことができる」 ような プロダクト なら、前述した モデル を例にすれば、クラス （スーパーセット） で実装しないで下位の 出荷・請求をそれぞれ実装して、データベース 自体が クラス の状態を扱っているでしょう。そういう機能を搭載していない データベース を使うのであれば、クラス （スーパーセット） の状態で実装しかない。要するに、プロダクト の機能を加味して実装を決めるということです。

　性能のいい データベース を使って プログラム の ソース・コード のすべてを プログラマ が作成するのであれば、F-真の モデル をそのまま実装形にするのが理想なのですが、たぶん、現代では、フレームワーク などの プログラム 生成 ツール を使っていることが多いでしょう。そうであるならば、フレームワーク の設計思想や機能を加味して、モデル を調整するのは当然でしょうね。

　私が関与している client であれば、client が使っている ツール を私はわかっているので、実装形を どうすればいいかを指導できるのですが、私が関与していない場合には実装形を どのようにすればいいかを語ることはできない。だから、私は、セミナー では実装形を語ることをしない [ できない ] のです。






　 << もどる HOME すすむ >>
　 目次にもどる