I'll certainly make an attempt to do so!
Cascade Update is only needed *if* one needs to change the value for a given
record in the primary key (PK). Take a look at the sample Northwind database
as an example. You will notice that the Customers table uses a text-based PK
that is based on the name of the company. For example, Alfreds Futterkiste
has a PK value = ALFKI. Now, if Alfred sells his business to Sally, she may
wish to rename it to Sally's Deli. At this point, the PK value in the
database would not exactly match any recognizable form of the business name.
The Cascade Update option allows a database administrator (DBA) to change
ALFKI, to something else, such as SADLI. The change will automagically
"cascade" to all related records in the Orders table. Without Cascade Update
enabled, the DBA would not be allowed to make this change, because doing so
would result in unmatched order records for ALFKI that did not have a
matching parent record.
Cascade delete will cause all related records in a child table to be
automatically deleted, if the parent record is deleted. In the Northwind
example, if you delete Alfred's Futterkiste from the Customers table, and
Cascade Delete is enabled, all of Alfred's Orders will be removed as well.
This would, of course, require that cascade delete was also enabled for the
relationship between the Orders table and the Order Details table, since
enforced RI would not allow for unmatched Order Detail records to exist.
Whether one uses text-based (natural) PK or surrogate (autonumber) PK is up
to the individual developer. There are people strongly aligned on both sides
of the fence. I am personally on the surrogate autonumber side of the fence.
I'll certainly respect the opinion of others who are firmly convinced that
using natural PK is always better; I'm simply not in that camp. One advantage
of using surrogate keys is that you should never need to change the value,
since should be considered a meaningless number. Thus, no need for Cascade
Update when one uses an autonumber PK.
Here is some background information on using autonumber PK:
http://www.access.qbuilt.com/html/articles.html
(See article # 4: The Case for the Surrogate Key)
Database Normalization Tips
by Luke Chung
http://www.fmsinc.com/tpapers/genaccess/databasenorm.html
(See the section titled "Use Meaningless Field for the Key Field")
I have an intense dislike for cascade deletes in Microsoft Access. And I
don't like cascade updates.
by Access MVP Tony Toews
http://www.granite.ab.ca/access/cascadeupdatedelete.htm
Okay, so perhaps that's a bit more advanced than how I might attempt to
present such a concept to a child--actually, I probably wouldn't even
try--but have I left you with a clear understanding of the concept?
Tom Wickerath, Microsoft Access MVP
http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________