Tài liệu Managing time in relational databases- P16 pdf

beginning assertion time of the not-yet-approved parent. We are working on the problem as this book goes to press. We know that the problem is not insoluble. But we also know that it is difficult. Glossary References Glossary entries whose definitions form strong interdep- endencies 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. We note, in particular, that the nine terms used to refer to the act of giving a truth value to a statement, listed in the section The Semantics of Deferred Assertion Time, are not included in this list. Nor are nodes in our Allen Relationship taxonomy or our State Transformation taxonomy included in this list. 12/31/9999 clock tick closed-open Now() Allen relationships approval transaction assertion group date deferred assertion group deferred assertion deferred transaction empty assertion time fall into currency fall out of currency far future assertion time near future assertion time override lock retrograde movement Asserted Versioning Framework (AVF) assertion begin date assertion end date assertion time period Chapter 12 DEFERRED ASSERTIONS AND OTHER PIPELINE DATASETS 285 assertion time assertion closed assertion conventional table dataset episode open episode statement hand-over clock tick instance type managed object object oid persistent object thing occupied represented match replace supercede withdraw pipeline dataset inflow pipeline dataset inflow pipeline outflow pipeline dataset outflow pipeline production data production database production dataset production table row creation date temporal dimension temporal entity integrity (TEI) temporal foreign key (TFK) temporal referential integrity (TRI) the standard temporal model 286 Chapter 12 DEFERRED ASSERTIONS AND OTHER PIPELINE DATASETS transaction table transaction time version effective begin date effective end date effective time period Chapter 12 DEFERRED ASSERTIONS AND OTHER PIPELINE DATASETS 287 13 RE-PRESENTING INTERNALIZED PIPELINE DATASETS CONTENTS Internalized Pipeline Datasets 292 Pipeline Datasets as Queryable Objects 296 Posted History: Past Claims About the Past 297 Posted Updates: Past Claims About the Present 298 Posted Projections: Past Claims About the Future 299 Current History: Current Claims About the Past 300 Current Data: Current Claims About the Present 301 Current Projections: Current Claims About the Future 303 Pending History: Future Claims About the Past 304 Pending Updates: Future Claims About the Present 305 Pending Projections: Future Claim s About the Future 306 Mirror Images of the Nine-Fold Way 307 The Value of Internalizing Pipeline Datasets 308 Glossary References 309 In Chapter 12, we introduced the concept of pipeline datasets. These are files, tables or other physical dataset s in which the managed object itself represents a type and contains multiple managed objects each of which represents an instance of that type, and which in turn themselves contain instances of other types. Using the language of tables, rows and columns, these managed objects are tables, the instances they contain are rows, and those last-mentioned types are the columns of those tables, whose instances describe the properties and relationships of the objects represented by those rows. Because our focus is temporal data management at the level of tables and rows, and not at the level of databases, we have discussed pipeline datasets as though there were a distinct set of them for each production table. Figure 13.1 sho ws one con - ventional table, and a set of eight pipeline datasets related to it. Managing Time in Relational Databases. Doi: 10.1016/B978-0-12-375041-9.00013-3 Copyright # 2010 Elsevier Inc. All rights of reproduction in any form reserved. 289 What Figure 13.1 illustrates is a simplification of the always complex and usually messy physical database environment which IT departments everywhere must manage. Pipeline datasets may often contain data targeted at, or derived from, several tables within that database. They do not necessarily tar- get, or derive from, single tables within a database. In addition, the IT industry has only the broadest of categories of pipeline datasets, categories such as batch transaction tables, logfiles of processed transactions, history tables, or staging areas where unusually complicated data transformations are carried out before the data is moved back into the production tables from whence it originated. Figure 13.1 shows eight different types of pipeline datasets surrounding a conventional table of current data. These nine datasets align with the set of nine categories of temporal data which we introduced in Chapter 12. Given a bi-temporal framework of two temporal dimensions, i n each of which data can exist in the past, the present or the future, this set of nine categories is what results from the intersec- tion of those two temporal dimensions. In addition, since the past, present and future are clear and distinct within each tempo- ral dimension, and since each dimension is clear and distinct from the other, the result of this intersection is a set of nine categories which are themselves clear and distinct, which are, pre- cisely, jointly exhaustive and mutually exclusive. Like our taxonomies, they cover all the ground there is to cover, and they don’t overlap. Like our taxonomies, they are what mathematicians call a partitioning of their domain. Like our taxonomies, they Posted History Pending History Current History A Conventional Table Current Data Posted Updates Pending Updates Posted Projections Pending Projections Current Projections Figure 13.1 Physically Distinct Pipeline Datasets. 290 Chapter 13 RE-PRESENTING INTERNALIZED PIPELINE DATASETS assure us that in our discussions, we won’t overlook anything and we won’t confuse anything with anything else. In the previous chapter, we showed how to physically inter- nalize one particular kind of pipeline dataset within the produc- tion tables which are their destinations or points of origin. We showed how to turn them from distinct physical collections of data into logical collections of data that share residence in a single physical table. The internalization of pipeline datasets is illustrated in Figure 13.2. These internalizations of pipeline datasets are not themselves managed objects to either the operating system or the DBMS. They are managed objects only to the AVF. The operating system recognizes and manages database instances, but is neither aware of nor can manage tables, rows, columns or the other managed objects that exist within database instances. As for the DBMS, once these pipeline datasets are internalized, all it sees is the production table itself, and the columns and rows of that table. In this chapter, we show how to r e-present these internalized datasets as queryable objects. We use the hyphenated form “re-present” advisedly. We do mean that we will show how to represent those internalized datasets as queryable objects, in the ordinary sense of the word “represent”. But we also wish to emphasize that we are re-presenting, i.e. presenting again, things whose presence we had removed. 1 Those things are the physical An Asserted Version Table Posted History Posted Updates Current Data Current History Pending History Pending Updates Posted Projections Current Projections Pending Projections Figure 13.2 Internalized Pipeline Datasets. 1 We also wish to avoid confusion with our technical term represent, in which an object, we say, is represented in an effective time clock tick within an assertion time clock tick just in case business data describing that object exists on an asserted version row whose assertion and effective time periods contain those clock tick pairs. Chapter 13 RE-PRESENTING INTERNALIZED PIPELINE DATASETS 291 pipeline datasets which, in the previous chapter, we showed how to internalize within the production tables which are their destinations or points of origin. For example, we show how to provide, as queryable objects, all th e pen ding transactions against a production table, or a logfile of posted transactions that have already been applied to that table, or a set of data from that table which we currently claim to be true, or that same set of data but as it was originally entered and prior to any corrections that may have been made to it. We do not claim that any of these eight types of pipeline dataset correspond to data that supports a specific business need. For the most part, that will not be the case. For example, auditors will frequently want to look at Posted History pipeline datasets, i.e. at the rows that belong to that logical category of temporal data. But they will usually want to see current assertions about the historical past of the objects they are inter- ested in, along with those past assertions. The current assertions about historical data are logically part of, as we will see, the Posted Updates pipeline dataset. So to provide queryable objects corresponding to their specific business requirements, auditors will usually write queries directly against asserted version tables, queries that combine and filter data from any number of these pipeline datasets. To take another example, the Pending Projections pipeline dataset does not distinguish data in the near assertion time future from data in the far assertion time future. Yet deferred assertions with an assertion begin date that will become current an hour from now serve an entirely different business purpose than deferred assertions whose assertion begin date is January 1 st , 5000. So to provide queryable objects corresponding to real business requirements, we will often have to write queries that filter out rows from within a single pipeline dataset, and com- bine rows from multiple pipeline datasets. Internalized Pipeline Datasets We can say what things used to be like, what they are like, and also what they will be like. These statements we can make are statements about, respectively, the past, the present and the future. In a table in a databas e, each row makes one such state- ment. In conventional tables, however, the only rows are ones that make statements about the present. These things we say represent what we claim is true. Of course, as we saw in Chapter 12, we can equally well say that 292 Chapter 13 RE-PRESENTING INTERNALIZED PIPELINE DATASETS they represent what we accept as true, agree is true, assent to or assert as true, or believe, know or think is true. For now, we’ll just call them our truth claims, or simply our claims, about the statements made by rows in our tables. Besides what we currently claim is true, there are also claims that we once made but are no longer willing to make. These are statements that, based on our current understanding of things, are not true, or should no longer be considered as reli- able sources of information. It is also the case that we may have statements—whether about the past, the present or the future— that we are not yet willing to claim are true, but which none- theless are “works in progress” that we intend to complete and that, at that time, we will be willing to claim are true. Or perhaps they are complete, and we are pretty certain that they are cor- rect, but we are waiting on a business decision-maker to review them and approve them for release as current assertions. The former is a set of transactions about to be applied to the data- base. The latter is a set of data in a staging area, either waiting for additional work to be performed on it, or waiting for review and approval. So if statements may be about what things were, are or will be like, and claims about statements may have once been made and later repudiated, or be current claims, or be claims that we are not yet willing to make but might at some time in the future be willing to make, then the intersection of facts and claims creates a matrix of nine temporal combinations. That matrix is shown in Figure 13.3. 2 what things used to be like what we used to claim what we used to claim things used to be like what we currently claim things used to be like what we will claim things used to be like what we will claim things are like now what we will claim things will be like what we currently claim things are like now what we currently claim things will be like what we used to claim things are like now what we used to claim things will be like what we currently claim what we will claim what things are like what things will be like Figure 13.3 Facts, Claims and Time. 2 With the substitution of the word “claims” for “beliefs”, this is the same matrix shown in Figure 12.1. Chapter 12 also contains a discussion of the interchangeability of “claims”, “beliefs” and several other terms. We note, however, that “claims” is a stronger word than “beliefs” in this sense, that some of the things we believe are true are things we are nonetheless not yet willing to claim are true. We take “claims”, and “asserts” or “assertions”, to be synonymous, and the other equivalent terms discussed in Chapter 12 to be terminological variations that appear more or less suitable in different contexts. Chapter 13 RE-PRESENTING INTERNALIZED PIPELINE DATASETS 293 The reason we are interested in the intersection of facts and claims is that rows in database tables are both. All rows in data- base tables represent factual claims. One aspect of the row is that it represents a statement of fact. The other aspect is that it represents a claim that that statement of fact is, in fact, true. This is just as true of conventional tables as it is of asserted version tables. When dealing with periods of time, as we are, the past includes all and only those periods of time which end before Now(). The future includes all and only those periods of time which begin after Now(). The present includes all and only those periods of time which include Now(). Every row in a bi-temporal table is tagged with two periods of time, which we call assertion time and effective time. Conse- quently, every row falls into one of these nine categories. Con- ventional tables contain rows which exist in only one of these nine temporal combinations. They are rows which represent current claims about what things are currently like. But since conventional tables do not contain any of the othe r eight categories of rows, their rows don’t need explicit time periods to distinguish them from rows in those other categories. And in conventional tables, of course, they don’t have them. Both the assertion and the effective time periods of conven- tional rows are co-extensive with their physical presence in their tables. They begin to be asserted, and also go into effect, when they are created; and they remain asserted, and also remain in effect, until they are deleted. They don’t keep track of history because they aren’t interested in it. They don’t distinguish updates whi ch correct mistakes in data from updates which keep data current with a changing reality, ultimately because the busi- ness doesn’t notice the difference, or is willing to tolerate the ambiguity in the data. So conventional tables, all in all, are a poor kind of thing. They do less than they could, and less than the business needs them to do. They overwrite history. They don’t distinguish between correcting mistakes and making changes to keep up with a changing world. And these conventional tables, as we all know, make up the vast majority of all persistent object tables managed by IT departments. We put up with tables like these because the IT profession isn’t yet aware that there is an alternative and because, by dint of hard work, we can make up for the shortcomings of these tables. Data which falls into one of the other eight categories can usually be found somewhere, or reconstructed from data that can be found somewhere. If all else fails, DBMS archives 294 Chapter 13 RE-PRESENTING INTERNALIZED PIPELINE DATASETS and backups, and their associated transaction logs, will usually enable us to recreate any state that the database has been in. They will allow us to re-present six of the nine temporal categories we have identified. 3 The three categories that cannot be re-presented from backups and logfiles are the three categories of future claims— things we are going to make our databases say (unless we change our minds) about what things once were like, or are like now, or may be like in the future. Future claims often start out as scribbled notes on someone’s desk. But once inside the machine, they exist in transaction datasets, in collections of data that are intended, at some time or other, to be applied to the database and become currently asserted data. In the previous chapter, we called the eight categories of data which are not current claims about the present, pipeline datasets, collections of data that exist at various points along the pipelines leading into production tables or leading out from them. As phys ically separate from those production tables, these collections of data are general ly not immediately available for business use. Usually, IT technical personne l must do some work on these physical files or tables before a business user can query them for information. This takes time, and until the work is complete, the informa- tion is not available. By the time the work is complete, the busi- ness value of the information may be much reduced. This work also has its costs in terms of how much time those technicians must spend to prepare that data to be queried. In addition, even without special requests for information in them, these physical datasets, taken together, constitute a significant management cost for IT. With multiple points of rest in the pipelines leading into and out of production databa se tables, there are multiple points at which data can be lost. For example, data can be accidentally deleted before any copies are made. For datasets in the inflow pipelines, and which have not yet made it into the da tabase itself, the only recourse for lost data is to reacquire or recreate the data. If prior datasets in the pipeline have already been 3 That’s the idea, anyway. In reality, this “data of last resort” isn’t always there when we go looking for it. Backups and logfiles are rarely kept forever, so the data we need may have been purged or written over. There will inevitably be occasional intervals during which the system hiccupped, and simply failed to capture the data in the first place. If the data is still available, it might not be in a readily accessible format because of schema changes made after it was captured. Chapter 13 RE-PRESENTING INTERNALIZED PIPELINE DATASETS 295 [...]... a second time, down the pipeline And this risk is quite real because, prior to making it into the database, the backups and logfiles which protect data once it has reached the DBMS are not yet available By internalizing these datasets within the production tables whose data they contain, we eliminate the costs of managing them, including the costs of recovering from mistakes made in managing them We... as of some point in past effective time, those reports will reflect all corrections made to that data since that time Queries supporting specific business requests for information can, of course, be written against these internalizations of pipeline datasets For example, if we are interested only in 2009’s historical data, as we currently claim that data to be, we can issue a query against this view... eff_beg_dt Now() In the original non-temporal table, there was one row per object Since each oid uniquely identifies an object, and since there can only be one row for each object that is currently asserted as being currently in effect, this view also contains one row per object In addition, since, at every point in time, the original table contains rows that represent what we currently... RE-PRESENTING INTERNALIZED PIPELINE DATASETS legitimately deleted (legitimately because the data had successfully made it to the next downstream point), then we may have to go all the way back to the original point at which the data was first acquired or created This can impose significant delays in getting the data to its consumers, and significant costs in reacquiring or recreating it and in moving it,... those rows in an asserted version table which lie in the assertion time present and also in the effective time present Its subject matter is things 301 302 Chapter 13 RE-PRESENTING INTERNALIZED PIPELINE DATASETS as they are now Its rows are claims about these things which we currently make Current Data is what most of our database tables contain It is a record of what we currently believe things are... to a point in time, and so both time periods must be included on all rows in the view The unique identifier for this or for any other bi-temporal view of an asserted version table, is the combination of oid, assertion time period and effective time period Because Asserted Versioning manages the two pairs of dates as PERIOD datatypes, either or both can be used to represent the time period So, in an... making actionable statements A simple example of a current projection is a version that shows a change in a policy’s copay amount that will go into effect next month The version exists in current assertion time but in future effective time Pending History: Future Claims About the Past The Pending History dataset consists of all those rows in an asserted version table which lie in the assertion time. .. to claim what things what we used to claim used to be like things used to be like what things are like what things will be like Figure 13.4 Posted History what we currently claim what we will claim 297 298 Chapter 13 RE-PRESENTING INTERNALIZED PIPELINE DATASETS This is important to know when creating indexes for performance, as described in Chapter 15 Any report about the effective -time past can be... dataset consists of all those rows in an asserted version table which lie in the assertion time past but in the effective time present Its subject matter is things as they currently are Its rows are claims about these things which we are no longer willing to make Posted Updates are a record of all the times we got it wrong about what is now the present, up to but not including our current claims about that... Chapter 13 RE-PRESENTING INTERNALIZED PIPELINE DATASETS Posted Projections: Past Claims About the Future The Posted Projections dataset consists of all those rows in an asserted version table which lie in the assertion time past but in the effective time future Its subject matter is things as they might have turned out to be Its rows are claims about these things which we are no longer willing to make Posted . within the production tables whose data they contain, we eliminate the costs of managing them, including the costs of recovering from mistakes made in managing. currently asserted as being currently in effect, this view also contains one row per object. In addition, since, at every point in time, the original table contains rows