Introduction to Software Testing

Software never runs as we want it to work. Creating a software is an attempt at formally specifying a solution to a problem. Assuming that the software implements the correct solution. It is very often implements this solution incorrectly. Even if it does implement the solution correctly, the solution may itself not be what the customer wants, or may have unforeseen consequences in the software's behaviour.

In all of these situations the software may produce unexpected and unintended behaviour. The error which causes this unexpected and unintended behaviour is called a software bug.

Software testing is the process of analysing and finding the defect in a software and to detect the differences between existing and required conditions and to evaluate the features of the software. Software testing is an activity that should be done throughout the whole development process of a software.

Finding errors in the software solution itself is an important aspect to software testing, but it is not the only aspect. Testing can also be used to find how well the software conforms to the software requirements, including performance requirements, usability requirements etc., Understanding how to test software in a methodical manner which is a fundamental skill required in Software Engineering of acceptable quality.

Principles of Software Testing

1. Testing shows presence of defects: Testing can show the defects that are present in the software, but cannot say that there are no defects. Even after testing the application or product or Software thoroughly, we cannot say that the product is fully defect free. Testing always reduces the number of un-finding defects remaining in the software but even if no defects are found, it is not a proof that the software implemented is correct.

2. Exhaustive testing is impossible: Testing everything in the software including all combinations of inputs and preconditions is not possible. So, instead of doing the exhaustive testing we can use           risks and priorities to focus testing efforts.

3. Early testing: In the software development life cycle testing activities should start as early as possible and should be focused on defined objectives.

4. Defect clustering: A small number of modules contains most of the defects discovered during pre-release of testing or shows the most operational failures.

5. Pesticide paradox: If the same kinds of tests are repeated again and again, eventually the same set of test cases will no longer be able to find any new bugs. To overcome this “Pesticide Paradox” is   very important to review the test cases regularly. So new cases and different tests need to be written to exercise different parts of the software to potentially find more defects in the software.

6. Testing is context dependent: Testing is basically context dependent. Different kinds of sites are tested differently.

7. Absence of errors fallacy: If the system built is unusable and if the User is not fulfil with the software done by the development team and did not reach the user’s requirements and expectations then   finding and fixing defects does not help.

     Software testing never completes. It is an ongoing process that begins with the project's inception and continues until the project is no longer supported. During the software lifetime the burden of testing slowly shifts from the developers during design and programming, to independent testing teams, and finally to the customers. Every action that the customer performs with the software can be considered a test of the software itself.

Time and money constraints often intervene and it may not be worth the developer's time or money to fix particular software errors. This trade-off between resources spent vs potential benefit can easily occur for small errors, and for errors which are not often encountered by the software's users.

It is also possible and also difficult to be statistically be careful when discussing software errors. For instance, it is possible to develop a statistical model of the number of expected software failures with respect to execution time. Error rates over a given period can then be specified given a particular probability. When that probability is low enough then the testing of the software could be considered as complete.

Contents

• Purpose
• Disclaimer
• Overview
• Key features
• Summary

Purpose

The purpose of this document is to provide an overview of Atlassian Confluence and Microsoft SharePoint, and provide the capabilities, strengths and limitations of each tool for varied business needs.

Disclaimer

Information provided in this document is for reference use only. Information in this document is prepared based on prior projects experience, Confluence.com, Microsoft.com, and web research. The information in this document does not guaranty full accuracy of the items explained. For any questions or concerns please contact Nagaraj Yerram at nyerram@netpeach.com

 An overview

Key features

Team Spaces

In General

Document Management

Applications List and Services Integration 

Summary

Confluence and SharePoint two separate platforms for different purposes which do share similar functionality in some aspects. Both the tools are based on completely different technology. Great advantage of Confluence is easy-to-use, whereas SharePoint lets you design/build easy-to-use portal. Both the tools offer lots of options and choices.

Both Confluence and SharePoint are good alternatives for intranets. To make the choice, the most important thing is to first crystallize what you want from your intranet. What will it be used for? For an intranet concept combining published pages and documents, news, collaboration and social features, Confluence might be the more user-friendly option. For an Intranet do lot more than publishing news and manage documents, such as business process developments, application integrations, BI and reporting services, etc. SharePoint might be a better option.

Contents

• Purpose
• Disclaimer
• Overview
• Key features
• Pros and Cons
• Summary

Purpose

The purpose of this document is to provide an overview of SharePoint 2013 Cloud vs On-Premise.

Disclaimer

Information provided in this document is for reference use only. Information in this document is prepared based on prior projects experience, Microsoft.com, and web research. The information in this document does not guaranty full accuracy of the items explained. For any questions or concerns please contact Nagaraj Yerram at nyerram@netpeach.com

Key features…

Product features compared 

For complete feature comparison visit: SharePoint Online Services Description.

On-Premise Pros and Cons 

Summary 

SharePoint Cloud option was first introduced in 2010. In the past, there have been some major differences between SharePoint Online and SharePoint On Premise. Since then, Microsoft has been working towards release parity, meaning that SharePoint Online will be the equivalent of SharePoint On Premise. With the release of SharePoint 2013 that gap has come down significantly. With that said, there are still integration points and advanced functionality that are only available with SharePoint On Premise.

All Office 365 plans include the SharePoint Online service, but not all plans support all SharePoint features. E3 and E4 plans support most features. Cloud option is missing SharePoint’s some of the Business Intelligence features.

Could and On-Premise options come with its own advantages and disadvantages. Most of the information has been summarized in this document for reference purpose only.

