In contrast, the Fact Model is a visual
representation of a structured business
vocabulary. Fact Models document what's
happening in the business by using standard
and universally accepted business words and
statements. The Fact Model is simpler than a
conceptual model; the sentences that express
the facts don't place constraints on instances
of these facts. Realistically, conceptual
models are built on constraints—one-to-one (1:1), one-to-many (1:M), and many-to-many (M:N) relationships. Remember,
adding a constraint to a fact converts the
fact into a rule, so library patron borrows books is a fact and a library patron may borrow a
maximum of 6 books at one time is a rule. The
Fact Model has no concept of limitation by
storage structure; there's no implication that
the Fact Model will be converted into anything other than what it is. Creators of Fact
Models don't have to be IT people; business
users can draw Fact Models without regard
to whether they're correctly representing
some facet of IT.
Benefits of a Fact Model
So what are the benefits of adopting this
Fact Model methodology? Let's take a look
at the factors that contribute to a successful
blend of IT and business-user benefits.
Business rules are controlled by business
users. By exposing business facts to the
universe of business users, users can better
manage the business rules and business policies. Because users are the business owners,
they should be able to set policy.
Rules become a shared resource. No more
"hiding" rules and no more guessing what to
do in a given circumstance. Because the rules
and facts are now a shared resource, anyone in
the company can easily read the content and
determine the intent of a specific rule.
Application development is faster. This is a
terrific benefit for both IT and non-IT business units. When facts and rules are published,
developers can quickly, concisely write code
and build systems that mirror the intent and
purpose of the facts and rules. Testing and
production groups have ready access to the
data from which they can build metrics for
measuring success. The entire company runs
more smoothly, unencumbered by a lack of
knowledge of the rules.
I can quickly convert a Fact Model into
a conceptual model. At last, here's the real
reason why I love Fact Models. In my job as
a consultant, I usually have to plow through
stacks of written documentation and use-case descriptions, study mock-ups of input screens and output reports, and infer from
all this written stuff what's important to the
business and what's not—and my customers
expect me to be able to do this in no time
at all. With an accurate Fact Model, I can
quickly get my head around the most
important components of a company and
the critical processes that will make or break
it. Then, depending on my design assignment, I can usually convert a Fact Model (or
part of it) to a first-draft conceptual model
in less time and with greater accuracy
than conventional methods. Lower cost to
delivery, less time to production, a greater
understanding of the critical elements of the
business—what's not to like?
Anyone who believes that business analysis and modeling methodologies are static
is very much mistaken. New techniques let
us better define how a business works and
use that understanding to create databases
and applications. Business users can participate in developing systems that will make
the business run better. Developers can use
the output from these techniques to build
quicker, better applications. Customers
get the benefit of a business that knows
what they need and how to get it to them.
Sounds like a win-win-win to me!
You can post your thoughts about Fact
Models and their potential, on the SQL
Server Magazine Database Design forum at http://www.sqlmag.com/go/dbdesign
End of Article
Prev. page
1
[2]
next page -->
