...
And if we populate it with some data
first name | last name | destination city | destination country | reason for visit | number of visits |
---|---|---|---|---|---|
Sel | RTR | Buzios | Brasil | Sun | 2 |
Sel | RTR | Jo/burg | South Africa | Work, Sun | 4 |
Sel | RTR | Nepal | Mountains | 2 | |
Sel | RTR | Rio De Janeiro | Brasil | Lifestyle, Sun | 2 |
Sel | RTR | empumalanga | South Africa | Safari | 2 |
Sel | RTR | Flogaman | Jamaica | Family, Sun, Lifestyle | 10 |
It's clear to see from this table that there are quite a few repeated elements such as the first name, last name, destination country, and reason for visit. We can easily improve on this model by splitting the table into two tables
...
In our example above, we can easily link the two tables together because there is only one traveller. But what if we were to increase the number of travellers and destinations to the following sets
Traveller Table
first name | last name |
---|---|
Sel | RTR |
Sam | Wright |
Carol | Anne |
Destination Table
destination city | destination country | reason for visit | number of visits |
---|---|---|---|
Buzios | Brasil | Sun | 2 |
Jo/burg | South Africa | Work, Sun | 4 |
Tokyo | Japan | Manga comics | 2 |
Nepal | Mountains | 2 | |
Mauritius | India | Chilling in the sun | 3 |
Rio De Janeiro | Brasil | Lifestyle, Sun | 2 |
Bridgetown | Barbados | Sun | 3 |
Puerto Banús | Spain | Lifestyle | 5 |
Empumalanga | South Africa | Safari | 2 |
Flogaman | Jamaica | Family, Sun, Lifestyle | 10 |
It's now clear that we cannot easily (actually it's impossible without intimate knowledge of each traveller) associate the destination rows with the travellers. We need some way of identifying which destination row belongs to which traveller.
...
And populated with the updated IDs
Traveller Table
traveller id | first name | last name |
---|---|---|
1 | Sel | RTR |
2 | Sam | Wright |
3 | Carol | Anne |
Destination Table
destination id | destination city | destination country | reason for visit | number of visits |
---|---|---|---|---|
1 | Buzios | Brasil | Sun | 2 |
2 | Jo/burg | South Africa | Work, Sun | 4 |
3 | Tokyo | Japan | Manga comics | 2 |
4 | Nepal | Mountains | 2 | |
5 | Port Luis | Mauritius | Chilling in the sun | 3 |
6 | Rio De Janeiro | Brasil | Lifestyle, Sun | 2 |
7 | Bridgetown | Barbados | Sun | 3 |
8 | Puerto Banús | Spain | Lifestyle | 5 |
9 | Empumalanga | South Africa | Safari | 2 |
10 | Flogaman | Jamaica | Family, Sun, Lifestyle | 10 |
The IDs in both cases must be unique. You might be asking yourself: do we need the destination id? We will come back to this.
...
Destination Table (updated with traveller id)
destination id | traveller id | destination city | destination country | reason for visit | number of visits |
---|---|---|---|---|---|
1 | 1 | Buzios | Brasil | Sun | 2 |
2 | 1 | Jo/burg | South Africa | Work, Sun | 4 |
3 | 2 | Tokyo | Japan | Manga comics | 2 |
4 | 1 | Nepal | Mountains | 2 | |
5 | 2 | Port Luis | Mauritius | Chilling in the sun | 3 |
6 | 1 | Rio De Janeiro | Brasil | Lifestyle, Sun | 2 |
7 | 3 | Bridgetown | Barbados | Sun | 3 |
8 | 3 | Puerto Banús | Spain | Lifestyle | 5 |
9 | 1 | Empumalanga | South Africa | Safari | 2 |
10 | 1 | Flogaman | Jamaica | Family, Sun, Lifestyle | 10 |
We now have enough information to be able to link the rows on either table to each other.
...
Destination Table (updated with traveller id)
destination id | traveller id | destination city | destination country | reason for visit | number of visits |
---|---|---|---|---|---|
BRABUZ | 1 | Buzios | Brasil | Sun | 2 |
ZAFJOH | 1 | Jo/burg | South Africa | Work, Sun | 4 |
JPNTOK | 2 | Tokyo | Japan | Manga comics | 2 |
NPLXXX | 1 | Nepal | Mountains | 2 | |
MUSPOR | 2 | Port Luis | Mauritius | Chilling in the sun | 3 |
BRARIO | 1 | Rio De Janeiro | Brasil | Lifestyle, Sun | 2 |
BRBBRI | 3 | Bridgetown | Barbados | Sun | 3 |
ESPPUE | 3 | Puerto Banús | Spain | Lifestyle | 5 |
ZAFEMP | 1 | Mpumalanga | South Africa | Safari | 2 |
JAMFLO | 1 | Flogaman | Jamaica | Family, Sun, Lifestyle | 10 |
Now we specify the destination id as the primary key and index on it. Also, we would write some algorithms to identify the full country name from the data in the destination id column.
...
The CREATE TABLE command is used to tell the DBMS that a table should be created, the full syntax is as follows
|
So our traveler table could be defined as follows
|
And the destination table is as follows
|
In this example, we have used a CONSTRAINT just to show an example of its usage. We could have and should have used the NOT NULL constraint as shown on the destination_country.
...
The most general syntax is - to insert a value into every column
|
The most common syntax is - to insert a value into selected columns
|
The usual syntax when a field has an auto-increment constraint - insert to selected fields
|
Querying the data
Once you have data in your database, you can use the query elements of SQL to find data. The SELECT command has many forms, we simply use it to query one and two tables.
Its most basic form is the following - this will read all data from all columns
|
You can restrict the columns returned using
|
We can restrict the amount of data returned using this SELECT ... WHERE form
|
The WHERE clause is used to constrain the result set that is returned. You can see this if you run the query above that contains any of the WHERE clauses.
...
A SQL join is an instruction to combine data from two sets of data (i.e. two tables). So in our example, above we can bring the two tables back together as a single result set using the following query
|
Unfortunately, when you run this query it will duplicate the traveller_id because the select * selects all columns from both tables. Let's narrow this by altering the query
|