Re: RM's Canonical database

From: Marshall <marshall.spight_at_gmail.com>
Date: 3 Jul 2006 18:49:10 -0700
Message-ID: <1151977750.636470.187310_at_m73g2000cwd.googlegroups.com>


Bob Badour wrote:
> Marshall wrote:
>
> > Bob Badour wrote:
> >
> >>The truth of the matter is we
> >>have several uniform and universal names for these 'rules' including the
> >>word 'rules' as well as the word 'constraints'.
> >
> > I have never been very clear on a taxonomy of these things. What
> > *exactly* "business rules" are I'm not certain.
> >
> > If we are speaking of declarative integrity constraints written in
> > FOL, it is clear what is being denoted.
> >
> > If we are speaking of procedural app server code that executes
> > updates, it is clear what is being denoted.
> >
> > I don't have short, specific terms for either of these.
> >
> > Also, what about building abstractions inside the dbms
> > that execute updates, a la stored procedures. Is that
> > ever done? Good idea, or what? Theoretical foundations?
>
> You mean like triggered procedures?

I was thinking more of something like stored procedures. (But I don't know much about either, so I could be quite confused.)

It seems to me that sometimes one wants to capture formula abstractions within the dbms, as well as simple constraints. For example, there could be a complex formula to calculate the annual bonus, and a procedure to apply the bonus to a given payroll calculation. I can see how this could be captured procedurally, or via a declarative formula, but I don't see how this could then be expressed as either relational algebra, or as FOL constraints. (Well, I actually can see how it could be a query, but where do you "put" it?) It seems like you need something more.

For example, in *What Not How* Date gives some examples of rules.

TOTAL_OWED = Sum(ORDER_TOTAL where not PAID)

So, what is this exactly? A rule, but that's just giving it a name. The rule seems to be specifying a named amount as an aggregate query. If I read this correctly, there are no relation names here, only attribute names. So what is the scope of this?

Another one:

If QTY_ON_HAND - QTY_ORD < REORDER_LEVEL, Reorder

So what's this? A trigger? Is Reorder some kind of procedure?

I don't really understand the logical framework that these sorts of rules exist within. Clearly they are more expressive than FOL. So what exactly *can* they express? What are their limits?

> Yes, that is done. Like most design
> options, whether it is a good idea depends on a lot of factors. Do audit
> trails have a theoretical foundation? I don't know. But one pretty much
> has two choices for them: 1) use a product that preserves the entire log
> and allows one to query the state of the database at any past moment and
> all transactions or 2) use a triggered procedure to record the audited
> facts.
>
>
> > I am somewhat frustrated that my professional experience
> > has never included any of the features of SQL outside
> > of queries and updates, and only the most minimal of
> > integrity constraints: primary and foreign keys. My
> > understanding outside of this area remains weak
> > and/or theoretical only.
>
> First, let me say I do not think a theoretical understanding is
> weak--quite the opposite.

Ah, it was not my intent to say that. What I was saying was that my understanding is 1) weak, insofar as it is not very developed, and in an unrelated matter, also 2) lacking in any practical experience, which is to say "theoretical only." Perhaps "and/or" was a poor choice of connective. It is my feeling that the best understanding is one that is both solid in theory and experienced in practical applications.

> Second, I suggest Date's _Introduction to
> Database Systems_ is probably the most comprehensive text with regard to
> these issues. The classification of constraints has evolved over the
> years, and I would say the evolution has more to do with aesthetics and
> elegance than with theory.

Does "Intro" cover rules, or constraints, or both? (Or am I missing something and rules are in fact a kind of constraint?) I am not all that interested in constraint taxonomies; the ones I have seen don't seem to add much, insofar as every constraint could be considered a database constraint, and ones that reference only a single column or a single table are merely simpler examples than those that reference multiple tables, such as foreign key constraints.

Marshall Received on Tue Jul 04 2006 - 03:49:10 CEST

Original text of this message