This is the heart of any application. We call them "business" rules, but even if your app is not used by a business (say, an app for managing your DVD collection), you still use rules to define what is acceptable data and what is not.
A trivial example might be that you require all phone numbers to also have an associated area code. While a database may have no problem storing a blank area code, your business might if you need to contact a customer with that phone number. That is why this is a business rule and not a database issue.
Business rules are also used to represent business processes. For example, perhaps you offer a customer a free item after they have bought a certain number of items; your business object for recording purchases would contain the code to update the customer's free item status when they have met their purchase targets.
A good rule-of-thumb for design is that you define a separate bizobj (common abbreviated term for "business object") for each table in the database. Since ideally a database table represents a single entity, there should be a single bizobj class for handling validation of that type of entity. There are many exceptions to this rule, of course, but these are usually matters of database design choices. If you stick with the notion of one bizobj per entity, your coding will be much cleaner.