Entity-Relationship Model

● Entity Sets
● Relationship Sets
● Design Issues
● Mapping Constraints
● Keys
● E-R Diagram
● Extended E-R Features
● Design of an E-R Database Schema
● Reduction of an E-R Schema to Tables
 Entity Relationship Model
● The objective of Entity Relationship is to design complete structure of
database.

● It is a representation of structure and constraints of the database

● It is independent of DBMS.

● It represent data as entities and its characteristics as attributes.

● An entity-relationship model is used by the designer of the database.

● E-R Diagram depicts the design of database from which implementation

can be done,
 Entity, Attributes

● A database can be modeled as:

● a collection of entities,
● relationship among entities.
● Entity : An entity is an object that exists and is distinguishable from
other objects.
● Example: specific person, company, event, course.
● Entities have attributes
● Example: people have names and addresses
● Attributes : Attributes are characteristics of entity.
Example:
● Student Attributes : roll no , studentname
● Project Attributes : projectno , projectname ,Dept.
 Entity Sets
● An entity set is a set of entities of the same type that share the same
properties.
● Example:all persons having an account at a bank.

Entity Sets customer and loan

customer-id customer- customer- customer- loan- amount

name street city number
 Attributes

● An entity is represented by a set of attributes, that is

descriptive properties possessed by all members of
an entity set.

Example:
1) customer = (customer-id, customer-name, customer-
street, customer-city)

2) loan = (loan-number, amount)

Attributes
Attributes Notations
 Simple Attribute

Simple attributes are those that are atomic (Not

Divisible).
Example: Roll_no, Class and Age.
 Composite Attributes

Composite attributes are those that can be further

subdivided into simpler parts. Here, the attributes “Name”
and “Address” are composite attributes as they are
composed of many other simple attributes.
 Single Valued Attribute

● Single valued attributes are those attributes which can take only one
value for a given entity from an entity set.
● Here, all the attributes are single valued attributes as they can take only
one specific value for each entity. 
 Multi-Valued Attributes

● Multi valued attributes are those attributes which can take more than
one value for a given entity from an entity set.
● Here, the attributes “Mob_no” and “Email_id” are multi valued
attributes as they can take more than one values for a given entity.
Multi Valued Attributes
 Derived Attributes

● Derived attributes are those attributes which can be derived from other
attribute(s).
● Here, the attribute “Age” is a derived attribute as it can be derived from
the attribute “DOB”.
Derived Attributes
 Key Attributes

● Key attributes are those attributes which can identify an entity uniquely
in an entity set.
● Here, the attribute “Roll_no” is a key attribute as it can identify any
student uniquely.
 Domain
● Domain or Value set :
● Domain or Value Set of an attribute is the set of all values that the attribute
can take.
Ex : AGE of an employee can take values from 20 to 60 .
Domain set of AGE attribute for the employee is {20,21. …. 59,60}.

ENO ENAME AGE DNO

1 DEVA 34 10
2 PRABHU 45 10
3 GOPAL 23 20
4 NITIN 24 20
Entity - EMPLOYEE
Attributes - ENO,ENAME,AGE,DNO
Domain of AGE - {34,45,23,24}
Relationship and Their characteristics
● A relationship is an association among one or more entities
Example: EMPLOYEE and DEPARTMENT are two entities with their
own attributes. A relationship exists between EMPLOYEE and
DEPARTMENT IS WORKS_FOR

EMPLOYEE WORKS_FOR DEPARTMENT

santosh R1 CSE

supriya R2 EC

sumangala R3 MATHS

chhaya R4 MECHANICAL
Relationship and Their characteristics
● A relationship set is a mathematical relation among n ≥ 2 entities, each
taken from entity sets
{(e1, e2, … en) | e1 ∈ E1, e2 ∈ E2, …, en ∈ En}

where (e1, e2, …, en) is a relationship

● Example:
(Chhaya, CSE) ∈ WORKS_FOR
(Santosh,CSE) ∈ WORKS_FOR
(Supriya,MATHS) ∈ WORKS_FOR
(Sumangala ,EC) ∈ WORKS_FOR
Relationship Set borrower
Relationship and Their characteristics
● The relationship can be described by certain characteristics.

● Degree of the relationship.

● Role.
● Recursive Relationship.
● Cardinality
● Participation Constraint.
Degree of The Relationship
● The total number of entities participating in
the relation is called degree of the
Relationship.
1.Unary Relationship.
2. Binary Relationship.
3. Ternary Relationship.
 1.Unary Relationship.

