Access 2007-2013
Access 2000-2003
Seminars
Tips & Tricks
Access Forum
Course Index Insider Circle
Collapse Menubar
 
Tutorials   News   Tips   Templates   Forums   Help   Logon   Order  
 
 
 

Access Relationship Seminar
Just about everything there is to know about relationships in Access

 

 

In this seminar, you will learn just about everything there is to know about relationships in Microsoft Access. Setting up proper relationships between your tables is absolutely crucial to building a successful database. Bad table design, and bad relationships between those tables, is disasterous, and will cause you nothing but trouble down the line.

This seminar covers just about all of the different possible relationship scenarios that you will ever come across. We will build eight (8) different database projects so you can see how to set up good relationships between your tables.

Watch this video to learn more about this seminar:

 

Want to Learn More?

You can watch first two lessons plus the final review lesson in our Online Theater. There you will learn more about exactly what's covered. Then continue reading the course outline below if you have further questions. Of course, if you have specific questions about the seminar that aren't covered here, always feel free to contact customer service.

 

 
Seminars - Access Relationships
Description: Learn about the different ways to properly set up relationships in your Access databases.
Versions: I will use Access 2010, however the lessons are valid for all versions of Access back to 2000 with some minor cosmetic differences.
Pre-Requisites: This course is mostly for beginner to intermediate users. Basic knowledge of Access table, query, and form design is a must. You should have at least taken my Beginner Access courses before taking this seminar. A couple of the later lessons are for advanced users. There will be some VBA and a little bit of SQL used, so it would help for you to have taken my Access 300-level courses as well, but that's not necessary. I will explain what you need to know to get the databases working. Most of the course doesn't require any advanced knowledge, however.
Running Time: 3 Hours, 58 minutes
Cost: $99 - Order multiple courses to receive a discount up to 50% off

 

This seminar will teach you about all of the following types of relationships:

1. No relationships
2. One-to-Many
3. One-to-One
4. Many-to-Many
5. Self-Join One-to-Many
6. Self-Join Many-to-Many
7. Reverse Relationships
8. Multiple Relationships

We will build sample databases to track:

1. Children to Parents with their relation (one-to-many)
2. Which parents receive mail on their child's behalf
3. Student data with a secondary optional detail table (one-to-one)
4. Vendors to Products and vice versa (many-to-many)
5. Employees to Supervisors (self-join, one-to-many)
6. Complete family history with relationships (self-join, many-to-many)
7. Organizations to Members (whether companies, families, charities, etc.)
 

We will begin by looking at in table that has no relationships. You'll learn how NOT to build a database. This is basically one table with all kinds of information in it that shouldn't be there.

 

Next we'll build a database to track students and parents. This is a one-to-many relationship where one student can have many parents. We'll also keep track of which parents will receive mail for each student.

 

We will learn about one-to-one relationships. This is handy if you have a lot of data but you only have some information on most of your records. For example, if you have a student database but only have names for most of your students. You need to be able to track additional information such as address, phone number, and so on, however you only have that information for a small group of students. A 1-to-1 relationship saves a lot of space in your database in this instance. Plus you can also put sensitive information in a separate table, such as financial data.

 

Next we will learn how to create many-to-many relationships. These are quite popular but difficult to implement because they involve a third table. You need a junction table to link two other tables in a many-to-many relationship. For example ,we will learn how to track vendors and the products they sell, however each product may also be offered by multiple vendors. This is the basis for a many to many relationship.

 

Next we'll create a self-join table. This is where a table relates to itself. We'll create an employee form that allows us to choose a supervisor for each employee. However, the supervisor is just an employee, so the table relates to itself.

 

You'll also learn how to create a grouped report showing each supervisor in the employees he supervises. This requires building a query using the same table twice.

 

Next you'll create a another self-join table. We will track people and their relatives again, but this time we will set up a many-to-many relationship so each person can relate to each other person in the same table. This allows you to set up complete family trees (great for genealogy databases).

 

Next we will set up something that I like to call a reverse relationship. We'll specify two people, tell the database that one of them is (for example) the other person's uncle, and the database will figure out that the reverse relationship is niece or nephew.

This is one of the more advanced lessons in this seminar. It will use a little VBA programming and some SQL. I will show you everything you need to know to get the database working, but taking my SQL Seminar and advanced Access lessons first would be a great help. But don't worry, I'll show you how to get the database is working. Just follow along a step by step.

 

Finally will make a database to track organizations and members. Now in organization can be a family, company, charity, church, or anything else you want it to be. We'll track members of that organization in a many to many relationship. These can be family members, employees, donors, etc.

We will track multiple addresses for each organization and for each member. We will also build a contact management table to keep track of correspondence with each organization or member. We will build one big form so that we can see all of the information for each organization. We'll do the same thing for each member.

 