Many small to medium-sized organizations start using SharePoint in a “two-tier” server farm topology.  The two tiers consist of:

1. Tier 1 – SharePoint Server with all web page serving and all Service Applications running on it
2. Tier 2 – A SQL Server to store the SharePoint databases – the SQL Server could be dedicated to the farm or it might be shared with other non-SharePoint applications.

This farm topology can frequently support companies with hundreds of employees.  Of course, it depends a lot on the specifications of the hardware, but with late-model quad-core Xeons running on the two servers and 8 – 16 GBs of RAM on each one with RAID built with 15k RPM SAS drives in the SQL Server, this configuration with SharePoint Server 2010 can perform very well in many organizations that have less than 1000 users.

At some point, an organization that started with this two-tier topology may want to scale out to the next level which is a three-tier topology.  The three tiers would be:

1. Tier 1 – SharePoint Server dedicated as a Web Front-End (WFE) with only the web application(s) and the search query service running on it
2. Tier 2 – SharePoint Server dedicated as an Application Server with all of the other service applications running on it, but no web applications or query service
3. Tier 3 – SQL Server for the databases

Visually, this topology looks like this:

1.     Scaling Out SharePoint 2010 Farm From 2-Tier to 3-Tier

Many small to medium-sized organizations start using SharePoint in a “two-tier” server farm topology.

The 2-Tiers consist of the main components:

1.       Tier 1 – SharePoint Server with all Web page serving and all Service Applications running on it.

2.       Tier 2 – A SQL Server to store the SharePoint databases – the SQL Server could be dedicated to the farm or it might be shared with other non-SharePoint applications.

This configuration with SharePoint Server 2010 can perform very well in many organizations that have less than 1000 users

At some point, Organizations that started with two-tier topology need to scale up to 3-Tier depending on the business need/requirement.

3-Tier components are broadly classified into the following segments:

1.       Tier 1 – SharePoint Server dedicated for Web Front-End (WFE) with only Web application(s) and Search Query running on it.

2.       Tier 2 – SharePoint Server dedicated for Application Server (App server) with all of the other service applications running excluding Web Applications and Query Service.

3.       Tier 3 – SQL Server for the Content DB/Search DB etc.

There are many different reasons why a company might want to scale out to 3-Tiers. Some kind of performance improvement is frequently what drives it. However, it may not be the obvious one of desiring better page serving times for the end users.  For instance, frequently companies do this to move the search crawling and index building process to a different server that is more tuned for its unique resource requirements and can do a more efficient job of crawling and indexing the company’s content. Perhaps in the two-tier approach their crawl\index component can’t get enough hardware resources to crawl through all of the content on a timely basis.

Services on Server page will have all of the service applications that run on the SharePoint 2010 server in a two-tier farm when you install SharePoint Server 2010 Enterprise edition and run the out-of-the-box configure Your SharePoint Farm Wizard and choose to provision all service applications.

Our goal is to add a third server to the SharePoint 2010 farm and have it take over running all of the service applications in the list Services on Server, with the exception of below three.

·         Microsoft SharePoint Foundation Web Application

·         Search Query and Site Settings Service

·         SharePoint Server Search

These three are the ones that are necessary for the original server to function as a dedicated WFE with query processing.

The Search Query and Site Settings Service and some of its associated functionality in the SharePoint Server Search Service are technically not required on a WFE, but it is the best place to put them. The reason is that this is the process that takes the user’s search query and looks it up in the indexes. The indexes are files that the query processor needs local access to and are stored on the file system of the server(s) that is running the query service, not in SQL Server.

So, for best performance it is recommended to run the Search Query and Site Settings Service on the WFEs that are serving the pages.  The crawling and index process is a separate process whose job it is to build the indexes and push them up to the query servers.

The Search Topology configuration settings in SharePoint 2010 dictate what functionality of the SharePoint Server Search Service runs on what server in the farm.  So, while the SharePoint Server Search Service needs to run on both the WFE and the Application Server, it will be possible break out the functionality that it performs on each.  We will want it to perform query-related functionality on the WFE and crawling/indexing functionality on the Application Server.

1.1   Build a new SharePoint Server with exactly the same software

Take a fresh physical or virtual server that has Windows Server 2008 (R1 or R2) running on it, and install all the same SharePoint Server 2010 software on it that is installed on the existing SharePoint 2010 server in your existing farm.  That includes the full RTM Enterprise edition, whatever patches have been applied in your farm since RTM, and any other separate products that have been installed on your existing server such as the Office 2010 Web Applications and its patches.

1.2    Run the SharePoint 2010 Products Configuration Wizard on the new server and join the existing farm

Install all RTM software and all patches that have previously been applied to the farm BEFORE running the SharePoint 2010 Products Configuration Wizard from the new server’s Start menu. This means that you will want to respond NO to the prompt to automatically run the wizard until you have installed all software packages on the new server.  This will save you from having to run the wizard multiple times.  Run it once – after you have installed all software and patches on the new server.

When you do run the SharePoint 2010 Products Configuration Wizard, you will run it on the new server that will be your application server.

A screen in the wizard asks you for the Farm passphrase. This is a special password you created when you originally created the farm.  You have to enter it here in order to join this server to the farm.

Now the server has been joined to the farm and is a full-fledged farm member.  But, the Configure Your SharePoint Farm Wizard in Central Administration needs to run to add the service applications that exist in the farm to this new server.  So, it automatically fires up your browser and asks you to run the Farm Configuration Wizard.

1.3   Verify that everything is running properly on the new server

