Introduction to DBMS

&
ER-Diagram
Rishu Gupta & Manish Srivastava
Database System Overview
Data

● Data is a collection of facts about the object of

interest. It is the description of an object. For e.g.
marks, grade etc.
● Data is raw, just a set of facts which by itself does
not convey anything. To understand data, we need
to identify patterns on the basis of data. This
pattern is called as information. For e.g.A Grade
● Combination of Data and Information, gives
knowledge. For e.g. Toper

Rishu Gupta & Manish Srivastava

Requirements from Data
Following type of requirements can be concluded from following:

● Integrity : data accuracy

● Availability : when required, it should be available
● Security : data accessibility should be secure
● Independent of Application : data can be access from anywhere
● Concurrent : many users can access data at the same time

Flat files drawback

● File based data is dependent on format of data.
● Data accessing is difficult.
● Data loss on concurrent access
● Less secured
● Data duplicacy
Rishu Gupta & Manish Srivastava
Database
● A database is a collection of information
related to a particular subject or purpose. For
e.g. tracking customer orders, student exam
records, etc. .
● A Database Management System is a software
system that enables users to create, insert,
delete, maintain, and control access to the
database.
● An Application Program interacts with a
database by giving an appropriate request (a
SQL statement)

Rishu Gupta & Manish Srivastava

Types of DBMS
It is categorised into four types :

1. Hierarchical: It organize data into a tree-

like structure. Data is stored as records
which are connected to one another
through parent child relationships.

Rishu Gupta & Manish Srivastava

Types of DBMS

2. Network: It organize data into a

graph structure in which object
types are nodes and relationship
types are arcs. Each record can
have multiple parent and child
records.
3. Relational : Relational Databases
organizes data into one or more
tables. A table consists of
attributes (columns), tuples
(rows) and provides a way to
uniquely identify each tuple.
Tables are related to each other
through parent child
relationships.

Rishu Gupta & Manish Srivastava

Types of DBMS

4. NoSql : NoSQL (Not only SQL) database uses key-

value, graph or document data structures to store
data. These databases aim for simplicity of design,
horizontal scaling and finer control over availability.
Some examples on No Sql databases are Cassandra,
MongoDB, CouchDB, OrientDB, HBASE etc.

Additionally there are other databases types as well like

Object Oriented databases e.g. DB4O and ZopeDB, Graph
Databases e.g. Neo4J and InfiniteGraph etc.

Relational databases are the most widely used database in

the current times.

Rishu Gupta & Manish Srivastava

Basic steps in designing a database system
Steps:

1. Development of an ER Diagram - Pictorial documentation of the given scenario.

2. Conversion of ERD into tables as recommended by ERD.
3. Normalization - removes redundancy and anomalies. Leads to an optimized structure of tables.

We Will create actual tables by running SQL queries.

Rishu Gupta & Manish Srivastava

Entity-Relationship Model (E-R Model)
● An Entity may be an object representing something having a physical existence. For example a
particular person, car, house, or an employee. Or it may be an object representing something
conceptual. For example a company, a job, or a university course.
● An Entity type is a collection of entities.
● The collection of entities in an entity type is known as Entity set.
● ER model is a graphical representation of entities and their relationships which helps in understanding
data independent of the actual database implementation.
● Each entity has a set of properties. These properties are termed as attributes.

Rishu Gupta & Manish Srivastava

Example: Terminologies Symbol

Entity type Rectangle

Employee have following features: employee id,
employee name, employee age, salary.
Attribute Oval
Entity type: Employee

Id
Attributes: Id, EName, EAge, Salary

EName

EAge
Employee

Salary

Rishu Gupta & Manish Srivastava

Relational Model
● Relational Databases store data in relations i.e. tables. Each relation must have a name.
■ Relation is usually represented as Employee(Id, EName, EAge, Salary )
● An attribute is a column name of a relation.
■ It stores a specific information about an object e.g. salary.
● A tuple is a row in a relation. It represents relationship between attributes that can contain single
value. Row, record and tuple is a similar term.
● Cardinality of relation/table is the number of rows it contains. e.g. Cardinality of relation below is 3.

Employee

EName ID EAge Salary

John E1 32 7L

James E2 28 8L

John E3 32 5L
Rishu Gupta & Manish Srivastava
Relational Model

● Degree of relation is the number of attributes it contains. e.g. Degree of relation below is 4.

● NULL represents the value of an attribute that is currently unknown or not applicable.

● A domain is the set of allowable values for one or more attributes. E.g. EAge Domain(28,29,30,31,32)

● A collection of relations with distinct relation names is called as Relational Model.

EName ID EAge Salary

John E1 32 7L

James E2 28 8L

John E3 32 NULL

Rishu Gupta & Manish Srivastava

Key
● Super Key. Any combination of attributes including the identifying attribute(s) will be a super key.

● Composite Key: Any combination of more than one attribute that can uniquely identify an entity in its
entity set.

● Candidate Key: All those super keys that, if broken down further, will no longer be able to uniquely
identify the entity in its entity set. All the candidate keys are “candidate” to be designated as Primary
Key.

