Hi Thomas,
While I sympathize with your ultimate goal, I have to clear up some
misconceptions before I can address it.
The fact is that Rete-based expert systems and RDBMSs are actually
very, very similar. Both maintain tables of relations (lists of facts
that adhere to deftemplates, or rows of database records.) Both keep
zero or more indices on each table (SQL KEYs in the RDBMS, the Rete
memories themselves in the expert system.) Inserting data into the
database (asserting facts into the expert system) is made slower by
the presence of the indexes; retrieving data (generating partial
matches or activations, or doing queries for the RDBMS) are faster
because of the indexes. Both types of systems assume that once the
data is loaded, it will change slowly. If this assumption is
invalidated, either system becomes worse than a flat-file. And both
kinds of systems can trigger an event (fire a rule) when certain data
become true.
In any event, the important thing to see here is that neither type of
system has a "matcher" that actively roots around in the
database. Classification of data is driven by inserting the data
itself. In the case of an RDBMS, a query comes from outside, and is
mapped onto the existing indexes as best as can be done. Then linear
search is used to eliminate unwanted records.
In the case of the expert system, there are no queries at all. When a
fact arrives, it is routed by the Rete network to be recorded in various
specific places according to the existing indexes. When a fact is
inserted into an index, other facts -already at that index- may be
joined to it, and the joined facts may be stored in yet another
index. SOme indexes trigger rule activations when joined facts are
stored in them. But nothing ever actively iterates through the fact-list
looking for facts that match certain characteristics. That kind of
searching behaviour is exactly the inefficiency that Rete is designed
to avoid. So it really does make sense to copy all the database info
into Jess, if you can.
One thing that would help would be the ability to persist the entire
populated Rete network. The final release of Jess 5 should do this
properly with the bload/bsave commands (bsave right now only saves the
network, but not the data in it.)
All that said, since Rete indexes are so much denser than typical
RDBMS indices, as an RDBMS gets larger, it eventually becomes much
better at storing large amounts of data (probably not faster, just
more space-efficient.) In the limit of large data, it starts to make
sense to do exactly the kind of thing you're asking about.
Here's a way to do it using Jess' new backward chaining
capability. Note that backwards chaining is activated in precisely
the same sort of way as database triggers are: a fact reaches a
certain point in the Rete network, and the node at that location is
wired up to take an action -- in this case, simply assert an
appropriate need-MYTABLENAME fact.
(set-backchain-reactive MYTABLENAME)
(deftemplate MYTABLENAME (slot MYFIELD1) ...)
(defrule foo
(A ?X)
(MYTABLENAME (MYFIELD1 ?X))
=>
(do-something))
(defrule MYTABLENAME-MYFIELD-fetch
(need-MYTABLENAME (MYFIELD1 ?X))
=>
(issue-query-and-assert-facts
(format nil "select from MYTABLENAME where MYFIELD1 = '" ?X "'")))
Now, you might need a great many rules like
MYTABLENAME-MYFIELD-fetch, but they could probably be generated
automatically easy enough. Similarly, the deftemplates could be
autogenerated as well. issue-query-and-assert-facts is a relatively
involved by straightforward function, left as an exercise for the
reader :)
>
>
> Hi!
>
> G. David Barnett wrote:
> >It appears that you are trying to map the contents of the database into
> >the world of facts within JESS. This may not be what you are really
> >looking for.
> >...
>
> You are right. I definitely don't want to do this. This is what I meant
> with the "on-demand" assertion (without bulk assertion). The databases
> (potentially very large ones) should only be accessed when the fact is
> actually needed.
>
> I should perhaps tell you more about the background of my question:
>
> As a part of my Ph.D. thesis I am currently implementing an EAI
> architecture for a process-level integration of (legacy) information
> systems (e.g. SAP R/3, host-based systems, etc.). One important component
> is an intelligent sensor/listener that recovers high-level business events
> (e.g., "Sales Order created") from database events (inserts, updates,
> deletes) observed (using automatically generated database triggers) in the
> information system's database (Ernest: I sent you a paper about it).
> The recovery rules are semi-automatically induced using machine learning
> algorithms and then installed (together with all other also automatically
> generated templates one needs) in Jess at run-time. For each observed
> database event (logged as an XML string in a special database table) a
> corresponding fact is asserted in the Rete engine. When a rule fires, you
> can do things like notify users or trigger dependent actions/workflows etc.
> The current limitation is that you can only pass on the information carried
> by the database events. In case one needs additional information (e.g. from
> lookup tables) you need to query the database (just then).
>
> I think Robin Burke got that point (by the way, what did Ernest reply to
> that message):
> >* a specialized version of deftemplate that specifies the database
> >specifics, the columns of the relation, and the key fields.
>
> I already generate "normal" deftemplates using the database schema.
>
> >* a specialized matcher that, when encountering a "database-backed"
> >fact, performs a query to retrieve all matching rows. You would be
> >required to supply at least one value in a key field. Each row would
> >be turned into an assertion and then matching would proceed normally.
> >...
> How would you do that?
>
> In my special case I only need to read from the database (although writing
> might be a future issue). Changes to database relations are reported by the
> triggers anyway, so you don't need to continuously query the database.
>
> I would be greatly interested in continuing that discussion.
>
> Greetings
>
> Thomas Barnekow
>
> ________________________________
>
> Dipl.-Inform. Thomas Barnekow
> Fraunhofer IAO, Competence Center Software Technology
>
> mail: Nobelstraße 12, D-70569 Stuttgart,
> Germany
>
> phone: +49 (0) 711 / 970 - 2346
>
> fax: +49 (0) 711 / 970 - 2300
>
> email: [EMAIL PROTECTED]
>
> web: http://www.swt.iao.fhg.de
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
> in the BODY of a message to [EMAIL PROTECTED], NOT to the
> list (use your own address!) List problems? Notify [EMAIL PROTECTED]
> ---------------------------------------------------------------------
>
>
---------------------------------------------------------
Ernest Friedman-Hill
Distributed Systems Research Phone: (925) 294-2154
Sandia National Labs FAX: (925) 294-2234
Org. 8920, MS 9012 [EMAIL PROTECTED]
PO Box 969 http://herzberg.ca.sandia.gov
Livermore, CA 94550
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
