3

パーツ注文アプリケーションをモデル化するためのデータベース (クラス用) を構築しています。「供給者」は部品を提供し (異なる供給者はそれぞれ同じ役割を果たす 1 つ以上の部品を供給し、すべての部品が 1 つの役割を果たします)、「管理者」は注文可能な部品を決定します (特定の役割を満たす部品は 1 つだけです)。注文可能)、ユーザーは部品を注文できます。

現在、ER図を描いている段階です。部品、役割、および注文品をモデル化する方法がわかりません。各注文可能/役割を (概念的な) 「顧客部品」エンティティとして表し、「サプライヤー部品」エンティティへの 2 つの関係を作成できます。

ここに画像の説明を入力

「Created by Trial Version」という文字があちこちにあるので非常にダサく見えますが、信じてください、チキンスクラッチの手書きよりはましです。

ただし、ここでは取り上げない重要な制約が 1 つあります。それぞれ 1 つの役割を果たす 2 セットのサプライヤ部品があるとします。パーツの各セット (各ロール) は、1 つの顧客パーツによって表されます。ただし、このモデルは、顧客部分が「注文」関係で正しい役割を果たす部分に対応することを保証するものではありません。

三項関係と集計でモデル化も試みましたが、まだすべての制約を把握できていません。

私の質問は次のとおりです。部品、役割、および注文品があります。役割と注文可能なものは 1 対 1 でマッピングされ、実際には 1 つのエンティティにマージできます。各部品が正確に 1 つの役割に関連付けられていること、各役割が正確に 1 つの注文可能なものに関連付けられていること、および各注文可能なものが正確に 1 つの部品に関連付けられていること、および各注文可能なものがその注文可能な役割に対応する役割にも関連付けられている正確に 1 つの部品に関連付けられていることをどのように表現すればよいですか?

お気づきの点がございましたら、よろしくお願いいたします。

4

2 に答える 2

2

私は少し急いでいるので、あなたの要求で迷ってしまったかもしれません. (しかし、それらをかなり明確に述べるために+1します。) 最初に簡単なことに取り組みましょう。ここでは主に自然キーを使用しています。なぜなら、自然キーを使用すると何が起こっているかを簡単に確認できるからです。あなたにとって本当に重要な部分は、オーバーラップしている外部キー制約 (終わり近く) だと思います。

簡単なもの - 部品、サプライヤー、役割のテーブル。

create table test.parts (
  part_num varchar(15) primary key
);

insert into test.parts values 
('Part A'), ('Part B'), ('Part C');

-- "Suppliers" provide parts.
create table test.suppliers (
  supplier_name varchar(35) primary key
);

insert into test.suppliers values
('Supplier A'), ('Supplier B'), ('Supplier C');

create table test.roles (
  role_name varchar(15) primary key
);

insert into test.roles values
('Role 1'), ('Role 2'), ('Role 3');

1 つの要件: すべてのパーツが 1 つの役割を果たすこと。(UNIQUE 制約の詳細と、単に「パーツ」に列を追加する代わりにこのテーブルを使用する方法については、後で説明します。)

create table test.part_roles (
  part_num varchar(15) primary key references test.parts (part_num),
  role_name varchar(15) not null references test.roles (role_name),
  unique (part_num, role_name)
);

insert into test.part_roles values
('Part A', 'Role 1'), ('Part B', 'Role 1'), ('Part C', 'Role 2');

もう 1 つの要件は、各サプライヤが同じ役割を果たす 1 つまたは複数の部品を提供することです。これは「各サプライヤーが複数の部品を供給する」と単純化できると思います。(パーツがどの役割に属しているかについての事実を格納することは、別のテーブルの責任です。)

create table test.supplied_parts (
  supplier_name varchar(35) not null 
    references test.suppliers (supplier_name),
  part_num varchar(15) not null references test.parts (part_num),
  primary key (supplier_name, part_num)
);

insert into test.supplied_parts values
('Supplier A', 'Part A'),
('Supplier A', 'Part B'),
('Supplier A', 'Part C'),
('Supplier B', 'Part A'),
('Supplier B', 'Part B');

もう 1 つの要件は、マネージャがどの部品を注文可能にするかを決定することです。(マネージャーは GRANT と REVOKE で処理します。) 指定された役割を果たす 1 つのパーツのみを注文できます。(これは、role_name に対する主キー制約または一意制約のいずれかを意味します。) また、誰かが部品を提供しない限り、部品を注文することはできません。(そのため、重複する外部キー制約が必要になります。)

ここで、先ほど述べた test.part_roles (part_num, role_name) の UNIQUE 制約の出番です。

create table test.orderable_parts (
  role_name varchar(15) primary key references test.roles,
  part_num varchar(15) not null,
  foreign key (part_num, role_name) 
    references test.part_roles (part_num, role_name),

  supplier_name varchar(35) not null,
  foreign key (supplier_name, part_num) 
    references test.supplied_parts (supplier_name, part_num)
);

insert into test.orderable_parts values
('Role 1', 'Part A', 'Supplier A'),
('Role 2', 'Part C', 'Supplier A');

part_roles の別のテーブルを使用したほうがよいと思います。(たとえば、部品に列を追加するよりも優れています。) サプライヤーは通常、現在関心のあるよりも多くの部品を供給しますが、企業は多くの場合、事前に計画を立てて、部品の使用を約束する前に部品に関する情報を収集したいと考えています (あなたの場合、特定の役割）。

于 2012-10-13T13:23:58.430 に答える
0 
suppliers
---------
PK supplier_id

parts -- 1-1 part to role
-----
PK part_id
FK role_id

stocks -- suppliers' parts
------
PK stock_id
FK supplier_id
FK part_id

roles
-----
PK role_id

managers
--------
PK manager_id

selections -- part selected by a manager for a role
----------
PK selection_id
FK manager_id
FK role_id
FK part_id

LEGEND: PK = Primary Key (assuming SERIAL PRIMARY KEY), FK = Foreign Key

テーブルの代わりに に追加するselectionsこともできます。FK part_idroles

于 2012-10-13T10:09:12.293 に答える