Scribd
Upload
14 views16 pages

Lecture 9 Sem I 2025

The lecture discusses the Entity Relationship Model, focusing on what constitutes an appropriate entity and the distinction between strong and weak entity types. It also covers various classifications of attributes, including required vs optional, simple vs composite, and single-valued vs multivalued attributes. Additionally, criteria for selecting identifiers (primary keys) are outlined to ensure they remain stable and unique throughout the entity's lifecycle.

Uploaded by

khanbisma584
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
14 views16 pages

Lecture 9 Sem I 2025

The lecture discusses the Entity Relationship Model, focusing on what constitutes an appropriate entity and the distinction between strong and weak entity types. It also covers various classifications of attributes, including required vs optional, simple vs composite, and single-valued vs multivalued attributes. Additionally, criteria for selecting identifiers (primary keys) are outlined to ensure they remain stable and unique throughout the entity's lifecycle.

Uploaded by

khanbisma584
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 16

Database systems

Lecture 9
Previous Lecture Content
 The Entity Relationship Model
Lecture Content
 The Entity Relationship Model (cont..)
What Should an Entity Be?
• Entity: A person, place, object, event, concept in
the user environment about which the organization
wishes to maintain data
• SHOULD BE:
• An object that will have many instances each with
distinguishing characteristic
• An object that will be composed of multiple attributes
• An object that we are trying to model

4
What Should an Entity Not
Be?
• SHOULD NOT BE:
• A user of the database system
• Treasurer manages account
• An output of the database system (e.g. a report)
• TREASURER receives EXPENSE REPORT
• STUDENT receives CGCARD
• PAYSLIP sent to FACULTY
• The names receives, sent to refer to activities that
transfer or translate data but does not indicate any
association between data.

5
Figure 3-4 Inappropriate entities

System user System output

Appropriate entities

6
Strong Vs Weak Entity
Types
• Strong Entity Type: An entity that exists
independently of other entity types.
• It has identifier, attribute or combination of
attributes that uniquely distinguish each
occurrence of that entity
• Ex: COURSE, STUDENT, FACULTY
• Weak Entity Type: An entity type whose
existence depends on some other entity type
• It doesn’t have its own identifier
• Ex: COURSE and LECTURE SECTION
• EMPLOYEE and DEPENDENT
• Identifying owner: The entity type on which
the weak entity type depends
• Ex: COURSE and LECTURE SECTION
• EMPLOYEE and DEPENDENT

7
Attributes

• Attribute - property or characteristic of an entity type that is of interest to


the organization
• Has a noun name
• Ex: STUDENT (Idno, Name, Hostel, Room_No, CGPA)
• Classifications of attributes:
• Required versus Optional Attribute
• Required: An attribute of an entity that must have a value for each entity instance
• Optional : An attribute of an entity that may not have a value for each entity
instance
• Ex: Idno Vs Room No

8
Attributes

• Simple versus Composite Attribute


• Simple: An attribute that cant be broken down into smaller components
• Composite: An attribute that can be broken down into component parts
• Ex: CGPA Vs Address

9
Attributes
• Single-Valued versus Multivalued Attribute
• Multivalued: An attribute that can take more than
one value for a given entity instance
• Ex: STUDENT having multiple skills

10
Attributes
• 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

11
Attributes[2]
• Classifications of attributes:
• Identifier Attributes (primary key)
• An attribute ( or combination of attributes) that uniquely
identifies individual instances of an entity type
• Ex: Employee: Employee_ID
• Identifier attribute is underlined
• Composite identifier: An identifier that consists of a
composite attribute
• Ex: Flight_ID (Flight_Number, Date)

12
Criteria for selecting Identifiers (primary
keys)

• Should not change its value over the life of each instance of the entity type
• Ex: Idno
• Should not take null values
• NULL -> no value
• Avoid intelligent identifiers
• e.g. containing locations or classifications that might change
• Intelligent identifiers: Idno, course code AAOC C311
• Consider substituting single attribute surrogate identifiers for long,
composite keys
• Ex: comp code for Course_Code, Record_No for Idno

13
Figure 3-8 -- Entity with a multivalued attribute (Skill) and
derived attribute (Years_Employed)

Multivalued:
Derived an employee can have
from date employed and current date
more than one skill

14
Figure 3-19 – an attribute that is both multivalued and composite

This is an
example of
time-
stamping

15
References:

• Modern Database Management by Fred McFadden, Jeffrey Hoofer,


Mary Prescott, Prentice Hall; 11th Edition (July 26, 2012). ISBN-10:
0132662256.

16

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy