Advance Database Systems

Advance Database Systems
Lec 2
Advance Database Systems Dr. Mukaram MCS

Entity Relationship Data Model
ERD Model

Example
The following gives the requirements for the IMDB.
 IMDB records the information about each studio, such as studio name, year established, year closed (if applicable),
country, etc.
 The system records overall movie information, such as movie title, tagline, genre, year made, country, website,
running time, language, colour, rating, showing start date, ranking, etc.
 Tagline is a one-sentence description of a movie.
 Values of colour could be “True” or “False” for colour movie or black/white movie respectively.
 Rating could be “G”, “PG”, “M”, “MA”, etc.
 Studios produce movies.
 The genre describes the type of a movie, such as “comedy”, “drama”, “biography”, “action”, “thriller”, “horror”,
“romance”, “war”, “animation”, “adventure”, etc. One movie may have more than one genre.
 You may record the people involved with the movies with their titles, family names, given names, genders,
websites, emails, dates of birth, cities of birth, countries of birth, and other necessary information.
 A casts is actor or actress in a movie.
 Crews are staff other than casts involved with a movie, such as “Director”.
 You should record each role’s name for casts. For example, “Actor of leading role”, “Actor of supporting
role”, etc.
 You should record each job title for crews. For example, “Director”, “Producer”, “Writer”, etc.
 You may assume a person only performs one role in a movie.
 IMDB records the name of each part in a movie, also records the job title for each crew in a movie.
 There are many movie awards around the world from different organization. The organization is recorded with
name and country.
 Each organization holds one award ceremony in each year.
 You should record the award and nominations with title, category, etc.
o Award titles could be classified as to two categories: for person (such as “Best Actor of leading role”, “Best
Director”) or for movie “Best movie”, etc.
o There will be many nominations for an award in a given year, but only one winner for the award in that
year.
o An award may been won many times, or may have never been awarded (or nominated)
 Movies released will be shown in cinemas. You should record cinema name, phone number, website, number of
screen, Database
Advance street, city, state, country, etc.
Systems Dr. Mukaram MCS
Example

Example
• MOVIE {MovieID number primary key • PEOPLE{ PeopleID number primary key
GenreID text (20) foreign key reference to Title text(35)
GENRE Tagline text(50) FamilyName text(20)
StreetName text(35) GivenName text(35)
YearMade number Gender text(1)
Country text(35) Website text(35)
Website text(35) Email text(50)
RunningTime time DateofBirth date
Language text(20) CityofBirth text(35)
Colour bit CountryofBirth
Rating text(2) text(35)}
ShowingStartDate date • MOVIE_PEOPLE {MovieID number primary key
Ranking number} foreign key reference to MOVIE
• STUDIO {StudioID PeopleID number primary key
number primary key foreign key reference to PEOPLE}
StudioName text(35) • CREW {PeopleID number primary key
YearEstablished foreign key reference to PEOPLE
date YearClosed JobTitle text(35)}
date Country • CAST {PeopleID number primary key
text(35)} foreign key reference to PEOPLE
• MOVIE_PRODUCE RoleName text(35)}
{StudioID number primary key • AWARD {AwardID number primary key
foreign key reference to STUDIO OrganisationID number
MovieID number primary key foreign key reference to ORGANISATION
foreign key reference to Title text(35)
MOVIE} Year date}
• GENRE {GenreID number primary key
Type text(20)}
Example
• NOMINEE {AwardID number primary key • MOVIE_CINEMA {MovieID number primary key
foreign key reference to AWARD foreign key reference to MOVIE
MovieID number primary key CinemaID number primary key
foreign key reference to MOVIE foreign key reference to CINEMA}
PeopleID number primary key • CITY {CityID number primary key
foreign key reference to PEOPLE} Name text(35)
• ORGANISATION {OrganisationID number State text(35)
primary key Country
Name text(50) text(35)}
Country • SUPERVISOR_CINEMA {CityID number primary
text(35)} key
• CINEMA {CinemaID number primary key foreign key reference to CITY
CityID number CinemaID number primary key
foreign key reference to CITY foreign key reference to CINEMA}
Name text(50)
Country text(35)
PhoneNumber number
Website text(35)
NumberofScreen number
Street text(35)}

Entity/Relationship Model
• An entity is represented by a set of attributes, that is
descriptive properties possessed by all members of
an entity set
• 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
Example:
customer (customer_id, customer_name, customer_street,
customer_city )
loan (loan_number,
Advance Database Systems amount ) Dr. Mukaram MCS

Diagrams to represent designs.

• Entity like object, = “thing.”
• Entity set like class = set of “similar”
entities/objects.
• Attribute = property of entities in an entity set,
similar to fields of a struct.
• In diagrams, entity set  rectangle;
attribute  oval.
ID name phone
Students height

