- PR -

RDB的なクラス設計はなぜ悪い？

1
投稿者投稿内容
ミッキー
会議室デビュー日: 2003/03/14
投稿数: 2
投稿日時: 2003-12-28 01:46
ＵＭＬでクラス設計するとき、ＲＤＢをもとにして設計するのは
ありがちなことだと思います。

以前オブジェクト指向の研修に参加したときは、
「ＲＤＢ的な考えでクラス設計する（参照キーを属性にして関係
を考える）のはありがちな間違いです。それでも動くことは動く
けど、オブジェクト指向とはずれた考え方なので、あまり良くない
設計の仕方です」
と、講師の方が言ってました。

ですが、以前ＤＯＡで開発をやってきていて、ＤＢ設計も
バリバリできて、現在はＵＭＬ＋Ｊａｖａで開発してる人に
にその話をすると、
「動くんだからいいじゃん。それが悪いっていうなら、ＲＤＢ
的な設計でどんなデメリットがあるのかを具体例を挙げて説明
してみてよ。」
と言われてしまい、答えることができませんでした。

また、
「テーブルをもとにクラス図作ったほうがＯＲマッピングも
しやすいし、それはメリットなんじゃないの？　小難しい理想論を
振りかざすより、現実を考えて効率よくやったほうが利口だよ。
時間もないし、それで動くんだから。」
とも言われてしまいました。

そこでＵＭＬを利用して開発を行っている皆さんに質問なのですが、
・参照キーの考えでクラスの関連を考える。
・テーブル＝クラスでクラス設計をする
などのＲＤＢ的なクラス設計の具体的なデメリットって何が
考えられるでしょうか。

個人的には、2番目については、ＤＢの正規化も、責務にのっとった
クラス設計も、変更が生じた場合に影響を小さくするという考えでは
一緒のような気もするんですが、
正規化はある程度機械的に行えるのに対し、オブジェクト指向の
責務洗い出しはそんな単純にはいかないような気もするので、
やっぱなんらかの差異はあるんだろうなーと考え込んでしまいます。
未記入
ぬし
会議室デビュー日: 2002/03/28
投稿数: 255
投稿日時: 2003-12-28 07:06
>ＵＭＬでクラス設計するとき、ＲＤＢをもとにして設計するのは
>ありがちなことだと思います。
UMLを使わないでクラスを設計する方が，もっと良くあると思います．
UMLは表記法なんで，設計をした「後」に，書き下すのに使うだけ．
UMLを「使って」設計するわけじゃない．DB設計のER図とはこの辺が
違います．

>「ＲＤＢ的な考えでクラス設計する（参照キーを属性にして関係
>を考える）のはありがちな間違いです。それでも動くことは動く
>けど、オブジェクト指向とはずれた考え方なので、あまり良くない
>設計の仕方です」
まったくその通りです．オブジェクト指向の設計と，RDBの設計は全く
別物です．モデルも違うし，持っている機能や制約も異なります．

>ですが、以前ＤＯＡで開発をやってきていて、ＤＢ設計も
>バリバリできて、現在はＵＭＬ＋Ｊａｖａで開発してる人ににその話をすると、
DB設計ができることとJavaを使いこなすことは何の関係もありません．
＃逆もまた同じ．良いJavaプログラマーがDBの設計に関しては素人と
＃いうことも良くあります．

そもそも，RDBMSは「リレーショナルモデル」を元にしたデータベースです．
リレーショナルモデルには，オブジェクト指向の基本となる継承，カプセル化
（情報隠蔽），ポリモフィズムさえもありません．当然これらの機能を使った
設計など行われるはずもありません．

>「動くんだからいいじゃん。それが悪いっていうなら、ＲＤＢ
>的な設計でどんなデメリットがあるのかを具体例を挙げて説明
>してみてよ。」
バグが出やすく生産性が低下する．再利用性が下がる，等々．
とりあえずGoFのデザインパターンを勉強することをお勧めします．

>「テーブルをもとにクラス図作ったほうがＯＲマッピングも
>しやすいし、それはメリットなんじゃないの？　小難しい理想論を
＃少しでもテーブルに変更が加わると，プログラムを「全部」書き直す
＃つもりなんでしょうね．時間の浪費．

