The Experts below are selected from a list of 12 Experts worldwide ranked by ideXlab platform
Randall Weis - One of the best experts on this subject based on the ideXlab platform.
-
Designing and Generating Asserted Versioning Databases
Managing Time in Relational Databases, 2010Co-Authors: Tom Johnston, Randall WeisAbstract:This chapter discusses how Asserted Versioning databases can be designed and generated. An Asserted Versioning database is one that contains at least one asserted version Table. Asserted Versioning databases are generated from the combination of a conventional logical data model and a set of metadata entries. Asserted Versioning simplifies the management of temporal databases by providing maintenance encapsulation, query encapsulation, and design encapsulation. The chapter discusses how temporal design requirements are expressed in metadata associated with a conventional logical data model, how this metadata is used to convert Nontemporal Table schemas into bitemporal Table schemas, and also how it is used to generate the code, such as stored procedures, that enforce both temporal entity integrity and temporal referential integrity on those Tables. If ERwin is used as the data modeling tool, then a set of Erwin macros that have been written will do the conversion automatically. Otherwise, the conversion will be a manual process.
-
The Basic Scenario
Managing Time in Relational Databases, 2010Co-Authors: Tom Johnston, Randall WeisAbstract:When an object is represented by a row in a Nontemporal Table, the sequence of events begins with the insertion of that row, continues with zero or more updates, and either continues on with no further activity, or ends when the row is eventually deleted. When an object is represented in an asserted version Table, the result includes one row corresponding to the insert in the Nontemporal Table, additional rows corresponding to the updates to the original row in the Nontemporal Table, and an additional row if a delete eventually takes place. This sequence of events constitutes what is called the basic scenario of activity against both conventional and asserted version Tables. This chapter describes how the basic scenario works when the target of that activity is an asserted version Table. Basic temporal transactions are temporal transactions that do not specify any bitemporal parameters. Any one or more of three bitemporal parameters—an assertion begin date, an effective begin date or an effective end date—may be specified on a temporal transaction. On a basic temporal transaction, none of them are specified. A temporal delete is translated into a set of physical update transactions that withdraw the affected versions, followed by either one or two physical insert transactions that delimit the scope of the delete and, if necessary, any number of withdrawals and replacements to adjust episode begin dates that may have been affected.
Tom Johnston - One of the best experts on this subject based on the ideXlab platform.
-
Designing and Generating Asserted Versioning Databases
Managing Time in Relational Databases, 2010Co-Authors: Tom Johnston, Randall WeisAbstract:This chapter discusses how Asserted Versioning databases can be designed and generated. An Asserted Versioning database is one that contains at least one asserted version Table. Asserted Versioning databases are generated from the combination of a conventional logical data model and a set of metadata entries. Asserted Versioning simplifies the management of temporal databases by providing maintenance encapsulation, query encapsulation, and design encapsulation. The chapter discusses how temporal design requirements are expressed in metadata associated with a conventional logical data model, how this metadata is used to convert Nontemporal Table schemas into bitemporal Table schemas, and also how it is used to generate the code, such as stored procedures, that enforce both temporal entity integrity and temporal referential integrity on those Tables. If ERwin is used as the data modeling tool, then a set of Erwin macros that have been written will do the conversion automatically. Otherwise, the conversion will be a manual process.
-
The Basic Scenario
Managing Time in Relational Databases, 2010Co-Authors: Tom Johnston, Randall WeisAbstract:When an object is represented by a row in a Nontemporal Table, the sequence of events begins with the insertion of that row, continues with zero or more updates, and either continues on with no further activity, or ends when the row is eventually deleted. When an object is represented in an asserted version Table, the result includes one row corresponding to the insert in the Nontemporal Table, additional rows corresponding to the updates to the original row in the Nontemporal Table, and an additional row if a delete eventually takes place. This sequence of events constitutes what is called the basic scenario of activity against both conventional and asserted version Tables. This chapter describes how the basic scenario works when the target of that activity is an asserted version Table. Basic temporal transactions are temporal transactions that do not specify any bitemporal parameters. Any one or more of three bitemporal parameters—an assertion begin date, an effective begin date or an effective end date—may be specified on a temporal transaction. On a basic temporal transaction, none of them are specified. A temporal delete is translated into a set of physical update transactions that withdraw the affected versions, followed by either one or two physical insert transactions that delimit the scope of the delete and, if necessary, any number of withdrawals and replacements to adjust episode begin dates that may have been affected.
