DROWNING IN DISPARATE DATA

Let us look at the reasons why you should look at the alternate offering by TAGGIT for the merge of multiple data sources.

What is a datamart?

Essentially it is a data warehouse (DW), smaller by nature and aimed at departmental level. Normally it is a repository for a collection of specific data assets required for the production of reports and other information for that specific section or segment of the enterprise or business.

It's principle objective is to converge disparate islands of data from across dissimilar businesses application databases. This data would be the product of specific business processes that once combined illuminates the entire business performance and historical record – a global insight into the business’s activity and performance.

What are the limitations?

Although this is useful, there are many limitations that reduce the overall effectiveness of a datamart project. This includes the project time, transformation of the data and three other highly important elements being;

• Investment versus Return
• Cost of Maintenance and
• Resource Consumption

Data Warehousing has a chequered history of massive over spend, long implementation times, huge resource requirements, and at the end, limited and inflexible use either through sheer complexity or significant resource and hardware limitations.

	Normal data process for a DataMart .

There are many inherent and inevitable obstacles to embrace when designing, building and maintaining a Data Warehouse. From the back end architecture, to the front-end interfaces and Business Intelligence applications.

Conversely, business improvement, “joined up systems data”, more responsive and proactive business agility are frequent positive reasons for such an investment. This is why enterprises that can afford the time persevere with the DW route.

So where does TAGGIT fit in?

Accelerate project speed

We admit there is no shortcut to gathering and analysing business requirements. These will be specific to each organisation and what the business wants from a Data Warehouse project.

The implementation of our solution similarly requires this step. However, the ability to rapidly “go shopping” for complementary data sources and to allow joins without change to existing data structures, permits “Try before you buy” Warehouse planning and inexpensive data exploration.

	Compare TAGGIT project times to the normal process for a DataMart implementation.

While the data is "sampled" we can pinpoint data cleansing issues, data integrity and the relevance can easily be explored and then tested almost immediately.

From the moment our automated build process is complete, immediate benefit can be realised from running existing or new reports on all the data, without any impact on core systems. TAGGIT's application is capable of building a “unified platform” offering a high performance “light” operational view of Enterprise data, accessible by all front-end ODBC compliant business intelligence products.

Significantly reduce risk of project

“Forearmed is forewarned”. If you can quickly identify logical restrictions and holes in the data, well in advance, valuable time can be saved and recycle steps can be avoided when the DW project rolls forward. Numerous builds an be easily tested, discarded or modified to provide a fertile testing environment working with real and relevant data in its entirety.

All DW projects can benefit from this valuable capability. Significant planning and theoretical exploration can be conducted on complete data sets without impact on the source systems.

Reduce hardware dependency

Unlike Data Warehouse architecture requirements, the TAGGIT package relies on advanced Maths and sophisticated algorithms to achieve its performance and scalability. Massively parallel processing power essential for the large data warehouse when implemented is not required to underpin our performance.

All you need is a single processor P4 server with Windows 2000 Professional® and a large disk.

Again, all DW projects can benefit hugely by this technology to provide huge scalability of access, without massive increase on hardware dependency, and benefits from insulation from excessive user query loads.

Data cleansing and transformation

The integration and examination of databases will reveal legacy problems within each source, not least of which will be the purity of the data. Every Data Warehousing project undergoes significant data transformation to resolve and consolidate these issues. This is referred to as ETL (Extract, Transform and Load).

	The single repository (Query Data Set) showing the various DBs imported, unchanged.

The TAGGIT application extracts data from systems with ease, and loads it through its repository builder. Typically a Data Warehouse also requires full transformation of the data to be completed in its entirety before it is functional. TAGGIT does not depend on this process, although it enjoys great benefit from fully transformed data. Put more simply, TAGGIT can join databases and tables where a Data Warehouse cannot, by exploiting its unique vector mapping and absolute index.

By implication, TAGGIT can shortcut this costly process and transform some of the data during its build process. Most significantly, from a data audit perspective, we deliberately preserve the integrity of the original sources, and still allows logical joins to be created across systems. This is a feature that is impossible for traditional Data Warehouses and considered to be a significant weakness.

Scale to meet demand without resource implications

As the numbers of dependant users of a deployed DW grow, significant infrastructure enhancements are needed to sustain the increased load. TAGGIT accommodates even the largest web traffic requirements without significant dependency on hardware and without any impact to source data systems.

The TAGGIT package can be implemented after the warehouse has been completed, to sit in-front of the warehouse holding a copy of accelerated data. This could be opened to the user community to exploit it without impacting the Warehouse.

Analytics, reporting and ad-hoc queries can be satisfied regardless of the front-end access method (Portal, application, Business Intelligence etc.).

Historical Data Warehouses and Data Marts benefit greatly from our ability to shield query load and deliver answers to queries exceedingly fast, without tuning.

Lift query constraints

Typically, a live Data Warehouse will be tuned to process predefined queries and reports. Those user questions that fall outside its constraints are either scheduled to run when there is spare capacity, or worse still, not at all.

Our repository is 100% indexed and optimised in advance for any query demand. This allows you to quickly answer complex queries and reports. Whatever their nature and demand, queries will be resolved much faster, and overall Data Warehouse performance is improved as query pressure is lifted off it on to our system.

We serve all comers on demand without degradation of performance. Further more, the finest of detail can be reached by users, rather than summary information restricted for performance reasons, or worse - your process terminated so you have to start again.

In Summary…

We revolutionise the approach to solving a number of your common Data Warehousing hurdles.

The very significant contributions that this technology uniquely contributes to the Data Warehouse arena are:

• Speed of data integration and implementation.
• Speed of query and report processing.
• Highly intuitive and easy to use query generation.
• Scalability - from 5 Megabytes, up to 55 terrabytes of raw asci data in a single repository.
• Reduced cost of implementation and maitenance.
• It will allow you to address high value issues whilst a warehouse is being developed and to contribute to the effectiveness of the warehouse during and after implementation.

All of the above fundamentally contribute to the success and rapid ROI of a Data Warehouse project and its ultimate usability.