Category: 02. Relational Model

Relational database systems are not just about storing data; they also need to focus on maintaining the integrity and consistency of data during various operations.

In this chapter, we will take a close look at update operations, along with the concept of transactions, and strategies for handling constraint violations, with detailed examples for a better understanding.

Insert, Delete, and Update Operations

There are three major operations that we normally perform on a database –

• Insert − Adds new tuples to a table.
• Delete − Removes tuples from a table.
• Update (or Modify) − Changes the values in existing tuples.

The update operation in a database allows modifications to the existing values of one or more attributes within a relation. The goal is to maintain a consistent state that adheres to all integrity constraints.

All the three operations have the potential to breach the constraints defined in the database schema. Constraints such as key constraints, entity integrity, referential integrity, etc., are used for preserving data quality.

Operations and Constraint Violations

The insert operation is used to add a new record to a relation. However, it can trigger several constraint violations:

• Domain Constraint − If the data type or range of a value in an attribute is incorrect, this constraint is breached.
• Key Constraint − Violated when a primary key value in the new tuple matches an existing primary key.
• Entity Integrity − Cause error if a primary key in the new tuple contains a NULL value.
• Referential Integrity − Occurs when a foreign key references a non-existent value in the related table.

Consider we are attempting to insert the tuple:

<'Alicia','J','Zelaya','999887777','1960-04-05','6357 Windy Lane, Katy, TX', F,28000,'987654321',4>

into the EMPLOYEE table. In this case, a key constraint violation will occur if 999887777 already exists as a primary key.

The delete operation can violate referential integrity because the tuple being removed is referenced by foreign keys in other tables. For instance, deleting an employee whose ID is used in the WORKS_ON table would create orphaned records. This will disrupt data relationships. For example, deleting an EMPLOYEE with Ssn = ‘333445555’ could violate referential integrity because tuples in DEPARTMENT, WORKS_ON, and DEPENDENT might reference this employee.

Now, let’s check what kind of constraint violations might occur while updating a database. Updating the existing data can be complex, especially when altering primary keys or foreign keys. Modifying a primary key is equivalent to deleting the original record and inserting a new one, which may trigger key constraints or referential integrity issues. For example, updating the Dno (department number) of an EMPLOYEE record to a value that does not exist in the DEPARTMENT table results in a referential integrity violation.

Handling Constraint Violations

In this section, let’s understand how to handle the constraint violations that occur during the insert, delete, and update operations.

Handling Insertion Violations

When an insertion violates constraints, the most common response is to reject the insertion and notify the user. But, there are situations where DBMS can assist by suggesting corrective measures:

• Prompting for valid values − The DBMS might ask for a non-NULL value for primary keys if the violation is due to NULL entries.
• Proposing related tuple insertion − If referential integrity fails, the system may suggest inserting a corresponding record into the referenced table.

For example, attempting to insert an EMPLOYEE with a Dno value that does not exist can prompt the DBMS to suggest inserting a valid department first.

Handling Deletion Violations

Delete operations may also cause problems, primarily affecting referential integrity. The strategies to manage these violations are:

• Restrict − Prevents the deletion if it disrupts related records.
• Cascade − Automatically deletes all related tuples. This is useful when removing an entry that is referenced in multiple tables.
• Set NULL / Default − Changes foreign key references to NULL or a preset default value when the primary key is deleted.

For example, if an EMPLOYEE tuple with Ssn = ‘123456789’ is deleted, then the DBMS may set the Essn in WORKS_ON to NULL. This will avoid referential integrity breaches.

Managing Update Operation

Update operations can also breach constraints, particularly when modifying attributes tied to keys:

• Updating a primary key − The DBMS treats it like a combination of delete and insert. If other tables reference the original primary key, this may lead to referential integrity problems.
• Updating a foreign key − The DBMS must verify that the new value references an existing primary key or set it to NULL.

For example, changing an employee’s Ssn from ‘123456789’ to ‘987654321’ may lead to issues if ‘987654321’ is already in use as a primary key elsewhere.

Transactions and Their Importance

Along with database operations, another important concept is transactions. In a database context, a transaction is an atomic sequence of operations that includes reading or updating the data. Transactions ensure that operations are performed as a single unit, maintaining the database’s consistency.

Key properties of transactions include:

