MicroStrategy Objects are logical abstractions of mainly database components, such as tables and columns. However, there are some objects that represent other things such as databases (connections), users, server nodes, schedules, and devices, to mention a few. All MicroStrategy Objects are stored in the MicroStrategy metadata database. In other words, if it is stored in the metadata then it must be a MicroStrategy Object.

This wide variety of MicroStrategy Objects are grouped into the following three main categories:

• Schema Objects: These objects directly represent database objects such as columns, tables, and partitions. Some examples are: Tables, Attributes, Facts, Hierarchies, and Transformations.
• Application Objects: Also known as Public Objects, these objects represent reporting and visualization objects. Some examples...

When MicroStrategy is installed, there is the option to install MicroStrategy Analytics Modules. Basically, this option will install two sample projects: MicroStrategy Tutorial and Human Resources Analysis Module. These two projects are installed and configured automatically. Both the data warehouse and the metadata databases reside on Microsoft Access. In addition, a 2-Tier Project Source is also created and accessible from MicroStrategy Developer. The login is Administrator with a blank password.

It is recommended to leave these sample projects to perform testing of MicroStrategy Features and self-training in a DEV or System Test environments, never in Production. Otherwise, these could be uninstalled. Throughout this book, we will use these two projects to describe examples and perform exercises.

MicroStrategy Developer is a client interface that was conceived while thinking of an interface that the majority of the developers and users are familiar with: Windows Explorer. Microsoft Windows Explorer is a tool that helps the user to visualize, manage, organize, create, and delete files in a PC. Similarly, MicroStrategy Developer (which by the way was called MicroStrategy Desktop for many years before version 9.5) is a tool that helps the user to visualize, manage, organize, create, and delete MicroStrategy Objects in the metadata.

Although other MicroStrategy clients, covered in Chapter 1, Architecture – Installing and Configuring MicroStrategy, will offer some specific functionality and interaction with the MicroStrategy Objects, MicroStrategy Developer is the main client to develop and manage all three object categories, as shown in the following...

The Projects are usually created according to a business area (such as marketing, finance, and human resources) or, in some organizations, by the technology that supports its data source (such as Teradata, Oracle, SQL Server). In any case, a MicroStrategy Project helps developers and users to organize their reporting and analytics applications. There are other Configuration Objects, but these will be covered in Chapter 6, Security – Managing Your Users and Their Access and Chapter 7, Administration – Maintaining and Monitoring Your Project.

The MicroStrategy Schema Objects are going to be the foundation of any project. These objects serve as building blocks on which other objects will be erected. Generally speaking, Schema Objects are mapped to database structures such as tables or columns with a few exceptions in which other Schema Objects are used as part of their components. Usually, there is only one person at a time creating or modifying Schema Objects. This person is called the project Architect. It is not recommended to have multiple persons modifying Schema Objects since this could lead to metadata inconsistencies and eventually corruption. Once any change has been performed to a schema object, it is necessary to commit this change into the metadata. To do so the Architect must Update Schema.

The first Schema Object to be created must be a MicroStrategy Table. The following is a quick reference table for this MicroStrategy Object:

This object is simply the logical representation of a table in the database (data warehouse). MicroStrategy imports into the object definition the table name, structure, columns, and data types. In addition, MicroStrategy assigns a value to the table based on the fields and Attributes mapped to it. It is important to mention that this number doesn't represent a measure of megabytes or number of rows but instead a conceptual value; this is why it is called the logical table size. This number is utilized by the MicroStrategy SQL Engine to choose which table should be used for the query when two tables are available to get the same data. MicroStrategy chooses the table with the smaller logical table size to...

MicroStrategy Facts are objects that represent a business measure stored in a database table. The following is a quick reference table for this MicroStrategy Object:

These measures usually have the following characteristics:

• They are numerical
• They can be aggregated (summed up or operated in some way)

The Facts usually map directly to one or more columns in a Fact table. The Fact is defined with a MicroStrategy expression. An expression could be:

• Base: an expression which is represented as a single table field
• Derived: an expression in which two or more table fields are operated or a function is applied to them

The Fact on its own is meaningless. It needs a context and a rule of aggregation in order to be useful. In the following sections, we will learn about which other MicroStrategy Objects serve this purpose.