About this course

This course includes:

Goals
After completing this course you will be able to:

Two self-paced lessons and two practice sessions for hands-on experience. A short test at the end of each lesson; tests are not scored. A Quick Reference Card you can take away from the course.

Create a select query. Refine a query in Design view. Retrieve data that matches the criteria you specify.

Database design basics

Applies to: Microsoft Office Access 2007

Print

A properly designed database provides you with access to up-to-date, accurate information. Because a correct design is essential to achieving your goals in working with a database, investing the time required to learn the principles of good design makes sense. In the end, you are much more likely to end up with a database that meets your needs and can easily accommodate change. This article provides guidelines for planning a database. You will learn how to decide what information you need, how to divide that information into the appropriate tables and columns, and how those tables relate to each other. You should read this article before you create your first database.

In this article

Some database terms to know What is good database design? The design process Determining the purpose of your database Finding and organizing the required information Dividing the information into tables Turning information items into columns Specifying primary keys Creating the table relationships Refining the design Applying the normalization rules

Some database terms to know

Microsoft Office Access 2007 organizes your information into tables: lists of rows and columns reminiscent of an accountants pad or a Microsoft Office Excel 2007 worksheet. In a simple database, you might have only one table. For most databases you will need more than one. For example, you might have a table that stores information about products, another table that stores information about orders, and another table with information about customers.

Each row is also called a record, and each column, is also called a field. A record is a meaningful and consistent way to combine information about something. A field is a single item of information an item type that appears in every record. In the Products table, for instance, each row or record would hold information about one product. Each column or field holds some type of information about that product, such as its name or price.

TOP OF PAGE

What is good database design?

Certain principles guide the database design process. The first principle is that duplicate information (also called redundant data) is bad, because it wastes space and increases the likelihood of errors and inconsistencies. The second principle is that the correctness and completeness of information is important. If your database contains incorrect information, any reports that pull information from the database will also contain incorrect information. As a result, any decisions you make that are based on those reports will then be misinformed. A good database design is, therefore, one that:

Divides your information into subject-based tables to reduce redundant data. Provides Access with the information it requires to join the information in the tables together as needed. Helps support and ensure the accuracy and integrity of your information. Accommodates your data processing and reporting needs.

TOP OF PAGE

The design process

The design process consists of the following steps:

Determine the purpose of your database This helps prepare you for the remaining steps.

Find and organize the information required Gather all of the types of information you might want to record in the database, such as product name and order number.

Divide the information into tables Divide your information items into major entities or subjects, such as Products or Orders. Each subject then becomes a table.

Turn information items into columns Decide what information you want to store in each table. Each item becomes a field, and is displayed as a column in the table. For example, an Employees table might include fields such as Last Name and Hire Date.

Specify primary keys Choose each tables primary key. The primary key is a column that is used to uniquely identify each row. An example might be Product ID or Order ID.

Set up the table relationships Look at each table and decide how the data in one table is related to the data in other tables. Add fields to tables or create new tables to clarify the relationships, as necessary.

Refine your design Analyze your design for errors. Create the tables and add a few records of sample data. See if you can get the results you want from your tables. Make adjustments to the design, as needed.

Apply the normalization rules Apply the data normalization rules to see if your tables are structured correctly. Make adjustments to the tables, as needed.

TOP OF PAGE

Determining the purpose of your database

It is a good idea to write down the purpose of the database on paper its purpose, how you expect to use it, and who will use it. For a small database for a home based business, for example, you might write something simple like "The customer database keeps a list of customer information for the purpose of producing mailings and reports." If the database is more complex or is used by many people, as often occurs in a corporate setting, the purpose could easily be a paragraph or more and should include when and how each person will use the database. The idea is to have a well developed mission statement that can be referred to throughout the design process. Having such a statement helps you focus on your goals when you make decisions.

TOP OF PAGE

Finding and organizing the required information

To find and organize the information required, start with your existing information. For example, you might record purchase orders in a ledger or keep customer information on paper forms in a file cabinet. Gather those documents and list each type of information shown (for example, each box that you fill in on a form). If you don't have any existing forms, imagine instead that you have to design a form to record the customer information. What information would you put on the form? What fill-in boxes would you create? Identify and list each of these items. For example, suppose you currently keep the customer list on index cards. Examining these cards might show that each card holds a customers name, address, city, state, postal code and telephone number. Each of these items represents a potential column in a table.

As you prepare this list, dont worry about getting it perfect at first. Instead, list each item that comes to mind. If someone else will be using the database, ask for their ideas, too. You can fine-tune the list later. Next, consider the types of reports or mailings you might want to produce from the database. For instance, you might want a product sales report to show sales by region, or an inventory summary report that shows product inventory levels. You might also want to generate form letters to send to customers that announces a sale event or offers a premium. Design the report in your mind, and imagine what it would look like. What information would you place on the report? List each item. Do the same for the form letter and for any other report you anticipate creating.

Giving thought to the reports and mailings you might want to create helps you identify items you will need in your database. For example, suppose you give customers the opportunity to opt in to (or out of) periodic e-mail updates, and you want to print a listing of those who have opted in. To record that information, you add a Send e-mail column to the customer table. For each customer, you can set the field to Yes or No. The requirement to send e-mail messages to customers suggests another item to record. Once you know that a customer wants to receive email messages, you will also need to know the e-mail address to which to send them. Therefore you need to record an e-mail address for each customer. It makes good sense to construct a prototype of each report or output listing and consider what items you will need to produce the report. For instance, when you examine a form letter, a few things might come to mind. If you want to include a proper salutation for example, the "Mr.", "Mrs." or "Ms." string that starts a greeting, you will have to create a salutation item. Also, you might typically start a letter with Dear Mr. Smith, rather than Dear. Mr. Sylvester Smith. This suggests you would typically want to store the last name separate from the first name. A key point to remember is that you should break each piece of information into its smallest useful parts. In the case of a name, to make the last name readily available, you will break the name into two parts First Name and Last Name. To sort a report by last name, for example, it helps to have the customer's last name stored separately. In general, if you want to sort, search, calculate, or report based on an item of information, you should put that item in its own field. Think about the questions you might want the database to answer. For instance, how many sales of your featured product did you close last month? Where do your best customers live? Who is the supplier for your best-selling product? Anticipating these questions helps you zero in on additional items to record. After gathering this information, you are ready for the next step.

TOP OF PAGE

Dividing the information into tables

To divide the information into tables, choose the major entities, or subjects. For example, after finding and organizing information for a product sales database, the preliminary list might look like this:

The major entities shown here are the products, the suppliers, the customers, and the orders. Therefore, it makes sense to start out with these four tables: one for facts about products, one for facts about suppliers, one for facts about customers, and one for facts about orders. Although this doesnt complete the list, it is a good starting point. You can continue to refine this list until you have a design that works well. When you first review the preliminary list of items, you might be tempted to place them all in a single table, instead of the four shown in the preceding illustration. You will learn here why that is a bad idea. Consider for a moment, the table shown here:

In this case, each row contains information about both the product and its supplier. Because you can have many products from the same supplier, the supplier name and address information has to be repeated many times. This wastes disk space. Recording the supplier information only once in a separate Suppliers table, and then linking that table to the Products table, is a much better solution. A second problem with this design comes about when you need to modify information about the supplier. For example, suppose you need to change a supplier's address. Because it appears in many places, you might accidentally change the address in one place but forget to change it in the others. Recording the suppliers address in only one place solves the problem. When you design your database, always try to record each fact just once. If you find yourself repeating the same information in more than one place, such as the address for a particular supplier, place that information in a separate table. Finally, suppose there is only one product supplied by Coho Winery, and you want to delete the product, but retain the supplier name and address information. How would you delete the product record without also losing the supplier information? You can't. Because each record contains facts about a product, as well as facts about a supplier, you cannot delete one without deleting the other. To keep these facts separate, you must split the one table into two: one table for product information, and another table for supplier information. Deleting a product record should delete only the facts about the product, not the facts about the supplier. Once you have chosen the subject that is represented by a table, columns in that table should store facts only about the subject. For instance, the product table should store facts only about products. Because the supplier address is a fact about the supplier, and not a fact about the product, it belongs in the supplier table.

