• There are important differences among these terms, in the fields of epistemology and semantics. For example, some terms designate what philosophers call “speech acts”, while others designate what philosophers call “propositional attitudes”.

• For other DBMSs, the value used should similarly be the latest date which can be represented by that DBMS.

• As a kind of shorthand, we say that the assertion time period of a row is the period of time during which we assert that it is true. And if we discover that a row is incorrect, and does not make a true statement, we do end its assertion time period.

• But some true statements are not actionable. For example, a currently effective row in a 100-column table may have 10 of its columns filled with accurate data, and the other 90 columns empty. So that row makes a true statement “as far as it goes”, but because it is so incomplete, it is probably not a statement that provides enough information to act on.

• And some actionable statements are not even true. Financial forecasts, for example, may be actionable. But because they are about the future, what they describe hasn't happened yet, and so they are statements which are neither true nor false. ¹

• These queries are usually written by business researchers and analysts, and are often run only a few times before they are discarded. Thus the cost of writing them is amortized over only a few occasions on which they are used, and so it is important to keep the query-writing costs as low as possible. This is why we recommend that, as far as possible, ad hoc queries should be written against views.

• Our Mechanics definitions of the Allen relationships will express time periods as date pairs, using the closed-open convention. The two time periods will be designated P₁ and P₂, and the begin and end dates, respectively, eff_beg_dt₁ and eff_end_dt₁, and eff_beg_dt₂ and eff_end_dt₂. By convention, P₁ is the earlier of the two time periods when one is earlier than the other, and is the shorter of the two time periods otherwise.

• These definitions assume that the begin date value for a time period is less than the end date value for that time period. This assumption excludes non-sensical time periods that end before they begin. It also excludes empty time periods.

• Our Semantics definitions of the Allen relationships will be stated in terms of clock ticks contained or not contained in time periods, and so these definitions are independent of the convention chosen for using pairs of dates to delimit time periods. In particular, “begin”, “end”, “earlier”, “later” and other terms refer to relationships in time, not to comparisons of begin and/or end dates to other begin and/or end dates.

• Boolean operators (AND, OR, NOT) are capitalized.

• The Allen relationships are mutually exclusive and jointly exhaustive.

• Good discussions of the Allen relationships can also be found in (Snodgrass, 2000), from Chapter 4 and (Date, Darwen and Lorentzos, 2002), from Chapter 6.

• The transaction by which deferred assertions are moved close enough to Now() that the business is willing to let them become current by means of the passage of time. See also: fall into currency.

• See also: as-was. The as-is vs. as-was distinction is often confused with the distinction between current and past versions. Many best practices implementations of versioning do not distinguish between the two, and therefore introduce ambiguities into their temporal semantics.

• In contrast, rows in bi-temporal tables of the standard temporal model cannot exist in future assertion time.

• Also, a table whose structure conforms to the schema presented in Chapter 6. See also: bi-temporal data canonical form.

• The Asserted Versioning Framework is software developed by the authors which implements Asserted Versioning.

• A row can never be inserted with an assertion begin date in the past, because an assertion cannot exist prior to the row whose truth it asserts. See also: temporalized extension of the Closed World Assumption.

• But a row can be inserted with an assertion begin date in the future because when that future date comes to pass, the row will already exist. See also: deferred assertion.

• An assertion end date is always set to 9999 when its row is inserted. It retains that value unless and until that assertion is withdrawn.

• This date is also the unique identifier of an assertion group.

• See also: as-is. The as-was vs. as-is distinction is an assertion time distinction, but in supporting temporal data management in their databases, IT professionals often confuse this distinction with the effective time distinction between past and current versions.

• See also: clock tick.

• Assertion end dates are the one temporal parameter that cannot be specified on temporal transactions. All temporal transactions, including basic ones, create asserted version rows with an assertion end date of 9999.

• Basic versioning is not part of Asserted Versioning. It is a form of best practices versioning. See Chapter 4.

• See also: logical delete versioning, temporal gap versioning, effective time versioning.

• Any history table, logfile, or version table can be transformed into an asserted version table without loss of content.

• The temporal scope of every temporal transaction is delimited by the bi-temporal envelope specified on the transaction.

• Every row in an asserted version table exists in a bi-temporal envelope.

• See also: epistemological time, ontological time.

• If a surrogate key is used in the logical data model, this surrogate key is used as the business key in an asserted version table.

• The various “parent” and “child” expressions also apply to conventional tables, of course, in which case the relationship involved is referential integrity, not temporal referential integrity. But in this Glossary, we are explicitly defining these expressions as they apply to asserted version tables.

• See the 1992 entry in the bibliography for the standard computer science glossary of bi-temporal concepts.

• Note that chronons are atomic clock ticks, not clock ticks.

