Micro Strategy Technical Training

MICROSTRATEGYEDUCATOR.COM A place to redefine your BI knowledge

© Copyright MICROSTRATEGYEDUCATOR.COM 2009

Microstrategy Technical Training

By Joydip BanerjeeDW-BI professional & Microstrategy Technical Educator

Business Consulting Services

© Copyright IBM Corporation 2007

MICROSTRATEGYEDUCATOR.COMA place to redefine your BI knowledge


Setting the expectation

Introductions Expectations Ground Rules Who is the target audience for this course? What topics will be covered?





Method of Instruction

Each Session will be followed by Practical Hands On Trainees will have to create local database (i.e MS Access) LDM & PDM will be provided by the trainer Microstrategy will be configured to connect to the Local database For each topic there will be two Hands On Project

1) Basic

2) Advanced





Agenda

Microstrategy Essentials Introduction to Microstrategy MSTR feature highlights Data Modeling for optimal BI performance MSTR Installation Creating MSTR Project

Microstrategy Objects Schema Objects & Public Objects

Microstrategy Report Services Reports, Dashboards, Scorecards

Microstrategy Administration Microstrategy Administration & I - Server

Microstrategy Add Ons Microstrategy Office & Microstrategy SDK VLDB Properties Troubleshooting





Introduction

An optimum business intelligence application

Gives users access to data at various levels of details.

Allows users to request information and have it delivered to them accurately and quickly.

Provides a foundation of proactive delivery of information to system subscribers.

A typical BI architecture has the following components

A source system (Usually an OLTP system)

An ETL Process

A data warehouse (OLAP system)

A BI platform





How it all fits into DW/BI Framework

Data Warehouse

Data modeling Tool

SQL queries

ETL Tools

OLTP DB

Reports, Charts, Scorecards, Dashboards

Data warehouse Intermediate Processing Reporting and Analysis

Manual Queries

Custom Applications

BI tools

http://www.qtechinternational.com/Images/Email%20Charts-Reports%20Picture.jpg





What is enterprise business intelligence and how does the MicroStrategy 8 platform deliver it?

Business Users: Explore all 5 styles of BI — Scorecards and Dashboards, Enterprise Reporting, OLAP Analysis, Advanced and Predictive Analysis, and Alerts and Proactive Notification — integrated into a seamless reporting, analysis, and monitoring experience for fact-based decisions.

Analysts: Investigate enterprise data with easy to use analytical techniques such as pivot, drill, sort, prompting, on-the-fly metric creation, report filtering, ad hoc report creation, and more.

Report Authors: Design and refine scorecards, dashboards, enterprise reports, and OLAP reports — with what-you-see-is-what-you-get (WYSIWYG) ease.

BI Developers: Create the crucial and reusable report building blocks that business users, analysts, and report authors use: KPIs, metrics, data filters, prompts, time series calculations and many more.

BI Architects: Model the business into easy to understand objects such as business dimensions, business attributes, and facts to eliminate database table, schema, and naming complexity.

Administrators: Manage enterprise BI applications for thousands of users using real-time system monitoring, historical operating information, and comprehensive security.

BI Project or Application Managers: Turn business users’ requirements into insightful BI applications, while maintaining the lowest total cost of ownership (TCO).





Architecture

Simple, scalable and unified architecture





MicroStrategy 8 Platform

Server Administration User Interface Developer Tools

Service Modules

Intelligence Server

MSTR Administrator

Desktop MSTR Administrator

OLAP Services

Narrowcast Server

Narrowcast Administrator

MSTR Web MSTR Desktop(Architect/Designer)

Report Services

MSTR Office SDK Data mining Services

BI Developer Kit

MSTR SAP Services





Data Modeling for MSTR

