Introduction to databases - Recap

• Entity, Attributes, Relationships

• Types of Binary relationships
 one-to-one (1:1)
 one-to-many (1:*) same as (1:M)
 many-to-many (*:*) same as (M:M)
• Database models – Conceptual, Logical, Physical
• Student Task – study No SQL/ Non-relational
databases
Today’s Session

 Strong and Weak Entity

 Types of attributes
 DBMS Keys
 Entity Relationship diagram (ERD)
 UML notations
 Recap – Entity – (Entities describe things)

• An entity type is an abstract thing - no physical

referents eg: Actor

• An Occurrence is a concrete thing - has physical

referents eg: Emma Watson

• Regular (or strong) entities:

- things having their own existence
Eg: Customer, Employee
• Weak (or derived) entities:
- things that depend on strong entities for own existence
Eg: Loan, Dependent
Strong and Weak Entity
Employee has Dependent

has
Employee Dependent
1..1 0..*

Strong weak
Entity Entity

has
Customer Loan
1..1 0..*
 Attributes
• Attributes describe the Property of an entity or a
relationship type.

• An attribute type is an abstract property

eg first_name, last_name, address
• An attribute instance is a concrete property
eg Mike

• Attribute Domain
Set of allowable values for one or more attributes.
 Types of Attributes
Simple Attribute
Attribute composed of a single component with an
independent existence. which cannot be divided
further. Ex: phone_number, SSN Passport number

Composite Attribute
Attribute composed of multiple components, each with
an independent existence.
Ex: name – first_name, middle_name, last_name
address – street, city, postcode
 Types of Attributes
Single-valued Attribute
Attribute that holds a single value for each occurrence of an entity
type.
Ex: passport_number, driving_license_number

Multi-valued Attribute
Attribute that holds multiple values for each occurrence of an entity
type.
Ex: phone_number, email_address

Derived Attribute
Attribute that represents a value that is derivable from value of a
related attribute, or set of attributes, not necessarily in the same entity
type.
Ex: average_salary, age
Example of entities and attributes
Types of Keys in DBMS
What is a key in DBMS
std_id std_name course gpa email city

2019123 Jon snow SE 3.8 [email protected] The wall

2020345 Daenerys CS 3.5 [email protected] Dragonstone
2019678 Arya AI&DS 4.0 [email protected] Winterfell
2020987 Sansa CS 3.2 [email protected] Winterfell
2019347 Tyrion AI&DS 2.8 [email protected] King’s Landing
2020887 Lyanna CS 3.0 [email protected] Bear Island
2020546 Samwell SE 2.5 [email protected] Andal
2019478 Lyanna SE 3.7 [email protected] Winterfell

Then how to identify any

Lyanna - row of data in a table
Where does she come from? uniquely???
What is her gpa? It gives you either wrong
What is her email address? answer or multiple
answers
Keys in DBMS

What is a key?

It is an attribute or set of attributes

which help you to uniquely identify
a record/tuple/row in a
relation/table/entity.
Why Keys are important?

 To identify any row of data in a table

uniquely.

 To ensure data integrity.(insert, delete,

search, modify etc. using the key)

 To establish relationship between

tables.
Types of Keys in DBMS
Super key Candidate key

Primary key Foreign key

Composite & Compound key

Alternative key Natural Key

Surrogate key - Generated Key(Auto increment)

What is a key in DBMS
std_id std_name course gpa email city

2019123 Jon snow SE 3.8 [email protected] The wall

2020345 Daenerys CS 3.5 [email protected] Dragonstone
2019678 Arya AI&DS 4.0 [email protected] Winterfell
2020987 Sansa CS 3.2 [email protected] Winterfell
2019347 Tyrion AI&DS 2.8 [email protected] King’s Landing
2020887 Lyanna CS 3.0 [email protected] Bear Island
2020546 Samwell SE 2.5 [email protected] Andal
2019478 Lyanna SE 3.7 [email protected] Winterfell
 Types of Keys in DBMS
Super Key
A super key is a attribute or set of attributes that can be identify each
row uniquely.
Ex: std_id std_id, email std_id, std_name, email, gpa, city
email email, city email, course, gpa, city

Candidate Key
A minimal super key. (If any proper subset of a super key is a super key,
then that cannot be a candidate key)
Ex: std_id
email
 Types of Keys in DBMS

Primary Key
Almost every entity must have one!
A candidate key chosen to uniquely identify each row in a table.

Ex: std_id OR email

Alternative Key
All the candidate keys which are not selected as PK call as alternative keys.
 Types of Keys in DBMS
Foreign Key
Attribute in a table which is used to define it’s relationship with another table.
A key from another table maintain referential integrity for tables in
relationship
A referring attribute in an entity, pointing back to a primary key in another
(parent) table.

Student Course

NIC sName age IITno course courseId course course

{PK} Id {FK} {PK} Name Leader
1994.. Ann 19 2019123 1 1 SE Mr.Alex

2001.. John 20 2019456 2 2 CS Ms.Julia

2002.. Alex 22 2020789 1

 Types of Keys in DBMS
Composite Key
Sometimes one attribute is not enough to identify a record
Any candidate key with more than one attribute.
Ex: IITNo{PK}, NIC