• Atomicity − Ensures that all parts of a transaction are completed; otherwise, none are applied.
• Consistency − Keeps the database in a valid state.
• Isolation − Transactions do not interfere with each other.
• Durability − Once a transaction is committed, changes are permanent.

For example, a bank transfer operation where one account is debited, and another is credited must either complete fully or revert to the initial state to prevent inconsistencies.

Handling Transactions in Practice

Transactions are nothing but a set of rules that follow certain behavior. Transactions often involve multiple steps that could individually violate constraints. Atomicity means the DBMS checks for violations at each step:

• Before committing − The DBMS verifies all constraints. If a violation is detected, the entire transaction rolls back to prevent partial changes.
• After a rollback − The database state returns to what it was before the transaction began, preserving data consistency.

For example, in an order processing system, a transaction might include checking stock availability, updating inventory, and recording the sale. If the stock update fails due to an inventory constraint, the entire transaction should revert.

Referential Integrity Violation

Let’s check a practical scenario of constraint violation. Consider the following UPDATE operation:

UPDATE EMPLOYEE SET Dno =10WHERE Ssn ='999887777';

If Dnumber = 10 does not exist in DEPARTMENT, then this update fails due to a referential integrity violation. The DBMS must check to ensure that relationships remain consistent.

Combining Strategies for Complex Violations

In some cases, a combination of cascade, set NULL, and restrict strategies might be applied based on specific needs:

• Cascade for deep deletions − When deleting a department, cascade deletes associated employees and projects.
• Set NULL for non-critical references − Updates foreign key values to NULL when the primary record is removed.
• Restrict for critical data − Prevents deletion if essential references are present, such as financial records.

Conclusion

In this chapter, we explained how update operations, transactions, and constraint handling are integral to maintaining data integrity in relational databases. We understood the importance of managing insert, delete, and update operations without violating any constraints. We also explored how the DBMS reacts to constraint violations with strategies like restrict, cascade, and set NULL. Additionally, we examined how transactions help ensure that changes maintain consistency and follow atomicity.

In a relational database model, the structure of data is maintained through a defined schema. A relational schema serves as the framework that outlines how data is organized and managed within a relational database. It includes attributes and the relationships between them. This framework ensures that data is stored in a way that maintains consistency and integrity.

In this chapter, we will explore relational database schemas in depth, understand key concepts through examples, and explain how constraints help maintain data reliability.

Relational Database Schema

A relational database schema, represented by S, acts as a map for how data is structured in the database. It consists of a set of relation schemas and a collection of integrity constraints.

The schema outlines how data interacts within and between tables. Each relation schema specifies the table’s name, its attributes, and their domains.

Components of a Schema

A relational schema has three major components:

• Relation Schema (R) − The structure of a table, written as R(A1, A2, …, An), where A1, A2, …, An are attributes.
• Attribute − A column within a table, each with a specific domain that limits the type of data it can contain.
• Database State (DB) − The current data held in all tables conforming to the schema. A valid state meets all schema constraints.

Example − Consider a relational schema for a COMPANY database:

• EMPLOYEE (Ssn, Name, Salary, Dno)
• DEPARTMENT (Dnumber, Dname, Mgr_ssn, Mgr_start_date)
• PROJECT (Pnumber, Pname, Plocation, Dnum)

Each relation schema outlines the columns of its respective table. It also indicates how data should be represented.

Relational Database Schemas – Key Features and Components

Let us now understand some of the key features and components of Relational Database Schemas:

Attributes and Their Domains

Every attribute within a relation schema has an associated domain that defines its allowable values. The domains enforce data type restrictions and value limits, ensuring consistency within the database.

Consider an example where the Ssn attribute in the EMPLOYEE table might be limited to a pattern that matches valid social security numbers (e.g., XXX-XX-XXXX). Similarly the Age attribute could be restricted to integer values between 18 and 65.

We know domains help prevent errors by ensuring the supplied data conforms to expected types and formats. So, an Age attribute defined with INTEGER CHECK (Age BETWEEN 18 AND 65) would block an insertion of Age = 17 or Age = 70.

Relation States

A relation state is the set of tuples (rows) that exist in a table at any given time. Each tuple must comply with the attribute domains defined in the schema.

For a better understanding, consider the following EMPLOYEE table with data:

