---
# System prepended metadata

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

---

# 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上だと問題ない