🎉

学習備忘録〜「達人に学ぶDB設計徹底指南書」第1章〜

2024/02/21に公開

はじめに

この備忘録は、新卒1年目の初学者バックエンドエンジニアの学習記録のためにつけているものです。
解釈違いや、誤情報がある可能性があります。見つけた際にはご指摘をお願いします。
今回は、開発をしていく中で全く知識をインプットできていないと感じたDB周りについての学習を進めていきます。

第1章〜データベースを制する者はシステムを制す〜

ポイント

私たちの生活は、意識していなくてもさまざまなデータベースに囲まれて成り立っている
データベースにはデータを保持する形式によって多くの種類がある。今回取り上げるのはRDBとその設計技法
「データベース」と「DBMS」は異なる。「データベース」はデータの集積を指す論理的概念であるのに対して、「DBMS」は「データベース「を実装したソフトウェアのこと
データベース設計を制する者はシステム開発を制す。それはシステムがデータのフォーマットに合わせて作られるから（システムに合わせてデータを作るのではない）
データベース設計を考える際には、データベースを外部スキーマ、概念スキーマ、内部スキーマの3層に分けて考える

システムとデータベース

今日の我々の生活は、システム時っ絵も切り離せないほど密接に結びついている。
一口に「システム」と言っても、そこには多面的な捉え方がある。

データ処理としてのシステム

世の中にあるシステムは、稼働するハードウェアもソフトウェアも異なっていながら、全てのシステムが「データ」を扱っているという共通点を持っている。
「データ」を整合的に保持して、いつでも簡単に利用可能な状態にしておくためのシステムが、「データベース」である。「データベース」とは「データの集まり」を指す言葉で、そのデータベースを管理するためのシステムを「DBMS」という。

今日のシステムの中で、データベースを持っていないシステムは存在しない。サービスという全体的な観点から見れば、そこには必ずデータベースが存在する。ただし、データベースは通常、個人情報等重要なデータを多く含んでいるため、利用者に見えるようにはなっていない。注意深く隠されている。そのため、私たちがシステムを利用する際に、データベースを意識することがないだけ。

データベースあれこれ

代表的なモデル

RDB（リレーショナルデーターベース）

関係データベースとも呼ばれ、現在最も広く使われているデータベースモデル。
特徴は、データを人間が理解しやすい二次元表の形式で管理するため、データの取り扱いが他のデータベースに比べると直感的で簡単。

オブジェクト指向データベース

プログラミング言語の中の思想の、オブジェクト指向と同じ考え方。
データと操作をまとめて「オブジェクト」という単位で管理するためにそう呼ばれる。このhirose武ジェクトをデータベースに保存するために作られたのが、オブジェクト指向データベース。

XMLデータベース

きんんはやkん、Web上でやり取りされるデータの形式にXMLが普及している。このXML形式のデータを扱うことのできるデータベースとしてカイアcategoryつされたのが、さきのデータベース。リレーショナルデータベースが苦手とする階層構造のデータの扱いを得意とする。

キーバリュー型ストア

データをKey（識別キー）とValue（値）の組み合わせただけの単純なデータ型で表現するデータベース。単純なデータ問い合わせを高速化することを目的としており、大量データを高速に処理する必要のあるWebサービスで多く利用される。その反面、複雑なデータ操作等は苦手。

階層型データベース

データを階層構造で表現するデータベース。リレーショナルデータベースより一世代前の主流データベースだったが、現在はRDBの普及に伴い、あまり一般的には使用されなくなった。

データベースのモデルが異なれば、データフォーマットも異なる。モデルが異なれば設計技法も異なる

DBMSの違いは設計に影響するか？

主なDBMS

Oracle Database
SQL Server
DB2
PostgreSQL
MySQL

DBMSの違いと設計技法の関係

データベースのモデルが異なる場合、その設計技法も異なる。一方で、DBMSの違いは設計技法に影響を与えない。
データベースの設計技法は、モデルに影響を受けるば、DBMSは、そのモデルを具体的に表現したものにすぎない。そのため、DBMSの違いによらず適用可能である。

リレーショナルデータベースを管理するシステムは「RDBMS」と呼ぶ。

DBMSが異なっても、設計の方法は基本的に影響を受けない

システム開発の工程と設計

今まで、「設計」と大雑把な括りで読んでいた作業が、システム開発全体においてどのような位置を占めているのか。

システム開発の設計工程

開発は、いくつかのステップに分解することができる。

要件定義
設計
開発（実装）
テスト

1.要件定義
システムが満たすべき機能やサービスの水準、要件を決める工程。通常は何らかの形で外部の顧客と要件を合意するが、パッケージソフトやWebサービスの場合は、自社内のみで要件を定義することもある。
２.設計
定義された要件を満たすために必要なシステムを作るための設計を行う工程。建築で言えば、実際に作る前に図面を引く作業に相当する。
3.開発（実装）
設計書に従ってシステムを実際に作る工程。
この工程は、一般的にはプログラマによるコーディングを指すことが多いが、それ以外にもサーバやネットワーク機器、ストレージといったハードウェアの調達や環境の物理的構築といった作業も含まれる。
4.テスト
実装によって組み上がったシステムが、本当に実用に耐える品質であるかを試験する工程。目的に応じてテストの種類とレベルにも何種類かあるが、大きくは機能的な品質に対するテストと、性能や信頼性といった非機能品質に対するテストの２種類がある。

