http://db.cs.berkeley.edu/topics/cs186/public_html/lecs/chapter14/sld014.

htm
Unit2
Database design

DATABASE DESIGN AND ER DIAGRAMS:-

The Entity-Relationship(ER) data model allows us to describe the data involved in a

real-world enterprise in terms of objects and their relationships and is widely used to
develop an initial database design.
Steps in Database Design:-
The process of database design is divided into different parts. It consists of a series of
steps. They are

 Requirement Analysis
 Conceptual Database Design (ER-Diagram)
 Logical Database Design (Tables, Normalization etc)
 Schema refinement
 Physical Database design (Table Indexing, Clustering etc)
 Application development & security

Requirement 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. It makes use of various information gathering methods for this purpose.
Some of them are

 Interview
 Analyzing documents
 Survey
 Site visit

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. This step is often carried out
using the ER model. ER diagram consists of Entities, Attributes and Relationships.

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. We will consider only relational DBMSs, and
therefore, the task in the logical design step is to convert an ER schema into a
relational database schema.

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 refine it
by normalizing relations and restructuring them.
Physical Database Design: It deals with the physical implementation of the database
in a database management system. 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. All these
information are stored in the data dictionary.

Application and Security Design: Any software project that involves a DBMS must
consider aspects of the application that go beyond the database itself. Design
methodologies like UML try to address the complete software design and development
cycle. Briefly, 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 every
process that is reflected in some application task, as part of a complete workflow for
that task. For each role, we must identify the parts of the database that must be
accessible and the parts of the database that must not be accessible, and we must take
steps to ensure that these access rules are enforced.

ENTITIES, ATTRIBUTES, AND ENTITY SETS:-

Entities: - An entity is a thing or object in the real world that is distinguishable from
all other objects. For example ‘Person’ in an organization is an entity. An entity has a
set of properties. At the E-R modeling level an entity actually refers to an entity set. In
other words, entity in ER model corresponds to a table. The ER model refers to a
specific table row as an entity instance or entity occurrence.

Entity set:-Collection of similar entities (Entity Set) often corresponds to a table. Each
entity set has a key. All entities in an entity set have the same set of attributes. Thus
entity set is a set of entities of the same type that share the same properties or
attributes. An entity is represented by a rectangle containing the entity name.

Fig: Employees Entity set

Attributes: - An entity is described using a set of attributes. All entities in a given

entity set have the same attributes. It corresponds to a field in a table. For each
attribute there is a set of permitted values called the domain or value set of the
attribute. For example, the domain associated with the attribute name of Employees
might be the set of 20-character strings. Attributes are represented by ovals and are
connected to the entity with a line. Each oval contains the name of the attribute it
represents.

Relationship: - A relationship is an association among two or more entities. In ER

model the association among entities is described as one-to-one, one-to-many, many-
to-many. Relationships are represented by a diamond connected to the related entities.
The relationship name (an active or passive verb), is written inside the diamond.

Relationship set: - Collection of similar relationships is called relationship set.

Fig. The Works-ln Relationship Set

An instance of a relationship set is a set of relationships. An instance of the Works-ln

relationship set is shown in below figure.

Each Employees entity is denoted by its ssn, and each Departments entity is denoted
by its did, for simplicity. The since value is shown beside each relationship.

Attribute Types:
In ER Model attributes can be classified into the following types.

 Simple and Composite Attribute

 Single Valued and Multi Valued attribute
 Stored and Derived Attributes
 Complex Attribute

Simple and Composite Attribute: - Simple attribute that consist of a single atomic
value. A composite attribute is an attribute that can be further subdivided. For
example the attribute ADDRESS can be subdivided into street, city, state, and zip
code. A simple attribute cannot be subdivided. For example the attributes age, sex etc
are simple attributes.

Single Valued and Multi Valued Attribute: - A single valued attribute can have only a
single value. For example a person can have only one 'date of birth', 'age' etc. That is a
single valued attributes can have only single value. But it can be simple or composite
attribute. That is 'date of birth' is a composite attribute, 'age' is a simple attribute. But
both are single valued attributes.

Multi valued attributes can have multiple values. For instance a person may have
multiple phone numbers, multiple degrees etc.Multivalued attributes are shown by a
double line connecting to the entity in the ER diagram.

Stored and Derived Attributes: - The value for the derived attribute is derived from
the stored attribute (An attribute that supplies a value to the related attribute). For
example 'Date of birth' of a person is a stored attribute. The value for the attribute
'AGE' can be derived by subtracting the 'Date of Birth'(DOB) from the current date.
Stored attribute supplies a value to the related attribute.

Complex Attribute: - A complex attribute that is both composite and multi valued.
Descriptive attributes: - are used to record information about the relationship, rather
than about any one of the participating entities

Types of relationships:-

A relationship's degree indicates the number of associated entities or participants.

 Unary Relationship
 Binary Relationship
 Ternary Relationship

Unary Relationship:-
The entity sets that participate in a relationship set need not be distinct; sometimes a
relationship might involve two entities in the same entity set. For example, consider
the Reports_To relationship set shown in Figure

