Database Reference
In-Depth Information
and queries
recipe for defining
FullName
. Ignore any related tables the wiz-
ard might detect; they're irrelevant for this example.
3. Choose
Employee Key
,
Parent Employee Key
,
Title
,
Hire Date
,
and
Department Name
as regular attributes.
4. Name the dimension as
Employee
. The wizard automatically detects self-
reference and creates a parent-child hierarchy.
5. Once the dimension is created, rename the
Parent Employee Key
at-
tribute to
Employees
, set the attribute
Type
property to
Person
, and the
Usage
property to
Parent
. The
Type
property assigns commonly used at-
tribute types, such as
person
,
account
,
currency
,
date
, and so on to the
attribute. Also rename the
Employee Key
attribute to
Employee
.
6. Set the
NamingTemplate
property to
Employee Level *;
. This property
assigns the name to each level in a parent-child hierarchy. Since we cannot
reasonably predict the number of levels (and we don't know the job titles at
each level), we'll simply call each level Employee Level N, where
N
is the in-
teger starting at Employee Level 02 (the top level is All).
7. Set the
MembersWithData
property to
NonLeafDataHidden
.
8. Save and process the dimension.
How it works...
If you have created a parent-child dimension as shown in the preceding section, the
dimension browser will show the employees arranged in accordance to the organiz-
ational chart. Had we left the naming template property at its default (blank) value,
the levels would simply be called level 02, level 03, and so on. Checking the
Hier-
archy
dropdown confirms that the
Employee
dimension includes other, non-parent-
child hierarchies as well: hire date, department name, and title. Refer to the following
screenshot:
Search WWH ::
Custom Search