Diagrams and Table Relationships

Figure 7.26. Creating and visualizing table relationships

Now that you’ve created these foreign keys, you can be sure that all the data stored in your tables will obey the enforced table relationships. The DepartmentID column in the Employees table will always reference valid departments, and the HelpDesk records will always reference valid employees, help desk categories, help desk subjects, and help desk status codes.

In Chapter 8, you’ll start learning how to use your new database. Before then, let’s take a moment to analyze the diagram, and learn more about the information it shows us.

Diagrams and Table Relationships

Relationships describe how data in one table is linked to data in other tables. In fact, it’s because relationships are so crucial that these types of databases are given the name “relational databases.” Relationships exist for the sole purpose of associating one table with one or more other tables using primary keys and foreign keys.

287

Chapter 7: Database Design and Development

There are three types of relationships that can occur between the tables in your database:

one-to-one relationships

one-to-many relationships

many-to-many relationships

One-to-one Relationships

A one-to-one relationship means that for each record in one table, only one other related record can exist in another table.

One-to-one relationships are rarely used, since it’s usually more efficient just to combine the two records and store them together as columns in a single table. For example, every employee in our database will have a phone number stored in the HomePhone column of the Employees table. In theory, we could store the phone numbers in a separate table and link to them via a foreign key in the Employees table, but this would be of no benefit to our application, since we assume that one phone number can belong to only one employee. As such, we can leave this one-to-one relationship (along with any others) out of our database design.

One-to-many Relationships

The one-to-many relationship is by far the most common relationship type. Within a one-to-many relationship, each record in a table can be associated with multiple records from a second table. These records are usually related on the basis of the primary key from the first table. In the employees/departments example, a one-to-many relationship exists between the Employees and Departments tables, as one department can be associated with many employees.

When a foreign key is used to link two tables, the table that contains the foreign key is on the “many” side of the relationship, and the table that contains the primary key is on the “one” side of the relationship. In database diagrams, one- to-many relationships are signified by a line between the two tables; a golden key symbol appears next to the table on the “one” side of the relationship, and an infinity sign (∞) is displayed next to the table that could have many items related to each of its records. In Figure 7.27, those icons appear next to the Employees and Departments tables.

288

Diagrams and Table Relationships

Figure 7.27. Database diagram showing a one-to-many relationship

As you can see, one-to-many relationships are easy to spot if you have a diagram at hand—just look for the icons next to the tables. Note that the symbols don’t show the exact columns that form the relationship; they simply identify the tables involved.

Select the line that appears between two related tables to view the properties of the foreign key that defines that relationship. The properties display in the

Properties window (you can open this by selecting View > Properties Window). As Figure 7.28 illustrates, they’re the same options we saw earlier in Figure 7.24.

Figure 7.28. The properties of a foreign key

289

Chapter 7: Database Design and Development

Advanced Foreign Key Options

Unless you really know what you’re doing, we recommend that you use the default foreign key options for now. However, it’s good to have some idea of the features available through the Properties window, as they may well come in handy later in your database development career.

The most significant setting here is Enforce Foreign Key Constraint, which, when set to Yes, prevents users or applications from entering inconsistent data into our database (for example, by inserting into the Employees table a DepartmentID value that doesn’t have a matching entry in the Departments table). In our application, every user must be associated with a valid department, so we’ll leave this option enabled.

The options available under INSERT And UPDATE Specification can be used to tell your database to update the tables itself in order to keep the data valid at times when a change in a given table would affect a related table. If, for some reason, we changed the ID of a department in the Departments table, we could set the database to propagate this change to all the tables related to that department, keeping the relationships intact. Similarly, we can set the database to automatically delete all the employees related to a department that’s deleted. However, these are quite sensitive options, and it’s best to avoid them unless you have good reason not to. The cases in which an ID changes are very uncommon (the ID doesn’t have any special meaning itself, other than being an unique identifier), and letting the database delete data for you is a risky approach (it’s safer to delete the related records yourself).

If these concepts sound a bit advanced at the moment, don’t worry: it will all become clear as you spend some time working with databases.

Many-to-many Relationships

Many-to-many relationships occur between two tables, when records from either table can be associated with multiple records in the other table.

Imagine that you wanted a single employee to be able to belong to more than one department—someone who works in “Engineering” could also be an “Executive,” for example. One employee can belong to many departments, and one department can contain many employees, so this is a many-to-many relationship.

How do we represent it in our database? Faced with this question, many less-ex- perienced developers begin to think of ways to store several values in a single column, because the obvious solution is to change the DepartmentID column in

290

Diagrams and Table Relationships

the Employees table so that it contains a list of the IDs of those departments to which each employee belongs. One those good old rules of thumb we discussed previously applies here:

If you need to store multiple values in a single column, your design is probably flawed.

The correct way to represent a many-to-many relationship is to add a third table, named a mapping table, to the database. A mapping table is a table that contains no data other than the definitions of the pairs of entries that are related. Figure 7.29 shows the database design for our employees and departments.

Figure 7.29. Using a mapping table to implement a many-to-many relationship

The EmployeeDepartment table associates employee IDs with department IDs.

If we added this table to our database, we could add Zak Ruvalcaba to both the “Executive” and “Engineering” departments.

A mapping table is created in much the same way as any other table. The only difference lies in the choice of the primary key. Every table we’ve created so far has had a column named somethingID that was designed to be that table’s primary key. Designating a column as a primary key tells the database not to allow two entries in that column to have the same value. It also speeds up database searches based on that column.

In the case of a mapping table, there's no single column that we want to force to have unique values. Each employee ID may appear more than once, as an employee may belong to more than one department, and each department ID may appear more than once, as a department may contain many employees. What we don’t

291