DBMS スキーマ: 内部、概念的、外部
フィオナ・ブラウン
⚡ スマートサマリー
DBMSスキーマはデータベースを3つの絶対的な構造に整理しますtracレベル分けにより、ユーザー、設計者、管理者それぞれが適切なレベルで作業できます。内部スキーマ、概念スキーマ、外部スキーマが一体となって、データ独立性を実現するANSI-SPARCの3層アーキテクチャを構成します。
データアブスとは何かtracDBMSにおける機能？
データベースシステムは複雑なデータ構造に基づいて構築されています。データの取得を効率化し、ユーザーの操作の複雑さを軽減するために、開発者はデータ抽象化の手法を使用します。tracデータアブソリュートtracこの機能により、データの保存方法や管理方法の詳細が隠蔽され、各タイプのユーザーが必要とする情報のみが表示されます。
データアブソリュートには主に3つのレベルがありますtracる：
- 内部レベル: 実際の物理的なストレージ構造とアクセス経路。
- 概念レベルまたは論理レベル： データベース全体の構造と制約。
- 外部またはビューレベル: さまざまなユーザービューについて説明します。
これら3つのレベルは、それぞれに対応する3つのスキーマによって記述され、これらを総称してANSI-SPARC 3レベルアーキテクチャと呼びます。スキーマとは、あるレベルにおけるデータベースの設計または記述であり、データ自体はインスタンスと呼ばれます。下の図は、各レベルがどのように階層的に配置されているかを示しています。
それでは、ストレージ層から始めてユーザー層へと順に、各レベルを詳しく見ていきましょう。
内部レベル／スキーマ
内部スキーマは、データベースの物理的な記憶構造を定義します。内部スキーマは、データベース全体を非常に低レベルで表現したものです。内部スキーマには、複数の種類の内部レコードが複数回出現します。ANSI規格では、「格納レコード」とも呼ばれます。
内部スキーマに関する事実：
- 内部スキーマはデータの最下位レベルですtracる。
- これは、レコードの形式でディスク上に実際に保存されているデータなど、データベース全体の実際の表現に関する情報を保持します。
- 内部ビューでは、データベースにどのようなデータがどのように保存されているかがわかります。
- 物理デバイスを直接扱うことはありません。代わりに、内部スキーマは物理デバイスを物理ページの集合として捉えます。
ストレージ層が定義されると、その上に位置する論理設計が概念スキーマによって記述される。
概念スキーマ／レベル
概念スキーマは、ユーザーコミュニティ向けにデータベース全体の構造を記述するものです。このスキーマは物理的なストレージ構造に関する情報を隠蔽し、データ型、エンティティ、リレーションシップなどの記述に重点を置いています。
この論理レベルは、ユーザーレベルと物理ストレージビューの中間に位置します。単一のデータベースに対して、概念的なビューは一つしか存在しません。
概念スキーマに関する事実：
- すべてのデータベースエンティティ、その属性、およびそれらの関係を定義します。
- セキュリティおよび完全性に関する情報を保持します。
- 概念レベルでは、ユーザーが利用できるデータは、物理レベルに含まれているか、または物理レベルから導出できるものでなければならない。
コンセプトデザインは、 リレーショナルデータモデルエンティティがテーブルになり、リレーションシップがキーになる。概念レベルより上では、個々のユーザーは、外部スキーマによって記述された、自分に関連するデータのみを見ることができる。
外部スキーマ／レベル
外部スキーマは、特定のユーザーが関心を持つデータベースの部分を記述します。これにより、データベースの関連性のない詳細情報はユーザーから隠蔽されます。各データベースには、n 個の外部ビューが存在する可能性があります。
各外部ビューは、外部スキーマを使用して定義されます。外部スキーマは、その特定のビューに対応するさまざまな種類の外部レコードの定義で構成されます。
外部ビューとは、特定のユーザーから見たデータベースの内容のことです。例えば、営業部門のユーザーは、営業関連のデータのみを見ることができます。
外部スキーマに関する事実:
- 外部レベルは、特定のエンドユーザーが閲覧するデータのみに関係します。
- このレベルには、1つ以上の外部スキーマが含まれます。
- 外部スキーマレベルはユーザーに最も近い。
- 外部スキーマは、特定のユーザーグループに必要なデータベースのセグメントを記述し、そのグループから残りの詳細情報を隠蔽します。
3段階構造 Archiテクスチャ比較
3つのレベルは、並べて考えると覚えやすいでしょう。それぞれ異なる質問に答え、異なる対象者を想定し、異なる理由で変化します。
| 側面 | 内部スキーマ | 概念図式 | 外部スキーマ |
|---|---|---|---|
| とも呼ばれている | 体力レベル | 論理レベル | ビューレベル |
| 説明 | ディスクにデータを保存する方法 | どのようなデータと関係性が存在するのか | ユーザーグループが見るもの |
| Audience | データベース管理者 | データベース設計者 | エンドユーザー |
| 幾つ | 1 | 1 | その他にもたくさんのグーグルの |
| 隠す | その下には何もない | 物理ストレージ | 無関係なデータ |
各レベルは独立して機能するわけではありません。マップによって接続されています。pingこれらは、データ独立性を実現するメカニズムです。
地図pingスキーマレベル間
地図ping これは、DBMSが隣接する2つのレベル間で保持する対応関係であり、上位レベルの要求を下位レベルのアクションに変換できます。3レベルアーキテクチャは2つのマップを使用します。pings:
- 概念図／内部マップping: 論理設計と物理ストレージを接続します。概念スキーマ内のエンティティと属性が、内部スキーマ内の格納レコードとファイルにどのように対応するかを定義します。ストレージが変更された場合、このマップのみが対象となります。ping 更新されます。
- 外部/概念マップping: 各ユーザービューを全体的な論理設計に接続します。ユーザーが見るフィールドが概念スキーマ内のエンティティとどのように関連しているかを定義します。論理設計が拡大すると、影響を受けるマップのみが変更されます。pings が更新されました。
これらの地図はping変更を吸収し、ユーザープログラムを書き換えることなくストレージを再編成できます。これはまさに データの独立性 このアーキテクチャは、以下のことを提供するように設計されています。
3段階スキーマの目標 Archi構造
3つのスキーマからなるアーキテクチャを採用する目的をいくつか挙げます。
- すべてのユーザーは同じデータにアクセスできるべきだが、それぞれカスタマイズされた表示方法を見ることができるべきである。
- ユーザーは、物理的なデータベースストレージの詳細を直接扱う必要はありません。
- データベース管理者は、ユーザーの表示を妨げることなく、データベースのストレージ構造を変更できる必要がある。
- ストレージの物理的な側面に変更が加えられた場合でも、データベースの内部構造は影響を受けないはずである。
データベーススキーマの利点
- 物理的なストレージとは独立してデータを管理できます。
- 新しいグラフィカル環境への移行がより迅速になります。
- その DBMSアーキテクチャ プレゼンテーションレベルで変更を加える際に、他の2つのレイヤーに影響を与えないようにすることができます。
- 各階層が独立しているため、異なる開発者チームを起用することが可能です。
- クライアントがデータベースのビジネスロジックに直接アクセスできないため、より安全です。
- いずれかの層が故障しても、他の層にアクセスすることで常にセキュリティが確保されるため、データ損失は発生しません。
データベーススキーマの欠点
- 完全なデータベーススキーマは複雑な構造であり、誰にとっても理解するのは困難です。
- 設定と維持管理が難しい。
- 階層の物理的な分離は、データベースのパフォーマンスに影響を与える可能性があります。
