SQL SELECT文とその結果

コンピューティングにおいて、データベースとは、データベース管理システム（DBMS）の使用に基づいて整理されたデータの集合、またはデータストアの一種です。DBMSは、エンドユーザー、アプリケーション、およびデータベース自体と対話してデータを取得および分析するソフトウェアです。DBMSには、データベースを管理するために提供されるコア機能も含まれています。データベース、DBMS、および関連アプリケーションの総体をデータベースシステムと呼ぶことができます。「データベース」という用語は、多くの場合、DBMS、データベースシステム、またはデータベースに関連付けられたアプリケーションのいずれかを指すために、緩く使用されます

データのデジタル保存と検索が普及する前は、インデックスカードは幅広い用途と環境でデータ保存に使用されていました。家庭ではレシピ、買い物リスト、連絡先情報、その他の組織データの記録と保存に、ビジネスではプレゼンテーションのメモ、プロジェクトの研究とメモ、連絡先情報の記録に、学校ではフラッシュカードやその他の視覚教材として、学術研究では書誌引用やメモなどのデータをカードファイルに保管するために使用されていました。専門の書籍索引作成者は、1980年代と1990年代に 索引作成ソフトウェアに置き換えられるまで、書籍索引の作成にインデックスカードを使用していました。

小規模なデータベースはファイルシステムに保存できますが、大規模なデータベースはコンピュータクラスターまたはクラウドストレージでホストされます。データベースの設計には、データモデリング、効率的なデータ表現と保存、クエリ言語、機密データのセキュリティとプライバシー、同時アクセスとフォールトトレランスのサポートを含む分散コンピューティングの問題など、 正式な技術と実用的な考慮事項が含まれます

コンピュータ科学者は、データベース管理システムをサポートするデータベースモデルに応じて分類することがあります。リレーショナルデータベースは1980年代に主流になりました。これらのデータベースは、データを一連のテーブルの行と列としてモデル化し、大多数はデータの書き込みとクエリにSQLを使用します。2000年代には、異なるクエリ言語を使用するため、総称してNoSQLと呼ばれる非リレーショナルデータベースが普及しました。

用語と概要

正式には、「データベース」とは、「データベース管理システム」（DBMS）を使用してアクセスされる関連データのセットを指します。DBMSは、ユーザーが1つ以上のデータベースと対話し、データベースに含まれるすべてのデータにアクセスできるようにする統合されたコンピュータソフトウェアセットです（ただし、特定のデータへのアクセスを制限する制限が存在する場合があります）。DBMSは、大量の情報の入力、保存、検索を可能にするさまざまな機能を提供し、その情報をどのように整理するかを管理する方法を提供します

両者は密接な関係にあるため、「データベース」という用語は、データベースとそれを操作するDBMSの両方を指すために、しばしば気軽に使用されます。

専門的な情報技術の世界以外では、データベースという用語は、サイズと使用要件により通常データベース管理システムの使用が必要となるため、関連データの集合（スプレッドシートやカードインデックスなど）を指すために使用されることがよくあります。[1]

既存のDBMSは、データベースとそのデータの管理を可能にするさまざまな機能を提供しており、これらは4つの主要な機能グループに分類できます。

  • データ定義- データの編成方法を詳述する定義の作成、変更、および削除。
  • 更新– データ自体の挿入、変更、削除。[2]
  • 検索– 指定された基準（例：クエリ、階層内の位置、他のデータとの関係における位置）に従ってデータを選択し、そのデータをユーザーに直接提供するか、データベース自体または他のアプリケーションによるさらなる処理に利用できるようにします。取得されたデータは、データベースに格納されている状態のまま、ほぼそのままの形で提供される場合もあれば、変更を加えたりデータベースの既存のデータと組み合わせたりすることで新しい形で提供される場合もあります。[3]
  • 管理– ユーザーの登録と監視、データセキュリティの強化、パフォーマンスの監視、データ整合性の維持、同時実行制御の処理、予期しないシステム障害などのイベントによって破損した情報の回復。[4]

データベースとそのDBMSはどちらも、特定のデータベースモデルの原則に準拠しています。[5]「データベースシステム」とは、データベースモデル、データベース管理システム、およびデータベースを総称して指します。[6]

物理的には、データベースサーバーは実際のデータベースを保持し、DBMSと関連ソフトウェアのみを実行する専用コンピュータです。データベースサーバーは通常、安定したストレージに使用される十分なメモリとRAIDディスクアレイを備えたマルチプロセッサコンピュータです。高速チャネルを介して1つ以上のサーバーに接続されたハードウェアデータベースアクセラレータも、大規模トランザクション処理環境で使用されます。DBMSは、ほとんどのデータベースアプリケーションの中核にあります。DBMSは、ネットワークサポートが組み込まれたカスタムマルチタスクカーネルを中心に構築される場合がありますが、現代のDBMSは通常、これらの機能を提供するために標準のオペレーティングシステムに依存しています。[要出典]

DBMSは大きな市場を構成しているため、コンピュータおよびストレージベンダーは、独自の開発計画においてDBMSの要件を考慮することがよくあります。[7]

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

歴史

データベースとそれぞれのDBMSのサイズ、機能、パフォーマンスは桁違いに向上しました。これらのパフォーマンスの向上は、プロセッサ、コンピュータメモリ、コンピュータストレージ、コンピュータネットワークの分野における技術の進歩によって可能になりました。データベースの概念は、1960年代半ばに広く利用可能になった磁気ディスクなどの直接アクセスストレージメディアの出現によって可能になりました。それ以前のシステムは、磁気テープへのデータのシーケンシャルストレージに依存していました。その後のデータベース技術の発展は、データモデルまたは構造に基づいて、ナビゲーション、[8] SQL/リレーショナル、ポストリレーショナルの 3つの時代に分けられます。

初期の2つの主要なナビゲーションデータモデルは、階層モデルとCODASYLモデル（ネットワークモデル）でした。これらは、ポインタ（多くの場合、物理ディスクアドレス）を使用して、あるレコードから別のレコードへの関係をたどることを 特徴としていました

1970年にエドガー・F・コッドによって初めて提案されたリレーショナルモデルは、アプリケーションはリンクをたどるのではなく、コンテンツによってデータを検索すべきであると主張することで、この伝統から逸脱しました。リレーショナルモデルは、それぞれ異なるタイプのエンティティに使用される元帳スタイルのテーブルのセットを採用しています。1980年代半ばになって初めて、コンピューティングハードウェアはリレーショナルシステム（DBMSとアプリケーション）の広範な展開を可能にするほど強力になりました。しかし、1990年代初頭までに、リレーショナルシステムはすべての大規模データ処理アプリケーションで主流となり、2018年現在も依然として主流です。IBM Db2、Oracle、MySQL、Microsoft SQL Serverは、最も検索されているDBMSです。[9]主要なデータベース言語であるリレーショナルモデルの標準化されたSQLは、他のデータモデルのデータベース言語に影響を与えています。[要出典]

