Phát triển web với PHP và MySQL - p 21 ppsx

The relational database term for this relationship is foreign key. CustomerID is the primary
key in Customers, but when it appears in another table, such as Orders, it is referred to as a
foreign key.
You might wonder why we chose to have two separate tables—why not just store Julie’s
address in the Orders table? We’ll explore this in more detail in the next section.
Schemas
The complete set of the table designs for a database is called the database schema. It is akin to
a blueprint for the database. A schema should show the tables along with their columns, the
data types of the columns and indicate the primary key of each table and any foreign keys. A
schema does not include any data, but you might want to show sample data with your schema
to explain what it is for. The schema can be shown as it is in the diagrams we are using, in
entity relationship diagrams (which are not covered in this book), or in a text form, such as
Customers(CustomerID, Name, Address, City)
Orders(OrderID, CustomerID, Amount, Date)
Underlined terms in the schema are primary keys in the relation in which they are underlined.
Dotted underlined terms are foreign keys in the relation in which they appear with a dotted
underline.
Relationships
Foreign keys represent a relationship between data in two tables. For example, the link from
Orders to Customers represents a relationship between a row in the Orders table and a row in
the Customers table.
Three basic kinds of relationships exist in a relational database. They are classified according
to the number of things on each side of the relationship. Relationships can be either one-to-
one, one-to-many, or many-to-many.
A one-to-one relationship means that there is one of each thing in the relationship. For exam-
ple, if we had put addresses in a separate table from Customers, there would be a one-to-one
relationship between them. You could have a foreign key from Addresses to Customer or the
other way around (both are not required).
In a one-to-many relationship, one row in one table is linked to many rows in another table. In
this example, one Customer might place many Orders. In these relationships, the table that
contains the many rows will have a foreign key to the table with the one row. Here, we have

put the CustomerID into the Order table to show the relationship.
In a many-to-many relationship, many rows in one table are linked to many rows in another table.
For example, if we had two tables,
Books and Authors, you might find that one book had been
Designing Your Web Database
C
HAPTER 7
7
DESIGNING YOUR
WEB DATABASE
175
10 7842 CH07 3/6/01 3:34 PM Page 175
written by two coauthors, each of whom had written other books, on their own or possibly with
other authors. This type of relationship usually gets a table all to itself, so you might have Books,
Authors, and Books_Authors. This third table would only contain the keys of the other tables as
foreign keys in pairs, to show which authors have been involved with which books.
How to Design Your Web Database
Knowing when you need a new table and what the key should be can be something of an art.
You can read huge reams of information about entity relationship diagrams and database nor-
malization, which are beyond the scope of this book. Most of the time, however, you can fol-
low a few basic design principles. Let’s consider these in the context of Book-O-Rama.
Think About the Real World Objects You Are Modeling
When you create a database, you are usually modeling real-world items and relationships and
storing information about those objects and relationships.
Generally, each class of real-world objects you model will need its own table. Think about it:
We want to store the same information about all our customers. If there is a set of data that has
the same “shape,” we can easily create a table corresponding to that data.
In the Book-O-Rama example, we want to store information about our customers, the books
that we sell, and details of the orders. The customers all have a name and address. The orders
have a date, a total amount, and a set of books that were ordered. The books have an ISBN, an

author, a title, and a price.
This suggests we need at least three tables in this database: Customers, Orders, and Books.
This initial schema is shown in Figure 7.3.
At present, we can’t tell from the model which books were ordered in each order. We will deal
with this in a minute.
Avoid Storing Redundant Data
Earlier, we asked the question: “Why not just store Julie Smith’s address in the Orders table?”
If Julie orders from Book-O-Rama on a number of occasions, which we hope she will, we will
end up storing her data multiple times. You might end up with an Orders table that looks like
the one shown in Figure 7.4.
There are two basic problems with this.
The first is that it’s a waste of space. Why store Julie’s details three times if we only have to
store them once?
Using MySQL
P
ART II
176
10 7842 CH07 3/6/01 3:34 PM Page 176
Designing Your Web Database
C
HAPTER 7
7
DESIGNING YOUR
WEB DATABASE
177
CustomerID
CUSTOMERS
Name Address City
1 Julie Smith 25 Oak Street Airport West
2 Alan Wong 1/47 Haines Avenue Box Hill