• A 1-month-per-tick clock represents a situation in which a database is updated at most once a month. By the same token, a 1-week or 1-day clock would record updates that take place at most once a week or once daily, respectively.

• Using this convention, two time periods [meet] if and only if the begin date of the later one is one clock tick after the end date of the earlier one, at whatever level of granularity is used to designate the clock ticks.

• Using this convention, two time periods [meet] if and only if the begin date of the later one is the same clock tick as the end date of the earlier one, at whatever level of granularity is used to designate the clock ticks.

• More accurately, conventional data is data which lacks explicitly expressed assertion and effective time periods. For in fact, conventional data is asserted, and its assertion time period is co-extensive with its physical presence in the database. And conventional data is also versioned, and the effective time of the one version of an object thus represented is always from Now() until further notice.

• In the early part of the book, used as synonymous with “non-temporal database”. But starting in Chapter 15, a distinction is drawn in which a conventional database may contain temporal data about persistent objects, but not in the form of bi-temporal tables.

• Conventional transactions are SQL insert, update or delete statements.

• An object may have at most one current episode.

• A past episode is not a current episode because its effective time period is past.

• A no longer asserted episode is not a current episode because its assertion time period is past.

• An episode all of whose assertions are deferred is not a current episode because it is not yet asserted.

• An episode all of whose versions have an effective begin date in the future is not a current episode because it has no current version.

• See also: deferred transaction, proactive transaction, retroactive transaction.

• Rows in conventional tables are currently asserted current versions of the objects they represent.

• See also the Wikipedia definition.

• If a table needs to be de-dupped, it is because its business keys are not reliable. In a world of pure theory, rows with unreliable business keys would not be allowed into a table. But business requirements for such data, however unreliable, frequently outweigh theoretical considerations.

• See also: dirty data, row-level homonym, row-level synonym.

• Along with the truth-functional equivalence of (P IMPLIES Q) with (NOT-P OR Q), the deMorgan's equivalences allow any statement in propositional logic to be broken down into a series of ORs or a series of ANDs (including, in both cases, the NOT operand). In these simplified forms, computer software can carry out logic proofs, discovering contradictions when they exist, and presenting the logical implications of a set of assertions, many of which may turn out to be a surprise to those who accepted the original set of assertions.

• Software which does this is called an inference engine. While relational databases are the principal way that software helps us reason about instances, inference engines are the principal way that software helps us reason about types. Reasoning about types is what formal ontology is about. It is not often recognized that formal ontology and relational databases are complementary in this way, as means of reasoning about, respectively, types and instances.

• Recent consulting experience by the authors has demonstrated the very significant cost savings that result from the ability to exclude all temporal design considerations from the process of creating the logical data model for a database. Discussions of how to best implement project-specific temporal requirements are often difficult, lengthy, contentious and inconclusive—in short, costly. Those costs are incurred over and over again, for every data model in which even a single table must be given temporal capabilities. And almost every time, the result is a slightly different solution, whose maintenance and querying are never quite the same as for any other temporalized tables. Asserted Versioning's design encapsulation feature eliminates these costs, and guarantees a uniform implementation of temporal semantics across all tables in all databases in the enterprise. Moreover, firmly grounded in computer science research, Asserted Versioning guarantees that its single enterprise solution is a complete and correct implementation of bi-temporal semantics.

• Much of the temporal data in an enterprise is not directly queryable.

• Even if one table of temporal data is directly queryable, the needs of any specific query may require access to multiple temporal tables, and often that combination of tables is not directly queryable. For example, a query may need both last year's customer data from an enterprise data warehouse, and last month's customer data from an Operational Data Store (ODS) history table. But it is unlikely that the schemas in the two databases are identical, and therefore unlikely that the combination of those tables is directly queryable.

• With directly queryable data, nothing needs to be done to get the data ready to be queried, whether by native SQL or via query tools.

• Among IT professionals, the term “dirty data” often has a broader meaning, and covers a wide range of problems with data. In this narrower sense, dirty data is the result of unreliable business keys.

• See also: de-dupped, row-level homonym, row-level synonym.

• The effective begin date of an episode is the effective begin date of its earliest version.

• The effective end date of an episode is the effective end date of its latest version.

• We do not say “The temporal dimension which interprets a time period on a row as indicating when that row was the unique row validly representing that object” because that suggests that this temporal dimension is a property of rows. It is not. It is a property of objects represented by rows.

• But assertion time periods are properties of rows or, more precisely, of the existentially quantified statements made by those rows.

• Effective time versioning is not part of Asserted Versioning. See Chapter 4.

• See also: basic versioning, logical delete versioning, temporal gap versioning.

• Deferred assertions which are deleted before they become currently asserted are moved into empty assertion time, i.e. are given empty assertion time periods.

• This is one of the most important concepts in Asserted Versioning.

