Creating and modifying multiple attributes

With Architect, you can create and modify multiple attributes in your project quickly from an integrated interface. Architect allows you to create and modify attributes in most of the same ways as the Attribute Editor.

For conceptual information on attributes as well as detailed examples, see The Context of Your Business Data: Attributes. Refer to the list below for steps to perform various attribute definitions using Architect:

• Modifying attributes with the Properties pane

• Creating attribute form expressions

• Creating and modifying attribute data types: Column aliases

• Creating attributes with multiple ID columns: Compound attributes

• Modifying how to use attributes to browse and report on data

• Specifying attribute roles: Attributes that use the same lookup

• Supporting data internationalization for attribute elements

Modifying attributes with the Properties pane

Once attributes are created, you can modify and view attribute definitions using the Properties pane in Architect. To view the various properties of an attribute in Architect, from the Attributes tab of the Properties pane, select the attribute from the drop-down list. The Category attribute of the MicroStrategy Tutorial project shown below is used as an example of how you can modify and view attributes using Architect.

When selecting an attribute in Architect, the Properties pane allows you to modify and view attributes as described below.

You can select a property in the Properties pane to view a description of the property. The description is displayed at the bottom of the Properties pane.

• Defining and viewing attribute definitions: Definition section

• Modifying attribute forms: Forms sections

Defining and viewing attribute definitions: Definition section

When you select an attribute in Architect, the Definition section of the Properties pane displays the various properties for the attribute. These properties and how to use them are described below:

• ID: The identifier of the attribute. You cannot modify this value.

• Name: The name of the attribute in a MicroStrategy project.

• Description: The description of the attribute. A description can help explain the purpose of an attribute in a project.

• Hidden: Specifies whether the attribute is defined as hidden. Select the check box to set the value to True, which defines the table as hidden.

  Objects that are hidden are not displayed to a user unless the user has changed his or her Developer Preferences and selected the Display hidden objects check box. Therefore, defining an object as hidden does not necessarily prevent users from viewing or accessing an object. The best way to prevent users from viewing or accessing an object is to restrict the user permissions for it.

• Location: The location of the attribute in a project.

• Lock Type: Specifies how you can browse attribute elements within the System Hierarchy in the Data Explorer. You have the following options:

  • Locked: No elements of the attribute are shown within the System Hierarchy in the Data Explorer. For example, if the attribute Year is locked, no elements for Year display in the Data Explorer when Year is expanded from the System Hierarchy.

  • Unlocked: All elements of the attribute are shown within the System Hierarchy in the Data Explorer. For example, if the attribute Year is unlocked, all elements of Year (such as 2005, 2006, and 2007) display in the Data Explorer when Year is expanded from the System Hierarchy.

  • Limit: Incrementally retrieves the number of elements set for the attribute. For example, if the limit for the attribute Year is set to one, the years 2005, 2006, and 2007 are retrieved one-by-one as they are requested.

• Lock Limit: If you choose the Limit lock type above, you can define the number of elements to incrementally retrieve and display within the System Hierarchy in the Data Explorer.

• Apply Security Filters: Enables and disables the use of security filters in element requests. This setting also applies to the use of security filters for creating an element cache.

  This setting covers situations where only certain attributes need the security filters for element requests. For example, if you have an external-facing data warehouse for your suppliers, security filters can be used on attributes in the product dimension so one supplier cannot see another supplier's products. However, since security is not necessary on attributes in the Time dimension, security filters do not need to be applied and the element cache can be shared.

• Enable Element Caching: Enables and disables element caching at the attribute level. By caching the elements of an attribute, the elements are returned quickly from a cache when browsing the attribute elements. This is particularly helpful for attributes that rarely or never have a modification to the elements available for the attribute. The volatility of the elements within different attributes can fluctuate greatly. For example, the Order Number attribute may have elements that change once a day (depending on the warehouse load), while the Product Number attribute may only have elements that change once a week or once a month.

Modifying attribute forms: Forms sections

