11 Nov 1996 updated
PowerDesigner is one of a very few Entity-Relationship tools which attempts to formalize a structure for recording business rules per se [1]. It provides a means to define such rules and then "attach" them to modeled objects. This memo examines the concepts, weaknesses, and unexploited opportunities of PowerDesigner's rules feature. It does not attempt to teach how to operate PowerDesigner's interface elements for business rules [2].
Ron Ross is perhaps the most notable author in the field of modeling business rules. Barbara von Halle has also written several articles, based largely on Ross’ work, in which she discusses the discovery and meaning of "business rules". Since Xiao Wang [3] has stated that PowerDesigner's rules are taken directly from von Halle’s articles [4], the following discussion explores Barbara von Halle’s classification of rules and how they are implemented in PowerDesigner.
As we suggest in the diagram below, the notions of "business rules" and "business objects" are attempts to classify our discoveries in the problem space so that we can begin to deal with them in a more orderly modeled manner. Modeled rules can then be fitted into the rigorous mathematical structure of Entity-Relationship modeling and, subsequently, a relational database schema.
The writings of Ross and von Halle use the term "business rule" to denote some issue, policy, or requirement of the business. It implies nothing about the translation of such rules into a computer software solution. Thus loosely taken, "business rules" include statements which recognize the existence of objects known and used by the business - what we would prefer to label "business objects" - as well as statements about the behavior of those objects - hence our narrower application of the term "business rule".
In implementing its business rules features, PowerDesigner adopts von Halle’s classification (but not her terminology) but restricts its interpretation to the behavior side, specifically to coded stored procedures and triggers.
We offer here a broader, more complete approach using PowerDesigner’s business rules features to tie together the objects and rules discovered in analysis with their corresponding relational objects and code segments in the resulting software solution.
is the definition of a perceived object, which may become a data item, entity, or larger business object. This definition may be manifested in the model as the existence of such an object, by some structural features of it, or in a textural description or documentation of the object. In any of these cases, the business rule becomes the object and serves no further purpose other than to record the object’s origin and justification.
The definition type of "business rule" leads us to the observation that "business rule" is a misnomer, implying too narrow a concept. These are really business issues, statements, policies, assertions, or requirements. While some become what we would call "business objects" (e.g., the definition of customer, product, or employee) others become "business rules" in the pure sense of actions which may or must be performed on business objects.
is a role or relationship between two objects of any complexity (e.g., data items, entities, business objects). In Object Role Modeling [5], these are the roles between objects (at the granularity of either data item or entity). In Entity-Relationship modeling, these are the relationships between entities.
This difference reveals a fundamental deficiency of E-R: it cannot model interactions between objects at the data item level. (Fact type business rules can record those in unmodeled text). E-R’s inability to model inter-attribute constraints argues strongly that given the incomplete constraints in E-R models, it is senseless to embellish them with "arc" notations trying to represent a certain small sub-set of role or relationship constraints.
is some limit on the population or membership of a domain or object type (data item, entity, or business object). Constraints express rules of allowable values, by inclusion or exclusion, either by formula or explicit list.
is a method by which the contents of some object are constructed, calculated, or derived from other objects. This implies the ability to house derived objects in a model. Relational schema (e.g., the PowerDesigner PDM) can model database views, which are business objects derived from one or more tables. And relational database instances make no distinction between base and derived columns, so any column can be either.
Unfortunately, most E-R models, including PowerDesigner, provide no means to capture a derived data item, along with the method of its derivation and some indication as to whether it is to be stored (i.e., propagated as physical columns) or derived as needed.
PowerDesigner’s capability to capture business rules in advance of (or during) the E-R modeling process provides a significant benefit. An analyst or designer can initially record casually stated business issues and later inventory their eventual satisfaction as each is attached to some modeled object.
However, PowerDesigner offers neither a conceptual framework for its rules nor meaningful explanations of its rule types. Furthermore, PowerDesigner does not limit the utilization of a rule type to corresponding object types in the model which are appropriate for that rule type. Thus in PowerDesigner any rule type can be "attached" to most of the modeled objects which have the [Rules] button.
On the other hand, everything in PowerDesigner’s documentation and support materials would lead one to believe that business rules are useful only to specify code modules for client or server execution. There is no hint that the "rules" might have come before the model or that a rule might be retained only to substantiate the existence of some modeled object. This attitude is exemplified by Version 5.0’s unexpected relocation of the Table [Rules] button from the Table properties sheet to its nested section for Check constraints.
In the table below, named cells in the left half indicate where PowerDesigner’s [Rules] feature does or should exist. Model objects which do not currently (Version 5.0.2) have access to rules are grayed out. The right half of the table maps business rule types from von Halle to the model objects which are appropriate targets for each rule type. It is important to understand that the budding science of business rules has far less precision that relation theory. There is ample room for interpretation in how a particular rule type is defined, attached, or implemented.
A definition rule can cause the existence of a modeled object (i.e., data item, entity, column, table) in PowerDesigner and it may also contribute to the unambiguous text description of such an object. A definition type rule should not result in procedural code, either in the client or the server. Since every part of a definition type rule can be expressed directly as some property of an object, the original rule is retained only to trace and substantiate the origin of that object.
A fact rule is manifested by the existence and description (including predicate labels) of a relationship in PowerDesigner, or the placement of a data item into an entity as one of its attributes [6]. Since every part of a fact type rule can be expressed directly as some property of a relationship or attribute, the original rule is retained only to trace the origin of that relationship or attribute.
Note that PowerDesigner does not currently have the capability of attaching business rules (or descriptions or annotations) to attributes; all three are only attached to the underlying data item. This precludes any definition or explanation for the attribute per se; that is, for the attachment of the data item to the specific entity. For example, we might document the existence and definition of a data item called "customer number". But how do we explain the significance of it appearing as an attribute of a sales invoice?
A constraint or validation rule may be manifested by the existence and description of a domain, index, or alternate key in PowerDesigner.
For example, analysis may uncover a requirement that some attribute combination must be unique among all occurrences. In relational terms this is a candidate key. Since PowerDesigner lacks the means to designate candidate keys, this requirement could be captured as a business rule and modeled as an alternate key with that rule attached to trace the requirement.
Or analysis might reveal the need for frequent rapid access to an entity based on certain attributes. This might be recorded as a business rule and modeled as an index with that rule attached to trace the requirement.
A constraint may also concern values or occurrences which are intra-entity but inter-attribute, or possibly inter-entity. For example, in our class exercise we specify that a pilot who is scheduled to fly a segment must be employed by the same airline as that which flies the segment. This can be captured as an unstructured rule and later implemented in any of several ways: left to the user to manage (poor choice!); enforced programmatically in client code; enforced as code [7] in insert and update triggers in the database; or modeled by the merging of two foreign keys. Regardless, the original rule should be attached to the eventual structure(s) to document the requirements and reasoning.
A derivation or formula rule is manifested by the existence and description of a data item, attribute, column, or view in PowerDesigner, and thus should only be attached to objects of those types.
For example, one might model a data item of "item total orders year to date" to be derived by incrementing from each item transaction. The derivation rule would state the transaction source and formula for calculating the total. there also needs to be a way, which PowerDesigner does not provide, to indicate whether each derived data item is to be generated into a physical column or merely modeled to represent the derivable information. Such a rule for the derivation of a single value might be coded in a PowerDesigner’s business rules editor and linked into a stored procedure to be called whenever that value is needed.
Database views are combinations of columns and rows form one or more base tables. Thus a view represents a complex derivable business object. The requirement for such a view might be captured in a business rule which is satisfied by the modeled view object.
In the case of ProcessAnalyst, it should be obvious that while analyzing process one discovers both business objects (e.g., data items) and business rules; both should flow bi-directionally between ProcessAnalyst and DataArchitect. Unfortunately, as of Version 5.0 the ProcessAnalyst module does not contain the business rules features offered in DataArchitect and AppModeler. This looks like a design oversight since the business rules features appear to be quite localized and reusable between modules.
As for PowerDesigner’s PowerBuilder extended attributes, if one has used the PowerDesigner business rules facility to record rules in DataArchitect (and, less appropriately, AppModeler), shouldn't those rules also be available in the client interface? After all, that is what the "client" radio button suggests in the rules definition window. Yet the PowerBuilder extended attributes facilities have no awareness of PowerDesigner’s business rules.
Another
is CSA’s Silverrun
RDM which includes a facility to define "processes" attached
to modeled objects. However, there is (to my knowledge) no means of defining
unstructured rules before attaching them to modeled objects. Popkin’s System
Architect does have a facility for tracking system requirements
and their satisfaction by features of the model, as does LBMS’ Systems
Engineer.See
http://www.aisintl.com/services/olais.sd.html
for an extended usage guide.Xiao
Wang of Powersoft’s Design Products Division is PowerDesigner’s original
author and continues to direct its methodology and interface. Check out
the Easter egg in PowerDesigner - open Help; About and then Shift-Ctrl-double-click
to see the product team."Uncovering
Business Rules", Database Programming & Design, December
1995; "Back to Business Rule Basics", Database Programming
& Design, October 1994.See
InfoModeler
for an implementation of ORM in a CASE
tool.Entity-Relationship
modeling is inherently defficient in that it can only model "relationships"
between "entities". E-R has no semantic expression for intra-entity
facts; e.g., inter-attribute rules or rules involving an attribute anf
an entity and some other external object. Nonetheless, intra-entity, inter-attribute
facts are common and can be captured with PowerDesigner’s business
rules.This
would be one of the less frequent cases where one might utilize PowerDesigner’s
features to write code in a business rule and then link it into a stored
procedure or trigger.