SEN 304: Database Management I

Prepared by: Dr. Bilkisu L. Muhammad-Bello

Database System Concepts, 7th Ed.

©Silberschatz, Korth and Sudarshan
See www.db-book.com
www.db-book.com for conditions on re-use 1
 More on Relationships, Understanding
CRUD Requirements and Unique Identifiers

2
Database System Concepts - 7th Edition 1.2 ©Silberschatz, Korth and Sudarshan
 Relationship Transferability

3
Database System Concepts - 7th Edition 1.3 ©Silberschatz, Korth and Sudarshan
 Outline

▪ Review of ERD Concepts with Crow foot’s notation

▪ Relationship transferability
▪ Transferable and nontransferable relationships
▪ Illustration of nontransferable relationships on ERDs
▪ Resolving Many-to-Many Relationships
▪ Understanding CRUD Requirements
▪ Artificial, Composite, and Secondary UIDs

Database System Concepts - 7th Edition 1.4 ©Silberschatz, Korth and Sudarshan
 Introduction

▪ Once a class has been allocated to a lecturer, can that class later be
transferred to another lecturer, possibly in mid-semester?
▪ Usually yes, because if not, what would we do if the original lecturer
becomes sick or resigns suddenly?
▪ Some gyms/health clubs allow memberships to be transferred from one
person to another, but other health clubs don’t.
▪ This business rule is normally determined by what is most efficient and
most profitable for the club.

Database System Concepts - 7th Edition 1.5 ©Silberschatz, Korth and Sudarshan
 Relationship Review

▪ Let’s review a simple relationship between EMPLOYEE and

DEPARTMENT.
▪ Cardinality:
• How many EMPLOYEEs can a DEPARTMENT be responsible for?
• How many DEPARTMENTs can an EMPLOYEE be assigned to?
▪ ANSWER:
▪ Each DEPARTMENT is responsible for one or more employees, so we
draw a crows foot at the EMPLOYEE side of the relationship.
▪ Each EMPLOYEE can be assigned to only one DEPARTMENT , so we
draw a single toe at the DEPARTMENT side of the relationship

Database System Concepts - 7th Edition 1.6 ©Silberschatz, Korth and Sudarshan
 Relationship Review

▪ Optionality:
• Must every EMPLOYEE be assigned to a DEPARTMENT?
• Must every DEPARTMENT be responsible for an employee?
• Can you have an EMPLOYEE not assigned to a DEPARTMENT?
ANSWER: NO, so relationship is drawn as mandatory (solid line).
• Can you have a DEPARTMENT not responsible for any EMPLOYEEs?
ANSWER: It depends on the business rules of the company in
question, but in this case YES “We have some departments that
currently have no employees assigned to them”, so relationship is
drawn as optional (dashed line).

Database System Concepts - 7th Edition 1.7 ©Silberschatz, Korth and Sudarshan
 Relationship Review

▪ Transferability:
• Can an EMPLOYEE be transferred from one DEPARTMENT to
another DEPARTMENT?
▪ Answer: yes, an EMPLOYEE and change from one DEPARTMENT to
another. This makes the relationship transferable.
▪ Does the ERD indicate this possibility (transferability)?

Database System Concepts - 7th Edition 1.8 ©Silberschatz, Korth and Sudarshan
 Relationship Transferability

▪ Transferable: A STUDENT being allowed to move from one STUDY

GROUP to another.
▪ There is a relationship between STUDENT and STUDY GROUP that is
transferable.

Database System Concepts - 7th Edition 1.9 ©Silberschatz, Korth and Sudarshan
 Relationship Transferability

▪ Nontransferable: A STUDENT can be issued a RECEIPT for paying

tuition fees, taking a certification exam, or purchasing items at the
bookstore.
▪ Once a RECEIPT has been issued, it cannot be transferred to another
STUDENT.
▪ Nontransferable: If the transferability of a relationship is false, the
relationship is said to be nontransferable. Nontransferable relationships
are important to note because they usually reflect a business rule and
will have implications when the ERD is implemented as a database.

