EXTENDING SSAS CUBES

1. )Define attribute hierarchies and attribute relationship to optimize cube design and facilitate data analytics.
2.) Enrich the reporting experience by building a end user layer consisting of KPI’s, action, translations and perspectives.
3.) Use MDX language expressions to define important business metrics not available in fact tables and require custom expressions.

A.) Defining user hierarchies and dimension relationships:
Attribute Relationship:
Notes:
1.)If a dimension is based on Star Schema its source is a single dimension table. Snowflake schemas have multiple dimension tables.
2.)Unlike relational database which is a 2 dimensional structure of rows and columns, a UDM is a multi-dimensional which supports data hierarchies eg Year, Quarter and month levels and the relationships that exists between these attributes.
All dimension attributes are directly or indirectly related to the dimension key attribute with 1:1 or M:1 logical relationships.
By default the UDM is not aware of the logical relationships among attributes. It defies M:1 relationship with all attributes and the dimension key, except with snowflake dimension where it automatically creates separate M:1 relationships among attributes from different tables in the attribute relationship tab in the dimensions.
One must spend time to understand and appropriately define attribute relationships.
3.)Setting up attribute relationships provide the following benefits:
-- Server can optimize the storage of the attribute hierarchies
--SSAS can effectively retrieve and aggregate data.
If there is no attribute relationship the query that groups data by product category will scan the fact data on the fly to summaries the individual products but if the attributes are related the server could optimize the query and use the subcategory subtotals.

Attribute Relationship Properties:
1.) Attribute- Specifies the related attribute name
2.) Cardinality- Cardinality of relationship definition
3.) Name- Relationship name specification
4.) RelationshipType –Flexible (slowly changing dimension) or rigid (does not change with time)
5.) Visible- If False the corresponding member property will not show to the end user.

Creating a New attribute Relationship or creating a new Dimension hierarchy:
1.) Attribute Relationship: Right click the source attribute in the attributes pane (in the Attribute relationship tab for a particular dimension) that is on the one side of the relationship. Make sure the source attribute shows the attribute on the many side and the Related Attribute is the attribute on the one side of the relationship.(Territory CountryTerritory Group). Else drag and drop the many side attribute to the one side attribute in the Attribute relationship pane.
2.) Dimension Hierarchy: Right click the attribute you want to be at the top level and say ‘Start New Hierarchy. Else drag and drop the top level attribute to the Hierarchy tab in the dimension structure.
Important
Note:
1.)Although you can set up the user defined hierarchies without defining the attribute relationships, this should be avoided because it reflect poor design.
2.)Consider hiding attributes that are used in user hierarchies by setting their AttributeHierarchyVisible property to False to prevent redundancy in user exp.

Associating Dimension to User Group:
When a dimension is added the cube designer determines which measure group the dimension is related to by using the table relationship metadata within the DSV on which the cube is based.
The dimension usage tab within the cube designer defines the various relationships that should exists between each measure and dimension within the cube.

Relationship Types:
1.) Regular Dimension- is joined directly to the fact table through a granularity attribute
2.) Fact- When the dimension is based on the fact table used to define the measure group
Eg To see all sales order line items for a given Sales Order, you need to build dimensions directly from the fact table and then join them to the related measure group through a fact relationship.
3.) Referenced- Given dimension is related to fact table through an intermediate dimension.
4.) Many-to-Many- Dimension is related to a given measure group through a intermediate measure group
5.) Data Mining- Defines the relationship between a dimension based on a data mining model and a given measure group.

B.) Creating KPIS's, Actions, Translations and Perspectives:
B1.) KPI:
Organisations use KPI's to gauge their business performance. Eg Sales Profit, Revenue Growth, and growth in Customer base. It shows the health of a company.
SSAS is suitable for KPIs because
1.) Automatic calculation of KPIs- The server automatically calculates the KPI properties as the user slices the cube data. eg a user can drill down to time dimension and cube could calculate the KPI across the hierarchy of year, quarters and month levels.
2.) Time effective-Since the dashboards include different chart and report views that show historical trends, the server is pinged with many queries including large data sets and the page is rendered within seconds.

