As RuralGuy mentioned, the purpose of referential integrity is to prevent you from creating orphan records either by deleting parent records or by inserting children without parents. The way a relational database eliminates the need for storing the same data in multiple places is by the use of queries to join tables. For example, in an order entry application, your minimum set of tables would be Customer, Order, OrderDetail, and Product. In the relationship window, the relationships would look like:
Customer-->Order-->OrderDetail<--Product
Notice that OrderDetail has arrows that go both ways. OrderDetail is a "child" of an Order. That means that it makes no sense to have an orderDetail that is not linked to an Order (its parent). You would not want to be able to delete an Order without also deleting the OrderDetails. This feature is called CascadeDelete and you use it to tell Access that when you delete an Order, you want Access to automatically delete any dependent OrderDetails. For the relationship between Customer and Order, which is also a parent/child relationship, you would NOT want to delete orders if you delete a customer. Therefore, if you do NOT specify CascadeDelete on this relationship, Access will not allow you to delete a Customer that has any Order records.
CascadeUpdate may be what you were expecting to push data to other tables. It does, but not the way you are thinking. If your customer ID was comprised of the first four characters of the customer name plus a number, you would run the risk of having to change the customer ID if the customer's name changed (This is just an example and a good reason why you would really never want to do this). So my customer number is Hart2234. I get married and my name is now Cowles. In order to keep with your naming scheme, you would want to change my customerID but that would "break" any link to orders I have placed and cause them to be orphaned. So you would define CascadeUpdate on this relationship so you can change my customerID from Hart2234 to Cowl2234 and Access will change all my orders so that the CustomerID stays connected to my customer record.
This was an extremely simplistic explaination of CascadeDelete and CascadeUpdate which are the ONLY updates which affect child tables. If you were thinking you could store the customer name in the order table and have that change if you changed the customer name, or store the product name in the OrderDetail table and have that change if you change the product name, think again. You ALWAYS store ONLY the primary key of the table you want to relate to. Then you use a query to join the two tables on that common key to make all data available in the same recordsource.
