Basic Database Terminology

You may have noticed that you're already several pages into a database book and still haven't seen a whole bunch of jargon and technical terminology. In fact, I still haven't said anything at all about what "a database" actually looks like, even though we have a rough specification of how our sample database will be used. However, we're about to design that database, and then we'll begin implementing it, so we can't avoid terminology any longer. That's what this section is about. It describes some terms that come up throughout the book so that you'll be familiar with them. Fortunately, many relational database concepts are really quite simple. In fact, much of the appeal of relational databases stems from the simplicity of their foundational concepts.

Structural Terminology

Within the database world, MySQL is classified as a relational database management system (RDBMS). That phrase breaks down as follows:

• The database (the "DB" in RDBMS) is the repository for the information you want to store, structured in a simple, regular fashion:

  • The collection of data in a database is organized into tables.

  • Each table is organized into rows and columns.

  • Each row in a table is a record.

  • Records may contain several pieces of information; each column in a table corresponds to one of those pieces.

• The management system (the "MS") is the software that lets you use your data by allowing you to insert, retrieve, modify, or delete records.

• The word "relational" (the "R") indicates a particular kind of DBMS, one that is very good at relating (that is, matching up) information stored in one table to information stored in another by looking for elements common to each of them. The power of a relational DBMS lies in its ability to pull data from those tables conveniently and to join information from related tables to produce answers to questions that can't be answered from individual tables alone.

Here's an example that shows how a relational database organizes data into tables and relates the information from one table to another. Suppose you run a Web site that includes a banner-advertisement service. You contract with companies that want their ads displayed when people visit the pages on your site. Each time a visitor hits one of your pages, you serve the ad embedded in the page to the visitor's browser and assess the company a small fee. To represent this information, you maintain three tables (see Figure 1.1). One table, company, has columns for company name, number, address, and telephone number. Another table, ad, lists ad numbers, the number for the company that "owns" the ad, and the amount you charge per hit. The third table, hits, logs ad hits by ad number and the date on which the ad was served.

Some questions can be answered from this information using a single table. To determine the number of companies you have contracts with, you need count only the rows in the company table. Similarly, to determine the number of hits during a given time period, only the hit table need be examined. Other questions are more complex, and it's necessary to consult multiple tables to determine the answers. For example, to determine how many times each of the ads for Pickles, Inc. was served on July 14, you'd use all three tables as follows:

Sounds complicated! But that's just the kind of thing at which relational database systems excel. The complexity is actually somewhat illusory because each of the steps just described really amounts to little more than a simple matching operation: You relate one table to another by matching values from one table's rows to values in another table's rows. This same simple operation can be exploited in various ways to answer all kinds of questions: How many different ads does each company have? Which company's ads are most popular? How much revenue does each ad generate? What is the total fee for each company for the current billing period?

Now you know enough relational database theory to understand the rest of the book, and we don't have to go into Third Normal Form, Entity-Relationship Diagrams, and all that kind of stuff. If you really want to know about such things, that's terrific, but you're in the wrong place to find out. I suggest you begin by reading some C.J. Date or E.F. Codd.

Query Language Terminology

To communicate with MySQL, you use a language called SQL (Structured Query Language). SQL is today's standard database language, and all major database systems understand it. SQL includes many different kinds of statements, all designed to make it possible to interact with your database in interesting and useful ways.

As with any language, SQL may seem strange while you're first learning it. For example, to create a table, you need to tell MySQL what the table's structure should be. You and I might think of the table in terms of a diagram or picture, but MySQL doesn't, so you create the table by telling MySQL something like this:

CREATE TABLE company
(
    company_name CHAR(30),
    company_num INT,
    address CHAR(30),
    phone CHAR(12)
)

When you're new to SQL, statements like that can be somewhat imposing, but you don't need to be a programmer to learn how to use SQL effectively. As you gain familiarity with the language, you'll look at CREATE TABLE in a different light—as an ally that helps you describe your information, not as just a weird bit of gibberish.

MySQL Architecture Terminology

When you use MySQL, you're actually using two programs because MySQL operates using a client/server architecture:

• The database server is a program located on the machine where your data are stored. It listens for client requests coming in over the network and accesses database contents according to those requests to provide clients with the information they ask for.

• Clients are programs that connect to the database server and issue queries to tell it what information they want.

The MySQL distribution includes the server and several client programs. You use the clients according to the purposes you want to achieve. The one most commonly used is mysql, an interactive client that lets you issue queries and see the results. Other clients include mysqldump and mysqlimport, which dump table contents into a file and vice versa, and mysqladmin, which allows you to check on the status of the server and performs administrative tasks, such as telling the server to shut down. If you have applications for which the standard clients are unsuited, MySQL also provides a client-programming library so that you can write your own programs. The library is usable directly from C programs, and several other interfaces are available if you prefer a language other than C.

MySQL's client/server architecture has certain benefits:

• The server provides concurrency control so that two users cannot modify the same record at the same time. All client requests go through the server, so the server sorts out who gets to do what, and when. If multiple clients want to access the same table at the same time, they don't all have to find and negotiate with each other. They just send their requests to the server and let it take care of determining the order in which the requests will be performed.

• You don't have to be logged in on the machine where your database is located. MySQL understands how to work over the Internet, so you can run a client program from wherever you happen to be, and the client can connect to the server over the network. Distance isn't a factor; you can access the server from anywhere in the world. If the server is located on a computer in Australia, you can take your laptop computer on a trip to Iceland and still access your database.

  Does that mean anyone can get at your data, just by connecting to the Internet? No. MySQL includes a flexible security system, so you can allow access only to people who should have it. And you can make sure those people are able to do only what they should. Perhaps Sally in the billing office should be able to read and update (modify) records, but Phil at the service desk should be able only to look at them. You can set their privileges accordingly. If you do want to run a self-contained system, just set the access privileges so that clients can connect only from the host on which the server is running.