実践データベース設計

by Recruit

Slide 1

Slide 1 text

実践データベース設計プロジェクト推進部藤本毅

Slide 2

Slide 2 text

Slide 3

Slide 3 text

(C) Recruit Co.,Ltd. All rights reserved. 3 【⾔語・OS・フレームワーク等】 Mac, Linux(CentOS, Debian, Ubuntu, Kali, Raspberry Pi ), Windows C#、C、C++、Clojure、Ruby、Python、Ocaml、Haskell、PHP、Java、 Kotolin、Scala、Swift、Objective-C、JavaScript、CoffeeScript、 TypeScript、Go Ruby On Rails、CodeIgniter、Django、Spring、Laravel、 Playframework、sokko、 React、 Backbone.js、Vue.js、Unity、 Metasploit、Nessus、TensorFlow ..etc 【直近の活動】 Web(フロントエンド、バックエンド)、インフラ（オンプレミス・クラウド）、サイバーセキュリティ、スマートフォン（iOS、Android、Tyzen）、電⼦回路・FPGA、機械学習・ディープラーニング、3Dゲーム開発、OSやネットワーク等の低レイヤー技術等、⻑年の試作やOSSの解析、業務経験等を通して得た様々な知⾒や技術を活かし、それらを統合する研究を個⼈でおこなっている講師自己紹介②

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

(C) Recruit Co.,Ltd. All rights reserved. 8 データベースの始まり（アドレス帳）データベースの始まりはアドレス帳名前電話番号メールアドレス住所 ○山○男 03-12xx-99xx [email protected] 東京都港区XXX △田△子 042-x4x-34xx [email protected] 東京都町田市XXX ×木×太 023-x8-33xx [email protected] 千葉県千葉市XXX ・・・・・・・・アドレス帳のイメージ

Slide 9

Slide 9 text

Slide 10

Slide 10 text

(C) Recruit Co.,Ltd. All rights reserved. 10 • 階層型データベースは、データを階層的な構造で管理する。この種類のデータベースは、データ要素が親⼦関係を持つツリー構造で表される • 各要素は⼀つの親要素を持ち、複数の⼦要素を持つことができる • 階層型データベースは、その構造が直感的であるため、特定のアプリケーション、特にファイルシステムの管理に適しているが、現代の多くの⽤途には柔軟性に⽋けるとされている ①階層型データベース

Slide 11

Slide 11 text

(C) Recruit Co.,Ltd. All rights reserved. 11 • リレーショナルデータベースは、表（テーブル）を使⽤してデータを格納する。テーブルは⾏（レコード）と列（属性）で構成され、SQL（Structured Query Language）という特定の⾔語を使⽤してデータを管理する。 • リレーショナルデータベースは汎⽤性が⾼く、整合性と耐久性を保証するための厳格な制約が特徴 • Oracle、MySQL、PostgreSQLなどが有名 ②リレーショナルデータベース

Slide 12

Slide 12 text

(C) Recruit Co.,Ltd. All rights reserved. 12 • オブジェクト指向データベースは、オブジェクト指向プログラミング⾔語の概念を利⽤してデータを管理するデータベースで、これにより、データをオブジェクトとして保存し、クラス、継承、多様性などのオブジェクト指向の機能を直接データベース管理システム内で使⽤することができる • このタイプのデータベースは、複雑なデータ構造を持つアプリケーションに適している • 主な製品にはObjectDBやdb4o、 GemStone/S等がある ③オブジェクト指向データベース

Slide 13

Slide 13 text

(C) Recruit Co.,Ltd. All rights reserved. 13 • XMLデータベースは、XML形式でデータを格納するために設計されていることで、階層的なデータとしてのXMLの強みを⽣かし、柔軟なデータモデリングと⾃⼰記述的なデータ形式が可能になる • XMLデータベースは、Webサービスやインターネットベースのアプリケーションでの使⽤が理想的 • 主な製品にBaseXや、eXist-db、Berkeley DB XML等がある ④XMLデータベース

