DB設計に必要な知識と基本的な設計方法を紹介

はじめに

ITシステムを開発する際はWebサーバーやDNS、FTPサーバー等様々なサーバーや機能が必要となりますが、DB(データベース)も同じく必須となる機能(またはサーバー)の一つとなります。すでにエンジニアとして働いている方であればMySQLやOracleという名称を聞いたことのある人も多いのではないでしょうか。これらDBは、例えばECサイトにおける商品名や価格といった商品情報を格納したり、顧客システムにおける名前や電話番号といった顧客情報を格納したり、WordPressのようなCMSにおいて記事データやリンク情報を格納したりと、各種データを整理して格納し、必要な時にアクセスして検索や変更・削除等が行えるシステムです。近年ビッグデータを扱うシステムが増えてきていますが、ビッグデータにおいてもDBが利用されます。

また開発プロジェクトにおいてネットワークエンジニアやサーバーエンジニアという専門のエンジニアがいるように、DBもDBエンジニアがいるほど専門性の高い分野です。今回は、DBを使ったシステムを構築するうえで重要となるDB設計を行う際の基礎知識、一般的な設計手順について紹介していきます。

DB設計を行うに当たって

プログラミングやサーバー構築、ネットワーク設定をする等、ITシステムの開発は、形のないものを頭の中でイメージして完成させていく部分がほとんどですが、DBも同様であり、かつ慣れていないと頭の中で描きづらい要素が多く、設計に当たっては、直接携わっていない部分も含めたシステム全体の把握が必須となる仕組みとなっています。そのため、DB構築に携わる全ての人が把握できるような設計書を作成することは重要な業務となります。

またシステムは後から改修していくことを前提としてリリースするアジャイル開発のような手法を取ったとしても、DBに関しては容易に改修ができないため、システムの仕様を把握したうえで今後改修が発生しない状態を想定して設計・構築を進めていく必要があります。以上のことよりDB設計は非常に重要な過程であることがわかっていただけたことでしょう。それでは設計に必要となる知識について紹介していきます。

なおここで言うDB設計とは、DBサーバーのスペックの見積もりや必要となるソフトウェアを検討するような業務ではなく、データベースの中身をどのような構造とし、どのような情報を格納し、どのようにこれから開発するシステムにアジャストさせていくかということをあらゆる角度から考慮して設計書として落とし込んでいく業務のことを指します。

DB設計に必要な4つの基礎知識

DB設計はデータモデリングとも呼ばれ、要件の洗い出しや分析、取り扱い範囲等を決めていく作業であり、データモデルを作成することとなります。その際に必要となる要素はエンティティ、属性、関係(リレーションシップ)、関連の多重度の4つです。なおデータモデルの3大要素としてエンティティ、属性、関係のみ取り扱われることもありますが、関連の多重度も抑えておくべき内容となるため、今回はこちらも含めて4つとします。

エンティティ

DBで管理する情報(項目)、またDBのテーブルのことをエンティティと呼びます。例えば宿泊システムであれば、名前、住所、電話番号、宿泊履歴等が該当します。必要なエンティティをあらかじめ全て洗い出せているかどうかで、その後の設計・構築がスムーズに進むかが変わってきます。逆に本来不要なエンティティを含めしまって後々混乱が生じないよう注意も必要です。なおほぼ変更が発生しないものをリソースエンティティと呼び、変化が頻繁に発生するものをイベントエンティティと呼びます。

属性(アトリビュート)

一つのエンティティにおいて同時に分かる項目のことを属性と呼びます。例えば商品の情報を取得しようとした際に、その商品の商品名と価格が同時に確認できる場合、商品名や価格は属性ということになります。DBのテーブルにおいてはフィールドに該当する部分が属性です。

関係(リレーションシップ)

関係は、エンティティ同士を関連付けるもので、DBではテーブル同士を繋ぐ共通の項目のことを指します。例えば顧客と商品というエンティティがあった場合、注文するという行為で関連が生まれますが、この「注文する」が関係となります。なお、あるシステムにおけるデータやデータ間の処理を図にしたものをER図と呼びますが、このERはエンティティ(Entity)と関係(Relationship)の頭文字となっています。ER図においてエンティティは四角で、関係は線で表されます。

関連の多重度

関連性のあるエンティティ同士が、1対1であるか、1対多あるいは多対1であるか、多対多であるかを表すものが関連の多重度です。例えば一人の学生が受験した各科目の点数のデータをDBに格納する場合、学生と科目というエンティティは1対多になります。しかしクラス全体のデータを格納する場合は多対多となります。この多重度に変更があると、本来描いていたシステムと全く異なる状態が発生してしまうため、エンティティの抽出漏れに注意が必要なことはもちろん、どういった目的を持って運用するDBなのかという点も把握したうえで多重度を設定していく必要があります。

改めて各多重度の例を挙げておきます。1対1は、一人の社員に対して割り当てられる社員番号という関係をイメージするとわかりやすいことでしょう。1対多/多対1は、商品の購入と客というそれぞれの側面からの見方で表現できます。客は複数の商品を購入できるという見方が1対多、しかし複数の購入に紐づく客は一人になるという見方が多対1になります。多対多は、企業における社員とタスクの関係で表せます。社員は複数のタスクを持っていますが、タスクも複数あり、複数の社員が担当しているといった関係です。

