OO Databases using Eiffel 
Author Message
 OO Databases using Eiffel

I have been looking at OO databases, with the hope that my organisation
may use one in the future. What I have been looking for is one that will
allow me to define what one would call 'business rules' in a relational
database. Such rules are explicitly defined and stored
in the database. As far as I can see there is no equivalent mechanism in
OO databases (certainly not in the few I have looked at) and so such
rules are implicitly embedded in the code used to implement the
persistent classes in the database.

I'm sure most of you are ahead of me, but it strikes me that an OO
database that incorporated a Design by Contract methodology into its
schema generation facilities, would effectively allow me to do this.
Does anyone know of any databases that do this ? I imagine any that
do would use Eiffel to implement persistent objects.

Failing that, is it possible to put an Eiffel wrapper around an existing
C++-based OO database, e.g. ObjectStore? I can imagine all sorts of
problems with this, since (as I understand it) OO databases tend to
override memory allocation routines to make objects persistent.

If an OO database using Eiffel does not exists, then I would encourage
someone to get to work quickly. I would certainly buy it ;-).

Regards,

Stuart.

--
============================================================
Stuart L. Moodie                      Tel:+44-(0)1223 494662
EMBL Outstation -- Hinxton            Fax:+44-(0)1223 494468
European Bioinformatics Institute  
Wellcome Trust Genome Campus                    
Hinxton, Cambridge CB10 1SD

============================================================



Fri, 05 Nov 1999 03:00:00 GMT  
 OO Databases using Eiffel

Quote:

> I'm sure most of you are ahead of me, but it strikes me that an OO
> database that incorporated a Design by Contract methodology into its
> schema generation facilities, would effectively allow me to do this.
> Does anyone know of any databases that do this ? I imagine any that
> do would use Eiffel to implement persistent objects.
> If an OO database using Eiffel does not exists, then I would encourage
> someone to get to work quickly. I would certainly buy it ;-).
> In OOSC2, Bertrand Meyer mentions both Matisse and Versant in the chapter on OO persistence.

-- Ted Velkoff


Sat, 06 Nov 1999 03:00:00 GMT  
 OO Databases using Eiffel

Quote:

> I have been looking at OO databases, with the hope that my organisation
> may use one in the future. What I have been looking for is one that will
> allow me to define what one would call 'business rules' in a relational
> database. Such rules are explicitly defined and stored
> in the database. As far as I can see there is no equivalent mechanism in
> OO databases (certainly not in the few I have looked at) and so such
> rules are implicitly embedded in the code used to implement the
> persistent classes in the database.

Correct - no products provide this ability standard (whether there
are add-ons from any of the ODB vendors I don't know off-hand). For
an OO system which process rules, there are several possibilities:

      * if the "rules" are really propositions from the business
        domain - i.e. statements which are always true (DRIVER
        must always have a VEHICLE), then you can encode
        them as class invariants and other assertions. Since these
        assertions govern the valid states of objects, and ODBs are
        for storing state (forget the methods for the moment), an
        ODB doesn't need to understand assertions as such, just be
        able to store the state of objects that do.

        In this solution, the "rules" are effectively hard-coded;
        only the software engineers can get at them.

      * if the "rules" are statements governing the behaviour of
        business processes and information being modelled in the
        system, and they are usually subject to modification
        themselves, they need a representation
        amenable to being authored (created), edited (modified),
        validated, displayed (read) by humans. This could be via
        GUI or text files or whatever. In this case we are dealing
        with a syntax representation of the rules (which can be OO),
        and a parser of some kind is needed. The output of the parser
        (or some further transform thereof) will be an object
        form of the rule which is executable (i.e. a compiled form);
        for instance the rule may cause some kind of query filter to
        be constructed, or it may result in actual method dispatching
        on the underlying business/domain object model.

        The decision in this situation is: in which form do you store
        the rules? If in their syntax form, they are always immmediately
        editable, displayable etc, but always have to be "recompiled"
        on the fly for execution; if in their "compiled" form, they
        are immediately executable, which is more convenient for
        periodic execution, but probably useless for modification
        (unless you reverse-compile them). In this case, you would
        normally store both forms.

      * other possibilities exist, depending on how complex the rules
        are. If there are a number of standard rule templates known
        in advance, then it may be the case that only certain parameters
        need be changed. In this case, the rules can be coded as part
        of the software, and a parameter editing/input facility is
        all that is needed (e.g. values in .ini files).

Quote:
> I'm sure most of you are ahead of me, but it strikes me that an OO
> database that incorporated a Design by Contract methodology into its
> schema generation facilities, would effectively allow me to do this.

One thing to note: you are presupposing a particular flavour of
assertion
usage - one where assertions are assumed to be on all the time, since
if not, no rule "evaluation" is going on. Also, you have to be prepared
to have an exception raised, and to deal with it, if a rule is violated.
In other words, if a rule is violated, it means the software is
incorrect.
This may indeed be the case - it's perfectly legitimate, but the thing
is not to mix up rules of this kind and modifiable business rules.

The more standard idea of assertions is pure correctness checking,
which has no functional effect on the system execution. While assertions
can serve your purpose (as I understand it), you probably want to
express
some of your business rules as functional methods which don't throw an
exception on failure, or else as modifiable syntax as above.

Quote:
> Does anyone know of any databases that do this ? I imagine any that
> do would use Eiffel to implement persistent objects.

We are using Eiffel and Matisse to do the job. There is also a product
by HASC which will make Eiffel objects persistent in an O2 database.

Email if you are interested in particular details.

- thomas beale



Sun, 07 Nov 1999 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. ?? OO database using Eiffel ??

2. FU exacter Infos about databases, database functions in Eiffel

3. Infos about databases, database functions in Eiffel

4. Any sites using OO (particularly OO COBOL) development on the mainframe

5. Any sites using OO (particularly OO) development on the mainframe

6. Eiffel and other paradigms ( was re: who is using eiffel )

7. Eiffel and other paradigms ( was re: who is using eiffel )

8. Urgent!!Oracle9i:using ODBC, I am noy able to link to my database tables using Access

9. Looking for the OO database for VW

10. OO database for "normal" people

11. WILL TRAIN IN OO Databases

12. OO Database expert in NYC

 

 
Powered by phpBB® Forum Software