UNIT-1

CHAPTER 1.1

Lecture-1.4 (Referential Data Structure, Schema, Instances

and Keys)

Relational Data Model

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

1. 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.
2. Tuple − A single row of a table, which contains a single record for that relation is
called a tuple.
3. Relation instance − A finite set of tuples in the relational database system represents
relation instance. Relation instances do not have duplicate tuples.
4. Relation schema − A relation schema describes the relation name (table name),
attributes, and their names.
5. Relation key − Each row has one or more attributes, known as relation key, which
can identify the row in the relation (table) uniquely.
6. Attribute domain − Every attribute has some pre-defined value scope, known as
attribute domain.
Database Schema

A database schema is the skeleton structure that represents the logical view of the entire
database. It defines how the data is organized and how the relations among them are
associated. It formulates all the constraints that are to be applied on the data.

A database schema defines its entities and the relationship among them. It contains a
descriptive detail of the database, which can be depicted by means of schema diagrams. It’s
the database designers who design the schema to help programmers understand the database
and make it useful.

A database schema can be divided broadly into two categories −

 Physical Database Schema − This schema pertains to the actual storage of data and
its form of storage like files, indices, etc. It defines how the data will be stored in a
secondary storage.

 Logical Database Schema − This schema defines all the logical constraints that need
to be applied on the data stored. It defines tables, views, and integrity constraints.
Definition of schema: Design of a database is called the schema. Schema is of three types:
Physical schema, logical schema and view schema.

For example: In the following diagram, we have a schema that shows the relationship
between three tables: Course, Student and Section. The diagram only shows the design of the
database, it doesn’t show the data present in those tables. Schema is only a structural
view(design) of a database as shown in the diagram below.

The design of a database at physical level is called physical schema, how the data stored in
blocks of storage is described at this level.

Design of database at logical level is called logical schema, programmers and database
administrators work at this level, at this level data can be described as certain types of data
records gets stored in data structures, however the internal details such as implementation of
data structure is hidden at this level (available at physical level).

Design of database at view level is called view schema. This generally describes end user
interaction with database systems.
Database Instance

It is important that we distinguish these two terms individually. Database schema is the
skeleton of database. It is designed when the database doesn't exist at all. Once the database is
operational, it is very difficult to make any changes to it. A database schema does not contain
any data or information.

A database instance is a state of operational database with data at any given time. It contains
a snapshot of the database. Database instances tend to change with time. A DBMS ensures
that its every instance (state) is in a valid state, by diligently following all the validations,
constraints, and conditions that the database designers have imposed.

Definition of instance: The data stored in database at a particular moment of time is called
instance of database. Database schema defines the variable declarations in tables that belong
to a particular database; the value of these variables at a moment of time is called the instance
of that database.

For example, lets say we have a single table student in the database, today the table has 100
records, so today the instance of the database has 100 records. Lets say we are going to add
another 100 records in this table by tomorrow so the instance of database tomorrow will have
200 records in table. In short, at a particular moment the data stored in database is called the
instance, that changes over time when we add or delete data from the database.

Keys

Key plays an important role in relational database; it is used for identifying unique rows from
table. It also establishes relationship among tables.

Types of keys in DBMS

 Primary Key:– A primary is a column or set of columns in a table that uniquely

identifies tuples (rows) in that table.
 Super Key: – A super key is a set of one of more columns (attributes) to uniquely
identify rows in a table.
 Candidate Key :– A super key with no redundant attribute is known as candidate key
 Alternate Key:– Out of all candidate keys, only one gets selected as primary key,
remaining keys are known as alternate or secondary keys.
 Composite Key:– A key that consists of more than one attribute to uniquely identify
rows (also known as records & tuples) in a table is called composite key.
  Foreign Key: – Foreign keys are the columns of a table that points to the primary key
of another table. They act as a cross-reference between tables.

Primary key in DBMS

Definition: A primary key is a minimal set of attributes (columns) in a table that uniquely
identifies tuples (rows) in that table.

Primary Key Example in DBMS

Lets take an example to understand the concept of primary key. In the following table, there
are three attributes: Stu_ID, Stu_Name & Stu_Age. Out of these three attributes, one attribute
or a set of more than one attributes can be a primary key.

 Attribute Stu_Name alone cannot be a primary key as more than one students can
have same name.

 Attribute Stu_Age alone cannot be a primary key as more than one students can have
same age.

 Attribute Stu_Id alone is a primary key as each student has a unique id that can
identify the student record in the table.