TOP OF PAGE

Turning information items into columns

To determine the columns in a table, decide what information you need to track about the subject recorded in the table. For example, for the Customers table, Name, Address, City-State-Zip, Send e-mail, Salutation and E-mail address comprise a good starting list of columns. Each record in the table contains the same set of columns, so you can store Name, Address, City-State-Zip, Send e-mail, Salutation and E-mail address information for each record. For example, the address column contains customers addresses. Each record contains data about one customer, and the address field contains the address for that customer. Once you have determined the initial set of columns for each table, you can further refine the columns. For example, it makes sense to store the customer name as two separate columns: first name and last name, so that you can sort, search, and index on just those columns. Similarly, the address actually consists of five separate components, address, city, state, postal code, and country/region, and it also makes sense to store them in separate columns. If you want to perform a search, filter or sort operation by state, for example, you need the state information stored in a separate column. You should also consider whether the database will hold information that is of domestic origin only, or international, as well. For instance, if you plan to store international addresses, it is better to have a Region column instead of State, because such a column can accommodate both domestic states and the regions of other countries/regions. Similarly, Postal Code makes more sense than Zip Code if you are going to store international addresses. The following list shows a few tips for determining your columns.

Dont include calculated data In most cases, you should not store the result of calculations in tables. Instead, you can have Access perform the calculations when you want to see the result. For example, suppose there is a Products On Order report that displays the subtotal of units on order for each category of product in the database. However, there is no Units On Order subtotal column in any table. Instead, the Products table includes a Units On Order column that stores the units on order for each product. Using that data, Access calculates the subtotal each time you print the report. The subtotal itself should not be stored in a table.

Store information in its smallest logical parts You may be tempted to have a single field for full names, or for product names along with product descriptions. If you combine more than one kind of information in a field, it is difficult to retrieve individual facts later. Try to break down information into logical parts; for example, create separate fields for first and last name, or for product name, category, and description.

Once you have refined the data columns in each table, you are ready to choose each table's primary key.

TOP OF PAGE

Specifying primary keys

Each table should include a column or set of columns that uniquely identifies each row stored in the table. This is often a unique identification number, such as an employee ID number or a serial number. In database terminology, this information is called the primary key of the table. Access uses primary key fields to quickly associate data from multiple tables and bring the data together for you. If you already have a unique identifier for a table, such as a product number that uniquely identifies each product in your catalog, you can use that identifier as the tables primary key but only if the values in this column will always be different for each record. You cannot have duplicate values in a primary key. For example, dont use peoples names as a primary key, because names are not unique. You could easily have two people with the same name in the same table. A primary key must always have a value. If a column's value can become unassigned or unknown (a missing value) at some point, it can't be used as a component in a primary key. You should always choose a primary key whose value will not change. In a database that uses more than one table, a tables primary key can be used as a reference in other tables. If the primary key changes, the change must also be applied everywhere the key is referenced. Using a primary key that will not change reduces the chance that the primary key might become out of sync with other tables that reference it. Often, an arbitrary unique number is used as the primary key. For example, you might assign each order a unique order number. The order number's only purpose is to identify an order. Once assigned, it never changes. If you dont have in mind a column or set of columns that might make a good primary key, consider using a column that has the AutoNumber data type. When you use the AutoNumber data type, Access automatically assigns a value for you. Such an identifier is factless; it contains no factual information describing the row that it represents. Factless identifiers are ideal for use as a primary key because they do not change. A primary key that contains facts about a row a telephone number or a customer name, for example is more likely to change, because the factual information itself might change.

A column set to the AutoNumber data type often makes a good primary key. No two product IDs are the same.

In some cases, you may want to use two or more fields that, together, provide the primary key of a table. For example, an Order Details table that stores line items for orders would use two columns in its primary key: Order ID and Product ID. When a primary key employs more than one column, it is also called a composite key. For the product sales database, you can create an AutoNumber column for each of the tables to serve as primary key: ProductID for the Products table, OrderID for the Orders table, CustomerID for the Customers table, and SupplierID for the Suppliers table.

TOP OF PAGE

Creating the table relationships

Now that you have divided your information into tables, you need a way to bring the information together again in meaningful ways. For example, the following form includes information from several tables.

Information in this form comes from the Customers table... ...the Employees table... ...the Orders table... ...the Products table... ...and the Order Details table.

Access is a relational database management system. In a relational database, you divide your information into separate, subject-based tables. You then use table relationships to bring the information together as needed.

TOP OF PAGE

Creating a one-to-many relationship

Consider this example: the Suppliers and Products tables in the product orders database. A supplier can supply any number of products. It follows that for any supplier represented in the Suppliers table, there can be many products represented in the Products table. The relationship between the Suppliers table and the Products table is, therefore, a one-to-many relationship.

To represent a one-to-many relationship in your database design, take the primary key on the "one" side of the relationship and add it as an additional column or columns to the table on the "many" side of the relationship. In this case, for example, you add the Supplier ID column from the Suppliers table to the Products table. Access can then use the supplier ID number in the Products table to locate the correct supplier for each product. The Supplier ID column in the Products table is called a foreign key. A foreign key is another tables primary key. The Supplier ID column in the Products table is a foreign key because it is also the primary key in the Suppliers table.

You provide the basis for joining related tables by establishing pairings of primary keys and foreign keys. If you are not sure which tables should share a common column, identifying a one-to-many relationship ensures that the two tables involved will, indeed, require a shared column.

TOP OF PAGE

Creating a many-to-many relationship

Consider the relationship between the Products table and Orders table. A single order can include more than one product. On the other hand, a single product can appear on many orders. Therefore, for each record in the Orders table, there can be many records in the Products table. And for each record in the Products table, there can be many records in the Orders table. This type of relationship is called a many-to-many relationship because for any product, there can be many orders; and for any order, there can be many products. Note that to detect many-to-many relationships between your tables, it is important that you consider both sides of the relationship. The subjects of the two tables orders and products have a many-to-many relationship. This presents a problem. To understand the problem, imagine what would happen if you tried to create the relationship between the two tables by adding the Product ID field to the Orders table. To have more than one product per order, you need more than one record in the Orders table per order. You would be repeating order information for each row that relates to a single order resulting in an inefficient design that could lead to inaccurate data. You run into the same problem if you put the Order ID field in the Products table you would have more than one record in the Products table for each product. How do you solve this problem? The answer is to create a third table, often called a junction table, that breaks down the many-to-many relationship into two one-to-many relationships. You insert the primary key from each of the two tables into the third table. As a result, the third table records each occurrence or instance of the relationship.

Each record in the Order Details table represents one line item on an order. The Order Details tables primary key consists of two fields the foreign keys from the Orders and the Products tables. Using the Order ID field alone doesnt work as the primary key for this table, because one order can have many line items. The Order ID is repeated for each line item on an order, so the field doesnt contain unique values. Using the Product ID field alone doesnt work either, because one product can appear on many different orders. But together, the two fields always produce a unique value for each record. In the product sales database, the Orders table and the Products table are not related to each other directly. Instead, they are related indirectly through the Order Details table. The many-to-many relationship between orders and products is represented in the database by using two one-to-many relationships:

The Orders table and Order Details table have a one-to-many relationship. Each order can have more than one line item, but each line item is connected to only one order. The Products table and Order Details table have a one-to-many relationship. Each product can have many line items associated with it, but each line item refers to only one product.

From the Order Details table, you can determine all of the products on a particular order. You can also determine all of the orders for a particular product. After incorporating the Order Details table, the list of tables and fields might look something like this:

TOP OF PAGE

Creating a one-to-one relationship

Another type of relationship is the one-to-one relationship. For instance, suppose you need to record some special supplementary product information that you will need rarely or that only applies to a few products. Because you don't need the information often, and because storing the information in the Products table would result in empty space for every product to which it doesnt apply, you place it in a separate table. Like the Products table, you use the ProductID as the primary key. The relationship between this supplemental table and the Product table is a one-to-one relationship. For each record in the Product table, there exists a single matching record in the supplemental table. When you do identify such a relationship, both tables must share a common field. When you detect the need for a one-to-one relationship in your database, consider whether you can put the information from the two tables together in one table. If you dont want to do that for some reason, perhaps because it would result in a lot of empty space, the following list shows how you would represent the relationship in your design:

