Wednesday, August 18, 2010

Multi-Developer OBI EE Environments

In an environment with more than two or three OBI EE developers, it becomes increasingly difficult to coordinate and control code changes and updates to the OBI EE catalog, repository, and BI Publisher XMLP content. The larger the development team, the more likely the chance of two developers updating the same report and inadvertently overwriting each other’s work.

Often, some type of control is enforced by dividing the content into separate areas of responsibility. For example, developer 1 is responsible for maintaining the repository, developer 2 is responsible for all accounting reports, and so on. However, this approach makes resource utilization planning difficult for project managers since work-loads are never equally distributed across the areas of responsibility.

Since OBI EE has no built-in source code control capability, one has to look for third party software that can add this capability to an OBI EE development environment. There are several options including Microsoft Visual SourceSafe, CVS, and Tortoise Subversion (TortoiseSVN), which is an open source version control tool that can be downloaded for free at http://tortoisesvn.net/.

Regardless of the tool, the solution boils down to version control on the OBI EE content files as depicted in the diagram below.



Developers run local instances of the OBI EE environment on their own workstations. All files and subfolders in the OBI EE web catalog folder, the BI Publisher XMLP folder, and the repository files are placed under source code control in a central master repository. Each workstation has a local repository that is synchronized with the master repository via update, check-in, and check-out operations.

The development server, which is mainly used by the business analysts for testing, is another subscriber to the master repository. A simple update from the repository will deploy the most current version to the development server.

Once a developer has checked-out a file, the file is locked in the master repository and no other developer is allowed to change the file until it is checked in again. Thus, no longer can one developer inadvertently overwrite changes of another. In addition, this approach provides the capability to roll back the environment to a previous version.

Saturday, August 7, 2010

eDiscovery - Your Next Crisis?

 For more information on this topic, refer to:

http://www.guident.com/ or contact the author directly at mailto:info@guident.com.

Crisis Brewing

Litigation has a long tradition in the US. Now, as firms and enterprises increasingly shift from paper to digital knowledge assets, that litigation trend is also moving into the digital arena. Ediscovery is a broad term applying to one of a series of responses to a legal "triggering event." That event starts begins an obligation to preserve and disclose data that may be due to a judicial order, or even the mere knowledge of a future legal proceeding that is likely to require preserving and finding relevant information stored in your electronic documents. In the Ediscovery world, these assets are now called Electronically Stored Information or ESI. Ediscovery is a relatively new concept. You could be excused if you are not familiar with the term. In the US, the Federal Rules of Civil Procedure or "FRCP" issued rule 26, and related rules, in December 2007. This update to the FRCP made all ESI "discoverable" just as non-electronic information, usually paper, is discoverable. ESI, eDiscovery, FRCP… these and related acronyms are enough to make your head swim. But keep your head above water and pay attention, because if you are not ready for eDiscovery, you could be in for some serious pain, both to your organization's bottom line and to its reputation.


In our view, eDiscovery is built on a series of tools and best practices that should be present in every enterprise and that everyone should proactively follow. Sadly, few actually do, because these tools and practices are often seen as optional, a distraction from the main business activities. The tools we refer to are Enterprise Content Management (ECM), Records Management (RM) and Search. The best practices, foundation for effective management of ESI, relate to the processes and procedures you follow to oversee all your ESI – records and non-records.

So how do you get started? Meet EDRM, the Electronic Discovery Reference Model, and its sibling, IMRM, the Information Management Reference Model. We told you this wouldn't be simple.

Reference Models



The EDRM group, responsible for both these reference models, is a consortium of vendors and other interested parties wanting to develop comprehensive guidelines, standards, and tools to reduce the incidence of eDiscovery nightmares, or provide ways to cope when they occur. The Electronic Discovery Reference Model (EDRM) provides guidelines, sets standards, and delivers resources to help those who purchase eDiscovery solutions and vendors who provide them, improving the quality of the tools and reducing the costs associated with eDiscovery.

IMRM, shown below, aims to "provide a common, practical, flexible framework to help organizations develop and implement effective and actionable information management programs. The IMRM Project, also part of the EDRM industry working group, aims to offer guidance to Legal, IT, Records Management, line-of-business leaders and other business stakeholders within organizations." This project within the EDRM group suggests ways to facilitate a common approach among these different groups to discuss and make decisions on the organization's information needs.



