LASSIC Media らしくメディア
データベース設計・データモデリングの外注の進め方
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- データベース設計は概念設計・論理設計・物理設計の3段階に分かれ、外注時はこの段階ごとに委託範囲を切ることができます。
- 正規化・非正規化の判断とインデックス設計は、性能・拡張性・データ整合性のバランスを左右する技術的な意思決定です。
- 外注を成功させるには、発注側が業務ルールとデータ量の見通しを事前に整理し、設計レビューに参加できる体制を整えることが大切です。
目次
データベース設計・データモデリングとは何か
データベース設計・データモデリングとは、業務で扱うデータの構造・関係性・制約を整理し、システムが扱うデータの土台を定義する作業です。IPA（情報処理推進機構）は、データベーススペシャリスト試験の対象者像において「データモデリング技法を理解し、利用者の要求に基づいてデータ分析を行い、正確な概念データモデルを作成できる」ことを期待する技術水準として示しています*1。データモデリングは設計工程の中でもデータの意味・構造を定める中核的な作業と位置づけられます。
データモデリングは、要件定義で洗い出した業務対象（顧客・注文・在庫など）を、システムが扱えるデータ構造に変換する作業です。この変換の精度が、後工程の開発効率とシステムの保守性を左右します。設計段階で見落とした関係性やルールは、開発が進んだ後に修正すると影響範囲が広がりやすいという特徴があります。
データベース設計を外注する場面は、新規システム開発でのゼロからの設計だけではありません。既存システムのデータモデルが業務変化に追随できず再設計が必要になる場面、複数システムを統合する際にデータ構造を統一する場面など、外部の設計力を必要とする状況は複数あります。
概念設計・論理設計・物理設計——3段階で進む設計プロセス
データベース設計は、抽象度の高い概念設計から、DBMS（データベース管理システム）の実装に近い物理設計へと段階的に具体化していく3段階のプロセスで進みます。各段階で決めることと成果物が異なります。
概念設計——業務の実体と関係を整理する
概念設計は、特定のDBMSやテーブル構造を意識せず、業務上の「実体（エンティティ）」と「関係（リレーション）」を整理する段階です。「顧客」「注文」「商品」といったエンティティを洗い出し、それぞれの関連をER図（Entity-Relationship Diagram、実体関連図）として可視化します。
この段階の成果物はER図と、各エンティティが持つ属性の一覧です。概念設計はDBMSの種類（リレーショナルデータベースか、それ以外か）に依存しないため、業務理解が最も重要になる段階といえます。発注側の業務知識が設計品質に直結するのはこの段階です。
論理設計——テーブルと項目の構造を定義する
論理設計は、概念設計で整理したエンティティ・関係を、リレーショナルデータベースであればテーブル・カラム・データ型・制約として定義する段階です。この段階で正規化（後述）を行い、データの重複や更新時の不整合を防ぐ構造に整理します。
論理設計の成果物は、テーブル定義書・ER図（論理レベル）・データ項目定義書です。論理設計も特定のDBMS製品（Oracle・MySQL・PostgreSQL等）には依存しませんが、リレーショナルモデルという実装方式には依存します。
物理設計——DBMS製品の実装に落とし込む
物理設計は、論理設計で定めたテーブル構造を、実際に採用するDBMS製品の機能を使って実装する段階です。インデックスの設計、パーティショニング（データの分割配置）、格納領域の設計、DBMS固有のデータ型選定などを決めます。
物理設計の成果物はDDL（テーブル作成用のSQL文）、インデックス定義書、テーブル定義書（物理レベル）です。この段階からはDBMS製品の技術知識が必要になるため、外注先の技術力が最も試される段階になります。
正規化と非正規化——整合性と性能のトレードオフ
正規化とは、リレーショナルデータベースにおいて、同じ情報が複数の場所に重複して保持されないようテーブルを整理する手法です。正規化の目的は、一つの事実を一箇所にまとめ、更新時の不整合（同じ情報を更新し忘れて食い違いが生じる状態）を防ぐことにあります。
正規化には段階があり、第1正規形では繰り返し項目を排除し、第2正規形では主キーの一部にしか依存しない項目を別テーブルに分離します。第3正規形では、主キー以外の項目に依存する項目（推移的関数依存）をさらに分離します。実務では第3正規形までの適用が広く行われています。
| 段階 | 整理する内容 | 効果 |
|---|---|---|
| 第1正規形 | 繰り返し項目を1項目1値に分解する。 | 1セルに複数値が入る状態を解消する。 |
| 第2正規形 | 主キーの一部だけに依存する項目を分離する。 | 部分的な重複更新の不整合を防ぐ。 |
| 第3正規形 | 主キー以外の項目に依存する項目を分離する。 | 間接的な依存による重複を排除する。 |
一方、正規化を進めるほどテーブル数が増え、参照系の処理では複数テーブルの結合（JOIN）が必要になります。テーブル結合はデータ量が増えるほど処理負荷が上がりやすく、読み取り性能を優先する場面では、意図的に正規化の水準を下げてテーブルを統合する非正規化が選択されることもあります。
正規化と非正規化はどちらが正しいという二択ではありません。更新頻度が高く整合性を重視する業務データは正規化を優先し、大量データの集計・参照が中心の分析用途では非正規化やサマリーテーブルの併用を検討する、という使い分けが実務上の判断軸になります。
インデックス設計・キー設計が性能と拡張性を決める
インデックスとは、テーブル内の特定の列を高速に検索できるようにする索引構造です。インデックスを適切な列に設定することで検索処理の速度は改善しますが、インデックスの数が増えるほど、データ更新時にインデックス自体の更新処理も発生し、書き込み性能への影響が生じます。
キー設計も物理設計の重要な要素です。主キー（レコードを一意に識別する項目）に業務上意味のあるコード（例：顧客コード）を使うか、意味を持たない連番（サロゲートキー）を使うかは、将来的な業務ルールの変更に対する影響範囲の大きさに関わります。業務コードが変更される可能性がある場合、主キーに業務コードを直接使うと、コード変更時にすべての関連テーブルへ影響が及びます。
外部キー（他テーブルの主キーを参照する項目）による整合性制約の設計も、データの整合性を保つ仕組みです。外部キー制約をどこまでDBMS側で強制するか、アプリケーション側の処理でチェックするかは、開発チームとの合意が必要な設計判断になります。
外注時の委託範囲——どこまで社内で握り、どこから任せるか
データベース設計を外注する際、委託範囲の切り方には複数のパターンがあります。どの段階から委託するかによって、発注側に求められる準備や設計への関与度が変わります。
| 委託パターン | 社内で担う範囲 | 外部に委託する範囲 |
|---|---|---|
| 概念設計から委託 | 業務要件の提示・レビュー | 概念設計・論理設計・物理設計の全段階 |
| 論理設計から委託 | 概念設計（ER図・エンティティ整理） | 論理設計・物理設計 |
| 物理設計のみ委託 | 概念設計・論理設計 | 物理設計（DBMS実装・インデックス設計） |
業務知識を持つ社内メンバーが概念設計・論理設計までを握り、DBMS固有の技術知識が必要な物理設計だけを外部に委託するパターンは、業務要件のブレを防ぎながら技術面を補完できる進め方です。社内に業務知識を持つ人材がいない場合や、新規事業でゼロから業務ルールを整理する必要がある場合は、概念設計から委託する進め方が選ばれます。
委託範囲を曖昧にしたまま発注すると、「業務ルールの解釈違い」による設計のやり直しが発生しやすくなります。特に、業務上のルール（在庫のマイナス値を許容するか、注文のキャンセル履歴を保持するかなど）は、外部の設計者が推測で決めると実態と合わない設計になるリスクがあります。委託範囲の境界線を発注前に明文化しておくことが、手戻りを防ぐ前提条件になります。
発注側が準備すべき情報と設計レビューの進め方
データベース設計を外注する場合、発注側が事前に用意する情報の質が、設計の精度を左右します。最低限整理しておきたい情報は次の通りです。
- 業務で扱うデータの種類と、データ間の関係（1つの注文に複数の商品が紐づく、など）
- データの発生量と増加の見通し（1日あたりの新規注文数、想定される顧客数の上限など）
- 業務ルール上の制約（同じ商品を同時に注文できるか、削除したデータを復元する必要があるかなど）
- 既存システムがある場合は、現行のデータ構造・移行対象データの範囲
- 参照・更新の頻度が高い処理（検索条件として使われる項目、集計処理の対象項目）
データ量の見通しが共有されないまま設計を進めると、想定より大量のデータが発生した際にインデックス設計や正規化の水準が合わなくなるリスクがあります。運用開始後にテーブル構造を大きく変更するには、既存データの移行作業とアプリケーション側の修正が伴うため、初期設計段階で数量感を伝えておく重要性は高いといえます。
設計レビューでは、ER図やテーブル定義書を発注側が読み解けるよう、外部設計者に業務用語での説明を求めることが有効です。技術用語のまま提示されたER図を発注側が十分に検証できず、業務ルールとの不一致に気づかないまま承認してしまうケースは、後工程での修正コストにつながります。レビュー時には「このテーブルのこの項目は、業務上のどの情報に対応するか」を1つずつ確認する進め方が実務上の対策になります。
LASSICのデータベース設計支援——元請として担う役割
LASSICはIT事業部において、元請（プライムベンダー）としてシステムの保守・運用を受託する体制を持ちます。データベース設計・データモデリングは、その後の開発・運用フェーズの土台となる工程であるため、要件定義から物理設計までを一貫した窓口で担う体制を重視しています。
設計だけを単発で請け負うのではなく、業務要件のヒアリングから概念設計・論理設計・物理設計、その後の開発・運用までを見据えて関与することで、工程の引き継ぎで生じがちな認識のズレを抑えられます。データベース設計は後工程の開発効率と長期的な保守性を左右する土台であるため、上流の要件整理から一貫して伴走する体制を重視しています。
まとめ：データベース設計外注を成功させる3つの判断軸
本稿では、データベース設計・データモデリングの外注における進め方を整理しました。要点を3つに集約すると次の通りです。第一に、設計は概念設計・論理設計・物理設計の3段階で進み、段階ごとに必要な知識と成果物が異なります。第二に、正規化・インデックス設計は整合性と性能のトレードオフを踏まえた判断であり、業務特性に応じた選択が必要です。第三に、委託範囲を段階のどこで切るかを発注前に明文化し、業務ルールとデータ量の見通しを共有することが、手戻りのない外注につながります。
よくある質問
データベース設計とデータモデリングは同じ意味ですか。
厳密には範囲が異なります。データモデリングは業務データの構造・関係を整理する作業を指し、主に概念設計・論理設計にあたります。データベース設計はそれに加えて、DBMS製品への実装（物理設計）までを含む、より広い工程を指す言葉として使われることが一般的です。
概念設計だけを社内で行い、論理設計以降を外注することはできますか。
可能です。業務知識を持つ社内メンバーがエンティティと関係を整理したER図を用意し、それをもとに論理設計・物理設計を外部に委託する進め方は実務でよく見られます。この場合、概念設計の内容が正確であることが後工程の精度を左右するため、社内での整理段階に十分な時間を確保することが大切です。
正規化を進めすぎるとどのような問題が起こりますか。
テーブル数が増えるため、データを参照する処理で複数テーブルの結合が必要になり、データ量が多い場合は処理負荷が上がりやすくなります。更新の整合性を重視する業務データと、大量データを高速に参照したい分析用途とでは適切な正規化の水準が異なるため、用途に応じてバランスを取ることが必要です。
既存システムのデータベースを再設計する場合、新規設計と何が違いますか。
既存データの移行が伴う点が大きく異なります。新しいテーブル構造に既存データをどう変換するかの移行設計が必要になり、移行中の業務停止時間や、移行後のデータ整合性の検証も設計範囲に含まれます。既存システムの現行データ構造とデータ量を外部設計者に正確に共有できるかが、再設計の精度を左右します。
データベース設計の外注では何を基準に委託先を選べばよいですか。
委託を検討している業務領域・データ量規模に近い設計経験があるか、採用予定のDBMS製品への実装経験があるかを確認することが基本です。加えて、設計内容を業務用語で説明し発注側と合意形成できるコミュニケーション体制があるかも、レビューの実効性に関わる確認点になります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：IPA（独立行政法人情報処理推進機構）「データベーススペシャリスト試験」対象者像・期待する技術水準（試験区分ページ）
