Global Environments
May 20, 2008
In a globalised Business Intelligence deployment, three key aspects are becoming increasingly important; standardisation, manageability and process integration.
• Global businesses require simple, standardised solutions which can be managed effectively by non-specialists.
• Development teams need to use industry standard tools to develop robust, easily maintained, Business Intelligence applications.
• Businesses need to integrate BI into their existing infrastructure, either to provide security or to deliver additional value from an existing application.
Logi9 delivers effectively against all of these three challenges.
The Next Wave of BI
May 20, 2008
Progress comes in waves, each wave building on the last. Increasing standardisation delivers more functionality from fewer lines of application code, while increases in processing power make seemingly insurmountable computing tasks today an everyday occurrence tomorrow.
We believe that we are seeing the start of the third wave of the development and adoption of business intelligence tools. These tools fully leverage industry standard technology platforms such as .Net or Java. At the forefront of these developments is the Unified Business Intelligence platform from LogiXML, Logi9.
Logi9 delivers the same functionality as competing platforms for 10-15% of the investment, both in terms of software acquisition and total cost of ownership throughout the lifecycle of the solution. This is achieved by the aggressive adoption of industry standards and compliant technologies.
The pioneers who made up the second wave of Business Intelligence needed to build their solutions from the ground up. Solutions contained the reporting tools but in many cases the application server, portal technology and authentication mechanisms were also proprietary.
However, having set the standard for functionality, the resulting software became complex and clumsy, with multi-year release cycles for product enhancements becoming the norm. These legacy tools, with their proprietary technology, typically need specialist staff to both manage and maintain the solutions built with them. They become difficult to maintain in the face of changing business and technology requirements.
In today’s business environment, responding to change will become a key differentiator.
The next wave in Business Intelligence software, Logi9, provides your business with the tools to quickly and effectively integrate business intelligence into every decision.
The Star Schema
May 17, 2008
The Star Schema can be considered as the API for reporting, the concept and use of the star schema was popularised by Ralph Kimball, although the approach was developed over many years by leaders in the data management industry.
The current lingua franca of Business Intelligence, the star schema is in effect the API upon which most Business Intelligence solutions are built.
A star schema defines the business dimensions and encapsulates the measures held against these in a simple easy to navigate structure, with predictable performance characteristics.
The star schema abstracts the business requirement from the underlying data warehouse structures.
The advantages of doing this are found in the effective delivery to requirements, the risks lie in the level of abstraction required.
The article below describes the concepts of the star scema:
Fact Tables and Dimension Tables
The logical foundation of dimensional modeling
by Ralph Kimball
Dimensional modeling is a design discipline that straddles the formal relational model and the engineering realities of text and number data. Compared to entity/relation modeling, it’s less rigorous (allowing the designer more discretion in organizing the tables) but more practical because it accommodates database complexity and improves performance. Contrasted with other modeling disciplines, dimensional modeling has developed an extensive portfolio of techniques for handling real-world situations.
[AD]
Measurements and Context
Dimensional modeling begins by dividing the world into measurements and context. Measurements are usually numeric and taken repeatedly. Numeric measurements are facts. Facts are always surrounded by mostly textual context that’s true at the moment the fact is recorded. Facts are very specific, well-defined numeric attributes. By contrast, the context surrounding the facts is open-ended and verbose. It’s not uncommon for the designer to add context to a set of facts partway through the implementation.
Although you could lump all context into a wide, logical record associated with each measured fact, you’ll usually find it convenient and intuitive to divide the context into independent logical clumps. When you record facts — dollar sales of a grocery store purchase of an individual product, for example — you naturally divide the context into clumps named Product, Store, Time, Customer, Clerk, and several others. We call these logical clumps dimensions and assume informally that these dimensions are independent. Figure 1 shows the dimensional model for a typical grocery store fact.
In truth, dimensions rarely are completely independent in a strong statistical sense. In the grocery store example, Customer and Store clearly will show a statistical correlation. But it’s usually the right decision to model Customer and Store as separate dimensions. A single, combined dimension would likely be unwieldy with tens of millions of rows. And the record of when a given customer shopped in a given store would be expressed more naturally in a fact table that also showed the Time dimension.
The assumption of dimension independence would mean that all the dimensions, such as Product, Store, and Customer, are independent of Time. But you have to account for the slow, episodic change of these dimensions in the way you handle them. In effect, as keepers of the data warehouse, we have taken a pledge to faithfully represent these changes. This predicament gives rise to the technique of slowly changing dimensions, the subject of the next column in this series.
Dimensional Keys
If the facts are truly measures taken repeatedly, you find that fact tables always create a characteristic many-to-many relationship among the dimensions. Many customers buy many products in many stores at many times.
Therefore, you logically model measurements as fact tables with multiple foreign keys referring to the contextual entities. And the contextual entities are each dimensions with a single primary key. (See Figure 1.) Although you can separate the logical design from the physical design, in a relational database fact tables and dimension tables are most often explicit tables.
Actually, a real relational database has two levels of physical design. At the higher level, tables are explicitly declared together with their fields and keys. The lower level of physical design describes the way the bits are organized on the disk and in memory. Not only is this design highly dependent on the particular database, but some implementations may even “invert” the database beneath the level of table declarations and store the bits in ways that are not directly related to the higher-level physical records. What follows is a discussion of the higher level only.
A fact table in a pure star schema consists of multiple foreign keys, each paired with a primary key in a dimension, together with the facts containing the measurements. In Figure 1, the foreign keys in the fact table are labeled FK, and the primary keys in the dimension tables are labeled PK. (The field labeled DD, special degenerate dimension key, is discussed later in this column.)
I insist that the foreign keys in the fact table obey referential integrity with respect to the primary keys in their respective dimensions. In other words, every foreign key in the fact table has a match to a unique primary key in the respective dimension. Note that this design allows the dimension table to possess primary keys that aren’t found in the fact table. Therefore, a product dimension table might be paired with a sales fact table in which some of the products are never sold. This situation is perfectly consistent with referential integrity and proper dimensional modeling.
In the real world, there are many compelling reasons to build the FK-PK pairs as surrogate keys that are just sequentially assigned integers. It’s a major mistake to build data warehouse keys out of the natural keys that come from the underlying data sources. I discuss this fascinating and intricate topic in detail in a pair of Intelligent Enterprise columns, “Surrogate Keys” and “Pipelining Your Surrogates,” which you can find in my article archive at www.kimballuniversity.com or at www.intelligententerprise.com.
Reports; the Building Blocks of BI
May 17, 2008
re·port (r-pôrt -prt)
n.
1. An account presented usually in detail.
Reports are the basic building blocks of Business Intelligence (BI) and like the humble building brick often ignored or underestimated.
Reports are the lifeblood of any business interaction, clear concise reports deliver the information which supports effective decisions and negotiations.
However the report as a source of requirements can prove to be unreliable.
Design your solutions to deliver information and then package the information into effective reports ……………….
OLAP and Analytics
May 17, 2008
an·a·lyt·ics (n-ltks)
n. (used with a sing. or pl. verb)
The branch of logic dealing with analysis.
Taken from http://searchcio.techtarget.com/
“OLAP (online analytical processing) is computer processing that enables a user to easily and selectively extract and view data from different points-of-view. For example, a user can request that data be analyzed to display a spreadsheet showing all of a company’s beach ball products sold in Florida in the month of July, compare revenue figures with those for the same products in September, and then see a comparison of other product sales in Florida in the same time period. To facilitate this kind of analysis, OLAP data is stored in a multidimensional database. Whereas a relational database can be thought of as two-dimensional, a multidimensional database considers each data attribute (such as product, geographic sales region, and time period) as a separate “dimension.” OLAP software can locate the intersection of dimensions (all products sold in the Eastern region above a certain price during a certain time period) and display them. Attributes such as time periods can be broken down into subattributes.
OLAP can be used for data mining or the discovery of previously undiscerned relationships between data items.”
An important element of any Business Intelligence deployment, OLAP cubes deliver vital packages of data in a rich and readily consumable form. OLAP has suffered from a lack of standards and remains proprietary technology for most vendors.
The advent of MDX the multi-dimensional query language at the heart of SQL Server SSAS has opened this up slightly, this standard has also been adopted by Cognos in it’s Series 7 and 8 product lines and by the open source project Pentaho.
As hardware capabilities constantly improve and specialised data warehouse ready databases come to the fore the jury is out on the future of OLAP technologies.
OLAP however, for now offers unique functionality which enables rapid analysis of multiple fact tables at different levels of granularity. MDX queries also allow otherwise complex queries to be implemented quickly and easily with a few lines of code. An example of this capability would be the comparison of year to-date sales figures for this year vs. last.
The stand out OLAP implementation in today’s marketplace is Microsoft’s SQL Server SSAS and the best way to extend this capability inside and outside your organisation is by deploying Logi OLAP.
Business Intelligence Defined
May 17, 2008
Business intelligence (BI) is a broad category of applications and technologies for gathering, storing, analyzing, and providing access to data to help enterprise users make better business decisions. BI applications include the activities of decision support systems, query and reporting, online analytical processing (OLAP), statistical analysis, forecasting, and data mining.
Business intelligence applications can be:
1. Mission-critical and integral to an enterprise’s operations or occasional to meet a special requirement
2. Enterprise-wide or local to one division, department, or project
3. Centrally initiated or driven by user demand
4. This term was used as early as September, 1996, when a Gartner Group report said:
By 2000, Information Democracy will emerge in forward-thinking enterprises, with Business Intelligence information and applications available broadly to employees, consultants, customers, suppliers, and the public. The key to thriving in a competitive marketplace is staying ahead of the competition. Making sound business decisions based on accurate and current information takes more than intuition. Data analysis, reporting, and query tools can help business users wade through a sea of data to synthesize valuable information from it - today these tools collectively fall into a category called “Business Intelligence.”
Alleanza: Our History
March 24, 2007
The Alleanza partnership was formed in March 2007 with the objective of providing technology focused consultancy to clients delivering business intelligence and data integration projects.
The partnership has a shared heritage which stems from the professional services organisation of Cognos Inc., recently acquired by IBM, in the UK.
Our focus and passion is the delivery of requirements driven business intelligence solutions which deliver value to our customers.
We believe that business intelligence is a process and that an essential essential component of this process is business driven iterative design and development driven by the business
Our flagship product is Logi9 the unified business intelligence platform from LogiXML.
We have partnerships with Microsoft, IBM and of course LogiXML.
