The idea of a Foreign Key is that it relates multiple rows to data in a different table. For example, think of an invoice. It consists of invfo with is relevant to the whole invoice, like the Invoice number and the date it was issued, and a set of rows for each item purchased:
Invoice number: 12345
Invoice Date: 12/04/2018
Customer: Joe's Shoes, Shoe House, Shoe Lane, Shoeton
Qty Desc Price Per Total
1 Laces $5.00 $5.00
2 Shoe polish $7.00 $14.00
To store this, you set up tables:
Invoices
ID PRIMARY KEY
InvoiceNumber
Date
CustomerID
InvoiceLines
ID PRIMARY KEY
InvoiceID FOREIGN KEY to Invoices.ID
ItemsCount
Description
Price
You create the Invoices item first, then use the ID to set the value of the Foreign Key for each row of the InvoiceLines table.
This doesn't happen automatically - you pick up the Invoices.ID value from the DB after you insert a row, normally by using the @@IDENTITY or SCOPE_IDENTITY value:
@@IDENTITY (Transact-SQL) | Microsoft Docs[
^]. Normally, the whole set of INSERT operations would be contained in a TRANSACTION to ensure database integrity if there is a problem.
Personally, I prefer to use GUID based IDs instead of IDENTITY, and assign the ID value from the presentation software instead of relying on incrementing values - if nothing else, it does not imply any order or lack of "gaps" which IDENTITY does (and shouldn't be used for)