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

196
Chapter 6
Who and What
Describing Heterogeneous Products
Heterogeneous
products and
services can have
too many specialist
dimensional
attributes to fit
comfortably into a
single product
dimension
Large sets of
specialist attributes
should be grouped
together in their own
swappable subset
dimensions, based
on a defining
characteristic such
as product type
Product dimensions can become very complex when an organization like
Pomegranate deals with very different types of products—such as hardware,
software, third party accessories, consulting services, licenses and support
subscriptions—that all need to be described in very different ways. These
heterogeneous descriptions can lead to wide sets of dimensional attributes that are
only valid for certain product types. This is the same mixed business problem as
dealing with multiple customer types but greatly compounded by the fact that
organizations usually know a lot more about their products than their customers
and have many more specialist ways of describing them. Even though product
dimensions rarely approach the row count of customer dimensions, the row length
of product dimensions, that attempt to describe every radically different product
type can cause just as many performance, usability and manageability problems.
With large sets of specialist attributes for heterogeneous products and services, BI
users will have to scroll through pages of attributes to find the ones that interest
them and will be daunted when trying to find correlated attributes. You may even
exceed the maximum number of columns in a single table supported by your
DBMS.
For both query performance and usability, you may want to break a monolithic
product dimension into several swappable subset dimensions (SD), as in Figure 6-
4, based on defining characteristics (DC) such as product type or subcategory.
Each swappable dimension would contain exclusive (X) attribute groups that
require specialist knowledge to use or interpret correctly. For example, a retailer
may have more than 300 attributes that describe clothing products—in minutia.
These would be fascinating to clothing buyers but of little interest to finance or
logistics. If query performance is not an issue, swappable subsets can be delivered
as views, otherwise materialized views or separate tables may be needed to over-
come poor performance or column number limitations.
Balancing Ragged Product Hierarchies
Product hierarchies
can sometimes look
like variable-depth
hierarchies but they
are in most cases
ragged hierarchies
Product hierarchies can sometimes appear to be of variable-depth, especially when
source data is held in recursive structures within an Enterprise Resource Planning
(ERP) package, or when every department seems to have a different number of
levels on the product hierarchy charts pinned to their walls. However, what is most
often thought of as “the product hierarchy” is not a true variable-depth hierarchy—
a hierarchy of products within products—but actually a ragged hierarchy of prod-
ucts within groups that are based on the physical, organizational, or geographic
properties of products. Many of the attributes used to assign products to these
groups are not mandatory, or are exclusive to certain subsets, leading to raggedness
when you try to create a single conformed hierarchy of all products, across all
business processes and departments.