Expression Based Properties of KPI:
1.)Value
Current Value of the KPI
2.)Goal
What the KPI value should be in a perfect world
Following exp sets it to 40% more than Reseller sales Amount from the previous date period.
1.40*([Date].[Calendar].PrevMember ,[Measures].[Reseller Sales Amount])
The PrevMember function returns the previous member in the hierarchy eg if the level is yr it returns the previous year.
3.)Status-
Indicates how the KPI value is as compared to Goal.

1-Good performance-->
When KPIValue(Reseller Sales")/KPIGoal("Reseller Sales)>=1

0-Acceptable Performance-->
When KPIValue(Reseller Sales")/KPIGoal("Reseller Sales)<1 and When KPIValue(Reseller Sales")/KPIGoal("Reseller Sales)>=.85

-1-Under performance-->
Else the above statements

SSAS provides several standard KPI related functions:
--KPIValue(to retrieve KPI values)
--KPIGoal(to retrieve KPI Goal)
--KPIStatus(to retrieve KPI Status)
--KPITrend(to retrieve KPI Trend)

4.)Trend-
How the KPI is doing over time. Returns -1 to 1. It is equal to the following expression.
(
[Measures].[Reseller Sales Amount]-([Date].[Calender].PrevMember,[Measures].[Reseller Sales Amount])
) /
[Measures].[Reseller Sales Amount]

Additional KPI Properties:
Associated Measure Group
Display folder
Parent KPI- Used to indicate the parent KPI of the current KPI. Useful if the set of KPIs are shown together as they might be in a scorecard.
Current Time Member
Weight
Status Indicator and Trend Indicator- used to indicate the images the client should use to display the values graphically.

Note:
You can use KPI aware client applications such as Excel and SSRS to display KPIs on the report.You can also write MDX statements to directly query the KPI properties by using KPIValue(), KPIGoal(), KPIStatus() and KPITrend()
Eg below statement retries the properties of the Reseller Sales KPI that ave been implemented in the cube sliced by the Product Category by the year 2003....

SELECT { KPIValue('Reseller Sales"),
KPIGoal('Reseller Sales"),
KPIStatus('Reseller Sales"),
KPITrend('Reseller Sales") } ON COLUMNS,
[Dim Product].[Product Category].Members ON ROW
FROM [Adventure Works]
WHERE [Date].[Calender].[Calendar Year].&[2003]

B2.) Implementing Actions:
Actions provide another mechanism by which the users can gather information and take next steps based on the information they find in cubes
Actions can extend the cube in a versatile way eg if a user has drilled down to the lowest level of a dimension eg product dimension and wants to see the individual sales and orders placed for that product. If this info is not stored in a cube one can implement a reporting action that lets the user use a reporting action that displays a report with the required data.

Note:
Actions are defined in a cube but interpreted and initiated in a client app. Not all clients support actions. eg excel 2007 supports actions but SSRS does not. An action relates to an object(eg dimension table particular cell) in the cube.

Action Types:
Define action types to integrate the cube with client applications. They inform the client applications how to interpret the action.
1.)Regular Action Type
--Dataset-action content is a MDX statement
--Proprietary- action is client specific. Client is responsible for interpreting the semantic meaning of action.
--Rowset-Action content is a command statement. Unlike dataset, a rowset action targets any OLE-DB compliant data source, including relational db
--Statement-Content type is an OLE-DB command. The statement should not yeild any result except success or failure
--URL(default)- action content is a URL
a.)Used to construct a URL that displays a reporting server report
b.)Used to build a URL that references a specific page on the corporate website related to the product.
2.)Drillthrough Actions:
Lets the client request details behind aggregated cell values
3.)Reporting Actions- Can be used to request SSRS reports.