MSTR uses ROLAP. Hence the data model should have a schema suitable for ROLAP Snowflake schemas work best with MSTR Deal with M:M relationship in the Database. Do not try to deal with M:M in MSTR Verify all dimensions required are available in database Understand the relationship between dimensions in your model Identify the granularity of facts Understand the aggregates Your data model should not include unconnected attribute hierarchies within the same dimension Prepare your model for transformations Maintain homogenous definitions in warehouse Raw data is usually copious, consisting of a large number of facts and attributes. What subset of the facts and

attributes in the raw data are of interest to you in decision support investigations? What attributes and facts, not present in the raw data, would you like to include in your decision support reports?

These could be from a different data source altogether and typically reflect the business rules of the organization. Within each dimension, what is the drill-down path along which you would like to get data at successively finer detail?

This provides an indication of the principal attribute hierarchy within each dimension and forms the basis of the connected tree of attributes that will completely specify the dimension

Cooked tables of required Correct Indexing strategy Data Partitioning strategy In the case of compound attributes, all attribute IDs within the compound structure that are needed to uniquely

identify an attribute within the compound structure should be included in base tables at that attribute level.





The warehouse can be partitioned along any number of dimensions If you choose to partition a table in your data warehouse, you must construct a Partition Mapping

Table that contains the attribute ID(s) you are using for your partition. Neither range nor description mapping is supported. In addition, the Partition Mapping Table must contain a column named “PBTNAME” containing the names of each of the partitioned base tables.

You must have one Partition Mapping Table (PMT) for each fact table to be partitioned. Column names must be consistent throughout the Partition Mapping Table, attribute lookup tables,

and partitioned base tables Partitioned base tables must contain either the attribute by which they are partitioned or one of its

descendants Parts of a compound attribute cannot be omitted from partitioned base tables For each level of aggregation, the data warehouse must contain a separate lookup table for each

attribute and only one record per attribute element. Multiple attributes can use the same lookup table as long as the lookup can only be joined to a fact table by the unique, or atomic, key

For all attributes that are not compound, lookup tables can contain only the attribute ID, description of the attribute, or both

For compound attributes, the IDs and descriptions of all the attributes within the compound structure that are necessary to uniquely identify an attribute should be included in the lookup table






A relationship table (or a combined lookup-relationship table) must exist for each parent-child relationship. It must contain the parent ID and the child ID; no descendants of the child attribute can be included in this table

For attributes that have a many-to-one or many-to-many relationship the relationship table for the child attribute should have the parent and child attribute forming the primary key

For attributes that have a one-to-one or one-to-many relationship, the relationship table for the child attribute should have the child as the primary key

If you include non-multiple parent-child relationships in a lookup table, the child attribute must be the primary key in the modified lookup table

Including all ancestor attributes within a relationship or modified lookup table is most optimal

For attributes that share a multiple parent-child relationship, you must not include the parent-child relationship in the lookup table containing the child attribute

When creating modified lookup and relationship tables, you must ensure that each non-multiple parent-child relationship is in one table in which the child attribute is the primary key, and that each attribute has a lookup table associated with it

Indexing provides a means for quickly locating information in a data warehouse table and can significantly improve query response time






Model Warehouse





MicroStrategy Metadata

MicroStrategy Metadata contains information about the Microstrategy application objects.

Metadata stores

Information about the data warehouse table names/column names that have been included in the Microstrategy

Object Mappings ( Attributes/Facts to table/column names)

Maps MicroStrategy objects to data warehouse structure and content.

Metadata Objects:

Schema Objects – Directly reflects the warehouse, such as tables, facts, attributes.

Application Objects – Top layer information, such as reports, filters, metrics.





MicroStrategy Intelligence Server

Major Functions:

Central Point for all communication for metadata and warehouse and the clients

Handles client requests for objects

Handles Database connections

Apply security to all incoming requests

Object/ Element/Report Caching

Included the SQL Engine

Contains an Analytical engine with over 150 different mathematical and statistical functions. This is capable of handling some processing too

All other products in the MicroStrategy platform work in conjunction with the Intelligence Server.





MicroStrategy Architect

