3.3 論理設計の手順(4/4)

できるエンジニアになるためのちょい上DB術/第2章 概念設計

3.3 論理設計の手順(4/4)

3.3.7 ビューとアクセス権限の設計

ビューとは

ビューとはどのようなオブジェクトか、どのような目的で使用するのかを説明します。

表は物理的にデータベース内に格納されるスキーマですが、ビューは、これを通して必要なデータのみを、定義した形で取得させるフィルターのようなものです。
ビューは(マテリアライズドビューを除いて)実際のデータを格納するものではありません。

セキュリティの観点から、アプリケーションやユーザは、直接、表のデータにアクセスすることはできないけれども、ビューを経由してであればデータにアクセスできるという制限をかけることができます。
ビューを経由することによって、ビューで定義した列や行のみを参照できるようにすることができます。
ビューに定義されていない列は、参照も更新もできないことになります。
また、更新できるかどうかは、ビューではなく、列単位でオブジェクト権限と呼ばれるアクセス権限を設定することによって制御することができます。

ビューの必要性

次の3つの観点からビューを定義します。

  • 照会の容易性
  • データの独立性
  • データの保護

ビューの作成方法

ビューは、以下のようなCREATE文を使って作成され、データデイクショナリと呼ばれる管理表にその定義が格納されます。

CREATE VIEW 社内従業員参照
(従業員名,メールアドレス,役職,職種,部門番号,部門名,代表電話番号) AS
SELECT 従業員.従業員名,従業員.メールアドレス,従業員.役職,従業員.職種,部門.部門番号,
       部門.部門名,部門.代表電話番号
FROM 従業員,部門
WHERE 従業員.部門番号 = 部門.部門番号;

ビューの照会

SELECT*FROM 社内従業員参照:

上記SELECT文が発行されると、SELECT文の定義とVIEWの定義(VIEW作成時のAS SELECT文以下)がマージされ、1つのSQL文として実行されます。

アプリケーションから見ると照会のための文は簡易になりますが、パフォーマンスがよくなるわけではありません。
それは、ビューが実際の値をもつオブジェクトではないからです。

ビューを参照するSQL文の書き方によっては、かえって複雑になり、遅くなるケースも考えられるので、ビューをFROM句に指定した場合、実行計画やレスポンスタイムに気をつけてください。
ビューがネスト構造になっている場合は特に、実行計画やコストを確認した方がいいでしょう。

ビューによる独立性

物理スキーマ(表)に変更があったとしても、アプリケーションから直接その部分に関係することがなければ、論理スキーマ(ビュー)が定義してあれば、アプリケーションを書き直す必要はありません。
アプリケーションが、論理スキーマに対して処理を記述していれば、物理的な構造が変化したとしても、アプリケーションを書き直す必要はありません。
データとアプリケーションの独立性をビューによって実現することができます。

ビューによるデータ保護とアクセス権限

図3-20で、ユーザsuzukiは、従業員表に対して直接アクセスすることはできません。
一方、ビューと表の所有ユーザであるdevempによって、次の権限を与えられると、「社内従業員参照」ビューに対してSELECT文のみ発行することができるようになります。

  • 社内従業員参照ビューのSELECT権限
GRANT select on社内従業員参照 TO suzuki;

これによって、ユーザsuzukiは、社内従業員参照ビューを介して、従業員表と部門表の列のうち、ビューに定義されている列を参照することができるようになります。

ただし、このビューで定義されていない、従業員表の給与列を参照することはできません。
また、一方で、これらの列に対するUPDATE権限やDELETE権限はユーザsuzukiには与えられていないため、更新や削除はできません。

ビューは参照のために使われるオブジェクトなので、更新処理などは基本的にビュー経由では行いません。
ビューを定義するのであれば、複数の元表を結合して必要な列を複数の表から取得してくることが多いのですが、その場合、更新できるのは、「ビューで定義された行集合から1行を特定できる主キー列を含む1表のみ」になるため、事実上、ビュー経由では更新はできません。

更新系の作業は、列単位または表単位でオブジェクト権限と呼ばれる権限を、ユーザまたは権限セットであるロールに付与します。
業務に必要な権限をまとめてロールに付与し、そのロールをユーザに付与することによって、管理負荷を軽減します。

< 前へ | 3.3 論理設計の手順(4/4) | 次へ >

解説トレーナー

Oracle / 上流工程 担当 中村 才千代

データベース設計、システム構築の上流~下流工程全般のインストラクターです。SE時代の経験を生かし「業務を知るエンジニアこそDB設計に関わるべき」「DB設計に携わるエンジニアは業務を知る人に知恵を貸してもらう」ことを伝えたいと思っています。

■認定・受賞

2000年 Oracle University「Best Instructor of the Year」受賞
2002年 Oracle University「Best Instructor of the Year」受賞

Page Top