● When there is a relationship between two entities of the same type, it is

known as a unary or recursive relationship. This means that the
relationship is between different instances of the same entity type.
● when both participants in the relationship are the same entity.
 Binary Relationship

● When there is a relationship between two different entities, it is known

as a binary relationship.
Binary Relationship
 Ternary Relationship

● When there is a relationship between three different entities, it is

known as a ternary relationship. An example of a ternary relationship
can be shown as follows
 Role
● Role : Role is the function an entity plays in the relationship.
● Roles are optional.
● They help in clarifying the semantics of a relationship.
● EMPLOYEE entity is playing the role of worker.

worker

EMPLOYEE WORK DEPARTMENT

S_FOR
 Recursive Relationship
● When the relationship occurs within the same entity.it is called
Recursive Relationship.
● An entity related to itself is the recursive relationship.
● The same entity performs different roles.
● EMPLOYEE entity is playing the role of worker.
● EMPLOYEE entity is playing the role of manager.

worker manager

EMPLOYEE WORK EMPLOYEE

S
 Recursive Relationship

worker

EMPLOYEE
WORK
S

manager
Recursive Relationship
 Mapping Cardinalities
● The number of instances of an entity in the entity set related with
the number of instances of another entity in its entity set through a
relationship set is called Cardinality ratio.
● Express the number of entities to which another entity can be
associated via a relationship set.
● Most useful in describing binary relationship sets.
CARDINALITY RATIOS
 Mapping Cardinalities

One to one One to many

Note: Some elements in A and B may not be mapped to any
elements in the other set
 Mapping Cardinalities

Many to one Many to many

Note: Some elements in A and B may not be mapped to any
elements in the other set
 Cardinality Ratio

One to One (1:1) : one instance of an entity is related with one instance of another entity
is called One-to-One relationship.

Cardinality ratio is 1:1

 Cardinality Ratio

● One to Many (1:M) : one instance of an entity is related with many

instance of another entity is called One-to-Many relationship.
● Cardinality ratio is 1:M
 Cardinality Ratio

● Many to One (N:1) : Many instances of an entity is related with one

instance of another entity is called Many-to-One relationship.
● Cardinality ratio is N:1
 Cardinality Ratio
Many to Many (M:N) : Many instances of an entity is related with Many
instances of another entity is called Many-to-Many relationship.

Cardinality ratio is M:N

 Participation Constraint
● Participation Constraint : Participation Constraint describe the
participation of an entity in the relationship set.

● Participation is of Two Types

⮚ Total Participation
⮚ Partial Participation

● Total Participation − Each entity is involved in the relationship.

Total participation is represented by double lines.
● Partial participation − Not all entities are involved in the
relationship. Partial participation is represented by single lines.
Participation Constraint
● Total Participation : If every instance of an entity set participates in the
relationship ,it is called Total participation.

TEACHER SUBJECT
TEAC
HES
SUBJECT
TEACHER
Dbms
santosh
Flat
phanikant
System software
manoj
Operating
chhaya System
 Total Participation

● For instance, consider the relationship borrower between customers

and loans. A double line from loan to borrower, as shown in figure
below indicates that each loan must have at least one associated
customer.
Participation Constraint
● Partial Participation : If not every instance of an entity set participates
in the relationship ,it is called Partial participation.

TEACHER SUBJECT
TEAC
HES
SUBJECT
TEACHER
Dbms
santosh
Flat
phanikant
System software
manoj

chhaya
Participation Constraint
● Partial Participation : If not every instance of an entity set participates
in the relationship ,it is called Partial participation.

TEACHER SUBJECT
TEAC
HES
SUBJECT
TEACHER
Dbms
santosh
Flat
phanikant
System software
manoj
SE
chhaya
 Participation Constraint

● Partial Participation:
● For instance, If a company policy states that employee (manager) must
manage a department, However every employee may not manage a
department, so the participation of EMPLOYEE in the MANAGES
relationship type is partial, meaning that some or part of the set of
employee entities are related to some department entity via
MANAGES, but not necessarily all.
 E-R Diagrams

● Rectangles represent entity sets.

● Diamonds represent relationship sets.
● Lines link attributes to entity sets and entity sets to relationship sets.
● Ellipses represent attributes
● Double ellipses represent multivalued attributes.
● Dashed ellipses denote derived attributes.
● Underline indicates primary key attributes (will study later)
E-R Diagram With Composite, Multivalued, and Derived
Attributes
Relationship Sets with Attributes
 Roles
