ここでは、データベースの概要を学習します。いくつかの事柄の詳細はリンク先にあります。
データベース、ＤＢＭＳ、プログラムからの独立，冗長性の排除，データ管理の容易化、排他制御，２相コミットメント，ＡＣＩＤ特性、スキーマ、インデックス
データベースとは、広義には「データの集合体」であり、通常のファイルもデータベースですし、「仕事紹介データベース」のような商用データベースもあります。しかしここでは、「データを整理・統合して格納し、そのデータを検索・活用しやすくするための技術、および、それにより管理されたデータの集合体」であるとします。
さらに、一般企業での業務システムで活用される分野でのデータベースを対象にします。
これらのデータベースは、ＤＢＭＳ（Database Management System、データ管理システム）というソフトウェアによって管理されています。いいかえれば、ここでのデータベースとは、ＤＢＭＳにより管理されるデータの集合体だといえます。
通常のファイルからデータベースへ発展する考え方については、「ファイルの概念」と「マスタファイルとイベントファイル」にあります。なお、一般のファイルのデータ形式については、「ファイル編成」にあります。
現在、最もポピュラなデータベースは、ＲＤＢ（Relational Database、リレーショナルデータベース、関係データベース）といいます。また、これによるデータベースの形式を関係モデルといいます。このシリーズでは、特に断らない限り、データベースといえばこれを指しています。
ＲＤＢ以外のデータベースを列挙します。詳細は「データベースの種類」にあります。
通常のファイルは下図のような形式になっています。ファイルに入っているものはデータだけであり，「月日」や「得意先コード」などの項目名はファイルには含まれていません。さらに，物理的にはファイルの中では，項目間の区切りやレコードとレコードの間の区切りもありません。しかも，実際にはバイナリ表示になっているので，これよりさらに複雑になっています（図示）。
1001500コダマ電器101目立テレビ10テレビ10401001500コダマ電器205ＨＡＬパソコン20パソコン202001001500コダマ電器326松川ケータイ30ケータイ10101004600リラックス213ＭＤＢパソコン20パソコン30180・・・・
それで，プログラムでどこからどこまでを何という項目名で取扱うのかを定義する必要があります。すなわち、プログラマは利用するファイルの詳細を知る必要があったのです（ＣＯＢＯＬでのファイル定義例）。
下はＣＯＢＯＬ言語でのファイル定義文ですが，プログラマは個々のプログラムでこのような定義をしなければならなかったのです。
FD 売上ファイル.
01 売上レコード.
02 月日 PICTURE 9(4).
02 得意先コード PICTURE 9(3).
02 得意先名 PICTURE N(5).
02 商品コード PICTURE 9(3).
02 商品名 PICTURE N(7).
02 商品区分コード PICTURE 9(2).
02 商品区分名 PICTURE N(4).
02 個数 PICTURE S9(3) COMPUTATIONAL.
02 金額 PICTURE S9(9) COMPUTATIONAL.
それに対して、データベースをアクセスするにはＳＱＬ言語が用いられますが，それでは下図のような記述ができます。
ＳＥＬＥＣＴ 得意先名，商品名，個数
ＦＲＯＭ 売上テーブル
ＷＨＥＲＥ 月日＝"1001"；
ここでは，「得意先名」や「商品名」「数量」などの項目名はＤＢＭＳ（データベース管理システム）で定義されているので，プログラマはファイルデザインを知る必要はないのです。
通常のファイルでは、個々のプログラムでファイルデザインを定義しているので、ファイルに新規の項目が追加された、既存項目の桁数が変更になったなど、ファイルデザインが変化したら、そのファイルを用いているプログラムをすべて変更しなければなりません。
それに対して、個々のプログラムでは，そこで必要とする項目名だけを使っているのですから，後になってファイルデザインが変更になっても，プログラムを修正する必要はありません。すなわち，データベースでのデータをプログラムから独立して管理できるのです。
これは，データを部品と考えることでもあります。すなわち，データベースとはデータを部品として再利用することを目的としているともいえます。
データベースにするにあたり，データの正規化をすることが必要になります。正規化すると，一つの項目は一つの場所にしか存在しなくなるので，全体としてのデータ量が少なくなり，ディスクなどの記憶装置のコストを少なくすることができます。
それだけでなく，一つの項目は一つの場所にしか存在しないことは，データの管理を容易にします。たとえば，得意先名が多くのファイルに存在するとき，その名称が変更になったとしたら，どのファイルに該当する得意先があるのかを調べて，それを間違いなく修正しなければならなりません。これは大変な作業になるし，修正もれを完全になくすことは困難です。それに対して，正規化されていれば，得意先名は得意先マスタテーブルにしか存在しないので，一つのテーブルを修正するだけで，すべてのシステムについて，間違いなく修正できたことになります。
データベースを管理するシステムをＤＢＭＳといいます。ＤＢＭＳは次のような機能をもっています。ここでは、」後に出てくる用語を説明なしに使っています。
更新処理では、複数の処理が一つのセットになっていることがよくあります。例えば「倉庫Ａから倉庫Ｂに商品を１０個送る」という処理は、「倉庫Ａの在庫を１０個減らす」ことと「倉庫Ｂの在庫を１０個増やす」処理の両方を実行する必要があり、一方だけを実行したのでは困ります。
この処理を実行できるのは、「倉庫Ａに１０個以上の在庫があり」「倉庫Ｂに１０個を受け入れるスペースがある」ことが条件になります。倉庫Ａの在庫減の処理をした後で倉庫Ｂのスペースがないとわかったら倉庫Ａの処理をキャンセルする必要があります。このような確認をして実行することを２相コミットメントといいます。
信頼性のあるトランザクションシステムが持つべき特性をＡＣＩＤ特性といいます。
２相コミットメント、排他制御、バックアップとリカバリーなどは、ＡＣＩＤ特性を実現する機能だといえます。
Atomicity：原子性（不可分性）
Consistency：一貫性
Isolation：独立性（隔離性）
Durability：耐久性（永続性）
通常のファイルでもファイル管理システムにより、利用者に対して、ファイルの読出し書込みなどのアクセス権を設定できますが、データベースでは、表単位だけでなく、行単位や列単位など細かいレベル（粒度）での設定もできます。
しかし、あまりにも煩雑なので、通常は表単位で設定します。行や列で指定するには、アクセスできる部分だけを抽出したビュー（仮想テーブル）を作り、利用者には本体のテーブルは見せずビューだけを示すこともできます。
アクセス権の設定は、利用者のＩＤやパスワードを用いる方法と、データベース側にパスワードを設定しておき、アクセスされたときにパスワードを要求する方法があります。後者の場合。毎回多くのデータベースについてパスワードを入力するのは煩雑などで、アプリケーションの開始時に入力させ、それでこのアプリケーションで用いる全データベースにアクセスできるようにするのが通常です。
オンラインシステムでは、同時に同じデータを更新することがあります。例えば、入出荷システムで、ある商品の在庫が１００個だったとき、Ａが５０個の入荷を入力した直後に、Ｂが１２０個の出荷を入力したとします。この順序で処理されればよいのですが、Ａの処理に時間がかかっている間にＢの処理が行われると在庫不足でエラーになってしまいます。このような状況を同時更新といい、Ａの処理が完了するまでＢの処理を待たせるような工夫を排他制御といいます。
同時更新と排他制御の現象については、「排他制御」、タスク管理からの技術面では「排他制御」で詳述しています。
通常の事務処理では、データの更新や照合など、データをあるキーで検索する処理が多発します。その処理を効率化するためには、データにインデックスという検索用の索引をつけておくことがあります。通常のファイルでも乱編成ファイルや索引つきファイルなどがありますが、データベースではＤＢＭＳがインデックスを管理しており、項目ごとに多様なインデックスがつけられるようになっています。
万一のトラブルによりデータの整合性を失ったとき，データベースを回復する機能があります。データベースを更新するとき，更新件数や時間などによりチェックポイントを設定しておき，チェックポイントになると，次のチェックポイントに達するまで，更新前と更新後の情報をログというファイルに記録しておき、チェックポイント間でトラブルが発生したときは，ログファイルを用いてデータベースの内容を直前のチェックポイントの状態に回復するのです。
→詳細：「バックアップとリカバリー」
スキーマ（schema）とは、データベースの構造やデータの格納形式（これらをメタデータといいます）を定義したものです。ＤＢＭＳ管理下にスキーマデータベースとして保管されます。データベースを定義するということは，すなわちスキーマを定義することです。
例えば、利用者はＳＱＬのＳＥＬＥＣＴ文で、
SELECT 商品名, 数量 FROM 売上テーブル;
とするだけで結果が得られます。
売上テーブルがどこに保管してあるのか、商品名や数量が売上テーブル内のどこに、どのような形式で記録されているかは、スキーマに登録してあり、ＤＢＭＳがスキーマの内容をＳＱＬに教えるからです。
スキーマは、抽象化のレベルにより、次の３階層があります。
データディクショナリとリポジトリはほぼ同義語です。これらは、データについて項目名や形式、所在、属性などを登録して厳密に規定したもので、スキーマと似たものです。 これらは、スキーマを作成する過程の中間物、あるいはスキーマを補完するものだと理解することができます。
ＲＤＢをＳＱＬで処理する場合、処理効率を向上するための工夫をパフォーマンス・チューニングといいます。前述のインデックスを付けることもその一つです。