実践データベース設計

2024年度リクルート エンジニアコース新人研修の講義資料です

Transcript

1. 実践データベース設計 プロジェクト推進部 藤本 毅
2. (C) Recruit Co.,Ltd. All rights reserved. 2 講師自己紹介 【名前】 藤本 毅（フジモト タケシ） 【所属】 プロジェクト推進部 【経歴】 IT企業、常駐型開発会社、スタート アップ⽀援会社、通信キャリア等を 通してB2BからB2Cまで官公庁シス テムからチャットサービス、広告、 ⾳楽、エンタメ、旅⾏、⾦融、飲⾷、 HR等様々なシステムの開発に携わ る
3. (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の解析、業務経験等を通して得た 様々な知⾒や技術を活かし、それらを統合する研究を個⼈でおこなっている 講師自己紹介②
4. (C) Recruit Co.,Ltd. All rights reserved. 4 当講座と『実践オブジェクト指向設計』 の2講座を通しての⽬的 架空のECサイトR書店（仮） を題材にデー タベースからアプリケーションの設計・実装 までの広範なナレッジを体系的に整理しなが ら、実践的な内容を解説する
5. (C) Recruit Co.,Ltd. All rights reserved. 5 当講義の概要 架空のECサイトR書店（仮）のアプリケー ションに必要なテーブル設計を通して実践的 なデータベース設計の講義と解説を⾏う
6. (C) Recruit Co.,Ltd. All rights reserved. 6 はじめに︓データベースとは
7. (C) Recruit Co.,Ltd. All rights reserved. 7 データと情報の違いについて データ（Data）︓ ⼀定の⽬的に沿って観測したり、収集した数 値や⽂字列、⽇付等 情報（Infomation）︓ データに⼀定の⽂脈における解釈を加えたも の
8. (C) Recruit Co.,Ltd. All rights reserved. 8 データベースの始まり（アドレス帳） データベースの始まりはアドレス帳 名前 電話番号 メールアドレス 住所 ◦山◦男 03-12xx-99xx hogehoge@test.com 東京都港区XXX △田△子 042-x4x-34xx hagehage@temp.co.jp 東京都町田市XXX ×木×太 023-x8-33xx hugahuga@wahaha.or.jp 千葉県千葉市XXX ・ ・ ・ ・ ・ ・ ・ ・ アドレス帳のイメージ
9. (C) Recruit Co.,Ltd. All rights reserved. 9 ①階層型データベース ②リレーショナルデータベース ③オブジェクト指向データベース ④XMLデータベース ⑤NoSQLデータベース 主なデータベースの種類
10. (C) Recruit Co.,Ltd. All rights reserved. 10 • 階層型データベースは、データを階層的な構造で管理する。こ の種類のデータベースは、データ要素が親⼦関係を持つツリー 構造で表される • 各要素は⼀つの親要素を持ち、複数の⼦要素を持つことができ る • 階層型データベースは、その構造が直感的であるため、特定の アプリケーション、特にファイルシステムの管理に適している が、現代の多くの⽤途には柔軟性に⽋けるとされている ①階層型データベース
11. (C) Recruit Co.,Ltd. All rights reserved. 11 • リレーショナルデータベースは、表（テーブル）を使⽤して データを格納する。テーブルは⾏（レコード）と列（属性）で 構成され、SQL（Structured Query Language）という特定 の⾔語を使⽤してデータを管理する。 • リレーショナルデータベースは汎⽤性が⾼く、整合性と耐久性 を保証するための厳格な制約が特徴 • Oracle、MySQL、PostgreSQLなどが有名 ②リレーショナルデータベース
12. (C) Recruit Co.,Ltd. All rights reserved. 12 • オブジェクト指向データベースは、オブジェクト指向プログラ ミング⾔語の概念を利⽤してデータを管理するデータベースで、 これにより、データをオブジェクトとして保存し、クラス、継 承、多様性などのオブジェクト指向の機能を直接データベース 管理システム内で使⽤することができる • このタイプのデータベースは、複雑なデータ構造を持つアプリ ケーションに適している • 主な製品にはObjectDBやdb4o、 GemStone/S等がある ③オブジェクト指向データベース
13. (C) Recruit Co.,Ltd. All rights reserved. 13 • XMLデータベースは、XML形式でデータを格納するために設計 されていることで、階層的なデータとしてのXMLの強みを⽣か し、柔軟なデータモデリングと⾃⼰記述的なデータ形式が可能 になる • XMLデータベースは、Webサービスやインターネットベースの アプリケーションでの使⽤が理想的 • 主な製品にBaseXや、eXist-db、Berkeley DB XML等がある ④XMLデータベース
14. (C) Recruit Co.,Ltd. All rights reserved. 14 • NoSQLデータベースは、リレーショナルデータベースのスキー マレスな代替品として登場した。 • スキーマが固定されていないため、柔軟なデータ構造を扱うこ とができ、⼤規模なデータセットの⾼速処理に適している。 • 主なタイプにはドキュメント型（MongoDBなど）、キーバ リューストア（Redisなど）、列指向データベース （Cassandra、Google BigQueryなど）、グラフデータベー ス（Neo4jなど）があります。 ⑤NoSQLデータベース
15. (C) Recruit Co.,Ltd. All rights reserved. 15 本講義ではリレーショナルデータベース を前提に設計を解説
16. (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）
17. (C) Recruit Co.,Ltd. All rights reserved. 17 ⽤語の確認
18. (C) Recruit Co.,Ltd. All rights reserved. 18 インスタンス データベースは階層構造になっており、最上位に位置 する概念がインスタンス インスタンスはDBMSが動く際の単位で、OSからは 「プロセス」として⾒える 例： Oracleのインスタンス（プロセス） 引用元：https://encrypted- tbn0.gstatic.com/images?q=tbn:ANd9GcS9vWMSi_YkHICZGC0KMM76PJYDLKG9iaBm0g&s
19. (C) Recruit Co.,Ltd. All rights reserved. 19 スキーマ データベースはインスタンスを最上位に階層（通常4 層構造）に分かれており、そのフォルダ（ディレクト リ）に該当するのがスキーマ リレーショナルデータベースの階層構造 インスタンス データベース1 データベース2 スキーマI スキーマII スキーマIII テーブルA テーブルB テーブルC テーブルD テーブルE テーブルE
20. (C) Recruit Co.,Ltd. All rights reserved. 20 注︓MySQLのスキーマ MySQLはデータベースとスキーマを「同⼀」とみな しており（3層構造）、MySQLにおいてはデータ ベースとスキーマは同義語である MySQLの階層構造 インスタンス スキーマI スキーマII スキーマIII テーブルA テーブルB テーブルC テーブルD テーブルE テーブルE
21. (C) Recruit Co.,Ltd. All rights reserved. 21 注︓Oracleのスキーマ Oracleではデータベースとスキーマは別（4層構 造）であるが、1つのインスタンスの配下に1つしか データベースを作れないため、実質3層構造 Oracleの階層構造 インスタンス データベース スキーマI スキーマII スキーマIII テーブルA テーブルB テーブルC テーブルD テーブルE テーブルE
22. (C) Recruit Co.,Ltd. All rights reserved. 22 テーブル テーブルは、データを管理・保存するための⼊れ物 ⾏と列で構成され、データはレコードとして記録される 列A 列B 列C 列D 列E 行 列 レコード テーブルのイメージ
23. (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
24. (C) Recruit Co.,Ltd. All rights reserved. 24 インデックス インデックスはテーブル内の⼤量のデータの中から必要 な情報を素早く⾒つけ出すための道しるべのようなもの インデックスの仕組み 本の索引が特定の主題やキーワードがどのページにある のかを明⽰することで、情報を迅速に検索できるように しているように、 データベースのインデックスもテー ブル内の特定の列（フィールド）に対して作成され、そ の列に格納されているデータの検索を⾼速化する
25. (C) Recruit Co.,Ltd. All rights reserved. 25 SQLとは SQLはデータベースがデータ操作のために備えてい る⾔語で⼤きく3つに分類される • DDL︓データ定義⾔語 • DML︓データ操作⾔語 • DCL︓データ制御⾔語 なお、データベース製品には多くの種類があるが、 SQLはISO（国際標準化機構）で標準化されている ため、SQLを覚えれば多くのデータベースで扱える
26. (C) Recruit Co.,Ltd. All rights reserved. 26 DDL DDL（Data Definition Language）はデータ定 義⾔語と呼ばれ、テーブルや索引、シーケンスなど のデータベースオブジェクトを定義する⾔語 データベースやテーブルを新規に作成（CREATE） する場合や、変更（ALTER）、削除（DROP）する 際に使⽤する また、テーブルに格納されているデータを⼀括です べて削除するTRUNCATEも、DDLに含まれる
27. (C) Recruit Co.,Ltd. All rights reserved. 27 DML DML（Data Manipulation Language）はデー タ操作⾔語と呼ばれ、データベースを操作し、格納 されているデータの検索や削除などを⾏うための⾔ 語 データベースを使⽤する中で最も使⽤する⾔語と⾔ えます。命令⽂は、データの検索（SELECT）、更 新（UPDATE）、挿⼊（INSERT）、削除 （DELETE）がある
28. (C) Recruit Co.,Ltd. All rights reserved. 28 DCL DCL（Data Control Language）はデータ制御⾔ 語と呼ばれ、データやトランザクションを制御する ための⾔語です。ユーザーに対してアクセス権限を 付与（GRANT）する命令や、権限の取消 （REVOKE）が含まれる なお、データベース製品によっては、COMMITや ROLLBACKなどトランザクションを制御する⾔語 （TCL）も、DCLに含める場合がある
29. (C) Recruit Co.,Ltd. All rights reserved. 29 クエリ クエリとは、SQLを実⾏した際にデータベースへ送るための 命令⽂のこと SQLとクエリの違い（混同されやすい） • SQL︓データベースを操作するための⾔語 • クエリ︓SQLを実⾏したときにデータベースに送る命令⽂
30. (C) Recruit Co.,Ltd. All rights reserved. 30 サブクエリ（副問い合わせ） サブクエリ（副問い合わせ）とは、クエリの中で使⽤される別の クエリのことを指す サブクエリを使⽤すると、複雑な条件を持つクエリを簡潔に表現 でき、データの抽出や加⼯をより柔軟に⾏うことができる SELECT 商品ID, 商品名 --主問い合わせ FROM 商品リスト WHERE EXISTS ( SELECT * --このSELECT⽂が副問い合わせ FROM 売上表 WHERE 売上表.商品ID = 商品リスト.商品ID ) サブクエリの例
31. (C) Recruit Co.,Ltd. All rights reserved. 31 トランザクション SELECTおよび更新系の INSERT/DELETE/UPDATE等の複数のSQL クエリを⼀貫性のある形でひとまとまりにして 扱い、実⾏する仕組み
32. (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 例：サブクエリをビューに置き換え
33. (C) Recruit Co.,Ltd. All rights reserved. 33 データベース設計の前に必要なこと
34. (C) Recruit Co.,Ltd. All rights reserved. 34 「要求」と「要件」の明確化 設計の前に「要件」と「要求」の明確化が重要 ビジネス要求 ビジネス要件 業務要求 業務要件 システム要求 システム要件 ※赤俊哉著『要件定義のセオリー』に掲載の図を元に作成
35. (C) Recruit Co.,Ltd. All rights reserved. 35 要件と要求の違い 「要求」＝ 本当に欲しいもの ＝ ユーザが情報シス テムで実現したいこと 「要件」＝ 本当に要るもの ＝ 要求に基づきつつ、 制約を踏まえて、情報システムに盛り込むべきもの
36. (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
37. (C) Recruit Co.,Ltd. All rights reserved. 37 ウォーターフォール開発とアジャイル開発におけ る要求の取り扱いの違い ウォーターフォール（WF）開発とアジャイル（Agile） 開発はソフトウェア開発のアプローチにおいて⼤きく異 なる哲学とプロセスを持っており、特に、要求定義の取 り扱い⽅において顕著な違いがある
38. (C) Recruit Co.,Ltd. All rights reserved. 38 ウォーターフォール開発における要求 詳細な要求定義 プロジェクト開始前に全ての要求を収集・分析・⽂書化する。 この段階で定義された要求はプロジェクト全体を通じて基本的 に変更されることはない 計画の重視: 全てのプロジェクト活動は事前に計画され、スケジュールに 従って厳格に管理される 引用元：https://www.ogis- ri.co.jp/otc/hiroba/technical/IntroASDooSquar e/chapter4/image/WaterfallLifecycle.jpg
39. (C) Recruit Co.,Ltd. All rights reserved. 39 アジャイル開発における要求 引用元：https://www.ogis- ri.co.jp/otc/hiroba/technical/IntroASDooSquare/chapter4/image/Iterati onOfXPwithAM.jpg 進化する要求 要求はプロジェクトの進⾏とともに進化し続けると考えられ、 初期段階で完全には固定されない。フィードバックを基に要求 が追加、変更、削除されることがある 反復的・漸進的開発 短い開発サイクルを繰り返し、各イテレーションでユーザーか らのフィードバックを取り⼊れながら製品を改善していく
40. (C) Recruit Co.,Ltd. All rights reserved. 40 補⾜︓アジャイル開発における要件定義 アジャイル開発では繰り返しの前に、要件定義で⼤ 枠をしっかり掴み、設計から実装⼯程でなるべくブ レを⽣じさせないことが⼤切
41. (C) Recruit Co.,Ltd. All rights reserved. 41 データベース設計
42. (C) Recruit Co.,Ltd. All rights reserved. 42 データベース設計とは データベース設計とは、データベースによっ てデータを管理できるように、現実の世界を 抽象化してデータモデルを作成していく作業 （データモデリング）
43. (C) Recruit Co.,Ltd. All rights reserved. 43 データモデルは⼤まかにエンティティと属性、リレーションシップで構成される データモデルの構成要素
44. (C) Recruit Co.,Ltd. All rights reserved. 44 データモデル システムまたは組織のデータの構造、関係性、および制約を記述す る表現でデータ型、エンティティ、属性、およびそれらの関係（リ レーション）を定義する エンティティ データモデルの構成要素のひとつで組織全体もしくはシステム開発 における「静的な管理対象（取引先・商品などのデータの集ま り）」を指し、「実体」と訳される データモデルとエンティティ
45. (C) Recruit Co.,Ltd. All rights reserved. 45 エンティティは以下の「5W1H」を表す名詞 • 誰が（Who）︓⼈、組織、取引先、顧客など • 何を（What）︓製品、商品、原材料、サービスなど • いつ（When）︓年⽉（⽇）、季節、催事、会計年度など • どこで（Where）︓国や地域、住所、店舗、陳列棚など • なぜ（Why）︓業務ルール、法律、慣⾏、問い合わせ、クレー ムなど エンティティが表す概念
46. (C) Recruit Co.,Ltd. All rights reserved. 46 エンティティはリソース系orイベント系および従属or独⽴のそれ ぞれの軸で分けられる エンティティの種類 独立 従属 リソース系 イベント系
47. (C) Recruit Co.,Ltd. All rights reserved. 47 リソース系エンティティ データベースの設計・実装時に「マスタ」となりうるエンティティ でビジネスおよび業務におけるあり⽅を⽰し、資源となりうるもの を指す 例えば「取引先」「顧客」「商品」「サービス」等 イベント系エンティティ データベースの設計・実装時に「トランザクション」となりうるエ ンティティでビジネスおよび業務の⾏為により発⽣するものを指す 例えば「受注」「発注」などの出来事 リソース系エンティティ/イベント系エンティティ
48. (C) Recruit Co.,Ltd. All rights reserved. 48 独⽴エンティティ 例えば「顧客」や「商品」など、他のエンティティに依存すること なく存在するエンティティ 従属エンティティ 他のエンティティに依存して存在する「受注明細」（「受注」がな いと成⽴しない）のようなエンティティ 独⽴エンティティと従属エンティティ
49. (C) Recruit Co.,Ltd. All rights reserved. 49 リレーションシップは、エンティティ（実体）同⼠のつながり（関 係）を意味するが、⼤きく分けて以下の3つに分類される リレーションシップの種類 リレーションシップの種類 ①依存型 ➁⾮依存型 ③汎化型
50. (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
51. (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
52. (C) Recruit Co.,Ltd. All rights reserved. 52 親と⼦のエンティティが汎化関係にある場合のリレーションシップを汎化型と呼ぶ その場合、親エンティティを「スーパータイプ」、⼦エンティティを「サブタイ プ」と呼ぶ ③汎化型リレーションシップ 引用元：https://image.itmedia.co.jp/ait/articles/1703/01/r20_06-01.PNG
53. (C) Recruit Co.,Ltd. All rights reserved. 53 「サブジェクトエリア」とはデータモデル全体をいくつかに区切った場合の、 個々の領域（範囲）のこと 例えば業務単位で区切る場合は販売・購買・在庫管理等に分け、事業単位で管理 する場合は、外⾷・物販・不動産等に分ける サブジェクトエリア（サブジェクトスコープ） 引用元：https://assets.st-note.com/img/1700395732347-IkB5MlsNmQ.jpg?width=800
54. (C) Recruit Co.,Ltd. All rights reserved. 54 データモデリングの概要
55. (C) Recruit Co.,Ltd. All rights reserved. 55 データモデリングの各⼯程 データモデルを作成していく作業（データモデリング）は、⼀ 般的に概念設計、論理設計、物理設計という3つの段階を通し て⾏われ、それぞれの段階ではアウトプットとして概念モデル、 論理モデル、物理モデルが作成される 引用元：https://gihyo.jp/dev/feature/01/database/0001
56. (C) Recruit Co.,Ltd. All rights reserved. 56 概念設計 システムに必要なデータの全体像（概念デー タモデル）を定義することによって、データ に関する要求を明確にする作業 概念データモデルはビジネス（業務）の観点 で必要な情報の体系をデータモデルとして表 現したもの
57. (C) Recruit Co.,Ltd. All rights reserved. 57 論理設計 特定のデータベースに依存しないデータモデ ル（論理データモデル）を作る 論理データモデルでは、業務における意味を 反映した⽇本語での項⽬名や項⽬に関する説 明などを定義することで、業務においてどの ようなデータが必要なのかを詳細に定義する
58. (C) Recruit Co.,Ltd. All rights reserved. 58 物理設計 特定のデータベース（Oracle, DB2, SQL, Server…）を前提とした物理的なデータ仕 様を定義した物理データモデルを作る 物理データモデルでは、具体的にはテーブル、 属性、キー制約、別名、インデックス、 ビューといった実際のデータベース構築に必 要な詳細情報を定義する
59. (C) Recruit Co.,Ltd. All rights reserved. 59 各⼯程での主な成果物 概念設計︓コンセプトモデル図(UML) 論理設計︓ER図、エンティティ状態遷移図 、エンティティ定義書等 物理設計︓ER図、テーブル定義書ライフサ イクル定義書、キー項⽬体系定義書、DDL 等
60. (C) Recruit Co.,Ltd. All rights reserved. 60 データモデルパターン データモデルパターンは、システム設計にお けるデザインパターンと同様に業種や業務の 違いに左右されない汎⽤なデータモデル ※代表的なパターンとして、⼈や組織を表す「パー ティパターン」や受注/発注を表す「取引パター ン」等がある
61. (C) Recruit Co.,Ltd. All rights reserved. 61 データモデルパターン例 例）パーティパターン 引用元：https://www.biprogy.com/pdf/tec_info/11102.pdf
62. (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
63. (C) Recruit Co.,Ltd. All rights reserved. 63 データモデリングのアプローチ⽅法 システム開発は「トップダウンで⾻組み、ボ トムアップで⾁付け」が基本で、DB設計に に関しても同様の考えでモデリングする
64. (C) Recruit Co.,Ltd. All rights reserved. 64 トップダウンアプローチ トップダウンアプローチとは、ビジネス要件 →業務要件→システム要件とブレイクダウン してきた要件を基に、「本来あるべきデータ モデル」を作成する⼿法で、主にリソース系 エンティティの抽出と定義で⾏われる
65. (C) Recruit Co.,Ltd. All rights reserved. 65 ボトムアップアプローチ ボトムアップモデリングとは業務フロー等により捕 獲した発⽣データを基に、主にイベント系エンティ ティの抽出と定義の際に⾏われる その他、ボトムアップアプローチでは、UIプロトタ イプや画⾯遷移等から項⽬（リソース系・イベント 系ともに）の洗い出しと定義を⾏いつつ、正規化を 実施して、「現実に即したデータモデル」を作成す る
66. (C) Recruit Co.,Ltd. All rights reserved. 66 データモデリングでは、属性を統⼀したグループを”ドメイン”と呼ぶ ⼀⽅で『実践オブジェクト指向設計』で扱うドメイン駆動設計における”ドメイ ン”は「システムが対象とする事業が取り扱う世界」を表し、全く別のものを指 すので混同しないように注意 注︓データモデリングにおける”ドメイン”
67. (C) Recruit Co.,Ltd. All rights reserved. 67 概念データモデリング
68. (C) Recruit Co.,Ltd. All rights reserved. 68 概念データモデルとは 概念（コンセプト）データモデルとは、「顧客にとって 興味のあるデータモデル」のことで、全体の静的ビジネ ス要求を把握するために作成する ※概念データモデルを作る過程では、様々なビジネスルールが明らか になってくる 引用元：https://www.ulsystems.co.jp/archives/assets/topics_modeling_002_23.gif
69. (C) Recruit Co.,Ltd. All rights reserved. 69 概念データモデルを省くケース 特にコンシューマ向けシステムで、この⼯程 を実施しないケースも多く、また「論理デー タモデル」をほぼ「概念データモデル」とし て位置付けている意⾒やそれに準拠した⼿法 もある
70. (C) Recruit Co.,Ltd. All rights reserved. 70 論理データモデリング
71. (C) Recruit Co.,Ltd. All rights reserved. 71 論理データモデルとは 論理データモデルは、概念データモデルにて登録したエンティ ティに対し、属性を定義していくことにより作成する。また、 属性定義とともに、「正規化」と具体的なデータやその関係性 等の「抽象化」を⾏うことにより、データ構造を確定していく 引用元：https://www.ulsystems.co.jp/archives/assets/topics_modeling_002_05.gif
72. (C) Recruit Co.,Ltd. All rights reserved. 72 論理モデル設計フェーズで⾏うこと • 属性の定義 • 属性名の命名ルールの標準化と明確化 • ドメインの定義 • 正規化の実施 • 主キーと外部キーの設定 • サブジェクトエリアの確定 ..etc
73. (C) Recruit Co.,Ltd. All rights reserved. 73 正規化とパフォーマンスについて 正規化とは冗⻑さを省く反⾯、テーブル結合時のコ スト等がかかるため、パフォーマンス要件の厳しい システムではレスポンスのボトルネックの原因にな りやすいので実装時には注意 またその際、部分最適・局所的にパフォーマンス チューニングしようとすると設計・実装が複雑化す ることもあるため、アプリケーションにおいてDB 設計は⾮常に重要といえる
74. (C) Recruit Co.,Ltd. All rights reserved. 74 物理データモデリング
75. (C) Recruit Co.,Ltd. All rights reserved. 75 物理データモデルとは 物理データモデルは、論理データモデルを基にして、以 下の事項について取捨選択を⾏い、対策を講じる形で作 成する • 技術上の制約 • アプリケーションの⽤途 • パフォーマンス（性能に関する要求） 引用元：https://www.ogis-ri.co.jp/otc/swec/process/am-res/am/images/models/physicalDataModel.jpg
76. (C) Recruit Co.,Ltd. All rights reserved. 76 物理モデル設計フェーズで⾏うこと 主に以下のような作業を⾏なうことで、「開発者が読むための 論理モデル」から「実際にDBMS上に実装するための物理モデ ル」へデータモデルを精査していく 1. テーブル名／項⽬名に物理名（英語名）を定義 2. 属性のデータ型／桁数／精度を定義 3. ⼀意制約やNOT NULL等の各種ルールを定義 4. パフォーマンス等を考慮し「正規化崩し」を実施 5. インデックスやトリガーの定義 ..etc
77. (C) Recruit Co.,Ltd. All rights reserved. 77 物理データモデル作成後は、以下を考慮しながら、DB の実装環境を構築していく • キャパシティプランニング • パーティショニング • 性能要件（パフォーマンス） • 排他制御 • データセキュリティ • トランザクションの単位..etc 物理設計後の考慮事項
78. (C) Recruit Co.,Ltd. All rights reserved. 78 データベースの変更容易性について
79. (C) Recruit Co.,Ltd. All rights reserved. 79 データベースのリファクタリング DBのスキーマ（構造）は、アプリケーションと密接に結びつ いているため、以下のようなDBのリファクタリングは⼤変 • クエリの書き換え • テーブル名や属性名の変更 • 外部キーやその他制約の変更 • ビューの修正 • ストアドプロシージャの修正 テーブルの定義を変更することによって、そのテーブルへアク セスする処理すべてに影響範囲が広がります。そのため、⼀度 DBに⼿を⼊れると実にさまざまな調整が必要になる
80. (C) Recruit Co.,Ltd. All rights reserved. 80 つまり、データベースは変更に弱い
81. (C) Recruit Co.,Ltd. All rights reserved. 81 DB設計における拡張性の考慮 拡張性の考慮とは、「将来発⽣しうる変化」を予測し、 その変化が起こったときにもシステムの改修量を最低限 に抑えられるようなモデルを検討すること。⾔い換える と、現状の概念モデルにおいて「現実に起こりうる業務 上の変化」に耐えられないところを発⾒し、そのモデル を「変更に強いモデル」に精査していくこと 引用元：https://www.ulsystems.co.jp/archives/assets/topics_modeling_002_21.gif
82. (C) Recruit Co.,Ltd. All rights reserved. 82 データベースの変更の難しさを踏まえた データモデリングのポイント • 「構築するシステムのデータベース設 計」よりも広い視野に⽴ち「将来も⾒据 えた最適なデータモデルを検討する」こ と • 既存のデータやテーブル構造に直接的な 影響を与える変更より漸進的に追加・拡 張していく形が望ましい
83. (C) Recruit Co.,Ltd. All rights reserved. 83 オブジェクト指向とデータベース
84. (C) Recruit Co.,Ltd. All rights reserved. 84 ソフトウェア開発においてオブジェクト指向プログラミング（OOP）とデータ ベースの連携や相互作⽤において両者のパラダイムの違いにより、しばしばミス マッチ（インピーダンスミスマッチ）が起こる。例えば以下の違い オブジェクト指向プログラミング オブジェクトがメモリ内でどこに存在するかは透過的で、参照を通じて⾃由に他 のオブジェクトへ直接アクセスできるため、オブジェクト間の関係性も柔軟に組 み替えたり、構築することが可能 データベース DBのデータは固定されたテーブルの列定義に従って格納され、主キーによって 各レコードの位置が定義されるため、特定のデータへのアクセスはSQLクエリを 通じて、特定のパス（クエリ）を定義してその結果を得る必要がある オブジェクト指向とデータベースの連携
85. (C) Recruit Co.,Ltd. All rights reserved. 85 要するにオブジェクト指向のオブジェクトは他のオブ ジェクトを直接参照することによって⾃由にオブジェ クト同⼠の関係性を表現できるが、データベースでは 特定のレコードへは「固定されたルート」でしかアク セスできない このような違いは両者の連携の際にギャップを⽣むこ とになる
86. (C) Recruit Co.,Ltd. All rights reserved. 86 例えば注⽂と商品が多対多で表現する際に、概念上は、注⽂と商品は簡単に結び つけられるが、テーブル構造でで表現する際は、直接結びつけられず、両者の組 み合わせを格納するための中間テーブルが必要になる インピーダンスミスマッチの例（中間テーブル） 論理データモデル
87. (C) Recruit Co.,Ltd. All rights reserved. 87 ⼤規模システムにおけるデータベース
88. (C) Recruit Co.,Ltd. All rights reserved. 88 ⼤規模システムでは、単⼀のDBでの運⽤するケースは少なく、負 荷分散をしながら複数のDBでサービスを運⽤している（スケール アウト） スケールアウトの⼿法として、主にレプリケーションやシャーディ ング（⽔平分割）の⽅法を採ることが多い なお、⼆つを掛け合わせるケースもある データベースのスケールアウト
89. (C) Recruit Co.,Ltd. All rights reserved. 89 主に読み出し（Read）⽤のDBをレプリカとして増やして負荷分散する⽅法 メリット︓運⽤が⽐較的楽、障害時のバックアップとしても使える デメリット︓マスタが単⼀の場合、書き込みに負荷がかかる レプリケーション 引用元：https://insights-jp.arcserve.com/wp-content/uploads/2022/08/ijZ7t8YUnRyXgL4Mpz2mVsuoC-1659946336.png
90. (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
91. (C) Recruit Co.,Ltd. All rights reserved. 91 DBRE（Database Reliability Engineering）は、データベー スシステムの信頼性、パフォーマンス、効率性を維持するための実 践であり、SRE（Site Reliability Engineering）の概念をデー タベース管理に適⽤したもので、DBREにおいては、データベース の設計が⾮常に重要。設計が不適切だと、データの登録や取得が複 雑になったり、それがシステムのレスポンスタイムに悪影響を及ぼ し、最終的にはアプリケーション全体のパフォーマンスが低下する 等、影響が⼤きい DBREとデータベース設計
92. (C) Recruit Co.,Ltd. All rights reserved. 92 データベースのアーキテクチャ
93. (C) Recruit Co.,Ltd. All rights reserved. 93 データベースの構造（3層スキーマ） 現代の多くのデータベースシステムではデータベー スの構造を以下の3つの層に分けて定義する • 外部スキーマ（ビュー層） • 概念スキーマ（論理層） • 内部スキーマ（物理層）
94. (C) Recruit Co.,Ltd. All rights reserved. 94 外部スキーマ（ビュー層） 画⾯のUIや⼊⼒データ等、「ユーザから⾒たデータ ベース」の姿を表すスキーマ 引用元：https://itmanabi.com/wp-content/uploads/2018/12/db-schema.png
95. (C) Recruit Co.,Ltd. All rights reserved. 95 概念スキーマ（論理層） テーブル定義（データの要素やデータ同⼠の関係） を記述するスキーマで「開発者から⾒たデータベー ス」を表す 引用元：https://itmanabi.com/wp-content/uploads/2018/12/db-schema.png
96. (C) Recruit Co.,Ltd. All rights reserved. 96 内部スキーマ（物理層） 概念スキーマで定義された論理データモデルを DBMS内部に格納する具体的な⽅法を定義するス キーマで「DBMSから⾒たデータベース」を表す 引用元：https://itmanabi.com/wp-content/uploads/2018/12/db-schema.png
97. (C) Recruit Co.,Ltd. All rights reserved. 97 概念・論理・物理の各データモデルと3層スキー マアーキテクチャの対応 引用元：https://metafind.jp/wp-content/uploads/2023/02/bbb60a98ec07ab378b142f894d5083ca.png
98. (C) Recruit Co.,Ltd. All rights reserved. 98 概念・論理・物理の各データモデルと3層スキー マアーキテクチャの対応（DMBOK準拠） 外部スキーマ（ビュー層） 概念スキーマ（論理層） →概念データモデル（概念設計） →論理データモデル（論理設計） 内部スキーマ（物理層） →物理データモデル（物理設計）
99. (C) Recruit Co.,Ltd. All rights reserved. 99 データベースが3層に分かれている理由 データベースが3層構造に分かれている理由 の⼀つが、データの独⽴性の保証で、例えば、 アプリケーションの要求（外部スキーマ）が 変わったり、データの物理的な格納⽅法（内 部スキーマ）が変わったりしても、他の層が 影響を受けないようにデザインされている この独⽴性は、システムの拡張性と適応性を 向上させ、継続的な変化に対応しやすくする
100. (C) Recruit Co.,Ltd. All rights reserved. 100 デーベース設計の実践
101. (C) Recruit Co.,Ltd. All rights reserved. 101 課題の確認 【課題内容】 架空の EC サイト(R 書店)を設計・実装してく ださい(※両講座共通の課題)
102. (C) Recruit Co.,Ltd. All rights reserved. 102 サブ資料①：概念データモデリング サブ資料②：論理データモデリング サブ資料③：物理データモデリング 本講義のサブ資料 具体的な設計作業の詳細はサブ資料で解説
103. (C) Recruit Co.,Ltd. All rights reserved. 103 終わりに
104. (C) Recruit Co.,Ltd. All rights reserved. 104 アプリケーションとの連携 データベースとアプリケーションの連携の実態 ※データベースの設計不備をアプリケーション側の設計で吸収することも少なくない
105. (C) Recruit Co.,Ltd. All rights reserved. 105 理想と実物との隔たり ドキュメントベースで想定されるシステムのイメー ジと実物との隔たりは少なくなく、そのため、⽇頃 から⼿を動かしてモノづくりを⾏い、要件定義や設 計の際には実装から逆算してイメージしたり、思考 できるようにしておくことが⼤事 理想 実際の実装 引用元：https://thumb.ac- illust.com/0c/0c40bbe466ee623d574f8642383409f7_t.jpeg
106. (C) Recruit Co.,Ltd. All rights reserved. 106 【結論】 データベースの設計を磨くにはデータ ベース単体ではなく、データベースを含 むアプリケーション全体を設計・実装す る⼒を養うことが⼤事
107. (C) Recruit Co.,Ltd. All rights reserved. 107 副読本について
108. (C) Recruit Co.,Ltd. All rights reserved. 108 データベースの基本的な仕組みや正規化について詳しく 解説されている良書 『達⼈に学ぶDB設計 徹底指南書』 引用元：https://m.media-amazon.com/images/I/91KkYEHTxXL._SL1500_.jpg
109. (C) Recruit Co.,Ltd. All rights reserved. 109 当講義の関連リポジトリ（GHE） 架空のECサイトR書店 ※準備中 rbooks (https://ghe.misosiru.io/takeshi-fujimoto/rbooks) rbooks-ddd (https://ghe.misosiru.io/takeshi-fujimoto/rbooks-ddd)