Slide 14

Slide 14 text

(C) Recruit Co.,Ltd. All rights reserved. 14 • NoSQLデータベースは、リレーショナルデータベースのスキーマレスな代替品として登場した。 • スキーマが固定されていないため、柔軟なデータ構造を扱うことができ、⼤規模なデータセットの⾼速処理に適している。 • 主なタイプにはドキュメント型（MongoDBなど）、キーバリューストア（Redisなど）、列指向データベース（Cassandra、Google BigQueryなど）、グラフデータベース（Neo4jなど）があります。 ⑤NoSQLデータベース

Slide 15

Slide 15 text

Slide 16

Slide 16 text

(C) Recruit Co.,Ltd. All rights reserved. 16 リレーショナルデータベースはハードディスクで保持する実体としてのバイナリファイルとそれを操作・管理するアプリケーションのデータベース管理システム（DBMS）で構成される。なお、DBMSを持たず直接ファイルを操作する SQLiteやハードディスクではなくメモリ上に構築するインメモリDBもある）引用元：https://cz-cdn.shoeisha.jp/static/images/article/12216/12216_06.jpg データベースの仕組み（DBMS）

Slide 17

Slide 17 text

Slide 18

Slide 18 text

(C) Recruit Co.,Ltd. All rights reserved. 18 インスタンスデータベースは階層構造になっており、最上位に位置する概念がインスタンスインスタンスはDBMSが動く際の単位で、OSからは「プロセス」として⾒える例： Oracleのインスタンス（プロセス）引用元：https://encrypted- tbn0.gstatic.com/images?q=tbn:ANd9GcS9vWMSi_YkHICZGC0KMM76PJYDLKG9iaBm0g&s

Slide 19

Slide 19 text

(C) Recruit Co.,Ltd. All rights reserved. 19 スキーマデータベースはインスタンスを最上位に階層（通常4 層構造）に分かれており、そのフォルダ（ディレクトリ）に該当するのがスキーマリレーショナルデータベースの階層構造インスタンスデータベース1 データベース2 スキーマI スキーマII スキーマIII テーブルA テーブルB テーブルC テーブルD テーブルE テーブルE

Slide 20

Slide 20 text

Slide 21

Slide 21 text

(C) Recruit Co.,Ltd. All rights reserved. 21 注︓Oracleのスキーマ Oracleではデータベースとスキーマは別（4層構造）であるが、1つのインスタンスの配下に1つしかデータベースを作れないため、実質3層構造 Oracleの階層構造インスタンスデータベーススキーマI スキーマII スキーマIII テーブルA テーブルB テーブルC テーブルD テーブルE テーブルE

Slide 22

Slide 22 text

Slide 23

Slide 23 text

(C) Recruit Co.,Ltd. All rights reserved. 23 テーブルの結合テーブルの結合とはSQLの「結合（JOIN）」を使⽤してデータベース内の複数のテーブルから関連するデータを組み合わせて新たなデータセットを作成する⽅法で、結合の種類には、内部結合、外部結合、クロス結合などがあり、それぞれ異なるシナリオや要件に応じて活⽤される引用元：https://xs691486.xsrv.jp/wp-content/uploads/2024/01/2.27- 2%E3%80%801.%E5%86%85%E9%83%A8%E7%B5%90%E5%90%88%E3%80%80%E5%86%85%E9%83%A8%E7%B5%90%E5%90%88%E3%80%81%E5%A4%96%E9%83% A8%E7%B5%90%E5%90%88%E3%80%81%E3%82%AF%E3%83%AD%E3%82%B9%E7%B5%90%E5%90%88%E3%80%802000%C3%972000-1024x1024.jpg

Slide 24

Slide 24 text

