CA2427159A1 - Simplified metadata modelling for reporting - Google Patents

Simplified metadata modelling for reporting Download PDF

Info

Publication number
CA2427159A1
CA2427159A1 CA002427159A CA2427159A CA2427159A1 CA 2427159 A1 CA2427159 A1 CA 2427159A1 CA 002427159 A CA002427159 A CA 002427159A CA 2427159 A CA2427159 A CA 2427159A CA 2427159 A1 CA2427159 A1 CA 2427159A1
Authority
CA
Canada
Prior art keywords
data
query
model
metadata
data sources
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
CA002427159A
Other languages
French (fr)
Inventor
Charles Mike Potter
Glen Michael Seeds
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Cognos Inc
Original Assignee
Cognos Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Cognos Inc filed Critical Cognos Inc
Priority to CA002427159A priority Critical patent/CA2427159A1/en
Priority to EP04010200A priority patent/EP1475733A3/en
Priority to US10/835,236 priority patent/US7747651B2/en
Priority to CA002465643A priority patent/CA2465643A1/en
Publication of CA2427159A1 publication Critical patent/CA2427159A1/en
Abandoned legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/242Query formulation
    • G06F16/2423Interactive query statement specification based on a database schema

Abstract

The invention introduces a methodology to automatically derive the relationships between tables and columns within tables so that problems such as those that result in double counting of information are avoided. It comprises a method for creati ng a report by first defining a model based on an existing database comprising two or mo re querySubjects, each querySubject comprising at least one fact column and one primary key column, then generating a hierarchy within the model. Next a further fac t is introduced into one of the querySubjects. The expression is decomposed into sub-queries so that double-counting of data in ambiguously defined situations is prevent ed using the further fact to determine that such decomposition is required. Finally, the data is accessed using the sub-queries, and a report is produced.

Description