Properties:
1.)Name
2.)Target-
1.) target type(attribute member)- If you set cube the action will relate to the entire cube and do not need to provide more details about the cube. In the client the action is available for all cube objects every member , every cell, every dimension and every level.
Limit the action by selecting Dimension members. The action in this case is available for all members of the dimension specified in the target object.
Select Hierarchy or level to limit the availability of the action to the members of the specific hierarchy.
Another option is to select cell as the target type. when a user clicks a cell in a client application the action passes the value of teh cell as the parameter.
2.)target object(attribute hierarchy) if want to target a attribute hierarchy
3.)Condition

Note:
For configuring a drilldown action, one needs a list of drillthrough columns that the end user will see when the action is executed.

B3.) Localisation of Cube through Translations:
Translations support International Users.
To translate the cube metadata including captions of cubes, cube dimensions, measure group, measures, KPI, actions, named sets browse to the translation tab in the cube designer.

B4.) Implementing Cube Perspective:
Represents a subset of the cube.
Main purpose is to reduce the perceived complexity of the large cube by exposing only a subset of the cube objects.
eg if the members of a project are interested in browsing just the reseller sales, a perspective can be created that includes only the reseller sales measure group and the associated dimensions.
By default the cube has a single perspective that exposes the entire cube content.
Perspectives cannot be used to enforce restricted access to portions of the cube(security mechanism).

C.)Creating Calculations and Queries by using MDX
MDX gives the programming power to implement custom solutions.

MDX Syntax:
MDX used in 2 main ways:
1.)To query
2.)To extend multidimensional cubes- eg implement business metrics eg KPI's

Tuples:
Multidimensional coordinate that identifies a single cell in the cube space.
eg [Product].[Product].[Road Bike],[Date].[Year].2005,[Measures].[Internet Sales] references a cell found at the intersection of product Road Bike, year 2004 and measures Internet Sales.
Sets:
Collection of tuples with same dimensionality or attribute hierarchies. represented by {}
eg
1.){[Sales Territories].[Countries].[All Countries],[Date].[Year].[2004],[Product].[Product].[Mountain-100]}
2.){[Sales Territories].[Countries].[All Countries],[Date].[Year].[2004],[Product].[Product].[Road-200]}

Notes:
1.) The cube measures are treated as members of a special Measures dimension.
2.) When a dimension member in a tuple is referenced, you can use a member name eg [Product].[Product].[Mountain-100]. This syntax works only if there is a single product with that name.
You can resolve the member uniquely by using its key and prefix the key by & eg [product].[Product].&[10] will resolve the member uniquely even if there are more than 1 same name members.
3.) Cube space consists of many hierarchies, enumerating them is tedious so if the attribute hierarchy is missed it references to the default hierarchy...Usually the
"All Member" hierarchy.
4.) Can use the CurrentMember for most dimensions, but you do not need to explicitly reference in the tuple By default the Current Memeber of each attribute hierarchy is implicitly referenced in a tuple.
5.) Difference between 'Members' and 'All'-
Eg [Product].[Category].[All] Dragging the All Member of any hierarchy gives all the members present in that hierarchy. eg it returns just 1 row with All data.
Eg Product.Category.Members Members lists the the members from the category attribute hierarchy of the Product Dimension



Basic MDX query:
SELECT [Measures].[Internet Sales Amount] on COLUMNS
[Product].[Category]. ON ROWS
FROM [Adventure Works]
WHERE [Date].[Calendar Year].&[2003]

Notes:
1.) A query can have upto 128 axes(numbered 0 to 127)
First 5 are named COLUMNS, ROWS, PAGES, SECTIONS and CHAPTERS.
2.) Cannot skip axes

*Members-returns all members of the hierarchy