Relationships
• Connect two or more entity sets.
• Represented by diamonds.
Students Takin Courses

g

ERD – Example

Relationship Set
Think of the “value” of a relationship set as a table
• One column for each of the connected entity sets.
• One row for each list of entities, one from each set, that
are connected by the relationship.
Students Courses
Sally CS180
Sally CS111
Joe CS180
… …

Multiway Relationships
• Usually binary relationships (connecting two E.S.)
suffice
• However, there are some cases where three or more E.S.
must be connected by one relationship
• Example: relationship among students, courses, TA's
(and graders).
Students Enrolls Courses
TA/
Graders

Courses
Students Enrolls
TAs
Students Courses TAs

Ann CS180 Jan
Sue CS180 Pat
Bob CS180 Jan
… … …

Pizza-Provider-Customer Example
name addr Services
Serves Pizza Hut Visi

t
Pizza Like Customers
name topping name addr
Advance Database Systems

Attributes Dr. Mukaram MCS
Degree of Relationships
Many-many Many-one One-one
Representation
• E/R: arrow pointing to “one.”

One-One Relationships
Put arrows in both directions.
Best-
Manfs pizza
seller

Attributes on Relationships
price
Pizza Huts Sells Pizza
• Shorthand for 3-way relationship:

price
Prices
Pizza Hut Sells Pizza

• A true 3-way relationship.
 Price depends jointly on manufacturer and
Pizza type
• Notice arrow convention for multiway
relationships: “all other E.S. determine one of
these.”
 Not sufficiently general to express any
possibility
 However, if price, say, depended only on the
Pizza type, then we could use two 2-way
relationships: price-pizza and pizza-
manufacturer
 Or better: just make price an attribute of
pizza
Roles
• Sometimes an E.S. participates more than once in a
relationship.
• Label edges with roles to distinguish.
Husband Wife
d1 d2
d3
Married … d4
husband wife
…
Customer

Buddy1 Buddy2
Buddies d1 d2
d1 d3
1 2 d2 d1
d2 d4
Customer … …
• Design Question
 Should we replace husband and wife by one
relationship spouse?

Four-way relationship

Subclasses
Subclass = special case = fewer entities = more

properties.
• Example: BBQ are a kind of pizza. In addition
to the properties (= attributes and relationships)
of pizza, there is a “color” attribute for BBQ

E/R Subclasses
• Assume subclasses form a tree (no multiple inheritance).
• isa triangles indicate the subclass relation.
name Pizza Type manf
isa
color BBQ Pizza

Different Subclass Viewpoints
• E/R viewpoint: An entity has a component in each entity set
to which it logically belongs.
 Its properties are the union of the properties of these E.S.
• Contrasts with object-oriented viewpoint: An object (entity)
belongs to exactly one class.
 It inherits properties name Pizza manf
of its superclasses.
isa P.Hut’s BBQ
color BBQ

Multiple Inheritance
Theoretically, an E.S. could be a subclass of several
other entity sets.
name manf name manf
Pizza Burger
isa isa
Fast Food

Modeling of Constraints
• Keys (e.g. attribute uniquely identifying an entity)
• Single-value constraints (e.g. unique value)
• Referential integrity constraints (e.g. pointer to an
existing value in another entity)
• Domain constraints (e.g. from star a, b, c and d)
• General constraints (e.g. no more than 10 stars in a
movie)

Keys
• A key is a set of attributes whose values can belong to
at most one entity
• In E/R model, every E.S. must have a key
• A key may consist of more than one attribute
• An E.S. can have more than one key, but one set of
attributes is the “designated” or “primary” key
• In an ‘isa’ hierarchy, key for each entity is found from
its components in the root entity
• In E/R diagrams, you should underline all attributes of
the designated key

Key

Example: A Multiattribute Key
number hours
dept Courses room
• Possibly, the combination of hours + room also

forms a key, but we have not designated it as
such.

Example
• Suppose name is key for
Pizza.
name Pizza manf
isa
color BBQ
• Pizza name is also key for BBQ.

 In general, key at root is key for all.

Single-value Constraints
• Writing a note with an attribute to be unique valued
• Many-one relationship has a single-valued constraint, so
an arrow out of relation indicates a single value constraint

Referential Integrity Constraint
• Refers to relationship among entities
• In many-one relation, in a movie example, no movie can
be owned by more than one studios
• The value of studio should be present in order to own a
movie

Other Constraints
Gen Constraints i.e. no of
stars
Length
[0-240]
Domain

Weak Entity Sets
• If an entity set’s key is composed of attributes, some or
all of which, belong to another entity set
• Causes
 Weak entity existence depends on some other entity
 Entity sets fall into a hierarchy based on classifications
which does not qualify to be an "isa hierarchy“

Weak Entity Sets
• Causes
 the connecting entity sets that are created to eliminate a
