Distributed data warehouse query and resource management system

Details Distributed data warehouse query and resource management system Distributed data warehouse query and resource management system

1998-07-28

2001-01-23

Ho, Ruay Lian (Department: 2771)

Data processing: database and file management or data structures

Database design

Data structure types

C713S155000, C370S255000

Reexamination Certificate

active

06178418

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to data warehousing and decision support systems. More particularly, the invention relates to a system and method of operation to support data query and retrieval in a data warehousing environment including a plurality of data providing computers accessible via a suitable communication network, wherein the information appears as though it may be emanating from a single (logical) data source.
2. Background and Objects of the Invention
The advent of mainframe computing provided the ability to manage large amounts of data in a manner that had not been previously possible. The advantages of managing such volumes of data by computer was obvious, especially to government and large corporate entities. As can be seen in
FIG. 1A
, the architecture of such prior art systems, such as system
10
a
, initially provided a user accessing the system with a terminal
12
that was coupled to the mainframe
20
by way of a cable
12
a
. The cable
12
a
establishes what may be termed a ‘communication channel’. These systems generally provided very simple ASCII-type user interfaces, wherein data was presented in tables (or lists) on monochrome screens. The early terminal interfaces enabled a user to enter, view, and modify the stored data, which could later be printed for hardcopy records. Importantly, even with the significant expense in deploying and maintaining these systems, they provided a cost-effective means to store, maintain, and manipulate very large amounts of data in a manner never before possible.
Soon thereafter, the advent of the mini-computer resulted in the introduction of reduced cost low-end database systems. Now it was possible for relatively small and medium sized companies to enjoyed the benefits of computer based data handling and management. Again, the interface screens employed by users of such systems were rather mundane by today's high resolution graphical user interface (GUI) standards. However, the availability of mini-computers also made it possible to have a plurality of such systems employed within an organization. For example, different departments or geographical locations within a single organization could employ one or more such systems.
Eventually, the advent of server based systems resulted from a merging of low-cost microprocessor based technology, and complex network and multi-user operating systems. These system architectures were, of course, driven by the introduction and proliferation of the personal computer or PC. As the computing power of these personal computer systems rapidly increased, and as prices continued to drop, the ubiquitous PC lead to the wide scale deployment of LAN based client/server computing environments. These systems provided advantages with regard to scalability and redundancy not previously available (especially when considering cost). Another significant advantage of these systems was their ability to run a variety of business application programs, which evolved and steadily improved in power and ease-of-use. The cost of these application programs was also quite low when compared to the cost of mainframe and mini-computer software. The PC based applications where generally simple and intuitive to use, and provided a ‘standard interface’ (GUI) having excellent graphical capabilities. Once a user understood the basics of the interface, new applications, or updated versions of older applications (having additional feature sets), were easy to learn and use.
However, the significant investment in mainframe and mini-computer based database systems, termed by some as ‘legacy’ database systems, combined with their stability and relative reliability, lead to a desire by some to mix legacy systems with newer server based data storage systems, which are often referred to as data warehousing systems. As depicted in
FIG. 1B
, when desiring to maintain older or original data providing systems, the result was the birth of hybrid systems. Whether hybrid (consisting of a plurality of mixed physical servers) or homogeneous (consisting of a plurality of the same or equivalent physical servers) these systems may require the analysis of information stored therein, and may accordingly be termed ‘decision support systems’ or DSS environments. An illustrative DSS 10
b
, as shown in
FIG. 1B
, includes clients such as client
14
a
,
14
b
, etc., with the ability to access data stored in one or more data marts
20
a
, data warehouses
20
b
, and/or legacy data-base systems
20
c
. It is important to note that the DSS environment may be formed by a mixed or hybrid arrangement (as illustrated), or a homogenous arrangement, say consisting only of data warehouses
20
b
. In each instance, however, a number of problems resulted from the desire to establish and maintain such DSS architectures. For example, certain database systems may employ accessing formats (or query languages) that differed from later PC and client/server based data warehouse query formats. This results in a need for query translation and reformatting. Also, as data within an organization could be located on any one of a number of data providing physical servers, there was a need to determine where the specific data being requested was actually located. This need to locate data, which has been exacerbated by the introduction of Web and enterprise resource planning (ERP) applications (which are typically distributed throughout an enterprise or organization), may be termed ‘query routing’. That is, query requests are steered or routed to a particular database, data warehouse, or data mart, wherein the data required is located. Query routing generally works best when based on cost and business rules.
Yet, other problems existed in these distributed DSS architectures, such as the need to manage redundancy, replication, and load-balancing, as well as provide security to confidential or sensitive information. In short, the DSS landscape was complex and full of pitfalls! The recent explosion in the use of the Internet as a data distributing medium certainly further complicated the situation.
One solution which was initially embraced to solve the above listed problems and concerns is illustrated in FIG.
2
. The arrangement therein employed a middle-tier server
22
, which was interposed between the client PCs, such as
16
aa
and
16
bb,
and the data sources, such as data mart
20
a,
data warehouse
20
b
, and or legacy data bases
20
c
. In theory, all the above listed problems, including translation, query routing, security, etc., would simply be handled by the middle-tier server
22
employing suitable ‘middle-ware’ software. A request for data would be passed to the middle-tier server
22
, translated if necessary, and passed to the appropriate system to satisfy the query. The queried data would then be passed back to the requesting application program (executing on a respective client PC
16
) via the middle-tier server. As one skilled in the art will recognize, the architecture of
FIG. 2
clearly has several major drawbacks. First, the middle-tier server
22
is clearly a bottleneck for the flow of information. Not only do the queries flow through the middle-tier server
22
, all requested (queried) data also passed through it. If very large volumes of data are requested by a client PC
16
, the utilization demands placed on such a (middle-tier) server increases quickly. If a large number of users are to be serviced by the arrangement of
FIG. 2
, the middle-ware server may need to be a very high throughput, high-cost system. Accordingly, the middle-tier server
22
may require more computing power than the actual data mart
20
a
or data warehouse
20
b
systems! In addition, if the middle-tier server
22
were to fail and go down, the entire system would generally be rendered inoperable with regard to delivering queried data to the client PCs
16
. Skilled individuals will also appreciate the difficulty in scaling the arrangement of
FIG. 2
, wherein a large number of client PCs must be

Affiliated with

Also associated with

Rating

Distributed data warehouse query and resource management system does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Distributed data warehouse query and resource management system, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Distributed data warehouse query and resource management system will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2531751