Verify that the new server is showing up as a member of the farm with a healthy status.  To do that go to Central Administration > System Settings > Manage Servers In This Farm and find the new server and verify that it has a “No action required” status. This is now a three-tier SharePoint 2010 farm.

Next step is to ensure that the three-tier farm has only the web page serving and query processing services running on the WFE and all of the other service applications running only on the Application Server.

(Note: the farm will work and be fully functional if you stop here.  You will have the same Service Applications running on multiple servers and SharePoint 2010 will automatically use this topology as a load balancing technique for the Service Applications.  There may be some environments where this is desired.  But, most organizations will want to separate the web-serving services and the application-serving services to provide a better balance for the farm as a whole as opposed to just load balancing the Service Applications.)

1.4   Re-configure the servers to run the services that are appropriate for their individual roles

The Web Front-End should run these (and only these) services:

1.       Microsoft SharePoint Foundation Web Application (this is what turns IIS into a SharePoint “page-serving” machine)

2.       Search Query and Site Settings Service (the process that takes the user’s query string and looks it up in the index)

3.       SharePoint Server Search Service (but just the functionality that is necessary for the query processor)

4.       Central Administration (assuming it is not moved it to the Application Server)

The Application Server should run these (and only these) services:

1.       Access Database Service

2.       Application Registry Service

3.       Business Data Connectivity Service

4.       Excel Calculation Services

5.       Managed Metadata Web Service

6.       Microsoft SharePoint Foundation Incoming E-mail

7.       Microsoft SharePoint Foundation Workflow Timer Service

8.       PerformancePoint Service

9.       Secure Store Service

10.   SharePoint Server Search (but just the scheduled content crawling and indexing building functionality)

11.   User Profile Service

12.   Visio Graphics Service

13.   Web Analytics Data Processing Service

14.   Web Analytics Web Service

15.   Word Automation Services

16.   Word Viewing Service

 (Important Note: Step 1 above is really the only step in the process that can be done during normal working hours.  Everything else has the potential to impact the availability of the system to the users. Of course, it is highly recommended to have solid backups in place before starting Step 2.)

For the most part, the re-configuration of the services involves stopping a lot of services on the WFE server (using the Services on Server page in Central Admin) and verifying that they are running on the new server (which they probably are because the Configure Your SharePoint Farm wizard started them up when you ran it in Step 2).  Then, you will want to make one last pass over the list of services running on the Application Server and make sure that the Microsoft SharePoint Foundation Web Application Service and the Search Query and Site Settings are not running on it.

Adjusting the Search Application Topology

The exception to the statements of the previous paragraph is the search-related services:  SharePoint Server Search Service and Search Query and Site Settings Service.  Search is complicated enough that it has its own topology configuration settings. We need to use this capability to place the query functionality of the SharePoint Server Search Service on the WFE and to place the crawling\indexing functionality of the service on the Application Server.

Since this is a little more complicated than the other Service Applications, this must be done first.

Navigate to the Search Administration home page in Central Administration. Scroll down to the bottom of the page until you see the section titled Search Application Topology:

This part of the page shows you what servers the following four components of the Search service are running on:

·         Search Administration component

·         Crawling component (this is the crawling engine that crawls your content and builds full-text indexes from it)

·         Database component (as the crawling engine crawls through the content, it stores the full-text indexes in SQL Server.  It also compiles the full-text indexes into special non-SQL files that can be propagated up to the WFE)

·         Query component (this is the component that receives the user’s query and looks up the results in the special files that have been propagated to the hard drive of the WFE)

The Server Name column shows that the Search Administration, Crawl, and Query components are currently running on the existing server.  The search-related databases are running on the SQL Server.

You want to do the following:

1.       Move the Search Administration component to the new Application Server

2.       Move the Crawl component to the new Application Server

3.       Leave the Database component running on the SQL Server

4.       Leave the Query component running on the WFE

To accomplish this, click on the Modify button to go to the Topology for Search Service Application page

By hovering your mouse over the component lines, you can bring up a drop down menu and select Edit Properties for the components you want to move to the new server. 

Do this now for the Search Administration component.

Now do it the same way for the Crawl component. Once you have changed the server assignments for these two components, you need to kick of the actual transfer of responsibilities by clicking on Apply Topology Changes.

When it is finished, you will be returned to the Search Administration home page and you should see that the components have been transferred as directed and all of the search-related servers should have a status of “Online”:

Transferring the remaining Service Applications

All that is left is to use the Services on Server page in Central Administration to make sure the list of services running on each server matches your master list from above:

You want the Web Front-End to run these (and only these) services:

1.       Microsoft SharePoint Foundation Web Application (this is what turns IIS into a SharePoint page-serving machine)

2.       Search Query and Site Settings Service (the process that takes the user’s query string and looks it up in the index)

3.       SharePoint Server Search Service (only the functionality that is necessary for the query processor)

4.       Central Administration.

You want the Application Server to run these (and only these) services:

1.       Access Database Service

2.       Application Registry Service

3.       Business Data Connectivity Service

4.       Excel Calculation Services

5.       Managed Metadata Web Service

6.       Microsoft SharePoint Foundation Incoming E-mail

7.       Microsoft SharePoint Foundation Workflow Timer Service

8.       PerformancePoint Service

9.       Secure Store Service

10.   SharePoint Server Search (only the scheduled content crawling and indexing building functionality)

11.   User Profile Service

12.   Visio Graphics Service

13.   Web Analytics Data Processing Service

14.   Web Analytics Web Service

15.   Word Automation Services

16.   Word Viewing Service

