Q&A
ご回答ありがとうございます。非常に分かりやすいご指摘で、頭の整理ができました。
それぞれのテーブルが自分の親を参照するだけで遡れるのは分かりましたが、回答を保管するAnswerテーブルは、自分の親になるテーブルが中項目の時もあれば小項目のときもあるので、親になる可能性のある項目のidを持っておくという認識は合っていますでしょうか？
前提・実現したいこと
Railsで、学生たちに国語・数学・理科・社会・英語の習熟度をラジオボタンを使って0~5段階でチェックしてもらうアプリを作成しようとしています。
躓いていること
DB設計で躓いてしまい、お力をお借りしたいです。
今回、例えば数学であれば、
このように、大項目の下に中項目、中項目の下に小項目、というような形式です。
これが残り４教科分あります。
加えて、最後にアンケート欄を設けます。
考えてみたテーブル設計
■ Userテーブル
name:string
password:string
あとadminなど追加、、、
■ Questionテーブル
user_id:integer ← 誰の回答なのかを管理するため
description:text ← 冒頭の説明文
■ FirstClassテーブル(大項目)
first_title:text ← 大項目の名称(数学)
■ SecondClassテーブル(中項目)
second_title ← 中項目の名称(数Ⅰ、数A)
first_class_id:integer ← どの大項目に属するかを管理するため
■ ThirdClassテーブル(小項目)
third_title ← 小項目の名称(順列)
first_class_id:integer ← どの大項目に属するかを管理するため
second_class_id:integer ← どの中項目に属するかを管理するため
■ ForthClassテーブル(少々項目)
forth_title ← 小項目の名称(円順列、重複順列)
first_class_id:integer ← どの大項目に属するかを管理するため
second_class_id:integer ← どの中項目に属するかを管理するため
third_class_id:integer ← どの小項目に属するかを管理するため
■ Answerテーブル
user_id:integer ← 誰のアンケートなのかを管理するため
first_class_id:integer ← どの大項目に属するかを管理するため
second_class_id:integer ← どの中項目に属するかを管理するため
third_class_id:integer ← どの小項目に属するかを管理するため
forth_class_id:integer ← どの少々項目に属するかを管理するため
coice_number:integer ← 回答番号
今回のような少し複雑な表をデータベースにするとき、このような考え方で合っていますでしょうか？？
初歩的な質問かもしれませんが、どうぞよろしくお願い致します。
回答3件
0
ベストアンサー
質問文にある表の形をそのまま DB にするので十分では？
User テーブル id, name, password, ... Category テーブル id, 教科名, 項目名1, 項目名2, 項目名3, 項目名4, 項目名5 Answer テーブル id, user_id, category_id, 回答
Category テーブ中の文字列の重複記載が気になるなら、
名前 テーブル id, 名前
として、Caeroby てテーブルに 名前_id を記載するようにすればよいです。
親子関係のリンクをレコードに持つ方法は柔軟性はありますが、質問文にあるような形式の表示を組み立てようとする際に苦労する気がします。
投稿2019/04/23 14:28
総合スコア22324
0
「Aさんの重複順列が2点」
という情報がわかれば
「重複順列は順列に属する」
「順列は数Aに属する」
「数Aは数IAに属する」
「数IAは数学に属する」
と遡れますよね。
質問のケースでは一つ一つのテーブルが自分の親を参照するだけで十分なはずです。
仮に質問に記載されているように一番下の項目がすべての上位項目に対して「どこに属するか」と指定を入れた場合、「重複順列は数IAに属し、英語に属する」かつ「数IAは数学に属する」という矛盾が発生してしまう可能性を含んでしまい、データの整合性が担保できなくなってしまいます。
投稿2019/04/23 11:27
総合スコア6753
点数それぞれが1レコードになるので、点数を格納する単位にまずは粒度を合わせたほうがいいと思います。
僕だったら、「数と列」「円順列」は同じテーブルに格納して、その親はそれぞれ「数と列」「順列」にすることで、親子が同じ名前になる場合は中間が分岐していないだけだと解釈すればいいのではないでしょうか。
返答ありがとうございます。
>「数と列」「円順列」は同じテーブルに格納して、その親はそれぞれ「数と列」「順列」にすることで、親子が同じ名前になる場合は中間が分岐していないだけ
というのが少し難しいのですが、整理して考えさせていただきます！
数学 -> 数1A -> 数A -> 順列 -> 円順列 -> Aさんが2点
に対して
数学 -> 数1A -> 数1 -> 数と列 -> 数と列 -> Aさんが2点
とみなせば同じ階層の数で表現できますよね？
ちなみに、「Aさんが2点」と言っても２つの値の意味（「数と列」、「円順列」の点数）は違うのでデータベース上は親IDが違って同じレコードにはなりませんし、
同じ「数と列」であっても、違う階層を表現しているものなのでデータベース上はテーブルが分かれるため同じものではありません。
「数と列」と「円順列」を同じ階層で考えるということの意味が分かりました。個人的に、親子で名前が同じになるケースを考えるとややこしく感じるので、以下のテーブル設計で進めてみようと思います。
Category(項目)テーブル
id, 教科名, 項目名1, 項目名2, 項目名3, 項目名4, 項目名5
⇒(項目名3, 項目名4, 項目名5はnullの場合もある)
Answer テーブル
id, user_id, category_id, 回答
非常に分かりやすい指摘をいただきましてありがとうございます！
また考えが詰まったとき、ご助力いただけますと嬉しいです。
0
DBの設計について一番単純なデータ保持の仕方は
「隣接リストモデル」すなわち、自分のIDを持ち、自分の親のIDを持つ方法
SQL
1create table tbl(id int primary key,pid int null,name varchar(20),endflg tinyint); 2insert into tbl values 3( 1,null,'数学',0), 4( 2, 1,'数IA',0), 5( 3, 2,'数I',0), 6( 4, 3,'数と列',1), 7( 5, 3,'論理と集合',1), 8( 6, 3,'2次関数',1), 9( 7, 2,'数A',0), 10( 8, 7,'場合の数と確率',1), 11( 9, 7,'順列',0), 12(10, 9,'円順列',1), 13(11, 9,'重複順列',1), 14(12, 1,'数IIB',0), 15(13,12,'数II',0), 16(14,13,'式と証明',1), 17(15,13,'複素数と方程式',1), 18(16,13,'図形と方程式',1), 19(17,12,'数B',0), 20(18,17,'平面ベクトル',1), 21(19,17,'空間ベクトル',1);
endflgは最終データかどうか（別になくてもよい）
- データ検出
SQL
1select * from tbl as t1 2left join tbl as t2 on t1.id=t2.pid 3left join tbl as t3 on t2.id=t3.pid 4left join tbl as t4 on t3.id=t4.pid 5left join tbl as t5 on t4.id=t5.pid 6where t1.pid is null 7order by t1.id,t2.id,t3.id,t4.id,t5.id 8
※この場合データの保持が冗長なため
ネストが最大いくつになるかをわかっていないと調べられません。
これを更に効率よく管理するには「入れ子集合モデル」という
データ保持の仕方が必要です。
このモデルの場合、データがインタラクティブに変化していくため
プロシージャという仕組みで随時データを書き換える必要がでてきますので
もし興味があるようなら聞いてください
投稿2019/04/23 10:50
総合スコア114757
ご回答ありがとうございます。プロシージャという単語は初めて聞きました。SQLもまだ全然なレベルなので時間がかかるかもしれませんが、丁寧にご回答いただいたのでしっかり調べたいと思います。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2019/04/23 14:56
2019/04/23 22:24
2019/04/24 06:49
2019/04/24 12:19
2019/04/24 14:48
2019/04/24 20:55
2019/04/25 00:47
2019/04/25 12:13
2019/05/01 05:20