データベース
ページは半保護されています

SQL SELECT文とその結果

コンピューティングにおいて、データベースとは、データベース管理システム（DBMS）に基づいて体系的に構築されたデータの集合、またはデータストアの一種です。DBMSは、エンドユーザー、アプリケーション、そしてデータベース自体と連携してデータを取得し分析するソフトウェアです。DBMSには、データベースを管理するための中核的な機能も含まれています。データベース、DBMS、および関連アプリケーションを総称してデータベースシステムと呼ぶこともあります。「データベース」という用語は、DBMS、データベースシステム、またはデータベースに関連するアプリケーションのいずれかを指すために、しばしば緩く使用されます。

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

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

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

用語と概要

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

これら 2 つの関係が密接であるため、「データベース」という用語は、データベースと、それを操作する 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つの時代に分けられます。

初期のナビゲーション・データ・モデルとして、階層モデルと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年代、ナビゲーションDBMS

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

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

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

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

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

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

IBMも1966年に情報管理システム（IMS）として知られる独自のDBMSを持っていました。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 つの理由があります。エンジニアリングの観点からは、データベースを高コストに再編成することなくテーブルの再配置やサイズ変更が可能になります。しかし、Codd が興味を持ったのはセマンティクスの違いです。明示的な識別子を使用することで、更新操作を明確な数学的定義で定義することが容易になり、また、確立された一階述語計算の分野でクエリ操作を定義することも可能になります。これらの操作は明確な数学的特性を持つため、クエリを証明可能に正しい方法で書き換えることが可能になり、これがクエリ最適化の基礎となります。階層モデルやネットワーク モデルと比べて表現力は失われませんが、テーブル間の接続はそれほど明示的ではありません。

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

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

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

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

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

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

統合アプローチ

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

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

1970年代後半、SQL DBMS

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

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

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

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

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

ユースケース

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

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

分類

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

  • インメモリデータベースとは、主にメインメモリ上に常駐するデータベースですが、通常は不揮発性コンピュータデータストレージにバックアップされます。メインメモリデータベースはディスクデータベースよりも高速であるため、通信ネットワーク機器など、応答時間が重要となる用途でよく使用されます。
  • アクティブデータベースは、データベース内外のあらゆる状況に対応できるイベント駆動型アーキテクチャを備えています。セキュリティ監視、アラート、統計情報収集、認可といった用途が考えられます。多くのデータベースは、データベーストリガーという形でアクティブデータベース機能を提供しています。
  • クラウドデータベースはクラウドテクノロジーに依存しています。データベースとそのDBMSの大部分はリモートの「クラウド」上に存在し、アプリケーションはプログラマーによって開発され、その後、エンドユーザーによってWebブラウザとオープンAPIを通じて保守・利用されます。
  • データウェアハウスは、オペレーショナルデータベースだけでなく、市場調査会社などの外部ソースからもデータをアーカイブします。ウェアハウスは、オペレーショナルデータにアクセスできない可能性のある管理者やその他のエンドユーザーが使用するデータの中心的なソースとなります。例えば、売上データを週ごとの合計に集計し、社内製品コードからUPCコードに変換することで、 ACNielsenデータと比較できるようになります。データウェアハウスの基本的かつ不可欠な要素には、データの抽出、分析、マイニング、そしてデータの変換、ロード、管理などがあり、それらをさらに活用できるようにします。
  • 演繹データベースは、論理プログラミングとリレーショナル データベースを組み合わせたものです。
  • 分散データベースとは、データと DBMS の両方が複数のコンピューターにまたがるデータベースです。
  • ドキュメント指向データベースは、ドキュメント指向、つまり半構造化された情報を保存、取得、管理するために設計されています。ドキュメント指向データベースは、NoSQLデータベースの主要なカテゴリの1つです。
  • 組み込みデータベースシステムとは、保存されたデータへのアクセスを必要とするアプリケーションソフトウェアと緊密に統合されたDBMSであり、アプリケーションのエンドユーザーからはDBMSが隠されており、継続的なメンテナンスはほとんどまたはまったく必要ありません。[ 25 ]
  • エンドユーザーデータベースは、個々のエンドユーザーによって開発されたデータで構成されます。例としては、ドキュメント、スプレッドシート、プレゼンテーション、マルチメディア、その他のファイルのコレクションが挙げられます。このようなデータベースをサポートする製品はいくつか存在します。
  • 連合データベースシステムは、それぞれ独自のDBMSを持つ複数の異なるデータベースで構成されます。連合データベース管理システム（FDBMS）によって単一のデータベースとして扱われ、複数の自律型DBMS（異なる種類の場合もあるが、その場合は異種データベースシステムとも呼ばれる）を透過的に統合し、統合された概念ビューを提供します。
  • マルチデータベースという用語は、連合データベースの同義語として使われることもありますが、実際には、単一のアプリケーションで連携する、統合度が低い（例えば、FDBMSや管理された統合スキーマを持たない）データベース群を指すこともあります。この場合、分散処理にはミドルウェアが使用され、これには通常、 2フェーズコミットプロトコルなどのアトミックコミットプロトコル（ACP）が含まれており、これにより、参加するデータベース間で分散（グローバル）トランザクションが可能になります。
  • グラフデータベースは、ノード、エッジ、プロパティを含むグラフ構造を用いて情報を表現・保存する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または言語は、DBMSによってサポートされている必要があり、場合によってはプリプロセッサやブリッジングAPIを介して間接的にサポートされることもあります。一部のAPIはデータベースに依存しないことを目的としており、ODBCはよく知られています。その他の一般的なAPIには、JDBCやADO.NETなどがあります。

