Explore topic-wise InterviewSolutions in .

No, all the NODES in the same CLUSTER MUST RUN against the same METADATA

No, all the nodes in the same cluster must run against the same metadata

Technically, MicroStrategy Intelligence Servers in a cluster do not have to be configured identically. The only technical requirements are that all MicroStrategy Intelligence Servers point to the same METADATA and that all MicroStrategy Intelligence Servers have the same projects registered and in the same state (i.e., if Node A has Project A in a 'Loaded' state, then Node B must also have Project A in a 'Loaded' state.).However, in order to ease administration and to reduce the risk of unbalanced LOAD across cluster nodes, it is recommended that all nodes use the same MicroStrategy Intelligence Server definition and that each machine shows identical characteristics (i.e., EQUAL RAM, hard DISK space, CPU).

Technically, MicroStrategy Intelligence Servers in a cluster do not have to be configured identically. The only technical requirements are that all MicroStrategy Intelligence Servers point to the same metadata and that all MicroStrategy Intelligence Servers have the same projects registered and in the same state (i.e., if Node A has Project A in a 'Loaded' state, then Node B must also have Project A in a 'Loaded' state.).However, in order to ease administration and to reduce the risk of unbalanced load across cluster nodes, it is recommended that all nodes use the same MicroStrategy Intelligence Server definition and that each machine shows identical characteristics (i.e., equal RAM, hard disk space, CPU).

Yes. Object caches are synchronized across all cluster nodes. If any change affecting the Metadata is made by one cluster node, then the cluster node broadcasts the change to the other cluster nodes. The other cluster nodes will then update their LOCAL object caches. NOTE: Client-side object caches will not be automatically be refreshed. In MICROSTRATEGY Desktop, for example, a user may have to EXPLICITLY click on 'Refresh' to SEE an object change be reflected in the client application

Yes. Object caches are synchronized across all cluster nodes. If any change affecting the Metadata is made by one cluster node, then the cluster node broadcasts the change to the other cluster nodes. The other cluster nodes will then update their local object caches. NOTE: Client-side object caches will not be automatically be refreshed. In MicroStrategy Desktop, for example, a user may have to explicitly click on 'Refresh' to see an object change be reflected in the client application

No. Although the new report CACHE will be available for use by other cluster nodes, the cache will not APPEAR in the Cache Monitor of other cluster nodes. In order to see all report caches WITHIN a cluster, the ADMINISTRATOR will need to create a SEPARATE data source within Desktop for each cluster node. Then, the report caches within each node can be administered separately, using the same instance of the MicroStrategy Desktop application.

No. Although the new report cache will be available for use by other cluster nodes, the cache will not appear in the Cache Monitor of other cluster nodes. In order to see all report caches within a cluster, the administrator will need to create a separate data source within Desktop for each cluster node. Then, the report caches within each node can be administered separately, using the same instance of the MicroStrategy Desktop application.

To prevent the LOSS of a MicroStrategy Intelligence Server cluster node from affecting REPORT cache availability, the cluster can be configured such that a SEPARATE file server is USED as a common report cache repository. In order to maintain cache availability, this separate file server can be configured for failover with third-party clustering SOFTWARE.

To prevent the loss of a MicroStrategy Intelligence Server cluster node from affecting report cache availability, the cluster can be configured such that a separate file server is used as a common report cache repository. In order to maintain cache availability, this separate file server can be configured for failover with third-party clustering software.

Each NODE in a MicroStrategy Intelligence Server 7.0 cluster maintains indices of the caches available on the DIFFERENT nodes. When a report is submitted, these indices will be searched and once an EXISTING cache is found (in any nodes), the cached results will be RETRIEVED DIRECTLY from cache locations in either the local or remote machine.

Each node in a MicroStrategy Intelligence Server 7.0 cluster maintains indices of the caches available on the different nodes. When a report is submitted, these indices will be searched and once an existing cache is found (in any nodes), the cached results will be retrieved directly from cache locations in either the local or remote machine.

If an administrator removes a cluster node from a cluster, then all report CACHES that had been created by that cluster node will be inaccessible by the REST of the cluster, WHETHER or not a SEPARATE file server is used as a common report cache. This behavior is by design.

If an administrator removes a cluster node from a cluster, then all report caches that had been created by that cluster node will be inaccessible by the rest of the cluster, whether or not a separate file server is used as a common report cache. This behavior is by design.