(C) Recruit Co.,Ltd. All rights reserved. 24 インデックスインデックスはテーブル内の⼤量のデータの中から必要な情報を素早く⾒つけ出すための道しるべのようなものインデックスの仕組み本の索引が特定の主題やキーワードがどのページにあるのかを明⽰することで、情報を迅速に検索できるようにしているように、データベースのインデックスもテーブル内の特定の列（フィールド）に対して作成され、その列に格納されているデータの検索を⾼速化する

Slide 25

Slide 25 text

(C) Recruit Co.,Ltd. All rights reserved. 25 SQLとは SQLはデータベースがデータ操作のために備えている⾔語で⼤きく3つに分類される ● DDL︓データ定義⾔語 ● DML︓データ操作⾔語 ● DCL︓データ制御⾔語なお、データベース製品には多くの種類があるが、 SQLはISO（国際標準化機構）で標準化されているため、SQLを覚えれば多くのデータベースで扱える

Slide 26

Slide 26 text

(C) Recruit Co.,Ltd. All rights reserved. 26 DDL DDL（Data Definition Language）はデータ定義⾔語と呼ばれ、テーブルや索引、シーケンスなどのデータベースオブジェクトを定義する⾔語データベースやテーブルを新規に作成（CREATE）する場合や、変更（ALTER）、削除（DROP）する際に使⽤するまた、テーブルに格納されているデータを⼀括ですべて削除するTRUNCATEも、DDLに含まれる

Slide 27

Slide 27 text

(C) Recruit Co.,Ltd. All rights reserved. 27 DML DML（Data Manipulation Language）はデータ操作⾔語と呼ばれ、データベースを操作し、格納されているデータの検索や削除などを⾏うための⾔語データベースを使⽤する中で最も使⽤する⾔語と⾔えます。命令⽂は、データの検索（SELECT）、更新（UPDATE）、挿⼊（INSERT）、削除（DELETE）がある

Slide 28

Slide 28 text

(C) Recruit Co.,Ltd. All rights reserved. 28 DCL DCL（Data Control Language）はデータ制御⾔語と呼ばれ、データやトランザクションを制御するための⾔語です。ユーザーに対してアクセス権限を付与（GRANT）する命令や、権限の取消（REVOKE）が含まれるなお、データベース製品によっては、COMMITや ROLLBACKなどトランザクションを制御する⾔語（TCL）も、DCLに含める場合がある

Slide 29

Slide 29 text

Slide 30

Slide 30 text

(C) Recruit Co.,Ltd. All rights reserved. 30 サブクエリ（副問い合わせ）サブクエリ（副問い合わせ）とは、クエリの中で使⽤される別のクエリのことを指すサブクエリを使⽤すると、複雑な条件を持つクエリを簡潔に表現でき、データの抽出や加⼯をより柔軟に⾏うことができる SELECT 商品ID, 商品名 --主問い合わせ FROM 商品リスト WHERE EXISTS ( SELECT * --このSELECT⽂が副問い合わせ FROM 売上表 WHERE 売上表.商品ID = 商品リスト.商品ID ) サブクエリの例

Slide 31

Slide 31 text

Slide 32

Slide 32 text

(C) Recruit Co.,Ltd. All rights reserved. 32 ビュー（View）ビュー（View）はSQLに名前をつけて保存した仮想テーブルのようなもの（但しテーブルのようにデータは持たず、テーブルに対するSELECTを持っている）で、ビューを使⽤するとSQL⽂がすっきり書けるメリットがある引用元：https://image.itmedia.co.jp/ait/articles/1703/01/r20_06-01.PNG 例：サブクエリをビューに置き換え

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

(C) Recruit Co.,Ltd. All rights reserved. 36 要件と要求の関係圧倒的な数の要求に対して、絞り込み、練り込んだ要件からシステムを設計・実装する要求要件引用元：https://www.google.com/url?sa=i&url=https%3A%2F%2Fwand- d.com%2Fcolumn%2F001iceberg%2F&psig=AOvVaw06p_5eR3fRFokCNZ Is9ZeL&ust=1718792150721000&source=images&cd=vfe&opi=8997844 9&ved=0CBEQjRxqFwoTCLC2hvD15IYDFQAAAAAdAAAAABAE

