【研修資料】データベース基礎

by エブリー

Slide 1

Slide 1 text

データベース基礎 2025/09/08

Slide 2

Slide 2 text

Slide 3

Slide 3 text

講義の目的とゴール

Slide 4

Slide 4 text

Slide 5

Slide 5 text

データとは

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Copyright © 2015 every, Inc. All rights reserved. 12 ● リレーショナルデータベース（RDB） ○ データベースと言えば一般的に RDBのことを指す ○ データを人間が理解しやすい二次元表形式で管理 ○ データ間の関連（リレーション）を管理するのが得意 ○ 例）レシピのID、タイトル、栄養素などを持つマスターデータ ● キーバリューストア（KVS） ○ データをKey（識別キー）とValue（値）を組み合わせたデータベース ○ シンプルなデータの問い合わせが高速 ○ 例）ユーザIDをキー、レシピID一覧をバリューとして持つレシピ推薦 ● オブジェクトストレージ ○ データをオブジェクト（データ本体とメタデータ）として管理 ○ スケーラビリティが高く、大量のデータを安価に保存できる ○ 例）media-bucket：recipe/{レシピID}/video.mp4 log-bucket：access/{日付}/{月}/{日}/hogefuga.gz 発生したデータをどこに保持するかデータベース ---- -------- File Log DB DB

Slide 13

Slide 13 text

SQL

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Copyright © 2015 every, Inc. All rights reserved. 15 SQLの実行順序データベース順序句内容 1 FROM 参照するテーブルやビューを決める 2 JOIN 必要な他テーブルを結合する 3 WHERE 条件に合わないデータを除外する 4 GROUP BY 指定したキーでグループ化する 5 HAVING グループに対して条件で絞り込む 6 SELECT 出力する列・式などを選択する 7 ORDER BY 結果を並び替える 8 LIMIT 返す行数を制限する

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Copyright © 2015 every, Inc. All rights reserved. 20 トランザクション：関連する一連の処理を一つのまとまりとして扱う仕組み SQL：ACID トランザクションデータベース特性内容 Atomicity （原子性）トランザクションの処理を分割しない（全て実行する / しない） Consistency （一貫性）トランザクションの実行前後でデータベースの整合性を保つ Isolation （独立性）同時に複数人が操作してもお互いに干渉しない Durability （永続性）トランザクションをCOMMITした結果が失われない

Slide 21

Slide 21 text

Copyright © 2015 every, Inc. All rights reserved. 21 SQL：トランザクションがない場合の問題点データベーストランザクションがないと、送金が途中でとまる / 同時処理で片方の更新を上書き【一貫性の欠如（Consistency）】 Aさんの口座からお金を引き落とした時に障害が起きると Bさんの口座には振り込まれない【同時実行制御の欠如（Isolation）】 Bさんの口座にAさんとCさんが同時に振り込んだ時に、トランザクションがないと一方の更新が消えてしまう

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

正規化・インデックス

Slide 27

Slide 27 text

Slide 28

Slide 28 text

28 Copyright © 2015 every, Inc. All rights reserved. 正規化の仕組みと段階 • 正規化と結合 • 正規化するとテーブルは細分化 • JOINで結合すれば元の形に戻せる（可逆） • 正規形の段階 • 第1正規形：繰り返し項目をなくす • 第2正規形：主キーの一部依存を排除 • 第3正規形：主キー以外への依存を排除 • 第4・第5正規形：より高度な整理（実務ではあまり使わない） 👉 実務では第3正規形までがよく使われる

Slide 29

Slide 29 text

29 Copyright © 2015 every, Inc. All rights reserved. 第1正規化目的：キーに対して値が一意に定まる状態（関数従属性）を保証すること • ex. {顧客ID} → {顧客名}、 {顧客ID} → {商品} • RDBのテーブルは第一正規形を満たしている顧客ID 顧客名商品 C001 佐藤キャベツにんじん C002 鈴木 C003 田中みかんブドウメロン購入品第1正規化を満たしていないテーブル❌

Slide 30

Slide 30 text

30 Copyright © 2015 every, Inc. All rights reserved. 第1正規化目的を達成するために • 1つのセルに単一の値になるようにする顧客ID 顧客名商品1 商品2 商品3 C001 佐藤キャベツにんじん C002 鈴木 C003 田中ぶどうみかんメロン顧客ID 顧客名商品 C001 佐藤キャベツ C001 佐藤にんじん C002 鈴木 C003 田中ぶどう C003 田中みかん C003 田中メロン OR 購入品購入品

Slide 31

Slide 31 text

