MicroStrategy Design Challenges - Tips and Best Practices

10 MicroStrategy
Design Challenges
Design Tips & Best Practices for MicroStrategy
BI Architects and Developers
www.persistentsys.com
eBook

Contents
Technical Design Challenges
#1 Developing Multi-language Reports 4
#2 Developing Metadata for Various Business Functions 7
#3 Improving Warehouse Performance 9
#4 Improving Report Performance 11
#5 Data Authorization 13
#6 Time Series Analysis in MicroStrategy 15
#7 Ad-hoc Report Creation via Guided Process 17
Process Design Challenges
#8 Metadata Development in a Distributed Environment 19
#9 Testing Metadata 21
#10 Handling Updates of OEM Applications 23
Conclusion 25

A Quick Primer
MicroStrategy is a Business Intelligence tool used to design and develop BI solutions that addresses a myriad
challenges faced by various industry verticals in analytics. BI solutions are developed to serve the analytical needs of
multiple customers coming from various industry verticals. As the functions and needs of every industry and business
are disparate, designing a BI solution for each specific need becomes an interesting challenge. In this eBook, we share
10 interesting and common design patterns and challenges encountered when working on MicroStrategy projects.
Some of these design patterns are more involved than others. We will discuss design problems such as multi-language
support, ad-hoc reporting, authorization, etc. and also provide possible solutions for these, as well as things to
consider while developing BI solutions.
This eBook focuses on data warehouse and metadata related problems in MicroStrategy projects and is split in to two
parts-technical and process related design challenges.
If you are developing a metadata and BI framework using MicroStrategy, this eBook will help you overcome the
common design loopholes. This eBook will also be helpful if you are architecting BI solutions.
This eBook
focuses on
Data warehouse and
metadata related
problems in
MicroStrategy projects
and is split in to two
parts-technical and
process related design
challenges.
eBook
Persistent
© 2013 Persistent Systems Ltd. All rights reserved.
3
10 MicroStrategy Design Challenges

Developing Multi-language Reports
BI solutions need to provide multi-language support. Multi-language support implies that data on the reports and the
metadata showing up on the reporting user interface be translated to the user's preferred language. Business users
may not really differentiate between data and metadata; however, developers need to make sure that the following
items are translated appropriately to the users' preferred language(s):
 Metadata objects provided by the tool (e.g. labels on the menu such as File/Open dialogs and other general
interface)
 Metadata objects created by developers (user defined metrics, attributes, prompt text, chart titles, etc.)
 Data on the reports (e.g. data showing up on the reports coming from the data warehouse)
Support for multiple languages, for the first two objects on the list, is relatively well defined in a BI tool. MicroStrategy
provides a Repository Translation Wizard (part of Object Manager), which can export the metadata object strings for
translation. The translated object strings can then be imported into MicroStrategy. However, when it comes to the third
item–data on the reports–it can turn out to be quite challenging, because the solution depends on how the warehouse
is modelled. We will look at various ways to store multi-lingual data in the warehouse and how MicroStrategy can use
this data to provide multi-lingual reports.
eBook
Persistent
Challenge
Solution
Common patterns used for storing the multi-lingual data in the warehouse:
 Column-based or database-based translation: In this pattern, the translated data items are placed in
separate columns, tables, or in separate databases. Most BI tools provide well-defined language translation
methods, when the warehouse is modelled using this pattern. This pattern, however, calls for additional ETL
effort and maintenance activities, for any language-related changes. Various ways, using which, you can
store data in the database are:
#1
1Challenges 2 3 4 5 6 7 8 9 10
4

eBook
Persistent
MicroStrategy
supports out-of-the-
box column-based
language translation
A column per language: There is one column per language in the dimension table.
A table per language: The translated data can be stored using one dimension table per language.
A database per language: A separate database instance for each language to store translated data. Based on the
user's preferred language, the BI tool connects to the appropriate data source. This configuration can be done in
MicroStrategy.
For the column or table-based approach, MicroStrategy provides SQL-based Data Internationalization.
MicroStrategy uses appropriate SQL queries to access data in the warehouse. For the database-based approach,
MicroStrategy provides connection-based Data Internationalization. MicroStrategy uses ODBC APIs to access data
from the appropriate warehouse. In either case, you have to take additional steps to configure your project to enable
internationalization.
Figure 1. One column per language
ID NAME NAME_DEFAULT NAME_ENGLISH NAME_FRENCH NAME_GERMAN
1 Blackboard Blackboard Blackboard TABLEAU NOIR TAFEL
ID NAME
1 Blackboard
DIM_PRODUCT_DEFAULT
ID NAME
1 Blackboard
DIM_PRODUCT_ENGLISH
ID NAME
1 TABLEAU NOIR
DIM_PRODUCT_FRENCH
ID NAME
1 TAFEL
DIM_PRODUCT_GERMAN
Figure 2. One table per language
DB_DEFAULT DB_ENGLISH DB_FRENCH DB_GERMAN
Figure 3. One database per language
© 2013 Persistent Systems Ltd. All rights reserved.1Challenges 2 3 4 5 6 7 8 9 10
5

