Internationalization Design Technics

Microstrategy Internationalization Design Technics

MicroStrategy supports data internationalization through two different techniques. You can either provide translated data through the use of extra tables and columns, or you can provide separate databases to store your translated data. These techniques are described below:

You can support data internationalization in your database by using separate tables and columns to store your translated data. You can use various combinations of tables and columns to support and identify the translated data in your database.

To support displaying the name of each month in multiple languages, you can include the translated names in a separate column, one for each required language, within the same table. Each column can use a suffix to identify that the column contains translated data for a certain language. The same LU_MONTH_OF_YEAR table with translated data for the Spanish and German languages is shown below:

The data for Spanish is included in a MONTH_OF_YEAR_NAME column with the suffix _ES, and the data for German is included in a MONTH_OF_YEAR_NAME column with the suffix _DE.
As an alternative to supplying translations by using separate columns in the same table, you can create separate tables for your translations. Each table can share the same column name for the same data in different languages. In the tables below, the Spanish and German data is provided in separate Spanish and German tables:

The data for Spanish is included in a LU_MONTH_OF_YEAR table with the suffix _ES, but the MONTH_OF_YEAR column shares the same column name as in the English LU_MONTH_OF_YEAR table. The data for German uses the same technique and is stored in a LU_MONTH_OF_YEAR table with the suffix _DE.
You can also use both techniques (separate tables and extra columns in one table) to store and identify your translated data. This can be helpful to distinguish the language used for each table and column. It can also be helpful if you have a primary language stored in one table, and you store all internationalizations in an internationalization table. For example, you can store the Spanish and German data in the same internationalization table, as shown below:

In this scenario, the LU_MONTH_OF_YEAR_LANG table includes all translations in all languages other than the primary language, for the MONTH_OF_YEAR_NAME column. Each column is assigned a suffix to identify the language of the translated data.

•

In the examples above, suffixes on tables and columns are used to identify the language of the translated data. While it is not a requirement to use suffixes for these identification purposes, it is the easiest method to define and support in MicroStrategy. Using prefixes or other naming conventions requires you to use some functions to recognize the location of the translated data.

•

If your project supports data internationalization, you cannot use logical views as lookup tables for attributes that use translated data.

Using separate databases for internationalization

You can support data internationalization in your database by using separate databases for each supported language. A user can then be granted access, through connection mappings, to the database that contains their preferred language.
For example, the MicroStrategy Tutorial project includes a Month of Year attribute which retrieves its primary information in English from the LU_MONTH_OF_YEAR table shown below:

For the purposes of this example, you can assume this data is stored in a database named Tutorial (English). You also provide your projects in Spanish and German, which means you must have a database for Spanish and a database for German. Each database contains the same table structure, column structure, and naming conventions, but includes translated data, as shown below:

This method of data internationalization requires that the same data is available in each internationalized database.

Comments

URL API connection mode parameters

URL API connection mode parameters When using the URL API, to denote which type of Authentication to use, developers can use the connMode parameter. The following values are used for this parameter: Standard = 1 LDAP Authentication = 16 Database Authentication = 32 Guest = 8 Windows Authentication = 2 Trusted Authentication = 64 Integrated Authentication = 128

Level metrics in Microstartegy/MSTR

Level Metrics Level metrics allows the users to choose the right combination of level target, filtering, and grouping (referred to as elements) to achieve your desired results. The elements of a metric level are described below: • Target : The target is the attribute level at which the metric calculation groups. For a more detailed description, see Target: The context of a calculation . • Grouping : Grouping determines how the metric aggregates. For a more detailed description, see Grouping: How aggregation is performed . • Filtering : Filtering governs how the report filter interacts with the metric calculation. For a more detailed description, see Filtering: Interaction with report filters . The level is indicated between the curly braces ({ }) in the metric definition shown below: Sum(Revenue) {~, Product} The tilde (~) represents the report level with standard filtering, denoted by the plus sign (+). If you add item as a level, th...

Create a transaction services photo uploader

Create a transaction services photo uploader 1. Create a new table "photo_upload" in Tutorial warehouse database (the default location: C:\Program Files\MicroStrategy\Tutorial Reporting\TUTORIAL_DATA_7200.mdb), as shown below: 2. The 'photo_upload' table has to be pre-populated with *exactly* 10 rows of data, the values for the 'ID' column should be 1-10 and the values for the 'uploaded' column should all be 0 3. In MicroStrategy Desktop, create a freeform report "R1" based on the new table "photo_upload" in Tutorial data created at step 1, as shown below: SELECT Location, Description, ID, uploaded, numbers FROM PHOTO_UPLOAD 4. Create another table for transaction insert SQL. Make sure to create an 'autonumber' type ID as primary key for this table, or auto_increment ID for different DBs. 5. Create...

Case functions Microstrategy