Database System Concepts - 7th Edition 1.10 ©Silberschatz, Korth and Sudarshan
 Relationship Transferability

▪ If it was issued in error, it would have to be cancelled, and another

RECEIPT would have to be written up.
▪ The relationship between STUDENT and RECEIPT is nontransferable.
▪ The diamond is typically drawn on the “many” (crows-foot) side of the
relationship.
▪

Database System Concepts - 7th Edition 1.11 ©Silberschatz, Korth and Sudarshan
 More Nontransferable Relationships

▪ Ownership of a POEM belongs with its AUTHOR.

▪ Authorship is a relationship that cannot be moved to another person.

Database System Concepts - 7th Edition 1.12 ©Silberschatz, Korth and Sudarshan
 One-to-Many (1:M) Relationships

▪ The various types of 1:M relationships are most common in an ER Model.

▪ You have seen several examples already.
▪ “Many” can mean one-or-more or zero-or-more, depending on the
optionality.
▪ Mandatory at both ends: This type of relationship typically models entities
that cannot exist without each other. This usually represents an ideal
situation—we cannot have ORDER ITEMs without ORDERs.
▪ Mandatory on the one side, optional on the many side: This is rarely
used. You will see it only when the relationship expresses that an entity
instance exists only when it is a nonempty set, and where the elements of
the set can exist independently.
• A MUSICIAN may be part of one BAND. A BAND is of no interest if it is
empty. How can you have a BAND without MUSICIANs?

Database System Concepts - 7th Edition 1.13 ©Silberschatz, Korth and Sudarshan
 Many-to-Many (M:M) Relationships

▪ The various types of M:M relationships are common, particularly in a first

version of an ER model.
▪ In later stages of the modeling process, all M:M relationships will be
resolved.
▪ In most cases, M:M relationships indicate that an entity is missing from the
model.

Database System Concepts - 7th Edition 1.14 ©Silberschatz, Korth and Sudarshan
 One-to-One Relationships For Roles

▪ Usually you will find just a few of the various types of 1:1 relationships in
every ER model.
▪ Mandatory at one end of the 1:1 relationship commonly occurs when roles
are modeled.
▪ Alternatively, TEACHER and STUDENT could have been modeled as
subtypes of PERSON, unless a PERSON can be both a TEACHER and a
STUDENT at the same time.

Database System Concepts - 7th Edition 1.15 ©Silberschatz, Korth and Sudarshan
 One-to-One Relationships For Processes

▪ 1:1 relationships (of all three variations) also occur when some of the
entities represent various stages in a process.
▪ Mandatory 1:1 A 1:1 relationship, mandatory at both ends, tightly
connects two entities: when you create an instance of one entity, there
must be exactly one dedicated instance for the other simultaneously.
▪ This leads to the question why you want to make a distinction between the
two entities anyway. The only acceptable answer is: only if there is a
business need.

Database System Concepts - 7th Edition 1.16 ©Silberschatz, Korth and Sudarshan
 Resolving Many-to-Many Relationships

Database System Concepts - 7th Edition 1.17 ©Silberschatz, Korth and Sudarshan
 Purpose

▪ This lesson will help you complete your model -you may need to create
new entities or new relationships based on the business needs.
▪ It will also help you define the scope of your data model -you only model
what is of importance to the business.

Database System Concepts - 7th Edition 1.18 ©Silberschatz, Korth and Sudarshan
 Relationship Hiding an Attribute

▪ In a school, a STUDENT may study one or more SUBJECTs.

▪ Each SUBJECT may be studied by one or more STUDENTs

Database System Concepts - 7th Edition 1.19 ©Silberschatz, Korth and Sudarshan
 Relationship Hiding an Attribute

▪ When a student enrolls for a subject, we want to be able to record the

