DBMSにおけるデータの独立性
- はじめに
- データの独立性とは何ですか?
- データの独立性の種類
はじめに
今日は、データベース管理システムの最も重要なトピックの一つ、すなわちデータの独立性を取り上げます。 3つのレベルのデータ抽象化を実装する理由は、データの独立性を達成することに他なりません。 データの独立性は、さまざまなレベルのスキーマで行われる変更を扱うものです。 データの独立性の意味とは別に、ここでその必要性とそのタイプについて学びます。 だから、私たちはそれ以上の騒ぎを始めることができます!
データの独立性とは何ですか?
我々はすでに二つの用語”データ”と”独立性”を別々に精通しているので、多かれ少なかれ同じ意味で”データ独立性”という用語全体の意味を解読することがで この用語自体から、データベースに存在するデータの独立性について話していることは明らかです。 技術的に言えば、”データの独立性は、ユーザーが次の上位レベルでスキーマ定義を変更する必要なしに、あるレベルでスキーマ定義を変更できるDBMSの特性です”。 あるレベルで変更を行っているときに、他のレベルを妨げないことが非常に必要です。 正確には、データの独立性とは、データベースアーキテクチャの3つのレベルに存在するデータの独立性または自立性を指します。 また、それはそれを利用して、アプリケーションプログラムから分離されたデータを維持するのに役立つものです。 これは、集中型データベース管理システムが非常に関心を持っているデータの透明性の一種と見なされることがよくあります。
データの独立性のより深い側面を調べる前に、データベースのレベルを簡単に思い出してみましょう。 内部または物理スキーマは、メモリレベルでもデータベースと直接接続されている最初のレベルです。 第二は、第三のレベルと第一のレベルの間の仲介者として機能する概念的または論理スキーマです。 第三のレベルは、データベースが複数のエンドユーザーにどのように表示されるかを指示する外部スキーマです。 ライブラリデータベースのインスタンスを想定すると、これらの3つのレベルの実装は次のようになります:
内部スキーマ | 論理スキーマ | 外部スキーマ |
データベースの関係の順不同ファイル最初の列訪問者のインデックス | 訪問者(id:int、名前:string、年齢:int、連絡先:数値、住所:string)書籍(id:int、タイトル:string、著者:string、isbn:数値) | View1: BookRecords(b_id:int,b_name:string,author:string)View2:VisitorRecords(v_id:int,v_name:string) |
データの独立性は、APIからデータを分離し、レベル間マッピングのいずれかのレベルで行われた変更を実装します。 これは、データベースのこれらの個々のレベルの自由を同時に維持するのに役立ちます。 ある観点から、データの独立性と操作の独立性は、DBMS内のデータ抽象化現象を一緒に引き出します。DBMSでデータの独立性を実現するには?
データの独立性を取得するために、データベースがデータ抽象化の必要条件を満たしていることを確認します。 簡単に言えば、データ抽象化とは、無関係な詳細をエンドユーザーから隠さないようにするプロセスです。 現実世界の実体に関して考えると、車の例を取ることができます。 ドライバーが車を運転するとき、彼は車を運転する完全なノウハウを持っていますが、何らかの理由で車を始めることができない場合、彼は車の整備士 ドライバーは車を運転する方法を知っているので、それはそうです、彼は内部回路の問題に対処する方法を知らない、車の内部回路とメカニズムである 同様に、内部構造はプログラマやエンドユーザーには見えません。 データベース内の可視性を制限するこのプロパティは、データ抽象化と呼ばれます。 データベースは、3つのレベルの抽象化を保持します。 これらの3つのレベルを以下に示します:
- 物理レベル(内部スキーマ)
- 概念レベル(論理レベル)
- ビューレベル
データ抽象化の物理レベルは、内部スキーマの世話をします。 このレベルの抽象化は、データベース内のデータの格納方法を定義します。 これは、エンドユーザーやプログラマが興味を持っていないデータベースの詳細で複雑なデータ構造を格納します。 また、データ抽象化の最低レベルとも考えられています。
データ抽象化の中間レベルである概念的レベルは、スキーマの論理レベル用です。 前のレベルは、質問に答えます”どのように?’. 同様に、このレベルは質問に答えます”なぜですか?”データベースに格納されているデータの種類と種類を説明します。
データ抽象化の最後のレベルと最高レベルはビューレベルです。 このレベルは、異なるn人のユーザーがデータをどのように表示するかを示します。 これは、データベースとのユーザーの対話を担当します。
店舗の顧客の詳細を保存した非常に低いスケールの例を見てみましょう。 したがって、物理レベルについて話すと、データはバイト、ギガバイト、テラバイトなどのメモリブロックとして格納されます。 基本的には、複雑なメモリストレージを扱います。 この情報はプログラマには表示されません。 論理レベルには、入力された顧客の詳細とそのデータ型が記述されます。 論理的な関係は、プログラミング言語を使用してこのレベルのデータ間で実装されます。 このレベルは主にプログラマによって処理されます。 ビューレベルでは、ユーザーはGUIを介してシステムと対話して、フォーム形式またはその他のセット形式でデータを入力します。 さて、各レベルは他のレベルから独立していなければならないので、あるレベルで変更を加えるときに、次のより高いレベルで変更を加える必要はあ そして、これはデータの独立性が何をするかです。
これらの3つのレベルのデータ抽象化を維持するために、データベースの1つのレベルで変更を加える必要があるかもしれませんが、これはデータの独立性ではないにしても大きな手間になる可能性があります。 あなたは、物理スキーマのわずかな変更を反映するようにアプリケーションプログラム全体を変更することは、時間とプログラミングの面で私たちの データの独立性により、あるレベルで変更を実行しても、データベースの他のレベルに影響を与えないことが保証されます。 データ抽象化の3つのレベルに基づいて、データの独立性は2つのタイプに分岐します。
データの独立性の種類
私たちは、データの独立性の二つのタイプとそのプロパティについて学びましょう。 二つのカテゴリは次のとおりです:
- 物理データの独立性
- 論理データの独立性
物理データの独立性: 物理データの独立性の下では、アプリケーションプログラムを変更することに縛られることなく、物理スキーマを変更する自由が得られます。 内部レベルをデータベース構造の概念的レベルから分離する責任があります。 物理データの独立性を使用すると、データベースの論理構造の詳細を指定する必要はなく、データベースの論理的な説明または概要を提供できます。 物理データの独立性に応じて、内部レベルで行われた変更は、概念レベルまたはビューレベルスキーマの定義を変更することは想定されていません。
物理的な独立性を使用すると、ファイルストレージ構造、ハッシュアルゴリズム、圧縮技術、ストレージデバイス、データベースの場所、アクセス方法、インデックスなどを変更できます。 したがって、基本的には効率的なメモリ記憶技術の実装を扱います。 このレベルで行われた変更は、データベースの内部レベルと概念的レベルの間のマッピングに適用されます。 導入された変更はローカライズする必要があることに注意してください。 物理的なデータの独立性は、物理的なレベルによって達成され、その後、データベースの概念レベルから内部レベルへの変換が実行されます。
メモリ管理の観点から、DBMSのパフォーマンスを向上させるために内部レベルを更新する必要があることがあります。 したがって、物理的なデータの独立性は、私たちの要件に応じてストレージ技術を変更することが効率的なDBMSが起こりやすいものであるという事実に基づ
論理データの独立性: 論理データの独立性により、外部ビューや外部プログラムやAPIを変更することなく、スキーマの概念レベルを自由に変更できます。 このレベルで行われた変更は、論理ビューレベルマッピングと終了ビューレベルマッピングに適用されます。 アプリケーションプログラムは概念レベルに大きく依存しているため、物理データの独立性と比較して論理データの独立性を達成するこ データベースの論理構造に小さな変更や大きな変更がある場合は、プログラムも変更する必要があります。 したがって、論理データの独立性を実現することはかなり困難です。 論理データの独立性は、エンドビューレベルと概念的レベルとの間の分離を制御します。
論理データの独立性により、属性、エンティティ、またはリレーションシップの追加、変更、削除などの変更を行うことができます。 このような変更を行うことは、アプリケーションプログラムを書き換えることを要求するのではなく、プログラムに対応する変更を加えることを要求するものではありません。 これは、外部層に影響を与えることなく、一つに二つのレコードをマージすることができます。 既存のレコードを2つに分割したい場合は、特定のデータベースのエンドユーザビューレベル構造に干渉することなく可能です。
DBMSを最新の状態に保つためには、概念的なレベルを適時に変更することが不可欠です。 これが、論理データの独立性が重要な役割を担っていると言われている理由です。 これは、DBMSのパフォーマンスと速度を向上させるだけでなく、データベースをより使いやすく、より信頼性の高いものにするのに役立つことが判明しました。
データの独立性の利点
データの独立性は、データベース管理システムの最も重要な特性の一つであることになると、議論の余地のない足場にあります。 DBMSでのデータの独立性の必要性を正当化する理由はいくつかあります。 そこで、DBMSのニーズを満たす利点を見てみましょう。
- データの品質–データの独立性は、データベースに格納されているデータの品質を高めるのに役立ちます。 データ独立性によりデータベース構造の変更がより便利になるため、データストレージが効率的になります。 それは分割されていないか、または損なわれていない状態の強化を促進する。 したがって、格納されたデータの品質の向上をもたらす。
- 費用対効果の高いメンテナンス-データの独立性により、ある回路図レベルで変更が必要な場合に、データベースのすべての回路図レベルを変更する手間 それによって、私たちのデータベースを維持することは素晴らしい程度に手頃な価格になります。
- セキュリティの側面–データベースを保護するための標準とプロトコルの適切な施行が容易になります。 したがって、データの独立性は、データベースのセキュリティを向上させるのに役立ちます。
- 一般的な構造に焦点を当てた開発者:開発者は、内部移植について気にすることなく、論理構造の処理と更新に専念できます。 変更は、概念レベルと内部レベルマッピングによって直接吸収されます。
- データの違和感の軽減–データの独立性は、互換性を高めるためにデータベース構造を変更することをサポートします。 これは、データの違和感を制御するのに役立ちます。
- パフォーマンスの向上–データの独立性は、データ抽象化の原因に燃料を供給します。 その上、それは新しい変更の滑らかな実施を促進します。 その結果、データアクセス、検索、またはデータ変更は迅速かつ便利になります。 これは、データの独立性がデータベースのパフォーマンスを向上させるのに役立つことが証明されている方法です。
上記の点から、データ独立性のメリットを強調して推測できるように、データ独立性は、ファイルベースのシステムの欠点を克服するDBMSの武器の一つとな これは、スキーマ定義とデータ編成で行われた変更に対するユーザーアプリケーションの耐性と見なすことができます。 すべてのコインには2つの顔があり、これも同じです。 データベースの信頼性とセキュリティを得るための鍵であるデータの独立性についてかなり確信しているので、その暗い側面について疑問に思う必要が 次に、データの独立性を扱う際に一般的に遭遇する2つの大きな欠点があることをお伝えしましょう。 最初のものは、データの独立性を採用することに伴う複雑さの増加です。 データベースは、データの独立性を最適に使用するように慎重に設計する必要があります。 第二の欠点は、前者に関連している。 アプリケーション-プログラムは、データの論理スキーマに大きく依存します。 したがって、概念構造を変更するには、それぞれのアプリケーションプログラムを変更する必要があります。
このブログがデータの独立性に適切な光を投げ、DBMSに関する知識に価値を加えることができたことを願っています。 データの独立性とは別に、データベースに大きな影響を与えるいくつかの要因があります。 DBMSのこのような関連するトピックを十分に把握するには、偉大な学習の他のブログを参照することができます。 お楽しみにして、私たちと一緒にあなたの学習の旅を続けてください。 あなたは、証明書を獲得するの罰金チャンスとDBMS上のクラッシュコースを選ぶことを好むかもしれません。 私たちは、いずれかまたは別の方法であなたの利益になる多数の認定コースを持っています。 だから、あなたは他に何を待っていますか? 行くと、ここで新しいコースのために自分自身を登録! 幸せな学習!
Leave a Reply