• Episodes are a series of versions of the same object that are contiguous in effective time within a period of shared assertion time. They represent what we believe, during that period of assertion time, the life history of that object was/is/will be like, across those contiguous periods of effective time. (From Chapter 5.)

• A neutral term referring to either the standard temporal model's transaction time or to Asserted Versioning's assertion time.

• See also: “assert” cognates.

• Events are the occasions on which changes happen to persistent objects. As events, they have two important features: (i) they occur at a point in time, or sometimes last for a limited period of time; and (ii) in either case, they do not change. An event happens, and then it's over. Once it's over, that's it; it is frozen in time. (From Chapter 2.)

• Note the “can be”. If “is” were in its place, the statements would express a correlation, but not a requirement.

• See also: implicitly temporal data.

• Tabular data which will become part of the production database are transactions acquired or generated by a company's OLTP systems. They are either immediately and directly applied to the production database, or are augmented, corrected or otherwise transformed as they are moved along an “inflow data pipeline” leading into the production database.

• Tabular data which has been a part of the production database are the persisted result sets of SQL queries or equivalent processes. They are either end state result sets, i.e. immediately delivered to internal business users or exported to outside users, or are augmented as they move along an “outflow data pipeline” leading to a final state in which they are delivered to internal business users or outside users.

• The various kinds of external pipeline datasets do not form a partitioning. Most of these names are in fairly widespread usage, but no standard definition of them exists. Therefore, in this Glossary, we will provide a description of them, but cannot provide a definition.

• The distinction between inflow pipeline datasets and outflow pipeline datasets is a matter of perspective. Any physical dataset may be used to update a production table, in which case it is an inflow dataset. And any physical dataset other than those created by means of manual data entry or automated data collection from instruments, for example, contains data from production tables and so are outflow datasets.

• Of course, the same physical dataset which was an extract may, with or without going through additional modifications, also be a feed.

• When applied to a production table, the contents of a data staging area may or may not overlay rows already in that table.

• The contents of a data staging area may have originated as a copy of rows in a production table, or simply be a collection of transactions each of which requires data from multiple sources, and so must be built up over time. If it originated as a copy of production rows, it is both an outflow pipeline dataset and, later on, an inflow pipeline dataset.

• The purpose of a staging area is to move the row or rows representing an object into a state where they are not available to normal queries. The reason for doing this is usually to withdraw those rows into an area where a series of updates can be made to them, only after which are those rows returned to production data status.

• Aside from the difference in media (video display vs. hardcopy), screens differ from reports in that reports usually contain data representing many objects, while screens usually contain data representing one object or a few objects.

• Once an assertion and/or a version falls into currency, it remains current until its end date becomes a date in the past.

• See also: near future assertion time.

• A typical far future assertion begin date would be hundreds or even thousands of years in the future. In business databases, there is little risk of such assertions falling into currency by the mere passage of time.

• The intent, with far future deferred assertions, is that they exist in a “temporal sandbox” within a production table. They can be used for forecasting, for “what if” analyses, or for building up or otherwise working on one or more assertions until those assertions are ready to become visible in the production table that physically contains them. When they are ready, an approval transaction will move them to near future assertion time, where the passage of time will quickly make them current assertions.

• “CTD” stands for “clock tick duration”. (From Chapter 14.)

• A temporal update or delete transaction will affect only clock ticks within the effective time period specified by the transaction.

• If the first clock tick in the transaction's effective time period is a non-initial clock tick in a version of the object referenced by the transaction, then that version must be split into a contiguous pair of otherwise identical versions.

• If the last clock tick in the transaction's effective time period is a non-final clock tick in a version of the object referenced by the transaction, then that version must be split into a contiguous pair of otherwise identical versions.

• The result is that the temporal transaction can be carried out by updating or deleting complete versions.

• See also: match.

• That current assertion time starts Now(), i.e. when the transaction is processed, and continues on until further notice. Every temporal transaction that accepts the default values for effective time, creates a version that describes what its object looks like from now on. Every non-deferred temporal transaction creates an assertion that, from now on, claims that its version makes a true statement. (From Chapter 9.)

• More generally, the granularity of a measurement is the size of the units in which the measurement is expressed, a smaller size referred to as a “finer” granularity. For example, inches are a finer granularity of linear measurement than yards, and ounces are a finer granularity of the measurement of weight than pounds.

• Note that this term does not refer to data which is itself, historical, i.e. to no longer currently asserted data, but rather to data which is about history, i.e. about the past states of persistent objects.

• For the term which does refer to data which is itself historical, See also as-was data.

• Note that, in the special sense used here, historical data is data about persistent objects. Thus, fact/dimension data marts do not provide historical data because their history is a history of events, not of objects, and also because they do not make assertion time distinctions.

• Thus, rows in conventional tables are implicitly temporal data. No columns of those tables indicate assertion or effective time periods. Each row is asserted for as long as it is present in its table, and is in effect for as long as it is present in its table.