When you select an attribute in Architect, the Forms sections of the Properties pane display information about the attribute forms for the attribute. The properties for attribute forms and how to use them are described below:

• Attribute form category: The first property for an attribute form reflects the category used for the attribute form. In the example shown above in Modifying attributes with the Properties pane, ID is displayed as the first property. You can select the attribute form property and click the ... button to modify the attribute form.

  If the attribute form uses a form group to combine multiple attribute forms, you can modify the separate attribute forms that are included in the form group. For information on creating form groups in Architect, see Creating attributes with multiple ID columns: Compound attributes.

• Name: The name of the attribute form in a MicroStrategy project.

• Geographical Role: Defines how the attribute form can be used as geographical data with various MicroStrategy mapping features. When using Data Import, this type of geographical information can be automatically detected. For details on how Data Import is able to assign geographical roles to your data, see Strategies to include supplemental data in a project.

• Shape File: Defines the shapes used to display the attribute form on various MicroStrategy mapping features.

• Category: The category used for the attribute form, which can help group or identify attribute forms. From the drop-down list, select the category to use for the attribute form. For information on how the category helps group attribute forms, see Attribute form expressions.

• Format: The format of the attribute form, which controls how the form is displayed and how filters are defined. From the drop-down list, select the format to use for the attribute form. For information on the format of attribute forms, see Attribute form expressions.

• Report Sort: Defines the default sort order of the attribute form when it is included in a report. From the drop-down list, you can choose from Ascending, Descending, or None. For information on how attribute forms are sorted when multiple attribute forms of a single attribute define a default sort order, see Displaying forms: Attribute form properties.

• Browse Sort: Defines the default sort order of the attribute form when it is viewed in the Data Explorer. From the drop-down list, you can choose from Ascending, Descending, or None. The Data Explorer is discussed in Hierarchy browsing.

• Use as Browse Form: Defines whether the attribute form can be displayed in the Data Explorer. To allow an attribute form to be displayed in the Data Explorer, select the check box to set the value to True. The Data Explorer is discussed in Hierarchy browsing.

• Use as Report Form: Defines whether the attribute form is displayed on reports by default. To define an attribute form to be displayed on reports by default, select the check box to set the value to True.

• Supports Multiple Languages: Defines whether the attribute form's information can be displayed in multiple languages using data internationalization. To define an attribute form to allow data to be displayed in multiple languages, select True.

  Enabling data internationalization for an attribute form is described in Supporting data internationalization for attribute elements.

  The ID form of an attribute does not have this option as these forms are used strictly for identification purposes.

• Column Alias: The column alias of the attribute form, which allows you to define a new data type that you can use in place of the default data type for a given attribute form. You can select the Column Alias property and click the ... button to modify the attribute form's column alias. For information on column aliases for attribute forms, see Modifying attribute data types: Column aliases.

• Attribute Expressions: The expressions used for the attribute form. You can select an attribute expression and click the ... button to modify the attribute form expression.

Creating attribute form expressions

An attribute expression represents a mapping to specific attribute information in the data source. For conceptual information on attribute forms and attribute form expressions, see Column data descriptions and identifiers: Attribute forms and Attribute form expressions.

Attribute form expressions are commonly created by mapping a column to an attribute form, as described in Creating attributes. With Architect, you can also create and define attributes as listed below:

• Creating derived attribute form expressions

• Joining dissimilar column names: Heterogeneous mappings

Creating derived attribute form expressions

Derived expressions are created using a combination of warehouse columns, mathematical operators, functions, and constants. While simple expressions have their value determined by just one column in a warehouse table, derived expressions are defined using one or more columns as well as other operators and values. Any operation on a column (such as adding a constant, adding another column, or setting the expression to be an absolute value) creates a derived expression.

For information on derived attribute form expressions, see Attribute form expressions. The procedure below describes how to create a derived attribute form expression using Architect, and follows the example scenario provided in Attribute form expressions.

To create an attribute form with a derived expression using Architect

1. In MicroStrategy Developer, log in to a project.

   For the example scenario, log in to the MicroStrategy Tutorial project.