The tables or columns that store translated data must follow
consistent naming conventions. For example, as showed in the
Figures 1 and 2, if you are using '_FRENCH' for storing French data,
then use the same suffix for all the rows and columns in the tables
that store French data.
It is important to configure the project to use the underneath
language tables. The Language section needs to be filled to choose
the appropriate method (SQL-DI or Connection-DI) for translation.
Also, specify the suffixes that will be used.
 Row based translation: This pattern stores the translated data in
different rows of the same table and is illustrated in Figure 4. In
DIM_PRODUCT, we will have one row per language for a
particular product. With this approach, adding more languages to
the warehouse and maintaining multi-lingual data becomes
flexible and easy. However, reporting solution for this model,
when using MicroStrategy, becomes very complex.
DIM_PRODUCT
ID NAME LANGUAGE
1
1
1
1
BLACKBOARD
BLACKBOARD
TABLEAU NOIR
TAFEL
Default
English
French
German
Figure 4. Product Dimension with multi-language data
MicroStrategy does not have an out-of-the-box solution for row-based translation. Your creativity will need to come into picture! One of the various ways
this can be done is by using the system prompt and security filter combination to capture the logged in user and the user's language preference. Security
filter functions similar to a normal filter. However, the qualification defined by the security filter is added to the WHERE clause of every SQL that
MicroStrategy generates. For this type of solution to work accurately, metadata relationships between the language tables and the dimension tables
should be modelled precisely during the metadata modelling phase.
6
eBook
Persistent10 MicroStrategy Design Challenges

Developing Metadata for Various Business
Functions
Enterprises prefer a BI solution that works for multiple business functions/groups. For example, in the retail industry the
same BI solution needs to work for sales, purchase, inventory, billing, etc. The boundaries around these functions need
to be drawn within the solution such that, only authorized business groups get access to specific reports and
operations. This section lists a few of the multiple considerations that need to be made to develop such a BI solution.
eBook
Persistent
Solution
Even if the same BI solution supports multiple business groups and
functions, there is a lot of common metadata that they share. Also, there
would be parts of metadata and reports that are mutually exclusive for
each business function or department. As a first step when developing a
BI solution developers should identify a set of objects that are common
across business functions and objects that are exclusive to each business
function. A thorough design/paper work must outline the
metadata/object separation.
Business functions will be sharing confirmed dimensions and will have
common data, as well as data and tables that are exclusive to certain
functions. Within MicroStrategy, it makes sense to have a single metadata
database that supports all the functions. As the common set of metadata
objects resides in a single codebase or metadata database, there is no
duplication of common metadata and resulting maintenance work. The
setup for development and testing environments also becomes simple.
Challenge
#2
BI
Solution
se
laS
Inven
tory
7

eBook
Persistent
The following pointers can help when using a single metadata database:
 Identify the common and speciﬁc metadata objects across business functions.
 Identify the list of reports for various business functions.
 Decide on a strategy for separation of metadata across business functions. This would involve a detailed design of user groups and their
update policies, access control lists and corresponding update policies, speciﬁc objects needing authorization, etc.
 Creating one user group per business function.
 Create ACLs (Access Control Lists) so that objects belonging to a particular business function can be accessed by the authorized business
user group only.
 MicroStrategy administrator can see all the objects and should be aware of the boundaries and metadata.
 The roles that MicroStrategy provides must also be considered to create a separation within the business functions. For example, users who
can only run reports would belong to MicroStrategy Web Reporter group, while users who can create an ad-hoc report would belong to
MicroStrategy Web Analyst group.
 All the ACLs and updates to users/groups can be controlled via Command Manager scripts to make bulk operations easy rather than