● Primary Key: We can choose any appropriate candidate key as Primary Key. Candidate key consists of
one or more attributes, none of the constituent attribute should be null.

● Foreign Key: A foreign key is a set of one or more columns in the child table whose values are
required to match with corresponding columns in the parent table. Foreign key columns on child
tables must be primary key or unique on the parent table. The child table can contain NULL values.
Let us take Employee and Computer tables as provided below

Rishu Gupta & Manish Srivastava

Candidate key
● All those super keys that, if broken down further, will no longer be able to uniquely identify the entity
in its entity set. All the candidate keys are “candidate” to be designated as Primary Key.

For e.g. try to identify some candidate keys for below relation:
Employee(EmployeeNo, Name, AadharNo, Salary, DateOfBirth)

Thus the choice of candidate key depends upon the business context. Rishu Gupta & Manish Srivastava
 Primary Key
It is the candidate key that is selected to uniquely identify a tuple in a relation. The mandatory and desired
attributes for a primary key are:

E.g. Employee(EmployeeNo, Name, AadharNo, Salary, DateofBirth)

When two or more columns together identify the unique row then it's referred to as Composite Primary Key.
The combination of Name and DateOfBirth if selected as a primary key would be a composite primary key.

Rishu Gupta & Manish Srivastava

Foreign Key
● A foreign key is a set of one or more columns in the child table whose values are required to match
with corresponding columns in the parent table. Foreign key columns on child tables must be primary
key or unique on the parent table. The child table can contain NULL values. Let us take Employee and
Computer tables as provided below:

● Computer is the parent table with CompId as the primary key. Employee is the child table with Id as
the primary key. If we want to allocate a maximum of one computer to an employee then CompId
must be made the foreign key in the Employee table. It can only contain values that are present in
Computer table or no values at all. We cannot allocate a computer that does not exist to an
employee.
● Additionally multiple rows in the child table can link to the same row of the parent table depending
upon the type of relationship.
Rishu Gupta & Manish Srivastava
Crow foot notation
● Crow foot notation is one of the ways to represent
cardinality of relationship in an ER Model. The notation
comprises of four symbols and one of them need to be
used for each entity in a relationship.

● For e.g. the relationship between employee and computer

is such that a computer must be allocated to one and only Employe
one employee but an employee can be allocated zero or Compute
e
any number of computers. Such a relationship is r
represented by the diagram below: ID
CompID
EName
Make
Salary
Model
Dept

Rishu Gupta & Manish Srivastava

Relationship
● Relationships depict how one or more entity types
are connected with each other. Each relationship has
a name e.g. a Computer is allocated to an
Employee.

● There can be more than one relationship between

entities, e.g. an Employee works in a Department
while the head of department (also an employee)
manages a Department.

● A relationship can also exist between instances of

same entity, e.g. an Employee reports to another
Employee.

Rishu Gupta & Manish Srivastava

1 : 1 relationship
● 1:1 relationship represents association between single
occurrence of one entity and a single occurrence of the
second entity.

For e.g. consider a company where each employee can be

allocated a maximum of 1 computer and computers are not
shared between employees.

The Allot_Dt attribute is not a property of employee or

computer. It belongs to the relationship and therefore
represented separately in the ER Model.
employee table has two additional attributes - CompId and
Allot_Dt. CompId is a foreign key to establish the link
between these two tables. Allot_Dt which is the attribute of
the relationship is always stored in the table that has the
foreign key.
Alternatively we could also have added Id and Allot_Dt
attributes in computer table to establish the link.

Rishu Gupta & Manish Srivastava

1 : N Relationship
● 1 : N relationship represents association between single occurrence of one entity and multiple
occurrences of second entity. For e.g. consider a company where each employee can be allocated
many computers but still computers cannot be shared between employees.

In 1 : N relationships, the foreign key and relationship attributes are always added to the many (N) side of
the relationship. Hence these attributes are added to Computer table. The reverse solution will not work.
Rishu Gupta & Manish Srivastava
M : N Relationship
● M:N relationship represents association between multiple occurrences of both entities. For e.g.
consider a company where each employee can be allocated many computers and computers can be
shared between employees.

In M : N relationships, the relationship is represented by a completely new table that has a composite
primary key. Such a structure requires two foreign keys on the new table linking to the primary keys of each
of the parent tables. The attribute of the relationship resides on this new table.
Rishu Gupta & Manish Srivastava
Relationship and Foreign Key
Foreign keys need to be created in tables in order to establish relationship between entities. The table in which
foreign key will be created depends upon the cardinality of relationship.

Rishu Gupta & Manish Srivastava

Cardinality of Relationship
● Cardinality of relationship is the number of instances in one entity type which is associated to the
number of instances in another entity type.
● For the relationship between Employee and Computer, it helps us answer questions like how many
computers can be allocated to an employee, can computers be shared between employees, can
employees exist without being allocated a computer etc. e.g. if 0 or 1 computer can be allocated to 0
or 1 employee then the cardinality of relationship between these two entities will be 1:1.
● Cardinality ratio of relationships are of three types: 1:1, 1:N and M:N.

Rishu Gupta & Manish Srivastava