So as you can see we cover just about everything there is to know about relationships in Microsoft Access. From the very basic to the advanced, you will definitely know how to properly setup your tables and relationships after watching this seminar.. Of course, if you have any questions about whether or not this seminar is for you, please contact me.

NOTE: There is a NEW lesson on database table normalization found in Access Expert Level 2 that wasn't included in this seminar. It's not necessary for you to learn, but it covers a lot of theory that isn't discussed in this seminar. It was recorded after this seminar was finished.
 

 

Access Relationship Seminar - Outline

00. Intro (7:59)

01. Types of Relationships (13:04)
No Relationships
One-To-Many
One-To-One
Many-To-Many
Self-Join One-To-Many
Self-Join Many-To-Many
Reverse Relationships
Multiple Relationships

02. No Relationships (5:26)
Flat File
The wrong way to build a database
Child and Parents in Same Table

03. One-To-Many Relationships (10:45)
Delete parent data from student table
Create a RelativeTypeT
Create ParentT
Fill in sample data

04. One-To-Many Form 1 (12:38)
Create ParentF Subform
Set up relationship with subform wizard
Turn off navigation buttons
Turn off scroll bars

05. One-To-Many Form 2 (9:53)
Hide IDs
Combo Box for RelativeType
Combo Box Wizard

06. One-To-Many Query (15:34)
StudentQ for Mailings
Query Criteria
Field Name Aliases
OR Conditions
Show ALL students and related parents
LEFT Inner Join
Global Relationships
Cascade Delete

07. One-To-One Relationships (18:33)
Student
Extra Student Info
One-To-One Global Relationship
Command Button to Open 2nd Form
Show Specific Records
Forms!FormName!FieldName
Refer to Value on Another Form
Default Value
One-To-One Subform
Discuss Securing Data with Split DB
Discuss Multiple Back-End Files
One for Users, One for Admins

08. Many-To-Many 1 (11:47)
Products and Vendors
Multiple products per vendor
Multiple vendors per product
Junction table
Cross Reference Table
Vendor Form
Product Form

09. Many-To-Many 2 (14:24)
Products with Vendor Subform
Vendors with Product Subform
ProductVendorF
Product Combo Box
Vendor Combo Box
On Double Click Event
VBA Code to open a form
OnDblClick
Docmd.OpenForm
Where Criteria

10. Self Join One-To-Many (17:00)
Relating a Table to Itself
EmployeeT
SupervisorID
Supervisor Combo Box
String Concatenation
Calculated Field
Employee With Supervisor Q
Grouped Report
Sorting & Grouping Level
Report Showing Supervisor with Employees

11. Self Join Many-To-Many (20:46)
People to People with Relationships
Person table and form
Junction Table
PersonQ with Full Name
Form Subform for People and Relatives
Great for Genealogy Tracking

12. Reverse Relationships 1 (14:23)
Add opposite relationships
If Mother is picked, Child is default
Non-gender specific opposites
AllowAdditions
Do not allow additions to subform
Unbound forms
Control Source
Unbound Combo Boxes
Turn off Navigation Buttons
Record Selectors
Scroll Bars
Modal
Popup
Docmd.Openform
Set value across forms
Forms!FormName!FieldName

13. Reverse Relationships 2 (22:44)
AfterUpdate Event
DLOOKUP Function to find Opposite
SQL
INSERT INTO
Append Query
IsNull
MsgBox
Exit Sub
Docmd.Close
Refresh
DoCmd.SetWarnings

14. Multiple Relationships 1 (14:58)
Main Organization Table
Members Subtable
Great for Charities, Churches
Fund Raising possibilities
Good to track Family Data
Multiple subforms of data
One master form
OrgT for organization
Junction Table
Member Subform

15. Multiple Relationships 2 (21:56)
Address subform on Org Form
Address is for Org OR Member
Address subform on Member Form
OnDblClick to jump from Org to Member
Vice Versa
Contact History Subform
Contacts for both Orgs and Members

16. Review (5:43)
 

 


 

 
 

Student Interaction: Access Relationship Seminar