3 Michelle Arthur 357 North Road Yarraville
ISBN
BOOKS
Author Title Price
0-672-31687-8 Michael Morgan Java 2 for Professional Developers 34.99
0-672-31745-1 Thomas Down Installing Debian GNU/Linux 24.99
0-672-31509-2 Pruitt, et al. Teach Yourself GIMP in 24 Hours 24.99
OrderID
ORDERS
CustomerID Amount Date
1 3 27.50 02-Apr-2000
2 1 12.99 15-Apr-2000
3 2 74.00 19-Apr-2000
4 4 6.99 01-May-2000
OrderID
ORDERS
CustomerIDAmount Date
12 1199.50 25-Apr-2000
13 143.00 29-Apr-2000
14 115.99 30-Apr-2000
15 123.75 01-May-2000
Name
Julie Smith
Julie Smith
Julie Smith
Julie Smith
Address
28 Oak Street
28 Oak Street
28 Oak Street

28 Oak Street
City
Airport West
Airport West
Airport West
Airport West
FIGURE 7.3
The initial schema consists of Customers, Orders, and Books.
FIGURE 7.4
A database design that stores redundant data takes up extra space and can cause anomalies in the data.
The second problem is that it can lead to update anomalies, that is, situations where we change
the database and end up with inconsistent data. The integrity of the data is violated and we no
longer know which data is correct and which incorrect. This generally leads to losing informa-
tion.
Three kinds of update anomalies need to be avoided: modification, insertion, and deletion
anomalies.
If Julie moves house while she has pending orders, we will need to update her address in three
places instead of one, doing three times as much work. It is easy to overlook this fact and only
change her address in one place, leading to inconsistent data in the database (a very bad thing).
These problems are called modification anomalies because they occur when we are trying to
modify the database.
10 7842 CH07 3/6/01 3:34 PM Page 177
With this design, we need to insert Julie’s details every time we take an order, so each time we
must check and make sure that her details are consistent with the existing rows in the table. If we
don’t check, we might end up with two rows of conflicting information about Julie. For example,
one row might tell us that Julie lives in Airport West, and another might tell us she lives in
Airport. This is called an insertion anomaly because it occurs when data is being inserted.
The third kind of anomaly is called a deletion anomaly because it occurs (surprise, surprise)
when we are deleting rows from the database. For example, imagine that when an order has
been shipped, we delete it from the database. When all Julie’s current orders have been ful-

filled, they are all deleted from the Orders table. This means that we no longer have a record of
Julie’s address. We can’t send her any special offers, and next time she wants to order some-
thing from us, we will have to get her details all over again.
Generally you want to design your database so that none of these anomalies occur.
Use Atomic Column Values
This means that in each attribute in each row, we store only one thing. For example, we need to
know what books make up each order. There are several ways we could do this.
We could add a column to the Orders table which lists all the books that have been ordered, as
shown in Figure 7.5.
Using MySQL
P
ART II
178
OrderID
ORDERS
CustomerID Amount Date
1 3 27.50 02-Apr-2000
2 1 12.99 15-Apr-2000
3 2 74.00 19-Apr-2000
4 3 6.99 01-May-2000
Books Ordered
0-672-31697-8
0-672-31745-1, 0-672-31509-2
0-672-31697-8
0-672-31745-1, 0-672-31509-2, 0-672-31697-8
FIGURE 7.5
With this design, the Books Ordered attribute in each row has multiple values.
This isn’t a good idea for a few reasons. What we’re really doing is nesting a whole table
inside one column—a table that relates orders to books. When you do it this way, it becomes
more difficult to answer questions like “How many copies of Java 2 for Professional

