UNIT-3

CHAPTER-1: Database design and the E-R Model

1.Overview of the design process:
The database design process can be divided into six steps. The ER model is most relevant to the first
three steps.
1. Requirements Analysis: The very first step in designing a database application is to understand what data is
to be stored in the database, what applications must be built on top of it, and what operations are most
frequent and subject to performance requirements. In other words,
we must find out what the users want from the database.
2. Conceptual Database Design: The information gathered in the requirements analysis step is used to
develop a high-level description of the data to be stored in the database, along with the constraints known to
hold over this data. The ER model is one of several high-level, or semantic, data models used in database
design. The goal is to create a simple description of the data that closely matches how users and developers
think of the data.
3. Logical Database Design: We must choose a DBMS to implement our database design, and convert the
conceptual database design into a database schema in the data model of the chosen DBMS. The conceptual
schema, sometimes called the logical schema, in the relational data model.Once we have a good logical
schema, we must consider performance criteria and design the physical schema. Finally, we must address
security issues and ensure that users are able to access the data they need, but not data that we wish to hide
from them.
The remaining three steps of database design are
4. Schema Refinement: The fourth step in database design is to analyze the collection of relations in our
relational database schema to identify potential problems, and to refine it. In contrast to the requirements
analysis and conceptual design steps, which are essentially subjective, schema refinement can be guided by
some elegant and powerful theory.
5. Physical Database Design: This step may simply involve building indexes on some tables and clustering
some tables, or it may involve a substantial redesign of parts of the database schema obtained from the
earlier design steps.
6. Application go beyond the database itself. we must identify the entities (e.g., users, user groups,
departments) and processes involved in the application. We must describe the role of each entity in and
Security Design: Any software project that involves a DBMS must consider aspects of the application that
every process that is reflected in some application task, as part of a complete workflow for that task.
2.Entity Relationship model
ENTITIES, ATTRIBUTES, AND ENTITY SETS
The ER model defines the conceptual view of a database. It works around real-world entities and the
associations among them. At view level, the ER model is considered a good option for designing databases.
Entity :An entity is an object that exists and which is distinguishable from other objects. An entity can be a
person, a place, an object, an event, or a concept about which an organization wishes to maintain data. The
following are some examples of entities:
Person: STUDENT, EMPLOYEE, CLIENT
Object: COUCH, AIRPLANE, MACHINE
Place: CITY, NATIONAL PARK, ROOM, WAREHOUSE
Event: WAR, MARRIAGE, LEASE
Concept: PROJECT, ACCOUNT, COURSE
All these entities have some attributes or properties that give them their identity.
It is important to understand the distinction between an entity type, an entity instance, and an entity
set. An entity type defines a collection of entities that have same attributes. An entity instance is a single
item in this collection. An entity set is a set of entity instances.
Attributes
Entities are represented by means of their properties, called attributes. All attributes have values. For
example, a student entity may have name, class, and age as attributes.
There exists a domain or range of values that can be assigned to attributes. For example, a student's name
cannot be a numeric value. It has to be alphabetic. A student's age cannot be negative, etc.
Types of Attributes
 Simple attribute − Simple attributes are atomic values, which cannot be divided further. For example, a
student's phone number is an atomic value of 10 digits.
 Composite attribute − Composite attributes are made of more than one simple attribute. For example,
a student's complete name may have first name and last name.
 Derived attribute − Derived attributes are the attributes that do not exist in the physical database, but
their values are derived from other attributes present in the database. For example, age can be derived
from date of birth.
 Single-value attribute − Single-value attributes contain single value. For example – Adhar Number.
 Multi-value attribute − Multi-value attributes may contain more than one values. For example, a
person can have more than one phone number, email, address, etc.
Symbol Shape Name Symbol Description

Entities

An entity is represented by a rectangle which

Entity
contains the entity’s name.

An entity that cannot be uniquely identified by its

attributes alone. The existence of a weak entity is
dependent upon another entity called the owner
Weak Entity
entity. The weak entity’s identifier is a combination
of the identifier of the owner entity and the partial
key of the weak entity.

An entity used in a many-to-many relationship. All

Associative
relationships for the associative entity should be
Entity
many

Attributes

In the Chen notation, each attribute is represented

Attribute
by an oval containing atributte’s name

An attribute that uniquely identifies a particular

Key attribute
entity. The name of a key attribute is underscored.
 An attribute that can have many values (there are
Multivalued many distinct values entered for it in the same
attribute column of the table). Multivalued attribute is
depicted by a dual oval.

