「データベース」の意味や使い方 わかりやすく解説 Weblio辞書 (original) (raw)

この項目では、コンピューティング的な概念について説明しています。データベースの実例については「データベースの一覧（英語版）」を、データベースの概要およびトピックガイドについては「データベースの概要（英語版）」をご覧ください。
ウィキペディアにおけるデータベースの利用については、「Wikipedia:データベースダウンロード」をご覧ください。

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

コンピューティングにおいて、データベース（英: database）は、電子的に保存され、アクセスできる組織化されたデータの集合である。実メモリに保存されるもの、CSVなどのファイルに保管される物、OSのファイルシステムなどから、後述のデータベース管理システムを使った大規模なものまである。

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

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

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

用語と概要

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

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

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

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

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

物理的には、データベース・サーバーは、実際のデータベースを格納し、DBMSと関連ソフトウェアのみを実行する専用コンピュータである。データベース・サーバーは通常、大容量のメモリと、安定したストレージ（例: RAIDディスクアレイ）を備えたマルチプロセッサ・コンピュータである。大容量のトランザクション処理環境では、複数台のサーバーと高速チャネルを介して接続されたハードウェア・データベース・アクセラレータも使用される。ほとんどのデータベース・アプリケーション（英語版）の中心に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、PostgreSQLは、最も検索されているDBMSである[9]。リレーショナルモデル用の主要なデータベース言語である標準SQLは、他のデータモデル用のデータベース言語にも影響を与えた[_要出典_]。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

統合型アプローチ

詳細は「データベースマシン（英語版）」を参照

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

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

1970年代後半、SQL DBMS

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

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

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

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

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

1980年代、デスクトップ

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

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

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

2000年代、NoSQLとNewSQL

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

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

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

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

使用例

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

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

分類

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

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

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

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

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

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

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

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

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

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

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

アプリケーション

詳細は「データベースアプリケーション（英語版）」を参照

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

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

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

データベース言語

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

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

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

ストレージ

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

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

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

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

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

レプリケーション

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

セキュリティ

詳細は「データベースセキュリティ（英語版）」を参照

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

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

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

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

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

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

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

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

移行

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

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

詳細は「データベースチューニング（英語版）」を参照

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

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

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

バックアップと復元

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

静的解析

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

その他の機能

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

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

設計とモデリング

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

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

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

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

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

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

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

モデル

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

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

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

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

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

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

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

外部、概念、内部ビュー

詳細は「三層スキーマ方式（英語版）」を参照

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

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

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

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

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

研究

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

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

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

参照項目

脚注

注釈

  1. ^ この記事では、DB2リリース9単独で750人が関与した5年間の開発期間を引用している。(Chong et al. 2007)
  2. ^ 3層の分け方はいくつかの種類があり、次の説明は、外部-概念-内部の3層に分けているが、他にも概念-論理-物理の3層に分けた説明もある。

