« データベース正規化・非正規化 | トップページ | コミュニケーション・コストを減らす方法 »

2008年4月10日 (木)

インターフェイスとしてのリレーショナル・モデル

でも、経験的には、外部インターフェイスが同じであっても内部インターフェイスは、少なくともプログラムの場合は異なる。

データベース(端的にはテーブルのスキーマ)はどうだろうか? 同じだよなぁ。

結果は同じでも過程が異なる (L'eclat des jours)

まさにそのとおり、ですね。

リレーショナル・モデルの範囲内で考えると、"外部インターフェイス”として、唯一使えるのがビューになるわけですが。ビューは基本的に検索にしか使えないわけで、そうしますと:

  • テーブル: 挿入・削除・更新
  • ビュー: 検索

といった形にしかならないのですよね。

結合操作でできたビューが更新可能になる、というのは、現実の製品では聞かないですね。もし可能な製品があったとしても、導出元のテーブルを意識しないわけにはいかないでしょう。特に挿入と削除を行なう場合には。

・・・

テーブルが増えると、SQLクエリのJOIN句が複雑化してしまうという意見もあるが、羽生氏は「サブクエリやOUTER JOINがスラスラ書けない人は、DBの設計をすべきでない」と断言する。DBの設計は、プログラムの都合を一切忘れて行わねばならない、というのが氏の主張するところである。

DBは超グローバル変数、どう設計するか (マイコミジャーナル)

データベースをそうやって設計して、ユーザ/プログラマに「さあ、使ってください」という段階になって、”サブクエリやOUTER JOINがスラスラ書けない人”がユーザ/プログラマである場合は、どうしましょうか。

Who Needs Theory - Just Give Me The Data

Because most of what programmers do has no theoretical basis or system of proof, programmers back away from anything that looks like hard math. Failure to understand and appreciate relational theory has launched countless bad databases (and thousands of witless articles condemning SQL).

Why Programmers Don't Like Relational Databases (Typical Programmer)

アプリケーションで使う全てのクエリを、データベース設計者が書いて、プログラマに渡すとか。

内部設計の工程では,「詳細クラスモデル」 「SQLモデル」 「物理データモデル」を部分的に自動生成し,「共通詳細クラスモデル」を人手で作成する。

システム開発の業務プロセス自動化とは? (ITpro)

あるいは、O/Rマッパー(のようなもの)を使うとかですかね。それは、リレーショナル・モデルの”外”になりますけども。それこそ、オブジェクト指向のような、プログラミング・モデルで、リレーショナル・モデルを隠してしまう、という考えは、昔からありますね。3層C/Sモデルみたいな。

しかし、何か”屋上屋”な感じがして仕方がなかったりします。

|

« データベース正規化・非正規化 | トップページ | コミュニケーション・コストを減らす方法 »

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック

この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/80472/20082116

この記事へのトラックバック一覧です: インターフェイスとしてのリレーショナル・モデル:

« データベース正規化・非正規化 | トップページ | コミュニケーション・コストを減らす方法 »