Although report caches will not be lost, access to report caches may be affected, depending on the way in which the report cache is configured.If a separate file server is used as a common report cache REPOSITORY for all MicroStrategy Intelligence Server cluster nodes, then the LOSS of a cluster NODE will not AFFECT access to the report cache by other nodes.If the cluster is configured such that each node locally hosts the report cache CREATED by that node, then those report caches residing in the lost node will naturally be inaccessible. If any report cached in that lost node is requested, then another node within the cluster will re-run and re-cache the report. When the cluster node is recovered and rejoined into the cluster, all report caches in that cluster node will be made available again to the rest of the cluster.

Although report caches will not be lost, access to report caches may be affected, depending on the way in which the report cache is configured.If a separate file server is used as a common report cache repository for all MicroStrategy Intelligence Server cluster nodes, then the loss of a cluster node will not affect access to the report cache by other nodes.If the cluster is configured such that each node locally hosts the report cache created by that node, then those report caches residing in the lost node will naturally be inaccessible. If any report cached in that lost node is requested, then another node within the cluster will re-run and re-cache the report. When the cluster node is recovered and rejoined into the cluster, all report caches in that cluster node will be made available again to the rest of the cluster.

No. Each MicroStrategy Intelligence Server retains a lookup table with INFORMATION about the existence and location of REPORT caches. When a cluster node creates a report cache, information about the location of the new cache is shared with the other cluster NODES. Each cluster node then UPDATES its own lookup table with the location of the new cache.

No. Each MicroStrategy Intelligence Server retains a lookup table with information about the existence and location of report caches. When a cluster node creates a report cache, information about the location of the new cache is shared with the other cluster nodes. Each cluster node then updates its own lookup table with the location of the new cache.

REPORT caches are shared in a cluster and OBJECT caches on each MICROSTRATEGY INTELLIGENCE Server node are synchronized

Report caches are shared in a cluster and Object caches on each MicroStrategy Intelligence Server node are synchronized

No. When the administrator configures MicroStrategy Web to ACCESS a particular MicroStrategy INTELLIGENCE SERVER, the MicroStrategy Web application will automatically detect that the MicroStrategy Intelligence Server is a member of a cluster. Once this detection is made, MicroStrategy Web will automatically ADD all the other members of the same cluster into the pool of AVAILABLE MicroStrategy Intelligence Servers.

No. When the administrator configures MicroStrategy Web to access a particular MicroStrategy Intelligence Server, the MicroStrategy Web application will automatically detect that the MicroStrategy Intelligence Server is a member of a cluster. Once this detection is made, MicroStrategy Web will automatically add all the other members of the same cluster into the pool of available MicroStrategy Intelligence Servers.

The MicroStrategy WEB application is designed so that each MicroStrategy Web cluster node does not need to know that it is a member of a cluster. MicroStrategy Web is designed to be stateless, so that each CLIENT http request can be PROCESSED individually without having to persist information within the MicroStrategy Web application. THEREFORE, third-party Web-server CLUSTERING software can be used to cluster together multiple web servers running MicroStrategy Web.

The MicroStrategy Web application is designed so that each MicroStrategy Web cluster node does not need to know that it is a member of a cluster. MicroStrategy Web is designed to be stateless, so that each client http request can be processed individually without having to persist information within the MicroStrategy Web application. Therefore, third-party Web-server clustering software can be used to cluster together multiple web servers running MicroStrategy Web.

MicroStrategy Web is designed to be as stateless as possible. Therefore, no information is SHARED by the MicroStrategy Web application across cluster nodes. All state information for running jobs is pushed to the client browser.When a REPORT is submitted by a MicroStrategy Web user, the user will receive a wait page in the client browser. This wait page will POLL the MicroStrategy Web Server periodically for the STATUS of the report. This polling is performed as new http requests. This http request will contain all state information, including encrypted login information and MicroStrategy Intelligence Server connection information.

MicroStrategy Web is designed to be as stateless as possible. Therefore, no information is shared by the MicroStrategy Web application across cluster nodes. All state information for running jobs is pushed to the client browser.When a report is submitted by a MicroStrategy Web user, the user will receive a wait page in the client browser. This wait page will poll the MicroStrategy Web Server periodically for the status of the report. This polling is performed as new http requests. This http request will contain all state information, including encrypted login information and MicroStrategy Intelligence Server connection information.

