16. Conclusion
Seamless Access to Temporal Data381
The Internalization of Pipeline Datasets388
Performance390
Enterprise Contextualization390
Ongoing Research and Development393
Going Forward396
Glossary References396
In the Preface, we listed four objectives for this book. Those objectives were to explain how to support:
(i) Seamless access to temporal data;
(ii) The encapsulation of temporal data structures and processes;
(iii) The internalization of pipeline datasets; and
(iv) The enterprise contextualization of this functionality.
Let's see whether we have achieved these objectives.
Seamless Access to Temporal Data
We've known all along that, with enough hard work, we can almost always pull together any data that the business asks for—past or present versions of objects of interest, current data about those versions or past data about them. And we now know how to extend the range of what we can pull together to include future data as well, in either or both of our two temporal dimensions—although we emphasize, again, that it is only the Asserted Versioning temporal model that recognizes future assertion time.
But the hard work has to be paid for. And sometimes the results are flawed. Sometimes we don't pull together all the data relevant to a business request, because we overlook some sources we should have known about. Sometimes we don't pull together the best or most current copy of relevant data because we don't know how to tell the best from the rest. And often, by the time the hard work is over and the data is assembled, that data has lost some business value, or perhaps has become completely irrelevant, simply because too much time has gone by.
When data requests are for our best data about what things are currently like, we are usually able to respond rapidly. Usually, the data is already available, ready to be queried from within application programs, or by means of tools available to business analysts or researchers. This is the data we have been calling conventional data. In the terminology we have developed, conventional data consists of currently asserted current versions of the persistent objects we are interested in.
But past, present or future assertions about past, present or future versions give us nine temporal categories of data, and conventional data is only one of those nine. As requests for data in one or more of those other eight categories become more frequent, it becomes more important to reduce the work involved in satisfying those requests. As it becomes increasingly important to provide that data as quickly as possible, scavenger hunts for scattered data are less and less acceptable as a standard procedure.
This increasing importance of past and future data points to an obvious end-state. First, all nine bi-temporal categories of data should be as quickly and easily available as conventional data already is. Secondly, seamless access across data from multiple categories should be just as easy, and just as quick.
Asserted version tables are that end-state. Asserted version tables can contain any number of rows representing the same object, and those tables can include rows from any or all of those nine bi-temporal categories. This means that when data about one or more objects, in any of those categories, is requested, all of that data is immediately available and ready to be queried. There is no assembly and/or transformation work to be done to get that data ready for querying. There is no delay between the business request for data, and its availability in queryable form.
The majority of queries against bi-temporal data are point-in-time queries. A point in assertion time, and a point in effective time, are specified. As for assertion time, when Now() is specified, the result is an as-is query, a query returning our best and current data about what an object used to be like, is like, or may eventually be like. When a past point in time is specified, the result is an as-was query, a query returning data about the past, present or future which was asserted at some past point in time. As for queries specifying future assertion time, they are queries about internalized batch transaction datasets, about what our data is going to look like if and when we apply those transactions.
Queries which specify an assertion point in time, but either no effective time or else an effective range of time, are queries which return versioned data. So clearly, queries can return result sets all of whose rows reside in one of the nine bi-temporal categories or result sets whose rows are drawn from several of those bi-temporal categories. In this way, seamless access across those categories is provided. By containing all this data in production tables, there is no delay between a request for that data and when a query can be written against it.
We conclude that Asserted Versioning does provide real-time seamless access to the full range of bi-temporal data.
Encapsulation of Temporal Data Structures and Processes
Asserted version tables are complex. There are two time periods, and each is expressed as a pair of dates. Surrogate keys are required. Temporal foreign keys are no kind of foreign key that a DBMS can recognize. If these bi-temporal components of data schemas must be designed and expressed in logical data models, the work required of those data modelers will be more complex than work on equivalent non-temporal models. Asserted Versioning shields data modelers from this temporal design work by means of its support for design encapsulation.
The semantic constraints that make bi-temporal data meaningful are complex. They involve extensive checks for temporal gaps, temporal contiguity and temporal overlaps. Temporal relationships between referential parent and child data are especially complex. The code that is required to make temporal foreign keys carry out a temporalized version of the same work that conventional foreign keys do is not simple code. Asserted Versioning shields developers and DBAs from this programming work by means of its support for maintenance encapsulation. This also shields those who write maintenance transactions from the complexities involved in writing what is often a lengthy series of SQL insert and update statements, all to carry out what, to the business, is a single action for example, “Extend the start date on policy P861 back to the beginning of the year”.
Query encapsulation is provided for both ad hoc queries and production queries. Ad hoc queries, usually written by business analysts and researchers who are not IT technical specialists, may benefit from a rich set of views which hides much of the temporal selection and join criteria that might otherwise be difficult for those authors to write. Production queries, written by developers and DBAs, will generally not make use of views. But because Asserted Versioning insures that all data being queried already satisfies temporal entity integrity and temporal referential integrity constraints, it eliminates the need to filter out violations of those constraints from query result sets. In this way, Asserted Versioning eliminates much of the complexity that would otherwise have to be written into queries that directly access asserted version tables. In this way, Asserted Versioning provides as simple a target as possible for both ad hoc queries and production queries and, in doing so, provides the query encapsulation that assists both kinds of query authors.
Design Encapsulation
Data modeling is usually on a project's critical path. That's because it is difficult to write code when you don't know what the database is going to look like! Database schemas come first; code comes after that.
The first thing the data modeler must do, with respect to temporal data, is to get the temporal requirements right. This can often be difficult because while IT and technically conversant business people usually have developed a business/IT pidgin that enables them to communicate clearly, there is no such pidgin for temporal requirements. But with Asserted Versioning, and its extensive Glossary, the material for such a pidgin does exist.
For example, technically conversant business people often understand IT people when they say things like “No, you don't really want a referential integrity relationship between salespersons and clients, because you want to be able to add a client before you assign a salesperson to him and, for that matter, be able to add a salesperson before you assign her a client”. The modeler may be right or wrong; but both she and the business lead on the project understand what she's saying.
Now think of trying to explain temporal referential integrity with the language only of overlaps and gaps, and begin and end dates, all involving a set of rows in a pair of tables. Both the business analyst and the DBA will have to use the language of physical data and relationships among physical data to express semantic constraints, to express what are often called business rules. Those would be difficult conversations, and misunderstandings would inevitably result because of the mismatch between semantic requirements and the ability to talk about them in only physical terms.
But Asserted Versioning provides the concept of temporal referential integrity, and such related concepts as temporal foreign keys and episode to version temporal extent relationships. And TRI really is RI extended across two temporal dimensions, not a new concept which has no connection to concepts the business and technical members of the project team are already familiar with. And so, using the Asserted Versioning concepts of objects, episodes, versions, assertions, TEI and TRI, the modeler and the business lead can communicate at a level of abstraction appropriate to the content of the conversation. The terminology introduced by Asserted Versioning, and defined in its Glossary, is the basis for an extension of the business/IT pidgin to cover temporal data.
Once temporal requirements are clarified, Asserted Versioning provides a set of metadata tables (or ERwin UDPs) to capture those requirements. Expressing those requirements as metadata is straightforward, as we saw in Chapter 8. But expressing them in the logical data model, i.e. the one the modeler writes, is often complex, as the chapter on the subject in Dr. Snodgrass's book shows us. 1
1See Chapter 11 in that book, the chapter entitled Temporal Database Design. In that chapter, Dr. Snodgrass takes 56 pages to describe how to express temporal data requirements in a logical data model.
We believe that if it were necessary to express temporal requirements in data models, that requirement might add 25% or more to the total modeling effort on a typical project, and might extend the timeline for completing the model by at least that much. But by expressing temporal requirements separately from the logical data model, we both reduce the total amount of work to do in this phase of the project and also shorten the timeline along the critical path because clarifying temporal requirements, and building or extending the non-temporal logical data model, is work that can be done in parallel. This also means that existing logical data models can continue to function, without modification, as the data models for databases some or all of whose conventional tables have been and may continue to be converted to asserted version tables.
We conclude that Asserted Versioning does provide design encapsulation for bi-temporal data, and also temporal upward compatibility for logical data models and conventional databases.
Maintenance Encapsulation
Maintenance encapsulation protects both the user of the database, and the developers who have to write the code that maintains it.
This book contains several scenarios which show a temporal transaction—one written by a person—being applied to an Asserted Versioning database. The early scenarios, such as those in Chapter 7, are relatively simple. One temporal insert transaction is usually translated into one physical SQL transaction. But a temporal delete transaction, even one which does not cascade, may require three or more physical transactions to carry it out. Temporal update transactions will require a combination of physical update and physical insert transactions. Temporal retroactive transactions may require several dozen physical transactions to complete.
Asserted Versioning's maintenance encapsulation relieves the user of the burden of writing these SQL maintenance transactions. Because of this encapsulation, the user can instead, using the Instead Of functionality of the AVF, write a single insert, update or delete statement. The AVF will carry out the intentions expressed in those transactions, no matter how many physical transactions are required to do it.
Maintenance encapsulation also protects developers. The translation of the user's temporal transaction is done by the AVF, not by developer-written code. The management of the one or more physical transactions which implement each temporal transaction as an atomic and isolated unit of work is done by the AVF, not by developer-written code. All bi-temporal management processes are managed by code within the AVF; there is no bi-temporal management code for application developers to write.
We also note that temporal insert, update and delete transactions, by default and without any overrides to those defaults, insert, update and delete currently asserted data describing what the referenced object is currently like. This provides temporal upward compatibility for applications which manage conventional tables.
We conclude that Asserted Versioning does provide maintenance encapsulation for bi-temporal data, and also temporal upward compatibility for maintenance transactions to conventional data.
Query Encapsulation
As we have already pointed out, production queries against Asserted Versioning databases do not have to check for TEI or TRI violations. The maintenance processes carried out by the AVF guarantee that asserted version tables will already conform to those semantic requirements. For example, when joining from a TRI child to a TRI parent, these queries do not have to check that the parent object is represented by an effective-time set of contiguous and non-overlapping rows whose end-to-end time period fully includes that of the child row. Asserted Versioning already guarantees that those parent version rows [meet] within an episode, and that they [fill-1] the effective time period of the child row.
Ad hoc queries against Asserted Versioning databases can be written directly against asserted version tables. But as far as possible, they should be written against views in order to simplify the query-writing task of predominately non-technical query authors. So we recommend that a basic set of views be provided for each asserted version table. Additional subject-matter-specific views written against these basic views could also be created. Some basic views that we believe might prove useful for these query authors are:
(i) The Conventional Data View, consisting of all currently asserted current versions in the table. This is a one-row-per-object view.
(ii) The Current Versions View, consisting of all currently asserted versions in the table, past, present and future. This is a view that will satisfy all the requirements satisfied by any best practice versioning tables, as described in Chapter 4.
(iii) The Episode View, consisting of one current assertion for each episode. That is the current version for current episodes, the last version for past episodes, and the latest version for future episodes. This view is useful because it filters out the “blow-by-blow” history which version tables provide, and leaves only a “latest row” to represent each episode of an object of interest.
(iv) The Semantic Logfile View, consisting of all no longer asserted versions in the table. This view collects all asserted version data that we no longer claim is true, and should be of particular interest to auditors.
(v) The Transaction File View, consisting of all near future asserted versions. These are deferred assertions that will become currently asserted data soon enough that the business is willing to let them become current by means of the passage of time.
(vi) The Staging Area View, consisting of all far future asserted versions. These are deferred assertions that are still a work in progress. They might be incomplete data that the business fully intends to assert once they are completed. They might also be hypothetical data, created to try out various what-if scenarios.
We also note that existing queries against conventional tables will execute properly when their target tables are converted to asserted version tables. In the conversion, the tables are given new names. For example, we use the suffix “_AV” on asserted version tables and only on those tables. One of the views provided on each table, then, is one which selects exactly those columns that made up the original table, and all and only those rows that dynamically remain currently asserted and currently in effect. This dynamic view provides, as a queryable object, a set of data that is row for row and column for column identical to the original table. The view itself is given the name the original table had. Every column has the same name it originally had. This provides temporal upward compatibility for all queries, whether embedded in application code or free-standing.
We conclude that Asserted Versioning does provide query encapsulation for bi-temporal data, and also temporal upward compatibility for queries.
The Internalization of Pipeline Datasets
Non-current data is often found in numerous nooks and crannies of conventional databases. Surrounding conventional tables whose rows have no time periods explicitly attached to them, and which represent our current beliefs about what their objects are currently like, there may be various history tables, transaction tables, staging area tables and developer-maintained logfile tables. In some cases, temporality has even infiltrated some of those tables themselves, transforming them into one or another of some variation on the four types of version tables which we described in Chapter 4.
When we began writing, we knew that deferred transactions and deferred assertions went beyond the standard bi-temporal semantics recognized in the computer science community. We knew that they corresponded to insert, update or delete transactions written but not yet submitted to the DBMS. The most familiar collections of transactions in this state, we recognized, are those called batch transaction datasets.
But as soon as we identified the nine logical categories of bi-temporal data, we realized that deferred transactions and deferred assertions dealt with only three of those nine categories—with future assertions about past, present or future versions. What, then, we wondered, did the three categories of past assertions correspond to?
The answer is that past assertions play the role of a DBMS semantic logfile, one specific to a particular production table. Of course, by now we understand that past assertions do not make it possible to fully recreate the physical state of a table as of any point in past time because of deferred assertions which are not, by definition, past assertions. Instead, they make it possible to recreate what we claimed, at some past point in time, was the truth about the past, present and future of the things we were interested in at the time. In this way, past assertions support a semantic logfile, and allow us to recreate what we once claimed was true, as of any point of time in the past. They provide the as-was semantics for bi-temporal data.
But Asserted Versioning also supports a table-specific physical logfile. It does so with the row create date. With this date, we can almost recreate everything that was physically in a table as of any past point in time, no matter where in assertion time or effective time any of those rows are located. 2
2The exception is deferred assertions that have been moved backwards in assertion time. Currently, Asserted Versioning does not preserve information about the far future assertion time these assertions originally existed in.
This leaves us with only three of the nine categories—the current assertion of past, present and future versions of objects. The current assertions of current versions, of course, are the conventional data in an asserted version table. This leaves currently asserted past versions and currently asserted future versions. But these are nothing new to IT professionals. They are what IT best practice version tables have been trying to manage for several decades.
Now it all comes together. Instead of conventional physical logfiles, Asserted Versioning supports queries which make both semantic logfile data and physical logfile data available. Instead of batch transaction datasets, Asserted Versioning keeps track of what the database will look like when those transactions are applied—which, for asserted version tables, means when those future assertions pass into currency. Instead of variations on best practice version tables which support some part of the semantics of versioning, Asserted Versioning is an enterprise solution which implements versioning, in every case, with the same schemas and with support for the full semantics of versioning, whether or not the specific business requirements, at the time, specify those full semantics.
With all these various physical datasets internalized within the production tables they are directed to or derived from, Asserted Versioning eliminates the cost of managing them as distinct physical data objects.
Asserted Versioning also eliminates the cost of coordinating maintenance to them. There is no latency as updates to production tables ripple out to downstream copies of that same data, such as separate history tables. On the inward-bound side, there is also no latency. As soon as a transaction is written, it becomes part of its target table. The semantics supported here is, for maintenance transactions, “submit it and forget it”.
We conclude that Asserted Versioning does support the semantics of the internalization of pipeline datasets.
Performance
We have provided techniques on how to index, partition, cluster and query an Asserted Versioning database. We've recommended key structures for primary keys, foreign keys and search keys, and recommended the placement of temporal columns in indexes for optimal performance. We have also shown how to improve performance with the use of currency flags. All these techniques help to provide query performance in Asserted Versioning databases which is nearly equivalent to the query performance in equivalent conventional databases.
We conclude that queries against even very large Asserted Versioning databases, especially those queries retrieving currently asserted current versions of persistent objects, will perform as well or nearly as well as the corresponding queries against a conventional database.
Enterprise Contextualization
As temporal data has become increasingly important, much of it has migrated from being reconstructable temporal data to being queryable temporal data. But much of that queryable temporal data is still isolated in data warehouses or other historical databases, although some of it also exists in production databases as history tables, or as version tables. Often, this queryable temporal data fails to distinguish between data which reflects changes in the real world, and data which corrects mistakes in earlier data.
So business needs for a collection of temporal data against which queries can be written are often difficult to meet. Some of the needed data may be in a data warehouse; the rest of it may be contained in various history tables and version tables in the production database, and the odds of those history tables all using the same schemas and all being updated according to the same rules are not good. As for version tables, we have seen how many different kinds there are, and how difficult it can be to write queries that extract exactly the desired data from them.
We need an enterprise solution to the provision of queryable bi-temporal data. We need one consistent set of schemas, across all tables and all databases. We need one set of transactions that update bi-temporal data, and enforce the same temporal integrity constraints, across all tables and all databases. We need a standard way to ask for uni-temporal or bi-temporal data. And we need a way to remove all temporal logic from application programs, isolate it in a separate layer of code, and invoke it declaratively.
Asserted Versioning is that enterprise solution.
Asserted Versioning as a Bridge and as a Destination
Asserted Versioning, either in the form of the AVF or of a home-grown implementation of its concepts, has value as both a bridge and as a destination. As a bridge to a standards-based, vendor-supported implementation of bi-temporal data management, Asserted Versioning is a way to begin migrating databases and applications right away, using the DBMSs available today and the SQL available today. As a destination, Asserted Versioning is an implementation of a more complete semantics for bi-temporality than has yet been defined in the academic literature.
Asserted Versioning as a Bridge
Applications which manage temporal data intermingle code expressing subject-matter-specific business rules with code for managing these different forms in which temporal data is stored. Queries which access temporal data in these databases cannot be written correctly without a deep knowledge of the specific schemas used to store the data, and of both the scope and limits of the semantics of that data. Assembling data from two or more temporal tables, whether in the same or in different physical databases, is likely to require complicated logic to mediate the discrepancies between different implementations of the same semantics.
As a bridge to the new SQL standards and to DBMS support for them, Asserted Versioning standardizes temporal semantics by removing history tables, various forms of version tables, transaction datasets, staging areas and logfile data from databases. In their place, Asserted Versioning provides a standard canonical form for bi-temporal data, that form being the Asserted Versioning schema used by all asserted version tables.
By implementing Asserted Versioning, businesses can begin to remove temporal logic from their applications, and at each point where often complex temporal logic is hardcoded inside an application program, they can begin to replace that code with a simple temporal insert, update or delete statement.
Sometimes this will be difficult work. Some implementations of versioning, for example, are more convoluted than others. The code that supports those implementations will be correspondingly difficult to identify, isolate and replace. But if a business is going to avail itself of standards-based temporal SQL and commercial support for those temporal extensions—as it surely will, sooner or later—then this work will have to be done, sooner or later. With an Asserted Versioning Framework available to the business, that work can begin sooner rather than later. It can begin right now.
Asserted Versioning as a Destination
Even if the primary motivation for using the AVF—ours or a home-grown version—is as a bridge to standards-based and vendor implemented bi-temporal functionality, that is certainly not its only value. For as soon as the AVF is installed, hundreds of person hours will typically be saved on every new project to introduce temporal data into a database. Based on our own consulting experience, which jointly spans about half a century and several dozen client engagements, we can confidently say, without exaggeration, that many large projects involving temporal data will save thousands of person hours.
Here's how. Temporal data modeling work that would otherwise have to be done, will be eliminated. Project-specific designs for history tables or version tables, likely differing in some way from the many other designs that already exist in the databases across the enterprise, will no longer proliferate. Separate code to maintain these idiosyncratically different structures will no longer have to be written. Temporal entity integrity rules and temporal referential integrity rules will no longer be overlooked, or only partially or incorrectly implemented.
Special instructions to those who will write the often complex sets of SQL transactions required to carry out what is a single insert, update or delete action from a business user perspective will no longer have to be provided and remembered each time a transaction is written. Special instructions to those who will write queries against these tables, possibly joining them with slightly different temporal tables designed and written by some other project team, will no longer have to be provided and remembered each time a query is written.
When the first set of tables is converted to asserted version tables, seamless real-time access to bi-temporal data will be immediately available for that data. This is declaratively specified access, with the procedural complexities encapsulated within the AVF. In addition, the benefits of the internalization of pipeline datasets will also be made immediately available, this being one of the principal areas in which Asserted Versioning extends bi-temporal semantics beyond the semantics of the standard model.
We conclude that Asserted Versioning has value both as a bridge and as a destination. It is a bridge to a standards-based SQL that includes support for PERIOD datatypes, Allen relationships and the declarative specification of bi-temporal semantics. It is a destination in the sense that it is a currently available solution which provides the benefits of declaratively specified, seamless real-time access to bi-temporal data, including the extended semantics of objects, episodes and internalized pipeline datasets.
Ongoing Research and Development
Bi-temporal data is an ongoing research and development topic within the computer science and DBMS vendor communities. Most of that research will affect IT professionals only as products delivered to us, specifically in the form of enhancements to the SQL language and to relational DBMSs.
But bi-temporal data and its management by means of Asserted Versioning's conceptual and software frameworks is an ongoing research and development topic for us as well. Some of this ongoing work will appear as future releases of the Asserted Versioning AVF. Some of it will be published on our website, AssertedVersioning.com, and some of it will be made available as seminars. Following is a partial list of topics that we are working on as this book goes to press.
(i) An Asserted Versioning Ontology. A research topic. We have begun to formalize Asserted Versioning as an ontology by translating our Glossary into a FOPL axiomatic system. The undefined predicates of the system are being collected into a controlled vocabulary. Multiple taxonomies will be identified as KIND-OF threads running through the ontology. Theorems will be formally proved, demonstrating how automated inferencing can extract useful information from a collection of statements that are not organized as a database of tables, rows and columns.
(ii) Asserted Versioning and the Relational Model. A research topic. Bi-temporal extensions to the SQL language have been blocked for over 15 years, in large part because of objections that those extensions violate Codd's relational model and, in particular, his Information Principle. We will discuss those objections, especially as they apply to Asserted Versioning, and respond to them.
(iii) Deferred Transaction Workflow Management and the AVF. A development topic. When deferred assertion groups are moved backwards in assertion time, and when isolation cannot be maintained across the entire unit of work, violations of bi-temporal semantics may be exposed to the database user. We are developing a solution that identifies semantic components within and across deferred assertion groups, and moves those components backwards in a sequence that preserves temporal semantic integrity at each step of the process.
(iv) Asserted Versioning and Real-Time Data Warehousing. A methodology topic. Asserted Versioning supports bi-temporal tables in OLTP source system databases and/or Operational Data Stores. It is a better solution to the management of near-term historical data than is real-time data warehousing, for several reasons. First, much near-term historical data remains operationally relevant, and must be as accessible to OLTP systems as current data is. Thus, it must either be maintained in ad hoc structures within OLTP systems, or retrieved from the data warehouse with poorly-performing federated queries. Second, data warehouses, and indeed any collection of uni-temporal data, do not support the important as-was vs. as-is distinction. Third, real-time feeds to data warehouses change the warehousing paradigm. Data warehouses originally kept historical data about persistent objects as a time-series of periodic snapshots. Real-time updating of warehouses forces versioning into warehouses, and the mixture of snapshots and versions is conceptually confused and confusing. Asserted Versioning makes real-time data warehousing neither necessary nor desirable.
(v) Temporalized Unique Indexes. A development topic. Values which are unique to one row in a conventional table may appear on any number of rows when the table is converted to an asserted version table. So unique indexes on conventional tables are no longer unique after the conversion. To make those indexes unique, both an assertion and an effective time period must be added to them. This reflects the fact that although those values are no longer unique across all rows in the converted table, they remain unique across all rows in the table at any one point in time, specifically at any one combination of assertion and effective time clock ticks.
(vi) Instead Of Triggers. A development topic. Instead Of triggers function as updatable views. These updatable views make Asserted Versioning's temporal transactions look like conventional SQL. When invoked, the triggered code recognizes insert, update and delete statements as temporal transactions. As described in this book, it will translate them into multiple physical transactions, apply TEI and TRI checks, and manage the processing of those physical transactions as atomic and isolated units of work. The utilization of Instead Of triggers by the AVF is ongoing work, as we go to press.
(vii) Java and Hibernate. A research and development topic. Hibernate is an object/relational persistence and query service framework for Java. It hides the complexities of SQL, and functions as a data access layer supporting object-oriented semantics (not to be confused with the semantics of objects, as Asserted Versioning uses that term). Hibernate and other frameworks can be used to invoke the AVF logic to enforce TEI and TRI while maintaining an Asserted Versioning bi-temporal database.
(viii) Archiving. A methodology topic. An important archiving issue is how to archive integral semantic units, i.e. how to archive without leaving “dangling references” to archived data in the source database. Assertions, versions, episodes and objects define integral semantic units, and we are developing an archiving strategy, and AVF support for it, based on those Asserted Versioning concepts.
(ix) Star Schema Temporal Data. A methodology topic. Bi-temporal dimensions can make the “cube explosion problem” unmanageable, and bi-temporal semantics do not apply to fact tables the same way they apply to dimension tables. We are developing a methodology for supporting both versioning, and the as-was vs. as-is distinction, in both fact and dimension tables.
Going Forward
We thank our readers who have stuck with us through an extended discussion of some very complex ideas. For those who would like to learn more about bi-temporal data, and about Asserted Versioning, we recommend that you visit our website, AssertedVersioning.com, and our webpage at Elsevier.com.
At our website, we have also created a small sample database of asserted version tables. Registered users can write both maintenance transactions and queries against that database. Because these tables contain data from all nine temporal categories, we recommend that interested readers first print out the contents of these tables before querying them. It is by comparing the full contents of those tables to query result sets that the work of each query can best be understood, and the semantic richness of the contents of Asserted Versioning databases best be appreciated.
Glossary References
Glossary entries whose definitions form strong inter-dependencies are grouped together in the following list. The same glossary entries may be grouped together in different ways at the end of different chapters, each grouping reflecting the semantic perspective of each chapter. There will usually be several other, and often many other, glossary entries that are not included in the list, and we recommend that the Glossary be consulted whenever an unfamiliar term is encountered.
ad hoc query
production query
Allen relationships
time period
as-is query
as-was query
asserted version table
assertion
assertion time
Asserted Versioning
Asserted Versioning Framework (AVF)
history table
row create date
semantic logfile
transaction table
bi-temporal data
bi-temporal data management
business data
conventional data
conventional table
currently asserted current version
implicitly temporal data
deferred assertion
deferred transaction
far future assertion time
near future assertion time
design encapsulation
maintenance encapsulation
query encapsulation
effective time
version
version table
versioned data
enterprise contextualization
episode
non-current data
non-temporal data
Now()
PERIOD datatype
point in time
object
temporalized unique index
physical transaction
temporal transaction
temporal insert transaction
temporal update transaction
temporal delete transaction
pipeline dataset
internalization of pipeline datasets
production database
production table
queryable object
queryable temporal data
reconstructable temporal data
seamless access
temporal data
temporal dimension
temporal entity integrity (TEI)
temporal foreign key (TFK)
temporal referential integrity (TRI)
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.