2. From the Schema menu, select Architect.

3. If a message is displayed asking if you want to open Architect in read only mode or edit mode, select Edit and click OK to open Architect in edit mode so that you can make changes to the project. MicroStrategy Architect opens.

   If you are only given the option of opening Architect in read only mode, this means another user is modifying the project's schema. You cannot open Architect in edit mode until the other user is finished with their changes and the schema is unlocked.

   For information on how you can use read only mode and edit mode for various schema editors, see Using read only or edit mode for schema editors.

4. From the Project Tables View, locate and select a table that includes a column or columns to use in an attribute definition.

   For the example scenario, select the LU_CUSTOMER table.

5. Right-click the Customer attribute and select New Attribute form. The Create New Form Expression dialog box opens.

6. Double-click the CUST_LAST_NAME column to add it to the Form expression pane on the right.

7. In the Form expression pane, place the cursor to the right of [CUST_LAST_NAME] and type + ", " +.

8. Double-click the CUST_FIRST_NAME column to add it to the Form expression pane on the right. Your expression should be defined as shown below.

   

9. Select Manual as the mapping method.

10. Click OK to return to Architect. The new attribute form is displayed as part of the Customer attribute in the LU_CUSTOMER table.

11. In the Properties pane, locate the new attribute form.

12. In the Name field, type Last Name, First Name.

13. From the Category drop-down list, select None since Last Name, First Name is neither the ID form of Customer nor the primary description form.

14. Because this is only an example, you can close Architect without saving your changes.

Joining dissimilar column names: Heterogeneous mappings

Heterogeneous mapping allows Intelligence Server to perform joins on dissimilar column names. If you define more than one expression for a given form, heterogeneous mapping automatically occurs when tables and column names require it.

For information on heterogeneous mappings for attributes, see Attribute form expressions. The procedure below describes how to create an attribute form with a heterogeneous column mapping using Architect, and follows the example scenario provided in Attribute form expressions.

To create an attribute form with a heterogeneous column mapping using Architect

1. In MicroStrategy Developer, log in to a project.

   For the example scenario, log in to the MicroStrategy Tutorial project.

2. From the Schema menu, select Architect.

3. If a message is displayed asking if you want to open Architect in read only mode or edit mode, select Edit and click OK to open Architect in edit mode so that you can make changes to the project. MicroStrategy Architect opens.

   If you are only given the option of opening Architect in read only mode, this means another user is modifying the project's schema. You cannot open Architect in edit mode until the other user is finished with their changes and the schema is unlocked.

   For information on how you can use read only mode and edit mode for various schema editors, see Using read only or edit mode for schema editors.

4. From the Project Tables View, locate and select a table that includes a column or columns to use in an attribute definition.

   For the example scenario, select the LU_DAY table.

5. Right-click the Customer attribute and select New Attribute form. The Create New Form Expression dialog box opens.

6. Double-click the DAY_DATE column to add it to the Form expression pane on the right.

7. Select Automatic as the mapping method.

8. Click OK to return to Architect. The new attribute form is displayed as part of the Day attribute in the LU_DAY table.

9. Right-click the new attribute form and select Edit. The Modify Attribute Form dialog box opens.

10. Click New. The Create New Form Expression dialog box opens.

11. From the Source table drop-down list, select the ORDER_DETAIL table.

12. Double-click the ORDER_DATE column to add it to the Form expression pane on the right.

13. Select Automatic as the mapping method.

14. Click OK. The Create New Attribute Form dialog box opens.

    Notice that there are now two expressions for the attribute form definition, both of which use different tables as the source of their information. You can continue this process to add as many heterogeneous columns as part of one attribute form as necessary.

15. Click OK to return to Architect.

16. In the Properties pane, locate the new attribute form.

17. In the Name field, type Date Example.

18. From the Category drop-down list, select None since this is an example scenario.

19. Because this is only an example, you can close Architect without saving your changes.

Creating and modifying attribute data types: Column aliases

A column alias is a new data type that you can specify in place of the default data type for a given attribute form. Column aliases allow you to specify a more appropriate data type that can help avoid errors in your SQL. They can also help you take more advantage of the data in your data warehouse.

For information on column aliases for attributes, see Modifying attribute data types: Column aliases. The procedure below describes how to create a column alias using Architect, and follows the example scenario provided in Modifying attribute data types: Column aliases.

Prerequisites

This procedure assumes you have already created an attribute with a valid attribute expression for which to create a new column alias.

To create a column alias for an attribute using Architect

1. In MicroStrategy Developer, log in to a project.

   For the example scenario, log in to the MicroStrategy Tutorial project.

2. From the Schema menu, select Architect.

3. If a message is displayed asking if you want to open Architect in read only mode or edit mode, select Edit and click OK to open Architect in edit mode so that you can make changes to the project. MicroStrategy Architect opens.

   If you are only given the option of opening Architect in read only mode, this means another user is modifying the project's schema. You cannot open Architect in edit mode until the other user is finished with their changes and the schema is unlocked.

   For information on how you can use read only mode and edit mode for various schema editors, see Using read only or edit mode for schema editors.

4. From the Project Tables View, locate and select a table that includes an attribute to create a column alias for.

5. Right-click the attribute form to create a column alias for, and select Edit. The Modify Attribute Form dialog box opens.

6. Select the Column Alias tab.

7. In the Column alias area, click Select. The Column Editor - Column Selection dialog box opens.

8. Select New to create a new column alias. The Column Editor - Definition dialog box opens.

9. You can modify the following properties for the column alias:

   • Column name: The name for the column alias. This name is used in any SQL statements which include the fact column.

   • Data type: The data type for the fact. For a description of the different data types supported by MicroStrategy, see Data Types.

   • Depending on the data type selected, you can specify the byte length, bit length, precision, scale, or time scale for your column alias. For a detailed description on each of these properties, see the MicroStrategy Developer Help (formerly MicroStrategy Desktop Help).

10. Click OK to save your changes and return to the Column Editor - Column Selection dialog box.

11. Click OK to save your changes and return to the Modify Attribute Form dialog box.

12. Click OK to return to Architect.

13. From the Home tab, in the Save area, click Save and Update Schema to save your changes.

Creating attributes with multiple ID columns: Compound attributes

A compound attribute is an attribute with multiple columns specified as the ID column. This implies that more than one ID column is needed to uniquely identify the elements of that attribute. Generally, you build a compound attribute when your logical data model reflects that a compound key relationship is present. In the relational database, a compound key is a primary key that consists of more than one database column.

For information on compound attributes, see Attributes with multiple ID columns: Compound attributes. The procedure below describes how to create a compound attribute using Architect, and follows the example scenario provided in Example: Creating compound attributes.

To create a compound attribute using Architect

1. In MicroStrategy Developer, log in to a project.

   For the example scenario, log in to the MicroStrategy Tutorial project.

2. From the Schema menu, select Architect.

3. If a message is displayed asking if you want to open Architect in read only mode or edit mode, select Edit and click OK to open Architect in edit mode so that you can make changes to the project. MicroStrategy Architect opens.

   If you are only given the option of opening Architect in read only mode, this means another user is modifying the project's schema. You cannot open Architect in edit mode until the other user is finished with their changes and the schema is unlocked.

   For information on how you can use read only mode and edit mode for various schema editors, see Using read only or edit mode for schema editors.

4. From the Project Tables View, locate and select a table that includes the columns to use for a compound attribute.

   For the example scenario, select the LU_DIST_CTR table.

5. Right-click the table and select Create Attribute. The Create New Form Expression dialog box opens.

6. Double-click the COUNTRY_ID column to add it to the Form expression pane on the right.

7. Select Automatic mapping method.

8. Click OK to return to Architect. The new attribute is displayed in the LU_DIST_CTR table.

   To rename the attribute, right-click the attribute and select Rename.

9. In the Properties pane, locate the new attribute form.

10. In the Name field, type ID 1.

11. Right-click the attribute and click New Attribute form to create the other attribute ID form. The Create New Form Expression dialog box opens.