● Entity sets of a relationship need not be distinct
● The labels “manager” and “worker” are called roles; they specify how
employee entities interact via the works-for relationship set.
● Roles are indicated in E-R diagrams by labeling the lines that connect
diamonds to rectangles.
● Role labels are optional, and are used to clarify semantics of the relationship
 Cardinality Constraints
● We express cardinality constraints by drawing either a directed line
(→), signifying “one,” or an undirected line (—), signifying “many,”
between the relationship set and the entity set.
● E.g.: One-to-one relationship:
● A customer is associated with at most one loan via the relationship
borrower
● A loan is associated with at most one customer via borrower
 One-To-Many Relationship

● In the one-to-many relationship a loan is associated with at most one

customer via borrower, a customer is associated with several loans via
borrower
 Many-To-One Relationships

● In a many-to-one relationship a loan is associated with several

customers via borrower, a customer is associated with at most one loan
via borrower
 Many-To-Many Relationship

● A customer is associated with several loans via borrower

● A loan is associated with several customers via borrower
 Participation of an Entity Set in a Relationship
Set
● Total participation (indicated by double line): every entity in the entity set
participates in at least one relationship in the relationship set
● E.g. participation of loan in borrower is total
● every loan must have a customer associated to it via borrower
● Partial participation: some entities may not participate in any relationship in
the relationship set
● E.g. participation of customer in borrower is partial
 Keys

● Key : Key is an attribute or set of attributes that is used

to identify the data in the entity sets.

● KEYS in DBMS is an attribute or set of attributes

which helps you to identify a row(tuple) in a
relation(table). They allow you to find the relation
between two tables. Keys help you uniquely identify a
row in a table by a combination of one or more
columns in that table. Key is also helpful for finding
unique record or row from the table. Database key is
also helpful for finding unique record or row from the
table.
 Why we need a key?

● Keys help you to identify any row of data in a table. In a

real-world application, a table could contain thousands of
records. Moreover, the records could be duplicated. Keys
ensure that you can uniquely identify a table record despite
these challenges.
● Allow you to establish a relationship between and identify
the relation between tables
● Help you to enforce identity and integrity in the
relationship.
 Keys

● There are mainly six different types of Keys in DBMS

and each key has it’s different functionality:
● Super Key -  A super key is a group of single or
multiple keys which identifies rows in a table.
● Primary Key -  is a column or group of columns in a
table that uniquely identify every row in that table.
● Candidate Key -  is a set of attributes that uniquely
identify tuples in a table. Candidate Key is a super key
with no repeated attributes.
● Alternate Key -  is a column or group of columns in a
table that uniquely identify every row in that table.
 Keys

● Foreign Key -  is a column that creates a relationship

between two tables. The purpose of Foreign keys is to
maintain data integrity and allow navigation between two
different instances of an entity.
● Compound Key -  has two or more attributes that allow
you to uniquely recognize a specific record. It is possible
that each column may not be unique by itself within the
database.
 Primary Key

● PRIMARY KEY is a column or group of columns in a table that

uniquely identify every row in that table. The Primary Key can't be a
duplicate, meaning, the same value can't appear more than once in the
table. A table cannot have more than one primary key.
● Rules for defining Primary key:
● Two rows can't have the same primary key value
● It is must for every row to have a primary key value.
● The primary key field cannot be null.
● The value in a primary key column can never be modified or updated if
any foreign key refers to that primary key.
Primary Key example
 Candidate Keys

● CANDIDATE KEY is a set of attributes that uniquely identify tuples

in a table. Candidate Key is a super key with no repeated attributes.
The Primary key should be selected from the candidate keys. Every
table must have at least a single candidate key. A table can have
multiple candidate keys but only a single primary key.

● Properties of Candidate key:

● It must contain unique values
● Candidate key may have multiple attributes
● Must not contain null values
● It should contain minimum fields to ensure uniqueness
● Uniquely identify each record in a table
Candidate Keys
 Alternate Keys

● ALTERNATE KEYS is a column or group of columns in a table that

uniquely identify every row in that table. A table can have multiple
choices for a primary key but only one can be set as the primary key.
All the keys which are not primary key are called an Alternate Key.
 Super Key

● A superkey is a group of single or multiple keys which identifies rows

in a table. A Super key may have additional attributes that are not
needed for unique identification..

In the above EMPLOYEE table, for(EMPLOEE_ID, EMPLOYEE_NAME) the