setting permissions manually through MicroStrategy's admin UI.
 MicroStrategy admin manual has a section on setting up user security and provides details of the various aspects described above.
8

Improving Warehouse Performance
Performance boost, performance improvements, and performance issues constantly haunt BI architects and BI
developers. Performance issues in a typical BI solution can originate in the data warehouse, BI application, web, or in
the BI tool itself. Reports are the face of a BI application. While the BI team gets all the credit for excellent reports, they
are the first to be blamed for performance issues! As a first step, we need to locate the root of the problem.
Performance can be improved, by tuning the data warehouse objects and the reporting tool components. In this
section, we will walk through some of the techniques applied to the warehouse to boost performance.
eBook
Persistent
Challenge
#3
Solution
When working on performance improvement, define the benchmarks first. Run the tests to determine low performing
reports. MicroStrategy's Enterprise Manager provides a breakup of the time taken for query execution, report
execution, rendering, etc. This specifies whether the focus of tuning should be on the data warehouse or the report
components. Reports where query execution takes a long time, serve as sample reports for tuning the warehouse. An
easy way to do this is to run the query, generated by MicroStrategy, directly on the database. Note that MicroStrategy
generated SQL has multiple passes and DDL for creating temporary tables. You would need appropriate access on the
database.
Design of the warehouse, modeling techniques, breaking data into multiple data marts, and other such factors affect
database performance. In this section we discuss some solutions, assuming, the data warehouse architecture and
model are already in place.
Examine the following elements:
 Aggregation layer: Ensure that the reporting query is getting data from the aggregated table. The data in
the fact table can be stored at the lowest granularity and data required on the reports should be at higher
granularity. It is important to ensure that the required summarization layer is available in the data
9

warehouse. For example, the click stream data is available at granularity up to seconds.However, most of the reports need data only at the
daily granularity level and above. The fact table should have pre-aggregated data for such levels. MicroStrategy's aggregate awareness
functionality can be leveraged to shift from fact to fact in a report at the required granularity.
 Archival strategy: Is there an archival strategy in place for the warehouse? If not, it makes sense to develop one. Large amount of queried
data or dormant data will definitely affect the performance of reports.
 Data mart maintenance-index rebuilds and update of statistics: Data is regularly added to the warehouse. Based on the frequency of
changes, statistics should be updated and indexes should be rebuilt to provide optimum performance. Analyze the commonly used filters for
reports and create corresponding indexes.
 Analyze SQL and query execution plans: Indexes that are not in place and those that have too many columns can cause slowdowns. Get
SQL passes from MicroStrategy for the slow reports and check the execution plan. Come up with an indexing strategy if the existing one does
not seem to work.
 Create materialized views: Some
views in the warehouse may have
complex logic and thereby a
complex query in the background,
causing slowdown. It makes sense
to replace such views with
materialized views, based on which
database technology is being used.
Incremental refresh of materialized
views will improve the performance.
When your BI solutions need to
work with multiple databases,
materialized views may not be
supported across all the
technologies. Complex views can be
persisted as tables, which will need
some ETL work as depicted in
Figure 6:
Warehouse tables Metadata model Reports
Warehouse tables
Materialized views or
persisted tables Metadata model Reports
Figure 6. Creating Views under Reports-Before and After Scenarios
10
eBook

Improving Report Performance
If tests indicate that the data warehouse is fairly well tuned and the reporting layer needs to be worked on to address
performance issues, you will find a solution to the major causes in this section.
eBook
Persistent
Challenge
#4
Solution
Keeping tabs on how the SQL is generated at the time of report development is a good practice. SQL generated by
MicroStrategy may have too many SQL passes or heavy SQL passes, in turn affecting the performance. MicroStrategy
enables tweaking SQL generation through VLDB properties among few other things that can be done to boost the
performance. Let’s go through these techniques in brief:
 VLDB properties: These properties control the behavior of MicroStrategy. These settings can be done at the
database instance level, attribute level, or report level. For example, by setting an appropriate option in the
VLDB property called 'Cartesian Join Warning ' you can disallow MicroStrategy to stop executing SQL with
cross joins. You can also direct MicroStrategy to stop the execution if a warehouse table is involved in cross
joins (only if the temporary tables are not involved). This way you can avoid situations where huge fact tables
get cross joined with dimensions such as Date.
 Report as a Filter: A report may be pulling data from joins across huge dimensions. For example, selecting
