Time and the Relational Schema
Oracle Forensics tips by Paul Wright
Dr. Codds relational model is good at
organizing sets of objects in a moment in time. One problem is that
as these objects change over time, they are overwritten. So for
instance in the employees table the historical salaries are not
recorded. Relational schemas tend towards keeping a single row for
each instance of a thing e.g. a single row for an employee in an
employees table. This is good for organizing sets of data but not as
useful for organizing information about each tuple over time. For
instance if the employee left the company and then returned it might
cause problems. One way of dealing with this is to duplicate each
entry with an additional column called timestamp to differentiate
them so that past states of a tuple can be recorded in the relation.
This is not perfect.
Temporal databases become very interesting
especially when applied to using SQL based RDBMSs as log hosts and
thinking about the forensic investigation of a potential database
The University of Arizona in Phoenix has played
a lead role in temporal database research and contributes to the
proposed Temporal extensions to SQL3.
Oracle has already added features to combat the
temporal shortcoming of the relational model largely based around
the proposed temporal extensions to SQL3. Of particular interest is
the ability to select all versions of a tuple/row between two times.
Select * from EMPLOYEE versions between '2:00
PM' and '3:00 PM';
This is dependant on the redo available as
The ability to query historic data using
temporal SQL is useful but in order to go back weeks, months and
years very large storage is required which will prompt organizations
to invest in Data Warehouse and Storage Area Network technology to
house the large amount of archived data required.
Oracle should be
commended for their adoption of greater time functionality in some
of its products.
?The Oracle 10g
Workspace Manager includes the period data type, valid-time support,
transaction-time support, support for bitemporal tables, and support
for sequenced primary keys, sequenced uniqueness, sequenced
referential integrity, and sequenced selection and projection, in a
manner quite similar to that proposed in SQL/Temporal.?
When all the
tables in an RDBMS have this type of time support then tracing
actions on data will be much improved. One major reason for this is
that Oracle basic auditing currently has the ability to record the
SQL issued by a user but not the ability to show what data was
returned as a result of the query. This may be very important in an
investigation. Workspace Manager gives the ability to run audited
SQL on previous
versions of the data and so regenerate the result of the audited
query. If Extended auditing was being used then by also using
LogMiner to query the historical state of the information using
regenerated SQL from the Audit then the reporting data should be the
same as the original user who issued the SQL.
Being able to
prove the state of an electronic file at a certain time is a problem
which is at the centre of many legal issues concerning Oracle DBA?s.
Firstly there is the ability to prove that an external person hacked
their database, secondly is the need to show an internal employee
misrepresented/modified/abused data in the database, thirdly to
prove compliance with external policies such as SOX/PCI and fourthly
to show internal due diligence with company policy. Just being able
to make the database work and work fast is not enough. Legal
controls are also required.
This is an excerpt from the book "Oracle
Forensics: Oracle Security Best Practices", by Paul M. Wright,
the father of Oracle Forensics.