How to organize data in tables?

RDBMS tables are organized like other tables that you’re used to — in rows and columns. The place where a particular row and column intersect, the individual cell, is a field.
The focus of each table is an object (a thing) that you want to store information about. Here are some examples of objects:

Customers Shapes Rooms
Companies Projects Computers
Cities Products Documents
Books Animals Weeks

You create a table for each object. The table name should clearly identify the objects that it contains with a descriptive word or term. The name must be a character string, containing letters, numbers, underscores, or dollar signs, with no spaces in it. It’s customary to name the table in the singular. Thus, a name for a table of customers might be Customer, and a table containing customer orders might be named CustomerOrder. Uppercase and lowercase is significant on Linux and Unix but not on Windows: CustomerOrder and Customerorder are the same to Windows — but not to Linux or Unix.

In database talk, an object is an entity, and an entity has attributes. In the table, each row represents an entity, and the columns contain the attributes of each entity. For example, in a table of customers, each row contains information for a single customer. Some of the attributes contained in the columns might be first name, last name, phone number, and age.
Here are the steps for organizing your data into tables:

• Name your database. Assign a name to the database for your application. For instance, a database containing information about households in a neighborhood might be named HouseholdDirectory.
• Identify the objects. Look at the list of information that you want to store in the database (as discussed in the section, “Choosing the data,” earlier in this chapter). Analyze your list and identify the objects. For instance, the HouseholdDirectory database might need to store the following:
• Name of each family member
• Address of the house
• Phone number
• Age of each household member
• Favorite breakfast cereal of each household member
• When you analyze this list carefully, you realize that you’re storing information about two objects: the household and the household members. That is, the address and phone number are for the household in general, but the name, age, and favorite cereal are for a particular household member.
• Define and name a table for each object. For instance, the HouseholdDirectory database needs a table called Household and a table called HouseholdMember.
• Identify the attributes for each object. Analyze your information list and identify the attributes you need to store for each object. Break the information to be stored into its smallest reasonable pieces. For example, when storing the name of a person in a table, you can break the name into first name and last name. Doing this enables you to sort by the last name, which would be more difficult if the first and last name were stored together. You can even break down the name into first name, middle name, and last name, although not many applications need to use the middle name separately.
• Define and name columns for each separate attribute that you identified in Step 4. Give each column a name that clearly identifies the information in that column. The column names should be one word, with no spaces. For example, you might have columns named firstName and lastName or first_name and last_name.
• Some words are reserved by MySQL and SQL for their own use and can’t be used as column names. The words are currently used in SQL statements or are reserved for future use. For example, ADD, ALL, AND, CREATE, DROP, GROUP, ORDER, RETURN, SELECT, SET, TABLE, USE, WHERE, and many, many more can’t be used as column names. For a complete list of reserved words, see the online MySQL manual at www.mysql.com/doc/en/Reserved_words.html.
• Identify the primary key. Each row in a table needs a unique identifier. No two rows in a table should be exactly the same. When you design your table, you decide which column holds the unique identifier, called the primary key. The primary key can be more than one column combined. In many cases, your object attributes will not have a unique identifier. For example, a customer table might not have a unique identifier because two customers can have the same name. When there is no unique identifier column, you need to add a column specifically to be the primary key. Frequently, a column with a sequence number is used for this purpose.
  
• Define the defaults. You can define a default that MySQL will assign to a field when no data is entered into the field. A default is not required but is often useful. For example, if your application stores an address that includes a country, you can specify US as the default. If the user does not type a country, US will be entered.
• Identify columns that require data. You can specify that certain columns are not allowed to be empty (also called NULL). For instance, the column containing your primary key can’t be empty. That means that MySQL will not create the row and will return an error message if no value is stored in the column. The value can be a blank space or an empty string (for example, “”), but some value must be stored in the column. Other columns, in addition to the primary key, can be set to require data.

Well-designed databases store each piece of information in only one place. Storing it in more than one place is inefficient and creates problems if information needs to be changed. If you change information in one place but forget to change it in another place, your database can have serious problems. If you find that you’re storing the same data in several rows, you probably need to reorganize your tables. For example, suppose you’re storing data about books, including the publisher’s address. When you enter the data, you realize that you’re entering the same publisher’s address in many rows.

A more efficient way to store this data would be to store the book information in one table and the book publisher information in a separate table. You can define two tables: Book and BookPublisher. In the Book table, you would have the columns title, author, pub_date, and price. In the BookPublisher table, you would have columns such as name, streetAddress, and city.