grade they attain for that subject.
• Which entity would the attribute “Grade” belong to?
• If we put “Grade” in the STUDENT entity, how would we know which
SUBJECT it is for?
• If we put “Grade” in the SUBJECT entity, how would we know which
STUDENT got that grade?
▪ The grade is an attribute of the many-to-many relationship between
STUDENT and CLASS, not of either entity alone.

Database System Concepts - 7th Edition 1.20 ©Silberschatz, Korth and Sudarshan
 Resolution of a M:M Relationship

▪ A third entity is needed to resolve the M:M relationship. This is called an

"intersection" entity.
▪ Since every attribute must belong to an entity, we need a third entity.
▪ Intersection Entity: An intersection entity –ENROLLMENT –has been
added, including the “Grade” attribute.
• The original M:M relationship has become two 1:M relationships.
• What would be the UID of the intersection entity?
▪ Intersection entity: The product of the resolution of a many to many
relationship

Database System Concepts - 7th Edition 1.21 ©Silberschatz, Korth and Sudarshan
 Barred Relationships

▪ The unique identifier (UID) of the intersection entity often comes from the
originating relationships and is represented by the bars.
▪ In this case, the relationships from the originating entities to the
intersection entity are called "barred" relationships.
▪ Barred relationship: A relationship that participates in an entity's unique
identifier

Database System Concepts - 7th Edition 1.22 ©Silberschatz, Korth and Sudarshan
 Documenting Business Rules

Database System Concepts - 7th Edition 1.23 ©Silberschatz, Korth and Sudarshan
 Purpose

▪ One of the primary goals of data modeling is to ensure that all pieces of
information that are required to run a business are recognized.
▪ Identifying and documenting business rules are keys to checking your data
model for accuracy and completeness.
▪ It is important to recognize that not all business rules can be represented in
the ERD.
▪ Some business rules must be implemented by programming.

Database System Concepts - 7th Edition 1.24 ©Silberschatz, Korth and Sudarshan
 Structural and Procedural Business Rules

▪ Structural business rules indicate the types of information to be stored

and how the information elements interrelate.
▪ Procedural rules deal with the prerequisites, steps, processes, or
workflow requirements of a business.
• Many procedural business rules are related to time: event A must
happen before event B.
▪ Structural business rules can nearly always be diagrammed in the ERD.
▪ Some procedural business rules cannot be diagrammed, but must still be
documented so that they can be programmed later.

Database System Concepts - 7th Edition 1.25 ©Silberschatz, Korth and Sudarshan
 Structural Rule Example

▪ Structural business rules indicate the types of information to be stored

(attributes) and how the information elements interrelate (relationships).
▪ All orders at a restaurant must be handled by a staff member (specifically,
an order taker).
• There is no self-service ordering system.
▪ All teachers at our school must possess a valid teaching certificate.

Database System Concepts - 7th Edition 1.26 ©Silberschatz, Korth and Sudarshan
 Rule Discussion

▪ What kinds of rules does my employer have that affects me ?

• Each course I teach must be assigned by a line manager (HOD)
• The credit hours for every course I teach must be documented.

▪ Our University has many business rules that answer the following
questions:
▪ Is it reasonable/effective for a class not to have a lecturer assigned?
▪ Is it reasonable/effective for two students to have the same student id
number or no student id number at all?
▪ Is it reasonable to schedule a lecturer to teach a course if no students are
enrolled?
▪ Is it reasonable to allow someone to attend lectures/sit for final exams if
they are not enrolled in any classes?

Database System Concepts - 7th Edition 1.27 ©Silberschatz, Korth and Sudarshan
 Procedural Rule Example

▪ Procedural business rules are workflow or process related.

▪ Here are some examples of the processes that must be followed in a
Human Resource Department scenario:
• “Some of our employees are required to attend mandatory training
events. These events take place at one of the company’s existing
locations, and the employees travel to the location to take part in the
training.”
• “Approval for all travel requests to a training event must be signed by
the employee’s manager before the employee can register for the
event.”
▪ We can model the relationships between EMPLOYEEs , TRAINING and
LOCATIONs in an ERD as this is an example of a Structural Business
Rule.
▪ We cannot model the second Business rule in an ERD, as it is an example
of a workflow related rule.

