WO2014016589A2 - Bases de données relationnelles bitemporelles et leurs procédés de fabrication et d'utilisation - Google Patents

Bases de données relationnelles bitemporelles et leurs procédés de fabrication et d'utilisation Download PDF

Info

Publication number
WO2014016589A2
WO2014016589A2 PCT/GB2013/051971 GB2013051971W WO2014016589A2 WO 2014016589 A2 WO2014016589 A2 WO 2014016589A2 GB 2013051971 W GB2013051971 W GB 2013051971W WO 2014016589 A2 WO2014016589 A2 WO 2014016589A2
Authority
WO
WIPO (PCT)
Prior art keywords
time
valid
database
tables
data
Prior art date
Application number
PCT/GB2013/051971
Other languages
English (en)
Other versions
WO2014016589A3 (fr
Inventor
Luke Leonard Martin Porter
Original Assignee
Luke Leonard Martin Porter
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
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=49118568&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=WO2014016589(A2) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Priority claimed from GBGB1213273.4A external-priority patent/GB201213273D0/en
Priority claimed from US13/614,609 external-priority patent/US8812512B2/en
Application filed by Luke Leonard Martin Porter filed Critical Luke Leonard Martin Porter
Publication of WO2014016589A2 publication Critical patent/WO2014016589A2/fr
Publication of WO2014016589A3 publication Critical patent/WO2014016589A3/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/24—Querying
    • G06F16/245—Query processing
    • G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
    • G06F16/2477—Temporal data queries
    • 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

Definitions

  • the present invention generally relates to bi-temporal relational databases, how to make them, and how to use them.
  • Bi-temporal databases are known (ones with valid time and transaction time).
  • OrableTM databases When a relational database for example an OrableTM database is designed, great care is taken in the writing of the software that controls the data and sets up the data structure to allow for all queries that will be made.
  • a kernel is created to control allowable changes to data entries, within relationship rules linking the data entries. The relationship rules all need to be specified in advance.
  • databases often have roll-back software and memories that are used to recreate the "then" content of the databases so that queries of the database can return answers to queires that are the same as that which the query would have returned at a specified date in the past (the current view data having been corrected to correct the error).
  • the invention comprises a temporal relational database and associated data structure and database management software system comprising:
  • business data and associated time data held in computer memory and associated time data held in computer memory; and database management software held in computer memory and runable on the processor to interact with the business data;
  • the data structure comprising having the business data and associated time data held in three tables, a first S$ table, a second T$ table and a third E$ table, where: the S$ table (summary table) contains all versions of the all rows of business data, the rows having at least dimensions of transaction time, valid time , and business primary key;
  • the E$ table (event table) holds the valid start of existence and valid end of existence of all rows in the S$ table, avoiding storing end dates of rows in the S$ table, and the rows of the E$ table being dimensional by at least transaction time and business primary key;
  • the T$ table holds the primary key and unique keys of all rows in the $ table dimensioned by business primary key
  • the management software may also enable pseudo tables to be generated and displayed or communicated to a user, the pseudo tables having values for foreign keys of primary key-identified entities, and having generated by the management software one, two, three, four or five of:-
  • (v) end of valid (EOV) column that is the valid time that the next version of that row in the S$ table acquired its values; and wherein the EOV is not stored in the same row of the $ table as the primary key to which it relates, but is derived from the SOV of the next (in transaction time) row version from that primary key.
  • the invention comprises a method of reducing the time taken to manufacture a bitemporal relational database comprising manufacturing a system according to the preceding first aspect of the invention claim 1 and designing business database tables with relational rules stored in a relational kernel or referential rule dictionary, and designing those tables so as to be without start date and end date columns for start of valid time and end of valid time for entities, and designing the system to be without history tables recording the history of relationships between entities in the database; the system being designed as a current view with primary key and unique key constraints, and time-related issues being taken care of by the S$, T$, and E$ tables automatically generated as the data structure of the system is populated with data.
  • a method of receiving an answer to a query in a system comprising specifying in a query the transaction time and valid time to be used, and the processor using the valid time and prosecution time to generate from the S$, T$ and E$ tables a response to the query, and displaying the query on a screen, printing it out, or transmitting it to a remote site.
  • the Temporal Relational Extension (TRE) invention is a method for storing data to comprehensively provide temporal support in a computer database.
  • the TRE method stores data based on semantic rules implemented via a set of constraints.
  • TRE comprises a logical data model, algorithms and temporal constraints used when populating a database.
  • Figure 1 shows a typical use of timestamp columns to add valid time and transaction time to rows in a database
  • Figure 2 shows a typical way of depicting an entity relationship between entities
  • Figure 3 shows three tables used by a database embodying the present invention, S$, E$ and T$ tables;
  • Figure 4 shows three available views of data in the database of Figure 3, achievable using the tables of Figure 3;
  • Figure 5 depicts example considerations when designing a database relating to trading currencies
  • Figure 6 shows a typical client report used by banks for trade reconciliation
  • Figure 7 shows the results of performance testing an embodiment of the present invention
  • Figure 8 shows an example SQL script for producing a report using an embodiment of the present invention
  • Figures 9 to 12 illustrates the old, known, timestamp approach used in the prior art to create or make a bi-temporal relational database
  • Figures 13 to 19 illustrate my new TRE approach to time in a bi-temporal database and to make the database
  • Figures 20 to 25 show an embodiment implementation of the approach and represent data structure of an embodiment of the new database.
  • TRE uses the mathematical technique of factoring. As time is ubiquitous and applies to all data (ie all data held in a database has at least the two time dimensions of transaction time and valid time), it can be factored away and dealt with separately. This has the added benefit of simplifying the design and implementation of the database data model for any business or user requirement.
  • time Once time is separated from the business data it can be efficiently managed and stored by the infrastructure and presented back to the computer application as pseudo columns.
  • time When time is managed in this way the application developer only needs to consider the business data. Additional history/audit tables are not required since all versions of rows (both past and future) are inherently provided by infrastructure. Data is accessed by setting the time context at statement level through SQL syntax. It is understood that bi-temporal support is "all or nothing". The choice is to either model time, or to restrict to the "current view” taken by existing relational theory. Tables which have temporal support cannot be related to tables without. A similar design philosophy has also been adopted by Oracle Workspace Manager.
  • TRE achieves the ideal by which a database analyst does not have to model any transaction time or valid time timestamps. These timestamps exist (in the same layout) on every entity but TRE delivers the capability where these timestamps are not changed directly and consequently do not appear as physical columns. They are therefore accessed as pseudo-columns (as with ROWNUM, LEVEL, SYSDATE et al). This is not to say that relations are not ever presented to the user or application with timestamps or periods, but that the underlying storage separates them and the only way to alter their values is through SQL instructions.
  • every row has additional start date and/or end date columns of data type 'date' or 'period' . These columns define or imply an effective duration for the row. Unfortunately, once timestamps are added in this way the possibility of overlaps and gaps between these durations occur.
  • One of the main principles of the TRE storage approach is that storing duration on a single row should be avoided since it creates the possibility of overlaps and gaps in the data. Overlaps and gaps do not make logical sense and so it follows that they should not be stored by the database. For example, a system that reports an employee as having both a salary of 20k and a salary of 30k at a specific valid time is clearly wrong. This breaks the principle that a database should provide a single version of the truth at a point in time. Similarly, a system that allows gaps in existence of a person makes no common sense since people do not exist, disappear and then reincarnate. Likewise, if an employee leaves an organisation and then returns, it is a different period of employment i.e.
  • FIG. 1 shows a typical use of timestamp columns to add valid time and transaction time to rows in a database.
  • Database table 110 uses notations as defined in 120 When tables use time stamps as in Figure 100 Data Manipulation Language (DML) operations and SELECTS become very complicated. If a FROM timestamp is stored on the same row then the possibility of gaps and overlaps needs to be catered for and 'date effective' joins are needed. Developing Time-Oriented Applications in SQL written by Richard T Snodgrass gives a good description of the problems caused using this approach. On page 117 of ref [3] he argues that a problem arises in assigning a primary key to a table which has "from valid time” timestamps and "to valid time” timestamps.
  • DML Data Manipulation Language
  • the TRE approach separates time from the business data, manages and stores it according to its rules and then presents it back to the application/user.
  • the effort of dealing with time is taken by the infrastructure and not by the application layer.
  • At a stroke TRE provides simplicity and improved functionality at the application layer.
  • TAB1 with columns A and B and a valid time duration VT: TAB1 (A, B, VT) with rows: Al Bl [tl , t8]
  • TRE maintains the unique integrity of the primary key and importantly elevates/separates the role of the primary key from the role of the unique key. In non temporal storage modelling there is little differentiation between the use of primary keys and unique keys. In TRE the use and application of primary keys and unique keys are very specific.
  • the primary key is specifically used as a constraint that enforces that no two occurrences of an entity can hold the same value at any valid time and that each primary key value identifies an entity occurrence for its entire valid time life history (past and future) and cannot be reused i.e. gaps and overlaps are not allowed.
  • a valid time history or valid time period can be any period of time covering any part of the past, present or future.
  • TRE the unique key is specifically used as a constraint that enforces that two entity occurrences cannot hold the same value at the same valid time i.e. overlaps are not allowed but there can be a period of valid times when no entity occurrence has that value and that value can be reused by any entity occurrence.
  • the event approach of TRE implicitly ensures that an entity occurrence cannot store two values of any attribute at the same valid time. Note also that an entity occurrence can hold the same value of an attribute at different valid times as long as that value it is not used in another entity occurrence at that valid time.
  • Oracle already has constraint mechanisms for managing primary keys and unique keys which are perfectly adequate for the needs of TRE. This means that the existing SQL syntax for primary and unique keys does not need to be changed or enhanced.
  • the timestamp columns are managed entirely by the database, it follows that they should not appear as physical columns. It is preferable that they are accessed as pseudo-columns (as with the system ROWNUM, LEVEL, SYSDATE). This means that when the database analyst is designing his model he does not include start dates and end dates in table designs. Additionally, because the database inherently knows the transaction and valid time history, there is no need to include History tables in the business data model. In fact, all that the data modeller needs to do is define the business data model as a current view with standard primary key and unique key constraints. In Figure 2 210 shows a normal way of depicting an entity relationship between two tables (Table 1 and Table2) where the meaning of the notation is defined in 220.
  • the role of the foreign key is unchanged and is used to relate rows in one table with a row in a separate table e.g. employees with a department. It follows that TRE can interpret any foreign constraints defined by the data modeller and use them accordingly. However, according to the semantics of TRE there are additional requirements, over and above the simple existence of a related row. When dealing with valid time it is a requirement to ensure that the start of existence and end of existence of related rows are also constrained appropriately. For example we cannot allow an employee to be placed in a department when that department does not exist at that valid time. To ensure that related rows have this kind of temporal referential integrity the database needs an additional set of referential constraint rules.
  • the elevated role of the primary key is critical when dealing with referential integrity. In a non temporal world the foreign can be joined to any unique column (primary key or unique key) in the related entity. In TRE, the foreign key must be joined to a primary key since that is what identities an entity occurrence for its entire valid life history.
  • Unique keys are not sufficient for referential integrity because their role is only to guarantee uniqueness i.e. that at a particular point in valid time only one entity occurrence has that value. With unique keys there can be periods of valid time where a value is not used in any row and furthermore that value can be reused by any entity occurrence.
  • Additional foreign constraint rules are defined to keep referential integrity intact with respect to the Start of Existence (SOE) and End of Existence (EOE) of related rows when certain events occur.
  • the "Alter Insert Forward” event where the SOE is changed to a later valid time.
  • the "Alter Insert Back” event where the SOE is changed to an earlier valid time.
  • the "Delete” event where the End of Existence of an entity occurrence is set.
  • the "Alter Delete Forward” event where the EOE is changed to a later valid time.
  • Oracle implements two referential constraint rules i.e. Restrict (the default) and Cascade which can be attached to a DELETE event. Theoretically there are two more constraint rules i.e. Nullifies and Defaults, but these are not implemented in the Oracle code base.
  • each table in the business data model is implemented in the TRE storage layer as three underlying tables using standard database facilities e.g. standard constraints and indexes as provided within the Oracle database system.
  • 310 shows the relationships between the three tables in the TRE storage layer representing a single table in a business data model.
  • S$ SSTABLENAME
  • S$ Summary
  • E$TABLENAME(E$) is called the Event (E$) table. It holds the valid start of existence (insert) and valid end of existence (delete) of all rows and avoids the problem of storing the end dates of row versions in the Summary table. It is acceptable to hold the end of existence in this table because, by definition, there is no row to overlap/or create a gap with after deletion.
  • the TRE semantics of a Primary Key also guarantee that no subsequent rows occur in valid time with the same primary key value.
  • the rows are identified / dimensioned by Transaction Time and Business Primary Key.
  • T$TABLE (T$) is called the T$ table. It holds the Primary key and Unique Key(s) of all the rows and is used as the locking mechanism to ensure the Primary Keys and Unique Key semantics are observed.
  • the rows are dimensioned by Business Primary Key only and the table has standard Primary and Unique key constraints applied to it.
  • the Presentation Lay The role of a "normal" table in the "3 table” TRE implementation is taken by the TABLENAME view which 'hides' the three underlying tables from the eyes of the developer. Since the underlying TRE storage layer implicitly supports both valid and transaction time it gives us the opportunity to provide two very useful additional views of the data namely TABLENAME Y and TABLENAME X.
  • the _Y naming convention means a view with a fixed Y (or transaction) time can be provided i.e. it gives the valid time history (a horizontal slice) where valid time is conceptually seen from left to right.
  • the X naming convention means a view with a fixed X (or valid time) time can be provided i.e. it gives the transaction time history (a vertical slice) where transaction time is conceptually seen going from top to bottom.
  • Figure 4 shows the three available 'views'.
  • the TRE "TABLENAME” view provides the "Normal” or “current view” table equivalent. It is used for Data Manipulation Language (DML) operations and SELECT (query) operations. It provides values for a set of rows for a given valid time and transaction time.
  • this view uses instead-of triggers to deal with INSERT, UPDATE and DELETE events. The instead-of triggers use the constraint rules to populate the underlying tables according to the semantic rules of TRE.
  • the TRE "TABLENAME Y" view provides the Valid Time History view and is used for SELECT operations and to navigate through the valid life history of the rows. It provides a valid time history (time series) of values for a set of rows for a given transaction time.
  • the TRE "TABLENAME X" view provides Transaction Time History View and is used for SELECT and to navigate through the transaction life history of the rows. It provides a transaction time history (time series) of values for a set of rows for a given valid time. In addition to displaying the business data, in one implementation these views also display the following pseudo columns back to the user:-
  • the Pseudo Column “YTS” provides the Transaction Time which is the time that the row was committed to the database. This is also known as the Y-Timestamp.
  • the Pseudo Column “SOE” provides the Start of Existence which is the valid time of the insert event.
  • the Pseudo Column “EOE” provides the End of Existence which is the valid time of the delete event (if one exists).
  • the Pseudo Column “SOV” provides the Start of Valid which is the valid time that a version of the row acquired its values and is the same as SOE for the first version of the row. This is also known as the X-timestamp.
  • the Pseudo Column “EOV” provides the End of Valid which is the valid time that the next version of the row acquired its values (if one exists). Unlike other pseudo columns, the EOV value is not stored on the same row. It is derived from the SOV of the next row version.
  • Dates are never directly updated by the user. Instead they are provided at statement level using SQL syntax. Dates are managed and stored by the infrastructure but are available as pseudo columns (not shown in Figure 5 schema diagram). Client Report
  • Figure 6 shows a printout of a typical client report used by banks for trade reconciliation.
  • the SQL output provided by one implementation of TRE is shown below. Notice that the SQL query uses standard relational joins and that the same SOL query is run at different transaction and valid times in order to provide the reconciliation between different versions of the report. This is a good example of how time is supplied at the statement level. Stepping through Valid Time
  • T.PSN_ID P. ID
  • T.PSN_ID P. ID
  • T.PSN_ID P. ID
  • T.PSN_ID P. ID
  • T.PSN_ID P. ID
  • T.PSN_ID P. ID
  • T.PSN_ID P. ID
  • Figure 8 shows an example of SQL script for producing a report using the present invention methodology.
  • the user sets the transaction time (for example 6 June 2005, 9:30 AM) that they wish to pretend is the time at which the query was made - that is s time that they wish to have as the point in time for the query.
  • the system has a default which sets to current view (now) if no transaction time is entered to be a different time at which the system asks the query.( The internal computer clock obviously sets the system time/transaction time when transactions are entered into the system.)
  • the selection of the transaction time determines which of the summary positions for the entity is referred to when making the query.
  • Figures 9 to 12 illustrate a timestamp approach.
  • Figure 1 refers to first normal form through to fifth normal form.
  • Figure 10 illustrates FROM and capital TO columns for valid time.
  • Figure 1 1 illustrates FROM and capital TO columns for transaction time - stored in the table.
  • Figure 12 illustrates that the timestamp approach is to store and index the FROM and TO columns in various ways.
  • Figures 13 to 19 illustrate the new approach to handling time in bi- temporal databases.
  • the transaction time (or computer clock system time) continues to run on the computer.
  • entries When entries are entered into the computer they have a particular transaction time associated with them - the time they were really entered into the computer system.
  • Figure 13 shows this.
  • Figure 14 illustrates the concept of giving an entity an allowable existence in the valid time - a second time dimension.
  • Each entity has a start of existence time.
  • the end of existence time can either be entered directly, or calculated from some other entry (for example the start of existence of a different value or entity).
  • Figure 15 shows the S $ table for an entity, being a summary table containing all versions of all rows of the business data of the entity, the rows having at least the dimensions of transaction time, valid time, and business primary key.
  • Figure 16 illustrates another feature of determining the start of existence and end of existence time, in valid time for an entity.
  • the valid time (X time) start of existence and end of existence could be determined by reading data in the existing rows, or entered in the s$ table directly.
  • Figure 17 indicates that a delete event is actually an insert event, where a new summary position row is created which represents the "deletion" by providing a value in the valid time for end of existence.
  • Figure 18 illustrates an E $ table, being an event table, that holds the valid start of existence and valid end of existence of all rows in the S$r table. This avoids the need to store end dates of rows in the S $, and the rows of the E $ table are dimensioned by at least transaction time and business primary key. It will be noted that the business primary key is present in both the S $ table and E $ table. This allows the two tables to be linked/referenced together.
  • Figure 19 shows a T $ table, which holds the primary key and unique keys all roles in the S $ table, and is dimensioned by business primary key.
  • the business primary key is present in all three of the S $, E $, and T $ tables, and is used to ensure that the correct tables are used when retrieving data from a query, and is used to ensure that the correct point in transaction time is selected, and the correct summary position is used to respond to a query of the database.
  • Figure 20 illustrates an implementation of the invention in which the E $ and S $ table are clustered.
  • Figure 21 shows further detail of an embodiment implementation, in which a query enters both a given valid time, and given transaction time and the two dimensions of time set "cross-hairs", to retrieve data representative of the position at both a given transaction time, and valid time.
  • the result retrieved for values of parameters associated with a data entry can be different for different transaction times - because the entries actually in the computer records/memory could be different at different points in transaction time.
  • Figure 22 shows a representation of a report view (the report could be displayed on a screen, printed out, sent electronically to another device (over the internet or a local network ) , stored in memory , etc.).
  • the report view chosen shows the entity life history/valid time history at a given transaction time.
  • the previous report view of figure 21 showed data at it given valid time and transaction time.
  • the report of figure 22 shows the history over valid time at a given transaction time.
  • Figure 23 shows another report/view that can be produced using the system, and that is to show the transaction life history of one or more attributes of an entity in the database at a given valid time.
  • Figure 24 illustrates another view, this time a view where the query that generates the report specifies a particular X time (valid time), and Y time (transaction time), and also provides temporal information (for example end of existence, start a value, etc).
  • Figure 25 shows another summary view where a user has input/a query has input a given X time and Y time, and the summary view is selected using both temporal inputs.
  • this implementation of TRE accommodated a real business requirement with the overall development taking only a few days due to the complexity being handled by the development strength of the invention.
  • TRE Temporal Relational Extension
  • the TRE methodology provides development and

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Fuzzy Systems (AREA)
  • Mathematical Physics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Software Systems (AREA)
  • Computational Linguistics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention porte sur un procédé de réduction du temps nécessaire pour fabriquer une base de données relationnelle bitemporelle. Le procédé consiste à concevoir des tables de base de données métier avec des règles relationnelles stockées dans un noyau relationnel ou dictionnaire de règles référentielles, et à concevoir ces tables pour qu'elles soient dépourvues de colonnes de date de début et de date de fin pour un début de durée valide et une fin de durée valide pour des entités, et à concevoir le système pour qu'il soit dépourvu de tables d'historique enregistrant l'historique de relations entre entités dans la base de données ; le système étant conçu sous la forme d'une vue courante avec des contraintes de clé primaire et de clé unique, et des questions relatives au temps étant gérées par les tables S$, T$ et E$ automatiquement générées à mesure que la structure de données du système est peuplée par des données.
PCT/GB2013/051971 2012-07-26 2013-07-24 Bases de données relationnelles bitemporelles et leurs procédés de fabrication et d'utilisation WO2014016589A2 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
GB1213273.4 2012-07-26
GBGB1213273.4A GB201213273D0 (en) 2012-07-26 2012-07-26 Bitemporal relational databases and methods of manufacturing them, and of using them
US13/614,609 US8812512B2 (en) 2003-01-15 2012-09-13 Bitemporal relational databases and methods of manufacturing and use
US13/614,609 2012-09-13

Publications (2)

Publication Number Publication Date
WO2014016589A2 true WO2014016589A2 (fr) 2014-01-30
WO2014016589A3 WO2014016589A3 (fr) 2014-08-21

Family

ID=49118568

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2013/051971 WO2014016589A2 (fr) 2012-07-26 2013-07-24 Bases de données relationnelles bitemporelles et leurs procédés de fabrication et d'utilisation

Country Status (2)

Country Link
GB (1) GB2505313A (fr)
WO (1) WO2014016589A2 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004063943A2 (fr) * 2003-01-15 2004-07-29 Luke Leonard Martin Porter Gestion du temps dans des bases de donnees et applications de bases de donnees

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004063943A2 (fr) * 2003-01-15 2004-07-29 Luke Leonard Martin Porter Gestion du temps dans des bases de donnees et applications de bases de donnees

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
EDELWEISS N ET AL: "A temporal database management system implemented on top of a conventional database", COMPUTER SCIENCE SOCIETY, 2000. PROCEEDINGS. XX INTERNATIONAL CONFEREN CE OF THE CHILEAN 16-18 NOVEMBER 2000, PISCATAWAY, NJ, USA,IEEE, 16 November 2000 (2000-11-16), pages 58-67, XP010527610, ISBN: 978-0-7695-0810-8 *

Also Published As

Publication number Publication date
WO2014016589A3 (fr) 2014-08-21
GB201313192D0 (en) 2013-09-04
GB2505313A (en) 2014-02-26

Similar Documents

Publication Publication Date Title
Sadalage et al. NoSQL distilled: a brief guide to the emerging world of polyglot persistence
US9384222B2 (en) Database system that provides for history-enabled tables
US6189004B1 (en) Method and apparatus for creating a datamart and for creating a query structure for the datamart
US7730412B2 (en) System and method for model-based user interface using transformation nodes
Agrawal et al. Asynchronous view maintenance for VLSD databases
US6766325B1 (en) System and method for maintaining data for performing “what if” analysis
US20160292227A1 (en) Processing database queries using format conversion
US7617198B2 (en) Generation of XML search profiles
US7739224B1 (en) Method and system for creating a well-formed database using semantic definitions
US7774318B2 (en) Method and system for fast deletion of database information
US20120136839A1 (en) User-Driven Conflict Resolution Of Concurrent Updates In Snapshot Isolation
US20140108331A1 (en) OLAP Execution Model Using Relational Operations
EP2784700A2 (fr) Intégration de capacités analytiques et transactionnelles d'un système de gestion de base de données
US7627554B2 (en) Uniform financial reporting system interface utilizing staging tables having a standardized structure
EP2869220B1 (fr) Système de base de données en réseau
EP1607883A1 (fr) Système et procédé de traitement de données pour surveiller les réplications de base de données
Eisenberg et al. SQL standardization: the next steps
US11544266B1 (en) Methods and systems for efficiently and rapidly generating highly customized cloud-based enterprise software applications
US10503752B2 (en) Delta replication
US20070094233A1 (en) Translating time-independent data using database operations
US10838947B2 (en) Consistency check for foreign key definition
US8812512B2 (en) Bitemporal relational databases and methods of manufacturing and use
WO2014016589A2 (fr) Bases de données relationnelles bitemporelles et leurs procédés de fabrication et d'utilisation
WO2010029366A1 (fr) Stockage de données et couche de fusion
CN115221254A (zh) 多数据源处理方法、装置、设备及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13759268

Country of ref document: EP

Kind code of ref document: A2

122 Ep: pct application non-entry in european phase

Ref document number: 13759268

Country of ref document: EP

Kind code of ref document: A2