COURSE NAME : DATABASE MANAGEMENT

SYSTEMS
COURSE CODE : 18CSC303J
UNIT II
PART-I

INSTRUCTOR:
DR. NIRANJAN LAL @ SRM IST, DELHI NCR CAMPUS
[email protected] (personal)
[email protected] (professional)
http://cooltechie.in/
Unit-II : Syllabus/ Roadmap
Session Learning Outcomes(SLO)

Database Design
Design process
Entity Relation Model
ER diagram
Keys , Attributes and Constraints
Mapping Cardinality Extended ER –
Generalization
Specialization and Aggregation
ER Diagram Issues
Weak Entity
Relational Model
Conversion of ER to Relational Table
Course Outcomes (Unit 2)
 Apply the fundamentals of data models to model an
application’s data requirements using conceptual
modelling tools like ER diagrams.

 Apply the method to convert the ER model to a

database schemas based on the conceptual relational
model.
Database Design
Database design is the organization of data
according to a database model.
The designer determines what data must be
stored and how the data elements interrelate.
With this information, they can begin to fit the
data to the database model.
A database management system manages the
data accordingly.
 Design Phases
 Initial phase -- characterize fully the data needs of the prospective database
users.
 Second phase -- choosing a data model
 Final Phase -- Moving from an abstract data model to the implementation of
the database
 Logical Design – Deciding on the database schema.
 Physical Design – Deciding on the physical layout of the database
 Schemas versus Instances
 Database Schema: The description of a database.
Includes descriptions of the database structure and
the constraints that should hold on the database.
 Schema Diagram: A diagrammatic display of
(some aspects of) a database schema.
 Database Instance: The actual data stored in a
database at a particular moment in time. Also
called database state (or occurrence).
 Thedatabase schema changes very infrequently.
The database state changes every time the
database is updated. Schema is also called
intension, whereas state is called extension.
Data Modeling Using the Entity-
Relationship(ER) Data Model
 Database Design Process
 Example Database Application(COMPANY)
 ER Model Concepts
 Entities and Attributes
 Entity Types, Value Sets, and Key Attributes
 Relationships and Relationship Types
 Structural Constraints and Roles
 Weak Entity Types

 ER Diagrams Notation
 Relationships of Higher Degree
Example COMPANY Database
 Requirements for the COMPANY Database:
 The company is organized into DEPARTMENTs. Each department has a
name, number and an employee who manages the department. We keep
track of the start date of the department manager. A department may
have several locations.
 Each department controls a number of PROJECTs. Each project has a
name, number, and is located at a single location
 We store each EMPLOYEE’s social security number, address, salary, sex,
and birth date. Each employee works for one department but may work on
several projects.We keep track of the number of hours per week that an
employee currently works on each project. We also keep track of the direct
supervisor of each employee.
 Each employee may have a number of DEPENDENTs. For each dependent,
we keep their name, sex, birth date, and relationship to the employee.
 ER model
 ER model stands for an Entity-Relationship model. It is a high-
level data model. This model is used to define the data elements
and relationship for a specified system.
 It develops a conceptual design for the database. It also develops
a very simple and easy to design view of data.
 In ER modeling, the database structure is portrayed as a diagram
called an entity-relationship diagram.
For example, Suppose we design a school database. In this database,
the student will be an entity with attributes like address, name, id,
age, etc. The address can be another entity with attributes like
city, street name, pin code, etc and there will be a relationship
between them.
ER diagram
 Entity Relationship Diagram
– ER Diagram in DBMS. An
Entity–relationship model
(ER model) describes the
structure of a database with
the help of a diagram, which
is known as Entity
Relationship Diagram (ER
Diagram).
 An ER model is a design or
blueprint of a database that
can later be implemented as a
database.
Terminologies Related to ER
Model
 The ER data model employs three basic concepts:
 entity sets,
 relationship sets,
 attributes.

 Domain – the set of permitted values for each attribute

 Cardinality - In Mathematics, Cardinality is defined as the number of
elements in a given set. But, cardinality in DBMS refers to the
Relationship which specifies how many times a particular Entity
occurs in the Relationship.
What is Mapping Cardinalities
in ER Diagrams
 In a Database Management System (DBMS), mapping
cardinalities explains how entities (tables) in a database schema
relate to one another.
 One to one
 One to many
 Many to one
 Many to many
1. One to one relationship (1:1) 2. One to many relationship (1:M)
3. Many to one relationship (M:1) 4. Many to many relationship (M:N)
Structural Constraints on
Relationship
 Cardinality constraints
 Zero-to-one 0..1
 Zero-to-many 0..*
 One-to-many 1..*
 Many-to-many *..*
 Participation constraints
 Total (mandatory, every one involved)
 Partial (optional, only some involved)
Keys , Attributes and
Constraints
Super Key in DBMS

These all are the set of super keys

