Re: Multiple specification of constraints

From: Eric Kaun <ekaun_at_yahoo.com>
Date: Thu, 04 Mar 2004 13:36:49 GMT
Message-ID: <RhG1c.30935$yD7.22856_at_newssvr16.news.prodigy.com>


"ben brugman" <ben_at_niethier.nl> wrote in message news:4046fba2$0$279$4d4ebb8e_at_read.news.nl.uu.net...
> 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.)

Data from an external source can be made to appear as part of the database in many different ways - web services, imports and exports, DB links, etc.

> 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).

Another external source, right? The fact that they're non-relational makes this annoying, but still, the data must be interpreted, and if a person is looking at it making a decision, there's at least a chance they're thinking in terms modelable as predicates.

> 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.

It's a human decision. Depends on the decision-making process they use, but much of it could be automated. Perhaps at least to generate risk evaluations...

> 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).

Then how is the data seen by the people who need it?

> 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.)

Then that's a problem. There's a difference between wanting to automate and not... if they can't be explicit, they can't automate this. That's nothing any technology can solve, other than perhaps providing better quantitative measures for the decision.

> 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.

That's fine - I just seem most of this example outside the realm of automation - or at least peoples' willingness to automate. Received on Thu Mar 04 2004 - 14:36:49 CET

Original text of this message