MicroStrategy Web relies on third-party web-CLUSTERING SOFTWARE to PROVIDE clustering functionality. MicroStrategy Web is designed to be STATELESS so that each individual MicroStrategy Web node can function without the knowledge of the existence of other nodes. THEREFORE, any third-party software used to cluster web servers can be used.

MicroStrategy Web relies on third-party web-clustering software to provide clustering functionality. MicroStrategy Web is designed to be stateless so that each individual MicroStrategy Web node can function without the knowledge of the existence of other nodes. Therefore, any third-party software used to cluster web servers can be used.

If the OWNER of the source object does not exist in the DESTINATION PROJECT, the user LOGIN for the destination project takes ownership of the object when it is copied or replaced.

If the owner of the source object does not exist in the destination project, the user login for the destination project takes ownership of the object when it is copied or replaced.

If the location exists in the destination project, the dependent OBJECT is copied to that location. If the location does not EXIST in the destination project, a new folder entitled 'Dependencies' is CREATED and the object is copied to that folder

If the location exists in the destination project, the dependent object is copied to that location. If the location does not exist in the destination project, a new folder entitled 'Dependencies' is created and the object is copied to that folder

TRACING is available under the Tools/Diagnostics menu. These tracing options apply to every MicroStrategy product installed on the machine.To see the SQL that has been EXECUTED against the metadata, GO to the ADVANCED tab and turn on 'SQL Tracing' under the DSS MDServer key.Function level tracing can be accomplished by going to the Advanced tab and turning on 'Function Level Tracing' under the DSS ObjectManager key.

Tracing is available under the Tools/Diagnostics menu. These tracing options apply to every MicroStrategy product installed on the machine.To see the SQL that has been executed against the metadata, go to the Advanced tab and turn on 'SQL Tracing' under the DSS MDServer key.Function level tracing can be accomplished by going to the Advanced tab and turning on 'Function Level Tracing' under the DSS ObjectManager key.

Using MicroStrategy Object Manager to copy/move objects around is not recommended while other USER sessions are making CHANGES using MicroStrategy Agent, as it could lead to metadata inconsistency. PROJECT and schema locking PREVENT multiple USERS sessions from manipulating the schema at the same time. This prevents metadata inconsistency from occurring.

Using MicroStrategy Object Manager to copy/move objects around is not recommended while other user sessions are making changes using MicroStrategy Agent, as it could lead to metadata inconsistency. Project and schema locking prevent multiple users sessions from manipulating the schema at the same time. This prevents metadata inconsistency from occurring.

Security in MicroStrategy OBJECT Manager is based on the MicroStrategy 7.x PRODUCT Suite security model. All ACTIVITIES that can be performed in MicroStrategy Object Manager are governed by privileges and access control lists. For example, if a user is not allowed to access a certain FOLDER in MicroStrategy Agent, they will not be able to access the folder in MicroStrategy Object Manager.

Security in MicroStrategy Object Manager is based on the MicroStrategy 7.x Product Suite security model. All activities that can be performed in MicroStrategy Object Manager are governed by privileges and access control lists. For example, if a user is not allowed to access a certain folder in MicroStrategy Agent, they will not be able to access the folder in MicroStrategy Object Manager.

Yes, schema objects can be copied across projects using MicroStrategy Object Manager. MicroStrategy Object Manager moves objects seamlessly between similar projects such as from a development project version to a production project version where the warehouses are the same in terms of views, prefixes, and WAREHOUSE structure. HOWEVER, subtle changes in the warehouse that RELATE to prefixes, views, or table structure cannot be tracked by MicroStrategy Object Manager. For situations where the projects' warehouse structures or setups are DISSIMILAR, users may be REQUIRED to make further edits of the objects to ensure full integration into the destination project. These edits may include hierarchical relationship changes or modifications to the prefixes.

Yes, schema objects can be copied across projects using MicroStrategy Object Manager. MicroStrategy Object Manager moves objects seamlessly between similar projects such as from a development project version to a production project version where the warehouses are the same in terms of views, prefixes, and warehouse structure. However, subtle changes in the warehouse that relate to prefixes, views, or table structure cannot be tracked by MicroStrategy Object Manager. For situations where the projects' warehouse structures or setups are dissimilar, users may be required to make further edits of the objects to ensure full integration into the destination project. These edits may include hierarchical relationship changes or modifications to the prefixes.

