It’s no mystery that a database is something that stores data. However, today’s modern Relational Database Management Systems (RDBMS), such as MySQL, PostgreSQL, SQL Server, Oracle, DB2, and others, have extended this basic role by adding the capability to store and manage rela- tional data.
So what does relational data mean? It’s easy to see that every piece of data ever written in a real-world database is somehow related to some already existing information. Products are related to categories and departments, orders are related to products and customers, and so on. A relational database keeps its information stored in data tables but is also aware of the relations between them.
These related tables form the relational database, which becomes an object with a signifi- cance of its own, rather than simply being a group of unrelated data tables. It is said that data becomes information only when we give significance to it, and establishing relations with other pieces of data is a good means of doing that.
Look at the product catalog to see what pieces of data it needs and how you can transform this data into information. For the product catalog, you’ll need at least three data tables: one for departments, one for categories, and one for products. It’s important to note that physically each data table is an independent database object, even if logically it’s part of a larger entity—
in other words, even though we say that a category contains products, the table that contains the products is not inside the table that contains categories. This is not in contradiction with the relational character of the database. Figure 4-1 shows a simple representation of three data tables, including some selected sample data.
When two tables are related, this more specifically means that the records of those tables are related. So, if the products table is related to the categories table, this translates into each product record being somehow related to one of the records in the categories table.
Figure 4-1 doesn’t show the physical representation of the database, so we didn’t list the table names there. Diagrams like this are used to decide what needs to be stored in the data- base. After you know what to store, the next step is to decide how the listed data is related, which leads to the physical structure for the database. Although Figure 4-1 shows three kinds of data that you want to store, you’ll learn later that to implement this structure in the data- base, you’ll actually use four tables.
So, now that you know the data you want to store, let’s think about how the three parts relate to each other. Apart from knowing that the records of two tables are related somehow, you also need to know the kind of relationship between them. Let’s now take a closer look at the different ways in which two tables can be related.
Figure 4-1. Unrelated departments, categories, and products
Relational Data and Table Relationships
To continue exploring the world of relational databases, let’s further analyze the three logical tables we’ve been looking at so far. To make life easier, let’s give them names now: the table containing products is Product, the table containing categories is Category, and the last one is our old friend, Department. No surprises here! These tables implement the most common kinds of relationships that exist between tables, the One-to-Many and Many-to-Many relationships, so you have the chance to learn about them.
■ Note Some variations of these two relationship types exist, as well as the less popular One-to-One rela- tionship. In the One-to-One relationship, each row in one table matches exactly one row in the other. For example, in a database that allowed patients to be assigned to beds, you would hope that there would be a one-to-one relationship between patients and beds! Database systems don’t support enforcing this kind of relationship, because you would have to add matching records in both tables at the same time. Moreover, two tables with a One-to-One relationship can be joined to form a single table. No One-to-One relationships are used in this book.
One-to-Many Relationships
The One-to-Many relationship happens when one record in a table can be associated with multiple records in the related table, but not vice versa. In our catalog, this happens for the Department–Category relation. A specific department can contain any number of categories, but each category belongs to exactly one department. Figure 4-2 better represents the One-to- Many relationship between departments and categories.
Figure 4-2. A One-to-Many relationship between departments and categories
Another common scenario in which you see the One-to-Many relationship is with the Order–Order Details tables, where Order contains general details about the order (such as date, total amount, and so on) and Order Details contains the products related to the order.
Many-to-Many Relationships
The other common type of relationship is the Many-to-Many relationship. This kind of rela- tionship is implemented when records in both tables of the relationship can have multiple matching records in the other. In our scenario, this happens between the Product and Category tables, because a product can exist in more than one category (one product—many categories), and also a category can have more than one product (one category—many products).
This happens because we decided earlier that a product could be in more than one category.
If a product belonged to a single category, you would have another One-to-Many relationship, just like that between departments and categories (where a category can’t belong to more than one department).
If you represent this relationship with a picture as shown previously in Figure 4-2, but with generic names this time, you get something like what is shown in Figure 4-3.
Figure 4-3. The Many-to-Many relationship between categories and products
Although logically the Many-to-Many relationship happens between two tables, databases don’t have the means to physically implement this kind of relationship by using just two tables, so we cheat by adding a third table to the mix. This third table, called a junction table (also known as a linking table or associate table) and two One-to-Many relationships will help achieve the Many-to-Many relationship.
The junction table is used to associate products and categories, with no restriction on how many products can exist for a category or how many categories a product can be added to.
Figure 4-4 shows the role of the junction table.
Figure 4-4. The Many-to-Many relationship between categories and products
Note that each record in the junction table links one category with one product. You can have as many records as you like in the junction table, linking any category to any product. The linking table contains two fields, each one referencing the primary key of one of the two linked tables.
In our case, the junction table will contain two fields: a CategoryID field and a ProductID field.
Each record in the junction table will consist of a (ProductID, CategoryID) pair, which is used to associate a particular product with a particular category. By adding more records to the junction table, you can associate a product with more categories or a category with more prod- ucts, effectively implementing the Many-to-Many relationship.
Because the Many-to-Many relationship is implemented using a third table that makes the connection between the linked tables, there is no need to add additional fields to the related tables in the way that you added DepartmentID to the category table for implementing the One-to-Many relationship.
There’s no definitive naming convention to use for the junction table. Most of the time it’s okay to just join the names of the two linked tables—in this case, our junction table will be named ProductCategory.
Enforcing Table Relationships with the FOREIGN KEY