WO2006062747A2 - Schema de base de donnees - Google Patents

Schema de base de donnees Download PDF

Info

Publication number
WO2006062747A2
WO2006062747A2 PCT/US2005/042622 US2005042622W WO2006062747A2 WO 2006062747 A2 WO2006062747 A2 WO 2006062747A2 US 2005042622 W US2005042622 W US 2005042622W WO 2006062747 A2 WO2006062747 A2 WO 2006062747A2
Authority
WO
WIPO (PCT)
Prior art keywords
data
attribute
elements
database
class
Prior art date
Application number
PCT/US2005/042622
Other languages
English (en)
Other versions
WO2006062747A3 (fr
Inventor
Anthony Guy Gaines
Jason Patrick Walker
Original Assignee
Calpine Corporation
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 Calpine Corporation filed Critical Calpine Corporation
Publication of WO2006062747A2 publication Critical patent/WO2006062747A2/fr
Publication of WO2006062747A3 publication Critical patent/WO2006062747A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/284—Relational databases
    • G06F16/288—Entity relationship models

Definitions

  • the present invention relates to database software. More particularly, the present invention relates to a schema for managing a database with improved performance.
  • Project management is the process of keeping track of all the different phases of complex activities over time. Project management software enables such activities to be broken into many separate sub-tasks, and then displays the way these tasks overlap in time, often using some standard model such as Gantt charts or Critical Path Analysis.
  • Project management is very complex, comprising a multitude of requirements for information management. These requirements range from estimating and budgeting processes to task management, planning, and scheduling. Additionally, there are various processes that need attention such as specifications, design, procurement, progress, quality, and deficiencies.
  • tables are invariably named in a manner that describes their component set. For example, if the table is used to store information about people, it might be named "tblPeople". Similarly, columns are named in a manner describing their contents. Clearly this mnemonic naming of objects facilitates the categorization of data into various domains, enabling user interaction with the data.
  • Control data tables may define the schema and behavior
  • authentication data tables may be utilized in access control and security
  • data tables may comprise the content of the databases.
  • FIG. 1 is a diagram illustrating a parent-child set type arrangement in a data_element table in accordance with an embodiment of the present invention.
  • FIG. 2 is a diagram illustrating a data_elements table in accordance with an embodiment of the present invention.
  • FIG. 3 is a diagram illustrating an organizational chart in accordance with an embodiment of the present invention.
  • FIG. 4 is a diagram illustrating a parent-child set type arrangement in a data_element table along with a ctl_element table in accordance with an embodiment of the present invention.
  • FIG. 5 is a diagram illustrating the content of a ctl_elements table in accordance with an embodiment of the present invention.
  • FIG. 6 is a diagram illustrating the content of a ctl_elements table after additional classes have been added in accordance with an embodiment of the present invention.
  • FIG. 7 is a diagram illustrating a data_elements table with newly added records in accordance with an embodiment of the present invention.
  • FIG. 8 is a diagram illustrating an organizational chart after the addition of records in accordance with an embodiment of the present invention.
  • FIG. 9 is a diagram illustrating an example of attribute tables and associated support and control tables in accordance with an embodiment of the present invention.
  • FIG, 10 is a diagram illustrating an example of a control attribute table loaded with desired attributes in accordance with an embodiment of the present invention.
  • FIG. 11 is a diagram illustrating an example of a control class attributes links table in accordance with an embodiment of the present invention.
  • FIG. 12 is a diagram illustrating an organizational chart showing loaded attributes in accordance with an embodiment of the present invention.
  • FIG. 13 is a diagram illustrating the storage of txt attributes in accordance with an embodiment of the present invention.
  • FIG. 14 is a diagram illustrating the storage of num attributes in accordance with an embodiment of the present invention.
  • FIG. 15 is a diagram illustrating a ctl_elements table with added classes in accordance with an embodiment of the present invention.
  • FIG. 16 is a diagram illustrating actual data added to a data elements table in accordance with an embodiment of the present invention.
  • FIG. 17 is a diagram illustrating attributes added to a data attribute dnx table in accordance with an embodiment of the present invention.
  • FIG. 18 is a diagram illustrating a data_xact table in accordance with an embodiment of the present invention.
  • FIG. 19 is a diagram illustrating actual cost data added into a data transactions table in accordance with an embodiment of the present invention.
  • FIG. 20 is a diagram illustrating records that may be added to the ctl_elements table in accordance with an embodiment of the present invention.
  • FIG. 21 is a diagram illustrating a data elements table in accordance with an embodiment of the present invention.
  • FIG. 22 is a diagram illustrating the data elements table of FIG. 21 with an additional record representing an association between elements in accordance with an embodiment of the present invention.
  • FIG. 23 is a flow diagram illustrating a method for adding data to a database in accordance with an embodiment of the present invention.
  • FIG. 24 is a block diagram illustrating an apparatus for adding data to a database in accordance with an embodiment of the present invention.
  • the components, process steps, and/or data structures may be implemented using various types of operating systems, computing platforms, computer programs, and/or general purpose machines.
  • devices of a less general purpose nature such as hardwired devices, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), or the like, may also be used without departing from the scope and spirit of the inventive concepts disclosed herein.
  • the present invention allows an unlimited number of sets to be persisted and interrelated, while each element of each set has an unlimited collection of properties or attributes, and each element of each set may also have an unlimited collection of transactions which themselves may have an unlimited collection of properties or attributes.
  • This may be accomplished using three types of tables, control data tables, authentication data tables, and data tables, and providing a clear separation between them.
  • Control data tables may define the schema and behavior
  • authentication data tables may be utilized in access control and security
  • data tables may comprise the content of the databases.
  • zzzz_elements may refer to ctl_elements, auth_elements, and data_elements.
  • Sets are domains comprised of various elements, representing those objects to which data should be related. Sets may be thought of as elements, or in more conventional terms, rows or records.
  • the present invention allows for an unlimited number of primary data structures, with each set having a hierarchical Parent-Child structure. Additionally, each element member of each set can have an unlimited number of relationships with members of any set, including its own.
  • FIG. 1 is a diagram illustrating a parent-child set type arrangement in a data_element table in accordance with an embodiment of the present invention.
  • each parent (p_id) 100 is allowed multiple children (e__id) 102, and that the parent 100 for a given child must exist in the data_elements table as an element (e_id).
  • the p_id value 0 may be reserved as the root. However, any unique character may be used.
  • FIG. 2 is a diagram illustrating a data_elements table in accordance with an embodiment of the present invention.
  • FIG. 3 is a diagram illustrating an organizational chart in accordance with an embodiment of the present invention. Populating the data_elements table as shown in FIG. 2 would persist the necessary structure for the organizational chart in FIG. 3.
  • the s_id column 200 is a utility column introduced to simplify programming, hence the absence of data in that column.
  • the c_id value 202 may change for each type of element, or level in the organizational chart depicted in FIG. 3.
  • c_id allows for the persistence of multiple separate primary data structures as well as multiple associative data structures. This effectively allows for the creation of separate instances of the zzzz_elements tables. Additionally, c_id may also be leveraged to assign a set of attributes to those elements of a particular class, which will be described in more detail later in this document. To support this, the ctl_elements table may be introduced.
  • FIG. 4 is a diagram illustrating a parent-child set type arrangement in a data_element table along with a ctl_element table in accordance with an embodiment of the present invention.
  • ctl_elements table positive values of c_id may be used to differentiate between class types for those elements in the ctljslements table.
  • Negative c_id values may be reserved to differentiate entity types for those elements present in the zzzz_elements table.
  • -1 may define a record of type Class for use with zzzz_elements.
  • -2 may define a record of type Class for use with zzzz_xact.
  • -3 may define a record of type Association for use with zzzz_elements.
  • FIG. 5 is a diagram illustrating the content of a ctl_elements table in accordance with an embodiment of the present invention. Elements bearing c_id of -1 establish classes for corporation 500, division 502, and plant 504.
  • FIG. 6 is a diagram illustrating the content of a ctl_elements table after additional classes have been added in accordance with an embodiment of the present invention. Then, c_id may be set to a value of -1 to indicate that the record is of type Class for use with zzzz_elements.
  • FIG. 7 is a diagram illustrating a data_elements table with newly added records in accordance with an embodiment of the present invention.
  • Primary data structures can be persisted as well as associated data structures. The difference between the two is that each element belongs to its own primary data structure domain, while it is possible for that same element to be a part of several associative data structure domains.
  • FIG. 8 is a diagram illustrating an organizational chart after the addition of records in accordance with an embodiment of the present invention.
  • five plants 800a, 800b, 800c, 800d, 800e of a corporation 802 are represented, and separate structure 804 represents a purchase order.
  • properties are those characteristics or attributes that can be used to describe the various elements of a set. These may be thought of as attributes or columns.
  • the present invention allows for an unlimited number of attributes that can be made available to any element. In conventional terms, these attributes are synonymous with the metadata tags used to name columns in tables.
  • some new tables may be introduced into the schema. These include ctl_attr, which serves as a collection of all available attributes, and data_e_attr_xxx, where xxx represents the type of data persisted.
  • the available options may be anx, cnx, dnx, which represent lookups to e_id from auth_elements, ctl_elements, or data_elements, respectively.
  • the available options are date/time(dtm), obj, num and txt, which store data for the suggested formats.
  • FIG. 9 is a diagram illustrating an example of attribute tables and associated support and control tables in accordance with an embodiment of the present invention.
  • the two sets of tables have been separated to demonstrate the different relationships.
  • the metadata column name is persisted in the ctl_attr table 900, while the actual attribute value is persisted in the appropriate data_e_attr_xxx tables.
  • the collection of attributes available for a given element in ctl_element (class) 902 is persisted in ctl_class_attr_links 904.
  • each of the plants should have an address, and the Purchase Order Line Item a Unit Price and Quantity
  • the attributes should be made available to the appropriate classes. This may involve loading ctl_attr with the desired attributes, as depicted in FIG. 10.
  • ctl_class_attr_links may be loaded to enable the appropriate attributes for the appropriate classes, as depicted in FIG. 11.
  • attributes may be loaded to persist data as shown in FIG. 12.
  • the storage of the txt and num attributes is straightforward and may be represented by FIG. 13 and FIG. 14, respectively.
  • the storage of the dnx attributes is a bit more complex, as the stored value in the dnx is really a pointer to e_id in data_elements.
  • FIG. 15 is a diagram illustrating a ctl_elements table with added classes in accordance with an embodiment of the present invention.
  • e_id 9, for Header, has been added to serve as an organizational branch used to organize like classes.
  • the actual data may be added to the data_elements table and attributes (pointers) may be added to the data_e_attr_dnx table. This is depicted in FIGS. 16 and 17, respectively.
  • transactions are those recurring events that are value and time sensitive in nature which occur against a member, or members of a set. Transactions can possess properties.
  • the present invention allows for an unlimited number of transactions having an unlimited number of types of transmissions. Transactions have available to them the same property mechanism that has been demonstrated for elements.
  • a transaction may be viewed as a child of an element, with the properties of the transaction describing the nature of the transaction.
  • the payments for the purchase order may occur over time.
  • FIG. 18 is a diagram illustrating a data_xact table in accordance with an embodiment of the present invention. The payments may be recorded in the data_xact table 1800.
  • FIG. 20 is a diagram illustrating records that may be added to the cnt_elements table in accordance with an embodiment of the present invention. Here, a record may be created for the default type of transaction.
  • sets are associative data structure domains that can be extremely useful and efficient for presenting data from several different contexts. For example, one may want to present the 121 Purchase Order record as a child of the 117 Plant record. This can simply be added as an association between the element 117 and the element 121, as depicted in FIG. 21
  • a record may be added to ctl_elements that may be used to classify the record in data_elements as an association.
  • One of the primary types of associations that is used is an alias.
  • An alias allows the mixture of data between primary data structure domains, effectively making the data from the primary domain available in the associative domain.
  • a record can be added to the data_elements table that represents the association between 117 Plant and 121 Purchase Order, as depicted in FIG. 22
  • This record may depend on a dnx attribute to point at the source element, and based on the class of association, various sets of business rules can be applied to the data engine to show children or not, to carry source attributes or not, etc.
  • the organizational chart in FIG. 23 depicts a situation where the association has been designated to include all children of the source element.
  • FIG. 23 is a flow diagram illustrating a method for adding data to a database in accordance with an embodiment of the present invention. Each act in this method may be performed in software, hardware, or any combination thereof.
  • data to be stored in the database may be received, the data having one or more elements belonging to one or more classes, each element potentially having one or more attribute values with one or more types, each class potentially having one or more attribute names, the data also potentially having one or more transactions associated with the elements, the transactions potentially having one or more attribute values with one or more types, the transactions having one or more classes potentially having one or more attribute names.
  • 2302-2330 refer to acts performed within a loop. The loop advances through the elements in the data, beginning with the first element.
  • the class associated with this element may be added to a control elements table in the database.
  • all attribute names for the element class may be stored in a control attributes table in the database, except for attribute names already in the control attributes table.
  • all attribute names for the element class may be stored in a control class attribute links table in the database. 2304-2306 need only be performed if the class associated with this element is new.
  • the element may be persisted to a data elements table in the database.
  • each of the attribute values for the element may be stored in a data attribute table in the database corresponding to the type of the attribute value.
  • it then may be determined if the element has transactions. If so, then 2316-2328 refer to acts performed within a loop. The loop advances through the transactions in the element, beginning with the first transaction.
  • it may be determined if the class associated with this transaction is new. If so, then at 2318, the class for this transaction may be added to the control elements table in the database.
  • all attribute names for the transaction class may be stored in a control attributes table, except for attribute names already in the control attributes table.
  • all attribute names for the transaction class may be stored in a control class attribute links table in the database. 2318- 2322 need only be performed if the class associated with this transaction is new.
  • the transaction may be loaded into a data transactions table in the database.
  • each of the attribute values for the transaction may be stored in a data transaction attribute table in the database corresponding to the type of the attribute value.
  • it may be determined if this is the last transaction for the element. If not, then the process may loop back to 2316, advancing to the next transaction for the element. If so, however, then at 2330, it may be determined if this is the last element in the data. If not, then the process may loop back to 2302, advancing to the next element in the data. If so, however, then at 2332, access rights for various users to portions of the database maybe stored in an authentication table in the database. It should be noted that it may be necessary to prevent users from accessing the data in these portions of the database until access rights are established, lest newly loaded data be left available to unwanted access.
  • FIG. 24 is a block diagram illustrating an apparatus adding data to a database in accordance with an embodiment of the present invention.
  • Each element in this apparatus may be embodied in software, hardware, or any combination thereof.
  • a data receiver 2400 may receive data to be stored in the database, the data having one or more elements belonging to one or more classes, each element potentially having one or more attribute values with one or more types, each class potentially having one or more attribute names, the data also potentially having one or more transactions associated with the elements, the transactions potentially having one or more attribute values with one or more types, the transactions having one or more classes potentially having one or more attribute names. Acts may then be performed within a loop. The loop advances through the elements in the data, beginning with the first element.
  • a new element class determiner 2402 coupled to the data receiver 2400 may determine if the class associated with this element is new. If so, then a class control elements table adder 2404 coupled to the new element class determiner 2402 may add the class for this element a control elements table in the database. Then an all possible attribute names control attribute table storer 2406 coupled to the class control elements table adder 2404 may store all attribute names for the element class in a control attributes table in the database, except for attribute names already in the control attributes table. An attribute name control class attribute links table storer 2408 coupled to the all possible attribute names control attribute table storer 2406 may store all attribute names for the element class in a control class attribute links table in the database.
  • An elements data elements table persister 2410 coupled to the class control elements table adder 2404 and to the attribute name control class attribute links table storer 2408 may persist the element to a data elements table in the database.
  • An attribute value data attribute type table storer 2412 coupled to the elements data elements table persister 2410 may store each of the attribute values for the element in a data attribute table in the database corresponding to the type of the attribute value.
  • An element transaction determiner 2414 coupled to the data receiver 2400 may determine if the element has transactions. If so, then acts are performed within a loop. The loop advances through the transactions in the element, beginning with the first transaction.
  • a new transaction class determiner 2416 coupled to the element transaction determiner 2414 may determine if the class associated with this transaction is new. If so, then the class control elements table adder 2404 coupled to the new transaction class determiner 2416 may add the class for this transaction to the control elements table in the database.
  • the all possible attribute names control attribute table storer 2406 may then store all attribute names for the transaction class in a control attributes table, except for attribute names already in the control attributes table.
  • the attribute name control class attribute links table storer 2408 may then store all attribute names for the transaction class in a control class attribute links table in the database.
  • a transactions data transactions table persister 2418 coupled to the new transaction class determiner 2416 may load the transaction into a data transactions table in the database.
  • An attribute value data transaction attribute type table storer 2420 coupled to the transactions data transactions table persister 2418 may then store each of the attribute values for the transaction in a data transaction attribute table in the database corresponding to the type of the attribute value.
  • a last transaction determiner 2422 coupled to the attribute value data transaction attribute type table storer 2420 may determine if this is the last transaction for the element. If not, then the process may proceed back to determining if the transaction class is new, advancing to the next transaction for the element. If so, however, then a last element determiner 2424 coupled to the last transaction determiner 2422 may determine if this is the last element in the data.
  • a various user access right authentication table storer 2426 coupled to the new element class determiner 2402 may store access rights for various users to portions of the database in an authentication table in the database. It should be noted that it may be necessary to prevent users from accessing the data in these portions of the database until access rights are established, lest newly loaded data be left available to unwanted access.
  • the present invention allows the supporting database code to be reused, in that a similar object may be used in various places within the same application. It also allows the code to be portable, as it can be easily utilized by other platforms. Furthermore, the present invention provides a schema that is easily compatible with distributed systems. Additionally, the cost of implementation and the storage size of the database are both dramatically reduced. The present invention also allows database modification to occur at a much quicker rate of speed than prior art solutions.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Storage Device Security (AREA)

