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

Conte

nts

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 PrimerMicroStrategy 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.

eBookPersistent

© 2013 Persistent Systems Ltd. All rights reserved.

3

10 MicroStrategy Design Challenges

Developing Multi-language ReportsBI 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.

eBookPersistent


Ch

alleng

e

SolutionCommon 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


eBookPersistent

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

eBookPersistent10 MicroStrategy Design Challenges

Developing Metadata for Various Business FunctionsEnterprises 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.

eBookPersistent

SolutionEven 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.

Ch

alleng

e#2

BI Solution

selaS

Inventory


7


eBookPersistent

The following pointers can help when using a single metadata database:

Identify the common and specific 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, specific 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 PerformancePerformance 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.

eBookPersistent

Ch

alleng

e#3

SolutionWhen 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 tablesMaterialized views or

persisted tables Metadata model Reports

Figure 6. Creating Views under Reports-Before and After Scenarios


10


Improving Report PerformanceIf 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.

eBookPersistent

Ch

alleng

e#4

SolutionKeeping 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

eBookPersistent

ProductCategory 1

Product 1 Product 2

Model 1 Model 1

Model 2

ProductCategory 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 AuthorizationData 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.

eBookPersistent

Ch

alleng

e#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


SolutionAs 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.

UserLogin

DataAccessTable

Fact

Userauthenticated

User authorized to accessonly certain data

WHERE Fact.region = DataAccessTable.region

MicroStrategy features used: System prompt Security filter Metadata Relationships

Figure 9. Implementing data authorization


14


eBookPersistent

Ch

alleng

e#6

Time Series Analysis in MicroStrategyAnalysis 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


SolutionMicroStrategy 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


eBookPersistent

Ch

alleng

e#7

Ad-hoc Report Creation via Guided ProcessIt 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.

SolutionAn 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


eBookPersistent

Ch

alleng

e#8

Metadata Development in a Distributed EnvironmentToo 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 conict 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 conict will occur at the time of

merging objects. Conict 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.

SolutionDevelopment 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

MasterBuildMachine


20


eBookPersistent

Ch

alleng

e#9

Testing Metadata Testing reports is a common practice. However, engineers do not target metadata specific 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.

SolutionWhen 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


eBookPersistent

Ch

alleng

e#10

Handling Updates of OEM ApplicationsISVs 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 reected 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 conicts 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.

SolutionIn 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


eBookPersistent


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


eBookPersistent

About Persistent SystemsEstablished 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: [email protected]


26


http://blog.persistentsys.com/

http://www.facebook.com/PersistentSystems

http://www.linkedin.com/company/5034?trk=tyah

https://twitter.com/#!/Persistentsys

http://www.youtube.com/user/persistentsys

MicroStrategy Design Challenges - Tips and Best Practices

Software

Transcript of MicroStrategy Design Challenges - Tips and Best Practices