Model applications using an intuitive graphical interface. It provides an environment for creating and maintaining BI application.

Project Designer is responsible for the design,implementation, and creation of projects.





MicroStrategy Web

Deploy reports and related objects to large number of users via the web.

It provides an easy large scale deployment to many users without having to install a product on each users machine..

Pure HTML thin web client which is easily customizable using the SDK

All the major tasks are handled by the Intelligence Server, the web server handles http requests from users and returns data requested.





MicroStrategy Office

Users can run, edit and format any MicroStrategy report directly from within Microsoft Office applications such as Excel, PowerPoint and Word.

Designed using Microsoft .NET technology and accesses the MicroStrategy business intelligence platform using XML and Web services.





MicroStrategy Narrowcast Server

Proactively distributes personalized information to report customers through a variety of devices, including mobile phones, PDA’s, e-mail, Web pages, and pagers.

Distribution of personalized messages are triggered according to predefined schedules and exception criteria

MicroStrategy Narrowcast Server also provides a self-subscription portal.





MicroStrategy Architect





Setting up a MSTR Project

Identifying the Datamart/Database Setting up the ODBC Connection – MSTR Metadata connection, Database

Connection Creating New Project Identifying the Tables required from Datawarehouse Bring the required Tables in the MSTR warehouse schema Ready to go





Exercise

Creating your first project– Create Metadata DSN– Create Database DSN– Create new project in Desktop– Point the Project to Metadata Database Instance (This is for MSTR to create the

MSTR proprietary tables which will hold the metadata information)– Point to the Ware House Database instance (This step gets the actual warehouse

tables that have the reporting application data)– Include tables from warehouse to MSTR– Create Attributes– Create Facts– Create Hierarchies and other schema objects– Proceed to create Public objects





Architect – Concepts

This section includes

Project

Project Source

Data Model/Warehouse Connection

Attributes

Facts

Hierarchies

Partitions

Transformations





Project

A project is the highest-level intersection of a data warehouse, metadata repository, and user community.

Projects are where you create and modify objects that the Report Designer can incorporate into future reports.

Determines the set of warehouse tables to be used, and therefore the set of data available to be analyzed.

Contains all of the schema objects used to interpret the data in those tables (facts, attributes, hierarchies, and so on).

Contains all of the reporting objects used to create reports and analyze the data (metrics, filters, reports, and so on).

Defines the security scheme for the user community who will access these objects based on restrictions/access control (security filters, security roles, privileges, access control, and so on).





Project Source

A project source is the connection to a MicroStrategy metadata or a MicroStrategy Intelligence server

Connection Modes

The connection modes determine how the projects connect to the metadata for data retrieval. A project source can have one of 2 connection modes:

Server (3-tier): A 3-tier connection mode connects the project to the metadata via the MicroStrategy Intelligence Server. You need to know the server name and port number to setup this connection.

Direct (2-tier): A 2-tier connection mode connects the project to the metadata via an Open Database Connectivity (ODBC) data source name (DSN). You need to know which database the project uses.





Project Source (Direct)

Repository 2

Project Source 1

Project 1

Project Source 2

Repository 1

Project 2

Data Warehouse

Data WarehouseProject 3Desktop





Project Source (Server)

Repository 2

Project 1

Project Source 2

Repository 1

Project 2

Data Warehouse1

Data Warehouse2

Desktop

Server





Exercise2 A – Warehouse Definition

Pre-Requisites

• Metadata and project creation complete.





Data Model/Warehouse Instance

The data model is composed of the following parts:

Attributes allows users to define the level of aggregation at the attribute level. For example, City may be an attribute while New York City, San Francisco, and Boston are elements within that attribute.

Hierarchies are groupings of attributes that are ordered to reflect their relationship with other attributes. The best design for a hierarchy is to organize or group attributes into logical business areas. For example, the attributes City, State, and Store are grouped to form the Geography hierarchy.

