38

1つのテーブルのPKをFKとして他のテーブルに追加することにより、1対多の関係を実装します。2つのテーブルのPKを3番目のテーブルに追加することにより、多対多の関係を実装します。

IS-A関係をどのように実装しますか？

エンティティは技術者と管理者であり、どちらも従業員です。テーブルEMPLOYEE（id、name、surname、role、... AdminFields ...、... TechFields ...）で追加のフィールドを使用できます。

しかし、私はIS-Aオプションを探求したいと思います。

編集：私はドニーが提案したようにしたが、役割フィールドはなかった。

4

8 に答える 8

29

私はドニーが提案したようにやりましたが、物事を複雑にするため、役割フィールドはありませんでした。これが最終的な実装です。

DDL：

CREATE TABLE Employee (
ast VARCHAR(20) not null,
firstname VARCHAR(200) not null,
surname VARCHAR(200) not null,
...
PRIMARY KEY(ast)
);

CREATE TABLE Administrative (
employee_ast VARCHAR(20) not null REFERENCES Employee(ast),
PRIMARY KEY(employee_ast)
);

CREATE TABLE Technical (
employee_ast VARCHAR(20) not null REFERENCES Employee(ast),
...
PRIMARY KEY(employee_ast)
);

ER図：

ERD

このモデルには、ジェネリック型の従業員は存在しません。ここでは、従業員は管理者または技術者のみになります。

于 2011-01-12T09:09:50.680 に答える
8

IS-A関係は、gen-specデザインパターンとも呼ばれます。Gen-specは「一般化スペシャライゼーション」の略です。

gen-specのリレーショナルモデリングは、gen-specのオブジェクトモデリングとは異なります。これは、リレーショナルモデルに継承が組み込まれていないためです。

これは、テーブルのコレクションとしてgen-specを実装する方法を示す良い記事です。

http://www.javaguicodexample.com/erdrelationalmodelnotes1.html

特殊なテーブルで主キーを設定する方法に特に注意してください。これが、これらのテーブルの使用を非常に簡単にする理由です。

googlin「一般化特殊化リレーショナルモデリング」によって他の多くの記事を見つけることができます。

于 2010-12-06T08:58:12.213 に答える
7

私はいつもこれをroleフィールドで行い、次にオプションの関係で行いました。

つまり、テーブルEMPLOYEE (id, ...generic fields... , role)

そして、役割ごとに：

テーブルROLE1 (employeeid, ...specific fields...)

これにより、1回のクエリで一般的な従業員情報を取得でき、役割固有の情報を取得するには結合が必要です。これの1つの（大きな）欠点は、すべての役割情報を含む1つのスーパーレポートが必要な場合、多数の外部結合でスタックすることです。

于 2010-12-05T21:45:18.927 に答える
5

リレーショナルバックエンドデータベースに接続する必要のあるオブジェクト指向アプリケーションがある場合は、MartinFowlerのエンタープライズアプリケーションアーキテクチャのパターンを入手することをお勧めします。

彼はまた彼のウェブサイトにいくつかの関連するメモと図を持っています。具体的には、単一テーブル継承、クラステーブル継承、および具象テーブル継承のパターンは、データテーブルにIS-Aをマッピングするための3つの戦術を記述しています。

HibernateまたはJPAを使用している場合、名前は異なりますが、これらすべてのマッピングをサポートします。

この特定の例では、IS-Aはまったく使用しません。

従業員の役割のようなものは、HAS-Aとしてより適切にモデル化されます。

  1. 1人の人に複数の役割を持たせたい場合があります。
  2. 人の役割を変更する方が簡単です。
于 2010-12-05T22:37:57.950 に答える
3

このホワイトペーパーでは、一般化をスキーマ設計にマッピングするためのいくつかの戦略について説明します。

http://www.sztaki.hu/conferences/ADBIS/3-Eder.pdf

要約のコピー：

オブジェクトリレーショナルデータベースのより豊富なデータモデルは、データベーススキーマの論理設計のためのより多くのオプションを開き、論理データベース設計の複雑さを大幅に増大させます。概念モデルの一般化構造に焦点を当て、一般化をオブジェクトリレーショナルデータベースシステムのスキーマにマッピングするためのさまざまな設計代替案のパフォーマンスへの影響を調査します。

于 2010-12-05T22:42:25.043 に答える
2

これを1対0/1のテーブル関係として実装してみませんか？VehicleIDの主キーを持つVehicleという基本クラスを表すテーブルがあるとします。次に、Vehicleのすべてのサブクラスを表す任意の数のサテライトテーブルを作成できます。これらのテーブルには、Vehicle->Subclassから1->0/1の関係を持つ、主キーとしてVehicleIDもあります。

または、単純にしたい場合で、サブクラスが数個しかなく、変更される可能性がほとんどないことが確実にわかっている場合は、構造全体を1つのテーブルで識別子タイプフィールドで表すことができます。 。

于 2010-12-05T21:54:39.253 に答える
1

ほとんどのORMは、単一の列識別子を使用してIS-A関係を実装し、特定の列の値に基づいてインスタンス化するサブクラスを選択します。あなたの例に関しては、あなたはおそらく実際には役割を意味していません。なぜなら、通常、人は多くの異なるタイプの役割を果たすことができるからです。役割は通常、has-a関係としてモデル化されます。is-関係（またはサブクラス化）を使用してそれを実装しようとすると、必然的に、ハイブリッドポジションを埋める人がいる場合を処理するために、より複雑なことをしなければならないことになります-つまり、ローカルとしても機能する秘書IT担当者、両方の権限または属性が必要です。

于 2010-12-05T21:51:56.007 に答える
1

モノ階層を構築するのか、ポリ階層を構築するのかによって異なります。これはハードコードされたデザインであり、あなたが望んでいたものだと私は信じています。

モノ（子テーブルには1つの親テーブルがあります）の場合、子は親であり、FKとPKは子テーブルで同じであり、そのキーは親テーブルのPKでもあります。

子IS-A親-1と子IS-A親-2であるpoly（子テーブルに複数の親テーブルがある）の場合、複合キー（テーブルレコードを一意にするための複数の主キーを意味する）があり、ルール各キーの単一階層と同じです。

于 2013-12-05T19:56:52.093 に答える