設計工程と開発モデル

システム開発の進め方（開発モデル）には大きく分けて２種類の方法がある。ウォーターフォールモデルと、プロトタイピングモデル。
また、最近は開発スピードの最大化を図るアジャイルソフトウェア開発も存在する。

設計工程とデータベース

データベース設計が重要な理由

システム開発において大半のデータはデータベース内に保持される。そのため、普通、データ設計とはデータベース設計とほぼ同義である。
データ設計がシステムの品質を最も大きく左右する。ソフトウェアというのは、言ってみれば「データの流通機構」であって、どのようなプログラムが必要になるかは、どのようなデータをどういうフォーマットで設計するかに左右される。

DOAとPOA

近年のソフトウェア開発では、データ中心アプローチ（Data Oriented Approach：ODA）という考え方が主流。これは、文字通りシステムを作る際に
、プログラムよりも前にデータの設計から始める方法論。スローガン的に言えば「最後にデータありき」
かつてのシステム開発の主流の考え方は、これと正反対だった。プロセス中心アプローチ（Process Oriented Approach：POA）。「プロセス」は「処理」のことであるので、プログラムと同義だと考える。

システムというのは何よりっプログラムによってるくられているのだから、プログラムから作り始めるというのは、それほどおかしいことではない。むしろ自然のような気がするが。事実、システム開発の素人に、予備知識を何も与え得ないままで開発を行わせると、ほとんどがプログラムから設計を始める。新人研修のチーム開発でも、データ設計から始めるチームはマイノリティ。

POAは非効率的
プロセスは、短期間で大きく変わっていくことが頻繁にあり、プロセス単位でデータ設計を行うことになるため、複数のプロセスで同じデータを個別に持つという冗長性が生じる等、不都合が多い。
DOAは、上記POAの欠点を克服するために登場した。その着眼点はデータがあまり変化しない（永続的）という点である。従って、データの意味や形式が先に決まっていれば、複数のプログラムで共用することも容易で、業務要件の仕様変更にも柔軟に対応できるというメリットがある。

こうした理由から、システム開発においては、プログラム設計に先立ってまずデータ設計が優先される。

最初にデータがある。プログラムはその次にできる

データ設計や、データベース設計は、システムの品質を決める最も重要な要件と言っても過言ではない。このデータ設計において、セオリーを踏み外した設計を行なってしまうと、システムの機能、非機能の品質を致命的に損なうことになる。

データーベースは、システムの中心であるとともに、システム開発の中心である

３層スキーマ

「スキーマ」とは、データベースのデータ構造やフォーマットという意味で使う。データベース設計のステップは、このスキーマのレベルと密接に結びついている。スキーマは一般的に以下の３つに分類される。

外部スキーマ＝ビューの世界
概念スキーマ＝テーブルの世界
内部スキーマ＝ファイルの世界

1.外部スキーマ
システムの利用者であるユーザから見て、データがどのような機能とインタフェースを持っているのかをて意義するスキーマである。
「ユーザから見たデータベース」の姿。このスキーマは、データベースだけでなく、画面のユーザインタフェースや入力データ等、ユーザから見える「システムの姿」の一部であるということもできる。

2.概念スキーマ
データベースに保持するデータの要素および、データ同士の関係を記述するスキーマ。
がオブスキーマがユーザから見たデータベースだとすれば、概念スキーマは「開発者から見たデータベース」である。必然的に、データベース石器絵において重要な位置を占めることになる。概念スキーマの設計を「論理設計」と呼ぶ。データベース設計の中心となるスキーマである。

3.内部スキーマ
概念スキーマで定義された理論データモデルを具体的にどのようにDBMS内部に格納するかを定義するスキーマ。「DBMSから見たデータベース」とも言える。テーブルやインデックスの物理的定義を含む。内部スキーマの設計を、論理設計との対比で「物理設計」と呼ぶ。

概念スキーマとデータ独立性

概念スキーマは何のためにあるの？
外部スキーマは、ユーザにどのようにデータを見せるかという、システムの機能や使い勝手に大レクトに関係する。内部スキーマは、データを実際にDBMS内部に格納するための形式を考える時点で必要。
しかし、その中間の概念スキーマはなぜ必要なのか。
「もし仮に概念スキーマがなかったらどうなる？」
→変更に対する柔軟性がなくなる。概念スキーマは、外部スキーマと内部スキーマの間に位置することで、両者の変更が互いに影響し合わないようにするための緩衝材の役割をになっている。このようなスキーマの独立性のことを、データ独立性と呼ぶ。外部スキーマからの独立性を論理的データ独立性、内部しキーマからの独立性を物理的データ独立性と呼ぶ。

概念スキーマはデータ独立性を保証するためにある
システム開発のガイねにゃ方法論には、一見すると「なぜこれが必要なのか、何の役に立っているのか」と疑問が浮かぶようなものがあるが、実はそうした直感的に必然性の理解できない概念は、長年の試行錯誤によって生まれた工夫であることがしばしば。

概念の有用性がわからなかったら「それがなかったらどうなるか」を考える