which, together or combining with other
prime attributes, can identify a table
uniquely.
Super Key in DBMS
ER Diagram
Initial Conceptual Design of the
COMPANY Database
We can now define the entity types for the COMPANY database
1. An entity type DEPARTMENT with attributes Name, Number, Locations,
Manager, and Manager_start_date. Locations is the only multivalued
attribute. We can specify that both Name and Number are (separate) key
attributes because each was specified to be unique.
Initial Conceptual Design of the
COMPANY Database
We can now define the entity types for the COMPANY database
2. An entity type PROJECT with attributes Name, Number, Location,
and Controlling_department. Both Name and Number are
(separate) key attributes.
Initial Conceptual Design of the
COMPANY Database
We can now define the entity types for the COMPANY database
3. An entity type EMPLOYEE with attributes Name, Ssn, Sex, Address,
Salary, Birth_date, Department, and Supervisor. Both Name and
Address may be composite attributes; however, this was not specified
in the requirements. We must go back to the users to see if any of
them will refer to the individual components of Name—First_name,
Middle_initial, Last_name—or of Address.
Initial Conceptual Design of the
COMPANY Database
We can now define the entity types for the COMPANY database
4. An entity type DEPENDENT with attributes Employee,
Dependent_name, Sex, Birth_date, and Relationship (to the employee).
Ternary relationship types.
(a) The SUPPLY relationship.
(b) Three binary relationships not
equivalent to SUPPLY.
(c) SUPPLY represented as a weak entity
type.
Extended ER
 EER stands for Enhanced ER or Extended ER
 EER Model Concepts
 Includes all modeling concepts of basic ER
 Additional concepts:
subclasses/superclasses
specialization/generalization
categories (UNION types)
attribute and relationship inheritance
 These are fundamental to conceptual modeling
 The additional EER concepts are used to model applications more completely
and more accurately
 EER includes some object-oriented concepts, such as inheritance
Subclasses and
Superclasses
Specialization
Specialization is the process of defining a set of
subclasses of a superclass
The set of subclasses is based upon some
distinguishing characteristics of the entities in
the superclass
Example: {SECRETARY, ENGINEER,
TECHNICIAN} is a specialization of
EMPLOYEE based upon job type.
May have several specializations of the
same superclass
Generalization

 Generalization is the reverse of the specialization process

 Several classes with common features are generalized into a
superclass;
 original classes become its subclasses
 Example: CAR, TRUCK generalized into VEHICLE;
 both CAR, TRUCK become subclasses of the superclass
VEHICLE.
 We can view {CAR, TRUCK} as a specialization of
VEHICLE
 Alternatively, we can view VEHICLE as a generalization of
CAR and TRUCK
Categories (UNION TYPES)

 Allof the superclass/subclass relationships we

have seen thus far have a single superclass
 A shared subclass is a subclass in:
more than one distinct superclass/subclass
relationships
each relationships has a single superclass
shared subclass leads to multiple inheritance
 Aggregation
 Aggregation in DBMS (Database
Management System) is the
process of combining two or
more entities to form a more
meaningful new entity
 When the entities do not make
sense on their own, the
aggregation process is used.
 ER Diagram Issues
1) Use of Entity Set vs Attributes
2) Use of Entity Set vs. Relationship Sets
3) Use of Binary vs n-ary Relationship Sets
4) Placing Relationship Attributes
Relational Model in DBMS
Table Student
 Relational model can represent as a
table with columns and rows. Each ROLL_N
NAME ADDRESS PHONE AGE
O
row is known as a tuple. Each table of
the column has a name or attribute. 94551234
1 RAM DELHI 18
 51
The relational model represents how
data is stored in Relational Databases. RAMES GURGAO 96524315
2 18
H N 43
A relational database consists of a
collection of tables, each of which is 91562531
3 SUJIT ROHTAK 20
31
assigned a unique name. Consider a
relation STUDENT with attributes SURES
4 DELHI 18
H
ROLL_NO, NAME, ADDRESS,
PHONE, and AGE shown in
the table.
Important Terminologies
• Attribute: Attributes are the properties that define an entity. e.g.; ROLL_NO, NAME, ADDRESS
• Relation Schema: A relation schema defines the structure of the relation and represents the name of the
relation with its attributes. e.g.; STUDENT (ROLL_NO, NAME, ADDRESS, PHONE, and AGE) is
the relation schema for STUDENT. If a schema has more than 1 relation, it is called Relational
Schema.
• Tuple: Each row in the relation is known as a tuple. The above relation contains 4 tuples, one of which
is shown as:
• Relation Instance: The set of tuples of a relation at a particular instance of time is called a relation
instance. Table 1 shows the relation instance of STUDENT at a particular time. It can change
whenever there is an insertion, deletion, or update in the database.
• Degree: The number of attributes in the relation is known as the degree of the relation.
The STUDENT relation defined above has degree 5.
• Cardinality: The number of tuples in a relation is known as cardinality. The STUDENT relation
defined above has cardinality 4.
• Column: The column represents the set of values for a particular attribute. The column ROLL_NO is
extracted from the relation STUDENT.
• NULL Values: The value which is not known or unavailable is called a NULL value. It is represented
Conversion of ER to Relational
Table
Mapping from ER Model to Relational Model
To understand this, you should have an idea about:
 ER model
 Relation model
After designing the ER diagram of system, we need to
convert it to Relational models which can directly be
implemented by any RDBMS like Oracle, MySQL etc. In
this article we will discuss how to convert ER diagram to
Relational Model for different scenarios.
Conversion of ER to Relational
Table
 ER-to-Relational Mapping Algorithm
 Step 1: Mapping of Regular Entity Types
 Step 2: Mapping of Weak Entity Types
 Step 3: Mapping of Binary 1:1 Relation Types
 Step 4: Mapping of Binary 1:N Relationship Types.
 Step 5: Mapping of Binary M:N Relationship Types.
 Step 6: Mapping of Multivalued attributes.
 Step 7: Mapping of N-ary Relationship Types.

 Mapping EER Model Constructs to Relations

 Step 8: Options for Mapping Specialization or Generalization.
 Step 9: Mapping of Union Types (Categories).
The ER conceptual schema diagram for
the COMPANY database.
Result of mapping the COMPANY ER
schema into a relational schema.
THANK YOU