MODULE 2

Database Design

• Conceptual design: (ER Model is used at this stage.)

– What are the entities and relationships in the
enterprise?
– What information about these entities and
relationships should we store in the database?
– What are the integrity constraints or business rules
that hold?
– A database `schema’ in the ER Model can be
represented pictorially (ER diagrams).
– Can map an ER diagram into a relational schema.

Slide No:L2-1
 Overview of Database Design Process

Slide 3- 3
 Modeling
• A database can be modeled as:
– a collection of entities,
– relationship among entities.
• An entity is an object that exists and is
distinguishable from other objects.
– Example: specific person, company, event, plant
• Entities have attributes
– Example: people have names and addresses
• An entity set is a set of entities of the same type
that share the same properties.
– Example: set of all persons, companies, trees,
holidays
Entity Sets customer and loan
customer_id customer_ customer_ customer_ loan_ amount
name street city number

Slide No:L2-3
Example COMPANY Database
 We need to create a database schema design
based on the following (simplified) requirements
of 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 unique name,
unique number and is located at a single location.

Copyright © 2007 Ramez Elmasr and Shamkant B. Navathei Slide 3- 6

Example COMPANY Database
(Contd.)
 We store each EMPLOYEE’s social security
number, address, salary, sex, and birthdate.

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 track of their name,
sex, birthdate, and relationship to the employee.

Copyright © 2007 Ramez Elmasr and Shamkant B. Navathei Slide 3- 7

ER Model Concepts
 Entities and Attributes

Entities are specific objects or things in the mini-world that
are represented in the database.

For example the EMPLOYEE John Smith, the Research
DEPARTMENT, the ProductX PROJECT

Attributes are properties used to describe an entity.

For example an EMPLOYEE entity may have the attributes
Name, SSN, Address, Sex, BirthDate

A specific entity will have a value for each of its attributes.

For example a specific employee entity may have
Name='John Smith', SSN='123456789', Address ='731,
Fondren, Houston, TX', Sex='M', BirthDate='09-JAN-55‘

Each attribute has a value set (or data type) associated with
it – e.g. integer, string, subrange, enumerated type, …

Copyright © 2007 Ramez Elmasr and Shamkant B. Navathei Slide 3- 8

Attributes
 An entity is represented by a set of attributes, that is
descriptive properties possessed by all members of an
entity set.
Example:
customer = (customer_id, customer_name,
customer_street, customer_city )
loan = (loan_number, amount )
 Domain – the set of permitted values for each attribute
 Attribute types:
 Simple and composite attributes.

 Single-valued and multi-valued attributes


Example: multivalued attribute: phone_numbers
 Derived attributes


Can be computed from other attributes

Example: age, given date_of_birth

Slide No:L5-2
Copyright © 2007 Ramez Elmasr and Shamkant B. Navathei
Composite Attributes

Slide No:L5-2
Copyright © 2007 Ramez Elmasr and Shamkant B. Navathei
Types of Attributes (1)
 Simple

Each entity has a single atomic value for the attribute. For
example, SSN or Sex.
 Composite

The attribute may be composed of several components. For
example:

Address(Apt#, House#, Street, City, State, ZipCode, Country), or

Name(FirstName, MiddleName, LastName).

Composition may form a hierarchy where some components
are themselves composite.
 Multi-valued

An entity may have multiple values for that attribute. For
example, Color of a CAR or PreviousDegrees of a STUDENT.

Denoted as {Color} or {PreviousDegrees}.

Copyright © 2007 Ramez Elmasr and Shamkant B. Navathei Slide 3- 11

Types of Attributes (2)
 In general, composite and multi-valued attributes
may be nested arbitrarily to any number of levels,
although this is rare.
 For example, PreviousDegrees of a STUDENT is
a composite multi-valued attribute denoted by
{PreviousDegrees (College, Year, Degree, Field)}
 Multiple PreviousDegrees values can exist
 Each has four subcomponent attributes:

College, Year, Degree, Field

Copyright © 2007 Ramez Elmasr and Shamkant B. Navathei Slide 3- 12

Example of a composite attribute

Copyright © 2007 Ramez Elmasr and Shamkant B. Navathei Slide 3- 13

Entity Types and Key Attributes (1)
 Entities with the same basic attributes are
grouped or typed into an entity type.
 For example, the entity type EMPLOYEE
and PROJECT.
 An attribute of an entity type for which each
entity must have a unique value is called a
key attribute of the entity type.
 For example, SSN of EMPLOYEE.

Copyright © 2007 Ramez Elmasr and Shamkant B. Navathei Slide 3- 14

Entity Types and Key Attributes (2)
 A key attribute may be composite.
 VehicleTagNumber is a key of the CAR entity

type with components (Number, State).

 An entity type may have more than one key.
 The CAR entity type may have two keys:


VehicleIdentificationNumber (popularly called VIN)

VehicleTagNumber (Number, State), aka license
plate number.
 Each key is underlined

Copyright © 2007 Ramez Elmasr and Shamkant B. Navathei Slide 3- 15

Displaying an Entity type
 In ER diagrams, an entity type is displayed in a
rectangular box
 Attributes are displayed in ovals
 Each attribute is connected to its entity type
 Components of a composite attribute are
connected to the oval representing the composite
attribute
 Each key attribute is underlined
 Multivalued attributes displayed in double ovals
 See CAR example on next slide

Copyright © 2007 Ramez Elmasr and Shamkant B. Navathei Slide 3- 16

Entity Type CAR with two keys and a
corresponding Entity Set

Copyright © 2007 Ramez Elmasr and Shamkant B. Navathei Slide 3- 17

Entity Set
 Each entity type will have a collection of entities
stored in the database
 Called the entity set
 Previous slide shows three CAR entity instances
in the entity set for CAR
 Same name (CAR) used to refer to both the entity
type and the entity set
 Entity set is the current state of the entities of that
type that are stored in the database

Copyright © 2007 Ramez Elmasr and Shamkant B. Navathei Slide 3- 18

Initial Design of Entity Types for the
COMPANY Database Schema

 Based on the requirements, we can identify four

initial entity types in the COMPANY database:
 DEPARTMENT
 PROJECT
 EMPLOYEE
 DEPENDENT
 Their initial design is shown on the following slide
 The initial attributes shown are derived from the
requirements description

Copyright © 2007 Ramez Elmasr and Shamkant B. Navathei Slide 3- 19

Initial Design of Entity Types:
EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT

Copyright © 2007 Ramez Elmasr and Shamkant B. Navathei Slide 3- 20

Mapping Cardinality Constraints

• Express the number of entities to which another

entity can be associated via a relationship set.
• Most useful in describing binary relationship sets.
• For a binary relationship set the mapping
cardinality must be one of the following types:
– One to one
– One to many
– Many to one
– Many to many

Slide No:L2-6
 Mapping Cardinalities

One to one One to many

Note: Some elements in A and B may not be mapped to any
elements in the other set

Slide No:L2-7
 Mapping Cardinalities

Many to one Many to many

Note: Some elements in A and B may not be mapped to any
elements in the other set

Slide No:L2-8
 ER Model Basics

name
ssn lot

Employees

• Entity: Real-world object distinguishable from other

objects. An entity is described (in DB) using a set of
attributes.
• Entity Set: A collection of similar entities. E.g., all
employees.
– All entities in an entity set have the same set of
attributes. (Until we consider ISA hierarchies,
anyway!)
– Each entity set has a key.
– Each attribute has a domain.
Slide No:L2-9
 ER Model Basics (Contd.)
name

ssn lot
since
name dname
ssn lot did budget Employees

super- subord
Employees Works_In Departments visor inate
Reports_To

• Relationship: Association among two or more entities. E.g.,

Attishoo works in Pharmacy department.
• Relationship Set: Collection of similar relationships.
– An n-ary relationship set R relates n entity sets E1 ... En;
each relationship in R involves entities e1 E1, ..., en En
• Same entity set could participate in different
relationship sets, or in different “roles” in same set.

Slide No:L2-10
 Relationship Sets
• A relationship is an association among several
entities
Example:
Hayes depositor A-102
customer entityrelationship setaccount entity
• A relationship set is a mathematical relation
among n  2 entities, each taken from entity sets
{(e1, e2, … en) | e1  E1, e2  E2, …, en 
En}

where (e1, e2, …, en) is a relationship

– Example:
(Hayes, A-102)  depositor

Slide No:L3-1
Relationship Set borrower

Slide No:L3-2
 Relationship Sets (Cont.)
• An attribute can also be property of a relationship set.
• For instance, the depositor relationship set between entity
sets customer and account may have the attribute access-
date

Slide No:L3-3
 Degree of a Relationship Set

• Refers to number of entity sets that

participate in a relationship set.
• Relationship sets that involve two entity
sets are binary (or degree two).
Generally, most relationship sets in a
database system are binary.
• Relationship sets may involve more
than two entity sets.

Slide No:L3-4
 Degree of a Relationship Set
Example: Suppose employees of a bank
may have jobs (responsibilities) at
multiple branches, with different jobs at
different branches. Then there is a
ternary relationship set between entity
sets employee, job, and branch
• Relationships between more than two entity sets
are rare. Most relationships are binary. (More on
this later.)

Slide No:L3-5
 Additional
since
features of the name dname
ER model
ssn lot did budget

Key Constraints
Employees Manages Departments

• Consider Works_In:
An employee can
work in many
departments; a dept
can have many
employees.
• In contrast, each
dept has at most one
manager, according
to the key
constraint on 1-to-1 1-to Many Many-to-1 Many-to-Many
Manages.
Slide No:L4-1
 Participation Constraints
• Does every department have a manager?
– If so, this is a participation constraint: the
participation of Departments in Manages is said to be
total (vs. partial).
• Every Departments entity must appear in an
instance of the Manages relationship.
since
name dname
ssn lot did budget

Employees Manages Departments

Works_In

since

Slide No:L4-2
 Weak Entities
• A weak entity can be identified uniquely only by considering the
primary key of another (owner) entity.
– Owner entity set and weak entity set must participate in a
one-to-many relationship set (one owner, many weak
entities).
– Weak entity set must have total participation in this
identifying relationship set.

name
cost pname age
ssn lot

Employees Policy Dependents

Slide No:L4-3
 Weak Entity Sets
• An entity set that does not have a primary key is referred
to as a weak entity set.
• The existence of a weak entity set depends on the
existence of a identifying entity set
– it must relate to the identifying entity set via a total,
one-to-many relationship set from the identifying to the
weak entity set
– Identifying relationship depicted using a double diamond
• The discriminator (or partial key) of a weak entity set is
the set of attributes that distinguishes among all the
entities of a weak entity set.
• The primary key of a weak entity set is formed by the
primary key of the strong entity set on which the weak
entity set is existence dependent, plus the weak entity set’s
discriminator.

Slide No:L4-4
 Weak Entity Sets (Cont.)
• We depict a weak entity set by double rectangles.
• We underline the discriminator of a weak entity set with a
dashed line.
• payment_number – discriminator of the payment entity set
• Primary key for payment – (loan_number, payment_number)

Slide No:L4-5
 Weak Entity Sets (Cont.)

• Note: the primary key of the strong entity set is

not explicitly stored with the weak entity set,
since it is implicit in the identifying relationship.
• If loan_number were explicitly stored, payment
could be made a strong entity, but then the
relationship between payment and loan would
be duplicated by an implicit relationship defined
by the attribute loan_number common to
payment and loan

Slide No:L4-6
 More Weak Entity Set Examples

• In a university, a course is a strong entity and a

course_offering can be modeled as a weak entity
• The discriminator of course_offering would be semester
(including year) and section_number (if there is more than
one section)
• If we model course_offering as a strong entity we would
model course_number as an attribute.
Then the relationship with course would be implicit in the
course_number attribute

Slide No:L4-7
 ISA (`is a’) Hierarchies
