Codd's
twelve rules
are a set of thirteen rules proposed by Edgar F. Codd, a pioneer of the relational model for databases, designed to define what is required from
a database management system in order for it to be considered relational,
i.e., a relational database management system (RDBMS). They are known as ‘Codd’s Twelves Rules’ as follows-
Rule
(0):
The
system must qualify as relational, as a database, and as a management system. For a system to
qualify as a relational database management system (RDBMS), that system must use its relational facilities
(exclusively) to manage the database.
Rule
1:
The information rule:
All
information in a relational database (including table and column names) is
represented in only one way, namely as a value in a table.
Rule
2:
The guaranteed access rule:
All
data must be accessible. This rule is essentially a restatement of the
fundamental requirement for primary keys. It says that every
individual scalar value in the database must be logically addressable by
specifying the name of the containing table, the name of the
containing column and the primary key value of the containing row.
Rule
3:
Systematic treatment of null values:
The
DBMS must allow each field to remain null (or empty). Specifically, it must
support a representation of "missing information and inapplicable
information" that is systematic, distinct from all
regular values (for example, "distinct from zero or any other
number", in the case of numeric values), and independent of data type. It is also implied that such
representations must be manipulated by the DBMS in a systematic way.
The
system must support an online, inline, relational catalog that is accessible
to authorized users by means of their regular query language. That is, users
must be able to access the database's structure (catalog) using the same query
language that they use to access the database's data.
Rule
5:
The comprehensive data sublanguage rule:
The
system must support at least one relational language that Has a linear syntax Can be used both
interactively and within application programs, Supports data definition
operations (including view definitions), data manipulation operations (update
as well as retrieval), security and integrity constraints, and transaction management
operations (begin, commit, and rollback).
All
views that are theoretically updatable must be updatable by the system.
Rule
7:
High-level insert, update, and delete:
The
system must support set-at-a-time insert, update, and delete operators. This
means that data can be retrieved from a relational database in sets constructed
of data from multiple rows and/or multiple tables. This rule states that
insert, update, and delete operations should be supported for any retrievable
set rather than just for a single row in a single table.
Rule
8:
Physical data independence:
Changes
to the physical level (how the data is stored, whether in arrays or linked
lists etc.) must not require a change to an application based on the structure.
Rule
9:
Logical data independence:
Changes
to the logical level (tables, columns, rows, and so on) must not require a
change to an application based on the structure. Logical data independence is
more difficult to achieve than physical data independence.
Rule
10:
Integrity independence:
Integrity
constraints
must be specified separately from application programs and stored in the catalog. It must be
possible to change such constraints as and when appropriate without
unnecessarily affecting existing applications.
Rule
11:
Distribution independence:
The
distribution of portions of the database to various locations should be
invisible to users of the database. Existing applications should continue to
operate successfully :
when
a distributed version of the DBMS is first introduced; and
when
existing distributed data are redistributed around the system.
Rule
12:
The nonsubversion rule:
If
the system provides a low-level (record-at-a-time) interface, then that
interface cannot be used to subvert the system, for example, bypassing a
relational security or integrity constraint.
Difference between
SQL and SWL*Plus
SQL:
# A language
# ANSI standard
# Keywords cannot be abbreviated
# Statements manipulate data and table definitions
in the database
SQL*Plus:
# An environment
# Oracle proprietary
# Keywords can be abbreviated
# Commands do not allow manipulation of values in
the database
No comments:
Post a Comment