All language subtitles for 27 - Hierarchical And Networking Model English

All right, so first up is the hierarchical model.

Now, this is a fairly old model.

It was primarily used by IBM in the 60s and 70s and hasn't been seen today very much due to its inefficiencies.

It isn't as popular anymore because it isn't really an efficient model for storing data.

But how does the data get organized in the hierarchical model?

Well, as the name suggests, there is a hierarchy.

It decides to store and organize data in a tree like structure, and it has this concept of parent child.

So what we can see here is that the parent author has two children, Moe and Andre and Moe and Andre

have two children as well, two books that they wrote.

So every child only can have a single root.

What do I mean by that?

There is no ability to say Moe and Andre, both Kofod book one.

There is no linking of one child node to someone else's child, each and every node.

And what we mean by node is a child that are synonymous to each other.

Each and every node can only have one parent.

So with this tree like structure, we already have put in place one constraint.

Every parent can have multiple children, but every child can only have one parent.

Now I hear you saying, OK, I understand the concept, but what does that look like in real life?

Well, because this model is very outdated.

There are many things that emulate it quite as well as it used to be used.

But one thing we can use to kind of.

Make this structure look like it would have been stored is XML and XML is a document type in which we

structure data also in a tree like fashion.

Over here you can see an example of XML.

We have a parent node author and then we have a child node MO and a child node, Andre and Mo and Andre

are storing some data about themselves.

They're storing their name.

And they're storing their country, these are directly related to MO.

And then they're also storing their books, book one, book two and the release dates, and Andre is

doing the same thing.

He has his name and his country, his books.

Now, you can see here, because of this structure, if I were to delete most all of the information

about more would be deleted as well.

Same counts for Andre if I deleted his book, won the release date goes poof.

So this is one of the drawbacks of a hierarchical structure right here, because you have this parent

child structure and every child can only have one parent.

When you delete a parent, all of the child's information goes away.

So the data is what we would call tightly coupled.

The child data is tightly coupled, tightly coupled, meaning it is directly related to its parent.

If the parent goes away, the child information goes away.

This is what we call tight coupling because it's directly related.

And if the parent were to go away, so would the data.

Now, what we can see here is that this is pretty good for describing what we would call real world

relationships most is directly related to his information and his books.

But it is also good for describing what we would call a one to many relationship.

Let me backtrack a little bit to explain what that means.

What a one to many relationship means is that if we look here, an author can have many children, but

a child can only have one parent.

Andre can only be related to author book.

One can only be related to Andre because it's his book.

It's not most book that we don't have a way of saying, hey, book one right here was both Moes and

Andre's.

They wrote a completely different book, one.

Just think of it as having a completely different title, for instance.

So what do we mean by one too many?

One parent can have many children.

The child can only have one parent.

That is what we call a one to many relationship.

So the hierarchical model supports one too many relationships and that is very apparent here.

Author has two children and the children have more children.

Si Mo has a name country book, book two, so that becomes very clear, we now know how the hierarchical

model is storing data.

This is just an example of how data would be stored.

This is not exactly how it was stored back in the day when hierarchical databases were out.

Again, these are rarely seen today due to their inefficiencies.

So then came along.

The networking model and the networking model expanded on the hierarchical model, allowing many to

many relationships.

Now, what do I mean by that?

Well, suddenly we could allow coauthoring more, could now help Andre on book one and they could have

a significant relationship that related to each other.

We could now see the child entities could have multiple parents.

Let's solidify that a bit more and go back to the hierarchical model.

So what we said here is that each and every parent can have multiple children, but each child could

only have one parent.

All right, because of that, we couldn't do things like have a book be co-authored, so because the

networking model expanded on the hierarchical model and allowed the many to many relationships, it

became a bit more complex to manage your data.

And if we took our XML example, the software would basically do something like, OK, we have an author,

we have Morgan, we know this, but then his book one.

Would reference author Andre.

And then it would specify his relation to be co-author.

And then Andre would have the book definition of book one.

Now, what this would mean is that the software would have to keep intact what a relationship was,

and this is just one way of defining a relationship.

Now, this is in no way the practical way, in any way, shape or form that a networking model would

have done its relationship.

But for reference sake, let's just say that the software did have this type of relationship where it

would say, OK, the author, the other parent is Audry, and my relation to it is co-author.

That way we would have enough information to say, go get the information from Andrea about book one.

And here's the extra information about me.

I'm the co-author.

Now, that would mean that if Andre ever deleted his book one, the software would have to go and say,

OK, Andre deleted book one.

Let me go through all of my other data and see if there is a book, one that links author Andre so that

I can manage the deletion.

And this meant that it became more complex for the software to look at relationships and warrant the

relationship between data.

So now that we know how the networking model in the hierarchical model, our historical models used

to work where one to many relationships came to start, we defined where many to many relationships

came to be, and people started to think, huh, OK, this tree like structure that we're storing our

data in, it isn't really working for us.

So in comes the relational model.

Let's take a closer look at that.