name
 As in C++, or other PLs, ssn lot

attributes are inherited.

 If we declare A ISA B, Employees

every A entity is also hourly_wages hours_worked

considered to be a B ISA
contractid
entity.
Contract_Emps
Hourly_Emps

• Overlap constraints: Can Joe be an Hourly_Emps as well as a

Contract_Emps entity? (Allowed/disallowed)
• Covering constraints: Does every Employees entity also have
to be an Hourly_Emps or a Contract_Emps entity? (Yes/no)
• Reasons for using ISA:
– To add descriptive attributes specific to a subclass.
– To identify entitities that participate in a relationship.

Slide No:L5-1
 Aggregation
• Used when we have name
ssn lot
to model a
relationship involving Employees
(entitity sets and) a
relationship set.
– Aggregation Monitors until
allows us to treat
a relationship set
as an entity set started_on since
dname
for purposes of pid pbudget did
participation in budget
(other) Projects Sponsors Departments
relationships.

 Aggregation vs. ternary relationship:

Monitors is a distinct relationship, with a descriptive attribute.
 Also, can say that each sponsorship is monitored by at most one

employee.
Slide No:L5-2
 Aggregation
Consider the ternary relationship works_on, which we
saw earlier
 Suppose we want to record managers for tasks
performed by an employee at a branch

