0

私はデータベースの学習に取り組んでいますが、私には意味をなさないと思われる何かについて確信が持てません。リレーショナル モデルでは、参照を通じて組み合わせることができますが、この情報を組み合わせるには、各テーブルにグローバル ソート キーが常に必要です。ほとんどの場合、これは明らかに必要ですが、データベースの完全なツリー階層のセットアップでは、これは非効率的だと思います。

これをよりよく説明するために、製品をデータベースに格納する例を使用します。製品にはメイン カテゴリとサブ カテゴリがあり、これらは非常に明確です。(つまり、牛乳は食品のサブカテゴリである乳製品のサブカテゴリです。)

このような場合、フィールド内のテーブルへの参照/ポインターの単一またはリストを格納する機能により、多くの検索クエリとストレージ要件が取り除かれると考えました。

これを説明するために私が作成した簡単なペイン レイアウトへのリンクを次に示し ます。そこにポインタ)

私は今データベースの操作を学んでいるので、この問題に関する知識が欠けている可能性があることは理解していますが、この問題をグーグルで検索しても何も見つからないようです. どこから始めるべきか、またはこれにより効率が向上する可能性があること、およびこれを自分で書く方法をどこで学べるかを説明する助けがあれば、すばらしいでしょう。

4

1 に答える 1

1

「ポインター」の概念は、ポイントしたいオブジェクトが、少なくともポインター自体と同じくらい永続的な明確に定義されたアドレスを持っている場合にのみ役立ちます。アドレスの永続性が低い場合、「ダングリング」ポインターになる可能性があります。

データベース内の行には、必ずしも永続的なアドレスがあるとは限りません。1 (物理アドレスではなく) 論理値を介して行を参照することにより、行が物理的に移動しても参照は有効なままになります。2また、値が正確に 1 つの行を識別するようにするには、一意である必要があります。3

単一のフィールド内に値のリスト (「ポインター」など) を格納することに関しては、これは原子性の原則に違反しているため、1NF に違反しています。参照整合性を維持し、インデックス作成を利用する機能など、1NF に違反しないようにする十分な理由があります。そうは言っても、1 つのフィールド内で配列やサブテーブルをサポートする DBMS があり、まれに役立つ場合があります。


1たとえば、Oracle ROWID は、行がディスク上で物理的に移動されない限り一定ですが、通常のデータベース操作の一部である多くの状況で発生する可能性があります。したがって、データベースの使用方法に厳しい制限を課すことは別として、ROWID を参照する行の存続期間 (データベース自体の存続期間と同じくらい長くなる可能性があります) にわたって ROWID が一定であることに依存することはできませんでした。

2理論的には、DBMS がすべてのポインタを追跡し、行が物理的に移動したときにそれらを更新することは可能だと思います。ただし、実際にそのような「更新可能な」ポインターを実際にサポートしている DBMS については知りません。おそらく、そのために必要な基本的なメカニズムが、標準の「値ベース」の参照よりも効率的ではないためです。

3そして、明らかに非 NULL でなければなりません。属性 (またはその組み合わせ) が「非 NULL で一意」であるということは、それが「キー」であるということと同義です。理想的には、キーも不変である必要があります (したがって、ON UPDATE CASCADE などのカスケード参照アクションは必要ありません)。

于 2013-04-14T15:17:21.480 に答える