Fname	Lname	Ssn	Salary	Dno
John	Smith	123456789	30000	5
Franklin	Wong	333445555	40000	5
Alicia	Zelaya	999887777	25000	4
Jennifer	Wallace	987654321	43000	4
Ramesh	Narayan	666884444	38000	5
Joyce	English	453453453	25000	5
Ahmad	Jabbar	987987987	25000	4
James	Borg	888665555	55000	1

For example, a tuple in the EMPLOYEE table might be represented as,

<John, Smith,123-45-6789,30000,5>

This tuple states that John Smith, identified by his Ssn, earns a salary of $30,000 and works in the department with Dno = 5. (We have removed other attributes for simplicity)

Integrity Constraints

Integrity constraints make sure that the data remains accurate and logically consistent. Integrity constraints include:

• Key Constraints − Enforce uniqueness for specified attributes, known as keys, so that no two tuples share the same values for these attributes.
• Entity Integrity − Ensures primary key attributes cannot have NULL values, maintaining the uniqueness and identifiability of each tuple.
• Referential Integrity − Ensures foreign keys match primary keys in related tables or are NULL.

Dname	Dnumber	Mgr_ssn	Mgr_start_date
Research	5	333445555	1988-05-22
Administration	4	987654321	1995-01-01
Headquarters	1	888665555	1981-06-19

In the COMPANY database, the Dno attribute in the EMPLOYEE table is a foreign key referencing the Dnumber attribute in the DEPARTMENT table. If an EMPLOYEE record has Dno = 5, Dnumber = 5 must exist in the DEPARTMENT table for referential integrity to hold.

Practical Examples of Relational Database Schemas

Let us go through the COMPANY database schema and see how the tables relate and enforce constraints.

Here is the PROJECT table:

Pname	Pnumber	Plocation	Dnum
ProductX	1	Bellaire	5
ProductY	2	Sugarland	5
ProductZ	3	Houston	5
Computerization	10	Stafford	4
Reorganization	20	Houston	1
Newbenefits	30	Stafford	4

• EMPLOYEE (Ssn, Name, Salary, Dno) − The Ssn attribute acts as the primary key, uniquely identifying each employee. The Dno attribute is a foreign key referencing Dnumber in the DEPARTMENT table.
• DEPARTMENT (Dnumber, Dname, Mgr_ssn, Mgr_start_date) − The Dnumber attribute is the primary key, uniquely identifying each department. The Mgr_ssn attribute references Ssn in the EMPLOYEE table, indicating which employee manages the department.
• PROJECT (Pnumber, Pname, Plocation, Dnum) − Pnumber serves as the primary key. Dnum is a foreign key referencing Dnumber in DEPARTMENT.

If an employee record is inserted with Dno = 10, but Dnumber = 10 does not exist in the DEPARTMENT table, the insertion will be rejected due to a referential integrity violation.

Super Keys and Candidate Keys

Super keys and candidate keys help identify unique tuples within a relation.

• The term “super key” is used for any combination of attributes that uniquely identifies a tuple.
• A candidate key is a minimal super key without redundant attributes.

Consider a CAR schema:

CAR (License_number, Engine_serial_number, Make, Model)

In this case,

• License_number is a candidate key, as it uniquely identifies each car.
• License_number, Engine_serial_number together is a superkey, but not minimal, so it is not a candidate key.

The Importance of Primary Keys

A primary key is nothing but a chosen candidate key. It must have unique, non-NULL values. This constraint ensures every record can be uniquely identified.

For example, Ssn is the primary key in the EMPLOYEE table. Trying to insert a record with Ssn = NULL will violate entity integrity, resulting in a rejected insertion.

Relationships and Foreign Keys

Foreign keys are attributes in one table that link to primary keys in another. Foreign keys are meant for creating relationship between tables. They help ensure consistency when dealing with related data.

Consider the WORKS_ON table with attributes Essn and Pno:

Essn	Pno	Hours
123456789	1	32.5
123456789	2	7.5
666884444	3	40.0
453453453	1	20.0
453453453	2	20.0
333445555	2	10.0
333445555	3	10.0
333445555	10	10.0
333445555	20	10.0
999887777	30	30.0
999887777	10	10.0
987987987	10	35.0
987987987	30	5.0
987654321	30	20.0
987654321	20	15.0
888665555	20	NULL

Essn references Ssn in EMPLOYEE, and Pno references Pnumber in PROJECT. This relationship defines which employees are working on which projects.

