Please enable JavaScript to view this site.

Invantive Estate

The following simple example shows how, based on a data model and relationships, a business layer is realized:

The business object acme_gebruiker_rollen_v is composed of three elements (for example, registered with use of the screen Views):

Element 1: acme_gebruiker_rollen, alias grl.

Element 2: acme_rollen, alias rol, relation: rol.id=grl.rol_id.

Element 3: acme_gebruikers, alias gbr, relation: gbr.id=grl.gbr_id.

Based on this specification Invantive Producer will produce a database view similar with the following view:

create or replace force view acme_gebruiker_rollen_v

as

/*

* Generated by it_install, version:

* $Header: http://svn.invantive.com/repos/p104/trunk/help/nl/manual/Topics/ip-voorbeeld-bedrijfslaag.xml 19891 2012-10-09 13:23:03Z gle3 $

*/

select grl.id                    grl_id

,      grl.orig_system_reference  grl_orig_system_reference

,      grl.datum_intrf_geladen    grl_datum_intrf_geladen

,      grl.datum_intrf_bijgewerkt grl_datum_intrf_bijgewerkt

,      rol.id                     rol_id

,      rol.code                   rol_code

,      rol.omschrijving           rol_omschrijving

,      rol.alle_prjctn_zien_vlag  rol_alle_prjctn_zien_vlag

,      ...

,      gbr.wachtwoord             gbr_wachtwoord

,      gbr.orig_system_reference  gbr_orig_system_reference

,      gbr.datum_intrf_geladen    gbr_datum_intrf_geladen

from   acme_gebruiker_rollen          grl

join   acme_rollen                    rol

on     rol.id = grl.rol_id

join   acme_gebruikers                gbr

on     gbr.id = grl.gbr_id

This view can easily be used to present data in the normalized data model as a business object. It is no longer necessary that users of this view have to determine every time again relationships: all information is already available as fields in the business object, even though the information comes from multiple tables.

Moreover, the result contains a number of instead-of triggers. These ensure that any changes or additions of data in the view result in the correct actions on the underlying tables:

 

create or replace trigger acme_gebruiker_rollen_ord

instead of delete on acme_gebruiker_rollen_v

for each row

...

begin

 --

 -- Populate the old and new records...

 -- Check the Access Control list for this transaction...

 -- Fill-in default values...

 -- Call the before-delete user hook if available...

 -- Delete from base table...

 --

 delete

 from   acme_gebruiker_rollen grl

 where  1=1

 and    grl.id = l_old.grl_id

 ; ...

 --

 -- Call the after-delete user hook if available.

 --

 if acme#gebruiker_rollen.has_after_delete

 then

   acme#gebruiker_rollen.after_delete(l_old, l_new);

 end if;

exception...

end;