>そこでＵＭＬを利用して開発を行っている皆さんに質問なのですが、
これは失礼．UMLなんてガラクタはほとんど使っていませんでした．
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)
投稿日時: 2003-12-28 13:45
unibon です。こんにちわ。

引用:

ミッキーさんの書き込み (2003-12-28 01:46) より:
そこでＵＭＬを利用して開発を行っている皆さんに質問なのですが、
・参照キーの考えでクラスの関連を考える。
・テーブル＝クラスでクラス設計をする
などのＲＤＢ的なクラス設計の具体的なデメリットって何が
考えられるでしょうか。

上記の「参照キーの考え」とは具体的にはどのようなことでしょうか。
(a) 社員テーブルに所属部署列を設けたり、部署テーブルに所属社員列を設けること(後述の(b)よりは広い概念)
(b) 部署テーブルに所属社員列を設けるだけだと、一対多が表現できないので、中間テーブルを設けたり、あるいは、社員テーブルに所属部署列を設けることで解決すること
(c) 部署や社員のために人為(artificial)キーである ID を付けること

オブジェクト指向であろうと Dead or Alive であろうと、(a) の概念がないことには関連を構築できないので、(a) を問うことはないだろうと思います。だとすると、(b) や (c) でしょうか。
＃以下、コードは擬似的なものですが。

上記 (b) だと、たとえば
コード:
class Department {
    List<Employee> employees;
}

とすれば良いところを、RDB を忠実に翻訳して、
コード:
class DepartmentEmployee {
    Department department;
    Employee employee;
}
class DepartmentEmployeeMap {
    List<DepartmentEmployee> departmentEmployeeList;
}

みたいなことをするをしてしまうことであり、これは避けるべきでしょう。

さらに (c) だと、
コード:
class Department {
    int id;
    List<int> employees;
}

みたいな感じでしょうか。これも避けたほうが良いと思います。

引用:

ミッキーさんの書き込み (2003-12-28 01:46) より:
・テーブル＝クラスでクラス設計をする

なお、これは「テーブル＝クラス」でしょうか。ふと、「レコード(tuple、行)＝クラス」かとも思ったのですが。でも設計はテーブルやクラス単位でおこないますね。RDB はクラスを考えると自動的に List になってしまうのも使いにくいところです。
思うに、結局は、オブジェクト指向の中のひとつの特殊化された実装として RDB(や ER)があるだけであり、両者を対等に扱う必要はないのかもしれません。
ミッキー
会議室デビュー日: 2003/03/14
投稿数: 2
投稿日時: 2003-12-29 11:46
ミッキーです。

悪夢を統べるものさん、unibonさん、ご意見ありがとうございます。


>そもそも，RDBMSは「リレーショナルモデル」を元にしたデータベースです．
>リレーショナルモデルには，オブジェクト指向の基本となる継承，カプセル化
>（情報隠蔽），ポリモフィズムさえもありません．当然これらの機能を使った
>設計など行われるはずもありません

たしかに、そういったオブジェクト指向特有の概念はＲＤＢでは
表現できないですね。

>バグが出やすく生産性が低下する．再利用性が下がる，等々．
>とりあえずGoFのデザインパターンを勉強することをお勧めします．

つまり、オブジェクト指向の特徴を活かしたメリットを享受できない
ということですよね。
なんとなく、頭では理解できるんですが、それを人に説明するのが
うまくできないんですよね。
まだまだ経験不足ってことなんでしょうけど。


>上記の「参照キーの考え」とは具体的にはどのようなことでしょうか。
>(a) 社員テーブルに所属部署列を設けたり、部署テーブルに所属社員列を設けること(後述の(b)よりは広い概念)
>(b) 部署テーブルに所属社員列を設けるだけだと、一対多が表現できないので、中間テーブルを設けたり、あるいは、社員テーブルに所属部署列を設けることで解決すること
>(c) 部署や社員のために人為(artificial)キーである ID を付けること

