Modeling the

Rules of the
Organization
Instructor: Iqra Saher
 Business Rules
Business rules, the foundation of data models, are derived from policies, procedures, events,
functions, and other business objects, and they state constraints on the organization. Business
rules represent the language and fundamental structure of an organization (Hay, 2003).
Business rules are important in data modeling because they govern how data are handled and
stored.
Examples of basic business rules are data names and definitions.
• In terms of conceptual data modeling, names and definitions must be provided for the
main data objects: entity types (e.g., Customer),attributes (Customer Name) and relationships
(Customer Places Orders)
• Other business rules may state constraints on these data objects. These constraints can be
captured in a data model, such as an entity-relationship diagram, and associated
documentation.
• Additional business rules govern the people, places, events, processes, networks, and
objectives of the organization, which are all linked to the data requirements through other
system documentation.
• Data modeling facilitates interaction/communication between designer,
application programmer, and end user, thus reducing misunderstandings and improving
the thoroughness of resultant systems; this is accomplished, in part, by providing a
simplified (visual) understanding of data (data model) with agreed upon supporting
documentation (metadata).
• Data modeling can foster understanding of the organization (rules) for
which the data model is being developed; consistency and completeness of rules can be
verified; otherwise, it is possible to create systems that are incorrect or inconsistent and
unable to accommodate changes in user requirements (such as processing certain
transactions or producing specific reports).
• The value of data modeling can be demonstrated as an overall savings in
maintenance or development costs by determining the right requirements before the
more costly steps of software development and hardware acquisition; further, data
models can be reused in whole or in part on multiple projects, which can result in
significant savings to any organization by reducing the costs for building redundant
systems or complex interfaces between systems.
• Data modeling results in improved data quality because of consistent business data
definitions (metadata), and hence greater accuracy of reporting and consistency
across systems, and less organizational confusion; data modeling across the
organization results in everyone having the same understanding of the same data.
• Data modeling reduces the significant costs of moving and translating
data from one system to another; decisions can be made about the efficacy of sharing
 Modeling the Rules of the
Organization
Business rules and policies govern creating, updating, and removing data in an
information processing and storage system; thus, they must be described along with
the data to which they are related.
For example, the policy “every student in the university must have a faculty adviser”
forces data (in a database) about each student to be associated with data about some
student adviser.
Also, the statement “a student is any person who has applied for admission or taken a
course or training program from any credit or non-credit unit of the university” not
only defines the concept of “student” for a particular university but also states
a policy of that university (e.g.,alumni are students, and a high school student who
attended a college fair but has not applied is not a student, assuming the college fair
is not a non-credit training program).
Business rules and policies are not universal; for example, different universities
may have different policies for student advising and may include different types of
people as students. Also, the rules and policies of an organization may change
(usually slowly) over time; a university may decide that a student does not have to be
assigned a faculty adviser until the student chooses a major.
Your job as a database analyst is to
 The Business Rules Paradigm
The concept of business rules has been used in information systems for some time.
There are many software products that help organizations manage their business
rules (for example, JRules from ILOG, an IBM company). In the database world, it
has been more common to use the related term integrity constraint when referring
to such rules. The intent of this term is somewhat more limited in scope, usually
referring to maintaining valid data values and relationships in the database.
A business rules approach is based on the following premises:
• Business rules are a core concept in an enterprise because they are an
expression of business policy and guide individual. Well-structured business
rules can be stated in natural language for end users and in a data model for
systems developers.
• Business rules can be expressed in terms that are familiar to end users.
Thus, users can define and then maintain their own rules.
• Business rules are highly maintainable. They are stored in a central
repository, and each rule is expressed only once, then shared throughout the
organization. Each rule is discovered and documented only once, to be applied in
all systems development projects.
Enforcement of business rules can be automated through the use of software that
can interpret the rules and enforce them using the integrity mechanisms of the
 Scope of Business Rules
Most organizations have a broad set of rules and/or policies that fall outside
this definition. For example, the rule “Friday is business casual dress day”
may be an important policy statement, but it has no immediate impact on
databases.
In contrast, the rule “A student may register for a section of a course only if
he or she has successfully completed the prerequisites for that course” is
within our scope because it constrains the transactions that may be
processed against the database.In particular, it causes any transaction that
attempts to register a student who does not have the necessary prerequisites
to be rejected.
Some business rules cannot be represented in common data modeling
notation; those rules that cannot be represented in a variation of an entity-
relationship diagram are stated in natural language, and some can be
represented in the relational data model.
 Gathering Business Rules
