Re: Multiple specification of constraints

I'll try to give an example of a constraint, which can not be implemented in a RDBMS.

For example giving a mortgage to a person. The decision is based on :
1. Knowledge of the customer in the 'banks' database.

    (His income, his spending, his his savings.). 2. External database.
(Here in my country we have a centralised record of debt's and of not repaying your debt's.)
3. Knowledge from several databases, using Olap and datamining tools to access riscs. (For ages, postal codes, maybe even the color of somebody's car).

The decision is made by a human (a bank-employee).

I think here getting or not getting a mortgage is for the bank-customer a constraint ruled.

Maybe in the future this constraint can be implemented, but at the moment I do not think this is possible for at least two reasons : 1. An outside database.

   (Which can not be accessed by 'outside' systems). 2. Constraints although implemented by the bank, which are not totaly clear to the outside world. (Even if the rules are clear to the employee, there is probably an understanding within the bank that the rules are not to be vented, and not to be written down explicitly.)

In the future this might be implemented by automated processes. Using datamining functions to access the riscs for certain type of customers (drivers of red cars have a higher risc ?). At the moment I doubt that the law allows this kind of decision making. (Although I am pretty sure insurance companies use these kind of techniques.).

I am aware that this is an 'extreme' example.

ben brugman

"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news:K5n1c.20848$9G4.6151_at_newssvr31.news.prodigy.com...
> "ben brugman" <ben_at_niethier.nl> wrote in message
> news:403e2973$0$1416$4d4ebb8e_at_read.news.nl.uu.net...
> > (Some database people say that if a constraint can not be implemented
> > in a database, then it can not be a real constraint. I do not agree with
> > that.)

>