DB設計を語るスレ 6

>>950
いいたいことは>>941でかいてるので。

主観とは何かスレ

Wikipedia至上主義もいい加減にして欲しいね。

要出典

ところで>>889,893あたりの人達はもういいのかな？

>>956
連関エンティティではあるが関連テーブルではなさそうだ

>>957
>>856の情報だけでは、連関エンティティかどうかは判断できないのではないのかな？

単なるエンティティで、たまたま２つの外部キーを持っているだけかもしれない
つまり members がERモデル設計における連関エンティティを実装したテーブルであるという
確証がない限り、たとえば(コード上のコメントを含む)ドキュメンテーション内で記述が無ければ、
members が連関エンティティであるか否かは誰にも(客観的には)判断できない、ってこと

もちろん、>>957がRedmine設計者本人であったり、十分にRedmineの実装設計を理解した上で
連関エンティティであると判断したのであれば、その判断は正しいのだと思うけどね....

>>958
>>856の情報だけでは判断できないことには賛成だが

なんか斜め上いってない？

>>958
普通にプロジェクト参加メンバーなんじゃないの

ここ設計スレだよな

DBの実装からERモデルに戻せないような発言とかレベル低くくね？

ましてや定義もしっかりしてる連関エンティティで言うとはな

DB設計を(できるようになりたいから自論を長文で)語るスレ
かもしれない。

>>961
DBの実装からERモデルへと連関エンティティを戻せるというのは精神論だよ
コンパイラが出力したアセンブリ言語コードから、
元のソースコードを正確に復元しようとする発想と同じ

実際の現場ではドキュメンテーションが確実に保守されているサイトは稀
場合によっては、まともなDB設計書無しに詳細設計書だけで改修を要求する顧客もある
まあ、学生さんのDB演習レベルであれば、
「戻せるはず」という発想もいたしかたがないのかもしれない....

>>963
かといって>>856をみて判断をできないのは、ええっと、DB設計者？（まさかｗ)にとっては致命的だよね。

>>962
ダウト。
DB設計(以前の基礎知識)を(>>894にわかるようにやさしく)語るスレ

>>964
断定的に判断できるのは「>>856は連関エンティティの可能性がある」迄だね

もしもそれ以上の判断が必要ならば、システム(この場合は Redmine)全体のDB設計を
調査して推測的に判断した上で、開発元(この場合は ...)へ問い合わせて確認すべき
現実には、「可能性がある」というレベルの判断で十分なケースが大半だとは思うがね.....

>>966
連関エンティティを理解できてなさそうな状態でこれを聞くのは酷かもしれないんだけど、
どっちである確率が高いと思う？

>>967
連関エンティティを理解できている>>966は、
どっちである確率が高いと思う？
そして、そう判断した(客観的な)理由は何？

逆質問キマシタワー！！
ごく自然に連関エンティティだと思うね。
連関エンティティじゃなかった場合の、相手のテーブルをおよそ想像できない。
無理やりそうじゃない構成を考えることはできるけど、きわめて不自然になるからね。

で、これに対してサロゲートキーの是非を持ち出してくるなら、頼むから出直してくれと釘を刺しておく。

>>964
>>856だけからならば、「*_idという名前のフィールドはなんらかのエンティティのIDに違いない」という
推定を加えなければ判断はできないと思うが。

君たち、可能性の話をしてるのか、常識論で話してるのか、どっち？

>>970
そりゃ推定を加えてるよ。だから可能性が高いか低いかって話をしてるんだよね。
まさか日本語の勉強からやらないとダメなの？

さておき、>>856のテーブル定義をみて、これが連関エンティティである確率が低いと思う人は、
どういう構成を想像してるの？

>>856をみて連関エンティティかなと推測でき
Redmineのソース(>>855のソースやその周り)をみたら確定。

>>856回りの流れでrole_idがないのは古いんじゃなくて新しいから。
Membersに多対1でRolesがついてたのが多対多になって
member_rolesという結合テーブルで連関エンティティを加えたから。

別にRedmineのソース見る必要なくね？

ところでAssosiative Entitiesの日本語訳の話なんだけど、このスレでの最近のトレンドは
「連関エンティティ」になってるけど、みんなそれでいいの？

そもそも今回の話の基点は、このスレでは>>476で、それ以降>>882まで俺以外で「連関
エンティティ」って言ってる人がいないんだよね。
そして俺自身も「連関エンティティ」がメジャーな訳かどうか自信が持てない。

ちなみにミック氏は「関連実体」と訳してます。

>>974
少なくともPostgreSQLでは、membersからusers, projectsへのFK設定もないし、
{user_id, project_id}のユニーク制約もないから、Redminの要件や実装コードを
見ないとわからないと思う。

>>975
エンティティとしては連関エンティティしか出てないんでは？

関連テーブル(結合テーブル)と連関エンティティを混ぜて考えてはいかんよ

>>976
確定できないことには賛成
でもPostgreSQL関係ないわな

>>978
MySQLでも（それ以外も？）使えるけど、俺はPostgreSQLの場合しか確認できないということ。

>>977
いや、Assosiative Entitiesのつもりで「連関エンティティ」以外の言葉を使ってた人はいないのかってこと。
俺の感想は>>876。なので、ずっとモヤモヤ感が続いてる。

ちょっと見直したら、関連エンティティと表現してる人もいるな。(>>868)
文脈ではAssoiative Entitiesのことだと思うんだが。

ちなみにミック氏は（くどい）、「関連エンティティ」という言葉は別の意味で使ってます。

