Data integrity is orthogonal to stored procedures and triggers
Depends on how you define data integrity. If I have a banking application where it should be impossible to update the value of the balance column of the current_account table without there being an appropriate entry in the debit or credit tables I would call it a data integrity issue, and enforcing it with stored procedures and/or triggers would seem a sensible option.
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.
I think I'll just have to say to-may-to / to-mah-to on this one. As far as I'm concerned when I do something like:
CREATE OR REPLACE TRIGGER enforce_business_rules
... etc ...
I'm doing something to the current_account table. YMMV :-)