Although this diagram has the ring of endless numbers of PowerPoint slides you've seen on a variety of topics, it re-iterates some basic, commonsensical ideas that all should adopt but most ignore. We won't go into details about this, but the general themes are obvious. These various different business units, often at odds and seldom understanding each other's language and values, must work together to manage ESI, whether records or not. The result could be that eDiscovery nightmare. Some key takeaways: Decide and oversee the ways your organization creates and saves information. Throw away what isn't needed, keep what you must – all within the corporate requirements for both records and other ESI. IT will benefit (less to back up, archive, and index for search); Legal will be happy you are reducing risk; Records Management will appreciate getting all the help with ESI it can get; and business profits will be shielded somewhat from the risks of bad information management practices.

EDRM



Now what of the EDRM model itself? Again, this is not an easy concept but still critical to prepare for that inevitable crisis.

To understand this model, courtesy EDRM (edrm.net), read left to right and notice how the process sifts through huge volumes of ESI and aims to focus on the important, most relevant pieces. EDRM has eight ongoing projects to fill out the details of their goals to "establish guidelines, set standards, and delivering resources."




IMRM is related to the left-most process, "Information Management," but don't view it as a picture of Information Management itself. Instead, think of IMRM as a way of promoting cross-organizational dialog – always important, critical if that eDiscovery request comes a knocking.

So those two models give you the grand overview. In upcoming posts, we'll look at the elements of these models in greater detail. We also spoke with several leading eDiscovery tools vendors recently. We'll tell you their views and our impressions about the vendor involvement with EDRM in general. Are vendors just giving a new name to the same old products, or jumping onto the "next big thing" so they don't get left behind, or are they up to something truly useful , for eDiscovery and maybe morein this collaborative effort?

In a subsequent post we'll look at the first element of the EDRM model, Information Management. You'll see what vendors had to say and our assessment about how their views provide insights for you to get started preparing for, or better still avoiding, that next crisis.

For more information on this topic, refer to:

http://www.guident.com/ or contact the author directly at mailto:info@guident.com.


Friday, August 6, 2010

The Need for Performance and Portfolio Management

For more information on this topic, refer to:

http://www.guident.com/ or contact the author directly at mailto:info@guident.com.


With ever-increasing scrutiny of Federal IT initiatives’ performance (e.g., Federal CIO, Federal IT Dashboard, TechStat Sessions, Financial Systems Advisory Board, GAO reports, cancelled projects, etc.), the need for sound Portfolio Management and Performance Management is quickly coming to the forefront. Unfortunately, these disciplines often suffer from ill-defined processes, disjointed tools and inconsistent education. At the same time, agencies are banking on the success of their IT initiatives with large investments of time and resources. A cohesive solution of processes, tools and education is needed to bring the focus back to mission objectives and performance relative to those objectives.

What else do you believe are symptoms, contributors to this problem, and possible solutions?

Also, see the below Guident and Oracle webinar on our Project Performance Portfolio Management (PPFM) Solution.

http://www.guident.com/index.php?page=download&target=Managing_Projects_and_Budget_with_OBIEE_and_Primavera.pdf

For more information on this topic, refer to:

http://www.guident.com/ or contact the author directly at mailto:info@guident.com.

Tuesday, August 3, 2010

Oracle Analytic Functions in ODI

Oracle Analytic functions are a great way to write efficient, complex SQL statements. Instead of having to write multiple joins and subqueries you can write a similar statement in just one line. This is a great time saver especially when using a tool such as Oracle Data Integrator (ODI), which makes it difficult to do subqueries. Unfortunately, ODI’s knowledge modules do not support all analytic function out of the box. The problem is when ODI sees the SUM keyword it automatically triggers the use of the GROUP BY and HAVING clause regardless if is a regular SUM or analytical query SUM. If you ever tried using such a function in ODI you probably received “ORA-00979: not a GROUP BY expression”.

With just a few lines of code you can easily implement a solution to fix this issue:

1) Navigate to the KM you wish to customize to use analytic functions (can be either LKM or IKM).

2) Create a new KM Option




3) Open the knowledge module and navigate to the Details tab, “Load Data” step (or “Insert flow into I$ table” step for IKM).

4) In the Definition tab look for the lines of code that contains (either Command on Target or Source):

<%=snpRef.getGrpBy()%>
<%=snpRef.getHaving()%>

And replace it with the following

<% if (odiRef.getOption("USE_ANALYTIC_FUNCTION").equals("0")){
out.print(odiRef.getGrpBy());
out.print(odiRef.getHaving());
} else
{
out.print("--Group by functions are suppresses by KM");
}
%>