Facts can be thought of as business measurements, data, or variables that are typically numerical.





Attributes

Attributes represent entities in the business model and are normally identified by a unique ID column in the datawarehouse.Attributes are the schema objects against which the measures will be viewed (Dimension). Eg Country Attribute

Attribute elements are the unique values or contents of an attribute. For example, if City is the attribute, then Chicago and Miami are elements of City.





Attribute Form

Attribute forms are identifiers or descriptors of an attribute.

Two types of forms: (Though new types of form like URL etc. can be defined)

• ID – Identifying elements of the attribute

• DESC – Description elements of the attribute.

There can be a single ID and a single DESC form for a single attribute.

Form group is a grouping of attribute forms that have something in common. Form group Name can be defined grouping the First Name and the Last Name.

Each form must have a form expression. It defines the mapping between database columns and the attribute form.

Attribute display: You can choose the ID or the description or both for display.The types of attribute form expressions are• simple• implicit• derived• heterogeneous mappingsApplySimple pass-through function can be used to add database-

specific syntax which allows SQL to go directly to the database.





Attribute Tables

Attributes are defined by using expressions off of the source tables.

Each attribute can have many source tables but only one LOOK-UP table

Source tables are candidate tables for joins

Lookup tables have a distinct listing of all attribute elements ( they are used for attribute browsing)





Attribute Relationships

Attribute relationships relate and define the relational data model.Without relationships there is no interaction of data, and therefore no structure. The attribute relationships give meaning to the data by describing how data is related within a project. Through relationships, attributes can act as either child or parent in a relationship. The defined parent-child relationships determine the system hierarchy.

The following types of relationships are explained below:

one-to-one (1:1)

one-to-many (1:M)

many-to-many (M:M)

joint-child relationships*

* Some attributes exist at the intersection of other indirectly related attributes. Such attributes are called joint children.





Exercise – 3 Create Attributes

Pre-Requisites

• Empty Project Shell

• Warehouse Instance defined.

• Warehouse Catalog SQL configured.

• Necessary tables added in the project

DON’T FORGET “SCHEMA UPDATE”





Hierarchies

Are structures based on relationships between attributes.

Helps to logically define and order groups of attributes

Types of Hierarchies:

System Hierarchy – It contains all of the attributes in the project and is actually part of the definition of the schema.The system hierarchy holds information on the relationships between attributes in the project. The system hierarchy cannot be edited, but is updated every time children or parents are added or removed in the attribute editor. There is only one system hierarchy in each project. Data Explorer is a tool in the object browser which holds the System Hierarchy

User Hierarchy – Defines the browse and drill relationships between attributes. The user hierarchy is the only type of hierarchy which can be defined, and unlimited number of user hierarchies can be created for each project.





User Hierarchies

Entry Point: Starting attribute while browsing the hierarchy. Filtering: You can add filters to a given hierarchy so only a subset of data is

available for users Locked/Unlocked: This refers to the actual element display of the attributes. If

you have a large list of elements it is cumbersome to browse thru them. So you can lock the attribute display.





Exercise – 4 Create Hierarchies

Pre-Requisites

• Defined Attributes with relationships

• Business requirements for hierarchy browsing/drilling





Facts

Fact are actual measurable objects. It doesn’t describe data like attributes. It is the actual data values.

Facts are used to create Metrics which are used in MicroStrategy reports. Facts directly cannot be used in reports.

Types of Fact:

Simple Facts

Implicit Facts

Derived Facts

Fact Definition:





Fact – Level Extension

Facts are stored at a particular level in the warehouse. The fact level is defined by the attribute id(s) present in the table.

Level extensions are necessary when facts are stored in the DW at one level and reported at a different, unrelated level.

It defines how the fact level can be extended, lowered, disallowed to other attributes across the schema.

The fact level can be extended through

• Table relation

• Fact relation

• Cross Product join – When Cartesian product is necessary (while reporting a fact against totally unrelated attribute)