name of two employees can be the same, but their EMPLYEE_ID can't be the same.
Hence, this combination can also be a key.
The super key would be EMPLOYEE-ID, (EMPLOYEE_ID, EMPLOYEE-
NAME), etc.
 Foreign keys

● FOREIGN KEY is a column that creates a

relationship between two tables.
● The purpose of Foreign keys is to maintain data
integrity and allow navigation between two
different instances of an entity.
● It acts as a cross-reference between two tables as it
references the primary key of another table.
Foreign Keys
 Foreign Keys

● In this key in dbms example, we have two table, teach and department
in a school. However, there is no way to see which search work in
which department.
● In this table, adding the foreign key in Deptcode to the Teacher name,
we can create a relationship between the two tables.
 Compound Keys

● COMPOUND KEY has two or more attributes

that allow you to uniquely recognize a specific
record.
● It is possible that each column may not be unique
by itself within the database.
● However, when combined with the other column
or columns the combination of composite keys
become unique.
● The purpose of the compound key in database is to
uniquely identify each record in the table.
Compound Keys
Entity Sets
 Strong Entity Sets
● Strong Entity Set- 
● A strong entity set is an entity set that contains sufficient attributes to
uniquely identify all its entities.
● In other words, a primary key exists for a strong entity set.
● Primary key of a strong entity set is represented by underlining it. 

● Symbols Used-
● A single rectangle is used for representing a strong entity set.
● A diamond symbol is used for representing the relationship that exists
between two strong entity sets.
● A single line is used for representing the connection of the strong entity set
with the relationship set.
● A double line is used for representing the total participation of an entity set
with the relationship set.
● Total participation may or may not exist in the relationship.
 Strong Entity Sets

⮚ Two strong entity sets “Student” and “Course” are related to each other.

⮚ Student ID is the primary key using which any student can be identified uniquely.

⮚ Course ID is the primary key using which any course can be identified uniquely.

⮚ Double line between Student and relationship set signifies total participation.

⮚ It suggests that each student must be enrolled in at least one course.

⮚ Single line between Course and relationship set signifies partial participation.
It suggests that there might exist some courses for which no enrolments are made.
 Weak Entity sets

● A weak entity set is an entity set that does not contain sufficient
attributes to uniquely identify its entities.
● In other words, a primary key does not exist for a weak entity set.
● However, it contains a partial key called as a discriminator.
● Discriminator can identify a group of entities from the entity set.
● Discriminator is represented by underlining with a dashed line.
 Weak Entity sets

● Symbols Used-

● A double rectangle is used for representing a weak entity set.

● A double diamond symbol is used for representing the relationship that
exists between the strong and weak entity sets and this relationship is
known as identifying relationship.
● A double line is used for representing the connection of the weak entity
set with the relationship set.
● Total participation always exists in the identifying relationship.
Weak Entity Sets
 Weak Entity Sets

● One strong entity set “Building” and one weak entity set “Apartment” are
related to each other.
● Strong entity set “Building” has building number as its primary key.
● Door number is the discriminator of the weak entity set “Apartment”.
● This is because door number alone can not identify an apartment uniquely as
there may be several other buildings having the same door number.
● Double line between Apartment and relationship set signifies total
participation.
● It suggests that each apartment must be present in at least one building.
● Single line between Building and relationship set signifies partial
participation.
● It suggests that there might exist some buildings which has no apartment.
Weak Entity Sets
Strong vs Weak Entity Sets
 Keys for Relationship Sets

● The combination of primary keys of the participating entity sets forms

a super key of a relationship set.
● (customer-id, account-number) is the super key of depositor
● NOTE: this means a pair of entity sets can have at most one relationship
in a particular relationship set.
● E.g. if we wish to track all access-dates to each account by each
customer, we cannot assume a relationship for each access. We can use
a multivalued attribute though
● Must consider the mapping cardinality of the relationship set when
deciding the what are the candidate keys
● Need to consider semantics of relationship set in selecting the primary
key in case of more than one candidate key
 E-R Design Decisions

● The use of an attribute or entity set to represent an object.