データベース言語

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

データベース言語は特定のデータモデルに特化しています。代表的な例としては、以下のようなものがあります。

  • SQLは、データ定義、データ操作、クエリの役割を単一の言語に統合しています。SQLはリレーショナルモデル向けの最初の商用言語の一つですが、コッドが定義したリレーショナルモデルとはいくつかの点で異なります（例えば、テーブルの行と列を順序付けることができます）。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タイプに変換する必要があります。この変換では、データベース関連のアプリケーション（つまり、関連するすべてのアプリケーションプログラム）は（可能であれば）そのまま維持する必要があります。したがって、データベースの概念レベルと外部アーキテクチャレベルは、変換中に維持される必要があります。アーキテクチャの内部レベルの一部の側面も維持されることが望ましい場合もあります。複雑なデータベースや大規模なデータベースの移行は、それ自体が複雑でコストのかかる（一度限りの）プロジェクトになる可能性があり、移行の決定においてこの点を考慮する必要があります。これは、特定のDBMS間の移行を支援するツールが存在するにもかかわらずです。通常、DBMSベンダーは、他の一般的なDBMSからデータベースをインポートするためのツールを提供しています。

構築、保守、チューニング

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

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

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

バックアップと復元

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

静的解析

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

その他の機能

その他の DBMS 機能としては次のようなものがあります。

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

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

設計とモデリング

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

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

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

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

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

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

モデル

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

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

データベースの一般的な論理データ モデルには次のようなものがあります。

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

物理データ モデルには次のものが含まれます。

その他のモデルは次のとおりです:

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

外部、概念、内部の視点

データの伝統的な見方[ 42 ]

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

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

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

