MICROSOFT ACCESS CONCEPTS AND TERMINOLOGY

Before we jump in and start building, entering, and

maintaining an Access Database, we need to talk a little about
concepts and terminology.
The most common misconception about Access is that it
replaces Excel, which is completely untrue, they are very
different. You’ll hear the word Database used everywhere in
both Excel and Access, it’s a really loose term.
Excel is usually referred to as a Spreadsheet, where
Access is a Relational Database. Both are used to store data
information, but Excel stores that information both vertical and
horizontally, Access only stores the information vertically.
Excel is mainly used for laundry lists of information, like
inventory lists and sales, and although it can be organized in
hundreds of sheets none of the information is really related to
other.
In Access everything has some kind of relation. If I own a
car company I am going to be dealing with more than just
inventory and sales. Now I have to deal with who bought the
car, who sold it, what manufacturer did I get it from, where was
it shipped, and which mechanic worked on it last.
All this information can come from separate tables but is
still related. The best Excel can do with relationships is linking.
So Excel is great for simple lists with complex
calculations and formulas, and Access is great for storing large
amounts of data that is interrelated or dependant. It’s great to
know both.

Now Access has some terms that differ from Excel, such
as Field. A field is a single piece of categorizing information
organized in columns. Excel calls them headings. An example
would be First Name, Last Name, and so forth.
A Record is a collection fields pertaining to one person
or entry. Like Bob Peterson from Los Angeles, California.

Page 1 of 8
 A Table is a group of records stored in rows and
columns. So I could have a Customers Table with customer
information and an Employees table with employee information.
A Database in Access refers to a collection of seven
objects or tools. So not just tables, but queries, forms, reports,
macros, modules, and pages. The database has a size limit of 2
gigabytes. And that’s for ALL objects, not 2 gigs for each.

The Database Road map is important so you understand

how all these tools and objects are connected.
And the most important part of that is Tables. Now I
mentioned before that a table is used to store information, think
of them like a digital filing cabinet. If you want to keep it store it
in a table. I can have as many tables as I want, and it’s better to
have several smaller tables than one giant massive list.

Queries are sometimes referred to as filters, but that’s

like saying a Ferrari is just a car. A query is used to select or
display information in any way you can possibly dream of.
I can connect it to one table or an infinite number of
tables. Either way a query takes the information from a table
and gives it to me.
Weather I make a change to the table or the query,
doesn’t matter, but the information is always kept in the table.
The query never stores any information.

Page 2 of 8
 Forms are used to enter data into a table. Everyone in
this world has had to fill out a form. Go to the DMV, the doctor’s
office, or buy something off the internet, you have to fill out
your personal information.
A form can be connected to either a query or a table. It
cannot be connected to multiple tables unless they are first
connected to a query. So if I want customer, employee, and
product information, all from different tables, pass them thru
the query and into the form.
A form can be used for data entry, can be set to read
only, or both.

Reports are then used to view or print data. I might

want the information to look prettier than just a bunch or rows
and columns. Reports can be designed any way you want.
Like forms they can be connected to a query or a table
and are read only. Users cannot interact with the report. It’s like
Print Preview in Word or Excel.
These four are the main objects in Access.

There are 3 others that are more advanced objects.

Pages are like a form and report together. Access 2007
has discontinued the creation of pages and now uses
SharePoint. However if you are working on an older database
that still has pages created, they can be modified in Access 2007,
just not created.
Macros are used for automation. You can create basic
functionally for buttons or trigger them based on conditions. So
an example would be click a button and print a specific invoice
report.
Modules are like macros only with greater flexibility and
power. They open the VBA editor and allow you to redefine or
even create your own objects. So if I want to integrate AutoCAD
into Access I just need a module that allows that.

Page 3 of 8
 When creating a database the most important part
starts outside of the Access program. Many people feel
brainstorming isn't necessary or is trivial. I guarantee 90% of the
problems people have with their Access databases can or could
have been solved during their brainstorming session.
When building your tables the first thing you'll want to
do is list them out. Now I'm going to keep my example simple so
I'll pretend we've just inherited a car company and the tables
will be Customers, Employees, Cars, Orders, and Order Details.

Next list out the fields in each table. Customer fields

would include things like Name, Address, Phone Number, what
their credit score might be, weather their married or single, or
what their use for the car might be commuter or recreational.
You decide how much information is needed.
But even before you start listing out fields, every table
needs a Primary Key or Unique Identifier. In the Customer's case
it could be as simple as Customer ID. This gives the table a
specific identifier than can be used in relationships. If the table
doesn't have a Primary Key, you can't have a relationship. And if
we don't have any relationships, you might as well be doing this
table in Excel.

For the Employees table the first thing we need is the

Primary Key. Employee ID works fine. Then list off all the other
fields you deem necessary; like Address, Department, Social, or
whether or not their part of the company baseball team.
Again you decide what fields are needed. If you're not
sure start asking people what kind of information needs to be
stored and kept.

Page 4 of 8
 For our Cars table we can use the car's Vehicle