5) Click the option tab and be sure to check your option name (USE_ANALYTIC_FUNCTION). Click Okay to complete.
6) When creating your interface and choosing your KM, in the flow tab you now have the ability to select the user defined USE_ANALYTYIC_FUNCTION.

The USE_ANALYIC_FUNTION option works by suppressing the GROUP BY and HAVING clause of the query when the value of Yes is selected. Because the GROUP BY will not be used you can use any analytic function you like.

Thursday, July 15, 2010

Analytics in the Social Media Space

Will Analytics be an integral part of the social media space? According to the IT budgets of Fortune 500 companies, the analysis of customer online social interactions is taking center stage. Forrester reports: “Despite recession, more than 50 percent of marketers increase spending on social media”1.

Organizations have begun to realize that understanding potential customer’s online behavior is critical to staying one step ahead of the competition. Some online vendors have utilized this information to create personalized web content to better target potential customer groups. Collecting and analyzing online behavior and translating this information into reliable and actionable knowledge to support decision making is quite a challenge.



There are many tools on the market to support analytics for social media. Feature rich tools like Lyzasoft support searches; bookmarks; mixing, matching, and combining; tagging; sharing; commenting; and rating - with BI analytics. Open source tools like Google analytics which are not typically used for Social Media sites can be customized with an extension of Social Media Metrics for Web 2.0 social sites like Digg, StumbleUpon, del.icio.us and more. Industry leaders like IBM offer text analytics; SAS offers Social Media analytics, while niche vendors like Lexalytics offer Sentiment Analytics. These software products help organizations in converting online behavior and opinions into virtual currency by analyzing the deep rooted semantics and the context of every single word.

With so many products available in this space how does an Organization choose the right vendor to support their endeavors? Forrester lists of a few top attributes to look for in a Social Media BI vendor 2:
  • Reliable data collection
  • Easy-to-use Interface
  • Product pricing
  • Match between product capabilities and requirements
  • Quality of support
  • Data reporting assurance
  • Integration with other BI applications
Forrester also suggests these important data capabilities in the solution:
  • Custom metrics
  • Easy implementation / deployment
  • Benchmarking
  • Data warehouse
  • Ability to export data to other applications
  • Collection of full (no sampling) data
  • Administrative access controls
  • Ability to import data for blended analysis
It is safe to say that this area is swiftly moving to the top of the hype cycle. The next Web Analytics maturity wave intertwined with Web 2.0 will touch upon every single aspect of our lives from political campaigns to everyday dining. Just imagine, you are vacationing in an exotic island and your cell phone alerts you when you are within 5 miles of a restaurant your friend mentioned during a casual Facebook chat.


References:

1 - Despite Recession, More Than 50pct of Marketers Increase Spending on Social Media, Forrester Consulting, http://www.readwriteweb.com/enterprise/2009/03/despite-recession-more-than-50-of-marketers-increase-spending-on-social-media.php

2 - Appraising Investments in Web Analytics - A Commissioned Study Conducted by Forrester Consulting on Behalf of Google, Forrester Consulting, September 2009

Tuesday, June 22, 2010

Enterprise Search vs. a Centralized Electronic Information Repository

Enterprise Findability: Leveraging Synergies between the Common Electronic Repository and Enterprise Search

This paper describes synergies the organizations can achieve if Enterprise Content Management (ECM) and Enterprise Search technologies are considered and implemented together.

Many organizations are required to identify, retain, and share mission-critical information efficiently. Historically, individual departments in an organization took responsibility for assuring appropriate retention and access. However, the increasing complexity of regulation mean that this mission-critical information increasingly applies across entire organizations. Information in one department may be relevant to another department, as together they work to provide consolidated information to the external world.

A key challenge is to achieve the best use of information assets in its repositories. The goals are to eliminate duplicate content, maximize its reuse, and assure that information is protected and accessible. These goals summarize the concept of findability. In essence, findability is the art and science of locating information in or about electronic documents. People want to find answers, not search for them. AIIM, the industry Association for Imaging and Information Management, says in a 2008 report that “effective Findability retrieves content in context. Therein lies the crux of Findability. It cannot be attained simply by search, even a powerful search.” (AIIM MarketIQ, 2008). Improving findability requires a cooperative strategy, achieved by combining complementary technologies and systems. Findability is critical to effective use of information at many organizations.



