– 4 – Um Geschäftsregeln von der Fachkonzeptebene in ein DV-Konzept zu überführen, wird im  Allgemeinen  das  in  [HLM88]  vorgeschlagene  Event-Condition-Action-Konstrukt (ECA) benutzt. Wenn ein Ereignis (E) eintritt, wird die Bedingung (C) ausgewertet und die entsprechende Aktion (A) ausgelöst, falls (C) zutrifft. E, C und A können sich aus verschiedenen, logisch verknüpften, Elementen zusammensetzen. Ferner kann eine Geschäftsregel definitorischen Charakter haben (z. B. „Bestellsumme = Summer aller Zeilen einer Bestellung“). Geschäftsregeln  können  sich  laut  [Da00b]  auf  verschiedene  Ebenen  einer  Applikation beziehen: 1.   Präsentationsregeln 2.   Datenbankregeln 3.   Applikationsregeln Wobei  2.  und  3.  wegen  der  starken  Verflechtung  zwischen  Daten  und  Applikation schwer zu trennen sind.⁴ Wenn  ein  Geschäftsprozess  vollständig  durch  Geschäftsregeln  spezifiziert  worden  ist, so  ist  er  auch  automatisierbar.  Hier  wird  aber  einen  Schr itt  weitergegangen.  Während bei der rein prozeduralen (objektorientierten) Programmierung die Geschäftsregeln be- reits  in  der  Zielprogrammiersprache  definiert  und  im  Zielsystem  verankert  werden,  ist hier das Ziel, durch eine deklarative Formulierung der Anforderungen automatisiert zu einer prozeduralen bzw. objektorientierten Implementierung zu kommen. Auf Grund der Determiniertheit des Regelcompilers wird bei richtiger Formulierung der Regeln  auch  die  richtige,  optimale  Applikation  generiert.  Die  Reihenfolge  der G e- schäftsregeln ist für den Entwickler irrelevant, da das System für die korrekte Ausfüh- rung durch Vorwärtsverkettung der betroffenen Regeln in der Rule Engine sorgt. Wenn davon ausgegangen wird, dass eine Vielzahl an Geschäftsregeln durch eine Vielzahl von Ereignissen  abgefeuert  wird,  so  ist  eine  erhebliche  Produktions-  und  Anpassungsbe- schleunigung möglich. Die Fehlerquelle Mensch wird in eine andere Stufe des Entwick- lungsprozesses verlagert.                                                                  4   Dies ist nicht zu verwechseln mit der Implementierungsebene. Ziel ist es immer, Daten und Logik möglichst getrennt voneinander zu halten.