UNIT-02

DATABASE DESIGN AND E-R

MODEL
 INTRODUCTION

•Database systems are designed to manage large bodies of information. These large bodies of information do not
exist in isolation.

•They are part of the operation of some enterprise whose end product may be information from the database or
may be some device or service for which the database plays only a supporting role.

•The design of a complete database application environment that meets the needs of the enterprise being Modeled
requires attention to a broader set of issues,
 Overview of the Design Process
The task of creating a database application is a complex one, involving design of the database schema, design
of the programs that access and update the data, and design of a security scheme to control access to data.

 The needs of the users play a central role in the design process.

The design of a complete database application environment that meets the needs of the enterprise being
modeled requires attention to a broad set of issues.

Design Phases:

For small applications, it may be feasible for a database designer who understands the application requirements
to decide directly on the relations to be created, their attributes, and constraints on the relations. However, such
a direct design process is difficult for real-world applications, since they are often highly complex.

The database designer must interact with users of the application to understand the needs of the application,
represent them in a high-level fashion that can be understood by the users, and then translate the requirements
Design Phases
A high-level data model serves the database designer by providing a conceptual framework in which to specify, in a
systematic fashion, the data requirements of the database users, and a database structure that fulfills these requirements.

1. The initial phase of database design is to characterize fully the data needs of the prospective database users. The database
designer needs to interact extensively with domain experts and users to carry out this task. The outcome of this phase is a
specification of user requirements. While there are techniques for diagrammatically representing user requirements.

2. Next, the designer chooses a data model and, by applying the concepts of the chosen data model, translates these
requirements into a conceptual schema of the database. The schema developed at this conceptual-design phase provides
a detailed overview of the enterprise.

Stated in terms of the entity-relationship model, the conceptual schema specifies the entities that are represented in the
database, the attributes of the entities, the relationships among the entities, and constraints on the entities and relationships.
the conceptual-design phase results in the creation of an entity-relationship diagram that provides a graphic representation of
the schema.
 Design Phases
3. A fully developed conceptual schema also indicates the functional requirements of the enterprise. In a specification of
functional requirements, users describe the kinds of operations (or transactions) that will be performed on the data.

Example operations include modifying or updating data, searching for and retrieving specific data, and deleting data. At this
stage of conceptual design, the designer can review the schema to ensure it meets functional requirements.

4. The process of moving from an abstract data model to the implementation of the database proceeds in two final design
phases.

o In the logical-design phase, the designer maps the high-level conceptual schema onto the implementation data model of the
database system that will be used. The implementation data model is typically the relational data model, and this step
typically consists of mapping the conceptual schema defined using the entity-relationship model into a relation schema.

oFinally, the designer uses the resulting system-specific database schema in the subsequent physical-design phase, in which
the physical features of the database are specified. These features include the form of file organization and choice of index
structures
Design Alternatives

A major part of the database design process is deciding how to represent in the design the various types of “things” such as
people, places, products, and the like.

We use the term entity to refer to any such distinctly identifiable item.

 In a university database, examples of entities would include instructors, students, departments, courses, and course
offerings. The various entities are related to each other in a variety of ways, all of which need to be captured in the
database design.

 For example, a student takes a course offering, while an instructor teaches a course offering; teaches and takes are
examples of relationships between entities.
Design Alternatives
In designing a database schema, we must ensure that we avoid two major pitfalls:

1. Redundancy : A bad design may repeat information. For example, if we store the course identifier and title of a course
with each course offering, the title would be stored redundantly (that is, multiple times, unnecessarily) with each course
offering. It would suffice to store only the course identifier with each course offering, and to associate the title with the
course identifier only once, in a course entity.

• Redundancy can also occur in a relational schema. The biggest problem with such redundant representation of information

is that the copies of a piece of information can become inconsistent if the information is updated without taking precautions
to update all copies of the information. Ideally, information should appear in exactly one place.

2. Incompleteness : A bad design may make certain aspects of the enterprise difficult or impossible to model. For
example, suppose that, as in case (1) above, we only had entities corresponding to course offering, without having an entity
corresponding to courses.
 The Entity-Relationship Model
The entity-relationship (E-R) data model was developed to facilitate database design by allowing specification
of an enterprise schema that represents the overall logical structure of a database.

ENTITY RELATIONAL (ER) MODEL is a high-level conceptual data model diagram.

ER modelling helps you to analyse data requirements systematically to produce a well-designed database.

The Entity-Relation model represents real-world entities and the relationship between them.

 It is considered a best practice to complete ER modelling before implementing your database.

