World Library  
Flag as Inappropriate
Email this Article




Type Private
Industry Data Warehousing and Master Data Management Software
Founded 2003
Headquarters Burlington, MA, USA and London, UK
Key people Bill Hewitt - President and Chief Executive Officer
Joan Nevins - Chief Financial Officer
Nigel Turner - Vice President, Product Development
Products Kalido Dynamic Information Warehouse
Kalido Master Data Management
Kalido Business Information Modeler
Kalido Universal Information Director

Kalido Company is a software company headquartered in Burlington, Massachusetts with offices in the US, London and India.


  • History 1
  • Kalido DIW 2
  • Kalido MDM 3
  • Generic Modeling and the Data Warehouse 4
  • References 5
  • External links 6


The ideas behind Kalido started in 1985, when the Royal Dutch/Shell Group began twelve years of advanced data-modeling research, involving highly generic models and time variance.

Between 1997 and 2000, a Shell team led by Andy Hayler spotted the opportunity to develop Kalido software on the basis of this research to solve the challenge of obtaining performance information across multiple Shell organizations throughout business change. The software was deployed within Shell in 100 countries worldwide, powering dozens of projects and generating tens of millions of dollars of annual cost savings.

Kalido DIW

The architecture of Kalido DIW (Dynamic Information Warehouse) is based on "generic data modeling" principles. Generic data modeling is an advanced database design technique that offers advantages over conventional designs. Shell developed the technique and offered the data design approach to the ISO standards community. The approach is now used extensively within the ISO STEP world.

The approach involves the structure of the data being held as data, rather than being defined by a specific physical database design. Generic data modeling is a radical departure from traditional data modeling principles.

Kalido MDM

Kalido MDM (Master Data Management) is a software application for harmonizing, storing and managing master data over time. It increases the consistency and accuracy of corporate performance reporting by enabling business people to collaboratively manage and control master data in a workflow-driven environment. It produces a master data warehouse from which “golden-copy” master data can be distributed to enterprise applications and business people throughout the organization.

Kalido MDM features:

  • Manages any type of master data — from products and customers to brands, markets, territories and more.
  • Facilitates data governance in a collaborative, workflow-driven environment
  • Flexible master data modeling—featuring cataloging, segmenting, merging and mapping facilities
  • Loads non-conforming master data — all master data is loaded even if it doesn’t conform to the master data model. Workflows can be used to ensure that the data — or the model — is revised accordingly
  • Maintains master data history

Generic Modeling and the Data Warehouse

The generic structure, compared to the traditional data warehouse design based on third normal form schemas and snowflake or star schemas, has both advantages and disadvantages.

  • The generic structure can store time variant business context data (i.e., changes to the business context data that happen over time such as a reorganization where departments are grouped differently), without requiring any database design changes. By contrast, traditional data models represent a snapshot of the requirements that were valid at the time the model was created. This makes it difficult to store historic data, which may require as much analysis as the current data. Often historic information is discarded due to the extra design required.
  • The generic structure presents a highly standardized approach to loading and retrieval, enabling the automatic creation of loading and retrieval routines by Kalido DIW.
  • The generic structure enables the loading of new classes of data through the simple addition of a few records of metadata. Conventionally, changes in requirements cause changes to the design, requiring a database administrator to alter the table structure of the warehouse and to reorganize the data in the database. The costs and time involved can be considerable.
  • The generic structure allows the capture of complex business rules that are difficult to capture using a conventional relational structure.
  • The use of metadata allows the structure of business context and transaction data to be easily understood by business users.

A pure implementation of generic modeling principles will bring with it some disadvantages such as:

  • Conventional star schema can give better performance than physical implementations of the generic structure. Kalido DIW addresses these issues by combining elements of the generic structure with those of a star schema.
  • The generic structure supports the business structure by holding multiple rows, linked by pointers, instead of the conventional columns in a table. This makes the data difficult to read and the SQL difficult to write, requiring a codegenerating front-end to read and load data. Kalido DIW has such a code-generating front-end.

Despite the generic structure being different from conventional designs, it is far easier to query once understood as it combines the business metadata dictionary with the business context data. Finding out where something is stored is far simpler than navigating through hundreds of obscure tables.


Given the above advantages and disadvantages, a mix of the generic design for business context data and the star schema for transaction data and retrieval would make an ideal situation. This has been the basis for the physical implementation of Kalido DIW. The results of the Kalido implementation have proved that this innovative design can, and does, work. Kalido has UK patents on this design. The generic design of Kalido DIW is highly flexible but could have made processing transactions against the hierarchies of business context data it rather inefficient. To improve performance, the complex hierarchies are automatically flattened out by Kalido DIW to create "mapping" tables.

These mapping tables are complex and contain the full structure of the business context data hierarchies, including the date and time stamping of changes. They are regenerated when either the master data or its structure change so Kalido DIW fully manages both the generic data storage and its replication in mapping tables. This replication is done incrementally and can be delayed so that bulk changes can be made over a period with only a single generation of the mapping tables concerned. This ensures that optimum performance is delivered, in accessing both the generic data for exploration queries and the mapping tables for OLAP queries.

The creation of mapping tables makes a Kalido warehouse appear like any other star schema. Conventional star schemas include the business context data, but they are keyed reference tables with all the attributes, classifications, etc. as columns. This causes duplication of data and difficulty in maintenance, but is fast to process. This is why the Kalido warehouse can equal the query performance of a conventional design. The creation of the mapping tables can be a scheduled task or the user can initiate it. Batch tasks can also be used for business context data loading, transaction loading, summary generation, mapping table generation, data mart building, or export of transaction or business context data.

Data marts are generated by extracting information from the warehouse in a form that can be analyzed using tools such as Excel or BusinessObjects to slice and dice, or drill-down through it. The data mart can be separated from the database, and small ones can take the form of Excel pivot tables, which can be taken away on a portable computer for offline analysis.

In summary, one of the requirements of a data warehouse is that it should be capable of storing and managing almost any data from any source.

In a Kalido warehouse:

  • Information is held in a neutral format, i.e. not limited to a particular type of business data.
  • There are neutral formats for transaction data and business context data.

Metadata is used for:

  • validation and loading of data into the warehouse
  • structuring data in the warehouse
  • defining data marts

The neutral formats allow you to select and view information as you want in data marts.


External links

  • Kalido Corporate Website
This article was sourced from Creative Commons Attribution-ShareAlike License; additional terms may apply. World Heritage Encyclopedia content is assembled from numerous content providers, Open Access Publishing, and in compliance with The Fair Access to Science and Technology Research Act (FASTR), Wikimedia Foundation, Inc., Public Library of Science, The Encyclopedia of Life, Open Book Publishers (OBP), PubMed, U.S. National Library of Medicine, National Center for Biotechnology Information, U.S. National Library of Medicine, National Institutes of Health (NIH), U.S. Department of Health & Human Services, and, which sources content from all federal, state, local, tribal, and territorial government publication portals (.gov, .mil, .edu). Funding for and content contributors is made possible from the U.S. Congress, E-Government Act of 2002.
Crowd sourced content that is contributed to World Heritage Encyclopedia is peer reviewed and edited by our editorial staff to ensure quality scholarly research articles.
By using this site, you agree to the Terms of Use and Privacy Policy. World Heritage Encyclopedia™ is a registered trademark of the World Public Library Association, a non-profit organization.

Copyright © World Library Foundation. All rights reserved. eBooks from Project Gutenberg are sponsored by the World Library Foundation,
a 501c(4) Member's Support Non-Profit Organization, and is NOT affiliated with any governmental agency or department.