Identification Number. If the item being stored in the table has
something that defines it as unique, like a Vehicle Identification
Number or Social Security Number for our employees, use it.
Now I didn't use the Social Security Number for our employees
because if I did, other users might see it and I might want to
limit who has access to that information.
I can then list off the rest of the fields like Make, Model,
Color, and so forth.

With the Orders table we can create an Order ID field.

This would be just like what you'd get at a fast food restaurant
when you order something.
Now in the case of orders I don't want the customer's
name, address and other information just the Customer ID
which will relate back to the Customer table. Same with the
Employees table, this way there are less chances for duplicate
data or mistakes.
These two fields have an FK in front of them just to
remind myself that they aren't Primary Keys in this table. The
Primary Key is Order ID. These are called Foreign Keys, which
simply means Primary Keys from another table.

Order Details will also have Foreign Keys from both the
Orders table and the Cars table. We also need to have a Primary
Key. Rather than create a single Primary Key, I can use both
Foreign Keys together as a Composite key.
This Composite Key is created when both Order ID and
VIN are added to the Order Details table.

Page 5 of 8
 Now by itself this is great list, but we need to
incorporate Normalization. The problem with this philosophy is
everyone has a set of normalization rules. I try to boil them
down into three rules.
The first is Atomic Data, an atom is the smallest particle
in the universe, so break your fields down into the smallest,
meaningful, most non-destructive fields possible.
For example break Name into First and Last Name,
Middle, Title, Suffix, or Nickname. You might not need all those
fields, which is what I mean by non-destructive. Don't feel you
have to break fields down just to do it.
The point is, if I have a name field like Bob Peterson, I
have to deal with the name as a whole. Break it down into first
and last and we can now sort and filter by either first or last
name.
So Address can be broken into Street, City, State, Postal
Code, Country, Region, you could even break the Postal Code
into the first five numbers and the last four for mailing purposes.
Phone Number could be broken down by Area Code, but
again this might be getting into what I called destructive, just
breaking fields down that aren't necessary.

The Second and Third rules are very close in meaning so

I will list them both. Everything Must Rely on Keys, means make
sure everything inside the table has to do with that table. If I
need fields that deals with another table, make sure I have a
Foreign Key, and get rid of everything else.
And One Topic per Table means if I have so much
information in a single table, it might be better to break it up.
For example, I might not want everyone seeing the employees
pay rate, benefits, and hours. So can split the table into two
different tables and connect them using a Primary and Foreign
Key.
Even Accessories and Packages could be separated into
different tables.

Page 6 of 8
 No matter how many rules everyone says there might
be they all deal with two concerns, Data Redundancy, and
Inconsistent Dependencies. So spend as much time as you need
during the brainstorming session and you can save a lot of
heartache later.
It's easier to change on paper than it is in the program
with 100,000 or millions of records behind it.

Before we can create Relationships in Access we need to

understand how their setup. When creating Relationships,
ignore any fields expect key identifier fields, so focus on Primary
keys, Foreign keys, and Composite keys. Then simply connect
the dots.
Customer ID from the Customers table is connected to
the Foreign key in the Orders Table. Employee ID is connect to
Employee ID. Primary keys can also be connect to multiple
tables, so the Employee ID from the Employees table can also be
connected to the HRData table.
Connect the rest and that's it.

Access is very good at knowing which type of

relationship is needed, but it's still good to know your
relationship types. There are three types of relationships.
The first type of relationship is One to One; you have a
One to One relationship with your employer. You're the only
one who receives your paycheck. If someone else is getting your
paycheck you've got a problem.

Page 7 of 8
 The second type of relationship is One to Many; I have a
customer and I want that customer to purchase multiple items
from me, it's called return business. Same goes for my
employee, the employee either sells multiple cars or is gonna
have to find another job. Each Order can have multiple details.
So a customer can either purchase one car or hopefully a whole
fleet of them.
Now this last ones tricky. Most people think we have
one car and want to sell it only once, but actually we have one
car that we want to sell more than once. If a car comes back to
me in trade I want to be able to turn around and sell it again. So
the relationship is a One to Many.

The third Relationship is Many to Many; which means I

have many items in one table that are connected to many items
in another table.
The best example I can give you is projects and
employees. I can have multiple projects and multiple employees
on those projects. This relationship is the only relationship that's
extremely dangerous, and if you can avoid using it, do so.
Most of the time a Many to Many relationship can be
broken into different tables with a third acting as a junction
connecting the two. This way you end up with two tables that
are connected to the third using One to Many. However this
relationship exists because there might be times when you can't
break the table apart.

After creating relationships you might hear these tables

referred to in a different manner.
The Customers table will be referred to as a Parent table
and the Orders table will be its Child. Just like any child can grow
to be a parent, the Orders table would be referred to as the
Parent and Order Detail would be its Child, making the
Customers table the Grand Parent of the Order Details table.
Some tables share parents Like Cars sharing Order
Details and Employees sharing Orders. The HRData table has no
children and is considered a Window of Employees.
And of course you might have a table that isn't
connected to the relationships so it's called an Orphan table. As
you can see setting up the relationships is easy so long as the
table design is worked out. But remember, even though all these
names and terms sound fun, this is probably the most important
part of Access.

Page 8 of 8