E.g. a table representing library loans with attributes StudentID, BookID and
date.
StudentID on its own is not unique (as a student can borrow many bookss)…
…nor is BookID (as a book can be borrowed by many students at various times
But StudentID + BookID + Date will be unique – unless?
This is a composite primary key.

Compound key
If a composite key has at-least one attribute which is a FK then it is called a
compound key.
Ex: IITNo{PK}, courseId{FK}
 Types of Keys in DBMS
Natural Key
A key that has some external meaning
Ex: ISBN book number, vehicle registration number etc.

Surrogated Key

If a relationship has no attribute which can be used to identify a row uniquely

then we can create an attribute as a key.
EX: Generated Key
one that has no external meaning
Ex: an auto-generated receipt number.
 Relationship Degrees
• A binary relationship has two participating entities, (this is
the most common type of relationship).
• A ternary relationship has three participating entities
• A unary relationship has just one participating entities (it is
recursive),
• eg an employee can be a manager

Is supervised by

Employee
 Recap - Cardinality constraints
• 1:1
this relationship constraint is sometimes removed
by merging the two connected entities
• 1:m
a common constraint which often models
referential integrity
• m:m
this relationship constraint is often simplied into two
relationships; 1 : m and m:1
• (minN, maxN) : (minM, maxM)
the most specific constraint, min and max may be numeric
but are often just 0, 1 or M.
One to One – optional.

has
Student 1..1 0..1
Laptop

1. A student may not have a laptop

2. A student can only have one laptop
3. A laptop should belong to at least one student
4. A laptop can only belong to a one student
 One to One – Mandatory.

has
Student 1..1 1..1
Student_ID

1. A student must have a student_id

2. A student can only have one student_id
3. A student_id should only belong to a one student
4. A student_id can only belong to a one student
 One to Many
has registered
Student 1..* 1..1
Course

1. A student should register at least for a one course

2. A student can only be registered for a one course
3. A course should have at least one students
4. A course may have many students
 Many to Many

has registered
Student 1..* 1..*
Module

1. A student should register for at least one module

2. A student can register for many modules
3. A module should have at least one student
4. A module should can have many students
 Student Task
A university consists of a number of
departments. Each department offers several
courses. A number of modules make up each
course. Students enroll in a particular course
and take modules towards the completion of
that course. Each module is taught by a
lecturer from the appropriate department, and
each lecturer tutors a group of students.
 Entities in the system - nouns
A university consists of a number of
departments. Each department offers several
courses. A number of modules make up
each course. Students enroll in a particular
course and take modules towards the
completion of that course. Each module is
taught by a lecturer from the appropriate
department.
 Relationships in the system - Verbs
A university consists of a number of
departments. Each department offers several
courses. A number of modules make up each
course. Students enroll in a particular course
and take modules towards the completion of
that course. Each module is taught by a
lecturer from the appropriate department,
and each lecturer tutors a group of students.
Example - Relationships
1. A university consists of a number of
departments.
2. Each department offers several courses.
3. A number of modules make up each course.
4. Students enroll in a particular course and take
modules towards the completion of that course.
5. Each module is taught by a lecturer from the
appropriate department, and each lecturer tutors a
group of students.
 Database models - Coursework

conceptual model - model of the real world expressed in

term of entities, relationships and attributes.

Normalization
logical model - model of the real world expressed in term
of entities, relationships and attributes, domains, primary
keys and foreign keys.

physical model - model of the real world expressed in term

of files and access structures – Using Xampp and
phpMyAdmin
Conceptual Entity Relationship
Diagram
Answer Department
offers
deptId {pk}
deptName
1..1 location

Each department offers several courses.

1..*
Lecturer
Course
Module
NIC {pk}
courseId {pk}
moduleId {pk} lecName
courseName
modName address
courseLeader
modLeader salary
hireDate

Student

stdId {pk}
stdName
payment
Answer Department
offers
deptId {pk}
deptName
1..1 location

1..*
Lecturer
Course Module
make up NIC {pk}
courseId {pk} moduleId {pk} lecName
courseName modName
courseLeader 1..* 1..* address
modLeader salary
hireDate
A number of modules make up each course.

Student

stdId {pk}
stdName
payment
Answer Department
offers
deptId {pk}
deptName
1..1 location

1..*
Lecturer
Course Module
make up NIC {pk}
courseId {pk} moduleId {pk} lecName
courseName 1.. modName
courseLeader 1..* address
* modLeader salary
hireDate
1..1 1..*
Students enroll in a particular course
take and take modules towards the
completion of that course.
0..*
Student
1..*
stdId {pk}
enroll in stdName
payment
Answer Department
offers employ
deptId {pk}
deptName
1..1 location
1..1

Each module is taught by a lecturer from the

appropriate department, and each lecturer
1..*
1..* tutors a group of students. Lecturer
Course
Module
make up is taught by NIC {pk}
courseId {pk}
moduleId {pk} lecName
courseName 0..*
courseLeader 1..* 1..* modName 1..* address
modLeader salary
hireDate
1..1 1..*
1..*

take

0..*
Student
0..* 0..*
stdId {pk}
enroll in stdName tutors
payment
 char(max_size) and varchar(max_size)
char(10) – Fix length
Ex: NIC 1 2 3 4 5 6 7 8 9 V

Name O l i v i a

Wasting space

varchar(10) – Variable length

Ex: Name O l i v i a

C l e m e n t i n e