Coded rule

Rule 0: The Foundation Rule

The DB must be structured in a relational manner so that the system’s relational capabilities can
manage the DB.

Rule 1: The Information Rule

A DB comprises a variety of data, which must be recorded in the form of columns and rows in each
and every cell of a table.

Rule 2: The Guaranteed Access Rule

A relational DB’s primary key value, column name, and table name can be used to conceptually
retrieve any single or precise data (the atomic value).

Rule 3: The Systematic Treatment of Null Values

The treatment of Null values in DB records is defined by this rule. No value in a cell, missing data,
unsuitable information, unknown data, the primary key that should not be null, etc., are all examples
of null values in DBs.

Rule 4: The Dynamic/Active Online Catalog on the basis of the Relational Model

A DB dictionary is a logical representation of the whole logical structure of a descriptive DB that

needs to be stored online. It grants users access to the DB and uses a query language that is
comparable to that of the DB.

Rule 5: The Comprehensive Data SubLanguage Rule

The relational DB supports a variety of languages, and in order to access the DB, the language has to
be linear, explicit, or a well-defined syntax, character strings. It must support the following
operations: view definition, integrity constraints, data manipulation, data definition, as well as limit
transaction management. It is considered a DB violation if the DB permits access to the data and
information without the use of any language.

Rule 6: The View Updating Rule

A view table can theoretically be updated, and DB systems must update them in practice.
Rule 7: The Relational Level Operation (or High-Level Insert, Delete, and Update) Rule

In each level or single row, a DB system should adhere to high-level relational operations (for
example, update, insert, and delete). The DB system also includes operations like intersection, union,
and minus.

Rule 8: The Physical Data Independence Rule

To access a DB or an application, all stored data must be independent physically. Each piece of data
should not be reliant on another piece of data or an application. External applications that access
data from the DB will have no effect if data is altered or the physical structure of a given DB is
modified.

Rule 9: The Logical Data Independence Rule

It’s similar to the independence of physical data. It indicates that any modifications made at the
logical level (or the table structures) should not have an impact on the user’s experience
(application). For example, if a table is split into two separate tables or into two table joins in order
to produce a single table, the application at the user view should not be affected.

Rule 10: The Integrity Independence Rule

When we are using SQL to put data into table cells, a DB must guarantee integrity independence. All
the entered values must not be changed, and the integrity of the data should not be reliant on any
external component or application. It’s also useful for making each front-end app DB-independent.

Rule 11: The Distribution Independence Rule

This rule denotes that a DB must function properly even if it’s stored in multiple locations and used
by various end-users. Let’s say a person uses an application to access the DB. In such a case, they
must not be aware that another user is using the same data, and thus, the data they always obtain is
only available on one site. The DB can be accessed by end-users, and each user’s access data must
be independent in order for them to run SQL queries.

Rule 12: The Non-Subversion Rule

RDBMS is defined by this rule as a SQL language for storing and manipulating data in a DB. If a
system uses a low-level or different language to access the DB system other than SQL, it should not
bypass or subvert data integrity.
Data Models
Data Model is the modeling of the data description, data semantics, and consistency
constraints of the data. It provides the conceptual tools for describing the design of a
database at each level of data abstraction. Therefore, there are following four data
models used for understanding the structure of the database:

1) Relational Data Model: This type of model designs the data in the form of rows and
columns within a table. Thus, a relational model uses tables for representing data and in-
between relationships. Tables are also called relations. This model was initially
described by Edgar F. Codd, in 1969. The relational data model is the widely used
model which is primarily used by commercial data processing applications.

2) Entity-Relationship Data Model: An ER model is the logical representation of data

as objects and relationships among them. These objects are known as entities, and
relationship is an association among these entities. This model was designed by Peter
Chen and published in 1976 papers. It was widely used in database designing. A set of
attributes describe the entities. For example, student_name, student_id describes the
'student' entity. A set of the same type of entities is known as an 'Entity set', and the set
of the same type of relationships is known as 'relationship set'.

3) Object-based Data Model: An extension of the ER model with notions of functions,

encapsulation, and object identity, as well. This model supports a rich type system that
includes structured and collection types. Thus, in 1980s, various database systems
following the object-oriented approach were developed. Here, the objects are nothing
but the data carrying its properties.

4) Semistructured Data Model: This type of data model is different from the other three
data models (explained above). The semistructured data model allows the data
specifications at places where the individual data items of the same type may have
different attributes sets. The Extensible Markup Language, also known as XML, is widely
used for representing the semistructured data. Although XML was initially designed for
including the markup information to the text document, it gains importance because of its
application in the exchange of data.