Richard on 6/20/2012:  In this seminar, you will learn just about everything there is to know about relationships in Microsoft Access. Setting up proper relationships between your tables is absolutely crucial to building a successful database. Bad table design, and bad relationships between those tables, is disasterous, and will cause you nothing but trouble down the line. This seminar covers just about all of the different possible relationship scenarios that you will ever come across. We will build eight (8) different database projects so you can see how to set up good relationships between your tables. This seminar will teach you about all of the following types of relationships: 1. No relationships 2. One-to-Many 3. One-to-One 4. Many-to-Many 5. Self-Join One-to-Many 6. Self-Join Many-to-Many 7. Reverse Relationships 8. Multiple Relationships We will build sample databases to track: 1. Children to Parents with their relation (one-to-many) 2. Which parents receive mail on their child's behalf 3. Student data with a secondary optional detail table (one-to-one) 4. Vendors to Products and vice versa (many-to-many) 5. Employees to Supervisors (self-join, one-to-many) 6. Complete family history with relationships (self-join, many-to-many) 7. Organizations to Members (whether companies, families, charities, etc.) You can learn more about this seminar here: Access Relationship Seminar Of course if you have any questions, post them here!
Tracy on 6/28/2012: Great seminars. Let's see more
will powers on 6/29/2012: is there a way besides going into the relative typeT table like in the video to make the opposite ID? I want to make a database for our parade in town. the idea would be to fill up a float with people and show floats that aren't full yet and floats that are full. then use the reverse to show what people went on what float in the past.

- Will

Reply from Richard Rost:

Well, the floats that are full/not full would just be a simple DCOUNT (or a form footer total) of the number of child records.

Making a query to show who was on which float in the past should be a simple matter too.

Jim Upton on 7/6/2012: Hi Richard

Readlly enjoy this relationship seminar. I will need to watch it again but thats me at being slow getting my head around it.

I would be interested in expantion on any of those comments that you made and adding payments into this and making reports as a address book

Reply from Richard Rost:

Thanks, Jim.

 Chris on 7/11/2012: Not to belabour this and just to ensure I understand. On the cascade deletes, if another record uses the same cascaded data, the common records are not deleted. It is only when there is one remaining record that uses this cascaded record that it is removed from the database. Is this correct? (ref: 15:00)

Reply from Richard Rost:

Cascade deletes come in handy if you delete a PARENT and want all of its CHILD records to be automatically deleted. I don't know what you mean about "common records." Can you explain with an example?

Chris on 7/11/2012: My earlier question was asking: When does the data in a cascading table get deleted when there are several other records pointing to the same cascading record?

As an example - Three people (three records) in PersonT each refer to the same address data located within table AddressT. There exists a global relationship between these two tables using Foreign Key AddressID in the PersonT table and the Primary Key (AddressID) in the AddressT table. In each of the PersonT records, they each refer to the same address record with AddressT.

Will the AddressT record remain in the AddressT table until all three records have been deleted from PersonT?



(as a side note - yes I could try this; but I was asking so that others could also get an answer to this question)

Richard R on 7/12/2012: Chris that's a very good question. See this tip video for my reply. :)
 Bruce on 7/16/2012: Video 13 covers a lot of ground. I am grateful that I have had the opportunity of viewing this critical seminar.

Reply from Richard Rost:

Glad you're enjoying it.

Kevin Robertson on 7/16/2012: Hi Richard,

Completely loved this seminar - learned lots I didn't know. Keep up the good work!

Reply from Richard Rost:

Thanks, Kevin.

  on 7/17/2012: Brilliant AGAIN, Rick.
Couldn't honestly say anything was unknown to me but the real value in these seminars is that you show how to bring it all together.
Actually, I just realised that the one-to-one was a new idea from the point of view of security.
Well done, Rick, keep 'em coming to feed my Access adiction :o)
Regards
Chris

Reply from Richard Rost:

Ha ha. Thanks, Chris. I'm working on more crack for you right now. :)

Tom on 10/12/2012: Richard- I would like to use my choice in a combo box to populate another field without user intervention. The combo box pulls from a table that contains catalog items. Each individual item also contains a number that corresponds with a product type (stored in a product type table) Any thoughts?

Reply from Richard Rost:

Use an AfterUpdate event?

Roderick Barbour on 12/2/2012: I have been questioning the concept that Richard has of making so many copies of each database as we went through the lessons, until I just hit a key or a combination of keys and just lost my whole database. Im an old IT guy and there was always a way of getting a file or document back. But with Access, once its gone it is really gone. WOW!! Great lesson.

Reply from Richard Rost:

There is a method to my madness. :)

Kamal Benlitifah on 2/17/2013: Thanks - Kamal
Jennifer on 2/25/2013: I have asked this somewhere else: what if you have a lot of info about a single student / patient. Eg a unique pt ID but with up to 15 differing tables containing results or clinical findings. Each of these 15 is I think? a 1 to 1 relationships, but there are 15 of them??? What do you call this and how does it work.
Anonymous on 2/26/2013: I set up a table with a unique pt number which was indexed as no duplicates and made it the Primary key. I used the unique number in a 2nd form and made it the primary key, no duplicates, and was told I had broken the integrity rules as this duplicated values?? Relationships lesson 7 time 0259

Reply from Richard Rost:

Don't make it a primary key in your second table.

PETER on 4/23/2013: At minute 2:30 on the video the subform automatically shows only subform contents that match the VendorID on the parent form. That filtering doesn't seem to be occurring when I try to do it on one of my own subforms ... Is there something I missed on the video?

