A log (record) of changes that can be used to restore the original database or content if every change is recorded.

--------

A basic relational log might look something like:

  Table: changeLog
  ----------------
  tableName
  columnName
  Key
  operation  (C=change, D=delete)
  newValue
  sequence   (sequence applied in case time is the same)
  dateTimeOfChange   (ugly name, suggestions? "whenChanged"?)

Note that we don't need an Add operation because upon restoration Add is assumed if the key is not already there. Also note that "columnName" would be blank if we are doing a delete. Some may suggest using a different table for logging deletes, but that is another HolyWar about how to normalize.

The flexibility of what "newValue" can hold greatly depends upon vendor implementation related to the field types available and the availability of "generic" types. Most BigIron RDBMS are static-typed unfortunately.

Note that this assumes we know the existing schema. Logging schema changes is another issue (unless schemas are also stored in tables, which many DB's do.)
  
I suspect that for efficiency purposes, a highly proprietary representation or access protocol will most likely be used in practice.

There is similar example in DataAndCodeAreTheSameThing.

----

In software, a ChangeLog records what has changed between versions of a program.  The converse of the ToDo list.
  
-----
See also: TeleType (line-based increments)