- 1 -

・・‥……━━━━━━━━━━━━━━━━━━━━━━━━━……‥・・

データベース技術者のための DOA入門（1/2）・・‥……━━━━━━━━━━━━━━━━━━━━━━━━━……‥・・

佐藤正美

- 2 -

本講演は、以下の点を論旨とします。

RDBMS の基本的動作を理解する。

目次

１. 事例１-１. パフォーマンス１-２. ソース・コード

２. データの独自性２-１. 物理データ独立性２-２. 論理データ独立性３-３. ３階層構造★ 今回は、分散アーキテクチャには言及しない。

３. データ・モデル３-１. データ構造３-２. データ演算３-３. Integrity 制約

４. データ構造４-１. テーブル構造４-２. 関係モデル

５. リレーショナル代数演算５-１. 集合演算５-２. リレーショナル代数演算５-３. セット・アット・ア・タイム法

６. キーと indexing６-１. キー概念６-２. indexing とＢ-tree（レコード・アット・ア・タイム法）

７. INDEX-only

８. 基本的なモニタリング・チューニング８-１. Ｉ/Ｏ関連８-２. Ｉ/Ｏ関連以外

- 3 -

▼ 事例

‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾

RDBの高ﾊﾟﾌｫｰﾏﾝｽ 正当なデータ構造があれば、

ＲＤＢは、「驚異的な」パフォーマンスを実現する。

ﾌﾟﾛｸﾞﾗﾑのｿｰｽ･ｺｰﾄﾞ 正当なデータ構造があれば、

プログラムのソース・コードが削減される。

▼ データの独立性

‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾

外部層（external layer） 外部モデル ● 応用（application）

② 論理独立性

概念層（conceptual layer） 概念モデル ● データ構造

① データ独立性

内部層（internal layer） 内部モデル ● 物理構造

（注意）今回は、入門編なので、分散したデータベース・システムを対象にしない。

★ 参考

「概念」という用語の使いかたは、データの独立性とデータ設計では違うので注意

してください。

データ設計

① 概念設計 ② 論理設計 ③ 物理設計

（conceptual） （logical） （physical）

データベース化の対象を 特定のプロダクトを考慮 使うプロダクトを考慮

調べる。 しない。 する。

- 4 -

▼ データ・モデル

‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾

データ・モデル

データ構造 データ演算 Integrity 制約

① スキーマ（schema） ① データ定義（DDL） ① 実体 integrity 制約

② 例（instance） ② データ演算（DML） ② 参照 integrity 制約

実現値（occurrence）、状態（state）とも云う。

Data Definition（スキーマに対して）Data Manipulation（例に対して）

（１）Integrity を乱す更新演算を拒否する。（２）Integrity が崩れないように、他のデータを更新する。

（cascading、nullfied）

★[ tips ]

たとえば、以下のデータを前提にして、nullified を考えます。

｛従業員番号、従業員名称、...部門ｺｰﾄﾞ(R)｝.001 Ａ 01

部門ﾃｰﾌﾞﾙから部門ｺｰﾄﾞ 01が削除されたとき、上記の部門ｺｰﾄﾞは、nullfied にします。ただ、RDB のなかで、null の使用は危険であることを注意してください。たとえば、以下のデータを使って、null の危険性を調べてみてください。

SELECT name salary + bonus FROM employee.

従業員のなかに、ボーナスのない（null）従業員がいれば、その従業員は、「salary + bonus」も、null になってしまいます。

- 5 -

▼ データ構造

‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾

● 直積集合

直積集合 ２つの集合に対して、それぞれのメンバーの組を直積集合という。

Ａ Ａ×Ｂ

Ｂ

Ａ＝｛０, １｝ Ｂ＝｛１, ２｝

直積（Ａ×Ｂ） （０, １）（０, ２）（１, １）（１, ２）

一般形 Ｒ＝｛ｓ１, ｓ２, ..., ｓｎ｜ｓ１∈Ｘ１, ｓ２∈Ｘ２,..., ｓｎ∈Ｘｎ｝.

★ 個々のセットから選んで構成された｛ｓ１, ｓ２, ..., ｓｎ｝を「タプル（tuple）」という。