Degradation – Lowering the fact level. Mostly used in case of allocation.

Disallow the fact level – Disallows the reporting of a fact against specified level of an attribute. (Data can be stored at Minute level, but reporting may not be allowed at that level. Only works for the extended levels)





Level Extension – Table Relation





Level Extension – Fact Relation





Exercise – 5 Create Facts

Pre-Requisites

• Source Data Model and business requirements

• Underlying Tables incorporated in the project





Exercise – 5 Contd

Facts

• Cost – TOT_COST or (QTY_SOLD*UNIT_COST) or ORDER_COST

• Discount – QTY_SOLD*DISCOUNT

• Profit – (TOT_DOLLAR_SALES – TOT_COST) or QTY_SOLD*((UNIT_PRICE-DISCOUNT) – UNIT_COST) or ORDER_AMT – ORDER_COST.

• Revenue – TOT_DOLLAR_SALES or QTY_SOLD*(UNIT_PRICE-DISCOUNT) or ORDER_AMT





Transformations

A transformation is a schema object that helps us to compare results of different time periods.

Transformations are based on tables, such as transformation tables that are selected to compare values at different times, for example, this year vs.last year sales, or new customers this month vs. last month.

Transformations can be used to define metrics based on the member attributes included.

A single transformation contains:

• Member attributes – Transformation contains attributes that are already defined in the project.

• Expression – Retrieves the information from the current member attribute value. So the table selected for the expression must include the included attribute(s).

• Transformation mapping type - Determines the way the transformation is created based on the nature of the data. It can be of two types:

• one-to-one – like Last Year Day to This Year same day.

• many-to-many - Year to Date.





Public Objects





Public Objects – Concepts

This section includes

Metrics

Filters

Custom Groups

Prompts

Consolidation

Report

Templates

Documents





Metrics

Metrics are analytical calculations performed against stored data to produce results analyzed for decision-making purposes. Metrics are report components that enable analytical calculations against warehouse data.

Types of Metric :

There are two types of Metric:

Simple – These are the simplest of metrics and derived directly from fact(s), some formula can be used to calculate the metric.

Compound – Compound metrics are made of other metrics (which could, in turn, be simple, or other compound metrics) and one or more mathematical operators.





Metric Composition

Metrics may consist of:

Formula – The portion of the metric that is included in the SQL Select clause. It defines the data on which the metric is applied and the calculations to be performed on that information.

Dimensionality (known as metric level) – Includes three parts:

• Target, which determines at what level the criteria specified by Where and Group by are to be applied

• Grouping, which determines how the SQL Group by clause is modified. Options are

- Standard, None, Beginning Lookup, Ending Lookup, Beginning Fact, Ending Fact

• Filtering, which determines how the SQL Where clause is modified for calculating the metrics.

Conditionality - Allows associating a filter to metric calculations. This filter modifies only the metric to which it is applied; it does not affect other metrics applied to the report.

Transformation - Applies offset values to selected attributes. They are most frequently applied to time.





Exercise – 6Create Metrics





Exercise – 6

Metrics

• Revenue

• Revenue contribution income bracket wise.

• Last Year’s Revenue (User Last Year’s transformation)





Filters

Specifies the conditions/qualifications that the data must meet/qualify in order to be included in the report results.

Qualification Types

• Attribute – Can qualify on attribute elements/forms(ID, DESC), Elements , Date (Static, Dynamic)

• Set Qualification – Helps to define a set based on metric qualification or relationship.

Eg. Sales numbers for products whose current inventory levels fall below a certain level. (Metric Qualification)

All the stores selling Nike shoes in the Washington. (Relationship Qualification)

• Report Shortcut

• Filter Shortcut





Relationship Filtering

Allows to create a link between two attributes and place a filter upon that relationship. It allows to create a set of elements from an attribute based on its relationship with another attribute. For example, relationship filtering allows you to create a report that could show you all the stores selling Nike shoes in the Washington, DC area.