31 Copyright © 2015 every, Inc. All rights reserved. 第1正規化目的を達成するために • キーは一部であっても NULLを含んではならない顧客ID 顧客名 C001 佐藤 C002 鈴木 C003 田中顧客ID 商品 C001 キャベツ C001 にんじん C003 ぶどう C003 みかん C003 メロン顧客商品テーブルの分割を行う顧客ID 顧客名商品 C001 佐藤キャベツ C001 佐藤にんじん C002 鈴木 C003 田中ぶどう C003 田中みかん C003 田中メロン購入品主キーが定まらない！

Slide 32

Slide 32 text

32 Copyright © 2015 every, Inc. All rights reserved. 目的：部分関数従属を解消して、完全関数従属のみの状態にすること • 完全関数従属 : キーを構成する全ての列に対して従属する状態 • ex. {任意のキー1, 任意のキー2} → {一意の値} • {顧客ID,商品コード} → {購入個数} ⭕ 第2正規化顧客ID 商品コード顧客名商品名カテゴリID カテゴリ名単価購入数量 CUST001 P001 佐藤キャベツ CAT001 野菜 150 10 CUST001 P002 佐藤にんじん CAT001 野菜 100 5 CUST003 P003 田中りんご CAT002 果物 150 3 CUST003 P004 田中みかん CAT002 果物 80 20 CUST003 P005 田中ぶどう CAT002 果物 300 2 購入履歴第2正規化を満たしていないテーブル❌

Slide 33

Slide 33 text

33 Copyright © 2015 every, Inc. All rights reserved. 第2正規化 • 部分関数従属 • {顧客ID} → {顧客名} ❌ • {商品コード} → {商品名, カテゴリID, カテゴリ名, 単価} ❌ 第2正規化を満たしていないテーブル❌ 顧客ID 商品コード顧客名商品名カテゴリID カテゴリ名単価購入数量 CUST001 P001 佐藤キャベツ CAT001 野菜 150 10 CUST001 P002 佐藤にんじん CAT001 野菜 100 5 CUST003 P003 田中りんご CAT002 果物 150 3 CUST003 P004 田中みかん CAT002 果物 80 20 CUST003 P005 田中ぶどう CAT002 果物 300 2 購入履歴

Slide 34

Slide 34 text

34 Copyright © 2015 every, Inc. All rights reserved. 第2正規化目的を達成するために • 部分関数従属している列を、依存先のキーと共に別のテーブルに切り出す • 各テーブルの情報がキーに対して一意に定まるようになった顧客ID 顧客名 CUST001 佐藤 CUST003 田中商品コード商品名カテゴリID カテゴリ名単価 P001 キャベツ C001 野菜 150 P002 にんじん C001 野菜 100 P003 りんご C002 果物 150 P004 みかん C002 果物 80 P005 ぶどう C002 果物 300 顧客ID 商品コード購入数量 CAT001 P001 10 CAT001 P002 5 CAT003 P003 3 CAT003 P004 20 CAT003 P005 2 購入履歴商品顧客

Slide 35

Slide 35 text

35 Copyright © 2015 every, Inc. All rights reserved. 第3正規化目的：推移的関数従属が解消された状態にすること • 推移的関数従属 : {X} → {Y} → {Z}のときZはXに推移的関数従属している商品コード商品名カテゴリID カテゴリ名単価 P001 キャベツ CAT001 野菜 150 P002 にんじん CAT001 野菜 100 P003 りんご CAT002 果物 150 P004 みかん CAT002 果物 80 P005 ぶどう CAT002 果物 300 商品第3正規化を満たしていないテーブル❌

Slide 36

Slide 36 text

36 Copyright © 2015 every, Inc. All rights reserved. 第3正規化 • 推移的関数従属 • {商品コード} → {カテゴリID} ({X} → {Y}) • {カテゴリID} → {カテゴリ名} ({Y} → {Z}) • {商品コード} → {カテゴリID} → {カテゴリ名} ({X} → {Y} → {Z})❌ 商品コード商品名カテゴリID カテゴリ名単価 P001 キャベツ CAT001 野菜 150 P002 にんじん CAT001 野菜 100 P003 りんご CAT002 果物 150 P004 みかん CAT002 果物 80 P005 ぶどう CAT002 果物 300 商品第3正規化を満たしていないテーブル❌

Slide 37

Slide 37 text

37 Copyright © 2015 every, Inc. All rights reserved. 第3正規化目的を達成するために • 推移的関数従属の原因となっている {カテゴリID} と {カテゴリ名 } を、新しい商品カテゴリテーブルとして切り出す商品コード商品名カテゴリID 単価 P001 キャベツ CAT001 150 P002 にんじん CAT001 100 P003 りんご CAT002 150 P004 みかん CAT002 80 P005 ぶどう CAT002 300 商品カテゴリ ID カテゴリ名 C001 野菜 C002 果物商品カテゴリ

