COMPLIANCE COMPONENT

DEFINITION
Name Database Management Systems Integrity Data Integrity is an umbrella term that refers to the consistency, accuracy, and correctness of data stored in a database. Data integrity is not about physical security, fault tolerance, or data preservation (backups). Think of data integrity in terms of the old adage: 'garbage in, garbage out'. Data integrity is about keeping the garbage out. There are four primary types of data integrity: entity, domain, referential, and user-defined. In general terms; entity integrity applies at the row level; domain integrity applies at the column level; and referential integrity applies at the table level. 1. Entity integrity ensures that each row in the table is uniquely identified. In other words, entity integrity ensures a table does not have any duplicate rows. 2. Domain integrity requires that a set of data values fall within a specific range (domain) in order to be valid. In other words, domain integrity defines the permissible entries for a given column by restricting the data type, format, or range of possible values. 3. Referential integrity is concerned with keeping the relationships between tables synchronized. 4. User-defined integrity refers to specific business rules not covered by the other integrity categories. It is typically implemented through triggers and stored procedures. Data integrity is enforced by features such as check constraints, triggers, views, stored procedures, user defined functions, and/or referential constraints. Maintaining Integrity of the data is a cornerstone function of the DBMS. Integrity constraints that the DBMS maintains are the business rules that are defined by the enterprise. The DBMS should have the capability to enforce data integrity for all the applications that use the data. Data integrity rules defined centrally in the database are independent from the applications that use the database. When data integrity is implemented directly on the database, the application developer does not need to worry about coding all of the data integrity features directly into the application. Potential problems associated with coding data integrity into the application are 1) additional programming required; 2) inconsistencies and potential errors; 3) it is difficult to make changes; and, 4) weaker security (i.e., it is easier to bypass).

Description

Rationale

Benefits

ASSOCIATED ARCHITECTURE LEVELS

Specify the Domain Name Specify the Discipline Name Specify the Technology Area Name Specify the Product Component Name Document the Compliance Component Type Component Sub-type Information Database Management Database Management Systems Relational Database Management Systems

COMPLIANCE COMPONENT TYPE

Standard

COMPLIANCE DETAIL
Entity Integrity Entity integrity ensures that each row in a table has a unique identifier that allows one row to be distinguished from another. Placing a primary key (PK) constraint on a specific column (although it can also be enforced with a UNIQUE constraint, a unique index, or the IDENTITY property) most often enforces entity integrity. The PK constraint forces each value inserted into a column (or combination of columns) to be unique; if a user attempts to insert a duplicate value into the column(s), the PK constraint will cause the insert to fail. A PK will not allow any Nulls to be inserted into the column(s) (A NULL entry would be disallowed even if it would be the only NULL in the column and therefore unique.). A PK is referred to as a ' surrogate key' if the column contains no real data other than a uniqueness identifier If real data can be used as a PK (e.g., a social security number), then it is referred to as an ' intelligent key'. There can be only one PK per table. A composite PK is a PK that consists of more than one column; it is used when none of the columns in the composite key is unique by itself. Thus, there can be only one PK in a table but the PK can consist of more than one column. If you need to enforce uniqueness on more than one column, use a PK constraint on one column and a UNIQUE constraint or IDENTITY property on any other columns that must not contain duplicates. Non-PK columns on which uniqueness is enforced are referred to as alternative keys or AKs; they get their name from the fact that they are 'alternatives' to the PK and as such, make good candidates for indexing or 'joining' on. Domain Integrity A domain in database terminology refers to a set of permissible values for a column (it should not be confused with an Internet or DNS 'domain' or a Windows NT 'domain'). Examples of domain integrity: correct data type; values that fall within the range supported by the system; null status; permitted size values. Domain integrity is sometimes referred to as 'attribute' integrity. Domain Integrity can be enforced with a DEFAULT constraint, FOREIGN KEY, CHECK constraint and data types. Data types limit fields to broad categories (e.g., integers). A default is a definition of a value that can be inserted into a column; a rule is a definition of acceptable values that can be inserted into a column. Rules and defaults are similar to constraints but are not ANSI standard; their continued use is not encouraged. Referential Integrity Referential integrity is typically enforced with a Primary Key (PK) and Foreign Key (FK) combination. A Foreign Key (FK) is a column or combination of columns in one table (referred to as the 'child table') that takes its values from the PK in another table (referred to as the 'parent table'). Note that while PK-FK combinations represent logical relationships among data, they do not necessarily limit the possible access paths through the data. In order for referential integrity to be maintained, the FK in the 'child' table can only accept values that exist in the PK of 'parent' table. The primary objective of referential integrity is to prevent 'orphans;' i.e., records in the child table that cannot be related to a record in the Parent table. Enforcing referential integrity means the relationship between the tables must be preserved when records are added (INSERT), changed (UPDATE), or deleted (DELETE). Although referential Integrity is often implemented with a PK-FK combination, database developers can also use triggers or stored procedures as well. There are three fundamental approaches to implementing referential integrity: 1) restrict

