データベース

SQL言語のSELECT文とその実行結果を示す

コンピューティングにおいて、データベース（英: database）は、電子的に保存され、アクセスできる組織化されたデータの集合である。小規模なデータベースはファイルシステム上に保存されるが、大規模なデータベースはコンピュータ・クラスターまたはクラウド・ストレージで保存される。データベース設計に関わる分野は多岐にわたり、データ・モデリング、効率的なデータ表現と保存、クエリ言語、機密データのセキュリティやプライバシー、同時アクセスとフォールトトレランスのサポートを含む分散コンピューティングの課題など、形式技術と実用的な考慮事項に及ぶ。

データベース管理システム（DBMS）は、エンドユーザー、アプリケーション、およびデータベース自体と対話し、データを取得し分析するためのソフトウェアである。さらに、DBMSソフトウェアには、データベースを管理するために提供される関連機能も含まれている。データベース、DBMS、関連アプリケーションの全体を含めてデータベースシステムと呼ぶ。しばしば「データベース」という用語が、DBMS、データベースシステム、またはデータベースに関連するアプリケーションのいずれかを指す場合に漠然と使われている。

コンピュータ科学者は、データベース管理システムを、サポートするデータベースモデルに基づいて分類している。リレーショナルデータベースは、1980年代の主流であった。これらは、データを一連の表の行と列としてモデル化し、大多数はデータの書き込みとクエリ（問い合わせ）にSQLを使用する。2000年代には、異なるクエリ言語を使用する NoSQL と総称される非リレーショナルデータベースが普及した。

用語と概要

形式的な「データベース」は、関連するデータの集合とその編成方法を指す。通常、このデータへのアクセスは、「データベース管理システム」（DBMS）によって提供される。DBMSは、ユーザーが1つまたは複数のデータベースと対話し、データベースに含まれるすべてのデータへのアクセスを提供するコンピュータソフトウェアの統合セットで構成されている（ただし、特定のデータへのアクセスを制限する制約が存在することもある）。DBMSは、大量の情報の入力、保存、および検索を可能にするさまざまな機能を提供し、その情報がどのように編成されているかを管理する方法を提供する。

このように、両者は密接な関係にあるため、「データベース」という用語は、データの集まりとしてのデータベースと、それを操作するために用いるDBMSの両方を指す言葉として気軽に使われることが多い。

情報技術の専門家以外の世界では、「データベース」という用語は、関連するデータの集合体（例: スプレッドシートやカードインデックスなど）を指すことが多く、サイズや使用要件の点からデータベース管理システムを用いることが一般的である。

既存のDBMSは、データベースとそのデータを管理するためのさまざまなな機能を提供しており、それらは次の4つの主要な機能群に分類される。

• データ定義（Data definition）- データの編成を規定する定義を作成、変更、および削除する。
• 更新（Update）- 実データを挿入、変更、および削除する。
• 検索（Retrieval）- 情報を直接利用できる形式で、または他のアプリケーションでさらに処理できる形式で提供する。検索したデータは、基本的にデータベースに保存されているのと同じ形式で利用できる他、データベースの既存のデータを変更または組み合わせて得た新たな形式でも利用することができる。
• 管理（Administration）- ユーザーの登録と監視、データセキュリティの実施、性能の監視、データ完全性の維持、並行性制御の対応、予期しないシステム障害などの事象によって破損した情報の回復など。

データベースとそのDBMSは共に、特定のデータベースモデルの原則に準拠している。 「データベースシステム」とは、データベースモデル、データベース管理システム、データベースを総称したものである。

物理的には、データベース・サーバーは、実際のデータベースを格納し、DBMSと関連ソフトウェアのみを実行する専用コンピュータである。データベース・サーバーは通常、大容量のメモリと、安定したストレージ（例: RAIDディスクアレイ）を備えたマルチプロセッサ・コンピュータである。大容量のトランザクション処理環境では、複数台のサーバーと高速チャネルを介して接続されたハードウェア・データベース・アクセラレータも使用される。ほとんどのデータベース・アプリケーションの中心にDBMSがある。DBMSは、ネットワークのサポートを組み込んだカスタムのマルチタスク・カーネルを中心に構築されることもあるが、最近のDBMSは通常、これらの機能を提供するために、標準的なオペレーティングシステムに依存している。

DBMSは重要な市場を形成しているため、コンピューターやストレージのベンダーは、自社の開発計画にDBMSの要件を考慮に入れていることが多い。

データベースとDBMSは、サポートするデータベースモデル（リレーショナルやXMLなど）、実行するコンピュータの種類（サーバークラスタから携帯電話まで）、データベースへのアクセスに使用するクエリ言語（SQLやXQueryなど）、内部エンジニアリング（性能、スケーラビリティ、障害許容力、およびセキュリティに影響する）によって分類することができる。

歴史

データベースとそれぞれのDBMSの規模、機能、性能は桁違いに大きくなっている。これらの性能向上は、プロセッサ、コンピュータメモリ、コンピュータストレージ、およびコンピュータネットワークの技術進歩により可能となった。データベースの概念は、1960年代半ばに広く普及した磁気ディスクなどの直接アクセス記憶媒体の出現によって可能となった。それ以前のシステムは、磁気テープへのデータの順次保存に依っていた。その後のデータベース技術の発展は、データモデルまたはデータ構造に基づいて、ナビゲーショナル、SQL/リレーショナル、ポストリレーショナルの3つの時代に分けることができる。

初期のナビゲーショナル・データモデルは、階層型モデルとネットワーク型モデル（CODASYLモデル）の2つが主であった。これらは、あるレコードから別のレコードへの関係を追跡するために、ポインタ（多くの場合、物理的なディスクアドレス）を使用することが特徴であった。

1970年にエドガー・F・コッドが提唱したリレーショナルモデルは、この伝統から脱却するもので、アプリケーションがリンクをたどるのではなく、内容からデータを検索すべきであると主張するものであった。リレーショナルモデルは、元帳型の表の集まりを組み合わせたもので、それぞれの表は異なる種類のエンティティ（実体）を格納する。1980年代半ばになって、コンピューティング・ハードウェアは、リレーショナルシステム（DBMSとアプリケーション）を幅広く普及するのに十分な性能を持つようになった。けれども、1990年代初頭には、すべての大規模なデータ処理アプリケーションにおいてリレーショナルシステムが主流となり、2018年現在も主流であり続けている。IBM Db2、Oracle、MySQL、Microsoft SQL Server、PostgreSQLは、最も検索されているDBMSである。リレーショナルモデル用の主要なデータベース言語である標準SQLは、他のデータモデル用のデータベース言語にも影響を与えた。

オブジェクトデータベースは、オブジェクト指向とリレーショナル型とのインピーダンスミスマッチ（相性の欠如）による不便さを解消するために1980年代に開発され、これにより「ポストリレーショナル（post-relational）」という言葉が生まれ、また、ハイブリッド型のオブジェクト・リレーショナルデータベースも開発された。

2000年代後半に登場した、次世代のポスト・リレーショナルデータベースは、高速なキーバリュー型ストアやドキュメント指向データベースを導入し、NoSQLデータベースと呼ばれるようになった。これと競合するNewSQLと呼ばれる次世代データベースは、リレーショナル/SQLモデルを維持しつつ、市販のリレーショナルDBMSと比較してNoSQLの高い性能に見合うような新しい実装を試みている。

1960年代、ナビゲーショナルDBMS

→詳細は「ナビゲーショナル・データベース」を参照

ナビゲーショナル・データベースモデル（例: CODASYL）の基本構造であるレコードセットの閉じた連鎖を示す。レコードセットは、「オーナー」とも呼ばれる1つの親レコードと、「メンバーレコード」とも呼ばれるn個の子レコードから構成される。各レコードのキーによって正方向ポインタ、逆方向ポインタ、直接ポインタが提供される。