>>980
そういう意味か

>>876みたとき間違いと思ってみてたよ

Junction Table >>920を関連テーブル(結合テーブル)と呼んでると思ってた

Junction Tableが属性をもてるのかが曖昧でその答えが出ないかなと思ってみてる

>>981
ミックって誰？
関連実体が別の意味なの？

>>983
> ミックって誰？
この人。
http://www.geocities.jp/mickindex/database/idx_database.html

> 関連実体が別の意味なの？
・ミック氏はAssociative Entityを「関連実体」と訳している
・ミック氏は「関連エンティティ」を「関連実体」とは別の意味で使っている

>>984
http://www.geocities.jp/mickindex/database/db_whyname.html
「二つ以上の実体を相互に関連付けた実体である。」が
E-Rモデルにおける関連エンティティのことです。
といってるから同じ意味で使ってない？

http://www.geocities.jp/mickindex/database/db_case.html
多対多の関係を扱うための関連エンティティの構造です。 って説明してるけど
Associative Entityだよ

関連実体って表記がみつからないんだわ
URL教えて

>>985
> 「二つ以上の実体を相互に関連付けた実体である。」が

ミック氏はまさにこの意味で「関連エンティティ」を使っている。
「二つ以上の実体を相互に関連付けた実体」がいつでもAssosiative Entityになるわけではないよね。

> 多対多の関係を扱うための関連エンティティの構造です。 って説明してるけど
> Associative Entityだよ

多対多の関係を解決する為の「関連エンティティ」をAssociative Entityと呼ぶ。

> 関連実体って表記がみつからないんだわ
> URL教えて

Web上にあるかどうかは知らない。
ミック氏の『達人に学ぶDB設計』でそう訳している。

>>985
グーグルで"関連実体"で検索してみたら、Googleブックスで『達人に学ぶDB設計』の内容がヒットしたわ。
Googleブックス便利すぎ。

>>986
>「二つ以上の実体を相互に関連付けた実体」がいつでもAssosiative Entityになるわけではないよね。
ならないか？

> 多対多の関係を解決する為の「関連エンティティ」をAssociative Entityと呼ぶ。
このサイトだとその通りかと

relatedとassociativeこの2個をどう訳すかだと思うんだ
前者は「関係」、後者は「連関」と普段訳される
ミック氏は前者を「関連」と訳してると読める

>>987
サンキュ
Associative Entityを関連実体と訳してるね
"「多対多」を「1対多」に分解するときに必要となるエンティティを
「関連実体」と呼ぶ"と書いてあるから間違えてないな

>>988
> ならないか？
『達人に学ぶDB設計』では、二つのエンティティの単なる関連という文脈で「関連エンティティ」を使ってる。

ただ、個人的にはどうも『達人に学ぶDB設計』の「関連エンティティ」と「関連実体」の使い分けがしっくり
きてないんだよね。同書で「エンティティ」＝「実体」だと明記されてるし。なのに、「関連エンティティ」と
「関連実体」は使い分けされてる。

話がそれたが、知りたいのはこれね。
> いや、Assosiative Entitiesのつもりで「連関エンティティ」以外の言葉を使ってた人はいないのかってこと。

まあそれがわかったとして、もう一度それを念頭に置いてこのスレを読み直すかと言われたら、
多分読まないんだが……。

次スレ

DB設計を語るスレ 7
http://toro.2ch.net/test/read.cgi/db/1386312737/

次スレはRails禁止で

1000なら主キーの無いテーブルなんて世の中から消えて亡くなる。

>>969
客観的な理由を期待したけど、「ごく自然に」とか「およそ想像できない」といった
主観的な言葉でしか語れないのであれば、これ以上の議論は続けても無駄だね

>>936
> という、設計者の「主観」によって、いいかえると「主観的」に定義されるものである

なんだかこれでOKみたいな雰囲気醸し出してるから、簡単にコメントしとこう。

確かに、連関エンティティなのかどうか、そのときに得られた情報だけでは判断できない場合もあるだろう。

しかし、仮にmembers.user_idがusers.idのFKであり、members.project_idがprojects.idのFK、そして
{user_id, project_id}にユニーク制約が付いていたら、客観的にこれが連関エンティティだと判断できる。

そして、データモデリングfirst(俺用語）な場合は、大抵FKとUKの設定をするはずだ。（アプリ側で保証
する云々ということについては議論したくない）
Railsアプリは設定first(俺用語）だから、事情が違うのかもしれんが。

あと、
> たまたまあるエンティティが２つの外部キーを持ち、
>そのエンティティを介して２つのエンティティがm:n関係
の具体例があったら上げて欲しい。「出版」みたいなわけわからん奴じゃなくて。

>>856から連関エンティティかわかるかって話が
なんでこんなに広がっちゃってるの？

ソース読めば終了だろ。机上野郎だけ？

>>996
ソース読まなくてもER図でわかるだろ

>>996
そもそもは、こいつのせい。
>>846
> 残念だけど、Redmineのmembersであってるんかな？
> これは関連テーブルじゃないんだよ
> role_idをもってしまってる

こいつが突っ張ってたからグダグダになった。

実際はrole_idはないんだけど、role_idがあっても連関エンティティには変わりないんだけどね。

>>998
テーブルとエンティティをごっちゃにするなって
関連テーブルと連関エンティティは別物だぞ

>>998
Cテーブル
A.id
B.id
これに、サロゲートキーが必要かが元だよな
Railsはこのタイプのテーブルにサロゲートキー必要ないのに
関係ないもの持ち出したのが元では？

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。