State the Guideline, Standard or Legislation

(disallow the data modification); 2) cascade (extend the data modification to related tables); or 3) nullify (set the values of matching FKs to NULL). Threats to Referential Integrity The UPDATE Threat to Referential Integrity UPDATEs can produce orphans when either the PK of the parent is changed or the FK of child is changed. In order to preserve referential integrity, the offending UPDATE can be disallowed; this happens automatically when a FK references a PK. Alternatively, the UPDATE can be 'cascaded' from the parent table to the child table. A third option for dealing the UPDATE threat is to set the FK values to NULL when the PK is changed; this is generally not a good solution. The INSERT Threat to Referential Integrity The INSERT threat only applies to data modifications to the child table. The INSERT threat involves adding records to the child table with no associated record in the parent table; again, the result is orphaned records. There are two ways to preserve referential integrity in the case of an INSERT: The INSERT can be disallowed; this is what happens automatically when a FK references a PK. Alternatively, the FK can be set to null (but, as with the UPDATE threat, this option is generally not a good idea). Note that unlike UPDATEs and DELETEs, INSERTs cannot be cascaded. The DELETE Threat to Referential Integrity The DELETE threat applies only to data modifications to the parent table. The DELETE threat involves deleting records in the parent table when there are matching records in the child table; as always, the result is orphaned records. Like UPDATEs, there are 3 ways to preserve referential integrity with a DELETE the offending DELETE can be disallowed; this happens automatically when a FK references a PK. Alternatively, the DELETE can be 'cascaded' from the parent table to the child table. The third (and bad) option for dealing the DELETE threat is to set the FK values to NULL when the PK is changed. User-Defined Integrity User-defined integrity refers to specific business rules not covered by the other integrity categories. It is typically implemented through triggers and stored procedures. Document Source Reference # N/A

Compliance Sources
Name Contact Information Name Contact Information Name Contact Information University of Texas Website http://www.utexas.edu/its/windows/d atabase/datamodeling/dm/integrity. html Microsoft Developer Network Website http://msdn.microsoft.com David R. Frick & Co. , CPA Website http://www.frick-cpa.com

KEYWORDS
List Keywords Referential integrity, user-defined integrity, domain integrity, entity integrity, data integrity, DB2, SQL Server, Oracle

COMPONENT CLASSIFICATION
Provide the Classification Sunset Date Emerging Current Twilight Sunset

COMPONENT SUB-CLASSIFICATION
Sub-Classification Technology Watch Variance Conditional Use Date Additional Sub-Classification Information

Rationale for Component Classification

Document the Rationale for Component Classification

Migration Strategy
Document the Migration Strategy

Impact Position Statement

Document the Position Statement on Impact

CURRENT STATUS
Provide the Current Status In Development Under Review Approved Rejected

AUDIT TRAIL
Creation Date Reason for Rejection Last Date Reviewed Reason for Update Last Date Updated 11-29-2004 Date Approved / Rejected 2-8-05