Relationship filtering Components:

Relation – A Fact, Table, or it can be Empty. The fact and table are the relationship between the attributes in Filtering Input and Output Level. The Relationship determines which table is used during SQL generation.

Filter – Qualification defines input filtering criteria. It consists of an attribute qualification, filter qualification, or metric qualification.

Output – Attributes you want to filter on.

For the above example Fact = Sales, Filter = {Item = ‘NIKE’ and Region = ‘WASHINGTON’), Output = Store.





Prompts

There are four major prompt types available for definition:

Filter definition prompts, with which can qualify on:

• all attributes in a hierarchy

• a single attribute – Apply conditions or qualifications on an attribute form.

• an attribute element list – To restrict, at run time, the attribute elements from which the user can select for inclusion in a filter or custom group.

• a metric – To limit, at run time, the selection of metrics that can be used to create qualifications for inclusion in a filter or custom group.

Object prompts – Used to define the list of objects applicable to a report at run time.

Value prompts – Used when the information desired at run time is a single value of a specific data type.

Level prompts – Used to define dimensionality when two or more metrics differ only in level.





Custom Groups

Custom group is a group of filters that can be placed on a template/report.

It is made up of an ordered collection of elements called custom group elements.

A custom group element is a logical expression of qualifications. A custom group element contains:

• Header – This is an arbitrary name to define the elements. This name can be displayed on the report, and can be modified as desired.

• Expression of qualifications –any qualification or logical expression of the qualification can be defined, previously created filters can be used to build the custom group element. It also includes banding qualification.

Small stores with low inventory Large stores with low inventory

Store Sales > 50 Store Sales < 50

AND AND

Store Inventory < 200 Store Inventory < 200





Consolidations

Suppose the requirement is to see season wise revenue, but season does not exist as an attribute.

Consolidation allows to group together the elements of month and year attribute into various seasons and place them on the report as an attribute.

In general consolidation provide two powerful functions:

• Create virtual attribute.

• Perform row level math.

Consolidation elements can contain

• Elements of the same attribute (Season)

• Elements from different levels (Value at lower level as Percentage of the higher level)

• Elements from unrelated attributes. (Difference in value of two regions for a particular month)





Reports

A report is a MicroStrategy object that represents a request for a specific set of formatted data from the DW.





Reports – Options

Calculated Metric

Dynamic Aggregation

Apply Transformation

Ranking

Advanced Sorting

Export to Excel, Word, Access, Text, HTML

Create Data mart

Format

Subtotals

Calculate Percentage

Grand Totals





Templates

A template defines the layout of general categories of information in a report. In a template, the information that will be retrieved from the data warehouse and the way it will be displayed are specified.

Layout – Can be Cross tab, Tabular.

Template Objects:

• Attribute

• Consolidation

• Hierarchy

• Metric

• Custom Group

• Object Prompt





Exercise – 7Create Reports





Exercise – 8Create Advanced Reports using

FilterCustom Groups Consolidation Transformation





Exercise – 8

Filter

• Create a filter Item A to select a single Item. Provide a default selection.

• Create a filter Item B to select a single Item. Provide a default selection.

• Create a filter that will return the orders containing the selected items in the two created prompts.

Custom Groups

• Create Customer Age groups

Consolidation

• Create Season combining calendar months

Transformation

• Create a transformation to report Last Year’s data.





Documents

A document is an HTML container for formatting, displaying, and distributing multiple reports on the same page.

The document layout is an HTML file

It includes special tags to identify the placements of the reports.

Reports are represented by image tags.

The images are replaced by the actual reports when the document is executed.

Documents can not be viewed in a 2-tier architecture.

For each report placed in the document a XSL style sheet has to be specified.





MicroStrategy Administrator





Security

In the MicroStrategy environment, security can be implemented in the following places:

Database – facilities depends on the database vendor.

Network/Operating system

MicroStrategy applications

In general, security systems have the following components:

User Definition