If the two tables have the same subject, you can probably set up the relationship by using the same primary key in both tables. If the two tables have different subjects with different primary keys, choose one of the tables (either one) and insert its primary key in the other table as a foreign key. Determining the relationships between tables helps you ensure that you have the right tables and columns. When a one-to-one or one-tomany relationship exists, the tables involved need to share a common column or columns. When a many-to-many relationship exists, a third table is needed to represent the relationship.

TOP OF PAGE

Refining the design

Once you have the tables, fields, and relationships you need, you should create and populate your tables with sample data and try working with the information: creating queries, adding new records, and so on. Doing this helps highlight potential problems for example, you might need to add a column that you forgot to insert during your design phase, or you may have a table that you should split into two tables to remove duplication. See if you can use the database to get the answers you want. Create rough drafts of your forms and reports and see if they show the data you expect. Look for unnecessary duplication of data and, when you find any, alter your design to eliminate it. As you try out your initial database, you will probably discover room for improvement. Here are a few things to check for:

Did you forget any columns? If so, does the information belong in the existing tables? If it is information about something else, you may need to create another table. Create a column for every information item you need to track. If the information cant be calculated from other columns, it is likely that you will need a new column for it. Are any columns unnecessary because they can be calculated from existing fields? If an information item can be calculated from other existing columns a discounted price calculated from the retail price, for example it is usually better to do just that, and avoid creating new column. Are you repeatedly entering duplicate information in one of your tables? If so, you probably need to divide the table into two tables that have a one-to-many relationship. Do you have tables with many fields, a limited number of records, and many empty fields in individual records? If so, think about redesigning the table so it has fewer fields and more records. Has each information item been broken into its smallest useful parts? If you need to report, sort, search, or calculate on an item of information, put that item in its own column. Does each column contain a fact about the table's subject? If a column does not contain information about the table's subject, it belongs in a different table. Are all relationships between tables represented, either by common fields or by a third table? One-to-one and one-to- many relationships require common columns. Many-to-many relationships require a third table.

Refining the Products table

Suppose that each product in the product sales database falls under a general category, such as beverages, condiments, or seafood. The Products table could include a field that shows the category of each product. Suppose that after examining and refining the design of the database, you decide to store a description of the category along with its name. If you add a Category Description field to the Products table, you have to repeat each category description for each product that falls under the category this is not a good solution. A better solution is to make Categories a new subject for the database to track, with its own table and its own primary key. You can then add the primary key from the Categories table to the Products table as a foreign key. The Categories and Products tables have a one-to-many relationship: a category can include more than one product, but a product can belong to only one category. When you review your table structures, be on the lookout for repeating groups. For example, consider a table containing the following columns:

Product ID Name Product ID1 Name1 Product ID2 Name2 Product ID3 Name3

Here, each product is a repeating group of columns that differs from the others only by adding a number to the end of the column name. When you see columns numbered this way, you should revisit your design. Such a design has several flaws. For starters, it forces you to place an upper limit on the number of products. As soon as you exceed that limit, you must add a new group of columns to the table structure, which is a major administrative task. Another problem is that those suppliers that have fewer than the maximum number of products will waste some space, since the additional columns will be blank. The most serious flaw with such a design is that it makes many tasks difficult to perform, such as sorting or indexing the table by product ID or name. Whenever you see repeating groups review the design closely with an eye on splitting the table in two. In the above example it is better to use two tables, one for suppliers and one for products, linked by supplier ID.

TOP OF PAGE

Applying the normalization rules

You can apply the data normalization rules (sometimes just called normalization rules) as the next step in your design. You use these rules to see if your tables are structured correctly. The process of applying the rules to your database design is called normalizing the database, or just normalization. Normalization is most useful after you have represented all of the information items and have arrived at a preliminary design. The idea is to help you ensure that you have divided your information items into the appropriate tables. What normalization cannot do is ensure that you have all the correct data items to begin with. You apply the rules in succession, at each step ensuring that your design arrives at one of what is known as the "normal forms." Five normal forms are widely accepted the first normal form through the fifth normal form. This article expands on the first three, because they are all that is required for the majority of database designs.

First normal form

First normal form states that at every row and column intersection in the table there, exists a single value, and never a list of values. For example, you cannot have a field named Price in which you place more than one Price. If you think of each intersection of rows and columns as a cell, each cell can hold only one value.

Second normal form

Second normal form requires that each non-key column be fully dependent on the entire primary key, not on just part of the key. This rule applies when you have a primary key that consists of more than one column. For example, suppose you have a table containing the following columns, where Order ID and Product ID form the primary key:

Order ID (primary key) Product ID (primary key) Product Name This design violates second normal form, because Product Name is dependent on Product ID, but not on Order ID, so it is not dependent on the entire primary key. You must remove Product Name from the table. It belongs in a different table (Products).

Third normal form

Third normal form requires that not only every non-key column be dependent on the entire primary key, but that non-key columns be independent of each other.

Another way of saying this is that each non-key column must be dependent on the primary key and nothing but the primary key. For example, suppose you have a table containing the following columns:

ProductID (primary key) Name SRP Discount Assume that Discount depends on the suggested retail price (SRP). This table violates third normal form because a non-key column, Discount, depends on another non-key column, SRP. Column independence means that you should be able to change any non-key column without affecting any other column. If you change a value in the SRP field, the Discount would change accordingly, thus violating that rule. In this case Discount should be moved to another table that is keyed on SRP.

CREATE A DATABASE:

When you create a database, you store your data in tablessubject-based lists that contain rows and columns. For instance, you can create a Contacts table to store a list of names, addresses, and telephone numbers, or a Products table to store information about products. This article explains how to create a table, how to add fields to a table, and how to set a table's primary key (primary key: One or more fields (columns) whose values uniquely identify each record in a table. A primary key cannot allow Null values and must always have a unique index. A primary key is used to relate a table to foreign keys in other tables.). It also explains how to set field and table properties. Because other database objects (database objects: An Access database contains objects such as tables, queries, forms, reports, pages, macros, and modules. An Access project contains objects such as forms, reports, pages, macros, and modules.) depend so heavily on tables, you should always start your design of a database by creating all of its tables and then creating any other objects. Before you create tables, carefully consider your requirements and determine all the tables that you need. For an introduction to planning and designing a database, see the article Database design basics. Note This article does not explain how to create a table by using a data-definition query (datadefinition query: An SQL-specific query that contains data definition language (DDL) statements. These statements allow you to create or alter objects in the database.). Find links to more information about data-definition queries in the See Also section. In this article

Overview Before you begin

Create a new table Add a field to a table Save a table

Overview A table is a database object that you use to store data about a particular subject, such as employees or products. A table consists of records and fields. Each record contains data about one instance of the table subject, such as a particular employee. A record is also commonly called a row or an instance. Each field contains data about one aspect of the table subject, such as first name or e-mail address. A field is also commonly called a column or an attribute. A record consists of field values, such as Contoso, Ltd. or someone@example.com. A field value is also commonly called a fact.

A record A field A field value

A database can contain many tables, each storing information about a different subject. Each table can contain many fields of different types of data, such as text, numbers, dates, and hyperlinks. Table and field properties Tables and fields also have properties that you can set to control their characteristics or behavior.

A table open in Design view. Table properties Field properties

In an Access database, table properties are attributes of a table that affect the appearance or behavior of the table as a whole. Table properties are set in the table's property sheet, in Design view. For example, you can set a table's Default View property to specify how the table is displayed by default. A field property applies to a particular field in a table and defines one of the field's characteristics or an aspect of the field's behavior. You can set some field properties in Datasheet view (Datasheet view: A view that displays data from a table, form, query, view, or stored procedure in a row-and-column format. In Datasheet view, you can edit fields, add and delete data, and search for data.). You can also set any field property in Design view by using the Field Properties pane. Data types Every field has a data type. A field's data type indicates the kind of data that the field stores, such as large amounts of text or attached files.