データベースという言葉が登場したのは、1960年代半ば以降に、直接アクセスストレージ（ディスクやドラム）が利用できるようになった時期と重なる。この用語は、過去のテープベースのシステムとは対照的に、日常のバッチ処理ではなく、対話的な共有での利用を可能にすることを意味した。オックスフォード英語辞典では、カリフォルニアのSystem Development Corporationが1962年に発表した報告書を、特定の技術的な意味で「データベース」という用語を初めて使用したものとして引用している。

コンピュータの速度と機能が向上するに伴い、多くの汎用データベースシステムが登場し、1960年代半ばには多くのこうしたシステムが商用化されるようになった。標準化への関心が高まり、そうした製品の一つであるIntegrated Data Store（IDS）の制作者であるチャールズ・バックマンが、COBOLの作成と標準化を担当したグループCODASYL内にデータベース・タスクグループを設立した。1971年、データベース・タスクグループは、一般に「CODASYLアプローチ」として知られるようになった彼らの標準を提供し、まもなくこのアプローチに基づいた多くの商用製品が市場に参入した。

CODASYLアプローチ方式は、アプリケーションに対し、大規模ネットワーク内に形成された連結データセットを移動する機能を提供した。アプリケーションは、3つの方法のうちのいずれかによってレコードを見つけることができる。

1. 主キーの使用（CALCキーとして知られ、典型的にはハッシュによって実装される）。
2. あるレコードから別のレコードへの関係（セットと呼ばれる）の移動。
3. すべてのレコードを順番にスキャンする。

その後のシステムで、B木（B-tree）が追加され、代替アクセス経路を提供するようになった。また、多くのCODASYLデータベースでは、エンドユーザー向けに（ナビゲーション型APIとは異なる）宣言型クエリ言語も追加された。しかし、CODASYLデータベースは複雑で、有用なアプリケーションを作るには多大な訓練と労力を要した。

また、IBMは、1966年に、Information Management System（IMS）として知られる独自のDBMSを持っていた。IMSは、アポロ計画のために作成されたソフトウェアのSystem/360への発展型であった。IMSは一般にCODASYLと概念が似ているが、そのデータナビゲーションのモデルは厳密な階層を使用し、CODASYLのネットワーク型モデルではなかった。どちらの概念も、データへのアクセス方法の観点から、後にナビゲーショナル・データベースと呼ばれるようになった。この用語は、1973年のバックマンのチューリング賞の講演「The Programmer as Navigator」によって広まった。IBMによって、IMSは階層型データベースとして分類されている。IDMSやCincom SystemsのTOTALデータベースは、ネットワーク型データベースに分類される。2014年現在、IMSは使用されている。

1970年代、リレーショナルDBMS

エドガー・F・コッドは、カリフォルニア州サンノゼにあるIBMの研究室の1つで、主にハードディスクシステムの開発に携わっていた。彼は、CODASYLアプローチのナビゲーションモデルにおいて、特に「検索（search）」機能の欠如に不満を抱いていた。1970年、彼はデータベース構築の新しいアプローチを概説する多くの論文を書き、最終的に画期的な論文「大規模共有データバンクのためのデータのリレーショナルモデル（A Relational Model of Data for Large Shared Data Banks）」に結実させた。

この論文で、彼は大規模なデータベースを保存し、操作するための新しいシステムについて説明した。コッドの考えは、CODASYLのように自由形式のレコードをある種の連結リストに格納するのではなく、データをいくつかの「テーブル」（table、表）として編成し、それぞれのテーブルを異なる種類のエンティティ（entity、実体）に使用することであった。各テーブルは、エンティティの属性を含む固定数の列を含むことになる。各テーブルの1つ以上の列は、テーブルの行を一意に識別するための主キーとして指定され、テーブル間の相互参照には、ディスクアドレスではなく、常にこの主キーが使用された。クエリにおいては、関係論理の数学的体系に基づく一連の操作を用いて、これらのキー関係に基づいてテーブルを結合する（モデルの名前の由来）。データを正規化された一連のテーブル（または関係（relation）、リレーション）に分割することで、各々の「ファクト（fact、事実）」を一度だけ保存するようにし、更新操作を簡略化する。ビュー（view）と呼ばれる仮想的なテーブルは、ユーザーごとに異なる方法でデータを表示することができるが、ビューを直接更新することはできなかった。

コッドは、テーブル、行、列ではなく、関係（relation）、組（tuple）、定義域（domain）という数学用語を使ってモデルを定義した。現在よく知られているこれらの用語は、初期の実装に由来するものである。コッドは後に、実際の実装が、モデルの基礎となった数学的な基礎から逸脱する傾向にあることを批判した。

リレーショナルモデルでは、仮想キーを使ってレコードどうしがリンクされる。仮想キーは、データベースに格納されていないが、必要に応じてレコードに含まれるデータ間で定義される。この図は、login列の値「mark」を仮想キーとしてリンクした2つのレコードを示す。

テーブル間の関係を表すために、ディスクアドレスではなく主キー（ユーザー指向の識別子）を使用したのは、主に2つの動機があった。エンジニアリングの観点からは、費用がかかるデータベースの再編成をすることなく、テーブルの再配置やサイズ変更を可能とした。しかし、コッドは、セマンティクス（意味）の違いにより強い興味を持っていた。明示的な識別子を使用することで、純粋な数学的定義で更新操作を定義することが容易になり、一階述語論理という確立した学問分野の観点でクエリ操作を定義できるようになった。これらの操作は純粋な数学的性質があるため、クエリ最適化の基礎をなす証明可能な正しい方法でクエリを書き換えることが可能となる。テーブル間の接続は明示的ではなくなったが、階層型モデルやネットワーク型モデルと比較して表現力が損なわれることはない。

階層型モデルやネットワーク型モデルでは、レコードが複雑な内部構造を持つことが許容された。たとえば、ある従業員の給与履歴は、従業員レコードの中の「繰り返しグループ」として表わされることがある。リレーショナルモデルでは、正規化の過程によって、そのような内部構造は、論理キーのみで結合された複数のテーブルに保持されたデータで置き換えられた。

たとえば、データベースシステムの一般的な使い方として、ユーザーに関する情報、名前、ログイン情報、さまざまな住所や電話番号を突き止めることがあげられる。ナビゲーショナル方式では、これらのデータはすべて1つの可変長レコード内に格納される。リレーショナル方式では、そのデータは（たとえば）ユーザーテーブル、アドレステーブル、電話番号テーブルに「正規化（normalize）」される。これらの任意のテーブル内には、実際に住所や電話番号が提供された場合のみ、レコードが作成される。

コッドは、（ディスクアドレスではなく）論理的な識別子を使用して行／レコードを識別するだけでなく、アプリケーションが複数のレコードからデータを組み立てる方法も変更した。アプリケーションがリンクを移動して1レコードずつデータを収集することを要求するのではなく、アプリケーションは、宣言型のクエリ言語を使用して（どのようにデータを見つけるかというアクセス経路ではなく）どのようなデータが必要なのかを表現する。データへの効率的なアクセス経路を見つけるのは、アプリケーションのプログラマーではなく、データベース管理システムの責任となった。クエリ最適化（query optimization）と呼ばれるこの過程は、クエリが数学的論理の観点で表現されているという事実に基づいている。

コッドの論文は、バークレー校のユージン・ウォンとマイケル・ストーンブレーカーの二人によって着目された。彼らは、地理データベースプロジェクトにすでに割り当てられていた資金と、コードを作成する学生プログラマーを使って、INGRESと呼ばれるプロジェクトを開始した。INGRESは、1973年の初頭に最初のテスト製品を提供し、1979年には一般に広く使用されるようになった。INGRESは、データアクセスのためのQUELと呼ばれる「言語（language）」の使用を含め、多くの点でIBM System Rと類似していた。時の経過とともに、INGRESは新しい標準SQLに移行していった。

IBM自身は、リレーショナルモデルのテスト実装であるPRTVと、製品版であるBusiness System 12の開発を一度行ったが、いずれも現在は廃止されている。Honeywellは、Multics用のMRDSを開発したが、現在ではAlphora DataphorとRelの2つの新しい実装が存在する。「リレーショナル」と呼ばれる他のDBMSの実装のほとんどは、実際にはSQL DBMSである。

