Comparision of Repository Objects using Workflow Manager?

In order to compare two repository objects of the same type we can use Workflow manager.Using this we can identify the difference between two objects like difference between two Email task.Comparison can be done across Folders and repositories.

Following objects can be compared but we cannot compare objects of different types. For example, you cannot compare an Email task with a Session task.

• Tasks
• Sessions
• Worklets
• Workflows

Steps for Comparing Objects

• Open the folders that contain the Repository objects you want to compare.
• Open the Workflow Manager
•  For tasks, Click Tasks > Compare,For Worklets:Worklets > Compare,For Workflows: Workflow > Compare.
• You can find a dialog box opened.Click Browse to select an object.
• And then Click Compare.

What is a FACT LESS FACT TABLE? Where we use Factless Fact?

We know that fact table is a collection of many facts and measures having multiple keys joined with one or more dimension tables. Facts contain both numeric and additive fields. But factless fact table are different from all these.

A factless fact table is fact table that does not contain fact. They contain only dimensional keys and it captures events that happen only at information level but not included in the calculations level. just an information about an event that happen over a period.

A factless fact table captures the many-to-many relationships between dimensions, but contains no numeric or textual facts. They are often used to record events or coverage information. Common examples of factless fact tables include:

• Identifying product promotion events (to determine promoted products that didn’t sell)
• Tracking student attendance or registration events
• Tracking insurance-related accident events
• Identifying building, facility, and equipment schedules for a hospital or university

Factless fact tables are used for tracking a process or collecting stats. They are called so because, the fact table does not have aggregate table numeric values or information. There are two types of factless fact tables: those that describe events, and those that describe conditions. Both may play important roles in your dimensional models.
Factless fact tables for events
The first type of factless fact table is a table that records an event. Many event-tracking tables in dimensional data warehouses turn out to be factless. Sometimes there seem to be no facts associated with an important business process. Events or activities occur that you wish to track, but you find no measurements. In situations like this, build a standard transaction-grained fact table that contains no facts.

For eg.

The above fact is used to capture the leave taken by an employee. Whenever an employee takes leave a record is created with the dimensions. Using the fact FACT_LEAVE we can answer many questions like

• Number of leaves taken by an employee
• The type of leave an employee takes
• Details of the employee who took leave

Factless fact tables for conditions
Factless fact tables are also used to model conditions or other important relationships among dimensions. In these cases, there are no clear transactions or events. It is used to support negative analysis report. For example a Store that did not sell a product for a given period.  To produce such report, you need to have a fact table to capture all the possible combinations.  You can then figure out what is missing.

For eg, fact_promo gives the information about the products which have promotions but still did not sell

This  fact answers the below questions:

• To find out products that have promotions.
• To find out products that have promotion that sell.
• The list of products that have promotion but did not sell.

This kind of factless fact table is used to track conditions, coverage or eligibility.  In Kimball terminology, it is called a “coverage table.”

Note:

We may have the question that why we cannot include these information in the actual fact table .The problem is that if we do so then the fact size will increase enormously.

Factless fact table is crucial in many complex business processes. By applying you can design a dimensional model that has no clear facts to produce more meaningful information for your business processes. Factless fact table itself can be used to generate the useful reports.

After a Very long time , I had some time to Check for some blogs which i was thinking to Jot down into my blog for further reference

Oracle Business Intelligence - an overview

At work I have to deal with OBIEE ( Oracle Business Intelligence Enterprise Edition ) as a developer and administrator, so I decided to share the amount of knowledge that have accumulated. I hope it will help someone to learn the system.First, I plan to talk about the system as a whole, then - about the architecture and interaction of the components, and in the end - to tell you about those features encountered during the work.

System Overview

Oracle Business Intelligence Enterprise Edition (OBIEE, OBI) - a software platform for solving business analytics: Interactive and published reports, KPI monitoring, and business processes. Is a descendant of Siebel Analytics. Main functional parts are available to users:

