# 汎用DB開発 - mtg議事録

## ドメイン知識
- 典型問題演習
- 現在作成中. 過去問演習講座と異なる商品.

## メンバーと工数
- 中井 : コンスタント 10h程度/1week.
- 津田 : 10h/1week
- 石本 : 10h/1week
- 吉田 : 10h/1week. 年内はあまり時間が取りにくい
- 坂上(さかじょう) : 今週は3-5. 再来週くらいから10近く
- 松田 : 5-10h/1week
- 妹尾(せのお) : 今週は10h. 来週以降は5h
- 森 : 10h/1week. 年内は5h程度
- 畑中 : 5h/1week
- 福田 : 5h/1week
- 遠藤 : 10h/1week
- 阿部 : 5-10h/1week
- 西村 : -5h/1week. ちょっと知識足りない気がしているので力になれそうになったら本気を出せるくらいのペースでいきたいです
- 千原 : 5-10h/1week まだ自分もDBの知識が足りてないような気がするので、今週時間かけたいと思ってます。

## スケジュールと分担
- 12/2 DB仕様決定
- 12/9 ERD決定. 物理設計のERDも作成
- 12/16 MySQLにおける完全なテーブル定義を行うsqlファイル作成とdocker化完了
- 12/23 最低限データの流し込みとエクスポートに必要なビュー作成. RDSへのデプロイ
- 12/30 最終成果物確認
- 1/1〜 更新を含めたCRUD操作のためのビュー作成→API実装

---

## 12/9 21:00 参加者 : 後藤さん、中井、津田、吉田、坂上(さかじょう)、松田、遠藤、阿部、千原、福田、石本、森、畑中、妹尾(せのお) (遅刻 : 西村)