multivalued relationship.

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 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 (unique attribute)
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)

Weak Entity Sets (Cont.)
• 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_numbers were explicitly stored, payment could
be made a strong entity

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
are more than one sections)
• 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

Case Study – Problem Statement
• The bank is organized into branches. Each branch is located in a particular city and is
identified by a unique name. The bank monitors the assets of each branch. Bank
customers are identified by their customer-id values. The bank stores each customer's
name and the street and city where the customer lives. Customers may have accounts
and can take out loans. A customer may be associated with a particular banker, who
may act as a loan officer or personal banker for that customer. Bank employees are
identified by their employee-id values. The bank administration stores the name and
telephone number of each employee, the names of the employee's dependents, and the
employee-id number of the employee's manager. The bank also keeps track of the
employee's start date and, thus, length of employment. The bank offers two types of
accounts-savings and checking accounts. Accounts can be held by more than one
customer, and a customer can have more than one account. Each account is assigned a
unique account number. The bank maintains a record of each account's balance and
the most recent date on which the account was accessed by each customer holding the
account. In addition, each savings account has an interest rate and overdrafts are
recorded for each checking account. A loan originates at a particular branch and can
be held by one or more customers. A loan is identified by a unique loan number. For
each loan, the bank keeps track of the loan amount and the loan payments. Although a
loan payment number does not uniquely identify a particular payment among those
for all the bank's loans, a payment number does identify a particular payment for a
specific loan. The date and amount are recorded for each payment.

Case Study – Problem Statement
The bank is organized into branches. Each branch is located in a particular city and is
identified by a unique name. The bank monitors the assets of each branch. Bank
customers are identified by their customer-id values. The bank stores each customer's
name and the street and city where the customer lives. Customers may have accounts and
can take out loans. A customer may be associated with a particular banker, who may act
as a loan officer or personal banker for that customer. Bank employees are identified by
their employee-id values. The bank administration stores the name and telephone number
of each employee, the names of the employee's dependents, and the employee-id number
of the employee's manager. The bank also keeps track of the employee's start date and,
thus, length of employment. The bank offers two types of accounts - savings and
checking accounts. Accounts can be held by more than one customer, and a customer can
have more than one account. Each account is assigned a unique account number. The
bank maintains a record of each account's balance and the most recent date on which the
account was accessed by each customer holding the account. In addition, each savings
account has an interest rate and overdrafts are recorded for each checking account. A
loan originates at a particular branch and can be held by one or more customers. A loan is
identified by a unique loan number. For each loan, the bank keeps track of the loan
amount and the loan payments. Although a loan payment number does not uniquely
identify a particular payment among those for all the bank's loans, a payment number
does identify a particular payment for a specific loan. The date and amount are recorded
for each payment.

Entity Sets
• The branch entity set, with attributes branch_name,
branch_city, and assets
• The customer entity set, with attributes customer_id,
customer_name, customer_street, and customer_city. A
possible additional attribute is banker-name.
• The employee entity set, with attributes employee_id,
employee_name, telephone_number, salary, and
manager. Additional descriptive features are the
multivalued attribute dependent_name, the base
attribute start_date, and the derived attribute
empolyment_length

Entity Sets
• Two account entity sets, saving_account and
checking_account – with the common attributes of
account_number and balance, in addition
savings_account has the attribute interest_rate and
checking_account has an attribute overdraft-amount
• The loan entity set, with the attributes loan_number,
amount, and originating_branch
• The weak entity set loan_payment, with attributes
payment-number, payment_date, and payment_amount

Relationship Sets
• borrower, a many-to-many relationship set between
customer and loan
• loan-branch, a many-to-one relationship set that
indicates in which branch a loan originated. Note that
this relationship set replaces the attribute
originating_branch of the entity set loan
• Loan_payment, a one-to-many relationship from loan to
payment, which documents that a payment is made on
a loan
• depositor, with relationship attribute access_date, a
many-to-many relationship set between customer and
account, indicating that a customer owns an account

Relationship Sets
• Cust_banker, with relationship attribute type, a many-to-one
relationship set expressing that a customer can be advised
by a bank employee, and that a bank employee can advise
one or more customers.
Note that this relationship set has replaced the attribute
banker_name of the entity set customer
• Works_for, a relationship set between employee entities
with role indicators manager and worker; the mapping
cardinalities express that an employee works for only one
manager and that a manager supervises one or more
employees.
Note that this relationship set has replaced the manager
attribute of employee.

Weak Entity Sets
• An entity set that does not have sufficient attributes to
form a primary key
• e.g. payment
 Payment_number is a sequential number starting

from 1 and generated separately for each loan
 Payments for different loans may share the same
payment number
 Thus payment does not have a primary key, so it is
a weak entity