12. Double-click the DIST_CTR_ID column to add it to the Form expression pane on the right.

13. Select Automatic mapping method.

14. Click OK to return to Architect. The new attribute form is displayed in the LU_DIST_CTR table.

    You can change the default name of the fact by right-clicking it in the table and selecting Rename.

15. In the Properties pane, locate the new attribute form.

16. In the Name field, type ID 2.

17. In the Category drop-down list, select ID. A message about creating a form group is displayed.

    You can also create a form group by dragging and dropping one attribute form onto another attribute form for the same attribute.

18. Click Yes to create a form group. The two attribute forms are included in a form group.

    For more information on using form groups to create compound attributes, see Attributes with multiple ID columns: Compound attributes.

19. In the first Name field for the attribute form, type ID.

20. Because this is only an example, you can close Architect without saving your changes.

Modifying how to use attributes to browse and report on data

Once attributes are built, they are used in two primary ways—browsing and reporting. Users browse through attributes to locate an attribute to use on a report, and users place an attribute on a report to display details about the particular attribute and how it relates to fact data. Each attribute can be displayed in a variety of forms so you must specify the default display of each of the attributes in the project. You can do this on a report-by-report basis, but you still must specify the global, or project-wide, default for each attribute.

For information on modifying the attribute forms used for reporting and browsing, see Using attributes to browse and report on data. The procedure below describes how to define attribute form display using Architect. The steps below follow the example scenario provided in Defining how attribute forms are displayed by default.

To display an attribute form in reports and in the Data Explorer using Architect

1. In MicroStrategy Developer, log in to a project.

   For the example scenario, log in to the MicroStrategy Tutorial project.

2. From the Schema menu, select Architect.

3. If a message is displayed asking if you want to open Architect in read only mode or edit mode, select Edit and click OK to open Architect in edit mode so that you can make changes to the project. MicroStrategy Architect opens.

   If you are only given the option of opening Architect in read only mode, this means another user is modifying the project's schema. You cannot open Architect in edit mode until the other user is finished with their changes and the schema is unlocked.

   For information on how you can use read only mode and edit mode for various schema editors, see Using read only or edit mode for schema editors.

4. From the Project Tables View, locate and select a table that includes the attribute to define how its attribute forms are displayed by default.

   For the example scenario, select the LU_DIST_CTR table, which includes the attribute Distribution Center.

5. Select an attribute.

   For the example scenario, select the Distribution Center attribute.

6. In the Properties pane, locate the attribute form.

   For the example scenario, locate the ID 2 attribute form.

7. You can define the following display options:

   • Report Sort: Defines the default sort order of the attribute form when it is included in a report. From the drop-down list, you can choose from Ascending, Descending, or None. For information on how attribute forms are sorted when multiple attribute forms of a single attribute define a default sort order, see Displaying forms: Attribute form properties.

   • Browse Sort: Defines the default sort order of the attribute form when it is viewed in the Data Explorer. From the drop-down list, you can choose from Ascending, Descending, or None. The Data Explorer is discussed in Hierarchy browsing.

   • Use as Browse Form: Defines whether the attribute form can be displayed in the Data Explorer. To allow an attribute form to be displayed in the Data Explorer, select the check box to set the value to True. The Data Explorer is discussed in Hierarchy browsing.

   • Use as Report Form: Defines whether the attribute form is displayed on reports by default. To define an attribute form to be displayed on reports by default, select the check box to set the value to True.

8. You can also define the default sort order for attributes on reports and the Data Explorer. For information on attribute form sorting options, see Displaying forms: Attribute form properties.

9. Because this is only an example, you can close Architect without saving your changes.

Specifying attribute roles: Attributes that use the same lookup

Attribute roles allow you to use the same data to define and support two separate attributes. If you identify that one of your attributes needs to play multiple roles, you must create an attribute in the logical model for each of the roles. This ensures that a report with attributes playing multiple roles returns correct data.

