Thank you for your earlier answers, but based on their feedback I have reformed the question.
If the answer to the question is no, then can the data's integrity for enforced by any other means. I do not consider the use of stored procedures sufficient as they may be circumvented. Would triggers be required?
No. Some business logic involves calculations. DBMSs can do calculations, of course but that would be 'by use of built-in functions', not referential integrity.
A footnote in Date's most recent book, "Database Explorations", answers this question :
"It's worth noting in passing that this fact implies that all possible database constraints can be expressed as INDs".
INDs are "inclusion dependencies", and they are basically the same thing as SQL's foreign keys, but with the limitations imposed by SQL left out.
EDIT
In response to "would triggers be required" : "Applied mathematics for Database Professionals" has a complete dedicated chapter on how to program triggers to enforce really just any arbitrary business rule. That chapter alone makes the book worth the buck.
BTW, sprocs are not circumventable if you use the security system to block out all "direct" access to the tables. Of course you then have to depend on your security rules being defined and managed properly ...
No. There are lots of business rules that cannot be represented by CHECK constraints and FOREIGN KEY constraints alone. In practice even referential integrity constraint support in SQL is extremely limited.
For example, given two tables called Employee and Department, I can easily enforce a rule that every Employee must be assigned to exactly one Department but I cannot also enforce a rule that every Department must be referenced by at least one Employee. Technically I can create constraints to that effect but then SQL won't allow me to update the tables!
ISO Standard SQL does have a CREATE ASSERTION feature that is supposed to be for general purpose constraint enforcement but most DBMSs don't support it. Even if it were available, the CREATE ASSERTION feature is crippled by SQL's lack of basic support for multiple assignment - you can only update one table at a time. Effective business rule enforcement requires a database model that allows multiple assignment.
It would be possible to have all logic at the database level, but not with simply database schema. You can implement it all logic at the database level via stored procedures and triggers, but this can be:
I think you would be far better off implementing business logic via stored procedure, but again, you could be placing a large load on your server (depends on number of clients, transactions, etc).
In SQL terms, referential integrity constraints usually means foreign keys.
Perhaps you meant data integrity constraints? If so, we should probably extend your definition to include CREATE ASSERTION and perhaps CREATE DOMAIN. This would allow constraints of arbitrary complexity to be enforced. However, "Any given business logic" is an unreasonable requirement in practice and enforcing every business rule at the DBMS level may be undesirable.
Thank you for your input. I was however specifically concerned with foreign keys and check constraints.
May I ask why? On the face it, it seems arbitrary an arbitrary classification.
It will depend on whether the CHECK constraints you have in mind support subqueries. If yes then this will still allow constraints of arbitrary complexity but will only be triggered on the table being updated i.e. if a CHECK constraints definition involves two tables then a complementary CHECK constraint may be required on the second table.
That said, I don’t know of an industrial-strength SQL product that supports subqueries (the Access Database Engine does but I don't consider it to be industrial-strength). However, many SQL products provide as a workaround that support subqueries (and procedural code plus much more). Perhaps your definition should allow tiggers.