|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Transaction time records when a datum is actually stored in a database, that is, it is the time between when the datum was inserted and when it was deleted. In our data model, edges can have transaction-time properties that record the lifetime of the edge in the database. In the movie database, the transaction-time lifetime is missing from many of the edges. Please examine the sequence of transactions that created the movie database. Legal pathsTo understand the important role of transaction time, let's start with a simple query that does not explicitly mention transaction time at all! (Note that we are setting the security to reach all the nodes in the database.)There are two similar names in the three result tuples. This is because Bruce's name was originally misspelled and was then corrected in the database. The corrected name appears twice because there are two separate valid paths to his name. The curious thing about the result is that Bruce Willis is reachable twice and Bruce Wilis only once. Let's try to figure out how each is reached by looking at the nodes on the paths to these names. Interesting, but why isn't there a path from &Star_Wars_IV to Bruce Wilis? If we look at the transaction times along the paths all will become clear.
Let's look at the transaction time, and the coalesced transaction time, for each name.
To get the current names, we can slice at now.
Curtis E. Dyreson, Michael H. Böhlen, and Christian S. Jensen © 1998-2000. All rights reserved. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
E-mail questions or comments to Curtis.Dyreson at usu.edu |