• Rows which share no clock ticks in assertion time are semantically and truth-functionally isolated from one another. They are what philosophers call incommensurable. (From Chapter 6.)

• Incommensurability restricts TEI and TRI relationships to managed objects in shared assertion time.

• Inflow pipeline datasets are tabular data which will become part of the production database. They originate with transactions acquired or generated by a company's OLTP systems. They are either immediately and directly applied to the production database, or are augmented, corrected or otherwise transformed as they are moved along an “inflow data pipeline” leading into the production database.

• See also: type.

• The concepts of types and instances has long history. A related distinction is that between universals and particulars.

• See also: withdraw.

• A deferred transaction locks a row by setting its assertion end date to the assertion begin date of the deferred assertion it creates. Rows that are locked by means of deferred assertions remain currently asserted until their assertion end dates fall into the past.

• Logical delete versioning is not part of Asserted Versioning. See Chapter 4.

• See also: basic versioning, temporal gap versioning, effective time versioning.

• Maintenance encapsulation means that inserts, updates and deletes to bi-temporal tables, and queries against them, are simple enough that anyone who could write them against non-temporal tables could also write them against these tables. (From the Preface.)

• For example, tables, rows, columns, versions and episodes are all managed objects. Individual customers, clients or policies, while examples of objects, are not examples of managed objects.

• In the phrase “managed object”, the word “object”, by itself, has no meaning. In particular, it has no connection with the technical term “object”.

• Managed objects are data which transformations and constraints treat as a single unit. (From Chapter 5.)

• See also: far future assertion time.

• Deferred assertions located in the near future will become current assertions as soon as enough time has passed. In a real-time update situation, a near future deferred assertion might be one with an assertion begin date just a few seconds from now. In a batch update situation, a near future deferred assertion might be one that does not become currently asserted until midnight, or perhaps even for another several days. What near future deferred assertions have in common is that, in all cases, the business is willing to wait for these assertions to fall into currency, i.e. to become current not because of some explicit action, but rather when the passage of time reaches their assertion begin dates. (From Chapter 12.)

• SQL Server may use getdate(), and DB2 may use Current Timestamp or Current Date. (From Chapter 3.)

• Now() stands for a function, not a value. However, we will often use Now() to designate a specific point in time. For example, we may say that a time period starts at Now() and continues on until 9999. This is a shorthand way of emphasizing that, whenever that time period was created, it was given as its begin date the value returned by Now() at that moment. (From Chapter 3.)

• See also: events. Events, whether points in time or durations in time, are not objects, because events, by definition, do not change.

• Examples of objects include vendors, customers, employees, regulatory agencies, products, services, bills of material, invoices, purchase orders, claims, certifications, etc.

• The unique identifier of a row in an asserted version table is the concatenation of an object identifier, an effective begin date, and an assertion begin date.

• A neutral term referring to either the standard temporal model's valid time or to Asserted Versioning's effective time.

• The effective end date of an episode is the effective end date of its latest version.

• Using this convention, two time periods [meet] if and only if the begin date of the later one is the same clock tick as the end date of the earlier one, at whatever level of granularity is used to designate the clock ticks.

• Using this convention, two time periods [meet] if and only if the begin date of the later one is one clock tick before the end date of the earlier one, at whatever level of granularity is used to designate the clock ticks.

• Outflow pipeline datasets are tabular data which has been a part of the production database; they are the persisted result sets of SQL queries or equivalent processes. They are either end state result sets, i.e. immediately delivered to internal business users or exported to outside users, or are augmented as they move along an “outflow data pipeline” leading to a final state in which they are delivered to internal business users or outside users.

• The termination points of outflow pipelines may be either internal to the organization, or external to it; and we may think of the data that flows along these pipelines to be the result sets of queries applied to those production tables. (From Chapter 12.)

• An assertion is overridden only when an approval transaction retrograde moves a matching version to an earlier assertion period than the assertion period of the assertion being overridden.

• Creating future versions and/or deferred assertions is a way of managing a large volume of transactions so that the result of those transactions will all become current on exactly the same clock tick. An example would be a corporate acquisition in which the entire set of customers, policies, accounts and other objects managed by the acquired company need to become part of the acquiring company's production databases—and thus available to the maintenance processes, queries and reporting processes of the acquiring company—all at the same time, on precisely the same clock tick.

• Pending transactions are collected in batch transaction files. See also external pipeline dataset, batch transaction file.

• As internalized by Asserted Versioning, they are those semantic collections of asserted version rows called Pending History, Pending Updates and Pending Projections.

• Several DBMS vendors, including Oracle and Teradata, have defined PERIOD datatypes, but we do not know whether or not their definitions are equivalent.