Slide 37

Slide 37 text

Slide 38

Slide 38 text

(C) Recruit Co.,Ltd. All rights reserved. 38 ウォーターフォール開発における要求詳細な要求定義プロジェクト開始前に全ての要求を収集・分析・⽂書化する。この段階で定義された要求はプロジェクト全体を通じて基本的に変更されることはない計画の重視: 全てのプロジェクト活動は事前に計画され、スケジュールに従って厳格に管理される引用元：https://www.ogis- ri.co.jp/otc/hiroba/technical/IntroASDooSquar e/chapter4/image/WaterfallLifecycle.jpg

Slide 39

Slide 39 text

(C) Recruit Co.,Ltd. All rights reserved. 39 アジャイル開発における要求引用元：https://www.ogis- ri.co.jp/otc/hiroba/technical/IntroASDooSquare/chapter4/image/Iterati onOfXPwithAM.jpg 進化する要求要求はプロジェクトの進⾏とともに進化し続けると考えられ、初期段階で完全には固定されない。フィードバックを基に要求が追加、変更、削除されることがある反復的・漸進的開発短い開発サイクルを繰り返し、各イテレーションでユーザーからのフィードバックを取り⼊れながら製品を改善していく

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

(C) Recruit Co.,Ltd. All rights reserved. 44 データモデルシステムまたは組織のデータの構造、関係性、および制約を記述する表現でデータ型、エンティティ、属性、およびそれらの関係（リレーション）を定義するエンティティデータモデルの構成要素のひとつで組織全体もしくはシステム開発における「静的な管理対象（取引先・商品などのデータの集まり）」を指し、「実体」と訳されるデータモデルとエンティティ

Slide 45

Slide 45 text

(C) Recruit Co.,Ltd. All rights reserved. 45 エンティティは以下の「5W1H」を表す名詞 • 誰が（Who）︓⼈、組織、取引先、顧客など • 何を（What）︓製品、商品、原材料、サービスなど • いつ（When）︓年⽉（⽇）、季節、催事、会計年度など • どこで（Where）︓国や地域、住所、店舗、陳列棚など • なぜ（Why）︓業務ルール、法律、慣⾏、問い合わせ、クレームなどエンティティが表す概念

Slide 46

Slide 46 text

Slide 47

Slide 47 text

(C) Recruit Co.,Ltd. All rights reserved. 47 リソース系エンティティデータベースの設計・実装時に「マスタ」となりうるエンティティでビジネスおよび業務におけるあり⽅を⽰し、資源となりうるものを指す例えば「取引先」「顧客」「商品」「サービス」等イベント系エンティティデータベースの設計・実装時に「トランザクション」となりうるエンティティでビジネスおよび業務の⾏為により発⽣するものを指す例えば「受注」「発注」などの出来事リソース系エンティティ/イベント系エンティティ

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

(C) Recruit Co.,Ltd. All rights reserved. 50 あるエンティティが他に依存して存在する場合、その関係はリレーションシップは依存型（「従属関係」という呼び⽅もある） ER図では独⽴エンティティまたは従属エンティティから、従属エンティティに向けて実線で結んで表現する ①依存型リレーションシップ引用元：https://qiita-user-contents.imgix.net/https%3A%2F%2Fqiita-image- store.s3.amazonaws.com%2F0%2F59354%2F16327612-8002-548a-216d- b2829ce40a25.png?ixlib=rb-4.0.0&auto=format&gif- q=60&q=75&s=cfb6a785a4b2bcc2034ea62bdc3a2f8a

Slide 51

Slide 51 text

