Using a Join to Connect Tables The only downside to disconnecting the data tables is the necessity to rejoin the data when needed. The user doesn’t care that the operation and the agent are in different tables, but he will want the data to look as if they were on the same table. The secret to reattaching tables is a tool called the inner join. Take a look at the following SELECT statement in SQL: SELECT agent.name AS agent, operation.name AS operation FROM agent, operation WHERE agent.operationID = operation.operationID ORDER BY agent.name; At first glance this looks like an ordinary query, but it is a little different. It joins data from two different tables. Table 11.5 illustrates the results of this query. Creating Useful Joins An SQL query can pull data from more than one table. To do this, follow a few basic rules. • Specify the field names more formally if necessary. Notice that the SELECT statement specifies agent.name rather than simply name. This is necessary because both tables contain a field called name. Using the table.field syntax is much like using a person’s first and last name. It’s not necessary if there’s no chance of confusion, but in a larger environment the more complete naming scheme can avoid confusion. • Use the AS clause to clarify your output. This provides an alias for the column and provides a nicer output. 373 C h a p t e r 1 1 D a t a N o r m a l i z a t i o n Agent Operation Blackford Enduring Angst Bond Dancing Elephant Cardinal Enduring Angst Falcon Dancing Elephant Rahab Furious Dandelion TABLE 11.5 COMBINING TWO TABLES • Modify the FROM clause so it indicates both of the tables you’re pulling data from. The FROM clause up to now has only specified one table. In this example, it’s necessary to specify that data will be coming from two different tables. • Indicate how the tables will be connected using a modification of the WHERE clause. Examining a Join without a WHERE Clause The WHERE clause helps clarify the relationship between two tables. As an expla- nation, consider the following query: SELECT agent.name AS ‘agent’, agent.operationID as ‘agent opID’, operation.operationID as ‘op opID’, operation.name AS ‘operation’ FROM agent, operation ORDER BY agent.name; This query is much like the earlier query, except it includes the operationID field from each table and it omits the WHERE clause. You might be surprised by the results, which are shown in Table 11.6. The results of this query are called a Cartesian join, which shows all possible combinations of agent and operation. Of course, you don’t really want all the combinations—only those combinations where the two tables indicate the same operation ID. Adding a WHERE Clause to Make a Proper Join Without a WHERE clause, all possible combinations are returned. The only concern- worthy records are those where the operationID fields in the agent and operation tables have the same value. The WHERE clause returns only these values joined by a common operation ID. The secret to making this work is the operationID fields in the two tables. You’ve already learned that each table should have a primary key. The primary key field is used to uniquely identify each database record. In the agents table, agentID is the primary key. In operations, operationID is the primary key. (You might note my unimaginative but very useful naming convention here.) 374 P H P 5 /M y S Q L P r o g r a m m i n g f o r t h e A b s o l u t e B e g i n n e r I was able to take all data that refers to the operation out of the agent table by replacing those fields with a field that points to the operations table’s primary key. A field that references the primary key of another table is called a foreign key . Primary and foreign keys cement the relationships between tables. Adding a Condition to a Joined Query Of course, you can still use the WHERE clause to limit which records are shown. Use the AND structure to build compound conditions. For example, this code returns the code name and operation name of every agent whose code name begins with B: SELECT agent.name AS ‘agent’, 375 C h a p t e r 1 1 D a t a N o r m a l i z a t i o n Agent Agent Op ID Op Op ID Operation Blackford 1 1 Dancing Elephant Blackford 1 2 Enduring Angst Blackford 1 3 Furious Dandelion Bond 1 1 Dancing Elephant Bond 1 2 Enduring Angst Bond 1 3 Furious Dandelion Cardinal 2 2 Enduring Angst Cardinal 2 3 Furious Dandelion Cardinal 2 1 Dancing Elephant Falcon 1 1 Dancing Elephant Falcon 1 2 Enduring Angst Falcon 1 3 Furious Dandelion Rahab 3 1 Dancing Elephant Rahab 3 2 Enduring Angst Rahab 3 3 Furious Dandelion Op = operation TABLE 11.6 JOINING AGENT AND OPERATION WITHOUT A WHERE CLAUSE 376 P H P 5 /M y S Q L P r o g r a m m i n g f o r t h e A b s o l u t e B e g i n n e r operation.name AS operation FROM agent, operation WHERE agent.operationID = operation.operationID AND agent.name LIKE ‘B%’; Building a Link Table for Many-to-Many Relationships Once you’ve created an ER diagram, you can create new tables to handle all the one-to-many relationships. It’s a little less obvious what to do with many-to-many relationships such as the link between agents and skills. Recall that each agent can have many skills, and several agents can use each skill. The best way to han- dle this kind of situation is to build a special kind of table. Enhancing the ER Diagram Figure 11.5 shows a new version of the ER diagram that eliminates all many-many relationships. The ER diagram in Figure 11.5 improves on the earlier version shown in Figure 11.4 in a number of ways. • I added (PK) to the end of every primary key. • I added (FK) to the end of every foreign key. THE TRUTH ABOUT INNER JOINS You should know that the syntax I provided here is a convenient shortcut sup- ported by most DBMS systems. The inner join’s formal syntax looks like this: SELECT agent.name, operation.name FROM agent INNER JOIN operation ON agent.OperationID = operation.OperationID ORDER BY agent.name; Many data programmers prefer to think of the join as part of the WHERE clause and use the WHERE syntax. A few SQL databases (notably many offerings from Microsoft) do not allow the WHERE syntax for inner joins and require the INNER JOIN to be specified as part of the FROM clause. When you use this INNER JOIN syntax, the ON clause indicates how the tables will be joined. • The placements of the lines in the diagram are now much more important. I now draw a line only between a foreign key reference and the correspond- ing primary key in the other table. Every relationship should go between a foreign key reference in one table and a primary key in the other. • The other main improvement is the addition of the agent_specialty table. This table is interesting because it contains nothing but primary and for- eign keys. Each entry in this table represents one link between the agent and specialty tables. All the actual data referring to the agent or specialty are encoded in other tables. This arrangement provides a great deal of flexibility. Most tables in a relational database are about entities in the data set, but link tables are about relationships between entities. Creating the specialty Table The specialty table is simple, as shown in Table 11.7. As you can see, there is nothing in the specialty table that connects it directly with any particular agent. Likewise, you find no references to specialties in the agent table. The complex relationship between these two tables is handled by the new agent_specialty table. This is called a link table because it manages relationships between other tables. Table 11.8 shows a sample set of data in the agent_specialty table. TRICK 377 C h a p t e r 1 1 D a t a N o r m a l i z a t i o n FIGURE 11.5 This newer ER diagram includes a special table to handle the many- many relationship