- PR -

スキーマ設計について質問　親子関係について

1
投稿者投稿内容
たくぽん
会議室デビュー日: 2006/10/18
投稿数: 10
投稿日時: 2006-10-31 09:49
DB初心者です。
DBを設計する際に同じテーブルからの参照を持つような設計は
するべきではないのでしょうか？

親子関係を主キーではないキーで実現したいと思っています。
具体的には以下のようなスキーマを実現したいです。
同じテーブルからの参照を持つようなテーブルを見たいことがないため
まったく論外な設計かもしれませんが、どのように書き換えればよいか
よろしくご教授ください。

/*==============================================================*/
/* Table: tCategory */
/*==============================================================*/
create table tCategory
(
ID_CATEGORY unsigned int not null default autoincrement,
CATEGORY_NAME varchar(32) not null,
constraint PK_TCATEGORY primary key (ID_CATEGORY),
constraint AK_AK1CATEGORY_NAME_TCATEGOR unique (CATEGORY_NAME)
);

/*==============================================================*/
/* Table: tGroup */
/*==============================================================*/
create table tGroup
(
ID_GROUP unsigned int not null default autoincrement,
ID_CATEGORY unsigned int,
ID_CHILD_CATEGORY unsigned int,
DATE_STAMP datetime,
USER_STAMP varchar(32),
constraint PK_TGROUP primary key (ID_GROUP)
);


alter table tGroup
add constraint FK_TGROUP_REFERENCE_TCATEGOR foreign key (ID_CATEGORY)
references tCategory (ID_CATEGORY)
on update restrict
on delete restrict;

alter table tGroup
add constraint FK_TGROUP_REFERENCE_TCHILDCATEGOR foreign key (ID_CHILD_CATEGORY)
references tCategory (ID_CATEGORY)
on update restrict
on delete restrict;

unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)
投稿日時: 2006-10-31 11:10
引用:

たくぽんさんの書き込み (2006-10-31 09:49) より:
DBを設計する際に同じテーブルからの参照を持つような設計は
するべきではないのでしょうか？

テーブル tGroup の2つの列(ID_CATEGORY および ID_CHILD_CATEGORY)の両方から、テーブル tCategory を参照していることを問題とされているのでしょうか？別に構わないと思います。

引用:

たくぽんさんの書き込み (2006-10-31 09:49) より:
親子関係を主キーではないキーで実現したいと思っています。

この意味が良く分かりませんでした。
参照される側である、テーブル tCategory の、列 ID_CATEGORY は主キーですよね。

--
unibon {B73D0144-CD2A-11DA-8E06-0050DA15BC86}
あしゅ
ぬし
会議室デビュー日: 2005/08/05
投稿数: 613
投稿日時: 2006-10-31 11:18
引用:

たくぽんさんの書き込み (2006-10-31 09:49) より:
親子関係を主キーではないキーで実現したいと思っています。


これだとtGroupの外部キーが主キーでも一意制約でもないので、
同一の参照を持ったレコードが複数存在する状況がありえます。

この構造って木構造な親子関係にはなりませんよ？
tCategoryがtGroupを挟んで多対多になるので親を複数持てます。

そういった意図でこの構造にしているのでしょうか？

前者を解決するならtGroupの外部キーを複合主キー(or 一意制約)に、
後者ならtCategoryを子から親への自己参照にすればよいです。
たくぽん
会議室デビュー日: 2006/10/18
投稿数: 10
投稿日時: 2006-10-31 15:57
unibonさん　あしゅさん早速の回答ありがとうございます。

引用:
-------------------------------------------------------------------------------
この意味が良く分かりませんでした。
参照される側である、テーブル tCategory の、列 ID_CATEGORY は主キーですよね。
-------------------------------------------------------------------------------
についてですがID_CATEGORYは主キーです。



引用:
-------------------------------------------------------------------------------
　　＞引用:
　　＞------------------------------------------------------------------------
　　＞たくぽんさんの書き込み (2006-10-31 09:49) より:
　　＞親子関係を主キーではないキーで実現したいと思っています。
　　＞-------------------------------------------------------------------------

これだとtGroupの外部キーが主キーでも一意制約でもないので、
同一の参照を持ったレコードが複数存在する状況がありえます。

この構造って木構造な親子関係にはなりませんよ？
tCategoryがtGroupを挟んで多対多になるので親を複数持てます。

そういった意図でこの構造にしているのでしょうか？
-------------------------------------------------------------------------------
ご指摘のようにtGroupをはさんでtCategoryは重複を許すようにしたいです。
この多対多の関係はホントに良いのか？という疑問を持ちながら考えておりました。

たとえばtCategoryには
１　アミュージュメントパーク
２　カラオケ
３　ビリヤード
４　ゲーム
５　個室
６　パーティールーム
（アミューズメントパークAのデータ）
アミューズメントパーク----カラオケ　
　　　　　　　　　　　　　+ビリヤード
　　　　　　　　　　　　　+ゲーム

（アミューズメントパークBのデータ）
アミューズメントパークB----カラオケ　
　　　　　　　　　　　　+ゲーム

（アミューズメントパークCのデータ）
アミューズメントパークC----ビリヤード
　　　　　　　　　　　　　+ゲーム

（カラオケ屋さんAのデータ）
カラオケ--------------個室

（カラオケ屋さんBのデータ）
カラオケB--------------個室
+パーティールーム

すみません。いくら考えてもあんまり良いサンプルが思いつかなかったのですが
ｔCategoryの中身は１〜４　５６分けれない同じ階層のデータと考えてください。

上記のようなデータを収めようとした場合
カテゴリーを自己参照するとデータのストラクチャーが決まってしまうため登録できなくなってしまいます。

tGroupの外部キー２つを複合代替キーとすると同じ構造が登録できなくなってしまいます。

すみませんがもう少しご教授ください。
よろしくお願いします。
1

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