Database System Concepts - 7th Edition 1.28 ©Silberschatz, Korth and Sudarshan
 Business Rule diagrammed in an ERD

▪ “Some of our employees are required to attend mandatory training events.

These events take place at one of the company’s existing locations, and
the employees travel to the location to take part in the training.”

Database System Concepts - 7th Edition 1.29 ©Silberschatz, Korth and Sudarshan
 Procedural Rule Example

▪ “Students must have studied algebra and geometry in order to sign

up for trigonometry.”
▪ Could you represent this in the ERD?
▪ How would you implement this with programming?
▪ If the student had taken the subjects, can you think of an additional
business rule that a school may want in this scenario?

▪ These Procedural Business Rules must be recorded in a separate

document that will supplement the ERD. Different Organizations will
have different formats for documenting Business rules, but are often word
processed documents or presentation software slides.

Database System Concepts - 7th Edition 1.30 ©Silberschatz, Korth and Sudarshan
 Documenting Rules

▪ In the process of developing a conceptual data model, not all business

rules can be modeled.
▪ Some rules such as the two listed below must be implemented by
programming the processes that interact with data:
• Any employee whose overtime exceeds 10 hours per week must be
paid 1.5 times the hourly rate.
• Customers whose account balances are 90 days overdue will not be
permitted to charge additional orders.
▪ These Business Rules must be documented, and supplement the ERD

Database System Concepts - 7th Edition 1.31 ©Silberschatz, Korth and Sudarshan
 Understanding CRUD Requirements

Database System Concepts - 7th Edition 1.32 ©Silberschatz, Korth and Sudarshan
 CRUD Analysis

▪ CRUD analysis ties data modeling to business functions.

▪ Although functional modeling is not covered in this course, the business
functions and processes that the client describes will operate on the data.
▪ CRUD analysis checks that all the appropriate operations are possible.
▪ This is a good tool to check for completeness and proper scope of the data
model.

Database System Concepts - 7th Edition 1.33 ©Silberschatz, Korth and Sudarshan
 Purpose

▪ From the business scenarios that you develop and the list of business
rules that you identify during client interviews, you will build the ERD.
▪ The ERD is the conversation tool between the consultant and the client,
and it is also the blueprint for the DBA who will eventually build the
database.
▪ You need a way to check that you haven’t missed any entities or
relationships in your data model.
▪ You also want to ensure that you haven’t modeled anything that the
business does not require.
▪ CRUD analysis will help you do this.
▪ A good way to validate an ERD is to do a CRUD analysis on it.

Database System Concepts - 7th Edition 1.34 ©Silberschatz, Korth and Sudarshan
 CRUD Analysis

▪ CRUD is an acronym for create, retrieve, update, delete.

▪ These are the four basic functions (or operations) that a database allows.
▪ Part of checking a data model for completeness and accuracy is making
sure that all the CRUD functions specified by the business scenario and
the business rules are represented in the ERD.

Database System Concepts - 7th Edition 1.35 ©Silberschatz, Korth and Sudarshan
 CRUD Analysis—Create Function

▪ During the client interview, and while writing the business scenarios and
rules, look for keywords like:
• INPUT, ENTER, LOAD, IMPORT, RECORD, & CREATE
▪ These all indicate that a record is created in the database at this time.
▪ Review the requirements for these keywords.
▪ Does your data model account for all of these functions?

▪ “Whenever we get a new customer, we take down basic information

(name, address, email) and assign an ID.” (CREATE)

Database System Concepts - 7th Edition 1.36 ©Silberschatz, Korth and Sudarshan
 CRUD Analysis—Retrieve Function