No organization today can afford to duplicate assets or investments, whether in enterprise software or knowledge assets developed by its workers. Savvy organizations instead are adopting Information Lifecycle Management (ILM) practices. These ILM practices are “based on aligning the business value of information to the most appropriate and cost effective infrastructure.” (SNIA, 2004). ILM practices recognize that multiple technologies are critical to attaining desired organizational outcomes.

Findability Efforts at a Large Government Agency: An Overview

In 2006, a large federal government agency recognized the critical role of its information and resources by creating a Board to better coordinate IT investment. The board also initiated a set of enterprise-wide initiatives aimed at modernizing its IT systems. Among these initiatives is creation of a common electronic document repository, whose objective is to integrate individual repositories and contain the vast majority of documents created or received by the agency. This would:

1. Improve access to the content and its associated metadata, and


2. Facilitate reviewers’ and others’ ability to do their jobs effectively and efficiently.

More recently, the agency launched an Enterprise Search initiative to provide agency wide searches of its information repositories, one of which would be the Common electronic repository.

These two unfolding projects position the agency to plan and implement them in concert to meet Information Lifecycle Management best practices: increase findability, with maximum effectiveness and minimum cost.

Here is how both support findability.

Findability: Concepts and Technologies

Because of their interlocking components, a variety of technologies can enhance findability. Organizations seeking to enhance findability should select whatever combination of technologies that best meet their needs. The agency has already determined that two critical, enterprise technologies are needed to attain findability: Common electronic repository and Enterprise Search. Together these can overcome an agency's findability challenges:

1. Multiple silos of information that segregate potentially useful content into individual repositories,


2. Multiple sets of metadata and terminology, making it challenging to identify all potentially relevant content,


3. Rapid growth in content that burdens storage and hinders implementing electronic record policies.

Attributes, properties, and metadata all refer to the same thing: information about, not inside, the content. Both a Centralized Electronic repository and Enterprise Search will use metadata. Organizations will enable employees to find and use what they need and when they need it by identifying the synergies of these two systems.


How the Centralized Electronic Repository Enhances Findability


A Common Electronic Repository increases findability by:


1. Providing a hierarchical folder structure that shows content groupings and relationships


2. Associating metadata with content, providing document context and enhancing internal search of the content


3. Supporting the setting of security levels and other access controls

As an ECM system, the Common Electronic repository provides a hierarchical folder structure (or taxonomy) for content storage. By merely looking at this taxonomy, users can understand important content groupings and their relationships.

Another key feature of ECM systems for a Common Electronic Repository is their capability to associate metadata with content. Metadata adds additional context to the content, helping users better understand how, when and why the content was created. For example, each piece of content in a Common Electronic Repository will have several common metadata attributes such as “Document Authors,” indicating whom to contact for more information.

Metadata can be designed to use controlled, predefined lists of keywords. A specific attribute such "drug additive" could contain only one of a small set of values. By constraining the list of values with one like “Drug Evaluation and Research,” Enterprise Search will return more relevant results. Enterprise Search would not need lists of synonymous names.

A Common Electronic Repository also supports the setting of security levels and other access controls. These also can provide context for the content. Content might be considered available for limited release, such as within a specific research group, or have constrained usage based on specific time periods. Access controls also reduce visual clutter, since users see only what they have rights to see, and they can change content only as policy permits.

In summary, a Common Electronic Repository will enhance findability. The system’s folder structure and metadata are shared. Folders provide additional relevant context. The system allows content to cross organizational boundaries, enhancing findability. The organization also establishes a shared understanding of the domain and its content.


How Enterprise Search Enhances Findability


Enterprise Search will also play an important role in findability. That is why enterprise search systems are among the first technologies organizations consider as they wrestle with findability challenges. The most basic enterprise search function is to generate indexes for content items. For example, search systems generate indexes of key words to search content. Search systems also provide relevance ranking. However, credible relevance ranking requires advanced Enterprise Search features. Incorporating these advanced features adds additional value to findability:

• Create and manage organization specific thesauri. This helps a user searching for a specific word missing from documents of interest. Thesauri help the search systems return all documents of interest by finding those containing words meaning the same, but spelled differently, from what the user searched for.


• Support Term weighting. This identifies those terms that center users might find more important than others, when all have similar meanings. Term weighting, combined with Thesaurus support, enhances findability.


• Provide natural language processing. This allows Search to analyze content beyond merely identifying key words. For example, a document that contains the word “bush” could be analyzed to determine whether it was about a United States president or a type of vegetation.

Since a Common Electronic Repository will contain both internal and external content from large numbers of sources, the Enterprise Search system’s natural language support will help searchers sift through these different kinds of information.