Slide No:L5-3
 Aggregation (Cont.)
• Relationship sets works_on and manages represent
overlapping information
– Every manages relationship corresponds to a
works_on relationship
– However, some works_on relationships may not
correspond to any manages relationships
• So we can’t discard the works_on relationship
• Eliminate this redundancy via aggregation
– Treat relationship as an abstract entity
– Allows relationships between relationships
– Abstraction of relationship into new entity

Slide No:L5-4
 Aggregation (Cont.)
• Eliminate this redundancy via aggregation
– Treat relationship as an abstract entity
– Allows relationships between relationships
– Abstraction of relationship into new entity
• Without introducing redundancy, the following
diagram represents:
– An employee works on a particular job at a
particular branch
– An employee, branch, job combination may have
an associated manager

Slide No:L5-5
E-R Diagram With Aggregation

Slide No:L5-6
 Conceptual Design Using the ER Model

• Design choices:
– Should a concept be modeled as an entity or an
attribute?
– Should a concept be modeled as an entity or a
relationship?
– Identifying relationships: Binary or ternary?
Aggregation?
• Constraints in the ER Model:
– A lot of data semantics can (and should) be captured.
– But some constraints cannot be captured in ER
diagrams.

Slide No:L6-1
 Entity vs. Attribute
• Should address be an attribute of Employees or an entity
(connected to Employees by a relationship)?
• Depends upon the use we want to make of address
information, and the semantics of the data:
• If we have several addresses per employee,
address must be an entity (since attributes cannot
be set-valued).
• If the structure (city, street, etc.) is important, e.g.,
we want to retrieve employees in a given city,
address must be modeled as an entity (since
attribute values are atomic).