An attribute whose value is calculated (derived)

from other attributes. The derived attribute may
Derived
or may not be physically stored in the database. In
attribute
the Chen notation, this attribute is represented by
dashed oval.

Relationships

A relationship where entity is existence-

independent of other entities, and PK of Child
Strong
doesn’t contain PK component of Parent Entity. A
relationship
strong relationship is represented by a single
rhombus

A relationship where Child entity is existence-

Weak
dependent on parent, and PK of Child Entity
(identifying)
contains PK component of Parent Entity. This
relationship
relationship is represented by a double rhombus.
 Fig :Attributes of the STUDENT entity type.
RELATIONSHIP AND RELATIONSHIP SETS
The association among entities is called a relationship. Relationships are represented by diamond-
shaped box. Name of the relationship is written inside the diamond-box. All the entities (rectangles)
participating in a relationship, are connected to it by a line. For example, an employee works_at a
department, a student enrolls in a course. Here, Works_at and Enrolls are called relationships.
Relationship Set
A set of relationships of similar type is called a relationship set. Like entities, a relationship too can have
attributes. These attributes are called descriptive attributes. Descriptive attributes are used to record
information about the relationship, rather than about any one of the participating entities
Degree of Relationship
The degree of a relationship is the number of entity types that participate in the relationship. The three most
common relationships in ER models are Binary, UnaryandTernary
A binary relationship, or an association between two entity types, is the most common form of a relationship
expressed by an E-R diagram.
For Example:

A unary relationship is when both participants in the relationship are the same entity
A ternary relationship is when three entities participate in the relationship

Degrees of Relationship (Cardinality)

The degree of relationship (also known as cardinality) is the number of occurrences in one entity which are
associated (or linked) to the number of occurrences in another.
There are three degrees of relationship, known as:
1. one-to-one (1:1)
2. one-to-many (1:M)
3. many-to-many (M:N)
One-to-one (1:1)
This is where one occurrence of an entity relates to only one occurrence in another entity.
A one-to-one relationship rarely exists in practice, but it can. However, you may consider combining them into
one entity.
For example, an employee is allocated a company car, which can only be driven by that employee.
Therefore, there is a one-to-one relationship between employee and company car.

One-to-Many (1:M)
Is where one occurrence in an entity relates to many occurrences in another entity.
For example, taking the employee and department entities shown on the previous page, an employee works
in one department but a department has many employees.
Therefore, there is a one-to-many relationship between department and employee.
Many-to-Many (M:N)
This is where many occurrences in an entity relate to many occurrences in another entity.
For example, an employee may work on several projects at the same time and a project has a team of many
employees.
Therefore, there is a many-to-many relationship between employee and project.

3. CONSTRAINTS
Constraints are categorized into 2 types
1) Key Constraints
2) Participation Constraints
Key Constraints :Keys are attributes or sets of attributes that uniquely identify an entity within its entity set.
These can be classified into 4 types as below.
1.Many to Many: An employee is allowed to work in different departments and a department is allowed to
have several employees.

2.One to Many: 1 employee can be associated with many departments, where as each department can be
associated with at most 1 employee as its manager.

3.Many to One:
Each employee works in at most 1 department.i.e, many employees can work in same department.
4.One to One:
Each employee can manage at most 1 department.

Participation Constraints :The participation constraint specifies whether the existence of an entity depends on
its being related to another entity via the relationship type.
A department has at most one manager. This requirement is an example of participation constraints. There
are 2 types of participation constraints, which are as below.
1.Total. 2.Partial.
Total: An entity set dependent on a relationship set and having one to many relationships is said to be ‘total’.
The participation of the entity set ‘departments’ in the relationship set ‘manages’ is said to be total.
Partial: A participation that is not total is said to be partial.
Example: Participation of the entity set ‘employees’ in ‘manages’ is partial, since not every employee gets to
manage a department.
In E-R diagram, the total participation is displayed as a ‘double line’ connecting the participating entity type to
the relationship, where as partial participation is represented by a single line. If the participation of an entity
set in a relationship set is total, then a thick line connects the two. The presence of an arrow indicates a key
constraint.
Weak Entities :Entity types can be classified into two categories: strong entity typesand weak entity types. A
strong entity type exists independent of other entity types, while a weak entity type depends on another
entity type. i.e.Entity types that do not have key attributes of their own are called as weak entity types. A
weak entity type always has a ‘total participation constraint’.
The dependent weak entity set and its relationship to employees is shown in the following diagram.

Linking them with a dark line indicates the total participation of dependents in policy.
To understand the fact that dependents is a weak entity and policy is its identifying relationship, we draw both
with dark lines. To indicate that ‘pname’ is a partial key for dependents, we underline it using a broken line.
4.REDUCTION TO RELATIONAL SCHEMAS:

We can represent a database that conforms to an E-R database schema by a col- lection of relation schemas.
For each entity set and for each relationship set in the database design, there is a unique relation schema to
which we assign the name of the corresponding entity set or relationship set.
.
Representation of Strong Entity Sets with Simple Attributes
Let E be a strong entity set with only simple descriptive attributes a1, a 2 ,..., an. We represent this entity by a
schema called E with n distinct attributes. Each tuple in a relation on this schema corresponds to one entity of
the entity set E.
For schemas derived from strong entity sets, the primary key of the entity set serves as the primary key of the
resulting schema. This follows directly from the fact that each tuple corresponds to a specific entity in the
entity set.
From the above fig This entity set has three attributes: ID, name, tot cred. We represent this entity set by a
schema called student with three attributes:

student (ID, name, tot cred)

Note that since student ID is the primary key of the entity set, it is also the primary key of the relation
schema.
Continuing with our example, for the E-R diagram in Figure 7.15, all the strong entity sets, except time slot,
have only simple attributes. The schemas derived from these strong entity sets are:
classroom (building, room number, capacity) department (dept name,
building, budget) course (course id, title, credits)
instructor (ID, name, salary) student (ID, name, tot cred)

As you can see, both the instructor and student schemas are different from the schemas we have used in the
previous chapters (they do not contain the attribute dept name). We shall revisit this issue shortly.
Representation of Strong Entity Sets with Complex Attributes
When a strong entity set has nonsimple attributes, things are a bit more complex. We handle composite
attributes by creating a separate attribute for each of the component attributes; we do not create a
separate attribute for the composite attribute itself.
Multivalued attributes are treated differently from other attributes. We have seen that attributes in an
E-R diagram generally map directly into attributes for the appropriate relation schemas. Multivalued
attributes, however, are an exception; new relation schemas are created for these attributes, as we shall
see shortly.
complex attributes, without including the multivalued attribute, is thus:

instructor (ID, first name, middle name, last name, street number, street
name, apt number, city, state, zip code, date of birth)
We create a primary key of the relation schema consisting of all attributes of the schema. In the above
example, the primary key consists of both attributes of the relation instructor phone.
In addition, we create a foreign-key constraint on the relation schema created from the multivalued
attribute, with the attribute generated from the primary key of the entity set referencing the relation
generated from the entity set. In the above example, the foreign-key constraint on the instructor phone
relation would be that attribute ID references the instructor relation.
Representation of Weak Entity Sets
Let A be a weak entity set with attributes a1, a 2 ,..., am. Let B be the strong entity set on which A
depends. Let the primary key of B consist of attributes b1, b 2 ,..., bn. We represent the entity set A by a
relation schema called A with one attribute for each member of the set:

{a1, a 2 ,... , am} ∪ {b1, b 2 ,... , bn}

For schemas derived from a weak entity set, the combination of the pri- mary key of the strong entity
set and the discriminator of the weak entity set serves as the primary key of the schema. In addition to
creating a primary key, we also create a foreign-key constraint on the relation A, specifying that the
attributes b1, b2,..., bn reference the primary key of the relation B. The foreign- key constraint ensures that
for each tuple representing a weak entity, there is a corresponding tuple representing the corresponding
strong entity. Thus, we represent section by a schema with the following attributes:

section (course id, sec id, semester, year)

The primary key consists of the primary key of the entity set course, along with the discriminator
of section, which is sec id, semester, and year. We also create a foreign-key constraint on the
section schema, with the attribute course id refer- encing the primary key of the course schema,
and the integrity constraint “on delete cascade”.7 Because of the “on delete cascade”
specification on the foreign key constraint, if a course entity is deleted, then so are all the
associated section entities.
• For a binary many-to-many relationship, the union of the primary-key at- tributes from the
participating entity sets becomes the primary key.
• For a binary one-to-one relationship set, the primary key of either entity set can be chosen as
the primary key. The choice can be made arbitrarily.
• For a binary many-to-one or one-to-many relationship set, the primary key of the entity set
on the “many” side of the relationship set serves as the primary key.