基本情報技術者単語帳 - データベース

コンピュータ上でソフトウェアによって管理され、特定の構造や形式に従って同種のデータ群を蓄積したものを指すことが多い。「データベース」の語は文脈によって、実際に蓄積されたデータの集合体そのものを指す場合と、これを管理する「データベース管理システム」(DBMS：Dababase Management System)を指す場合、両者やデータを利用するアプリケーションソフトなどを含めたシステム全体を指す場合がある。

DBMSは管理者が設定した一定の形式や構造に従ってデータをストレージ装置などに記録・蓄積するシステムで、大量のデータを系統立てて保管することができる。必要に応じて検索、抽出、加工することができるため、企業の情報システムのデータ管理の中核として利用されることが多い。

リレーショナルデータベース

データベースにはデータをどのような構造や方式で格納、管理するかによって様々な種類がある。今日最も一般的に利用されるのは「リレーショナルデータベース」(RDB：Relational Database/関係データベース)と呼ばれるもので、一件のデータを複数の属性の値の組として表現し、組を列挙することでデータを格納していく。属性を列、組を行とする表(テーブル)の形で示されることが多い。

RDBの操作は「SQL」(Structured Query Language)と呼ばれる専用の問い合わせ言語で行われることが多い。命令語と操作対象、条件などを連ねてDBMSに指示を与える言語で、テーブルの作成や削除、テーブルへのデータの追加や上書き、削除、DBMS自体の設定の変更などの操作を行うことができる。

リレーショナルデータベースを管理するためのDBMSのことを「リレーショナルデータベース管理システム」(RDBMS)という。Microsoft AccessやFileMaker Proのようなデスクトップアプリケーションから、企業などの情報システムで専門の技術者が運用するOracle DatabaseやMicrosoft SQL Server、MySQL、PostgreSQLなどのサーバアプリケーションまで様々な規模、機能の製品がある。

リレーショナルデータモデル(関係データモデル)と呼ばれる数学的なモデルに基づいてデータを秩序立てて格納したデータ集合である。一件の登録単位は複数の属性(attribute)の組(tuple)で、同じ属性を持つ組を何件も集めたデータの集合体をリレーション(関係)という。

これは実際には縦横に項目が並んだ表(テーブル)の形で整理される。リレーションが表に相当し、属性を縦方向に並んだ列(column)、組を横方向に並んだ行(row)として表す。システムによっては行を「レコード」(record)、列を「フィールド」(field)と呼ぶこともある。

実際のデータベースは「顧客マスタ」「製品マスタ」「受注明細」のように複数の表の集合として管理されることが多い。「受注明細の顧客IDは顧客マスタを参照する」といったように複数の表にまたがって同じ属性を配置し、対応付けて管理することができ、複雑なデータや大規模なデータを柔軟に取り扱うことができる。

RDBMSによる管理

関係データベースはRDBMS(Relational Database Management System：リレーショナルデータベース管理システム)と呼ばれる専用のソフトウェアによって作成・運用されることが多い。データベースの管理はRDBMSが行い、他のソフトウェアは必要なときにRDBMSへ接続して操作を依頼する。

RDMBSへの指示には「SQL」(Structured Query Language)という問い合わせ言語が標準的に用いられ、データベースの作成や削除、テーブルへのデータの追加や更新、指定した条件を満たすデータ集合の抽出などの操作を行なうことができる。

著名なRDBMSとしては、米オラクル(Oracle)社の「Oracle Database」、米マイクロソフト(Microsoft)社の「SQL Server」、米IBM社の「Db2」などの商用ソフトウェア製品、オープンソースで配布されている「MySQL」「MariaDB」「PostgreSQL」などが知られる。

個人や小集団で利用する「Microsoft Access」や米クラリス(Claris)社の「FileMaker Pro」のようなデスクトップデータベース製品や、RDBMSをクラウドサービスとして提供する米アマゾンドットコム(Amazon.com)社の「Amazon RDS」「Amazon Aurora」などもある。

歴史

関係データベースの基礎となる理論は1969年に米IBM社のエドガー・コッド(Edgar F. Codd)氏が提唱したリレーショナルデータモデル(relational data model)で、これを元に開発されたRDBMSが1980年頃から当時の大型コンピュータ向けのソフトウェアとして普及し始めた。

1990年代以降は他の方式を圧倒し、企業などが情報システムでデータの記録や管理を行う際の標準的な手法として広まった。近年では、用途によっては「NoSQL」(Not only SQL)と総称される非リレーショナル型の方式が導入される事例も増えている。

起点であるルートノードに複数の子ノード(の記憶装置上での所在)が登録され、子ノードはさらに複数の子ノードを持つことができる。どのノードにとっても親ノードは一つで、親をたどっていくとルートノードに行き着く。

特定のノードを指定して内容を読み書きする操作を高速に行なうことができ、記憶領域の利用効率も良いが、データ全体から条件を指定してノードを絞り込む操作は苦手(標準的な方法がなくアプリケーション次第)で、子が複数の親を持つことができないなど柔軟性にも欠ける。

リレーショナルデータベース(関係データベース)の発明以前から存在する米IBM社のメインフレーム向けデータ管理システム「IMS」(Information Management System)が有名だが、SNMPで用いられるMIB(Management Information Base)なども一種の階層型データベースであると考えることができる。

一連の属性から成るデータのまとまり(レコード)を格納単位とし、レコード間は親子関係を持つが、各レコードは親レコードも子レコードも複数持つことができるため、必要に応じて関連する他の種類のレコードを参照することができる。

1970年代に考案された方式で、それ以前に主流だった「階層型データベース」ではレコード間を親子関係(親は必ず一つ)で結びつける木構造で管理していたが、ネットワーク型は親レコードを複数持つことができるため、現実世界のデータの関係に即した柔軟なモデリングが可能となった。

1980年代になるとデータの組を行と列を組み合わせた表のような形式で表現する「リレーショナルデータベース」が台頭し、商用データベース製品の主流の方式として定着したため、ネットワーク型が顧みられることはなくなった。2010年代には、データの繋がりを網状に表現できるという点は網型データベースに似ているが、より抽象度や柔軟性が高い「グラフデータベース」が登場し、リレーショナル型が苦手とする分野で活躍している。

オブジェクト指向データベースに格納されたデータ群はオブジェクト指向プログラミング言語からそのままの形で直に操作、参照することができ、リレーショナルデータベース(RDB/RDBMS)などで必要なデータ形式の変換や対応付け(O/Rマッピング)、問い合わせ言語による操作指示などが不要で、データ構造の変更などに柔軟に対応できるなどの長所がある。

ただし、特定のプログラミング言語から利用を前提としてシステムが多く、他の環境や言語から利用しにくい場合があるほか、データ構造が特定のアプリケーションの設計と密接に結びついているため、様々なプログラムから同じデータベースを利用するような用途には向かない。

オブジェクト指向データベースは異なる種類・形式のデータが混在するデータ群や、多数のデータが一体的に結び付いたデータ構造の格納に適している。特定の言語で開発されたシステムが取り扱う複雑な構造のデータを高速に処理する用途や、CADシステムやマルチメディアデータベースなどでの応用がよく知られている。

オブジェクト指向データベースを作成・管理するためのデータベース管理システム(DBMS)は「オブジェクト指向データベース管理システム」(OODBMS：Object-Oriented Database Management System)という。著名な製品には米オブジェクティビティ(Objectivity)社の「Objectivity/DB」や米インターシステムズ(InterSystems)社の「Caché」などがある。

オブジェクト指向データベースとしての機能に加え、問い合わせ言語としてSQLを利用できるなどリレーショナルデータベースとしての特徴を兼ね備えたものは「オブジェクトリレーショナルデータベース」(ORDB：Object-Relational Database)、その管理システムは「オブジェクトリレーショナルデータベース管理システム」(ORDBMS：Object-Relational Database Management System)と呼ばれる。

同じ施設の複数のサーバなどに、あるいは、地理的に離れた施設に設置されたサーバなどにレプリケーション機能などでデータを分散して管理する。データの転送や複製は利用者やアプリケーションからは透過的に行われ、どのサーバに接続しても単一のデータベースであるかのように振る舞う。

複数のコンピュータでデータ管理を行うことで、可用性を高めることができる。一部の機器が停止しても他の機器を用いて外部に対するサービス提供を継続することができ、装置の故障などでデータを喪失する危険も減少する。

また、データの読み出しは複数のシステムで並列に行うことができるため、台数を増やせば全体としての性能を向上させることができる。世界的に利用されるサービスでは、データを地理的に分散させることで利用者や端末に近い場所からサービスを提供することができ、通信遅延の低減や回線資源の節約に繋がる。

一方、分散システム一般の性質として、CAP定理により一貫性(Consistency)、可用性(Availability)、分断耐性(Partition-tolerance)の3つのうちいずれか2つしか同時に確保することができないため、厳密な整合性が求められるような処理には向いていない。また、システム構成が複雑になれば、その分だけ管理・運用にかかるコストや手間、セキュリティ上の懸念は増大する。

ここで言う「グラフ」は円グラフや棒グラフといったデータ集合を図で表したものではなく、コンピュータ科学のグラフ理論で取り扱われるデータ構造の一つである。データの集まりを「ノード」(node)「プロパティ」(property)「エッジ」(edge)の3要素の組み合わせとして表現する。

ノードは意味のあるデータ集合の単位(例：ユーザー情報)で、何らかの属性を表すプロパティ(例：ID、氏名、メールアドレス)を持つ。ノードは他のノードと何らかの繋がり(例：友達関係、フォロー関係)を持っており、ノード間の繋がりをエッジという。

構造と特徴

グラフデータベースはデータ集合をグラフ構造に従って格納するデータベースで、各ノードのプロパティとエッジの情報を保管する。ノードを指定してプロパティの書き込みや読み出しを行ったり、あるノードから繋がっている別のノードを素早く参照することができる。

例えば、SNSのユーザー情報で、あるユーザーの友達、友達の友達、友達の友達の友達…と繋がりをたどって関連ノードを挙げていく処理を一般的なリレーショナルデータベースで行うと負荷が大きく時間がかかるが、グラフデータベースでは瞬時に関連ノードを割り出して参照することができる。

一方、リレーショナルデータベースが得意な、プロパティについての条件を指定してノードを検索したり、ノード全体を対象に特定のプロパティの値を集計するといった使い方は難しい。実用上は、大規模で複雑な「繋がり」を含むデータ構造を取り扱う場合に特化して用いられる。

種類と応用

グラフデータベースを実装するための代表的なデータモデルとして「プロパティグラフ」と「RDFグラフ」(RDF：Resource Description Framework)がある。著名な製品としては「Neo4j」「JanusGraph」などがよく知られる。「Amazon Neptune」「Azure Cosmos DB」のようにクラウド上でグラフデータベースを提供するサービスもある。

グラフデータベースの主な応用分野として、SNSなどのソーシャルメディアにおけるユーザー間の繋がりの管理や分析、ECサイトなどで「おすすめ」を表示するリコメンデーション機能、移動や配送などにおける最適な経路の探索、金融機関などで取引情報を分析して不正を検知する機能などが挙げられる。

保存したい値(value)に対して標識となるキー(key)を設定し、両者をセットでストレージなどに書き込む。読み出し時にはキーを指定すると対応する値を取り出すことができる。既存のキーを指定して書き込むと新たな値で上書きされる。

値やキーに指定できるデータの種類は処理系によって異なり、キーは参照や識別がしやすいよう数値や文字列などが用いられることが多い。値には単純なデータ型やバイト列を指定できることが多いが、複雑なデータ構造やオブジェクトなどを格納できるものもある。構造的なデータを一定の決まった手順で文字列やバイト列に変換(シリアライズ)して保存する処理系もある。

一意のキーに値を対応付けて保存するデータ構造は多くプログラミング言語で連想配列、辞書(ディクショナリ)、ハッシュ、マップなどの名称で提供されてきており、キーバリュー型データベースはこの仕組みを永続的なデータ管理システムに応用したものと考えることもできる。

伝統的なリレーショナルデータベース(RDB)に代わるデータ管理システムは「NoSQL」(RDBの操作を行うSQL言語を用いないという意味)と総称され、キーバリュー型データベースはそのなかでも最も手軽で汎用的な方式として広く浸透している。複数のサーバや記憶装置などに分散してデータを保存できる機能を持ったものもあり、「分散KVS」(distributed KVS)と呼ばれる。

インメモリデータベースでは原則としてすべてのデータをメモリ上に展開し、データの読み込みや追加、変更、削除をすべてメモリ上で完結させることで、従来型の数百倍から数万倍も高速に処理を実行することができる。ただし、メモリ上のデータは電源を切ると失われてしまうため、システムの終了・再起動時や一定時間ごとなどに、メモリ上の内容をストレージに保存してデータの永続性を確保する機能が搭載されている。

また、トランザクションログや変更履歴(ジャーナル)などをストレージに記録したり、ネットワークを通じて別のコンピュータにデータベースの複製を取るレプリケーション機能などにより、不意な電源断などで内容が失われても、なるべく直近の状態を復元できるよう配慮されていることが多い。

オンディスクデータベース (on-disk database/disk-based database)

従来型のストレージに記録されるデータベースのことをオンディスクデータベースと呼ぶことがある。英語では “on-disk database” の他に “disk-based database” などとも呼ばれる。ほとんどのデータベースシステムはこの方式であるため、このような呼び方をするのはインメモリデータベースと対比する文脈にほぼ限られる。データ容量や設定などによりインメモリとしてもオンディスクとしても動作するハイブリッド型のデータベース製品もある。

データベースの構造を定義したものをスキーマ(schema)というが、データモデルの設計や管理のために抽象度の異なる複数のスキーマを定義して使い分ける場合がある。これを3段階の階層型の構造としたものを3層スキーマという。

概念-論理-物理の3層とする場合、まず概念スキーマでデータベースによって扱おうとする概念および概念間の関係などを定義する。次に論理スキーマによって概念スキーマで定義された概念やその関係について、特定のデータモデルを用いて表現する。最後に物理スキーマで論理スキーマに規定されたデータ集合の具体的な格納・管理方式を定義する。

ANSI/SPARC 3層スキーマ

スキーマを外部-概念-内部の3階層で表現する著名なモデルに「ANSI/SPARC 3層スキーマ」がある。米国国家規格協会(ANSI)の標準化計画要求委員会(SPARC)が1975年に提唱した方式で、データの論理的および物理的な独立性の確保を主眼としている。

外部スキーマは利用者が必要とするデータの抜き出し方と並べ方を定義する。これはリレーショナルデータベース(RDB)ではビューなどに相当する。概念スキーマはデータ全体の論理的な構造を定義するもので、RDBではテーブルなどに相当する。内部スキーマは記憶装置やデータファイル上でのデータの配置や格納方法について定義する(RDBではRDBMSの内部仕様となる)。

アプリケーションなどからは外部スキーマを介してデータにアクセスすることで、概念スキーマが変更されても影響を最小限に抑えることができる(論理的独立性)。一方、データを内部スキーマを介して記憶装置に記録することにより、データの論理的な構造を装置の物理的な構造から分離することができる(物理的独立性)。

データベースの構造を定義したものをスキーマ(schema)というが、データモデルの設計や管理のために抽象度の異なる複数のスキーマを定義して使い分ける場合がある。これを3段階の階層型の構造としたものを概念スキーマという。

概念-論理-物理の3層とする場合、まず概念スキーマでデータベースによって扱おうとする概念および概念間の関係などを定義する。次に論理スキーマによって概念スキーマで定義された概念やその関係について、特定のデータモデルを用いて表現する。最後に物理スキーマで論理スキーマに規定されたデータ集合の具体的な格納・管理方式を定義する。

ANSI/SPARC 3層スキーマ

スキーマを外部-概念-内部の3階層で表現する著名なモデルに「ANSI/SPARC 3層スキーマ」がある。米国国家規格協会(ANSI)の標準化計画要求委員会(SPARC)が1975年に提唱した方式で、データの論理的および物理的な独立性の確保を主眼としている。

外部スキーマは利用者が必要とするデータの抜き出し方と並べ方を定義する。これはリレーショナルデータベース(RDB)ではビューなどに相当する。概念スキーマはデータ全体の論理的な構造を定義するもので、RDBではテーブルなどに相当する。内部スキーマは記憶装置やデータファイル上でのデータの配置や格納方法について定義する(RDBではRDBMSの内部仕様となる)。

アプリケーションなどからは外部スキーマを介してデータにアクセスすることで、概念スキーマが変更されても影響を最小限に抑えることができる(論理的独立性)。一方、データを内部スキーマを介して記憶装置に記録することにより、データの論理的な構造を装置の物理的な構造から分離することができる(物理的独立性)。

データベースの構造を定義したものをスキーマ(schema)というが、データモデルの設計や管理のために抽象度の異なる複数のスキーマを定義して使い分ける場合がある。これを3段階の階層型の構造としたものを外部スキーマという。

概念-論理-物理の3層とする場合、まず概念スキーマでデータベースによって扱おうとする概念および概念間の関係などを定義する。次に論理スキーマによって概念スキーマで定義された概念やその関係について、特定のデータモデルを用いて表現する。最後に物理スキーマで論理スキーマに規定されたデータ集合の具体的な格納・管理方式を定義する。

ANSI/SPARC 3層スキーマ

スキーマを外部-概念-内部の3階層で表現する著名なモデルに「ANSI/SPARC 3層スキーマ」がある。米国国家規格協会(ANSI)の標準化計画要求委員会(SPARC)が1975年に提唱した方式で、データの論理的および物理的な独立性の確保を主眼としている。

外部スキーマは利用者が必要とするデータの抜き出し方と並べ方を定義する。これはリレーショナルデータベース(RDB)ではビューなどに相当する。概念スキーマはデータ全体の論理的な構造を定義するもので、RDBではテーブルなどに相当する。内部スキーマは記憶装置やデータファイル上でのデータの配置や格納方法について定義する(RDBではRDBMSの内部仕様となる)。

アプリケーションなどからは外部スキーマを介してデータにアクセスすることで、概念スキーマが変更されても影響を最小限に抑えることができる(論理的独立性)。一方、データを内部スキーマを介して記憶装置に記録することにより、データの論理的な構造を装置の物理的な構造から分離することができる(物理的独立性)。

データベースの構造を定義したものをスキーマ(schema)というが、データモデルの設計や管理のために抽象度の異なる複数のスキーマを定義して使い分ける場合がある。これを3段階の階層型の構造としたものを内部スキーマという。

概念-論理-物理の3層とする場合、まず概念スキーマでデータベースによって扱おうとする概念および概念間の関係などを定義する。次に論理スキーマによって概念スキーマで定義された概念やその関係について、特定のデータモデルを用いて表現する。最後に物理スキーマで論理スキーマに規定されたデータ集合の具体的な格納・管理方式を定義する。

ANSI/SPARC 3層スキーマ

スキーマを外部-概念-内部の3階層で表現する著名なモデルに「ANSI/SPARC 3層スキーマ」がある。米国国家規格協会(ANSI)の標準化計画要求委員会(SPARC)が1975年に提唱した方式で、データの論理的および物理的な独立性の確保を主眼としている。

外部スキーマは利用者が必要とするデータの抜き出し方と並べ方を定義する。これはリレーショナルデータベース(RDB)ではビューなどに相当する。概念スキーマはデータ全体の論理的な構造を定義するもので、RDBではテーブルなどに相当する。内部スキーマは記憶装置やデータファイル上でのデータの配置や格納方法について定義する(RDBではRDBMSの内部仕様となる)。

アプリケーションなどからは外部スキーマを介してデータにアクセスすることで、概念スキーマが変更されても影響を最小限に抑えることができる(論理的独立性)。一方、データを内部スキーマを介して記憶装置に記録することにより、データの論理的な構造を装置の物理的な構造から分離することができる(物理的独立性)。

業務などで使用するシステムは様々な現実の存在を反映したデータを取り扱うが、システムの利用目的に照らして必要な情報(だけ)を、コンピュータプログラムによる自動処理に適した構造や形式で記録する必要がある。

現実の存在をどのようにデータとして表現するかを定めた取り決めがデータモデルで、データベースを用いたシステム開発などの際に設計作業の一環として作成される。データモデルを作成することを「データモデリング」(data modelling)という。

データモデルの表現形式や構築法には様々な手法があるが、例えば「ERモデル」(Entity-Relationship Model)を用いる場合、対象のうち名詞として表されるものを「実体」(entity)、実体間の関連性を「関係」(relation)、実体や関連の持つ性質を「属性」(attribute)として整理する。作成したモデルはER図などの形で図示して関係者間で共有することが多い。

人間による世界解釈からコンピュータの記憶装置上でのデータ構造へ落とし込んでいくため、対象全体を大まかにモデル化した「概念データモデル」、システム上で取り扱うデータをすべて詳細に定義した「論理データモデル」、論理データモデルをコンピュータ上の具体的な記録形式に変換した「物理データモデル」の三段階で詳細化する方式が用いられることがある。

企業などの情報システムではデータモデルが表すデータの格納先としてリレーショナルデータベース(RDB)が用いられることが多く、データモデルをもとに具体的なデータベーススキーマなどを設計し、データベース管理システム(DBMS)上でテーブルの構築などをしていく。

関係モデルでは、一件のデータを複数の値を紐付けた「組」(tuple)として表現する。それぞれの値は「属性」(attribute)に所属しており、組の中では属性名を使って指し示すことができる。各属性はどのような値を取りうるかを定めた定義域(domain)を持つ。

この「組」と「属性」で整理されたデータ集合全体のことを「関係」(relation)と呼ぶ。関係のことを、属性のみが定義された、データの入れ物としての「関係変数」(relation variable)と、関係変数に具体的に0個以上の組を代入した「関係値」(relation value)に分けて考える場合もある。

関係モデルは集合論に基づいており、関係代数による関係同士の演算が可能である。基本的な演算として「和」(和集合を求める)、「差」(差集合を求める)、「交差」(積集合を求める)、「直積」(デカルト積を求める)、「制限」(条件に合う集合を抽出する)、「射影」(特定の属性だけ抽出する)、「結合」(条件に従って組み合わせる)、「商」(直積の逆演算)などがある。

