2ちゃんねる★スマホ版★■掲示板に戻る■全部1-最新50

【ER図】なんでもリレーション貼るの害悪じゃないかな? [転載禁止]©2ch.net

1 :
デフォルトの名無しさん
2015/06/18(木) 10:53:03.83 ID:Ln+NExBw
E-R図ってツール使ってると簡単に関連したテーブルに
リレーション貼れるんだけど、なんでもかんでも貼りまくった
E-R図って見にくいだけだと思いませんか?

O/Rマッパーであの図のとおりにリレーション定義していくと
モデルの関連情報のせいで1つの大きな塊になってしまって、
アプリ作る時にモジュール化しにくいだけなんだけど。

親子関連みたいに強く結びついているものは
リレーションはっていいけど、そうではない部分は
あえてリレーションはらないで、小さくモジュール化
したほうがいいと思うのだけれど、そんな考え方って無い?
2 :
2015/06/18(木) 11:55:39.62 ID:yshh0B6q
ターゲット次第
アプリとかで腹にDB抱えるなら無駄にリレーはる必要なんかない

リレーションは大規模なデータベースでアプリケーションにテーブル関係構造が埋もれるのを回避する仕組み
3 :
2015/06/18(木) 12:07:42.79 ID:yshh0B6q
設計時点で選択条件を定めて、性能劣化を抑える趣旨
ただエスパーするて、表の正規化が過剰なんじゃないか
普通はリレーションの量なんか気にしない
メタ表のさいずなんかメガまでいくかいかないか
4 :
2015/06/18(木) 19:20:36.76 ID:sk5olvXp
お、いきなりちゃんとしたレスがきた。幸先いいなw

>>2-3
なんていうかデータベースの話というよりアプリ開発の話なんだよね。
O/Rマッパーの話というか。説明が難しいな。スレタイよくなかったかも。

最終的な目標としてはアプリ開発する時に小さくモジュール化したいって話なんだよ。

例えばこれはWordPressのER図
http://wpdocs.osdn.jp/%E3%83%87%E3%83%BC%E3%82%BF%E3%83%99%E3%83%BC%E3%82%B9%E6%A7%8B%E9%80%A0

これは簡単な例だけど、この線の通りにO/Rマッパーを定義すると
wp_optionsを除いて、全てが一つに固まってしまう。

でもモジュール化の考えからすると、
例えばwp_usersとwp_potstsって分けたくならない?

知ってると思うけど最近のフレームワークではO/Rマッパーの定義からSQLを自動生成する機能がある。
つまりモデルの定義がそのままSQLになるので、逆に見ればER図に書かれているものを
生成するためにモデルを書くことになる。そこに外部キーの定義も行う。
そうすることで簡単に関連モデルのデータを取得することができる。

で、ER図(全体がほぼ一つの塊なる)の通りにモデルを実装すると
モデル同士が結びついてモジュール化できなくなってしまう。

データベースの定義自体は正規化をするかしないかは、それほど関係ないと思ってる。
しなくてもどちらにしろテーブル自体に関連(リレーション)はあると思うから。
関連するデータ(テーブル)同士の関連をアプリ開発上は切断してモジュール化して実装し、
手動でつなげるという考え方があるのだろうか?という話
5 :
2015/06/18(木) 21:14:47.70 ID:d3zAGFRa
長い
要点だけにしろ
6 :
2015/06/18(木) 21:16:58.15 ID:sk5olvXp
>>5
要点はスレタイです。
7 :
2015/06/18(木) 23:24:50.15 ID:ro+SXwr3
リレーションとリレーションシップの違いから勉強しなおせ。
8 :
2015/06/18(木) 23:36:43.76 ID:sk5olvXp
リレーションシップなんて一言も言ってないですよ。
9 :
2015/06/18(木) 23:52:20.89 ID:ro+SXwr3
O/RのRはリレーション、ERのRはリレーションシップ。
その違いすら認識してないってことは基礎がまったくできていないってことだ。
10 :
2015/06/19(金) 08:45:23.86 ID:nXV/2Pbs
>>4
兵庫とにわけなきゃよろしい
11 :
2015/06/19(金) 12:29:49.89 ID:X+CwqWOz
>>9
そうか。わかったよ。

じゃあ訂正する。

訂正したという前提で話をしよう。
何か意見があるのならどうぞ。
12 :
2015/06/19(金) 12:30:29.91 ID:X+CwqWOz
>>10
> 兵庫とにわけなきゃよろしい

どういうこと?
13 :
2015/06/19(金) 13:00:49.40 ID:p5SNpdEu
>>11
> 訂正したという前提で話をしよう。
> 何か意見があるのならどうぞ。
『理論から学ぶデータベース実践入門』読んでから出直せ、ど素人が
14 :
2015/06/19(金) 13:04:15.96 ID:X+CwqWOz
>>13
それで、違うのはわかったけど、
それがこの話題に何か関係有るのでしょうか?

揚げ足を取っているだけにしか見えないので、
ちゃんとコミュニケーションを取ってください。
15 :
2015/06/19(金) 13:43:35.74 ID:p5SNpdEu
>>14
揚げ足を取ってるわけではない
Work PressのER図を見て「なんでもかんでも貼りまくったE-R図」と読み取るレベルの
お前と話す価値なんて、俺を含めて誰にもない
16 :
2015/06/19(金) 13:45:59.92 ID:p5SNpdEu
おっと、揚げ足を取られるとこだった
Work PressじゃなくてWordPressな