Simplified Metadata Modelling for Reporting FIELD OF THE INVENTION
The present invention relates generally to a metadata model, and more particularly to a metadata model which is suitably used in a reporting system that accesses one or more data stores including relational databases..
BACKGROUND OF THE INVENTION
Currently, information reporting systems use predefined query techniques to hide the complexity of Structured Query Language (SQL) and relational databases. T
ypically, members of Management Information System (MIS) staff build a database solution by creating user-dedicated tables, relational views or predefined SQL queries.
These are then made available to users by means of menus or similar techniques. In these systems, if end-users want to change the purpose of a query they ask the MIS staff to program another query. Alternatively the user rnay program the SQL query or command themselves. However, the syntax of non-procedural languages (in particular SQL) is complex, and typically, the data structure is not expressed in terms of the users' everyday work. Relational databases store information as well as metadata (data describing the data organisation) such as tables, columns, keys, indices, and their structure and design.
Although suited to the overall needs of the customer organisation, these databases will likely contain much that is not of interest to a particular user. In addition, although a query may be syntactically correct, its results may not be what are expected, due to the inherent complexity of a large scale database. Indeed, the results may be totally meaningless.
For these and other reasons modeling tools are often used that allow conceptual modeling of databases. These tools provide a layer on top of the database, and allow the underlying database to be accessed in terms that are more relevant to a particular end application. Such modeling tools include "Impromptu", "Transformer", and "Architect"
by Cognos Incorporated.
2 A previous application "Metadata Modeling", Cowlings file 0$84485US, Canadian Application 2,317,166, filed 31 August 2000, describes a three level abstraction model for use in such environments. This is described with reference to figure 1.
The lowest level in the database abstraction is the internal level 1. In the internal level l, the database is viewed as a collection of files. organized according to an internal data organization. The internal data organization may be anyone of several possible internal data organizations, such as B+-tree data organization and relational data organization..
The middle level in the database abstraction is the conceptual level 2. In the conceptual level 2, the database is viewed at an abstract level. The user of the conceptual level 2 is thus shielded from the internal storage details of the database viewed at the internal level 1.
The highest level in the database abstraction is the external level 3. In the external level 3, each group of users has their own perception or view of the database.
Each view is derived from the conceptual level 2 and is designed to meet the needs of a particular group of users. To ensure privacy and security of data, each group of users only has access to the data specified by its particular view for the group.
The mapping between the three levels of database abstraction is the task of the DBMS. When the data structure or file organization of the database is changed, the internal level 1 is also changed. When changes to the internal level 1 do not affect the conceptual level 2 and external level 3, the DBMS is said to provide for physical data independence. When changes to the conceptual level 2 do not affect the external level 3, the DBMS is said to provide for logical data independence.
Typical DBMSs use a data model to describe the data and its structure, data relationships, and data constraints in the database. Some data models provide a set of operators that are used to update and query the database. DBMSs may be classified as either record based systems or object based systems. Both types of DBMSs use a data model to describe databases at the conceptual level 2 and external level 3.
3 Data models may also be called metadata models as they store metadata, i.e., data about data in databases.
Three main existing data models used in record based systems are the relational model, the network model and the hierarchical model.
In the relational model, data is represented as a collection of relations. To a large extent, each relation can be thought of as a table. A typical relational database contains catalogues, each catalogue contains schemes, and each schema contain tables, views, stored procedures and synonyms. Each table has columns, keys and indexes. A
key is a set of columns whose composite value is distinct for all rows. I~o proper subset of the key is allowed to have this property. A table may have several possible keys. Data at the conceptual level 2 is represented as a collection of interrelated tables. The tables are normalized so as to minimize data redundancy and update anomalies. The relational model is a logical data structure based on a set of tables having common keys that allow the relationships between data items to be defined without considering the physical database organization.
A known high level conceptual data model IS the Entity-Relationship (ER) model. In an ER model, data is described as entities, attributes and relationships. An entity is anything about which data can be stored. Each entity has a set of properties, called attributes, that describe the entity. A relationship is an association 'between entities.
F'or example, a professor entity may be described by its name, age, and salary and can be associated with a department entity by the relationship "works for". Existing information systems use business intelligence tools or client applications that provide data warehousing and business decision making and data analysis support services using a data model. In a typical information system, a business intelligence tool is conceptually provided on the top of a data model, and underneath of the data model is a database. The data model of existing information systems typically has layers corresponding to the external level 3 and the internal level 1. Some data models may use a layer corresponding to both the external level 3 and the conceptual level 2
4 Existing data models are used for the conceptual design of databases. When a system designer constructs an information system, the designer starts from a higher abstraction level 3 and moves down to a lower abstraction level 1, as symbolized in Figure 1 by arrows.
That is, the system designer first performs logical design. At the logical design stage, the designer considers entities of interest to the system users and identifies at an abstract level information to be recorded about entities. The designer then determines conceptual scheme, i.e., the external level 3 and/or conceptual level 2 of a data model.
After the logical design is completed, the designer next performs physical design. At the physical design stage, the designer decides how the data is to be represented in a database. The designer then creates the corresponding storage scheme, i.e., the structure of a database, and provides mapping between the internal level 1 of the data model and the database.
Existing business intelligence tools thus each provides a different paradigm for retrieving and delivering information from a database. Accordingly, it is difficult to share information in the database among different business intelligence tools.
It is common that in a single organization, each group of users has its own established information system that uses its corresponding database. Thus, the single organization often has multiple databases. Those databases often contain certain types of information which are useful for multiple groups of users. Such types of information may include information about business concepts, data retrieval, and user limits and privileges.
1-Iowever, each information system was designed and constructed in accordance with specific needs of the group, and may use a different business intelligence tool from others. These differences in the information systems and business intelligence tools used do not allow sharing the information already existing in the databases among multiple groups of users.
5 The previous invention describes a data model or metadata model which realizes the three abstraction levels and provides information that can be shared by multiple users who use those different business intelligence tools or client applications.
It does this by providing a metadata model that defines model objects to represent one or more data sources. The metadata model comprises a data access layer, a business layer and a package Layer. The data access layer contains data access model objects. The data access model objects include a data access model object that describes how to retrieve data from the data sources. The business layer contains business model objects.
The business model objects include a business model object that describes a business view of data in the data sources. The package layer contains package model objects. The package model objects include a package model object which references a subset of business model objects.
It also provides for a metadata model to contain model objects representing one or more data sources. The data sources contain tables having columns. The metadata model comprises a data access layer, a business layer and a package layer. The data access layer contains data access model objects. The data access model objects include table objects that describe definitions of the tables contained in the data sources, and column objects that describe definitions of the columns of the tables contained in the data sources. The business layer contains business model objects. The business model objects include entities that are constructed based on the table objects in the data access layer, and attributes that are constructed based on the column objects in the data access Layer. The package layer contains package model objects. The package model objects include a package model object that reference a subset of the business model objects.
What is needed is a way to reduce the apparent complexity and inherent learning barrier to the use of the earlier invention.
SUMMAIW' OF THE INVENTION
The present invention introduces a methodology that reduces the apparent complexity faced by a user when confronted by this modeling environment.
6 In one aspect the invention provides for a metadata model that represents one or more data sources, the metadata model comprising a combined data access and business layer including query subjects that describe how to retrieve data from the data sources, the query subjects containing query items.
In a second aspect the invention provides for a metadata model containing model objects representing one or more data sources, the data sources containing tables having columns, the metadata model comprising a combined data access and business layer containing query subjects, the query subjects including table objects that describe definitions of the tables contained in the data sources, and query items that describe definitions of the columns of the tables contained in the data sources.
BRIEF DESCRIPTION OF DRAWINGS
Embodiments of the invention will be described with reference to the following figures:
Figure 1 is a diagram showing an example of database abstractions;
Figure 2 is a diagram showing an example of a reporting system to which an embodiment of the present invention is applied;
Figure 2A is a diagram showing functions of the metadata exchange, metadata model and transformations shown in Figure 2; and Figure 3 describes the use of the metadata model by the query engine.
DETAILED DESCRIPTION OF THE INVENTION
We now describe preferred embodiments of the present invention. All such embodiments may conveniently be implemented on any general purpose computing platform, including one incorporated in a client/server or networked environment.
7 Although the abstraction levels described in the earlier invention are necessary, presenting them directly to modelers creates a substantial learning barrier to those using the tool because the levels are not related to how the users perceive the data.
In order to make the model as useful as practicable, it is necessary to reduce these barriers to the point where the operation of the model is intuitive to users that understand the results expected from a reporting application, but who only have limited knowledge of the underlying database, or of database analysis techniques generally. In this context, users are the people (model designers and report authors) who develop report outlines or templates.
~Ve therefore introduce new concepts, requiring (or rather resulting in) the definition of related new terminology. This new terminology is described in this new context. The new terms are then used with the concepts to describe one embodiment of the invention. In doing so, the various simplifications, and rationalizations made to the original concept as described in the previous patent (Metadata Modeling) are made clear.
Figure 2 illustrates a reporting system 4 to which an embodiment of the present invention is suitably applied. The reporting system 4 provides a single administration point for rnetadata that supports different business intelligence tools or client applications. Thus, it enables different business intelligence tools to extract and interpret data from various data sources in the same way.
The reporting system 4 includes common object services (COS) 5, a metadata exchange 10, a metadata model 15, a metadata model transformer or transformations 20, a user interface 25 and a query engine 30. The fundamental objective of the reporting system 4 is to provide a rich business-oriented metadata model 15 that allows the query engine 30 to generate the best queries of which it is capable, and allows users to build queries, reports and cubes with the aid of the query engine 30 to obtain desired reports from underlying data sources. To this end, COS 5, metadata exchange 10 and transformations 20 are provided.
8 COS 5 defines the framework for object persistence. Object persistence is the storage, administration and management of objects on a physical device and transfer of those objects to and from memory as well as the management of those objects on the physical device. The double head arrow from COS 5 in Figure 2 represents that communicates with all other elements shown in Figure 2. COS 5 performs functions such as creating new obj ects, storing them on disk, deleting them, copying them, moving them, handling change isolation (check-in, check-out) and object modeling.
. The metadata exchange 10 is used to obtain metadata from external physical sources. Metadata is obtained from one or more external sources of metadata.
As shown in Figure 2A, external sources of metadata may be one or more data sources 100 and/or one or more metadata sources 101. Data sources 100 contain physical data.
Examples of data sources 100 include databases and files. Metadata sources 101 contain descriptive information about data sources. Metadata sources 101 are also known as metadata repositories. Metadata repositories may be third party repositories. Metadata sources 101 generally have underlying data sources 100 containing physical data. The metadata exchange 10 facilitates importation of metadata from external sources 100 and 101 into the metadata model 15. Also, the metadata exchange 10 may facilitate exportation of metadata from the metadata model 15 to external metadata repositories.
The metadata model 15 stores metadata about its underlying one or more data sources 100. It is used to provide a common set of business-oriented abstractions of the underlying data sources 100. The metadata model 15 defines the objects that are needed to define client applications that users build. The metadata model 15 provides three layers to realize three levels of abstractions of data sources 100 as described above referring to Figure 1. The three layers are a physical layer or data access layer 102, a business layer 104 and a presentation layer or package layer 106.
Transformations 20 are used to complete the metadata model 15. For example, when a database is introduced to the reporting system 4, metadata is imported from the database into the metadata model 15. Metadata may also be imported from one or more metadata repositories or other data sources. Sufficient metadata may be imported from a
9 database that would build only a small number of the objects that would actually be needed to execute queries. However, if such rnetadata does not have good mapping to the metadata model 15, then the transformations 20 can be used to complete the metadata model 15.
The user interface 25 is layered on top of the metadata model 15 as a basic maintenance facility. The user interface 25 provides users with the ability to browse through the metadata model 15 and manipulate the objects defined thereby The query engine 30 is responsible for taking the metadata model 15 and a user's request for information, and generating a query that can be executed against the underlining data sources, e.g., a relational database. The query engine 30 is basically the reason for the existence of the rest of the blocks. The objective of the query engine 30 is to function as efficiently as possible and to preserve the semantics of the original question. A user may ask a question that is not precise. The request may be for something from "customers" and something from "products". But these may be related in multiple ways. The query engine 30 needs to figure out which relationship is used to relate "customers" and "products" to provide the user with information requested.
The use of the metadata model 15 by the query engine 30 is briefly described with reference to Figure 3. A user uses a business intelligence tool or client application (not shown) to generate a user's request for information. Upon the receipt of the user's request, the client application generates an initial specification 35 based on the request.
The specification 35 may be ambiguous. Also, it is not in a form that can be applied to the data sources directly. Using the information that is built in the metadata model 15, the query engine 30 makes the specification 35 unambiguous and builds a query in terms of the data access layer 102 for the specification 35. This intermediate formulation of the query is also called a physical query and is subsequently translated into a data source specification language. The data source specification language may be structured Query Language (SQL). A query in a data source specification language can be executed on the data sources. Thus, the correct data 40 may be obtained.

The metadata model 15 provides a unified and centralized modeling environment, and application program interfaces for business intelligence tools. The architecture of the metadata model 15 will now be described in further detail.
The metadata model 15 is composed of several layers, namely, a physical layer or data access layer 102, a business layer 104 and a presentation layer or package layer 106.
These layers correspond to those abstraction levels described earlier and shown in Figure 1. However, in the present invention, the access layer 102 and business layer 104 are combined. This is possible because the entities and attributes used in defining the model have been replaced by the more powerful concepts of concepts of query subjects and query items. When a database schema is imported, the system now creates a set of unified database query subjects that are directly tied to the underlying database, and are also directly usable in creating reports without the need for a separate business layer as was previously the case. This set of objects bring together all of the abstraction and mapping that the previous invention (Metadata lvlodeling) handles with 'connections' between physical and logical segments of the model. In contrast to a 'view', which is defined by the database administrator DBA, a query subject is abstracted and separate from the underlying database, is applicable to and able to translate different kinds of databases, and provides a translation of the data and metadata into the terminology of the user.
The combined data access and business layer 102, 104 contains metadata that describes how to retrieve physical data from data sources 100. It is used to formulate and refine queries against the underlying data sources 100. The underlying data sources 100 rnay be a single or multiple data sources, as described above. Examples of data sources 100 include relational databases, such as Oracle, Sybase, DB2, SQL Server and Informix.
The combined data access and business layer 102, 104 contains a part of the model objects that directly describe actual physical data in the data sources 100 and their relationships. These model objects are called query subjects, and contain query items, which are attributes and relate the columns of the underlying databases. In addition, the query subjects may include, among other things, databases, catalogues, schemas, tables, files, columns, data access keys, indexes and data access joins, as well as SQL code that assists in the transformation of the data. Each table has one or more columns.
Data access joins exist between tables..
The query subjects in the combined data access and business layer 102, 104 may be thought of as extended metadata, which are created as a result of importing metadata from data sources 100 and metadata sources 101 provided by users. The information of some data access objects may be available from the underlying data sources 100. The user can customize some objects in the data access layer 102 in order to create data access joins, i:e., relationships between objects that were imported from various data sources.
The combined data access and business layer 102, 104 also describes the business view of the physical data in the underlying data sources 100. It is used to provide business abstractions of the physical data with which the query engine 30 can formulate queries against the underlying data sources 100.
Thus the combined data access and business layer 102, 104 contains information encapsulated in the query subjects and query items that can be used to define in abstract terms the user's business entities and their inter-relationships. The query subjects are reusable objects that represent the concepts and structure of the business to be used in business intelligence environments. They present a single unified business model, with direct relationships to the underlying databases, and can be related to physical data in a number of different data sources 100. 'the business model also includes business rules and display rules. As well as query subjects and query items, the business model may include keys and joins. Since the query subjects have the ability to incorporate SQL, they may be used directly in creating reports without the need for a separate business layer as previously. This set of objects bring together alI of the abstraction and mapping that the previous invention (Metadata Modeling) handles with 'connections' between physical and logical segments of the model. In contrast to a 'view', which is defined by the database administrator, a query subject is abstracted and separate from the underlying database, is applicable to and able to translate different kinds of databases, and provides a translation of the data and metadata into the terminology of the user.