1970年、ミシガン大学は、デイヴィッド・L・チャイルズの集合論的データモデルに基づくMICRO情報管理システムの開発を開始した。MICROは、非常に大きなデータセットを管理するために、米国労働省、米国環境保護庁、アルバータ大学、ミシガン大学、ウェイン州立大学の研究者によって使用された。これは、ミシガン・ターミナル・システムを使用するIBMメインフレームコンピューター上で稼働した。このシステムは1998年まで稼動し続けた。

統合型アプローチ

→詳細は「データベースマシン」を参照

1970年代から1980年代にかけ、ハードウェアとソフトウェアを統合したデータベースシステムの構築が試みられた。その根底にある理念は、このような統合が、より高い性能をより低い費用で提供できるというものである。その例として、IBM System/38、Teradataの初期の製品、およびBritton Lee, Inc.のデータベースマシンがあげられる。

また、データベース管理をハードウェアでサポートするアプローチには、ICLのCAFSアクセラレータという、プログラム可能な検索機能を持つハードウェアディスクコントローラーがあった。しかし、汎用コンピュータの急速な発展と進歩に、データベース専用機が追いつくことができなかったため、長期的にはこれらの取り組みは概して失敗に終わった。こうしたことから、現今のほとんどのデータベースシステムは、汎用ハードウェア上で動作するソフトウェアシステムであり、汎用のコンピュータとデータストレージを使用している。しかし、この着想は今もなお、NetezzaやOracle （Exadata）など一部の企業によって特定の用途で追求されている。

1970年代後半、SQL DBMS

1970年代前半、IBMは、System Rとして、コッドの概念に大まかに基づいたプロトタイプシステムの開発を始めた。最初のバージョンは1974年5月に完成し、その後、レコードを構成するすべての要素（一部はオプション）を単一の大きな「チャンク（chunk、塊）」に格納する必要がないように、データを分割できるマルチテーブルシステムに対応する作業が開始された。その後、1978年と1979年にマルチユーザーバージョンが顧客によってテストされ、その時点では標準化されていたクエリ言語SQLが追加されていた。コッドのアイデアは、実行可能でCODASYLよりも優れたものとして確立され、IBMがSQL/DSとして知られるSystem Rの真の製品版、そして後にDatabase 2（IBM Db2）を開発することを後押しした。

ラリー・エリソンのOracle Database（以下、Oracle）は、IBMのSystem Rに関する論文を基に、別の系統から出発した。Oracle V1の実装は1978年に完了したが、エリソンが1979年にIBMを打ち負かしたのはOracle Version 2を市場に投入してからであった。

ストーンブレーカーはその後、INGRESからの教訓を応用して、現在はPostgreSQLとして知られている新しいデータベースPostgresを開発した。PostgreSQLは、大域的で基幹的な業務アプリケーションによく使用されている。（.orgや.infoのドメイン名レジストリでは、多くの大企業や金融機関と同様に、これを主要データストアとして使用している）。

スウェーデンでもコッドの論文は読まれ、1970年代半ばにウプサラ大学でMimer SQLが開発された。1984年、このプロジェクトは独立した企業に統合された。

1976年に登場した実体関係モデルは、それまでのリレーショナルモデルよりも馴染みのある記述法を重視したもう一つのデータモデルであり、データベース設計で人気を博した。その後、実体-関係構造は、リレーショナルモデルのデータモデリング構造として追加され、両者の違いは無意味なものとなった。

1980年代、デスクトップ

1980年代は、デスクトップコンピューティングの時代の到来を告げた。新しいコンピュータは、Lotus 1-2-3のような表計算ソフトやdBASEのようなデータベースソフトで、ユーザーに力をもたらした。dBASE製品は軽量で、コンピューターユーザーは誰でも容易に理解できた。dBASEの作者、ウェイン・ラトリフは次のように述べている。「dBASEは、BASIC、C、FORTRAN、COBOLのようなプログラムとは異なり、多くの汚い仕事はすでに行われている。データ操作はユーザーではなくdBASEが行うので、ユーザーはファイルを開き、読み込み、閉じ、スペース割り当ての管理などの汚い詳細に煩わされることなく、自分のしていることに集中することができる」。dBASEは、1980年代から1990年代初頭にかけて、最も売れたソフトウェアの一つであった。

1990年代、オブジェクト指向

1990年代は、オブジェクト指向プログラミングの台頭とともに、さまざまなデータベース内のデータの扱い方で発展が見られた。プログラマーと設計者は、データベース内のデータをオブジェクトとして扱うようになった。つまり、ある個人のデータがデータベース内にある場合、その人の住所、電話番号、年齢などの特性は外来のデータではなく、その人に属するものと考えられるようになった。これにより、データ間の関係は、個々のフィールドではなく、オブジェクトとその属性に関連付けられる。プログラムされたオブジェクトとデータベースのテーブルとの間の変換の不都合は、「オブジェクト-リレーショナル・インピーダンスミスマッチ」という言葉で表わされる。オブジェクト・データベースやオブジェクト・リレーショナルデータベースは、この問題を解決するために、プログラマーが純粋なリレーショナルSQLの代わりに使用できるオブジェクト指向言語（SQLの拡張機能という場合もある）を提供しようとするものである。プログラミング側の立場では、オブジェクト・リレーショナル・マッピング（ORM）と呼ばれるライブラリで、同じ問題を解決しようとしている

2000年代、NoSQLとNewSQL

→詳細は「NoSQL」および「NewSQL」を参照

XMLデータベースは、構造化されたドキュメント指向データベースの一種で、XML文書の属性に基づいたクエリが可能である。XMLデータベースは、たとえば科学論文、特許、税務申告、人事記録など、非常に柔軟なものから非常に厳格なものまで、データをさまざまな構造を持つ文書の集合として見るのに便利なアプリケーションで主に使用される。

NoSQLデータベースは、多くの場合、非常に高速で、固定化したテーブルスキーマを必要とせず、非正規化したデータを格納することで結合操作を回避し、水平スケーリングするように設計されている。

近年、高い分断耐性を備えた大規模分散データベースが強く求められているが、CAP定理によれば、分散システムで一貫性、可用性、分断耐性を同時に備えることは不可能とされている。分散システムは、これら3つの保証のうち、いずれか2つを同時に満たすことはできても、3つすべてを満たすことはできない。そのため、多くのNoSQLデータベースでは、データ整合性のレベルを下げて可用性と分断耐性の両方を保証する、結果整合性という考え方を採用している。

最新のリレーショナルデータベースの一種であるNewSQLは、SQLを使用し、また従来のデータベースシステムのACID保証を維持しながらも、オンライントランザクション処理のワークロード（読み込みと書き込みの両方を伴う）に対して、NoSQLシステムと同じスケーラブルな性能を提供することを目的としている。

使用例

データベースは、組織の内部業務を支援し、顧客や発注先とのオンラインでのやり取りを支えるために使用される（エンタープライズ・ソフトウェアを参照）。

データベースは、業務における管理情報、エンジニアリングデータや経済モデルなどのより専門的なデータを保持するためにも使用される。たとえば、コンピュータによる図書館システム、航空座席予約システム、コンピュータ化された部品在庫管理システム、およびウェブサイトをウェブページの集合としてデータベースに保存する多くのコンテンツ管理システムなどがあげられる。

分類

データベースを分類する方法として、たとえば、書誌、文書、テキスト、統計、マルチメディアなど、その内容の種類によるものがある。第二の方法は、会計、作曲、映画、銀行、製造、保険など、応用面による分類がある。第三の方法は、データベースの構造やインタフェースの種類など、技術的な側面によるものである。この節では、さまざまな種類のデータベースを特徴付けるために使用される用語をいくつか列挙する。

• インメモリデータベースとは、主にメインメモリ内に存在するデータベースで、一般的に不揮発性のコンピューターデータストレージによってバックアップされる。メインメモリーデータベースはディスクデータベースよりも高速であるため、通信ネットワーク機器など、応答時間が重要な場合に使用されることが多い。
• アクティブデータベースは、データベース内外の両方の状況に応答できるイベント駆動型アーキテクチャを備えている。セキュリティ監視、アラート、統計収集、および承認などの用途が考えられる。多くのデータベースは、データベーストリガーという形でアクティブデータベースの機能を提供する。
• クラウドデータベースは、クラウド技術に基づいている。データベースとDBMSの大半はいずれも遠く離れた「クラウド」上に存在するが、アプリケーションはプログラマーが開発し、エンドユーザーがウェブブラウザとオープンAPIを通じてデータベースを保守／利用する。
• データウェアハウスは、業務用データベースや、しばしば市場調査会社などの外部ソースから得たデータをアーカイブする。 データウェアハウスは、業務データにアクセスできない管理者やその他のエンドユーザーが使用するデータの中心的な供給源となる。たとえば、販売データを週ごとの合計に集計し、ACニールセンのデータと比較できるように社内商品コードを統一商品コード（UPC）に変換する。データウェアハウジングの基本的かつ不可欠なコンポーネントには、データの抽出、分析、マイニング、変換、読み込み、そしてデータをさらに利用できるようにするデータ管理がある。
• 演繹データベースは、論理プログラミングとリレーショナルデータベースを組み合わせたものである。
• 分散データベースとは、データとDBMSの両方が複数のコンピュータにまたがったデータベースのことである。
• ドキュメント指向データベースは、ドキュメント指向または半構造化された情報を格納、取得、および管理するために設計されている。ドキュメント指向データベースは、NoSQLデータベースの主要なカテゴリの一つである。
• 組み込みデータベースシステムとは、保存されたデータへのアクセスを要するアプリケーションソフトウェアと緊密に統合されたDBMSで、アプリケーションのエンドユーザーから隠され、継続的なメンテナンスをほとんど（あるいは全く）必要としないものである。
• エンドユーザー・データベースは、個々のエンドユーザーによって開発されたデータから構成されている。たとえば、文書、スプレッドシート、プレゼンテーション、マルチメディア、およびその他のファイルの集合体である。このようなデータベースをサポートするいくつかの製品が存在する。その中には、本格的なDBMSよりもはるかに単純で、基本的なDBMSの機能を備えているものもある。
• 連合データベースシステムは、複数の異なるデータベースから構成され、それぞれは独自のDBMSを持っている。これは連合データベース管理システム (FDBMS) によって単一のデータベースとして扱われ、あるいは複数の自律的なDBMSを透過的に統合し（この場合、異種データベースシステムでもある）、統合された概念ビューを提供するものである。
• マルチデータベースという用語は、連合データベースの同義語として用いられることもあるが、単一のアプリケーション内で連携する、あまり統合されていないデータベースのグループを指す場合もある（例: FDBMSや管理された統合スキーマを持たない）。この場合、一般的にはアトミックコミットプロトコル（ACP、たとえば2フェーズコミットプロトコル）を含むミドルウェアが分散に使われ、参加データベース間での分散（グローバル）トランザクションを可能とする。
• グラフデータベースは、ノード、エッジ、プロパティを持つグラフ構造を用いて情報を表現および保存するデータベースであり、NoSQLデータベースの一種である。任意のグラフを格納できる一般的なグラフデータベースは、トリプルストアやネットワーク型データベースなどの特殊なグラフデータベースとは異なるものとして区別される。
• 配列DBMSは、衛星画像や気候シミュレーションの出力など、（通常は大規模な）多次元配列のモデリング、保存、検索を可能にするNoSQL DBMSの一種である。
• ハイパーテキストまたはハイパーメディア・データベースでは、オブジェクト（例: 別のテキスト、記事、画像、または映画）を表す任意の単語やテキスト部分を、そのオブジェクトにハイパーリンクすることができる。ハイパーテキスト・データベースは、大量にある異種の情報を整理するのに特に有効である。たとえば、ユーザーがテキストの中を簡単に飛び回ることができるオンライン百科事典を整理するのに役立つ。したがって、ワールドワイドウェブは大規模な分散型ハイパーテキストデータベースと言える。
• 知識ベース（KB、kb、またはΔと略す）は、知識管理のための特別な種類のデータベースであり、コンピュータ化された知識を収集、編成、および検索するための手段を提供するものである。また、問題点とその解決策、あるいは関連する経験などを表すデータの集合でもある。
• モバイルデータベースは、モバイル・コンピューティング・デバイスで実行したり、他のデバイスと同期させたりできる。
• 運用データベースは、組織の運営に関する詳細なデータを格納する。通常、トランザクションを使用して、比較的大量の更新を処理する。たとえば、顧客データベースは、企業の顧客に関する連絡先、信用情報、人口統計情報を記録し、人事データベースは、従業員に関する給与、福利厚生、技能データなどの情報を保持し、企業資源計画システムは、製品の部品、部品在庫、財務に関する詳細を管理し、財務データベースは、組織の収支、会計、および金融取引を監視する。
• 並列データベースは、データのロード、インデックスの作成、クエリの実行などの作業を並列化することで性能向上を図るものである。

基盤となるハードウェア・アーキテクチャによって分類される主な並列DBMSアーキテクチャは次のとおりである。

• 共有メモリ・アーキテクチャ: 複数のプロセッサが主記憶領域や他のデータスト レージを共有する。
• 共有ディスク・アーキテクチャ: 各処理装置（通常は複数のプロセッサで構成）は、独自の主記憶領域を持つが、他のストレージは全装置で共有する。
• シェアード・ナッシング・アーキテクチャ: 各処理装置が独自の主記憶領域その他のストレージを持つ。

• 確率的データベース：ファジィ論理を採用して不正確なデータから推論を引き出す。
• リアルタイムデータベースは、結果が戻ってすぐに処理するのに十分な速度でトランザクションを処理する。
• 空間データベースは、多次元的な特徴を持つデータを格納することができる。このようなデータに対するクエリには、たとえば「私のいる地域で最も近いホテルはどこですか?」というような、位置に基づくクエリが含まれる。
• 時間データベースは、時間データモデルや時間バージョンのSQLなど、時間的な側面が組み込まれている。より具体的には、通常、時間的側面には有効時間とトランザクション時間が含まれる。
• 用語指向データベースは、オブジェクト指向データベースに基づいて構築され、多くの場合、特定の分野向けにカスタマイズされている。
• 非構造化データデータベースは、一般的なデータベースに自然かつ簡単に適合しない多様なオブジェクトを、管理可能かつ保護された方法で格納することを目的としている。これには、電子メールメッセージ、文書、雑誌、マルチメディアオブジェクトなどが含まれることがある。オブジェクトの中には高度に構造化されたものもあるため、この名称は誤解を招く可能性がある。しかし、可能性のあるオブジェクトの集合全体が、あらかじめ定義された構造化フレームワークに適合するものではない。現在、ほとんどの既製のDBMSは、さまざまな方法で非構造化データをサポートしており、新しい専用DBMSも登場している。

データベース管理システム

ConnollyとBeggは、データベース管理システム（DBMS）を「ユーザーがデータベースを定義、作成、保守、およびアクセスを制御できるようにするソフトウェアシステム」と定義している。DBMSの例として、MySQL、PostgreSQL、Microsoft SQL Server、Oracle Database、Microsoft Accessがあげられる。

DBMSの頭文字は、基盤となるデータベースモデルを示して拡張されることがあり、リレーショナル型はRDBMS、オブジェクト(指向)型はOODBMS、オブジェクトリレーショナル型はORDBMSと呼ばれる。また、分散型データベース管理システムを表すDDBMSなど、他の特性を表すように拡張することができる。

DBMSが提供する機能は非常に多様である。中心的な機能は、データの保存、検索、更新である。コッドは、本格的な汎用DBMSが提供すべき機能およびサービスとして、次のようなものを提案した。