(C) Recruit Co.,Ltd. All rights reserved. 51 エンティティ間の依存関係がない場合は、⾮依存型のリレーションシップになる（「参照関係型」という呼び⽅もある） ER図では独⽴エンティティから他の独⽴エンティティに向けて点線でつないで表現する ➁⾮依存型リレーションシップ引用元： https://www.google.com/url?sa=i&url=https%3A%2F%2Fenvader.plus%2Farticle%2F48&psig=AOvVaw1R5n OPYjWviuTPjMDYIaJg&ust=1718879139360000&source=images&cd=vfe&opi=89978449&ved=0CBEQjRxqFw oTCPjB4Pi554YDFQAAAAAdAAAAABAE

Slide 52

Slide 52 text

(C) Recruit Co.,Ltd. All rights reserved. 52 親と⼦のエンティティが汎化関係にある場合のリレーションシップを汎化型と呼ぶその場合、親エンティティを「スーパータイプ」、⼦エンティティを「サブタイプ」と呼ぶ ③汎化型リレーションシップ引用元：https://image.itmedia.co.jp/ait/articles/1703/01/r20_06-01.PNG

Slide 53

Slide 53 text

(C) Recruit Co.,Ltd. All rights reserved. 53 「サブジェクトエリア」とはデータモデル全体をいくつかに区切った場合の、個々の領域（範囲）のこと例えば業務単位で区切る場合は販売・購買・在庫管理等に分け、事業単位で管理する場合は、外⾷・物販・不動産等に分けるサブジェクトエリア（サブジェクトスコープ）引用元：https://assets.st-note.com/img/1700395732347-IkB5MlsNmQ.jpg?width=800

Slide 54

Slide 54 text

Slide 55

Slide 55 text

(C) Recruit Co.,Ltd. All rights reserved. 55 データモデリングの各⼯程データモデルを作成していく作業（データモデリング）は、⼀般的に概念設計、論理設計、物理設計という3つの段階を通して⾏われ、それぞれの段階ではアウトプットとして概念モデル、論理モデル、物理モデルが作成される引用元：https://gihyo.jp/dev/feature/01/database/0001

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Slide 58

Slide 58 text

Slide 59

Slide 59 text

Slide 60

Slide 60 text

Slide 61

Slide 61 text

Slide 62

Slide 62 text

(C) Recruit Co.,Ltd. All rights reserved. 62 DMBOKについてまたDMBOKは、データ管理に関連するさまざまな領域を包括的にカバーしており、データ管理の専⾨家が共通の基準と⾔語でコミュニケーションを図るための基盤を提供している DMBOK（Data Management Body of Knowledge）は、データ管理の専⾨知識を体系的にまとめたガイドであり、データ管理のベストプラクティス、⼿法、および⽤語を定義しており、データ管理の標準化を⽬指している引用元：https://m.media-amazon.com/images/I/51YN9LdHKgL.jpg

Slide 63

Slide 63 text

Slide 64

Slide 64 text

Slide 65

Slide 65 text

(C) Recruit Co.,Ltd. All rights reserved. 65 ボトムアップアプローチボトムアップモデリングとは業務フロー等により捕獲した発⽣データを基に、主にイベント系エンティティの抽出と定義の際に⾏われるその他、ボトムアップアプローチでは、UIプロトタイプや画⾯遷移等から項⽬（リソース系・イベント系ともに）の洗い出しと定義を⾏いつつ、正規化を実施して、「現実に即したデータモデル」を作成する

Slide 66

Slide 66 text

Slide 67

Slide 67 text

Slide 68

Slide 68 text

(C) Recruit Co.,Ltd. All rights reserved. 68 概念データモデルとは概念（コンセプト）データモデルとは、「顧客にとって興味のあるデータモデル」のことで、全体の静的ビジネス要求を把握するために作成する ※概念データモデルを作る過程では、様々なビジネスルールが明らかになってくる引用元：https://www.ulsystems.co.jp/archives/assets/topics_modeling_002_23.gif

