A dimension hierarchy is a logical structure that organizes your Endeca records.
The dimension values in a dimension are related to each other as parent and child dimension values.
A dimension value that has sub-dimension values is the parent of those sub-dimension values. The sub-dimension values are children or child dimension values of their parent. Child dimension values that have the same parent are dimension value siblings.
The following figure illustrates a typical dimension:
Child dimension values enable users to refine their navigation queries and, consequently, the resulting record sets. Thus, when you configure dimensions, make sure that child dimension values contain more specialized data than their parents. See Refining a navigation query in a hierarchical dimension for more information about query refinements.
Dimensions that have only one level of hierarchy beneath the dimension root are called flat dimensions. The following figure illustrates a flat version of the Wine Type dimension.
Automatically generated dimensions are flat unless you configure their dimension values to be of type Sift. The Sift type is an extension of automatic dimension generation that makes it possible to place automatically generated dimension values (of type Sift) in an existing hierarchical dimension. For information about how to create and use dimensions with Sift dimension values, refer to the Oracle Commerce Developer Studio Help.
Related links
A dimension value can have only one parent dimension value but any number of child dimension values.
In the example on the left below, Red is the child of the Wine Type dimension value and the parent of the Merlot and Chianti dimension values. The example on the right is incorrect, because Red is specified as the child of both the Wine Type and Flavor dimension values. An Endeca dimension value can have only one parent.
The ancestors of a given dimension value are all the dimension values between the given dimension value and the dimension root. The parent of the given dimension value is also one of its ancestors.
In the example below, Other and Fortified represent the ancestors for the Sherry dimension value.
The MDEX Engine returns not only the records tagged with the dimension value to which you navigated, but also those records that are tagged with any of that dimension value’s children.
In the following example, a navigation query on Red would produce a result set of four bottles, Bottles A through D.
If you refine the query by navigating to one of Red’s children (Merlot, for example), the result set is reduced in size and now contains only Bottles A and B.
Navigating from a dimension value to one of its children refines the navigation query and typically reduces the size of the result set. Conversely, navigating from a dimension value to the value’s parent typically broadens the query and increases the size of the result set. The information required to create these refining and broadening queries makes up the bulk of the follow-on query information contained in the MDEX Engine’s query results.
Note
Child dimension values are often referred to as refinement values or refinements.
Because navigation queries can cross multiple dimensions, the MDEX Engine’s query results contain follow-on information for every dimension. This means that you can refine or broaden your query in one or more dimensions while making no change to the query parameters in the other dimensions.
You can design dimension hierarchies in ways that reduce the number of follow-on queries that are presented to users as they navigate.
For example, in the flat dimension below, a navigation query on the Wine Type dimension value would return six possible refinement queries, one for each child.
A simple flat dimension such as the one shown in the preceding figure is small enough to navigate through quickly. Larger flat dimensions, however, present too many choices for follow-on queries to be easily navigable.
Organizing data as dimensions reduces this information overload and provides for an easier, more intuitive navigation experience. In the hierarchical example below, the Wine Type dimension value has only three possible refinement queries: Red, White, or Sparkling.
A second reason to use dimension hierarchy is that, by limiting the number of refinement queries, you decrease the amount of time it takes for the MDEX Engine to return its results. Returning query results that contain follow-on information for 20 refinement queries is faster than returning query results that contain information for 2000 refinement queries.
Note
The time that the MDEX Engine takes to process a large flat dimension can be lessened by requesting that the MDEX Engine return only the most important refinements.
Creating easy to understand dimension hierarchies makes it easier for your end users to navigate through your data.
This section provides information about how to make dimensions as easy-to-understand and navigate through as possible.
Making a theme increasingly specialized
All the dimension values in a dimension should be part of the same theme.
Because navigating on a dimension value implicitly navigates all of the dimension value’s children, a child dimension value that does not have the same theme as its parent can produce a result set that contains Endeca records with multiple unrelated themes.
Child dimension values should be specializations of their parent's theme. Child values that are not more specialized than their parents can create nonsensical navigation paths. In the incorrect example above, it makes good sense to refine the Wine Type dimension value by navigating to the Red dimension value. Refining the Red dimension value by navigating to the Italy dimension value, however, does not make sense, because "Italy" is not a type of red wine.
While it is technically possible to tag your Endeca records with any dimension value that exists in a dimension, it is highly recommended that you tag your Endeca records only with leaf dimension values. The following figure illustrates leaf dimension values in a simple dimension.
Tagging your Endeca records with leaf dimension values creates a more easily understood navigation experience, because the sum of the records in the leaf dimension values equals the number of records returned for the parent dimension value.
The following figure illustrates the difference between tagging all records with leaf dimension values and tagging some records with dimension values that are not leaves:
As the preceding figure shows, tagging all records with either of the two leaf values Merlot or Chianti produces the same result set for the query on "Red" and the query on "Merlot + Chianti". However, tagging two of the records (Bottle E and Bottle F) with a non-leaf dimension value ("Red") produces different result sets for the query on "Red" and the query on "Merlot + Chianti".