All language subtitles for 28 - Relational Model English

So the relational model now, we looked at the hierarchical model and we looked at the networking model,

the networking model being the expansion of the hierarchical model and how they followed this parent

child structure, which to its own right had its efficiencies when retrieving data.

Because once you had the parent, you had all the child information right there.

But it came with its own set of inefficiencies with the networking model because of the way many to

many relationships were formed.

Like we said, if you were to delete book one from Andre, you would have to go and look at every other

parent and see if they had a reference to book one of Andre would a specific relationship.

So there were these intricacies in data management that came to be.

So in comes the relational model, if God looked at the landscape of how we were organizing data and

realized that most of the models we were following, they were informal, there wasn't any set rules

in place for the hierarchical model nor the network model.

There was this idea and there were these theoretical papers on the models, but there weren't any hard

set rules in place to say, hey, this is how you should do it.

This is how you get the most out of it, and this is how we're going to model our system.

So he came out with the relational model, which had a formalized set of rules, the first model with

the formalized set of rules, to be exact.

And if we look at the model here, it doesn't follow that parent child like structure anymore.

It shows a completely different route.

Instead of relating your data through a parent child relationship, it followed a table structure.

Organizing your data in tables also called relations.

Now you're using what is a table.

Well, think of an Excel sheet.

An Excel sheet has columns and rows, and when you use an Excel sheet and you have those columns and

rows, you can give the sheet a name that's very closely related to what tables are.

Our table has the name author and a table has the name book and the columns, although not like Excel,

having the name ABC and they do have specific names.

Let's take a closer look at that here.

You can see three tables over here.

You can see the table for author over here.

You can see the table for book.

And don't pay attention to the middle just yet.

We'll get to that.

When we look at author, we can see our columns aren't called ABC and we have authorized first name,

last name.

So we're specifically saying what is going to go in this column?

And over here we can see author 20 is Mobily.

Author Twenty one is Andre Nagoya.

You may ask yourself, why do we have this authority while we want something to uniquely identify our

data?

Because first and last name?

Well, there may be someone with my first and last name.

There may be someone with Andre's first and last name.

That's not really unique.

So we choose something that can uniquely identify each and every piece of data.

And the same for book.

The book name isn't really unique.

Book one, two and three.

There may be someone that has the same book name out there.

So we choose a book ID.

All right.

Now I can see you looking at this and being confused.

When we looked at the network model in the hierarchical model, we were storing data in that remember

the XML format that we were looking at?

We were storing it in a parent child like structure and every parent have all of the information of

its child.

How does this relate to what we're doing in the relational model?

Well, remember, I said we're storing all our data separately now.

We don't have this parent child structure anymore.

We have a table structure, so now instead of having an author parent, each and every author is an

individual piece of data with a unique identifier.

And each and every book is an individual piece of data with a unique identifier.

Now, you may be thinking, OK, I can see that they're completely separate, but how do we link them

together?

Well, in the relational model, we have a bunch of concepts that we will get into on how to draw relationships

between data.

This is one way of doing it will create a third table where we say, OK.

Author Mo.

Wrote book Two Hundred and author Andre also wrote book Two Hundred, so now we can say, Oh they may

have co-authored this.

And then author Andre also wrote book Two Hundred and One.

So Book Two was written by Andre and Book three was written by MO.

So by linking their unique identifiers together in a separate table, we can now say, Hey, this author

and this book is related, and by retrieving all the authors for a book, we could potentially now say,

Oh, this book has two authors.

So there may be a co-author situation.

So by storing all our data in a flat way unrelated to parent and child like structure, we can now draw

relationships in a much simpler way.

You could do this in an Excel sheet in a very simple way.

You can input this data in one sheet and put this data in another.

She'd give the sheet a name book and then in a third sheet you could start putting ideas together.

And that is the exact same concept here.

Now I hear you saying, OK, OK, but if I put this in Excel, Excel isn't going to tell me that these

are actually related.

There's some kind of logic there.

Right.

And you would be correct, the logic of how the relationships are linked are managed by the database

management software now.

So now we've looked at three models, right?

We've looked at hierarchical network and relational.

Each and every one of these models, formal or informal rule sets in place, have specific rules.

Right.

There is a rule that you have to follow.

He authorized needs to be unique.

Book ID needs to be unique.

Hey, in the hierarchical model, you can't have more than two children linked to a parent in the network

model.

When you change a book that has two parents, we need to change it in both places.

All of these things, all of these rules, all of these things that we've talked about need to be managed

and we're not going to manage these.

These need to be managed automatically.

We don't want to do manual data entry.

That would be unfair.

So like I said, would file processing systems, there's always software in place.

And with the models, we went to a database oriented approach, meaning there is one piece of software

that is going to manage the model and that is the database management software.

Now, we'll look at the relational model more closely in all of its rules later on.

But I really want to zoom in and look at the database management software right now because it is the

key player in making sure that when we do implement a system like this, a structure like this, that

all of the relationships and all of the management of your data and the safety of your data and where

your data is going to be saved, it's going to manage all of that.

Let's take a closer look at that piece of software, because it is extremely important to the whole

picture.