オブジェクトデータベースは、オブジェクトとリレーショナルデータベース間のインピーダンス不一致の不便さを克服するために1980年代に開発され、「ポストリレーショナル」という用語の誕生と、ハイブリッドなオブジェクトとリレーショナルデータベースの開発につながりました

2000年代後半のポストリレーショナルデータベースの次世代はNoSQLデータベースとして知られるようになり、高速なキーバリューストアとドキュメント指向データベースが導入されました。競合する「次世代」のNewSQLデータベースは、リレーショナル/SQLモデルを維持しながら、市販のリレーショナルDBMSと比較してNoSQLの高性能に匹敵することを目指した新しい実装を試みました。

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

ナビゲーションCODASYLデータベースモデルの基本構造

「データベース」という用語の導入は、1960年代半ば以降、直接アクセスストレージ（ディスクとドラム）が利用可能になったことと一致しました。この用語は、過去のテープベースのシステムとは対照的で、毎日のバッチ処理ではなく、共有されたインタラクティブな使用を可能にしました。オックスフォード英語辞典は、「データベース」という用語を特定の技術的な意味で初めて使用したものとして、1962年のカリフォルニアシステム開発会社による報告書を挙げています。[10]

コンピュータの速度と機能が向上するにつれて、多くの汎用データベースシステムが登場し、1960年代半ばまでに多くのシステムが商用化されました。標準への関心が高まり始め、そのような製品の1つであるIntegrated Data Store（IDS）の作者であるCharles Bachmanは、 COBOLの作成と標準化を担当するグループであるCODASYL内にデータベースタスクグループを設立しました。1971年、データベースタスクグループは標準を公開し、これは一般にCODASYLアプローチとして知られるようになり、すぐにこのアプローチに基づく多くの商用製品が市場に投入されました。

CODASYLアプローチは、大規模なネットワークに形成されたリンクされたデータセット内をアプリケーションがナビゲートする機能を提供しました。アプリケーションは、次の3つの方法のいずれかでレコードを見つけることができました。

  1. 主キー（CALCキーと呼ばれ、通常はハッシュによって実装されます）の使用
  2. あるレコードから別のレコードへの関係（セットと呼ばれる）のナビゲート
  3. すべてのレコードを順番にスキャンする

その後のシステムでは、代替アクセスパスを提供するためにBツリーが追加されました。多くのCODASYLデータベースでは、エンドユーザー向けに宣言型クエリ言語（ナビゲーションAPIとは別）も追加されました。しかし、CODASYLデータベースは複雑であり、有用なアプリケーションを開発するにはかなりのトレーニングと労力が必要でした。

IBMも1966年に独自のDBMSを開発しており、情報管理システム（IMS）として知られています。IMSは、System/360上のアポロ計画用に開発されたソフトウェアでした。IMSはCODASYLと概念的には似ていましたが、CODASYLのネットワークモデルではなく、データナビゲーションモデルに厳密な階層構造を採用していました。どちらの概念も、データへのアクセス方法から、後にナビゲーションデータベースとして知られるようになりました。この用語は、1973年のチューリング賞受賞時にバッハマンが行った「ナビゲーターとしてのプログラマ」によって普及しました。IMSはIBMによって階層型データベースに分類されています。IDMSとCincom SystemsのTOTALデータベースはネットワークデータベースに分類されています。IMSは2014年現在も使用されています。[11]

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

エドガー・F・コッドは、カリフォルニア州サンノゼのIBMで、主にハードディスクシステムの開発に携わるオフィスに勤務していました。[12]彼はCODASYLアプローチのナビゲーションモデル、特に「検索」機能の欠如に不満を抱いていました。1970年、彼はデータベース構築への新しいアプローチを概説したいくつかの論文を執筆し、最終的には画期的な大規模共有データバンクのためのリレーショナルデータモデル[ 13]につながりました

この論文では、大規模データベースの保存と操作のための新しいシステムについて説明しました。CODASYLのように、レコードを自由形式のレコードのリンクリストのようなものに保存する代わりに、コッドのアイデアは、データを複数の「テーブル」として整理し、各テーブルを異なるタイプのエンティティに使用するというものでした。各テーブルには、エンティティの属性を含む固定数の列が含まれます。各テーブルの1つ以上の列は 主キーとして指定され、これによりテーブルの行を一意に識別できます。テーブル間の相互参照では、ディスクアドレスではなく常にこれらの主キーが使用され、クエリはこれらのキーの関係に基づいてテーブルを結合します。結合には、関係計算の数学的システム（モデルの名前の由来）に基づく一連の操作が使用されます。データを正規化されたテーブル（またはリレーション）のセットに分割することで、各「事実」が一度だけ保存されるようにし、更新操作を簡素化することを目指しました。ビューと呼ばれる仮想テーブルは、ユーザーごとに異なる方法でデータを表示できますが、ビューを直接更新することはできませんでした

コッドはモデルを定義するために、テーブル、行、列ではなく、リレーション、タプル、ドメインといった数学用語を使用しました。現在よく知られている用語は、初期の実装から派生したものです。コッドは後に、実際の実装がモデルの基盤となった数学的基礎から逸脱する傾向を批判しました。

リレーショナルモデルでは、レコードはデータベースには保存されず、レコードに含まれるデータ間で必要に応じて定義される仮想キーを使用して「リンク」されます

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

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

たとえば、データベースシステムの一般的な用途は、ユーザーに関する情報、名前、ログイン情報、さまざまな住所や電話番号を追跡することです。ナビゲーションアプローチでは、これらすべてのデータが単一の可変長レコードに配置されます。リレーショナルアプローチでは、データはユーザーテーブル、住所テーブル、電話番号テーブル（例）に正規化されます。これらのオプションテーブルには、住所または電話番号が実際に提供された場合にのみレコードが作成されます

コッドは、ディスクアドレスではなく論理識別子を用いて行/レコードを識別するだけでなく、アプリケーションが複数のレコードからデータを組み立てる方法も変革しました。アプリケーションは、リンクをたどってレコードを1つずつ収集するのではなく、必要なデータそのものを表現する宣言型クエリ言語を使用するようになりました。これは、データを見つけるためのアクセスパスではなく、必要なデータそのものを表現するものです。データへの効率的なアクセスパスを見つけるのは、アプリケーションプログラマではなく、データベース管理システムの役割となりました。クエリ最適化と呼ばれるこのプロセスは、クエリが数学的論理で表現されるという事実に依存していました。

コッドの論文は、様々な大学のチームにこのテーマの研究を促しました。その中には、ユージン・ウォンとマイケル・ストーンブレーカーが率いるカリフォルニア大学バークレー校[12]のチームも含まれていました。彼らは、地理データベースプロジェクトに既に割り当てられていた資金と、学生プログラマーによるコード作成を利用してINGRESを立ち上げました。1973年から、INGRESは最初のテスト製品を提供し、1979年には広く使用できる状態になりました。INGRESは、 QUELと呼ばれるデータアクセス用の「言語」の使用など、多くの点でSystem Rに類似していました。時が経つにつれ、INGRESは当時台頭しつつあったSQL標準に移行しました。

