Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>++ For the answers above.</p> <p>You should start thinking about the <em>keys</em> of these tables now. Each table should have <em>something</em> that will serve to uniquely identify a row -- done sensibly this will ensure that you can't get duplicate rows which would mess up your data.</p> <p>Here's a really simple example.</p> <pre><code>CREATE TABLE Parts ( [PartNumber] INT , [PartDescription] VARCHAR(50) ) </code></pre> <p>The PartNumber column would make a really good PRIMARY KEY (Assuming that no two parts thet you will ever have would have the same PartNumber) A property that uniquely defines a row and has meaning in and of itself is an example of a NATURAL KEY</p> <pre><code>CREATE TABLE Kits ( [KitNumber] INT , [KitDescription] VARCHAR(50) ) </code></pre> <p>Again -- KitNumber would be a good primary key. If there wasn't a NATURAL KEY for kits then you would probably make the KitNumber a simple Auto Incrementing SURROGATE KEY.</p> <p>Now to the more complicated table. The one that models the link between Parts and Kits. (Kits are made of parts).</p> <pre><code>CREATE TABLE KitParts ( [KitNumber] INT , [PartNumber] INT ) </code></pre> <p>So the only information this table contains is the links between Kits and Parts. What should the PRIMARY KEY be?</p> <p>If you think about the thing that uniquely identifies a row is the COMBINATION of the two columns. Therefore the NATURAL KEY is both ([KitNumber] and [PartNumber]). This is called a COMPOSITE KEY.</p> <p>Also this table should add some FOREIGN KEY Constraints. For example, [KitNumber] should never contain a value that doesn't exist in the Kits table.......</p> <p>Good luck. Welcome to SQL Development.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload