730 likes | 873 Views
An Overview of Database Management. CHAPTER 1. ~データベース管理の概略~. 遠山研究室 B3 日髙 大輔 2004/02/23. Outline. 1.導入 2.データベースシステムとは何か 3.データベースとは何か 4.なぜデータベースなのか 5.データの独立性 6.関係型システムとその他 7.まとめ. 1.導入. データベース(システム)とは. データベースシステムとは、「コンピュータ化した記録保持システム」。 データベースそのものは「コンピュータのデータファイルの収納庫」と捉えられる。.
E N D
An Overview of Database Management CHAPTER1 ~データベース管理の概略~ 遠山研究室 B3 日髙 大輔 2004/02/23
Outline 1.導入 2.データベースシステムとは何か 3.データベースとは何か 4.なぜデータベースなのか 5.データの独立性 6.関係型システムとその他 7.まとめ
データベース(システム)とは • データベースシステムとは、「コンピュータ化した記録保持システム」。 • データベースそのものは「コンピュータのデータファイルの収納庫」と捉えられる。
データベースシステムに対する操作 • 新しいファイルをデータベースに「追加」 • 既存ファイルにデータを「挿入」 • 既存ファイルからデータを「抽出」 • 既存ファイルからデータを「削除」 • 既存ファイルのデータを「更新」 • データベースから既存ファイルを「消去」 • 新しいファイルをデータベースに • 既存ファイルにデータを • 既存ファイルからデータを • 既存ファイルからデータを • 既存ファイルのデータを • データベースから既存ファイルを
図1.1 ワインセラーのデータベース(ファイル:CELLAR)図1.1 ワインセラーのデータベース(ファイル:CELLAR)
図1.1について • 後述するSQLにおいては、図1.1のCELLARファイルを「表」と呼ぶ。 • 表の行はファイルの「レコード」、列は「フィールド」と考えられる。 • 一般的にデータベースシステムについて述べるときは「ファイル」「レコード」「フィールド」、SQLにおいては「表」「行」「列」と呼ぶ。 (Chapter 3以降においてのより形式的な議論では「関係」「タプル」「属性」と呼ぶ)
CELLARに対する検索例 検索: SELECT WINE, BIN, PRODUCERFROM CELLAR WHERE READY = 2004 ; 結果(ディスプレイ表示): 図1.2 検索例
挿入(Insert)、削除(Delete)、更新(UPDATE) 図1.3 挿入、削除、更新の例
図1.2~1.3について(1) • SELECT, INSERT, DELETE, UPDATEの要求(文、コマンド、演算子などと呼ぶ)はSQLによる表現である。 • SQLはもともとIBMによる独自言語であったが、現在はほぼ全ての商用データベースによってサポートされている国際標準。 • SQLはもともと”Structured Query Langage”の略で、読みは「シークェル」だった。文法と違い、名称には規定が無く、今は「エスキューエル」と呼ぶのが一般的。
図1.2~1.3について(2) • 図1.3のUPDATEは「変更」を意味するが、“update”という語をINSERT, DELETE, UPDATEのひとまとまりと考えると、混乱する。 • 以後、一般的な意味を意図するときは小文字表記、UPDATE演算子について述べるときは大文字表記とする。 • 他にも厳密に言うなら、operationは行われた操作。operatorは呼び出されたもの(演算子)なので両者は異なるものだが、略式では区別されず使われる。
表CELLARについて • WINE列とPRODUCER列は文字列型データ、他列は整数型データ。 • 一般に行は、任意の複雑なデータも含むことが可能。 例:表CELLARに追加できる行 ・LABEL(ワインボトルのラベル写真)・REVIEW(ワイン雑誌の講評)・MAP(ワインの生産地地図)・NOTES(味見記録の録音)
主キー • BIN#は、表CELLARの主キーが含まれる。 • 簡単に言えば、主キーとは同表内に同値を持つデータが存在しないもの。 • ゆえにBIN#には値の重複がない。
データベースシステム • 「データベースシステム」は情報を保持し、要求に応じてそれを利用できることを目的とするコンピュータシステム。 ※注「データ」と「情報」は本書においては同義。 厳密に区別すると、データベースが物理的に記憶している物が「データ」、あるユーザが理解しているそれらの値の意味が「情報」
Database management system (DBMS) 図1.4 データベースシステムを簡易化した図
データとシステム規模 • データベースシステムは、パソコンから大型汎用コンピュータ、クラスタと利用システムの規模を問わない。 • 大規模システムでは複数ユーザが同時並行にデータベースにアクセスできる「マルチユーザシステム」、小規模システムでは最大一人のユーザのみがアクセスできる「シングルユーザシステム」になることが多い。
「統合(Integration)」 と「共用(Sharing)」 • データベース中のデータは大規模システムにおいても、統合・共用される。 • データ統合とデータ共用は「大規模な」環境におけるデータベースシステムの代表的な利点 • 少なくともデータ統合も、小規模環境において利点となりうる。
統合(Integration) • 別に存在するいくつかのファイルを、ファイル間重複を部分的もしくは全体的に除いた形で結合したものとして、データベースが捉えられる事。 例:)氏名・住所・部署・給料などが記録されたEMPLOYEEファイル、氏名・研修課程記録のENROLLMENTファイルが存在する→研修課程管理の処理に各員の所属部署を知る必要がある→対応するEMPLOYEEファイル中のレコードを参照すればよく、わざわざENROLLMENTファイルの中に重複して情報を含む必要がない。
共用(Sharing) • 複数ユーザの各々が、同一のデータにアクセスし、異なる目的での使用を許されるという意味。 • 前述のEMPLOYEEファイルは人事課・教育家の両方に共用される。 • 一つのデータベースは異なるユーザによって様々に解釈される。(くわしくは後述)
ハードウェア • 補助記憶装置(磁気ディスクなど)I/O機器、I/Oチャネルなどと共に、データ保持に使われる。 • 処理装置と主記憶データベースシステムソフトウェアの実行を支援する。
ソフトウェア(1) • 物理的なデータベース(実際に記憶されているデータ)とシステムのユーザの間にはデータベースマネージャやデータベースサーバ、そしてデータベース管理システム(DBMS)といういずれかのソフトウェア層がある。 • DBMSは、データベースのユーザに、ハードウェアレベルの詳細を隠蔽する。→プログラミング言語がハードウェアレベルの詳細を隠蔽しているのと同様
ソフトウェア(2) • DBMSはハードウェアレベルより抽象化されたデータベースの認識をユーザにさせる。 ※DBMSはシステム全体の内、最も重要なソフトウェア構成要素ではあるが、それだけが全てではない。アプリケーション開発ツール、設計支援、レポートライターなどが他の構成要素として存在する。
ユーザ 大きく分けて、3種類のユーザを考える。 • アプリケーションプログラマーApplication Programmer • エンドユーザEnd User • データベース管理者Database Administrator
アプリケーションプログラマー • COBOL, PL/I, C++, Java,上位第四世代言語などのプログラミング言語で、データベースアプリケーションを作成するユーザ。 • これらのアプリケーションプログラムはインタラクティブに(対話形式で)データベースにアクセスできる。 • アプリケーションには従来からの「バッチアプリケーション」と「オンラインアプリケーション」(オンラインでデータベースにアクセス)がある。
※第四世代言語(4GL) • 定型的な事務処理を行なうためのオンラインのアプリケーションソフトを、実際にアプリケーションソフトを使う人(エンドユーザ)が設計できるように、対話形式で開発ができるプログラミング言語。COBOLなど、専業のプログラマが必要な従来のプログラミング言語よりも生産性が高いとされている。機械語を第1世代、アセンブリ言語を第2世代、COBOLなどの高級言語を第3世代と呼ぶことから、第4世代と呼ばれる。 (詳細はChapter 2)
エンドユーザ • データベースに対話形式でアクセスする。 • ほとんどのデータベースシステムは、対話式の“query language processor”が組み込まれている。 • SQLがその典型。これによってユーザは高次レベルの命令やステートメント(SELECT,INSERTなど)をDBMSに要求できる。
データベース管理者(DBA) • データベースを技術的な面から管理するITの専門家(詳しくは4.なぜデータベースかにて)
永続的(Persistent)データ • データベース内のデータは「永続的」といわれる。⇔「短命(ephemeral)」 • 短命なデータとは、入力データ・出力データ・処理列・ソフトウェア制御ブロック・SQL文・中間結果などを指す。
データベースは、ある企業によって使用される永続的データの集合である。データベースは、ある企業によって使用される永続的データの集合である。 • ここで述べる「企業」とは、商用、科学的、技術的、その他を目的とする組織の総称。企業は(小規模の個人用データベースを持つ)個人や、(非常に大きな共用データベースを持った)完全な企業、あるいは大きな団体でもあり、その中間のものでもある。
企業とその永続的データの例 1.製造会社 …製品データ 2.銀行 …口座データ 3.病院 …患者データ 4.大学 …学生データ 5.官庁 …計画データ
運営データ • 当初は「永続的データ」の代わりに「運営的データ」という用語を使っていた。それは運営や生産におけるデータベースの適用に主眼を置いていた事を反映している。→ 定型的で反復性の高いアプリケーションは繰り返し実行され、日常的な組織 運営を支えていた。例:銀行の現金預け入れ・引き出し支援アプリケーション
OnlineTransactionProcessing(OLTP) • 「運営データ」から「永続的データ」へ表現が変わった昨今の情勢として、よく用いられる用語。 • ネットワークに接続された複数の端末(もしくはクライアント)がそれぞれ、ホストコンピュータ(もしくはサーバ)にアクセスして処理要求を行い、それに基づいてホストコンピュータがデータの追加・更新・変更・削除といった処理を行い、その処理結果を逐次端末に送り返す形の情報処理方式。
実体(Entity) • 製造会社を例に挙げると、プロジェクト、部品、部品の納入業者、部品を保管する倉庫、従業員などを記録しようとする。→プロジェクト、部品、業者などは、その会社が情報を記録する必要のある基本的な実体(entity)を構成している。
図1.6 E/Rダイアグラム (製造会社KnowWare Inc.の例)
関係(Relation) • 図1.6において、菱形とそれを結ぶ線で表現されている物 例1:SuppliersとPartsの関係はSP →納入業者はある部品を供給する。 (=部品はある納入業者から供給される) 例2:PartsとProjectsの関係はPJ →部品はプロジェクトで使用される。 (=プロジェクトは部品を使用する)
関係を用いたクエリの例 • ある納入業者が供給する部品はどれ? • ある部品を供給する納入業者はどれ? ∴関係は双方向であり、どちらの方向にも行き来できる!
図1.6の補足(1) • 図中の関連のほとんどは二種類の実体の結合だが、SPJのように三種類のエンティティを結びつける1つの関係という場合もある。 例: a.スミスはモンキーレンチをマンハッタンプロジェクト に納入する b.スミスはモンキーレンチを納入する c.モンキーレンチはマンハッタンプロジェクトで使用さ れる d.マンハッタンプロジェクトはスミスから供給を受ける b.c.dだけではaを推論できない!
connection trap(結合の罠) • 前述のb,c,dでは・スミスはモンキーレンチをプロジェクトJzに納入・納入業者Sxはモンキーレンチをマンハッタンプロジェクト に納入・スミスは部品Pyをマンハッタンプロジェクトに納入 ∴Sx=スミス,Py=モンキーレンチ,Jz=マンハッタンプロジェクトという推論が出来ない! このような誤った推論を “connection trap”(結合の罠)という
図1.6の補足(2) • PPのように、一種の実体のみを結ぶ関係もある。→ ある部品は他の部品を直接の構成要 素としている。(bill-of-material関係) 例:蝶つがいとネジ
図1.6の補足(3) • 一般に二つの実体間には、いくつ関係があってもよい 例: ProjectsとEmployeesEJ:従業員がプロジェクトに割り当てられている。MJ:従業員がプロジェクトを管理している。 • 関係はそれ自体が一つの実体と見なすことができる 例: 部品P4は倉庫W8に収納されている →それに関する情報(量など)を記録してある
実体の性質 • 納入業者は所在地、部品は重量、プロジェクトは優先順位、割り当ては開始日といった属性を持つ。→そのような属性もデータベース中で表現されなければならない。 例: 納入業者という実体を表すレコードS Sは属性“所在地”を表すフィールド型CITYを持つ • 属性は単純な物もあるが、複雑な内部構造の物もありうる。例: 納入業者所在地 → 都市の名前(文字列型) 倉庫の見取り図 → 図面と説明文
紙記録とデータベースの比較 • データベースは伝統的な紙による記録保持より以下の点で優位 • コンパクト:大量の紙ファイルが不必要 • スピード: 機械は人間より高速にデータを検索・更新 • 単調な作業が少ない • 正確かつ最新情報がいつでも利用可能 • 保護: 意図しないミスや不正アクセスからデータを守る
マルチユーザ環境での優位性 • 先述の利点は、大規模で複雑になる傾向があるマルチユーザ環境で特に強い ∵組織に対してデータの集中制御が可能 • もしデータベースでなかったら… 各アプリケーションが専用ファイルを持ち 各個人は自分専用のテープやディスクを所有 ∴体系的にデータ制御するのが困難!
データ管理者(DA) • データ管理者(Data Administrator)とは、データに対して中心的な責任を負う人間。仕事:記録されるべきデータの決定と、そのデータの維 持・取り扱いの方針を制定する。 • データ管理者はあくまでも管理職であって、専門の技術者ではない。(といっても、技術的なレベルでデータベース能力の理解は必要)
データベース管理者(DBA) • データ管理者の役割の技術的な方面を見る人間(=専門の技術者) • 実際のデータベースを作成し、DAの定めた方針を施行するのに必要な技術的統制を実施する。 • システムが適切な性能で動作する保証と、関連する技術サービスを提供する責任がある。 • DBAの機能は、システムプログラマーやアシスタントなど複数の人間のチームで実行されるのが一般的
データベースによるアプローチの利点(1) • データを共有できる 既存アプリケーションがデータベース中のデータを共有できるだけでなく、新アプリケーションも同じデータに対して操作を行うように開発できる。 • 冗長性を減少できるデータベースでないシステムは各アプリケーションが専用ファイルを持つため、記憶データに冗長性が生じる。
データベースによるアプローチの利点(2) • 矛盾を(ある程度)回避できるファイルが統合されたため、実世界に関する事実(例:従業員E3は部署D8で働いている)がデータベース中の二つの異なるエントリで表現されているとき、この冗長性がシステムにとって既知ならば、一つのみが更新を受けたとしても、伝搬更新(Propagating update)により、一致させる事が可能。もしくはこの冗長性を、一つのエントリで記述するようにすれば、伝搬更新そのものが不要。