MicroStrategy Object Manager makes a list of all object dependencies before copying an object to prevent metadata inconsistency. The TIME required for dependency CHECKING varies based on a CUSTOMER's metadata size and schema complexity. For large metadata and complex schemas, gathering all the dependencies may take a LONG time.

MicroStrategy Object Manager makes a list of all object dependencies before copying an object to prevent metadata inconsistency. The time required for dependency checking varies based on a customer's metadata size and schema complexity. For large metadata and complex schemas, gathering all the dependencies may take a long time.

To view the OBJECT ID of an object, right-mouse CLICK on the object and SELECT 'Properties.' The Object ID and Version ID are listed on the 'General' tab.

To view the Object ID of an object, right-mouse click on the object and select 'Properties.' The Object ID and Version ID are listed on the 'General' tab.

To determine if two OBJECTS are the same, MICROSTRATEGY Object Manager COMPARES their Object ID's. If these ID's are the same, MicroStrategy Object Manager then compares the Version ID's. If the Version ID's are the same, the Conflict Resolution GRID lists the conflict as 'Exists Identically.' If the Version ID's are DIFFERENT, the Conflict Resolution grid lists the conflict as 'Exists Differently.

To determine if two objects are the same, MicroStrategy Object Manager compares their Object ID's. If these ID's are the same, MicroStrategy Object Manager then compares the Version ID's. If the Version ID's are the same, the Conflict Resolution grid lists the conflict as 'Exists Identically.' If the Version ID's are different, the Conflict Resolution grid lists the conflict as 'Exists Differently.

The Conflict RESOLUTION window provides the USER with a means to decide how to handle OBJECT CONFLICTS between the source project and the destination project. In addition, the Conflict Resolution window displays the object name in the ORIGINAL project, the object name in the destination project and the type of conflict. Users may also specify a new name for the object depending on the action chosen

The Conflict Resolution window provides the user with a means to decide how to handle object conflicts between the source project and the destination project. In addition, the Conflict Resolution window displays the object name in the original project, the object name in the destination project and the type of conflict. Users may also specify a new name for the object depending on the action chosen

MicroStrategy Object MANAGER compares the SCHEMA ID's of the two projects. DUPLICATED projects have different Project ID's, but their Schema ID's are the same.

MicroStrategy Object Manager compares the Schema ID's of the two projects. Duplicated projects have different Project ID's, but their Schema ID's are the same.

Yes. In order to perform cross-project operations, the PROJECTS INVOLVED must originate from the same SOURCE project. In other words, the projects can only be related by the duplication of a single project. This ensures that the projects have a SIMILAR set of schema and application objects, and that the object ID's in the two projects are the same. MicroStrategy Object Manager uses the object and version ID's across the projects to perform comparisons.MicroStrategy Object Manager prevents the user from attempting operations across unrelated projects.

Yes. In order to perform cross-project operations, the projects involved must originate from the same source project. In other words, the projects can only be related by the duplication of a single project. This ensures that the projects have a similar set of schema and application objects, and that the object ID's in the two projects are the same. MicroStrategy Object Manager uses the object and version ID's across the projects to perform comparisons.MicroStrategy Object Manager prevents the user from attempting operations across unrelated projects.

Microstrategy Narrowcast Server supports: enterprise reporting applications, executive information portals, corporate information dissemination, sale force automation, WORKING capital management, supply chain management, EXTRANET portals, secure business to business portals, customer SERVICE applications, and intelligent ALERTING applications

Microstrategy Narrowcast Server supports: enterprise reporting applications, executive information portals, corporate information dissemination, sale force automation, working capital management, supply chain management, extranet portals, secure business to business portals, customer service applications, and intelligent alerting applications

MICROSTRATEGY Narrowcast Server provides an easy and inexpensive WAY to SEND CORPORATE information to untrained employees, PARTNERS, and customers. As a result, decision-makers have the information they need to maximize revenue generation and streamline business processes that cut operating costs

Microstrategy Narrowcast Server provides an easy and inexpensive way to send corporate information to untrained employees, partners, and customers. As a result, decision-makers have the information they need to maximize revenue generation and streamline business processes that cut operating costs

MICROSTRATEGY Narrowcast Server is a software PRODUCT that monitors and delivers individualized information to users via email, WEB portals, and wireless devices such as PDAS, pagers, and phones. Through a easy-to-use web page, users specify what information they want, when and how they want to receive it.