● 関係の論理（ａＲｂ）

関係の論理

ａＲｂ ａはｂに対して関係Ｒ（Relation）にある。

ａＲｂ ≡ Ｒ(ａ, ｂ)

性質 関係

ｆ(x) ｆ(x, y)

関数

- 6 -

● 関係モデル

関係スキーマ 直積集合

① 統語論 集合演算

代数演算

リレーショナル演算

関数従属性

② 意味論 従属性

包含従属性

[ 注釈 ]

用語 意味

統語論 記号の間に成立する関係（対象言語の構造）を扱う。

意味論 事実と言明（叙述文）の対応関係を扱う。

スキーマ 時間不変な論理単位、「組織化された知識」のこと。

直積集合 Ｒ＝｛ｓ１, ｓ２, ..., ｓｎ｜ｓ１∈Ｘ１, ｓ２∈Ｘ２,..., ｓｎ∈Ｘｎ｝.

集合演算 和集合や共通集合などの演算

リレーショナル演算 SELECT, JOIN, PROJECTION

関数従属性 １つのテーブルのなかで、１つの属性値に対して、べつの属性

値が、一意にきまること。

包含従属性 或るテーブルのなかのキーの値は、他のテーブルのなかにも

存在していなければならない。

● テーブル構造（タプルに実際値を入れた「表」、flat-file とも云う。）

table

→ row

↓ column

- 7 -

▼ セット・アット・ア・タイム法（set-at-a-time）‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾

● traversal-table

「物」テーブル ＳＱＬ

NAME ････ 色 ････ SELECT....FROM 物ROW-ID WHERE

Ａ ････ 緑 ････ NAME＝"Ｂ"① OR

Ｂ ････ 黒 ････ 色 ＝"赤".②

Ｂ ････ 赤 ････

③

traverse-table（同一 row 上の検証をする）

ROW-ID

traverse-table ② Ｂ

③ Ｂ

③ 赤

③ のＢと③の赤は、同一 row 上にある。

セット・アット・ア・タイム法

MAX-SIO の無制限 同一 row 上の検証

（１）テーブルのなかのデータを 機能的依存関係は row 単位に記述され、すべて scan する（table-scan）。 集合は column 単位に記述されている

（２）ORDER-BY句を記述すれば、 ので、同一 row 上の検証をするために、並びを保証するために、traverse- traverse-table を生成する。table を生成する。

★[ tips ]

かならず、execution-plan（実行プラン）を確認してください。（多量データ、多量トランズを対象にしているのであれば、）

以下の表示がされたら、「しまった(Darn it !)」と思ってください。

table-scan ×××

- 8 -

▼ キー（keys）‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾

● キーの種類

① native -key データをロードするときに物理配置をきめる。

② master-key 一意性を検証する。

③ (n-key、m-key以外の)keys １つ以上のレコードを検索する。

④ cluster-key データの物理配置を編成する。

⑤ null-key キーの値を nullにする。

⑥ inverted-key 「１つのキー値-複数データアドレス」方式

⑦ hash-key Indexing を使わないで、ページをアクセスする。

● native-key と master-key

emp-no sec-no

01 13

02 8

03 10

emp-no を master-key とする。

sec-ne を native-key とする。 ★ space-management① no reclamation② reclamation③ wrap-around

emp-no sec-no ④ clustering(insert)

→ 02 8

(reject) 03 10 （deleted）

01 13↓ (insert)

02 8 50 48

- 9 -

● master-key と keys

① ②

master-key duplicate-master-key y n

keys change-master-key y n

● cluster-key

clustering

① multi-tables in one dataset ② merge of tables

複数のﾃｰﾌﾞﾙを１つの物理ﾃﾞｰﾀｾｯﾄのなか 複数のﾃｰﾌﾞﾙを merge して、１つの物理に分離格納する。 ﾃﾞｰﾀｾｯﾄにする。

● キーの系統樹

keys

the master-key null-keys

the native-key cluster-key

★[ tips ]

