Re: Can these constraint be implemented in an RDBMS ?

Again thanks for your solution,
now another question pops up.

How about constraints who can access which data.

In real live we have a outside the "RDBMS" routine which does the checking if a person is allowed to access certain type of data.

Rules like :
If he belongs to a 'certain' department het can access any dossier which was on that department in the last three weeks.
Or if he has an appointment in the comming three weeks with a customer, he can access the customers data. (Except sometimes for a certain part).

The rules are quite complex, and our implementation is to check the rules and then give the user permission for the next 24 hours for that data.

We could build this into views, but then allready complex views would get a lot of extra tables added to the view, like the appointment table, the table which describes to which department a person has access etc. etc. This makes the views far more complex and probably very slow because the access has to be evaluated for each row. (Over and over again).

Do you have a solutions for this type of problem within your 'RDBMS' ?

Is access control part of a 'RDBMS' ?

ben brugman

"Alfredo Novoa" <alfredo_at_ncs.es> wrote in message news:4044793f.9804438_at_news.wanadoo.es...
> On Tue, 2 Mar 2004 11:15:40 +0100, "ben brugman" <ben_at_niethier.nl>
> wrote:
>
> >> There is a clear contradiction. Oracle and SQL-Server are not RDBMSs.
> >
> >Can you clearify this a bit more ?
>
> Oracle and SQL Server are not truly Relational Database Management
> Systems, they violate The Relational Model in many ways.
>
> >
> >Can you name RDBMSs ?
>
> No. I can't. They don't exist.
>
> >Do you have a solution for the problem if this requirement (Oracle or
> >SQL-server)
> >is dropped.
>
> It does not seem very difficult.
>
> Here is a solution in Tutorial D I typed in a hurry and I have not
> checked, so I supose it is flawed O:-)
>
> var Customers relation { Customer Char } key { Customer };
>
> var Accounts relation { Account Char, Customer Char, Amount Numeric }
> key { Account };
>
> var Sets relation { Set Char } key { Set };
>
> var SetMinimums { Set Char, MinimunAmount Numeric }
> key { Set }
> foreign key { Set } references Set;
>
> var SetAccounts { Set Char, Account Char }
> key { Set, Account }
> foreign key { Set } references Sets;
>
> var IndividualAccounts view
> Accounts { Account } minus SetAccounts { Account };
>
> var SetAccountsAmount view
> summarize SetAccounts join Accounts per SetAccounts { Set } add
> Sum(Amount) as Amount;
>
> create constraint MaxAmount
> IsEmpty(Accounts where Amount > 100000000);
>
> create constraint IndividualAccountsNotNegative
> IsEmpty((Accounts join IndividualAccounts) where Amount < 0);
>
> create constraint SetAccountsNotNegative
> IsEmpty(SetAccountsAmount where Amount < 0);
>
> create constraint MinimumAmount
> IsEmpty(SetAccountsAmount join SetMinimums where Amount <
> MinimumAmount);
>
> > The imaginairy customer still likes to make a choice between at
> >least two 'RDBMSs'.
>
> Then he would have to build at least two RDBMSs by himself :)
>
>
> Regards
> Alfredo
Received on Tue Mar 02 2004 - 15:19:07 CET