The various parts of the business model are closely related to the underlying data in that, for example, query subjects are related to tables in the data access layer 102 indirectly; and query items correspond to columns in the underlying data sources 100.
Business joins exist between query subjects. The new terms query subjects and query items are not totally analogous to older terms, since they imply an extra level of referencing is possible thereby providing powerful new benefits as will be obvious from the following description. Each business model object has a partner in the data access layer 102, i.e., a relationship exists between a table and an entity. The query subjects also hold the rnetadata representing the business concept. They are collections of attributes.
Query items within the combined layer contain expressions related to columns of tables in the underlying database. A query item is usually directly related to a single column of the underlying data sources 100. For example, the query subject "customer"
could have query items "customer name", ''customer address", and the like. In the simplest case, all the query items of a query subject in the combined access and business layer 102, 104 are related one-to-one to the columns of a single table in the underlying data sources 100. However, the relationship is not always a one-to-one relationship.
Also, a query item may be expressed as a calculation based on other query items, and constants, (and columns). For example, a query item may be a summary of data in other query items, e.g., a total amount of all the orders placed by customer.
Query subjects are related to other query subjects by joins.
The query subjects, during the importation process are converted to 'objects' containing embedded SQL. During use, such objects may be inserted into existing SQL
statements - typically using 'drag and drop' graphical techniques - and the embedded SQL takes care of ensuring consistent syntax. In some circumstances, guided manual intervention is required during the creation of these new objects, but generally it is an automated process.
The present technique is a significant improvement over that described earlier, in that almost all of the modelling process is automated, and only occasional intervention is required.

