So we ended on cardinality and we've looked at a lot of the relational model, we've seen so much of
it, but yet we haven't hit the main point of what makes the relational model the relational model,
and that is the ability to link relationships between different types of data.
If we look over here, we can see something called the primary key.
And so the primary key, in essence, is a key.
Now, you may be thinking, well, yeah, I can read two primary key, but what this is, is something
that uniquely identifies your data.
We've always seen this in most of the tables that I've shown you.
We've seen the ID field there and we've seen it uniquely identify each and every one, two, three,
four, five.
It is a unique identifier, uniquely identifies each and every role.
And why is that important?
Well, uniquely identifying each and every piece of data means that we can now know for certain the
person with I.D. one is mobily.
Now, it's great, I'm number one, I'm not trying to say that, but what I'm trying to say here is
that because of the I.D. being the primary key, primary key being the term that we use to say this
is the thing that's uniquely identifying each and every role because it is the primary, we can now
use it and we can say, well, hey, I have some other data over here.
And it's kind of linked to this is kind of linked to Mobeen.
And so I can use his ID, right?
I can use his I.D. and I can say, oh, this is linked to MCGEENEY.
And yes, you can.
That is the vital part of the relational model, the ability to draw relationships.
And so how would that look?
Well, let me show you.
There is also something called the foreign key, and the foreign key is just this other terminology
for saying, well, if the primary key is uniquely identifying my data in place, if I am going to reference
data from somewhere else, well, I'm going to reference it by that primary key because like I said,
I want to uniquely identify MCGEENEY.
So Mobeen is number one.
Well, if I went into the manager ID, I can see here, M1, M2, M3.
And so if I'm going to link that relationship, if I'm going to say, well, you know what, Clive Bowie
is the manager of Moe, well, then I'm going to have to do that in a certain way.
So we see over here in Orange the manager ID being the primary key of managers and one and two and three.
And so over here we see the primary chemokine one.
And the manager of Mobily.
Is done by drawing a relationship to manage, right?
And the way we do this is by injecting a column, there is a new column in this table in the sole purpose
of this column is to manage that relationship is to say, hey, well, Mo.
Is managed by anyone, so a foreign key references the primary key of a different table.
Let me repeat that again.
A foreign key is a key that will reference the primary key, the unique identifier of a different table,
therefore allowing a relationship to be formed that is solidified in stone, more so than my fiance
and I's marriage.
I'm kidding there, of course.
But that being said, with this, what you basically get is a relationship and a relationship that is
warranted by the fact that is linked to a key and that key is unique.
That key cannot be changed.
That key cannot be deleted because if it is deleted, then it would cause issues throughout the system.
We'll get into that part later.
But that being said, what we need to know now is because we are referencing a unique key and because
we are injecting this column that says Manager Idee.
In the same table as the employees will now we know for certain that Mo, its manager, is Clyde Bowie,
and that is how we link relationships.
We link relationships by primary keys.
And once you've created a relationship, a primary key.
Where it is injected becomes the foreign.
So now that we know all of that, we know the core of the relational model, we know the essence of
why the relational model is the way it is, this unique way of trying relationships is what makes it
special.
Amazing.
Well, now we know the relational model.
Now we know all of this stuff.
Let's look at how these databases can be used.