• We would regard any PERIOD datatype as inadequate unless it could express a time period with an unknown starting point or an unknown ending point. We would regard DBMS support for any PERIOD datatype as inadequate unless a unique index could be defined on any column with a PERIOD datatype that would treat any two time periods as duplicates if they shared even a single clock tick.

• See also semantic logfile.

• Deferred assertions which have been retrograde moved from far future to near future assertion time are the one exception to this ability to recreate any past physical state of an asserted version table. Currently, Asserted Versioning does not preserve information about the far future assertion time these assertions originally existed in. (From Chapter 16.)

• The AVF translates each temporal transaction into the one or more physical transactions that, when processed, carry out the intentions expressed by the user who submitted the temporal transaction.

• Pipeline production datasets (pipeline datasets, for short) are points at which data comes to rest along the inflow pipelines whose termination points are production tables, or along the outflow pipelines whose points of origin are those same tables. (From Chapter 12.)

• For purposes of temporal data management, a point in time is considered indivisible.

• Note that in this book, in which we use a month as our level of temporal granularity, that one month is considered indivisible. For example, if a transaction is applied, it is assumed that its results will remain unchanged until the next month.

• Posted transactions are collected in logfiles. See also external pipeline dataset, logfile table.

• As internalized by Asserted Versioning, they are those semantic collections of asserted version rows called Posted History, Posted Updates and Posted Projections.

• See also: retroactive transaction.

• Production databases are the collections of production datasets which the business recognizes as the official repositories of that data. Production databases consist of production tables. (From Chapter 12.)

• See also: ad hoc query. (From Chapter 5.)

• The term “production” indicates that these tables are in use by business processes, and contain “real” data. Regularly scheduled processes are being carried out to maintain these tables, and to keep their contents as accurate, secure and current as possible. Regularly scheduled processes, as well as non-scheduled ones, are being carried out to access this data to obtain needed information. So production tables are the tables that the business tries to keep accurate, current and secure, and from which it draws the information it needs to carry out its mission and meet its objectives. (From Chapter 3.)

• Production tables are production datasets whose data is designated as always reliable and always available for use. (From Chapter 12.)

• Query encapsulation means that queries against asserted version tables are simple enough that anyone who could write them against non-temporal tables could also write them against these tables. (From the Preface.)

• See also: withdraw, supercede.

• A row X replaces a row Y if and only if X says the same thing about what the object Y represents is like, during the effective time period specified by Y.

• If a superceding version was also created as part of the temporal update transaction which created a replacement version, then this replacement version will [meet] that superceding version in effective time, while having an [equal] assertion time.

• A temporal update transaction whose effective time period [intersects] that of a target version, but does not [equal] it, requires the AVF to withdraw the target version and then to split that target version into one version that matches the transaction, and one (or two) versions that do not. This is done with the fCUT function. The resulting version or versions that do not match the transaction are replacements, with identical business data. The one version that does match the transaction is updated with the new business data, and supercedes the corresponding effective timespan of the withdrawn version.

• See also: occupy.

• In a conventional table, the only mistake in data that can be corrected is a mistake in data values, and the correction is done “destructively”, by overwriting the old data.

• But in an asserted version table, there are two other mistakes in data. One is to mistakenly claim that an object was represented during a past effective time period. The other is to mistakenly claim that an object was not represented during a past effective time period. A retroactive delete transaction is the means by which the former mistake is corrected. A retroactive insert transaction is the means by which the latter mistake is corrected.

• See also: retroactive delete.

• See also: proactive transaction.

• The means by which a physical logfile can be re-presented as a queryable object.

• A row-level homonym is eliminated by replacing it with multiple rows, one for each object represented by the row. For example, a row in a Client table which has been updated with data representing two or more different clients, is a homonym.

• See also: de-dupped, dirty data, row-level synonym.

• Row-level synonyms are eliminated by replacing them with one row that represents the one object that each of the synonym's references. For example, multiple rows in a Client table which are discovered to represent the same client, are synonyms.

• See also: de-dupped, dirty data, row-level homonym.

• Queries which return temporal data, or a mix of temporal and current data, must return equivalent-sized results in an equivalent amount of elapsed time. Chapter 15 discusses the performance issues involved in using asserted version tables.

• Differences in maintenance performance will be greater than differences in query performance because one logical unit of work—the insertion, update or deletion of business data about one object—will affect only one row in a conventional table, but one update or deletion to an asserted version table will usually physically insert several rows.

• Increasingly, temporal data must be available on-line, just as current data is. Transactions to maintain temporal data must be as easy to write as are transactions to maintain current data. Queries to retrieve temporal data, or a combination of temporal and current data, must be as easy to write as are queries to retrieve current data only. (From Chapter 1.)

• See also: physical logfile.

• The contents of a physical logfile of a particular table, as of point in time X, are all those rows physically present in the table as of that point in time. The contents of a semantic logfile of that table, as of that point in time, are all those rows asserted on or prior to that point in time. The difference is the set of all assertions which are deferred assertions as of that point in time.