Note: In some cases an attribute alone cannot uniquely identify a record in a table, in that
case we try to find a set of attributes that can uniquely identify a row in table. We will see the
example of it after this example.

Table Name: STUDENT

Stu_Id Stu_Name Stu_Age

101 Steve 23

102 John 24

103 Robert 28

104 Steve 29

105 Carl 29

Points to Note regarding Primary Key

 We denote usually denote it by underlining the attribute name (column name).

  The value of primary key should be unique for each row of the table. The column(s)
that makes the key cannot contain duplicate values.

 The attribute(s) that is marked as primary key is not allowed to have null values.

 Primary keys are not necessarily to be a single attribute (column). It can be a set of
more than one attributes (columns). For example {Stu_Id, Stu_Name} collectively
can identify the tuple in the above table, but we do not choose it as primary key
because Stu_Id alone is enough to uniquely identifies rows in a table and we always
go for minimal set. Having that said, we should choose more than one columns as
primary key only when there is no single column that can uniquely identify the tuple
in table.

How to define primary key in RDBMS?

In the above example, we already had a table with data and we were trying to understand the
purpose and meaning of primary key, however you should know that generally we define the
primary key during table creation. We can define the primary key later as well but that rarely
happens in the real world scenario.

Lets say we want to create the table that we have discussed above with the customer id and
product id set working as primary key. We can do that in SQL like this:

Create table STUDENT

Stu_Id int primary key,

Stu_Name varchar(255) not null,

Stu_Age int not null);

Super key in DBMS

Definition of Super Key in DBMS: A super key is a set of one or more attributes (columns),
which can uniquely identify a row in a table. Often some students are confused between super
key and candidate key, so we will also discuss candidate key and its relation with super key
in this.
How candidate key is different from super key?

Answer is simple – Candidate keys are selected from the set of super keys, the only thing we
take care while selecting candidate key is: It should not have any redundant attribute. That’s
the reason they are also termed as minimal super key.

Let’s take an example to understand this:

Table: Employee

Emp_SSN Emp_Number Emp_Name

--------- ---------- --------

123456789 226 Steve

999999321 227 Ajeet

888997212 228 Chaitanya

777778888 229 Robert

Super keys: The above table has following super keys. All of the following sets of super key
are able to uniquely identify a row of the employee table.

 {Emp_SSN}

 {Emp_Number}

 {Emp_SSN, Emp_Number}

 {Emp_SSN, Emp_Name}

 {Emp_SSN, Emp_Number, Emp_Name}

 {Emp_Number, Emp_Name}

Candidate Keys: As I mentioned in the beginning, a candidate key is a minimal super key
with no redundant attributes. The following two set of super keys are chosen from the above
sets as there are no redundant attributes in these sets.

 {Emp_SSN}

 {Emp_Number}
Only these two sets are candidate keys as all other sets are having redundant attributes that
are not necessary for unique identification.

Super key vs Candidate Key

I have been getting lot of comments regarding the confusion between super key and candidate
key. Let me give you a clear explanation.

1. First you have to understand that all the candidate keys are super keys. This is because the
candidate keys are chosen out of the super keys.
2. How we choose candidate keys from the set of super keys? We look for those keys from
which we cannot remove any fields. In the above example, we have not chosen
{Emp_SSN, Emp_Name} as candidate key because {Emp_SSN} alone can identify a
unique row in the table and Emp_Name is redundant.

Primary Key:

A Primary key is selected from a set of candidate keys. This is done by database admin or
database designer. We can say that either {Emp_SSN} or {Emp_Number} can be chosen as a
primary key for the table Employee.

Candidate Key in DBMS

Definition of Candidate Key in DBMS: A Super Key with no redundant attribute is known
as candidate key. Candidate keys are selected from the set of super keys, the only thing we
take care while selecting candidate key is that the candidate key should not have any
redundant attributes. That’s the reason they are also termed as minimal super key.

Candidate Key Example

Lets take an example of table “Employee”. This table has three attributes: Emp_Id,
Emp_Number & Emp_Name. Here Emp_Id & Emp_Number will be having unique values
and Emp_Name can have duplicate values as more than one employees can have same name.

Emp_Id Emp_Number Emp_Name

------ ---------- --------

E01 2264 Steve

E22 2278 Ajeet

E23 2288 Chaitanya

E45 2290 Robert

How many super keys the above table can have?

1. {Emp_Id}

2. {Emp_Number}

3. {Emp_Id, Emp_Number}

4. {Emp_Id, Emp_Name}

5. {Emp_Id, Emp_Number, Emp_Name}

