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

Dimensional Design Patterns for People and Organizations, Products and Services
195
Figure 6-25
HR timelines
Product and Service Dimensions
Product dimensions have their own unique design challenges. Though not as large
or volatile as who dimensions, these what dimensions can be just as complex to
model because products can be described in so many different ways, by so many
different stakeholder groups. While stakeholders never know enough about their
customers, they know almost too much about their products and services! Product dimensions
Product hierarchies are important for BI reporting because businesses are often
closely organized around them. Yet despite their importance, they may not be well
designed from a BI perspective. Thankfully, product hierarchies are fixed-depth
rather than variable-depth, but they can still be difficult to define. Established
product hierarchies often represent the single biggest conformance issue for agile
data warehouse design, because they have become ragged and full of conflicting
definitions, through years of ad hoc growth and redefinition by many different
departments. Product hierarchies
Another challenge unique to what dimensions is the need to ask BI questions about
what is going on inside a product or service. This is rare for who dimensions—
unless you are dealing with medical data. For products, “what is going inside” may
be other products and services, in the case of product bundle sales, or components
and parts, in the case of design and manufacturing. To answer questions about
these, a data warehouse design must handle “bill-of-materials” information—and
that is another example of a variable-depth hierarchy. Product “bill-of-
are complex because
stakeholders know
too much about their
products and services
are typically the most
important hierarchies
but they can often be
ragged and difficult to
conform
materials” is another
type of variable-depth
hierarchy that the
data warehouse may
need to support