Microstrategy Narrowcast Server is a software product that monitors and delivers individualized information to users via email, web portals, and wireless devices such as PDAs, pagers, and phones. Through a easy-to-use web page, users specify what information they want, when and how they want to receive it.

Yes, OLAP Services is sold as a SEPARATE product that is installed with MICROSTRATEGY Intelligence SERVER. It is licensed EITHER on a per-user or per-CPU BASIS.

Yes, OLAP Services is sold as a separate product that is installed with Microstrategy Intelligence Server. It is licensed either on a per-user or per-CPU basis.

Yes, with the appropriate version of MICROSTRATEGY Web or Desktop, certain functions leverage the Intelligent Cubes. These functions INCLUDE: report formatting down to cell level, column aliasing, drilling, pivoting, page-by, adding metric thresholds, adding SUBTOTALS, ranking and sorting. Please see the Web and Desktop version comparisons to determine EXACTLY which Web or Desktop version includes the desired functionality.

Yes, with the appropriate version of Microstrategy Web or Desktop, certain functions leverage the Intelligent Cubes. These functions include: report formatting down to cell level, column aliasing, drilling, pivoting, page-by, adding metric thresholds, adding subtotals, ranking and sorting. Please see the Web and Desktop version comparisons to determine exactly which Web or Desktop version includes the desired functionality.

Intelligent CUBES used by OLAP Services automatically inherit all of the security provisions of EVERY REPORT object used within the Intelligent Cube, and those provisions are dynamically applied to each user's security profile when the cube is ACCESSED. If a user only has privileges to use four of the five metrics contained in an Intelligent Cube, that restriction will automatically and seamlessly apply when the user accesses the Intelligent Cube. The user will still have access to the Intelligent Cube for the four metrics he or she has privileges to use

Intelligent Cubes used by OLAP Services automatically inherit all of the security provisions of every report object used within the Intelligent Cube, and those provisions are dynamically applied to each user's security profile when the cube is accessed. If a user only has privileges to use four of the five metrics contained in an Intelligent Cube, that restriction will automatically and seamlessly apply when the user accesses the Intelligent Cube. The user will still have access to the Intelligent Cube for the four metrics he or she has privileges to use

The usage of OLAP Services is transparent to END-USERS. Users do not need to know the NAME and location of an Intelligent Cube, or even if it EXISTS. OLAP Services works with Microstrategy Intelligence Server to automatically use the appropriate Intelligent Cube or create a new one to satisfy the end user request

The usage of OLAP Services is transparent to end-users. Users do not need to know the name and location of an Intelligent Cube, or even if it exists. OLAP Services works with Microstrategy Intelligence Server to automatically use the appropriate Intelligent Cube or create a new one to satisfy the end user request

MICROSTRATEGY Web (ANALYST and Professional versions), Microstrategy Desktop (Analyst and Designer versions) and Microstrategy Office all leverage the functionality ENABLED by OLAP SERVICES

Microstrategy Web (Analyst and Professional versions), Microstrategy Desktop (Analyst and Designer versions) and Microstrategy Office all leverage the functionality enabled by OLAP Services

Intelligent Cubes are created automatically when a new report is run against the data warehouse. Subsequent requests by other users can SEAMLESSLY hit this new Intelligent Cube. The logic to match USER requests with the appropriate Intelligent Cube is automatically handled within the Microstrategy platform. Users don't have to specify the cube to which they WANT to connect. Benefits of Intelligent Cubes include:

• Greater Efficiency - Intelligent Cubes are automatically generated and shared among all users whenever a report is executed by a user or pre-cached by the administrator or a user.
• Easy to Use - Intelligent Cubes can be designed by mainstream BI users, using the same interface and the same operations as are used with basic OLAP analysis.
• More Scalable Cubes - Intelligent Cubes do not need massive pre-calculations or pre-aggregations. The mid-tier Intelligence Server can do these calculations on-the-fly as the cubes are being used.
• Increased Manageability and Reliability - Intelligent Cubes can be configured to expire or refresh automatically whenever underlying data or definitions change.
• Increased Power for End-Users - Users can seamlessly drill through to the full depth of the data warehouse, or slice and dice with speed-of-thought response time within the Intelligent Cube.