a set of products from complex product hierarchy tables may take a long time. For every SQL pass that
MicroStrategy creates, large dimensions and the joins between them get involved. If dimensions parsing can
be done once to store the results set into a temporary table, the temporary table then can be used in all the
remaining passes. As depicted in Figure 7, report as a filter provides a way to use the dataset of the report,
as a qualification inside another report.
11

 iCubes: iCubes or Intelligent Cubes are objects that provide pre-cached data which can be queried on the reports.
Rather than returning data from the warehouse, if it is placed in the memory (pre-cached), so the results are returned
quickly. The reports accessing iCubes can use all of the OLAP Service features for analysis and reporting purposes. If you
want to generate reports, fetching huge data multiple times, iCubes can be beneficial. The cube leverages both memory
and a file on the disk, so data is quickly reloaded into memory when required. iCubes, however, has some limitations
and thereby needs to be used judiciously based on the need.
 Aggregate Awareness: Most of the data warehouses provide aggregated layer of fact tables. For example, the sales
can be stored at an hourly level and at the daily level, as fact_productsales_hourly at the granularity level of hours and
fact_productsales_daily at the granularity level of days. Both the facts have exactly same columns, except for the
column that indicates time of sales. When a report is pulled to show the daily sales, MicroStrategy will pull information
from the fact_productsales_daily and when an hourly sales report is generated, it will pull data appropriately from the
fact_productsales_hourly table. MicroStrategy is aggregate aware and it will choose the best table to run the report
from and we can use this wonderful feature for optimal performance.
 Metadata partitioning: In MicroStrategy, you can build metadata that provides a way for MicroStrategy to choose a
table for the query. This provides a more flexible way for us to provide partitioning than just basing on database
partitioned tables.
12
eBook
Persistent
Product
Category 1
Product 1 Product 2
Model 1 Model 1
Model 2
Product
Category 2
Product 1 Product 2
Model 1 Model 1
Model 2
Product table hierarchy is joined in every pass
SQL PASS 1
SQL PASS 2
SQL PASS 3
SQL PASS
SQL PASS 1
SQL PASS 2
SQL PASS 3
Single SQL Pass on the product hierarchy tables
Figure 7 Creating report as a filter

Data Authorization
Data authorization is a means to ensure that the right people get access to the right data. This is a common design
issue for any BI solution and for that matter any data-centric application. Authorization, in a broader sense, includes
access to objects and operations in addition to data. In this section we will limit the scope of discussion to data
authorization.
The authorization module design in a BI tool is tightly
linked with the warehouse model and how data is
organized into that data model. For example, in a
Product Sales application, a user can only see data
for the region that he/she is responsible for. As
showed in Figure 8, users can be responsible for
sales in more than one region. For example, John
should be able to see the sales data for North and
South regions only. Using the BI tool, we built a single
report for sales analysis and the same report would
show the appropriate slice of data, based on which
the user is running the report.
eBook
Persistent
Challenge
#5
User table defining access to regions
User Region
Fact table storing the data for the regions
Product SalesRegion
John
John
Andrew
Sarah
North
South
West
East
North
South
West
East
40
20
30
30
Figure 8. Tables providing authorization data
13

Solution
As showed in Figure 8, the warehouse model has a user dimension, which stores the regions that users are authorized for. This table stores the information
on data access restriction. After the user is authenticated, we can use MicroStrategy's system prompt for user ID in a security filter. The security filter
appends a WHERE clause to every SQL that MicroStrategy generates. This implements a simple authorization framework and is depicted in Figure 9:
 User logs into MicroStrategy
 User is identified and the system prompt is answered with the User ID
 The metadata relationship between the user
and regions is used to initialize the security
filter
 This security filter is applied to every query that
MicroStrategy generates
 Security filter restricts the joins to only those
regions that the logged-in user is allowed
access to
One of the issues that can come up is multi-path joins
in MicroStrategy that can prohibit the security filter
from getting applied. This can occur when there are
ambiguous paths from the authorization table to the
fact table. Ambiguous paths should be avoided.
User
Login
Data
Access
Table
Fact
User
authenticated
User authorized to access
only certain data
WHERE Fact.region = DataAccessTable.region
MicroStrategy features used:
 System prompt
 Security filter
 Metadata Relationships