Slide 38

Slide 38 text

38 Copyright © 2015 every, Inc. All rights reserved. インデックス • テーブルの索引のようなもの • 特定のデータを見つけたい時に、順に探すのではなくダイレクトに示すことでクエリのパフォーマンスをあげるもの • テーブルのデータとは別にオブジェクトとして保持されている • SQLの評価順序が上位の WHERE句やORDER BY句に指定される列に設定すると効果的

Slide 39

Slide 39 text

39 Copyright © 2015 every, Inc. All rights reserved. インデックスの内部構造 B+Treeインデックス • 多くのRDBMSでデフォルト採用 • データを木構造で管理し、範囲検索や ORDER BYに強い • 例: WHERE age BETWEEN 20 AND 30 Hashインデックス • ハッシュ関数で値を直接検索 • 等価検索 (WHERE id = 123) に高速 • 範囲検索や順序付けには不向き

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

デリッシュキッチンのデータフロー

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Copyright © 2015 every, Inc. All rights reserved. 46 データの流れ : RDB② デリッシュキッチンのデータフロー 1. ユーザーが操作を行う 2. B/EサーバーへAPIが呼ばれ、クエリ生成 3. DBでクエリが実行され、データの取得・作成・更新・削除が行われる 4. 3.の結果をサーバーで処理した結果がレスポンスになる頻繁にアクセスされるデータはキャッシュから取得

Slide 47

Slide 47 text

Copyright © 2015 every, Inc. All rights reserved. 47 データの流れ : ログデリッシュキッチンのデータフロー ● アクセスログ ○ F/E, B/Eのサーバー訪問者の情報と時刻 ○ 例：クライアントIP, リクエストURL, ステータスコード ● エラーログ ○ アプリケーション実行中に発生したエラーの内容を含む ⇨ログはオブジェクトストレージに格納される

Slide 48

Slide 48 text

Copyright © 2015 every, Inc. All rights reserved. 48 ● リレーショナルデータベース（RDB） ○ データベースと言えば一般的に RDBのことを指す ○ データを人間が理解しやすい表形式で管理 ○ データ間の関連（リレーション）を管理するのが得意 ● キーバリューストア（KVS） ○ データを識別キー（キー）と値（バリュー）を組み合わせたデータベース ○ シンプルなデータの問い合わせが高速 ● オブジェクトストレージ ○ データをオブジェクト（データ本体とメタデータ）として管理 ○ スケーラビリティが高く、大量のデータを安価に保存できる発生したデータをどこに保持するか (再掲) データベース ---- -------- File Log DB DB

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Copyright © 2015 every, Inc. All rights reserved. 50 各種AWSサービス： KVS AWSサービス ● ElastiCache for Redis ○ 完全マネージド型のインメモリデータストア ○ 高速なキャッシュとデータベース機能を提供している ○ ミリ秒単位の低レイテンシでデータにアクセスでき、アプリケーションのパフォーマンスを大幅に向上させる ○ レシピの材料や作成者などはRDS上で別のtableに保存されている ⇨Redisではまとめて一つのオブジェクトとして保存 ElastiCache

Slide 51

Slide 51 text

Copyright © 2015 every, Inc. All rights reserved. 51 各種AWSサービス：オブジェクトストレージ AWSサービス ● S3 ○ ログや動画などのメディアデータが保存されている ○ 高い耐久性（99.999999999%）を誇り、どんな規模のデータでも低コストで保管できる ○ バージョニングやライフサイクル管理など、データ管理のための豊富な機能を提供する S3

Slide 52

Slide 52 text

Copyright © 2015 every, Inc. All rights reserved. 52 デリッシュキッチンのデータ基盤デリッシュキッチンのデータフロー BigQuery S3 RDS クライアントのログマスタデータファイル・ログ外部APIなどデータレイク：データ統合と大規模分析機械学習(ML)：AIモデル開発と活用 DevOps, CI/CDなどフローの管理生データビジネスデータへビジネスロジック QuickSight 分析ツール

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Slide 55

Slide 55 text

Copyright © 2015 every, Inc. All rights reserved. 55 Q. サーバーの基盤とデータの基盤はなぜ分離するのでしょうか？　例えばMasterデータはサーバーにあるのに、データ基盤にもMasterデータをコピーして用意します。それはなぜだと思いますか？ A. データ分析・集計をするのにサービス上のDBに負荷をかけたくないため Question デリッシュキッチンのデータフロー