一般にRDBにおいて、エンティティはテーブルにして、そのテーブルに主キーおよびさまざまな項目をもち、あるエンティティ（＝テーブル）と他のエンティティ（＝テーブル）の間に関係がある場合、
あるエンティティ（＝テーブル）をテーブルAとし
関係のある他のテーブルを、テーブルBとしたとき、
テーブルAが親、テーブルBが子の場合
（例：テーブルAが発注テーブル、テーブルBが発注明細テーブルの場合）
テーブルAの主キーを、テーブルBの項目の１つとする。
このとき、テーブルBの項目となった、「テーブルAの主キー」のコトを外部キー（または参照キー）とよぶ。
と、一般には習う。
これが成立する場合、エンティティはテーブルであり、関係は外部キーを参照すれば、関係があるか無いかが分かる。
しかし、これは、多対多の場合は成立しない。テーブルAの外部キーは、テーブルB中には１つしかもてない。
で、どうするか。
このとき、関係もテーブルにしてしまう。
（テーブルAの主キー、テーブルBの主キー）で１レコードとなるテーブルを作成すればよい。
たとえば、在庫を考える。在庫は、倉庫（の場所）と、商品の多対多の関係の上になりたつ。たとえば、
お台場の倉庫１０１に、「りんご」と「みかん」
お台場の倉庫１０２に、「りんご」と「なし」
とあった場合、倉庫テーブルの中に、商品１、商品２・・・商品１０とかつくって、商品１にりんご、商品２にみかん・・といれていくと、今回は２つだからいいけど、１１個の商品がきたら、テーブルが破綻してしまうのでだめ、
同様に、商品の中に倉庫１、倉庫２といれるのも、ダメ。
ここでは、商品と倉庫の対応である、在庫テーブルというのを作成し、
（倉庫１０１,りんご）
（倉庫１０１,みかん）
（倉庫１０２,りんご）
（倉庫１０２,なし）
とすればよい。そうすれば、仮に、倉庫１０１に、２０個きても、１００個商品がきても、どんどんレコードを追加すればいいだけ。
このように、多対多の関係を表現するには、テーブルを作って表現する。
この場合、エンティティは当然テーブルだが、関係もテーブルになってしまう。
■たとえば、SugarCRMのER図を作ろうとした場合
たとえば、SugarCRMのER図を作ろうとした場合のことを考えよう。
SugarCRMは、多分汎用的に作るためだと思うけど、関係も、テーブルになっている
（エンティティのカスタマイズが可能ということは、エンティティの関係もどうなるかわかんないわけで、そうすると、多対多でも１対多でも対応できるテーブル方式となるのかな？）
そこで、テーブル中、エンティティとリレーションに分けないといけない。
SugarCRMでは、関係のテーブルは、エンティティ_エンティティのように、
_（アンダーバーってウィリアムのいたずらは言うけど、あんすこ？っていうの？？）がついている。
ということは、逆の言い方をすると、アンダーバーがついていないテーブル(casesとかaccountsとかleadsとか）が、エンティティ候補となる。
そして、このエンティティ間の関係（ER図でいうと、線で結ばれるやつ）が、エンティティ_エンティティというあんすこ？で結ばれたテーブルとなる。
さて、ここで、カーディナリティ（１対多とか、多対多とか）についてだけど、これは、そのモジュールのvardefs.phpなど（metadataにもある？）中のrelationship_typeにかいてあるみたい。。
■でもね
ER図を描くとき、もし、関係の内容まで書くとしたら、それは、すぐには分からないかも。。
「cases_bugs」ケースとバグ？？なんだろー（＾＾；）
アクセス
トータル
ランキング