To do this, you use the Server drop-down control to select the server you want to adjust, and then use the Start/Stop link in the Action column to turn on/off the services.

1.5             Testing and Verifying

Below are the steps to for testing:

1.       Browse to each of the SharePoint web applications and log in with your user account and make sure you can hit the home page of each of them.

2.       In the opened sites, try to open up and edit a document in the browser using one of the Office 2010 Web Apps (Word, PowerPoint, Excel or OneNote).

3.       Browse to your My Site and verify that everything is working normally.

4.       Add a unique phrase to a test page somewhere in one of your Sites and then go run an incremental Search crawl from Central Administration.  After the crawl completes, go back to your Site Collection and search for the phrase.  Verify that it comes up in the results.

5.       Run an incremental User Profile Synchronization from the User Profile Administration page.  While it is running, logon to the desktop of the new Application Server, and find this program and run it:  c:\program files\microsoft office servers\14.0\synchronization service\uishell\miisclient.exe.  This is the Forefront Identity Management (FIM) client application that you can use to see the details of the AD synchronization process.  Several jobs will be run by FIM.  Verify that they all complete successfully with no error messages.

6.       In Central Administration, go into Manage Service Applications and click on Managed Metadata Service and select Manage in the ribbon.  Verify that the Term Store management interface loads and that you can add/change/delete a Term Set and some Terms.

7.       Finally, reboot your WFE and Application Server.  When they come back up, check your Windows System and Application event logs on those servers and verify that there are no SharePoint-related critical or warning events that you haven’t seen before you scaled out to three tiers.

8.       Browse to your primary web application one final time.

There are many different reasons why a company might want to scale out to three-tiers from two.  Some kind of performance improvement is frequently what drives it.  However, it may not be the obvious one of desiring better page serving times for the end users.  For instance, I frequently see companies do this to move the search crawling and index building process to a different server that is more tuned for its unique resource requirements and can do a more efficient job of crawling and indexing the company’s content.  Perhaps in the two-tier approach their crawl\index component can’t get enough hardware resources to crawl through all of the content on a timely basis.

One more point.  Many organizations will also choose to add a second WFE when they scale out to a three-tier farm.  (I don’t show this in the diagram above).  The second WFE will be configured exactly like the first one and some type of network load balancing (NLB) mechanism will be put in front of the WFEs to intelligently route user traffic to the two servers to balance out the load.   In this scenario, the three-tier farm diagram above would be modified to add a second WFE and the total number of servers in the SharePoint farm would be four.

Hardware requirements—web servers, application servers, and single server installations

Minimum recommended services for development environments

The following are the minimum SharePoint 2013 services and service applications that are recommended for development environments:

• App Management service application
• Central Administration web site
• Claims to Windows Token service (C2WTS)
• Distributed cache service
• Microsoft SharePoint Foundation 2013 Site and Subscription Settings service
• Secure Store Service
• User Profile service application (SharePoint Server 2013 only)

Minimum software requirements

This section provides minimum software requirements for each server in the farm.

Minimum requirements for a database server in a farm:

• One of the following:
  • The 64-bit edition of Microsoft SQL Server 2012.
  • The 64-bit edition of SQL Server 2008 R2 Service Pack 1
• The 64-bit edition of Windows Server 2008 R2 Service Pack 1 (SP1) Standard, Enterprise, or Datacenter or the 64-bit edition of Windows Server 2012 Standard or Datacenter
• Microsoft .NET Framework version 4.5

Business Intelligence Overview

-          Definition

-          Architecture

-          Source systems /OLTP

-          ETL process

-          Data Warehouses /OLAP

-          OLTP vs. OLAP

-          ODS and Data Marts

-          Data Warehouse Design Approaches

-          Dimensional Modeling

-          From Enterprise models to Dimensional models

-          Schema Types: Star, Snowflake, Fact Constellation

-          Conclusion

Definition
The term business intelligence (BI) refers to technologies, applications and practices for the collection, integration, analysis, and presentation of business information. The purpose of business intelligence is to support better business decision making. BI systems provide historical, current, and predictive views of business operations, most often using data that has been gathered into a data warehouse or a data mart and occasionally working from operational data.

BI enables enterprises

• Measure performance and trends
• To use analytic information strategically
• Unlock the value of its information
• Identify opportunities
• Improve efficiency
• Do competitive analysis..
• to find the Cause
• data Mining
• Etc.

Examples

• Cause & predictive analysis: Credit cart annual fee
• Performance and trends: Region total sales / our sales
• Competitive: Our sales / competitor sales in a particular region or a location, etc,
• Right timing: Bank customer accounts (pattern changes)
• Data mining:  market basket analysis

Architecture

Architecture cont…

Typical BI architecture has the following components:

•  A source system, also called Operational system—typically an online transaction processing (OLTP) system, but other systems or files that capture or hold data of interest are      also possible.

•  An extraction, transformation, and loading (ETL) process.

•  A data warehouse—typically an online analytical processing (OLAP) system.

•  A business intelligence platform such as Microstrategy.

Source Systems (OLTP)

An operational system is a term used in data warehousing to refer to a system that is used to process the day-to-day transactions of an organization. These systems are designed so processing of day-to-day transactions is performed efficiently and the integrity of the transactional data is preserved.

                Sometimes operational systems are referred to as operational databases, transaction processing systems, or on-line transaction processing systems (OLTP). In OLTP — online transaction processing systems relational database design use the discipline of data modeling and generally follow the Codd rules of data normalization in order to ensure absolute data integrity.

Source Systems examples

