10

次の2つの違いしか見つけることができませんでした。

  1. ER モデルの関係は明示的に定義されますが、リレーショナル モデルでは暗黙的です。
  2. リレーショナル モデルでは、多対多の関係を実装する 2 つの外部キーを保持するために、中間テーブル (「ジャンクション テーブル」と呼ばれることが多い) が必要です。

ER図があるのに、なぜリレーショナルモデルを使用するのでしょうか?

4

2 に答える 2

13

あなたはそれを逆に持っています。

  1. ER モデルの関係は明示的に定義されますが、リレーショナル モデルでは暗黙的です。

いいえ。各リレーショナル モデル (RM) データベースのベース テーブルとクエリ結果は、アプリケーションの関係を表します。Entity-Relationship Modeling (E-RM) スキーマは、リレーショナル テーブルと制約を整理する (ただし、十分に使用されておらず、十分に指定されていない) (ただし誤解があります) 方法にすぎません。

  1. リレーショナル モデルでは、多対多の関係を実装する 2 つの外部キーを保持するために、中間テーブル (「ジャンクション テーブル」と呼ばれることが多い) が必要です。

いいえ。それはオブジェクト リレーショナル マッピング (ORM) アプローチであり、基礎となる単純なリレーショナル アプリケーションの関係、テーブル、および制約を覆い隠しています。「ジャンクション テーブル」の概念は、それ自体が RM を誤解している E-RM の混乱したプレゼンテーションの ORM の誤解から生じました。

CJ Date が述べたように、データベース システムの紹介、第 8 版:

[Chen の元の論文] を慈善的に読むと、E/R モデルは確かにデータ モデルであることが示唆されますが、基本的なリレーショナル モデル[p 426]の上の薄い層にすぎません。

シンプルすぎてもシンプルなソリューションが人気だというのは、IT 分野の現状に対する悲しいコメントです。[p 427]

リレーショナル モデル

すべてのリレーショナル テーブルは、アプリケーションの関係を表します。

-- employee EID has name NAME and ...
E(EID,NAME,...)

そのようなもの、およびそれを表す数学的順序付きタプル セットの数学用語は、「関係」です。したがって、「リレーショナルモデル」(および「エンティティ関係モデリング」) です。数学では、関係はパラメータ化されたステートメント テンプレートによって記述されることが多く、その 1 つの数学用語が「特性述語」です。述語のパラメーターは、テーブルの列です。RM では、DBA が各ベース テーブルの述語を指定し、ユーザーは列の値と述語から真のステートメントを作成する行をテーブルに配置し、偽のステートメントを作成する行を除外します。

/* now also employee 717 has name 'Smith' and ...
    AND employee 202 has name 'Doodle' and ...
*/
INSERT INTO E VALUES (EID,NAME,...)
    (717,'Smith',...),(202,'Doodle',...)

クエリ式には、関係演算子と論理演算子 (条件内) から構築された述語もあります。また、その値は述語を真にする行を保持し、偽にする行を除外します。

/* rows where
   FOR SOME E.*, M.*,
        EID = E.EID AND ... AND MID = M.MID
   AND employee E.EID has name E.NAME and ...
   AND manager M.MID has 
   AND E.DEPT = M.DEPT AND E.NAME = 'Smith'
/*
SELECT E.*, M.MID
FROM E JOIN M ON E.DEPT = M.DEPT
WHERE E.NAME = 'Smith'

真のステートメントを作成する表の現在の行と、誤ったステートメントを作成する不在の行は、データベース内の申請状況についてどのように記録し、データベースが申請状況について何を言っているのかを解釈する方法です。述語、つまり適用関係を理解し​​なければ、データベースを使用したり解釈したりすることはできません。

エンティティ関係モデリング

E-RM (RM を実際には理解していない) は、本質的に、リレーショナル データベース (の一部) (の限定された形式) を記述するための (不必要で、制限された、限定的な) 図式表記法です。もともと、候補キー (CK) 値がアプリケーション エンティティと他の列 (「エンティティ」の「プロパティ」) と 1:1 である「エンティティ (クラス)」アイコン/関係があり、「関係 (クラス)」アイコンがありました。複数のエンティティとその他のもの (「関連」の「プロパティ」) のアプリケーション関係を表すエンティティ テーブルへの外部キー (FK) を持つ / テーブル。アプリケーション関係は、関係するさまざまなエンティティ アイコンへの線を含むアイコンで表されました。(つまり、線は FK を表しています。

E-RM はリレーショナル モデルを認識しません。アプリケーション エンティティと関係との間に、無意味で誤解を招くような違いがあります。結局のところ、すべてのベース テーブルまたはクエリ結果のすべてのスーパーキー(一意の列セット) は、エンティティ テーブルを持つエンティティだけでなく、何らかのアプリケーション エンティティと 1 対 1 で対応しています。たとえば、人々は結婚することで関連付けることができます。しかし、そのような各関連付けは、結婚と呼ばれるエンティティと 1 対 1 で行われます。これにより、不適切な正規化と制約が発生し、冗長性と完全性が失われます。または、これらの手順が適切に実行されると、実際にはリレーショナル データベースの述語、テーブル、および制約によって記述されるアプリケーションを記述していない ER ダイアグラムにつながります。その場合、ER図はあいまいで、冗長で、間違っています。

短縮形の E-RM と ORM

E-RM であると主張するプレゼンテーションや製品の多くは、RM は言うまでもなく、E-RM をゆがめます。彼らは「関係」という言葉を使用して、FK 制約を意味します。これは次のように発生します。E-RM 関係がバイナリの場合、FK への 2 つの行を持つシンボルです。したがって、これら 3 つのことは、FK 間の 1 行に置き換えることができます。この種の線は、特定の 2 項関係とその FK を表しますが、現在、ER 関係は図では明示されていませんが、ER 関係は手書きバージョンで明示されており、図が の写真である表に反映されています。彼らが説明しているリレーショナルデータベース。これは「ジャンクション テーブル」と呼ばれます。そして、人々はその線/表が「X:Y 関係」である/表すことについて話します。それが特定のアプリケーション関係であることに実際に気付くことはありません。また、同じ 2 つのエンティティおよび/または関連付けの間に、そのようなアプリケーション関係が多数存在する可能性があります。

ORM もこれを行いますが、関連するアプリケーションの関係とテーブルがさらにわかりにくくなるように、n 項の関連付けを FK だけに置き換えます。Active Records は、複数の短縮形の関係とそれらのテーブルを一度に定義することで、さらに先へ進みます。これは、手書きの E-RM ダイアグラムの一連の FK 線と関連アイコンに相当します。これは、E-RM や ORM のバージョンを含む多くのモデリング手法によって悪化し、アプリケーションの関係はバイナリにしかならないと考えられています。繰り返しますが、これは歴史的にRMの理解の欠如から生じました。

于 2014-12-03T12:44:19.493 に答える
2

それらは、それ自体が 2 つの異なるものです。リレーショナル モデルは、リレーショナル スキーマに直接マップされたタプルとして情報を表します。ガイドラインは関係代数に由来します。

一方、ER ダイアグラムは、エンティティを使用してシステム内のユーザーとその基になるデータとの関係をモデル化します。ER ダイアグラムはリレーショナル モデルにマッピングでき、最終的に作業スキーマにマッピングできます。

于 2014-12-03T10:13:00.227 に答える