MDX Functions for Navigating Hierarchies:
1.)CurrentMember-eg [Order Date].[Calander].CurrentMember, [Measures].[Reseller Sales Amount] tuple returns the reseller Sales Amount for the member of the calendar hierarchy that references the current cell.
2.)PrevMember-eg [Order Date].[Calander].PrevMember returns the previous member with respect to the current member in the calendar hierarchy
Imp: Used to define KPI Trend and KPI Goals.
eg KPI Goal= 1.40([Date].[Calendar].PrevMember,[Measures].[Reseller Sales Amount])
3.)Children-eg [Order Date].[Calander].[2003].Children returns all quarters of the year 2003 assuming that the level below the calender year in the calender hierarchy is the quarters.
4.)Parent- Returns the member's parent in a given hierarchy
eg [Product].[Category].[Product].[Road Bike].Parents returns th Bike members of the Product Category Hierarchy.
5.)Member-Returns all the members of the hierarchy eg [Product].[Product].[Product]. Members return all the products of the product dimension and product Hierarchy excluding the All member.

Functions for Navigating Time: These functions help navigate time dimension.
1.) Lag
eg [Order Date].[Calendar].Lag(1) returns the previous sibling of the current year.
So if the current member is quarter level the Lag(1) will give the previous quarter
2.) Parallel Period- Returns the member from the prior period in the same relative position as the specified member with an optional offset.
If no member is specified then 0 is assumed.
eg 1 with 0 offset
Parallel Period([Date].[Calendar].[Calendar Quarter], [Date].[Calendar].[Month Name].[October 2003]) returns October 2002.

Syntax:
ParallelPeriod( [ Level_Expression [ ,Index [ , Member_Expression ] ] ] )

eg 2 with offset:
SELECT ParallelPeriod ([Date].[Calendar].[Calendar Quarter]
, 3
, [Date].[Calendar].[Month].[October 2003])
ON 0
FROM [Adventure Works]
returns the parallel period for the month of October 2003 with a lag of three periods, based on the quarter level, which returns the month of January, 2003
3.) PeriodsToDate- returns a set of sibling members from the same level as the given member starting with the first sibling ending with the given member.

Syntax:PeriodsToDate( [ Level_Expression [ ,Member_Expression ] ] )
Arguments:
Level_Expression
A valid Multidimensional Expressions (MDX) expression that returns a level.
Member_Expression
A valid Multidimensional Expressions (MDX) expression that returns a member.

eg following query returns internet sales for the 1st 10 months of 2003
Select [Measures].[Internet Sales Amount] on 0,
PeriodsToDate([Date].[Calendar].[Calendar Year],
[Date].[Calendar].[Month Name].&[10].&[2003]) on 1
from [Adventure Works]

Creating a Calculated Member:
It is a dimension member whose value is calculated at the run time. Imp:The cube members are considered as members of the special Measures dimension.
The definitions of the Cube Calculated members and the named sets become part of the cube MDX Script which can be accessed from the calculation tab.

Calculated Member Syntax:
CREATE MEMBER CURRENTCUBE.[measures].[Sales Amount]
AS [measures].[Internet Sales Amount]+[measures].[Reseller Sales Amount],
FORMAT_String="Currency",
VISIBLE=1;

Calculated Members:
A query can request calculated columns using WITH clause before SELECT
eg

With Member [Gross Profit] AS
'[Measures].[Internet Sales Amount]+[Measures].[Reseller Sales Amount]'
SELECT {[Measures].[Internet Sales Amount],[Gross Profit]} ON COLUMNS,
[Product].[Category].members on Rows
FROM [Adventure Works]
WHERE [Date].[Calender year].&[2003]

When to use Calculated Members:
1.)If a Measure is needed that does not belong to a particular measure group.
2.)when you need a non additive measure that operates uniformly across dimension levels.
eg a calculated member that calculates avg reseller profit amount (Reseller Sales Amount/Reseller Sales Count) returns the expected results no matter how the user slices the data.