Because Search systems work with indexes created from content throughout the enterprise, they can find relevant content no matter where it is stored. No navigation through a pre-set folder structure is needed. Such navigation requires choices which may not be intuitive when a user is not familiar with the domain.

In summary, Enterprise Search will play an important role in meeting an organization’s findability needs. Because an organization cannot pre-determine all relevant organizational structures, or other context for content, Enterprise Search will provide the opportunity to avoid dealing with specific folder structures, such as those in a Common Electronic Repository, and still find useful content.


A Common Electronic Repository Provides Value to Enterprise Search

One of the limitations of any enterprise search system is its brute-force nature. Search systems operate primarily on individual words, which by themselves are isolated from context. The result is that users often have to wade through large lists of search results to find what they really are looking for. An Electronic Content Management system is a good source of context to add value to a Enterprise search engine and can also reduce the length of those lists. A Common Electronic Repository can help organize search results by providing groups (“facets”) of Enterprise Search results. A good source of those facets is the Electronic Repository folder taxonomy.

Enterprise search systems can also use folder names to refine search results by allowing a search restricted to a particular branch in a folder hierarchy. Many search engines also allow advanced use of dictionaries and thesauri. Since every organization is unique, these dictionaries are generally not available “out-of-the-box” but instead must be built to reflect the organization’s vocabularies. However, a Common Electronic Repository folder structure could serve as an initial set of preferred terminology for Enterprise Search dictionaries, rather than requiring an organization to create that starter dictionary from scratch.

Enterprise Search can index metadata in a Common Electronic Repository to focus the types of searches available, again providing context to the content. The investment made adding rich metadata values to a Common Electronic Repository becomes immediately available to Enterprise Search. For example, a user might want to see content related to the a specific drug Lisinopril, but only when that document was written as part of a site inspection.

By making use of Common Electronic Repository metadata, an Enterprise Search query could say in effect “show me only those documents containing the word ‘Lisinopril’ which also have been tagged as a ‘site inspection’.”


Search provides value to ECM

Just as the Common EDR will add value to Enterprise Search, Enterprise Search can greatly enhance the value of an Common Electronic Repository. Like all ECM systems, a common Electronic Repository provides structures to store and process content according to an organization’s business rules. However, a Common Electronic Repository can provide only rudimentary searching.

• Enterprise Search will provide richer searching than basic search that is part of the Common Electronic Repository. By reusing metadata already describing content in the Common Electronic Repository, Enterprise Search can provide more relevant search results.

• By supporting dictionaries (such as lists of synonyms), Enterprise Search can provide additional ways to find content when the Common Electronic Repository folder names don’t match a user’s search query.

Enterprise Search will also provide a findability alternative to navigating a Common Electronic Repository folders. Rich Enterprise Search features can even allow a searcher to influence the search process to create his or her own context, as opposed to the one represented by the single Common EDR folder structure.

Lastly, Enterprise Search will provide another important feature: search logs. Search logs provide a record of what search queries users ran. Search administrators can analyze these logs to show how content is used, and logs can even suggest possible changes to the Common Electronic Repository folder structure, metadata elements and values.
Leveraging the Synergies

To repeat, neither Enterprise Search nor a Common Electronic Repository alone can provide a complete findability solution. Implemented together, they not only support richer findability, they do so more efficiently than either by itself.

A Common Electronic Repository, with its pre-set folder structure, and Enterprise Search with its ability to cross storage locations, provide two different approaches to finding content. Both approaches will be valuable depending on each user’s particular needs. One person familiar with the Common Electronic Repository folders may find navigating its folders faster and more effective than using Enterprise Search, which might seem more “scattershot.” Another person, unfamiliar with the Common Electronic Repository, could prefer Enterprise Search for rapidly finding relevant content. For that user, navigating through unfamiliar folders and reviewing content within each folder might be cumbersome.

A key operational challenge for deploying any enterprise search system is building connections to various ECM systems and translating their metadata elements to those used in the Search system. Integrating most content into one repository, the Common Electronic Repository, reduces the number of bridges and maps for Enterprise Search. This in turn reduces initial implementation cost as well as ongoing maintenance costs. Failure to consolidate content into the Common Electronic Repository would increase costs as the number and size of island repositories increases. Enterprise Search system administrators would have to spend ever-increasing resources to maintain those ECM system bridges and maps. Over time, the result would be a babble of inconsistencies, reduced relevancy, and decreased confidence in the Enterprise Search system’s results.