RDBのテーブル

リレーショナルデータベースでは「テーブル」(table)と呼ばれる2次元の表を用いて関係モデルを具体的なデータ構造として記録する。関係モデルにおける組はテーブルにおける「行」(row)に、属性は「列」(column)に、定義域は「データ型」(data type)に、それぞれほぼ相当する。

ただし、テーブルと関係は厳密には同じ概念ではない。例えば、関係における組や属性の並びに順序は無いがテーブルでは順序が設定される、関係では行の重複(すべての値が同一である組を複数持つ)はできないがテーブルではできる、関係では値の不存在は許されないがテーブルではできる(Null値)、などの点が異なっている。

起点であるルートノードに複数の子ノード(の記憶装置上での所在)が登録され、子ノードはさらに複数の子ノードを持つことができる。どのノードにとっても親ノードは一つで、親をたどっていくとルートノードに行き着く。

特定のノードを指定して内容を読み書きする操作を高速に行なうことができ、記憶領域の利用効率も良いが、データ全体から条件を指定してノードを絞り込む操作は苦手(標準的な方法がなくアプリケーション次第)で、子が複数の親を持つことができないなど柔軟性にも欠ける。

リレーショナルデータベース(関係データベース)の発明以前から存在する米IBM社のメインフレーム向けデータ管理システム「IMS」(Information Management System)が有名だが、SNMPで用いられるMIB(Management Information Base)なども一種の階層モデルであると考えることができる。

一連の属性から成るデータのまとまり(レコード)を格納単位とし、レコード間は親子関係を持つが、各レコードは親レコードも子レコードも複数持つことができるため、必要に応じて関連する他の種類のレコードを参照することができる。

1970年代に考案された方式で、それ以前に主流だった「階層型データベース」ではレコード間を親子関係(親は必ず一つ)で結びつける木構造で管理していたが、ネットワーク型は親レコードを複数持つことができるため、現実世界のデータの関係に即した柔軟なモデリングが可能となった。

1980年代になるとデータの組を行と列を組み合わせた表のような形式で表現する「リレーショナルデータベース」が台頭し、商用データベース製品の主流の方式として定着したため、ネットワーク型が顧みられることはなくなった。2010年代には、データの繋がりを網状に表現できるという点はネットワークモデルに似ているが、より抽象度や柔軟性が高い「グラフデータベース」が登場し、リレーショナル型が苦手とする分野で活躍している。

データベースのリレーションシップ

リレーショナルデータベース管理システム(RDBMS)で、複数のテーブルの間で特定のフィールドを関連付ける機能をリレーションという。

これにより、テーブル間で同じ情報が重複するのを避けることができ、あるフィールドの入力を別のテーブルの特定のフィールドの項目から選択するようにしたり、複数のテーブルを連結して情報をまとめたりすることができる。

例えば、受注テーブルの顧客コードに、顧客テーブルの顧客コードを関連付ければ、顧客テーブルに登録されていない顧客コードを受注テーブルに誤って入力してしまうことを防ぐことができる。関連付けられた他のテーブル上のフィールド(この例では顧客コード)を「外部キー」(foreign key)という。

一般的なリレーションでは外部キーの各項目が複数のレコードに繰り返し登場することがあり、このような関係を「一対多リレーション」という。外部キーの各項目が一つのレコードにしか現れないよう制約する「一対一リレーション」もあるが、使われる場面は少ない。また、両テーブルのフィールドが互いに相手方へ(一対多の)リレーションを張った状態を「多対多リレーション」という場合がある。

タプル型の仕様は言語によって異なるが、複数の異なる型のデータやオブジェクトなどを格納でき、配列のように各要素に通し番号(添字)が割り振られ、これによって要素を識別するようなデータ構造を表すことが多い。

異なる型のデータの列を単一のデータのようにまとめて扱うことができるため、関数が呼び出し元に複数の戻り値を返したい場合や、複数の変数に値の組を一度にまとめて代入したい場合などに便利である。

オブジェクトのフィールド

例えば、オブジェクト指向プログラミングにおいて、オブジェクトやインスタンスの持つ固有のデータのことをフィールドということがある。言語によっては「プロパティ」(property)あるいは「メンバ変数」(member variable)と呼ぶ場合もある。

テーブルのフィールド

リレーショナルデータベースや表計算ソフトなど、データの集合を表(テーブル)の形で表すシステムでは、行やレコードを構成する個々の要素やデータ項目をフィールドという。複数行の同じフィールドを並べたものを列という。

ユーザーインターフェースのフィールド

ソフトウェアの操作画面上で、入力フォームなどを構成する個々の入力項目や書き込み欄などのことをフィールドという。特に、利用者が任意の内容を入れることができる要素をこのように呼ぶことが多く、例えば文字を入力する欄を「テキストフィールド」(text field)という。

動画やディスプレイのフィールド

インターレース走査(飛び越し走査)の映像や表示機器などで、一回の走査で書き換える画面半分のことをフィールドという。上から奇数番目あるいは偶数番目のラインの集合のことで、2フィールドの走査で画面全体が1フレーム書き換わる。毎秒60フィールドの書き換え速度の場合、毎秒30フレームの書き換えが行われる。

フレームやパケットのフィールド

プロトコル(通信規約)などで定義されたフレームやパケットなどのデータの送受信単位において、ヘッダなど制御用のデータ領域に配置された個々のパラメータのための領域をフィールドという。

データ先頭からの距離(何ビット目/何バイト目)と長さ、内容の形式などで定義され、データの宛先や送信元のアドレスなど、データの送受信に必要な制御用の情報が記録される。

ハードディスクなどのストレージ装置(外部記憶装置)内に専用の管理領域を設け、データを記録するための構造体の作成や消去、構造の修正、データの書き込み、上書き、削除などを行う。条件を指定してデータを検索したり、特定のデータの集合を抽出したりする機能も提供する。

管理者や利用者が直接操作してこれらの操作を行うほかに、外部のソフトウェアからの接続を受け付け、指示を受けてこれらの操作を行うのもDBMSの重要な機能である。データの管理にDBMSを利用することで、個別のアプリケーションソフトがデータの記録・管理機能を自前で実装する必要がなくなり、自らの役割に専念することができる。

基本的な機能の他にも、誤ったデータの記録を拒否して整合性を維持する機能や、権限のない利用者による不正なデータの盗み見や改竄を防ぐ機能、関連する複数の操作を一体的に矛盾なく実行する「トランザクション処理」機能、障害に備えてデータを複製(バックアップ)したり過去のある時点の状態を復元する機能を備えたものもある。

DBMSの種類

DBMSにはデータの記録形式(データモデル)によっていくつかの種類がある。最も広く普及しているのは「リレーショナルデータモデル」(関係データモデル)と呼ばれる方式でデータを格納する「「リレーショナルデータベース管理システム」(RDBMS：Relational Database Management System)で、単にDBMSと言えばRDBMSを指すことが多い。

代表的なRDBMS製品としては、米オラクル(Oracle)社の「Oracle Database」、米マイクロソフト(Microsoft)社の「SQL Server」、米IBM社の「Db2」などがあり、オープンソースソフトウェアとして配布されている「MySQL」や「PostgreSQL」「MariaDB」なども人気が高い。

パソコンなど利用者の操作環境上で単体のアプリケーションとして動作し、グラフィック表示(GUI)の操作・編集システムと共に提供される製品は「デスクトップデータベース」とも呼ばれる。個人やグループ単位の小規模なデータ管理に用いられ、「Microsoft Access」や米クラリス(Claris)社の「FileMaker Pro」などがよく知られる。

近年では「KVS」(Key-Value Store：キーバリューストア)や「列指向データベース」「グラフ指向データベース」「ドキュメント指向データベース」など非リレーショナル型のDBMSの増えている。RDBMSの問い合わせ言語であるSQL(Structured Query Language)に囚われないという意味で「NoSQL」(Not only SQL)と総称される。

データベースの構造や構成を定義するために用いられるものが多く、単にデータベース定義機能といった場合には、リレーショナルデータベース(RDB)の制御に用いられる問い合わせ言語の標準、SQL(Structured Query Language)の一部の命令群を指すことが多い。

SQLにおけるデータベース定義機能には、データベースやテーブル、ビューなどの作成を行うCREATE文や、これらを削除するDROP文、これらの設定や構成に変更を加えるALTER文、テーブル中のデータを全削除するTRUNCATE文が含まれる。

これに対し、定義されたデータ構造中の個々のデータを操作する言語を「DML」(Data Manipulation Language：データ操作言語)、データへのアクセス権限などを制御する言語を「DCL」(Data Control Language：データ制御言語)という。DMLにはSELECT文やINSERT文などが、DCLにはGRANT文やREVOKE文などが含まれる。

データベースへのデータの新規登録や、既存のデータの上書きや削除、条件に合致するデータの検索や抽出などを行うために用いられる。リレーショナルデータベースを管理するための標準的な言語であるSQLでは、SELECT文(検索・抽出)やINSERT文(データの追加)、UPDATE文(データの更新)、DELETE文(データの削除)などがこれに当たる。

これに対し、データを格納するための構造を定義する言語をDDL(Data Definition Language：データ定義言語)、データへのアクセス権限などを制御する言語をDCL(Data Control Language：データ制御言語)という。

データベースの登録利用者にデータの読み込み、登録、変更、削除などを行なう権限を与えたり奪ったりするのに用いられる。また、トランザクション処理などを行なう際の状態の変更や確定などを実施する際にも用いられる。

リレーショナルデータベース管理システム(RDBMS)の標準的な操作言語であるSQL(Structured Query Language)の場合、GRANT文(権限を与える)やREVOKE文(権限を奪う)、COMMIT文(トランザクションの確定)、ROLLBACK文(トランザクションの破棄)などがこれに当たる。

一方、データベース言語(および言語の構成要素)のうち、データベース内のデータ自体の操作を行うためのものは「DML」(Data Manipulation Language：データ操作言語)、データベースの構造や構成要素などを定義・変更するためのものは「DDL」(Data Definition Language：データ定義言語)という。

トランザクション処理は複数のデータ処理を一体不可分の単位として扱う実行方式で、実行の前後でデータに矛盾が無いことが要請される。実際のコンピュータシステムでは複数のトランザクションを同時に稼働させる必要があり、他のトランザクションの操作によって処理に矛盾を来さないよう適切に制御する必要がある。

原理的にまったく互いに干渉しないようにするにはトランザクションを並行に実行せず順番に実行する「直列化」(シリアライゼーション)を行えば良いが、性能が極端に下がり処理が進まなくなってしまうため現実に採用することは難しい。

そこで、アクセスしようとする資源(テーブルやレコードなど)を一時的に封鎖(ロック)して占有し、処理中は他のトランザクションのアクセスを禁じる「排他制御」が行われる。テーブル単位で行うか行単位で行うか、他のトランザクションの読み書きを完全に禁じるか読み込みは許可するのかなど、ロックの仕方には様々な種類がある。

トランザクション分離レベル

同時実行制御におけるトランザクションの並行性(高速性)と独立性(安全性)はトレードオフ(あちらを立てればこちらが立たず)の関係にあるため、それぞれをどの水準で両立(妥協)するのかについていくつかのレベル提唱されている。よく知られるSQL標準では4段階のトランザクション分離レベルを定義している。

最も安全だが性能が低いレベルが「SERIALIZABLE」で、直列化したのと同じように他のトランザクションの影響をまったく受けないよう制御する。次に安全なのが「REPEABLE READ」で、対象データを処理中に他のトランザクションが削除・更新するのを防ぐ。

3番目は「READ COMMITED」で、他のトランザクションでコミットされた値の変更の影響を受ける。最も分離レベルが低いのが「READ UNCOMMITED」で、他のトランザクションによる未コミットの変更の影響も受ける(が最も性能が高い)。

例えば、あるプログラムがストレージ上のあるファイルに書き込みを行なっている最中に、並行して実行されている別のプログラムがそのファイルへの書き込みを開始してしまうと、ファイルの内容が破壊され整合性のないものになってしまう。

このような事態を防ぐために、ファイルへの書き込みが行われている間は別のプログラムによる書き込みを禁止するという制御が行われる。このような制御は「ロック」(lock)と呼ばれ、最も有名な排他制御の方式の一つである。

排他制御は割り込み禁止機構などのハードウェア上の機能を利用して実装する場合と、プログラムの実行制御によりソフトウェア的に実装する場合がある。オペレーティングシステム(OS)やライブラリなどの中には、これを利用するプログラムに対して何らかの同期機構を提供するものもある。

OS上のプロセスやプログラム上のスレッド間でロック機構を実現する方式として「ミューテックス」(mutex)がよく用いられる。また、資源が複数個ある場合の排他制御として、プロセスが資源へのアクセスを開始・終了する度に利用可能な残り数を増減させる「セマフォ」(semaphore)が用いられることもある。

ストレージ(外部記憶装置)について言う場合は、媒体の破損などでデータが正常に読み出せなくなった機器から可能な限りデータを取り出して保全したり、故障した装置を新しいものと交換して残りの装置からデータを復元する作業(RAID等の場合)などを表す。

ソフトウェアについて言う場合は、プログラムや設定の不具合で正常に動作しなくなったオペレーティングシステム(OS)などを消去し、再び導入(インストール)し直して初期状態に戻すことなどを指す。この場合、導入済みのソフトウェアや保存された設定情報、データなどは消去されるため、必要であれば利用者が別の装置への保全などを行わなければならない。

例えば、文書データであればタイトルや著者名、作成日などが、楽曲を収めた音声データであれば曲名や収録媒体、作曲家、作詞家、実演家、発表(発売)日時などが考えられる。どのような属性がメタデータとして適切あるいは必要かはデータの種類によって異なり、また、データの作成方法、利用目的などによっても異なる。

文書や画像、音声、動画など多くのファイル形式では、ファイルの先頭などにメタデータを格納する領域が用意されており、あらかじめ決められた形式で、データと一緒にメタデータを保管できるようになっている。ファイル自体もまた、ファイルシステムによって作成者、作成日時、最終更新日時、アクセス権などのメタデータと共に管理されている。

複雑なシステムを大人数で開発したり、長期間に渡って修正・機能追加などを重ねていくと、すでに存在するデータ項目に気づかずに、同じものを微妙に異なる名称で重複して登録してしまったり、違う種類のデータなのに気づかずに同じ名称を与えてしまったりすることがある。

データディクショナリはこうした事態を避けるため、システム全体で扱うデータをすべて定義して列挙し、開発チーム全体で共有する。小規模な場合は文書ファイルなどの形で作成することもあるが、大規模な場合はこれ自体を一つのデータベースにしたり、専用のデータ管理システムを用いたりする。

DBMSのデータディクショナリ

データベース管理システム(DBMS)によっては、あるデータベースの定義や管理に関連するデータを格納するために作られたデータベースをデータディクショナリということがある。

通常のデータベースと同じくテーブル(表)やビューなどで構成され、内部には管理対象のデータベースのテーブルやビュー、インデックス、スキーマ、制約、ユーザーや権限などに関する情報があらかじめ決められた構成で記録される。

システムが取り扱う対象とする現実世界の要素を抽象化し、名詞として表すことができるものを「実体」(エンティティ)として矩形で表す。実体は必ずしも物理的な存在とは限らず、情報や行為などでも構わない。

実体間の関係性を表す要素は「関連」あるいは「関係」(リレーションシップ)と呼ばれ、動詞として表すことができるものが該当する。図中では菱形もしくは矩形の間を結ぶ線分として表記される。

実体と関連は共にその性質を表す「属性」(アトリビュート)を複数持つことができる。属性は楕円で表し実体や関連と線分で紐付ける記法と、実体の矩形の中に列挙する記法がある。

多重度

また、記法によっては関連に多重度(cardinality/カーディナリティ)を設定することができるものがある。二つの実体の関連が一対一、一対多、多対多といった対応関係になっていることを表す。

例えば、ER図の表記法の一つであるIE記法では、関連の末端部分に「○」(0を表す)「|」(1を表す)、鳥の足のような三股の枝分かれ(任意の複数を表す)の3つの記号の組み合わせで数を表記する。「|」のみならば「必ず一つ」、「○」と三股ならば「0を含む任意個」を表す。

記法の種類

ER図は1975年にマサチューセッツ工科大学(MIT)のピーター・チェン(Peter Chen)氏がERモデルと共に考案した。氏の提唱したオリジナルの記法は現在ではPeter Chen記法とも呼ばれる。

用途などに応じて微妙に表記法の異なる10以上の記法が考案され、様々な用途に使用されている。中でも有名なものとして、米国立標準技術研究所(NIST)が規格化したIDEF1x記法(IDEF：ICAM Definition Language)、ジェームズ・マーティン(James Martin)氏が考案したIE記法(IE：Information Engineering)がよく利用される。

ソフトウェア開発では、プログラムを作成する前にシステムの設計や構造、振る舞いを定義し、発注者と開発者、あるいは開発チーム内で仕様について共通認識を得る必要がある。その際、説明が文章や箇条書きだけだと分かりにくく、多数の要素の複雑な相互作用などを簡潔に表現することが難しい。

UMLでは、システムをオブジェクトの組み合わせとしてモデル化し、その構造や仕様を図表によって記述するための表記法を定めている。システムの構成要素の定義や、要素間の関連性、要素の振る舞いなどを図示することができる。

図表の描き方が人や組織によってまちまちでは相互理解に支障を来すが、標準化されたUMLという共通の「言語」を用いることで、書き手の意図を正しく読み手に伝えることができる。システムの様々な側面を伝達できるよう、UMLには14種類の図が用意されている。

UMLの仕様は1996年に当時のラショナル・ソフトウェア(Rational Software)社(2003年に米IBM社が買収)が策定した。その後、仕様の策定・改訂は業界団体のOMG(Object Management Group)が行うようになった。UML1.4が2005年にISO/IEC 19501として、UML 2.4が2012年にISO/IEC 19505としてそれぞれ国際標準となっている。

図の種類

UMLで定義される図は大きく分けて、システムの構造を表す「構造図」(structure diagram)と、動作や変化を表す「振る舞い図」(behavior diagram)の2種類に分類される。

構造図には「クラス図」(class diagram)、「オブジェクト図」(object diagram)、「コンポーネント図」(component diagram)、「パッケージ図」(package diagram)、「配置図」(deployment diagram)、「複合構造図」(composite structure diagram)、「プロファイル図」(profile diagram)がある。

振る舞い図には「アクティビティ図」(activity diagram)、「ユースケース図」(use case diagram)、「ステートマシン図」(state machine diagram)、「相互作用図」(interaction diagram)がある。

相互作用図はさらに、「シーケンス図」(sequence diagram)、「コミュニケーション図」(communication diagram、以前はコンポーネント図と呼ばれていた)、「タイミング図」(timing diagram)、「相互作用概要図」(interaction overview diagram)に分かれる。

例えば、学籍簿のテーブルを考える場合、学籍番号は全員異なり、氏名は同姓同名以外は異なっているため、これらの列は行ごとに値が異なっている度合いが高い。このことを「カーディナリティが高い」という。一方、性別や学年は取りうる値の種類が少なく、同じ値が何度も登場する度合いが高い。これを「カーディナリティが低い」という。

カーディナリティは値の数の絶対値とする場合と、レコード件数に対する比率とする場合がある。後者は値のバリエーションが多くても、レコード件数が極めて多く繰り返し同じ値が登場するならばカーディナリティは低いとする考え方である。

リレーションシップのカーディナリティ

ER図などによるデータモデリングやRDBMSのリレーションシップ機能では、項目の対応関係が一対一、一対多、多対多のいずれであるかを指してカーディナリティという。「多重度」と訳されることもある。

「担任」と「クラス」のように一方の一つの項目には他方の一つの項目のみが紐付く関係が「一対一」、「生徒」と「クラス」のように一方の一つの項目に他方の複数の項目が紐付きうる関係が「一対多」、「生徒」と「習い事」のように互いに相手方の複数の項目が紐付きうる関係が「多対多」となる。

具体的にどんな存在のことをエンティティと呼ぶかは分野や製品によって異なるため一概には言えないが、一つの物事を表すひとまとまりのデータの集合などを意味することが多い。類義語には「インスタンス」(instance)、「オブジェクト」(object)などがある。

ソフトウェア設計などの分野では、システム上でデータとして取り扱うことができるよう抽象的にモデル化された、現実世界の対象物や概念のことをエンティティということがある。例えば、「学生」というエンティティをシステム上で表すために、「氏名」「学年」「学籍番号」という属性と「進級」「退学」「卒業」という操作の集合として定義する、といったモデル化が行われる。

HTMLエンティティ

HTMLやXMLなどのマークアップ言語では、特殊な記法によって画面上に表示された文字のことをエンティティという。「&」(アンパサンド)と「;」(セミコロン)で挟まれた文字列は表示する文字を指定する特殊な記法であるとみなされ、これを置き換えて実際に表示された文字をエンティティという。例えば、HTMLファイル中で「©」と記述すると画面上ではその箇所が「©」に置き換えられて表示されるが、この「©」という文字のことをエンティティという。

様々な分野や場面で用いられる一般的な用語で、それぞれの対象が持つ固有の属性値やその集合体のことを指す。例えば、「ファイルの属性」と言った場合には、ファイル名やファイルの種類、ストレージ上での所在、アクセス権の設定、作成日時、最終更新日時、データサイズ、読み取り属性などが含まれる。

Windowsなどでは、対象の属性の表示や変更を行う設定画面や設定ソフトなどのことを「○○の属性」のように表示するため、文脈によっては「属性を開く」といったようにこの設定画面のことを指して属性という場合もある。

オブジェクト指向プログラミングにおけるプロパティ

オブジェクト指向プログラミングでは、オブジェクトのフィールド(メンバ変数)を外部から直に操作するように記述できるが、実際には内部的にメソッド呼び出しを利用するよう自動的に変換してくれる機能を属性ということがある。