A data type is a field property, but it differs from other field properties as follows: You set a field's data type in the table design grid, not in the Field Properties pane. A field's data type determines what other properties the field has. You must set a field's data type when you create the field.

Note You can create a new field in Access by entering data in a new column in Datasheet view. When you create a field by entering data in Datasheet view, Access automatically assigns a data type for the field, based on the value that you enter. If no other data type is implied by your input, Access sets the data type to Text. If needed, you can change the data type by using the Ribbon, part of the new Microsoft Office Fluent user interface. Examples of automatic data type detection The following table shows how automatic data type detection works in Datasheet view. If you enter: Office Access 2007 creates a field with a data type of: Text Hyperlink

John http://www.contoso.com You can use any valid Internet protocol prefix. For example, http://, https://, and mailto: are valid prefixes. 1 50,000 50,000.99 50000.389 12/67 The date and time formats recognized are those of your user locale. December 31, 2006 10:50:23 10:50 am 17:50 $12.50 The currency symbol recognized is that of your user locale. 21.75

Number, Long Integer Number, Long Integer Number, Double Number, Double Date/Time

Date/Time Date/Time Date/Time Date/Time Currency

Number, Double

123.00% 3.46E+03

Number, Double Number, Double

Table relationships Although each table stores data about a different subject, tables in a database usually store data about subjects that are related to each other. For example, a database might contain: A customers table that lists your companys customers and their addresses. A products table that lists the products that you sell, including prices and pictures for each item. An orders table that tracks customer orders. Because you store data about different subjects in separate tables, you need some way to tie the data together so that you can easily combine related data from those separate tables. To connect the data stored in different tables, you create relationships. A relationship is a logical connection between two tables that specifies fields that the tables have in common. Keys Fields that are part of a table relationship are called keys. A key usually consists of one field, but may consist of more than one field. There are two kinds of keys: Primary key A table can have only one primary key. A primary key consists of one or more fields that uniquely identify each record that you store in the table. Often, there is a unique identification number, such as an ID number, a serial number, or a code, that serves as a primary key. For example, you might have a Customers table where each customer has a unique customer ID number. The customer ID field is the primary key of the Customers table. When a primary key contains more than one field, it is usually composed of pre-existing fields that, taken together, provide unique values. For example, you might use a combination of last name, first name, and birth date as the primary key for a table about people. Foreign key A table can also have one or more foreign keys. A foreign key contains values that correspond to values in the primary key of another table. For example, you might have an Orders table in which each order has a customer ID number that corresponds to a record in a Customers table. The customer ID field is a foreign key of the Orders table. The correspondence of values between key fields forms the basis of a table relationship. You use a table relationship to combine data from related tables. For example, suppose that you have a Customers table and an Orders table. In your Customers table, each record is identified by the primary key field, ID. To associate each order with a customer, you add a foreign key field to the Orders table that corresponds to the ID field of the Customers table, and then create a relationship between the two keys.

When you add a record to the Orders table, you use a value for customer ID that comes from the Customers table. Whenever you want to view any information about an order's customer, you use the relationship to identify which data from the Customers table corresponds to which records in the Orders table.

A table relationship, shown in the Relationships window. A primary key, identified by the key icon next to the field name. A foreign key note the absence of the key icon.

Benefits of using relationships Keeping data separated in related tables produces the following benefits: Consistency Because each item of data is recorded only once, in one table, there is less opportunity for ambiguity or inconsistency. For example, you store a customer's name only once, in a table about customers, rather than storing it repeatedly (and potentially inconsistently) in a table that contains order data. Efficiency Recording data in only one place means you use less disk space. Moreover, smaller tables tend to provide data more quickly than larger tables. Finally, if you don't use separate tables for separate subjects, you will introduce null values (the absence of data) and redundancy into your tables, both of which can waste space and impede performance.

Comprehensibility The design of a database is easier to understand if the subjects are properly separated into tables. Tip Plan your tables with relationships in mind. You can use the Lookup Wizard to create a foreign key field if the table that contains the corresponding primary key already exists. The Lookup Wizard creates the relationship for you. Top of Page Before you begin Before you start to create tables in Microsoft Office Access 2007, there are a few differences from earlier versions of Access that you should keep in mind. Table and field templates have replaced the Table Wizard In earlier versions of Access, you used the Table Wizard to create a table quickly by answering a few questions. In Office Access 2007, the Table Wizard has been replaced by table and field templates. Datasheet creation In Office Access 2007, you can create and modify tables and fields while working in Datasheet view. More information about these features is presented in the following section. Top of Page Create a new table A simple database, such as a contact list, might use only a single table. Many databases, however, use several tables. When you create a new database, you create a new file on your computer that acts as a container for all of the objects in your database, including your tables. Tip In Access 2010, you can use Application Parts to quickly add commonly used tables, forms, and reports to your database. Read an article or try Office 2010! You can create a table by creating a new database, by inserting a table into an existing database, or by importing or linking to a table from another data source such as a Microsoft Office Excel workbook, a Microsoft Office Word document, a text file, or another database. When you create a new, blank database, a new, empty table is automatically inserted for you. You can then enter data in the table to start defining your fields. What do you want to do?

Create a new table in a new database Create a new table in an existing database

Use a table template to create a table Import or link to create a table Use a SharePoint site to create a table Set a table's primary key Set a table's properties

Create a new table in a new database Click the Microsoft Office Button , and then click New.

In the File Name box, type a file name for the new database. To browse to a different location to save the database, click the folder icon. Click Create. The new database opens, and a new table named Table1 is created and opens in Datasheet view. Create a new table in an existing database Click the Microsoft Office Button , and then click Open.

In the Open dialog box, select the database that you want to open, and then click Open. On the Create tab, in the Tables group, click Table.

A new table is inserted in the database and the table opens in Datasheet view. Top of Section

Top of Page Use a table template to create a table

In earlier versions of Access, you used the Table Wizard to quickly create a table from sample tables and fields. In Office Access 2007, you use table templates and field templates instead. A table template is an empty table that you can start using as-is, or modify to suit your needs. Office Access 2007 comes with the following table templates, designed to be compatible with the Windows SharePoint Services 3.0 lists of the same name: Contacts A table for managing business contact information, which includes e-mail addresses, Web page URLs, and attachments, such as a service contract and a photo. Tasks A table for tracking tasks, which includes a field for attachments. Issues A table for tracking issues, which includes a field for attachments and an append-only Memo field that keeps a history of old field values. Events A table for managing events, which includes a rich text Memo field and a field for attachments. Assets A table for managing business assets, which includes two currency fields so that you can track asset depreciation. After you create a table by using a table template, you may want to add fields by using field templates. A field template is a predefined field that you can add to any table in Datasheet view. For more information about using a field template, see the section Add a field by using a field template, later in this article. Create a new table by using a table template Click the Microsoft Office Button , and then click Open.

In the Open dialog box, select and open the database in which you wish to create a table. On the Create tab, in the Tables group, click Table Templates and then select one of the available templates from the list.

A new table is inserted, based on the table template that you chose. Top of Section

Top of Page

Import or link to create a table You can create a table by importing or linking to data that is stored elsewhere. You can import or link to data in an Excel worksheet, a Windows SharePoint Services list, an XML file, another Access database, a Microsoft Office Outlook folder, and more. When you import data, you create a copy of the data in a new table in the current database. Subsequent changes to the source data will have no effect on the imported data, and changes to the imported data do not affect the source data. After you connect to a data source and import its data, you can then use the imported data without connecting to the source. You can change the design of an imported table. When you link to data, you create a linked table in the current database that represents a live link to the existing information that is stored elsewhere. When you change data in a linked table, you are changing it in the source. Whenever data changes in the source, that change is shown in the linked table. You must be able to connect to the data source whenever you use a linked table. You cannot change the design of a linked table. Note You cannot edit data in an Excel worksheet by using a linked table. As a workaround, import the source data into an Access database, and then link to the database from Excel. For more information about linking to Access from Excel, search Excel Help, or see the links in the See Also section. Create a new table by importing or linking to external data Click the Microsoft Office Button , and then click Open.

In the Open dialog box, select and open the database in which you wish to create a new table. On the External Data tab, in the Import group, click one of the available data sources.

