第2回 ITパスポート社内勉強会 データベース

第2回 ITパスポート勉強会の資料です。

【コーポレートサイト】
https://yojo.co.jp/

【採用情報】
https://herp.careers/v1/yojo

Transcript

1. ITパスポート勉強会 ～データベース～
2. 勉強会の予定 ・第１回 デジタルデータ 12/ 6 ・第２回 データベース 12/13 ・第３回 ネットワーク 12/20 ・第４回 セキュリティ 12/27 目次 ・毎週月曜日全4回
3. 今日の予定 目次 • RDB • 主キーと外部キー • 論理演算 • 排他制御・トランザクション データベース
4. これらは全部データベースにやってもらいます！ データベースとは？ 複数のデータを一括管理・保存する場所です！ 顧客の住所 診断に出てくる漢方 顧客の支払方法 データを追加・削除したい！ こういう条件のデータが見たい！ データの一部を変更したい！ 複数のデータを一括管理・保存する場所です！ 私がやりましょう(キリッ データベース
5. 表から関係性が読み取れますね！ RDB（リレーショナルデータベース） 複数の「表」と、その「関係性」によって構成されるDB 顧客の住所 顧客の支払方法 顧客 この表を見ると住所と支払い方法はどの顧客のものなのかわかるように顧客IDを持っています。 ID 名前 電話番号 1 山田太郎 09000001111 2 田中一郎 09022221111 3 佐藤花子 09012345678 ID 顧客ID 住所 番地 郵便番号 1 2 東京都ああ区いい街 11-1 1111111 2 1 東京都いい区うう街 1-23-2 1232221 3 3 東京都ええ区おお街 1-33 4441115 ID 顧客ID 支払い方法 1 2 クレカ 2 1 クレカ 3 3 代引き 顧客は住所、支払い方法を持っていることがわかります。 データベース
6. これは正規化と呼ばれます 支払い方法の表現が一貫されていない そんなときは表を分けましょう！ この表はどうでしょう？ ID 顧客ID 支払い方法 1 2 クレカ 2 1 クレカ 3 3 代引き 4 6 クレジット 5 9 クレジットカード 6 5 クレカ 7 12 代金引換 検索しづらく、修正漏れしやすくなります、、、 ID 顧客ID 支払い方法ID 1 2 1 2 1 1 3 3 2 4 6 1 5 9 1 6 5 1 7 12 2 ID 支払い方法 1 クレジットカード 2 代引き これなら代引きを「代金引換」に変える場合でも 修正箇所は１つで済みますね！ データベース
7. データベース 実際にデータを見るときはデータをくっつけたり、 抽出したりします！ 顧客の支払方法 ID 顧客ID 支払い方法ID 1 2 1 2 1 1 3 3 2 4 6 1 5 9 1 6 5 1 7 12 2 ID 支払い方法 1 クレジットカード 2 代引き この状態だとデータの整合性や一貫性を保つこと ができますが、ちょっと見づらいですね... 支払方法 選択 （必要な行を抽出） ID 顧客ID 支払い方法ID 3 3 2 7 12 2 代引きの人だけ抽出 射影 （必要な列を抽出） 支払方法だけ抽出 結合 （関連の表を結合） ID 顧客ID 支払い方法ID 支払方法 3 3 2 代引き 6 5 1 クレジットカード ID 支払い方法 ID 1 1 2 1 3 2 4 1 5 1 6 1 7 2 支払方法の表を右に結合 見るとき用の一時的な表（ビュー）を作ります！
8. データベース 問１ 問２ A. ウ フィールドとは表の中の項目のこと（IDや支払方法など） で、関連性からデータの一貫性や整合性を考え、フィール ドを整理する作業は正規化と呼ばれます。 この中で本質的に重複しているのは生年月日と年 齢です。 生年月日から年齢を知ることはできますが、年齢 から生年月日を知ることはできないため、今回は 年齢の方が削除可能です。 A. イ ちなみにYOJOではユーザーの中に年齢の項目があり、生年月日は元々 なかったため、入力したときの年齢のまま永遠に変わりません笑
9. データベース 顧客の住所 顧客 ID 名前 電話番号 1 山田太郎 09000001111 2 田中一郎 09022221111 3 佐藤花子 09012345678 ID 顧客ID 住所 番地 郵便番号 1 2 東京都ああ区いい街 11-1 1111111 2 1 東京都いい区うう街 1-23-2 1232221 3 3 東京都ええ区おお街 1-33 4441115 これらの表において… 名前や電話番号は同じデータが複数作成される可能性があります。 このように、行を特定できる項目を主キーといいます！ しかし、顧客IDが１のデータは１つしかありません また、関連する表の主キーを持っている項目を 外部キーといいます！ 主キー 主キー 外部キー
10. データベース 配送 こういうデータがあったとき、複数条件でデータを 絞り込みたいことがあります。 こういうときは論理演算をします！ ex) 昨日の配送のうち、まだ配送中のものを知りたい 両方の条件を満たす！ ID 状態 配送先ID 作成日 1 未発送 3 2021/12/13 2 配送中 2 2021/12/12 3 完了 1 2021/12/12 4 配達中 4 2021/12/11 5 完了 5 2020/1/2 6 完了 7 2019/9/30 7 完了 6 2019/7/1 AND（論理積） 条件１ 条件２ OR（論理和） 条件１ 条件２ どちらか１つでも 条件を満たす！ 今回の例だと (作成日が昨日) AND (状態が配送中) ですね！
11. データベース 問１ 問２ A. イ 上の図を言い換えると、BまたはCの部分かつAではな い部分なので、（Aではない）かつ（BまたはC）にな ります！ 積集合はANDのことなので、表Aと表Bの共通部分 であるせんべいとチョコレートになっているはず です！ A. エ
12. データベース ID 商品名 在庫 1 漢方A 3 2 漢方B 2 3 漢方C 4 商品 データベースはデータを一括で管理していますが、同 時に操作されると不整合を起こす可能性があります。 漢方Bが2人に売れたとします。 例えば、、、 それぞれの担当者2人が同時に漢方Bの在庫を確認し、 売れた分在庫を１引くと？ 担当者A 担当者B 在庫は２か、、 在庫は２か、、 １つ引いて １に更新！ １つ引いて １に更新！ ２つ売れたのに在庫が１つある ことになってしまいます…
13. データベース どうすれば防げるでしょうか？ このように、処理中に他の人からのアクセスをロックすること を排他制御といいます！ 他 の 人 更 新 禁 止 ！ 共有ロック 担当者B 在庫は２か、、 在庫は１か、、 １つ引いて １に更新！ １つ引いて ０に更新！ 今回だと、 ↓ こういう流れになればいいですね！ 担当者A 誰かが編集中だ！ 更新を待とう！ データを見ることはできますが、 更新することはできません！ 占有ロック データを見ることも、更新する こともできません！ 在庫は常に見れた方が良いので 共有ロックがいいですね！
14. データベース 問１ 問２ A. ウ 同時アクセスによるデータ不整合の防止に役立つのが 排他制御です。 ③の更新前に②の読み取りがされているため、② で読み取ったのは初期値の10になります。よって ④で書き込まれるのは17です！ A. エ
15. データベース YOJOでは購入時、 もし、この処理が②と③の間で止まってしまったらどうでしょうか？ お金を払ったのに何も届かなかったら大問題ですね！ ↓ こんな感じで処理が進みます！ ①クレカの決済処理 ②注文を完了状態にする ③支払いを完了状態にする ④配送を準備状態にする お金が支払われ、注文も完了したことになっているのに、支払われたことに なっておらず、配送も作られません。
16. データベース ではどうすればいいか？ このようにどれか１つでも失敗すると不整合が起きる １連の処理単位をトランザクションと呼びます！ ①クレカの決済処理 ②注文を完了状態にする ③支払いを完了状態にする ④配送を準備状態にする ①～④までは一連の処理なので、どこかでエラーが発生したらそれまでの処理 もなかったことにしたいですね！ ex) ②～③で処理が止まったら、①、②の処理が成功していても、実行前の データ状態に巻き戻す必要があります！ これはロールバックと呼ばれます
17. データベース 問１ 問２ A. エ 関連する１連の処理単位がトランザクションです。 Bは更新履歴と書いてあるのでログファイルが正しいで す。バックアップファイルにはデータそのもののコ ピーが入っています。 A. エ ４の処理が失敗した場合（3まで成功）のみ、AとBが 残った状態になります！
18. データベース 次回予告 ネットワーク LANとWAN プロトコル ネットワークの構成 12/20 21時からやります！ keywords