RDBは、バージョンアップのなかで、「CRETAE INDEX」や「IF...THEN...」を搭載してきました。これらが、RDBを、ファイルのように使う弊害を生んだようです。すなわち、INDEX を使って、row 単位にアクセスして、SQL を使って、「構造的プログラミング」をおこなう、と。SQL は、基本的には、「I/O言語」と考えたほうが、効果的・効率的に使うことができます。

- 10 -

▼ レコード・アット・ア・タイム法（record-at-a-time）‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾

レコード・アット・ア・タイム法

テーブル インデックス・ファイル

CUST table CREATE INDEX (CUST-NO)

NO NAME ････ （１）常駐ファイル（resident）

１ Ａ ････ （２）Ｂ-tree 構造

２ Ｂ ････

： ： ････

Ｂ-tree 構造（Compound Relational Index）

root

branch

leaf

（１）最上位をルート（root）といい、最下位をリーフ（leaf）という。途中の階層をブランチ（branch）という。

（２）２階層までを「high-level index」という。３階層から最下位までを「low-level index」という。

（３）最下位には、キーの値とデータ・アドレスが納められている。

データ・アドレスは相対アドレス（始まり点から＋αのアドレス）である。

Ｂ-tree 構造の弱点

Ｂ-tree 構造は（rootを起点にして leafに至るまで）「手繰る」構造になっている。したがって、

（１）indexing を使って、すべてのデータを順次的にアクセスすれば、おそい。（この弱点を回避するには、leaf の「GETNEXT」を使えばよい。）

（２）Ｂ-tree 構造の階層が多くなれば、おそい。（null-keys を使って、階層を生成しないようにすればよい--後述。）

（３）「low-level index」が split すれば、「high-level index」は再編成される。

- 11 -

▼ キー（index-key）の定義表‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾

● 「キーの定義表」のフォーマット（ﾃｰﾌﾞﾙごとに作成する）

キー N ２ ３ ４ ５ ６ ７ ８ ９ 10データ M

一意性を検証する keys

● 「キーの定義表」の具体例

受注テーブルのキー定義書： 受注テーブル

キー N ２ ３ ４ ５ 受注 Ｅ

データ M受注 NO 受注日

受注 NO ② 顧客 NO（Ｒ） 受注数品目ｺｰﾄ （゙Ｒ）

顧客 NO ① ①

品目ｺｰﾄﾞ

受注日 ②

受注数 ③

（１）顧客ごとに、受注番号は連続番号が付与されている。

受注番号は、一意性を実現しない。

（２）顧客ごとに、受注数の推移を知りたい。

- 12 -

▼ INDEX-only‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾

セット・アット・ア・タイム法 レコード・アット・ア・タイム法

できる view できない

悪い パフォーマンス セット系に比べて、良い

traverse-table の罠がある Ｂ-tree 構造の罠がある

同一 rowの検証 MAX-SIOの無制限 手繰る（たぐる） 揺らぐ（ゆらぐ）

「INDEX-only」w/ null-keys

traverse-table を生成しない Ｂ-tree 構造を手繰らない

高パフォーマンスを実現する

レコード・アット・ア・タイムをセット・アット・ア・タイムとして使う。

★[ tips ]

RDBMS側から観れば、「INDEX」と「VIEW」は、アクセス単位として、区分がないのです。というのは、「INDEX」は、ｾｯﾄ･ｱｯﾄ･ｱ･ﾀｲﾑ法に対して、「上積み」されたにすぎないから。

★[ tips ]

以下の実験をしてみてください。

（１）３つの column を用意する。｛ａ, ｂ, ｃ｝.（２）｛ａ, ｂ, ｃ｝に対して、「CREATE INDEX」を、default のまま

--つまり、ascending のまま--生成する。（３）｛ａ, ｂ, ｃ｝に対して、「CREATE INDEX」を、descending で、

生成する。

さて、｛ａ, ｂ, ｃ｝の indexing を使って、DB2・ORACLE で、降順にデータを並べてください。SQL/Serverで、昇順にデータを並べてください。

- 13 -

● 「INDEX-only」の単純な例

画面の例：顧客 NOと受注 NOを入力する

受注照会画面

顧客 NO：×××× 顧客名称：××××××××××

受注 NO：×××× 受注日：××××-××-××

品目ｺｰﾄﾞ 品目名称 受注数 品目単価