Abstract

Un nombre illimité d'ensembles peuvent être conservés et rendus interdépendants, tandis que chaque élément de chaque ensemble peut présenter un nombre illimitée de propriétés ou d'attributs, et chaque élément de chaque ensemble peut également avoir un nombre illimité de transactions qui elles-mêmes peuvent avoir un nombre illimité de propriétés ou d'attributs, grâce à l'utilisation de trois types de tables, des tables de données de commande, des tables de données d'authentification, et des tables de données, en opérant une nette séparation entre elles. Des tables de données de commande peuvent définir le schéma et le comportement, des tables de données d'authentification peuvent être utilisées dans le contrôle et la sécurité d'accès, et les tables de données peuvent comprendre le contenu des base de données.
PCT/US2005/042622 2004-12-09 2005-11-23 Schema de base de donnees WO2006062747A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/009,288 2004-12-09
US11/009,288 US20060129509A1 (en) 2004-12-09 2004-12-09 Database schema

Publications (2)

Publication Number Publication Date
WO2006062747A2 true WO2006062747A2 (fr) 2006-06-15
WO2006062747A3 WO2006062747A3 (fr) 2006-11-23

Family

ID=36578390

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2005/042622 WO2006062747A2 (fr) 2004-12-09 2005-11-23 Schema de base de donnees