Violation Case − If an employee’s Ssn is deleted from EMPLOYEE but still exists as Essn in WORKS_ON, then referential integrity gets violated unless action is taken (e.g., cascading the delete or setting Essn to NULL).

Conclusion

To conclude, relational database schemas are foundational for defining how data is structured and managed. In this chapter, we highlighted the components of a schema, such as relation schemas, attributes, and their domains. Thereafter, we used the COMPANY schema to illustrate the importance of primary and foreign keys. We also understood how integrity constraints like entity and referential integrity help maintain data reliability.

Relational databases are widely used; they provide structured and reliable ways to store and access the data. To ensure data integrity and consistency, relational databases mostly rely on certain rules known as constraints. These constraints are used to maintain the quality and reliability of data across different tables and records.

In this chapter, we will take a look at the types of relational model constraints, supplemented with practical examples and explanations for a better understanding.

Relational Model Constraints

Relational model constraints are set of rules applied to the structure and data of a database to maintain logical consistency. They ensure that data is valid according to the rules defined in the database schema. These constraints can be broken down into three main types as given below −

• Inherent model-based constraints − Implied by the nature of the relational model itself.
• Schema-based constraints − Explicitly defined within the database schema and enforced by the database system.
• Application-based constraints − Managed through external application logic as they cannot be directly expressed in the schema.

Types of Relational Model Constraints

Relational model constraints can be of the following types −

• Domain Constraints
• Key Constraints
• Entity Integrity Constraint
• Referential Integrity Constraint

Let’s understand each of these in detail.

Domain Constraints

Domain constraints are used to specify that, every attribute in a database must contain only values from a predefined set known as domain. This ensures that each column in a table holds data of a particular type and format.

For example, consider an EMPLOYEE table with an Age column that only allows integer values between 18 and 65. This domain constraint ensures that inserting a value such as “17” or “70” would violate the rule and be rejected by the system.

If we define Age as INTEGER CHECK (Age BETWEEN 18 AND 65), any attempt to insert Age = 17 will trigger an error. The domain constraints is used to maintain data accuracy by preventing improper data types or out-of-bounds values.

Key Constraints

Key constraints are used for each record within a relation. It can be uniquely identified. This uniqueness is achieved through keys.

Keys can be of the following types −

• Superkey − Any set of attributes that uniquely identifies a tuple in a relation.
• Candidate key − A minimal superkey. Removing any attribute would break the uniqueness property.
• Primary key − A chosen candidate key that uniquely identifies each tuple in the table.

For example, consider a table called STUDENT as given below −

Name	SSN	Home Phone	Address	Office Phone	Age	GPA
Dick Davidson	422-11-2320	NULL	3452 Elgin Road	(817)749-1253	25	3.53
Barbara Benson	533-69-1238	(817)839-8461	7384 Fontana Lane	NULL	19	3.25
Rohan Panchal	489-22-1100	(817)376-9821	265 Lark Lane	(817)749-6492	28	3.93
Chung-cha Kim	381-62-1245	(817)375-4409	125 Kirby Road	NULL	18	2.89
Benjamin Bayer	305-61-2435	(817)373-1616	2918 Bluebonnet Lane	NULL	19	3.21

The SSN (Social Security Number) serves as a primary key because each student must have a unique SSN. The primary key constraint guarantees that no two students can have the same SSN.

This is important because the primary keys help to maintain the identity of each record. If a STUDENT table did not have a primary key, then distinguishing between duplicate records would be difficult, which will lead to a potential data ambiguity.

Entity Integrity Constraint

The entity integrity constraint states that, the primary key of a relation must always have a non-NULL value. It is needed because primary keys are used to identify tuples, and a NULL value would make identification impossible.

Consider a table called CUSTOMER. If Customer_ID is defined as the primary key, then any attempt to insert a record with “Customer_ID = NULL” will violet the entity integrity constraint. It will be rejected by the system.

Practically, we can consider a situation where a banking system has a Customer relation with primary keys representing account numbers. If one record had Account_ID = NULL, then it would be impossible to reference or link this record.

Referential Integrity Constraint

Referential integrity constraint states that, the relationships between tables remain consistent. A foreign key in one table must either match a primary key value in another table or be NULL. This constraint can preserve the logical connections between records in different tables.