It was proposed by Peter Chen in 1971 to create a uniform convention which can be used for relational
database and network. He aimed to use an ER model as a conceptual modelling approach.
 What is ER Diagrams?

ENTITY-RELATIONSHIP DIAGRAM (ERD) displays the relationships of entity set stored in a

database.

In other words, we can say that ER diagrams help you to explain the logical structure of databases.

At first look, an ER diagram looks very similar to the flowchart. However, ER Diagram includes many
specialized symbols, and its meanings make this model unique.

 The purpose of ER Diagram is to represent the entity framework infrastructure.

It is an easy to use graphical tool for modelling data.

Widely used in Database Design.

It is a GUI representation of the logical structure of a Database.

It helps you to identifies the entities which exist in a system and the relationships between those
 Why use ER Diagrams?
Helps you to define terms related to entity relationship modelling.

Provide a preview of how all your tables should connect, what fields are going to be on each table.

Helps to describe entities, attributes, relationships , ER diagrams are translatable into relational tables which
allows you to build databases quickly

ER diagrams can be used by database designers as a blueprint for implementing data in specific software
applications.

The database designer gains a better understanding of the information to be contained in the database with the
help of ERP diagram

ERD is allowed you to communicate with the logical structure of the database to users
 Components of the ER Diagram
This model is based on three basic concepts:
•Entities
•Attributes
•Relationships
Components of the ER Diagram
 Entity Sets
An entity is a “thing” or “object” in the real world that is distinguishable from all other objects.

In the ER diagram, an entity can be represented as rectangles.

For example, each person in a university is an entity. An entity has a set of properties, and the values for some
set of properties may uniquely identify an entity. For instance, a person may have a person id property.

An entity set is a set of entities of the same type that share the same properties, or attributes. The set of all
people who are instructors at a given university, for example, can be defined as the entity set instructor.
Similarly, the entity set student might represent the set of all students in the university.
 Entity Sets
In the process of modeling, we often use the term entity set in the abstract, without referring to a particular set
of individual entities. We use the term extension of the entity set to refer to the actual collection of entities
belonging to the entity set. Thus, the set of actual instructors in the university forms the extension of the entity
set instructor.

An entity is represented by a set of attributes.

Attributes are descriptive properties possessed by each member of an entity set.

The designation of an attribute for an entity set expresses that the database stores similar information
concerning each entity in the entity set; however, each entity may have its own value for each attribute.

Possible attributes of the instructor entity set are ID, name, dept name, and salary.

Each entity has a value for each of its attributes. For instance, a particular instructor entity may have the value
12121 for ID, the value Anu for name, the value Finance for dept name, and the value 90000 for salary.
 Relationship Sets
A relationship is an association among several entities.
A relationship set is a set of relationships of the same type.
If E1, E2, . . . , En are entity sets, then a relationship set R is a subset of
{(e1, e2, . . . , en) | e1 ∈ E1, e2 ∈ E2, . . . , en ∈ En}
where (e1, e2, . . . , en) is a relationship.
We define
the relationship set advisor to denote the association between instructors and
students. Figure 7.2 depicts this association.
The association between entity sets is referred to as participation; that is, the
entity sets E1, E2, . . . , En participate in relationship set R.
A relationship instance in an E-R schema represents an association between the named entities in
the real-world enterprise that is being modeled.
The function that an entity plays in a relationship is called that entity’s role. Since entity sets participating in a
relationship set are generally distinct, roles are implicit and are not usually specified.
 Attributes
For each attribute, there is a set of permitted values, called the domain, or value set, of that attribute.
An attribute describes the property of an entity. An attribute is represented as Oval in an ER diagram.
There are four types of attributes:
1. Key attribute
2. Composite attribute
3. Multivalued attribute
4. Derived attribute
 Key attribute

A key attribute can uniquely identify an entity from an entity set. For example, student roll number can
uniquely identify a student from a set of students. Key attribute is represented by oval same as other attributes
however the text of key attribute is underlined.
 Composite attribute
An attribute that is a combination of other attributes is known as composite attribute. For example, In student
entity, the student address is a composite attribute as an address is composed of other attributes such as pin
code, state, country.
 Multivalued attribute
An attribute consisting more than one value for a given entity. For example, Phone_No (can be more than one
for a given student). In ER diagram, multivalued attribute is represented by double oval.

Derived Attribute

An attribute which can be derived from other attributes of the entity type is known as derived attribute. e.g.;
Age (can be derived from DOB). In ER diagram, derived attribute is represented by dashed oval.
 Relationship

A relationship is represented by diamond shape in ER diagram, it shows the relationship among entities.

There are four types of relationships:

