U.S. patent application number 12/956395 was filed with the patent office on 2012-05-31 for records management of database tables.
This patent application is currently assigned to ORACLE INTERNATIONAL CORPORATION. Invention is credited to Kiran Vedula VENKATA NAGA RAVI.
Application Number | 20120136904 12/956395 |
Document ID | / |
Family ID | 46127342 |
Filed Date | 2012-05-31 |
United States Patent
Application |
20120136904 |
Kind Code |
A1 |
VENKATA NAGA RAVI; Kiran
Vedula |
May 31, 2012 |
RECORDS MANAGEMENT OF DATABASE TABLES
Abstract
Systems, methods, and other embodiments associated with records
management are described. One example method includes managing a
relational database for compliance with record retention rules,
where the relational database includes a table organized with rows
and columns. The relational database provides options for
designating rows for records management.
Inventors: |
VENKATA NAGA RAVI; Kiran
Vedula; (Belmont, CA) |
Assignee: |
ORACLE INTERNATIONAL
CORPORATION
Redwood Shores
CA
|
Family ID: |
46127342 |
Appl. No.: |
12/956395 |
Filed: |
November 30, 2010 |
Current U.S.
Class: |
707/803 ;
707/E17.045 |
Current CPC
Class: |
G06F 16/21 20190101 |
Class at
Publication: |
707/803 ;
707/E17.045 |
International
Class: |
G06F 17/30 20060101
G06F017/30 |
Claims
1. A non-transitory computer-readable medium storing
computer-executable instructions that when executed by a computer
cause the computer to perform a method, the method comprising:
managing a relational database for compliance with record retention
rules, where the relational database includes a table organized
with rows and columns, where the relational database provides
options for designating rows for records management, where the
managing comprises: adding a virtual column to the table in the
relational database; providing an interface to select and designate
one or more rows in the table to be a managed record; and in
response to a row in the table being designated as a managed
record, generating a unique identifier and storing the unique
identifier in the virtual column associated with the row that is
designated, where access to data in the row is controlled at least
in part by the unique identifier.
2. The non-transitory computer-readable medium of claim 1, further
comprising instructions that: in response to a request to modify or
delete data from the table, performing a compliance operation
comprising: (i) identifying a row in the table that stores the data
associated with the request; (ii) determining if the row contains a
unique identifier in the virtual column; (iii) if the unique
identifier exists, then prohibiting the request to modify or delete
the data from the row; and (iv) if the unique identifier does not
exist, allowing the request to be performed.
3. The non-transitory computer-readable medium of claim 1, further
comprising instructions that identify retention rules that apply to
the row by using the unique identifier from the virtual column of
the row, where the retention rules are stored in a life cycle table
and are associated with the unique identifier.
4. The non-transitory computer-readable medium of claim 1, where
adding the virtual column comprises instructions for generating and
inserting the virtual column as part of the table and inserting the
unique identifier in the virtual column when a row is marked as a
record.
5. The non-transitory computer-readable medium of claim 1, where
the virtual column is not included in a visible structure of the
table and is not accessible from a user query application.
6. The non-transitory computer-readable medium of claim 1, where if
a row is designated as being a record and the unique identifier is
assigned to the row, access from a database level interface or
access from an application level interface to the row is controlled
based at least in part on the unique identifier.
7. The non-transitory computer-readable medium of claim 1, where
the row that is designated as a record includes data contained in
the row that is subject to a pre-defined life cycle.
8. The non-transitory computer-readable medium of claim 1, further
comprising providing a soft delete option where data that is
deleted from the relational database is moved to a read-only
tablespace and retained.
9. The non-transitory computer-readable medium of claim 1, where
providing the interface includes providing an application
programming interface that is configured to provide the only access
to the virtual column.
10. A database system, comprising: a non-transitory
computer-readable medium for storing a database where the database
includes at least one table organized with rows and columns of
data; a records management module, implemented in a non-transitory
computer-readable medium, configured to generate and add a column
to the table for records management control where the records
management module is configure to generate a unique identifier for
each row in the table that is designated as a record and to store
the unique identifier in the virtual column associated with the
row; and a physical access manager configured to process access
requests to the database; where the physical access manager is
configured to determine whether the unique identifier exists for a
row in the virtual column prior to processing the access request
and if the unique identifier is present, then access to the row is
prohibited.
11. The database system of claim 10, an application programming
interface configured to allow selection of rows in the table to be
under records management control.
12. The database system of claim 10, further comprising a life
cycle table that contains retention rules that are applied to a
row, where the retention rules are assigned to the row by the
unique identifier from the virtual column.
13. The database system of claim 10, where the column added to the
table is a virtual column that is not included in a visible
structure of the table and is not accessible from a user query
application.
14. The database system of claim 10, where the database system is
configured to partition the table into two tablespaces, where rows
that include the unique identifier in the virtual column are moved
to a read-only tablespace and where rows with no unique identifier
are stored in a separate tablespace.
15. A non-transitory computer-readable medium storing
computer-executable instructions that when executed by a computer
cause the computer to perform a method, the method comprising:
adding a virtual column to a pre-existing table in a database;
generating a unique identifier for each row in the table that is
designated as a record to be subject to compliance rules and
storing the unique identifier in the virtual column associated with
the corresponding row; and in response to a received request that
attempts to manipulate data in the table, prohibiting access to a
row if the unique identifier exists in the virtual column
associated with the row.
16. The computer-readable medium of claim 15, where the rows of the
table are linked to applicable compliance rules by the unique
identifier associated with the row.
17. The computer-readable medium of claim 15, further comprising
instructions that generate a life cycle table that contains the
compliance rules.
18. The computer-readable medium of claim 17, where in response to
receiving the request: identifying rows in the table that are
affected by the request; and for a selected row, determining the
compliance rules that are applied to the selected row from the life
cycle table using the associated unique identifier.
19. The computer-readable medium of claim 15, where the virtual
column is not included in a visible structure of the table and is
not accessible from a user query application.
20. The computer-readable medium of claim 15, further comprising
providing a soft delete option where data that is deleted from the
database is moved to a read-only tablespace and retained.
Description
BACKGROUND
[0001] Many business organizations have found that the importance
and volume of business-critical records is rapidly increasing.
Because of this, many companies are reevaluating their unstructured
data strategy and are turning towards more reliable records
management policies.
[0002] "Records management" is the systematic and comprehensive
control of the creation, capture, maintenance, filing, use, and
disposition of records. It aims to ensure that records contained in
a database are authentic and reliable; can be retrieved when needed
as quickly and efficiently as possible; and are not destroyed
prematurely or kept longer than required. A "record" in the
compliance industry is any data item (recorded information) that is
under records management control and subject to a life cycle. A
record's life cycle is the life span of a record from its creation
or receipt to its final disposition. It is usually described in
three stages: creation, maintenance and use, and final disposition.
A set of retention rules/policies are applied to the record over a
defined time period.
[0003] Different user applications (e.g. email, accounting,
personnel, etc.) operate with different types of data that use
different databases. To control access to its associated database,
each user application must implement policies/rules that apply to
its data. For example, an email application can implement a
retention policy that emails will be maintained in the database for
7 years. However, someone with direct access to the database (e.g.
a database administrator) can by-pass the email application policy
and delete emails directly from the database (intentionally or
unintentionally).
[0004] Another example is a background job that periodically
updates/deletes data from the database tables. The background job
does not operate through the email application and thus by-passes
the retention policies. To ensure compliance, the background job
must be programmed to be aware of the email retention policies and
to comply with the email application's logic to prevent
updates/deletions. Other background jobs must also be individually
reprogrammed, which can be time intensive. Of course, if a policy
changes, then all applications and background jobs that are
affected must be identified and reprogrammed. This type of records
management does not ensure compliance with implemented
policies.
BRIEF DESCRIPTION OF THE DRAWINGS
[0005] The accompanying drawings, which are incorporated in and
constitute a part of the specification, illustrate various systems,
methods, and other embodiments of the disclosure. It will be
appreciated that the illustrated element boundaries (e.g., boxes,
groups of boxes, or other shapes) in the figures represent one
embodiment of the boundaries. One of ordinary skill in the art will
appreciate that in some embodiments one element may be designed as
multiple elements or that multiple elements may be designed as one
element. In some embodiments, an element shown as an internal
component of another element may be implemented as an external
component and vice versa. Furthermore, elements may not be drawn to
scale.
[0006] FIG. 1 illustrates one embodiment of a method associated
with records management.
[0007] FIGS. 2a-2b illustrates one embodiment of a database table
before and after a column is added.
[0008] FIG. 2c illustrates one embodiment of a life cycle
table.
[0009] FIG. 2d illustrates one embodiment of a life cycle log
table.
[0010] FIG. 3 illustrates one embodiment of a method associated
with controlling access to a database.
[0011] FIG. 4 illustrates an embodiment of a database system that
includes records management.
DETAILED DESCRIPTION
[0012] Systems, methods, and other embodiments are described herein
that provide records management techniques. In one embodiment,
records management features are pushed down and implemented into a
database table itself rather than at a user application level. In
one embodiment, the database is configured to be aware of and
determine a life cycle of a record. Physical access to the database
is protected even when someone or something (e.g. computer process)
by-passes the user application that operates on the database and
tries to access the physical database directly. In this manner, the
database is configured to provide the infrastructure for compliance
solutions.
[0013] With reference to FIG. 1, one embodiment of a method 100 is
illustrated that is associated with records management. The method
100 is computer-implemented and in one embodiment, may be
implemented as executable instructions stored in a non-transitory
computer-readable medium. At 110, the method provides for managing
a relational database for compliance with record retention rules.
The relational database includes one or more tables. A table is
organized in rows and columns where each row represents a single,
implicitly structured data item, and each column defines a field in
the row. To implement a compliance policy for data in the table,
the table is designated to be records managed. The designation may
be performed by a programming instruction, a selection via a
graphical user interface, or other selection mechanism. This will
be described in more detail below.
[0014] At 120, a virtual column is added to the table that has been
designated to be records managed. FIG. 2a illustrates an example of
an accounts payable table 200 as originally created. FIG. 2a is a
"before" image of the table since it does not include a virtual
column. FIG. 2b shows the table 200 "after" a virtual column 210 is
added to the pre-existing table 200.
[0015] In one embodiment, the virtual column is not included in a
visible structure of the table and is not accessible from a user
query application. For example, the virtual column 210 is a pseudo
column or hidden column. It can be selected through a records
management interface but not updated or deleted by a user. This
prevents tampering with the virtual column 210 and its data.
[0016] With continued reference to FIG. 1, at 130, the method
provides an interface to allow a user to select rows to be records
managed. Since records management is an administrative task, the
user in this case is most likely an authorized database
administrator. When selecting one or more rows, the selected rows
are marked or designated to be a "record." As stated, a "record" is
recorded information that is under records management control.
Retention rules/policies then apply to the data within the selected
rows. At 140, in response to a row in the table being designated as
a managed record, a unique identifier is generated for the row and
the unique identifier is stored in the virtual column associated
with the row.
[0017] For example in FIG. 2a, suppose row 1 (payment ID=1) is
selected to be a record. A unique identifier (e.g. "1515515") is
generated and stored in the virtual column 210 for row 1. Other
unique identifiers are generated for other selected rows. The row
with Payment ID=2 does not include a unique identifier in the
virtual column 210 and thus is not subject to records management
control. The virtual column 210 is labeled as REC_ID (record
identifier) but other labels may be used.
[0018] Once a unique identifier is stored and assigned to the row,
access to data in the row is controlled at least in part by the
unique identifier. In one embodiment, the existence of the unique
identifier is an indicator that the data in the row cannot be
updated or deleted. Thus, regardless of how the access is made or
from which application, the database will not permit a row with a
unique identifier to be modified or deleted.
[0019] In another embodiment, pre-defined rules can be applied to a
row during its life cycle. For example, the unique identifier links
the row to retention rules that apply to the row. The retention
rules may be defined in a life cycle table that defines actions
that can or cannot be performed along with time durations and/or
dates. Particular retention rules in the life cycle table 220 are
linked to a row in the table 200 by assigning the same unique
identifier as in the corresponding row. FIG. 2b shows a life cycle
table 220 and shows rows in the table 200 of FIG. 2a linked to
actions in the life cycle table 220. Thus the marked row and its
data are subject to pre-defined rules/actions that are maintained
in the life cycle table 220. For example, the row with payment ID=1
is linked to actions in the life cycle table 220 where the action
is "Retain" and the duration is "3 years." Thus the record must be
retained and not deleted/updated for 3 years.
[0020] In another embodiment, if a row is designated as being a
managed record and the unique identifier is assigned to the row,
then access from a database level interface or access from an
application level interface to the row is controlled based at least
in part on the unique identifier. For example, since the records
management features are implemented on the database itself,
external applications such as a user application (e.g. email
application) cannot by-pass the management features.
[0021] As stated previously, even though the email application may
have record retention rules implemented internally, a person or
process may have ways to access the database directly and thus not
go through the email application. Similarly, a database
administrator can by-pass the user application and can access the
physical database directly (due to appropriate authorization). Data
can be deleted intentionally or unintentionally. However, with the
implemented features, these types of accesses are still subjected
to control based on the unique identifier. If the unique identifier
exists for a row that the database administrator attempts to
update/delete, the operation is prohibited.
[0022] In another embodiment, FIG. 2d illustrates an example log
table 230 that may be generated and maintained for marked records.
When an operation is attempted on a marked record from the table
200, an event is stored in the log table 230 and is associated with
the corresponding unique identifier (e.g., REC_ID). For example,
REC_ID 2552525 shows that an "illegal access" was attempted on the
corresponding record (e.g. an illegal delete action). Access may
have been denied for various reasons such as the user did not have
appropriate authorization to delete the record or the retention
period has not yet expired. Retention periods determine the length
of time that a record must be kept, unless there is a legal or
regulatory action requiring that certain records be held or frozen
from possible destruction.
[0023] In another embodiment, method 100 may include a soft delete
feature. A soft delete is where data is deleted from a user's
application but is not deleted from the main database. The soft
delete may also delete a record from the relational database but
then move the record to a read-only tablespace where it is
retained.
[0024] For example, a user may wish to clean out his/her email
in-box and delete old emails to make it more manageable (e.g. user
has a large volume of emails). However, suppose retention rules
have been applied that prohibit the deletion of the emails. Rather
than prohibit the user from cleaning out the in-box, the emails can
be deleted from the user's in-box (and from his/her view). But, the
emails are then stored in a separate storage device/location to
comply with the retention rules. Thus although the user believes
the emails are deleted, they still exist in a different
location.
[0025] The following example is one embodiment for defining a
database table using the CREATE TABLE syntax of SQL/Oracle
Database. Of course, other syntax can be used based on the database
application/programming language that is used. For example, an
additional option is provided to organize the table as "Records
Managed" as part of the CREATE TABLE command that defines a new
table or as part of an ALTER TABLE command that alters an existing
table.
TABLE-US-00001 CREATE TABLE Table_Name ORGANIZATION RECORDS_MANAGED
[RETENTION RECORD|NON-RECORD|CUSTOM DEFAULT RECORD] [RMA_ROLE
ROLE_NAME DEFAULT RMA_ADMIN] [AUTO_PURGE ON|OFF DEFAULT OFF]
[LC_TABLE TABLE_NAME TABLE_NAME_LC_TABLE] [SOFT_DELETE ON|OFF
DEFAULT OFF] [STORAGE IN_PLACE|READ_ONLY_TABLESPACE DEFAULT
IN_PLACE]
[0026] In this CREATE TABLE construct, the table created is
classified to be RECORDS_MANAGED in an ORGANIZATION parameter. This
classification causes a virtual column to be added to the table. It
should be appreciated that other parameters that may appear as part
of the CREATE TABLE instructions are not shown here. For example,
other parameters may include defining fields, field types, key
fields, and so on. Thus when a table is created, a number of fields
are defined for each row, where each field is a column in the
table. However, the virtual column is not defined as a field.
[0027] Various options may be provided under the RECORDS_MANAGED
classification. As seen above in the CREATE TABLE construct, the
first line designates a "RETENTION" option that designates the
table to be a record, non-record, or custom type. As a "RECORD,"
the data is retained for applicable compliance policies. A
"NON-RECORD" can be used for data that is not necessarily subject
to compliance policies but other desired rules can be applied. For
example, it can be used for personal information that should be
purged after a period of time (e.g., after 3 years). Thus a
non-record can be used for data that does not require retention but
does require destruction after a certain period. The "CUSTOM"
option can be used to specify custom retention/destruction rules.
One or more options can also have a default setting if not
specified. Sample default settings appear after the "DEFAULT" term
in each command line.
[0028] The "RMA_ROLE" option designates the records management
administrator (RMA) role. The "AUTO_PURGE" option may be on or off.
The "LC_TABLE" option identifies the Life Cycle Table that is
linked with the table. As explained previously, the life cycle
table defines retention and/or disposition rules that apply to
associated records (e.g., preserve for 5 years, then move to
location B, then destroy record). The "SOFT_DELETE" option, as
explained above, allows for records to be removed from the user
application but not from the main database. The "STORAGE" option
can be set as "in place" or "read only tablespace." The "in place"
setting is mutually exclusive with the "soft delete" option. The
"read only tablespace" means that once the data is written, it can
only be read and cannot be deleted or modified.
[0029] A similar process can be performed to an existing database
table using, for example, an ALTER TABLE command:
TABLE-US-00002 ALTER TABLE AC_PAYABLES ORGANIZATION RECORDS_MANAGED
[Options]
[0030] With this command, the pre-existing table named
"AC_PAYABLES" is reorganized to be "Records Managed" and thus under
the control of records management. In one embodiment, when a
database administrator creates or alters a table as shown above,
the database: [0031] Adds a pseudo/virtual column RECORD_ID to the
TABLE specified. [0032] Creates additional internal tables (e.g.
Life Cycle Table, Log Table, etc) as required. These tables are not
accessible to end-user or administrator to prevent tampering.
[0033] Adds additional checks during requests to update or delete
data from the table. Modification of rows that are marked as
records is prohibited.
[0034] In one embodiment, application program interfaces (API) are
provided to perform operations related specifically to records
management. The following APIs can be implemented as commands that
are applicable to a specified table that has been classified as
"records managed" and are available to an administrator after the
classification is made:
TABLE-US-00003 DBMS_RM_MARK_ROW_AS_RECORD (rowid ROWID, Options...)
DBMS_RM_PURGE_RECORD_ROW (rowid ROWID, Options...)
[0035] The example commands are labeled as DBMS_RM, which stands
for Database Management System Records Management. Of course, other
names can be used. The first command is used to mark specified rows
as a "record" and includes parameters to identify the rows (e.g.
identify by row ID). The command is one example of an interface
that may be provided for selecting rows as records with respect to
block 130 in FIG. 1. Other desired "options" can be included. The
second command is used to purge specified rows. As stated
previously, after a row is designated or marked as a "record," a
record ID is generated and stored in the virtual column for that
row. In another embodiment, a graphical user interface can be
provided to allow for selection of rows instead of or in
combination with the command level instructions. The database
system can be configured where these interfaces provide the only
access to the virtual column so as to reduce data tampering.
[0036] In one embodiment, changing the organization of an existing
table to be "records managed" using the ALTER TABLE command does
not alter the logical structure of the table. The virtual column is
added or associated with the table but is hidden from view and
cannot be accessed by users. This also means that a table can be
switched back and forth between being "Records Managed" or not.
Once a table is classified as "Records Managed," the method and
system then allows the database administrator to use the Records
Management APIs specified above to manage the records in the
database.
[0037] When data is marked as a record, based on the options
defined in the CREATE/ALTER table command, the database can
automatically save a copy of this record in a WORM storage (write
once read many) that would be available for restoration of the
record if needed. Also, given that the record is stored in a
database, the typical features of data replication and disaster
recovery are additional benefits to an application that uses the
records management approach. In another embodiment, the records are
given an inherent expiration date and associated life cycle. Hence
replicated copies of the database may also purge the data at the
same time as the original record that is intended to be
destroyed.
[0038] With reference to FIG. 3, one embodiment of a method 300 is
illustrated that is associated with controlling access to a
database in view of compliance policies. Method 300 is described
from the view point that a request is made to modify or delete data
from the database and a controller (e.g. a physical access manager)
is responsible for processing requests to the database. Presume
that the database has been created and selected rows have been
marked as "records managed" as described with reference to FIGS.
1-2. Thus the database includes a virtual column and marked records
have a unique identifier assigned in the virtual column. Unmarked
rows do not have an assigned unique identifier.
[0039] Method 300 initiates in response to receiving a request to
modify or delete data from the database. In some embodiments, the
request may be part of a query. Before processing the request, the
method performs compliance operations to determine if the request
is permitted. At 310, the method identifies the row(s) that store
the data associated with the request. This may involve a query
parser that parses the query to extract terms and determines which
rows are requested. At 320, once the row is identified, the method
determines if the row contains a unique identifier in the virtual
column. At 330, if the unique identifier exists, then the request
to modify or delete is prohibited at 340. If the unique identifier
does not exist in the virtual column, the request is allowed to
perform on the data within the row because the row is not subject
to records management. The method repeats for as many rows that are
involved in the request.
[0040] Thus, whenever a record/row is being updated, the database
checks if the row is marked as a "record" based on the presence of
the ID in the virtual column. This process prevents updates to data
that needs to be retained. However, an administrator that is
granted records management administrator privileges can delete
marked rows using the records management commands/interfaces
identified above as DBMS_RM commands.
[0041] FIG. 4 illustrates one embodiment of a database system 400
that is configured with one or more of the records management
features described with reference to FIGS. 1-3. FIG. 4 is a
simplified example and does not show all possible components of a
database system, which can be very complex. A database table 410 is
maintained on one or more non-transitory storage devices and a
physical access manager 420 is configured to control access
requests to the data in the database table 410. For example, user
applications or background tasks issue access requests that wish to
perform various operations (e.g. write data, read data, modify
data, delete data, and so on).
[0042] The database system 400 includes a records management module
430 and records management application program interfaces (APIs)
440. The records management module 430 is configured to create and
implement records management features that are applied to a
selected table as described above. For example, suppose the table
410 is selected to be "records managed." The records management
module 430 causes a virtual column to be added to the table as
shown by column 450. The virtual column 450 is labeled as REC ID
and is used to store a unique identifier for marked rows. The
virtual column 450 and the marked rows are linked to applicable
rules in a life cycle table 455 as previously described.
[0043] The records management APIs 440 allow for the selection of
rows to be marked as a "record" that are subject to compliance
rules. The physical access manager 420 is configured to control
access to the table 410 by checking the virtual column 450 to
determine whether or not a modification or deletion request is
permitted. In one embodiment, the physical access manager 420 is
configured to perform the method of FIG. 3.
[0044] In one embodiment, the database system 400 is part of a
computing system that includes one or more processors 460, memories
470, storage devices 480, and other computer components that
operate with the database system 400. In one embodiment, the
physical access manager 420 and the records management module 430
are implemented with logic as defined herein. This may include
hardware components, firmware, a non-transitory computer readable
medium with stored instructions, or combinations of these
elements.
[0045] In another embodiment, the described methods and/or their
equivalents may be implemented with computer executable
instructions. Thus, in one embodiment, a non-transitory
computer-readable medium is configured with stored computer
executable instructions that when executed by a machine (e.g.,
processor, computer, and so on) cause the machine (and/or
associated components) to perform the method.
[0046] In another embodiment, the database system 400 is configured
to automatically partition the database table 410 into two
tablespaces based on whether the record identifier in the virtual
column 450 is present or null. One tablespace includes all rows
that have a record identifier assigned to them (e.g. rows that are
marked as records). The other tablespace includes all rows that
have a null record identifier in the virtual column 450 (e.g. rows
not marked as records). Once a row is marked as a record and has a
non-null record identifier, the record is moved to a read-only
tablespace and thus cannot be modified.
[0047] While for purposes of simplicity of explanation, the
illustrated methodologies in the figures are shown and described as
a series of blocks, it is to be appreciated that the methodologies
are not limited by the order of the blocks, as some blocks can
occur in different orders and/or concurrently with other blocks
from that shown and described. Moreover, less than all the
illustrated blocks may be used to implement an example methodology.
Blocks may be combined or separated into multiple components.
Furthermore, additional and/or alternative methodologies can employ
additional blocks that are not illustrated.
[0048] Glossary
[0049] Various terms are listed here for convenience.
[0050] Cutoff: When a record is marked to begin its disposition or
retention cycle.
[0051] Disposition: The set of rules which specify what to do with
records as part of their lifecycle. This may include retaining,
moving, or deleting records.
[0052] Freeze/Unfreeze: The ability to stop the final disposition
instruction (delete) in the lifecycle of a record from being
executed. Other disposition instructions (e.g., retain and move)
are executed. In one embodiment, the system is implemented to
support legal holds, which allows the records management module 430
(used by an administrator) to suspend the lifecycles of records in
a record category or folder indefinitely by using a freeze/unfreeze
command.
[0053] Hardware immutability: The ability of the hardware to
prevent anyone from accessing, altering or deleting any content
stored on a disk. In one embodiment, the physical access manager
420 of FIG. 4 is configured with this feature.
[0054] Lifecycle: The life span of a record from its creation or
receipt to its final disposition. It is usually described in three
stages: creation, maintenance and use, and final disposition.
[0055] Record: Any form of recorded information that is under
records management control.
[0056] Retention period: The set of rules which specify how long to
keep records.
[0057] RAM: random access memory.
[0058] DRAM: dynamic RAM.
[0059] ROM: read only memory.
[0060] SQL: structured query language.
[0061] The following includes definitions of selected terms
employed herein. The definitions include various examples and/or
forms of components that fall within the scope of a term and that
may be used for implementation. The examples are not intended to be
limiting. Both singular and plural forms of terms may be within the
definitions.
[0062] References to "one embodiment", "an embodiment", "one
example", "an example", and so on, indicate that the embodiment(s)
or example(s) so described may include a particular feature,
structure, characteristic, property, element, or limitation, but
that not every embodiment or example necessarily includes that
particular feature, structure, characteristic, property, element or
limitation. Furthermore, repeated use of the phrase "in one
embodiment" does not necessarily refer to the same embodiment,
though it may.
[0063] "Computer-readable medium", as used herein, refers to a
non-transitory medium that stores instructions and/or data. A
computer-readable medium may take forms, including, but not limited
to, non-volatile media, and volatile media. Non-volatile media may
include, for example, optical disks, magnetic disks, and so on.
Volatile media may include, for example, semiconductor memories,
dynamic memory, and so on. Forms of a computer-readable medium may
include, but are not limited to, a floppy disk, a flexible disk, a
hard disk, a magnetic tape, other magnetic medium, an ASIC
(application specific integrated circuit), a compact disk, other
optical medium, a RAM, a ROM, programmable memories, a memory chip
or card, a memory stick, and other media from which a computer, a
processor or other electronic device can read.
[0064] In some examples, "database" is used to refer to a table. In
other examples, "database" may be used to refer to a set of tables.
In still other examples, "database" may refer to a set of data
tables and methods for accessing and/or manipulating those data
tables.
[0065] "Logic", as used herein, includes but is not limited to
hardware, firmware, a non-transitory computer readable medium that
stores instructions, instructions in execution on a machine, and/or
combinations of each to perform a function(s) or an action(s),
and/or to cause a function or action from another logic, method,
and/or system. Logic may include a microprocessor, a discrete logic
(e.g., ASIC), an analog circuit, a digital circuit, a programmed
logic device, a memory device containing instructions, and so on.
Logic may include one or more gates, combinations of gates, or
other circuit components. Where multiple logics are described, it
may be possible to incorporate the multiple logics into one
physical logic. Similarly, where a single logic is described, it
may be possible to distribute that single logic between multiple
physical logics.
[0066] While example systems, methods, and so on have been
illustrated by describing examples, and while the examples have
been described in considerable detail, it is not the intention of
the applicants to restrict or in any way limit the scope of the
appended claims to such detail. It is, of course, not possible to
describe every conceivable combination of components or
methodologies for purposes of describing the systems, methods, and
so on described herein. Therefore, the disclosure is not limited to
the specific details, the representative apparatus, and
illustrative examples shown and described. Thus, this application
is intended to embrace alterations, modifications, and variations
that fall within the scope of the appended claims.
[0067] To the extent that the term "includes" or "including" is
employed in the detailed description or the claims, it is intended
to be inclusive in a manner similar to the term "comprising" as
that term is interpreted when employed as a transitional word in a
claim.
[0068] To the extent that the term "or" is used in the detailed
description or claims (e.g., A or B) it is intended to mean "A or B
or both". When the applicants intend to indicate "only A or B but
not both" then the phrase "only A or B but not both" will be used.
Thus, use of the term "or" herein is the inclusive, and not the
exclusive use. See, Bryan A. Garner, A Dictionary of Modern Legal
Usage 624 (2d. Ed. 1995).
* * * * *