出典

  1. ^ Ullman & Widom 1997, p. 1.
  2. ^ “Update – Definition of update by Merriam-Webster”. merriam-webster.com. 2022年8月14日閲覧。
  3. ^ “Retrieval – Definition of retrieval by Merriam-Webster”. merriam-webster.com. 2022年8月14日閲覧。
  4. ^ “Administration – Definition of administration by Merriam-Webster”. merriam-webster.com. 2022年8月14日閲覧。
  5. ^ Tsitchizris & Lochovsky 1982.
  6. ^ Beynon-Davies 2003.
  7. ^ Nelson & Nelson 2001.
  8. ^ Bachman 1973.
  9. ^ “TOPDB Top Database index”. pypl.github.io. 2022年7月16日閲覧。
  10. ^ “database, n”. OED Online. Oxford University Press (June 2013). July 12, 2013閲覧。 (要購読契約)
  11. ^ IBM Corporation (October 2013). “IBM Information Management System (IMS) 13 Transaction and Database Servers delivers high performance and low total cost of ownership”. Feb 20, 2014閲覧。
  12. ^ Codd 1970.
  13. ^ Hershey & Easthope 1972.
  14. ^ North 2010.
  15. ^ Childs 1968a.
  16. ^ Childs 1968b.
  17. ^ M.A. Kahn; D.L. Rumelhart; B.L. Bronson (October 1977). MICRO Information Management System (Version 5.0) Reference Manual. Institute of Labor and Industrial Relations (ILIR), University of Michigan and Wayne State University. https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B4t_NX-QeWDYZGMwOTRmOTItZTg2Zi00YmJkLTg4MTktN2E4MWU0YmZlMjE3
  18. ^ “Oracle 30th Anniversary Timeline”. 23 August 2017閲覧。
  19. ^ Interview with Wayne Ratliff. The FoxPro History. Retrieved on 2013-07-12.
  20. ^ Development of an object-oriented DBMS; Portland, Oregon, United States; Pages: 472–482; 1986; ISBN 0-89791-204-7
  21. ^ 斎藤, 謙一郎「航空予約システムとその動向」『電気学会誌』第123巻第6号、2003年、352頁、doi:10.1541/ieejjournal.123.349、ISSN 1881-4190。
  22. ^ Graves, Steve. "COTS Databases For Embedded Systems" Archived 2007-11-14 at the Wayback Machine., Embedded Computing Design magazine, January 2007. Retrieved on August 13, 2008.
  23. ^ Argumentation in Artificial Intelligence by Iyad Rahwan, Guillermo R. Simari
  24. ^ “OWL DL Semantics”. 10 December 2010閲覧。
  25. ^ Connolly & Begg 2014, p. 64.
  26. ^ Connolly & Begg 2014, pp. 97–102.
  27. ^ Connolly & Begg 2014, p. 102.
  28. ^ Connolly & Begg 2014, pp. 106–113.
  29. ^ Connolly & Begg 2014, p. 65.
  30. ^ Chapple 2005.
  31. ^ “Structured Query Language (SQL)”. International Business Machines (October 27, 2006). 2007年6月10日閲覧。
  32. ^ Wagner 2010.
  33. ^ Ramalho, José Carlos; Faria, Luis; Silva, Hélder; Coutada, Miguel (2014). Database Preservation Toolkit: a flexible tool to normalize and give access to databases. Biblioteca Nacional de Portugal (BNP). hdl:1822/35183. ISBN 978-972-565-541-2. https://repositorium.sdum.uminho.pt/handle/1822/35183.
  34. ^ David Y. Chan; Victoria Chiu; Miklos A. Vasarhelyi (2018). Continuous auditing : theory and application (1st ed.). Bingley, UK. ISBN 978-1-78743-413-4. OCLC 1029759767
  35. ^ Halder & Cortesi 2011.
  36. ^ Ben Linders (January 28, 2016). “How Database Administration Fits into DevOps”. April 15, 2017閲覧。
  37. ^ a b itl.nist.gov (1993) Integration Definition for Information Modeling (IDEFIX) Archived 2013-12-03 at the Wayback Machine.. 21 December 1993.
  38. ^ a b Date 2003, pp. 31–32.

出典

推薦文献

外部リンク