具体的にはＣです。
どう考えても参照使うのが当たり前だと思うのですが、
それを言ってもなかなか理解してもらえません。
短期の開発なんで、とりあえず動くもの先決みたいな雰囲気
でして、自分の意見を認めてもらうのが難しいんですよね。
私のオブジェクト指向の経験が浅いんで、発言力があまり
ないってのもありますけど。

>思うに、結局は、オブジェクト指向の中のひとつの特殊化された実装として RDB(や ER)があるだけであり、両者を対等に扱う必要はないのかもしれません。

なるほど、そういう考え方もありますね。
参考になります。

でも、ご意見頂いたことを私の言葉に噛み砕いて説明するのも
結構難しそうです。
やはり、経験をもとにした設計論でないと、信用されないような
気がします。
（お恥ずかしいですが、当たり前ですね。）

文句言うならおまえがやってみろといわれて、これはこうあるべき
でしょとさらっと例を示して見せるぐらいじゃないと、意見だけかよ
ってなっちゃいますよね。

これからもっとオブジェクト指向の経験積んで、周りの人を変えて
いけるようになろうと思います。

どうもありがとうございました。
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)
投稿日時: 2003-12-29 23:11
unibon です。こんにちわ。

引用:

ミッキーさんの書き込み (2003-12-29 11:46) より:
具体的にはＣです。
どう考えても参照使うのが当たり前だと思うのですが、
それを言ってもなかなか理解してもらえません。
短期の開発なんで、とりあえず動くもの先決みたいな雰囲気
でして、自分の意見を認めてもらうのが難しいんですよね。
私のオブジェクト指向の経験が浅いんで、発言力があまり
ないってのもありますけど。

私も、自分で全部書けるのならば、ほとんどの場合ではやはり参照が良いと思います。
しかし、メモリリークとは何? とか、ガーベッジコレクションっていつ起きるの? のようにメモリ管理が心もとないような状況の場合は、プロジェクトマネージメントも絡んだテクニックとしてはあえて参照を避けるのもひとつの手としてはあるのかもしれません。
またそれとは別に、アプリケーション開発技法としては、人為キーを付けたほうが良い場面もわずかにありそうな気もします。どんな場合なんでしょう?たまにそういう誘惑に駆られることはありますが、いまいち場合分けが把握できていません。考え方としては不変(immutable)オブジェクトに近いかもしれません。
とんび
常連さん
会議室デビュー日: 2003/07/11
投稿数: 32
投稿日時: 2003-12-30 13:27
引用:

unibonさんの書き込み (2003-12-29 23:11) より:
またそれとは別に、アプリケーション開発技法としては、人為キーを付けたほうが良い場面もわずかにありそうな気もします。どんな場合なんでしょう?たまにそういう誘惑に駆られることはありますが、いまいち場合分けが把握できていません。考え方としては不変(immutable)オブジェクトに近いかもしれません。

すぐ思いつくのはLazy loadingとかですかね。
コード:
class Department {
    int id;
    List<int> employees;
}

この例がRDB的なクラス設計かと言うとちょっとちがうような気がするのですが。
employeesをpublicにしてたらさすがにまずいと思うのですが、
employeesを直接公開してないかぎり、intで持っていようが、Employeeで持っていようが
もしくは、全く持っていなかろうが他に影響がないと言うのがオブジェクト指向
のよいところだと思うので。
秀人
常連さん
会議室デビュー日: 2003/02/19
投稿数: 22
お住まい・勤務地: 東京都
投稿日時: 2004-01-02 07:00
私も以前研修を受けた時似たような質問をした記憶があります。
その時の回答は、
・ＤＢとクラスは平行して設計し、ドメインモデルで統合する。
・ドメインモデル以降は、設計上必要なクラスがどんどん出てくるので、最終的にクラスとＤＢは同じにはならなくてよい。
とのことでした。
それを聞いて以来、私はドメインモデル中のクラスはＤＢと１対１にするようにしています。
そのクラスですが、属性は必ずしも一致させず、クラスのほうに、ＤＢの列にはないような情報も付加して設計しています。
1

スキルアップ／キャリアアップ（JOB@IT）