So in the previous video, we ended on talking about the limitations of a file processing system and
how redundant data, isolated data and the file structures in which the data were stored were problematic
for systems to talk to each other and for users to be able to understand how to manage their data.
And comes the database oriented approach as the process started outweighing the cons.
When Oracle and PostgreSQL and Microsoft came out with these database softwares, people had no choice
but to migrate away from their approach of building custom software to manage these systems and using
a database approach.
Now, what do we mean by database approach?
Well, there is this software that is utilized to manage databases and it's called a database management
software.
Its sole purpose is to put constraints in place.
It's going to manage your data.
That's its only task, is to manage your data in the way it does.
This is by following a model.
So different database softwares follow different models becomes a bit tricky.
Right.
So what are we saying by that?
Well, if we had a school system where we had library exams and students, all of these concepts are
going to be managed by this database management software.
But on top of that, it's going to enforce a model.
It's going to enforce a structure of data that each and every one of these needs to follow.
And by enforcing that structure now, no one needs to care about where the data is stored.
This isn't important anymore because all of these structures are following the same principles and there
is a layer of software in front of whoever's talking to it that is doing this management.
That means you don't need software developers anymore to create custom solutions.
You don't need all of these migration and gluing together of systems that you previously needed between
the data which would happen here to make systems talk to each other.
What you had now is one piece of software that promised you, if you follow this model of the way to
save your data, will do all of the management for you.
And that is what the database management software did.
So a database approach took all of these fragmented, isolated systems that stored data separately in
different ways and unified made them one that is amazing.
That's a huge step forward, not only because it's simplified so many things, but also because you
can now build more robust systems.
You could build a library, examine student interface that knew about each other and could make relationships.
If a library rented a book to a student, it could reference the student by an identifier, by something
unique to that student.
And if the student updated his address because the library reference the student by something unique,
it didn't have to copy over the student's data.
It just had a reference to the student, like a student ID or something like that.
It depends on the model you follow.
But what's important here is that because that model is enforced and you unified the data, you can
now draw relationships between the data.
You can say a student is related to a book rental, a student is related to an exam.
You could make these mental maps.
And it was so much more logical than saying, well, my students are stored over here and my exams are
stored over here and my library rentals are stored over here.
And if I need a student, if he's going to rent the book, let me just copy his information from over
here and put it in the rental, because if that information ever changed, how are you going to migrate
that change over and such?
All of those things went the way with the database oriented approach and by using this software.
Now, how does that look in practice?
Previously we saw that a user just was using a system and that would talk directly to wherever the data
was stored.
There was custom software in between.
But by utilizing the database oriented approach, we now have this new player, the DBMS or database
management software.
This software was the interface between your data and whatever was storing your data.
So now you didn't even need to care if you were running Windows, Linux, Mac, this software over here
would handle all of that and it would just give you a common way of saving data.
And with that common way of saving data came a specific language, that specific language being Eskew
well structured query language.
It was a unified one way of talking to the database management software to get data, to put data.
And by unifying all of that, you simplified all of your systems so the user now didn't need to know
the specific system.
All he needed to know was ask you.
Well, and by knowing ask you, well, it didn't matter what database management software you were using.
Sure, there are small differences here and there between the versions of as well as we discussed prior.
But by knowing ask you, will, you basically took this entire layer away from the user.
They didn't need to know anything about the way that that was stored.
And you also took away the need for developers to build complex software solutions to manage this data.
All they needed to do was learn how to model their data for the database management system, because
each database management system has their own model.
And we'll get deeper into the different types of models as we go along, focusing primarily on one,
which is the relational model.
But we'll get into that later.
For now, all you need to know is that a database management system follows a specific way of structuring
and saving data called the model.
And as long as software developers knew how to model their data for the database management system,
they were golden.
They could structure relationships between data.
They can make a student exam library system easily.
And by structuring the data in that model now, school could easily talk and retrieve data.
There was less isolated data, there was less need for redundant data, and there was less of an issue,
migrating data between systems because all the systems use the same model and the same software to manage
the data.
And that brought along so many benefits that we've seen taking away all of those limitations that file
processing systems had.
So let's talk a little bit more about database models.