Intelligent Cubes are created automatically when a new report is run against the data warehouse. Subsequent requests by other users can seamlessly hit this new Intelligent Cube. The logic to match user requests with the appropriate Intelligent Cube is automatically handled within the Microstrategy platform. Users don't have to specify the cube to which they want to connect. Benefits of Intelligent Cubes include:

With OLAP Services Microstrategy Web, Desktop and OFFICE users can:

• Create unique report views BASED off an Intelligent Cube. With OLAP Services, users can create unique report views by adding or removing attributes and metrics contained within the Intelligent Cube. This allows speed-of-thought report creation and modification with no NEED to extract DATA from the data warehouse.
• Create new on-the-fly metric calculations from existing metrics in an Intelligent Cube. The new calculation is performed without submitting a new request to the data warehouse.
• Filter their view of the data within an Intelligent Cube. The filtering will be performed on Microstrategy Intelligence Server within the Intelligent Cube.

With OLAP Services Microstrategy Web, Desktop and Office users can:

The Very Large Data Base PROPERTIES is the configuration set that manages the overall way in which the database behaves and generates reports. There are many such settings like check for cross joins, intermediate table creation and type etc. The VLDB properties can be set at many different level like metric level, attribute level, Database INSTANCE level, PROJECT level or the DBMS level. The highest precedence is given to the report level of configurations.

The Very Large Data Base properties is the configuration set that manages the overall way in which the database behaves and generates reports. There are many such settings like check for cross joins, intermediate table creation and type etc. The VLDB properties can be set at many different level like metric level, attribute level, Database Instance level, project level or the DBMS level. The highest precedence is given to the report level of configurations.

• Column level security ESTABLISHED by the imposing user specific ACCESS PERMISSIONS in the database and having user specific connections.
• Entire SET of objects can be secured by imposing folder and object level security.
• Row level security is imposed by having user specific security filters for various records.

The PASS-through functions are the SPECIFIC DATABASE oriented SQL statements and constructs that are executed by the microstrategy WITHOUT checking semantics of the actual construct. They are called pass-through as they are not checked for CORRECTNESS by the microstrategy as such. ApplySimple, Applycomparison are two pass through functions that microstrategy usually applies.

The pass-through functions are the specific database oriented SQL statements and constructs that are executed by the microstrategy without checking semantics of the actual construct. They are called pass-through as they are not checked for correctness by the microstrategy as such. ApplySimple, Applycomparison are two pass through functions that microstrategy usually applies.

The level metrics are the metric calculation that are carried out over the specific attribute but at the different levels or dimensions. For example, the number of units sold is an attribute that we keep a count on. That metric can be calculated across TIME and region. Say number of units sold in last month and the number of units sold in specific region of the country. Here the region and time are TWO different levels. Such level based metric give analytical INFERENCE as to the performance of the organization ETC.

The level metrics are the metric calculation that are carried out over the specific attribute but at the different levels or dimensions. For example, the number of units sold is an attribute that we keep a count on. That metric can be calculated across time and region. Say number of units sold in last month and the number of units sold in specific region of the country. Here the region and time are two different levels. Such level based metric give analytical inference as to the performance of the organization etc.

The object manager is the one that copies GROUPS of OBJECTS with all the attributes that are associated with it. The project merge is used for COPYING the entire project ALONG with all the objects. This is why it does not have to CHECK for the attribute constraints before copying. The Object manager however has to make sure of the object attribute matches before copying the objects. The object manager cannot be run from the command prompt directly whilst the project merge can be run directly

The object manager is the one that copies groups of objects with all the attributes that are associated with it. The project merge is used for copying the entire project along with all the objects. This is why it does not have to check for the attribute constraints before copying. The Object manager however has to make sure of the object attribute matches before copying the objects. The object manager cannot be run from the command prompt directly whilst the project merge can be run directly

The command manger is the one through which you can manage the applications, user accesses, security and DATABASES of the microstrategy. The command manager allows US to SAVE the text commands that can be EXECUTED as scripts. Thus it can help in automation of the entire management PROCESS.

The command manger is the one through which you can manage the applications, user accesses, security and databases of the microstrategy. The command manager allows us to save the text commands that can be executed as scripts. Thus it can help in automation of the entire management process.