-          Account transactions in a Bank

-          Sales transactions in a Retail outlet.

-          Inventory management transactions in a warehouse

-          Workforce management transactions such as attendance, vacations, overtime tracking, etc.

-          Operational expenditure systems

-          External sources such as industry information like elasticity  or demand of a product from a third part sources in Retail domain.

-          Etc.

ETL – Extraction, Transformation and Loading

The Extraction, Transformation, and Loading (ETL) process represents all the steps necessary to move data from different source systems to an integrated data warehouse.

The ETL process involves the following steps:

-          Data is gathered from various source systems.

-      The data is transformed and prepared to be loaded into the data warehouse. Transformation procedures can include converting data types and names, eliminating unwanted data, correcting typographical errors, aggregating data, filling in incomplete data, and similar processes to standardize the format and structure of data.

-      The data is loaded into the data warehouse.

Data Warehouse (OLAP)

A Data Warehouse, in its simplest perception, is no more than a collection of the key pieces of information used to manage and direct the business for the most profitable outcome.  

- According to Bill Inmon, “a data warehouse is a

• subject-oriented,
• integrated,
• nonvolatile,
• time-variant

 collection of data in support of management decisions”.

- Ralph Kimball states that a data warehouse is “ a copy of transaction data specifically structured for Query and Analysis”.

OLAP

OLAP: a category of software tools that provides analysis of data stored in a database. OLAP tools enable users to analyze different dimensions of multidimensional data. For example, it provides time series and trend analysis views. OLAP often is used in data mining.

OLAP Analysis

Imagine an organization that manufactures and sells goods in several states of USA

During the OLAP analysis, the top executives may seek answers for the following:

-          Number of products manufactured.

-          Number of products manufactured in a location

-          Number of products manufactured on time basis within a location.

-          Number of products manufactured in the current year when compared to the previous year.

-          Sales Dollar value for a particular product.

-          Sales Dollar value for a product in a location.

-          Sales Dollar value for a product in a year within a location.

-          Sales Dollar value for a product in a year within a location sold or serviced by an employee.  

OLTP / OLAP

DW related: ODS and Data Marts

ODS (Operational Data Store) - This has a broad enterprise wide scope, but unlike the real enterprise data warehouse, data is refreshed in near real time and used for routine business activity.

Data Mart – is a subset of data warehouse and it supports a particular region, business unit or business function 

ODS and DW use case

In a pharmaceutical company

Customer ODS is used for:

                - sending new product details,

                - promotional activities,

                - and scheduling appointments.

DW is used to answer:

                - In a month, what is the total value of medicines prescribed by a Doctor?           

                - What is our company share

                - Is he missing any info from us.

Data Warehouse design approaches

Kimball - Let everybody build what they want when they want it, we'll integrate it all when and if we need to. (BOTTOM-UP APPROACH)

Pros:      fast to build, quick ROI, nimble

Cons:     harder to maintain as an enterprise resource, often redundant, often difficult to integrate data marts

Inmon - Don't do anything until you've designed everything. (TOP-DOWN APPROACH)

Pros:      easy to maintain, tightly integrated

Cons:     takes way too long to deliver first projects, rigid

Dimensional data modeling

•       Dimensional data modeling is

–      A logical design technique

                that seeks to

–      present the data in a standard frame work

                that is

–      intuitive and allows high-performance access.

•       A data model specifically for designing data warehouses

•       The method was developed based on observations of practice, and in particular, providing data in “user-friendly” form.

Step 1. Classify Entities

Transaction Entities

-          An event happened at a point of time

-          contains measurements or quantities

Component Entities :

-          directly related to a transaction entity

-          Component entities answer questions like “who”, “what”, “when”, “where”, “how” and “why” of a business event.

In a sales application transaction entities are:

                Customer: who made the purchase                                                       

   Product: what was sold

                Location: where it was sold

                Period: when it was sold

Classification Entities:

-          related to component entities by a chain of one-to-many relationships

-          represent hierarchies embedded in the data model

Step 2. Identify Hierarchies

•       A hierarchy in an Entity Relationship model is any sequence of entities joined together by one-to-many relationships, all aligned in the same direction.

Step 3. Produce Dimensional Models

Operators For Producing Dimensional Models

                Operator 1: Collapse Hierarchy

                Operator 2: Aggregation

There is a wide range of options for producing dimensional models from an Entity Relationship model.

These include:

                Star Schema

                Snowflake Schema

                Constellation / Integrated Schema

Star Schema

A star schema consists of one large central table called the fact table, and a number of smaller tables called dimension tables which radiate out from the central table

•       A fact table is formed for each transaction entity. The key of the table is the combination of the keys of its associated component entities.

•       A dimension table is formed for each component entity, by collapsing hierarchically related classification entities into it.

Sample Star Schema

Snowflake Schema

A snowflake schema is a star schema with all hierarchies explicitly shown.

Star vs. Snowflake

Fact constellation schema

The fact constellation architecture contains multiple fact tables that share many dimension tables

Constellation /Integrated Schema

A constellation schema consists of a set of star schemas with hierarchically linked fact tables.

Step 4. Evolution and Refinement

• Check if we can Combine any Fact Tables
• Check if we can Combine any Dimension Tables
• Handling Subtypes.

MicroStrategy Architecture and Product suite

• Overview and Architecture
• MicroStrategy Platform
• MicroStrategy Intelligent Server
• MicroStrategy Architect
• MicroStrategy Desktop
• MicroStrategy Web
• MicroStrategy Administrator
  • MicroStrategy Object Manager
  • MicroStrategy Command Manager
  • MicroStrategy Enterprise Manager
