実践データベース設計 ①データベース設計概論

実践データベース設計 ①データベース設計概論プロジェクト推進部藤本毅 2025年7月15日

(C) Recruit Co.,Ltd. All rights reserved. 2 当講座と『実践アプリケーション設計』の2講座を通しての目標架空のECサイト「R書店」を題材に、データ
ベースからアプリケーションの設計・実装に関する広範なナレッジを体系的に整理し、全体を俯瞰して理解を深めていただく。また、開発現場で求められる設計や実装のポイント等を実践的な課題や演習を通して、丁寧に解説する。

(C) Recruit Co.,Ltd. All rights reserved. 3 講師自己紹介① 【名前】藤本
毅（フジモトタケシ）【所属】プロジェクト推進部【経歴】 IT企業、常駐型開発会社、スタートアップ支援会社、通信キャリア等を通してB2BからB2Cまで（官公庁システム、チャットサービス、広告、音楽、エンタメ、旅行、金融、飲食、 HR等）様々なシステムの開発に携わる

(C) Recruit Co.,Ltd. All rights reserved. 4 【言語・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、PyTorch ..etc 講師自己紹介②

(C) Recruit Co.,Ltd. All rights reserved. 5 【直近の活動】 Web(フロントエンド、バックエンド)、インフラ（オンプレミス・クラウド）、サイバーセキュリティ、スマートフォン（iOS、Android、
Tyzen）、電子回路・FPGA、機械学習・ディープラーニング、3Dゲーム開発、OSやネットワーク等の低レイヤー技術等、長年の試作やOSSの解析、業務経験等を通して得た様々な知見や技術を活かし、それらを統合する研究を個人でおこなっている【その他】総務省異能vationノミネート、大手ベンチャーキャピタルのアクセラレーションプログラムのファイナリスト..etc 講師自己紹介③

(C) Recruit Co.,Ltd. All rights reserved. 6 本資料の目的データベースとその仕組みや種類、およびデータベース設計とそれに関連する主なト
ピックについて概要を解説する。

(C) Recruit Co.,Ltd. All rights reserved. 7 目次 1. はじめに：データベースとは
2. 用語の確認 3. データベース設計の前に必要なこと 4. 本題：データベース設計 5. データモデリング 5-1. 概念データモデリング 5-2. 論理データモデリング 5-3. 物理データモデリング 6. データベースの変更容易性 7. オブジェクト指向とデータベース

(C) Recruit Co.,Ltd. All rights reserved. 8 目次 8. データベース設計における盲点（NULL）
補足：マスタ（M）とトランザクション（T） 9：「イミュータブルデータモデル」 10. 大規模システムにおけるデータベース 11. データベースのアーキテクチャ 12. デーベース設計の実践 13. データベース設計で大事なこと 14. 当講座の推薦図書 15. 当講座の関連リポジトリ

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

(C) Recruit Co.,Ltd. All rights reserved. 11 データと情報の違いについてデータ（Data）：一定の目的に沿って観測したり、収集した数
値や文字列、日付等情報（Infomation）：データに一定の文脈における解釈を加えたもの

(C) Recruit Co.,Ltd. All rights reserved. 12 ①階層型データベース ②リレーショナルデータベース ③オブジェクト指向データベース
④XMLデータベース ⑤NoSQLデータベース主なデータベースの種類

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

(C) Recruit Co.,Ltd. All rights reserved. 14 • リレーショナルデータベースは、表（テーブル）を使用してデータを格納する。テーブルは行（レコード）と列（属
性）で構成され、SQL（Structured Query Language）という特定の言語を使用してデータを管理する。 • リレーショナルデータベースは汎用性が高く、整合性と耐久性を保証するための厳格な制約が特徴 • Oracle、MySQL、PostgreSQLなどが有名 • スケーラビリティが課題であったが、近年その部分を強化した「New SQL」と呼ばれる製品群も登場している ②リレーショナルデータベース

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

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

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

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

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

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

(C) Recruit Co.,Ltd. All rights reserved. 23 注：MySQLのスキーマ MySQLはデータベースとスキーマを「同一」とみなしており（3層構造）、MySQLにおいてはデータ
ベースとスキーマは同義語である MySQLの階層構造インスタンススキーマI スキーマII スキーマIII テーブルA テーブルB テーブルC テーブルD テーブルE テーブルE

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

(C) Recruit Co.,Ltd. All rights reserved. 25 テーブルテーブルは、データを管理・保存するための入れ物行と列で構成され、データはレコードとして記録される
列A 列B 列C 列D 列E 行列レコードテーブルのイメージ

(C) Recruit Co.,Ltd. All rights reserved. 26 テーブルの結合テーブルの結合とは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

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

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

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

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

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

(C) Recruit Co.,Ltd. All rights reserved. 32 クエリクエリとは、SQLを実行した際にデータベースへ送るための命令文のこと
SQLとクエリの違い（混同されやすい） • SQL：データベースを操作するための言語 • クエリ：SQLを実行する際にデータベースに送る命令文

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

