Each anomaly is fixed with one DDL/DML statement (MySQL syntax):

-- a) rename the relation PRICE to COST
ALTER TABLE PRICE RENAME TO COST;

-- b) insert the handkerchief record (new UCode 7, medium, Rs 100)
INSERT INTO COST (UCode, Size, Price) VALUES (7, 'M', 100);

-- c) allow a COST row only if its UCode exists in UNIFORM (foreign key)
ALTER TABLE COST
  ADD CONSTRAINT fk_cost_uniform FOREIGN KEY (UCode) REFERENCES UNIFORM(UCode);

-- d) a new UCode needs a valid UName
ALTER TABLE UNIFORM MODIFY UName VARCHAR(20) NOT NULL;

-- e) price must always be greater than zero
ALTER TABLE COST ADD CONSTRAINT chk_price CHECK (Price > 0); …

a) Rename the relation PRICE to COST

Having a table named PRICE with a column also named Price is confusing, so:

ALTER TABLE PRICE RENAME TO COST;

Why: ALTER TABLE changes a table's definition; the RENAME TO clause changes its name without touching the data. (MySQL also accepts RENAME TABLE PRICE TO COST; — same effect.) All 16 rows are preserved; only the name changes.

b) Insert the handkerchief record

Handkerchief is a new item, so it needs a fresh code — the highest existing UCode is 6, so we use 7. COST stores only (UCode, Size, Price):

INSERT INTO COST (UCode, Size, Price)
VALUES (7, 'M', 100);

COST now additionally contains:

Notice the anomaly: the name "Handkerchief" and colour "Red" have nowhere to go in COST — they belong in UNIFORM, where no UCode 7 exists yet. The database happily accepted a price for an item it knows nothing about. That is exactly the problem part (c) fixes.

c) COST rows only for items that exist in UNIFORM — a FOREIGN KEY

A referential-integrity (foreign key) constraint makes the DBMS reject any COST row whose UCode is absent from UNIFORM:

ALTER TABLE COST
  ADD CONSTRAINT fk_cost_uniform
  FOREIGN KEY (UCode) REFERENCES UNIFORM(UCode);

Why the order matters: the handkerchief row (UCode 7) inserted in (b) is currently an orphan — adding the constraint would fail while it violates the rule. So first make the data consistent by registering the item:

INSERT INTO UNIFORM (UCode, UName, UColor)
VALUES (7, 'Handkerchief', 'Red');

After that, the ALTER TABLE succeeds, and from then on any INSERT into COST with an unknown UCode is rejected with a foreign-key error.

d) A new UCode only with a valid UName — NOT NULL

An item without a name is meaningless, so forbid empty names at the schema level:

ALTER TABLE UNIFORM
  MODIFY UName VARCHAR(20) NOT NULL;

Why: MODIFY redefines the column, and NOT NULL makes the DBMS reject any UNIFORM row that omits UName. Combined with (c), a price can now exist only for a coded item, and a coded item must carry a name. …