IBM自身も、リレーショナルモデルのテスト実装であるPRTVと、実稼働用のBusiness System 12を1つずつ行いました。どちらも現在は廃止されています。ハネウェルはMultics用にMRDSを開発し、現在ではAlphora DataphorとRelという2つの新しい実装があります。通常リレーショナルと呼ばれる他のほとんどのDBMS実装は、実際にはSQL DBMSです

1970年、ミシガン大学はDLチャイルズの集合論的データモデル[15] [16] [17]に基づいたMICRO情報管理システム[14]の開発を開始しました。同大学は1974年にコッドとバックマンの討論会を主催し、IBMのブルース・リンゼイは後にこれを「互いに稲妻を投げ合っているようだった！」と評しました。[12] MICROは、米国労働省、米国環境保護庁、そしてアルバータ大学、ミシガン大学、ウェイン州立大学の研究者によって、非常に大規模なデータセットの管理に使用されました。MICROは、ミシガン端末システムを使用したIBMメインフレームコンピュータ上で動作しました。[18]このシステムは1998年まで運用されていました。

統合アプローチ

1970年代と1980年代には、ハードウェアとソフトウェアを統合したデータベースシステムを構築する試みがなされました。その根底にある考え方は、そのような統合によって低コストでより高いパフォーマンスが得られるというものでした。例としては、IBM System/38、初期のTeradata、Britton Lee, Inc.のデータベースマシンなどが挙げられます。

データベース管理のためのハードウェアサポートへのもう1つのアプローチは、ICLのCAFSアクセラレータ、つまりプログラム可能な検索機能を備えたハードウェアディスクコントローラでした。長期的には、専用のデータベースマシンが汎用コンピュータの急速な開発と進歩に追いつくことができなかったため、これらの取り組みは概して成功しませんでした。そのため、今日のほとんどのデータベースシステムは、汎用コンピュータデータストレージを使用し、汎用ハードウェア上で実行されるソフトウェアシステムです。ただし、この考え方は、NetezzaやOracle（Exadata）などの一部の企業によって、特定のアプリケーションで依然として追求されています。

1970年代後半、SQL DBMS

IBMは、社内の他者からの反対にもかかわらず、プロトタイプシステムであるSystem Rの開発に着手した。 [12]最初のバージョンは1974年から1975年に完成し、その後、データを分割してレコードのすべてのデータ（一部はオプション）を単一の大きな「チャンク」に格納する必要のないマルチテーブルシステムの開発が開始された。その後のマルチユーザーバージョンは1978年と1979年に顧客によってテストされ、その時点で標準化されたクエリ言語であるSQL [要出典]が追加されていた。コッドのアイデアは実行可能であり、CODASYLよりも優れていることが確立され、IBMはSQL/DSとして知られるSystem Rの真の製品版、そして後にDatabase 2（IBM Db2） の開発に着手した

ラリー・エリソンのOracleデータベース（またはより簡潔にOracle）は、IBMのSystem Rに関する論文に基づいた、異なる流れから始まりました。Oracle V1の実装は1978年に完了しましたが、エリソンがIBMに先んじて市場に参入したのは1979年のOracleバージョン2でした。[19]

ストーンブレーカーはINGRESから得た教訓を応用し、新しいデータベースPostgresを開発しました。これは現在PostgreSQLとして知られています。PostgreSQLは、グローバルなミッションクリティカルなアプリケーションでよく使用されています（.orgおよび.infoドメイン名レジストリは、多くの大企業や金融機関と同様に、PostgreSQLを主要なデータストアとして使用しています）。

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

1976年に登場した別のデータモデルである実体関連モデルは、以前のリレーショナルモデルよりも分かりやすい記述を重視していたため、データベース設計で人気を博しました。その後、実体関連構造はリレーショナルモデルのデータモデリング構造として改良され、両者の違いは重要ではなくなりました。[要出典]

1980年代、デスクトップで

IBMやSybase、Informix Corporationなどの様々なソフトウェア企業に加えて、1980年代までにほとんどの大手コンピュータハードウェアベンダーは、 DECのVAX Rdb/VMSなどの独自のデータベースシステムを備えていました。[20]この10年間は​​デスクトップコンピューティングの時代を迎えました。新しいコンピュータは、Lotus 1-2-3のようなスプレッドシートやdBASEのようなデータベースソフトウェアをユーザーに提供しました。dBASE製品は軽量で、どのコンピュータユーザーでもすぐに理解できるものでしたdBASEの開発者であるC・ウェイン・ラトリフは次のように述べています。「dBASEは、BASIC、C、FORTRAN、COBOLなどのプログラムとは異なり、多くの面倒な作業がすでに行われていました。データ操作はユーザーではなくdBASEによって行われるため、ユーザーはファイルのオープン、読み取り、クローズ、スペース割り当ての管理といった面倒な作業に煩わされることなく、自分の作業に集中できます。」[21] dBASEは、1980年代から1990年代初頭にかけて最も売れたソフトウェアの1つでした。

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

1990年代初頭までに、データベースは約10年で10億ドル規模の産業へと成長しました。[20] 1990年代には、オブジェクト指向プログラミングの台頭とともに、様々なデータベースにおけるデータの取り扱い方が進化しました。プログラマーや設計者は、データベース内のデータをオブジェクトとして扱うようになりました。つまり、ある人物のデータがデータベースに格納されている場合、住所、電話番号、年齢といった人物の属性は、無関係なデータではなく、その人物に属するものとみなされるようになりました。これにより、データ間の関係は、個々のフィールドではなく、オブジェクトとその属性に関連付けることができるようになりました。 [22] 「オブジェクト・リレーショナル・インピーダンス・ミスマッチ」という用語は、プログラムされたオブジェクトとデータベース・テーブル間の変換の不便さを表しています。オブジェクト・データベースとオブジェクト・リレーショナル・データベースは、プログラマーが純粋なリレーショナルSQLの代替として使用できるオブジェクト指向言語（場合によってはSQLの拡張）を提供することで、この問題を解決しようとしています。プログラミング面では、オブジェクトリレーショナルマッピング（ORM）と呼ばれるライブラリが同じ問題を解決しようとします。

2000年代、NoSQLとNewSQL

ドットコムバブルの期間中、そしてバブル崩壊後のeコマースの台頭により、データベースの売上は急速に増加しました。MySQLなどのオープンソースデータベースの人気は2000年以降高まり、2005年にはOracleのKen Jacobs氏が「彼らはIBMに対して行ったのと同じことを我々に対して行っているのかもしれない」と述べました。[20]