1. One to One
2. One to Many
3. Many to One
4. Many to Many
 One to One Relationship

When a single instance of an entity is associated with a single instance of another entity then it is called
one to one relationship.

For example, a person has only one passport and a passport is given to one person.
 One to Many Relationship

When a single instance of an entity is associated with more than one instances of another
entity then it is called one to many relationship.

For example – a customer can place many orders but a order cannot be placed by many
customers.
 Many to One Relationship

When more than one instances of an entity is associated with a single instance of
another entity then it is called many to one relationship.

For example – many students can study in a single college but a student cannot study
in many colleges at the same time.
 Many to Many Relationship
When more than one instances of an entity is associated with more than one instances of another
entity then it is called many to many relationship.

For example, a can be assigned to many projects and a project can be assigned to many students.
 Constraints
An E-R enterprise schema may define certain constraints to which the contents of a database must conform.
Mapping Cardinalities
Mapping cardinalities, or cardinality ratios, express the number of entities to which another entity can be
associated via a relationship set.
Mapping cardinalities are most useful in describing binary relationship sets, although they can contribute to the
description of relationship sets that involve more than two entity sets.
For a binary relationship set R between entity sets A and B, the mapping cardinality must be one of the
following:
1. One-to-one. An entity in A is associated with at most one entity in B, and an entity in B is associated with at
most one entity in A.
 MappingCardinalities

2. One-to-many. An entity in A is associated with any number (zero or more) of entities in B. An entity in B,
however, can be associated with at most one entity in A.
 Mapping Cardinalities

3. Many-to-one. An entity in A is associated with at most one entity in B. An entity in B,

however, can be associated with any number (zero or more) of entities in A.
 Mapping Cardinalities

4. Many-to-many. An entity in A is associated with any number (zero or more) of entities in

B, and an entity in B is associated with any number (zero or more) of entities in A.

The appropriate mapping cardinality for a particular relationship set obviously depends on the real-world situation that the
relationship set is modeling.
 Participation Constraints

Total Participation − Each entity is involved in the relationship. Total participation is

represented by double lines.

Partial participation − Not all entities are involved in the relationship. Partial
participation is represented by single lines.
 Removing Redundant Attributes in Entity Sets
When we design a database using the E-R model, we usually start by identifying those entity sets that should be
included.

For example, in the university organization we decided to include such entity sets as student, instructor, etc.
Once the entity sets are decided upon, we must choose the appropriate attributes. These attributes are supposed
to represent the various values we want to capture in the database.

 In the university organization, we decided that for the instructor entity set, we will include the attributes ID,
name, dept name, and salary. We could have added the attributes: phone number, office number, home page, etc.
The choice of what attributes to include is up to the designer, who has a good understanding of the structure of
the enterprise.

Once the entities and their corresponding attributes are chosen, the relationship sets among the various entities
are formed. These relationship sets may result in a situation where attributes in the various entity sets are
redundant and need to be removed from the original entity sets.
 Entity-Relationship Diagrams
an E-R diagram can express the overall logical structure of a database graphically.

 E-R diagrams are simple and clear—qualities that may well account in large part for the widespread use of the
E-R model.
Basic Structure
An E-R diagram consists of the following major components:
Rectangles divided into two parts represent entity sets. The first part, which in this textbook is shaded blue,
contains the name of the entity set. The second part contains the names of all the attributes of the entity set.
 Diamonds represent relationship sets.
 Undivided rectangles represent the attributes of a relationship set. Attributes that are part of the primary key
are underlined.
 Lines link entity sets to relationship sets.
Dashed lines link attributes of a relationship set to the relationship set.
 Double lines indicate total participation of an entity in a relationship set.
Double diamonds represent identifying relationship sets linked to weak entity sets
Entity-Relationship Diagrams

we have the date descriptive attribute attached to the relationship set advisor to specify the date on which an
instructor became the advisor.
 Weak Entity Sets

A weak entity is a type of entity which doesn't have its key attribute. It can be identified
uniquely by considering the primary key of another entity. For that, weak entity sets
need to have participation.
 Strong Entity Set Weak Entity Set
Strong entity set always has a primary key. It does not have enough attributes to build a primary key.

It is represented by a rectangle symbol. It is represented by a double rectangle symbol.

It contains a Primary key represented by the underline symbol. It contains a Partial Key which is represented by a dashed
underline symbol.

The member of a strong entity set is called as dominant entity The member of a weak entity set called as a subordinate entity
set. set.

Primary Key is one of its attributes which helps to identify its In a weak entity set, it is a combination of primary key and
member. partial key of the strong entity set.

In the ER diagram the relationship between two strong entity set The relationship between one strong and a weak entity set
shown by using a diamond symbol. shown by using the double diamond symbol.

The connecting line of the strong entity set with the relationship The line connecting the weak entity set for identifying
is single. relationship is double.
Alternative Notations for Modelling Data
 Keys
Keys play an important role in the relational database.
It is used to uniquely identify any record or row of data from the table.
It is also used to establish and identify relationships between tables.
Key is an attribute or collection of attributes that uniquely identifies an entity among entity set.
 Primary key

It is the first key which is used to identify one and only
one instance of an entity uniquely. An entity can
contain multiple keys as we saw in PERSON table.
The key which is most suitable from those lists
become a primary key.

In the EMPLOYEE table, ID can be primary key since

it is unique for each employee. In the EMPLOYEE
table, we can even select License_Number and
Passport_Number as primary key since they are also
unique.

For each entity, selection of the primary key is based

on requirement and developers.
Candidatekey

A candidate key is an attribute or set of an attribute which can

uniquely identify a tuple.

The remaining attributes except for primary key are considered

as a candidate key. The candidate keys are as strong as the
primary key.

For example:

In the EMPLOYEE table, id is best suited for the primary key.
Rest of the attributes like SSN, Passport_Number, and
License_Number, etc. are considered as a candidate key.
Super Key
Super key is a set of an attribute which can uniquely identify a tuple. Super key is a superset of a
candidate key.

For example: In the above EMPLOYEE table, for(EMPLOEE_ID, EMPLOYEE_NAME) the name
of two employees can be the same, but their EMPLYEE_ID can't be the same. Hence, this
combination can also be a key.

The super key would be EMPLOYEE-ID, (EMPLOYEE_ID, EMPLOYEE-NAME), etc.

Foreign key

Foreign keys are the column of the table which is used to point to the primary key of another table.

In a company, every employee works in a specific department, and employee and department are two
different entities. So we can't store the information of the department in the employee table. That's
why we link these two tables through the primary key of one table.

We add the primary key of the DEPARTMENT table, Department_Id as a new attribute in the
EMPLOYEE table.

Now in the EMPLOYEE table, Department_Id is the foreign key, and both the tables are related.
 Null
A null is a special symbol, independent of data type, which means either unknown or inapplicable.

It does not mean zero or blank.

Features of null include:

No data entry.

Not permitted in the primary key.

Should be avoided in other attributes.

Can represent:

 An unknown attribute value.

 A known, but missing, attribute value.

 A “not applicable” condition.

Can create problems when functions such as COUNT, AVERAGE and SUM are used.

Can create logical problems when relational tables are linked.

Sr. Key Strong Entity Weak Entity
No.

Key Strong entity always have one primary key. Weak entity have a foreign key referencing
primary key of strong entity.
1

Dependency Strong entity is independent of other entities. Weak entity is dependent on strong entity.
2

Represented by A strong entity is represented by single A weak entity is represented by double

3 rectangle. rectangle.

Relationship Relationship between two strong entities is Relationship between a strong and weak
Representation represented by single diamond. entity is represented by double diamond.
4

Participation Strong entity may or may not participate in Weak entity always participates in entity
5 entity relationships. relationships.
There are three types of relationship that exist between Entities.
Binary Relationship

Recursive Relationship

Ternary Relationship
 SCHEMA
A schema can be defined as the design of a database. The overall description of the database is
called the database schema.
It can be categorized into three parts:
1. Physical Schema
2. Logical Schema
3. View Schema
 Extended E-R Features
The extended E-R features of specialization, generalization, higher- and lower-level entity sets, attribute
inheritance, and aggregation.

The basic E-R concepts can model most database features, some aspects of a database may be more aptly
expressed by certain extensions to the basic E-R model.

Generalization
 Generalization
Generalization is like a bottom-up approach in which two or more entities of lower level combine to form a higher level entity if they
have some attributes in common.

In generalization, an entity of a higher level can also combine with the entities of the lower level to form a further higher level entity.

Generalization is more like subclass and superclass system, but the only difference is the approach. Generalization uses the bottom-up
approach.

In generalization, entities are combined to form a more generalized entity, i.e., subclasses are combined to make a superclass.

For example, Faculty and Student entities can be generalized and create a higher level entity Person.
 Specialization
Specialization is a top-down approach, and it is opposite to Generalization.
In specialization, one higher level entity can be broken down into two lower level entities.
Specialization is used to identify the subset of an entity set that shares some distinguishing characteristics.
Normally, the superclass is defined first, the subclass and its related attributes are defined next, and relationship set are
then added.