What Evidence is Obtained Through Computer Forensics?
 By Todd L. Dietrich and Gregory Fordham
(Page 3)

3. Database Entries and Financial Transactions: Using Them Correctly

In general terms, everything is a database of one kind or another.  But even if the scope is narrowed to its more vernacular meaning, computerized database management systems are probably the single largest repository of the electronic data desired for commercial civil litigation.  In today’s world there simply is very little that is not captured in a database.

In the early days of computer systems databases were hierarchical, since they reflected the real life models that they emulated.  Drawing packages have a hierarchy.  Contracts have a hierarchy.  Organizational structures have a hierarchy.  However, as the use of computers expanded and the need to integrate the operations of organizations increased, the hierarchical structure proved to be a limiting factor.  Often times integration of the organization required that the data on one branch of a hierarchy combine with the data on another branch of the same hierarchical tree or even on a different hierarchical tree altogether.  For example, engineering data needed to be combined with marketing data and sales forecasts in order to produce a production plan for the factory floor.  When engineering was a separate tree from marketing which was also separate from manufacturing it was difficult to automate the integration of these activities.

By the late sixties work was underway to resolve the limitation of the hierarchical data model.  By 1968 researchers at IBM had developed the relational database model.

Relational databases are so named because they are comprised of multiple data tables that can be related to each other to produce a desired result.  In the above illustration the LbrHrs table contains labor timesheet entries.  When the contents of the LbrHrs table are related to the Names table, WrkCode table, BldgCode table and the DataSource table a complete picture is obtained about who was performing the work, the type of work that was being performed, where it was being performed and how the data was entered (timesheet, clock card, wand, etc.).  This information could then also be combined with wage rate information to produce payroll or combined with billing information to produce invoices.

Relational databases are used in all kinds of applications such as financial systems, engineering and configuration management systems, project management and scheduling systems, contract management, personnel management, manufacturing management, and on and on and on.  In fact, most databases used in business today are relational databases.  This includes systems such as the large set based systems like Oracle, SQL Server, DB2,  Informix, Sybase, and the smaller file based systems like Access, Paradox, and dBase.  As will be explained shortly this fact has significant ramifications in the field of electronic data discovery.

• There Is a Difference Between the Front End and the Back End

Typically, people still think of computer applications as some kind of monolithic entity.  As a result, they are unaware that in today’s world computer applications can be split into at least two parts; the front end and the back end.  Simplistically stated, the front end is that part that interacts with the user while the back end is that part that manages the data.

The significance here is that even though there might be a million accounting systems on the market,  those million front ends are probably built on no more than about 100 different back ends.  Even more significant is that the vast majority of today’s market is controlled by only three of those 100 database systems.  This concentration of database back ends makes it easier for the litigator to acquire the expertise necessary to penetrate the opposition’s electronic data repository.

•  There are Standards

Despite the concentration of database back ends, there are other facets to database systems that even further facilitate the litigator’s penetration of the opposition’s electronic data repository.  The most significant of these is standardization.

Relational databases were developed in the late 1960s to overcome the inefficiencies in the hierarchical data model and solve the needs of business applications.  Once the solution was determined to be the relational database model there still needed to be a way to retrieve the data in usable form.  Researchers at IBM pioneered relational database technology and the relational language initially known as Structured English Query Language (SEQueL).  The language was repeatedly revised, improved and renamed to SEQUEL-XRM, SEQUEL2 and finally shortened to SQL, properly pronounced “ess-que-ell” but commonly pronounced “sequel”.

By the late 1970s IBM had successfully demonstrated the capability of its relational technology and was developing a commercial product based on its SQL language when other vendors entered the relational database field.  By the mid 1980s numerous companies had launched SQL database products and SQL was becoming a de facto standard on everything from micros to mainframes.

At about the same time, however, SQL became an official standard, too.  In 1982 the American National Standards Institute (ANSI) began development of a relational language standard.  The standard was ultimately ratified in 1986 and commonly referred to as SQL/86.  In 1987 the standard was also accepted internationally by the International Organization for Standardization (ISO).  The original SQL standard was later expanded and also ratified by both the ANSI and ISO committees in late 1992 and is commonly referred to as SQL/92.  Even today work continues on further enhancement of the standard.  Numerous features and capabilities continue to be added.

Initially the SQL standard was designed for stand­-alone interactive use.  Over the years, however, facilities were added to allow invocation of SQL operations from application programs written in other languages.  Hence, the front-end versus back-end capability discussed above.

For the litigator there is real significance to all this SQL history.  First, since the standard was initially designed for stand alone interactive use, every SQL based relational database system should provide a console capability or at least some capability for accessing and manipulating its contents that is separate and apart from whatever front end application might be using it.  Thus, neither knowledge nor use of the opposition’s application software is necessary in order to access their data.  Second, the broad acceptance of the SQL standard means that with only a few minor syntactical differences litigators can extract electronic data from virtually any system simply by providing a few standard commands.  For example, if one’s desire is to take all the data in one of the opposition’s data tables that desire can be realized by executing the following command.

SELECT * FROM [table name]

The returned result set can then be copied to disk or tape and taken by the litigator.  The command can then be repeated for every table in the opposition’s database so that the litigator has a complete copy of all of the opposition’s data. 

The next logical question is how does one know from what tables to request data.  The answer is that the console, from which the above command is issued, can also be used to identify all of the tables in the opposition’s database.

If there are concerns of relevance then the above command can be modified for a selection criteria as shown below.

SELECT * FROM [table name] WHERE [condition1 (... and conditionN)]

So for the litigator this means that regardless of the million front ends being used or the hundred back ends being used the same instructions can be used to obtain the desired electronic data from practically any relational database system anywhere in the world today. 

< Previous  Next >

Printable Version