Deploying both a Common Electronic Repository and an Enterprise Search system also reduces the costs of governance for each. A single set of centralized governance processes applied to Common Electronic Repository content and folder structures minimizes costs, since only one folder structure needs to be reviewed, updated, and managed. Enterprise Search system governance decreases since metadata and the meaning of taxonomy nodes in the Common Electronic Repository are stable, predictable, and understood by Enterprise Search users.


Conclusions

With a Common Electronic Repository and Enterprise Search working together, they achieve findability levels unavailable to each alone. Each system brings unique advantages to enhancing findability. Implementing both Enterprise Search and a Common Electronic Repository is critical to reducing costs, getting best use from technology investments, and achieving the level of findability that an organization's mission requires.

References

AIIM MarketIQ (Q2 2008) “Findability: The Art and Science of Making Content Easy to Find. http://www.aiim.org/Research/MarketIQ/Findability-7-16-08.aspx

SNIA: Storage Networking Industry Association. (2004). Information Lifecycle Management: A Vision for the Future. http://www.snia.org/forums/dmf/programs/ilmi/ilm_docs/SRC-Profile_ILM_Vision_3-29-04.pdf (accessed March 10, 2010).

For more information on these topics, go to http://www.guident.com/ or contact the author directly at mailto:rweiner@guident.com.

Friday, June 11, 2010

Redundancy in the BI Data Model

Recently, an experienced database professional who had just started his first business intelligence (BI) project asked me two questions:
  1. Is data redundancy allowed in a BI data model?
  2. How much normalization is industry standard in BI if at all?
I had no hesitation answering the first question. Yes, absolutely, data redundancy is not only allowed but is recommended in many situations in BI data models. Redundancy is the key to simple BI data models and fast query response. The rules of normalization, which minimize data redundancy, were designed with transaction processing systems in mind and were also designed at a time when computer resources were scarce and expensive and data storage devices had limited capacity and slow I/O speeds.




One of the primary goals of normalizing to eliminate redundancy was to ensure data consistency. You didn't want to capture the same data at multiple entry points, since this meant extra effort of people typing in what should be the same data but often wasn't because of typos and variations in usage of abbreviations, nicknames, etc. Second, if the data changed and you had redundancy in the data model you had to go back to update multiple records in many tables - not necessarily easy to program and manage. Third normal form data models eliminate these problems and store data efficiently, but not without a price. The proliferation of tables with third normal form means queries have to join many tables. This is no big deal for transaction processing activity because individual transactions only insert or update a handful of rows in each table and typically use procedural code to do this.

With BI data models we don't care about capturing data. That is the job of the source application. So long as the source did a good job of normalizing and capturing the data properly, the BI model does not need to repeat the normalization process to ensure good source data. Second we are not supposed to update records in BI models - data warehouses are supposed to be static. We preserve point-in-time history so we typically don't have to go back and make updates to multiple occurrences of redundant data.

BI queries are very different from source transactions. Having to join many tables in a non-procedural SQL query has a huge cost when you are talking about queries that touch hundreds of thousands or even millions of records which is common for BI. Therefore redundancy that eliminates table joins for runtime queries is a recommended practice in BI. Fewer tables in the model also make it easier for end users to understand the model and easier to write ad hoc queries. Dimensional data modeling featuring the use of star schemas which may include redundancy is the technique most frequently used to reduce the number of tables in the model.

Other examples of acceptable redundancy in BI databases include having the same data stored in staging tables as well as production tables. And having variations of the same data stored in summary tables with different levels of aggregation so standard reports that frequently use the aggregated data run faster.

The answer to the second question is not so easy. There are two diametrically opposed schools of thought on data modeling for data warehousing. The one school, associated with Bill Inmon who is often called the father of data warehousing, believes that data warehouses should first acquire and store all data in non-redundant third normal form. They believe this is still required for good data management practices and do not believe that dimensional data models are robust enough for large data warehouses. However since BI tools like Business Objects and MicroStrategy run best with dimensional models, once the data is safely stored in a third normal form warehouse the model is extended with redundant downstream dimensional data marts that re-extract and reload data out of the data warehouse model into the data mart models.

The other school of thought, associated with Ralph Kimball who is one of the pioneers of dimensional data modeling, believes that dimensional models are perfectly capable of managing data of any size and complexity and are suitable for data warehouses or data marts no matter their size. Followers of this school avoid the extra effort of designing and maintaining two models (one third normal and one downstream dimensional) and two ETL jobs to load the two models. Consequently they also typically deliver new BI projects with shorter development cycles.