Figure 9. Implementing data authorization
14
eBook

eBook
Persistent
Challenge
#6Time Series Analysis in MicroStrategy
Analysis of numbers along the time dimension is a commonly found pattern in the reports, for example:
 Month-on-month comparison of product revenue for the current year
 Typical TY/LY analysis (This Year v/s Last Year) for product sales
The number of time periods used in a particular domain and the unit of time periods may vary from business to
business. Some businesses may use conventional time periods and may limit analysis to a fixed set of time periods
such as Last Year, Last Week, This Year, This Week, etc. Some businesses use custom time periods to suit their
requirements. MicroStrategy provides various ways to implement these time periods on the metadata for time-based
trend analysis.
Figure 10. TY / LY Comparison of Product Sales
15

Solution
MicroStrategy provides transformations-schema objects that map to a specified time period-which can be used to implement features such as, Year-
To-Date (YTD) and the like. The transformation object is applied to a metric called a Transformation Metric. Without using transformations, to
calculate product sales for a year, the Product-Sales metric can be used with a filter for that particular year. With transformations, it becomes more
intuitive.
Transformations can be table based or expression based in MicroStrategy. In the table-based approach, the lookup tables or the corresponding
dimension tables need to have fields with corresponding linkages to define the last year with respect to the current year. However, this creates the
need for managing the warehouse tables. In case of expression-based transformation, an expression or formula is involved to compute the 'previous
year' or 'previous week' calculations. This lessens the pain of data warehouse maintenance; however, it increases the burden at the time of report
execution, as the system needs to compute the results.
If there are multiple time periods in the business and time periods are continuously added
or updated, transformation would be an expensive solution. An alternative to using
transformation is to create time periods in a database table and provide filters for reports
in MicroStrategy. Another way would be to create filters for various time periods within
MicroStrategy itself and make no changes in the data warehouse. These filters can be
maintained by a background command manager script that can update the filter values
before running the reports. For these solutions metadata modeling needs to complete
such that end users can easily select the required time period for the report.
16
eBook

eBook
Persistent
Challenge
#7Ad-hoc Report Creation via Guided Process
It is important to empower business users to create their own reports. Dependence on the technical team for every
trivial analytical need is often not desirable. The metadata objects layer in MicroStrategy, provides a wonderful way to
make business objects available to the users for drag-and-drop ad-hoc reporting. However, while creating ad-hoc
reports, there are chances that users might choose the wrong combination of objects on their ad-hoc reports, causing
system instability. With a wizard-guided report development process users can draw an accurate ad-hoc report.
Solution
An ad-hoc report is developed around a specific subject area associated with a fact. For example, a user might want to
analyze the sales of a product. For this, he/she needs metrics from sales facts and various attributes, such as product
name, category, and month from the dimensions around that fact. In such cases, providing only relevant set of objects
to the user is a better option than providing access to a whole set of objects such as inventory, order related objects,
and others. In addition, users who are not very tech-savvy may need a guided process for report development.
MicroStrategy provides a feature called 'Object Prompts', that enables you to add objects to your report. We can
create a 'prompted report' that prompts users to add filters, attributes, metrics, prompts and other such objects. We can
control objects that are provided for selection and restrict them to only a particular business function or a subset of
business functions, giving a focused approach to the users. The developer needs to:
1. Create separate folders for each function and provide navigation to create ad-hoc reports.
2. Create Search Objects to get references of all objects, related to that business function. This way you
ensure that any modifications made to the respective objects are included in the Object Prompt list when
the report is executed next time.
17

3. Create separate Search Objects for each class of objects (metrics, attribute, filters, etc.) in that business function.
4. Create a prompted report or template using the above prompts and make it available only to the authorized user group.
Using this approach, developers can enforce selection of mandatory objects on reports. This approach helps users to select the required objects through
a controlled process. The objects included in any ad-hoc report created by this process will be related to one function or a sub-function for analysis.
Developers can add critical prompts (e.g. date) to ensure that the ad-hoc report restricts the amount of data generated, thereby reducing load on the
system. ACLs can be applied on the template to restrict accessibility to authorized users only. This technique boosts user productivity and reduces system
instability.
18
eBook