• MicroStrategy Distribution Services
• MicroStrategy Office
• MicroStrategy Mobile
• MicroStrategy OLAP Service
• MicroStrategy Report Services
• MicroStrategy Integrity Manager
• MicroStrategy SDK

Typical MicroStrategy Architecture

MicroStrategy Platform

Layers of MicroStrategy Platform

• Data layer consists of Metadata Repository, Relational Data warehouses, Non-Relational Data Stores.

        The Metadata repository contains information used by all the MicroStrategy products.

• Interactive reporting and Analysis layer allows users to perform on-demand reporting and data manipulation.
• Information Delivery and Alerting allows users to receive proactive information delivery services, delivered on a schedule or only when a certain condition is triggered.
• Design and Administration products allow speeding up project development and enabling fast, simple and centralized administration.

Intelligence Server
MicroStrategy Intelligence Server — architectural foundation and core component of the MicroStrategy system provides a powerful, comprehensive set of features necessary for a scalable, fault-tolerant, enterprise-wide business intelligence system; which provides the core analytical processing and  job management for all reporting, analysis and monitoring applications.
    It consists of :

• SQL Engine
• Query Engine
• Analytical Engine

Architect
MicroStrategy Architect is a rapid development tool that maps the physical structure of your database into a logical business model consisting of Schema objects. These mappings are stored in a centralized metadata repository. These schema objects are used to build reports and other objects.

Desktop

MicroStrategy Desktop is a Client/Server application used to create reports, documents, other reporting objects and manipulate result sets. It provides integrated querying and reporting, powerful analytics, decision support workflows and enables to perform complex types of online analysis of data.

    It is available in 2 versions:

• Desktop designer - Full featured version supporting complete functionality.
• Desktop analyst - Simplified version supporting basic interactive functionality.

Desktop Screenshot

Web
 MicroStrategy Web is a reporting interface for end users that offers interactive reporting and analysis through a web browser and provides access to extensive report generation, document creation, manipulation and formatting capabilities with data browsing and drilling.
    It is available in 3 versions:

• Web Professional - Full featured version that allows to create Intelligent cubes and reports.
• Web Analyst - Simplified version that allows ad hoc analysis from intelligent cubes.
• Web Reporter - Enterprise reporting version allows to view scheduled reports.

Web Screenshot

Administrator
MicroStrategy Administrator provides system administrators with a comprehensive set of tools to monitor manage and automates their BI Infrastructure by providing the centralized user and object management and performance monitoring that is critical for rolling out high performance, secure applications to small internal audiences or large Extranets.

    It consists of following components:

• Object Manager - It enables to manage distributed environments for Change management, Versioning, Internationalization from a single interface and provides Full object life cycle management from development and testing to production. Its four components are Manager, Project Merge Wizard, User Merge Wizard and Repository Translation Wizard.
• Enterprise Manager - It provides prebuilt reports and dashboards that enable to monitor MicroStrategy usage patterns and activities. It also helps to monitor system, user and group activity to tune performance and resource utilization.
• Command Manager - It is used to automate administrative tasks which enables to reduce workload and increase efficiency. It provides a fast and easy way to perform necessary and repetitive tasks.

Distribution Services

MicroStrategy Distribution Services - an add-on component available for MicroStrategy Intelligence Server that offers business performance monitoring and automated information distribution.

MicroStrategy platform also consists of the following products:

• MicroStrategy Office - this add-on enables power analysts and end users to run and analyze reports in Microsoft Excel,     Word, or PowerPoint.
• MicroStrategy Mobile - an interactive interface to the MicroStrategy BI platform that lets mobile business users run reports and dashboards directly from their BlackBerry mobile devices from Research in Motion.
• MicroStrategy OLAP Services - an add-on component available for MicroStrategy Intelligence Server that provides MicroStrategy Desktop, MicroStrategy Office, and MicroStrategy Web users with faster and more extensive analytics as part of In-Memory BI.
• MicroStrategy Report Services - an add-on component available for MicroStrategy Intelligence Server that enables business users to easily create and analyze Pixel-Perfect dynamic enterprise dashboards, scorecards, or production reports from multiple sources of data.
• MicroStrategy Integrity Manager - an application that automates the detection of inconsistencies and errors in your BI environment.
• MicroStrategy SDK - a collection of programming tools, utilities, documentation, and libraries of functions or classes that are designed to enable users to customize and extend MicroStrategy products and to integrate them within other applications.

MicroStrategy Architect and Project Design

• Overview of MicroStrategy Architect and Schema Objects
• Roles of MicroStrategy Architect and its importance
• Building Logical table design and Warehouse catalogue
• Architect Interface
• Creating Project Tables, Facts, Attributes and its relationships and hierarchies

Overview of MicroStrategy Architect and Schema Objects
MicroStrategy Architect provides a set of tools that are used to create new projects and modify the structure of existing projects.
It enables to perform the following tasks:

• Initially populate the metadata
• Create schema objects

The role of the metadata in generating report and document results

Any time you create, modify, or remove any type of project object, those changes are stored in the metadata.

Creating Schema Objects
The most fundamental objects stored in the metadata are schema objects. The basic schema objects are:

Roles of MicroStrategy Architect and its Importance
MicroStrategy Architect supports the following project functions :

• Reporting
• Drilling
• Browsing

MicroStrategy Architect and Reporting
Attributes and metrics are two of the most frequently used objects in designing reports. Metrics consist of facts, which are also schema objects.

