Loading article…
コンピューティングにおいて、データベースとは、データベース管理システム（DBMS）を用いて整理されたデータの集合、あるいはデータストアの一種を指します。DBMSは、エンドユーザー、アプリケーション、そしてデータベース自体と連携してデータを取得・分析するソフトウェアです。さらに、DBMSにはデータベースを管理するために提供されるコア機能も含まれます。データベース、DBMS、および関連アプリケーションの総体をデータベースシステムと呼ぶことができます。また、「データベース」という用語は、DBMS、データベースシステム、またはデータベースに関連付けられたアプリケーションのいずれかを指す場合にも、広義に用いられることがあります。
デジタルデータ保存・検索が普及する以前は、インデックスカードはさまざまな用途や環境でデータ保存に利用されていました。家庭ではレシピ、買い物リスト、連絡先情報などの組織的なデータの記録・保存に、ビジネスではプレゼンテーションのメモ、プロジェクトの調査やメモ、連絡先情報の記録に、学校ではフラッシュカードなどの視覚教材として、学術研究では書誌情報やメモなどのデータをカードファイルに保管するために使われていました。プロの書籍索引作成者は、1980年代から1990年代にかけて索引作成ソフトウェアに取って代わられるまで、書籍索引の作成にインデックスカードを使用していました。
小規模なデータベースはファイルシステムに保存できますが、大規模なデータベースはコンピュータクラスタやクラウドストレージでホストされます。データベースの設計は、データモデリング、効率的なデータ表現と保存、クエリ言語、機密データのセキュリティとプライバシー、同時アクセスや耐障害性のサポートなどの分散コンピューティングの問題など、形式的な手法と実用的な考慮事項に及びます。
コンピュータ科学者は、データベース管理システムを、サポートするデータベースモデルに基づいて分類することがあります。リレーショナルデータベースは1980年代に主流となりました。これらはデータを一連のテーブルの行と列としてモデル化し、その大部分はデータの書き込みとクエリにSQLを使用します。2000年代には、異なるクエリ言語を使用する非リレーショナルデータベースが普及し、これらはまとめてNoSQLと呼ばれています。
正式には、「データベース」とは、「データベース管理システム」（DBMS）を使用してアクセスされる関連データの集合を指します。DBMSは、ユーザーが1つまたは複数のデータベースとやり取りできるようにし、データベースに含まれるすべてのデータへのアクセスを提供する統合されたコンピュータソフトウェアです（ただし、特定のデータへのアクセスを制限する制約が存在する場合があります）。DBMSは、大量の情報の入力、保存、および検索を可能にするさまざまな機能を提供し、その情報がどのように整理されているかを管理する方法を提供します。
両者の密接な関係から、「データベース」という用語は、データベースそのものと、それを操作するために用いられるDBMSの両方を指す場合によく使われる。
専門的な情報技術の世界以外では、データベースという用語は、関連するデータの集合（スプレッドシートやカードインデックスなど）を指すためによく使われます。これは、通常、サイズと使用要件からデータベース管理システムの使用が必要となるためです。[ 1 ]
既存のDBMSは、データベースとそのデータの管理を可能にする様々な機能を提供しており、それらは主に4つの機能グループに分類できます。
データベースとそのDBMSはどちらも、特定のデータベースモデルの原則に準拠しています。[ 5 ]「データベースシステム」とは、データベースモデル、データベース管理システム、およびデータベースを総称するものです。[ 6 ]
物理的には、データベースサーバーは実際のデータベースを保持し、DBMSと関連ソフトウェアのみを実行する専用コンピュータです。データベースサーバーは通常、マルチプロセッサコンピュータであり、十分なメモリと安定したストレージに使用されるRAIDディスクアレイを備えています。高速チャネルを介して1つ以上のサーバーに接続されたハードウェアデータベースアクセラレータも、大量のトランザクション処理環境で使用されます。DBMSは、ほとんどのデータベースアプリケーションの中核にあります。DBMSは、組み込みのネットワークサポートを備えたカスタムマルチタスクカーネルを中心に構築される場合もありますが、最新のDBMSは通常、これらの機能を提供するために標準のオペレーティングシステムに依存しています。
DBMSは大きな市場を形成しているため、コンピュータおよびストレージベンダーは、自社の開発計画においてDBMSの要件を考慮に入れることが多い。[ 7 ]
データベースとDBMSは、サポートするデータベースモデル（リレーショナルデータベースやXMLなど） 、動作するコンピュータの種類（サーバークラスタから携帯電話まで）、データベースへのアクセスに使用されるクエリ言語（SQLやXQueryなど）、およびパフォーマンス、拡張性、回復力、セキュリティに影響を与える内部設計に基づいて分類できます。
データベースとそのそれぞれの DBMS の規模、機能、およびパフォーマンスは桁違いに拡大しました。これらのパフォーマンスの向上は、プロセッサ、コンピュータ メモリ、コンピュータ ストレージ、およびコンピュータ ネットワークの分野における技術の進歩によって可能になりました。データベースの概念は、1960 年代半ばに広く利用可能になった磁気ディスクなどの直接アクセス可能なストレージ メディアの出現によって可能になりました。それ以前のシステムは、磁気テープへのデータの順次ストレージに依存していました。その後のデータベース技術の発展は、データ モデルまたは構造に基づいて、ナビゲーション[ 8 ] SQL/リレーショナル、およびポストリレーショナルの3 つの時代に分けることができます。
初期のナビゲーションデータモデルの主なものは、階層型モデルとCODASYLモデル（ネットワークモデル）の2つでした。これらのモデルは、ポインタ（多くの場合、物理ディスクのアドレス）を使用して、あるレコードから別のレコードへの関係をたどることを特徴としていました。
1970年にエドガー・F・コッドによって初めて提唱されたリレーショナルモデルは、アプリケーションがリンクをたどるのではなく、コンテンツに基づいてデータを検索すべきだと主張することで、この伝統から脱却した。リレーショナルモデルは、それぞれ異なるタイプのエンティティに使用される台帳スタイルのテーブルのセットを採用している。1980年代半ばになってようやく、コンピューターハードウェアがリレーショナルシステム（DBMSとアプリケーション）の広範な展開を可能にするほど強力になった。しかし、1990年代初頭には、リレーショナルシステムはすべての大規模データ処理アプリケーションで支配的となり、2018年現在ではIBM Db2、Oracle、MySQL、Microsoft SQL Serverは依然として支配的な地位を占めており、最も検索されているDBMSです。[ 9 ]リレーショナルモデル用の標準化されたSQLという支配的なデータベース言語は、他のデータモデルのデータベース言語に影響を与えています。
オブジェクトデータベースは、オブジェクトとリレーショナルのインピーダンスミスマッチの不便さを克服するために1980年代に開発され、その結果「ポストリレーショナル」という用語が生まれ、ハイブリッドオブジェクトリレーショナルデータベースの開発にもつながりました。
2000年代後半に登場した次世代のポストリレーショナルデータベースは、 NoSQLデータベースとして知られるようになり、高速なキーバリューストアとドキュメント指向データベースを導入しました。これに対抗する「次世代」として登場したNewSQLデータベースは、リレーショナル/SQLモデルを維持しつつ、市販のリレーショナルDBMSと比較してNoSQLの高いパフォーマンスに匹敵することを目指した新たな実装を試みました。
データベースという用語の導入は、1960年代半ば以降、直接アクセスストレージ（ディスクやドラム）が利用可能になった時期と重なります。この用語は、過去のテープベースのシステムとは対照的で、日々のバッチ処理ではなく、共有の対話型利用を可能にしました。オックスフォード英語辞典は、カリフォルニアのシステム開発会社による1962年のレポートを、特定の技術的な意味で「データベース」という用語を初めて使用したものとして挙げています。[ 10 ]
コンピュータの速度と性能が向上するにつれて、汎用データベースシステムが数多く登場し、1960年代半ばには、そうしたシステムの多くが商用利用されるようになった。標準規格への関心が高まり、そうした製品の一つである統合データストア（IDS）の開発者であるチャールズ・バッハマンは、 COBOLの作成と標準化を担当するグループであるCODASYL内にデータベースタスクグループを設立した。1971年、データベースタスクグループは標準規格を発表し、これは一般にCODASYL方式として知られるようになり、間もなくこの方式に基づいた多くの商用製品が市場に投入された。
CODASYLのアプローチでは、アプリケーションは大規模なネットワークに形成されたリンクデータセット内をナビゲートする機能を備えていました。アプリケーションは、次の3つの方法のいずれかでレコードを検索することができました。
後のシステムでは、代替アクセスパスを提供するためにBツリーが追加されました。多くのCODASYLデータベースは、エンドユーザー向けに宣言型クエリ言語も追加しました（ナビゲーションAPIとは別個のものです）。しかし、CODASYLデータベースは複雑で、実用的なアプリケーションを作成するには相当なトレーニングと労力が必要でした。
IBMも1966年に独自のDBMSを開発しており、Information Management System（IMS）と呼ばれていました。IMSはSystem/360上でアポロ計画のために開発されたソフトウェアを基に開発されたものです。IMSは概念的にはCODASYLと類似していましたが、データナビゲーションモデルとしてCODASYLのネットワークモデルではなく、厳密な階層構造を採用していました。これらの概念は、データのアクセス方法から後にナビゲーションデータベースと呼ばれるようになり、この用語はバッハマンが1973年にチューリング賞を受賞した際のプレゼンテーション「ナビゲーターとしてのプログラマー」によって広く知られるようになりました。IBMはIMSを階層型データベースに分類しています。IDMSとCincom SystemsのTOTALデータベースはネットワークデータベースに分類されています。IMSは2014年現在も使用されています。[ 11 ]
エドガー・F・コッドは、カリフォルニア州サンノゼのIBMで、主にハードディスクシステムの開発に携わる部署に勤務していた。[ 12 ]彼はCODASYLのナビゲーションモデル、特に「検索」機能の欠如に不満を抱いていた。1970年、彼はデータベース構築への新しいアプローチを概説した論文をいくつか執筆し、それが最終的に画期的な「大規模共有データバンクのためのリレーショナルデータモデル」へと結実した。[ 13 ]
この論文では、大規模データベースの保存と操作のための新しいシステムが説明されています。CODASYLのようにレコードを自由形式のレコードのリンクリストに格納するのではなく、Coddのアイデアはデータを複数の「テーブル」として整理し、各テーブルを異なるタイプのエンティティに使用するというものでした。各テーブルには、エンティティの属性を含む固定数の列が含まれます。各テーブルの1つ以上の列は、 テーブルの行を一意に識別できる主キーとして指定されます。テーブル間の相互参照には、ディスクアドレスではなく常にこれらの主キーが使用され、クエリは関係計算の数学システム（このモデルの名前の由来）に基づく一連の操作を使用して、これらのキー関係に基づいてテーブルを結合します。データを正規化されたテーブル（またはリレーション）のセットに分割することで、各「事実」が一度だけ格納されるようにし、更新操作を簡素化することを目指しました。ビューと呼ばれる仮想テーブルは、異なるユーザーに対してデータを異なる方法で表示できますが、ビューを直接更新することはできません。
コッドは、モデルを定義する際に、表、行、列ではなく、関係、タプル、ドメインといった数学的な用語を用いた。現在よく知られている用語は、初期の実装に由来する。コッドは後に、実際の実装がモデルの基盤となる数学的基礎から逸脱する傾向があることを批判した。
テーブル間の関係を表すのに、ディスクアドレスではなく主キー（ユーザー指向の識別子）を使用するようになった主な理由は2つあります。エンジニアリングの観点からは、高額なデータベース再編成をすることなく、テーブルの移動やサイズ変更が可能になりました。しかし、コッドは意味論的な違いに特に注目していました。明示的な識別子を使用することで、更新操作を明確な数学的定義で容易に定義できるようになり、また、確立された一階述語論理の枠組みでクエリ操作を定義できるようになりました。これらの操作は明確な数学的特性を持つため、クエリを証明可能な正しい方法で書き換えることが可能になり、これがクエリ最適化の基礎となります。階層型モデルやネットワーク型モデルと比較して表現力は低下しませんが、テーブル間の接続は以前ほど明示的ではなくなりました。
階層型モデルとネットワーク型モデルでは、レコードは複雑な内部構造を持つことが許容されていました。例えば、従業員の給与履歴は、従業員レコード内の「繰り返しグループ」として表現されることがあります。リレーショナルモデルでは、正規化のプロセスによって、このような内部構造は、論理キーのみで接続された複数のテーブルに格納されたデータに置き換えられました。
例えば、データベースシステムの一般的な用途として、ユーザー情報（名前、ログイン情報、住所、電話番号など）の追跡が挙げられます。ナビゲーション方式では、これらのデータはすべて単一の可変長レコードに格納されます。一方、リレーショナル方式では、データはユーザーテーブル、住所テーブル、電話番号テーブル（例えば）に正規化されます。これらのオプションテーブルには、住所や電話番号が実際に提供された場合にのみレコードが作成されます。
コッドは、行/レコードをディスクアドレスではなく論理識別子で識別するだけでなく、アプリケーションが複数のレコードからデータを集める方法も変えました。アプリケーションは、リンクをたどってレコードを1つずつ収集するのではなく、必要なデータの内容を表現する宣言型クエリ言語を使用するようになりました。データのアクセスパスではなく、データ自体のアクセスパスを記述するようになったのです。効率的なデータアクセスパスを見つけるのは、アプリケーションプログラマではなく、データベース管理システムの責任となりました。クエリ最適化と呼ばれるこのプロセスは、クエリが数学的論理に基づいて表現されるという事実に依存していました。
コッドの論文は、さまざまな大学の研究チームにこのテーマの研究を促し、その中にはユージン・ウォンとマイケル・ストーンブレーカーが率いるカリフォルニア大学バークレー校のチーム[ 12 ]も含まれていた。彼らは、地理データベースプロジェクトに既に割り当てられていた資金と学生プログラマーを使ってINGRESを開始した。1973年から、INGRESは最初のテスト製品を提供し、1979年には広く使用できる状態になった。INGRESは、 QUELとして知られるデータアクセス用の「言語」の使用など、多くの点でSystem Rに似ていた。時を経て、INGRESは新興のSQL標準に移行した。
IBM自身もリレーショナルモデルのテスト実装であるPRTVと、本番環境向けのBusiness System 12を開発したが、どちらも現在は開発が終了している。HoneywellはMultics向けにMRDSを開発し、現在ではAlphora DataphorとRelという2つの新しい実装が存在する。一般的にリレーショナルと呼ばれる他のほとんどのDBMS実装は、実際にはSQL DBMSである。
1970年、ミシガン大学はDLチャイルズの集合論的データモデルに基づいてMICRO情報管理システム[ 14 ]の開発を開始しました。 [ 15 ] [ 16 ] [ 17 ] 1974年、同大学はコッドとバッハマンの討論会を開催し、IBMのブルース・リンゼイは後にそれを「互いに稲妻を投げ合っているようだった」と表現しました。[ 12 ] MICROは、米国労働省、米国環境保護庁、アルバータ大学、ミシガン大学、ウェイン州立大学の研究者によって、非常に大規模なデータセットの管理に使用されました。これは、ミシガン端末システムを使用してIBMメインフレームコンピュータ上で動作しました。[ 18 ]このシステムは1998年まで運用されていました。
1970年代から1980年代にかけて、ハードウェアとソフトウェアを統合したデータベースシステムの構築が試みられた。その根底にある考え方は、このような統合によって、より低いコストでより高いパフォーマンスが得られるというものだった。例としては、IBM System/38、初期のTeradata、そしてBritton Lee社のデータベースマシンなどが挙げられる。
データベース管理のためのハードウェアサポートのもう一つのアプローチは、ICLのCAFSアクセラレータでした。これは、プログラム可能な検索機能を備えたハードウェアディスクコントローラです。しかし、汎用コンピュータの急速な発展と進歩に専用データベースマシンが追いつけなかったため、長期的にはこれらの取り組みは概して失敗に終わりました。そのため、現在ではほとんどのデータベースシステムは、汎用コンピュータのデータストレージを使用する汎用ハードウェア上で動作するソフトウェアシステムとなっています。ただし、NetezzaやOracle（Exadata）などの一部の企業は、特定のアプリケーションにおいてこの考え方を今もなお追求しています。
IBMは、社内の反対にもかかわらず、コッドが率いるチームを結成し、プロトタイプシステムであるSystem Rの開発に着手した。 [ 12 ]最初のバージョンは1974/5年に完成し、その後、レコードのすべてのデータ（一部はオプション）を単一の大きな「チャンク」に格納する必要がないようにデータを分割できるマルチテーブルシステムの開発が始まった。その後のマルチユーザーバージョンは1978年と1979年に顧客によってテストされ、その時点で標準化されたクエリ言語であるSQL [ 19 ]が追加されていた。コッドのアイデアは実用的かつCODASYLよりも優れていることが確立され、IBMはSQL/DSとして知られるSystem Rの真の製品版、そして後にDatabase 2（IBM Db2）の開発に着手した。
ラリー・エリソンのOracle Database（または単にOracle）は、IBMのSystem Rに関する論文に基づいて、異なる流れから始まった。Oracle V1の実装は1978年に完了したが、エリソンがIBMに先んじて市場に投入したのはOracle Version 2で、1979年のことだった。[ 20 ]
ストーンブレーカーはINGRESで得た教訓を活かし、新しいデータベースであるPostgresを開発しました。これは現在PostgreSQLとして知られています。PostgreSQLは、グローバルなミッションクリティカルなアプリケーションでよく使用されています（.orgや.infoドメイン名レジストリは主要なデータストアとして使用しており、多くの大企業や金融機関も同様です）。
スウェーデンでもコッドの論文が読まれ、1970年代半ばにウプサラ大学でMimer SQLが開発された。1984年には、このプロジェクトは独立した企業として統合された。
もう一つのデータモデルであるエンティティ関係モデルは1976年に登場し、それまでのリレーショナルモデルよりも馴染みやすい記述を重視したことから、データベース設計において人気を博しました。その後、エンティティ関係の構成要素はリレーショナルモデルのデータモデリング構成要素として後付けされ、両者の違いはもはや重要ではなくなりました。
IBMやSybase、Informix Corporationなどの様々なソフトウェア企業に加え、1980年代までにほとんどの大手コンピュータハードウェアベンダーがDECのVAX Rdb/VMSなどの独自のデータベースシステムを持っていた。[ 21 ]この10年間はデスクトップコンピューティングの時代を到来させた。新しいコンピュータは、Lotus 1-2-3のような表計算ソフトやdBASEのようなデータベースソフトウェアによってユーザーに力を与えた。dBASE製品は軽量で、どんなコンピュータユーザーでもすぐに理解できた。dBASEの開発者であるC. Wayne Ratliffは次のように述べている。「dBASEはBASIC、C、FORTRAN、COBOLのようなプログラムとは異なり、面倒な作業の多くがすでに完了している。データ操作はユーザーではなくdBASEによって行われるため、ユーザーはファイルのオープン、読み込み、クローズ、領域割り当ての管理といった面倒な詳細に気を取られることなく、自分の作業に集中できる。」[ 22 ] dBASEは1980年代から1990年代初頭にかけて最も売れたソフトウェアタイトルの1つでした。
1990年代初頭までに、データベースはわずか10年ほどで数十億ドル規模の産業となった。[ 21 ] 1990年代には、オブジェクト指向プログラミングの台頭とともに、さまざまなデータベースのデータ処理方法が大きく発展した。プログラマーや設計者は、データベース内のデータをオブジェクトとして扱うようになった。つまり、ある人物のデータがデータベースにある場合、その人物の住所、電話番号、年齢などの属性は、無関係なデータではなく、その人物に属するものとみなされるようになった。これにより、データ間の関係は、個々のフィールドではなく、オブジェクトとその属性に関連付けられるようになった。 [ 23 ]「オブジェクトリレーショナルインピーダンスミスマッチ」という用語は、プログラムされたオブジェクトとデータベーステーブル間の変換の不便さを表している。オブジェクトデータベースとオブジェクトリレーショナルデータベースは、プログラマーが純粋なリレーショナルSQLの代替として使用できるオブジェクト指向言語（SQLの拡張として使用される場合もある）を提供することで、この問題を解決しようとしている。プログラミングの面では、オブジェクトリレーショナルマッピング（ORM）と呼ばれるライブラリが、同じ問題を解決しようと試みている。
データベースの販売はドットコムバブル期に急速に伸び、バブル崩壊後にはeコマースの台頭とともに成長した。MySQLなどのオープンソースデータベースの人気は2000年以降高まり、Oracleのケン・ジェイコブスは2005年に「彼らは我々がIBMに対して行ったことを我々に対して行っているのかもしれない」と述べている。[ 21 ]
XMLデータベースは、 XMLドキュメントの属性に基づいてクエリを実行できる、構造化されたドキュメント指向データベースの一種です。XMLデータベースは、データがドキュメントの集合として扱いやすく、その構造が非常に柔軟なものから非常に厳格なものまで様々であるアプリケーションで主に利用されます。例としては、科学論文、特許、納税申告書、人事記録などが挙げられます。
NoSQLデータベースは多くの場合非常に高速で、[ 24 ] [ 25 ]固定テーブルスキーマを必要とせず、非正規化データを格納することで結合操作を回避し、水平方向に拡張できるように設計されています。Neo4jなどのグラフデータベースを含む一部のNoSQLデータベースは、エンティティ間の関係をモデル化するためにデータをノードとエッジとして表現します。[ 26 ]
近年、高いパーティション耐性を備えた大規模分散データベースへの需要が高まっていますが、CAP定理によれば、分散システムが一貫性、可用性、およびパーティション耐性の保証を同時に提供することは不可能です。分散システムはこれらの保証のうち2つを同時に満たすことはできますが、3つすべてを同時に満たすことはできません。そのため、多くのNoSQLデータベースは、可用性とパーティション耐性の両方の保証を、データ一貫性のレベルを下げて提供するために、結果整合性と呼ばれる手法を採用しています。
NewSQLは、最新のリレーショナルデータベースの一種であり、SQLを使用しながら、従来のデータベースシステムのACID特性を維持し、オンラインのトランザクション処理（読み書き）ワークロードにおいてNoSQLシステムと同等のスケーラブルなパフォーマンスを提供することを目指しています。
データベースは、組織の内部業務をサポートし、顧客やサプライヤーとのオンラインでのやり取りを支えるために使用されます（エンタープライズソフトウェアを参照）。
データベースは、管理情報や、エンジニアリングデータ、経済モデルなどのより専門的なデータを格納するために使用されます。例としては、コンピュータ化された図書館システム、航空券予約システム、コンピュータ化された部品在庫管理システム、そしてウェブサイトをウェブページの集合としてデータベースに格納する多くのコンテンツ管理システムなどが挙げられます。
データベースを分類する方法の一つは、その内容の種類による分類です。例えば、書誌情報、文書テキスト、統計情報、マルチメディアオブジェクトなどが挙げられます。もう一つの分類方法は、その応用分野による分類です。例えば、会計、楽曲、映画、銀行業務、製造業、保険などが挙げられます。さらに、データベースの構造やインターフェースの種類といった技術的な側面による分類もあります。このセクションでは、さまざまな種類のデータベースを特徴づけるために使用される形容詞をいくつか紹介します。
コノリーとベッグは、データベース管理システム（DBMS）を「ユーザーがデータベースを定義、作成、維持、およびアクセスを制御できるようにするソフトウェアシステム」と定義しています。[ 30 ] DBMSの例としては、 MySQL、MariaDB、PostgreSQL、Microsoft SQL Server、Oracle Database、Microsoft Accessなどがあります。
DBMSという略語は、基となるデータベースモデルを示すために拡張されることがあり、リレーショナルデータベースの場合はRDBMS 、オブジェクト指向データベースの場合はOODBMS 、オブジェクトリレーショナルデータベースの場合はORDBMSといった具合です。その他の拡張では、分散データベース管理システムを表すDDBMSなど、他の特性を示す場合もあります。
DBMSが提供する機能は非常に多様です。コア機能はデータの保存、取得、更新です。コッドは、本格的な汎用DBMSが提供すべき機能とサービスとして以下を提案しました。[ 31 ]
また、一般的には、DBMS は、インポート、エクスポート、監視、デフラグメンテーション、分析ユーティリティなど、データベースを効果的に管理するために必要な一連のユーティリティを提供するものと期待されます。[ 32 ]データベースとアプリケーション インターフェースの間でやり取りする DBMS の中核部分は、データベース エンジンと呼ばれることもあります。
DBMSには、静的および動的に調整可能な構成パラメータが用意されていることが多く、例えば、データベースが使用できるサーバーのメインメモリの最大容量などが挙げられます。近年の傾向としては、手動による構成作業を最小限に抑えることが挙げられ、組み込みデータベースのようなケースでは、管理作業ゼロを目指すことが極めて重要となります。
大規模なエンタープライズ向けDBMSは、規模と機能が拡大する傾向があり、そのライフサイクルを通じて数千人年もの開発努力を要してきた。[ a ]
初期のマルチユーザーDBMSでは、通常、アプリケーションは同じコンピュータ上に存在し、端末または端末エミュレーションソフトウェアを介してのみアクセス可能でした。クライアント/サーバーアーキテクチャは、アプリケーションがクライアントのデスクトップ上に、データベースがサーバー上に配置され、処理を分散できるようになったものです。これは、アプリケーションサーバーとWebサーバーを組み込んだマルチティアアーキテクチャへと進化し、エンドユーザーインターフェースはWebブラウザを介して提供され、データベースは隣接するティアにのみ直接接続されるようになりました。[ 34 ]
汎用DBMSは、公開アプリケーションプログラミングインターフェース（API）と、オプションでSQLなどのデータベース言語用のプロセッサを提供し、アプリケーションがデータベースと連携して操作できるようにします。一方、特殊用途DBMSは、プライベートAPIを使用し、特定のアプリケーションに合わせてカスタマイズおよびリンクされる場合があります。例えば、電子メールシステムは、メッセージの挿入、メッセージの削除、添付ファイルの処理、ブロックリストの検索、メッセージと電子メールアドレスの関連付けなど、汎用DBMSの多くの機能を実行しますが、これらの機能は電子メールの処理に必要な範囲に限定されています。
データベースとの外部からのやり取りは、DBMSとインターフェースするアプリケーションプログラムを介して行われます。[ 35 ]これは、ユーザーがテキストまたはグラフィカルにSQLクエリを実行できるデータベースツールから、データベースを使用して情報を保存および検索するWebサイトまで多岐にわたります。
プログラマーは、アプリケーションプログラミングインターフェース（API）またはデータベース言語を介して、データベース（データソースと呼ばれることもあります）とのやり取りをコーディングします。選択した特定のAPIまたは言語は、DBMSによってサポートされている必要があり、場合によってはプリプロセッサまたはブリッジングAPIを介して間接的にサポートされます。一部のAPIはデータベースに依存しないことを目指しており、ODBCはその代表的な例です。その他の一般的なAPIには、JDBCやADO.NETなどがあります。
データベース言語は、特定の目的のために設計された言語であり、以下のタスクの1つ以上を実行できるように設計されており、場合によってはサブ言語として区別される。
データベース言語は、特定のデータモデルに特化しています。代表的な例としては、以下のようなものがあります。
データベース言語には、次のような機能も組み込まれている場合があります。
データベースストレージは、データベースの物理的な具現化のコンテナです。データベースアーキテクチャの内部（物理）レベルを構成します。また、必要に応じて内部レベルから概念レベルと外部レベルを再構築するために必要なすべての情報（メタデータ、「データに関するデータ」、内部データ構造など）も含まれています。デジタルオブジェクトとしてのデータベースには、データ、構造、意味論という、保存する必要のある3つの情報層が含まれています。データベースの将来の保存と長寿命のためには、3つの層すべてを適切に保存する必要があります。 [ 39 ]データを永続ストレージに格納するのは、一般的にデータベースエンジン、別名「ストレージエンジン」の責任です。通常、基盤となるオペレーティングシステムを介してDBMSによってアクセスされますが（多くの場合、ストレージレイアウトの中間としてオペレーティングシステムのファイルシステムを使用します）、ストレージプロパティと構成設定はDBMSの効率的な動作にとって非常に重要であるため、データベース管理者によって厳密に管理されます。DBMSは、動作中は常に、データベースを複数の種類のストレージ（メモリや外部ストレージなど）に保持しています。データベースデータと、場合によっては非常に大量の追加必要な情報は、ビットに符号化されます。データは通常、概念レベルや外部レベルでのデータとは全く異なる構造でストレージに格納されますが、ユーザーやプログラムが必要とする場合、これらのレベルの再構築を（可能な限り）最適化し、データから必要な追加タイプの情報を計算する（たとえば、データベースを照会する場合）ための方法を採用しています。
一部のDBMSは、データの保存に使用された文字エンコーディングを指定する機能をサポートしているため、同じデータベース内で複数のエンコーディングを使用できます。
ストレージエンジンは、さまざまな低レベルのデータベースストレージ構造を使用してデータモデルをシリアル化し、選択したメディアに書き込めるようにします。インデックスなどの技術を使用してパフォーマンスを向上させることができます。従来のストレージは行指向ですが、列指向データベースや相関データベースも存在します。
ストレージの冗長性は、パフォーマンス向上のためにしばしば用いられます。一般的な例としては、頻繁に必要となる外部ビューやクエリ結果で構成されるマテリアライズドビューの保存が挙げられます。このようなビューを保存することで、必要となるたびに計算するコストを削減できます。マテリアライズドビューの欠点は、更新時に発生するオーバーヘッド、つまり元の更新済みデータベースデータとの同期を維持すること、そしてストレージの冗長性にかかるコストです。
データベースによっては、データ可用性を高めるために、データベースオブジェクトの複製（1つ以上のコピーを作成）によるストレージ冗長性を採用することがあります（これは、複数のエンドユーザーが同時に同じデータベースオブジェクトにアクセスする際のパフォーマンス向上と、分散データベースの部分的な障害発生時の回復力向上の両方を目的としています）。複製されたオブジェクトの更新は、オブジェクトのコピー間で同期させる必要があります。多くの場合、データベース全体が複製されます。
データ仮想化では、使用されるデータは元の場所に保持され、リアルタイムアクセスが確立されるため、複数のソースにわたる分析が可能になります。これにより、さまざまなプラットフォームからのデータを組み合わせる際の互換性の問題などの技術的な困難を解決したり、データの欠陥によるエラーのリスクを低減したり、最新のデータが使用されることを保証したりすることができます。さらに、個人情報を含む新しいデータベースの作成を避けることで、プライバシー規制への準拠が容易になります。ただし、データ仮想化では、データのローカルコピーがないため、必要なすべてのデータソースへの接続が稼働している必要があり、これがこのアプローチの主な欠点の1つです。[ 40 ]
データベースセキュリティとは、データベースの内容、所有者、および利用者を保護するためのあらゆる側面を網羅するものです。その範囲は、意図的な不正利用から、権限のない主体（例えば、人やコンピュータプログラム）による意図しないデータベースアクセスまで多岐にわたります。
データベースアクセス制御とは、データベース内のどの情報に誰が（個人または特定のコンピュータプログラムが）アクセスできるかを制御することです。アクセス可能な情報には、特定のデータベースオブジェクト（レコードタイプ、特定のレコード、データ構造など）、特定のオブジェクトに対する特定の計算（クエリタイプ、特定のクエリなど）、または特定のアクセスパス（特定のインデックスやその他のデータ構造を使用して情報にアクセスするなど）が含まれます。データベースアクセス制御は、専用の保護されたセキュリティDBMSインターフェースを使用する、データベース所有者によって特別に承認された担当者によって設定されます。
これは、個人単位で直接管理することも、個人と権限をグループに割り当てることによって管理することも、（最も高度なモデルでは）個人とグループを役割に割り当て、その役割に権限を付与することによって管理することもできます。データセキュリティにより、権限のないユーザーがデータベースを閲覧または更新することを防止します。パスワードを使用することで、ユーザーはデータベース全体、または「サブスキーマ」と呼ばれるそのサブセットへのアクセスを許可されます。たとえば、従業員データベースには個々の従業員に関するすべてのデータが含まれている可能性がありますが、あるユーザーグループは給与データのみを閲覧する権限を持ち、他のユーザーは勤務履歴と医療データのみへのアクセスを許可される場合があります。DBMSが対話的にデータベースに入力および更新し、照会する方法を提供している場合、この機能により個人データベースを管理できます。
データセキュリティとは一般的に、特定のデータ塊を物理的に（破損、破壊、削除などから保護すること。例えば、物理的セキュリティを参照）、あるいはデータ塊またはその一部を意味のある情報に解釈すること（例えば、データ塊を構成するビット列を調べて、特定の有効なクレジットカード番号を推測すること。例えば、データ暗号化を参照）の両方で保護することに関係します。
変更およびアクセスログは、誰がどの属性にアクセスしたか、何が変更されたか、いつ変更されたかを記録します。ログサービスは、アクセス発生と変更の記録を保持することで、後日フォレンジックデータベース監査を可能にします。変更をデータベースに残すのではなく、アプリケーションレベルのコードを使用して記録する場合もあります。監視を設定してセキュリティ侵害を検出することもできます。したがって、組織は、データベースセキュリティがもたらす多くの利点のために、真剣に取り組む必要があります。組織は、ファイアウォール侵入、ウイルス拡散、ランサムウェアなどのセキュリティ侵害やハッキング活動から保護されます。これは、いかなる場合でも外部と共有できない企業の重要な情報を保護するのに役立ちます。[ 41 ]
データベーストランザクションは、クラッシュからの復旧後に一定レベルの耐障害性とデータ整合性を確保するために使用できます。データベーストランザクションは、通常、データベースに対する複数の操作（データベースオブジェクトの読み取り、書き込み、ロックの取得または解放など）をカプセル化する作業単位であり、データベースだけでなく他のシステムでもサポートされている抽象化です。各トランザクションには、そのトランザクションに含まれるプログラム/コードの実行範囲が明確に定義されています（トランザクションのプログラマが特別なトランザクションコマンドを使用して決定します）。
ACIDという頭字語は、データベーストランザクションの理想的な特性、すなわち原子性、一貫性、分離性、および永続性を表しています。
ある DBMS で構築されたデータベースは、別の DBMS に移植できません (つまり、別の DBMS では実行できません)。しかし、状況によっては、データベースをある DBMS から別の DBMS に移行することが望ましい場合があります。その理由は主に経済的な理由 (DBMS によって総所有コスト(TCO) が異なる場合がある)、機能的な理由、および運用上の理由 (DBMS によって機能が異なる場合がある) です。移行には、データベースをある DBMS タイプから別の DBMS タイプに変換することが含まれます。この変換では、データベース関連のアプリケーション (つまり、関連するすべてのアプリケーション プログラム) を (可能であれば) そのまま維持する必要があります。したがって、データベースの概念的および外部アーキテクチャ レベルは、変換後も維持する必要があります。アーキテクチャの内部レベルの一部の側面も維持することが望ましい場合もあります。複雑または大規模なデータベース移行は、それ自体が複雑でコストのかかる (一度限りの) プロジェクトになる可能性があり、移行の決定にはこれを考慮する必要があります。これは、特定の DBMS 間の移行を支援するツールが存在する場合でも同様です。通常、DBMS ベンダーは、他の一般的な DBMS からデータベースをインポートするのに役立つツールを提供しています。
アプリケーション用のデータベースを設計した後、次の段階はデータベースの構築です。通常、この目的には適切な汎用DBMSを選択できます。DBMSは、データベース管理者がDBMSのデータモデル内で必要なアプリケーションのデータ構造を定義するために必要なユーザーインターフェースを提供します。その他のユーザーインターフェースは、必要なDBMSパラメータ（セキュリティ関連、ストレージ割り当てパラメータなど）を選択するために使用されます。
データベースの準備が整うと（すべてのデータ構造とその他の必要なコンポーネントが定義されると）、通常は運用開始前にアプリケーションの初期データが格納されます（データベースの初期化は通常、別のプロジェクトであり、多くの場合、一括挿入をサポートする専用のDBMSインターフェースが使用されます）。場合によっては、アプリケーションデータが空の状態でデータベースが運用開始され、運用中にデータが蓄積されることもあります。
データベースが作成、初期化、データ投入された後は、メンテナンスが必要です。さまざまなデータベースパラメータを変更する必要が生じたり、パフォーマンス向上のためにデータベースのチューニングが必要になる場合があります。アプリケーションのデータ構造を変更または追加したり、アプリケーションの機能を追加するために新しい関連アプリケーションプログラムを作成したりするなど、さまざまな変更が発生する可能性があります。
データベースを以前の状態に戻したい場合があります（ソフトウェアエラーによってデータベースが破損した場合や、誤ったデータで更新された場合など、理由は様々です）。これを実現するために、バックアップ操作が定期的に、または継続的に実行され、必要なデータベースの状態（つまり、データの値とデータベースのデータ構造への埋め込み）が専用のバックアップファイルに保存されます（これを効果的に行うための手法は数多く存在します）。データベース管理者がデータベースをこの状態に戻すことを決定した場合（例えば、データベースがこの状態であった時点を指定するなど）、これらのファイルを使用してその状態を復元します。
ソフトウェア検証のための静的解析技術は、クエリ言語のシナリオにも適用できます。特に、抽象解釈フレームワークは、健全な近似技術をサポートする方法として、リレーショナルデータベースのクエリ言語の分野に拡張されています。[ 42 ]クエリ言語のセマンティクスは、データの具体的なドメインの適切な抽象化に応じて調整できます。リレーショナルデータベースシステムの抽象化には、特にセキュリティ目的において、きめ細かなアクセス制御、電子透かしなど、多くの興味深いアプリケーションがあります。
その他のDBMSの機能には、以下のようなものがあるかもしれません。
データベース管理とソース管理のための、これらのコア機能すべてを同じビルド、テスト、デプロイメントフレームワークに統合した単一のシステムを求める声が高まっている。ソフトウェア業界の他の開発からヒントを得て、「データベースのためのDevOps」としてそのような製品を販売している企業もある。[ 43 ]
データベース設計者の最初の仕事は、データベースに格納される情報の構造を反映した概念データモデルを作成することです。このための一般的なアプローチは、多くの場合描画ツールを用いてエンティティ関係モデルを開発することです。もう1つの一般的なアプローチは、統一モデリング言語（UML）です。優れたデータモデルは、モデル化される外部世界の可能な状態を正確に反映します。たとえば、人が複数の電話番号を持つことができる場合、その情報を記録できるようにします。優れた概念データモデルを設計するには、アプリケーション領域を十分に理解する必要があります。通常、組織にとって関心のある事柄について、「顧客はサプライヤーにもなり得るか？」「製品が2種類の異なるパッケージで販売されている場合、それらは同じ製品か、異なる製品か？」「飛行機がニューヨークからフランクフルト経由でドバイに飛ぶ場合、それは1回のフライトか、2回（あるいは3回）のフライトか？」といった深い質問を投げかけることになります。これらの質問への回答によって、エンティティ（顧客、製品、フライト、フライト区間）とその関係および属性に使用される用語の定義が確立されます。
概念データモデルの作成には、業務プロセスからの情報や組織内のワークフロー分析が用いられることがあります。これにより、データベースに必要な情報と不要な情報を明確にすることができます。例えば、データベースに過去データと現在データの両方を格納する必要があるかどうかを判断する際に役立ちます。
ユーザーが満足する概念データモデルを作成したら、次の段階は、これをデータベース内の関連データ構造を実装するスキーマに変換することです。このプロセスは論理データベース設計と呼ばれることが多く、出力はスキーマの形式で表現された論理データモデルです。概念データモデルは（少なくとも理論上は）データベース技術の選択に依存しませんが、論理データモデルは、選択したDBMSがサポートする特定のデータベースモデルに基づいて表現されます。（データモデルとデータベースモデルという用語はしばしば同義語として使われますが、この記事では、データモデルは特定のデータベースの設計を指し、データベースモデルはその設計を表現するために使用されるモデリング表記法を指します。）
汎用データベースで最も普及しているデータベースモデルはリレーショナルモデル、より正確にはSQL言語で表されるリレーショナルモデルです。このモデルを用いて論理的なデータベース設計を作成するプロセスでは、正規化と呼ばれる体系的なアプローチが用いられます。正規化の目的は、各基本要素である「事実」が一箇所にのみ記録されるようにすることで、挿入、更新、削除によって整合性が自動的に維持されるようにすることです。
データベース設計の最終段階は、特定の DBMS に依存するパフォーマンス、スケーラビリティ、リカバリ、セキュリティなどに影響を与える決定を行うことです。これはしばしば物理データベース設計と呼ばれ、出力は物理データモデルです。この段階の重要な目標はデータ独立性であり、これはパフォーマンス最適化のために行われた決定がエンドユーザーやアプリケーションから見えないようにする必要があることを意味します。データ独立性には、物理データ独立性と論理データ独立性の 2 種類があります。物理設計は主にパフォーマンス要件に基づいて行われ、想定されるワークロードとアクセスパターンに関する十分な知識と、選択した DBMS が提供する機能に関する深い理解が必要です。
物理データベース設計のもう一つの側面はセキュリティです。これには、データベースオブジェクトへのアクセス制御を定義することと、データ自体のセキュリティレベルと方法を定義することの両方が含まれます。
データベースモデルとは、データベースの論理構造を決定し、データの格納、整理、操作方法を根本的に規定するデータモデルの一種です。最も一般的なデータベースモデルは、テーブルベースの形式を用いるリレーショナルモデル（またはSQLにおけるリレーショナルモデルの近似）です。
データベースの一般的な論理データモデルには、以下のようなものがあります。
オブジェクトリレーショナルデータベースは、これら2つの関連する構造を組み合わせたものである。
物理データモデルには以下が含まれます。
その他のモデルには以下が含まれます。
専用モデルは、特定の種類のデータに合わせて最適化されています。
データベース管理システムは、データベースデータの3つのビューを提供します。
通常、データには概念的かつ内部的なビューが1つしかありませんが、外部的なビューはいくつでも作成できます。これにより、ユーザーはデータベース情報を技術的な処理の観点からではなく、よりビジネスに関連した視点から見ることができます。例えば、企業の財務部門は、会社の経費の一部として全従業員の給与明細を必要としますが、人事部門にとって重要な従業員の情報は必要としません。このように、部門ごとに企業のデータベースに対する異なるビューが必要となるのです。
3 層データベース アーキテクチャは、リレーショナル モデルの初期の主要な推進力の 1 つですであったデータ独立性の概念に関連しています。 [ 45 ]この考え方は、あるレベルで行われた変更が上位レベルのビューに影響を与えないということです。たとえば、内部レベルでの変更は、概念レベルのインターフェースを使用して記述されたアプリケーション プログラムに影響を与えないため、パフォーマンスを向上させるための物理的な変更の影響が軽減されます。
概念ビューは、内部と外部の間に間接的な関係を提供します。一方では、さまざまな外部ビュー構造に依存しないデータベースの共通ビューを提供し、他方では、データの格納方法や管理方法（内部レベル）の詳細を抽象化します。原則として、すべてのレベル、さらにはすべての外部ビューは、異なるデータモデルで表現できます。実際には、通常、特定のDBMSは、外部レベルと概念レベルの両方に同じデータモデル（リレーショナルモデルなど）を使用します。DBMS内部に隠蔽され、その実装に依存する内部レベルは、異なるレベルの詳細を必要とし、独自のデータ構造型を使用します。
データベース技術は、1960年代以降、学術界と企業の研究開発グループ（例えばIBMリサーチ）の両方で活発な研究テーマとなってきました。研究活動には、理論構築とプロトタイプ開発が含まれます。注目すべき研究テーマとしては、モデル、アトミックトランザクションの概念、関連する並行性制御技術、クエリ言語とクエリ最適化手法、RAIDなどが挙げられます。
データベース研究分野には、いくつかの専門学術誌（例えば、ACM Transactions on Database Systems - TODS、Data and Knowledge Engineering - DKE）や年次会議（例えば、ACM SIGMOD、ACM PODS、VLDB、IEEE ICDE）が存在する。
1970年代、IBMの科学者ドナルド・チェンバリンとレイモンド・ボイスはSQLを開発し、発表した。これは関係モデルの概念から生まれ、当初は構造化英語照会言語（SEQUEL）と呼ばれていたが、後にSQLに短縮された。