Additional levels of abstraction can be built for different levels of reporting by creating model query subjects whose query items are simply references to other query items, which can be in either database queries or model queries. In other words, references to references can be used,to any arbitrary depth.
In summary, the invention can be considered to involve the following concepts:
~ The embedding of SQL in a database query object (query subject) to facilitate access to the underlying databases.
~ The inclusion of query items in the query subjects, and the ability to use them interchangeably.
~ The inclusion of filter and calculation building blocks capable of acting on query subjects and query items contained in the query subjects through an extended form of SQL (or pseudo-SQL) that is not constrained by the capabilities of the underlying databases and their related database query languages.
~ The definition of relationships for the various query items so that they are not necessarily based directly on database columns.
The concept of entities (distinguishable objects to be represented in the database -usually by rows in relations) and attributes (columns or fields in a table) -is replaced by the concept of query subjects and query items. This is not just a change in terms. When a database schema is imported, the system creates a set of unii~ed database query subjects that are directly tied to the underlying database, and are also directly usable in creating reports without the need for a business layer as previously. This set of objects bring together all of the abstraction and mapping that the previous invention (Metadata Modelling) handles with 'connections' between physical and logical segments of the model. IN contrast to a 'view'. Which is defined by the database administrator, a query subject is abstracted and separate from the underlying database, is applicable to and able to translate different kinds of databases, and provides a translation of the data and metadata into the terminology of the user.
In the case of the present invention, these terms entities and attributes are 'replaced' by the terms query subject, which is the subject of the relational query, and query item, which is a particular attribute of a query subject (or rather a pointer or something that can be de-referenced as necessary to ultimately provide that data). These new terms may in fact be pointers or references to their underlying query item or query subject respectively. The new terms are not totally analogous to the older terms, since then imply that this extra level of referencing is possible - and thereby provide powerful new benefits.
The query subjects, during the importation process are converted to 'objects' containing embedded SQL. During use, such objects may be inserted into existing SQL
statements - typically using 'drag and drop' techniques - and the embedded SQL
takes care of ensuring consistent syntax. In some circumstances, guided manual intervention is required during the creation of these new objects, but generally it is an automated process.
The present technique is a significant improvement over that described earlier, in that almost all of the modelling process is automated, and only occasional intervention is required.
Additional levels of abstraction can be built for different levels of reporting by creating model query subjects whose query items are simply references to other query items, which can be in either database queries or model queries. In other words, references to references can be used,to any arbitrary depth.