Authentication – A way to identify the user to the system

Access control: data – What data the users are allowed to see once they have logged in

Access control: application functionality – What functions the users can perform once they have logged in to the system





MicroStrategy User Model

Users are defined in the MicroStrategy metadata and exist across projects.

Do not have to define users for every project those are created in a single metadata repository.

Administrator is a built-in default user created with a new MicroStrategy metadata repository.

A user group is simply a collection of users.

It is possible to create users individually using the User Manager interface or using the Command Manager utility that is part of Administrator.

It is also possible to import users from a text file, from the Windows NT user directory, or from an LDAP directory.





Authentication

There are six types of authentication modes in the MicroStrategy environment.

Standard – MicroStrategy Intelligence server is the authentication authority.

Windows NT

Database: Warehouse - MicroStrategy Intelligence server is the authentication authority. User logs into MSTR server using anonymous user. Server must be configured to allow anonymous authentication.

LDAP (lightweight directory access protocol) – identifies users within a repository of users stored in an LDAP server

Anonymous - When using anonymous authentication, users log in as “Guest” and do not need to provide a password.

The authentication mode is set for each project source using the Project Source Manager.





Access Control – Data

Data access control can be defined at two level:

RDBMS Level – Security view, Split table by rows, Split table by columns.

MicroStrategy application level – MicroStrategy Intelligence server provides the following security services to implement access control:

• Connection Map –

• Pass through execution –

• Security filter – prevent users from seeing certain data in the database. A security filter has these parts:

o Filter expression specifies the subset of the data that a user can analyze.

o Top range attribute specifies the highest level of detail that the security filter allows the user to view.

o Bottom range attribute specifies the lowest level of detail that the security filter allows the user to view.





Access Control – Application

Functionality for access control within the Intelligence Server:

Privileges –

• Object creation privileges specify the types of objects a user can create.

• Application access privileges specify the editors, dialogs, and wizards with which a user can interact.

• System privileges are system-wide privileges, such as whether a user is allowed to back up the system, take ownership of an object, or log another user out of the system.

• There is a special privilege called Bypass all object security access checks. For users who have this special privilege, the access control permissions described here are effectively ignored.

Security roles – Collection of privileges.

Permissions - define which users and groups have access to what objects and the degree to which they can access those objects.





Scheduling

Schedule reports according to two types of criteria:

• time-triggered criteria

• event-triggered criteria

Schedule is available to user groups based on the Access Control List.

There are two ways to use report scheduling:

• allow end-users to subscribe to reports themselves either through Desktop or Web based on schedules defined by administrators

• have the administrators schedule reports on the behalf of users

When a scheduled report finishes executing, a message appears in the user’s history list alerting him that the report is ready to be viewed.

Alternatively, it might not be as important to deliver the results of a scheduled report to the user as it is to refresh a report cache, which can be shared by several users.

Cache refreshing schedules are usually event-triggered since caches do not need refreshing unless the underlying data changes from an event like a warehouse load.





MicroStrategy 8 / Microstrategy 9 (ORION) Architecture

Microsoft IIS Server

Desktop Client- Designer/Reporter

Web Client

Intelligence Server

Data Warehouse

Repository

• Server Centric

• Better Management and scalability

Metadata

ODBC

ODBC

HTTP

TCP/ IP





Exercise – 2Create Project

Pre-Requisites

• Installed Software(At least Desktop)

• For 2 tier: Identify Repository Location (tables space where the metadata tables are going to be created)

Run the Metadata configuration script

• For 3 Tier: Identify the Server which is going to be used. Configure the server to point to the right metadata

• Run Create project Wizard from the desktop.





Setting up a Project

Pre-requisites MicroStrategy server/desktop installed

Server Instance Configured in a MicroStrategy Metadata

or Metadata tables created in a db instance.

Warehouse Instance definition ( login/password)

Micro Strategy Technical Training

Documents

Transcript of Micro Strategy Technical Training