My first Publication Agile-Data-Warehouse-Design-eBook | Page 142

Modeling Business Processes
121
translate into physical tables. But this rush to physically model events is counter-
productive. Business keys are mostly cryptic codes that will rob event tables and
stories of their readability and descriptive power, and—as you will see in Chapter
5—business keys do not make the best foreign keys (or primary keys) in a dimen-
sional data warehouse.
Using Abbreviations in Event Stories
Instead of business keys, use abbreviated examples: abbreviations or shortening of
previously modeled examples, as in Figure 4-19 which shows shipment stories with
abbreviated employee and product examples. The advantage of abbreviations over
business keys is that they keep event stories readable while saving whiteboard space
and speeding up story telling. You can also expand them to full examples later in
your documented model relatively easily with a “replace all”.
Use abbreviated
examples to keep
stories brief and
readable
Figure 4-19
Using
abbreviations to
tell event stories
To avoid confusing abbreviated stories, keep abbreviations unique within dimen-
sions. If an abbreviation is not unique, just add a sequence number to it. For
example, if your two favorite employees are James Bond and Jed Bartlet, they can
appear in stories as JB1 and JB2. Of course employee James Bond is exceptional; his
business key, employee ID 007, is so well known that it is more descriptive than his
initials, and could be used very successfully in many eventful stories.
Provide stakeholders with handouts of previously modeled BEAM✲ dimension
tables and an ‘up to date’ event matrix to help them reuse conformed examples
and decode abbreviations. the dimension tables need not show every attribute;
just the example dimension subjects (which get abbreviated) and one or two
defining characteristics that identify role subtypes, such as warehouse employees
and sales employees.
Keep abbreviations
unique by adding a
sequence number if
necessary