通常、フィールドへ外部からアクセスするには「アクセサメソッド」(setterメソッド/getterメソッド)を定義する必要があるが、属性機能のある言語ではこれを簡易化し、少ないコード量で安全にフィールドへアクセスできるようにしてくれる。

例えば、objオブジェクトのPropフィールドを外部から参照するには、クラス内でgetPropメソッドを定義し、外部から x=obj.getProp() のように記述するのが一般的だが、プロパティとして宣言することにより x=obj.Prop のように記述するだけで内部的にアクセサメソッドを呼び出して値を取り出してくれる。

データベースのリレーションシップ

リレーショナルデータベース管理システム(RDBMS)で、複数のテーブルの間で特定のフィールドを関連付ける機能をリレーションシップという。

これにより、テーブル間で同じ情報が重複するのを避けることができ、あるフィールドの入力を別のテーブルの特定のフィールドの項目から選択するようにしたり、複数のテーブルを連結して情報をまとめたりすることができる。

例えば、受注テーブルの顧客コードに、顧客テーブルの顧客コードを関連付ければ、顧客テーブルに登録されていない顧客コードを受注テーブルに誤って入力してしまうことを防ぐことができる。関連付けられた他のテーブル上のフィールド(この例では顧客コード)を「外部キー」(foreign key)という。

一般的なリレーションシップでは外部キーの各項目が複数のレコードに繰り返し登場することがあり、このような関係を「一対多リレーションシップ」という。外部キーの各項目が一つのレコードにしか現れないよう制約する「一対一リレーションシップ」もあるが、使われる場面は少ない。また、両テーブルのフィールドが互いに相手方へ(一対多の)リレーションシップを張った状態を「多対多リレーションシップ」という場合がある。

文書作成ソフトやWebページなどでは、内部が格子状に分かれた表のことをテーブルという。要素の垂直方向の集合を列(column：カラム)、水平方向の集合を行(row)という。

上端の行や左端の列に項目名などを入れ、他の各項にはそれぞれが属する行や列に該当する内容を書き入れる。一つの項目が複数行や複数列にまたがる場合には、これを連結して大きな項目にできる機能が提供されることもある。

プログラミングの分野でも、表のように複数の異なる要素間の対応関係を管理するためのデータ構造や格納領域をテーブルという。この場合は必ずしも2次元の格子状に整理された構造を指すとは限らない。

データベースのテーブル

リレーショナルデータベース(RDB)ではデータの格納領域をテーブルという。内部は行と列に分かれ、列が要素の種類や形式を表しており、データの挿入や削除、編集は各列の要素を組み合わせた行単位で行う。列は属性(attribute)とも呼ばれ、行は組(tuple)、レコード(record)とも呼ばれる。

レコードを構成する項目の中から一つあるいは複数の組み合わせ(複合主キー)が主キーとして選択・設定される。主キーに選ばれた列はすべてのレコードが異なる値を持たなければならず、NULL値とすることもできない。レコードの中で主キーとして選択可能な項目(や項目の組み合わせ)のことを「候補キー」(candidate key)、候補キーのうち主キー以外のものを「代理キー」(alternate key)ということがある。

あらかじめ異なる値が格納されており、内容が更新・追加されないことが分かっている場合は、人間にとって意味のあるデータそのものを主キーとすることもあるが、レコードが動的に追加・生成されるテーブルでは、識別のためだけに通し番号のような項目を設け、これを主キーに設定することが多い。氏名の同姓同名のように意図せず重複してしまうことを避けるためである。

データベース管理システム(DBMS)などには、主キーのために一意の番号を自動生成するデータ型や機能(オートナンバー型、シリアル型などと呼ばれる)が用意されている場合がある。

ある列に入力するデータに制約を課し、別のテーブルのある列に登録済みのデータしか入力できないようにする。参照先のデータの変更に追随して自動的に参照元も書き換えるよう指定したり、参照先の削除や変更を禁じるよう指定することもできる。

例えば、受注テーブルの顧客コードの列に、顧客テーブルの顧客コードの列を外部キーとして設定すれば、顧客テーブルに登録されていない顧客コードを受注テーブルに誤って入力してしまうことを防ぐことができる。既存顧客の一覧から一つを選択して入力するような形にすることもできるようになる。

SQLでの記述

テーブル作成時には、CONSTRAINT句を用いて「CREATE TABLE テーブル定義 CONSTRAINT 制約名 FOREIGN KEY(列名) REFERENCING 参照先テーブル名(列名) 参照操作」という形式で記述する。列名は参照元、参照先ともに複数指定することができ、その場合は各列の値の組み合わせに対して制約を課す。既存のテーブルにALTER TABLE文で外部キーを追加することもできる。

「参照操作」は参照先のデータの更新や削除をどう扱うかを指定するキーワードである。「CASCADE」なら参照先の更新や削除に参照元を自動的に追随させ、「RESTRICT」なら参照されている値の(参照先での)更新や削除を禁じる。「NO ACTION」もRISTRICT同様に参照先の変更時にエラーを発するが、そのチェックはトランザクションの最後に行われる。

「SET NULL」は参照先が削除されたときに参照元にNull値をセットし、「SET DEFAULT」は列のデフォルト値をセットする。参照操作を更新時に適用するか削除時に適用するかは「ON UPDATE CASCADE ON DELETE RESTRICT」のように「ON UPDATE」および「ON DELETE」で指示することができる。

データベースに記録するデータの中には、特定の値の種類しか取らないものや、何らかの規則や基準に従った内容である必要があるものがある。そのような制約条件を各フィールド(カラム)の仕様として組み込み、データが追加・更新・削除される時点でシステム側でチェックする仕組みが一貫性制約である。

具体的な制約にはいくつかの種類があり、それぞれ固有の構文やキーワードなどで指定を行う。多くのRDBMSが対応している一貫性制約としては、値の未設定(空欄)を許さない「NOT NULL制約」(非NULL制約)や、列の中で他の行のデータと重複しない(一意である)ことを求める「UNIQUE制約」(一意制約)、条件式などで満たすべき条件を直接指定する「CHECK制約」(検査制約)、他のテーブルの特定のカラムに含まれる値しか指定できないようにする「外部キー制約」(参照制約/参照整合性制約)などがある。

オブジェクトのフィールド

例えば、オブジェクト指向プログラミングにおいて、オブジェクトやインスタンスの持つ固有のデータのことをフィールドということがある。言語によっては「プロパティ」(property)あるいは「メンバ変数」(member variable)と呼ぶ場合もある。

テーブルのフィールド

リレーショナルデータベースや表計算ソフトなど、データの集合を表(テーブル)の形で表すシステムでは、行やレコードを構成する個々の要素やデータ項目をフィールドという。複数行の同じフィールドを並べたものを列という。

ユーザーインターフェースのフィールド

ソフトウェアの操作画面上で、入力フォームなどを構成する個々の入力項目や書き込み欄などのことをフィールドという。特に、利用者が任意の内容を入れることができる要素をこのように呼ぶことが多く、例えば文字を入力する欄を「テキストフィールド」(text field)という。

動画やディスプレイのフィールド

インターレース走査(飛び越し走査)の映像や表示機器などで、一回の走査で書き換える画面半分のことをフィールドという。上から奇数番目あるいは偶数番目のラインの集合のことで、2フィールドの走査で画面全体が1フレーム書き換わる。毎秒60フィールドの書き換え速度の場合、毎秒30フレームの書き換えが行われる。

フレームやパケットのフィールド

プロトコル(通信規約)などで定義されたフレームやパケットなどのデータの送受信単位において、ヘッダなど制御用のデータ領域に配置された個々のパラメータのための領域をフィールドという。

データ先頭からの距離(何ビット目/何バイト目)と長さ、内容の形式などで定義され、データの宛先や送信元のアドレスなど、データの送受信に必要な制御用の情報が記録される。

データベースのレコード

リレーショナルデータベース(RDB)において、あるテーブル(表)に格納された、一組の値の連なりのことをレコードあるいは行(row)、組(tuple)などという。

RDBのテーブルは格納すべきデータの名前(属性名、フィールド名)と形式(データ型)を列挙して定義される。テーブル上のデータを操作(挿入や削除、更新など)する際には、定義で列挙された値の組を一件の記録単位として行う。この一組の値の集合をレコードと呼ぶ場合がある。一方、テーブル内の各レコードの特定のフィールドの値を並べたデータ集合は列(カラム/column)、属性(attribute)などという。

データ構造のレコード

いくつかのプログラミング言語では、データベースのレコードのように、固有の識別名やデータ型、形式を持つ複数の変数を一つにまとめたデータ構造のことをレコード型と呼ぶ場合がある。

レコード型の値の内部には、異なる型の変数や別のデータ構造(配列など)などを含めることができ、全体をまとめて一つの変数として関数などの引数や返り値に指定したり、丸ごと複製や代入を行ったりすることができる。

レコードをプログラム上で扱うには、まずレコードの構造の定義を行い、定義したレコードの実体を宣言して値を代入する。この過程は開発者がその言語に新しいデータ型を組み込むようなものであるため、言語によっては「ユーザー定義型」のように呼ぶ場合もある。ちなみにC言語では同じ仕組みを構造体と呼ぶ。

利用者がコンピュータを用いて記憶媒体にデータを保存、読み込み、移動、削除などする際に一つのまとまりとして取り扱うデータの集合を表し、OSの一部であるファイルシステム(file system)によって管理される。

ハードディスクやSSD、USBメモリ、光学ディスク(CD/DVD/Blu-ray Disc)などの記憶装置・記憶媒体を利用する際に用いられるほか、コンピュータと周辺機器の間やコンピュータ間の通信においてもデータの送受信単位として利用される。

ディレクトリとパス

ファイルシステムは記憶媒体内でファイルの作成や削除、上書き、移動、複製などを管理する仕組みで、複数のファイルをまとめて一つの集まりとして扱う「ディレクトリ」(directory)や「フォルダ」(folder)などの入れ物(領域)を作成することもできる。

ディレクトリやフォルダの中に別のディレクトリやフォルダを作成し、入れ子状にすることもでき、記憶媒体全体を階層構造に整理して管理する。装置内でのファイルの位置は、「C:￥Windows￥System32￥cmd.exe」のように最上位から順にディレクトリ名を繋げた「パス」(path)という記法で表される。

ファイル名

ファイルにはそれぞれ固有のファイル名が付けられ、これを用いて識別・指定される。多くのOSではファイル名の末尾にファイルの種類や形式を表す「拡張子」(extension)と呼ばれる数文字の英数字の符号が付与される。

コンピュータの操作画面ではファイルは記憶媒体内での位置(パス)やファイル名で表示され、キーボードなどからパスやファイル名を指定して操作する。グラフィック表示を用いるGUI(Graphical User Interface)を備えたOSでは、ファイルは種類によって異なるアイコン(絵文字)とファイル名によって表示され、マウス操作やタッチ操作でアイコンを指し示して操作を行う。

ファイル属性

ファイルはファイルシステムに記録される際に様々な属性や付加情報(メタデータ)と共に記録される。作成日時や最終更新日時、最終アクセス日時、作成者(所有者)、各利用者やグループのアクセス権限などが記録、設定される。

また、多くのOSではファイルに「読み取り専用」属性を付与でき、解除されるまで削除や上書きができなくなる。「隠しファイル」に設定されたファイルは通常の動作モードではファイル一覧画面などに表示されなくなる(ファイル名を直に指定すれば操作はできる)。

ファイル形式

ファイルに記録されるデータの形式や書式(ファイルフォーマット)は作成したソフトウェアによって様々だが、大きく分類すると「バイナリファイル」(binary file)と「テキストファイル」(text file)に分かれる。

バイナリファイルは特に制約なくあらゆるビットパターンを記録できる自由な形式で、その形式に対応したソフトウェアでなければ何が記録されているか知ることができない。テキストファイルはデータを文字情報として記録したファイルで、文字コード規格で規定されたコードに従ってデータを文字列に置き換えて記録する。対応ソフトがなくてもどのような文字が記録されているかは見ることができる。

変数やフィールドなどが作られてから一度も値が記録されたことがない、「データが存在しない」特殊な状態を表す。多くの言語や処理系では特定のデータ型に属さない特殊な値として扱われ、他の値との比較や演算、結合などの操作はできない一方、「NULLか否か」を判定する特殊な関数などが用意されていることが多い。

言語によっては「nil」「Nothing」「None」などがほぼ同じ機能を表している場合がある。JavaScriptのように値が未定義なのを「undefined」、値が存在しない状態を「null」として区別する言語もある。

一方、ASCIIなどの文字コードでは0番の文字が「ヌル文字」(null character)と定義されており、プログラミングでは長さ0の文字列(何の文字も含まない文字列型データ)を「ヌル文字列」(null string)という。文脈によってはこれらを指してヌルと呼ぶことがある。

データ表現以外では、変数や関数などのメモリアドレスを格納するポインタがどのアドレスも指し示さない特殊な状態であることを「ヌルポインタ」(null pointer)と呼んだり、オペレーティングシステム(OS)に内蔵された仮想的な出力装置で、プログラムからの出力を受け取って消滅させるものを「nullデバイス」(UNIX系OSの/dev/nullやWindowsのNULなど)という。

ちなみに、“null” は英語では「ナル」に近い発音となるが、ドイツ語でゼロを意味する “Null” は「ヌル」に近い。両者ともラテン語で「無い」などを意味する “nullus” から転じた語と言われ、これは「ヌールス」のように発音する。

ヌル文字 (null character/NUL)

ASCIIやUnicodeなどの文字コードでは、文字の識別番号(コードポイント)として0番を与えられた特殊な制御文字を「ヌル文字」(null character)あるいは「空文字からもじ」と呼び、これを略してNULLと呼ぶ場合がある。

もともと周辺機器などへ命令を送る制御文字として「何もしない」という特殊な制御を表していたが、C言語などのプログラミング言語で文字列の終端を表す特殊文字として使用されるようになり、現在ではこの用法が最も有名である。

コード中では「￥0」(C言語など)や「�」(HTMLなど)「^@」などといった特殊表記で表されたり、「NUL」などの略号で示されることもある。制御文字であるため画面や紙面には直接現れることはないが、無理に描画を試みた場合には処理系によって空白が挿入されたり、「NUL」を一文字に縮めた特殊な文字(␀)が記されたりする。

一意性制約を設定した列では、その列の中にデータの重複があってはならず、すでに他の行に存在するのと同じデータを入力しようとするとデータベース管理システム(DBMS)によって拒否されてエラーとなる。ただし、値なし(Null値)の行が複数存在することは可能である。

一意性制約はCREATE TABLE文やALTER TABLE文でCONSTRAINT句とUNIQUEキーワードを用いて設定することができる。列の定義に続けて「CONSTRAINT 制約名 UNIQUE」とすればその列に制約が設定され、テーブル定義の末尾で「CONSTRAINT 制約名 UNIQUE (列名1,列名2,…)」とすれば複数の列にまとめて制約を設定することができる。

主キー制約との違い

似た制約に「主キー制約」(プライマリキー制約、PRIMARY KEY制約)がある。これは、ある列または複数の列の組み合わせに対し、その各行の値が空(Null)ではなく、かつ他の行と重複しない(複数列の場合は同じ値の組み合わせにならない)ことを保証する。テーブルに一つだけ設定することが可能で、各行を一意に識別するための識別子(主キー)を設定するのに使われる。

リレーショナルデータベースの正規化

リレーショナルデータベース(RDBMS)では、データの保守性向上や処理の高速化を図るため、データベース内で同じ情報が複数の箇所に重複して記録されず、個々のテーブルは主キーから直接連想されるデータのみで構成されるよう設計するのが理想とされている。

この基準に基づいてデータ構造を再編する作業や操作のことをデータベースの正規化と呼び、正規化の度合いによって第1正規化から第5正規化、およびボイスコッド正規化などの種類に分類されている。

浮動小数点数の正規化

浮動小数点数を符号部、仮数部、指数部に分けてビット列で表す場合、同じ数を同じ符号化方式で表す場合でも仮数と指数の取り方によって複数の表現が可能となるが、標準となる形式を定めてこれに合わせて表現することを正規化という。

IEEE 754などの標準規格では有効数字の桁数が最大限に確保される表現に正規化するよう定められている。具体的には仮数部のビット列の左端の値が0以外になるように仮数を決め、それに合わせて指数が算出される。

XML文書の正規化

XML文書はテキスト形式を採用しているため、ホワイトスペースの扱いや要素の出現順序などに非常に寛容である。しかし、ソフトウェアにXML文書のデータを渡す場合や、データが改竄されていないことを証明するための署名などを行う場合には、XML文書を一定のルールに従って整形しなおす必要がある。

XMLの正規化は「Canonicalized XML」規格に定められたカノニカライズ(canonicalize)と、「XML Normalization」規格に定められたXML文書のノーマライズ(normalize)、XML規格本体に定められた属性値のノーマライズ(Attribute-Value Normalization)の3種類がある。

カノニカライズは論理的に同等の文書がバイナリデータのレベルで完全に一致するように整形する手順を定めており、XML文書が改竄されていないことを証明するための電子署名を有効に機能させるために必要となる。

XML文書のノーマライズは、ソフトウェアが文書の解釈や変換などを行いやすいように表記法を統一する処理を指す。XMLは名前空間を使用する場合などに意味的に同じ内容を複数の表記で書くことができるが、XML Normalization規格ではこれを一定の基準に基づいて統一された表記にすることを求めている。

属性値のノーマライズは、人間の入力の都合や見やすさなどのために様々な表記が混在する属性値を一定の基準で変換し、ソフトウェアが表記の揺れに影響されないようにする処理である。文字参照表現を参照先の文字自体で置き換えたり、改行文字やタブ文字を空白文字(16進数で20)に置き換えたり、連続する複数の空白を一文字に短縮するといった変換が行われる。

例えば、書籍の情報を表で表そうとすると、著者が複数人の書籍について、著者の項が人数分だけ繰り返し出現したり、著者の項の中で著者名をカンマ区切りで列挙したりすることがある。このような形式は非正規形と呼ばれ、リレーショナルデータベースで扱うには適さないため、このような構造を改め、一つのレコードに同じ項目は一つのみ、一つの項目に記録するのは単一の値(データ)のみ、という制約に基づいて表を構成したものを第1正規化という。

第2正規形 (2NF/第2正規化)

ある表(リレーション)が第1正規形であり、かつ、レコード中の非キー項目のうち、主キーのいずれかが定まれば一意に定まるようなものを排除して独立した表として分離したものを第2正規形(second normal form)という。そのような形式に変換することを第2正規化という。

例えば、顧客からの注文を記録する表が「受注日、顧客名、製品コード、製品名、単価、数量」で構成され、受注日、顧客名、製品コードが主キーであるとき、製品名と単価は製品コードが定まれば一意に定まる。このような場合に、注文表から製品名と単価の項目を取り除き、「製品コード、製品名、単価」からなる新たな表として分離したものが第2正規形となる。

第3正規形 (3NF/第3正規化)

ある表(リレーション)が第2正規形であり、かつ、レコード中の非キー項目のうち、他の非キー項目のいずれかが定まれば一意に定まるようなものを排除して独立した表として分離したものを第3正規形(third normal form)という。そのような形式に変換することを第3正規化という。

例えば、製品の仕入れ先を記録する表が「製品コード、製品名、仕入先コード、仕入先名、所在地、電話番号」で構成され、製品コードが主キーであるとき、仕入先名や所在地、電話番号は仕入先コードが定まれば一意に定まる。このような場合に、表から仕入先名、所在地、電話番号の項目を取り除き、「仕入先コード、仕入先名、所在地、電話番号」からなる新たな表として分離したものが第3正規形となる。

例えば、書籍の情報を表で表そうとすると、著者が複数人の書籍について、著者の項が人数分だけ繰り返し出現したり、著者の項の中で著者名をカンマ区切りで列挙したりすることがある。このような形式は非正規形と呼ばれ、リレーショナルデータベースで扱うには適さないため、このような構造を改め、一つのレコードに同じ項目は一つのみ、一つの項目に記録するのは単一の値(データ)のみ、という制約に基づいて表を構成したものを第2正規化という。

第2正規形 (2NF/第2正規化)

ある表(リレーション)が第1正規形であり、かつ、レコード中の非キー項目のうち、主キーのいずれかが定まれば一意に定まるようなものを排除して独立した表として分離したものを第2正規形(second normal form)という。そのような形式に変換することを第2正規化という。

例えば、顧客からの注文を記録する表が「受注日、顧客名、製品コード、製品名、単価、数量」で構成され、受注日、顧客名、製品コードが主キーであるとき、製品名と単価は製品コードが定まれば一意に定まる。このような場合に、注文表から製品名と単価の項目を取り除き、「製品コード、製品名、単価」からなる新たな表として分離したものが第2正規形となる。

第3正規形 (3NF/第3正規化)

ある表(リレーション)が第2正規形であり、かつ、レコード中の非キー項目のうち、他の非キー項目のいずれかが定まれば一意に定まるようなものを排除して独立した表として分離したものを第3正規形(third normal form)という。そのような形式に変換することを第3正規化という。

例えば、製品の仕入れ先を記録する表が「製品コード、製品名、仕入先コード、仕入先名、所在地、電話番号」で構成され、製品コードが主キーであるとき、仕入先名や所在地、電話番号は仕入先コードが定まれば一意に定まる。このような場合に、表から仕入先名、所在地、電話番号の項目を取り除き、「仕入先コード、仕入先名、所在地、電話番号」からなる新たな表として分離したものが第3正規形となる。

例えば、書籍の情報を表で表そうとすると、著者が複数人の書籍について、著者の項が人数分だけ繰り返し出現したり、著者の項の中で著者名をカンマ区切りで列挙したりすることがある。このような形式は非正規形と呼ばれ、リレーショナルデータベースで扱うには適さないため、このような構造を改め、一つのレコードに同じ項目は一つのみ、一つの項目に記録するのは単一の値(データ)のみ、という制約に基づいて表を構成したものを第3正規化という。