• データの保存、検索、更新
• メタデータを記述した、ユーザーがアクセス可能なカタログまたはデータディクショナリ
• トランザクションと並行処理のサポート
• データベースが破損した場合に復旧するための機能
• データへのアクセス時および更新時の承認のサポート
• 遠隔地からのアクセスサポート
• データベース内のデータが特定の規則に従うことを保証するための制約の適用

また、DBMS は、インポート、エクスポート、監視、デフラグメント、分析ユーティリティなど、データベースを効果的に管理するために必要な一連のユーティリティを提供することも、一般に期待されている。データベースとアプリケーション・インタフェースの間で相互作用するDBMSの中心部分は、データベース・エンジンと呼ばれることもある。

多くのDBMSは、データベースが使用できるサーバ上のメインメモリの最大量など、静的または動的に調整可能な構成パラメータを持っている。手動構成する量を最小限に抑える傾向があり、組み込みデータベースのような場合は、ゼロ管理を目標とする要求が最も重要である。

大規模なエンタープライズDBMSでは、サイズや機能が増大する傾向があり、その生涯を通じて数千人年の開発努力が費やされることがある。

初期のマルチユーザーDBMSでは、一般的に、アプリケーションを同じコンピュータ上で動作させ、コンピュータ端末または端末エミュレーションソフトウェアを通じてアクセスすることしかできなかった。クライアント・サーバー・アーキテクチャは、アプリケーションはクライアントのデスクトップ上にあり、サーバー上に存在するデータベースが処理を分散できるように開発された。これが進化して、アプリケーションサーバーやウェブサーバーを組み込んだ多層アーキテクチャとなり、エンドユーザーインターフェイスはウェブブラウザーを介してアクセスし、データベースは隣接する層に直接接続されるのみとなった。

汎用DBMSは、公開のアプリケーション・プログラミング・インタフェース（API）と、オプションでSQLなどのデータベース言語用のプロセッサを提供して、データベースと対話し操作するアプリケーションを作成できるようにする。特殊用途のDBMSは、プライベートなAPIを使用し、特別にカスタマイズして単一のアプリケーションにリンクされることがある。たとえば、電子メールシステムは、メッセージの挿入、削除、添付ファイルの処理、ブロックリストの検索、メッセージと電子メールアドレスの関連付けなど、汎用DBMSの機能の多くを実行するが、これらの機能は電子メールの処理に必要なものに限定されている。

アプリケーション

→詳細は「データベースアプリケーション」を参照

データベースとの外部相互作用は、DBMSと接続するアプリケーション・プログラムを介して行われる。アプリケーションは、ユーザーが文字的または視覚的にSQLクエリを実行できるデータベースツールから、情報を格納し検索するためにデータベースを使用するWebサイトまで、多岐にわたる。

アプリケーション・プログラム・インタフェース

プログラマーは、アプリケーション・プログラミング・インタフェース（API）またはデータベース言語を介して、データベース（データソースと呼ばれることもある）との相互対話をコーディングする。選択された特定のAPIや言語は、DBMSによって直接的にサポートされるか、またはプリプロセッサまたはブリッジングAPIを介して間接的にサポートされる必要がある。APIの中にはデータベースに依存しないことを目的とするものもあり、ODBCはそのよく知られた例である。その他の一般的なAPIには、JDBCやADO.NETがある。

データベース言語

データベース言語は、次のような作業を可能とする特殊用途の言語であり、部分言語として区別されることもある。

• データ制御言語（DCL）- データへのアクセスを制御する。
• データ定義言語（DDL）- テーブルの作成、変更、削除などのデータ型の定義や、テーブル間の関係を定義する。
• データ操作言語（DML）- 発生データの挿入、更新、削除などの作業を実行する。
• データ問い合わせ言語（DQL）- 情報を検索し、派生情報を導出できる。

データベース言語は、特定のデータモデルに特化した言語である。著名な例として次のものがある。

• SQLは、データ定義、データ操作、およびクエリ（問い合わせ）の役割を1つの言語で兼ね備えたものである。SQLは、コッドによって説明されたリレーショナルモデルとはからいくつかの点で異なっているが（たとえば、テーブルの行と列を並び替えることができる）、リレーショナルモデルの最初の商用言語の1つである。SQLは1986年に米国規格協会（ANSI）標準となり、1987年に国際標準化機構（ISO）標準となった。この標準はそれ以降も定期的に強化されており、すべての主流の商用リレーショナルDBMSによってサポートされている（適合性の程度はさまざまである）。
• OQLは、オブジェクトモデル言語標準である（Object Data Management Groupによる）。これは、JDOQLやEJB QLなどの新しいクエリ言語の設計に影響を与えている。
• XQueryは、MarkLogicやeXistなどのXMLデータベースシステム、OracleやDb2などのXML機能を備えたリレーショナルデータベース、およびSaxonなどのインメモリXMLプロセッサで実装された標準のXMLクエリ言語である。
• SQL/XMLは、XQueryとSQLを組み合わせたものである。

データベース言語には、次のような機能を組み込んでいるものもある。

• DBMS固有の構成やストレージエンジンの管理。
• クエリ結果を変更するための計算。たとえば、カウント、合計、平均、並び替え、グループ化、クロスリファレンス。
• 制約の適用（例: 自動車データベースでは、1台の車ごとに1種類のエンジンのみ許可される）。
• プログラマーの便宜のために、クエリ言語のアプリケーション・プログラミング・インターフェース版。

ストレージ

→詳細は「記憶装置」および「データベースエンジン」を参照

データベースストレージは、データベースの物理的な実体の格納庫である。これは、データベースアーキテクチャの「内部（物理）レベル」を構成する。また、必要に応じて「内部レベル」から「概念レベル」や「外部レベル」を再構築するために必要なすべての情報（たとえばメタデータ、「データに関するデータ」、内部データ構造など）も含んでいる。デジタル・オブジェクトとしてのデータベースには、データ、構造、セマンティクス（意味）の3つの層からなる情報が含まれ、保存する必要がある。長期間に渡ってデータベースを保存し、長持ちさせるために、3つの層すべてを適切に保存する必要がある。データを永続的ストレージに保存するのは、一般に、データベースエンジン（別名「ストレージエンジン」）の責任である。DBMSは通常、基盤となるオペレーティングシステムを通じてアクセスするが（多くの場合、オペレーティングシステムのファイルシステムを、ストレージ配置の仲介役として使用する）、ストレージの特性と構成設定はDBMSの効率的な運用に極めて重要であるため、データベース管理者によって密接に管理される。DBMSは、その運用中に、常に数種類のストレージ（メモリや外部ストレージ）にデータベースを常駐させている。データベースのデータと、追加の必要な情報（おそらく非常に大量にある）は、ビット列に符号化される。データは通常、概念レベルや外部レベルでの見え方とは全く異なる構造でストレージ内に存在するが、ユーザーやプログラムが必要とするとき、または必要な情報の追加形式をデータから計算するとき（例: データベースに問い合わせる時）、これらのレベルの再構築を（可能な限り）最適化するような方法で格納される。

DBMSの中には、データの格納に用いる文字エンコーディングを指定できるものがあり、同じデータベースで複数のエンコーディングを使用することができる。

データモデルをシリアル化し、選ばれた媒体に書き込めるようにするために、ストレージエンジンは、さまざまな低レベルのデータベースストレージ構造を使用する。性能を向上させるために、インデックス作成などの手法を使用することもある。従来のストレージは行指向であるが、列指向データベースや相関データベース (en:英語版) もある。

マテリアライズド・ビュー

→詳細は「マテリアライズド・ビュー」を参照

性能を向上させるためにストレージを冗長化することがよくある。一般的な例は、頻繁に必要とされる外部ビュー（external view）や、クエリ結果から構成されるマテリアライズド・ビュー（materialized view）の保存である。このようなビューを保存することで、必要になるたびに計算する費用を節約することができる。マテリアライズド・ビューの欠点は、元の更新されたデータベースデータと同期を維持するためにビューを更新する際に発生するオーバーヘッドと、ストレージの冗長化にかかる費用である。