6. {Emp_Number, Emp_Name}

Lets select the candidate keys from the above set of super keys.

1. {Emp_Id} – No redundant attributes

2. {Emp_Number} – No redundant attributes

3. {Emp_Id, Emp_Number} – Redundant attribute. Either of those attributes can be a

minimal super key as both of these columns have unique values.

4. {Emp_Id, Emp_Name} – Redundant attribute Emp_Name.

5. {Emp_Id, Emp_Number, Emp_Name} – Redundant attributes. Emp_Id or Emp_Number

alone are sufficient enough to uniquely identify a row of Employee table.

6. {Emp_Number, Emp_Name} – Redundant attribute Emp_Name.

The candidate keys we have selected are:

{Emp_Id}

{Emp_Number}

Note: A primary key is selected from the set of candidate keys. That means we can either
have Emp_Id or Emp_Number as primary key. The decision is made by DBA (Database
administrator)
Foreign key in DBMS

Definition: Foreign keys are the columns of a table that points to the primary key of another
table. They act as a cross-reference between tables.

For example:

In the below example the Stu_Id column in Course_enrollment table is a foreign key as it
points to the primary key of the Student table.

Course_enrollment table:

Course_Id Stu_Id

C01 101

C02 102

C03 101

C05 102

C06 103

C07 102

Student table:

Stu_Id Stu_Name Stu_Age

101 Chaitanya 22

102 Arya 26

103 Bran 25

104 Jon 21

Note: Practically, the foreign key has nothing to do with the primary key tag of another table,
if it points to a unique column (not necessarily a primary key) of another table then too, it
would be a foreign key. So, a correct definition of foreign key would be: Foreign keys are the
columns of a table that points to the candidate key of another table.
Composite key in DBMS

Definition of Composite key: A key that has more than one attributes is known as composite
key. It is also known as compound key.

Note: Any key such as super key, primary key, candidate key etc. can be called composite
key if it has more than one attributes.

Composite key Example

Lets consider a table Sales. This table has four columns (attributes) – cust_Id, order_Id,
product_code & product_count.

Table – Sales

cust_Id order_Id product_code product_count

-------- -------- ------------ -------------

C01 O001 P007 23

C02 O123 P007 19

C02 O123 P230 82

C01 O001 P890 42

None of these columns alone can play a role of key in this table.

Column cust_Id alone cannot become a key as a same customer can place multiple orders,
thus the same customer can have multiple entires.

Column order_Id alone cannot be a primary key as a same order can contain the order of
multiple products, thus same order_Id can be present multiple times.

Column product_code cannot be a primary key as more than one customers can place order
for the same product.

Column product_count alone cannot be a primary key because two orders can be placed for
the same product count.

Based on this, it is safe to assume that the key should be having more than one attributes:

Key in above table: {cust_id, product_code}

This is a composite key as it is made up of more than one attributes.

Alternate key in DBMS

As we have seen in the candidate key guide that a table can have multiple candidate keys.
Among these candidate keys, only one key gets selected as primary key, the remaining keys
are known as alternative or secondary keys.

Alternate Key Example

Lets take an example to understand the alternate key concept. Here we have a table
Employee, this table has three attributes: Emp_Id, Emp_Number & Emp_Name.

Table: Employee/strong>

Emp_Id Emp_Number Emp_Name

------ ---------- --------

E01 2264 Steve

E22 2278 Ajeet

E23 2288 Chaitanya

E45 2290 Robert

There are two candidate keys in the above table:

{Emp_Id}

{Emp_Number}

DBA (Database administrator) can choose any of the above key as primary key. Lets say
Emp_Id is chosen as primary key.

Since we have selected Emp_Id as primary key, the remaining key Emp_Number would be
called alternative or secondary key.
OTHER REFRENCES

 Instance and schema in DBMS (beginnersbook.com)

 DBMS - Data Schemas - Tutorialspoint

 Primary key in DBMS (beginnersbook.com)

 Alternate key in DBMS (beginnersbook.com)

SUGGESTED BOOK REFERENCES

1. J. Date, “An Introduction to DatabaseSystems”, Addison Wesley.

2. Ramez Elmasri and Shamkant B. Navathe,“Fundamentals of Database System”, The

Benjamin / Cummings Publishing Co.

3. Korth and Silberschatz Abraham, “DatabaseSystem Concepts”, McGraw Hall.

4. Pratt,”DBMS”, Cengage Learning.

5. Navathe,“Fundamentals of Database System”, The Benjamin / Cummings Publishing

Co.