Since employees reports to other employees, every relationship in Reports_To is of the

form (emlJ1. emp2), where both empl and emp2 are entities in Employees. However,
they play different roles: empl reports to the managing employee emp2, which is
reflected in the role indicators supervisor and subordinate in, the below Figure.

If an entity set plays more than one role, the role indicator concatenated with an
attribute name from the entity set gives us a unique name for each attribute in the
relationship set. For example, the Reports_To relationship set has attributes
corresponding to the ssn of the supervisor and the ssn of the subordinate, and the
names of these attributes are supervisor_ssn and subordinate_ssn.

Binary Relationship:-
A binary relationship exists when two entities are associated. Below figure shows that
the relationship set Works_In, in which each relationship indicates a department in
which an employee works.

Ternary Relationship:-
A ternary relationship exists when three entities are associated. Suppose that each
department has offices in several locations and we want to record the locations at
which each employee works. This relationship is ternary because we must record an
association between an employee, a department, and a location. The ER diagram for
this variant of Works_In, which we call Works.ln2, is shown in the following Figure.

ADDITIONAL FEATURES OF THE ER MODEL

Here we look at some of the constructs in the ER model that allow us to describe some
subtle properties of the data.

Key Constraints:-
Consider the Works-In relationship, an employee can work in several departments, and
a department can have several employees, as illustrated in the Works_In instance
shown in Figure.

Employee 231-31-5368 has worked in Department 51 since 3/3/93 and in

Department 56 since 2/2/92. Department 51 has two employees.
Now consider another relationship set called Manages between the Employees and
Departments entity sets such that each department has at most one manager,
although a single employee is allowed to manage more than one department. The
restriction that each department has at most one manager is an example of a key
constraint, and it implies that each Departments entity appears in at most one
1Jlanages relationship in any allowable instance of Manages. This restriction is
indicated in the ER diagram of Figure 2.6 by using an arrow from Departments to
Manages. Intuitively, the arrow states that given a Departments entity, we can
uniquely determine the Manages relationship in which it appears. An instance of the
Manages relationship set is shown in Figure 2.7

A relationship set like Manages is sometimes said to be one-to-many, to indicate that

one employee can be associated with many departments (in the capacity of a manager),
whereas each department can be associated with at most one employee as its manager.
In contrast, the Works-.In relationship set, in which an employee is allowed to work in
several departments and a department is allowed to have several employees, is said to
be many-to-many.

If we add the restriction that each employee can manage at most one department to
the Manages relationship set, which would be indicated by adding an arrow from
Employees to Manages in Figure 2.6, we have a one-to-one relationship set.

Key Constraints for Ternary Relationships

In Figure 2.8, we show a ternary relationship with key constraints. Each employee
works in at most one department and at a single location. An instance of the
Works_In3 relationship set is shown in Figure 2.9. Note that each department can be
associated with several employees and locations and each location can be associated
with several departments and employees; however, each employee is associated with a
single department and location.
Participation Constraints
The key constraint on Manages tells us that a department has at most one manager. A
natural question to ask is whether every department has a ‘Inanagel'. Let us say that
every department is required to have a manager. This requirement is an example of a
participation constraint; the participation of the entity set Departments in the
relationship set Manages is said to be total. A participation that is not total is said to
be partial. As an example, the Participation of the entity set Employees in Manages is
partial, since not every employee gets to manage a department.

Consider the Works_In relationship set, it is natural to expect that each employee
works in at least one department and that each department has at least one employee.
This means that the participation of both Employees and Departments in Works_In is
total.

If the participation of an entity set in a relationship set is total, the two are connected
by a thick line; independently, the presence of an arrow indicates a key constraint.

Weak Entities:-
Thus far, we have assumed that the attributes associated with an entity set include a
key. This assumption does not always hold. For example, suppose that employees can
purchase insurance policies to cover their dependents. We wish to record information
about policies, including who is covered by each policy, but this information is really
our only interest in the dependents of an employee. If an employee quits, any policy
owned by the employee is terminated and we want to delete all the relevant policy and
dependent information from the database.

We might choose to identify a dependent by name alone in this situation, since it is

reasonable to expect that the dependents of a given employee have different names.
Thus the attributes of the Dependents entity set might be pname and age. The
attribute pname does not identify a dependent uniquely. Recall that the key for
Employees is ssn; thus we might have two employees called Smethurst and each might
have a son called Joe. Dependents is an example of a weak entity set. A weak entity
can be identified uniquely only by considering some of its attributes in conjunction
with the primary key of another entity, which is called the identifying owner.

The following restrictions must hold:

 The owner entity set and the weak entity set must participate in a one-to- many
relationship set. This relationship set is called the identifying relationship set of
the weak entity set.
 The weak entity set must have total participation in the identifying relationship
set.
For example, a Dependents entity can be identified uniquely only if we take the key of
the owning Employees entity and the pname of the Dependents entity. The set of
attributes of a weak entity set that uniquely identify a weak entity for a given owner
entity is called a partial key of the weak entity set. In our example, pname is a partial
key for Dependents.
Class Hierarchies:-
Sometimes it is natural to classify the entities in an entity set into subclasses. For
example, we might want to talk about an Hourly-Emps entity set and a Contract-Emps
entity set to distinguish the basis on which they are paid. We might have attributes
hours_worked and hourly_wage defined for Hourly_Emps and an attribute contract_id
defined for Contract-Emps. Therefore, the attributes defined for a Hourly_Emps entity
are the attributes for Employees plus Hourly-Emps. We say that the attributes for the
entity set Employees are inherited by the entity set Hourly_Emps and that Hourly-
Emps ISA (read is a) Employees.
A class hierarchy can be viewed in one of two ways:
 Employees is specialized into subclasses. Specialization (top-down approach) is
the process of identifying subsets of an entity set (the super class) that share
some distinguishing characteristic. Typically, the super class is defined first, the
subclasses are defined next and subclass-specific attributes and relationship
sets are then added.
 Hourly-Emps and ContracLEmps are generalized by Employees. As another
example, two entity_sets Motorboats and Cars may be generalized into an entity
set MotoLVehicles. Generalization (bottom-up approach) consists of identifying
some common characteristics of a collection of entity sets and creating a new
entity set that contains entities possessing these common characteristics.
Typically, the subclasses are defined first, the super class is defined next, and
any relationship sets that involve the super class are then defined
We can specify two kinds of constraints with respect to ISA hierarchies, namely,
overlap and covering constraints.
 Overlap constraints determine whether two subclasses are allowed to contain the
same entity. For example, can Attishoo be both a Hourly_Emps entity and a
Contract-Emps entity? Intuitively, no. Can he be both a ContracLEmps entity
and a Senior-Emps entity? Intuitively, yes. We denote this by writing 'Contract-
Emps OVERLAPS Senior-Emps.' In the absence of such a statement, we assume
by default that entity sets are constrained to have no overlap.
 Covering constraints determine whether the entities in the subclasses
collectively include all entities in the super class. For example, does every
Employees entity have to belong to one of its subclasses? Intuitively, no. Does
every Motor Vehicles entity have to be either a Motorboats entity or a Cars
entity? Intuitively, yes; a characteristic property of generalization hierarchies is
that every instance of a super class is an instance of a subclass. We denote this
by writing 'Motorboats AND Cars COVER Motor-Vehicles.' In the absence of such
a statement, we assume by default that there is no covering constraint; we can
have motor vehicles that are not motorboats or cars.

Aggregation:-
Used when we have to model a relationship involving (entitity sets and) a relationship
set. Aggregation allows us to treat a relationship set as an entity set for purposes of
participation in (other) relationships.
Suppose that we have an entity set called Projects and that each Projects entity is
sponsored by one or more departments. The Sponsors relationship set captures this
information. A department that sponsors a project might assign employees to monitor
the sponsorship. Intuitively, Monitors should be a relationship set that associates a
Sponsors relationship (rather than a Projects or Departments entity) with an
Employees entity. However, we have defined relationships to associate two or more
entities.
To define a relationship set such as Monitors, we introduce a new feature of the ER
model, called aggregation. Aggregation allows us to indicate that a relationship set
(identified through a dashed box) participates in another relationship set. This is
illustrated in Figure 2.13, with a dashed box around Sponsors (and its participating
entity sets) used to denote aggregation. This effectively allows us to treat Sponsors as
an entity set for purposes of defining the Monitors relationship set.
CONCEPTUAL DESIGN WITH THE ER MODEL
Developing an ER diagram presents several choices, including the following:
 Should a concept be modeled as an entity or an attribute?
 Should a concept be modeled &'3 an entity or a relationship?
 What arc the relationship sets and their participating entity sets? Should we use
binary or ternary relationships?
 Should we use aggregation?
We now discuss the issues involved in making these choices.

Entity versus Attribute

While identifying the attributes of an entity set, it is sometimes not clear whether a
property should be modeled as an attribute or as an entity set (and related to the first
entity set using a relationship set). For example, consider adding address information
to the Employees entity set. One option is to use an attribute address. This option is
appropriate if we need to record only one address per employee, and it suffices to think
of an address as a string. An alternative is to create an entity set called Addresses and
to record associations between employees and addresses using a relationship (say,
Has_Address).
This more complex alternative is necessary in two situations:
 We have to record more than one address for an employee.
 We want to capture the structure of an address in our ER diagram. For example,
we might break down an address into city, state, country, and Zip code, in
addition to a string for street information. By representing an address as an
entity with these attributes, we can support queries such as "Find all employees
with an address in Madison, WI."

Works_In4 does not allow an employee to work in a department for two or more
periods .A relationship is uniquely identified by the participating entities.
Similar to the problem of wanting to record several addresses for an employee: We
want to record several values of the descriptive attributes for each instance of this
relationship.
 Accomplished by introducing new entity set, Duration.
 Set-valued, then attribute