Claims (6)

What we claim is:
1. A metadata model defining model objects to represent one or more data sources, the metadata model comprising a combined data access and business layer including query subjects that describe how to retrieve data from the data sources, the query subjects containing query items.
2. The metadata model as claimed in claim 1, wherein the query subjects are constructed from metadata in the data sources.
3. The metadata model as claimed in claim 1, wherein the query subjects include a query subject that is imported from a metadata repository.
4. The metadata model as claimed in claim 1, wherein the data sources include a database that contains a table having columns; the query subjects include definitions of the tables contained in the data sources, and query items that that describe definitions of the columns of the tables contained in the data sources.
5. A metadata model containing model objects representing one or more data sources, the data sources containing tables having columns, the metadata model comprising a combined data access and business layer containing query subjects, the query subjects including table objects that describe definitions of the tables contained in the data sources, and query items that describe definitions of the columns of the tables contained in the data sources.
6. The invention as substantially described in the specification attached hereto.
CA002427159A 2003-04-29 2003-04-29 Simplified metadata modelling for reporting Abandoned CA2427159A1 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CA002427159A CA2427159A1 (en) 2003-04-29 2003-04-29 Simplified metadata modelling for reporting
EP04010200A EP1475733A3 (en) 2003-04-29 2004-04-29 Metadata model for reporting comprising a query layer which combines the functions of a data access layer and a business layer
US10/835,236 US7747651B2 (en) 2003-04-29 2004-04-29 Metadata modelling for reporting
CA002465643A CA2465643A1 (en) 2003-04-29 2004-04-29 Metadata modelling for reporting

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CA002427159A CA2427159A1 (en) 2003-04-29 2003-04-29 Simplified metadata modelling for reporting

Publications (1)

Publication Number Publication Date
CA2427159A1 true CA2427159A1 (en) 2004-10-29

Family