レプリケーション

→詳細は「データベースレプリケーション」を参照

データベースは、データの可用性を向上させるために、データベース・オブジェクトの複製（1つ以上のレプリケーション）によるストレージ冗長性を採用することがある。これによって、同じデータベース・オブジェクトに複数のエンドユーザーが同時アクセスした場合の性能を向上させ、また、分散データベースに部分的な障害が発生した場合の回復力を提供する。複製されたオブジェクトの更新には、オブジェクトのコピー間で同期される必要がある。多くの場合、データベース全体が複製される。

セキュリティ

→詳細は「データベースセキュリティ」を参照

データベース・セキュリティは、データベースの内容、その所有者、およびそのユーザーを保護するためのあらゆる側面を扱う。その範囲は、意図的な不正なデータベースの使用から、権限のないエンティティ（たとえば、人やコンピュータプログラムなど）による意図しないデータベースへのアクセスまで、さまざまな保護に及ぶ。

データベースアクセス制御は、データベース内のどの情報に誰が（人間または特定のコンピュータプログラム）アクセスを許可されるかを制御することを扱う。その情報には、特定のデータベースオブジェクト（例: レコード種類、特定レコード、データ構造）、特定のオブジェクトに対する特定の計算（例: クエリ種類、特定のクエリ）、または前者に対する特定のアクセス経路の使用（例: 情報にアクセスするために特定のインデックスまたは他のデータ構造の使用）が含まれる。データベースのアクセス制御は、データベース所有者から特別に許可された人員によって、保護された専用のセキュリティDBMSインタフェースを用いて設定される。

アクセス制御の管理は、個人別に直接行うことも、個人と特権をグループに割り当てることも、（最も精巧なモデルでは）個人やグループにロール（役割）を割り当ててからロールに権限を付与することもできる。データセキュリティは、権限のないユーザーによるデータベースの閲覧や更新を阻止する。パスワードを使用すると、ユーザーはデータベース全体、または「サブスキーマ」と呼ばれる一部分へのアクセスを許可される。たとえば、従業員データベースには個々の従業員に関するすべてのデータを含めていても、あるグループのユーザーには給与データのみの閲覧を許可し、別のグループには職歴と医療データのみアクセスを許可することが可能である。DBMSがデータベースの入力、更新、問い合わせを対話的に行う方法を提供している場合、この機能によって個人データベースを管理することができる。

一般にデータセキュリティは、特定のデータチャンク（data chunk、塊）を物理的に保護すること（すなわち破損、破壊、削除から。物理的セキュリティを参照）、または、データチャンクやその一部を意味のある情報に変換すること（例: それらが構成するビット列を見て、特定の有効なクレジットカード番号を決定する。データ暗号化を参照）の両方を扱う。

変更およびアクセスのロギングは、誰がどの属性にアクセスしたか、何が変更されたか、そしていつ変更されたかを記録する。ロギングサービスは、アクセスの発生や変更の記録を保持することで、後でフォレンジックデータベース監査を行うことを可能にする。場合によっては、データベースレベルで記録するのではなく、アプリケーションレベルのコードで変更を記録することもある。セキュリティ違反の検出を試みるために監視を設定することもできる。データベース・セキュリティには多くの利点があるため、組織はこれに真剣に取り組む必要がある。組織は、ファイアウォール内への侵入、ウィルスの蔓延、ランサムウェアなどのセキュリティ違反やハッキング行為から守られる。これは、企業において、いかなる理由があっても部外者と共有することが許されない、重要な情報を保護するために役に立つ。

トランザクションと同時平行

→詳細は「並行性制御」を参照

データベース・トランザクションは、クラッシュ（障害）からの復旧後に、ある程度の耐障害性とデータ完全性を導入するために使用することができる。データベーストランザクションは通常、データベースに対する一連の操作（データベースオブジェクトの読み込み、書き込み、ロックの取得や解放など）をカプセル化した作業の単位であり、データベースやその他のシステムでサポートされている抽象概念である。各トランザクションには、どのプログラム／コードの実行がそのトランザクションに含まれるかという点で、明確に定義された境界がある（トランザクションの設計者が、特別なトランザクションコマンドで決定する）。

ACIDという頭字語は、データベーストランザクションの理想的な特性である、原子性（atomicity）、一貫性（consistency）、分離性（isolation）、永続性（durability）を表している。

移行

→「データ移行#データベース移行」も参照

あるDBMSで構築されたデータベースは、別のDBMSに移植できない（つまり、別のDBMSでは実行できない）。しかし、状況によっては、あるDBMSから別のDBMSにデータベースを移行（database migration）するのが望ましい場合がある。その理由は、主に経済的（DBMS によって総所有コスト（TCO）が異なる）、機能的、および運用的（DBMSによって機能が異なることがある）である。移行には、あるDBMSの種類から別の種類へデータベースを変換することも含まれる。この変換では、（可能であれば）データベース関連のアプリケーション（つまり、関連するすべてのアプリケーションプログラム）をそのまま維持する必要がある。したがって、データベースの概念レベルおよび外部レベルのアーキテクチャは、変換時に維持する必要がある。また、アーキテクチャの内部レベルのいくつかの側面も維持されることが望まれる場合もある。複雑または大規模なデータベースの移行は、それ自体が複雑で費用のかかる（1度きりの）プロジェクトになる可能性があるので、移行を決定するときはその点を考慮する必要がある。これは、特定のDBMS間の移行を支援するツールが存在する可能性があるのにも関わらない。一般に、DBMSベンダーは、他の普及しているDBMSからデータベースをインポートするツールを提供している。

構築、保守、およびチューニング

→詳細は「データベースチューニング」を参照

アプリケーションのデータベースを設計したら、次の段階はデータベースの構築である。通常、この用途で用いるために、適切な汎用DBMSを選択することができる。DBMSは、データベース管理者が必要なアプリケーションのデータ構造をDBMSの各データモデルに準じて定義するために必要なユーザーインタフェースを提供する。その他のユーザーインタフェースは、必要なDBMSパラメータ（セキュリティ関連、ストレージ割り当てパラメータなど）を選択するために用いられる。

データベースの準備が整うと（データ構造およびその他の必要なコンポーネントがすべて定義される）、通常は、運用を開始する前にアプリケーションの初期データを入力する（データベースの初期化は、通常は別プロジェクトとされ、多くの場合、一括挿入をサポートする専用のDBMSインタフェースを用いる）。場合によっては、アプリケーションのデータを持たない状態でデータベースが稼働し、その運用を経てデータが蓄積されることもある。

データベースを作成し、初期化し、データを入力した後は、データベースを維持する必要がある。たとえば、より良い性能を得るために、さまざまなデータベース・パラメータを変更し、データベースをチューニングする必要があるかもしれない。あるいは、アプリケーションの機能を追加するために、アプリケーションのデータ構造を変更または追加し、新しい関連アプリケーションプログラムを作成するかもしれない。

バックアップと復元

→詳細は「バックアップ」を参照

場合によっては、データベースを以前の状態に戻すことが必要となる（たとえばソフトウェアの誤りが原因でデータベースが破損していることが判明した場合や、誤ったデータで更新された場合など、さまざまな理由が考えられる）。そのために、バックアップ操作が時々または継続的に実施され、それぞれの望ましいデータベースの状態（すなわち、データ値とデータベースのデータ構造への埋め込み）が専用のバックアップファイルに保持される（これを効果的に行うための多くの技術が存在する）。データベース管理者がデータベースをこの状態に戻すと決めたとき（たとえば、データベースがこの状態にあった時、所望の時点を指定する）、これらのファイルをその状態を復元するために使用する。

静的解析