第2正規形 (2NF/第2正規化)

ある表(リレーション)が第1正規形であり、かつ、レコード中の非キー項目のうち、主キーのいずれかが定まれば一意に定まるようなものを排除して独立した表として分離したものを第2正規形(second normal form)という。そのような形式に変換することを第2正規化という。

例えば、顧客からの注文を記録する表が「受注日、顧客名、製品コード、製品名、単価、数量」で構成され、受注日、顧客名、製品コードが主キーであるとき、製品名と単価は製品コードが定まれば一意に定まる。このような場合に、注文表から製品名と単価の項目を取り除き、「製品コード、製品名、単価」からなる新たな表として分離したものが第2正規形となる。

第3正規形 (3NF/第3正規化)

ある表(リレーション)が第2正規形であり、かつ、レコード中の非キー項目のうち、他の非キー項目のいずれかが定まれば一意に定まるようなものを排除して独立した表として分離したものを第3正規形(third normal form)という。そのような形式に変換することを第3正規化という。

例えば、製品の仕入れ先を記録する表が「製品コード、製品名、仕入先コード、仕入先名、所在地、電話番号」で構成され、製品コードが主キーであるとき、仕入先名や所在地、電話番号は仕入先コードが定まれば一意に定まる。このような場合に、表から仕入先名、所在地、電話番号の項目を取り除き、「仕入先コード、仕入先名、所在地、電話番号」からなる新たな表として分離したものが第3正規形となる。

表の中で、ある属性の値を決定すると別の属性の値も一意に決まる性質を「関数従属性」という。属性Xを決めると属性Yが定まるとき、「X→Y」のように表記し、Xを「決定項」、Yを「従属項」あるいは「被決定項」という。

複数の候補キーの組み合わせて復号主キーを構成しているような表で、ある属性が候補キーの組み合わせにのみ従属している(候補キーすべての値が決まらないと値が定まらない)状態を、完全関数従属であるという。一方、候補キーのいずれか一つに対しても従属している状態は「部分関数従属」という。

例えば、「注文番号, 商品ID, 商品名, 数量」のように候補キー2つ(注文番号・商品ID)で複合主キーを構成するような表で、「数量」は注文番号と商品IDの両方が決まらないと分からないため完全関数従属である。一方、「商品名」は候補キー2つの組み合わせにも従属しているが、商品IDのみから一意に求めることができるため部分関数従属となる。

表の中で、ある属性の値を決定すると別の属性の値も一意に決まる性質を「関数従属性」という。属性Xを決めると属性Yが定まるとき、「X→Y」のように表記し、Xを「決定項」、Yを「従属項」あるいは「被決定項」という。

複数の候補キーの組み合わせて複合主キーを構成しているような表で、ある属性が候補キーのいずれか一つに対して従属している状態を、部分関数従属であるという。一方、候補キーの組み合わせにのみ従属している(候補キーすべての値が決まらないと値が定まらない)状態は「完全関数従属」という。

例えば、「注文番号, 商品ID, 商品名, 数量」のように候補キー2つ(注文番号・商品ID)で複合主キーを構成するような表で、「商品名」は候補キー2つの組み合わせにも従属しているが、商品IDのみから一意に求めることができる。このような場合を部分関数従属という。一方、「数量」は注文番号と商品IDの両方が決まらないと分からないため、完全関数従属となる。

表の中で、ある属性の値を決定すると別の属性の値も一意に決まる性質を「関数従属性」という。属性Xを決めると属性Yが定まるとき、「X→Y」のように表記し、Xを「決定項」、Yを「従属項」あるいは「被決定項」という。

属性X、Y、Zがあり、Xが決まるとYも決まり、Yが決まるとZも決まるという関係、すなわち、X→Y、Y→Zが推移的に成り立つ(かつ、厳密にはY→Xが成り立たない)とき、ZはXに推移関数従属しているという。

例えば、「社員ID, 氏名, 住所, 郵便番号」という表で、「社員ID→住所」が成り立つが、「住所」が決まれば「郵便番号」も一意に定まるため「住所→郵便番号」も成り立っている。このとき、「社員ID→郵便番号」という従属性も成立し、「郵便番号」は「社員ID」に推移関数従属しているという。

集合Aと集合Bの要素をすべて合わせた集合を「和集合」(union)という。数学では「A∪B」のように表記する。例えば、{1,2}∪{2,3}は{1,2,3}となる。二つの集合から和集合を得る操作を「和集合演算」と呼ぶことがある。

集合Aと集合Bのどちらにも含まれる要素の集合を「積集合」(intersection)という。数学では「A∩B」のように表記する。例えば、{1,2}∩{2,3}は{2}となる。二つの集合から積集合を得る操作を「積集合演算」と呼ぶことがある。

集合Aには含まれるが集合Bには含まれない要素の集合を「差集合」(difference)という。数学では「A＼B」あるいは「A-B」のように表記する。{1,2,3}-{1,2}は{3}となる。二つの集合から差集合を得る操作を「差集合演算」と呼ぶことがある。

全体集合が定義されるとき、全要素のうち集合Aに含まれない要素の集合を「補集合」(complement)という。数学では「Ā」のように表記する。全体集合が{1,2,3,4}で、Aが{1,3}のとき、Aの補集合は{2,4}となる。

数学の集合論で用いられる概念で、集合Aと集合Bの少なくとも一方に含まれる元全体から成る集合を「AとBの和集合」と呼び、「A∪B」と書き表す。演算としては整数などの加算と同じように、交換法則、結合法則、分配法則が成り立つ。

AとBに共通の元がない場合は「直和」(direct sum)あるいは「非交和」(disjoint union)とも呼ばれる。例えば、Aが奇数の集合、Bが偶数の集合の場合、両者の間に交わりは無く、自然数の集合であるA∪Bは直和となる。

数学の集合論で用いられる概念で、集合Aから集合Bに属する元を取り去った集合を「AからBを引いた差集合」と呼び、「A-B」あるいは「A＼B」と書き表す。例えば、自然数の集合Aから奇数の集合Bを引いたA-Bは偶数の集合となる。

全体集合Uから集合Aの要素を引いた差集合のことを集合Aの「補集合」(あるいは余集合)と呼び、「A」あるいは「A^c」のように表記する。

数学の集合論で用いられる概念で、集合Aに含まれる元 { a₁, a₂, a₃, … } と集合Bに含まれる元 { b₁, b₂, b₃, … } を一つずつ使って (a₁,b₁) といった値の組を作り、そのすべての組み合わせを元とする集合である。

この値の組は値の登場順も区別する順序対と呼ばれるもので、(1,2)と(2,1)は異なる組であるとみなされる。このため、一般にA×BとB×Aは必ずしも一致するとは限らず、演算として「項の前後を入れ替えても同じ結果」になるという交換法則は成り立たない。

積集合の例としてよく知られるのはトランプの図柄で、4つの絵柄(スート) { ♠, ♥, ♦, ♣ } の集合と、13のランク(数字・文字) { A, 2, 3, 4, 5, 6, 7, 8, 9, 10, J, Q, K } の集合のすべての元の組み合わせで52枚(4×13)の絵柄が構成されている。

積集合は「直積」「積」「デカルト積」「積集合」などとも呼ばれるが、「積集合」は複数の集合のすべてに所属する元から成る集合(論理演算の論理積に相当)を指すこともある。積集合との混同を避けるため、こちらは「共通集合」「共通部分」等と呼ばれることもある。

数学の集合論で用いられる概念で、集合Aに含まれる元 { a₁, a₂, a₃, … } と集合Bに含まれる元 { b₁, b₂, b₃, … } を一つずつ使って (a₁,b₁) といった値の組を作り、そのすべての組み合わせを元とする集合である。

この値の組は値の登場順も区別する順序対と呼ばれるもので、(1,2)と(2,1)は異なる組であるとみなされる。このため、一般にA×BとB×Aは必ずしも一致するとは限らず、演算として「項の前後を入れ替えても同じ結果」になるという交換法則は成り立たない。

直積集合の例としてよく知られるのはトランプの図柄で、4つの絵柄(スート) { ♠, ♥, ♦, ♣ } の集合と、13のランク(数字・文字) { A, 2, 3, 4, 5, 6, 7, 8, 9, 10, J, Q, K } の集合のすべての元の組み合わせで52枚(4×13)の絵柄が構成されている。

直積集合は「直積」「積」「デカルト積」「積集合」などとも呼ばれるが、「積集合」は複数の集合のすべてに所属する元から成る集合(論理演算の論理積に相当)を指すこともある。直積集合との混同を避けるため、こちらは「共通集合」「共通部分」等と呼ばれることもある。

「射影」(projection)は、関係(表)から特定の属性(列)を抽出する操作を表す。「選択」(selection)は、関係(表)から特定の条件を満たす組(行)の集合を抽出する操作を表し、「制限」(restriction)と呼ばれることもある。

「結合」(join)は、複数の関係(表)を特定の属性(列)に関連付けて結びつけ、一つの関係(表)を生成する操作を表す。「商」(division)は数の割り算に似た操作で、割られる側の関係(表)の中から割る側の値の組み合わせを含む組(行)を抽出し、重複する組(行)と割る側に含まれる属性を取り除いたものを求める。

関係演算は関係代数と呼ばれるコンピュータ科学の分野で理論化されており、データを関係モデルという構造で表し、様々な操作を行うことができる。関係モデルは関係データベース(リレーショナルデータベース)として実用化されており、データベースに対する操作や問い合わせを行うためのSQL(Structured Query Language)にも関係演算が取り入れられている。

「射影」(projection)は、関係(表)から特定の属性(列)を抽出する操作を表す。「選択」(selection)は、関係(表)から特定の条件を満たす組(行)の集合を抽出する操作を表し、「制限」(restriction)と呼ばれることもある。

「結合」(join)は、複数の関係(表)を特定の属性(列)に関連付けて結びつけ、一つの関係(表)を生成する操作を表す。「商」(division)は数の割り算に似た操作で、割られる側の関係(表)の中から割る側の値の組み合わせを含む組(行)を抽出し、重複する組(行)と割る側に含まれる属性を取り除いたものを求める。

選択は関係代数と呼ばれるコンピュータ科学の分野で理論化されており、データを関係モデルという構造で表し、様々な操作を行うことができる。関係モデルは関係データベース(リレーショナルデータベース)として実用化されており、データベースに対する操作や問い合わせを行うためのSQL(Structured Query Language)にも選択が取り入れられている。

ITの分野では、関係演算やリレーショナルデータベースの操作において、ある関係(表)から指定した条件に従って特定のいくつかの属性(列)を抜き出す操作や、そのような操作の結果得られる関係(表)のことを射影ということが多い。

例えば、表「名簿」が「識別番号」「氏名」「住所」「電話番号」の4属性で構成されるとして、そこから「識別番号」と「氏名」のみで構成される表を抜き出す操作(および得られた表)を射影という。SQL文では「SELECT 識別番号,氏名 FROM 名簿」のように表現される。

「射影」(projection)は、関係(表)から特定の属性(列)を抽出する操作を表す。「選択」(selection)は、関係(表)から特定の条件を満たす組(行)の集合を抽出する操作を表し、「制限」(restriction)と呼ばれることもある。

「結合」(join)は、複数の関係(表)を特定の属性(列)に関連付けて結びつけ、一つの関係(表)を生成する操作を表す。「商」(division)は数の割り算に似た操作で、割られる側の関係(表)の中から割る側の値の組み合わせを含む組(行)を抽出し、重複する組(行)と割る側に含まれる属性を取り除いたものを求める。

結合は関係代数と呼ばれるコンピュータ科学の分野で理論化されており、データを関係モデルという構造で表し、様々な操作を行うことができる。関係モデルは関係データベース(リレーショナルデータベース)として実用化されており、データベースに対する操作や問い合わせを行うためのSQL(Structured Query Language)にも結合が取り入れられている。

「射影」(projection)は、関係(表)から特定の属性(列)を抽出する操作を表す。「選択」(selection)は、関係(表)から特定の条件を満たす組(行)の集合を抽出する操作を表し、「制限」(restriction)と呼ばれることもある。

「結合」(join)は、複数の関係(表)を特定の属性(列)に関連付けて結びつけ、一つの関係(表)を生成する操作を表す。「商」(division)は数の割り算に似た操作で、割られる側の関係(表)の中から割る側の値の組み合わせを含む組(行)を抽出し、重複する組(行)と割る側に含まれる属性を取り除いたものを求める。

商は関係代数と呼ばれるコンピュータ科学の分野で理論化されており、データを関係モデルという構造で表し、様々な操作を行うことができる。関係モデルは関係データベース(リレーショナルデータベース)として実用化されており、データベースに対する操作や問い合わせを行うためのSQL(Structured Query Language)にも商が取り入れられている。

データベースの構造や構成を定義するために用いられるものが多く、単にDDLといった場合には、リレーショナルデータベース(RDB)の制御に用いられる問い合わせ言語の標準、SQL(Structured Query Language)の一部の命令群を指すことが多い。

SQLにおけるDDLには、データベースやテーブル、ビューなどの作成を行うCREATE文や、これらを削除するDROP文、これらの設定や構成に変更を加えるALTER文、テーブル中のデータを全削除するTRUNCATE文が含まれる。

これに対し、定義されたデータ構造中の個々のデータを操作する言語を「DML」(Data Manipulation Language：データ操作言語)、データへのアクセス権限などを制御する言語を「DCL」(Data Control Language：データ制御言語)という。DMLにはSELECT文やINSERT文などが、DCLにはGRANT文やREVOKE文などが含まれる。

データベースへのデータの新規登録や、既存のデータの上書きや削除、条件に合致するデータの検索や抽出などを行うために用いられる。リレーショナルデータベースを管理するための標準的な言語であるSQLでは、SELECT文(検索・抽出)やINSERT文(データの追加)、UPDATE文(データの更新)、DELETE文(データの削除)などがこれに当たる。

これに対し、データを格納するための構造を定義する言語をDDL(Data Definition Language：データ定義言語)、データへのアクセス権限などを制御する言語をDCL(Data Control Language：データ制御言語)という。

DBMSへ利用者や外部のソフトウェアから命令を発行するために用いる言語で、データベースへのテーブルの追加や設定変更、削除、テーブル間の関係の定義や削除、テーブルへのデータの追加、更新、削除、データベースやシステムの設定変更などを行うための命令語と構文、文法などを定めている。

主なSQL文

データを操作する命令文としては、テーブルや制約条件などの定義を行うCREATE文、削除を行うDROP文、設定変更を行うALTER文、テーブルにレコードを挿入するINSERT INTO文、削除するDELETE文、更新(上書き)するUPDATE文、条件を元に抽出するSELECT文などがある。

データベースを管理する命令文としては、利用者に権限を付与するGRANT文、剥奪するREVOKE文、トランザクション処理を開始するBEGIN文、完了するCOMMIT文、取り消すROLLBACK文などがある。一部の命令文では文の一部に別の文(サブクエリ/副問い合わせ)を含めることができ、複雑な処理を記述することができる。

これらの命令のうち、CREATE文などデータ構造や関係の定義に関するものを「データ定義言語」(DDL：Data Definition Language)、SELECT文などデータの操作に関するものを「データ操作言語」(DML：Data Manipulation Language)、GRANT文などシステムの管理や制御に関するものを「データ制御言語」(DCL：Data Control Language)にそれぞれ分類することもある。

SQL文の実行

DBMSの管理ツールなどとして対話的にSQL文を実行する環境が用意されていることが多く、管理者や利用者が当座の目的のためにその場でSQL文を入力して実行させることができる。

また、関連する複数の命令文からなる一連の処理を一つの手続きとしてあらかじめデータベースに保存しておき、一定間隔や利用者からの指示などにより実行する「ストアドプロシージャ」(stored procedure)と呼ばれる仕組みが提供される。このうち、何らかの操作やイベントを契機に自動的に起動するよう設定されたものは「トリガー」(データベーストリガー)と呼ばれる。

SQL自体はプログラミング言語ではなく、複雑な処理は実行できないため、外部のコンピュータプログラムからDBMSに命令を発行する仕組みも用意されている。Oracle Databaseの「PL/SQL」のようにDBMS自身がプログラム実行環境となる独自の言語を用いる場合が多い。

プログラミング言語で記述されたソースコード中に命令文を記述し、その言語による記述に自動変換して実行する「埋め込みSQL」(Embedded SQL)や、様々な言語から共通して利用できるプログラミングインターフェース(API)を定義した「ODBC」(Open Database Connectivity)などの仕組みもある。JDBCのようにプログラミング言語側でSQL文発行のための仕組みを整えている場合もある。

歴史

SQLの元になったのは1970年代に米IBM社がRDBMS「System R」を開発する際に、その制御・操作用言語として考案した「SEQUEL」(Structured English Query Language/「シークェル」と読む)である。1980年代以降、他社のRDBMSもSQLを採用するようになり、事実上の標準として普及した。

当初はメーカーやシステムにより仕様が大きく異なっていたため標準化を求める声が強まり、1986年にANSI(米国国家規格協会)によって標準規格「SQL86」が制定された。ISO(国際標準化機構)とIEC(国際電気標準会議)の情報分野の合同委員会JTC 1はこの規格を1987年にISO/IEC 9075として国際標準化している。

ちなみに、ANSI規格のSQLという名称は公式には何の略でもないとされる。その後、同規格はSQL92、SQL99などと改訂され、近年もSQL:2008やSQL:2011、SQL:2016などの新しい改訂版が発行されている。

入力フォーム

(紙の)記入用紙や申請書のように、内容を書き込んだり選択肢から一つを選ぶ操作要素が並んだ画面や領域を入力フォーム(input form)と呼び、単にフォームと言った場合はこれを指すことが多い。

ソフトウェアの機能として用意される場合、ソフトウェアの設定画面や、新規の書類やファイルの作成、既存のデータの編集など、利用者が一つの目的のためにまとまった数の項目を入力・指定する必要がある場合に用いられる。

Webページの場合は閲覧者から必要な情報を聞き出してWebサーバに送信するために用いられ、会員登録や問い合わせ、アンケート、購入や決済、サービスについての各種の手続きなどでよく利用される。検索機能や検索エンジンのキーワード入力欄なども簡易なフォームの一種である。

フォームは入力内容や目的により様々な機能の要素が用いられる。例えば、任意の文字列を入力できる「テキストボックス」(Webページでは複数行のものを「テキストエリア」という)、複数の選択肢から一つを選ぶ「ラジオボックス」や「セレクトボックス」、複数の選択肢から複数を選ぶことができる「チェックボックス」、文字入力と選択肢を組み合わせることができる「コンボボックス」、はい・いいえやオン・オフなどを指定する「トグルスイッチ」、内容の送信やリセットなどを指示するための「ボタン」などがよく用いられる。

泡を意味するフォーム

美容・衛生・建築などの分野で泡のことをフォームということがあるが、これは英語の “foam” を音写したもので、日本語の外来語としては同音異義語だが、英語では発音も綴りも異なり特に共通点はない。

一般的には、情報の検索や抽出を行うために、含まれるキーワードやフレーズ、探索対象や範囲、対象期間などを組み合わせて検索条件を書き記した文字列を指す。広義には、システムに対する操作や要求など、何らかのメッセージを一定の書式で記したデータ全般が含まれる。

複数の条件を組み合わせる場合には、システムの書式に定められた論理演算子などを用いて条件の結合の仕方を指示する。例えば、「A and B」は「条件AとBの両方を満たす」、「A or B」は「AとBの少なくともどちらかを満たす」、「A and not B」は「Aを満たしBを満たさない」といった意味になる。

検索クエリ

Web検索エンジンでは、利用者が入力した検索文字列のことをクエリと呼ぶ。検索したい内容を表す語句やフレーズの組み合わせで、検索エンジンは関連度が高いと思われるWebページを探し出してリストにして表示する。

複数の語句を並べると原則としてそれらがすべて含まれるページを探す(AND検索)が、演算子を用いて複雑な条件を指定することもできる。例えば、「|」(縦棒)は「いずれかが含まれる」(OR検索)を、「-」(ハイフン)は「～を含まない」(NOT検索)を意味する。

数式のように括弧で条件の組み合わせ方の優先度を指定したり、ページの最終更新日時の範囲を指定したり、ページが記述されている言語(日本語、英語などの自然言語)を指定したり、「site:」演算子で特定のWebサイトのみを検索対象にする(サイト内検索)こともできる。

SQLクエリ

データベース管理システム(DBMS)では、利用者や外部システムからデータベースに対する処理要求(問い合わせ)を文字列として表したものをクエリという。データの検索や抽出だけでなく、追加や更新、削除などの要求を発行するのにも使われる。

例えば、検索クエリであれば検索対象のテーブルやデータの抽出条件、並べ方などを指定する。DBMSはクエリを解釈・実行し、結果をレコードセットなどの形で応答する。一度作成したクエリは保存しておいて何度も使うことができるようになっているものが多い。

データベースとして最も広く普及しているリレーショナルデータベース(RDB/RDBMS)ではクエリを記述する言語の標準として「SQL」(Structured Query Language)が定められており、単にクエリと言えば通常はSQLクエリを指す。

SQLではデータの問い合わせおよび抽出を行うのはSELECT文だが、データを追加するINSERT文や更新を行うUPDATE文、削除を行うDELETE文、テーブルの作成を行うCREATE文など、DBMSに対して処理や操作を要求する命令文はすべてクエリと呼ばれる。

データベーススキーマ

データベースにどのような種類のデータをどのような構造で格納するか定義したものをスキーマという。抽象度に応じて段階的に複数の異なるスキーマを用いることが多く、よく用いられるのはデータの表現と格納について「概念スキーマ」「論理スキーマ」「物理スキーマ」の三段階で定義する「3層スキーマ」である。

「概念スキーマ」はデータベースが取り扱う対象がどのような概念で構成され、それぞれの概念がどのような属性の集合として表されるかをモデル化して定義する。この段階ではデータベースへの格納方法などは考慮せず、対象をどんな形で表現するのかを明確にする。