関連項目
表話編歴コンピュータ科学ハードウェア プリント基板 周辺機器 Integrated Circuit (IC) Very Large Scale Integration (超大規模集積回路、VLSI) Systems on Chip (SoC) エネルギー消費 (グリーン・コンピューティング) EDA ハードウェアアクセラレーション コンピュータシステムの構造 コンピュータ・アーキテクチャ 組み込みシステム リアルタイムシステム ディペンダビリティ ネットワーク ネットワーク・アーキテクチャ（英語版） 通信プロトコル ネットワーク・コンポーネント（英語版） ネットワーク・スケジューラ（英語版） ネットワーク性能評価（英語版） ネットワーク・サービス（英語版） ソフトウェアの構造 インタプリタ ミドルウェア 仮想マシン オペレーティングシステム ソフトウェア品質 ソフトウェア記法（英語版）とツール プログラミングパラダイム プログラミング言語 コンパイラ ドメイン固有言語 モデリング言語 ソフトウェアフレームワーク 統合開発環境 ソフトウェア構成管理 ソフトウェアライブラリ ソフトウェアリポジトリ ソフトウェア開発 ソフトウェア開発プロセス 要求分析 ソフトウェア設計 ソフトウェア構築（英語版） ソフトウェアデプロイメント ソフトウェアメンテナンス プログラミングチーム（英語版） オープンソースモデル 計算理論 計算モデル 形式言語 オートマトン理論 計算可能性理論 計算複雑性理論 コンピュータ科学における論理学（英語版） 意味論 アルゴリズム アルゴリズム（英語版） アルゴリズム解析 アルゴリズム効率（英語版） 乱択アルゴリズム 計算幾何学 コンピューティングの数学 離散数学 確率 統計学 数学ソフトウェア 情報理論 解析学 数値解析 情報システム データベース管理システム 情報ストレージシステム 企業情報システム 社会情報システム（英語版） 地理情報システム 意思決定支援システム プロセス制御システム マルチメディア情報システム（英語版） データマイニング 電子図書館 コンピューティング・プラットフォーム デジタルマーケティング World Wide Web 情報検索 セキュリティ 暗号理論 形式手法 セキュリティ・サービス（英語版） 侵入検知システム ハードウェア・セキュリティ（英語版） ネットワーク・セキュリティ 情報セキュリティ アプリケーション・セキュリティ（英語版） ヒューマンコンピュータ インタラクション インタラクションデザイン ソーシャル・コンピューティング（英語版） ユビキタスコンピューティング 可視化 アクセシビリティ 並行性 並行コンピューティング 並列コンピューティング 分散コンピューティング マルチスレッディング マルチプロセッシング 人工知能 自然言語処理 知識表現と推論 コンピュータビジョン 自動計画とスケジューリング 検索手法 制御手法 人工知能の哲学（英語版） 分散人工知能（英語版） 機械学習 教師あり学習 教師なし学習 強化学習 マルチタスク学習（英語版） 交差検証 グラフィックス アニメーション レンダリング 画像編集 GPU 複合現実 バーチャル・リアリティ 画像圧縮 ソリッドモデリング 応用コンピューティング 電子商取引 企業アプリケーション 計算数学（英語版） 計算物理学 計算化学 計算生物学 計算社会科学 計算工学（英語版） 健康情報学 デジタルアート 電子出版 サイバー戦争 電子投票 コンピュータゲーム ワードプロセッサー オペレーションズ・リサーチ 教育工学 文書管理システム 概要（英語版） カテゴリ ブック コモンズ 表話編歴データベース管理システム データモデル 関係モデル データベース設計 正規化 参照整合性 関係代数 関係論理 データベース管理システム 関係データベース管理システム オブジェクト関係データベース 分散データベース トランザクション処理概念 データベース ACID CRUD 3値論理（NULL） 候補キー 外部キー 主キー スーパーキー 代理キー オブジェクト 関係 (表) ビュー トランザクション ログ トリガ 索引 ストアドプロシージャ カーソル 分割 SQL SELECT INSERT UPDATE MERGE DELETE JOIN CREATE DROP COMMIT ROLLBACK TRUNCATE ALTER WHERE SAVEPOINT 構成要素 並行性制御 データ辞書 JDBC ODBC データベース言語 問い合わせ言語 クエリ最適化 クエリ実行計画 データベース製品 関係データベース管理システムの比較 データベース接続クライアント カテゴリ 表話編歴データベース管理システム データモデル 関係モデル データベース設計 正規化 参照整合性 関係代数 関係論理 データベース管理システム 関係データベース管理システム オブジェクト関係データベース 分散データベース トランザクション処理概念 データベース ACID CRUD 3値論理（NULL） 候補キー 外部キー 主キー スーパーキー 代理キー オブジェクト 関係 (表) ビュー トランザクション ログ トリガ 索引 ストアドプロシージャ カーソル 分割 SQL SELECT INSERT UPDATE MERGE DELETE JOIN CREATE DROP COMMIT ROLLBACK TRUNCATE ALTER WHERE SAVEPOINT 構成要素 並行性制御 データ辞書 JDBC ODBC データベース言語 問い合わせ言語 クエリ最適化 クエリ実行計画 データベース製品 関係データベース管理システムの比較 データベース接続クライアント カテゴリ 表話編歴データベースモデルモデル フラットファイルデータベース 階層型データモデル ディメンショナルモデリング（英語版） データウェアハウス ネットワーク型データモデル 関係モデル 実体関連モデル 拡張（英語版） グラフデータベース（英語版） オブジェクト(指向)データベース エンティティ属性数値(EAV)モデル（英語版） 他のモデル アソシアティブ(連想)モデル（英語版） コリレーション(相関)データベース（英語版） 多次元データベース(OLAP) Array DBMS（英語版） セマンティックデータモデル（英語版） スタースキーマ XMLデータベース 実装 フラットファイルデータベース データベース管理システム(DBMS) 列指向DBMS オブジェクト(ODBMS) 関係(RDBMS) オブジェクト関係(ORDBMS) Document-oriented database（英語版） 演繹的データベース（英語版） テンポラルデータベース（英語版） XML-DBMS キーバリュー型データベース トリプルストア（英語版） Template:Data warehouse 表話編歴セマンティック・ウェブ背景 データベース ハイパーテキスト インターネット オントロジー 意味ネットワーク World Wide Web サブトピック データウェブ データ空間（英語版） ハイパーデータ（英語版） Linked Data (en) ルールベースシステム（英語版） アプリケーション Semantic analytics Semantic broker Semantic computing Semantic mapper Semantic matching Semantic publishing Semantic reasoner Semantic search Semantic service-oriented architecture Semantic wiki 関連項目 集団的知性 記述論理（英語版） フォークソノミー ジオタギング 情報アーキテクチャ 知識抽出（英語版） ナレッジマネジメント 知識表現 図書館2.0（英語版） メタデータ マインドマップ ODBC 参照 トピックマップ Web 2.0 ウェブエンジニアリング（英語版） ウェブ・サイエンス・トラスト（英語版） 標準文法とサポート技術 HTTP IRI URI RDF triples RDF/XML JSON-LD Turtle（英語版） TriG（英語版） Notation3 N-Triples TriX（英語版） (非W3C標準) RRID SPARQL XML スキーム、オントロジー、ルール Common Logic OWL RDFS Rule Interchange Format Semantic Web Rule Language ALPS セマンティック注釈 eRDF GRDDL マイクロデータ（英語版） マイクロフォーマット RDFa SAWSDL Facebook Platform 共通語彙 DOAP Dublin Core FOAF Schema.org SIOC SKOS マイクロフォーマット語彙 hAtom hCalendar hCard hProduct hRecipe hResume hReview カテゴリ 表話編歴システム科学全般 システム 系 (自然科学) システム科学 システムアーキテクチャ タイプ 解剖学(人体) アート体系（英語版） 生物学的体系（英語版） 複雑系 複雑適応系 Conceptual system（英語版） 概念体系(オントロジー) en:Coupled human–environment system データベース 力学系 生態系 経済体系 エネルギー体系（英語版） 形式体系 Holarchic(ホロン) 情報システム 法系 法系の一覧 単位系 メートル法 マルチエージェントシステム 神経系 非線型システム論 線型システム論 オペレーティングシステム 惑星系 政治システム 感覚器 社会体系(en:Social system) 恒星系 文字 コンセプト 倍加時間 12のレバレッジ・ポイント（英語版） 制限要因 ネガティブフィードバック ポジティブフィードバック 理論分野 カオス理論 複雑系 制御理論 サイバネティックス 地球システム科学（英語版） リビングシステム（英語版） 社会技術システム（英語版） Systemics（英語版） アーバン・メタボリズム（英語版） 社会システム理論 オートポイエーシス ゲーム理論 分野 システム解析 システム生物学 システムダイナミクス システムエコロジー（英語版） システム工学 システム神経科学 システム薬理学（英語版） システム心理学（英語版） 一般システム理論 人物 ラッセル・エイコフ（英語版） ウィリアム・ロス・アシュビー ベラ・バナシー（英語版） グレゴリー・ベイトソン リチャード・E・ベルマン スタッフォード・ビーア ルートヴィヒ・フォン・ベルタランフィ マレー・ボーエン（英語版） ケネス・E・ボールディング チャールズ・ウェスト・チャーチマン（英語版） ジョージ・ダンツィーグ ハインツ・フォン・フェルスター（英語版） ジェイ・フォレスター ジョージ・クリアー（英語版） エドワード・ローレンツ ニクラス・ルーマン ウンベルト・マトゥラーナ マーガレット・ミード ドネラ・メドウス（英語版） ミハイロ・メサロビッチ（英語版） ジェームス・ミラー（英語版） ハワード・オダム（英語版） タルコット・パーソンズ イリヤ・プリゴジン アナトール・ラパポート クロード・シャノン フランシスコ・バレーラ ケビン・ウォーリック（英語版） ノーバート・ウィーナー アンソニー・ワイルデン（英語版） チャールズ・A・S・ホール（英語版） 応用 人類学でのシステム理論(英語版) 考古学でのシステム理論(英語版) 政治学でのシステム理論(英語版) システム システム理論 システム科学 Commons