XMLデータベースは、 XML文書属性に基づいたクエリを可能にする構造化文書指向データベースの一種です。XMLデータベースは主に、データが文書の集合として都合よく表示されるアプリケーションで使用され、その構造は非常に柔軟なものから非常に厳格なものまで様々です。例としては、科学論文、特許、納税申告書、人事記録などが挙げられます。

NoSQLデータベースは多くの場合非常に高速で、[23] [24]固定テーブルスキーマを必要とせず、非正規化されたデータを保存することで結合操作を回避し、水平方向に拡張するよう に設計されています

近年、高い分断耐性を備えた大規模分散データベースへの需要が高まっていますが、CAP定理によれば、分散システムが一貫性、可用性、分断耐性の保証を同時に提供することは不可能です。分散システムはこれらの保証のうち2つを同時に満たすことはできますが、3つすべてを満たすことはできません。そのため、多くのNoSQLデータベースは、結果整合性と呼ばれるものを使用して、データ整合性を低下させた状態で可用性と分断耐性の両方の保証を提供しています。

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

ユースケース

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

データベースは、管理情報や、エンジニアリングデータや経済モデルなどのより専門的なデータを保持するために使用されます。例としては、コンピュータ化された図書館システム、航空券予約システム、コンピュータ化された部品在庫システム、そしてウェブサイトをウェブページのコレクションとしてデータベースに 保存する多くのコンテンツ管理システムなどがあります

分類

データベースを分類する方法の1つは、コンテンツの種類、たとえば書誌、文書テキスト、統計、マルチメディアオブジェクトなどです。もう1つの方法は、会計、音楽作曲、映画、銀行、製造、保険など、アプリケーション分野によるものです。3つ目の方法は、データベース構造やインターフェースの種類などの技術的な側面によるものです。このセクションでは、さまざまな種類のデータベースを特徴付けるために使用される形容詞をいくつか示します。

  • インメモリデータベースは、主にメインメモリに常駐するデータベースですが、通常は不揮発性コンピュータデータストレージによってバックアップされます。メインメモリデータベースはディスクデータベースよりも高速であるため、通信ネットワーク機器など、応答時間が重要な場合によく使用されます。
  • アクティブデータベースには、データベースの内外の両方の条件に応答できるイベント駆動型アーキテクチャが含まれています。考えられる用途としては、セキュリティ監視、アラート、統計収集、承認などがあります。多くのデータベースは、データベーストリガーの形でアクティブデータベース機能を提供しています
  • クラウドデータベースはクラウドテクノロジーに依存しています。データベースとそのDBMSの大部分はリモートの「クラウド内」に存在し、アプリケーションはプログラマーによって開発され、その後、WebブラウザとオープンAPIを介してエンドユーザーによって保守および使用されます。
  • データウェアハウス[要出典]は、運用データベースから、そして多くの場合、市場調査会社などの外部ソースからデータをアーカイブします。ウェアハウスは、運用データにアクセスできない可能性のある管理者やその他のエンドユーザーが使用するデータの中心的なソースになります。たとえば、売上データは週ごとの合計に集計され、社内製品コードからUPCを使用して変換され、 ACNielsenデータと比較できるようになります。データウェアハウスの基本的な必須コンポーネントには、データの抽出、分析、マイニング、データの変換、ロード、管理などがあり、それらをさらに使用できるようにすることが挙げられます。
  • 演繹データベースは、論理プログラミングとリレーショナルデータベースを組み合わせたものです。
  • 分散データベースは、データとDBMSの両方が複数のコンピューターにまたがるデータベースです
  • ドキュメント指向データベースは、ドキュメント指向、つまり半構造化された情報を保存、取得、管理するために設計されています。ドキュメント指向データベースは、NoSQLデータベースの主要なカテゴリの1つです
  • 組み込みデータベースシステムは、保存されたデータへのアクセスを必要とするアプリケーションソフトウェアと緊密に統合されたDBMSであり、アプリケーションのエンドユーザーからDBMSが隠蔽され、継続的なメンテナンスがほとんどまたはまったく必要ありません。[25]
  • エンドユーザーデータベースは、個々のエンドユーザーによって開発されたデータで構成されます。これらの例としては、ドキュメント、スプレッドシート、プレゼンテーション、マルチメディア、その他のファイルのコレクションが挙げられます。このようなデータベースをサポートするために、いくつかの製品（どれ？）が存在します。
  • 連合データベースシステムは、それぞれ独自のDBMSを持つ複数の異なるデータベースで構成されています。連合データベース管理システム（FDBMS）によって単一のデータベースとして処理されます。FDBMSは、複数の自律型DBMS（異なるタイプである場合もありますが、その場合は異種データベースシステムでもあります）を透過的に統合し、統合された概念ビューを提供します
  • マルチデータベースという用語は、連合データベースの同義語として使用されることもありますが、単一のアプリケーションで連携する、統合度の低い（例：FDBMSと管理された統合スキーマがない）データベースのグループを指すこともあります。この場合、通常、分散にはミドルウェアが使用されます。ミドルウェアには通常、アトミックコミットプロトコル（ACP）、例：2フェーズコミットプロトコルが含まれており、参加するデータベース間で分散（グローバル）トランザクションを可能にします。
  • グラフデータベースは、ノード、エッジ、プロパティを持つグラフ構造を使用して情報を表現および保存するNoSQLデータベースの一種です。任意のグラフを保存できる一般的なグラフデータベースは、トリプルストアやネットワークデータベースなどの特殊なグラフデータベースとは異なります。
  • 配列DBMSは、衛星画像や気候シミュレーションの出力などの（通常は大規模な）多次元配列のモデリング、保存、および検索を可能にするNoSQL DBMSの一種です
  • ハイパーテキストまたはハイパーメディアデータベースでは、オブジェクト（別のテキスト、記事、画像、映画など）を表す任意の単語またはテキスト部分を、そのオブジェクトにハイパーリンクすることができます。ハイパーテキストデータベースは、大量の異なる情報を整理するのに特に役立ちます。例えば、ユーザーがテキスト内を自由に移動できるオンライン百科事典を整理するのに役立ちます。したがって、ワールドワイドウェブは大規模な分散型ハイパーテキストデータベースです
  • ナレッジベース（略称KB、kb、またはΔ [26] [27] ）は、知識管理のための特別な種類のデータベースであり、コンピュータ化された知識の収集、整理、および検索のための手段を提供します。また、問題とその解決策および関連する経験を表すデータの集合でもあります。