Note:
Calculated Member does not increase the cube size since the server stores only its definition, not the data.

Defining Named Sets:
The following MDX construct returns a set of dimension members. eg the below MDX returns top 50 customers:
CREATE SET CURRENTCUBE.[Top 50 Most Profitable Customers]
AS
TopCount(
(Existing [Customer].[Customer].[Customer].Members), 50, [Measures].[Internet Sales Amount]);

Note:
The member function returns all members of the customer attribute hierarchy in the dimension customer table. Use the triple notion syntax eg Dimension.Attribute.Attribute to exclude the All member of the hierarchy.
2.)Provides 2 types of named sets
Static: Evaluated once by the server
Dynamic:Evaluated for each query
By default BIDs creates Dynamic sets.

DEVELOPING SSAS CUBES

Dimensional Modeling is the methodology to architect schemas required for reporting by reducing the number of tables and deformalizing the data. There are facts(containing the measure) and dimension(subject areas on which the data is sliced) tables in the schema.
For a BI solution the OLAP methodology is used which extracts the data in the underlying transactional database and loaded into a data mart. Data Mart is designed using the dimensional modeling. On top of data mart a UDM layer is built which has advantages of exceptional performance for large data volumes.
SSAS understands semantics of data so helps extend the cube with important business calculations in form of MDX (multi dimensional expressions). Eg KPIs that measure company performance. Lot of 3rd part tools support SSAS and MDX query language and dashboards can be developed using SharePoint or other tools.

UDM consists of the below components:
1.) Data Source
2.) Data Source View- helps us visualize the database schema and augment it using calculated columns and calculated queries
3.) Dimensional Model
4.) Calculations (optional)- augment the cube using custom logic of MDX such as QTD, YTD etc
5.) End User Model (optional)- Additional features that can be built to give richer scemantics including KPI’s, actions, perspectives and translations.
6.) Management Settings-Admin configures the cube to meet various operational requirements including availability, latency and security.

Defining a Data Source:
Note:
1.)Choose native OLE DB provider because SSAS is implemented in native code.
2.)Authentication option:
Standard security –less secure than windows authentication since need to manage the passwords
Windows Authentication-If the user is a system admin then all the operations will succeed.
3.)Impersonation information:
-Use a specific username n pwd
-Use service account- this is appropriate if SSAS service acctn is the domain or local account and has read access to the underlying data source.
-Use credentials of the current user- this is seldom used since it applies to certain data retrieval scenarios involving querying data mining models.
-Inherit- lets the server decide the mode. The server uses service acctn for cube processing and current user for querying data mining models.

Creating DSV:
IF the primary key and table relationship are defined in the underlying database the wizard automatically detects it . If not you need to add manually by going to the DSV designer and right click and set Logical Primary Key. For a foreign key drag the foreign key of a table to its related Primary key in another table and the relationship automatically creates.
Note: The DSV designer does not validate any logical Pk and table relationships that are manually created so if the underlying tables break any relationship one would not know until the cube is fully completed.
Defining DSV Named Calculations and Named Queries:
Named Calculations: A specific table might have columns that are derived from other columns from the same table or columns of another table.
Named Queries: Helps creating a new table
Note: As the requirements evolve it might be required to replace a table using a new table so in that case named Query can be used to write a query to replace the old table.

Creating and Modifying Cubes:
The next task is to create the dimension layer of the UDM. This includes design dimensions, cubes, measure groups and measures. The cube wizard reads metadata from the DSV and the underlying relational database to deduce the structure of the cube and its related dimensions.
Notes:
Use existing tables is the most common choice for cube creation but the option generate tables in the data source can be used to design the UDM from top to bottom in absence of data source.
A measure group in the UDM is equivalent to the fact table in dimensional modeling. It contains numeric measures that change over time.
Measures and dimensions can be renamed and removed by clearing the check box.