Follow the instructions in the dialog boxes that appear at each step. Access creates the new table and displays it in the Navigation Pane. Tip You can also import or link to a SharePoint list by using a command on the Create tab. Top of Section

Top of Page

Use a SharePoint site to create a table You can create a table in your database that imports from or links to a SharePoint list. You can also create a new SharePoint list by using a predefined template. The predefined templates in Office Access 2007 include Contacts, Tasks, Issues, and Events. Click the Microsoft Office Button , and then click Open.

In the Open dialog box, select the database in which you want to create the new table, and then click Open. On the Create tab, in the Tables group, click SharePoint Lists.

Do one of the following: Create a SharePoint list that is based on a template Click either Contacts, Tasks, Issues, or Events. In the Create New List dialog box, type the URL for the SharePoint site where you want to create the list. Enter a name for the new list and its description in the Specify a name for the new list and Description boxes. To open the linked table after it is created, select the Open the list when finished check box (selected by default).

Create a new custom list Click Custom. In the Create New List dialog box, type the URL for the SharePoint site where you want to create the list. Enter a name for the new list and its description in the Specify a name for the new list and Description boxes. To open the linked table after it is created, select the Open the list when finished check box (selected by default).

Import the data from an existing list Click Existing SharePoint List. In the Get External Data dialog box, type the URL for the SharePoint site that contains the data that you want to import. Click Import the source data into a new table in the current database, and then click Next. Select the check box next to each SharePoint list that you want to import.

Link to an existing list Click Existing SharePoint List. In the Get External Data - SharePoint Site dialog box, type the URL for the SharePoint site that contains the list to which you want to link. Click Link to the data source by creating a linked table, and then click Next. Select the check box next to each SharePoint list to which you want to link. Top of Section

Top of Page Set a table's primary key Unless you have a specific reason not to, you should specify a primary key for a table. Access automatically creates an index for the primary key, which can help improve database performance. Access also makes sure that every record has a value in the primary key field, and that the value is always unique. Unique values are crucial, because otherwise there is no way to reliably distinguish a particular row from other rows. When you create a new table in Datasheet view, Access automatically creates a primary key for you and assigns it a field name of ID and the AutoNumber data type. In Design view, you can change or remove the primary key, or set the primary key for a table that doesn't already have one. Determine which fields to use as a primary key Sometimes, you might already have data that you want to use as a primary key. For example, you may have existing ID numbers for your employees. If you create a table to track employee information, you

might decide to use the existing employee ID as the primary key for the table. Or, perhaps employee ID is only unique in combination with department ID, requiring that you use both fields together as the primary key. A good candidate for the primary key has the following characteristics: Each record has a unique value for the field or combination of fields. The field or combination of fields is never empty or null there is always a value. The values do not change. If no suitable data exists to use as a primary key, you can create a new field to use as a primary key. When you create a new field to use as a primary key, set the field's data type to AutoNumber to help make sure that it meets the three characteristics in the preceding list. Set or change the primary key Select the table whose primary key you want to set or change. On the Home tab, in the Views group, click View, and then click Design View. In the table design grid, select the field or fields that you want to use as the primary key. To select one field, click the row selector (row selector: A small box or bar that, when clicked, selects an entire row in table or macro Design view, or when you sort and group records in report Design view.) for the field that you want. To select more than one field, hold down CTRL, and then click the row selector for each field. On the Design tab, in the Tools group, click Primary Key.

A key indicator appears to the left of the field or fields that you specify as the primary key. Remove the primary key Select the table whose primary key you want to remove. On the Home tab, in the Views group, click View, and then click Design View. Click the row selector (row selector: A small box or bar that, when clicked, selects an entire row in table or macro Design view, or when you sort and group records in report Design view.) for the current primary key. If the primary key consists of multiple fields, hold down CTRL, and then click the row selector for each field.

On the Design tab, in the Tools group, click Primary Key.

The key indicator is removed from the field or fields that you previously specified as the primary key. Note When you save a new table without setting a primary key, Access prompts you to create a new field for the primary key. If you click Yes, Access creates an ID field that uses the AutoNumber data type to provide a unique value for each record. If your table already includes an AutoNumber field, Access uses it as the primary key. If you click No, Access does not add a field, and no primary key is set. Top of Section

Top of Page Set a table's properties In addition to setting properties fields, you can also set properties that apply to an entire table or to entire records. Select the table whose properties you want to set. On the Home tab, in the Views group, click View, and then click Design View. On the Design tab, in the Show/Hide group, click Property Sheet.

The table property sheet is shown. On the property sheet, click the General tab. Click the box to the left of the property that you want to set, and then enter a setting for the property. Available table properties Use this table property To

Display Views On SharePoint Site

Specify whether views that are based on the table can be displayed on a SharePoint site. Note The effects of this setting depend on the setting of the Display All Views On SharePoint Site database property. For more information, see the See Also section.

Subdatasheet Expanded Subdatasheet Height

Expand all subdatasheets when you open the table.

Do one of the following: If you want the subdatasheet window to expand to display all rows, leave this property set at 0". If you want to control the height of the subdatasheet, enter the desired height in inches.

Orientation

Set the view orientation, according to whether your language is read left-to-right, or right-to-left. Provide a description of the table. This description will appear in tooltips for the table. Set Datasheet, PivotTable, or PivotChart as the default view when you open the table. Enter an expression that must be true whenever you add or change a record. Enter a message that is displayed when a record violates the expression in the Validation Rule property. Define criteria to display only matching rows in Datasheet view. Select one or more fields to specify the default sort order of rows in Datasheet view. Specify whether a subdatasheet should appear in Datasheet view, and if so, which table or query should supply the rows in the subdatasheet. List the fields in the table or query that are used for the subdatasheet that match the Link Master Fields property that is specified for the table. List the fields in the table that match the Link Child Fields property that is specified for the table.

Description

Default View

Validation Rule Validation Text

Filter Order By

Subdatasheet Name

Link Child Fields

Link Master Fields

Filter On Load

Automatically apply the filter criteria in the Filter property (by setting to Yes) when the table is opened in Datasheet view. Automatically apply the sort criteria in the Order By property (by setting to Yes) when the table is opened in Datasheet view.

Order By On Load

Tip To provide more space to enter or edit a setting in the property box, press SHIFT+F2 to display the Zoom box. If you are setting the Validation Rule property to an expression and would like help in building it, click next to the ValidationRule property box to display the Expression Builder.

To save your changes, press CTRL+S. Top of Section

Top of Page Add a field to a table You store each piece of data that you want to track in a field. For example, in a contacts table you create fields for Last Name, First Name, Telephone Number, and Address. In a products table you create fields for Product Name, Product ID, and Price. Before you create fields, try to separate data into its smallest useful parts. It is much easier to combine data later than it is to pull it apart. For example, instead of a Full Name field, consider creating separate fields for Last Name and First Name. Then, you can easily search or sort by First Name, Last Name, or both. If you plan to report, sort, search, or calculate on an item of data, put that item in a field by itself. For more information about designing a database and creating fields, see the links in the See Also section. After you create a field, you can also set field properties to control its appearance and behavior. What do you want to do?

Add a field by entering data Add a field from an existing table Set field properties

Add a field by entering data

When you create a new table or open an existing table in Datasheet view, you can add a field to the table by entering data in the Add New Field column of the datasheet.

Enter data in the Add New Field column. Create or open a table in Datasheet view. Note For more information about creating a table, see the section, Create a new table. In the Add New Field column, enter the name of the field that you want to create. Use a descriptive name so that the field will be easier to identify. Enter data in the new field. Top of Section

Top of Page Add a field by using a field template Sometimes it is easier to choose from a predefined list of fields that fit your needs than to manually create a field. You can use the Field Templates task pane to choose from a list of field templates. A field template is a predefined set of characteristics and properties that describes a field. The field template definition includes a field name, a data type, a setting for the field's Format property, and other field properties. On the Home tab, in the Views group, click View, and then click Datasheet View. On the Datasheet tab, in the Fields & Columns group, click New Field.

Select one or more fields in the Field Templates pane, and then drag them to the table where you want to insert the new column.