(C) Recruit Co.,Ltd. All rights reserved. 34 トランザクション SELECTおよび更新系のINSERT/DELETE/UPDATE等の
複数のSQLクエリを一貫性のある形でひとまとまりにして扱い、実行する仕組み

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

(C) Recruit Co.,Ltd. All rights reserved. 37 「要求」と「要件」の明確化設計の前に「要件」と「要求」の明確化が重要ビジネス要求
ビジネス要件業務要求業務要件システム要求システム要件 ※赤俊哉著『要件定義のセオリー』に掲載の図を元に作成

(C) Recruit Co.,Ltd. All rights reserved. 38 要求と要件の違い • 「要求」＝
本当に欲しいもの＝ユーザが情報システムで実現したいこと • 「要件」＝本当に要るもの＝要求に基づきつつ、制約を踏まえて、情報システムに盛り込むべきもの

(C) Recruit Co.,Ltd. All rights reserved. 39 要件と要求の関係圧倒的な数の要求に対して、絞り込み、練り込んだ要件からシステムを設計・実装する
要求要件引用元：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

(C) Recruit Co.,Ltd. All rights reserved. 40 ウォーターフォール開発とアジャイル開発における要求の取り扱いの違いウォーターフォール（WF）開発とアジャイル（Agile）
開発はソフトウェア開発のアプローチにおいて大きく異なる哲学とプロセスを持っており、特に、要求定義の取り扱い方において顕著な違いがある

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

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

(C) Recruit Co.,Ltd. All rights reserved. 43 補足：アジャイル開発における要件定義アジャイル開発では繰り返しの前に、要件定義で大枠をしっかり掴み、設計から実装工程でなるべくブ
レを生じさせないことが大切

(C) Recruit Co.,Ltd. All rights reserved. 45 データベース設計とはデータベース設計とは、データベースによってデータを管理できるように、現実の世界を
抽象化してデータモデルを作成していく作業（データモデリング）

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

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

(C) Recruit Co.,Ltd. All rights reserved. 49 エンティティはリソース系orイベント系および従属or独立のそれぞれの軸で分けられるエンティティの種類
独立従属リソース系イベント系

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

(C) Recruit Co.,Ltd. All rights reserved. 51 独立エンティティ例えば「顧客」や「商品」など、他のエンティティに依存することなく存在するエンティティ
従属エンティティ他のエンティティに依存して存在する「受注明細」（「受注」がないと成立しない）のようなエンティティ独立エンティティと従属エンティティ

(C) Recruit Co.,Ltd. All rights reserved. 52 リレーションシップは、エンティティ（実体）同士のつながり（関係）を意味するが、大きく分けて以下の3つに分類されるリレーションシップの種類
リレーションシップの種類 ①依存型 ➁非依存型 ③汎化型

(C) Recruit Co.,Ltd. All rights reserved. 53 あるエンティティが他に依存して存在する場合、その関係はリレーションシップは依存型（「従属関係」という呼び方もある） 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

(C) Recruit Co.,Ltd. All rights reserved. 54 エンティティ間の依存関係がない場合は、非依存型のリレーションシップになる（「参照関係型」という呼び方もある） 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

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

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

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

(C) Recruit Co.,Ltd. All rights reserved. 59 概念設計システムに必要なデータの全体像（概念データモデル）を定義することによって、データ
に関する要求を明確にする作業概念データモデルはビジネス（業務）の観点で必要な情報の体系をデータモデルとして表現したもの

(C) Recruit Co.,Ltd. All rights reserved. 60 論理設計特定のデータベースに依存しないデータモデル（論理データモデル）を作る
論理データモデルでは、業務における意味を反映した日本語での項目名や項目に関する説明などを定義することで、業務においてどのようなデータが必要なのかを詳細に定義する

(C) Recruit Co.,Ltd. All rights reserved. 61 物理設計特定のデータベース（Oracle, DB2,
SQL, Server…）を前提とした物理的なデータ仕様を定義した物理データモデルを作る物理データモデルでは、具体的にはテーブル、属性、キー制約、別名、インデックス、ビューといった実際のデータベース構築に必要な詳細情報を定義する

(C) Recruit Co.,Ltd. All rights reserved. 62 各工程での主な成果物概念設計：コンセプトモデル図(UML) 論理設計：ER図、エンティティ状態遷移図
、エンティティ定義書等物理設計：ER図、テーブル定義書ライフサイクル定義書、キー項目体系定義書、DDL 等

(C) Recruit Co.,Ltd. All rights reserved. 63 データモデルパターンデータモデルパターンは、システム設計におけるデザインパターンと同様に業種や業務の
違いに左右されない汎用なデータモデル ※代表的なパターンとして、人や組織を表す「パーティパターン」や受注/発注を表す「取引パターン」等がある

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

(C) Recruit Co.,Ltd. All rights reserved. 66 データモデリングのアプローチ方法システム開発は「トップダウンで骨組み、ボトムアップで肉付け」が基本で、DB設計に
に関しても同様の考えでモデリングする

