Source: http://www.google.com/patents/US7908125?dq=6,339,780
Timestamp: 2015-05-23 02:21:50
Document Index: 409907330

Matched Legal Cases: ['arts 239', 'arts 239', 'arts 239', 'arts 241', 'arts 241', 'Application No. 04005846']

Patent US7908125 - Architecture for automating analytical view of business applications - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsThe present invention provides an architecture for obtaining an analytical view of data. The invention includes a model service component for receiving an indication of a first object model and generating a dimensional model and a second object model from the first object model. The second object model...http://www.google.com/patents/US7908125?utm_source=gb-gplus-sharePatent US7908125 - Architecture for automating analytical view of business applicationsAdvanced Patent SearchPublication numberUS7908125 B2Publication typeGrantApplication numberUS 12/481,018Publication dateMar 15, 2011Filing dateJun 9, 2009Priority dateDec 30, 2003Fee statusPaidAlso published asUS7546226, US20090271158Publication number12481018, 481018, US 7908125 B2, US 7908125B2, US-B2-7908125, US7908125 B2, US7908125B2InventorsAdam Yeh, Jonathan Tang, Alvin LoOriginal AssigneeMicrosoft CorporationExport CitationBiBTeX, EndNote, RefManPatent Citations (38), Non-Patent Citations (35), Referenced by (2), Classifications (14), Legal Events (2) External Links: USPTO, USPTO Assignment, EspacenetArchitecture for automating analytical view of business applications
US 7908125 B2Abstract
The present invention provides an architecture for obtaining an analytical view of data. The invention includes a model service component for receiving an indication of a first object model and generating a dimensional model and a second object model from the first object model. The second object model is analytical in that it preserves relationships identified in the dimensional model, but allows the user to obtain information in terms of objects instead of specifying the data in terms of the dimensional model. The architecture also includes a navigational component that allows a user to navigate from the second object model to underlying data represented by the first object model.
1. A computer-readable storage medium having computer-readable program instructions embedded therein for directing operation of a computer system, wherein the computer-readable program instructions, when executed by a processor on the computer system, enable the computing system implement a data processing system, that comprises:
a model service system receiving, as an input, an object model description, indicative of a first object model that represents business data, and generating a dimensional model based on the input;
an entity generator generating a second object model based on the dimensional model, the second object model representing business data represented by the dimensional model;
a navigation service identifying a data navigation path from relationships between individual sets of data that comprise the business data, and outputting the data navigation path for navigation by a user from a first data set to a related second data set wherein the navigation service comprises:
a plurality of navigation providers each associated with a specific type of navigation;
a navigation service layer transmitting a navigation service request to one or more of the navigation providers that are registered with the navigation service layer; and
a metadata service providing the plurality of navigation providers with access to a metadata store, each navigation provider responding to a received data navigation request by interacting with the metadata service to identify at least one data navigation path and returning the at least one identified data navigation path to the navigation service layer for output to the user; and
a computer processor being a functional component of the data processing system and activated by the model service system, the entity generator and the navigation service to facilitate receiving the object model, generating the second object model and identifying the navigation path.
2. The computer-readable storage medium of claim 1 wherein the first object model represents transactional business data.
3. The computer-readable storage medium of claim 2 wherein the second object model represents aggregated business data.
4. The computer-readable storage medium of claim 3 wherein the navigation service identifies data navigation paths between the transactional and aggregated business data.
5. The computer-readable storage medium of claim 1 wherein the computer-readable program instructions enable the processor to implement the data processing system that further comprises:
a data accessing system providing an interface to access the business data through the second object model.
6. The computer-readable storage medium of claim 5 wherein the data accessing system is configured to receive an object oriented query expression expressed in terms of entities in the second object model, and wherein the data accessing system comprises:
a translation component configured to translate the object oriented query expression into a dimensional model query expression and execute it against the dimensional model.
7. The computer-readable storage medium of claim 1 wherein the object model description describes a relationship between entities in the first object model and wherein the model service system comprises:
a dimensional model construction system configured to receive, as inputs, the object model description and a focal point identifier identifying information in the object model as a focal point; and
a map system configured to receive, as an input, mapping information indicative of a mapping between entities in the first object model and a persistent data store.
8. The computer-readable storage medium of claim 1 wherein at least one of the plurality of navigation providers is associated with navigation from aggregated data to related transaction data.
9. The computer-readable storage medium of claim 1 wherein at least one of the plurality of navigation providers is associated with navigation from transaction data to related aggregated data.
10. The computer-readable storage medium of claim 1 wherein at least one of the plurality of navigation providers is associated with navigation between two data units that share a dimension.
11. The computer-readable storage medium of claim 1 wherein at least one of the plurality of navigation providers is associated with hierarchical navigation through collections of data that are hierarchically organized.
12. The computer-readable storage medium of claim 1 wherein at least one of the plurality of navigation providers is associated with navigation between two data collections that the user has identified as related.
13. A computer-readable storage medium having computer-readable program instructions embedded therein for directing operation of a processor associated with a computer system, wherein the computer-readable program instructions include instructions that, when executed by the processor, enable the processor to implement a data processing system for supporting analytical processing of transactional business data by an application, the computer-readable program instructions enabling the processor to implement the data processing system comprising:
a design system receiving a transactional object model description describing a transactional object model used in collecting the transactional business data and generating a dimensional model and an analytical programming object model from the transactional object model description, the analytical programming model representing data represented by the dimensional model and the transactional object model; and
a navigation service automatically identifying navigable paths between data sets in the business data in the system and output the paths for navigation by a user wherein the navigation service identifies navigation paths among data sets in the transactional object model, the dimensional model and the analytical programming object model.
14. The computer-readable storage medium of claim 13 wherein the navigation service identifies data navigation paths between the transactional and analytical business data.
15. The computer-readable storage medium of claim 13 wherein the navigation service further comprises:
a data accessing system providing an interface to access the business data through the analytical programming model.
16. The computer-readable storage medium of claim 15 wherein the data accessing system is configured to receive an object oriented query expression expressed in terms of entities in the analytical programming model, and wherein the data accessing system comprises:
17. The computer-readable storage medium of claim 13 wherein the transactional object model description describes a relationship between entities in the transactional object model and wherein the design system comprises:
a model service configured to receive, as inputs, the transactional object model description, a focal point identifier identifying information in the transactional object model as a focal point, and mapping information indicative of a mapping between entities in the transactional object model and a persistent data store.
18. The computer-readable storage medium of claim 17 wherein the navigation service comprises:
a navigation service layer configured to transmit a navigation service request to one or more of the navigation providers; and
a metadata service for providing the plurality of navigation providers with access to a metadata store, each navigation provider being configured to respond to a received data navigation request by interacting with the metadata service to identify at least one data navigation path.
19. The computer-readable storage medium of claim 18 wherein at least one of the plurality of navigation providers is associated with navigation from aggregated data to related transaction data.
20. The computer-readable storage medium of claim 18 wherein at least one of the plurality of navigation providers is associated with navigation from transaction data to related aggregated data.
21. The computer-readable storage medium of claim 18 wherein at least one of the plurality of navigation providers is associated with navigation between two data units that share a dimension.
22. The computer-readable storage medium of claim 18 wherein at least one of the plurality of navigation providers is associated with hierarchical navigation through collections of data that are hierarchically organized.
23. The computer-readable storage medium of claim 18 wherein at least one of the plurality of navigation providers is associated with navigation between two data collections that the user has identified as related. Description
The present application is a continuation of and claims priority of U.S. patent application Ser. No. 10/748,391, filed Dec. 30, 2003, now U.S. Pat. No. 7,546,226, issued Jun. 9, 2009, the content of which is hereby incorporated by reference in its entirety.
The present invention deals with accessing saved data. More specifically, the present invention deals with an overall architecture for logically extending to the conventional transaction based application framework an Analytical View (AV) of business data and its supporting subsystems. The AV is based on a design time service referred to as model service, a programming model referred to as Business Intelligence Entities (BIEs) and a runtime service to provide a metadata driven information navigation functionality. The AV feature set addresses enterprise application requirements for analysis and decision support, and complements the transactional feature set currently provided by a conventional application framework.
Prior business database accessing systems focused primarily on the transactional portion of the data accessing system. In other words, transactional data (in non-aggregated form) was generated and saved to the database for later retrieval, reporting and viewing. In such systems, it was very difficult, to retrieve the data in such a way that a user could obtain an analytical view of the data. There were a variety of reasons that this type of viewing of the data was very difficult, and those are addressed below.
FIG. 4D is a more detailed block diagram of the report parts architecture shown in FIG. 4.
FIG. 12 illustrates one exemplary embodiment of a UML class diagram for a business intelligence entity generator.
FIG. 13 illustrates one exemplary interface for invoking the functionality of the business intelligence entity generator.
FIGS. 19-23 are screen shots demonstrating presentations of data in the context of a business application.
FIG. 24 is a diagrammatic representation of a star-oriented data organization schema.
FIGS. 25 and 26 are screen shots demonstrating presentations of data in the context of a business application.
FIG. 27 is a schematic representation demonstrating the origin of navigation paths.
FIG. 28 is a flow illustration demonstrating generation of BI entity metadata for an intelligent navigation service.
FIG. 29 is a flow illustration demonstrating interaction between a navigation service and a user.
FIG. 30 is a block diagram illustrating a navigation service architecture.
FIG. 31 is a block diagram illustrating an embodiment of a navigation service architecture.
FIG. 32 is a combination block-flow diagram illustrating a process of collecting navigation links.
FIG. 33 is a combination block-flow diagram illustrating a process of traversing one particular navigation link.
FIG. 34 is a request/response class diagram that pertains to a process of acquiring links in response to a user request for intelligent data navigation, and to a process of traversing a link selected by the user.
Various aspects of the present invention deal with an architecture that allows a user to obtain an analytical view of data. However, prior to describing the present invention in greater detail, one illustrative environment in which the present invention can be used will be described.
Then, developers supporting the reporting structure for the user generated a dimensional model, such as model 210. The dimensional model typically includes a Fact table 211 which has measures noted therein. The Fact table 211 also has a plurality of dimensions illustrated as D1-D5 in FIG. 2. The dimensional model 210 was typically created based on the particular features in the data that the user desired to report on and analyze. Thus, some of the business logic implemented in object model 200 was recreated in dimensional model 210.
FIG. 4 is a block diagram of an analytical data accessing architecture in accordance with one embodiment of the present invention. Business data is stored in relational database 231. That data is illustratively stored in tables, but is represented by objects or entities 232. The entities 232, represent such things as customer, order and order line, as is discussed in greater detail below.
In one illustrative embodiment, the data can be queried in terms of entities 232 through object-relational data accessing system 233. A user-input query is provided in terms of the entities 232, or attributes of those entities, and the entity query is translated into a relational database statement executed against relational database 231. Data accessing system 233 then formats the data, as a desired result set, and provides it to the user.
However, because entities 232 are often arranged in terms of transactional processing, it can be difficult, even with the flexibility provided by data accessing system 233, to obtain an analytical view of the business data stored in relational database 231. Therefore, in accordance with one embodiment of the invention, model service/BI generator system 234 is provided. System 234 illustratively includes model service component 250 and entity generator component 260.
As discussed in greater detail later in the specification, system 234 automatically generates a dimensional model, such as UDM cube 258, and stores it in data store 259 (which can be implemented in the same store as database 231). System 234 also illustratively automatically generates business intelligence entities (BI entities) 262 from UDM cube 258 and the information represented by entities 232. In addition, BI entity data accessing system 236 allows a user to query the data represented by BI entities 262 in terms of objects. System 236 accesses UDM cube 258 to obtain the data represented by BI entities 262 and presents that data to the user in terms of the BI entities referenced in the query. Since the BI entities are generated at least based in part on the dimensions of dimensional model 258, they can represent an analytical, aggregated, view of the data.
Navigation service 237 allows a user to navigate from data represented by BI entities 262, back to the original entities 232 that contain the data. For instance, a user viewing data represented by BI entities 262 can “drill down” to the original transactional data that gave rise to the data in BI entities 262. This navigation is provided through navigation service 237.
FIG. 4 also shows that data can be reported through an abstraction layer referred to herein as report parts 239. Report parts 239 are contained in reports generated from the architecture and are described in greater detail below with respect to FIG. 4D.
FIG. 4A illustrates one embodiment of model services system (or component) 250 that takes, as inputs, a specification of focal points 252, an object description 254 and a set of persistent data store mappings 256. System 250 then produces a dimensional model 258 based on the inputs. FIG. 4A also illustrates entity generator component 260 that generates a set of objects (or entities), referred to herein as business intelligence entities (or BI entities) 262, based on the dimensional model 258.
Object description 254 is an input which describes the object orientation relationships in a set of metadata corresponding to a set of objects (such as business entities 232). This can take the form of, for example, a UML class diagram. One example of a UML class diagram for a plurality of business entities (Customer, Order and OrderLine) is illustrated in FIG. 4B.
Persistent data store mappings 256 map the data referred to by the object model to the persistent data store, in one illustrative embodiment the relational database 231 shown in FIG. 4. These are illustratively created by the user in the form of a map file, an example of which is found in Appendix B. The map file shown in Appendix B maps from a Customer entity to relational database tables.
Model services system 250 receives inputs 252, 254 and 256 and automatically generates a dimensional model 258 based on those inputs. In accordance with one embodiment of the present invention, dimensional model 258 is inferred from the inputs supplied by the user, and there is no requirement for a second set of developers to be involved in recreating the business logic to obtain model 258. In one embodiment, and as will be discussed in greater detail below, model services system 250 uses the associations and compositions in the object model specified by the object model description 254 to infer foreign key relationships in dimensional model 258. System 250 also uses the focal points of analysis defined by the user in file 252 and the persistent data store mappings 256 to automatically create dimensional model 258 and access data through model 258.
FIG. 4C illustrates the system shown in FIG. 4A, in greater detail. In the example illustrated in FIG. 4C, the object model is represented by object description 254, and the mappings 256 are shown between the object model representation 254 and the relational database representation 264 which represents relational database 231. FIG. 4C also shows dimensional model 258 in greater detail. Dimensional model 258 includes a Fact table 266 along with a plurality of dimensions 268 and 270 (the Customer dimension and the Order dimension). Each of the dimensions is formed of one or more tables. It is also worth noting that Fact table 266 includes the OrderlineID and CustomerID as foreign key references.
FIG. 4D is a more detailed block diagram of the architecture associated with report parts 239 shown in FIG. 4. Reports generated from the information shown in FIG. 4 contain report parts for data access. A number of different report parts are shown at 241 in FIG. 4D. Report parts 241 represent a higher level of data abstraction for data coming from entities 232, BI entities 262, object spaces, XML, etc. The report parts architecture 239 provides reusability for reports containing report parts 241, and at the same time provides a pluggable architecture for adding object oriented query providers such as those illustrated at 243 in FIG. 4D. In addition, this level of data abstraction allows the architecture to provide a unified query experience in design time, and a consistent data access interface in run time.
In one illustrative embodiment, the different query expressions used by different query provides 243 are not unified. Instead, during design time, “type” information is gathered from selected objects and used to prepare the expressions for queries. This design time metadata is gathered by object model 245 and is persisted in a global metadata store (or in metadata store 247). The metadata is gathered by unified query builder 249.
During run time, the design time metadata for a query is received by subsystem 251 and is serialized by serializer 253. Based on its type information, the query is provided to a designated query provider 243 through a common provider interface 255. The query providers 243 can access the information, in one embodiment, through a suitable security layer 257. If the received query requires access to two different query providers 243, it can be virtualized in a dataset first.
FIG. 4D also shows that the layer containing subsystem 251, type driver parser/serializer 253 and common provider interface 255 can also be accessed through a web service interface, an object interface, or a data binding service by a serialized dataset, a dataset for objects and a serialized row set, respectively.
Model services component 300 provides these inputs to map system 302 and invokes certain functionality in map system 302. Using the ER mapper, the user produces serialized ER maps 256 to describe how the object model is mapped to the relational database. These serialized maps 322 are then loaded by map loader 308. Map loader 308 deserializes those maps and converts them to entity map (EM) objects 324. The precise form of EM objects 324 is not important. They are simply objects generated from the serialized maps 322 that are predefined such that the structure of EM objects 324 is known by map walker 310. Loading maps 322 and creating EM objects 324 is indicated by block 323 in FIG. 6A.
Entity generator 260 then generates a non-primary BI entity for each dimension of the Fact table. It should be noted that nested classes can be used to maintain the original structure, hierarchy, and levels of the dimensional model. Generating the non-primary BI entities is indicated by block 514 in FIG. 11B. Entity generator 260 performs these operations for each Fact table in dimensional model 258, as indicated by block 516. FIG. 12 shows an interface implemented by Model Service to generate the code for accessing the dimension model created. The interface allows Model Service to convey information on the structure of the dimensional model to the code generator. A dimensional model consists of a cube with measures and a number of dimensions with hierarchies and attributes. FIG. 12 shows the relationships among these components of the dimensional model. The interface for invoking entity generator 260 is illustrated in FIG. 13. Appendix D illustrates the interfaces supported by the various components of system 250, and by entity generator 260.
MDX set functions supported: Cross join, children, descendants, ancestors, all members, members, etc.; MDX member functions supported: CurrentMember, DefaultMember, FirstChild, LastChild, Lead, Lag, etc. . . . ; MDX numeric functions supported: Average, Aggregate, count, sum, max, min, median, IIF, etc. . . . Table 1 lists one exemplary set of MDX operators which are supported.
<> (Comparison)
Criteria criteria = new Criteria(typeof(Sales));
criteria.CalculatedMembers.Add(Sales.Measures, “TotalSales”,
Sales.SaleDollars * Sales.SaleUnits);
//criteria with column selection
criteria.Column.Selection.Add(Sales.Measures.AllMembers( ));
//criteria added with row selection
criteria.Row.Selection.Add(Sales.Product.Category.Category.Members( )
criteria = new Criteria(typeof(Sales));
criteria.CalculatedMembers.Add(Sales.Measures, “Profitable”,
Sales.SaleDollars > Sales.Expense);
namespace Microsoft.TestNamespace.SubNameSpace {
// Sales EntityCube
[Microsoft.BusinessFramework.ReportingAnalysis.Analytics.Client.Metadata-
Info(“31236ae6-d9a8-417c-a6c6-abf450a27b1d”, “sales”)]
public sealed class Sales :
Microsoft.BusinessFramework.ReportingAnalysis.Analytics.Client.EntityCube {
// Product Dimension
private static Microsoft.TestNamespace.SubNameSpace.Product
product = new
Microsoft.TestNamespace.SubNameSpace.Product(typeof(Sales));
// SalesUnit Measure
private static Microsoft.TestNamespace.SubNameSpace.SaleUnits
saleUnits = new
Microsoft.TestNamespace.SubNameSpace.SaleUnits(typeof(Sales));
// SaleDollars Measure
Microsoft.TestNamespace.SubNameSpace.SaleDollars saleDollars =
Microsoft.TestNamespace.SubNameSpace.SaleDollars(typeof(Sales));
// Measures collection
Microsoft.BusinessFramework.ReportingAnalysis.Analytics.Client.Measures
measures = new
Microsoft.BusinessFramework.ReportingAnalysis.Analytics.Client.Measures(typeof(Sales));
// Dimensions collection
Microsoft.BusinessFramework.ReportingAnalysis.Analytics.Client.Dimensions
dimensions = new
Microsoft.BusinessFramework.ReportingAnalysis.Analytics.Client.Dimensions(typeof(Sales));
public static Microsoft.TestNamespace.SubNameSpace.Product
public static Microsoft.TestNamespace.SubNameSpace.SaleUnits
SaleUnits {
public static Microsoft.TestNamespace.SubNameSpace.SaleDollars
SaleDollars {
Measures {
Info(“efee9c2f-e003-43b4-a1cc-0741b72d0823”, “Product”)]
public sealed class Product :
Microsoft.BusinessFramework.ReportingAnalysis.Analytics.Client.Dimension {
// Category Hierarchy
Microsoft.TestNamespace.SubNameSpace.ProductNamespace.Category
public Product(System.Type entityCubeType) :
base(entityCubeType) {
this.category = new
Microsoft.TestNamespace.SubNameSpace.ProductNamespace.Category(this);
return this.category;
Microsoft.TestNamespace.SubNameSpace.ProductNamespace {
Info(“1808b148-2c5f-46fa-aa4c-102c7e0929cd”, “category”)]
public sealed class Category :
Microsoft.BusinessFramework.ReportingAnalysis.Analytics.Client.Hierarchy {
// All Level
Microsoft.TestNamespace.SubNameSpace.ProductNamespace.CategoryNamespace.All
// Category Level
Microsoft.TestNamespace.SubNameSpace.ProductNamespace.CategoryNamespace.Category
Category(Microsoft.TestNamespace.SubNameSpace.Product parent) :
this.all = new
Microsoft.TestNamespace.SubNameSpace.ProductNamespace.CategoryNamespace.All(this);
Microsoft.TestNamespace.SubNameSpace.ProductNamespace.CategoryNamespace.Category(this);
Microsoft.TestNamespace.SubNameSpace.ProductNamespace.CategoryNamespace
Info(“74f06e63-7b3f-46ae-ae03-2c97be8ed4d2”, “all”)]
public sealed class All :
Microsoft.BusinessFramework.ReportingAnalysis.Analytics.Client.Level {
All(Microsoft.TestNamespace.SubNameSpace.ProductNamespace.Category
parent) :
Info(“66068192-c3e2-42a0-9c2f-b76fe70a221e”, “category”)]
Category(Microsoft.TestNamespace.SubNameSpace.ProductNamespace.Category
Info(“cf84c740-787c-48f0-9f28-e800912c04db”, “SaleUnits”)]
public sealed class SaleUnits :
Microsoft.BusinessFramework.ReportingAnalysis.Analytics.Client.Measure {
public SaleUnits(System.Type entityCubeType) :
Info(“327eabf7-82a7-4de5-9802-68aab18a65b5”, “saleDollars”)]
public sealed class SaleDollars :
public SaleDollars(System.Type entityCubeType) :
Criteria criteria = new Criteria(typeof(Microsoft_EntityTest));
criteria.Column.Selection.Add
(Microsoft_EntityTest.FACT_Product_Product_UnitsInStock,
Microsoft_EntityTest.FACT_OrderLine_OrderLine_UnitPrice);
criteria.Row.Selection.Add(Microsoft_EntityTest.Order.Members( ));
Navigational service 237 (shown in FIG. 4) is now discussed in greater detail.
Various aspects of the present invention pertain to a system for enabling a user to extract useful information from a collection of business. The foundation underlying navigation service 237 is based upon the identification and user-utilization of navigation paths between related data elements. The general nature of five specific navigation paths will now be described in the context of the data processing environments described in relation to FIG. 4. Detailed data relationships that enable these data navigation paths are described below with respect to FIGS. 19-28.
As was discussed above in relation to FIG. 4, data store 259 illustratively contains data aggregations corresponding to transaction data stored in database 231. The first data navigation path relates to the process of traversing from an OLAP data element to corresponding transaction data. For the purpose of illustration, this navigation path will hereafter be referred to as “drill down” navigation (also can be referred to as “drill through” navigation).
An example will help to describe the nature of a drill down navigation. FIG. 19 is a screen shot demonstrating a presentation of aggregated data (e.g., OLAP data) to a user of a business application. The screen shot shows a graph illustrating the fact that a company's sales for calendar 1996 in the U.S. was $5,949.00. Assuming the user is interested in figuring out all of the U.S. customers that purchased the associated product in 1996, he can illustratively use a drill down navigation. Through a drill down navigation, the user is able to drill down to a customer transaction table. FIG. 20 is an example of a screen shot demonstrating the result of the drill down navigation, which is a customer transaction table showing U.S. customers who purchased the relevant product in calendar 1996.
The second data navigation path involves moving from transactional data to an associated aggregated collection of data (e.g., from transactional data to corresponding OLAP data, or from database 231 data to data in data store 259). For the purpose of illustration, this process of moving from transactional data to aggregated data is hereafter referred to as “drill up” navigation.
An example will help to describe the nature of a drill up navigation. The customer transaction table illustrated in the screen shot of FIG. 20 is an appropriate starting point for illustrating a drill up navigation. Each customer in the table has illustratively been assigned a city, as well as an ID category. If a user is interested in determining the aggregated total sales order quantity for all customers under the ID category “ALFKI”, a drill up navigation can be utilized to produce such information. FIG. 21 is a screen shot illustrating the result of the drill up navigation and shows a graph showing that the sales order quantity for the customer ID “ALFKI” is 225.58.
It is common for the data in data store 259 to be aggregated into a hierarchical scheme. For example, the following scheme is typical of organization within the data warehouse:
-->LOCATION
-->Region
-->City
-->Customer Name
Accordingly, an example set of data warehouse data is organized as follows:
-->Northwest
-->Seattle
-->Boeing
-->Portland
-->Starbucks
-->Midwest
-->Minneapolis
-->Target
Hierarchical schemes are utilized within the data warehouse because they are a relatively natural way to organize data. Given such organization, it becomes relatively simple to query data based on obvious aggregation patterns. For example, in accordance with the above example scheme, a user could easily query to find out what customers are in Portland, or to find out what customers are located in the Northwest, etc.
The third data navigation path involves moving through collections of data that are hierarchically organized. For the purpose of illustration, the third data navigation path will hereafter be referred to as “drill to detail” navigation. A drill to detail navigation enables a user to move through certain levels of data based on inherent hierarchical organization.
An example will bring light to the nature of a drill to detail navigation. FIG. 22 is an example of a screen shot that provides aggregated information (e.g., data in store 259) to a user of a business application. The screen shot includes a chart showing that U.S. sales for a company in calendar 1997 was $15,072.00. Assuming the user wants to see the monthly sales for calendar 1997, he/she can perform a drill to detail navigation. In other words, he/she can drill to the monthly sales for 1997. The ability to move between data sets in this manner is illustratively supported by the hierarchical organization of data store 259. FIG. 23 is a screen shot example showing a graph that represents monthly sales for 1997. The user is illustratively able to drill from the FIG. 22 aggregation to the narrower FIG. 23 aggregation.
It is possible for data, such as data in data store 259, to be organized in association with a framework that includes a multi-dimensional star-oriented schema, a simple example of which is illustrated in FIG. 24. Within FIG. 24, Sale 800 is associated with two dimensions, namely, customer 801 and product 802. Shipment 810 is associated with the same two dimensions. It should be noted that Sale 800 could just as easily be associated with dimensions that are different than the dimensions of Product 810. In accordance with one embodiment, Sale 800 and Shipment 810 are each independent objects or entities. In accordance with another embodiment, however, Sale 800 and Shipment 810 are independent data stores.
When dimensions are shared as they are in FIG. 24, the stage is set for the fourth data navigation path. For the purpose of illustration, the fourth data navigation path will hence forth be referred to as “drill across” navigation. With a drill across navigation, a user is able to navigate from a first object (or data warehouse) to an object (or data warehouse) that is similarly situated in terms of having a related dimension. For example, with reference to FIG. 24, if a user is looking at a collection of data related to Sale 800, he/she can drill across and view data pertaining to Product 810. A drill across navigation enables the user to switch between sets of inherently related data.
An example will help shed light on the nature of a drill across navigation. FIG. 25 is an illustration of a sample screen shot that contains a portion of a graph that is viewed by a user of a business application. The graph generally presents sales information. More specifically, the graph presents sales order quantity to product relationship data for a company. To simplify the illustration, only a few rows of the graph are shown. A complete graph will include additional rows. It is assumed that the data organization scheme supporting the graph includes a sales data warehouse and a product data warehouse that share the same dimension, namely a product dimension. Accordingly, assuming the user is interested in determining a stock value for a product underlying the graph of FIG. 25, he/she can drill across from the FIG. 25 graph to view stock value information. FIG. 26 is an example of a screen shot having a graph containing a stock value for a product.
In accordance with one embodiment of the present invention, the described fourth navigation path is based on an analysis of a dimensional model (such as UDM 258), or based on a BI entity model (such as BI entities 262). In accordance with one embodiment of the present invention, a fact-to-fact drill across navigation is available in instances where dimensions are shared.
The fifth data navigation path is called an ad hoc logic association navigation, hence forth referred to as a “logic association” navigation. This navigation path is essentially a user-defined shortcut between two sets of related data. In one embodiment, a user applies his/her business knowledge to identify properties within a first data collection that are related to properties in a second data collection. The related properties are then utilized as the basis for a data navigation path between the first and second collections of data.
An example will help to describe the fifth navigation path. A user illustratively creates a “Customer” object within a data warehouse. The same user also illustratively creates a “Customer-Related-Information” object. It is assumed that the user has a fundamental understanding of his/her business. In accordance with the fifth navigation path, the user applies his/her business knowledge to identify a property within the Customer object that is related to a property in the Customer-Related-Information object. The user is allowed to identify the related property relationship ad hoc at run time to enable data navigation between their associated objects. As opposed to the previously described four data navigation paths, the fifth path is generally not based on an underlying physical relationship, but instead is based on a user's understanding of his/her business.
In accordance with one embodiment of the present invention, a metadata store is created to catalog relationships between data elements. The above-described data navigation paths are illustratively defined and implemented through analysis of the relationship data in the metadata store.
FIG. 27 is a schematic diagram showing the input of data relationship information 1101 into a metadata store 1100. Navigation service 1104 then analyzes information in metadata store 1100 in order to identify certain data relationships that become the basis for implementation of navigation paths 1102. The nature of the services provided by service 1104, as well as an illustrative underlying architecture, will be described below in more detail in relation to other Figures. Suffice it to now say that the data relationships underlying navigation paths 1102 satisfy criteria applied by navigation service 1104 (e.g., criteria are created at runtime based on metadata in the metadata store and current data context input). Navigation paths 1102 are illustratively provided to a user of a business application in some form (e.g., a set of links) to enable intelligent data navigation. The user can illustratively utilize the automatically generated navigation paths to navigate through data in order to improve his/her understanding of data, to analyze data, to make projections, to make informed decisions, etc.
In accordance with one embodiment, the analysis of metadata store 1100 and the identification of navigation paths are performed at run time. Accordingly, with the possible exception of input required for logic association navigations, user knowledge is generally not required to enable utilization of the navigation paths. The navigation paths are identified and provided to the user simply based on data relationships reflected in the data processing system.
Population of metadata store 1100 with data relationship information 1101 will now be described in greater detail. It should be noted, however, that the specific type of relationship data stored within metadata store 1100 can be customized to support a particular navigation path. For example, it is within the scope of the present invention to develop a new navigation path and configure the system to store corresponding relationship data within metadata store 1100, if such data is not already being stored. For the purpose of illustration, examples of relationship data that is stored within metadata store 1100 to support the above-described and other data navigation paths will be described in detail.
It is common for data warehouse 210 (FIG. 2) or data store 259 (FIG. 4) to be organized in accordance with a framework that enables a user to define objects and relationships. An example of such a framework was illustrated and described in relation to FIG. 4B. In accordance with one aspect of the present invention, at least some of the relationships underlying the object-relational framework represent potential navigation paths, and are therefore utilized to populate metadata store 1100. For example, based on a UML object diagram, the relationships between objects (e.g., associations and compositions) represent potential navigation paths and are therefore illustratively identified and cataloged in metadata store 1100. Other known object relationships, such as inheritance relationships, also represent potential navigation paths and are therefore also illustratively cataloged in metadata store 1100.
In accordance with one aspect of the present invention, some of the data relationships 1101 stored in metadata store 1100 are from other sources as well. For instance, the data relationship 1101 in metadata store 1100 are related to mappings 1256, dimensional model 1258 and/or BI entity object model 1262.
Similarly, in accordance with one embodiment, relational mappings of the transition from the regular object model entities 254 (FIG. 4C) to the BI entity object model 262 (FIG. 4C) represent potential navigation paths, and are therefore added to metadata store 1100. For reference, the regular object model objects are business entities, while the objects associated with the OLAP data warehouse object model are BI entities.
The mappings between the business entities and the BI entities are illustratively saved to metadata store 1100. The mappings ultimately enable report navigation between the OLAP and OLTP domains. Also, navigation paths between BI entities are enabled for report navigation, including the ability to look across BI entities and to review transaction data associated with a BI entity.
FIG. 28 is a flow illustration demonstrating generation of BI entity metadata for the described intelligent navigation services. First, in accordance with step 1301, model service system 234 (FIG. 4) generates BI entities. Next, in accordance with step 1302, metadata 1304 is created based on the BI entities for the navigation service.
Exemplary correlations between specific data relationships and navigation paths will now be described, however, the present invention is not limited to the described examples.
In accordance with one aspect of the present invention, drill up and drill down navigation paths are derived based on the relationships between BI entities and their corresponding business entities. As has been described, the mappings generated during the generation of BI entities are cataloged to the metadata store. These mappings are illustratively the foundation that enables drill up and drill down navigations.
In accordance with another aspect of the present invention, model service system 234 is configured to identify the manner in which two UML models are related, and to generate shared dimensions for corresponding dimensional model cubes. Then, BI entities become the natural reflection of the star-oriented model, wherein for each dimension there will be generated one non-primary BI entity. To enable drill across navigation paths, the mappings between non-primary BI entities and their corresponding dimensions are illustratively cataloged to the metadata store. The relationships between BI entities are also identified. Accordingly, when two BI entities refer to the same shared dimension, a drill across is possible.
In accordance with another aspect of the present invention, to enable the foundation for drill to detail navigation paths, hierarchical relationships are cataloged to the metadata store when the BI entity model 262 is generated from the UML model 258 by model service 234.
With reference to FIG. 27 it was described that navigation service 1104 analyzes the data in metadata store 1100 in order to identify and implement navigation paths 1102. In accordance with additional aspects of the present invention, illustrative architectural characteristics and functional methodology will now be described with regard to navigation service 1104.
FIG. 29, in accordance with one aspect of the present invention, is a flow illustration demonstrating interaction between the navigation service (e.g., service 1104 in FIG. 27) and a user of the services provided. As is illustrated by step 1401, the process begins when the user transmits a request for data navigation to the navigation service. As is indicated by step 1402, the navigation service responds to the request by reviewing metadata (e.g., metadata stored in store 1100 in FIG. 27). In accordance with one embodiment, the user provides a data context to the navigation service in step 1401. The data context is the starting point for data analysis, such as the current data set being reviewed by the user. The navigation service illustratively reviews metadata based on the received data context to determine what data navigation paths are available to the user based on his/her data context starting point.
In accordance with step 1403, the navigation service provides a plurality of links to the user. The links, which are displayed to the user, represent data navigation paths that are available for execution. The links are identified based on the review of the metadata. As is represented by step 1404, the user selects a link and communicates the selection to the navigation service. In accordance with step 1405, the navigation service retrieves data corresponding to the user's selection. Finally, in accordance with step 1406, the result of the navigation is returned to the user, thereby providing him/her with the desired data set.
FIG. 30, in accordance with one aspect of the present invention, is a block diagram illustrating a navigation service architecture. The architecture includes, but is not limited to, a plurality of illustrated clients 1502, 1504, 1506 and 1508.
Examples of the clients are now discussed, but these are examples only and do not limit the scope of the invention. Client 1502 is illustratively a client based in the Microsoft Business Framework (MBF) but could by any other framework as well. The Microsoft Business Framework is a set of developer tools and software classes offered by Microsoft Corporation of Redmond, Wash. Client 1504 is illustratively a client based in Windows, an operating system offered by Microsoft Corporation, but could be based on any other operating system as well. Client 1506 is illustratively based in Microsoft Office, a software package offered by Microsoft Corporation, but could be based on any other software package as well. Client 1508 is a more generic identifier representing a web-based client.
In accordance with one embodiment, at least one of the illustrated clients are BAPI clients in that they are configured to support object-oriented programming via an interface defined in terms of objects and methods based in what is known as the Business Application Program Interface (BAPI). In other words, a BAPI client application navigates information using BAPI. To support the BAPI clients, the illustrated architecture includes a BAPI provider manager and an MBF BIPath API 1522, but any other BI path API could be used.
Provider manager 1520 is illustratively configured to operate in conjunction with a plurality of providers. A few specific providers, to which the present invention is not limited, are illustrated in FIG. 30. Providers 1536, 1534, 1532 and 1530 are configured to support different types of navigation, such as navigation based on analysis of BI Entity data, as described herein. Provider 1538 illustratively provides navigation via analysis of metamodel data. Provider 1540 is a generic block indicating other providers that the architecture can easily be extended to support (e.g., navigation based on other sources). At least one provider is illustratively a BAPI provider configured to operate in conjunction with the other BAPI components of the architecture.
In accordance with one aspect of the present invention, one of the BAPI clients sends a navigation Request to BAPI provider manager 1520 through BAPI. The BAPI provider manager then either delegates the Request to a set of specific providers or broadcasts to all providers. The BAPI provider manager 1520 then aggregates results returned from different providers and sends them back to the requesting BAPI client.
In accordance with one embodiment, when a new BAPI provider is implemented, it will implement the BAPI API and extend the Request/Response objects if necessary to provide additional functionality. The new BAPI provider will then be plugged into the BAPI provider manager 1520 and make itself available for requests. After this, the BAPI client will be able to request the service from the new BAPI provider to obtain any additional offered functionality.
Accordingly, a BAPI client includes an application that navigates information using BAPI. The BAPI, which will illustratively be exposed, is the principle interface implemented by a BAPI provider. A BAPI providers is an implementation of BAPI API: a BAPI client navigates to obtain a different information perspective via a BAPI provider. The framework can then be extended through implementation of future/other providers through the similar Request/Response object exchange format. There therefor can be type specific BAPI providers (Hypermedia providers, BIPath providers, etc.). This can be done through implementation of BAPI in a provider specific manner to support custom Request/Response objects. The BAPI provider plugs itself into the BAPI provider manager and is used by the BAPI client in a delegation (if type is specified)/broadcasting pattern.
It should be emphasized that the client systems involved can be web services or non-web services. The submitted Requests illustratively, although not necessarily, include a data context used by a provider in the creation of a Response. In accordance with one embodiment, certain providers are associated with their own particular type of data navigation path. For its type of path, the navigation provider is configured to identify corresponding navigation paths based on a received Request.
In accordance with one embodiment, when a new type of data navigation path is desired, a corresponding new provider is simply registered and integrated. Accordingly, any entity can illustratively develop a navigation path provider to expand on the types of navigations available to client users. In other words, the provider layer is essentially plug-and-play with the service layer to enable relatively simple extensions of service functionality.
FIG. 31 is a simplified block diagram illustrating the described navigation service architecture. As illustrated, a BAPI client 1904 sends Requests 1904 through API 1922 to BAPI provider manager 1920. In accordance with one embodiment, the Request in sent in the form of a “GetLinks( )” request to API 1922. BAPI provider manager 1920 either delegates the request to a corresponding provider (or providers) or broadcasts the request to multiple providers (e.g., all providers).
Within FIG. 31, the providers are generically lists as providers 1940 (e.g., providers that provide navigation paths based on business entity information), providers 1930 (e.g., providers that provide navigation paths based on BI Entity enformation), and providers 1936 (e.g., other ISV providers including providers that provide navigation paths based on “other” sources).
As is illustrated, requests are delegated (or broadcast) to providers 1940, 1938 and 1936, which respond with a response. In accordance with block 1906, the responses are then provided to BAPI client 1902 in an aggregated form (aggregation is optional). In accordance with one embodiment, the responses are provided to client 1902 in the form of a collection of links. A link is selected by a user of the client and a corresponding “TraverseLink( )” command is sent to API 1922. A corresponding navigation command is then sent to one or more providers so as to produce a data result, which is provided to client 1902.
It should be emphasized that the Request/Response objects can be extended by users. For example, each provider is configured to generate potentially different Requests/Responses (e.g., exemplified in FIG. 31 by the different sizes of response circles).
As was described above in relation to FIG. 29, the process of intelligent data navigation includes generation of a plurality of data navigation links available for a data context received from the user. FIG. 32, in accordance with one aspect of the present invention, is a combination block-flow diagram illustrating the process of collecting available navigation links in association with the described system architecture.
The process illustratively begins when a user 1602 interacts with a data navigation program (e.g., a plug-in navigation application implemented within a main application such as a spreadsheet or other application). Through the interaction, the user illustratively passes to a navigation service 1604 a data context and request for navigation links. Navigation service 1604 illustratively delegates (or broadcasts) a request for links to each of a plurality of navigation providers 1606-1614. Each navigation provider 1606-1614 is illustratively configured to support a different type of data navigation path. Each navigation provider interacts with metadata service 1616 to review information within metadata store 1618 (e.g., store 1100 in FIG. 27) based on the data context provided by the user to service 1604 to identify navigation paths of its own respective type. Each navigation provider 1606-1614 then returns a list of links to service 1604, the list of links corresponding to navigation paths available for the provider's respective navigation type. Service 1604 illustratively aggregates all available navigation links and provides them to the user 1602.
In accordance with one aspect of the present invention, as has been alluded to, as opposed to delegating a request for links to a suitable navigation provider, the request can instead be broadcast to multiple providers. In accordance with one embodiment, no navigation type is specified by a client in a broadcast request object. The clients do not specify a type so that the request will be broadcasted to multiple providers (e.g., all registered providers). The providers that know about the request will illustratively respond while other providers will not. This is different than the “delegating” scenario.
As was described above in relation to FIG. 29, the described process of intelligent data navigation also includes a user executing or traversing one particular link from the received aggregated list of links. FIG. 33, in accordance with one aspect of the present invention, is a combination block-flow diagram illustrating the process of traversing one particular navigation link in association with the described system architecture.
The FIG. 33 process begins with user 1602 selecting one of the available navigation links returned in response to his/her request for navigation. The selected link is provided to the navigation provider 1606-1614 to which it corresponds. In the illustrated example, the link is provided to drill across provider 1608. The provider that receives the link passes criterion related to the link to either data service 1630 or database service 1632. Service 1630 serves providers that will provide data warehouse (e.g., data warehouse 210) information to the user, while service 1632 services providers that will provide database (e.g., database 231) information to the user. Based on the received criterion, service 1630 or 1632 will interact with either data warehouse 1634 or database 1636, respectively, to obtain the information that corresponds to the navigation destination associated with the link. The information, which is illustratively the executed navigation, is provided to user 1602 through service layer 1604.
In accordance with one aspect of the present invention, the metadata in the metadata store (e.g., store 1100 in FIG. 27) is maintained in an XML format.
In accordance with one embodiment, the interface with which navigation providers interact to provide the described intelligent navigation capability can illustratively be described as follows:
Navigation Service Provider
+GetProviderInfo ([in]providerInfoRequest:XmlElement):XmlElement
+GetDrillPath ([in]DrillPathRequest:XmlElement):XmlElement
+TraverseLink([in]TraversReuest:XmlElement):XmlElement
+Navigate (NavigateRequest : XmlElement) : XmlElement
Finally, in accordance with one aspect of the present invention, FIG. 34 is an exemplary request/response class diagram that pertains to the processes associated with acquiring links in response to a user request for intelligent data navigation, and to the process of traversing one of the links selected by the user. As is illustrated, the processes are routed through a serialization base associated with an XML interface. It should be noted that the configuration of FIG. 34 is but one example of a system that is suitable to support the described intelligent navigation capabilities.
In accordance with one aspect of the present invention, following are a listing of code snippets that illustrate one exemplary implementation of the described extensible system.
The first code snippet (a) describes in code an example process of acquiring a listing of navigation links, and then traversing a navigation link. Comments denoted within the code snippet with “//” explain the functionality of each line of code.
a. Get Links and Traverse Link
//init INavigateProxy
INavigateProxy navigateProxy= ...;
//create get links request
GetLinksRequest getLinksRequest = new GetLinksRequest( );
//set containment key
getLinksRequest.ContainmentKey = ...;
//add data context
getLinksRequest.DataContext.Add(“Microsoft.EntityTests.Customer.CustomerID”, 01963656”);
//create a link filter
getLinksRequest.InclusiveFilters.Add(typeof(Microsoft.EntityTests.Sales), “TurnOver”, “Profit”) ;
//set link categories
getLinksRequest.LinkCategoryCollection.Add(“Microsoft.BusinessFramework.IntelliDrill.DrillUp”);
//send get links request
GetLinksResponse getLinksReponse = navigateProxy.GetLinks(getLinksRequest);
//traverse the link if a link is returned
TraverseLinkRequest traverseLinkRequest = new TraverseLinkRequest( );
traverseLinkRequest.Link = getLinksReponse.Links[0];
traverseLinkRequest.ContainmentKey = ...;
traverseLinkRequest.SecurityDescriptor = ...;
//send traverse link request
NavigateResponse navigateResponse = navigateProxy.TraverseLink(traverseLinkRequest);
//get dataset back
DataSet dataset = (DataSet) navigateResponse.Result;
The code snippet listed in part (a) assumes a scenario wherein, in response to a Request, a user is provided with a plurality of links. In accordance with one embodiment, the user simply asks for a link (or a type of link) and is directly provided a result. In essence, the GetLinks and TraverseLink processes are combined into a consolidated function. This consolidated function is illustratively called a Navigate function. Snippet (b) described a Navigate function.
b. Navigate
//create navigate request
NavigateRequest navigateRequest = new NavigateRequest( );
navigateRequest.ContainmentKey = ...;
navigateRequest.DataContext.Add(“Microsoft.Entity-
Tests.Customer.CustomerID”, “01963656”);
navigateRequest.InclusiveFilters.Add(typeof(Microsoft.EntityTests.Sales),
“TurnOver”, “Profiit”)
navigateRequest.LinkCategoryCollection.Add(“Micro-
soft.BusinessFramework.IntelliDrill.DrillUp”);
//set security descriptor
navigateRequest.SecurityDescriptor = ...;
NavigateResponse navigateResponse =
navigateProxy.Navigate(navigateRequest);
In accordance with one aspect of the present invention, in order to support new providers, a flexible architecture is provided wherein Request/Response objects are extensible. For example, a user can define tailored instances of GetLinks and other elements so as to extend the base class for new providers. Snippet (c) demonstrates the flexible architecture.
c. Request/Response Extensibility
public class MyGetLinksRequest : GetLinksRequest
public MyGetLinksRequest(XmlElement request) : base(request) { ... }
public String MyProperty { ... }
public class MyTraverseLinkRequest : TraverseLinkRequest
public class MyNavigateRequest : NavigateRequest
public class MyNavigateResponse : NavigateResponse
Request/Response Extensibility can illustratively be implemented by either extending the base class or using property bag.
In accordance with one aspect of the present invention, the extensible architecture extends to provider functionality. Snippet (d) is an example.
d. Provider Extensibility
public class MyNavigateProvider : INavigateProvider
public XmlElement GetLinks(XmlElement request)
//get object model from xml element
MyGetLinksRequest getLinksRequest =
new MyGetLinksRequest(request);
//do whatever with the request object
public String LinkCategory
return “Microsoft.BusinessFramework.IntelliDrill.MyDrillType”;
Snippet (e), in accordance with one aspect of the present invention, demonstrates how the extended architecture is implemented within the original system to enable extended functionality for new providers.
e. Extensibility usage
MyGetLinksRequest getLinksRequest = new MyGetLinksRequest( );
getLinksRequest.DataContext.Add(“Microsoft.Entity-
getLinksRequest.InclusiveFilters.Add(typeof(Microsoft.EntityTests.Sales),
“TurnOver”, “Profit”) ;
getLinksRequest.LinkCategoryCollection.Add(“Micro-
soft.BusinessFramework.IntelliDrill.MyDrillType”);
//set property for the extended request
getLinksRequest.MyProperty = ...;
GetLinksResponse getLinksReponse =
navigateProxy.GetLinks(getLinksRequest);
Similarly, navigation is provided. A user can navigate between and among transactional and analytical representations of the data.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS5499371Mar 22, 1995Mar 12, 1996Persistence Software, Inc.Method and apparatus for automatic generation of object oriented code for mapping relational data to objectsUS6101502Sep 25, 1998Aug 8, 2000Ontos, Inc.Object model mapping and runtime engine for employing relational database with object oriented softwareUS6173439Sep 24, 1998Jan 9, 2001International Business Machines CorporationInterface mechanism and method for accessing non-object oriented data from within an object oriented frameworkUS6212524May 6, 1998Apr 3, 2001E.Piphany, Inc.Method and apparatus for creating and populating a datamartUS6354689Dec 22, 1998Mar 12, 2002Eastman Kodak CompanyMethod of compensating for malperforming nozzles in a multitone inkjet printerUS6360223Jun 29, 1998Mar 19, 2002Sun Microsystems, Inc.Rule-based approach to object-relational mapping strategiesUS6609123Sep 1, 2000Aug 19, 2003Cognos IncorporatedQuery engine and method for querying data using metadata modelUS6665644Aug 10, 1999Dec 16, 2003International Business Machines CorporationConversational data miningUS6704744Sep 18, 2000Mar 9, 2004Next Computer, Inc.Method and apparatus for mapping objects to multiple tables of a databaseUS6807518Apr 13, 2000Oct 19, 2004Ford Motor CompanyMethod for analyzing product informationUS6862574Jul 27, 2000Mar 1, 2005Ncr CorporationMethod for customer segmentation with applications to electronic commerceUS6907433Aug 1, 2001Jun 14, 2005Oracle International Corp.System and method for managing object to relational one-to-many mappingUS6964023Feb 5, 2001Nov 8, 2005International Business Machines CorporationSystem and method for multi-modal focus detection, referential ambiguity resolution and mood classification using multi-modal inputUS6980980Jan 16, 2002Dec 27, 2005Microsoft CorporationSummary-detail cube architecture using horizontal partitioning of dimensionsUS7007029Jan 13, 2000Feb 28, 2006Metaedge CorporationSystem for visualizing information in a data warehousing environmentUS7111010Sep 24, 2001Sep 19, 2006Hon Hai Precision Industry, Ltd.Method and system for managing event attributesUS7185016Sep 1, 2000Feb 27, 2007Cognos IncorporatedMethods and transformations for transforming metadata modelUS7275024Mar 12, 2003Sep 25, 2007Microsoft CorporationAutomatic generation of a dimensional model for business analytics from an object model for online transaction processingUS7313561Dec 3, 2003Dec 25, 2007Microsoft CorporationModel definition schemaUS7315849Dec 9, 2002Jan 1, 2008Hyperroll Israel, Ltd.Enterprise-wide data-warehouse with integrated data aggregation engineUS7546226Dec 30, 2003Jun 9, 2009Microsoft CorporationArchitecture for automating analytical view of business applicationsUS7634478Dec 2, 2003Dec 15, 2009Microsoft CorporationMetadata driven intelligent data navigationUS20020060707Jan 29, 2002May 23, 2002Chia-Lei YuInk jet printer with a compensation function for malfunctioning nozzlesUS20020070953May 4, 2001Jun 13, 2002Barg Timothy A.Systems and methods for visualizing and analyzing conditioned dataUS20020087516Apr 3, 2001Jul 4, 2002Jean-Yves CrasMapping of an RDBMS schema onto a multidimensional data modelUS20020147848Aug 31, 2001Oct 10, 2002Burgin Daniel KeeleSystem and method for enabling communication between browser framesUS20030120593Aug 15, 2002Jun 26, 2003Visa U.S.A.Method and system for delivering multiple services electronically to customers via a centralized portal architectureUS20030187756Dec 27, 2002Oct 2, 2003Klivington Eva T.Electronic realty and transaction system and method thereinUS20040181502Mar 12, 2003Sep 16, 2004Microsoft CorporationGeneration of business intelligence entities from a dimensional modelUS20040215626Apr 9, 2003Oct 28, 2004International Business Machines CorporationMethod, system, and program for improving performance of database queriesUS20050038780Sep 14, 2004Feb 17, 2005I2 Technologies Us, Inc., A Nevada CorporationOptimization using a multi-dimensional data modelUS20050120021Dec 2, 2003Jun 2, 2005Microsoft CorporationMetadata driven intelligent data navigationUS20050246370Jul 8, 2005Nov 3, 2005Craig RubendallServer-side object filteringEP0974467A1Jul 9, 1999Jan 26, 2000EASTMAN KODAK COMPANY (a New Jersey corporation)Printer and method of compensating for malperforming and inoperative ink nozzles in a print headEP0983855A2Aug 12, 1999Mar 8, 2000Hewlett-Packard CompanyDot substitution to compensate for failed ink jet nozzlesEP1157840A2May 21, 2001Nov 28, 2001Canon Kabushiki KaishaDefective nozzle compensationWO1998040222A1Mar 6, 1998Sep 17, 1998Raster Graphics IncPrinting system and ink jet nozzle control method and apparatus having compensation for malfunctioning nozzlesWO1999008875A1Jul 31, 1998Feb 25, 1999Encad IncInk-jet printer, method and system compensating for nonfunctional print elementsNon-Patent CitationsReference1"A Survey of Approaches to Automatic Schema Matching", Rahm et al., The VLDB Journal 10:334-350, Feb. 2001.2"Automating Data Warehouse Conceptual Schema Design and Evaluation", Phipps et al., DMDW '02, Canada.3"Issues of Object-Relational View Design in Data Warehousing Environment", Gopalkrishnan et al., IEEE 0-7803-4778, Jan. 1998.4"Star/Snow-Flak Schema Driven Object-Relational Data Warehouse and Query Processing Strategies", Gopalkrishnan et al., DaWak '99, LNCS, 1999.5Barrett, Alexandria, "Databases Embrace XML," SW Expert, Aug. 2001, pp. 43-47.6Braganholo, et al., "On the Updatability of XML Views Over Relational Databases," International Workshop on the Web and Databases (WebDB), Jun. 12-13, 2003, San Diego, California.7Coox, S.V., "Axiomatization of the Evolution of XML Database Schema," Programming Computer Software, vol. 29, No. 3, 2003, pp. 1-7, Jan. 29, 2003.8European Application No. 04005846.3-2224 Communication pursuant to Article 96(2) EPC, dated Apr. 26, 2007.9European Search Report 2003.10Hahsler, Dr. Michael. Knowledge Management Data Warehouses and Data Mining of Economics and BA, Dec. 11, 2001, pp. 2-29.11HiTSoftware, "Unifying XML and Relational Database Application Development," Jan. 2003, pp. 1-10.12Meng, et al. "OrientStore: A Schema Based Native XML Storage System," 29th VLDB Conference, Berlin, Germany 2003.13Notice of Allowance dated Jul. 19, 2007, in related case for U.S. Appl. No. 10/386,633, filed Mar. 12, 2003.14Notice of Allowance dated Mar. 20, 2007, in related case for U.S. Appl. No. 10/386,633, filed Mar. 12, 2003.15Notice of Allowance dated Mar. 27, 2009, in related case for U.S. Appl. No. 10/748,391, filed Dec. 20, 2003.16Notice of Allowance dated Oct. 16, 2007, in related case for U.S. Appl. No. 10/727,176, filed Dec. 3, 2003.17Notice of Allowance dated Sep. 30, 2009, in related case for U.S. Appl. No. 10/425,665, filed Dec. 2, 2003.18Office Action for U.S. Appl. No. 10/386,633, mailed Jun. 21, 2006.19Office Action for U.S. Appl. No. 10/727,176, mailed Jun. 27, 2006.20Official Action dated Nov. 27, 2007, in related case for U.S. Appl. No. 10/748,391, filed Dec. 20, 2003.21Related European Official Action dated Jun. 13, 2007, for Serial No. 04005846.3, filed Mar. 11, 2004.22Related Japanese Official Action dated Jan. 19, 2010, for Serial No. 2004-69829, filed Mar. 11, 2004.23U.S. Appl. No. 10/386,633 Office Action mailed Dec. 11, 2006.24U.S. Appl. No. 10/386,633 Office Action mailed Jun. 21, 2006.25U.S. Appl. No. 10/725,665 Office Action mailed May 28, 2009.26U.S. Appl. No. 10/725,665 Office Action mailed Nov. 25, 2008.27U.S. Appl. No. 10/727,176 Office Action mailed Apr. 9, 2007.28U.S. Appl. No. 10/727,176 Office Action mailed Dec. 20, 2006.29U.S. Appl. No. 10/727,176 Office Action mailed Jul. 5, 2007.30U.S. Appl. No. 10/727,176 Office Action mailed Jun. 27, 2006.31U.S. Appl. No. 10/748,391 Office Action mailed Aug. 7, 2008.32U.S. Appl. No. 10/748,391 Office Action mailed Mar. 20, 2007.33XML.com, "Mapping DTDs to Databases," http://www.xml.com/lpt/a/2001/05/09/dtdodbs.html, May 19,2001.34XML.com, "RAX: An XML Database API," http://www.xml.com/lpt/a/2000/04/26/rax/index.html, Apr. 26, 2000.35XML.com, "RAX: An XML Database API," http://www.xml.com/lpt/a/2000/04/26/rax/index.html, Apr. 26, 2000.Referenced byCiting PatentFiling datePublication dateApplicantTitleUS8694481 *Jan 4, 2012Apr 8, 2014Fujitsu LimitedComputer product, information processing apparatus, and information processing methodUS20120239672 *Jan 4, 2012Sep 20, 2012Fujitsu LimitedComputer product, information processing apparatus, and information processing method* Cited by examinerClassifications U.S. Classification703/2, 703/21, 703/17, 703/13, 717/108International ClassificationG06F17/10, G06F7/00Cooperative ClassificationY10S707/99931, G06F17/30592, G06F17/30604, G06F17/30607European ClassificationG06F17/30S8M, G06F17/30S8T, G06F17/30S8R2Legal EventsDateCodeEventDescriptionDec 9, 2014ASAssignmentOwner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTONFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034564/0001Effective date: 20141014Aug 25, 2014FPAYFee paymentYear of fee payment: 4RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services