The Relation Vendor Order (V_no, V_ord_no, V_name, Qty_sup, unit_price) is in…

Concept: A relation is in Second Normal Form (2NF) when it is already in 1NF and every non-key attribute is fully functionally dependent on the entire primary key. A non-key attribute that depends on only part of a composite primary key (a partial functional dependency) means the relation VIOLATES 2NF, not that it satisfies it.

Application: Vendor Order(V_no, V_ord_no, V_name, Qty_sup, unit_price) is conventionally read with the composite primary key (V_no, V_ord_no). Under this key, V_name (vendor name) depends only on V_no, which is part of the composite key — a partial dependency. Qty_sup and unit_price each relate to a specific vendor-order pairing and depend on the whole (V_no, V_ord_no) key. So the relation contains one partial dependency, V_name on V_no, and by the concept above, that dependency means the relation is NOT in 2NF as it stands.

Cross-check (decomposition): Removing the partial dependency confirms it existed.

1. Create Vendor(V_no, V_name), where V_no is the whole primary key and V_name depends on it fully.

2. Create VendorOrder(V_no, V_ord_no, Qty_sup, unit_price), with composite primary key (V_no, V_ord_no) and no remaining partial dependency.

Each resulting relation now satisfies 2NF, which confirms that the original single relation did not — the partial dependency had to be removed by decomposition.

Why the other statements do not hold:

• "Non-key attribute V_name is dependent on Qty_sup" — Qty_sup is not part of the composite primary key (V_no, V_ord_no), so a dependency of V_name on Qty_sup, even if it existed, would not be a partial dependency on the key; the schema’s declared attributes give no basis for this dependency at all.

• "Key attribute Qty_sup is dependent on primary key unit_price" — Qty_sup is not part of the composite primary key (V_no, V_ord_no), and unit_price is not the primary key; both halves of this statement misdescribe the schema.

• "Key attribute V_ord_no is dependent on primary key unit_price" — V_ord_no is indeed part of the composite primary key, but unit_price is not the primary key, so the dependency direction and the key attribution here are both wrong.

Note on the exam’s answer key: For this UGC NET June 2015 Computer Science item, the examination’s own published final answer key assigns the answer as the option stating that a non-key attribute V_name is dependent on V_no, which is part of the composite key — matching the answer recorded here, with no bonus or drop announced for this item. That said, evaluated strictly against the 2NF definition above, this same statement describes a PARTIAL dependency, which is textbook evidence of a 2NF VIOLATION rather than proof that the relation satisfies 2NF — a mismatch between the stem’s framing (“is in 2NF because”) and the logic of its own official key that discussions of this item have long pointed out. None of the remaining options describes a dependency that actually holds in this schema either, so the official key remains the best-supported choice among those offered even though, strictly, it evidences a violation rather than a proof of 2NF. This platform records the official key for continuity with the source exam while making that underlying inconsistency explicit above.