ソフトウェア検証のための静的解析技術は、クエリ言語の領域にも適用することができる。特に、抽象解釈フレームワークは、適切な近似技術をサポートする方法として、リレーショナルデータベースのクエリ言語の分野に拡張されている。クエリ言語のセマンティクスは、データの具体的な領域（ドメイン）を適切に抽象化することによって調整することができる。リレーショナルデータベースシステムの抽象化は、特に、細粒度アクセス制御や、電子透かしなどのセキュリティ分野で、多くの興味深い応用がある。

その他の機能

DBMSのその他の機能として、次のようなものもあげられる。

• データベースログ - これは実行された機能の履歴を残すのに役立つ。
• グラフィックコンポーネント - 特にデータウェアハウスシステムで、グラフやチャートを作成するためのもの。
• クエリオプティマイザ - すべてのクエリに対してクエリを最適化し、クエリ結果を効率的に得るための実行計画（手順の部分的な順序（ツリー））を選択する。特定のストレージエンジンに特化することもある。
• データベース設計、アプリケーションプログラミング、アプリケーションプログラムの保守、データベース性能分析および監視、データベース構成監視、DBMSハードウェア構成（DBMSや関連データベースはコンピュータ、ネットワーク、ストレージ装置にまたがる場合がある）および関連するデータベースマッピング（特に分散DBMS）、ストレージ割り当てとデータベースレイアウトの監視、ストレージ移行のためのツールまたはフック。

データベース管理とソース管理のために、ビルド、テスト、デプロイメントフレームワークに、これらの中心機能をすべて組み込んだ単一システムを求める声はますます高まっている。ソフトウェア業界における別の進化を借りて、そうした製品を「データベース用DevOps」として提供する企業もある。

設計とモデリング

→詳細は「データベース設計」を参照

データベース設計の過程を示す流れ図。1.まずビジネス上の用途や知識から概念データモデルを作成し、2.次にデータベース内のデータ構造を反映した論理データモデルを作成し、3.最後に特定のRDBMSに依存した決定に基づく物理データベースを作成する。

データベース設計者の最初の作業は概念データモデル (en:英語版) の作成で、データベースに保持する情報の構造を反映する。そのための一般的な方法は、描画ツールを用いて実体関連モデルを作成することが多い。統一モデリング言語（UML）の使用は、もう一つのよく知られた方法である。出来のよいデータモデルは、モデル化される外界の可能な状態を正確に反映する。たとえば、人々が複数の電話番号を持つことができる場合、その情報を取得することが可能となる。優れた概念データモデルを設計するには、アプリケーションの領域を十分に理解する必要がある。それには、一般的に、組織が関心を持っていることについて深い問いを立てる必要がある。たとえば「顧客は発注先にもなり得るのか?」、あるいは「ある製品が2種類の包装形態で販売されている場合、それらは同じ製品か、それとも異なる製品なのか?」、あるいは「飛行機がニューヨークからフランクフルト経由でドバイまで飛ぶ場合、それは1便か2便か（または3便か）?」のような質問をする。これらの質問に対する回答によって、エンティティ（顧客、製品、フライト、フライト区間）に使用される用語の定義、およびそれらの関係や属性を確立する。

概念データモデルを作成する過程で、ビジネスプロセスからの入力や、組織内のワークフロー分析からの入力が必要な場合がある。これによって、データベースにどのような情報が必要で、何を省略できるかを特定することができる。たとえば、データベースに現在のデータだけでなく、過去の履歴データも保持する必要があるかどうかを決定するのに役立つ。

ユーザーが満足できる概念データモデルを作成したら、次の段階では、これをデータベース内の関連データ構造を実装するスキーマに変換する必要がある。この過程は、しばしば論理データベース設計と呼ばれ、スキーマの形で表現された論理データモデルを作成する。概念データモデルがデータベース技術の選択と関係しないのに対し（少なくとも理論的には）、論理データモデルは、選択したDBMSがサポートする特定のデータベースモデルの観点で表現される。（データモデルとデータベースモデルという用語はしばしば同じ意味で用いられるが、この記事では特定のデータベースの設計を「データモデル」、その設計を表現するために用いられるモデリング表記を「データベースモデル」とそれぞれ呼ぶ。）

汎用データベースで最も普及しているデータベースモデルはリレーショナルモデル、より正確には、SQL言語で表現されるリレーショナルモデルである。このモデルを用いて論理データベースを設計する過程では、正規化と呼ばれる系統的アプローチが用いられる。正規化の目的は、挿入、更新、削除の一貫性を自然に維持することで、おのおのの基本的「事実」を一箇所にのみ記録することでなされる。

データベース設計の最終段階では、特定のDBMSに依存する性能、スケーラビリティ、回復、セキュリティなどに影響する決定をする。これはしばしば「物理データベース設計」と呼ばれ、物理データモデルを作成する。この段階での重要な目標はデータの独立性である。これは、性能を最適化するために行われた決定を、エンドユーザーやアプリケーションから見えないようにすることを意味する。データの独立性には2つのタイプがあり、物理的なデータ独立性と論理的なデータ独立性である。物理設計は主に性能要件によって推進され、予想される作業負荷とアクセスパターンに関する十分な知識と、選択したDBMSが持つ機能についての深い理解を必要とする。

物理データベース設計のもうひとつの側面はセキュリティである。これには、データベースオブジェクトへのアクセス制御を定義することと、データ自体のセキュリティレベルとメソッド（手順）の定義の両方を含んでいる。

モデル

→詳細は「データベースモデル」を参照

5種類のデータベースモデルを切り貼りした図。

データベースモデルとは、データベースの論理構造を決定するデータモデルの一種で、データをどのように格納、整理、操作するかの根本を規定するものである。データベースモデルの最も一般的な例は、テーブルベースの形式を使用するリレーショナルモデル（またはリレーションを近似したSQL）である。

データベースの一般的な論理データモデルを次にあげる。

• ナビゲーショナル・データベース
  • 階層型データモデル
  • ネットワーク型データモデル
  • グラフデータベース
• リレーショナルモデル
• 実体関係モデル
  • 拡張実体関係モデル
• オブジェクトモデル
• ドキュメント型モデル  (en:英語版) 
• 実体-属性-値モデル
• スタースキーマ

オブジェクトリレーショナルデータベースは、この2つの関連する構造を組み合わせたものである。

物理データモデルを次にあげる。

• 転置インデックス
• フラットファイル

その他、次のようなモデルがある。

• 多次元モデル
• 配列モデル
• 多値モデル

特定の種類のデータ用に最適化された特殊モデルがある。

• XMLデータベース
• セマンティックモデル
• コンテンツストア
• イベントストア
• 時系列モデル

外部、概念、内部ビュー

→詳細は「三層スキーマ方式」を参照

データに対する従来の捉え方は、ユーザ視点とコンピュータ視点という、2つの異なる視点からデータ定義することに焦点を当ててきた。アプリケーションと物理的に保存されたデータが直接に対応した結果、アプリケーション数の増加にともないデータの冗長性や整合性の問題が起こりやすかった。

三層スキーマ方式は、データを単一に定義する概念レベルを介すことで、データのアクセス方法(外部レベル)やデータの物理的な保存方法(内部レベル)に依存しないデータ提供を可能にするものである。

データベース管理システムは、データベースのデータに対して三層のビューを提供する。

• 外部レベル（external level）では、エンドユーザーの各グループがデータベース内のデータ構成をどのように見るかを定義する。1つのデータベースは、外部レベルで任意の数のビューを持つことができる。
• 概念レベル（conceptual level）では、さまざまな外部レベルのビューを、適合性のある単一の大域的ビューに統一化する。概念レベルのビューは、すべての外部ビューを組み立てる。それは、データベースのさまざまなエンドユーザーの範囲外であり、むしろデータベースアプリケーション開発者やデータベース管理者にとって興味対象である。
• 内部レベル（internal level）または物理レベル（physical level）とは、DBMS内におけるデータの内部編成のことである。これは費用、性能、スケーラビリティ、その他の運用上の事項に関与している。このレベルでは、データの記憶領域配置を扱い、性能を向上させるためにインデックス（索引）などの格納構造を用いる。冗長性に対する性能上の正当性が認められる場合は、一般的なデータから計算された個々のビュー（マテリアライズド・ビュー）のデータを格納することもある。すべての活動において、全体的な性能を最適化するために、すべての外部ビューの性能要件（競合する可能性のある）の間でバランスをとる。

