| This section describes the sample database we'll use throughout the rest of this book. It gives you a source of examples you can try out as you learn to put MySQL to work. We'll draw examples primarily from two of the situations described earlier: The organizational secretary scenario. We need something more definite than "an organization," so I'll make one up with these characteristics: It's composed of people drawn together through a common affinity for United States history (called, for lack of a better name, the U.S. Historical League). The members maintain their affiliation by renewing their memberships periodically on a dues-paying basis. Dues go toward the expenses incurred by the League, such as publication of a newsletter, Chronicles of U.S. Past. The League also operates a small Web site, but it hasn't been developed very much. Thus far, the site has been limited to basic information, such as what the League is about, who the officers are, and how people can join. The grade-keeping scenario. During the grading period, you administer quizzes and tests, record scores, and assign grades. Afterward, you determine final grades, which you turn in to the school office along with an attendance summary. Now let's examine these situations more closely in terms of two requirements: -
You have to decide what you want to get out of the database that is, what goals you want to accomplish. -
You have to figure out what you're going to put into the database that is, what data you will keep track of.
Perhaps it seems backward to think about what comes out of the database before considering what goes into it. After all, you must enter your data before you can retrieve it. But the way you use a database is driven by your goals, and those are more closely associated with what you want to get from your database than with what you put into it. You certainly aren't going to waste time and effort putting information into a database unless you're going to use it for something later. The U.S. Historical League The initial situation for this scenario is that you as League secretary maintain the membership list using a word processing document. That works reasonably well for generating a printed directory but limits what else you can do with the information. You have the following objectives in mind: You want to be able to produce output from the directory in different formats, using only information appropriate to the application. One goal is to be able to generate the printed directory each year a requirement the League has had in the past that you plan to continue to carry out. You can think of other uses for the information in the directory, too for example, to provide the current member list for the printed program that's handed out to attendees of the League's annual banquet. These applications involve different sets of information. The printed directory uses the entire contents of each member's entry. For the banquet program, you need to pull out only member names (something that hasn't been easy using a word processor). You want to search the directory for members whose entries satisfy various criteria. For example, you want to know which members need to renew their memberships soon. Another application that involves searching arises from the list of keywords you maintain for each member. These keywords describe areas of U.S. history in which each member is particularly interested (for example, the Civil War, the Depression, civil rights, or the life of Thomas Jefferson). Members sometimes ask you for a list of other members with interests similar to their own, and you'd like to be able to satisfy these requests. You want to put the directory online at the League's Web site. This would benefit both the members and yourself. If you could convert the directory to Web pages by some reasonably automated process, an online version of the directory could be kept up to date in a more timely fashion than the printed version. And if the online directory could be made searchable, members could look for information easily themselves. For example, a member who wants to know which other members are interested in the Civil War could find that out without waiting for you to perform the search, and you wouldn't need to find the time to do it yourself. I'm well aware that databases are not the most exciting things in the world, so I'm not about to make any wild claims that using one stimulates creative thinking. Nevertheless, when you stop thinking of information as something you must wrestle with (as you do with your word processing document) and begin thinking of it as something you can manipulate relatively easily (as you hope to do with MySQL), it has a certain liberating effect on your ability to come up with new ways to use or present that information: If the information in the database can be moved to the Web site in the form of an online directory, you might be able to make information flow the other way. For example, if members could edit their own entries online to update the database, you wouldn't have to do all the editing yourself, and it would help make the information in the directory more accurate. If you stored email addresses in the database, you could use them to send email to members who haven't updated their entries in a while. The messages could show members the current contents of their entries, ask them to review it, and indicate how to make any needed modifications using the facilities provided on the Web site. A database might help you make the Web site more useful in ways not even related to the membership list. The League publishes a newsletter, Chronicles of U.S. Past, that has a children's section in each issue containing a history-based quiz. Some of the recent issues have focused on biographical facts about U.S. presidents. The Web site could have a children's section, too, where the quizzes are put online. Perhaps this section could even be made interactive by putting the information from which quizzes are drawn in the database and having the Web server query the database for questions to present to visitors. Well! At this point the number of uses for the database that you're coming up with may make you realize that you could be getting a little carried away. After pausing to come back down to earth, you start asking some practical questions: Isn't this a little ambitious? Won't it be a lot of work to set this up? Anything's easier when you're just thinking about it and not doing it, of course, and I won't pretend that all of this will be trivial to implement. Nevertheless, you'll have done everything we've just outlined by the end of this book. Just keep one thing in mind: It's not necessary to do everything all at once. We'll break the job into pieces and tackle it a piece at a time. Can MySQL do all these things? No it can't, at least not by itself. For example, MySQL has no direct Web-programming facilities. But even though MySQL alone cannot do everything we've discussed, you can combine MySQL with other tools that work with it to complement and extend its capabilities. We'll use the Perl scripting language and the DBI (database interface) Perl module to write scripts that access MySQL databases. Perl has excellent text-processing capabilities that allow for manipulation of query results in a highly flexible manner to produce output in a variety of formats. For example, we can use Perl to generate the directory in Rich Text Format (RTF), a format that can be read by all kinds of word processors. We'll also use PHP, another scripting language. PHP is particularly adapted to writing Web applications, and it interfaces easily with databases. This allows you to run MySQL queries right from Web pages and to generate new pages that include the results of database queries. PHP works well with Apache (the most popular Web server in the world), making it easy to do things such as presenting a search form and displaying the results of the search. MySQL integrates well with these tools and gives you the flexibility to choose how to combine them to achieve the ends you have in mind. You're not locked into some all-in-one suite's components that have highly touted "integration" capabilities but that actually work well only with each other. And, finally, the big question how much will all this cost? The League has a limited budget, after all. This may surprise you, but it probably won't cost anything. If you're familiar with the usual ken of database systems, you know that they're generally pretty pricey. By contrast, MySQL is usually free. (See the MySQL Reference Manual for specific details.) The other tools we'll use (Perl, DBI, PHP, Apache) are free, so, all things considered, you can put together a useful system quite inexpensively. The choice of operating system for developing the database is up to you. Virtually all the software we'll discuss runs under both UNIX (which I use as an umbrella term that includes BSD UNIX, Linux, Mac OS X, and so on) and Windows. The few exceptions tend to be shell or batch scripts that are specific to either UNIX or Windows. Now let's consider the other situation for which we'll be using the sample database. The Grade-Keeping Project The initial scenario here is that as a teacher, you have grade keeping responsibilities. You want to convert the grading process from a manual operation using a gradebook to an electronic representation using MySQL. In this case, the information you want to get from a database is implicit in the way you use your gradebook now: For each quiz or test, you record the scores. For tests, you put the scores in order so that you can look at them and determine the cutoffs for each letter grade (A, B, C, D, and F). At the end of the grading period, you calculate each student's total score, sort the totals, and then determine grades based on them. The totals might involve weighted calculations because you probably want to count tests more heavily than quizzes. You provide attendance information to the school office at the end of the grading period. The objectives are to avoid manually sorting and summarizing scores and attendance records. In other words, you want MySQL to sort the scores and perform the calculations necessary to compute each student's total score and number of absences when the grading period ends. To achieve these goals, you'll need the list of students in the class, the scores for each quiz and test, and the dates on which students are absent. How the Sample Database Applies to You If you're not particularly interested in the Historical League or in grade keeping, you may be wondering what any of this has to do with you. The answer is that these example scenarios aren't an end in themselves. They simply provide a vehicle by which to illustrate what you can do with MySQL and tools that are related to it. With a little imagination, you'll see how example database queries apply to the particular problems you want to solve. Suppose you're working in that dentist's office I mentioned earlier. You won't see many dentistry-related queries in this book, but you will see that many of the queries you find here apply to patient record maintenance, office bookkeeping, and so on. For example, determining which Historical League members need to renew their memberships soon is similar to determining which patients haven't visited the dentist for a while. Both are date-based queries, so once you learn to write the membership-renewal query, you can apply that skill to writing the delinquent-patient query in which you have a more immediate interest. |