Country Status (2)

Country Link
US (1) US20060129509A1 (fr)
WO (1) WO2006062747A2 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101996218A (zh) * 2009-08-21 2011-03-30 上海博科资讯股份有限公司 一种实现数据访问权限控制的方法
CN103929325A (zh) * 2014-02-26 2014-07-16 浪潮软件股份有限公司 一种信息系统集成中的组织机构及用户权限统一控制方法

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7788499B2 (en) * 2005-12-19 2010-08-31 Microsoft Corporation Security tokens including displayable claims
US20070203852A1 (en) * 2006-02-24 2007-08-30 Microsoft Corporation Identity information including reputation information
US8117459B2 (en) * 2006-02-24 2012-02-14 Microsoft Corporation Personal identification information schemas
US8104074B2 (en) * 2006-02-24 2012-01-24 Microsoft Corporation Identity providers in digital identity system
US8078880B2 (en) * 2006-07-28 2011-12-13 Microsoft Corporation Portable personal identity information
US8087072B2 (en) * 2007-01-18 2011-12-27 Microsoft Corporation Provisioning of digital identity representations
US8407767B2 (en) * 2007-01-18 2013-03-26 Microsoft Corporation Provisioning of digital identity representations
US8689296B2 (en) 2007-01-26 2014-04-01 Microsoft Corporation Remote access of digital identities
CN105227380B (zh) * 2015-10-29 2019-07-16 邱彼特 用户数据处理的方法、装置及系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5423034A (en) * 1992-06-10 1995-06-06 Cohen-Levy; Leon Network file management with user determined hierarchical file structures and means for intercepting application program open and save commands for inputting and displaying user inputted descriptions of the location and content of files
US5446575A (en) * 1991-06-28 1995-08-29 Digital Equipment Corp. System for constructing and loading a table data structure based on an associated configuration data
US20030028537A1 (en) * 2001-07-31 2003-02-06 Manabu Nakamura Relay server, relay server method, and relay server computer program product
US20030115176A1 (en) * 2000-01-07 2003-06-19 Bobroff Peter James Information system
US20040015470A1 (en) * 2002-07-20 2004-01-22 Smith Michael David Dynamic filtering in a database system

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5446575A (en) * 1991-06-28 1995-08-29 Digital Equipment Corp. System for constructing and loading a table data structure based on an associated configuration data
US5423034A (en) * 1992-06-10 1995-06-06 Cohen-Levy; Leon Network file management with user determined hierarchical file structures and means for intercepting application program open and save commands for inputting and displaying user inputted descriptions of the location and content of files
US20030115176A1 (en) * 2000-01-07 2003-06-19 Bobroff Peter James Information system
US20030028537A1 (en) * 2001-07-31 2003-02-06 Manabu Nakamura Relay server, relay server method, and relay server computer program product
US20040015470A1 (en) * 2002-07-20 2004-01-22 Smith Michael David Dynamic filtering in a database system

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101996218A (zh) * 2009-08-21 2011-03-30 上海博科资讯股份有限公司 一种实现数据访问权限控制的方法
CN101996218B (zh) * 2009-08-21 2013-07-24 上海博科资讯股份有限公司 一种实现数据访问权限控制的方法
CN103929325A (zh) * 2014-02-26 2014-07-16 浪潮软件股份有限公司 一种信息系统集成中的组织机构及用户权限统一控制方法

