†COBOLでデータファイルに直接アクセスしていた。このときのデータベースはディスク上に記録された単なるファイルだったのである。これはCOBOLに限らず、汎用機やそこから派生したオフコンのOSでは普通のことであった。これらのOSは、ディスクに記録するファイルには順編成ファイルと索引順編成ファイルの2種類があった。順編成ファイルと索引順編成ファイルのどちらもデータ1件分のバイトすうと総件数を決めて、その領域を確保してから利用するという方式であった。ユーザから見れば、現在のRDBMSでいうテーブルとほとんど同じものである。†データベースを構築するには、対象となる実世界の複雑な情報とそれに対応する操作を規定する枠組みが必要である。この枠組みをデータモデルと呼ぶ。データモデルを作成する目的は次のようにまとめられる。データとその構造を記述する上での規約を与える。規約に基づいて表現されたデータについて、その操作体系を規定する。実世界の情報を正しく表すための、意味上の制約を表現する上での枠組みを与える。データモデルの主要な役割は次の2つに要約される。データベース管理システム(DBMS)を管理するためのソフトウェアとユーザーとのインタフェース物理的なデータ格納形態やデータの検索手順などとは独立している。論理レベルのデータ記述と操作を可能とする。したがって、ユーザーは物理レベルの内容を知らなくてもデータベースを利用することができる。実世界のモデル化ツール対象世界の情報構造を反映したデータの構造や意味をできるだけ自然に表現するための枠組みを与える。†データベースについて考える場合、最も問題になるのが現実世界のデータをどのようにコンピュータ内部で表現するかという、データモデルの作成に関することである。データのモデル化については、1978年にANSIが3階層のデータモデルを提唱し、現在最も広く受け入れられている。概念モデル現実世界全体のデータをコンピュータやプログラムは意識せずに、データ同士の相互関係などの論理的な構造を定義したもの。ひとつの概念モデルがひとつのデータベースに対応する。概念モデルの図式的表現方法として、E-R図などがある。外部モデル(論理モデル)ユーザー(プログラム)の立場から必要なデータをあげ、データベースを利用者(プログラム)ごとに定義したものである。外部も出るには、階層モデル・ネットワークモデル・関係モデルがある。内部モデル(物理モデル)概念モデルで定義されたデータベースを、コンピュータ上でどのように実現するか(物理的な格納方法やアクセス方式など)を定義したもの。†データベースが完成した後でも、データベース中のデータの構造や意味や意味を理解するためには、DBMSの制約を受けない自然な表現が必要である。そのためには、一般にデータモデリングは少なくとも2つの段階を経て行われる。1:概念モデルの作成まず、DBMSが提供するデータモデルとは独立に構築される対象データが、どのようなものかを表現する。この結果得られるモデルを概念モデルという。概念モデルを、DBMSが提供するデータモデルに変換する。この変換されたモデルを論理モデルという。これは後述する3層スキーマの概念スキーマに対応する。System)に採用されたデータモデルである。階層データモデルにしたがって集積されたデータの集合を階層データベースという。階層モデルは次の3つの要素で構成される。根(root:ルート)最上位レベルのデータ。原則としてデータの探索は根から行われる。節(node:ノード)中位レベルのデータ。葉(leaf:リーフ)末端のデータ。葉より下位のレベルのデータは存在しない。データは、枝(branch:ブランチ)と呼ばれるポインタによって接続されており、根と節、節と葉は親子の関係になる。親は複数の子を持つことが出来るが、子は複数の親を持つことができない。これを親子関係と呼ぶ。したがって、あるデータに達する経路(パス)はひとつしか存在しない。階層データモデルの特徴は次の通りである。階層データモデルを表現する場合、バックマン線図が用いられる。網状の構造を持つ対象を表現するときに階層データモデルだと、冗長な表現になってしまう。Store)に採用されたデータモデルである。ネットワークデータモデルにしたがって集積されたデータの集合をネットワークデータベースという。階層データモデル同様に、データを木構造で表現するが、子が複数の親を持つことができる。関係データモデルとは、1970年にIBM社のコッド(E.F.Codd)によって提案されたデータモデルである。関係データモデルにしたがって集積されたデータの集合を関係データベースという。行(レコード)と列(フィールド)で構成されている表なので、Excelの画面をイメージするとよいだろう。現在利用されているデータベースの主流となっている。†データのモデル化の一種である。スキーマとは、データベースの記述という意味である。データベースシステムの基本構造を次の3つに階層化している。外部スキーマデータベースを利用するプログラムの立場からデータベースを定義する。概念スキーマで定義されたデータ構造の一部分として考える。概念スキーマデータを処理する上で、コンピュータシステムに必要な現実世界全体のデータを論理的に定義する。ひとつのデータベースにひとつの概念スキーマが対応する。内部スキーマ概念スキーまで定義されたデータベースを、物理的に補助記憶装置上にどのように格納するかを定義する。ひとつの概念スキーマにひとつの内部スキーマが対応する。処理効率を考慮するので、記憶媒体にどのように格納するかということはこの部分が担当する。このようにデータの論理的関係を示すスキーマと、ユーザーが欲するデータの見方を示すスキーマを用意することで、論理データの独立性を実現している。データモデルを利用すると、データの物理的な機能方法の違いに左右されることなく、論理的なレベルでのデータ記述ができるようになる。3層スキーマに切り分けることができる(各層は独立性を持つ)。System:データベース管理システム)とは、ユーザー(プログラム)とデータベースの間に位置し、データベースを管理するためのソフトウェアのことである。・データベースを使用する目的のひとつに、データのプログラムからの独立がアル。これを実現しているのが3層スキーまである。データ独立には、物理データ独立と論理データ独立がある。内部データの構造変更や磁気ディスク装置の変更など、データの物理的な変化に影響されない特性のこと。この場合、内部スキーマと概念スキーマを修正するだけで、プログラムを修正する必要はない。他の業務プログラムを変更しても、論理的に関連の無いデータは影響を受けないという特性のこと。この場合、外部スキーマと概念スキーマを修正するだけで、データそのものを修正する必要はない。・データベースシステムでは、プログラムが直接データをアクセスすることはなく、全ての操作がDBMSを介して行われる。例:関係データベースではSQL文の実行により、データにアクセスする。・データベースシステムでは、複数のユーザーからのアクセスに対して、その可否を含め応答しなければならない。そのため対応が複雑であり、生涯の発生時にはその影響が複数のユーザーに及ぶため、速やかに復旧させなければならない。†データをアプリケーションと分離して管理できる。多目的にデータを利用できる。データの重複や矛盾が起こらないようにできる。データに意味を付け加え、他のデータとの関連を把握しやすくなる。†DBMSの機能の中で、データベース定義機能とデータベース操作機能はデータベースの利用者である応用プログラムにデータやスキーマをアクセスさせるための基本機能である。DBMSには、それ以外にも次のような機能が要求される。適正な処理効率を維持するための機能これらの機能を実現するために、次のような機能がある。トランザクション管理データベースの参照や更新処理を含む、ユーザーから見たひとまとまりの処理単位をトランザクションと呼ぶ。データベースの更新は常にトランザクション単位で管理される。トランザクション処理が正常に完了すれば、入出庫が正常に完了すれば、入出庫処理は正常に処理されたことになるので更新を確定する。トランザクション処理が途中で以上終了すれば、正常に処理されたことにならないので、トランザクション処理の開始前の状態に戻す。更新を確定することをコミット処理と呼び、元に戻すことをロールバック処理という。外部スキーマのことを特にビューとも呼ぶ。ビューは概念スキーマからその一部を抽出した者である。関係データベースでは、ビューはSQL文で定義される。表は実在表であり補助記憶装置上に格納されるが、ビューはSQL文の実行により実在表からその都度生成される仮想的な表であり実体はない。一般には、結合演算などにより生成されるビューは更新不可能である。・データ構造がリレーショナルタイプであるデータベースである。データ構造がテーブルで構成されているデータベースである。そのため、関係データベースと呼ばれる。・コンピュータの専門的な知識を必要としないため、現在のパソコン用データベースソフトにはほとんどこのRDBが採用されている。データ操作などが論理的に体系化されている。・また、その構造は、文字列、数値をデータの最小単位とする単なる2次元の表の集まりなので、非常に単純でわかりやすい。・さらに、データ操作はパスをたどっていくような操作ではなく、関係代数による宣言的な操作に基づくため、高水準データ制御言語を提供できる。・現在使われているデータベース管理システムはリレーショナルデータベースを採用しているものが多く、なぜ、リレーショナルデータベースが人気かというと、すべて2次元でのリレーション(表)で表現できるという直感的に理解できるモデルだからだといえる。・関係データベースが文字データや数値データを扱っているのに対して、マルチメディアデータなどの複雑なデータを効率よく処理することを可能にしているのがこのオブジェクト指向データベース(OODB)である。・データとその処理手続きを一体化(カプセル化)したものをオブジェクトと呼ぶが、OODBではこのオブジェクトを磁気ディスク装置上に記録し、管理する。・処理手続きには、検索・更新などの基本操作のほかに、データの整合性機能や障害回復機能も含まれ、オブジェクトの独立性を高めている。・よって、応用プログラムはオブジェクトを組合わせて使用することができる。・また、ユーザーはあらかじめ決められた形式のメッセージを送ることによって、処理要求を行う。・オブジェクトリレーショナルデータベース(ORDB)は、RDBのデータモデルやデータ操作法を引き継ぎ、オブジェクト指向の機能を追加したデータベースである。・RDBで扱える数値と文字列のほかに、抽象化されたデータに対応している。・ネットワークデータベースのこと。・NDBの利用には、コンピュータの専門的な知識を必要とし、主に定型業務などの基幹システムで用いられている。・階層データベースに比べて複数の親の存在が許されるため、上下関係の階層だけでなくサイクル(閉路)やループ(自分を自分の親とする)構造を設定でき、柔軟な構造を取ることが可能である。・しかし、処理経路を越えたアクセスが効率的に行えないという問題がある。・文字や数値に加えて画像、音声などのマルチメディアデータを扱うことができる。・ユーザーに対してメディアのデータ構造を意識させることなく、統一させたユーザーインタフェースを提供するために、オブジェクト指向のアプローチを取ることが多い。・複雑で巨大なデータ構造が扱える。DBMS自身がデータ構造を定義し、その構造に沿って検索や部分変更が行える。・データの時間的な操作・検索に対応できる。・従来の構造型データベースや関係データベースでは表現できない複雑なデータ構造を処理することができる。†データベースは多くのデータ(情報)を集めて整理し、必要に応じてデータを検索できるようにしたシステムである。図書館に行くと図書カードやコンピュータを利用して、読みたい本を探し出すことできる。このようなコンピュータ以外のところでデータベースは利用されているが、さらにこのデータがどのように相互に結びついているかという点が重要である。データベースの構造にはデータモデルと呼ばれるいろいろなタイプのモデルがある。データベース格納方法には次の4タイプがある。ファイルタイプノートや台帳など紙で記録していたものをコンピュータのファイルにしたもの。ファイルを自分だけで利用しているのであれば必要ないことだが、他の人もそれをみえるようにするにはファイル共有という形を取ることになる。ファイル共有では、ファイルを作った人に訊かないとそのファイルのデータを活用できない。した寄せ集めでは、一元管理はできない。階層タイプデータを親子の関係で管理していこうというデータベースの初期の形態。データがファイルシステムのディレクトリ構造になっているタイプ。ファイルタイプとの根本的な違いは、統一した構造でデータを管理しようという目的意識で考えられるものである。階層タイプからデータベースと呼べるものになってきたわけだ。階層タイプは親子関係だけを管理するものであるが、親子の関係を表す手法として、親データが格納されている(ディスク上の)位置と子が格納されている(ディスク上の)位置を芋づる式に繋いでいく方法を採用している(これを物理ポインタあるいはチェーンという)。この方法だと、ディスクが故障して別のディスクに入れ直したりするとデータの格納位置を変わってしまう。親が2つ以上あると、親ごとに子のデータを重複させて持たなければならなくなり、冗長な構造になる。ネットワークタイプ階層タイプの論理的な欠点を改善したタイプ。各レコード間の関連付けが網目状になっているタイプ。階層タイプと同じくポイントを使う。子のデータを重複して持たずに、実の親と義理の親データから子データに対してそれぞれポインタで繋ぐことによって、ひとつの子データが2つの親データに属している状態を作り出している。ポインタを使っているということは、階層タイプの物理的な構造面での問題点をそのまま引きずってしまっているので、根本的な解決になっていない。リレーショナルタイプリレーションと呼ばれるテーブル(表)とテーブルの関連性を基本としてデータを管理するタイプ。関連付けは主キーと外部キーを使っている。データの格納位置が変わってもデータ間の関係には影響しないという利点がある。†DBにはいくつかのタイプがあることはすでに述べた。それらのタイプには根幹部分にデータモデルという捉え方があり、それに基づいて開発されている。各モデルが一件異なるモデルであるかのように見えるが、原理は同じで、抽象化のレベルの差が本質的な違いであるのだ。作られたデータ構造を基にして物理的なデータの配置などを定義する。各工程の設計結果を、次のように考えればよい。実現手法別にデータモデルを整理すると、次のような4つに分類できる。†システムを実際に構築するときのスタイル(型)として、2階層型・3階層型がある。・クライアントとサーバーの構成をいう。・DBはサーバー上に構築され、業務処理プログラムはクライアント上に構築され、ネットワークを介してクライアントからサーバー上のDBにアクセスする。・DBがサーバー上でアプリケーションプログラムがクライアント上に配置されるので、同じプログラムをクライアントマシンすべてにインストールすることになる。プログラムの変更があった場合、すべてのクライアントにプログラムを入れなおさなければならない。よって、メンテナンスが非常に大変。・データの階層と処理ロジックの階層を分けたところまではよいが、処理ロジックの共通化ができないの欠点。処理ロジックはユーザーごとに異なるものもあれば、共通のものもある。共通ロジックは冗長に配置するなく一元管理できれば理想的だろう。・2階層型の欠点を改善した形態。・2階層ではクライアントに冗長にインストールされていたプログラムがあったが、ユーザーが共通に活用できる処理ロジックを別のサーバーで管理して、ユーザーごとに異なる処理をクライアントにインストールするという形態になる。・このような3つの階層は一般的に次のように呼ぶ。・3階層型を採用した例として、Webサイトの構築がある。大型のWebサイトは、Webサーバー、APサーバー、DBサーバーと呼ばれる3つのサーバーで構成される。†クエリは、データ分析やデータの一括更新などの作業を行う。レコードやフォームなどの他のオブジェクトに比べて少々難しいが、データベース運用には欠かせないものなのでしっかり理解しておいて欲しい。クエリ自体は、テーブルと異なりデータが実体を持たないので、ちょっと抽象的である。クエリ自身は、テーブルなどからデータの抽出などを行う作業書のようなもので、表示されたデータは、基データからの借り物といえる。この借り物のデータを閲覧、またはまとめて更新などを行うのにクエリを使用する。選択クエリ最も基本的なクエリ。テーブルのデータを抽出して表示する機能を持つ。抽出の際に並べ替えや演算を行うことができる。表示されたデータへの変更は、演算フィールドなどの例外を除き、基のレコードに反映される。パラメータクエリ:実行ごとに抽出条件を入力する。クロス集計クエリ:データ分析に用いる。クションクエリ実行時に多数のレコードデータの改変を行うクエリ。更新クエリ:データをまとめて更新する。削除クエリ:条件に合致したレコードを削除する。†リレーショナルタイプは多くのテーブルで構成されている。求めるテーブルを指定するために、テーブルの名前が必要である。これをテーブル名という。テーブルは同じ構造を持つタプル(行)から構成されている。逆にいえば幾つかのタプルが集まってテーブルを構成していることになる。タプルは一意的に指定可能ではなる。一意的に指定できなければ、情報検索の際混乱してしまう。この一意性こそが本質といっても過言ではない。このタプルは項目から構成されている。この項目の中にリレーショナルデータベースで扱うデータが収められる。この項目にも名前が必要で、これを項目名と呼ぶ。ちなみに、列はカラムと呼ぶ。この項目には型を持つ。よって、同一の項目は同一の型を持つ。情報の種類によってこの型は変わる。テーブル作成時には型の定義も行う必要があるわけである。†テーブル定義は後で簡単に変更できない。テーブル定義を変更してしまうと、大抵の場合アプリケーションに手を入れる必要になってしまうからである。効率よく整合性を保つために同じデータを複数の箇所で管理しない。同じデータを分散させて管理してしまうと、一部だけ更新して、他のものが更新されなかったりすることが考えられるからである。DBはデータが命であり、常に整合性がある状態を維持する必要がある。データの変動を予測する。運用期間によって、蓄積されるデータの量が変わってくる。データの量が増えることで、DB操作・管理の処理がボトルネックになってしまってはいけない。†ファイルの読み書きすると、ファイル単位でロックがかかり、1人が書き込みしている間はそのファイルに別の人が書き込みすることができない。それに対してデータベースの場合は、1つのテーブルで管理していても行単位などの細かい単位でロックをかけることができる。データベースの方が複数人が同時にデータを操作するときでもぶつかる可能性が少ないのである。†JavaScriptといったクライアントサイドのアプリケーションでもデータベースを扱うことは可能である。データベース更新のたびにデータやり取りが増大して処理速度が低下したり、更新タイミングによってデータベース情報のずれが発生する可能性があり、非効率的である。ゆえに、データベースをWebで利用するにはサーバーサイドのアプリケーションを利用するのが適している。ASP・Javaサーブレット・CGIが当てはまる。†PHPやASPなどはデータベースエンジンを使ってサーバーに保存したデータベースを操作するため、多言語から比べてデータベースの扱いに長けている。このようにデータベースエンジンは大量のデータを効率的に扱うには必須である。データベースエンジンにも様々な種類があるが、それらのデータファイル(データベースファイル)の形式が異なっていて一貫性がないという問題がある。よって、同じ組織内で使う場合は問題ないが、外部との情報をやり取りするときに、大きな問題になる。Language:拡張可能な記述言語)を利用するというアプローチがある。主キーにより行が特定できるということは、その列には必ず異なるデータが入っているため、主キーも制約の一種でる。これを主キー制約という。行を特定するためにはデータが入っていないものいけない。よって、主キーはNULLを取り得ることはない。table時に次の2つの方法で主キー制約を宣言できる。[,...]」と記述する。主キーが1つの列からなるときはどちらの方法でもよいが、2つ以上の列からなる場合には2番目の方法のみとなる。†NULLが入ることを許さないという制約。必要不可欠な情報に対して用いられる。同じ値が入らないという制約。値の範囲を制限する制約。数値関係の時によく使われる。†RDBSでは参照整合性制約に関する色々なルールを設定することができ、きちんと設定すれば自動的にデータの整合性を保つことができる。テーブルが複数あり、テーブル間の列が同じデータを持つ場合、データの整合性を自動的に保つ仕組みを持つ制約。あるWebサービスにユーザー登録した場合、そのユーザーに関する情報は様々なテーブルに登録されることがある。このときユーザーを削除したとき分散されていた情報がすべて削除されることを保障するのがこの制約である。同じデータを管理しているところは基本的に同じ属性名を利用しているので、それを参照しながら、データが一意に特定される方を参照するようにデータベースの内部設計を行う。PostgreSQLの場合は、REFERENCESキーワードをの後に、参照先(モデル図の矢印が指し先)を書けばよい。†テーブルにイベント(INSERT/UPDATE/DELETEから指定可能)が起こった場合に、それに連動したアクションを起こす仕組み。PostgreSQLではPL/pgSQL,C,PL/Perl,PL/Tclなどで定義可能。本の索引と同じように検索を早くするための手段。インデックスとはテーブルのデータ以外に索引データを持つ。そのため、データを挿入・更新すると索引データにも変更が入る。インデックスを導入することで、検索は早くなるが、挿入・更新が遅くなる可能性があるということである。索引データは別に持つため、容量も食う。複数の列を指定する複合インデックスというのもある。PostgreSQLの場合は、主キー制約とUNIQUE制約をつけた列には自動的にインデックスが付く。索引というのはなるべく重複しないデータを持っている場合にあらかじめ並べ替えをした索引を持っていると検索の効率がよいからである。逆に同じようなデータばかりが管理されている列にインデックスを作成することはあまり効果がない。単純に検索条件になっていればインデックスを作成するのではなく、管理されるデータの特性も考慮する必要がある。次の書式で指定できる。(列名);列名に区切りで指定することで、複数の列を合わせて複合インデックスを作成することが可能。メソッドは内部の検索手法のこと。PostgreSQLの場合は、Btree,hash,GiST,GINが指定できる。場合はBtreeを利用するのがよく、指定しない場合はデフォルトでBtreeが選択される。†リレーション中でタプルを特定できる単一の属性もしくは、複数の属性(候補キーという)のこと。選んだ候補キーが意味的に重要であること。NULLが含まれる可能性のある候補キーが含まれないこと。外部キーにおいて参照される列に指定するには、主キーもしくはユニーク制約が付いている必要がある。接続の確立と維持、メッセージ交換を行う。FoundationとTCPなどの間のクッションになる。統合流通情報システム(4588d)。