DXやデータサイエンスなどの普及により、企業には今まで以上にシステム開発や運用を行う際の適切なデータ管理が求められています。

そのためには、当然ですがただデータベースを導入すればいいわけではありません。システム側の要件定義書や仕様書と照らし合わせ、適切にかつ綿密なデータベース設計を行う必要があります。

ただし、データベース設計に関しては、ある程度手順や考え方が確立されている分野でもあります。今回はデータベース設計について、基本的な手順や考え方、作成する際のポイントなどを現役エンジニアの目線から解説します。

弊社GIGは、ナショナルクライアントからスタートアップまで、Webコンサルティング、UI/UXデザイン、システム開発など、DX支援をおこなうデジタルコンサルティング企業です。データベース設計やWeb制作、DX支援のご相談はいつでもご連絡ください。
■実績紹介
■お問い合わせはこちら

データベース設計とは

まず、前提となる「データベース」とは、大量のデータを保管・管理するだけでなく、ユーザーが参照しやすいように整理されたデータの集まりのことです。

たとえば「顧客情報を整理したもの」などが代表的なデータベースですが、じつは私たちがよく目にする「アドレス・電話帳」「住所録」なども広い意味ではデータベースといえます。

こういったデータをデジタルで効率よく保管・管理するためには、データベース管理システムなどが必要です。代表的なデータベースには、アメリカのオラクル社が製造する『Oracle Database』や、『MySQL』といったものが挙げられます。

しかし、こうしたシステムを導入するだけで、効率的なデータ運用ができるわけではありません。データベースをうまく活用してデータ管理を行うためには、現実世界の情報を抽象化し、どのような情報をどういった構造でデータベース化するのかを細かく設計することが求められます。

この一連の流れを「データベース設計」とIT業界では定義しています。

適切にデータベース設計を行うことで、最新かつ正確な情報へ瞬時にアクセスすることが可能となり、社内のデータ活用を促進できます。社員一人ひとりが情報を探す時間も短縮できるなど、業務の効率化やDX促進にも効果が大きいです。

つまり、データベース設計の質は、業務効率化に多大な影響をおよぼします。

データベース設計のプロセス

データベース設計には「概念設計」「論理設計」「物理設計」といった3段階のプロセスが存在します。まずはそれらのプロセスについて確認します。

プロセス1. 概念設計

概念設計とは、データベースで管理すべき情報を洗い出し、どのような構成でデータを管理するのかを決める作業のことを指します。システム開発における要件定義と並行して行われるケースもあります。

概念設計では、おもに概念データモデルを作成することになります。概念データモデルとは、対象世界（エンティティ）の情報構造を抽象化して表現したものです。とはいえ、これでは分かりにくいので、もっと簡単に言うと「データを見える化したもの」のようなイメージをもっていただけたら良いでしょう。

データベースを構築するにあたり、どんな情報をどのようなカタチで管理するのかは非常に重要です。

概念データモデルでは、データベースの種類や製品（オラクルやMySQLなど）に関係なく、フラットなカタチでデータの世界を表現することが大きな特徴だともいえます。

プロセス2. 論理設計

論理設計とは、概念データモデルをより具体化させたもので、このモデルを実際に作成するデータベースの種類や製品にあわせたカタチに変換する作業のことを指します。

リレーショナルデータベースによってデータを管理するのであれば、概念データモデルからリレーショナルモデルを作成することになります。

リレーショナルデータベース（RDB）：表に似た構造で管理されるデータベース。関連のある属性を列とする表（テーブル）形式でデータを格納する。行単位でデータを操作し、複数のテーブルが関連付けされながら管理されるデータベースともいう。操作は複雑だが、高度なデータ検索・管理が可能

概念データモデルからリレーショナルモデルへの変換は機械的に行うことができますが、そのまま変換しただけでは、リレーショナルモデルとしての適切なカタチにならない場合があります。

そこで論理設計では、適切なカタチに変換する作業として「正規化（一定のルールに基づいて、データを標準化すること）」を行うことになります。正規化を行うことで、データの冗長性や不整合の発生を減らすことにもつながります。

プロセス3. 物理設計

物理設計とは、論理設計でカタチづけたものを実際のデータベースの運用環境に当てはめる作業のことを指します。

データベースの性能や可用性などを考慮しながら、論理設計において正規化したテーブルの定義をあえて崩してみたり、インデックスを定義したりして性能がより向上するように修正していきます。