Also Published As

Publication number Publication date
US20060129509A1 (en) 2006-06-15
WO2006062747A3 (fr) 2006-11-23

Similar Documents

Publication Publication Date Title
WO2006062747A2 (fr) Schema de base de donnees
US7827478B2 (en) Dynamic generation of form pages for accessing a database
Halevy et al. Enterprise information integration: successes, challenges and controversies
Bernstein et al. Information integration in the enterprise
US9026901B2 (en) Viewing annotations across multiple applications
US7734657B2 (en) Containment hierarchy in a database system
CN100470538C (zh) 对多个内容管理数据模型的支持
US5721911A (en) Mechanism for metadata for an information catalog system
US20110179049A1 (en) Automatic Aggregation Across Data Stores and Content Types
US7613715B2 (en) Map and data location provider
CA2405482C (fr) Systeme et procede permettant de representer des concepts apparentes
US9110935B2 (en) Generate in-memory views from universe schema
US20070156653A1 (en) Automated knowledge management system
Mathiak et al. Challenges in matching dataset citation strings to datasets in social science
Ariyachandra et al. Key factors in selecting a Data Warehouse architecture
US20040117392A1 (en) Value mapping
Prakashbhai et al. Inference patterns from Big Data using aggregation, filtering and tagging-A survey
Naeem et al. An ontology based digital preservation system for enterprise collaboration
Diwisch et al. Managing cultural assets: Challenges for implementing typical cultural heritage archive’s usage scenarios
US11687506B1 (en) Similarity-based listing recommendations in a data exchange
US20030192038A1 (en) Linking data objects to a project development system
Gray The Leading Edge in is Management.
Safferstone The distributed mind: achieving high performance through the collective intelligence of knowledge work teams
US20060271382A1 (en) Entity projection
Herur Analysis of Database Management

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KN KP KR KZ LC LK LR LS LT LU LV LY MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 05852133

Country of ref document: EP

Kind code of ref document: A2