Weak Entity Sets
• For a weak entity set to be meaningful, it must be
associated with a strong entity set, called the identifying or
owner entity set.
• The weak entity set’s existence dependents on its
identifying entity set
• The identifying entity set owns the weak entity set that it
identifies
• The relationship associating the weak entity set with the
identifying entity set is called the identifying relationship
• The identifying relationship is many-to-one from the weak
entity set to the identifying entity set, and the
participation of the weak entity set in the relationship is
total
• e.g. the identifying entity set for payment is loan, and a
relationship loan_payment that associates payment
entities with their corresponding loan entities is the
identifying relationship
Weak Entity Sets
• In order to distinguish among all the entities in the weak entity set that
depend on one particular strong entity, we identify a discriminator of
a weak entity set, which is a set of attributes that allows this
distinction to be made
• e.g. the discriminator of the weak entity set payment is the
attribute payment_number since for each loan, a payment number
uniquely identifies one single payment for that loan
• The discriminator of a weak entity set is also called the partial key
of
the entity set
• The primary key of a weak entity set is formed by the primary key of
the identifying entity set, plus the weak entity set's discriminator
• In the case of the entity set payment, its primary key is {loan_number,
payment_number}, where loan_number is the primary key of the
identifying entity set, namely loan, and payments_number
distinguishes payment entities within the same loan.
Design Principles
• Faithfulness
 Entity sets and attributes should represent reality
 Cardinality should also be logical
• Avoiding Redundancy
 Everything should come once only e.g no studio name
in movies entity

Design Principles
• Simplicity
 Avoid adding more elements than required
• Choosing Right Relationships

 Don’t add unnecessary relationships to the design
 It may lead to redundancy as a relationship can be
deduced from more than one ways
 The database may require much more space

Design Principles
• Picking Right Kind of Elements
 Pick only right elements for entities.
 Be careful in deciding to choose an element as entity
or an attribute only
 Attribute is simpler to implement
 Everything cann’t be an attribute

Advance Database Systems - Lec 2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Advance Database Systems - Lec 2

Uploaded by

Copyright:

Available Formats

Advance Database Systems Dr. Mukaram MCS

Advance Database Systems Dr. Mukaram MCS

Advance Database Systems Dr. Mukaram MCS

Advance Database Systems Dr. Mukaram MCS

Advance Database Systems Dr. Mukaram MCS

Diagrams to represent designs.

Advance Database Systems Dr. Mukaram MCS

Students Takin Courses

Advance Database Systems Dr. Mukaram MCS

Advance Database Systems Dr. Mukaram MCS

Advance Database Systems Dr. Mukaram MCS

Advance Database Systems Dr. Mukaram MCS

Students Courses TAs

Advance Database Systems Dr. Mukaram MCS

name addr Services

Serves Pizza Hut Visi

Pizza Like Customers

name topping name addr

Advance Database Systems

Many-many Many-one One-one

Advance Database Systems Dr. Mukaram MCS

Advance Database Systems Dr. Mukaram MCS

Pizza Huts Sells Pizza

• Shorthand for 3-way relationship:

Pizza Hut Sells Pizza

Advance Database Systems Dr. Mukaram MCS

Advance Database Systems Dr. Mukaram MCS

Advance Database Systems Dr. Mukaram MCS

Advance Database Systems Dr. Mukaram MCS

Subclass = special case = fewer entities = more

Advance Database Systems Dr. Mukaram MCS

name Pizza Type manf

color BBQ Pizza

Advance Database Systems Dr. Mukaram MCS

isa P.Hut’s BBQ

Advance Database Systems Dr. Mukaram MCS

Advance Database Systems Dr. Mukaram MCS

Advance Database Systems Dr. Mukaram MCS

Advance Database Systems Dr. Mukaram MCS

Advance Database Systems Dr. Mukaram MCS

dept Courses room

• Possibly, the combination of hours + room also

Advance Database Systems Dr. Mukaram MCS

• Pizza name is also key for BBQ.

Advance Database Systems Dr. Mukaram MCS

Advance Database Systems Dr. Mukaram MCS

Advance Database Systems Dr. Mukaram MCS

Advance Database Systems Dr. Mukaram MCS

Advance Database Systems Dr. Mukaram MCS

Advance Database Systems Dr. Mukaram MCS

Advance Database Systems Dr. Mukaram MCS

Advance Database Systems Dr. Mukaram MCS

Advance Database Systems Dr. Mukaram MCS

Advance Database Systems Dr. Mukaram MCS

Advance Database Systems Dr. Mukaram MCS

Advance Database Systems Dr. Mukaram MCS

Advance Database Systems Dr. Mukaram MCS

Advance Database Systems Dr. Mukaram MCS

Advance Database Systems Dr. Mukaram MCS

 Payment_number is a sequential number starting

Advance Database Systems Dr. Mukaram MCS

Advance Database Systems Dr. Mukaram MCS