▪ During the client interview, and while writing the business scenarios and
rules, look for keywords like:
• VIEW, REPORT, BRING UP, PRINT, FIND, READ, & LOOK UP
▪ These all point to retrieving information from the database.
▪ Review the requirements for these keywords.
▪ Does your data model account for all these functions?

▪ “We’d like to print out a list of the customers whose account is in

arrears.” (RETRIEVE)

Database System Concepts - 7th Edition 1.37 ©Silberschatz, Korth and Sudarshan
 CRUD Analysis—Update Function

▪ During the client interview, and while writing the business scenarios and
rules, look for keywords like:
• CHANGE, MODIFY, ALTER, & UPDATE
▪ These all point to updating information that is already in the database.
▪ Review the requirements for these keywords.
▪ Does your data model account for all these functions?

▪ “When a customer pays into their account, we alter their record by

modifying the outstanding balance” (UPDATE)

Database System Concepts - 7th Edition 1.38 ©Silberschatz, Korth and Sudarshan
 CRUD Analysis—Delete Function

▪ During the client interview, and while writing the business scenarios and
rules, look for keywords like:
• DISCARD, REMOVE, TRASH, PURGE, & DELETE
▪ These all point to deleting information that is already in the database.
▪ Review the requirements for these keywords.
▪ Does your data model account for all these functions?

▪ “A number of our customers were small businesses that were hit hard
by the recession. They went out of business. We deleted them from
our current records.” (DELETE)

Database System Concepts - 7th Edition 1.39 ©Silberschatz, Korth and Sudarshan
 CRUD Validation

▪ Performing a CRUD analysis on your data model helps you check for
scope and completeness.
▪ If you have a business rule that has no entity to CRUD against, then your
data model may be incomplete.
▪ Similarly, if you have entities in your ERD that are not touched by any
CRUD function (no business rule creates, retrieves, updates, or deletes
from it), then you may not need that entity in your model.

Database System Concepts - 7th Edition 1.40 ©Silberschatz, Korth and Sudarshan
 Artificial, Composite, and Secondary UIDs

Database System Concepts - 7th Edition 1.41 ©Silberschatz, Korth and Sudarshan
 Purpose

▪ The unique identifier (UID) is very important in relational databases.

▪ It is the value or combination of values that enables the user to find that
one unique item among all the rest.
▪ Identifying just the right attribute, or combination of attributes and
relationships, is a skill that any database designer must master.
▪ The unique identifier enables you to find your record in a file, a particular,
your package in a warehouse, or a specific piece of data in a database.

Database System Concepts - 7th Edition 1.42 ©Silberschatz, Korth and Sudarshan
 Simple UIDs vs. Composite UIDs

▪ Simple UIDs vs. Composite UIDs

▪ A UID that is a single attribute is a simple UID.
▪ However, sometimes a single attribute is not enough to uniquely identify an
instance of an entity.
▪ If the UID is a combination of attributes, it is called a composite UID.

▪ The date of performance or seat number alone does not identify a concert
ticket. On any given date, there are many seats available. The same seat
number is sold for many different dates.

Database System Concepts - 7th Edition 1.43 ©Silberschatz, Korth and Sudarshan
 Artificial UIDs

▪ Artificial UIDs are those that don’t occur in the natural world but are
created for purposes of identification in a system.
▪ People are not born with “numbers,” but a lot of systems assign unique
numbers to identify people: student numbers, customer IDs, etc.

▪ More examples: credit card numbers, social security numbers, National

Identity Number, passport numbers.

Database System Concepts - 7th Edition 1.44 ©Silberschatz, Korth and Sudarshan
 Artificial UIDs - Examples

▪ A shoe has a color, a size, a style, but no truly descriptive “number.”

▪ However, a shoe store will assign unique numbers to each pair of shoes so
they can be uniquely identified.

Database System Concepts - 7th Edition 1.45 ©Silberschatz, Korth and Sudarshan
 Artificial UID Example

▪ How can we uniquely identify a STUDENT?