Slide No:L6-2
 Entity vs. Attribute (Contd.)
• Works_In4 does not
allow an employee
from to
to work in a name dname
department for ssn lot did budget
two or more periods.
• Similar to the Employees Works_In4 Departments
problem of wanting
to record several
addresses for an
employee: We want
to record several
values of the ssn
name dname
lot did budget
descriptive attributes
for each instance of Employees Works_In4 Departments
this relationship.
Accomplished by
introducing new from Duration to
entity set, Duration.
Slide No:L6-3
 Entity vs. Relationship

• First ER diagram OK if a
manager gets a since dbudget
name dname
separate discretionary ssn lot did budget
budget for each dept.
• What if a manager gets Employees Manages2 Departments
a discretionary budget
that covers all
managed depts? name
ssn lot
– Redundancy:
since dname
dbudget stored for did
Employees budget
each dept managed
by manager.
Manages2 Departments
– Misleading: Suggests ISA
dbudget associated
with department-mgr This fixes the
combination. Managers dbudget
problem!
Slide No:L6-4
 Binary vs. Ternary Relationships

• If each policy is name

owned by just 1 ssn lot pname age
employee, and Employees Dependents
Covers
each dependent
is tied to the Bad design Policies
covering policy,
first diagram is policyid cost
inaccurate. name pname age
ssn lot
• What are the
additional Dependents
Employees
constraints in
the 2nd Purchaser
Beneficiary
diagram?
Better design Policies

Slide No:L6-5
policyid cost
 Binary vs. Ternary Relationships
(Contd.)

• Previous example illustrated a case when two binary

relationships were better than one ternary relationship.
• An example in the other direction: a ternary relation
Contracts relates entity sets Parts, Departments and
Suppliers, and has descriptive attribute qty. No
combination of binary relationships is an adequate
substitute:
– S “can-supply” P, D “needs” P, and D “deals-with”
S does not imply that D has agreed to buy P from S.
– How do we record qty?

Slide No:L6-6
 Logical DB Design: ER to Relational

• Entity sets to tables:

CREATE TABLE
name
Employees
ssn lot (ssn CHAR(11),
name CHAR(20),
Employees lot INTEGER,
PRIMARY KEY
(ssn))

Slide No:L3-1
 Relationship Sets to Tables

• In translating a relationship set to