Slide 69

Slide 69 text

Slide 70

Slide 70 text

Slide 71

Slide 71 text

(C) Recruit Co.,Ltd. All rights reserved. 71 論理データモデルとは論理データモデルは、概念データモデルにて登録したエンティティに対し、属性を定義していくことにより作成する。また、属性定義とともに、「正規化」と具体的なデータやその関係性等の「抽象化」を⾏うことにより、データ構造を確定していく引用元：https://www.ulsystems.co.jp/archives/assets/topics_modeling_002_05.gif

Slide 72

Slide 72 text

Slide 73

Slide 73 text

(C) Recruit Co.,Ltd. All rights reserved. 73 正規化とパフォーマンスについて正規化とは冗⻑さを省く反⾯、テーブル結合時のコスト等がかかるため、パフォーマンス要件の厳しいシステムではレスポンスのボトルネックの原因になりやすいので実装時には注意またその際、部分最適・局所的にパフォーマンスチューニングしようとすると設計・実装が複雑化することもあるため、アプリケーションにおいてDB 設計は⾮常に重要といえる

Slide 74

Slide 74 text

Slide 75

Slide 75 text

(C) Recruit Co.,Ltd. All rights reserved. 75 物理データモデルとは物理データモデルは、論理データモデルを基にして、以下の事項について取捨選択を⾏い、対策を講じる形で作成する • 技術上の制約 • アプリケーションの⽤途 • パフォーマンス（性能に関する要求）引用元：https://www.ogis-ri.co.jp/otc/swec/process/am-res/am/images/models/physicalDataModel.jpg

Slide 76

Slide 76 text

(C) Recruit Co.,Ltd. All rights reserved. 76 物理モデル設計フェーズで⾏うこと主に以下のような作業を⾏なうことで、「開発者が読むための論理モデル」から「実際にDBMS上に実装するための物理モデル」へデータモデルを精査していく 1. テーブル名／項⽬名に物理名（英語名）を定義 2. 属性のデータ型／桁数／精度を定義 3. ⼀意制約やNOT NULL等の各種ルールを定義 4. パフォーマンス等を考慮し「正規化崩し」を実施 5. インデックスやトリガーの定義 ..etc

Slide 77

Slide 77 text

Slide 78

Slide 78 text

Slide 79

Slide 79 text

(C) Recruit Co.,Ltd. All rights reserved. 79 データベースのリファクタリング DBのスキーマ（構造）は、アプリケーションと密接に結びついているため、以下のようなDBのリファクタリングは⼤変 • クエリの書き換え • テーブル名や属性名の変更 • 外部キーやその他制約の変更 • ビューの修正 • ストアドプロシージャの修正テーブルの定義を変更することによって、そのテーブルへアクセスする処理すべてに影響範囲が広がります。そのため、⼀度 DBに⼿を⼊れると実にさまざまな調整が必要になる

Slide 80

Slide 80 text

Slide 81

Slide 81 text

(C) Recruit Co.,Ltd. All rights reserved. 81 DB設計における拡張性の考慮拡張性の考慮とは、「将来発⽣しうる変化」を予測し、その変化が起こったときにもシステムの改修量を最低限に抑えられるようなモデルを検討すること。⾔い換えると、現状の概念モデルにおいて「現実に起こりうる業務上の変化」に耐えられないところを発⾒し、そのモデルを「変更に強いモデル」に精査していくこと引用元：https://www.ulsystems.co.jp/archives/assets/topics_modeling_002_21.gif

Slide 82

Slide 82 text

Slide 83

Slide 83 text

Slide 84

Slide 84 text