The attributes that are single in definition but the INSTANCES of the attribute can BEHAVE differently according to the role they take. Example for this can be a database of airports around the world. The attribute of airport name is always based on the same database table but can be SEEN as a destination airport or source airport. Such roles are RESOLVED by having aliases for the same table, one alias for destination and one for source airports. We can also enable the automatic attribute role recognition by configuring it properly.

The attributes that are single in definition but the instances of the attribute can behave differently according to the role they take. Example for this can be a database of airports around the world. The attribute of airport name is always based on the same database table but can be seen as a destination airport or source airport. Such roles are resolved by having aliases for the same table, one alias for destination and one for source airports. We can also enable the automatic attribute role recognition by configuring it properly.

The objects maps are the ones that are used to select the GROUP of MICROSTRATEGY objects that are used to GENERATE the REPORT. This can serve as the template or filter. Then optimizations to the various reports can be DONE by analysis of the VLDB properties and the customizations can be monitored by the processing path taken up by the Anlytical engine

The objects maps are the ones that are used to select the group of microstrategy objects that are used to generate the report. This can serve as the template or filter. Then optimizations to the various reports can be done by analysis of the VLDB properties and the customizations can be monitored by the processing path taken up by the Anlytical engine

The CUSTOM GROUPS are the made up of what are called as custom GROUP elements and together they act as a special filter that can be implemented over a specific template. Consolidations refer to the WAY in which you group or order the DATA in your report. The different attributes can be gathered together without changing the underlying metadata and ware housing structure

The custom groups are the made up of what are called as custom group elements and together they act as a special filter that can be implemented over a specific template. Consolidations refer to the way in which you group or order the data in your report. The different attributes can be gathered together without changing the underlying metadata and ware housing structure

The number of passes REPRESENTS the number of times the SQL query has to be parsed and different parts of the query is handled for EVERY pass. The FEWER passes we have the more efficient the query EXECUTES and faster the reports are GENERATED.

The number of passes represents the number of times the SQL query has to be parsed and different parts of the query is handled for every pass. The fewer passes we have the more efficient the query executes and faster the reports are generated.

The parent-CHILD relationship helps in establishing the HIERARCHICAL structure to the entire logic and business model. For example, you can have the quarter to be a child of a SPECIFIC year attribute. This will help us in having a modularized approach in the design and will help in establishing COMMON usage SEMANTICS. The various types of relationships can be one to one, many to one, many to many, one to many relationships.

The parent-child relationship helps in establishing the hierarchical structure to the entire logic and business model. For example, you can have the quarter to be a child of a specific year attribute. This will help us in having a modularized approach in the design and will help in establishing common usage semantics. The various types of relationships can be one to one, many to one, many to many, one to many relationships.

Report FILTERS: report filters are the conditions that accompany the report generating SQL statements. The report definitions have the filters as part of their definition.

View Filters: View Filters are the conditions that come into PLAY before a specific RESULT is presented to the user. Thus the view filters are not part of the SQL statements like report definitions, rather they are the filters APPLIED after the execution of the SQL statements, after the data is retrieved from the data WAREHOUSE.

Report filters: report filters are the conditions that accompany the report generating SQL statements. The report definitions have the filters as part of their definition.

View Filters: View Filters are the conditions that come into play before a specific result is presented to the user. Thus the view filters are not part of the SQL statements like report definitions, rather they are the filters applied after the execution of the SQL statements, after the data is retrieved from the data warehouse.

The MSTR operates in such a WAY that the incoming queries and data retrievals are done from the table which has the LEAST logical size. Thus if we prefer a SPECIFIC table to be the center of activity then we should try to reduce the logical size of that specific table so that it becomes considerably lesser than the other TABLES.

The MSTR operates in such a way that the incoming queries and data retrievals are done from the table which has the least logical size. Thus if we prefer a specific table to be the center of activity then we should try to reduce the logical size of that specific table so that it becomes considerably lesser than the other tables.

The logical views help in establishing a specific view based on the COMBINATION of facts, attributes and EXPRESSIONS that are based on VALUES from multiple tables. This can be done without the ACTUAL modification to the actual physical DATABASE or the DBA involvement. This way the reporting can be altered at the highest level of application and can be very quick way to alterations for reporting.

The logical views help in establishing a specific view based on the combination of facts, attributes and expressions that are based on values from multiple tables. This can be done without the actual modification to the actual physical database or the DBA involvement. This way the reporting can be altered at the highest level of application and can be very quick way to alterations for reporting.