今日も見に来てくれて、ありがとう。励みになります♪
先日「エンティティ」という単語を何となく使ってしまいましたが、それほど一般的なことばではないよねぇ、ということが気になっていて、ちょっと補足したいと思います。
ぼくが初めてエンティティということばを聞いたのはいつでしょうかねぇ、たぶん、システム開発の中で必要だと言われていた、「ER図（Entity-Relationship-Diagram）」というドキュメントからでしょうか。日本語では実体関連図、と翻訳されています。ぼくはこの図を見たとき、リレーショナルデータベースのテーブルとその関係を表す図になっていたので、単純にこう思っていました。
エンティティ ＝ テーブル リレーションシップ ＝ テーブルとテーブルの関係
システム開発の製造工程、プログラムを作成するうえでは、この理解で充分でした。画面や帳票があって、どのテーブルのどの項目が画面や帳票とマッピングされるのか、どんな条件で取り出せばいいのか、ということさえわかればプログラミングできたからです。当時はほとんどのひとがそんな認識だったんじゃないかなぁ。どうしてそんな風になっていたかというと、当時、リレーショナルデータベース(RDB)は新しく登場した概念だったし、システム開発においては、単なるファイルに替わるものとして利用されていたからだと思います。画面のプログラムを作るためにはそこに表示するデータを格納するためのテーブルが必要で、これがなかなか決まらなくて、苦労していたのをよく覚えています。
TM（T字形ER手法）を習ったときには、エンティティは以下の通り定義されていました。あまりにも簡単で明快！でも、それまでモヤモヤしていたのがスッキリしました！
エンティティ：管理したい対象で、認知番号があるもの
当時「認知番号」は、個体指定子と言われていました。英語では、entity-setterです。その前は、identifierと言っていました。日本語だと「識別子」という意味になるのですけど、あまり適切な訳ではないということで、当時はidentifierを英語のまま使っていたということでした。このあたり、佐藤正美先生（TM（T字形ER手法）の考案者）が考えられることですので、またちょっとしたら呼び名は変わるかもしれません。いずれにせよ、簡単に言うと、認知番号は、番号、No、ID、コードがついた項目で、これらをもとにエンティティを作る、ということになります。例えば、以下のようになります。
認知番号：顧客番号 → エンティティ：顧客 認知番号：商品No → エンティティ：商品 認知番号：店舗番号 → エンティティ：店舗 認知番号：取引ID → エンティティ：取引
「エンティティ＝テーブル」と思い込んでいて、テーブルって、何を基準に作るんだろうねぇ、と思っていたぼくにはかなりの衝撃でした。それまでぼくが知っていたエンティティは実体と訳されていて「業務におけるひとまとまりのモノ」みたいに言われていたのです。「モノ」ってなんなんだよ、誰がどうやって決めるんだよ！というぼくの疑問のような不満なような問題は、簡単に決着がついたわけです。
この衝撃の事実を知ったことで、うれしくなったぼくは、ずっといろんなひとに説明して回っていたのですけど、あるときなんと、「そんなの当たり前のことでしょ。どうして大発見みたいな感じなのか、よく分からないんですけど？」というひとが現れました！ぼくにとってのこの大発見は、プログラムもテーブルも作ったことがないひとからすると、別に声を大にして言うようなことでもなんでもなくて、自然なことだったようです。む～、確かに！余計な前提知識があったために、ずいぶんと遠回りしちゃったようです。もうちょっと、素直になろう♪