物理設計によって修正されたモデルは「物理モデル」とも呼ばれ、このモデルをもって実際にデータベースによって管理することができるカタチとなります。

データベース設計の手順

「概念設計」「論理設計」「物理設計」についての理解を深めたところで、次に実際のデータベース設計における手順を解説します。

手順1. 要件定義を行う【概念設計】

システム開発で最初に行うのは要件定義ですが、これはデータベース設計においても同じです。

具体的には、作成しようとしているデータベースで「どのようなデータをどう管理したいのか」を明確にすることからスタートします。これにはデータベースを使用する対象の業務を詳細に分析し、必要な要件を洗い出すことが不可欠でしょう。

システム開発全般にいえることですが、要件定義が不十分だと後で大問題につながることがほとんどです。データベースを設計する場合でも、いったん思い込みなどを排除して十分な打ち合わせを行うよう心がけましょう。

関連記事：リモートワーク時代の要件定義のススメ方

手順2. エンティティを抽出する【概念設計】

エンティティとは、日本語に直訳すると「実体」という意味になります。しかし、「実体」といわれても正直ピンとこない方が大半かと思います。

エンティティといえば「ある目的のためにまとめられたデータのかたまり」で、もっと分かりやすく言えば「データベースにおけるテーブル」というイメージをもっていただけると分かりやすいでしょう。

たとえば、社員マスタ（社員データのまとまり）を作成する場合、「氏名」「性別」「年齢」「役職」「所属部署」などがそれぞれのカテゴリ（テーブル）ごとにまとめられます。このカテゴリをエンティティと考え、データのなかから抽出していきます。

データベースの世界では、エンティティというキーワードはかなり重要です。なんとなくでも構わないので、この機会にイメージだけでもつかんでおきましょう。

手順3. ER図を作成する【概念設計】

業務に必要なエンティティを全て洗い出したら、それをもとにした「概念データモデル」を作成していきます。概念データモデルを作成する手法としてよく用いられるのが「ER図」です。

「ER」とは「エンティティ（Entity）」と「リレーションシップ（Relationship）」をあわせたもので、各エンティティ同士の関係性を示した図となります。

中小規模のシステムであれば、数十個のエンティティでおさまるかもしれませんが、大規模システムだと数百個のエンティティが発生するかもしれません。数百個のエンティティ同士の関係を何の助けもなく理解することは不可能です。

そのため、複雑化したテーブル構成からシステム構造をいち早く理解するには、ER図を作成しておくことが重要です。ER図は作成用のツールも発売されているため、活用してみても良いかもしれません。

ER図は、「エンティティ」「アトリビュート」「リレーション」「カーディナリティ」と呼ばれるオブジェクトで構成されます。

▲IE記法で記されたER図の例（出典：Smart Data Platform）

・エンティティ：データのまとまりのこと。データベースではテーブルとして管理される

・アトリビュート：エンティティにある情報を詳細に分解したもの。属性とも呼ばれる。データベースではテーブルが持つカラムとして管理される

・リレーション：エンティティの関係性を表現したもの。エンティティ間に関係性がある場合、ER図上で線や矢印を引いて表現する

・カーディナリティ：多重度とも呼ばれる概念。1つのエンティティに対してリレーション（関係性）を持つ他のエンティティがいくつ存在しているのかを表したもの。ER図では「○＝ゼロ」「｜＝1 」「鳥の足（3つ股の線）＝多」の3つの記号を組み合せて表現する

手順4. ER図をRDBのテーブルに変換する【論理設計】

論理設計のフェーズに入ると、作成するデータベースの種類を決め、それに応じてテーブルを作成することになります。データベース上で要件を実現できるテーブル構成にする必要があり、各テーブルがどのような列やキーを持つのかを明確に定義することが求められます。

その際に活用するのが、上記で作成したER図です。きちんと情報が整理されたER図があれば、機械的にRDBのテーブル用に変換できるため、ER図の質がデータベース設計の効率化に直結します。

手順5. 正規化を行う【論理設計】

手順6. 性能要件を確認する【物理設計】

手順7. インデックスを作成する【物理設計】

物理設計では、インデックスの作成と登録も行います。インデックスには「索引」という意味があり、検索するテーブル内のレコードを識別する項目と、レコードの格納場所を示すポインタで構成されているのが特徴です。

稼働初期のころは、レコード数もそれほど多くないので、検索もスムーズに行うことができるでしょう。しかし1、2年と経過すると、膨大なレコードがデータベースにたまってしまい、検索速度が低下して結果がなかなか得られないことも。