(C) Recruit Co.,Ltd. All rights reserved. 67 トップダウンアプローチトップダウンアプローチとは、ビジネス要件 →業務要件→システム要件とブレイクダウン
してきた要件を基に、「本来あるべきデータモデル」を作成する手法で、主にリソース系エンティティの抽出と定義で行われる

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

(C) Recruit Co.,Ltd. All rights reserved. 69 データモデリングでは、属性を統一したグループを”ドメイン”と呼ぶ一方で『実践オブジェクト指向設計』で扱うドメイン駆動設計における”ドメイン”は「システムが対象とする事業が取り扱う世界」を表し、全く別のものを指
すので混同しないように注意注：データモデリングにおける”ドメイン”

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

(C) Recruit Co.,Ltd. All rights reserved. 72 概念データモデルを省くケース特にコンシューマ向けシステムで、この工程を実施しないケースも多く、また「論理データモデル」を
ほぼ「概念データモデル」として位置付けるアプローチもある。しかしながら、エンタープライズ系等、業務で扱うデータの全体像を掴む必要がある場合は、「木を見て森を見ず」にならないように作成が推奨される

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

(C) Recruit Co.,Ltd. All rights reserved. 75 論理モデル設計フェーズで行うこと • 属性の定義
• 属性名の命名ルールの標準化と明確化 • ドメインの定義 • 正規化の実施 • 主キーと外部キーの設定 • サブジェクトエリアの確定 ..etc

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

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

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

(C) Recruit Co.,Ltd. All rights reserved. 80 物理データモデル作成後は、以下を考慮しながら、DB の実装環境を構築していく •
キャパシティプランニング • パーティショニング • 性能要件（パフォーマンス） • 排他制御 • データセキュリティ • トランザクションの単位..etc 物理設計後の考慮事項

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

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

(C) Recruit Co.,Ltd. All rights reserved. 85 データベースの変更の難しさを踏まえたデータモデリングのポイント •
「構築するシステムのデータベース設計」よりも広い視野に立ち「将来も見据えた最適なデータモデルを検討する」こと • 既存のデータやテーブル構造に直接的な影響を与える変更より漸進的に追加・拡張していく形が望ましい

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

(C) Recruit Co.,Ltd. All rights reserved. 91 複数の項目に対して複合ユニーク制約を設定しても、どちらかの項目がNULLの場合、重複を許してしまう。例えば下記の例では deleted_atとemailで複合ユニーク制約を設定してもdeleated_at
がNULLの場合に重複を許してしまう。その原因はSQLの3値論理。複合ユニーク制約とNULL 同じ値が重複で INSERTできてしまう複合ユニーク制約

(C) Recruit Co.,Ltd. All rights reserved. 92 3値論理とは通常の真 (true) と偽
(false) から成る真偽値の他に、第3の真理値を持つ論理体系（多値論理のひとつ）。 SQLでは、NULLはTRUEやFALSEではなく「値が存在しない（不明＝UNKNOWN）」を意味する。そのため、前頁では複合ユニーク制約(email, deleted_at)を設定しているにも関わらず、deleted_at がNULLの場合、同じemailの値を持つレコード同士が重複と判断されないため、重複データのINSERTが可能になった。 SQLの3値論理について

(C) Recruit Co.,Ltd. All rights reserved. 99 • 「すべてをイミュータブル（不変）にすべき」は現実的では
ない • 「重要な状態変化（意味のあるビジネスイベント）」を不変な履歴として残すのがイミュータブルデータ設計の目的 • 「現在の状態」は必要な場合は少なくない（従ってUPDATE を全く使わない設計もまた現実的ではない）イミュータブルデータモデルのポイント

(C) Recruit Co.,Ltd. All rights reserved. 102 大規模サービスにおけるインデックスの重要性大規模サービスにおいて、インデックス（Index）は非常に重要で、正しいインデックス設計が性能・
可用性・スケーラビリティ等に直結する。理由1 データ量大規模サービスはデータ量が指数関数的に増える理由2 ユーザ数やトラフィック大規模サービスはユーザ数やトラフィックが多く、小さな遅延の積み重ねが致命的になりかねない理由3 スケールアウトの猶予 DBのスケールアウトは手間がかかるので、インデックスで抑えられる大規模サービスにおいてインデックスが重要になる理由

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

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

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

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

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

(C) Recruit Co.,Ltd. All rights reserved. 129 当講座の関連リポジトリ（GHE）架空のECサイトR書店 •
rbooks-jpa (https://ghe.misosiru.io/takeshi-fujimoto/rbooks-jpa) • rbooks-ddd-jpa (https://ghe.misosiru.io/takeshi-fujimoto/rbooks-ddd-jpa)

実践データベース設計 ①データベース設計概論

実践データベース設計 ①データベース設計概論

More Decks by Recruit

Other Decks in Technology

Featured

Transcript