Cube designer tabs:
1.) Cube Structure- used to edit the cube structure
2.) Dimension usage- Defines the relationship between dimension and measures
3.) Calculations- Contains MDX formulas
4.) KPIs- Defines KPIs
5.) Actions- used to create actions eg reporting or launching URLs available to the end user while browsing the cube
6.) Partitions-storage structure is defined
7.) Aggregations- Creates custom aggregation designs
8.) Perspectives-used to create subsets of cube content for easier end user browsing
9.) Translations-defines language translations for cube metadata
10.) Browser- used to browse the cube

Measure/ Dimension Properties:
Measure pane lists the measure groups and measure defined in the cube. The property window describes the properties related to the selected object.
Name: How the measure id called in the end user tool.
FormatString: How the measure should be formatted eg currency or percentage.
Note: It is important to note that any properties you change in the cube do not affect the design of the dimension modeling outside the cube. A dimension included in the cube is an instance of dimension (called the cube dimension) that is defined within the dimension folder of the project.

Creating and Modifying Dimensions:
A dimension gives the user the abilities to isolate, drill down, roll up, categories, filter, summaries and perform other actions on data. It gives the user the ability to analyze data by subject areas.
Creating a dimension:
Notes:
1.)While creating a dimension in the dimension wizard the option Generate a time table in the source option lets you create a time dimension in the data source and then lets you populate the table with range of dates. The option Generate a time table in the server is useful when the fact table contains columns of DateTime date type and resolving these columns to a designated time table is not an option.
2.)Best practice is to use a designated time dimension table in the data source. This helps to enhance the time table with additional attributes like holiday flag etc.
3.)In the dimension wizard, in the select dimension attribute page by default each attribute forms a hierarchy called the Attribute Hierarchy and lets the user analyze data by the members of this hierarchy. Eg Color attribute contains the distinct values of the color column. This lets the user see the aggregated measure values of each member of the attribute hierarchy. Eg user can browse sales amount measure by a product color.
Furthermore you can improve the performance of browsing dimension data through user defined hierarchies by defining attribute relationships between attributes within the hierarchies.
You can clear the enable browsing checkbox to hide the attribute when a user browses a cube.
4.)SSAS supports assigning a pre defined attribute type to an attribute. Imp in time dimension because it tells the server that the attribute represents time periods (year, quarter, Month etc) when you write related calculating eg YTD, MTD , QTD.
5.)The properties are set both on the dimension object and the attributes of the dimension.
6.)Configuring Column Bindings:
Three properties used for column bindings: KeyColumn, NameColumn and ValueColumn.
By default the Key column property of English Month Name is configured to EngMonthName column and if you process the dimension the output can be viewed in the browser and it shows the English Month Name attribute hierarchy ill show the month in alpha order.
Can manipulate this property by using namecolumn property so first change the keyColumn property to point to MonthNumberOfYear and when the dimension is processed the result is 1 to 12 ascending order. This is where NameColumn property becomes useful so here we provide a mapping to the EnglishName. Processing the dimension gives Jan till Dec.

Modifying a Dimension:
You can add/delete an attribute by removing and adding in the attribute pane.
Note:
1.)For the dimension the following 2 properties define the storage mode:
--Storage Mode-defines if the attribute is stored using MOLAP or ROLAP. Most Common MOLAP deployment.
--Proactive Caching- determines whether SSAS processes the updates automatically .Most solutions do not deploy Proactive Caching

