チェンジビジョン平鍋が「リソース系の顧客および商品、とイベント系の注文をつなぐパ­ターン」を易しく紹介します。
前回の「パターン編(1) 注文書を表現するヘッダー明細パターン 」の続きです。

モデリングしてますか？

前回は、ヘッダー明細パターンという事で、「注文」と、「注文明細」、もう少し詳しくいうと、このような「注文書」の中で、この「注文明細」と、全体の「注文」の関係について解説をしました。今回は、前回登場しなかった「商品」という概念について、今回は詳しくお話ししたいと思います。

「商品」という概念とは？

ここには「注文明細」とありますが、注文の1行は、1つの商品と紐付いています。
そのため、「商品」という概念を登場させます。

このように注文明細の中にある「タオル」という注文に対して、「単価」「数量」「金額」がありますが、この「商品」をモデリングすると、このようになります。「商品名」と「定価」という風に、データ構造しておきます。

ここで、「単価」と「定価」は重なるのですが、場合によっては「定価」から値引きをする場合があるので、このような形にしておきます。「注文明細」から見ると、「商品」は1つと決まっていて「商品」から見ると、「注文」は複数対応する事があるというパターンになります。

「モノ – コト – モノ」パターン

ここからが面白いんですが、両脇にある「顧客」と「商品」は割と長く存在しているものです。
「注文」とは、一時のものです。

このような「顧客」や「商品」の事を、「リソース」という言葉で表す事があります。

それから、「注文」は、寿命が長い2つのオブジェクト（リソース）の間にあって、一時のトランザクションを示すものを、「イベント」と呼ぶ事があります。このように2つのリソースを、結びつけて1つのイベントが起こるというパターンは、非常によく起こる事ですね。

ここをヘッダー明細パターンといいましたが、色々よび方がありますが、この事を、児玉さんは、「モノ – コト – モノ」パターンという非常に良い名前をつけています。

また、企業の情報システム構築のデータ構造では、このパターンは非常によく出てきます。
リソース2つがあって、真ん中にイベントがある。特徴は、イベントには必ず「日付」があるという事ですね。

それから、前回お話しできなかったのですが、この「注文明細」の合計が「注文」になります。そのため、「注文金額」というのは、実際には「注文明細」から掛け算して、足し合わせたものになるので、自動的に決まりますね。これを、「派生属性」と呼んで、斜線で表します。

応用がきくパターン

まとめると、よく見る「注文書」とは、1つの注文の明細になっています。「件名」と「金額」が、1つの注文になっています。
また、注文の「日付」があり、「合計」金額があります。これは、ヘッダー明細パターンと、「モノ – コト – モノ」パターンの組み合わせで、真ん中に「注文」として「コト」が出てきます。

とても分かりやすい例ですし、応用がきくので、他にも使えると思います。
ぜひ応用してみてください。

では。

Published by Satomi Joba

View all posts by Satomi Joba