MicroStrategy Architect and Drilling
The basic drilling options available for a report directly relate to the definition of following items in MicroStrategy Architect:

• Relationships between attributes
• Hierarchies and their drilling configuration

MicroStrategy Architect and Browsing
MicroStrategy Architect is used to create and define hierarchies, which determine the various paths for browsing attributes.

Building Logical table design and Warehouse catalogue

Logical Data Model
The first step in project design process is to design the logical data model. Logical Data Model is a diagram that shows what information is to be analyzed in a project and seen in reports and how that information is related. It depicts the flow of data in an organization but does not show the physical structure of how the information is stored in the data warehouse.
Simple Logical Data Model

Logical Data Model components
A logical data model includes the following three components :

• Facts
• Attributes
• Hierarchies

Facts
Facts are measures that are used to analyze  business. Fact data is typically numeric, and it is generally aggregated. In MicroStrategy projects, facts map to fact schema objects, which form the basis for all the metrics you use in reports. The other components of a logical data model provide context for the facts.

Attributes
Attributes are descriptive data that provide context for analyzing facts. Attributes provide levels for aggregating and qualifying fact data. They map to attribute schema objects, which describe the metrics on reports.

Attribute Relationships
They help to join data from different attributes and aggregating fact data to different levels. Attributes are related to each other in 2 ways :
•    Direct - A parent-child relationship exists between two or more attributes.
•    Indirect - Two or more attributes are related only through a fact or set of facts.

Types of Direct Relationships

Hierarchies
Hierarchies are groupings of directly related attributes ordered to reflect their relationships. Hierarchies contain only attributes that are directly related to each other. Attributes in one hierarchy are indirectly related to attributes in other hierarchies.
Structure of a Logical Data Model
When all components - facts, attributes and their relationships, and hierarchies are put together we have a logical data model.

Creating a Logical Data Model
Factors that influence the design of the logical data model :

• User reporting requirements
• Existing source data
• Technical and performance considerations

User reporting requirements
The Logical data model should take into account the reporting requirements of end users. It should include all information needed for reports and must not include any information captured  in source systems that is not needed for reports.

Existing Source Data
The Logical data model should take into account what source data is available for use. It should be ensured through an initial review of source systems that sufficient source data is present to support user reporting requirements.

Technical and Performance Considerations
Many technical and performance factors affect the design of logical data model, mostly with regard to its size and complexity. Technical factors are Robustness of database server and software, Network bandwidth and Volume of concurrent users. Complex user reporting requirements or source data structures pose greater challenges to delivering optimal performance.

Steps to Create a Logical Data Model
Factors that influence the design of the logical data model :

• List all the information from the source data needed to include in the logical data model
• Identify which items are facts
• Identify which items are attributes
• Determine the direct relationships between attributes
• Organize directly related attributes into hierarchies

Introduction to Physical Schema
The second step in the project design process is to design the data warehouse schema.
             A physical schema is a detailed, graphical representation of the physical structure of a database. The physical schema is designed  based on the organization of the logical data model. While the logical data model shows the facts and attributes, the physical schema shows how the underlying data for these objects is stored in the data warehouse.

Physical Schema Components
A physical schema includes the following two primary components:

• Columns
• Tables

Column Types
In a data warehouse, the columns in tables store fact or attribute data. The following are the three types of columns:

• ID Columns
• Description Columns
• Fact Columns

Table Keys
Every table has a primary key that consists of a unique value that identifies each distinct record (or row) in the table. There are two types of primary keys :

• Simple Key
• Compound Key

Lookup Tables
Lookup tables store information about attributes, including their IDs and any descriptions. They enable you to easily browse attribute data. Depending on the design of physical schema, a lookup table can store information for a single attribute or multiple related attributes.

Relationship Tables
Relationship tables store information about the relationship between two or more attributes. They enable you to join data for related attributes. To map the relationship between two or more attributes, their respective ID columns must exist together in a relationship table.

One-to-One Relationship
For one-to-one relationship, there is no separate relationship table and separate lookup table for the parent attribute. Instead, the parent is directly placed in the lookup table of the child attribute to map the relationship between the two attributes.

One-to-Many Relationship
For a one-to-many relationship, there is no need to have a separate relationship table. Instead, the parent-child relationship can be defined by including the ID column for the parent attribute in the lookup table of the child attribute.

Many-to-Many Relationship
For a many-to-many relationship, a separate relationship table with the IDs of parent and child attributes is created to map the parent-child relationship.
Fact Tables
Fact tables store fact data and attribute ID columns that describe the level at which the fact values are recorded. They enable to analyze fact data with regard to the business dimensions or hierarchies those attributes represent.

Base and Aggregate Fact Tables
Base fact tables are tables that store a fact or set of facts at the lowest possible level of detail. Aggregate fact tables are tables that store a fact or set of facts at a higher, or summarized, level of detail.
Schema Types
The type of schema design for the data warehouse depends on the nature of the data, how users want to query the data and other factors unique to the project and database environments. Commonly used schema designs :

• Completely normalized schema
• Moderately denormalized schema
• Completely denormalized schema

Normalized Versus Denormalized Schemas
Normalization occurs whenever there is a schema design that does not store data redundantly. Denormalization occurs whenever there is a schema design that stores at least some data multiple times, or redundantly.
Completely Normalized Schema
A completely normalized schema does not store any data redundantly.

Moderately Denormalized Schema
A moderately denormalized schema stores some data redundantly.

Completely Denormalized Schema
A completely denormalized schema stores the maximum amount of data redundantly.

