関数従属性は統辞論的（シンタックス的）か

モデリングのスタイル：意味論と統辞論について
上記でERモデルを作成する方法として、『関数従属性』を利用する方法と『リソース・イベントを区別』する方法について言及されています。

いくつか気になる点があり、その中でも「関数従属性」が「統辞論的な枠組み」としている点について、以前から関数従属性の判断は案外難しいと感じていたので興味もあって少し考えてみました。

ここでは、ある属性が関数従属しているかの判断を統辞論的（シンタックス的）にできるということをいっているのか、関数従属が判断された属性をシンタックス的に正規化できるとしているのか良く分からなかったのですが、前者については従属しているかの判断はケースごとに違う可能性があり意味的な判断が必要だと思っています。
ER図を作成する上ではもちろん前者・後者両方行う必要があり、関数従属性は統辞論的（シンタックス的）とするのであれば、ある属性が関数従属しているかの判断をシンタックス的にできる必要があるのではないかと感じました。
もちろん、意味論にも判断基準が明確で利用しやすいもの そうでないものがあって、関数従属は比較的直感的で分かりやすいという意味でシンタックス的としているかもしれませんが、やはり意味論を利用していることには変わりはないと思います。

イベント・リソースの判断は難しいのか

最終的にはイベント・リソースや関数従属性は手がかりの１つということで総合力勝負という結論になっているので、決して関数従属性が万能でイベント・リソースが役に立たないといっている訳ではないのでしょうが、リソースかイベントの判断をしなくてもモデリングを進められる点をメリットとあげている点について考えてみます。

これは、「イベント・リソースの判断」が（関数従属性にくらべて）難しいと考えているからこそ上がられるメリットだと思いますが、具体的にどのようなことかまでは理解できませんでした。いくつかたとえがありましたが単にエンティティの分離が不十分なのかもしれないだけのようにも感じました。より具体的な例があればこのあたりはクリアになるのでしょう。

また、「イベント・リソースの判断」をどのように使うのかの言及がなかったのでわからないですが、「イベント・リソースの判断」は一般的にトップダウンで使われ、関数従属性は正規化の１つとしてボトムアップで使わていると考えています。もし、ボトムアップで正規化した結果のテーブルに「イベント・リソースの判断」をしているのであれば、それはそれまでの正規化の手順（意味的な判断）に依存するので、「イベント・リソースの判断」は難しくというか判断できなくなる可能性もでてきます。これは単にやり方の問題と考えるべきでしょう。

結論

残念ながら、「イベント・リソースの判断」をしないでモデリングが進めるメリットは感じることはできませんでした。これは、T字などで示されている「イベント・リソースの判断」基準は非常に分かりやすく特に問題を感じていないのがひとつ、あと、関数従属性を含む正規化でボトムアップで構築した構造がどうしてもデータの入出力構造に依存しやすくなると考えており、トップダウンでモデルを縛っていく必要を感じているためです。

補足

『「リソース」か「イベント」かを区別するやり方が主流』と言及されていますが、僕の知っている範囲では『「リソース」か「イベント」かを区別するやり方』 すなわち 『もの−こと分析』を行う開発チームはまだまだ少ないという印象をもっています。
これは『もの−こと分析』がまだまだ知られていないことが原因だと思っています。知っていて利用しないのと、単に知らないのは大きな違いですよね。