コンピューティングにおいて、データベース（）は、電子的に保存され、アクセスできる組織化されたデータの集合である。実メモリに保存されるもの、CSVなどのファイルに保管される物、OSのファイルシステムなどから、後述のデータベース管理システムを使った大規模なものまである。
小規模なデータベースはOSのファイルシステム上にファイルとして保存されるが、大規模なデータベースはOSに依存しない低レベルなフォーマットで外部記憶装置に保存される。またコンピュータ・クラスターまたはクラウドストレージで保存される。データベース設計に関わる分野は多岐にわたり、データモデリング、効率的なデータ表現と保存、クエリ言語、機密データのやプライバシー、同時アクセスとフォールトトレランスのサポートを含む分散コンピューティングの課題など、形式技術と実用的な考慮事項に及ぶ。
データベース管理システム（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
データベースという言葉が登場したのは、1960年代半ば以降に、直接アクセスストレージ（ディスクやドラム）が利用できるようになった時期と重なる。この用語は、過去のテープベースのシステムとは対照的に、日常のバッチ処理ではなく、対話的な共有での利用を可能にすることを意味した。オックスフォード英語辞典では、カリフォルニアのが1962年に発表した報告書を、特定の技術的な意味で「データベース」という用語を初めて使用したものとして引用している 。
コンピュータの速度と機能が向上するに伴い、多くの汎用データベースシステムが登場し、1960年代半ばには多くのこうしたシステムが商用化されるようになった。標準化への関心が高まり、そうした製品の一つであるIntegrated Data Store（IDS）の制作者であるチャールズ・バックマンが、COBOLの作成と標準化を担当したグループCODASYL内にデータベース・タスクグループを設立した。1971年、データベース・タスクグループは、一般に「CODASYLアプローチ」として知られるようになった彼らの標準を提供し、まもなくこのアプローチに基づいた多くの商用製品が市場に参入した。
CODASYLアプローチ方式は、アプリケーションに対し、大規模ネットワーク内に形成された連結データセットを移動する機能を提供した。アプリケーションは、3つの方法のうちのいずれかによってレコードを見つけることができる。
主キーの使用（CALCキーとして知られ、典型的にはハッシュによって実装される）。 あるレコードから別のレコードへの関係（セットと呼ばれる）の移動。 すべてのレコードを順番にスキャンする。 その後のシステムで、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やの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）という数学用語を使ってモデルを定義した。現在よく知られているこれらの用語は、初期の実装に由来するものである。コッドは後に、実際の実装が、モデルの基礎となった数学的な基礎から逸脱する傾向にあることを批判した。
テーブル間の関係を表すために、ディスクアドレスではなく主キー（ユーザー指向の識別子）を使用したのは、主に2つの動機があった。エンジニアリングの観点からは、費用がかかるデータベースの再編成をすることなく、テーブルの再配置やサイズ変更を可能とした。しかし、コッドは、セマンティクス（意味）の違いにより強い興味を持っていた。明示的な識別子を使用することで、純粋な数学的定義で更新操作を定義することが容易になり、一階述語論理という確立した学問分野の観点でクエリ操作を定義できるようになった。これらの操作は純粋な数学的性質があるため、クエリ最適化の基礎をなす証明可能な正しい方法でクエリを書き換えることが可能となる。テーブル間の接続は明示的ではなくなったが、階層型モデルやネットワーク型モデルと比較して表現力が損なわれることはない。
階層型モデルやネットワーク型モデルでは、レコードが複雑な内部構造を持つことが許容された。たとえば、ある従業員の給与履歴は、従業員レコードの中の「繰り返しグループ」として表わされることがある。リレーショナルモデルでは、正規化の過程によって、そのような内部構造は、論理キーのみで結合された複数のテーブルに保持されたデータで置き換えられた。
たとえば、データベースシステムの一般的な使い方として、ユーザーに関する情報、名前、ログイン情報、さまざまな住所や電話番号を突き止めることがあげられる。ナビゲーショナル方式では、これらのデータはすべて1つの可変長レコード内に格納される。リレーショナル方式では、そのデータは（たとえば）ユーザーテーブル、アドレステーブル、電話番号テーブルに「正規化（normalize）」される。これらの任意のテーブル内には、実際に住所や電話番号が提供された場合のみ、レコードが作成される。
コッドは、（ディスクアドレスではなく）論理的な識別子を使用して行／レコードを識別するだけでなく、アプリケーションが複数のレコードからデータを組み立てる方法も変更した。アプリケーションがリンクを移動して1レコードずつデータを収集することを要求するのではなく、アプリケーションは、宣言型のクエリ言語を使用して（どのようにデータを見つけるかというアクセス経路ではなく）どのようなデータが必要なのかを表現する。データへの効率的なアクセス経路を見つけるのは、アプリケーションのプログラマーではなく、データベース管理システムの責任となった。クエリ最適化（query optimization）と呼ばれるこの過程は、クエリが数学的論理の観点で表現されているという事実に基づいている。
コッドの論文は、バークレー校のとマイケル・ストーンブレーカーの二人によって着目された。彼らは、地理データベースプロジェクトにすでに割り当てられていた資金と、コードを作成する学生プログラマーを使って、INGRESと呼ばれるプロジェクトを開始した。INGRESは、1973年の初頭に最初のテスト製品を提供し、1979年には一般に広く使用されるようになった。INGRESは、のためのQUELと呼ばれる「言語（language）」の使用を含め、多くの点でIBM System Rと類似していた。時の経過とともに、INGRESは新しい標準SQLに移行していった。
IBM自身は、リレーショナルモデルのテスト実装であると、製品版であるの開発を一度行ったが、いずれも現在は廃止されている。Honeywellは、Multics用のを開発したが、現在ではとの2つの新しい実装が存在する。「リレーショナル」と呼ばれる他のDBMSの実装のほとんどは、実際にはSQL DBMSである。
1970年、ミシガン大学は、の集合論的データモデルに基づくの開発を開始した。MICROは、非常に大きなデータセットを管理するために、米国労働省、米国環境保護庁、アルバータ大学、ミシガン大学、ウェイン州立大学の研究者によって使用された。これは、を使用するIBMメインフレームコンピューター上で稼働した。このシステムは1998年まで稼動し続けた。
統合型アプローチ
1970年代から1980年代にかけ、ハードウェアとソフトウェアを統合したデータベースシステムの構築が試みられた。その根底にある理念は、このような統合が、より高い性能をより低い費用で提供できるというものである。その例として、IBM System/38、Teradataの初期の製品、およびのデータベースマシンがあげられる。
また、データベース管理をハードウェアでサポートするアプローチには、のアクセラレータという、プログラム可能な検索機能を持つハードウェアディスクコントローラーがあった。しかし、汎用コンピュータの急速な発展と進歩に、データベース専用機が追いつくことができなかったため、長期的にはこれらの取り組みは概して失敗に終わった。こうしたことから、現今のほとんどのデータベースシステムは、汎用ハードウェア上で動作するソフトウェアシステムであり、汎用のコンピュータとデータストレージを使用している。しかし、この着想は今もなお、やOracle （）など一部の企業によって特定の用途で追求されている。
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年代半ばにウプサラ大学でが開発された。1984年、このプロジェクトは独立した企業に統合された。
1976年に登場した実体関係モデルは、それまでのリレーショナルモデルよりも馴染みのある記述法を重視したもう一つのデータモデルであり、データベース設計で人気を博した。その後、実体-関係構造は、リレーショナルモデルのデータモデリング構造として追加され、両者の違いは無意味なものとなった。
1980年代、デスクトップ 1980年代は、デスクトップコンピューティングの時代の到来を告げた。新しいコンピュータは、Lotus 1-2-3のような表計算ソフトやdBASEのようなデータベースソフトで、ユーザーに力をもたらした。dBASE製品は軽量で、コンピューターユーザーは誰でも容易に理解できた。dBASEの作者、は次のように述べている。「dBASEは、BASIC、C、FORTRAN、COBOLのようなプログラムとは異なり、多くの汚い仕事はすでに行われている。データ操作はユーザーではなくdBASEが行うので、ユーザーはファイルを開き、読み込み、閉じ、スペース割り当ての管理などの汚い詳細に煩わされることなく、自分のしていることに集中することができる」Interview with Wayne Ratliff. The FoxPro History. Retrieved on 2013-07-12.。dBASEは、1980年代から1990年代初頭にかけて、最も売れたソフトウェアの一つであった。
1990年代、オブジェクト指向 1990年代は、オブジェクト指向プログラミングの台頭とともに、さまざまなデータベース内のデータの扱い方で発展が見られた。プログラマーと設計者は、データベース内のデータをオブジェクトとして扱うようになった。つまり、ある個人のデータがデータベース内にある場合、その人の住所、電話番号、年齢などの特性は外来のデータではなく、その人に属するものと考えられるようになったDevelopment of an object-oriented DBMS; Portland, Oregon, United States; Pages: 472–482; 1986; 。これにより、データ間の関係は、個々のフィールドではなく、オブジェクトとその属性に関連付けられる。プログラムされたオブジェクトとデータベースのテーブルとの間の変換の不都合は、「オブジェクト-リレーショナル・インピーダンスミスマッチ」という言葉で表わされる。オブジェクト・データベースやオブジェクト・リレーショナルデータベースは、この問題を解決するために、プログラマーが純粋なリレーショナルSQLの代わりに使用できるオブジェクト指向言語（SQLの拡張機能という場合もある）を提供しようとするものである。プログラミング側の立場では、オブジェクト・リレーショナル・マッピング（ORM）と呼ばれるライブラリで、同じ問題を解決しようとしている
2000年代、NoSQLとNewSQL
XMLデータベースは、構造化されたドキュメント指向データベースの一種で、XML文書の属性に基づいたクエリが可能である。XMLデータベースは、たとえば科学論文、特許、税務申告、人事記録など、非常に柔軟なものから非常に厳格なものまで、データをさまざまな構造を持つ文書の集合として見るのに便利なアプリケーションで主に使用される。
NoSQLデータベースは、多くの場合、非常に高速で、固定化したテーブルスキーマを必要とせず、したデータを格納することで結合操作を回避し、水平スケーリングするように設計されている。
近年、高い分断耐性を備えた大規模分散データベースが強く求められているが、CAP定理によれば、分散システムで一貫性、可用性、分断耐性を同時に備えることは不可能とされている。分散システムは、これら3つの保証のうち、いずれか2つを同時に満たすことはできても、3つすべてを満たすことはできない。そのため、多くのNoSQLデータベースでは、データ整合性のレベルを下げて可用性と分断耐性の両方を保証する、結果整合性という考え方を採用している。
最新のリレーショナルデータベースの一種であるNewSQLは、SQLを使用し、また従来のデータベースシステムのACID保証を維持しながらも、オンライントランザクション処理のワークロード（読み込みと書き込みの両方を伴う）に対して、NoSQLシステムと同じスケーラブルな性能を提供することを目的としている。
使用例
データベースは、組織の内部業務を支援し、顧客や発注先とのオンラインでのやり取りを支えるために使用される（エンタープライズ・ソフトウェアを参照）。
データベースは、業務における管理情報、エンジニアリングデータや経済モデルなどのより専門的なデータを保持するためにも使用される。たとえば、コンピュータによる図書館システム、航空座席予約システム、コンピュータ化された部品在庫管理システム、およびウェブサイトをウェブページの集合としてデータベースに保存する多くのコンテンツ管理システムなどがあげられる。
分類 データベースを分類する方法として、たとえば、、文書、テキスト、統計、マルチメディアなど、その内容の種類によるものがある。第二の方法は、会計、作曲、映画、銀行、製造、保険など、応用面による分類がある。第三の方法は、データベースの構造やインターフェースの種類など、技術的な側面によるものである。この節では、さまざまな種類のデータベースを特徴付けるために使用される用語をいくつか列挙する。 インメモリデータベースとは、主にメインメモリ内に存在するデータベースで、一般的に不揮発性のコンピューターデータストレージによってバックアップされる。メインメモリーデータベースはディスクデータベースよりも高速であるため、通信ネットワーク機器など、応答時間が重要な場合に使用されることが多い。 は、データベース内外の両方の状況に応答できるイベント駆動型アーキテクチャを備えている。セキュリティ監視、アラート、統計収集、および承認などの用途が考えられる。多くのデータベースは、データベーストリガーという形でアクティブデータベースの機能を提供する。 は、クラウド技術に基づいている。データベースとDBMSの大半はいずれも遠く離れた「クラウド」上に存在するが、アプリケーションはプログラマーが開発し、エンドユーザーがウェブブラウザとを通じてデータベースを保守／利用する。 データウェアハウスは、業務用データベースや、しばしば市場調査会社などの外部ソースから得たデータをアーカイブする。 データウェアハウスは、業務データにアクセスできない管理者やその他のエンドユーザーが使用するデータの中心的な供給源となる。たとえば、販売データを週ごとの合計に集計し、ACニールセンのデータと比較できるように社内商品コードを統一商品コード（UPC）に変換する。データウェアハウジングの基本的かつ不可欠なコンポーネントには、データの抽出、分析、マイニング、変換、読み込み、そしてデータをさらに利用できるようにするデータ管理がある。 は、論理プログラミングとリレーショナルデータベースを組み合わせたものである。 分散データベースとは、データとDBMSの両方が複数のコンピュータにまたがったデータベースのことである。