Model database to represent constraints - database

Question

I'm building a database (for a class) to model a parts ordering application. "Suppliers" provide parts (different suppliers may each supply one or more parts that fulfill the same role, and every part fulfills exactly one role), "managers" decide which parts are going to be orderable (only one part that fulfills a given role can be orderable), and users can order the parts.
I'm currently in the E-R diagram drawing stage. I'm not sure how to model the parts, roles and orderables. I can represent each orderable/role as a (conceptual) "customer part" entity and create two relationships to the "supplier parts" entity:
That looks tremendously tacky with the "Created by Trial Version" all over it, but believe me, it's better than my chicken scratch handwriting.
However, there is one crucial constraint that would not be captured here. Imagine that you have two sets of supplier parts that fulfill one role each. Each set of parts (each role) would be represented by one customer part. However, the model does not guarantee that the customer part would correspond to a part that fulfills the correct role in the "orders" relationship.
I have also tried modelling it with a ternary relationship and an aggregation, but I still can't capture all the constraints.
My questions boils down to: I have parts, roles, and orderables. Roles and orderables map 1-1 and onto and can really be merged into a single entity. How do I represent that each part is associated with exactly one role, each role is associated with exactly one orderable and vice versa, and each orderable is associated with exactly one part that is also associated with the role corresponding to that orderable?
Thank you for any insights you may have.

Answer 1

I'm in a bit of a hurry, and I might have gotten lost in your requirements. (But +1 for stating them fairly clearly.) Let's tackle the easy stuff first. I'm mostly using natural keys here, because natural keys make it easier to see what's going on. The really important part for you, I think, is the overlapping foreign key constraints (near the end).
The easy stuff--tables for parts, suppliers, and roles.
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');
One requirement: Every part fulfills exactly one role. (More about the UNIQUE constraint, and about using this table instead of simply adding a column to "parts" later.)
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');
Another requirement--each supplier may supply one or more parts that fulfill the same role. I think this simplifies to "Each supplier supplies multiple parts." (Storing the facts about which role a part belongs to is a different table's responsibility.)
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');
Another requirement--managers decide which parts are going to be orderable. (Handle the managers with GRANT and REVOKE.) Only one part that fulfills a given role can be orderable. (That implies either a primary key constraint or a unique constraint on role_name.) And you can't order a part unless someone supplies it. (So we'll need overlapping foreign key constraints.)
This is where the UNIQUE constraint on test.part_roles (part_num, role_name) I mentioned earlier comes in.
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');
I think you're probably better off with a separate table of part_roles. (Better than adding a column to parts, for example.) Suppliers usually supply more parts than you're interested in today, but businesses often want to plan ahead, gathering information about parts before they commit to using them (in your case, in a particular role).

Answer 2

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
Instead of the selections table you could also add FK part_id to roles.