データベース
大規模なエンタープライズDBMSでは、サイズや機能が増大する傾向があり、その生涯を通じて数千人年の開発努力が費やされることがあるこの記事では、DB2リリース9単独で750人が関与した5年間の開発期間を引用している。。
初期のマルチユーザーDBMSでは、一般的に、アプリケーションを同じコンピュータ上で動作させ、コンピュータ端末または端末エミュレーションソフトウェアを通じてアクセスすることしかできなかった。クライアント・サーバー・アーキテクチャは、アプリケーションはクライアントのデスクトップ上にあり、サーバー上に存在するデータベースが処理を分散できるように開発された。これが進化して、アプリケーションサーバーやウェブサーバーを組み込んだ多層アーキテクチャとなり、エンドユーザーインターフェイスはウェブブラウザーを介してアクセスし、データベースは隣接する層に直接接続されるのみとなった。
汎用DBMSは、公開のアプリケーション・プログラミング・インタフェース(API)と、オプションでSQLなどのデータベース言語用のプロセッサを提供して、データベースと対話し操作するアプリケーションを作成できるようにする。特殊用途のDBMSは、プライベートなAPIを使用し、特別にカスタマイズして単一のアプリケーションにリンクされることがある。たとえば、電子メールシステムは、メッセージの挿入、削除、添付ファイルの処理、ブロックリストの検索、メッセージと電子メールアドレスの関連付けなど、汎用DBMSの機能の多くを実行するが、これらの機能は電子メールの処理に必要なものに限定されている。
データベースとの外部相互作用は、DBMSと接続するアプリケーション・プログラムを介して行われる。アプリケーションは、ユーザーが文字的または視覚的にSQLクエリを実行できるデータベースツールから、情報を格納し検索するためにデータベースを使用するWebサイトまで、多岐にわたる。
プログラマーは、アプリケーション・プログラミング・インタフェース(API)またはデータベース言語を介して、データベース(データソースと呼ばれることもある)との相互対話をコーディングする。選択された特定のAPIや言語は、DBMSによって直接的にサポートされるか、またはプリプロセッサまたはブリッジングAPIを介して間接的にサポートされる必要がある。APIの中にはデータベースに依存しないことを目的とするものもあり、ODBCはそのよく知られた例である。その他の一般的なAPIには、JDBCやADO.NETがある。
データベース言語は、次のような作業を可能とする特殊用途の言語であり、部分言語として区別されることもある。
データ制御言語(DCL)- データへのアクセスを制御する。
データ定義言語(DDL)- テーブルの作成、変更、削除などのデータ型の定義や、テーブル間の関係を定義する。
データ操作言語(DML)- 発生データの挿入、更新、削除などの作業を実行する。
データ問い合わせ言語(DQL)- 情報を検索し、派生情報を導出できる。
データベース言語は、特定のデータモデルに特化した言語である。著名な例として次のものがある。
SQLは、データ定義、データ操作、およびクエリ(問い合わせ)の役割を1つの言語で兼ね備えたものである。SQLは、コッドによって説明されたリレーショナルモデルとはからいくつかの点で異なっているが(たとえば、テーブルの行と列を並び替えることができる)、リレーショナルモデルの最初の商用言語の1つである。SQLは1986年に米国規格協会(ANSI)標準となり、1987年に国際標準化機構(ISO)標準となった。この標準はそれ以降も定期的に強化されており、すべての主流の商用リレーショナルDBMSによってサポートされている(適合性の程度はさまざまである)。
OQLは、オブジェクトモデル言語標準である(Object Data Management Groupによる)。これは、JDOQLやEJB QLなどの新しいクエリ言語の設計に影響を与えている。
XQueryは、MarkLogicやeXistなどのXMLデータベースシステム、OracleやDb2などのXML機能を備えたリレーショナルデータベース、およびSaxonなどのインメモリXMLプロセッサで実装された標準のXMLクエリ言語である。
SQL/XMLは、XQueryとSQLを組み合わせたものである。
データベース言語には、次のような機能を組み込んでいるものもある。
DBMS固有の構成やストレージエンジンの管理。
クエリ結果を変更するための計算。たとえば、カウント、合計、平均、並び替え、グループ化、クロスリファレンス。
制約の適用(例: 自動車データベースでは、1台の車ごとに1種類のエンジンのみ許可される)。
プログラマーの便宜のために、クエリ言語のアプリケーション・プログラミング・インターフェース版。
データベースストレージは、データベースの物理的な実体の格納庫である。これは、データベースアーキテクチャの「内部(物理)レベル」を構成する。また、必要に応じて「内部レベル」から「概念レベル」や「外部レベル」を再構築するために必要なすべての情報(たとえばメタデータ、「データに関するデータ」、内部データ構造など)も含んでいる。デジタル・オブジェクトとしてのデータベースには、データ、構造、セマンティクス(意味)の3つの層からなる情報が含まれ、保存する必要がある。長期間に渡ってデータベース保存し、長持ちさせるために、3つの層すべてを適切に保存する必要がある。データを永続的ストレージに保存するのは、一般に、データベースエンジン(別名「ストレージエンジン」)の責任である。DBMSは通常、基盤となるオペレーティングシステムを通じてアクセスするが(多くの場合、オペレーティングシステムのファイルシステムを、ストレージ配置の仲介役として使用する)、ストレージの特性と構成設定はDBMSの効率的な運用に極めて重要であるため、データベース管理者によって密接に管理される。DBMSは、その運用中に、常に数種類のストレージ(メモリや外部ストレージ)にデータベースを常駐させている。データベースのデータと、追加の必要な情報(おそらく非常に大量にある)は、ビット列に符号化される。データは通常、概念レベルや外部レベルでの見え方とは全く異なる構造でストレージ内に存在するが、ユーザーやプログラムが必要とするとき、または必要な情報の追加形式をデータから計算するとき(例: データベースに問い合わせる時)、これらのレベルの再構築を(可能な限り)最適化するような方法で格納される。
DBMSの中には、データの格納に用いる文字エンコーディングを指定できるものがあり、同じデータベースで複数のエンコーディングを使用することができる。
データモデルをシリアル化し、選ばれた媒体に書き込めるようにするために、ストレージエンジンは、さまざまな低レベルのデータベースストレージ構造を使用する。性能を向上させるために、インデックス作成などの手法を使用することもある。従来のストレージは行指向であるが、列指向データベースや相関データベースOutline of databases#Types of databasesもある。
性能を向上させるためにストレージを冗長化することがよくある。一般的な例は、頻繁に必要とされる外部ビュー(external view)や、クエリ結果から構成されるマテリアライズド・ビュー(materialized view)の保存である。このようなビューを保存することで、必要になるたびに計算する費用を節約することができる。マテリアライズド・ビューの欠点は、元の更新されたデータベースデータと同期を維持するためにビューを更新する際に発生するオーバーヘッドと、ストレージの冗長化にかかる費用である。
データベースは、データの可用性を向上させるために、データベース・オブジェクトの複製(1つ以上のレプリケーション)によるストレージ冗長性を採用することがある。これによって、同じデータベース・オブジェクトに複数のエンドユーザーが同時アクセスした場合の性能を向上させ、また、分散データベースに部分的な障害が発生した場合の回復力を提供する。複製されたオブジェクトの更新には、オブジェクトのコピー間で同期される必要がある。多くの場合、データベース全体が複製される。
データベースセキュリティは、データベースの内容、その所有者、およびそのユーザーを保護するためのあらゆる側面を扱う。その範囲は、意図的な不正なデータベースの使用から、権限のないエンティティ(たとえば、人やコンピュータプログラムなど)による意図しないデータベースへのアクセスまで、さまざまな保護に及ぶ。
データベースアクセス制御は、データベース内のどの情報に誰が(人間または特定のコンピュータプログラム)アクセスを許可されるかを制御することを扱う。その情報には、特定のデータベースオブジェクト(例: レコード種類、特定レコード、データ構造)、特定のオブジェクトに対する特定の計算(例: クエリ種類、特定のクエリ)、または前者に対する特定のアクセス経路の使用(例: 情報にアクセスするために特定のインデックスまたは他のデータ構造の使用)が含まれる。データベースのアクセス制御は、データベース所有者から特別に許可された人員によって、保護された専用のセキュリティDBMSインタフェースを用いて設定される。
アクセス制御の管理は、個人別に直接行うことも、個人と特権 (コンピュータ)をグループに割り当てることも、(最も精巧なモデルでは)個人やグループにロール(役割)を割り当ててからロールに権限を付与することもできる。データセキュリティは、権限のないユーザーによるデータベースの閲覧や更新を阻止する。パスワードを使用すると、ユーザーはデータベース全体、または「サブスキーマ」と呼ばれる一部分へのアクセスを許可される。たとえば、従業員データベースには個々の従業員に関するすべてのデータを含めていても、あるグループのユーザーには給与データのみの閲覧を許可し、別のグループには職歴と医療データのみアクセスを許可することが可能である。DBMSがデータベースの入力、更新、問い合わせを対話的に行う方法を提供している場合、この機能によって個人データベースを管理することができる。
一般にデータセキュリティは、特定のデータチャンク(data chunk、塊)を物理的に保護すること(すなわち破損、破壊、削除から。物理的セキュリティを参照)、または、データチャンクやその一部を意味のある情報に変換すること(例: それらが構成するビット列を見て、特定の有効なクレジットカード番号を決定する。データ暗号化を参照)の両方を扱う。
変更およびアクセスのロギングは、誰がどの属性にアクセスしたか、何が変更されたか、そしていつ変更されたかを記録する。ロギングサービスは、アクセスの発生や変更の記録を保持することで、後でフォレンジックデータベース監査を行うことを可能にする。場合によっては、データベースレベルで記録するのではなく、アプリケーションレベルのコードで変更を記録することもある。セキュリティ違反の検出を試みるために監視を設定することもできる。データベース・セキュリティには多くの利点があるため、組織はこれに真剣に取り組む必要がある。組織は、ファイアウォール内への侵入、ウィルスの蔓延、ランサムウェアなどのセキュリティ違反やハッキング行為から守られる。これは、企業において、いかなる理由があっても部外者と共有することが許されない、重要な情報を保護するために役に立つ。
データベース・トランザクションは、クラッシュ(障害)からの復旧後に、ある程度の耐障害性とデータ完全性を導入するために使用することができる。データベーストランザクションは通常、データベースに対する一連の操作(データベースオブジェクトの読み込み、書き込み、レコードロックの取得や解放など)をカプセル化した作業の単位であり、データベースやその他のシステムでサポートされている抽象概念である。各トランザクションには、どのプログラム/コードの実行がそのトランザクションに含まれるかという点で、明確に定義された境界がある(トランザクションの設計者が、特別なトランザクションコマンドで決定する)。
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インタフェースを用いる)。場合によっては、アプリケーションのデータを持たない状態でデータベースが稼働し、その運用を経てデータが蓄積されることもある。
データベースを作成し、初期化し、データを入力した後は、データベースを維持する必要がある。たとえば、より良い性能を得るために、さまざまなデータベース・パラメータを変更し、データベースをデータベースチューニングする必要があるかもしれない。あるいは、アプリケーションの機能を追加するために、アプリケーションのデータ構造を変更または追加し、新しい関連アプリケーションプログラムを作成するかもしれない。
場合によっては、データベースを以前の状態に戻すことが必要となる(たとえばソフトウェアの誤りが原因でデータベースが破損していることが判明した場合や、誤ったデータで更新された場合など、さまざまな理由が考えられる)。そのために、バックアップ操作が時々または継続的に実施され、それぞれの望ましいデータベースの状態(すなわち、データ値とデータベースのデータ構造への埋め込み)が専用のバックアップファイルに保持される(これを効果的に行うための多くの技術が存在する)。データベース管理者がデータベースをこの状態に戻すと決めたとき(たとえば、データベースがこの状態にあった時、所望の時点を指定する)、これらのファイルをその状態を復元するために使用する。
ソフトウェア検証のための静的解析技術は、クエリ言語の領域にも適用することができる。特に、抽象解釈フレームワークは、適切な近似技術をサポートする方法として、リレーショナルデータベースのクエリ言語の分野に拡張されている。クエリ言語のセマンティクスは、データの具体的な領域(ドメイン)を適切に抽象化することによって調整することができる。リレーショナルデータベースシステムの抽象化は、特に、細粒度アクセス制御や、電子透かしなどのセキュリティ分野で、多くの興味深い応用がある。
DBMSのその他の機能として、次のようなものもあげられる。
データベースログ - これは実行された機能の履歴を残すのに役立つ。
グラフィックコンポーネント - 特にデータウェアハウスシステムで、グラフやチャートを作成するためのもの。
クエリオプティマイザ - すべてのクエリに対してクエリを最適化し、クエリ結果を効率的に得るための実行計画(手順の部分的な順序(ツリー))を選択する。特定のストレージエンジンに特化することもある。
データベース設計、アプリケーションプログラミング、アプリケーションプログラムの保守、データベース性能分析および監視、データベース構成監視、DBMSハードウェア構成(DBMSや関連データベースはコンピュータ、ネットワーク、ストレージ装置にまたがる場合がある)および関連するデータベースマッピング(特に分散DBMS)、ストレージ割り当てとデータベースレイアウトの監視、ストレージ移行のためのツールまたはフック。
データベース管理とソース管理のために、ビルド、テスト、デプロイメントフレームワークに、これらの中心機能をすべて組み込んだ単一システムを求める声はますます高まっている。ソフトウェア業界における別の進化を借りて、そうした製品を「データベース用DevOps」として提供する企業もある。
データベース設計者の最初の作業は概念データモデルConceptual schemaの作成で、データベースに保持する情報の構造を反映する。そのための一般的な方法は、描画ツールを用いて実体関連モデルを作成することが多い。統一モデリング言語(UML)の使用は、もう一つのよく知られた方法である。出来のよいデータモデルは、モデル化される外界の可能な状態を正確に反映する。たとえば、人々が複数の電話番号を持つことができる場合、その情報を取得することが可能となる。優れた概念データモデルを設計するには、アプリケーションの領域を十分に理解する必要がある。それには、一般的に、組織が関心を持っていることについて深い問いを立てる必要がある。たとえば「顧客は発注先にもなり得るのか?」、あるいは「ある製品が2種類の包装形態で販売されている場合、それらは同じ製品か、それとも異なる製品なのか?」、あるいは「飛行機がニューヨークからフランクフルト経由でドバイまで飛ぶ場合、それは1便か2便か(または3便か)?」のような質問をする。これらの質問に対する回答によって、エンティティ(顧客、製品、フライト、フライト区間)に使用される用語の定義、およびそれらの関係や属性を確立する。
概念データモデルを作成する過程で、ビジネスプロセスからの入力や、組織内のワークフロー分析からの入力が必要な場合がある。これによって、データベースにどのような情報が必要で、何を省略できるかを特定することができる。たとえば、データベースに現在のデータだけでなく、過去の履歴データも保持する必要があるかどうかを決定するのに役立つ。
ユーザーが満足できる概念データモデルを作成したら、次の段階では、これをデータベース内の関連データ構造を実装するスキーマに変換する必要がある。この過程は、しばしば論理データベース設計と呼ばれ、スキーマの形で表現された論理データモデルを作成する。概念データモデルがデータベース技術の選択と関係しないのに対し(少なくとも理論的には)、論理データモデルは、選択したDBMSがサポートする特定のデータベースモデルの観点で表現される。(データモデルとデータベースモデルという用語はしばしば同じ意味で用いられるが、この記事では特定のデータベースの設計を「データモデル」、その設計を表現するために用いられるモデリング表記を「データベースモデル」とそれぞれ呼ぶ。)
汎用データベースで最も普及しているデータベースモデルはリレーショナルモデル、より正確には、SQL言語で表現されるリレーショナルモデルである。このモデルを用いて論理データベースを設計する過程では、正規化と呼ばれる系統的アプローチが用いられる。正規化の目的は、挿入、更新、削除の一貫性を自然に維持することで、おのおのの基本的「事実」を一箇所にのみ記録することでなされる。
データベース設計の最終段階では、特定のDBMSに依存する性能、スケーラビリティ、回復、セキュリティなどに影響する決定をする。これはしばしば「物理データベース設計」と呼ばれ、物理データモデルを作成する。この段階での重要な目標はデータの独立性である。これは、性能を最適化するために行われた決定を、エンドユーザーやアプリケーションから見えないようにすることを意味する。データの独立性には2つのタイプがあり、物理的なデータ独立性と論理的なデータ独立性である。物理設計は主に性能要件によって推進され、予想される作業負荷とアクセスパターンに関する十分な知識と、選択したDBMSが持つ機能についての深い理解を必要とする。
物理データベース設計のもうひとつの側面はセキュリティである。これには、データベースオブジェクトへのアクセス制御を定義することと、データ自体のセキュリティレベルとメソッド(手順)の定義の両方を含んでいる。
データベースモデルとは、データベースの論理構造を決定するデータモデルの一種で、データをどのように格納、整理、操作するかの根本を規定するものである。データベースモデルの最も一般的な例は、テーブルベースの形式を使用するリレーショナルモデル(またはリレーションを近似したSQL)である。
データベースの一般的な論理データモデルを次にあげる。
オブジェクトリレーショナルデータベースは、この2つの関連する構造を組み合わせたものである。
物理データモデルを次にあげる。
その他、次のようなモデルがある。
特定の種類のデータ用に最適化された特殊モデルがある。
データベース管理システムは、データベースのデータに対して三層のビューを提供する。3層の分け方はいくつかの種類があり、次の説明は、外部-概念-内部の3層に分けているが、他にも概念-論理-物理の3層に分けた説明もある。
外部レベル(external level)では、エンドユーザーの各グループがデータベース内のデータ構成をどのように見るかを定義する。1つのデータベースは、外部レベルで任意の数のビューを持つことができる。
概念レベル(conceptual level)では、さまざまな外部レベルのビューを、適合性のある単一の大域的ビューに統一化する。概念レベルのビューは、すべての外部ビューを組み立てる。それは、データベースのさまざまなエンドユーザーの範囲外であり、むしろデータベースアプリケーション開発者やデータベース管理者にとって興味対象である。
内部レベル(internal level)または物理レベル(physical level)とは、DBMS内におけるデータの内部編成のことである。これは費用、性能、スケーラビリティ、その他の運用上の事項に関与している。このレベルでは、データの記憶領域配置を扱い、性能を向上させるためにインデックス(索引)などの格納構造を用いる。冗長性に対する性能上の正当性が認められる場合は、一般的なデータから計算された個々のビュー(マテリアライズド・ビュー)のデータを格納することもある。すべての活動において、全体的な性能を最適化するために、すべての外部ビューの性能要件(競合する可能性のある)の間でバランスをとる。
データの概念ビュー(または論理ビュー)および物理ビュー(または内部ビュー)は、通常、1つしかないが、さまざまな外部ビューはいくつでも存在することができる。これにより、ユーザーは、技術的あるいは処理的な視点からではなく、よりビジネスに関連した視点からデータベース情報を見ることができるようになる。たとえば、企業の財務部門は会社の経費の一部として全従業員の支払明細を必要とするが、人事部門の関心事である従業員に関する明細は必要ない。このように、部門によって、企業データベースには異なるビューが必要となる。
三層データベース・アーキテクチャは、リレーショナルモデルの主要な初期推進力の1つであったデータの独立性の概念に関連している。この考え方は、あるレベルで行われた変更は、より高いレベルのビューに影響を与えないというものである。たとえば、内部レベルの変更は、概念レベルのインタフェースを使用して記述されたアプリケーションプログラムには影響しないので、性能を向上させるために物理的変更を加えてもその影響を軽減することができる。
概念ビューは、内部ビューと外部ビューの間に間接的なレベルを提供する。一方では、異なる外部ビュー構造に依存しないデータベースの共通ビューを提供し、また他方では、データがどのように格納され管理されるかという詳細(内部レベル)を抽象化する。原則として、すべてのレベルの、さらにはすべての外部ビューは、異なるデータモデルで表現することができる。実際には通常、特定のDBMSは外部レベルと概念レベルの両方で同じデータモデルを使用する(例: リレーショナルモデル)。内部レベルは特定のDBMSの内側に隠されており、(その実装にも依存するが)異なるレベルの詳細が要求され、独自の種類のデータ構造型が用いられる。
外部、概念、および内部レベルを分離することは、21世紀のデータベースを支配するリレーショナルデータベースモデルの実装における大きな特徴であった。
データベース技術は、1960年代から、学界や企業の研究開発グループ(例: IBM基礎研究所)の両方で活発な研究課題となっている。研究活動には、データベース理論やプロトタイプの開発が含まれる。注目すべき研究課題には、モデル、アトミックトランザクションの概念、関連する並行性制御技術、クエリ言語とクエリ最適化手法、RAIDがある。
データベース研究分野には、いくつかの専門学術誌や(例: ACM Transactions on Database Systems-TODS、Data and Knowledge Engineering-DKE)、年次会議(例: ACM SIGMOD、ACM PODS、VLDB、IEEE ICDE)がある。
日本の学会としては、日本データベース学会があげられる。