基盤となるハードウェアアーキテクチャによって誘導される主要な並列DBMSアーキテクチャは次のとおりです
  • 共有メモリアーキテクチャ。複数のプロセッサがメインメモリ空間とその他のデータストレージを共有します。
  • 共有ディスクアーキテクチャ。各処理ユニット（通常は複数のプロセッサで構成）は独自のメインメモリを持ちますが、他のストレージはすべてのユニットで共有します。
  • シェアードナッシングアーキテクチャ。各処理ユニットは独自のメインメモリとその他のストレージを持ちます。
  • 確率データベースは、ファジー論理を用いて不正確なデータから推論を導き出します。
  • リアルタイムデータベースは、結果が返されてすぐに対応できるほど高速にトランザクションを処理します。
  • 空間データベースは、多次元の特徴を持つデータを保存できます。このようなデータに対するクエリには、「私の地域で最も近いホテルはどこですか？」のような位置情報に基づくクエリが含まれます
  • 時間データベースには、時間的な側面が組み込まれています。たとえば、時間データモデルやSQLの時間バージョンなどです。より具体的には、時間的な側面には通常、有効時間とトランザクション時間が含まれます。
  • 用語指向データベースは、オブジェクト指向データベースに基づいて構築され、多くの場合、特定の分野に合わせてカスタマイズされます
  • 非構造化データデータベースは、一般的なデータベースに自然かつ容易に適合しない多様なオブジェクトを、管理しやすく保護された方法で保存することを目的としています。これには、電子メールメッセージ、文書、ジャーナル、マルチメディアオブジェクトなどが含まれます。一部のオブジェクトは高度に構造化されているため、この名称は誤解を招く可能性があります。しかし、考えられるオブジェクトコレクション全体が、事前定義された構造化フレームワークに適合するわけではありません。現在、ほとんどの確立されたDBMSは、さまざまな方法で非構造化データをサポートしており、新しい専用DBMSが登場しています。

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

コノリーとベッグは、データベース管理システム（DBMS）を「ユーザーがデータベースへのアクセスを定義、作成、維持、制御できるようにするソフトウェアシステム」と定義しています。[28] DBMSの例としては、 MySQL、MariaDB、PostgreSQL、Microsoft SQL Server、Oracle Database、Microsoft Accessなどがあります。

DBMSの頭字語は、基盤となるデータベースモデルを示すために拡張されることがあります。RDBMSはリレーショナルデータベース、OODBMSはオブジェクト指向データベース、ORDBMSはオブジェクトリレーショナルモデルを表します。その他の拡張は、分散データベース管理システムのDDBMSなど、他の特性を示す場合があります。

DBMSが提供する機能は非常に多岐にわたります。中核となる機能は、データの保存、検索、更新です。コッドは、本格的な汎用DBMSが提供すべき以下の機能とサービスを提案しました。[29]

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

また、DBMSは、インポート、エクスポート、監視、デフラグ、分析ユーティリティなど、データベースを効果的に管理するために必要なユーティリティセットを提供することが一般的に期待されています。[30]データベースとアプリケーションインターフェースの間で対話するDBMSの中核部分は、データベースエンジンと呼ばれることもあります。

DBMSには、静的および動的に調整可能な設定パラメータが備わっていることがよくあります。例えば、データベースが使用できるサーバーのメインメモリの最大容量などです。近年、手動設定の負担を最小限に抑える傾向が強まっており、組み込みデータベースなどのケースでは、ゼロ管理を目標とすることが極めて重要です。

大規模な主要エンタープライズDBMSは、規模と機能が増加する傾向があり、その寿命を通じて最大数千人年の開発努力を費やしてきました。[a]

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

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

アプリケーション

データベースとの外部とのやり取りは、DBMSとインターフェースするアプリケーションプログラムを介して行われます。[33]これは、ユーザーがSQLクエリをテキストまたはグラフィカルに実行できる データベースツールから、データベースを使用して情報を保存および検索するウェブサイトまで多岐にわたります。

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

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

データベース言語

データベース言語は特殊な目的の言語であり、次の 1 つ以上のタスクを実行できます。これらはサブ言語として区別されることもあります。

  • データ制御言語（DCL） – データへのアクセスを制御します。
  • データ定義言語（DDL） – テーブルの作成、変更、削除などのデータ型とそれらの関係を定義します。
  • データ操作言語（DML） – データの発生の挿入、更新、削除などのタスクを実行します。
  • データクエリ言語（DQL） – 情報の検索と派生情報の計算を可能にします。

データベース言語は特定のデータモデルに固有のものです。注目すべき例としては、以下のものがあります

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

データベース言語には、次のような機能が組み込まれる場合もあります。

  • DBMS固有の構成とストレージエンジン管理
  • カウント、合計、平均、ソート、グループ化、相互参照など、クエリ結果を変更するための計算
  • 制約の適用（例：自動車データベースでは、車ごとに1種類のエンジンのみを許可する）
  • プログラマの利便性のための、クエリ言語のアプリケーションプログラミングインターフェースバージョン

ストレージ

データベースストレージは、データベースの物理的な実体化のコンテナです。データベースアーキテクチャにおける内部（物理）レベルを構成します。また、必要に応じて内部レベルから概念レベルと外部レベルを再構築するために必要なすべての情報（メタデータ、「データに関するデータ」、内部データ構造など）も含まれています。デジタルオブジェクトとしてのデータベースには、保存する必要がある3つの情報層（データ、構造、セマンティクス）が含まれます。データベースの将来的な保存と長期使用のためには、これら3つの層すべてを適切に保存する必要があります。 [37]データを永続ストレージに保存するのは、一般的にデータベースエンジン（「ストレージエンジン」とも呼ばれます）の役割です。DBMSは通常、基盤となるオペレーティングシステムを介してアクセスしますが（多くの場合、オペレーティングシステムのファイルシステムをストレージレイアウトの中間手段として使用します）、ストレージのプロパティと構成設定はDBMSの効率的な運用にとって非常に重要であり、データベース管理者によって綿密に管理されます。DBMSは、運用中は常にデータベースを複数の種類のストレージ（メモリや外部ストレージなど）に保持しています。データベースデータと、場合によっては非常に大量の必要な追加情報は、ビットにコード化されます。データは通常、概念レベルおよび外部レベルでのデータの見え方とはまったく異なる構造でストレージ内に存在しますが、ユーザーやプログラムが必要とする場合、またデータから必要な追加タイプの情報を計算する場合（データベースへのクエリ実行時など）に、これらのレベルの再構築を（可能な限り）最適化するように試みられます。

一部のDBMSは、データの保存に使用された文字エンコーディングの指定をサポートしているため、同じデータベースで複数のエンコーディングを使用できます。

ストレージエンジンは、さまざまな低レベルのデータベースストレージ構造を使用してデータモデルをシリアル化し、選択したメディアに書き込むことができます。インデックス作成などの手法を使用してパフォーマンスを向上させることができます。従来のストレージは行指向ですが、列指向データベースや相関データベースもあります。

マテリアライズドビュー

パフォーマンスを向上させるために、ストレージの冗長性が採用されることがよくあります。一般的な例としては、頻繁に必要となる外部ビューやクエリ結果で構成されるマテリアライズド・ビューの保存が挙げられます。このようなビューを保存することで、必要になるたびに高価なコンピューティング処理を省くことができます。マテリアライズド・ビューの欠点は、元の更新されたデータベースデータとの同期を維持するために更新時に発生するオーバーヘッドと、ストレージの冗長性にかかるコストです。