Suppose we have an EMPLOYEE table with a Dno column. Here, it references the Dnumber from the DEPARTMENT table. If Dno is set to a value that does not exist in the DEPARTMENT table, then it violates the referential integrity constraint.

Detailed Scenario − See the Employee table −

Fname	Minit	Lname	SSN	Bdate	Address	Sex	Salary	Super_ssn	Dno
John	B	Smith	123456789	1965-01-09	731 Fondren, Houston, TX	M	30000	333445555	5
Franklin	T	Wong	333445555	1955-12-08	638 Voss, Houston, TX	M	40000	888665555	5
Alicia	J	Zelaya	999887777	1968-01-19	3321 Castle, Spring, TX	F	25000	987654321	4
Jennifer	S	Wallace	987654321	1941-06-20	291 Berry, Bellaire, TX	F	43000	888665555	4
Ramesh	K	Narayan	666884444	1962-09-15	975 Fire Oak, Humble, TX	M	38000	333445555	5
Joyce	A	English	453453453	1972-07-31	5631 Rice, Houston, TX	F	25000	333445555	5
Ahmad	V	Jabbar	987987987	1969-03-29	980 Dallas, Houston, TX	M	25000	987654321	4
James	E	Borg	888665555	1937-11-10	450 Stone, Houston, TX	M	55000	NULL	1

See the Department table −

Dname	Dnumber	Mgr_ssn	Mgr_start_date
Research	5	333445555	1988-05-22
Administration	4	987654321	1995-01-01
Headquarters	1	888665555	1981-06-19

Valid Insertion − Adding an EMPLOYEE with Dno = 4 is allowed if Dnumber = 4 exists in DEPARTMENT.

Violation Example − Inserting an EMPLOYEE with Dno = 99, where Dnumber = 99 does not exist in DEPARTMENT, would be rejected.

This constraint is particularly useful in maintaining relationships between parent and child tables. So, deleting a department referenced by employees must either be restricted or cascaded to maintain integrity.

Handling Constraint Violations

In this section, let’s understand the kind of operations that can cause constraint violations and what precautionary measures can be taken in order to prevent such operations.

Insertion Violations

An insertion operation can violate various constraints because of −

• Domain Constraint Violation − Inserting a non-integer value in an Age column defined as an integer will be rejected.
• Key Constraint Violation − Adding a tuple with a duplicate Ssn in a STUDENT table where Ssn is the primary key will result in an error.
• Entity Integrity Violation − Attempting to insert a row with NULL as the primary key value violates the entity integrity constraint.
• Referential Integrity Violation − Inserting an EMPLOYEE with a Dno value that does not match any Dnumber in DEPARTMENT.

Deletion and Referential Integrity

Deleting a tuple can trigger constraint violations, particularly for referential integrity. For example, deleting the DEPARTMENT record that is referenced by the Dno of an EMPLOYEE tuple results in referential integrity issues.

We can solve this issue by Restrict operation, like prevent deletion if it causes a violation. Or cascade, that is, automatically delete all dependent records. There is another solution: Set NULL / Default, i.e., modify the foreign key in dependent records to NULL or a default value.

Update Operations

Updating a record can affect primary keys and foreign keys. Modifying a primary key is similar to deleting the original record and inserting a new one, which may violate existing constraints. Updates can be two types:

• Safe Update − Changing an employee’s salary does not affect primary or foreign keys and is permissible.
• Risky Update − Modifying Ssn in EMPLOYEE to an existing Ssn violates the primary key constraint.

Other Constraints and Business Rules

We have studied the rules, but there are some other application-based constraints, or business rules. These rules include those that cannot be easily defined within the schema, such as −

• “An employee’s salary must not exceed that of their supervisor.”
• “Total weekly working hours for an employee should not exceed 56 hours.”

These are typically enforced using application logic or triggers.

Conclusion

In this chapter, we presented an elaborate explanation of how relational model constraints play a crucial role in maintaining data integrity and consistency in a database. We understood the different types of constraints, such as domain constraint, key constraint, entity integrity constraints, and referential integrity constraints. We discussed practical examples for these constraints in action. We also reviewed how constraint violations can be handled and the importance of application-based rules.

Relational data model is the primary data model, which is used widely around the world for data storage and processing. This model is simple and it has all the properties and capabilities required to process data with storage efficiency.

Concepts