Ca se functions Microstrategy Case functions return specified data in a SQL query based on the evaluation of user-defined conditions. In general, a user specifies a list of conditions and corresponding return values. Case This function evaluates multiple expressions until a condition is determined to be true, then returns a corresponding value. If all conditions are false, a default value is returned. Case can be used for categorizing data based on multiple conditions. This is a single-value function. Syntax Case ( Condition1 , ReturnValue1 , Condition2 , ReturnValue2 ,..., DefaultValue ) Example Case(([Total Revenue] < 300000), 0, ([Total Revenue] < 600000), 1, 2) sum(Case (Day@DESC in (“Sat”,”Sun”), Sales, 0) {~+} Sum(Case(Category@DESC In("Books","Electronics"),Revenue,0)){~+} CaseV (case vector) CaseV evaluates a single metric and returns different values according to the results. It can be used to perfo...

MicroStrategy URL API Parameters

MicroStrategy URL Structure The following table summarizes the root URL structure used for every request to MicroStrategy Web. Environment Main Application URL Administration URL J2EE http://webserver/MicroStrategy/servlet/mstrWeb http://webserver/MicroStrategy/servlet/mstrWebAdmin .NET http://webserver/MicroStrategy/asp/Main.aspx http://webserver/MicroStrategy/asp/Admin.aspx Every request sent to MicroStrategy Web calls a central controller. Parameters are appended to Main.aspx or mstrWeb (in a .NET and J2EE environment, respectively) to indicate to the controller how the request should be internally forwarded and handled. The following examples show a URL for accessing a MicroStrategy folder when the user does not have an existing session. The URL contains not only the parameters needed to connect to MicroStrategy Web, but also the parameters needed to log on and create a session. J2EE environment: <a href="http:...

Microstrategy Removing sections that do not have metric data

Removing sections that do not have metric data This is an interesting feature which might not be explored by many of us and it comes us handy. A cross join between datasets can result in rows or Group Header/Footer sections that do not have metric data. For example, a document contains two datasets. Dataset 1 contains Year and Revenue, with data for three years (2007-2009). Dataset 2 contains Year and Profit, filtered to return data for only two years (2008 and 2009). If you place Year and Profit in the Details and execute the document, it displays three rows, although no profit data exists for 2007. This is a product of the cross join between the two datasets. You do not want to see the blank line for 2007 since it does not give you any data for profit. You can select the Trim sections for which no metric value data is available check box. This removes the row for 2007, since no metric data for Profit is available for 2007. The results are shown below: ...

Configure Connection Mapping in Microstrategy

Configure Connection Mapping in Microstrategy The following steps demonstrate the second scenario where two different data warehouses are used within the same project: Create two different database connections - One that points to the data warehouse for the European users and the other that points to the data warehouse for USA users as shown below: Select Europe as the default database connection for the database Instance as seen below: Go to P...

Microstrategy Custom number formatting symbols

Custom number formatting symbols If none of the built-in number formats meet your needs, you can create your own custom format in the Number tab of the Format Cells dialog box. Select Custom as the Category and create the format using the number format symbols listed in the table below. Each custom format can have up to four optional sections, one each for: Positive numbers Negative numbers Zeros Text Each section is optional. Separate the sections by semicolons, as shown in the example below: #,###;(#,###);0;"Error: Entry must be numeric" For more examples, see Custom number formatting examples . To jump to a section of the formatting symbol table, click one of the following: Numeric symbols Character/text symbols Date and time symbols Text color symbols Currency symbols Conditional symbols Numeric symbols For details on how numeric symbols apply to the Big Decimal data type, refer to the Project Design Guide . ...

MicroStrategy Hadoop Gateway operation modes

MicroStrategy Hadoop Gateway operation modes MicroStrategy Hadoop Gateway is a native connector which was built based on Spark 1.6.x. You can choose one or more data files from Hadoop HDFS and load them into MicroStrategy Intelligence Server. Data files can be published as either an In-Memory Cube or a Live Connect Cube. MicroStrategy Hadoop Gateway supports three operation modes : YARN client Standalone (HDP cluster does not support Standalone) Local YARN client mode: The driver runs in the client process, and the application master is only used for requesting resources from YARN. Running in this mode requires YARN service to be enabled on your Hadoop cluster. Standalone mode: MicroStrategy Hadoop Gateway uses Spark Master to coordinate data processing. Local mode: no application is deployed in the Spark nodes. All data processing is executed in the MicroStrategy Hadoop Gateway host. This modality is intended for testing and troubleshooting.

Types of filters in Microstrategy

Types of filters in Microstrategy Below are the types of filters: 1. Attribute qualification filter These types of qualifications restrict data related to attributes on the report. a) Attribute form qualification Filters data related to a business attribute’s form(s), such as ID or description. • For example, the attribute Customer has the forms ID, First Name, Last Name, Address, and Birth Date. An attribute form qualification might filter on the form Last Name, the operator Begins With, and the letter H. The results show a list of customers whose last names start with the letter H. b) Attribute element list qualification Filters data related to a business attribute’s elements, such as New York, Washington, and San Francisco, which are elements of the attribute City. • For example, the attribute Customer has the elements John Smith, Jane Doe, William Hill, and so on. An attribute element list qualification can filter data to display only those customer...

Microstrategy Analytics

Search This Blog