そういったケースに対処するためにもインデックスは不可欠です。インデックスによって検索するデータが格納されている場所をすぐに特定できるため、データベースの処理スピードをより高速化させることが可能です。

ただし、このインデックスは最初に一度だけ作成すればそれで終わりではありません。稼働後も最適解を求めてインデックスの再作成を何度か行う必要はあるでしょう。

手順8. データ格納領域を決める【物理設計】

性能要件で確認した容量のデータを十分に格納できるだけのデータ領域を確保し、ハードウェアの仕様やハードウェア上でのファイルの配置を最後に決めます。

将来的には必ずデータベースに格納する情報量が増えます。そのため、データ領域のサイズにはある程度余裕を持たせておくことも必要でしょう。

データベース設計を行う際のポイント

最後にデータベース設計を行う際のポイントについても解説します。

ポイント1. データベース導入の目的を明確にする

当然のことですが、データベースを導入する目的や用途は明確にしておきましょう。目的やおもな用途、自社のどの部署が使用するのか、どのぐらいの数のユーザーが利用するのか、といった具体的なユーザーを想定してデータベース設計は行うべきです。

また、データベース設計は基本的にシステムありきで話が進みます。そのため、システムに関する要件や仕様も同時に理解しておく必要があります。システム側の要件や仕様を理解していなければ、データベース側で用意すべきテーブルの種類やカラムの定義が見えてきません。

システム側の要件定義書や仕様書をくまなく確認しながら必要なテーブルを洗い出し、システム全体を見ながら設計を進めていきましょう。

ポイント2. 仕様書に細かく明記されていない箇所まで想像する

システム側の要件定義書や仕様書を確認しても、データベースに関する項目は細かく明記されていないことがあります。なかには「〇〇テーブルに登録」「〇〇テーブルの△△項目を更新」などとしか記載されていないケースも。

ですが、実際は仕様書に明記されていなくても確認すべき箇所はあります。たとえば、「すでに登録されたレコードは物理削除しても大丈夫なのか」「いつ、だれが登録したデータなのか分からなくて大丈夫なのか」などです。

こうした項目に関しては、以下のような対策を設けておきましょう。

・物理削除されて困るテーブルには、論理削除（復元可能な形でデータを一時的に削除扱いとする）フラグを設ける
・いつ、だれが操作したレコードなのか後から追えるように、「登録日」「登録者」「登録プログラム」「更新日」「更新者」「更新プログラム」などの項目をテーブルに用意する

上で紹介した7つの項目は、データベースには必ず設けたい項目ともいえます。要件定義書や仕様書に書かれていなくても、忘れずに準備しましょう。

ポイント3. 将来性も考える

企業が扱うシステムである以上、新ビジネス発足や事業成長により扱う商品などが増えるケースは想定しておかなければなりません。想定が不足すると、思わぬバグを引き起こすことも考えられます。

たとえば、当初想定していたテーブルの項目桁数をオーバーして登録や更新を行ってしまった場合、データベースへの登録や更新ができずにシステムエラーとなります。

システムに仕様変更はつきものです。ですが、それにともなう変更漏れで項目の桁数が不足するといったことはある意味ヒューマンエラーでもあります。1桁不足するだけでもシステムではバグ扱いです。それが嫌で無駄に桁数をとるのも違いますが、ある程度将来を見すえたデータベース設計は不可欠だともいえます。

データベース設計はGIGにお任せください

データベース設計が適切に行われていないと、「求めている結果が得られない！」「検索結果の表示が遅い！」「データの整合性があってない！」など、現場から苦情だらけのシステムになってしまうかもしれません。

今回解説したように、データベース設計の手順や考え方はある程度確立されているものの、実際に設計できるかは別の話です。作業については、システム開発のプロに任せるのが無難だともいえます。

GIGではシステム開発やデータベース設計はもちろんのこと、クライアント企業が抱える課題を明確化し、目的を達成するためのプランニングから運用・改善まで総合的にサポートいたします。

豊富なシステム開発の実績が示すように、GIGはお客様と丁寧で密なコミュニケーションを重ねてきたと自負しております。データベース設計について分からないことや不明点がある場合には、無料相談から承っていますので、ぜひ一度お問い合わせください。

GIG BLOG編集部

株式会社GIGのメンバーによって構成される編集部。GIG社員のインタビューや、GIGで行われたイベントのレポート、その他GIGにかかわるさまざまな情報をお届けします。