eBook
Persistent
Challenge
#8Metadata Development in a Distributed
Environment
Too many cooks spoil the broth! Large project teams are geographically distributed and many times they deal with
large amounts of metadata. Various modules are developed simultaneously and it is a challenge to ensure that
metadata objects from one module do not conict with those of another module and corrupt relationships.
Developing a MicroStrategy metadata model is similar to developing a dimensional data model. In this section, we
discuss best practices to deal with distributed metadata development.
Issues that can come up at the time of distributed development are:
 Same object being modified at more than one location: In this case a conict will occur at the time of
merging objects. Conict resolution process will get rid of one set of objects and in the process it may end up
removing some essential metadata relationships.
 Same new object being added to the metadata from two sources: For example, team A adds attributes
related to an Employee and team B adds attributes related to that Employee, from two different locations. In
this situation, MicroStrategy will create two sets of attributes for the Employee in the same metadata.
Solution
Development teams should use a well-defined process, along with the right tools for effective multi-site development.
Unfortunately, MicroStrategy does not provide enough support for versioning. Therefore, versioning needs to be
managed manually. This can be done using 'packages' in MicroStrategy. Packages are binary files that contain
metadata objects and can be created using the Object Manager component in MicroStrategy.
19

We would suggest the following for version control:
 Decide and develop confirmed dimensions: These are base dimensions for the project and it is crucial to define
dimensions for objects to be developed. In situations, where two different teams use the same underlying tables
to create metadata objects for separate server instances, MicroStrategy does not flag them as egregious. Such
instances can lead to erroneous and confusing models. Follow strict discipline for conformed dimensions, do not
allow changes to objects without a build manager's approval.
 Define teams for metadata object mapping: The team assigned to
a metadata object owns that object, implying, when there are
merge conflicts their copy is marked as the master copy.
 Nominate a release manager per team: This manager should
maintain integrity of the builds for the team.
 Merge early and merge often in the project lifecycle. Do not let the
changes accumulate over a long time.
 Nominate a release management team: This team controls the
master copy of metadata (in the form of Packages) and ensures
integrity of metadata. This team uses a master MicroStrategy
server, as showed in Figure 11. The production builds will be
created on this server and all satellite teams merge their code
here. The Build Management team manages Metadata using
well-defined file naming conventions for version control.
 When new objects are created, it should be communicated to all
teams.
 Automate regression tests and run them after every merge
operation to identify integration problems early on.
Team A
Team BTeam D
Team C
MasterBuild
Machine
20
eBook

eBook
Persistent
Challenge
#9Testing Metadata
Testing reports is a common practice. However, engineers do not target metadata speciﬁc testing. Metadata is very
critical and one inappropriate relation can potentially bring down any report. In case of ad-hoc reporting the
challenges are elevated, as developers do not have control over objects used by business users in their
reports.Therefore, every combination of objects used for reporting should give accurate results. This section discusses
how metadata testing can be done and some of the challenges involved.
Solution
When testing Metadata, create ad-hoc reports (e.g. simple grid reports) for all use cases of a particular subject area.
Each of these reports needs to be manually tested for accuracy. Once manual testing is done, we can leverage
MicroStrategy's Integrity Manager to automate testing of the specific report for future executions. The idea is to keep
this report and its results intact, irrespective of any changes in the metadata. You can create baselines for reports with
different parameters (prompt answers).
Another useful way of tracking metadata changes is to develop MicroStrategy documentation (documentation wizard)
for all the metadata objects. After every set of considerable changes to the metadata, compare the latest
documentation report with the earlier one. All the differences that show up should be explainable and attributable to
the project features being implemented.
21

Some challenges involved in the baseline comparisons done using
Integrity Manager are as follows:
A report may have 'Printed For' displayed, as showed in Figure 12. This field
changes based on who runs the test suite and the Integrity Manager will flag
an error each time. In the test-automation environment, a command
manager script can be used to change the value of an object before the tests
are run.
Sales Report
Year
Printed for - John
2008
2008
2008
2008
2008
2008
2008
2008
2008
2008
2008
2008
Region
Central
Mid-Atlantic
Northeast
Northwest
South
Southeast
Southwest
Web
Total
Average
Minimum
Maximum
Units Sold
10,425
9,405
18,456
3,853
11,703
4,905
8,363
3,992
71,102
8,888
3,653
18,456
(User name may change)
Figure 12 Date eld that changes every day
22
eBook