××× ×××××××××× 999 9,999 １

顧客 Ｒ 受注 Ｅ 品目 Ｒ

顧客 NO 顧客区分ｺｰﾄﾞ ┼──＜ 受注 NO 受注日 ＞──┼ 品目ｺｰﾄﾞ 品目名称

顧客名称 顧客番号(R） 受注数 品目単価

品目ｺｰﾄﾞ(R)

キーの定義書（「CREATE INDEX」）

顧客： 受注： 品目：

顧客 NO ① 受注 NO ② 品目ｺｰﾄﾞ ①

顧客名称 ② 顧客番号(R） ① 品目名称 ②

品目ｺｰﾄﾞ(R) ④ 品目単価 ③

受注日 ③

受注数 ⑤

SELECT 顧客. 顧客名称,受注. 品目ｺｰﾄﾞ, 受注. 受注日, 受注. 受注数,品目. 品目名称, 品目. 品目単価

FROM 顧客, 受注, 品目

WHERE 顧客. 顧客 NO = 受注. 顧客 NOAND 受注. 品目ｺｰﾄﾞ = 品目. 品目ｺｰﾄﾞ ....（以下、省略）

★[ tips ]

「INDEX＝ VIEW」と思ってください。検索したいデータ（columns）を、表示したい順に並べて、「CREATE INDEX」を作ればよいでしょう。高ﾊﾟﾌｫｰﾏﾝｽを実現します。

- 14 -

● 「INDEX-only」と曖昧選択（LIKE句）

（１）環境：ORACLE7, UNIX（２）テーブル：（100％正規化されている）

① 顧客テーブル（データ総数は 300万件である）② 店テーブル（データ総数は 300万件である）③ 契約テーブル（データ総数は 70万件である）

（３）以上の３つのテーブルを join した曖昧選択：SELECT 顧客. 顧客氏名, 契約. 契約 NO, 店. 店名称, 契約. 売上元金FROM 顧客, 契約, 店WHERE 顧客. 顧客 NO = 契約. 顧客 NO

AND 顧客. 顧客氏名 LIKE '佐藤％'AND 店. 店 NO LIKE '％ 12％'AND 契約. 売上元金 ＞ 1500000;

（４）選択されたデータ件数は 540件で、レスポンスは「瞬き」の速さだった。[ 「LIKE '％値％'」を使っても高パフォーマンスは保証できる。]

● 「INDEX-only」使用上の注意点

① データ件数が少なければ効果はない。

② データのロードがおそくなる。

③ index-file が大きくなる。（容量計算に注意する。）

★[ tips ]

「INDEX-only」を使ったら、かならず、execution-planを確認してください。以下の表示になっていれば、成功です。

index-scan ××

★[ tips ]

RDB の最大特徴は、JOIN 操作です。RDB を使っているなら、inner join を最大限に活用してください。

「INDEX-only」は、複合検索条件（AND/OR）や JOIN に対して、きわめて、有効に作用します。複合検索条件では、「INDEX-only」を前提にしていれば、「OR」を使っても、複数の「OR」条件に該当したデータは、１件として、表示されるので、大丈夫です。

- 15 -

● 論理 I/O の計算式

READ ２

ADD １＋Ｎ

UPDATE CHANGE ３（＋Ｎ）

DELETE ２＋Ｎ

Ｎは、（当該 column をふくんでいる）index-key の数である。

ADD が、いちばんに、論理 I/O が少ない。「ADD-only」を考えればよい。

● pipeline 機能

DBMS(3) INDEX

→

→

THREAD-1 →

→ (2)DATA

→

→ (1)THREAD-2 →

→

LOGmemory buffers

① DELETE, UPDATE requests ③ Physical writes② Logical updates to buffers in memory

★[ tips ]

RDBMS の internals には、更新を高速にするﾊﾟﾗﾒｰﾀは用意されていますが、READ を高速にするﾊﾟﾗﾒｰﾀはない。

したがって、「INDEX-only」と「ADD-only」を、できるかぎり、使えばよい。

- 16 -

▼ Null-keys‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾

● 基本的作用

null-key-1（正社員） null-key-2（パート） emp-no 従業員区分ｺｰﾄﾞ

０１ //////////////////////////////// ０１ 正社員

////////////////////////////// ０２ ０２ パート

０３ //////////////////////////////// ０３ 正社員

Null-key は、B-tree から排除されることが前提である。

● 補集合と null-key

受注 Ｅ 契約 Ｅ

受注 NO 受注日 ┼────┼ 契約 NO 契約日

受注数 受注 NO (R) 契約数

受注は「仮契約」である。

契約されていない受注（補集合）を一覧表示したい

受注の「キーの定義書」

keys-1 null-key ････

受注 NO ① ○

受注日 ②

受注数 ③

受注テーブルの実装形

受注 NO（null） 受注 NO 受注日 受注数

///////////////////////// ０１ 1999-12-13 100０２ ０２ 1999-12-14 150

///////////////////////// ０３ 1999-12-15 80///////////////////////// ０４ 1999-12-16 120

（１）契約された受注 NOは、受注 NO（null）を null 値（HEX'00'）にする。（２）受注 NO（null）を「CREATE INDEX」すればよい。

null-key を使えば、契約されていない受注 NO（補集合）が得られる。

- 17 -

● データの圧縮

tableI/Oは block単位

memory

DATA buffers

block

圧縮 record 圧縮 record 圧縮 record

program 排他は record単位

拡張 buffers

ｱｸｾｽは view単位

★[ tips ]

data-compress は、DBMS に対して、多大な負荷を及ぼします。データを圧縮すれば、（block のなかに格納される record が多くなるので、）データのヒット率が高くなる、というような俗説もありますが、もし、

DISK の圧縮効果が、30％以下であれば、data-compress をしないほうがよいでしょう。

★[ tips ]

（１） directory と log-file は、それぞれ、（data および index とは）べつのdisk に割り当てる。

（２） data と index は、できるかぎり、数多くの disk を用意して、べつべつの disk に散らすように割り当てる。（index と data は、同じ disk に割り当てない。）

- 18 -

▼ DBMS の使用状況（monitor and tune-up）‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾

算 式 原 因

データ構造が正規

I/O 関係 ③ ÷ ② ≧ 0.05 化されていない。

① requests 総数② １次排他の requests 回数 ④ ÷ ① ≧ 0.5 SEQBUFS が少な

③ １次排他の conflicts 回数 い

④ READ-AHEADの I/O回数 CHECKPOINT の⑤ ２次排他の conflicts回数 ⑤ ÷ ② ≧ 0.25 interval が大きい

過ぎる

「≧」（超える数値）

になったら危険である、

ということ。

I/O 以外

（１）buffers の refresh回数（２）INDEX の split 状況 データの更新時の排他制御のこと

（３）data-compression（４）DISK が busy

transaction-backout/rollbackが起こったときの排他制御のこと

accounting

LOGIO EXCP ETIME RTIME I/O回数ではない

多 少 少 少 （理想的）

多 多 多 少 （「pipeline機能」の効果がない。wait-timeが多い。）

- 19 -

END

- 20 -

■ あとがき

（１）弊社（株式会社ＳＤＩ）のホームページ

本日のプレゼンテーションを補足するために、弊社のホームページを御覧いただければ

幸いです。以下の４つのなかで、本日、お話いたしました中味を補足しております。

「ベーシックス（数学基礎論とデータベースの基礎知識）」

http://www.sdi-net.co.jp

（２）メールのアドレス

本プレゼンテーションに対する御質問・ご意見がございましたら、

ご一報いただければ幸いです。

mail@sdi-net.co.jp

masami@sdi-net.co.jp

（３）謝辞

情報システム・コンサルタントとして、実地の仕事のなかで使っている技術（技術の根

底にある前提）を、DOA+ の観点から、概略ですが述べてみました。皆様のシステム構築に少しでも役立てば幸いです。

御聴講いただきました皆様の御活躍をお祈りしております。

佐藤正美

株式会社 SDI107-0052 東京都港区赤坂 7-3-37

ﾌﾟﾗｰｽｶﾅﾀﾞ 1 階電話：03-6894-7446

[ 作成 ] 佐藤正美 All Rights Reserved. 本テキストの複写・転載を禁止いたします。