Scribd
Upload
14 views7 pages

Practical 4 - Foreign Key

Uploaded by

abhishek kumar bhaugeeruthy
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
14 views7 pages

Practical 4 - Foreign Key

Uploaded by

abhishek kumar bhaugeeruthy
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 7

Foreign key graphical representation

Before we define what FK is, we’ll once more remind ourselves of what is the
primary key:

“Primary key is a value, or a combination of few values from the table,


uniquely defining each record in this table. If we know this
value/combination, we can easily find the related record and access all
remaining values from that record.”

In our model, both tables, country, and city have 1 attribute which is used
as a primary key and that is the id attribute. The value of this attribute is
defined to start from 1 and increment by 1 for each new row added. That
way, the system automatically ensures that we don’t have duplicate values.
The one thing which is pretty obvious is that we have a line connecting our
tables. This line goes from country.id to city.country_id and there is a
good reason for that. This is how we graphically represent a FK.

What is a foreign key?


In the previous section, we concluded that there is some kind of relationship
between our two tables. The attribute from one table (city.country_id) is
related to the primary key attribute from another table (country.id). That
attribute (city.country_id) is a FK attribute. The table country is the
referenced table, and the table city is the child table. This relationship
actually says that value stored in the city.country_id attribute should be
one from the set of values stored in the country.id attribute (or, in some
cases, although not this one, could be undefined = NULL).

So, the definition of the FK would be:

“The foreign key is an attribute, or more of them, directly related to the


primary key of another table. When properly set, this rule shall ensure that
we must always set the value of that attribute to exactly 1 value from the
referenced table. This is the way how we relate data stored in different
tables in our database model.”
Note: If primary keys are always defined as a single column, then each FK shall be
exactly 1 attribute. While this might not look so important at first, it actually proves
to be a good “rule” to follow when designing a database. We’ll talk more about that
in the next article related to indices.

Foreign key – How it’s stored/defined in the


database?
After the theory, it’s a good time to take a look at when is actually in the
database. We’ll do it using the database we’ve created previously

After I clicked on the relationship city_country in Object explorer, the


Foreign Key Relationship window popped up. Under General -> Tables And
Columns Specification you can see the previously mentioned relation
between 2 columns in out 2 tables. If we scroll down a little, we can also see
the remaining properties:
You can see the following settings:

 Enforce for replication – possible values here are “Yes” and “No” –
Enables or disables it for replication. Please read more about the
replication in SQL Server Replication (Merge) – What gets replicated
and what doesn’t article
 Enforce Foreign Key Constraint – possible values are “Yes” and
“No”. If it’s enabled, the FK constraint works as we want it. We could
disable it if we want, but we should have a good reason for that. One
could be that we want to manually change keys values and we
wouldn’t be able to do that because constraints would “scream” all the
time
 Delete Rule – possible values are “No Action”, “Cascade”, “Set NULL”,
and “Set Default” – defines what will happen with child table rows if we
delete the related row from the referenced table
 Update Rule – possible values are “No Action”, “Cascade”, “Set
NULL”, and “Set Default” – defines what will happen with child table
rows if we update the related row in the referenced table

Now we’ll examine the code to see how the FK was defined. Let’s right-click
on the table dbo.city and then Script Table as | CREATE to | New Query
Editor Window just as on the picture below:
The result is the following code:
USE [our_first_database]
GO

/****** Object: Table [dbo].[city] Script Date: 12/25/2019 4:54:11 PM ******/


SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[city](


[id] [int] IDENTITY(1,1) NOT NULL,
[city_name] [char](128) NOT NULL,
[lat] [decimal](9, 6) NOT NULL,
[long] [decimal](9, 6) NOT NULL,
[country_id] [int] NOT NULL,
CONSTRAINT [city_pk] PRIMARY KEY CLUSTERED
(
[id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY =
OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

ALTER TABLE [dbo].[city] WITH CHECK ADD CONSTRAINT [city_country] FOREIGN


KEY([country_id])
REFERENCES [dbo].[country] ([id])
GO

ALTER TABLE [dbo].[city] CHECK CONSTRAINT [city_country]


GO

You can see FK definitions in the red lines, with the first statement defining
which attributes are included in the check and the second statement telling
us this is related to the definition of the city table.

Foreign key – What it actually does?


First, let’s see the contents of our tables:
FK will do a few checks, but most important are:

 If you add a row to a table, the attribute which is part of the foreign
key must have the pair in the original table (1:n). It can be NULL if
the type of that relation (FK) is not mandatory (0:n). In any case, it
can’t contain a value not existing in the referenced table
In our case, this means, that we can’t add a city if the country_id is
not in the range [1,5] – set of id values from the country table. If we
try to execute something like this (notice that in this
statement country_id = 6 and we don’t have a pair in
the country table):

This is what happens:

And this is great because the FK prevented us from making a mistake

Note: In case we could execute this INSERT statement, we would


insert a city belonging to a country with id = 6, without actually
knowing that country. Later, someone could insert e.g. the Netherlands
as the country with id = 6 and we would have inconsistent data

 When we delete data from the referenced table, we won’t be able to


delete if there are related records in the child table. This stands when
setting Delete Rule is set to “No Action” (this should be how you set
your foreign key in most cases). “Cascade” would also delete rows
from the child table, while “Set NULL” and “Set Default” wouldn’t
delete entire rows from the child table, but just set the values of these
attributes to NULL or predefined value

Let’s try to delete country with id = 5 (Poland) using the statement:

The result is shown below:


Once again, this is really great because the defined rule (FK), prevented us
from deleting something we still use
Note: If the statement would delete Poland, then Warsaw would be assigned
to the non-existing country. While we don’t know which country it belongs to,
someone could later insert another country with id = 5 (as for inserts) and
we would have a problem with our data.

The FK, when defined properly, instead of you, does the job in the
background. It takes care of the referential integrity in our database.

You might also like