Attribute Properties:
1.) Name
2.) Usage- setting of key means that it’s a key column which other attributes relate to. A setting of parent means that it is a part of parent child relationship.
3.) KeyColumns - columns used for Pk
4.) NameColums - optional specifies the columns that provide name values
5.) AttributeHierarchy -Enabled- True if the attribute is used in a multi level hierarcy.
6.) AttributeHierarchy -Visible – if the attribute can be seen and selected by the users
7.) IsAggregatable – Specifies whether the values of the attribute members can be aggregated.
8.) OrderBy - specifies if the members of the attribute are ordered by its own key or name columns.
9.) OrderByAttribute - provides the name of the attribute that provides ordering
10.) Type- specifies the type of info contained in the attribute
Note:
It is important to add the dimension that is created after the cube id processed. They can be added by clicking add cube dimension button at the toolbar.
1 dimension can be added more than once eg time dimension might have to be added more than once to support analysis by different dates eg due date, order date, ship date etc. A dimension that is added multiple times to the same cube is called the Role-Playing dimension.
A role-playing dimension is a dimension that is used in a cube more than one time, each time for a different purpose. For example, you might add a Time dimension to a cube three times to track the times that products are ordered, shipped, and received. Each role-playing dimension is joined to a fact table on a different foreign key.
Dimension usage tab can be used to assign meaningful names to the multiple used dimensions with the appropriate measure groups.

Creating Measure Groups and Measures:
2 scenarios when new measure groups are required:
1.)When new fact table has been added to the database:
As relational table is a container of columns, a cube measure group contains related measures. As new column is added to a fact table, there is a need to add corresponding measures to the measure group.
Use theusage drop down list to select its aggregate behavior . Based on how they aggregate they can be classified as additive (can be summed across all dimensions eg sales amount), semi additive (can be summed across all dimensions except time account balance) or non additive (cannot be summed eg interest rates).
2.) When you need a distinct count measure that calculates the number of fact rows with unique values eg number of unique customers that have places orders. Because of the required server overhead to store distinct count measures a measure group can have only 1 measure with the distinct count aggregation function.
The new measure Group Dialouge box does not let you select a fact table that is already being used by another measure group. The distinct count measure must be placed in a separate measure group. As a workaround the cube will automatically create a new measure group when you try to add a measure that contains a DistinctCount aggregate function to the existing measure group.
Make sure the underlying fact table is included.
Best Practices:
The end user can browse data in the measure group only by dimensions that are joined to the measure group. If the dimension is not joined to a measure group the IgnoreUnrelatedDimension measure group property controls the result when a user browses the measure group by that dimension. When a new measure group is added, the cube designer examines the relationship between fact table and the cube dimensions and sets the dimension usage accordingly. Go to Dimension usage tab to review the settings.
Notes:
A measure group must contain at least 1 measure.
The cube designer adds a system generated measure that contains a count aggregate function. This is useful if you need the server to automatically calculate the number of fact table rows.
Eg if the Internet Sales Measures group represents a customer order and the user slices the cube by year the Internet sales count measure will return the number of orders places in the year. You can remove the count measure after the cube designer has generated the measure group.

Measure Group Properties:
ErrorConfiguration-Specifies default or custom error config
EstimatedRows-number of rows of fact table already know in this case help the server choose optimum data structure.
IgnoreUnrelatedDimensions- Defines the server behavior when the user browses the measure by unrelated dimensions to the measure group.
ProactiveCaching-none
ProcessingMode-Regular (users cannot access the measure group until processing is complete), LazyAggregations (data is accessible as soon as it is processed but processing takes longer)
StorageMode- MOLAP, ROLAP, HOLAP
Tyoe-information about the contents of the measure group

Measure Properties:
AggreagateFunction:
1.)Additive (additive across all dimensions) eg sales amt, volume of participant’s etc, Semiadditive (additive across dimensions except time dimension) eg account balance and nonAdditive (cannot be added across dimensions) eg rates etc
2.)Display folders: Groups measures into logical folders
3.)DataType: Needs to be explicitly set for count and distinct count measures. Inherit gets the data type from the underlying DSV.
4.)FormatString : Defines the measure display format
5.)MeasureExpression: Defines the measure expressions.
6.)Source: Defines the measure bindings. A count measure can be bound to a row if it needs to count rows.
7.)Visible: When set to false the measure is hidden from the end users though can be used in MDX expressions.