Learn the structure of an Access database
Becoming familiar with the tables, forms, queries, and other objects in a database can make it easier to perform a wide variety of tasks, such as entering data into a form, adding or removing tables, finding and replacing data, and running queries.
This article provides a basic overview of the structure of an Access database. Access provides several tools that you can use to familiarize yourself with the structure of a particular database. This article also explains how, when, and why you use each tool.
In this article
A database is a collection of information that is related to a particular subject or purpose, such as tracking customer orders or maintaining a music collection. If your database isn't stored on a computer, or only parts of it are, you may be tracking information from a variety of sources that you must coordinate and organize.
For example, suppose the phone numbers of your suppliers are stored in various locations: in a card file containing supplier phone numbers, in product information files in a file cabinet, and in a spreadsheet containing order information. If a supplier's phone number changes, you might have to update that information in all three places. In a well-designed Access database, the phone number is stored just once, so you only have to update that information in one place. As a result, when you update a supplier's phone number, it is automatically updated wherever you use it in the database.
Access database files
You can use Access to manage all of your information in one file. Within an Access database file, you can use:
Tables to store your data.
Queries to find and retrieve just the data that you want.
Forms to view, add, and update data in tables.
Reports to analyze or print data in a specific layout.
1. Store data once in one table, but view it from multiple locations. When you update the data, it's automatically updated everywhere it appears.
2. Retrieve data by using a query.
3. View or enter data by using a form.
4. Display or print data by using a report.
All of these items — tables, queries, forms, and reports — are database objects.
Tables and relationships
To store your data, you create one table for each type of information that you track. Types of information might include customer information, products, and order details. To bring the data from multiple tables together in a query, form, or report, you define relationships between the tables.
1. Customer information that once existed in a mailing list now resides in the Customers table.
2. Order information that once existed in a spreadsheet now resides in the Orders table.
3. A unique ID, such as a Customer ID, distinguishes one record from another within a table. By adding one table's unique ID field to another table and defining a relationship between the two fields, Access can match related records from both tables so that you can bring them together in a form, report, or query.
A query can help you find and retrieve the data that meets conditions that you specify — including data from multiple tables. You can also use a query to update or delete multiple records at the same time and to perform predefined or custom calculations on your data.
1. The Customers table has information about customers.
2. The Orders table has information about customer orders.
3. This query retrieves the Order ID and Required Date data from the Orders table, and the Company Name and City data from the Customers table. The query returns only orders that were required in April, and only for customers who are based in London.
You can use a form to easily view, enter, and change data one row at a time. You can also use a form to perform other actions, such as sending data to another application. Forms typically contain controls that are linked to underlying fields in tables. When you open a form, Access retrieves the data from one or more of those tables, and then displays the data in the layout that you chose when you created the form. You can create a form by using one of the Form commands on the Ribbon, the Form Wizard, or create a form yourself in Design view.
1. A table displays many records at the same time, but you may have to scroll horizontally to see all of the data in a single record. Also, when you view a table, you can't update data from more than one table at the same time.
2. A form focuses on one record at a time, and it can display fields from more than one table. It can also display pictures and other objects.
3. A form can contain a button that you click to print a report, open other objects, or otherwise automate tasks.
You can use a report to quickly analyze your data or to present it a certain way in print or in other formats. For example, you may send a colleague a report that groups data and calculates totals. Or, you may create a report with address data formatted for printing mailing labels.
1. Use a report to create mailing labels.
2. Use a report to show totals in a chart.
3. Use a report to display calculated totals.
Now that you know about the basic structure of Access databases, read on to learn how to use the built-in tools to explore a particular Access database.
See details about the objects in a database
One of the best ways to learn about a particular database is by using the Database Documenter. You use the Database Documenter to build a report containing detailed information about the objects in a database. You first choose which objects will be detailed in the report. When you run the Database Documenter, its report contains all of the data about the database objects that you selected.
Open the database that you want to document.
On the Database Tools tab, in the Analyze group, click Database Documenter.
In the Documenter dialog box, click the tab that represents the type of database object that you want to document. To create a report on all of the objects in a database, click the All Object Types tab.
Select one or more of the objects listed on the tab. To select all of the objects on a tab, click Select All.
The Database Documenter creates a report that contains detailed data for each selected object, and then opens the report in Print Preview. For example, if you run the Database Documenter against a data entry form, the report created by the Documenter lists the properties for the form as a whole, the properties for each of the sections in the form, and the properties for any buttons, labels, text boxes, and other controls on the form, plus any code modules and user permissions that are associated with the form.
To print the report, on the Print Preview tab, in the Print group, click Print.
Explore a table in Design view
Opening a table in Design view gives you a detailed look at the table's structure. For example, you can find the data type setting for each field, find any input masks, or see if the table uses any lookup fields — fields that use queries to extract data from other tables. This information is useful because data types and input masks can affect your ability to find data and run update queries. For example, suppose that you want to use an update query to update particular fields in one table by copying data in similar fields from another table. The query will not run if the data types for each field in the source and destination tables don't match.
Open the database that you want to analyze.
In the Navigation Pane, right-click the table that you want to explore, and then click Design View on the shortcut menu.
As needed, note the name of each table field and the data type assigned to each field.
The data type assigned to a field can limit the size and type of data that users can enter in a field. For example, users may be limited to 20 characters in a text field, and cannot enter text data in a field set to the Number data type.
To determine whether a field is a lookup field, click the Lookup tab in the lower section of the table design grid, under Field Properties.
A lookup field displays one set of values (one or more fields, such as a first and last name), but usually stores a different set of values (one field, such as a numeric ID). For example, a lookup field may store an employee's ID number (the stored value), but it displays the employee's name (the displayed value). When you use a lookup field in expressions or in find and replace operations, you use the stored value, not the displayed value. Becoming familiar with the stored and displayed values of a lookup field is the best way to make sure that an expression or a find and replace operation that uses the lookup field works the way that you expect.
The following illustration shows a typical lookup field. Remember that the settings that you see in the Row Source property of the field will vary.
The lookup field shown here uses a query to retrieve data from another table. You may also see another type of lookup field, called a value list, that uses a hard-coded list of choices. This figure shows a typical value list.
By default, value lists use the Text data type.
The best way to find lookup and value lists is by displaying the Lookup tab, and then clicking the entries in the Data Type column for each field in the table. For more information about creating lookup fields and value lists, see the links in the See Also section.
See the relationships between tables
To see a graphical representation of the tables in a database, the fields in each table, and the relationships between those tables, use the Relationships object tab. The Relationships object tab provides an overall picture of the table and relationship structure of a database — crucial information when you need to create or change the relationships between tables.
Open the database that you want to analyze.
On the Database Tools tab, in the Relationships group, click Relationships.
The Relationships object tab appears and shows you the relationships between all of the tables in the open database.
See how objects use other objects
The Object Dependencies pane illustrates how database objects, such as tables, forms, queries, and reports, interact with or depend on other objects.
You can use the Object Dependencies pane to help avoid inadvertently deleting record sources. For example, suppose that you have a Quarterly Orders query in a Sales database, and you no longer need the query. Before you delete the query, you should find out if any of the other objects in the database, such as a form or report, use the query as a data source. You can then either modify the dependent objects to remove references to the query, or you can delete the dependent objects along with the query. Viewing a complete list of dependent objects can help you save time by removing the need to manually check object properties and minimize errors by finding the details that a manual audit might miss.
When you want to change the design of a database object, the Object Dependencies pane can also be useful by showing you how other objects will be affected by the design change. You should use the Object Dependencies pane to help you plan major design changes.
Use the Object Dependencies pane
Open the database that you want to investigate.
In the Navigation Pane, select or open a table, form, report, or query.
On the Database Tools tab, in the Relationships group, click Object Dependencies.
If prompted, click OK to update the dependency information.
Note Updating dependency information may take some time.
The Object Dependencies pane appears.
To see a list of the objects that use the object that you selected in step 2, click Objects that depend on me at the top of the pane. To see a list of the objects that the selected object uses, click Objects that I depend on.
To see dependency information for an object, click the expand (+) icon next to that object. Access shows up to four levels of dependencies for an object.
Remember these facts as you use the Object Dependencies pane:
Dependency information is available only if you have permissions to open an object in Design view.
The pane does not show information for macros and code modules.
The pane works only for tables, forms, reports, and queries, except for the following types of queries:
Action queries — queries that insert, update, or delete data
SQL-specific queries, including union queries, data-definition queries, and pass-through queries
When Access encounters nested queries, dependency information is generated only for the outermost query. This rule also applies to the source tables and queries of a query's subdatasheet, and to lookup fields.
Access generates dependency information by searching the name maps maintained by the name AutoCorrect feature — a feature that automatically corrects common side effects that occur when you rename forms, reports, tables, queries, fields, or controls on forms and reports. If tracking name AutoCorrect information is disabled, you will be prompted to turn it on before you can view the dependency information.