データベース設計（データベースせっけい、英: database design）は、ソフトウェア開発工程においてデータベースの詳細なデータモデルを作る工程である。データベース設計の成果物である物理スキーマは、論理設計上の決定と物理設計上の決定、および物理的な記憶装置に設定するパラメタ群を、すべて含む。物理スキーマで記述される物理的な記憶装置に設定するパラメタ群については、なんらかのデータ定義言語 (DDL) を使って記述する際に必要なパラメタ群のみを、決定する。DDLで記述された内容は、データベースを構築するために使うことができる。十分に詳細に記述されたデータモデルは、おのおのの実体ごとに属性群を詳細に規定する。ウィキシステムを実体関連図（ER図）で記述した例（MediaWikiのデータベーススキーマの一部）

データベース設計という用語には、あいまいさがある。データベースシステム（データベースを使うコンピュータシステム）の全体の設計のうち、いくつかの異なる構成要素に対して、データベース設計という同じ用語が使われている。正確には、データベース設計という用語は、データを永続化 (格納) するために使われる基本データ構造群の論理的な設計を意味すると、考えられている。関係データベースを使う関係モデルにおいては、データベース設計は、基底関係（関係、表、テーブル）の集まりと導出関係 (ビュー）の集まりをいう。オブジェクトデータベースを使うオブジェクト指向モデリングにおいては、データベース設計は、実体（エンティティ）の集まりと関連（リレーションシップ）の集まりは、オブジェクトのクラスの集まりと名前つきの関連の集まりに、直接に対応づけられる。しかしながら、データベース設計という用語は、設計の工程の全体に対して適用されることもある。その場合は、基本データ構造に加えて、データベース管理システム (DBMS) においてデータベースと相互作用するアプリケーションソフトウェア全体の一部分として使われる、ユーザインタフェースやデータ操作（データ問い合わせを含む）をも、データベース設計の対象に含まれる。
設計工程

データベース設計を行う工程は、一般的には、データベース設計者が行う多くの作業から、構成される。こうした作業のすべてが、あらゆる場合において必ずしも必要であるわけではない。多くの場合、データベース設計者が行う作業のうち必須であるのは、次に列記する作業である。

データベース内に永続化（格納）するべきデータを決定する

異なるデータ要素間の関連の集まりを決定する

こうして決定された関連の集まりを基盤として、データに論理構造を重ね合わせる

関係モデルにおいては、データベース設計の最後の作業は、一般的にはさらに2つの作業に分割することができる。1つは、構築するシステム内の情報をグループの集まりにまとめる作業である。この作業は、一般的には基底オブジェクトの集まりを同定する作業である。基底オブジェクトの集まりに関する情報がデータベースに永続化されることになる。もう一つは、情報のグループの集まりあるいはオブジェクトの集まりの、相互の、関連の集まりを決定する作業である。後者の作業は、データベースとしてオブジェクトデータベースを採用する場合は、不要である。

データを木構造に構造化する場合は、必然的に階層型データモデルでデータを構成することになるであろう。階層型データモデルによるデータ構成は、親-子 (has-a, is-a) の関連の集まりである。オブジェクトデータベースでは、オブジェクトクラスのインスタンス間に、単純に一対多の関連を使う。オブジェクトデータベースではまた、オブジェクトクラス間に階層的な関連の概念を、導入している。このオブジェクトクラス間の階層的な関連の概念は、継承という用語で呼ばれる。継承の関連においては、階層構造の上側のクラスを基底クラスといい、下側のクラスを派生クラスという。
永続化するデータを決定する

多くの場合、データベース設計を行う人は、データベース設計に精通している。いっぽうで、データベース設計者が、永続化（格納）の対象となる業務データ（例えば金融の情報や生物学の情報）の業務に精通していることは、あまりない。こうした事情により、データベースに永続化するデータを決定する作業は、データベース設計に精通している人と、業務に精通しておりかつデータベース内にどのデータを永続化しなければならないかをわかっている人との、共同作業でなければならない。

この作業は、一般的には、ソフトウェア開発工程における要求分析の作業の一つと位置づけられる。データベース設計者には、業務知識に精通している人々から必要な情報をくみとる能力が、必須である。なぜなら、データベース設計で必要とされる業務知識には、データベースに対するシステム面での要求が明瞭に表現されていないことが、多いからである。データベース設計者は、永続化しなければならないおのおのの業務データ要素を基盤として思考することに、慣れていないことが多い。永続化するデータは、要求仕様で記述する。
概念設計「概念スキーマ」も参照

データベース設計者は、データベースに永続化するデータを同定した後、つぎにデータがどのように互いに関連しあっているかを決定しなければならない。この作業を行う際に、データベース設計者は一般的にはデータ間の従属関連を同定する。このような従属関連でむすびついているデータは、一方のデータの一部分の情報が他方のデータに依存している。すなわち、依存元のデータの一部分の情報が変われば、依存先のデータもまた変わるのである。氏名と住所の一覧の例を考える。次のように前提する。

2人の人々が同一の住所をもつことができる。

1人の人は2つの住所をもつことはできない。

この前提のもとでは、氏名は住所に従属している。なぜなら、住所が異なれば、その住所と関連している氏名もまた異なっているからである。しかしこの逆は必ずしも真ではない。すなわち、氏名が異なっていても住所が同一である可能性がある。

（注記: よくある誤解は、関係モデルという用語はデータ間の「関連」について言及しているから「関係」モデルと呼ばれている、というものである。これは正しくない。関係モデルは、関係として知られている数学的構造を基盤としているため、関係モデルと名づけられたのである。）
論理設計「論理スキーマ」も参照

永続化の対象となるさまざまな情報を入力として従属関連の集まりが同定されると、データを論理的に構造化することができる。データの論理的構造は、データベース管理システム (DBMS) によってサポートされる記憶域オブジェクトに対応づけることができる。

関係データベースを使う場合は、記憶域オブジェクトは基底関係（表、テーブル）である。関係は、組 (タプル、行)と属性 (列、カラム) のなかにデータを格納する。おのおのの関係 (表) は、論理的オブジェクトの、もしくは一つ以上の論理的オブジェクトと一つ以上の論理的オブジェクトをむすびつける関連の、実装を表現する。論理的オブジェクトの間の関連は、子の論理的オブジェクトと親の論理的オブジェクトをむすびつける関連として格納される。複雑な論理的関連は、それ自体が関係である。複雑な論理的関連を表現する関係は、おそらく複数の親の論理的オブジェクトの関係群への参照をもつであろう。

オブジェクトデータベースを使う場合は、記憶域オブジェクトは、オブジェクト指向プログラミング言語で使われるオブジェクトに直接に対応づけられる。オブジェクト指向プログラミング言語は、データを管理しまたデータにアクセスするアプリケーションソフトウェアを記述するために、使われる。関連は、オブジェクトクラスの属性として定義されるか、もしくはオブジェクトクラスにおいて操作を行うメソッドとして定義される。
物理設計「物理スキーマ」も参照

データベースの物理設計では、記憶装置上でのデータベースの物理的な設定を指定する。この設定には、データベース管理システム (DBMS) のデータ辞書に保持される、次に示すものの詳細仕様が含まれる。

データ要素

データ型

索引 (インデクス) づけのオプション

その他のパラメタ

システムの詳細設計には、次に示すものが含まれる。

モジュールの集まり

データベースのハードウェア仕様

データベースのソフトウェア仕様

設計の原理

クリス・デイトなどの人々は、関係データベースによるデータベース設計の基盤となるいくつかの原理を提唱している。
直交設計の原理 (Principle of Orthogonal Design, POOD)[1]