Top of Section

Top of Page Add a field from an existing table If your database already contains tables, you can add a field from one of those tables to your new table by using the Field List pane. The Field List pane lists all the other tables in your database, grouped into two categories: Fields available in related tables and Fields available in other tables. If the table you are adding a field to is in relationships (relationship: An association that is established between common fields (columns) in two tables. A relationship can be one-to-one, one-to-many, or many-to-many.) with other tables, the related tables' fields are listed first in the Field List pane.

Click the Microsoft Office Button

, and then click Open.

In the Open dialog box, select and open the database that you want to work with. In the Navigation Pane, double-click the table to which you want to add an existing field. The table opens in Datasheet view. On the Datasheet tab, in the Fields & Columns group, click Add Existing Fields.

Click the plus sign (+) next to a table in the Field List pane to display the list of fields in that table. Select the field that you want, and drag it to the table where you want to insert the new column. Follow the instructions in the Lookup Wizard. After you have completed the wizard, the field appears in the table in Datasheet view. Note When you add a field from an unrelated table and then complete the Lookup Wizard, a new oneto-many relationship is automatically created between the table in the Field List pane and the table that you have open. Find links to more information about the Lookup Wizard in the See Also section. Top of Section

Top of Page Set field properties After you create a field, you can set field properties to control its appearance and behavior. For example, by setting field properties, you can: Control the appearance of data in a field Help prevent incorrect data entry in a field Specify default values for a field Help speed up searching and sorting on a field You can set some of the available field properties while you work in Datasheet view. To have access to and set the complete list of field properties; however, you must use Design view.

Set field properties in Datasheet view You can rename a field, change its data type, change its Format property, and change some of a field's other properties while you work in Datasheet view. Open a table in Datasheet view In the Navigation Pane, right-click the table that you want to open. On the shortcut menu, click Datasheet view. Rename a field When you add a field by entering data in Datasheet view, Access automatically assigns a generic name to the field. Access assigns the name Field1 to the first new field, Field2 to the second new field, and so on. By default, a field's name is used as its label wherever the field is displayed, such as a column heading on a datasheet. Renaming fields so that they have more descriptive names helps make them easier to use when you view or edit records. Right-click the heading of the field that you want to rename (for example, Field1). On the shortcut menu, click Rename Column. Enter the new name in the field heading. Field names can consist of up to 64 characters (letters or numbers), including spaces. Change a field's data type When you create a field by entering data in Datasheet view, Access examines that data to determine the appropriate data type for the field. For example, if you enter 1/1/2006, Access recognizes that data as a date and sets the data type for the field to Date/Time. If Access can't definitively determine the data type, the data type is set to Text by default. The data type of the field determines which other field properties you can set. For example, you can set only the Append Only property for a field that has the Hyperlink data type or the Memo data type. There may be cases where you want to manually change a field's data type. For example, suppose you have room numbers that resemble dates, such as 10/2001. If you enter 10/2001 into a new field in Datasheet view, the automatic data type detection feature selects the Date/Time data type for the field. Because room numbers are labels, and not dates, they should use the Text data type. Use the following procedure to change a field's data type. On the Ribbon, click the Datasheet tab . In the Data Type list, in the Data Type & Formatting group, select the data type that you want.

Available data types Data type Text Use to store Alphanumeric characters Use for text, or for numbers that are not used in calculations (for example, a product ID). A numeric value that is stored as text can be sorted and filtered more logically, but cannot be easily used in calculations. Memo Alphanumeric characters (longer than 255 characters in length) or text that uses rich text formatting. Use for text that is more than 255 characters in length, or for text that uses rich text formatting. Notes, lengthy descriptions, and paragraphs that use text formatting, such as bold or italics, are good examples of where to use a Memo field. Number Numeric values (integers or fractional values). Use for storing numbers that are used in calculations, except for monetary values (use the Currency data type for monetary values). Date/Time Dates and times. Use for storing date/time values. Note that each value stored includes both a date component and a time component. Currency Monetary values. Use for storing monetary values (currency). AutoNumber A unique numeric value that Access automatically inserts when a record is added. 4 bytes or 16 bytes when used for replication ID. 8 bytes. Up to 1 gigabyte of characters, or 2 gigabytes of storage (2 bytes per character), of which you can display 65,535 characters in a control. Size Up to 255 characters.

1, 2, 4, or 8 bytes, or 16 bytes when used for a replication ID.

8 bytes.

Use for generating unique values that can be used as a primary key. Note that values for AutoNumber fields can be incremented sequentially or by a specified value, or assigned randomly. Yes/No Boolean values (yes/no). You can use one of three formats: Yes/No, True/False, or On/Off. OLE Object OLE objects or other binary data. Use for storing OLE objects from other Microsoft Windows programs. Attachment Pictures, Images, Binary files, Office files. This is the preferred data type for storing digital images and any type of binary file. For compressed attachments, 2 gigabytes. For uncompressed attachments, approximately 700kb, depending on the degree to which the attachment can be compressed. Up to 1 gigabyte of characters, or 2 gigabytes of storage (2 bytes per character), of which you can display 65,535 characters in a control. Up to 1 gigabyte. 1 bit (8 bits = 1 byte).

Hyperlink

Hyperlinks. Use for storing hyperlinks to provide single-click access to Web pages through a URL (Uniform Resource Locator) or files through a name in UNC (universal naming convention) format. You can also link to Access objects stored in a database.

Lookup Wizard

Not actually a data type; instead, this starts the Lookup Wizard. Use to start the Lookup Wizard so that you can create a field that uses a combo box to look up a value in another table, query, or list of values.

Table or query based: The size of the bound column. Value based: The size of the Text field used to store the value.

Note The maximum size of an Access database file is 2 gigabytes. Tips on data types To optimize performance, you should use the most appropriate Field Size when you create a Text or Number field. For example, if you expect to store postal codes of a predictable length, specify that length as the field size. You can specify the field size by setting a value in the FieldSize property box. For more information, see the section, Set other field properties.

For phone numbers, part numbers, and other numbers that you don't intend to use for mathematical calculations, you should select the Text data type instead of the Number data type. A numeric value that is stored as text can be sorted and filtered more logically.

Change a field's format In addition to determining the data type of a new field, Access may also set the Format property for the field, depending on what you enter. For example, if you enter 10:50 a.m., Access sets the data type to Date/Time and the Format property to Medium Time. To manually change a field's Format property, do the following: On the Ribbon, click the Datasheet tab. In the Format list, in the Data Type & Formatting group, enter the format that you want. Note The Format list may be unavailable for some fields (for example, Text), depending on the data type of the field. Set other field properties In Datasheet view, click the field for which you want to set the property. On the Datasheet tab, in the Data Type & Formatting group, select the properties that you want.

Top of Section

Top of Page Set field properties in Design view You can set any field property while you work with a table in Design view. In Design view, you set a field's data type in the table design grid, and you set other properties in the Field Properties pane. Open a table in Design view In the Navigation Pane, right-click the table. On the shortcut menu, click Design view.

Change a field's data type In the table design grid, locate the field for which you want to set the data type. In the Data Type column, choose a data type from the list. Available data types Data type Text Use to store Alphanumeric characters Use for text, or for numbers that are not used in calculations (for example, a product ID). A numeric value that is stored as text can be sorted and filtered more logically, but cannot be easily used in calculations. Memo Alphanumeric characters (longer than 255 characters in length) or text that uses rich text formatting. Use for text that is more than 255 characters in length, or for text that uses rich text formatting. Notes, lengthy descriptions, and paragraphs that use text formatting, such as bold or italics, are good examples of where to use a Memo field. Number Numeric values (integers or fractional values). Use for storing numbers that are used in calculations, except for monetary values (use the Currency data type for monetary values). Date/Time Dates and times. Use for storing date/time values. Note that each value stored includes both a date component and a time component. Currency Monetary values. Use for storing monetary values (currency). AutoNumber A unique numeric value that Access automatically inserts when a record is added. 4 bytes or 16 bytes when used for replication ID. 8 bytes. Up to 1 gigabyte of characters, or 2 gigabytes of storage (2 bytes per character), of which you can display 65,535 characters in a control. Size Up to 255 characters.

