Issues with Data Integrity with RDBMS

Anyone know about Cascade events in a relational data base system? How it works, how it helps and if the开发者_开发百科re are any disadvantages. Thanks.

Cascade events are quite simple really. For example, say you have a User table with attribute and primary key username, and an Email table with attributes username and email address. Now it's quite likely that we might make username in Email a reference (foreign key) to username in User, because we want every user that has an email to also be in our User table. Now think about what would happen if you deleted a user in User. Should you delete all the matching rows in Email? If not, what do you do? Some DBMS's will just throw an error, saying something like "You mustn't do that! References exist and we don't know what to do with them!". This is where cascade events come in. If the DMBS supported cascading events, you might be allowed the option to specify whether the DMBS actually throws that error, or maybe delete all the matching (on username in Email) rows, so there are no "dangling" references. This is called a cascade delete.

There are other cascading options too! Another occurs if we try to update username in User to something different. Without cascading options, we would probably throw an error if there are matching rows in Email. But with cascading options, we have the option to automatically update username in Email with the new username. That is called a cascading update.

These are two major ones, but by no means the only existing "cascading" options that exist in some DBMS's.

If it helps, think of "cascading" modifications as "recursive" modifications, as their are synonymous, and is what is meant by "cascading". Modifications "cascade" down to other tables that use the same attribute.

Think about the advantages and disadvantages of this feature. We can now specify exactly what we want to happen when we want to have changes "cascade" to attributes in different tables. A possible disadvantage of allowing these features is that we now have the opportunity to cause modifications on a bigger scale than we might like (depending on design). Changing username in User may cause changes in a different table Email, even if we don't mean to!

Hope this helps.