• In Asserted Versioning, a row in past assertion time is a record of a statement we once made, and a row in future assertion time is a record of a statement that we may make at some point in the future. Neither are statements because neither have truth values.

• See also: withdraw, replace.

• A row X supercedes a row Y if and only if X says something new about what the object Y represents is like, during all or part of the effective time period specified by Y.

• If either one or two replacement versions were also created as part of the temporal update transaction which created this superceding version, then this superceding version will [meet] the earlier replacement version, and [meet⁻¹] the later replacement version in effective time.

• Besides DBMS tables, files and their records are tabular data, as are the rows and columns in spreadsheets.

• There can be more than one target episode for a temporal update or delete. A temporal insert can insert only one episode.

• There can be more than one target row for a temporal update or delete. A temporal insert can insert only one row.

• Temporal transactions have one and only one target table, even though temporal delete transactions can modify multiple tables.

• We leave KIND-OF as formally undefined, i.e. as part of our controlled vocabulary of primitive terms. When X is a KIND-OF Y, it follows that every instance of X is also an instance of Y, and that this is so because of what “X” and “Y” mean.

• See also: explicitly temporal data, implicitly temporal data.

• An event, once completed, cannot change. If data describing an event needs to be altered, it is because the data is incorrect, not because the event changed.

• As an object changes from one state to the next, we store the before-image of the current state, and update a copy of that state, not the original. The update becomes the new current state of the object.

• When managing time using state data, what we record are not transactions, but rather the results of transactions, the rows resulting from inserts and (logical) deletes, and the rows representing both a before- and an after-image of every update. (From Chapter 2.)

• Thus, for example, data warehouses and data marts are not part of this taxonomy because they are methods of managing temporal data at the database level.

• The temporal model described by C. J. Date, Hugh Darwen and Nikos Lorentzos in their book Temporal Data and the Relational Model. (Morgan-Kaufmann, 2002).

• The temporal model described in this book.

• Distinguished from the alternative temporal model in particular (i) in all the ways it is distinguished from the standard temporal model, and also (ii) by its recognition and treatment of assertion tables and bi-temporal tables and (iii) its decision to not manage temporal data at the column level.

• Distinguished from the standard temporal model in particular by providing design and maintenance encapsulation, managing data located in future assertion time, its reliance on episodes as managed objects, and its internalization of adjunct datasets.

• The temporal model described by Dr. Rick Snodgrass in his book Developing Time-Oriented Database Applications in SQL (Morgan-Kaufmann, 2000).

• Thus versioning, in any of its forms, is a method of managing uni-temporal data.

• Those values are Now() for the assertion and effective begin dates, and 9999 for the assertion and effective end dates.

• a temporal delete cascade will attempt to remove both the parent managed object, and all its dependent children, from the clock ticks specified in the transaction. (From Chapter 11.)

• A temporal delete is like a temporal update except that it specifies that every version or part of a version of the designated managed object that falls, wholly or partially, within that target span will be, in current assertion time, removed from that target effective timespan. (From Chapter 9.)

• A temporal delete withdraws its target object from one or more effective time clock ticks. In the process, it may {withdraw} an entire version from current assertion time, or {split} a version in two, or {shorten} a version either forwards or backwards, or do several of these things to one or more versions with one and the same transaction.

• One of the two constraints by means of which Asserted Versioning expresses the semantics of bi-temporal data.

• In the definitions of the temporal extent state transformations, the phrase “in a given period of assertion time” will be present implicitly.

• At the schema level, a temporal foreign key points from one table to a table it is dependent on. But at the row level, it points from one row, which is a version, to a group of one or more rows which make up an episode of the object whose oid matches the oid value in that temporal foreign key.

• At the instance level, temporal referential integrity guarantees that, for every temporal foreign key, there is an episode of the designated object in the referenced table, and that the effective time period of that episode in the referenced table includes ([fills⁻¹]) the effective time period of the version which contains the referring temporal foreign key. (From Chapter 6.)

• Temporal foreign keys, like conventional foreign keys, are the managed object construct which represents the existence dependency of a child object on a parent object.

• Temporal gap versioning is not part of Asserted Versioning. See Chapter 4.

• See also: basic versioning, logical delete versioning, effective time versioning.

• A temporal insert adds a representation of its specified object to a series of one or more contiguous effective time clock ticks. In the process, it may {create} an entire single-episode version, or {merge} two adjacent episodes, or {lengthen} an episode either forwards or backwards.

• A temporal referential integrity relationship between a child managed object and a parent managed object is based on an existence dependency between the objects which those managed objects represent. (From Chapter 11.)

