With the right structure, Jet can guarantee that, if a row exists in a
subtype table, there won't be corresponding rows in any other subtype
table.  

So if I have a complaint (supertype) about quality (subtype), Jet can
guarantee the subtype data--*if* it exists--will be found only in the
subtype table "Quality".  But Jet can't guarantee that subtype data
will exist.  The best support for this kind of stuff requires an
engine that lets you defer constraint checking until the end of a
transaction.

You have to store a code for the subtype in the supertype, but you'd
do that anyway.  (In relational literature, the terms are "supertype"
and "subtype"; "superclass" and "subclass" are something else.)

The ugly part is the UNIQUE constraint on the PK and subtype column in
the first table.  You have to have it in order to enforce a foreign
key constraint in the second table.

(air code)

CREATE TABLE Complaint (
 Complaint_Num INTEGER,
 Complaint_Type VARCHAR(8),
 -- other columns
 CONSTRAINT Complaint_PK
   PRIMARY KEY (Complaint_Num),
 CONSTRAINT Complaint_Unique
   UNIQUE (Complaint_Num, Complaint_Type)
);

CREATE TABLE Quality (
 Complaint_Num INTEGER,
 Complaint_Type VARCHAR(8),
 -- other columns
 CONSTRAINT Quality_PK
   PRIMARY KEY (Complaint_Num),
 -- This foreign key constraint requires a unique index
 -- on these two columns in the referenced table.
 CONSTRAINT Quality_only
   FOREIGN KEY (Complaint_Num, Complaint_Type)
   REFERENCES Complaint (Complaint_Num, Complaint_Type)
);

Now open the table "Quality" in design view, select the column
"Complaint_Type", and use the one-word expression "quality" (including
the quotes) as its validation rule.  Now you can

INSERT INTO Complaint VALUES (1, 'quality')
INSERT INTO Quality VALUES (1, 'quality')

You need some other constraints, too.  But this illustrates how to
guarantee only one subtype row per supertype row.