# ITチーム各PJ間データベースmtg#2

## 開催情報

| 日付 | 5/15
| -------- | ---------------------------------- |
| 主催 | 楠本 |
| 開始時刻 | 19:00 |
| 終了時刻 | |
| 場所 | Zoom （[録画リンク]()） |
| 参加人数 | 名 |
| 参加者 | 楠本(DB)、西川(スプレッドシート、添削者評価) |

## 目的
- スプレッドシートとの担当範囲を決定する

## データ類
- [現在扱うデータ類](https://drive.google.com/drive/folders/1m9Dy4AGQk1-K40_ORlgFOpiYu5OvHUcU)

## スプシに保存するデータ
- 添削者リストなど
- 添削者評価など

## DBに保存するデータ
- 添削者リストの変わらない部分はDBに載せる
- team添削者の扱い
- 退職したときに番号を削除する機能

## すみわけ
- 一回、二回くらいしか更新しないデータはスプシ
- 頻繁に使うデータはDB
- リーダーがスプシで編集する
- →編集し終わったデータをDBに反映する
- IT業務で扱うデータはDBに保存する
- 日報PJ
- 週例MTGでどの程度のデータを保存する必要があるのか聞く
- 基準
- 一日一回以上の更新がある場合はスプシで管理
- 取り出し頻度について聞く必要がある
-

---

# ITチーム各PJ間データベースmtg#1

## 開催情報

| 日付 | 5/11 |
| -------- | ---------------------------------- |
| 主催 | 楠本 |
| 開始時刻 | 22:00 |
| 終了時刻 | |
| 場所 | Zoom （[録画リンク]()） |
| 参加人数 | 名 |
| 参加者 | 楠本(DB), 赤司(opstts_tgt), 西川(添削者評価),<br>河野(slack),樋口(CL),畑中(DB),<br>瀬尾(日報),石川(DB),阿部(管理POS),遠藤(返却),<br>高橋(振り分け),大鐘(統括/22:30~),|

## 目的
- 入出力形式に関して明確に規定する
- DBpjと他PJとの担当範囲を明確にする

## DBpjの現段階構想
- データレイクに非構造化データを含めて全ての入力を保存する。
- AWS S3への保存をapi形式で全PJに提供する
- Amazon DynamoDBテーブルデータをAmazon S3のデータレイクにエクスポートする
- 生データをapi経由で送信してもらう
- ETLは決まっていない。
- クロージングPJ・返却PJ
- 小さいデータがリアルタイムで求められる。管理POSでデータを取得するorデータベースから引いてくる。
- Aさんがある時刻で答案を5件持っている等
- 添削者-答案情報は常に更新するものではない。
- 更新頻度ではなくETLに入るのかどうか。
- 管理POSで答案を動かしてもETLには入らずDBの更新ができない。
- そこが難しい。
- 返却状況のリアルタイム性に関して
- 拡張機能を使う
- 差し戻しはフレームワークを使って実現
- だれが答案を持っているかの情報は事前にDBに格納されているのか
- 返却以前に把握するための情報をDBで管理しておくのかどうか
- 振り分けからとってくることは可能
- 定期的な取得はなくはない(opstts,tgt)
- 受付段階・振り分け段階・返却開始時に格納
- 基本的には情報が送られるたびにDBに保存
- 現状のDBに関して、定期的な情報はDBだがリアルタイム性の高い業務に関しては直接管理POSなどで完結するのではない
- 管理POSとの連携？
- **管理POSで完結する情報に関しては管理POSで完結させる？**
- 受付から返却まで(変わる情報)：管理POS
- 返却後(変わらない情報)：DB
- ASIDに関しては管理POSのアクセス集中は避けたいので情報が担保されているDBで管理する方向性でもいい
- DBの現状の目的
- **複数の業務にまたがるテーブルに関して管理しておく場所を提供**
- 常に最新にすることは考慮しなくてもいいのでないか
- リアルタイム性は妥協してもいい
- opsttsPJ
- ETLに関して
- 現状としては、データの加工は他のPJで任せて、DBはその加工されたデータを格納→加工前のデータでいい
- DBには使いやすいデータを格納してほしい
- 7z(解凍前)をデータレイクにいれる
- ETLで解凍
- ETLでの加工はopsttsPJ側が作ればいい
- opsttsがDBに吸収される形にはなると思う
- GraphQLでselectだと柔軟性がある
- rest apiだとデータもらった後に結合(汚いし手間)
- GraphQLは必要十分な情報をいっぺんにゲットできる
- table同士の結合を考えなくて良い
- その代わり導入に慣れてないので工数がかかるかも
- 工数との紐付けはデータウェアハウスからとりだしたあとに行う
- GraphQLなのか、RestAPI+Pandasなのか
- Pandasだと汚いし，保守性は悪くなる
- どちらでもできる
- 無駄がなくなり早くなる
- opsttg,tgtの観点からGraphQLのほうがいい
- APIの対応はDB側か他PJかは負担によって判断する
- 工数分析以外はRESTAPIでもいい
- 実装はDjangoのRESTAPIの部分をGraphQLに書き換える感じになると思われる。
- graphene-djangoってのがある
- 出力ではdjango rest apiを考えている。
- 生データを必要分受け渡しした後は、pandas等で整形する形を考えている。SQLを直接叩くのは学習コストや引継ぎの観点、言語の複数化の観点からあまり望ましくない。
- 列の指定などをどうするか？が問題

## 各PJへのヒアリング結果
- [各PJに聞いた必要なデータ類](https://drive.google.com/drive/folders/1m9Dy4AGQk1-K40_ORlgFOpiYu5OvHUcU)
- 上記の回答をベースにDBへの搭載の是非を考えました。
- [データベースpj議事録](https://hackmd.io/baN08vjaSbKJj5hfU3Oy0Q#DB%E3%81%AB%E5%85%A5%E3%82%8C%E3%82%8B%E3%81%8B%E5%85%A5%E3%82%8C%E3%81%AA%E3%81%84%E3%81%8B)

## 各PJとの担当範囲について
- データウェアハウスのテーブル形式を決めておく
- 各PJに関してデータウェアハウス内のテーブルの組み合わせから提供することができる
- DBに入れなれないデータに関しては別のAPIに委託
- テーブルの提示をDB側から提供
- カラムの追加は難しい
- テーブルの正規化を事前にしておく
- 各PJとの相談としてはクエリとKeyを明確化させる
- APIは分割したテーブルごとに存在するのか
- RestAPIはテーブルごとなので、複数APIを叩いて取得する
- あるPJのみが使う組み合わせはそのPJに作成
- よく使う組み合わせに関してはDBPJ側で提供
- 格納する行数
- DB上だと問題ない