ID=32968320

Family Applications (1)

Application Number Title Priority Date Filing Date
CA002427159A Abandoned CA2427159A1 (en) 2003-04-29 2003-04-29 Simplified metadata modelling for reporting

Country Status (3)

Country Link
US (1) US7747651B2 (en)
EP (1) EP1475733A3 (en)
CA (1) CA2427159A1 (en)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8694532B2 (en) * 2004-09-17 2014-04-08 First American Data Co., Llc Method and system for query transformation for managing information from multiple datasets
US7809763B2 (en) * 2004-10-15 2010-10-05 Oracle International Corporation Method(s) for updating database object metadata
US8010376B2 (en) * 2006-12-15 2011-08-30 Sap Ag On-request views of business object types
US20080183725A1 (en) * 2007-01-31 2008-07-31 Microsoft Corporation Metadata service employing common data model
US20080208806A1 (en) * 2007-02-28 2008-08-28 Microsoft Corporation Techniques for a web services data access layer
US8495513B2 (en) * 2008-05-13 2013-07-23 International Business Machines Corporation Automated content generation through selective combination
US8250024B2 (en) * 2008-05-13 2012-08-21 International Business Machines Corporation Search relevance in business intelligence systems through networked ranking
US8484204B2 (en) * 2008-08-28 2013-07-09 Microsoft Corporation Dynamic metadata
US8775921B2 (en) * 2009-09-03 2014-07-08 International Business Machines Corporation Creating, updating, saving, and propagating customized views of table and grid information
CA2718701A1 (en) 2010-10-29 2011-01-10 Ibm Canada Limited - Ibm Canada Limitee Using organizational awareness in locating business intelligence
US9754230B2 (en) * 2010-11-29 2017-09-05 International Business Machines Corporation Deployment of a business intelligence (BI) meta model and a BI report specification for use in presenting data mining and predictive insights using BI tools
US8874601B2 (en) * 2010-12-17 2014-10-28 Sap Ag SADL query view—a model-driven approach to speed-up read-only use cases
US9171039B2 (en) * 2011-09-29 2015-10-27 Sap Se Query language based on business object model
CN102591952A (en) * 2011-12-28 2012-07-18 用友软件股份有限公司 Data query device and data query method based on semanteme
US9582782B2 (en) 2012-04-04 2017-02-28 International Business Machines Corporation Discovering a reporting model from an existing reporting environment
US9547672B2 (en) * 2012-09-24 2017-01-17 Bmc Software, Inc. Zero-outage database reorganization
US10761839B1 (en) * 2019-10-17 2020-09-01 Globant España S.A. Natural language search engine with a predictive writing tool for coding

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4454576A (en) * 1981-05-18 1984-06-12 International Business Machines Corporation Report preparation
US5287444A (en) 1989-08-14 1994-02-15 International Business Machines Corporation Message processing system
ATE190156T1 (en) * 1992-09-04 2000-03-15 Caterpillar Inc INTEGRATED DESIGN AND TRANSLATION SYSTEM
US5611076A (en) * 1994-09-21 1997-03-11 Micro Data Base Systems, Inc. Multi-model database management system engine for databases having complex data models
US5893125A (en) * 1995-01-27 1999-04-06 Borland International, Inc. Non-modal database system with methods for incremental maintenance
US5903859A (en) * 1996-03-27 1999-05-11 Dell Usa, L.P. Dynamic multi-lingual software module system
US6003036A (en) * 1998-02-12 1999-12-14 Martin; Michael W. Interval-partitioning method for multidimensional data
US6411961B1 (en) * 1999-01-15 2002-06-25 Metaedge Corporation Apparatus for providing a reverse star schema data model
US7167853B2 (en) * 1999-05-20 2007-01-23 International Business Machines Corporation Matching and compensation tests for optimizing correlated subqueries within query using automatic summary tables
US6847962B1 (en) * 1999-05-20 2005-01-25 International Business Machines Corporation Analyzing, optimizing and rewriting queries using matching and compensation between query and automatic summary tables
CA2281331A1 (en) * 1999-09-03 2001-03-03 Cognos Incorporated Database management system
FR2806183B1 (en) * 1999-12-01 2006-09-01 Cartesis S A DEVICE AND METHOD FOR INSTANT CONSOLIDATION, ENRICHMENT AND "REPORTING" OR BACKGROUND OF INFORMATION IN A MULTIDIMENSIONAL DATABASE
US7185192B1 (en) * 2000-07-07 2007-02-27 Emc Corporation Methods and apparatus for controlling access to a resource
US6996566B1 (en) * 2000-11-21 2006-02-07 International Business Machines Corporation Method and system for an object model with embedded metadata and mapping information
US20030101170A1 (en) * 2001-05-25 2003-05-29 Joseph Edelstein Data query and location through a central ontology model
US7139755B2 (en) * 2001-11-06 2006-11-21 Thomson Scientific Inc. Method and apparatus for providing comprehensive search results in response to user queries entered over a computer network
US6738762B1 (en) * 2001-11-26 2004-05-18 At&T Corp. Multidimensional substring selectivity estimation using set hashing of cross-counts
US20030154277A1 (en) * 2002-02-11 2003-08-14 Rabih Haddad Method and system for real-time generating, managing, and broadcasting multimedia events reports over communications networks
US6999977B1 (en) * 2002-05-09 2006-02-14 Oracle International Corp Method and apparatus for change data capture in a database system
US7136873B2 (en) * 2002-07-20 2006-11-14 Microsoft Corporation Dynamic filtering in a database system
US7162469B2 (en) * 2002-07-20 2007-01-09 Microsoft Corporation Querying an object for properties
US6996556B2 (en) * 2002-08-20 2006-02-07 International Business Machines Corporation Metadata manager for database query optimizer
US7383513B2 (en) * 2002-09-25 2008-06-03 Oracle International Corporation Graphical condition builder for facilitating database queries
US20040249810A1 (en) * 2003-06-03 2004-12-09 Microsoft Corporation Small group sampling of data for use in query processing
US20040268306A1 (en) * 2003-06-30 2004-12-30 Cheng Ken Prayoon Methods, systems and computer program products for language independent data communication and display