a relation, attributes of the
relation must include: CREATE TABLE Works_In(
– Keys for each participating ssn CHAR(11),
entity set (as foreign keys). did INTEGER,
• This set of attributes since DATE,
forms a superkey for
PRIMARY KEY (ssn, did),
the relation.
– All descriptive attributes. FOREIGN KEY (ssn)
REFERENCES Employees,
FOREIGN KEY (did)
REFERENCES Departments

Slide No:L3-2
 Review: Key Constraints

• Each dept has at most

one manager,
according to the key since
constraint on Manages. name dname
ssn lot did budget

Employees Manages Departments

Translation to
relational model?

1-to-1 1-to Many Many-to-1 Many-to-Many

Slide No:L3-3
 Translating ER Diagrams with Key
Constraints
• Map relationship to a
table: CREATE TABLE Manages(
– Note that did is the ssn CHAR(11),
key now! did INTEGER,
– Separate tables for since DATE,
Employees and PRIMARY KEY (did),
Departments. FOREIGN KEY (ssn) REFERENCES
• Since each department Employees,
has a unique manager, FOREIGN KEY (did) REFERENCES
we could instead Departments)
combine Manages and CREATE TABLE Dept_Mgr(
Departments. did INTEGER,
dname CHAR(20),
budget REAL,
ssn CHAR(11),
since DATE,
PRIMARY KEY (did),
FOREIGN KEY (ssn) REFERENCES Employees)

Slide No:L3-4
 Review: Participation Constraints

• Does every department have a manager?

– If so, this is a participation constraint: the participation of
Departments in Manages is said to be total (vs. partial).
• Every did value in Departments table must appear in a row
of the Manages table (with a non-null ssn value!)

since
name dname
ssn lot did budget

Employees Manages Departments

Works_In

since

Slide No:L3-5
 Participation Constraints in SQL

• We can capture participation constraints involving one entity set in a

binary relationship, but little else (without resorting to CHECK
constraints).

CREATE TABLE Dept_Mgr(

did INTEGER,
dname CHAR(20),
budget REAL,
ssn CHAR(11) NOT NULL,
since DATE,
PRIMARY KEY (did),
FOREIGN KEY (ssn) REFERENCES Employees,
ON DELETE NO ACTION)

Slide No:L3-6
 Review: Weak Entities

• A weak entity can be identified uniquely only by considering the primary

key of another (owner) entity.
– Owner entity set and weak entity set must participate in a one-to-
many relationship set (1 owner, many weak entities).
– Weak entity set must have total participation in this identifying
relationship set.

name
cost pname age
ssn lot

Employees Policy Dependents

Slide No:L4-1
 Translating Weak Entity Sets

• Weak entity set and identifying relationship set are translated

into a single table.
– When the owner entity is deleted, all owned weak entities
must also be deleted.

CREATE TABLE Dep_Policy (

pname CHAR(20),
age INTEGER,
cost REAL,
ssn CHAR(11) NOT NULL,
PRIMARY KEY (pname, ssn),
FOREIGN KEY (ssn) REFERENCES Employees,
ON DELETE CASCADE)

Slide No:L4-2
 Review: ISA Hierarchies

name
 As in C++, or other ssn lot
PLs, attributes are
inherited. Employees

 If we declare A ISA
hourly_wages hours_worked
B, every A entity is ISA
contractid
also considered to be
a B entity. Contract_Emps
Hourly_Emps

• Overlap constraints: Can Joe be an Hourly_Emps as well as a

Contract_Emps entity? (Allowed/disallowed)
• Covering constraints: Does every Employees entity also have to be
an Hourly_Emps or a Contract_Emps entity? (Yes/no)

Slide No:L4-3
 Translating ISA Hierarchies to Relations

• General approach:
– 3 relations: Employees, Hourly_Emps and Contract_Emps.
• Hourly_Emps: Every employee is recorded in
Employees. For hourly emps, extra info recorded in
Hourly_Emps (hourly_wages, hours_worked, ssn);
must delete Hourly_Emps tuple if referenced
Employees tuple is deleted).
• Queries involving all employees easy, those involving
just Hourly_Emps require a join to get some attributes.
• Alternative: Just Hourly_Emps and Contract_Emps.
– Hourly_Emps: ssn, name, lot, hourly_wages, hours_worked.
– Each employee must be in one of these two subclasses.

Slide No:L4-4
 Review: Binary vs. Ternary
Relationships
name
ssn lot pname age
• What are the
additional Employees Covers
constraints in the
Dependents
2nd diagram? Bad design Policies

policyid cost

name pname age

ssn lot
Dependents
Employees

Purchaser
Beneficiary

Better design Policies

Slide No:L4-5
policyid cost
 Binary vs. Ternary Relationships
(Contd.)
CREATE TABLE Policies (
• The key
constraints allow policyid INTEGER,
us to combine cost REAL,
Purchaser with ssn CHAR(11) NOT NULL,
Policies and PRIMARY KEY (policyid).
Beneficiary with FOREIGN KEY (ssn) REFERENCES Employees
Dependents. ON DELETE CASCADE)
• Participation CREATE TABLE Dependents (
constraints lead pname CHAR(20),
to NOT NULL
age INTEGER,
constraints.
policyid INTEGER,
• What if Policies
PRIMARY KEY (pname, policyid).
is a weak entity
set? FOREIGN KEY (policyid) REFERENCES Policies
ON DELETE CASCADE)
Slide No:L4-6
 Views

