F -X C h a n ge F -X C h a n ge

PD PD
1/5/2010 Develop Business applications with Micr…

!
W

W
O

O
N

N
y

y
bu

bu
to

to
k

k
lic

lic
C

C
w

w
m

m
w w
w

w
o

o
.d o .c .d o .c
c u -tr a c k c u -tr a c k

Previous Contents Next

Lesson 4 for Tuesday, January 05, 2010

Creating relationships

For more information and special deals related to

any of the issues on this page, plac e your cursor
over the double-underlined links.
All information supplied by Kontera.c om.

Identifying the tables

After Lesson 3, these are the tables you should have.

Note that there are several fields in both tables that refer to Links to other table. The reason for that is that
Relationships are very powerful in database design.

Let's look at the c ase of c redit c ards in the Customer table.

www.profsr.com/access/accless04.htm 1/5
 F -X C h a n ge F -X C h a n ge
PD PD
1/5/2010 Develop Business applications with Micr…

!
W

W
O

O
N

N
y

y
bu

bu
If you have to keep a record of the customer's c redit card name, number and expiry date you will create 3 fields in the
to

to
k

k
table. Obviously, c ard number and date will be individual but, you may have 2,000 c ustomers with Visa. When you
lic

lic
C

C
w

w
m

m
w
enter the c ustomer's record you c ould just type "Visa" for the c ard name. But what if the person keying the data keys w
w

w
o

o
.d o .c .d o .c
c u -tr a c k c u -tr a c k
"Viza" instead, or " Visa", or "Vissa", or ...... If, later on you have to have a list of all c ustomers with a "Visa" card, all
those entered incorrectly won't show-up.

And what if Visa decided to change its name to VizaCard? You would have to go through the rec ords and c hange
2,000 customers.

The solution to those problems is: don't key the c ard name into the rec ord, selec t the name from a list, and the list
will c ome from another table.

In this c ase, we create a CreditCard table and it will contain only a list of credit c ards that we will ac cept.

The c ustomer record won't actually contain the c redit c ard name, it will contain a pointer to the CreditCard table. If
ever a card company changes its name, we only need to change the name in the CreditCard table and all customers
who point to that name will automatic ally be c hanged.

Relationships and data types

One crucial point you have to keep in mind when

describing relationships: the link is always from the
primary key of one table to a field in another table.
The primary key can be any type field - in CreditCards
it's a Text(50) field. The other end of the relationship
must contain a field of the same type and size. So,
in the Customers table, c_CardName must also be a
Text(50) field.

In the other tables we'll look at in a minute, the

primary key is defined as an AutoNumber field.
AutoNumber is not a type, it's a function. The data
type is Number and the Length is Long integer. In
those relationships the other end of the link must
also be defined as a Number field.

In all relationships involving an AutoNumber, the

other field must be a Number. In the Language table
l_No is AutoNumber so, m_Language in Movies is
Number Long integer.

A common mistake is to try to link two AutoNumber

fields together.

The CreditCard table doesn't have to be complicated, as you can see:

To c reate the Relationship, hit the Relationships button on the toolbar:

www.profsr.com/access/accless04.htm 2/5
 F -X C h a n ge F -X C h a n ge
PD PD
1/5/2010 Develop Business applications with Micr…

!
W

W
O

O
N

N
y

y
bu

bu
to

to
k

k
lic

lic
C

C
w

w
m

m
w w
w

w
o

o
.d o .c .d o .c
c u -tr a c k c u -tr a c k

Referential integrity: this

is important; it means that
you can't enter a credit
card that is not in the
CreditCard table; this
keeps the data honest;
you almost always want to
do this.

Cascade update: if a card

name changes, all
customer records will be
updated automatically to
reflect the change; that's
OK - usually you want this
to happen.

Cascade delete: if you

delete a credit card name
from the CreditCard table,
all customer records
holding that card will be
deleted; you don't want
that to happen; don't
check this box.

www.profsr.com/access/accless04.htm 3/5
 F -X C h a n ge F -X C h a n ge
PD PD
1/5/2010 Develop Business applications with Micr…

!
W

W
O

O
N

N
y

y
bu

bu
to

to
k

k
lic

lic
C

C
w

w
m

m
w w
w

w
o

o
.d o .c .d o .c
c u -tr a c k c u -tr a c k

Now, apply the same idea to the Movies table.

The fields: Category, Rating, Language, Format c an all be stored in other tables and linked to Movies.

The same princ iples will apply. If you add a new category, you add it only once to the Categories table. If a category
name changes, you change it onc e, in the Categories table.

The only differenc e in those tables is that we've given eac h item in the list a number: 1 = Action, 2 = Romance, etc .
The list will still work the same as the CreditCard table.

For example, the Language table:

Here's what you will eventually get when all the tables and relationships are set-up. Don't worry about all the extra
tables, we'll get to those in the following lessons.

www.profsr.com/access/accless04.htm 4/5
 F -X C h a n ge F -X C h a n ge
PD PD
1/5/2010 Develop Business applications with Micr…

!
W

W
O

O
N

N
y

y
bu

bu
to

to
k

k
lic

lic
C

C
w

w
m

m
w
Next week: Entering data into tables. See you then! w
w

w
o

o
.d o .c .d o .c
c u -tr a c k c u -tr a c k

www.profsr.com/access/accless04.htm 5/5