データの概念ビュー（または論理ビュー）および物理ビュー（または内部ビュー）は、通常、1つしかないが、さまざまな外部ビューはいくつでも存在することができる。これにより、ユーザーは、技術的あるいは処理的な視点からではなく、よりビジネスに関連した視点からデータベース情報を見ることができるようになる。たとえば、企業の財務部門は会社の経費の一部として全従業員の支払明細を必要とするが、人事部門の関心事である従業員に関する明細は必要ない。このように、部門によって、企業データベースには異なるビューが必要となる。

三層データベース・アーキテクチャは、リレーショナルモデルの主要な初期推進力の1つであったデータの独立性の概念に関連している。この考え方は、あるレベルで行われた変更は、より高いレベルのビューに影響を与えないというものである。たとえば、内部レベルの変更は、概念レベルのインタフェースを使用して記述されたアプリケーションプログラムには影響しないので、性能を向上させるために物理的変更を加えてもその影響を軽減することができる。

概念ビューは、内部ビューと外部ビューの間に間接的なレベルを提供する。一方では、異なる外部ビュー構造に依存しないデータベースの共通ビューを提供し、また他方では、データがどのように格納され管理されるかという詳細（内部レベル）を抽象化する。原則として、すべてのレベルの、さらにはすべての外部ビューは、異なるデータモデルで表現することができる。実際には通常、特定のDBMSは外部レベルと概念レベルの両方で同じデータモデルを使用する（例: リレーショナルモデル）。内部レベルは特定のDBMSの内側に隠されており、（その実装にも依存するが）異なるレベルの詳細が要求され、独自の種類のデータ構造型が用いられる。

外部、概念、および内部レベルを分離することは、21世紀のデータベースを支配するリレーショナルデータベースモデルの実装における大きな特徴であった。

研究

データベース技術は、1960年代から、学界や企業の研究開発グループ（例: IBM基礎研究所）の両方で活発な研究課題となっている。研究活動には、理論やプロトタイプの開発が含まれる。注目すべき研究課題には、モデル、アトミックトランザクションの概念、関連する並行性制御技術、クエリ言語とクエリ最適化手法、RAIDがある。

データベース研究分野には、いくつかの専門学術誌や（例: ACM Transactions on Database Systems-TODS、Data and Knowledge Engineering-DKE）、年次会議（例: ACM SIGMOD、ACM PODS、VLDB、IEEE ICDE）がある。

日本の学会としては、日本データベース学会があげられる。

参照項目

• データベース管理ツールの比較
• オブジェクトデータベース管理システムの比較
• オブジェクト・リレーショナルデータベース管理システムの比較
• リレーショナルデータベース管理システムの比較
• データ階層
• データバンク
• データストア
• データベース理論
• データベーステスト
• データベース中心アーキテクチャ
• フラットファイルデータベース

出典

• Bachman, Charles W. (1973). “The Programmer as Navigator”. Communications of the ACM 16 (11): 653–658. doi:10.1145/355611.362534. 
• Beynon-Davies, Paul (2003). Database Systems (3rd ed.). Palgrave Macmillan. ISBN 978-1403916013 
• “SQL Fundamentals”. Databases. About.com (2005年). 22 February 2009時点のオリジナルよりアーカイブ。28 January 2009閲覧。
• Childs, David L. (1968a). Description of a set-theoretic data structure (PDF) (Technical report). CONCOMP (Research in Conversational Use of Computers) Project. University of Michigan. Technical Report 3。
• Childs, David L. (1968b). Feasibility of a set-theoretic data structure: a general structure based on a reconstituted definition (PDF) (Technical report). CONCOMP (Research in Conversational Use of Computers) Project. University of Michigan. Technical Report 6。
• Chong, Raul F.; Wang, Xiaomei; Dang, Michael; Snow, Dwaine R. (2007). “Introduction to DB2”. Understanding DB2: Learning Visually with Examples (2nd ed.). ISBN 978-0131580183. http://www.ibmpressbooks.com/articles/article.asp?p=1163083 17 March 2013閲覧。 
• Codd, Edgar F. (1970). “A Relational Model of Data for Large Shared Data Banks”. Communications of the ACM 13 (6): 377–387. doi:10.1145/362384.362685. http://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf. 
• Connolly, Thomas M.; Begg, Carolyn E. (2014). Database Systems – A Practical Approach to Design Implementation and Management (6th ed.). Pearson. ISBN 978-1292061184 
• Date, C. J. (2003). An Introduction to Database Systems (8th ed.). Pearson. ISBN 978-0321197849. https://archive.org/details/introductiontoda0000date 
• Halder, Raju; Cortesi, Agostino (2011). “Abstract Interpretation of Database Query Languages”. Computer Languages, Systems & Structures 38 (2): 123–157. doi:10.1016/j.cl.2011.10.004. ISSN 1477-8424. http://www.dsi.unive.it/~cortesi/paperi/CL2012.pdf. 
• Hershey, William; Easthope, Carol (1972). A set theoretic data structure and retrieval language. Spring Joint Computer Conference, May 1972. ACM SIGIR Forum. Vol. 7, no. 4. pp. 45–55. doi:10.1145/1095495.1095500。
• Nelson, Anne Fulcher; Nelson, William Harris Morehead (2001). Building Electronic Commerce: With Web Database Constructions. Prentice Hall. ISBN 978-0201741308 
• North, Ken (10 March 2010). “Sets, Data Models and Data Independence”. Dr. Dobb's. オリジナルの24 October 2010時点におけるアーカイブ。. https://web.archive.org/web/20121024064523/http://www.drdobbs.com/database/sets-data-models-and-data-independence/228700616. 
• Tsitchizris, Dionysios C.; Lochovsky, Fred H. (1982). Data Models. Prentice–Hall. ISBN 978-0131964280. https://archive.org/details/datamodels00tsic/page/13/mode/1up 
• Ullman, Jeffrey; Widom, Jennifer (1997). A First Course in Database Systems. Prentice–Hall. ISBN 978-0138613372. https://archive.org/details/firstcourseindat00ullm 
• Wagner, Michael (2010), SQL/XML:2006 – Evaluierung der Standardkonformität ausgewählter Datenbanksysteme, Diplomica Verlag, ISBN 978-3836696098 

推薦文献

• 増永良文『データベース入門 [第2版]』サイエンス社、2021年2月10日。ISBN 978-4-7819-1500-5。 
• 増永良文『リレーショナルデータベース入門 [第3版]』サイエンス社、2017年2月。ISBN 978-4-7819-1390-2。 
• Ling Liu and Tamer M. Özsu (Eds.) (2009). "Encyclopedia of Database Systems, 4100 p. 60 illus. ISBN 978-0-387-49616-0.
• Gray, J. and Reuter, A. Transaction Processing: Concepts and Techniques, 1st edition, Morgan Kaufmann Publishers, 1992.
• Kroenke, David M. and David J. Auer. Database Concepts. 3rd ed. New York: Prentice, 2007.
• Raghu Ramakrishnan and Johannes Gehrke, Database Management Systems
• Abraham Silberschatz, Henry F. Korth, S. Sudarshan, Database System Concepts
• Lightstone, S.; Teorey, T.; Nadeau, T. (2007). Physical Database Design: the database professional's guide to exploiting indexes, views, storage, and more. Morgan Kaufmann Press. ISBN 978-0-12-369389-1 
• Teorey, T.; Lightstone, S. and Nadeau, T. Database Modeling & Design: Logical Design, 4th edition, Morgan Kaufmann Press, 2005. ISBN 0-12-685352-5

外部リンク

• DB File extension - DB拡張子を持つファイルに関する情報（英語）