Also Published As

Publication number Publication date
EP1475733A2 (en) 2004-11-10
EP1475733A3 (en) 2004-12-08
US7747651B2 (en) 2010-06-29
US20050027674A1 (en) 2005-02-03

Similar Documents

Publication Publication Date Title
US6662188B1 (en) Metadata model
US6611838B1 (en) Metadata exchange
US7133865B1 (en) Method and systems for making OLAP hierarchies summarisable
US7769769B2 (en) Methods and transformations for transforming metadata model
Parent et al. Database integration: the key to data interoperability
US7747651B2 (en) Metadata modelling for reporting
Böhlen et al. Temporal data management–an overview
EP1081610A2 (en) Methods for transforming metadata models
Berger et al. From federated databases to a federated data warehouse system
EP4155964A1 (en) Centralized metadata repository with relevancy identifiers
Ahmed et al. An overview of Pegasus
US7555786B2 (en) Method for providing security mechanisms for data warehousing and analysis
Vincini et al. Semantic integration of heterogeneous data sources in the momis data transformation system
Maatuk et al. Converting relational databases into object relational databases
Follenfant et al. RDF modelling and SPARQL processing of SQL abstract syntax trees
Ma et al. Semantic web technologies and data management
Berger et al. Analysing multi-dimensional data across autonomous data warehouses
CA2465643A1 (en) Metadata modelling for reporting
CA2317166C (en) Metadata model
Lee et al. Spatial metadata and its management
Lin Object-oriented database systems: A survey
N. Karanikolas et al. Comparison of Post-Relational and Object-Relational modelling for real-world database applications
Tankoano Providing in RDBMSs the Flexibility to Work with Various Non-Relational Data Models
CA2318302C (en) Methods and transformations for transforming metadata model
Beneventano et al. Query translation on heterogeneous sources in momis data transformation systems

Legal Events

Date Code Title Description
FZDE Discontinued