「論理スキーマ」は概念スキーマで定義したモデルを、具体的な特定のデータベーシステムで取り扱えるデータ形式の集合として記述していく。リレーショナルデータベースであれば、各概念をどんなテーブル(表/関係)に、どんなフィールド(属性)の集合として格納し、それぞれのフィールド間、テーブル間の関係はどうなっているか、といったことを定義していく。単にスキーマといった場合、この定義のを指すことがある。

「物理スキーマ」は論理スキーマで定義したデータモデルを、具体的なコンピュータシステムでどのように格納・管理するかを定義したもので、データベース管理システム(DBMS)がコンピュータのストレージ(外部記憶装置)上にデータを記録する方法を指示したものを表す。

3層で構成されるデータベーススキーマには他に、「外部スキーマ」「概念スキーマ」「内部スキーマ」の三段階を用いる「ANSI/SPARC3層スキーマ」もよく知られている。概念-論理-物理の場合とそれぞれの役割は似ているものの、詳細は微妙に異なっている。

スキーマ言語

SGMLやXMLなどの汎用的なマークアップ言語で、使用するタグ(要素)の定義や属性の書式などを記述し、ある特定の用途やデータ構造のための具体的なマークアップ言語の仕様を定義するための言語を「スキーマ言語」という。言語を定義する言語である「メタ言語」の一種である。

例えば、Webページをマークアップ言語で記述するには「画像の埋め込みを指示するタグ」「段落の開始と終了を指示するタグ」などが必要になるが、汎用マークアップ言語にはこのような特定の用途における特定の目的のための具体的なタグなどは用意されていない。

そこで、Webページを記述するのに必要なタグの名称(例：imgタグ)や、指定できる属性の種類(width属性)、属性値の内容(自然数かパーセンテージ)などを体系的に定義し、汎用マークアップ言語の記法に則した具体的なマークアップ言語として用いる。

その際に、言語仕様の定義を記述するための言語のことをスキーマ言語という。実際、初期のHTMLはSGMLの仕様に則って定義され、スキーマ言語の「DTD」(Document Type Definition)によって仕様が記述されていた(現在はSGMLから切り離され単体の言語として定義されている)。

文書作成ソフトやWebページなどでは、内部が格子状に分かれた表のことをテーブルという。要素の垂直方向の集合を列(column：カラム)、水平方向の集合を行(row)という。

上端の行や左端の列に項目名などを入れ、他の各項にはそれぞれが属する行や列に該当する内容を書き入れる。一つの項目が複数行や複数列にまたがる場合には、これを連結して大きな項目にできる機能が提供されることもある。

プログラミングの分野でも、表のように複数の異なる要素間の対応関係を管理するためのデータ構造や格納領域をテーブルという。この場合は必ずしも2次元の格子状に整理された構造を指すとは限らない。

データベースのテーブル

リレーショナルデータベース(RDB)ではデータの格納領域をテーブルという。内部は行と列に分かれ、列が要素の種類や形式を表しており、データの挿入や削除、編集は各列の要素を組み合わせた行単位で行う。列は属性(attribute)とも呼ばれ、行は組(tuple)、レコード(record)とも呼ばれる。

CGのビュー

コンピュータグラフィックスやビデオゲームの分野で、空間をどのような視点から眺めて画面に表示するかをビューという。真上から見下ろした「トップビュー」(top-down view)、斜め上から見下ろした「クォータービュー」(isometric view)、真横から眺める「サイドビュー」(side view)などがよく知られる。

データベースのビュー表

データベース管理システム(DBMS)で、一つまたは複数のテーブルから特定の条件に基づいて一部のデータを抜き出し、あたかも一つの新しいテーブルのように表したものをビューという。

データベース以外のデータ解析システムなどでも、データ群を指定された条件によって整理して表示し、その設定に名前をつけて保存することにより繰り返し呼び出せるようにしたものをビューということがある。

ソフトウェア開発におけるビュー

ソフトウェア開発において、システム全体を機能によって分割する際に、利用者への表示や操作の受け付け(ユーザーインターフェース)を担当する部分のことをビューということがある。

よく知られる設計モデルのMVC(Model-View-Controller)では、モデル(Model)、ビュー(View)、コントローラ(Controller)の三つに分割して整理する。ビューは他の二要素からの指示を受けて利用者への表示・出力(の変更)を行い、システムによっては利用者の操作・入力内容をコントローラに伝達する役割を果たす。

あるデータがどのような性質のもので、どのように取り扱うべきかを定めたもので、典型的なものには整数型や文字列型などがある。それぞれの変数や値のデータ型に応じて、それを適切に扱うためのプログラムコードが生成・適用される。

例えば、整数型の値について「1+1」という処理を実行すると、数値計算のコードが適用されて「2」という結果が得られるが、文字列型の値について「"1"+"1"」という処理を実施すると、文字列の連結処理が適用されて「"11"」という結果が得られる。

整数を文字列で除算しようとするなど、型が不整合な処理はエラーとなる。"1"という文字列型の値を1という整数型の値に変換するなど、異なる型へ一定のルールに基づいて変換することを「型変換」あるいは「型キャスト」(type casting)という。

プリミティブ型と複合型

様々なデータ型のうち、それ以上要素に分解できない最小単位のデータを格納する最も基本的なデータ型を「単純データ型」「プリミティブデータ型」などという。

言語によって用意されている単純型の種類は異なるが、文字型や文字列型、整数型、浮動小数点数型(あるいは固定小数点数型や実数型)、論理型(ブーリアン型)、日付・時刻型、バイナリ型などが用意されていることが多い。

ポインタ型や参照型などメモリ上の位置を格納する型や、関数型などプログラムをデータのように扱う型、データが「無い」ことを明示するvoid型など、特殊な型が用意されている言語もある。

浮動小数点数型に単精度や倍精度など異なる精度の型が用意されていたり、整数型がバイト長や符号の有無(負数を表現できるか否か)でいくつかの種類に分かれているなど、データの種類が同じでも仕様が異なる複数の型に分かれている場合もある。

一方、複数のデータ型を組み合わて定義された型や、複数の要素からなるデータ構造を格納するためのデータ型を「複合データ型」(complex type)という。配列や連想配列(ハッシュ、マップ、辞書)、リスト、タプル、集合型(セット)、列挙型などがこれに当たる。

組み込み型とユーザー定義型

言語仕様や標準ライブラリなどにあらかじめ用意されているデータ型を「組み込みデータ型」(ビルトインデータ型)、開発者が独自に定義したものを「ユーザー定義データ型」(user-defined type)という。

組み込み型は言語処理系が標準的に扱うことができ、演算子による演算を行ったり、基本的な操作や処理を行うための関数やメソッドが標準で提供されることが多い。

ユーザー定義型は単に既存の組み込みデータ型に別名を与えられるだけの場合もあるが、様々なデータ型を組み合わせた複合データ型を独自に定義できる機能を指すことが多い。演算子の処理内容を独自に定義(上書き)して、ユーザー定義型の値に対しても演算子を適用できる言語もある。

型宣言と型付け

プログラムの開発者がそれぞれの変数などのデータ型をプログラム上に明示することを「型宣言」(type statement)という。コード中で使用する変数などについて必ず事前に型宣言しなければならない言語と、型宣言しなくても変数などを使ってよい言語がある。

プログラムの実行前、ソースコードの記述やコンパイルの時点で型が決定されることを「静的型付け」(static typing)、実行時に実際の値に基づいて型が決定されることを「動的型付け」(dynamic typing)という。

型宣言が不要な言語の多くは動的型付けを採用しているが、「型推論」(type inference)機能により内部的に静的型付けを自動的に行う仕組みの言語もある。

C言語で「char型」として知られる型で、古い言語仕様や処理系ではASCII文字コードを格納するための1バイト固定長となっている場合もあるが、現代ではUnicodeなどで多バイト文字を表現することを考慮して、2バイトや4バイト、あるいは1～4バイトの不定長として設計されていることもある。

C/C++言語のように実態が整数型で数値としての処理・演算もできる場合と、文字としてしか扱えない場合がある。文字型が用意されている言語では文字列は文字型の配列などとして表され、データ型としての文字列型は用意されていないことが多い(逆に、文字列型がある言語に文字型はない)。

一方、データベース管理システム(DBMS)の場合には、「CHAR型」という名称が固定長の文字列型を表すことが多い。SQL文などで「CHAR(10)」のように表記され、この例では10文字の固定長文字列を表す。

西暦、月、日の組み合わせで表される日付データ、あるいはこれに時刻を組み合わせたデータを格納することができる。数の大小と同じように比較演算子などを用いて前後を判定したり、範囲を指定することができる。書式を指定して文字列に出力したり、文字列を解釈して値を設定する機能が提供されることが多い。

日付の表現形式はシステムによるが、4桁の西暦(YYYY)、2桁の月(MM)、2桁の日(DD)を組み合わせて「YYYY-MM-DD」のように表すことが多い。国によって順序や月の表し方などが異なるため、「MM/DD/YYYY」など複数の形式を受け付ける設計となっていることも多い。

時刻まで格納可能な場合は24時制で「HH:MM:SS」のように指定するが、システムによっては更に細かくミリ秒やマイクロ秒のような単位で記録できる場合もある。内部的には歴史上のある特定日時からの経過秒数や経過ミリ秒数として表現することが多く、起点より前の日付や時刻は表せないことがある。

日付や時刻を扱うデータ型やクラスの名称は様々で、「Date型」(DATE型)、「Time型」(TIME型)、「TIMESTAMP型」「DateTime型」(DATETIME型)などのバリエーションがある。日付・時刻の片方のみを格納するか、両方を扱うことができるかも言語や処理系によって異なる。

一意性制約を設定した列では、その列の中にデータの重複があってはならず、すでに他の行に存在するのと同じデータを入力しようとするとデータベース管理システム(DBMS)によって拒否されてエラーとなる。ただし、値なし(Null値)の行が複数存在することは可能である。

一意性制約はCREATE TABLE文やALTER TABLE文でCONSTRAINT句とUNIQUEキーワードを用いて設定することができる。列の定義に続けて「CONSTRAINT 制約名 UNIQUE」とすればその列に制約が設定され、テーブル定義の末尾で「CONSTRAINT 制約名 UNIQUE (列名1,列名2,…)」とすれば複数の列にまとめて制約を設定することができる。

主キー制約との違い

似た制約に「主キー制約」(プライマリキー制約、PRIMARY KEY制約)がある。これは、ある列または複数の列の組み合わせに対し、その各行の値が空(Null)ではなく、かつ他の行と重複しない(複数列の場合は同じ値の組み合わせにならない)ことを保証する。テーブルに一つだけ設定することが可能で、各行を一意に識別するための識別子(主キー)を設定するのに使われる。

あるテーブル(子テーブル)の列に参照制約を設定すると、参照先のテーブル(親テーブル)の指定された列に記録された値しか書き込むことができないようになる。参照先の列に対しても、子テーブルから参照されている値は削除することができない制約が設けられる。

これにより、例えば、受注テーブルの顧客コードには、顧客テーブルに存在するコードしか記入できないようにするといった制約を加えることができる。一般的なSQL文では、CREATE TABLE文のCONSTRAINT句の内部で「FOREIGN KEY」キーワードを用いることで制約を作成することができる。

検査制約を設定した列では、データの書き込みが行われる際に制約に指定した条件を満たすかどうかをチェックし、満たしていなければ書き込みは拒否される。制約はテーブルの作成時などにSQL文の中で条件式などを用いて記述する。

例えば「価格」フィールドに対して「価格>=0」という検査制約を設定しておけば、価格として負の値を記録しようとしてもデータベース管理システム(DBMS)が制約違反として拒否する。

非NULL制約を指定した列は、値が未設定の状態(Null)であることは許されず、追加・更新の際に必ず何らかの値を付与しなければならない。SQL文などで必要な列に値が存在しない状態で書き込みを行おうとするとデータベース管理システム(DBMS)側から拒否される。

当該列がNull値にはならないことをデータベース側で保証するため、アプリケーション側はこれを前提にプログラムを設計・実装することができるようになる。主キー制約など他の制約でもNull値の格納を拒否する仕様のものがある。

何に対するどんな権限を設定できるかはシステムの種類によって様々だが、単にアクセス権といった場合はOSのアカウント管理システムやファイルシステムなどを通じて設定される、ストレージ(外部記憶装置)内のファイルやフォルダ、周辺機器などに対する利用権限を指すことが多い。

多くのOSでは、ファイルやフォルダに対しては「読み込み」「書き込み」「作成」「削除」などの動作について、また、実行可能ファイルはこれに加えて「実行」について可否を設定できるようになっている。

アクセス権は特定のユーザーアカウントやアカウントのグループを単位に設定するようになっていることが多いが、「管理者」「全員」「システム」「作成者」など特別な組み込みアカウントやグループを指名できる場合もある。

アクセス権を変更する権限を持つのは一般に管理者や管理者グループに属するユーザーで、一般の利用者は与えられたアクセス権に従って資源を使用するのみになっていることが多い。

基本的な構文は「SELECT 列名 FROM 表名 WHERE 条件」で、表名で指定したテーブルの中から指定した条件に一致する行を探し出し、列名で指定した列(フィールド)を列挙したデータを返す。列名に「*」を指定すると行全体を返し、WHERE句を省略するとすべての行を返す。

オプションで「ORDER BY 列名 ASC」を追加すると指定された列の値が小さい順(昇順)に行を整列(ソート)したものを返し、ASCの代わりに「DESC」を指定すると列の値が大きい順(降順)に整列したものを返す。

また、「GROUP BY 列名」を追加すると指定した列の値が同じ行同士をグループ化することができる。これはCOUNT関数と共に用いられることが多く、条件に一致する行の中から指定した列の値が同じものを数え上げ、その行数を返させることができる。

FROM句は「FROM (SELECT ～)」のように別のSELECT文を入れ子に指定することもでき、内部のSELECT文が返すテーブルを対象に抽出を行う。入れ子状になった内側の問い合わせを「サブクエリ」「副問い合わせ」(subquery)という。DBMSによってはSELECT文で計算式や組み込み関数の実行を行うこともでき、FROM句の省略が可能な場合もある。

SELECT文で抽出した行に対し、指定した列の値が同一である行同士を一つのグループとしてまとめ、グループごとに一つの値を返す。どんな値を返すかは集計関数によって指定し、「COUNT」(行数カウント)や「SUM」(合計値)、「AVG」(平均値)などを用いる。

例えば、「SELECT COUNT(*) AS Count, AVG(Age) AS AvgAge FROM Users GROUP BY Region」のように指定すると、Usersテーブルの行をRegionフィールドの値が同一であるもの同士でグループ化し、その行数をCountとして、Ageフィールドの平均値をAvgAgeとして返す。

対象をテーブル全体ではなく指定した条件に基づいて絞り込みたい場合は末尾にHAVING句を付け加える。例えば、先のクエリの末尾に「HAVING Age > 20」を加えると、Ageフィールドが20より大きい行のみを対象に集計を行う。

複数の同じ種類の要素が一列に並んでいる場合に、すべての要素に一律に適用可能な順序の規則を用いて並べ替える操作を意味する。数値と日付のように異なる種類の要素が混在していたり、要素間にじゃんけんの出し手のような循環的な関係性がある場合には正しく整列することができない。

数を小さい方から大きい方へ並べる順序を「昇順」(ascending order)、その逆を「降順」(descending order)という。数以外の場合、アルファベットを「A」から「Z」へ、読み仮名を「あ」から「ん」へ、日付や時刻を古い方(過去)から新しい方(未来)へといったように、本来の並び順や自然な順序を昇順、逆を降順という。

ソートアルゴリズム

コンピュータによるデータ処理でも並べ替えは頻繁に用いられる操作で、整列手順を定式化したものを「ソートアルゴリズム」(sorting algorithm)という。古くから活発に研究され様々な手法が考案されており、計算回数の少なさ(高速さ)や必要な記憶装置の容量、手順のシンプルさ(プログラムの短さ)などが異なる。

平均的に効率が良く、広く用いられるのは「クイックソート」(quick sort)と呼ばれる手法で、要素数がn倍になると平均の計算時間が n×log₂n 倍になる。プログラミング言語に標準で組み込まれた配列を整列する関数などによく採用されている。

データ列に同じ値が含まれる場合、その出現順がソート前後で変わらない手法を「安定ソート」(stable sorting)、保存されるとは限らない(順序が入れ替わることがある)手法を「不安定ソート」(unstable sorting)という。

また、元のデータ列の格納領域のみを用いて操作が完結する手法を「内部ソート」(in-place sorting)、外部に別の領域を確保する必要がある手法を「外部ソート」(external sorting)という。組み込みシステムなど利用できるメモリ領域が限られる場合には、高速性よりも内部ソートであることが重視されることもある。

よく用いられるのはSQLのSELECT文を利用した副問合せで、SELECT文や他の様々な文の中に別のSELECT文を副問合せとして埋め込み、その実行結果を条件や対象を記述する際の値として利用する。副問合せ中の条件などの記述にさらに副問合せを用いて、何段階も入れ子(ネスト)状にすることもできる。

条件として副問合せの結果と特定の値の一致や大小比較を記述する場合は副問合せの結果が必ず単一に定まる必要があるが、INやALLなどの演算子を用いて「いずれかが一致する」など複数の結果を扱う条件を記述することもできる。

副問合せを用いるとデータをいったん制御プログラムに引き取って処理しなくても、一つのクエリの記述・実行だけで多様な処理を行うことができるが、処理の負荷が大きく実行に時間がかかることが多い。

ITの分野では、文字列の指定や比較、探索などを行う際に、任意の、あるいは特定のパターンに一致する文字列を表す特殊な記法や記号のことをパターン文字列という。どの記号がどのパターンを意味するかはソフトウェアの種類によって異なる。

例えば、Windowsのコマンドプロンプトでファイル名などを指定する際に、「?」は任意の一文字を、「*」は任意の長さの任意の文字列を表す。これにより、「ta?e」という表記は「take」「tale」「tape」などに一致し、「ta*e」という表記はこれらに加えて「taste」「tackle」などにも一致する。

特殊な記法で文字列のパターンを指定する方式には「正規表現」(regular expression)もあり、プログラミングなどでよく用いられる。任意の文字列に一致する部分を指定できる点はパターン文字列と共通しているが、文字の種類や繰り返しの回数など、より細かい条件を複雑に組み合わせて指定することができる。

競技におけるワイルドカード

スポーツなどの競技会では、本大会や決勝トーナメントなど予選で出場者を決める場合に、本来の選出枠とは別に特別に用意された枠のことをパターン文字列ということがある。敗者復活枠や主催者による推薦枠などがこれに当たり、その枠に選出された選手やチームなどを指してパターン文字列と呼ぶ場合もある。

例えば、北米のプロ野球リーグであるメジャーリーグベースボール(MLB)では、総合優勝を決めるポストシーズンには各リーグの各地区の優勝チームに出場権が与えられるが、これとは別に、2位以下のチームの中で各リーグの勝率上位2チーム(計4チーム)に特別な出場枠が用意されており、これをパターン文字列という。

基本的な構文は「INSERT INTO 表名(列名1, 列名2, …) VALUES(値1,値2,…)」というもので、列名1に値1、列名2に値2という具合に、指定された順に各列に値が代入された新しい行が追加される。列名の指定を省略するとテーブル作成時に定義された順序に従って値が代入される。

DBMSによっては特定の値の代わりに「DEFAULT」を指定することで、その列のデフォルト値(何も指定しなかったときの初期値)を指定することができ、VALUES句を「VALUES DEFAULT」とすることですべての値をデフォルトにすることもできる。

基本的な構文は「UPDATE 表名 SET 列名1=値1, 列名2=値2, … WHERE 条件」で、表名で指定したテーブルのWHERE句で指定した条件に該当する行について、SET句で示した各列に対してそれぞれ「=」以降に記した値を書き込んでいく。列名は存在する限りいくつ列挙してもよい。WHERE句を省略した場合は表中のすべての行に同じ更新を適用する。

値の指定には自身の元の値を使った計算式を用いることもでき、例えば「SET X=X*2」のように記述すると「Xを元の数の2倍で置き換える」という指定になる。また、「SET 列名1=(SELECT～)」のように別のSQL文を入れ子状に記述することもでき、内部のSQL文(サブクエリ、副問い合わせ)の結果を代入することができる。

構文は「DELETE 表名 WHERE 条件」で、表名で指定したテーブルの中からWHERE句で指定した条件に該当する行を削除する。DBMSによっては、WHERE句に「CURRENT OF」と指定することでカーソルが現在指し示している行を削除することもできる。

WHERE句を省略するとテーブルに含まれるすべての行が削除され、テーブルは空の状態に戻る。全件削除する構文としてはTRUNCATE文もあるが、DELETE文は一行ずつ削除処理を行い負荷が大きいため、テーブルを空に戻す用途ではTRUNCATE文を使うべきとされる。

また、DBMSによってはLIMIT句で削除件数の上限を、ORDER BY句で指定された列の値を用いて昇順あるいは降順に並べ替えてから削除するよう指定することもでき、「日付の古い方から10件削除」といった操作を指示することもできる。

データベース管理システム(DBMS)上で作成されたユーザー(利用者アカウント)やロール(ユーザーに与えられた役割)に対して、テーブルなど各オブジェクトの作成や参照、追加、更新、削除などの権限を与える。DBMSによってはシステム管理のための操作を行なう権限を付与できる構文が用意されていることもある。

基本的な構文は「GRANT 権限 ON オブジェクト名 TO ユーザー名またはロール名」で、指定されたユーザーやロールに対して、オブジェクト名で指定したオブジェクトに対する操作権限を付与する。対象を「PUBLIC」とすると全ユーザーに権限を与える。

権限は「SELECT」(参照)、「UPDATE」(値の変更)、「INSERT」(行の追加)、「DELETE」(行の削除)など実行可能なSQL文の種類で指定するか、「CONNECTION_ADMIN」などシステム権限の名前で指定する。「ALL」または「ALL PRIVILEGES」ですべての操作を指定することができる。

