Data integrity is orthogonal to stored procedures and triggers. Data integrity is maintained by normalization and foreign keys¹. Triggers and stored procedures are the ability to use a programming language that is supported by the database engine. They are not necessary for data storage or to maintain data integrity. In fact, the entire idea of stored procedures is marked as "implementation-specific" in the ANSI-92 standard.

Now, triggers can be used to help maintain data integrity. The most obvious case is if you have a schema that has been deliberately denormalized for performance reasons. If you make a modification to table A, table B might need to be updated in an atomic fashion, to maintain the denormalization. However, that is outside the basic functions of an RDBMS.

As for triggers and stored procedures being behaviors ... I still maintain they are not truly behaviors, in the OO sense. The table doesn't have a behavior that is associated with it. If anything, the behavior is associated with the action that triggers it, not the table the action was performed on.

Another item to note is that certain things that require triggers and sequences in one RDBMS (Oracle) can be done with a set of keywords in another (MySQL). I'm speaking of the AUTO_INCREMENT keyword in MySQL that can only be duplicated by using a trigger and a sequence in Oracle. The keyword may be implemented as such under the hood, but it also may not. Regardless, it's still syntactic sugar.

1. Granted, most RDBMSes implement foreign keys as triggers, but that doesn't mean that the triggers are necessary, or even sufficient, for foreign keys. MySQL, for example, requires that the referenced column have an explicit index on it (in the InnoDB tabletype), while Oracle does not.