Reply from Richard Rost:

Access should have automatically set up a relationship between your main form and sub form. It's the LINK MASTER FIELD and LINK CHILD FIELD properties in the subform.

PETER on 4/23/2013: Please see my last comment - I just realized that rather than have Access build the parent form, I had built it myself using Form Design (as suggested by you in many other video's). When I let Access build the parent form for me, the subform behaved as expected - only showing subform values relevant to the item shown on the parent. What would I have done wrong in building the parent form from scratch compared to what Access does itself?

Reply from Richard Rost:

You can build the parent form from scratch. Just make sure you set up the link fields properties. Access SHOULD do that for you if your fields are named correctly (the same) on each of the forms.

David Robinson on 5/3/2013: Richard
All I can say your the Best, your courses and the best I have ever seen, easy to follow and you explain everything, I just need more time to get to all the courses I havew purchased and I will be purchasing more.


Thank you very much

Reply from Richard Rost:

Thanks, David. :)

Mark Bee on 5/4/2013: I am having problems with understanding how to have one address table for my customers, that relate to the customers jobs, their invoices and quotes etc... I can have 1 customers with many jobs related to one address, then 1 customer with many address and many jobs. I've been unable this far to work out how to get this to work with out running into duplicating the same address in the address table.

I've tried to make work a junction table to work between the customers, jobs, address, quotes and invoices but end up confused. Even going through this relationship seminar twice I'm unable to see how the examples relate to what I'm trying to achieve.

Can anyone help?

Reply from Richard Rost:

I would have 3 tables: customers, addresses, jobs.

AddressT has CustomerID as a foreign key
JobT also has CustomerID as a foreign key

Now, assuming a JOB will have ONE AND ONLY ONE address, you could just have one AddressID field as a foreign key field in your JobT table.

If a job can have MULTIPLE addresses, then you need to set up a FOURTH table as a junction table which would look like:

AddressesForJobsT
ID: AutoNumber
JobID: Foreign Key to JobT
AddressID: Foreign Key to AddressT
Details...

Mark on 5/7/2013: Hi Richard, Thanks for your quick reply.

A JOB will have ONE AND ONLY ONE address. So I have one AddressID field in my JobT table.

I have a JobAddressSubF for showing and inputing new addresses in the JobF. The Sub form picks up the JobID ok, but I haven't found a way to get the AddressID from the subform to update onto the JobF.

I've tried a combo box on the main form using:

Forms!JobAddressSubF.Form!AddressID

To get it into the main form but haven't got it to work.

So I'm not sure where I'm going wrong here? Or should I scrap trying to get the AddressID over and just work with the JobID as this automatically comes up in the JobAddressSubF.

The other problem I'm having is when the Job address is the same as the customers home address. I have an "AsHomeAddress" option button, which when selected, I need the JobAddressSubF to automatically update to their home address and save the relationship with the JobT/AddressT.

I'm more than happy to have a paid session to get this resolved if needed. But I'm hoping it's something simple that I'm just not seeing yet?

Please can you help?

Reply from Richard Rost:

You should have 3 separate forms: CustomerF, AddressF, JobF. You would select an address from a list of addresses ON THE JOB FORM. You can use them as subforms if you want, but be sure to REQUERY the list if the addresses are changed otherwise they won't show up in the combo on the job form. Or just use separate forms and you won't have that problem. Enter the addresses on the address form. Close it. Open the Job form and pick it.

I wouldn't even bother storing a separate home address in the customer table. Put everything in the address table and just use your "AsHomeAddress" checkbox to indicate it.

 

You may want to read these articles from the 599CD News:

 
 
Learn
 
Microsoft Accessindex
Microsoft Excelindex
Microsoft Wordindex
Microsoft Windowsindex
Microsoft PowerPointindex
Adobe Photoshopindex
Visual Basicindex
Active Server Pagesindex
Online Seminars
More...
Customers
 
Account Login
Online Theater
Downloads
Lost Password
Free Upgrades
Insider Circle
Info
 
Latest News
New Releases
User Forums
Tips & Tricks
Search Our Site
Waiting List
Production Schedule
Collapse Menus
Help
 
Live Chat
Customer Support
WalkThru Tutorials
Troubleshooting
FAQs
TechHelp
Consulting Services
About Us
 
Background
Testimonials
Jobs
Affiliate Program
Richard Rost
Free Lessons
Mailing List
Order
 
Video Tutorials
Handbooks
MYOLP Memberships
Idiot's Guide to Excel
Volume Discounts
Payment Info
Shipping
Terms of Sale
Contact
 
Live Chat
General Contact Info
Support Policy
Contact Form
Email Us
Mailing Address
Phone Number
Fax Number
Course Survey