Developers have been ordered?” The system can no longer just count the matching fields.
Instead, it has to parse each attribute value to see if it contains a match anywhere inside it.
Because we’re really creating a table-inside-a-table, we should really just create that new table.
This new table is called Order_Items and is shown in Figure 7.6.
This table provides a link between the
Orders table and the Books table. This type of table is
common when there is a many-to-many relationship between two objects—in this case, one
order might consist of many books, and each book can be ordered by many people.
10 7842 CH07 3/6/01 3:34 PM Page 178
Choose Sensible Keys
Make sure that the keys you choose are unique. In this case, we’ve created a special key for
customers (CustomerID) and for orders (OrderID) because these real-world objects might not
naturally have an identifier that can be guaranteed to be unique. We don’t need to create a
unique identifier for books—this has already been done, in the form of an ISBN. For
Order_Item, you can add an extra key if you want, but the combination of the two attributes
OrderID and ISBN will be unique as long as more than one copy of the same book in an order
is treated as one row. For this reason, the table Order_Items has a Quantity column.
Designing Your Web Database
C
HAPTER 7
7
DESIGNING YOUR
WEB DATABASE
179
OrderID
ORDER_ITEMS
Quantity
11
22
21

31
ISBN
0-672-31697-8
0-672-31745-1
0-672-31509-2
0-672-31697-8
410-672-31745-1
420-672-31509-2
410-672-31697-8
FIGURE 7.6
This design makes it easier to search for particular books that have been ordered.
Think About the Questions You Want to Ask the
Database
Continuing from the last section, think about what questions you want the database to answer.
(Think back to those questions we mentioned at the start of the chapter. For example, what are
Book-O-Rama’s bestselling books?) Make sure that the database contains all the data required,
and that the appropriate links exist between tables to answer the questions you have.
Avoid Designs with Many Empty Attributes
If we wanted to add book reviews to the database, there are at least two ways we could do this.
These two approaches are shown in Figure 7.7.
ISBN
BOOKS
Author
ISBN
BOOK_REVIEWS
Review
Title Price
0-672-31687-8 Michael Morgan Java 2 for Professional Developers 34.99
0-672-31745-1 Thomas Down Installing Debian GNU/Linux 24.99
0-672-31509-2 Pruitt, et al. Teach Yourself GIMP in 24 Hours 24.99

Review
FIGURE 7.7
To add reviews, we can either add a Review column to the Books table, or add a table specifically for
reviews.
10 7842 CH07 3/6/01 3:34 PM Page 179
The first way means adding a Review column to the Books table. This way, there is a field for
the Review to be added for each book. If many books are in the database, and the reviewer
doesn’t plan to review them all, many rows won’t have a value in this attribute. This is called
having a null value.
Having many null values in your database is a bad idea. It wastes storage space and causes
problems when working out totals and other functions on numerical columns. When a user sees
a null in a table, they don’t know if it’s because this attribute is irrelevant, whether there’s a
mistake in the database, or whether the data just hasn’t been entered yet.
You can generally avoid problems with many nulls by using an alternate design. In this case,
we can use the second design proposed in Figure 7.7. Here, only books with a review are listed
in the
Book_Reviews table, along with their review.
Note that this design is based on the idea of having a single in-house reviewer. We could just
as easily let customers author reviews. If we wanted to do this, we could add the CustomerID
to the
Book_Reviews table.
Summary of Table Types
You will usually find that your database design ends up consisting of two kinds of table:
• Simple tables that describe a real-world object. These might also contain keys to other
simple objects where there is a one-to-one or one-to-many relationship. For example, one
customer might have many orders, but an order is placed by a single customer. Thus, we
put a reference to the customer in the order.
• Linking tables that describe a many-to-many relationship between two real objects such
as the relationship between Orders and Books. These tables are often associated with
some kind of real-world transaction.

Web Database Architecture
Now that we’ve discussed the internal architecture of your database, we’ll look at the external
architecture of a Web database system, and discuss the methodology for developing a Web
database system.
Architecture
The basic operation of a Web server is shown in Figure 7.8. This system consists of two
objects: a Web browser and a Web server. A communication link is required between them. A
Web browser makes a request of the server. The server sends back a response. This architecture
suits a server delivering static pages well. The architecture that delivers a database backed Web
site is a little more complex.
Using MySQL
P
ART II
180
10 7842 CH07 3/6/01 3:34 PM Page 180
FIGURE 7.8
The client/server relationship between a Web browser and Web server requires communication.
The Web database applications we will build in this book follow a general Web database struc-
ture that is shown in Figure 7.9. Most of this structure should already be familiar to you.
Designing Your Web Database
C
HAPTER 7
7
DESIGNING YOUR
WEB DATABASE
181
Browser
Response
Request
Web Server