• Note that a temporal update will change the business data for an object in occupied clock ticks, and will ignore unoccupied clock ticks. Thus the clock ticks that a temporal update affects are not necessarily contiguous clock ticks. And consequently, to be valid, it is not necessary that all clock ticks in the effective-time range of a temporal update be occupied by the specified object. It is only necessary that at least one of them be occupied.

• Note, by contrast, that a temporal transaction can insert data into past effective time, update data in past effective time, and delete data from past effective time.

• In Chapter 12, we explained the reason that we can modify the statement content of past effective time but not of past assertion time. We said: “.…. a belief is expressed by the presence of a row in a table. No row, no belief. So if we write a transaction today that creates a row stating that we believed something yesterday, we are creating a row that states that we believed something at a time when there was no row to represent that belief …… (But) it would be a logical contradiction to state that we had such a belief at a point or period in time during which there was no row to represent that belief.”

• If two rows in an asserted version table are adjacent, then either one is [before] the other, or one [meets] the other. This is because they would otherwise violate the temporal entity integrity constraint, which the AVF prevents.

• If one row in an asserted version table is adjacent to and [before] the other, then they belong to different episodes.

• If one row in an asserted version is adjacent to and [meets] the other, then they belong to the same episode.

• A temporal transaction is temporally delimited to its effective time period within its assertion time period.

• Note that these time periods can, and often do, remain current until further notice, i.e. that they can, and often do, end in 9999.

• The termination of an episode {withdraws} that episode from some but not all of the effective-time clock ticks which it occupies.

• The termination of an episode should be thought of as the by-product of a temporal delete transaction, not as that transaction's semantic objective. The semantic objective of a temporal delete transaction is to remove the representation of an object from all clock ticks within the effective timespan specified on the transaction. If that effective timespan on the delete transaction includes the entire episode, then we say that the episode has been deleted, not that it has been terminated.

• See also: object, event.

• If the end date of a time period is not known, 9999 is used as the end date. Because of its interpretation as a valid date by the DBMS, the effective semantics is “until further notice”.

• A timeslice of an object represented in an asserted version table does not have to align on episode or version boundaries. It is just a continuous period of time in the life history of an object (or in the projection of that life history into the future).

• The first sense designates a row of data that represents an event. For example, a customer purchase is an event, represented by a row in a sales table; the receipt of a shipment is an event, represented by a row in a receipts table. In this sense, transactions are what are collected in the fact tables of fact-dimension data marts.

• The second sense designates any insert, update or delete applied to a database. For example, it is an insert transaction that creates a new customer record, an update transaction that changes a customer's name, and a delete transaction that removes a customer from the database. (From Chapter 2.)

• (In any formalization of this Glossary, of course, this homonym would have to be resolved. In this book, we rely on context to do so.)

• Another one of the several homonyms of “transaction”.

• Transaction tables record the events that change the states of objects and, in particular, the relationships among them. (From Chapter 1.)

• Transaction tables are often used as the fact tables in fact-dimension data marts.

• There can be only one version of an event, since events do not persist and change over time. Multiple rows for the same event can only be multiple assertions about that event, presumably a series of corrections to the data.

• As defined by Jensen, the computer science term “transaction time” may be treated as co-extensive with our term “row creation date”. But the two terms cannot be said to be synonymous because they are defined by means of two vocabularies between which semantic correlations have not been established. Also, while Jensen's definition, given here, indicates that transaction time is a point in time, Snodgrass's use of the term, in [Snodgrass, 2000] has it referring to a period of time, usually open-ended, but not necessarily so. In this second sense, the term is co-extensive with a proper subset of our term “assertion time period”.

• In this entry, “transaction” refers to “temporal transaction”, not to any of the other homonyms of “transaction”.

• This standard has not been adopted by the SQL standards committee.

• See also: instance.

• In a database, tables represent types of things, and rows represent instances of those types.

• We say “explicitly expressed” to emphasize that all data is bi-temporal. In a conventional table, in which no assertion and/or effective time period columns are included, each row is nonetheless bi-temporal. Each row is a current assertion about what the object it represents is currently like. As a claim that its object exists, each row's assertion and effective time periods are co-extensive with the row's physical presence in its table.

• Uni-temporal version tables are common in business databases; Chapter 4 describes their major variants. But see update in place for a common misuse of this kind of table.

• Uni-temporal assertion tables are single-table logfiles. They are usually described as the history table companions to conventional tables. However, history tables are often designed with a primary key which is the same as the primary key of the table whose changes they track, but with the addition of a low-order date (or timestamp) to that primary key. In general, history tables like this are not semantically complete uni-temporal assertion tables, being unable, for example, to distinguish entries which represent a delete from those which represent an update.

• The distinction between reliable and unreliable business keys can be seen at work in the description of the match logic for Asserted Versioning's temporal transactions, in Chapter 9.