- 質問/連絡事項
- 現在はAOTの当初の方針をなぞってマスタデータをsql文でimportできるように設計していると思いますが、マスタデータ更新用のAPIを用意してAPI経由で更新することとのpros/consはなんでしょうか？ (社員さん、石本さん、森本さんあたりに伺いたいです)
- (後藤さん) 特に強いこだわりはないが、apiでもsqlでも楽な方で
- (石本) APIにすると、APIを知っている人間が誰でもupdate/insertなどができてしまう. データの整合性を取るため、流し込むデータのリソースは固定にしたい.
- APIにするとvmのspikeが気になる (ピーク時のアクセス数に耐えれるか)
- そんなことを考慮するくらいなら、sqlでバッチ処理を書いた方が楽なのでは
- 各自進捗/作業工数報告
- 中井 : (進捗)最終調整を行いました (作業工数)引き続き10h前後 (その他)
- 千原 : (進捗)特になし (作業工数)5-10h (その他)
- 妹尾 : (進捗) (作業工数)10h (その他)
- 遠藤 : (進捗) (作業工数) (その他)
- 福田 : (進捗) (作業工数) (その他)
- 吉田 : (進捗) (作業工数) (その他)
- 石本 : (進捗) (作業工数) (その他)
- 阿部 : (進捗)特になし (作業工数)10h (その他)
- 森 : (進捗) (作業工数) (その他)
- 松田 : (進捗)特になし (作業工数)10h (その他)
- 津田 : (進捗) ERDの最終調整をしました. (作業工数) 10h前後 (その他)
- 畑中 : (進捗) ERDの現在の状態に関してキャッチアップしました．(作業工数)5h(その他)
- 坂上 : (進捗)最新のものに追いつきました (作業工数)5-10h (その他)
- 西村 : (進捗)なし (作業工数) -2(その他)
- チーム進捗
- 最新のERDはslackを参照
- 過去問 / 問題集 / 確認テスト (中井, 千原(5-10), 妹尾, 西村(-5h))
- 採点ユニットテーブルについて、ここだけ主キーが自然キーのままであった (確認テストや修了判定テストの採点単位の主キーは問題IDとグループIDであり、採点NOはない) ため、サロゲートキーに変更
- 単ジャを作るためには、問題集とかも「大問ID+scoring_no」としてexportできる必要があるので、tgt用のマスタエクスポートに支障がないかを確認する
- その他、試験科目CD&試験年度との紐付けを変更
- 自チーム周りの設計はひと段落したという認識
- **修正点**
- 問題集については、大問に試験科目がつく
- 既にある大問に対するキーを持つか
- 大問テーブルに変更する
- TGT (遠藤, 福田(5), 吉田(10))
- MTGを踏まえて、タグの親子関係を閉包テーブルモデルで管理するようにしました。
- タグと科目の紐付けを整理しました。
- タグ付け用タグ科目
- 過去問PJ_タグ科目
- TGT_タグ科目
- **修正点**
- 過去問pjに出力するために、過去問pj用教科IDなどを追加する必要はありそう
- 過去問詳細 (石本, 阿部(5-10), 森, 松田)
- 前回のMTGを踏まえて一部修正しました。
- おおよそ終わったと思います。
- 過去問pj (津田, 畑中(5), 坂上(10))
- 前回のmtgで不必要であることが分かったテーブルやカラムを削除し,ERDの最終調整しました.
- masterブランチにあるERDにはマスタ出力に必要なカラムが全て含まれていることを再度確認しました.([スプシ](https://docs.google.com/spreadsheets/d/1pxkJ2PWUd4Zfb9lcAe9CfOUTn3AjtRbjPt5Q23X7HSI/edit?usp=sharing))
-
- 次の手順について
- MySQLにおける完全なテーブル定義を行うsqlファイル作成とdocker化完了
- MySQLはカラムを追加する際、好きな位置に追加できる. postgresは末尾にしか追加できない
- 基本的な機能は双方使える
- とりあえずひたすらcreate_table
- 空のテーブルがたくさんできる
- .sqlファイル
- →→ 頂いて、自分がdocker compose upできるようにする
- **import/exportを行う実際のデータを収集する** (重要)
- 各テーブルについて、1つずつ確認してbacklogにまとめてください
- [専用ページ](https://n-contents.backlog.com/alias/wiki/613055)を次週までに埋める
- 用意できなければ、カラムとテスト用のデータだけでも
- (できれば、import用のtransactionとexport用のviewを作成する)
- [参考](https://n-contents.backlog.com/git/CT_48/DataBase-Kousu-Mapping/blob/abe/drf_answersheets/db/commands/update_kousu_mapping.sql)
- 実データで欲しいものがあれば、後藤さんへ依頼
- (石本)マスタでーたの一覧はある?
- ない. きちんとしたのはTGTのテーブル定義書
- 採点ユニットもこのテーブル定義書に基づく
- データの中身も順次渡すことは可能
- あとはデータだけが存在する状況など
- あるマスタで追加できないデータをどう補うか考える
- 一旦追加せずにマスタを登録できるようにするためにNOT NULL制約を外す必要がある or 他のマスタも一緒に登録する etc
- こういうことを考えていると、ERDに修正が必要な場合も出てくる → 適宜修正&PR
- その他

## 12/2 21:00 参加者 : 後藤さん、田村さん、中井、津田、吉田、坂上(さかじょう)、松田、妹尾(せのお)、遠藤、阿部、千原、福田、石本 (遅刻 : 西村、森) (欠席 : 畑中)

- 連絡事項
- 各自進捗/作業工数報告
- 中井 : (進捗) (作業工数) (その他)
- 千原 : (進捗) (作業工数) (その他)
- 妹尾 : (進捗)ER図のキャッチアップしました (作業工数)だいぶ働けます (その他)
- 遠藤 : (進捗) (作業工数) (その他)
- 福田 : (進捗)特になし (作業工数)-5 (その他)忙しめ
- 吉田 : (進捗)特になし (作業工数)~10 (その他)
- 石本 : (進捗) (作業工数) (その他)
- 阿部 : (進捗) 演習大問_採点ユニット紐づけテーブルを再確認してERDを修正 (作業工数) 10h(その他)
- 森 : (進捗) (作業工数) (その他)
- 松田 : (進捗) タグ周りのリレーション確認 (作業工数) 時間取れます (その他)
- 津田 : (進捗) ER図の更新などを行なった. (作業工数) 10h前後(必要があればそれ以上も可) (その他) 特に無し.
- 畑中 : (進捗) (作業工数) (その他)
- 坂上 : (進捗) ほとんどありません (作業工数)今週はあまり動けなさそうです…… (その他)なし
- 西村 : (進捗)中井さん変更分の確認 (作業工数) -1 (その他) 別業務が忙しく時間が取れません
- チーム進捗
- 最新のERD
- ![image][main.png]
- 過去問 / 問題集 / 確認テスト (中井, 千原(5-10), 妹尾, 西村(-5h))
- 冗長なテーブル構成を一部変更しました
- 主には、「紐付けテーブル」の一部は冗長なテーブル分割になってしまっていたため、非キー属性に追加する形に変更
- 採点ユニットに「試験種」の属性を入れました
- 問題集と確認テスト/修了判定テストのメタデータを含めて新たに再構成しました
- **講座コードマスタはTGTではない**
- 過去問pj周りとの分掌も津田さんと話し合いの上調整しました
- 疑問 : 教科IDの関係 (問題集に付与されているもの、過去問pjのもの、TGTのもの) がよくわかっていないのでFKを持たせ兼ねている
- 試験種に持たせている試験科目CDも無くした方が良さそう
- (後藤さん)
- 問題にはタグがついていて、タグに科目がつく方が扱いやすい
- 一方、問題検索などでは問題に科目がついていた方が良さそう
- (田村さん) 試験科目と科目ID(タグ科目)は異なる
- 試験科目を問題に紐付けて、タグ科目をタグに紐付ける
- 問題が決まる=試験科目が決まる→試験科目_タグ用科目_紐付けから科目IDが複数決まる→結びつけられるタグが決まる
- 試験科目CDは問題集と確認テストにはつけられない (入試年度がないから)
- → 別の科目をつける必要がある
- 案1 : 問題用科目をつける
- 案2 : 問題1つごとに複数タグ科目をつけられるように
- 案3 : 試験科目マスタに「入試年度」にダミーデータを入れた上で追加する (フローを統一化できる)
- 教科IDは英数国理社程度.
- 試験科目CDがあれば決まる. 過去問試験種は下の案で大丈夫 (教科IDは不要)
- pj科目は過去問pj用演習に必要なので消さない
- 疑問 : 試験種箱と大学マスタの関係
- 志望校コード (受験単位) と試験種 を使い分ける
- 試験種は問題が同じであれば学部学科が違くても同じ試験種
- 志望校コードは学部学科ごと異なる
- 「大学マスタ+試験科目CD」は「試験種箱」に対して複数結びつく
- 大学マスタと試験科目マスタをPKにもつテーブルの属性に試験種箱を追加する形に変更
- (森本) 章の階層構造を、タグマスタのように「親」を持たせるようにすることもできそう
- (田村さん) 複雑になりすぎるので、何層か決め打ちするのも手段
- (後藤さん) これはアノテーションに必要なメタ情報?
- 問題集のアノテーションが3層構造だから3層構造になっている (西文に合わせてる)
- 一番細かい単位がきちんと決まっていれば問題ないのでは
- (田村さん) 章テーブルに「親章ID」の属性を入れ、問題に紐づくのは最小単位の章ID. (ループになっているのが少し怖い)
- TGT (遠藤, 福田(5), 吉田(10))
- (from中井) 汎用DB開発ではTGTのデータ形式でエクスポートするという用途はあったが、TGTのデータをこちらで持っておく必要があるのはどうしてか (教科IDや科目ID 使っていない..?)
- (遠藤)最初からあったからそのままという感じです。。
- タグ紐づけ対象・タグ紐づけ（タグ紐づけ対象・レベル紐づけ）もデータの持ち方としては冗長になってしまうので、中井さんがslackで挙げられていたようにビューとして保持して、テーブルとしては持たない方が良いかと思いました。
- タグ紐づけ対象マスタ、タグ紐づけ対象種別マスタも、「採点ユニットマスタ_一意キー紐付け」をなくすという方向性であれば、「タグ紐づけ対象ID」「タグ紐づけ対象種別ID」「タグ紐付け対象診断利用フラグ」（後者二つは自動生成できる？）を採点ユニットの方に持たせて、ビューとして作成した方が良いと思います。
- タグ紐づけ対象IDのハンドリングを完全にこちらでできない場合は別テーブルで持った方が良いかも？
- (遠藤) タグ紐付け対象IDがどのように採番されるか
- (後藤さん) TGT用の大問IDが一意になっていれば大丈夫
- TGT側で分かれていたら別のIDをふりたい (同じ採点ユニットで異なる演習大問の場合異なるタグ紐付け対象IDを結びつけられるようにしておきたい)
- → **演習大問_採点ユニット_紐付けの方に追加すれば大丈夫**
- この場合、種別マスタに結びつかなくなるが、種別IDは汎用DBで保持しなくて良いのか
- (後藤さん) 種別IDも演習大問_採点ユニット_紐付けに追加すれば大丈夫 (一応持っておいた方が良い)
- → 種別マスタも持っておき、演習大問_採点ユニット_紐付けの種別IDとFK
- タグマスタ周りの設計が結局決まっていない..?
- → TGT側にエクスポートはできる. 現状過去問pjへのエクスポートは考えていなかった
- (遠藤) タグマスタを過去問PJに対してoutputすることはあるのか
- (後藤さん) 大問とタグの紐付けデータは過去問PJ向けにエクスポートできる必要はない.
- (後藤さん) タグマスタはあくまでタグの情報のみ. タグと大問の紐付けは含まない. これらは大下さんに裏から入れてもらう形で運用中
- (遠藤) この時に必要な形式がわからない..
- → (後藤さん) 以前お渡しした形式.
- (遠藤) 過去問pj用のタグ科目をpkに追加する必要がありそう (別のテーブルにした方が良い?)
- → **明日のmtgで確認**
- 過去問詳細 (石本, 阿部(5-10), 森, 松田)
- 静的ファイルを追加した
- (from中井) 静的ファイル置き場において、画像の何枚目という情報は保持しなくて良い?
- (石本) これは追記します
- (from津田) [こちら](https://it-ntw8349.slack.com/archives/C02MH8KMWMV/p1638439687050200) について、確認していただけましたでしょうか？問題なさそうであれば自分の方でERDを編集しておきます。
- 合格者平均得点率, 受験者平均得点率, 問題形式, 標準時間(SEC)は演習大問に置く方針で大丈夫
- 汎用DB用大問の出典IDは (確認テスト/問題集/二次私大)を区別するのが目的だったので足してしまって大丈夫
- 過去問pj (津田, 畑中(5), 坂上(10))
- マスタ出力に関してあまり理解できていませんでしたが, 後藤さんとのmtgなどを通して, 理解できてきました。
- 汎用DBの目的の1つに「マスタ出力」があり、その出力に必要なカラムがERD上にあるかを確認した
- タグ関連で2点疑問が
- (with遠藤) 演習大問_採点ユニット_紐付けにタグ紐付け対象診断...フラグも必要か
- or エクスポートするときに自動で付与する形式にもできる
- (後藤さん) とりあえず全部1で良いので、持たせる必要はない
- タグIDと別にレベルIDも出力する必要がある. レベルIDを汎用DB側で演習大問だけに持つか、演習大問と採点ユニットの両方に持つ必要があるか
- (後藤さん) 現状は演習大問ごとについている. 演習大問の中の採点ユニットは全部同じレベルになる運用. 今後採点ユニットごとに異なるレベルIDを付与するのであれば、採点ユニットでもレベルIDを持つ必要がある
- → ひとまず演習大問ごとにレベルIDがあれば良い. 今は採点ユニットについている. 消して演習大問の方に入れるように変更.
- (from中井) TGTのエクスポートに必要なデータの洗い出しはどうなった?
- [こちらのスプシ](https://docs.google.com/spreadsheets/d/1pxkJ2PWUd4Zfb9lcAe9CfOUTn3AjtRbjPt5Q23X7HSI/edit?usp=sharing) で全てのカラムを網羅できているか管理しています。
- 上記に関して, 以下の数点検討が必要です.
- タグ紐付け対象診断利用フラグについて(遠藤さんからご説明いただけるとありがたいです)
- レベルIDを採点ユニット単位にもつけるのかどうか
- マスタ出力用の出典IDについて
- 演習大問で大問IDを持つならpos〇〇系統は全て必要ない？
- →消す (TGT用の試験種IDがあれば問題ないので)
-
- 上記の件を踏まえた上で、汎用DBの目的が「マスタ出力を過去問PJの代わりにできるようにする」と「過去問・問題集・確認テスト等を同列で扱えるようなDBを作る」という2点なのであれば過去問PJ専用の領域にあるものは全て不要な気がしているのですが、どうでしょうか？
- 例えば, 3つを同列で扱うのであれば、過去問PJ_科目などではなく、3つとも同じ科目を持つだけでいいのではないでしょうか？（汎用試験種テーブルが試験科目CDというカラムを持っているのでそれで十分な気がしています。試験科目CDがどのようなものか分かっていませんが...）
- PJ科目やPJ大学は検索などで用いるためいる
- 設立区分は検索では使用しないためいらない. POS大問情報用科目もいらない (必要になったら足す形でも大丈b)
- PJタグ科目はタグ周りの情報として必要になるからいる.

- その他
- 演習セットマスタは多対多
- (遠藤) 過去問pj_演習大問に科目idが入っているが、複数になり得ないか
- 過去問pjタグ科目は演習大問に対して1つ結びつく.
- グループIDを忘れている