Browser
6
1
Web Server
5
2
PHP Engine
4
3
MySQL Server
FIGURE 7.9
The basic Web database architecture consists of the Web browser, Web server, scripting engine, and database server.
A typical Web database transaction consists of the following stages, which are numbered in
Figure 7.9. We will examine the stages in the context of the Book-O-Rama example.
1. A user’s Web browser issues an HTTP request for a particular Web page. For example,
she might have requested a search for all the books at Book-O-Rama written by Laura
Thomson, using an HTML form. The search results page is called results.php.
2. The Web server receives the request for results.php, retrieves the file, and passes it to the
PHP engine for processing.
3. The PHP engine begins parsing the script. Inside the script is a command to connect to
the database and execute a query (perform the search for books). PHP opens a connec-
tion to the MySQL server and sends on the appropriate query.
4. The MySQL server receives the database query and processes it, and sends the results—
a list of books—back to the PHP engine.
5. The PHP engine finishes running the script, which will usually involve formatting the
query results nicely in HTML. It then returns the resulting HTML to the Web server.
6. The Web server passes the HTML back to the browser, where the user can see the list of
books she requested.
The process is basically the same regardless of which scripting engine or database server you
use. Often the Web server software, the PHP engine, and the database server all run on the

same machine. However, it is also quite common for the database server to run on a different
machine. You might do this for reasons of security, increased capacity, or load spreading. From
a development perspective, this will be much the same to work with, but it might offer some
significant advantages in performance.
10 7842 CH07 3/6/01 3:34 PM Page 181
Further Reading
In this chapter, we covered some guidelines for relational database design. If you want to delve
into the theory behind relational databases, you can try reading books by some of the relational
gurus like C.J. Date. Be warned, however, that the material can get pretty theoretical and might
not be immediately relevant to a commercial Web developer. Your average Web database tends
not to be that complicated.
Next
In the next chapter, we’ll start setting up your MySQL database. First you’ll learn how to set
up a MySQL database for the Web, how to query it, and then how to query it from PHP.
Using MySQL
P
ART II
182
10 7842 CH07 3/6/01 3:34 PM Page 182
CHAPTER
8
Creating Your Web Database
11 7842 CH08 3/6/01 3:38 PM Page 183
Using MySQL
P
ART II
184
In this chapter we’ll talk about how to set up a MySQL database for use on a Web site.
We’ll cover
• Creating a database

• Users and privileges
• Introduction to the privilege system
• Creating database tables
• Column types in MySQL
In this chapter, we’ll follow through with the Book-O-Rama online bookstore application dis-
cussed in the last chapter. As a reminder, here is the schema for the Book-O-Rama application:
Customers(CustomerID, Name, Address, City)
Orders(OrderID, CustomerID, Amount, Date)
Books(ISBN, Author, Title, Price)
Order_Items(OrderID, ISBN, Quantity)
Book_Reviews(ISBN, Reviews)
Remember that primary keys are underlined and foreign keys have a dotted underline.
In order to use the material in this section, you must have access to MySQL. This usually
means that you
1. Have completed the basic install of MySQL on your Web server. This includes
• Installing the files
• Setting up a user for MySQL to run as
• Setting up your path
• Running mysql_install_db, if required
• Setting the root password
• Deleting the anonymous user
• Starting the MySQL server and setting it up to run automatically
If you’ve done all those things, you can go right ahead and read this chapter. If you
haven’t, you can find instructions on how to do these things in Appendix A, “Installing
PHP 4 and MySQL.”
If you have problems at any point in this chapter, it might be because your MySQL sys-
tem is not set up correctly. If that happens, refer back to this list and Appendix A to make
sure that your set up is correct.
11 7842 CH08 3/6/01 3:38 PM Page 184