a) UNIFORM — i) (7, Handkerchief, NULL): Yes — UCode 7 is new, UName given, UColor has no NOT NULL constraint. ii) (4, Ribbon, Red): No — UCode 4 already exists; duplicate primary key. iii) (8, NULL, White): No — UName is NOT NULL.

b) COST — i) (7, S, 0): No — Price must be > 0 (and there is no uniform 7 to price). ii) (9, XL, 100): by the printed constraints Yes — (9, XL) is a new composite-key value and 100 > 0; though logically odd, since no uniform 9 exists (it would be rejected only if UCode were also declared a foreign key to UNIFORM, which the given schema does not state). …

The declared constraints, as a CREATE TABLE (this is exactly what the printed schema states — note there is no foreign key declared on COST.UCode):

CREATE TABLE UNIFORM (
  UCode  INT PRIMARY KEY,       -- unique + NOT NULL
  UName  VARCHAR(20) NOT NULL,
  UColor VARCHAR(15)            -- no constraint: NULL allowed
);

CREATE TABLE COST (
  UCode INT,
  Size  VARCHAR(3),
  Price INT CHECK (Price > 0),
  PRIMARY KEY (UCode, Size)     -- composite key: the PAIR must be unique, neither part NULL
);

a) Inserting into UNIFORM

i) (7, 'Handkerchief', NULL) — YES, can be inserted.

UCode 7 does not occur among the existing codes 1–6 → primary key satisfied. UName is given ('Handkerchief') → NOT NULL satisfied. UColor is NULL — but UColor carries no constraint, and NULL simply records that the colour is unknown/unspecified. Every constraint passes.

ii) (4, 'Ribbon', 'Red') — NO.

UCode 4 already exists (Tie). The primary key must be unique; inserting a second tuple with key 4 violates entity integrity, and the DBMS rejects it with a duplicate-key error. (Ribbon would need a fresh code, e.g. 7 or 8.)

iii) (8, NULL, 'White') — NO.

UName has the NOT NULL constraint, and this tuple offers NULL for it. Rejected — every uniform must have a name.

b) Inserting into COST

i) (7, 'S', 0) — NO.

The Price constraint requires Price > 0, and 0 is not greater than 0 → the CHECK fails and the tuple is rejected. (The composite key (7, 'S') itself would have been fine — it's new. Also worth noting: no uniform with UCode 7 exists yet, so even if the row were priced correctly it would describe a non-existent product — see the note below.)

ii) (9, 'XL', 100) — YES, under the printed constraints.

Composite primary key (9, 'XL') does not occur in COST → unique, neither part NULL. Price 100 > 0 → CHECK satisfied. So all the constraints stated in the schema are met and the insertion is allowed. …