eBook
Persistent
Challenge
#10Handling Updates of OEM Applications
ISVs include MicroStrategy as a part of their product. Customers usually request for rights to customize/modify
metadata to some extent such that alterations in metadata are reected in the latest product releases. The design
challenge is to make provisions to accommodate for any customization in subsequent results. A design process needs
to be followed to eliminate conicts that can prove to be detrimental for the product. A combination of stringent
processes and BI application design need to be in place to handle custom metadata effectively.
Solution
In MicroStrategy the Administrator has full access to metadata objects and can change any part of the metadata. As a
first step, it is important for ISVs to define a list of data that can be customized by the customer.
Company releases
Product Ver I
Company releases
Product Ver II
Customer buys Product Ver I
Customer customizes Ver I
Ver I - A
Customer wants to buy Product Ver II
Ver II B = Ver I A + Ver II
Figure 13. Releases and custom metadata
23

Metadata is similar to a data warehouse model, so care needs to be taken when
modifying it. Certain objects cannot be changed at all, for example, metadata
relationship between the USER attribute and data access related attributes. Schema
objects defined in the metadata form the layer that is closest to the warehouse columns
and any changes to these objects can affect the functioning of the BI application
drastically. Therefore, it is important for ISVs to document use cases, rules, and
guidelines for customization.
For new releases of the product, conflict resolution rules need to be defined for all objects
to appropriately change, overwrite, or duplicate metadata objects at the time of new
production release.
If it is essential for customers to change properties of metadata objects, it is advisable to
make copies of the objects involved and make changes on these copies, rather than on
the original objects. This ensures that changes are not overwritten when a new version of
the product is installed, and these changes are implemented after the installation is
complete. This is a clean way of handling such exceptional changes.
MicroStrategy's Installation and Configuration guide provides good level of detail
deployment of OEM applications.
24
eBook

eBook
Persistent
Conclusion
We discussed various techniques to improve report building, system performance, and user productivity with
MicroStrategy in this eBook. Some of the important points discussed can be summarized as:
 Metadata modeling is a complex task, so set aside sufficient time for this activity. Any mistake at this stage turns
out to be very expensive to fix down the line. With MicroStrategy it is of utmost importance that metadata
relationships be clearly chalked out.
 Eliminate ambiguity in object selection path. Multi-join paths lead to inappropriate SQL statements. This can
lead to serious consequences such as authorization failure or unauthorized access, in addition to performance
complications.
 Metadata testing should start much before actual reports are built, so incorporate ad-hoc reports as part of the
development and testing cycles.
 MicroStrategy does not provide adequate versioning abilities, as part of the development environment.
Therefore, when developing a complex project, teams should plan on supplementing this inadequacy by using
other version control methods.
 Overall, MicroStrategy addresses complexities of building products around Business Intelligence and Analytics.
When working with MicroStrategy, consider its features and limitations right from the design phase. Use every
opportunity to make changes on the warehouse side, in order to have a better BI solution. If you have worked on
MicroStrategy and faced problems, other than the ones discussed in this eBook, we would like to hear from you and
know your approach towards solving them.
25

eBook
Persistent
About Persistent Systems
Established in 1990, Persistent Systems (BSE & NSE: PERSISTENT) is a global company specializing in software product and technology services. For more
than two decades, Persistent has been an innovation partner for the world's largest technology brands, leading enterprises and pioneering start-ups. With a
global team of more than 6,000 employees, Persistent has 300 customers spread across North America, Europe, and Asia. Today, Persistent focuses on
developing best-in-class solutions in four key next-generation technology areas: Cloud Computing, Mobility, Analytics and Collaboration, for
telecommunications, life sciences, consumer packaged goods, banking & financial services and healthcare verticals. For more information, please visit:
www.persistentsys.com.
India
Persistent Systems Ltd.
Bhageerath, 402,
Senapati Bapat Road
Pune 411016
Tel: +91 (20) 2570 2000
Fax: +91 (20) 2567 8901
USA
Persistent Systems, Inc.
2055 Laurelwood Road, Suite 210
Santa Clara, CA 95054
Tel: +1 (408) 216 7010
Fax: +1 (408) 451 9177
Email: info@persistentsys.com
26

MicroStrategy Design Challenges - Tips and Best Practices

Recommended

More Related Content

What's hot (20)

Viewers also liked (18)

Similar to MicroStrategy Design Challenges - Tips and Best Practices (20)

More from BiBoard.Org (16)

Recently uploaded (20)

MicroStrategy Design Challenges - Tips and Best Practices