Unit 2

 Fundamentals of RDBMS:
 A Relational database management system (RDBMS) is a database
management system (DBMS) that is based on the relational model

 What is a table?
 Table is a collection of data which is organized in terms of rows and
columns.
 This table is basically a collection of related data entries and data is stored in
database objects.
 Example of a CUSTOMERS table which stores customer's ID, Name, Age,
Salary, City and Country

 What is a field?
 Every table is broken up into smaller segments called fields.
 A field in a table that is designed to maintain specific information about
every record in the table.
 For example, CUSTOMERS table consists of different fields like ID, Name,
Age, Salary, City and Country.

 What is a Record or a Row?

 A record is also called as a row of data where each individual entry that
exists in a table.
 Rows are horizontal elements in a table.

 What is a NULL value?

 A NULL value in a table is a value in a field that appears to be blank, which
means a field with no value.
 It is very important to understand that a NULL value is different than a zero
value or a field that contains spaces.
 Datatypes:
 SQL data types define the type of data that can be stored in a database
column.
 Data Type Properties

Numeric data These are used to store numeric values. Examples include
types INT,BIGINT,DECIMAL, and FLOAT.

Character data These are used to store character strings. Examples include
types CHAR, VARCHAR, and TEXT.

These are used to store date and time values. Examples

Date and time include
data types DATE,TIME, and TIMESTAMP
.

Binary It has a maximum length of 8000 bytes. It contains fixed-

length binary data.

Boolean data This data type is used to store logical values. The only
type possible values are TRUE and FALSE.
  Dr Edgar F Codd’s Twelve Commandments

Rule 0: The Foundation Rule

 The database must be in relational form. So that the system can handle the
database through its relational capabilities.

Rule 1: Information Rule

 A database contains various information, and this information must be
stored in each cell of a table in the form of rows and columns.

 Everything in database must be stored in the tabular format

Rule 2: Guaranteed Access Rule

Every single data (atomic value) may be accessed logically from a relational
database using the combination of primary key value, table name, and column
name.

Rule 3: Systematic Treatment of Null Values

 This rule defines the systematic treatment of Null values in database records.

 The null value has various meanings in the database, like missing the data,
no value in a cell

 It should allow a field to remain empty.

 But the primary key should not be null.

Rule 4: Active Online Catalog

 The structure description (Table attribute, name, size) of the entire database
must be stored in online catalog known as data dictionary, which can be
accessed by authorized users.
 Same query language is used to access catalog, which they are using for
database access.
Rule 5: Comprehensive Data Sub Language Rule

 Data sub language rule states that database needs to support minimum one
clearly defined language.

 This language should be capable of handling data definition, view definition,

data manipulation, integrity constraints, and transaction management
operations.

 If the database allows access to the data without any language, it is

considered a violation of the database.

Rule 6: View Updating Rule

 All views table can be theoretically updated and must be practically updated
by the database systems.
Rule 7: Relational Level Operation (High-Level Insert, Update and delete)
Rule

A database system should follow high-level relational operations such as insert,

update, and delete in each level or a single row. It also supports union, intersection
and minus operation in the database system.

Rule 8: Physical Data Independence Rule

All stored data in a database or an application must be physically independent to

access the database. Each data should not depend on other data or an application. If
data is updated or the physical structure of the database is changed, it will not show
any effect on external applications that are accessing the data from the database.

Rule 9: Logical Data Independence Rule

It is similar to physical data independence. It means, if any changes occurred to the

logical level (table structures), it should not affect the user's view (application). For
example, suppose a table either split into two tables, or two table joins to create a
single table, these changes should not be impacted on the user view application.

Rule 10: Integrity Independence Rule

A database must maintain integrity independence when inserting data into table's
cells using the SQL query language. All entered values should not be changed or
rely on any external factor or application to maintain integrity. It is also helpful in
making the database-independent for each front-end application.

Rule 11: Distribution Independence Rule

The distribution independence rule represents a database that must work properly,
even if it is stored in different locations and used by different end-users. Suppose a
user accesses the database through an application; in that case, they should not be
aware that another user uses particular data, and the data they always get is only
located on one site. The end users can access the database, and these access data
should be independent for every user to perform the SQL queries.

Rule 12: Non Subversion Rule

The non-submersion rule defines RDBMS as a SQL language to store and

manipulate the data in the database. If a system has a low-level or separate
language other than SQL to access the database system, it should not subvert or
bypass integrity to transform data.

Key Concepts:
 Primary Key: A primary key is used as a unique identifier to quickly identify
data within the table.
 A table cannot have more than one primary key.
 It must contain a unique value for each row of data.

 It cannot contain null values.

 Every row must have a primary key value.

 Example: In the case of a student when identification needs to be done in

the class, the roll number of the student plays the role of Primary key.
 Query: CREATE TABLE Persons (
ID int NOT NULL PRIMARY KEY,
FirstName varchar(255),
Age int
);

At column level:

 <column_name><datatype> Primary key;

  At table level:
 Primary key(<column_name1>[,column_name>]....);

 Foreign Key: Foreign key (FK) is a column that is used to establish a link
between the data in two tables.
 A FOREIGN KEY is a field (or collection of fields) in one table, that refers
to the PRIMARY KEY in another table.
 The table with the foreign key is called the child table, and the table with the
primary key is called the referenced or parent table.
 nsider two tables Student and Department having their respective attributes as
shown in the below table structure:
 Example:
  In the tables, one attribute, you can see, is common, that is Stud_Id, but it has
different key constraints for both tables.
 In the Student table, the field Stud_Id is a primary key because it is uniquely
identifying all other fields of the Student table.
 On the other hand, Stud_Id is a foreign key attribute for the Department table
because it is acting as a primary key attribute for the Student table.
 It means that both the Student and Department table are linked with one
another because of the Stud_Id attribute.
 In the below-shown figure, you can view the following structure of the
relationship between the two tables.

Query: CREATE TABLE Department (

Dept_name varchar (120) NOT NULL,
Stud_Id int,
FOREIGN KEY (Stud_Id) REFERENCES Student (Stud_Id));

 Candidate Key: A candidate key is a subset of a super key set where the key
which contains no redundant attribute is none other than a Candidate Key.

 How a Candidate key is different from a Primary Key

 Although the purpose of both candidate and the primary key is the same, that
is to uniquely identify the tuples, and then also they are different from each
other.
 It is because, in a table, we can have one or more than one candidate key, but
we can create only one primary key for a table.

 Thus, from the number of obtained candidate keys, we can identify the
appropriate primary key. However, if there is only one candidate key in a
table, then it can be considered for both key constraints.