• Answers (also called Interactive Dashboards) - build interactive reports available to users through a web interface OBIEE. Reporting unit is the analysis - a simple report usually includes one map (table, graph, chart, etc.). Analysis combined into dashboards (Dashboards), they work with end users. Dashboards can also include invitations (prompts) - setting elements with which the user can interact with the panel.
• Publisher (sometimes it include Delivers) - a means of creating and distributing static reports. Because publisher evolved from a single product, then it has the opportunity to build their own reports on the data model, independent of the data model OBI, but you can use a common model. Also there is the possibility to send existing reports of answers.
• Action Framework - a set of tools to perform any automated action from OBIEE - such as sending reports to achieve a certain measure of value, call external Web services, call java code, etc. Actions can be grouped into chains.Possible to set up different channels alert users - ee-mail, sms, pager, etc.
• Scorecard and Strategy Management - a means to track key performance metrics (KPI) and working with scorecards (Scorecard - http://en.wikipedia.org/wiki/Balanced_scorecard ). Used to visually display the status of implementation of goals (company, project). User access, as is the case with the answers, through a web interface.
• Marketing - integration with Siebel Marketing.
• Office Tools - integration with Microsoft Office.

Architecture

OBIEE, in fact, is the mediator between the data sources and users (user reports). The system does not store the data (excluding caches) - all reports are built "on the fly" by querying data sources (pictures from the book OBI 11g Developer's Guide):

OBIEE supports a variety of data sources, including relational databases, systems OLAP, files and apache hadoop. The system allows you to combine in one report data from different sources, combining them with each other according to the rules. 
At the heart of the system is a common data model (also called repository) - description of the logical model of the business area and bind it to the physical data sources. The model consists of three layers - presentation, business, and physical.The business logic layer is described by the model (which is understandable to end-users), in the form of a multi-dimensional model - the facts and measurements, and describes the binding of logical attributes to physical sources.Presentation allows you to split a logical model for several domains and restrict user access to various parameters and attributes. The physical layer describes the data sources - tables, columns, keys, data cubes. Creating a data model (repository) performs developer using special software - Oracle BI Administration Tool. 
When a user opens a report, presentation server (Presentation Server) generates a query using Logical SQL server BI. BI server parses the request and translates it into queries to data sources in their "native" languages ​​- sql, mdx, etc. After receiving data from source server combines them, conducts various operations on the data (for example, calculates the units if necessary), and returns the result to the server presentations. Presentation server, in turn, renders the data in the web interface or generate static report.

The server part of OBIEE includes several disparate components, some of which is controlled by the application server Weblogic, and the other part there as usual (native) program and managed component oracle process manager (opmn).Also OBIEE uses to store data of the official relational database (Oracle, MS SQL, IBM DB2, or MySQL). OBIEE domain management via a web-interface Weblogic Administration Console and Fusion Middleware Enterprise Management Console.

How does the system work

Suppose there is a need of business users to receive analytical information about the status of any area of ​​the company (for example, sales volumes in riteylingovoy chain stores). How to meet the needs of users with OBIEE? Steps will be approximately as follows (in this case an interactive reports Answers):

1.    Determination of the available data to build reports
have business may already be trained and active data repository for consistent and consolidated data. Then the task easier - we take the data from an existing shop and directly appeal to them of OBIEE. Another thing - if the CD is not available, and there are, for example, data from multiple disparate systems. Typically, these data are in normalized form (NF 3 or higher), and very detailed, which is not good for building reports. In this case, you must design and build a data mart schema type "star" or "snowflake" (or more, depending on the complexity of the data).Showcase can be implemented as tables, or for example, the representations (conventional or materialized).Naturally, this requires constantly working database, capable of withstanding a sufficiently large number of requests.
also possible that the data is available in the form of OLAP - then, as a rule, no revision is not required because this means that the multidimensional data model has been built and operated.

2.    Building a data model
must describe the existing data and bind logical attributes (eg, sales metrics) from the physical attributes in the database or server OLAP. Based on these data constructed multivariate model - description of the data in terms of facts, dimensions, attributes, dimensions and hierarchies.

3.    Creating a repository
now developed a data model should be moved to the repository OBIEE. This is done in the Oracle BI Administration Tool (mentioned just above). Development takes place in three stages - import metadata sources, the construction of the business layer and the presentation layer construction. As a rule, there is only one data source, but there may be more complex scenarios, such as combining data from a relational database and OLAP, or merge data with different levels of granularity from multiple databases. In these cases, the developer must also correctly configure the "relationship" between the sources. Building the business layer is mainly composed of the attribute transfer physical layer description hierarchies, select the types of aggregations of metrics and setting tables for logical sources. Presentation layer usually is a reflection of "1 1" business layer, sometimes broken into separate areas (for example, if want to share access to data for users). Also worth noting is that OBIEE has some funds for the joint development of the repository - there is a possibility of their merging of different versions, and can be stored in the repository as a set of xml files for the convenience of working with version control systems.

4.    Designing Reports
After the formation of the repository and upload it to the server begins main phase - development of reports. First developed separate analyzes, then they are integrated into the information panel. As a rule, each developer is working on its own set of analyzes and dashboards, as funds for joint development is not (all happening in the web interface), and simultaneous editing one will overwrite the work of another :)

A little bit of personal experience

Here I have tried to describe some features of the system that caused the greatest frustration in the development. The list is far from complete, but may be useful in the planning of the system architecture.

• OBIEE not always work correctly with schemes such as "snowflake" in the data model. This means that not always generates the correct SQL query report. As possible to translate such a scheme into a "star" at the business layer.For example, if there is a table "Customer", which refers to a table "class customer" (individual, corporate client, etc.), the business layer is necessary to reduce them to a single logical table "Customer" with a full set of attributes .The situation becomes more complicated when there is communication fact tables through several dimension tables.In such cases it is necessary to monitor the correctness of query generation.
• In OBIEE have the option of drawing up analyzes on the basis of direct queries to the database. This requires a change in the configuration file NQSconfig.INI. This feature often makes life easier if you need to implement an artful display logic, without complicating the model without the need for data. However, in this case, you have to remember which data should have access, business users, and does not give the opportunity to query the database all in a row.
• You have to properly configure caching data tables. In that case, if the data changes are planned during the working day, that people need to see in the reports - you must either disable caching, or manually (via WLST) to update the cache. Also good practice to "warm up" (seeding) cache before workday users so that users can immediately use all reports.
• It should be remembered that the functional dashboards as a Web application is very limited. If you want a serious interactivity for users to interact with the interface, it is better to look towards other BI tools such as stack MS. All that can be obtained in OBIEE - this filter selection, work with data in tables (sorting order of the columns, creating groups, adding the results and the like) and so-called "master-detail" events - when the user can click on the cell in the same table, and in the next graph or table data is automatically filtered by the selected value in the cell. A functional action (actions), but he also is very limited - there is only a transition to a URL, call REST method and transition to other information panel.

Mobile Business Intelligence

In the arsenal of OBIEE also have the means to mobile analytics (using mobile devices):

1.    Oracle BI Mobile - app for ios, which allows you to view the content of dashboards and analysis on the mobile device. The mapping is performed almost without changing the appearance of the report, why it looks a bit in the style of 90-x :)

2.    Oracle BI Moblie App Designer - application that integrates in OBIEE , you can create reports on HTML5 using the data model of OBIEE or Publisher. In fact, it is the generator of web applications - each report consists of several pages, with interactivity and transitions between them. The advantage of this solution is that the application will look the same in the full browser and on the device, and no need to install a separate application. Negative - that the data is not cached on the device, respectively, to use it only if you have an Internet connection. Mobile App Designer was released recently and is not yet included in the basic delivery OBIEE.

Ref: http://www.itshop.ru/Oracle-Business-Intelligence-obzor/l9i35984