• Business rules appear in descriptions of business functions, events,
policies, units, stakeholders, and other objects. These descriptions can
be found in interview notes from individual and group information
systems requirements collection sessions, organizational documents
(e.g., personnel manuals, policies, contracts, marketing brochures, and
technical instructions), and other sources.
• Rules are identified by asking questions about the who, what, when,
where, why, and how of the organization. Usually, a data analyst has to
be persistent in clarifying initial statements of rules because initial
statements may be vague or imprecise (what some people have called
“business ramblings”). Thus, precise rules are formulated from an
iterative inquiry process. You should be prepared to ask such questions
as “Is this always true?” “Are there special circumstances when an
alternative occurs?” “Are there distinct kinds of that person?” “Is there
 Data Names and Definitions
Fundamental to understanding and modeling data are
naming and defining data objects. Data objects must be
named and defined before they can be used unambiguously
in a model of organizational data
• Data Names
• Data Definition
• Good Data Definition
 Data Name
Salin (1990) suggests that you develop data names by
1. Preparing a definition of the data. (We talk about definitions next.)
2. Removing insignificant or illegal words (words not on the approved list for
names); note that the presence of AND and OR in the definition may imply
that two or more data objects are combined, and you may want to separate
the objects and assign different names.
3. Arranging the words in a meaningful, repeatable way.
4. Assigning a standard abbreviation for each word.
5. Determining whether the name already exists, and if so, adding other
qualifiers that make the name unique.
 Data Names
here are some general guidelines about naming any data object. Data names should (Salin,
1990; ISO/IEC, 2005)
• Relate to business, not technical (hardware or software), characteristics;
so, Customer is a good name, but File10, Bit7, and Payroll Report Sort Key are not good
names.
• Be meaningful, almost to the point of being self-documenting (i.e., the definition
will refine and explain the name without having to state the essence of the object’s
meaning); you should avoid using generic words such as has, is, person, or it.
• Be unique from the name used for every other distinct data object; words should
be included in a data name if they distinguish the data object from other similar data
objects (e.g., Home Address versus Campus Address).
• Be readable, so that the name is structured as the concept would most naturally
be said (e.g., Grade Point Average is a good name, whereas Average Grade Relative To A,
although possibly accurate, is an awkward name).
• Be composed of words taken from an approved list; each organization often
chooses a vocabulary from which significant words in data names must be chosen (e.g.,
maximum is preferred, never upper limit, ceiling, or highest); alternative, or alias names,
also can be used as can approved abbreviations (e.g., CUST for CUSTOMER), and you may
be encouraged to use the abbreviations so that data names are short enough to meet
maximum length limits of database technology.
• Be repeatable, meaning that different people or the same person at different
 Data Definitions
• A definition is an explanation of a term or a fact. A definition (sometimes called a
structural assertion) is considered a type of business rule (GUIDE Business Rules
Project, 1997). A "structural assertion" defines and organizes the relationships
between terms or facts within a system or business. It essentially provides
structure by asserting how different concepts are related. Structural assertions typically
involve definitions or relationships between entities, ensuring that these terms are
consistently understood and used within a business.
• A term is a word or phrase that has a specific meaning for the business. Examples of
terms are course, section, rental car, flight, reservation, and passenger. Terms are often
the key words used to form data names. Terms must be defined carefully and concisely.
However, there is no need to define common terms such as day, month, person, or
television, because these terms are understood without ambiguity by most persons.
• A fact is an association between two or more terms. A fact is documented as a simple
declarative statement that relates terms. Examples of facts that are definitions are the
following (the defined terms are underlined):
• “A course is a module of instruction in a particular subject area.” This definition
 Good Business Rules
• A definition will use commonly understood terms and abbreviations and stand alone in
its meaning and not embed other definitions within it. It should be concise and
concentrate on the essential meaning of the data, but it may also state such
characteristics of a data object as
• Subtleties
• Special or exceptional conditions
• Examples
• Where, when, and how the data are created or calculated in the organization
• Whether the data are static or change over time
• Whether the data are singular or plural in their atomic form
• Who determines the value for the data
• Who owns the data (i.e., who controls the definition and usage)
• Whether the data are optional or whether empty (what we will call null) values
are allowed
• Whether the data can be broken down into more atomic parts or are often
combined with other data into some more composite or aggregate form