このスレの話題で利益を得るとしたら、難の知識もないお前しかいない
17 :
2015/06/19(金) 13:56:26.22 ID:p5SNpdEu
めんどくさいが、『理論から学ぶデータベース実践入門』から引用してやるわ

> リレーションとはいったい何でしょうか? 最もよくある間違いは、「テーブル同士の関係」というものです。
> 繰り返しになりますが、テーブル同士の関係を(ER図などを使って)デザインするのが、リレーショナル
> モデルだと、誤解している方をけっこう見かけます。もし、あなたがそのような誤解をしているのだとしたら、
> 今すぐ考えを改めてください。

どう改めれば良いかは、『理論から学ぶデータベース実践入門』読め
話を続けたいなら、『理論から学ぶデータベース実践入門』に書かれてる程度のことがわかってからにしろ
18 :
2015/06/19(金) 14:44:03.53 ID:X+CwqWOz
それはわかったので、>>4に対してレスしてください。
全く関係ない話じゃないですか。
19 :
2015/06/19(金) 16:19:39.63 ID:p5SNpdEu
>>18
> 全く関係ない話じゃないですか。
関係ありありなんだが

> それはわかったので、>>4に対してレスしてください。
レスが欲しかったら、

* 自分がどの言語のどのFW/ライブラリのO/R mapperを使っていて
* どうやってコードを生成したのか
* その結果のコード
* そのコードのどこがおかしいと思っているのか
* 望むべきコードはどういうものか

位は情報出せ
20 :
2015/06/19(金) 17:03:12.42 ID:nXV/2Pbs
>>12
指摘されている通りだけど
噛み砕けば、モジュールを表とペアにする必要はない
表間の関係を図にしたのがER
抽出条件を整理してインデックスやマテリアライズドビューを先に作るかー、抽出条件はこうだからお前らSELECT書くときは必ずこの抽出条件つけろ
とするツール

関係図はモジュール分割には役立たん
21 :
2015/06/19(金) 19:28:28.55 ID:X+CwqWOz
>>19
関係無いですよw
だってあなたの質問にデータベース出てきてないんですから。

話をまとめましょう。

O/Rマッパーを使う時リレーションの設定をします。
(例えばrailsのActiveRecordでいいですよ。)

ActiveRecordがよくわからない人は、こちらを参照してください。
http://magazine.rubyist.net/?0006-RubyOnRails

こことかですね。
> has_many は1対多の関連付けに用います。 普通はふたつのテーブルを使いますが、
> Topic は Reply と共に Single table inheritance を構成します。

つまりO/Rマッパーの定義をすると、
モデル同士が相互に依存してしまうわけです。

ですが相互に依存させたくないのです。
22 :
2015/06/19(金) 19:33:17.22 ID:X+CwqWOz
もう一つ、Pythonのdjangoの例を見つけましたが。
https://docs.djangoproject.com/en/1.8/topics/db/models/

あれ? Relationships って書いてますよ?

そんなにリレーションとリレーションシップの違いって
重要だったんですかね?
23 :
2015/06/19(金) 19:37:22.62 ID:X+CwqWOz
http://www.atmarkit.co.jp/ait/articles/0409/22/news094.html

こちらは、Javaのhibernateですね。依存しちゃってます。

package sample.entity;
import java.io.Serializable;
public class Member implements Serializable {
private Integer no;
private String name;
private Integer groupno;
private WorkGroup workGroup; //リレーション先の型で定義しているところに注目

public Member() { }
public Integer getGroupno() { return groupno; }
public String getName() { return name; }
public Integer getNo() { return no; }
public WorkGroup getWorkGroup() { return workGroup; }

public void setGroupno(Integer integer) {groupno = integer; }
public void setName(String string) { name = string; }
public void setNo(Integer integer) { no = integer; }
public void setWorkGroup(WorkGroup group) {workGroup = group;}
}
24 :
2015/06/22(月) 10:45:37.16 ID:/sLPnrl8
ORMを使うと、リレーションが発生するのが嫌なら、ORM使わないで自分で全部実装すればいいんじゃないかな。
ORMで一切リレーションを使わないというのはできないんでしょ?
25 :
2015/06/22(月) 10:47:18.71 ID:/sLPnrl8
あと、仮に
> あえてリレーションはらないで、小さくモジュール化
こうした場合、JOIN部分はどうやって実現するつもりなのかな?
結果データをループしながら、自分で探すの?
26 :
2015/06/26(金) 01:27:24.31 ID:AHKQV2Vb
前提として自分は、ドメイン駆動的に純粋な(ORMに依存しない)モデルを、
ARとかとは別に作るべきだと思ってる。

その上での意見だけど、
ビジネスロジック的に(またはその他の理由で)モジュール分割すべきなのは前者であって、
後者は一枚岩でいいんじゃないかな?(DBとの接点という役割の1モジュールとして考える)
27 :
デフォルトの名無しさん
2016/03/21(月) 00:48:13.76 ID:KQkKBKcO
>>1
リレーションを勘違いしているやつがいるんだよな。

テーブル作ってからリレーションを発見して、リレーションがあるようにアプリケーションを作るから、おかしくなる。
13KB

新着レスの表示

★スマホ版★■掲示板に戻る■全部前100次100最新50

名前:E-mail: