At its heart, a database is just an organized collection of information. Think of the contacts app on your phone. It's a simple database. Each person is an entry, and for each entry, you store specific pieces of information like a name, a phone number, and an email address.

Instead of a random list, the data is structured. This structure makes it easy to find, add, or update information. Relational databases are a very common way to create this kind of organized structure for data, from a simple contact list to the massive inventory system of an online store.

The “relational” part of the name comes from how these databases organize information: in tables, which are officially called relations. A table is a lot like a spreadsheet. It has columns that define what kind of information is stored, and rows that contain the actual data for each entry.

• Columns (or fields) are the vertical categories in a table. For our contacts app, the columns might be FirstName, LastName, and PhoneNumber.
• Rows (or records) are the horizontal entries. Each row represents a single item, like one specific person in your contact list.

Let’s look at a simple table that might store customer information for an online shop.

In this Customers table, each row is a unique customer, and the columns define the pieces of information we store about them. Simple enough. But what happens when these customers start placing orders? We could add more columns to this table for OrderDate, ProductName, ProductPrice, and so on. But that would get messy fast. What if a customer places ten orders? We'd have to repeat their name and email ten times. This repetition, called data redundancy, is inefficient and can lead to errors.

Instead of stuffing everything into one giant table, the relational model uses multiple tables that are linked together. To make these links work, we need a way to uniquely identify every single row. That's where keys come in.

In our Customers table, CustomerID is the perfect primary key. It's a unique number assigned to each customer.

Now, let's create a separate Orders table to store order information. This table will also have its own primary key, OrderID.

Look closely at the Orders table. How do we know which customer placed which order? We use the CustomerID column. By including the customer's unique ID with each order, we create a link back to the Customers table. This CustomerID column in the Orders table is called a foreign key.

This relationship between a primary key and a foreign key is the foundation of the relational database model. It allows us to split our data into logical, manageable tables and then connect them to answer more complex questions. For example, we can easily find all the orders placed by Loid Forger by linking the tables.

By breaking data into related tables, we reduce repetition and improve data integrity. If a customer changes their email, we only have to update it in one place: the Customers table. All their orders will remain correctly linked through their unchanging CustomerID.

This structure of tables and relationships is the blueprint upon which all SQL commands are built. Understanding it is the first step to mastering how to talk to databases.

Time to check your understanding of these core concepts.

Now that you understand the basic building blocks of a relational database, you're ready to learn the language used to interact with them: SQL.