The document discusses entity relationship diagrams (ERDs) and cardinality. It explains that ERDs show relationships between tables and cardinality indicates how records in different tables relate to each other. The key cardinality relationships are one-to-one, one-to-many, many-to-one, and many-to-many. Many-to-many relationships require a linking table to properly represent the data. Examples are provided to illustrate each type of relationship.

1. ERD Cardinality

2. ERD Cardinality
● When we show relationships between
tables we need to show the cardinality.
● Depending on the data we are storing
there are several options to choose
from.

3. ERD Cardinality
● The cardinality relationship is shown with
lines between two entities to indicate a
relationship.
● This line denotes that there is a
relationship between the entities.
Entity A Entity B

4. ERD Cardinality
● The ENDS of these lines denote the cardinality
to that entity.
Entity A Entity B
● This is a ‘One to One’ relationship.
● This means that Entity A will relate to only one
of Entity B.
● And Entity B will relate to only one of Entity A

5. Erd Cardinality
● Here is an example..
Bus Driver
● One Driver drives just one Bus.
● One Bus has just one Driver.
● The records might be held like this:
Bus
PK BusID
Colour
NoOfSeats
FK DriverID
Driver
PK DriverID
Name
Address
Age

6. Erd Cardinality
To ensure that each record is unique in each table, we
can set one field to be a Primary Key field.
● A Primary Key is a field that that will contain no
duplicates and no blank values. It assures the
value in the specific column is unique.
● Foreign Keys link to data in another table. It is
generally used to build a relationship between
the two tables.

7. Erd Cardinality
BusID Colour NoOfSeats DriverID
001 Yellow 30 1001
002 Blue 40 1002
003 Green 30 1003
Table Name: Bus
DriverID Name Address Age
1001 Juan Dela Cruz Pasig 45
1002 Cardo Dalisay Pasay 40
1003 Pepito Manaloto Ortigas 38
Table Name: Driver

8. Erd Cardinality
What is the reason of having Multiple table in
databases, why not a huge single table?
• In relational databases this would take up too
much resources to store not only data but also
relations between them. It would also hamper
data retrieval efficiency, especially in a multi-user
environment.

9. ERD Cardinality
● This is a ‘One to Many’ relationship.
● This means that Entity A will relate to many of
Entity B.
● And Entity B will relate to only one of Entity A.
EntityA Entity B

10. Erd Cardinality
● Here is an example.
Customer Order
● One Customer may have many orders.
● One Order is for just one Customer.
● The records might be held like this:
PK CustNo
Name
Address
Order
PK OrderNo
OrderName
FK CustNo
Customer

11. Erd Cardinality
CustNo Name Address
001 Juan Dela Cruz Pasig
002 Cardo Dalisay Pasay
003 Pepito Manaloto Ortigas
Table Name: Customer
OrderID OrderName CustNo
B1 Regular French Fries 001
B2 Cheese Burger 001
B3 Bucket Fried Chicken 002
B4 Burger Steak 001
Table Name: Order

12. ERD Cardinality
Entity A Entity B
● This is a ‘Many to One’ relationship.
● This means that Entity A will relate to only one
of Entity B.
● And Entity B will relate to many of Entity A.
● (We still tend to refer to as a one to many, just the
other way round from B to A)

13. Erd Cardinality
● Here is an example.
Product Supplier
● Many Products will have just one Supplier.
● One Supplier will supply many Products.
● The records might be held like this:
Supplier
PK SuppID
Name
Address
Product
PK ProdID
Pname
Price
FK SuppID

14. Erd Cardinality
ProdID PName Price SuppID
001 Mouse 250 1003
002 Keyboard 450 1003
003 Speaker 1500 1004
Table Name: Product
SuppID Name Address
1001 EMCOR Rizal Ave
1002 DU EK SAM Rizal Ave
1003 ELECTRONICO Lacao Street
1004 TESLINQUE Mendoza
Table Name: Supplier

15. ERD Cardinality
● This is a ‘Many to Many’ relationship.
● This means that Entity A will relate to many of
Entity B.
● And Entity B will relate to many of Entity A.
EntityA Entity B

16. ERD Cardinality
● Many to Many - This can cause problems with
data, as we can’t pinpoint the link.
Entity A Entity B
● Imagine this, a Lender can borrow many
Books. But a Book can be borrowed by more
than one Lender.
Lender Book

17. Book
PK BookID
Title
Author
FK LenderID
ERD Cardinality
● How do we know who has each individual book?
Lender Book
● Also when we look at the data, how will we store this?
Lender
PK LenderID
Name
Address
FK BookID
FK BookID
FK BookID

18. ERD Cardinality
● To manage the many to many relationship, the
data would need to keep growing.
● This still causes problems
● Who has the book now?
● We can resolve this
● By adding a link table.
Book
PK BookID
Title
Author
FK LenderID
FK LenderID
FK LenderID
FK LenderID
FK LenderID
FK LenderID
FK LenderID
FK LenderID

19. ERD Cardinality
● To resolve a many to many relationship.
Entity A Entity B
● We resolve it by adding a link table.
Entity A Entity C Entity B
● This means we now have two manageable
one to many relationships instead.

20. ERD Cardinality
● The resolved many to many relationship.
Lender Records Book
● One lender can have many Records
● Many Records is for just one Lender
● One Book can have several Records
● Many Records is for just one Book

21. ERD Cardinality
● The data for this system might look something
like this:
Book
● Here is the resolved example.
Book
PK BookID
Title
Author
PK RecordID
FK LenderID
FK BookID
PK LenderID
Name
Address
Records
Lender
Lender Records

22. ERD Cardinality
● The Records record could be deleted when the
book is returned.
Lender Records Book
● Or fields added to identify the current loan.
Book
PK BookID
Title
Author
PK RecordID
FK LenderID
FK BookID
Lentdate
ReturedYN
ReturedDate
PK LenderID
Name
Address
Lender Records

23. LenderID Name Address
001 Juan Dela Cruz Alfonso XII
002 Cardo Dalisay Tagusao
003 Pepito Manaloto Tabon
Table Name: Lender
BookID Title Author
1100 Noli Me Tángere Dr. Jose Rizal
1101 The Daughter's Tale Armando Lucas Correa
1102 Romeo and Juliet William Shakespeare
1103 The Sun’s Heartbeat Jonah Mae Pacala
Table Name: Book
Table Name: Records
RecordID LenderID BookID LentDate ReturnedYN ReurnedDate
1 001 1100 Dec 28, 2022 Yes Jan 1, 2023
2 002 1101 Jan 8, 2023 Yes Jan 14, 2023
3 003 1102 Jan 10, 2023 Yes Jan 12, 2023
4 001 1103 Jan 10, 2023 Yes Jan 14, 2023
5 001 1102 Jan 13, 2023 Yes Jan 18, 2023
6 003 1100 Jan 10, 2023 No Null
7 002 1103 Feb 1, 2023 No Null
ERD Cardinality

24. ERD Cardinality
● A null value in a relational database is used
when the value in a column is unknown or
missing. A null is neither an empty string (for
character or datetime data types) nor a zero
value (for numeric data types).

25. Erd Cardinality
Students_ID Firstname Lastname Year_Level Course_ID
1002019 Danica Cruz 1st Year 1001
1102019 William Ramos 2nd Year 1002
1202019 Anna Santos 3rd Year 1002
1302019 Justine Grey 4th Year 1001
1402019 George Ramos 1st Year 1002
Table Name: Students
Course_ID Course_Title
1001 Information Technology
1002 Hospitality Management
1003 Tourism Management
1004 Business Administration
Table Name: Courses