Tables − In relational data model, relations are saved in the format of Tables. This format stores the relation among entities. A table has rows and columns, where rows represents records and columns represent the attributes.

Tuple − A single row of a table, which contains a single record for that relation is called a tuple.

Relation instance − A finite set of tuples in the relational database system represents relation instance. Relation instances do not have duplicate tuples.

Relation schema − A relation schema describes the relation name (table name), attributes, and their names.

Relation key − Each row has one or more attributes, known as relation key, which can identify the row in the relation (table) uniquely.

Attribute domain − Every attribute has some pre-defined value scope, known as attribute domain.

Constraints

Every relation has some conditions that must hold for it to be a valid relation. These conditions are called Relational Integrity Constraints. There are three main integrity constraints −

• Key constraints
• Domain constraints
• Referential integrity constraints

Key Constraints

There must be at least one minimal subset of attributes in the relation, which can identify a tuple uniquely. This minimal subset of attributes is called key for that relation. If there are more than one such minimal subsets, these are called candidate keys.

Key constraints force that −

• in a relation with a key attribute, no two tuples can have identical values for key attributes.
• a key attribute can not have NULL values.

Key constraints are also referred to as Entity Constraints.

Domain Constraints

Attributes have specific values in real-world scenario. For example, age can only be a positive integer. The same constraints have been tried to employ on the attributes of a relation. Every attribute is bound to have a specific range of values. For example, age cannot be less than zero and telephone numbers cannot contain a digit outside 0-9.

Referential integrity Constraints

Referential integrity constraints work on the concept of Foreign Keys. A foreign key is a key attribute of a relation that can be referred in other relation.

Referential integrity constraint states that if a relation refers to a key attribute of a different or same relation, then that key element must exist.

Dr Edgar F. Codd, after his extensive research on the Relational Model of database systems, came up with twelve rules of his own, which according to him, a database must obey in order to be regarded as a true relational database.

These rules can be applied on any database system that manages stored data using only its relational capabilities. This is a foundation rule, which acts as a base for all the other rules.

Rule 1: Information Rule

The data stored in a database, may it be user data or metadata, must be a value of some table cell. Everything in a database must be stored in a table format.

Rule 2: Guaranteed Access Rule

Every single data element (value) is guaranteed to be accessible logically with a combination of table-name, primary-key (row value), and attribute-name (column value). No other means, such as pointers, can be used to access data.

Rule 3: Systematic Treatment of NULL Values

The NULL values in a database must be given a systematic and uniform treatment. This is a very important rule because a NULL can be interpreted as one the following − data is missing, data is not known, or data is not applicable.

Rule 4: Active Online Catalog

The structure description of the entire database must be stored in an online catalog, known as data dictionary, which can be accessed by authorized users. Users can use the same query language to access the catalog which they use to access the database itself.

Rule 5: Comprehensive Data Sub-Language Rule

A database can only be accessed using a language having linear syntax that supports data definition, data manipulation, and transaction management operations. This language can be used directly or by means of some application. If the database allows access to data without any help of this language, then it is considered as a violation.

Rule 6: View Updating Rule

All the views of a database, which can theoretically be updated, must also be updatable by the system.

Rule 7: High-Level Insert, Update, and Delete Rule

A database must support high-level insertion, updation, and deletion. This must not be limited to a single row, that is, it must also support union, intersection and minus operations to yield sets of data records.

Rule 8: Physical Data Independence

The data stored in a database must be independent of the applications that access the database. Any change in the physical structure of a database must not have any impact on how the data is being accessed by external applications.

Rule 9: Logical Data Independence

The logical data in a database must be independent of its users view (application). Any change in logical data must not affect the applications using it. For example, if two tables are merged or one is split into two different tables, there should be no impact or change on the user application. This is one of the most difficult rule to apply.

Rule 10: Integrity Independence

A database must be independent of the application that uses it. All its integrity constraints can be independently modified without the need of any change in the application. This rule makes a database independent of the front-end application and its interface.

Rule 11: Distribution Independence

The end-user must not be able to see that the data is distributed over various locations. Users should always get the impression that the data is located at one site only. This rule has been regarded as the foundation of distributed database systems.

Rule 12: Non-Subversion Rule

If a system has an interface that provides access to low-level records, then the interface must not be able to subvert the system and bypass security and integrity constraints.