レプリケーション

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

仮想化

データ仮想化では、使用されるデータは元の場所に残り、複数のソースにわたる分析を可能にするためにリアルタイムアクセスが確立されます。これは、さまざまなプラットフォームからのデータを組み合わせる際の互換性の問題などの技術的な問題の解決、障害のあるデータによるエラーのリスクの低減、最新のデータが使用されることの保証に役立ちます。さらに、個人情報を含む新しいデータベースの作成を回避することで、プライバシー規制への準拠が容易になります。ただし、データ仮想化では、データのローカルコピーがないため、必要なすべてのデータソースへの接続が動作している必要があり、これがこのアプローチの主な欠点の1つです。[38]

セキュリティ

データベースセキュリティは、データベースのコンテンツ、その所有者、およびユーザーを保護するためのさまざまな側面を扱います。意図的な不正なデータベース使用からの保護から、不正なエンティティ（例：個人またはコンピュータプログラム）による意図しないデータベースアクセスまで、多岐にわたります

データベースアクセス制御は、データベース内のどの情報に誰（個人または特定のコンピュータプログラム）がアクセスできるかを制御するものです。アクセス対象となる情報には、特定のデータベースオブジェクト（例：レコードタイプ、特定のレコード、データ構造）、特定のオブジェクトに対する特定の計算（例：クエリタイプ、特定のクエリ）、または前者への特定のアクセスパス（例：特定のインデックスやその他のデータ構造を使用して情報にアクセスする）が含まれます。データベースアクセス制御は、データベース所有者によって承認された特別な担当者によって、専用のセキュリティ保護されたDBMSインターフェースを使用して設定されます。

これは、個人単位で直接管理することも、個人と権限をグループに割り当てることによって管理することも、あるいは（最も複雑なモデルでは）個人とグループをロールに割り当て、そのロールに権限を付与することによって管理することもできます。データセキュリティは、権限のないユーザーによるデータベースの閲覧や更新を防ぎます。ユーザーはパスワードを使用することで、データベース全体、または「サブスキーマ」と呼ばれるデータベースのサブセットにアクセスできます。例えば、従業員データベースには個々の従業員に関するすべてのデータが格納されている場合がありますが、あるユーザーグループには給与データのみの閲覧を許可し、他のユーザーグループには職歴と医療データのみへのアクセスを許可することができます。DBMSがデータベースへの対話的なアクセスと更新、および照会機能を提供している場合、この機能によって個人データベースの管理が可能になります。

データセキュリティは一般的に、特定のデータチャンクを物理的に（つまり、破損、破壊、または削除から。例：物理セキュリティを参照）、またはそれら、あるいはそれらの一部を意味のある情報に解釈すること（例：それらを構成するビット列を調べて、特定の有効なクレジットカード番号を推測する。例：データ暗号化を参照）の両方で保護することを扱います。

変更ログとアクセスログは、誰がどの属性にアクセスしたか、何が変更されたか、いつ変更されたかを記録します。ログサービスは、アクセスの発生と変更の記録を保持することで、後でデータベースのフォレンジック監査を可能にします。変更を記録するために、データベースに残すのではなく、アプリケーションレベルのコードが使用される場合があります。セキュリティ侵害を検出するために監視を設定することもできます。したがって、組織はデータベースセキュリティがもたらす多くの利点のために、データベースセキュリティを真剣に受け止めなければなりません。組織は、ファイアウォール侵入、ウイルスの拡散、ランサムウェアなどのセキュリティ侵害やハッキング活動から保護されます。これは、いかなる理由においても外部と共有できない会社の重要な情報を保護するのに役立ちます。[39]

トランザクションと同時実行性

データベーストランザクションは、クラッシュからの回復後にあるレベルのフォールトトレランスとデータ整合性を導入するために使用できます。データベーストランザクションは作業単位であり、通常はデータベースに対する複数の操作（データベースオブジェクトの読み取り、書き込み、ロックの取得または解放など）をカプセル化します。これは、データベースや他のシステムでサポートされている抽象化です。各トランザクションには、そのトランザクションに含まれるプログラム/コード実行に関して明確に定義された境界があります（トランザクションのプログラマが特別なトランザクションコマンドを使用して決定します）。

ACIDという頭字語は、データベーストランザクションの理想的な特性、すなわち原子性、一貫性、独立性、永続性を表します。

移行

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

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

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

データベースの準備が整うと（すべてのデータ構造とその他の必要なコンポーネントが定義されている場合）、通常は初期アプリケーションデータ（通常は別個のプロジェクトであるデータベースの初期化。多くの場合、一括挿入をサポートする専用のDBMSインターフェースを使用）が入力され、その後運用可能になります。場合によっては、データベースはアプリケーションデータが空の状態で運用可能になり、運用中にデータが蓄積されます

データベースが作成、初期化、そしてデータが入力された後は、メンテナンスが必要です。パフォーマンスを向上させるために、さまざまなデータベースパラメータの変更やデータベースの調整（チューニング）が必要になる場合があります。アプリケーションのデータ構造の変更や追加、アプリケーションの機能強化のために新しい関連アプリケーションプログラムの作成などが必要になる場合もあります。

バックアップとリストア

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

静的分析

ソフトウェア検証のための静的解析技術は、クエリ言語のシナリオにも適用できます。特に、*抽象解釈フレームワークは、健全な近似技術をサポートする方法として、リレーショナルデータベースのクエリ言語の分野に拡張されています。[40]クエリ言語のセマンティクスは、具体的なデータドメインの適切な抽象化に応じて調整できます。リレーショナルデータベースシステムの抽象化には、きめ細かいアクセス制御、透かしなど、セキュリティ目的において特に多くの興味深い用途があります。

その他の機能

その他のDBMS機能には以下が含まれます。

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

これらのコア機能すべてを、データベース管理とソース管理のための同じビルド、テスト、デプロイメントフレームワークに組み込んだ単一のシステムへの要望が高まっています。ソフトウェア業界の他の開発を参考に、「データベース向けDevOps」などのサービスを販売している企業もあります。[41]

設計とモデリング

データベース設計者の最初の仕事は、データベースに格納される情報の構造を反映した概念データモデルを作成することです。一般的なアプローチは、多くの場合描画ツールを用いてエンティティ・リレーションシップ・モデル（ERM）を開発することです。もう一つの一般的なアプローチは、統一モデリング言語（UML）です。優れたデータモデルは、モデル化対象となる外部世界のあり得る状態を正確に反映します。例えば、人が複数の電話番号を持つことができる場合、この情報も取り込むことができます。優れた概念データモデルを設計するには、アプリケーションドメインを十分に理解する必要があります。通常、組織にとって重要な事柄について、深い問いを投げかける必要があります。例えば、「顧客はサプライヤーにもなり得るか？」、「製品が2つの異なる包装で販売されている場合、それらは同じ製品か、それとも異なる製品か？」、「飛行機がニューヨークからフランクフルト経由でドバイへ飛ぶ場合、それは1便か、2便か（あるいは3便か）？」などです。これらの問いへの答えによって、エンティティ（顧客、製品、フライト、フライト区間）に使用される用語、そしてそれらの関係性や属性が定義されます。

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