1, 2, 4, or 8 bytes, or 16 bytes when used for a replication ID.

8 bytes.

Use for generating unique values that can be used as a primary key. Note that values for AutoNumber fields can be incremented sequentially or by a specified value, or assigned randomly. Yes/No Boolean values (yes/no). You can use one of three formats: Yes/No, True/False, or On/Off. OLE Object OLE objects or other binary data. Use for storing OLE objects from other Microsoft Windows programs. Attachment Pictures, Images, Binary files, Office files. This is the preferred data type for storing digital images and any type of binary file. For compressed attachments, 2 gigabytes. For uncompressed attachments, approximately 700kb, depending on the degree to which the attachment can be compressed. Up to 1 gigabyte of characters, or 2 gigabytes of storage (2 bytes per character), of which you can display 65,535 characters in a control. Up to 1 gigabyte. 1 bit (8 bits = 1 byte).

Hyperlink

Hyperlinks. Use for storing hyperlinks to provide single-click access to Web pages through a URL (Uniform Resource Locator) or files through a name in UNC (universal naming convention) format. You can also link to Access objects stored in a database.

Lookup Wizard

Not actually a data type; instead, this starts the Lookup Wizard. Use to start the Lookup Wizard so that you can create a field that uses a combo box to look up a value in another table, query, or list of values.

Table or query based: The size of the bound column. Value based: The size of the Text field used to store the value.

Note The maximum size of an Access database file is 2 gigabytes. Tips on data types For phone numbers, part numbers, and other numbers that you don't intend to use for mathematical calculations, you should select the Text data type instead of the Number data type. A numeric value that is stored as text can be sorted and filtered more logically, but cannot be easily used in calculations. For the Text and Number data types, you can specify the field size or data type more precisely by setting a value in the FieldSize property box.

Set other field properties In the table design grid, select the field for which you want to set properties. Access displays the properties for this field in the Field Properties pane. Note The data type of the field determines the properties that you can set. In the Field Properties pane, enter the settings that you want for each property, or press F6 and then use the arrow keys to select a property. What field properties are available? Note Not all properties are available for every field. A field's data type determines which properties it has. Field property Field Size Description

Set the maximum size for data stored as a Text, Number, or AutoNumber data type. Tip For best performance, always specify the smallest sufficient Field Size.

Format

Customize the way that the field appears by default when displayed or printed.

Decimal Places Specify the number of decimal places to use when displaying numbers. New Values Specify whether an AutoNumber field is incremented or assigned a random value when a new record is added. Display characters that help to guide data entry. For more information about creating and using an input mask, see the See Also section. Set the text displayed by default in labels for forms, reports, and queries.

Input Mask

Caption