▪ Could we use a combination of first name and last name?
• Only if we are sure that the combination is unique.
▪ Often, it is simpler and more straightforward to create an artificial attribute
and make it the unique identifier.
▪ A UID can be both artificial and composite.
▪ A combination of first name, last name, and address would possibly be
unique. However, it is not as convenient as a single ID.
▪ Think of the business requirements: if you went to the library, or
checked out equipment at the gym, or asked for a copy of your grades – is
it easier to just provide a student ID or to provide name and address each
time?

Database System Concepts - 7th Edition 1.46 ©Silberschatz, Korth and Sudarshan
 UID from Barred Relationship Intersection Entity

▪ As we’ve seen before, the resolution of a M:M relationship often results in

barred relationships from the intersection entity to the original ones.
▪ In this example, the UID of ENROLLMENT comes from STUDENT and
SUBJECT.
▪ The bars on the relationships tell you this.

Database System Concepts - 7th Edition 1.47 ©Silberschatz, Korth and Sudarshan
 Artificial UID Intersection Entity

▪ It is possible for an intersection entity to use an artificial attribute as the

UID, instead of the barred relationships to the originating entities.

▪ Each MANUFACTURER may produce one or more PRODUCTs (shoes,

shirts, jeans, etc.).
▪ Each PRODUCT may be produced by one or more MANUFACTURERs
(Nike shoes, Adidas shoes, Levi’s jeans, etc.).

Database System Concepts - 7th Edition 1.48 ©Silberschatz, Korth and Sudarshan
 Artificial UID Intersection Entity

▪ CATALOG ITEM resolves this many-to-many relationship.

▪ An item in a catalog can be uniquely identified by the manufacturer number
and the product code.
▪ The relationships are not barred, because an artificial UID –catalog
number –has been created instead.

Database System Concepts - 7th Edition 1.49 ©Silberschatz, Korth and Sudarshan
 Candidate UIDs

▪ Sometimes two or more possible UIDs exist.

▪ For example, when you order a product from a commercial website, you
will usually be assigned a unique customer code and asked to enter your
e-mail address.
▪ Each of these uniquely identifies you, and each could be chosen as the
UID. These are both candidate UIDs.
▪ Only one of the candidate UIDs is chosen as the actual UID. This is called
the primary UID.
▪ The other candidates are called secondary UIDs.

Database System Concepts - 7th Edition 1.50 ©Silberschatz, Korth and Sudarshan
 Examples

▪ Candidate UID: One of several UIDs that could be used to identify

something
▪ Primary UID: A candidate UID that is the primary identifier of something
▪ Secondary UID: A candidate UID that also identifies something, but is not
the primary UID
▪ Secondary UIDs can be useful as an alternative means of searching for
data.
▪ Examples:
▪ You forgot your NIN, but you know your registered telephone number with
NIMC.
▪ You have a frequent-shopper card at the supermarket but did not bring it
with you. Some systems can find your information if you provide your
telephone number.

Database System Concepts - 7th Edition 1.51 ©Silberschatz, Korth and Sudarshan
 Candidate UIDs

▪ Student ID has been chosen as the primary UID in both of these

STUDENT entities.
▪ The first entity has one secondary UID, while the second has two
secondary UIDs (one of which is composite).

▪ The composite secondary UID (first name, last name) in

the second entity may not be unique and therefore would
not be chosen to be the primary UID.

Database System Concepts - 7th Edition 1.52 ©Silberschatz, Korth and Sudarshan
 Key terms for your Review

▪ Nontransferable relationship
▪ Transferable relationship
▪ Redundant relationship
▪ Barred relationship
▪ Intersection entity
▪ CRUD Analysis
▪ Artificial UID
▪ Candidate UID
▪ Composite UID
▪ Primary UID
▪ Secondary UID
▪ Simple UID
▪ UID

Database System Concepts - 7th Edition 1.53 ©Silberschatz, Korth and Sudarshan