ユーザーが満足できる概念データモデルを作成したら、次の段階は、それをデータベース内の関連するデータ構造を実装するスキーマに変換することです。このプロセスは論理データベース設計と呼ばれることが多く、出力はスキーマの形式で表現された論理データモデルです。概念データモデルは（少なくとも理論上は）データベーステクノロジの選択とは独立していますが、論理データモデルは、選択したDBMSによってサポートされる特定のデータベースモデルで表現されます。（データモデルとデータベースモデルという用語はしばしば同じ意味で使用されますが、この記事では、特定のデータベースの設計にはデータモデルを使用し、その設計を表現するために使用されるモデリング表記法にはデータベースモデルを使用します。）

汎用データベースで最も一般的なデータベースモデルはリレーショナルモデル、より正確にはSQL言語で表されるリレーショナルモデルです。このモデルを使用して論理データベース設計を作成するプロセスでは、正規化と呼ばれる方法論的なアプローチが使用されます。正規化の目的は、各基本的な「事実」が1か所にのみ記録され、挿入、更新、削除によって自動的に一貫性が維持されるようにすることです。

データベース設計の最終段階は、特定のDBMSに依存するパフォーマンス、スケーラビリティ、リカバリ、セキュリティなどに影響を与える決定を行うことです。これはしばしば物理データベース設計と呼ばれ、出力は物理データモデルです。この段階での重要な目標はデータ独立性です。つまり、パフォーマンス最適化のために行われた決定は、エンドユーザーやアプリケーションには見えないようにする必要があります。データ独立性には、物理​​データ独立性と論理データ独立性の2種類があります。物理設計は主にパフォーマンス要件によって決定され、予想されるワークロードとアクセスパターンに関する十分な知識、および選択したDBMSが提供する機能に関する深い理解が必要です

物理データベース設計のもう1つの側面はセキュリティです。セキュリティには、データベースオブジェクトへのアクセス制御の定義と、データ自体のセキュリティレベルとメソッドの定義の両方が含まれます。

モデル

5種類のデータベースモデルのコラージュ

データベースモデルは、データベースの論理構造を決定し、データの保存、整理、操作方法を 根本的に決定するデータモデルの一種です。最も一般的なデータベースモデルの例は、テーブルベースの形式を使用するリレーショナルモデル（またはリレーショナルのSQL版）です。

データベースの一般的な論理データモデルには、以下のものがあります。

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

物理データモデルには以下のものがあります 。

その他のモデルには以下のものがあります。

特殊なモデルは、特定の種類のデータに最適化されています。

外部ビュー、概念ビュー、内部ビュー

従来のデータビュー[42]

データベース管理システムは、データベースデータの3つのビューを提供します。

  • 外部レベルは、エンドユーザーの各グループがデータベース内のデータの構成をどのように表示するかを定義します。1つのデータベースは、外部レベルのビューを任意の数だけ持つことができます
  • 概念レベル（または論理レベル）は、様々な外部ビューを互換性のあるグローバルビューに統合します。[43]すべての外部ビューの統合を提供します。これは、様々なデータベースエンドユーザーの範囲外であり、むしろデータベースアプリケーション開発者やデータベース管理者にとって重要です。
  • 内部レベル（または物理レベル）は、DBMS内のデータの内部構成です。コスト、パフォーマンス、スケーラビリティ、その他の運用上の事項に関係します。データのストレージレイアウトを扱い、インデックスなどのストレージ構造を使用してパフォーマンスを向上させます。パフォーマンス上の正当な理由がある場合は、汎用データから計算された個々のビュー（マテリアライズドビュー）のデータを格納することもあります。すべてのアクティビティ全体のパフォーマンスを最適化するために、競合する可能性のあるすべての外部ビューのパフォーマンス要件のバランスを取ります

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

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

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

研究

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

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

参照

注記

  1. ^ この記事では、DB2リリース9の開発に750人が関わった5年間の開発期間について言及しています。[31]

参考文献

  1. ^ Ullman & Widom 1997, p. 1.
  2. ^ 「Update Definition & Meaning」Merriam-Webster。2024年2月25日時点のオリジナルよりアーカイブ。
  3. ^ 「Retrieval Definition & Meaning」Merriam- Webster 。 2023年6月27日時点のオリジナルよりアーカイブ。
  4. ^ 「Administration Definition & Meaning」Merriam-Webster。2023年12月6日時点のオリジナルよりアーカイブ。
  5. ^ Tsitchizris & Lochovsky 1982.
  6. ^ Beynon-Davies 2003.
  7. ^ Nelson & Nelson 2001.
  8. ^ Bachman 1973
  9. ^ 「TOPDB Top Database index」. pypl.github.io
  10. ^ 「database, n」. OED Online . Oxford University Press. 2013年6月. 2013年7月12日閲覧. （購読が必要です。）
  11. ^ IBM Corporation（2013年10月）. 「IBM Information Management System (IMS) 13 Transaction and Database Servers delivers high performance and low total cost of ownership」 . 2014年2月20日閲覧.
  12. ^ abcd 「RDBMS Plenary 1: Early Years」（PDF）（インタビュー）。Burton Gradによるインタビュー。コンピュータ歴史博物館。2007年6月12日。 2025年5月30日閲覧.
  13. ^ Codd 1970.
  14. ^ Hershey & Easthope 1972.
  15. ^ North 2010
  16. ^ Childs 1968a
  17. ^ Childs 1968b
  18. ^ MA Kahn、DL Rumelhart、B.L. Bronson（1977年10月）。MICRO情報管理システム（バージョン5.0）リファレンスマニュアル。ミシガン大学およびウェイン州立大学労働産業関係研究所（ILIR）。
  19. ^ 「Oracle 30周年記念タイムライン」（PDF） 。 2011年3月20日時点のオリジナルからアーカイブ（PDF）。2017年8月23日閲覧
  20. ^ abc 「RDBMS全体会議：後年」（PDF）（インタビュー）。バートン・グラッド氏によるインタビュー。コンピュータ歴史博物館。2007年6月12日。2025年5月30日閲覧。
  21. ^ ウェイン・ラトリフ氏へのインタビュー。FoxProの歴史。2013年7月12日閲覧。
  22. ^ オブジェクト指向DBMSの開発。米国オレゴン州ポートランド。472～482ページ。1986年。ISBN   0-89791-204-7
  23. ^ ジョーダン、メーガン。「NoSQLレイテンシー」。ScyllaDB 。 2025年6月9日閲覧
  24. ^ 「SQL vs. NoSQL：機能、相違点などの完全比較」www.testgorilla.com 。 2025年6月9日閲覧。
  25. ^ グレイブス、スティーブ。「組み込みシステム向けCOTSデータベース」Wayback Machineに2007年11月14日アーカイブ、Embedded Computing Design誌、2007年1月号。2008年8月13日閲覧。
  26. ^ 人工知能における議論、Iyad Rahwan、Guillermo R. Simari著
  27. ^ 「OWL DLセマンティクス」 。 2010年12月10日閲覧。
  28. ^ Connolly & Begg 2014、64ページ。
  29. ^ Connolly & Begg 2014、97～102ページ
  30. ^ Connolly & Begg 2014, p. 102.
  31. ^ Chong et al. 2007.
  32. ^ Connolly & Begg 2014, pp. 106–113.
  33. ^ Connolly & Begg 2014, p. 65.
  34. ^ Chapple 2005.
  35. ^ 「構造化問い合わせ言語（SQL）」International Business Machines. 2006年10月27日. 2007年6月10日閲覧.
  36. ^ Wagner 2010.
  37. ^ Ramalho, JC; Faria, L.; Helder, S.; Coutada, M. (2013年12月31日). 「データベース保存ツールキット：データベースを正規化し、アクセスを提供する柔軟なツール」ポルトガル国立図書館. ミーニョ大学
  38. ^ Paiho, Satu; Tuominen, Pekka; Rökman, Jyri; Ylikerälä, Markus; Pajula, Juha; Siikavirta, Hanne (2022). 「スマートシティのための収集された都市データの機会」IET Smart Cities . 4 (4): 275– 291. doi : 10.1049/smc2.12044 . ISSN  2631-7680. S2CID  253467923.
  39. ^ David Y. Chan、Victoria Chiu、Miklos A. Vasarhelyi (2018). 『継続的オーディティング：理論と応用（第1版）』 ビングリー、英国：Emerald Publishing. ISBN 978-1-78743-413-4 OCLC  1029759767
  40. ^ Halder & Cortesi 2011
  41. ^ Ben Linders (2016年1月28日). 「データベース管理がDevOpsにどのように適合するか」 . 2017年4月15日閲覧
  42. ^ itl.nist.gov (1993) 情報モデリングのための統合定義 (IDEFIX) 2013年12月3日アーカイブ、Wayback Machine。1993年12月21日。
  43. ^ ab 日付 2003年、31～32ページ。