末尾に「WITH GRANT OPTION」を指定すると、権限を与えられたユーザーは同等の権限を他のユーザーに与えることができるようになる。また、「GRANT ロール名 TO ユーザー名」とすることでユーザーにロールを与えることもできる。GRANT文で付与した権限を剥奪するにはREVOKE文を用いる。

文字ベースの表示・操作画面(CUI：Character User Interface)では、利用者が入力した文字が出現する位置を表す特殊な図形文字などのことをカーソルという。システムによってはキャレット(caret)、キーボードカーソル、テキストカーソルなどと呼ばれることもある。

下線や縦棒、全体が塗りつぶされた縦長の長方形などが用いられることが多く、単なる記号ではなくカーソルであることを示すため点滅などの装飾が行われることもある。挿入モードと上書きモードなど、キー入力の動作の違いにより形状が変化する場合もある。

グラフィック表示を多用した操作画面(GUI：Graphical User Interface)の場合には、マウスなどのポインティングデバイス(位置入力装置)が画面上で指し示している現在位置に矢印や手などを模した小さなアイコンが表示され、これをカーソルという。マウスポインタ(mouse pointer)とも呼ばれる。GUI画面でもスマートフォンのようにタッチ操作が前提の場合はカーソルは表示されない。

“cursor” の原義は計算尺の目盛りを合わせるのに用いる可動部品のことで、尺の目盛りの中からカーソルの指し示す値を読み取って計算結果を得た。これになぞらえ、コンピュータ上で現在地を指し示す記号をカーソルと呼ぶようになった。

複数の処理を連結した処理単位を「トランザクション」(transaction)という。関連付けられた複数の処理が「すべて成功」か「すべて失敗」のどちらかであることを保証し、途中で処理が停止・失敗した場合にはすでに完了済みの処理を取り消して、トランザクション開始前の状態に戻すようになっている。

例えば、資金の移動を情報システムで処理する場合、「出金処理は完了したが入金処理には失敗した」状態で処理を終了することは許されない。このような場合に、入出金処理全体を一つのトランザクションとしてまとめて管理し、いずれかの処理が失敗したら残りも取り消して、すべて成功したときに初めて全体を完了とする。

トランザクション処理に求められる4つの特性を「ACID特性」という。複数の処理が一体不可分であることを表す “Atomicity”(原子性)、処理の前後でデータの整合性が保たれることを表す “Consistency” (一貫性)、他の処理へ影響を与えず、また影響を受けないことを表す “Isolation” (独立性)、処理結果が失われず永続することを表す “Durability”(耐久性)の頭文字をつなぎ合わせたものである。

データベースシステムなどでトランザクション処理が必要な場合は、データベース管理システム(DBMS)の機能やTPモニタなどの専用のミドルウェアを用いて複数の処理の一体的な管理を行う。一連の処理全体が成功してデータの変更を反映させることを「コミット」(commit)、途中で中断や失敗が生じて開始前の状態に戻すことを「ロールバック」(rollback)という。

トランザクション処理は複数のデータ処理を一体不可分の単位として扱う実行方式で、実行の前後でデータに矛盾が無いことが要請される。実際のコンピュータシステムでは複数のトランザクションを同時に稼働させる必要があり、他のトランザクションの操作によって処理に矛盾を来さないよう適切に制御する必要がある。

原理的にまったく互いに干渉しないようにするにはトランザクションを並行に実行せず順番に実行する「直列化」(シリアライゼーション)を行えば良いが、性能が極端に下がり処理が進まなくなってしまうため現実に採用することは難しい。

そこで、アクセスしようとする資源(テーブルやレコードなど)を一時的に封鎖(ロック)して占有し、処理中は他のトランザクションのアクセスを禁じる「排他制御」が行われる。テーブル単位で行うか行単位で行うか、他のトランザクションの読み書きを完全に禁じるか読み込みは許可するのかなど、ロックの仕方には様々な種類がある。

トランザクション分離レベル

同時実行制御におけるトランザクションの並行性(高速性)と独立性(安全性)はトレードオフ(あちらを立てればこちらが立たず)の関係にあるため、それぞれをどの水準で両立(妥協)するのかについていくつかのレベル提唱されている。よく知られるSQL標準では4段階のトランザクション分離レベルを定義している。

最も安全だが性能が低いレベルが「SERIALIZABLE」で、直列化したのと同じように他のトランザクションの影響をまったく受けないよう制御する。次に安全なのが「REPEABLE READ」で、対象データを処理中に他のトランザクションが削除・更新するのを防ぐ。

3番目は「READ COMMITED」で、他のトランザクションでコミットされた値の変更の影響を受ける。最も分離レベルが低いのが「READ UNCOMMITED」で、他のトランザクションによる未コミットの変更の影響も受ける(が最も性能が高い)。

例えば、あるプログラムがストレージ上のあるファイルに書き込みを行なっている最中に、並行して実行されている別のプログラムがそのファイルへの書き込みを開始してしまうと、ファイルの内容が破壊され整合性のないものになってしまう。

このような事態を防ぐために、ファイルへの書き込みが行われている間は別のプログラムによる書き込みを禁止するという制御が行われる。このような制御は「ロック」(lock)と呼ばれ、最も有名な排他制御の方式の一つである。

排他制御は割り込み禁止機構などのハードウェア上の機能を利用して実装する場合と、プログラムの実行制御によりソフトウェア的に実装する場合がある。オペレーティングシステム(OS)やライブラリなどの中には、これを利用するプログラムに対して何らかの同期機構を提供するものもある。

OS上のプロセスやプログラム上のスレッド間でロック機構を実現する方式として「ミューテックス」(mutex)がよく用いられる。また、資源が複数個ある場合の排他制御として、プロセスが資源へのアクセスを開始・終了する度に利用可能な残り数を増減させる「セマフォ」(semaphore)が用いられることもある。

同期機構のロック

ソフトウェアの排他制御の仕組みの一つで、ファイルへの書き込みや周辺機器の操作などを行う際に、他からのアクセスを一時的に禁止する方式をロック方式という。

並行して複数のプログラムなどが動作している場合に、データや機器の状態の整合性を保つために行われる。対象を利用するプロセスはまず他からのアクセスを禁じるロック方式処理を行い、対象の状態を変更する。変更が終わったらロック方式を解除して他のプロセスへ開放する。

これにより、データの書き込み中に他のプロセスの書き込みが重なって内容が破損したり、書き換え途上の内容が読み取られたり、周辺機器に一貫性のない命令が送信されることを避けることができる。

ただし、二つのプロセスが二つの対象を同じタイミングで取り扱うような場合に、両者が互いに相手方がロック方式している資源の開放を待ってしまい、いつまでも処理が進まない状態に陥る場合がある。これを「デッドロック」(deadlock)という。

機器のロック

スマートフォンなどの情報機器で、一定の条件が満たされるまで操作を受け付けないようにするオペレーティングシステム(OS)の機能をロック方式ということがある。

通常の操作が行えないロック方式画面が表示され、利用者は特定の操作を行わなければ操作画面に戻ることができない。単に画面の特定箇所のタッチやスワイプなどで解除される設定になっていることもあるが、利用者認証が必要な設定の場合には、パスコードの入力や生体認証などを行い、本人であることが確認できない限りロック方式は解除されない。

セマフォ方式はコンピュータ上の共有資源について、利用可能な資源の数を指し示している。プログラムが資源を占有するときはセマフォ方式の値から1を減じ、処理が終わって解放する際には1を加える。セマフォ方式が0のときは空いている資源がないため正の値になるまで待機する。セマフォ方式の値を同じ資源に同時にアクセスできるプロセスの数として扱う場合もある。

資源を獲得しセマフォ方式を減じる処理を「P操作」、資源を解放しセマフォ方式を加える処理を「V操作」という。関数名などではP操作を「down」「wait」「acquire」「pend」などの語で、V操作を「up」「signal」「release」「post」などの語で表すことが多い。

セマフォによる同期

セマフォ方式の値の増減はどのプログラムからも常に可能であるため、同期処理に用いることもできる。例えば、一方のプロセスが共有資源に書き込んだデータをもう一方が読み込む処理について、書き込み側がセマフォ方式を減じておくことで、書き込み処理が完了するまで読み込み側を待たせておくといった処理が可能となる。

セマフォとミューテックス

資源が複数ある場合を「計数セマフォ方式」あるいは「カウンティングセマフォ方式」と呼び、資源が一つの場合(値が0と1に限られる)を「2進セマフォ方式」あるいは「バイナリセマフォ方式」という。バイナリセマフォ方式は当該資源が利用可能か不可能かを表すと考えられ、特定の資源の競合を防止する「ミューテックス」(mutex)とほぼ同じ機能となる。

歴史

セマフォ方式は1960年代に著名なコンピュータ科学者のエドガー・ダイクストラ(Edsger W. Dijkstra)氏が考案した手法で、英単語の “semaphore” の原義は鉄道の腕木式信号機である(「手旗信号」などの意味もある)。同じ線路に同時に複数の列車が侵入することを防ぐ信号の役割を排他制御になぞらえた名称となっている。

データベースシステムにおけるコミット

トランザクション処理において、関連する処理がすべて成功し、結果を確定させることをコミットメント制御という。

トランザクション処理では一体不可分な複数の処理が「すべて成功」か「すべて失敗」のいずれかになるよう制御している。すべての処理が成功し、データベースの状態を処理結果によって更新することをコミットメント制御という。

一方、途中でいずれかの処理が失敗し、完了済みの処理をすべてキャンセルしてトランザクション開始前の状態に戻すことをロールバック(rollback)という。

バージョン管理システムにおけるコミット

いくつかのバージョン管理システム(VCS)では、利用者が手元で編集・更新したファイルの内容をリポジトリに反映させる処理のことをコミットメント制御という。「コミットメント制御する」のように動詞として用いることもある。

一般的なVCSでは一つのプロジェクトに関連する複数のファイルをリポジトリと呼ばれる専用のファイル保管領域で管理しており、利用者はリポジトリからファイルを取得して内容を編集する。編集したファイルをリポジトリへ登録することをコミットメント制御と呼び、そのファイルの最新バージョンとしてリポジトリに保管される。

コミッター (committer)

分散バージョン管理システムにおいて、リポジトリへコミットメント制御する権限が一部の利用者にのみ与えられている場合に、そのような利用者をコミッター(committer)という。

企業内の小規模プロジェクトのようにメンバーが少数の身内に限られている場合は誰でも自由にコミットメント制御できる設定で運用することが多いが、著名なオープンソースソフトウェアや企業内の大規模プロジェクトなどでは、コミットメント制御できる権限を一部の利用者に限定することがある。その場合、個々の開発者は更新内容をリポジトリへ送信してコミットメント制御を依頼し、コミッターが内容を確認して許可あるいは拒否する。

一般の外来語におけるコミット

ビジネス分野などで一般の外来語としてコミットメント制御(する)という表現用いられることもあり、「責任を負う」「専念する」「主体的に関わる」「結果を約束する」といった意味合いで用いられることが多い。

並行して複数のプログラムが実行されている環境で、同じ記憶領域の内容を同時に読み書きすると内容が破損したり処理に矛盾が生じるため、先にアクセスした主体が処理の終了まで一時的に他の主体によるアクセスを制限・禁止する仕組みをロックという。

ロックの方式のうち、他の主体による参照や書き込み、削除、ロックなどを完全に遮断し、処理の終了まで完全に独占するものを専有ロックという。対象を安全に更新したいときに行われる。同時に一つの主体しか専有ロックを行うことはできない。

一方、他の主体による参照は許可し、書き込みや専有ロックを禁じるロック方式は「共有ロック」という。

並行して複数のプログラムが実行されている環境で、同じ記憶領域の内容を同時に読み書きすると内容が破損したり処理に矛盾が生じるため、先にアクセスした主体が処理の終了まで一時的に他の主体によるアクセスを制限・禁止する仕組みをロックという。

ロックの方式のうち、他の主体による書き換えや削除は禁じるが、読み込みは許可するものを共有ロックという。ロックを行った主体自身も書き込みを行うことはできず、対象を安全に参照したいときに行われる。複数の主体が同時に共有ロックをかけて同時に参照することもできる。

一方、他の主体による書き込みだけでなく参照も禁じ、対象へのアクセスを一時的に完全に独占するロック方式は「排他ロック」あるいは「占有ロック」という。

例えば、リレーショナルデータベース(RDB)の場合、あるプログラムがあるデータベースのあるテーブルのあるレコードにアクセスする際に行うロックの対象範囲として、「当該データベース全体」「当該テーブル」「当該テーブルの当該レコードを含む記憶装置上のブロック」「当該レコード」などが考えられる。

データベース全体のように広い範囲をいっぺんにロックすることを「ロック粒度が粗い」あるいは「ロック粒度が大きい」という。逆に、レコード単位のように小さな範囲だけロックすることを「ロック粒度が細かい」あるいは「ロック粒度が小さい」という。

ロック粒度が粗い場合、ロックに伴う処理の負担は小さいが、広範囲をロックするため競合状態が起きやすく、ロック解放の待ち時間が長くなり、並列に実行できるトランザクションの数は少なくなる。ロック粒度が細かいと、これとは逆にロック処理の負担は大きくなるが、競合が起きにくく、待ち時間は短くなり、トランザクションの並列度を高めやすくなる。

データベース管理システム(RDBMS)は主にテーブル単位のロック(テーブルロック)と行単位のロック(行ロック/行レベルロック)に対応しており、SQL文の記述などでどちらを適用するか選択できるようになっていることが多い。

一台のコンピュータ上で複数の処理の流れ(プロセスやスレッド)を並行して実行する場合、処理の矛盾や不整合を防ぐため、ある主体が特定の資源(メモリ領域など)を利用している間、他の主体がその資源にアクセスすることを禁じる「排他制御」が行われることがある。

並行に実行されているスレッドAが資源aを、スレッドBが資源bをそれぞれ占有(ロック)して処理を開始し、途中でAがbを、Bがaを必要とした場合、AはBがbを解放するまで待とうとするが、同時にBはAがaを解放するのを待とうとする。互いに相手の終了待ちとなってしまい、いつまでも処理が進まなくなってしまう。

このような状況は三者以上でも起きることがあり、AやBの処理そのものに一見誤りがなくても発生し得るため、原因不明の不具合としてなかなか発見できない場合もある。万能の解決策は無いが、ロックの順番を揃える、ロックの粒度を細かくする、同時にアクセスされやすい資源はグループ化して両方同時にロックするといった手法で緩和することができる。

トランザクション処理では、振り込みにおける出金と入金のように一体不可分な連続した処理を、すべて成功かすべて失敗(途中の処理が失敗したら実行済みの処理を取り消して開始前の状態に戻す)のどちらかに制御する。

分散トランザクションでは複数の独立した処理主体が一連の処理を分担して実行するため、通常のコミット処理によって結果を確定させることができない。このような場合に、準備と確定の2段階に分けてコミットを実施する方式を2相コミットメントという。

トランザクションの制御を司るコーディネータはまず、処理を実行して結果を返すよう参加者に通知する。各参加者はトランザクションを構成する処理を実行し、成功したら「コミット可能」の応答を返す。すべての参加者から成功の通知を受け取ったら、コーディネータはコミットを確定するよう参加者に通知する。これを受けてすべての参加者がコミットを実行することにより、トランザクション全体のコミットが完了する。

準備段階で処理に失敗した参加者がいた場合、コーディネータはトランザクションの失敗を全参加者に伝え、行った処理を取り消して巻き戻すロールバック処理を行うよう促す。参加者がコミット可能な状態で待っている際にコーディネータが故障などで停止すると、コミットもロールバックもできないまま放置されてしまうという問題がある。

単にバックアップといった場合は、データの破損や損失に備えてデータの写しを取って保管する「データバックアップ」のことを指す場合が多い。データをコピーする作業や工程のことをバックアップという場合と、作成されたデータの複製(を記録した装置など)のことをバックアップという場合がある。

コンピュータの記憶装置に保存されたデータを別の装置や記憶媒体へ複製して別に保管するもので、機器の故障や破損、人為ミス、不正行為などによってデータの消失や改変などが起こった場合に、複製した時点のデータに復旧させることができる。

また、「バックアップ回線」「バックアップサーバ」などのように、通常時に使用している機器などが何らかの原因で正常に稼働できなくなった時に、その機能を肩代わりするための機器や設備、施設などのことをバックアップということもある。

ストレージ(外部記憶装置)について言う場合は、媒体の破損などでデータが正常に読み出せなくなった機器から可能な限りデータを取り出して保全したり、故障した装置を新しいものと交換して残りの装置からデータを復元する作業(RAID等の場合)などを表す。

ソフトウェアについて言う場合は、プログラムや設定の不具合で正常に動作しなくなったオペレーティングシステム(OS)などを消去し、再び導入(インストール)し直して初期状態に戻すことなどを指す。この場合、導入済みのソフトウェアや保存された設定情報、データなどは消去されるため、必要であれば利用者が別の装置への保全などを行わなければならない。

システムの稼働中に変更された箇所や変更内容などを時系列に記録したデータを指すことが多い。システム障害やデータ喪失などが発生した際に、原因究明や復旧のために使用される。システムの性能上の問題点の分析や、改善のデータとしても使用される。

分野や文脈によっては「ログ」(log)の同義語とする場合もあるが、「ログ」がある操作や出来事が「起こったという記録」を指すのに対し、ジャーナルファイルはある操作や処理によって「変更された内容の記録」を指すことが多い。この場合、「ある時点の状態に戻す」といった処理をログに基づいて行うことはできず、ジャーナルファイルが必要となる。

データベース管理システムでは、トランザクション処理によって一体として処理されるべき更新情報をジャーナルファイルに記録する。更新中に障害などで中断した場合には、ジャーナルファイルの記録を元にすべての処理を取り消して元に戻したり、中途の処理を完了させて更新を確定したりする。

ファイルシステムの一種である「ジャーナリングファイルシステム」では、ストレージへの書き込み前にファイルの更新情報などをジャーナルファイルに記録する。書き換え中に故障や電源断が発生してストレージ上のデータの整合性が失われた場合などに、ジャーナルファイルの記録を元に書き込み前あるいは後の状態に速やかに回復することができる。

オペレーティングシステム(OS)やアプリケーションソフトなどが作成するもので、利用者の操作の状況や、障害や不具合、警告などの発生状況、外部とのデータの送受信などを記録することが多い。

一般的には日時(ファイルが日毎に分かれている場合は時刻)と出来事を発生した順に記録していく。記録形式はソフトウェアによって異なるが、テキストファイルに改行区切りで一件一行ずつ記録していく方式がよく採用され、人間にとっても視認性が良く自動処理もしやすい。

LOGファイル (.logファイル)

ログファイルのファイル名として、拡張子を「.log」とした名前が用いられることがよくあるが、これはシステム内で他の形式や役割のファイルと区別するためで、特定の同じファイル形式で記録されているわけではない。

中身のログデータの記録形式はシステムごとに異なっており、統一された標準形式があるわけではなく、他のシステムとの互換性もない。ただし、多くのシステムは改行区切りのテキストデータとしてログを記録するため、利用者が直接開いて内容を確認したり、簡易なプログラムで解析や変換を行うことができる。

データベースのチェックポイント

データベース管理システム(DBMS)で、データベースへの変更をストレージ(外部記憶装置)上のファイルに書き込む処理や、最後にそのような書き込み処理が行われた時点のことをチェックポイントという。

データベースの内容の変更はまずメインメモリ(RAM)上で行われ、ストレージへの反映は変更内容がある程度溜まってからまとめて行われる。障害発生時にはチェックポイントのデータを元に復旧作業を行なうことが多い。

障害発生時にすでにコミットされたトランザクションの復旧には、チェックポイント時のデータにトランザクションログに記録された処理を適用していき、コミット時の状態に戻す。この作業を「ロールフォワード」(roll forward)という。

一方、障害発生時にコミットされていなかったトランザクションの場合は処理をすべて取り消して開始前の状態を復元し、最初からトランザクションをやり直す。これを「ロールバック」(rollback)という。

障害発生時点ですでに完了(コミット)済みのトランザクションに対して用いられる復帰手法で、直前のチェックポイントで作成された全データのバックアップを、(交換後の新しい)記憶装置に書き込み、チェックポイント後に実行された処理を記録したジャーナルファイルの内容を順番に反映させていき、トランザクションが完了した状態を再現する。

一方、障害発生時に処理途上でコミット前だったトランザクションに対しては、チェックポイント以前の変更を遡って取り消していき、トランザクション開始前の状態に戻す。この処理を「ロールバック」(rollback：後退復帰)という。

トランザクション処理は複数の処理を一体化して実行するもので、「すべて実行前」「すべて完了」のいずれかになるように制御しなければならない。ロールフォワードはトランザクション完了時の状態に、ロールバックは開始前の状態にそれぞれ復帰するもので、いずれもトランザクションの原子性(atomicity)を維持することができる。

ある時点の正常な状態のデータやプログラム、設定などを複製してまとめて保管しておき、障害などが発生した時にこれをシステムに書き戻してその時点の状態に戻す処理をロールバックという。

トランザクション処理のロールバック

特にデータベースシステムのトランザクション処理でよく用いられる概念である。トランザクション開始前の状態を保存しておき、コミットする前に途中で中断された場合に完了済みの処理をすべてキャンセルし、開始前のデータを書き戻して復旧する。トランザクションは途中で終了すると結果に矛盾が生じることがあるため、このような制御が行われる。

一方、障害発生時にすでにコミットされたトランザクションの場合には、ある時点(チェックポイント)で複製したデータを書き戻し、これにトランザクションログに記録された処理を適用していき、コミット時の状態に戻す。この復帰方式を「ロールフォワード」(roll forward)という。

通常の起動プロセスでは、内蔵された装置や回路の初期化や検査が行われるが、ウォームスタートではこうした初期段階の一部をスキップし、迅速にオペレーティングシステム(OS)のストレージからの読み込みと起動に移る。

