 <blockquote> <p>product_size alone will not be a PK and so I cannot reference it</p> </blockquote> <p>Imagine you have two rows in <code>product_stock</code> table that have the same <code>product_size</code> (and different <code>product_code</code>). Now imagine one of these rows (but not the other) is deleted. </p> <ul> <li>Should that be restricted because there are <code>orderline</code> rows that reference it? </li> <li>Or should it be allowed because there still exists the other <code>product_stock</code> row, that <code>orderline</code> rows <em>also</em> reference?</li> </ul> <p><em>(Similar problems exist for ON DELETE CASCADE / SET NULL and also when UPDATE-ing the PK.)</em></p> <p>To avoid these kinds of ambiguities, the DBMS won't let you create a foreign key unless you can uniquely identify parent row, meaning you must use the <strong>whole</strong> key after the REFERENCES clause of your FK.</p> <hr> <p>That being said, you could create both...</p> <pre><code>FOREIGN KEY (product_code) REFERENCES product (product_code) </code></pre> <p>...and...</p> <pre><code>FOREIGN KEY (product_code, product_size) REFERENCES product_stock (product_code, product_size) </code></pre> <p>Although, if you have the latter, the former is <em>probably</em> redundant.</p> <p>In fact, (since you already have the FK <code>product_stock -&gt; product</code>), having both FKs would create a "diamond shaped" dependency. BTW, some DMBSes have restrictions on diamond-shaped FKs (MS SQL Server doesn't support cascading referential actions on them).</p>