Default Value Automatically assign a default value to a field when new records are added. Validation Rule Supply an expression that must be true whenever you add or change the value in this field. Validation Text Enter a message to display when a value violates the expression in the Validation Rule property. Required Allow Zero Length Require that data be entered in a field. Allow entry (by setting the property's value to Yes) of a zero-length string ("") in a Text or Memo field.

Indexed Unicode Compression IME Mode

Speed up access to data in this field by creating and using an index. Compress text stored in this field when a small amount of text is stored (< 4,096 characters). Control conversion of characters in an East Asian version of Windows.

IME Sentence Control conversion of sentences in an East Asian version of Windows. Mode Smart Tags Attach a smart tag (action tags: Data recognized and labeled as a particular type. For example, a person's name or the name of a recent Microsoft Outlook e-mail message recipient is a type of data that can be recognized and labeled with an action tag.) to this field. Track the history of field values (by setting the property's value to Yes). Choose the property's Rich Text value to store text as HTML and allow rich formatting. Choose the property's Plain Text value to store only unformatted text. Specify the default alignment of text within a control.

Append Only Text Format

Text Align

To provide more space for entering or editing a property setting in the property box, press SHIFT+F2 to display the Zoom box. Tip If you are entering an input mask or validation expression and would like help in building it, click next to the property box to display the appropriate builder. To save your changes, press CTRL+S. Find links to more information about data types and field properties in the See Also section. Top of Section

Top of Page Save a table After you create or modify a table, you should save its design. When you save a table for the first time, give it a name that describes the data that it contains. You can use up to 64 alphanumeric characters, including spaces. For example, you might name a table Customers, Parts Inventory, or Products. Tip You should decide on a naming convention for the objects in your database, and use it consistently. Click the Microsoft Office Button , and then click Save, or press CTRL+S .

If you are saving the table for the first time, type a name for the table, and then click OK.

QUERY

Once you get your data into your database, how do you get the data out again? A database becomes really valuable when you use the data it contains as a resource to answer questions or perform tasks. Whether it's comparing weekly sales figures, tracking packages, finding all the members of your club who live in Texas, or a multitude of other scenarios, a query can help you retrieve data and put it to good use. To learn more about this course, read the overview in the center of this page or the table of contents in the left column. Then click Next to start the first lesson.

BEFORE YOU BEGIN

You should be familiar with the basics of databases and database tables, or you should take these courses: Get to know Access and Table that data. Queries can select items from your data and make it more useful.

Queries let you pull just the data you need out of a database so you can perform tasks and get questions answered. With queries, you can retrieve, combine, reuse, and analyze your data. You can use queries to retrieve data from multiple tables, or as a source for forms and reports.

In this course, we'll stick to the basics of choosing and retrieving data with select queries, which will give you a good foundation for working with other, more complex types of queries. Click Next to continue reading this lesson on your own. Queries express the questions you want your data to answer.

When you work with queries, you need to keep in mind the questions that you want your data to answer. The better you state the question, the more precisely you can define the query. Here are some examples that will help you think of others.

A CORPORATE SALES AND PRODUCTS DATABASE

What's the company's most popular sales item in the United Kingdom? What would we gain and lose if we dropped our slowest-moving product line? What item costs the most to make?

A PERSONAL MEDIA COLLECTION DATABASE

How many of my DVDs are on loan to my friends? Which CDs contain my all-time favorite tunes?

A SPORTS LEAGUE DATABASE

Which team had the highest total score in all games last year? Who ordered team jerseys this year, and what sizes do they need? What questions do you want your It can help to put your query into sentence form before creating it in Access.

Before you start thinking about the nitty-gritty of creating a query, it's a good idea to think through the questions you want to answer, logically and in detail.

How do you want to choose your data? Do you want, for example, the 10 most of something, all items above or below a certain amount, or all employees who live in a different county from the location of your office? What database fields do you need? For example, for a list of your company's five best-selling beverages, you might want beverage names, manufacturers, and suppliers, but you probably don't need the states they're bottled in. Once the data is returned, do you want to do more with it? Do you want to multiply sales quantities times price, or view the impact on sales figures of a recent discount? It can help to put your question into full sentence form, as in this example: "I want to know the 10 best-selling products in our Midwest region. I need to know the product names, the product IDs, and the department that produces each product." Don't forget: If at first you don't succeed, if your query doesn't get just the results you need, you can tinker with the query later

Queries retrieve the latest information from your database.

Whenever you run a query, it checks for the latest data in your database. The data returned by a query is called a recordset. You can browse through the recordset, select from it, sort it, and print it. Typically, the recordset you produce with a query isn't saved, but the query structure and criteria you used to get the results are saved. You can check for the most recent data again at any time, simply by rerunning the query. Queries have titles, so you can easily find them and use them again. Because Access saves query structures and criteria, if you frequently need a certain set of information, such as sales during a specific year, you can avoid hunting down that data each time, just by rerunning the query. Chances are, you have better things to do with your time.

You can create and save multiple queries to retrieve data in different ways. Queries are easy to revise as well, so if you don't set them up right the first time, or if your needs change, you can easily change your criteria. You can even use one or more queries as the source of data for another query, increasing your efficiency as you select more and more precisely to get just the data you want.
QUERY TYPE
Select query

DESCRIPTION

Retrieves data from one or more tables and displays the recordset in a datasheet. This is the most common type of query.

Parameter query Prompts the user to enter values that define the query, such as a specified region for sales results, or a specified price range for houses. Cross-tab query Arranges a recordset to make it more easily visible, using both row headings and column headings. Action query SQL query Creates a new table or changes an existing table. An advanced query that is created by using an SQL statement.

Access provides many different types of queries to meet many different needs for data. We'll briefly describe most of the query types, although in this course we'll focus on the most commonly used query type, the select query. A select query retrieves data from one or more tables and displays the recordset in a datasheet. You can also use a select query to group data, and to calculate sums, counts, averages, and other types of totals, although we won't cover calculations in this course. A parameter query displays a dialog box when it runs, prompting the user to enter information to use as criteria for the query. You can design a parameter query to prompt for more than one piece of information; for example, you can design it to prompt for two dates. Access will then retrieve all data with values between those two dates. A cross-tab query arranges a recordset to make it more easily visible, using both row headings and column headings. Data can be seen in terms of two categories at once. An action query creates a new table or changes an existing table by adding data to it, deleting data from it, or updating it. Because an action query is so powerful, actually changing table data, you should consider backing up your data before running an action query.

An SQL query is created by using a statement in Structured Query Language (SQL). SQL is an advanced way to query, update, and manage relational databases. Access can create the SQL statement for you when you create this type of query, or you can create your own SQL statement. Download size: 172 KB (<1 min @ 56 Kbps)
Problems with the practice?

Practice in Access

Try our troubleshooting tips

In this practice, you'll run some queries and look at their results. Then you'll take a look at the queries under the hood to see how they actually work.

ABOUT THE PRACTICE SESSION When you click Practice in Access, you may see a security warning. When you click Open in the Security Warning dialog box, a practice database will download to your computer and open in Access, and a separate window with practice instructions will appear alongside (see picture). Note You need to have Access 2003 installed on your computer.

TIPS

If the practice instructions aren't visible, or if they disappear when you click in Access, click the Access Help taskbar button and then click the Auto Tile button in the upper-left corner of the instructions.

If the practice instructions cover up Access, click the Auto Tile button in the upper-left corner of the instructions.

BEFORE YOU BEGIN Make sure to close Access if it is already running.

START THE PRACTICE Click the Practice in Access button now. Which of the following is a reason to use a query? A query makes data entry easier.
Nice thought, but

A query retrieves data, using criteria that you specify.

Very good. A que

A query produces a formatted, printed report of your data.

Not really. To pro

When you create a query, what does Access save? The data.
Not exactly. A qu

The query structure and criteria to retrieve data.

Exactly. Access

The way the data looks when viewed or printed.

Not exactly. Quer

Data returned by a query is called a _____. recordset

Exactly. You can

parameter
Try again. A para

selected field

Sorry, but no. A f

Queries can make your data more useful by selecting from it to answer questions and perform tasks.

Now that you've learned the basics about queries, it's time to create one yourself. In this lesson, you'll learn two ways to create a select query, a simple but versatile type of query that is used in many different situations. To continue reading this lesson on your own, click Next.

You can create queries in Design view or by using a wizard.

As with forms and reports, Access provides two basic ways to create queries: by using a wizard, and in Design view. The wizard, also known as the Simple Query Wizard, gives you a head start in setting up your query's structure by making some arrangements for you. In Design view you have total control when creating a query. You drag the fields you want to a grid, and then you enter the criteria for selecting the data to be retrieved. You can also create your query using the wizard and then refine the query in Design view to get just what you need.

A wizard guides you through creating a query.

The Simple Query Wizard begins by prompting you to select the database fields you need. You can select fields from tables. You can also select fields from preexisting queries. For example, if you were retrieving a list of people from an Employees table, the wizard would prompt you to choose fields to include in your query, such as each employee's name, manager, and extension. The wizard also enables you to group and summarize data, which isn't necessary for simple queries but can help you analyze more complex recordsets.

After you create your query, the wizard can run it, or the wizard can take you to Design view. In Design view you can specify criteria and refine your query. For example, you could specify in Design view that the retrieved list show only employees in the Marketing Department and that it be sorted by the employees' last names

You can create and modify queries in Design view. Design view shows the tables or the existing queries that you can base your query on... ...and a grid where you can add criteria and modify your query.

In Design view, you begin by choosing the tables or existing queries that contain the fields you want to use. Then, you select and drag those fields to a grid. The fields can come from just one table, or from multiple tables. In this course, we focus on working with one table. After you have added your fields, you can specify criteria and other settings, such as whether to sort the results. Note You can change the fields used in a query after you have made your original selection. For details on making

changes, see the Quick Reference Card. Whether you create your query with the wizard or in Design view, testing it in Design view lets you easily tweak your query if you don't get the results you want.

In Design view, you can double-click... ...or drag fields... ...to add them to the grid.

The fields you specify for a query control the data that the query retrieves. For example, in a list of the best-selling products, you might want to see the name of each product, its profit margin, its sales figures, and its distributors. You might not need to know information such as the product's manufacture dates. You can specify the fields you want whether you use the wizard or Design view. The wizard prompts you to choose the tables or queries you want to use, and then which fields you want to use. In Design view, you also start by choosing the tables or queries you want to use. Then you add each desired field to your query by dragging it from the table summary displayed above the grid. This action will populate both the Field and the Table boxes in the query. You can also double-click fields to select them, and they will appear in the grid in the order in which you click them.

Criteria help focus data by specifying precisely what you want.

Criteria are details you build into a query to identify the specific data you want to retrieve. For example, if you're hungry for lunch, you might want to display only the recipes for lunch items. To do this, you would specify a criterion that limits the recordset to recipes that say "Lunch" in the WhichMeal field. Recipes that have any other data, or no data, in that field do not fulfill this criterion and so are not retrieved by this query. To set a criterion, you type the text or value that focuses the query into the Criteria row in the query grid. For example, to limit the recordset to lunch recipes, you simply type Lunch, surrounded by quotation marks, into the Criteria row under WhichMeal. Criteria can be as simple as "Lunch" or more complex. Complex criteria can include multiple conditions (for example, all lunch recipes that also use chicken in their ingredients). Or you can compare values (for example, all recipes that have more than 200 calories per serving).

You can specify which of the fields that you use in your query are displayed in the results.

Sometimes you'll prefer not to display all the data that a query retrieves. The information may not be necessary, or you may not wish to advertise the criteria that you used in the query.

For example, if you were retrieving just your recipes for lunch dishes, you'd want to display each recipe name and its description. But you wouldn't need to display the WhichMeal field, since all recipes returned by that query would be for lunches. If you titled your query something like Lunch Recipes, it would be redundant for people to see the WhichMeal field. The Show box lets you decide whether to display each field used in your query. You can display or not display a field, whether or not you have specified a criterion for that field. You can check or clear the Show box for each field any time that you use the query. This feature also enables you to reuse a query but to display only some of the results, if you need only a subset of the recordset on a particular occasion. You can show two fields instead of a dozen, without having to create a new query for the purpose

In Design view... ...you can run a query... ...and view its results.

You can test a new query in Design view. Just click the Run button you to the results view. If you don't see the results you want, click the Design button

on the Query Design toolbar. This will switch

to return to Design view for more tweaks.

To run a query, all you need to do is to open it by double-clicking it in the list of queries, which appears when you click Queries under Objects in the Database window.

To better display your query results, you may want to create a form; to better print your query results, you can create a report. For more information, see the courses "Forms follow function" and "Reports I: Show off your data."

Download size: 168 KB (<1 min @ 56 Kbps)

Problems with the practice?

Practice in Access

Try our troubleshooting tips

In this practice, you'll create and run a couple of simple queries.

ABOUT THE PRACTICE SESSION When you click Practice in Access, you may see a security warning. When you click Open in the Security Warning dialog box, a practice database will download to your computer and open in Access, and a separate window with practice instructions will appear alongside (see picture). Note You need to have Access 2003 installed on your computer.

TIPS

If the practice instructions aren't visible, or if they disappear when you click in Access, click the Access Help taskbar button and then click the Auto Tile button in the upper-left corner of the instructions.

If the practice instructions cover up Access, click the Auto Tile button in the upper-left corner of the instructions.

BEFORE YOU BEGIN Make sure to close Access if it is already running.

START THE PRACTICE Click the Practice in Access button now