すでにハードウェアが稼働状態になっていることが分かっているOSの再起動時などに用いられる起動方式だが、近年のWindowsのようにシャットダウン操作を行ってもOSが終了した状態で停止し、次回起動時にウォームスタートで高速に起動するシステムもある(高速スタートアップ)。

一方、完全に電源断の状態に戻して最初からすべてのプロセスを実行して起動することは「コールドブート」(cold boot)あるいは「コールドスタート」(cold start)という。シャットダウンからの起動がウォームスタートのシステムでは、明示的に再起動を指示するとコールドブートが行われ、却って時間がかかる場合ある。

通常のコンピュータの起動プロセスをゼロからすべて行う起動方法で、BIOSやUEFIによるメインメモリ(RAM)や各装置のチェックや初期化、OSのストレージ(外部記憶装置)からの読み込みと起動などを行う。

一方、ソフトウェアの操作による再起動などの場合、主にハードウェアのチェックなど初期段階のプロセスを飛ばしてOSの起動から行う高速な起動方法もあり、「ウォームブート」(ウォームスタート/ウォームリブート/ウォームリスタート/ホットブート/ホットリブート/ホットスタート/ホットリスタート)などと呼ばれる。

かつては電源を落として起動すると必ずコールドスタートされたが、最近のWindowsなどでは初期状態ではOSの「電源を切る」操作がOSを終了するだけで停止状態となり、再び電源ボタンなどを押して起動するとウォームブートされる(高速スタートアップ)場合がある。その場合、以前はウォームブート動作であることが多かった「再起動」操作が逆に完全に初期状態から起動するコールドスタートとなっている。

トランザクション処理は連続する複数の操作が一体的に一つの処理や手続きを形成したもので、例えば、銀行における口座間の送金処理は「送金元口座からの出金」と「送金先口座への入金」という二つの操作が一体不可分の関係となっている。

「出金したが入金に失敗した」状態で終了してはお金が宙に浮いてしまうため、全体が成功するか、さもなくば全体を取り消すといった制御を行う必要がある。このような場合にシステムに求められる4つの特性、“Atomicity” 、“Consistency”、“Isolation”、“Durability” の頭文字を繋げて “ACID” と呼んでいる。

“Atomicity” (原子性/不可分性)とは、トランザクションに含まれる個々の手順が「すべて実行される」か「一つも実行されない」のどちらかの状態になるという性質である。送金処理における出金と入金を一体的に扱うことなどが該当する。

“Consistency” (一貫性/整合性)とは、トランザクションの前後でデータの整合性が保たれ、矛盾の無い状態が継続される性質である。例えば、送金トランザクションによって口座の残高の値が負になるといったことが起きないようにする。

“Isolation” (独立性/隔離性)とは、トランザクション実行中の処理過程が外部から隠蔽され、他の処理などに影響を与えない性質である。例えば、送金処理の途上である「出金は実施済みだが入金は未実施」といった状態を外部から読み出されないよう排他制御などを行う。

“Durability” (耐久性/永続性)とは、トランザクションが完了したら、その結果は記録され、システム障害などが生じても失われることがないという性質である。データ操作の時系列の記録(ログ)をストレージなどに保存しておき、データ記録中に障害などで中断したら記録を元に更新を反映させるといった処理が行われる。

トランザクション処理は連続する複数の操作が一体的に一つの処理や手続きを形成したもので、例えば、銀行における口座間の送金処理は「送金元口座からの出金」と「送金先口座への入金」という二つの操作が一体不可分の関係となっている。

「出金したが入金に失敗した」状態で終了してはお金が宙に浮いてしまうため、全体が成功するか、さもなくば全体を取り消すといった制御を行う必要がある。このような場合にシステムに求められる4つの特性、“Atomicity” 、“Consistency”、“Isolation”、“Durability” の頭文字を繋げて “ACID” と呼んでいる。

“Atomicity” (原子性/不可分性)とは、トランザクションに含まれる個々の手順が「すべて実行される」か「一つも実行されない」のどちらかの状態になるという性質である。送金処理における出金と入金を一体的に扱うことなどが該当する。

“Consistency” (一貫性/整合性)とは、トランザクションの前後でデータの整合性が保たれ、矛盾の無い状態が継続される性質である。例えば、送金トランザクションによって口座の残高の値が負になるといったことが起きないようにする。

“Isolation” (独立性/隔離性)とは、トランザクション実行中の処理過程が外部から隠蔽され、他の処理などに影響を与えない性質である。例えば、送金処理の途上である「出金は実施済みだが入金は未実施」といった状態を外部から読み出されないよう排他制御などを行う。

“Durability” (耐久性/永続性)とは、トランザクションが完了したら、その結果は記録され、システム障害などが生じても失われることがないという性質である。データ操作の時系列の記録(ログ)をストレージなどに保存しておき、データ記録中に障害などで中断したら記録を元に更新を反映させるといった処理が行われる。

トランザクション処理は連続する複数の操作が一体的に一つの処理や手続きを形成したもので、例えば、銀行における口座間の送金処理は「送金元口座からの出金」と「送金先口座への入金」という二つの操作が一体不可分の関係となっている。

「出金したが入金に失敗した」状態で終了してはお金が宙に浮いてしまうため、全体が成功するか、さもなくば全体を取り消すといった制御を行う必要がある。このような場合にシステムに求められる4つの特性、“Atomicity” 、“Consistency”、“Isolation”、“Durability” の頭文字を繋げて “ACID” と呼んでいる。

“Atomicity” (原子性/不可分性)とは、トランザクションに含まれる個々の手順が「すべて実行される」か「一つも実行されない」のどちらかの状態になるという性質である。送金処理における出金と入金を一体的に扱うことなどが該当する。

“Consistency” (一貫性/整合性)とは、トランザクションの前後でデータの整合性が保たれ、矛盾の無い状態が継続される性質である。例えば、送金トランザクションによって口座の残高の値が負になるといったことが起きないようにする。

“Isolation” (独立性/隔離性)とは、トランザクション実行中の処理過程が外部から隠蔽され、他の処理などに影響を与えない性質である。例えば、送金処理の途上である「出金は実施済みだが入金は未実施」といった状態を外部から読み出されないよう排他制御などを行う。

“Durability” (耐久性/永続性)とは、トランザクションが完了したら、その結果は記録され、システム障害などが生じても失われることがないという性質である。データ操作の時系列の記録(ログ)をストレージなどに保存しておき、データ記録中に障害などで中断したら記録を元に更新を反映させるといった処理が行われる。

トランザクション処理は連続する複数の操作が一体的に一つの処理や手続きを形成したもので、例えば、銀行における口座間の送金処理は「送金元口座からの出金」と「送金先口座への入金」という二つの操作が一体不可分の関係となっている。

「出金したが入金に失敗した」状態で終了してはお金が宙に浮いてしまうため、全体が成功するか、さもなくば全体を取り消すといった制御を行う必要がある。このような場合にシステムに求められる4つの特性、“Atomicity” 、“Consistency”、“Isolation”、“Durability” の頭文字を繋げて “ACID” と呼んでいる。

“Atomicity” (原子性/不可分性)とは、トランザクションに含まれる個々の手順が「すべて実行される」か「一つも実行されない」のどちらかの状態になるという性質である。送金処理における出金と入金を一体的に扱うことなどが該当する。

“Consistency” (一貫性/整合性)とは、トランザクションの前後でデータの整合性が保たれ、矛盾の無い状態が継続される性質である。例えば、送金トランザクションによって口座の残高の値が負になるといったことが起きないようにする。

“Isolation” (独立性/隔離性)とは、トランザクション実行中の処理過程が外部から隠蔽され、他の処理などに影響を与えない性質である。例えば、送金処理の途上である「出金は実施済みだが入金は未実施」といった状態を外部から読み出されないよう排他制御などを行う。

“Durability” (耐久性/永続性)とは、トランザクションが完了したら、その結果は記録され、システム障害などが生じても失われることがないという性質である。データ操作の時系列の記録(ログ)をストレージなどに保存しておき、データ記録中に障害などで中断したら記録を元に更新を反映させるといった処理が行われる。

トランザクション処理は連続する複数の操作が一体的に一つの処理や手続きを形成したもので、例えば、銀行における口座間の送金処理は「送金元口座からの出金」と「送金先口座への入金」という二つの操作が一体不可分の関係となっている。

「出金したが入金に失敗した」状態で終了してはお金が宙に浮いてしまうため、全体が成功するか、さもなくば全体を取り消すといった制御を行う必要がある。このような場合にシステムに求められる4つの特性、“Atomicity” 、“Consistency”、“Isolation”、“Durability” の頭文字を繋げて “ACID” と呼んでいる。

“Atomicity” (原子性/不可分性)とは、トランザクションに含まれる個々の手順が「すべて実行される」か「一つも実行されない」のどちらかの状態になるという性質である。送金処理における出金と入金を一体的に扱うことなどが該当する。

“Consistency” (一貫性/整合性)とは、トランザクションの前後でデータの整合性が保たれ、矛盾の無い状態が継続される性質である。例えば、送金トランザクションによって口座の残高の値が負になるといったことが起きないようにする。

“Isolation” (独立性/隔離性)とは、トランザクション実行中の処理過程が外部から隠蔽され、他の処理などに影響を与えない性質である。例えば、送金処理の途上である「出金は実施済みだが入金は未実施」といった状態を外部から読み出されないよう排他制御などを行う。

“Durability” (耐久性/永続性)とは、トランザクションが完了したら、その結果は記録され、システム障害などが生じても失われることがないという性質である。データ操作の時系列の記録(ログ)をストレージなどに保存しておき、データ記録中に障害などで中断したら記録を元に更新を反映させるといった処理が行われる。

プログラミングなどの分野では、同種の複数のものが並んでいるときに、個々の要素を区別するために付けられた通し番号などの識別情報をインデックスという。配列の要素を指し示す添字などが該当する。

データベースやファイルシステム、検索エンジンなどでは、収集・格納された大量のデータをすばやく検索・抽出するために作成された索引データをインデックスという。データ本体を端から順に探すよりも圧倒的に短い手順で目的のデータを探し出せる。

具体的には、見出しとなる識別符号と、データ本体のある所在情報などを対応付け、整列・分類などを行ったあと木構造やハッシュテーブルなど検索に適したデータ構造に格納したものを指すことが多い。

何らかの主体(人間や機器、ソフトウェアなど)が、システムの管理下にある対象(装置や回線、データ、プログラム、ファイルなど)に対して、どのような操作が許されているかを登録・管理し、権限外の操作を実行しようとした時にはこれを拒否する。

例えば、ファイルシステムによるアクセス制御であれば、各ユーザーアカウントやユーザーのグループに対して、ファイルやディレクトリに対する読み込み、書き込み、削除、プログラムファイルの実行といった権限を付与し、操作主体と権限を確認して許可や拒否を行う。

認証・認可・監査

アクセス制御は「認証」(authentication)、「認可」(aurhorization)、「監査」(audit)といったプロセスから成る。認証は主体を識別して本物であることを確認するプロセスで、利用者にアカウント名を入力させ、パスワードなどの確認手段で本院であることを確かめる活動などが該当する。

認可は権限に基づいて操作の可否を判断するプロセスで、アカウント情報や管理者の定義したポリシー設定、アクセス制御リスト(ACL)などを参照して対象者の資格や権限を確認し、対象者が行おうとしている操作を許可したり拒絶したりする。

監査は、認証や認可、および利用主体による対象へのアクセスの履歴(ログ)を記録・蓄積し、後から「いつ誰が何を試みて結果がどうなったか」を管理者が追跡できるようにするプロセスである。システムやデータの安全を脅かす不審な試みや、不正な行為による被害などを確かめることができるようにする。

モデル

アクセス制御を適用する手法にはいくつかの典型的なモデルがあり、実際のシステムはモデルに基づいてアクセス制御の仕組みを実装している。

古くからありよく知られるのは、操作対象(オブジェクト)の所有者がアクセス許可の指定を行う「任意アクセス制御」(DAC：Discretionary Access Control)で、一般的なオペレーティングシステム(OS)のセキュリティ機能などで採用されている。

これに対して、「強制アクセス制御」(MAC：Mandatory Access Control)は管理者およびシステムが権限を設定し、所有者と言えどこれを変更できない仕組みである。軍用システムなど高度なセキュリティが要求される一部のシステムで実装されている。

他にも、利用者の役割(ロール)ごとに権限を設定する「ロールベースアクセス制御」(RBAC：Role-Based Access Control)や、利用者や操作対象の持つ様々な属性情報を収集し、どの属性のユーザーがどの環境でどの対象にアクセス可能かといった設定を記述していく「属性ベースアクセス制御」(ABAC：Attribute-Based Access Control)などの手法も提唱されている。

何に対するどんな権限を設定できるかはシステムの種類によって様々だが、単にアクセス権限といった場合はOSのアカウント管理システムやファイルシステムなどを通じて設定される、ストレージ(外部記憶装置)内のファイルやフォルダ、周辺機器などに対する利用権限を指すことが多い。

多くのOSでは、ファイルやフォルダに対しては「読み込み」「書き込み」「作成」「削除」などの動作について、また、実行可能ファイルはこれに加えて「実行」について可否を設定できるようになっている。

アクセス権限は特定のユーザーアカウントやアカウントのグループを単位に設定するようになっていることが多いが、「管理者」「全員」「システム」「作成者」など特別な組み込みアカウントやグループを指名できる場合もある。

アクセス権限を変更する権限を持つのは一般に管理者や管理者グループに属するユーザーで、一般の利用者は与えられたアクセス権限に従って資源を使用するのみになっていることが多い。

データベース管理システム(DBMS)上で作成されたユーザー(利用者アカウント)やロール(ユーザーに与えられた役割)に対して、テーブルなど各オブジェクトの作成や参照、追加、更新、削除などの権限を与える。DBMSによってはシステム管理のための操作を行なう権限を付与できる構文が用意されていることもある。

基本的な構文は「GRANT 権限 ON オブジェクト名 TO ユーザー名またはロール名」で、指定されたユーザーやロールに対して、オブジェクト名で指定したオブジェクトに対する操作権限を付与する。対象を「PUBLIC」とすると全ユーザーに権限を与える。

権限は「SELECT」(参照)、「UPDATE」(値の変更)、「INSERT」(行の追加)、「DELETE」(行の削除)など実行可能なSQL文の種類で指定するか、「CONNECTION_ADMIN」などシステム権限の名前で指定する。「ALL」または「ALL PRIVILEGES」ですべての操作を指定することができる。

末尾に「WITH GRANT OPTION」を指定すると、権限を与えられたユーザーは同等の権限を他のユーザーに与えることができるようになる。また、「GRANT ロール名 TO ユーザー名」とすることでユーザーにロールを与えることもできる。参照権限で付与した権限を剥奪するにはREVOKE文を用いる。

データベース管理システム(DBMS)上で作成されたユーザー(利用者アカウント)やロール(ユーザーに与えられた役割)に対して、テーブルなど各オブジェクトの作成や参照、追加、更新、削除などの権限を与える。DBMSによってはシステム管理のための操作を行なう権限を付与できる構文が用意されていることもある。

基本的な構文は「GRANT 権限 ON オブジェクト名 TO ユーザー名またはロール名」で、指定されたユーザーやロールに対して、オブジェクト名で指定したオブジェクトに対する操作権限を付与する。対象を「PUBLIC」とすると全ユーザーに権限を与える。

権限は「SELECT」(参照)、「UPDATE」(値の変更)、「INSERT」(行の追加)、「DELETE」(行の削除)など実行可能なSQL文の種類で指定するか、「CONNECTION_ADMIN」などシステム権限の名前で指定する。「ALL」または「ALL PRIVILEGES」ですべての操作を指定することができる。

末尾に「WITH GRANT OPTION」を指定すると、権限を与えられたユーザーは同等の権限を他のユーザーに与えることができるようになる。また、「GRANT ロール名 TO ユーザー名」とすることでユーザーにロールを与えることもできる。挿入権限で付与した権限を剥奪するにはREVOKE文を用いる。

データベース管理システム(DBMS)上で作成されたユーザー(利用者アカウント)やロール(ユーザーに与えられた役割)に対して、テーブルなど各オブジェクトの作成や参照、追加、更新、削除などの権限を与える。DBMSによってはシステム管理のための操作を行なう権限を付与できる構文が用意されていることもある。

基本的な構文は「GRANT 権限 ON オブジェクト名 TO ユーザー名またはロール名」で、指定されたユーザーやロールに対して、オブジェクト名で指定したオブジェクトに対する操作権限を付与する。対象を「PUBLIC」とすると全ユーザーに権限を与える。

権限は「SELECT」(参照)、「UPDATE」(値の変更)、「INSERT」(行の追加)、「DELETE」(行の削除)など実行可能なSQL文の種類で指定するか、「CONNECTION_ADMIN」などシステム権限の名前で指定する。「ALL」または「ALL PRIVILEGES」ですべての操作を指定することができる。

末尾に「WITH GRANT OPTION」を指定すると、権限を与えられたユーザーは同等の権限を他のユーザーに与えることができるようになる。また、「GRANT ロール名 TO ユーザー名」とすることでユーザーにロールを与えることもできる。削除権限で付与した権限を剥奪するにはREVOKE文を用いる。

「ウェアハウス」(warehouse)とは「倉庫」という意味で、組織内で運用される様々な情報システムやデータベースなどから集めたデータを保管する「データの倉庫」という意味合いでこのように呼ばれる。

通常、種々雑多なデータを単にそのまま記録するわけでなく、同じ意味のデータは横断的に扱えるようにするなど統合し、データの主題ごとに整理し直して格納する。このデータの収集や整形、統合を専門に行うツールを「ETLツール」(Extract/Transform/Load、ELTツールとも)という。

データは発生した時系列に記録していき、更新や削除は行わなず、過去のある時点の個別のデータを参照できるように格納される。集積された過去のデータを元に、OLAPやBIツールなどの分析ツールを用いて抽出や集計、解析、比較などを行なって、計画立案や意思決定などのために有用な知見を得るために構築されることが多い。

データマート

蓄積された個々のデータの中から、利用部門や用途、目的などに応じて必要なものだけを抽出、集計し、利用しやすい形に格納したデータベースを作成する場合があり、これを「データマート」(data mart)という。小規模なシステムではデータウェアハウスを作らずにデータマートだけを構築することもある。

データレイク

データウェアハウスは原則としてリレーショナルデータベース(RDB)など構造化されたデータ形式で記録されたものを対象とするが、近年では情報システムの種類や利用方法の多様化、複雑化を受け、文書ファイルやソーシャルメディアの書き込みなど構造や形式が整っていないデータを扱う機会が増えている。形式によらず非構造化データを含む雑多なデータを一元的に保管する管理システムやデータ群のことを「データレイク」(data lake)という。

企業がデータベースシステムに蓄積する膨大な生データは個々の利用部門にとって不要なデータもあり、データ量によっては迅速に分析できない場合もある。データマートはそのような場合に用意するもので、データを利用部門の主題に沿って整理しなおし、選択や集計、要約によってサイズを減らして構築する。

これにより、各部門は自らの業務に関連するデータのみを用いて素早く分析や集計を実行し、意思決定や計画立案に役立てることができる。再集計などが容易になるため、様々な仮説や切り口から繰り返しデータを分析することで、多面的にデータを活用することができる。

多くの場合、データマートは「データウェアハウス」(data warehouse)に蓄積されたデータを利用し、その一部を抽出・加工して構築されるが、企業やシステムの規模によっては、各システムのデータベースなどから直接データマートだけを構築する場合もある。企業によっては部門や用途ごとに数十から数百のデータマートが構築されることもある。

一般的なOLAPシステムはまずリレーショナルデータベース(RDB)などに蓄積されたデータを集計して多次元データベースを生成し、これを元に利用者の指示した複雑な分析処理を行う。専門の技術者でなくても検索や分析ができるよう、グラフィック表示や項目選択を多用した操作画面や、表やグラフなどを用いた分かりやすい結果表示などの機能を持つシステムが多い。

通常のデータベースシステムによる集計・レポート機能は定期的、定型的なものが中心で時間がかかることが多いが、OLAPは対話的な操作ですぐに結果を返すことができ、その場限りの特殊な分析を行いたい場合や、試行錯誤を繰り返す必要がある場合に特に威力を発揮する。

MOLAP (多次元OLAP)

OLAPシステムの実装方式の一つで、独自に多次元データ構造を整備してから分析を行うものを「MOLAP」(Multidimensional OLAP)という。最もオーソドックスな実装で、単にOLAPといえばMOLAP方式であることが多い。

元データの格納されたリレーショナルデータベースから必要なデータを取り込み、あらかじめ様々な集計データを算出、「OLAPキューブ」と呼ばれる独自の多次元データベースを構築する。データの抽出や集計などはOLAPキューブを元に実行する。

利用者からの問い合わせに素早く応答することができ、複雑で多角的な分析を得意とするが、取り込み時点までのデータしか利用できないためリアルタイム性では劣る。項目数や組み合わせの数によってはキューブの生成・保管に巨大な記憶容量を要する場合もある。利用者は元データとは異なる独自の多次元データベースについての知識や理解が必要とされる。

ROLAP (リレーショナルOLAP)

OLAPシステムの実装方式の一つで、元データの格納されたリレーショナルデータベースをそのまま利用して分析を行うものを「ROLAP」(Relational OLAP)という。元データの格納されたリレーショナルデータベースをそのまま使い、利用者からの問い合わせに応じてデータを抽出、集計して分析結果を提供する。

独自の集計データベースなどを用意しないため元データをリアルタイムに分析でき、MOLAPで必要となる前処理にかかる時間や多次元データの保管領域も不要である。メーカーによる仕様の違いが小さく互換性が高いが、前処理しない分だけ集計処理に長い時間を要することがある。

HOLAP (ハイブリッドOLAP)