• In general, this term means “unknown but presumed valid”. In a SQL Server asserted version table, a row is asserted until further notice if and only if its assertion end date is 12/31/9999, and is in effect until further notice if and only if its effective end date is 12/31/9999.

• Mechanically, a time period with a begin date in the past, and that is presumed to be current until further notice, will be interpreted by the DBMS in that way because in any query, Now() will always be greater than that begin date and less than that end date.

• Neither 12/31/9999, nor any other DBMS representation of 9999, is valid as an assertion begin date or effective begin date.

• If 12/31/9999 (or any other DBMS representation of 9999) is used in a business data column, of course, it has whatever semantics the business chooses to give to it.

• In a conventional table, all updates are updates in place, and therefore all updates destroy historical information. An update which reflects a change in the object represented by a row of data has the effect of replacing a current version with a new current version, thus destroying effective-time history. An update which reflects a correction to a mistake made in the data has the effect of replacing a current assertion with a new current assertion, thus destroying assertion-time history.

• And so, in a uni-temporal table, either one or the other of those two types of updates must be done as an update in place, thus destroying one or the other of those two kinds of history, or else the two kinds of updates are not distinguished and both result in the creation of a new row of data. But this second way of managing uni-temporal tables makes it impossible to distinguish true versions, i.e. rows which are part of the effective-time history of an object, from corrections to bad data. All too frequently, in business databases, this second way of managing uni-temporal tables is called versioning, and the rows in those tables are called versions. Interpreted in this way, these tables are themselves mistaken data, and provide incorrect information to their business consumers.

• “The valid time of a fact is the time when the fact is true in the modeled reality. A fact may have associated any number of events and intervals, with single events and intervals being important special cases.” From [Jensen, 1992].

• Every row in an asserted version table is either a past, present or future version representing an object.

• This expression does not apply to a row in an asserted version table. A row in an asserted version table is a version, and the begin date associated with that row, as a version, is its effective begin date. The version begin date of a row in any other kind of version table might represent either the physical date on which the row was created, or a logical date on which the version becomes effective.

• This expression does not apply to a row in an asserted version table. A row in an asserted version table is a version, and the end date associated with that row, as a version, is its effective end date. The version end date of a row in any other kind of version table might represent either the physical date on which a delete transaction was applied to the row, or a logical date on which the version ceased to be in effect.

• When a version is split, the earlier half becomes a new version which is located [before] the latter half. Because the two versions are not contiguous, the result of splitting a version is always to split an episode. See also: temporal extent state transformation {split}.

• Although a version split always results in an episode split, an episode may be split without splitting any of its versions.

• To be semantically valid, a uni-temporal version table must correct errors in data by overwriting those errors. Frequently, businesses have uni-temporal tables which they think are version tables, but in which every update results in a new row in the table. But this means that the begin, or begin and end dates, of those rows are not true version dates. They are just dates of physical database activity. If the update reflects a change in the object being represented, then the version date or dates have the semantics of effective dates. But if the update reflects a correction to bad data, then the version date or dates have the semantics of assertion dates. By mixing both kinds of updates, the semantics are destroyed, and we don't know what any row in the table is really telling us.

• An asserted version table is one kind of version table. IT best practices have given rise to many other kinds of version tables, which we grouped into four main types in Chapter 4. What the standard temporal model calls a valid-time table is another kind of version table.

• What kind of period of time is involved depends on the kind of version table. In many best practice implementations of versioned tables, unfortunately, effective time and assertion time are not distinguished. An update that reflects a change to the object represented in the table results in a new version, but an update that reflects a correction to erroneous data also results in a new version. And in both cases, the version begin date is simply the date the new row was physically created. Nearly all best practice support for versioned data is semantically incomplete. But when effective time changes are not clearly distinguished from error correction changes, those implementations are semantically flawed, and the data thus supported is semantically ambiguous.

• See also: replace, supercede.

• See also: lock.

• Non-deferred update and delete transactions set the end date of versions they will then replace and/or supercede to Now() which, upon the conclusion of the temporal transaction, immediately becomes a past date. This is a “clearing the decks” transformation which removes the representation of the object affected by the transaction from current assertion time.

• A temporal transaction cannot set a row's assertion end date to a past date because, if it did, it would create a contradiction. During the time period from that past date to the time the transaction took place, the database asserted that row. But after Now(), the record of that assertion is erased from the database. Just as we cannot retroactively begin an assertion, we cannot retroactively end one, either. This is another manifestation of the temporalized extension of the Closed World Assumption.

• If a temporal transaction sets a row's assertion end date to a future date, it locks that row, making it a closed version. Only deferred transactions can set a row's assertion end date to a future date.

• Thus, no temporal transaction can set a row's assertion end date to a past date. Deferred transactions set that date to a future date. Non-deferred transactions set that date to Now(), and then as soon as the transaction is complete, that row is in past assertion time.