So let's explore these two kinds
of database management systems,
and let's start with the SQL databases
with relational database management systems.
Now, how do SQL databases work?
What's the idea behind them?
Now, in SQL databases,
you typically store so-called normalized data
across multiple tables.
And I'll come back to what normalized data means.
For the moment, let me give you an example.
Let's say we're building a website
where we need airports and flights between those airports.
If we opt for a SQL database,
we could create two tables in that database.
One for the airports and one for the flights.
And then in every table,
we would have columns and rows.
For airports, we could have three columns,
with the idea of the airport, the city and the country.
We could also have more columns.
You can have as many columns as you want.
Now for flights, we could also have three columns.
We could also have more or less.
You don't need to have the same amount of columns
into the two tables because the two tables
will be totally independent from each other.
And then in flights,
we also might have IDs for the flights,
and then we have our start and destination airports,
where we pick up the IDs from our airports.
And that's important.
We kind of relate these two tables with each other
by using the ID from one table as a value
in another column in another table.
So the IDs of our airports like JFK,
are used in the start and destination fields
of our flights table.
And that's a very common thing to do in SQL databases.
Now, the data here is normalized
because we don't have any nested data in any table.
Every column in our tables holds only one value per row.
Start does not hold two airports, but just one airport.
City in our airports table,
does not hold multiple cities, but one city.
And therefore, here in this example,
we would have normalized data split across multiple tables.
Now, you would create such tables in your database
with help of some database management software
or by running such SQL queries.
And then, the database would store that data and the schema
of these tables in some files on your system,
but it would do that for you.
You are not involved in that file storing.
You don't have to care about that.
You instead,
would only interact with your database
and with those tables.
Now, one important thing to understand
about SQL databases,
is therefore indeed,
that you do have clearly defined schemas
and also data types.
Before you start saving or fetching any data,
you set up your database tables
and you come up with a schema for every table
and you define which kind of data should be stored
in every field of that database.
Now for example,
that the idea of the airports
should be some unique string,
that city and country holds some text data
and they offer strings,
that the IDs of our flights could be integers
that should be unique,
and that we then again, have more strings in there.
The uniqueness is also an important feature here
because that ensures that each row has a unique identifier,
which is another very important thing
in relational databases since you need
to be able to establish relations between tables,
with help of such unique identifiers.
Without unique identifiers,
you could not have clear relations
between different pieces of data in different tables.
And that brings us to the next point.
With SQL databases,
you can of course, then query your data,
and especially also your related data.
You could for example,
run a simple query where you get all the flights
that start in Munich
and you could then go to the flights table
and query on the start column
and search for the MUC identifier
and get all the entries where you have that identifier.
And then you could return the start value and the ID
and the destination value that belongs to this identifier.
This would be a relatively simple query.
You can also run queries across multiple tables,
and indeed that's one of the main ideas
behind relational databases.
You can for example,
get all the flights data where flights start in Munich,
but then you don't just want to get the flights data,
but also all the data for that start airport.
So then, you would use that relation
and that unique identifier,
which is so important as I mentioned,
to then also go to the airport's table,
look for the MUC identifier data in the ID column
and fetch all the data related to that airport.
And then one query could return data about the flight,
so the ID, start and destination,
and also in the same query,
data about the starting airport,
like the city and the country.
That's the idea behind SQL.
And of course, it still might be a bit abstract
with these slides only,
but in the very next section,
we are going to dive deeper into SQL databases,
and then we're going to play with some concrete examples
in a real database.
And then this will definitely become very clear.
So, these were SQL databases
and the key characteristics really are,
that you have multiple tables,
possibly a lot of tables,
and that you split your data across these tables,
that every table has a clearly defined schema
with clearly defined data types for the different fields,
and that you can then run queries
on a single table or on multiple tables
by using these relations,
which under the hood,
utilize unique identifiers,
which you have in every table.