Sean,
As someone who breaths this stuff, here is a little snapshot regarding
business rules:
Business rules enforce business requirements across business functions.
A business function is an action performed by the user of an
application to fulfill a specific business purpose. For example, taking
a new order. In some systems, business functions are called
"transactions," but these are really functions bound together in an
atomic recovery unit.
A business requirement is a statement of objectives for part of a
business function. It identifies the rules for working with the data
(validation, derivation, security and so on). A requirement usually
encompasses a series of validations and computations that begin as an
update on a data object and may in turn affect other data objects. For
example, the requirements for inserting each order item might be (1)
assuring that the customer balance does not exceed the credit limit, (2)
calculating the order total, and (3) ordering more parts when inventory
falls below a given level.
Declarative business rules implement the validations and computations of
the requirements. Once defined, the rules' triggers fire automatically
to enforce the business requirements across all business functions.
The modularity and reusability of business rules encourage a flexible
approach to business requirements definition and implementation. One
standard approach is to work with end users to develop an inventory of
application business functions, analyze each function to determine
business logic requirements, and define rules that enforce each
requirement.
When you change a rule, you do not have to model all of the potential
effects on all related requirements and functions. . As a result,
modifying the business logic is a fairly short and simple procedure.
Good Luck
--
David Upham
Nan Pao Information Systems, Inc.
Tel: 886-2-2816-5511 ext. 35
Fax: 886-2-2813-2111
E-Mail: da...@npis.com.tw
Sean Gallivan wrote in message <35747406...@bton.ac.uk>...
A business rule is a requirement established by management that must
be met before a transaction can be completed.
David's response seemed somewhat less baffling than some others :-)
On Wed, 3 Jun 1998 07:07:33 +0800, "David Upham" <da...@npis.com.tw>
wrote:
Steve's article on business rules is very complete and informative.
Business rules are one of the segments of our industry that is growing
rapidly, and remains a popular topic among the tech execs. But speaking on a
very basic level, a business requirement is nothing more than a constraint
your data must honor. For example, a stock table with a low, high price for
the day might have a business rule stating, "The high price may not be lower
than the low price." You would implement this rule in SQL like this:
create table StockPrice(
ticker varchar(8) not null,
date smalldatetime not null,
lo smallmoney not null,
hi smallmoney not null,
check (lo <= hi)
)
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
This both over and understates the complexity of the notion of "business
rules."
Business rules represent the set of policies used when you "do stuff."
This might include:
- Before filling an order that has been requested, you must consult the
inventory database to see if the inventory is in stock.
If there's lots of stock on hand, there is no problem; there may be
further business rules to deal with:
- Maxmimum order sizes
- How much will you sell to this customer, based on their credit
rating?
- How much stock *must* be kept on hand to handle unusual requests?
- What happens if there's *not* enough stock on hand?
- Order more?
- Tell the customer you can't fill the order?
- "Steal" from another order that hasn't yet been shipped?
Each of these things represents a "How do we do business?" question,
and needs to be represented somehow in the information system.
a) There may be database "field level" restrictions that can be used to
make sure business policy is followed.
For instance, you may require that the "customer number" for an order be
filled in ("not null"), and must reference a valid entry in the
"customer table" ("foreign key").
b) More complex requirements may involve having SQL or other code behind
the scenes that queries various tables to (say) check inventory levels
before accepting a customer order.
These tend to be the "interesting" business rules, and much of the area
of client/server computing represents trying to find efficient/effective
ways of managing these requirements.
The issue being that this sort of [rule checking] may involve looking at
a variety of data in different databases, and thus requires some form of
"application server" on which the programs reside and run, in the case
of particularly complex business requirements.
It is a nice thing if the requirements are simple; field checking may
be adequate.
Slightly more complex requirements may be handled within a modern RDBMS
via a stored procedure or "trigger."
More complex business rules may, most effectively, be handled via
initiating a program outside of the RDBMS server.
c) Some policies may not be enforced by the computer system; staff may
be *ordered* to fill in certain fields on a screen that the system does
not directly enforce.
There might be after-the-fact checks in place; there may be the business
policy that Internet users are not allowed to visit sexually oriented
web sites. A proxy server could have been used to filter out known
"offending" sites, but queries might be logged by the proxy server so
that someone can later check a report, see that you've visited
"www.playboy.com," and talk to your manager about it...
--
In most countries selling harmful things like drugs is punishable.
Then how come people can sell Microsoft software and go unpunished?
(By ha...@rost.abo.fi, Hasse Skrifvars)
cbbr...@hex.net - <http://www.hex.net/~cbbrowne/lsf.html>
Dear Colleague,
I'd like to inform you of the possibility to
submit innovative OO applications to the 5th
OMG Object Application Awards.
Deadline is August 20, 1998.
The entry kit can be downloaded at http://www.comdex.de/index2.html
Please post this call as you see proper.
Regards
Roberto Zicari
OMG Central Europe.
Dear Colleague,
I`d like to inform you of the possibility to submit innovative applications
in the area of Electronic Commerce to the international
COMDEX Applications Awards `98, sponsored by Microsoft, Siemens Nixdorf and
Software AG. Media partner Ziff Davis Deutschland.
The Awards last year were very successful with over 160
entries submitted from more than 10 countries world wide.
The Entry Form for the Awards can be obtained at
http://www.comdex.de/awards/
The deadline for submitting entries is **August 20, 1998**
The Awards Ceremony is on September 28 at
COMDEX Enterprise Frankfurt`98. (http://www.comdex.de)
Please help distributing this call and linking the page.
Thank you!
Best Regards
Roberto Zicari
Chair COMDEX Awards Jury.