• A view is just a relation, but we store a definition, rather than

a set of tuples.

CREATE VIEW YoungActiveStudents (name, grade)

AS SELECT S.name, E.grade
FROM Students S, Enrolled E
WHERE S.sid = E.sid and S.age<21

 Views can be dropped using the DROP VIEW command.

 How to handle DROP TABLE if there’s a view on the table?

• DROP TABLE command has options to let the user

specify this.

Slide No:L5-1
 Views and Security

• Views can be used to present necessary information (or

a summary), while hiding details in underlying
relation(s).
– Given YoungStudents, but not Students or Enrolled,
we can find students s who have are enrolled, but
not the cid’s of the courses they are enrolled in.

Slide No:L5-2
 View Definition
• A relation that is not of the conceptual model but is
made visible to a user as a “virtual relation” is
called a view.
• A view is defined using the create view statement
which has the form

create view v as < query expression >

where <query expression> is any legal SQL
expression. The view name is represented by v.
• Once a view is defined, the view name can be used
to refer to the virtual relation that the view
generates.

Slide No:L5-3
 Example Queries
• A view consisting of branches and their customers
create view all_customer as
(select branch_name, customer_name
from depositor, account
where depositor.account_number =
account.account_number )
union
(select branch_name, customer_name
from borrower, loan
where borrower.loan_number = loan.loan_number )

 Find all customers of the Perryridge branch

select customer_name
from all_customer
where branch_name = 'Perryridge'

Slide No:L5-4
 Uses of Views
• Hiding some information from some users
– Consider a user who needs to know a customer’s name, loan
number and branch name, but has no need to see the loan
amount.
– Define a view
(create view cust_loan_data as
select customer_name, borrower.loan_number,
branch_name
from borrower, loan
where borrower.loan_number = loan.loan_number )
– Grant the user permission to read cust_loan_data, but not
borrower or loan
• Predefined queries to make writing of other queries easier
– Common example: Aggregate queries used for statistical
analysis of data

Slide No:L5-5
 Processing of Views
• When a view is created
– the query expression is stored in the database along with the
view name
– the expression is substituted into any query using the view
• Views definitions containing views
– One view may be used in the expression defining another view
– A view relation v1 is said to depend directly on a view relation
v2 if v2 is used in the expression defining v1
– A view relation v1 is said to depend on view relation v2 if either
v1 depends directly to v2 or there is a path of dependencies
from v1 to v2
– A view relation v is said to be recursive if it depends on itself.

Slide No:L5-6
 View Expansion
• A way to define the meaning of views defined in terms of
other views.
• Let view v1 be defined by an expression e1 that may itself
contain uses of view relations.
• View expansion of an expression repeats the following
replacement step:
repeat
Find any view relation vi in e1
Replace the view relation vi by the expression
defining vi
until no more view relations are present in e1
• As long as the view definitions are not recursive, this loop
will terminate

Slide No:L5-7
 Summary of Conceptual Design

• Conceptual design follows requirements analysis,

– Yields a high-level description of data to be stored

• ER model popular for conceptual design

– Constructs are expressive, close to the way people think
about their applications.
• Basic constructs: entities, relationships, and attributes (of
entities and relationships).
• Some additional constructs: weak entities, ISA hierarchies,
and aggregation.
• Note: There are many variations on ER model.

Slide No:L7-1
 Summary of ER (Contd.)

• Several kinds of integrity constraints can be expressed in

the ER model: key constraints, participation constraints,
and overlap/covering constraints for ISA hierarchies. Some
foreign key constraints are also implicit in the definition of a
relationship set.
– Some constraints (notably, functional dependencies)
cannot be expressed in the ER model.
– Constraints play an important role in determining the
best database design for an enterprise.

Slide No:L7-2
 Summary of ER (Contd.)

• ER design is subjective. There are often many ways to

model a given scenario! Analyzing alternatives can be
tricky, especially for a large enterprise. Common
choices include:
– Entity vs. attribute, entity vs. relationship, binary or
n-ary relationship, whether or not to use ISA
hierarchies, and whether or not to use aggregation.
• Ensuring good database design: resulting relational
schema should be analyzed and refined further. FD
information and normalization techniques are especially
useful.

Slide No:L7-3