(C) Recruit Co.,Ltd. All rights reserved. 84 ソフトウェア開発においてオブジェクト指向プログラミング（OOP）とデータベースの連携や相互作⽤において両者のパラダイムの違いにより、しばしばミスマッチ（インピーダンスミスマッチ）が起こる。例えば以下の違いオブジェクト指向プログラミングオブジェクトがメモリ内でどこに存在するかは透過的で、参照を通じて⾃由に他のオブジェクトへ直接アクセスできるため、オブジェクト間の関係性も柔軟に組み替えたり、構築することが可能データベース DBのデータは固定されたテーブルの列定義に従って格納され、主キーによって各レコードの位置が定義されるため、特定のデータへのアクセスはSQLクエリを通じて、特定のパス（クエリ）を定義してその結果を得る必要があるオブジェクト指向とデータベースの連携

Slide 85

Slide 85 text

Slide 86

Slide 86 text

Slide 87

Slide 87 text

Slide 88

Slide 88 text

Slide 89

Slide 89 text

(C) Recruit Co.,Ltd. All rights reserved. 89 主に読み出し（Read）⽤のDBをレプリカとして増やして負荷分散する⽅法メリット︓運⽤が⽐較的楽、障害時のバックアップとしても使えるデメリット︓マスタが単⼀の場合、書き込みに負荷がかかるレプリケーション引用元：https://insights-jp.arcserve.com/wp-content/uploads/2022/08/ijZ7t8YUnRyXgL4Mpz2mVsuoC-1659946336.png

Slide 90

Slide 90 text

(C) Recruit Co.,Ltd. All rights reserved. 90 1つのDBサーバ上に格納された、1つのテーブルデータを、レコード（⾏）単位で複数のサーバに分散して保持することをシャーディング（⽔平分割）と呼ぶ ※正確にはシャーディングには列単位で分割する垂直分割もあるシャーディング（⽔平分割）引用元：https://i0.wp.com/pecopla.net/wp-content/uploads/2019/10/ecf48f973a24b465a8e59a97386a3ae9.png?resize=650%2C408&ssl=1

Slide 91

Slide 91 text

(C) Recruit Co.,Ltd. All rights reserved. 91 DBRE（Database Reliability Engineering）は、データベースシステムの信頼性、パフォーマンス、効率性を維持するための実践であり、SRE（Site Reliability Engineering）の概念をデータベース管理に適⽤したもので、DBREにおいては、データベースの設計が⾮常に重要。設計が不適切だと、データの登録や取得が複雑になったり、それがシステムのレスポンスタイムに悪影響を及ぼし、最終的にはアプリケーション全体のパフォーマンスが低下する等、影響が⼤きい DBREとデータベース設計

Slide 92

Slide 92 text

Slide 93

Slide 93 text

Slide 94

Slide 94 text

Slide 95

Slide 95 text

Slide 96

Slide 96 text

Slide 97

Slide 97 text

Slide 98

Slide 98 text

Slide 99

Slide 99 text

(C) Recruit Co.,Ltd. All rights reserved. 99 データベースが3層に分かれている理由データベースが3層構造に分かれている理由の⼀つが、データの独⽴性の保証で、例えば、アプリケーションの要求（外部スキーマ）が変わったり、データの物理的な格納⽅法（内部スキーマ）が変わったりしても、他の層が影響を受けないようにデザインされているこの独⽴性は、システムの拡張性と適応性を向上させ、継続的な変化に対応しやすくする

Slide 100

Slide 100 text

Slide 101

Slide 101 text

Slide 102

Slide 102 text

Slide 103

Slide 103 text

Slide 104

Slide 104 text

Slide 105

Slide 105 text

(C) Recruit Co.,Ltd. All rights reserved. 105 理想と実物との隔たりドキュメントベースで想定されるシステムのイメージと実物との隔たりは少なくなく、そのため、⽇頃から⼿を動かしてモノづくりを⾏い、要件定義や設計の際には実装から逆算してイメージしたり、思考できるようにしておくことが⼤事理想実際の実装引用元：https://thumb.ac- illust.com/0c/0c40bbe466ee623d574f8642383409f7_t.jpeg