MOLAPとROLAPの中間的な実装で、元データはリレーショナルデータベースに格納したまま、集計データのみを独自の多次元データベースに収める方式を「HOLAP」(Hybrid OLAP)という。MOLAPより少ないデータ量で多次元データを構成でき、分析が集計データの範疇に収まる場合は高い性能を発揮できる。元データが必要な状況ではROLAPと同様となる。

「マイニング」(mining)とは「採掘」の意味で、膨大なデータの集積を鉱山に、そこから有用な知見を見出すことを資源の採掘になぞらえている。適用分野や目的、対象となるデータの種類は多種多様だが、ビジネスの分野では企業が業務に関連して記録したデータ(過去の取引記録、行動履歴など)を元に、意思決定や計画立案、販売促進などに有効な知見を得るために行われることが多い。

例えば、小売店の商品の売上データの履歴は、それ自体は会計上の手続きや監査などの業務にしか使われないが、データマイニングの手法で統計的に処理することで、これまで知られていなかった「商品Aと商品Bを一緒に購入する顧客が多い」といった傾向が分かる場合がある。これにより、AとBの売り場を統合するといった販売促進施策を行うことが可能となる。

商業分野だけでなく、自然言語処理やパターン認識、人工知能などの研究などでも利用される。分析・解析の手法も様々だが、代表的な手法としては、頻度の高いパターンの抽出や、相関関係にある項目の組の発見、データの特徴や共通点に基づく分類、過去の傾向に基づく将来の予測などがある。

近年では、一般的なシステムやソフトウェアでの解析が困難な巨大なデータセットである「ビッグデータ」を対象とした解析手法や、人工知能の一分野である機械学習、特に先進的な手法である「ディープラーニング」を応用したマイニング手法などが活発に研究・開発されている。

OLTPシステムでは、利用者の操作などに応じて提起された処理要求を、端末やクライアントが通信回線などを通じてホストコンピュータやサーバにすぐに送信する。これら中央のシステムは受理した処理を即座に開始し、密接に関連する複数の手続きを一体的に実行し、結果をすぐに返答する。

OLTPシステムは大量の処理要求が一斉に集まっても停止したり大きく遅延させない高い性能や拡張性が求められ、また、入出金処理など途中で中断してはいけない処理を扱うため、同時に高い信頼性も要求される。様々な分野や目的で利用される方式だが、日常的には座席やチケットの予約システムや、金融機関における入出金や送金、株式取引などの処理でよく用いられる。

なお、金融取引などで誤りを起こさないよう、複数のデータベース操作を不可分の一体の処理として管理し、「すべて成功」か「すべて失敗」のどちらかになるよう処理する方式を「トランザクション処理」というが、処理要求に基づいて即座にこのトランザクション処理を行うことをOLTPという場合もある。

OLAP・バッチ処理との違い

データのオンライン処理システムには「OLAP」(Online Analytical Processing)もある。これはデータベースなどに蓄積されたデータを利用者の要求に基づいて即座に集計、分析し、直ちに結果を返すシステムである。OLTPのようにデータの操作(追加や更新、削除)は行わない。

OLTPもOLAPも「オンライン」のデータ処理を指す用語である。ここでいうオンラインとは「バッチ処理」と対比される概念で、通信回線などを通じて処理要求を中央システムへ送り、即座に結果を返すという処理形態を指す。バッチ処理の場合はデータや要求はすぐに処理されずに蓄積され、一定期間や一定量ごとに一括して処理される。

一般的にはデータウェアハウスを構築する際に外部のデータベースや何らかの情報源からデータを取り出して必要な形式に整えて保存することを指す。このような処理を行う専門のソフトウェアや拡張機能をETLツールという。

抽出元となるのは業務システムに日々蓄積されていく様々な種類や内容、形式のデータで、ETLツールは様々なシステムに対応できるよう、リレーショナルデータベース(RDB)やCSVファイル、表計算ソフトのデータファイル、XMLファイル、ログファイル、テキストファイルなど多様なデータ形式を読み込めるようになっている。

変換・加工の過程では、得られたデータ群から分析のために必要な要素を特定し、分析システム側が利用できる表現形式に変換したり、不要な要素を切り落としたりする。複数の値を組み合わせて新たな値を生成したり、一つの値を複数に分割したりといった処理が行われることもある。複数の情報源からのデータを統合する操作もここで行われる。

格納の工程ではデータウェアハウスなど対象のシステムにデータを流し込む。データの取り込みはリアルタイムには行われず、一週間や一ヶ月といった一定の期間毎に定期的に行ったり、分析業務を始める前にまとめて行うことが多い。

蓄積されたデータを分析したり活用したりする際に、同じ意味を表しているのに表記が微妙に異なっていて同一とみなされない例など、そのままでは自動処理に適さない状態になっていることがある。特に、複数の情報源からデータを集めた場合や、一件ごとに入力者が異なる場合などにこの点が問題となることが多い。

そのような場合に、一定の基準やルールなどを定め、一項目ずつデータを調べて適切な状態に編集、統合、補正などしていく処理や作業をデータクレンジングという。具体的な手法はデータの種類や形式、利用目的などにより様々である。

一般的な例としては、全角文字と半角文字の違いや、空白文字や区切り記号の有無、人名の異体字の誤りや姓名の分割・併合、法人名の表記(株式会社と(株)の違いなど)、住所や電話番号の表記法などが対象となり、それぞれについて表記ルールを決めて修正や削除などを行なっていく。

多くの場合、ビッグデータとは単に量が多いだけでなく、様々な種類・形式が含まれる非構造化データ・非定型的データであり、さらに、日々膨大に生成・記録される時系列性・リアルタイム性のあるようなものを指すことが多い。

今までは管理しきれないため見過ごされてきたそのようなデータ群を記録・保管して即座に解析することで、ビジネスや社会に有用な知見を得たり、これまでにないような新たな仕組みやシステムを産み出す可能性が高まるとされている。

米大手IT調査会社ガートナー(Gartner)社では、ビッグデータを特徴づける要素として、データの大きさ(Volume)、入出力や処理の速度(Verocity)、データの種類や情報源の多様性(Variety)を挙げ、これら3つの「V」のいずれか、あるいは複数が極めて高いものがビッグデータであるとしている。これに価値(Value)や正確性(Veracity)を加える提案もある。

コンピュータやソフトウェアの技術の進歩は速く、具体的にどのような量や速度、多様さであればビッグデータと言えるかは時代により異なる。ビッグデータという用語がビジネスの文脈で広まった2010年代前半にはデータ量が数テラバイト程度のものも含まれたが、2010年代後半になるとペタバイト(1000テラバイト)級やそれ以上のものがこのように呼ばれることが多い。

近年ではスマートフォンやSNS、電子決済、オンライン通販の浸透により人間が日々の活動で生み出す情報のデータ化が進み、また、IoT(Internet of Things)やM2M、機器の制御の自動化などの進展により人工物から収集されるデータも爆発的に増大している。

また、人工知能(AI)の構築・運用手法として、膨大なデータから規則性やルールなどを見出し、予測や推論、分類、人間の作業の自動化などを行う機械学習(ML：Machine Learning)、中でも、多階層のニューラルネットワークで機械学習を行う深層学習(ディープラーニング)と呼ばれる手法が台頭している。

このような背景から、膨大なデータを的確、効率的に扱う技術上の要請はますます高まっており、統計やデータ分析、大容量データを扱う手法やアルゴリズムなどに精通した「データサイエンティスト」(data scientist)と呼ばれる専門職の育成が急務とされている。

既存顧客や見込顧客のそれぞれについて、営業活動に関連する情報を記録・管理することができ、過去の商談の履歴や、現在進行中の案件の進捗状況、営業活動を通じて入手した重要な情報、アポイントメントや期限といったスケジュールなどを一覧したり編集することができる。

営業支援システムをチームで利用することによりチーム内で常に最新の状況を共有することができ、属人性を排して組織として効率的に営業業務を進めることができる。

既存顧客との関係を管理する情報システムやソフトウェアをCRM(Customer Relationship Management)というが、多くの企業では既存顧客への営業も重要な営業活動であるため、CRMが営業支援システムの機能を取り込んだり、営業支援システムにCRMとしての機能が追加される事例が増えており、両者の融合が進みつつある。

コンタクト管理 (contact management)

顧客の要望や取引相手との交渉内容などを整理し、データベース化して管理することをコンタクト管理(contact management)という。顧客ごとに詳細な情報を持つことで、それぞれに応じた最適のサービスを提供することを目的とする。

営業担当者の間では以前から個人レベルで行われていたことだが、これを一元的に管理して社内で共有することで、後のサポートや新製品のセールス、マーケティング分析などに応用することが可能になる。SFAの重要な一環として様々な企業で整備が進められており、専用のソフトウェアも販売されている。

チームセリング (team selling)

営業担当者が個々に営業活動を行うのではなく、営業部門全体として戦略的に活動を行うことをチームセリングという。グループ単位で一つの企業に売り込みをかける、などの行動を指す。

個々人の受注成績ではなく、営業部門全体の生産性を上げようという考え方に基づいた行動であり、顧客を企業全体の資産とする観点が背景にある。実現のために必要な要素として、スキルや情報を共有することによる営業プロセスの標準化や、営業活動の経過や結果の共有が挙げられる。SFAの一環と言うことができ、それを援助するソフトウェアも開発されている。

同じ施設の複数のサーバなどに、あるいは、地理的に離れた施設に設置されたサーバなどにレプリケーション機能などでデータを分散して管理する。データの転送や複製は利用者やアプリケーションからは透過的に行われ、どのサーバに接続しても単一のデータベースであるかのように振る舞う。

複数のコンピュータでデータ管理を行うことで、可用性を高めることができる。一部の機器が停止しても他の機器を用いて外部に対するサービス提供を継続することができ、装置の故障などでデータを喪失する危険も減少する。

また、データの読み出しは複数のシステムで並列に行うことができるため、台数を増やせば全体としての性能を向上させることができる。世界的に利用されるサービスでは、データを地理的に分散させることで利用者や端末に近い場所からサービスを提供することができ、通信遅延の低減や回線資源の節約に繋がる。

一方、分散システム一般の性質として、CAP定理により一貫性(Consistency)、可用性(Availability)、分断耐性(Partition-tolerance)の3つのうちいずれか2つしか同時に確保することができないため、厳密な整合性が求められるような処理には向いていない。また、システム構成が複雑になれば、その分だけ管理・運用にかかるコストや手間、セキュリティ上の懸念は増大する。

複製元のデータが追加、更新、削除などされると、リアルタイムに複製先(レプリカ)に伝達され、同じ変更が加えられる。ネットワークやコンピュータへの負荷は高いが、複数のサーバなどの間で常に同様の記憶内容が維持される。最小の構成では現用系(マスター)と待機系(スレーブ)の2系統の同期が行われるが、複数の待機系へ同時に同期して信頼性を高める場合や、現用系が複数ありそれぞれに加えられた変更を互いに通知し合って同期する構成(マルチマスター)もある。

複製元と複製先のソフトウェア環境やサービス、機能は同等になるよう設定されており、複製元が障害などで停止すると複製先が即座に代用として利用できるようになる。複製元が復帰すると停止中に加えられた変更が自動的に反映される。この切り替えはデータの利用側からは分からないように行われるよう制御されることが多い。

レプリケーション機能はデータベース管理システム(DBMS)やクラスタリングソフトなどに搭載されており、DBMSの場合は管理下のデータベースが、クラスタの場合はストレージ全体(あるいは指定された重要な一部分)が複製の対象となる。

バックアップとの違い

バックアップもデータの複製を取るという意味では同じだが、通常は複製されるのはデータのみで複製先のシステムが複製元の代用として機能することはできず、リアルタイムに内容を同期するという運用も一般的ではない。

ただし、ある瞬間の状態を記録したスナップショットを作成したり、過去の様々な時点における複製を作成する世代管理によって特定の時点に遡れるようにするのはレプリケーションにはない機能であり、操作ミスや改竄などでデータが破損した場合に復旧するにはバックアップが必要となる(レプリケーションではデータの破壊も伝播してしまう)。

トランザクション処理では、振り込みにおける出金と入金のように一体不可分な連続した処理を、すべて成功かすべて失敗(途中の処理が失敗したら実行済みの処理を取り消して開始前の状態に戻す)のどちらかに制御する。

分散トランザクションでは複数の独立した処理主体が一連の処理を分担して実行するため、通常のコミット処理によって結果を確定させることができない。このような場合に、準備と確定の2段階に分けてコミットを実施する方式を2相コミットメントという。

トランザクションの制御を司るコーディネータはまず、処理を実行して結果を返すよう参加者に通知する。各参加者はトランザクションを構成する処理を実行し、成功したら「コミット可能」の応答を返す。すべての参加者から成功の通知を受け取ったら、コーディネータはコミットを確定するよう参加者に通知する。これを受けてすべての参加者がコミットを実行することにより、トランザクション全体のコミットが完了する。

準備段階で処理に失敗した参加者がいた場合、コーディネータはトランザクションの失敗を全参加者に伝え、行った処理を取り消して巻き戻すロールバック処理を行うよう促す。参加者がコミット可能な状態で待っている際にコーディネータが故障などで停止すると、コミットもロールバックもできないまま放置されてしまうという問題がある。

例えば、文書データであればタイトルや著者名、作成日などが、楽曲を収めた音声データであれば曲名や収録媒体、作曲家、作詞家、実演家、発表(発売)日時などが考えられる。どのような属性がメタデータとして適切あるいは必要かはデータの種類によって異なり、また、データの作成方法、利用目的などによっても異なる。

文書や画像、音声、動画など多くのファイル形式では、ファイルの先頭などにメタデータを格納する領域が用意されており、あらかじめ決められた形式で、データと一緒にメタデータを保管できるようになっている。ファイル自体もまた、ファイルシステムによって作成者、作成日時、最終更新日時、アクセス権などのメタデータと共に管理されている。

複雑なシステムを大人数で開発したり、長期間に渡って修正・機能追加などを重ねていくと、すでに存在するデータ項目に気づかずに、同じものを微妙に異なる名称で重複して登録してしまったり、違う種類のデータなのに気づかずに同じ名称を与えてしまったりすることがある。

データディクショナリはこうした事態を避けるため、システム全体で扱うデータをすべて定義して列挙し、開発チーム全体で共有する。小規模な場合は文書ファイルなどの形で作成することもあるが、大規模な場合はこれ自体を一つのデータベースにしたり、専用のデータ管理システムを用いたりする。

DBMSのデータディクショナリ

データベース管理システム(DBMS)によっては、あるデータベースの定義や管理に関連するデータを格納するために作られたデータベースをデータディクショナリということがある。

通常のデータベースと同じくテーブル(表)やビューなどで構成され、内部には管理対象のデータベースのテーブルやビュー、インデックス、スキーマ、制約、ユーザーや権限などに関する情報があらかじめ決められた構成で記録される。

IT分野では、ソフトウェア開発などに用いるバージョン管理システムやプロジェクト管理システムなどで、プロジェクトを構成するプログラムのソースコードやドキュメント、関連する各種のデータやファイルなどを一元的に管理する格納場所のことをリポジトリという。

特に、データそのものに加えて、版数(バージョン番号)や最終更新日時、更新履歴など「データについてのデータ」(メタデータ)を記録・管理し、複数人が共同で編集作業を行ってもデータを矛盾なく管理・共有できる仕組みを備えたシステムや保管場所のことを指すことが多い。

リポジトリを用いてデータを管理することで、同じデータの過去の特定時点の版を取り寄せたり、最新版と以前の版の違い(差分)を求めたり、新しい版を破棄して過去の版に差し戻すといった操作が容易になる。多人数での共同のプログラミングなどでは必須の管理方式となっている。

バージョン管理システムとリポジトリ

バージョン管理システム(VCS)の場合、CVSやSubversionなどの集中型システムでは単一の「中央リポジトリ」(central repository)に各利用者が接続して操作するが、GitやMercurialなどの分散型システムでは中央リポジトリの内容を各利用者の手元に複製した「ローカルリポジトリ」(local repository)に対して操作を行う。

オープンソースソフトウェアの開発に用いられるリポジトリなど、誰でも自由にアクセスできるようインターネット上で公開されているリポジトリを「パブリックリポジトリ」(public repository)、企業内のシステム開発など関係者のみがアクセス可能なものを「プライベートリポジトリ」(private repository)という。ネット上にはVCSの中央リポジトリの運用環境を貸与するGitHubなどのホスティングサービスもある。

システム管理ソフトなどのリポジトリ

機器やソフトウェア、システムなどを管理・操作するためのソフトウェアなどで、管理対象の設定や状態、属性に関するデータを一元的にまとめたファイルやデータベースなどのことをリポジトリということがある。特に、多数の対象を管理者が一元的に把握・管理するためのシステムで、データを統一的に扱うために用いられる仕組みを指すことが多い。

リレーショナルデータベースのテーブルやCSVファイルのように、一件のレコードの構成、各項目のデータ型や形式、項目の並び順、項目やレコードの区切り文字などが事前に決まっており、同じ構成のレコードの繰り返しとしてデータを列挙したものを指すことが多い。

ソフトウェアによって容易に読み込んで内容を認識させることができ、大量のデータを集計したり分析するのに適している。人間がそのまま眺めて読みやすい形式とは限らず、ソフトウェアによって抽出や集計を行ったり、見やすいよう整形したり、レポートなど別の形式へ変換してから人間に供されることが多い。

一方、Webページや電子メール等のメッセージ、ワープロソフトやプレゼンテーションソフトなどで作成した(見栄え重視の)文書ファイル、画像や音声、動画などのメディアデータといった、決まった形式や配置に従ってデータが並んでいるわけではない不定形なデータ群のことを「非構造化データ」(unstructured data)という。

Webページの構造化データ

WebページのHTMLコードは、Webブラウザにその文書の構造やレイアウトを伝達するという意味では構造化されているが、書かれている情報をサイト横断的に同じ形式に従って自動収集・処理できるような構造にはなっていない。

そこで、ソフトウェアが自動処理しやすいようページ内に書かれている内容を特定の規約に則って構造化データとして記述する手法が提唱されている。同じ情報を人間向けと機械向けに同じページに埋め込んでおき、ブラウザは人間向けのデータを表示し、Webロボットなどの自動処理プログラムは機械向けのデータを収集する。

様々な手法が提唱されているが、現在有力な方式はHTMLのヘッダ領域などにJSON-LD形式でスクリプトの形で情報を埋め込む手法で、Schema.orgという業界団体が情報の種類ごとにデータの記述形式(スキーマ)の標準を提案している。

例えば、ある行事の開催案内のWebページに、Schema.orgの定義する「Event」(行事)のスキーマで構造化データを埋め込むことで、巡回してきたロボットに行事名や主催、出演者、開催日時などを伝達することができる。

リレーショナルデータベース(RDB)やCSVファイルのようにあらかじめ決められた構造に当てはめてデータを記録する「構造化データ」(structured data)と、文書ファイルなど決まった構造を持たない雑多なデータの集まりである「非構造化データ」(unstructured data)の中間の形式である。

半構造化データはRDBに対するSQLによる操作のように特定のデータモデルに従ってデータを自動処理することは難しいが、区切り文字やリテラル、タグなどの一定の記法に従って記録されており、データを読み込んでソフトウェア上のデータ構造に対応付けることはできる。

半構造化データの格納形式としては、HTMLに似たマークアップ言語であるXMLで記述されたXMLファイル、JavaScriptのオブジェクト定義構文をデータ記述に応用したJSONファイルなどがある。データベース管理システムで管理する場合はKVS(Key-Value Store)などのいわゆるNoSQL型のシステムを用いる。

コンピュータが扱うデータの多くは何らかの形式や構造に従って記録されているものが大半だが、非構造化データといった場合はリレーショナルデータベース(RDB)の表(テーブル)のように構成要素を分割、配列した構造を持たず、コンピュータプログラムによって要素を個別に把握して処理するような利用方法が難しいようなものを指す。

よく挙げられる例として、(人間が閲覧するための)Webページ、電子メールやメッセンジャーなどのメッセージ、ワープロソフトやプレゼンテーションソフトなどで作成した(見栄え重視の)文書ファイル、画像や音声、動画などのメディアデータなどがある。

これらのデータはそれぞれ特定のデータ形式で記録されてはいるものの、主に人間が見聞きするために視聴覚的な構成を整えることを主眼に作成・編集されており、内部の構成要素をプログラムが自動認識できるような形になっていない。データベースのような検索性や再利用性は乏しく、情報として後から活用することが難しい。

一方、データベースのテーブルやCSVファイルのように、一件のレコードの構成、各項目のデータ型や形式、項目の並び順、項目やレコードの区切り文字などが事前に決まっており、同じ構成のレコードの繰り返しとしてデータを列挙したものを「構造化データ」(structured data)という。

これまでデータ解析のために管理されるデータの置き場としてデータウェアハウスなどが用いられてきたが、これは業務システムなどがリレーショナルデータベース(RDB)のテーブルなどの形で定型的に整然と記録した構造化データに限られる傾向があった。

データレイクではこうしたデータ源だけに限らず、人間の作成した文書ファイル群や外部から収集したオープンデータ、Webサイトのログデータ、ソーシャルメディアの書き込み、IoTデバイスが記録したデータなど、様々な種類のデータを単一のシステムで管理する。

事前に決められた特定の構造や形式へのデータの変換や整形は不要で、非構造化データもそのままの形で格納することができる。分析などで後で実際に読み出す際に必要な前処理が行われる(スキーマオンリード)。データの記録には安価なストレージ装置を用い、コストに縛られずにとにかく大量のデータを収集、保管することを主眼とする。

集めたデータはビッグデータ解析システムや全文検索システム、機械学習システムなどを用いて事業や業務に有用な洞察や知見、予測などを得るために活用される。

どんなデータも蓄積できるといっても、高度な活用のためにはどこに何がどのように記録されているかといったメタデータが適切に付与され、データカタログなどの形で整理されている必要がある。野放図にデータを記録した結果、データの意味や所在が不明になってしまった混沌とした状態は「データスワンプ」(swamp：沼)と呼ばれる。