以前、業務をまとめたシートについて書いたとき、入出力を自動的にまとめて、ＥＲをだすところは、また今度にしておこうと書いたのですが、それを書くには、
・入出力を、シート上でどう表現するか
をまず書かねばならず、さらにそれを書くには
・入出力は、どういう種類と構造になっているか
を書かないといけないことに気づいてしまいました。
そこで、今回はまず、「入出力は、どういう種類と構造になっているか」について書きたいと思います。
■入出力の種類
入出力というと、ＭＶＣモデルで考えると、
Ｖｉｅｗに相当する画面（あるいは帳票）、
それとＭ（モデル）において、永続的なデータを保存するファイル、ＤＢ
が、多くは、それにあたる。
もちろん、これ以外にも、シリアルポートからの電気信号出力などもありえる。
これは、データ入出力とよんでおこう。
そうすると、入出力は、
画面
帳票
データ入出力
ファイル・ＤＢ
という種類にわかれる。
■ファイル・ＤＢは、リソースとイベントにわかれる。
ここで、画面や帳票は、電子化すると、ファイルやＤＢに置き換えられる
データ入出力もファイルやＤＢに置き換えられる。
ということで、情報は、ファイルやＤＢにまとめることができる。
このとき、ファイルやＤＢは、
１つのまとまったモノや事柄をあらわしているもの
それが複数あつまっているもの
にわけられる。
「１つのまとまったモノや事柄」というのが、エンティティという。
このエンティティは、１つのモノや事柄と認識でき、番号付けをすることができる。
（これが、主キーを持っているということ。また、主キーが決まった場合、このエンティティを特徴付ける値は決まってしまう。これが、第二正規形といわれるものである）
エンティティには、モノの場合と事柄の場合がある。
モノは、物体なので、リソースと呼ぶ場合がある
事柄は、イベントと呼ばれる。
■イベントのエンティティは、なぜありえるのか
ここでオブジェクト指向で考えると、エンティティは、クラスとなりえる。
リソースは、問題ない。ものは名詞なので、これはクラスになりえる。
でも、問題なのは、イベントだ。
イベントは事柄である。
つまり、受注とか、発注とか。。
でも、これは、動詞にもなりえる。受注する、発注する。。。
もし、動詞なら、それはメソッド（操作）として、存在するはずだ。クラスではない。
このイベントのエンティティのクラスとメソッドの切り分け
（受注クラスを作るべきか、受注メソッドになるべきか）は、どうなるのか？
もし、この切り分けがないとしたら、そもそも、
イベントのエンティティは、なぜありえるのか？という話になる。
■イベントのエンティティは、永続性で決まる
これは、話を元に戻すとわかる。イベントのエンティティは、ファイル・ＤＢを
考える中ででてきた。ファイルやＤＢがなぜあるのかというと、それは、永続性を
もつためだ。
永続性とは、パソコンの電気をポチッとなってきって、そのあとまた付けても、
その情報はのこっていないといけないものである。
たとえば、受注。
もし、永続性がないとすると、受注は、自分のパソコンの電気を切ったとたんに消える。
そーすると、お客さんから「この前頼んだ、商品、こないんですけど、お金振り込んだのに」
「あ、ごめんなさい。パソコンの電気切っちゃったんでわかんないです」
といったら、たぶん、客から殺される（うそ、殺されはなしなけど、問題がある）
なので、受注データは永続性を持たせないといけない。
ちなみに、モノも永続性がある。あんまり、従業員がパソコンの電気を切った途端に消えることはない。たぶん。
ところが、メソッドは処理をしてしまうと終わりで、基本的に永続性はない。
ということで、永続性のあるイベントは、モノと同様クラスとして、さらにファイルやＤＢにいれるということになる。
しかし、このイベントにおけるメソッドとクラスの差は微妙である。
なぜなら、その判断は、永続性になるからだ。人によって、永続性は違う。
今目の前にＳｈｏｐ９９のレシートがあるが、レシートを残しておく人と（永続性）すぐに捨てちゃう人と、いろいろいる。このように、そのイベントを永続的にのこすかどうかは微妙な場合もある。
■エンティティには、属性値がある
エンティティは、１つのモノ（や事柄）として独立しているが、それだけでは、処理ができない。モノのある側面を数値化、文字化、見える化して、処理する。
たとえば、１０人人をあつめて、この中で若い人といったとき、直感で決めるということは、少なくともコンピューター処理ではしない。コンピューターに直感はない。多分。。。
なので、その１０人の人を、生年月日という切り口で、数値化し、それを比較する。
このエンティティに対して、ある側面を数値化、文字化、見える化したとき、その側面（上記の例だと生年月日）を属性といい、数値化、文字化、見える化したものが属性値である。
したがって、エンティティは、属性を複数持ち、それぞれに、たいてい値はある（ない場合（値がNULL)もありえる）。
■項目名は、エンティティ.属性の形に、たいていなる
さて、コンピューターで処理するとき、項目名は、たいていは（というか、そういう命名規約になっているときもあるが）エンティティ.属性の形で表す。
受注番号とは、受注エンティティの番号であり、
商品名は、商品エンティティの名（名前）である。
前に、エンティティはリソースとイベントに分かれるといったが、
・リソースの場合は、たいてい、
エンティティ”の”属性
といえる。
例従業員氏名＝従業員の氏名、商品単価＝商品の単価
・一方イベントの場合は、上記の”の”でもいえるが、
エンティティしたとき（するとき）の属性
になる。
例：受注番号＝受注したときの番号
なお、実際には、エンティティ.属性の項目名を属性といってしまう。
また、エンティティ.エンティティ.属性のように、エンティティがいくつかつながることもある。この場合、エンティティに関連がある。
例：受注商品単価（受注.商品.単価）
■まとめ
ということで、まとめると、入出力には、
とあって、これらはすべて、
エンティティ.属性
という形であらわせられる。ちなみに、入出力とあわせると、こんなかんじ
エンティティ 属性 画面 各画面 画面の各項目 帳票 各帳票 帳票の各項目 ファイル ファイル名 ファイルの各項目 ＤＢ テーブル 各項目 データ メッセージ メッセージ内項目
って説明したので、やっとシートに展開できる。。。
アクセス
トータル
ランキング