● Whether a real-world concept is best expressed by an entity set or a
relationship set.
● The use of a ternary relationship versus a pair of binary relationships.
● The use of a strong or weak entity set.
● The use of specialization/generalization – contributes to modularity in
the design.
● The use of aggregation – can treat the aggregate entity set as a single
unit without concern for the details of its internal structure.
E-R Diagram for a Banking Enterprise
Summary of Symbols Used in E-R Notation
Summary of Symbols (Cont.)
Alternative E-R Notations
● Construct an E-R diagram for a hospital
with a set of patients and a set of
medical doctors. Associate with each
patient a log of the various tests and
examinations conducted.
● A university registrar’s office maintains data about the following
entities: (a) courses, including number, title, credits, syllabus, and
prerequisites; (b) course offerings, including course number, year,
semester, section number, instructor(s), timings, and classroom; (c)
students, including student-id, name, and program; and (d) instructors,
including identification number, name, department, and title. Further,
the enrollment of students in courses and grades awarded to students in
each course they are enrolled for must be appropriately modeled.
● Construct an E-R diagram for the registrar’s office. Document all
assumptions that you make about the mapping constraints
 Music Database
We first draw up a clear list of requirements for our database:

1.The collection consists of albums.

2.An album is made by exactly one artist.
3.An artist makes one or more albums.
4.An album contains one or more tracks
5.Artists, albums, and tracks each have a name.
6.Each track is on exactly one album.
7.Each track has a time length, measured in seconds.
8.When a track is played, the date and time the playback began (to the nearest
second) should be recorded; this is used for reporting when a track was last played,
as well as the number of times music by an artist, from an album, or a track has
been played.
9.There’s no requirement to capture composers, group members or sidemen,
recording date or location, the source media, or any other details of artists, albums,
or tracks.
● It consists of only one-to-many relationships:
● one artist can make many albums,
● one album can contain many tracks, and
● one track can be played many times.

● Conversely,
● each play is associated with one track,
● a track is on one album, and
● an album is by one artist.

● The attributes are straightforward: artists, albums, and tracks have names,
as well as identifiers to uniquely identify each entity.
● The track entity has a time attribute to store the duration, and the played
entity has a timestamp to store when the track was played.
● The only strong entity in the database is 
1) Artist, which has an artist_id attribute that uniquely identifies it.
2) Each Album entity is uniquely identified by its album_id combined with
the artist_id of the corresponding Artist entity.
3) A Track entity is similarly uniquely identified by its track_id combined
with the related album_id and artist_id attributes.
4) The Played entity is uniquely identified by a combination of
its played time, and the related track_id, album_id, and artist_id attributes.
 UNIVERSITY DATABASE

● The university database stores details

about university students, courses, the semester a
student took a particular course (and his mark and
grade if he completed it), and what degree program
each student is enrolled in.
Consider the following requirements list:
●The university offers one or more programs.
●A program is made up of one or more courses.
●A student must enroll in a program.
●A student takes the courses that are part of her program.
●A program has a name, a program identifier, the total credit points required
to graduate, and the year it commenced.
●A course has a name, a course identifier, a credit point value, and the year it
commenced.
●Students have one or more given names, a surname, a student identifier, a
date of birth, and the year they first enrolled. We can treat all given names as a
single object—for example, “John Paul.”
●When a student takes a course, the year and semester he attempted it are
recorded. When he finishes the course, a grade (such as A or B) and a mark
(such as 60 percent) are recorded.
●Each course in a program is sequenced into a year (for example, year 1) and
a semester (for example, semester 1).
● In our design:
● Student is a strong entity, with an identifier, student_id, created to be the
primary key used to distinguish between students (remember, we could have
several students with the same name).

● Program is a strong entity, with the identifier program_id as the primary key

used to distinguish between programs.

● Each student must be enrolled in a program, so the Student entity participates

totally in the many-to-one EnrollsIn relationship with Program.

● A program can exist without having any enrolled students, so it participates

partially in this relationship.

● A Course has meaning only in the context of a Program, so it’s a weak entity,

with course_id as a weak key. This means that a Course is uniquely identified
using its course_id and the program_id of its owning program.
● As a weak entity, Course participates totally in the many-to-one
identifying relationship with its owning Program. This relationship
has Year and Semester attributes that identify its sequence position.

● Student and Course are related through the many-to-

many Attempts relationships; a course can exist without a student, and a
student can be enrolled without attempting any courses, so the participation
is not total.
 BANK DATABASE MANAGEMENT SYSTEM

ER diagram of Bank has the following description :

•Bank have customer.
•Banks are identified by a name, code, address of main office.
•Banks have branches.
•Branches are identified by a branch_no., Branch_name, address.
•Customers are identified by name, cust-id, phone number, address.
•Customer can have one or more accounts.
•Accounts are identified by acc_no., Acc_type, balance.
•Customer can avail loans.
•Loans are identified by loan_id, loan_type and amount.
•Account and loans are related to bank’s branch.
 Entities and their Attributes are