出典

  • Bachman, Charles W. (1973). 「The Programmer as Navigator」Communications of the ACM . 16 (11): 653– 658. doi : 10.1145/ 355611.362534
  • ポール・ベイノン＝デイヴィス (2003).データベースシステム（第3版）. パルグレイブ・マクミラン. ISBN 978-1403916013。
  • Chapple, Mike (2005). 「SQLの基礎」.データベース. About.com. 2009年2月22日アーカイブ. 2009年1月28日閲覧。
  • Childs, David L. (1968a). 集合論的データ構造の説明(PDF) (技術レポート). CONCOMP (コンピュータの会話的利用に関する研究) プロジェクト. ミシガン大学. 技術レポート3.
  • Childs, David L. (1968b). 集合論的データ構造の実現可能性：再構成された定義に基づく一般的な構造(PDF) (技術レポート). CONCOMP (コンピュータの会話的利用に関する研究) プロジェクト. ミシガン大学. 技術レポート6
  • Chong, Raul F.; Wang, Xiaomei; Dang, Michael; Snow, Dwaine R. (2007). 「DB2入門」. 『DB2を理解する：例題を使って視覚的に学ぶ』（第2版）. IBM Press Pearson plc. ISBN 978-0131580183. 2013年3月17日閲覧。
  • Codd, Edgar F. (1970). 「大規模共有データバンクのためのリレーショナル・データ・モデル」（PDF） . Communications of the ACM . 13 (6): 377– 387. doi :10.1145/362384.362685. S2CID  207549016
  • コノリー、トーマス・M.、ベッグ、キャロリン・E. (2014). 『データベースシステム ― 設計、実装、管理への実践的アプローチ』（第6版）. ピアソン. ISBN 978-1292061184。
  • Date, CJ (2003).データベースシステム入門（第8版）. ピアソン. ISBN 978-0321197849。
  • Halder, Raju; Cortesi, Agostino (2011). 「データベースクエリ言語の抽象解釈」(PDF) .コンピュータ言語、システム、構造. 38 (2): 123– 157. doi :10.1016/j.cl.2011.10.004. ISSN  1477-8424. オリジナル(PDF)から2024年11月23日にアーカイブ。2015年6月18日閲覧
  • ウィリアム・ハーシー、キャロル・イーストホープ (1972). 集合論的データ構造と検索言語．Spring Joint Computer Conference, 1972年5月．ACM SIGIR Forum．第7巻第4号．pp.45–55.  doi : 10.1145 /1095495.1095500.
  • アン・フルチャー・ネルソン、ウィリアム・ハリス・モアヘッド・ネルソン (2001).電子商取引の構築：Webデータベース構築による. プレンティス・ホール. ISBN 978-0201741308。
  • North, Ken (2010年3月10日). 「集合、データモデル、そしてデータの独立性」. Dr. Dobb's . 2012年10月24日時点のオリジナルからのアーカイブ。
  • Tsitchizris, Dionysios C.; Lochovsky, Fred H. (1982). データモデル. Prentice–Hall. ISBN 978-0131964280。
  • Ullman, Jeffrey; Widom, Jennifer (1997). データベースシステム入門. Prentice–Hall. ISBN 978-0138613372。
  • Wagner, Michael (2010). SQL/XML:2006 – Evaluierung der Standardkonformität ausgewählter Datanbanksysteme. Diplomica Verlag. ISBN 978-3836696098

参考文献

  • Ling Liu、Tamer M. Özsu編 (2009) 『データベースシステム百科事典』、4100ページ、図版60枚、ISBN 978-0-387-49616-0。
  • Gray, J.、Reuter, A. 『トランザクション処理：概念と技法』、第1版、Morgan Kaufmann Publishers、1992年
  • Kroenke, David M.、David J. Auer. 『データベースの概念』、第3版、ニューヨーク：Prentice、2007年
  • Raghu Ramakrishnan、Johannes Gehrke . 『データベース管理システム』
  • Abraham Silberschatz、Henry F. Korth、S. Sudarshan. 『データベースシステムの概念』
  • Lightstone, S.; Teorey, T.; Nadeau, T. (2007). 『物理データベース設計：インデックス、ビュー、ストレージなどを活用するためのデータベース専門家向けガイド』 Morgan Kaufmann Press. ISBN 978-0-12-369389-1。
  • Teorey, T.; Lightstone, S.、Nadeau, T. 『データベースモデリングと設計：論理設計』第4版、Morgan Kaufmann Press、2005年. ISBN 0-12-685352-5。
  • CMU データベースコース プレイリスト
  • MIT OCW 6.830 | 2010年秋 | データベースシステム
  • バークレー CS W186
  • DBファイル拡張子 - DB拡張子を持つファイルに関する情報