PHP 5/MySQL Programming- P80 pdf

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