3階層データベースアーキテクチャは、リレーショナルモデルの初期の主要な推進力の一つであったデータ独立性の概念に関連しています。 [ 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. ^ウルマン＆ウィドム 1997、1ページ。
  2. ^ 「Update Definition & Meaning」 . Merriam-Webster . 2024年2月25日時点のオリジナルよりアーカイブ。
  3. ^ 「検索の定義と意味」メリアム・ウェブスター。2023年6月27日時点のオリジナルよりアーカイブ。
  4. ^ 「Administration Definition & Meaning」 . Merriam-Webster . 2023年12月6日時点のオリジナルよりアーカイブ。
  5. ^ Tsitchizris & Lochovsky 1982 .
  6. ^ベイノン・デイヴィス 2003 .
  7. ^ネルソン＆ネルソン 2001 .
  8. ^バックマン 1973 .
  9. ^ 「TOPDB トップデータベースインデックス」 . 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. ^ a b c d「RDBMS Plenary 1: Early Years」（PDF）（インタビュー）。Burton Gradによるインタビュー。コンピュータ歴史博物館。2007年6月12日。2025年5月30日閲覧。
  13. ^コッド 1970 .
  14. ^ハーシー＆イーストホープ 1972 .
  15. ^ノース 2010 .
  16. ^チャイルズ 1968a .
  17. ^チャイルズ 1968b .
  18. ^ MA Kahn、DL Rumelhart、BL Bronson（1977年10月）。MICRO情報管理システム（バージョン5.0）リファレンスマニュアル。ミシガン大学およびウェイン州立大学労働産業関係研究所（ILIR）。
  19. ^ 「Oracle 30周年記念タイムライン」(PDF)。2011年3月20日時点のオリジナルよりアーカイブ(PDF) 。 2017年8月23日閲覧。
  20. ^ a b c「RDBMS Plenary Session: The Later Years」（PDF）（インタビュー）。Burton Gradによるインタビュー。コンピュータ歴史博物館。2007年6月12日。2025年5月30日閲覧。
  21. ^ウェイン・ラトリフ氏へのインタビュー。FoxProの歴史。2013年7月12日閲覧。
  22. ^オブジェクト指向DBMSの開発; アメリカ合衆国オレゴン州ポートランド; ページ: 472–482; 1986; ISBN 0-89791-204-7
  23. ^ Jordan, Meghan. 「NoSQLレイテンシー」 . ScyllaDB . 2025年6月9日閲覧。
  24. ^ 「SQLとNoSQL：機能、相違点などの完全比較」 www.testgorilla.com . 2025年6月9日閲覧。
  25. ^ Graves, Steve.「組み込みシステム向け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. ^コノリー＆ベッグ 2014、64ページ。
  29. ^コノリー＆ベッグ 2014年、97～102頁。
  30. ^コノリー＆ベッグ 2014、102ページ。
  31. ^ Chong et al. 2007 .
  32. ^コノリー＆ベッグ 2014年、106～113頁。
  33. ^コノリー＆ベッグ 2014、65ページ。
  34. ^チャップル 2005 .
  35. ^ 「構造化照会言語（SQL）」 International Business Machines、2006年10月27日。 2007年6月10日閲覧。
  36. ^ワーグナー 2010 .
  37. ^ラマーリョ、JC;ファリア、L.ヘルダー、S. Coutada、M. (2013 年 12 月 31 日) 「データベース保存ツールキット: データベースを正規化し、データベースへのアクセスを提供する柔軟なツール」。ポルトガル国立図書館。ミンホ大学。
  38. ^パイホ、サトゥ;トゥオミネン、ペッカ。ロックマン、ジリ。 Ylikerälä、マルクス;パジュラ、ジュハ。シイカヴィルタ、ハンネ（2022）。「スマートシティ向けに収集された都市データの機会」。IET スマートシティ。4 (4): 275–291 .土井: 10.1049/smc2.12044。ISSN 2631-7680。S2CID 253467923。  
  39. ^ David Y. Chan、Victoria Chiu、Miklos A. Vasarhelyi (2018). 『継続的オーディティング：理論と応用』（第1版）. Bingley, UK: Emerald Publishing. ISBN 978-1-78743-413-4. OCLC  1029759767 .
  40. ^ハルダー＆コルテシ 2011 .
  41. ^ Ben Linders (2016年1月28日). 「データベース管理がDevOpsにどのように適合するか」 . 2017年4月15日閲覧。
  42. ^ itl.nist.gov (1993)情報モデリングのための統合定義 (IDEFIX) Archived 2013-12-03 at the Wayback Machine . 1993年12月21日。
  43. ^ a b 2003年、31～32頁。

出典

さらに読む

「 https://en.wikipedia.org/w/index.php?title=データベース&oldid= 1328986224」より取得