DBのリレーションって「張る」ものだったよ！

10年ほどエンジニアをやってて「まさかっ！」と思ってしまった記事。

RDBMSに関する典型的な誤解が絶えないという現実
http://nippondanji.blogspot.jp/2013/04/rdbms.html

重要なのはリレーショナルモデルにおける「関係」ないしは「リレーション」とは、テーブル同士の関係（リレーションシップ）のことではなく、テーブルそのものを指すという点だ。「テーブル同士の関係性を表現するデータモデルだ」というのは非常にポピュラーな誤解である。

記事の全文を読めば腑に落ちるし「確かにそーだ」と全面的に認められる、、、、が、じゃぁ、なぜ一般的なSIer（っつーか、技術的練度の低い下請けSIとか）の間ではこういう誤解がまかり通っているのか？という疑問が残る。
一応、仮にもOracleなどの勉強をした身では、確かに理論として上記のような内容を勉強した記憶はあるが、まずその理論にたって実践はしていない。

リンク先には

恐らくは、SQLを学習する際、みな実践ばかりに力を入れて、理論（リレーショナルモデル）についての学習が疎かになっているからではないかと思う。
とあるが、それはそもそも理論と実践に乖離があるから始まるんじゃなかろうか、と思う。

確かに、RDBMSの理論を正確に踏襲して行くためには、理論→実践→理論の立ち返りが必ず必要だ。そもそも、学問としてはそれが正しい。だけど、大多数がそうだと勝手に思ってるけど、プロジェクトの最中、もしくは終わった後でそんな振り返りをすることは稀だ。
時間とか人のタイミングとか体制とか色々あるけど、それに対するモチベーションは無いと思う。
まぁ、環境やらなんやらを言い訳に使うにはさておき。

具体的に作業ベースで考えると、現場で上記のような理論を目にすることはない。
なぜか？
多分、オブジェクト指向プログラミングとの乖離がRDBMSとの間に乖離が発生しているんじゃないかと思う。

例えば顧客情報という概念モデルが、「名前、生年月日、住所・・・」の他に、例えば「お得意様フラグ」みたいな、顧客の2次情報（システムとして判別する属性）がくっついていることが多い。顧客情報の概念モデルとしては一緒だが、実際にテーブル設計する際は、別テーブルにし、外部キーで紐付け、つまり”リレーションを貼る”ことになる。

ここの問題は2つ。

・システムを作る際、インターフェースの考慮は必ず必要になる。つまり、画面の制御に関する属性がある程度モデリングで考慮されていなければ、利便性の担保は出来ない。（もしかして、基幹システムとかシステム同士のIFしか持たないモノだと純粋なモデリングが出来るのかな？）
・外部キーを「リレーションを貼る」と言う慣用。つまり、モデル同士の紐付けもRDBMSの理論の一つの体現だと言う認識であること。

この2つの問題は、実践を繰り返す上で、経験からくる洗練を繰り返した結果なんじゃないかと思っている。だって顧客情報の中のカラムをリレーションされたものって意識しないし。オブジェクトの集合体とかデータモデルの集合体ですよね。

ここからは言い訳なんだけど、相当上流なアーキテクチャ設計や、金融系やお役所みたいな巨大システムでも無い限り、モデリングってもうちょっと簡易に作るものだと思われる。となると、JavaやPHP、もしくはRailsみたいに手軽に作れるFWを選定することが第一の基準になる。
結局は適材適所ってことになるんだろうけど、こういう理論を先行させなければならないプロジェクトもあるってことなんだと思う。当然、その理論を理解している人が集められるんだろうけど。

と、理論などろくな学習もなく、JavaとMySQLな現場に叩きこまれた地方SIerの成れの果ての個人的な雑感。
でも、小規模案件～中規模案件にしか関わってない浅い知識しか習得できてない自分には、こういう理論が先行して、秀逸なアーキテクチャを実現したプロジェクトって羨ましく思う。

結局は自学自習なんだろうけど。