DB設計の3段階

DB設計は一般的に概念設計、論理設計、物理設計の3段階で表されることが多いため、今回はその3分割した段階について紹介します。なおER図にも概念モデル、論理モデル、物理モデルの3つがあり、それぞれ作図されることが多いです。

概念設計

DBに取り入れる必要があるエンティティを洗い出し、エンティティ同士の関係(リレーションシップ)をモデリングする段階です。どのような構成で整理していくかという全体像が分かるように設計していきます。概念設計は要件定義→エンティティの抽出→概念データモデルの作成→ER図の作成という順に進めます。「要件定義」ではどういった機能が必要になるか、DBでどのようなデータを管理し、いつどういった方法でアクセスされるか、また今後の拡張性等を決め、「エンティティの抽出」で必要な要素を一覧表示して洗い出し、「概念データモデルの作成」「ER図」でDBシステムの全体像を、エンティティと関係の組み合わせで作図します。

論理設計

概念設計したものに肉付けをして具体化する段階で、実際にシステムで利用するDBの形式に変換する段階にもなります。肉付けするものは属性、主キー、外部キー、関係、多重度といった要素で、特定のDBに向けに依存するようなデータ型の定義等まではこの段階で行いません。そのため他の段階に比べると、多くの人が理解できるような設計が行われるのが論理設計と言えます。データの正規化を行うのも論理設計で行うこととなります。DBを学ぶ際に必ずと言っていいほど登場する正規化は、エンティティを極力最小単位にしてデータを利用しやすくすることを指します。正規化は多くの場合第一から第三正規化まで行われ、データの整合性が取れていない箇所がないかを確認しながら修正していきます。

物理設計

例えばMySQLやOracleデータベース等、システムで実際に利用するDBに当てはめた設計を行うのが物理設計です。この段階で初めてデータ型の定義やデータテーブルの修正、インデックス(データを識別する項目と、データの格納場所を示すポインタで構成されたもの)の付与したり、稼働時のパフォーマンスを考慮しながらDBの整理や調整を行なったりします。論理設計で行った正規化を、実際の運用に合わせて敢えて崩すこともあります。この整理や調整を実施するためにテストデータをインポートし、これまでの設計で想定していた通りに操作可能かの確認も行います。さらにこの段階では将来を見越したシステムへのアクセス数・転送量等も考慮してDBサーバーのハードウェア、サーバー等の選定や設計が行われることも多いです。

DB設計で必要になること

ここまではDB設計で使われる用語の定義や設計手順について紹介していきましたが、初めてDBに触れると新たに覚えることばかりで、何から手をつけていけば良いのかわからないという状況に陥る可能性があります。そのため最後に今一度DB設計における重要ポイントをまとめて紹介します。

繰り返しになりますが、DB設計は今後改修することを前提として見切り発進せず、可能な限り設計の段階から要件や仕様を詰めて過不足なく、想定外の事態が起こらないようにする必要があります。そのためには、たとえ関わる部分がDBだけであっても開発するシステムの全体の全体像を把握しなければなりません。また物理設計の段階でテストをしながら正規化や調整で実用的なDBに仕上げる工程も重要です。以上より、DB設計にはシステムの全体像と捉える能力、将来を見越した設計ができる能力、物事を整理して論理的にアウトプットできる能力が必要になると言えるでしょう。なおER図の表記方法も早い段階で覚えておいた方が良い知識となることも付け加えておきます。

これらDB設計に重要な能力が自分には欠けているのではと思っている方もDBエンジニアへの道を諦める必要はありません。何度も設計を繰り返していくうちに慣れるという部分もありますが、最近は十分な知識がなくてもDB設計が可能なソフトウェアも出ています。Lucidchart、ERMaster、MySQL Workbenchといったものが有料または無料で利用でき、中には設計・開発の両方を網羅できるソフトもあります。書籍等で勉強している時はわからなかったことも、ソフトを利用していくことで容易に理解できる可能性もあります。もしDB設計・構築の必要に迫られているものの自分の知識やスキルだけでは及ばないという場合は、これらソフトの利用も検討してみてはいかがでしょうか。

まとめ

ITエンジニアのスキルや知識はITの進歩と共に変わっていくため、常に学習する姿勢がないと、あっという間に既存のスキル・知識だけでは太刀打ちできないという状態に陥りやすいと言えます。プログラミング言語一つを取っても、JavaやJavaScript、PHPと長年使われ続ける言語も一部ありますが、5年、10年前に主流であった言語が下火になっていることも珍しくありません。そういった中で、今回紹介した設計含めDBの仕組みが大きく更新されることはないため、一度習得してしまえば長くDBエンジニアとして活躍できる可能性が高く、様々な分野のシステム開発で汎用的に利用できるスキルとなります。

実際に15年以上前の2005年に、DB設計は陳腐化しないという内容の記事があり、その中で紹介されていたDBの知識や設計方法は現在とほぼ同様の内容となっていました。それでもビッグデータに適したデータベースとしてNoSQL(Not Only SQL)が使われる傾向にある等、新たな要素は出てきているので、最新技術の情報にアンテナを張っておく必要はあります。まずは今回の記事をきっかけにDB設計を習得して、DBエンジニアとして長くIT業界で活躍してみてはいかがでしょうか。