Creating a Data Warehouse Schema
The following factors influence the design of the schema :

• User reporting requirements
• Query performance
• Data volume
• Database maintenance

Architect Interface

Introduction to Architect
Overview of Architect Components
The Architect graphical interface consists of several components that combine most of the functions of the Project Creation Assistant with most of the functions of the schema object editors.
The Architect graphical interface has the following components:

• Warehouse Tables pane
• Project Tables View tab
• Hierarchy View tab
• Properties pane
• Project objects pane
• Menu bar
• Toolbar

Architect Interface
Architect Graphical Interface

Warehouse Tables Pane
The Warehouse Tables pane enables to view database instances and their associated tables and select the tables to be included in a project. The Warehouse Tables pane also displays only database instances that have been associated to the project.

Project Tables View Tab
The Project Tables View tab displays images of the tables used in a project. It uses layers to display the tables. The All Project Tables layer enables to view all the tables used in a project. This layer exists by default when a project is created.

Hierarchy View Tab

The Hierarchy View tab displays all of the attributes that have been created in a project. This tab is used to create, modify, and remove relationships between attributes, which builds the system hierarchy. It can also be used to create, modify, and remove user hierarchies.

Properties Pane
The Properties pane enables to view and modify the properties for attributes, facts, and tables. It has three tabs-Attributes, Facts, and Tables.
Architect Interface

Project Objects Pane
The Project objects pane enables to view the number of attributes, facts, and tables that have been created in a project. It also shows the project name and the current user.

MicroStrategy Intelligence Server

 MicroStrategy Intelligence Server

• Setting up MicroStrategy Intelligence Server
• Intelligent server configuration, start up and connectivity
• Creating Metadata and Statistics Repositories
• Project Sources, connectivity and MicroStrategy Projects
• Defining and setting up the MicroStrategy reporting Environment

MicroStrategy Intelligence Server

MicroStrategy Intelligence Server provides the core analytical processing and  job management for all reporting, analysis and monitoring applications.

Setting up MicroStrategy Intelligence Server

Configuration Wizard

Metadata Connection

MicroStrategy Authentication

Server Definitions

Settings

Summary

Intelligent server configuration, start up and connectivity

Intelligent server configuration, start up and connectivity contd.

Creating Metadata and Statistics Repositories

Configuration Wizard

Repository Types

Metadata Tables

Summary

History List Tables

Summary

Statistics Tables

Project Sources, connectivity and MicroStrategy Projects

Configuration Wizard

Project Source Name

Metadata Location

Authentication

Summary

Defining and setting up the MicroStrategy reporting Environment

Configuring the MicroStrategy Reporting Suite – Connectivity Wizard

Driver Selection

Driver Details

DSN Created

MicroStrategy BI vs. Microsoft BI Compared

The overview of this document is to provide the capabilities of MicroStrategy and Microsoft BI (SSAS, SSRS and PPS), and guide appropriate tool for the business need based on business requirements, maintenance and support perspective.

Disclaimer: Information provided in this document is for reference use only. Information in this document prepared based on projects experience, Microsoft.com, MicroStrategy.com and web search, and information in this document does not guaranty full accuracy of the items explained. For any questions or concerns please contact info@netpeach.com

MicroStrategy BI vs. Microsoft BI Compared in details

Context	Microsoft BI Stack	MicroStrategy BI Stack	Remarks
Product Architecture (Tool set)	- Microsoft BI Stack combines various products to make complete BI: SQL Server 2008 R2, SharePoint 2010, Excel 2010 - Tool set: SSAS, SSRS, Report Builder, Performance Point Services (PPS) for Standard reporting and dashboards. - Microsoft version of Self Service BI: Power Pivot, Power view of Excel,	- MicroStrategy 9.2.1 - Tool Set: Intelligence Server, Web, Mobile, Report Services, OLAP Services, Distribution Services, etc.	- Microsoft BI requires disparate multiple products whereas MicroStrategy is a single unified platform for enterprise BI. - Microsoft has traditionally served smaller organizations and departmental applications. Microsoft BI remains unproven in the ability to cost effectively support large data and user scales while providing adequate performance.
Capabilities	- SSRS: Report Development and subscription - PPS: KPIs, Score Cards and Dash boards development - Excel BI: Connect to any ODBC /OLE DB Source and model the data for a specific analysis or self-service BI.	- Report development, querying, analysis, dash board development and subscription. - Drill anywhere: Users can seamlessly drill anywhere for boundary-free investigative analysis, regardless if the data is in one or multiple data sources. - Self-service BI using preconfigured report objects.	- Microsoft Reporting Services doesn’t have a unified semantic business layer across the data compared to an integrated unified architecture of MicroStrategy offering all styles of BI. With this limitation Microsoft end users cannot access report models and create reports from scratch using reusable metadata through Excel. - In Microsoft Reporting Services, each report references a specific datasource and doesn’t share any subcomponents of the report like attributes, metrics, filters etc. - Lack of Automatic Drill Anywhere: Microsoft does not have automatic drill anywhere capabilities across reports. All drill paths across cubes and across reports have to be manually pre-defined by IT or report developers.

MicroStrategy BI vs. Microsoft BI Compared in details Cnt

MicroStrategy BI vs. Microsoft BI Compared in details Cnt

MicroStrategy BI vs. Microsoft BI Compared in details Cnt

MicroStrategy BI vs. Microsoft BI Compared in details Cnt

MicroStrategy BI vs. Microsoft BI Compared in details Cnt

Microsoft BI vs. MicroStrategy BI Compared in details Cnt.