• Bank entity : attributes of bank entity are bank name, code and address.
Code is primary key for bank entity.
• Customer entity : attributes of customer entity are customer_id, name, phone number
and address.
Customer_id is primary key for customer entity.
• Branch entity : attributes of branch entity are branch_id, name and address.
Branch_id is primary key for branch entity.
• Account entity : attributes of account entity are account_number, account_type and
balance.
Account_number is primary key for account entity.
• Loan entity : attributes of loan entity are loan_id, loan_type and amount.
Loan_id is primary key for loan entity.
 Relationships are
• Bank has branches => 1 : N
one bank can have many branches but one branch can not belong to many banks, so
the relationship between bank and branch is one to many relationship.
• Branch maintain accounts => 1 : N
one branch can have many accounts but one account can not belong to many branches,
so the relationship between branch and account is one to many relationship.
• Branch offer loans => 1 : N
one branch can have many loans but one loan can not belong to many branches, so the
relationship between branch and loan is one to many relationship.
• Account held by customers => m : n
one customer can have more than one accounts and also one account can be held by
one or more customers(Joint account), so the relationship between account and
customers is many to many relationship.
• Loan availed by customer => m : n
(assume loan can be jointly held by many customers).
One customer can have more than one loans and also one loan can be availed by one
or more customers, so the relationship between loan and customers is many to many
relationship.
 Library Management System
● The library management system database keeps track of readers with the following
considerations –
• The system keeps track of the staff with a single point authentication system comprising
login id and password.
• Staff maintains the book catalog with its ISBN, book title, price(in INR), category(novel,
general, story), edition, author number and details.
• A publisher has publisher id, year when the book was published, and name of the book.
• Readers are registered with their user_id, email, name (first name, last name), phone no
(multiple entries allowed), communication address. The staff keeps track of readers.
• Readers can return/reserve books that stamps with issue date and return date. If not
returned within the prescribed time period, it may have a due date too.
• Staff also generate reports that has readers id, registration no of report, book no and
return/issue info.
Library Management System
Entities and their Attributes –

•Book entity : it has author number , ISBN number, title, edition, category, price.
ISBN(International Standard Book Number) is the primary key for book entity.
•Reader entity : it has user Id, email, address, phone no, name. Name is composite attribute
of firstname and lastname. Phone no is multi valued attribute. Userid is the primary key for
readers entity.
•Publisher entity : it has Publisher Id, year of publication, name. Publisher id is the primary
key.
•Authentication system entity : it has login id and password with login id as primary key.
•Reports entity : it has user id, reg_no, book_no, issue/return date. Reg_no is the primary
key of reports entity.
•Staff entity : it has staff name and staff_id with staff_id as primary key.
•Reserve/return relationship set : it has three attributes: reserve date, due date, return date.
Relationship between Entities

•A reader can reserve N books but one book can be reserved by only one
reader. The relationship 1:N.
•A publisher can publish many books but a book is published by only one
publisher. The relationship 1:N.
•Staffs keeps track of readers. The relationship is M:N.
•Staff maintains multiple reports. The relationship 1:N.
•Staff maintains multiple books. The relationship 1:N.
•Authentication system provides login to multiple staffs. The relation is
1:N.
 Flight Database
● The flight database stores details about an airline’s fleet, flights, and seat
bookings.

Consider the following requirements list:

1) The airline has one or more airplanes.
2) An airplane has a model number, a unique registration number, and the
capacity to take one or more passengers.
3) An airplane flight has a unique flight number, a departure airport, a
destination airport, a departure date and time, and an arrival date and time.
4) Each flight is carried out by a single airplane.
5) A passenger has given names, a surname, and a unique email address.
6) A passenger can book a seat on a flight.
● An Airplane is uniquely identified by its RegistrationNumber, so we use this
as the primary key.

● A Flight is uniquely identified by its FlightNumber, so we use the flight

number as the primary key. The departure and destination airports are captured
in the From and To attributes, and we have separate attributes for the departure
and arrival date and time.

● Because no two passengers will share an email address, we can use

the EmailAddress as the primary key for the Passenger entity.

● An airplane can be involved in any number of flights,

while each flight uses exactly one airplane, so the Flies relationship between
the Airplane and Flight relationships has cardinality 1:N; because a flight
cannot exist without an airplane.
The Flight entity participates totally in this relationship.

● A passenger can book any number of flights, while a flight can be booked by
any number of passengers.