For information on attribute roles, see Attributes that use the same lookup table: Attribute roles. The procedure below describes how to specify attribute roles using explicit table aliasing. The steps below follow the example scenario provided in Specifying attribute roles.

You can also define attribute roles using automatic role recognition, which utilizes MicroStrategy VLDB properties and is described in Specifying attribute roles.

To create attribute roles with explicit table aliasing using Architect

This procedure provides steps to re-create the example of explicit table aliasing described in Specifying attribute roles. The LU_STATE table is not included in the MicroStrategy Tutorial project. However, you can use the same high-level procedure and concepts as guidelines to create attribute roles in your project setup.

1. In MicroStrategy Developer, log in to the project to create attribute roles with explicit table aliasing.

2. From the Schema menu, select Architect.

3. If a message is displayed asking if you want to open Architect in read only mode or edit mode, select Edit and click OK to open Architect in edit mode so that you can make changes to the project. MicroStrategy Architect opens.

   If you are only given the option of opening Architect in read only mode, this means another user is modifying the project's schema. You cannot open Architect in edit mode until the other user is finished with their changes and the schema is unlocked.

   For information on how you can use read only mode and edit mode for various schema editors, see Using read only or edit mode for schema editors.

4. From the Project Tables View, locate and select the LU_STATE table that includes the attribute to define attribute roles for.

5. Right-click the LU_STATE table and select Create Table Alias. An LU_STATE(1) table is created.

6. Right-click LU_STATE(1), select Rename, and type LU_STATE_STORE.

7. Right-click the LU_STATE table and select Create Table Alias. An LU_STATE(1) table is created.

8. Right-click LU_STATE(1), select Rename, and type LU_STATE_VENDOR.

Create the attributes

1. Right-click the LU_STATE_STORE table and select Create Attribute. The Create New Form Expression dialog box opens.

2. In the Available columns pane, double-click STATE_ID, which identifies the attribute role.

3. Select Manual mapping and click OK. You are returned to Architect and the new attribute is created in the LU_STATE_STORE table.

4. Right-click the new attribute, select Rename, and type State Store.

5. Right-click the State Store attribute table and select New Attribute form. The Create New Form Expression dialog box opens.

6. Map any other columns to attribute forms for the State Store attribute. You must make sure to map any State Store attribute forms to columns from the LU_STATE_STORE table.

7. Click OK and save the State Store attribute.

8. Create a Vendor State attribute with the same sub-procedure (Create the attributes) used to create State Store above, except you must use the LU_STATE_VENDOR table instead of the LU_STATE_STORE table.

Supporting data internationalization for attribute elements

MicroStrategy supports the internationalization of your data into the languages required for your users. This allows attribute element data to be displayed in various languages that reflect the user's language preferences.

For information on enabling data internationalization for attribute elements and an example of its benefits, see Supporting data internationalization for attribute elements. The procedure below describes how to enable data internationalization for attribute elements using Architect.

Prerequisites

• The internationalized data must be stored in your data source, as described in Supporting data internationalization.

• The project must enable data internationalization, as described in Enabling data internationalization for a project.

• An attribute has been created.

To enable or disable data internationalization for attribute forms using Architect

1. In Developer, log in to a project.

2. From the Schema menu, select Architect.

3. If a message is displayed asking if you want to open Architect in read only mode or edit mode, select Edit and click OK to open Architect in edit mode so that you can make changes to the project. MicroStrategy Architect opens.

   If you are only given the option of opening Architect in read only mode, this means another user is modifying the project's schema. You cannot open Architect in edit mode until the other user is finished with their changes and the schema is unlocked.

   For information on how you can use read only mode and edit mode for various schema editors, see Using read only or edit mode for schema editors.

4. From the Project Tables View, locate an attribute.

5. From the Properties pane, locate an attribute form.

6. Select the Support multiple languages check box to set the value to True, which enables data internationalization for the attribute form. You can clear the check box and set it to False, which disables internationalization for the attribute form.

   The ID form of an attribute does not have this option as these forms are used strictly for identification purposes.

7. From the Home tab, in the Save area, click Save and Close to save your changes and close Architect.